similar to: [LLVMdev] misaligned_stack_error caused by LLVM code on MacOS: how to fix?

Hello > What is the right way for fix this misaligned_stack_error? Codegen stuff for darwin, there are many other differences in Linux/Darwin ABIs. -- With best regards, Anton Korobeynikov Faculty of Mathematics and Mechanics, Saint Petersburg State University

Hi David/Renato, By AST I mean Abstract Syntax Tree. We are writing an optimization pass for some FORTRAN95 + MPI code that requires us to analyze the AST. We thought of 2 ways of doing this: 1. Compile the code using Clang/llvm-gfortran, get the textual AST dump (somehow), analyze the AST dump using Ruby, modify it and then feed back the modified AST to LLVM. 2. Do the analysis as an LLVM

2009/11/3 David Greene <dag at cray.com>: > Your best bet is to use llvm-gfortran.  I don't know what you mean by > "AST."  Do you really want an AST or something else (LLVM IR, something > higher-level, etc.)?  LLVM doesn't understand ASTs directly. Probably for high-level optimisations, or just to see if the parser is good, as I do in my compiler. But AST is

I have taken over some old Rails code and am trying to get the tests to run. In the functional test every time the assertion ''assert_redirected_to'' is called I get the following error: test_should_update_venue(VenuesControllerTest): NoMethodError: undefined method `[]'' for #<Enumerable::Enumerator:0x102f747e0>

Hello, After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: (I know I should fill a bug report instead of posting here, but I don't get much time right now). Trying to compile the following simple code, clang asserts. ---------- round.c -------- #include <math.h> float test() { return llround(1); } -------------------- [MacPro:~/Desktop]

On Nov 20, 2012, at 11:03 AM, Meador Inge <meadori at codesourcery.com> wrote: > On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > >> IR Changes >> ---------- >> >> The attributes will be specified within the IR. This allows us to generate code >> that the user wants. This also has the advantage that it will no longer be >> necessary to specify

On Dec 28, 2010, at 9:39 AM, Lup Gratian wrote: > I recently downloaded LLVM 2.8 and started playing with the optimizations a bit. > I saw something curious while trying the following function: > > int g(unsigned int a) { > unsigned int c[100]; > c[10] = a; > c[11] = a; > unsigned int b = c[10] + c[11]; > > if(b > a*2) a = 4; > else a = 8; >

On Nov 13, 2012, at 12:20 AM, Bill Wendling wrote: > IR Changes > ---------- > > The attributes will be specified within the IR. This allows us to generate code > that the user wants. This also has the advantage that it will no longer be > necessary to specify all of the command line options when compiling the bit code > (via 'llc' or 'clang'). E.g.,

Thanks! I also found test/CodeGen/ARM/ghc-tcreturn-lowered.ll, which tests only for thumbv7-eabi, so, i tried a few more variations: [x] arm64-apple-ios [x] arm64-apple-ios7.0.0 [x] arm64-apple-darwin [x] armv7-apple [x] thumbv7-apple [x] thumbv7-apple-darwin [x] i386-apple-ios [x] i386-apple-darwin [f] thumbv7-apple-ios [f] thumbv7-apple-ios7.0.0 [f] armv7-apple-ios I’ve also just build a

I recently downloaded LLVM 2.8 and started playing with the optimizations a bit. I saw something curious while trying the following function: int g(unsigned int a) { unsigned int c[100]; c[10] = a; c[11] = a; unsigned int b = c[10] + c[11]; if(b > a*2) a = 4; else a = 8; return a + 7; } The generated code, with -O3 activated, is define i32 @g(i32 a) nounwind readnone { %add = shl i32

I will take a look in the next couple hours. Feel free to revert it in the meantime, thanks! -Chris On Sep 22, 2010, at 1:53 AM, Jean-Daniel Dupas <devlists at shadowlab.org> wrote: > Hello, > > After commit r114523, I start to get crash when compiling with clang (Release+Asserts) for i386: > (I know I should fill a bug report instead of posting here, but I don't get

Hi! This is a proposal to expand the Attributes class to support many different options that will be accessible by all parts of the compiler. Please read and give any feedback you may have. Thanks! -bw Passing Options to Different Parts of the Compiler Problem ======= There is a growing need to pass information from the front-end to different parts of the compiler, especially

Hi Gabriel, I suggest you don't bother with testcases like this that are doing undefined things. For example, neither i nor k are initialized, so the result of accessing the array is undefined. Thus the frontend can (and apparently does) produce anything strange thing it does. What is more, the result aux is unused, so there is no obligation to compute it correctly. I think you will get

I have this test case in my frontend, which is triggering an assert in llvm master branch: fn fnWithAlignedStack() -> i32 { @setAlignStack(1024); return 1234; } It sets alignstack=1024 in the function attributes (see http://llvm.org/docs/LangRef.html#function-attributes). It's tripping an assert: llvm/lib/IR/Attributes.cpp:134: static llvm::Attribute

Dear All, As of late I am having a hard time getting my head around how array accesses are translated by Clang into LLVM IR: the often misunderstood GEP instruction. I am trying to reverse-engineer array accesses to discover the number of dimensions and actual indexes of the original, and I am beginning to wonder whether this is possible at all. To illustrate (some of) my troubles, consider

The following comment: 00881 // As a hack, we allow "align 2" on functions as a synonym for "alignstack 00882 // 2". in "lib/AsmParser/LLParser.cpp" appears inaccurate, the "alignment" is later parsed as the alignment of the function itself, both when directly placed on the function: 02975 // If the alignment was parsed as an attribute, move

I have recently been modifying the DWARF parser and have more patches planned and I want to be able to add unit tests that test the internal llvm DWARF APIs to ensure they continue to work and also validate the changes that I am making. There are not many DWARF unit tests other than very simple ones that test DWARF forms currently. I would like to expand this to include many more tests. I had

I'm open to other suggestions. The problem is that these functions service an incoming abi stack alignment that differs from the host's abi alignment. An alternative would be to have the 'alignstack' IR attribute itself reduce the incoming stack alignment assumption. i.e. if it's specified then it's fair to assume that the incoming stack does not have the correct

These were requested by Bill Wendling to simplify a Mips 16 clang change. The test is in the code in Clang which uses these for mips 16. -------------- next part -------------- Index: include/llvm/IR/Function.h =================================================================== --- include/llvm/IR/Function.h (revision 176874) +++ include/llvm/IR/Function.h (working copy) @@ -181,6 +181,14 @@

Hi, I'm trying to fix an issue with clang's __force_align_arg_pointer__ attribute. The problem is described here: https://llvm.org/bugs/show_bug.cgi?id=26662 The problem is affecting Wine (https://www.winehq.org/) where we have a function that is an entry-point for the x86 Win32 abi. That function may then call functions in the host's (linux, OS/X, ...) abi. The issue is that the