search for: 31.81

Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is http://llvm.org/bugs/show_bug.cgi?id=15980 which results in unresolved symbols for _iround and _iroundf in the aermod and rnflow testcases. Note that this

Duncan, Here are the complete benchmarks rerun against gcc 4.5.4 built with... Using built-in specs. COLLECT_GCC=gfortran-fsf-4.5 COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.4/lto-wrapper Target: x86_64-apple-darwin11.0.0 Configured with: ../gcc-4.5.4/configure --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/lib/gcc4.5/info

Duncan, With r182593, the dragonegg 3.3 branch now completely passes the Polyhedron 2005 benchmarks using the FSF gcc 4.8.1svn compiler. Thanks. Jack Tested on x86_apple-darwin12 Compile Flags: -ffast-math -funroll-loops -O3 de-gfortran47: /sw/lib/gcc4.7/bin/gfortran -fplugin=/sw/lib/gcc4.7/lib/dragonegg.so -specs=/sw/lib/gcc4.7/lib/integrated-as.specs de-gfortran48:

On Wed, May 29, 2013 at 03:25:30PM +0200, Duncan Sands wrote: > Hi Jack, I pulled the loop vectorizer and fast math changes into the 3.3 branch, > so hopefully they will be part of 3.3 rc3 (and 3.3 final!). It would be great > if you could redo the benchmarks rc3. > Duncan, As requested, appended are the updated Polyhedron 2005 benchmark results with both RC1 and RC3 llvm 3.3

On Thu, Jun 09, 2011 at 03:44:40PM +0200, Duncan Sands wrote: > Hi Jack, thanks for doing this. > >> Below are the tabulated compile times and executable sizes. >> >> A) gcc 4.5.4svn using -msse3 -ffast-math -O3 -fno-tree-vectorize >> B) gcc 4.5.4svn/dragonegg using -msse3 -ffast-math -O3 -fno-tree-vectorize -fplugin-arg-dragonegg-enable-gcc-optzns >> C)

Hi, I want to increase my harddisk space and receive the following error # lvextend -l +323 /dev/VolGroup00/LogVol00 Extending logical volume LogVol00 to 48.97 GB device-mapper: reload ioctl failed: Invalid argument Failed to suspend LogVol00 Can you help me please? # fdisk -l Disk /dev/hda: 54.7 GB, 54759997440 bytes 255 heads, 63 sectors/track, 6657 cylinders Units =

On Thu, May 23, 2013 at 03:40:00PM +0200, Duncan Sands wrote: > Hi Jack, > > On 23/05/13 15:37, Jack Howarth wrote: >> Below are the results for the Polyhedron 2005 benchmarks compiled with llvm/compiler-rt/dragonegg 3.3svn at r182439 against current >> FSF gcc 4.7.3svn and 4.8.1svn. The only major bug remaining in the dragonegg 3.3svn support for gcc 4.8.x is

On Thu, Jun 09, 2011 at 08:47:26PM -0400, Jack Howarth wrote: > Duncan, > Here are the complete benchmarks rerun against gcc 4.5.4 built with... > > Using built-in specs. > COLLECT_GCC=gfortran-fsf-4.5 > COLLECT_LTO_WRAPPER=/sw/lib/gcc4.5/libexec/gcc/x86_64-apple-darwin11.0.0/4.5.4/lto-wrapper > Target: x86_64-apple-darwin11.0.0 > Configured with:

Hi Jack, On 29/05/13 22:04, Jack Howarth wrote: > On Wed, May 29, 2013 at 03:25:30PM +0200, Duncan Sands wrote: >> Hi Jack, I pulled the loop vectorizer and fast math changes into the 3.3 branch, >> so hopefully they will be part of 3.3 rc3 (and 3.3 final!). It would be great >> if you could redo the benchmarks rc3. >> > > Duncan, > As requested, appended

v2: - Change the OCaml code in the daemon to use PCRE instead of Str. - Call pcre_compile2 so we can capture the error code on failure. - Extend the test suite. - Some other cleanups, but very minor. Rich.

rucker222 wrote: > The drop down layer selection menu at the top left of the screen directly above where the drawing 1 tab is opens upwards off of the screen once the drawing has a few layers on it. jjmckenzie wrote: > Log file please. I loaded a drawing with plenty of layers and then clicked on the layer drop down menu a couple of times before exiting ProgeCAD. Log file below. (sorry

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 Thanks: Tomáš Golembiovský --- v2v/virt-v2v.pod | 38 ++++++++++++++++++++++++++------------ 1 file changed, 26 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..0943bf305 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,32 @@ that

See this bug for background information: https://bugzilla.redhat.com/show_bug.cgi?id=1350465 --- v2v/virt-v2v.pod | 39 +++++++++++++++++++++++++++------------ 1 file changed, 27 insertions(+), 12 deletions(-) diff --git a/v2v/virt-v2v.pod b/v2v/virt-v2v.pod index e68d75cf8..93d1a9ecd 100644 --- a/v2v/virt-v2v.pod +++ b/v2v/virt-v2v.pod @@ -1909,18 +1909,33 @@ that guest through the RHV-M UI,

If the connection is not local, paths of disks will refer to the remote host, which were mistakenly handled as local paths (in the best case failing to open a non-existing disk, and in the worst case opening a different disk!). In case the disks are remote resources like ssh or ceph, nothing guarantees that the hostname can be reached from the local machine, or even that it is actually the same on

Hopefully this time ...