similar to: [LLVMdev] bug in llvm-gcc implementation of long long

On Mon, 4 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: > Compiling the following C code > ------------------------------------------ > long %f4() { > entry: > ret long -2147483648 > } > ------------------------------------------ I get this: long %f4() { entry: ret long 2147483648 } What does the preprocessed output of that function look like? -Chris --

> What does the preprocessed output of that function look like? long long f4(void) { return (long long)2147483647 + 1; } Using 2147483648LL directly causes the same problem. > -Chris Best Regards, Rafael

On Mon, 4 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: >> What does the preprocessed output of that function look like? > long long f4(void) { > return (long long)2147483647 + 1; > } > > Using 2147483648LL directly causes the same problem. What target triple? -Chris -- http://nondot.org/sabre/ http://llvm.org/

Rafael Espíndola wrote: > return (long long)INT_MAX + 1; does it work in ordinary gcc? I recall I had a problem with this in an earlier version of gcc, maybe they still haven't fixed it. m.

> What target triple? i486-linux-gnu > -Chris Rafael

> does it work in ordinary gcc? I recall I had a problem with this in an earlier version of gcc, maybe they still haven't > fixed it. I have just compiled revision 102 without --enable-llvm and the resulting code correctly sets edx to 0. Time to try gdb. Rafael

sscanf is sadly not safe (because it doesn't handle integer overflow correctly), and strto*l functions are a pain to use correctly. Therefore add some functions to hide the pain of parsing integers from the command line. The simpler uses of sscanf and strto*l are replaced. There are still a few where we are using advanced features of sscanf. --- docs/nbdkit-plugin.pod | 48

> Time to try gdb. The problem was a cast of a 32 bits signed number to a 64 unsigned number. A patch is attached. I am currently trying a bootstrap to make sure this doesn't brake anything. Rafael -------------- next part -------------- A non-text attachment was scrubbed... Name: gcc-long-long.patch Type: application/octet-stream Size: 1090 bytes Desc: not available URL:

On Mon, Sep 23, 2019 at 12:05:11PM -0500, Eric Blake wrote: > > + int nbdkit_parse_long (const char *what, const char *str, long *r); > > + int nbdkit_parse_unsigned_long (const char *what, > > + const char *str, unsigned long *r); > > Do we really want to encourage the use of parse_long and > parse_unsigned_long? Those differ between

I am compiling the following code for the MIPS architecture: unsigned char trunc(float f) { return (unsigned char) f; } and it produces the following assembly (directives removed for convenience: trunc: trunc.w.s $f0, $f12 mfc1 $2, $f0 jr $ra nop However, this does not seem to produce the correct output for negative numbers. When I run the following code, I get

I was flipping through the code recently and noticed that we still have the double whammy of allocating dir entry positions with parent_dir->counter++ and that weird setting of f_pos to 2^31-1. So after enough creates (and deletes :)) in a directory we end up with an entry item whose key is past that value. f_pos gets rewound instead of being set to that magical EOF. readdir() gets stuck

Bugs 1519 and 1521 currently prevent a clean bootstrap on Linux x86_64. I was able to hack it to work :-) The attached patch includes two parts. One is a tentative fix bug 1519: just set LastFieldStartsAtNonByteBoundry in allFieldsAreNotBitFields. The other one is a plain hack. llvm-gcc and gcc disagree on how to pass some structures, so stage2 gcc fails to use the libcpp compiled by gcc. So I

Hello, compiling dovecot 2.1 Beta1 under Solaris 10 on SPARC with Sun Studio 11 stops with the following error: Making all in lib-imap-client gmake[3]: Entering directory `/net/fileserv/export/sunsrc/src/dovecot-2.1.beta1/src/lib-imap-client' source='imapc-client.c' object='imapc-client.lo' libtool=yes \ DEPDIR=.deps depmode=none /bin/bash ../../depcomp \

On Mon, 4 Sep 2006, [UTF-8] Rafael Esp?ndola wrote: >> What target triple? > i486-linux-gnu Okay, that is very very strange. This sounds like a failure in the GCC part of the compiler somehow, as constant+constant is folded before we get to it. Can you try to track this down a bit to see what is going wrong? -Chris -- http://nondot.org/sabre/ http://llvm.org/

On Sun, Feb 8, 2015 at 8:38 AM, Hal Finkel <hfinkel at anl.gov> wrote: > > Currently, we might replace: > %cmp = icmp sgt i32 undef, INT_MAX -> i1 false > > According to this proposal, we could replace: > %cmp = icmp sgt i32 undef, INT_MAX -> i1 undef > > While replacing it with false is still allowed, so is replacing it with > true. I'm not sure this

But (Poison > INT_MAX) <=> poison contradicts (X > INT_MAX) <=> false and I don't think you want to abandon the second rule just because x might be poison. - Matthias > On Jan 29, 2015, at 9:43 PM, Sanjoy Das <sanjoy at playingwithpointers.com> wrote: > > One way around this is to say that there are some special > instructions, icmp, sext and zext which

Hello, FYI, this is a bug http://llvm.org/bugs/show_bug.cgi?id=13324 When compiling the following code for sm_20, func params are by some reason given with .align 0, which is invalid. Problem does not occur if compiled for sm_10. > cat test.ll ; ModuleID = '__kernelgen_main_module' target datalayout = "e-p:64:64-i64:64:64-f64:64:64-n1:8:16:32:64" target triple =

On Thu, Jan 29, 2015 at 10:01 PM, Matthias Braun <matze at braunis.de> wrote: > But > (Poison > INT_MAX) <=> poison > contradicts > (X > INT_MAX) <=> false > > and I don't think you want to abandon the second rule just because x might be poison. Maybe we could define poison in such a way that it is safe to pretend it "is" false, as per our

On 2016-09-27 02:28, Philip Reames wrote: > On 09/20/2016 12:05 PM, Matti Niemenmaa via llvm-dev wrote: >> I posted some questions related to implementing inference of nsw/nuw >> flags based on known icmp results to Bug 30428 ( >> https://llvm.org/bugs/show_bug.cgi?id=30428 ) and it was recommended >> that I engage a wider audience by coming here. The minimal context is

On Fri, Sep 07, 2018 at 03:41:52PM +0800, Jason Wang wrote: > > > @@ -556,10 +667,14 @@ static void handle_tx_copy(struct vhost_net *net, struct socket *sock) > > > size_t len, total_len = 0; > > > int err; > > > int sent_pkts = 0; > > > + bool bulking = (sock->sk->sk_sndbuf == INT_MAX); > > What does bulking mean? > > The