similar to: [PATCH] for console width detection

Janne Hyv?rinen wrote: > Sorry for spamming but I noticed one more display glitch while doing > further testing. It could leave old status messages at the end of the > line while printing status messages if initial status fit on one line > and new status text required new line. Patches applied. Thanks! Erik --

Felix Homann wrote: > Here are the warnings I get with 03a9e6064d406e3656afacdbe50e8e47ebfa0de3: It seems Android sys/param.h doesn't define MIN/MAX. Could you try to revert this commit on current master (or simply change line 35 of src/libFLAC/include/private/macros.h back to #if defined(__GNUC__) ) and recompile? Or possibly bisect 03a9e60..master to find out when the

On 22.5.2013 17:03, Felix Homann wrote: > Sorry that it took so long to reply. As mentioned in an earlier mail > my first bisect session wasn't accurate. I've done a new one: > > Here's my patch suggestion but I'm no Android guy. -------------- next part -------------- diff --git a/src/flac/utils.c b/src/flac/utils.c index e908706..6f6382e 100644 ---

Attached patch works around for DJGPP missing wcswidth() in flac/utils.c:strlen_console() -- O.S. -------------- next part -------------- A non-text attachment was scrubbed... Name: 0001-flac-utils.c-strlen_console-workaround-for-DJGPP-mis.patch Type: application/octet-stream Size: 683 bytes Desc: not available URL:

Hi, I couldn't figure out how to file a bug in the bugtracker at sourceforge. So I send a report this way. Building FLAC from git for Android fails with the following message: utils.c: In function 'get_console_width': utils.c:181:17: error: storage size of 'w' isn't known utils.c:181:17: warning: unused variable 'w' [-Wunused-variable] make[3]: *** [utils.o]

Hi all, I have tagged 1.3.0pre4 in git and provided a tarball here: http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz I have built and tested the git tree on: linux-x86_64 openbsd5-i386 freebsd5-i386 as well as successfully cross compiling from Linux to 32 and 64 bit MinGW. As far as I am concerned, the only thing left to do for this release is to update the

On 04/28/13 02:38 am, Erik de Castro Lopo wrote: > Hi all, > > I have tagged 1.3.0pre4 in git and provided a tarball here: > > http://downloads.xiph.org/releases/flac/beta/flac-1.3.0pre4.tar.xz On OS/2 compile dies here, CC win_utf8_io/win_utf8_io.lo win_utf8_io/win_utf8_io.c:13:75: error: windows.h: No such file or directory ... with lots of more errors. The problem is

An HTML attachment was scrubbed... URL: <http://www.zytor.com/pipermail/klibc/attachments/20140708/d8624773/attachment-0001.html> -------------- next part -------------- A non-text attachment was scrubbed... Name: report_id.zip Type: application/zip Size: 20325 bytes Desc: not available URL: <http://www.zytor.com/pipermail/klibc/attachments/20140708/d8624773/attachment-0001.zip>

Is there any specific reason why the clang_rt.builtins-${arch} library is disabled for windows builds? if (NOT WIN32) foreach(arch x86_64 i386 arm) if(CAN_TARGET_${arch}) set_source_files_properties(${${arch}_SOURCES} PROPERTIES LANGUAGE C) add_compiler_rt_runtime(clang_rt.builtins-${arch} ${arch} STATIC SOURCES ${${arch}_SOURCES} CFLAGS

2014-07-08 12:11 GMT-07:00 Matt Arsenault <Matthew.Arsenault at amd.com>: > On 07/07/2014 09:47 PM, deadal nix wrote: > > OK from what I understand, the DAG.getSExtOrTrunc(SetCC, DL, SelectVT) > is unecessary and the SelectVT is nto the right type (as it is called with > incorrect parameter). > > Here is a patch so it won't generate a loop. I ran make check and

I believe the C source files in builtins directory are generic enough. Why not build a clang_rt.builtins-aarch64 library? --Sumanth G -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140708/969ee15b/attachment.html>

Hi Fellow LLVM Experts, Currently, Selection DAG node for load seems to expect a 32-bit base and an offset. Is it possible to extend load node definition to 2 32-bit bases and an offset? Two 32-bit bases are supposed to represent one 64-bit address. Any suggestions, comments are much appreciated. Regards, Iftekhar -------------- next part -------------- An HTML attachment was scrubbed...

I noticed the compiler-rt/lib/builtins/CmakeLists.txt is not including the .S files in building clang_rt.builtins-arm.a We need to tell the CMake build system that the .S files are also the source files. Is there any intention behind leaving the .S files not to compile? If not, let me know and I will push a patch. --Sumanth G -------------- next part -------------- An HTML attachment

On 07/08/2014 03:20 PM, Matt Arsenault wrote: > Alternatively maybe this should only be done if the setcc type is the > same as the sext result? I think we should actually do this. If you need to convert the setcc result after, you aren't really gaining anything by doing this transformation -------------- next part -------------- An HTML attachment was scrubbed... URL:

Yes, the target does not have 64-bit GPRs. But it still needs to support 64-bit address space. Cheers, Iftekhar On Tue, Jul 8, 2014 at 1:19 PM, Hal Finkel <hfinkel at anl.gov> wrote: > ----- Original Message ----- > > From: "Iftekhar Chowdhury" <iftekhar.hc at gmail.com> > > To: llvmdev at cs.uiuc.edu > > Sent: Tuesday, July 8, 2014 1:06:44 PM >

Sure, we can build libclang_rt.builtins-aarch64.a, if there are users for it and, ideally, someone able to setup a buildbot and keep it in a working state. On Tue, Jul 8, 2014 at 11:32 AM, sgundapa <sgundapa at codeaurora.org> wrote: > I believe the C source files in builtins directory are generic enough. > > Why not build a clang_rt.builtins-aarch64 library? > > > >

test_replaygain.sh fails because it calls flac with --endian=big --channels=1 --bps=24 --sample-rate=$1 --sign=unsigned but without --force-raw-format option. The patch is attached. -------------- next part -------------- A non-text attachment was scrubbed... Name: test_rg.patch Type: application/octet-stream Size: 446 bytes Desc: not available Url :

Hi, Is there something wrong with lcov.xapian.org ? It seems my quassel client suddenly can't connect to it. ------------------ Shangtong Zhang,Second Year Undergraduate, School of Computer Science, Fudan University, China. -------------- next part -------------- An HTML attachment was scrubbed... URL:

Thanks to Kevin and Paul for responses. We use a modified Tower of Hanoi scheme (on top of rsync and --link-dest and recycling) for deciding which backups to keep. Here is a sample of our holdings for one area: home.20111124.seq.0 set 0 home.20130512.seq.512 set 10 home.20140203.seq.768 set 9 home.20140414.seq.832 set 7 home.20140708.seq.896 set 8 home.20140815.seq.928 set 6

On 08/07/2014 01:02, Charles Lepple wrote: >>> Sorry I did not test this sooner - this went to Gmane but not to my email. >>> If you have time, could you please write up a quick man page for this driver? >>> >>> Also, there seem to be some missing symbols and include files: >>> >>>