[Bug rtl-optimization/24626] [4.1/4.2 Regression] internal compiler error: verify_flow_info failed

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #52 from dave at hiauly1 dot hia dot nrc dot ca  2006-01-15 02:37 -------
Subject: Re:  [4.1/4.2 Regression] internal compiler error: verify_flow_info
failed

> Almost no-one knows HPPA assembly these days. It completely puzzles me why you
> call the assembler output "wrong" if you're not specifically stating what
> you're expecting instead.  But then, I don't think it is useful to look at test

I did.  I said that I expected different registers to be used for
the variables "node" and "call_result".  However, with gcc 4.0 and
later, the variables are both placed in the same register "r3".  HP
cc, and gcc 3.3 and 3.4 use different registers.  The issue is
present in the RTL that I showed from the trunk.

I guess that I have stared at too much HPPA assembly.  I must admit
that x86 assembler is greek to me.

> cases reduced to reproduce an ICE to the point where you have uninitialized
> variables.  There is no such thing as "wrong code" if you're using
> uninitialized variables.  At worst, you have found a missing diagnostic AFAICT.

I don't agree.  Note that the function "F2" doesn't directly use the
value of "node".  It just passes its value to "after_node_func" and "T".
There is no information as to what these functions do with the value.
I could easily write implementations of "after_node_func" and "T"
that would cause "F2" to behaive differently between gcc 3.4 and 4.0
because the return from "after_node_func" changes the value of "node"
in "F2".  I can't do that if different storage is assigned to "node"
and "call_result".

Further, an uninitialized variable doesn't imply that the code can't
be wrong.  If you look at the documentation, you will see that the
warning is optional because GCC doesn't have enough information
to determine when the code might be correct despite appearing to
have an error.  I have to wonder about the no warning default in this
case as the lack of initialization is unambiguous.

A search of the C99 standard for "uninitialized" turned up no hits.
Thus, I would say GCC isn't allowed to assume the value of "node"
doesn't matter, and use it's storage for other purposes.

> I've tried hard enough to fix this bug and my patch from comment #39 is enough
> to fix the issue being discussed here.  I'm not going to look at this apparent
> new bug which can't possibly have anything to do with the problem that this PR
> was opened for.

Effort appreciated and I'm sure your patch fixes the ICE.  However, 
I also believe that gcc 4.0 and later generate wrong code for the
submitted testcase.  It's true that the submitter only complained
about the ICE, but I have to think that he also cares about the resulting
code ;)

Dave


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24626