* GCC 3.3.2 -Wall affects the code generated...
@ 2004-07-01 18:03 Denis Zaitsev
2004-07-06 20:41 ` Jim Wilson
0 siblings, 1 reply; 6+ messages in thread
From: Denis Zaitsev @ 2004-07-01 18:03 UTC (permalink / raw)
To: gcc; +Cc: linux-gcc
The long story is such: I was compiling GLIBC 2.3.2 and there is a
file libio/fileops.c which includes iconv/gconv_charset.h. In this
header an inline function named strip is defined. And I found that
the object code generated for this function depends of the presence of
-Wall in the list of option to GCC. (For some reason, GCC can't
inline this function, so it's compiled as just an outline one.) Is
this a bug in GCC?
Below I include the source code of this strip function and its
assembler generated with and without -Wall. I can say also, that it
seems that this libio/fileops.c file is kinda 'hard to compile'
source: another tho inline functions can't be inlined (and GCC
complains about that), GCC warns that yet another one function
'declared inline after being called', even though it's not true
(AFAIK) and GCC just silently refuse to do some other optimization
during the compilation.
The source code:
static inline void
strip (char *wp, const char *s)
{
int slash_count = 0;
while (*s != '\0')
{
if (__isalnum_l (*s, &_nl_C_locobj)
|| *s == '_' || *s == '-' || *s == '.')
*wp++ = __toupper_l (*s, &_nl_C_locobj);
else if (*s == '/')
{
if (++slash_count == 3)
break;
*wp++ = '/';
}
++s;
}
while (slash_count++ < 2)
*wp++ = '/';
*wp = '\0';
}
The command line:
gcc fileops.c -c -std=gnu99 -D__USE_STRING_INLINES -O2 -Wall -Winline -Wstrict-prototypes -Wwrite-strings -fno-align-functions -fno-align-jumps -fno-align-loops -fno-ident -fno-strength-reduce -mcpu=pentium -mpreferred-stack-boundary=2 -pipe -fPIC -g0 -fomit-frame-pointer -fexceptions -I../include -I. -I/home/src/zzz/lib/glibc/bld/libio -I.. -I../libio -I/home/src/zzz/lib/glibc/bld -I../sysdeps/i386/elf -I../linuxthreads/sysdeps/unix/sysv/linux/i386 -I../linuxthreads/sysdeps/unix/sysv/linux -I../linuxthreads/sysdeps/pthread -I../sysdeps/pthread -I../linuxthreads/sysdeps/unix/sysv -I../linuxthreads/sysdeps/unix -I../linuxthreads/sysdeps/i386/i586 -I../linuxthreads/sysdeps/i386 -I../sysdeps/unix/sysv/linux/i386 -I../sysdeps/unix/sysv/linux -I../sysdeps/gnu -I../sysdeps/unix/common -I../sysdeps/unix/mman -I../sysdeps/unix/inet -I../sysdeps/unix/sysv/i386 -I../sysdeps/unix/sysv -I../sysdeps/unix/i386 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/i386/i586 -I../sysdeps/i386/i486 -I../sysdeps/i386/fpu -I../sysdeps/i386 -I../sysdeps/wordsize-32 -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/ieee754 -I../sysdeps/generic/elf -I../sysdeps/generic -I /lib/modules/2.4.24/build/include -D_LIBC_REENTRANT -include ../include/libc-symbols.h -DPIC -DSHARED -D_IO_MTSAFE_IO -o ...
The assembler (-Wall):
strip:
.LFB113:
pushl %ebp
.LCFI521:
xorl %ebp, %ebp
pushl %edi
.LCFI522:
pushl %esi
.LCFI523:
pushl %ebx
.LCFI524:
pushl %edi
.LCFI525:
call .L796
.L796:
popl %ebx
addl $_GLOBAL_OFFSET_TABLE_+[.-.L796], %ebx
movl 28(%esp), %edi
movl 24(%esp), %esi
movb (%edi), %al
movb %al, 3(%esp)
testb %al, %al
je .L24
.L23:
movsbl 3(%esp),%edx
movl 52+_nl_C_locobj@GOTOFF(%ebx), %eax
testb $8, (%eax,%edx,2)
jne .L13
cmpb $95, 3(%esp)
je .L13
cmpb $45, 3(%esp)
je .L13
cmpb $46, 3(%esp)
je .L13
cmpb $47, 3(%esp)
je .L794
.L20:
incl %edi
movb (%edi), %al
movb %al, 3(%esp)
testb %al, %al
jne .L23
.L24:
movl %ebp, %eax
incl %ebp
decl %eax
jg .L795
movb $47, (%esi)
incl %esi
jmp .L24
.LCFI526:
.L795:
movb $0, (%esi)
popl %esi
.LCFI527:
popl %ebx
.LCFI528:
popl %esi
.LCFI529:
popl %edi
.LCFI530:
popl %ebp
.LCFI531:
ret
.L794:
incl %ebp
cmpl $3, %ebp
je .L24
movb $47, (%esi)
incl %esi
jmp .L20
.L13:
movsbl 3(%esp),%edx
movl 60+_nl_C_locobj@GOTOFF(%ebx), %eax
movl %esi, %ecx
incl %esi
movl (%eax,%edx,4), %eax
movb %al, (%ecx)
jmp .L20
.LFE113:
.size strip, .-strip
.type upstr, @function
The assembler (w/o -Wall):
strip:
.LFB113:
pushl %ebp
.LCFI521:
xorl %ebp, %ebp
pushl %edi
.LCFI522:
pushl %esi
.LCFI523:
pushl %ebx
.LCFI524:
pushl %edi
.LCFI525:
call .L797
.L797:
popl %ebx
addl $_GLOBAL_OFFSET_TABLE_+[.-.L797], %ebx
movl 28(%esp), %edi
movl 24(%esp), %esi
movb (%edi), %al
movb %al, 3(%esp)
testb %al, %al
je .L10
.L23:
movsbl 3(%esp),%edx
movl 52+_nl_C_locobj@GOTOFF(%ebx), %eax
testb $8, (%eax,%edx,2)
jne .L13
cmpb $95, 3(%esp)
je .L13
cmpb $45, 3(%esp)
je .L13
cmpb $46, 3(%esp)
je .L13
cmpb $47, 3(%esp)
je .L796
.L20:
incl %edi
movb (%edi), %al
movb %al, 3(%esp)
testb %al, %al
jne .L23
.L10:
movl %ebp, %eax
incl %ebp
decl %eax
jle .L27
.L795:
movb $0, (%esi)
popl %esi
.LCFI526:
popl %ebx
.LCFI527:
popl %esi
.LCFI528:
popl %edi
.LCFI529:
popl %ebp
.LCFI530:
ret
.L27:
movl %ebp, %eax
movb $47, (%esi)
incl %ebp
incl %esi
decl %eax
jle .L27
jmp .L795
.L796:
incl %ebp
cmpl $3, %ebp
je .L10
movb $47, (%esi)
incl %esi
jmp .L20
.L13:
movsbl 3(%esp),%edx
movl 60+_nl_C_locobj@GOTOFF(%ebx), %eax
movl %esi, %ecx
incl %esi
movl (%eax,%edx,4), %eax
movb %al, (%ecx)
jmp .L20
.LFE113:
.size strip, .-strip
.type upstr, @function
The diff (I omited all the parts that describe only the different
labels):
47,51c47
< jg .L795
< movb $47, (%esi)
< incl %esi
< jmp .L24
< .LCFI526:
---
> jle .L27
65c61,69
< .L794:
---
> .L27:
> movl %ebp, %eax
> movb $47, (%esi)
> incl %ebp
> incl %esi
> decl %eax
> jle .L27
> jmp .L795
> .L796:
^ permalink raw reply [flat|nested] 6+ messages in thread* Re: GCC 3.3.2 -Wall affects the code generated...
2004-07-01 18:03 GCC 3.3.2 -Wall affects the code generated Denis Zaitsev
@ 2004-07-06 20:41 ` Jim Wilson
2004-07-06 21:11 ` John Richard Moser
2004-07-06 22:46 ` Denis Zaitsev
0 siblings, 2 replies; 6+ messages in thread
From: Jim Wilson @ 2004-07-06 20:41 UTC (permalink / raw)
To: Denis Zaitsev; +Cc: linux-gcc, gcc
Denis Zaitsev wrote:
> header an inline function named strip is defined. And I found that
> the object code generated for this function depends of the presence of
> -Wall in the list of option to GCC.
This is probably a bug. This is a small loop that is being complied
differently, so this might be a problem with a loop optimizer, or with
the basic block reorganizer. I'd guess we have an uninitialized
variable, or some other kind of memory corruption somewhere. I don't
know of any other reason why -Wall would effect the code emitted.
We need a testcase to look at this. The source you provided can not be
compiled on its own. I don't happen to have an x86 GLIBC tree, so I can
not easily generate my own testcase. I tried fixing your testcase to
make it compilable, but nothing interesting happens when using
gcc-3.3.4. I suspect that there is a complicated interaction going on
here, and we actually need the full input file to reproduce the problem,
rather than just the source for the one function that changes. Or maybe
the problem has already been fixed. I can't tell.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.3.2 -Wall affects the code generated...
2004-07-06 20:41 ` Jim Wilson
@ 2004-07-06 21:11 ` John Richard Moser
2004-07-06 22:46 ` Denis Zaitsev
1 sibling, 0 replies; 6+ messages in thread
From: John Richard Moser @ 2004-07-06 21:11 UTC (permalink / raw)
To: Jim Wilson; +Cc: Denis Zaitsev, linux-gcc, gcc
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Jim Wilson wrote:
| Denis Zaitsev wrote:
|
| know of any other reason why -Wall would effect the code emitted.
AFFECT
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFA6xWEhDd4aOud5P8RAgDkAJ94vibaOqcTaSaLawg8LfCFBNqSjwCePPuC
iZEYFTr8NWdZ4zHy6AT+djs=
=qTaC
-----END PGP SIGNATURE-----
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.3.2 -Wall affects the code generated...
2004-07-06 20:41 ` Jim Wilson
2004-07-06 21:11 ` John Richard Moser
@ 2004-07-06 22:46 ` Denis Zaitsev
2004-07-07 0:20 ` Jim Wilson
1 sibling, 1 reply; 6+ messages in thread
From: Denis Zaitsev @ 2004-07-06 22:46 UTC (permalink / raw)
To: Jim Wilson; +Cc: linux-gcc, gcc
On Tue, Jul 06, 2004 at 01:41:02PM -0700, Jim Wilson wrote:
> Denis Zaitsev wrote:
> > header an inline function named strip is defined. And I found that
> > the object code generated for this function depends of the presence of
> > -Wall in the list of option to GCC.
>
> This is probably a bug. This is a small loop that is being complied
> differently, so this might be a problem with a loop optimizer, or with
> the basic block reorganizer. I'd guess we have an uninitialized
> variable, or some other kind of memory corruption somewhere. I don't
> know of any other reason why -Wall would effect the code emitted.
>
> We need a testcase to look at this. The source you provided can not be
> compiled on its own. I don't happen to have an x86 GLIBC tree, so I can
> not easily generate my own testcase. I tried fixing your testcase to
> make it compilable, but nothing interesting happens when using
> gcc-3.3.4. I suspect that there is a complicated interaction going on
> here, and we actually need the full input file to reproduce the problem,
> rather than just the source for the one function that changes. Or maybe
> the problem has already been fixed. I can't tell.
I used to assume that everybody has the GLIBC tree. :) So, I can
just sent all the necessary files to you. And I don't think that this
problem is specific for that function, so there is no sence to try to
reproduce the problem upon that function only. I have already told,
it seems that a compilation of that file loads GCC too high, and bugs
are popping up. Compiling that file, GCC just refuse to do some
(other that the inlining) optimization it always does. I can describe
this problem too, should it help.
And I going to compile and install GCC-3.3.4 myself, so I will try to
compile GLIBC with this GCC and will report the result.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.3.2 -Wall affects the code generated...
2004-07-06 22:46 ` Denis Zaitsev
@ 2004-07-07 0:20 ` Jim Wilson
2004-07-07 7:44 ` Denis Zaitsev
0 siblings, 1 reply; 6+ messages in thread
From: Jim Wilson @ 2004-07-07 0:20 UTC (permalink / raw)
To: Denis Zaitsev; +Cc: linux-gcc, gcc
On Tue, 2004-07-06 at 15:46, Denis Zaitsev wrote:
> I used to assume that everybody has the GLIBC tree. :)
I have a glibc src/build tree on my IA-64 machine, but not on my x86
machine. I wasn't sure I'd get the right testcase if I tried to
generate one on a IA-64 machine. It seemed easier to ask you for one.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: GCC 3.3.2 -Wall affects the code generated...
2004-07-07 0:20 ` Jim Wilson
@ 2004-07-07 7:44 ` Denis Zaitsev
0 siblings, 0 replies; 6+ messages in thread
From: Denis Zaitsev @ 2004-07-07 7:44 UTC (permalink / raw)
To: Jim Wilson; +Cc: linux-gcc, gcc
On Tue, Jul 06, 2004 at 05:20:21PM -0700, Jim Wilson wrote:
> On Tue, 2004-07-06 at 15:46, Denis Zaitsev wrote:
> > I used to assume that everybody has the GLIBC tree. :)
>
> I have a glibc src/build tree on my IA-64 machine, but not on my x86
> machine. I wasn't sure I'd get the right testcase if I tried to
> generate one on a IA-64 machine. It seemed easier to ask you for one.
Ok. I understand.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2004-07-07 7:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2004-07-01 18:03 GCC 3.3.2 -Wall affects the code generated Denis Zaitsev
2004-07-06 20:41 ` Jim Wilson
2004-07-06 21:11 ` John Richard Moser
2004-07-06 22:46 ` Denis Zaitsev
2004-07-07 0:20 ` Jim Wilson
2004-07-07 7:44 ` Denis Zaitsev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).