Hi I’ve been having 2 issues with GCC head on Solaris. Firstly. The build is currently broken
gmake[3]: Leaving directory `/export/home/paulf/scratch/gcc/build' Comparing stages 2 and 3 warning: gcc/cc1obj-checksum.o differs Bootstrap comparison failure! i386-pc-solaris2.11/amd64/libgcc/avx_resms64_s.o differs i386-pc-solaris2.11/amd64/libgcc/sse_resms64_s.o differs i386-pc-solaris2.11/amd64/libgcc/sse_resms64.o differs [more snipped] Is there any workaround for this Secondly I’ve been doing some work on adding support for C++14 and C++17 sized/aligned new and delete operators. Currently Valgrind can’t cope with the .rodata sections that get generated (see bugzilla https://bugs.kde.org/show_bug.cgi?id=390871 <https://bugs.kde.org/show_bug.cgi?id=390871>) Here’s an extract from the report --18142-- WARNING: Serious error when reading debug info --18142-- When reading debug info from /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25: --18142-- Can't make sense of .rodata section mapping The cause appears to be hundreds of Elf32_Shdr (also Elf64_Shdr) with names .rodata and/or .rodata.<subr_name>. Sample: Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al [15] .rodata._ZNKSt10l PROGBITS 00093a88 093a88 000010 01 AMS 0 0 1 [16] .rodata._ZNKSt12_ PROGBITS 00093a98 093a98 000008 01 AMS 0 0 1 [17] .rodata._ZNKSt12_ PROGBITS 00093aa0 093aa0 000007 01 AMS 0 0 1 [18] .rodata PROGBITS 00093ac0 093ac0 003504 00 A 0 0 32 [19] .rodata._ZTSNSt12 PROGBITS 00096fe0 096fe0 00002c 00 A 0 0 32 [20] .rodata._ZTSNSt12 PROGBITS 00097020 097020 00002b 00 A 0 0 32 [21] .rodata._ZNSt6chr PROGBITS 0009704b 09704b 000001 00 A 0 0 1 [22] .rodata._ZNSt6chr PROGBITS 0009704c 09704c 000001 00 A 0 0 1 [23] .rodata._ZNKSt9ba PROGBITS 0009704d 09704d 00000f 01 AMS 0 0 1 [24] .rodata._ZNKSt16b PROGBITS 0009705c 09705c 000016 01 AMS 0 0 1 [25] .rodata._ZNKSt20b PROGBITS 00097072 097072 00001a 01 AMS 0 0 1 [26] .rodata._ZNKSt8ba PROGBITS 0009708c 09708c 00000e 01 AMS 0 0 1 [27] .rodata._ZNKSt10b PROGBITS 0009709a 09709a 000010 01 AMS 0 0 1 [28] .rodata PROGBITS 000970ac 0970ac 0002b4 01 AMS 0 0 4 [29] .rodata._ZNKSt9ex PROGBITS 00097360 097360 00000f 01 AMS 0 0 1 and there are 639 more .rodata* Sections in that one file. Inspection shows that the .rodata* are adjacent after considering alignment. Therefore a workaround might be for the debuginfo reader to aggregate them all into a single internal .rodata section. A simple proposed patch is: https://bugsfiles.kde.org/attachment.cgi?id=110638 <https://bugsfiles.kde.org/attachment.cgi?id=110638> The above patch does fix the problem. Any idea why so many sections are getting generated? (The test case is trivially small) A+ Paul
