Miscompilation with "-fpeel-loops" and -O{2,3,s}

[Marcin Mirosław]

W dniu 22.10.2013 15:44, Michael Tokarev pisze:
> 22.10.2013 14:11, Marcin Mirosław wrote:
>> Hi!
>> I'm not sure if it's problem inside udns or inside gcc. I'm starting to
>> ask here about it, if it's not problem in udns I'll look for help on gcc
>> mailing list.
>> I've noticed that compiling udns-0.2 using "-fpeel-loops" optimalization
>> (togoether with -O2, -O3 or -Os) build executable which doesn't works
>> correctly.
>> Without -fpeel-loops:
>> $ ./rblcheck -s rbl.mejor.pl 88.198.102.195 ; echo  $?
>> 88.198.102.195 is listed by rbl.mejor.pl: 127.0.1.1
>> 100
>>
>> with -fpeel-loops:
>> $ ./rblcheck -s rbl.mejor.pl 88.198.102.195 ; echo $?
>> 0
> 
> Wow.
> 
> I tried to reproduce, but my gcc (debian 4.7.2) produces a working
> binary when compiled with -fpeel-loops -O2.

Hi Michael!
Could you please retest with -O3 and -Os?
I did some further tests:
	gcc-4.5.4	gcc-4.6.4	gcc-4.7.3	gcc-4.8.1
-O2	OK		OK		BAD		BAD
-O3	BAD		OK		BAD		BAD
-Os	BAD		OK		BAD		BAD



>> I also suspect problem appears while ocmpiling udns_resolver.c, I did
>> some tests, when udns_resolver.o was compiled with -fpeel-loops then
>> after linking libudns didn't work correctly.
> 
> Yes, it looks like the prob is with compiling udns_resolver.c (which is
> the main source file anyway).
> 
>> I have no more skills to find out where is problem (gcc or udns). I
>> prepared static clang analyse of udns[1], clang states there could be
>> "use-after-free" error in udns_resolver.c, can it be related to mine
>> problem?
> 
> No, all these clang warnings are bogus except of one - in ex-rdns.c there's
> a useless assignment to `c' variable.  There's no use-after-free in the
> place clang thinks there is (unless I don't understand C).  And even if
> it were were, we're not hitting it -- it can be "triggered" (at least
> how clang "thinks") at the cleanup path when stuff gets cleared after
> everything has been done (it is in udns_close() function, which isn't
> even called by rblcheck).

Thanks for information.

> So I don't quite sure what to do here.  And I haven't seen this
> -fpeel-loops
> flag, have no idea what it does (will read).
> 
> At least, can you specify gcc version which you used which produces bad
> results, and the architecture (if it is x86, please specify whenever it
> is 32 or 64bits).


I'm on amd64 arch, Gentoo OS:
# gcc -v
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with:
/var/tmp/portage/sys-devel/gcc-4.8.1-r1/work/gcc-4.8.1/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.8.1
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.1/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --with-cloog --disable-isl-version-check
--enable-lto --enable-nls --without-included-gettext --with-system-zlib
--enable-obsolete --disable-werror --enable-secureplt --enable-multilib
--with-multilib-list=m32,m64 --enable-libmudflap --disable-libssp
--enable-libgomp
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.8.1/python
--enable-checking=release --disable-libgcj --enable-libstdcxx-time
--enable-languages=c,c++,objc,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
--enable-targets=all --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.8.1-r1 p1.2, pie-0.5.7'
Thread model: posix
gcc version 4.8.1 (Gentoo 4.8.1-r1 p1.2, pie-0.5.7)

Thank you,
Marcin