public inbox for gcc-help@gcc.gnu.org
 help / color / mirror / Atom feed
* avr-gcc optimization issue
@ 2014-03-07 15:12 Henrik Juul Pedersen
  2014-03-07 15:36 ` Oleg Endo
  2014-03-07 17:18 ` David Brown
  0 siblings, 2 replies; 3+ messages in thread
From: Henrik Juul Pedersen @ 2014-03-07 15:12 UTC (permalink / raw)
  To: gcc-help

Hi, I'm not sure if this is the correct forum, but I'm not sure
whether this is a bug, or a feature.

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.

Best regards,
Henrik Juul Pedersen
LIAB ApS

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: avr-gcc optimization issue
  2014-03-07 15:12 avr-gcc optimization issue Henrik Juul Pedersen
@ 2014-03-07 15:36 ` Oleg Endo
  2014-03-07 17:18 ` David Brown
  1 sibling, 0 replies; 3+ messages in thread
From: Oleg Endo @ 2014-03-07 15:36 UTC (permalink / raw)
  To: Henrik Juul Pedersen; +Cc: gcc-help

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

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: avr-gcc optimization issue
  2014-03-07 15:12 avr-gcc optimization issue Henrik Juul Pedersen
  2014-03-07 15:36 ` Oleg Endo
@ 2014-03-07 17:18 ` David Brown
  1 sibling, 0 replies; 3+ messages in thread
From: David Brown @ 2014-03-07 17:18 UTC (permalink / raw)
  To: Henrik Juul Pedersen, gcc-help

On 07/03/14 15:39, 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.

gcc-help can be appropriate, but if your question is very specific to
the avr port then avr-gcc-list@nongnu.org might be better.

> 
> Im working on a program for an AVR microcontroller using avr-gcc for
> the compilation.
> 
> 
> I have gotten an issue with a single function variable not being
> checked after optimization.

Do you mean a variable local to the function (as distinct from a
function pointer variable)?

> My question is: shouldn't I be able to assume that function variables
> are treated as being volatile, unless optimized away completely?

No, you should assume the compiler will do all sorts of wonderful
optimisations with local variables.  It is usually a bit more limited
with local static variables, but "normal" local variables (what used to
be called "auto" variables before C++11 usurped that keyword) can be
heavily optimised.

> 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 is usually not useful to have a large source file - a small test case
is best.  It is quite common that in the process of finding a small test
case that shows the problem, people find the issue themselves.

mvh.,

David


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-03-07 17:01 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-07 15:12 avr-gcc optimization issue Henrik Juul Pedersen
2014-03-07 15:36 ` Oleg Endo
2014-03-07 17:18 ` David Brown

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).