Re: compiler bug turning up in cmake package?

[John Fine <johnsfine@xxxxxxxxxxx>]

Matthew Woehlke wrote:
> . CC'ing gcc-help one last time so those folk know it's resolved, but 
> I imagine we can drop them from any future correspondence.
Maybe gcc-help should get a bit more of a comment on the small "almost a 
bug" that caused the fault on line 888 to be misreported as line 787.

In general in optimized code there is no way to correctly match machine 
instructions to source lines.  But in this particular case, a bit more 
book keeping in GCC could have matched it.

The optimizer has almost fully merged the this->Internal->GetFileType() 
calls on lines 787, 887 and 888.

The machine instruction at _ZN5cmELF8GetRPathEv+15 is actually all three 
of those and thus cannot be correctly tied to its source line.

But the machine instruction at _ZN5cmELF8GetRPathEv+80 (the one that 
faulted) represents only line 888 (and in fact only when 888 is reached 
without executing 887).  That instruction could be attributed correctly 
to source line 888 rather than incorrectly to 787.

I assume (without digging into the relevant gcc source code) that in the 
process of merging the this->Internal->GetFileType() on line 888 with 
the one on 787 and then unmerging the two paths into line 888, gcc has 
lost track of the fact that one path into 888 is not actually merged 
with 787.

While it is impossible to consistently attribute such faults to the 
correct source line, it is always nicer to correctly attribute the ones 
that could be correctly attributed.

Also, where the optimizer has done enough data flow analysis (as it must 
have to rearrange this way) to know for certain that a particular 
machine instruction will always be dereferencing null, maybe there ought 
to be some warning or other special behavior.  (Line 888 doesn't always 
dereference null, but once the two paths to 888 have been split, there 
is machine code generated that the optimizer should know must fault).