Fix warnings from gcc 4.1.1

From: Pavel Roskin <[email protected]>

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.

---

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

index b42a0ca..7a786cb 100644
@@ -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) \

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

The code is correct, and the warning is bogus.

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.

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

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

----

index 5f021a3..66a76dc 100644
@@ -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);
 }

index b42a0ca..719f437 100644
@@ -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) \

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

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.

Now I understand why 27825 is a duplicate of 26632!

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