Re: missed uninitialised variable warning

Re: missed uninitialised variable warning

[Robert Dewar]

> void *x = &x;
> 
> This must work, and I don't see anything possibly dubious about it.


Well I certainly find the formal semantics in the C++ standard tricky
sometimes since it is not a standard that I am fully familiar with,
but I am not sure I can deduce that this must always work from the
formal semantics. But that may just be me :-)

Re: missed uninitialised variable warning

[Alexandre Oliva]

On Aug  4, 2003, dewar@gnat.com (Robert Dewar) wrote:

>> void *x = &x;
>> 
>> This must work, and I don't see anything possibly dubious about it.

> but I am not sure I can deduce that this must always work from the
> formal semantics

I don't see anything odd about a generic pointer pointing to a memory
location that happens to be its own address.  If you cast this void*
back to its original type (void**), you can even assign to it:

*(void**)x = some_other_pointer;

and it's required to work correctly, i.e., to assign this other
pointer to x.

Now let's please not talk about whether this is actually useful :-)
It may even turn out to be (circular linked lists come to mind), but I
probably wouldn't recommend this style anyway :-)

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: missed uninitialised variable warning

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > void *x = &x;
| > 
| > This must work, and I don't see anything possibly dubious about it.
| 
| 
| Well I certainly find the formal semantics in the C++ standard tricky
| sometimes since it is not a standard that I am fully familiar with,
| but I am not sure I can deduce that this must always work from the
| formal semantics. But that may just be me :-)

The declarator "x" designates an object whose initial value is its own
address.

-- Gaby

Re: missed uninitialised variable warning

[Phil Edwards]

On Mon, Aug 04, 2003 at 03:29:56PM -0300, Alexandre Oliva wrote:
> Now let's please not talk about whether this is actually useful :-)

Especially since it's quite useful.  :-)

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: missed uninitialised variable warning

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > No.  The reason is that there is no trap representation for unsigned
| > char.   You can safely read an uninitialized unsigned char -- you just
| > get "random"  bit patterns.
| 
| 
| There is absolutely NO justification for this position.

Huh?  Can you provide reference to the protion of the standard that
says otheriwse?

| The formal semantics does not begin to guarantee this behavior.

You're wrong.

| You are just restating the likely  actual behavior of what is
| formally undefined behavior.

No.  That unsigned char don't have trap representation is rule by both
C and C++ standards.

| At least that's my reading of the standard.

Which portion did you read that way?

-- Gaby

Re: missed uninitialised variable warning

[Robert Dewar]

> No.  The reason is that there is no trap representation for unsigned
> char.   You can safely read an uninitialized unsigned char -- you just
> get "random"  bit patterns.


There is absolutely NO justification for this position. The formal semantics
does not begin to guarantee this behavior. You are just restating the likely
actual behavior of what is formally undefined behavior. At least that's my
reading of the standard. If you manage to read otherwise, please let's see
how!

neither C nor C++ are defined by what happens to work!

Re: missed uninitialised variable warning

[Laurent GUERBY]

On Mon, 2003-08-04 at 20:05, Alexandre Oliva wrote:
> On Aug  4, 2003, Laurent GUERBY <guerby@acm.org> wrote:
> 
> > For Ada at least the construct is illegal
> 
> In C and C++ it's legal, and there are actual cases in which you do
> want to reference the variable (as an lvalue) before its declaration
> is complete.

I was answering a specific point about the effect of a patch
on languages other than C and C++, since not many
people know Ada I thought it was useful to mention
that such a construct is unlikely to get past
the front-end in Ada so no back-end or shared front-end issue there.

No need to turn the discussion in a language feature flame war :).

Laurent

Re: missed uninitialised variable warning

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > 
| >   unsigned char c = c;
| > 
| > is guaranted to work, just like
| 
| What on earth does "work" mean here (in formal C++ standard terms, not
| in pragmatic "we-know-what-it-must-mean" terms.

well-formed and does not have an undefined behaviour. 

-- Gaby

Re: missed uninitialised variable warning

[Gabriel Dos Reis]

Alexandre Oliva <aoliva@redhat.com> writes:

| On Aug  4, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:
| 
| >   unsigned char c = c;
| 
| Actually, I *think* this invokes undefined behavior, because you use
| an uninitialized value.  This is quite different from:

No.  The reason is that there is no trap representation for unsigned
char.   You can safely read an uninitialized unsigned char -- you just
get "random"  bit patterns.

-- Gaby

Re: missed uninitialised variable warning

[Robert Dewar]

> 
>   unsigned char c = c;
> 
> is guaranted to work, just like

What on earth does "work" mean here (in formal C++ standard terms, not
in pragmatic "we-know-what-it-must-mean" terms.

Re: missed uninitialised variable warning

[Alexandre Oliva]

On Aug  4, 2003, Gabriel Dos Reis <gdr@integrable-solutions.net> wrote:

>   unsigned char c = c;

Actually, I *think* this invokes undefined behavior, because you use
an uninitialized value.  This is quite different from:

>   void* x = &x;

that is indeed guaranteed to work.  The difference is clearly that you
use the former as an rvalue, and the latter as an lvalue.

Even more interesting is:

  int &x = x;

this is not illegal, but it's obviously useless, as any use of x would
invoke undefined behavior, even if the initialization (contrary to my
believe) doesn't.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: missed uninitialised variable warning

[Gabriel Dos Reis]

dewar@gnat.com (Robert Dewar) writes:

| > In C and C++ it's legal, and there are actual cases in which you do
| > want to reference the variable (as an lvalue) before its declaration
| > is complete.
| 
| Isn't that a bit dubious from a formal point of view.

It may be dubious from Ada point of view.  But it isn't necessary from C and
C++ point of view.

| Yes, I understand
| it will typically work, but I am not sure I can deduce that it must work.

  unsigned char c = c;

is guaranted to work, just like

  void* x = &x;

in C and C++.

-- Gaby

Re: missed uninitialised variable warning

[Alexandre Oliva]

On Aug  4, 2003, dewar@gnat.com (Robert Dewar) wrote:

>> In C and C++ it's legal, and there are actual cases in which you do
>> want to reference the variable (as an lvalue) before its declaration
>> is complete.

> Isn't that a bit dubious from a formal point of view.

I don't see why, and I've already given the example:

void *x = &x;

This must work, and I don't see anything possibly dubious about it.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: missed uninitialised variable warning

[Robert Dewar]

> In C and C++ it's legal, and there are actual cases in which you do
> want to reference the variable (as an lvalue) before its declaration
> is complete.

Isn't that a bit dubious from a formal point of view. Yes, I understand
it will typically work, but I am not sure I can deduce that it must work.

Re: missed uninitialised variable warning

[Alexandre Oliva]

On Aug  4, 2003, Laurent GUERBY <guerby@acm.org> wrote:

> For Ada at least the construct is illegal

In C and C++ it's legal, and there are actual cases in which you do
want to reference the variable (as an lvalue) before its declaration
is complete.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: missed uninitialised variable warning

[Laurent GUERBY]

On Mon, 2003-08-04 at 17:15, Andrew Pinski wrote:
> On Monday, Aug 4, 2003, at 09:56 US/Eastern, Andrew Pinski wrote:
> > Here is a patch which should warn about more complicated expressions.
> > If you want to limit gcc not warn about int i=i;, then add a condition 
> > in contains_exp
> > for the case x==t and change the name of contains_exp.
> 
> This patch does not work with anything other than c and C++ because 
> walk_tree depends on the c front-end which
> needs to change (and is changed already on the tree-ssa branch).

For Ada at least the construct is illegal so it's
handled by the front-end with the following error message:

p.adb:2:19: object "I" cannot be used before end of its declaration

Don't know for other languages.

Laurent

Re: missed uninitialised variable warning

[Alexandre Oliva]

On Aug  4, 2003, Andrew Pinski <pinskia@physics.uc.edu> wrote:

> Here is a patch which should warn about more complicated expressions.

I get the impression that, with your patch, we'd get a warning for this:

void *x = &x;

which shouldn't be warned about, IMO.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: missed uninitialised variable warning

[Andrew Pinski]

On Monday, Aug 4, 2003, at 09:56 US/Eastern, Andrew Pinski wrote:
> Here is a patch which should warn about more complicated expressions.
> If you want to limit gcc not warn about int i=i;, then add a condition 
> in contains_exp
> for the case x==t and change the name of contains_exp.

This patch does not work with anything other than c and C++ because 
walk_tree depends on the c front-end which
needs to change (and is changed already on the tree-ssa branch).

Thanks,
Andrew Pinsi

Re: missed uninitialised variable warning

[Andrew Pinski]

On Monday, Aug 4, 2003, at 09:20 US/Eastern, Michael Matz wrote:

> Hi,
>
> On 4 Aug 2003, Gabriel Dos Reis wrote:
>
>> | Hmm, hard to fix ...  I don't know, the patch below does it for the 
>> easy
>> | 'x = x' case.  But I immediately withdraw it, as I like this 
>> feature ;-)
>>
>> where were you when people argued with that? ;-)
>
> I think I also argued for this feature.  ;-)
>
> The patch catches only one certain instance of the whole recursive
> initialization problem.  Namely it does not catch things like
> "int i = g(i); int j = j + 1;" , i.e. any more complicated expression 
> than
> the var itself.


Here is a patch which should warn about more complicated expressions.
If you want to limit gcc not warn about int i=i;, then add a condition 
in contains_exp
for the case x==t and change the name of contains_exp.


Thanks,
Andrew Pinski

Index: Makefile.in
===================================================================
RCS file: /cvs/gcc/gcc/gcc/Makefile.in,v
retrieving revision 1.1135
diff -u -p -r1.1135 Makefile.in
--- Makefile.in	1 Aug 2003 14:04:00 -0000	1.1135
+++ Makefile.in	4 Aug 2003 13:54:13 -0000
@@ -1525,7 +1525,7 @@ varasm.o : varasm.c $(CONFIG_H) $(SYSTEM
  function.o : function.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) 
$(RTL_H) $(TREE_H) \
     flags.h function.h $(EXPR_H) $(OPTABS_H) libfuncs.h $(REGS_H) 
hard-reg-set.h \
     insn-config.h $(RECOG_H) output.h toplev.h except.h $(HASHTAB_H) 
$(GGC_H) \
-   $(TM_P_H) langhooks.h gt-function.h
+   $(TM_P_H) tree-inline.h langhooks.h gt-function.h
  stmt.o : stmt.c $(CONFIG_H) $(SYSTEM_H) coretypes.h $(TM_H) $(RTL_H) 
$(TREE_H) flags.h \
     function.h insn-config.h hard-reg-set.h $(EXPR_H) libfuncs.h 
except.h \
     $(LOOP_H) $(RECOG_H) toplev.h output.h varray.h $(GGC_H) $(TM_P_H) \
Index: function.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.449
diff -u -p -r1.449 function.c
--- function.c	25 Jul 2003 09:52:25 -0000	1.449
+++ function.c	4 Aug 2003 13:54:13 -0000
@@ -62,6 +62,7 @@ Software Foundation, 59 Temple Place - S
  #include "tm_p.h"
  #include "integrate.h"
  #include "langhooks.h"
+#include "tree-inline.h"

  #ifndef TRAMPOLINE_ALIGNMENT
  #define TRAMPOLINE_ALIGNMENT FUNCTION_BOUNDARY
@@ -5539,6 +5540,24 @@ pad_below (struct args_size *offset_ptr,
      }
  }
  \f
+/* Is the tree, t, the expression x. */
+static tree
+contains_exp_1 (tree *t , int *walk_sub_trees, void *x)
+{
+  if (*t == x)
+    return t;
+  return NULL_TREE;
+}
+
+/* Does the tree, t, contain the expression x. */
+static bool
+contains_exp (tree t, tree x)
+{
+  if (walk_tree_without_duplicates ( &t, contains_exp_1, x))
+    return true;
+  return false;
+}
+
  /* Walk the tree of blocks describing the binding levels within a 
function
     and warn about uninitialized variables.
     This is done after calling flow_analysis and before global_alloc
@@ -5566,7 +5585,8 @@ uninitialized_vars_warning (tree block)

  	     We do not care about the actual value in DECL_INITIAL, so we do
  	     not worry that it may be a dangling pointer.  */
-	  && DECL_INITIAL (decl) == NULL_TREE
+	  && (DECL_INITIAL (decl) == NULL_TREE || contains_exp (DECL_INITIAL 
(decl), decl) )
  	  && regno_uninitialized (REGNO (DECL_RTL (decl))))
  	warning ("%H'%D' might be used uninitialized in this function",
                   &DECL_SOURCE_LOCATION (decl), decl);

Re: missed uninitialised variable warning

[Alexandre Oliva]

On Aug  4, 2003, Michael Matz <matz@suse.de> wrote:

>> and that it was actually undesirable, but hard to fix.

> Hmm, hard to fix ...  I don't know, the patch below does it for the easy
> 'x = x' case.

Cool.  I don't often like when someone misleads me, but I'm happy this
was not hard to fix, after all :-)

Unfortunately, a proper fix is not this simple.  We'd have to take
into account other uses of the variable, but not uses that simply take
its address.  Or do we already get that right?

> But I immediately withdraw it, as I like this feature ;-)

Ideally we should have an attribute to disable the warning.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: missed uninitialised variable warning

[Michael Matz]

Hi,

On 4 Aug 2003, Gabriel Dos Reis wrote:

> | Hmm, hard to fix ...  I don't know, the patch below does it for the easy
> | 'x = x' case.  But I immediately withdraw it, as I like this feature ;-)
>
> where were you when people argued with that? ;-)

I think I also argued for this feature.  ;-)

The patch catches only one certain instance of the whole recursive
initialization problem.  Namely it does not catch things like
"int i = g(i); int j = j + 1;" , i.e. any more complicated expression than
the var itself.


Ciao,
Michael.

Re: missed uninitialised variable warning

[Gabriel Dos Reis]

Michael Matz <matz@suse.de> writes:

| > and that it was actually undesirable, but hard to fix.
| 
| Hmm, hard to fix ...  I don't know, the patch below does it for the easy
| 'x = x' case.  But I immediately withdraw it, as I like this feature ;-)

where were you when people argued with that? ;-)

-- Gaby

Re: missed uninitialised variable warning

[Michael Matz]

Hi,

On 4 Aug 2003, Alexandre Oliva wrote:

> > That's a feature.
>
> Not really.  At some point I thought it was, and even argued for it,

I darkly remember.

> but then I was convinced with hard data that it was just a bug that
> I'd happened to take for a feature,

I don't remember this, though.

> and that it was actually undesirable, but hard to fix.

Hmm, hard to fix ...  I don't know, the patch below does it for the easy
'x = x' case.  But I immediately withdraw it, as I like this feature ;-)


Ciao,
Michael.
Index: function.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.449
diff -u -p -r1.449 function.c
--- function.c	25 Jul 2003 09:52:25 -0000	1.449
+++ function.c	4 Aug 2003 13:05:23 -0000
@@ -5566,7 +5566,7 @@ uninitialized_vars_warning (tree block)

 	     We do not care about the actual value in DECL_INITIAL, so we do
 	     not worry that it may be a dangling pointer.  */
-	  && DECL_INITIAL (decl) == NULL_TREE
+	  && (DECL_INITIAL (decl) == NULL_TREE || DECL_INITIAL (decl) == decl)
 	  && regno_uninitialized (REGNO (DECL_RTL (decl))))
 	warning ("%H'%D' might be used uninitialized in this function",
                  &DECL_SOURCE_LOCATION (decl), decl);

Re: missed uninitialised variable warning

[Alexandre Oliva]

On Aug  4, 2003, Michael Matz <matz@suse.de> wrote:

> On Sun, 3 Aug 2003, Andrew Morton wrote:

>> int foo(void)
>> {
>> int i = i;
>> return i;
>> }

> That's a feature.

Not really.  At some point I thought it was, and even argued for it,
but then I was convinced with hard data that it was just a bug that
I'd happened to take for a feature, and that it was actually
undesirable, but hard to fix.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                 aoliva@{redhat.com, gcc.gnu.org}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: missed uninitialised variable warning

[Andrew Morton]

Michael Matz <matz@suse.de> wrote:
>
> Hi,
> 
> On Sun, 3 Aug 2003, Andrew Morton wrote:
> 
> > int foo(void)
> > {
> > 	int i = i;
> > 	return i;
> > }
> 
> That's a feature.  GCC doesn't warn about such self-initialization.  It's
> used to silence GCC warnings in code where the user knows, that the
> variable isn't used uninitialized,

What a perfectly terrible idea that was.

> without generating any code, which
>   int i = 0;
> would do.  There was a proposal to implement that feature with some
> attribute and get rid of the above special meaning for that syntax (which
> I quite like btw ;-))  I don't know if the status of that.

It would be nice.  I'm aware of two bugs across the development of the 2.5
kernel which would not have occurred but for this gcc problem.

Re: missed uninitialised variable warning

[Michael Matz]

Hi,

On Sun, 3 Aug 2003, Andrew Morton wrote:

> int foo(void)
> {
> 	int i = i;
> 	return i;
> }

That's a feature.  GCC doesn't warn about such self-initialization.  It's
used to silence GCC warnings in code where the user knows, that the
variable isn't used uninitialized, without generating any code, which
  int i = 0;
would do.  There was a proposal to implement that feature with some
attribute and get rid of the above special meaning for that syntax (which
I quite like btw ;-))  I don't know if the status of that.


Ciao,
Michael.

missed uninitialised variable warning

[Andrew Morton]

gcc-3.2 doesn't warn about this:

int foo(void)
{
	int i = i;
	return i;
}

it can occur sometimes in macros.  Fixable?