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
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/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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67031
Senthil Kumar Selvaraj changed:
What|Removed |Added
CC||senthil_kumar.selvaraj@atme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67373
Senthil Kumar Selvaraj changed:
What|Removed |Added
CC||senthil_kumar.selvaraj@atme
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
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
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
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
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
: 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
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
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
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
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
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
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
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
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
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:
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
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
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
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
25 matches
Mail list logo
