similar to: LibCallAliasAnalysis class instantiation parameter

Hi Dmitri, For what version of VS did you update the project files? Ted On May 17, 2008, at 3:00 PM, Dmitri Makarov wrote: > attached is the diff of vcprojs that need to be changed to fix the VS > build as of revision: 51224. > > I don't know if this catches all the missing bits, but this does build > all the way through. > > > Index: win32/Analysis/Analysis.vcproj

A warning: R:\SDKs\llvm\trunk\include\llvm/Analysis/LibCallSemantics.h(63) : warning C4099: 'llvm::LibCallFunctionInfo' : type name first seen using 'class' now seen using 'struct' R:\SDKs\llvm\trunk\include\llvm/Analysis/LibCallAliasAnalysis.h(22) : see declaration of 'llvm::LibCallFunctionInfo' The problem line appears to be in file

attached is the diff of vcprojs that need to be changed to fix the VS build as of revision: 51224. I don't know if this catches all the missing bits, but this does build all the way through. -------------- next part -------------- An embedded and charset-unspecified text was scrubbed... Name: msvs.patch URL:

I tried to compile on Windows ( using the win32/llvm.sln in MSVC Express 2008 ) the new 2.3 branch and here are the results: 1. I needed to copy the file Configure.exe.embed.manifest to Configure.exe.intermediate.manifest . This is a bug from the previous llvm release (2.2) 2. I copied the file SimplifyLibCalls.cpp from lib/Transforms/Scalar to lib/Transforms/IPO. I think the position of

On May 11, 2008, at 12:59 PM, Razvan Aciu wrote: > I tried to compile on Windows ( using the win32/llvm.sln in MSVC > Express > 2008 ) the new 2.3 branch and here are the results: It would be great to get any windows improvements into the 2.3 release if possible. > 1. I needed to copy the file Configure.exe.embed.manifest to > Configure.exe.intermediate.manifest . This is a

Razvan Aciu wrote: > As I saw from the mailing list the MSVC 2005 patches were made to take into > account the new files from the development branch, files which are not in > the 2.3 release. So for now the below patch is the only one functional for > the release. If I am wrong, please someone correct me. > > If someone can make a 2005 patch for the release branch, it is ok.

I think the simplest, most complete, short term fix, would be to call llvm::colorEHFunclets, and to have the relevant instrumentation passes apply the appropriate funclet bundle when inserting function calls. It's not elegant because it means every simple instrumentation pass that inserts regular function calls (ASan, TSan, MSan, instrprof, etc) needs to be funclet-aware. But, it will work,

Hi, Does your pass use multiple inheritance? Sounds like your problem is that you need to define getAdjustedAnalysisPointer, see: http://llvm.org/docs/doxygen/html/classllvm_1_1Pass.html#a03d3a81b1c46aff7c38ef3a6750ba225 An example implementation (very likely exactly what you want) is in LibCallAliasAnalysis: http://llvm.org/docs/doxygen/html/LibCallAliasAnalysis_8h_source.html#l00060 Hope

I think this is the same underlying issue as https://bugs.llvm.org/show_bug.cgi?id=40320. CCing Reid, who's had a bunch of thoughts on this in the past. On 1/11/20, 10:25 AM, "llvm-dev on behalf of Chrulski, Christopher M via llvm-dev" <llvm-dev-bounces at lists.llvm.org on behalf of llvm-dev at lists.llvm.org> wrote: Hi, I've run into a bug with the LLVM

Not that I sympathize with the OP's manners but... Bill Wendling <isanbard at gmail.com> writes: > On May 10, 2008, at 7:55 PM, kr512 wrote: > >> See how gcc is invoked to generate the final executable >> file. This means LLVM is an incomplete backend, >> unfortunately. >> > That's only a convenience. GCC generates assembly code too and calls

Our frontend can guarantee that loads from globals are rematerializable and do not alias with any stores in any function in the given module. We'd like the optimization passes (and ideally the register allocator as well) to be able to use this fact. The globals are not constant "forever" but are constant during the calling of any given function in the module. There seem to

Hi, I have a data frame with two columns. I need to remove duplicated rows in first column, but I need to do it conditionally to values of the second column. Example: Point_counts Psi_Sp 1 A 0 2 A 1 3 B 1 4 B 2 5 B 0

Hi, I came across an issue where some optimizations that would normally be applied to standard math function calls are not getting applied when the –ffast-math option is enabled on the Clang command line on a Linux x86_64 target. I tracked down the issue to occurring because the –ffast-math option is triggering Clang to preprocess the math.h header file with the __FINITE_MATH_ONLY__ macro set

Hi, I am now trying to write an alias analysis pass for LLVM 3.1. The pass is compiled into a .so library. When I loaded it into opt to perform evaluation with command: opt -load my-so-lib -aa-eval foo.bc the following errors occurred: opt: raw_ostream.cpp:261: void llvm::raw_ostream::flush_nonempty(): Assertion `OutBufCur > OutBufStart && "Invalid call to

libswfdec/swfdec_movie.c | 91 ++++++++++++++++++++++++++++++------ libswfdec/swfdec_movie.h | 7 ++ libswfdec/swfdec_player.c | 57 ++++++++++++++++------ libswfdec/swfdec_player_internal.h | 12 +++- libswfdec/swfdec_sprite_movie_as.c | 75 +++++++---------------------- vivified/core/vivi_application.c | 37 ++++++--------

SimplifyLibCalls.cpp is no longer part of Transforms\IPO and Transforms\Scalar\SimplifyCFG.cpp is renamed to SimplifyCFG.cpp or something to that effect ( I didn't look up the actual checkins ). Having fixed that, I still can't get through the build: Creating library C:\work\s\llvm\win32\\bin\Win32\Debug/opt.lib and object C:\work\s\llvm\win32\\bin\Win32\Debug/opt.exp 1>opt.obj : error

Hello, I've noticed a following strange behavior: clang-3.2 fails to compile/parse any assembly code that invokes macros which named arguments contains non alphanumeric characters. For example, compilation of the following code snippet would fail with "Parameter not found" error: .macro mov_macro reg_1, reg_2 movl %\reg_1, %\reg_2 .endm mov_macro eax, ebx Although, if one

When enabling both VFIO and VIRTIO_IOMMU modules, automatically select VFIO_IOMMU_TYPE1 as well. Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com> --- drivers/vfio/Kconfig | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/vfio/Kconfig b/drivers/vfio/Kconfig index c84333eb5eb5..65a1e691110c 100644 --- a/drivers/vfio/Kconfig +++

On 14/02/18 15:26, Alex Williamson wrote: > On Wed, 14 Feb 2018 14:53:40 +0000 > Jean-Philippe Brucker <jean-philippe.brucker at arm.com> wrote: > >> When enabling both VFIO and VIRTIO_IOMMU modules, automatically select >> VFIO_IOMMU_TYPE1 as well. >> >> Signed-off-by: Jean-Philippe Brucker <jean-philippe.brucker at arm.com> >> --- >>

Dear All, A small inconsistency (it's probably not even a buglet): > setClass("A", contains="numeric") [1] "A" > names(new("A", c(a=23))) [1] "a" > setClass("B", contains="A") [1] "B" > names(new("B", c(a=23))) NULL > This is exactly that kind of behavior S4 was invented for, you