Bug 44116 - 64bit inodes for source code causes "Value too large for defined data type" (XFS,inode64)
Summary: 64bit inodes for source code causes "Value too large for defined data type" (...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: other (show other bugs)
Version: 4.4.5
: P3 normal
Target Milestone: 4.6.0
Assignee: Not yet assigned to anyone
URL: http://gcc.gnu.org/ml/gcc-patches/200...
Keywords:
Depends on:
Blocks:
 
Reported: 2010-05-13 14:32 UTC by Tomas Kasparek
Modified: 2016-08-24 05:17 UTC (History)
5 users (show)

See Also:
Host: x86_64-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: x86_64-pc-linux-gnu
Known to work:
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tomas Kasparek 2010-05-13 14:32:39 UTC
On multi-TB storage array with XFS filesystem I have to enable 64bit inodes recently (inode64 mount option). Having test.c with:

int main(void){
  return 0;
}

compiles fine for one file, but if i copy it to another one (several times till it got the right inode number) it produces:

root@matylda1: /mnt/data/kasparek# LC_ALL=C gcc -o test.o test-10356.c
cc1: error: test-10356.c: Value too large for defined data type

The only difference I believe is inode number, definitely not the content of the file:

root@matylda1: /mnt/data/kasparek# stat test.c
  File: `test.c'
  Size: 30              Blocks: 8          IO Block: 4096   regular file
Device: 810h/2064d      Inode: 10853690    Links: 1

root@matylda1: /mnt/data/kasparek# stat test-10356.c
  File: `test-10356.c'
  Size: 30              Blocks: 8          IO Block: 4096   regular file
Device: 810h/2064d      Inode: 15447948189  Links: 1


from strace I found that cc1 is doing fstat64 call on the source code file and then finishes with this message. The first this I need to help with is how to check if the code that causes this (expect somewhere is used 32bit variable to store the inode) is from gcc itself or it is some third-party library. I checked latest version of 4.0, 4.1, 4.2, 4.3, 4.4, 4.5 branches and all behave the same. The system is x86_64 2.6.32.12 kernel on CentOS 5.4. All GCCs are 32bit binaries (with cross compiler for x86_64, mips, arm and alpha having the same behavior).

Thanks in advance.
Comment 1 Alexander Monakov 2010-05-13 14:46:18 UTC
> root@matylda1: /mnt/data/kasparek# LC_ALL=C gcc -o test.o test-10356.c
> cc1: error: test-10356.c: Value too large for defined data type

> The first this I need to help with is how to
> check if the code that causes this (expect somewhere is used 32bit variable to
> store the inode) is from gcc itself or it is some third-party library. I

Execute
gcc -o test.o test-10356.c -### 2>&1 | grep cc1
to get the cc1 command line.  Then use gdb --args <cc1 cmdline> to debug the compiler.  Getting a backtrace before the abort would be nice.
Comment 2 Richard Biener 2010-05-13 15:31:44 UTC
This is know.  GCC does not use LFS and thus fails.  A patch to fix that
was once applied but broke AIX and thus was reverted.
Comment 3 Tomas Kasparek 2010-05-14 06:50:06 UTC
(In reply to comment #1)
> to get the cc1 command line.  Then use gdb --args <cc1 cmdline> to debug the
> compiler.  Getting a backtrace before the abort would be nice.


(gdb) bt
#0  open_file (file=0x8a64148) at /usr/local/lib/gcc/i686-pc-linux-gnu/4.3.4/include-fixed/sys/stat.h:510
#1  0x0866d707 in _cpp_find_file (pfile=0x8a5bb80, fname=0xff8d636f "test-10356.c", start_dir=0x8a5bbf4, fake=0 '\0', angle_brackets=0)
    at ../../libcpp/files.c:378
#2  0x0866e2cc in cpp_read_main_file (pfile=0x8a5bb80, fname=0xff8d636f "test-10356.c") at ../../libcpp/init.c:561
#3  0x080f94a1 in c_common_post_options (pfilename=0x8945fdc) at ../../gcc/c-opts.c:1197
#4  0x08339410 in toplev_main (argc=11, argv=0xff8d4874) at ../../gcc/toplev.c:1810
#5  0x08118cb2 in main (argc=Cannot access memory at address 0x100
) at ../../gcc/main.c:35


I belive the problematic stat is gcc/files.c:232 (gcc-4.5.0). Would it be possible to add config option to enable LFS that may be disabled by default?
Comment 4 Tomas Kasparek 2010-06-08 10:34:32 UTC
Hello, is there any progress in this, may I help with something?
Comment 5 Sebastian Andrzej Siewior 2013-02-07 21:17:46 UTC
I run into this myself today with an older compiler. This has been fixed in svn commit 166230. The fix is part of gcc-4.6.0+ and it does not look like it has been backported.
It can be closed now :)
Comment 6 Andrew Pinski 2013-02-07 21:23:22 UTC
Fixed so closing; 4.6.
Comment 7 Andrew Pinski 2013-02-07 21:31:13 UTC
Fixed so closing; 4.6.x and above is only supported for fixing bugs now.