http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #12 from Manuel López-Ibáñez 2013-03-27
20:37:05 UTC ---
That was the intention, if the comment or the behaviour does not match this,
then I did a mistake implementing it, and it is a bug in my opinion.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #11 from Paolo Carlini 2013-03-27
20:30:36 UTC ---
Ok, thanks a lot again. Then however we have to tweak a bit that comment too
(it only mentions warnings for true, instead means any diagnostics is actually
reported (that's mu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #10 from Manuel López-Ibáñez 2013-03-27
20:24:47 UTC ---
No, true means something was reported (error or warning), false means that
nothing was reported. The same as for pedwarn and warning. pedwarn also returns
true for --pedantic-e
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #9 from Paolo Carlini 2013-03-27
19:52:57 UTC ---
Ok, thanks! Thus, if I remember correctly that comment (true meaning warning),
looks like we want everywhere if (!permerror...) inform(... right? Otherwise if
I misremembering,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #8 from Manuel López-Ibáñez 2013-03-27
19:48:21 UTC ---
(In reply to comment #7)
> manuel@gcc10:~$ ~/test1/195333/build/gcc/cc1plus test.cc -fpermissive
> test.cc:4:5: note: initializing argument 3 of ‘int callf(int, int, int
> (*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #7 from Manuel López-Ibáñez 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #6 from Paolo Carlini 2013-03-27
19:28:09 UTC ---
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 behav
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #5 from Manuel López-Ibáñez 2013-03-27
17:43:02 UTC ---
(In reply to comment #4)
> Hi Manuel. I wanted to actually handle this per your indications and move on,
> but I don't understand why you check the return value of permerror: sh
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
Paolo Carlini changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unas
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #2 from Manuel López-Ibáñez 2013-03-25
23:03:42 UTC ---
Note that there are a fair amount of calls like these in the C++ FE, and the
use is inconsistent. I guess the indentation predates the use of inform, and
this is why there are s
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
--- Comment #3 from Manuel López-Ibáñez 2013-03-25
23:07:00 UTC ---
BTW, in this case, I find the output of g++ much better than that of clang++
test.cc:7:10: error: no matching function for call to 'callf'
return callf (23, 72,
^~~~
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56725
Manuel López-Ibáñez changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
13 matches
Mail list logo
