On Wed, 9 Aug 2006 09:09:56 -0700, Bruce Korb wrote:
> const char * pOptTitle;
const char * pOptTitle = pOptTitle;
is another possibility to shut the warning... without adding any
generated code...
There was another discussion about this issue here:
http://gcc.gnu.org/ml/gcc/2006-01/msg00274
As you probably know by now, one can't look at a bug of this sort
without a compilable test case. Andrew correctly pointed out that this
optimization is affected by (for instance) inlining.
Hi Daniel,
The function referenced is in a separate compilation unit and
even if it were in the same uni
On Wed, Aug 09, 2006 at 09:09:56AM -0700, Bruce Korb wrote:
> Here is the real code. The complaint is about pOptTitle.
> The compiler is GCC 4.1.1. Both "set*OptFmts" functions
> *WILL* set pOptTitle to something. Option level is -O4, so
> flow analysis is being done:
As you probably know by no
>
>
> There's more to it than that, unless your compiler is very broken.
> GCC should not warn for "int x; foo (&x);".
Or inlining happened and foo got inlined and really there is a path
which could leave x uninitialized.
-- Pinski
Here is the real code. The complaint is about pOptTitle.
The compiler is GCC 4.1.1. Both "set*OptFmts" functions
*WILL* set pOptTitle to something. Option level is -O4, so
flow analysis is being done:
void
optionOnlyUsage(
tOptions* pOpts,
int ex_code )
{
const char * pOptTitle;
On Wed, Aug 09, 2006 at 08:35:42AM -0700, Bruce Korb wrote:
> or else:
>
> extern void yyy( int* zzz __sets_value__ );
>
> void foo(void) {
>int xxx;
> yyy( &xxx );
>
>
> Where "__sets_value__" implies both that the current value is not
> accessed and that it will be set before ret
