Alex Coplan appointed maintainer of AArch64 pair fusion pass and pair-fusion pass.

congratulating Alex on his new roles. Alex , please update your listing in the MAINTAINERS file. Regards Ramana

Christophe Lyon as MVE reviewer for the AArch32 (arm) port.

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

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

on bare-metal > > targets. > > > > > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or > > > > aarch64-linux- > > elf... > > > > I get a KeyError in build_compilers and build_glibcs when it tries to > > > > look up

Re: [EXTERNAL] Re: How to test aarch64 when building a cross-compiler?

re for use only on bare-metal targets. > > Hmm.. build-many-glibcs.py doesn't like either aarch64-elf or > > aarch64-linux-elf... > > I get a KeyError in build_compilers and build_glibcs when it tries to look > > up the config with either of those values. > > > > Unfortunately the build-many-glibcs.py does not have support for baremetal > build yet (since it is a tool created to build cross-compiling toolchain > using glibc). And glibc doesn't work bare-metal .. regards Ramana

Kyrylo Tkachov and Richard Sandiford appointed AArch64 maintainers.

file. Thanks, Ramana

Re: Doubts regarding the _Dependent_ptr keyword

nder if marking this volatile would be sufficient for prototyping. I suspect we would need another flag somewhere which someone with gimple knowledge might be able to help us with. regards Ramana > > Thanx, Paul > > > Ramana > >

Re: Doubts regarding the _Dependent_ptr keyword

itive nature of >> assignments with these attributes ? >> >> regards >> Ramana > > I don't understand what information to store, can you explain? I was thinking > of putting some code inside the pass, which breaks the dependency chains, > which w

Re: Doubts regarding the _Dependent_ptr keyword

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

Re: GCC missing -flto optimizations? SPEC lbm benchmark

Just it is better not to have it if > it causes lots of wrong-code issues and there is nobody to fix those. I also remember a cauldron talk in the recent past about this. It was in Prague. Ah , here's a youtube video of it. : https://www.youtube.com/watch?v=vhV75sys0Nw Ramana > > Jakub

Re: autovectorization in gcc

ical. It would be nice > to have a warning which would fire if vectorization failed. That would > surely help the OP. That would help certainly : the user could get some information out today with the debug dumps - however they are designed more for the compiler writers rather than users. regards Ramana

Re: Suitable regression test for vectorizer patches? - (need {u,}madd* pattern)

you probably need 2 smlald instructions to achieve this IIUC . We do have a dot product optab in the arm backend but that's with Advanced simd which isn't in the M profile. regards Ramana > > Would the test be suitable if it made the arm target, > with a patch added to add a s

Re: [RFC] Adding Python as a possible language and it's usage

gt; dependencies, use in glibc is more or less equivalent to use in GCC. (But > if build dependencies include those involved in testing, you already have > python as one for glibc, and Tcl for GCC, for example.) This implies that the decision for glibc has been made. while you imply above that the discussion is still on going ? regards Ramana > > > Joseph S. Myers > jos...@codesourcery.com

Re: GCC 8.2 Status Report (2018-07-19), branch frozen for release

; https://gcc.gnu.org/ml/gcc/2018-07/msg00194.html Is there any chance we can get some of the spectrev1 mitigation patches reviewed and into 8.2 . It would be quite useful to get these into a release as I see that the reviews are kinda petering out and there hasn't been any objection to the approach. regards Ramana

Re: Subnormal float support in armv7(with -msoft-float) for intrinsics

tches to. regards Ramana > ~Umesh > > On Fri, Jul 13, 2018 at 1:22 PM, Umesh Kalappa > wrote: >> Thank you and issue raised at >> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86512 >> >> ~Umesh >> >> On Thu, Jul 12, 2018 at 9:33 PM, Szabolcs Nagy wrote:

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

till holds, it's not a question of an architecture bug or a >> >> > missing feature in KVM, but a question of a guest doing something wrong. >> >> > >> >> >> >> Do you have a mutt macro for that response? :-) >> >> >> > >> > No I don't. And I wouldn't mind adding instruction decoding to KVM. I >> > already wrote it once, but the maintainer didn't want to merge the code >> > unless I unified all instruction decoding in the arm kernel, which I was >> > unable to do. >> > >> >> Yikes. >> >> So how does your code actually load the opcode? >> >> > Sarkasm and instruction decoding stories aside, we've had a number of >> > reports of this kind of error in the past where the problem was simply >> > people using the wrong the DT with their guest kernel. I don't think >> > we've seen an actual case of a real guest that was using the 'wrong' >> > instruction to actually do I/O. >> > >> >> Currently, LTO builds of EDK2 for 32-bit mach-virt are broken because >> of this. The MMIO accessors are written in C using volatile pointers, >> allowing LTO to merge adjacent accesses or loops performing MMIO, >> resulting in, e.g., instructions with writeback to be emitted. > > I'd like to see a testcase where GCC does merging on volatile accesses. > That would be a GCC bug. So I suspect the C code isn't quite using volatile > accesses... > I'd also like to see a proper testcase to action. IIRC we have checks preventing such merges for volatiles irrespective of LTO or not. Ramana

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

they pop up over time. The expression "all cases we can identify" is > the core of the problem; it's not a well-defined set. > > Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a > pin-point location; another possibility (that might scale better to > humans) is a new, lighter-weight flag, such as "-mno-multiple", that is > applied universally to a codebase. I don't see enough detail to explain what the problem is in the first place. LTO to me is a red-herring here and smells of a hack. There's no guarantee that GCC won't use these instructions in non-LTO configurations and infact will aggressively do this in a number of situations. The -fno-lto fix and the fix for disabling load / store multiple or load / store pair being suggested here both smell of an underlying problem that needs to be understood in the various sourcebases first. Ramana > > Thanks! > Laszlo

Re: Dealing with default recursive procedures in Fortran

IIRC that will have a dependency on a newer glibc as well,so that would depend on a newer glibc as well for split-stack to work reliably as platforms. Ramana

Richard Sandiford appointed SVE maintainer in AArch64 port.

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

Re: Fw: GCC interpretation of C11 atomics (DR 459)

is a guarantee from the standard that there are no problems with read-only locations is to implement the change in libatomic. You cannot have the same region of memory protected by locks in older binaries and the appropriate load / store instructions in new binaries. Ramana > 4. Faster & e

Re: "GOT" under aarch64

er the question when are relocations through the GOT used, the answer is whenever folks want to have position independence either in their libraries or in their executables. regards Ramana

Re: Help out/New to the Project

wiki page here https://gcc.gnu.org/wiki/EasyHacks regards Ramana > > Thanks for any answers, > Nick

Announcing ARM and AArch64 port maintainers.

it would be appreciated. Thanks, Ramana

Re: Linux and Windows generate different binaries

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

Andrew Burgess and Claudiu Zissulescu as reviewers for the ARC port

, Ramana

Oliver Hainque as co-maintainer of the VxWorks port.

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

Re: How to check if two symbols are from same source unit during WPA ?

;implemented" using some special relocations and thus as linker > optimization. For performance (and probably code size too) as you can end up CSE'ing the anchor point. the difference in performance with -flto-partitions=1 is visible on quite a few of the spec2k benchmarks. I don't remember which ones immediately but yeah it makes a difference. Ramana > > Richard. >

Re: [RFC PR43721] Optimize a/b and a%b to single divmod call

o check the transformation - I think you need to check for __ARM_ARCH_EXT_IDIV__ here similar to the way in which we test for FMA or __ARM_FEATURE_UNALIGNED. Could you please repost with the changes so that I can take another look ? Otherwise I think this is something we should queue up for GCC 7. thanks, Ramana

Re: Instruction scheduler rewriting instructions?

about PR 48814 and ivopts (thus the -fno-ivopts option). IIRC it's because the scheduler *thinks* it can get a tighter schedule - probably because it thinks it can dual issue the lbu from $4 and the addiu to $5. Can it think so ? This may be related - https://gcc.gnu.org/ml/gcc-patches/2012-08/ms

Re: How do we write unused arguments?

> one comments, I'll start enforcing that in patch reviews. Currently no one > seems sure and everything is getting totally inconsistent. When I asked on IRC the other day it sounded like people were tending towards some_target_hook (tree decl, machine_mode) and that's what I'm starting to use personally these days. regards Ramana > > > Bernd

Re: [RFC, VECTOR ABI] Allow __attribute__((vector)) in GCC by default.

is dependent as usual on command line options, target options, pragmas etc ? regards Ramana

Re: dejagnu version update?

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 >>

Re: Repository for the conversion machinery

ust avoiding it. After all the information is in the changelog and in the commit - currently svn log shows username with an implicit gcc.gnu.org. I can certainly say I'm in those shoes - you can work that out from the Changelogs and I'm sure there may be others too. It sounds like gcc.gnu.org is the safest map for everyone. regards Ramana > > - FChE

Re: dejagnu version update?

me ? Advantage is that everyone is guaranteed to be on the same version. I fully expect resistance due to specific issues with specific versions of tcl and expect, but if folks aren't aware of this . regards Ramana

Re: Moving to git

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

Re: Moving to git

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

Re: Moving to git

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

Re: Moving to git

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

Re: Moving to git

f "next" I've seen is with gerrit, where "next" refers to a "next" commit that's been put up for code review. > > One interesting thing that they do is to keep earlier branches merged into > later branches, so 4.9 into 5, 5 into trunk, trunk into next. This is an > interesting discipline, but I'm not sure it is of much practical value. I don't see how that fits with our development model. regards Ramana > > Jason >

Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

ons of the compiler, and the debate has been whether this is a regression or not. If in case it is not deemed to be a regression based on that comment, we should just XFAIL the test and move on. Given Jakub's away I'm CCing richi on this discussion. regards Ramana > > Kind regards, > Alex >

Re: ira.c update_equiv_regs patch causes gcc/testsuite/gcc.target/arm/pr43920-2.c regression

; So this is a regression in fsf-5. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64916#c3 regards Ramana > > Kind regards, > Alex >

Re: [AArch64] Missed vectorization opportunity in cactusADM

>> 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, > R

Re: GCC 5.1.1 Status Report (2015-06-22)

eral back-ends. I'd also like to see the ARM patches backported please unless there are RM objections for it. It doesn't make sense for them to diverge with something like this at different release points on the branch if we can avoid it. Ramana > > Matthew

Re: ARM's Changing Call Used Registers Causes Weird Bugs

t obeying the ABI and clobbering D8. If you have an actual reproducible issue please report it on bugzilla following the rules for reporting bugs by producing a standalone testcase. as documented here https://gcc.gnu.org/bugs/ Thanks, Ramana > -- > Lin Zuojian

Re: debug-early branch merged into mainline

7;m seeing bootstrap failures on arm-none-linux-gnueabihf gcc/cfgloop.o differs gcc/tree-ssa-dom.o differs gcc/dwarf2asm.o differs gcc/tree-affine.o differs gcc/cse.o differs gcc/data-streamer-out.o differs gcc/tree-ssa-sccvn.o differs regards Ramana > > and on ia64: > > ../../gcc/dw

Re: Compilers and RCU readers: Once more unto the breach!

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

Re: Compilers and RCU readers: Once more unto the breach!

ng, though. The scheduler for e.g. is free to reorder if it can prove there is no dependence (or indeed side-effects for y) between insns produced for y and `x = z'. regards Ramana David

Re: interest for ARM/thumb multiversionning ?

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

Re: [RFC] cortex-a{53,57}-simd.md missing?

are merited it will be picked up. That being said I believe the current description isn't too bad on the Cortex-A53 - it's definitely better than having none at all. regards Ramana -- Best regards, Ilya Palachev

Re: [RFC] load/store widening question

ordering issues and you'll have quite a few variances between ports to make this work sensibly. regards Ramana > $ gcc t2.c -O3 -S > > $ cat t2.s > > ... > > main: > .LFB0: > .cfi_startproc > movla(%rip), %eax > movl%

Re: Failure to dlopen libgomp due to static TLS data

org/ml/libc-alpha/2014-10/msg00134.html though my brain is too frazzled today to remember what the conclusion was. regards Ramana > > One example of a system library that does this is libgomp, the OpenMP > support library provided with GCC. Here's an email thread from the > gcc

Re: LRA handling of subreg (on AARCH64 with ILP32)

pear to store a 64 bit value on the stack and then reobtain into a different register set , ie. r6, r3 -> r6, r7 Ramana > > Thanks, > Andrew Pinski

Re: arm/thumb broken on head

; ../../gcc/gcc/passes.c:1868 > 0x870733 execute_todo > ../../gcc/gcc/passes.c:1925 > Please submit a full bug report, > with preprocessed source if appropriate. That certainly looks like a different issue to the one with Terry's patch. It does look like something else is br

Re: [AArch64] Usage of FP regs whe only GP regs are allowed

e LRA from using FP registers if the user so desires. Please send patches to the mailing list. I think however in this case you are papering over the problem as explained in the PR. regards Ramana

Re: [ARM] Is TARGET_UNIFIED_ASM still needed?

were to do the full transition, remember that users need to have a way of mixing non-unified syntax in inline assembler with unified syntax in the rest of the C code. regards Ramana Is it perhaps time to just drop this and assume unified asm everywhere? Kyrill

Re: missing symbols in libstdc++.so.6 built from the 4.9 branch

x/arm-eabi-extra.ver to have added these symbols in and I'm not sure what's going on here. So prima-facie this is a bug. I wonder if something's broken in the handling of port_specific_symbol_files for arm. regards Ramana - HPPA (build log [2]), is missing all the fut

Re: missing symbols in libstdc++.so.6 built from the 4.9 branch

ines for this support. We currently define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_4, etc, in pa-linux.h. I'll experiment with defining ATOMIC_INT_LOCK_FREE there. We then need to do the same on ARM especially for older architectures that don't have these sync patterns. Ramana Thanks,

Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM

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 Neo

Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM

(as you know RedHat works on a server market) but unfortunately I have no such machine for SPEC benchmarking. Ramana

Re: Comparison of GCC-4.9 and LLVM-3.4 performance on SPECInt2000 for x86-64 and ARM

-fpu=vfpv3-d16 Did you add any other architecture specific options to your SPEC2k runs ? regards Ramana If you need exact numbers they can be found in the tables. If you have any comments and proposals, please feel free to write me. I try to take them into account next year.

Regarding concrete inlined and out-of-line inlined instances

Hi, I have the below debug information (dwarf4) generated by the GCC compiler v4.8.2 for an inlined function. Please help me with the following queries. In the concrete inlined instance of 'ext2_lookup', its DW_AT_entry_pc value (0xc01b49d0) is overlapping with the address range i.e. DW

Re: Using particular register class (like floating point registers) as spill register class

84>: fmovd10, x0 >0x007fb76dc848 <+188>: add x0, x29, #0xf8 >0x007fb76dc84c <+192>: fmovd11, x0 > > followed later by: > >0x007fb76dd224 <+2712>: fmovx0, d9 >0x007fb76dd228 <+2716>: add x6, x29, #0x118 >0x007fb76dd22c <+2720>: str x20, [x0,w27,sxtw #3] >0x007fb76dd230 <+2724>: fmovx0, d10 >0x007fb76dd234 <+2728>: str w28, [x0,w27,sxtw #2] >0x007fb76dd238 <+2732>: fmovx0, d11 >0x007fb76dd23c <+2736>: str w19, [x0,w27,sxtw #2] > > which seems a bit suboptimal, given that these double registers now have > to be saved in the prologue. That looks a bit suspicious - Is there a pre-processed file you can put on to bugzilla for someone to take a look at with command line options et al ? I had a testcase that I was investigating a few days back from a benchmark that was doing SHA2 calculations. From my notes I'd been playing with REGISTER_MOVE_COST and MEMORY_MOVE_COST and additionally the extra moves appeared to disappear with -fno-schedule-insns. Remember however that on AArch64 we don't have sched-pressure on by default. regards Ramana >

Re: Live range shrinkage in pre-reload scheduling

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

Re: Live range shrinkage in pre-reload scheduling

> E.g. tracking pressure classes isn't always the right thing for > targets like PowerPC where only part of the vector register set > can be used for floating-point operations. Is there another post that deals with this particular case ? I tried digging through the archives but couldn't find anything easily enough. regards Ramana > > Thanks, > Richard

Re: ARM inline assembly usage in Linux kernel

while IMNSHO. Adding the warning by default to GAS is just part of the solution. regards Ramana > > cheers, > --renato

Re: ARM inline assembly usage in Linux kernel

) implementation dependent. It is purely a grammar for the instructions in the assembly language and doesn't attempt to standardize assembler directives which would have evolved differently over time and different assemblers. How do you otherwise tell the assembler whether to assemble for ARM

Re: [GCC 4.8.1] Which section to emit, .eh_frame or .debug_section?

On Thu, Feb 13, 2014 at 5:29 PM, Jakub Jelinek wrote: > On Thu, Feb 13, 2014 at 05:24:53PM +0530, Ramana wrote: >> For C++ applications, on PPC, gcc v4.8.1 is generating the call frame >> information in the .eh_frame section by default. >> >> Could you please tel

[GCC 4.8.1] Which section to emit, .eh_frame or .debug_section?

Hi, For C++ applications, on PPC, gcc v4.8.1 is generating the call frame information in the .eh_frame section by default. Could you please tell me why .eh_frame is being generated instead of .debug_frame? Also, the dwarf4 standard does not describe .eh_frame section. I understand that by default

Re: [RFC][PATCH 0/5] arch: atomic rework

userspace can't normally disable interrupts. David Ramana

Re: Question about simple_return pattern for the GCC ARM backend.

k sources since that is where new development happens. Thanks, Ramana > >> >> On 2013/12/28 09:31 AM, Yangfei (Felix) wrote: >> > Hi, >> > >> > I think that simple_return standard pattern is useful for the ARM. I mean >> it should be good for tar

Re: DONT_BREAK_DEPENDENCIES bitmask for scheduling

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

Re: DONT_BREAK_DEPENDENCIES bitmask for scheduling

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

Re: DONT_BREAK_DEPENDENCIES bitmask for scheduling

litch and ended up asking the same question today. Additionally if I use TARGET_SCHED_SET_SCHED_FLAGS on a port that doesn't use the selective scheduler, this does nothing. Does anyone know why is this the default for ports where we don't turn on selective scheduling and might need a hook to turn this off ? regards Ramana > > Cheers, > > Paulo Matos > >

Re: ARM calling conventions generated in gcc with different optimizations

possible to generate some straightforward heuristic to detect this > evens (with\without debug info)? With debug information you could in theory work this out but not without it especially if LR were used as a temporary. regards Ramana > > Thank you in advance for any suggestions!

Re: Using movw/movt rather than minipools in ARM gcc

t's triggered this. Would you be able to experiment with some of the suggestions in that report and maybe create an equivalent one in the GCC bugzilla . I haven't had the time to investigate this particular problem further. regards, Ramana > > I have enabled TARGET_USE_MOVT

Re: [RFC] Converting end of loop computations to MIN_EXPRs.

nd table is probably worthwhile looking at - > > Btw, the canonical case this happens in is probably > >   for (i = 0; i < n; ++i) >     for (j = 0; j < m && j < i; ++j) >       a[i][j] = ... > > thus iterating over the lower/upper triangular part of a non-s

[RFC] Converting end of loop computations to MIN_EXPRs.

h this case and I'm guessing that it could also handle more of the comparison cases and come up with more intelligent choices and should be made quite a lot more robust than what it is right now. regards, Ramana diff --git a/gcc/tree-ssa-loop-im.c b/gcc/tree-ssa-loop-im.c index ce5eb20..a52953

Re: __sync_sychronize on ARM

static libgcc where this should be defined. I don't know what your linker command line is so maybe that's a place to start investigating from. cheers Ramana

RE: [RFC, ARM] cortex_a8_call cost

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.

Re: A question abt finding all register uses in instruction

he destination register involved in this case in that the lower order bits of the register are left unchanged ? cheers Ramana

Re: regrename and odd behaviour with early clobber operands

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

Re: Second GCC 4.6.0 release candidate is now available

nd it just seemed to work. I'm still looking through the other results but I haven't spotted anything obvious broken yet. cheers Ramana On Thu, Mar 24, 2011 at 9:04 PM, Michael Hope wrote: > On Tue, Mar 22, 2011 at 11:12 AM, Jakub Jelinek wrote: >> A second GCC 4.6

Re: [ARM] Implementing doloop pattern

itialize the >> +      new IV can potentially effects branch optimizations.  */ > > s/effects/effect/ Err I think it should be "affect" rather than effect here. Thus s/effects/affect Ramana

Re: GCC 4.5.2 Release Candidate available from gcc.gnu.org

llowing parameters : --with-cpu=cortex-a9 --with-fpu=vfpv3-d16 --with-float=softfp Tests are still running. Ramana

Re: RFC: ARM Cortex-A8 and floating point performance

gle precision calculations. Only in situations that the user is aware about -ffast-math. I will point out that single precision floating point operations on NEON are not completely IEEE compliant. cheers Ramana

inconsistencies in the documentation regarding side effects with auto inc-dec

ss shortly before or after; these cases are then transformed to use pre- or post-increment or -decrement. Cheers Ramana

Re: GCC 4.5 Status Report (2010-03-15)

> 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

Re: GCC 4.4.3 Release Candidate available from gcc.gnu.org

, so that some spurious Neon test failures go away. Can I also ask to backport the fix for http://gcc.gnu.org/PR40887 into the 4.3 / 4.4 branches ? Cheers Ramana

Re: [ARM] Neon / Ocaml question

s you beat me to it. cheers Ramana -- Ramana Radhakrishnan GNU Tools ARM Ltd.

[ARM] Neon / Ocaml question

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.

Re: Unnecessary PRE optimization

wprop patch I'm happy to test for performance on the ARM and look at ADDRESS_COST carefully on the ARM. cheers Ramana > > Paolo

Re: Request for code review - (ZEE patch : Redundant Zero extension elimination)

instructions after the patch be less than the number of zero-extension instructions before or is this a regression ? Thanks, Ramana > > > I have attached the latest patch : > > > On Sun, Aug 9, 2009 at 2:15 PM, Richard Guenther > wrote: >> On Sat, Aug 8, 2009 at 11:59

Re: irc.oftc.net down?

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. >

Re: ifcvt.c question.

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

ifcvt.c question.

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

Re: PRE_DEC, POST_INC

ing to address auto-inc generation for loop ivopts but I'm not sure if these have gone into trunk yet. Hope this helps. cheers Ramana

Re: Machine Description Template?

was curious if there was a generic template. Sadly you'd have to keep them in sync with every version of gcc and no one has thought of maintaining something like that. Best of luck - HTH Ramana > > graham >

RE: cond-optab merge delay? [was Re: GCC 4.5.0 Status Report (2009-05-05)]

> -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

RE: Multilib for ARM in thumb2 mode

ile for armv4t and why should one have an additional multi-lib for thumb2 in such a case ? Cheers Ramana

RE: Setting ARM PIC register (Was: RE: GCC 4.5.0 Status Report (2009-05-05))

> -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

RE: GCC 4.5.0 Status Report (2009-05-05)

been seeing with http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39929#c12. Ramana > -Original Message- > From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of > Mark Mitchell > Sent: 06 May 2009 16:10 > To: Richard Earnshaw > Cc: gcc@gcc.gnu.org > Subject:

  1   2   >