Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

> ifdef CONFIG_WIN32 > TCCFLAGS = -B$(top_srcdir)/win32 -I$(top_srcdir) 
> -I$(top_srcdir)/include -L$(TOP) > endif

And where the case of CONFIG_WIN64?

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

Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

you changed the code to use 'realpath', but realpath is not available
on all systems.

old code can be used for suçh systems. I don't like to use cp on Linux.

PS: I currently on tablet, a notebook must be repaired.


2016-05-20 18:29 GMT+03:00, avih <avih...@yahoo.com>:
> @seyko
> While I appreciate the confidence in me when you take code/patches which I
> wrote and commit them to mob yourself (and also the credit which you gave in
> your commits from today - in the past you did so without giving credit
> IIRC), I'd also appreciate some heads up and possibly some discussion.
> For instance, your commit bab4519 which is based on an issue which I
> detected and fixed (not perfectly, but still) at my drafts branch to allow
> the tests to run at a custom build dir, you changed the code to use
> 'realpath', but realpath is not available on all systems.
> You can use this code instead, which I wrote and I think would be enough for
> this case, here:
> https://github.com/avih/tinycc/blob/drafts/win32/build-tcc-reproducible.sh#L11
>
>
> Also, if you take someone else's commit and push it yourself, you can keep
> the author the same (assuming you didn't make meaningful changes) using git
> format-patch and git am (or cherry-pick etc), such that the original author
> doesn't appear only at the commit message, but actually stays the author of
> the commit.
>
>
>
> On Saturday, May 14, 2016 5:33 PM, avih <avih...@yahoo.com> wrote:
>
>
>  You can try my branch: https://github.com/avih/tinycc/commits/drafts (note,
> I force-push and keep it rebased on top of mob).
> It includes several build consolidation for windows such that it needs less
> windows-specific checks etc, but also adds some other improvements (like
> getopt working out of the box, and few more, including make it self-hosting
> using the latest official tcc-for-windows-release - 0.26). It shouldn't hard
> to identify the commits which only touch the build system.
>
> I haven't touched tcc for some months, and at the time I was able to use my
> drafts branch to build tcc and cross out of tree with all tests passing and
> the output executables working as expected, either on windows or linux,
> either in msys2-32/64 env using the native (gcc) compiler or msys1 env
> (using tcc0.26-32 for windows as the compiler and tiny_libmaker.exe as AR).
> I've updated it today (pushed to the drafts branch already) and added one
> commit which reverts a win32 specific stuff at the tests/Makefile (my
> earlier consolidations made it unneeded), and it now _seems_ to work again
> as expected (was able to build using msys2 (gcc) or msys[1] (tcc.exe) and
> all the tests pass). But I didn't test it extensively.
>
> If you wish to test the version which got some more testing by me, you can
> try the branch "snapshot-drafts-2015-12-17"
>
> Hope it helps.
> PS.I wanted to push some/all of the commits on my "drafts" branch to mob
> after some cleanups, but never really got to end up doing it. If there's
> enough interest and my current drafts branc ends up usable for many, I'll
> reconsider putting the effort.
>
>
> On Saturday, May 14, 2016 4:57 PM, Chris Marshall
> <devel.chm...@gmail.com> wrote:
>
>
>  As someone whose primary development environment is cygwin/win7, I would
> love for tcc to build and run under cygwin.
>
>
> --Chris
>
>
> On 5/14/2016 03:24, Sergey Korshunoff wrote:
>> MSYS2 is current environment for Qt and other software development on
>> Windows. It is a mingw+cygwin with a package manager (pacman), ported
>> from ARCH Linux. MSYS2 allow to build
>> mingw32/mingw64/cygwin32/cygwin64 programs in unix-like environment.
>> Currenly tcc can not be build on this environment (mix of unix and
>> windows). I think a system name (uname output) is needed to
>> select/reject some code in sources of the tcc.
>>
>> ___
>> Tinycc-devel mailing list
>> Tinycc-devel@nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
> ___
> Tinycc-devel mailing list
> Tinycc-devel@nongnu.org
> https://lists.nongnu.org/mailman/listinfo/tinycc-devel
>
>
>
>
>

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

Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

> The mob branch does not have tests/exsymtab/* which your updated configure 
> tries to use.
my fault. please fix it (I can't now)

> You didn't take my change at tests/Makefile, and without this change it won't 
> work on windows (It needs -I$(TOP) because the configured config.h is there 
> and there only).

a patch was only for Linux part . A Windows part is planed. Why it
works on inux?

you changed the code to use 'realpath', but realpath is not available
on all systems.

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

Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

> The mob branch does not have tests/exsymtab/* which your updated configure 
> tries to use.
my fault. please fix it (I can't now)

> You didn't take my change at tests/Makefile, and without this change it won't 
> work on windows (It needs -I$(TOP) because the configured config.h is there 
> and there only).

a patch was only for Linux part . A Windows part is planed. Why it
works on inux?


you changed the code to use 'realpath', but realpath is not available
on all systems.

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

Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

> However, since the
> preprocessing is being done by tcc the __CYGWIN__ macro is not defined
> and I can't figure out where that would go.
iff --git a/libtcc.c b/libtcc.c
index 7d9a058..a5ec7f3 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1170,6 +1170,8 @@ LIBTCCAPI TCCState *tcc_new(void)
 # ifdef TCC_TARGET_X86_64
 tcc_define_symbol(s, "_WIN64", NULL);
 # endif
+#elif defined(__CYGWIN__)
+tcc_define_symbol(s, "__CYGWIN__", NULL);
 #else
 tcc_define_symbol(s, "__unix__", NULL);
 tcc_define_symbol(s, "__unix", NULL);
diff --git a/include/stddef.h b/include/stddef.h
index 791ba31..31b60dd 100644
--- a/include/stddef.h
+++ b/include/stddef.h
@@ -8,8 +8,9 @@ typedef __PTRDIFF_TYPE__ ptrdiff_t;
 typedef __PTRDIFF_TYPE__ intptr_t;
 typedef __SIZE_TYPE__ uintptr_t;
 
-#ifndef __int8_t_defined
+#if !defined(__int8_t_defined) && !defined(___int8_t_defined)
 #define __int8_t_defined
+#define ___int8_t_defined
 typedef signed char int8_t;
 typedef signed short int int16_t;
 typedef signed int int32_t;
diff --git a/lib/bcheck.c b/lib/bcheck.c
index 18415cd..e3a8ef2 100644
--- a/lib/bcheck.c
+++ b/lib/bcheck.c
@@ -17,10 +17,10 @@
  * License along with this library; if not, write to the Free Software
  * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
  */
-#include 
 #include 
 #include 
 #include 
+#include 
 #if !defined(__FreeBSD__) && !defined(__FreeBSD_kernel__) \
 && !defined(__DragonFly__) && !defined(__OpenBSD__) && !defined(__NetBSD__)
 #include 
@@ -47,7 +47,7 @@ extern void *sbrk (intptr_t __delta);
 #if defined(__FreeBSD__) || defined(__FreeBSD_kernel__) \
 || defined(__DragonFly__) || defined(__dietlibc__) \
 || defined(__UCLIBC__) || defined(__OpenBSD__) || defined(__NetBSD__) \
-|| defined(_WIN32) || defined(TCC_UCLIBC)
+|| defined(_WIN32) || defined(TCC_UCLIBC) || defined(__CYGWIN__)
 #warning Bound checking does not support malloc (etc.) in this environment.
 #undef CONFIG_TCC_MALLOC_HOOKS
 #undef HAVE_MEMALIGN
diff --git a/libtcc.c b/libtcc.c
index 7d9a058..a5ec7f3 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1170,6 +1170,8 @@ LIBTCCAPI TCCState *tcc_new(void)
 # ifdef TCC_TARGET_X86_64
 tcc_define_symbol(s, "_WIN64", NULL);
 # endif
+#elif defined(__CYGWIN__)
+tcc_define_symbol(s, "__CYGWIN__", NULL);
 #else
 tcc_define_symbol(s, "__unix__", NULL);
 tcc_define_symbol(s, "__unix", NULL);
diff --git a/tccrun.c b/tccrun.c
index 52d3015..72c62e9 100644
--- a/tccrun.c
+++ b/tccrun.c
@@ -502,7 +502,7 @@ static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, 
int level)
 *paddr = uc->uc_mcontext->__ss.__eip;
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || 
defined(__DragonFly__)
 *paddr = uc->uc_mcontext.mc_eip;
-#elif defined(__dietlibc__)
+#elif defined(__dietlibc__) || defined(__CYGWIN__)
 *paddr = uc->uc_mcontext.eip;
 #elif defined(__NetBSD__)
 *paddr = uc->uc_mcontext.__gregs[_REG_EIP];
@@ -515,7 +515,7 @@ static int rt_get_caller_pc(addr_t *paddr, ucontext_t *uc, 
int level)
 fp = uc->uc_mcontext->__ss.__ebp;
 #elif defined(__FreeBSD__) || defined(__FreeBSD_kernel__) || 
defined(__DragonFly__)
 fp = uc->uc_mcontext.mc_ebp;
-#elif defined(__dietlibc__)
+#elif defined(__dietlibc__) || defined(__CYGWIN__)
 fp = uc->uc_mcontext.ebp;
 #elif defined(__NetBSD__)
 fp = uc->uc_mcontext.__gregs[_REG_EBP];
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

> I'm trying to do that, i.e MSYS2 unix.
Fixed a mingw64 build on Linux with --enable-tcc64-mingw
https://github.com/seyko2/tinycc/commit/47f80bd7f70904711a046c4ca98de2657ad298a7

Problem: a name of the libtcc.a and libtcc1.a libraries is the same
for 32 and 64 builds. And all files go to the C:\Program FIles\tcc.
May be there must be lib32 and lib64 dirs with thise libraries as it
is done on Linux?

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

Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

@avih
> apparently there have been some build system changed between December and now

yes, the same is on my branch. A problem is exposed after my commit
  commit 7ed43415380ec6270e53c0ed3f42e5cb99df1f6e
  Author: seyko   bad
  Date:   Wed Mar 4 10:57:13 2015 +0300
   a libraries paths
* x86_64-tcc: use /usr/lib64,.. instead of /usr/lib,..
* don't set tcc_lddir="lib64" if cpu="x86"

--- a/configure
+++ b/configure
 if test x"$bindir" = x""; then
 bindir="${execprefix}/bin"
 fi
-if test x"$tccdir" = x""; then
-tccdir="tcc"
-fi
 if test x"$docdir" = x""; then
 docdir="${sharedir}/doc/${tccdir}"
 fi

Then the right fix must be
- docdir="${sharedir}/doc/${tccdir}"
+docdir="${sharedir}/doc/tcc"

> Chris Marshall wrote: ---
> To be more specific, it should be possible to build the mingw version of tcc 
> on cygwin (I don't > know, haven't had time to try) but what I would like is 
> the linux/unix version---if it builds on
> unix, it should be buildable on cygwin---as long as you don't look under the 
> covers to find
> windows.

> gr
> Probably you could do that.  It is just that you'll find that
> such (almost true) linux/unix version of tcc will produce
> (entirely) true linux/unix programs.  And these will not
> run on windows, not even under cygwin.

I'm trying to do that, i.e MSYS2 unix. A big issue is not to define
_WIN32 which assume standalone mingw (tcc headers/libraries in
C:\Program Files\tcc) w/o MSYS2. mingw on MSYS2 can be different too
because there is all headers and libraries already present.

Executable names:
MSYS2:
  i386-tcc.exe
  x86_64-tcc.exe

Mingw on MSYS2 or standalone tcc installation:
  i386-win-tcc.exe
  x86_64-win-tcc.exe

By default target will be selected depending on msys2 shell
environment (MSYS2 or Mingw on MSYS2).

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

Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

> You can try my branch: https://github.com/avih/tinycc/commits/drafts (note, I 
> force-push and keep it rebased on top of mob).

First impression with this branch on Linux:
1)
fantoo tinycc # ./configure
Binary  directory   /usr/local/bin
TinyCC directory/usr/local/lib/tcc
Library directory   /usr/local/lib
Include directory   /usr/local/include
Manual directory/usr/local/share/man
Info directory  /usr/local/share/info
Doc directory   /usr/local/share/doc//usr/local/lib/tcc ??

2) there is no i386-tcc on i386 Linux even when "./configure --enable-cross"
But I need a i386-tcc to compile a tccboot kernel. Not a general tcc
wiich target is unknown.

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

[Tinycc-devel] -C option

[Sergey Korshunoff]

I simplified a -C option handling. Currently a code in my repo is like
in [mob]. Only check in parse_line_commen remain.
https://github.com/seyko2/tinycc/commit/acd6224a7fda62fe003e9901b85ef9a8d5dae851

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

Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

> With the prev fix I still have a tccboot kernel trap on PCI bus configuration.

What the purpose of the

-ALT(DEF_ASM_OP2(addb, 0x80, 0, OPC_ARITH | OPC_MODRM | OPC_BWLX,
OPT_IM, OPT_EA | OPT_REG))
 ALT(DEF_ASM_OP2(addw, 0x83, 0, OPC_ARITH | OPC_MODRM | OPC_WLX,
OPT_IM8S, OPT_EA | OPT_REG))
+ALT(DEF_ASM_OP2(addb, 0x80, 0, OPC_ARITH | OPC_MODRM | OPC_BWLX,
OPT_IM, OPT_EA | OPT_REG))

in the "Fix signed constants and opcode order" ?

With thise change reverted there is no problem with tccboot kernel.

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

Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

> Is the following patch correct?
With the prev fix I still have a tccboot kernel trap on PCI bus configuration.

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

Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

> .fill problem is not fixed (on i386)

Is the following patch correct?
diff --git a/tccasm.c b/tccasm.c
index b494398..9dcab1c 100644
--- a/tccasm.c
+++ b/tccasm.c
@@ -42,7 +42,7 @@ static void asm_expr_unary(TCCState *s1, ExprValue *pe)
 {
 Sym *sym;
 int op, label;
-long n;
+unsigned long n;
 const char *p;

 switch(tok) {

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

Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

.fill problem is not fixed (on i386)

linux/arch/i386/kernel/head.S:380: error: repeat < 0; .fill ignored

.org 0x1000
.globl swapper_pg_dir; .align 16,0x90; swapper_pg_dir:
<-->.long 0x00102007
<-->.long 0x00103007
<-->.fill ((0xC000) >> 22)-2,4,0

Is a shift arithmetic there?

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

Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

> And the second is not correct
The second in my answer is stddef.h patch (removing the typedefs from stddef.h)

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

Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

> The idea of using only tcc headers for lib/* compilation might sound good at 
> first, but tcc
> doesn't provide all standard headers (and shouldn't because it's not a full 
> toolchain with C
> library); it really relies on the existence of working/compatible target 
> headers that also the lib/* > implementation can use.

But we can compile a cross-tcc compilers on i386 host w/o right
headers for target.
Why we stop on lib/* compilation? lib/* is a small support library for
the target. It don't use/need a full target headers.

> So, I offer two patches for you to try.  The first (removing the typedefs 
> from stddef.h) is more > correct, and the second might be more compatible 
> with current behaviour.

The first patch don't helps. And the second is not correct: with this
patch a produced library use a host intptr_t (32 bit) for 64 bit
targets.

My solution is better in this aspect.

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

Re: [Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

> You can try my branch: https://github.com/avih/tinycc/commits/drafts (note, I 
> force-push and keep it rebased on top of mob).

>I wanted to push some/all of the commits on my "drafts" branch to mob after 
>some cleanups, but never really got to end up doing it. If there's enough 
>interest and my current drafts branc ends up usable for many, I'll reconsider 
>putting the effort.

Big thanks! I will try to test your branch. It is good to know any
usefull branch of the tcc.

PS: It was my first attempt to build tcc on Windows.. I think it is a
./configure error, which say OK for the unknown environment. Looking
like Unix, I expected tcc build in the Unix way.

PPS: For me Windows is foreign environment and configuring a PATH for
the compiler/utilities is a problem. MSYS2 with a package manager
looks like a primary target for the Unix man.

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

[Tinycc-devel] tcc compilation on MSYS2

[Sergey Korshunoff]

MSYS2 is current environment for Qt and other software development on
Windows. It is a mingw+cygwin with a package manager (pacman), ported
from ARCH Linux. MSYS2 allow to build
mingw32/mingw64/cygwin32/cygwin64 programs in unix-like environment.
Currenly tcc can not be build on this environment (mix of unix and
windows). I think a system name (uname output) is needed to
select/reject some code in sources of the tcc.

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

Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

> It might also simply be that your libc headers are incompatible with a 64bit 
> compilation (e.g. if
> you miss any WORDSIZE support from ). In that case we might 
> have to do
> more hackery, but generally it won't be possible on such a system to build 
> much software cross > (to 64bit) at all.

My glibc on host is quite old (2.9) Is the new glibc on i386 allow to
compile 64 bit code? How about muslim or uclibc headers? I think we
must use a tcc headers for lib/* compilation

PS: on my host /usr/include/bits/wordsize.h is
#define __WORDSIZE  32

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

[Tinycc-devel] patches for discussion

[Sergey Korshunoff]

I have the following patches in github repo (requests in tinycc bugzilla):

+ memory model macros __{L,}LP64__
https://github.com/seyko2/tinycc/commit/eb2a3a8ae941817a5bea7e561999b4c463873a0f

+ short_call_convention
https://github.com/seyko2/tinycc/commit/558614d3f822de03bb6267f47a24487faa69d29a

+ --whole-archive support
https://github.com/seyko2/tinycc/commit/65e42df4d0fedb340f42652bb49fdacc7bc3e05c

PS: there is request (Bugzilla) to implement
bug #37244: tinycc: lacks -nostartfiles -nodefaultlibs support, needed by Wine
http://savannah.nongnu.org/bugs/?37244

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

[Tinycc-devel] tcc helped to catch bug in linux 2.4.37 - 2.6.32

[Sergey Korshunoff]

Hi!
A bug in kernels 2.4.37.11, RHEL6u7 kernel 2.6.32-573.7.1.el6 found by
using tcc as compiler.
https://github.com/seyko2/tccboot/commit/cee8898165a7bc5aefa8170f6a0290fb2500acf4

Description:
  /* Test for the divl bug.*/ must be prefixed by call to the
kernel_fpu_begin().
Bug is fixed in 3.4 kernel. It is present in 3.0.36 kernel.

How to catched:
A tccboot kernel traps sometimes when compiled by tcc. A problem was
before and temporaly solved by reordering of the source file order.

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

Re: [Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

> Is this change must be for x86_64 only?
I reverted this patch in my github repo.
https://github.com/seyko2/tinycc/commit/e5250b8d5fc8782dcf5eaa9681d5111a223d9e69
It breaks cmany things: .rept, .fill, "and $-16, %rax"
(cross-compilation in i386)

Also
https://github.com/seyko2/tinycc/commit/74dcf589d7b2d67a3d0642a8ea56aa25c93f573a
[fix, cross] lib/* includes
There was errors in cross-compilation mode on i386:
../x86_64-tcc -B.. -c libtcc1.c
error: incompatible redefinition of 'intptr_t'
../x86_64-tcc -B.. -c bcheck.c
error: incompatible redefinition of 'ssize_t'

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

[Tinycc-devel] .fill .rept broken by "Clean up 64bit immediate support"

[Sergey Korshunoff]

Hi!
Compiling tccboot with "Clean up 64bit immediate support" there are an
error now:
linux/arch/i386/kernel/head.S:380: error: repeat < 0; .fill ignored
It is caused by

 typedef struct ExprValue {
-uint32_t v;
+uint64_t v;
 Sym *sym;
 } ExprValue;

Is this change must be for x86_64 only?

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

Re: [Tinycc-devel] what was purpose of -db ?

[Sergey Korshunoff]

I'm abount "tccpp: cleanup options -dD -dM, remove -C"
 case TCC_OPTION_d:
if (*optarg == 'D')
s->dflag = 3;
else if (*optarg == 'M')
s->dflag = 7;
else if (*optarg == 'b') // ???
s->dflag = 8;
else
goto unsupported_option;
 break;

2016-05-08 16:35 GMT+03:00 Sergey Korshunoff <sey...@gmail.com>:
> Subj.

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

[Tinycc-devel] what was purpose of -db ?

[Sergey Korshunoff]

Subj.

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

Re: [Tinycc-devel] Inserting spaces in output from -E

[Sergey Korshunoff]

> Updated patch... Maybe not finished, but must rush to school now...
> 2016-05-06-spaces.patch

May be it is quite good and can be pushed to the [mod]?
PS: currently one pp test fails.

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

Re: [Tinycc-devel] TOK_PPNUM for asm

[Sergey Korshunoff]

> > There may be a float numbers in assembler like 0x1eP+1 and 10e-1

> Are you sure that syntax is correct? Can you show an example that is
> accepted by GCC or TCC?

An example of float declaration (compiles by gcc but not tcc)
data
.global pi_minus
pi_minus:
.float 0f-31415926535897932384626433832795028841971.693993751E-40

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

Re: [Tinycc-devel] Inserting spaces in output from -E

[Sergey Korshunoff]

> I can imagine, but then again I'd maybe put the extended bit into
> the TokenSym rather than on the token number,  Like
>int is_extended = table_ident[v - TOK_IDENT]->is_extended;

This may be a good solution. An extra memory usage by tcc in such case
needs to be measured

PS: Current solution can compile kernel in one pass (no problem with
limited symbol range) and quite fast (bench is practically the same as
w/o exsymtab)

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

Re: [Tinycc-devel] TOK_PPNUM for asm

[Sergey Korshunoff]

> Also, presumably there's a good reason why your patch modified 43
> lines, rather than just one, as below. What is that reason?

There may be a float numbers in assembler like 0x1eP+1 and 10e-1 but
0x1e+1 must be parsed as 0x1e +1

2016-05-05 2:12 GMT+03:00 Edmund Grimley Evans :
>> > Proposed patch: handle 0x1e+1 as 0x1e +1 if (parse_flags & 
>> > PARSE_FLAG_ASM_FILE)
>>
>> Please explain and justify exactly what you're trying to do. What do
>> you believe the correct definition of a pp-number is when tokenising
>> assembly? What definition does the GNU toolchain use?
>
> Also, presumably there's a good reason why your patch modified 43
> lines, rather than just one, as below. What is that reason?
>
> diff --git a/tccpp.c b/tccpp.c
> index ad35687..7dd6d36 100644
> --- a/tccpp.c
> +++ b/tccpp.c
> @@ -2766,6 +2766,7 @@ maybe_newline:
>|| c == '.'
>|| ((c == '+' || c == '-')
>&& (t == 'e' || t == 'E' || t == 'p' || t == 'P')
> +  && !(parse_flags & PARSE_FLAG_ASM_FILE)
>)))
>  break;
>  }
>
> ___
> 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] 85-asm-outside-function.c on non Intel

[Sergey Korshunoff]

> Can you please check processor and adapt this test otherwise I get:

There is SKIP variable in test/test2/Makefile which holds test to skip.
You can test modifications and I not.

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

[Tinycc-devel] error: bad operand with opcode 'movq'

[Sergey Korshunoff]

Hi!
tcc don't understand xmm1 register (but understand mm1)
A test program:
int main (void)
{
long long d;
__asm__ __volatile__( "movq %0, %%mm1" : "=m" (d) );
__asm__ __volatile__( "movq %0, %%xmm1" : "=m" (d) );
return 0;
}
// test.c:5: error: bad operand with opcode 'movq'

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

Re: [Tinycc-devel] tcc bug: big exe in 1 step

[Sergey Korshunoff]

> The problem solved by a file list reordering. I think there may be a
> bug in tcc

No bug in tcc. But sections filling order differs for *.c and *.o A
problem was in user.c file calling slab allocator before its
initialization. Moving this file after slab.c in list solved a
problem.

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

Re: [Tinycc-devel] tcc bug: big exe in 1 step

[Sergey Korshunoff]

> 'm going to check a free memory in compilation of the each file

The problem solved by a file list reordering. I think there may be a
bug in tcc which don't check a destination of the call/jump when
compiling many files in one step.

Can I disable usage of the short call/jumps? Or this is the problem of
the fixups? What can be done?

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

Re: [Tinycc-devel] tcc bug: big exe in 1 step

[Sergey Korshunoff]

> This looks like a problem with tcc compiling a big code in one step
May be some memory must be free() when going to compile a next file
from the command line?
  tcc -o aaa.exe aaa1.c aaa2.c ... aaaN.c

I'm going to check a free memory in compilation of the each file.

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

[Tinycc-devel] tcc bug: big exe in 1 step

[Sergey Korshunoff]

Hi!
It looks like tcc have some bug when compiling a big exectutable in one step.
This is a tccboot kernel. When I added some additional files to
compile (PCI bus and ethernet)
then compiled kernel hags if compiled w/o specific option
-fnocode-if-false. This option is not needed for 2 steps (compile +
link) or 3 steps (preprocess + compile + link) builds.

-fnocode-if-false skips code generation for the BLOCK in
  if(0) {BLOCK}

This looks like a problem with tcc compiling a big code in one step.
This option was not needed with a smaller source base (before PCI
addition). What parms/limits can be changed to find a problem?
VSTACK_SIZE? What else?

May be there is limit on the resulting code? If we skip some code with
-fnocode-if-false then bug not exposed.

PS: There is no output from the kernel at all. VirtualBox window is
closed on start.

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

Re: [Tinycc-devel] lcall invalid hex code

[Sergey Korshunoff]

> > The mod/rm byte was simply missing from the encoding.  I've corrected this 
> > in mob.
> can you post a diff? I don't see any patch in the [mob]
Just tested the following patch for the lcall, all OK

diff --git a/i386-asm.h b/i386-asm.h
index 677519c..4e0a1c3 100644
--- a/i386-asm.h
+++ b/i386-asm.h
@@ -213,9 +213,9 @@ ALT(DEF_ASM_OP1(jmp, 0xff, 0, OPC_JMP | OPC_WL, OPT_REGW))
 #endif
.
 ALT(DEF_ASM_OP2(lcall, 0x9a, 0, 0, OPT_IM16, OPT_IM32))
-ALT(DEF_ASM_OP1(lcall, 0xff1f, 3, 0, OPT_EA))
+ALT(DEF_ASM_OP1(lcall, 0xff, 3, OPC_MODRM, OPT_INDIR))
 ALT(DEF_ASM_OP2(ljmp, 0xea, 0, 0, OPT_IM16, OPT_IM32))
-ALT(DEF_ASM_OP1(ljmp, 0xff, 5, 0, OPT_EA))
+ALT(DEF_ASM_OP1(ljmp, 0xff, 5, OPC_MODRM, OPT_INDIR))
.
 ALT(DEF_ASM_OP1(int, 0xcd, 0, 0, OPT_IM8))
 ALT(DEF_ASM_OP1(seto, 0x0f90, 0, OPC_MODRM | OPC_TEST, OPT_REG8 | OPT_EA))
diff --git a/x86_64-asm.h b/x86_64-asm.h
index 9b01a02..65934fb 100644
--- a/x86_64-asm.h
+++ b/x86_64-asm.h
@@ -199,8 +199,8 @@ ALT(DEF_ASM_OP1(jmp, 0xff, 4, OPC_MODRM, OPT_INDIR))
 ALT(DEF_ASM_OP1(jmp, 0xff, 0, OPC_JMP | OPC_WL, OPT_REGW))
 ALT(DEF_ASM_OP1(jmp, 0xeb, 0, OPC_SHORTJMP | OPC_JMP, OPT_ADDR))
.
-ALT(DEF_ASM_OP1(lcall, 0xff, 3, 0, OPT_EA))
-ALT(DEF_ASM_OP1(ljmp, 0xff, 5, 0, OPT_EA))
+ALT(DEF_ASM_OP1(lcall, 0xff, 3, OPC_MODRM, OPT_INDIR))
+ALT(DEF_ASM_OP1(ljmp, 0xff, 5, OPC_MODRM, OPT_INDIR))
.
 ALT(DEF_ASM_OP1(int, 0xcd, 0, 0, OPT_IM8))
 ALT(DEF_ASM_OP1(seto, 0x0f90, 0, OPC_MODRM | OPC_TEST, OPT_REG8 | OPT_EA))

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

Re: [Tinycc-devel] lcall invalid hex code

[Sergey Korshunoff]

> You realize that you can't simply copy random bytes around without 
> understanding the
> instruction encoding, right?  You took one specific instruction with its 
> specific operands and
> made that the "encoding" of all instructions with that mnemonic irrespective 
> of operands.

Yes, a patch was incorrect. A  patch for the next asm code bug:

fix the "bug #39341: TCC emits wrong opcode for XCHG"

#include 
int main() {
int i = 0x16789;
printf("Number:   %x\n", i);
__asm__ __volatile__ ("xchg %%ah, %%al;" : "=a" (i) : "0" (i));
printf("Reversed: %x\n", i);
}
// The asm instruction is 0x94 which is xchg %eax,%esp (according to objdump
// and ollydbg). This leads to an immediate segfault!
// The correct opcode would be 0x86 0xE0..

A bug description: a byte code ops must be declared _before_
a word codes in i386-asm.h and x86_64-asm.h

diff --git a/i386-asm.h b/i386-asm.h
index 637568b..677519c 100644
--- a/i386-asm.h
+++ b/i386-asm.h
@@ -135,10 +135,10 @@ ALT(DEF_ASM_OP1(popw, 0x58, 0, OPC_REG | OPC_WL,
OPT_REGW))
 ALT(DEF_ASM_OP1(popw, 0x8f, 0, OPC_MODRM | OPC_WL, OPT_REGW | OPT_EA))
 ALT(DEF_ASM_OP1(popw, 0x07, 0, OPC_WL, OPT_SEG))
.
-ALT(DEF_ASM_OP2(xchgw, 0x90, 0, OPC_REG | OPC_WL, OPT_REG, OPT_EAX))
-ALT(DEF_ASM_OP2(xchgw, 0x90, 0, OPC_REG | OPC_WL, OPT_EAX, OPT_REG))
 ALT(DEF_ASM_OP2(xchgb, 0x86, 0, OPC_MODRM | OPC_BWL, OPT_REG, OPT_EA
| OPT_REG))
 ALT(DEF_ASM_OP2(xchgb, 0x86, 0, OPC_MODRM | OPC_BWL, OPT_EA |
OPT_REG, OPT_REG))
+ALT(DEF_ASM_OP2(xchgw, 0x90, 0, OPC_REG | OPC_WL, OPT_REG, OPT_EAX))
+ALT(DEF_ASM_OP2(xchgw, 0x90, 0, OPC_REG | OPC_WL, OPT_EAX, OPT_REG))
.
 ALT(DEF_ASM_OP2(inb, 0xe4, 0, OPC_BWL, OPT_IM8, OPT_EAX))
 ALT(DEF_ASM_OP1(inb, 0xe4, 0, OPC_BWL, OPT_IM8))
diff --git a/x86_64-asm.h b/x86_64-asm.h
index df76bf0..9b01a02 100644
--- a/x86_64-asm.h
+++ b/x86_64-asm.h
@@ -124,10 +124,10 @@ ALT(DEF_ASM_OP1(popw, 0x58, 0, OPC_REG |
OPC_WLQ, OPT_REGW))
 ALT(DEF_ASM_OP1(popw, 0x8f, 0, OPC_MODRM | OPC_WLQ, OPT_REGW | OPT_EA))
 ALT(DEF_ASM_OP1(popw, 0x07, 0, OPC_WLQ, OPT_SEG))

-ALT(DEF_ASM_OP2(xchgw, 0x90, 0, OPC_REG | OPC_WLQ, OPT_REG, OPT_EAX))
-ALT(DEF_ASM_OP2(xchgw, 0x90, 0, OPC_REG | OPC_WLQ, OPT_EAX, OPT_REG))
 ALT(DEF_ASM_OP2(xchgb, 0x86, 0, OPC_MODRM | OPC_BWLQ, OPT_REG, OPT_EA
| OPT_REG))
 ALT(DEF_ASM_OP2(xchgb, 0x86, 0, OPC_MODRM | OPC_BWLQ, OPT_EA |
OPT_REG, OPT_REG))
+ALT(DEF_ASM_OP2(xchgw, 0x90, 0, OPC_REG | OPC_WLQ, OPT_REG, OPT_EAX))
+ALT(DEF_ASM_OP2(xchgw, 0x90, 0, OPC_REG | OPC_WLQ, OPT_EAX, OPT_REG))

 ALT(DEF_ASM_OP2(inb, 0xe4, 0, OPC_BWL, OPT_IM8, OPT_EAX))
 ALT(DEF_ASM_OP1(inb, 0xe4, 0, OPC_BWL, OPT_IM8))

PS:
> The mod/rm byte was simply missing from the encoding.  I've corrected this in 
> mob.
can you post a diff? I don't see any patch in the [mob]

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

[Tinycc-devel] bug #47379: Compare bug

[Sergey Korshunoff]

bug #47379: Compare bug
Please test/confirm on x86-64 (no bug on x86 Linux)

include 
#include 
int main(int argc, char* argv[]) {
printf("%d\n", -2147483648);
printf("%ld\n", -2147483648LL);
printf("%d\n", (1LL) < (-2147483648LL));
return 0;
}

tcc output:
-2147483648
-2147483648
1

gcc output:
-2147483648
-2147483648
0

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

Re: [Tinycc-devel] lcall invalid hex code

[Sergey Korshunoff]

> This is the current kernel on the my notebook: openvz containers,
> different drivers (acronis TrueImage, parallels ufsd, aufs, android
> binder and ashmem), 32 and 64 versions

An ISO with this kernel and android-x86 userland can be checked in VirtualBox
https://forum.openvz.org/index.php?t=msg=52031=90d4ac643a82cd2b85dcfe679554f07f=android#msg_52031

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

Re: [Tinycc-devel] lcall invalid hex code

[Sergey Korshunoff]

> What is invalid? Is the actual constant incorrect

Yes. Strange, but the actual constant was invalid. Catched by trap of
the tccboot with PCI bus configuration turned on (PCnet-PCI II for
VirtualBox).  lcall constant is used only in assmbler code.

pci-pc.c (linux 2.4.37.11)
static struct {
unsigned long address;
unsigned short segment;
} bios32_indirect = { 0, __KERNEL_CS };

/*
 * Returns the entry point for the given service, NULL on error
 */

static unsigned long bios32_service(unsigned long service)
{
unsigned char return_code;<>/* %al */
unsigned long address;<><-->/* %ebx */
unsigned long length;<-><-->/* %ecx */
unsigned long entry;<--><-->/* %edx */
unsigned long flags;

__save_flags(flags); __cli();
__asm__("lcall (%%edi); cld"
: "=a" (return_code),
  "=b" (address),
  "=c" (length),
  "=d" (entry)
: "0" (service),
  "1" (0),
  "D" (_indirect));
__restore_flags(flags);

switch (return_code) {
case 0:
return address + entry;
case 0x80:  /* Not present */
printk(KERN_WARNING "bios32_service(0x%lx): not
present\n", service);
return 0;
default: /* Shouldn't happen */
printk(KERN_WARNING "bios32_service(0x%lx): returned 0x%x
-- BIOS bug!\n",
service, return_code);
}
}

A right constant value was detected by comparing *.o produced by gcc
and tcc (objdump -Dtsr test.o)

PS: I'm going to use tcc for compilation of the openvz-2.6.32 kernel.
This is the current kernel on the my notebook: openvz containers,
different drivers (acronis TrueImage, parallels ufsd, aufs, android
binder and ashmem), 32 and 64 versions, Compilation of this kernel for
the ARM processors is waiting.

https://github.com/seyko2/openvz_rhel6_kernel_mirror

cellRocks patches are published on gitthub and partially ported to
this kernel too (todo on my whish list)
https://github.com/Cellrox/devns-patches

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

[Tinycc-devel] lcall invalid hex code

[Sergey Korshunoff]

Hi!

diff --git a/i386-asm.h b/i386-asm.h
index 486cffe..637568b 100644
--- a/i386-asm.h
+++ b/i386-asm.h
@@ -213,7 +213,7 @@ ALT(DEF_ASM_OP1(jmp, 0xff, 0, OPC_JMP | OPC_WL, OPT_REGW))
 #endif
.
 ALT(DEF_ASM_OP2(lcall, 0x9a, 0, 0, OPT_IM16, OPT_IM32))
-ALT(DEF_ASM_OP1(lcall, 0xff, 3, 0, OPT_EA))
+ALT(DEF_ASM_OP1(lcall, 0xff1f, 3, 0, OPT_EA))
 ALT(DEF_ASM_OP2(ljmp, 0xea, 0, 0, OPT_IM16, OPT_IM32))
 ALT(DEF_ASM_OP1(ljmp, 0xff, 5, 0, OPT_EA))

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

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

a 3rd version of the patch attached

2016-05-01 5:52 GMT+03:00, Sergey Korshunoff <sey...@gmail.com>:
>> No result.  Make the patch 10 lines in the right place instead
>> of 60 lines in the wrong place, and it will work.
>
> Where is the right place? That is the question.
>
> PS: a modified version attached.
> Algorithm changed: we can expand a next macro too.
>


03-space_after_TOK_PPNUM.patch.gz
Description: GNU Zip compressed data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

> No result.  Make the patch 10 lines in the right place instead
> of 60 lines in the wrong place, and it will work.

Where is the right place? That is the question.

PS: a modified version attached.
Algorithm changed: we can expand a next macro too.


02-space_after_TOK_PPNUM.patch.gz
Description: GNU Zip compressed data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] how to name a switch

[Sergey Korshunoff]

> void vide(void); __asm__("vide: ret");
> int main() {
>vide();
>return 0;
> }

No switch is needed. if (nocode_wanted) then this feature is used. Not
perfect, but there is no flag indicating compilation of the function
body.
https://github.com/seyko2/tinycc/commit/97b41548083fbe5332dbace8eb35390c5215a833

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

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

>PS: what about output with -E should include spaces: #define n 0xe 
> {newline} n+1
> You mean the attempts on your branch?  Horrible, of course ;)

I mean attached patch. It is not abount X(X(1)), but about
preprocessor output for
#define n 0xe
n+1
It must look like
0xe +1
and not
0xe+1

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

Re: [Tinycc-devel] tcc build on OSX

[Sergey Korshunoff]

>> How to check a OSX target in *.c code? Any proposal?
> #ifdef __APPLE__

This means that tcc for Darwin must define __APPLE__ too?

PS: there is a code in tcc which must be #ifdef -ed. for Darwin. But
we don't have CONFIG_TARGETOS in config.h

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

Re: [Tinycc-devel] tcc build on OSX

[Sergey Korshunoff]

> FYI, I found it helpful (necessary? I don't remember) to include the 
> following typedefs when
> working with Mac:

Thanks. I will play with pipcet version of the tinycc and your (run4flat)

PS: it will be nice if you put a travis-CI build status in README.md
(as I done following  wqweto) https://github.com/seyko2/tinycc

PPS: I go to place in README.md links to the other usefull branches of the tcc:

https://github.com/tinycc/tinycc
  Mirror from mob branch http://repo.or.cz/w/tinycc.git

https://github.com/pipcet/tinycc
  tinycc for perl jit?

https://github.com/run4flat/tinycc
 exsymtab patch/extension main source

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

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

> A useful patch that does not add lines:
Yes, a master stroke.

PS: what about
output with -E should include spaces: #define n 0xe {newline} n+1


01-space_after_TOK_PPNUM.patch
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] tcc build on OSX

[Sergey Korshunoff]

Hi!
Just started travis-CI builds with OSX configuration.
After adding a linker options
-Wl,-flat_namespace,-warning,unsupported, I faced with the following
problem:

1. abitest-tcc is compiled w/o -run option and crt1.o crti.o are not found
2. /usr/include/sys/cdefs.h:81: warning: #warning "Unsupported compiler"
  ../tccpp.c:3413: warning: implicit declaration of function 'snprintf'
  ../tccelf.c:2500: warning: implicit declaration of function 'fdopen'
  ../tccrun.c:429: error: invalid type

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

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

> And currently output is identical for the case #define A B+1

correction for X(X(X(X(X(1)
https://github.com/seyko2/tinycc/commit/a95cb9a7d90f844fb6f5e8f14eaa8798af71577f

I think a patch is quite usefull. It adds a right replacement for the
nested macro calls and don't break any other cases for macro calls.
But any additional cases when new algo don't work are welcom.

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

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

> Thanks. Segfaults fixed. And even the output of the tcc and gcc for
> the above test is the same (but not if #define A B+1)

And currently output is identical for the case #define A B+1
https://github.com/seyko2/tinycc/commit/bfc3e1dbd810de79a85903728c55218e65b461f1

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

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

> Bad idea :
#define A B
#define B A
return A + B;

Thanks. Segfaults fixed. And even the output of the tcc and gcc for
the above test is the same (but not if #define A B+1)
https://github.com/seyko2/tinycc/commit/ddeed8dda55b6d0f8b8cc19bfcba4fe1b91dc3b2

PS: start point: tcc don't expand X(X(1)), current state: sometime tcc
detects recursion at some later point then gcc

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

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

> The recommendation is:
>  Implementations should avoid imposing fixed translation limits
>  whenever possible.

Implemented adddition is a macro recursion detection:
 * on define macro stage (is the name of macro can be found in macro string)
 * on macro call stage (is the name of macro can be found in args)

If macro or call is not recursive then we don't block expansion.
Behaviour is the same as gcc have. All tcc preprop test pass. A
compilation speed is not changed.

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

Re: [Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

Hi!
A problem solved. A patch
https://github.com/seyko2/tinycc/commit/152d0fb3275169c8f4eca97f4f90ec85f437ae4c
https://github.com/seyko2/tinycc/commit/bc60d942e52f7e8cb9392dd0e6e6a79b42fcd054

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

Re: [Tinycc-devel] parsing 0x1e+1 as 0x1e +1

[Sergey Korshunoff]

@Vincent Lefevre
Big thanks!

PS: I added right -E output for the a +P+ b test and commented out
NEW_PPNUM_CODE
https://github.com/seyko2/tinycc/commits/github

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

Re: [Tinycc-devel] parsing 0x1e+1 as 0x1e +1

[Sergey Korshunoff]

> CompCert 2.4 outputs 0x10 0x1e (following its interpretation of 6.4.8)
> though if the user expects a subtraction in both cases, he probably
> expects that E yields the same value in both cases

pcc outputs 0x10 0x1e too. But tcc with first patch outputs 0x10 0x1d
(as user expects)

PS: a second patch attached which allows to add space after 0x1e. It
is based on scanning expanded string of the macro in next(). and
checking some rules. For example, a patch inserts a space after
TOK_PPNUM which followed by '+' or '-'. May be this is needed only
when -E is given..


02-macro-expansion.patch
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] parsing 0x1e+1 as 0x1e +1

[Sergey Korshunoff]

> he following program is correctly rejected by both GCC and TCC, with
> fairly similar error messages:
> int main() { return 0x1e+1; }

Check pcc.

> There should be a space between 0x1e and +1 (see for instance, the
> output of "gcc -E", "clang -E" and "icc -E")

Space is not required. Check pcc. 0x1e+1 is parsed as 0x1e +1. If
icc/gcc/clang. complain, then this is theire problem. eE is valid exp
char only for decimal notation. And for hexadeciamal notation it is an
ordinal digit char.

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

[Tinycc-devel] parsing 0x1e+1 as 0x1e +1

[Sergey Korshunoff]

Hi!
A problem solved (as someone suggested on the list) by teaching tcc to
recognize right exponent chars in next_nomacro1().(no any space chars
after macro expansion). This is like pcc do. A test prgram:

extern int printf(const char *format, ...);
#define ACPI_TYPE_INVALID 0x1E
#define NUM_NS_TYPES ACPI_TYPE_INVALID+1
int array[NUM_NS_TYPES];
#define n 0xe
int main() {
printf("n+1 = %d\n", n+1);
}

prints 15
And preprocessor output is
...
printf("n+1 = %d\n", 0x1e+1);.

https://github.com/seyko2/tinycc/commit/132a3366132a34d55c67f0b73a14e634219bae93

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

[Tinycc-devel] X(X(1)) (nested macro substitution)

[Sergey Korshunoff]

About
#define Y(x) Z(x)
#define X Y
X(X(1))

If comment out in tccpp.c the following lines
/* if nested substitution, do nothing */
if ( (!s->next)
&& sym_find2(*nested_list, t))
{
/* and mark it as TOK_NOSUBST, so it doesn't get subst'd again */
tok_str_add2(tok_str, TOK_NOSUBST, NULL);
goto no_subst;
}
then we get the right result  Z(Z(1) (but tcc loops in other macro
substiturion cases).
Currently we get Z(Y(1)), i.e. Y() is added to the nosubst_list affter
first substitution.

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

Re: [Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

> The problem is not so urgent that it's worth fixing it badly
Some work is done.
https://github.com/seyko2/tinycc/commit/f054611dc73a085c15085458c195d632b64d4135
https://github.com/seyko2/tinycc/commit/7b3a197f20483967950e5ec32c2e0dc76af8a28f
A more test cases are needed.

> - Make -E add spaces in the same way that GCC adds them (if that's not
too complicated).

This is not possible w/o syntax analize

> Also, what is the point of having a -E1 option that is only used by
> tests that test something that nobody uses?

Make tcc compatible with pcc :-)
A pp test suit is quite well tested and getting *.expect files by gcc
is very simple.
But yes,I go to remove -E1 and make *.expect files by hand (no
automatic creation)

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

Re: [Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

> I don't like it, and I don't think we need it. Also, it doesn't fix
> the TODO because the output with -E is still wrong.

Just tested pcc. The output is identical to the tcc one.

PS: We can change meaning of the -E and -E1. Then -E will add a space
char after macro expansion and -E1 can be used for the pp tests.
Otherwise this problem can not be solved.

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

Re: [Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

> Many pp tests now fails.
> May be we can introduce -E1 option for the output with a space
> after macro expansion.

https://github.com/seyko2/tinycc/commit/231157675ccebf9830b4e8608785f38dea41fbe0

-E1 option
add space after macro expansion. This is fix for the following TODO:
- output with -E should include spaces: #define n 0xe {newline} n+1

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

Re: [Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

> Is it possible to ignore space after macro in tests?

Or we must prepare *.expect files by tcc and don't use gcc for this.

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

Re: [Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

> Many pp tests now fails. Is it possible to ignore space after macro in tests?
Or may be we can introduce -E1 option for the output with a space
after macro expansion.

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

Re: [Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

> Then I'll make the following addition to the bug list, if nobody
> objects, as I don't suppose the bug will get fixed soon.
> +- output with -E should include spaces: #define n 0xe {newline} n+1

How gcc decide when to insert space after macro expansion w/o syntax analize?
A dumb rule: insert space after macro expansion. I implemented this.
What the result? test/pp/01.c
char p[] = "x ## y"; // gcc
char p[] = "x ## y" ; // tcc (a space after \" and before \;)
Many pp tests now fails. Is it possible to ignore space after macro in tests?

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

Re: [Tinycc-devel] how to name a switch

[Sergey Korshunoff]

> So, vide is not marked global with GCC either.  Can you show us a complete 
> example where > GCC and TCC behaviour differs?

void vide(void); __asm__("vide: ret");
int main()
{
vide();
return 0;
}

There was discussion above this
https://lists.nongnu.org/archive/html/tinycc-devel/2015-05/msg00094.html

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

Re: [Tinycc-devel] -fno-hex-floats option

[Sergey Korshunoff]

>> Some time before I have troubles compiling 2.4.26 code with tcc.

>Which version of TCC, and were you just compiling with TCC, or were
>you preprocessing with TCC and then trying to compile the preprocessed
>file?

I can't remember. I simply added spaces.

PS: is it allowed to disable hex float format in asm file/string?

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

Re: [Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

> Has TCC always had this bug, or was it introduced recently?
I don't found a correct tcc version (starting since 2013)

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

Re: [Tinycc-devel] -fno-hex-floats option

[Sergey Korshunoff]

> My first attempt was to disable such format in asm files/strings.
https://github.com/seyko2/tinycc/commit/f2f01c4c25be72de7266973ea80489a529f81ab3

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

[Tinycc-devel] how to name a switch

[Sergey Korshunoff]

I need some switch to allow tcc behave like gcc/pcc in the code:
  void vide(void); __asm__("vide: ret");
like
  void vide(void); __asm__("globl vide\nvide: ret");

When the right solution is to ask developers to write asm code correctly,
there is many such code in linux kernels. How to name this switch?

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

Re: [Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

> Look at the __ie16_to_cpu presence in the tcc output: nested macro was
not expanded

But if we define le16_to_cpu with arg, i.e
-#define le16_to_cpu __le16_to_cpu
+#define le16_to_cpu(x) __le16_to_cpu(x)

then tcc output is OK. I used gcc 3.4.6 and 4.1.2 to test. May be new
versions of the gcc behave like tcc.

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

[Tinycc-devel] gcc/tcc nested macros difference

[Sergey Korshunoff]

Hi!
A test file:
#define __le16_to_cpu(x) ((__u16)(x))
#define le16_to_cpu __le16_to_cpu
static void pcnet32_load_multicast (struct net_device *dev)
{
mcast_table [crc >> 4] = le16_to_cpu(le16_to_cpu(mcast_table [crc
>> 4]) | (1 << (crc & 0xf)));
return;
}

GCC -E output:
...
mcast_table [crc >> 4] = ((__u16)(((__u16)(mcast_table [crc >>
4])) | (1 << (crc & 0xf;

TCC -E output:
...
mcast_table [crc >> 4] = ((__u16)(__le16_to_cpu(mcast_table [crc
>> 4]) | (1 << (crc & 0xf

Look at the __ie16_to_cpu presence in the tcc output: nested macro was
not expanded.

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

Re: [Tinycc-devel] if (0 == 1) { some_code(); }

[Sergey Korshunoff]

What to do with 78_vla_label test? May be a tcc switch to skip unused code?
void f1(int argc) {
  char test[argc];
  if(0)
  label:
printf("boom!\n");
  if(argc-- == 0)
return;
  goto label;
}

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

Re: [Tinycc-devel] if (0 == 1) { some_code(); }

[Sergey Korshunoff]

> A call to the printf is present
To skip a block I need to know if (COND) was const and false from the gvtst()

T_FUNC int gvtst(int inv, int t)
{
int v = vtop->r & VT_VALMASK;
if (v != VT_CMP && v != VT_JMP && v != VT_JMPI) {
vpushi(0);
gen_op(TOK_NE);
}
if ((vtop->r & (VT_VALMASK | VT_LVAL | VT_SYM)) == VT_CONST) {
/* constant jmp optimization */
if ((vtop->c.i != 0) != inv)
t = gjmp(t);
vtop--;
return t;
}
return gtst(inv, t);
}

But currently this is unpossible. Use a static variable? Or introduce
another gvtst with 3 parms?

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

Re: [Tinycc-devel] if (0 == 1) { some_code(); }

[Sergey Korshunoff]

> May be it don't generate a code, but a reference to the
A test program:

extern int printf(const char *format, ...);
main() {
if(0 == 1)
printf("There must be not printf reference in *.o\n");
return 0;
}

a gcc test.o disassembled:
Disassembly of section .text:
 :
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   83 ec 08sub$0x8,%esp
   6:   83 e4 f0and$0xfff0,%esp
   9:   b8 00 00 00 00  mov$0x0,%eax
   e:   83 c0 0fadd$0xf,%eax
  11:   83 c0 0fadd$0xf,%eax
  14:   c1 e8 04shr$0x4,%eax
  17:   c1 e0 04shl$0x4,%eax
  1a:   29 c4   sub%eax,%esp
  1c:   b8 00 00 00 00  mov$0x0,%eax
  21:   c9  leave
  22:   c3  ret

a tcc test.o disassmbled:
isassembly of section .text:

 :
   0:   55  push   %ebp
   1:   89 e5   mov%esp,%ebp
   3:   81 ec 00 00 00 00   sub$0x0,%esp
   9:   e9 0e 00 00 00  jmp1c 
   e:   b8 00 00 00 00  mov$0x0,%eax
f: R_386_32 L.0
  13:   50  push   %eax
  14:   e8 fc ff ff ff  call   15 
15: R_386_PC32  printf
  19:   83 c4 04add$0x4,%esp
  1c:   b8 00 00 00 00  mov$0x0,%eax
  21:   e9 00 00 00 00  jmp26 
  26:   c9  leave
  27:   c3  ret

A call to the printf is present.

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

[Tinycc-devel] precompiled headers

[Sergey Korshunoff]

Hi!
> David Mertens wrote:
> If there is an argument to be made for including exsymtab, it would probably 
> be based on these results. It is plausible to use symbol table caching and 
> serializing/deserializing to avoid loading and parsing standard header files. 
> This could potentially reduce compilation times. If you (we?) could show 
> measurable performance gains with such a modification, then it might get 
> broader support for being included with tcc.

As I see this today. For example, I prefer to speed up tccboot kernel
compilation.
A current command to compile is like
  tcc -o vmlinux linux/kernel/init.c linux/arch/kernel/head.c ...

With -cheaders[=dDIR] option tcc will precompile headers in each *.c
before  the first C token is seen and create files
[DIR]linux/kernel/init.tch, [DIR]linux/arch/kernel/head.tch,...  or
use these files if they already present. I think this is better and
don't need a special tuning.

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

Re: [Tinycc-devel] if (0 == 1) { some_code(); }

[Sergey Korshunoff]

> generate code for the false branch. As I remember, there was work to skip 
> this.
Why it is not work for the above?

May be it don't generate a code, but a reference to the
cpu_2_physical_apicid as external
symbol is recorded and link phase failed.

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

[Tinycc-devel] if (0 == 1) { some_code(); }

[Sergey Korshunoff]

Hi!
Currently the code

/*emum for clustered_apic_mode values*/
enum{
 CLUSTERED_APIC_NONE = 0,
 CLUSTERED_APIC_XAPIC,
 CLUSTERED_APIC_NUMAQ
};
/* pick a single cpu for clustered xapics */
if((CLUSTERED_APIC_NONE) == CLUSTERED_APIC_XAPIC){
  int cpu = ffs(mask)-1;
  mask = cpu_2_physical_apicid[cpu];
}

generate code for the false branch. As I remember, there was work to skip this.
Why it is not work for the above?

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

[Tinycc-devel] -fno-hex-floats option

[Sergey Korshunoff]

Hi!
https://github.com/seyko2/tinycc/commit/086ae74b696b7e2a73980bd852516b84251bd553

don't accept 0x123e-3 float format. This allow to compile
tccboot kernel with a macro expansion like
__asm__( "pushl $""0xfe""-256\n\t" );

gcc don't have problem with this w/o any option. May be gcc don't
allow a hex floats format in asm file.

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

Re: [Tinycc-devel] First kcachegrind output

[Sergey Korshunoff]

exsymtab:
>  It is plausible to use symbol table caching and serializing/deserializing to 
> avoid loading and parsing standard header files

Nice idea! Thanks.Something like precompiled headers. tcc must be able
to compile a *.h file and build *.tch one (if there is only one *.h in
the project main.c file). And then use this file insteed of the *.h.
May be a new switch (or pragma) will be needed?

https://gcc.gnu.org/onlinedocs/gcc/Precompiled-Headers.html

PS: But I like idea to use tcc with perl too.(just in time compiler)

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

[Tinycc-devel] vectorize the curent hash implementation

[Sergey Korshunoff]

Hi!
> IMO, the way to go w/ performance improvement is to vectorize the curent hash 
> implementation. Instead of computing the hash one character at a time, take 
> next 4 characters, process these in parallel and compute 4 hashes

How to implement this?
There is some hash optimization for the tcc compiled by gcc.
https://github.com/seyko2/tinycc/commit/b89f0d63af4f494a83c91fb0360d7d37c0f6f9a3

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

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

>> Here is a patch that tweaks it to use separate static CString buffer
>Don't helped.

Fixed on [mob]. Please verify.

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

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

> Here is a patch that tweaks it to use separate static CString buffer
Don't helped.

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

> In any event, it is odd to me that any software compiled entirely from source
> should care about this sort of alignment. It should leave such issues up to
> the compiler, as an implementation detail, shouldn't it?

In the source code we can ask about a section where to place result,
an alignment
of the result, but not alignment (padding) of the section itself. I.e.
how sections of the
same name (from different source code) are combined.

PS: A description of the linux initial code: a name (pointer) of the
init function is placed in
the special section. And after kernel start this functions are called.
If section padding
is more then sizeof(pointer), then there are null pointers and we have a trap

A special section for this is used to free memory after start (no need
after start).

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

> 0x1234-123 parsed by tcc as float number
May be 0x0fe-123 (as macro expansion, I can't remember now)

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

> That's a good bit of sleuthing. A couple of questions immediately come to 
> mind:
>Why does gcc and pcc take 4 as their alignment? Why do we take 32?
I'm not a guru. But tcc behaviour cost me a day of the problem discovering

>Does this have any performance impact?
I don't think so. This alignment is for unusual sections, not for
.text .data and so.

>Is there a reason you are implementing this with #ifdef?
I don't know about gcc defaults on different ARCH

> Might we use a preprocessor value (i.e. TCC_DEFAULT_ALIGNMENT) and #define 
> that in architecture-specific header files instead?
May be. But problem exposed only on i386.

PS: another problem: 0x1234-123 parsed by tcc as float number by
default and there is no switch to dsiable this. And gcc-3.4.6 (4.1.2)
understand the above as expression 0x1234 - 123 by default.

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

[Tinycc-devel] [mob] is moderated now?

[Sergey Korshunoff]

Hi!
I have 3 patches to submit. But now I can't, nothing happens.

commit a07946980624b1cfe4955a329c49bfe704a2cfb7
Author: seyko 
Date:   Thu Apr 21 01:32:22 2016 +0300

.rept asm directive

and '.' alone is a token now in *.S (not an identifier)
representing a current position in the code (PC).

commit 6ac0883e3035768afb3e584f579cb341d60a9207
Author: seyko 
Date:   Thu Apr 21 01:30:45 2016 +0300

section alignment on ARCH=i386 changed

Alignment of unknown sections changed from 32 to 4.
This is gcc/pcc default value.

commit 647c09f5a66a73c4a6769d972771f4bcc85a5228
Author: seyko 
Date:   Thu Apr 21 01:28:46 2016 +0300

source and destination overlap in memcpy, cstr_cat (tccpp.c:322)

Fix, this code is from "Improve hash performance"

commit cdc16d428f32294aa06b293fb81123f418e38b82
Author: Vlad Vissoultchev 
Date:   Sun Apr 17 16:22:50 2016 +0300

Reduce allocations overhead

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

> A problem may be in the section aligment: gcc sets this to 4 and tcc to 32.
Just checked. I used a hex editor to replace a 0x20 bytes in mem-2.o with 0x04.
This helped.

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

Re: [Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

A problem may be in the section aligment: gcc sets this to 4 and tcc to 32.
Where in the source this is fixed?

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

[Tinycc-devel] tcc as compiler for tccboot

[Sergey Korshunoff]

Hi!
I'm trying to use tcc as CC compiler for usual kernel compilation (2.4.37) i.e.
  cd linux
  make bzImage CC=tcc

Kernel compiles fine, but hangs some time after start. After
Investigating a problem, I got the following difference: a file
mem-2.s (a part of the file drivers/char/mem.c)
.section .initcall.init
.long chr_dev_init

objdump -Dtsr mem-2.o (compiled by gcc)

mem-2.o: file format elf32-i386
SYMBOL TABLE:
 ld  .text<> .text
 ld  .data<> .data
 ld  .bss<-> .bss
 ld  .initcall.init> .initcall.init
 *UND*<> chr_dev_init
Disassembly of section .initcall.init:
 <.initcall.init>:
   0:<->00 00<->add%al,(%eax)
<--><--><-->0: R_386_32<--->chr_dev_init

objdump -Dtsr mem-2.o (compiled by tcc)
mem-2.o: file format elf32-i386
SYMBOL TABLE:
 ldf *ABS*<> mem-2.s
 *UND*<> chr_dev_init
Disassembly of section .initcall.init:
 <.initcall.init>:
   0:<->00 00<->add%al,(%eax)
<--><--><-->0: R_386_32<--->chr_dev_init

As you can see, there is only one difference:
in mem-2.o compiled by gcc  we see extra data in symbol table
 ld  .text<> .text
 ld  .data<> .data
 ld  .bss<-> .bss
 ld  .initcall.init> .initcall.init
Nothing serious. But kernel hangs with mem-2.o compiled by tcc.
May be gnu ld needs that? Is it possible to modify tcc in the way like gcc?

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

[Tinycc-devel] Compilation on Mac

[Sergey Korshunoff]

Hi!
> David Mertens:
> My fork dates back to 2013. At that time, [mob] compiled on Mac, Linux, and 
> Windows, and > "tcc -run" functioned on all three platforms. This 
> functionality is critical for my uses. In the
> summer of 2014 I decided to update my fork by merging in the latest [mob], 
> only to discover > that tcc no longer compiled on Mac!

Is there someone who can help to improve current tcc for Mac?
Is it possible to download some MacOS ISO (x86)?

PS: I never tried to use MacOS.

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

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

Using a tcc compiled by CC="tcc -b" results only
step 1: compile & link
bcheck.c bound_error: realloc'ing invalid pointer
error: compilation failed

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

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

> And "valgrind  --leak-check=full " provides no help?
A valgrind report about invalid realloc attached.


valgrind-report.txt.gz
Description: GNU Zip compressed data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

>> And "valgrind  --leak-check=full " provides no help?
> I just discovered. A help fron the tcc (MEM_DEBUG) was expected.

A quick result (on the start of compilation):
CC=valgrind --leak-check=full i386-tcc -D__GNUC__=2
-D__GNUC_MINOR__=95 -fold-struct-init-code -bench
step 1: compile & link
==11033== Memcheck, a memory error detector
==11033== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==11033== Using Valgrind-3.9.0 and LibVEX; rerun with -h for copyright info
==11033== Command: i386-tcc -D__GNUC__=2 -D__GNUC_MINOR__=95
-fold-struct-init-code -bench -o vmlinux -nostdlib -static -Wl
==11033== Source and destination overlap in memcpy(0x4317d94, 0x4317d94, 2)
==11033==at 0x402879F: memcpy (in
/usr/lib/valgrind/vgpreload_memcheck-x86-linux.so)
==11033==by 0x804979A: cstr_cat (tccpp.c:322)
==11033==by 0x804B0A8: macro_is_equal (tccpp.c:1294)
==11033==by 0x804BAA2: define_push (tccpp.c:1387)
==11033==by 0x804BA5C: parse_define (tccpp.c:1604)
==11033==by 0x804C28E: preprocess (tccpp.c:1792)
==11033==by 0x804DD33: next_nomacro1 (tccpp.c:2649)
==11033==by 0x804DAD4: next_nomacro_spc (tccpp.c:2986)
==11033==by 0x804E90B: next_nomacro (tccpp.c:2993)
==11033==by 0x804F874: next (tccpp.c:3525)
==11033==by 0x805B832: decl0 (tccgen.c:6283)
==11033==by 0x805BEC9: decl (tccgen.c:6497)
==11033==.

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

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

> Can you test w/ "Reduce allocations overhead" reverted? Sounds like some
> edge-case there is failing, unfortunately.

Yes, with patch reverted all OK. A more checks with MEM_DEBUG are needed
(I checked patch with and w/o this option, no difference).

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

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

> And "valgrind  --leak-check=full " provides no help?
I just discovered. A help fron the tcc (MEM_DEBUG) was expected.

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

Re: [Tinycc-devel] Preprocessor performance tuning

[Sergey Korshunoff]

Hi Vladimir Vissoultchev
> Just comitted the patch to mob. Before that fixed the failing test and split
> the patch in two so that the allocators could easily be reversed if problems
> crop up.

Just discovered on tccboot-2.4.37. After "Reduce allocations overhead"
compilation
craches. Where is it in the tcc code -- don't know. Even with MEM_DEBUG there
is no help from tcc.

CC=i386-tcc -D__GNUC__=2 -D__GNUC_MINOR__=95 -fold-struct-init-code -bench

step 1: compile & link
*** glibc detected *** i386-tcc: realloc(): invalid pointer: 0xb7071fcc ***
=== Backtrace: =
/lib/libc.so.6[0xb7681d0e]
/lib/libc.so.6(realloc+0x286)[0xb7684a26]
i386-tcc[0x8068116]
i386-tcc[0x804967b]
i386-tcc[0x80496d0]
i386-tcc[0x804971b]
i386-tcc[0x8065659]
i386-tcc[0x80659db]
i386-tcc[0x8059914]
i386-tcc[0x8058efd]
i386-tcc[0x805b4a0]
i386-tcc[0x805b691]
i386-tcc[0x8068fd6]
i386-tcc[0x8069a7e]
i386-tcc[0x8069c8b]
i386-tcc[0x806bfea]
/lib/libc.so.6(__libc_start_main+0xe4)[0xb7631ff4]
i386-tcc[0x80491d1]
=== Memory map: 
08048000-08074000 r-xp  00:13 34 /usr/local/bin/i386-tcc
08074000-08075000 r--p 0002b000 00:13 34 /usr/local/bin/i386-tcc
08075000-08076000 rw-p 0002c000 00:13 34 /usr/local/bin/i386-tcc
08076000-08088000 rw-p  00:00 0
09a69000-09db7000 rw-p  00:00 0  [heap]
b6cae000-b6eaf000 rw-p  00:00 0
b6f97000-b6f9f000 r-xp  00:13 7939
/usr/lib/gcc/i486-pc-linux-gnu/3.4.6/libgcc_s.so.1
b6f9f000-b6fa r--p 7000 00:13 7939
/usr/lib/gcc/i486-pc-linux-gnu/3.4.6/libgcc_s.so.1
b6fa-b6fa1000 rw-p 8000 00:13 7939
/usr/lib/gcc/i486-pc-linux-gnu/3.4.6/libgcc_s.so.1
b6fb-b6ff1000 rw-p  00:00 0
b6ff2000-b7073000 rw-p  00:00 0

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

Re: [Tinycc-devel] '.' as code position in asm_expr_unary()

[Sergey Korshunoff]

> Probably on PARSE_FLAG_ASM_FILE would be better to leave single dots as tok
= '.' -- that is when next char is not IS_ID it will not become a symbol on
its own.

A patch for the asm .rept/.endr directives
https://github.com/seyko2/tinycc/commit/41356cad25119a1c0d1bdac85991657b4fdf829f
and '.' alone is a token now in *.S (not an identifier)
representing a current position in the code (PC).

PS: I don't know now how to commit to the [mob] branch

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

Re: [Tinycc-devel] Development style

[Sergey Korshunoff]

> When somebody explains the purpose of those changes I'm fairly sure we can 
> develop something that doesn't need to be tacked on the side of tcc like a 
> wart and needs 3000 lines to implement.  That is all work (in discussion 
> and/or implementation) that you should have done _before_ committing 
> something that controversial.

What was discussed simce may 2015?  And patch is about using tcc as
JIT and embedded in the app compiler. A patch include a lot of the
examples how to use tcc for this purpose.

> "let's wait a few more months"

I waited 12 months.

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

Re: [Tinycc-devel] Development style

[Sergey Korshunoff]

> 5. Push your changes to here: "git push 
> ssh://m...@repo.or.cz/srv/git/tinycc.git mypatch:mob"

I don't understand. The above is exactly the same what is in my PUSH.sh script.

PS: Please say what to do with my local repo. How to sync my local
repo with [mob]?

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

Re: [Tinycc-devel] Development style

[Sergey Korshunoff]

> exsymtab is a huge addition to tcc. It should not go in without a serious 
> discussion and code > review

Do you look at the patch? All changes were protected by #ifdef
TCC_CONFIG_EXSYMTAB
There was nothing affected w/o ./configure --enable-exsymtab

> I am not yet ready to discuss adding exsymtab to tcc; I likely won't have 
> time until this
> summer

You are the master of the patch. But I expected something from you in
august/september 2015 (you say something like above in may 2015)

PS: all new optimizations will break the patch again and again. How
long I must perform
adoptation by myself?

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