from:"Thomas Preud'homme"

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  
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] [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 

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 

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] Partial revert of nocode_wanted patch

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] 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] 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] [TIPS] empty test program will crash if compiled with -b option

Le mercredi 25 mars 2015, 20:59:23 Sergey Korshunoff a écrit :
> Hi! There is a patch attached. This patch:
>  1) installs bcheck.o along with the libtcc1.a
>  2) enforces bcheck.o linking

I just tested your patch without the tcc_add_support(s1, "bcheck.o"); and it 
works fine for me. This is not really surprising since as I said earlier 
bcheck.o is part of libtcc1.a which is linked.

So can you revert this commit (except the if (!sym_index) part) and the 
following commit 548a55eda53a0dcf2eabd617115c4e46330d7e23 ? If you did observe 
an issue without this, please tell me how to reproduce it and I'll look what 
is the actual issue.

Note that I do appreciate all your efforts to improve TinyCC, I don't want you 
to think the contrary. ;-)

Thanks in advance.

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] 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

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] [TIPS] empty test program will crash if compiled with -b option

Le mercredi 25 mars 2015, 19:55:46 Sergey Korshunoff a écrit :
> Hi! Is there a way to add a file from a library like:
>tcc_add_support(s1, "libtcc1.a(bcheck.o)");
> 
> There was a code in the old tccelf.c (0.9.22) which then removed:
> snprintf(buf, sizeof(buf), "%s/%s", tcc_lib_path, "bcheck.o");
> tcc_add_file(s1, buf);
> 
> Currently we install only a libtcc1.a. There is no bcheck.o
> Question: how to force a bcheck.o linking?

bcheck.o is part of libtcc1.a. See lib/Makefile:

BCHECK_O = bcheck.o
(…)
I386_O = libtcc1.o alloca86.o alloca86-bt.o $(BCHECK_O)
X86_64_O = libtcc1.o alloca86_64.o alloca86_64-bt.o $(BCHECK_O)
(…)
ifeq "$(TARGET)" "i386"
 OBJ = $(addprefix $(DIR)/,$(I386_O))
(…)
ifeq "$(TARGET)" "x86_64"
 OBJ = $(addprefix $(DIR)/,$(X86_64_O))
(…)
$(DIR)/libtcc1.a ../libtcc1.a : $(OBJ) $(XAR)
$(XAR) rcs $@ $(OBJ)

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 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] 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] some thoughts on the search path mess

2015-03-12 Thread Thomas Preud'homme

Le mercredi 11 mars 2015, 21:28:25 Edmund Grimley Evans a écrit :
> Currently the search paths for a non-cross tcc on Debian arm64 look
> like this (./tcc -vv):
> 
> crt:
>   /usr/lib/aarch64-linux-gnu
> libraries:
>   /usr/lib/aarch64-linux-gnu
>   /usr/lib
>   /lib/aarch64-linux-gnu
>   /lib
>   /usr/local/lib/aarch64-linux-gnu
>   /usr/local/lib
> include:
>   /usr/local/include/aarch64-linux-gnu
>   /usr/local/include
>   /usr/include/aarch64-linux-gnu
>   /usr/include
>   /usr/local/lib/tcc/include
> 
> Does that seem correct?
> 
> I note that /usr/local/lib comes after /usr/lib, but
> /usr/local/include comes before /usr/include. Why is that?

Probably a mistake.

> 
> Also, should /usr/lib be on the search path for crt?

For symmetry we could, but I've never met a system where they are stored in 
/usr/lib.

> 
> Also, is it correct for /usr/local/lib/tcc/include to come last rather
> than first in the "include" list?

I'm not sure what's the usual way. Isn't the set of files in this directory and 
others include directory different?

> 
> Presumably the search paths for any other Debian architecture could be
> the same with the appropriate triplet substituted for
> "aarch64-linux-gnu".

Yes.

> 
> Now, it seems that some other Linux distributions use lib32 and lib64.
> Is that only on Intel, or do they do the same on other architectures
> that have 32-bit and 64-bit variants?

I'm pretty sure others do.

> 
> What should the search paths look like on one of those Linuxes?

You forget about the triplet-qualified paths and replace lib by lib64. It's 
important *not* to look on /lib as it's where 32 bit libraries would be. 
Basically /lib and /lib64 is a specialization of the multiarch directories 
where files for any architecture can coexist.

> 
> A general question: should "configure" try to work out what kind of
> Linux we're on, or it should it just merrily include all the
> possibilities in the search paths?

I've pondered about it and I think we could make things a bit simpler. That 
said on a multiarch system for amd64 you want to look at x86_64-linux-gnu/lib 
and then /lib while on a non multiarch system for amd64 you only look at 
/lib64. You cannot make it look in the 3 directories as /lib if not empty will 
contain some 32bit libraries on a non-multiarch system.

> 
> The situation for a cross compiler is mostly very similar, except:
> 
> * You can't run a test program. But TCC's configure doesn't do that
>   anyway.

Yeah, and there is no switch to specify the triplet on multiarch systems, you 
have to set all the path manually which is cumbersome.

> 
> * There's no point in including generic paths like /usr/lib in the
>   search paths. They are almost certainly wrong. However, if you're
>   cross-compiling between variants of the same architecture then it
>   probably make sense to include things like /usr/lib32 in the paths.

Except for biarch (-m 32) precisely.

> 
> * With a cross-compiler it's quite probable that the user will install
>   libraries after building TCC so it perhaps makes more sense to
>   include directories that don't yet exist in the search paths.

We don't look at whether there is file in the directory searched now, do we?

> 
> That last point suggests that for symmetry between cross and non-cross
> compilers it might make sense to put, by default, all likely
> directories into the search path whether or not they exist.

In the limits mentionned above.

> 
> Another general point: You can put complex "sh" logic in "configure",
> complex "make" logic in "Makefile", or complex "cpp" logic in the C
> source files: a choice of three crap programming languages! If you're
> a masochist, you can also put double-escaped sh code in the Makefile.
> Also, you can make the logic at each stage attempt to pre-empt bzw.
> second-guess what the logic at other stages has done or will do. I
> tend to think that "configure" is probably the best place to do things
> as "sh" is arguably the least hostile of the three environments. Also,
> configure produces a human-readable output and you can insert print
> statement into it, both of which help with debugging.

The problem is the --enable-cross option. It will build all cross compiler 
currently supported by tcc and each will have different search directory. You 
could maybe output the different paths into different file and then play with 
symlink when compiling the cross-compiler now that I think about it.

> 
> Thoughts?

It would be nice to clean the build system mess. The configure is still 
readable but the Makefile has become a bit crazy yeah.

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] Straightening out x86_64 build?

Le mardi 10 mars 2015, 20:02:51 Sergey Korshunoff a écrit :
> > A crt*.o searching  on Debian/Ubuntu is another problem.
> > 
> >> A problem you caused?
> 
> A problem was caused by a Debians boys I think.

Please refrain from such generalization. Being a small project I'm pretty sure 
all people involved in development of TinyCC make their own decision and work 
on it because they care about this project.

> 
> > In general, could you please be a bit more careful
> 
> The same suggestion for debian boys. I only reverted a commit "Set
> CONFIG_MULTIARCHDIR for cross compilers" It was only debian oriented
> "and breaks x86 / x86_64 compilres for linux" other then debian.
> Correct me if I wrong.

Yes, this applies to everybody. It's ok to break things occasionally, I broke 
things an important number of times myself as long as one fixes his mistake (of 
course it's fine for other people to fix it before if they wish).

As I've said before, I encourage people to submit patches if they are unsure 
about them or if they often broke things. I tend to include myself in this 
latter category. I acknowledge that the review bandwith is quite low (I myself 
don't have as much time as I would like to dedicate to tcc and am slow at 
reviewing) which is why patch review is not mandatory.

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

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] [PATCH] deprecating VT_REF

Le dimanche 22 février 2015, 00:16:20 Michael Matz a écrit :
> Hi,
> 
> On Sat, 21 Feb 2015, Edmund Grimley Evans wrote:
> > 
> > I agree, but inserting those #ifdefs is merely making the
> > architecture-specificity explicit, thereby perhaps encouraging someone
> > to do something about it. Without the #ifdefs, but with VT_REF only
> > used by the x86_64 back end, you have hidden target-specificity, which
> > is more dangerous.
> 
> I disagree about dangerous; it's only a problem for those targets, and
> presumably for them the generic handling of VT_REF is correct.  If you
> mean dangerous as in "others might be tempted to use it in their target,
> even though the generic handling isn't correct for them", then, well, life
> is tough; it's not enough reason IMHO to uglify common code.  Neither is
> trying to make others interested in removing the thing.

FWIW, I fully agree.

> 
> But apart from that philosophical argument, I claim that the concept of
> VT_REF is not target specific at all.  It does have things in common with
> VT_LLOCAL, but is not _quite_ the same currently, as we now found out in
> the other mails.  This not-quite-equality might indeed be bugs in how
> VT_LLOCAL is handled, e.g. VT_LLOCAL might be understood as an
> optimization to VT_REF (even though the latter was introduced later), the
> optimization being that lvalueness/referenceness can be changed by a
> simple bitflip, instead of generating code.
> 
> So, yes, ideally VT_LLOCAL and VT_REF should be merged.  Though the
> question still is into which one.  VT_LLOCAL is tricky, as the docu said
> 
> :)  And it currently contains bugs, when used for some things.
> 
> _If_ the issues with VT_LLOCAL can be fixed, then I'd be in favor of
> removing VT_REF.  After such fixing goes in.

No matter which one is used, it would be nice to use the name VT_REF as the 
name encompasse better what it is about: a value for a memory reference that 
contains the address of another value. The name VT_LLOCAL refers to much to 
the purpose of VT_LVAL on stack. 

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] RE :Re: 1cbb4d322bc3c89a3b56d35c803a19f99f33ab65 broke tcc on arm (RPi) 6 days ago

Le mardi 10 mars 2015, 11:37:30 Christian JULLIEN a écrit :
> 
> > 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] regressions on i386

On March 6, 2015 3:46:46 AM GMT+08:00, Edmund Grimley Evans 
 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] [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  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] CValue

2015-03-07 Thread Thomas Preud'homme

Le jeudi 05 mars 2015, 22:13:17 Edmund Grimley Evans a écrit :
> Can anyone think of an argument for preserving the way TCC currently
> stores an integer constant in one of the following union members?
> 
> int i;
> unsigned int ui;
> unsigned int ul; /* address (should be unsigned long on 64 bit cpu) */
> long long ll;
> unsigned long long ull;

Funny, I never thought about it. Digging into the history 
(25618c0430b58d1d5522091c83c89cdde83135f1) one can see that there was no such 
duplication for integer initially. There is this for float but I suppose it's 
to not have more precision than the programmer requested.

> 
> To me it seems to make the implementation more complicated while
> inviting people to rely on undefined behaviour such as signed overflow
> and writing to one member of a union then reading from another. The
> obvious thing to do is to use unsigned long long (or uint64_t or
> uintmax_t) for all integer constants, but I've not actually tried
> changing the code.

If there is a lot of such union some space might be saved but I'm not 
convinced it's significant. Setting a value in one field and accessing it in 
another is forbidden by the C standard I think (aliasing?) and anyway only 
make sense for downcasting on little endian target. I don't think the 
endianness is such a big problem because this assumption must already be all 
over the place but avoiding bug and simplifying the code is a good reason to 
get rid of 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] [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] [BUG] [PATCH] tcc and INT64: wrong result of comparison (a test included)

2015-02-17 Thread Thomas Preud'homme

Le lundi 5 janvier 2015, 17:47:58 Sergey Korshunoff a écrit :
> tccpp(parse_number): changes to detect a constat type correctly.
> This patch is tested with a nimrod compiler build process. All works.

Hi Sergey,

Sorry, I did a patch independantly from yours as I was looking for an 
occupatino in the train and was surprised when looking at your patch (I never 
got to look at it before) to have such similar solution to yours.

Best regards,

Thomas
> 
> 2015-01-05 2:03 GMT+03:00, Sergey Korshunoff :
> > There is another approach: assume the constant is negative by default.
> > This is the method used in nimrod to scan a constants:
> > lib/pure/parseutils.nim(rawparse)
> > 
> > proc rawParseInt(s: string, b: var BiggestInt, start: int = 0): int =
> > var
> > 
> > sign: BiggestInt = -1 # minus by defaul
> > i = start
> >   
> >   if s[i] == '+': inc(i)
> >   
> >   elif s[i] == '-':
> > inc(i)
> > sign = 1
> >   
> >   if s[i] in {'0'..'9'}:
> > b = 0
> > 
> > while s[i] in {'0'..'9'}:
> >   b = b * 10 - (ord(s[i]) - ord('0')) #!  the point
> >   inc(i)
> >   while s[i] == '_': inc(i) # underscores are allowed and ignored
> > 
> > b = b * sign
> > result = i - start
> > 
> > Sun, 04 Jan 2015 16:51 +, Thomas Preud'homme :
> >> Le dimanche 4 janvier 2015, 19:18:34 Sergey Korshunoff a écrit :
> >>> By replacing a -2147483648 with a -2147483647 I can succesfully build
> >>> a working nim compiler. But this is not so good...
> >> 
> >> The bug is in tccpp.c parse_number. The function tries to guess what
> >> should
> >> be
> >> the size and sign of the litteral before parsing the suffix (which might
> >> not
> >> 
> >> exist).
> >> 
> >> /* XXX: not exactly ANSI compliant */
> >> if ((n & 0xLL) != 0) {
> >> 
> >> if ((n >> 63) != 0)
> >> 
> >> tok = TOK_CULLONG;
> >> 
> >> else
> >> 
> >> tok = TOK_CLLONG;
> >> 
> >> } else if (n > 0x7fff) {
> >> 
> >> tok = TOK_CUINT;
> >> 
> >> } else {
> >> 
> >> tok = TOK_CINT;
> >> 
> >> }
> >> 
> >> In your case it will pass in the first else if and set tok to TOK_CUINT.
> >> So
> >> far
> >> so good.
> >> 
> >> Then it will parse the suffix and when it sees the second L it does this:
> >> if (tok == TOK_CINT)
> >> 
> >> tok = TOK_CLLONG;
> >> 
> >> else if (tok == TOK_CUINT)
> >> 
> >> tok = TOK_CULLONG;
> >> 
> >> So here it will set the value to TOK_CULLONG while it should set it to
> >> TOK_CLLONG and warn if the value is too big.
> >> 
> >> My feeling is that the automatic guess for the size and sign should be
> >> done
> >> 
> >> after trying to look for a suffix.
> >> 
> >> The algorithm would be something like:
> >> 
> >> 1) Set tok to TOK_CINT and suffix_found to false.
> >> 2) Then look for a L or U suffix with unchanged code except for setting a
> >> suffix_found variable if any such suffix is found.
> >> 3) Then if suffix_found is false try automatic detection, otherwise warn
> >> of
> >> 
> >> overflow and possibly process the overflow (what does GCC does in this
> >> case?) Be
> >> careful about the sign when checking for overflow.
> >> 
> >> Do you want to take a stab at it?
> >> 
> >> 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-11 Thread Thomas Preud'homme

Le mercredi 7 janvier 2015, 06:01:49 Sergey Korshunoff a écrit :
> Using a strtoul with TOK_PPNUM to convert string to number is a
> standard method in tcc. And strtoul() is much shorter and faster then
> parse_number(). parse_number deal with floats and long long integers
> and ... And there is no need to declare any function or move it.

I don't know the reason but I suppose if parse_number doesn't use strtoul 
there must be a reason. And it there isn't then parse_number and next() should 
be modified to use strtoul as well.

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] [BUG] tcc and INT64: wrong result of comparison (a test included)

Le dimanche 4 janvier 2015, 19:18:34 Sergey Korshunoff a écrit :
> By replacing a -2147483648 with a -2147483647 I can succesfully build
> a working nim compiler. But this is not so good...

The bug is in tccpp.c parse_number. The function tries to guess what should be 
the size and sign of the litteral before parsing the suffix (which might not 
exist).

/* XXX: not exactly ANSI compliant */
if ((n & 0xLL) != 0) {
if ((n >> 63) != 0)
tok = TOK_CULLONG;
else
tok = TOK_CLLONG;
} else if (n > 0x7fff) {
tok = TOK_CUINT;
} else {
tok = TOK_CINT;
}

In your case it will pass in the first else if and set tok to TOK_CUINT. So far 
so good.

Then it will parse the suffix and when it sees the second L it does this:

if (tok == TOK_CINT)
tok = TOK_CLLONG;
else if (tok == TOK_CUINT)
tok = TOK_CULLONG;

So here it will set the value to TOK_CULLONG while it should set it to 
TOK_CLLONG and warn if the value is too big.

My feeling is that the automatic guess for the size and sign should be done 
after trying to look for a suffix.

The algorithm would be something like:

1) Set tok to TOK_CINT and suffix_found to false.
2) Then look for a L or U suffix with unchanged code except for setting a 
suffix_found variable if any such suffix is found.
3) Then if suffix_found is false try automatic detection, otherwise warn of 
overflow and possibly process the overflow (what does GCC does in this case?) 
Be 
careful about the sign when checking for overflow.

Do you want to take a stab at it?

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 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] Re: using gdb 6.6 on linux fail after dec18 2013

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] Re: using gdb 6.6 on linux fail after dec18 2013

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 
> 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] 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] [PATCH] accepting a 'b' suffix at the end of all the setcc instructions

Le samedi 3 janvier 2015, 09:34:14 Sergey Korshunoff a écrit :
> Allow tcc to understand a setob,... opcodes as alias to  seto,...
> 
> PS:
> http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20101122/112576
> .html This is fix PR8686 for llvm: accepting a 'b' suffix at the end of all
> the setcc instructions

Hi Sergey,

As said previously I'm not very familiar with this part of the code but your 
change looks good. I just have one suggestion:

rename DEF_ASMTEST by DEF_ASMTEST_SUF and make it take a third parameter that 
is concatenated at the end. Then make DEF_ASMTEST call DEF_ASMTEST_SUF and you 
can define DEF_ASMTEST_SET with DEF_ASM_SUF as well using less lines overall.

By the way, is it normal that there is only 2 variants of set for x86_64 but 
so many for i386?

Best regards,

Thomas

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

Re: [Tinycc-devel] [PATCH] sinf/sin problem: turn on (by default) implicit-function-declaration

Le samedi 3 janvier 2015, 07:35:46 Sergey Korshunoff a écrit :
> Turn on a implicit-function-declaration warning by default. This could
> help to resolve a problem with sinf/sin

diff -urN tinycc.old/libtcc.c tinycc/libtcc.c
--- tinycc.old/libtcc.c 2015-01-03 06:12:53.0 +0300
+++ tinycc/libtcc.c 2015-01-03 07:24:02.0 +0300
@@ -1769,6 +1769,9 @@
 CString linker_arg;
 cstr_new(&linker_arg);
 
+tcc_set_warning(s, "implicit-function-declaration" , 1);
+// turn it on by default
+
 while (optind < argc) {
 
 r = argv[optind++];

It would be better to add the warning when compiling the tests by changing the 
Makefile. It seems wrong to show a warning when the user didn't ask for one and 
this is consistent with what other compilers do.


diff -urN tinycc.old/tests/tests2/46_grep.c tinycc/tests/tests2/46_grep.c
--- tinycc.old/tests/tests2/46_grep.c   2015-01-03 06:12:53.0 +0300
+++ tinycc/tests/tests2/46_grep.c   2015-01-03 07:26:07.0 +0300
@@ -16,6 +16,7 @@
  */
 #include 
 #include 
+#include  // tolower()
 
 /*
  * grep
diff -urN tinycc.old/tests/tests2/64_macro_nesting.c 
tinycc/tests/tests2/64_macro_nesting.c
--- tinycc.old/tests/tests2/64_macro_nesting.c  2015-01-03 06:12:53.0 
+0300
+++ tinycc/tests/tests2/64_macro_nesting.c  2015-01-03 07:29:18.0 
+0300
@@ -1,3 +1,5 @@
+#include  // printf()
+
 #define CAT2(a,b) a##b
 #define CAT(a,b) CAT2(a,b)
 #define AB(x) CAT(x,y)

You can commit these last two changes.

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] 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] 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 undefine symbol

Le jeudi 1 janvier 2015, 16:59:51 Sergey Korshunoff a écrit :
> tcc_undefine_symbol(): free an alloced symbol

Why not simply calling tcc_free and not create that new function until it 
proves necessary?

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] [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] 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] 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 
> #include 
> #include 
> #include 
> 
> /* #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] 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] [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] 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] 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] tiny c executable will run on windows 98, getmainargs ?

Le vendredi 21 novembre 2014, 17:53:50 Carlos Montiers a écrit :
> Hello. The executables compiled with tiny c should run on windows 98?.
> 
> I ask this, because, windows 98 use msvcrt.dll v6.0 and is different than
> msvcrt.dll v7.0
> 
> For example, the sources for the crt for __getmainargs function
> 
> in the visual studio 98 (v6.0) prototype is:
> _CRTIMP void __cdecl __wgetmainargs
> and in visual studio 2010 (v7.0) the prototype is:
> _CRTIMP int __cdecl __wgetmainargs
> 
> v6.0 says:
> Exit: No return value. Values for the arguments to main() are copied
> through the passed pointers.
> And in the function _setargv (that call):
> Exceptions: Terminates with out of memory error if no memory to allocate.
> 
> v7.0 says:
> Exit: Returns 0 on success, negative if _*setargv returns an error. Values
> for the arguments to main() are copied through the passed pointers.
> 
> Because this, I think if we want compatibility with this two versions of
> msvcrt.dll we cannot use the return value for check success, because v6.0
> return void.
> 
> I propose this way for check the success of the function:
> 
> argv = NULL;
> __getmainargs(&argc, &argv, &env, 0, &start_info);
> // check success of __getmainargs comparing argv with NULL
> if (! argv) {
> ExitProcess(-1);
> }
> 
> Some comments about this?

Sounds reasonnable but note that I don't know anything about programming on 
Windows right now. Adding grishka in the loop for an opinion.

Thanks for the detailed explaination by the way.

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 . 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] [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] [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] libtcc.c (put_extern_sym2): Extend the scope of buf to match its use

Le jeudi 18 décembre 2014, 20:00:02 David Mertens a écrit :
> Good catch. I'm not closely acquainted with this particular section of
> code, but your observation looks correct to me, and the fix looks right.

I have 2 minor nitpick though (I know it's already commited). First, with that 
change buf is no longer declared at the start of a block (C89 style) and this 
is the coding style used in tcc. Second, it would be more consistent and 
clearer to declare it in the same scope as name since they are both used in 
the same scope.

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 2/1

Le samedi 3 janvier 2015, 06:11:12 Sergey Korshunoff a écrit :
> Lets "table_ident = NULL" after "tcc_free(table_ident)" in libtcc.
> Before this done a some test are failing with a memory double freeing
> error. triggered by first patch.

Hi Sergey,

I don't disagree to this patch per se but there is probably another problem. 
tcc_new () already call preprocess_new that sets table_ident to NULL so the 
realloc of table_ident in tccpp.c should be fine and there shouldn't be a 
double free.

Besides, if you sets table_ident here you should remove the similar line from 
preprocess_new in my opinion.

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] 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 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  
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] 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 
> 
> 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] 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 
> 
> 
> 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] 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] 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] 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=tcc&arch=armhf&ver=0.9.27~git20140801.14745bd-1&stamp=1409978859
[2] 
https://buildd.debian.org/status/fetch.php?pkg=tcc&arch=armhf&ver=0.9.27~git20140907.87d879a-1&stamp=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 l

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] 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] 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=tcc&arch=armhf&ver=0.9.27%7Egit20140907.87d879a-1&stamp=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

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] 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-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] 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
> +

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] 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 :
> > 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

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] 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_BTYP

Re: [Tinycc-devel] tcc grammar problems