[Bug c/21322] O2 and O3 memory access error - compiled program - incorrect debug output

["fastsnip-bcard1 at yahoo dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From fastsnip-bcard1 at yahoo dot com  2005-05-01 20:30 -------
Subject: Re:  O2 and O3 memory access error - compiled program - incorrect debug output

On Sunday 01 May 2005 16:25, you wrote:
> ------- Additional Comments From fastsnip-bcard1 at yahoo dot com 
> 2005-05-01 20:24 ------- Subject: Re:  O2 and O3 memory access error -
> compiled program - incorrect debug output
>
> On Sunday 01 May 2005 15:40, you wrote:
> > ------- Additional Comments From pinskia at gcc dot gnu dot org 
> > 2005-05-01 19:40 ------- (In reply to comment #5)
> >
> > > Subject: Re:  O2 and O3 memory access error - compiled program -
> > > incorrect debug output
> > >
> > > On Sunday 01 May 2005 15:19, you wrote:
> > > > ------- Additional Comments From pinskia at gcc dot gnu dot org
> > > > 2005-05-01 19:19 ------- Also can you look to see you have any
> > > > warnings with -W -Wall? The warnings about unsigned vs signed were
> > > > there before just enabled with -pedantic.
> > > >
> > > > Also does -fno-strict-aliasing help if so this might not be a bug in
> > > > GCC but your code.
> > >
> > > Compiled with the above flag as you suggested - no change - I still get
> > > a memory access error using "-O3" optiomization.
> > >
> > > Will try the "-W -Wall" flags top see what that produces and let you
> > > know.
> > >
> > > Terry
> >
> > Hmm, try -O1 -funit-at-a-time also make sure that you are not going past
> > an array bounds. Also make sure that you are not invoking undefined
> > behavior.
>
> Okay I tried the following optimizing options:
>
> -O1 -funit-at-a-time ==== program ran fine
> -O1                       ==== program ran fine
> -O2 -funit-at-a-time ==== memory access error
> -O3 -funit-at-a-time ==== memory access error
>
> It seems that O2 and O3 only trigger the memory access error.
>
>
> Do not know exactly what you mean by "Also make sure that you are not
> invoking undefined behavior." Exactly how do I do this. Is there something
> in 4.0.0 that wasn't in 2.95 through 3.4.3 that would trigger this? The
> program compiled and ran fine under previous versions with the same
> compilation optimization options.
>
> > I get a lot of warnings about uninitialized variables like so:
> > awkpcmp.c: In function 'c_pop':
> > awkpcmp.c:57: warning: 'R_Token' may be used uninitialized in this
> > function awkpcmp.c: In function 'c_primary_expr':
> > awkpcmp.c:159: warning: 'arg2' may be used uninitialized in this function
> > awkpcmp.c:158: warning: 'arg1' may be used uninitialized in this function
> > awkpcmp.c: In function 'c_statement':
> > awkpcmp.c:1122: warning: 'Last_Token' may be used uninitialized in this
> > function awkpcmp.c: In function 'set_user_fun':
> > awkpcmp.c:1789: warning: 'name' may be used uninitialized in this
> > function
> >
> > so you might just be invoking undefined.

Yes these warnings are fine to have and check - unfortunately  the compiler 
cannot run through the code logic and I find that these warnings are 
generated spuriously because of that. Once you cycle through the code logic, 
the warning is unfounded. Again, good as a check, but it can generatea lot of 
un-necessary warnings and create a LOT of work checking logic.

Thanks,
Terry



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21322