public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Georg-Johann Lay <avr@gjlay.de>
To: gcc@gcc.gnu.org
Subject: -Warray-bounds interprets int *var as int var[0] ?
Date: Wed, 23 Nov 2022 18:13:39 +0100	[thread overview]
Message-ID: <6cf489d9-ccd6-af3c-b49e-7bc5166557c6@gjlay.de> (raw)

The following code throws a warning which I do not understand.

Purpose is to save and restore SREG, which is a special function 
register (SFR) defined by its hardware address as:

#define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__))

which is the common C idiom to define such an SFR. The C code is:

<code>
typedef __UINT8_TYPE__ uint8_t;

#define SREG (*(volatile uint8_t*) (0x3F + __AVR_SFR_OFFSET__))

static __inline__ uint8_t __iCliRetVal (void)
{
     __asm__ __volatile__ ("cli" ::: "memory");
     return 1;
}

static __inline__ void __iRestore (const uint8_t *__s)
{
     SREG = *__s;
     __asm__ volatile ("" ::: "memory");
}

void foo (void)
{

    for (uint8_t sreg_save __attribute__((__cleanup__(__iRestore))) = SREG,
             __ToDo = __iCliRetVal();
          __ToDo ;
          __ToDo = 0 )
    {
        __asm ("nop");
    }
}
</code>

The documentation of attribute cleanup says that the function provided 
to cleanup (__iRestore) must take a pointer type that is compatible with 
the attributed variable, which is the case.  The warning is:

  avr-gcc-13 -c foo-i.c -mmcu=atmega8 -Os -Wall -save-temps -dumpbase ""
foo-i.c: In function 'foo':
foo-i.c:20:71: warning: array subscript 0 is outside array bounds of 
'volatile uint8_t[0]' {aka 'volatile unsigned char[]'} [-Warray-bounds]
    20 |    for (uint8_t sreg_save 
__attribute__((__cleanup__(__iRestore))) = SREG,
       | 
      ~^~~~
In function '__iRestore',
     inlined from 'foo' at foo-i.c:20:17:
foo-i.c:13:42: warning: array subscript 0 is outside array bounds of 
'volatile uint8_t[0]' {aka 'volatile unsigned char[]'} [-Warray-bounds]
    13 |     SREG = *__s;
       |     ~~~~~~~~~~~~                         ^

To me this looks like a GCC problem, and older versions of the compiler 
don't complain.  Or is there actually an issue with that code? Purpose 
of the code is to save / restore SREG around a block of code, "nop" in 
the example.

The warning complains about the places that are using SREG, so it that 
macro definition wrong?

Thanks in advance,

Johann


 > avr-gcc-13 -v
Using built-in specs.
Reading specs from 
/home/DATA/gnu/install/gcc-master-avr/bin/../lib/gcc/avr/13.0.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc-13
COLLECT_LTO_WRAPPER=/home/DATA/gnu/install/gcc-master-avr/bin/../libexec/gcc/avr/13.0.0/lto-wrapper
Target: avr
Configured with: ../../source/gcc-master/configure --target=avr 
--disable-nls --with-dwarf2 --enable-languages=c,c++ --with-gnu-as 
--with-gnu-ld --disable-shared --with-fixed-point=no 
--prefix=/home/john/gnu/install/gcc-master-avr --enable-checking=release
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20221103 (experimental) (GCC)


             reply	other threads:[~2022-11-23 17:13 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-11-23 17:13 Georg-Johann Lay [this message]
2022-11-23 17:18 ` Andrew Pinski
2022-11-23 17:44   ` Georg-Johann Lay

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=6cf489d9-ccd6-af3c-b49e-7bc5166557c6@gjlay.de \
    --to=avr@gjlay.de \
    --cc=gcc@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: link
Be 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).