> The newly built gfortran must be stomping on memory. I've found that
> attached patch allows gfortran to still function. Could someone who
> sees this problem try bootstrapping gfortran with the patch?
gfortran bootstrapped OK with this patch on ppc64 r126353.
Thanks,
Revital
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> On Jul 8, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>
> > But since these aspects of the register allocator are not at all
> > likely to change, wouldn't it be a waste of time to prepare for them
> > now?
>
> Yup. But from that to concludin
> The newly built gfortran must be stomping on memory. I've found that
> attached patch allows gfortran to still function. Could someone who
> sees this problem try bootstrapping gfortran with the patch?
I will try it.
Revital
On Jul 8, 2007, Kenneth Zadeck <[EMAIL PROTECTED]> wrote:
> To be even more blunt, I never viewed no_new_pseudos as a useful abstraction
> It was a gate that protected a set of badly designed concrete
> datastructures.
I can appreciate that this is a valid point of view for the
implementation of
On Jul 8, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> But since these aspects of the register allocator are not at all
> likely to change, wouldn't it be a waste of time to prepare for them
> now?
Yup. But from that to concluding that we should remove the clear
abstraction that enables
Dorit sent me a copy of the libgfortran/config.log on
her failing system. In looking through the log, I've
found (note, I've paths to ABC, XYZ for shortness):
configure:11335: checking if ABC/./gcc/gfortran -BABC/./gcc/ -BXYZ/bin/
-BXYZ/lib/ -isystem XYZ/include -isystem XYZ/sys-include suppo
On 7/7/07 7:04 AM, [EMAIL PROTECTED] wrote:
> If you ask nicely they would let you use CIL's code in GCC ;) .
Any specific reasons why we should? Better memory savings? Faster
processing? It's not clear from your message what the advantages would
be (ignoring the fact that their implementation
Ian Lance Taylor wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>
>
>> See why imprecise abstractions are a problem, and why lowering
>> abstractions just because it's possible ATM, without any performance
>> or maintainability gains to justify them, is a losing proposition in
>> the long
On 7/8/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
On Sun, 8 Jul 2007, Richard Guenther wrote:
> So type-generic is supposed to apply to scalar floating point types
> only?
So far, yes.
I don't see anything that requires or prohibits changing that for the
initial implementation. If later a
On Sun, 8 Jul 2007, Richard Guenther wrote:
> So type-generic is supposed to apply to scalar floating point types
> only?
So far, yes.
I don't see anything that requires or prohibits changing that for the
initial implementation. If later a GCC developer wants to change it to
not promote e.g. ch
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> See why imprecise abstractions are a problem, and why lowering
> abstractions just because it's possible ATM, without any performance
> or maintainability gains to justify them, is a losing proposition in
> the long run?
To be blunt: no, I don't. I s
On 7/8/07, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
On Sat, 7 Jul 2007, Joseph S. Myers wrote:
> No, that's something else entirely (a "float" old-style parameter
> declaration corresponds to a "double" argument in a prototype). It's
> convert_arguments that handles converting to prototype typ
On Jul 6, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> That's why it seems so odd to me to want to get rid of the port uses
>> and not replace it with something directly equivalent. I just don't
>> see how it qualifies as a clean-up. I thi
13 matches
Mail list logo
