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...