[PATCH] Fix warnings from gcc 4.1.1

[PATCH] Fix warnings from gcc 4.1.1

[Pavel Roskin]

From: Pavel Roskin <proski@gnu.org>

These warnings are reported for every file:
lib.h: In function 'add_symbol':
lib.h:171: warning: value computed is not used
lib.h: In function 'add_statement':
lib.h:176: warning: value computed is not used
lib.h: In function 'add_expression':
lib.h:181: warning: value computed is not used

That's the way new versions of gcc warn about values that are cast to a
type but not used.

The cast in add_ptr_list_tag() is not really needed.  Its return value
is used only in one place (add_pseudo) where it's converted to (void *)
anyway.

Signed-off-by: Pavel Roskin <proski@gnu.org>
---

 ptrlist.h |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/ptrlist.h b/ptrlist.h
index b42a0ca..7a786cb 100644
--- a/ptrlist.h
+++ b/ptrlist.h
@@ -46,7 +46,7 @@ extern int linearize_ptr_list(struct ptr
  * extensions..
  */
 #define add_ptr_list_tag(list,entry,tag) \
-	(TYPEOF(*(list))) (CHECK_TYPE(*(list),(entry)),__add_ptr_list((struct ptr_list **)(list), (entry), (tag)))
+	(CHECK_TYPE(*(list),(entry)),__add_ptr_list((struct ptr_list **)(list), (entry), (tag)))
 #define add_ptr_list(list,entry) \
 	add_ptr_list_tag(list,entry,0)
 #define free_ptr_list(list) \

Re: [PATCH] Fix warnings from gcc 4.1.1

[Linus Torvalds]

On Sat, 8 Jul 2006, Pavel Roskin wrote:
> 
> These warnings are reported for every file:
> lib.h: In function 'add_symbol':
> lib.h:171: warning: value computed is not used

Please send a bug-report to the gcc people instead.

The code is correct, and the warning is bogus.

> That's the way new versions of gcc warn about values that are cast to a
> type but not used.

Yeah, and it's crap. The cast exists because we don't want to lose the 
type knowledge. Removing the cast would be wrong.

The fact that gcc warns about 

	(cast) a;

but does not warn about

	a;

is a sign of a gcc _bug_, and total insanity. The value is equally ignored 
in both cases.

> The cast in add_ptr_list_tag() is not really needed.  Its return value
> is used only in one place (add_pseudo) where it's converted to (void *)
> anyway.

Actually, _that_ is a bug.

The whole point of the cast is to not use a "void *", when we actually 
know exactly what kind of pointer the result is, and we want to do proper 
type-checking.

For example, when you do an "add_pseudo()", the return value should be a 
pointer to a pseudo_t.

So the declaration for "add_pseudo()" should be

	static inline pseudo_t *add_pseudo(struct pseudo_list **list, pseudo_t pseudo)

and we should never have cast it to "void *" since we know damn well what 
the result should be.

		Linus

Re: [PATCH] Fix warnings from gcc 4.1.1

[Linus Torvalds]

On Sat, 8 Jul 2006, Linus Torvalds wrote:
> 
> Please send a bug-report to the gcc people instead.
> 
> The code is correct, and the warning is bogus.

Ahhah.

I figured out a way to get gcc to not complain about it.

Making it a statement expression shuts gcc up about the unused result.

Damn gcc. But this patch _should_ fix things... (it also fixes 
"add_pseudo()" to return the proper type rather than silently drop the 
type information on the floor with "void *").

Does this silence the bogus compiler warnings for you?

		Linus

----
diff --git a/linearize.h b/linearize.h
index 5f021a3..66a76dc 100644
--- a/linearize.h
+++ b/linearize.h
@@ -237,7 +237,7 @@ static inline void add_multijmp(struct m
 	add_ptr_list(list, multijmp);
 }
 
-static inline void *add_pseudo(struct pseudo_list **list, struct pseudo *pseudo)
+static inline pseudo_t *add_pseudo(struct pseudo_list **list, pseudo_t pseudo)
 {
 	return add_ptr_list(list, pseudo);
 }
diff --git a/ptrlist.h b/ptrlist.h
index b42a0ca..719f437 100644
--- a/ptrlist.h
+++ b/ptrlist.h
@@ -15,6 +15,7 @@ #define DECLARE_PTR_LIST(listname,type)	
 #define CHECK_TYPE(head,ptr)		(void)(&(ptr) == &(head)->list[0])
 #define TYPEOF(head)			__typeof__(&(head)->list[0])
 #define VRFY_PTR_LIST(head)		(void)(sizeof((head)->list[0]))
+#define MKTYPE(head,expr)		({ (TYPEOF(head))(expr); })
 
 #define LIST_NODE_NR (29)
 
@@ -46,7 +47,7 @@ extern int linearize_ptr_list(struct ptr
  * extensions..
  */
 #define add_ptr_list_tag(list,entry,tag) \
-	(TYPEOF(*(list))) (CHECK_TYPE(*(list),(entry)),__add_ptr_list((struct ptr_list **)(list), (entry), (tag)))
+	MKTYPE(*(list), (CHECK_TYPE(*(list),(entry)),__add_ptr_list((struct ptr_list **)(list), (entry), (tag))))
 #define add_ptr_list(list,entry) \
 	add_ptr_list_tag(list,entry,0)
 #define free_ptr_list(list) \

Re: [PATCH] Fix warnings from gcc 4.1.1

[Pavel Roskin]

On Sat, 2006-07-08 at 11:14 -0700, Linus Torvalds wrote:
> Actually, _that_ is a bug.

Indeed, that's a bug number 26632:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632

Nobody is arguing that it's a feature.

The warning is gone from sparse.  Thank you!

-- 
Regards,
Pavel Roskin

Re: [PATCH] Fix warnings from gcc 4.1.1

[Morten Welinder]

> Indeed, that's a bug number 26632:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632
> Nobody is arguing that it's a feature.

That's a bit too optimistic in my reading.  As I read it, they
want to keep the warning for explicit casts, but drop it for
casts that the gcc front end decides to insert itself.

I'm sure they mean well, but this warning is getting in the way
of lots of people doing stuff with macros.

M.

Re: [PATCH] Fix warnings from gcc 4.1.1

[Pavel Roskin]

On Mon, 2006-07-10 at 15:13 -0400, Morten Welinder wrote:
> > Indeed, that's a bug number 26632:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26632
> > Nobody is arguing that it's a feature.
> 
> That's a bit too optimistic in my reading.  As I read it, they
> want to keep the warning for explicit casts, but drop it for
> casts that the gcc front end decides to insert itself.

Now I understand why 27825 is a duplicate of 26632!

> I'm sure they mean well, but this warning is getting in the way
> of lots of people doing stuff with macros.

OK, I didn't search well enough.  This issue is bug 24900, which is
marked "WONTFIX".  It's interesting that the statement expression is
proposed as a workaround - exactly what Linus did!

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

The argument that statement expressions are not portable has been
ignored so far.

-- 
Regards,
Pavel Roskin