from:"Thomas Preud'homme"

Le samedi 11 avril 2015, 17:43:05 Sergey Korshunoff a écrit :
 Hi, Thomas!
 
  What do you mean by is not a good one? Is the code totally invalid C? It
  all boils down to whether we want tcc to be able to compile such code. If
  yes, then it doesn't matter if the code is ugly or what.
 
 This version of the kernel can't be compiled by the gcc 3.4+  Only gcc
 2.95  This is what I mean. The situation is different with the 2.4.37.
 This version of the kernel can be compiled by newer versions of the
 gcc (I tested gcc 3.4.6 and 4.1.2)

I see. But perhaps the error is unrelated to the thing GCC doesn't like?

Anyway, if the bug is also triggered with kernel 2.4.37 then feel free to 
reduce that one instead.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] TCC arm64 back end

Hi Michael,

Le mercredi 11 mars 2015, 23:10:45 Thomas Preud'homme a écrit :
 Le dimanche 22 février 2015, 06:13:21 Michael Matz a écrit :
  
  And I pulled my hair out again when tracing the different paths the
  linker can go through in different modes, and how the relocs and symbol
  values change over the course of compilation.  One of those days ... :-)
 
 I think that's the next thing I'm going to work on. And then maybe simplify
 the Makefile and configure machinery but that's less fun and easier to break
 in my experience. I already started looking at bind_exe_dynsyms and why
 it's needed. All I can say for now is that without it the linking fails on
 x86-64 because of unresolved __libc_start_main. This is unsurprisingly
 provided by the libc.
 

 From what I understand a symbol is considered unresolved if it cannot be
 found  in the dynsym section of the output file and it seems only
 relocation handled in build_got_entries leads to a dynsym being created.
 However
 __libc_start_main has a R_X86_64_PC32 that doesn't lead to a got + plt so
 no  entry created in dynsym.

I was a bit puzzled because I saw symbols are resolved when a file is loaded 
that define them (in tcc_load_object_file). The reason this doesn't happen here 
is that the symbol is provided by libc.so.6 and the function that loads 
dynamic libraries (tcc_load_dll) only look for undefined symbols in 
dynsymtab_section rather than symtab_section. There might be an obvious reason 
but I'm not sure why symbols from object files and libraries are handled 
differently in terms of name resolution. Of course relocation happens 
differently but name resolution should be the same, shouldn't it?

 
 I probably won't write any code tonight and it'll take time but we'll get
 things cleaned up eventually.

To be honest I just finally started really working on it (I already check a 
small thing in the code last time before I wrote the mail and then another 
small bit later). I didn't write anything yet but already found a bug in tcc: 
the name resolution put the program last in the global order rather than first.

I confirmed it with the following example:

% cat program_resolve_lib.c 
#include stdio.h

int foo (const char * __restrict, ...);

int
printf (const char * __restrict s, ...)
{
  puts (Program's printf);
  return puts (s);
}

int
main (void)
{
  return foo (Hello, world!);
}

% cat libprogram_resolve_lib.c 
#include stdio.h

int
foo (const char * __restrict s, ...)
{
  return !printf (s);
}

I compiled and linked the library with gcc, and compiled the main with gcc as 
well. When linking the main with gcc I get:

Program's printf
Hello, world!

But when linking with tcc I get:

Hello, world!

(without newline after).


I also found a possible speed improvement. Currently tcc_load_dll load dll 
recursively. That should only be necessary for tcc_run but that require 
changing bind_libs_dynsyms (which requires changing anyway because of the bug 
above).

I'll let you know of my progress if you are interested. Anyway, as usual with 
the linker, I'm having a lot of fun. :-)

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Fix for Microsoft compilers

Le dimanche 12 avril 2015, 15:10:14 oldfaber a écrit :
  Except that later there is name = buf; with name staying live out of
  this if scope. So this change is not correct. It would be better to move
  it out up a bit.
  
  Best regards,
  
  Thomas
 
 Yes, you are right, the patch is wrong.
 
 What about removing char buf[32] and replacing
 strcpy(buf, __bound_);
 strcat(buf, name);
 name = buf;
 
 with
 
 if (strlen(name) + strlen(__bound_) 
 (unsigned)STRING_MAX_SIZE) {
 memmove(name + strlen(__bound_), name, strlen(name));
 memcpy(name, __bound_, strlen(__bound_));
 }

Oh my, get_tok_str returns a pointer to a local variable. So the proper fix 
would be to make get_tok_str take a CString as parameter and have the caller 
allocate the buffer associated with the CString. And then it's just a matter of 
allocating buf to STRING_MAX_SIZE.

Cheers,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] TCC arm64 back end

On April 12, 2015 7:02:22 PM GMT+08:00, Sergey Korshunoff sey...@gmail.com 
wrote:
 Hi, Tomas!
 
  the name resolution put the program last in the global order rather
 than first.
 Is this hard to change?

It should be ok for me because I'm already familiar with the code. I will fix 
it this week.

Cheers.

Tom

 
 ___
 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] Fix for Microsoft compilers

Le mardi 24 mars 2015, 22:55:49 oldfaber a écrit :
 Hi,
 
 Miccrosoft Visual Sudio (Express) 2008 and 2010 do not accept variable
 definitions C99 style.
 Please apply this patch to mob
 
 libtcc.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/libtcc.c b/libtcc.c
 index 5a9681f..660c935 100644
 --- a/libtcc.c
 +++ b/libtcc.c
 @@ -462,8 +462,8 @@ ST_FUNC void put_extern_sym2(Sym *sym, Section *section,
 if (!sym-c) {
  name = get_tok_str(sym-v, NULL);
  #ifdef CONFIG_TCC_BCHECK
 -char buf[32];
  if (tcc_state-do_bounds_check) {
 +   char buf[32];
  /* XXX: avoid doing that for statics ? */
  /* if bound checking is activated, we change some function
 names by adding the __bound prefix */

Except that later there is name = buf; with name staying live out of this if 
scope. So this change is not correct. It would be better to move it out up a 
bit.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Dollar Sign in Identifiers Extension

Le samedi 11 avril 2015, 06:14:04 Sergey Korshunoff a écrit :
 Hi! A modified version of the patch is attached.

Looks good at quick look. I'm not sure about the switch, we already accept 
some gnu extension without any switch for that. Or maybe introduce a more 
general switch for all C extensions. You could enable it by default en disable 
it if std=c99 for instance?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Any interest in #pragma(lib) and CGI extensions?

Le samedi 11 avril 2015, 07:59:44 Sergey Korshunoff a écrit :
 A preliminary patch for the -xc and -xa options is attached.

I often swear at software that refuse to perform an action because the 
extension is not the one they expect. Usually it's with media player though 
but I'm still very much in favor of such a patch.

As for the content of the patch, I'd remove all warnings except the 
unsupported language one. Also, since you introduce the concept of kind of file 
(assembly code, C code, etc…) it seems better to set the kind according to the 
extension if -x is not specify and use only the kind after rather than keep 
checking both the kind and the extension.

I'm also not sure about the indentation but maybe it's because I spent more 
time coding on GCC than TinyCC these days. Is it usual in TinyCC to have the 
second line of a if not aligned with the first character inside the 
parenthesis? Ie:

If (foo || bar
|| baz)

I was also surprised to have the || at the end of the line but that might be 
normal in TinyCC's code, I'm not sure anymore.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Partial revert of nocode_wanted patch

Hi Sergey,

I noticed your commit 78c076a70f562fc88bcd6e467bfe61b856f91fbd that partially 
revert a patch of mine. I don't mind people reverting my patch but this seems 
like the wrong solution here.

save_regs(int reg) can generate code generation (and is actually very likely 
to do so, especially if reg = 0) so it seems perfectly appropriate to error 
out if nocode_wanted is defined.

This suggest that the problem is rather that nocode_wanted is defined somewhere 
when it shouldn't. I'd be happy to look into this if you can provide me a 
reduced testcase. Please replace -c by -E on the command line and then use 
creduce to make the test as small as possible.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Dollar Sign in Identifiers Extension

Le samedi 11 avril 2015, 12:49:49 Daniel Holden a écrit :
 
 I'm mainly interested in this change because I'm working on a new
 version of my library Cello: http://libcello.org/ which uses `$` and
 several variations of as macros. There is also RayLanguage which also
 uses it as a macro for a kind of ObjC style message passing:
 https://github.com/kojiba/RayLanguage . But I can also put together some
 test cases using it in the various ways (variable, function, macro,
 define, etc) so make sure it is completely covered.

Testcase are very much welcome for each new feature and bugfix. There should 
always be a testcase unless it's difficult to construct one.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Partial revert of nocode_wanted patch

Le samedi 11 avril 2015, 15:54:45 Sergey Korshunoff a écrit :
 Hi!
 
  I don't mind people reverting my patch but this seems
 
 like the wrong solution here
 
 Sorry :-) I think I can introduce an option like -flinux-kernel-2426
 and then use this option to exclude/change code which breaks
 compilation of this code w/o affecting other usage cases.

It's not what I meant. I'm happy to see a fix to compile an old linux kernel. 
It's just that I think this is not the right place for a fix. nocode_wanted is 
there to indicate that we are out of a function and so generating code doesn't 
have any meaning. This suggest that nocode_wanted was set when it shouldn't 
have.

 
 It is possible to reduce a test like a linux 2.4.26 kernel? I can
 replace -c by -E and then compile a big preprocessed source. But I
 don't know how to use creduce with this file.

The size of the file doesn't matter. creduce works by iteratively trying some 
valid transformation on the source and then running the script you specified it 
and see if it fails or not. Here the script would just look at the warning 
generated by tcc and return an exit code accordingly. If the file after 
reduction is still too big, try a few transformation yourself and try to 
reduce the result again. I've used it a few times and it works quite well.

 
 PS: this version of the kernel is not a good one. 2.4.37 is better.
 But currently 2.4.26 is the only one which can be compiled by tcc.

What do you mean by is not a good one? Is the code totally invalid C? It all 
boils down to whether we want tcc to be able to compile such code. If yes, 
then it doesn't matter if the code is ugly or what.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] regressions on i386

2015-03-12 Thread Thomas Preud'homme

Le jeudi 12 mars 2015, 09:49:03 Sergey Korshunoff a écrit :
 There is a patch in discussion which try to solve this problem.

Can you give a link to this discussion?

Thank you.

Tom

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] TCC arm64 back end

2015-03-11 Thread Thomas Preud'homme

Le dimanche 22 février 2015, 06:13:21 Michael Matz a écrit :
 Hi,
 

 
 And I pulled my hair out again when tracing the different paths the
 linker can go through in different modes, and how the relocs and symbol
 values change over the course of compilation.  One of those days ... :-)

I think that's the next thing I'm going to work on. And then maybe simplify 
the Makefile and configure machinery but that's less fun and easier to break in 
my experience. I already started looking at bind_exe_dynsyms and why it's 
needed. All I can say for now is that without it the linking fails on x86-64 
because of unresolved __libc_start_main. This is unsurprisingly provided by 
the libc.

From what I understand a symbol is considered unresolved if it cannot be found 
in the dynsym section of the output file and it seems only relocation handled 
in build_got_entries leads to a dynsym being created. However 
__libc_start_main has a R_X86_64_PC32 that doesn't lead to a got + plt so no 
entry created in dynsym.

I probably won't write any code tonight and it'll take time but we'll get 
things cleaned up eventually.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] regressions on i386

2015-03-11 Thread Thomas Preud'homme

On March 6, 2015 3:46:46 AM GMT+08:00, Edmund Grimley Evans
edmund.grimley.ev...@gmail.com wrote:

Then commit 76af94862352a3f1d26249d9ea6f795d107c1d7f broke building:

../tcc -B.. -c libtcc1.c -o i386/libtcc1.o -I.. -Wall -g -O2
-fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare
-Wno-unused-result -fPIC -DTCC_TARGET_I386
In file included from libtcc1.c:31:
In file included from /usr/include/stdint.h:26:
/usr/include/features.h:323: error: include file 'bits/predefs.h' not
found
make[1]: *** [i386/libtcc1.o] Error 1
make[1]: Leaving directory `/tmp/tt/lib'

I believe it's also now broken on Debian arm64 and Ubuntu x86_64. Does
it work for anyone?

I have the same problem. I tracked it down to lines 92-112 [1].

The problem comes from adding the _LINK variable containing the arch-qualified
symlink to the native compiler into PROGS. This causes these symlink files to
be interpreted as target to be built and they then match the pattern for
cross-compilers. Since these does not use multiarch by default, the build fails
when trying to use them to compile libtcc1.

Even on non-multiarch systems this approach is wrong as it would leads to 2
builds if I'm correct. The right approach is to extend the recipe for building
native compiler in the same way as cross-compiler with an extra symlink step.

[1]
http://repo.or.cz/w/tinycc.git/blob/5de8b5638f3d0bca6723d5d63d9e22a7f04fff6c:/Makefile#l92

Seiko, can you fix this along those lines?

Best regards,

Tom

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

Re: [Tinycc-devel] RE :Re: 1cbb4d322bc3c89a3b56d35c803a19f99f33ab65 broke tcc on arm (RPi) 6 days ago

2015-03-11 Thread Thomas Preud'homme

Le mardi 10 mars 2015, 11:37:30 Christian JULLIEN a écrit :
 
 gt; PS: arm-tcc can be a cross-compiler on x86.  Can it compile arm *.S
 files in such case?

No because there is no support for ARM assembly. So no matter if it's a native 
or cross compiler tcc cannot compile any ARM .S file.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] Convert some lines from ISO-8859-1 to UTF-8.

2015-03-10 Thread Thomas Preud'homme

On March 9, 2015 7:16:40 AM GMT+08:00, Michael Matz matz@frakked.de wrote:
 Hi,
 
 On Sun, 8 Mar 2015, Edmund Grimley Evans wrote:
 
  Is this a good change, or pointless fiddling?
 
 It doesn't cause too much churn (only changes 10 lines), and it 
 annoyed me sometimes as well, so IMHO it's a good change.

Agreed.

Best regards,

Thomas


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

Re: [Tinycc-devel] Is there a some communication policy?

2015-03-08 Thread Thomas Preud'homme

Le mardi 27 janvier 2015, 14:34:09 Sergey Korshunoff a écrit :
 Looking a http://repo.or.cz/w/tinycc.git
 A commit  Fix macro expansion of empty args has a too short
 description. This comment don't explain what was before a patch. I
 don't see a post or discussion about this patch. There was a patch for
 the same puspose in my set of the patches. And no discussion about  my
 patch too.
 Why to post a patches if others don't  comminicate?

Ideally we would comment on all patch but we desperately lack of enough review 
bandwith for this. I still encourage people to post patch for review unless 
they have a long experience with tcc or compilers in general.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [PATCH] fix potential bug in handling of case_reg

2015-02-17 Thread Thomas Preud'homme

Le lundi 16 février 2015, 12:41:02 Edmund Grimley Evans a écrit :
 
 What's the procedure for contributing to TCC? Should I first send a
 patch to this list and then push it to mob once someone has approved
 it?

There is no formal procedure in place right now. We have a branch (mob) where 
everybody can commit. My take on this is that it depends on your own confidence 
and the history of your past commit to tcc. I encourage people that don't have 
much experience in compilation or coding in general to go through patch 
review. This process is currently slow as we are very few reviewer with not 
much time but we do try our best.

Otherwise, you can commit directly but if there is a high number of problems 
with your commits, especially if it's trivial errors, it will be expected that 
you go through patch review until the quality of your patch improve.

Given your experience in compilation (disclaimer: we work in the same company 
and already met), I'd say just go ahead and commit to mob. Of course you are 
welcome to post for public review first if you want to make sure your patch 
follows tcc code style and use the right internal API for instance.

For what it's worth (my review skills are still modest), the patch looks good 
to me.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] pp should interpret #num as #line num

2015-01-06 Thread Thomas Preud'homme

Le mardi 6 janvier 2015, 12:52:06 Sergey Korshunoff a écrit :
 v2 of the patch, which uses strtoul() insteed of the parse_number()

As I said, I was just looking for some explanation about why the parse_number 
was necessary. The reason is that when dealing with TOK_LINE, next() is 
called. next() will call next_nomacro() and then execute this piece of code:

/* convert preprocessor tokens into C tokens */
if (tok == TOK_PPNUM 
(parse_flags  PARSE_FLAG_TOK_NUM)) {
parse_number((char *)tokc.cstr-data);
}

And at the top of the function preprocess that deal with TOK_LINE:

parse_flags = PARSE_FLAG_PREPROCESS | PARSE_FLAG_TOK_NUM | 
PARSE_FLAG_LINEFEED;

So yeah, the next token after TOK_LINE becomes a number and can be found in 
tokc.i. If dealing with a #N macro, it would be a TOK_PPNUM and you'd need to 
use parse_number to turn it into a normal number.

Therefore the approach in your first patch was perfectly fine. One thing 
though: 
could you rather move parse_number just before preprocess rather than 
predeclare it? Unless there is a reason for it to be at this place in the file 
in which case you can at least move the prototype declaration close the 
next_nomacro_spc () one.

Thanks for your patch.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] Re: using gdb 6.6 on linux fail after dec18 2013

2015-01-04 Thread Thomas Preud'homme

Le dimanche 4 janvier 2015, 08:10:40 Sergey Korshunoff a écrit :
 Return back a grischka patch which lost after
 Split elf_output_file in smaller functions
 
 Author: grischka grischka
 Date:   Tue Feb 5 21:18:29 2013 +0100
 tccelf: fix debug section relocation
 With:
tcc -g hello.c
gdb a.out
  b main
 gdb refused to know main because of broken dwarf info.

I don't understand. The commit you mention 
(92024ab07ad8e1c4a05f90add3d3ca7932251016) contains the exact opposite patch. 
Also the patch I wrote to split elf_output_file in several functions didn't 
change this line. I quote the rest of the commit message:

This partially reverts commit 0d598aca087e46ea67f97dda50df3eed522d5e7a.
I don't remember what the problem was but it was the wrong way to fix it.

So before we revert the revert it would be nice to have an explanation of why 
this is necessary. By this I mean an analysis of what's happening, not just 
it works after I revert.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] Re: using gdb 6.6 on linux fail after dec18 2013

2015-01-04 Thread Thomas Preud'homme

Le dimanche 4 janvier 2015, 11:04:22 Sergey Korshunoff a écrit :
 A patch is applied to solve this bug.

Hi Sergey,

Shouldn't file-line_num be passed as the last parameter of put_stabs?

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] pp-defines

2015-01-04 Thread Thomas Preud'homme

Le dimanche 4 janvier 2015, 07:53:44 Sergey Korshunoff a écrit :
  This patch seems unnecessary as tcc_define_symbol with a third argument
  NULL is equivalent as setting it to 1 (#define FOO is the same as #define
  FOO 1)
 I trying  to be exactly the same as gcc.  And this macros in gcc are
 as 1 not 

Do you have an example of where this difference matters? For all purpose 
#define 
FOO 1 and #define FOO should be identical.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH 4/4] tcc.[ch]: Adjust code style.

Le jeudi 27 novembre 2014, 11:44:31 Lee Duhem a écrit :
 On Wed, Nov 26, 2014 at 7:54 PM, David Mertens dcmertens.p...@gmail.com 
wrote:
  As for the order of value checking, I do not think this is a good idea.
  These are classic Yoda Conditions and they should be kept that way to
  encourage the practice, in my opinion.
 
 I am fine with both of these styles, as long as one of them is adopted
 consistently. Mixing them up randomly just too bad for my eyes.

Agreed.

 
 It looks like the existing code already chose `var == const` style, I think
 we should stick to it. If we decide to change to another style, that change
 should be made globally.

var == const is by far the most used construct I've seen in all the code I 
looked at and in tcc in particular. It also feel more natural, at least for 
French and English readers: If the value of var is const. That said I like 
the fact that this construct prevent a common mistake in C. I guess it's 
possible to use this construct when coding and then reversing the order at 
commit time (commit hook?) if one wants to use it. I'd be in favor of keeping 
the status quo to avoid a lot of code change but if others feel otherwise I 
don't mind changing.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] pp should interpret #num as #line num

Le samedi 27 décembre 2014, 15:29:53 Sergey Korshunoff a écrit :
 A preprocessor should Interpret an input line
 # NUM FILENAME
 like
 #line NUM FILENAME
 
 A cpp from gcc do this.  A test case:
  tcc -E tccasm.c -o tccasm.i
  tcc -E tccasm.i -o tccasm.ii
 
 After a patch the line numbers in tccasm.ii are the same  as in tccasm.i

@@ -1624,7 +1627,11 @@
 }
 break;
 case TOK_LINE:
-next();
+case TOK_PPNUM:
+   if (tok == TOK_LINE)
+   next();
+   else
+   parse_number((char *)tokc.cstr-data);
 if (tok != TOK_CINT)
 tcc_error(#line);
 file-line_num = tokc.i - 1; /* the line number will be incremented 
after */

There is already all the logic to parse the line number after the next 
(obviously since otherwise TOK_LINE parsing would not be working). So I don't 
think there is any else statement needed. If you think parse_number is more 
appropriate than the current adhoc parsing please justify *and* use it for 
both cases.

Best regards,

Thomas

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

Re: [Tinycc-devel] FreeBSD compilation issues

Le mercredi 5 novembre 2014, 17:16:49 David Mertens a écrit :
 Hey everyone,
 
 I've had a bug filed against the tcc built using my Perl Alien::TinyCC
 package https://github.com/run4flat/Alien-TinyCC/issues/8. The poster
 claims that tcc cannot build viable executables on FreeBSD. I'm not a
 FreeBSD user and wouldn't know where to start, but I thought that tcc was
 supposed to build a viable executable on BSDs.

I've noticed this problem in Debian as well. I'm not sure it ever worked as 
before all the tcc testsuite was using tcc -run which works for FreeBSD and 
I'm not sure the lack of bugreport so far means anything except that nobody is 
using it on Debian/kFreeBSD.

If any tcc users on *BSD systems is reading this: we would welcome any patch 
to fix the problem.

Best regards,

Thomas

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

Re: [Tinycc-devel] TCC as default compiler

Le mardi 9 décembre 2014, 14:03:10 stephen Turner a écrit :
 I compiled musl-libc with gcc as well as tcc. Tcc appears to be in good
 working order but when i use tcc to compile musl-libc it errors out.
 
 The command im using is CC=/path/to/tcc ./configure --prefix=/dest/folder
 --target=i386-linux-musl
 
 the error i receive is crt/i386/Scrt1.s:17: error: bad expression syntax [[]

It appears you hit one of the many bugs tcc has in its assembly parser. 
Improvement to that part of tcc are welcome but beware, there lies dragons ;-)

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] Fix parsing of binary floating point number

Le lundi 15 décembre 2014, 16:47:06 Lee Duhem a écrit :
 Hi,
 
 It looks like tcc cannot parse binary floating number currently. This
 patch fixes
 that and also add some test cases for this problem.

I know that the above comment already says it but it would have been nice to 
add a comment /* b == 2 */ in front of the else keyword. I leave it up to you 
whether it warrants a new commit or not.

Thanks for the fix.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] pp-defines 2/x

Le samedi 3 janvier 2015, 05:25:06 Sergey Korshunoff a écrit :
 On linux we continue trying to be like a gcc v2.6.9 (not a
 __STDC_VERSION__=199901L  compiler by default)  limits.h is taken from
 a gcc compiler.

What is the license of the file you copied from GCC? The contents seems close 
to what's in the system limits.h. I'm also not sure about the intptr_t, why is 
it only defined for non Linux systems?

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH 3/4] Makefile: Add rules to create tags and TAGS.

Le mercredi 26 novembre 2014, 16:06:14 Lee Duhem a écrit :
 Hi,
 
 This patch adds rules to create and remove tags files.

Hi Lee,

Sorry for the delay but why not use etags rather than ctags -e to create the 
TAGS file?

Best regards,

Thomas

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

Re: [Tinycc-devel] libtcc.dll on win32 issues

Le lundi 3 novembre 2014, 14:34:16 James Buren a écrit :
 If this library is dynamically loaded when compiled with recent MinGW
 environments, it causes the host process to crash when it exits. It seems
 to happen with any dll compiled with gcc if libgcc.so is linked to it
 dynamically. The only known workaround I know of is to link with the
 -static-libgcc flag. I'm not sure how this should be patched into the build
 environment if I were to try to send this to upstream. Thoughts?

This looks like a GCC bug then so you should report it to GCC community 
instead. Unless there is a good reason for GCC to do this.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] Don't break compilation process with unknow option

Le samedi 27 décembre 2014, 17:02:03 Sergey Korshunoff a écrit :
 # ./tcc -Wunsupported -traditional -E tcc.c -o tcc.i
 tcc: error: invalid option -- '-traditional'
 
 Don't break compilation process with unknow option  (-traditional for
 example). There is a warning label for such case.

GCC and clang also error out for unknown option. What option caused your 
program to fail to compile?

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] preprocess all files from a command line with a -E switch

Le samedi 27 décembre 2014, 16:19:04 Sergey Korshunoff a écrit :
 Don't drop a preprocessor defines when tcc going to preprocess a next
 file in the same pass like
 tcc -E one.c two.c three.c -o combined.i
 
 Currently tcc don't handle such case. The new behavior is better then
 the current one. After a patch it is possible to compile combined.i
 in case:
 
 * include files are properly protected by
 #ifndef MY_INCLUDE_H
 #define MY_INCLUDE_H
   extern void func();
 #endif
 * there is no incompatible declarations for the same name in *.c
 
 An archive for a test purpose is included

Sorry but I'm not sure I like this functionality. When gcc compiles several .c 
files they are compiled independently: macro are not kept accross files. Doing 
this only for -E flag would make it not very consistent. Also I don't like the 
shape of the patch: initialization of the preprocessing should be split out of 
the function but anyway that is not worth discussing further given previous 
point.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] add .i extension as alias for .c file extension

Le samedi 27 décembre 2014, 17:56:26 Sergey Korshunoff a écrit :
 Add a .i extension as alias for .c:  GCC and file extensions
 .i  C source code which should not be preprocessed.
 
 Before a patch:
 # ./tcc -E tccasm.c -o tccasm.i
 # ./tcc -c tccasm.i -o tccasm.o
 tccasm.i:1: error: unrecognized file type

Looks good, please proceed.

Best regards,

Thomas

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

Re: [Tinycc-devel] crt1.c revision

Le mardi 30 décembre 2014, 14:34:56 z_axis a écrit :
 $uname -a
 FreeBSD mybsd.zsoft.com 9.3-RELEASE-p5 FreeBSD 9.3-RELEASE-p5 #0: Mon Nov  3
 22:02:57 UTC 2014
 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
 
 $head bin/wmi.c
 #!/home/sw2wolf/tcc/bin/tcc -run
 #include stdlib.h
 #include stdio.h
 #include signal.h
 #include unistd.h
 
 /* #define __aligned(N) __attribute__ ((aligned (N))) */
 
 $bin/wmi.c
 In file included from bin/wmi.c:3:
 /usr/include/stdio.h:63: error: ';' expected (got va_list)

Did this error start with the commit 77ef3b2929094da36817ce15ac4445d736e5b7da 
? It seems unrelated at first look.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] allow to tell a target ARCH to a configure script

Le mardi 30 décembre 2014, 11:05:15 Sergey Korshunoff a écrit :
 Problem: configure in 32bit userspace running on 64bit kernel is
 trying to compile tcc for ARCH=x86_64. Expecting behavior: to
 configure a tcc for ARCH=x86
 
 This patch will allow to specify/configure a target cpu. Examples:
   ARCH=x86 ./configure
   ARCH=x86_64 ./configure
 
 If ARCH is not specified then try to detect a current cpu type by
 examining arch of the host_cc.

The principle is nice but the code style looks different from the rest and a 
bit complicated for what it is. Why using a subscript for instance? Why not 
nesting if?

Finally, you could instead of using readelf use a carefully crafted conftest 
that would give you whether userspace is 32bit of 64bit. The structure would 
then look like this:

if ARCH is defined, then use it
else use uname

if cpu is x86_64 and conftest gives 32bit, cpu=i386.

What do you think?

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] add a gcc preprocessor -P directive

Le mardi 30 décembre 2014, 18:40:14 Sergey Korshunoff a écrit :
 tcc -E -P
   Added a gcc preprocessor option -P. If given then there is
   no #line directive in preprocessor output.
 
 tcc -E -P1
   don't follow a gcc preprocessor style and do output a standard
   #line directive. In such case we don't lose a location info when
   we going to compile a resulting file wtith a compiler not
   understanding a gnu style line info.

diff -urN tinycc.old/libtcc.c tinycc/libtcc.c
--- tinycc.old/tcc.h2014-12-30 17:57:24.0 +0300
+++ tinycc/tcc.h2014-12-30 17:46:01.0 +0300
@@ -645,6 +645,7 @@
 
 /* output file for preprocessing (-E) */
 FILE *ppfp;
+int  Pflag; /* if true, no #line directive in preprocessor output */
 
 /* for -MD/-MF: collected dependencies for this compilation */
 char **target_deps;

The code below shows that Pflag may have 3 values so the comment should reflect 
that. Did you call it Pflag with the idea that it could be used to encode 
something else later? If yes, you should use its value with a 0x3 mask. If 
not, better rename it to something that shows it's about the line macro like 
int line_macro_style or something better.
 
diff -urN tinycc.old/tccpp.c tinycc/tccpp.c
--- tinycc.old/tccpp.c  2014-12-30 17:57:24.0 +0300
+++ tinycc/tccpp.c  2014-12-30 18:19:40.0 +0300
@@ -3184,7 +3184,15 @@
   : 
   ;
 iptr = iptr_new;
-fprintf(s1-ppfp, # %d \%s\%s\n, file-line_num, file-
filename, s);
+   if (tcc_state-Pflag == 0)
+   fprintf(s1-ppfp, # %d \%s\%s\n, file-line_num, file-
filename, s);
+   else
+   if (tcc_state-Pflag == 1)
+   ; /* tcc -E -P case: don't output a line directive */
+   else
+   if (tcc_state-Pflag == 2)
+   fprintf(s1-ppfp, # line %d \%s\\n, file-line_num, 
file-
filename);
+   /* tcc -E -P1 case */
 } else {
 while (d)
 fputs(\n, s1-ppfp), --d;

Better use a switch case here. By the way, when doing a switch made of it 
statement it's traditional to put the if right after the else like this:

if (condition1)
  foo;
else if (condition2)
  bar;
else
  baz;

Also why not define a union for that flag, it would read better to see if 
(tcc_stage-Pflag == LINE_MACRO_NONE) or the same with 
LINE_MACRO_GCC/LINE_MACRO_STD? Well, I leave that one up to you.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] pp table_ident freeing

Le jeudi 1 janvier 2015, 14:17:10 Sergey Korshunoff a écrit :
 Free a memory allocted to identifiers table in the previous call to
 the preprocess_new() function.  Do the same when calling
 tcc_preprocess(0)

diff -urN tinycc.old/tccpp.c tinycc/tccpp.c
--- tinycc.old/tccpp.c  2014-12-30 18:33:52.0 +0300
+++ tinycc/tccpp.c  2015-01-01 14:01:36.0 +0300
@@ -3111,6 +3111,8 @@
 isidnum_table[i-CH_EOF] = isid(i) || isnum(i);
 
 /* add all tokens */
+if (table_ident)
+   tcc_free (table_ident);
 table_ident = NULL;
 memset(hash_ident, 0, TOK_HASH_SIZE * sizeof(TokenSym *));
 
The free should be done by calling tcc_cleanup. Also the if is useless as free 
does nothing if its parameter is NULL.

Could you post a testcase of the problem you are encountering? That would help 
me understand why this patch is necessary.

Best regards,

Thomas

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

Re: [Tinycc-devel] tcc don't know a setcb -- x86 assembler command

Le vendredi 2 janvier 2015, 20:21:08 Sergey Korshunoff a écrit :
 Hi! Do anyone know how to learn a tcc to recognize a setcb assembler
 command? There are some in glibc header, __FD_ISSET() macro for
 example.

Take a look into i386-asm.h

Unfortunately I won't be able to help you much with assembly parsing code in 
tcc as I didn't play much with it so far but I'll do my best if you have any 
question.

best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] pp-defines

Le vendredi 2 janvier 2015, 15:53:39 Sergey Korshunoff a écrit :
 A values for
 __STDC__, __STDC_VERSION__, __STDC_HOSTED__
 on the Linux are defined as in gcc.

Hi Sergey,

This patch seems unnecessary as tcc_define_symbol with a third argument NULL is 
equivalent as setting it to 1 (#define FOO is the same as #define FOO 1).

See for yourself:

% cat ~/foo.c
int foo = __STDC__;
% tcc -E ~/foo.c
# 1 /home/foo/foo.c
int foo = 1;

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] pp-defines 3/x

Le samedi 3 janvier 2015, 07:00:41 Sergey Korshunoff a écrit :
 round() in tests (24_math_library) fail because there are no defs
 included.gcc complain but work right and tcc simply fail to compile
 right.

Thanks for the patch, please commit it.

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] warn about conflicting options on the command line like -E, -c, -run, -shared

Le samedi 3 janvier 2015, 10:30:08 Sergey Korshunoff a écrit :
 Warn about a conflicting compile options spectified on the command line

Thanks for the patch. Looks good to me.

Best regards,

Thomas

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

Re: [Tinycc-devel] How to use char \

2014-09-30 Thread Thomas Preud'homme

Le mardi 30 septembre 2014, 11:56:43 JFC Morfin a écrit :
 May be not the right place to ask?

It's ok but you should have created a new mail instead of replying to an email 
and changing the subject.

 I am trying to port my old bcc32 libraries under tcc.
 
 I have a problem with the char \. For example in the line:
 
 strpbrk (file_name,\*?)
 
 ir order to know if i have a simple file name, tcc tells me unknown
 escape sequence.

The manpage doesn't say that the strings accept escape sequence. Is it even 
defined in the standard? Sounds like a bug in TinyCC.

 
 When I want use as a char both text[i]='\' and text[i]='\\' do not
 work. Since I am there working on text strings I cannot equate '\' to
 ascii 28 first.

'\' should be correct. What is the error you get?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] How to build a static executable ?

2014-09-29 Thread Thomas Preud'homme

Le lundi 29 septembre 2014, 13:39:27 Issam Anour a écrit :
 Hi;
 
 I didn't manage to build a simple Hello world program statically.
 
 main.c
 
 #include stdio.h
 
 int main(int argc, char* argv[]) {
 
printf(Hello world!\n);
return 0;
 }
 
 tcc -static main.c -o main
 
 output:
 
 tcc: error: undefined symbol '__rel_iplt_end'
 tcc: error: undefined symbol '__rel_iplt_start'
 tcc: error: undefined symbol '__gcc_personality_v0'
 tcc: error: undefined symbol '_Unwind_Resume'
 tcc: error: undefined symbol '_Unwind_GetIP'
 tcc: error: undefined symbol '_Unwind_GetGR'
 tcc: error: undefined symbol '_Unwind_GetCFA'
 tcc: error: undefined symbol '_Unwind_Backtrace'
 
 
 What is the issue ? i have googled and find that libgcc_eh.a is missing, but
 when i like against it using :

Static compilation of executable with tcc is sadly broken for a long time.
 
 tcc /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/libgcc_eh.a -static
 main.c -o main
 
 I get the same error.

If you want missing symbol to be resolved from this library it should be last 
on the command line. Something like:

tcc -L/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/ -static main.c -
lgcc_eh.a

 
 How to resolve the issue ? If this require to build glibc using tcc than i
 didn't manage because the errors from the configure script i already
 mentioned in a previous message.

Honnestly I doubt you can compile glibc with tcc. It probably relies on a lot 
of GCC specific behavior and anyway, the support for inline assembly in tcc is 
not complete. I think we would all welcome any patch to improve this if you 
are motivated but trying to compile glibc will likely lead to an important 
quantity of fixes.
 
 Thank you very much.
 
 Best regards

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] two fixes (was: Cannot code on TinyCC for now)

2014-09-24 Thread Thomas Preud'homme

Le mardi 23 septembre 2014, 12:37:24 grischka a écrit :
 Thomas Preud'homme wrote:
  Grischka: it would be nice to have a release now (Debian is freezing soon)
  after the issue I'm discussing with Michael is sorted out. I would have
  liked to have the two fixes Jiang is working on but he didn't reply in
  some time.
 I fixed one:
 http://repo.or.cz/w/tinycc.git/commitdiff/9d7fb3336049243a16ce20ba907946d1de
 9e1c0d

Wow, so short change. I'm not sure I understand. It seems before the 
destination would have lost its bitfield (since the gv_dup is done after). But 
you also changed gv_dup + vswap + vrott into vdup, is that just an improvement 
unrelated to the bug or it also matters?

I feel quite ashamed with all the review I gave Jiang about this to not have 
seen a simpler solution. It doesn't seem I'm close to increase the bus factor…

 
 What was the other?  (Anyway I'd leave it for someone else to try.)

http://lists.nongnu.org/archive/html/tinycc-devel/2014-08/msg00051.html

It's another instance of being able to redefined something in a local context. 
As suggested, I think this should be fixed more globally in sym_push2.

 
 --- grischka

Cheers,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Alignment issue

2014-09-24 Thread Thomas Preud'homme

Le lundi 22 septembre 2014, 07:50:33 Daniel Fiala a écrit :
 Hello.It seems that alignment in tcc is not working properly. I tried
 following program:
 
 
 #include lt;stdio.hgt;
 
 
 static float x[4] = { 1, 2, 3, 4 };
 static float y[4] __attribute__((aligned(32))) = { 4, 5, 6, 7 };
 
 
 int
 main(void) {
 fprintf(stderr, %p\n, x);
 fprintf(stderr, %p\n, y);
 
 
 return 0;
 }
 
 
 
 I compiled it with tcc 0.9.5 under Ubuntu 14.04 and I got following output:
 
 
 0x8049544
 0x8049554
 
 
 
 It looks that address is not aligned. :-(

From tcc.h:

struct Attribute {
unsigned
func_call : 3, /* calling convention (0..5), see below */
aligned   : 5, /* alignement (0..16) */
packed: 1,
func_export   : 1,
func_import   : 1,
func_args : 5,
func_proto: 1,
mode  : 4,
weak  : 1,
visibility: 2,
fill  : 8; // 8 bits left to fit well in union below
};

You get the picture I think. Aligned should probably be a separate field of 
type unsigned char (so alignment from 0 to 64 (size of most cacheline). If 
more is necessary we can bump to an unsigned short instead.

Feel free to do the change.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835445848b

2014-09-20 Thread Thomas Preud'homme

Le jeudi 18 septembre 2014, 17:46:36 Michael Matz a écrit :
 Hi,
 
 On Tue, 9 Sep 2014, Thomas Preud'homme wrote:
  1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT
  relocations but the computation you added ignore the possible addend at
  *ptr by doing a simple assignment. Is that normal? Did I miss something?
 
 This is per the ABI.  The addend for both relocations (when using REL
 form) is (and must be) always zero.  I didn't bother checking for this,
 but rather just ignored anything that was in there.

Mmmh ok, I didn't check sorry for the noise.

 
  2) When creating a GOT and PLT entry for a R_ARM_PC24, R_ARM_CALL or
  R_ARM_JUMP24 you add the offset of the PLT entry to the place being
  relocated. I'm not sure I got it right but it seems to me that the
  relocation will be processed again in relocate_section and seems the
  symbol referenced is still the target function (and not the PLT entry
  created) as the index in the r_info field of the relocation has remained
  unchanged. Also this put some relocation computation in
  build_got_entries. Why not change the initial relocation to make it
  resolve to the PLT entry.
 
 It might be that I got some of the logic wrong, though I obviously did
 check tcc on arm with itself (and IIRC gawk).  I'll need to reproduce the
 problem somewhen.  Are you positive that it was my commit that broke it?
 Hmm, or it might be that I also hit an error but somehow convinced myself
 that it was a pre-existing but possibly hidden problem.  Man, it's long
 ago :)

I'm not 100% sure no. Here are the facts:

Two builds of tcc mob were done by Debian buildd. The source is slightly 
modified to disable some tests, otherwise it's the same. The first build [1] 
succedded but didn't contain 63376d7712081c739a3e8dfe5fba396721bbe10b.
The second build [2] does contain it and failed. I looked at the relocation 
that failed (thank you for adding the relocation number in the error message) 
and checked the code. With the changes you made as part of the removal of jmp 
table the only condition that can fail now is being out of reach. I looked at 
what changed in this code recently and I found your commits.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=tccarch=armhfver=0.9.27~git20140801.14745bd-1stamp=1409978859
[2] 
https://buildd.debian.org/status/fetch.php?pkg=tccarch=armhfver=0.9.27~git20140907.87d879a-1stamp=1410110433

Now of course I did try on my Toshiba AC100 ARM laptop and the test does pass 
and given one of the two Debian build passed this lead me to believe it's a 
non deterministic error. It probably depends on where the libraries are 
loaded.

However I did look at your code and this thing seems surprising. The *offset* 
of the PLT entry is added in the place being relocated but the base of the PLT 
is never added. Also, everything seems to be already in place to handle PLT 
entries (how would it work before if it wasn't?):

1) put_got_entry
  (i) create a PLT entry
  (ii) create a new symbol in the .dynsym section whose value is the offset of 
the PLT entry from the beginning of the PLT section.
  (iii) add a relocation for the GOT (created in next step) entry to be 
relocated to the callee function location
  (iii) create a GOT entry
2) elf_output_file add the base of the PLT section to the value of the symbol 
created in dynsym at step 1(ii): see at comment relocate symbols in .dynsym 
now that final addresses are known.

At this point the symbol in dynsym refer to the PLT entry.

3) relocate_section (called via final_sections_reloc) do the relocation of the 
called function and writes there the offset between the destination (the PLT 
entry) and the place being relocated.

By the way (I also write this to myself as I always forget how this whole mess 
work), for a call to a library function put_got_entry is called from 
bind_exe_dynsyms. This function call put_got_entry for each symbols that is 
still undefined and is a function.

 
  3) I don't see any test for the type of output when deciding what type of
  relocation to add. So even when the output is in memory reloc_type will be
  JUMP_SLOT which will lead to a PLT entry being created. This seems to
  contradict the comment near the end of put_got_entry. The comment seems
  wrong as I don't see how a branch could be relocated without a PLT entry.
 I think what I wanted to convey in the comment is the following situation:
 normally with memory output (or static linking) no symbolic relocations
 whatsoever are required in the executable, because, well, everything is
 relocated from the beginning.  But the means by which that is ensured is
 itself (at least in TCCs link editor) by creating (and later processing)
 relocations.  Where it matters are indirect calls:
 
   extern void f(void);
   g() { void (*ptr)(void) = f; ptr(); }
 
 Here there will be a GOT slot allocated for 'f'.  The initialization of
 'ptr' will load from that GOT slot.  So even though direct calls to 'f'
 can

Re: [Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835445848b

2014-09-20 Thread Thomas Preud'homme

Le jeudi 18 septembre 2014, 18:13:23 Michael Matz a écrit :
 Hi,
 
 On Thu, 18 Sep 2014, Michael Matz wrote:
  Now obviously I bungled something regarding all that on ARM and will
  have to look at the details.  Let me first try to reproduce and I'll
  come back.
 
 Hmm, current git TCC works for me on ARMv7 in a qemu-simulated chroot.  I
 do have to configure with --with-libgcc (which is different from the
 debian buildlog you referenced), because my libc_nonshared.a references
 __aeabi_unwind_cpp_pr[01] .
 
 Probably I'd have to use that exact debian-based setup under qemu (my
 chroot is based on some openSUSE version), but I don't know a simple
 recipe for how.  Any help appreciated.

It might be possible to create you an account on Debian porterbox if you are 
interested. Just let me know if you are and I'll ask around.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] sizeof (long double) vs sizeof (double)

2014-09-18 Thread Thomas Preud'homme

Le dimanche 07 septembre 2014, 13:47:39 Mads a écrit :
 So basically, I should be able to get additional 2 bytes? And I suppose it
 will be stored as 12 bytes to maintain data structure alignment?

LDOUBLE_SIZE is defined to be 16 so you should have 16 bytes for long double 
(twice that of double).

 
 Reading through the code as well as changelogs, x87 is indeed implemented,
 which means I should be able to use long double with higher precision than
 double.
 Correct me if I'm wrong, but shouldn't long double precision be like that
 declared in floats.h (see below __i386__ / __x86_64__ ).
 
 (sorry for the hassle, but long double as extended precision is a necessary
 evil for me).
 
 *From include\floats.h*
 /* horrible intel long double */
 #if defined __i386__ || defined __x86_64__
 
 #define LDBL_MANT_DIG 64
 #define LDBL_DIG 18
 #define LDBL_EPSILON 1.08420217248550443401e-19L
 #define LDBL_MIN_EXP (-16381)
 #define LDBL_MIN 3.36210314311209350626e-4932L
 #define LDBL_MIN_10_EXP (-4931)
 #define LDBL_MAX_EXP 16384
 #define LDBL_MAX 1.18973149535723176502e+4932L
 #define LDBL_MAX_10_EXP 4932
 
 #else
 
 /* same as IEEE double */
 #define LDBL_MANT_DIG 53
 #define LDBL_DIG 15
 #define LDBL_EPSILON 2.2204460492503131e-16
 #define LDBL_MIN_EXP (-1021)
 #define LDBL_MIN 2.2250738585072014e-308
 #define LDBL_MIN_10_EXP (-307)
 #define LDBL_MAX_EXP 1024
 #define LDBL_MAX 1.7976931348623157e+308
 #define LDBL_MAX_10_EXP 308
 
 #endif

Except these don't seem to be used in tcc's code. It's probably for system 
headers only.

But I just tried compiling a similar testcase as yours and it gives the 
correct sizeof (16). Can you show me the output of the configure script?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] [patch] tcc reports wrong file name for static inline functions

2014-09-18 Thread Thomas Preud'homme

Le vendredi 12 septembre 2014, 17:50:08 Vadim Ushakov a écrit :
 
 The bug seems to be in decl0(). When it sees a static inline declaration,
 it _first_ reads the function body and _then_ saves the body and the file
 name in tcc_state-inline_fns.
 
 If the function is the last declaration, the parser pops the file from the
 stack after reading the function. After that, decl0() attempts to read
 file-filename and gets the name of the previous file in the stack.

Thanks for the analysis, it helps reviewing the patch.

 
 The patch is:
 
 diff --git a/tccgen.c b/tccgen.c
 index 5fd127f..f1146db 100644
 --- a/tccgen.c
 +++ b/tccgen.c
 @@ -6055,7 +6055,11 @@ static int decl0(int l, int is_for_loop_init)
  int block_level;
  struct InlineFunc *fn;
  const char *filename;
 -
 +
 +filename = file ? file-filename : ;
 +fn = tcc_malloc(sizeof *fn + strlen(filename));
 +strcpy(fn-filename, filename);
 +
  tok_str_new(func_str);
 
  block_level = 0;
 @@ -6076,9 +6080,7 @@ static int decl0(int l, int is_for_loop_init)
  }
  tok_str_add(func_str, -1);
  tok_str_add(func_str, 0);
 -filename = file ? file-filename : ;
 -fn = tcc_malloc(sizeof *fn + strlen(filename));
 -strcpy(fn-filename, filename);
 +
  fn-sym = sym;
  fn-token_str = func_str.str;
  dynarray_add((void ***)tcc_state-inline_fns,
 tcc_state-nb_inline_fns, fn);

Looks good but please add a testcase. Maybe the example you showed us? Look at 
tests in test2.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Make tries to install cross compilers

2014-09-12 Thread Thomas Preud'homme

Le mercredi 10 septembre 2014, 09:48:39 Simon Blomberg a écrit :
 Yesterday i tried to build tcc with:
 $ ./configure --prefix=../pref --cc=tcc
 
 everything worked fine until i issued
 $ make install
 and it tried to install the cross compilers which weren't built:
 ...
 install -m755 tcc x86_64-tcc i386-win32-tcc x86_64-win32-tcc arm-fpa-tcc
 arm-fpa-ld-tcc arm-vfp-tcc arm-eabi-tcc  ../pref/bin
 install: cannot stat ‘x86_64-tcc’: No such file or directory
 install: cannot stat ‘i386-win32-tcc’: No such file or directory
 install: cannot stat ‘x86_64-win32-tcc’: No such file or directory
 install: cannot stat ‘arm-fpa-tcc’: No such file or directory
 install: cannot stat ‘arm-fpa-ld-tcc’: No such file or directory
 install: cannot stat ‘arm-vfp-tcc’: No such file or directory
 install: cannot stat ‘arm-eabi-tcc’: No such file or directory
 make: *** [install] Error 1
 
 i looked through the Makfile and found this part:
 
 ifeq ($(CC),tcc)
 $(INSTALL) -m755 $(PROGS) $(PROGS_CROSS_LINK) $(bindir)
 else
 
 When i removed $(PROGS_CROSS_LINK) the installation worked fine.
 i don't know it this is a bug or if there is something strange with my setup
 but i thought i'd mention it here anyways.

Indeed, I introduced a bug. PROGS_CROSS_LINK should probably be defined a few 
lines down inside the ifdef CONFIG_CROSS. Feel free to fix it in mob and thanks 
for the report.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] Fallout from commit 01c041923474750a236da02561f0f8835445848b

2014-09-09 Thread Thomas Preud'homme

Hi Michael,

A recent upload of tcc in Debian showed a self test failure [1] due to a
failed R_ARM_PC24 relocation. The two bits with the smallest weight are 0 so
it's a problem of out of range branch.

[1]
https://buildd.debian.org/status/fetch.php?pkg=tccarch=armhfver=0.9.27%7Egit20140907.87d879a-1stamp=1410110433

The biggest change in this code was your commits to get rid of
runtime_plt_and_got so I took a closer look at it. A few things surprised me
so I wanted to ask you some questions.

1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT relocations
but the computation you added ignore the possible addend at *ptr by doing a
simple assignment. Is that normal? Did I miss something?

2) When creating a GOT and PLT entry for a R_ARM_PC24, R_ARM_CALL or
R_ARM_JUMP24 you add the offset of the PLT entry to the place being relocated.
I'm not sure I got it right but it seems to me that the relocation will be
processed again in relocate_section and seems the symbol referenced is still
the target function (and not the PLT entry created) as the index in the r_info
field of the relocation has remained unchanged. Also this put some relocation
computation in build_got_entries. Why not change the initial relocation to
make it resolve to the PLT entry.

3) I don't see any test for the type of output when deciding what type of
relocation to add. So even when the output is in memory reloc_type will be
JUMP_SLOT which will lead to a PLT entry being created. This seems to
contradict the comment near the end of put_got_entry. The comment seems wrong
as I don't see how a branch could be relocated without a PLT entry.

4) the jump table that was removed in subsequent patch was only available when
outputing to memory. But now a PLT and GOT entry is created no matter what
type of output (see 3) above).

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] sizeof (long double) vs sizeof (double)

2014-09-07 Thread Thomas Preud'homme

Le samedi 06 septembre 2014, 17:40:14 Mads a écrit :
 While I have seen similar behavior on other compilers, I interpret the
 downgrading of extended precision to double as an indication that extended
 precision is not supported (for one reason or another).
 
 To be a little more specific, I want to know if tcc does support extended
 precision like gcc does (~18 significant digits) without just downgrading
 to the double precision (15 significant digits). And if so, why that
 doesn't work for me.

$ grep define.*LDOUBLE_SIZE *-gen.c
arm-gen.c:#define LDOUBLE_SIZE  8
arm-gen.c:#define LDOUBLE_SIZE  8
c67-gen.c:#define LDOUBLE_SIZE  12
i386-gen.c:#define LDOUBLE_SIZE  12
il-gen.c:#define LDOUBLE_SIZE  8
x86_64-gen.c:#define LDOUBLE_SIZE  16

So no matter what, tcc will never give you more than 2 bytes for a long 
double.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

2014-08-31 Thread Thomas Preud'homme

Le lundi 18 août 2014, 20:39:26 jiang a écrit :
 Hi,Thomas
 

Hi Jiang,

 
 fixbitfields.patch
 Nothing bug

More than a week late sorry. Here is my review:

 commit 1c0c88408b56d0e4e36b795b7d92f25f6606988a
 Author: Jiang 30155...@qq.com
 Date:   Mon Aug 18 20:25:19 2014 +0800
 
 fix bitfields

Fix assignment to bitfield would be more precise.

 
 see:
 
 http://lists.nongnu.org/archive/html/tinycc-devel/2014-07/msg00023.html
 
 Conflicts:
   tests/tests2/03_struct.c

Remove the conflicts, there is no interest to see your private experiments in 
the commit message.

 
 diff --git a/tcc.h b/tcc.h
 index c93cedf..fb618ec 100644
 --- a/tcc.h
 +++ b/tcc.h
 @@ -1192,6 +1192,13 @@ ST_DATA int func_var; /* true if current function is 
variadic */
  ST_DATA int func_vc;
  ST_DATA int last_line_num, last_ind, func_ind; /* debug last line number 
and pc */
  ST_DATA char *funcname;
 +/* gen_ctrl */
 +enum {
 +CTRL_NONE,
 +CTRL_FOCE,
 +CTRL_INIT,

So you don't use CTRL_NONE and the use of CTRL_INIT seems wrong to me. 
Therefore just use a boolean variable like check_downcast and declare it in 
tccgen.c instead of declaring gen_ctrl.

By the way, it's not foce but force. ;)

 +};
 +ST_DATA int gen_ctrl;
  
  ST_INLN int is_float(int t);
  ST_FUNC int ieee_finite(double d);
 diff --git a/tccgen.c b/tccgen.c
 index d3d1026..e321f96 100644
 --- a/tccgen.c
 +++ b/tccgen.c
 @@ -70,6 +70,7 @@ ST_DATA int func_var; /* true if current function is 
variadic (used by return in
  ST_DATA int func_vc;
  ST_DATA int last_line_num, last_ind, func_ind; /* debug last line number 
and pc */
  ST_DATA char *funcname;
 +ST_DATA int gen_ctrl;

Here, declare check_downcast (you can use another name if you find a better 
one).

  
  ST_DATA CType char_pointer_type, func_old_type, int_type, size_type;
  
 @@ -1017,6 +1018,7 @@ ST_FUNC void lexpand_nr(void)
  }
  #endif
  
 +#ifndef TCC_TARGET_X86_64
  /* build a long long from two ints */
  static void lbuild(int t)
  {
 @@ -1025,6 +1027,7 @@ static void lbuild(int t)
  vtop[-1].type.t = t;
  vpop();
  }
 +#endif
  
  /* rotate n first stack elements to the bottom 
 I1 ... In - I2 ... In I1 [top is right]

Mmmh, you fix several issues together. It's ok here because your patch is 
already big anyway and it's related but try to do these in separate patch next 
time.

 @@ -1087,7 +1090,8 @@ static void gv_dup(void)
  int rc, t, r, r1;
  SValue sv;
  
 -t = vtop-type.t;
 +#ifndef TCC_TARGET_X86_64
 +t = VT_INT;
  if ((t  VT_BTYPE) == VT_LLONG) {
  lexpand();
  gv_dup();
 @@ -1097,15 +1101,16 @@ static void gv_dup(void)
  vrotb(4);
  /* stack: H L L1 H1 */
  lbuild(t);
 -vrotb(3);
 -vrotb(3);
 +vrott(3);
  vswap();
  lbuild(t);
  vswap();
 -} else {
 +} else
 +#else
 +t = vtop-type.t;
 +#endif
 +{
  /* duplicate value */
 -rc = RC_INT;
 -sv.type.t = VT_INT;
  if (is_float(t)) {
  rc = RC_FLOAT;
  #ifdef TCC_TARGET_X86_64
 @@ -1113,8 +1118,9 @@ static void gv_dup(void)
  rc = RC_ST0;
  }
  #endif
 -sv.type.t = t;
 -}
 +}else
 +rc = RC_INT;
 +sv.type.t = t;
  r = gv(rc);
  r1 = get_reg(rc);
  sv.r = r;

Rather than doing all this, it would be better to guard the if (... VT_LLONG) 
by that conditional, like is done in gv () after the line r = get_reg(rc); 
to check against VT_QLONG or VT_LLONG.

Note: it would be nice to remove all these conditionals and replace by 
appropriate 
macro in the backends one day.


***

Let's do a first pause now. I reviewed your patch completely but when I arrived 
at vstore () I wondered if gen_cast is the right place to deal with store in a 
bitfield. In C there is no way to cast explicitely to a bitfield. It's only 
done 
implicitely when doing a store. And then I realized when reading init_putv 
that the initialization doesn't go through vstore which might be the reason to 
do this in gen_cast. Is it because of initialization that you deal with 
bitfield in gen_cast? Can you point me to where is the cast done in the 
initialization?

If it's not this, don't read further as my review only makes sense if checking 
for bitfield in gen_cast is the right approach.

***


 @@ -1909,8 +1915,11 @@ static void force_charshort_cast(int t)
  /* cast 'vtop' to 'type'. Casting to bitfields is forbidden. */
  static void gen_cast(CType *type)
  {
 -int sbt, dbt, sf, df, c, p;
 +int sbt, dbt, dt, sf, df, c, p, bitfield;
 +CType dtype;
  
 +dtype = *type;
 +bitfield = dtype.t  VT_BITFIELD;

Naming is better, thanks. :)

Three things can be improved:

1) I'm not convince about the need for dtype (See below). I don't mind you to 
rename the type parameter to dtype to make it more clear what type we are

Re: [Tinycc-devel] tcc grammar problems

2014-08-30 Thread Thomas Preud'homme

Le lundi 18 août 2014, 20:39:26 jiang a écrit :
 Hi,Thomas
 

Hi Jiang,

 
 fixbitfields.patch
 Nothing bug

Just a quick mail to say that I started to review this but unlike last time 
I'll only send the email when I'll have completely reviewed it as it seems to 
have puzzled you a bit (and I understand).

Good news is that this time I didn't start tired and thus noticed several 
things I failed to notice last time. I also found some better ideas on how to 
improve your patch. I'll try to finish reviewing it tomorrow if I can.

Cheers,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

2014-08-21 Thread Thomas Preud'homme

Le mardi 19 août 2014, 21:28:52 Thomas Preud'homme a écrit :
 
 Ok, I'll take a look at this one later this week.

Sorry, I wanted to do it today but it's already too late. Maybe this WE 
otherwise next week.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Problem to compile with visual studio 2010 project

2014-08-21 Thread Thomas Preud'homme

Le jeudi 21 août 2014, 08:04:56 Mohamed Rezgui a écrit :
 Dear Sir,
 
 I have an issue,
 I cannot compile with visual studio 2010 project generated by CMakeList
 with the last revision on git repository
 
 = LINK : fatal error LNK1104: cannot open file 'Debug\tcc.lib'

Can you give us some more complete log? Can you enable a verbose run?

Note that I can't promise to find the problem as I don't know CMake but I can 
take a look.

Cheers,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

2014-08-19 Thread Thomas Preud'homme

Le lundi 18 août 2014, 20:39:26 jiang a écrit :
 Hi,Thomas
 
 fixstruct.patch
 Let tcc compile yasm software

 commit 0c67ef96bc161927ea6562f6ba0fa3578132de38
 Author: Jiang 30155...@qq.com
 Date:   Mon Aug 18 19:38:23 2014 +0800
 
 Let the following be compiled:
 
 struct buffered_lines_head {
 int *slh_first;
 };
 
 static int eval_rept()
 {
 struct buffered_lines_head {
 int *slh_first;
 } lines;
 return 0;
 }
 
 int main()
 {
 struct buffered_lines_head ppp;
 ppp.slh_first = 0;
 return 0;
 }

The main is useless here. The bug can already be reproduced with just the first 
2 elements.

 
 diff --git a/tccgen.c b/tccgen.c
 index 5fd127f..639ad64 100644
 --- a/tccgen.c
 +++ b/tccgen.c
 @@ -317,7 +317,7 @@ static void apply_visibility(Sym *sym, CType *type)
  ElfW(Sym) *esym;
  
  esym = ((ElfW(Sym) *)symtab_section-data)[sym-c];
 - vis = VT_VIS_SHIFT;
 +vis = VT_VIS_SHIFT;
  esym-st_other = (esym-st_other  ~ELFW(ST_VISIBILITY)(-1)) | vis;
  }
  }

Spurious change. Please remove.


 @@ -2851,15 +2851,17 @@ static void struct_decl(CType *type, int u, int 
tdef)
  /* we put an undefined size for struct/union */
  s = sym_push(v | SYM_STRUCT, type1, 0, -1);
  s-r = 0; /* default alignment is zero as gcc */
 -/* put struct/union/enum name in type */
   do_decl:
 -type-t = u;
 -type-ref = s;
 -
  if (tok == '{') {
 +if (s-c != -1){
 +if(local_stack){
 +s = sym_push(v | SYM_STRUCT, type1, 0, -1);
 +s-r = 0; /* default alignment is zero as gcc */
 +}else{
 +tcc_error(struct/union/enum already defined);
 +}
 +}
  next();
 -if (s-c != -1)
 -tcc_error(struct/union/enum already defined);

Why so much reordering? Only the extra if should be added and only to guard 
against tcc_error (that is the then clause is the tcc_error and there is no 
else clause). Also you should check its position against scope_stack_bottom.

Basically you should forbid a definition of a structure with the same name in 
the same scope but authorize it in a more nested scope. I know, I forgot to do 
this myself in 3e56584223a67a6c2f41a43cf38e0960e9992238. I wonder if this 
should not be done in sym_push2 instead. I cannot think of something that 
could be defined locally but not redefined in inner scopes. This would benefit 
lots of places instead of just struct.

  /* cannot be empty */
  c = 0;
  /* non empty enums are not allowed */
 @@ -2900,9 +2902,9 @@ static void struct_decl(CType *type, int u, int tdef)
  while (tok != '}') {
  parse_btype(btype, ad);
  while (1) {
 - if (flexible)
 - tcc_error(flexible array member '%s' not at the end of 
struct,
 -  get_tok_str(v, NULL));
 +if (flexible)
 +tcc_error(flexible array member '%s' not at the end 
of struct,
 +get_tok_str(v, NULL));
  bit_size = -1;
  v = 0;
  type1 = btype;

Spurious change, remove it.

 @@ -3035,6 +3037,9 @@ static void struct_decl(CType *type, int u, int tdef)
  s-r = maxalign;
  }
  }
 +/* put struct/union/enum name in type */
 +type-t = u;
 +type-ref = s;
  }

Why move this from the top of the function to the end?

  
  /* return 1 if basic type is a type size (short, long, long long) */
 @@ -5704,12 +5709,12 @@ static void decl_initializer_alloc(CType *type, 
AttributeDef *ad, int r,
  } else {
  /* push global reference */
  sym = get_sym_ref(type, sec, addr, size);
 - vpushsym(type, sym);
 +vpushsym(type, sym);
  }
  /* patch symbol weakness */
  if (type-t  VT_WEAK)
  weaken_symbol(sym);
 - apply_visibility(sym, type);
 +apply_visibility(sym, type);
  #ifdef CONFIG_TCC_BCHECK
  /* handles bounds now because the symbol must be defined
 before for the relocation */

Spurious change, remove them.

 @@ -6027,10 +6032,10 @@ static int decl0(int l, int is_for_loop_init)
  if (sym-type.t  VT_STATIC)
  type.t = (type.t  ~VT_EXTERN) | VT_STATIC;
  
 - /* If the definition has no visibility use the
 -one from prototype.  */
 - if (! (type.t  VT_VIS_MASK))
 - type.t |= sym-type.t  VT_VIS_MASK;
 +/* If the definition has no visibility use the
 +   one from prototype.  */
 +if (! (type.t  VT_VIS_MASK))
 +type.t |= sym-type.t  VT_VIS_MASK;

Re: [Tinycc-devel] tcc grammar problems

2014-08-13 Thread Thomas Preud'homme

Le lundi 11 août 2014, 00:39:17 jiang a écrit :
 
 +/* gen_ctrl */
 +enum {
 +CTRL_NONE,
 +CTRL_CALL,
 +CTRL_FOCE,
 +CTRL_ARGS,
 +CTRL_RETS,
 +CTRL_INIT,
 +CTRL_USED,
 +};
 +ST_DATA int gen_ctrl;
 
 
 This is  one of my  local branch  code,  want to join the  mob  after

Alright, I don't really want to see your local branch as long as it's not 
ready. Just remove the unused enum for now and add them later in the patches 
that add the pieces you are still working on.

  
  Why this vtop  (vstack + 1)? What's so special about a stack with 3
  entries or more? It looks fishy.
 
 For example  the following expression:
 a = b = c; - (a = (b = c));
 Requires  three  SValue,  will  be greater than  vstack + 1, ret  equal to
 1. Return  right  value
 
 a = b
 Less than or equal  vstack + 1, ret  equal to  0.
 Does not return  the right  value
 
 Generate  less  machine code

Maybe but that seems wrong. Why not have some code for when you have 3 
assignments? It's inelegant as it is now.

You should only deal with one assignment at a time so 2 Svalue. In the first 
example you give, it means dealing with b = c, then return the Svalue that 
correspond to it and then process the a = result assignment that has only 2 
Svalue. Improving the right way would mean not generating the code right away 
and doing a pass after that.

The final result of your patch should be quite small. If not, either I 
underestimate the difficulty of this bug fix (it's quite possible) or you 
overcomplicated things.

Cheers,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

2014-08-10 Thread Thomas Preud'homme

Le samedi 09 août 2014, 11:49:50 jiang a écrit :
 These days I'm going to worship. Few days and then a detailed reply to you.
 This is my latest Review: Please see the attachment.
   fixbitfields.patch
 By testing the software: tcc gnumake binutils-2.24

I didn't look at the patch yet but I still see the control structure with lots 
of enumerator unused. What happen to my comments about this?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

2014-08-08 Thread Thomas Preud'homme

Le mercredi 06 août 2014, 22:41:18 Thomas Preud'homme a écrit :

[SNIP review part 2]

And here is the final part (part 3)

@@ -3605,7 +3643,7 @@ static void vpush_tokc(int t)
 
 ST_FUNC void unary(void)
 {
-int n, t, align, size, r, sizeof_caller;
+int n, t, align, size, r, sizeof_caller, save_ctrl;
 CType type;
 Sym *s;
 AttributeDef ad;
@@ -3714,7 +3752,10 @@ ST_FUNC void unary(void)
 return;
 }
 unary();
+save_ctrl = gen_ctrl;
+gen_ctrl = CTRL_FOCE;
 gen_cast(type);
+gen_ctrl = save_ctrl;


I think it would be better to add a parameter explicit of type bool to 
gen_cast(). CTRL_INIT looks weird and you only need to know if it's an 
implicit cast or not.


 }
 } else if (tok == '{') {
 /* save all registers */
@@ -5127,7 +5168,7 @@ static void decl_designator(CType *type, Section *sec, 
unsigned long c,
 static void init_putv(CType *type, Section *sec, unsigned long c, 
   int v, int expr_type)
 {
-int saved_global_expr, bt, bit_pos, bit_size;
+int saved_global_expr, bt, bit_pos, bit_size, save_ctrl;
 void *ptr;
 unsigned long long bit_mask;
 CType dtype;
@@ -5147,7 +5188,10 @@ static void init_putv(CType *type, Section *sec, 
unsigned long c,
 tcc_error(initializer element is not constant);
 break;
 case EXPR_ANY:
+save_ctrl = gen_ctrl;
+gen_ctrl = CTRL_INIT;
 expr_eq();
+gen_ctrl = save_ctrl;
 break;
 }


I don't see why this is needed. The code you moved in vstore() didn't need it 
before.
 

diff --git a/tests/tests2/03_struct.c b/tests/tests2/03_struct.c
index c5d48c5..e06d20d 100644
--- a/tests/tests2/03_struct.c
+++ b/tests/tests2/03_struct.c
@@ -27,5 +27,36 @@ int main()
printf(%d\n, jones[1].boris);
printf(%d\n, jones[1].natasha);
 
+   struct sbf1 {
+int f1 : 3;
+int : 2;
+int f2 : 1;
+int : 0;
+int f3 : 5;
+int f4 : 7;
+unsigned int f5 : 7;
+   } st1;
+   st1.f1 = st1.f2 = st1.f3 = st1.f4 = st1.f5 = 3;
+   printf(%d %d %d %d %d\n,
+ st1.f1, st1.f2, st1.f3, st1.f4, st1.f5);
+
+   struct { unsigned a:9, b:7, c:5; } s1;
+s1.a = s1.b = s1.c = 3;
+   printf(%d / %d / %d\n, s1.a, s1.b, s1.c);
+
+   struct {
+unsigned a:9, b:5, c:7;
+   } s2, *ps = s2;
+   int n = 250;
+
+   int ii = ps-a = ps-b = ps-c = n + 4;
+   printf(%d / %d / %d\n, ps-a, ps-b, ps-c);
+   printf(%d\n, ii);
+   
+   ps-a = n + 4;
+   ps-b = n + 4;
+   ps-c = n + 4;
+   printf(%d / %d / %d\n, ps-a, ps-b, ps-c);
+
return 0;
 }
diff --git a/tests/tests2/03_struct.expect b/tests/tests2/03_struct.expect
index ecbf589..6b90186 100644
--- a/tests/tests2/03_struct.expect
+++ b/tests/tests2/03_struct.expect
@@ -1,6 +1,12 @@
+03_struct.c:39: warning: overflow in implicit constant conversion
 12
 34
 12
 34
 56
 78
+-1 -1 3 3 3
+3 / 3 / 3
+30 / 30 / 126
+30
+254 / 30 / 126


The added code in 03_struct.c don't exercise the explicit cast. Is it exercise 
somewhere else? If not you should add something for this.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

Le mardi 05 août 2014, 22:08:13 Thomas Preud'homme a écrit :
 
 +warr = 0;
 +if(bb){
 +s = 64 - ((type-t  (VT_STRUCT_SHIFT + 6)) 
 0x3f);
 
 Spacing issue again and I don't understand the + 6. The bitfield size is
 encoded from bit (1  VT_STRUCT_SHIFT) on 6 bits. So you should do:
 (type-t  VT_STRUCT_SHIFT)  0x3f (that is remove all the bits before the
 bitfield size and then only keep the 6 least significant bits.

Sorry my apologize. I forgot there is 6 bits for the position and then again 6 
bits for the size. Please ignore above remark.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

Le mardi 05 août 2014, 22:08:13 Thomas Preud'homme a écrit :
 Le vendredi 01 août 2014, 16:37:15 jiang a écrit :
  my patch:See Attachment
  You look at, if no problem, I'll push mob
 
 Ok, here is what I noticed so far:
 

[SNIP review part 1]

 
 
 Ok. I'll stop this for now and will continue to review tomorrow or the day
 after tomorrow. Wait before doing any modifications as I might have some
 more important remarks that would require a more important rewrite. However
 from what I've seen so far (the ctrl enum excepted) it seems to be going in
 the right direction.

Let's continue, shall we?

@@ -2024,67 +2058,78 @@ static void gen_cast(CType *type)


What about the else if (sf) case before that? A cast from a float to a 
bitfield 
is possible and does not seem to be handled here. Am I wrong?


 gen_cast(type);
 }
 }
+} else {
+
 #ifndef TCC_TARGET_X86_64
-} else if ((dbt  VT_BTYPE) == VT_LLONG) {
-if ((sbt  VT_BTYPE) != VT_LLONG) {
-/* scalar to long long */
-/* machine independent conversion */
-gv(RC_INT);
-/* generate high word */
-if (sbt == (VT_INT | VT_UNSIGNED)) {
-vpushi(0);
+if ((dbt  VT_BTYPE) == VT_LLONG) {
+if ((sbt  VT_BTYPE) != VT_LLONG) {
+/* scalar to long long */
+/* machine independent conversion */
 gv(RC_INT);
-} else {
-if (sbt == VT_PTR) {
-/* cast from pointer to int before we apply
-   shift operation, which pointers don't 
support*/
-gen_cast(int_type);
+/* generate high word */
+if (sbt == (VT_INT | VT_UNSIGNED)) {
+vpushi(0);
+gv(RC_INT);
+} else {
+if (sbt == VT_PTR) {
+/* cast from pointer to int before we apply
+   shift operation, which pointers don't 
support*/


You need to reformat this comment to don't go beyond 80 columns.


+gen_cast(int_type);
+}
+gv_dup();
+vpushi(31);
+gen_op(TOK_SAR);
 }
-gv_dup();
-vpushi(31);
-gen_op(TOK_SAR);
+/* patch second register */
+vtop[-1].r2 = vtop-r;
+vpop();
 }
-/* patch second register */
-vtop[-1].r2 = vtop-r;
-vpop();
 }
 #else
-} else if ((dbt  VT_BTYPE) == VT_LLONG ||
-   (dbt  VT_BTYPE) == VT_PTR ||
-   (dbt  VT_BTYPE) == VT_FUNC) {
-if ((sbt  VT_BTYPE) != VT_LLONG 
-(sbt  VT_BTYPE) != VT_PTR 
-(sbt  VT_BTYPE) != VT_FUNC) {
-/* need to convert from 32bit to 64bit */
-int r = gv(RC_INT);
-if (sbt != (VT_INT | VT_UNSIGNED)) {
-/* x86_64 specific: movslq */
-o(0x6348);
-o(0xc0 + (REG_VALUE(r)  3) + REG_VALUE(r));
+if((dbt  VT_BTYPE) == VT_LLONG || (dbt  VT_BTYPE) == VT_PTR 
||


For the same reason, you need to use a new line after the first ||.


+(dbt  VT_BTYPE) == VT_FUNC) {
+if ((sbt  VT_BTYPE) != VT_LLONG  (sbt  VT_BTYPE) != 
VT_PTR 


And again here after the first .


+(sbt  VT_BTYPE) != VT_FUNC) {
+/* need to convert from 32bit to 64bit */
+int r = gv(RC_INT);
+if (sbt != (VT_INT | VT_UNSIGNED)) {
+/* x86_64 specific: movslq */
+o(0x6348);
+o(0xc0 + (REG_VALUE(r)  3) + REG_VALUE(r));
+}
 }
 }
 #endif
-} else if (dbt == VT_BOOL) {
-/* scalar to bool */
-vpushi(0);
-gen_op(TOK_NE);
-} else if ((dbt  VT_BTYPE) == VT_BYTE || 
-   (dbt  VT_BTYPE) == VT_SHORT) {
-if (sbt == VT_PTR) {
-vtop-type.t = VT_INT;
-tcc_warning(nonportable conversion from pointer to 
char/short);
+else if (dbt == VT_BOOL) {
+/* scalar to bool

Re: [Tinycc-devel] tcc grammar problems

Le mercredi 06 août 2014, 21:10:29 jiang a écrit :
 Hi, Thomas
 My p1 patch, there is a fatal flaw, but I know it was not satisfied!
 Thank you for writing to me.

Can you be more precise? What's the fatal flaw you are talking about?

 
 But I have a patch, want to join the mob, excuse me, please review it!
 
 My patch:See Attachment

Maybe you could explain what you are trying to fix with these two patches. I'd 
suggest to give them a more meaningful name (instead of p1, p2) and I'd 
appreciate if you could include them inline in the message. When doing this 
make sure that your MUA (Mail User Agent) doesn't mangle the message, that is 
keeps the original formatting.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] asm unknown constraint 't' issue

Le mercredi 06 août 2014, 18:40:19 Roy Tam a écrit :
 Hello,
 
 2014-08-06 18:27 GMT+08:00 YX Hao lifenjoi...@163.com:
  Hi there,
  
  Here is what I found:
  
  
  math.h:341: error: unknown constraint 't'
  
  
  And more around this line.
  
  I know little about asm. Can somebody take a look at it?
 
 I have a little patch for that, someone please review it.
 Thank you.

Note that i386-asm.c is probably one of the piece of tcc I know the least (I 
think it comes second after the Windows stuff). If you are still interested in 
my review, see below.

 
 diff --git a/i386-asm.c b/i386-asm.c
 index 664aade..1a24e30 100644
 --- a/i386-asm.c
 +++ b/i386-asm.c
 @@ -1029,6 +1029,9 @@ static inline int constraint_priority(const char *str)
 case 'i':
  case 'm':
  case 'g':
 +case 'f':
 +case 't':
 +case 'u':
  pr = 4;
  break;
  default:

It would be nice if you take advantage of your patch to sort this block as 
with LC_COLLATE=C (f, i, g, m, t, u, I, N, M). I can't comment on the priority 
though, I didn't know about the priority between constraints.


 @@ -1211,6 +1214,11 @@ ST_FUNC void asm_compute_constraints(ASMOperand
 *operands,
  if (!((op-vt-r  (VT_VALMASK | VT_LVAL | VT_SYM)) ==
 VT_CONST)) goto try_next;
  break;
 +case 'f':
 +case 't':
 +case 'u':
 +/* float */
 +break;
  case 'm':
  case 'g':
  /* nothing special to do because the operand is already in

As I said I'm not a specialist of this code but it seems to me that 't' should 
do reg = TREG_ST0, then add something that says it's a float register and 
finally call goto alloc_reg. For 'u' it would be similar with TREG_ST1 but it 
doesn't exist so it probably needs to be declared. For 'f' it should be any 
float register so you should probably follow what is done for 'r' I guess.

Right now no register is allocated so a random general register will be used 
(according to what's in the stack at the address op-reg).

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

2014-08-05 Thread Thomas Preud'homme

Le vendredi 01 août 2014, 16:37:15 jiang a écrit :
 my patch:See Attachment
 You look at, if no problem, I'll push mob

Ok, here is what I noticed so far:

commit 1988c974137f3042d9c38000fda3e00779fecab3
Author: Jiang 30155...@qq.com
Date:   Fri Aug 1 16:27:58 2014 +0800

fix bitfields

see:
http://lists.nongnu.org/archive/html/tinycc-devel/2014-07/msg00023.html


Fix casts to bitfield followed by the quick testcase provided by grishka 
would be better.


diff --git a/tcc.h b/tcc.h
index c93cedf..a8cabb6 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1192,6 +1192,17 @@ ST_DATA int func_var; /* true if current function is 
variadic */
 ST_DATA int func_vc;
 ST_DATA int last_line_num, last_ind, func_ind; /* debug last line number and 
pc */
 ST_DATA char *funcname;
+/* gen_ctrl */
+enum {
+CTRL_NONE,
+CTRL_CALL,
+CTRL_FOCE,
+CTRL_ARGS,
+CTRL_RETS,
+CTRL_INIT,
+CTRL_USED,
+};
+ST_DATA int gen_ctrl;

A description of the use for each enumerator would be nice. Also, unless you 
mean something else, I think you should rename CTRL_FOCE into CTRL_FORCE. Also 
you seem to only use CTRL_FOCE and CTRL_INIT. So you should probably remove 
all the others. And why separating the kind of check? Why not just a switch 
which enables or not warnings? Please explain me why you feel the need for 
this enum.
 
 ST_INLN int is_float(int t);
 ST_FUNC int ieee_finite(double d);
diff --git a/tccgen.c b/tccgen.c
index 1a89d4a..73b759f 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -70,6 +70,7 @@ ST_DATA int func_var; /* true if current function is 
variadic (used by return in
 ST_DATA int func_vc;
 ST_DATA int last_line_num, last_ind, func_ind; /* debug last line number and 
pc */
 ST_DATA char *funcname;
+ST_DATA int gen_ctrl;
 
 ST_DATA CType char_pointer_type, func_old_type, int_type, size_type;
 
@@ -1909,8 +1910,9 @@ static void force_charshort_cast(int t)
 /* cast 'vtop' to 'type'. Casting to bitfields is forbidden. */
 static void gen_cast(CType *type)
 {
-int sbt, dbt, sf, df, c, p;
+int sbt, dbt, dt, sf, df, c, p, bb;
 
+bb = type-t  VT_BITFIELD;

Why bb for the bitfield? Maybe you could use db (destination bitfield) to 
follow the same naming convention as df (destination float). Also you should 
add it just before the c, but that's really nitpick.

I'm not sure about dt. On one hand its the real destination basic type but on 
the other hand dbt is already used.

 /* special delayed cast for char/short */
 /* XXX: in some cases (multiple cascaded casts), it may still
be incorrect */
@@ -1925,9 +1927,10 @@ static void gen_cast(CType *type)
 }
 
 dbt = type-t  (VT_BTYPE | VT_UNSIGNED);
+dt = dbt  VT_BTYPE;
 sbt = vtop-type.t  (VT_BTYPE | VT_UNSIGNED);
 
-if (sbt != dbt) {
+if (sbt != dbt || bb) {
 sf = is_float(sbt);
 df = is_float(dbt);
 c = (vtop-r  (VT_VALMASK | VT_LVAL | VT_SYM)) == VT_CONST;
@@ -1959,6 +1962,8 @@ static void gen_cast(CType *type)
 vtop-c.d = (double)vtop-c.ld;
 } else if (sf  dbt == (VT_LLONG|VT_UNSIGNED)) {
 vtop-c.ull = (unsigned long long)vtop-c.ld;
+if(bb)
+goto to_min;
 } else if (sf  dbt == VT_BOOL) {
 vtop-c.i = (vtop-c.ld != 0);
 } else {
@@ -1975,24 +1980,53 @@ static void gen_cast(CType *type)
 else if (sbt != VT_LLONG)
 vtop-c.ll = vtop-c.i;
 
-if (dbt == (VT_LLONG|VT_UNSIGNED))
+if (dbt == (VT_LLONG|VT_UNSIGNED)){
 vtop-c.ull = vtop-c.ll;
-else if (dbt == VT_BOOL)
+if(bb)
+goto to_min;
+}else if (dbt == VT_BOOL)

Spacing issue. You should have a space before '{' and after '}'

 vtop-c.i = (vtop-c.ll != 0);
 #ifdef TCC_TARGET_X86_64
 else if (dbt == VT_PTR)
 ;
 #endif
 else if (dbt != VT_LLONG) {
-int s = 0;
-if ((dbt  VT_BTYPE) == VT_BYTE)
-s = 24;
-else if ((dbt  VT_BTYPE) == VT_SHORT)
-s = 16;
-if(dbt  VT_UNSIGNED)
-vtop-c.ui = ((unsigned int)vtop-c.ll  s)  s;
-else
-vtop-c.i = ((int)vtop-c.ll  s)  s;
+unsigned long long ull;
+long long ll;
+int s, warr;

It would be better to name this variable warn.

+to_min:

Why not use the label cast_bitfield?

+warr = 0;
+if(bb){
+s = 64 - ((type-t  (VT_STRUCT_SHIFT + 6))  0x3f);

Spacing issue again and I don't understand the + 6. The bitfield size is 
encoded from bit (1  VT_STRUCT_SHIFT) on 6 bits. So you should do:
(type-t  VT_STRUCT_SHIFT)  0x3f (that is remove all the bits

Re: [Tinycc-devel] tcc grammar problems

2014-08-04 Thread Thomas Preud'homme

Le samedi 02 août 2014, 02:30:25 Sia Lang a écrit :
 On Fri, Aug 1, 2014 at 5:10 PM, jiang 30155...@qq.com wrote:
  I would like you to explain my patch.
  I vstore () in bitfield values on the right match, with gen_cast (dt) to
  achieve.
 
 [...]
 
 
 Could you please repost your explanation in english?

And could you be a bit more respectful? You could simply have said that you 
don't understand him and ask him some precision. Not everybody is a native 
english speaker or speak a language similar to english.

Regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

2014-08-04 Thread Thomas Preud'homme

Le vendredi 01 août 2014, 16:37:15 jiang a écrit :
 my patch:See Attachment
 You look at, if no problem, I'll push mob

Hi Jiang,

I wanted to tell you that I started reviewing your patch. It'll take me time 
as I don't have so much time to spend on it everyday but I hope I can finish in 
a few days only.

I started to make some note and already noted a few mistakes. I'll send you an 
email later this week.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc grammar problems

2014-07-28 Thread Thomas Preud'homme

Le dimanche 13 juillet 2014, 22:12:39 jiang a écrit :
 Hello everyone!
 
 (s-a = (s-b = (s-c = n + 4)));
 
 
 gcc  msvc:
 -- 30 / 30 / 126 // Because the return value is left
 
 
 tcc
 -- 254 / 30 / 126 // Because the return is the right value

Since it works for the last two values I don't think it's that. It simply 
looks like tcc compute n + 4 (254) and then tries to store it in each field 
independently. It's a folding issue. Tcc records 254 in a CValue associated 
with the SValue for n + 4. The problem is how this is propagated (folded) to 
the three field access.

 
 Shall tcc assignment modify what? Same with gccmsvc.

Yes, gcc and msvc are definitely right here.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Problem using alloca

2014-07-02 Thread Thomas Preud'homme

Le mardi 01 juillet 2014 10:20:12, vous avez écrit :
 Yes. Please. You can tell me the steps for be able of send commits ?

Sure but first let's discuss how to make the patch.

1) Downloading the latest development code

So first you'll need a copy of the latest code that we keep in git source code 
management tool. You can find an installer for git at [1]. Once installed, 
you'll have two programs you can use: git-bash and git-gui if I remember 
correctly.

[1] http://git-scm.com/download/

Launch git-bash and there just type: git clone git://repo.or.cz/tinycc.git

This will create a directory tinycc in which you'll find the most recent 
code.

2) Hacking

From there, you'll have to take a look at lib/alloca86_64.S and 
lib/alloca86.S. You'll notice a cmp $4096,%rax or cmp $4096,%eax whose 
goal is to compare the parameter given to alloca (rounded up to a multiple of 
16) with 4096. If it's less or equal it will continue at p2 and skip the code 
you see below. Otherwise it'll allocate 4096 bytes by substracting this amount 
to the stack pointer (esp) and then read something on the stack (the test 
instruction) and loop again at the cmp instruction.

Basically it does a loop allocating 4096 bytes at a time and trying to read 
one of these byte before continuing the loop. If there is something to do when 
allocating 8MB or more, you'll have to add another cmp just before the p1 
label to compare eax with this value and then do what needs to be done on 
Windows. For this I cannot tell, you seem to know more than me.

3) Committing in the main repo

Once the patch written, you will prepare the file for the commit with git add 
lib/alloca86.S lib/alloca86_64.S. Then you should inspect it with git diff --
cached to make sure you didn't add spurious whitespace somewhere (it will 
appear in red in git). Then if all is ok you can commit with git commit and 
enter the commit message. At this stage you have a local commit, meaning that 
only you have this commit, nobody else has it. You'll need to push this 
commit to the main repository for everybody to see it. This is done by doing a 
git push ssh://m...@repo.or.cz/srv/git/tinycc.git mob:mob that instruct to 
push everything you made on branch mob (the one automatically created when you 
issued git clone initially) on a branch mob on our main repo.

If you have an error message it means somebody else pushed some commits to the 
main repo. In this case, just do git pull --rebase and then you'll be able 
to do the push. If there is any problem, feel free to ask here, I'm sure 
you'll find an answer to your question. Note that this answer will not come 
from me as I'll be absent for two weeks from this friday.

I look forward to your contribution.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Request push

2014-07-02 Thread Thomas Preud'homme

Le mercredi 02 juillet 2014, 00:07:02 jiang a écrit :
 I'm sorry, I was remiss.
 I did not find a space with gitk.
 This is my new commit:89000c18dc7d5ccb2687948f94fe49d392990dab

That's great. Thanks. For the ;;; patch I won't be able to review for 2 
weeks as I'll be away from my computer. See if you can find someone else to 
review or else wait for my return.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] incorrect/missing license files

2014-07-01 Thread Thomas Preud'homme

Le mardi 01 juillet 2014, 06:42:09 grischka a écrit :
 
 And the author is?
 
  libtcc1.c:148:
  /* most of this code is taken from libgcc2.c from gcc */

Hum, no comment :-D

 
 Since libtcc1.c is part of a library (and tcc doesn't have LTO) I'd
 rather suggest to put everything not related to float conversion into
 its own file each.

This just made me realized I didn't put any copyright header on lib/armeabi.c.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Problem using alloca

2014-07-01 Thread Thomas Preud'homme

Le lundi 30 juin 2014 13:20:05, vous avez écrit :
 I think is a bug of tiny c.
 I use the tiny c for x86.
 The problem is that the stack overflow exception that generates alloca, is
 not catched with the function passed to SetUnhandledExceptionFilter. This
 only happen with the executable created with tiny c. When I compile the
 executable with mingw. The exception is catched ok.
 
 I imitate the behavior with malloc, if the allocation fails, I set the
 pointer to NULL.
 I use MAX_INT intentionally for provocate the exception.

Ok, sorry I didn't understand this was made on purpose. When you report a bug, 
it's a good idea to give the expected result with the testcase.

About the bug in itself I'm not familiar with Windows so do you know how to 
generate such an exception? If yes I can guide you as to where modify tcc's 
code and you could make your first commit to tcc :) How does that sound?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] isxdigit conversion inconsistency with widechar

2014-07-01 Thread Thomas Preud'homme

Le lundi 30 juin 2014, 15:03:35 Carlos Montiers a écrit :
 
 Yes. It is not a bug. But, I post this for the knowledge. I inspect
 mscvrt.dll and isxdigit internally call to _isctype. Then I think is more
 speedy call directly to _isctype instead of isxdigit. But the current macro
 of tiny c not call to it like the counterpart iswxdigit. Because it I post
 my little fix:
 
 #undefisxdigit
 #undefiswxdigit
 #defineisxdigit(d)  _isctype(d, _HEX)
 #defineiswxdigit(d)iswctype(d, _HEX)

If you can provide number that shows it's indeed slower then it is indeed a 
bug and someone might fix it someday. Else I doubt somebody will feel motivated 
enough to change this (I might be wrong).

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Problem using alloca

2014-06-30 Thread Thomas Preud'homme

Le dimanche 29 juin 2014, 21:38:33 Carlos Montiers a écrit :
 Hello.
 I requesting memory from the stack using the function alloca.
 I know that the use of it is discourage, but I want use it anyways.
 
 I write a code for windows that use it and I tested ok, but only when I
 compile with gcc. Compiling it with tiny c fails, the program crash.
 Maybe is a bug of tiny c.

I assume that your program is compiled on Windows 64 bits, given the alloca 
(INT_MAX). The definition of alloca for Windows 64 bits is in 
lib/alloca86_64.S. When the parameter is bigger than 4096, then it will do a 
loop that allocates 4096 bytes on the stack, read a value on the stack and 
start all over again until all the space asked is allocated. I suppose that 
the goal of the read is to make Windows actually allocate the space to avoid 
an error if a big alloca is made.

I don't know for Windows but on Linux nothing is allocated as long as nothing 
is written. So a big alloca would do nothing and then writing a bit structure 
on the stack would fail as it would make the stack grow too quickly. I guess 
that's what is happening here. Try to reduce the amount given to alloca (Try 
8192 for instance).

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Request push

Le dimanche 29 juin 2014, 12:32:57 大熊猫 a écrit :
 Thank you Thomas, I hope you agree with my request. 

Sure, as I said, provided that a testcase is added I'd be happy for you to 
commit the patch.

 I'll change it a warning message, and then add some tests, along with a push
 up! 

Great.
 
 Not follow GCC blindly. 
 I was too blind! I'm not very familiar with C99, but I think there is a lot
 to learn from GCC place!

There are two reasons for that, the first is that GCC also has bugs and the 
second is that sometimes GCC deviates from the standard, especially if you 
don't specify -std=c99 of course. In this case, the correct behavior is defined 
it section 6.10.3 in the definition of the function-like macro. It says that 
it's a left parenthesis followed by an arbitrary number of identifier. Earlier 
in the document (section 6.4.2.1) an identifier is defined and it cannot 
contain 
any parenthesis, only digit, letters from in the range a-zA-Z, underscore 
('_') and universal character (basically non ascii character with no ambiguity 
with any of those used in the language).
 
 jiang
 
I'll push a patch.

Please post the result before and I'll happily give you green light.

Eventually, after a certain number of good patches you will be welcome to 
commit directly.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] To document -l option clearer

Le dimanche 29 juin 2014, 04:56:59 YX Hao a écrit :
 Hi,
 
 Usage: tcc [options...] [-o outfile] [-c] infile(s)...
 
 Is -l option must follow the infile(s)? Yes! I tried different positions.
 Before, undefined symbol error; behind, ok. Because of I had forgotten
 it. Usually, a library is appended by reviewing.
 
 I searched and found the reason out. A linker only adds the undefined
 symbols that the (previous) existing program codes need.

Indeed, it works this way in all compilers. The advantage is that a library is 
not pulled in if none of its symbol is used.

 
 It is a trick that experienced one knows (usage format from gcc). If the
 usage is organized in a clearer way, it may be better. How to do it simple
 and clear?

I don't think usage can renders this appropriately. After all it can be put 
anywhere, it's just that its position matters. The manual should mention it 
though, as is done in GCC:

It makes a difference where in the command you write this option; the linker 
searches and processes libraries and object files in the order they are 
specified.  Thus, foo.o -lz bar.o searches library z after file foo.o but 
before 
bar.o.  If bar.o refers to functions in z, those functions may not be loaded.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] State of the tcc project

Le dimanche 01 juin 2014, 00:04:27 mobi phil a écrit :
   Why tinyCC didn't use a hierarchical code review, with people who
  
  follows the project and have a good overview (Thomas Preud'homme,
  grischka, Daniel Glöckner for ARM) ?
  
  Thanks,
 
 I also got dizzy by those useless patches.
 
 Also got lost if the patches related to global variables were/are going to
 be integrated?

What patch related to global variables? What was it about?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Why missing #includes don't cause warning/fail?

Le samedi 31 mai 2014, 16:27:32 David Mertens a écrit :
 I have encountered this behavior before as well. I am pretty sure that the
 compiler is making a guess as to the form of the function based on how it's
 called. Then, it links to libc by default, so it is able to link against
 those functions without trouble. If you enable certain warnings (not sure
 which ones off the top of my head), tcc will complain about this behavior.

TL;DR: a function not defined will be assumed to return an int and no check 
will be performed on its arguments. When linking, the function will be found 
if it is part of the libc. See below for a more complete explanation if you 
are interested.

The code responsible for this is in unary(void) just after the label 
tok_identifier:

s = sym_find(t);

We search a symbol with that name

if (!s) {

We cannot find such a symbol

const char *name = get_tok_str(t, NULL);
if (tok != '(')
tcc_error('%s' undeclared, name);

For variable, this is a hard error and tcc stops right now.

/* for simple function calls, we tolerate undeclared
   external reference to int() function */
if (tcc_state-warn_implicit_function_declaration
#ifdef TCC_TARGET_PE
/* people must be warned about using undeclared WINAPI 
functions
   (which usually start with uppercase letter) */
|| (name[0] = 'A'  name[0] = 'Z')
#endif
)
tcc_warning(implicit declaration of function '%s', name);

A warning is emitted if -Wall is specified (-Wall enable several warning, 
including this one).

s = external_global_sym(t, func_old_type, 0); 
}

Consider the function is an int() one, that is a function that returns an int 
and take any parameter. func_old_type is defined in libtcc.c:

func_old_type.t = VT_FUNC;
func_old_type.ref = sym_push(SYM_FIELD, int_type, FUNC_CDECL, FUNC_OLD);

Int_type is the return type. FUNC_OLD is the interesting part as it indicates 
that it is compatible with any function, no matter the parameters. This check 
is done in is_compatible_func:

if (s1-c == FUNC_OLD || s2-c == FUNC_OLD)
return 1;

If one of the two compared function is FUNC_OLD, return 1 to say it's 
compatible.

This is for the compilation. As you noticed, it also passes linkage. The 
reason is that in -run functionality, tcc will resolve functions by way of 
dlsym (on Unices, on Windows it's probably a similar mechanism). So since tcc 
is linked with libc, any function part of libc will be found and there will be 
no error.

If you appreciated this detailed description let me know and I'll try to do 
such a detailed analysis with code snipped on some other occasions. Some 
people who want to contribute to tcc could learn a bit about its internals.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] incorrect/missing license files

Le dimanche 29 juin 2014, 12:40:04 Vincent Lefevre a écrit :
 On 2014-06-28 19:32:38 +0800, Thomas Preud'homme wrote:
  Le vendredi 27 juin 2014, 20:45:55 Vincent Lefevre a écrit :
   I'm not sure, due to the GPL system library exception.
  
  There is some disagreement over what that exception means. As far as
  I know, it only applies if the software is usually found on systems.
 
 This is the usual case, but this is not exactly what the GPL says,
 which mentions the case of a compiler.
 
  *  lib/libtcc1.c
  
  All the author of this file (except 2 lines of mingodad) agreed to
  relicense their work. I know the RELICENSING file only consider file
  copyright and consider that someone cannot have a copyright by
  contributing to an existing file. I believe this is wrong but from the
  exchange on this list, it seems obvious that all the contributor of this
  file agree to relicense whatever is needed in tcc.
 
 The problem would apply if new authors contribute to this file.
 Shouldn't the license change now, as it is possible?

It should yes. Grischka, Shinichiro, James: do you agree to relicense your 
contributions to lib/libtcc1.c under the BSD variants in RELICENSING file?

If both of you answer yes, could you commit the change Grischka?

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Mob has been reverted

Le mardi 24 juin 2014, 23:06:50 David Mertens a écrit :
 Hey everyone,
 

 
 This, at least, is what I intended to do. I would appreciate if others
 could double-check that I performed the cherry picking and merging
 correctly. I do not perform this sort of work often.

Looks correct on my side. Thanks for doing this.

 
 This reversion does not invalidate jiang's work. *jiang has demonstrated
 tremendous enthusiasm for improving tcc, and I think everybody here
 appreciates that enthusiasm*. The problem is that jiang did not discuss the
 changes with the mailing list before pushing them. jiang, please filter
 your future contributions through a conversation on the mailing list before
 committing your work to mob. In the end, everybody will be happier with the
 result! :-)

Agreed, it would be preferable that new comers post patches on mailing list 
and wait for some review before commiting them. I know that I may not have 
been involved in tcc if it was not for the relaxed rules on the mob branch and 
I certainly wrote some incorrect code (and still does of course albeit less 
often I hope). But it seems some people have some difficulties assessing the 
quality of their code. I perfectly understand that it is difficult to be 
neutral 
with one's own code which is exactly I encourage people to pass some kind of 
review first.

Grischka, I'm certainly not expecting you to do all the work. Even if I'm too 
slow to process patches, please refrain from processing all of them. You are 
the most experienced on tcc's code base and I really don't want you to burn 
out. Also, I'm not going to improve at code review if you review everything ;)

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] incorrect/missing license files

Le vendredi 27 juin 2014, 20:45:55 Vincent Lefevre a écrit :
 On 2014-06-27 11:30:54 -0500, Evan Langlois wrote:
  Stupid legal question.   If TCC is GPL (rather than lesser GPL) and you
  link with libtcc, then you would end up with software that was GPL.  This
  may be significant.   Additionally, and start-up object files that TCC
  generates may be considered linking with tcc.
 
 I'm not sure, due to the GPL system library exception.

There is some disagreement over what that exception means. As far as I know, 
it only applies if the software is usually found on systems. I doubt tcc 
applies here.

However, given the list of files under GPL, it seems perfectly possible to 
build a libtcc that is not GPL. Let's look at the list again:

*  il-opcodes.h

No problem if you don't build this target

*  lib/libtcc1.c

All the author of this file (except 2 lines of mingodad) agreed to relicense 
their work. I know the RELICENSING file only consider file copyright and 
consider that someone cannot have a copyright by contributing to an existing 
file. I believe this is wrong but from the exchange on this list, it seems 
obvious that all the contributor of this file agree to relicense whatever is 
needed in tcc.

  texi2pod.pl

Not needed to build libtcc, only for the documentation.

  win32/tools/tiny_impdef.c

Written by grischka. Grischka, maybe you could write a star * in RELICENSING 
for the file/feature part?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Request push

Le lundi 23 juin 2014, 23:56:10 jiang a écrit :
 I'll push a patch.

I'll take this as I'd like to commit/push this patch, what do you think of 
it?

The patch itself looks good but it would be better if you add a testcase that 
would fail without your patch. You already have a program that exhibit the 
bug, you just need to transform it so that it returns 0 if tcc behaves 
correctly and 1 else.

I also have a minor nitpick: \'%s\' may not appear in parameter list, 
get_tok_str(var, NULL)

That is, use single quote and put the symbol at the beginning of the sentence, 
that would avoid the colon.

If you fix those (testcase is very important), you are welcome to commit/push 
your patch.

In the future it would be better if you provide a patch as given by git 
format-patch. This way we'd have the message that you intend to use in your 
commit. And finally please try to find a title more specific than Request 
push. 
Try to find a title that explain what you want to fix. In this case you could 
choose Fix identifier list parsing. If you can refer to a section in C99 
standard in your message and your commit message that's the icing on the cake 
but we don't do it systematically ourselves. However I think it is good 
practice as GCC can sometimes deviate from the standard and we should try to 
adhere to the standard, not follow GCC blindly.

Thanks for your patch.

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] A few omissions from the docs

Le mercredi 18 juin 2014, 10:37:20 Wendell P a écrit :
 I found a few things missing from the documentation.
 
 1. In addition to -vv, there is also -vvv, which behaves a little
 differently.

Right. I cannot commit now, would you be willing to make a patch for this?

 
 2. The -E switch to preprocess only. I'm not sure, but -xc also seems to
 be recognized.

I don't understand what is the problem you states here. -E is mentioned in 
tcc's help. -xc is just -x -c where -x is ignored and -c ask for compilation 
only (no linkage).

 
 3. In the file tcc-win32.txt, the syntax given for windres is
 
 windres -O coff app.rc -o appres.o
 
 but that leaves out a necessary preprocessor command, so it should be
 
 windres --preprocessor tcc -E -O coff app.rc -o appres.o

I cannot comment on this, I really don't know anything about Windows. I should 
try to learn someday I know…

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] build error on FreeBSD

Le dimanche 08 juin 2014, 09:09:42 z_axis a écrit :
 $ git pull
 Already up-to-date.
 tinycc $ gmake
 gcc -o tccelf.o -c tccelf.c -DTCC_TARGET_I386 -I.  -Wall -g -O2
 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare
 -D_FORTIFY_SOURCE=0
 tccelf.c: In function 'layout_sections':
 tccelf.c:1962: error: 'strsec' undeclared (first use in this function)
 tccelf.c:1962: error: (Each undeclared identifier is reported only once
 tccelf.c:1962: error: for each function it appears in.)
 gmake: *** [tccelf.o] error 1
 ...
 
 $ uname -a
 FreeBSD mybsd.zsoft.com 9.1-RELEASE-p14 FreeBSD 9.1-RELEASE-p14 #0: Tue Jun 
 3 08:49:09 UTC 2014
 r...@amd64-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386

Mmmh, sorry, that's my fault. A parameter should be added to layout_sections 
to pass strsec so that it's available in it. I cannot commit right now, do you 
want to give it a try?

Best regards,

Thomas

signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] TinyCC contributors attending GNU Tools Cauldron