search for: signedness

...issues on the new Intel version of Mac OS X. I have been using Apple''s new iMac Core Duo (which comes with Intel version of Mac OS X) for about a week now. Here''s my experience: Ruby 1.8.4: It compiles albeit with many warnings. Most warnings were about "differ in signedness". It seems to work okay mostly though. (Error messages are appended at the end of this message.) PCRE 6.6 (Lighty is dependent on this library): You must compile with -O1 compile optimization option. Otherwise "make test" will fail and Lighty''s domain name matching...

...me using gcc 4.*.*? I noticed that NUT generates an enormous amount of warning noise with that compiler, mostly due to implicit casts between signed/unsigned pointer types. Any volunteers to de-noise the code a bit? The easy way is to insert typecasts; the better way is to actually take care about signedness. -- Peter gcc -I../include -O -Wall -Wsign-compare -c -o everups.o everups.c everups.c: In function Code: everups.c:38: warning: pointer targets in passing argument 2 of ser_get_char differ in signedness everups.c: In function InitUpsType: everups.c:49: warning: pointer targets in passing argume...

...as no type or storage class res_config_oracle.c: In function 'realtime_oracle': res_config_oracle.c:109: warning: incompatible implicit declaration of built-in function 'snprintf' res_config_oracle.c:127: warning: pointer targets in passing argument 3 of 'checkerr' differ in signedness res_config_oracle.c:129: warning: pointer targets in passing argument 3 of 'OCIStmtPrepare' differ in signedness res_config_oracle.c:130: warning: pointer targets in passing argument 3 of 'checkerr' differ in signedness res_config_oracle.c:133: warning: pointer targets in passing ar...

...pt/local/include/libxml2 -I/opt/local/include -g -O2 -c `test -f 'stream_shared.c' || echo './'`stream_shared.c stream_shared.c: In function 'process_and_send_buffer': stream_shared.c:184: warning: pointer targets in passing argument 2 of 'downmix_buffer' differ in signedness source='metadata.c' object='metadata.o' libtool=no \ depfile='.deps/metadata.Po' tmpdepfile='.deps/metadata.TPo' \ depmode=gcc3 /bin/sh ../depcomp \ gcc -DHAVE_CONFIG_H -I. -I. -I.. -ffast-math -fsigned-char -I/opt/local/include -I/opt/local/include/libxml2 -I/opt...

Hi I currently would like to find out the signedness of a instruction. But looking at the CBackend, it looks as if it is not that simple? So i have two questions: Is there an easier way than guessing as it is done in the CBackend? Is there a reason for that signedness is not part of the instruction type? Best regards ST

...fno-common -I/usr/include/libxml2 -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I. -I/usr/local/include -c ruby_xml.c ruby_xml.c: In function ‘rxml_default_tree_indent_string_set’: ruby_xml.c:575: warning: pointer targets in assignment differ in signedness ruby_xml.c: In function ‘rxml_default_tree_indent_string_set’: ruby_xml.c:575: warning: pointer targets in assignment differ in signedness gcc -I. -I. -I/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/lib/ruby/1.8/universal-darwin9.0 -I. -I/usr/local/include -DRUBY_EXTCONF_H=\"extco...

On Tue, Jun 3, 2008 at 2:42 AM, ST <st at iss.tu-darmstadt.de> wrote: > Hi > > I currently would like to find out the signedness of a instruction. But > looking at the CBackend, it looks as if it is not that simple? So i have two > questions: > Is there an easier way than guessing as it is done in the CBackend? > Is there a reason for that signedness is not part of the instruction type? A lot of LLVM integer ins...

...: >>> >>>> Thanks for your reply. >>>> >>>> We are propagating sign info to tablegen currently using >>>> BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm. >>>> >>> >>> Note that this flag doesn't indicate signedness of the operation. It >>> just means that the optimizer or code generator can assume that no >>> signed >>> overflow will happen during the operation. To get a better >>> understanding >>> of why this flag is not suitable for reconstructing the signed...

....h:7: warning: type defaults to 'int' in declaration of 'udev' hid-usb.h:7: warning: data definition has no type or storage class libhid.c: In function 'HIDGetItemString': libhid.c:258: warning: pointer targets in passing argument 2 of 'libusb_get_string' differ in signedness libhid.c:259: warning: pointer targets in return differ in signedness libhid.c: In function 'HIDGetEvents': libhid.c:368: warning: implicit declaration of function 'malloc' libhid.c:368: warning: incompatible implicit declaration of built-in function 'malloc' libhid.c: In...

...and operations > if they don't have to) have no sign. But IR integers have to be printed > somehow and it was decided to print them as being signed. > > I'm not a SelectionDAG and tablegen expert really, but I'm sure it is the > same in the code generator. Sometimes the signedness is important for an > instruction because flags are affected. But I'm ignoring that for now, as > they would be represented as llvm.*.with.overflow in the IR with explicit > signedness. > > In cases where flags don't matter, just select the best instruction. I'd > ad...

Hi, my target handles operands of multiplying instructions differently based on signedness. I wonder then how I would do instruction selection based on the operands signs? The mul instruction sets a nsw for signed, but when i try unsigned ops, there is no wrap flag at all. I'm not sure this is enough information to work with, or? Jonas -------------- next part -----...

...ft-float -m64 -mno-red-zone -fpic -fno-reorder- blocks -fno-asynchronous-unwind-tables -DNDEBUG -c cpu/common.c -o cpu/common.o cc1: warnings being treated as errors cpu/common.c: In function ‘early_cpu_detect’: cpu/common.c:209: warning: pointer targets in passing argument 2 of ‘cpuid’ diff er in signedness cpu/common.c:209: warning: pointer targets in passing argument 3 of ‘cpuid’ diff er in signedness cpu/common.c:209: warning: pointer targets in passing argument 4 of ‘cpuid’ diff er in signedness cpu/common.c:209: warning: pointer targets in passing argument 5 of ‘cpuid’ diff er in signedness cpu/c...

...nueljacob.de> wrote: > On 2017-02-15 19:54, Ryan Taylor wrote: > >> Thanks for your reply. >> >> We are propagating sign info to tablegen currently using >> BinaryWithFlagsSDNode.Flags.hasNoSignedWrap atm. >> > > Note that this flag doesn't indicate signedness of the operation. It just > means that the optimizer or code generator can assume that no signed > overflow will happen during the operation. To get a better understanding > of why this flag is not suitable for reconstructing the signedness of an > operation (which is actually inheren...

...ibpq-compat.c: In function ‘PQescapeBytea’: libpq-compat.c:104: warning: implicit declaration of function ‘sprintf’ libpq-compat.c:104: warning: incompatible implicit declaration of built-in function ‘sprintf’ libpq-compat.c:104: warning: pointer targets in passing argument 1 of ‘sprintf’ differ in signedness libpq-compat.c: In function ‘PQunescapeBytea’: libpq-compat.c:158: warning: implicit declaration of function ‘strlen’ libpq-compat.c:158: warning: incompatible implicit declaration of built-in function ‘strlen’ libpq-compat.c:158: warning: pointer targets in passing argument 1 of ‘strlen’ differ in...

Hi Jonas, > my target handles operands of multiplying instructions differently based on > signedness. since the result of a multiply doesn't depend on the signedness, I find it strange that your target differentiates between them. What I'm saying is that if you have (say) two i32 numbers a and b and you do a signed multiply: c = a *s b and an unsigned multiply d = a *u b then c and...

Hello, Alberto. > I'm using llvm for instrumenting code, and I need to know if there's a way to > difference between signed and unsigned Values of integer type during an > optimization pass. Types are signless in LLVM 2, operations are not. So, you should probably inspect insts itself, not their operands. -- With best regards, Anton Korobeynikov. Faculty of Mathematics &

The problem is that what i'm instrumenting is loads and stores, plus function call arguments and return values, which have no signedness information. El 26/06/2007, a las 17:03, Anton Korobeynikov escribió: > Hello, Alberto. > >> I'm using llvm for instrumenting code, and I need to know if >> there's a way to >> difference between signed and unsigned Values of integer type >> during an &...

On Tue, 26 Jun 2007, [ISO-8859-1] Alberto González wrote: > The problem is that what i'm instrumenting is loads and stores, plus > function call arguments and return values, which have no signedness > information. Why do you need this? -Chris > El 26/06/2007, a las 17:03, Anton Korobeynikov escribió: > >> Hello, Alberto. >> >>> I'm using llvm for instrumenting code, and I need to know if >>> there's a way to >>> difference between sign...

...sicBlock: "In basicBlock B, what is the set of possible > assignments for each live values ?" > and I obtains results such as "In B, we have 0 <= x <= 42" > Well, you have to find that from the comparisons that control the branches to the blocks, so you determine signedness from the signedness of the comparison instructions. (And get to have the fun of figuring out the right thing to do when the instructions mix signedness.) ~ Scott

...libs/klibc/klibc.git;a=commit;h=8443e57e5ba71e462e31e3b5aad9f7dd1b4736f5 Author: Ben Hutchings <ben at decadent.org.uk> AuthorDate: Tue, 5 Nov 2019 00:39:53 +0000 Committer: Ben Hutchings <ben at decadent.org.uk> CommitDate: Tue, 5 Nov 2019 00:44:32 +0000 [klibc] losetup: Fix char signedness mismatches with <linux/loop.h> For some reason the kernel's definition of struct loop_info64 defines string fields as arrays of __u8 (unsigned char) instead of char. Add the necessary casts to avoid compiler warnings. Signed-off-by: Ben Hutchings <ben at decadent.org.uk> --- us...