This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/25399] Another bogus 'clobbered by longjmp' message
- From: "pinskia at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 13 Dec 2005 23:03:43 -0000
- Subject: [Bug middle-end/25399] Another bogus 'clobbered by longjmp' message
- References: <bug-25399-1620@http.gcc.gnu.org/bugzilla/>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Comment #4 from pinskia at gcc dot gnu dot org 2005-12-13 23:03 -------
(In reply to comment #3)
> (In the original example) note the bit vectors at beginning and end of blocks
> show 120 as live throughout the loop, although it isn't really. That's why I
> think it affects register pressure. GRA does do some munging of those bit
> vectors though, maybe it fixes this.
And the reason why it is done that way is because it is used uninitialized and
with
zero_extract. Now if we do some live analysis at the tree level and find out
that the
union is only set/used in the loop, we should be able to emit the set r120 in
the loop
when expanding (but we currently don't).
Hmm, Actually I was wrong in saying that we get li r3, 0 inside the loop.
There is some missed optimizations here. First the following is not
simplified:
.....
(insn 14 12 15 (set (reg:SI 121)
(const_int 0 [0x0])) -1 (nil)
(nil))
(insn 15 14 0 (set (zero_extract:SI (reg/v:SI 120 [ u ])
(const_int 16 [0x10])
(const_int 0 [0x0]))
(reg:SI 121)) -1 (nil)
(nil))
into:
(set (reg:SI 120) (const_int 0))
if 120 is uninitialized. That will fix the issue fully for both of the issue.
Maybe not as it is only partly uninitailized as 120 is initialized after going
through the loop.
Maybe we need better optimizations with uninitialized pesdu registers at the
rtl level.
Currently we just put a (set r120 0) in the first BB.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25399