Hi,
On 05/17/2012 10:29 PM, Iain Sandoe wrote:
On 17 May 2012, at 21:16, Mike Stump wrote:
On May 17, 2012, at 12:53 PM, Paolo Carlini wrote:
On 05/17/2012 09:47 PM, Jason Merrill wrote:
On 05/17/2012 05:06 AM, Paolo Carlini wrote:
On 05/17/2012 10:33 AM, Gabriel Dos Reis wrote:
I am still puzzled by why we need to assert, as opposed to just
ignore, unless we have a plan to make a wholesale move -- but
even there I am bit
nervous.
Eh, don't ask me ;) Anyway, in terms of testing that we aren't
screwing
up anything in the C++ front-end, the testsuite just passed with the
below p3 attached. That's good.
Yep, that's what the assert is for: testing that we aren't screwing
up anything in the C++ front end. If it fires, it lets us know
there's something still to fix. Sounds like it looks good so far.
If you like, I can install p3 now, but I think it would be a pity if
we can't have the warning_at bit because of that lone use in the
ocbj front-end of an explicit 'warning_at (0' (in
objc-gnu-runtime-abi-01.c). Maybe Mike has something to suggest?
Gosh, I'm not wedded to even having that warning. :-) The compiler
knows what it has to do for codegen, it can eat and ignore the flag
silently for all I care. I'd ask Nicola or Iain if they have any
thoughts.
One could also reasonably use:
inform (UNKNOWN_LOCATION, "");
for it, if that helps.
For my part, I'd prefer inform (UNKNOWN_LOCATION as is used below ..
and, hopefully everywhere else, where new stuff has been introduced.
Ok, thanks. Today I wanted to concretely test and post a patch but I
noticed this other objc bit in objc-next-runtime-abi-01.c which I don't
know how to handle due to the OPT_Wall gate:
warning_at (UNKNOWN_LOCATION, OPT_Wall,
"%<-fobjc-sjlj-exceptions%> is the only supported exceptions "
"system for %<-fnext-runtime%> with %<-fobjc-abi-version%> < 2");
If the objc maintainers could help with those uses of warning_at (0 in
the objc tree, I have a patch ready for the asserts proper.
Thanks,
Paolo.
