Re: [Tinycc-devel] Where do I get pthread.h?

[ian]

First of all : Hello.

I really rarely answer (when I unexpectedly could), BUT :

with tcc, this (test.c)

#include 
#include 

int main(void) {
  printf("%d\n", PTHREAD_PRIO_NONE);
  return 0;
}

|compiles and ouputs :|

|ian@KsyNET-0:~$ tcc -run test.c
0
ian@KsyNET-0:~$
|

|Furthermore, I really don't catch the concept of "|comes with GCC by 
default", since pthread.h is a unix default — and what's the point of "I 
thought that TCC was supposed to be GCC compatible" ??
The main aim of tiny c is to be a very fast and reliable C compiler. 
Whenever some flags are compatible with the GCC ones, it is only for 
convenience (in my opinion). By the way, GCC itself uses some flags, 
such as -c or -o, ONLY to be compatible with the good old 'cc' and its 
legacy...


Finally, I think that you should start searching in your include dir...

Regards,

ian

|
|

Le 07/02/2024 à 05:25, Videogamer555 a écrit :
I was trying to compile a program that requires pthread.h (which is a 
header file that comes with GCC by default, and I thought that TCC was 
supposed to be GCC compatible) but TCC is missing pthread.h 
unfortunately. So I can't compile the program who's source code I 
downloaded, because its source code doesn't have pthread.h and instead 
expects the compiler to already have this file. Please ship TCC with 
pthread.h from now on. For now though, please tell me what the easiest 
way to get a copy of that file is.


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

--
-- İȃɲ ƝᵋᵃʳᶩỾ
-- *menea...@gmail.com*
-- Développeur compulsif



OpenPGP_0xF9ADC2DB1DFA90FB.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] initializer element is not constant for float comparison

[ian]

Hi you all

IMHO, since static initialization must be done with litterals, the 
expression (-1.0 <0) must be evaluated, hence should fail.

AFAIK it's even done (in that case) before main is called.
Seems to me like a preprocessing stuff.

--ian

Le 21/05/2023 à 23:27, Fred van Kempen via Tinycc-devel a écrit :
> When initializing static variables with the result of float 
comparisons, tcc errors out. This works fine on clang without warning, 
therefore I
> assume this is a bug. The expression -1.0 < 0 should always evaluate 
to 1, no?


Since you are taking the result of a numeric expression, which is 
auto-casted to 'int' type, yes, this should work.


In my opinion, "tiz a bugg!" :)

--Fred


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

--
İȃɲ ƝᵋᵃʳᶩỾ
--*menea...@gmail.com*
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Implementation of '--' argument

[ian]

Hi all.

Honestly ? When I read "-- option to tcc", I laughed at lot !

I consider this particularly irrelevant, and Grishka's comment is right
("For example, not to support compilation of files such as -c.c is not a 
problem as long as we assume that such files do not exist.")


Considering other cases, I just tried a very simple test case :
#!/usr/bin/env -S tcc inc.o -run
#include 
#include "inc.h"
int main(int argc, const char* argv[]) {
  for (int i=0;iFor example, not to support compilation of files such as -c.c is 

--
İȃɲ ƝᵋᵃʳᶩỾ
--*menea...@gmail.com*
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] new tcc release

[ian]

Hi there,

I also vote *YES*.


Regards.
Le 08/07/2022 à 16:17, Antonio Prates a écrit :

Cool


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

--
İȃɲ ƝᵋᵃʳᶩỾ
--*menea...@gmail.com*
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Can a biggener (and idiot) like me read and understand TCC's backend so I can create my own frontend with it?

[ian]

Hi

One thing or the other :

- you wanna learn asm or algorithmics, and it's not the best place; but
you obviously need to have to know them a "few",

- or, you already know how to code something in ASM, and then the
suggested book about how to make an interpreter is the good starting
point for you.

Rgds

Le 29/01/2022 à 10:08, rempas via Tinycc-devel a écrit :
> 29 Ιαν 2022, 03:20 Από s...@conman.org:
>
>> It was thus said that the Great rempas via Tinycc-devel once stated:
>>
 I would advice you to start with this 
 https://craftinginterpreters.com/contents.html first.

 The rest will follow before you know it.
>>> Thanks! However, I don't understand how this will help me. I mean, I don't
>>> even want to create an intepreter to begin with. So this has nothing to do
>>> with what I want to make. Unless you are referring to the frontend so in
>>> this case, It will probably be a good idea to read this book. Or maybe I
>>> should make an intepreter in the end? Hm
>>>
>> It's interpreters all the way down (what do you think CPUs do with machine
>> code?  They interpret it).  Also, if you have parsed code into a form you
>> can interpret, you have enough information to generate machine code.
>>
>>  -spc
>>
>> ___
>> Tinycc-devel mailing list
>> Tinycc-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
> I don't know if I'm that stupid but I really don't understand. I know that 
> the CPU interprets the instructions but an interpreter will use a programming 
> language to interpret. For example, the following statement:
>
> `println("Hello from my lang: {}", "BestLang")`
>
> will be translated to (suppose the interpreted is written in C) and then be 
> executed:
>
> `printf("Hello from my lang: %s", "BestLang);`
>
> So how is this going to teach my assembly and how the instructions are 
> represented in binary? The book specifically says that it won't work with 
> teaching assembly. The interpreted is a binary that takes source code and 
> executes it. It doesn't create a binary. So I really don't understand what's 
> going on here...
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- sibian0...@gmail.com
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs

[ian]

Hi to all, and *happy new year*.

AFAIK neither -NaN nor +NaN have sense (how to put a sign at a 'not a
number' ).

So, d=-d is a non-sense too.

For instance, in my own language NaN have no sign, but on the other hand
I use -Inf and +Inf :

? (/ -1 0)
-Inf.
? (/ 1 0)
+Inf.
? (* 0 (/ -1 0))
NaN


It seems to me that using a sign bit on NaN is a design error.

Regards to all, and best wishes.

*ian*

Le 05/01/2021 à 10:27, Vincent Lefevre a écrit :
> On 2021-01-04 04:59:28 +0100, Michael Matz wrote:
>> Hello,
>>
>> On Mon, 4 Jan 2021, Vincent Lefevre wrote:
>>
>>>> -
>>>> #include 
>>>> #include 
>>>> #include 
>>>>
>>>> int main(int argc, char **argv)
>>>> {
>>>>double d = strtod("-nan", NULL);
>>>>d = -d;
>>>>printf("%g, signbit(d) = %d\n", d, signbit(d));
>>>>return 0;
>>>> }
>>>> -
>>>>
>>>> Results:
>>>>
>>>>$ gcc foo.c -o foo && ./foo
>>>>-nan, signbit(d) = 1
>>>>
>>>>$ tcc foo.c -o foo2 && ./foo2
>>>>nan, signbit(d) = 0
>>>>
>>>> I get the same results as gcc with clang and pcc. tcc is the outlier.
>>> AFAIK, the status of the sign bit of a NaN is unspecified, except
>>> for some particular functions, but not strtod. So I don't see a
>>> bug in tcc.
>>>
>>> Note: for GCC, there's an inconsistency between your testcase
>>> and the result.
>> Yeah, I think that's merely a typo in Arnolds email.  The inconsistency is
>> there, applying unary '-' to a NaN doesn't change the sign of it in TCC.
> But my point is that with the above testcase, you cannot know whether
> the difference between gcc and tcc comes from strtod (which would be
> valid, as strtod doesn't specify the sign or NaN) or the "d = -d;"
> (which would be invalid). A printf should have been added between
> the strtod and the "d = -d;" to be sure.
>
-- 
-- sibian0...@gmail.com
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] A possible bug in TCC

[ian]

Since I had not enough permissions to install TCC

Le 13/12/2020 à 21:35, Anton Shepelev a écrit :
> Since I had not
> enough permissions to install TCC
-- 
-- sibian0...@gmail.com
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Reformatting Tinycc source code

[ian]

Hi to all of you.

Just to say, I used to reformat about 30'000 lines with simple /sed/
commands (changing my old habit of tabulations to 2 or 4 spaces).

It's quite simple, the only thing that matter is to hamonize the habits,
everything else is superfluous.

Regards

Le 05/12/2020 à 11:11, Tyge Løvset a écrit :
> Hi Antonio,
> Yes, I have also experienced that formatters can be "too eager at
> their job". I haven't really tried clang-format, but I will check it
> out just to compare with astyle, which has worked well for me over the
> years. I don't think i will need your scripts because I don't want to
> use much time on it, but thank you anyways.
>
> Best regards,
> Tyge
>
> On Fri, 4 Dec 2020 at 02:46, Antonio Prates  > wrote:
>
> Hello Tyge,
>
> While I was forking TCC on to the sugar project, I must say, for
> the record, I tried to pass all .C and .H sources through clang
> code formatter, with all kinds of different defaults and options,
> and to my surprise all of them broke the build !?! hehe
>
> I literally spent hours playing with that. Don't ask me why a code
> formatter breaks code. It should not happen, yet, it happens with
> TCC. I tried to fix the compile errors, but each fix would force
> even more changes. So I never completed the goal and finally gave
> up on it.
>
> My original plan for patching sugar sources was to run same script
> over TCC updates on my local to make the changes diff from
> formatted to formatted, witch should have been easy. In the end I
> had to go back and live with an unevenly formatted codebase, where
> each file will have it's own way... it's a detachment exercise for
> me, as any unformatted bracket sounds like a very annoying mistake
> to me :P
>
> But if you want I can search for the script that would format it
> all, and you can try playing with it a bit more, to see if you can
> figure out why it does not build.
>
> Best regards,
> Antonio
>
>
> On Dec 3 2020, at 4:30 am, Steffen Nurpmeso  > wrote:
>
> Tyge Løvset wrote in
>  
> >:
> |No problem, I should have read the CodingStyle file.
> @grischka, you are
> |right, tabs are consistently 8 indents.
> |It is also true that it is not blame-friendly, apart from
> blaming those who
> |aren't following the style guides, of course ;)
> |
> ||Doesn't really look much different to me except that it
> seems to create
> ||10233 changes which isn't really the git-blame friendly way
> of making
> ||not much difference ;)
> |
> |I guess I just regard this a little more important than you
> guys, I know
> |some projects are even forcing all code through a formatter,
> |which is too much imo, so it comes down to preference in the end.
>
> Mind you, FreeBSD seems to be about to use the clang formatter in
> a git commit or so hook in a not too distant future, it arose on
> the ML several times now.
> In hindsight of mixed codebases like groff or tcc however, in
> a world of plastics and artificiality, why not a godemiche.
>
> --steffen
> |
> |Der Kragenbaer, The moon bear,
> |der holt sich munter he cheerfully and one by one
> |einen nach dem anderen runter wa.ks himself off
> |(By Robert Gernhardt)
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org 
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
> Sent from Mailspring___
> 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
-- 
-- sibian0...@gmail.com
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Error with today's patches

[ian]

Hi back to all.

I read carefully all of the mailing-list, but I hava add a quick
comment, right now.

The main aim of a CVS is to able people to test patches, and concurrent
versions.

The target should be to create a fork, and, tests achieved, to merge
them to the mob.

Every one HAVE to test their modifications upon EVERY structures (OSes,
procs, byte lengthS, and so on) before submitting them, or to leave them
in the fork branch before merging

It's a shame that everybody could come and propose modifications, even
push them on mob, without a complete review

Really, I do believe that Christian, while working on his own language,
is right in many ways You should read him with attention.


Take care all,  and sorry for this.

ian


Le 09/09/2020 à 11:44, Christian Jullien a écrit :
>
> macOS:
>
>  
>
> …
>
> compiling tcc.c 10 times
>
> (827 ms)
>
>  test3 
>
> tcc: error: undefined symbol '___va_arg'
>
> tcc: error: undefined symbol '_alloca'
>
> make[2]: *** [test3] Error 255
>
>  memtest 
>
>  
>
> RPi:
>
> running fib in threads
>
>   1 8 144 5 10946 21 6765 89 55 34 3 377 610 233 987 2 13 4181 2584 1597
>
> (35 ms)
>
> running tcc.c in threads to run fib
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idiv'
>
> tcc: error: undefined symbol '__aeabi_uldivmod'
>
> tcc: error: undefined symbol '__aeabi_llsl'
>
> tcc: error: undefined symbol '__aeabi_llsr'
>
> tcc: error: undefined symbol '__aeabi_ul2d'
>
> tcc: error: undefined symbol '__aeabi_d2lz'
>
> tcc: error: undefined symbol '__aeabi_uidivmod'
>
> tcc: error: undefined symbol '__clear_cache'
>
> tcc: error: undefined symbol '__aeabi_uidiv'
>
> tcc: error: undefined symbol '__aeabi_idivmod'
>
> tcc: error: undefined symbol '__aeabi_idiv'
>
> tcc: error: undefined symbol '__aeabi_uldivmod'
>
> tcc: error: undefined symbol '__aeabi_llsl'
>
> tcc: error: undefined symbol '__aeabi_llsr'
>
> tcc: error: undefined symbol '__aeabi_ul2d'
>
> …
>
>  
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- sibian0...@gmail.com
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after cleanup

[ian]

Hi Christian,

You're right, obviously.

The point were only "a mailing-list ain't a chat".

But, yes, obviously again, Avi did a great job !!

Kind regards.

ian

Le 11/07/2020 à 08:01, Christian Jullien a écrit :
>
> Hi Ian,
>
> Sorry for the inconvenience.
>
>  
>
> We are talking to tinycc-devel which … hum? … is for devel!
>
> As macos port is new it seems natural to have more (devel) emails than
> before.
>
> Avih did a very good job chasing issues with different ./configure
> options. Thanks again Avi.
>
> This makes macos more robust and compatible with Linux behavior.
>
>  
>
> If I talk privately to other contributors (something I do sometime),
> we may lose useful advices from other persons knowing macos very well.
>
>  
>
> I’ll be glad to follow what maintainers will ask me to do on
> tiny-devel list.
>
>  
>
> Have a nice day.
>
>  
>
>  
>
> *From:*ian [mailto:sibian0...@gmail.com]
> *Sent:* Saturday, July 11, 2020 07:17
> *To:* tinycc-devel@nongnu.org; jull...@eligis.com
> *Cc:* avih
> *Subject:* Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works
> after cleanup
>
>  
>
> Hi.
>
> Please consider not  fucking everybody's mailing-list.
>
> I ain't a  chat hu ?
>
> But FYI your  contribution is welcomed, many thanks.
>
>  
>
> ian
>
>  
>
> Le 09/07/2020 à 23:16, avih via Tinycc-devel a écrit :
>
>
> I've pushed a fix to mob to support arbitrary libdir (c69290fb).
>
> The relative path is now used during `make test', while the fixed
> libdir is used after install.
>
> On Thursday, July 9, 2020, 09:12:06 PM GMT+3, avih via
> Tinycc-devel 
> <mailto:tinycc-devel@nongnu.org> wrote:
>
>  
>
>  
>
> Note to self: Make sure to double check before posting.
>
> Turns out ./dist/lib/ remained from the previous install, which I
> didn't delete
> before testing with --libdir=$(pwd)/dist/mylibs.
>
> Indeed, it only creates ./dist/mylibs, and indeed it fails to find
> the dylib
> when running ./dist/bin/tcc, (make test still works).
>
> On Thursday, July 9, 2020, 09:02:24 PM GMT+3, avih
>  <mailto:avih...@yahoo.com> wrote:
>
>  
>
>  
>
> Thanks. I can confirm current mob (6c94df6) does work also with
> custom prefix,
> as well as building in a custom dir (mkdir build && cd build &&
> ../configure ...).
>
> However, looking at that commit, I thought it would break with a
> custom --libdir,
> like ./configure --libdir=$(pwd)/dist/mylibs but I tried it and it
> still worked.
>
> Turns out it creates both ./dist/lib and ./dist/mylibs, and
> libtcc.dylib is at both
> of them as well as tcc/ and its content (duplicated at both dirs),
> though libtcc.a
> is only at ./dist/lib/ .
>
> Is that expected? I never tried using --libdir before, but commit
> 6c94df6 makes it look
> a bit hardcoded, so I tried it now. Wouldn't it be better to
> specify the absolute
> install [libdir] ?
>
> Avi
>
> On Thursday, July 9, 2020, 08:40:42 PM GMT+3, Christian Jullien
>  <mailto:eli...@orange.fr> wrote:
>
>  
>
>  
>
> I’ve found another (and better) way to achieve this:
>
> -Wl,-rpath,"@executable_path/$(TOP)"
> -Wl,-rpath,"@executable_path/$(TOP)/../lib
> <mailto:%22%20-Wl,-rpath,%22@executable_path/$(TOP)/../lib>"
>
>  
>
> It is commited, can you please test this one.
>
>  
>
>  
>
> *From:*Tinycc-devel
> [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] *On
> Behalf Of *Christian Jullien
> *Sent:* Thursday, July 09, 2020 19:07
> *To:* tinycc-devel@nongnu.org <mailto:tinycc-devel@nongnu.org>;
> jull...@eligis.com <mailto:jull...@eligis.com>
> *Cc:* 'avih'
> *Subject:* Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer
> works after cleanup
>
>  
>
> Thanks avih, another step is missing (it works well with default
> install location)
>
> Can you please test this:
>
> $ install_name_tool -add_rpath "@executable_path/../lib/" tcc
>
> $ make install
>
> $ ./dist/bin/tcc -vv
>
> tcc version 0.9.27 (x86_64 Darwin)
>
> install: /Users/jullien/tinycc/dist/lib/tcc
>
> …
>
>  
>
> It work for me. If it also works for you I’ll add this step to
> macos build
>
>  
>
> *From:*Tinycc-devel
> [mailto:tinycc-devel-bounces+e

Re: [Tinycc-devel] macos: new tcc command line option?

[ian]

Hi there.

My point is "Why should tcc be gcc compatible ?"

Its main aim is to be faster, and "on the run" via #!/usr/bin/tcc.

IMHO, support too many options, and relevant code behind, is
anti-productive.

Regards.

Le 11/07/2020 à 11:10, avih via Tinycc-devel a écrit :
> I don't have proper gcc installed (via brew or macports), but I think
> it would
> make sense to first check what gcc does and supports.
>
> On the other hand, if it's only aliases to existing options, possibly
> which are
> enabled only on OSX, then I don't think [m]any would object, and it should
> be fairly simple to add and possibly revert later.
>
>
> On Saturday, July 11, 2020, 08:09:07 AM GMT+3, Christian Jullien
>  wrote:
>
>
> Hi maintainers,
>
>  
>
> As often, Apple reinvent the wheel and makes things differently.
>
> Among other, clang handles shared libs .dylib with a different set of
> compiler options.
>
> For example, -shared is replaced by –dynamiclib etc…
>
>  
>
> It means that a ./configure must test if it uses clang or tcc and
> adapt its compiler options.
>
>  
>
> Question: with proper #if/#endif do you allow me to handle clang
> specific options on macos?
>
>  
>
> FYI I currently see 4/5 options to add (or at least silently drop) to
> support tcc on macos with a better compatibility with clang.
>
>  
>
> C.
>
> ___
> 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
-- 
-- sibian0...@gmail.com
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works after cleanup

[ian]

Hi.

Please consider not  fucking everybody's mailing-list.

I ain't a  chat hu ?

But FYI your  contribution is welcomed, many thanks.


ian


Le 09/07/2020 à 23:16, avih via Tinycc-devel a écrit :
>
> I've pushed a fix to mob to support arbitrary libdir (c69290fb).
>
> The relative path is now used during `make test', while the fixed
> libdir is used after install.
>
> On Thursday, July 9, 2020, 09:12:06 PM GMT+3, avih via Tinycc-devel
>  wrote:
>
>
> Note to self: Make sure to double check before posting.
>
> Turns out ./dist/lib/ remained from the previous install, which I
> didn't delete
> before testing with --libdir=$(pwd)/dist/mylibs.
>
> Indeed, it only creates ./dist/mylibs, and indeed it fails to find the
> dylib
> when running ./dist/bin/tcc, (make test still works).
>
>
> On Thursday, July 9, 2020, 09:02:24 PM GMT+3, avih 
> wrote:
>
>
> Thanks. I can confirm current mob (6c94df6) does work also with custom
> prefix,
> as well as building in a custom dir (mkdir build && cd build &&
> ../configure ...).
>
> However, looking at that commit, I thought it would break with a
> custom --libdir,
> like ./configure --libdir=$(pwd)/dist/mylibs but I tried it and it
> still worked.
>
> Turns out it creates both ./dist/lib and ./dist/mylibs, and
> libtcc.dylib is at both
> of them as well as tcc/ and its content (duplicated at both dirs),
> though libtcc.a
> is only at ./dist/lib/ .
>
> Is that expected? I never tried using --libdir before, but commit
> 6c94df6 makes it look
> a bit hardcoded, so I tried it now. Wouldn't it be better to specify
> the absolute
> install [libdir] ?
>
> Avi
>
>
> On Thursday, July 9, 2020, 08:40:42 PM GMT+3, Christian Jullien
>  wrote:
>
>
> I’ve found another (and better) way to achieve this:
>
> -Wl,-rpath,"@executable_path/$(TOP)"
> -Wl,-rpath,"@executable_path/$(TOP)/../lib
> <mailto:%22%20-Wl,-rpath,%22@executable_path/$(TOP)/../lib>"
>
>  
>
> It is commited, can you please test this one.
>
>  
>
>  
>
> *From:*Tinycc-devel
> [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] *On Behalf
> Of *Christian Jullien
> *Sent:* Thursday, July 09, 2020 19:07
> *To:* tinycc-devel@nongnu.org; jull...@eligis.com
> *Cc:* 'avih'
> *Subject:* Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works
> after cleanup
>
>  
>
> Thanks avih, another step is missing (it works well with default
> install location)
>
> Can you please test this:
>
> $ install_name_tool -add_rpath "@executable_path/../lib/" tcc
>
> $ make install
>
> $ ./dist/bin/tcc -vv
>
> tcc version 0.9.27 (x86_64 Darwin)
>
> install: /Users/jullien/tinycc/dist/lib/tcc
>
> …
>
>  
>
> It work for me. If it also works for you I’ll add this step to macos build
>
>  
>
> *From:*Tinycc-devel
> [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] *On Behalf
> Of *avih via Tinycc-devel
> *Sent:* Thursday, July 09, 2020 18:23
> *To:* tinycc-devel@nongnu.org; jull...@eligis.com
> *Cc:* avih
> *Subject:* Re: [Tinycc-devel] macos: DYLD_LIBRARY_PATH no longer works
> after cleanup
>
>  
>
>
> Seems that moving ./dist/lib/libtcc.dylib to ./dist/bin/ makes it work,
> compile programs successfully, and -run works as well.
>
> So it seems that install target doesn't take everything into account.
>
> On Thursday, July 9, 2020, 07:17:38 PM GMT+3, avih 
> wrote:
>
>  
>
>  
>
>
> Oh, I missed the commits from today.
>
> Indeed, with latest mob (6bd0ced) this now succeeds:
> ./configure --disable-static && make && make test
>
> However, when building and installing like this:
> ./configure --disable-static --prefix=$(pwd)/dist && make && make test
> && make install
>
> Then it succeeds, but the tcc binary seems missing the dylib:
> $ ./dist/bin/tcc
> dyld: Library not loaded: @rpath/libtcc.dylib
> Referenced from: /Users/avih/dev/tcc/tcc.upstream/./dist/bin/tcc
> Reason: image not found
> Abort trap: 6
>
> When not using --disable-static, then tcc runs fine, compiles and even
> -run works.
>
> On Thursday, July 9, 2020, 07:07:12 PM GMT+3, Christian Jullien
>  wrote:
>
>  
>
>  
>
> ?? can you please try with mob and give me the complete log?
>
>  
>
> The fix is
> “macos: tcc searches for libtcc.dyln in the same directory as its executable”
>
>  
>
> C.
>
>  
>
> *From:*avih [mailto:avih...@yahoo.com]
> *Sent:* Thursday, July 09, 2020 17:52
> *To:* jull...@eligis.com; tinycc-devel@nongnu.org
> *Subject:* Re: [Tinycc-devel] mac

Re: [Tinycc-devel] Regression building GMP with tcc, bisected

[ian]

BTW and IMHO, using a lib function (such as `strcmp`) in a compiler, is
*always* a bad solution.

... such as litterals like ""

Regards

Le 06/07/2020 à 18:16, Michael Matz a écrit :
> Hello,
>
> On Mon, 6 Jul 2020, Herman ten Brugge wrote:
>
>> In the old code you can also make it fail:
>> tst.s:
>> -
>>     .data
>>     .globl  foo
>>     .long   0
>> foo
>>     .byte   0
>> -
>>
>> If you compile it in the old compiler with:
>> tcc -include tst.s -c tst.s
>> you get no error. This is because of the same latent bug in
>> next_nomacro1.
>
> I think the bug is rather to prepare preprocessing directives and the
> inline stack when no preprocessing is to be done.  See 40671f76 in mob.
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- sibian0...@gmail.com
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Add new _ISOCxx macros?

[ian]

Hi Christian,

It seems consistent to me.

Regards.

Le 16/01/2020 à 06:55, Christian Jullien a écrit :
>
> Hi all,
>
>  
>
> When we use tcc on Linux, we also use /usr/include/*.h.
>
> Some definitions are only visible for C11 and controlled by use of
> _ISOC11_SOURCE as used by glibc (see for example
> http://man7.org/linux/man-pages/man7/feature_test_macros.7.html).
>
>  
>
> As tcc is C99 by default, I propose to also automatically set
> _ISOC99_SOURCE by default but _ISOC11_SOURCE when -std=c11 is used.
>
>  
>
> Wdyt?
>
>  
>
> Reference:
>
>  
>
>     _ISOC99_SOURCE (since glibc 2.1.3)
>
>    Exposes declarations consistent with the ISO C99 standard.
>
>  
>
>    Earlier glibc 2.1.x versions recognized an equivalent macro
>
>    named _ISOC9X_SOURCE (because the C99 standard had not then
>
>    been finalized).  Although the use of this macro is
> obsolete,
>
>    glibc continues to recognize it for backward compatibility.
>
>  
>
>    Defining _ISOC99_SOURCE also exposes ISO C (1990)
> Amendment 1
>
>    ("C95") definitions.  (The primary change in C95 was
> support
>
>    for international character sets.)
>
>  
>
>    Invoking the C compiler with the *option -std=c99
> produces the*
>
> *   same effects as defining this macro.*
>
>  
>
>    _ISOC11_SOURCE (since glibc 2.16)
>
>    Exposes declarations consistent with the ISO C11 standard.
>
>    Defining this macro also enables C99 and C95 features (like
>
>    _ISOC99_SOURCE).
>
>  
>
>    Invoking the C compiler with the option *-std=c11
> produces the*
>
> *   same effects as defining this macro.*
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Request: __attribute__((vector_size))

[ian]

Hi again, and after re-reading (and I admit, a few hours sleeping )

I do get the point, when you compare it to the floats. But I see a major
difference :
a float is a scalar value, not a data structure (in that case, even if
as you wrote that the float is one too, it's still a scalar).
To do the things the right way, the compiler then should define a new
data-type (say vec or so), and new general standard operations upon it.
And we get back to my first point : it wouldn't be C anymore, but
something more like C++.

The compiler does not have to deal with user defined data-structures,
and must not overload operators. Here are the assumptions. You can
easily understand that + is well defined for floating numbers, as for
integer (even big nums, which is from a library, not a standard type),
but for algebraic data types it makes assumptions.
Again, what if I just want to concatenate the datas ? Not do a vectorial
addition, but use it like arrays or lists ?

Regards,


ian

Le 09/01/2020 à 16:50, uso ewin a écrit :
> On Thu, Jan 9, 2020 at 3:55 PM ian  wrote:
>> Hi.
>>
>> I stay at my position, and keep saying it has nothing to deal with a 
>> compiler !
>> It deals with assumptions concerning the main aim of data structures.
>> It seems that you know how to code it, so if tcc can compile this it's fine 
>> and enough.
>> But, FOR SURE, it does not have to translate an index-by-index array 
>> elements sum !!!
>>
>>
>> Regards, ian.
>>
> I have a different point of view:
>
> I saw that kind of extension as somewhat similar to what float/double are in 
> C:
> Machine don't have a float data type, they have registry, memory and
> instructions,
> that allow to do floating point arithmetic on registry.
>
> Float support are more or less compiler that does assumption
> concerning the aim of some data.
> That's why they add a type in C I guess.
>
> And as vector extension, you could code float operation in C, but it
> would be hard to tell the
> compiler to use the float specific instructions.
>
> I see this extension as similar: it add a type that do some assumption
> of some data and
> allow to use some instruction on them.
>
> The main difference is that only a few processor support instruction on 
> matrix.
> (But I guess that if intel had some kind of vector operation when C
> was created this would be part of the standard)
>
> I don't think it's a must have (far from it), nor I think tcc should
> support vector extension,
> but if the support is done in a non intrusive way, I don't see why not.
>
> Matthias,
>
>> Le 09/01/2020 à 12:34, Rasmus Riiner via Tinycc-devel a écrit :
>>
>> I would say that it is okay to generate low quality code, that it's better 
>> than nothing, as long the implementation doesn't impact the rest of the 
>> compiler too much... but of course that is from my biased point of view.
>>
>> Which is that the only thing presently keeping TCC compile times out of my 
>> reach is that a bunch of code akin to this in C++:
>>
>> vec2 v4 = vel + a3 * dt;
>> vec2 p4 = pos + v4 * dt;
>> vec2 a4 = entity_acceleration(p4, v4, entity);
>>
>> *dpos = (v1 + (v2 + v3) * 2.0 + v4) * (dt * (1.0 / 6.0));
>> *dvel = (a1 + (a2 + a3) * 2.0 + a4) * (dt * (1.0 / 6.0));
>>
>> Would have to be rewritten to something like this for plain C:
>>
>> vec2 v4 = v2Add(vel + v2Scale(a3 * dt));
>> vec2 p4 = v2Add(pos + v2Scale(v4 * dt));
>> vec2 a4 = entity_acceleration(p4, v4, entity);
>>
>> *dpos = v2Scale(v2Add(v2Add(v1, v2Scale(v2Add(v2, v3), 2.0)), v4), dt * 
>> (1.0 / 6.0));
>> *dvel = v2Scale(v2Add(v2Add(a1, v2Scale(v2Add(a2, a3), 2.0)), a4), dt * 
>> (1.0 / 6.0));
>>
>> Operator overloading doesn't fit C, and I'm glad it's not in there, but then 
>> the only way to fix this particular inefficiency is with some kind of 
>> built-in array math, perhaps as an extension... which is exactly what the 
>> GCC extension would provide. The extension goes a bit too far perhaps, what 
>> with supporting every basic type as a vector element, I can see why they did 
>> that though. For TCC, it might be sensible to limit the possible element 
>> types to 32bit floats or integers, and cap the possible vector length to 4...
>>
>> I'm not sure what I would do in your position, implementing the extension 
>> (or a subset of it) might not be what's ultimately best for the project, but 
>> hopefully you can see where I'm coming from. Compile times for basic C++ 
>> programs take entire seconds with the available compilers, whereas I could 
>> literally tcc -run and be in-game, w

Re: [Tinycc-devel] Request: __attribute__((vector_size))

[ian]

Hi back Matt,

My main point is so far "why not implement then a * operator dedicated
to vectors" 
Believe me, from what I did in languages programmation, overwiting such
a standard operaor is ALWAYS a very bad idea..

Regards

Le 09/01/2020 à 16:50, uso ewin a écrit :
> On Thu, Jan 9, 2020 at 3:55 PM ian  wrote:
>> Hi.
>>
>> I stay at my position, and keep saying it has nothing to deal with a 
>> compiler !
>> It deals with assumptions concerning the main aim of data structures.
>> It seems that you know how to code it, so if tcc can compile this it's fine 
>> and enough.
>> But, FOR SURE, it does not have to translate an index-by-index array 
>> elements sum !!!
>>
>>
>> Regards, ian.
>>
> I have a different point of view:
>
> I saw that kind of extension as somewhat similar to what float/double are in 
> C:
> Machine don't have a float data type, they have registry, memory and
> instructions,
> that allow to do floating point arithmetic on registry.
>
> Float support are more or less compiler that does assumption
> concerning the aim of some data.
> That's why they add a type in C I guess.
>
> And as vector extension, you could code float operation in C, but it
> would be hard to tell the
> compiler to use the float specific instructions.
>
> I see this extension as similar: it add a type that do some assumption
> of some data and
> allow to use some instruction on them.
>
> The main difference is that only a few processor support instruction on 
> matrix.
> (But I guess that if intel had some kind of vector operation when C
> was created this would be part of the standard)
>
> I don't think it's a must have (far from it), nor I think tcc should
> support vector extension,
> but if the support is done in a non intrusive way, I don't see why not.
>
> Matthias,
>
>> Le 09/01/2020 à 12:34, Rasmus Riiner via Tinycc-devel a écrit :
>>
>> I would say that it is okay to generate low quality code, that it's better 
>> than nothing, as long the implementation doesn't impact the rest of the 
>> compiler too much... but of course that is from my biased point of view.
>>
>> Which is that the only thing presently keeping TCC compile times out of my 
>> reach is that a bunch of code akin to this in C++:
>>
>> vec2 v4 = vel + a3 * dt;
>> vec2 p4 = pos + v4 * dt;
>> vec2 a4 = entity_acceleration(p4, v4, entity);
>>
>> *dpos = (v1 + (v2 + v3) * 2.0 + v4) * (dt * (1.0 / 6.0));
>> *dvel = (a1 + (a2 + a3) * 2.0 + a4) * (dt * (1.0 / 6.0));
>>
>> Would have to be rewritten to something like this for plain C:
>>
>> vec2 v4 = v2Add(vel + v2Scale(a3 * dt));
>> vec2 p4 = v2Add(pos + v2Scale(v4 * dt));
>> vec2 a4 = entity_acceleration(p4, v4, entity);
>>
>> *dpos = v2Scale(v2Add(v2Add(v1, v2Scale(v2Add(v2, v3), 2.0)), v4), dt * 
>> (1.0 / 6.0));
>> *dvel = v2Scale(v2Add(v2Add(a1, v2Scale(v2Add(a2, a3), 2.0)), a4), dt * 
>> (1.0 / 6.0));
>>
>> Operator overloading doesn't fit C, and I'm glad it's not in there, but then 
>> the only way to fix this particular inefficiency is with some kind of 
>> built-in array math, perhaps as an extension... which is exactly what the 
>> GCC extension would provide. The extension goes a bit too far perhaps, what 
>> with supporting every basic type as a vector element, I can see why they did 
>> that though. For TCC, it might be sensible to limit the possible element 
>> types to 32bit floats or integers, and cap the possible vector length to 4...
>>
>> I'm not sure what I would do in your position, implementing the extension 
>> (or a subset of it) might not be what's ultimately best for the project, but 
>> hopefully you can see where I'm coming from. Compile times for basic C++ 
>> programs take entire seconds with the available compilers, whereas I could 
>> literally tcc -run and be in-game, with immediate feedback, nearly instantly.
>> I could bite the bullet and start using function syntax for basic vector 
>> operations, I just wanted to confirm whether the GCC extension is outside 
>> the scope of TCC, or not, first. I don't actually use any C++ features over 
>> C, other than operator overloading and a little bit of function overloading 
>> (which I could do just fine without). It feels like so close, yet so far, 
>> you know?
>>
>> Rasmus.
>>
>> - Reply to message -
>>
>> Sure, Rasmus asked to have this extension in TCC to be able to use it for
>> writing libraries or apps; i.e. he asked if TCC could be extended to
>> compil

Re: [Tinycc-devel] Request: __attribute__((vector_size))

[ian]

Hi.

I stay at my position, and keep saying it has nothing to deal with a
compiler !
It deals with assumptions concerning the main aim of data structures.
It seems that you know how to code it, so if tcc can compile this it's
fine and enough.
But, FOR SURE, it does not have to translate an index-by-index array
elements sum !!!


Regards, ian.


Le 09/01/2020 à 12:34, Rasmus Riiner via Tinycc-devel a écrit :
> I would say that it is okay to generate low quality code, that it's
> better than nothing, as long the implementation doesn't impact the
> rest of the compiler too much... but of course that is from my biased
> point of view.
>
> Which is that the only thing presently keeping TCC compile times out
> of my reach is that a bunch of code akin to this in C++:
>
>     vec2 v4 = vel + a3 * dt;
>     vec2 p4 = pos + v4 * dt;
>     vec2 a4 = entity_acceleration(p4, v4, entity);
>
>     *dpos = (v1 + (v2 + v3) * 2.0 + v4) * (dt * (1.0 / 6.0));
>     *dvel = (a1 + (a2 + a3) * 2.0 + a4) * (dt * (1.0 / 6.0));
>
> Would have to be rewritten to something like this for plain C:
>
>     vec2 v4 = v2Add(vel + v2Scale(a3 * dt));
>     vec2 p4 = v2Add(pos + v2Scale(v4 * dt));
>     vec2 a4 = entity_acceleration(p4, v4, entity);
>
>     *dpos = v2Scale(v2Add(v2Add(v1, v2Scale(v2Add(v2, v3), 2.0)), v4),
> dt * (1.0 / 6.0));
>     *dvel = v2Scale(v2Add(v2Add(a1, v2Scale(v2Add(a2, a3), 2.0)), a4),
> dt * (1.0 / 6.0));
>
> Operator overloading doesn't fit C, and I'm glad it's not in there,
> but then the only way to fix this particular inefficiency is with some
> kind of built-in array math, perhaps as an extension... which is
> exactly what the GCC extension would provide. The extension goes a bit
> too far perhaps, what with supporting every basic type as a vector
> element, I can see why they did that though. For TCC, it might be
> sensible to limit the possible element types to 32bit floats or
> integers, and cap the possible vector length to 4...
>
> I'm not sure what I would do in your position, implementing the
> extension (or a subset of it) might not be what's ultimately best for
> the project, but hopefully you can see where I'm coming from. Compile
> times for basic C++ programs take entire seconds with the available
> compilers, whereas I could literally tcc -run and be in-game, with
> immediate feedback, nearly instantly.
> I could bite the bullet and start using function syntax for basic
> vector operations, I just wanted to confirm whether the GCC extension
> is outside the scope of TCC, or not, first. I don't actually use any
> C++ features over C, other than operator overloading and a little bit
> of function overloading (which I could do just fine without). It feels
> like so close, yet so far, you know?
>
> Rasmus.
>
> - Reply to message -
>
> Sure, Rasmus asked to have this extension in TCC to be able to use
> it for
> writing libraries or apps; i.e. he asked if TCC could be extended to
> compile code like this:
>
> -
> typedef int v4si __attribute__ ((vector_size (16)));
> void foo (void) {
> v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
> c = a + b;
> bar(c[0], c[1], c[2], c[3]);
> }
> -
>
> For that TCC would need to be extended somewhat, and I was
> alluding to the
> fact that this extension isn't totally trivial if it shouldn't
> generate
> very low quality code. If it's okay to generate low quality code and
> not adhere to the psABI for parameter passing of these types then
> it's not
> too much work.
>
> If you were asking if such extension is really a must have in a
> compiler: no, otherwise it wouldn't be an extension. It's a nice
> to have,
> and I can see why Rasmus wants it, but it comes at a non-trivial
> cost to
> support it in a small compiler.
>
>
> Ciao,
> Michael.
>  
>
>  
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Request: __attribute__((vector_size))

[ian]

Hi.

Ok, thanks for explanation (and btw sorry for yesterday, I was a lil bit
tired), but then it makes me think that I'm not so wrong.
Defining an addition operation for vectors is defining a group for this
operation and this data structure.
So it becomes something more like an object than a raw structure.
And the use of the standard "+" symbol makes me very suspicious about this.

So. Further then, why not defining a group for multiplication (and "*"
symbol...) too ?
And, finally, what if s/o would just concatenate the structures (like
`(append '(1 2 3 4) '(4 5 6 7))` for instance) ?

I'm really still not sure the compiler should be extended for this,
because it makes a lot of assumptions about the purpose of the structure.

Have a nice day 

ian

Le 07/01/2020 à 01:33, Michael Matz a écrit :
> Hi,
>
> On Mon, 6 Jan 2020, ian wrote:
>
>> Did I miss something ?
>> It seemed to me that it was dealing with application side of things.
>
> Sure, Rasmus asked to have this extension in TCC to be able to use it
> for writing libraries or apps; i.e. he asked if TCC could be extended
> to compile code like this:
>
> -
> typedef int v4si __attribute__ ((vector_size (16)));
> void foo (void) {
>   v4si a = {1,2,3,4}, b = {5,6,7,8}, c;
>   c = a + b;
>   bar(c[0], c[1], c[2], c[3]);
> }
> -
>
> For that TCC would need to be extended somewhat, and I was alluding to
> the fact that this extension isn't totally trivial if it shouldn't
> generate very low quality code.  If it's okay to generate low quality
> code and not adhere to the psABI for parameter passing of these types
> then it's not too much work.
>
> If you were asking if such extension is really a must have in a
> compiler: no, otherwise it wouldn't be an extension.  It's a nice to
> have, and I can see why Rasmus wants it, but it comes at a non-trivial
> cost to support it in a small compiler.
>
>
> Ciao,
> Michael.
>
>> Like, say, libraries. For the least, as long as compilers does not care
>> about maths or physics
>>
>> If I'm wrong, please, explain to me where...
>>
>> ian
>>
>> Le 06/01/2020 à 21:46, Michael Matz a écrit :
>>   Hi,
>>
>>   On Mon, 6 Jan 2020, ian wrote:
>>
>>     Is the support for data structures and calculations
>>     a real "need to" for a compiler 
>>
>>
>>   Um, I don't know how to answer this.  As it seems the
>>   alternative to calculations is guessing, yes, I do think
>>   calculations and data structures are indeed necessary for a
>>   compiler, or any program whatsoever.
>>
>>
>>   Ciao,
>>   Michael.
>>
>>
>>     regards,
>>
>>     ian
>>
>>     Le 06/01/2020 à 20:36, Michael Matz a écrit :
>>       Hello,
>>
>>       On Mon, 6 Jan 2020, Rasmus Riiner via
>>     Tinycc-devel wrote:
>>
>>         See here:
>>        
>>     https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>>
>>         This is one of those things that doesn't
>>     come up in
>>         a lot of types of programming, but is
>>     indispensable
>>         in some, namely anything to do with 2D
>>     or 3D math.
>>         The ability to just write `position +=
>>     velocity *
>>         dt;` style statements might be one of
>>     the most
>>         important reasons most game developers
>>     choose C++
>>         over C. It's certainly the only thing
>>     keeping me
>>         from using TCC in the development of my
>>     own project.
>>
>>         Actually emitting SSE instructions might
>>     be beyond
>>         the scope of tcc (Tiny after all),
>>     supporting the
>>         expressions though would be a huge help.
>>
>>
>>       Without proper support in the backends for
>>     vector instructions
>>       the generated code for this extension from TCC
>>     would be of
>>       abysmal quality. Technically it wouldn't be
>>     too much work to
>>       semantically support that, but the values
>>     would need to be
>>       c

Re: [Tinycc-devel] Request: __attribute__((vector_size))

[ian]

Michael,

Did I miss something ?
It seemed to me that it was dealing with application side of things.
Like, say, libraries. For the least, as long as compilers does not care
about maths or physics

If I'm wrong, please, explain to me where...

ian

Le 06/01/2020 à 21:46, Michael Matz a écrit :
> Hi,
>
> On Mon, 6 Jan 2020, ian wrote:
>
>> Is the support for data structures and calculations a real "need to"
>> for a compiler 
>
> Um, I don't know how to answer this.  As it seems the alternative to
> calculations is guessing, yes, I do think calculations and data
> structures are indeed necessary for a compiler, or any program
> whatsoever.
>
>
> Ciao,
> Michael.
>
>>
>> regards,
>>
>> ian
>>
>> Le 06/01/2020 à 20:36, Michael Matz a écrit :
>>   Hello,
>>
>>   On Mon, 6 Jan 2020, Rasmus Riiner via Tinycc-devel wrote:
>>
>>     See here:
>>     https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>>
>>     This is one of those things that doesn't come up in
>>     a lot of types of programming, but is indispensable
>>     in some, namely anything to do with 2D or 3D math.
>>     The ability to just write `position += velocity *
>>     dt;` style statements might be one of the most
>>     important reasons most game developers choose C++
>>     over C. It's certainly the only thing keeping me
>>     from using TCC in the development of my own project.
>>
>>     Actually emitting SSE instructions might be beyond
>>     the scope of tcc (Tiny after all), supporting the
>>     expressions though would be a huge help.
>>
>>
>>   Without proper support in the backends for vector instructions
>>   the generated code for this extension from TCC would be of
>>   abysmal quality. Technically it wouldn't be too much work to
>>   semantically support that, but the values would need to be
>>   committed to memory (instead of vector registers) and regarded
>>   as constant sized arrays (at which point the function call ABI
>>   would be different from the respective native ABI, which, again,
>>   would be hard to fix without proper support for vector insns in
>>   the backends).
>>
>>   That extension really doesn't feel very well suited for a simple
>>   compiler like TCC ;-)  But perhaps it can be done
>>   non-intrusively enough.
>>
>>     I sat down yesterday in an attempt to do this
>>     myself, but it turns out I'm not good enough for the
>>     job. I couldn't make heads or tails of it. However,
>>     this might be a breeze for someone that knows TCC
>>     like the back of their hand.
>>
>>     So, any takers?
>>
>>
>>
>>   Ciao,
>>   Michael.
>>
>>   ___
>>   Tinycc-devel mailing list
>>   Tinycc-devel@nongnu.org
>>   https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>>
>> -- 
>> -- i...@sibian.fr
>> -- Développeur compulsif
>>
>>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Request: __attribute__((vector_size))

[ian]

Hi Michael.
Is the support for data structures and calculations a real "need to" for
a compiler 

regards,

ian

Le 06/01/2020 à 20:36, Michael Matz a écrit :
> Hello,
>
> On Mon, 6 Jan 2020, Rasmus Riiner via Tinycc-devel wrote:
>
>> See here: https://gcc.gnu.org/onlinedocs/gcc/Vector-Extensions.html
>>
>> This is one of those things that doesn't come up in a lot of types of
>> programming, but is indispensable in some, namely anything to do with
>> 2D or 3D math. The ability to just write `position += velocity * dt;`
>> style statements might be one of the most important reasons most game
>> developers choose C++ over C. It's certainly the only thing keeping
>> me from using TCC in the development of my own project.
>>
>> Actually emitting SSE instructions might be beyond the scope of tcc
>> (Tiny after all), supporting the expressions though would be a huge
>> help.
>
> Without proper support in the backends for vector instructions the
> generated code for this extension from TCC would be of abysmal
> quality. Technically it wouldn't be too much work to semantically
> support that, but the values would need to be committed to memory
> (instead of vector registers) and regarded as constant sized arrays
> (at which point the function call ABI would be different from the
> respective native ABI, which, again, would be hard to fix without
> proper support for vector insns in the backends).
>
> That extension really doesn't feel very well suited for a simple
> compiler like TCC ;-)  But perhaps it can be done non-intrusively enough.
>
>> I sat down yesterday in an attempt to do this myself, but it turns
>> out I'm not good enough for the job. I couldn't make heads or tails
>> of it. However, this might be a breeze for someone that knows TCC
>> like the back of their hand.
>>
>> So, any takers?
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] bcheck cleanup

[ian]

What a wise answer !

I was thinking exactly the same...
Nevertheless, I just pull down this morning the last commits, and AFAIK,
after a compile with the last mob from october it did work fine on
x86_32 debian10

But Grischka is right, it ain't the place for self testing, neither chat...

Regards.

Le 14/12/2019 à 18:00, grischka a écrit :
> Hi,
>
> I felt some cleanup of the recently additions wrt. the bound-checker
> was needed before it gets too much out of shape.
>
> https://repo.or.cz/tinycc.git/commitdiff/56db092ab7df109508efa4e3d2034028b18fd101
>
>
> Please people do not abuse the public mob branch as your personal
> scratch board.  In your own interest, there is no need to make any
> new idea that you might or might not have visible to the public
> instantly.
>
> As we know for any good idea an even better idea does exist and that
> it may come to the same person just a few hours or days later.  But
> we're really interested only in the best idea you could come up with,
> given the common limitations of time of course.
>
> Also, new features should have at least some relevance for other people
> too.  Which personal easter-eggs or home-brew temporary debugging add-ons
> usually don't.
>
> Thanks,
>
> --- grischka
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] A little hacky CI for TinyCC

[ian]

I agree too.

#TGIF

Le 13/12/2019 à 12:03, Christian Jullien a écrit :
> I LOVE that!!!
>
> If we all agree, is it possible to send an email once and only once with link 
> to failure(s) when a new commit is done which breaks at least one supported 
> architecture?
>
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] 
> On Behalf Of Giovanni Mascellani
> Sent: Friday, December 13, 2019 11:54
> To: tinycc-devel@nongnu.org
> Subject: [Tinycc-devel] A little hacky CI for TinyCC
>
> Hi,
>
> I tried to set up something vaguely resembling a Continuous Integration for 
> TinyCC. The only other CI for TinyCC I managed to find seems to be [1], which 
> is months out of date and only tests one architecture (amd64).
>
>  [1] https://travis-ci.org/TinyCC/tinycc/branches
>
> My CI tests many architectures. I don't have hardware for all of them, so 
> instead I use the runners provided by GitLab CI (which is again amd64), 
> spawning a QEMU virtual machine for the tested architecture.
> QEMU is not identical to actual hardware, but I believe this is better than 
> nothing. Also, the end result is very very hacky and much slower than it 
> could be, but, again, the alternative is nothing (correct me if I am wrong).
>
> I currently test for Debian i386, amd64, armhf and arm64. I will add
> riscv64 as soon as the latest Debian kernel boots again. In line of principle 
> armel too could be added, but I don't know how to generate a Debian armel 
> image that boots with QEMU. It would be nice to add Windows and macOS as 
> well, but I don't know how to automatically perform tests once the virtual 
> machine has started.
>
> Results are here:
>
>   https://gitlab.com/giomasce/tinycc/pipelines
>
> There is a cron job that automatically pushes there commits on the mob 
> branch. Incidentally, i386 tests currently fail[2] (I haven't investigated 
> this yet).
>
>  [2] https://gitlab.com/giomasce/tinycc/-/jobs/378533140#L563
>
> For horror lovers among you, scripts powering the CI are here:
>
>   https://gitlab.com/giomasce/tinycc-test
>
> I hope you find this useful for detecting regressions.
>
> Have fun, Giovanni.
> --
> Giovanni Mascellani  Postdoc researcher - Université 
> Libre de Bruxelles
>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] bounds checking with tcc

[ian]

Hi.

Wondering why you think a mailing-list is a review/tests review notepad.
Not under-rating your work, it's very fine, but why not a private chat ?
Or only when tested a simple comment on a fork ?

Btw, I'd be glad to test it on x86 32 bits linux 5.0.

Regards, ian

Le 02/12/2019 à 22:46, Herman ten Brugge via Tinycc-devel a écrit :
> Little updated patch. Still needs more work.
>
> Regards,
>
>     Herman
>
> On 2019-12-02 18:24, Herman ten Brugge wrote:
>> Hello,
>>
>> I did some debugging with bouds-checking and came up with attached
>> patch.
>> I seriously doubt any one did use bounds checking in a large project
>> before.
>>
>> Currently I can use this now in a large multi threaded project. It
>> still needs some more testing so do not apply the patch yet.
>>
>> I disabled some errors. For example if a bounded pointer is not found
>> I give no error. I also relaxed printing free errors.
>> There were some off by 1 errors in lib/bcheck.c and I needed to make
>> the code thread safe.
>> I used the patch to not link in libtcc1.a in shared objects when
>> bounds checking so I have only one memory pool.
>> This has to be documented because you cannot use this with dlopen for
>> example.
>> I also added the pthread library when bounds checking so it is now
>> multi threaded.
>> I found another problem with nocode_wanted when using sizeof().
>> Also the push/pop trick needed to push some more registers when more
>> parameters are passed in registers.
>>
>> I probably forget to mention a lot a other changes. See the patch.
>>
>> I only tested this on linux x86_64. There are for sure problems on
>> other targets.
>>
>> Regards,
>>
>>     Herman
>>
>>
>> On 2019-11-28 17:41, Michael Matz wrote:
>>> Hello again,
>>>
>>> but to maybe be a bit more constructive:
>>>
>>> On Thu, 28 Nov 2019, Michael Matz wrote:
>>>
>>>>> I fixed this with some push/pop trickery.
>>> I see, yeah, expanding calls during calls is broken as gfunc_call in
>>> the
>>> generators doesn't generally leave a trace in vtop[] which registers
>>> are
>>> currently holding values.  I think you only need so push/pop si/di, as
>>> cx/dx aren't used intentionally during reg-param setup.
>>>
>>> (I think i386-gen.c has a simila bug with fastcall functions).
>>>
>>>>> This probably could be
>>>>> improved. I have now added a minimum patch so bounds checking works a
>>>>> little bit. We need still to fix the shared lib reloc problems and
>>>>> the
>>>>> malloc/free hooks.
>>>> Do we?  Can we perhaps also simply declare bounds checking to work
>>>> only
>>>> with the main executable?  Or remove that whole feature altogether?
>>> And perhaps another compromise: only conditionally enable tracking of
>>> locals: Invent a new cmdline option (say, '-bb'), which sets
>>> do_bounds_checking to 2.  And only if it's > 1 you would also track
>>> locals, whereas with == 1 you would only track arrays and structs.
>>>
>>> Your decision, I think you can push this patch either with that
>>> change, or
>>> without (but try to remove cx/dx from the push/pop).  It doesn't
>>> make tccs
>>> source code larger or uglier in any meaningful way, but does fix
>>> practical
>>> bugs.
>>>
>>>
>>> Ciao,
>>> Michael.
>>
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
-- 
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] SSE calling convention bug

[ian]

Hi.

On GNU/Linux x86, tcc built 24/10/2019,
same test case produces 5.00 too.

ian.

Le 27/10/2019 à 07:32, Christian Jullien a écrit :
> Trying your sample with mod on Windows -m64/-m32 I get:
>
> c: >tcc -m32 foo.c && foo
> 5.00
>
> c:>tcc -m64 foo.c && foo
> 5.00
>
> It only return 3. on Linux x64 (I've not tested your code on Linux x86).
>
> C.
>
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] 
> On Behalf Of Shachaf Ben-Kiki
> Sent: Saturday, October 26, 2019 12:59
> To: tinycc-devel@nongnu.org
> Subject: [Tinycc-devel] SSE calling convention bug
>
> Hello,
>
> I ran into a bug in the SSE function call code in x86_64-gen.c. It's
> in the following lines, in gfunc_call:
>
> if (sse_reg) { /* avoid redundant movaps %xmm0, %xmm0 */
> /* movaps %xmm0, %xmmN */
> o(0x280f);
> o(0xc0 + (sse_reg << 3));
> /* movaps %xmm1, %xmmN */
> o(0x280f);
> o(0xc1 + ((sse_reg+1) << 3));
> }
>
> When sse_reg is %xmm1, this generates
>
> 0f 28 c8movaps %xmm0,%xmm1
> 0f 28 d1movaps %xmm1,%xmm2
>
> Such that the first mov overwrites xmm1 before the second mov uses it.
> Since the registers are used in reverse order and only one or two at a
> time, I think swapping the order of the movs should be sufficient to
> fix it.
>
> Here's a test case:
>
> #include 
>
> struct Point {
>   float x;
>   float y;
> };
>
> struct Rect {
>   struct Point top_left;
>   struct Point size;
> };
>
> float foo(struct Point p, struct Rect r) {
>   return r.size.x;
> }
>
> int main(int argc, char **argv) {
>   struct Point p = {1, 2};
>   struct Rect r = {{3, 4}, {5, 6}};
>   printf("%f\n", foo(p, r));
>   return 0;
> }
>
> This program should print 5, but it prints 3 in tcc.
>
> Is this the right place to post this? I can post it elsewhere, or send
> a patch (it took a while to track this down but I think the fix should
> be easy).
>
> Thanks,
> Shachaf
>
> ___
> 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
-- 
-- i...@sibian.fr
-- Développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] match formats and arguments exactly

[ian]

Hi Pascal,

I *know* that (including the no-way part).
And I *know* too that this misuse is sometimes what's expected by
developers...
Anyway, I don't think it's desirable that kinds of pointers are checked.
Still my humble opinion.

-- ian (i...@sibian.fr)
-- développeur compulsif
Le 21/06/2019 à 16:47, Pascal Cuoq a écrit :
>
>> On 21 Jun 2019, at 16:10, ian > <mailto:sibian0...@gmail.com>> wrote:
>>
>> Hello,IMHO, considering that flexibility is what I love in C
>> programming, and that this checking should be printf job (in that case),
>>
>
> Unfortunately, this is not how printf, or other variadic functions,
> work. The way they work is: the non-variadic arguments (in the case of
> printf, the format string) indicate what variadic arguments should be
> consumed with what type. If the types of the arguments actually passed
> do not match the types indicated by the non-variadic arguments, the
> behavior is undefined.
>
> Not only printf, and other variadic functions, have no obligation to
> warn you if you misuse them, but on every existing platform (including
> the exotic platforms where a pointer is not a pointer), they actually
> have no way to warn you that you are misusing them.

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

Re: [Tinycc-devel] match formats and arguments exactly

[ian]

Hello,

IMHO, considering that flexibility is what I love in C programming, and
that this checking should be printf job (in that case), and many other
things, I agree with Christian.
Even more, still IMHO, a pointer is a pointer, no matter actually how it
will be interpreted later.

Regards

-- ian (i...@sibian.fr)
-- développeur compulsif
Le 21/06/2019 à 15:33, Christian Jullien a écrit :
>
> If I read you correctly, you want to protest if type does not strictly
> match format directive.
>
>  
>
> This is something even gcc does NOT ensure by default:
>
>  
>
> #include 
>
> #include 
>
>  
>
> int
>
> main() {
>
>     int i = 256;
>
>     const char* s = "Hello";
>
>     const void* p = s;
>
>  
>
>     printf("%x\n", i);
>
>     printf("%u %s\n", i, p);
>
> }
>
>  
>
>  
>
> $ gcc -std=c11  foo.c
>
> $ => Ok
>
>  
>
> Only -Wformat (or -Wall) shows a warning on the 2nd printf, printf of
> i (a signed) is always Ok.
>
>  
>
> $ gcc -std=c11 -Wall foo.c
>
> foo.c: In function 'main':
>
> foo.c:11:21: warning: format '%s' expects argument of type 'char *',
> but argument 3 has type 'const void *' [-Wformat=]
>
>  printf("%u %s\n", i, p);   
>    ~^ 
> 
> %p   
>
>  
>
> -Original Message-
> From: Pascal Cuoq [mailto:c...@trust-in-soft.com]
> Sent: Friday, June 21, 2019 15:17
> To: jull...@eligis.com; tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] match formats and arguments exactly
>
>  
>
>  
>
> > On 21 Jun 2019, at 14:56, Christian Jullien  wrote:
>
> >
>
> > This is a valuable check but IMHO, it should be controlled by
> -Wformat (as
>
> > GNU gcc) and set of false by default.
>
> > Otherwise, I suspect tcc users will have a lot a new warnings.
>
>  
>
> I'm not implementing a new warning in TCC. I am only ensuring, by
> following C11 7.21.6.1:8 to the letter, that the TCC source code
> passes the strictest such checks that a C compiler could have, and
> also that a very exotic C compiler does not produce a non-functional
> binary when compiling TCC.
>
>  
>
> Considering the amount of code that good warnings represent, I think
> that a C compiler can either be tiny, or provide helpful warnings. The
> patches I have been sending, including the last one, only make TCC not
> exhibit undefined behavior, a more manageable goal that only requires
> small changes and do not make TCC significantly larger.
>
>  
>
> Pascal
>
>
>
> ___
> 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] Windows x86_64 BUG, SIGSEV is not correctly handled by installed signal handler.

[ian]

Hi all.

With all these changes, any idea of what release I should take for my
32bit machine ?

Any impact on something particular ?

FY I only use C at this time for all the most with JNI or so (or for
educational purpose, as they say).

Any clue ?

/btw Hi fab, so long..

-- ian (i...@sibian.fr)
-- développeur compulsif

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

Re: [Tinycc-devel] not an issue, surely a mistake

[ian]

Thanks all.

Finally found it (but strange).

As Michael said, as suspected, it was a problem about -L. (not a
libc6-dev install problem)

So, I was forced to use a -L/usr/lib/i386-linux-gnu option in all cases,
and to copy crt* to /usr/lib (THIS may be an issue on linux)

On the other hand, my main aim was to use "tcc -run" which works very
fine :)

Thanks again.

ian


Le 24/11/2018 à 18:36, Michael Matz a écrit :
> Hi,
>
> On Sat, 24 Nov 2018, ian wrote:
>
>> None of my habits, but I'd like an advice. I didn't code in C for
>> many many
>> years. But...
>> I did a few years ago correctly install tcc on my windows 7, but
>> unfortunately it went down (winscrap), and I only have my debian 8
>> x32 other
>> PC (kinda server for apache/php/mysql/pgsql/ and so on).
>>
>> I did get the last release found, and I have this error while trying to
>> compile a simple "Hello World, exit=%d"...
>>
>> I get almost the same kind of error while trying to compile
>> gcctestsuite.c
>>
>> tcc: file '/usr/lib/crt1.o' not found
>> tcc: file '/usr/lib/crti.o' not found
>> In file included from test.c:1:
>> In file included from /usr/include/stdio.h:27:
>> /usr/include/features.h:374: include file 'sys/cdefs.h' not found
>
> You miss the development files for glibc, I think on debian it's
> libc-dev or libc6-dev.  (after installing those you probably need to
> reconfigure/build tcc, so that it searches in the correct dirs on
> debian).
>
>
> Ciao,
> Michael.
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel

-- 
-- ian (sibian0...@gmail.com)
-- développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] not an issue, surely a mistake

[ian]

Hi to you all.

None of my habits, but I'd like an advice. I didn't code in C for many
many years. But...
I did a few years ago correctly install tcc on my windows 7, but
unfortunately it went down (winscrap), and I only have my debian 8 x32
other PC (kinda server for apache/php/mysql/pgsql/ and so on).

I did get the last release found, and I have this error while trying to
compile a simple "Hello World, exit=%d"...

I get almost the same kind of error while trying to compile gcctestsuite.c

tcc: file '/usr/lib/crt1.o' not found
tcc: file '/usr/lib/crti.o' not found
In file included from test.c:1:
In file included from /usr/include/stdio.h:27:
/usr/include/features.h:374: include file 'sys/cdefs.h' not found

Any clue ? Where was I wrong ?

-- 
-- ian (sibian0...@gmail.com)
-- développeur compulsif
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel