Re: [Tinycc-devel] Just reporting an expression issue
On Wed, Jul 20, 2011 at 11:12 AM, Michael B. Smith wrote: > I've got an expression patch that I'm working on regarding structure bitfield > handling, but this came out recently and thought it might be of interest: > http://blog.regehr.org/archives/558 Just a heads-up... I discovered a few days ago as well, that tcc's handling of bitfields is what causes sed's "make check" to fail 3 important cases (at least sed-4.1.5). "unsigned newline_anchor : 1;" in regex_.h (which is enabled by --with-included-regex) causes make check to fail... and also, more importantly, causes some real-world garden-variety configure scripts to go into an endless loop when using a tcc-compiled sed to generate configure.lineno. . ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Revert "better constant handling for expr_cond"
On Tue, Jul 19, 2011 at 10:26 AM, grischka wrote:
>>> Issue: http://repo.or.cz/w/tinycc.git/commitdiff/d7d84588
> ... not work. See this:
> printf("%.1f\n", 0 ? (printf("A"), 3.0) : (printf("B"), 4));
> ...
> Plus there might be other things wrong with the patch that this
> example does not show. Not trivial, you see?
No, not trivial, you're right. The change was less than half-baked
and I've just pushed a much more focused patch that actually works.
> Anyway we should not force TCC to do something what is was not
> written for. It is waste of time. If we want optimized code,
> then TCC wants an optimizer. That is how it is. Possible but
> non-trivial.
I agree 100%. Performance/code-size is completely off my radar; I'm
not concerned at all with that. I've just got mounds of Makefiles to
wade through, one of them was choking on this particular thing, and I
made a 'fix' way outside of where it belonged in an misguided effort
to be more general and 'clever' about it.
> Other topic: I've seen you did something with the macro preprocessor.
> Could you make some progress there?
> I've attached the cpp tests from the pcc compiler.
> http://pcc.ludd.ltu.se/
> Just in case you have fun to try how far TCC can get on this
> area. (I've tried it some time ago, it was, well, ...)
Thanks for this. I looked at the mcpp testsuite but got lost in the
scaffolding. I will definitely take a look at the pcc suite. I am
working on a few different PP issues at the moment and I'll be
interested to see if they're covered in the pcc suite.
Joe
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] macro issue with vstack warning and __FUNCTION__ error
On Apr 29, 2011 8:47 PM, "Luis Alejandro Muzzachiodi" < lamuzzachi...@yahoo.com> wrote: > When i try to compile library related to gtk, with the mob's version, i get: > > aspectFrame.c:53: error: ',' expected (got "__FUNCTION__") > aspectFrame.c:53: warning: internal compiler error: vstack leak? (5) The warning about vstack leak is spurious, it's my fault and I thought I already committed a fix, but I will do now. As for the error, I don't know anything about that for now. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Best workaround for VLA's
On Mon, Apr 11, 2011 at 5:29 AM, Thomas Preud'homme wrote: > I'd also want to apologize as I didn't have time to work on tcc again this WE > since I have some work to do for my job. I will try to work on it tonight or > tomorrow evening. Just to let you know, I've already finished the fixes you described for VLA, committed on my local branch. You can take a break and relax if you want. I'm just installing a 64bit VM to try get it working on x86-64. Should be done pretty soon. Thanks, Joe. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Best workaround for VLA's
On Thu, Apr 7, 2011 at 9:50 PM, Luis Alejandro Muzzachiodi
wrote:
>
> Until now i was using successfully TCC with a multiplatform library.
> However in the last time the author begin to use VLA's (and tough i'm trying
> that not, it's very possible that he keeps and/or increases more your use).
> So, what's would be the best workaround in TCC for stuff like:
> char str[i+15];
> or
> float flt[veclen];
> etc.?
> I mean, the simplest option could be the max possible length, sure; but i
> haven't idea of max size of these arrays ...
> Having this on mind, what's the best alternative (if exists...) ?.
I'm planning to push a modified version of Thomas Preud'homme's VLA
patch very soon that might solve your problem.
But basically what I've been doing, is just converting those things to
alloca() calls.
So,
char str[i+15];
float flt[veclen];
becomes
char *str = alloca(sizeof(char)*(i+15));
float *flt = alloca(sizeof(float)*veclen);
The problem with that approach is that it doesn't work with
multidimensional arrays, doesn't work with function parameters, and
most importantly doesn't work with sizeof.
For example, there's no alloca equivalent for multidimensional dereferencing:
char str[i+15][10];
str[0][0] = 123;
Also, there's no obvious equivalent for something like the VLA example
in "C in a nutshell":
double maximum(int nrows, int ncols, double matrix[nrows][ncols])
{ /* ... */ }
Finally,
float flt[veclen];
memset(flt, 0, sizeof(flt));
doesn't work.
You can of course just use
memset(flt, 0, sizeof(float)*veclen);
instead, but "veclen" may have changed since the array was allocated,
say if it was reused for some other purpose in between.
Also you probably should '#include ' which can be slightly annoying.
..
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tricky little bounds-checking bug
On Thu, Apr 7, 2011 at 7:05 AM, grischka wrote: >> Before you invest too much time however note that Fabrice once said >> that there is some flaw in the implementation of in the bounds checker >> with (as I understood it) possible impact on reliability of detection. >> I don't know what exactly he meant though. > > FYI, this was Fabrice's original message (from 2007/11): > > "Another point is that I realized that the bound check region algorithm > used in TCC is completely broken (the code to search the region associated > to a pointer does not work in all cases). I think the only way to make it > work reliably is to tag each allocated byte with one bit." Thanks, I appreciate it. I'm not too concerned with making bounds-checking work globally, though... I just wanted to get VLA working with bounds checking, since the last VLA patch didn't, and I stumbled upon the fact that tcc itself doesn't run under bounds-checks and went off on that tangent. I see now what needs to change to get tcc running under bounds-checks but I want to get VLA in first. Basically, Thomas' patch said that it didn't work with bounds-checking and had a warning, but it actually appears to work just fine with bounds-checking on, so no problem there. I just have a couple of changes to make to Thomas patch and that should do it for now. I was planning to push VLA tonight. Thanks for your help. Joe ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tricky little bounds-checking bug
On Sat, Mar 26, 2011 at 5:13 AM, grischka wrote: >> Looking at the disassembly, it seems that the '!' operator causes a >> register to be stomped on. ... >> I've tried to fix it, but I'm kinda lost in the bounds-checking logic. >> Anyone have any ideas? > > I recall there was a similar problem without bounds-checking: > http://landley.net/hg/tinycc/rev/3f48bed56ab4 > + 437: Call 'saveregs()' before jumping with logical and/or/not Thank you, it's much appreciated. I was messing around blindly with those saveregs() calls and a bunch of other stuff before realizing that it isn't anything weird, it's exactly what it "looks" like. In vstore(), the gbound() call should be done immediately before the store(), not before the gv(rc) call, and certainly not outside of the !nocode_wanted block, right? Just moving the gbound() block down directly before the store(r, vtop -1) solves the problem, it seems. . ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] tricky little bounds-checking bug
-
char xyz[123];
void main(void)
{
int i = 0;
xyz[0] = !i;
}
This comes from trying to get tcc to run itself with bounds-checking
turned on. This is a reduced form of "init isid table" in
preprocess_new().
Looking at the disassembly, it seems that the '!' operator causes a
register to be stomped on. Some other expressions do the same thing,
like "i || 1".
I've tried to fix it, but I'm kinda lost in the bounds-checking logic.
Anyone have any ideas?
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Test case for C99 feature
On Mon, Mar 21, 2011 at 6:27 AM, Pedro A ARANDA wrote: > paag@paag:~.../Devel$ gcc kk.c > kk.c: In function ‘main’: > kk.c:10: error: expected expression before ‘pascal_string’ Hi Pedro. I think that, in general, if gcc refuses to compile some source, tcc doesn't strive to guarantee anything about tcc compiling that same source, in this case it happily seems to output invalid code. I think that's normal and correct to focus relatively minuscule development resources on valid sources and giving no guarantees about what happens with invalid source. Having said that, patches are welcome of course, if you figure out why tcc accepts a typedef name in place of an expression. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] about patch: support c99 for-loop init decls
On Tue, Mar 8, 2011 at 1:24 PM, grischka wrote: >>> I'd rather let decl0() just do the c99 case and return a value >> >> Yes... I wanted to do that, but it didn't seem to fit with the rest of the >> code. I thought this way was more tcc-like. > > tcc-like in how? Any evidence of analogous hacks elsewhere in the code? I just meant leaving decl() alone and creating a decl0() so the other callsites wouldn't have to change, and I do see evidence of that sort of thing elsewhere in tcc. But that's not what you were getting at, and now I understand. >> Please feel free to change it however you see fit. > Maybe I will. I didn't want to seem ornery, I just meant that I thought I understood what you were getting at, but that I had absolutely no problem with someone else committing over top of me, and certainly you would do a better job than me of expressing your internal concept in code. Plus you obviously have more ownership than just about anyone else, so I was merely deferring to your eminence. > Until then feel free to fix incorrect variable scope ;) > [example code] Darn. Thank you. I'm doubly embarrassed now. Joe ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] about patch: support c99 for-loop init decls
On Tue, Mar 8, 2011 at 9:15 AM, Joe Soroka wrote: > On Tue, Mar 8, 2011 at 6:00 AM, grischka wrote: >> I'd rather let decl0() just do the c99 case and return a value > > Yes... I wanted to do that, but it didn't seem to fit with the rest of the > code. I thought this way was more tcc-like. Please feel free to > change it however you see fit. I'm sorry, I didn't understand you precisely at first. I've figured it out now. I'll make the changes you've suggested. Thanks. Joe ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] about patch: support c99 for-loop init decls
On Tue, Mar 8, 2011 at 6:00 AM, grischka wrote: > I'd rather let decl0() just do the c99 case and return a value Yes... I wanted to do that, but it didn't seem to fit with the rest of the code. I thought this way was more tcc-like. Please feel free to change it however you see fit. Thanks. Joe ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] can't build mob branch on x86 64
On Sat, Feb 5, 2011 at 5:52 PM, Thomas Preud'homme wrote: > As to a negative size for VLA, I'm not sure of what the correct behaviour > should > be. Should we just do nothing, take the opposite of the value, or something > else? In my opinion, since the tests are set up as diffs against gcc, just do whatever gcc does. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] can't build mob branch on x86 64
Hey guys, sorry I got in the way at all. If there wasn't the build breakage, I wouldn't have said anything. Just go ahead on mob, Thomas, if you want. If I have some suggestions for enhancements, I'll just propose them as they develop. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] can't build mob branch on x86 64
On Fri, Feb 4, 2011 at 3:49 PM, Thomas Preud'homme wrote: > Really? You want to rewrite it entirely? Took me so much time and it work well > now :( Couldn't just some CONFIG_TCC_ALLOCA macro be defined in Makefile when > compiling? Rewrite it entirely, no. I apologize for accidentally implying that. While there *are* problems with your patch (doesn't handle size==0, doesn't work with bcheck, some others) I don't mean to throw it out. I guess I just mean that the fact you missed the "TOK_alloca is an enum" bit plus a few other simple things makes me worry about how well tested the *complicated* stuff is and I'd kinda like to see you pull it back, sleep on it, think on it, polish it a little bit and then bring it back. I went through the same kind of thing with my patch for weak symbols - I had to throw it out and start over and ended up with a much smaller, much better version. Plus, I had my own partially-working VLA patch in my queue that "took me so much time" and I hate to throw it out as well, so I know what it feels like. :) > Anyway, however you code VLA, you need alloca and need a way to detect if > alloca is available or not. Do you have suggestion on how to rewrite it? I have a few ideas, but basically if libtcc1.a doesn't have an alloca for the target, (or perhaps CONFIG_USE_LIBGCC) then don't do it. That's the safest way I can think of, at least for tccgen.c. For tcctest, you'd need an ifdef that works with gcc too, or modify the test Makefile. I'll try to come up with a patch now. Also, it wouldn't hurt to introduce a __builtin_alloca and use that for stuff like VLA, so there's no link-time confusion with any other libc allocas, if they exist. That gawk report about missing "__builtin_malloc" after the introduction of VLA seems to hint at that as a problem. I dunno, the whole build/test/cross system is a bit of a mess. I'm leaning towards my own friendly-fork a-la landley which focuses solely on x86 and gets it working perfectly there, without regard for other targets, because I have a lot more patches and with each one I'm afraid of stomping on something I can't test. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] can't build mob branch on x86 64
On Fri, Feb 4, 2011 at 6:28 AM, Thomas Preud'homme wrote: > My mistake, I forgot that TOK_alloca was not defined on x86-64. As alloca You missed the fact that TOK_alloca is never 'defined'. It's an enum element. #ifdef TOK_alloca is the same as #ifdef TOK_INT is the same as #if 0 So, you'll have to pull that patch back out. It's just fundamentally flawed. All it does is turn off VLA for every arch, no matter what, and then turn off the test too. Good try, though. I don't know what you should do instead. I humbly request that you revert the whole VLA patch and we try again, a little more slowly. I have some ideas for how to proceed. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] switching from lurker to mob committer, with lots of patches ready
Hello TinyCCers, Long-time lurker here. A few years ago, I spent a lot of time on tinycc, but had to stop. I don't like that all my patches are rotting in my private repo. I would estimate that I have nearly a hundred of them, possibly a lot more if my private commit logs are accurate. Almost all of them come with test cases to match, and I'll add test cases for the ones that don't, when appropriate. I just wanted to say hello before loading the patch cannon. I think I will launch one per day, and if no one has problems with the patches, I may step it up and go faster. My initial goal, way back when, was to compile dietlibc and busybox and eventually binutils and gcc. So most of the patches come out of that - adding features that gcc and gas have that tinycc does not. A smaller number of the patches are legitimate bug-fixes, but they're peppered haphazardly into the commit-stream. I'd rather not sort them all into priority bins because I'm afraid I'll just give up during the sorting. I'd like to just post them chronologically as they were written. Comments are welcome, of course. Sincerely, Joe Soroka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/tinycc-devel
