similar to: [LLVMdev] [llvm-gcc] backport patch 98010

On Nov 29, 2006, at 11:27 AM, Devang Patel wrote: > When we back port patches from FSF GCC mainline, we decorate them > with 'mainline' markers, for example > > /* APPLE LOCAL begin 4229621 mainline */ > .... > /* APPLE LOCAL end 4229621 mainline */ > > There are many examples of such markers in source. These markers > help us resolve conflicts when >

When we back port patches from FSF GCC mainline, we decorate them with 'mainline' markers, for example /* APPLE LOCAL begin 4229621 mainline */ .... /* APPLE LOCAL end 4229621 mainline */ There are many examples of such markers in source. These markers help us resolve conflicts when we merge current sources in mass with FSF GCC mainline. They also help solve mysterious failures

Hi All, llvm-gcc-4-2 development branch is now open for development at llvm.org/svn/llvm-project/llvm-gcc-4-2 It is not yet ready, it can not even bootstrap. I welcome LLVM developers to test and apply fixes! However, first take a note of ground rules : 1) LLVM developers, use your write access as judiciously as you use it for LLVM development and follow same check-in procedure. 2)

Hi Devang, thanks very much for doing this. > 2) I'd appreciate if LLVM specific code is covered by appropriate > markers. There are tons of existing examples in current sources. > Entire LLVM support patch is covered by these markers. I might have > removed code from llvm-gcc-4.0 that was required for LLVM support but > was not covered under /* APPLE LOCAL

On Fri, Apr 9, 2010 at 9:30 AM, Jack Howarth <howarth at bromo.med.uc.edu> wrote: > On Fri, Apr 09, 2010 at 05:22:17PM +0200, Duncan Sands wrote: >> Hi Jack, >> >>>>>      Is there a timeline for when dragonegg might be >>>>> merged into gcc (4.6 perhaps)? I ask because FSF gcc >>>>> has allowed code in as technology previews

> 2) I'd appreciate if LLVM specific code is covered by appropriate > markers. There are tons of existing examples in current sources. > Entire LLVM support patch is covered by these markers. I might have > removed code from llvm-gcc-4.0 that was required for LLVM support but > was not covered under /* APPLE LOCAL <begin|end> LLVM */ markers. If > someone

On Fri, Apr 09, 2010 at 05:22:17PM +0200, Duncan Sands wrote: > Hi Jack, > >>>> Is there a timeline for when dragonegg might be >>>> merged into gcc (4.6 perhaps)? I ask because FSF gcc >>>> has allowed code in as technology previews before. >>>> For instance, graphite really wasn't that usable in >>>> gcc 4.4 and produced

On Aug 10, 2008, at 11:40 PM, Duncan Sands wrote: > Hi Jack, > >> The curent llvm svn (r54623) is unable to link the gfortran >> compiler in llvm-gcc-4.2 svn. I am getting the error... > ... >> Undefined symbols: >> "_create_init_utf16_var", referenced from: >> _darwin_build_constant_cfstring in libbackend.a(darwin.o) > > this is

I am pretty excited about the recent activity on dependence analysis. The only remaining problem from our point of view is how to get the alias information to the back end instruction scheduler. If I understand things correctly, the alias information basically gets lost in the process of lowering to target instructions. We are interested in the DSP domain, so we really need to get SIMD style

Hi,   The link and the information shared was helpful.   I will make my problem definition more clear. While I am "asm printing" target code, I also want to emit scope related information. Scope related information includes, - for each scope, start line, end line, start column, end column and - scope heirarchy. As scope is delimited by "{" and "}" (for an input

I am wondering how the following issue was handled for libLTO? We have a working patch to implement the FSF gcc LTO on darwin which now passes all of the liblto testsuite but are seeing linker issues with larger programs like aermod... as -arch x86_64 -force_cpusubtype_ALL -o aermod.o aermod.s /usr/bin/ld -dynamic -arch x86_64 -macosx_version_min 10.6.3 -weak_reference_mismatches

Pankaj, If you want to decorate MachineInstrs then for the end of scope you're not looking at "}" but instead you're looking at _last_ machine instruction in that scope. Now, if you want to find out start and end MachineInstrs for a lexical scope (and corresponding line numbers) then see CodeGen/LexicalScopes pass. It collects lexical scope information and maps MIs to respective

Anton, I didn't have to time to do fresh set of benchmarks for llvm-gfortran from 2.4 and current gcc trunk. I'll do that this weekend. However I suspect I'll see similar behavior as before. Compared to FSF gcc 4.2, llvm-gfortran will show improvements but it won't be as impressive compared to gcc trunk. Is there a projected date for supporting the vectorization in llvm for the

On Jan 10, 2008, at 10:29 AM, Thomas Jablin wrote: > Hi, > > I've figured out a little more. #if defined DBX_DEBUGGING_INFO || > XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, > neither is defined on Intanium. In gt-dbxout.h type_queue's uses are > unguarded and thus are undefined on Itanium. When I compared llvm- > gcc's > gt-dbxout.h

Introduction ----------------- Currently llvm-mca only accepts assembly code as input. We would like to extend llvm-mca to support object files, allowing users to analyze the performance of binaries. The proposed changes (which involve both clang and llvm) optionally introduce an object file section, but this can be stripped-out if desired. For the llvm-mca binary support feature to be useful, a

The attached patch implements iasm_memory_clobber so that cc1 links correctly on arm targets. Best Regards, Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc.patch Type: application/octet-stream Size: 570 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20061003/947791cb/attachment.obj>

Since it came up, what is blocking us from putting these tests in the llvm-gcc test suite instead of in the LLVM test suite? - Daniel On Tue, Jul 14, 2009 at 4:01 AM, Jakob Stoklund Olesen<stoklund at 2pi.dk> wrote: > > On 14/07/2009, at 12.35, Harel Cain wrote: >> When using "make check" with the DejaGNU test collection, I encounter >> two unexpected failures

On Tue, Jul 20, 2010 at 6:49 AM, Rafael Espindola <espindola at google.com> wrote: >> export PATH="$LLVMPREFIX/bin:$LLVMGCCPREFIX/bin:$PATH" >> export CC="llvm-gcc -use-gold-plugin -Wl,-plugin-opt=also-emit-llvm" >> export CXX="llvm-g++ -use-gold-plugin -Wl,-plugin-opt=also-emit-llvm" >> export RANLIB=/bin/true >> export

Just working on some of the gmlt+fission debug info stuff and I came across a comment that might be relevant to reducing the number of distinct debugloc metadata nodes: "or some sub-optimal metadata that // isn't structurally identical (see: file path/name info from clang, which // includes the directory of the cpp file being built, even when the file name // is absolute (such as

Hi, I've figured out a little more. #if defined DBX_DEBUGGING_INFO || XCOFF_DEBUGGING_INFO guards the declaration of type_queue, however, neither is defined on Intanium. In gt-dbxout.h type_queue's uses are unguarded and thus are undefined on Itanium. When I compared llvm-gcc's gt-dbxout.h with FSF gcc's, I found that type_queue was never used in FSF gcc's version. Does