search for: variantion

Is this expected result for Chipset: G98 (NV98)? $ modinfo nvidia -F version 304.123 $ stat -c %s mmiotrace.log 134659197 $ file mmiotrace.log mmiotrace.log: ASCII text $ grep -i lost mmiotrace.log ; echo $? 1 $ ./envytools/rnn/demmio -f mmiotrace.log | perl -e 'open($fh409c, ">fuc409c"); open($fh409d, ">fuc409d"); open($fh41ac, ">fuc41ac");

Why the output is different for this below program when compiled using clang with fast-math optimization #include<stdio.h> int main() { double d = 1.0; double max = 1.79769e+308; d /= max; printf("d:%e:\n", d); d *= max; printf("d:%e:\n", d); return 0; } prints 0 with fast math but 1 without fast math. -------------- next part -------------- An

I installed the most current version of Wine and then installed Legacy 7.0 onto my Ubuntu 8.04. the installation seemed to 'take'. Unfortunately when I activate Legacy, all I get is a view 1/4 of the screen - not a full screen, just the upper left had corner which shows a partial Legacy screen. I did not get any 'runtime' errors - just the partial screen and the program will not

Hi Francesco, On 06/03, Francesco Petrogalli wrote: > > On Jun 3, 2019, at 1:43 PM, Andrea Bocci <andrea.bocci at cern.ch> wrote: > > as a candidate future user of the proposed extension, I think I like the simplified proposal better than the original RFC. > > > > The only part of the syntax that I would find not very much user-friendly is having to mangle the

>Although there are some "isohybrid.exe" around, there is no official support for them and they are also outdated. >The Syslinux mailing list already includes several emails about issues in the included isohybrid variants. I think that deleting either of them would be a mistake. At least users such as Ian might benefit from both being included. >Ideally, the Perl variant

# ./testcall testcall.conf Chan 1, class 'mfcr2', variant 'ar,10,4', end 1, caller 0, from '30025860' to '013331339767' Chan 2, class 'mfcr2', variant 'ar,10,4', end 1, caller 0, from '30025861' to '013331339768' Chan 3, class 'mfcr2', variant 'ar,10,4', end 1, caller 0, from '30025862' to

Hello, On Thu, 20 Jul 2017 11:36:55 +0200, Philipp Zabel wrote: > > I don't know if it has been discussed in the past, so forgive me if it > > has been. Have you considered adding a "int flags" argument to the > > existing reset_control_get_*() functions, rather than introducing > > separate exclusive variants ? > > > > Indeed, with a "int

Dear all, This RFC is a proposal to provide auto-vectorization functionality for user provided vector functions. The proposal is a modification of an RFC that I have sent out a couple of months ago, with the title `[RFC] Re-implementing -fveclib with OpenMP` (see http://lists.llvm.org/pipermail/llvm-dev/2018-December/128426.html). The previous RFC is to be considered abandoned. The original RFC

On 5/28/19 3:31 PM, Philip Reames via cfe-dev wrote: > I generally like the idea of having support in IR for vectorization of > custom functions.  I have several use cases which would benefit from this. > > I'd suggest a couple of reframings to the IR representation though. > > First, this should probably be specified as metadata/attribute on a > function declaration. 

> Hi, > > Ady: > > Since both included variants are currently different, and both > > variants have problems > > I am not aware of problems of the perl version. It is just lacking > the newer features which support EFI/GPT and Mac/APM. > The known bugs of isohybrid.c are with those newer features. > http://www.syslinux.org/archives/2012-May/017843.html >

On 05/31, Saito, Hideki wrote: > > >This works for variants that are created from definitions in the module but what about #omp declare simd declarations? > > I'm sorry that I haven't digested this thread in its entirety, but let me just deal with this one point for now. > Suppose #pragma omp declare simd is applied to foo(). I'd expect the corresponding Function

I think I did misunderstand what you want to do with attributes. This is my bad. Let me try to explain: It seems you want the "vector-variants" attributes (which I could not find with this name in trunk, correct?) to "remember" what vector versions can be created (wrt. validity), assuming a definition is available? Correct? What I was concerned with is the example I sketched

>VectorClone does more than just mapping a scalar version to a vector one. It builds also the vector version definition by auto-vectorizing the body of the scalar function. To be more precise: VecClone strictly deals with the callee side of the code. Caller side mapping happens in vectorizer (LoopVectorize for the most part, but I don't see why SLPVectorize can't, for example).

On 5/29/19 1:52 PM, Philip Reames wrote: > On 5/28/19 7:55 PM, Finkel, Hal J. wrote: >> On 5/28/19 3:31 PM, Philip Reames via cfe-dev wrote: >>> I generally like the idea of having support in IR for vectorization of >>> custom functions.  I have several use cases which would benefit from this. >>> >>> I'd suggest a couple of reframings to the IR

On 5/30/19 9:05 AM, Doerfert, Johannes wrote: > On 05/29, Finkel, Hal J. via cfe-dev wrote: >> On 5/29/19 1:52 PM, Philip Reames wrote: >>> On 5/28/19 7:55 PM, Finkel, Hal J. wrote: >>>> On 5/28/19 3:31 PM, Philip Reames via cfe-dev wrote: >>>>> I generally like the idea of having support in IR for vectorization of >>>>> custom

>Is this also the case if the user did require lock-step semantic for the code to be correct? Certainly not, but that part is actually beyond OpenMP specification. I suggest looking up ICC's "#pragma simd assert" description and see if the assert feature is something you may be interested in seeing as an extended part of LLVM implementation of OpenMP (declare) simd. Else,

I think we should split this discussion: TOPIC 1 & 2 & 4: How do implement all use cases and OpenMP 5.X features, including compatibility with other compilers and cross module support. TOPIC 3b & 5: Interoperability with clang declare (system vs. user declares) TOPIC 3a & 3c: floating point issues? I inlined comments for

Hi Francesco, did you think about adding the attribute instead of the pragma? It is a common way to express such constructs as function attributes in clang/GCC rather than as pragma. Best regards, Alexey Bataev > 31 мая 2019 г., в 12:18, Francesco Petrogalli via cfe-dev <cfe-dev at lists.llvm.org> написал(а): > > Hi All, > > Thank you for the feedback so far. > > I

Page 22 of OpenMP 5.0 specification (Lines 13/14): When any thread encounters a simd construct, the iterations of the loop associated with the construct may be executed concurrently using the SIMD lanes that are available to the thread This is the Execution Model. The word here is "may" i.e., not "must". Declare simd is not explicitly mentioned here, but requiring