On Tue, 8 Apr 2014, dw wrote:
> > The general bits seems like a big improvement, but what worries
> > me is the deleted text. For example, the aspects of "Explicit
> > Reg Vars" when *directly feeding an asm* and how to write them
> > to avoid the named registers being call-clobbered between
> > a
Hello world,
please find attached a patch for PR 59604.
The patch makes sure that, if -fno-range-check is specified,
using int on an overflowing boz constant yields the same
result for compile-time simplification and run-time
execution.
OK for trunk?
Thomas
2014-03-12 Thomas Koenig
Senthil Kumar Selvaraj schrieb:
This patch modifies AVR target's ASM spec to pass -mlink-relax to the
assembler if -mrelax is passed to the compiler driver. This was already
being passed on to the linker, this patch merely makes the assembler
also aware of it.
The corresponding patch in binutils
On Sat, Apr 12, 2014 at 7:04 AM, Svante Signell
wrote:
>
> (cd src/libgo;automake-1.11)
> aclocal.m4:16: warning: this file was generated for autoconf 2.64.
> You have another version of autoconf. It may work, but is not
> guaranteed to.
To rebuild any of the GCC configuration generated files, y
On Sat, 2014-04-12 at 16:04 +0200, Svante Signell wrote:
> On Fri, 2014-04-11 at 07:48 -0700, Ian Lance Taylor wrote:
> > On Fri, Apr 11, 2014 at 5:47 AM, Svante Signell
> > wrote:
> >
> > I don't understand this comment. The GCC libraries do still use
> > automake. I regularly use automake to
On Fri, 2014-04-11 at 07:48 -0700, Ian Lance Taylor wrote:
> On Fri, Apr 11, 2014 at 5:47 AM, Svante Signell
> wrote:
> >
> > Attached are patches to enable gccgo to build properly on Debian
> > GNU/Hurd on gcc-4.9 (4.9-20140406).
>
> Thanks. Will review after 4.9 has branched.
Thanks! Modified
Dear All,
I have upgraded this patch slightly to fix PR58085 as well. I would
judge this to be completely safe because the fixes depend on the new
bit flag for both PRs.
Bootstrapped and regtested on FC17/x86_64 - OK for 4.9 immediately and trunk?
Paul
2014-04-12 Paul Thomas
PR fortran/
On Sat, 12 Apr 2014, Dominique Dhumieres wrote:
> > This test, after the update on 4.8 in r209070 when the test-case was
> > modified substantially (not really covered by the ChangeLog entry) to be
> > identical to that on trunk, apparently takes a different route in the
> > fortran run-time libra
Richard Sandiford writes:
> Matthew Fortune writes:
>> Hi Catherine/Richard,
>>
>> I think there may be some impact on register move costs by introducing
>> this class.
>
> Yeah, I was worried about that too. I'm going to do some code comparison
> tests for SE and MIPS16 to see what happens.
OK
> This test, after the update on 4.8 in r209070 when the test-case was
> modified substantially (not really covered by the ChangeLog entry) to be
> identical to that on trunk, apparently takes a different route in the
> fortran run-time library on 4.8 compared to trunk. For 4.8, it requires
> more
On Fri, Apr 11, 2014 at 04:57:42PM -0700, Jerry DeLisle wrote:
> On 04/11/2014 04:31 PM, Tobias Burnus wrote:
> > Jerry DeLisle wrote:
> >> I plan to commit the following patch to 4.10, 4.9, 4.8, and 4.7.
> >>
> >> It is a partial revert of the patch to PR38199 which is an optimization of
> >> inte
On Wed, Apr 02, 2014 at 10:29:23PM +0200, Paul Richard Thomas wrote:
> 2014-04-12 Paul Thomas
>
> PR fortran/58771
> * trans.h : Add 'use_offset' bitfield to gfc_se.
> * trans-array.c (gfc_conv_expr_descriptor) : Use 'use_offset'
> as a trigger to unconditionally recalculate th
On Sat, 12 Apr 2014, Eric Botcazou wrote:
r209321
(for a patch accepted long ago, I guess it is better to leave a trace in
gcc-patches near the commit date)
Nope, see the doc, we have ChangeLog and gcc-cvs for this purpose.
Those don't point to the conversation in gcc-patches where the patch
> r209321
> (for a patch accepted long ago, I guess it is better to leave a trace in
> gcc-patches near the commit date)
Nope, see the doc, we have ChangeLog and gcc-cvs for this purpose.
--
Eric Botcazou
Matthew Fortune writes:
> Hi Catherine/Richard,
>
> I think there may be some impact on register move costs by introducing
> this class.
Yeah, I was worried about that too. I'm going to do some code comparison
tests for SE and MIPS16 to see what happens.
> Is it worth having mips_canonicalize_m
15 matches
Mail list logo