Tom Tromey <[EMAIL PROTECTED]> writes: > I'm not certain that this is the tradeoff I prefer, but I haven't > exactly done a survey of what diagnostics are emitted where. My > general worry is that these more distant (from the FE) diagnostics > will also be the ones where having good location information would be > the most useful.
As Chris and others have argued, we can do uninitialized warnings in the frontend. It has a downside: Chris commented that the optimizers can emit confusing uninitialized warnings with many layers of inlining. I've seen that myself. But I've seen correct warnings that way--the variable really was uninitialized. So moving the warnings to the tradeoff has a simple tradeoff: you miss some correct warnings. The warnings we can not do in the frontend are the warnings about aliasing violations and reliance on undefined overflow. At least, I don't see any way to do those reliably without using the optimization machinery. I think most other warnings could move to the frontend if we so desired. I agree in general that for middle-end warnings having good location information is useful. The problem is that for warnings like the undefined overflow warnings good location information is quite difficult. As you know the optimizers can pull together information from all over the place. The actual warning can be issued for code which looks very different from anything the user actually wrote. Translating back to the problem in the user code can be complicated. I don't think gcc is going to be able to do that translation. Ian
