$ cat hw.c int main() { printf("hello world\n"); } ryan@ryan:~/gcc/lto/arm-build/gcc$ ./xgcc -B. -flto hw.c hw.c: In function 'main': hw.c:2:3: warning: incompatible implicit declaration of built-in function 'printf' lto1: internal compiler error: in lto_end_uncompression, at lto-compress.c:282 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: ././xgcc returned 1 exit status collect2: lto-wrapper returned 1 exit status ryan@ryan:~/gcc/lto/arm-build/gcc$ ./xgcc -v Using built-in specs. COLLECT_GCC=./xgcc Target: arm-unknown-linux-gnu Configured with: ../configure --target=arm-unknown-linux-gnu --prefix=/home/ryan/cross/arm-unknown-linux-gnu --with-headers=/home/ryan/cross/arm-unknown-linux-gnu/arm-unknown-linux-gnu/include --with-local-prefix=/home/ryan/cross/arm-unknown-linux-gnu/arm-unknown-linux-gnu --disable-nls --enable-threads=posix --enable-symvers=gnu --enable-__cxa_atexit --enable-languages=c,c++ --enable-shared --enable-c99 --enable-long-long --enable-lto Thread model: posix gcc version 4.5.0 20090605 (experimental) (lto merged with rev 148228)
Confirmed in lto revision 149393.
Created attachment 18187 [details] Fixing ICE in lto_end_uncompression, at lto-compress.c I've solved this problem with this patch (lto rev. 148497, ICE in lto-compress.c:281). Try it out, please.
Yes, the patch resolves the ICE.
The patch is not yet in but I think it's the wrong approach. Instead uncompression should deal with tail padding. Maybe the issue is no longer present though - can you possibly re-check?
Problem still happens with gcc version 4.5.0 20090914 (experimental) [lto revision 151753] (lto merged with rev 150842)
Problem still happens with 4.5.0 20090928 (experimental) [lto revision 152240] (lto merged with rev 150842). Without the langhooks.c patch -flto is currently unusable/untestable (ICEs on pretty well everything) for arm-unknown-linux-gnu and sh-unknown-linux-gnu.
(In reply to comment #6) > Problem still happens with 4.5.0 20090928 (experimental) [lto revision 152240] > (lto merged with rev 150842). > > Without the langhooks.c patch -flto is currently unusable/untestable > (ICEs on pretty well everything) for arm-unknown-linux-gnu and > sh-unknown-linux-gnu. Also on alpha-linux-gnu: Target: alphaev68-unknown-linux-gnu Configured with: /home/uros/gcc-svn/branches/lto/configure --enable-lto Thread model: posix gcc version 4.5.0 20090928 (experimental) (lto merged with rev 152236) lto1: internal compiler error: in lto_end_uncompression, at lto-compress.c:281 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. lto-wrapper: /space/uros/gcc-build-lto/gcc/xgcc returned 1 exit status collect2: lto-wrapper returned 1 exit status
And s390(x).
Diego, can't we simply drop the assemble_align call from lhd_begin_section?
Subject: Bug 40392 Author: rguenth Date: Tue Sep 29 12:56:29 2009 New Revision: 152274 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152274 Log: 2009-09-29 Richard Guenther <rguenther@suse.de> PR lto/41467 * lto-symtab.c (lto_symtab_compatible): Fix typos. PR lto/40392 * langhooks.c (lhd_begin_section): Do not align the section. * config/rs6000/rs6000.c (rs6000_output_function_epilogue): Handle LTO. PR lto/40754 * lto-elf.c (init_shdr##BITS): Properly specify alignment in bytes. (first_data_block): New static variable. (lto_elf_append_data): Align the first data block in each section. * lib/torture-options.exp: Do not append an empty option. Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/config/rs6000/rs6000.c branches/lto/gcc/langhooks.c branches/lto/gcc/lto-symtab.c branches/lto/gcc/lto/ChangeLog branches/lto/gcc/lto/lto-elf.c branches/lto/gcc/testsuite/ChangeLog.lto branches/lto/gcc/testsuite/lib/torture-options.exp
Fixed.
(In reply to comment #4) > The patch is not yet in but I think it's the wrong approach. Instead > uncompression should deal with tail padding. I think you're right. I just ran into this bug on cygwin (x86/PE-COFF) because section sizes were being padded to meet the alignment requirements, rather than leaving unallocated gaps between them. A neat solution would be to use pkcs-style self-describing padding at the end of each section: you always add at least one byte of tail padding (even if that means adding a whole alignment-size word), and you put that number of bytes of padding in the final pad byte. It would mean bumping the lto header version and watching out for back-compat of course. Apropos this particular patch, I see you've structured things so that the start of each section is aligned, but the size is one-byte granular. Is this alignment necessary for any reason apart from allowing RISC machines to read the words and half-words in the lto header struct without any worries about misaligned access when using mmap? I think zlib should be pretty easy-going about byte-aligned data streams, so if this is the only reason, it might be easiest for cygwin (since x86 handles misaligned accesses) to just pack all the lto sections with one byte alignment /and/ size granularity, and not worry about the start of each lto data section being aligned or not. So, would it be OK not to align the LTO sections to POINTER_SIZE? Or is there something elsewhere in LTO that requires it?
(In reply to comment #12) > (In reply to comment #4) > > The patch is not yet in but I think it's the wrong approach. Instead > > uncompression should deal with tail padding. > > I think you're right. I just ran into this bug on cygwin (x86/PE-COFF) because > section sizes were being padded to meet the alignment requirements, rather than > leaving unallocated gaps between them. A neat solution would be to use > pkcs-style self-describing padding at the end of each section: you always add > at least one byte of tail padding (even if that means adding a whole > alignment-size word), and you put that number of bytes of padding in the final > pad byte. It would mean bumping the lto header version and watching out for > back-compat of course. Maybe. Or simply store the size of the compressed blob at the beginning? (Not that I have spent too much time with looking how zlib works) > Apropos this particular patch, I see you've structured things so that the start > of each section is aligned, but the size is one-byte granular. Is this > alignment necessary for any reason apart from allowing RISC machines to read > the words and half-words in the lto header struct without any worries about > misaligned access when using mmap? Yes, that was the reason. There was even a bug about this somewhen somewhere ...
(In reply to comment #13) > Maybe. Or simply store the size of the compressed blob at the beginning? Yep, of course. The padding trick is kinda neat because you can do it on the fly at the end of writing the data without having to rewind the file, but they'll both serve the job perfectly well. > (Not that I have spent too much time with looking how zlib works) > > > Apropos this particular patch, I see you've structured things so that the start > > of each section is aligned, but the size is one-byte granular. Is this > > alignment necessary for any reason apart from allowing RISC machines to read > > the words and half-words in the lto header struct without any worries about > > misaligned access when using mmap? > > Yes, that was the reason. That's convenient, as it gives me an option for a more minimal change to the COFF assembler (at least until I want to worry about supporting non-x86 coff platforms, anyway...) > There was even a bug about this somewhen > somewhere ... Ah, ITYM Bug 40754.