Hi again,
On 05/22/2012 06:42 PM, Jason Merrill wrote:
On 05/22/2012 11:55 AM, Paolo Carlini wrote:
FAIL: gcc.dg/opts-1.c (internal compiler error)
FAIL: gcc.dg/opts-1.c -fno-abi-version (test for errors, line )
FAIL: gcc.dg/opts-1.c -fno-lto-compression-level (test for errors,
line )
FAIL: gcc.dg/opts-1.c -fno-tree-parallelize-loops (test for errors,
line )
FAIL: gcc.dg/opts-1.c -Wno-strict-overflow (test for errors, line )
FAIL: gcc.dg/opts-1.c -Wno-strict-aliasing (test for errors, line )
FAIL: gcc.dg/opts-1.c (test for excess errors)
FAIL: gcc.dg/opts-5.c (internal compiler error)
FAIL: gcc.dg/opts-5.c (test for errors, line )
FAIL: gcc.dg/opts-5.c (test for excess errors)
FAIL: gcc.dg/opts-6.c (internal compiler error)
FAIL: gcc.dg/opts-6.c (test for errors, line )
FAIL: gcc.dg/opts-6.c (test for excess errors)
That all looks like diagnostics about options that don't work properly
together, much like the objc issues. I think it makes sense to switch
all such diagnostics over to BUILTINS_LOCATION, because we do know the
location of the thing we're complaining about: it's on the command line.
Uhhm, I have an "out of the blue" idea, so please excuse me if for some
"obvious" reason doesn't make sense: don't we have a global variable
saying "where we are" in the compiler pipeline? If we have one, it would
seem to me pretty neat to assert that *a front end* cannot pass
UNKNOWN_LOCATION to warning_at, error_at and the like. I think it would
work also for objc, because, AFAICS, the warning_at are in the runtime
(and in that specific case we know how to handle the problem anyway)
Paolo.
