I am pleased to announce that the GCC Steering Committee has appointed
Alex Coplan as a maintainer for the AArch64 load / store pair fusion
pass.
In addition the steering committee has also appointed him as
maintainer for the Pair Fusion pass in the target independent
portions.
Please join me in
I am pleased to announce that the GCC Steering Committee has appointed
Christophe Lyon as a MVE Reviewer for the AArch32 port.
Please join me in congratulating Christophe on his new role.
Christophe, please update your listings in the MAINTAINERS file.
Regards,
Ramana
On Mon, Nov 25, 2019 at 9:43 PM Andrew Dean wrote:
>
> > > >>> I get errors like this:
> > > >>>
> > > >>> aarch64-glibc-linux-gnu-gcc: fatal error: cannot read spec file
> > > >>> 'rdimon.specs': No such file or directory
> > > >>>
> > > >>> I can see that the rdimon.specs flag is added based on
On Mon, Nov 25, 2019 at 8:40 PM Adhemerval Zanella
wrote:
>
>
>
> On 25/11/2019 17:28, Andrew Dean via gcc wrote:
> >>> This completes successfully. However, when I then try to run the gcc
> >>> tests like
> >> so:
> >>> runtest --outdir . --tool gcc --srcdir /path/to/gcc/gcc/testsuite
> >>> aarc
Hi,
I'm pleased to announce that the GCC steering committee has appointed
Kyrylo Tkachov and Richard Sandiford as AArch64 maintainers.
Please join me in congratulating them both on their additional roles
in the community. Kyrill / Richard, please update your listings in the
MAINTAINERS file.
Tha
On Tue, Jul 2, 2019 at 1:38 PM Paul E. McKenney wrote:
>
> Once a user-created non-dependent pointer is assigned to, it is OK to
> break the dependency.
Ok, that's good.
>
> Or am I missing the point here?
I was just trying to make sure we were on the same page. I wonder if
marking this volatil
>>
>> It's worth figuring out what passes are doing this - however the worry
>> I have is that every pass now needs to be handling this case with
>> respect to pointer attributes. Is there some place that you are
>> storing said information and what is the transitive nature of
>> assignments with t
On Tue, Jul 2, 2019 at 1:29 AM Akshat Garg wrote:
>
> On Tue, Jun 25, 2019 at 9:49 PM Akshat Garg wrote:
>>
>> On Tue, Jun 25, 2019 at 4:04 PM Ramana Radhakrishnan
>> wrote:
>>>
>> [CCing gcc mailing list]
>>
>> So, shall I start looki
On Fri, Feb 15, 2019 at 1:16 PM Jakub Jelinek wrote:
>
> On Fri, Feb 15, 2019 at 02:12:27PM +0100, Richard Biener wrote:
> > On February 15, 2019 1:45:10 PM GMT+01:00, Hi-Angel
> > wrote:
> > >I never could understand, why field reordering was removed from GCC?
> >
> > The implementation simply
On Wed, Jan 9, 2019 at 9:50 AM Andrew Haley wrote:
>
> On 1/9/19 9:45 AM, Kyrill Tkachov wrote:
> > Hi Kay,
> >
> > On 09/01/19 08:29, Kay F. Jahnke wrote:
> >> Hi there!
> >>
> >> I am developing software which tries to deliberately exploit the
> >> compiler's autovectorization facilities by feed
On Thu, Nov 1, 2018 at 10:42 AM Joern Wolfgang Rennecke
wrote:
>
>
> On 30/10/18 08:36, Richard Biener wrote:
> > On Mon, Oct 29, 2018 at 7:03 PM Joern Wolfgang Rennecke
> > wrote:
> >> I want to submit some vectorizer patches, what would be a suitable
> >> regression test?
> > I am sure you have
On Fri, Jul 27, 2018 at 3:38 PM, Joseph Myers wrote:
> On Fri, 27 Jul 2018, Michael Matz wrote:
>
>> Using any python scripts as part of generally building GCC (i.e. where the
>> generated files aren't prepackaged) will introduce a python dependency for
>> distro packages. And for those distros t
On Thu, Jul 19, 2018 at 10:11 AM, Richard Biener wrote:
>
> Status
> ==
>
> The GCC 8 branch is frozen for preparation of the GCC 8.2 release.
> All changes to the branch now require release manager approval.
>
>
> Previous Report
> ===
>
> https://gcc.gnu.org/ml/gcc/2018-07/msg001
On Tue, Jul 17, 2018 at 10:41 AM, Umesh Kalappa
wrote:
> Hi Nagy,
>
> Please help us with your comments on the attached patch for the issue
> (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512)
>
> Thank you and waiting for your inputs on the same.
Patches should be sent to gcc-patc...@gcc.gnu
On Thu, Jun 7, 2018 at 10:35 AM, Richard Biener
wrote:
> On Thu, Jun 7, 2018 at 10:45 AM Ard Biesheuvel
> wrote:
>>
>> On 7 June 2018 at 10:21, Christoffer Dall wrote:
>> > On Thu, Jun 07, 2018 at 09:56:18AM +0200, Ard Biesheuvel wrote:
>> >> On 7 June 2018 at 09:48, Christoffer Dall
>> >> wro
On Tue, Jun 5, 2018 at 9:16 AM, Laszlo Ersek wrote:
> On 06/05/18 08:04, Ard Biesheuvel wrote:
>> On 4 June 2018 at 20:10, Laszlo Ersek wrote:
>>> Hi!
>>>
>>> Apologies if this isn't the right place for asking. For the problem
>>> statement, I'll simply steal Ard's writeup [1]:
>>>
KVM on AR
On Thu, Apr 12, 2018 at 10:50 PM, Thomas König wrote:
> Hello world,
>
> with Fortran 2018, recursive is becoming the default. This will likely
> have a serious impact on many user codes, which often declare large
> arrays which could then overflow stacks, leading to segfaults without
> further ex
I am pleased to announced that the GCC Steering Committee has
appointed Richard Sandiford as SVE maintainer in the AArch64 port.
Please join me in congratulating Richard on his additional role.
Richard, please update your listing in the MAINTAINERS file.
regards
Ramana
On Mon, Feb 26, 2018 at 10:45 PM, Ruslan Nikolaev via gcc
wrote:
> Thanks, everyone, for the output, it is very useful. I am just proposing to
> consider the change unless there are clear roadblocks. (Either design choice
> is probably OK with respect to the standard formally speaking, but there
On Fri, Sep 22, 2017 at 12:29 PM, Wilco Dijkstra wrote:
> Hi,
>
> You'll get GOT relocations to globals when you use -fpic:
>
> int x;
> int f(void) { return x; }
>>gcc -O2 -S -o- -fpic
>
> f:
> adrpx0, :got:x
> ldr x0, [x0, #:got_lo12:x]
> ldr w0, [x0]
>
On Sat, Sep 9, 2017 at 4:27 AM, nick wrote:
> Greetings All,
>
> I am interested in helping out with the gcc project. I understand there is a
> bugzilla I can get started on
> but is there anything else in terms of things I should be reading outside the
> core docs in the git tree
> and the docs
I'm pleased to announce that the steering committee has appointed
- James Greenhalgh as a full maintainer for the AArch64 port
and
- Kyrylo Tkachov as a full maintainer for the ARM port.
James & Kyrylo, if you could update your entries in the MAINTAINERS
file to reflect these roles, it would
On Wed, Jul 12, 2017 at 3:57 PM, Sandra Loosemore
wrote:
> On 07/12/2017 05:07 AM, Klaus Kruse Pedersen (Klaus) wrote:
>>
>> I have seen reproducible builds being discussed here, but what is the
>> position on inter c-lib and OS reproducible builds?
>
>
> I think we consider unstable sort problems
I am pleased to announce that the GCC Steering Committee has
appointed Andrew Burgess and Claudiu Zissulescu as reviewers for
the ARC port.
Please join me in congratulating Andrew and Claudiu on their new roles.
Claudiu / Andrew - please update your listing in the MAINTAINERS file.
Thanks,
Raman
I am pleased to announce that the GCC Steering Committee has
appointed Oliver Hainque as co-maintainer for the VxWorks port.
Please join me in congratulating Oliver on his new role.
Oliver, please update your listing in the MAINTAINERS file.
Thanks,
Ramana
>
> What happens in practice? GCC doesn't put functions in random
> partitions.
>
The data goes into a separate partition AFAIU - it means that all data accesses
are as though they are extern references which means there's not necessarily
any CSE'ing ability that's available with section anc
Hi Prathamesh,
Could you split out the ARM specific portions into a separate patch
please in a patch series?
>@deftypefn {Target Hook} void TARGET_EXPAND_DIVMOD_LIBFUNC (bool
>@var{unsignedp}, machine_mode @var{mode}, @var{rtx}, @var{rtx}, rtx
>*@var{quot}, rtx *@var{rem})
>Expand divmod libfun
On Thu, Dec 3, 2015 at 7:01 PM, Steve Ellcey wrote:
> Can the instruction scheduler actually rewrite instructions? I didn't
> think so but when I compile some code on MIPS with:
>
> -O2 -fno-ivopts -fno-peephole2 -fno-schedule-insns2
>
> I get:
>
> $L4:
> lbu $3,0($4)
>
On Thu, Nov 5, 2015 at 9:32 AM, Bernd Schmidt wrote:
> When reviewing patches I'm never quite sure which of the following we should
> be using:
>
> some_target_hook (tree decl, machine_mode mode ATTRIBUTE_UNUSED)
>
> some_target_hook (tree decl, machine_mode ARG_UNUSED (mode))
>
> some_target_hook
On Wed, Oct 7, 2015 at 6:22 PM, Joseph Myers wrote:
> On Wed, 7 Oct 2015, Jeff Law wrote:
>
>> I'm not sure why this attribute isn't documented, but clearly that should be
>> fixed.
>
> I assume the reasoning was: we document support for Cilk+ (and what's
> included in Cilk+ is externally document
On Wed, Sep 16, 2015 at 11:27 PM, Mike Stump wrote:
> On Sep 16, 2015, at 9:25 AM, Ramana Radhakrishnan
> wrote:
>>
>> Sorry about the obvious (possibly dumb) question.
>
>> Can't we just import a copy of dejagnu each year and install it as part of
>>
On Wed, Sep 16, 2015 at 6:06 PM, Frank Ch. Eigler wrote:
> Hi -
>
>> [...]
>> >- rewrite history - use some totally arbitrary, and quickly outdated,
>> >internet identity
>
>> I think this is main reason why @gnu.org or @gmail.com style addresses
>> are preferred over employer addresses when there
On 16/09/15 17:14, Mike Stump wrote:
> On Sep 16, 2015, at 12:29 AM, Andreas Schwab wrote:
>> Mike Stump writes:
>>
>>> The software presently works with 1.4.4 and there aren’t any changes
>>> that require anything newer.
>>
>> SLES 12 has 1.4.4.
>
> Would be nice to cover them as well, but th
On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner wrote:
> On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
>> Ramana Radhakrishnan writes:
>>
>> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
>> > wrote:
>> >> Teams following a differ
On Fri, Aug 21, 2015 at 4:09 PM, Peter Bergner wrote:
> On Fri, 2015-08-21 at 16:09 +0200, Andreas Schwab wrote:
>> Ramana Radhakrishnan writes:
>>
>> > On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
>> > wrote:
>> >> Teams following a differ
On Fri, Aug 21, 2015 at 3:09 PM, Andreas Schwab wrote:
> Ramana Radhakrishnan writes:
>
>> On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely
>> wrote:
>>> Teams following a different model could use a separate repo shared by
>>> those developers, not the gcc
On Fri, Aug 21, 2015 at 11:48 AM, Jonathan Wakely wrote:
> On 21 August 2015 at 11:44, Ramana Radhakrishnan wrote:
>>>
>>> Absolutely, a non-fast-forward push is anathema for anything other people
>>> might be working on. The git repository already prohibits this
>
> Absolutely, a non-fast-forward push is anathema for anything other people
> might be working on. The git repository already prohibits this; people that
> want to push-rebase-push their own branches need to delete the branch before
> pushing again.
On the FSF trunk and the main release branche
> Hi Marcus,
>
> On fsf-4.9 I see the test pass:
>
> PASS: gcc.target/arm/pr43920-2.c (test for excess errors)
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3
> Executing on host: arm-none-eabi-size pr43920-2.o (timeou
> On fsf-4.9 I see the test pass:
>
> PASS: gcc.target/arm/pr43920-2.c (test for excess errors)
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times pop 2
> PASS: gcc.target/arm/pr43920-2.c scan-assembler-times beq 3
> Executing on host: arm-none-eabi-size pr43920-2.o (timeout = 300)
> spawn
>> yes, that '50' should be a parameter somewhere in loop_vec_info.
>
> I see the broken code is still in aarch64.c - can someone please test
> & apply the above
> patch?
I believe this is on Alan's todo list.
Ramana
>
> Thanks,
> Richard.
>
>> Richard.
>>
>>> Thanks,
>>> James
>>>
>>> ---
>>> [
On Thu, Jul 2, 2015 at 12:03 PM, Matthew Wahab
wrote:
> On 22/06/15 12:56, Richard Biener wrote:
>>
>>
>> I plan to release GCC 5.2.0 around July 10th which means a release
>> candidate being done around July 3rd.
>>
>> Please check your open regression bugs for ones that eligible for
>> backporti
On Mon, Jun 8, 2015 at 9:07 AM, lin zuojian wrote:
> Hi,
> in arm.c
> static void
> arm_conditional_register_usage (void)
> ...
> if (TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_VFP)
> {
> /* VFPv3 registers are disabled when earlier VFP
> versions are selected
On Sat, Jun 6, 2015 at 10:49 AM, Andreas Schwab wrote:
> Bootstrap fails on aarch64:
>
> Comparing stages 2 and 3
> warning: gcc/cc1objplus-checksum.o differs
> warning: gcc/cc1obj-checksum.o differs
> warning: gcc/cc1plus-checksum.o differs
> warning: gcc/cc1-checksum.o differs
> Bootstrap compar
On 20/05/15 15:03, Paul E. McKenney wrote:
On Wed, May 20, 2015 at 02:44:30PM +0100, Ramana Radhakrishnan wrote:
On 20/05/15 14:37, David Howells wrote:
Paul E. McKenney wrote:
I was thinking of "y" as a simple variable, but if it is something more
complex, then the compile
On 20/05/15 14:37, David Howells wrote:
Paul E. McKenney wrote:
I was thinking of "y" as a simple variable, but if it is something more
complex, then the compiler could do this, right?
char *x;
y;
x = z;
Yeah. I presume it has to maintain the ordering, though.
On 29/04/2015 09:24, Christian Bruel wrote:
Hi Ramana, Richard
After playing with the attritute ((target ("[thumb,arm]")), during the
pending review, I added the "default" selector to neutralize
-mflip-thumb for the setjmp/longjmp based tests.
I was wondering it there would be an interest lev
;; Crude Advanced SIMD approximation.
(define_insn_reservation "cortex_53_advsimd" 4
(and (eq_attr "tune" "cortexa53")
(eq_attr:q "is_neon_type" "yes"))
"cortex_a53_simd0")
Does it mean that all AdvSIMD ins
On Thu, Feb 19, 2015 at 9:17 AM, Marat Zakirov wrote:
> Hi all!
>
> During my investigation I found that GCC does not performs load/store
> widening (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65088). Could you
> please answer is it so? And is there any plans to make it? I also would like
> to k
On Thu, Feb 12, 2015 at 3:18 PM, Ulrich Weigand wrote:
> Hello,
>
> we're running into a problem related to use of initial-exec access to
> TLS variables in dynamically-loaded libraries. Now, in general, this
> is actually not supported. However, there seems to an "inofficial"
> extension that a
On Thu, Jan 15, 2015 at 4:11 AM, Andrew Pinski wrote:
> Hi,
> I have some code where we generate some weird code that has stores
> followed by a load from the same location.
> For an example we get:
> add x14, sp, 240
> add x15, sp, 232
> str x14, [sp, 136]
> mov w2, w27
> ldr w1, [sp, 136]
> st
On Tue, Nov 11, 2014 at 3:16 PM, Joel Sherrill
wrote:
>
>> Fix is committed to trunk at
>> https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217341.
>>
>> BR,
>> Terry
>>
> That got past libgcc2 but now it fails building newlib for arm-eabi.
> This is just a build of gcc with newlib and libgl
On 04/08/14 23:34, Evandro Menezes wrote:
I noticed that when -mgeneral-regs-only FP registers are still used by the
LRA for spilling. Though in rare cases I saw an ICE because of it, even
when it works it seems to me that the compiler should follow the desires of
its user.
If you've notice
On 22/07/14 14:14, Kyrill Tkachov wrote:
Hi all,
In the arm backend we've got this TARGET_UNIFIED_ASM macro that is
currently on for TARGET_THUMB2 with a comment that says:
/* We could use unified syntax for arm mode, but for now we just use it
for Thumb-2. */
I've been doing some work
On 01/07/14 09:40, Matthias Klose wrote:
on some linux architectures there are some symbols missing in libstdc++.so.6
built from the 4.9 branch. I didn't notice before due to a packaging bug.
affected are ARM32, HPPA, SPARC.
- ARM32 (build log [1], both soft and hard float) are missing
On 01/07/14 20:58, John David Anglin wrote:
On 1-Jul-14, at 5:32 AM, Jonathan Wakely wrote:
On 1 July 2014 09:40, Matthias Klose wrote:
- HPPA (build log [2]), is missing all the future_base symbols and
exception_ptr13exception symbols, current_exception and
rethrow_exception.
This i
I wonder how much of that is due to auto-vectorization (on LLVM, -O2+
turns it on, I suppose GCC is only on -O3?). From Ramana's point,
there may be nothing serious if you haven't enabled NEON, though.
Auto-vec is turned off when you have -mfpu=vfpv3-d16 . That implies No Neon.
Ramana
Also
The ball-park number you have probably won't change much.
Unfortunately, that is the configuration I can use on my system because
of lack of libraries for other configurations.
Using --with-fpu={neon / neon-vfpv4} shouldn't cause you ABI issues with
libraries for any other configurations.
On 24/06/14 15:11, Vladimir Makarov wrote:
A few people asked me about new performance comparison of latest GCC
and LLVM. So I've finished it and put it on my site
http://vmakarov.fedorapeople.org/spec/
The comparison is achievable from 2014 link and links under it in
the left frame.
On Mon, May 19, 2014 at 1:02 PM, Andrew Haley wrote:
> On 05/16/2014 05:20 PM, Ian Bolton wrote:
>>> On 05/16/2014 12:05 PM, Kugan wrote:
On 16/05/14 20:40, pins...@gmail.com wrote:
>
>
>> On May 16, 2014, at 3:23 AM, Kugan
>>> wrote:
>>
>> I would like to know
On Thu, May 15, 2014 at 8:36 AM, Maxim Kuvyrkov
wrote:
> On May 15, 2014, at 6:46 PM, Ramana Radhakrishnan
> wrote:
>>
>>>
>>> I'm not claiming it's a great heuristic or anything. There's bound to
>>> be room for improvement. But it was
On Wed, May 14, 2014 at 5:38 PM, Richard Sandiford
wrote:
> Vladimir Makarov writes:
>> On 2014-05-13, 6:27 AM, Kyrill Tkachov wrote:
>>> Hi all,
>>>
>>> In haifa-sched.c (in rank_for_schedule) I notice that live range
>>> shrinkage is not performed when SCHED_PRESSURE_MODEL is used and the
>>> c
On Wed, Feb 19, 2014 at 11:26 PM, Renato Golin wrote:
> On 19 February 2014 23:19, Andrew Pinski wrote:
>> With the unified assembly format, you should not need those
>> .arm/.thumb and in fact emitting them can make things even worse.
>
> If only we could get rid or all pre-UAL inline assembly o
On Wed, Feb 19, 2014 at 11:19 PM, Andrew Pinski wrote:
> On Wed, Feb 19, 2014 at 3:17 PM, Renato Golin wrote:
>> On 19 February 2014 11:58, Richard Sandiford
>> wrote:
>>> I agree that having an unrecognised asm shouldn't be a hard error until
>>> assembly time though. Saleem, is the problem th
On 02/06/14 18:25, David Howells wrote:
Is it worth considering a move towards using C11 atomics and barriers and
compiler intrinsics inside the kernel? The compiler _ought_ to be able to do
these.
It sounds interesting to me, if we can make it work properly and
reliably. + gcc@gcc.gnu.org
On Mon, Dec 30, 2013 at 3:23 AM, Yangfei (Felix) wrote:
> Thanks for the reply. I found it in GCC-4.8.
> The gcc version I look at is GCC-4.7. Seems this pattern is not there for
> this version.
That will be because this was added in time for GCC 4.8. If you need
to find such information as to w
On Wed, Dec 11, 2013 at 12:02 AM, Maxim Kuvyrkov wrote:
> On 11/12/2013, at 11:14 am, Ramana Radhakrishnan
> wrote:
>
>> On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov wrote:
>>> On 11/12/2013, at 5:17 am, Ramana Radhakrishnan
>>> wrote:
>>>
>&g
On Tue, Dec 10, 2013 at 9:44 PM, Maxim Kuvyrkov wrote:
> On 11/12/2013, at 5:17 am, Ramana Radhakrishnan
> wrote:
>
>> On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote:
>>> Hi,
>>>
>>> Near the start of schedule_block, find_modifiable_mems is cal
On Mon, Jul 1, 2013 at 5:31 PM, Paulo Matos wrote:
> Hi,
>
> Near the start of schedule_block, find_modifiable_mems is called if
> DONT_BREAK_DEPENDENCIES is not enabled for this scheduling pass. It seems on
> c6x backend currently uses this.
> However, it's quite strange that this is not a requ
> And my main question is it possible to rely on this fact when
> compiling with gcc and different levels of optimizations?
No it is not , the compiler (especially trunk) is free to use LR as a
temporary after epilogue has been generated at higher optimization
levels.
> Is it
> possible to gener
On Fri, Apr 27, 2012 at 9:24 PM, David Sehr wrote:
> Hello All,
>
> We are using gcc trunk as of 4/27/12, and are attempting to add
> support to the ARM gcc compiler for Native Client.
> We are trying to get gcc -march=armv7-a to use movw/movt consistently
> instead of minipools. The motivation is
Sorry about the delayed response, I've been away for some time.
>
> I don't exactly understand why the general transform is not advisable.
> We already synthesize min/max operations.
>
> Can you elaborate on why you think that better code might be generated
> when not doing this transform?
The
Hi,
A colleague noticed that we were not vectorizing loops that had end of
loop computations that were MIN type operations that weren't expressed
in the form of a typical min operation. A transform from (i < x ) &&
( i < y) to ( i < min (x, y)) is only something that we should do in
these situat
On Mon, Jan 30, 2012 at 6:56 AM, Jon Masters wrote:
> The __sync_synchronize "legacy" sync function is intended to be used to
> perform an expensive data memory barrier operation. It is defined within
> libgcc in such a way that I *believe* means that, on most architectures,
> it is replaced with
k splitting is a consequence of that.
For the A8 this should be OK - try a few benchmarks to be sure it
doesn't spring any surprises performance wise.
cheers
Ramana
---
Ramana Radhakrishnan
PDSW Tools
ARM Ltd.
> I appreciate any advise of how to resolve this -- should I add
>
> (*fun) (&XEXP (dest, 0), data); ?
Actually I don't see why not - a zero_extract on the LHS of an
expression is supposed to be a bit field insert on that register.
Isn't there an implicit read of the destination register involved
On 16 August 2011 16:24, Richard Sandiford wrote:
> Ramana Radhakrishnan writes:
>> I can't see how it is right to construct essentially 2 chains for the
>> same register that have overlapping live ranges without an intervening
>> conditional branch and since regrename
Hi Michael,
Thanks for running these. I spent some time this morning looking
through the results, they largely look ok though I don't have much
perspective on the
the objc/ obj-c++ failures.
These failures here
For v7-a , A9 and Neon - these failures below:
> Running target unix
> FAIL: gfortra
>> Index: config/arm/thumb2.md
>> ===
>> --- config/arm/thumb2.md (revision 168424)
>> +++ config/arm/thumb2.md (working copy)
>
>> + ??? The possible introduction of a new block to initialize the
>> + new IV can po
On Wed, 2010-12-08 at 14:42 +0100, Richard Guenther wrote:
> A release candidate for GCC 4.5.2 is available from
>
> ftp://gcc.gnu.org/pub/gcc/snapshots/4.5.2-RC-20101208
>
> and shortly its mirrors. It has been generated from SVN revision 167585.
>
> I have so far bootstrapped and tested the
On Wed, 2010-06-16 at 15:52 +, Siarhei Siamashka wrote:
> Hello,
>
> Currently gcc (at least version 4.5.0) does a very poor job generating single
> precision floating point code for ARM Cortex-A8.
>
> The source of this problem is the use of VFP instructions which are run on a
> slow nonp
Hi Kenneth,
The documentation of auto-inc-dec still refers to flow and when I
raised this on IRC folks suggested that you might have some
documentation fixes if any, in this area.
http://gcc.gnu.org/onlinedocs/gccint/Incdec.html#Incdec
The lines in the doco are as below :
These embedded side ef
> 42509, arm-gnueabi doesn't bootstrap but is a primary target
I haven't had the time in the past few weeks to work on this
effectively. I'll be able to find some time to work on this during this
week and will get back on this.
cheers
Ramana
On Sat, 2010-01-16 at 16:23 +0100, Jakub Jelinek wrote:
>
> The branch is now frozen and all checkins until after the final release
> of GCC 4.4.3 require explicit RM approval.
I would like to backport this patch http://gcc.gnu.org/PR38697
from mainline into the 4.3 and 4.4 branches, so that som
s you beat me to it.
cheers
Ramana
--
Ramana Radhakrishnan
GNU Tools
ARM Ltd.
ters 0-10:
Unbound module Utils
It sounds like a configuration issue but given my rather rusty ocaml
skills - I'm not sure where to look. Googling around doesn't show me
anything obvious. I see this both with v. 3.09.3 and v 3.11 (on
karmic).
Any help would be appreciated.
On Wed, 2009-12-23 at 16:00 +0100, Paolo Bonzini wrote:
> On 12/23/2009 03:27 PM, Bingfeng Mei wrote:
> > Do you mean if TARGET_ADDRES_COST (non-x86) is defined properly,
> > this should be fixed? Or it requires extra patch?
>
> No, if TARGET_ADDRESS_COST was fixed for x86 (and of course defined
>
> GCC bootstrap :
>
> Total number of zero-extension instructions before : 1456
> Total number of zero-extension instructions after : 5814
> No impact on boot-strap time.
You sure you have these numbers the right way around ? Shouldn't the
number of zero-extension instructions after the pa
On Wed, Aug 19, 2009 at 1:27 PM, Diego Novillo wrote:
> I haven't been able to connect to #gcc today. Is anyone else having
> trouble connecting?
Wonder if it is something else . I've been connected pretty much all
day and things seem to be working.
Ramana
>
> Diego.
>
On Mon, 2009-08-10 at 15:09 +0200, Steven Bosscher wrote:
> On Mon, Aug 10, 2009 at 1:16 PM, Ramana
> Radhakrishnan wrote:
> > I wonder if the best way to fix this is to teach ifcvt.c to handle
> > conditional returns.
>
> Yes. This is a bug in the middle-end. I can only
ith this email.
Thanks in advance for the answers.
cheers
Ramana
Attachments
1. Patch to turn on predicable attributes on all the ARM call patterns.
2. Dumps of the testcase that are relevant, test.c.*.peephole2,
test.c.*.dse2, test.c.*.ce3. (dumps.tar.bz2)
3. Testcase test.c
--
Ram
On Fri, Aug 7, 2009 at 1:33 PM, Florent Defay wrote:
> Hi,
>
> I am working on a new port.
>
> The target machine supports post-increment and pre-decrement
> addressing modes. These modes are twice faster than indexed mode.
> It is important for us that GCC consider them well.
GCC does support ge
On Fri, Jun 5, 2009 at 11:11 PM, Graham Reitz wrote:
>
> Is there a machine description template in the gcc file source tree?
There is no template as such but you could look at existing ports for
the basic templates. Google should give you results for previous
questions on this list regarding new
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Paolo Bonzini
> Sent: 07 May 2009 14:53
> To: m...@codesourcery.com
> Cc: gcc@gcc.gnu.org; Ramana Radhakrishnan; Richard Earnshaw
> Subject: cond-optab merge delay? [was
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Samuel Tardieu
> Sent: 06 May 2009 11:06
> To: gcc@gcc.gnu.org
> Subject: Multilib for ARM in thumb2 mode
>
> Right now, to be able to compile a mutilib-enabled ARM-targeted
> compiler
> supp
> -Original Message-
> From: Michael Matz [mailto:m...@suse.de]
> Sent: 06 May 2009 18:00
> To: Richard Earnshaw
> Cc: Paolo Bonzini; Joern Rennecke; Ramana Radhakrishnan;
> m...@codesourcery.com; gcc@gcc.gnu.org
> Subject: Re: Setting ARM PIC register (Was: RE: GC
On Wed, May 6, 2009 at 4:10 PM, Mark Mitchell wrote:
> Richard Earnshaw wrote:
>
>>> The slush that I requested last week has been lifted. However, I have
>>> asked for relative calm until the cond-optab branch has been merged to
>>> mainline, which will hopefully occur on Friday, May 8th.
>>
>
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Nitin Garg
> Sent: 01 May 2009 14:11
> To: gcc@gcc.gnu.org; gcc-h...@gcc.gnu.org
> Subject: Problem with gcc-4.4.0 with Cortex-m3 and cortex-a9 cpu
>
> I am working on Cortex-A9 and M3 of ARM
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Ramana Radhakrishnan
> Sent: 08 April 2009 23:30
> To: Paolo Bonzini
> Cc: GCC Development; Ian Lance Taylor; Andreas Krebbel; Uros Bizjak
> Subject: Re: [cond-opta
On Tue, Apr 7, 2009 at 11:03 AM, Ramana Radhakrishnan
wrote:
>> To aid testing, I'd like people to help bootstrapping bootstrappable
>> targets -- arm, alpha, ia64, pa, s390, x86_64.
>
> I'm bootstrapping the branch on an arm-linux-gnueabi target.
bootstrap on
1 - 100 of 149 matches
Mail list logo
