Displaying 20 results from an estimated 439 matches for "disambiguous".
Did you mean:
isambiguous
2013 Jul 11
1
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wednesday 10 July 2013 22:18:23 Jevin Sweval wrote:
> http://www.cs.fsu.edu/~baker/devices/lxr/http/source/linux/arch/x86/include/
> asm/bitops.h#L68
>
> Here is one example that I found. Are the inline assembly arguments
> ambiguous in size?
It would help us for sure to build the kernel and others.
--
JS
2013 Jul 10
3
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra
<artagnon at gmail.com> wrote:
> The instructions btr and bts are perfectly valid, and have existed since
> Intel 386. GNU as supports them fine. Unfortunately, LLVM does not
> support them, and barfs with:
>
> error: ambiguous instructions require an explicit suffix
>
> Fix this problem by disambiguating it
2009 Feb 18
4
Disambiguate List Item Followed by Code Block
Howdy,
Quick question: Since list items with multiple paragraphs need to be
indented four spaces, and code blocks are also indented four spaces,
is there any way to disambiguate a list followed by a code block?
Example:
* This is a list
item.
* And so is this.
Is this a second paragraph in the second list item,
or a code block?
It looks like Markdown.pl and discount
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Also, please elaborate on why this is a good change. Because gas accepts it isn’t sufficient reason in and of itself.
-Jim
On Jul 10, 2013, at 1:18 PM, Eli Friedman <eli.friedman at gmail.com> wrote:
> On Wed, Jul 10, 2013 at 12:29 PM, Ramkumar Ramachandra
> <artagnon at gmail.com> wrote:
>> The instructions btr and bts are perfectly valid, and have existed since
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote:
> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants.
>
> The best reference I know of for the AT&T syntax is: http://docs.oracle.com/cd/E19253-01/817-5477/817-5477.pdf
I'm not sure
2020 Jul 07
3
BUILD_VECTOR disambiguation
Thanks for the clarification. The `except` seemed dangling to me, but
it's early here.
Just curious... how do we end up with a mixed type BUILD_VECTOR?
That's counterintuitive.
On Tue, Jul 7, 2020 at 10:58 AM Krzysztof Parzyszek via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Mixed integer types are ok, but the values will get truncated to the element type of the output
2020 Jul 07
2
BUILD_VECTOR disambiguation
Mixed types aren't allowed. They are checked for in VerifySDNode in
SelectionDAG.cpp and will fail an asserts build.
~Craig
On Tue, Jul 7, 2020 at 8:25 AM Krzysztof Parzyszek via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> The problem can happen when you want to build a vector of i8, but i8
> itself is not legal on your target. All operands to BUILD_VECTOR will be
>
2007 Mar 21
0
[909] branches/wxruby2/wxwidgets_282/doc/textile/combobox.txtl: Correct disambiguated method names in methods listing
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN"
"http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head><meta http-equiv="content-type" content="text/html; charset=utf-8" /><style type="text/css"><!--
#msg dl { border: 1px #006 solid; background: #369; padding:
2020 Jul 07
3
BUILD_VECTOR disambiguation
Hey devs,
>From ISDOpcodes.h...
/// BUILD_VECTOR(ELT0, ELT1, ELT2, ELT3,...) - Return a fixed-width vector
/// with the specified, possibly variable, elements. The number of elements
/// is required to be a power of two. The types of the operands must all be
/// the same and must match the vector element type, except that integer types
/// are allowed to be larger than the element type, in
2013 Jul 11
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote:
> On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote:
>> The length specifier is, as I understand it, required when the instruction references memory but is optional (and inferred from the registers) for the register variants.
>>
>> The best reference I know of for the
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Wed, Jul 10, 2013 at 7:15 PM, Jim Grosbach <grosbach at apple.com> wrote:
>
> On Jul 10, 2013, at 6:54 PM, Stephen Checkoway <s at pahtak.org> wrote:
>
> On Jul 10, 2013, at 17:44, Jim Grosbach <grosbach at apple.com> wrote:
>
> The length specifier is, as I understand it, required when the instruction
> references memory but is optional (and inferred from
2005 Oct 06
8
accessing extra request parameters
hi all,
how are other people passing and accessing ''get'' parameters from their apps?
what is the best way to do it?
ie:
www.example.com/controller/action/id/extra/extra2/ ??
or
www.example.com/controller/action/id/~extra/extra2/
or what ever....
are there built in methods for passing and accessing extra parameters?
thanks for your suggestions
-felix
2013 Oct 11
0
[LLVMdev] Request for comments: TBAA on call
On Thu, Oct 10, 2013 at 9:34 PM, Chris Lattner <clattner at apple.com> wrote:
> On Oct 10, 2013, at 8:53 PM, Daniel Berlin <dberlin at dberlin.org> wrote:
>
> The datastructures and algorithms we have are powerful enough to express
>> these sorts of things, and so long as a frontend abided by the rules, there
>> shouldn't be a problem.
>>
>
>
>
2013 Jul 10
2
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> Also, please elaborate on why this is a good change. Because gas accepts it
> isn’t sufficient reason in and of itself.
That they're valid instructions isn't sufficient reason? Should I
additionally say that linux.git uses them?
I wrote:
> The instructions btr and bts are perfectly valid, and have existed since
> Intel 386.
2013 Jul 10
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
On Jul 10, 2013, at 1:44 PM, Ramkumar Ramachandra <artagnon at gmail.com> wrote:
> Jim Grosbach wrote:
>> Also, please elaborate on why this is a good change. Because gas accepts it
>> isn’t sufficient reason in and of itself.
>
> That they're valid instructions isn't sufficient reason? Should I
> additionally say that linux.git uses them?
>
Is the
2013 Jul 11
0
[LLVMdev] [PATCH] x86: disambiguate unqualified btr, bts
Jim Grosbach wrote:
> That does raise a clarifying question here. Is the code you’re interested in
> using Intel or AT&T syntax?
>
> Also note that the question isn’t whether we should support the btr/bts
> instructions. We absolutely must (and do). The question is whether we are
> properly handling the un-suffixed mnemonic form of the assembly syntax.
>
> Perhaps you
2013 Jul 17
0
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> Jim Grosbach wrote:
> > No. The above rule is absolutely the wrong thing to do, as has been
> > previously noted.
>
> I don't give a shit about whether you think it is "absolutely wrong"
> or not; I did what hpa and the Intel manual outlined. If you have
> some _reason_ not to do
2013 Jul 17
1
[LLVMdev] [PATCH v2] X86: disambiguate unqualified btr, bts
On Jul 17, 2013 7:41 AM, "Joerg Sonnenberger" <joerg at britannica.bec.de>
wrote:
>
> On Wed, Jul 17, 2013 at 11:54:21AM +0530, Ramkumar Ramachandra wrote:
> > Jim Grosbach wrote:
> > > No. The above rule is absolutely the wrong thing to do, as has been
> > > previously noted.
> >
> > I don't give a shit about whether you think it is
2004 Apr 05
2
Disambiguating incoming IAXTel calls
I have two 1-700 numbers from IAXTel. Both get registered from the same
Asterisk server. I can make and receive calls on each without any
difficulty. What I can't figure out how to do is route the incoming calls
differently based on which 1-700 number is dialed. I must be missing
something obvious.
Thanks
-brian
-------------- next part --------------
An HTML attachment was scrubbed...
2014 May 13
2
[LLVMdev] Instructions with overlapping encodings that are disambiguated by field comparisons
Hi,
I'm not sure how to handle some of the trickier instruction encodings in MIPS64r6. My problem is that some instructions determine the operation based on the relationship between two fields. For example, 'beqc $rs, $rt, offset' (branch if equal, no delay slot) and bovc (branch if addition would overflow, no delay slot) share the same major opcode and field layout. When the register