This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Bug in C++ tree inlining or in PPC backend?


Am Sun, 02 Jan 2000 schrieb Mark Mitchell:
>Franz --
>
>  I'm going to have a hard time doing anything with your test case
>because of its size.  I don't have PPC hardware, which makes it even
>more difficult.  I know these kinds of problems tend to go away when
>the test-cases get smaller, but I bet you can shrink it a little bit,
>at least, and that would help.

Well, that's the shrinked version already :-). I'll try to convert it into a
library-free version (though the library stuff has no influence here).

>  The thing to do, painful as it is (and I know because I've done it)
>is to stare at the assembly code until you can see that *this* value
>right *here* is wrong.  You can work back from the first point there
>is observably incorrect output.  For instance, in your case, something
>is going wrong in the calculation of the length of `z' in the
>iostreams code.  So, first see whether `z' contains the right string
>or not.  Then, see where and how the length is being calculated and
>see what goes wrong.  Eventually you'll find that thus-and-such stack
>slot is being clobbered, but the value is still needed.  Then, you can
>track down why the compiler is doing that.

Hmm, let me ask differently, do you see any possibility that the C++ tree
inlining code causes this directly? Like not setting some memory attributes
correctly? Or do you think it's a general bug in the middle/backend? Currently
I'm just trying to leave some parts of the compiler aside and to focus on
others to ease debugging and code browsing, cause I believe the bug happens
prior to the first RTL dump and I'm not very familiar with these parts of the
compiler :-(. Anyway, I'll continue debugging this.

>  The fact that your patch fixes the problem is peculiar.  If I read
>it right, you're saying that -fstrict-aliasing helps in that it
>prevents stack slots from being reused (because we never taught the
>aliasing code about stack-slot lifetimes).

Exactly, at least as far as I understand the aliasing code yet.

Franz.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]