[Bug target/71151] New: -fmerge-constants and -fdata-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151
Bug ID: 71151
Summary: -fmerge-constants and -fdata-sections results in
string constants in .progmem.gcc_sw section
Product: gcc
Version: 6.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: senthil.thecoder at gmail dot com
Target Milestone: ---
Using -fdata-sections causes string literals in functions to go into
.progmem.sw_gcc, instead of .rodata.str. This is incorrect, since code using
them expects data memory addresses, not flash.
$ cat printf.c
extern void bar(const char*);
void foo(void)
{
bar("BB");
}
$ avr-gcc -mmcu=atmega32u2 printf.c -S -Os -fdata-sections -ffunction-sections
$ cat printf.s
jaguar:~/scratch$ cat printf.s
.file "printf.c"
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__SREG__ = 0x3f
__tmp_reg__ = 0
__zero_reg__ = 1
.section.progmem.gcc_sw_table.foo.str1.1,"aMS",@progbits,1
.LC0:
.string "BB"
.section.text.foo,"ax",@progbits
.global foo
.type foo, @function
foo:
/* prologue: function */
/* frame size = 0 */
/* stack size = 0 */
.L__stack_usage = 0
ldi r24,lo8(.LC0)
ldi r25,hi8(.LC0)
jmp bar
.size foo, .-foo
.ident "GCC: (GNU) 6.1.0"
As the testcase shows, the string goes into progmem.gcc_sw_table..*,
and this gets placed in flash by the linker script. Reading from the address in
r25:24 will obviously not give the correct results - it will read from whatever
happens to be mapped at the same address in the data address space.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #1 from Senthil Kumar Selvaraj --- A workaround is to disable constant merging (-fno-merge-constants).
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #3 from Senthil Kumar Selvaraj --- Yeah, it's a 6.x thing. There's a commit that changes varasm.c from using targetm.asm_out.mergeable_rodata_prefix to a function call to targetm.asm_out.function_rodata_section hook if the section category is SECCAT_RODATA_MERGE_STR. So avr_asm_function_rodata_section now gets called for string literals inside functions, not just jumptables. I'm trying out a fix that propagates the section category down to the target hook and have the avr backend use it to distinguish between jumptables and other data.
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #7 from Senthil Kumar Selvaraj --- Created attachment 38613 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38613&action=edit Tentative patch for 6.1 Looks like the right fix will need to somehow differentiate between jump tables and other per function data when the function_rodata_section target hook is invoked. I'll submit a tentative patch in the next couple of days that does that. However, I don't think that patch will get into 6.x, given that it changes the target hook interface. The attached patch instead tries to work around the problem, by letting default_elf_select_section run as usual, but then returning a different section with the name reverted to the right prefix (rodata instead of progmem), with the correct flags (MERGE and STRINGS)
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #9 from Senthil Kumar Selvaraj --- For both kinds of invocation (mergeable constants and jump tables), the decl passed is current_function_decl. And that looks right from the documentation for the target hook. I'll submit another patch for trunk that adds a new SECCAT_RODATA_JUMPTABLE to enum section_category, and then passes the section_category down to the target hook. avr_asm_function_rodata_section can then choose to return the correct section based on the category. What do you think?
[Bug target/71151] [avr] -fmerge-constants and -fdata-sections/-ffunction-sections results in string constants in .progmem.gcc_sw section
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71151 --- Comment #12 from Senthil Kumar Selvaraj --- Yes, tiny also has .rodata in .data I'd totally missed PR 63323, so just removing the target hook and turning on JUMP_TABLES_IN_TEXT_SECTION does the trick, like you said. Wrote a basic test to make sure jumptables get generated and used correctly, and that worked too.
[Bug target/110086] New: ICE when optimization level is changed using optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110086
Bug ID: 110086
Summary: ICE when optimization level is changed using optimize
attribute
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: senthil.thecoder at gmail dot com
Target Milestone: ---
Compiler crashes with an ICE for the below code.
Already seen in regression runs (gcc.c-torture/compile/pr104327.c, for e.g.).
$ cat optimize-attrib.c
void __attribute__((optimize("O0"))) foo() {
}
$ avr-gcc -mmcu=avr51 optimize-attrib.c -Os
optimize-attrib.c:1:1: internal compiler error: 'global_options' are modified
in local context
1 | void __attribute__((optimize("O0"))) foo() {
| ^~~~
0xd1288b cl_optimization_compare(gcc_options*, gcc_options*)
/home/toolsbuild/build/gcc/gcc/options-save.cc:13139
0x832d0c handle_optimize_attribute
/home/toolsbuild/code/gcc/gcc/c-family/c-attribs.cc:5689
0x6e8b58 decl_attributes(tree_node**, tree_node*, int, tree_node*)
/home/toolsbuild/code/gcc/gcc/attribs.cc:878
0x70fb4c start_function(c_declspecs*, c_declarator*, tree_node*)
/home/toolsbuild/code/gcc/gcc/c/c-decl.cc:10095
0x78eb0c c_parser_declaration_or_fndef
/home/toolsbuild/code/gcc/gcc/c/c-parser.cc:2742
0x797ec7 c_parser_external_declaration
/home/toolsbuild/code/gcc/gcc/c/c-parser.cc:1925
0x7987bd c_parser_translation_unit
/home/toolsbuild/code/gcc/gcc/c/c-parser.cc:1779
0x7987bd c_parse_file()
/home/toolsbuild/code/gcc/gcc/c/c-parser.cc:24657
0x813840 c_common_parse_file()
/home/toolsbuild/code/gcc/gcc/c-family/c-opts.cc:1248
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[Bug target/110086] ICE when optimization level is changed using optimize attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110086 Senthil Kumar Selvaraj changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #3 from Senthil Kumar Selvaraj --- Fixed on gcc master.
