Re: [Tinycc-devel] __VA_OPT__

[Detlef Riekenberg via Tinycc-devel]

> How do we feel about the lack of __VA_OPT__?I would delay that after the release.@grischka, your ping for a release.-- Regards ... Detlef

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

Re: [Tinycc-devel] RFC: Colored warnings/errors ?

[Detlef Riekenberg via Tinycc-devel]

tcc should be as small an simple as possible,so i vote against any colored output.For colored output, i pipe the output through a script.I use "colormake.pl" here and to reduce typing, i use a link with the shorter name "cmpl".Oh, i changed my "colormake.pl" to recognice tcc / *tcc.-- Regards ... Detlef

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

Re: [Tinycc-devel] new backend

[Detlef Riekenberg via Tinycc-devel]

Hi PaulCan you please tell me more about the new backend,which you are working on?Either here or  with  private mail.Thanks.> Well somewhere along the way I fixed it > when I started making gjmp and gjmp_append return sane values. Great > Are there any docs out there that describe how to write a backend.I'm not aware of any additional doc.You can also look at the commit history of recent added backends.> The doc here Tiny C Compiler Reference Documentation (bellard.org) > seems way way out of dateIt's build from the source tree: tcc-doc.texiCan you please add Everything, what you learned during yourbackend development,?(I suggest to upstream it after the 0.9.28 release from @grischka)> Any guidance, gotchas, tips are welcome I'm also interested in everything related to this topic.-- Regards ... Detlef

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

Re: [Tinycc-devel] Re: Waiting for a release / Please delay any commits

[Detlef Riekenberg via Tinycc-devel]

>> We have the tinycc 0.9.28 release canditate for a long time,>> but still no release@grischka, we need you>> Savannah has a buglist for tinycc:>> https://savannah.nongnu.org/bugs/?group=tinycc>> It works for collecting issue,>> but unfortunately no one works on this issue list> I did not even know that there is a bug tracker!Yes, the bug tracker is a builtin feature of the software,which is running to serve gnu.org and nongnu.org> Note that> https://bellard.org/tcc/> says very clearly> You want to help ?> Here are some suggestions:> Report bugs to the mailing list (and eventually fix them).> which seems to foster mailing-list communication, > and that is what was my impression for the many years i am on this list.Yes, I know this text..And with so few developer working on improving tinycc,the mailing list is the main location, where bug reports where recognizedand sometimes get fixed.But as soon, as a Mail is out of the short term history, it is also ignored.As an example, i wrote about fixing tinycc to support`nolibc.h`, but my assembly skills and my understanding,how tccasm.c and the arch dependant assember parts workwhere not good enough, so i  was not able to fix it myself.My mail is now 23 month old.Out of sight,out of mind.>> @grischka, what additional things can we do, to help you to make a release?>> Last time it just suddenly happened.I hope for a release every day.> I mean, v0.9.28 is just another number, right?NOSome people just get the outdated tcc 0.9.27 from the tcc homepage,and many linux distributions also have outdated tinycc packages.As an example, my distribution package is from 14.Aug.2020.That's better that the plain tcc-0.9.27 but still more than 3.5 years old.> Currently it is> version=20240309> gitver=9d2068c6309dc50dfdbbc30a5d6757683d3f884cSelf compiling from the mob branch is not the issue.The Download link on the TinyCC homepage links tohttps://download.savannah.gnu.org/releases/tinycc/and the newest tinycc is from 17.Dec.2017> You do this prodding all the time, A release is important.See above.> This is stunning since i learned that you contributed> to this software over fourteen (14!) years ago already, Upps, so long ago.I'm getting older> half a decade or so before i subscribed.You're welcome. Everybody can help.> Why don't you treat this is a "permanent rolling release" > instead for as long as there is no .28, A rolling release does not help, see above.> or (heaven!) 1.0After the tcc-0.9.28 release, i wish tcc to get * more attention* a bunch of updates and fixes* hopefully c99 conformance* probably a better c11/c17 conformance* probably more c23 features** a lot more testing* a tcc-0.9.29 release** even more attention* even more updates and fixes* even more testing* a tcc-1.0 releaseThe times between releases must be much shorter.As an example, wine has a bi-weekly snapshot release,which gets a new revision number and there is a yearlystabilization/bugfix only phase, which ends in a new major release.> I am happy to have tcc and that there are some major contributors> that bring this project that i use almost every day forward.You're welcome.

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

Re: [Tinycc-devel] Waiting for a release / Please delay any commits

[Detlef Riekenberg via Tinycc-devel]

Hi Ekaitz>> My suggestions:>> * Please hold back any commit before the release.>> * If you think, you have an urgent change to fix an urgent bug,>> discuss it on the mailing list first.>> * Together, we decide, if we postpone the change after the release is out,>> or commit the fix before the release.>> (Unfortunately, a commit will likely delay the release even longer)> I agree with the goal, Thanks>but not with the method.I do not know any better method, which has the possibility to work.> Are we seriously asking anyone to hold their commits?YES> And if they are not part of the ML and just fixed a bug?Then we have to wait longer for a release.> Isn't it more reasonable to make a release-candidate branch> from the current HEAD, for example, > and review that thoroughly > and let people continue sending patches to mob as always?Nope. Who is going the review the release candidate branchand test the tinycc from the release candidate branch?Are you willing to do reviews and test the release candidate branch,or would you ignore the release candidate branch (like everyone else)and continue to commit changes to the mob branch?I tested tcc with several C projects and filed some bug reports,but i didn't recognized anyone else doing testsand reporting back the test results on tbe mailing list.A seperate branch is possible and even mentioned ("personal mob branch")on the repository page:  https://repo.or.cz/tinycc.gitNobody uses it.Since yearsWe do not have hundreds of active developer working to improve tinycc.For the last 6 month, i probably saw a dozen or less peoplepushing changes to `mob`.> I say this for several reasons, > one being the fact that it's probably simpler for contributorsThe `mob` branch is the simplest way to contribute code to tinycc,but the stability of the `mob` branchdepends on every developer pushing to `mob`.> and the second being that we have no mechanism> to make people stop commiting to mob.Only the project admin (grischka)can change the text on the repository pageor probably block pushes to the mob branch.That's why i always ask @grischka to make a release.-- Regards ... Detlef

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

[Tinycc-devel] Waiting for a release / Please delay any commits

[Detlef Riekenberg via Tinycc-devel]

We have the tinycc 0.9.28 release canditate for a long time,but still no release.All people here can help grischka to be more confident to make a release.My suggestions:* Please hold back any commit before the release.* If you think, you have an urgent change to fix an urgent bug,  discuss it on the mailing list first.* Together, we decide, if we postpone the change after the release is out,   or commit the fix before the release.   (Unfortunately, a commit will likely delay the release even longer)Savannah has a buglist for tinycc:https://savannah.nongnu.org/bugs/?group=tinycc(It works for collecting issue,but unfortunately no one works on this issue list)I already created some entries for issues, which i like to get fixedand for features, which i like to get added.Please do the same.@grischka, what additional things can we do, to help you to make a release?-- Regards ... Detlef

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

Re: [Tinycc-devel] Questions about the future of TinyCC

[Detlef Riekenberg via Tinycc-devel]

Hi César Welcome to TinyCC> Basically, what I need is just a C compiler.> Written in C. A good C compiler. It depends, what you define as a 'good' compiler.TinyCC is a single pass compiler and very good at compilation speed.The code created by TinyCC is often remarkable slower,compared to code created by gcc/clang.> With a not too complex code tree and > reasonably easy to port to new targets in the future. That's it. Yes, the simple codebase is one of the goals of tcc.> It seems the old "portable C compiler" is either gone or abandoned> (the website is down). pcc is still under development, but the pcc webpages are often down.https://pcc.ludd.ltu.sepcc has more / different targets and even basic frontends for Fortran77 and c++,but development is very slow, done by one person.> TinyCC looks very appealing to me, but, before I embark on it,> are there any important warnings I should be aware of? * TinyCC has only very few optimizations   (only constant folding and in some situations code supression)* TinyCC compiles expressions self contained.   That's simple and fast to compile,   but a lot of code for loading of args & saving of results is created.   Many other compiler produce far better code for such situations.   > Does anybody use it on MacOS on a daily basis? With Apple Silicon? Sorry, i have no idea.> Does hardware floating point work fine in float and double precision> on Intel x86, x86_64, and on Apple Silicon?Should work and should produce correct results(i made my tests on linux  x86_64 / x86)but see above (self contained expressions: very likely slower code)> Also: are there plans to support OpenMP,No.  The TinyCC codebase should stay as simple as possible.Creating a parallel version of a loop requires a deep analyse of the code,which is too complex for TinyCC.> The thing is that all recent CPUs are multicore,> and you are sort of wasting them if you don't parallelize costly loops...TinyCC does not fully support all C11 features yet.I use the "C11threads" package in some of my code (on top of pthread)(other packages with similar code is available online),but when using threads,you have to think about parallel execution in all of your code.TinyCC is so much faster than other compiler, that TinyCC is usedas a backend for a different language (vlang),when the v code is trans-compiled to C.(tcc is used, when vlang compiles in DEBUG mode,and clang is used otherwise).(from the vlang repository: tcc: 500k loc/s, clang: 100k/s)my test on my machine for v.c (6418031 byte)tcc: 0.233s  (680k lin/s)gcc -O0: 7.999sclang -O0:  3.779s-- Regards ... Detlef

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

[Tinycc-devel] NotABug (Report a Bug about Parsing #ifdef, #ifndef and #else Line)

[Detlef Riekenberg via Tinycc-devel]

Am 31.03.24, 17:45 schrieb 837806295 via Tinycc-devel :Hi 837806295.Using a name for communication is better...> Hello!> Report a Bug about Parsing #ifdef, #ifndef and #else Line.Your intention to write a bug rebort is good,but your example is not vaild C code.From your example:> { > #ifndef Test   #else >  printf("Hello, Test\n"); > > #endif* A preproceccing directive starts with a hashtag and ends with a newline.Correct in your example* The #ifdef preprocessor directive starts an ` if-section`   and is followed by an identifier and a newlineSince  an `identifier` is not allowed to contain any whitespace,the requirements of the C standard not met by your example,so your example is not valid c code,and every c compiler is allowed to do anything with your text filetcc expects that the source code is correct,and has only simple error checking.Since "Test #else" (insert more space/tab here)is not defined, the example is compiled and "Hello, Test\n" is printed.gcc expects that the source code is correct,but tries sometimes a workaround on developer mistakes.For your example, gcc decides, that the identifier stops after the "Test"and gives you a warning:warning: extra tokens at the end of #ifndef directiveThe example is compiled, but "Hello, Test\n" is not printed.openwatcom expects that the source code is correct,and bails out with an error on your example:Error! E1009: Expecting 'end of line' but found '#'Since an Error was detected, the compilation in aborted.All three Compiler are correct.For reference: Section 6.10 in the C standard: Preprocessing directivesC99: n1256.pdfC11: n1570C17: n2176C23: n3096.pdfIn my c89 draft,  Preprocessing directives are in section 3.8> Fix:> According to your decision.This is not a bug in tcc.-- Regards ... Detlef

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

Re: [Tinycc-devel] Waiting for release...

[Detlef Riekenberg via Tinycc-devel]

Am 24.03.24, 16:53 schrieb "codif...@gmail.com" :> "release" personally I've just tracked git master (or is it main these days?) > and pull roughly monthly, > maybe I just got lucky, but its always "just works" (tm)Yes, using the mob branch is good (most of the time),but the tcc version in various Linux distributions is outdated.Some people even use the very old tcc 0.9.27 from the homepage athttps://bellard.org/tccwith the forward to the savannah download page:https://download.savannah.gnu.org/releases/tinycc/Only an official release can help here.Dates fom the savannah download page:2008.05.31  tcc-0.9.242009.05.18  tcc-0.9.25  ( 352 days)2013.02.15  tcc-0.9.26  (1369 days)2017.12.17  tcc-0.9.27  (1766 days)2024.03.xx  tcc-0.9.28   (Already 2289 days for today and growing.)@grishka, please...TinyCC needs a release.-- Regards ... Detlef

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

Re: [Tinycc-devel] recent riscv changes

[Detlef Riekenberg via Tinycc-devel]

Hi @ekaitz>> For adding new features, a message to the mailing list is always better.> I wasn't sure about that so I just decided to send the changes. > You are right.It is always a good idea,but very important during the rc phase.> Now that we are in the mailing list, > I have some support for extended asm that I'm not completely confident about. > I'll attach the patch, I would appreciate if you could take a look to it. > More specifically I'm not sure about how to choose the priority of the constraints, > and there's some code in `subst_asm_operand` that I'm not sure aboutUnfortunately, i do not know riscv assembly good enough to help here.-- Regards ... Detlef

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

[Tinycc-devel] Waiting for release...

[Detlef Riekenberg via Tinycc-devel]

Hi grischka.When do you plan to do a release?What can we, to help you?-- Regards ... Detlef

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

[Tinycc-devel] issue in the recent riscv change, which added the ".option" asm directive

[Detlef Riekenberg via Tinycc-devel]

Welcome to tinycc and thanks for your recent riscv-changes @Ekaitz.All are waiting for a release and should avoid to add new features.Since your changes are only for riscv targets, i hope, that the changes would not delay the release of tcc 0.9.28 even further,(but only @grischka can make a release).Are all your planned changes in the mob tree?The mentiond change added also 'DEF_ASM(rvc)' and 'DEF_ASM(norvc)' to 'riscv64-tok.h',but both are missing in 'tccasm.c'.Please take a look.For adding new features, a message to the mailing list is always better.-- Regards ... Detlef

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

[Tinycc-devel] Recent patches for the TinyCC 0.9.28 Release Candidate

[Detlef Riekenberg via Tinycc-devel]

Hi TinyCC follower.


The current branch is a release candidate for TinyCC 0.9.28 since some month.

From the active people here, only grischka has the rights to make a release,
and I suggest, that we should help him to be comfortable to make a release by:
* more testing
* add only minimal fixes to the current mob branch to increase stability
* avoid to push any new features for now

I further suggest, that for any patch, which is longer than one or two lines,
the change should be discussed here before pushing.


@grischka
I tested your recent fixes:
The i386-tcc search path works now. Thanks
(I tested with a simple Hello_World for X11 and a simple ppm viewer for X11)


@Eric Raible:
A custom allocator is not a new idea.
TinyCC has already a custom allocator and uses it by default.
How often will it be useful for a libtcc user to force TinyCC
to use an application provided allocator?
You add an overhead for every user of TinyCC for every memory allocation/free.

My additional comments to your patch:
* it is a far to big change for a release candidate
* it needs a lot of testing
* it adds more complexity

#

@kbkpbot
Yes, there are many things missing for atomic support,
but when i read your patch, i'm not sure,
if the code works with any windows compiler, which is incompatible to gcc.
(I changed my SSD and msvc is not installed yet, so I can't test that now)

Reason: "__attribute__" and "__asm__" are gcc extensions.
Are they supported by MSVC?
(Yes, i saw, that you mostly just moved the code around...)

+#ifndef __TINYC__
+void __atomic_signal_fence(int memorder) 
__attribute__((alias("__tcc_atomic_signal_fence")));


In the meantime, a macro for a fence can help


#

I suggest to revert both changes (with the cleanup from @Herman)
and wait until @grischka pushes a release.

@grischka, what do you think about reverting everything after your cleanup patch
and then push a release?


--
Bye bye ... Detlef


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

Re: [Tinycc-devel] SIMD intrinsics

[Detlef Riekenberg via Tinycc-devel]

Am 15.01.24, 08:57 schrieb Mathias Widman :> I am new to the list so forgive my lack of knowledge of previous questions.Welcome here, Mathias.> I wonder if there are any plans on incorporating/supporting SIMD intrinsics.Which target processor / which intrinsics?intrinsics are arch dependant  compiler extensions and they help the compiler during optimizations.Depending on your usecase, a simple implementation would be inline assemblyin the intrinsic header files with the same names used by other compiler.>  it seems pretty straightforward to add in the inline assembler and code gen parts?Yes, the inline assembler needs updates for unsupported mnemonicsUntil then, you can use ".byte" in inline assembly.(We use that in our tests)-- Regards ... Detlef

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

Re: [Tinycc-devel] Any plans to support utf8/utf16 string literals?

[Detlef Riekenberg via Tinycc-devel]

Am 15.01.24, 08:27 schrieb Brad Robinson via Tinycc-devel :> Just wondering if there are any plans to add support for utf8 (aka u8"string")> and utf16 (aka u"string") string literals in tcc?I also would like this c11 feature to be supportedand I have an old patch to detect thisbut it is not used in the codegen yet,and working on it has to wait after the release of tinycc 0.9.28.-- Regards ... Detlef

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

[Tinycc-devel] incomplete searchpath for i386-tcc

[Detlef Riekenberg via Tinycc-devel]

 
 Example, what does not work with i386-tcc from current mob.(on x86_64 linux)error: include file 'curses.h' not foundInstalled by the package manager in   /usr/include/curses.hWorkaround for tcc:   -I/usr/includeerror: library 'curses' not foundInstalled by the package manager in   /usr/lib/i386-linux-gnu/libcurses.soOn my xubuntu, the installed package is:  libncurses-dev:i386 I used the example from "Writing Programs with NCURSES"(ncurses-intro.pdf) in the section "Using the library"Am 06.01.24, 13:53 schrieb grischka via Tinycc-devel :

  On 06.01.2024 01:10, Detlef Riekenberg via Tinycc-devel wrote:
   >
   > Of course, there might be more issues in 0.9.28rc
   > As example, "i386-tcc" on a x86_64 linux machine
   > is missing additional search dirs:
   
   Can we see the output of "i386-tcc -vv" ?
   
   > include: "/usr/i686-linux-gnu/include"
   > lib: "/usr/i686-linux-gnu/lib"
   > crt: "/usr/i686-linux-gnu/lib"
   >
   > (there are no "crt*.o" files, "libc*" files and similar
   > in "/usr/lib/i386-linux-gnu")
   
   >
   >
   > Please do a release.
   > Please 
   > Please .
   
   
   ___
   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

Re: [Tinycc-devel] Re: Outdated tcc: Major bug in the pow function resulting in: 0.993013 = 0.860892

[Detlef Riekenberg via Tinycc-devel]

 
 Argh...tcc-mob was compiled on the new system, but it was not installed yet.I accidently tested a tcc version from 2020, provided by the newly installed OS.(And that does not work for i386-tcc)With tcc-mob, the search path seems to be ok.Sorry for the noise.Am 06.01.24, 13:53 schrieb grischka via Tinycc-devel :

  On 06.01.2024 01:10, Detlef Riekenberg via Tinycc-devel wrote:
   >
   > Of course, there might be more issues in 0.9.28rc
   > As example, "i386-tcc" on a x86_64 linux machine
   > is missing additional search dirs:
  
   Can we see the output of "i386-tcc -vv" ?
  
   > include: "/usr/i686-linux-gnu/include"
   > lib: "/usr/i686-linux-gnu/lib"
   > crt: "/usr/i686-linux-gnu/lib"
   >
   > (there are no "crt*.o" files, "libc*" files and similar
   > in "/usr/lib/i386-linux-gnu")
  
   >
   >
   > Please do a release.
   > Please 
   > Please .
  
  
   ___
   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

[Tinycc-devel] Outdated tcc: Major bug in the pow function resulting in: 0.993013 = 0.860892

[Detlef Riekenberg via Tinycc-devel]

 
 Hi Aurélie TissonThanks for your report.This was fixed at least more than 52 month ago.(I tried tcc 0.9.27+git20200815.62c30a4a,and that version works without issues)Others have also already tested your exampleals also discovered, that this is fixed.Currently, we have a tcc 0.9.28rc and waiting for @grishkato make a release from the current "mob" branch.https://repo.or.cz/tinycc.git###Hello grishka, new bug reports about issues,which are fixed long ago arrive regulary.A new release is really needed.What can we do, to help you to prepare a 0.9.28 release?Of course, there might be more issues in 0.9.28rcAs example, "i386-tcc" on a x86_64 linux machineis missing additional search dirs:  include:  "/usr/i686-linux-gnu/include" lib:   "/usr/i686-linux-gnu/lib"crt:  "/usr/i686-linux-gnu/lib"(there are no "crt*.o" files, "libc*" files and similarin "/usr/lib/i386-linux-gnu")Please do a release.Please Please .Bitte. Ein Release.Danke.Wenn du Hilfe brauchst, melde dich bitte.Ich habe Zeit, aber keine Berechtigung.-- Regards ... DetlefAm 05.01.24, 15:57 schrieb "Aurélie Tisson (BastaPrint)" :

  
   
Hello,
   
   
I discovered that TCC and GCC gave different results in a long algorithm.
   
   
I focused on the bug, and I could reduce the code to the following lines. If I reduce further the code, the bug disappears.
   
   

   
   
I think the code does not require further comments...  I'm using  tcc version 0.9.27 (x86_64 Windows)

   
   

   
   
The same calculation gives me 2 different values : 0.993013   0.860892 wheras it should give  0.993013  only (tells GCC).

   
   

   
   
#include 
#include 
   
   
int main(){
    double s = .7;
    double a = (1. - .1 * s) / (1. + .1 * s);
    double b = pow(a, .05);
    double c = pow( ((1. - .1 * s) / (1. + .1 * s)), .05);

    printf("%f   %f \n", b, c);
}
   
   

   
   
==> can anyone reproduce this?
==> any clue about the cause?
   
   

   
   
Thanks a lot !

   
  ___ 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

[Tinycc-devel] fixed in mob: Do not load all referenced libraries when linking a library

[Detlef Riekenberg]

After your suggestions and comments, i pushed an updated fix
for the build break of netbsd-curses to mob.

Thanks !



Build times (best of 3) for "netbsd-curses" on my machine (64bit linux)
The project build times include:
* generating terminfo hash
* generating compiled terminfo descriptions
* generating termcap hash


CC="tcc"  CFLAGS="-O0"  time make 2>&1 | tee _log_tcc_v2.txt
1.78user 1.37system 0:03.16elapsed 99%CPU

CC="gcc"  CFLAGS="-O0"  time make 2>&1 | tee _log_gcc_v2.txt
12.84user 4.22system 0:17.08elapsed 99%CPU

CC="clang"  CFLAGS="-O0"  time make 2>&1 | tee _log_clang_v2.txt
14.06user 7.22system 0:21.31elapsed 99%CPU


Using tcc gives a build speedup factor of 5.4 (gcc) or 6,7 (clang) here


--
Bye bye ... Detlef


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

[Tinycc-devel] Do not load all referenced libraries, when linking a library

[Detlef Riekenberg]

After the comments from grischka and Michael,
i prepared a different patch to fix the build break of netbsd-curses
and also updated the patch to current mob.


`make test` works
A testapp with netbsd-curses works,
but i am away for the next 2 weeks.


Since we have a release canditate, i decided to not push my patch to mob.


It would be nice, if you help with testing.


--
Bye bye ... Detlef
From 95045ae2407ab8070fd06810a6c97de21559c77c Mon Sep 17 00:00:00 2001
From: Detlef Riekenberg 
Date: Wed, 4 Oct 2023 22:48:48 +0200
Subject: [PATCH] tccelf: Do not load all referenced libraries when linking a library


Recursive loading of all references can break linking of libraries
(Example: building of netbsd-curses)

Thanks grischka and Michael Matz for the comments.

--
Regards ... Detlef
---
 tccelf.c | 15 ++-
 1 file changed, 2 insertions(+), 13 deletions(-)

diff --git a/tccelf.c b/tccelf.c
index 2e3d8ac..115e4ad 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -3648,19 +3648,8 @@ ST_FUNC int tcc_load_dll(TCCState *s1, int fd, const char *filename, int level)
 if (dt->d_tag == DT_RPATH)
 tcc_add_library_path(s1, dynstr + dt->d_un.d_val);

-/* load all referenced DLLs */
-for(i = 0, dt = dynamic; i < nb_dts; i++, dt++) {
-switch(dt->d_tag) {
-case DT_NEEDED:
-name = dynstr + dt->d_un.d_val;
-if (tcc_add_dllref(s1, name, -1))
-continue;
-if (tcc_add_dll(s1, name, AFF_REFERENCED_DLL) < 0) {
-ret = tcc_error_noabort("referenced dll '%s' not found", name);
-goto the_end;
-}
-}
-}
+/* do not load all referenced DLLs */
+/* recursive loading can break linking of libraries */

  ret_success:
 ret = 0;
--
2.39.2

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

Re: [Tinycc-devel] tcc 0.9.28rc testing: bug in autoconf 2.71 with AC_CHECK_DEFINE

[Detlef Riekenberg]

> > On 24/9/23 11:03, Nick Bowler wrote:
> >> The word AC_CHECK_DEFINE is not found anywhere in the Autoconf
> >> source code or documentation.
> >
> > My guess would be that the 3rd party is the autoconf archive because
> > they provide both AX_CHECK_DEFINE and AC_CHECK_DEFINE
> >
> > http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m4/ax_check_define.m4
>
> OK, I see.

Thanks Peter.
I can confirm, the "autoconf-archive" - Package is installed here.


> Ignoring the fact that the this macro definition flagrantly disregards
> the Autoconf reserved namespace...

That trap catched me.

> AC_CHECK_DEFINE here is quoting
> inconsistently: $1 is double-quoted in the argument to AC_LANG_PROGRAM,
> but it is only single-quoted in the arguments of AS_VAR_PUSHDEF and
> AC_CACHE_CHECK.

Oh, thanks for the in deepth analysis.
I will check to see, how and where i can report this bug.

> So no amount of quoting at the call site will ever solve the problem for 
> Detlef.

The suggested workarounds should help.

> We can quote __unix__ correctly for AC_LANG_PROGRAM, or we can
> quote it for the other expansions, but never both at the same time.

>  For example:
>  AC_CHECK_DEFINE([__unix@@__], [...])

>   m4_ifdef([__unix__], [m4_define([__unix__], [[__unix__]])])dnl
>   AC_CHECK_DEFINE([__unix__], [...])

I will try your suggested workarounds.

> I don't think there is any regression in Autoconf here, I don't see any
> significant difference in behaviour between Autoconf 2.72c, 2.71 or
> 2.69.

I was not sure, where the bug belongs, and with the "AC_" prefix, i started 
here.

--
Regards ... Detlef


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

Re: [Tinycc-devel] tcc 0.9.28rc testing: bug in autoconf 2.71 with AC_CHECK_DEFINE

[Detlef Riekenberg]

Thanks Nick and Peter for your analysis.

Yes, the "AC_" prefix fooled me, that AC_CHECK_DEFINE belongs to autoconf.


> On 2023-09-23, Nick Bowler  wrote:
> > On 2023-09-23, Detlef Riekenberg  wrote:
> >> AC_CHECK_DEFINE(__unix, CFLAGS="-DFOUND__unix $CFLAGS")
> >> AC_CHECK_DEFINE(__unix__, CFLAGS="-DFOUND__unix__ $CFLAGS")
> >> AC_CHECK_DEFINE(__linux__, CFLAGS="-DFOUND__linux__ $CFLAGS")
> [...]
> > So it sounds like there must be some third party code involved which
> > is defining this macro (and this code is defining macros in the AC_*
> > namespace to make it look like it came from Autoconf when in fact it
> > did not).

I can confirm, that i have the "autoconf-archive" package insalled.
The installed "/usr/share/aclocal/ax_check_define.m4"
contains AC_CHECK_DEFINE and AX_CHECK_DEFINE

> Just to add, you don't need any third party macros to check for typical
> C predefined macros including __unix, etc.  I would write such checks
> something like this (untested):
>
>   AC_COMPUTE_INT([unix_val], [__unix], [@@], [unix_val=0])
>   AS_IF([test $unix_val -ne 0],
> [put code here to run when __unix is defined and is non-zero])

Learned something new. Thanks
The magic "[@@]" is really strange.

> Hope that helps,

Sure.
Thanks


--
Regards ... Detlef


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

[Tinycc-devel] tcc 0.9.28rc testing: bug in autoconf 2.71 with AC_CHECK_DEFINE

[Detlef Riekenberg]

Hi autoconf team.

During testing of tcc 0.9.28rc,
I found a strange bug in autoconf 2.71 with `AC_CHECK_DEFINE` for `__unix__`.
For comparsion, i added checks for "__unix" and "__linux__":

Overview:
* [__unix__] always found, but the log text is crippled
*  __unix__  never found and the log text is crippled
* The second check does not use the cached result from the first check

* When i duplicate the tests, the duplicate test used the cached result
  from the previous check, but all other failures remain.
  (1: first result: see above, 2: cached result from 1,
   3: different result: see above, 4: cached result from 3)


I am using tcc 0.9.28rc on linux
and gcc 12.3.0 produces the same results.


Please test this snipped with the current 2.72rc:
```
AC_CHECK_DEFINE(__unix, CFLAGS="-DFOUND__unix $CFLAGS")
AC_CHECK_DEFINE(__unix__, CFLAGS="-DFOUND__unix__ $CFLAGS")
AC_CHECK_DEFINE(__linux__, CFLAGS="-DFOUND__linux__ $CFLAGS")

AC_CHECK_DEFINE([__unix], CFLAGS="-DFOUNDxx__unix $CFLAGS")
AC_CHECK_DEFINE([__unix__], CFLAGS="-DFOUNDxx__unix__ $CFLAGS")
AC_CHECK_DEFINE([__linux__], CFLAGS="-DFOUNDxx__linux__ $CFLAGS")
```

buggy results:
```
checking for __unix defined... yes
checking for  defined... no
checking for __linux__ defined... yes
checking for __unix defined... (cached) yes
checking for  defined... yes
checking for __linux__ defined... (cached) yes
```


And yes, when the checks are reordered, 
```
AC_CHECK_DEFINE([__unix], CFLAGS="-DFOUNDxx__unix $CFLAGS")
AC_CHECK_DEFINE([__unix__], CFLAGS="-DFOUNDxx__unix__ $CFLAGS")
AC_CHECK_DEFINE([__linux__], CFLAGS="-DFOUNDxx__linux__ $CFLAGS")

AC_CHECK_DEFINE(__unix, CFLAGS="-DFOUND__unix $CFLAGS")
AC_CHECK_DEFINE(__unix__, CFLAGS="-DFOUND__unix__ $CFLAGS")
AC_CHECK_DEFINE(__linux__, CFLAGS="-DFOUND__linux__ $CFLAGS")
```

... the results are different:

```
checking for __unix defined... yes
checking for  defined... yes
checking for __linux__ defined... yes
checking for __unix defined... (cached) yes
checking for  defined... no
checking for __linux__ defined... (cached) yes
```

* What is 2.72rc doing?
* Should i add a bug report for 2.71 to document this bug?


--
Bye bye ... Detlef


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

Re: [Tinycc-devel] rc testing with netbsd-curses: build break

[Detlef Riekenberg]

> >> Obviously when loading a .so library,
> >> tcc additionally is loads its dependencies too.
> >
> > That would be correct, when the target is TCC_OUTPUT_MEMORY
> > but i think, in all other cases, tcc should not do that.
>
> I'd suggest to use "grep -nrw tcc_load_dll ." for example.  There is
> only one place from where tcc_load_dll() is called:

i used "git greo -n -C 12 tcc_load_dll"

> in libtcc.c:tcc_add_file_internal():
>
>  case AFF_BINTYPE_DYN:
>  if (s1->output_type == TCC_OUTPUT_MEMORY) {
> #ifdef TCC_IS_NATIVE
>  void* dl = dlopen(filename, RTLD_GLOBAL | RTLD_LAZY);
>  if (dl)
>  tcc_add_dllref(s1, filename, 0)->handle = dl, ret = 0;
> #endif
>  } else
>  ret = tcc_load_dll(s1, fd, filename, (flags & 
> AFF_REFERENCED_DLL) != 0);
>  break;


> So, for TCC_OUTPUT_MEMORY, tcc does not use tcc_load_dll(),  It calls
> "dlopen()" instead.  Where dlopen() would invoke the dynamic linker
> (ld.so) and that one then would take care to load any dependencies
> (DT_NEEDED tags).

I found the same location, but it was in the night
and i unfortunately stopped code flow analyzis
after reading "TCC_IS_NATIVE".

What about:
* leave the code, as is
* remember this corner case
* go ahead with the release
* pick it up again after the release

or

* disable recursive the loading of the libraries
* remember this corner case
* go ahead with the release
* pick it up again after the release

Since you also do not know yet, in which case the code is needed,
a real fix requires a lot of time and some new tests

I think, the call to "tcc_load_ddl" was added here:
https://repo.or.cz/tinycc.git/commit/1df662c1b094d250db0501cf31db83dc5f9060e4


I really want to have a new release now, because
* tell eyeryone, that tcc is alive
* let compiler-explorer use a new tcc version
* let compiler-explorer use --enable-cross

* after a release, we can fix tcc to use "nolibc" without issues.
  That would make tcc independant of an installed host libc


nolibc introducion:
https://lwn.net/Articles/920158/

Multi-File-Sources:
https://github.com/wtarreau/nolibc

nolibc was merged into the linux kernel.
Recent updates are here:
https://git.kernel.org/pub/scm/linux/kernel/git/wtarreau/nolibc.git/tree/

There was a single file version, which mentioned, that nolibc is dual licensed.
In addition to GPL 2.0, there was also permissive license given.
When i remember correctly: MIT


--
Regards ... Detlef



source tree


--
Regards ... Detlef



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

Re: [Tinycc-devel] rc testing with netbsd-curses: build break

[Detlef Riekenberg]

--
Bye bye ... Detlef

> > libcurses/libcurses.so: error: referenced dll 'libterminfo.so' not found
> > make: *** [GNUmakefile:529: libpanel/libpanel.so] Fehler 1

> > * libpanel/libpanel.so depends on libcurses/libcurses.so
> > * libcurses/libcurses.so depends on libterminfo/libterminfo.so
> > * tcc searches for libterminfo.so, but fails

>
> That happened to get into my way too at some point.
> Obviously when loading a .so library,
> tcc additionally is loads its dependencies too.

That would be correct, when the target is TCC_OUTPUT_MEMORY
but i think, in all other cases, tcc should not do that.

> It's rather early code, at tccelf.c:3653
>
>  /* load all referenced DLLs */
>  for(i = 0, dt = dynamic; i < nb_dts; i++, dt++) {
>  switch(dt->d_tag) {
>  case DT_NEEDED:
>   ...

> What's the point isn't entirely clear to me.

The point here is, that tcc tries to load all referenced libraries,
which is wrong.

> Normally if one wants to use symbols from say libterminfo too
> one could just write -lcurses -lterminfo.

"-lterminfo" is wrong, as the affected code (libpanel.so)
has no reference to "libterminfo.so" but needs only "libcurses.so".
The fact, that "libcurses.so" depends on "libterminfo.so" is an implementation 
detail.

Transformed to windows:
The Program needs kernel32.dll, but that kernel32.dll depends on ntdll.dll
is also an implementation detail.


> There may be three options:
> 1) downgrade the error to a warning,
> 2) disable loading of referenced DLLs completely,
> 3) have some switch to choose behavior
 (if such exists in gcc for example)

#1: tcc still tries to load DT_NEEDED libraries.
#3: gcc builds libpanel.so without any fancy switch

I think, "2" is the only correct fix.

I don't know the tcc callchain good enough to say,
in which codepath lands in tccelf.c:3658

Do you think, that making tccelf.c:3658 to tccelf.c:3661
depend on  is enough?

At least, that fixes the compilation break.



$ git diff tccelf.c | tee _avoid_recursive_lib_loading.txt
diff --git a/tccelf.c b/tccelf.c
index 2e3d8ac..31b1b16 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -3655,9 +3655,13 @@ ST_FUNC int tcc_load_dll(TCCState *s1, int fd, const 
char *filename, int level)
 name = dynstr + dt->d_un.d_val;
 if (tcc_add_dllref(s1, name, -1))
 continue;
-if (tcc_add_dll(s1, name, AFF_REFERENCED_DLL) < 0) {
-ret = tcc_error_noabort("referenced dll '%s' not found", name);
-goto the_end;
+
+if (s1->output_type == TCC_OUTPUT_MEMORY) {
+/* TODO: check, when this code is reached/needed */
+if (tcc_add_dll(s1, name, AFF_REFERENCED_DLL) < 0) {
+ret = tcc_error_noabort("referenced dll '%s' not found", 
name);
+goto the_end;
+}
 }
 }
 }



--
Regards ... Detlef


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

[Tinycc-devel] Fw: TCC 0.9.28rc testing: dte (updated)

[Detlef Riekenberg]

Sorry, forget the compile time tests.
There was sill an "-O2" active.


> Results for testing 0.9.28rc with the project
> https://github.com/craigbarnes/dte
>
> * build break
>   -> fixed in mob
>
> * 128 warnings: assignment from incompatible pointer type
>-> that's ok. The project source has macros to disable these warnings
>   for gcc and clang
>
> * 1 warning: function might return no value: 'xvasprintf'
>   -> In the project source is a function call ("fatal_error") which is 
> declared as "noreturn"
>  tcc is not smart enough to detect, that the end of the function will 
> never be reached.
>
> * All tests are passed with "make check", but with tcc, fewer tests are run
>   gcc/clang: 30271, tcc: 30247.
>   (the 32bit numbers differ, and my system is missing a 32bit library)
>


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

[Tinycc-devel] TCC 0.9.28rc testing: dte

[Detlef Riekenberg]

Results for testing 0.9.28rc with the project
https://github.com/craigbarnes/dte

* build break
  -> fixed in mob

* 128 warnings: assignment from incompatible pointer type
   -> that's ok. The project source has macros to disable these warnings
  for gcc and clang

* 1 warning: function might return no value: 'xvasprintf'
  -> In the project source is a function call ("fatal_error") which is declared 
as "noreturn"
 tcc is not smart enough to detect, that the end of the function will never 
be reached.

* All tests are passed with "make check", but with tcc, fewer tests are run
  gcc/clang: 30271, tcc: 30247.
  (the 32bit numbers differ, and my system is missing a 32bit library)

* compile time comparsion (1x warmup, 5x time collected) with "gcc -O0" and 
clang -O0
  (always after a "make clean").
  Machine is a laptop with linux (i7 2620M: 2 core, 4 thread)

make (tcc):
1.10user 0.67system 0:00.57elapsed 310%CPU
1.13user 0.66system 0:00.58elapsed 306%CPU
1.13user 0.68system 0:00.58elapsed 309%CPU
1.06user 0.69system 0:00.57elapsed 307%CPU
1.07user 0.70system 0:00.57elapsed 309%CPU
average: 0,574

make (gcc 12.3.0):
25.95user 3.06system 0:07.85elapsed 369%CPU
25.79user 3.24system 0:07.94elapsed 365%CPU
26.04user 2.98system 0:07.97elapsed 363%CPU
26.02user 3.00system 0:08.13elapsed 356%CPU
26.02user 3.07system 0:07.96elapsed 365%CPU
average: 7,97
tcc is ~14 times faster


make (clang 15.0.7)
25.58user 4.38system 0:08.64elapsed 346%CPU
25.64user 4.50system 0:08.44elapsed 356%CPU
25.77user 4.37system 0:08.60elapsed 350%CPU
25.45user 4.57system 0:08.75elapsed 342%CPU
25.77user 4.36system 0:08.40elapsed 358%CPU
average: 8,566
tcc is ~15 times faster


For comparsion, a quick check without parallel jobs:

make -j1 check:
tcc1.06user 0.65system 0:01.71elapsed 100%CPU
gcc   20.01user 2.88system 0:22.90elapsed 100%CPU
clang 17.93user 3.84system 0:21.77elapsed 100%CPU


make -j1:
tcc0.85user 0.46system 0:01.31elapsed 100%CPU
gcc   15.17user 2.38system 0:17.55elapsed 100%CPU
clang 14.34user 3.08system 0:17.43elapsed 99%CPU

tcc is still >10 times faster, when using no paralell make jobs



--
Bye bye ... Detlef


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

[Tinycc-devel] rc testing with netbsd-curses: build break

[Detlef Riekenberg]

For testing the tcc rc, i tried https://github.com/sabotage-linux/netbsd-curses:
CC="tcc" make

Build breaks with tcc for "libpanel/libpanel.so" (gcc works):

tcc -v  -shared -o libpanel/libpanel.so libpanel/_deck.lo libpanel/above.lo 
libpanel/below.lo libpanel/bottom.lo libpanel/del.lo libpanel/getuser.lo 
libpanel/hidden.lo libpanel/hide.lo libpanel/move.lo libpanel/new.lo 
libpanel/replace.lo libpanel/setuser.lo libpanel/show.lo libpanel/top.lo 
libpanel/update.lo libpanel/window.lo libcurses/libcurses.so 
-Wl,-soname=libpanel.so
tcc version 0.9.28rc 2023-09-09 mob@7f39b4f (x86_64 Linux)
-> libpanel/_deck.lo
-> libpanel/above.lo
-> libpanel/below.lo
-> libpanel/bottom.lo
-> libpanel/del.lo
-> libpanel/getuser.lo
-> libpanel/hidden.lo
-> libpanel/hide.lo
-> libpanel/move.lo
-> libpanel/new.lo
-> libpanel/replace.lo
-> libpanel/setuser.lo
-> libpanel/show.lo
-> libpanel/top.lo
-> libpanel/update.lo
-> libpanel/window.lo
-> libcurses/libcurses.so
libcurses/libcurses.so: error: referenced dll 'libterminfo.so' not found
make: *** [GNUmakefile:529: libpanel/libpanel.so] Fehler 1
Command exited with non-zero status 2


Analyse results so far:
* libpanel/libpanel.so depends on libcurses/libcurses.so
* libcurses/libcurses.so depends on libterminfo/libterminfo.so
* tcc searches for libterminfo.so, but fails
* from the failure message, the code is in tccelf.c:3659


$ CC="tcc -v -v -v "   make  libpanel/libpanel.so
tcc -v -v -v  -shared -o libpanel/libpanel.so libpanel/_deck.lo 
libpanel/above.lo libpanel/below.lo libpanel/bottom.lo libpanel/del.lo 
libpanel/getuser.lo libpanel/hidden.lo libpanel/hide.lo libpanel/move.lo 
libpanel/new.lo libpanel/replace.lo libpanel/setuser.lo libpanel/show.lo 
libpanel/top.lo libpanel/update.lo libpanel/window.lo libcurses/libcurses.so 
-Wl,-soname=libpanel.so
tcc version 0.9.28rc 2023-09-09 mob@7f39b4f (x86_64 Linux)
-> /usr/lib/x86_64-linux-gnu/crti.o
-> libpanel/_deck.lo
-> libpanel/above.lo
-> libpanel/below.lo
-> libpanel/bottom.lo
-> libpanel/del.lo
-> libpanel/getuser.lo
-> libpanel/hidden.lo
-> libpanel/hide.lo
-> libpanel/move.lo
-> libpanel/new.lo
-> libpanel/replace.lo
-> libpanel/setuser.lo
-> libpanel/show.lo
-> libpanel/top.lo
-> libpanel/update.lo
-> libpanel/window.lo
-> libcurses/libcurses.so
nf /usr/lib/x86_64-linux-gnu/tcc/libterminfo.so
nf /usr/lib/x86_64-linux-gnu/libterminfo.so
nf /usr/lib/libterminfo.so
nf /lib/x86_64-linux-gnu/libterminfo.so
nf /lib/libterminfo.so
nf /usr/local/lib/x86_64-linux-gnu/libterminfo.so
nf /usr/local/lib/libterminfo.so
libcurses/libcurses.so: error: referenced dll 'libterminfo.so' not found
make: *** [GNUmakefile:529: libpanel/libpanel.so] Fehler 1
Command exited with non-zero status 2
0.01user 0.00system 0:00.02elapsed 100%CPU (0avgtext+0avgdata 3328maxresident)k

Any ideas, how to stop recurse loading of a referenced library?

I already tried a patch for netbsd-curses, but that is only a workaround:
https://github.com/sabotage-linux/netbsd-curses/pull/55


--
Bye bye ... Detlef


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

Re: [Tinycc-devel] Re : Lock-free tcc

[Detlef Riekenberg]

My Wishlist / Roadmap for 1.0


Since we have now 0.9.28rc ( thanks for that, grischka),
i want to write down my wishlist / roadmap
for a future 1.0 release
and ask you for improvements / comments.

( I have not added any issue/enhancement request
to the bugtracker at savannah yet. )

##  Fix / Update, what we have and add, was is missing
(Keep in mind the goals for tcc:
simple with a high compilation speed)

* The webpage from fabrice mentions, that tcc is 9 times faster as gcc
- Does anybody know, what lynx version was used?
- I tested once with an old lynx version and 32bit target:
  tcc: 1.09sec / gcc: ~8.5 sec -> tcc is nearly 8x faster

* The webpage from fabrice mentions, that the size of tcc is only 100k
- Does anybody know, which config was used?
- I did not test, how far the size of tcc can be reduced,
  without to cripple tcc too much.
- Is it possible to disable dwarf and / or stabs / win32 debug?
- I expect, that the small size was a cross compiler version
  (to disable the "-run" option).

* everywhere is mentioned, that tcc aims for c99 compatibility
- i am working on a testsuite, to verify, what is missing for a c std
- with the move of manny programs to use multithreading
  and other modern C11 features, i suggest,
  that the goal for tcc should be updated to C11 compatibility.
- support for complex is missing (c99: required, but c11: optional)
- atomic must be handled in the compiler as a storage class
  (every acces to any atomic variable has to be atomic.
   tcc has only support for the atomic macros)
- Thread local Storage needs to be handled as storage class
  (x86 family: segment depends on OS:  fs:offset or gs:offset)
 - "auto" was a storage class and is a variable type since C11

... More updates will follow

--
--
Regards ... Detlef

Sent with Delta Chat Messenger:  https://delta.chat


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

[Tinycc-devel] Es Eilt sehr / Very urgent: Bad tags on the tinycc project page

[Detlef Riekenberg]

Hi grischkathanks for the 0.9.28rc,  I will test it as much as possible.But please:* check and remove the bad tags from the repo.or.cz  project pageSome tags are really bad.I hope, that you can delete them as project admin,without additional help of repo.or.cz-- Regards ... Detlef

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

Re: [Tinycc-devel] Relative paths of include files are not normalised, which can break #pragma once

[Detlef Riekenberg]

Hi Herman

> > On 25.06.2023 20:30, Herman ten Brugge via Tinycc-devel wrote:
> >>
> >> I just pushed a patch to fix this.
> >
> > Hi Hermann,
> >
> > some numbers from Win32:
> >
> > before:
> >   # 6.334 s, 85768 lines/s, 27.9 MB/s
> > after first patch:
> >   # 11.825 s, 45941 lines/s, 14.9 MB/s
> > after second patch:
> >   # 10.406 s, 52206 lines/s, 17.0 MB/s
> >
> > Hm ...

I do not think, that we really need a 64bit hash (with 64bit multiply)
for the complete file content.

In addition to the filename and the filesize, i suggest to use "st_mtime":
 much cheaper and available for free.


> I tested this also before committing. I could not find a problem.
> I only have an x86_64 machine on redhat linux and a raspberry pi with 32 
> and 64 bits.
> I also have no Windows any more and my i386 machine died about 10 years ago.

> So I did the measurement with wine (32/64 bits) and saw no difference 
> before and after commit.

Your machine is too recent / too fast / has too much memory.
* Multiplications on recent processors are much faster than on older processors.
* A SSD is so fast, that loading many includes many times has no resonable 
delay.
* With a huge amount of system memory, your include directory entries and many 
include files are cached.

For speed tests comparsion, a low resource VM or an old system with fewer RAM 
and a HDD will show the slowdown.
(disable kernel VM support / force JIT mode to make the emulated processor 
slower)

> I cannot currently think of a better solution for pragma once. Maybe you 
> can?

* replace the hash with "st_mtime"


-- 
Regards ... Detlef




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

[Tinycc-devel] Please do a 0.9.28 release.

[Detlef Riekenberg]

Hi Grishka.Please create a 0.9.28 release.Afterwards, we can work towards a 1.0.0 release, probably in this year.I hope, that we get more attention with a 0.9.28 releaseand maybe also new contributions/testers.Thanks for your effort.

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

[Tinycc-devel] Has someone a Windows on ARM machine for a test?

[Detlef Riekenberg]

tcc is using IMAGE_FILE_MACHINE_ARM  (0x1c0) in tccpe.c.I expect, that this works since Windows CE,but can someone with a recent Windows (10/11 on ARM) system please check and report back herewhat the os files use and that a tcc compiled buinary works.```Microsoft documents also  IMAGE_FILE_MACHINE_ARMNT (0x1c4)as ARM, Thumb-2, LE with the hint:This  Constant is available starting with win 7 and server 2008r2.```Thanks.-- Regards ... Detlef

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

[Tinycc-devel] Another crash for a yarpgen1 testcase: seed 1988

[Detlef Riekenberg]

Current tcc has still a problem for a yarpgen_v1 testcase (using seed 1988)
Initialization works, but the program crash in the function tf_0_foo().

Output, when compiled with "-b -bt":

func.c:344: at tf_0_foo: RUNTIME ERROR: division by zero
driver.c:885: by main

Stripped down source is attached.

--
Bye bye ... Detlef


01988.tar.gz
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Crash for yarpgen_1 with seed 319: fixed in mob

[Detlef Riekenberg]

> I tested tcc (mob:ef3eb02) with yarpgen v1 for seeds upto 999
> and found only one failure (seed 319):
>
> tcc (mob:ef3eb02) created a program, which segfaults when running.
> 
> Building with "-bt -v" and running produced:
> $ tst-O0
> func.c:4286: at tf_3_foo: RUNTIME ERROR: invalid memory access
> driver.c:2669: by main
> 
> 
> Buidinǵ with "-b -bt  -v"  and running produced:
> $ tst-O0
> func.c:4450: at tf_3_foo: RUNTIME ERROR: division by zero
> driver.c:2669: by main


This bug is also already fixed in current mob.
Thanks again.

I'm now testing yarpgen1 with seed 1000 and up.

-- 
Bye bye ... Detlef



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

[Tinycc-devel] Overview for ubuntu, wich package provides which file.

[Detlef Riekenberg]

I found this web page:

https://packages.ubuntu.com/search?mode=exactfilename=lunar=all=any=en=crt1.o=contents


--
Bye bye ... Detlef


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

[Tinycc-devel] Help needed, where to find libc startup/runtime files

[Detlef Riekenberg]

Hi.

In order to help grishka to fix i386-tcc on a x86_64 linux machine,
we should collect infos, where the startup/runtime files are located.

On my machine (xubuntu 23.04: lunar):
The libc can be  found here:
 dpkg -S  libc.so | grep 86 |  sort
libc6-amd64-cross: /usr/x86_64-linux-gnu/lib/libc.so.6
libc6-amd64-i386-cross: /usr/i686-linux-gnu/lib64/libc.so.6
libc6-amd64:i386: /lib64/libc.so.6
libc6:amd64: /lib/x86_64-linux-gnu/libc.so.6
libc6-dev-amd64-cross: /usr/x86_64-linux-gnu/lib/libc.so
libc6-dev-amd64-i386-cross: /usr/i686-linux-gnu/lib64/libc.so
libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/libc.so
libc6-dev-i386-amd64-cross: /usr/x86_64-linux-gnu/lib32/libc.so
libc6-dev-i386-cross: /usr/i686-linux-gnu/lib/libc.so
libc6-dev-x32-i386-cross: /usr/i686-linux-gnu/libx32/libc.so
libc6-i386-amd64-cross: /usr/x86_64-linux-gnu/lib32/libc.so.6
libc6-i386-cross: /usr/i686-linux-gnu/lib/libc.so.6
libc6:i386: /lib/i386-linux-gnu/libc.so.6
libc6-x32-i386-cross: /usr/i686-linux-gnu/libx32/libc.so.6
libc6-x32:i386: /libx32/libc.so.6
musl:amd64: /lib/x86_64-linux-musl/libc.so


The startup-files are here:
$ dpkg -S crt1.o | grep -v "[gMS]crt" | grep -v "rcrt"  | sort
libc6-dev-amd64-cross: /usr/x86_64-linux-gnu/lib/crt1.o
libc6-dev-amd64-i386-cross: /usr/i686-linux-gnu/lib64/crt1.o
libc6-dev:amd64: /usr/lib/x86_64-linux-gnu/crt1.o
libc6-dev-arm64-cross: /usr/aarch64-linux-gnu/lib/crt1.o
libc6-dev-armhf-cross: /usr/arm-linux-gnueabihf/lib/crt1.o
libc6-dev-i386-amd64-cross: /usr/x86_64-linux-gnu/lib32/crt1.o
libc6-dev-i386-cross: /usr/i686-linux-gnu/lib/crt1.o
libc6-dev-x32-i386-cross: /usr/i686-linux-gnu/libx32/crt1.o
mingw-w64-i686-dev: /usr/i686-w64-mingw32/lib/crt1.o
mingw-w64-i686-dev: /usr/i686-w64-mingw32/lib/dllcrt1.o
mingw-w64-x86-64-dev: /usr/x86_64-w64-mingw32/lib/crt1.o
mingw-w64-x86-64-dev: /usr/x86_64-w64-mingw32/lib/dllcrt1.o
musl-dev:amd64: /usr/lib/x86_64-linux-musl/crt1.o





--
Bye bye ... Detlef


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

[Tinycc-devel] All known yarpgenv1 bugs fixed.Thanks Michael and Herman

[Detlef Riekenberg]

Thank you so much,  Michael and Herman for fixing the remaining yarpgen(v1) bugs,which i found with my testscript so far. (yarpgen.sh)The yarpgen.sh testscript was born out of my csmith testscript (csmith.sh).For your Info: I patched yarpgen, to generate the tons of printf on request.(Pull request send, but i'm not sure, if they want to update the old v1 codebase).Compilation speed Info:I used 'time' on my old laptop with yarpgen_v1 in c99 mode for seed 1 to seed 200.(Default OPTIMIZE is '-O0')368.65s  TESTCC=tcc  REFCC=gcc371.67s  TESTCC=tcc  REFCC=clang135.64s  TESTCC=tcc  REFCC=tccThe goal of the last run was not to find failures, but to show the speed advantage of tcc. (on top of the scripttime)I want to try OpenWatcom (v2 fork),  but wcl386 is far too slow.See my OW bug 1045 from feb. 2023 (source attached there).(using seed 25 and yarpgen_v1 in 32bit mode)tcc:  0,4sgcc:   20,8sclang:23,4sowcc:  490,4sYes, gcc/clang are about 50 times slower as tccand ow is about 1000 times slower as tcc for this testcase.Ping to grishka:  What about fixing your bug for 'tcc -m32' /  i386-tcc,which you introduced by reverting my patchesand prepare a release of tcc 0.9.28?That can give us 'tcc -m32' support at compiler-explorerwith using just a simple '--enable-cross' during configureand also a much newer tcc codebase used in all linux distros.When you need something to test, please let us know.I would do a release, but i do not have write access.When 0.9.28 is out, i suggest, that we work together to prepare for a tcc 1.0.0 release in the next months.-- Regards, Detlef

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

[Tinycc-devel] Another bug in tcc: Wrong array initialization (yarpgen.v1)

[Detlef Riekenberg]

I added another tcc bug report, discovered by yarpgen (v1).https://savannah.nongnu.org/bugs/?63895Initialization of an array (of struct tf_3_struct_2) is broken.tf_3_struct_2 contains some  structs of type tf_3_struct_1and tf_3_struct_1 contains bitfields and non bitfield member,and tcc always fails to initialize the member_1_3 of  tf_3_struct_1In the attached source files in the bug report, i split the initializationof tf_3_array_5 in multiple lines.The original initialization was in one line, similar to tf_3_array_6 and tf_3_array_7.(the source for tf_3_array_6 and  tf_3_array_7  is commented out by default)Any ideas?-- bye bye ... Detlef

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

[Tinycc-devel] Bug 63816 fixed (yarpgen_v1). Thanks Michael

[Detlef Riekenberg]

Thanks Michael.Your commit c771cb52 fixes a lot of bugs in the yarpgen v1 generated tests.For seed values from 1 to 99, only 4 result failures left: 26, 56, 64 and 84.For 100 to 200, there are some more result failures (102, 117 and 173)and some compile aborts: 123, 143, 197.-- bye bye ... Detlef

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

Re: [Tinycc-devel] Re: Cross compiling for riscv64 on arm64

[Detlef Riekenberg]

 
 For tcc, it should make no difference in the code, if your system is a x86_64 or an aarch64 machine,but i expect, that tcc on aarch64 is far less tested.And yes, an full assembler for riscv64 is missing in tcc.For your issues with the missing "crt1.o" and "crti.o" files:These are the startup files and they are provided byby the c runtime library. (dev package)For the gnu c library, they are in the cross dev packagesin your linux distro.A gcc cross compiler package is always specific: one host, one target(family), but you can try zig.While the package is designed/created for the zig language, zig is also a c and a c++ compiler (mostly based on clang and llvm).The interesting part of zig is also the fact, that all targets are supported in one packageand that the c and c++ runtime librariesare included in source form and compiledfor each target.And the zig downloads are not only x86_64 and x86, but also for running zig on aarch64 systems(linux, windows, macos)See the downloads at  https://ziglang.org/downloadsand you might want to try: zig-linux-aarch64-*zig  cc-target  riscv64-linux-muslzig  c++  -target  riscv64-linux-muslsupported targets:( https://ziglang.org/learn/overview/#support-table )-- bye bye ... DetlefAm 10.02.23, 11:21 schrieb Sagar Acharya via Tinycc-devel :

  I have this feature request. Can you please add asm support for riscv64 cross compiler built on arm64?
   Thanking you
   Sagar Acharya
   https://designman.org
   
   
   
   7 Feb 2023, 21:22 by sagaracha...@tutanota.com:
   
   > musl isn't compiled for riscv64. I tried to compile musl-1.2.3 with
   >
   > cd musl-1.2.3
   > ./configure --target=riscv64 CC=riscv64-tcc
   > make
   >
   > It shows an error which has asm module
   >
   > __asm__();
   >
   > I think current riscv64 cross compiler doesn't support asm. Is riscv64-asm.c for physical hardware based on rv64 processor and not for cross compilation?
   >
   > Thanking you
   > Sagar Acharya
   > https://designman.org
   >
   >
   >
   > 6 Feb 2023, 23:39 by sagaracha...@tutanota.com:
   >
   >> I built a cross-compiler with
   >>
   >> ./configure --config-musl
   >> make cross-riscv64
   >>
   >> On using the built riscv64-tcc to compile, I get,
   >>
   >> tcc: error: file 'crt1.o' not found
   >> tcc: error: file 'crti.o' not found
   >> error: include file 'stdint.h' not found
   >>
   >> Please help.
   >>
   >>
   >> Thanking you
   >> Sagar Acharya
   >>
   >>
   >>
   >> 6 Feb 2023, 21:17 by sagaracha...@tutanota.com:
   >>
   >>> I built an older commit successfully for
   >>>
   >>> --config-musl
   >>>
   >>> Can you help me with how to build tcc on arm64 to cross-compile a program for riscv64?
   >>>
   >>>
   >>> Thanking you
   >>> Sagar Acharya
   >>> https://designman.org
   >>>
   >>
   >>
   
   ___
   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

Re: [Tinycc-devel] tcc latest version and new glibc

[Detlef Riekenberg]

 
 Hi grischka.Another case, where the latest release makes problems,but current mob works.You said and did nothing about releasing a 0.9.28 from current mob and prepare for a  1.0 release.I already asked some month ago for a release.You also said and did nothing  to fix the link issue for i386-tcc on a 64 bit linux machine, which you introduced by reverting my patches.(I did a fresh install of xubuntu 23.04, and the 32bit files are installed in /usr/i686-linux-gnu/include and /usr/i686-linux-gnu/lib,but i have no idea, if there are still  systems,  which use /usr/i386-linux-gnu/* )When you need some help, please let us know.-- bye bye ... DetlefAm 07.02.23, 01:41 schrieb Ziyao via Tinycc-devel :

  On 2023-02-07 07:37, Fausto Saporito wrote:
   > Hello,
   > 
   > I’m trying to build the latest version of TCC with glibc 2.34 and
   > __malloc_hook is not present anymore.
   
   > make[1]: Entering directory '/home/fausap/TC/tcc-0.9.27/lib'
   
   It seems that you are working on 0.9.27, which is a quite old version.
   
   You may try the latest commit on branch mob, which works fine for me.
   
   (I remember there used to be a plan for 1.0.0, btw)
   
   -- 
   Ziyao
   
   ___
   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

Re: [Tinycc-devel] FWD: Can't build for riscv64 or arm64

[Detlef Riekenberg]

Hi Sagar

tcc has no support for 128bit int types.
__uint128_t
__int128_t


You might try with a replacement (typedef struct with 2x uint64)
This should be at least enough for the structsize for the typedef in signal.h,
but acessing the elements in the code you try to compile will propably fail

-- 
Bye bye ... Detlef


> When building lib/bt-exe.c , it imports ../tccrun.c
> Which throws error
> 
> /usr/include/bits/signal.h:14: error ';' expected (got "__uint128_t"
> 
> /usr/include/bits/signal.h is as follows:
> 
> typedef struct {
>     __uint128_t vregs[32];
>     unsigned int fpsr;
>     unsigned int fpcr;



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

[Tinycc-devel] C standards committee

[Detlef Riekenberg]

Hi JeanHeydI'm tracking c23 and we already exchanged some mails last autum.There are also bug reports for the open issues i send to you.tcc status, without additional testing( see http://www.github.com/winspool/stdtests )c99: complex missing (but that's allowed since c11 with the define)c99: _Pragma keyword missing (#pragma works)c11: unicode strings missing:  u8, u and U prefixc11: threads.h: does thread/sync functions need compiler support?c11: stdatomic.h: needs some workc11: _Thread_local: missingc17: not looked atc23:  __has_include: implementedc23: _Static_assert without comment: supportedc23:  #warning: implementedA lot of things in the C standard are not checked in our testsuite.Fun fact: The c23 proposal for '__has_include' mentioned, that tcc supports '__has_include', but at that time, only the keyword was detected, but ignored  :-)Autoconf feature checks for c11 where already on this list.Last missing step used by Autoconf for enable  c11 with tccare the u8 strings/literals.Primary advantage for using  tcc is compilation speed,so every fancy feature added to the C standard is probably bad for tcc.btw, i'm looking at / following:* OpenWatcom-v2* Autoconf* csmith  ( see also: https://www.github.com/winspool/csmith.sh )* qbe* zig ( for 'zig cc' mode )* some other projects-- bye bye ... Detlef

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

[Tinycc-devel] supported newer std c features in tinycc

[Detlef Riekenberg]

Oh, we also support the c11 variant of* _Static_assertthe upcoming c23 update makes the messagein _Static_assert optional. That should be easy to support-- Regards, Detlef

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

Re: [Tinycc-devel] Re: commit e5eedc0cd

[Detlef Riekenberg]

Hi grischka.At the moment, i find nothing, what is required in /libto build  i386 software on x86_64,but only things for running software.But that case must be handled by the compiled software.Can you please make a 0.9.28 release in the near future?That allow linux packages a far more current packagewith the new features.After the path fixes for i386-tcc, I want to have an updated Compiler explorer.https://godbolt.orgAfter a  0.9.28 release, i want to check every requirement for C99.When we support that (peobably excluding complex math), i suggest a version 1.0 releaseas c99 compatible (probably excluding complex math)with support for some c11 feature.missing c99 features already found:* _Pragma* #pragma STDC FENV_ACCESS* #pragma STDC FP_CONTRACT* #pragma STDC CX_LIMITED_RANGE* complex math implemented c11 features already found: * _Generic()* _Alignas* _Alignof* _Noreturn* _Atomic is available, but does not work as expectedI plan to provide external tests for every feature andwith that support, we can decide,which feature/test we want to add to tinycc.Regards, Detlef.

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

[Tinycc-devel] commit e5eedc0cd

[Detlef Riekenberg]

Hey grischka.Reducing the search path is a good idea. Thanks for that,but your code does not work for the i386-tcc on x86_64-linux.The path are different, as cross dev packages install files in:lib:/usr/lib/i386-linux-gnu/usr/libinclude:/usr/include/i386-linux-gnu/usr/includecrt:/usr/lib/i386-linux-gnu###and /lib is a link to /usr/libno idea, what  path are used on a musl system.-- Regards Detlef

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

[Tinycc-devel] VLA support is not detected with autoconf

[Detlef Riekenberg]

tcc can't compile the attached VLA check (gcc works)
and configure adds "#define __STDC_NO_VLA__ 1" to config.h

The code was generated using the autoconf macro "AC_C_VARARRAYS".

console output:
tcc -std=c11  vla_conftest.c -c
vla_conftest.c:30: error: constant expression expected


Any ideas, how to fix that?

(Link does not work: n is not available)


--
Bye bye ... Detlef
/* confdefs.h */

/* end confdefs.h.  */

/* Test for VLA support.  This test is partly inspired
  from examples in the C standard.  Use at least two VLA
  functions to detect the GCC 3.4.3 bug described in:
  
https://lists.gnu.org/archive/html/bug-gnulib/2014-08/msg00014.html
  */
   #ifdef __STDC_NO_VLA__
syntax error;
   #else
 extern int n;
 int B[100];
 int fvla (int m, int C[m][m]);

 int
 simple (int count, int all[static count])
 {
   return all[count - 1];
 }

 int
 fvla (int m, int C[m][m])
 {
   typedef int VLA[m][m];
   VLA x;
   int D[m];

   static int (*q)[m] = 

   int (*s)[n] = q;
   return C && [0][0] == [0] && [0] == s[0];
 }
   #endif

int
main (void)
{

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

[Tinycc-devel] Fix for -gdwarf

[Detlef Riekenberg]

tcc -gdwarf did not work as expected.

When tcc was compiled without DWARF as default (--dwarf=5 as example),
then DWARF_VERSION is 0, the -gdwarf command line option did not changed 
s->dwarf
and tcc created stabs debug infos.

I pushed a fix.
Now, tcc does the same as gcc with "-gdwarf":
dwarf-2 on Darwin/Mac OS X and dwarf-5 on other systems

--
Bye bye ... Detlef


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

[Tinycc-devel] Our __has_include implementation needs a fix

[Detlef Riekenberg]

We detect and handle "__has_include" (yeah),
but it's broken (we return always 1)
and we should fix it.

Any ideas?

__has_include was an gcc/clang extension, but it's now a part of C23.
(change accepted in aug/sep 2021)

The support for __has_include is also mentioned in an ISO document:
https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2799.pdf

The document named the compiler as tcc (Tiny C compiler),
probably because there is another compiler with the name "tcc" available
from the tendra project: https://github.com/tendra/tendra/tree/main/tcc


--
Bye bye ... Detlef


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

Re: [Tinycc-devel] Broken commit e460f7dbb216

[Detlef Riekenberg]

Hi grischka.


> Please try to be more precise.

> Also, the "(n > 1) &" part that you added in your one-line patch
>
> -  if (n <= 0 || (n & (n - 1)) != 0)
> +  if (n < 0 || ((n > 1) & ((n & (n - 1)) != 0)))
>
> is just redundant.

Yes, sorry for that.
I pushed a cleanup and check my patches better in the future


> As to the "n < 0 ||" clause by the way. the C-standards seem to say:
>
>"Alignments are represented as values of the type size_t. Valid alignments
> include only fundamental alignments, plus an additional implementation-
> defined set of values, which may be empty.  Every valid alignment value
> shall be a nonnegative integral power of two."
>
> Well, when "size_t" means unsigned, how could it be not "nonnegative"
> then ?!?

we use an int while parsing, so an _Alignas(-1) in a source file
will arrive here.
Using "size_t" for is a bad decision, as it introduce more warnings for:
   type_decl(, , , TYPE_ABSTRACT);
and for
  n = expr_const();

compared to a size_t for n and the casts for the warnings,
the current code with the "n < 0" is better.


I did not updated the failure message to hint, that zero is also
a valid option for _Alignas(), because there is also no hint in the gcc message


> As to your "My local workaround" below (-DTCC_LIBTCC1="\"libtcc1.a\"")
> all I can say is that it does not have any effect in the context of a
> tinycc as it is available in the public repo.
>
> Maybe you do have some local configuration hacks in place that may or
> may not have been disturbed.

You are allowed to follow my hint and try it yourself.
But please without your hack for windows, which reached the public repo:
echo>> ..\config.h #ifdef TCC_TARGET_X86_64
echo>> ..\config.h #define TCC_LIBTCC1 "libtcc1-64.a"
echo>> ..\config.h #else
echo>> ..\config.h #define TCC_LIBTCC1 "libtcc1-32.a"
echo>> ..\config.h #endif

Again, please fix the bug.
The failures from my previous message are still in the public repo.

And to verify with a windows target:
repo.or.cz_tinycc$ x86_64-win32-tcc helloworld.c -o 
helloworld_x86_64-win32-tcc.exe
repo.or.cz_tinycc$ i386-win32-tcc helloworld.c -o helloworld_i386-win32-tcc.exe
repo.or.cz_tinycc$ ls -al helloworld*
-rw-rw-r-- 1 detlef detlef   108 Jun 10 21:38 helloworld.c
-rwxrwxr-x 1 detlef detlef 15960 Aug  4 11:57 helloworld_gcc
-rwxrwxrwx 1 detlef detlef  2048 Aug  4 11:56 helloworld_i386-win32-tcc.exe
-rwxrwxrwx 1 detlef detlef  3072 Aug  4 11:56 helloworld_x86_64-win32-tcc.exe

When using a Windows target, the includes in "win32/include" are used instead.

> > And your patch is incomplete.
> > The cross prefix for libtcc1 is missing with -print-search-dirs

that's also still present.

--
Bye bye ... Detlef



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

[Tinycc-devel] Next failure with autotools: _Static_assert

[Detlef Riekenberg]

With my patch for _Alignas, tcc works for the next two configure tests:
A simple _Static_assert and _Noreturn check.

But then tcc fails, and i have no idea, where to look:
A _Static_assert in a struct.

Any Ideas, how to fix that?

 code from a configure script, generated by GNU autoconf_2.71:

// Check _Static_assert.
struct test_static_assert
{
  int x;
  _Static_assert (sizeof (int) <= sizeof (long int),
  "_Static_assert does not work in struct");
  long int y;
};


--
Bye bye ... Detlef


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

[Tinycc-devel] Tests for _Alignas (new autotools)

[Detlef Riekenberg]

Hi

GNU autotools went more than 20 years forward
from the old C89/c90 compatibility checks to C11 and C99 before C89/C90.

First try is with compiler default settings, next try is with "-std=gnu11".
tcc fail with both, but using CFLAGS="-std=c11"
works for the first check (__STDC_VERSION__)

Next check is _Alignas. tcc is broken, but i commited a fix
The current test is strange. It has a failure message
and only works with tcc.
tcc -m32 and tcc -m64 have the same results as gcc -m64 (1 1 1 1),
but the result with gcc -m32 is different: 1 0 1 1

What should we do?

Attached are a patch for the additional tests to verify my
implementation changes for _Alignas.


--
Bye bye ... Detlef
From edb7f281c4a44654de6984bf35a3e1515865a1c0 Mon Sep 17 00:00:00 2001
From: Detlef Riekenberg 
Date: Thu, 28 Jul 2022 18:39:56 +0200
Subject: [PATCH 1/1] Tests for _Alignas(0), _Alignas(1) and more

Used by newer configure scripts from GNU autotools

--
bye bye, Detlef
---
 tests/tests2/102_alignas.c  | 12 
 tests/tests2/102_alignas.expect |  1 +
 2 files changed, 13 insertions(+)

diff --git a/tests/tests2/102_alignas.c b/tests/tests2/102_alignas.c
index 62d3ed2..bd8dabe 100644
--- a/tests/tests2/102_alignas.c
+++ b/tests/tests2/102_alignas.c
@@ -14,6 +14,13 @@ int16aligned_t i7;
corresponding attribute _does_ apply to type-name, though not in
some clang versions.  */
 int _Alignas(int __attribute__((aligned(16 i8;
+char _Alignas (0) c0;
+char _Alignas (1) c1;
+char _Alignas (2) c2;
+char _Alignas (short) cs;
+char _Alignas (float) cf;
+char _Alignas (0) _Alignas (long) two;
+
 extern int printf(const char*, ...);
 #ifdef _MSC_VER
 #define alignof(x) (int)__alignof(x)
@@ -25,5 +32,10 @@ int main()
   printf("%d %d %d %d\n",
  alignof(i1) == 16, alignof(i4) == alignof(double),
  alignof(i5) == alignof(int) , alignof(i8) == 16);
+  printf("%d %d %d %d %d %d\n",
+ alignof(c0) == 1, alignof(c1) == 1, alignof(c2) == 2 ,
+ alignof(cs) == alignof(short), alignof(cf) == alignof(float),
+ alignof(two) == alignof(long));
+
   return 0;
 }
diff --git a/tests/tests2/102_alignas.expect b/tests/tests2/102_alignas.expect
index b458e07..697ea5d 100644
--- a/tests/tests2/102_alignas.expect
+++ b/tests/tests2/102_alignas.expect
@@ -1,2 +1,3 @@
 102_alignas.c:4: warning: type defaults to int
 1 1 1 1
+1 1 1 1 1 1
--
2.34.1

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

[Tinycc-devel] Broken commit e460f7dbb216

[Detlef Riekenberg]

Hi grischka.

After your commit related to CONFIG_TCC_CROSSPREFIX,
every compiler failed to work on Linux.
I rechecked with a clean checkout.

Broken commit:
https://repo.or.cz/tinycc.git/commitdiff/e460f7dbb2165112bc618816ec15be312b257de2

Message examples:
repo.or.cz_tinycc$ ./tcc helloworld.c -o helloworld_tcc
In file included from helloworld.c:6:
/usr/include/stdio.h:33: error: include file 'stddef.h' not found
repo.or.cz_tinycc$ ./i386-tcc helloworld.c -o helloworld_tcc
tcc: error: file 'crt1.o' not found
tcc: error: file 'crti.o' not found
In file included from helloworld.c:6:
/usr/include/stdio.h:33: error: include file 'stddef.h' not found


My local workaround:
diff --git a/Makefile b/Makefile
index 947f757..6d27eaf 100644
--- a/Makefile
+++ b/Makefile
@@ -175,10 +175,10 @@ DEFINES += $(DEF-$(or $(findstring win,$T),unx))

 ifneq ($(X),)
 ifeq ($(CONFIG_WIN32),yes)
-DEF-win += -DCONFIG_TCC_CROSSPREFIX="\"$X\""
-DEF-unx += -DCONFIG_TCC_CROSSPREFIX="\"lib/$X\""
+DEF-win += -DTCC_LIBTCC1="\"libtcc1.a\"" -DCONFIG_TCC_CROSSPREFIX="\"$X\""
+DEF-unx += -DTCC_LIBTCC1="\"libtcc1.a\"" -DCONFIG_TCC_CROSSPREFIX="\"lib/$X\""
 else
-DEF-all += -DCONFIG_TCC_CROSSPREFIX="\"$X\""
+DEF-all += -DTCC_LIBTCC1="\"libtcc1.a\"" -DCONFIG_TCC_CROSSPREFIX="\"$X\""
 DEF-win += -DCONFIG_TCCDIR="\"$(tccdir)/win32\""
 endif
 endif


And your patch is incomplete.
The cross prefix for libtcc1 is missing with -print-search-dirs


Can you please take a look?

Thanks


--
Bye bye ... Detlef


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

[Tinycc-devel] new tcc release

[Detlef Riekenberg]

The last tcc release is very old, and tcc has received many fixes and new features since then.What are the plans for a new release?I vote for a 0.9.28 rc with the current features, see, what simple fixes are possible and then make a release in the next weeks.(Would help distros to include a recent tcc)Afterwarde prepare for tcc 1.0 later this year.That would make it possible for distros to addtcc 1.0 in there spring/LTS releases.Unfortunately, we missed the 20. anniversary for tcc 1.0(first commit: 27. Oct. 2001),but releasing at the  21. anniversary is still possible.For 1.0, i vote for fixing more bugs and verified C99 support, either excluding Complex math or with optional Complex math (enable during configure, but defaults 'off')tcc already understand some C11 featuresand newer extensions (example: __has_include)but the related implementation is missing or buggy (_Atomic)I would see fixes for C11 things as 'cool, when working', but optional for tcc 1.0.What are you think?-- Regards, Detlef

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

[Tinycc-devel] bug: nolibc.h does not work with tcc

[Detlef Riekenberg]

nolibc.h looks nice and we should support it.What is nolibc.h?a header to replace libc on linux with syscalls.created by Willy Tarreau (linux kernel 2.4 maintainer).Where?a single file version (changed 21.1.2021) is on his homepagehttp://git.1wt.eu/git/nolibc.git  (License: MIT)The included test 'hello.c' works with gcc, but fails with tcc:x86_64: nolibc.h:1479: error: asm constraint 7 ('r') could not be satisfiedi386-tcc:compiles, but the created program produces no outputOther arch fail at the last line of the startup-code(empty asm string)arm64-tcc (at line 996), arm-tcc (at 799) and riscv64-tcc (at 1399)Interesting:x86_64 (line 434) and I386 (line 614) have the same empty asm string at the end of the startup-code, but do not complain.nolibc.h is also in the linux kernel source( tools/include/nolibc/nolibc.h ) (License: LGPL-2.1 OR MIT)(looking forward to be able to build a x86_64-linux-nolibc-tcc)-- Regards...Detlef

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

[Tinycc-devel] Reverted commits

[Detlef Riekenberg]

Yes, that sounds resonable.I will ask here for comments for some patches(in new mails),and only commit the bug fixesRegards ..Detlef--Diese Nachricht wurde von meinem Android Mobiltelefon mit WEB.DE Mail gesendet.

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

[Tinycc-devel] Reverted commits

[Detlef Riekenberg]

Hi List.

My commits from the last 2 month where reverted.

Why?
And why without any comment?


Fixing simple bugs to make tcc more usable for all developer should be our goal.

* Example Bug fixed, but patch reverted:
* CC=tcc configure
This is no longer possible


*Example Bug fixed, but patch reverted:
*CFLAGS includes "-g0"
Now, tcc creates debug infos again and produce much larger object files as gcc 
-O0
Yes, of course, removing "-g0" from the flags is possible.
Please try yourself to send patches for makefiles to work around a tcc bug to 
apache.org
and other projects.

*Example Bug fixed, but patch reverted:
*-Os has to define __OPTIMIZE_SIZE__
glibc header, uclibc-ng header and other code select a different 
implementation, when __OPTIMIZE_SIZE__ is defined

*Example Bug fixed, but patch reverted:
* arm64-tcc helloworld.c -o helloworld
No longer possible.
Startfiles are in /usr/aarch64-linux-gnu/lib
Includes are in /usr/aarch64-linux-gnu/include

I mentioned multiple times, that building tcc with the cross compiler feature 
fails
to build working cross compiler, which can even cross compile on most systems 
"out of the box".
config-extra.mak is not optional for any cross compiler.
"Out of the Box" experience failed.
The tcc pakage from the OS is too old
and provides only i386-tcc and tcc (on x86_64),
but not for arm, arm64 and other targets


--
Bye bye ... Detlef


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

Re: [Tinycc-devel] [Fwd: bug in tcc wi32]

[Detlef Riekenberg]

On Sa, 2010-05-01 at 13:58 +0200, grischka wrote:
 Detlef, please fix.
 
 (Beware, not as suggested below ;))
 
 --- grischka


Opps.
Sorry for that Problems.
I take a look.

-- 
By by ... Detlef




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

[Tinycc-devel] Drop mercurialtcc [TinyCC on Mercurial]

[Detlef Riekenberg]

On Di, 2007-11-13 at 14:04 +0800, KHMan wrote: 
 Hi all,
 
 mercurialtcc has been accepted on ShareSource. The URL is:
 
 http://sharesource.org/project/mercurialtcc/

In the old CVS-Only live of tcc, the inofficial mercurial tree
was created.
We have the git tree now, so I like to drop the old outdated code.

Any objections?


-- 
By by ... Detlef




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

Re: [Tinycc-devel] Need help with hardware i/o

[Detlef Riekenberg]

On Do, 2009-08-20 at 22:04 -0700, live...@hotmail.com wrote:

 I just discovered Tiny C

Welcome, person without a name.

 MS 'QuickC for DOS' had the inp()/outp() 
 functions defined in conio.h to do this.

There is no support for a 16Bit DOS target in tinycc.

 I can't figure out how to do this with TinyC. Since 
 TinyC runs on PC hardware (whether Linux or Windows),
 shouldn't it be able to do i/o commands?

You can access any pointer in memory, when you have the needed
permission,
but the OS is in charge to manage and access all resources.

 I also do direct access to video ram (xB800). Again, with QuickC I do
 this with:
 
 char _huge *vaddr;
   vaddr = (char *)0xB800;
   *vaddr = 'a';
 
 The _huge term makes QuickC use 32-bit pointers instead of 16-bits (to get
 to the video ram).

The video ram is managed by the OS (video driver) while the layout
and the location depend on the disply mode and resolution.

When you want to do use is 16-Bit DOS Text Mode related code.
That won't work on WIndows or Linux.

For 16-Bit DOS, you can use the compilers at http://www.openwatcom.org 
(Open Source) or http://www.digitalmars.com and even old Borland Compilers 
are free to use these days, but the old versions are no longer under
development: http://www.borland.com has a museum somewhere.

 Question: does TinyC use 32-bit pointers? Always?

32-Bit ans 64-Bit are possible with tinycc

 My program runs without a roblem when compiled with QuickC, 
 so I know what I'm doing can be done.

That can be done only with 16-Bit DOS. See the mentioned compiler above.

A 16-Bit DOS target might be a funny project, but not really useful
these days.

-- 
 
By by ... Detlef



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

tinycc.git (was: Re: [Tinycc-devel] Re: global 64-bit variables initialization)

[Detlef Riekenberg]

On Mi, 2008-11-26 at 16:08 +, Joshua Phillips wrote:
 Whatever happened to mercurialtcc on sharesource?
I never used hg before.
A while ago, I joined that tree and tried to sync patches from CVS,
but due to real life, i'm unable to sync it to a usable sate.
I suggest: rm -f

  We are since recently working with GIT at
  http://repo.or.cz/w/tinycc.git
  Daniel has his own fork at
  http://repo.or.cz/w/tinycc/daniel.git

I really prefer git.

Some changes, which i still want to have: 
- seperate path for lib and includes, depending on the target
  (different api between linux and win32.
   configure scripts fail over header for both os in one dir)
  - /usr/lib/tcc/stdc/include
  - /usr/lib/tcc/win32/include
  - /usr/lib/tcc/posix/include
  - /usr/lib/tcc/???/include
  Same for libs

- startfiles for all supported platforms

- use a real prefix, to make a tcc crosscompiler work with the autotools

- assembler and linker is present, so a frontend (commandline handling)
  for as and ld (with optional crosscompiler-prefix) should be possible
  without big problems

- out of tree builds did not work before 0.9.24.
  I did not test current git

- cleanup the build process for posix and win32
  (configure / Makefiles / the batch file)

- coff for win32. 
  (when possible to share code with the other coff output mode)


As example, how other compiler do this:
PCC ( http://pcc.ludd.ltu.se ) has subdirectories for:
- the target arch (codegen) and
- the target os (compiler configuration with an os dependant header)
  (startfiles, dyn-loader, ...)

http://pcc.ludd.ltu.se/fisheye/browse/pcc/pcc


-- 
 
By by ... Detlef




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

Re: [Tinycc-devel] Release Candidate - please test

[Detlef Riekenberg]

On Sa, 2008-03-08 at 22:52 +0100, grischka wrote:
 Here are the file that I propose for release:

I did not test the files yet, but I think that a regular release is much
better.

IMHO, the new tools should be usable in both environments
(win32 and unix) to allow tcc as drop-in for gcc and mingw.

Bugs, that forbid cross-compile are the shared include directory,
(On linux, the win32 includes must not be found) and the missing
startup-files for unix (We use the files from gcc)

More issues exist, but they should wait for tcc-0.9.25.
(AC_PATH_XTRA as example: the autotools check for X does not work )


I still plan to merge patches from tcc/cvs to tcc/hg, before i fix
outstanding issues, but the current patch-sets are hard to follow:
- make small and individual commits.
- send usable commit-logs on tcc-devel.


My vote to release tcc-1.0.0, when wine (and / or the linux-kernel)
can be compiled and work.



Thanks.

-- 
 
By by ... Detlef




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

Re: [Tinycc-devel] Release Candidate - please test

[Detlef Riekenberg]

On So, 2008-03-09 at 21:26 +0300, Alexander Gladysh wrote:
 -#if !defined(__FreeBSD__)  !defined(__DragonFly__)  !
 defined(__OpenBSD__)
 +#if !defined(__FreeBSD__)  !defined(__DragonFly__) \
 +  !defined(__OpenBSD__)  !defined(__APPLE__)
  #include malloc.h
  #endif

We really should test such things in a configure script.

Together with a simple script to convert a
configure.ac to a configure, we are done.

For uncommon systems, autotools can be a full-featured fallback.


-- 
 
By by ... Detlef




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

Re: [Tinycc-devel] Worm virus

[Detlef Riekenberg]

On Mo, 2008-01-21 at 14:34 -0800, Gary Dumer wrote:
 All of the EXEs were created with TCC from CVS for WindowsXP.
  
 Gary Dumer wrote:   AVG antivirus is detecting a WORM virus in all the EXEs 
 on my WindowsXP.   I'm using a recent version of TCC.Ummm... what does 
 it have to do with tcc?--   Cheers,  Kein-Hong Man (esq.)  Kuala Lumpur, 
 Malaysia

TCC is clean here.

Remember, that it is a common behavior for an active maleware,
that the malware-code is spread, when an executable is created on the
Disk.

Clean your complete system and everything should word as expected.

You can upload files to an online malware scanner.
(Example: http://virusscan.jotti.org/ )


-- 
 
By by ... Detlef




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

[Tinycc-devel] PATCH for CVS: remove unneeded swap in gen_opic()

[Detlef Riekenberg]

no swap needed (we do not use c1 or l1 below)


-- 
 
By by ... Detlef

Index: tcc.c
===
RCS file: /sources/tinycc/tinycc/tcc.c,v
retrieving revision 1.193
diff -u -r1.193 tcc.c
--- tcc.c	19 Dec 2007 17:36:43 -	1.193
+++ tcc.c	13 Jan 2008 14:02:20 -
@@ -5464,9 +5464,9 @@
independent opt */
 void gen_opic(int op)
 {
-int c1, c2, t1, t2, n, c;
+int c1, c2, t1, t2, n;
 SValue *v1, *v2;
-long long l1, l2, l;
+long long l1, l2;
 typedef unsigned long long U;
 
 v1 = vtop - 1;
@@ -5533,8 +5533,9 @@
 if (c1  (op == '+' || op == '' || op == '^' || 
op == '|' || op == '*')) {
 vswap();
-c = c1, c1 = c2, c2 = c;
-l = l1, l1 = l2, l2 = l;
+/* no swap needed (we do not use c1 or l1 below) */
+c2 = c1;
+l2 = l1;
 }
 /* Filter out NOP operations like x*1, x-0, x-1... */
 if (c2  (((op == '*' || op == '/' || op == TOK_UDIV || 
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel

__STDC_VERSION__ is needed (Re: [Tinycc-devel] CVS Sync - The Rest)

[Detlef Riekenberg]

On So, 2007-12-16 at 20:02 +0100, grischka wrote:

 I will drop those labeled 
 [N] will not apply 
 unless someone can tell a good reason why we would need one.

 [N] 477  RL_tcc_defines_stdc_ver (c99)
 http://hg.sharesource.org/mercurialtcc/rev/1e81d5b65878

every source, that use the typedefs for int64_t and u_int64_t
from sys/types.h does not work.

glibc (2.3) enable 64 bit types for gcc  2.7 and other compiler:
#if defined __GNUC__ \
|| (defined __PGI  defined __i386__ ) \
|| (defined __INTEL_COMPILER  \
   (defined __i386__ || defined __ia64__)) \
|| (defined __STDC_VERSION__  __STDC_VERSION__ = 199901L)
# define __GLIBC_HAVE_LONG_LONG 1
#endif

glibc use macros with __attribute__ ((__mode__ (MODE)))
for gcc 2.7 and above.

The Patch should work for many packages, when using glibc.
(packages that use uclibc still need __GNUC__)


-- 
 
By by ... Detlef




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

[Tinycc-devel] mercurialtcc updated: Sync from cvs to hg (part 1)

[Detlef Riekenberg]

As a step to update mercurialtcc, here is an Overview of recent CVS
commits by grischka:

1) 30.Oct.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-10/msg00076.html
Fix 'invalid relocation entry' problem on ubuntu - from Bernhard Fischer
(from hg)

2) 14.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00045.html
Import some changesets from Rob Landley's fork (part 1)
(from hg)

3) 21.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00065.html
Import more changesets from Rob Landley's fork (part 2)
(from hg with additional changes:
http://hg.sharesource.org/mercurialtcc/rev/1cdd9b80d04b )

4) 21.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00066.html
Import more changesets from Rob Landley's fork (part 2)
(additional change is alloca for win32/include/stddef.h:
http://hg.sharesource.org/mercurialtcc/rev/d07ba9d538e3 )


5) 23.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00075.html
New files: alloca86.S alloca86-bt.S
(mercurialtcc has a different implementation)

Is it required for windows and linux/unix to access every Page
(grow the stack-limit and move the GUARD_PAGE)?

--
Commits not checked yet:

6) 25.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00095.html
Some in-between fixes:
- Hanging tcc -E (from hg)
- Crashes with global 'int g_i = 1LL;'
- include  lib search paths on win32
- Reverted case label optimization

(The commit-mssage mentioned only Changelog)


7) 25.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00096.html
Some in-between fixes:
- Added quick build batch file for mingw

8) 04.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg6.html
Import 409,410: ARM EABI by Daniel Glöckner


9) 09.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00030.html
tiny_impdef.c - converted to LF line-endings (and slight cleanup)


10) 13.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00033.html
Use _WIN32 for a windows hosted tcc and define it for the PE target.


11) 13.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00034.html
Disable singnedness warnings with newer gcc


12) 16.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00039.html
Import changesets (part 4) 428,457,460,467: defines for openbsd etc


13) 17.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00041.html
Handle backslashes within #include, #error, #warning


14) 19.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00045.html
Switch to newer tccpe.c (includes support for resources)

-
Overview for the sync from hg to cvs:
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00040.html


-- 
 
By by ... Detlef




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

[Tinycc-devel] mercurialtcc updated: Sync from cvs to hg (part 1)

[Detlef Riekenberg]

As a step to sync mercurialtcc ( http://hg.sharesource.org/mercurialtcc ),
here is an Overview of recent CVS commits by grischka:

1) 30.Oct.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-10/msg00076.html
Fix 'invalid relocation entry' problem on ubuntu - from Bernhard Fischer
(from hg)

2) 14.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00045.html
Import some changesets from Rob Landley's fork (part 1)
(from hg)

3) 21.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00065.html
Import more changesets from Rob Landley's fork (part 2)
(from hg with additional changes:
http://hg.sharesource.org/mercurialtcc/rev/1cdd9b80d04b )

4) 21.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00066.html
Import more changesets from Rob Landley's fork (part 2)
(additional change is alloca for win32/include/stddef.h:
http://hg.sharesource.org/mercurialtcc/rev/d07ba9d538e3 )


5) 23.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00075.html
New files: alloca86.S alloca86-bt.S
(mercurialtcc has a different implementation)

Is it required for windows and linux/unix to access every Page
(grow the stack-limit and move the GUARD_PAGE)?

--
Commits not checked yet:

6) 25.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00095.html
Some in-between fixes:
- Hanging tcc -E (from hg)
- Crashes with global 'int g_i = 1LL;'
- include  lib search paths on win32
- Reverted case label optimization

(The commit-mssage mentioned only Changelog)


7) 25.Nov.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-11/msg00096.html
Some in-between fixes:
- Added quick build batch file for mingw

8) 04.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg6.html
Import 409,410: ARM EABI by Daniel Glöckner


9) 09.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00030.html
tiny_impdef.c - converted to LF line-endings (and slight cleanup)


10) 13.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00033.html
Use _WIN32 for a windows hosted tcc and define it for the PE target.


11) 13.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00034.html
Disable singnedness warnings with newer gcc


12) 16.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00039.html
Import changesets (part 4) 428,457,460,467: defines for openbsd etc


13) 17.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00041.html
Handle backslashes within #include, #error, #warning


14) 19.Dec.2007
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00045.html
Switch to newer tccpe.c (includes support for resources)

-
Overview for the sync from hg to cvs:
http://lists.nongnu.org/archive/html/tinycc-devel/2007-12/msg00040.html


-- 
 
By by ... Detlef




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

[Tinycc-devel] hg: partial disable commit 496 (check for duplicate parameter)

[Detlef Riekenberg]

This patch deactivates the detection of duplicate parameter and
mercurialtcc can compile merucialtcc again.

Does anyone has an idea for a real fix?

Any comments about revert the complete commit?


-- 
 
By by ... Detlef

diff -r 062087f616c1 tcc.c
--- a/tcc.c	Sun Dec 02 20:00:05 2007 +0800
+++ b/tcc.c	Tue Dec 18 21:22:44 2007 +0100
@@ -6136,9 +6136,13 @@ static void parse_function_parameters(CT
 next();
 }
 convert_parameter_type(pt);
+#if 0
+/* XXX: a false positive is sometimes reported here*/
 if(check_field(first, n | SYM_FIELD))
 error(redefinition of parameter '%s',
   get_tok_str(n, NULL));
+#endif
+
 s = sym_push(n | SYM_FIELD, pt, 0, 0);
 *plast = s;
 plast = s-next;
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [BUNDLE] Eliminate many bogus warnings produced during compilation of tcc by gcc

[Detlef Riekenberg]

On Do, 2007-11-29 at 09:19 +, Joshua Phillips wrote:
 Once they go into http://hg.sharesource.org/mercurialtcc/, you can get
 it from there. 

I downloaded the mercurialtcc 2 days ago, but the above commit was not
visible in the web-interface and hg log is broken on Ubuntu Dapper:
  ...
  File /usr/lib/python2.4/site-packages/mercurial/commands.py, line
326, in show_changeset
t, tz = changes[2].split(' ')


It works now with the latest stable hg.
The new hg version has also much more features.

 Otherwise, I'll have to post two copies of every change

I want to see the patch before apply to avoid conflicts with my
local changes.


-- 
 
By by ... Detlef




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

Re: [Tinycc-devel] Current cvs does not build (_WIN32 missing) Here is a fix.

[Detlef Riekenberg]

On Do, 2007-11-29 at 14:04 +0800, KHMan wrote:
  WIN32 is not defined on all Windows Compilers (PellesC as example),
  so i decided to use _WIN32, as documented on msdn:
  ( http://msdn2.microsoft.com/en-us/library/b0084kay(VS.80).aspx )
 
 I'll await comments. SDL does it like this:
 
 #if defined(WIN32) || defined(_WIN32)
 #undef __WIN32__
 #define __WIN32__ 1
 #endif

 Anyone wants to contribute a definitive version for tcc? :-)

WIN32 is no option (to easy to get a duplicate; wrong namespace)
__WIN32__ is not documented on MSDN
_WIN32 is 3 byte smaller as __WIN32__

I prefer _WIN32


 The normalize_slashes() bit is not in the hg repository yet, so
 I'll wait for grischka to finish pushing from hg to cvs before
 bugging him about moving the necessary bits and pieces from cvs to hg.

My Makefile patch re-enabled out of tree builds and build all files
(libs / apps ) for all targets, but need an update
(out of sync, because of the different directories in tcc-hg)


Which dev-tree is the expected base for patches
(cvs or mercurialtcc)?



-- 
 
By by ... Detlef




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

[Tinycc-devel] Current cvs does not build (_WIN32 missing) Here is a fix.

[Detlef Riekenberg]

A current commit added normalize_slashes(),
but this call in tcc_open() was not protected with _WIN32

WIN32 is not defined on all Windows Compilers (PellesC as example),
so i decided to use _WIN32, as documented on msdn:
( http://msdn2.microsoft.com/en-us/library/b0084kay(VS.80).aspx )




-- 
 
By by ... Detlef

--- cvs/tcc.c   2007-11-28 15:17:16.0 +0100
+++ src/tcc.c   2007-11-28 22:38:08.0 +0100
@@ -38,11 +38,11 @@
 #include fcntl.h
 #include setjmp.h
 #include time.h
-#ifdef WIN32
+#ifdef _WIN32
 #include sys/timeb.h
 // #include windows.h
 #endif
-#ifndef WIN32
+#ifndef _WIN32
 #include sys/time.h
 #include sys/ucontext.h
 #include sys/mman.h
@@ -86,12 +86,12 @@
 #define TCC_TARGET_I386
 #endif
 
-#if !defined(WIN32)  !defined(TCC_UCLIBC)  !defined(TCC_TARGET_ARM)  \
+#if !defined(_WIN32)  !defined(TCC_UCLIBC)  !defined(TCC_TARGET_ARM)  \
 !defined(TCC_TARGET_C67)
 #define CONFIG_TCC_BCHECK /* enable bound checking code */
 #endif
 
-#if defined(WIN32)  !defined(TCC_TARGET_PE)
+#if defined(_WIN32)  !defined(TCC_TARGET_PE)
 #define CONFIG_TCC_STATIC
 #endif
 
@@ -720,7 +720,7 @@
 
 #define TOK_UIDENT TOK_DEFINE
 
-#ifdef WIN32
+#ifdef _WIN32
 int __stdcall GetModuleFileNameA(void *, char *, int);
 void *__stdcall GetProcAddress(void *, const char *);
 void *__stdcall GetModuleHandleA(const char *);
@@ -965,7 +965,7 @@
 return NULL;
 }
 
-#elif !defined(WIN32)
+#elif !defined(_WIN32)
 
 #include dlfcn.h
 
@@ -1033,7 +1033,7 @@
 return 1;
 }
 
-#ifdef WIN32
+#ifdef _WIN32
 char *normalize_slashes(char *path)
 {
 char *p;
@@ -1885,7 +1885,9 @@
 bf-buf_end = bf-buffer;
 bf-buffer[0] = CH_EOB; /* put eob symbol */
 pstrcpy(bf-filename, sizeof(bf-filename), filename);
+#ifdef _WIN32
 normalize_slashes(bf-filename);
+#endif
 bf-line_num = 1;
 bf-ifndef_macro = 0;
 bf-ifdef_stack_ptr = s1-ifdef_stack_ptr;
@@ -9665,7 +9667,7 @@
 fprintf(stderr, \n);
 }
 
-#if !defined(WIN32)  !defined(CONFIG_TCCBOOT)
+#if !defined(_WIN32)  !defined(CONFIG_TCCBOOT)
 
 #ifdef __i386__
 
@@ -9830,7 +9832,7 @@
 s = s1-sections[i];
 if ((s-sh_flags  (SHF_ALLOC | SHF_EXECINSTR)) == 
 (SHF_ALLOC | SHF_EXECINSTR)) {
-#ifdef WIN32
+#ifdef _WIN32
 {
 unsigned long old_protect;
 VirtualProtect(s-data, s-data_offset,
@@ -9862,7 +9864,7 @@
 prog_main = tcc_get_symbol_err(s1, main);
 
 if (do_debug) {
-#if defined(WIN32) || defined(CONFIG_TCCBOOT)
+#if defined(_WIN32) || defined(CONFIG_TCCBOOT)
 error(debug mode currently not available for Windows);
 #else
 struct sigaction sigact;
@@ -10402,7 +10404,7 @@
 char *p = strchr(name, 0);
 while (p  name
  p[-1] != '/'
-#ifdef WIN32
+#ifdef _WIN32
  p[-1] != '\\'
 #endif
 )
@@ -10414,7 +10416,7 @@
 
 static int64_t getclock_us(void)
 {
-#ifdef WIN32
+#ifdef _WIN32
 struct _timeb tb;
 _ftime(tb);
 return (tb.time * 1000LL + tb.millitm) * 1000LL;
@@ -10790,7 +10792,7 @@
 char objfilename[1024];
 int64_t start_time = 0;
 
-#ifdef WIN32
+#ifdef _WIN32
 tcc_lib_path = w32_tcc_lib_path();
 #endif
 
--- cvs/tccpe.c 2005-06-17 23:31:04.0 +0200
+++ src/tccpe.c 2007-11-28 17:30:20.0 +0100
@@ -397,7 +397,7 @@
 return sym_index;
 }
 
-#ifdef WIN32
+#ifdef _WIN32
 ST void **pe_imp;
 ST int nb_pe_imp;
 
--- cvs/elf.h   2005-04-17 15:15:05.0 +0200
+++ src/elf.h   2007-11-28 17:28:34.0 +0100
@@ -21,7 +21,7 @@
 #ifndef _ELF_H
 #define_ELF_H 1
 
-#ifndef WIN32
+#ifndef _WIN32
 #include inttypes.h
 #else
 #ifndef __int8_t_defined
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [BUNDLE] Eliminate many bogus warnings produced during compilation of tcc by gcc

[Detlef Riekenberg]

On Di, 2007-11-27 at 17:33 +, Joshua Phillips wrote:
 Patch by David Wheeler; I've committed it to the incoming branch.
 (unpack using hg unbundle ...)


Can you please post patches to the List in a human readable format
( == text only)?

Thanks.


-- 
 
By by ... Detlef




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

[Tinycc-devel] cvs does not compile: (Import more changesets from Rob Landley's fork - part 2 )

[Detlef Riekenberg]

On Mi, 2007-11-21 at 17:16 +, grischka wrote:
 CVSROOT:  /sources/tinycc
 Module name:  tinycc
 Changes by:   grischka grischka 07/11/21 17:16:32
 
 Modified files:
   .  : Changelog Makefile stddef.h tcc.c tccasm.c 
tccelf.c tcctok.h 
   win32/include  : _mingw.h stdarg.h 
 
 Log message:
   Import more changesets from Rob Landley's fork (part 2)
 
 CVSWeb URLs:
 http://cvs.savannah.gnu.org/viewcvs/tinycc/Changelog?cvsroot=tinyccr1=1.24r2=1.25
 http://cvs.savannah.gnu.org/viewcvs/tinycc/Makefile?cvsroot=tinyccr1=1.39r2=1.40


You added alloca86.o and alloca86-bt.o to the Makefile,
but the sourcefiles and the build rules are missing.



-- 
 
By by ... Detlef




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