Re: 3.3 error when inlining

[Michael S. Zick <mszick at goquest dot com>]

On Saturday 14 June 2003 02:56 pm, Jim Wilson wrote:
> Michael S. Zick wrote:
> > I think the following confirms that the problem is more extensive...
> > Use release-3.3, on x86 (for i686)...
> > Use the below modification of the test case...
> > Compile without any gcc options, other than: -S -g ...
> > Inspect output.s ...
> > Bingo - silent generation of unexpected (wrong?) code.
>
> I just tried this, and I don't see anything wrong with the output.
>
Perhaps your output includes a jump past the len++ right after the
compare instruction.
Mine only showed a "compare" followed by an "increment" no
conditional instruction that changes program flow based on the
result of the compare instruction.

Now, of course, one might argue "garbage in - garbage out" if that
jump into the body of a conditional at an inner level of structure is 
not allowed by the language.
But even if that is the case - 
doing such (garbage in - garbage out) without a warning isn't 
going to win many friends.

> Perhaps you are assuming that there is no optimization if you don't
> specify -O?  
> 
I tried to make my assumptions clear in the comments on the
test case.

> This is incorrect.  Look at the RTL dumps.  Some of the
> branches are generated and then optimized away, even though -O was not
> specified.  
> 
Don't know RTL - but I could see that the function had some
rewriting and optimization effects showing.
Thought also that I had mentioned it.

> The labels are not optimized away, but that is harmless,
> after all we aren't trying to optimize here.  This is a change from 2.95
> which didn't do any optimization at all when -O wasn't specified.
>
I also assumed that those compiler generated labels were not
from a random letter sequence generator.  That there was (at one 
time in the process) a relation between the labels and the structure
that was being labeled.
Not knowing the relationship was the reason my comments
at several points said "I suspect" rather than a stronger statement;
but it was the spelling of labels that I was looking at.

>
> Jim
Thanks for your time;
Sorry if my input was totally wrong.
Mike