Re: [Tinycc-devel] plans to 0.9.28

[David Mertens]

+1

David

On Wed, Jul 26, 2017 at 6:33 AM, Christian JULLIEN  wrote:

>
> Hi all,
>
>
> Last December, we where close to release 0.9.28 but more than 6 months
> later, I see no plans for an imminent 0.9.28 release.
>
> I'm fortunate to know how to build tcc on the many machines I use but also
> see many users trying to use a very old 0.9.27 version.
>
> I think it's time to release 0.9.28 and start new dev. on 0.9.29
>
>
> IMHO,
>
> - we should decide what we really want to implement before we release
> 0.9.28 and propose an ETA for implementation
>
> - enter a bug fix, validation cycle (no new feature or gratuitous changes)
>
> - check all ports (Windows 32/64, Linux x86, x64, arm, Aarch64, more?), I
> will test all of them
>
> - Make 0.9.28
>
>
> Sounds reasonable to you?
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Please, please at least notify the list when you make big changes

[David Mertens]

Case in point:

I just tried to merge grischka's latest commit, described as "tccgen:
nodata_wanted fix, default ONE_SOURCE, etc...". I have no idea why, but
with the commit grischka decided to move a whole bunch of functionality out
of libtcc.c's tcc_compile() and into tccgen.c's tccgen_compile(). Is this a
good idea? Maybe? It makes tcc_compile read a little more clearly, though
the real functionality is now buried under one more layer of abstraction. I
don't know grischka's motivation because he never explained what he's doing
or why.

What I do know is that now two of my tests segfault, and I'll probably have
to spend a couple of *hours* reverse-engineering how to track the symbols.

Hours of my life wasted for what seems like a frivolous change.

David

On Tue, Jul 25, 2017 at 12:31 AM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Hello all,
>
> This is my annual (or so) rant/reminder urging everyone for high quality
> committing and communicating habits.
>
> As a maintainer of a fork of tcc, I go through a lot of effort when I
> merge the latest work on tcc's mob into my fork. This is a burden I have
> brought upon myself, and I am not complaining about folks' contributions to
> tcc that continue to improve it. However, there are ways to improve things
> (i.e organize, commit, and discuss your work) that are easy to process, and
> there are ways to improve things that are hard to process.
>
> If you want to see practices that are easy to process, look at Michael
> Matz's commits and the conversation surrounding them. If you want to see
> commits that are hard to process, see grischka's unprompted commits.
>
> Let me be clear before I go any further: the final result of grischka's
> commits are almost universally excellent. He wields C much better than I
> ever could, and I would rather have his commits as he currently does them
> than not have them at all. Specifically, grischka latest work refactoring
> the Sym layout is a fantastic contribution that makes this compiler easier
> to understand for current and future tcc hackers. It's the kind of think
> that everybody would like to have, but nobody except grischka will put the
> effort into doing. Thank you!
>
> But lordy I would really appreciate if he (and the rest of the community)
> could consider the following basic good-git practices:
>
>- orthogonal changes should be in distinct commits, don't commit "X...
>and also Y, Z, and W"
>- changes to any of the internal function APIs should be (at the very
>least) announced on the mailing list, and preferably discussed
>- changes in where and how functionality is implemented should be
>announced on the mailing list, and preferably discussed.
>- changes to public API functions *really* *should* be discussed on
>the mailing list before being committed
>- changes to the build process *really* *should* be discussed on the
>mailing list before being committed
>
> Why should you do these things? Because right now I cringe before I try to
> merge any commit made by grischka. I know the result will be worth it, but
> the interim will probably be time consuming and confusing. Do you want to
> be cringe-inducing to fellow developers? Of course not. Discuss your work
> on the list and commit your work in lots of small chunks.
> Thanks!
> David
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Please, please at least notify the list when you make big changes

[David Mertens]

Hello all,

This is my annual (or so) rant/reminder urging everyone for high quality
committing and communicating habits.

As a maintainer of a fork of tcc, I go through a lot of effort when I merge
the latest work on tcc's mob into my fork. This is a burden I have brought
upon myself, and I am not complaining about folks' contributions to tcc
that continue to improve it. However, there are ways to improve things (i.e
organize, commit, and discuss your work) that are easy to process, and
there are ways to improve things that are hard to process.

If you want to see practices that are easy to process, look at Michael
Matz's commits and the conversation surrounding them. If you want to see
commits that are hard to process, see grischka's unprompted commits.

Let me be clear before I go any further: the final result of grischka's
commits are almost universally excellent. He wields C much better than I
ever could, and I would rather have his commits as he currently does them
than not have them at all. Specifically, grischka latest work refactoring
the Sym layout is a fantastic contribution that makes this compiler easier
to understand for current and future tcc hackers. It's the kind of think
that everybody would like to have, but nobody except grischka will put the
effort into doing. Thank you!

But lordy I would really appreciate if he (and the rest of the community)
could consider the following basic good-git practices:

   - orthogonal changes should be in distinct commits, don't commit "X...
   and also Y, Z, and W"
   - changes to any of the internal function APIs should be (at the very
   least) announced on the mailing list, and preferably discussed
   - changes in where and how functionality is implemented should be
   announced on the mailing list, and preferably discussed.
   - changes to public API functions *really* *should* be discussed on the
   mailing list before being committed
   - changes to the build process *really* *should* be discussed on the
   mailing list before being committed

Why should you do these things? Because right now I cringe before I try to
merge any commit made by grischka. I know the result will be worth it, but
the interim will probably be time consuming and confusing. Do you want to
be cringe-inducing to fellow developers? Of course not. Discuss your work
on the list and commit your work in lots of small chunks.
Thanks!
David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] _Generic or __builtin_choose_expr

[David Mertens]

I would prefer that you push any and all fixes to mob as soon as you have
them ready. I think most contributors are very conservative about adding
things to mob, but once a feature is in place they push fixes as soon as
they are noticed.

Thanks for your work on this!
David

On Mon, Jul 17, 2017 at 12:47 PM, uso ewin  wrote:

> Hello
>
> On Sat, Jul 15, 2017 at 9:53 AM, grischka  wrote:
> > uso ewin wrote:
> >>
> >>
> >> Hello,
> >>
> >> Sorry if I take time to answer,
> >> So actually it's not a test issue, because gcc can do difference
> >> between a 'char *' a 'signed char *', and a 'unsigned char *',
> >> gcc doesn't consider int and a typedef of an int as the same type,
> >> and most important it will find the good match to a long.
> >>
> >> grischka seems to have fix char * problem,
> >> I've just push a fix for the long on my github,
> >> but it does refactor how VT_LONG is handle so I’m not very confident
> >> on pushing it now on mob without a review
> >> (this is why it take me time to answer).
> >>
> >> I've also fix all type.
> I mean fix all typo
>
> >>
> >> for the typedef, I guess it might work, but I didn't check further yet.
> >
> >
> > Does it work with "_Generic(i + 1L, ...)" ?
> >
>
> I didn't test it yet sorry,
> Apparently patches on my github have break some tests,
> which I try to fix at first, then I'll try to fix "_Generic(i + 1L, ...)"
> (I guess it doesn't work as untested)
>
> I'll notify again here once everything are fix.
>
> Should I push typo fix on mob now ?
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Patch that adds missing conditional standard defines and iso646.h

[David Mertens]

Hello Petr,

Since tcc implements variable length arrays, why would we define
__STDC_NO_VLA__?

David

On Mon, Jul 17, 2017 at 9:50 AM, Petr Skočík  wrote:

> Hi.
>
> This adds
> #define __STDC_NO_ATOMICS__ 1
> #define __STDC_NO_COMPLEX__ 1
> #define __STDC_NO_THREADS__ 1
> #define __STDC_NO_VLA__ 1
> and
> an iso646.h header.
>
> I think it should included in tcc.
>
> I'm using an all of C header (https://pastebin.com/bjwRJY9Q) and if this
> is part of tcc, I won't have to special-case the compiler inside the
> header.
>
> Best regards,
> Petr Skocik
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Crutches_for_TCC_inline_Asm.

[David Mertens]

No personal attacks on this list, please.

On Sun, Jul 16, 2017 at 2:30 AM, ANDY TAKKER  wrote:

> Chronology:
> http://lists.nongnu.org/archive/html/tinycc-devel/2017-07/msg00031.html
> http://lists.nongnu.org/archive/html/tinycc-devel/2017-07/msg00032.html
> http://lists.nongnu.org/archive/html/tinycc-devel/2017-07/msg00034.html
> http://lists.nongnu.org/archive/html/tinycc-devel/2017-07/msg00035.html
>
>
> A good programmer writes the program in 10 minutes. And for the
> rest of his life he corrects errors in it. :) Oleg E Tereshlov.
>
> A bad programmer John made a mistake in the code, due to which
> every user of the program was forced to spend an average of 15
> minutes to find a work around the problem. There were 10 million
> members. In total they wasted 150 million minutes = 2.5 million
> hours. If a person sleeps 8 hours a day, then 16 hours are left
> for the conscious activity. That is, John has destroyed 156,250
> man-days ? 427.8 person-years. The average man lives 64 years,
> so John had killed as many as 6.68 people.
>
> Are you sleeping well, John — serial programmer?
>
> Linux, Windows, GCC: But let's create together with our program
> a hundred other, completely useless, which nobody will use. And
> we will force the user to install all of them on the disk. We
> will not give him a choice. And we'll do our main job somehow
> as a typing blunder and ready. And so come down! Hahaha!
>
> Dear student - do not write the code.
> If you write, do not save it.
> If you save - do not upload.
> If laid out - not on the Internet.
> If the Internet - delete.
> If removed - did good to people.
>
> Good Code Rules:
> Simplicity-comprehensibility-compactness-productivity-lack of
> duplication.
>
> Why do I use TCC? Conveniently: Small size, *.def for the
> linker. It is not necessary to determine the parameters of
> functions in proto. Folder 'include' absolutely not needed.
> I can put TCC in any pose. Freedom! But local variables in
> inline Asm are fucked. Fucked.
>
> I would never have thought that TCC is the fork of GCC for
> Primates. But if you insist ...
>
> Dear Daniel. It's very fun to play these games:
>
> int   main()
> {
> unsigned int a;
> int junk1, junk2, junk3;
> b:
> asm ( "cpuid\n"
>   "rdtsc"
>   : "=a"(a), "=b"(junk1), "=c"(junk2), "=d"(junk3));
> printf("%u\n", a);
> goto b;
> }
>
> :00401000 55  push ebp
> :00401001 89E5mov ebp, esp
> :00401003 81EC1000sub esp, 0010
> :00401009 90  nop
>
> :0040100A 53  push ebx
> :0040100B 0FA2cpuid
> :0040100D 0F31rdtsc
> :0040100F 8945FC  mov dword ptr [ebp-04], eax
> :00401012 895DF8  mov dword ptr [ebp-08], ebx
> :00401015 894DF4  mov dword ptr [ebp-0C], ecx
> :00401018 8955F0  mov dword ptr [ebp-10], edx
> :0040101B 5B  pop ebx
> :0040101C 8B45FC  mov eax, dword ptr [ebp-04]
>
> :0040101F 50  push eax
> :00401020 B800204000  mov eax, 00402000
> :00401025 50  push eax
> :00401026 E80D00  call 00401038
> :0040102B 83C408  add esp, 0008
> :0040102E EBDAjmp 0040100A
> :00401030 C9  leave
> :00401031 C3  ret
>
>
> But the joy can quickly disappear when faced with these:
>
> { int a1, a2, ..., a200,
>   .,
>   ab1, ab2, ..., ab200,
>   .,
>   a...z1, a...z2, ..., a...z200; }
>
> I know a lot of fan clubs PureBasic and not one TCC. Do not you
> know why? Even LCC32 have... one. Just do not say that all are
> Fools. If you're the second I'm of Fabrice, pass Hello to him
> and again ask to do, about what he was asked.
>
> If not, then it's not Fabrice's author, but his mother, father,
> sister, wife, mother-in-law, etc. In 2013, the author of the TCC
> died and development stopped.
>
> GCC inline Asm is the most stupid thing in the world, which one
> could think of. Read about its rules yourself.
>
> I'll tell you and Fabrice a secret. When in my simple direct
> question GNU-man, as usual, answers: - read third-party manuals, my
> first thought: - I'll better read "Rest in peace" on your
> grave, hegoat. And I'm not alone. Remember this next time.
> After all, you answered.
>
> Do you want to take the exam again? Show the children how
> directly declare the stdcall function in the TCC. A long time
> ago, it's time. I want you to do it yourself. Do not be shy,
> more boldly. We will understand you. Who need windows.h for it?
> GCC manuals again... Yes? You are fan(n)y.
>
> Yesterday I was visited by inspiration:
> GAS = AssAsm + GNUlicense. Why? Because someone just lost one
> 's' in as.exe. Ass.exe is much better.
>

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

64-byte alignment adds about 10% to the longer example program I linked
earlier (which actually prints the size of the allocated code block). 10%
isn't bad! For this reason, and because lots of architectures use 64-byte
cache lines, I suggest that we just use 64-byte alignment, independent of
architecture.

Thoughts? Or, can anybody provide other memory consumption benchmarks that
paint a more complete picture?

David

On Sun, Jan 8, 2017 at 7:40 AM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> OK, done! And you were right, we only need to align on 64 bytes!
>
> Follow-up question: since the alignment is only 64-bytes, would it be
> sensible to have all architectures align to this, including ARM?
>
> David
>
> On Sun, Jan 8, 2017 at 7:19 AM, David Mertens <dcmertens.p...@gmail.com>
> wrote:
>
>> Thanks for the feedback, grischka.
>>
>> On Sat, Jan 7, 2017 at 6:15 AM, grischka <gris...@gmx.de> wrote:
>>
>>> David Mertens wrote:
>>>
>>>> I just pushed a commit that sets up 512-byte alignment for x86-64
>>>> architectures. It only uses 512 bytes for x86-64; for all others it
>>>> sticks
>>>> with the default of 16 bytes.
>>>>
>>>
>>> L1/L2 cache line size is 64 bytes on x86-like processors, no matter
>>> whether run in 32 or 64 bit mode.
>>>
>>
>> Yes, theoretically we should not need to align on anything more than 64
>> bytes. I chose 512 because I still got slowdowns for smaller alignments,
>> including 256. But you mention...
>>
>>
>>> However to make it work reliably the memory from malloc needs to be
>>> aligned as well, like so:
>>>
>>> offset = 0, mem = (addr_t)ptr;
>>> +mem += -(int)mem & SECTION_ALIGNMENT;
>>>
>>> and the possibly additional amount needs to be requested in advance:
>>>
>>> if (0 == mem)
>>> -return offset;
>>> +return offset + SECTION_ALIGNMENT;
>>>
>>
>> If I put this in place, then maybe the section alignment can be lessened.
>> I'll have to check. FWIW, I've been doing this with my own TCC-calling code
>> already and I've seen performance benefits. I don't see how the math would
>> work to let me reduce SECTION_ALIGNMENT to 64 bytes, but I'll experiment
>> and see what happens.
>>
>> All of this is a black box to me. From what I've read, I don't think we'd
>> need to worry about anything beyond 64 bytes, but I don't understand the
>> underlying CPU behavior well enough to predict. The numbers I actually use
>> will be based on real timing from testing on my machine or from feedback
>> from others.
>>
>> I ran the tests on my BeagleBone Black with
>>>> the original alignment and saw no performance issues,
>>>>
>>>
>>> Obviously ARM don't automatically clear the instruction cache which is
>>> why we have the explicit __clear_cache() call for ARM further down in
>>> set_pages_executable().
>>>
>>> I am not sure if this quite follows the project practices. I define
>>>> SECTION_ALIGNMENT just prior to the function tcc_relocate_ex. If anybody
>>>> can think of a better place to put it, to keep useful things in one
>>>> place,
>>>> please move it.
>>>>
>>>
>>> SECTION_ALIGNMENT seems too general as a name.  tccelf.c is full of
>>> section_alignments of various kinds.  I'd suggest something prefixed
>>> with RUN_  to indicate that it's used only in that specific place.
>>
>>
>> Can do! I may not have time today, but I should be able to push a revised
>> commit in the next couple of days.
>>
>> David
>>
>> --
>>  "Debugging is twice as hard as writing the code in the first place.
>>   Therefore, if you write the code as cleverly as possible, you are,
>>   by definition, not smart enough to debug it." -- Brian Kernighan
>>
>
>
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

OK, done! And you were right, we only need to align on 64 bytes!

Follow-up question: since the alignment is only 64-bytes, would it be
sensible to have all architectures align to this, including ARM?

David

On Sun, Jan 8, 2017 at 7:19 AM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Thanks for the feedback, grischka.
>
> On Sat, Jan 7, 2017 at 6:15 AM, grischka <gris...@gmx.de> wrote:
>
>> David Mertens wrote:
>>
>>> I just pushed a commit that sets up 512-byte alignment for x86-64
>>> architectures. It only uses 512 bytes for x86-64; for all others it
>>> sticks
>>> with the default of 16 bytes.
>>>
>>
>> L1/L2 cache line size is 64 bytes on x86-like processors, no matter
>> whether run in 32 or 64 bit mode.
>>
>
> Yes, theoretically we should not need to align on anything more than 64
> bytes. I chose 512 because I still got slowdowns for smaller alignments,
> including 256. But you mention...
>
>
>> However to make it work reliably the memory from malloc needs to be
>> aligned as well, like so:
>>
>> offset = 0, mem = (addr_t)ptr;
>> +mem += -(int)mem & SECTION_ALIGNMENT;
>>
>> and the possibly additional amount needs to be requested in advance:
>>
>> if (0 == mem)
>> -return offset;
>> +return offset + SECTION_ALIGNMENT;
>>
>
> If I put this in place, then maybe the section alignment can be lessened.
> I'll have to check. FWIW, I've been doing this with my own TCC-calling code
> already and I've seen performance benefits. I don't see how the math would
> work to let me reduce SECTION_ALIGNMENT to 64 bytes, but I'll experiment
> and see what happens.
>
> All of this is a black box to me. From what I've read, I don't think we'd
> need to worry about anything beyond 64 bytes, but I don't understand the
> underlying CPU behavior well enough to predict. The numbers I actually use
> will be based on real timing from testing on my machine or from feedback
> from others.
>
> I ran the tests on my BeagleBone Black with
>>> the original alignment and saw no performance issues,
>>>
>>
>> Obviously ARM don't automatically clear the instruction cache which is
>> why we have the explicit __clear_cache() call for ARM further down in
>> set_pages_executable().
>>
>> I am not sure if this quite follows the project practices. I define
>>> SECTION_ALIGNMENT just prior to the function tcc_relocate_ex. If anybody
>>> can think of a better place to put it, to keep useful things in one
>>> place,
>>> please move it.
>>>
>>
>> SECTION_ALIGNMENT seems too general as a name.  tccelf.c is full of
>> section_alignments of various kinds.  I'd suggest something prefixed
>> with RUN_  to indicate that it's used only in that specific place.
>
>
> Can do! I may not have time today, but I should be able to push a revised
> commit in the next couple of days.
>
> David
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

Thanks for the feedback, grischka.

On Sat, Jan 7, 2017 at 6:15 AM, grischka <gris...@gmx.de> wrote:

> David Mertens wrote:
>
>> I just pushed a commit that sets up 512-byte alignment for x86-64
>> architectures. It only uses 512 bytes for x86-64; for all others it sticks
>> with the default of 16 bytes.
>>
>
> L1/L2 cache line size is 64 bytes on x86-like processors, no matter
> whether run in 32 or 64 bit mode.
>

Yes, theoretically we should not need to align on anything more than 64
bytes. I chose 512 because I still got slowdowns for smaller alignments,
including 256. But you mention...


> However to make it work reliably the memory from malloc needs to be
> aligned as well, like so:
>
> offset = 0, mem = (addr_t)ptr;
> +mem += -(int)mem & SECTION_ALIGNMENT;
>
> and the possibly additional amount needs to be requested in advance:
>
> if (0 == mem)
> -return offset;
> +return offset + SECTION_ALIGNMENT;
>

If I put this in place, then maybe the section alignment can be lessened.
I'll have to check. FWIW, I've been doing this with my own TCC-calling code
already and I've seen performance benefits. I don't see how the math would
work to let me reduce SECTION_ALIGNMENT to 64 bytes, but I'll experiment
and see what happens.

All of this is a black box to me. From what I've read, I don't think we'd
need to worry about anything beyond 64 bytes, but I don't understand the
underlying CPU behavior well enough to predict. The numbers I actually use
will be based on real timing from testing on my machine or from feedback
from others.

I ran the tests on my BeagleBone Black with
>> the original alignment and saw no performance issues,
>>
>
> Obviously ARM don't automatically clear the instruction cache which is
> why we have the explicit __clear_cache() call for ARM further down in
> set_pages_executable().
>
> I am not sure if this quite follows the project practices. I define
>> SECTION_ALIGNMENT just prior to the function tcc_relocate_ex. If anybody
>> can think of a better place to put it, to keep useful things in one place,
>> please move it.
>>
>
> SECTION_ALIGNMENT seems too general as a name.  tccelf.c is full of
> section_alignments of various kinds.  I'd suggest something prefixed
> with RUN_  to indicate that it's used only in that specific place.


Can do! I may not have time today, but I should be able to push a revised
commit in the next couple of days.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

Hello everyone,

I just pushed a commit that sets up 512-byte alignment for x86-64
architectures. It only uses 512 bytes for x86-64; for all others it sticks
with the default of 16 bytes. I ran the tests on my BeagleBone Black with
the original alignment and saw no performance issues, so decided to keep
the change conservative. After all, TCC is known for producing small
executables, so I don't want to bloat to 512 bytes unless I have a good
reason. I know little in this area, though, so feel free to make the
setting more general if it is better that way.

I am not sure if this quite follows the project practices. I define
SECTION_ALIGNMENT just prior to the function tcc_relocate_ex. If anybody
can think of a better place to put it, to keep useful things in one place,
please move it.

I would appreciate if anybody who had slowdowns could test again with this
latest commit. Also, do we have any other architectures with benchmarks
that might suggest different alignments for those?

Thanks!
David

On Fri, Jan 6, 2017 at 12:47 AM, KHMan <keinh...@gmail.com> wrote:

> On 1/6/2017 11:44 AM, David Mertens wrote:
>
>> Spot on, grischka!
>>
>> Initial experiments indicate that changing the offset alignment
>> from 16 to 512 bytes (i.e. 15 to 511) solves this problem. I'll
>> try a few more experiments to be sure, though. I suspect that this
>> number should be tuned to the underlying architecture, but that's
>> not central to the discussion.
>>
>
> One thing that can trash I$ and D$ this way, a smart prefetcher... Any
> newish CPU could be susceptible.
>
> David
>>
>> On Thu, Jan 5, 2017 at 6:46 PM, grischka wrote:
>>
>> You might try larger "section alignment" for -run:
>>
>> in tccrun.c:208 instead of
>>  offset = (offset + 15) & ~15;
>> for example
>>  offset = (offset + 63) & ~63;
>>
>> This would add more space between your "foo" data variable and
>> the instructions in memory
>>
>> --- grischka
>>
>>
>> Harry van Haaren wrote:
>>
>> On Thu, Jan 5, 2017 at 2:12 PM, avih <avih...@yahoo.com
>> <mailto:avih...@yahoo.com>> wrote:
>>
>> I can reproduce x30 variations on Windows with tcc64
>> (built either using
>>
>> gcc (mingw) or using tcc64 itself), but for me -DNOPS=2 or
>> 5 or 9 are fast,
>> and the others (up to 9) are slow. I didn't check further.
>>
>> I also removed the #include  since it's not
>> where tcc typically
>>
>> is, and it's not required as far as I can tell, and also
>> removed the -B
>> thingy (the tcc binary is in the distribution dir on
>> windows and its
>> default -B location doesn't include anything other than tcc
>> files/libs/includes).
>>
>> Same here, removed the stdio include and -B. flag, tcc
>> version 0.9.26
>> (x86-64 Linux), recent desktop CPU:
>> Results (below), even NOPS are bad, odd NOPS are good up
>> to 8, then it
>> becomes unpredictable.
>>
>> Hope that helps, -Harry
>>
>> PS: My first post to TCC list - awesome project - thanks
>> all! :)
>>
>>
>> time tcc -DNOPS=0 -run test.c
>> real0m1.015s
>>
>> time tcc -DNOPS=1 -run test.c
>> real0m0.043s
>>
>> time tcc -DNOPS=2 -run test.c
>> real0m1.215s
>>
>> time tcc -DNOPS=3 -run test.c
>> real0m0.037s
>>
>> time tcc -DNOPS=4 -run test.c
>> real0m1.008s
>>
>> time tcc -DNOPS=5 -run test.c
>> real0m0.051s
>>
>> time tcc -DNOPS=6 -run test.c
>> real0m1.010s
>>
>> time tcc -DNOPS=7 -run test.c
>> real0m0.036s
>>
>> time tcc -DNOPS=8 -run test.c
>> real0m1.014s
>>
>> time tcc -DNOPS=9 -run test.c
>>     real0m1.112s
>>
>> time tcc -DNOPS=10 -run test.c
>> real0m0.041s
>>
>> time tcc -DNOPS=11 -run test.c
>> real0m1.161s
>>
>> time tcc -DNOPS=12 -run test.c
>> real0m0.039s
>>
>> time tcc -DNOPS=13 -run test.c
>> real0m1.482s
>>
>> time tcc -DNOPS=14 -run test.c
>> real0m1.009s
>>
>

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

Spot on, grischka!

Initial experiments indicate that changing the offset alignment from 16 to
512 bytes (i.e. 15 to 511) solves this problem. I'll try a few more
experiments to be sure, though. I suspect that this number should be tuned
to the underlying architecture, but that's not central to the discussion.

David

On Thu, Jan 5, 2017 at 6:46 PM, grischka <gris...@gmx.de> wrote:

> You might try larger "section alignment" for -run:
>
> in tccrun.c:208 instead of
> offset = (offset + 15) & ~15;
> for example
> offset = (offset + 63) & ~63;
>
> This would add more space between your "foo" data variable and
> the instructions in memory
>
> --- grischka
>
>
> Harry van Haaren wrote:
>
>> On Thu, Jan 5, 2017 at 2:12 PM, avih <avih...@yahoo.com> wrote:
>>
>>> I can reproduce x30 variations on Windows with tcc64 (built either using
>>>
>> gcc (mingw) or using tcc64 itself), but for me -DNOPS=2 or 5 or 9 are
>> fast,
>> and the others (up to 9) are slow. I didn't check further.
>>
>>> I also removed the #include  since it's not where tcc typically
>>>
>> is, and it's not required as far as I can tell, and also removed the -B
>> thingy (the tcc binary is in the distribution dir on windows and its
>> default -B location doesn't include anything other than tcc
>> files/libs/includes).
>>
>> Same here, removed the stdio include and -B. flag, tcc version 0.9.26
>> (x86-64 Linux), recent desktop CPU:
>> Results (below), even NOPS are bad, odd NOPS are good up to 8, then it
>> becomes unpredictable.
>>
>> Hope that helps, -Harry
>>
>> PS: My first post to TCC list - awesome project - thanks all! :)
>>
>>
>> time tcc -DNOPS=0 -run test.c
>> real0m1.015s
>>
>> time tcc -DNOPS=1 -run test.c
>> real0m0.043s
>>
>> time tcc -DNOPS=2 -run test.c
>> real0m1.215s
>>
>> time tcc -DNOPS=3 -run test.c
>> real0m0.037s
>>
>> time tcc -DNOPS=4 -run test.c
>> real0m1.008s
>>
>> time tcc -DNOPS=5 -run test.c
>> real0m0.051s
>>
>> time tcc -DNOPS=6 -run test.c
>> real0m1.010s
>>
>> time tcc -DNOPS=7 -run test.c
>> real0m0.036s
>>
>> time tcc -DNOPS=8 -run test.c
>> real0m1.014s
>>
>> time tcc -DNOPS=9 -run test.c
>> real0m1.112s
>>
>> time tcc -DNOPS=10 -run test.c
>> real0m0.041s
>>
>> time tcc -DNOPS=11 -run test.c
>> real0m1.161s
>>
>> time tcc -DNOPS=12 -run test.c
>> real0m0.039s
>>
>> time tcc -DNOPS=13 -run test.c
>> real0m1.482s
>>
>> time tcc -DNOPS=14 -run test.c
>> real0m1.009s
>>
>> time tcc -DNOPS=15 -run test.c
>> real0m1.506s
>>
>> time tcc -DNOPS=16 -run test.c
>> real0m1.005s
>>
>>
>>
>>
>>> On Thursday, January 5, 2017 3:25 PM, David Mertens <
>>>
>> dcmertens.p...@gmail.com> wrote:
>>
>>>
>>> Hello everyone,
>>>
>>> I have now written a very simple C program which gives highly erratic
>>>
>> timing behavior when run under tcc -run. I have added this file to the
>> gist; look for cache-test-simple.c here: https://gist.github.com/
>> run4flat/
>> fcbb6480275b1b9dcaa7a8d3a80846 38
>>
>>> The simple program does not attempt to produce a shared object library,
>>>
>> and so should be runnable on any operating system that supports tcc -run,
>> including Windows and Mac in addition to Linux. Here are some sample
>> outputs on my machine:
>>
>>> $ time ./tcc -B. -DNOPS=0 -run cache-test-simple.c
>>> real0m0.052s
>>> $ time ./tcc -B. -DNOPS=1 -run cache-test-simple.c  ***
>>> real0m1.413s
>>> $ time ./tcc -B. -DNOPS=2 -run cache-test-simple.c
>>> real0m0.069s
>>> $ time ./tcc -B. -DNOPS=3 -run cache-test-simple.c
>>> real0m0.076s
>>> $ time ./tcc -B. -DNOPS=4 -run cache-test-simple.c  ***
>>> real0m1.158s
>>>
>>> The starred results are over an order of magnitude slower than the
>>>
>> unstarred results.
>>
>>> 1) Do others see this on other operating systems with 64-bit Intel
>>>
>> processors?
>>
>>> 2) Do others see this on any operating system with 64-bit AMD processors?
>>> 3) Do others see this on any operating system with any other
>>> architecture?
>>>
>>> Thanks!
>>> David
>>

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

Hello everyone,

I have now written a very simple C program which gives highly erratic
timing behavior when run under tcc -run. I have added this file to the
gist; look for cache-test-simple.c here: https://gist.github.com/run4flat/
fcbb6480275b1b9dcaa7a8d3a8084638

The simple program does not attempt to produce a shared object library, and
so should be runnable on any operating system that supports tcc -run,
including Windows and Mac in addition to Linux. Here are some sample
outputs on my machine:

$ time ./tcc -B. -DNOPS=0 -run cache-test-simple.c
real0m0.052s
$ time ./tcc -B. -DNOPS=1 -run cache-test-simple.c  ***
real0m1.413s
$ time ./tcc -B. -DNOPS=2 -run cache-test-simple.c
real0m0.069s
$ time ./tcc -B. -DNOPS=3 -run cache-test-simple.c
real0m0.076s
$ time ./tcc -B. -DNOPS=4 -run cache-test-simple.c  ***
real0m1.158s

The starred results are over an order of magnitude slower than the
unstarred results.

1) Do others see this on other operating systems with 64-bit Intel
processors?
2) Do others see this on any operating system with 64-bit AMD processors?
3) Do others see this on any operating system with any other architecture?

Thanks!
David

On Thu, Jan 5, 2017 at 12:59 AM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Update: I *can* get this slowdown with tcc. The main trigger is to have a
> global variable that gets modified by the function.
>
> I have updated the gist: https://gist.github.com/run4flat/
> fcbb6480275b1b9dcaa7a8d3a8084638
>
> This program generates a single function filled with a collection of
> skipped operations (number of operations is a command-line option) and
> finished with a modification of a global variable. It compiles the function
> using tcc, then calls the function a specified number of times (repeat
> count specified via command-line). It can either generate code in-memory,
> or it can generate a .so file and load that using dlopen. (If it generates
> in-memory, it prints the size of the generated code.)
>
> Here are the interesting results on my machine, all for 10,000,000
> iterations, using compilation-in-memory:
>
> N   Code Size (Bytes)   Time (s)
> 0 128   2.52
> 1 144   2.54
> 2 176   2.57
> 3 208   0.035
> 4 224   0.058
> 5 256   2.57
> 6 272   0.060
>
> Switching over to a shared object file, I get these results (code size is
> size of the .so file):
> N   Code Size (Bytes)   Time (s)
> 02960   0.057
> 12984   0.040
> 23016   0.058
> 33040   0.039
> 43064   0.040
> 53088   0.060
> 63112   0.063
>
> As you can see, the jit-compiled code has odd jumps of 30x speed drops
> depending on... something. The shared object file, on the other hand, has
> consistently sound performance.
>
> Two questions:
> 1) Can anybody reproduce these effects on their Linux machines, especially
> different architectures? (I can try an ARM tomorrow.)
> 2) Is there something special about how tcc builds a shared object file
> that is not happening with the jit-compiled code?
>
> Thanks!
> David
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

Update: I *can* get this slowdown with tcc. The main trigger is to have a
global variable that gets modified by the function.

I have updated the gist:
https://gist.github.com/run4flat/fcbb6480275b1b9dcaa7a8d3a8084638

This program generates a single function filled with a collection of
skipped operations (number of operations is a command-line option) and
finished with a modification of a global variable. It compiles the function
using tcc, then calls the function a specified number of times (repeat
count specified via command-line). It can either generate code in-memory,
or it can generate a .so file and load that using dlopen. (If it generates
in-memory, it prints the size of the generated code.)

Here are the interesting results on my machine, all for 10,000,000
iterations, using compilation-in-memory:

N   Code Size (Bytes)   Time (s)
0 128   2.52
1 144   2.54
2 176   2.57
3 208   0.035
4 224   0.058
5 256   2.57
6 272   0.060

Switching over to a shared object file, I get these results (code size is
size of the .so file):
N   Code Size (Bytes)   Time (s)
02960   0.057
12984   0.040
23016   0.058
33040   0.039
43064   0.040
53088   0.060
63112   0.063

As you can see, the jit-compiled code has odd jumps of 30x speed drops
depending on... something. The shared object file, on the other hand, has
consistently sound performance.

Two questions:
1) Can anybody reproduce these effects on their Linux machines, especially
different architectures? (I can try an ARM tomorrow.)
2) Is there something special about how tcc builds a shared object file
that is not happening with the jit-compiled code?

Thanks!
David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

Bah, it looks like the situation is not as simple as I had hoped. Here is
the code I wrote to try (unsuccessfully) to emulate the problem:
https://gist.github.com/run4flat/fcbb6480275b1b9dcaa7a8d3a8084638

This executable uses libtcc to jit-compile a chunk of C code with varying
length, then call the generated function a variable number of cycles. The
only way to go off the icache cliff is to produce a function with over 3000
increment/decrement operations. Going from 2000 to 3000 causes the icache
miss rate to increase by a factor of 100. However, there is no measurable
performance degradation: the computational time increases as O(N).

This is good, I suppose. It means that any performance gains to be had are
on my end, not on tcc. For my original problem, I suspect that there are
icache conflicts between Perl's object code and the jit-compiled stuff, or
(as Edmund suggests) false cache invalidations due to adjacent data updates.

David

On Wed, Dec 21, 2016 at 2:39 AM, Christian Jullien  wrote:

> No!
> M2 mode generates a pseudo assembler Lisp code like:
>
>   ((fentry fib 1 0 0)
>(param 0)
>(jeq _l004 '1)
>(jneq _l003 '2)
>(move a1 '1)
>(return)
>   _l003
>(gsub1 a1)
> ...
>
> Each instruction is translated into an encoded integer (OpenLisp specific)
> and goes to a vector which corresponds to compiled code.
> This vector is interpreted with a state machine working much like a
> processor using a BIG switch
>
> JNEQ above is interpreted using:
>
> for( ;; ) {
> nextinst:
> inst = ((FIXPTR)opcode[ pc++ ]) >> 4;
>
> switch( olopcode( inst ) ) {
> case LAP_FENTRY:
> /*
>  * LEN = 3 : 00 | type |  |  | 
>  *
>  * information only,  should not be executed.
>  * x  is the number of required arguments and
>  * y  is flag used when function has  or
>  *:rest argument.
>  * z  is the number of local paramters.
>  */
> OLLAPNEXT;
> ...
> case LAP_JNEQ:
> /*
>  * LEN = 1 : 5C xx xx obj
>  *
>  * where xx is the next address and obj an
> immediate.
>  */
> ollapinton();
>
> if( a1 != opcode[ pc++ ] ) {
> pc = (int)olushortarg( inst );
> }
> OLLAPNEXT;
>
> M3 takes M2 pseudo code and generates pure C code which is statically
> compiled (as a standard .c file).
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=
> orange...@nongnu.org]
> On Behalf Of Edmund Grimley Evans
> Sent: mercredi 21 décembre 2016 08:26
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Huge swings in cache performance
>
> Are you dynamically generating code on Intel? But presumably the
> dynamically
> generated code is not inside your loop? However, if your dynamically
> generated code is adjacent in memory to some data that gets modified, then
> it could be (I have no idea how this stuff works on Intel) that the
> processor thinks that the code may have been modified, even though it
> hasn't
> been modified, and invalidates the cache just in case. And this phenomenon
> would be very sensitive to the precise layout. The solution might be to put
> the dynamically generated code in a block of memory that is separately
> allocated with mmap. On the other hand, if you're already doing that,
> probably this isn't the explanation.
>
> Edmund
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

I forgot to mention: the function in question is a simple random number
generator. It only contains 32-bit integer math operations, and does not
contain any loops. For this benchmark, the looping occurs at the Perl
level, so alignment optimizations for looping would not be important here.
(This lets me compare many different Perl-to-C function invocation
approaches to assess their speed.)

On Tue, Dec 20, 2016 at 10:44 PM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Discussion about alignment and execution speed for the Haskell compiler:
> https://ghc.haskell.org/trac/ghc/ticket/8279
>
> This discussion mentions why things should be aligned, and gives some
> multi-byte no-ops that can be used for padding for aligned loops.
> http://stackoverflow.com/questions/18113995/performance-optimisations-of-
> x86-64-assembly-alignment-and-branch-prediction
>
> I came across a similar issue a few weeks ago, but I was able to "fix" it
> by allocating more memory than I needed and then relocating to an address
> within that allocation that was aligned to the start of a page. This seemed
> to fix the problem back then, but this new flavor of alignment woes is
> impervious to such a trick.
>
> David
>
> On Tue, Dec 20, 2016 at 10:29 PM, KHMan <keinh...@gmail.com> wrote:
>
>> On 12/20/2016 10:17 PM, David Mertens wrote:
>>
>>> Hello Kein-Hong,
>>>
>>> I'm not convinced this is entirely an unpredictable hardware
>>> issue. The reason is that I can easily create similar
>>> functionality with gcc (the usual Perl XS module, the normal means
>>> for writing a C-based extension) and it does not show these kinds
>>> of cache swings. I think there is something gcc does while
>>> producing its machine code that makes it less susceptible to cache
>>> misses. (Well, there are lots of things it does, I'm sure.) I'm
>>> hoping there's one or two simple things that gcc does which tcc
>>> misses and could implement.
>>>
>>> Was the behavior observed with Lua noted when working with JIT?
>>>
>>
>> I couldn't find the old posting but it was along the lines of benchmark
>> variability due to memory layout, see "Mytkowicz memory layout". IIRC, the
>> discussion was about a small benchmark Lua script running the interpreter,
>> in one posting, changing an environment variable changed the program's
>> total running time significantly, IIRC it was in the 20-50% range. The
>> timings were done casually and nobody did detailed follow-up research.
>>
>> ... which of course are the same executables and is different from your
>> case. Long day and all. But tcc is not much of an optimizing compiler, if
>> the change caused register spilling in an inner loop it would hammer memory
>> access and account for at least some of the effects...
>>
>>
>> On Tue, Dec 20, 2016 at 9:05 AM, KHMan wrote:
>>>
>>> On 12/20/2016 9:16 PM, David Mertens wrote:
>>>
>>> Hello everyone,
>>>
>>> Reminder/Background: C::Blocks is my Perl wrapper around
>>> my fork
>>> of tcc with extended symbol table support.
>>>
>>> I've begun writing benchmarks to seriously test how C::Blocks
>>> compares with other JIT and JIT-ish options for Perl. I've
>>> noticed
>>> a couple of situations in which slight modifications to
>>> the code
>>> cause a huge drop in performance. One benchmark went from
>>> 370ms to
>>> 5,000ms (i.e. 5 sec).
>>>
>>> The change to the code was so slight that I immediately
>>> suspected
>>> cache misses as the culprit. Running with linux's "perf"
>>> command
>>> gave proof of that (hopefully this format properly with
>>> fixed-width characters):
>>>
>>> FastSlow  Significant
>>> time (ms)  3705022**
>>> instructions  3.5B3.5B
>>> branches  640M650M
>>> branch-miss   687k671k
>>> dcache-miss   974k 71M**
>>> icache-miss   3.2M 83M**
>>>
>>> By dcache-miss I refer to what perf calls "L1 dcache load
>>> miss",
>>> and by icache-miss I refer to what perf calls "L1 icache
>>> load miss".
>>>
>>> I'm a bit confused on what would cause this sort of persistent
>>>

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

Discussion about alignment and execution speed for the Haskell compiler:
https://ghc.haskell.org/trac/ghc/ticket/8279

This discussion mentions why things should be aligned, and gives some
multi-byte no-ops that can be used for padding for aligned loops.
http://stackoverflow.com/questions/18113995/performance-optimisations-of-x86-64-assembly-alignment-and-branch-prediction

I came across a similar issue a few weeks ago, but I was able to "fix" it
by allocating more memory than I needed and then relocating to an address
within that allocation that was aligned to the start of a page. This seemed
to fix the problem back then, but this new flavor of alignment woes is
impervious to such a trick.

David

On Tue, Dec 20, 2016 at 10:29 PM, KHMan <keinh...@gmail.com> wrote:

> On 12/20/2016 10:17 PM, David Mertens wrote:
>
>> Hello Kein-Hong,
>>
>> I'm not convinced this is entirely an unpredictable hardware
>> issue. The reason is that I can easily create similar
>> functionality with gcc (the usual Perl XS module, the normal means
>> for writing a C-based extension) and it does not show these kinds
>> of cache swings. I think there is something gcc does while
>> producing its machine code that makes it less susceptible to cache
>> misses. (Well, there are lots of things it does, I'm sure.) I'm
>> hoping there's one or two simple things that gcc does which tcc
>> misses and could implement.
>>
>> Was the behavior observed with Lua noted when working with JIT?
>>
>
> I couldn't find the old posting but it was along the lines of benchmark
> variability due to memory layout, see "Mytkowicz memory layout". IIRC, the
> discussion was about a small benchmark Lua script running the interpreter,
> in one posting, changing an environment variable changed the program's
> total running time significantly, IIRC it was in the 20-50% range. The
> timings were done casually and nobody did detailed follow-up research.
>
> ... which of course are the same executables and is different from your
> case. Long day and all. But tcc is not much of an optimizing compiler, if
> the change caused register spilling in an inner loop it would hammer memory
> access and account for at least some of the effects...
>
>
> On Tue, Dec 20, 2016 at 9:05 AM, KHMan wrote:
>>
>> On 12/20/2016 9:16 PM, David Mertens wrote:
>>
>> Hello everyone,
>>
>> Reminder/Background: C::Blocks is my Perl wrapper around
>> my fork
>> of tcc with extended symbol table support.
>>
>> I've begun writing benchmarks to seriously test how C::Blocks
>> compares with other JIT and JIT-ish options for Perl. I've
>> noticed
>> a couple of situations in which slight modifications to
>> the code
>> cause a huge drop in performance. One benchmark went from
>> 370ms to
>> 5,000ms (i.e. 5 sec).
>>
>> The change to the code was so slight that I immediately
>> suspected
>> cache misses as the culprit. Running with linux's "perf"
>> command
>> gave proof of that (hopefully this format properly with
>> fixed-width characters):
>>
>> FastSlow  Significant
>> time (ms)  3705022**
>> instructions  3.5B3.5B
>> branches  640M650M
>> branch-miss   687k671k
>> dcache-miss   974k 71M**
>> icache-miss   3.2M 83M**
>>
>> By dcache-miss I refer to what perf calls "L1 dcache load
>> miss",
>> and by icache-miss I refer to what perf calls "L1 icache
>> load miss".
>>
>> I'm a bit confused on what would cause this sort of persistent
>> cache miss behavior. In particular, I've tried working
>> with highly
>> distinct strategies for managing executable memory, including
>> ensuring page alignment (wrong: it should be line-width
>> alignment
>> of 64 bytes). This fixed a similar issue previously
>> observed, but
>> didn't seem to improve the situation here. I used malloc
>> instead
>> of Perl's built-in memory allocator. I created a pool for
>> executable memory so that multiple chunks of executable
>> code would
>> all be written to the same page in memory. EVEN THIS did
>> not fix
>> this issue, which really surprised me since I would have
>> thought
>>  

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

Hello Kein-Hong,

I'm not convinced this is entirely an unpredictable hardware issue. The
reason is that I can easily create similar functionality with gcc (the
usual Perl XS module, the normal means for writing a C-based extension) and
it does not show these kinds of cache swings. I think there is something
gcc does while producing its machine code that makes it less susceptible to
cache misses. (Well, there are lots of things it does, I'm sure.) I'm
hoping there's one or two simple things that gcc does which tcc misses and
could implement.

Was the behavior observed with Lua noted when working with JIT?

David

On Tue, Dec 20, 2016 at 9:05 AM, KHMan <keinh...@gmail.com> wrote:

> On 12/20/2016 9:16 PM, David Mertens wrote:
>
>> Hello everyone,
>>
>> Reminder/Background: C::Blocks is my Perl wrapper around my fork
>> of tcc with extended symbol table support.
>>
>> I've begun writing benchmarks to seriously test how C::Blocks
>> compares with other JIT and JIT-ish options for Perl. I've noticed
>> a couple of situations in which slight modifications to the code
>> cause a huge drop in performance. One benchmark went from 370ms to
>> 5,000ms (i.e. 5 sec).
>>
>> The change to the code was so slight that I immediately suspected
>> cache misses as the culprit. Running with linux's "perf" command
>> gave proof of that (hopefully this format properly with
>> fixed-width characters):
>>
>>FastSlow  Significant
>> time (ms)  3705022**
>> instructions  3.5B3.5B
>> branches  640M650M
>> branch-miss   687k671k
>> dcache-miss   974k 71M**
>> icache-miss   3.2M 83M**
>>
>> By dcache-miss I refer to what perf calls "L1 dcache load miss",
>> and by icache-miss I refer to what perf calls "L1 icache load miss".
>>
>> I'm a bit confused on what would cause this sort of persistent
>> cache miss behavior. In particular, I've tried working with highly
>> distinct strategies for managing executable memory, including
>> ensuring page alignment (wrong: it should be line-width alignment
>> of 64 bytes). This fixed a similar issue previously observed, but
>> didn't seem to improve the situation here. I used malloc instead
>> of Perl's built-in memory allocator. I created a pool for
>> executable memory so that multiple chunks of executable code would
>> all be written to the same page in memory. EVEN THIS did not fix
>> this issue, which really surprised me since I would have thought
>> adjacent memory would hash to different caches.
>>
>> I believe that what I've found is an issue with tcc, but I haven't
>> golfed it down to a simple libtcc-consuming example. I can do
>> that, but wanted to see if anybody could think of an obvious
>> cause, and fix, without going to such lengths. If not, I will see
>> if I can write a small reproducible example.
>>
>
> This kind of behaviour was discussed on the Lua list not long ago. IIRC,
> for example changing environment variables changed the way a program is
> loaded, and the timing changed. Probably cache behaviour. It's like, what
> can we really benchmark anymore?
>
> When modern GHz parts have cache misses and need to access main memory,
> they cause such train wrecks that everybody seems to be moving or have
> already moved to neural network-based (perceptron *cough*) branch
> prediction.
>
> So well, how do we scientifically or meaningfully benchmark these days,
> that is the question... (especially for folks in academic needing to
> justify benchmark results...)
>
> --
> Cheers,
> Kein-Hong Man (esq.)
> Selangor, Malaysia
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Huge swings in cache performance

[David Mertens]

I forgot to mention: all of this is based on tcc prior to Michael's latest
work.

On Tue, Dec 20, 2016 at 8:16 AM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Hello everyone,
>
> Reminder/Background: C::Blocks is my Perl wrapper around my fork of tcc
> with extended symbol table support.
>
> I've begun writing benchmarks to seriously test how C::Blocks compares
> with other JIT and JIT-ish options for Perl. I've noticed a couple of
> situations in which slight modifications to the code cause a huge drop in
> performance. One benchmark went from 370ms to 5,000ms (i.e. 5 sec).
>
> The change to the code was so slight that I immediately suspected cache
> misses as the culprit. Running with linux's "perf" command gave proof of
> that (hopefully this format properly with fixed-width characters):
>
>   FastSlow  Significant
> time (ms)  3705022**
> instructions  3.5B3.5B
> branches  640M650M
> branch-miss   687k671k
> dcache-miss   974k 71M**
> icache-miss   3.2M 83M**
>
> By dcache-miss I refer to what perf calls "L1 dcache load miss", and by
> icache-miss I refer to what perf calls "L1 icache load miss".
>
> I'm a bit confused on what would cause this sort of persistent cache miss
> behavior. In particular, I've tried working with highly distinct strategies
> for managing executable memory, including ensuring page alignment (wrong:
> it should be line-width alignment of 64 bytes). This fixed a similar issue
> previously observed, but didn't seem to improve the situation here. I used
> malloc instead of Perl's built-in memory allocator. I created a pool for
> executable memory so that multiple chunks of executable code would all be
> written to the same page in memory. EVEN THIS did not fix this issue, which
> really surprised me since I would have thought adjacent memory would hash
> to different caches.
>
> I believe that what I've found is an issue with tcc, but I haven't golfed
> it down to a simple libtcc-consuming example. I can do that, but wanted to
> see if anybody could think of an obvious cause, and fix, without going to
> such lengths. If not, I will see if I can write a small reproducible
> example.
>
> Thanks!
> David
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Huge swings in cache performance

[David Mertens]

Hello everyone,

Reminder/Background: C::Blocks is my Perl wrapper around my fork of tcc
with extended symbol table support.

I've begun writing benchmarks to seriously test how C::Blocks compares with
other JIT and JIT-ish options for Perl. I've noticed a couple of situations
in which slight modifications to the code cause a huge drop in performance.
One benchmark went from 370ms to 5,000ms (i.e. 5 sec).

The change to the code was so slight that I immediately suspected cache
misses as the culprit. Running with linux's "perf" command gave proof of
that (hopefully this format properly with fixed-width characters):

  FastSlow  Significant
time (ms)  3705022**
instructions  3.5B3.5B
branches  640M650M
branch-miss   687k671k
dcache-miss   974k 71M**
icache-miss   3.2M 83M**

By dcache-miss I refer to what perf calls "L1 dcache load miss", and by
icache-miss I refer to what perf calls "L1 icache load miss".

I'm a bit confused on what would cause this sort of persistent cache miss
behavior. In particular, I've tried working with highly distinct strategies
for managing executable memory, including ensuring page alignment (wrong:
it should be line-width alignment of 64 bytes). This fixed a similar issue
previously observed, but didn't seem to improve the situation here. I used
malloc instead of Perl's built-in memory allocator. I created a pool for
executable memory so that multiple chunks of executable code would all be
written to the same page in memory. EVEN THIS did not fix this issue, which
really surprised me since I would have thought adjacent memory would hash
to different caches.

I believe that what I've found is an issue with tcc, but I haven't golfed
it down to a simple libtcc-consuming example. I can do that, but wanted to
see if anybody could think of an obvious cause, and fix, without going to
such lengths. If not, I will see if I can write a small reproducible
example.

Thanks!
David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Compound literals not working in function calls

[David Mertens]

Here is a simple implementation of named arguments in a function call:

http://stackoverflow.com/questions/2826128/variadic-functions-and-arguments-assignment-in-c-c/2828263#2828263

This relies on compound literals, which I thought tcc supported. For
example, see http://repo.or.cz/tinycc.git/blob/HEAD:/tests/tcctest.c#l1407;
see also line 1447 in the same file.

Is this something that used to work and somehow slipped? Shall I run git
bisect on it?

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Linux port is broken with multi-arch

[David Mertens]

Hello Christian,

Not that I would be able to help, but I imagine that git bisect could help
us pinpoint the commit that led to the problem. I would run it, but I don't
have (or know how to setup) a multi-arch system for testing this.

David

On Mon, Nov 28, 2016 at 12:32 AM, Christian Jullien 
wrote:

> Hi Ramsay,
>
>
>
> For sure I ran ./configure. I did it zillions of times in the past on many
> different 32/64 platforms. I just tested this morning on my old RHEL 6.5
> reference platform which is also configure with multi-arch.
>
> And guess what, it is also broken which is new!
>
>
>
> Here is the result of what you suggested from Fedora 25 x86_64:
>
>
>
> [jullien@fedora tinycc]$ ./configure
>
> Binary  directory   /usr/local/bin
>
> TinyCC directory/usr/local/lib/tcc
>
> Library directory   /usr/local/lib
>
> Include directory   /usr/local/include
>
> Manual directory/usr/local/share/man
>
> Info directory  /usr/local/share/info
>
> Doc directory   /usr/local/share/doc
>
> Target root prefix  -
>
> Source path /home/jullien/tinycc
>
> C compiler  gcc
>
> Target OS   Linux
>
> CPU x86-64
>
> Big Endian  no
>
> Profiling   no
>
> Cross compilers no
>
> Use libgcc  no
>
> Triplet -
>
> Creating config.mak and config.h
>
>
>
>
>
> [jullien@fedora tinycc]$ more config.mak
>
> # Automatically generated by configure - do not modify
>
> prefix=/usr/local
>
> bindir=$(DESTDIR)/usr/local/bin
>
> tccdir=$(DESTDIR)/usr/local/lib/tcc
>
> libdir=$(DESTDIR)/usr/local/lib
>
> ln_libdir=/usr/local/lib
>
> includedir=$(DESTDIR)/usr/local/include
>
> mandir=$(DESTDIR)/usr/local/share/man
>
> infodir=$(DESTDIR)/usr/local/share/info
>
> docdir=$(DESTDIR)/usr/local/share/doc
>
> CC=gcc
>
> GCC_MAJOR=6
>
> GCC_MINOR=2
>
> AR=ar
>
> STRIP=strip -s -R .comment -R .note
>
> CFLAGS=-Wall -g -O2 -Wdeclaration-after-statement
> -Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
> -Wno-sign-compare -Wno-unused-result -Wno-uninitialized -fno-strict-aliasing
>
> LDFLAGS=
>
> LIBSUF=.a
>
> EXESUF=
>
> ARCH=x86-64
>
> TARGETOS=Linux
>
> VERSION = 0.9.26
>
> TOPSRC=$(TOP)
>
>
>
> [jullien@fedora tinycc]$ more config.h
>
> /* Automatically generated by configure - do not modify */
>
> #ifndef CONFIG_TCCDIR
>
> # define CONFIG_TCCDIR "/usr/local/lib/tcc"
>
> #endif
>
> #define GCC_MAJOR 6
>
> #define GCC_MINOR 2
>
>
>
> jullien@fedora tinycc]$ gcc conftest.c -o conftest && ./conftest t
>
> x86_64-linux-gnu
>
> [jullien@fedora tinycc]$
>
>
>
>
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=
> orange...@nongnu.org] On Behalf Of Ramsay Jones
> Sent: dimanche 27 novembre 2016 21:49
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Linux port is broken with multi-arch
>
>
>
>
>
>
>
> On 27/11/16 20:35, Ramsay Jones wrote:
>
> > On 27/11/16 15:55, Christian Jullien wrote:
>
> >> Triplet -
>
> >
>
> > This looks odd. Did you run ./configure?
>
> > You also don't appear to have CONFIG_TRIPLET set in your config.mak
>
> > file.
>
> >
>
> > [I would expect Triplet to be reported as 'x86_64-linux-gnu'
>
> > and your config.mak file to have a line similar to:
>
> >
>
> > NATIVE_DEFINES+=-DCONFIG_TRIPLET="\"x86_64-linux-gnu\""
>
> >
>
> > somewhere.]
>
>
>
> BTW, I forgot to suggest trying:
>
>
>
> $ gcc -o conftest conftest.c
>
> $ ./conftest t
>
>
>
> to see what it returns for the triplet. (Then check that the 'crt'
>
> object files are to be found in /usr/lib//).
>
>
>
> ATB,
>
> Ramsay Jones
>
>
>
>
>
> ___
>
> Tinycc-devel mailing list
>
> Tinycc-devel@nongnu.org
>
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] libtcc using existing structs

[David Mertens]

Hello Joel,

tcc_add_file() probably won't work for what you're trying to use it for.
The simplest way I can think to fix this problem is to #include the file
that contains the struct declaration.

Hope that helps!
David

On Sun, Nov 6, 2016 at 11:23 AM, Joel Bodenmann  wrote:

> Hello folks,
>
> I am successfully using libtcc to compile & link single C functions
> on-the-fly. Everything works great for those small C functions which don't
> do anything other than calling other functions which are already part of
> the
> program that uses libtcc. I simply use tcc_add_symbol() to make those
> functions become available to the compiled function.
> However, now I am facing issues when I try to compile C code that creates
> an
> instance of a struct. For example, I try to compile a C program that
> creates
> an instance of a struct named foo:
>
> struct foo f;
>
> the struct "foo" is part of the already compiled program (the program that
> uses libtcc to compile that smaller C program). The problem is that
> compiling using tcc_compile_string() fails with the error message: "error:
> unknown type size" at exactly that line. I understand that the compiler has
> to know the declaration of the struct foo in order to work with it,
> however,
> I fail to understand how I give TCC access to that struct declaration? I
> tried using supplying the header file that contains the declaration of the
> struct foo to TCC using tcc_add_file() but that didn't change anything at
> all.
>
> I'm a bit lost at this point and I'd be thankful for any kind of help.
> Please excuse if I am using wrong terminology somewhere.
>
>
> Best regards,
> ~ Joel
>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Patch: add option -mms-bitfields

[David Mertens]

Now this idea I like, a lot, in terms of forcing users to understand what
they're dealing with. This would also give impetus to our Windows folks to
update configure for more sensible the default selection behavior.

Thanks! Other thoughts?
David

On Tue, Nov 22, 2016 at 4:41 PM, Michael B. Smith <mich...@smithcons.com>
wrote:

> Speaking only to my personal opinion – if you are compiling on Windows,
> and the –mms-bitfields is not set and –no-ms-bitfields is not set, then you
> should issue a warning to that effect.
>
>
>
> *From:* Tinycc-devel [mailto:tinycc-devel-bounces+michael=
> theessentialexchange....@nongnu.org] *On Behalf Of *David Mertens
> *Sent:* Tuesday, November 22, 2016 4:32 PM
> *To:* tinycc-devel@nongnu.org
> *Subject:* [Tinycc-devel] Patch: add option -mms-bitfields
>
>
>
> Hello everyone,
>
> Per previous discussion, here is a patch to implement a command-line
> option, -mms-bitfields. This would alter tcc's bitfield alignment algorithm
> in a backwards-incompatible way to be a bit more consistent with gcc's
> algorithm. The old behavior is traditionally attributed to MSVC, and so
> (consistent with gcc) the command-line option to use the old behavior is
> -mms-bitfields. If this patch gets applied, Windows users would be
> encouraged to add -mms-bitfields to their Makefiles.
>
> I would appreciate comments, bug reports, etc. If you care, please give
> this a spin in the next 24 hours, or please tell me if you need more time.
> Any tests illustrating discrepancies between gcc and this algorithm would
> be especially appreciated!
>
>
>
> Thanks!
>
> David
>
> diff --git a/libtcc.c b/libtcc.c
> index f184502..b824c18 100644
> --- a/libtcc.c
> +++ b/libtcc.c
> @@ -752,6 +752,7 @@ LIBTCCAPI TCCState *tcc_new(void)
>  s->alacarte_link = 1;
>  s->nocommon = 1;
>  s->warn_implicit_function_declaration = 1;
> +s->ms_bitfields = 0;
>
>  #ifdef CHAR_IS_UNSIGNED
>  s->char_is_unsigned = 1;
> @@ -1508,6 +1509,7 @@ enum {
>  TCC_OPTION_Wl,
>  TCC_OPTION_W,
>  TCC_OPTION_O,
> +TCC_OPTION_mms_bitfields,
>  TCC_OPTION_m,
>  TCC_OPTION_f,
>  TCC_OPTION_isystem,
> @@ -1571,6 +1573,7 @@ static const TCCOption tcc_options[] = {
>  { "Wl,", TCC_OPTION_Wl, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
>  { "W", TCC_OPTION_W, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
>  { "O", TCC_OPTION_O, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
> +{ "mms-bitfields", TCC_OPTION_mms_bitfields, 0}, /* must go before
> option 'm' */
>  { "m", TCC_OPTION_m, TCC_OPTION_HAS_ARG },
>  { "f", TCC_OPTION_f, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
>  { "isystem", TCC_OPTION_isystem, TCC_OPTION_HAS_ARG },
> @@ -1854,6 +1857,9 @@ PUB_FUNC int tcc_parse_args(TCCState *s, int argc,
> char **argv)
>  if (x > 0)
>  tcc_define_symbol(s, "__OPTIMIZE__", NULL);
>  break;
> +case TCC_OPTION_mms_bitfields:
> +s->ms_bitfields = 1;
> +break;
>  case TCC_OPTION_traditional:
>  case TCC_OPTION_pedantic:
>  case TCC_OPTION_pipe:
> diff --git a/tcc-doc.texi b/tcc-doc.texi
> index 5aab13c..9f136ed 100644
> --- a/tcc-doc.texi
> +++ b/tcc-doc.texi
> @@ -176,6 +176,10 @@ In a script, it gives the following header:
>  #!/usr/local/bin/tcc -run -L/usr/X11R6/lib -lX11
>  @end example
>
> +@item -mms-bitfields
> +Use an algorithm for bitfield alignment consistent with MSVC. Default is
> +gcc's algorithm.
> +
>  @item -mfloat-abi (ARM only)
>  Select the float ABI. Possible values: @code{softfp} and @code{hard}
>
> diff --git a/tcc.c b/tcc.c
> index 28f3ae9..fbfbffa 100644
> --- a/tcc.c
> +++ b/tcc.c
> @@ -97,6 +97,7 @@ static void help(void)
> "  -o outfile  set output filename\n"
> "  -runrun compiled source\n"
> "  -fflag  set or reset (with 'no-' prefix) 'flag' (see
> man page)\n"
> +   "  -mms-bitfields  use bitfield alignment consistent with
> MSVC\n"
> "  -Wwarning   set or reset (with 'no-' prefix) 'warning' (see
> man page)\n"
> "  -w  disable all warnings\n"
> "  -v  show version\n"
> diff --git a/tcc.h b/tcc.h
> index 180838d..cbdebd3 100644
> --- a/tcc.h
> +++ b/tcc.h
> @@ -605,6 +605,7 @@ struct TCCState {
>  int old_struct_init_code;/* use old algorithm to init array in
> struct when there is no '{' used.
> Liuux 2.4.26 can't find initrd wh

[Tinycc-devel] Patch: add option -mms-bitfields

[David Mertens]

Hello everyone,

Per previous discussion, here is a patch to implement a command-line
option, -mms-bitfields. This would alter tcc's bitfield alignment algorithm
in a backwards-incompatible way to be a bit more consistent with gcc's
algorithm. The old behavior is traditionally attributed to MSVC, and so
(consistent with gcc) the command-line option to use the old behavior is
-mms-bitfields. If this patch gets applied, Windows users would be
encouraged to add -mms-bitfields to their Makefiles.

I would appreciate comments, bug reports, etc. If you care, please give
this a spin in the next 24 hours, or please tell me if you need more time.
Any tests illustrating discrepancies between gcc and this algorithm would
be especially appreciated!

Thanks!
David

diff --git a/libtcc.c b/libtcc.c
index f184502..b824c18 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -752,6 +752,7 @@ LIBTCCAPI TCCState *tcc_new(void)
 s->alacarte_link = 1;
 s->nocommon = 1;
 s->warn_implicit_function_declaration = 1;
+s->ms_bitfields = 0;

 #ifdef CHAR_IS_UNSIGNED
 s->char_is_unsigned = 1;
@@ -1508,6 +1509,7 @@ enum {
 TCC_OPTION_Wl,
 TCC_OPTION_W,
 TCC_OPTION_O,
+TCC_OPTION_mms_bitfields,
 TCC_OPTION_m,
 TCC_OPTION_f,
 TCC_OPTION_isystem,
@@ -1571,6 +1573,7 @@ static const TCCOption tcc_options[] = {
 { "Wl,", TCC_OPTION_Wl, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "W", TCC_OPTION_W, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "O", TCC_OPTION_O, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
+{ "mms-bitfields", TCC_OPTION_mms_bitfields, 0}, /* must go before
option 'm' */
 { "m", TCC_OPTION_m, TCC_OPTION_HAS_ARG },
 { "f", TCC_OPTION_f, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "isystem", TCC_OPTION_isystem, TCC_OPTION_HAS_ARG },
@@ -1854,6 +1857,9 @@ PUB_FUNC int tcc_parse_args(TCCState *s, int argc,
char **argv)
 if (x > 0)
 tcc_define_symbol(s, "__OPTIMIZE__", NULL);
 break;
+case TCC_OPTION_mms_bitfields:
+s->ms_bitfields = 1;
+break;
 case TCC_OPTION_traditional:
 case TCC_OPTION_pedantic:
 case TCC_OPTION_pipe:
diff --git a/tcc-doc.texi b/tcc-doc.texi
index 5aab13c..9f136ed 100644
--- a/tcc-doc.texi
+++ b/tcc-doc.texi
@@ -176,6 +176,10 @@ In a script, it gives the following header:
 #!/usr/local/bin/tcc -run -L/usr/X11R6/lib -lX11
 @end example

+@item -mms-bitfields
+Use an algorithm for bitfield alignment consistent with MSVC. Default is
+gcc's algorithm.
+
 @item -mfloat-abi (ARM only)
 Select the float ABI. Possible values: @code{softfp} and @code{hard}

diff --git a/tcc.c b/tcc.c
index 28f3ae9..fbfbffa 100644
--- a/tcc.c
+++ b/tcc.c
@@ -97,6 +97,7 @@ static void help(void)
"  -o outfile  set output filename\n"
"  -runrun compiled source\n"
"  -fflag  set or reset (with 'no-' prefix) 'flag' (see man
page)\n"
+   "  -mms-bitfields  use bitfield alignment consistent with
MSVC\n"
"  -Wwarning   set or reset (with 'no-' prefix) 'warning' (see
man page)\n"
"  -w  disable all warnings\n"
"  -v  show version\n"
diff --git a/tcc.h b/tcc.h
index 180838d..cbdebd3 100644
--- a/tcc.h
+++ b/tcc.h
@@ -605,6 +605,7 @@ struct TCCState {
 int old_struct_init_code;/* use old algorithm to init array in
struct when there is no '{' used.
Liuux 2.4.26 can't find initrd when compiled with a new
algorithm */
 int dollars_in_identifiers;/* allows '$' char in indentifiers */
+int ms_bitfields; /* if true, emulate MS algorithm for aligning
bitfields */

 /* warning switches */
 int warn_write_strings;
diff --git a/tccgen.c b/tccgen.c
index ba1757e..d064024 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -3154,7 +3154,7 @@ static void parse_attribute(AttributeDef *ad)
 /* enum/struct/union declaration. u is either VT_ENUM or VT_STRUCT */
 static void struct_decl(CType *type, AttributeDef *ad, int u)
 {
-int a, v, size, align, maxalign, c, offset, flexible;
+int a, v, size, align, maxalign, c, offset, flexible, extra_bytes;
 int bit_size, bit_pos, bsize, bt, lbit_pos, prevbt;
 Sym *s, *ss, *ass, **ps;
 AttributeDef ad1;
@@ -3235,6 +3235,7 @@ static void struct_decl(CType *type, AttributeDef
*ad, int u)
 while (tok != '}') {
 parse_btype(, );
 while (1) {
+extra_bytes = 0;
 if (flexible)
 tcc_error("flexible array member '%s' not at the end of
struct",
   get_tok_str(v, NULL));
@@ -3310,9 +3311,9 @@ static void struct_decl(CType *type, AttributeDef
*ad, int u)
 /* zero size: means to pad */
 bit_pos = 0;
 } else {
-/* we do not have enough room ?
-   did the type change?
-  

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[David Mertens]

Hello avih,

In short, very little is expected to break. Very few libraries present a
public API susceptible to this sort of problem. The linked discussion
mentions that this could be an issue with GTK+ v2, which apparently exposes
these sorts of bitfields in its public API. Obviously parts of the Perl API
could have issues. More examples of failures, or lack of failures, are
discussed here:
http://mingw-users.1079350.n2.nabble.com/mms-bitfields-td2288523.html

To be clear, failures in this case would come in the form of corrupt data
and, in therefore segmentation faults when that corrupt data is a pointer.
Possibly also stack mis-alignment issues, though I'm not sure how that
would manifest itself.

David

On Tue, Nov 22, 2016 at 2:21 PM, avih <avih...@yahoo.com> wrote:

> Thanks for the detailed reply. I haven't yet read the linked discussion,
> but I will.
>
> I like that it will work better on Linux, but the latter part of my
> question was intended to understand better what would stop working on
> Windows if you take approach #1 but the flag isn't used when invoking tcc.
>
>
> On Tuesday, November 22, 2016 8:38 PM, David Mertens <
> dcmertens.p...@gmail.com> wrote:
>
>
> Hello,
>
> Folks have been using tcc on linux for years and have not reported this as
> an issue. Juding from the evidence, the situations where this is
> problematic are vanishingly small. That's because it is only an issue when
> a library presents the following sort of struct as part of its public api:
>
> struct {
> void * some;
> double data;
> int a : 2;
> char vowel;
> }
>
> On 32-bit systems, the "int" in the a bitfield force the value of a to
> have an alignment of four bytes. But, does the bitfield take four bytes
> followed by a single char, causing the struct to consume eight bytes across
> its last two members? Or, does the bitfield take a single byte, followed by
> a char with a single byte, and two unused bytes? VC++ does the former
> behavior, gcc without -mms-bitfields does the latter.
>
> Perl uses gcc's close-packing behavior. That is what made me aware of the
> problem. Even so, it is possible to compile perl.h and call functions from
> the Perl API with tcc without running into trouble. If you use functions
> that only need struct info that comes ahead of this bitfield stuff, you're
> layouts will still agree. This means you can directly manipulate s->some,
> s->data, and s->a, even when the alignment of vowel is wrong. Obviously if
> you pass around pointers to your structs, you can call functions as pass
> the pointers without any problems. It's really only an issue in two
> circumstances: (1) if you are allowed/expected to directly manipulate the
> elements of the struct (or use macros that do so, which was the case with
> the Perl API), or (2) if you are supposed to call a function on a struct
> directly, rather than passing via a pointer, in which case the stack will
> not be properly set up.
>
> Here is a discussion of enabling -mms-bitfields by default for another
> project. You might find it informative: https://groups.google.com/
> forum/#!topic/cocotron-dev/jwhEynyoZms
>
> To reiterate, there is currently no way to get this to work correctly on
> Linux. I'm proposing something that'll make it possible for everyone to
> achieve the correct behavior, albeit possibly with an additional
> command-line flag if you're on Windows.
>
> David
>
> On Tue, Nov 22, 2016 at 9:40 AM, avih <avih...@yahoo.com> wrote:
>
> Sounds fine to me to have better interoperability with existing/common
> tools on Linux.
>
> > If a library was compiled on Linux with gcc, there is no way to compile
> consuming code using tcc that is binary-compatible.
>
> Could you please elaborate on the scope of the affected use cases? does it
> apply to both .a and .so libs? I think the windows side has a potential to
> suffer more, if I understand it correctly.
>
> Assuming we take suggestion 1 (so on windows we'd need to invoke tcc with
> special cli flag to set a non default alignment) but we _don't_ use that
> flag, what would work which didn't before? interoperability with gcc? what
> wouldn't work? linking with libs created by native windows tools (MSVC)?
> What about using windows DLLs (which happens almost always as AFAIK
> binaries built with tcc use the ms crt for many things, and tcc comes with
> interfaces definitions to major system DLLs)?
>
> etc.
>
> Thanks.
>
>
> On Tuesday, November 22, 2016 5:16 AM, David Mertens <
> dcmertens.p...@gmail.com> wrote:
>
>
> Hello all,
>
> I have finally found a bit of time to work on this. Just to re-iterate,
> I've found variation in alignment with bitfields across

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[David Mertens]

Hello,

Folks have been using tcc on linux for years and have not reported this as
an issue. Juding from the evidence, the situations where this is
problematic are vanishingly small. That's because it is only an issue when
a library presents the following sort of struct as part of its public api:

struct {
void * some;
double data;
int a : 2;
char vowel;
}

On 32-bit systems, the "int" in the a bitfield force the value of a to have
an alignment of four bytes. But, does the bitfield take four bytes followed
by a single char, causing the struct to consume eight bytes across its last
two members? Or, does the bitfield take a single byte, followed by a char
with a single byte, and two unused bytes? VC++ does the former behavior,
gcc without -mms-bitfields does the latter.

Perl uses gcc's close-packing behavior. That is what made me aware of the
problem. Even so, it is possible to compile perl.h and call functions from
the Perl API with tcc without running into trouble. If you use functions
that only need struct info that comes ahead of this bitfield stuff, you're
layouts will still agree. This means you can directly manipulate s->some,
s->data, and s->a, even when the alignment of vowel is wrong. Obviously if
you pass around pointers to your structs, you can call functions as pass
the pointers without any problems. It's really only an issue in two
circumstances: (1) if you are allowed/expected to directly manipulate the
elements of the struct (or use macros that do so, which was the case with
the Perl API), or (2) if you are supposed to call a function on a struct
directly, rather than passing via a pointer, in which case the stack will
not be properly set up.

Here is a discussion of enabling -mms-bitfields by default for another
project. You might find it informative:
https://groups.google.com/forum/#!topic/cocotron-dev/jwhEynyoZms

To reiterate, there is currently no way to get this to work correctly on
Linux. I'm proposing something that'll make it possible for everyone to
achieve the correct behavior, albeit possibly with an additional
command-line flag if you're on Windows.

David

On Tue, Nov 22, 2016 at 9:40 AM, avih <avih...@yahoo.com> wrote:

> Sounds fine to me to have better interoperability with existing/common
> tools on Linux.
>
> > If a library was compiled on Linux with gcc, there is no way to compile
> consuming code using tcc that is binary-compatible.
>
> Could you please elaborate on the scope of the affected use cases? does it
> apply to both .a and .so libs? I think the windows side has a potential to
> suffer more, if I understand it correctly.
>
> Assuming we take suggestion 1 (so on windows we'd need to invoke tcc with
> special cli flag to set a non default alignment) but we _don't_ use that
> flag, what would work which didn't before? interoperability with gcc? what
> wouldn't work? linking with libs created by native windows tools (MSVC)?
> What about using windows DLLs (which happens almost always as AFAIK
> binaries built with tcc use the ms crt for many things, and tcc comes with
> interfaces definitions to major system DLLs)?
>
> etc.
>
> Thanks.
>
>
> On Tuesday, November 22, 2016 5:16 AM, David Mertens <
> dcmertens.p...@gmail.com> wrote:
>
>
> Hello all,
>
> I have finally found a bit of time to work on this. Just to re-iterate,
> I've found variation in alignment with bitfields across different flavors
> of compilers, and tcc is incompatible with gcc on Linux. If a library was
> compiled on Linux with gcc, there is no way to compile consuming code using
> tcc that is binary-compatible. I've listed the test program and the known
> results below.
>
> I believe the sensible thing to do is to make tcc more gcc-ish. This would
> involve (1) making tcc's default behavior align with gcc's default
> behavior, which appears to be consistent across platforms, and (2)
> providing the -mms-bitfields command-line option for Windows folks who need
> it. This makes binary compatibility possible across both Linux and Windows,
> and asks no more of Windows folks than what gcc asks.
>
> Alternatively, we could make tcc's default behavior configurable. This
> would require an additional configure flag. It would also require both
> -mms-bitfields and -no-mms-bitfields (or whatever the proper name for that
> flag should be). And finally, it would probably be best to make the default
> configuration OS-dependent.
>
> I prefer the first option because (a) it is simpler and (b) any
> configuration tools that think they're working with gcc will be smart
> enough to include the -mms-bitfields flag when it's needed on Windows.
> (Perl's build chain does this, for example.) Pragmatically, it is what I
> have the time to accomplish. I think the second approach is in some ways
> "b

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[David Mertens]

Hello all,

I have finally found a bit of time to work on this. Just to re-iterate,
I've found variation in alignment with bitfields across different flavors
of compilers, and tcc is incompatible with gcc on Linux. If a library was
compiled on Linux with gcc, there is no way to compile consuming code using
tcc that is binary-compatible. I've listed the test program and the known
results below.

I believe the sensible thing to do is to make tcc more gcc-ish. This would
involve (1) making tcc's default behavior align with gcc's default
behavior, which appears to be consistent across platforms, and (2)
providing the -mms-bitfields command-line option for Windows folks who need
it. This makes binary compatibility possible across both Linux and Windows,
and asks no more of Windows folks than what gcc asks.

Alternatively, we could make tcc's default behavior configurable. This
would require an additional configure flag. It would also require both
-mms-bitfields and -no-mms-bitfields (or whatever the proper name for that
flag should be). And finally, it would probably be best to make the default
configuration OS-dependent.

I prefer the first option because (a) it is simpler and (b) any
configuration tools that think they're working with gcc will be smart
enough to include the -mms-bitfields flag when it's needed on Windows.
(Perl's build chain does this, for example.) Pragmatically, it is what I
have the time to accomplish. I think the second approach is in some ways
"better", but it'll also add a bunch of configuration code that I think tcc
would be better without.

Preferences?
David


Here is a re-iteration of known results, and a new one: mingw on Windows.

%<
#include 
#include 
struct t1 {
uint8_t op_type:1;
uint8_t op_flags;
};
struct t2 {
uint32_t op_type:1;
uint8_t op_flags;
};
struct t3 {
unsigned op_type:1;
char op_flags;
};

int main() {
printf("t1 struct size: %ld\n", sizeof(struct t1));
printf("t2 struct size: %ld\n", sizeof(struct t2));
printf("t3 struct size: %ld\n", sizeof(struct t3));
return 0;
}
>%

With tcc on 64-bit Linux, this prints:
t1 struct size: 2
t2 struct size: 8
t3 struct size: 8

With gcc on 64-bit Linux, this prints:
t1 struct size: 2
t2 struct size: 4
t3 struct size: 4

With i686-w64-mingw32 (i.e. with MinGW on 64-bit Windows), this prints
t1 struct size: 2
t2 struct size: 4
t3 struct size: 4

According to Christian Jullien, VC++ 32 and 64 both return:
t1 struct size: 2
t2 struct size: 8
t3 struct size: 8

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[David Mertens]

On Tue, Oct 18, 2016 at 11:37 AM, Michael Matz <matz@frakked.de> wrote:

> Hi,
>
> On Tue, 18 Oct 2016, David Mertens wrote:
>
> > According to Christian, we have at least one major compiler (VC++) whose
> > behavior matches tcc's current behavior and another (GCC) whose behavior
> > differs.
>
> Yes, I've implemented the GCC way privately already (necessary for e.g.
> linux kernel).  Need to clean this up, sigh.
>
> > While it would be nice to just pick one implementation and go with it, I
> > am personally much more concerned with binary compatibility with one's
> > major compiler of choice.
>
> Exactly.  Actually also GCC itself has different implementations.  E.g.
> when configured for windows (or with -mms-bitfields) it implements the
> microsoft way, otherwise it defaults to the old PCC layout, which GCC uses
> on most UNIXen and other operating systems.  There're also minor
> variations for the latter e.g. on ppc64, but those wouldn't concern us.
>

Should we add this as a compiler flag to tcc, perhaps?


> > Here is a patch that makes the bit field size logic match gcc. I can
> > confirm that the original alignment bug is gone (though other alignment
> > bugs may yet be around). I am not 100% sure if this is correct, but I
> > throw it out there for folks to mull over. Note that indentation may not
> > be consistent; the indentation pattern in the existing code was weird.
> > Finally, it might be more efficient to use (bit_size & 7) rather than
> > (bit_size % 8), or optimizing compilers might do that for us anyway; I
> > leave that to the gurus.
>
> >  } else {
> > +   size = bit_size / 8;
> > +if (bit_size % 8) size++; /* round up */
> > +lbit_pos = bit_pos;
> >  /* we do not have enough room ?
> > did the type change?
> > is it a union? */
> >  if ((bit_pos + bit_size) > bsize ||
> > -bt != prevbt || a == TOK_UNION)
> > -bit_pos = 0;
> > -lbit_pos = bit_pos;
> > +bt != prevbt || a == TOK_UNION) {
> > +lbit_pos = bit_pos = 0;
>
> For instance, this is wrong for PCC layout.  MS layout indeed switches
> storage containers when the base type changes, i.e. here:
>
> struct S {
>   char  c:1;
>   short s:1;
>   char foo;
> };
>
> PCC layout has no such provisions.  But the base type _does_ influence
> alignment of the containing struct nevertheless.  Except if the bitfield
> has :0 size, then it _does_ force the next field to be placed into a new
> storage container.  It's all quite terrible and twisted :-/
>

I question the wisdom of targeting the binary layout of pcc. It's a neat
compiler, with an aim similar to tcc, but developer time and resources are
limited. I'd vote for just MSVC and GCC compatibility as a start.
(Presumably we get clang for free with that.) If anybody later comes along
with inclination, they can extend it to handle PCC layout.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] core dump on FreeBSD with last commit "configure: --triplet= option, Makefile: cleanup"

[David Mertens]

Can we just take a moment to appreciate how a pull request with automated
testing (a la Travis CI) would have made this error obvious *before* it was
added to mob?

On Tue, Oct 18, 2016 at 11:09 AM, Michael Matz  wrote:

> Hi,
>
> On Tue, 18 Oct 2016, grischka wrote:
>
> > Christian Jullien wrote:
> > > Get worse as it now core dumps ...
> >
> > At least it seems to find the crt*.o now.
>
> But not on linux-x86-64 anymore :-/  I think trying to fix things for a
> system one doesn't have access to is futile.  FWIW, your recent patch did,
> amongst other things:
>
>  #ifndef CONFIG_LDDIR
> -# ifdef TCC_TARGET_X86_64
> -#   define CONFIG_LDDIR "lib64"
> -# else
> -#   define CONFIG_LDDIR "lib"
> -# endif
> +# define CONFIG_LDDIR "lib"
>  #endif
>
> Okay, so no sensible default setting anymore, which is fine, but now we
> rely on configure providing the correct one.  But the same commit also
> does:
>
> -  triplet="$($CONFTEST triplet)"
> -  if test -f "/usr/lib/$triplet/crti.o" ; then
> -   tcc_lddir="lib"
> -   multiarch_triplet="$triplet"
> -  elif test "$cpu" != "x86" -a -f "/usr/lib64/crti.o" ; then
> -   tcc_lddir="lib64"
> +
> +  if test -z "$triplet"; then
> +tt="$($CONFTEST triplet)"
> +if test -n "$tt" -a -f "/usr/lib/$tt/crti.o" ; then
> +  triplet="$tt"
> +fi
> +  fi
> +
> +  if test -z "$triplet"; then
> +if test ! -f "/usr/lib/crti.o" -a -f "/usr/lib64/crti.o" ; then
> +  tcc_lddir="lib64"
> +fi
>fi
>
> That's not correct.  On an x86-64 system I can have both /usr/lib/crti.o
> and /usr/lib64/crti.o, namely when one also has a 32bit development
> environment (which I have).  Before it was testing if the cpu isn't x86
> and differenciated by that.  Now, on my system, tcc_lddir remains unset
> and hence runs into the above hunk which has no fallback to lib64 anymore.
>
> Christian: do you have /usr/lib64 as well or only /usr/lib?  If you also
> have the former, is there a crti.o in there as well?
>
> I'm tempted to remove the check for /usr/lib/crti.o altogether.  That
> would mean to always assume lib64 if no triplet is given but
> /usr/lib64/crti.o exists.  That seems sensible to me (on 32 hosts you
> won't have lib64, and on 64bit hosts you probably will default to 64bit
> code).
>
> Thoughts?
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[David Mertens]

According to Christian, we have at least one major compiler (VC++) whose
behavior matches tcc's current behavior and another (GCC) whose behavior
differs. While it would be nice to just pick one implementation and go with
it, I am personally much more concerned with binary compatibility with
one's major compiler of choice. In that case, the logic for how to handle
this would depend upon a bit being set in the TCCState struct.

Here is a patch that makes the bit field size logic match gcc. I can
confirm that the original alignment bug is gone (though other alignment
bugs may yet be around). I am not 100% sure if this is correct, but I throw
it out there for folks to mull over. Note that indentation may not be
consistent; the indentation pattern in the existing code was weird.
Finally, it might be more efficient to use (bit_size & 7) rather than
(bit_size % 8), or optimizing compilers might do that for us anyway; I
leave that to the gurus.

If this looks good, I propose adding a bit to TCCState to pick this vs the
old behavior, then throwing in a couple of if statements to the below patch
to switch based on said bit.

David

diff --git a/tccgen.c b/tccgen.c
index ad70de6..97b37a4 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -3109,13 +3109,27 @@ static void struct_decl(CType *type, AttributeDef
*ad, int u)
 /* zero size: means to pad */
 bit_pos = 0;
 } else {
+   size = bit_size / 8;
+if (bit_size % 8) size++; /* round up */
+lbit_pos = bit_pos;
 /* we do not have enough room ?
did the type change?
is it a union? */
 if ((bit_pos + bit_size) > bsize ||
-bt != prevbt || a == TOK_UNION)
-bit_pos = 0;
-lbit_pos = bit_pos;
+bt != prevbt || a == TOK_UNION) {
+lbit_pos = bit_pos = 0;
+}
+/* only allocate large-type int bitfields
+ * one byte at a time */
+else {
+   int overage;
+   overage = bit_pos % 8 + bit_size;
+   if (overage > 8) {
+   lbit_pos = 0;
+   size = overage / 8;
+   if (overage % 8 == 0) size--;
+   }
+   }
 /* XXX: handle LSB first */
 type1.t |= VT_BITFIELD |
 (bit_pos << VT_STRUCT_SHIFT) |



On Tue, Oct 18, 2016 at 4:35 AM, Vincent Lefevre  wrote:

> On 2016-10-18 09:59:36 +0200, Daniel Glöckner wrote:
> > On Tue, Oct 18, 2016 at 09:41:49AM +0200, Vincent Lefevre wrote:
> > > AFAIK, both are correct.
> >
> > It depends on the ABI. The ARM EABI defines those details in
> > http://infocenter.arm.com/help/topic/com.arm.doc.
> ihi0042f/IHI0042F_aapcs.pdf
> > section 7.1.7. But I don't know if we adhere to those rules when
> > compiling for ARM.
>
> "For the purposes of calculating the alignment of the aggregate the
> type of the member shall be the Fundamental Data Type upon which the
> bit-field is based.[1]
>
> [1] The intent is to permit the C construct struct {int a:8; char b[7];}
> to have size 8 and alignment 4."
>
> Assuming that there are similar requirements for other architectures,
> the behavior of GCC now makes sense to me.
>
> --
> Vincent Lefèvre  - Web: 
> 100% accessible validated (X)HTML - Blog: 
> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

[David Mertens]

Hello everyone,

I recently uncovered some segfaulting code when compiling code with macros
that manipulate certain Perl structs on 64-bit Linux. I boiled the problem
down to a discrepancy between how tcc and gcc determine the size needed by
a series of bit fields. The tcc-compiled function would get the Perl
interpreter struct produced by gcc-compiled code, then reach into the wrong
memory slot for something. A reduced example is provided below.

Question 1: Would anybody be opposed to changing tcc's behavior to match
gcc's behavior here? This could lead to binary incompatibility with object
code previously compiled with tcc, but that seems to me highly unlikely to
be a real problem for anyone.

Question 2: Does anybody know tccgen.c well enough to fix this? I can work
on it, but if anybody knows exactly where this goes wrong, it would save me
a few hours.

%<
#include 
#include 
struct t1 {
uint8_t op_type:1;
uint8_t op_flags;
};
struct t2 {
uint32_t op_type:1;
uint8_t op_flags;
};
struct t3 {
unsigned op_type:1;
char op_flags;
};

int main() {
printf("t1 struct size: %ld\n", sizeof(struct t1));
printf("t2 struct size: %ld\n", sizeof(struct t2));
printf("t3 struct size: %ld\n", sizeof(struct t3));
return 0;
}
>%

With tcc, this prints:
t1 struct size: 2
t2 struct size: 8
t3 struct size: 8

With gcc, this prints:
t1 struct size: 2
t2 struct size: 4
t3 struct size: 4

This suggests that with tcc, the number of bytes given to a series of
bitfields in a struct depends upon the integer type of the bitfield. In
particular, plain old "unsigned" is interpreted (in 64-bit context) to be
"unsigned int", which has 32 bits. This is incompatible with gcc's
interpretation.

The relevant code is, I think, in tccgen.c's struct_decl. However, I can't
quite tease apart where the declaration comes in, and how it effect struct
size calculations.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

[David Mertens]

Hello Michael,

On Sun, Oct 16, 2016 at 5:59 PM, Michael Matz  wrote:

> 
> You can't "move" tinycc anyway.
>

Of course not. There are only a handful of folks who really understand the
inner workings of tcc (you being one of them), and if they want to stick
with repo.or.cz, then that's where code will stay. Nobody can forcibly move
the project anywhere.


> 
>
> Currently I don't see the need for gate keepers (though I certainly was
> extremely frustrated during at least two periods in the past where
> low-quality non-sense was added).
>

Sure, tcc itself does not need a gatekeeper. Unwanted commits can easily be
overturned. But, since tcc does not support extensions, it implicitly
forces extensions to be maintained as forks. This is what I do with my
extended symbol table project. Keeping forks up-to-date with mob is a huge
pain. A pull-request style would make the code much, much cleaner, and thus
my job much, much easier.

I wrote a much wordier statement, but I'm trying to learn to be more terse.
See below if you want to read more. :-)
David




Consider the following tcc policy:

* Nontrivial extensions to tcc should be maintained as separate forks.

That statement is not explicitly stated anywhere, but it is consistent with
how the tcc project maintains itself. Anything outside of tcc's main
goal---fast one-pass C compiler and linker---do not belong in this project.
As a corollary, any nontrivial extension to tcc should be maintained in a
fork*.* Or, there shouldn't be any nontrivial extensions, but that's not
realistic. So, I will take that as my premise.

The current situation is very precarious for extension maintainers like me.
This precariousness has been pointed out before: https://lists.nongnu.org/
archive/html/tinycc-devel/2014-05/msg00036.html. In a related but separate
story, I started my extended symbol table work back in the fall of 2013.
When I checked back in over the summer of 2014 (when Sia was writing that
email about jiang's commits), mob had an enormous number of low-quality
line changes, and it no longer compiled on Mac, so I didn't go through the
effort of updating my fork. The situation got worse and worse until I was
saved by seyko's heroic efforts and a major pull-request on my project.

Still, my efforts to track my nearly-up-to-date fork with mob are subject
to the whims of contributors who cannot or simply do not test their commits
on multiple operating systems, or who commit a series of half-completed
commits that break git-bisect. Or, suppose somebody contributes high
quality but unwanted code that touches something I've altered. Even if that
commit is later reverted---keeping tcc slim and the final state of the
sources in good shape---I still need to merge the initial commit and its
revert. I would be much, much happier if these reverted commits were never
added in the first place.

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

[David Mertens]

avih, one more note:

The big problem is not how we handle our discussions on the mailing list,
it's when a person does not respect the open source governance and pushes a
bunch of unsolicited commits without *any* discussion. This has happened
many times over the last three or four years. Pull requests would let us
manage those, mostly by preventing them when they do not fit the goals of
the project (i.e. unwanted extensions to the compiler).

FWIW, I don't think this would stifle the current discussion of patches
that occurs on the mailing list.

David

On Sun, Oct 16, 2016 at 12:53 PM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> On Sun, Oct 16, 2016 at 11:26 AM, avih <avih...@yahoo.com> wrote:
>
>> > I am less concerned about losing this kind of meta-info, as I expect
>> we would continue discussion primarily on the mailing list.
>>
>> Would you/we?
>>
>> The initial suggestion mentioned pull-requests as being easier to handle
>> than discussing patches over mailing lists - to which personally I agree
>> (though I don't claim everyone should agree to that).
>>
>> PRs carry discussions - which typically happen on the PR "page", on
>> github and the github hosting would also be quite more useful if people can
>> report bugs via github.
>>
>
> I had a vision in which the pull requests lived on github, but discussion
> of merging (or not) would take place on the mailing list. Even if we don't
> use the github facilities for discussion, just having a system for managing
> pull requests is a big win, in my book.
>
> That said, I think we can set up email notifications so that any bug
> notifications or pull requests would send an email to the mailing list. In
> that case, replies would go back to the PR/bug discussion, so we would have
> a synchronized discussion.
>
>
>> Otherwise, if there's no intention to use the github facilities which
>> make collaboration easier and more visible, what's the point of moving to
>> github? Just a different git-repo host?
>>
>
> Having a system for managing multiple pull-requests would be a big win. In
> addition, and probably more importantly, it's possible to set up travis and
> appveyor testing *on pull requests*, so we could get integration testing
> even *before* pulling in the code.
>
> David
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

[David Mertens]

Hey everyone,

I owe an apology to grishka. Grishka, I may not like how you currently
handle unwanted pushes (often by revert without discussion), but I don't
think you'd be half as reactive if we kept unwanted pushes out of the main
repo in the first place. In that case we'd get the best of your efforts
without the annoying parts, which I think would be a win for everyone.

Sorry,
David

On Sat, Oct 15, 2016 at 12:58 PM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Hello all,
>
> Jean-Claude articulates concerns I have felt as well. Sometimes we'll get
> a series of ridiculous commits from hitherto unknown programmers trying to
> "help". Sometimes we get commits from people trying to extend tcc's
> behavior beyond its core intent. Other times core hackers (OK, mostly just
> grishka) push a series of commits, some of which are brilliant and others
> of which are inappropriate and highly opinionated. (Overall I am glad to
> have grishka's contributions, but they always seem to come with a bit of
> avoidable pain.)
>
> I would be happy to see this project moved *out* of a mob branch on
> repo.or.cz, and managed on a site that provides facilities for
> collaborative programming. My experience is with github, but I don't care
> if it's there or somewhere else. I would just like to have contributions
> submitted as pull requests, and managed by one or two gatekeepers. If there
> is significant interest in this, I'm sure that we can start a grass-roots
> group. This is open source, after all. :-)
>
> So, are Jean-Claude and I mostly alone in this, or do others feel
> similarly?
>
> David
>
> On Sat, Oct 1, 2016 at 5:09 PM, Jean-Claude Beaudoin <
> jean.claude.beaud...@gmail.com> wrote:
>
>>
>>
>> On Sat, Oct 1, 2016 at 3:03 PM, grischka <gris...@gmx.de> wrote:
>>
>>> Hey all,
>>>
>>> I did push some cleanups to prepare for a release 0.9.27,
>>> eventually.  Just if you wonder what's the point of that.
>>>
>>
>> I was indeed wondering if we would see a new release sometime soon
>> considering that the latest one dates from a few years ago. That is
>> answered now.
>>
>> That also brought me to wonder how that release process would be
>> managed and effectively executed. Could you elaborate on that
>> point please?
>>
>> One fact that gives me serious pause in that area is that the
>> majority of the commits I contributed in the last few days were
>> simply reverted thus reintroducing the problems they tried to fix
>> or introducing some new lesser one when the revert was partial.
>> A good number of others recent commits have been also similarly
>> impacted.
>>
>> That leaves me quite puzzled.
>>
>> My intent was to use libtcc as a significant part of the back-end
>> of MKCL <https://common-lisp.net/project/mkcl/>. But after some study of
>> the TCC source code I came
>> to the realization that there were a number of serious technical
>> problems with that. And now there is this governance aspect
>> being raised.  All that push me to reconsider my approach.
>>
>> Regards,
>>
>> Jean-Claude Beaudoin
>>
>>
>> ___
>> Tinycc-devel mailing list
>> Tinycc-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
>>
>
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

[David Mertens]

On Sun, Oct 16, 2016 at 11:26 AM, avih  wrote:

> > I am less concerned about losing this kind of meta-info, as I expect we
> would continue discussion primarily on the mailing list.
>
> Would you/we?
>
> The initial suggestion mentioned pull-requests as being easier to handle
> than discussing patches over mailing lists - to which personally I agree
> (though I don't claim everyone should agree to that).
>
> PRs carry discussions - which typically happen on the PR "page", on github
> and the github hosting would also be quite more useful if people can report
> bugs via github.
>

I had a vision in which the pull requests lived on github, but discussion
of merging (or not) would take place on the mailing list. Even if we don't
use the github facilities for discussion, just having a system for managing
pull requests is a big win, in my book.

That said, I think we can set up email notifications so that any bug
notifications or pull requests would send an email to the mailing list. In
that case, replies would go back to the PR/bug discussion, so we would have
a synchronized discussion.


> Otherwise, if there's no intention to use the github facilities which make
> collaboration easier and more visible, what's the point of moving to
> github? Just a different git-repo host?
>

Having a system for managing multiple pull-requests would be a big win. In
addition, and probably more importantly, it's possible to set up travis and
appveyor testing *on pull requests*, so we could get integration testing
even *before* pulling in the code.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Governance (Re: cleanups)

[David Mertens]

I am less concerned about losing this kind of meta-info, as I expect we
would continue discussion primarily on the mailing list. Mailing lists seem
to me to be much better venues for discussion than the facilities provided
by github.

My bigger concern is: who would be the project managers? Who would manage
pull requests? I would volunteer for some of it, but I could only guarantee
responsiveness during winter and summer breaks, and would want to hand off
responsibility during my school's semesters. Are others willing to step up?
If not, we shouldn't move to a github/pull-requests workflow.

David

On Sun, Oct 16, 2016 at 7:13 AM, avih  wrote:

> I also think github could be good to tinycc.
>
> The obvious reasons were mentioned: Arguably easier and more open
> collaboration, bug reports and tracking, automatic builds and tests,
> possibly better exposure to other people, etc.
>
> There's one thing though which github doesn't make easy as far as I know:
> all the discussions, comments, code reviews, tagging (of issues) are not
> easy to export as far as I know. The project's wiki pages are in a git repo
> which the project owns (separate from the project's code), but as far as I
> know all the text which people enter (other than at commits) is available
> at most only via some github API. This is a lot of info which would be a
> shame to lose if github closes its doors tomorrow.
>
> While github is definitely used as the main host for some big projects,
> and while I maintain some projects on github myself (on my own and with
> others), I'd be much more comfortable if I knew all
> discussions/comments/etc are being mirrored to an external host under the
> project's control, even if only in a read-only format.
>
> FWIW, I know such export tools exist, but I haven't used them and I don't
> know how good they are.
>
> Overall, I'd vote to move tinycc to github, with the caveat that it'd be
> nice to also have an external archive of all the discussions, issues,
> reviews, etc.
>
>
> On Sunday, October 16, 2016 1:39 PM, Daniel Glöckner 
> wrote:
>
>
> Hi,
>
> on Github we could use Travis to run tests after every commit.
> We could also use Qemu there to check if the other architectures still
> work. It might also serve as an example how to setup a cross development
> environment with TinyCC.
>
> Best regards.
>
>   Daniel
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] cleanups

[David Mertens]

Ah, now I get errors running the preprocessor tests. Here's a
representative result:

PPTest 14 ...
--- 14.expect2016-10-15 13:07:53.790016538 -0400
+++ 14.output2016-10-15 22:36:25.971293975 -0400
@@ -1,3 +1,8 @@
+
 return Z(Z(1,2),2);
+
 return Q(1,2);
+
 return ((A + A) * (A + A)) + ((B * B) + (B * B));
+
+tcc: error: file '/usr/local/lib/tcc/x86-64/libtcc1.a' not found

Obviously something (a lib path?) is not getting set up correctly for
these, though it is getting set up correctly for the other tests. In case
it's not obvious, I have not installed tcc to a system-wide path. I suspect
there's something amiss in the pp makefile, but I am not a makefile guru.

David

On Sat, Oct 15, 2016 at 10:23 PM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> D'oh! Thanks!
>
> On Sat, Oct 15, 2016 at 6:09 PM, Michael Matz <matz@frakked.de> wrote:
>
>> Hello,
>>
>> On Sat, 15 Oct 2016, David Mertens wrote:
>>
>> This commit:
>>>
>>> 0a624782dfc8fee6f0600066b135d3b20e4274f4
>>>
>>> causes "make test" to fail on my 64-bit Linux (ubuntu 16.04). Any idea of
>>> what's going on? Below is the output of "make" followed by "make test".
>>>
>>> $ make test
>>> ../tcc -B.. -I/include -I -I.. ../examples/ex1.c -o hello || (../tcc -vv;
>>>
>>
>> See the -I/include here.  It's missing the setting of SRCTOP.  Which
>> means you haven't rerun configure after this commit.  Just do ./configure
>> and be done.
>>
>>
>> Ciao,
>> Michael.
>>
>>
>> ___
>> Tinycc-devel mailing list
>> Tinycc-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
>
>
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] cleanups

[David Mertens]

D'oh! Thanks!

On Sat, Oct 15, 2016 at 6:09 PM, Michael Matz <matz@frakked.de> wrote:

> Hello,
>
> On Sat, 15 Oct 2016, David Mertens wrote:
>
> This commit:
>>
>> 0a624782dfc8fee6f0600066b135d3b20e4274f4
>>
>> causes "make test" to fail on my 64-bit Linux (ubuntu 16.04). Any idea of
>> what's going on? Below is the output of "make" followed by "make test".
>>
>> $ make test
>> ../tcc -B.. -I/include -I -I.. ../examples/ex1.c -o hello || (../tcc -vv;
>>
>
> See the -I/include here.  It's missing the setting of SRCTOP.  Which means
> you haven't rerun configure after this commit.  Just do ./configure and be
> done.
>
>
> Ciao,
> Michael.
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] cleanups

[David Mertens]

This commit:

0a624782dfc8fee6f0600066b135d3b20e4274f4

causes "make test" to fail on my 64-bit Linux (ubuntu 16.04). Any idea of
what's going on? Below is the output of "make" followed by "make test".

David

$ make
gcc -o tcc.o -c tcc.c -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 -Wall -g -O0 -Wdeclaration-after-statement
-Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
-Wno-sign-compare -Wno-unused-result -Wno-uninitialized
-fno-strict-aliasing -I.
gcc -o libtcc.o -c libtcc.c -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 -Wall -g -O0 -Wdeclaration-after-statement
-Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
-Wno-sign-compare -Wno-unused-result -Wno-uninitialized
-fno-strict-aliasing -I.
gcc -o tccpp.o -c tccpp.c -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 -Wall -g -O0 -Wdeclaration-after-statement
-Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
-Wno-sign-compare -Wno-unused-result -Wno-uninitialized
-fno-strict-aliasing -I.
gcc -o tccgen.o -c tccgen.c -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 -Wall -g -O0 -Wdeclaration-after-statement
-Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
-Wno-sign-compare -Wno-unused-result -Wno-uninitialized
-fno-strict-aliasing -I.
gcc -o tccelf.o -c tccelf.c -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 -Wall -g -O0 -Wdeclaration-after-statement
-Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
-Wno-sign-compare -Wno-unused-result -Wno-uninitialized
-fno-strict-aliasing -I.
gcc -o tccasm.o -c tccasm.c -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 -Wall -g -O0 -Wdeclaration-after-statement
-Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
-Wno-sign-compare -Wno-unused-result -Wno-uninitialized
-fno-strict-aliasing -I.
gcc -o tccrun.o -c tccrun.c -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\""
-DTCC_TARGET_X86_64 -Wall -g -O0 -Wdeclaration-after-statement
-Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
-Wno-sign-compare -Wno-unused-result -Wno-uninitialized
-fno-strict-aliasing -I.
gcc -o x86_64-gen.o -c x86_64-gen.c
-DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\"" -DTCC_TARGET_X86_64 -Wall -g
-O0 -Wdeclaration-after-statement -Wno-deprecated-declarations
-Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result
-Wno-uninitialized -fno-strict-aliasing -I.
gcc -o i386-asm.o -c i386-asm.c
-DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\"" -DTCC_TARGET_X86_64 -Wall -g
-O0 -Wdeclaration-after-statement -Wno-deprecated-declarations
-Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result
-Wno-uninitialized -fno-strict-aliasing -I.
ar rcs libtcc.a libtcc.o tccpp.o tccgen.o tccelf.o tccasm.o tccrun.o
x86_64-gen.o i386-asm.o
gcc -o tcc tcc.o libtcc.a -Wall -g -O0 -Wdeclaration-after-statement
-Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign
-Wno-sign-compare -Wno-unused-result -Wno-uninitialized
-fno-strict-aliasing -I.  -lm -ldl
make -C lib native
make[1]: Entering directory '/home/dcmertens-perl/projects/tinycc/lib'
mkdir -p x86_64
gcc  -c libtcc1.c -o x86_64/libtcc1.o -Wall -g -O0
-Wdeclaration-after-statement -Wno-deprecated-declarations
-Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result
-Wno-uninitialized -fno-strict-aliasing -I.. -fPIC -DTCC_TARGET_X86_64
gcc  -c alloca86_64.S -o x86_64/alloca86_64.o -Wall -g -O0
-Wdeclaration-after-statement -Wno-deprecated-declarations
-Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result
-Wno-uninitialized -fno-strict-aliasing -I.. -fPIC -DTCC_TARGET_X86_64
gcc  -c alloca86_64-bt.S -o x86_64/alloca86_64-bt.o -Wall -g -O0
-Wdeclaration-after-statement -Wno-deprecated-declarations
-Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result
-Wno-uninitialized -fno-strict-aliasing -I.. -fPIC -DTCC_TARGET_X86_64
gcc  -c bcheck.c -o x86_64/bcheck.o -Wall -g -O0
-Wdeclaration-after-statement -Wno-deprecated-declarations
-Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result
-Wno-uninitialized -fno-strict-aliasing -I.. -fPIC -DTCC_TARGET_X86_64
ar rcs ../libtcc1.a x86_64/libtcc1.o x86_64/alloca86_64.o
x86_64/alloca86_64-bt.o x86_64/bcheck.o
make[1]: Leaving directory '/home/dcmertens-perl/projects/tinycc/lib'
makeinfo --no-split --html --number-sections -o tcc-doc.html tcc-doc.texi
make: makeinfo: Command not found
Makefile:304: recipe for target 'tcc-doc.html' failed
make: [tcc-doc.html] Error 127 (ignored)
makeinfo tcc-doc.texi
make: makeinfo: Command not found
Makefile:311: recipe for target 'tcc-doc.info' failed
make: [tcc-doc.info] Error 127 (ignored)

$ make test
make -C tests
make[1]: Entering directory '/home/dcmertens-perl/projects/tinycc/tests'
 hello-exe 
../tcc -B.. -I/include -I -I.. ../examples/ex1.c -o hello || (../tcc -vv;
exit 

[Tinycc-devel] Governance (Re: cleanups)

[David Mertens]

Hello all,

Jean-Claude articulates concerns I have felt as well. Sometimes we'll get a
series of ridiculous commits from hitherto unknown programmers trying to
"help". Sometimes we get commits from people trying to extend tcc's
behavior beyond its core intent. Other times core hackers (OK, mostly just
grishka) push a series of commits, some of which are brilliant and others
of which are inappropriate and highly opinionated. (Overall I am glad to
have grishka's contributions, but they always seem to come with a bit of
avoidable pain.)

I would be happy to see this project moved *out* of a mob branch on
repo.or.cz, and managed on a site that provides facilities for
collaborative programming. My experience is with github, but I don't care
if it's there or somewhere else. I would just like to have contributions
submitted as pull requests, and managed by one or two gatekeepers. If there
is significant interest in this, I'm sure that we can start a grass-roots
group. This is open source, after all. :-)

So, are Jean-Claude and I mostly alone in this, or do others feel similarly?

David

On Sat, Oct 1, 2016 at 5:09 PM, Jean-Claude Beaudoin <
jean.claude.beaud...@gmail.com> wrote:

>
>
> On Sat, Oct 1, 2016 at 3:03 PM, grischka  wrote:
>
>> Hey all,
>>
>> I did push some cleanups to prepare for a release 0.9.27,
>> eventually.  Just if you wonder what's the point of that.
>>
>
> I was indeed wondering if we would see a new release sometime soon
> considering that the latest one dates from a few years ago. That is
> answered now.
>
> That also brought me to wonder how that release process would be
> managed and effectively executed. Could you elaborate on that
> point please?
>
> One fact that gives me serious pause in that area is that the
> majority of the commits I contributed in the last few days were
> simply reverted thus reintroducing the problems they tried to fix
> or introducing some new lesser one when the revert was partial.
> A good number of others recent commits have been also similarly
> impacted.
>
> That leaves me quite puzzled.
>
> My intent was to use libtcc as a significant part of the back-end
> of MKCL . But after some study of
> the TCC source code I came
> to the realization that there were a number of serious technical
> problems with that. And now there is this governance aspect
> being raised.  All that push me to reconsider my approach.
>
> Regards,
>
> Jean-Claude Beaudoin
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Removal of certain windows headers---why?

[David Mertens]

Hello everyone,

A couple of weeks ago Grishka removed some header files copied from the
msys project. (Or is in MinSys? I don't know, but you know what I'm talking
about.) These were added so that tcc could compile Perl header files on
Windows. I had previously added a number of msys files to tcc for this
reason, but the list was incomplete. seyko added these files to tcc in
2015, based on their existence in my own fork of tcc. So, they were added
in the same spirit as other files I previously added. Now, of course, they
are gone.

When I added the (apparently incomplete) collection of headers, I asked for
permission from the mailing list. The consensus seemed to be that if Perl
needed it, the headers were probably important enough to include. Is this
still the consensus?

If it is, I will re-add them some time soon-ish.

Thanks!
David

P.S. We don't provide a full set of tcc-compatible system header files for
Unixen: we assume the system provides these or they are easy to obtain. We
have provided a minimal set for Windows because tcc-compatible system
headers are much harder to obtain on this OS.

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Trouble on x86-64, not windows, not gcc

[David Mertens]

Alright, it's been pushed to mob:

http://repo.or.cz/tinycc.git/commit/0a402f6e91c284dd37cb61e726cc95de20fe895e

On Wed, Aug 3, 2016 at 6:11 PM, Michael Matz <matz@frakked.de> wrote:

> Hi,
>
> On Tue, 2 Aug 2016, David Mertens wrote:
>
> Unless I hear opposition, I'll push a fix to mob some time tomorrow.
>>
>> Also, for similar reasons, it appears that including "#define
>> _VA_LIST_DECLARED" might help make BSD (or at least FreeBSD) happy. I am
>> currently testing this. Does anybody have experience with this, or any
>> commentary on whether this is a good idea?
>>
>
> I think it's reasonable (as well as the solution for the problem on
> MacOS).  Sorry for not coming back earlier to that, I would have suggested
> the same solution.
>
> (The other one would be to implement __builtin_va_list and
> __darwin_va_list in tcc itself as a built in predefined type, but that's
> more work and harder to maintain).
>
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Trouble on x86-64, not windows, not gcc

[David Mertens]

Unless I hear opposition, I'll push a fix to mob some time tomorrow.

Also, for similar reasons, it appears that including "#define
_VA_LIST_DECLARED" might help make BSD (or at least FreeBSD) happy. I am
currently testing this. Does anybody have experience with this, or any
commentary on whether this is a good idea?

David

On Mon, Aug 1, 2016 at 9:50 AM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> FWIW, when I patch our copy of stdarg.h to #define _VA_LIST_T on Macs, the
> tests pass:
> http://www.cpantesters.org/cpan/report/a5fc4ca8-5788-11e6-bb69-be43cba39ea2
>
> Amusingly, those are reported as test failures, but that's because I'm
> doing a straight text comparison of the output. The header files include a
> #warning with "Unsupported compiler detected" and so I get additional,
> unexpected text. I don't believe that this is something we want to work
> around; this is Apple's fault, I'd say.
>
> Shall I modify our stdarg.h?
>
> David
>
> On Sun, Jul 10, 2016 at 3:29 PM, David Mertens <dcmertens.p...@gmail.com>
> wrote:
>
>> I found a copy of Apple's _va_list.h header file:
>>
>>
>> http://opensource.apple.com/source/xnu/xnu-3248.20.55/bsd/sys/_types/_va_list.h
>>
>> The offending lines are:
>>
>> #ifndef _VA_LIST_T
>> #define _VA_LIST_Ttypedef __darwin_va_list va_list;
>> #endif /* _VA_LIST_T */
>>
>> Perhaps our stdarg.h should #define _VA_LIST_T?
>>
>> On Sun, Jul 10, 2016 at 3:13 PM, David Mertens <dcmertens.p...@gmail.com>
>> wrote:
>>
>>> Well bother, the cpantesters site appears to be experiencing
>>> intermittent trouble at the moment. If you try to read the full report on
>>> cpantesters, you may need to hit "refresh" a few times.
>>>
>>> On Sun, Jul 10, 2016 at 3:06 PM, David Mertens <dcmertens.p...@gmail.com
>>> > wrote:
>>>
>>>> Hello Michael,
>>>>
>>>> Thanks for your reply, and for explaining things. A few points of
>>>> clarification are in order.
>>>>
>>>> On Sun, Jul 10, 2016 at 1:21 PM, Michael Matz <matz@frakked.de>
>>>> wrote:
>>>>
>>>>> On Sat, 9 Jul 2016, David Mertens wrote:
>>>>>
>>>>> When run on Mac systems, I get errors about "incompatible redefinition
>>>>>> of
>>>>>> 'va_list'".
>>>>>>
>>>>>
>>>>> Is that the message from TCC or from some other compiler?  The other
>>>>> compiler should use its own , not TCCs version.  If the message
>>>>> comes from TCC, what are the two definitions of va_list and where does the
>>>>> one not coming from TCCs  comes from?
>>>>>
>>>>> (Ultimately the layout of va_list has to be compatible between
>>>>> compilers on the same system anyway; it's dictated by the psABI.)
>>>>>
>>>>
>>>> The error message comes from tcc. The exact text of the error (as well
>>>> as a preceding warning) is:
>>>>
>>>> In file included from test.c:8:
>>>> In file included from /usr/include/stdio.h:64:
>>>> /usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler 
>>>> detected"
>>>> In file included from test.c:8:
>>>> In file included from /usr/include/stdio.h:71:
>>>> /usr/include/sys/_types/_va_list.h:31: error: incompatible redefinition of 
>>>> 'va_list'
>>>>
>>>> I'm assuming that tcc picked up its own va_list definition first. Then
>>>> when it pulled in stdio.h via the system header files, they pulled in a
>>>> different va_list as illustrated in the series of include provided by the
>>>> error message. Probably, then, the problem is that everybody is using
>>>> preprocessor definitions for va_list, and because the tokens that clang
>>>> uses (a builtin expression) is different from the struct that tcc uses, tcc
>>>> can't figure out that the two are actually compatible. If that's the case,
>>>> I'm not entirely sure how to go about fixing the problem.
>>>>
>>>>
>>>>> 
>>>>>>
>>>>>
>>>>> Normal BSDs use the sysv ELF psABI, so better have the same definition
>>>>> of va_list like in TCCs .  Darwin uses the same layout as sysv 
>>>>> as
>>>>> well.  What could happen is that there are some (and different) type
>>>>> aliases in betw

Re: [Tinycc-devel] Trouble on x86-64, not windows, not gcc

[David Mertens]

FWIW, when I patch our copy of stdarg.h to #define _VA_LIST_T on Macs, the
tests pass:
http://www.cpantesters.org/cpan/report/a5fc4ca8-5788-11e6-bb69-be43cba39ea2

Amusingly, those are reported as test failures, but that's because I'm
doing a straight text comparison of the output. The header files include a
#warning with "Unsupported compiler detected" and so I get additional,
unexpected text. I don't believe that this is something we want to work
around; this is Apple's fault, I'd say.

Shall I modify our stdarg.h?

David

On Sun, Jul 10, 2016 at 3:29 PM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> I found a copy of Apple's _va_list.h header file:
>
>
> http://opensource.apple.com/source/xnu/xnu-3248.20.55/bsd/sys/_types/_va_list.h
>
> The offending lines are:
>
> #ifndef _VA_LIST_T
> #define _VA_LIST_Ttypedef __darwin_va_list va_list;
> #endif /* _VA_LIST_T */
>
> Perhaps our stdarg.h should #define _VA_LIST_T?
>
> On Sun, Jul 10, 2016 at 3:13 PM, David Mertens <dcmertens.p...@gmail.com>
> wrote:
>
>> Well bother, the cpantesters site appears to be experiencing intermittent
>> trouble at the moment. If you try to read the full report on cpantesters,
>> you may need to hit "refresh" a few times.
>>
>> On Sun, Jul 10, 2016 at 3:06 PM, David Mertens <dcmertens.p...@gmail.com>
>> wrote:
>>
>>> Hello Michael,
>>>
>>> Thanks for your reply, and for explaining things. A few points of
>>> clarification are in order.
>>>
>>> On Sun, Jul 10, 2016 at 1:21 PM, Michael Matz <matz@frakked.de>
>>> wrote:
>>>
>>>> On Sat, 9 Jul 2016, David Mertens wrote:
>>>>
>>>> When run on Mac systems, I get errors about "incompatible redefinition
>>>>> of
>>>>> 'va_list'".
>>>>>
>>>>
>>>> Is that the message from TCC or from some other compiler?  The other
>>>> compiler should use its own , not TCCs version.  If the message
>>>> comes from TCC, what are the two definitions of va_list and where does the
>>>> one not coming from TCCs  comes from?
>>>>
>>>> (Ultimately the layout of va_list has to be compatible between
>>>> compilers on the same system anyway; it's dictated by the psABI.)
>>>>
>>>
>>> The error message comes from tcc. The exact text of the error (as well
>>> as a preceding warning) is:
>>>
>>> In file included from test.c:8:
>>> In file included from /usr/include/stdio.h:64:
>>> /usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler 
>>> detected"
>>> In file included from test.c:8:
>>> In file included from /usr/include/stdio.h:71:
>>> /usr/include/sys/_types/_va_list.h:31: error: incompatible redefinition of 
>>> 'va_list'
>>>
>>> I'm assuming that tcc picked up its own va_list definition first. Then
>>> when it pulled in stdio.h via the system header files, they pulled in a
>>> different va_list as illustrated in the series of include provided by the
>>> error message. Probably, then, the problem is that everybody is using
>>> preprocessor definitions for va_list, and because the tokens that clang
>>> uses (a builtin expression) is different from the struct that tcc uses, tcc
>>> can't figure out that the two are actually compatible. If that's the case,
>>> I'm not entirely sure how to go about fixing the problem.
>>>
>>>
>>>> 
>>>>>
>>>>
>>>> Normal BSDs use the sysv ELF psABI, so better have the same definition
>>>> of va_list like in TCCs .  Darwin uses the same layout as sysv as
>>>> well.  What could happen is that there are some (and different) type
>>>> aliases in between va_list and the real struct type.
>>>>
>>>> 
>>>>>
>>>>
>>>> Solaris as well.
>>>>
>>>> TCC's handling of variable argument lists are spelled out in stdarg.h,
>>>>> with implementation in libtcc1.c. I think that for 64-bit machines, we
>>>>> should also check for clang, and then use clang-compatible definitions. I
>>>>> think I could just check if __llvm__ and/or __clang__ are defined, and 
>>>>> then
>>>>> insert the appropriate definitions. Does this sound right?
>>>>>
>>>>
>>>> Not quite.  The definition of va_list depends on the system, not on the
>>>> compiler.  clang can be used with different 

Re: [Tinycc-devel] Compiling to memory

[David Mertens]

Hello Philip,

Yes, you can allocate your own memory block where you want the compiled
code to be placed. I think it was one of the pointer arguments to
tcc_compile(), but I don't quite remember off the top of my head. Check the
comments in libtcc.h, I believe it's specified there. Let me know if you
can't find it.

David

On Sat, Jul 23, 2016 at 12:53 PM, Philip Picard 
wrote:

> I am emulating a fantasy computer based on a late 1980s computer. I did
> not want to write my own C compiler for this fantasy computer so I want to
> port TCC. However the main road block I have encountered is controlling
> where TCC compiles when it compiles to memory. For this emulator I need to
> control specifically where in the block of memory the code is located. With
> the TO_MEMORY option can I somehow change where in memory the binary code
> is placed?
>
>
>
> Thanks,
>
> Philip
>
>
>
> Sent from Mail  for
> Windows 10
>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc_add_symbol with macros

[David Mertens]

Hello Joel,

As I understand it, tcc_add_symbol only adds things that can be pointed to.
In your case, gdispClear is not something that can be pointed to, it's just
a macro, i.e. an instruction to the compiler on how to produce C code.
Functions and global variables can be pointed to, so they are the
appropriate targets for tcc_add_symbol. You should add those.

But, what exactly are you trying to accomplish? You probably want to
provide the macro-exposed interface to consuming code. In that case, you
could do the following one-two punch: add preprocessor definitions with
tcc_define_symbol, and then add the symbol to the function itself with
tcc_add_symbol. Also be sure to tcc_add_symbol GDISP. If you have to do
this with a bunch of functions, you might consider wrapping that work in a
script of some sort, but I leave that decision up to you. (If you work with
Perl---and if you work with Cygwin then you should have Perl
available---I'd be happy to figure out something, but I'd need a bit more
information about the specific headers.)

David

On Thu, Jul 14, 2016 at 1:38 PM, Joel Bodenmann  wrote:

> Hi folks,
>
>
>
> I am using libtcc. So far everything is going smoothly. Now I’d like to
> make some “built-in” functions available to the program that is being
> compiled as shown with the add() function in the libtcc_test.c example. It
> works well with pure C functions, however, in my library that I would like
> to use I have functions and macros like this:
>
>
>
> void gdispGClear(GDisplay* g, color_t color);
>
> #define gdispClear(c) gdispGClear(GDISP, c)
>
>
>
> void gdispGDrawPixel(GDisplay* g, coord_t x, coord_t y, color_t color);
>
> #define gdispDrawPixel(x,y,c) gdispGDrawPixel(GDISP,x,y,c)
>
>
>
> And so on… GDISP is a global variable in the file that declares those
> functions, something like a “default value”.
>
> Using tcc_add_symbol() on the functions themselves (eg. gdispGClear())
> works well, however, I’d like to use tcc_add_symbol() with gdispClear()
> instead. Sadly that doesn’t compile. I get the following error:
>
>
>
> ‘gdispClear’ undeclared (first use in this function)
>
>
>
> I think that I understand why that doesn’t work. However, is there still a
> workaround to get this working?
>
>
>
>
>
> Thank you for your help & best regards,
>
> ~ Joel
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Trouble on x86-64, not windows, not gcc

[David Mertens]

I found a copy of Apple's _va_list.h header file:

http://opensource.apple.com/source/xnu/xnu-3248.20.55/bsd/sys/_types/_va_list.h

The offending lines are:

#ifndef _VA_LIST_T
#define _VA_LIST_Ttypedef __darwin_va_list va_list;
#endif /* _VA_LIST_T */

Perhaps our stdarg.h should #define _VA_LIST_T?

On Sun, Jul 10, 2016 at 3:13 PM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Well bother, the cpantesters site appears to be experiencing intermittent
> trouble at the moment. If you try to read the full report on cpantesters,
> you may need to hit "refresh" a few times.
>
> On Sun, Jul 10, 2016 at 3:06 PM, David Mertens <dcmertens.p...@gmail.com>
> wrote:
>
>> Hello Michael,
>>
>> Thanks for your reply, and for explaining things. A few points of
>> clarification are in order.
>>
>> On Sun, Jul 10, 2016 at 1:21 PM, Michael Matz <matz@frakked.de>
>> wrote:
>>
>>> On Sat, 9 Jul 2016, David Mertens wrote:
>>>
>>> When run on Mac systems, I get errors about "incompatible redefinition of
>>>> 'va_list'".
>>>>
>>>
>>> Is that the message from TCC or from some other compiler?  The other
>>> compiler should use its own , not TCCs version.  If the message
>>> comes from TCC, what are the two definitions of va_list and where does the
>>> one not coming from TCCs  comes from?
>>>
>>> (Ultimately the layout of va_list has to be compatible between compilers
>>> on the same system anyway; it's dictated by the psABI.)
>>>
>>
>> The error message comes from tcc. The exact text of the error (as well as
>> a preceding warning) is:
>>
>> In file included from test.c:8:
>> In file included from /usr/include/stdio.h:64:
>> /usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler 
>> detected"
>> In file included from test.c:8:
>> In file included from /usr/include/stdio.h:71:
>> /usr/include/sys/_types/_va_list.h:31: error: incompatible redefinition of 
>> 'va_list'
>>
>> I'm assuming that tcc picked up its own va_list definition first. Then
>> when it pulled in stdio.h via the system header files, they pulled in a
>> different va_list as illustrated in the series of include provided by the
>> error message. Probably, then, the problem is that everybody is using
>> preprocessor definitions for va_list, and because the tokens that clang
>> uses (a builtin expression) is different from the struct that tcc uses, tcc
>> can't figure out that the two are actually compatible. If that's the case,
>> I'm not entirely sure how to go about fixing the problem.
>>
>>
>>> 
>>>>
>>>
>>> Normal BSDs use the sysv ELF psABI, so better have the same definition
>>> of va_list like in TCCs .  Darwin uses the same layout as sysv as
>>> well.  What could happen is that there are some (and different) type
>>> aliases in between va_list and the real struct type.
>>>
>>> 
>>>>
>>>
>>> Solaris as well.
>>>
>>> TCC's handling of variable argument lists are spelled out in stdarg.h,
>>>> with implementation in libtcc1.c. I think that for 64-bit machines, we
>>>> should also check for clang, and then use clang-compatible definitions. I
>>>> think I could just check if __llvm__ and/or __clang__ are defined, and then
>>>> insert the appropriate definitions. Does this sound right?
>>>>
>>>
>>> Not quite.  The definition of va_list depends on the system, not on the
>>> compiler.  clang can be used with different systems.  So if anything the
>>> appropriate define would be something MacOS/Darwin related.
>>
>>
>> Right, your above explanation makes clear that this idea is not the right
>> approach.
>>
>>
>>> I'd be happy to work on a solution, but I don't have access to a Mac
>>>> machine
>>>> or a BSD system. I'm not interested in going through a full-on BSD
>>>> installation at this time, so if anybody knows where I could find a
>>>> pre-canned BSD virtualbox image with working git and cc, I'd be much
>>>> obliged.
>>>>
>>>
>>> You need some Darwin system to properly solve this.  I wonder how you
>>> get the above error message on Mac if you don't have to Macs?
>>>
>>
>> Quite the puzzle, isn't it. (・_・ヾ
>>
>> This error comes from a CPAN test report for Alien::TinyCCx, a perl
>> distribution of mine that distributes tcc with extended symbol table
&

Re: [Tinycc-devel] Trouble on x86-64, not windows, not gcc

[David Mertens]

Well bother, the cpantesters site appears to be experiencing intermittent
trouble at the moment. If you try to read the full report on cpantesters,
you may need to hit "refresh" a few times.

On Sun, Jul 10, 2016 at 3:06 PM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Hello Michael,
>
> Thanks for your reply, and for explaining things. A few points of
> clarification are in order.
>
> On Sun, Jul 10, 2016 at 1:21 PM, Michael Matz <matz@frakked.de> wrote:
>
>> On Sat, 9 Jul 2016, David Mertens wrote:
>>
>> When run on Mac systems, I get errors about "incompatible redefinition of
>>> 'va_list'".
>>>
>>
>> Is that the message from TCC or from some other compiler?  The other
>> compiler should use its own , not TCCs version.  If the message
>> comes from TCC, what are the two definitions of va_list and where does the
>> one not coming from TCCs  comes from?
>>
>> (Ultimately the layout of va_list has to be compatible between compilers
>> on the same system anyway; it's dictated by the psABI.)
>>
>
> The error message comes from tcc. The exact text of the error (as well as
> a preceding warning) is:
>
> In file included from test.c:8:
> In file included from /usr/include/stdio.h:64:
> /usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler detected"
> In file included from test.c:8:
> In file included from /usr/include/stdio.h:71:
> /usr/include/sys/_types/_va_list.h:31: error: incompatible redefinition of 
> 'va_list'
>
> I'm assuming that tcc picked up its own va_list definition first. Then
> when it pulled in stdio.h via the system header files, they pulled in a
> different va_list as illustrated in the series of include provided by the
> error message. Probably, then, the problem is that everybody is using
> preprocessor definitions for va_list, and because the tokens that clang
> uses (a builtin expression) is different from the struct that tcc uses, tcc
> can't figure out that the two are actually compatible. If that's the case,
> I'm not entirely sure how to go about fixing the problem.
>
>
>> 
>>>
>>
>> Normal BSDs use the sysv ELF psABI, so better have the same definition of
>> va_list like in TCCs .  Darwin uses the same layout as sysv as
>> well.  What could happen is that there are some (and different) type
>> aliases in between va_list and the real struct type.
>>
>> 
>>>
>>
>> Solaris as well.
>>
>> TCC's handling of variable argument lists are spelled out in stdarg.h,
>>> with implementation in libtcc1.c. I think that for 64-bit machines, we
>>> should also check for clang, and then use clang-compatible definitions. I
>>> think I could just check if __llvm__ and/or __clang__ are defined, and then
>>> insert the appropriate definitions. Does this sound right?
>>>
>>
>> Not quite.  The definition of va_list depends on the system, not on the
>> compiler.  clang can be used with different systems.  So if anything the
>> appropriate define would be something MacOS/Darwin related.
>
>
> Right, your above explanation makes clear that this idea is not the right
> approach.
>
>
>> I'd be happy to work on a solution, but I don't have access to a Mac
>>> machine
>>> or a BSD system. I'm not interested in going through a full-on BSD
>>> installation at this time, so if anybody knows where I could find a
>>> pre-canned BSD virtualbox image with working git and cc, I'd be much
>>> obliged.
>>>
>>
>> You need some Darwin system to properly solve this.  I wonder how you get
>> the above error message on Mac if you don't have to Macs?
>>
>
> Quite the puzzle, isn't it. (・_・ヾ
>
> This error comes from a CPAN test report for Alien::TinyCCx, a perl
> distribution of mine that distributes tcc with extended symbol table
> support. The full test report can be found at
> http://www.cpantesters.org/cpan/report/b1b60820-29ae-11e6-9071-5d9dc272c7fc,
> with thanks to Nigel Horne for setting up his automated Mac testers. I
> cannot believe that this error is due to the exsymtab work, but if there is
> any concern, I can update a similar distribution, Alien::TinyCC, which is
> supposed to distribute the main tcc. We could then wait a few days for the
> smoke testers to pick it up and test it. It is a rather slow iteration
> cycle.
>
> For what it's worth, I didn't get these errors on the Macs I used to have
> access to (machines used for data acquisition in intro physics labs), and I
> strongly suspect they were older 32-bit machines. I may soon have access to
> Macs at 

Re: [Tinycc-devel] Trouble on x86-64, not windows, not gcc

[David Mertens]

Hello Michael,

Thanks for your reply, and for explaining things. A few points of
clarification are in order.

On Sun, Jul 10, 2016 at 1:21 PM, Michael Matz <matz@frakked.de> wrote:

> On Sat, 9 Jul 2016, David Mertens wrote:
>
> When run on Mac systems, I get errors about "incompatible redefinition of
>> 'va_list'".
>>
>
> Is that the message from TCC or from some other compiler?  The other
> compiler should use its own , not TCCs version.  If the message
> comes from TCC, what are the two definitions of va_list and where does the
> one not coming from TCCs  comes from?
>
> (Ultimately the layout of va_list has to be compatible between compilers
> on the same system anyway; it's dictated by the psABI.)
>

The error message comes from tcc. The exact text of the error (as well as a
preceding warning) is:

In file included from test.c:8:
In file included from /usr/include/stdio.h:64:
/usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler detected"
In file included from test.c:8:
In file included from /usr/include/stdio.h:71:
/usr/include/sys/_types/_va_list.h:31: error: incompatible
redefinition of 'va_list'

I'm assuming that tcc picked up its own va_list definition first. Then when
it pulled in stdio.h via the system header files, they pulled in a
different va_list as illustrated in the series of include provided by the
error message. Probably, then, the problem is that everybody is using
preprocessor definitions for va_list, and because the tokens that clang
uses (a builtin expression) is different from the struct that tcc uses, tcc
can't figure out that the two are actually compatible. If that's the case,
I'm not entirely sure how to go about fixing the problem.


> 
>>
>
> Normal BSDs use the sysv ELF psABI, so better have the same definition of
> va_list like in TCCs .  Darwin uses the same layout as sysv as
> well.  What could happen is that there are some (and different) type
> aliases in between va_list and the real struct type.
>
> 
>>
>
> Solaris as well.
>
> TCC's handling of variable argument lists are spelled out in stdarg.h,
>> with implementation in libtcc1.c. I think that for 64-bit machines, we
>> should also check for clang, and then use clang-compatible definitions. I
>> think I could just check if __llvm__ and/or __clang__ are defined, and then
>> insert the appropriate definitions. Does this sound right?
>>
>
> Not quite.  The definition of va_list depends on the system, not on the
> compiler.  clang can be used with different systems.  So if anything the
> appropriate define would be something MacOS/Darwin related.


Right, your above explanation makes clear that this idea is not the right
approach.


> I'd be happy to work on a solution, but I don't have access to a Mac
>> machine
>> or a BSD system. I'm not interested in going through a full-on BSD
>> installation at this time, so if anybody knows where I could find a
>> pre-canned BSD virtualbox image with working git and cc, I'd be much
>> obliged.
>>
>
> You need some Darwin system to properly solve this.  I wonder how you get
> the above error message on Mac if you don't have to Macs?
>

Quite the puzzle, isn't it. (・_・ヾ

This error comes from a CPAN test report for Alien::TinyCCx, a perl
distribution of mine that distributes tcc with extended symbol table
support. The full test report can be found at
http://www.cpantesters.org/cpan/report/b1b60820-29ae-11e6-9071-5d9dc272c7fc,
with thanks to Nigel Horne for setting up his automated Mac testers. I
cannot believe that this error is due to the exsymtab work, but if there is
any concern, I can update a similar distribution, Alien::TinyCC, which is
supposed to distribute the main tcc. We could then wait a few days for the
smoke testers to pick it up and test it. It is a rather slow iteration
cycle.

For what it's worth, I didn't get these errors on the Macs I used to have
access to (machines used for data acquisition in intro physics labs), and I
strongly suspect they were older 32-bit machines. I may soon have access to
Macs at work, but I'm in between jobs at the moment, and so I can't test
this myself.

@grishka, I was actually considering an approach that you had committed
quite a bit earlier:
http://repo.or.cz/tinycc.git/commitdiff/dc251a7d8d8bb4fb57773790152bfe85236f5f12#patch2

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Trouble on x86-64, not windows, not gcc

[David Mertens]

Hello everyone,

When run on Mac systems, I get errors about "incompatible redefinition of
'va_list'". Looking at the source files involved, I'm pretty sure this
occurs on x86-64 systems that are neither Windows nor built with gcc. Such
systems include 64-bit Macs and BSDs using clang. It might also occur on
Solaris, though I've not received any reports from that system yet.

TCC's handling of variable argument lists are spelled out in stdarg.h
, with
implementation
in libtcc1.c
. I think
that for 64-bit machines, we should also check for clang, and then use
clang-compatible
definitions . I think I could
just check if __llvm__ and/or __clang__ are defined
,
and then insert the appropriate definitions. Does this sound right? I am a
bit out of my depth working on such things, so if anybody has any ideas
about how to solve this, I'm all ears.

I'd be happy to work on a solution, but I don't have access to a Mac
machine or a BSD system. I'm not interested in going through a full-on BSD
installation at this time, so if anybody knows where I could find a
pre-canned BSD virtualbox image with working git and cc, I'd be much
obliged.

Thanks!
David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] -Wl,-rpath not passed through?

[David Mertens]

Nice. I am not very familiar with this part of tcc, but I noticed the use
of ':' as a path separator. Is this the path separator used across all
platforms? In particular, what about Windows?

Also, I am not sure what others think about the first line in which you
declare two integers and initialize them with the return values of function
calls. I guess that's fine, but I don't see it often in the codebase.
@Everyone, do we have a coding standard about this?

David

On Sat, Jun 4, 2016 at 9:46 AM, Steffen Nurpmeso  wrote:

> Hi!
>
> Pretty stormy here, huh?
>
> i wrote:
>  |Hello again!
>  |
>  |I have just recognized that i need to use -Wl,-rpath now (new
>
>  |So then, here we go:
>  |  ?0[steffen@wales nail.git]$ readelf -d s-nail
>
>  |   0x000f (RPATH)  Library rpath: [/usr/lib]
>
>  |This is still true for [mob:1ca685f], but which no longer needs
>  |a cherry-picked commit to do it.  Cool!  :-)
>
> With the attached diff we get
>
>   ?0[steffen@wales nail.git]$ readelf -d s-nail
>   Dynamic section at offset 0xf6a78 contains 19 entries:
> TagType Name/Value
>0x0001 (NEEDED) Shared library: [libssl.so.1.1]
>0x0001 (NEEDED) Shared library:
> [libcrypto.so.1.1]
>
>0x000f (RPATH)  Library rpath:
> [/home/steffen/usr/opt/.ssl-1.1.0/lib:/home/steffen/usr/lib:/home/steffen/usr/opt/tcc-mob/lib:/home/steffen/usr/opt/pcc/lib:/lib:/usr/local/lib:/usr/lib]
>
> Yay.
> Ciao!
>
> --steffen
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc port to cygwin

[David Mertens]

Hello Chris,

According to ack, "skip(')')" shows up all over the place in tccgen.c. What
does line 196 of your sys/reent.h look like?

Also, if I started from a pristine Windows installation with a core Cygwin
installation, which Cygwin packages would I need to install to get to where
you are?

David

On Fri, May 20, 2016 at 8:24 AM, Chris Marshall 
wrote:

> Atttached is a first cut port of the TinyCC build to the cygwin platform.
>
> The mains problems seem to be from managing the different include files.
> I hand added some defines to libtcc1.c for __INTPTR_TYPE__ and a few
> others to get that to build.
>
> However, it is now failing to build bcheck.c with:
>
> >  ../tcc -B.. -c bcheck.c -o x86_64/bcheck.o -I.. -Wall -g -O0
> -Wdeclaration-after-statement -Wno-deprecated-declarations
> -Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result
> -Wno-uninitialized -fno-strict-aliasing -fPIC -DTCC_TARGET_X86_64
> >  In file included from bcheck.c:20:
> >  In file included from /usr/include/stdlib.h:18:
> >  /usr/include/sys/reent.h:196: error: ')' expected (got "*")
> >  Makefile:116: recipe for target 'x86_64/bcheck.o' failed
> >  make[1]: *** [x86_64/bcheck.o] Error 1
>
> Looking at the origin of the error message in the skip() routine
> in tccpp.c, I could not find any place that skip() was called with
> an argument of ')'.  Is there some other place that message
> could be coming from.  Seems like it might be a possible
> problem in the preprocessing
>
> --Chris
>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc compilation on MSYS2

[David Mertens]

Hey Chris,

The latest tcc work is in the mob branch, and there have been preprocessor
fixes in there recently. You should definitely work off of that branch.

David

On Thu, May 19, 2016 at 2:10 PM, Chris Marshall 
wrote:

> It looks like this is definitely a bug in the version of tcc git I have.
> At least the error message I'm getting in the code does not appear
> to be possible since the error call is from skip() but there are no
> calls to skip() that could have the ')' as reported in the error so
> something is off-by-one or something.
>
> Will try the current git mob next.
>
> --Chris
>
> On Thu, May 19, 2016 at 1:49 PM, Chris Marshall 
> wrote:
>
>> Is it possible that this could be a bug in the tcc preprocessing?
>>
>> On Thu, May 19, 2016 at 10:33 AM, Chris Marshall 
>> wrote:
>>
>>> Thanks for the help.
>>>
>>> I've got tcc building but the bcheck.c compile is failing
>>> when the stdlib.h is pulled in.  My next step is to try
>>> the same with the latest tcc git.  I'm not sure what the
>>> best way to proceed woud be.  The top level gcc build
>>> can correctly (for cygwin) process the various system
>>> include files.  It is only when tcc tries to process those
>>> same files that the problems start.  Maybe there is a
>>> wayto use the gcc step to generate a tcc version of the
>>> include files.
>>>
>>>
>>>
>>>
>>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] spawnvp V.S. _spawnvp on Windows

[David Mertens]

Hello Christian,

That was an annoying warning. You patch works for me on my flavors of
Windows on the toolchain provided by Strawberry Perl. Thanks!

David

On Tue, May 17, 2016 at 12:23 AM, Christian Jullien 
wrote:

> I pushed this small patch:
>
>
>
> diff --git a/tcc.c
> 
> b/tcc.c
> 
>
> index 93ed4de
> 
> ..b340d9b
> 
> 100644 (file)
>
> --- a/tcc.c
> 
>
> +++ b/tcc.c
> 
>
> @@ -133,7
> 
> +133,7
> 
> @@ static void help(void)
>
>  #include 
>
>  static int execvp_win32(const char *prog, char **argv)
>
>  {
>
> -int ret = spawnvp(P_NOWAIT, prog, (const char *const*)argv);
>
> +int ret = _spawnvp(P_NOWAIT, prog, (const char *const*)argv);
>
>  if (-1 == ret)
>
>  return ret;
>
>  cwait(, ret, WAIT_CHILD);
>
>
>
>
>
> *From:* Tinycc-devel [mailto:tinycc-devel-bounces+eligis=
> orange...@nongnu.org] *On Behalf Of *Christian Jullien
> *Sent:* lundi 16 mai 2016 10:12
> *To:* tinycc-devel@nongnu.org
> *Subject:* [Tinycc-devel] spawnvp V.S. _spawnvp on Windows
>
>
>
> Hi,
>
>
>
> When I build tinycc on Windows (both 32/64 bit).
>
>
>
> I always get this warning:
>
>
>
> ../tcc.c:136:39: warning: passing argument 3 of 'spawnvp' from
> incompatible pointer type [-Wincompatible-pointer-types]
>
>  int ret = spawnvp(P_NOWAIT, prog, (const char *const*)argv);
>
>
>
> Looking a spawnvp documentation from Microsoft, I get:
>
>
>
> This POSIX function is deprecated. Use the ISO C++ conformant spawnvp
> instead.
>
>
>
> So I replaced spawnvp by _spawnvp and no more warning when using
> mingw32/64 gcc compilers.
>
>
>
> Please Windows maintainer (if any), can you consider this very simple
> change?
>
>
>
> Christian
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc compilation on MSYS2

[David Mertens]

On Sat, May 14, 2016 at 3:27 PM, grischka  wrote:

> Chris Marshall wrote: ---
>
>> To be more specific, it should be possible to build the mingw version of
>> tcc on cygwin (I don't know, haven't had time to try) but what I would like
>> is the linux/unix version---if it builds on unix, it should be buildable on
>> cygwin---as long as you don't look under the covers to find windows.
>>
>
> Probably you could do that.  It is just that you'll find that
> such (almost true) linux/unix version of tcc will produce
> (entirely) true linux/unix programs.  And these will not
> run on windows, not even under cygwin.
>
> -- gr
>

This is already the case on Macs, but we still go to some lengths to
support it anyway. And, just as with Macs, even if the compiled executables
cannot be run on Windows, the memory output can be run. Knowing Chris, I'm
pretty sure this is what he is most interested in. :-)

Chris, what happens if you run ./configure on Cygwin?

David
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc compilation on MSYS2

[David Mertens]

Hello Sergey,

Is this an issue with the standard Makefile, or with the Windows-specific
build batch (.BAT) file? FWIW, the batch file build-process works in at
least some of the mingw setups provided by Strawberry Perl.

David

On Sat, May 14, 2016 at 3:24 AM, Sergey Korshunoff  wrote:

> MSYS2 is current environment for Qt and other software development on
> Windows. It is a mingw+cygwin with a package manager (pacman), ported
> from ARCH Linux. MSYS2 allow to build
> mingw32/mingw64/cygwin32/cygwin64 programs in unix-like environment.
> Currenly tcc can not be build on this environment (mix of unix and
> windows). I think a system name (uname output) is needed to
> select/reject some code in sources of the tcc.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] patches for discussion

[David Mertens]

Here is my take on this:

__LLP64__ macro -> very short patch. I don't think there's any problem
defining this. But then, to quote wikipedia's article on 64-bit_computing,
"C code should prefer (u)intptr_t instead of long when casting pointers
into integer objects." I would argue this should be added to mob.

short_call -> small patch, looks like it solves a good and important
problem with return-value handling. I strongly believe this should be added
to mob.

whole-archive -> this is not a small patch, and it adds functionality which
I believe is not crucial to the purpose of tcc. In the interest of keeping
tcc's codebase small, I would lean toward not adding it.

That said, I am certainly not a gate keeper. I would wait to hear from
others before doing anything.

David

On Fri, May 13, 2016 at 10:41 AM, Sergey Korshunoff 
wrote:

> I have the following patches in github repo (requests in tinycc bugzilla):
>
> + memory model macros __{L,}LP64__
>
> https://github.com/seyko2/tinycc/commit/eb2a3a8ae941817a5bea7e561999b4c463873a0f
>
> + short_call_convention
>
> https://github.com/seyko2/tinycc/commit/558614d3f822de03bb6267f47a24487faa69d29a
>
> + --whole-archive support
>
> https://github.com/seyko2/tinycc/commit/65e42df4d0fedb340f42652bb49fdacc7bc3e05c
>
> PS: there is request (Bugzilla) to implement
> bug #37244: tinycc: lacks -nostartfiles -nodefaultlibs support, needed by
> Wine
> http://savannah.nongnu.org/bugs/?37244
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Do you know of any forks of TinyCC?

[David Mertens]

On Ubuntu I get segfaults when it tries to run the sample program you
provided, but I managed to figure out the compile and link flags, at least.

Add this to the top of the tcc source:

#include 
#include 
#include 
void expr(void);
void decl(int);

and compile like so:

gcc -Wno-int-conversion -Wno-implicit-int -o tcc tcc.c -ldl

That'll produce a tcc that will compile the provided source code, and then
segfault when it tries to run it. :-)

David

On Sat, May 7, 2016 at 5:05 AM, grischka <gris...@gmx.de> wrote:

> David Mertens wrote: ---
>
>> Nope. I had to learn by diving into the source myself. But if you want to
>> learn the process of compilation, you should just try to follow the series
>> of function calls to compile code.
>>
>
> First commits to tinycc are from 2001
>
> http://repo.or.cz/tinycc.git/shortlog/18a8013fe71a63633948bc40412f7939fe34907d
>
> They are functional AFAICS, on i386.
>
> For example download a snapshot (7kB) from Fabrice Bellard's initial
> revision
>
> http://repo.or.cz/tinycc.git/snapshot/27f6e16bae9d0f73acec07f61aea696ab5adc680.tar.gz
>
> add this on top of tcc.c ->
>   void expr(void);
>   void decl(int);
>   #ifdef _WIN32
>   #include 
>   void *dlsym(int x, const char *func) {
>   return GetProcAddress(GetModuleHandle("msvcrt"), func);
>   }
>   #endif
> <---
>
> compile:
>   $ gcc tcc.c -o tcc
> or
>   $ cl -MD tcc.c
>
> create hello.c ->
>   #define HELLO "Hello!\n"
>   int main (int argc, char **argv)
>   {
>   int i;
>   printf(HELLO);
>   i = 0;
>   while (i < argc) {
>   printf("arg %d = %s\n", i, argv[i]);
>   i++;
>   }
>   return 0;
>   }
> <---
>
> and run it:
>   $ tcc hello.c 111 222 333
>
>   Hello!
>   arg 0 = hello.c
>   arg 1 = 111
>   arg 2 = 222
>   arg 3 = 333
>
> As you can see, it works.  With preprocessor and all. ;)
>
> -- gr
>
>
> On Fri, May 6, 2016 at 1:16 AM, <mzlap...@tuta.io> wrote:
>>
>> I want to understand how TCC works, in the way it is now it confuses me
>>> greatly. Maybe you know of some forks that maybe dropped some of it's
>>> features and made source a bit easier to understand? Or, maybe I should
>>> look at some old enough commit, before TCC learned to compile asm code,
>>> and
>>> things of this sort?
>>>
>>>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Do you know of any forks of TinyCC?

[David Mertens]

As to your specific question, I have a fork of tcc, but it makes things
more complicated, not less. A fork of tcc that simplifies things would be
great, I think.

David

On Fri, May 6, 2016 at 9:07 AM, David Mertens <dcmertens.p...@gmail.com>
wrote:

> Nope. I had to learn by diving into the source myself. But if you want to
> learn the process of compilation, you should just try to follow the series
> of function calls to compile code. You could, for example, load tcc in gdb
> and set a breakpoint on one of the parsing functions, then look at the
> stack trace. This is how I really started to get my head wrapped around
> tcc's parsing, at least.
>
> David
>
> On Fri, May 6, 2016 at 1:16 AM, <mzlap...@tuta.io> wrote:
>
>> I want to understand how TCC works, in the way it is now it confuses me
>> greatly. Maybe you know of some forks that maybe dropped some of it's
>> features and made source a bit easier to understand? Or, maybe I should
>> look at some old enough commit, before TCC learned to compile asm code, and
>> things of this sort?
>>
>> ___
>> Tinycc-devel mailing list
>> Tinycc-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
>>
>
>
> --
>  "Debugging is twice as hard as writing the code in the first place.
>   Therefore, if you write the code as cleverly as possible, you are,
>   by definition, not smart enough to debug it." -- Brian Kernighan
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Do you know of any forks of TinyCC?

[David Mertens]

Nope. I had to learn by diving into the source myself. But if you want to
learn the process of compilation, you should just try to follow the series
of function calls to compile code. You could, for example, load tcc in gdb
and set a breakpoint on one of the parsing functions, then look at the
stack trace. This is how I really started to get my head wrapped around
tcc's parsing, at least.

David

On Fri, May 6, 2016 at 1:16 AM,  wrote:

> I want to understand how TCC works, in the way it is now it confuses me
> greatly. Maybe you know of some forks that maybe dropped some of it's
> features and made source a bit easier to understand? Or, maybe I should
> look at some old enough commit, before TCC learned to compile asm code, and
> things of this sort?
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Inserting spaces in output from -E

[David Mertens]

On Thu, May 5, 2016 at 4:57 PM, grischka <gris...@gmx.de> wrote:

> David Mertens wrote: ---
>
>>
>> Just as a point of context, I am now maintaining the exsymtab work as a
>> fork of the current mob, so any changes that are made have to be merged.
>> In
>> other words, I'm a downstream consumer of tcc. This morning I got a merge
>> conflict with these define print functions that you removed. I sure am
>> glad
>> you happened to mention this work off-hand, or I would have had no idea
>> why
>> I had a conflict.
>>
>
> I can imagine, but then again I'd maybe put the extended bit into
> the TokenSym rather than on the token number,  Like
>
> int is_extended = table_ident[v - TOK_IDENT]->is_extended;
>
> ... if I knew your code which I don't.
>
> -- gr


As it turns out, the conflict on the print statements had nothing to do
with my own work, which is one reason why I was so confused and annoyed
with the issue to begin with.

As to your suggestion, I thought about it. Adding a whole byte when I only
needed one bit seemed like an unnecessary use of memory. This is not much
of an argument, though: as best I can tell (haven't directly measured in a
while), there are only a few thousand tokens in a moderately large project
such as perl.h. For any real project, we're probably talking about less
than a kilobyte in additional memory. At any rate, I found 'room' in the
high bits, and as Sergey mentioned (and as you have argued in the past), it
doesn't impose a practical restriction on the number of available tokens.

David
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Commit caebbc3 breaks test 60 (enum redefinition)

[David Mertens]

Hello grischka,

Your commit caebbc3, "tccgen: scope levels for local symbols", breaks test
60_enum_redefinition on 32-bit Ubuntu 15.10. The test should error out
saying "error: struct/union/enum already defined", but now it errors saying
"main not defined". If a trivial main is added, it does not produce any
errors. So your change apparently removed a previously tested bit of error
reporting.

Let me know if you need more specifics about my platform to figure out the
problem.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Inserting spaces in output from -E

[David Mertens]

grischka,

wtf is this? Commit fe845cf is huge, and looks like it's messing with a
lot. You may know what you're doing, but onlookers will observe your
behavior and think, "Oh, it's OK if I push a huge, opinionated changeset to
mob without discussion." I don't think this is the kind of culture you want
to encourage around tcc development. In particular, you should have split
these changes across multiple commits and put a little more explanation
into what you're doing in the commit messages. You also should avoid
removal of command-line options without discussion.

Just as a point of context, I am now maintaining the exsymtab work as a
fork of the current mob, so any changes that are made have to be merged. In
other words, I'm a downstream consumer of tcc. This morning I got a merge
conflict with these define print functions that you removed. I sure am glad
you happened to mention this work off-hand, or I would have had no idea why
I had a conflict.

More conversation is better in this context.
David

On Thu, May 5, 2016 at 8:21 AM, grischka  wrote:

> Vladimir Vissoultchev wrote: ---
>
>> One remark: I believe in the tcc_preprocess routine s1->ppfp is always
>>> set, otherwise it wouldn't have been called.
>>>
>>
>> I think it can be NULL when dffp is set for the dflag output when dumping
>> defines only (w/o actual preprocessor output).
>>
>
> There is no dffp.
>
> Nor is there any -E output from outside of tcc_preprocess, in
> particular not from within the input file parser. ;)
>
>
> http://repo.or.cz/tinycc.git/commitdiff/fe845cf53da206bb28f6b49a0878b0118b4f242b
>
> -- gr
>
>
> cheers,
>> 
>>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] bug #47379: Compare bug

[David Mertens]

I can confirm on 32-bit. I realize you were asking for 64 bit, but I don't
have that handy.

On Mon, May 2, 2016 at 12:08 AM, Sergey Korshunoff  wrote:

> bug #47379: Compare bug
> Please test/confirm on x86-64 (no bug on x86 Linux)
>
> include 
> #include 
> int main(int argc, char* argv[]) {
> printf("%d\n", -2147483648);
> printf("%ld\n", -2147483648LL);
> printf("%d\n", (1LL) < (-2147483648LL));
> return 0;
> }
>
> tcc output:
> -2147483648
> -2147483648
> 1
>
> gcc output:
> -2147483648
> -2147483648
> 0
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc build on OSX

[David Mertens]

Hello Assaf,

On Sun, May 1, 2016 at 6:03 PM, Assaf Gordon  wrote:

> Hello,
>
> I can try to test some things on Mac OS X (10.10.4 with clang-602.0.53).
> please let me know if there are specific tests to do.
>

That would be great!


> from a cursory look, perhaps it is possible that 'tcc' still compiles
> linux/ELF format despite being on Mac?
>

That is correct. It does produce proper machine code, however. This means
that tcc can be used when invoked with the -run command-line option, and it
can be used a jit compiler. So, I think the output that you give below
makes sense.

David


> regards,
>  - gordon
>
>
> ===
> $ uname
> Darwin x 14.4.0 Darwin Kernel Version 14.4.0: Thu May 28 11:35:04 PDT
> 2015; root:xnu-2782.30.5~1/RELEASE_X86_64 x86_64 i386 MacBookAir6,1 Darwin
>
> $ git id
> release_0_9_26-676-g6afe668
>
> $ make distclean
> $ ./configure
> ./configure
> Binary  directory   /usr/local/bin
> TinyCC directory/usr/local/lib/tcc
> Library directory   /usr/local/lib64
> Include directory   /usr/local/include
> Manual directory/usr/local/share/man
> Info directory  /usr/local/share/info
> Doc directory   /usr/local/share/doc//usr/local/lib/tcc
> Target root prefix
> Source path  /Users/gordon/sources/tinycc
> C compiler   gcc
> cross compilers  no
> Target CPU   x86-64
> Host OS  Darwin
> Target OSDarwin
> Big Endian   no
> gprof enabledno
> use libgcc   no
> Creating config.mak and config.h
>
> $ make
>
> $ ./tcc -v
> tcc version 0.9.26 (x86-64 Linux)
>
> $ cat 1.c
> #include 
>
> int main()
> {
>   printf("hello TCC world\n");
>   return 0;
> }
>
> $ ./tcc -c -o 1.o 1.c
> In file included from 1.c:1:
> In file included from /usr/include/stdio.h:64:
> /usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler
> detected"
>
> $ file 1.o
> 1.o: ELF 64-bit LSB relocatable, x86-64, version 1 (SYSV), not stripped
>
> $ ./tcc -o 1 1.c
> tcc: error: file 'crt1.o' not found
> tcc: error: file 'crti.o' not found
> In file included from 1.c:1:
> In file included from /usr/include/stdio.h:64:
> /usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler
> detected"
> tcc: error: file 'crtn.o' not found
> tcc: error: undefined symbol 'printf'
> ===
>
>
>
>
> For reference, here's the compilation and linking with apple's LLVM:
> ===
> $ cc -v -c -o 1.o 1.c
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.4.0
> Thread model: posix
>  
> "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
> -cc1 -triple x86_64-apple-macosx10.10.0 -emit-obj -mrelax-all -disable-free
> -disable-llvm-verifier -main-file-name 1.c -mrelocation-model pic
> -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu
> core2 -target-linker-version 242.2 -v -dwarf-column-info -coverage-file
> /Users/gordon/sources/tinycc/1.o -resource-dir
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0
> -fdebug-compilation-dir /Users/gordon/sources/tinycc -ferror-limit 19
> -fmessage-length 150 -stack-protector 1 -mstackrealign -fblocks
> -fobjc-runtime=macosx-10.10.0 -fencode-extended-block-signature
> -fmax-type-align=16 -fdiagnostics-show-option -fcolor-diagnostics -o 1.o -x
> c 1.c
> clang -cc1 version 6.1.0 based upon LLVM 3.6.0svn default target
> x86_64-apple-darwin14.4.0
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/local/include
>
>  
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/include
>
>  
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/include
>  /usr/include
>  /System/Library/Frameworks (framework directory)
>  /Library/Frameworks (framework directory)
> End of search list.
>
> $ file 1.o
> 1.o: Mach-O 64-bit object x86_64
>
> $ cc -v -o 1 1.o
> Apple LLVM version 6.1.0 (clang-602.0.53) (based on LLVM 3.6.0svn)
> Target: x86_64-apple-darwin14.4.0
> Thread model: posix
>  
> "/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld"
> -demangle -dynamic -arch x86_64 -macosx_version_min 10.10.0 -o 1 1.o
> -lSystem
> /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin/libclang_rt.osx.a
>
> $ file 1
> 1: Mach-O 64-bit executable x86_64
> ===
>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org

Re: [Tinycc-devel] lcall invalid hex code

[David Mertens]

@Sergey,

I have a general request for the patches of yours that you submit in the
future. Could you assume that I don't actually know much at all about
compilers, but I would like to learn? That would be a useful assumption,
because it's true. :-P

Speaking only for myself, I have no idea what this patch practically does.
I can see that it changes one hex value in assembler-related stuff to
something else, but I'm not given enough context to teach myself and make
an assessment. What is invalid? Is the actual constant incorrect, or is the
notation for it in the C code simply incorrect? What did it used to do
before? Do you have any links for assembler op codes so that I might learn
more?

Give me just enough context and I'll teach myself. Thanks!

On Sun, May 1, 2016 at 2:58 PM, Sergey Korshunoff  wrote:

> Hi!
>
> diff --git a/i386-asm.h b/i386-asm.h
> index 486cffe..637568b 100644
> --- a/i386-asm.h
> +++ b/i386-asm.h
> @@ -213,7 +213,7 @@ ALT(DEF_ASM_OP1(jmp, 0xff, 0, OPC_JMP | OPC_WL,
> OPT_REGW))
>  #endif
> .
>  ALT(DEF_ASM_OP2(lcall, 0x9a, 0, 0, OPT_IM16, OPT_IM32))
> -ALT(DEF_ASM_OP1(lcall, 0xff, 3, 0, OPT_EA))
> +ALT(DEF_ASM_OP1(lcall, 0xff1f, 3, 0, OPT_EA))
>  ALT(DEF_ASM_OP2(ljmp, 0xea, 0, 0, OPT_IM16, OPT_IM32))
>  ALT(DEF_ASM_OP1(ljmp, 0xff, 5, 0, OPT_EA))
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc build on OSX

[David Mertens]

Hello Sergey,

I do not know what pipcet was up to here, or why this person decided to
clone my fork of tcc. The author's intent is far from clear, but I think it
has nothing to do with my work.

David

On Sat, Apr 30, 2016 at 12:05 AM, Sergey Korshunoff 
wrote:

> > FYI, I found it helpful (necessary? I don't remember) to include the
> following typedefs when
> > working with Mac:
>
> Thanks. I will play with pipcet version of the tinycc and your (run4flat)
>
> PS: it will be nice if you put a travis-CI build status in README.md
> (as I done following  wqweto) https://github.com/seyko2/tinycc
>
> PPS: I go to place in README.md links to the other usefull branches of the
> tcc:
>
> https://github.com/tinycc/tinycc
>   Mirror from mob branch http://repo.or.cz/w/tinycc.git
>
> https://github.com/pipcet/tinycc
>   tinycc for perl jit?
>
> https://github.com/run4flat/tinycc
>  exsymtab patch/extension main source
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Compilation on Mac

[David Mertens]

assaf,

Thank you! I am not a travis configuration guru, so this configuration file
is very helpful!

David

On Tue, Apr 19, 2016 at 1:30 PM, Assaf Gordon  wrote:

> Hello Sergey,
>
> On 04/19/2016 10:21 AM, Sergey Korshunoff wrote:
>
>> Is there someone who can help to improve current tcc for Mac?
>> Is it possible to download some MacOS ISO (x86)?
>>
>>
> GitHub + Travis-CI can check multiple OSes including OS-X.
>
> The attached change will do so.
>
> Build result example:
>  https://travis-ci.org/agordon/tinycc-mirror/builds/124249388
>
> If you want to take it further and test multiple OS-x versions, something
> like the following will do:
>   https://github.com/agordon/pretest-macos-runs/blob/master/.travis.yml
>
> While this doesn't allow debugging or interactive development, it's better
> than nothing,
> and will keep you posted on whether OS-X builds are broken.
>
>
> regards,
>  - assaf
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] precompiled headers

[David Mertens]

Sergey,

I think your command-line design and output are sensible. I have a
command-line option for producing similar output, but it's much clunkier.
If you want to try your hand at implementing this, feel free to fork my
version of tcc on github and issue a pull request. (You can also issue pull
requests to merge tcc's updates into my fork, if you have work on that.)

David

On Sun, Apr 24, 2016 at 4:13 AM, Sergey Korshunoff <sey...@gmail.com> wrote:

> Hi!
> > David Mertens wrote:
> > If there is an argument to be made for including exsymtab, it would
> probably be based on these results. It is plausible to use symbol table
> caching and serializing/deserializing to avoid loading and parsing standard
> header files. This could potentially reduce compilation times. If you (we?)
> could show measurable performance gains with such a modification, then it
> might get broader support for being included with tcc.
>
> As I see this today. For example, I prefer to speed up tccboot kernel
> compilation.
> A current command to compile is like
>   tcc -o vmlinux linux/kernel/init.c linux/arch/kernel/head.c ...
>
> With -cheaders[=dDIR] option tcc will precompile headers in each *.c
> before  the first C token is seen and create files
> [DIR]linux/kernel/init.tch, [DIR]linux/arch/kernel/head.tch,...  or
> use these files if they already present. I think this is better and
> don't need a special tuning.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] if (0 == 1) { some_code(); }

[David Mertens]

Hello Sergey,

Skipping unneeded code, and not even compiling it, could make tcc a bit
faster. However, as test 78 indicates, any implementation of tcc that skips
blocks will need some logic to detect the presence of labels.

For example, if gvtst detected a static value that would be false, it could
compile the code separately. Then, during the compilation of that block, if
it detected a label, it could add what it compiled the code before moving
on. Otherwise (since there would be no way to get to the code), it could
discard it. The problem with such an approach is that tcc will run slower
(maybe only marginal, but slower nonetheless). The resulting object file
will be smaller, but that's not tcc's primary aim.

If you want the feature without the compilation overhead, a flag might do
it, but I don't like the global nature of that effect. An alternative is to
have a pragma that can be applied and lifted locally. The Perl programmer
in me much prefers the pragma approach, but others may dissent.

David

On Sun, Apr 24, 2016 at 5:53 AM, Sergey Korshunoff  wrote:

> What to do with 78_vla_label test? May be a tcc switch to skip unused code?
> void f1(int argc) {
>   char test[argc];
>   if(0)
>   label:
> printf("boom!\n");
>   if(argc-- == 0)
> return;
>   goto label;
> }
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] First kcachegrind output

[David Mertens]

@Sergey,

If there is an argument to be made for including exsymtab, it would
probably be based on these results. It is plausible to use symbol table
caching and serializing/deserializing to avoid loading and parsing standard
header files. This could potentially reduce compilation times. If you (we?)
could show measurable performance gains with such a modification, then it
might get broader support for being included with tcc.

Just thought I'd put that out there. :-)

David

On Mon, Apr 18, 2016 at 4:59 AM, Vladimir Vissoultchev 
wrote:

> Hi,
>
> This is a very intresting picture although I'm not sure what the numbers on
> it are exactly.
>
> Numbers in the cell must be the Include Percent (100ths of a %) -- time
> spent in the function. Numbers besides arrows look like they are the same
> as
> the number in the cell they point to. And then in parentheses must be the
> number of calls, the arrow pointing from caller to called function?
>
> This inspired me to use VS profiler (already posted results before) on
> latest [mob] to collect perf info and here are some of the results:
> https://github.com/wqweto/tinycc/wiki/profiler-functions
>
> This table is sorted on Exclusive Samples % column (descending) which as
> far
> as I understand represents the percentage of the execution time spent in
> the
> body of the function w/o any time spent calling other functions. So I
> assume
> this must be an approximate indication which is the source code that is
> taking most time to execute.
>
> Also the modules table below it seems shows that ~52% is spent on I/O
> (open/read/close)
>
> cheers,
> 
>
>
> From: Tinycc-devel [mailto:tinycc-devel-bounces+wqweto=
> gmail@nongnu.org]
> On Behalf Of Christian Jullien
> Sent: Monday, April 18, 2016 9:52 AM
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] First kcachegrind output
>
> Same file but using JPG if easier to view.
>
>
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=
> orange...@nongnu.org]
> On Behalf Of Christian Jullien
> Sent: lundi 18 avril 2016 08:42
> To: tinycc-devel@nongnu.org
> Subject: [Tinycc-devel] First kcachegrind output
>
> Hi,
>
> I just had time to see how tcc behaves with callgrind (a valgrind tool) on
> Fedora.
>
> 1) Install required tools
> $ sudo dnf install graphviz valgrind kcachegrind
>
> 2) run tcc on top of callgrind and collect results.
> $ valgrind --tool=callgrind ./tcc -c -I include tccgen.c
>
> 3) See results using collected results.
> kcachegrind callgrind.out.4055 &
>
> This is the tool one should consider before trying to optimize tcc.
>
> Enclosed is a PS export but you can get much more from kcachegrind!
>
> Christian
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Development style

[David Mertens]

Hello Michael,

I committed the revert. Based on what I see at the gitweb for the mob
branch (http://repo.or.cz/tinycc.git/shortlog/refs/heads/mob), it's not
there. I don't see anything between Vlad's commit and the one you pushed an
hour ago.

David

On Fri, Apr 22, 2016 at 9:43 AM, Michael Matz <matz@frakked.de> wrote:

> Hello David,
>
> On Mon, 18 Apr 2016, David Mertens wrote:
>
> > I have nuked that commit.
>
> Thank you for that.  (But you haven't yet committed the revert, right?)
>
> > For time management reasons, my recreational programming goes through a
> > distinct email account, one that I hadn't checked since early January.
> > It might have looked as though I had abandoned my work on exsymtab. I
> > have not, I just put it on hiatus. Today happens to be the day I've
> > checked back, and wow, what a day.
>
> ;-)
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc as compiler for tccboot

[David Mertens]

Hello Sergey,

On Thu, Apr 21, 2016 at 12:44 AM, Sergey Korshunoff 
wrote:

> > That's a good bit of sleuthing. A couple of questions immediately come
> to mind:
> >Why does gcc and pcc take 4 as their alignment? Why do we take 32?
> I'm not a guru. But tcc behaviour cost me a day of the problem discovering
>

I hate it when I lose a full day to stuff like this.


> >Does this have any performance impact?
> I don't think so. This alignment is for unusual sections, not for
> .text .data and so.
>
> >Is there a reason you are implementing this with #ifdef?
> I don't know about gcc defaults on different ARCH
>
> > Might we use a preprocessor value (i.e. TCC_DEFAULT_ALIGNMENT) and
> #define that in architecture-specific header files instead?
> May be. But problem exposed only on i386.
>

Taking all three of these together, I wonder if there is a reason tcc
defaulted to 32 in the first place. That is, why not just switch to 4 for
all architectures? Perhaps you could do that, push a topic branch, and ask
folks to pull it and run their own tests on it. (It looks like you haven't
pushed any topic branches yet to http://repo.or.cz/tinycc.git/refs)

Something that might help the conversation along: Do you know where, in the
source code for gcc, the alignments are set? This might let us examine how
they handle it across architectures. It might even be possible to run "git
blame" on said lines in gcc's source, to see if we can learn anything from
the commit history.

In any event, it is odd to me that any software compiled entirely from
source should care about this sort of alignment. It should leave such
issues up to the compiler, as an implementation detail, shouldn't it?

PS: another problem: 0x1234-123 parsed by tcc as float number by
> default and there is no switch to dsiable this. And gcc-3.4.6 (4.1.2)
> understand the above as expression 0x1234 - 123 by default.
>

No no no! This is unrelated! Start a different thread, or the conversation
will get all confused!

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc as compiler for tccboot

[David Mertens]

Hello Sergey,

That's a good bit of sleuthing. A couple of questions immediately come to
mind:

   - Why does gcc and pcc take 4 as their alignment? Why do we take 32?
   - Does this have any performance impact?
   - Is there a reason you are implementing this with #ifdef? Might we use
   a preprocessor value (i.e. TCC_DEFAULT_ALIGNMENT) and #define that in
   architecture-specific header files instead?

Thanks!

David

On Wed, Apr 20, 2016 at 11:49 AM, Sergey Korshunoff 
wrote:

> > Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o
> with 0x04.
> > This helped.
>
> diff --git a/libtcc.c b/libtcc.c
> index 5aebd32..a8e109c 100644
> --- a/libtcc.c
> +++ b/libtcc.c
> @@ -514,7 +514,11 @@ ST_FUNC Section *new_section(TCCState *s1, const
> char *name, int sh_type, int sh
>  sec->sh_addralign = 1;
>  break;
>  default:
> +#ifdef TCC_TARGET_I386
> +sec->sh_addralign =  4; /* gcc/pcc default alignment for i386 */
> +#else
>  sec->sh_addralign = 32; /* default conservative alignment */
> +#endif
>  break;
>  }
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Development style

[David Mertens]

Hello Sergey,

This line of yours is symptomatic of a larger problem:

On Mon, Apr 18, 2016 at 11:56 PM, Sergey Korshunoff 
wrote:

> PS: all new optimizations will break the patch again and again. How
> long I must perform
> adoptation by myself?
>

You might pause and ask yourself why *I* have not kept my fork of tcc
up-to-date with [mob]. It's not like I want to rely on old, buggy code: I
would prefer to keep my code as an offshoot of the latest and greatest tcc.

My fork dates back to 2013. At that time, [mob] compiled on Mac, Linux, and
Windows, and "tcc -run" functioned on all three platforms. This
functionality is critical for my uses. In the summer of 2014 I decided to
update my fork by merging in the latest [mob], only to discover that tcc no
longer compiled on Mac! This was something I wanted to address, but I was
too busy at the time, so I reverted to my old fork. Since that time, I have
been too focused on developing C::Blocks to root through the myriad of
commits and figure out when the Mac build was fixed again, if ever.

And herein lies the problem: *when you commit code directly to [mob], you
run the risk of breaking tcc on platforms where you do not develop or test.*
This is why you should push your work to a personal mob branch. For more on
personal mob branches, see http://repo.or.cz/mob.html

After pushing to a personal mob branch, notify the mailing list. "Check out
my latest and greatest work on . I would really appreciate if folks
could test this on . If all goes well, I'd like
to merge this with [mob] in a week. Thanks!"

Then wait for a couple of days for folks to check things out. Expect that
if you get any responses, they will likely ask you to do some work. If you
really want to merge your code, put the time in and do that work. On the
other hand, if you don't get any responses, send a follow-up. Once there is
consensus on the mailing list that your code looks good---i.e. multiple
people have spoken well of your code---then and only then merge it into mob.

If everybody followed this approach to developing tcc, I would not have
nearly as much trouble updating my fork, because we would know which
commits work on which platforms.

David

-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Development style

[David Mertens]

All, please note step 5 in the committing instructions:

5. Push your changes to here:

*"git push ssh://m...@repo.or.cz/srv/git/tinycc.git
 mypatch:mob"*
That is, push your work to a *topic branch*, not the main branch. From
thence we can have a discussion. Any direct push to mob without discussion
is inappropriate.

David

On Sun, Apr 17, 2016 at 2:45 PM, Michael Matz  wrote:

> Hi,
>
> On Sun, 17 Apr 2016, Michael Matz wrote:
>
> Can try to extract this

>>> Sorry, reading a comment: no op now (a patch attached)
>>>
>>
>> This is just silly.  Put
>>  #define __builtin_expect(a,b) (a)
>> anywhere and you're done.  No need for support in the compiler.
>>
>
> Argh!  And now you put in this thing into [mob].  Are you even taking a
> step back and think about your patches before committing?
>
> Gosh, and you even put the exsymtab stuff into [mob] now.  Without
> discussion.  Of course!  What's the point of that?  Do you plan to use it
> for anything?
>
> I don't think [mob] is working for you.  Well, or not for me, but I have
> no problems with any other [mob] committer.  Your fast-paced
> attention-deficit way of pushing strange hacks into the branch just makes
> me want to bite my desk all the time.  I honestly don't know what to do:
> reverting all the crap again or just going away from here and not paying
> attention to tinycc anymore.  Sigh.  Will decide somewhen next week I guess.
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Development style

[David Mertens]

Hello Michael and Sergey,

I have nuked that commit. I'm sorry for altering the history of a public
git repository, but that commit was not appropriate, and it's better to fix
it quickly now than to live with the consequences or a rash commit.

exsymtab is a huge addition to tcc. It should not go in without a serious
discussion and code review. No such discussion or code review took place.
In fact, Sergey, you didn't even push your proposed work to a feature
branch as dictated in step number 5 of the instructions.

For time management reasons, my recreational programming goes through a
distinct email account, one that I hadn't checked since early January. It
might have looked as though I had abandoned my work on exsymtab. I have
not, I just put it on hiatus. Today happens to be the day I've checked
back, and wow, what a day.

I am not yet ready to discuss adding exsymtab to tcc; I likely won't have
time until this summer. If others want to take up that conversation, that's
great, and I'll try to follow the conversation moving forward.

Sorry for popping up out of nowhere and potentially causing damage. I
believe it's for the better.

David

On Mon, Apr 18, 2016 at 5:58 PM, Michael Matz  wrote:

> Hi,
>
> On Mon, 18 Apr 2016, Sergey Korshunoff wrote:
>
> Gosh, and you even put the exsymtab stuff into [mob] now.  Without
>>> discussion
>>>
>>
>> http://lists.nongnu.org/archive/html/tinycc-devel/2015-05/threads.html
>> (David Martens)
>>
>
> Yes, I know exsymtab, I was there when you both talked about it.  In
> particular I will remind you of Davids own stance towards the exsymtab
> patches:
>
> "I have more work to do on my exsymtab fork before I was going to bring it
> up for inclusion in tcc itself. (Indeed, I am not entirely sure that it is
> appropriate for inclusion in tcc.) Here are a couple of reasons we should
> wait for a little while longer: ".
>
> ...
>
> "let's wait a few more months until most of these issues have been ironed
> out and we all have had a chance to discuss the merits and drawbacks of
> extended symbol table support."
>
> So, you single-handedly decided to not have any discussion but instead
> dumped a large patchset into tcc that's inactive by default and where it's
> not even clear that it should be in tcc to start with.  IMNSHO it
> shouldn't.  Certainly not without re-discussing the reason for them, the
> implementation of them and the maintenance impact of them.
>
> don't think [mob] is working for you
>>> Sigh.  Will decide somewhen next week I guess.
>>>
>> Very interesting. Who are deciders?
>>
>
> Everyone who cares and commits.  Seemingly we aren't that many anymore.
>
> Your fast-paced attention-deficit way of pushing strange hacks into the
>>> branch
>>>
>> A patch was tested a whole year. since 2015.
>>
>
> Sure.  I have patches that implement a sudoku solver.  They are tested
> since 2011.  Should I put them into tcc?
>
> Do you see where I'm getting at?  tcc is not a kitchen sink of stuff that
> you happen to find on the net.
>
> So, please explain exactly what the purpose and merits of these patches
> are, and why it's so important for tcc to carry them that you overrode the
> authors own opinion about not having them in tcc.  This kind of #ifdef code
> is not only ugly but leads to bitrot down the line, so it needs to
> integrate with the rest of tcc by default (without slowing that one down);
> #ifdef should be used sparingly and certainly not everywhere where you need
> SYM_EXTENDED to be removed.  When somebody explains the purpose of those
> changes I'm fairly sure we can develop something that doesn't need to be
> tacked on the side of tcc like a wart and needs 3000 lines to implement.
> That is all work (in discussion and/or implementation) that you should have
> done _before_ committing something that controversial.
>
>
> Ciao,
> Michael.
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Removing the horrible CString hack

[David Mertens]

Hello Edmund, and everyone else following this,

Here are my thoughts, not as a gate-keeper, but rather in the spirit of
peer review.

In my own tcc hacking, I have looked closely at the cstring handling in
token streams and always found this sort of code troubling:

  nb_words = (sizeof(CString) + cv->cstr->size + 3) >> 2;

Doesn't this assume that ints are 4 bytes? Of course, if ints are actually
8 bytes, then the ensuing malloc simply allocates more room than we need,
so it's not been a problem, but it nonetheless seemed a bit to loose for my
taste. Your patch touches the offending lines, and it looks like it handles
them correctly.

What I'm not sure about, and would appreciate if somebody could check, is
whether changing the contents of the union might lead to substantial
increases in memory consumption. How many CValue-s are typically allocated
and used during a regular compilation? The proposed change will alter a
union the largest member of which used to be a pointer or 64-bit integer,
and replaced it with a struct that contains an int and two pointers. On the
other hand, allocating no more room than necessary for cstrings should
reduce the consumed memory on 64-bit architectures. I believe Edmund that
this fixes alignment issues, and this may also lead to better memory
consumption, at least on 64-bit.

Edmund, can you comment on any measurements of memory consumption during
compilation due to this change? Any information on both 32- and 64-bit
architectures would be great!

David

On Sat, Nov 21, 2015 at 7:06 AM, Edmund Grimley Evans <
edmund.grimley.ev...@gmail.com> wrote:

> I have removed from TCC all the cases of illegal/undefined C that I
> know about, apart from one, which is particularly horrible: the way a
> CString is copied into a token string, which is an int array: see
> tok_str_add2. On a 64-bit architecture the pointers end up misaligned,
> so ASan gives lots of warnings. On a 64-bit architecture that required
> memory accesses to be correctly aligned it would not work at all.
>
> Here is a patch to cure the problem by putting the struct CString into
> struct CValue instead. According to Valgrind, TCC does not leak memory
> with this patch, though that's almost a miracle because it's very
> unclear who is responsible for freeing the "data" in a string. Still,
> unless someone has a better idea of how to do this, and is willing to
> implement that better idea, I think this patch should go in. Opinions?
>
> Edmund
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] read32le/write32le

[David Mertens]

As I understand it, this patch changes certain bit copying lines. Those
which cast their data as integer arrays are now cast as character arrays,
and what used to be a single copy operation is now four copy operations.
Presumably this would lead to behavior that is more robust and less likely
to fail. Can you explain under which circumstances the integer copy would
fail where the character copy would succeed? Also, can we expect smart
compilers to notice that we're copying four consecutive bytes, and use a 32
bit read/write instead of four 8 bit read/writes?

In short: it seems unlikely to me that we'd get wrong behavior on any
platform used by TCC using the current code. Thus a good explanation, and
benchmarks showing minimal (or zero) impact on execution are important for
this patch.

Thanks!
David

On Tue, Nov 17, 2015 at 6:17 PM, Edmund Grimley Evans <
edmund.grimley.ev...@gmail.com> wrote:

> Here's a patch that makes TCC pass its tests on i386 under ASan and
> UBSan without any errors or warnings. Does this seem reasonable?
> Anyone object to this approach being extended to all architectures?
>
> Edmund
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Compile .c file to .pyd

[David Mertens]

This is hard for me to test, as I work primarily on Linux, and I don't have
Python on my Windows machine. Could you try to produce a smaller failing
example?

David

On Tue, Nov 17, 2015 at 8:59 AM, Ahd Abd-Elrazek  wrote:

> Hi All,
>
>
> I have python 3.4 and i want to compile .c file to .pyd file
>
> I followed the command in this post
> http://stackoverflow.com/questions/17255828/compile-c-files-to-pyd
>
> when i write this:
>
> "tcc.exe" sptk.c -o sptk.pyd -shared -I C:\Python34\include
> -L C:\Python34\libs -lpython34
>
>
> i get:
>
> tcc: cannot find -lpython3.4
>
>
> Am i missing something or what is the correct way?
>
>
>
> Best Regards,
> T.A. Ahd Abd El-Razek Mostafa
> Computer Science Department
> Faculty of Computer and Information Sciences
> Ain Shams University
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>


-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] read32le/write32le

[David Mertens]

Cool. I'm more of a tcc user than a compiler hacker, so your answers have
made me happy. Looking over the patch, I would say that it *looks* fine, so
if we get better behavior with no noticeable slowdowns, it's a good patch.

I am far from an authority, though. Anybody else care to comment?

David

On Wed, Nov 18, 2015 at 3:28 PM, Edmund Grimley Evans <
edmund.grimley.ev...@gmail.com> wrote:

> > As I understand it, this patch changes certain bit copying lines. Those
> which
> > cast their data as integer arrays are now cast as character arrays, and
> what
> > used to be a single copy operation is now four copy operations.
> Presumably this
> > would lead to behavior that is more robust and less likely to fail. Can
> you
> > explain under which circumstances the integer copy would fail where the
> > character copy would succeed?
>
> The "*(int *)ptr += ..." stuff could fail in several circumstances:
>
> - host is not little-endian
> - host does not allow unaligned memory access
> - compiler does some bizarre optimisation because of the implication
>   that ptr must, somehow, be a valid pointer to int
>
> > Also, can we expect smart compilers to notice
> > that we're copying four consecutive bytes, and use a 32 bit read/write
> instead
> > of four 8 bit read/writes?
>
> Yes.
>
> > In short: it seems unlikely to me that we'd get wrong behavior on any
> platform
> > used by TCC using the current code. Thus a good explanation, and
> benchmarks
> > showing minimal (or zero) impact on execution are important for this
> patch.
>
> I found no measurable slow-down of tcc built by tcc building tcc.
>
> Edmund
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>



-- 
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] RE :Re: RE : [RFC] Moving source code to src

[David Mertens]

FYI, a good rule of thumb I've seen with other open source projects is that
discussion threads should have at least 24 hours of open discussion before
any major changes are made. I don't know if tcc has any agreed-upon policy
along these lines, but it's not a bad approach.

As for my take on the matter, I really don't care one way or the other. I
don't feel any strong compulsion for a change, but I won't complain, either.

David

On Tue, Jul 28, 2015 at 12:58 AM, Christian JULLIEN eli...@orange.fr
wrote:

 Ouch!
 You're fast, maybe too fast.
 I've no responsibility on tcc project. If I think moving code to src is a
 good idea, it is my personal opinion. Official maintainers may have a
 different opinion or want to choose different code organization.

 Anyway, here is what I can already say (from my RPi)
 - it compiles well if you run make from src directory. I prefer a toplevel
 Makefile having different tagets calling make on different subdirectories.
 - related to previous point, you can't run 'make test' which fails
 - have you modified build-tcc.bat for Windows ?

 C.

 - message d'origine -
 *De :* gus knight waddlespl...@gmail.com
 *date *lun. 27/07/2015 22:11 (GMT +02:00)
 *À : *tinycc-devel@nongnu.org tinycc-devel@nongnu.org
 *Objet :* Re: [Tinycc-devel] RE : [RFC] Moving source code to src

 On Mon, Jul 27, 2015 at 12:48 PM, Christian JULLIEN eli...@orange.fr
 wrote:
  Hi Gus,
 
  This is a good idea. If you do so, I also suggest an arch directory that
  contains subdirectories for all supported archives

 I wound up going with one dir per arch rather than an arch
 directory. Let me know if there are any regressions.

 -gus

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel


 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Types, and references to other types

[David Mertens]

Hello everyone,

I have been playing with symbol table copying and ran into some trouble
with uninitialized pointers. I figured my troubles arose because I didn't
fully understand the uses of Sym objects, so I thought I'd read through
tcc-doc. While reading I came across references to the .t field of Syms, in
particular:

When a reference to another type is needed (for pointers, functions and
structures), the 32 - VT_STRUCT_SHIFT high order bits are used to store an
identifier reference.

This seems out of date. The current Sym struct does not have a .t field. It
has a .type field, which is a CType, which itself has a .t field, but also
a .ref field. The .ref is a pointer to the referenced type's Sym. I then
grepped through the source. The only code that seems to think that the a
type's higher-order bits have a type reference is il-gen.c. Any other
shifting of the type.t field assumes that the high bits contain bit field
offsets.

Is the tcc-doc.texi out of date?

David

-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] When does a CType's ref contain a valid pointer?

[David Mertens]

Hey Michael,

You are right about my type, I meant to say int btype = type_to_check.t 
VT_BTYPE;

Thanks for the confirmation, I'll start digging around elsewhere in my code.

David

On Mon, Jul 27, 2015 at 11:52 AM, Michael Matz matz@frakked.de wrote:

 Hi,

 On Mon, 27 Jul 2015, David Mertens wrote:

  Hello everyone,
 
  While working on symbol table copying, I have run into trouble copying
  type.ref pointers that point to garbage. Suppose we have a type struct
  called type_to_check. Then I thought the following check would ensure
  that the .ref field was valid:
 
  int btype = type_to_check-type.t  VT_BTYPE;
  if (btype == VT_PTR || btype == VT_STRUCT || btype == VT_FUNC) {
/* type_to_check.ref is a valid pointer */

 No, type_to_check-type.ref should be a valid pointer.  Or your btype
 computation was wrong and you meant type_to_check-t  VT_BTYPE.  Note
 that also VT_ARRAY use the -ref field.


 Ciao,
 Michael.

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] When does a CType's ref contain a valid pointer?

[David Mertens]

Hello everyone,

While working on symbol table copying, I have run into trouble copying
type.ref pointers that point to garbage. Suppose we have a type struct
called type_to_check. Then I thought the following check would ensure
that the .ref field was valid:

int btype = type_to_check-type.t  VT_BTYPE;
if (btype == VT_PTR || btype == VT_STRUCT || btype == VT_FUNC) {
  /* type_to_check.ref is a valid pointer */
}

Yet I seem to run into trouble. Does this look correct?

David

-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] build perl5 with tcc?

[David Mertens]

Hey Chris! Nice to see you in the TCC mailing lists as well. :-)

Here are a couple of thoughts on your ideas.

First, compiling perl5 with tcc will not really give you any of the
features of tcc. If it compiles (and it has a decent chance of doing that)
It'll just produce a perl binary that runs slower.

I suspect that you probably want to jit-compile code using tcc. For the
roots of that, see the test for libtcc:
http://repo.or.cz/w/tinycc.git/blob/HEAD:/tests/libtcc_test.c. That said,
if you're working in Perl, you probably should look into a couple of
packages that have already wrapped tcc up as a jit compiler, including (my)
C::TinyCompiler (https://metacpan.org/pod/C::TinyCompiler) and Steffen
Mueller's XS::TCC (https://metacpan.org/pod/XS::TCC).

Finally, you're probably interested in getting things working on Windows. I
bet that Cygwin works just fine even with the current branch, but MinGW
might give trouble. I spent some time making sure that Alien::TinyCC
installs the necessary header files for MinGW, so if you install that (or
C::TinyCompiler) then it should work correctly on both Cygwin and MinGW.
I've not tried building with visual studio, but I don't think you use that
on your end.

Let me know if you have more questions about Perl/tcc. This is a subject
near and dear to my heart. :-)

David

On Thu, Jul 16, 2015 at 6:08 PM, Chris Marshall devel.chm...@gmail.com
wrote:

 I would like to integrate tcc with some perl5 programs to the best extent
 possible.
 Has anyone tried and/or reported being able to build perl5 with tcc?

 Thanks,
 Chris

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] OT? old discussion, support for OOP in C

[David Mertens]

I've read parts of this book and love it. He describes how to write
object-orient C. As far as I would expect, you could read the book and use
it as inspiration to write an independent implementation of his ideas
without infringing upon his copyright.

David

On Sat, Jun 27, 2015 at 2:28 PM, Pierpaolo Bernardi olopie...@gmail.com
wrote:

 On Sat, Jun 27, 2015 at 10:05 AM, u-tcc-u...@aetey.se wrote:


 Any insights?


 Ask the author a clarification about what they mean?  AFAIU they are a
 single person, not a company or an institution. It shouldn't be so hard to
 get it.


 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

Hey Sergey,

Good point. I use the expressesion v  SYM_EXTENDED and (v 
~SYM_EXTENDED) == v interchangeably, as they *mean* the exact same thing
for an unsigned integer. I got the idea because inequalities are used with
SYM_FIRST_ANOM, so I assumed that inequalities would be safe. I'll fix mine
to bit checks.

@Everybody, Might there be a subtle bug in tcc's anonymous symbol checking,
since it uses inequalities rather than querying bits directly?

David

On Mon, May 18, 2015 at 6:52 AM, Sergey Korshunoff sey...@gmail.com wrote:

 0x8000 is a sign bit. If v == 0x8000 then v  0x4000

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

Sergey,

That's a good question. To add the SYM_EXTENDED flag, I took SYM_STRUCT,
SYM_FIELD, and SYM_FIRST_ANOM and shifted them down by 1. So, SYM_STRUCT
used to be 0x4000. As to whether or not a 32-bit integer can hold it,
isn't that constant equivalent to 2^31? Unless I've miscalculated or lost
my mind, I'm pretty sure that fits. It certainly achieves the desired end
in code that I've run on my machine, which uses 4 bytes for its integers.

David

On Mon, May 18, 2015 at 6:21 AM, Sergey Korshunoff sey...@gmail.com wrote:

 Hello all
 A some question:
 
 * push a given symbol on the symbol stack */
 ST_FUNC Sym *sym_push(int v, CType *type, int r, int c)
 {
 Sym *s, **ps;
 TokenSym *ts;

 #ifdef CONFIG_TCC_EXSYMTAB
 v = ~SYM_EXTENDED;
 #endif
 if (local_stack)
 ps = local_stack;
 else {
 #ifdef CONFIG_TCC_EXSYMTAB
 /* Global symbol stack. This is OK for the local symbol stack,
 but don't allow
  * this for symbols that are in the extended symbol stack. */
 if (v = SYM_EXTENDED) {
 tcc_error(Cannot use name '%s' as a global variable, it
 is already in the 
extended symbol table., get_tok_str(v, 0));
 }
 #endif
 ps = global_stack;
 }
 
 v is integer and SYM_EXTENDED=0x4000
 When  (v = SYM_EXTENDED) can be true ?

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

On Thu, May 14, 2015 at 10:39 PM, Jared Maddox absinthdr...@gmail.com
wrote:

  Date: Thu, 14 May 2015 09:35:12 -0400
  From: David Mertens dcmertens.p...@gmail.com
  To: tinycc-devel@nongnu.org
  Subject: Re: [Tinycc-devel] TinyCC REPL
  Message-ID:
  
 ca+4ieyuvehefrcjyhmnaeq2n6lbbvpexlafpzryawu7581k...@mail.gmail.com
  Content-Type: text/plain; charset=utf-8
 

 Out of curiosity, have you added an assert() to confirm that the
 character set is ASCII instead of something else? I think ASCII is the
 norm, but main-frames aren't the only place I've heard of non-ASCII
 encodings (not saying you should handle it, just test it; handling can
 be implemented by someone with a weird machine - I think it was
 embedded).


Not a bad idea, thanks. I've added an issue to my repo on github so I don't
forget this.


  You refer to what I understand to be the symbgol table as an Array
 Mapped Trie. I'm not familiar with the structure, but it looks like an
 array that someone shoved a bunch of trie data structures into. How
 exactly does ::filled_bits work? Is it a bit field indicating which
 children (I assume placed in relation to their parent) have data, and
 which don't?


I think your understanding is essentially correct. I'm not really sure why
Phil Bagwell used the term Array Mapped Trie, but I'm just following his
choice. His data structures are discussed in the paper at
http://lampwww.epfl.ch/papers/triesearches.pdf.gz. In my implementation,
the compressed trie is declared as

struct compressed_trie {
unsigned long long filled_bits;
struct compressed_trie children[1];
}

(Notice that I always have at least one child.) As I came from C++, this
sort of construction was new to me, but I like it. For example, a node with
three children would essentially have the layout

struct compressed_trie {
unsigned long long filled_bits;
struct compressed_trie * first;
struct compressed_trie * second;
struct compressed_trie * third;
};

The letter for the trie that corresponds to the first, second, and third
child depends on which bits are occupied in filled_bits. The point is that
any node only allocates exactly the number of pointers for child nodes that
it needs, rather than having room for 63 child nodes, most of which go
unused.

4. As implemented, this cuts the maximum number of token symbols in
 half. (I needed to use one of the bits to indicate extended symbol.)
 5. The current token lookup is based on a compressed trie that
 explicitly only supports A-Z, a-z, 0-9, and _. It does not support $
 in
 identifiers and would need to be revised in order to do so. I chose to
 implement Phil Bagwell's Array Mapped Trie
 http://lampwww.epfl.ch/papers/triesearches.pdf.gz in the belief
 that
 it would perform better than a hash for lookup. Once I add symbol
 table
 caching, I hope to add (or switch to) Array Compressed Tries for even
 better cache utilization. But currently, I rely on have 63 allowed
 characters in identifiers.

 Assuming that my understanding above is right (or at least the
 bitfield part is), how about reducing the allowed number of children
 for a single trie node, and use a custom encoding to indicate that
 some particular trie child node (let's say the first) is a
 continuation node, containing the OTHER half (or third, or whatever)
 of the children? The source already mentions the assumption that the
 upper-case letters are used more rarely. Depending on choosen method
 (something derived from UTF-8, perhaps? Nice and simple, after all,
 implementable purely via comparisons: instead of indicating extension
 bytes, the highest set bits would indicate subsidiary nodes),
 extension to full Unicode might be possible (if improbable, and
 ill-advised).

 As an example, assuming that only one continuation node was allowed
 per parent, the parent would have 62 - 2 bits, for 60 symbols if the
 highest bit was set, and 61 otherwise. Meanwhile, the continuation
 node would always have 62. The result is up to 122 - extended symbol
 == 121 available symbols: even if you add $, an ASCII C++ operator
 declaration doesn't allow even as many as 100 characters, much less C,
 so for relatively little cost (if the assumptions about character
 occurance ratios are close enough) you can easily cover more than is
 needed, thereby providing space for e.g. other languages at a later
 point in time.


Excellent idea! Using this idea, I could even map all 256 possibilities
through the trie and substantially simplify _c_trie_bit_offset_for_char. In
fact, this could lead to transparent support for unicode.


David

-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

Hey Sergey,

Thanks for this! I am impressed at your efforts! Unfortunately, I think
this is a bit premature. I have more work to do on my exsymtab fork before
I was going to bring it up for inclusion in tcc itself. (Indeed, I am not
entirely sure that it is appropriate for inclusion in tcc.) Here are a
couple of reasons we should wait for a little while longer:

   1. The extended symbol table API is not documented at all.
   2. The symbol table copy takes O(N_sym^2) to run. It might be possible
   to speed this up, but for the moment I plan to work around it by
   implementing symbol table caching. I have not yet completed that work, so I
   consider the exsymtab project to be incomplete at the moment.
   3. This work is most of interest for folks using tcc as an in-memory C
   JIT compiler. In its current form it is nearly useless to those who want a
   fast compiler that produces binaries. After I implement symbol table
   caching, it may prove a bit more useful to the fast-compiler crowd, but
   it's not ready yet. We need to have a wider discussion about the merits of
   the extension before we include it in mob.
   4. As implemented, this cuts the maximum number of token symbols in
   half. (I needed to use one of the bits to indicate extended symbol.)
   5. The current token lookup is based on a compressed trie that
   explicitly only supports A-Z, a-z, 0-9, and _. It does not support $ in
   identifiers and would need to be revised in order to do so. I chose to
   implement Phil Bagwell's Array Mapped Trie
   http://lampwww.epfl.ch/papers/triesearches.pdf.gz in the belief that
   it would perform better than a hash for lookup. Once I add symbol table
   caching, I hope to add (or switch to) Array Compressed Tries for even
   better cache utilization. But currently, I rely on have 63 allowed
   characters in identifiers.
   6. I know absolutely nothing about how the compilation and relocation
   stages modify the members of the symbol tables. It is a black box to me. As
   such, the copy procedure is a pile of ad-hoc data structure tests that is,
   in all likelihood, subtly broken and quite brittle. Adding this in its
   current state to tcc's codebase, especially without sufficient tests, could
   dampen efforts to change the symbol table handling or code generation.
   7. A separate idea that I plan to pursue on my fork is to extend how tcc
   pulls data in from file handles. I would like to make it hookable so that I
   could write hooks in my Perl module and have it interact directly with
   Perl's parser, rather than pulling all of the C code into a temporary
   buffer. This may go beyond the wishes of the community and merits further
   discussion.

For these reasons, I do not believe that the exsymtab fork, in its current
state, should be brought into the mob branch. I am more than happy to have
help, but let's wait a few more months until most of these issues have been
ironed out and we all have had a chance to discuss the merits and drawbacks
of extended symbol table support.


David
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

Hello Sergey,

On Wed, May 13, 2015 at 6:39 PM, Sergey Korshunoff sey...@gmail.com wrote:

 May be a fork of the current tcc with your patches is needed on the
 repo.or.cz?
 Just for a more public testing?


This fork will eventually see lots of testing via the CPAN Testers when I
include it in a Perl module. That's planned to happen this summer.


 I pushed to the mob your changes to the win32/inlcude/winapi


Those changes were the minimum necessary so that tcc could compile perl.h
on Windows. Is that a sensible criterion for including them in tcc's source
code?

David

-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

For what it's worth, I'm working on a fork of TCC that knows how to work
with multiple symbol tables https://github.com/run4flat/tinycc. Each line
of the REPL would be an independent compilation unit. You would have to
hack a little bit, but you could then copy the contents of each single-line
symbol table into a master symbol table. This way you would only have to
actually compile a single line at a time.

But it'll take a bit of work, I suspect. How much hacking do you want to do
to get this to work? :-)

David

On Tue, May 12, 2015 at 10:48 PM, Sergey Korshunoff sey...@gmail.com
wrote:

  Can you add clarification to why you added #include tcclib.h to the
 start of the compiled  string? Is this necessary?

 printf() and so declarations :-)

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

On Wed, May 13, 2015 at 8:50 AM, Joey Payne jyapa...@gmail.com wrote:

 Hi David,

 I may be misunderstanding, but doesn't the current implementation already
 have a master symbol table? I was just trying to hack that into giving me
 what I want. Do you think it would be easier with your fork?

It does, but I thought that all of the preprocessor macros and other
symbols get reset either after compilation or after relocation. The only
things that remain are global variables and functions, I think.

David
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

On Wed, May 13, 2015 at 10:20 AM, Sergey Korshunoff sey...@gmail.com
wrote:

 Hi David!

 2015-05-13 14:38 GMT+03:00, David Mertens dcmertens.p...@gmail.com:
  For what it's worth, I'm working on a fork of TCC that knows how to work
  with multiple symbol tables https://github.com/run4flat/tinycc

 Currently I know what the difference of this fork from the mob branch.
 Thanks for your message. And there is no way to understand this by reading
 info from github :-(


The difference is not at all obvious from a casual inspection. I simply
mention it in case others are curious, at which point we could begin a
conversation. :-)

The big difference is the presence of tccexsymtab.[ch], as well as the test
suite contained in tests/exsymtab. There are also a couple of entry points
scattered throughout the source. The fork is based on tcc from about 24
months ago, mostly due to laziness on my part.

David

-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TinyCC REPL

[David Mertens]

Hey Sergey,

I pushed a small fix that includes the ULL suffix for all of those
constants. Thanks for pointing that out. I'm so accustomed to working on a
32 bit machine that I hadn't realized I was on 64 bit these days.

David

On Wed, May 13, 2015 at 12:04 PM, Sergey Korshunoff sey...@gmail.com
wrote:

 Hi David!
 On Linux32 there are warnings:

 tccexsymtab.c: In function `_c_trie_popcount':
 tccexsymtab.c:55: warning: integer constant is too large for long type
 tccexsymtab.c:57: warning: integer constant is too large for long type
 tccexsymtab.c:57: warning: integer constant is too large for long type
 tccexsymtab.c:59: warning: integer constant is too large for long type
 tccexsymtab.c:59: warning: integer constant is too large for long type
 tccexsymtab.c:61: warning: integer constant is too large for long type
 tccexsymtab.c:61: warning: integer constant is too large for long type
 tccexsymtab.c: In function `_c_trie_find_child':
 tccexsymtab.c:111: warning: integer constant is too large for long type
 tccexsymtab.c: In function `_c_trie_add_one_more_slot':
 tccexsymtab.c:158: warning: integer constant is too large for long type

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Are there any OS X users?

[David Mertens]

Hey John,

Until about October my primary laptop was a Mac. I had been working with an
old checkout of tcc. Back in June I made a commit that reverted a large
collection of commits that most of the community deemed inappropriate, and
at that time I believe that tcc didn't compile on Mac. I suggest checking
out one of the commits from late 2013: I seem to recall that things were
working fine then.

One of the tcc community (Miki?) works pretty hard on keeping tcc working
on Mac, but he seems to be busy as of late. Also bear in mind that tcc
cannot produce Mach-O executables, which is what Macs expect. This means
that while tcc works as a JIT compiler on Mac, it does not build
stand-alone executables.

I hope that helps!
David

On Fri, Jan 9, 2015 at 6:05 AM, John Smith xp0...@gmail.com wrote:

 Hi people...

 I can't compile tinyCC on OS X.

 Are there any OS X users here? If so... could you let me know (you can
 private email if you prefer, I don't mind either) so I can ask you some
 questions about how well tinycc works...

 I'm getting compile errors but I can't find any solutions.

 I don't even know if tinycc is supported for OS X anymore.

 Please help.
 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] TCC's preprocessor for other use?

[David Mertens]

The Perl module Convert::Binary::C (
https://metacpan.org/pod/Convert::Binary::C) uses ucpp:
https://code.google.com/p/ucpp/

On Wed, Jan 7, 2015 at 12:42 PM, KHMan keinh...@gmail.com wrote:

 On 1/8/2015 1:05 AM, Kevin Ingwersen (Ingwie Phoenix) wrote:

 I am working on a project that involves AngelScript, which is a C++ like
 scripting language. But I wanted to add a preprocessor to it. Is it
 possible to embed TCC’s preprocessor into another app? I have never seen
 TCC running an external process for preprocessing files, which is why I
 believe that it must be inside it entirely.


 This may be a better option:
 http://mcpp.sourceforge.net/

 --
 Cheers,
 Kein-Hong Man (esq.)
 Kuala Lumpur, Malaysia



 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel




-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] .gitignore: Ignore Emacs temporary files

[David Mertens]

Add it.

On Mon, Dec 15, 2014 at 3:40 AM, Lee Duhem lee.du...@gmail.com wrote:

 Hi,

 This patch adds patterns to .gitignore to ignore Emacs temporary files.

 Sincerely,
 lee

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel



-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] libtcc.c (put_extern_sym2): Extend the scope of buf to match its use

[David Mertens]

Good catch. I'm not closely acquainted with this particular section of
code, but your observation looks correct to me, and the fix looks right.

On Mon, Dec 15, 2014 at 3:42 AM, Lee Duhem lee.du...@gmail.com wrote:

 Hi,

 In `put_extern_sym2', after leaving the code block that `buf' is
 defined, `buf' will not
 exist, so `name' will point to a variable that does not exist. This
 patch fixes that.

 Any comment?

 Sincerely,
 lee

 ___
 Tinycc-devel mailing list
 Tinycc-devel@nongnu.org
 https://lists.nongnu.org/mailman/listinfo/tinycc-devel



-- 
 Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it. -- Brian Kernighan
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel