Daniel Jacobowitz wrote:
Hey Bernd,
Has there been any news or progress on reload-branch lately? It
removes a lot of code that I'd dearly love to see gone...
Unfortunately not. I just don't have the time to work on too many extra
projects at the moment :-( Of course, others could always vo
On Fri, Mar 18, 2005 at 07:15:11PM +0100, Bernd Schmidt wrote:
> Jeffrey A Law wrote:
> >On Fri, 2005-01-21 at 17:50 +0100, Giovanni Bajo wrote:
> >
> >>Why not putting it on a branch? If you are going to finish and submit it
> >>for
> >>4.1, it might be easier to use CVS.
> >
> >It might also be
Bernd Schmidt <[EMAIL PROTECTED]> wrote on 11.04.2005 14:43:38:
>* reload.c (find_reloads): Only set INC field if we know we have an
>autoinc reload.
Yes, this helps for s390. With the current reload-branch, and just my
scan_rtx patch on top, I was able to bootstrap and run the test suit
I guess the best solution is to change the place you modified, but to
use a test that checks for autoinc codes. I'll come up with something.
Try this.
Bernd
* reload.c (find_reloads): Only set INC field if we know we have an
autoinc reload.
* reload.h (struct reload): Update comment to match.
Ulrich Weigand wrote:
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html
there is a code path in find_reloads that sets rld[].inc to a
nonzero value even for a platform that doesn't actually *have*
pre-/post-increment insns, leading to an ICE later on.
Index: gcc/reload.c
Bernd Schmidt <[EMAIL PROTECTED]> wrote on 03/20/2005 07:41:14 PM:
> This is OK. Would you check it in?
Done, thanks.
Mit freundlichen Gruessen / Best Regards
Ulrich Weigand
--
Dr. Ulrich Weigand
Linux for S/390 Design & Development
IBM Deutschland Entwicklung GmbH, Schoenaicher Str. 2
Ulrich Weigand wrote:
- As mentioned in http://gcc.gnu.org/ml/gcc/2005-01/msg00911.html
there is a code path in find_reloads that sets rld[].inc to a
nonzero value even for a platform that doesn't actually *have*
pre-/post-increment insns, leading to an ICE later on.
The patch below simply
Bernd Schmidt wrote:
I have created a new branch, "reload-branch", on which I'm going to
check in these changes.
Thanks - very important first step to make reload "the preferred way to
distribute the software" :-) AKA as complying to the GPL.
--
Toon Moene - e-mail: [EMAIL PROTECTED] - phone:
Giovanni Bajo wrote:
What is your plan for this branch? Is there more code refactoring/rewriting
planned, or are you just going to give it a wider testing and fix fallout bugs,
in preparation for a merge?
There's one known design flaw wrt. to enble_optional/disable_optional,
and I think autoinc re
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>>> It might also be easier for those of us who want to play with the
>>> code, without having to find a suitable sync point between the
>>> patch and
>>> mainline sources.
>>
>> I have created a new branch, "reload-branch", on which I'm going to
>> check i
Bernd Schmidt wrote:
> I have created a new branch, "reload-branch", on which I'm going to
> check in these changes.
Thanks!
With three changes described below, I'm able to bootstrap and test the
reload-branch on s390-ibm-linux and s390x-ibm-linux without regressions
against head (except two ad
Jeffrey A Law wrote:
On Fri, 2005-01-21 at 17:50 +0100, Giovanni Bajo wrote:
Why not putting it on a branch? If you are going to finish and submit it for
4.1, it might be easier to use CVS.
It might also be easier for those of us who want to play with the code,
without having to find a suitable syn
12 matches
Mail list logo
