Bug#1005863: gcc-11: invalid opcode for Geode LX on i386
On Sun, Mar 19, 2023 at 11:47:21PM +, James Addison wrote: > Package: gcc-11 > Followup-For: Bug #1005863 > X-Debbugs-Cc: debian-gcc@lists.debian.org, debian-rele...@lists.debian.org, > debian-pol...@lists.debian.org > > Hi folks, > > Bug #1005863 describes a gcc-11 behaviour that results in software that exits > ungracefully on Geode LX i686 hardware. Despite self-reporting as i586 > sometimes, Geode LX is in fact an i686 CPU (without physical address > extensions > and multi-instruction noops -- both optional per spec). > > My assessment -- which may be incorrect -- is that something like 20% of > packages in the bookworm i386 suite are susceptible to the bug, so I think > that > installing bookworm on a Geode LX system would present users with a poor > experience of Debian. > > Would it be fair to raise the severity of this bug to a release-critical > level? >From a purely engineering perspective, without a way to address this problem, increasing the severity will not achieve much. Instead this should be documented in the release notes, with any relevant information. However, the fact that the the CPU is 15 year old is not a sufficient rationale to stop supporting it. It is more useful for debian-i386 to focus on CPUs that cannot run debian-amd64 than on CPUs that can. Cheers, -- Bill. Imagine a large red swirl here.
Bug#1006803: -Wuse-after-free: spurious warning
Package: gcc-12
Version: 12-20220302-1
Severity: normal
Dear GCC maintainers,
The following sample code gives a spurious warning with gcc-12:
gcc-12 -c -O3 -Wall test.c
test.c: In function ‘fun’:
test.c:5:25: warning: pointer ‘old’ used after ‘realloc’
[-Wuse-after-free]
5 | unsigned long s = new-old;
| ~~~^~~~
test.c:4:15: note: call to ‘realloc’ here
4 | void *new = realloc(old, n);
| ^~~
It should check that "old" is dereferenced.
Cheers,
--
Bill.
Imagine a large red swirl here.
#include
unsigned long fun(void *old, void **ptr, size_t n)
{
void *new = realloc(old, n);
unsigned long s = new-old;
*ptr = new;
return s;
}
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, Aug 13, 2020 at 12:26:53PM +0200, Bill Allombert wrote: > Building such i386 chroots now would require heavy use of snaphots.debian.org, > and would be much less convenient. > > > Also there are amd64 -> > > i386 cross compilers for the newer versions. Is it really necessary to > > keep the > > non-default multilib builds? > > What is the cost of adding this Provides ? I am sorry to have answered your question by a question, but it seems you are seeing downsides to adding the Provides we are not aware of. Cheers, -- Bill. Imagine a large red swirl here.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, Aug 13, 2020 at 12:02:50PM +0200, Matthias Klose wrote: > On 8/13/20 11:49 AM, Bill Allombert wrote: > > On Thu, Aug 13, 2020 at 11:25:21AM +0200, Matthias Klose wrote: > >> On 8/12/20 11:16 PM, Bill Allombert wrote: > >>> On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: > >>>> On 21/05/2020 14.05, Matthias Klose wrote: > >>>>> On 5/20/20 10:32 PM, Andreas Beckmann wrote: > >>>>>> With the transitional packages gone in 10.1.0-2, please add versioned > >>>>>> (epoched!) provides on the old names (as already done in libgcc-s1) > >>>>>> in order to keep old packages installable along the latest gcc. > >>>>> > >>>>> I'd like to avoid that. Please build the nvidia packages using the new > >>>>> package > >>>>> names. > >>>> > >>>> This has nothing to do with nvidia. This breaks keeping old compilers > >>>> around, which so far worked fine for a long time. > >>> > >>> Seconded. I have all versions of gcc starting at 4.4 that I would like > >>> to keep, but the upgrade require to remove them. > >> > >> I don't want to do that. What exactly depends on the non-default multilib > >> libraries? > > > > # apt-get dist-upgrade > > The following packages will be REMOVED: > > g++-4.4-multilib g++-4.5-multilib g++-4.6-multilib g++-4.7-multilib > > g++-5-multilib > > g++-6-multilib gcc-4.4-multilib gcc-4.5-multilib gcc-4.6-multilib > > gcc-4.7-multilib > > gcc-5-multilib gcc-6-multilib lib32asan0 lib32asan1 lib32asan2 lib32asan3 > > lib32asan4 > > lib32cilkrts5 lib32gcc-4.7-dev lib32gcc-4.8-dev lib32gcc-4.9-dev > > lib32gcc-5-dev > > lib32gcc-6-dev lib32gcc-7-dev lib32gcc1 lib32stdc++-4.9-dev > > lib32stdc++-5-dev > > lib32stdc++-6-dev lib32stdc++6-4.7-dev lib32ubsan0 > > libclang-common-5.0-dev libgc1c2 libgcc1 > > libx32asan0 libx32asan1 libx32asan2 libx32asan3 libx32asan4 > > libx32cilkrts5 libx32gcc-4.7-dev > > libx32gcc-5-dev libx32gcc-6-dev libx32gcc-7-dev libx32gcc1 > > libx32stdc++-5-dev > > libx32stdc++-6-dev libx32stdc++6-4.7-dev libx32ubsan0 > > ok, so this is for the multilib compiler packages only. The default multilib > is > not affected by this change. > > > libgcc-s1 Provides: libgcc1 (= 1:10-20200418-1) which is OK. > > However lib32gcc-s1 does not provides lib32gcc1 (= 1:10-20200418-1) > > so packages depending on lib32gcc1 are broken. > > > > I like to add: I have all these compilers available for test purpose > > on my system thanks to your hard work packaging gcc over so many years. > > It is really neat. It would be sad to lose all this now. > > You have those available in i386/x32 chroots as well. Building such i386 chroots now would require heavy use of snaphots.debian.org, and would be much less convenient. > Also there are amd64 -> > i386 cross compilers for the newer versions. Is it really necessary to keep > the > non-default multilib builds? What is the cost of adding this Provides ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, Aug 13, 2020 at 11:25:21AM +0200, Matthias Klose wrote: > On 8/12/20 11:16 PM, Bill Allombert wrote: > > On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: > >> On 21/05/2020 14.05, Matthias Klose wrote: > >>> On 5/20/20 10:32 PM, Andreas Beckmann wrote: > >>>> With the transitional packages gone in 10.1.0-2, please add versioned > >>>> (epoched!) provides on the old names (as already done in libgcc-s1) > >>>> in order to keep old packages installable along the latest gcc. > >>> > >>> I'd like to avoid that. Please build the nvidia packages using the new > >>> package > >>> names. > >> > >> This has nothing to do with nvidia. This breaks keeping old compilers > >> around, which so far worked fine for a long time. > > > > Seconded. I have all versions of gcc starting at 4.4 that I would like > > to keep, but the upgrade require to remove them. > > I don't want to do that. What exactly depends on the non-default multilib > libraries? # apt-get dist-upgrade The following packages will be REMOVED: g++-4.4-multilib g++-4.5-multilib g++-4.6-multilib g++-4.7-multilib g++-5-multilib g++-6-multilib gcc-4.4-multilib gcc-4.5-multilib gcc-4.6-multilib gcc-4.7-multilib gcc-5-multilib gcc-6-multilib lib32asan0 lib32asan1 lib32asan2 lib32asan3 lib32asan4 lib32cilkrts5 lib32gcc-4.7-dev lib32gcc-4.8-dev lib32gcc-4.9-dev lib32gcc-5-dev lib32gcc-6-dev lib32gcc-7-dev lib32gcc1 lib32stdc++-4.9-dev lib32stdc++-5-dev lib32stdc++-6-dev lib32stdc++6-4.7-dev lib32ubsan0 libclang-common-5.0-dev libgc1c2 libgcc1 libx32asan0 libx32asan1 libx32asan2 libx32asan3 libx32asan4 libx32cilkrts5 libx32gcc-4.7-dev libx32gcc-5-dev libx32gcc-6-dev libx32gcc-7-dev libx32gcc1 libx32stdc++-5-dev libx32stdc++-6-dev libx32stdc++6-4.7-dev libx32ubsan0 libgcc-s1 Provides: libgcc1 (= 1:10-20200418-1) which is OK. However lib32gcc-s1 does not provides lib32gcc1 (= 1:10-20200418-1) so packages depending on lib32gcc1 are broken. I like to add: I have all these compilers available for test purpose on my system thanks to your hard work packaging gcc over so many years. It is really neat. It would be sad to lose all this now. Cheers, -- Bill. Imagine a large red swirl here.
Bug#961159: lib32{,x}gcc-s1: please provide lib{,x}32gcc1 (= 1:${binary:Version})
On Thu, May 21, 2020 at 02:15:51PM +0200, Andreas Beckmann wrote: > On 21/05/2020 14.05, Matthias Klose wrote: > > On 5/20/20 10:32 PM, Andreas Beckmann wrote: > >> With the transitional packages gone in 10.1.0-2, please add versioned > >> (epoched!) provides on the old names (as already done in libgcc-s1) > >> in order to keep old packages installable along the latest gcc. > > > > I'd like to avoid that. Please build the nvidia packages using the new > > package > > names. > > This has nothing to do with nvidia. This breaks keeping old compilers > around, which so far worked fine for a long time. Seconded. I have all versions of gcc starting at 4.4 that I would like to keep, but the upgrade require to remove them. Cheers, -- Bill. Imagine a large red swirl here.
Bug#898323: g++-8 -m32 do not find bits/c++config.h
Package: g++-8
Version: 8.1.0-1
Severity: normal
Hello GCC maintainers,
trying to the attached dummy file with g++-8 fails:
g++-8 -m32 hello.c
In file included from /usr/include/c++/8/stdlib.h:36,
from hello.c:1:
/usr/include/c++/8/cstdlib:41:10: fatal error: bits/c++config.h: No such file
or directory
#include
^~
compilation terminated.
g++-8-multilib is installed.
This work with g++-7 and g++-6
Maybe this is related to
"* Stop providing the 8.x.y symlinks in gcc_lib_dir and incluce/c++. "
ii g++-8 8.1.0-1amd64 GNU C++ compiler
ii g++-8-multilib 8.1.0-1amd64 GNU C++ compiler (multilib
support)
ii lib32stdc++-8-dev 8.1.0-1amd64 GNU Standard C++ Library
v3 (development
Cheers,
Bill.
#include
int main(void)
{
return 1;
}
Bug#635214: gcc-4.6: [sparc] miscompile PARI/GP 2.5.0 [test-case provided]
Hello GCC maintainers,
Please find a smaller test-case.
smetana% gcc -O3 -Wall -g test.c -o test
smetana% ./test
zsh: segmentation fault ./test
smetana% gcc -O3 -Wall -g test.c -o test -fno-inline
smetana% ./test
smetana%
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
#include stdlib.h
inline void*
pari_realloc(void *pointer, size_t size)
{
if (!pointer) return malloc(size);
else return realloc(pointer,size);
}
typedef struct {
long offset;
size_t size;
} pari_stack;
inline void
stack_init(pari_stack *s, size_t size, void **data)
{
s-offset = (char *)data-(char *)s;
*data = NULL;
s-size = size;
}
inline void
stack_alloc(pari_stack *s)
{
void **sdat = (void **) ((char *)s+s-offset);
*sdat = pari_realloc(*sdat,s-size);
}
static void ** MODULES;
static pari_stack s_MODULES;
void
pari_init_functions(void)
{
stack_init(s_MODULES, sizeof(*MODULES),(void**)MODULES);
stack_alloc(s_MODULES); MODULES[0]=NULL;
}
int main(void)
{
pari_init_functions();
return 0;
}
Bug#635214: gcc-4.6: [sparc] miscompile PARI/GP 2.5.0 [test-case provided]
Package: gcc-4.6
Version: 4.6.1-4
Severity: normal
Hello Debian GCC Maintainers,
gcc-4.6 miscompiles pari 2.5.0 on sparc, see
See
https://buildd.debian.org/status/fetch.php?pkg=pariarch=sparcver=2.5.0-1stamp=1311418380
Please find a small test-case attached (test.c)
gcc -O2 -g -Wall -fno-strict-aliasing test.c -o test
./test
zsh: segmentation fault ./test
It does not segfault with -fno-inline and also with -fPIC.
This bug is very similar to 627084 except it only happens on sparc and that the
test-case is simpler.
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
#include stdlib.h
inline void*
pari_realloc(void *pointer, size_t size)
{
char *tmp;
if (!pointer)
tmp = (char *) malloc(size);
else
tmp = (char *) realloc(pointer,size);
return tmp;
}
typedef struct {
long offset;
long n;
long alloc;
size_t size;
} pari_stack;
inline void **
stack_base(pari_stack *s) { return (void **) ((char *)s+s-offset); }
inline void
stack_init(pari_stack *s, size_t size, void **data)
{
s-offset = (char *)data-(char *)s;
*data = NULL;
s-n = 0;
s-alloc = 0;
s-size = size;
}
inline void
stack_alloc(pari_stack *s, long nb)
{
void **sdat = stack_base(s);
if (s-n+nb = s-alloc) return;
if (!s-alloc)
s-alloc = nb;
else
{
while (s-n+nb s-alloc) s-alloc = 1;
}
*sdat = pari_realloc(*sdat,s-alloc*s-size);
}
inline long
stack_new(pari_stack *s) { stack_alloc(s, 1); return s-n++; }
inline void
stack_pushp(pari_stack *s, void *u)
{
long n = stack_new(s);
void **sdat =(void**) *stack_base(s);
sdat[n] = u;
}
static void ** MODULES, ** OLDMODULES;
static pari_stack s_MODULES, s_OLDMODULES;
void
pari_init_functions(void)
{
stack_init(s_MODULES, sizeof(*MODULES),(void**)MODULES);
stack_pushp(s_MODULES,NULL);
stack_init(s_OLDMODULES, sizeof(*OLDMODULES),(void**)OLDMODULES);
stack_pushp(s_OLDMODULES,NULL);
}
int main(void)
{
pari_init_functions();
return 0;
}
Bug#631292: gcc-4.4: ia64: ICE while compiling PARI/GP 2.5.0
On Wed, Jun 22, 2011 at 06:17:55PM +0200, Bill Allombert wrote: Package: gcc-4.4 Version: 4.4.6-4 Severity: normal Hello Debian GCC Maintainers, On ia64, gcc ICE while compiling PARI/GP 2.5.0. This happens with: sid: gcc 4.4.6-4 squeeze: gcc 4.4.5-8 The compiler below works: sid : gcc 4.6.0-12 lenny: gcc 4.3.2-1.1 and please find the preprocessed source at: http://people.debian.org/~ballombe/misc/krasner.i gcc-4.4 -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer -fPIC -o krasner.o krasner.i and gcc-4.4 -c -O3 -Wall -fno-strict-aliasing -o krasner.o krasner.i ICE but gcc-4.4 -c -O2 -Wall -fno-strict-aliasing -fomit-frame-pointer -fPIC -o krasner.o krasner.i does not ICE. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110622164708.GA31834@yellowpig
Bug#631292: gcc-4.4: ia64: ICE while compiling PARI/GP 2.5.0
Package: gcc-4.4 Version: 4.4.6-4 Severity: normal Hello Debian GCC Maintainers, On ia64, gcc ICE while compiling PARI/GP 2.5.0. This happens with: sid: gcc 4.4.6-4 squeeze: gcc 4.4.5-8 The compiler below works: sid : gcc 4.6.0-12 lenny: gcc 4.3.2-1.1 How to reproduce: wget http://pari.math.u-bordeaux.fr/pub/pari/unix/pari-2.5.0.tar.gz tar xf pari-2.5.0.tar.gz cd pari-2.5.0 CC=gcc-4.4 ./Configure make gp The log from merulo is in attachment. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. Making gp in Olinux-ia64 make[1]: Entering directory `/home/ballombe/pari-2.5.0/Olinux-ia64' /usr/bin/gcc -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer-I. -I../src/headers -fPIC -o krasner.o ../src/modules/krasner.c ../src/modules/krasner.c: In function 'GetRamifiedPol': ../src/modules/krasner.c:878: error: unrecognizable insn: (insn 3685 2258 3694 56 (parallel [ (set (reg:DI 134 f6) (asm_operands:DI (xma.hu %0 = %2, %3, f0 ;; xma.l %1 = %2, %3, f0) (=f) 0 [ (reg:DI 135 f7) (reg/v:DI 130 f2 [orig:495 pmodg ] [495]) ] [ (asm_input:DI (f) 0) (asm_input:DI (f) 0) ] 3377396)) (set (reg:DI 135 f7) (asm_operands:DI (xma.hu %0 = %2, %3, f0 ;; xma.l %1 = %2, %3, f0) (=f) 1 [ (reg:DI 135 f7) (reg/v:DI 130 f2 [orig:495 pmodg ] [495]) ] [ (asm_input:DI (f) 0) (asm_input:DI (f) 0) ] 3377396)) ]) -1 (nil)) ../src/modules/krasner.c:878: internal compiler error: in internal_dfa_insn_code, at config/ia64/itanium2.md:1676 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. make[1]: *** [krasner.o] Error 1 make[1]: Leaving directory `/home/ballombe/pari-2.5.0/Olinux-ia64' make: *** [gp] Error 2
Re: Processed: Re: gcc-4.6: miscompile PARI/GP SVN revision 12000
On Thu, Jun 16, 2011 at 02:18:06PM +, Debian Bug Tracking System wrote: Processing commands for cont...@bugs.debian.org: reassign 627084 pari Bug #627084 [gcc-4.6] gcc-4.6: miscompile PARI/GP SVN revision 12000 Bug reassigned from package 'gcc-4.6' to 'pari'. Bug No longer marked as found in versions gcc-4.6/4.6.0-7. You cannot reassign it to pari: the pari package in Debian does not incude the offending code. I have still hope to report a test-case that does not include it FWIW. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110616143727.GA27998@yellowpig
Bug#630567: gcc-4.6: powerpc: gcc -O2 miscompiles gp2c (with testcase)
Package: gcc-4.6
Version: 4.6.0-12
Severity: normal
Hello Debian GCC Maintainers,
gcc-4.6 miscompiles gp2c on several platforms including powerpc, see
https://buildd.debian.org/status/package.php?p=gp2c
On powerpc (32 bit):
The function 'listostack' in src/utils.c is miscompiled with -O2.
Please find a testcase.
gcc-4.6 -O2 -Wall gccbug.c -o gccbug ./gccbug
zsh: segmentation fault ./gccbug
gcc-4.6 -O1 -Wall gccbug.c -o gccbug ./gccbug
nb=2
0: 1
1: 2
Cheers,
--
Bill. ballo...@debian.org
Imagine a large red swirl here.
#include stdio.h
#include stdlib.h
typedef struct
{
enum {LEAF=0, NODE=1} f;/*node function*/
int x; /*node left child*/
int y; /*node right child*/
} node;
node *tree;
int listtostack(int n, int f, int *stack, int nbmax)
{
int x,i,nb;
if (n==-1) return 0;
for(x=n,i=0;tree[x].f==f inbmax;x=tree[x].x,i++);
if (i==nbmax)
exit(1);
nb=i+1;
for(x=n;i0;stack[i]=tree[x].y,x=tree[x].x,i--);
stack[0]=x;
return nb;
}
#define STACKSZ 3
int main(void)
{
int stack[STACKSZ];
int i,nb;
tree = (node *)calloc(STACKSZ,sizeof(node));
tree[0].f = NODE;
tree[0].x = 1;
tree[0].y = 2;
nb=listtostack(0,1,stack,STACKSZ);
printf(nb=%d\n,nb);
for(i=0;inb;i++)
printf(%d: %d\n,i,stack[i]);
return 0;
}
Bug#627084: gcc-4.6: miscompile PARI/GP SVN revision 12000
Package: gcc-4.6 Version: 4.6.0-7 Severity: normal Hello Debian GCC Maintainers, gcc 4.6 on Debian/amd64 miscompiles PARI/GP SVN revision 12000: Step to reproduce: wget 'http://pari.math.u-bordeaux.fr/~bill/pari-2.4.3.12000.tar.gz' tar xf pari-2.4.3.12000.tar.gz cd pari-2.4.3.alpha ./Configure make gp make bench Result: all test suite fail. Cause: The function pari_init_parser() in the file src/language/parsec.h is miscompiled. (This file is included by src/language/parse.y). If you replace the line 43: s_node.n=OPnboperator; by parsestate_reset(); (which does the same thing), then all test pass. It seems that the issue is that the function stack_alloc() is not inlined correctly, which cause pari_tree to be NULL (or maybe the call to pari_inline inside stack_alloc() is not inlined correctly. The command line used is gcc-4.6 -c -O3 -Wall -fno-strict-aliasing -fomit-frame-pointer-I. -I../src/headers -fPIC -o parse.o ../src/language/parse.c It also happens with -O2, but not with -O3 -fno-inline. It works fine with gcc 4.3, 4.4 and 4.5. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110517150530.GA2420@yellowpig
Bug#619933: gcc-4.6-doc: please upload to unstable
Package: gcc-4.6-doc Severity: normal Hello Debian GCC maintainers, Please upload gcc-4.5-doc and gcc-4.6-doc to unstable, since gcc-4.5 and gcc-4.6 are in unstable. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20110328131403.GA22519@yellowpig
Bug#541816: gcc-4.4: eat all memory (regression from 4.4.1-1)
Package: gcc-4.4 Version: 4.4.1-2 Severity: important Hello Debian GCC Maintainers, Compiling the file linked below (on amd64) http://people.debian.org/~ballombe/misc/gcc44bug.i.gz with gcc-4.4 -c -O2 -Wall -fno-strict-aliasing -o base3.o gcc44bug.i cause gcc to eat all available memory and die. This is a regression from 4.4.1-1. This occurs both on amd64 and i386 (with a differently preprocessed file). Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#541816: gcc-4.4: eat all memory (regression from 4.4.1-1)
On Sun, Aug 16, 2009 at 04:00:34PM +0200, Bill Allombert wrote: Package: gcc-4.4 Version: 4.4.1-2 Severity: important Hello Debian GCC Maintainers, Compiling the file linked below (on amd64) http://people.debian.org/~ballombe/misc/gcc44bug.i.gz with gcc-4.4 -c -O2 -Wall -fno-strict-aliasing -o base3.o gcc44bug.i cause gcc to eat all available memory and die. This is a regression from 4.4.1-1. This occurs both on amd64 and i386 (with a differently preprocessed file). I forgot to mention that gcc44bug.i is the file src/basemath/base3.c in pari 2.3.4 (in Debian). Experimentally, the problem is with compiling the line r=x; x=y; y=r; in the function int_elt_val() in src/basemath/base3.c. Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526629: g++-4.4: circular dependency with libstdc++6-4.4-dev
On Sun, May 03, 2009 at 10:50:56PM +0200, Matthias Klose wrote: Bill Allombert schrieb: Given that both package are arch:any, are build from the same source and are required to be always installed together with the exact same version, the split is not particulary useful. So I would suggest to merge libstdc++6-4.4-dev inside g++-4.4 and g++-4.4 could Provides: libstdc++6-4.4-dev to preserve the package name interface. yes, that would be nice. you did forget to attach the patch. Great! Probably the same should be done for gcj-4.4-jdk - libgcj10-dev and gdc-4.1 - libphobos-4.1-dev Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#526629: g++-4.4: circular dependency with libstdc++6-4.4-dev
Package: g++-4.4 Version: 4.4.0-1 Severity: wishlist Hello Debian GCC Maintainers, There is a circular dependency between g++-4.4 and libstdc++6-4.4-dev: g++-4.4 :Depends: libstdc++6-4.4-dev (= 4.4.0-1) libstdc++6-4.4-dev :Depends: g++-4.4 (= 4.4.0-1) Given that both package are arch:any, are build from the same source and are required to be always installed together with the exact same version, the split is not particulary useful. So I would suggest to merge libstdc++6-4.4-dev inside g++-4.4 and g++-4.4 could Provides: libstdc++6-4.4-dev to preserve the package name interface. This would 1) remove the cicular dependency, and 2) reduce the packages count of Debian by one (and reduce the size of the Packages file). Cheers, -- Bill. ballo...@debian.org Imagine a large red swirl here. -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#385327: not fixed in gcc-4.1 4.1.1ds2-17
notfound 385327 4.1.1-20 quit On Fri, Nov 17, 2006 at 01:32:34PM +0100, Roman Zippel wrote: Hi, On Sat, Oct 21, 2006 at 06:19:20AM -0700, Matthias Klose wrote: Source: gcc-4.1 Source-Version: 4.1.1ds2-17 [Roman Zippel] * debian/patches/m68k-secondary-addr-reload.dpatch: Add secondary reloads to allow reload to get byte values into addr regs. Closes: #385327. Unfortunately I have just tried to build yacas again and that fail the same way. I tried both using gcc-4.1 4.1.1-17 (official native build) and 4.1.1-19 (cross-compiler build using official instruction). Please retry with the just released -20, the patch was included but wasn't enabled accidentally in previous versions. I confirm that yacas build fine with -20. Thanks! I have uploaded the resulting yacas packages. If you tell me packages that did not build with -91 but should with -20, I can build them. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#385327: not fixed in gcc-4.1 4.1.1ds2-17
found 385327 4.1.1-19 quit On Sat, Oct 21, 2006 at 06:19:20AM -0700, Matthias Klose wrote: Source: gcc-4.1 Source-Version: 4.1.1ds2-17 [Roman Zippel] * debian/patches/m68k-secondary-addr-reload.dpatch: Add secondary reloads to allow reload to get byte values into addr regs. Closes: #385327. Unfortunately I have just tried to build yacas again and that fail the same way. I tried both using gcc-4.1 4.1.1-17 (official native build) and 4.1.1-19 (cross-compiler build using official instruction). The error message is the same. Here the buildlog anyway. http://people.debian.org/~ballombe/m68k/yacas_1.0.57-2.4_m68k.build Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large blue swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#386864: [m68k] gcc-4.1 -O2 -fomit-frame-pointer generate wrong code
Package: gcc-4.1
Version: 4.1.1-13
Hello Debian GCC maintainers,
On m68k, gcc-4.1 miscompile the function darg in the file
src/basemath/trans2.c of the pari package version 2.3.0-2 when
using the following options:
gcc-4.1 -c -g -O2 -Wall -fomit-frame-pointer -fno-strict-aliasing -I.
-I../src/headers -D_REENTRANT -fPIC -o trans2.o ../src/basemath/trans2.c
It works fine if we remove the -fomit-frame-pointer flag.
The miscompiled function is as follow:
/* arg(s+it) */
double
darg(double s, double t)
{
double x;
if (!t) return (s0)? 0.: PI;
if (!s) return (t0)? PI/2: -PI/2;
x = atan(t/s);
return (s0)? x
: ((t0)? x+PI : x-PI);
}
The program segfault when the function returns.
This happen during the test suite or when entering
psi(1) inside the gp calculator.
The preprocessed file is available at
http://people.debian.org/~ballombe/misc/trans2.i.
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#373098: gcc-2.95: f77 FTBFS on alpha (work-around provided)
Package: gcc-2.95 Version: 2.95.4.ds15-25 Severity: serious Tags: patch Hello GCC maintainers, gcc-2.95 FTBFS on alpha as seen here: http://buildd.debian.org/fetch.php?pkg=gcc-2.95%26ver=2.95.4.ds15-25%26arch=alpha%26stamp=1149582600%26file=log While investigating, I found a simple work-around: simply not building f77 on alpha avoid the problem (I have made a test build on escher). This is not perfect but the alpha porters do not feel the need for gcc-2.95 on alpha anyway. I provide a patch that implement this solution. Thanks for considering, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. diff -u gcc-2.95-2.95.4.ds15/debian/rules.defs gcc-2.95-2.95.4.ds15/debian/rules.defs --- gcc-2.95-2.95.4.ds15/debian/rules.defs +++ gcc-2.95-2.95.4.ds15/debian/rules.defs @@ -138,9 +138,9 @@ endif with_fortran := yes -#ifeq ($(DEB_HOST_ARCH),hurd-i386) -# with_fortran := disabled for architecture $(DEB_HOST_ARCH) -#endif +ifeq ($(DEB_HOST_ARCH),alpha) + with_fortran := disabled for architecture $(DEB_HOST_ARCH) +endif ifeq ($(with_fortran),yes) enabled_languages += f77
Bug#350688: gcc-2.95: FTBFS with new make
On Mon, Jun 05, 2006 at 10:10:51AM +0100, Thiemo Seufer wrote: Bill Allombert wrote: On Sun, Jun 04, 2006 at 04:38:23PM +0200, Matthias Klose wrote: [EMAIL PROTECTED] writes: Hello Matthias, Daniel and Matt Krai provided a patch for this bug. Do you plan to upload this package soon ? In the alternative, would you consider the option of a NMU ? Thanks in advance fro your answer, Please coordinate with Thiemo, he planned an upload this weekend. I see a NMU by Steinar being rejected due to bad versions. So how do we proceed from there ? Who is going to upload a fix ? I'm preparing an upload of -25, sorry for the delay. It seems -25 FTBFS on alpha: http://buildd.debian.org/fetch.php?pkg=gcc-2.95%26ver=2.95.4.ds15-25%26arch=alpha%26stamp=1149582600%26file=log rm -f f771 stage1/xgcc -Bstage1/ -B/usr/alpha-linux-gnu/bin/ -DIN_GCC-g -O2 -W -Wal l -o ../f771 bad.o bit.o bld.o com.o data.o equiv.o expr.o global.o implic.o i nfo.o intrin.o lab.o lex.o malloc.o name.o parse.o proj.o src.o st.o sta.o stb. o stc.o std.o ste.o storag.o stp.o str.o sts.o stt.o stu.o stv.o stw.o symbol.o target.o top.o type.o version.o where.o `cat ../stamp-objlist` `if [ xobstack. o != x ]; then echo ../obstack.o; else true; fi` `case stage1/xgcc -Bstage1/ - B/usr/alpha-linux-gnu/bin/ in cc) if [ x != x ]; then echo ../; else true; f i ;; esac` `if [ x != x ]; then echo ../; else true; fi` ../loop.o: In function `init_loop': /build/buildd/gcc-2.95-2.95.4.ds15/src-native/gcc/loop.c:407: relocation trunca ted to fit: GPREL16 against symbol `word_mode' defined in .scommon section in . ./emit-rtl.o ../loop.o: In function `compute_luids': /build/buildd/gcc-2.95-2.95.4.ds15/src-native/gcc/loop.c:443: relocation trunca ted to fit: GPREL16 against symbol `max_uid_for_loop' defined in .scommon secti on in ../loop.o /build/buildd/gcc-2.95-2.95.4.ds15/src-native/gcc/loop.c:517: additional reloca tion overflows omitted from the output collect2: ld returned 1 exit status make[5]: *** [../f771] Error 1 Any hints ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331150: Bug #331150: [m68k] gcc segfaults with -g -fomit-frame-pointer
On Wed, May 24, 2006 at 02:15:39PM -0500, Stephen R Marenka wrote: On Sat, May 13, 2006 at 11:43:47AM +0200, Bill Allombert wrote: crest% wget http://people.debian.org/~ballombe/misc/kernel.i crest% gcc-4.0 -c -O1 -fomit-frame-pointer -g -o kernel.o kernel.i I just did this with gcc-4.0_4.0.3-3 which is currently sitting in incoming and it completed fine. I also have some evidence that -fomit-frame-pointer produce broken code on m68k, but this bug make them hard to debug. Maybe you can make some progress for us on this now. :) Hello Stephen, I did try gcc-4.1 and it produced correct code under my tests. Given that gcc-4.1 is now the default compiler, are you still interested with problems with gcc-4.0 ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#350688: gcc-2.95: FTBFS with new make
On Sun, Jun 04, 2006 at 04:38:23PM +0200, Matthias Klose wrote: [EMAIL PROTECTED] writes: On Tue, Jan 31, 2006 at 12:03:40PM +0100, Matthias Klose wrote: please send a fix. I do not intend to touch this code. it's fixed in the 3.4, 4.0 and 4.1 packages. Hello Matthias, Daniel and Matt Krai provided a patch for this bug. Do you plan to upload this package soon ? In the alternative, would you consider the option of a NMU ? Thanks in advance fro your answer, Please coordinate with Thiemo, he planned an upload this weekend. I see a NMU by Steinar being rejected due to bad versions. So how do we proceed from there ? Who is going to upload a fix ? Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#331150: Bug #331150: [m68k] gcc segfaults with -g -fomit-frame-pointer
reopen 331150 found 331150 4.0.3-1 quit Hello GCC maintainers, I hit this bug again on crest which is running 4.0.3-1. I retried the test suite I provided and I get the ICE back: crest% wget http://people.debian.org/~ballombe/misc/kernel.i crest% gcc-4.0 -c -O1 -fomit-frame-pointer -g -o kernel.o kernel.i In file included from ../src/headers/pari.h:95, from ../src/kernel/none/level0.c:18: ./pariinl.h: In function 'addllx': ./pariinl.h:70: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://gcc.gnu.org/bugs.html for instructions. For Debian GNU/Linux specific bug reporting instructions, see URL:file:///usr/share/doc/gcc-4.0/README.Bugs. I also have some evidence that -fomit-frame-pointer produce broken code on m68k, but this bug make them hard to debug. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#360895: Bug: #360895 ImportError: libstdc++.so.6: cannot handle TLS data
On Wed, Apr 05, 2006 at 12:32:28PM +0200, Bill Allombert wrote: Package: apt-listchanges Version: 2.59-0.2 Severity: grave apt-listchanges just fails with error message Traceback (most recent call last): File /usr/bin/apt-listchanges, line 30, in ? import apt_pkg ImportError: libstdc++.so.6: cannot handle TLS data which render the package useless. Well, as far as I am concerned this particular problem has disappeared some days ago. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: Bug#332876: weird problem with menu-2.1.26
On Sun, Oct 09, 2005 at 11:58:30AM +0800, bear wrote: Package: menu Version: 2.1.26 Severity: important hi, The update-menu in menu-2.1.26 always outputs the following error: update-menus: relocation error: update-menus: symbol _ZN9__gnu_cxx6__poolILb1EE13_M_initializeEv, version GLIBCXX_3.4.6 not defined in file libstdc++.so.6 with link time reference It seems like the C++ ABI transition problem. But I am not sure. Please help. Thanks! Hello, I cannot reproduce this bug with the exact same version of menu/libstdc++6/libgcc1, so I forward this to the debian-gcc list. If it suddenly disappear from our system after an upgrade please tell me! -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- System Information: Debian Release: testing/unstable APT prefers unstable APT policy: (500, 'unstable') Architecture: i386 (i686) Shell: /bin/sh linked to /bin/bash Kernel: Linux 2.6.12-p4 Locale: LANG=zh_CN.GBK, LC_CTYPE=zh_CN.GBK (charmap=GBK) Versions of packages menu depends on: ii dpkg 1.13.11.0.1 package maintenance system for Deb ii libc62.3.5-6 GNU C Library: Shared libraries an ii libgcc1 1:4.0.2-2 GCC support library ii libstdc++6 4.0.2-2 The GNU Standard C++ Library v3 menu recommends no packages. -- no debconf information -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309210: gcc-4.0 miscompile PARI/GP on x86
On Sun, May 22, 2005 at 07:05:38PM +0200, Falk Hueffner wrote: tags 309210 + moreinfo thanks how can this problem be reproduced? Can you make a stand-alone testcase? So far I have gathered the following info: This bug only affect gcc 4.0 build with configure --host=linux-i486. It no more affect gcc 4.1, and apparently gcc 4.0 build with configure --host=linux-i686 is OK. Apparently this bug occurs only when a single static function is inlined twice. I have also found another instance of (probably) the same bug in another source file that might be easier to investigate. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309210: gcc-4.0 miscompile PARI/GP on x86
tags 309210 - moreinfo thanks On Sun, May 22, 2005 at 07:05:38PM +0200, Falk Hueffner wrote: tags 309210 + moreinfo thanks Hi, how can this problem be reproduced? Easily: 1) download the tarball mentionned in the bug report and untar it 2) do CC=gcc-4.0 ./Configure 3) do make bench One test-case fails (alglin). Alternatively, you can do make gp ./gp matker([1,2;3,4]) *** matker: bug in GP (Segmentation Fault), please report More information about compiler options that fix this problem: http://pari.math.u-bordeaux.fr/archives/pari-dev-0505/msg7.html Can you make a stand-alone testcase? Not at that time, unfortunately. The bug only occurs inside deeply inlined code. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#285238: [arm] gcc-3.3 -O3 -fPIC produce wrong code via auto inlining
On Sun, May 22, 2005 at 09:01:42PM +0200, Matthias Klose wrote: Bill Allombert writes: On Sun, May 22, 2005 at 12:28:21AM +0200, Falk Hueffner wrote: Hi, can you still reproduce this? (Apparently, upstream can't (http://gcc.gnu.org/PR19008).) How about newer gcc? Hello Falk Upstream didn't claim they tried to reproduce the bug, that would involve actually running the code. The status of this bug is not changed: gcc-3.3 (3.3.6-5) is broken, gcc-3.4 (3.4.3-13) work OK and gcc 4.0 and 4.1 are too buggy on x86 to be worth testing on arm. which 4.0 and 4.1 versions did you test? OK, I checked gcc-snapshot on arm (still 4.0.0 20050110-1, unfortunately) and it fix _that_ bug. Sorry I should have tried that sooner, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#285238: [arm] gcc-3.3 -O3 -fPIC produce wrong code via auto inlining
On Sun, May 22, 2005 at 10:47:15PM +0200, Matthias Klose wrote: which 4.0 and 4.1 versions did you test? OK, I checked gcc-snapshot on arm (still 4.0.0 20050110-1, unfortunately) and it fix _that_ bug. Sorry I should have tried that sooner, gcc-4.0 from experimental is a bit newer. Thanks for the tip. So I confirm that gcc 4.0.0 20050326 (4.0-0pre9) does not exhibit this problem on arm. Cheers, Bill. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#309210: gcc-4.0 miscompile PARI/GP on x86
Package: gcc-4.0 Version: 4.0.0-7 Severity: normal Hello Debian GCC maintainers, gcc-4.0 and gcc-snapshot generate wrong code for PARI/GP 2.2.10 on x86. The source code can be found here: http://pari.math.u-bordeaux.fr/pub/pari/unstable/pari-2.2.10.alpha.tar.gz The problem is in the file src/basemath/alglin1.c, function ker0(). The compilation command used was: gcc-4.0 -c -O3 -DGCC_INLINE -Wall -fno-strict-aliasing -fomit-frame-pointer -DBOTH_GNUPLOT_AND_X11 -I. -I../src/headers -o alglin1.o alglin1.i Please find the preprocessed source here: http://people.debian.org/~ballombe/misc/alglin1.i Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Bug#285238: [ARM] gcc-3.3 -O3 -fPIC produce wrong code via auto inlining
On Wed, Dec 15, 2004 at 01:30:05PM +0100, Matthias Klose wrote: Bill Allombert writes: On Sun, Dec 12, 2004 at 05:11:15PM +0100, Matthias Klose wrote: Bill Allombert writes: If you want, I might dig farther into the problem at a later date. OK, I checked with gcc-3.4, and it works fine. I didn't check gcc-4.0 since bug #280972 would cause it to fails anyway. please attach the preprocessed source to the report and recheck with gcc-3.4 and gcc-4.0 / gcc-snapshot. ok, forwarded upstream. Please could you directly reply to the upstream report? See http://gcc.gnu.org/PR19008 How can I do that ? There is no email adress and the webform is subscriber-only. I tried to post the following: I suppose you mean -fno-strict-aliasing, since -fno-strict-alias does not exist. In this case that does not fix the problem. This code work correctly when build with the same compiler on 10 other platforms and AFAIK, casting long* to long does not break strict aliasing rules. but it didn't go through, AFAICS. thanks, I think I just meant to always check newer gcc versions to look for fixes. I usually do that, but only gcc-3.3 was installed on debussy. Then I remembered about the dpkg-deb trick. (By the way, thanks to have made the gcc packages easily relocatable!) Cheers, Bill.
Bug#285238: [ARM] gcc-3.3 -O3 -fPIC produce wrong code via auto inlining
On Sun, Dec 12, 2004 at 05:11:15PM +0100, Matthias Klose wrote: Bill Allombert writes: If you want, I might dig farther into the problem at a later date. OK, I checked with gcc-3.4, and it works fine. I didn't check gcc-4.0 since bug #280972 would cause it to fails anyway. please attach the preprocessed source to the report and recheck with gcc-3.4 and gcc-4.0 / gcc-snapshot. Last time I did that, you told me I 'should know better', whatever that was supposed to mean. Anyway please find here: http://people.debian.org/~ballombe/misc/alglin1.i.gz Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Bug#285238: [ARM] gcc-3.3 -O3 -fPIC produce wrong code via auto inlining
Package: gcc-3.3 Version: 1:3.3.5-3 Severity: normal Hello GCC developers and ARM porters, gcc-3.3 -O3 -fPIC miscompile pari on ARM. (see http://buildd.debian.org/fetch.php?pkg=pariver=2.1.6-1arch=armstamp=1102707589file=logas=raw) More precisely the file src/basemath/alglin1.c is miscompiled with -O3 -fPIC but correctly compiled with -O3 or -O2 -fPIC This is a regression since gcc-3.3_1:3.3.2-0pre5 built the same file correctly with -O3 -fPIC. Apparenlty gcc inline the function use_maximal_pivot() inside gauss_pivot_ker() and produce wrong code there. Removing the static qualifier from use_maximal_pivot() (thus forbidding the compiler to enable) work around the bug. If you want, I might dig farther into the problem at a later date. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Bug#280972: gcc-snapshot generate incorrect code with -O1 and up.
Package: gcc-snapshot
Version: 20041030-1
Severity: normal
Hello Matthias,
gcc-snapshot generate incorrect code for the attached file with
-O1 and above. It is correctly compiled with -O0.
%gcc div.c -O0
%./a.out
1 2 4 8 5 10 20 40 25 50 100 200 125 250 500 1000
%gcc div.c -O1
%./a.out
1 2 5 10 1073835008 -1021043573 1073789904 -1073742211 134518760 1575782908 0 0
1073789904 0 1814429448 0
gcc 3.3 and 3.4 compile it correctly at -O3.
Cheers,
Bill.
-- System Information:
Debian Release: 3.1
APT prefers unstable
APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.4.26-acpi
Locale: LANG=français, LC_CTYPE=français (charmap=ISO-8859-1)
Versions of packages gcc-snapshot depends on:
ii binutils2.15-4 The GNU assembler, linker and bina
ii libart-2.0-22.3.16-6 Library of functions for 2D graphi
ii libatk1.0-0 1.6.1-5 The ATK accessibility toolkit
ii libc6 2.3.2.ds1-18 GNU C Library: Shared libraries an
ii libglib2.0-02.4.7-1 The GLib library of C routines
ii libgtk2.0-0 2.4.13-1 The GTK+ graphical user interface
ii libpango1.0-0 1.4.1-4 Layout and rendering of internatio
ii zlib1g 1:1.2.2-3compression library - runtime
-- no debconf information
#include stdlib.h
#include stdio.h
typedef long *GEN;
GEN stoi(long n)
{
GEN z=(GEN)calloc(3,sizeof(GEN));
z[2]=n;
return z;
}
GEN mulii(GEN x, GEN y) { return stoi(x[2]*y[2]); }
void
divisors_bug(long l, GEN *t, GEN e, GEN P)
{
long i, j;
GEN *d, *t1, *t2, *t3;
d = t;
*++d = stoi(1);
for (i=1; il; i++)
for (t1=t,j=e[i]; j; j--)
{
for (t2=d, t3=t1; t3t2; )
*++d = mulii(*++t3, (GEN)P[i]);
t1=t2;
}
}
int main(void)
{
long e[3]={0,3,3};
long P[3]={0,(long)stoi(2),(long)stoi(5)};
GEN t[17];
long i;
divisors_bug(3,t,e,P);
for(i=1;i17;i++)
printf(%ld ,t[i][2]);
printf(\n);
return 0;
}
Bug#221291: [ia64] `asm' operand requires impossible reload
Package: gcc-3.3
Version: 1:3.3.2ds4-3
Severity: normal
Hello GCC maintainers,
On ia64, gcc fails to compile the following file
(available at
http://people.debian.org/~ballombe/misc/test2.c
)
merulo% gcc test2.c
test2.c: In function `muluu':
test2.c:20: error: `asm' operand requires impossible reload
Compiling with -O, -O1,-O2 or -Os avoid the problem,
as does removing the `register' keyword line 18.
Since the build fail before the assembler is called, the code
in the asm statement is irrelevant, only the constraint are
important.
In fact a asm statement of
__asm__ (: =f (hiremainder) );
or even
__asm__ (: :f (hiremainder) );
would be sufficient to trigger the problem.
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
---test2.c
typedef unsigned long ulong;
typedef long *GEN;
#define mulll(a, b) \
({ \
ulong __arg1 = (a), __arg2 = (b), __value;\
__asm__ (xma.hu %0 = %2, %3, f0\n\t;;\n\txma.l %1 = %2, %3, f0 \
: =f (hiremainder), =f (__value)\
: f (__arg1), f (__arg2)); \
__value; \
})
GEN
muluu(ulong x, ulong y)
{
long p1;
GEN z;
register ulong hiremainder;
p1 = mulll(x,y);
if (hiremainder)
{
z[2]=hiremainder; z[3]=p1; return z;
}
z[2]=p1; return z;
}
Bug#198172: status update on miscompilation at -O2 on arm?
On Fri, Oct 10, 2003 at 09:35:07AM +0200, Matthias Klose wrote: Please could you recheck with current gcc-3.3? gcc-3.4 isn't a choice to test, as it fails to build on arm. I checked with gcc (1:3.3.2ds3-0pre5) on debussy and it appears that all the problems mentioned are solved. With the example test.c earlier in this buglog, now both gcc -O2 and -O3 output the exact same assembly file, but it looks completly normal due to the nature of the code. You can close this bug as far as I am concerned. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Bug#197514: fixed in gcc-defaults 1.8
On Wed, Sep 03, 2003 at 10:12:50PM +0200, Matthias Klose wrote: Bill Allombert writes: Is it really supposed to cure the problem that info gcc show gccint-3.3 instead of gcc-3.3 ? At least it does not on my system. OK, the changelog was not very clear in that regard. it does for me on three systems. what do you in the directory when invoking info without args? What do I what ? The entries are: * gcc-3.2: (gcc-3.2).The GNU Compiler Collection (Version 3.2). * gcc-3.3: (gcc-3.3).The GNU Compiler Collection (Version 3.3). * gccint-3.2: (gccint-3.2). Internals of the GNU Compiler Collection (Version 3.2). * gccint-3.3: (gccint-3.3). Internals of the GNU Compiler Collection If I type 'm gcc' it say [not complete] Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Bug#197514: fixed in gcc-defaults 1.8
On Sun, Aug 10, 2003 at 07:07:00PM -0400, Matthias Klose wrote:
We believe that the bug you reported is fixed in the latest version of
gcc-defaults, which is due to be installed in the Debian FTP archive:
Changes:
gcc-defaults (1.8) unstable; urgency=low
.
* Add sparc-gcc.c wrapper for handling -m32/-m64 defaults. Replaces the
normal gcc symlink (Ben Collins).
* Make 3.3 the default for sparc again.
* Sync epoch for all architectures.
* Provide {cpp,gcc,g77,gpc}-doc dependency packages.
Closes: #178284, #188217, #193409, #197514.
Is it really supposed to cure the problem that
info gcc show gccint-3.3 instead of gcc-3.3 ?
At least it does not on my system.
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
Bug#198172: [arm] gcc-3.3 miscompile pari with -O3
On Wed, Jun 25, 2003 at 09:27:33AM +0100, Philip Blundell wrote: On Thu, 2003-06-19 at 16:26, Bill Allombert wrote: Package: gcc-3.3 Version: 1:3.3-3 Severity: normal Dear GCC maintainers, gcc 3.3 (1:3.3ds9-3) miscompile pari (2.1.5) on arm with -O3, whereas gcc 3.2 (3.2.3 20030331) worked fine. With -O2 gcc 3.3 works fine also The preprocessed miscompiled file is available at http://people.debian.org/~ballombe/misc/init.i.gz Thanks for your report. Can you give any details of the miscompilation? Dear Philip, I perfectly understand that this bug report is not very useful (outside the fact that you can grab PARI source and try to build for yourself), but that let you know gcc has arm specific issue. I also agree that using -O3 is asking for trouble. I believe there are two problems: 1) The file init.c is miscompiled to the point of making gp just crash at start up. It crash so hard that gdb does not provide useful backtrace, so I gave up trying to find why. 2) Other files are miscompiled with -O3 according to 'make bench'. This can be easier to attack. If you want I can try to investigate that, but no promise. Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here.
Bug#198172: [arm] gcc-3.3 miscompile pari with -O3
On Wed, Jun 25, 2003 at 09:27:33AM +0100, Philip Blundell wrote:
On Thu, 2003-06-19 at 16:26, Bill Allombert wrote:
Package: gcc-3.3
Version: 1:3.3-3
Severity: normal
Dear GCC maintainers,
gcc 3.3 (1:3.3ds9-3) miscompile pari (2.1.5) on arm with -O3, whereas
gcc 3.2 (3.2.3 20030331) worked fine.
With -O2 gcc 3.3 works fine also
The preprocessed miscompiled file is available at
http://people.debian.org/~ballombe/misc/init.i.gz
Thanks for your report. Can you give any details of the miscompilation?
Well, it look like return statement are uncorrectly optimised with -O3:
The following file exhibit the problem:
test.c
typedef long *GEN;
#define typ(x) long)(x))1)? 0: (((unsigned long) ((GEN) (x))[0]) 24))
GEN powrealraw(GEN x, long n);
GEN
powraw(GEN x, long n)
{
if (typ(x)==16)
return powrealraw(x,n);
else
return powrealraw(x,n);
}
--
Using a intermediary variable work around the problem:
GEN z=(typ(x)==16)? powrealraw(x,n): powrealraw(x,n);
return z;
Above is the diff of the asm file:
-O2 test2.S
-O3 test.S
--- test2.S 2003-06-25 20:05:52.0 +
+++ test.S 2003-06-25 20:05:41.0 +
@@ -12,8 +12,8 @@
mov r2, r0
mov ip, r1
bne .L2
- ldrbr3, [r0, #3]@ zero_extendqisi2
- cmp r3, #16
+ ldrblr, [r0, #3]@ zero_extendqisi2
+ cmp lr, #16
beq .L4
.L2:
mov r0, r2
Here the supposed buggy test.S:
--test.S-
.file test.c
.text
.align 2
.global powraw
.type powraw, %function
powraw:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
tst r0, #1
@ lr needed for prologue
mov r2, r0
mov ip, r1
bne .L2
ldrblr, [r0, #3]@ zero_extendqisi2
cmp lr, #16
beq .L4
.L2:
mov r0, r2
mov r1, ip
.L4:
b powrealraw
.size powraw, .-powraw
.ident GCC: (GNU) 3.3 (Debian)
--
A wild guess : '@ lr needed for prologue'
mean that lr must not be clobbered but
'ldrb lr, [r0, #3]' clobber it (??)
Cheers,
--
Bill. [EMAIL PROTECTED]
Imagine a large red swirl here.
Bug#198172: [arm] gcc-3.3 miscompile pari with -O3
Package: gcc-3.3 Version: 1:3.3-3 Severity: normal Dear GCC maintainers, gcc 3.3 (1:3.3ds9-3) miscompile pari (2.1.5) on arm with -O3, whereas gcc 3.2 (3.2.3 20030331) worked fine. With -O2 gcc 3.3 works fine also The preprocessed miscompiled file is available at http://people.debian.org/~ballombe/misc/init.i.gz Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux seventeen 2.4.20 #1 Mon Apr 14 16:02:08 CEST 2003 i686 Locale: LANG=français, LC_CTYPE=français Versions of packages gcc-3.3 depends on: ii binutils 2.14.90.0.4-0.1 The GNU assembler, linker and bina ii cpp-3.3 1:3.3-3 The GNU C preprocessor ii gcc-3.3-base 1:3.3-3 The GNU Compiler Collection (base ii libc62.3.1-17GNU C Library: Shared libraries an ii libgcc1 1:3.3-3 GCC support library
Bug#197514: 'info gcc' and 'info cpp' show gccint and cppint instead
Package: gcc-3.3 Version: 1:3.3-3 Severity: normal Dear Debian GCC maintainers, 'info gcc' show gccint-3.3.info instead of gcc-3.3.info, and 'info cpp' show cppinternals-3.2.info instead of cpp-3.2.info, Cheers, -- Bill. [EMAIL PROTECTED] Imagine a large red swirl here. -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux seventeen 2.4.20 #1 Mon Apr 14 16:02:08 CEST 2003 i686 Locale: LANG=français, LC_CTYPE=français Versions of packages gcc-3.3 depends on: ii binutils 2.14.90.0.4-0.1 The GNU assembler, linker and bina ii cpp-3.3 1:3.3-3 The GNU C preprocessor ii gcc-3.3-base 1:3.3-3 The GNU Compiler Collection (base ii libc62.3.1-17GNU C Library: Shared libraries an ii libgcc1 1:3.3-3 GCC support library -- no debconf information
Bug#130394: ARM] gcc misunhandle % with unsigned long operands
On Sun, Jan 27, 2002 at 03:31:35PM +0100, Matthias Klose wrote: tags 130394 + potato I suppose that mean you have tested and it works ? Then see below. please could you recheck with current compilers in testing/unstable? Not until debussy is up again, because I have no account on a arm outside rameau and debussy. Last time I check on debussy in the unstable chroot, gcc2.95 has the bug and gcc3.0 has a similar bug, but much harder to reduce to a small testcase, which occur when doing 'make bench' with PARI/GP. Please note that gcc build as a cross compiler dor arm is believed not to have this bug. Do you know if I can get an account on arm machine running unstable ? Thanks Bill.
Bug#130394: [ARM] gcc misunhandle % with unsigned long operands
Package: gcc
Version: 1:2.95.2-13.1
Severity: normal
Hello,
The following program is miscompiled by gcc on debussy.debian.org :
---
typedef unsigned long ulong;
main()
{
ulong x=3221225472UL;
ulong y=2UL;
printf(x%y=%lu\n,(ulong)(x%y));
}
---
./a.out
x%y=1073741824
instead of
x%y=0
Please read the thread at
http://lists.debian.org/debian-arm/2001/debian-arm-200105/msg00055.html
for more information.
Since the pari-gp package make extensive use of unsigned long ops,
it cause serious runtime bugs.
Thanks for your attention,
Bill. [EMAIL PROTECTED]
-- System Information
(please see debussy.debian.org and rameau.debian.org, they are down currently
so I cant say much. I have previously try to report it in debussy/unstable
chroot but the email never get out of it.)
Bug#111613: acknowledged by developer (no longer reproducible)
Hello, now the SEGV in ld is fixed, but I still get paer% gcc -O3 ~/preproc.c ../src/basemath/arith2.c: In function `compimagraw': ../src/basemath/arith2.c:1219: Internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. If it works for you, please tell me the version of gcc you use and the path so I can try. I need to know if the bug is fixed in the HPPA autobuilder or not. (If it is, I can remove the kludge to compile with -O2 on hppa only). PARI on HPPA has a bug in the timer (time is often 0) , so I will wait to fix it before making a new upload that fix the linking problem. Sorry for the delay I was busy with my PhD thesis. Regards, -- Bill. [EMAIL PROTECTED]
Re: Bug#121282: On i386, gcc-3.0 allows $ in indentifiers but not the asm
On Tue, Nov 27, 2001 at 07:18:43PM -0500, Christopher C. Chimelis wrote:
On Tue, 27 Nov 2001, Daniel Jacobowitz wrote:
I look at this differently; it's our job to be accepting and GCC's job
to be conformant. With Joseph and others actively deprecating
extensions, that seems a better place to take this up.
Agreed. It's worth at least some discussion there before any decisions
are made. For now, I'll agree that other things need to be changed
external to gcc (kernel code and/or Makefiles, etc) before flipping this
option off, so we can just point at any further bug reports and say bad
code, please fix and mark them wishlist until the issue is decided upon
with upstream.
Ok, that makes sense to me then. I guess I'll expect a few gas bugs to be
filed sooner or later about this, but I can live with that :-)
It seems to me gcc output broken asm code, not just that gas does not handle
it correctly.
Here a new file that compiles and links OK but which produce
buggy output:
yellowpig% cat EOF bug2.c
int $b=3;
int b=2;
main()
{
printf(%d\n,$b);
}
EOF
yellowpig% gcc-3.0 bug.c
yellowpig% ./a.out
134518112
The offending asm instruction is of course
movl $b,%eax
This is the same with gcc-2.95.
Also gcc272 is (was?) the prefered compiler for the Linux kernel and, as I
previously reported, Debian gcc272 does not allow dollars in identifiers by
default:
yellowpig% gcc272 bug2.c
bug2.c:1: parse error before `$'
bug2.c: In function `main':
bug2.c:5: parse error before `$'
(Also the NTFS code is not x86 specific, so it must also compile on platforms
where $ are forbidden.)
Cheers,
Bill. [EMAIL PROTECTED]
PS: Sorry to be so lame as to try to compile perl script with gcc:-)
Bug#111613: acknowledged by developer (no longer reproducible)
From: Matthew Wilcox [EMAIL PROTECTED] the example given no longer segfaults on paer.debian.org; i presume an upload since has fixed this bug. I cannot confirm it: paer% gcc -O3 preproc.c ../src/basemath/arith2.c: In function `compimagraw': ../src/basemath/arith2.c:1219: Internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. The file preproc.c is available as paer.debian.org:/home/ballombe/preproc.c with the file in the package itself it is the same: paer% make /usr/bin/gcc -c -O3 -DGCC_INLINE -Wall -Wno-implicit -fomit-frame-pointer -I. -I../src/headers -o arith2.o ../src/basemath/arith2.c ../src/basemath/arith2.c: In function `compimagraw': ../src/basemath/arith2.c:2406: Internal error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. make: *** [arith2.o] Error 1 The current version of my package include of work-around so that it is compiled with -O2 on hppa to avoid the SEGV. It is stated in the Changelog. Unfortunately now it is ld that break. But your fix in #121685 works, thanks! -- Bill. [EMAIL PROTECTED]
Bug#121269: gcc allows dollars in identifiers by default on i386 but fails
Package: gcc
Version: 2:2.95.4-8
Severity: minor
Hello,
gcc by default allows dollars in identifiers on i386.
Unfortunately, the assembler does not like them.
%cat bug.c EOF
int $b;
main()
{
for($b=0;$b10;$b++)
{
printf(%d\n,$b);
}
}
EOF
% gcc bug.c
/tmp/cc2uXoLV.s: Assembler messages:
/tmp/cc2uXoLV.s:16: Error: suffix or operands invalid for `mov'
/tmp/cc2uXoLV.s:19: Error: suffix or operands invalid for `cmp'
/tmp/cc2uXoLV.s:31: Error: suffix or operands invalid for `inc'
This fails with both woody gcc-2.95 and gcc-3.0, and potato gcc.
potato gcc272 reject dollars in identifier by default.
gcc272 -fdollars-in-identifiers fails.
The default for gcc on i386 should be set to reject dollars in identifiers.
Best regards,
-- System Information
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux yellowpig 2.2.19 #1 Tue Apr 24 20:02:21 CEST 2001 i686
Locale: LANG=french, LC_CTYPE=french
Versions of packages gcc depends on:
ii cpp2:2.95.4-8The GNU C preprocessor.
ii cpp-2.95 1:2.95.4-0.011006 The GNU C preprocessor.
ii gcc-2.95 1:2.95.4-0.011006 The GNU C compiler.
--
Bill. [EMAIL PROTECTED]
Re: working around gcc bugs.
On Mon, Sep 17, 2001 at 10:57:16PM +0200, Matthias Klose wrote: What is the best solution ? Build-Depends: gcc-3.0 [arm] use CC=gcc-3.0 for configuring/building on arm. hppa and ia64 don't have gcc-2.95 at all. OK, but default gcc is not gcc-3.0 on merulo (ia64) merulo% gcc -v Reading specs from /usr/lib/gcc-lib/ia64-linux/2.96/specs gcc version 2.96 2731 (Debian GNU/Linux IA64 experimental) (and it produce buggy code) Is it the version used by the autobuilder ? or does it use 3.0 ? Thanks ! Bill.
working around gcc bugs.
Hello, My PARI package has the bad habits of breaking compiler. Worse of all, problems are often run-time and not compile-time. Currently on hppa, arm and ia64 gcc-2.95 cannot build working binaries, but gcc-3.0 work. So should I force the package to be build with gcc-3.0 on these archs ? And in this case, what is the proper way of doing it ? For example,I can use arch-specific build-dependencies and explicitely specify CC=gcc-3.0 for compiling on these archs. What is the best solution ? Thanks in advance, Bill. [EMAIL PROTECTED]
