Martin Michlmayr wrote:
* Paolo Carlini <[EMAIL PROTECTED]> [2006-05-22 22:37]:
Of course, it would be nice if reporters could double check that on
those machines gcc4.1.0 behaves the same.
I can confirm that the abi_check failure has gone away now that I have
generated the de_DE local
* Paolo Carlini <[EMAIL PROTECTED]> [2006-05-22 22:37]:
> Of course, it would be nice if reporters could double check that on
> those machines gcc4.1.0 behaves the same.
I can confirm that the abi_check failure has gone away now that I have
generated the de_DE locale.
This makes me wonder, though
Mark Mitchell wrote:
> Richard Sandiford wrote:
>
>> Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf.
>> Mark, what do you think?
>
> I'm a bit torn. On the one hand, it doesn't look like there is any
> other reason to do a 4.1.1 RC2. So, we could declare that Fortran is
> n
Mark Mitchell wrote:
Martin Michlmayr wrote:
* Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
I'm a bit torn. On the one hand, it doesn't look like there is any
other reason to do a 4.1.1 RC2.
Did anyone investigate those abi_check failures I (and others) have
seen? Se
Martin Michlmayr wrote:
> * Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
>> I'm a bit torn. On the one hand, it doesn't look like there is any
>> other reason to do a 4.1.1 RC2.
>
> Did anyone investigate those abi_check failures I (and others) have
> seen? See http://gcc.gnu.org/ml/gcc
* Mark Mitchell <[EMAIL PROTECTED]> [2006-05-22 11:36]:
> I'm a bit torn. On the one hand, it doesn't look like there is any
> other reason to do a 4.1.1 RC2.
Did anyone investigate those abi_check failures I (and others) have
seen? See http://gcc.gnu.org/ml/gcc-testresults/2006-05/msg01058.html
Richard Sandiford wrote:
> Tested against gcc-4_1-branch on mips64-linux-gnu and mipsisa64-elf.
> Mark, what do you think?
I'm a bit torn. On the one hand, it doesn't look like there is any
other reason to do a 4.1.1 RC2. So, we could declare that Fortran is
not release-critical, and just relea
Richard Sandiford <[EMAIL PROTECTED]> writes:
> Roger Sayle <[EMAIL PROTECTED]> writes:
>> On Fri, 19 May 2006, Mark Mitchell wrote:
>>> I'm evaluating the options. It would be helpful if someone has time to
>>> apply and test Richard's patch on 4.1, as that would let us know whether
>>> that opti
"Joseph S. Myers" <[EMAIL PROTECTED]> writes:
> The patch (both that on mainline and this backport) includes _floatdidf in
> both the hardcoded lib2funcs list and that generated from lists of modes.
> This means that only one of the _floatdidf entries in the list gets
> deleted if _floatdidf is
On Sun, 21 May 2006, Roger Sayle wrote:
> The patch applies cleanly, with the exception of some mklibgcc.in
> hunks, due to the fact that the _floatun* symbols were added to 4.2
> and aren't available in 4.1.x libgcc, and that the LIB2FUNCS_EXCLUDE
> functionality isn't on the branch. For the rec
Roger Sayle <[EMAIL PROTECTED]> writes:
> On Fri, 19 May 2006, Mark Mitchell wrote:
>> I'm evaluating the options. It would be helpful if someone has time to
>> apply and test Richard's patch on 4.1, as that would let us know whether
>> that option is viable as well.
>
> I've bootstrapped and regr
On Fri, 19 May 2006, Mark Mitchell wrote:
> I'm evaluating the options. It would be helpful if someone has time to
> apply and test Richard's patch on 4.1, as that would let us know whether
> that option is viable as well.
I've bootstrapped and regression tested a backport of Richard's patch
aga
Andrew Pinski <[EMAIL PROTECTED]> writes:
> If the back-end was not lying to the front-ends, this would never
> have been a problem, hint hint.
I'm not sure what you mean here. In what way is the back end lying
to the front end?
Richard
Roger Sayle <[EMAIL PROTECTED]> writes:
> Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS
> backend's use of the GOFAST libraries which is one of the major blockers
> of adding -msoft-float tests to the testsuite? :-)
No. As I've explained earlier this week, -msoft-float c
Andrew Pinski wrote:
>> Andrew Pinski wrote:
>>
>>> Also why revert a patch which obvious works in the default configurations?
>> It eliminates a Fortran problem, but causes a C problem.
>
> I thought it only caused the problem with C code when supplying -msoft-float
> which is not a default confi
>
> Andrew Pinski wrote:
>
> > Also why revert a patch which obvious works in the default configurations?
>
> It eliminates a Fortran problem, but causes a C problem.
I thought it only caused the problem with C code when supplying -msoft-float
which is not a default configuration?
It eliminate
Andrew Pinski wrote:
> Also why revert a patch which obvious works in the default configurations?
It eliminates a Fortran problem, but causes a C problem.
I'm evaluating the options. It would be helpful if someone has time to
apply and test Richard's patch on 4.1, as that would let us know whet
On Fri, 19 May 2006, Mark Mitchell wrote:
> > No, you can invoke it via using the attribute mode(TI)
> Sure, but I'm not worried about that case.
That would be the only class of C or C++ failures that I could easily
construct by hand. Although the RTL optimizers will introduce TImode
moves and t
On May 19, 2006, at 10:12 AM, Mark Mitchell wrote:
Andrew Pinski wrote:
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
Am I correct PR 22209 is "only" a Fortran problem? This is not a
rhetorical question; I'm trying to gather data
No, you can invoke it via using the attribute mode(TI
Andrew Pinski wrote:
>
> On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
>
>>
>> Am I correct PR 22209 is "only" a Fortran problem? This is not a
>> rhetorical question; I'm trying to gather data
>
> No, you can invoke it via using the attribute mode(TI)
Sure, but I'm not worried about that
On May 19, 2006, at 9:59 AM, Mark Mitchell wrote:
Am I correct PR 22209 is "only" a Fortran problem? This is not a
rhetorical question; I'm trying to gather data
No, you can invoke it via using the attribute mode(TI), yes people
are not going to do that but who knows.
-- Pinski
Roger Sayle wrote:
> Hi Mark and Richard,
>
> On Fri, 19 May 2006, Mark Mitchell wrote:
>> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
>> for MIPS on the GCC 4.1 branch?
>>
>> (My brain failed to digest the fact that the patch was on 4.1 as well as
>> on mainline, perhaps in
On Fri, 19 May 2006, Roger Sayle wrote:
> Indeed, no good deed ever goes unpunished. In fact, isn't it the MIPS
> backend's use of the GOFAST libraries which is one of the major blockers
The GOFAST support is almost certainly unused and can probably be removed;
at least, no-one has cared enough
Hi Richard,
On Fri, 19 May 2006, Richard Sandiford wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
> > (My brain failed to digest the fact that the patch was on 4.1 as well as
> > on mainline, perhaps in part because there doesn't seem to be a PR;
> > Richard indicated to me that he would loca
Hi Mark and Richard,
On Fri, 19 May 2006, Mark Mitchell wrote:
> Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change
> for MIPS on the GCC 4.1 branch?
>
> (My brain failed to digest the fact that the patch was on 4.1 as well as
> on mainline, perhaps in part because there doesn't s
Mark Mitchell <[EMAIL PROTECTED]> writes:
> (My brain failed to digest the fact that the patch was on 4.1 as well as
> on mainline, perhaps in part because there doesn't seem to be a PR;
> Richard indicated to me that he would locate or open one now.)
Opened as 27681. (And Roger: sorry for all th
Richard, Roger --
Roger, would you please revert your MIPS MIN_UNITS_PER_WORD change for
MIPS on the GCC 4.1 branch?
(My brain failed to digest the fact that the patch was on 4.1 as well as
on mainline, perhaps in part because there doesn't seem to be a PR;
Richard indicated to me that he would l
27 matches
Mail list logo
