[Bug 618684] Re: ICE when building ziproxy
Bug Watch Updater
618684 at bugs.launchpad.net
Tue Aug 6 11:19:45 UTC 2013
Launchpad has imported 14 comments from the remote bug at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36466.
If you reply to an imported comment from within Launchpad, your comment
will be sent to the remote bug automatically. Read more about
Launchpad's inter-bugtracker facilities at
https://help.launchpad.net/InterBugTracking.
------------------------------------------------------------------------
On 2008-06-08T14:31:05+00:00 Aurelien Jarno wrote:
gcc fails to build the attached testcase with optimization levels above
-O0. The problem occurs with all versions from the gcc 4.x branch.
Versions gcc 3.x do not expose the problem. Note that the ICE occurs on
both old-ABI and EABI.
Using built-in specs.
Target: arm-linux-gnueabi
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.0-5' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --disable-libssp --disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi
Thread model: posix
gcc version 4.3.1 20080523 (prerelease) (Debian 4.3.0-5)
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/0
------------------------------------------------------------------------
On 2008-06-08T14:31:50+00:00 Aurelien Jarno wrote:
Created attachment 15731
reduced testcase
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/1
------------------------------------------------------------------------
On 2009-01-02T11:50:36+00:00 Laurent GUERBY wrote:
Confirmed with gcc-4.3.2-1 Debian gnueabi:
$ gcc -c -O1 pr36466.c
pr36466.c: In function ‘ReadCfgFile’:
pr36466.c:19: internal compiler error: in choose_reload_regs, at reload1.c:6190
And on trunk rev 142984:
pr36466.c: In function 'ReadCfgFile':
pr36466.c:19: internal compiler error: in choose_reload_regs, at reload1.c:6470
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/2
------------------------------------------------------------------------
On 2009-01-02T11:53:40+00:00 Laurent GUERBY wrote:
backtrace on trunk:
(gdb) bt
#0 fancy_abort (file=0x786084 "../../trunk/gcc/reload1.c", line=6470, function=0x785f8c "choose_reload_regs") at ../../trunk/gcc/diagnostic.c:712
#1 0x002ba378 in choose_reload_regs (chain=<value optimized out>) at ../../trunk/gcc/reload1.c:6470
#2 0x002baf08 in reload_as_needed (live_known=<value optimized out>) at ../../trunk/gcc/reload1.c:4240
#3 0x002bf868 in reload (first=<value optimized out>, global=<value optimized out>) at ../../trunk/gcc/reload1.c:1169
#4 0x0068815c in rest_of_handle_ira () at ../../trunk/gcc/ira.c:2018
#5 0x0026ebc8 in execute_one_pass (pass=0x91fa54) at ../../trunk/gcc/passes.c:1279
#6 0x0026ee34 in execute_pass_list (pass=0x91fa54) at ../../trunk/gcc/passes.c:1328
#7 0x0026ee4c in execute_pass_list (pass=0x91a390) at ../../trunk/gcc/passes.c:1329
#8 0x003726f4 in tree_rest_of_compilation (fndecl=0x40232780) at ../../trunk/gcc/tree-optimize.c:419
#9 0x004e92d4 in cgraph_expand_function (node=0x401b0900) at ../../trunk/gcc/cgraphunit.c:1047
#10 0x004eb35c in cgraph_optimize () at ../../trunk/gcc/cgraphunit.c:1106
#11 0x0001cabc in c_write_global_declarations () at ../../trunk/gcc/c-decl.c:8074
#12 0x0031e58c in toplev_main (argc=<value optimized out>, argv=<value optimized out>) at ../../trunk/gcc/toplev.c:981
#13 0x40095dfc in __libc_start_main () from /lib/libc.so.6
#14 0x0000aa7c in _start ()
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/3
------------------------------------------------------------------------
On 2009-08-04T06:52:10+00:00 Nospamnoham wrote:
I see the same problem when I try to compile transmission release 1.73.
The error happens with file libtransmission/fdlimit.c. Works till -O1
but fails with -O2 or -O3. Seeing this error with gcc 4.21.
Transmission was configured with:
./configure --host=arm-none-linux-gnueabi --target=arm-none-linux-gnueabi \
--build=i686-pc-linux \
--disable-gtk --disable-nls \
--prefix=/usr/local \
CFLAGS="-I/home/user/proj/syno-packager/precomp/88f6281/arm-none-linux-gnueabi/include -I/home/user/proj/syno-packager/out/88f6281/temproot/usr/local/include -I/home/user/proj/syno-packager/out/88f6281/root/usr/local/include" LDFLAGS="-L/home/user/proj/syno-packager/precomp/88f6281/arm-none-linux-gnueabi/lib -L/home/user/proj/syno-packager/out/88f6281/temproot/usr/local/lib -L/home/user/proj/syno-packager/out/88f6281/root/usr/local/lib"
Transmission needs openssl and curl to compile. So if you want to
reproduce this issue, you might have to compile them first.
Please email me if you need further data.
Thanks,
SK
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/4
------------------------------------------------------------------------
On 2009-08-04T13:58:58+00:00 Mikpe wrote:
Confirmed with gcc-4.3-20090802, gcc-4.4-20090728, and gcc-4.5-20090730.
Passing -mtune=xscale to gcc prevents the ICE.
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/5
------------------------------------------------------------------------
On 2009-08-04T14:07:34+00:00 Mikpe wrote:
Hang on, the test case looks invalid:
> ReadCfgFile (char *cfg_file)
> {
> void *conf_handler;
> int i;
> struct sockaddr_in nsaddr_list[0];
> char *nserver_str;
> qp_getconf_array_str (conf_handler, "Nameservers", i, &nserver_str, 0);
> (*__res_state ()).nsaddr_list[(*__res_state ()).nscount++] = nsaddr_list[0];
> }
This has a zero-element array as a local variable, which it then fetches
an element from. That's clearly invalid. Changing it as follows
- struct sockaddr_in nsaddr_list[0];
+ struct sockaddr_in nsaddr_list[1];
makes the test case work for me, even without -mtune=xscale.
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/6
------------------------------------------------------------------------
On 2009-08-05T16:42:08+00:00 Ramana-gcc wrote:
Invalid testcase as per comment #6.
(In reply to comment #4)
> I see the same problem when I try to compile transmission release 1.73. The
> error happens with file libtransmission/fdlimit.c. Works till -O1 but fails
> with -O2 or -O3. Seeing this error with gcc 4.21.
>
Please file a separate bug report about this as per
http://gcc.gnu.org/bugs.html if you can reproduce this for trunk or any
of the current release branches.
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/7
------------------------------------------------------------------------
On 2010-08-16T14:21:06+00:00 Loïc Minier wrote:
I'm not sure how the .i ends up with a zero-length array; resolv.h has:
# define MAXNS 3 /* max # name servers we'll track */
[...]
struct __res_state {
[...]
struct sockaddr_in
nsaddr_list[MAXNS]; /* address of name server */
so it should be [3], but it's [0] in the .i file attached here.
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/12
------------------------------------------------------------------------
On 2010-08-16T14:22:00+00:00 Loïc Minier wrote:
Also, even if it's invalid input, I guess gcc should never SEGV, but
rather throw an error out?
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/13
------------------------------------------------------------------------
On 2010-08-16T14:34:29+00:00 Tbm-8 wrote:
Reopening since GCC should not ICE, even if the code is invalid.
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/14
------------------------------------------------------------------------
On 2010-08-16T14:35:03+00:00 Tbm-8 wrote:
Reopening.
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/15
------------------------------------------------------------------------
On 2010-08-16T14:40:16+00:00 Loïc Minier wrote:
Ok, it's [0] because ziproxy uses "nsaddr" as an identifier for a local
variable which conflicts with a compatibility #define in glibc resolv.h.
Renaming to "nsaddress" for instance fixes the build, so clearly bogus
source code.
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/17
------------------------------------------------------------------------
On 2013-08-05T23:04:42+00:00 Rearnsha wrote:
gcc-4.6 seems to compile the code without generating an ICE. However,
versions of gcc older than 4.7 are no-longer being maintained.
Reply at: https://bugs.launchpad.net/gcc-linaro/+bug/618684/comments/23
** Changed in: gcc
Status: Confirmed => Fix Released
--
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to gcc-4.4 in Ubuntu.
https://bugs.launchpad.net/bugs/618684
Title:
ICE when building ziproxy
Status in The GNU Compiler Collection:
Fix Released
Status in Linaro GCC:
Fix Released
Status in “gcc-4.4” package in Ubuntu:
Fix Released
Bug description:
Hi
I've found that Ubuntu builds ziproxy with -O0 on armel to workaround
an ICE in gcc 4.4; see bug #539874.
The ICE should be fixed in any case, and then the ARM-specific
workaround should get reverted.
Debian has a similar issue:
https://buildd.debian.org/fetch.cgi?pkg=ziproxy&arch=armel&ver=3.1.1-1&stamp=1281879748&file=log&as=raw
I didn't try reproducing with latest Linaro GCC 4.4 release, nor with
4.5.
Thanks,
To manage notifications about this bug go to:
https://bugs.launchpad.net/gcc/+bug/618684/+subscriptions
More information about the foundations-bugs
mailing list