Path: csiph.com!usenet.pasdenom.info!aioe.org!.POSTED!not-for-mail From: "Rod Pemberton" Newsgroups: comp.os.msdos.programmer Subject: Re: Smaller C compiler Date: Fri, 06 Dec 2013 12:19:10 -0500 Organization: Aioe.org NNTP Server Lines: 124 Message-ID: References: <2aec554a-416a-48b3-94fb-3ec8c8cf215d@googlegroups.com> <943963d2-d981-4863-831f-c74b57a4db75@googlegroups.com> NNTP-Posting-Host: CNsg4fVcCsvs3UaOgZtQCw.user.speranza.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Opera Mail/12.16 (Linux) X-Notice: Filtered by postfilter v. 0.8.2 Xref: csiph.com comp.os.msdos.programmer:1119 On Fri, 06 Dec 2013 00:37:26 -0500, Alexei A. Frounze wrote: > On Thursday, December 5, 2013 3:33:51 AM UTC-8, Rod Pemberton wrote: >> On Wed, 04 Dec 2013 05:20:43 -0500, Alexei A. Frounze >> <...@gmail.com> wrote: >> > On Wednesday, December 4, 2013 2:01:02 AM UTC-8, Rod Pemberton wrote: >> >> On Wed, 04 Dec 2013 04:31:56 -0500, Rod Pemberton >> >> At the "Constant too big for %d-bit type" line in smlrc.c. >> >> >> >> SizeOfWord is 4, for 32-bits. >> >> sizeof(n) is 4, where n is an 'unsigned'. >> >> n >> 8 >> 12 >> 12 is 31. >> >> n >> 32 is 0. >> > >> > Precisely. The idea is to make sure that if n (IOW, unsigned) >> > is larger than 32 bits, I can see if it's value doesn't fit >> > into 32 bits. >> > >> >> Could OW v1.3 be having problems with the multiple shifts? >> > >> > I don't know for sure, but I bet it very well could [...] >> >> I did the following: >> >> changed multiple >> to single in the source >> changed multiple << to single in the source >> >> After that, I get the following error (32-bit): >> >> Error in "smlrc.c" (374:14) >> >> Variable(s) take(s) too much space >> >> This seems to be from errorVarSize(). It's the errorVarSize() >> call with near "(size != truncUint(size))" in case '(' of >> GetDeclSize(). size is 4. truncUint(size) is 0. 32-bits. >> You use ~0u in truncUint(). >> >> OpenWatcom v1.3 results of ~0u and with shifts: >> >> wcl/l=dos >> >> ~0u 8000ffff >> ~0u<<15 80000000 >> ~0u<<16 0000 >> ~0u<<8<<7 0002 >> ~0u<<8<<8 6322 or 6333 > > How come 16-bit ints look like 32-bit? Where's the garbage coming from? > I mean "8000" in "8000ffff". > It's coming from the program when it prints the value. Specifically, it's from a "%04lx" to a printf(). It overflowed. E.g., printf("%04lx\n",~0u); Yes, in theory, it should truncate to only four digits for display... Most likely, the compiler is using a larger intermediate representation, for some reason, i.e., an "implicit" cast or size conversion. FYI, a "%08lx" was used for 32-bit values, which displayed 8 digits for each. Personally, if I was attempting to do something like this, which I generally wouldn't because of possible differences in representation, I would cast to a known size for each compiler, with my preference being "unsigned long", and logically and & with 0xFFFF or 0xFFFFFFFF, etc. > Also, what does "6322 or 6333" mean? > That depends on the call to truncUint() where I inserted a line to print all those values. truncUint() is called multiple times when smrlc compiles itself. It seems to print 6322 sometimes and 6333 other times, i.e., appears it's being corrupted to me. The values would tend to imply by characters overwriting to me, but I have no idea what the values actually indicate. >> wcl386/l=dos4g >> >> ~0u ffffffff >> ~0u<<31 80000000 >> ~0u<<32 ffffffff >> ~0u<<8<<12<<11 80000000 >> ~0u<<8<<12<<12 00000000 >> >> Obviously, some things are not correct or computing as expected. > > For one thing, you shouldn't be expecting much from shifting a > 16-bit int by 16 bit positions or from shifting a 32-bit int by > 32 bit positions. Both invoke undefined behavior. > I shouldn't? You're the one doing so... <<8<<12<<12. Yes? I just reduced the shifts to see if multiple shifts were a parsing issue. Even if the compiler doesn't optimize them into a single shift, it's still a total shift of 32 bits. So, if the result of that is undefined, then it's undefined either way, correct? ... >> It appears that Rugxulo has OpenWatcom versions 1.3 and 1.7 >> on his website: >> https://sites.google.com/site/rugxulo/ > > What's wrong with the official OW website? AFAIK, nothing. they might still have 1.7 around, perhaps 1.3 too. Of course, they might not, which is what I suspect for 1.3. Anyway, the point was you could, if you wanted, check each to find out was is going on without needing me. It's very possible 1.3 is broken, but then again, maybe not. If I had 1.7 or 1.9, I'd test it for you, but I have no plans to install them. Personally, I decided to move away from using OW, even though it produces better code, IMO. Rod Pemberton