search for: 176,14

...uot; branch: Via a macro, it continues to use long double also for the PPC 64 in this case: $ svn diff -c77587 Index: src/main/arithmetic.c =================================================================== --- src/main/arithmetic.c (Revision 77586) +++ src/main/arithmetic.c (Revision 77587) @@ -176,8 +176,14 @@ #endif } + #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) +# ifdef __PPC64__ + // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with LDOUBLE +# define q_1_eps (1 / LDBL_EPSILON) +# else static LDOUBLE q_1_eps = 1 / LDBL_EPSILON; +# e...

...ostor"] } + +let get_block_driver_priority t = t.block_driver_priority +let set_block_driver_priority t v = t.block_driver_priority <- v let scsi_class_guid = "{4D36E97B-E325-11CE-BFC1-08002BE10318}" let viostor_legacy_pciid = "VEN_1AF4&DEV_1001&REV_00" @@ -176,14 +183,13 @@ let rec inject_virtio_win_drivers ({ g } as t) reg = else ( (* Can we install the block driver? *) let block : block_type = - let filenames = ["virtio_blk"; "vrtioblk"; "viostor"] in let viostor_driver = try ( Some (...

...,8 @@ static int physdev_unmap_pirq(struct phy struct domain *d; int ret; - if ( !IS_PRIV(current->domain) ) - return -EPERM; + if ( !unmap ) + return -EINVAL; if ( unmap->domid == DOMID_SELF ) d = rcu_lock_domain(current->domain); @@ -171,6 +176,14 @@ static int physdev_unmap_pirq(struct phy if ( d == NULL ) return -ESRCH; + else + { + if ( !IS_PRIV_FOR(current->domain, d) ) + { + rcu_unlock_domain(d); + return -EPERM; + } + } spin_lock(&pcidevs_lock); s...

...t get_block_driver_priority t = t.block_driver_priority +let set_block_driver_priority t v = t.block_driver_priority <- v let scsi_class_guid = "{4D36E97B-E325-11CE-BFC1-08002BE10318}" let viostor_legacy_pciid = "VEN_1AF4&DEV_1001&SUBSYS_00021AF4&REV_00" @@ -176,14 +183,13 @@ let rec inject_virtio_win_drivers ({ g } as t) reg = else ( (* Can we install the block driver? *) let block : block_type = - let filenames = ["virtio_blk"; "vrtioblk"; "viostor"] in let viostor_driver = try ( Some (...

...>> the PPC 64 in this case: > >> $ svn diff -c77587 >> Index: src/main/arithmetic.c >> =================================================================== >> --- src/main/arithmetic.c (Revision 77586) >> +++ src/main/arithmetic.c (Revision 77587) >> @@ -176,8 +176,14 @@ >> #endif >> } > >> + >> #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) >> +# ifdef __PPC64__ >> + // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with LDOUBLE >> +# define q_1_eps (1 / LDBL_E...

Being rather aggrevated when testing at the enforced 1 second delay between each connection attempt and the useless 1 second delay done after all connection attempts have failed I wrote a patch to make the number of seconds delayed between each connection attempt configurable. Stephen -------------- next part -------------- diff -u --recursive openssh-2.3.0p1/ChangeLog

...for > the PPC 64 in this case: > $ svn diff -c77587 > Index: src/main/arithmetic.c > =================================================================== > --- src/main/arithmetic.c (Revision 77586) > +++ src/main/arithmetic.c (Revision 77587) > @@ -176,8 +176,14 @@ > #endif > } > + > #if HAVE_LONG_DOUBLE && (SIZEOF_LONG_DOUBLE > SIZEOF_DOUBLE) > +# ifdef __PPC64__ > + // PowerPC 64 (when gcc has -mlong-double-128) fails constant folding with LDOUBLE > +# define q_1_eps (1 / LDBL_EPSIL...

...ERVISOR_set_timer_op( uint64_t timeout) diff -r fdf241ea6ff4 extras/mini-os/include/x86/x86_64/hypercall-x86_64.h --- a/extras/mini-os/include/x86/x86_64/hypercall-x86_64.h Wed Nov 28 21:29:18 2012 +0100 +++ b/extras/mini-os/include/x86/x86_64/hypercall-x86_64.h Wed Nov 28 22:53:42 2012 +0100 @@ -176,6 +176,14 @@ return _hypercall2(int, sched_op, cmd, arg); } +static inline int +HYPERVISOR_shutdown( + unsigned int reason) +{ + struct sched_shutdown shutdown = { .reason = reason }; + return _hypercall2(int, sched_op, SCHEDOP_shutdown, &shutdown); +} + static inline long HYPERVISOR_set...

Discussion on v1 https://listman.redhat.com/archives/libguestfs/2023-February/030849.html https://listman.redhat.com/archives/libguestfs/2023-March/030917.html v1 -> v2: * Drop the logic where default is switched to "vioscsi". Keep virtio-blk as default. * Adapt the patch suggested by Richard: https://listman.redhat.com/archives/libguestfs/2023-March/030974.html This

Discussion on v2: https://listman.redhat.com/archives/libguestfs/2023-March/030989.html v2 -> v3: * Patch 1/4 ("inject_virtio_win: match only vendor/device/revision"): do not omit PCI Revision ID. Adjust commit message accordingly; * Patch 2/4 ("inject_virtio_win: add Virtio_SCSI to block_type"): add non-empty commit message body. * Patch 4/4

...(match_hostname(host, cp, (u_int) (cp2 - cp)) != 1) continue; +#endif /* Got a match. Skip host name. */ cp = cp2; diff -u -p openssh-3.4p1/match.c openssh-3.4p1-hash/match.c --- openssh-3.4p1/match.c Mon Mar 4 20:42:43 2002 +++ openssh-3.4p1-hash/match.c Mon Mar 3 17:32:17 2003 @@ -176,6 +176,14 @@ match_hostname(const char *host, const c return match_pattern_list(host, pattern, len, 1); } +#ifdef HASH_KNOWN_HOSTS +int +match_hashed_hostname(const char *host, const char *pattern, u_int len) +{ + return match_pattern_list(host, pattern, len, 0); +} +#endif + /* * r...

>>>>> Tom Callaway >>>>> on Thu, 12 Dec 2019 14:21:10 -0500 writes: > Hi R folks, > Went to build R 3.6.2 for Fedora/EPEL and got failures across the board. > Disabling the test suite for all non-intel architectures resolves most of > the failures, but powerpc64 dies in the compiler, specifically here: > gcc -m64

As described here previously: https://www.redhat.com/archives/libguestfs/2010-March/msg00129.html Here is the three part patch to reimplement virt-win-reg to support exporting and merging Windows Registry entries in the 'regedit' format. Tested by me on a local Windows VM. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones virt-top is 'top'

...flag that could drive the vectorizer. I am not sure if we want to do this at this stage or even at all. For now I would keep it like this. I don't have a better solution, but wanted to write down my thoughts. > } > > PassManagerBuilder::~PassManagerBuilder() { > @@ -170,6 +176,14 @@ void PassManagerBuilder::populateModulePassManager(PassManagerBase&MPM) { > > addExtensionsToPM(EP_ScalarOptimizerLate, MPM); > > + if (Vectorize) { > + MPM.add(createBBVectorizePass()); > + if (OptLevel> 1) { > + MPM.add(createInstructionCombining...

...nt(buf, vc, param->encoding) < 0) { + if (add_comment(buf, vc) < 0) { fprintf(stderr, "bad comment: \"%s\"\n", buf); @@ -177,14 +176,14 @@ ***********/ -void print_comments(FILE *out, vorbis_comment *vc, char *encoding) +void print_comments(FILE *out, vorbis_comment *vc) { int i; char *decoded_value; for (i = 0; i < vc->comments; i++) { - if (utf8_decode(vc->user_comments[i], &amp...

OK, here is the large patchset that implements the virtio spec update that I sent earlier (the spec itself needs a minor update, will send that out too next week, but I think we are on the same page here already). It supercedes the PUBLISH_USED_IDX patches I sent out earlier. What will follow will be a patchset that actually includes 4 sets of patches. I note below their status. Please consider

OK, here is the large patchset that implements the virtio spec update that I sent earlier (the spec itself needs a minor update, will send that out too next week, but I think we are on the same page here already). It supercedes the PUBLISH_USED_IDX patches I sent out earlier. What will follow will be a patchset that actually includes 4 sets of patches. I note below their status. Please consider

...re if we > want to do this at this stage or even at all. > > For now I would keep it like this. I don't have a better solution, but > wanted to write down my thoughts. > > > > } > > > > PassManagerBuilder::~PassManagerBuilder() { > > @@ -170,6 +176,14 @@ void PassManagerBuilder::populateModulePassManager(PassManagerBase&MPM) { > > > > addExtensionsToPM(EP_ScalarOptimizerLate, MPM); > > > > + if (Vectorize) { > > + MPM.add(createBBVectorizePass()); > > + if (OptLevel> 1) { > > +...

Tobias, et al., Attached is the my autovectorization pass. I've fixed a bug that appears when using -bb-vectorize-aligned-only, fixed some 80-col violations, etc., and at least on x86_64, all test cases pass except for a few; and all of these failures look like instruction-selection bugs. For example: MultiSource/Applications/ClamAV - fails to compile shared_sha256.c with an error: error in

Tobias, I've attached the latest version of my autovectorization patch. I was able to add support for using the ScalarEvolution analysis for load/store pairing (thanks for your help!). This led to a modest performance increase and a modest compile-time increase. This version also has a cutoff as you suggested (although the default value is set high (4000 instructions between pairs) because