Re: PR c/30949 "incompatible pointer type" warning does not point to declaration

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Sat, 23 Aug 2008, Manuel López-Ibáñez wrote:

> Bootstrapped and regression tested on x86_64-unknown-linux-gnu with
> --enable-languages=all,ada
> 
> OK for trunk?
> 
> 2008-08-22  Manuel Lopez-Ibanez  <manu@gcc.gnu.org>
> 
> 	PR c/30949
> 	* c-typeck.c (convert_for_assignment): Give a note describing what
> 	was passed and what was expected.
> testsuite/
> 	* gcc.dg/pr30949.c: New.
> 	* gcc.dg/transparent-union-1.c: Update.
> 	* gcc.dg/cleanup-1.c: Update.
> 	* gcc.dg/assign-warn-2.c: Update.
> 	* gcc.dg/conv-2.c: Update.
> 	* gcc.dg/Wpointer-sign-pedantic.c: Update.
> 	* gcc.dg/Wpointer-sign-Wall.c: Update.
> 	* gcc.dg/assign-warn-1.c: Update.
> 	* gcc.dg/dfp/composite-type.c: Update.
> 	* gcc.dg/noncompile/20020213-1.c: Update.

This is OK if you verify that the message in the inform call within the 
macro definition does get properly extracted into gcc.pot when gcc.pot is 
regenerated.  (You do not need to check in the regenerated gcc.pot.)

I don't think this is really a full fix for the issue, in that the case at 
the bottom of convert_for_assignment where there is a hard error saying 
"incompatible type" could just as much do with such a note.  (The error 
rather than a pedwarn is where the compiler cannot do any plausible 
conversion at all, e.g. where one of the types is a structure or union.)  
I also don't know if C++ has any similar issues.

-- 
Joseph S. Myers
joseph@codesourcery.com