From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27584 invoked by alias); 7 Mar 2014 15:28:36 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 27571 invoked by uid 89); 7 Mar 2014 15:28:35 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,T_RP_MATCHES_RCVD,UNPARSEABLE_RELAY autolearn=ham version=3.3.2 X-HELO: mailout08.t-online.de Received: from mailout08.t-online.de (HELO mailout08.t-online.de) (194.25.134.20) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Fri, 07 Mar 2014 15:28:34 +0000 Received: from fwd12.aul.t-online.de (fwd12.aul.t-online.de ) by mailout08.t-online.de with smtp id 1WLwhK-0000dV-DW; Fri, 07 Mar 2014 16:28:30 +0100 Received: from [192.168.0.103] (ZwUP34Z6ohPygn3QHxL5CS7C-ZEQzYt5bB2xeRf1ls5RNd3t4b8E5PVjw2UYceBZIS@[93.195.28.43]) by fwd12.t-online.de with esmtp id 1WLwhI-2B4rWS0; Fri, 7 Mar 2014 16:28:28 +0100 Message-ID: <1394206106.19458.11.camel@yam-132-YW-E178-FTW> Subject: Re: avr-gcc optimization issue From: Oleg Endo To: Henrik Juul Pedersen Cc: gcc-help@gcc.gnu.org Date: Fri, 07 Mar 2014 15:36:00 -0000 In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Mime-Version: 1.0 X-IsSubscribed: yes X-SW-Source: 2014-03/txt/msg00023.txt.bz2 Hello, On Fri, 2014-03-07 at 15:39 +0100, Henrik Juul Pedersen wrote: > Hi, I'm not sure if this is the correct forum, but I'm not sure > whether this is a bug, or a feature. Yes, gcc-help is for these kind of questions, however ... > > Im working on a program for an AVR microcontroller using avr-gcc for > the compilation. > > $ avr-gcc -v > Using built-in specs. > COLLECT_GCC=avr-gcc > COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.8.2/lto-wrapper > Target: avr > Configured with: /build/avr-gcc/src/gcc-4.8.2/configure > --disable-cloog-version-check --disable-install-libiberty > --disable-libssp --disable-libstdcxx-pch > --disable-libunwind-exceptions --disable-linker-build-id --disable-nls > --disable-werror --enable-__cxa_atexit --enable-checking=release > --enable-clocale=gnu --enable-cloog-backend=isl > --enable-gnu-unique-object --enable-gold --enable-languages=c,c++ > --enable-ld=default --enable-lto --enable-plugin --enable-shared > --infodir=/usr/share/info --libdir=/usr/lib --libexecdir=/usr/lib > --mandir=/usr/share/man --prefix=/usr --target=avr > --with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld > --with-ld=/usr/bin/avr-ld --with-plugin-ld=ld.gold --with-system-zlib > Thread model: single > gcc version 4.8.2 (GCC) > > I have gotten an issue with a single function variable not being > checked after optimization. > My question is: shouldn't I be able to assume that function variables > are treated as being volatile, unless optimized away completely? > Marking the function variable volatile solves the issue. > > The code is compiled with -O2 -ffreestanding -Wall -Wextra and > produces no warnings. > > I have not been able to create a simple test-case, but I can supply > the entire source upon request. ... it's difficult to answer your question, because of lack of source code that shows the problem. There could be a bug in the compiler, or there could be a bug in your code. The compiler may remove local variables, if it thinks they are not needed. For example: int test (int a) { int b = 5; int c = a + b; return c; } will effectively be converted to 'return a + 5'. If one of the local variables is marked volatile, it will be usually allocated and loaded/stored using stack memory -- this is not the default behavior. Cheers, Oleg