Displaying 20 results from an estimated 2000 matches similar to: "[LLVMdev] varargs heads up"
2004 Sep 29
0
[LLVMdev] LLVM build error (sparc gcc 3.2.2)
On Wed, Sep 29, 2004 at 06:44:50PM -0400, Shukang Zhou wrote:
> I met some errors when I tried to build LLVM. The tar file is
> llvm-1.3.tar.gz. I am using a sparc machine with gcc 3.2.2.
>
> -------------
> Compiling SparcV9CodeEmitter.cpp
> /uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp: In
> static member function `static void
>
2016 Dec 12
1
Problem about 128bit floating-point operations in x86 machines
Hello,
I'm making a compiler utilizing LLVM.
Because I want the compiler to support 128bit floating-point operations, I
added the code for 128bit floating-point operations and tested these
operations in i686, x86_64, SPARCv8 and SPARCv9 machines.
Generated codes by LLVM operated normally when using x86_64, SPARCv8 and
SPARCv9 machines, but generated codes in a x86 machine produce wrong
2005 Jan 28
2
[LLVMdev] llc -load
Howdy everybody.
I'm trying hard to load my backend. But I got problems.
I took the target SparcV8 for lab.
1. mark all of the code in the bool
SparcV8TargetMachine::addPassesToEmitAssembly(PassManager
&PM,std::ostream &Out)
and make it return false.( Of course I mark the // Output assembly language.
PM.add(createSparcV8CodePrinterPass(Out, *this));)
2. generate the
2005 Oct 24
2
[LLVMdev] [patch] Fix problems with build LLVM using gcc 4.1.0 (gcc CVS mainline)
Hi!
I have some problems with build current CVS version LLVM using GCC 4.1.0
(GCC CVS mainline version).
1) Build terminate with error:
llvm[3]: Compiling SparcV8CodeEmitter.cpp for Debug build
/usr/home/wanderer/pkg/build/llvm/obj/lib/Target/SparcV8/SparcV8GenCodeEmitter.inc:11:
error: definition of 'unsigned int
2004 Sep 29
4
[LLVMdev] LLVM build error (sparc gcc 3.2.2)
Hi,
I met some errors when I tried to build LLVM. The tar file is
llvm-1.3.tar.gz. I am using a sparc machine with gcc 3.2.2.
-------------
Compiling SparcV9CodeEmitter.cpp
/uf24/zhou/research/llvm/src/lib/Target/SparcV9/SparcV9CodeEmitter.cpp: In
static member function `static void
llvm::<unnamed>::JITResolver::CompilationCallback()':
2005 Apr 22
0
[LLVMdev] tabs
I found 179 more *.{c,cpp,h} files with tabs. Unfortunately, the tabs
stops used vary so blindly expanding them messes up alignment in many
cases :(
Index: examples/BFtoLLVM/BFtoLLVM.cpp
Index: include/llvm/AbstractTypeUser.h
Index: include/llvm/GlobalVariable.h
Index: include/llvm/InstrTypes.h
Index: include/llvm/IntrinsicInst.h
Index: include/llvm/ADT/PostOrderIterator.h
Index:
2010 Feb 03
4
[LLVMdev] [patch] SPARCV9 subtarget support
Hi all,
I've put together some preliminary patches to add frontend support for the sparcv9-* subtarget (ie 64-bit SPARC), modelled on the corresponding x86-64 code - do these look reasonable for inclusion? This doesn't address the codegen side of things yet (isel falls over when trying to actually emit 64-bit code), but at least bitcode generation looks correct now. Tested on
2005 Oct 24
0
[LLVMdev] [patch] Fix problems with build LLVM using gcc 4.1.0(gcc CVS mainline)
On Mon, 24 Oct 2005, Vladimir A. Merzliakov wrote:
>>> 2) Same error but some diff. problem with AlphaCodeEmitter.cpp and
>>> PPCCodeEmitter.cpp:
>>>
>>> GCC don't like definition member-functions in global namespace with
>>> declaration in llvm::<unnamed> :
>
> Sorry for wrong comment.
> Must be:
> GCC 4.1.0 don't like
2005 Oct 24
1
[LLVMdev] [patch] Fix problems with build LLVM using gcc 4.1.0(gccCVS mainline)
>> Sorry for wrong comment.
>> Must be:
>> GCC 4.1.0 don't like definition member-functions in llvm namespace with
>> declaration in <global>::<unnamed> namespace
>
> Ahhh, ok, I see. I just applied a patch to SparcV8. With it, does this
> patch fix the problem?
>- o << "namespace llvm {\n\n";
>+ //o <<
2018 May 04
5
ASan port for Myriad RTEMS
I have ported ASan in LLVM to Myriad RTEMS, and I would like to
upstream the port. Below is the design doc. Feedback welcome.
https://docs.google.com/document/d/1oxmk0xUojybDaQDAuTEVpHVMi5xQX74cJPyMJbaSaRM
The port is expected to work with modified versions of RTEMS and
newlib. I have a git repo with changes to those projects, that I can
make available if there is interest.
Here is the patch
2010 Aug 16
19
v2.0.0 released
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig
As promised last Friday, here's the v2.0.0 release finally. I'm
cautiously optimistic that v2.0.1 won't (have to) be released for a few
weeks, since there was quite a lot of testing and fixing going on in the
RC stage.
Remember to read http://wiki2.dovecot.org/Upgrading/2.0
2010 Aug 16
19
v2.0.0 released
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz
http://dovecot.org/releases/2.0/dovecot-2.0.0.tar.gz.sig
As promised last Friday, here's the v2.0.0 release finally. I'm
cautiously optimistic that v2.0.1 won't (have to) be released for a few
weeks, since there was quite a lot of testing and fixing going on in the
RC stage.
Remember to read http://wiki2.dovecot.org/Upgrading/2.0
2009 Apr 21
0
[LLVMdev] MSIL backend: external varargs signatures printing
Hi,
After discussion with Anton, I did the whole thing in a little bit different
way (please see the attached patch). It again looks like reinvented wheel
for LLVM experts, I suppose, but it works. What I want to achieve is to
generate real (with all variadic arguments) call signature for each variadic
and external function, without the "vararg" keyword and without the "...",
2016 Jan 28
1
[cfe-dev] Adding sanity to the Atomics implementation
On Thu, Jan 28, 2016 at 08:32:31AM -0800, Reid Kleckner via llvm-dev wrote:
> I think Clang should continue to duplicate this information, the same way
> we duplicate target datalayout strings. Other than that, sure, we can let
> LLVM expand IR operations to libcalls. I don't immediately see a problem
> with that.
Note that a libcall doesn't necessarily mean using locks. With
2018 May 04
0
ASan port for Myriad RTEMS
Hi Walter,
I've done a first quick scan.
Overall looks reasonable, but I'd like to try reducing the number of newly
introduced platform-specific ifs.
Vitaly, please also take a look (once my initial comments are addressed).
One outstanding issue is your problem with initialization vs checking,
which requires you to insert so many ifs.
Is there any chance you can avoid this?
If you
2005 Feb 14
0
LLVM February Status Update
Hi Everyone,
Sorry for the long overdue status update, as you might guess, the holidays
have been busy for everyone. :)
Here's your periodic dose of updates on the progress of LLVM, which takes
us from the LLVM 1.4 release until present CVS. I appologize if I forgot
anything!
Big Things:
1. Brian contributed a new SparcV8 backend, which (unlike the SparcV9
backend) uses the
2018 May 04
0
ASan port for Myriad RTEMS
Hey,
I work on fuchsia symbolizer stuff. I don't know if you guys already have
an external symbolizer but I'm working on making one right now and I plan
on making one backed by LLVM that can be run host-side or target-side. I'd
like to contribute that back to llvm ideally. What do you guys have so far?
I have a prototype in golang that just spins up an instance of
llvm-symbolizer
2018 May 05
1
ASan port for Myriad RTEMS
Hi Jake. Thanks for the info. Where can I keep up to date on the
symbolizer status?
Our symbolizer is provided by the Myriad vendor and integrated into its
host test environment. It doesn't do much: just look for PC string
patterns and symbolize them using addr2line.
Thanks,
Walter
On Fri, May 4, 2018 at 5:36 PM Jake Ehrlich <jakehehrlich at google.com> wrote:
> Hey,
> I
2007 Aug 21
0
[LLVMdev] lowering varargs, rewriting types
Hi,
I'm looking at writing a custom backend targetting a proprietary virtual
machine. I'm basing it on the existing C and MSIL backends.
The VM has a defined ABI for varargs functions: the caller allocates some
memory to hold the arguments and passes a pointer to this memory as an extra
parameter in the call. I'd like to write a varargs lowering pass that
represents this ABI
2018 May 05
2
ASan port for Myriad RTEMS
Hi Kostya. Thanks for the quick feedback. I will work on addressing your
comments.
In regard to initialization checks, I can eliminate most of them by
initializing the shadow memory very early, but I still need to do something
in two places, __asan_handle_no_return and GetFakeStackFast. Would it be
ok to have guards for those two places only?
Walter
On Fri, May 4, 2018 at 6:10 PM Kostya