http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #7 from Manuel López-Ibáñez <manu at gcc dot gnu.org> 2013-03-27
19:46:57 UTC ---
(In reply to comment #6)
> I haven't tested anything so far, but stared a bit at the comment before
> permerror and figured tgat in case of plain error (vs warning) the function
> returns false thus the behavior would change. Besides that, empirically, I see
> around in the front end permerrors folliwed unconditionally by informs
> (actually that observation came first ;)
manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc
int docall()
test.cc:9:18: error: invalid conversion from ‘int (*)(int*)’ to ‘int
(*)(double*)’ [-fpermissive]
f);
^
test.cc:4:5: error: initializing argument 3 of ‘int callf(int, int, int
(*)(double*))’ [-fpermissive]
int callf (int, int, int (*)(double *));
^
manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive
[..the same but two warnings..]
manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive -w
[nothing]
so if you change the second permerror to inform, and don't check the output of
permerror and fn == true, then with -fpermissive -w you get:
manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive
test.cc:4:5: note: initializing argument 3 of ‘int callf(int, int, int
(*)(double*))’
int callf (int, int, int (*)(double *));
^
which doesn't make much sense. I added a bool return value to permerror for
this reason. error() doesn't return bool because you cannot silence it.
