search for: hollerith

Displaying 12 results from an estimated 12 matches for "hollerith".

2009 Aug 23
0
[LLVMdev] x86_64 darwin multilib gfortran testresults
...t_p_1.f90 -O3 -fomit-frame-pointer -funroll-loops execution test FAIL: gfortran.dg/fmt_p_1.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions execution test FAIL: gfortran.dg/fmt_p_1.f90 -O3 -g execution test FAIL: gfortran.dg/fmt_p_1.f90 -Os execution test FAIL: gfortran.dg/hollerith.f90 -O0 (internal compiler error) FAIL: gfortran.dg/hollerith.f90 -O0 (test for excess errors) WARNING: gfortran.dg/hollerith.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/hollerith.f90 -O1 (internal compiler error) FAIL: gfortran.dg/hollerith.f90 -O1 (test for excess...
2008 Nov 02
1
[LLVMdev] llvm-2.4 prerelease gfortran results
...harlen_function_5.f90 -O (test for excess errors) FAIL: gfortran.dg/char_transpose_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/char_transpose_1.f90 -O0 (test for excess errors) WARNING: gfortran.dg/char_transpose_1.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/hollerith.f90 -O0 (internal compiler error) FAIL: gfortran.dg/hollerith.f90 -O0 (test for excess errors) WARNING: gfortran.dg/hollerith.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/hollerith.f90 -O1 (internal compiler error) FAIL: gfortran.dg/hollerith.f90 -O1 (test for excess...
2009 Jan 19
2
[LLVMdev] llvm-gfortran test results
...ilation failed to produce executable FAIL: gfortran.dg/equiv_constraint_4.f90 -O3 -g (internal compiler error) FAIL: gfortran.dg/equiv_constraint_4.f90 -O3 -g (test for excess errors) WARNING: gfortran.dg/equiv_constraint_4.f90 -O3 -g compilation failed to produce executable FAIL: gfortran.dg/hollerith.f90 -O0 (internal compiler error) FAIL: gfortran.dg/hollerith.f90 -O0 (test for excess errors) WARNING: gfortran.dg/hollerith.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/hollerith.f90 -O1 (internal compiler error) FAIL: gfortran.dg/hollerith.f90 -O1 (test for excess...
2008 Jun 10
1
[LLVMdev] llvm-gcc4.2-2.3 gfortran failures
...harlen_function_5.f90 -O (test for excess errors) FAIL: gfortran.dg/char_transpose_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/char_transpose_1.f90 -O0 (test for excess errors) WARNING: gfortran.dg/char_transpose_1.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/hollerith.f90 -O0 (internal compiler error) FAIL: gfortran.dg/hollerith.f90 -O0 (test for excess errors) WARNING: gfortran.dg/hollerith.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/hollerith.f90 -O1 (internal compiler error) FAIL: gfortran.dg/hollerith.f90 -O1 (test for excess...
2005 Sep 16
1
column-binary data
I have a number of datasets that are multipunch column-binary format. Does anyone have any advice on how to read this into R? Thanks. David
2006 Dec 04
0
Paypal and soap4r gems
WSDL conversion as proposed in the paypal plugin howto doesn''t work. Any idea what goes wrong? See the output below. rsp@hollerith:~/workspace/pptest/vendor/plugins/paypal$ wsdl2ruby.rb --wsdl http://www.sandbox.paypal.com/wsdl/PayPalSvc.wsdl --type client --force F, [2006-12-04T16:30:43.136405 #11579] FATAL -- app: Detected an exception. Stopping ... undefined method `new'' for nil:NilClass (NoMethodError) /usr/lib/ru...
2016 Jan 25
2
[v3,11/41] mips: reuse asm-generic/barrier.h
...go at this. I tried defining something axiomatically, but got stuck pretty quickly. In my scheme, I used "data-directed transitivity" instead of "local transitivity", since the latter seems to be a bit of a misnomer. > +For example, switching to C code in deference to Herman Hollerith: > + > + int u, v, x, y, z; > + > + void cpu0(void) > + { > + r0 = smp_load_acquire(&x); > + WRITE_ONCE(u, 1); > + smp_store_release(&y, 1); > + } > + > + void cpu1(void) > + { > + r1 = smp_load_acquire(&y); > + r4 = READ_ONCE(v); > + r...
2016 Jan 25
2
[v3,11/41] mips: reuse asm-generic/barrier.h
...go at this. I tried defining something axiomatically, but got stuck pretty quickly. In my scheme, I used "data-directed transitivity" instead of "local transitivity", since the latter seems to be a bit of a misnomer. > +For example, switching to C code in deference to Herman Hollerith: > + > + int u, v, x, y, z; > + > + void cpu0(void) > + { > + r0 = smp_load_acquire(&x); > + WRITE_ONCE(u, 1); > + smp_store_release(&y, 1); > + } > + > + void cpu1(void) > + { > + r1 = smp_load_acquire(&y); > + r4 = READ_ONCE(v); > + r...
2016 Jan 15
5
[v3,11/41] mips: reuse asm-generic/barrier.h
On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive, all CPUs will agree on the order. Whereas the RCpc release+acquire is weakly so, only the two
2016 Jan 15
5
[v3,11/41] mips: reuse asm-generic/barrier.h
On Thu, Jan 14, 2016 at 01:29:13PM -0800, Paul E. McKenney wrote: > So smp_mb() provides transitivity, as do pairs of smp_store_release() > and smp_read_acquire(), But they provide different grades of transitivity, which is where all the confusion lays. smp_mb() is strongly/globally transitive, all CPUs will agree on the order. Whereas the RCpc release+acquire is weakly so, only the two
2016 Jan 15
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...ll CPUs will +agree on the order of operations. In contrast, a chain of release-acquire +pairs provides only "local transitivity", so that only those CPUs on +the chain are guaranteed to agree on the combined order of the accesses. +For example, switching to C code in deference to Herman Hollerith: + + int u, v, x, y, z; + + void cpu0(void) + { + r0 = smp_load_acquire(&x); + WRITE_ONCE(u, 1); + smp_store_release(&y, 1); + } + + void cpu1(void) + { + r1 = smp_load_acquire(&y); + r4 = READ_ONCE(v); + r5 = READ_ONCE(u); + smp_store_release(&z, 1); + } + + void cpu2(void)...
2016 Jan 26
0
[v3,11/41] mips: reuse asm-generic/barrier.h
...t "local" meant local to the CPUs participating in the release-acquire chain. As opposed to smp_mb() chains where the ordering is "global" as in visible to all CPUs, whether on the chain or not. Does that help? > > +For example, switching to C code in deference to Herman Hollerith: > > + > > + int u, v, x, y, z; > > + > > + void cpu0(void) > > + { > > + r0 = smp_load_acquire(&x); > > + WRITE_ONCE(u, 1); > > + smp_store_release(&y, 1); > > + } > > + > > + void cpu1(void) > > + { > > + r1...