[Bug libgcc/57085] New: Segmentation Fault when building a c file

[Bug libgcc/57085] New: Segmentation Fault when building a c file

[synergye at codefi dot re]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

             Bug #: 57085
           Summary: Segmentation Fault when building a c file
    Classification: Unclassified
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libgcc
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: synergye@codefi.re


GCC head is at "PR go/57045." I receive the following segmentation fault while
building system/extras of android. The flags gcc was built with are as follows:
--with-float=soft --with-fpu=neon --with-arch=armv7-a --enable-target-optspace
--with-abi=aapcs --disable-libssp --enable-threads --disable-nls
--disable-libmudflap --disable-libgomp --disable-libstdc__-v3
--disable-sjlj-exceptions --disable-shared --disable-tls --disable-libitm
--disable-libquadmath --disable-libatomic.

Here's the error and backtrace:

system/extras/ext4_utils/contents.c:162:1: internal compiler error:
Segmentation fault
 }
0x974095 crash_signal
        ../../../build/../gcc/gcc-4.9/gcc/toplev.c:333
0x8d68ea reload_cse_simplify_operands
        ../../../build/../gcc/gcc-4.9/gcc/postreload.c:655
0x8d6f3c reload_cse_simplify
        ../../../build/../gcc/gcc-4.9/gcc/postreload.c:123
0x8d6f3c reload_cse_regs_1
        ../../../build/../gcc/gcc-4.9/gcc/postreload.c:220
0x8d71a8 reload_cse_regs
        ../../../build/../gcc/gcc-4.9/gcc/postreload.c:75
0x8d71a8 rest_of_handle_postreload
        ../../../build/../gcc/gcc-4.9/gcc/postreload.c:2294
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

The code in contents.c is as follows:
u32 make_directory(u32 dir_inode_num, u32 entries, struct dentry *dentries,
        u32 dirs)
{
        struct ext4_inode *inode;
        u32 blocks;
        u32 len;
        u32 offset = 0;
        u32 inode_num;
        u8 *data;
        unsigned int i;
        struct ext4_dir_entry_2 *dentry;

        blocks = DIV_ROUND_UP(dentry_size(entries, dentries), info.block_size);
        len = blocks * info.block_size;

        if (dir_inode_num) {
                inode_num = allocate_inode(info);
        } else {
                dir_inode_num = EXT4_ROOT_INO;
                inode_num = EXT4_ROOT_INO;
        }

        if (inode_num == EXT4_ALLOCATE_FAILED) {
                error("failed to allocate inode\n");
                return EXT4_ALLOCATE_FAILED;
        }

        add_directory(inode_num);

        inode = get_inode(inode_num);
        if (inode == NULL) {
                error("failed to get inode %u", inode_num);
                return EXT4_ALLOCATE_FAILED;
        }

        data = inode_allocate_data_extents(inode, len, len);
        if (data == NULL) {
                error("failed to allocate %u extents", len);
                return EXT4_ALLOCATE_FAILED;
        }

        inode->i_mode = S_IFDIR;
        inode->i_links_count = dirs + 2;
        inode->i_flags |= aux_info.default_i_flags;

        dentry = NULL;

        dentry = add_dentry(data, &offset, NULL, inode_num, ".", EXT4_FT_DIR);
        if (!dentry) {
                error("failed to add . directory");
                return EXT4_ALLOCATE_FAILED;
        }

        for (i = 0; i < entries; i++) {
                dentry = add_dentry(data, &offset, dentry, 0,
                                dentries[i].filename, dentries[i].file_type);
                if (offset > len || (offset == len && i != entries - 1))
                        critical_error("internal error: dentry for %s ends at
%d, past %d\n",
                                dentries[i].filename, offset, len);
                dentries[i].inode = &dentry->inode;
                if (!dentry) {
                        error("failed to add directory");
                        return EXT4_ALLOCATE_FAILED;
                }
        }

        /* pad the last dentry out to the end of the block */
        dentry->rec_len += len - offset;

        return inode_num;
}

^^^^ The last line is line 162. 
Thank you

[Bug libgcc/57085] Segmentation Fault when building a c file

[synergye at codefi dot re]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #3 from synergye at codefi dot re 2013-04-27 22:54:43 UTC ---
(In reply to comment #1)
> Please attach _preprocessed_ source for the test case, and tell us what options
> gcc was invoked when compiling the test case.

I've added the attachment of the affected code. The cflags used to build it are
as follows: -O3 -march=armv7-a -mtune=cortex-a9 -mfpu=neon -fgcse-after-reload
-fipa-cp-clone -fpredictive-commoning -fsched-spec-load -funswitch-loops
-ftree-loop-distribution -ftree-loop-linear -fvect-cost-model
-fomit-frame-pointer -fstrict-aliasing -Wstrict-aliasing=3
-Werror=strict-aliasing -msoft-float -fpic -ffunction-sections -fdata-sections
-funwind-tables -fstack-protector -Wa,--noexecstack -Werror=format-security
-D_FORTIFY_SOURCE=1 -fno-short-enums -pipe.

This occurs at any optimization level.

[Bug libgcc/57085] Segmentation Fault when building a c file

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #4 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-28 09:11:03 UTC ---
(In reply to comment #2)
> Created attachment 29954 [details]
> Affected code
> 
> Attached is contents.c that I mentioned in the initial post. This is from
> system/extras/ext4_utils/ in jb-mr1.1-release of Android.

That's the original C code, not the _preprocessed_ C code.  It still depends on
numerous headers files to compile.  Please just do

> <your android arm gcc> <your compile options> -E -o contents.i contents.c

and attach contents.i.

[Bug libgcc/57085] Segmentation Fault when building a c file

[ubizjak at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #5 from Uros Bizjak <ubizjak at gmail dot com> 2013-04-28 10:18:03 UTC ---
(In reply to comment #4)

> That's the original C code, not the _preprocessed_ C code.  It still depends on
> numerous headers files to compile.  Please just do
> 
> > <your android arm gcc> <your compile options> -E -o contents.i contents.c
> 
> and attach contents.i.

... or add -save-temps to the complete compilation command, as described in
[1].

[1] http://gcc.gnu.org/bugs/

[Bug libgcc/57085] Segmentation Fault when building a c file

[synergye at codefi dot re]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #6 from synergye at codefi dot re 2013-04-28 10:18:46 UTC ---
Created attachment 29962
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29962
preprocessed code

Attached is the preprocessed code. I apologize about that and it won't happen
again.

[Bug libgcc/57085] Segmentation Fault when building a c file

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #7 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-28 13:41:53 UTC ---
I can't reproduce the ICE with 4.9 r198366 configured as a cross to
armv7l-unknown-linux-gnueabi, on either x86_64-linux or i686-linux, or natively
on armv5tel-unknown-linux-gnueabi with 4.9-20130421 (r198117).

[Bug libgcc/57085] Segmentation Fault when building a c file

[synergye at codefi dot re]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #8 from synergye at codefi dot re 2013-04-28 17:51:03 UTC ---
(In reply to comment #7)
> I can't reproduce the ICE with 4.9 r198366 configured as a cross to
> armv7l-unknown-linux-gnueabi, on either x86_64-linux or i686-linux, or natively
> on armv5tel-unknown-linux-gnueabi with 4.9-20130421 (r198117).

If  this is outside the scope of the site I apologize. Any suggestions for
troubleshooting this bug on my end? I've done a few toolchain builds and always
run into this segfault as do others.

[Bug libgcc/57085] Segmentation Fault when building a c file

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #9 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-28 18:08:02 UTC ---
(In reply to comment #8)
> Any suggestions for
> troubleshooting this bug on my end? I've done a few toolchain builds and always
> run into this segfault as do others.

Tell us more about the host and target system:

1. What's the complete target triplet?
2. What's the host system's triplet?  You only wrote "i686", but the OS part
may be relevant (Linux, *BSD, MacOS, Cygwin, MinGW, ...).
3. Are the gcc sources completely vanilla, or do you have local modifications?

[Bug libgcc/57085] Segmentation Fault when building a c file

[synergye at codefi dot re]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #10 from synergye at codefi dot re 2013-04-28 22:20:42 UTC ---
(In reply to comment #9)
> (In reply to comment #8)
> > Any suggestions for
> > troubleshooting this bug on my end? I've done a few toolchain builds and always
> > run into this segfault as do others.
> 
> Tell us more about the host and target system:
> 
> 1. What's the complete target triplet?
> 2. What's the host system's triplet?  You only wrote "i686", but the OS part
> may be relevant (Linux, *BSD, MacOS, Cygwin, MinGW, ...).
> 3. Are the gcc sources completely vanilla, or do you have local modifications?

(In reply to comment #9)
> (In reply to comment #8)
> > Any suggestions for
> > troubleshooting this bug on my end? I've done a few toolchain builds and always
> > run into this segfault as do others.
> 
> Tell us more about the host and target system:
> 
> 1. What's the complete target triplet?
> 2. What's the host system's triplet?  You only wrote "i686", but the OS part
> may be relevant (Linux, *BSD, MacOS, Cygwin, MinGW, ...).
> 3. Are the gcc sources completely vanilla, or do you have local modifications?
1. The target triplet is arm-linux-androideabi
2. Building with a host triplet of i686-unknown-linux-gnu. Also used
x86_64-unknown-linux-gnu.
3. The gcc sources are entirely vanilla trunk for testing.

[Bug libgcc/57085] Segmentation Fault when building a c file

[mikpe at it dot uu.se]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #11 from Mikael Pettersson <mikpe at it dot uu.se> 2013-04-29 19:30:35 UTC ---
I can't reproduce the ICE with a cross to arm-linux-androideabi either.

[Bug libgcc/57085] Segmentation Fault when building a c file

[synergye at codefi dot re]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

--- Comment #12 from synergye at codefi dot re 2013-04-29 21:13:10 UTC ---
(In reply to comment #11)
> I can't reproduce the ICE with a cross to arm-linux-androideabi either.

Strange. I've had others test and reproduce it as well. This seems to actually
be a trunk regression seeing as it doesn't affect the 4.8 branch at all.

[Bug libgcc/57085] Segmentation Fault when building a c file

[synergye at codefi dot re]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57085

synergye at codefi dot re changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |FIXED

--- Comment #13 from synergye at codefi dot re 2013-05-03 09:23:52 UTC ---
This is now fixed upstream. I don't know what actually fixed it, but syncing
today and doing a fresh toolchain build allowed contents.c to build without an
ICE. Thank you.