[Bug other/89347] gc-sections doesn't remove unused bss section variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |10.0 Status|UNCONFIRMED |RESOLVED --- Comment #5 from Andrew Pinski --- -fno-common is default since r10-4867. So closing as fixed.
[Bug other/89347] gc-sections doesn't remove unused bss section variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347 Maninder Singh changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #4 from Maninder Singh --- But its not mentioned in gc-section or data-section manual pages, either that needs updation or it need to be handled by -fdata-section flag only.
[Bug other/89347] gc-sections doesn't remove unused bss section variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347 --- Comment #3 from Maninder Singh --- But its not mentioned in gc-section or data-section manual pages, either that needs updation or it need to be handled by -fdata-section flag only. https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Optimize-Options.html#Optimize-Options -ffunction-sections -fdata-sections Place each function or data item into its own section in the output file if the target supports arbitrary sections. The name of the function or the name of the data item determines the section’s name in the output file. Use these options on systems where the linker can perform optimizations to improve locality of reference in the instruction space. Most systems using the ELF object format have linkers with such optimizations. On AIX, the linker rearranges sections (CSECTs) based on the call graph. The performance impact varies. Together with a linker garbage collection (linker --gc-sections option) these options may lead to smaller statically-linked executables (after stripping). On ELF/DWARF systems these options do not degenerate the quality of the debug information. There could be issues with other object files/debug info formats. Only use these options when there are significant benefits from doing so. When you specify these options, the assembler and linker create larger object and executable files and are also slower. These options affect code generation. They prevent optimizations by the compiler and assembler using relative locations inside a translation unit since the locations are unknown until link time. An example of such an optimization is relaxing calls to short call instructions.
[Bug other/89347] gc-sections doesn't remove unused bss section variables.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89347 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c |other Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- You need -fno-common instead: https://gcc.gnu.org/onlinedocs/gcc-8.2.0/gcc/Code-Gen-Options.html#index-fno-common -fno-common In C code, this option controls the placement of global variables defined without an initializer, known as tentative definitions in the C standard. Tentative definitions are distinct from declarations of a variable with the extern keyword, which do not allocate storage. Unix C compilers have traditionally allocated storage for uninitialized global variables in a common block. This allows the linker to resolve all tentative definitions of the same variable in different compilation units to the same object, or to a non-tentative definition. This is the behavior specified by -fcommon, and is the default for GCC on most targets. On the other hand, this behavior is not required by ISO C, and on some targets may carry a speed or code size penalty on variable references. The -fno-common option specifies that the compiler should instead place uninitialized global variables in the data section of the object file. This inhibits the merging of tentative definitions by the linker so you get a multiple-definition error if the same variable is defined in more than one compilation unit. Compiling with -fno-common is useful on targets for which it provides better performance, or if you wish to verify that the program will work on other systems that always treat uninitialized variable definitions this way.
