[Bug target/67839] Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 --- Comment #5 from Senthil Kumar Selvaraj --- The patch did not make it to the 5 branch, my fault really - guess I forgot to submit it for backporting. Not sure how you get that code though - I pulled the latest gcc-5_branch (svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-5-branch@232962), built it with main.c from PR 69330, and this is what I got cbi 0x20,0 ldi r24,0 ldi r25,0 ret .size main, .-main .ident "GCC: (GNU) 5.3.1 20160129" The problem shows up only when define_special_predicate is used - 4.9 and below only used define_predicate. Like I said in the first comment, I don't know wny that was changed. The change of constraint from n to i, IIRC, was to defer address computation for IO instructions to link time, so that that io and io_low attributes work (https://gcc.gnu.org/onlinedocs/gcc/AVR-Variable-Attributes.html)
[Bug bootstrap/67373] Can't compile gcc snapshot for avr target with mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67373 --- Comment #5 from Senthil Kumar Selvaraj --- The last released version of avr-libc (1.8.1) doesn't properly work with the spec file based device support approach introduced in 5.x. As the GCC 5 release notes (https://gcc.gnu.org/gcc-5/changes.html) describes The AVR port uses a new scheme to describe supported devices: For each supported device the compiler provides a device-specific spec file. If the compiler is used together with AVR-LibC, this requires at least GCC 5.2 and a version of AVR-LibC which implements feature #44574. Can you try building with the trunk version of avr-libc? That should work fine.
[Bug target/67839] Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 --- Comment #1 from Senthil Kumar Selvaraj --- Created attachment 36444 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36444=edit Test case Compile with avr-gcc test.c -Os
[Bug target/67839] New: Bit addressable instructions generated for invalid memory address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67839 Bug ID: 67839 Summary: Bit addressable instructions generated for invalid memory address Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: senthil_kumar.selvaraj at atmel dot com Target Milestone: --- Bit addressable instructions (sbi, cbi, sbis, sbic) only work on IO addresses 0x0-0x1f (inclusive). The compiler generates these instructions for IO address 0x20 as well. The problem is in the specification of low_io_address_operand predicate, which has (define_special_predicate "low_io_address_operand" (ior (and (match_code "const_int") (match_test "IN_RANGE (INTVAL (op) - avr_arch->sfr_offset, 0, 0x20 - GET_MODE_SIZE (mode))")) (and (match_code "symbol_ref") (match_test "SYMBOL_REF_FLAGS (op) & SYMBOL_FLAG_IO_LOW" While this looks ok, gcc invokes low_io_address_operand with mode set to VOID, and GET_MODE_SIZE for VOID returns 0, so the effective range becomes 0x0-0x20. gcc does pass the correct mode if the operand mode is set in the define_insn that uses this predicate. Don't know why it isn't set, and why define_special_predicate is used instead of define_predicate. Note that io_address_operand predicate has a GET_MODE_SIZE call as well, so the range check is off by one in it too
[Bug target/67031] avr-gcc internal compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67031 Senthil Kumar Selvaraj changed: What|Removed |Added CC||senthil_kumar.selvaraj@atme ||l.com --- Comment #1 from Senthil Kumar Selvaraj --- Confirmed on gcc 5.2
[Bug bootstrap/67373] Can't compile gcc snapshot for avr target with mingw
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67373 Senthil Kumar Selvaraj changed: What|Removed |Added CC||senthil_kumar.selvaraj@atme ||l.com --- Comment #1 from Senthil Kumar Selvaraj --- Looks like the build couldn't find an avr assembler that runs on the build machine. Building binutils with host=mingw creates an assembler that can only run on Windows. Can you try building binutils without setting host=mingw, add that to the PATH and then try building again?
[Bug target/66201] New: [avr] ICE in avr_print_operand: Bad address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66201
Bug ID: 66201
Summary: [avr] ICE in avr_print_operand: Bad address
Product: gcc
Version: 6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: senthil_kumar.selvaraj at atmel dot com
CC: gjl at gcc dot gnu.org
Target Milestone: ---
Target: avr
gcc.dg/pr57134.c fails for attiny40 (and for atmega1280 with -ffixed-30) with a
bad address ICE in avr_print_operand (see stack trace below).
avr_print_operand generates the ICE if the base register is X and the RTX code
is PLUS. The testcase uses inline assembly, like so
static __inline__ __attribute__((always_inline)) int64_t
atomic64_read(const atomic64_t *v)
{
int64_t t;
__asm__ __volatile__(# %0, %1 : =r(t) : m(v-counter));
return t;
}
and the RTX looks like this
(insn 16 42 43 2 (set (reg:DI 20 r20)
(asm_operands/v:DI (# %0, %1) (=r) 0 [
(mem:DI (plus:HI (reg:HI 26 r26)
(const_int 4 [0x4])) [1 MEM[(const struct atomic64_t
*)_5].counter+0 S8 A32])
]
[
(asm_input:DI (m)
/home/saaadhu/code/git/gcc/gcc/testsuite/gcc.dg/pr57134.c:21)
]
[] /home/saaadhu/code/git/gcc/gcc/testsuite/gcc.dg/pr57134.c:21))
/home/saaadhu/code/git/gcc/gcc/testsuite/gcc.dg/pr57134.c:21 -1
(nil))
Even worse, AVR_TINY does not have LDD/STD at all.
Could this be be because avr_legitimate_address_p returns ok even for such
RTXes? Perhaps it should reject MEM RTXes with base + offset for AVR_TINY, and
those with base reg as X for others?
#1 0x0104065a in avr_print_operand (file=0x1976ab0, x=0x76a023c0,
code=0) at /home/saaadhu/code/git/gcc/gcc/config/avr/avr.c:2412
#2 0x0092c3d0 in output_operand (x=0x76a023c0, code=0) at
/home/saaadhu/code/git/gcc/gcc/final.c:3881
#3 0x0092c034 in output_asm_insn (templ=0x769f0700 # %0, %1,
operands=0x7fffdf10) at /home/saaadhu/code/git/gcc/gcc/final.c:3797
#4 0x00929cc0 in final_scan_insn (insn=0x769f75c0, file=0x1976ab0,
optimize_p=2, nopeepholes=0, seen=0x7fffe194) at
/home/saaadhu/code/git/gcc/gcc/final.c:2665
#5 0x009287cb in final (first=0x769ed578, file=0x1976ab0,
optimize_p=2) at /home/saaadhu/code/git/gcc/gcc/final.c:2086
#6 0x0092d54e in rest_of_handle_final () at
/home/saaadhu/code/git/gcc/gcc/final.c:4479
#7 0x0092d821 in (anonymous namespace)::pass_final::execute
(this=0x199be90) at /home/saaadhu/code/git/gcc/gcc/final.c:4554
#8 0x00c16b79 in execute_one_pass (pass=0x199be90) at
/home/saaadhu/code/git/gcc/gcc/passes.c:2317
#9 0x00c16dc3 in execute_pass_list_1 (pass=0x199be90) at
/home/saaadhu/code/git/gcc/gcc/passes.c:2370
#10 0x00c16df4 in execute_pass_list_1 (pass=0x199ba10) at
/home/saaadhu/code/git/gcc/gcc/passes.c:2371
#11 0x00c16df4 in execute_pass_list_1 (pass=0x1999f70) at
/home/saaadhu/code/git/gcc/gcc/passes.c:2371
#12 0x00c16e31 in execute_pass_list (fn=0x769f5888, pass=0x1996d90)
at /home/saaadhu/code/git/gcc/gcc/passes.c:2381
#13 0x0082ca10 in cgraph_node::expand (this=0x768d6900) at
/home/saaadhu/code/git/gcc/gcc/cgraphunit.c:1895
#14 0x0082d044 in expand_all_functions () at
/home/saaadhu/code/git/gcc/gcc/cgraphunit.c:2031
#15 0x0082db5c in symbol_table::compile (this=0x768d8000) at
/home/saaadhu/code/git/gcc/gcc/cgraphunit.c:2384
#16 0x0082dd08 in symbol_table::finalize_compilation_unit
(this=0x768d8000) at /home/saaadhu/code/git/gcc/gcc/cgraphunit.c:2461
#17 0x0068729f in c_write_global_declarations () at
/home/saaadhu/code/git/gcc/gcc/c/c-decl.c:10828
#18 0x00ccfab2 in compile_file () at
/home/saaadhu/code/git/gcc/gcc/toplev.c:611
#19 0x00cd1e13 in do_compile () at
/home/saaadhu/code/git/gcc/gcc/toplev.c:2079
#20 0x00cd2061 in toplev::main (this=0x7fffe4b0, argc=26,
argv=0x7fffe5b8) at /home/saaadhu/code/git/gcc/gcc/toplev.c:2180
#21 0x0124fb7e in main (argc=26, argv=0x7fffe5b8) at
/home/saaadhu/code/git/gcc/gcc/main.c:39
[Bug target/65657] [avr] read from __memx address space tramples argument to following function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65657 --- Comment #5 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- This tentative patch (pending regression tests) makes the problem go away diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c index 68d5ddc..46ff7e1 100644 --- gcc/config/avr/avr.c +++ gcc/config/avr/avr.c @@ -9959,7 +9959,11 @@ avr_rtx_costs_1 (rtx x, int codearg, int outer_code ATTRIBUTE_UNUSED, return true; case MEM: - *total = COSTS_N_INSNS (GET_MODE_SIZE (mode)); + /* MEM rtx with non-default address space is more + expensive. Not expressing that results in reg + clobber during expand (PR 65657). */ + *total = COSTS_N_INSNS (GET_MODE_SIZE (mode) + + (MEM_ADDR_SPACE(x) == ADDR_SPACE_RAM ? 0 : 5)); return true; case NEG: Function call arguments are expanded right to left, which means that when expanding the call to foo, R22:R23 is set to 0xABCD first up, and then the expansion of *x clobbers R22 when movmode calls gen_xloadmode_A. Call expansion does not appear to take the clobber (reg:MOVMODE 22) into account - when it checks for argument overlap, the RTL (args[i].value) is only a MEM in QImode - the clobber shows up when it eventually calls emit_move_insn. This does not happen if x is a int pointer (rather than char) - turns out that precompute_register_parameters does a copy_to_mode_reg if the cost of args[i].value is more than COSTS_N_INSNS(1) i.e., it creates a pseudo and later assigns the pseudo to the arg register. Doing the same thing - providing a better cost estimate for a MEM rtx in the non-default address space, makes this problem go away.
[Bug target/65657] [avr] read from __memx address space tramples argument to following function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65657 --- Comment #4 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- Doesn't appear to be a missed clobber in the md file, as *.expand shows in insn 7 - r22 is in the clobbered registers list. Later passes assume r22 is unused after insn 6 (reg:R22 QI is marked as REG_UNUSED), and proceed to set r22 instead of r24 in insn 7. (note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK) (insn 2 4 3 2 (set (reg/v/f:PSI 43 [ x ]) (reg:PSI 22 r22 [ x ])) foo.c:3 -1 (nil)) (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG) (insn 6 3 7 2 (set (reg:HI 22 r22) (const_int -21555 [0xabcd])) foo.c:4 -1 (nil)) (insn 7 6 8 2 (parallel [ (set (reg:QI 24 r24) (mem:QI (reg/v/f:PSI 43 [ x ]) [0 *x_2(D)+0 S1 A8 AS7])) (clobber (reg:QI 22 r22)) (clobber (reg:QI 21 r21)) (clobber (reg:HI 30 r30)) ]) foo.c:4 -1 (nil)) (call_insn/j 8 7 9 2 (parallel [ (call (mem:HI (symbol_ref:HI (foo) [flags 0x41] function_decl 0x7f635059f360 foo) [0 foo S2 A8]) (const_int 0 [0])) (use (const_int 1 [0x1])) ]) foo.c:4 -1 (expr_list:REG_CALL_DECL (symbol_ref:HI (foo) [flags 0x41] function_decl 0x7f635059f360 foo) (nil)) (expr_list:QI (use (reg:QI 24 r24)) (expr_list:HI (use (reg:HI 22 r22)) (nil (barrier 9 8 0)
[Bug target/65657] [avr] read from __memx address space tramples argument to following function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65657
Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com changed:
What|Removed |Added
CC||senthil_kumar.selvaraj@atme
||l.com
--- Comment #3 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot
com ---
Happens on a recent trunk build as well.
Here's a simpler testcase.
$ cat foo.c
void foo (char a, unsigned int b);
void readx (const char __memx *x)
{
foo (*x, 0xABCD);
}
$ avr-gcc -mmcu=atmega1280 foo.c -S -Os
$ cat foo.s
snip
mov r18,r22
mov r25,r23
ldi r22,lo8(-51); Load 0xABCD into r22:r23 in prep for call to foo
ldi r23,lo8(-85)
mov r30,r18
mov r31,r25
mov r21,r24
call __xload_1; r22 clobbered here
mov r24,r22
jmp foo
[Bug target/62084] [avr] ICE: in convert_debug_memory_address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62084 Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com changed: What|Removed |Added CC||senthil_kumar.selvaraj@atme ||l.com --- Comment #5 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- Not reproducible with the latest trunk build (gcc version 5.0.0 20150102)
[Bug rtl-optimization/64331] New: regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331
Bug ID: 64331
Summary: regcprop propagates registers noted as REG_DEAD
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: senthil_kumar.selvaraj at atmel dot com
Created attachment 34290
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34290action=edit
Source file
For the AVR target, compiling the attached source file with -O1 results in code
like this
snip
or r20,r21
or r20,r22
or r20,r23
breq .L1
ldd r24,Z+4
ldd r25,Z+5
ldd r26,Z+6
ldd r27,Z+7
cp r20,r24
cpc r21,r25
cpc r22,r26
cpc r23,r27
/snip
Register R20 was clobbered first up, but is used to compare against R24.
fdump-rtl-all-raw showed that cprop_hardreg is the culprit. In pass *.ce3
snip
(insn 7 4 8 2 (set (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(reg/v:SI 20 r20 [orig:46 x ] [46])) reduced.c:12 94 {*movsi}
(nil))
...
(insn 13 12 14 3 (parallel [
(set (cc0)
(compare (reg/v:SI 20 r20 [orig:46 x ] [46])
(const_int 0 [0])))
(clobber (scratch:QI))
]) reduced.c:17 413 {*cmpsi}
(expr_list:REG_DEAD (reg/v:SI 20 r20 [orig:46 x ] [46])
(nil)))
...
(insn 17 16 18 4 (parallel [
(set (cc0)
(compare (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(reg:SI 24 r24 [orig:48 t_3(D)-b ] [48])))
(clobber (scratch:QI))
]) reduced.c:20 413 {*cmpsi}
(expr_list:REG_DEAD (reg:SI 24 r24 [orig:48 t_3(D)-b ] [48])
(expr_list:REG_DEAD (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(nil
/snip
into
snip
;; Function foo (foo, funcdef_no=0, decl_uid=1599, cgraph_uid=0,
symbol_order=0)
insn 17: replaced reg 16 with 20
rescanning insn with uid = 17.
..
(insn 17 16 18 4 (parallel [
(set (cc0)
(compare (reg:SI 20 r20 [orig:43 D.1617 ] [43])
(reg:SI 24 r24 [orig:48 t_3(D)-b ] [48])))
(clobber (scratch:QI))
]) reduced.c:20 413 {*cmpsi}
(expr_list:REG_DEAD (reg:SI 24 r24 [orig:48 t_3(D)-b ] [48])
(expr_list:REG_DEAD (reg:SI 16 r16 [orig:43 D.1617 ] [43])
(nil
/snip
The AVR backend, on seeing that reg:SI r20 is dead in insn 13, emits code that
clobbers r20, and this breaks the read in insn 17.
[Bug rtl-optimization/64331] regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331 --- Comment #1 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- Created attachment 34291 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34291action=edit Assembly
[Bug target/64331] regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331 --- Comment #4 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- Yes, running df_notes_add_problem and df_analyze in the target code does work. Is it just REG_USED/REG_DEAD notes, or is register liveliness (df_regs_ever_live_p etc..) also not guaranteed to be up to date?
[Bug target/61044] Computed goto on AVR fails to use word-addressing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61044 --- Comment #3 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- Johann, The primary reason I added the diff relocs was to prevent linker relaxation messing up DWARF line number information - as you know, relaxation can shorten instruction sequences, and the addresses in DWARF then go out of sync. I guess I must add some user documentation about this, but ideally, this is supposed to be transparent to the user - just passing -mrelax to the compiler should work. I turned diff reloc generation on only if -mlink-relax is passed because this is what other ports (xtensa) do, and I wasn't sure of the consequences of resolving every subtraction expression at link time. I tried assembling .word pm(.L3-.L2) with -mlink-relax, but the assembler gave up with an expression too complex error. Like you said, I guess documenting that this is not supported is the way to go.
[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300 Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com changed: What|Removed |Added CC||senthil_kumar.selvaraj@atme ||l.com --- Comment #4 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- It doesn't actually get to that - avr_sp_immediate_operand returns false if the operand is not IN_RANGE(-6,6). The comments are a bit misleading though - the shortest sequence only applies if the addend is within that range. Like Johann said, it must be a deliberate decision in favor of speed - the attached program with a stub implementation of bar and main calling foo clocks a couple of cycles lesser with DSIZE=7 than with DSIZE=6(as measured with avrtest), although the code is 6 bytes longer. If RCALLs and PUSH had been generated, the code would be 4 bytes shorter, but would need 4 more clock cycles.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991
Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com changed:
What|Removed |Added
CC||senthil_kumar.selvaraj@atme
||l.com
--- Comment #2 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot
com ---
Here's a simplified dejagnu testcase.
/* { dg-do run } */
/* { dg-options -O1 } */
/* This testcase (simplified from the original bug report) exposes
PR60991. The code generated for writing the __int24 value corrupts
the frame pointer if the offset is = 63 + MAX_LD_OFFSET */
#include stdlib.h
int main(void)
{
volatile char junk[62];
junk[0] = 5;
volatile __int24 staticConfig = 0;
if (junk[0] != 5)
abort();
exit(0);
return 0;
}
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991 --- Comment #3 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- The OP's suspicion/analysis was right. Here's a trivial patch that fixes the problem. diff --git gcc/config/avr/avr.c gcc/config/avr/avr.c index 2edc78a..e96691e 100644 --- gcc/config/avr/avr.c +++ gcc/config/avr/avr.c @@ -3993,7 +3993,7 @@ avr_out_store_psi (rtx insn, rtx *op, int *plen) std Y+61,%A1CR_TAB std Y+62,%B1CR_TAB std Y+63,%C1CR_TAB -sbiw r28,%o0-60, op, plen, -5); +sbiw r28,%o0-61, op, plen, -5); return avr_asm_len (subi r28,lo8(-%o0) CR_TAB sbci r29,hi8(-%o0) CR_TAB
[Bug target/60588] New: AVR target does not support init_priority attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60588 Bug ID: 60588 Summary: AVR target does not support init_priority attribute Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: senthil_kumar.selvaraj at atmel dot com The AVR target does not support init_priority attribute. This makes it hard to control initialization order of global objects across translation units. Was originally requested at http://lists.nongnu.org/archive/html/avr-gcc-list/2014-03/msg5.html
[Bug target/54476] New: Passing -1 to __builtin_avr_delay_cycles causes cc1 memory usage to explode on x86_64 host
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54476
Bug #: 54476
Summary: Passing -1 to __builtin_avr_delay_cycles causes cc1
memory usage to explode on x86_64 host
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: senthil_kumar.selva...@atmel.com
Host: Linux x86_64
Target: AVR
Build: 4.8.0 20120903
gcc/testsuite/gcc.target/avr/torture/builtins-1.c has
void delay_4 (void) { __builtin_avr_delay_cycles (-1ul); }
When run on a 64 bit host, the delay cycles call with -1 causes cc1 to consume
huge amounts of memory, eventually timing out or running out of virtual memory.
Looking at the code, avr_expand_delay_cycles converts the operand passed to an
unsigned HOST_WIDE_INT. On a 64 bit machine, -1 becomes 0x. The
range checks only check for 0x and therefore get bypassed. The while
(cycles = 2) then keeps running, generating loads of nop instructions,
eventually causing memory exhaustion.
The delay cycles builtin is declared to take an unsigned long in
avr_init_builtins. If longs are 32 bit for the AVR target, perhaps only the
lower 4 bytes should be used?
[Bug middle-end/54218] New: Debug info for function parameters is incorrect when compiled with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54218
Bug #: 54218
Summary: Debug info for function parameters is incorrect when
compiled with -O0
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: senthil_kumar.selva...@atmel.com
Created attachment 27980
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27980
Failing dejagnu test case
When compiling a function, like below, with no optimizations (-O0), on a x86_64
target (also occurs for atleast one other target (avr))
void func(int p)
{
p = 0;
p = 32;
}
wrong debug information is emitted for the function parameter (p), that cause
the debugger to keep showing the value of the actual argument, even after p is
overwritten. A failing dejagnu test is attached.
Based on a preliminary analysis, the actual problem seems to be that stack
space for a function parameter (that is not used??) is allocated twice when
gimple_expand_cfg runs - once when expand_used_vars runs, and later when
assign_parm_setup_stack runs. expand_used_vars allocates stack space despite
the check for a default definition being present in the partition, because the
function parameter node (which I guess should be the default definition) is not
present when iterating over num_ssa_names.
[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54218
--- Comment #2 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot
com 2012-08-10 10:23:55 UTC ---
Comment on attachment 27980
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27980
Failing dejagnu test case
/* { dg-do run } */
/* { dg-options -g } */
/* { dg-skip-if { *-*-* } { * } { -O0 } } */
void func(int p)
{
p = 0; /* { dg-final { gdb-test 8 p 0 } } */
p = 32;/* { dg-final { gdb-test 8 p 42 } } */
}
int
main (void)
{
int local = 42;
func(local);
}
[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54218 Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com changed: What|Removed |Added Attachment #27980|0 |1 is obsolete|| --- Comment #3 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com 2012-08-10 10:25:03 UTC --- Created attachment 27981 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27981 Failing dejagnu test case (right line number)
[Bug middle-end/54218] Debug info for function parameters is incorrect when compiled with -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54218
--- Comment #4 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot
com 2012-08-10 10:39:32 UTC ---
(In reply to comment #1)
That's because the actual parameter value is not used:
func (int p)
{
;; basic block 2, loop depth 0
;;pred: ENTRY
p_1 = 0;
p_2 = 32;
return;
Partition 0 (p_1 - 1 2 )
Does -fvar-tracking fix it?
Yes, it does. Doesn't change the code generated though - the initial copy is
still at a different frame offset.
(In reply to comment #1)
That's because the actual parameter value is not used:
func (int p)
{
;; basic block 2, loop depth 0
;;pred: ENTRY
p_1 = 0;
p_2 = 32;
return;
Partition 0 (p_1 - 1 2 )
Does -fvar-tracking fix it?
(In reply to comment #1)
That's because the actual parameter value is not used:
func (int p)
{
;; basic block 2, loop depth 0
;;pred: ENTRY
p_1 = 0;
p_2 = 32;
return;
Partition 0 (p_1 - 1 2 )
Does -fvar-tracking fix it?
[Bug target/54220] New: [avr] Potential stack corruption in naked functions at -O0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54220
Bug #: 54220
Summary: [avr] Potential stack corruption in naked functions at
-O0
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: senthil_kumar.selva...@atmel.com
Target: AVR
Naked functions do not have a prologue and an epilogue by design, but code
emitted with -O0 for function parameters assume their presence and attempt to
copy values onto the stack. This can corrupt the caller's stack frame.
Note the stores to Y+2 and Y+1 in the example below.
[scratch]$ cat test.c
void __attribute__((naked)) func(int x)
{
__asm volatile (ret);
}
[scratch]$ avr-gcc -O0 -S test.c
[scratch]$ cat test.s
.file test.c
__SREG__ = 0x3f
__SP_H__ = 0x3e
__SP_L__ = 0x3d
__CCP__ = 0x34
__tmp_reg__ = 0
__zero_reg__ = 1
.global __do_copy_data
.global __do_clear_bss
.text
.global func
.type func, @function
func:
/* prologue: naked */
/* frame size = 2 */
/* stack size = 0 */
.L__stack_usage = 0
std Y+2,r25
std Y+1,r24
/* #APP */
; 3 test.c 1
ret
; 0 2
/* epilogue start */
/* #NOAPP */
.size func, .-func
