similar to: [LLVMdev] struct passing on X86-64

David Meyer <pdox at google.com> writes: > The frontends (llvm-gcc, clang) appear to do the argument munging > themselves in order to compensate. Yep. There are lots of corner cases that the frontend MUST handle because LLVM does not have the necessary infrastructure. > Any plans or suggestions for implementing this properly in the backend? I don't think anyone has signed

Hi Dave, >> The frontends (llvm-gcc, clang) appear to do the argument munging >> themselves in order to compensate. > > Yep. There are lots of corner cases that the frontend MUST handle > because LLVM does not have the necessary infrastructure. I think it's more like: because LLVM doesn't have the necessary information. Due to LLVM using structural equivalence, all

Duncan Sands <baldrick at free.fr> writes: >> Yep. There are lots of corner cases that the frontend MUST handle >> because LLVM does not have the necessary infrastructure. > > I think it's more like: because LLVM doesn't have the necessary information. True. > Due to LLVM using structural equivalence, all kinds of types that are > different in the original

David A. Greene wrote: > Duncan Sands<baldrick at free.fr> writes: > >>> Yep. There are lots of corner cases that the frontend MUST handle >>> because LLVM does not have the necessary infrastructure. >> >> I think it's more like: because LLVM doesn't have the necessary information. > > True. > >> Due to LLVM using structural

Nick Lewycky <nicholas at mxc.ca> writes: > Why should the backends know about the frontend language? It seems > sensible to me that if I create a new language and a new ABI for my > language then I can expect to need to teach the backend about my new > ABI. And so the backend has to be taught about the language. To me, it is about conveying the necessary information in a more

On Fri, Jun 10, 2011 at 10:29 AM, David A. Greene <greened at obbligato.org> wrote: > Duncan Sands <baldrick at free.fr> writes: > >>> Yep.  There are lots of corner cases that the frontend MUST handle >>> because LLVM does not have the necessary infrastructure. >> >> I think it's more like: because LLVM doesn't have the necessary

David A. Greene wrote: > Nick Lewycky<nicholas at mxc.ca> writes: > >> Why should the backends know about the frontend language? It seems >> sensible to me that if I create a new language and a new ABI for my >> language then I can expect to need to teach the backend about my new >> ABI. > > And so the backend has to be taught about the language. Only if

Trying to get my wife's emails out of a proprietary format and into mbox for use on our local box. Doing some major file munging. In a test email the following doesn't work. (forgetting dates, email addresses, etc.) >From heraddress at herdomain.com Wed Oct 10 11:50:44 2005 -0700 Date: Wed, 10 Oct 2005 11:50:42 -0700 (PDT) This does work >From heraddress at herdomain.com Wed Oct

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 > > I've been working on this sort of approach using abcde as a front-end, > and have run into several issues. What I finally decided on doing is > ripping the CD to a single flac file with embedded cue sheet using a > variety of tools (more details later). The single flac file is then > enough to pretty much reconstruct the

Hi All: I''m writing my 1st Rails app and I can''t seem to find the answer on the web or in the book. I''m making a table, and I want to be able to expand a filename. The code is basically as as follows below. In the last <td> entry, I want to call an action and pass in the test_results_path, which I will go and read a file and munge the data for a separate

I would guess that reply-to is getting added because of header munging. Turn off munging and this all goes away.

On a file resource, if the content parameter is set and checksum is set to none, I am getting "Parameter content failed: Munging failed..." This appears to be a bug, but maybe I missed something in the documentation and it isn''t supposed to work. cat test.pp file { "/tmp/foo": checksum => none, content => "this is foo\n", } puppet

It appears that, without munging the startup scripts, it isn't possible to create a slave-only configuration. The scenario is this: My NUT server doesn't need to turn off, it isn't allowed to turn the UPS off, and it isn't authoritative to turn any other server off. Its only job is to make UPS status available to NUT clients. My NUT clients are independent of the NUT server.

On Jun 16, 2009, at 5:49 PM, David Greene wrote: > On Tuesday 16 June 2009 19:35, David Greene wrote: > >> So which is more intuitive and less error-prone? >> >> defm BLENDPS : >> sse41_avx_fp_binary_vector_osta_vintrinsic_rmi_rrmi<0x0C, >> i32i8imm, "blend", "blend", "f32", 4>; >> >> or

Greetings all, Sorry, resending this with the attachment inline. First of all, a disclaimer: Please forgive my horrible assembly code. This is just a quick munging of code to achieve x86 versus x86_64 detection within pxelinux. So please look at it as a proof of concept and not a real piece of code. :) For example it only works on pxelinux and has no thought for extending it beyond simple x86

Dear asterisk users, We want setup TE121 digium board: Model: Digium TE121: VoiceBus technology allows the TE121 to use an industry standard bus-mastering PCI Express interface. http://www.digium.com/en/products/digital/te121.php My platform Server: HP Proliant 150 G5 OS: UBUNTU x86_64 GNU/Linux Asterisk: 1.4.21.2 zaptel: SVN-branch-1.4-r4662M When we enable zaptel driver for TE121, the

ARM subtarget features are determined by parsing the target tuple string TT. (ParseARMTriple(StringRef TT) in ARMMCTargetDesc.cpp) In llc, the -march setting overrides the architecture specified in -mtriple. So when you invoke: $ llc -march arm -mtriple armv7-none-linux ... ParseARMTriple() will see TT == "arm-none-linux" instead of "armv7-none-linux". As a result, the

Sergey, Here's a patch on llvm-gcc which adds a flag "-fuse-llvm-va-arg". (Note that this patch won't ever be part of llvm-gcc upstream. It will most likely be deprecated by later changes.) - pdox -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20110220/f814866f/attachment.html>

On 09/02/2019 10:44, Aki Tuomi via dovecot wrote: > For some reason mailman failed to "munge from" for senders with dmarc policy ;( > > It's now configured to always munge to avoid this again. I'd say, let Mailman throw all people off the list that have enabled DMARC checking without using exceptions for the lists they are on. It's a known fact that DMARC does not

On Wed, 2018-03-28 at 19:11 +0100, Rowland Penny wrote: > On Thu, 29 Mar 2018 06:51:50 +1300 > Andrew Bartlett via samba <samba at lists.samba.org> wrote: > > are you sure about that Andrew ? All my samba list messages are 'munged' as I described. > If I log into Mailman and go to 'Reply-To: header munging' it tells me > that we aren't removing any