similar to: compilation errors

>From: Chris Lattner <sabre at nondot.org> >Date: Wed, 14 Jul 2004 14:49:01 -0500 (CDT) >The file you need to modify is here: >llvm/include/Support/DataTypes.h.in > >There is currently support for building in non-cygwin windows environments >protected by _MSC_VER. You just need to broaden the scope of the #ifndef >to include internix. > Sorry, Chris, but my

>From: Chris Lattner <sabre at nondot.org> >Date: Wed, 14 Jul 2004 14:49:01 -0500 (CDT) > >There is currently support for building in non-cygwin windows environments >protected by _MSC_VER. You just need to broaden the scope of the #ifndef >to include internix. > Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting LLVM 1.2), so I'm not

On Fri, 16 Jul 2004, Henrik Bach wrote: > >There is currently support for building in non-cygwin windows environments > >protected by _MSC_VER. You just need to broaden the scope of the #ifndef > >to include internix. > > > > Sorry Chris, but my DataTypes.h.in seems to be outdated (due to I'm porting > LLVM 1.2), so I'm not at the moment able to edit the

http://bugzilla.mindrot.org/show_bug.cgi?id=1347 Summary: LLONG_MAX v LONGLONG_MAX Product: Portable OpenSSH Version: 4.6p1 Platform: PPC OS/Version: AIX Status: NEW Severity: normal Priority: P2 Component: Miscellaneous AssignedTo: bitbucket at mindrot.org ReportedBy: David.Leonard at

http://bugzilla.mindrot.org/show_bug.cgi?id=842 Damien Miller <djm at mindrot.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #1287| |ok? Flag| | --- Comment #4 from Damien Miller <djm at mindrot.org>

hi all, I've been trying to use dovecot (from cvs 03.mar.2003, linux 2.2.20, gcc 2.96, openssl 0.9.7a) as an replacement for uw-imap, and it seems to be doing its job, except for one thing: I have my mua (sylpheed-claws from cvs) set up so that it will sort message into certain(imap) directories. so when I check the mail in the INBOX, new mails will be processed automatically and, for

http://bugzilla.mindrot.org/show_bug.cgi?id=1171 Summary: configure can't always figure out LLONG_MAX. Product: Portable OpenSSH Version: -current Platform: Other OS/Version: All Status: NEW Severity: normal Priority: P2 Component: Build system AssignedTo: bitbucket at mindrot.org

Details of installation attached. Effect: when I build and test (with full path names) ssh in the openssh... directory, everything works fine. When I "install" it as per attached file into a test-directory and run it from there, there are 2 phenomena: either it just hangs, eating 96% of CPU or it dies with a Segmentation fault (this is what happens most often) Help needed

Hi all. For a while, gcc has supported a stack protection mechanism (-fstack-protector and friends, available in gcc 4.1.2 and up). Can anyone think of a good reason not to enable it if the compiler supports it? A quick test here shows minimal difference in runtime over a full regress pass (~10sec over 8.5 minutes, and since the machine is not entirely idle that could be experimental error).

Hello, My imap daemon get SIGABRT with following message. "pool_data_stack_realloc(): stack frame changed" This is caused with cvs head sources.(and or not with my last 2 patches.) This causes while doing search command. This is IMAP command log: --------------------------------------------------------------------------- * PREAUTH [CAPABILITY IMAP4rev1 SORT THREAD=REFERENCES

Thanks, Andy. I'm not sure how to solve that or my case given the DAG's basic-block limit. Probably CodeGenPrepare or SelectionDAGBuilder...or we wait until after isel and try to split it up in a machine instruction pass. I filed my example here: https://bugs.llvm.org/show_bug.cgi?id=33013 Feel free to comment there and/or open a new bug for the FP_TO_UINT case. On Thu, May 11, 2017 at

I think it’s generally true that whenever branches can reliably be predicted branching is faster than a cmov that involves speculative execution, and I would guess that your assessment regarding looping on input values is probably correct. I believe the code that actually creates most of the transformation you’re interested in here is in SelectionDAGLegalize::ExpandNode() in LegalizeDAG.cpp. The

Just installed the version from CVS as of Oct. 27. I noticed three problems quite quickly: Still seeing "(imap) killed with signal 14" My INBOX closed with "access error" after reading it for a bit. There's nothing in the logs or anything, but this hasn't happened for quite a while now. There where quite a lot of incoming messages at the time and I was marking

This release features a dash sync to latest dash git (We continue in the tradition of providing the freshest dash), porter fixes for arm Debian and ppc64 Ubuntu. To the utils got added a minimal mv, so that /run initramfs content can be moved to the real rootfs. The shortlog is dominated by dash commits, plus usual minimal fixes. git repository: git://git.kernel.org/pub/scm/libs/klibc/klibc.git

From: Jan Kara <jack at suse.cz> If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires the journal pointer (to access journal->j_list_lock), which we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add a more detailed comment about why the function

On Wed, 29 Mar 2023, Chris Rapier wrote: > I was wondering if there was something specific to the internal chacha20 > cipher as opposed to OpenSSL implementation. > > I can't just change the block size because it breaks compatibility. I can do > something like as a hack (though it would probably be better to do it with the > compat function): > > if

Sounds like the select lowering issue is definitely separate from the FENV work. Is there a bug report with a C or IR example? You want to generate compare and branch instead of a cmov for something like this? int foo(float x) { if (x < 42.0f) return x; return 12; } define i32 @foo(float %x) { %cmp = fcmp olt float %x, 4.200000e+01 %conv = fptosi float %x to i32 %ret = select

I'm hardly an expert on this, but if I remember correctly, the rekey rate for good security is mostly dependent on the cipher block size. I left my reference books at home; so, I can't come up with a reference for you, but I would take Chris' "I'm deeply unsure of what impact that would have on the security of the cipher" comment seriously and switch to a cipher with a

From: Jan Kara <jack at suse.cz> If we race with commit code setting i_transaction to NULL, we could possibly dereference it. Proper locking requires the journal pointer (to access journal->j_list_lock), which we don't have. So we have to change the prototype of the function so that filesystem passes us the journal pointer. Also add a more detailed comment about why the function

The Wine development release 2.0-rc4 is now available. What's new in this release (see below for details): - Bug fixes only, we are in code freeze. The source is available from the following locations: http://dl.winehq.org/wine/source/2.0/wine-2.0-rc4.tar.bz2 http://mirrors.ibiblio.org/wine/source/2.0/wine-2.0-rc4.tar.bz2 Binary packages for various distributions will be available