Attached is locale-inst.ii for gcc-4_3-branch revision 143448. The assembler says, during build: locale-inst.s: Assembler messages: locale-inst.s:192360: Error: bignum invalid The line, with context, is (with -dA -mpdebug for improved clarity, but causing the line number to change to 203626): 203615 .dword 0x1fd ;# DW_AT_type 203616 .byte 0x1 ;# DW_AT_external 203617 .byte 0x1 ;# DW_AT_declaration 203618 .uleb128 0xb6 ;# (DIE (0x227ba) DW_TAG_variable) 203619 .dword .LASF1471 ;# DW_AT_name: "__min" 203620 .byte 0x36 ;# DW_AT_decl_file (/tmp/hptest/v32l/gccobj/crisv32-axis-linux-gnu/libstdc++-v3/include/ 203620 ext/numeric_traits.h) 203621 .byte 0x3e ;# DW_AT_decl_line 203622 .dword .LASF1591 ;# DW_AT_MIPS_linkage_name: "_ZN9__gnu_cxx24__numeric_traits_integerIxE5__minE" 203623 .dword 0x839f ;# DW_AT_type 203624 .byte 0x1 ;# DW_AT_external 203625 .byte 0x1 ;# DW_AT_declaration 203626 .sleb128 -9223372036854775808 ;# DW_AT_const_value 203627 .uleb128 0xba ;# (DIE (0x227d6) DW_TAG_variable) 203628 .dword .LASF1472 ;# DW_AT_name: "__max" 203629 .byte 0x36 ;# DW_AT_decl_file (/tmp/hptest/v32l/gccobj/crisv32-axis-linux-gnu/libstdc++-v3/include/ 203629 ext/numeric_traits.h) 203630 .byte 0x3f ;# DW_AT_decl_line 203631 .dword .LASF1592 ;# DW_AT_MIPS_linkage_name: "_ZN9__gnu_cxx24__numeric_traits_integerIxE5__maxE" 203632 .dword 0x839f ;# DW_AT_type 203633 .byte 0x1 ;# DW_AT_external 203634 .byte 0x1 ;# DW_AT_declaration 203635 .quad 0x7fffffffffffffff ;# DW_AT_const_value 203636 .uleb128 0x4f ;# (DIE (0x227f0) DW_TAG_variable) 203637 .dword .LASF1561 ;# DW_AT_name: "__is_signed" The number -9223372036854775808 is also known as 0x8000000000000000. I've been able to build for this target on the gcc-4.3 branch before.
Created attachment 17128 [details] as mentioned Use cc1plus -fpreprocessed locale-inst.ii -march=v32 -quiet -dumpbase locale-inst.cc -dA -mpdebug -auxbase-strip .libs/locale-inst.o -g -O2 -Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -fPIC -o locale-inst.s
Configured with /tmp/hptest/v32l/gcc/configure --prefix=/n/common_data/comptools/cris-1.64-64 --target=crisv32-axis-linux-gnu --with-gnu-ld --with-gnu-as --enable-checking
Um, ok, it's __gnu_cxx::__numeric_traits_integer<long long>::__min so the number as such is most likely valid. :) Not sure if that number is supposed to be valid as a .sleb128 operand though. I'd better assign this to myself and check.
Trunk binutils accepts it but produces junk: Contents of section .text: 0000 80808080 80808080 807f0000 ............
(In reply to comment #4) > 0000 80808080 80808080 807f0000 ............ Silly me, that's the right sleb128 encoding, IIUC. Doh.
(In reply to comment #3) > I'd better assign this to myself and check. FWIW, the assembler that complained was an old 2.12.something. There's a gcc sleb128 configure check, but it doesn't check for large numbers.
So... fixing the sleb128 configure test (to check that this number is parsed and handled correctly) is fairly simple, but should perhaps only be done for targets that actually will use 64-bit numbers. If someone wants to take this and run with it, fine by me. Unassigning, for now.
GCC 4.3.4 is being released, adjusting target milestone.
GCC 4.3.5 is being released, adjusting target milestone.
Binutils bug.
Recategorizing, if only just for the record.