Displaying 20 results from an estimated 40000 matches similar to: "On CLI SIP don't appear"
2010 May 22
1
Manual Web-meetme
Hi anyone,
I need to install an application to organize conference in Asterisk, and to this I wanna use webmeetme, but I don't get find a good manual, anyone have or know where I can find a good manual to this application?
Thank you very much.
Renato
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
2010 Apr 15
1
How can I record the conversations in a conference call?
Hello,
I wanna record the conversations in a conference call, anyone know how can I do it? I've already configurated a room on meetme.conf but I don't know as I can record the conversations.
I'm using SUSE 11 and Asterisk 1.6.2.
Thank you so much for help me.
Bye
____________________________________________________________________________________
Veja quais s?o os
2014 Jan 07
2
[LLVMdev] AArch64 Clang CLI interface proposal
Parsing the arch string is a bit icky, but I don't really have too much of
a problem with it - and it's better than -mcpu so...
-eric
On Tue Jan 07 2014 at 9:23:43 AM, Renato Golin <renato.golin at linaro.org>
wrote:
> On 7 January 2014 17:05, Amara Emerson <amara.emerson at arm.com> wrote:
>
> We plan on implementing this interface for AArch64 Clang in future, and
2014 Jan 09
2
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
I think that this works (and adds no appreciable driver complexity) provided
that we're not expecting to support -mtune. If clang is (one day) going to
be able to isel based on one target and optimize based on another then we
might find ourselves wanting to change the meaning of -march from 'isel and
optimize' to 'isel only'. So Amara's question about -mtune (or more
2014 Jan 08
7
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
I knew I'd regret leaving that option in for the MIPS port back in 99.
Basically this is the only acceptable way for mcpu to exist, but should
never have been added to the GCC aarch64 port at all since there's no
compatibility with existing build systems to worry about.
I would still like you to show this mythical piece of software that needs
this compatibility.
-eric
On Jan 8, 2014 3:06
2014 Jun 25
2
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
On 25 June 2014 12:58, James Molloy <james at jamesmolloy.co.uk> wrote:
> This is one of the worst parts about the Clang CLI for cross compilation at
> the moment. I'd really like, if we're changing the CLI, to allow users to
> remove it. For example, if I specify -march=armv7-a, it *shouldn't* need me
> to put "-target arm" before it to work!
Good lord,
2013 Aug 16
0
[LLVMdev] running spec2006 with clang
On 08/16/2013 01:42 PM, Renato Golin wrote:
> On 16 August 2013 20:02, reed kotler <rkotler at mips.com
> <mailto:rkotler at mips.com>> wrote:
>
> -std=gnu89 is not valid for c++
>
>
> I think the point here is that this is the default std for GCC but not
> Clang, so you have to force clang to behave like GCC. For C++, you'll
> have to force
2013 Aug 16
2
[LLVMdev] running spec2006 with clang
On 16 August 2013 20:02, reed kotler <rkotler at mips.com> wrote:
> -std=gnu89 is not valid for c++
>
I think the point here is that this is the default std for GCC but not
Clang, so you have to force clang to behave like GCC. For C++, you'll have
to force whatever default GCC has for it's C++ standard.
Though, GCC 4.8 is getting very close to Clang's behaviour, so
2014 Jan 08
4
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
On 8 January 2014 12:32, Bernard Ogden <Bernard.Ogden at arm.com> wrote:
> I don't think there's software that *needs* the compatibility, but it is
> easier for GCC projects to switch to clang if that compatibility is there -
> which I think is why we go for GCC compatibility in the first place?
>
Hi Bernie,
GCC compatibility is always considered to be an important
2010 Jun 16
2
[LLVMdev] [PATCH] ARM MC relocations
Sorry, I have been very behind on patch reviews. Bob and Jim, do you have any opinions about this?
Evan
On Jun 2, 2010, at 5:18 AM, Renato Golin wrote:
> Hi,
>
> Is there any interest in this patch? Is there any better way of doing this (that will be accepted mainstream)?
>
> I noticed my cast check was wrong (LLVM cast asserts, rather than return a null pointer). Also,
2010 May 28
1
[LLVMdev] Patch proposal: ARM MC relocations
Hi all,
I did some changes to the AsmPrinter in order to print relocation
information in GAS format compatible with ARM ELF. It doesn't look like the
best solution, but there were some problems and the fact that this is my
first attempt to change LLVM.
My original assumption was that, changing MCExpr to accept relocation
information, we could propagate that down later to whatever gets
2014 Jun 25
3
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
Hi,
Recently, I committed a patch adding default features for '-mcpu'. And
after that, Eric replied me here's a proposal toward using '-march' instead
of '-mcpu'. As it's half a year later from original proposal, some
background may changes. One thing worth to mention is, during this time,
Apple Contributed its backend and introduced another new CPU type: cyclone.
2016 Sep 05
2
[cfe-dev] Many bots don't build anything -- does anyone know why?
On 5 September 2016 at 22:12, Renato Golin <renato.golin at linaro.org> wrote:
> Should we revert this? This is pretty serious? Can we fix this quickly
> on the bots?
Just FYI, I'm moving the "llvm" directory away and making it as a
symlink to "llvm.src", at least until we sort out this problem.
Since this has been going on from Sep 1st, I believe we'll
2011 Oct 04
0
[LLVMdev] LLVM IR is a compiler IR
On Tue, Oct 4, 2011 at 6:36 PM, Renato Golin <rengolin at systemcall.org> wrote:
> Hi Talin,
>
> I too agree 100% with Dan's words, and this could be a good pointer
> for Jin-Gu Kang to continue on his pursuit for a better
> target-independent bitcode.
>
> Also, add your backwards compatibility issue to debug metadata in IR,
> in which fields appear or disappear
2011 Oct 04
3
[LLVMdev] LLVM IR is a compiler IR
Hi Talin,
I too agree 100% with Dan's words, and this could be a good pointer
for Jin-Gu Kang to continue on his pursuit for a better
target-independent bitcode.
Also, add your backwards compatibility issue to debug metadata in IR,
in which fields appear or disappear without notice.
But I think you hit a sweet spot here...
On 4 October 2011 21:23, Talin <viridia at gmail.com> wrote:
2014 Jan 07
2
[LLVMdev] AArch64 Clang CLI interface proposal
Hi,
Clang for AArch64 currently accepts an -mfpu option to specify the FPU/NEON
unit. This behaviour, while consistent with the ARM target and ARM gcc, will
no longer be supported in AArch64 gcc. The preferred CLI for specifying
FPU/NEON units will be the use of the -march option with feature modifiers
(+[no]feature). The feature modifiers according to the GCC manual are:
* crypto
* fp
* simd
2014 Jan 27
2
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
Ping. Can I assume that we're ok with this interface proposal then?
Amara
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140127/49962cbc/attachment.html>
2014 Jun 25
2
[LLVMdev] [cfe-dev] AArch64 Clang CLI interface proposal
On 25 Jun 2014, at 12:58, James Molloy <james at jamesmolloy.co.uk> wrote:
> This is one of the worst parts about the Clang CLI for cross compilation at the moment. I'd really like, if we're changing the CLI, to allow users to remove it. For example, if I specify -march=armv7-a, it *shouldn't* need me to put "-target arm" before it to work!
One thing that I've
2010 Jun 16
0
[LLVMdev] [PATCH] ARM MC relocations
Is there a way to handle this entirely in the ARM AsmPrinter bits? Adding pieces to the generic MC stuff feels a bit like overkill at first impression.
On a minor note:
You probably want dyn_cast<> instead of cast<> so you can do something like:
if (const MCSectionELF* SectionELF = dyn_cast<MCSectionELF>(Section)) {
// ...
}
-Jim
On Jun 16, 2010, at 3:44 PM, Evan Cheng
2016 Jul 06
2
llvm 3.8.1 Release
We just wanted to check to see if they are real bugs first. We will report them if they are not already fixed. Thanks.
Del
From: Renato Golin [mailto:renato.golin at linaro.org]
Sent: Wednesday, July 6, 2016 12:07 AM
To: Del Myers <delmyers at microsoft.com>
Cc: LLVM Dev <llvm-dev at lists.llvm.org>
Subject: RE: [llvm-dev] llvm 3.8.1 Release
Did you report the bugs? It would be a