search for: decling

On 9/1/06, Chris Lattner <sabre at nondot.org> wrote: > On Fri, 1 Sep 2006, Michael McCracken wrote: > > I wanted to know if I should submit patches with comments around them > > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > > the tree. I'd like to make it as easy as possible to apply these, so > > let me know any rules I

When support for decl.Atomic and .Shared was added, tgsi_build_declaration was not updated to propagate these properly. Signed-off-by: Hans de Goede <hdegoede at redhat.com> Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- Changes in v2: -Add Reviewed-by: Ilia Mirkin <imirkin at alum.mit.edu> --- src/gallium/auxiliary/tgsi/tgsi_build.c | 6 ++++++ 1 file changed, 6

Hi, Here are patches which implement the support for OpenCL kernel input parameters we discussed. They also add the tgsi parsing bits for adding support for global / local mem, but no implementation yet. Regards, Hans

CentOs zoneminder users, I have been trying to install zoneminder on Centos 5.3 (2.6.18-128.1.16.el5xen) and have hit a brick wall with ffmpeg which zoneminder has as a dependancy. There were no rpm's in centos or rpmforge so I have followed the instructions on the zoneminder website for a CentOs install. I have posted a note on the zoneminder list, but have not been able to get any takers

On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > Extend the MEMORY file support to differentiate between global, local > and shared memory, as well as "input" memory. > > "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a > special memory type is added for this, since the actual storage of these > (e.g.

Hi all, This patch is to fix a problem on PPC64 where an unaligned memcpy is generated. The testcase is this: $ cat testcase.c void Qux() { char Bar[11] = {0}; } What happens is that we produce LLVM code like this: call void @llvm.memcpy.i64( i8* %event_list2, i8* getelementptr ([11 x i8]* @C.103.30698, i32 0, i32 0), i64 11, i32 8 ) Notice that it has an 8-byte alignment. However, the Bar

Extend the MEMORY file support to differentiate between global, local and shared memory, as well as "input" memory. "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a special memory type is added for this, since the actual storage of these (e.g. UBO-s) may differ per implementation. The uploading of kernel parameters is handled by launch_grid,

Extend the MEMORY file support to differentiate between global, private and shared memory, as well as "input" memory. "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a special memory type is added for this, since the actual storage of these (e.g. UBO-s) may differ per implementation. The uploading of kernel parameters is handled by launch_grid,

On Nov 6, 2007, at 5:45 PM, Bill Wendling wrote: > $ more testcase.c.t03.generic > Qux () > { > static char C.0[11] = {0}; > char Bar[11]; > > Bar = C.0; > } > > Anyway, it turns out that the gimplifier was generating the correct > alignment, but it was being overridden in assemble_variable(): > > /* On some machines, it is good to increase alignment

Hi all, Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. While I don’t necessarily think it’s ideal to ignore all noreturn decls, I think there’s definitely room for some heuristics around ignoring things like llvm_unreachable (perhaps opt-in?). I’m

On Fri, 1 Sep 2006, Michael McCracken wrote: > Hi, I have a first quick patch and a question. The patch links f951 > with g++ when LLVM is enabled. It's at the end of this email. Thanks, applied! > I wanted to know if I should submit patches with comments around them > like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to > the tree. I'd like to

Hi, On 10-03-16 16:35, Aaron Watry wrote: > On Thu, Mar 10, 2016 at 9:14 AM, Hans de Goede <hdegoede at redhat.com> wrote: > >> Extend the MEMORY file support to differentiate between global, local >> and shared memory, as well as "input" memory. >> >> "MEMORY[x], INPUT" is intended to access OpenCL kernel parameters, a >> special

+ cfe-dev > On Mar 28, 2016, at 1:23 PM, Harlan Haskins via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi all, > > Recently I’ve noticed in coverage profiles that llvm_unreachable and the like are considered uncovered because there’s no special behavior in instrumentation to ‘ignore’ noreturn paths. FWIW, Daniel Dunbar and a few others have brought up the lack of a

Hi, I have a first quick patch and a question. The patch links f951 with g++ when LLVM is enabled. It's at the end of this email. I wanted to know if I should submit patches with comments around them like the "APPLE LOCAL LLVM" ones that mark the LLVM-only changes to the tree. I'd like to make it as easy as possible to apply these, so let me know any rules I should be following.

Hello, I recently ran into an issue where I wanted to use dyn_cast with a Multiple Inheritance hierarchy. LLVM’s help page on RTTI claims that it can be done, and that Clang’s Decl and DeclContext implement it; however, when I try to use it I run into odd behavior. Here’s my sample code which doesn’t work: ``` struct Base { void *ptr; bool hasInfo; }; struct Info { int size; static

On Sep 21, 2007, at 5:11 PM, Bill Wendling wrote: > > My question is, is this liable to break something else down the line? > Should it be modified to call the getNamedGlobal method only if it's > an Objective-C property? Is this even the correct method for an > Objective-C property? There is a bigger question here. One invariant that is useful is that there is only a

On Sun, Oct 23, 2011 at 10:34 PM, James Molloy wrote: > Hi, > > I haven't seen those errors. Clang and LLVM both build with no warnings on the 3 versions of GCC I test with. MSVC reports loads of warnings however. > $ make happiness ... Updated to revision 142790. ... make[4]: Entering directory `/home/ecsardu/LLVM/build-tcclab1/tools/clang/tools/libclang' llvm[4]: Compiling

FreeBSD 9.3 Dovecot 2.25 (7be1766) I'm trying to install Dovecot2-pigeonhole-0.4.14_2 from ports. Get an error: cc1: error: unrecognized command line option "-Wno-duplicate-decl-specifier" With options MAKE_JOBS_UNSAFE=yes: cc1: error: unrecognized command line option "-Wno-duplicate-decl-specifier" *** [edit-mail.lo] Error code 1 Stop in

I am installing SPLASH(http://www-flash.stanford.edu/SPLASH/) benchmark codes on CentOS 4.6. And there is compile error during make.. Here is the error messages. Does it come from the gcc library? Should I update the gcc or other library? [root at localhost barnes]# make BARNES make: Warning: File `code.C' has modification time 6e+02 s in the future m4 -s -Ulen -Uindex

W dniu 23.09.2015 o 15:30, Timo Sirainen pisze: > http://dovecot.org/releases/2.2/rc/dovecot-2.2.19.rc1.tar.gz > http://dovecot.org/releases/2.2/rc/dovecot-2.2.19.rc1.tar.gz.sig > > A lot of changes since v2.2.18, so here's a release candidate first. If no bugs are reported, I'm planning on making the final release sometimes this week. The most interesting new features here