public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Georg-Johann Lay <gjl@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc r13-8319] avr: Fix wrong array bounds warning on SFR access Date: Mon, 12 Feb 2024 17:08:04 +0000 (GMT) [thread overview] Message-ID: <20240212170804.3F75D3858D38@sourceware.org> (raw) https://gcc.gnu.org/g:83e9075ed22c0c5f27328b4be7d8eb9df5c8778b commit r13-8319-g83e9075ed22c0c5f27328b4be7d8eb9df5c8778b Author: Senthil Kumar Selvaraj <saaadhu@gcc.gnu.org> Date: Mon Jun 19 12:23:25 2023 +0530 avr: Fix wrong array bounds warning on SFR access The warning was raised on accessing SFRs at addresses below the default page size, as gcc considers accessing addresses in the first page of memory as suspicious. This doesn't apply to an embedded target like the avr, where both flash and RAM have zero as a valid address. Zero is also a valid address in named address spaces (__memx, flash<n> etc..). This commit implements TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID for the avr target and reports to gcc that zero is a valid address on all address spaces. It also disables flag_delete_null_pointer_checks based on the target hook, and modifies target-supports.exp to add avr to the list of targets that always keep null pointer checks. This fixes a bunch of DejaGNU failures that occur otherwise. PR target/105523 gcc/ChangeLog: * common/config/avr/avr-common.cc: Remove setting of OPT_fdelete_null_pointer_checks. * config/avr/avr.cc (avr_option_override): Clear flag_delete_null_pointer_checks if zero_address_valid. (avr_addr_space_zero_address_valid): New function. (TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID): Provide target hook. gcc/testsuite/ChangeLog: * lib/target-supports.exp (check_effective_target_keeps_null_pointer_checks): Add avr. * gcc.target/avr/pr105523.c: New test. (cherry picked from commit 58e1bc2b1c8420773b16452d47932a6ca0d003fb) Diff: --- gcc/common/config/avr/avr-common.cc | 6 ------ gcc/config/avr/avr.cc | 17 +++++++++++++++++ gcc/testsuite/gcc.target/avr/pr105523.c | 14 ++++++++++++++ gcc/testsuite/lib/target-supports.exp | 3 ++- 4 files changed, 33 insertions(+), 7 deletions(-) diff --git a/gcc/common/config/avr/avr-common.cc b/gcc/common/config/avr/avr-common.cc index 2ad02448e290..2f874c5b81c7 100644 --- a/gcc/common/config/avr/avr-common.cc +++ b/gcc/common/config/avr/avr-common.cc @@ -29,12 +29,6 @@ /* Implement TARGET_OPTION_OPTIMIZATION_TABLE. */ static const struct default_options avr_option_optimization_table[] = { - // With -fdelete-null-pointer-checks option, the compiler assumes - // that dereferencing of a null pointer would halt the program. - // For AVR this assumption is not true and a program can safely - // dereference null pointers. Changes made by this option may not - // work properly for AVR. So disable this option. - { OPT_LEVELS_ALL, OPT_fdelete_null_pointer_checks, NULL, 0 }, // The only effect of -fcaller-saves might be that it triggers // a frame without need when it tries to be smart around calls. { OPT_LEVELS_ALL, OPT_fcaller_saves, NULL, 0 }, diff --git a/gcc/config/avr/avr.cc b/gcc/config/avr/avr.cc index b50fe3b6bf53..0f046eba26dc 100644 --- a/gcc/config/avr/avr.cc +++ b/gcc/config/avr/avr.cc @@ -1097,6 +1097,10 @@ avr_option_override (void) flag_omit_frame_pointer = 0; } + /* Disable flag_delete_null_pointer_checks if zero is a valid address. */ + if (targetm.addr_space.zero_address_valid (ADDR_SPACE_GENERIC)) + flag_delete_null_pointer_checks = 0; + if (flag_pic == 1) warning (OPT_fpic, "%<-fpic%> is not supported"); if (flag_pic == 2) @@ -10387,6 +10391,16 @@ avr_addr_space_diagnose_usage (addr_space_t as, location_t loc) (void) avr_addr_space_supported_p (as, loc); } +/* Implement `TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID. Zero is a valid + address in all address spaces. Even in ADDR_SPACE_FLASH1 etc.., + a zero address is valid and means 0x<RAMPZ val>0000, where RAMPZ is + set to the appropriate segment value. */ + +static bool +avr_addr_space_zero_address_valid (addr_space_t) +{ + return true; +} /* Look if DECL shall be placed in program memory space by means of attribute `progmem' or some address-space qualifier. @@ -15197,6 +15211,9 @@ avr_float_lib_compare_returns_bool (machine_mode mode, enum rtx_code) #undef TARGET_ADDR_SPACE_DIAGNOSE_USAGE #define TARGET_ADDR_SPACE_DIAGNOSE_USAGE avr_addr_space_diagnose_usage +#undef TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID +#define TARGET_ADDR_SPACE_ZERO_ADDRESS_VALID avr_addr_space_zero_address_valid + #undef TARGET_MODE_DEPENDENT_ADDRESS_P #define TARGET_MODE_DEPENDENT_ADDRESS_P avr_mode_dependent_address_p diff --git a/gcc/testsuite/gcc.target/avr/pr105523.c b/gcc/testsuite/gcc.target/avr/pr105523.c new file mode 100644 index 000000000000..fbbf7bf44227 --- /dev/null +++ b/gcc/testsuite/gcc.target/avr/pr105523.c @@ -0,0 +1,14 @@ +/* { dg-do compile } */ +/* { dg-options "-Os -Wall" } */ + +/* Verify no "array subscript 0 is outside array bounds of" is generated + for accessing memory addresses in the 0-4096 range. */ + +typedef __UINT8_TYPE__ uint8_t; + +#define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__ )) + +void bar (void) +{ + SREG = 0; +} diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp index 4d6bf2eb8d32..9e189d91e4b0 100644 --- a/gcc/testsuite/lib/target-supports.exp +++ b/gcc/testsuite/lib/target-supports.exp @@ -686,7 +686,8 @@ proc check_effective_target_keeps_null_pointer_checks { } { if [target_info exists keeps_null_pointer_checks] { return 1 } - if { [istarget msp430-*-*] } { + if { [istarget msp430-*-*] + || [istarget avr-*-*] } { return 1; } return 0
reply other threads:[~2024-02-12 17:08 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20240212170804.3F75D3858D38@sourceware.org \ --to=gjl@gcc.gnu.org \ --cc=gcc-cvs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).