------- 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
