[Bug c/54303] New: -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 Bug #: 54303 Summary: -fdata-sections -ffunction-sections and -fmerge-constants do not work well together Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: tom.r...@gmail.com Created attachment 28045 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28045 Testcase for the issue The attached test-case demonstrates the problem I see: $ arm-linux-gnueabi-gcc -Wall -fdata-sections -ffunction-sections -o non-collected-strings.o -c non-collected-strings.c $ arm-linux-gnueabi-gcc -Wl,--gc-sections -o non-collected-strings non-collected-strings.o $ strings non-collected-strings | grep here This string should not be here This string should be here $ arm-linux-gnueabi-nm non-collected-strings| grep me 004004d0 t frame_dummy 004004f2 T keep_me $ arm-linux-gnueabi-nm non-collected-strings.o | grep me T garbage_collect_me T keep_me $ arm-linux-gnueabi-objdump -h non-collected-strings.o | grep str non-collected-strings.o: file format elf32-littlearm 3 .rodata.str1.4 003c 0034 2**2 And all strings in the object file are coalesced into a single section. Note that on x86-64 this works as expected as the last step shows instead: $ objdump -h non-collected-strings.o | grep str non-collected-strings.o: file format elf64-x86-64 3 .rodata.str1.8 001f 0040 2**3 5 .rodata.str1.1 001b 006f 2**0 I've verified this with a few different arm-linux-gnueabi toolchains (ELDK 4.2, ELDK 5.2.1, Linaro (4:4.6.2-7 in Ubuntu) and this seems like a long-standing thing, not Linaro-patch specific.
[Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 Tom Rini changed: What|Removed |Added Target|arm*, x86_64-linux-gnu |arm*-linux-gnu --- Comment #4 from Tom Rini 2012-09-04 20:34:18 UTC --- (In reply to comment #3) > Someone needs to tell the linker to garbage collect sections -Wl, > --gc-sections ? Please re-read the initial post. This works, as expected on x86_64 and does NOT on ARM as on ARM all of the strings are placed into a single .rodata section while on x86_64 they are placed into per-function sections.
[Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 Tom Rini changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | --- Comment #5 from Tom Rini 2012-09-04 20:35:56 UTC --- Putting back as unconfirmed.
[Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 --- Comment #8 from Tom Rini 2012-10-01 18:01:37 UTC --- I could be confused, but how is this a linker issue when gcc puts all of the strings into a single section? To reiterate, if you have N functions each with one string in it, on some platforms (ARM) you get one .rodata.str1.4 section and on others you get N .rodata.str.somethings sections.
[Bug c/80428] Incorrect -Wunused-const-variable= instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80428 Tom Rini changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Tom Rini --- OK, digging into this quite hard I found that indeed, during SPL builds for U-Boot, the code in question (or rather, the functions that use it) are never referenced, but only some times do we generate the warning, and in other times we do not. In all cases (again, for U-Boot) we use -fdata-sections/-ffunction-sections/--gc-sections and discard. In sum, there is a bug here in that the compiler should have been issuing this warning in a lot more cases, but I do not have the time / expertise to generate a stand-alone testcase. As I was reporting this as a warning when it shouldn't warn, but it turns out to be warning when it should be warning (and _not_ warning when it _should_ be warning), I'm movinv this to resolved/invalid.
[Bug other/70268] add option -ffile-prefix-map to map one directory name (old) to another (new) in __FILE__, __BASE_FILE__and __builtin_FILE()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70268 Tom Rini changed: What|Removed |Added CC||tom.rini at gmail dot com --- Comment #8 from Tom Rini --- This would also be useful in cases where we care about the size of our outputs but may have cases where file paths are included (critical debug type messages for example).
[Bug c/80428] New: Incorrect -Wunused-const-variable= instance
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80428 Bug ID: 80428 Summary: Incorrect -Wunused-const-variable= instance Product: gcc Version: 6.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: tom.rini at gmail dot com Target Milestone: --- With U-Boot v2017.05-rc1 and the 'ts4600_config' (make ts4600_config all to reproduce) we see: /home/trini/work/u-boot/u-boot/common/cli_readline.c:20:21: warning: ‘tab_seq’ defined but not used [-Wunused-const-variable=] static const char tab_seq[] = ""; /* used to expand TABs */ ^~~ /home/trini/work/u-boot/u-boot/common/cli_readline.c:19:19: warning: ‘erase_seq’ defined but not used [-Wunused-const-variable=] static const char erase_seq[] = "\b \b"; /* erase sequence */ The code in question is at: http://git.denx.de/?p=u-boot.git;a=blob;f=common/cli_readline.c;h=ecded11ca3985f27b132ef4d20f7e79ee02c8379;hb=11db152246607868f0e74db958947fbf79f28119 If we examine the generated .map file we can see that cli_readline_into_buffer() is kept in the binary as it is used. That in turn makes use of both tab_seq and erase_seq (as well as delete_char() which also uses them).
[Bug c/54303] -fdata-sections -ffunction-sections and -fmerge-constants do not work well together
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54303 --- Comment #11 from Tom Rini --- (In reply to Andrew Pinski from comment #10) > I noticed this also when I was helping out an uboot developer here at Cavium > for Octeon. > > Really I think someone should get LTO working for uboot. Please note that for the record this is not a U-Boot bug but U-Boot showing a compiler bug. And given the nature of the bug, LTO would not help here I suspect as the strings are merged together.
