Displaying 20 results from an estimated 90 matches similar to: "[LLVMdev] does new EH require newer linker?"
2012 May 27
0
[LLVMdev] Linking clang.exe takes more than two hours?
于 2012/5/27 11:04, Mikael Lyngvig 写道:
> Hi,
>
> I'm building using MINGW64 on a very slow system (Intel Atom 330 X2
> 1.6 GHz), but it seems rather odd that the system has been linking
> clang.exe for the past two hours. It appears that a couple of
> gigabytes of virtual memory are being used (causing constant swapping)
> - the system has only 2 GB of physical memory.
2012 May 27
2
[LLVMdev] Linking clang.exe takes more than two hours?
Hi,
I'm building using MINGW64 on a very slow system (Intel Atom 330 X2 1.6
GHz), but it seems rather odd that the system has been linking clang.exe
for the past two hours. It appears that a couple of gigabytes of virtual
memory are being used (causing constant swapping) - the system has only 2
GB of physical memory.
Is this a bug in MINGW64 (binutils 2.22) or is it just too little RAM in
2012 May 08
1
Patch for compiling xapian with gcc4.7
Hi,
I updated my system and shifted from gcc4.6 --> gcc4.7 .While building
xapian code with gcc4.7 there is error returned due to some changes in
GCC.Pastbin of error is http://pastebin.com/7ee5WGiu .I searched and found
it to some other packages also seems to face such issue like
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=667403 .
Attached herewith is patch.
--
with regards
Gaurav A.
2009 Jan 25
2
[LLVMdev] -O4 -fvisibility=hidden
After trying the recommended use of -O4 -fvisibility=hidden to
compile xplor-nih with full LTO optimizations, I discovered three
symbols become undefined...
llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \
\
-L. -lxplorCmd -lxplor -L/Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ -lfft -lintVar -lvmd -lpy -lswigpy-xplor -ltclXplor -lswigtcl8-xplor -lnmrPot -lcommon -lmarvin \
2009 Jan 24
1
[LLVMdev] -O4 limitations in llvm/llvm-gcc-4.2 2.5?
What exactly are the current limitations for using -O4 to create shared
libraries with llvm/llvm-gcc-4.2 2.5? I tried a build of xplor-nih at -O4
with llvm-gcc, llvm-g++ and llvm-gfortran. The build fails to link shared
libraries with errors such as...
Building xplor-nih for platform: Darwin_9_x86
[ -d /Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ ] || mkdir
2009 Jan 25
0
[LLVMdev] -O4 -fvisibility=hidden
Le 25 janv. 09 à 06:01, Jack Howarth a écrit :
> After trying the recommended use of -O4 -fvisibility=hidden to
> compile xplor-nih with full LTO optimizations, I discovered three
> symbols become undefined...
>
> llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \
> \
> -L. -lxplorCmd -lxplor -L/Users/howarth/xplor-nih-2.21/
> bin.Darwin_9_x86/ -lfft -lintVar
2014 Dec 02
0
User's DPAPI/backupkey protected data lost when changing domain password
Is there a corresponding bug number for the Samba bugzilla so that I can
track when this is fixed for vanilla samba?
On 26 November 2014 at 20:01, Andrew Bartlett <abartlet at samba.org> wrote:
> On Mon, 2014-11-24 at 11:35 +0100, Roberto Su?rez Soto wrote:
> >
> > Error verifying signature: parse
> > error
> > --------------ms020506010503000409040509
> >
2011 Sep 06
2
[LLVMdev] major dragonegg improvement
I'm not certain yet which commit in the last couple of days caused this,
but the current llvm/dragonegg svn shows a major improvement in the runtime
of the xplor-nih testsuite when xplor-nih is built with FSF gcc 4.6.1 and the
dragonegg plugin at -O3 -ffast-math -funroll-loops. Previously the xplor-nih
testsuite always executed in ~40 sec but now it is coming it at 34.5 sec which
is about the
2014 Dec 03
0
User's DPAPI/backupkey protected data lost when changing domain password
For anybody interested in tracking when this is resolved for mainline
samba4 there is now a bugzilla record here:
https://bugzilla.samba.org/show_bug.cgi?id=10980
On 2 December 2014 at 11:52, Kirin van der Veer <
kirin.vanderveer at planetinnovation.com.au> wrote:
> Is there a corresponding bug number for the Samba bugzilla so that I can
> track when this is fixed for vanilla samba?
2009 Jan 23
0
[LLVMdev] llvm/llvm-gcc-4.2 and xplor-nih
I am happy to report that current llvm/llvm-gcc-4.2 svn
builds all of xplor-nih (a complex mix of c, c++ and fortran)
with -O3 -fPIC -msse4 -ffast-math. A single fortran file
exposes PR3376 which is triggered by -O3 -ffinite-math-only.
The resulting build of xplor-nih completely passes its testsuite
and compares very well to the same build against gcc trunk for
gcc 4.4 in terms of execution time.
2011 Apr 13
1
[LLVMdev] dragonegg vs xplor-nih
I was quite surprised to find that dragonegg svn can now compile all of
xplor-nih (which is a complex mix of c, c++ and fortran that is a regression
magnet for FSF gcc). The xplor-nih package was compiled at -O3 -ffast-math -funroll-loops
for all three compilers. The xplor testsuite passed without regressions and benchmarked
as follows...
dragonegg svn with llvm 2.9 and FSF gcc 4.5.3svn
Total
2011 Sep 06
0
[LLVMdev] major dragonegg improvement
Seems very likely to be related to Andy's SCEV-unroll-loops changes.
--Owen
On Sep 6, 2011, at 11:56 AM, Jack Howarth wrote:
> I'm not certain yet which commit in the last couple of days caused this,
> but the current llvm/dragonegg svn shows a major improvement in the runtime
> of the xplor-nih testsuite when xplor-nih is built with FSF gcc 4.6.1 and the
> dragonegg plugin
2009 Jan 25
2
[LLVMdev] -O4 -fvisibility=hidden
On Sun, Jan 25, 2009 at 11:38:48AM +0100, Jean-Daniel Dupas wrote:
>
> Le 25 janv. 09 à 06:01, Jack Howarth a écrit :
>
> > After trying the recommended use of -O4 -fvisibility=hidden to
> > compile xplor-nih with full LTO optimizations, I discovered three
> > symbols become undefined...
> >
> > llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \
>
2011 Sep 06
1
[LLVMdev] major dragonegg improvement
Try -mllvm -disable-unroll-scev if you're curious.
There can be some luck involved. If you have the bitcode for the important function, I may be able to convert it into a test case to avoid regressing. I usually grab the unoptimized bitcode as follows: -emit-llvm -mllvm -disable-llvm-optzns -o module.bc
-Andy
On Sep 6, 2011, at 12:03 PM, Owen Anderson wrote:
> Seems very likely to be
2009 Jan 24
0
[LLVMdev] -O4 limitations in llvm/llvm-gcc-4.2 2.5?
Chris,
Thanks for the hint. Moving over the libLTO.dylib
from llvm 2.5 solved all of the linkage errors. I was
able to completely build xplor-nih at -O4 now. The
core xplor and xplor-tcl testsuite show no regressions.
I do get 7 testcases in the xplor-python testsuite
failing with bus errors now. The xplor-tcl and xplor-python
tests are all run by tcl and python respectively loading
their
2019 Apr 08
2
LLVM 8 + Mavericks?
W dniu 2019-04-04 o 09:18, Tim Northover pisze:
> On Wed, 3 Apr 2019 at 19:05, Audiovisart via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Does LLVM 8 work in macOS 10.9.5?
> It should do. The released binaries appear to have been compiled so
> they can run on that version, and Apple Clang 6.0 (from the newest
> Xcode that runs on 10.9) meets the build
2014 Nov 10
0
User's DPAPI/backupkey protected data lost when changing domain password
After a user changes their password (CTRL-ALT-DEL) in our Samba 4 domain
(4.1.12) they lose access to any stored passwords on their Windows PC.
I've set the log level in smb.conf to 4 and enabled the GPO to record DPAPI
log entries in Windows to get the below log data.
My reading of the two is that the Windows PC believes it is failing to reset
the access to its DPAPI store (where the saved
2016 Sep 12
2
lld: add build-time control for including ELF / COFF / Mach-O linkers?
On 12 September 2016 at 16:23, Rui Ueyama <ruiu at google.com> wrote:
> What's the motivation to not build COFF and Mach-O parts? If you don't need
> it, you could just leave it. Are you trying to reduce the executable size?
It was just easier to remove coff::link() and mach_o::link() from
lld.cpp than to add them to our own build infrastructure
2016 Dec 14
0
LLD status update and performance chart
On Tue, Dec 13, 2016 at 8:10 PM, Andrew Kelley <superjoe30 at gmail.com> wrote:
>
> On Tue, Dec 13, 2016 at 10:59 PM, Sean Silva via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>>
>> Yes. Rui has bent over backwards every time a real user has come to us
>> and said "we need X". The historical precedent here is that LLD is open to
>> many