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

[Sergey Korshunoff]

There is a patch 4aec2902cabb819e24850c80ddb364b7b4308b7b
Author: Thomas Preud'homme 
Date:   Wed Dec 18 11:17:17 2013 +0800
Split elf_output_file in smaller functions

After this patch a usage of the gdb 6.6 on Linux is not possible (gdb
can not find a main proc for setting a breakpoint). Which debuger you
on LInux to debug a programs compiled by tcc?

PS: I don't have problems with debugging a programs which are compiled
by gcc 4.1.2, 3.4.6, ...

___
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.

[Thomas Preud'homme]

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] TCC as default compiler

[Thomas Preud'homme]

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 3/4] Makefile: Add rules to create tags and TAGS.

[Thomas Preud'homme]

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] [PATCH] pp-defines 2/x

[Thomas Preud'homme]

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] pp table_ident freeing 2/1

[Thomas Preud'homme]

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

[Thomas Preud'homme]

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] Fix parsing of binary floating point number

[Thomas Preud'homme]

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

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

Thanks for the fix.

Best regards,

Thomas

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

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

[Thomas Preud'homme]

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

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

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

Best regards,

Thomas

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

Re: [Tinycc-devel] FreeBSD compilation issues

[Thomas Preud'homme]

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

[Thomas Preud'homme]

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] libtcc.dll on win32 issues

[Thomas Preud'homme]

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

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

Best regards,

Thomas

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

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

[Thomas Preud'homme]

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

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

Best regards,

Thomas

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

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

[Thomas Preud'homme]

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

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

Best regards,

Thomas

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

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

[Thomas Preud'homme]

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

Looks good, please proceed.

Best regards,

Thomas

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

Re: [Tinycc-devel] crt1.c revision

[Thomas Preud'homme]

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] allow to tell a target ARCH to a configure script

[Thomas Preud'homme]

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

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

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

if ARCH is defined, then use it
else use uname

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

What do you think?

Best regards,

Thomas

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

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

[Thomas Preud'homme]

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

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

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

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

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

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

Best regards,

Thomas

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

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

[Thomas Preud'homme]

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

[Thomas Preud'homme]

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] tcc don't know a setcb -- x86 assembler command

[Thomas Preud'homme]

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

Take a look into i386-asm.h

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

best regards,

Thomas

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

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

[Thomas Preud'homme]

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

Hi Sergey,

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

See for yourself:

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

Best regards,

Thomas

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

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

[Thomas Preud'homme]

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] sinf/sin problem: turn on (by default) implicit-function-declaration

[Thomas Preud'homme]

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

[Thomas Preud'homme]

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] warn about conflicting options on the command line like -E, -c, -run, -shared

[Thomas Preud'homme]

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] Don't break compilation process with unknow option

[Sergey Korshunoff]

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

The patch is for the case with -Wunsupported. In such case a user will
is "Don't trap, only warning". There are many gcc options which tcc
don't support. But in many cases, this options are not important.
Changing a Makefiles is not a solution when trying to use tcc insteed
of gcc.
And a patch test command is:
 /tcc -Wunsupported -traditional -E tcc.c -o tcc.i

2015-01-04 1:30 GMT+03:00, Thomas Preud'homme :
> Le samedi 27 décembre 2014, 17:02:03 Sergey Korshunoff a écrit :
>> # ./tcc -Wunsupported -traditional -E tcc.c -o tcc.i
>> tcc: error: invalid option -- '-traditional'
>>
>> Don't break compilation process with unknow option  (-traditional for
>> example). There is a warning label for such case.
>
> GCC and clang also error out for unknown option. What option caused your
> program to fail to compile?
>
> Best regards,
>
> Thomas
>

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

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

[Sergey Korshunoff]

What tcc do currently for the command:
  tcc -E a.c b.c -o aaa.i
Does it give even a warning?

PS: a patch is only suggestion. I need this functionality in the
preprocessor to speed up compilation, I use this functionality, it is
there in my version of the tcc since tcc 0.9.25



2015-01-04 1:46 GMT+03:00, Thomas Preud'homme :
> 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] pp-defines

[Sergey Korshunoff]

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


2015-01-04 4:03 GMT+03:00, Thomas Preud'homme :
> Le vendredi 2 janvier 2015, 15:53:39 Sergey Korshunoff a écrit :
>> A values for
>> __STDC__, __STDC_VERSION__, __STDC_HOSTED__
>> on the Linux are defined as in gcc.
>
> Hi Sergey,
>
> This patch seems unnecessary as tcc_define_symbol with a third argument NULL
> is
> equivalent as setting it to 1 (#define FOO is the same as #define FOO 1).
>
> See for yourself:
>
> % cat ~/foo.c
> int foo = __STDC__;
> % tcc -E ~/foo.c
> # 1 "/home/foo/foo.c"
> int foo = 1;
>
> Best regards,
>
> Thomas
>

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

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

[Sergey Korshunoff]

And yes, gcc do this rigth. gcc can preprocess all *.c files in the
command line.

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

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

[Sergey Korshunoff]

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.

2015-01-03 22:03 GMT+03:00, Sergey Korshunoff :
> There is a patch 4aec2902cabb819e24850c80ddb364b7b4308b7b
> Author: Thomas Preud'homme 
> Date:   Wed Dec 18 11:17:17 2013 +0800
> Split elf_output_file in smaller functions
>
> After this patch a usage of the gdb 6.6 on Linux is not possible (gdb
> can not find a main proc for setting a breakpoint). Which debuger you
> on LInux to debug a programs compiled by tcc?
>
> PS: I don't have problems with debugging a programs which are compiled
> by gcc 4.1.2, 3.4.6, ...
>


2015-01-05-1-tccelf-debug.patch
Description: Binary data
___
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

[Sergey Korshunoff]

After a previous patch applied...
Bug: a line number declaration (# NUM xxx "file_name") is not used
when generating a debug info. A test case: precompile your project
files with tcc and then use a precompiled files to get an executable
with a debug info included. This info will be wrong. A gcc works rigth
in this case.


2015-01-04 8:10 GMT+03:00, Sergey Korshunoff :
> 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.
>
> 2015-01-03 22:03 GMT+03:00, Sergey Korshunoff :
>> There is a patch 4aec2902cabb819e24850c80ddb364b7b4308b7b
>> Author: Thomas Preud'homme 
>> Date:   Wed Dec 18 11:17:17 2013 +0800
>> Split elf_output_file in smaller functions
>>
>> After this patch a usage of the gdb 6.6 on Linux is not possible (gdb
>> can not find a main proc for setting a breakpoint). Which debuger you
>> on LInux to debug a programs compiled by tcc?
>>
>> PS: I don't have problems with debugging a programs which are compiled
>> by gcc 4.1.2, 3.4.6, ...
>>
>

___
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

[Sergey Korshunoff]

Yes, It looks like else is not needed when processing
# line XXX "filename"
We must only get a next token and parse it as number.

2015-01-04 0:36 GMT+03:00, Thomas Preudomme :
> 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
>


2014-12-27-01-pp-num-as-line-2.patch
Description: Binary data
___
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

[Sergey Korshunoff]

But after testing: if "else" removed then tcc can not handle a #line
directive.And with first patch tcc process rigth all forms:
  # line XXX "file_name"
  # XXX "file_name"

2015-01-04 10:43 GMT+03:00, Sergey Korshunoff :
> Yes, It looks like else is not needed when processing
> # line XXX "filename"
> We must only get a next token and parse it as number.
>
> 2015-01-04 0:36 GMT+03:00, Thomas Preudomme :
>> 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