search for: irreconcilable

Displaying 13 results from an estimated 13 matches for "irreconcilable".

2016 Dec 07
4
Debug Locations for Optimized Code
Hi Kostya, So... a bunch of folks (not all CC'd - feel free to add anyone who seems relevant, I haven't gone back over the commits to check who's made what changes) have been making improvements to optimized code debug information - much of it around making sure sample profiles are accurate. This mostly entails removing debug locations from instructions that are moved between basic
2017 Jun 06
4
LLD support for mach-o aliases (weak or otherwise)
Hi Folks, I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say “Don’t do that”, but f...
2012 Nov 25
1
libguestfs 1.18.11 build error
I am trying to build libguestfs version libguestfs-1.18.11 in my archlinux box i am getting this error: febootstrap: error: /lib appears as both directory and ordinary file (glibc, ntfs-3g) make[2]: *** [stamp-supermin] Error 1 make[2]: Leaving directory `/mnt/downloads/dnl/PKGBUILDs/kvm/libguestfs/src/libguestfs-1.18.11/appliance' make[1]: *** [all-recursive] Error 1 make[1]: Leaving
2009 Aug 26
3
[LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...]
...the leaf nodes in that pass but I think using a runOnSCC we can extend this approach to overlay sections in such a way that a function and any of its predecessor have separate memory areas. Does that approach sound ok? > User assembly throws a big wrench into the works, but it's not > irreconcilable. I suggest requiring the user to flag assembly > functions as being either for mainline or for ISR code. Doing so via a > naming convention would likely tie in the easiest with the function > cloning done above. With the convention being sufficiently magic > (read: not legal C ident...
2008 Feb 27
3
forking Markdown.pl?
As many of you know, when a piece of open-source software languishes with bugs for 3 years it's often forked Markdown.pl is licensed under the BSD license. (do `>tail -35 /path/to/Markdown.pl`) Has anyone thought of forking and maintaining Markdown.pl (hopefully with Gruber's blessing) to fix some of the known bugs? I'm not volunteering (I'd be horrible)... just seeing if
2017 Jun 14
1
LLD support for mach-o aliases (weak or otherwise)
> On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Folks, > > I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say “Don’t do that”, but f...
2009 Aug 25
0
[LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...]
...anything from one tree with anything from the other tree. Varargs and should come along for the ride without any special handling since the functions are distinct well before those are lowered to reference static buffers. User assembly throws a big wrench into the works, but it's not irreconcilable. I suggest requiring the user to flag assembly functions as being either for mainline or for ISR code. Doing so via a naming convention would likely tie in the easiest with the function cloning done above. With the convention being sufficiently magic (read: not legal C identifiers so as to...
2008 Nov 10
6
changing the size of voice packets
Dear, is any way to change , the size of voice packets? I want to increase the quality by decreasing the size of each packets, because of bandwidth failure. ? thanks in advance Mani -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081110/c1b2ed9d/attachment.htm
2009 Aug 24
3
[LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...]
Up front I apologize for the lengthy email. Since our patch was not accepted, Chris asked us to follow up with this issue on llvm-dev. For the sake of completeness, let me give a bit of background and the problems that we are facing. I tried to capture as much as possible here so Please do give us feedback. Don't take your stack for granted.... PIC16 has very poor pointer handling, hence
2017 Jun 14
4
LLD support for mach-o aliases (weak or otherwise)
...gt; On Jun 6, 2017, at 4:08 PM, Michael Clark via llvm-dev <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: >>> >>> Hi Folks, >>> >>> I’m working on a port of musl libc to macos (arch triple is “x86_64-xnu-musl”) to solve some irreconcilable issues I’m having with libSystem.dylib. I don’t want to use glibc for various reasons, mainly because I want to static link. I have static PIE + ASLR working which is not actually supported by the Apple toolchain (*1), but I managed to get it to work. I’m sure Apple might say “Don’t do that”, but f...
2009 Aug 27
0
[LLVMdev] ISRs for PIC16 [was [llvm]r79631 ...]
...t pass but I think > using a runOnSCC we can extend this approach to overlay sections in such > a way that a function and any of its predecessor have separate memory > areas. Does that approach sound ok? > > User assembly throws a big wrench into the works, but it's not > > irreconcilable. I suggest requiring the user to flag assembly > > functions as being either for mainline or for ISR code. Doing so via a > > naming convention would likely tie in the easiest with the function > > cloning done above. With the convention being sufficiently magic > > (read: n...
2016 May 05
4
Resuming the discussion of establishing an LLVM code of conduct
On 5 May 2016, at 12:14, Charles Davis via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > The last sentence of the third paragraph bothers me: > >> In addition, violations of this code outside these spaces may affect >> a person's ability to participate within them. > ​This essentially gives the committee carte blanche to police our thoughts no matter where we
2017 Apr 17
10
RFC #3: Improving license & patent issues in the LLVM community
Hello everyone, This email is a continuation of a discussion started in October 2015, and continued in September 2016: http://lists.llvm.org/pipermail/llvm-dev/2015-October/091536.html http://lists.llvm.org/pipermail/llvm-dev/2016-September/104778.html As with those emails, this is a complicated topic and deals with sensitive legal issues. I am not a lawyer, and this email is not intended to be