From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102f.google.com (mail-pj1-x102f.google.com [IPv6:2607:f8b0:4864:20::102f]) by sourceware.org (Postfix) with ESMTPS id 21AE33852224 for ; Wed, 23 Nov 2022 17:18:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 21AE33852224 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x102f.google.com with SMTP id e7-20020a17090a77c700b00216928a3917so2673398pjs.4 for ; Wed, 23 Nov 2022 09:18:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=+YCd+qldYp/D1S37IZ9BATnuXTPl/Xfb/7UEMtUDa7o=; b=mVewjM+XFFkq4DIw02gA0NbdKdZHbYlm5Mc/Pak35/54YpCUs0gOqhn32Z4unZPGCC vGirOdk++p6CrLFx48T9wTvGbLKlcSlQ8Dhk3D1iPGOM+2mrlz1GyO+Ftlr9mLez+rsP j1aK89IPf4i2wym7xlRoSPPfzg9BoekcTIPercIOmq46vYxUegBhcQq938ZFU7az1sWe 7ReUOTRXJiBAgVmYgaTTDQKpd99Zv2TNXCsYSAyhv6ziTWOrJ/Tsdel5QeQ96++NJJ0T MgC20UZJmJDR8DmaEVo0ZObLl3Kt7WBga6xIHUjbWlnlSV5FJ2OqjKPxk75EKzEX6LK/ 7CGg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=+YCd+qldYp/D1S37IZ9BATnuXTPl/Xfb/7UEMtUDa7o=; b=OMM50JEF5BUW9Bm0IgkZHQzFYoK0kNYjChnP9h59Ruibma9kKhjuUMqlo2cns8aGio jZDslwfGbgSDUBdR11w3zKwDaxnWPj/9QPxWBivrrZPm9yc2bRktNfLW2/GZN4D0FdNE oukySwAGQ/Ojz/LODRV8BzlvJelBvczNDpIUDqWNSeYWicX0qbvjUvnOPevQ/4dFKGCz WUkitlwGVGQT0f326CvzkseR8HayAN2yPyvVol9ZwUBRYu5gHe420iI4cZsXtuSvxfyJ 4IY9PwhOcvhNaG6ei63TZX+jaQx/6JI6m3TCEDDKLbwoRwUGDeGZIfK/n+AzT/gu3laT /47w== X-Gm-Message-State: ANoB5pmK7BQa282nntLSQqKNj5x+xwyspOLYqxFLHtI+m25gZDiAl/wn dSolS9t0/gmQqZHJYHGcxH+/z4+kv2NHIPKxRmhU9Kwe30Ji1w== X-Google-Smtp-Source: AA0mqf50OjKzEikOnHezGTUnvzVxhy+QFpkcps91014lAgaKcV3YbqPAbNwXgzZu85VAMKcyyG/YLYx+4SZBAlXEEms= X-Received: by 2002:a17:90a:4207:b0:209:46fe:871b with SMTP id o7-20020a17090a420700b0020946fe871bmr37770980pjg.163.1669223905867; Wed, 23 Nov 2022 09:18:25 -0800 (PST) MIME-Version: 1.0 References: <6cf489d9-ccd6-af3c-b49e-7bc5166557c6@gjlay.de> In-Reply-To: <6cf489d9-ccd6-af3c-b49e-7bc5166557c6@gjlay.de> From: Andrew Pinski Date: Wed, 23 Nov 2022 09:18:13 -0800 Message-ID: Subject: Re: -Warray-bounds interprets int *var as int var[0] ? To: Georg-Johann Lay Cc: gcc@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Wed, Nov 23, 2022 at 9:15 AM Georg-Johann Lay wrote: > > 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: > > > 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"); > } > } > > > 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? Either you need to use --param=min-pagesize=0 as an option or you need to modify the avr backend to set that by default. Thanks, Andrew Pinski > > 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) >