Re: [Tinycc-devel] char points and char array
On Thu, Dec 24, 2009 at 09:58:50AM +0800, wrote: > char *s='hello,world'; > *(s+2) = '\0'; > > which in ansi C are not allowed cause *s is consider as read only The exact wording is "if the program attempts to modify such an array, the behavior is undefined". This is not a constraint violation, so the compiler is not required to detect the error or enforce any particular outcome. Because the behavior is undefined, _any_ result is considered valid, including placing the string literal in writable storage and modifying its content. The compiler can assume that no valid program will ever contain code such as the above, and it is the programmer's responsibilty to avoid writing undefined code in the first place. > and i compile the code with gcc it show me segment error while running > but tcc accept this act That's because gcc normally places string literals into read-only storage and the system detects the attempt to write there. The compiler is not required to do this. Older versions of gcc even had a command-line option to control whether strings were placed in read-only or writable storage. > btw,how to generate the asm code using tcc? I believe tcc compiles directly to machine code without an assembly stage. If you want to see what it produces, you'll need to use a disassembler on the resulting binary. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] "identifier expected"? But not by GCC.
On Sat, Apr 18, 2009 at 03:23:31AM +0800, KHMan wrote:
> test.c:10: error: a label can only be part of a statement
> and a declaration is not a statement
>
> IIRC it's not ISO C90 compliant. Nothing wrong with tcc. I'll leave the
> digging up the ISO C standard to others.
According to the C grammar, a declaration is not a statement, but both
are block items. The reason you can mix them in other contexts is
because a braced block contains block items rather than just
statements:
compound-statement:
'{' block-item-list-opt '}'
block-item:
declaration
statement
A labeled statement is more strict and requires a statement rather
than a block item:
labeled-statement:
identifier ':' statement
'case' constant-expr ':' statement
'default' ':' statement
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.
On Tue, Apr 14, 2009 at 06:37:49PM +0100, lostgallifreyan wrote: > Dave Dodge wrote: > >If the filename string contains any high-valued characters, such as > >accented letters, then accessing it with a char* might produce a > >negative char value, and passing that to isupper/islower can be a > >problem. > > Ok. Point taken about undefined behaviour. Is the "unsigned char *p" > declaration enough though? Yes. Dereferencing a valid (unsigned char *) will produce an (unsigned char), which by definition is safe to pass to isupper. > One mail suggested using "unsigned" at every subsequent use of the > variable. That's because p was a (char *), and therefore *p was producing a possibly-signed value. Casting the dereferenced value to (unsigned char) is another way of ensuring isupper gets a usable value, but I think simply changing p to an (unsigned char *) is cleaner. BTW it's worth noting that casting from a signed integer to an unsigned integer is a well-defined operation, but casting from unsigned to signed is implementation-defined. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.
On Tue, Apr 14, 2009 at 12:21:50PM +0100, lostgallifreyan wrote: > "Charlie Gordon" wrote: > >Also more importantly, do not pass char arguments to > >tolower/toupper and islower/isupper functions. 'char' may be > >signed whereas these functions expect an int parameter with a value > >among those of type unsigned char or EOF. > As the variable isn't assigned any negative values it's not going to > be an issue, If the filename string contains any high-valued characters, such as accented letters, then accessing it with a char* might produce a negative char value, and passing that to isupper/islower can be a problem. > Actually I forgot the unsigned char bit but even so, it compiled > without error or warning and it worked. I think you've mentioned you're new to C, in which case you need to understand that "compiled without error or warning and it worked" doesn't mean very much. C has the concept of "undefined behavior", which basically means the compiler is allowed to quietly accept the code but there are no constraints on what it actually does when you run it. It might even produce the expected result for some inputs. Passing a value outside the range of unsigned char (or EOF) to a function such as isupper is an example of something that produces undefined behavior. The program might implicitly cast it to unsigned char, or change it to 0, or corrupt memory, or crash, or quietly erase the hard drive and set the printer on fire. While some of these actions are perhaps more likely than others, all of them are a correct result as far as C is concerned. For example given a blatantly undefined bit of code such as: isupper(-20) gcc does not give a warning, even with -pedantic, -Wall, and -Wextra. Whatever it actually does when you run it, there is no guarantee that it will do the same thing in any other C compiler (including other versions of gcc). -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re: TCC:cannot find -l"xyz.dll"
On Wed, Apr 08, 2009 at 06:55:12PM +0100, lostgallifreyan wrote: > Joshua Phillips wrote: > >For case-insensitive comparisons in C, there's strcasecmp (GNU) and stricmp > >(MSVCRT). They're both identical in function, but are non-standard > >extensions. > > No generic case comparion OR forcing in C? Not for complete strings. There are case-folding functions for individual characters, and you can trivially case-fold a string by iterating over its content. Something like this, perhaps: for (unsigned char * p = s;*p != '\0';p++) *p = tolower(*p); > Lua is based in C Lua's "string.upper" function constructs a new string by calling C's "toupper" function on each of the original string's characters. The "string.lower" function does the same thing using "tolower". Aside: C also has case-folding functions for wide characters, but they probably aren't sufficient to handle Unicode because they just have single characters as input and output. Unicode's case folding algorithms sometimes change the string length. For example the German sharp-s is a single character in lower case but two characters in upper case, and Greek has even more complex conversions. There's also the issue that some letters fold differently based on the source language. C's locale support might be able to deal with this if you adjust the locale to match the text being processed (rather than the user environment). For example the case conversions for "i" and "I" are different in Turkish than in English. In one bizarre situation, using the English conversions on some Turkish text apparently set off a chain of events leading to multiple homicides: http://www.gizmodo.com.au/2008/04/a_cellphones_missing_dot_kills_two_people_puts_three_more_in_jail-2.html -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] wrong preprocessor shift operation
On Tue, Dec 30, 2008 at 05:32:57PM +0100, grischka wrote:
> Christian Jullien wrote:
>> printf("fails %08x\n", (~0) >> 1);
> fails
> Maybe gcc is not correct but then I need an exact explanation why ;)
0 has type int. On x86 the representation is 32 value bits set to
zero, with no padding bits.
~0 flips all of the bits of the representation, producing an int with
value -1.
(~0) >> 1 is a right-shift of a signed integer with negative value,
which is an implementation-defined operation. On x86, this is usually
implemented with the SAR instruction, which divides by 2 with rounding
toward -infinity. -1/2 rounded toward -infinity is -1, so the value
is unchanged.
This then passes int -1 to a printf specifier that expects unsigned
int. Since the value is negative and cannot be represented by
unsigned int, you get undefined behavior and any result is allowed.
I believe in this case, the representation of int -1 is reinterpreted
as an unsigned int, producing the printed value . But really,
the test itself is fundamentally broken.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Can the code comply to c89
On Wed, Mar 19, 2008 at 01:24:45PM +0800, Hanzac Chen wrote:
> I think the extensions of gcc should not be used especially. Here
> is the patch to make it compiled by VC.
-[OP_REG8] = 0,
-[OP_REG16] = 1,
-[OP_REG32] = 2,
+ 0,
+/* [OP_REG8] = */ 0,
+/* [OP_REG16] = */ 1,
+ 0,
+/* [OP_REG32] = */ 2,
BTW this is not a gcc extension; designated array initializers are a
standard feature of standard C99. Granted, last I checked Microsoft's
compiler doesn't even try to support C99 and they have no plans to
bring it up to spec.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] .hgtags in .hgignore?
On Wed, Nov 28, 2007 at 09:12:37AM +0800, KHMan wrote: > Joshua Phillips wrote: > > I've just noticed that .hgtags is in the .hgignore list - > > this doesn't seem right! > > I've no idea whether it's right or wrong; I don't think it's a problem. I just looked at a project of my own and I've got .hgtags in there as well. It appears to be an artifact of converting an existing repository to hg by using "tailor". Tailor generates .hgignore automatically in revision 0 and uses that particular style of matching expression within. My project's revision 0 .hgignore looks just like tinycc's except it ignores .svn instead of CVS. Note that despite being in .hgignore, the .hgtags file _is_ under revision control, as can be seen by doing "hg log .hgtags". Assuming you use "hg tag" to add tags, they'll get committed immediately and the fact that "hg status" ignores the file is a non-issue. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Sample patch from Mercurial repository
On Fri, Nov 02, 2007 at 09:31:23AM -0600, Gregg Reynolds wrote: > On 11/2/07, KHMan <[EMAIL PROTECTED]> wrote: > > grischka wrote: > > > Do you think it is possible and/or makes sense to extract all > > > changesets from Rob's repo into single patches first, with an > > > automatic script or something? > > In case you're not aware of it, check out Mercurial Queues > (http://hgbook.red-bean.com/hgbookch12.html#x16-26500012) which might > be helpful for this sort of thing. Also see "quilt" (http://savannah.nongnu.org/projects/quilt) if you want to manage patches without Mercurial. Quilt can be used with svn. Mercurial Queues (mq) are basically just a direct reimplementation of quilt, with several improvements because the patch stack and diffing is integrated into the Mercurial revision history. If you configure mq to use git-format patches it can even properly track renames and other corner cases via patch files. At work I used to use svn+quilt for all of my development; now I use mq instead and it's noticably nicer. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Sample patch from Mercurial repository
On Mon, Oct 29, 2007 at 02:59:15AM +0800, KHMan wrote: > Attached is a sample patch based on the Mercurial repository. I > assume revisions up to 395 is already in the official CVS, Just a quick note about mercurial: revision numbers such as 395 are just a convenience and are locally assigned to each copy of the repository. They aren't guaranteed to be the same for each user; in fact local commits will quickly knock them out of sync. Changeset IDs such as f357b2f8add5 _are_ kept globally consistent, so if you want to specify a particular change you can use those. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Buiding binutils 2.17 (needs dynamic arrays).
On Thu, Oct 04, 2007 at 05:15:55PM -0500, Rob Landley wrote:
> I dunno, is gcc claiming c99 compliance?
No, because they know some parts are missing or broken. They do
however keep a status chart of how they match up:
http://gcc.gnu.org/c99status.html
In one interesting case, gcc was known to not conform to a subtle
aspect of C99 having to do with the relationship between sizeof and
offsetof on a struct with a flexible array member:
http://gcc.gnu.org/ml/gcc/2002-05/msg02858.html
Here's an example of the problem in the wild:
http://www.ussg.iu.edu/hypermail/linux/kernel/0212.3/0206.html
Apparently the WG decided that gcc (and the other compilers including
tcc) had it right because n1124 has new wording that seems to remove
the constraint the compiler(s) were violating.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Parentheses handling within struct/union initialization
On Fri, Sep 28, 2007 at 06:47:09PM +0200, Marc Andre Tanner wrote:
> struct in6_addr {
> union {
> uint8_t u6_addr8 [ 16 ] ;
> uint16_t u6_addr16 [ 8 ] ;
> uint32_t u6_addr32 [ 4 ] ;
> } in6_u ;
> } ;
[...]
> IPADDR ip4_any = {
> 2,
> { ( ( in_addr_t ) 0x ) } // broken
> //{ ( in_addr_t ) 0x } // this would work
> };
Two things to note about this:
- It's making use of a gcc language extension. Proper C would require
at least some additional braces around that initializer value.
- Even with gcc's initializer extension, it only produces the
"correct" result as a side effect. The lack of a designated
initializer means that the initializer value gets assigned only to
the very first thing in the union. The 32-bit (in_addr_t)0 is
truncated to 8 bits and assigned to u6_addr8[0]. The remaining 15
elements of u6_addr8[] are implicitly zero-filled just like any
other integer array that only had its first element initialized.
The cast to in_addr_t is misleading, because it's not going to store
32 bits in the union and if you try to use any value _other_ than 0
you may not get what you want. For example if you try something
like 0x it will assign 0xff to only the first byte of the
union and zero-fill the other 15.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Wed, Sep 26, 2007 at 05:03:02AM -0500, Rob Landley wrote:
> Dunno about mpeg2.
MPEG-2 continues to be covered by a huge number of patents from 25+
companies. The mere list of worldwide patent numbers is 27 pages
long. It's such a morass that a special licensing authority (MPEG LA)
was set up to provide one-stop shopping for terms and payment.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [BUG] Nested array/struct/union initialization problem
On Wed, Sep 26, 2007 at 02:46:45AM -0500, Rob Landley wrote:
> Anyway, the first thing I'd do is try to pare the test case down to
> something smaller.
struct foo{
union{
int i;
};
};
static struct foo f = {
{ .i = 0 }
};
> I'm currently looking at unary() for one of the other issues
I took a brief look at it earlier. I traced it this far (line numbers
in tcc.c are a bit off due to the inserted trace code):
decl_initializer called from decl_initializer_alloc:8136
decl_initializer called from decl_designator:7598
decl_initializer called from decl_initializer:7911
expr_const1 called from init_putv:7641
expr_eq called from expr_const1:7129
uneq() called from expr_prod:6802
unary called from uneq:6779
unary:6368 tok=46
unary:6612 t=46
foo.c:8: unary: 6615: identifier expected
Basically I think it's entering the big switch in unary() with the '.'
as the token, which drops to the default case. Give the union a field
name in the struct, _or_ remove the ".i=" from the initializer, and it
takes it with this trace:
decl_initializer called from decl_initializer_alloc:8136
decl_initializer called from decl_designator:7598
decl_initializer called from decl_designator:7598
expr_const1 called from init_putv:7641
expr_eq called from expr_const1:7129
uneq() called from expr_prod:6802
unary called from uneq:6779
unary:6368 tok=179
Note that this time the token is 179, even when you merely name the
union and leave the ".i=" in place.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Preprocessor: ignore everything after #error or #warning
On Wed, Sep 26, 2007 at 01:23:32AM -0500, Rob Landley wrote: > Hmmm... What about #warning as last line of the file with no newline at the > end of the line? FWIW, the grammar for most preprocessing directives explicitly includes a newline. gcc accepts a #warning with no newline but emits an additional warning about the missing newline. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Wed, Sep 26, 2007 at 12:11:58AM -0500, Rob Landley wrote:
> I realize that they want to restrict their relevance as much as
> possible, and thus have no _official_ version freely available on
> the web.
I think part of the problem is that selling copies of standards has
long been a basic part of how groups like ANSI and ISO fund their
operations.
> I seriously hope that whatever the next version of the C standard is
> has nothing to do with people who fail to get it that spectacularly.
Some improvements have been made, slowly. C89 eventually became
indirectly available in hardcopy for about $40 (as part of Schildt's
book). Corrigenda and Rationales are usually free. ANSI sold a
downloadable PDF of C99 for $18 at one point, though the current price
on their webstore appears to be an old-school $289, ugh. IEEE has the
POSIX/Unix spec online and downloadable at no cost. I think even ISO
has seen the light a little bit; I recall the ffmpeg folks found a way
to download some of the MPEG standards legitimately for free (granted
this did nothing to solve the patent-licensing issues for those
particular standards).
n1124 is the best current "free" reference for implementing C99, as it
includes the final C99 text plus the 2001 and 2004 corrigenda.
http://www.open-std.org/JTC1/SC22/WG14/www/standards
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [BUG] Nested array/struct/union initialization problem
On Tue, Sep 25, 2007 at 06:37:01PM +0200, Marc Andre Tanner wrote:
> The call to expect comes from within unary () at tcc.c:6587 where t = '.'
>
> struct format_option {
> union {
> const char * fo_str ;
> int fo_int ;
> int fo_time ;
> } ;
Bear in mind that Standard C requires a name for this union. tcc
allows it to be anonymous as an extension, presumably to be compatible
with gcc which itself only allows it in order to be compatible with
other compilers. gcc does throw a fit if you try to compile that code
with "-std=c99".
It looks like there's some sort of conflict or missing code to get
designated initializers and anonymous unions working together. If you
take out the designated initializer tcc will accept it, but with the
downside that you can't initialize fo_int or fo_time. Alternatively,
if you give the union a name tcc will accept it (and the code becomes
proper C), but you'll probably also have to fixup all of the places
that access that union.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Preprocessor: ignore everything after #error or #warning
On Tue, Sep 25, 2007 at 09:58:03AM +0200, Marc Andre Tanner wrote: > Dave Dodge wrote: > >The real problem here seems to be that a bare apostrophe can be a valid > >preprocessing token according to C99, > > Ok i took a look at the C99 draft link which you posted and found the > following in 6.4 #3: [...] > and single non-white-space characters that do not lexically match > the other preprocessing token categories.58) If a ' or a " > character matches the last category, the behavior is undefined. > > I am not quite sure whether i have understood the above but doesn't it > say that the behavior of a ' in this context is undefined? You're right. I missed that caveat about single quotes being undefined. I'd mainly looked at the grammar in Annex A, which simply says "each non-white-space character that cannot be one of the above" and doesn't bother to mention quotes as a special case. So the _real_ problem is that the C code you're processing has undefined behavior ;-) You could argue that since the line in question is #ifdef'd out, the token shouldn't be a problem. But going strictly by the Standard you get the undefined behavior as early as translation phase 3 when the tokenization takes place, and the #ifdef doesn't get handled until phase 4. Note that the bare apostrophe probably also wreaks havoc with syntax highlighting editors. Emacs 21.4 seems to get very confused by it. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Sat, Sep 22, 2007 at 02:01:45AM -0500, Rob Landley wrote:
> Where would I find info on the legal status of these drafts? I'd love to
> mirror both versions on kernel.org/doc but not if I can't nail down that the
> terms are...
The n1124 draft I obtained at www.open-std.org (sponsored by a Danish
college) doesn't have doesn't have any copyright or distribution
notice on it. Digging around, I find this document from ISO about
their copyright policy:
http://isotc.iso.org/livelink/livelink/4230281/Guidelines_and_policies_for_the_protection_of_ISO_s_intellectual_property_ISO_GEN_09.pdf
According to Annex 1 (1.4), their policy for draft documents is:
While the reproduction of working drafts or committee drafts in any
form for use by participants in the ISO standards development
process is permitted without prior permission from ISO, neither [the
draft] nor any extract from it may be reproduced, stored or
transmitted in any form for any other purpose without prior written
permission from ISO.
My very limited experience from the sidelines has been that what they
really care about are the for-pay final Standards, and drafts are
passed around without raising any complaint. Mirroring at kernel.org
does however sound like "other purpose" and would technically require
permission -- which they might be reluctant to give since they don't
really want people relying on possibly outdated drafts as an
implementation reference.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH] Preprocessor: ignore everything after #error or #warning
On Mon, Sep 24, 2007 at 05:39:07PM +0200, Marc Andre Tanner wrote:
> There seems to be a problem in the skiping of preprocessor directives,
> tcc attempts to parse the string even after #error or #warning and
> complains when it shouldn't.
An #error (or the non-standard #warning, if you assume it works
similarly to #error) is supposed to contain preprocessing tokens. The
real problem here seems to be that a bare apostrophe can be a valid
preprocessing token according to C99, but tcc doesn't seem to have any
way to recognize it as such in preprocess_skip(). I don't have a
better solution, though.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Fri, Sep 21, 2007 at 06:04:01PM -0500, Rob Landley wrote: > I have a draft of the spec itself, in html format. BTW (this has probably been mentioned before) n1124 is a newer freely-available draft, which is closer to the C99 final than n869 (which is what I assume your HTML version is based on). The downside is that n1124 only comes in PDF format. I still go to n869 first myself since I can search/browse it in a text editor. > that I'm waiting for "gonna" to become an official contraction of > "going to", Aside: OED documents "gonna" but lists it as a US colloquialism. Dates to 1913, similar to "ganna" and "gaunna" which date to 1806. > Wandering back on topic, people who care about formal mathematical > models use lexx and yacc. People who want to turn source code into > object code in a fast and simple way with minimal external > dependencies hand code recursive descent parsers in ways that make > theoretical mathematicians' skin crawl. Another problem with lexx and yacc is that it's nearly impossible to get a clean build from their output if you have warnings enabled. My latest workaround was to write my own generator using parsing expression grammers, which spits out threadsafe recursive descent parsers. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Segmentation fault compiling jslong.c
On Thu, Sep 20, 2007 at 11:38:11PM -0500, Rob Landley wrote:
> On Thursday 20 September 2007 9:35:05 pm Gregg Reynolds wrote:
> > On 9/20/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> > > means is "doesn't move", same root as stasis.
> >
> > Mmm, more like "stands", which isn't quite the same.
>
> *shrug* My last etymology course was in 1987, I'm not interested in arguing
> with you.
OT: (since I have OED handy): "static" comes from Latin staticus, from
the Greek ({sigma}{tau}{alpha}{tau}{iota}{kappa}{goacu}{fsigma})
"causing to stand" and also pertaining to [skill in] weighing. It's
heavily overloaded even in English; OED has 7 definitions for it just
as an adjective. Earliest quotations OED has are mid-1600s, mostly to
do with weighing things though there's a rare usage describing someone
as having a stable mental condition. Its use in regard to
electricity, and in physics as the opposite of "dynamic", dates from
the mid-1800s.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Today's bug...
On Thu, Sep 06, 2007 at 05:42:35AM -0500, Rob Landley wrote:
> That definition comes from /usr/include/features.h, and to make
> a long story short we get it by #defining __STDC_VERSION__ 199901L
>
> Since we _do_ support c99, this shouldn't break anything. I think...
Well you can always just define it unconditionally, and then if anyone
complains about some broken C99 feature you can fall back on the same
rationale that gcc uses for defining __STDC__ unconditionally ;-)
"Sometimes people say that defining `__STDC__' in a compiler that
does not completely conform to the ISO C standard somehow violates
the standard. This is illogical. The standard is a standard for
compilers that claim to support ISO C, such as `gcc -ansi'--not
for other compilers such as plain `gcc'. Whatever the ISO C
standard says is relevant to the design of plain `gcc' without
`-ansi' only for pragmatic reasons, not as a requirement."
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Today's bug...
On Thu, Sep 06, 2007 at 06:33:14AM -0500, Rob Landley wrote:
> It seems that the right thing to do is set __STDC_VERSION__ to show we have
> c99, which I did, although now includes of regex.h are barfing. This might
> be a glibc bug, or might be that we need to understand "restrict",
Note that if "restrict" turns out to be the problem, one option is to
recognize but ignore the keyword entirely. Assuming the program being
compiled is written correctly, it won't make any semantic difference
to simply pretend that the "restrict" isn't there:
The intended use of the restrict qualifier (like the register
storage class) is to promote optimization, and deleting all
instances of the qualifier from a conforming program does not
change its meaning (i.e., observable behavior).
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Thu, Sep 06, 2007 at 02:13:53AM -0500, Rob Landley wrote: > On Wednesday 05 September 2007 9:55:43 pm Dave Dodge wrote: > > Cray had some architectures with 64-bit bytes, but simulated 8-bit > > bytes in userspace by using otherwise-unused high bits in a pointer to [...] > Again, does Linux run there? Aside: no, but they did run an 80s-era System V Unix with this crazy design. I pretty easily got an existing Unix application of mine running on one of these machines back in the early 90s, though it probably helped that the app was already designed to be portable. I think a good chunk of the GNU toolset (minus gcc) worked on those systems as well, though I don't recall for sure. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] 4 bugfixes for Rob Landley's revision 470
On Wed, Sep 05, 2007 at 08:46:30PM -0500, Rob Landley wrote: > On Wednesday 05 September 2007 7:14:30 pm Simon 'corecode' Schubert wrote: > > Like the majority of internet protocols. Actually, if you fopen() > > a text file with mode "rt" it does convert \r\n to \n. > > On Linux? That's not in the man page... No, the "t" is a Windows thing. In Standard C: "r" open for reading in text mode "rb" open for reading in binary mode UNIX/Linux accepts both forms, but of course there is no distinction between text and binary mode so the "b" is just ignored. On Windows: "rt" open for reading in text mode "rb" open for reading in binary mode "r" whether you get text or binary mode depends on the current setting of the global _fmode. Note that the default value for _fmode depends on how the application was linked. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Wed, Sep 05, 2007 at 06:17:38PM -0500, Rob Landley wrote: > On Wednesday 05 September 2007 5:32:06 pm Dave Dodge wrote: > > For Linux certainly. My understanding is that there are current > > architectures in the embedded market that use a 32-bit char, though. > > I haven't heard of them, and am not interested in supporting them. Just FYI looking into it, this is mostly to do with DSP chips. There's some SHARC device(s) with 32-bit bytes, and the TI TMS32F28xx family reportedly uses 16-bit bytes. > (I know that arm hasn't got instructions to manipulate bytes, but > char is still 8 bits on arm linux. The compiler emits code to mask > and shift to make it work, which is why you never want to use a char > as a loop index on arm.) If I recall the story correctly, early Alpha chips only had full 64-bit loads and stores, and simulated 8-bit loads and stores by means of shifts and masks. One of the subtle effects of this scheme was that single-char stores were not atomic, and this could badly break a shared-memory application which assumed otherwise. Cray had some architectures with 64-bit bytes, but simulated 8-bit bytes in userspace by using otherwise-unused high bits in a pointer to track which 8 of the 64 bits it was supposed to be pointing at. Applications using tagged pointers (such as emacs) had to be careful to preserve those bits. char was the only type that they handled specially; all of the other types including short were 64 bits. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Wed, Sep 05, 2007 at 12:46:00PM -0500, Rob Landley wrote:
> On Wednesday 05 September 2007 3:25:59 am Dave Dodge wrote:
> > Pretty much the only way it seems to allow using a
> > pointer/address to an object _anywhere_ in a constant expression is in
> > sizeof context, or when the final expression is an address
>
> A constant string is an address once the (dynamic) linker's done with it.
Yes, but it's only guaranteed to be a constant expression by the
Standard if the final expression produces an address. Things like
this are well-defined and portable
static char * foo = "bar";
static char * foo = "bar" + 1;
but your case is not, because your final expression produces an
integer.
> The c89 standard didn't insist that char be 8 bytes, either.
ITYM 8 bits, and neither does the C99 Standard.
> Any platform on which it wasn't was too broken to worry about.
For Linux certainly. My understanding is that there are current
architectures in the embedded market that use a 32-bit char, though.
> (If you're curious what I'm doing, it's my toybox project, main.c,
> line 61.)
I see the problem. This adds more ugliness, but like most things you
can fix it with another layer of abstraction:
USE_ECHO(NEWTOY(echo, OPT_STR("+en"), TOYFLAG_BIN))
USE_TOYSH(NEWTOY(exit, OPT_NONE, TOYFLAG_NOFORK))
And then make the trivial definitions alongside NEWTOY and OLDTOY:
#define OPT_STR(x) x
#define OPT_NONE NULL
and
#define OPT_STR(x) 1
#define OPT_NONE 0
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Look, Is this TCC's bug?
On Wed, Sep 05, 2007 at 01:32:17PM -0500, Rob Landley wrote:
> I don't own a copy of MSVC (or a copy of Windows, for that matter), but a
> Microsoft product being broken really doesn't come as a surprise...
They definitely don't support C99. Here's what they had to say about
it back in 2003:
http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_022703.aspx
Q: what, if anything, from C99 will we see in the future from VC
A: In general, we have seen little demand for many C99
features. Some features have more demand than others, and we will
consider them in future releases provided they are compatible with
C++. It is more likely we'll entertain C99 features if they are
picked up in the next version of the C++ standard.
Another thing of note is that Win64 is pretty much the only LLP64
system around (everybody else uses LP64). Even some Windows
developers seem to have done a WTF doubletake over that decision. MS
did this to avoid breaking the mountains of legacy code and data files
which assume long is 32 bits, which is apparently partly their own
fault thanks to a LONG typedef that they'd been supplying in their
headers. Microsoft blogger Raymond Chen tries to explain/defend the
pragmatic reasons behind the choice here:
http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Wed, Sep 05, 2007 at 02:33:58AM -0500, Rob Landley wrote: > On Wednesday 05 September 2007 1:02:03 am Dave Dodge wrote: > > > I fixed the "ptr || ptr" bit not working (check hg), and I just made it > > > stop warning me about "comparison between pointer and int" for && and ||, > > > but now it's saying "initializer element not constant". > > > > Well looking at 6.6, I'm having a hard time figuring out how to fit > > the above into one of the described forms of "constant expression". > It's a pointer to a constant string. It's in a read-only section of > memory. More to the point, the or is testing whether or not it's > nonzero, so the actual _value_ of the pointer goes away and all we > need to retain is that it wasn't NULL. I agree with all that; just saying the Standard doesn't explicitly permit it. Pretty much the only way it seems to allow using a pointer/address to an object _anywhere_ in a constant expression is in sizeof context, or when the final expression is an address (and then there are restrictions that are pretty obviously designed to make the address suitable for relocation). Even simply comparing a constant-valued pointer to null seems to put you in implementation-defined territory. > *shrug* GCC handles this just fine, that's why I was doing it. The > alternative is ugly and brittle #ifdefs instead of letting the optimizer > eliminate dead code naturally. Have not tried this, but maybe you could add another layer to trick tcc into taking it: (ptr != NULL) || (ptr != NULL) || ... || 0 Or even more hackish, _if_ you know that in this expression your strings are going to be given as string literals (not pointers) and have more or less characters than there are in the type produced by NULL, then: ((sizeof ptr) != (sizeof NULL)) -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fun little bug...
On Wed, Sep 05, 2007 at 01:04:23AM -0500, Rob Landley wrote: > On Wednesday 05 September 2007 12:30:42 am Dave Dodge wrote: > > All of the defined uses of > and < on pointers [...] > On Linux, on all platforms I'm aware of, it devolves into (long)a > > (long)b. Same here, and I'd add that long is large enough to hold a converted pointer, and that the address space is linear counting by 1, and that the conversion is a trivial bit-for-bit operation, and that a null pointer is all-bits-zero -- none of which is guaranteed by C, but as far as I know Linux doesn't run on the machines that do otherwise. > In any case, if there are cases where comparisons are allowed, and treating > the pointer value as a long works for all those cases, then worrying about > exactly what the undefined behavior would do if you pull out the same > comparison code in a case that _isn't_ allowed doesn't seem useful. It sort of depends on whether you're trying to make a strict C compiler, or one that allows all of the fudging that gcc does and handles it in the same way. I agree the latter is a lot more more useful when the goal is to be able to replace gcc for things like libc and kernel compilation. Aside: most commercial compilers also try to be gcc-compatible, though an interesting one is Intel's C compiler for IA64, which intentionally does not support inline assembly. > You worry way more about what the standards document says than I do. :) That comes from years of skimming comp.lang.c, where the Standard is law and implementations don't really matter :-) -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] More fun with comparison between pointer and integer...
On Wed, Sep 05, 2007 at 12:11:01AM -0500, Rob Landley wrote: > So in my toybox project (which I'm trying to build with tcc), I'm pulling a > dirty trick to do dead code elimination on gcc. Basically, I have macros > that boil down to: > > static const int blah = ptr || ptr || ptr || ptr || 0; > > with the various ptr entries being either a string constant or NULL. ... > I fixed the "ptr || ptr" bit not working (check hg), and I just made it stop > warning me about "comparison between pointer and int" for && and ||, but now > it's saying "initializer element not constant". Well looking at 6.6, I'm having a hard time figuring out how to fit the above into one of the described forms of "constant expression". It's the use of pointers at all that causes the problem; most of the ways of defining such expressions seem to be constrained to using only arithmetic types. I suspect your expression is falling into the gray area of "An implementation may accept other forms of constant expressions." -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fun little bug...
On Tue, Sep 04, 2007 at 11:29:46PM -0500, Rob Landley wrote: > and there's defined behavior for > and < too. You sure about that? All of the defined uses of > and < on pointers in 6.5.8 require the two pointers to point to the same actual object (or one past the same object in the case of an array). A null pointer doesn't satisfy those cases, and "In all other cases, the behavior is undefined". 6.5.9 has special wording allowing != and == to apply to null pointers. Interestingly, this means: NULL == NULL defined NULL <= NULL undefined Of course it's possible I'm missing wording elsewhere that makes null pointers work. As you say, the Standard can be difficult to work with. Just trying to support things like while(p) or (p && ...) where p is a pointer is tricky because: - They test if the expression p "compares equal with 0", - A pointer can only be compared with 0 if that 0 is a null pointer constant. - A 0 is only a null pointer constant if it's a constant integer expression. - I see nothing that _explicitly_ states that the _implicit_ 0 being compared against is a constant integer expression. Hmmm. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] how to generate intermediate code in tcc
On Tue, Jul 31, 2007 at 10:21:43PM -0700, Srinivasan Subha wrote: > Please let me know if intermediate code can be > generated in tcc. If you want x86 assembly code, then no. tcc's x86 generator emits object code directly from source, with no assembly phase. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How TCC handlse the scope
On Sat, Jun 23, 2007 at 12:48:01AM -0400, Rob Landley wrote: > > Actually, C assumes it takes all varargs and returns an int. int blah(...); > (see "man 3 va_arg".) > And C99 removes implicit declarations entirely; calling an undeclared function in C99 is a syntax error. And yes it's a bit weird that this is considered a _syntax_ error rather than something like a constraint violation, but that's how the Standard words it. > Way back when (before the Ansi C 89 standard) there were no function > prototypes, so every function was expected to do the above. This > works for a surprising number of things because on a 32-bit > platform, any pointer can be cast to an int and back so things that > return pointers work if you return ints. Basically there was a > register in which to expect the return value. Aside: in C89 you do have to be careful about mixing prototypes and non-prototypes, even on 32-bit platforms. I was once faced with some code that worked on SPARC/Solaris but broke bizarrely when compiled on m68k Domain/OS. The problem turned out to be a function that was defined with a prototype but was being called through an implicit declaration, and had a short in the middle of its parameter list. The caller (with no prototype) was promoting the short and passing it on the stack as four bytes; but the callee (with a prototype) was expecting an unpromoted two-byte short. This resulted in the callee getting very confused about not only the short argument but all of the arguments that came after it. It had "worked" on SPARC because the ABI there normally used fixed-size registers instead of stack space to pass arguments. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Parsing bug
On Mon, May 14, 2007 at 01:48:58AM -0400, Rob Landley wrote: > 1) The #include doesn't get parsed on Linux systems because the > #ifdef prevents everything until the #else from being looked at. Not so sure about that. Compiling this: #if 0 #include #endif fails with "stray '\' in program". From a quick glance at preprocess_skip() where it calls handle_stray(), there's a comment suggesting that this may be a known bug. My guess is that it's treating all backslashes between the #if/#endif pair as part of escape sequences, instead of handling C's special case tokenization of header names. I don't see any obvious code in there checking for an #include context, for example. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Isolated bug
On Sat, May 12, 2007 at 08:31:36PM +0200, Philippe Ribet wrote:
> I just succeed in isolating a tcc bug from a very large piece of software:
[...]
> printf("%d\n",INT64_C(0)>=(INT64_C(-2147483648)));
Invokes undefined behavior. According to 7.18.4p2, the argument to
INT64_C() must be an integer constant. Despite appearances,
-2147483648 is not an integer constant. C does not have negative
integer constants.
What -2147483648 _is_, is an integer constant expression applying the
unary negation operator to the integer constant 2147483648. If you're
trying to do this in real code, use something like this instead:
-INT64_C(2147483648)
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug Report (offset+cast)
On Fri, May 11, 2007 at 09:36:20PM -0400, Rob Landley wrote: > On Friday 11 May 2007 3:01 pm, Dave Dodge wrote: > > Aside: from a purely C standpoint the memcpy() solution isn't actually > > guaranteed to work either, thanks to C99's concept of padding bits. > > What are "padding bits"? For integer types other than unsigned char, C99 allows the representation to contain padding bits which do not contribute to the integer's value. Accessing an integer via a byte array gives you access to the entire representation, including the padding bits. Storing arbitrary data into padding bits (as with memcpy()) can lead to undefined behavior. An example in the Standard (in a footnote) is the case of an integer representation having a padding bit for a hardware parity check. If you fill the entire representation with random bits, you might end up with the parity bit flipped the wrong way, leading to a trap when you tried to use it as an integer. There are other unexpected things that can be true thanks to padding bits, such as sizeof(short) being larger than sizeof(int) even while range of short is smaller than the range of int. > I strongly suspect this isn't something Linux has to worry about... Right, I don't know of any hardware Linux runs on that uses padding bits. POSIX also constrains the implementation more tightly than plain C -- for example requiring that bytes be exactly 8 bits -- though I'm not sure it forbids padding bits in the basic types. There presumably are real devices that use padding bits, but they're probably special-purpose targets rather than CPUs. The C Standard has a lot of strange little corner cases in it that you almost never encounter in real life. I've heard the DSP world has some unusual ABIs with 32 or 64-bit bytes, and Cray had a CPU where 8-bit addressability was simulated in the runtime by using extra bits in the MSB of a pointer. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug Report (offset+cast)
On Fri, May 11, 2007 at 03:32:47PM -0400, David A. Wheeler wrote: > Dave Dodge: > > Well, the term "correctly" is a bit suspect. You can't convert an > > arbitrary char* to a short* and dereference it without risking > > undefined behavior, because among other things there's no guarantee > > that the pointed-to location will be aligned properly as a short. [...] > It'd be wiser to rewrite that code (e.g., as a memcpy to a short > which you KNOW it's aligned), since no matter what it's non-portable. Yeah that's probably how I'd do it. Aside: from a purely C standpoint the memcpy() solution isn't actually guaranteed to work either, thanks to C99's concept of padding bits. I don't know of any real hardware where it would actually break, though, and if such a system does exist it's almost certainly some weird DSP/ASIC where if you're writing code for it you already know about these issues. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug Report (offset+cast)
On Fri, May 11, 2007 at 11:31:28AM -0400, David A. Wheeler wrote:
> Gil Dabah:
> > > It seems you can't cast a pointer from a specified offset:
> > >
> > > char* s = "\x34\x34\x12";
> > > short word = *(short*)&s[1]; // <--buggy
> > > printf("%x", word);
> > >
> > > will print 34 instead of 1234 (on LE machine, of course).
>
> Confirmed, it's a bug in tcc.
>
> kf:
> > Happens here too. However,
> >
> > short word = *(short*)(s+1);
> > works as expected.
>
> Confirmed, that one works correctly.
Well, the term "correctly" is a bit suspect. You can't convert an
arbitrary char* to a short* and dereference it without risking
undefined behavior, because among other things there's no guarantee
that the pointed-to location will be aligned properly as a short.
That code on a Sparc (with any compiler) will almost certainly core
dump with a bus error. On IA64 (with gcc) it traps and emits an
"unaligned access..." message before continuing. x86 only lets you
get away with this sort of thing because of its loose alignment
behavior; other real-world systems are much less forgiving.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?
On Mon, May 07, 2007 at 05:33:51PM -0400, Rob Landley wrote:
> On Monday 07 May 2007 12:31 pm, David A. Wheeler wrote:
> I always mentally translated alloca() to something like (typecast)(char
> anonymous[size]). Does c99 allow you to do something like that in
> expressions? (I know it allows it in for loops...)
Probably the closest thing in C99 would be compound literals. These
can create modifiable anonymous objects, including arrays, on the fly:
foo((int[]){1,2,3});
But one of the constraints is that the type cannot be a variable
length array.
> > Interestingly, once alloca() is implemented, we can implement extensions
> > like non-constant-length automatic arrays. E.G., we could implement:
> > double f(int n) {
> > double x[n];
> >
> > }
> > by having the compiler detect that "n" is not constant and in such cases
> > generate code equivalent to:
> > double * const x = alloca(sizeof(double)*n);
>
> I'm still a touch unclear on what's wrong with going the other way instead,
> and emulating alloca() with an anonymous local char array...
Variable length arrays are only guaranteed to persist until the end of
the scope of the declaration. alloca() memory is apparently assumed
to persist until the function returns, regardless of the scope of its
creation.
You could of course implement variable-length arrays to persist until
the end of the function -- I don't think there's anything in the
standard that forbids it. But then you end up with an implementation
that probably can't handle things like:
for (i = 0;i < 10;i++) {
char a[whatever];
foo(a);
}
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Proposal for handling alloca(). Anyone see a problem with it?
On Mon, May 07, 2007 at 12:31:00PM -0400, David A. Wheeler wrote: > There are minor downsides. It's not QUITE as efficient as a > traditional alloca(), because you're fiddling with malloc() instead > of changing the stack pointer. If threading were introduced, these > alloca lists would need to be stored per-thread and malloc would > have to be thread-safe, which is doable though annoying. POSIX requires malloc() to be thread-safe, so in the presence of threads you'd be okay with this design once you had the per-thread lists worked out. There is however a more subtle issue: POSIX does not require malloc() to be async-signal-safe. So if alloca() invokes malloc(), that makes calling alloca() within a signal handler potentially undefined. Since alloca() is not a very well standardized function to begin with, I don't know if there is any code that expects that to work. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Implementation of ISO C99
On Sun, May 06, 2007 at 06:09:44PM -0400, Rob Landley wrote:
> Why doesn't it "#define begin {" and "#define end }" while it's at it?
>
> Is this really required by c99?
Yep. Section 7.9, and required in freestanding implementations. At
least it's easy to support. For a trickier situation, I don't think
tcc supports C99 alternate punctuators yet (section 6.4.6):
<: :> <% %> %: %:%:
Note that they have to retain these spellings under stringization, so
it's presumably more than just a quick tweak to the parsing code.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Patch: Permit certain pointer assignments (grischka-2005-09-25 case_7)
On Fri, May 04, 2007 at 09:12:01AM -0400, David A. Wheeler wrote:
> Dave Dodge:
> > In the same translation unit?
>
> Yes, in the same translation unit. I used gcc 4.1.1, no options,
> and it did NOT complain.
Strange; I still get the warning in 4.1.1. Here's what I'm compiling
(I put it in a function because a file-scope non-constant initializer
causes an error):
void foo(void)
{
struct _s1 { int a, b, c; } *p1 = 0;
struct _s2 { int a, b, c; } *p2 = p1;
}
> The C99 spec clearly says that they have to have the same name if
> they're in DIFFERENT translation units.. but it's not instantly
> obvious if there's a problem when they're in the SAME translation
> unit.
Best I can tell from 6.2.7p1 and 6.7.2.3p4, no two structure types are
ever compatible within the same translation unit. The compatibility
between translation units appears to be a special case.
Example 2 in 6.7.7 also mentions this situation:
After the declarations
typedef struct s1 { int x; } t1, *tp1;
typedef struct s2 { int x; } t2, *tp2;
type t1 and the type pointed to by tp1 are compatible. Type t1
is also compatible with type struct s1, but not compatible with
the types struct s2, t2, the type pointed to by tp2, or int.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Patch: Permit certain pointer assignments (grischka-2005-09-25 case_7)
On Thu, May 03, 2007 at 09:56:23AM -0400, David A. Wheeler wrote:
> In practice, given:
> struct _s1 { int a, b, c; } *p1 = NULL;
> gcc will accept the following assignment without even a warning:
> struct _s2 { int a, b, c; } *p2 = p1;
> (Notice that the struct tags are different, but no warning is given.)
In the same translation unit? Even old gcc 3.3.3 with no options complains:
warning: initialization from incompatible pointer type
It's a constraint violation, so the Standard requires a diagnostic for
it if it's visible to the compiler.
Aside: it's actually pretty important that the compiler complain about
this sort of thing. Some applications use struct encapsulation
entirely to get extra type-checking for basic types. For example say
you've got some code that's dealing with both byte offsets and block
offsets in a region of memory; both offsets are simple integers, but
if someone uses a byte offset where a block offset is expected (or
vice versa) it could lead to subtle and hard-to-debug failures. So
you can do something like this:
typedef struct _byteoffset { unsigned int x; } byteoffset_T;
typedef struct _blockoffset { unsigned int x; } blockoffset_T;
to effectively make two incompatible "unsigned int" types. Then a
function can explicitly request a byte offset:
void foo(byteoffset_T);
and the compiler will complain if someone screws up and passes a block
offset. Of course the hope is that the compiler will optimize away
the struct wrapper, so it ends up being just a compile-time check with
no impact on execution speed. As a real-world example, you can see
the Linux kernel using this technique in page.h for types such as
pgd_t and pmd_t.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Static variables (grischka5)
On Thu, May 03, 2007 at 12:45:50AM -0400, David A. Wheeler wrote: > I'd normally use a typedef; this would be HIDEOUS in normal code. > The only reason I did it this way was because I _was_ trying to > abuse the compiler. This is a test case, My mistake, actually. I'd glanced at the patch too quickly and it looked like this was being inserted into tcc.c itself. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Static variables (grischka5)
On Wed, May 02, 2007 at 08:32:13PM -0400, Rob Landley wrote: > it STILL looks like there's more parentheses there than are > strictly necessary... Yes, it can be simplified: void (*static_stub1(void (*p)(void))) (void) -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Static variables (grischka5)
On Wed, May 02, 2007 at 06:06:48PM -0400, Rob Landley wrote:
> On Wednesday 02 May 2007 4:54 pm, David A. Wheeler wrote:
> > void ((*static_stub1(void ((*p)(void (void))
> (I don't think I've ever declared a function that returns a function
> pointer before. Or seen it declared. So that's what it looks
> like?)
Yeah, that's pretty hardcore doing it all in one shot. This is one of
those cases where I'd probably resort to a typedef to keep the code a
bit cleaner, especially if the function type is being used in more
than one place:
typedef void (*voidfunc_T)(void);
voidfunc_T static_stub1(voidfunc_T p) ...
cdecl can also help; just remember to remove most of the identifiers:
cdecl> explain void ((*static_stub1(void ((*)(void (void))
declare static_stub1 as function (pointer to function (void)
returning void) returning pointer to function (void) returning void
> (How does anyone survive lisp?)
Lisp is much easier because it doesn't have things like left and right
precedence to deal with.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: Re: [Tinycc-devel] fib.c
On Fri, Mar 16, 2007 at 12:46:58PM -0700, Laszlo Hars wrote:
> Your code and this one relies on the "wrap-around at overflow" behavior
> of the compiler. I did not find it documented. Have I missed it?
C99 6.2.5 p9:
[...] A computation involving unsigned operands can never overflow,
because a result that cannot be represented by the resulting
unsigned integer type is reduced modulo the number that is one
greater than the largest value that can be represented by the
resulting type.
Note however that the overflow semantics for signed integer types are
undefined. In fact integer overflow is what the Standard uses as its
example of undefined behavior in the definition of terms section.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] fib.c
On Thu, Mar 15, 2007 at 04:38:07PM -0700, Laszlo Hars wrote:
> If you want to demonstrate recursive calls, here is an alternative,
> which saves already computed results, and so the number of recursive
> calls is never more than n:
Aside: if you don't need the cached values for later runs of fib(n),
or you want to avoid static data for thread-safety, you can do even
better. Here's an O(n) recursive technique with no value cache. Also
note that it uses tail recursion, so it can be compiled (if the
compiler recognizes it) to run to any n with only one stack frame:
static unsigned long long fibstep(
unsigned int const remaining,
unsigned long long const prev,
unsigned long long const prevprev)
{
unsigned long long const fibnext = prev + prevprev;
if (fibnext < prev)
return 0; /* overflow */
if (remaining == 0)
return fibnext;
else
return fibstep(remaining - 1,fibnext,prev);
}
unsigned long long fib(unsigned int const n)
{
switch (n)
{
case 0: return 0;
case 1: return 1;
default: return fibstep(n - 2,1,0);
}
}
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] struct initializer bug
I have some recent code that uses a lot of elaborate initializers, and
more than one file triggered this error. It says "field expected" for
the line containing the .v initializer in the second structure,
perhaps as if it doesn't think that the .p initializer is finished. I
only briefly glanced at the compiler and it looks like it's got to be
in decl_designator() since that's the only function that produces this
error message. Minor changes, such as removing the "y" field from
struct point, or removing the ".v" initializer, make the error go
away.
-Dave Dodge
struct point{
int x,y;
};
struct obj{
struct point p;
int v;
};
void foo(void)
{
/* this works */
struct obj zz1 = {
.p = (struct point){ .x = 0 },
.v = 0
};
/* this does not */
struct point p = { .x = 0 };
struct obj zz2 = {
.p = p,
.v = 0
}
}
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Re: Wandering through Dave Dodge's tcc patches...
On Thu, Feb 22, 2007 at 04:06:55PM -0500, Rob Landley wrote:
> but on the function parameters patch, I can't reproduce the failure
> in my tree. The patch isn't applied, but possibly it was already
> fixed somewhere else?
It's apparently been fixed. This fails to compile with tcc 0.9.21:
extern int foo(int);
int foo(int const x) { return x; }
but works fine with more recent versions. Fabrice's changelog for
0.9.22 mentions:
"ignore 'const' and 'volatile' in function prototypes"
which I assume solved the problem.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] what are tcc's limitations?
On Fri, Oct 13, 2006 at 09:16:06PM +0200, Bernhard Fischer wrote:
> 3) tcc is a C89 compiler, for the most part. Anyone who thinks he's able
> to compile e.g. the kernel or other SW that peruses certain C99 features
> is likely to be surprised.
The kernel isn't the best example, because Fabrice did get kernel
compilation working for his tccboot project:
http://fabrice.bellard.free.fr/tcc/tccboot.html
Admittedly that's kernel 2.4.26 with some patches to bypass a few code
features that tcc doesn't handle.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] what are tcc's limitations?
On Sun, Oct 15, 2006 at 02:02:57AM +0800, bj wrote:
> i didn't understand what you meant by these statements:
>
> > Nobody wants to use GCC with -O0 instead of -O2, but this is what you get
> > from TinyCC
> >
> > When GCC is a good human translator, TinyCC is babelfish.altavista.com
gcc with -O2 performs lots of optimizations before it produces the
object code. Statements can be reordered, functions may be
automatically inlined or converted to jumps, loops may be unwound,
dead code may be removed, etc. Pretty much anything is allowed so
long as the program still produces the same output and side effects.
If you try to use a debugger on a highly-optimized program from gcc,
you may find for example that your local variables no longer exist.
tinycc is more like babelfish or gcc -O0 in that it does a nearly
word-for-word translation of C code to object code. Each C construct
is converted directly to object code as it's encountered. It's doing
a literal translation as opposed to gcc -O2's subjective or
paraphrased translation.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling qemu-0.8.2 with tcc (yes, I am insane).
On Thu, Oct 12, 2006 at 04:35:31PM -0400, Rob Landley wrote: > I just don't see why what machine you're running the compiler on is > any of the compiler's business. It should only care what machine > it's producing target binaries for. I agree that in an ideal situation all of the backends would be built-in and selectable at runtime. There's no real technical reason why this shouldn't be possible. > > There's also minor variations in the > > architecture support itself, for example the Win64 ABI is LLP64 on > > x86_64 instead of the LP64 design that everyone else uses. > > And you have a code generator backend. Currently specified by the > name of the compiler binary you're running, but "-m arch" would work > too. There's still some slightly tricky bits, because -m has some interactions/dependencies on the compiler's header files and the -I and -m options are therefore not completely independent. In the particular case of Win64 vs. 64-bit Linux on the same target machine, compiler-related values such as ULONG_MAX would be different. Perhaps more complicated than it's worth, is the idea that the compiler header contents can be built into the compiler and generated internally at runtime based on the architecture selection. C doesn't actually require there to be disk files for things like "limits.h" -- it just says that the directive "#include " causes certain things to become visible to the translator somehow. > Sane defaults remain a good thing, so you'd probably want some kind > of "-nostdcrap" argument at the start of that... Yes, and you want to be sure it's truly independent of the host environment. As you're probably aware, in the past it's been notoriously difficult to configure a GNU toolchain to be 100% divorced from the host environment. For example if you want to cross-link against uclibc while running on a glibc system with the same target hardware, I think the only reliable way to do it is by chrooting into a uclibc host environment. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling qemu-0.8.2 with tcc (yes, I am insane).
On Thu, Oct 12, 2006 at 05:11:50PM -0400, Rob Landley wrote:
> I also have a patch to fix initializing a 10 byte floating point
> constant in a 12 byte storage space that leaves 2 bytes of
> uninitialized random data that gets written into binaries. Although
> by "patch" I mean "perl script david wheeler wrote to run against
> the source code": http://www.dwheeler.com/trusting-trust/
BTW independent of David's work, someone else did a little patch for
this same issue a few months ago:
http://www.mail-archive.com/tinycc-devel@nongnu.org/msg00421.html
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling qemu-0.8.2 with tcc (yes, I am insane).
On Mon, Oct 09, 2006 at 12:39:12AM -0400, Rob Landley wrote: > I don't see how this is significantly different from a docbook to > pdf converter. Well, it's about a 1000 times easier to install than anything to do with docbook :-). I've been known to edit software packages to remove dependencies on docbook because it's such a nightmare to get the blasted thing in place. And don't even get me started on docbook-related processing tools that assume they'll have network access at runtime. ...sorry about that, any mention of the "d" word tends to get me ranting. > It sounds like you made it run on x86-64, from which it can > presumably produce binaries for x86, arm, and whatever the heck c67 > is? As much as I love the idea of a trivial cross-compiler, there are some gotchas. For example it has to be sure to use header files that match the target machine's libraries. There's also minor variations in the architecture support itself, for example the Win64 ABI is LLP64 on x86_64 instead of the LP64 design that everyone else uses. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Merging patches...
On Sun, Oct 08, 2006 at 12:32:39AM -0400, Rob Landley wrote:
> I'm also currently squinting at:
> http://www.dododge.net/tcc/patches.html
> I'm still slightly fuzzy on the exact problem it's solving though,
> and avoid use of "const" in my own programs anyway.)
I use "const" pretty much anywhere I can. My code is littered with it.
As to the tcc problem: I'll have a header file with a prototype for a
function that specifies parameter types but no parameter names:
extern void foo(int,const char *);
I usually consider it bad style for a function to modify its
parameters (remember, I'm a const freak), so when I implement the
function and add the parameter names I mark them const. This tells
the compiler that for optimization purposes it can assume the
parameter values will not change within the function, and that if I do
inadvertantly try to change them, it should tell me:
void foo(int const a,const char * const s)
{
/* If I try to do "a=0" or "s++" in here the compiler should complain */
}
The file that implements the function will include the header with the
prototype. This is so that the compiler can tell me if I've screwed
up and the declaration doesn't match the definition.
The problem with tcc is that it thinks the above prototype doesn't
match the above definition, and it incorrectly flags a mismatch
between the header and the implementation. C says that the constness
of the parameter is supposed to be ignored when comparing function
signatures, but tcc doesn't take that into account.
> whether the first patch in that list is sufficient considering
> is_compatible_types() can recurse when looking at a pointer but the
> flag to ignore "const" gets stripped off by the wrapper function so
> it only applies at the top level...
The N869 wording referenced in the patch talks about the qualifiers on
the parameter type, and I think that means that ignoring only the
top-layer const is sufficient.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Basic questions about *implementation details* of tinycc please....
On Fri, Sep 29, 2006 at 10:42:52AM -0700, [EMAIL PROTECTED] wrote:
> Can you please point me to some web pages describing at a high level
> the architecture of tinycc??
Look at chapter 8 of this document:
http://fabrice.bellard.free.fr/tcc/tcc-doc.html
> Was tinycc's way of creating a C compilers easier or harder
> than using an abstract syntax tree?
It started out as an entry for the Obfuscated C Contest and grew from
that into a full C compiler:
http://fabrice.bellard.free.fr/otcc/
Its goals include being very small and very fast. As a result it
doesn't always follow normal compiler design principles. If you're
trying to study how a _typical_ compiler is designed, tcc may not be
the best choice.
On the other hand its small size and simple design means that it's
much easier to examine at the code level than a typical compiler. For
example the bulk of it is a single .c file that you can easily edit
and experiment with.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compound Literals
On Tue, Sep 26, 2006 at 12:33:28AM -0400, Andrew Johnson wrote:
> struct point { int X; int Y; } *test = &((struct point){1, 1});
>
> Is this a bug in compound literals support, or does tcc currently
> not support them at all?
I'm guessing you're defining them outside a function. It seems to
have a problem with that. It does appear to support them within
functions, with or without designated initializers. For example:
extern void foo(struct point *);
void bar(void)
{
struct point * pp = &((struct point){1,1});
foo(pp);
foo(&((struct point){1,1}));
foo(&((struct point){.X=1,.Y=1}));
}
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC on new ARM EABI (ARMEL)
On Sun, Sep 17, 2006 at 10:45:06PM -0500, Cayle Graumann wrote:
> On 9/17/06, Daniel Glöckner <[EMAIL PROTECTED]> wrote:
>Adding the extra set of parentheses in the define was the solution I
> came up with to get it to compile also. The real question is why does GCC
> allow it?
Because the grammar makes it unambiguous. The parentheses are not
supposed to be needed:
sizeof (x)/sizeof (x)[0]
The [0] can only be applied to a postfix-expression. None of these is
a postfix-expression:
sizeof (x)/sizeof (x)multiplicative-expression
(x)/sizeof (x)multiplicative-expression
sizeof (x)unary-expression
The only way it parses is:
(x)primary-expression
^^^[0] postfix-expression
sizeof ^^ unary-expression
(x) primary-expression
sizeof ^^^ unary-expression
^^/^ multiplicative-expression
Which is what the code intends.
> >But then we can go further and ask if "sizeof (char)7" is a legal C
> >expression...
No, that's always an error. For example:
char type-name
()7cast-expression
sizeof ^^^error: sizeof can't be applied to a cast-expression
or
char type-name
sizeof () unary-expression
^7error: unary-expression followed by constant
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
On Wed, Sep 13, 2006 at 01:10:13PM +0200, Guillaume POIRIER wrote: > Can't Opteron natively scale up to 8 sockets (so 16 core with > dual-code) natively? > Can't Opteon address already enough RAM for all realistic workloads? SGI for example has hardware today that goes up to 512 IA-64 sockets and I think 128 terabytes of RAM in a single machine. That's one computer booting one copy of Linux. If you need more, they can build clusters of these with multiple 10 gigabit/sec interconnects between them. The costs of course are insane -- high-end IA-64 is something like $10K per cpu just for the chip, and you don't even want to think about RAM prices since you have to use the highest-capacity sticks to reach thoses sizes. But people do build them. > The only shortcoming I see with Operon (right now) is the size of its > cache, not the size of the addressable memory nor the number of > core... > > ... or am I missing smth? I guess the real problem is that nobody's selling the boards to hold them right now (please prove me wrong!). One really nice feature of SGI's stuff is that it's all modular. If you find that you need more cores, or more RAM, or more PCI slots: you buy another 2U box, cable it into the rack, and reboot. The system doesn't need to share a single physical case/backplane/board for it to behave as a single machine. I think you can recently finally get an Opteron system at the same size as the "small" Itanium machine we were able to buy two years ago, and I expect to be at least testing on such hardware within a year. It's only a matter of time before someone does build Opteron machines much bigger and for a lot less money than an IA-64 equivalent. I'd love for SGI to start producing Altix-style bricks with Opterons in them but I don't really hold out hope for that. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
On Tue, Sep 12, 2006 at 11:46:45AM -0400, Rob Landley wrote: > Translation: Itanic sucks so badly that it takes a near-miraculous > compiler to get even reasonable performance out of it, although we > try to phrase it to seem like it's the compiler's fault. Oh I'm not making any excuses for IA-64. It comes to mind only because I have to deal with it on a regular basis and most people have no idea just how bizarre the IA-64 world is at the assembly level. I'd love to have things like tcc working there but I'm not masochistic enough to try porting it myself. > There's plenty of hardware out there that can get better performance > out of fewer transistors, fewer watts, and without requiring an > NP-complete (or AI-complete) optimizer to hide its most obvious > shortcomings. The problem is that for the workloads where IA-64 is king, there's things like huge core counts and RAM sizes that the other hardware can't easily reach yet. If AMD can get Opteron scaled up to those levels, though, it'll probably be the final nail in Itanium's coffin. Much of my IA-64 stuff is also designed to be buildable on x86_64, in anticipation of that day. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] (no subject)
On Fri, Sep 08, 2006 at 03:00:50PM +0200, Johannes Klarenbeek wrote:
> that depends on how you look at the way you write code... just to
> expect that a compiler does a better way optimizing stuff than a good
> programmer would, is a wrong assumption.
You have to take into account how forgiving the target architecture is
to the instruction ordering. If the system is able to reorder and
reschedule work internally, then clean code with a non-optimizing
compiler can probably get fast results.
On the other hand you have platforms like IA-64, where in theory a
good compiler can get much better results than a bad compiler no
matter how good the incoming code is. This sort of architecture
requires the compiler to explicitly reorder, bundle, group, and
schedule instructions ahead of time to hit the functional units on the
chip in the best way. I think compiler design for IA-64 is an active
research area at several universities.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problem while compiling tcc
On Fri, Jul 28, 2006 at 12:51:15PM +0200, Guillaume R. wrote:
> tcctest.c:1920: warning: integer constant is too large for ‘long’ type
What version of tcc are you compiling? The only integer constant on
line 1920 in version 0.9.23 is 3, which doesn't really fit the error
message.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How Install TCC on Ubuntu Linux
On Wed, Jul 26, 2006 at 02:42:14PM +0530, Sumesh KS wrote:
> But i have n't any internet connection. but i download tcc from it's site. i
> read the install help file in that file and i type the commands . But it
> give an error message like "No Compiler found". I downloades the source
> version so that package it show i want a C compiler like GCC.
Yes if you have the sourcecode for tcc, you will need another compiler
such as gcc in order to install tcc.
> How i Get C compiler for Ubuntu
If you cannot get an Internet connection for the machine, you'll have
to download the .deb files manually for the packages you want. I
think some Ubuntu package files can be found here:
http://archive.ubuntu.com/ubuntu/pool/
Sorry, I do not know the correct procedure for downloading them and
installing them offline.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] once again about anonymous struct/union bug
On Thu, Jul 13, 2006 at 05:19:57PM -0400, Ben Hinkle wrote:
> On 7/11/06, PerfectDark <[EMAIL PROTECTED]> wrote:
> >//
> >typedef struct {
> >int any_member;
> >;// just placeholder -
> >// we can put semicolon in almost each place of code :)
> >} my_struct_t;
> >//
>
> What section of the ISO_C99 spec says that?
In C99 the above code is a syntax error. The grammar (Annex A.2.2)
does not allow a "placeholder" semicolon in a struct-declaration-list
by itself.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug
On Tue, Jul 18, 2006 at 02:45:05PM +0530, Sumesh KS wrote:
> Thanks for Information,
> I'm getting an Error message like "C compliler is not found it searching C
> compiler like GCC" (This message is short).
> Please Help me. My Ubuntu Ver. 6.10.
Make sure you have the "build-essential" package installed for Ubuntu
first.
To configure tcc you'll need to have a C compiler (such as gcc) and
various other development tools already installed on the machine.
Ubuntu does not normally come with any development tools preloaded.
The build-essential package is a quick way to get a minimal toolchain
in place, and is probably sufficient to get tcc working.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] function call crash, 64bit?
On Tue, Jul 11, 2006 at 11:13:51PM -0700, Carl Dougan wrote:
> Does tcc have problems with 64bit?
If you're trying to use it within a 64-bit application, then that
probably would be trouble. I think it only understands the 32-bit
ABI.
> with win+64bit+gcc?
An additional issue with Windows 64-bit code is that Windows uses the
LLP64 model, while all of the 64-bit Unix-like systems use LP64. I
don't know if this is causing trouble for you, but it's something to
keep in mind.
> Im not even sure if the 64bit patch above is trying to
> solve the problem I have or if thats more a linux
> deal.
Glancing at the 64-bit patch, it looks like it's just making it
possible to compile tcc (in 32-bit mode) on a 64-bit Linux machine.
If you have some way of using a debugger to disassemble a running
program, you could try something like this: write a function that you
compile into the program, and then use libtcc to compile the same code
on the fly. Then examine the object code for both functions and see
if they look like they're using registers and the stack the same way.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] parameter declarations and long doubles
On Thu, Jun 08, 2006 at 08:36:11AM -0700, Jim Cook wrote: > Is there an online reference for 6.5.2.2, et al.? I don't have a dead-tree > version handy and would be more than happy to research such things myself > before posting questions. As someone mentioned, N1124 is the best online one. N869 is also available and comes in a plaintext version that may be easier to browse in a text editor, but a downside to N869 is that it's a pre-C99 draft and doesn't exactly match the final standard. N1124 is based on the final C99 document so it should be more accurate. If you need the official (non-draft) versions for some reason, you can purchase them from ANSI or ISO. > Do you have an online reference for the right printf arguments? In N1124 it's in section 7.19.6.1. It states that "L" is used for printing a long double, and that "l" has no effect on "f". > >Also, keep in mind that the actual implementation of "printf" is > >provided by the system's C library, not tcc. > > This answer gave me pause for a while until I realized you meant that when > the TCC binary was compiled, it was _that_ compiler that is responsible. More likely I just don't know enough about how tcc is packaged for Windows. In the Unix world the C compiler and the C library are separated. The compiler doesn't normally provide header files or code for functions such as fprintf and malloc; it assumes you have a C library package installed that will supply them. On Linux the library package is usually glibc or uClibc. On a commercial Unix system it would be provided by the vendor (Sun, Apple, HP, etc). The Unix C library has to implement a lot of very system-specific things, such as the arguments for the ioctl() function, and it's traditionally been easier to let the vendor deal with that stuff. > Windows binary distribution > <http://laurenssimonis.com/tcc/tcc-0.9.23.zip>maintained by Laurens > Simonis. Okay, it looks like he's taken tcc and bundled it with some other things to make it usable on Windows. The header files for example come from the MinGW package. > It appears that using either %lf or %Lf has the same result when passed a > long double. I think what's happening is that tcc (and MinGW) link your program with "msvcrt.dll", which is Microsoft's Visual C++ C runtime library. You end up with Microsoft's implementation of printf. A problem you're going to run into is that Microsoft's C library does not conform to the C standard: http://www.mingw.org/MinGWiki/index.php/C99 Here's what Microsoft had to say about C99 conformance back in 2003: http://msdn.microsoft.com/chats/transcripts/vstudio/vstudio_022703.aspx "In general, we have seen little demand for many C99 features. Some features have more demand than others, and we will consider them in future releases provided they are compatible with C++. It is more likely we'll entertain C99 features if they are picked up in the next version of the C++ standard." > I also happen to know that in the compilers from them, long double > and double are not different, so perhaps that's part of the > strangeness. Right, tcc is linking your code against the same version of printf that those compilers use. According to the MinGW documentation, that printf doesn't actually support long doubles at all: http://www.mingw.org/MinGWiki/index.php/long%20double -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] parameter declarations and long doubles
On Wed, Jun 07, 2006 at 05:22:40PM -0700, Jim Cook wrote:
> I'm using -Wall -Werror, in case that helps, and using the Windows binary
> port.
tcc's error checking is not as rigorous as it could be. For example
gcc 4.1.1 gives several warnings:
$ gcc -g -O3 -std=c99 -pedantic -Wall -Wextra foo.c
foo.c: In function 'main':
foo.c:19: warning: format '%lf' expects type 'double', but argument 2 has
type 'long double'
foo.c:22: warning: large integer implicitly truncated to unsigned type
foo.c:14: warning: unused parameter 'argc'
foo.c:14: warning: unused parameter 'argv'
foo.c:21: warning: large integer implicitly truncated to unsigned type
> static void test1(n)
> unsigned char n;
> {
>printf("n is %u. n is < 2? %u\n", n, n < 2);
> }
[...]
>test1(257);
The function is passed the value 257, with type int. That much we can
say for sure.
The question is what happens to that value when the parameter type
cannot represent it. The rules for functions with prototypes (such as
test2) are clear, and the value would be converted to an unsigned char
"as if by assignment", producing (on x86) the value 1. Looking at the
Standard, I can't seem to get a clear reading of what happens for a
function without a prototype, though.
For example 6.5.2.2 suggests that the call is okay, because the
promoted argument type (int) is compatible with the promoted parameter
type (which would also be int). But then it seems to say that no
implicit conversion is performed to the parameter type unless a
prototype is present.
Meanwhile 6.9.1 says that arguments are converted to parameter types
as if by assignment, and it _doesn't_ qualify that to only apply to
prototyped functions.
As far as what tcc implements, if you cast n to an unsigned int before
passing it to printf, it prints 257. If the function call is
considered undefined, then this bizarre behavior is allowed; otherwise
it's a tcc bug. gcc does produce different results, but that doesn't
really prove anything.
My guess is that it _is_ a tcc bug. The best and easist workaround is
to never use old-style function definitions in the first place. It's
been 17 years since prototypes were standardized, after all.
>long double ld = 3.14;
[...]
>printf("%lf\n", ld);
For long double you should use %Lf, not %lf. Also, keep in mind that
the actual implementation of "printf" is provided by the system's C
library, not tcc.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] External core functions
On Wed, May 31, 2006 at 09:43:05AM +0100, Sitting Duck wrote:
> TCC uses external core functions for bound-checking, and for
> memcpy etc. Where are the implementations of these functions?
I think they're in "bcheck.c".
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Re: Config.h
On Thu, May 25, 2006 at 11:50:04AM +0100, Joshua Phillips wrote: > I still can't find anything about config.h. It's generated by the "configure" script. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] C++ or C?
On Mon, May 22, 2006 at 02:55:50PM -0400, ice wrote:
> Didn't early C++ compilers just translate the code to C?
Yes, "cfront" was the original one:
http://en.wikipedia.org/wiki/Cfront
According to the Wikipedia article, C++ exception support turned out
to be so difficult to translate that cfront was abandoned.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Getting latest tcc
On Fri, May 19, 2006 at 07:30:30PM +0200, [EMAIL PROTECTED] wrote:
> IMHO the whole development model of projects initiated by Fabrice
> Bellard is not exactly what you'd call FLOSS state of the art :/
He does respond on the list sometimes, but it's indeed pretty rare
that he incorporates a patch into upstream. I've just gone ahead and
put together a list of the patches I know about:
http://www.dododge.net/tcc/patches.html
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Bug? At least error when compiling SQLite
On Wed, May 17, 2006 at 09:06:45AM +0200, Laurens Simonis wrote:
> typedef PVOID PACCESS_TOKEN;
> typedef struct _SE_IMPERSONATION_STATE {
> PACCESS_TOKEN Token;
> BOOLEAN CopyOnOpen;
> BOOLEAN EffectiveOnly;
> SECURITY_IMPERSONATION_LEVEL Level;
> } SE_IMPERSONATION_STATE,*PSE_IMPERSONATION_STATE;
>
> esp. regarding PACCESS_TOKEN Token; :
>
> In file included from ..\include\winapi/windows.h:105:
> In file included from ..\include\winapi/windef.h:155:
> ..\include\winapi/winnt.h:1808: identifier expected
>
> When I replace PACCESS_TOKEN Token; with void PACCESS_TOKEN Token;,
> everything compiles just fine.
Try this patch:
http://lists.gnu.org/archive/html/tinycc-devel/2005-01/msg00010.html
It doesn't look like the exact same problem, but it's possible that
it's just a different effect from the same bug. Or it might be that
PVOID is not being defined properly when tcc is used as the compiler.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TCC bug wilt long long
On Tue, May 02, 2006 at 11:10:28PM +0200, Benoit DUPONT-DE-DINECHIN wrote:
> Reproduce using the C file supplied:
>
> gcc BugTCC.c && ./a.out > OK
> tcc BugTCC.c && ./a.out > KO
> diff OK KO
I think the following patch will fix it:
------
20060503 Dave Dodge <[EMAIL PROTECTED]>
When a long long value is used as test expression, for example as the
controlling expression for an "if" or "while" statement, the tcc i386
backend does not actually test the upper 32 bits. This program
demonstrates the bug:
#include
int main(void)
{
unsigned long long x = 0xULL;
printf("x=%llx\n",x);
if(x != 0) printf("x!=0 true\n"); else printf("x!=0 false\n");
if(x) printf("x true\n"); else printf("x false\n");
printf("x!=0 %s\n",(x != 0) ? "true" : "false");
printf("x %s\n",x ? "true" : "false");
return 0;
}
The problem is that a statement such as "if(x)" ends up in the gtst()
function in i386-gen.c, which fetches the x value and then emits a
test instruction that assumes it's a 32-bit int. A simple, but
probably not optimal, fix is to treat a long long test the same way as
a floating point test, by inserting an explicit comparison != 0 to
produce a testable 32-bit integer.
Index: tcc-0.9.23/i386-gen.c
===
--- tcc-0.9.23.orig/i386-gen.c 2005-06-17 18:09:15.0 -0400
+++ tcc-0.9.23/i386-gen.c 2006-05-03 20:39:31.0 -0400
@@ -585,7 +585,8 @@
gsym(vtop->c.i);
}
} else {
-if (is_float(vtop->type.t)) {
+if (is_float(vtop->type.t) || is_llong(vtop->type.t)) {
+/* compare != 0 to get a 32-bit int for testing */
vpushi(0);
gen_op(TOK_NE);
}
Index: tcc-0.9.23/tcc.c
===
--- tcc-0.9.23.orig/tcc.c 2005-06-17 18:09:15.0 -0400
+++ tcc-0.9.23/tcc.c2006-05-03 20:37:54.0 -0400
@@ -883,6 +883,14 @@
return bt == VT_LDOUBLE || bt == VT_DOUBLE || bt == VT_FLOAT;
}
+/* true if long long type */
+static inline int is_llong(int t)
+{
+int bt;
+bt = t & VT_BTYPE;
+return bt == VT_LLONG;
+}
+
#ifdef TCC_TARGET_I386
#include "i386-gen.c"
#endif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[PATCH] pp-number pasting fix (was: Re: [Tinycc-devel] Preprocessor bug)
On Thu, Apr 27, 2006 at 12:00:42AM -0700, Jun Inoue wrote:
> I can't figure out how to stop the compilation after the
> preprocessing phase in tcc.
I don't think that's implemented.
> This behavior is consistently repeatable with tcc version 0.9.23 on
> Debian GNU/Linux sid (unstable) running on a Pentium M. I tried both
> Debian's binary package and the tarball put up at tinycc.org.
The patch below will probably fix it.
-------
20060428 Dave Dodge <[EMAIL PROTECTED]>
There's a bug in the macro_twosharps() function, where a pp-number is
not created properly when multiple token pastings are involved. The
sample code below from [EMAIL PROTECTED] demonstrates the problem;
FLAGS(0) should evaluate to 0 but ends up evaluating to 1:
#define SQUISH(n) (!!((n) & 0xF))
#define HEX2BIN(n) (SQUISH(n))
#define FLAGS(f) HEX2BIN(0x##f##U)
int main () { return FLAGS(0); }
What happens internally is that the first pasting of "0x"+"0" creates
the pp-number "0x0". The buffer containing that result is then used
directly as the current token string. When the second pasting begins,
the buffer is reset, destroying the current token string before the
pasting operation. So instead of pasting "0x0"+"U", it ends up with
""+"U".
A solution is to use a different buffer to hold the current token
contents, so that concatenation won't damage it. The global tokcstr
is normally used alongside tok and tokc when parsing, so I just used
that.
Index: tcc-0.9.23/tcc.c
===
--- tcc-0.9.23.orig/tcc.c 2006-04-28 03:40:30.0 -0400
+++ tcc-0.9.23/tcc.c2006-04-28 03:43:41.0 -0400
@@ -4214,9 +4214,14 @@
(t >= TOK_IDENT || t == TOK_PPNUM)) {
if (tok == TOK_PPNUM) {
/* if number, then create a number token */
-/* NOTE: no need to allocate because
- tok_str_add2() does it */
-tokc.cstr = &cstr;
+/* NOTE: we cannot use cstr directly for this
+ because if there are multiple token pastings
+ in a sequence the concatenation will reset
+ cstr before the final token is ready. */
+cstr_reset(&tokcstr);
+cstr_cat(&tokcstr, cstr.data);
+cstr_ccat(&tokcstr, '\0');
+tokc.cstr = &tokcstr;
} else {
/* if identifier, we must do a test to
validate we have a correct identifier */
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problems compiling with Glibc 2.4.4 (FC5)
On Thu, Apr 20, 2006 at 02:04:09AM +0200, Axel Liljencrantz wrote: > On 4/19/06, Dave Dodge <[EMAIL PROTECTED]> wrote: > > - Run "gcc -E" on the same piece of code in order to see what the > > preprocessing is doing. > pthread_mutexattr_t is only mentioned once, and everything looks sane. You could try compiling the output from gcc -E using tcc and see if it still exhibits the problem. If tcc doesn't complain, then that would indicate that tcc's preprocessing is doing something "different" from gcc's. If tcc does still complain, then at least you've now got a completely self-contained test case that you can play with (for example change the pthread_mutexattr_t to some other identifier and see if it still breaks; move the typedef to somewhere else in the file and see if the error follows it; etc). -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Problems compiling with Glibc 2.4.4 (FC5)
On Wed, Apr 19, 2006 at 05:51:04PM +0200, Axel Liljencrantz wrote:
> /usr/include/bits/pthreadtypes.h:69: identifier expected
> 65: typedef union
> 66: {
> 67: char __size[__SIZEOF_PTHREAD_MUTEXATTR_T];
> 68: long int __align;
> 69: } pthread_mutexattr_t;
A quick guess would be that the identifier pthread_mutexattr_t is
being used somewhere else for some other purpose and is confusing tcc.
Things to try:
- Run "gcc -E" on the same piece of code in order to see what the
preprocessing is doing. This might not be exactly the same as
what tcc does, but you should be able to find the above bit of
code in the output and at least make sure that 1) it still looks
sensible; and 2) pthread_mutexattr_t hasn't been defined earlier.
- Search through /usr/include for pthread_mutexattr_t to see if any
other files define it. The closest I've got to FC5 is a RHEL 4
system, and it has two different versions of pthreadtypes.h with
conflicting typedefs (depending on which threading implementation
you're using, I think).
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] struct member/typedefs share namespace?
On Tue, Apr 18, 2006 at 06:30:44PM -0400, Toby Thain wrote:
> On 18-Apr-06, at 5:12 PM, Dave Dodge wrote:
> >The patch below from January 2005 probably fixes it as well.
>
> Looks like it, thanks.
>
> Just curious, will that reach the mainline?
I've no idea. There's several little bugfixes of this sort that have
been posted over the past year or two, but don't know if Fabrice has
incorporated any of them.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] struct member/typedefs share namespace?
On Tue, Apr 18, 2006 at 10:00:54AM -0400, Toby Thain wrote:
> But then maybe my fix wasn't exactly the same as your workaround.
> Starting from version 0.9.22 (Gentoo ebuild), at line 6639 (!) of
> tcc.c, in parse_btype() after the default: label, I changed
> if(typespec_found)
> to
> if(type_found||typespec_found)
The patch below from January 2005 probably fixes it as well.
-Dave Dodge
-
tcc 0.9.22 doesn't properly handle the following construct:
typedef [...] a;
typedef [...] b;
[...] foo([...])
{
a b; /* not parsed correctly */
}
The problem is that it parses both "a" and "b" as typedef names, and
does nothing as a result. Although the C99 grammar allows this
parsing, there is a constraint in the narrative that invalidates it
and requires "b" to be treated as a declarator. This patch causes tcc
to stop looking for typedef names in a declaration specifier list
after it finds the first one; the end result should be that "b"
becomes a local variable and hides the "b" typedef while in scope.
--- tcc-0.9.22/tcc.c2004-11-08 15:47:16.0 -0500
+++ tcc-0.9.22-patched/tcc.c2005-01-24 23:08:04.0 -0500
@@ -6497,13 +6497,14 @@
*/
static int parse_btype(CType *type, AttributeDef *ad)
{
-int t, u, type_found, typespec_found;
+int t, u, type_found, typespec_found, typedef_found;
Sym *s;
CType type1;
memset(ad, 0, sizeof(AttributeDef));
type_found = 0;
typespec_found = 0;
+typedef_found = 0;
t = 0;
while(1) {
switch(tok) {
@@ -6638,9 +6639,15 @@
default:
if (typespec_found)
goto the_end;
+if (typedef_found)
+/* we've already found a typedef-name in the declaration */
+/* specifier list, so ignore any further ones and treat */
+/* them as plain identifiers */
+goto the_end;
s = sym_find(tok);
if (!s || !(s->type.t & VT_TYPEDEF))
goto the_end;
+typedef_found = 1;
t |= (s->type.t & ~VT_TYPEDEF);
type->ref = s->type.ref;
next();
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] going nuts trying to get / generate windows binary of tcc[Scanned]
On Wed, Feb 15, 2006 at 11:16:53AM -0500, Ben Hinkle wrote: > On 2/14/06, Andrew Finney <[EMAIL PROTECTED]> wrote: > I put all my mingw-related work in directories without spaces (eg /c/mingw, > /c/tcc etc). I have no idea if that would solve the problems you are seeing > but in a unixy world I never trust that all the tools work with directories > with spaces. It's possible. Back when it was still called Interix, even Services for Unix didn't work right if you installed it under Program\ Files. > > In file included from tcc.c:51: > > elf.h:37: error: conflicting types for 'uint32_t' > > /usr/include/stdint.h:28: error: previous declaration of 'uint32_t' was > > here Looking at the code, elf.h assumes that when WIN32 is set, the compiler will not supply some standard C99 types such as uint32_t. This looks like an attempt to fix a known problem with MSVC's C99 compliance. MinGW/gcc probably does provide these types, which is causing a conflict. > > tcc.c:1338: warning: implicit declaration of function `_vsnprintf' > > tcc.c:3374: warning: implicit declaration of function `strtold' > > tcc.c:4026: warning: implicit declaration of function `_snprintf' There's a bunch of things in tcc.c controlled by the WIN32 setting that would affect these. I notice that _vsnprintf is a documented (though deprecated) function over at MSDN. A library suite like MinGW probably supplies a working vsnprintf and shouldn't use the special WIN32 settings. I suspect the basic problem is that when WIN32 is defined, the tcc code expects to be compiled with MSVC, not gcc. And when WIN32 is not defined, tcc expects to be able to use ucontext, which is a Unix thing that MinGW does not provide. If you want to use something like MinGW, Cygwin, or SFU to compile it, you're probably going to have to either edit the WIN32 stuff so that the MSVC parts don't kick in; or leave WIN32 undefined and remove the ucontext dependency. Last year someone mentioned some success with the second approach, but had not completely tested it: http://lists.gnu.org/archive/html/tinycc-devel/2005-05/msg00019.html -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] TinyC origins ?
On Thu, Dec 15, 2005 at 04:41:20PM -0700, Kim Lux wrote:
> How/why did TinyC get started ?
Fabrice Bellard wrote a very small compiler as an entry in the
International Obfuscated C Code Contest (it won the "best abuse of the
rules" award):
http://fabrice.bellard.free.fr/otcc/
http://www0.us.ioccc.org/years.html#2001_bellard
As far as I know TinyCC evolved from that.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc compile options (assm, C comments)
On Thu, Dec 15, 2005 at 04:08:10PM -0700, Kim Lux wrote: > C67 can assemble assembly language. Actually I'm not sure that it can. I haven't tried using it, but I notice in tcc.c that the assembly stuff is all protected by CONFIG_TCC_ASM, which is disabled for both ARM and C67. I also notice that the assembler frontend code in tccasm.c calls asm_opcode(), which only exists in the i386 backend. So while C67 has a mini-assembler within it, I'm not sure if it's really accessible from sourcecode. > What would stop me from writing the back end to emit assembly ? It would probably work. > If I implemented the assembler ala C67, tcc could assemble its own > emitted assembly code. Again, it would probably work, assuming you also make it possible for tcc to read and process the assembly. > Is there a mechanism in the front end to pass an entire C statement to > the back end for emission ? (I'll admit I haven't looked in the parser > yet...) There's tcc_compile_string() in libtcc.h, but it probably wants a complete translation unit rather than a single statement. I've never tried using it. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Question about tcc (C67) assembler code.
On Thu, Dec 15, 2005 at 02:35:54PM -0700, Kim Lux wrote: > What are the "<<23"s about ? [...] > C67_g((0 << 29) | //creg > (0 << 28) | //inv > (C67_map_regn(c) << 23) | //dst > (C67_map_regn(b) << 18) | //src2 (possible x path) > (C67_map_regn(a) << 13) | //src1 > (xpath << 12) | //x cross path if opposite sides > (0x7b << 5) | //opcode > (0x6 << 2) | //opcode fixed > (C67_map_regs(c) << 1) | //side of dest > (0 << 0));//parallel I don't know anything about C67, but this appears to be a simple bitfield packing function. I assume C67_map_regn(c) returns a 5-bit value in the range [0,31], which is then shifted 23 bits so that it ends up in bits 24-28 of the resulting machine word. > If one is writing a new assembler, should it be done in the same way ? That probably depends on the machine architecture. Each system will have its own special issues and requirements. C67 looks like a simple design with 32-bit instructions and not a lot of variation in the instruction formats. Other architectures are not so simple, for example: - i386 has variable-length instructions and (if you include support for later models) a gigantic instruction set. The instruction set manual for i686 fills something like two 700-page books. - SPARC has "delay slots" that can cause the instruction after a branch to be executed even when the branch is taken; this may require instructions to be emitted out-of-order. - Itanium2 requires instructions to be emitted in bundles: each 128 bits contains 3 41-bit instructions and one 5-bit template describing the execution units involved. This gets complicated and the compiler is responsible for scheduling access to the CPU's resources. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tcc compile options (assm, C comments)
On Thu, Dec 15, 2005 at 02:30:49PM -0700, Kim Lux wrote:
> Is there a way to compile C files into an assembler file ?
I'm not aware of any. tcc normally goes directly from C code to
object code without producing an intermediate assembly file.
> (For use with an external linker ?)
The resulting .o files should be usable with a linker.
> Does the ARM port generate assembler or machine code ? I don't see
> assembler code anywhere in gen.c like I do in the C67 port. Am I
> missing something ?
>From a quick glance: the C67 backend looks like it's using a small
assembler internally to make some of the code simpler, but I think
this is just a design choice specific to the C67 backend. When it
needs to emit a machine instruction, it can just pass a string to the
assembly function and have it generate the bit pattern. This probably
also makes it easier to compile inline assembly.
The ARM and i386 backends use a different design, for example see the
store() function in i386-gen.c and notice that it has bit patterns for
several machine instructions hard-coded into it.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Undefined symbols when run under ttylinux.
On Mon, Oct 24, 2005 at 05:26:36PM -0500, Alan Kilian wrote: > I can compile tcc under Fedora-core-3 and it works fine. > When I copy the installation files to a ttylinux system, > I get the following errors when compiling a minimal program: > > % tcc -o a a.c > tcc: undefined symbol '__libc_csu_fini' > tcc: undefined symbol '__libc_csu_init' My guess would be a glibc compatibility problem. On both systems, try running "/lib/libc.so.6" as if it were a program. That should tell you the glibc versions you've got installed. If the version numbers are much different, that's probably what's causing the trouble. ttylinux claims to have glibc 2.3.5 available, which is the current release and is probably very close to what FC3 uses; if you're running an old version of ttylinux with some older glibc, you might consider upgrading it. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] GCC by TCC (some fixes)
On Thu, Sep 29, 2005 at 10:06:15PM +0200, grischka wrote: > The gcc sources were unchanged except at one point where tcc did > not accept a typedef symbol as variable name (known issue). This patch might be useful (I haven't compared it against current CVS, though): http://lists.gnu.org/archive/html/tinycc-devel/2005-01/msg00010.html -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Can't compile the eiffel generated C files
On Mon, Aug 01, 2005 at 12:11:14AM +0700, Lothar Scholz wrote:
> >When a function is called using a prototype, the implicit argument
> >conversions are done with the same rules as assignment. An assignment
> >of a structure pointer requires that the structures be compatible.
> >Structure compatibility requires all fields to match. This is
> >essentially the same problem as:
> >
> > struct x { int a; };
> > struct y { int a; int b; };
> >
> > struct x foo;
> > struct y * bar;
> > bar = &foo;/* cast needed */
>
> Sorry but i think this should compile nevertheless as such a case is
> well defined by the C-99 standard that it must copy the sizeof(bar)
> bytes from foo into bar.
While I agree that it probably should do this, I'm still not sure that
C99 defines the operation as valid. Care to provide a reference?
Here's what I based my message on; note that this comes from the C99
draft rather than the final standard, so it may be that the final does
change this:
6.5.2.2 Function calls
Constraints
[#2] If the expression that denotes the called function has a type
that includes a prototype, the number of arguments shall agree with
the number of parameters. Each argument shall have a type such that
its value may be assigned to an object with the unqualified version
of the type of its corresponding parameter.
Semantics
[#7] If the expression that denotes the called function has a type
that does include a prototype, the arguments are implicitly
converted, as if by assignment, to the types of the corresponding
parameters, [...]
6.5.16.1 Simple assignment
Constraints
[#1] One of the following shall hold:
-- [arithmetic types]
-- [compatible structures and unions (not pointers)]
-- both operands are pointers to qualified or unqualified versions
of compatible types, and the type pointed to by the left has all
the qualifiers of the type pointed to by the right;
-- [pointers, but one of them has to be void*]
-- [pointer = null pointer constant]
-- [_Bool = pointer]
Note the requirement for type compatibility.
6.2.7 Compatible type and composite type
[#1] Two types have compatible type if their types are the same.
Additional rules for determining whether two types are compatible
are described in 6.7.2 for type specifiers, in 6.7.3 for type
qualifiers, and in 6.7.5 for declarators.40) Moreover, two
structure, union, or enumerated types declared in separate
translation units are compatible if their tags and members satisfy
the following requirements: If one is declared with a tag, the other
shall be declared with the same tag. If both are completed types,
then the following additional requirements apply: there shall be a
one-to-one correspondence between their members such that each pair
of corresponding members are declared with compatible types, and
such that if one member of a corresponding pair is declared with a
name, the other member is declared with the same name. For two
structures, corresponding members shall be declared in the same
order. For two structures or unions, corresponding bit-fields shall
have the same widths. For two enumerations, corresponding members
shall have the same values.
I read this as saying the pointers are not to compatible types; therefore
there is a constraint violation in 6.5.16.1.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Can't compile the eiffel generated C files
On Thu, Jul 28, 2005 at 05:22:10PM -0400, Daniel Gryniewicz wrote:
> > struct foo * x;
> > char y = (char)x;
> >
> > Which is obviously non-portable C code. gcc will complain about it if
> > you turn up the warning level:
>
> Worse than this, I believe gcc 4.0 will fail to compile this with an
> error.
That wouldn't surprise me. Lots of projects have had to clean up
their code a bit to make it work with gcc 4. Recent versions of gcc
have become stricter about what code they will accept. There are a
few cases where gcc 3.4.3 will even emit code to intentionally crash
a program if it tries to invoke undefined behavior. For example:
#include
void foo(int x,...)
{ va_list args; va_start(args,x); va_arg(args,short); va_end(args); }
foo.c: In function `foo':
foo.c:3: warning: `short int' is promoted to `int' when passed through `...'
foo.c:3: warning: (so you should pass `int' not `short int' to `va_arg')
foo.c:3: note: if this code is reached, the program will abort
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Can't compile the eiffel generated C files
On Wed, Jul 27, 2005 at 11:56:53PM +0700, Lothar Scholz wrote:
> I really want to use TinyCC with SmartEiffel but i get 3
> different errors in some of the C files.
> arachno_ruby143.c:6793: memory full
This is caused by tcc overflowing its internal stack. Look in tcc.c for:
#define VSTACK_SIZE 256
Change the 256 to a higher value and rebuild tcc. I tried 2560 and it
managed to compile the file.
> arachno_ruby156.c:679: cannot use pointers here
It looks like a SmartEiffel problem. Here's the line of code:
R=(((T6)((/*RF2*/(((T382*)C))->_second/*4*/
"R" is a char. "T6" is type char. "_second" is a struct pointer.
It's casting a struct pointer value to a char value. That is at best
implementation-defined and at worst undefined. It's basically the
same as:
struct foo * x;
char y = (char)x;
Which is obviously non-portable C code. gcc will complain about it if
you turn up the warning level:
arachno_ruby156.c:679: warning: cast from pointer to integer of different size
arachno_ruby156.c:685: warning: cast from pointer to integer of different size
Fixing this safely will require understanding why SmartEiffel is doing
this unusual cast. If you just want to force tcc to take it, you
could try casting to a larger integer type first; it may or may not
produce the same results as some other compiler:
R=(((T6)(unsigned long)((/*RF2*/(((T382*)C))->_second/*4*/
> arachno_ruby119.c:2347: cannot cast 'struct S1763 *' to 'struct S0 *'
It looks like a SmartEiffel problem. Here's the statement:
call_e2r0e6v(&ds,vc(a2,1017183770),_b,C,1);
T0 is struct {int id; }
T1763 is struct {int id; plus some other stuff }
C is a pointer to a T1763.
The function expects a pointer to a T0.
This requires a cast. For example:
call_e2r0e6v(&ds,vc(a2,1017183770),_b,(T0*)C,1);
When a function is called using a prototype, the implicit argument
conversions are done with the same rules as assignment. An assignment
of a structure pointer requires that the structures be compatible.
Structure compatibility requires all fields to match. This is
essentially the same problem as:
struct x { int a; };
struct y { int a; int b; };
struct x foo;
struct y * bar;
bar = &foo;/* cast needed */
Again, gcc will tell you there is a problem if you turn up the warnings:
arachno_ruby119.c:2347: warning: passing arg 4 of `call_e2r0e6v' from
incompatible pointer type
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bug - pointer cast
On Sat, Jul 23, 2005 at 09:30:31AM +0300, Oded Shimon wrote:
> 09:29) [EMAIL PROTECTED]:~ $ cat -n a.c
> 1 #include
> 2 int main(void) {
> 3 uint8_t * a, b[] = { 1, 1, 0, 0 };
> 4 a = b;
> 5 printf("%u\n", *((uint32_t *)&a[0]));
> 6 printf("%u\n", *((uint32_t *)a));
> 7 return 0;
> 8 }
Note that your example code is invoking undefined behavior (besides
the failure to include ). C provides no guarantee that b is
suitably aligned for use as a uint32_t. For example on Sparc/Solaris,
which is much stricter about alignment, simply adding a few more
variables to change the storage layout causes the program to fail:
- uint8_t * a, b[] = { 1, 1, 0, 0 };
+ uint8_t * a, c, d, b[] = { 1, 1, 0, 0 };
$ gcc foo.c && ./a.out
Bus Error
That said, it might still sort of be considered a bug in tcc since
i386 doesn't really require natural alignment of types; you'd
therefore expect certain results even if C won't guarantee them.
> Took me FOREVER to find that this was why my tcc compilation of
> MPlayer was misbehaving...
If MPlayer is doing this sort of cast without being sure that the
cast is a defined operation, then that's a bug in MPlayer.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] bug - function pointers in ?: expression
On Fri, Jul 22, 2005 at 07:54:51PM -0400, Russ Cox wrote:
> This is tcc compiled from CVS earlier this afternoon.
> It appears that the type of a ?: expression with function
> pointers in the arms somehow gets deduced to be
> some form of integer type instead of function pointer.
Known problem. See attached patch (note: this is against an old version
but will probably apply anyway).
-Dave Dodge
Dave Dodge 2004
The problem is that tcc doesn't have any code to recognize function
pointers within a conditional expression, so it defaults to treating
them as integers. The resulting expression then has integer type,
which of course isn't valid for a function call. Here's a quick (but
somewhat incomplete) workaround.
--- tcc-0.9.22/tcc.c2004-11-08 15:47:16.0 -0500
+++ tcc-0.9.22-fixed/tcc.c 2004-11-11 02:55:54.0 -0500
@@ -7598,6 +7598,9 @@
} else if (bt1 == VT_PTR || bt2 == VT_PTR) {
/* XXX: test pointer compatibility */
type = type1;
+} else if (bt1 == VT_FUNC || bt2 == VT_FUNC) {
+/* XXX: test function pointer compatibility */
+type = type1;
} else if (bt1 == VT_STRUCT || bt2 == VT_STRUCT) {
/* XXX: test structure compatibility */
type = type1;
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Fwd: Segfault compiling bash?
On Sat, Jul 16, 2005 at 07:14:43AM -0700, [EMAIL PROTECTED] wrote:
> Still see this with the latest release. Anyone else
> have the same problem?
I can at least explain the "constant expression expected" bug: tcc
does not properly compile code when a long long value is used to
specify an array size.
This partly comes from the fact that the expr_const() function in tcc,
which is used to obtain the array size, assumes constant values have
type int. Demonstration code:
void foo(void){
/* this works, but only by accident */
char a1[1LL];
/*
* "invalid array size". It pulls the value out of the CType int
* field, which produces a bit pattern that looks like -1.
*/
char a2[0x8000LL];
/*
* "constant expression expected". When an operator is put into
* the long long expression, I think it ends up trying to actually
* generate code to evaluate the expression at runtime, rather than
* realizing that it's a constant.
*/
char a3[1LL + 1LL];
}
The code in bash is doing this:
char ibuf[INT_STRLEN_BOUND (intmax_t) + 1], *p;
which expands to an expression with some intmax_t casts in it. On
i386 intmax_t is long long.
Sorry, I don't have a patch to fix it. At the very least someone should
probably fix expr_const() and everything that calls it. But that probably
still won't fix the a3 case.
As far as the segfault, I don't know. It might be related to the constant
handling as well.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Linux off_t casting?
On Fri, Jul 15, 2005 at 04:28:09PM +0200, Ivan Popov wrote: > On Thu, Jul 14, 2005 at 09:49:00PM -0700, [EMAIL PROTECTED] wrote: > > [EMAIL PROTECTED] tcc-apps]$ tcc off_t.c > > off_t.c:10: cannot cast 'int' to 'struct ' [...] > $ tcc -o aa aa.c No problem here, either (also glibc 2.3.2). > which is most probably irrelevant. I'd rather guess the difference is due to > different includes. I'd suggest poking around in the header files to see how off_t is defined on that machine, or if there are any macros interfering with the test program. "gcc -E" might be useful. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] casting bug?
On Tue, Jul 12, 2005 at 09:44:09PM +0200, Alexander Strasser wrote:
> Felix Nawothnig wrote:
> > You can't have both a guaranteed size and guaranteed performance (while
> > being portable), so what would your proposed "int_fast32_t" be then?
>
> It's not my proposed type, this exists already I don't know if it is
> covered by C99 or not.
Yes, it's standard in C99 assuming you include . For N = 8,
16, 32, and 64, C99 has these typedefs:
intN_t, uintN_t
Exact-width integers. The type has exactly N value bits.
These are required only if the implementation has an underlying
integer type of the proper size available.
int_leastN_t, uint_leastN_t
Minimum-width integers. The type will be the smallest type with
at least N value bits (but possibly more than N). These are
required.
int_fastN_t, uint_fastN_t
Fastest minimum-width integers. The type will be the "fastest"
(for all purposes, as decided by the implementation) type with
at least N value bits (but possibly more than N). These are
required.
C99 also standardizes:
intptr_t, uintptr_t
A void pointer converted to this integer type, then back to a void
pointer again, shall compare equal to the original pointer. These
are optional.
intmax_t, uintmax_t
Greatest-width integers. This type is capable of representing any
value of any integer type. These are required.
A related header is , which declares some string
conversion functions and provides format specifiers for the
types. For example to print a uint32_t portably, you would do
something like this:
uint32_t x;
...
printf("%" PRIu32 "\n",x);
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] casting bug?
On Tue, Jul 12, 2005 at 04:23:53PM +0200, Felix Nawothnig wrote: > It also guarantees that sizeof(char) <= sizeof(short) <= sizeof(int) <= > sizeof(long). (again I guess ISO C99 adds <= sizeof(long long)) It's a subtle point, but I don't think C99 actually guarantees this. Instead it guarantees that the range of a smaller type is a subset of the range of a larger type. Where "smaller" and "larger" here refer to the "integer conversion rank" of the type. So while SHORT_MAX must be less than or equal to INT_MAX, sizeof(short) can be larger than sizeof(int). This is because C99 adds the concept of "padding bits" in an integer which do not contribute to the value. I think you could have a conforming implementation where: short = 1 sign bit + 15 value bits + some padding bits int = 1 sign bit + 15 value bits + no padding bits I doubt someone would actually implement this sort of thing, but I'm pretty sure the standard does allow it. There almost certainly are platforms that use padding bits in some way, since otherwise there wouldn't be much need to add the concept to the standard. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] casting bug?
On Tue, Jul 12, 2005 at 12:12:16PM +0200, Alexander Strasser wrote: > Henrik Nordstrom wrote: > > LP64 platforms commonly has > > > > sizeof(void *) == 8 > > sizeof(long long) == 8 > > sizeof(long) == 8 > > sizeof(int) == 4 > > sizeof(short) == 2 > > sizeof(char) == 1 > > IIRC m$ decided to go with LLP64 model, meaning long stays 32bit. Yes. There was a interesting discussion/argument about this decision in one of the MSDN blogs a few months ago: http://blogs.msdn.com/oldnewthing/archive/2005/01/31/363790.aspx Some other models that have been used: - I once ported some code to an old Cray system where char was 8 bits and everything else was 64 bits. - I've read about DSP platforms (I think these are currently in production) where everything, including char, is 64 bits wide. > This no-guarantee-about-sizes-in-C thing begins to hurt nowadays ;) > Maybe it is really best to use special types like int_fast32_t If the size of the type matters, can be very useful. -Dave Dodge ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] casting bug?
On Mon, Jul 11, 2005 at 10:12:45PM +0200, Felix Nawothnig wrote:
> Dave Dodge wrote:
> >The standard definitely does not guarantee that a null pointer is the
> >same as all-bits-zero. There have been a few real implementations
> >that used nonzero bits.
>
> So? Casting takes care of that in our case,
My point was that even when converting a pointer to an intptr_t, the
standard does not guarantee that casting a null pointer will produce
the integer value 0 (which was one of the assumptions in the original
message).
Likewise, given code like this:
intptr_t const i = 0;
void * p1 = (void*)0;
void * p2 = (void*)i;
C guarantees that p1 will be a null pointer, but it does not guarantee
that p2 will be a null pointer.
> the only way to get the real NULL representation is by doing:
>
> void *p = NULL;
> int i = *(int *)&p;
I think to do it in a defined manner you have to use an unsigned char
array instead of an int. For one thing, sizeof(void*) is much larger
than sizeof(int) on the most common 64-bit architectures. And even if
they're the same size they could have different alignment
requirements, making &p unusable as an int*.
-Dave Dodge
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
