Christian JULLIEN | 28 Jul 06:58 2015
Picon

RE :Re: RE : [RFC] Moving source code to "src"

Ouch!
You're fast, maybe too fast.
I've no responsibility on tcc project. If I think moving code to src is a good idea, it is my personal opinion. Official maintainers may have a different opinion or want to choose different code organization.

Anyway, here is what I can already say (from my RPi)
- it compiles well if you run make from src directory. I prefer a toplevel Makefile having different tagets calling make on different subdirectories.
- related to previous point, you can't run 'make test' which fails
- have you modified build-tcc.bat for Windows ?

C.

----- message d'origine -----
De : "gus knight" <waddlesplash-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
date lun. 27/07/2015 22:11 (GMT +02:00)
À : "tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org" <tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>
Objet : Re: [Tinycc-devel] RE : [RFC] Moving source code to "src"

On Mon, Jul 27, 2015 at 12:48 PM, Christian JULLIEN <eligis-1tsiiZ//OF9QFI55V6+gNQ@public.gmane.org> wrote:
> Hi Gus,
>
> This is a good idea. If you do so, I also suggest an arch directory that
> contains subdirectories for all supported archives

I wound up going with one dir per arch rather than an "arch"
directory. Let me know if there are any regressions.

-gus

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
<div>
<div>Ouch!</div>
<div>You're fast, maybe too fast.</div>
<div>I've no responsibility on tcc project. If I think moving code to src is a good idea, it is my personal opinion. Official maintainers may have a different opinion or want to choose different code organization.</div>
<div><br></div>
<div>Anyway, here is what I can already say (from my RPi)</div>
<div>- it compiles well if you run make from src directory. I prefer a toplevel Makefile having different tagets calling make on different subdirectories.</div>
<div>- related to previous point, you can't run 'make test' which fails<br>- have you modified build-tcc.bat for Windows ?</div>
<div><br></div>
<div>C.<br><br>
</div>
<blockquote>----- message d'origine -----<br>De : <span dir="ltr">"gus knight"</span> <span dir="lrt">&lt;waddlesplash@...&gt;</span><br>date lun. 27/07/2015 22:11 (GMT +02:00)<br>&Agrave; : <span dir="ltr">"tinycc-devel@..."</span> <span dir="lrt">&lt;tinycc-devel@...&gt;</span><br>Objet : Re: [Tinycc-devel] RE : [RFC] Moving source code to "src"<br><br>On Mon, Jul 27, 2015 at 12:48 PM, Christian JULLIEN &lt;eligis@...&gt; wrote:<br>&gt; Hi Gus,<br>&gt;<br>&gt; This is a good idea. If you do so, I also suggest an arch directory that<br>&gt; contains subdirectories for all supported archives<br><br>I wound up going with one dir per arch rather than an "arch"<br>directory. Let me know if there are any regressions.<br><br>-gus<br><br>_______________________________________________<br>Tinycc-devel mailing list<br>Tinycc-devel@...<br>https://lists.nongnu.org/mailman/listinfo/tinycc-devel<br>
</blockquote>
</div>
Christian JULLIEN | 27 Jul 18:48 2015
Picon

RE : [RFC] Moving source code to "src"

Hi Gus,

This is a good idea. If you do so, I also suggest an arch directory that contains subdirectories for all supported archives

arch/arm
arch/arm64
arch/i386
...

I'm afraid this code refactory will take long until it works on all platforms (including Windows).

Talking about Windows, who has a good Makefile producing standalone tcc for x86/x64 using recent Cygwin toolchain (and no more using Cygwin after it has been compiled).
My dream would be a unique tcc.exe having -m32/-m64 option.

----- message d'origine -----
De : "gus knight" <waddlesplash-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
date lun. 27/07/2015 18:25 (GMT +02:00)
À : "TinyCC ML" <tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org>
Objet : [Tinycc-devel] [RFC] Moving source code to "src"

Hi,

ATM the root directory of TinyCC is a bit cluttered, mostly because
the core of TinyCC's code is there. I propose moving it to a "src"
subdirectory.

-gus

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel-qX2TKyscuCcdnm+yROfE0A@public.gmane.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
<div>
<div>Hi Gus,</div>
<div><br></div>
<div>This is a good idea. If you do so, I also suggest an arch directory that contains subdirectories for all supported archives</div>
<div><br></div>
<div>arch/arm</div>
<div>arch/arm64</div>
<div>arch/i386</div>
<div>...</div>
<div><br></div>
<div>I'm afraid this code refactory will take long until it works on all platforms (including Windows).</div>
<div><br></div>
<div>Talking about Windows, who has a good Makefile producing standalone tcc for x86/x64 using recent Cygwin toolchain (and no more using Cygwin after it has been compiled).</div>
<div>My dream would be a unique tcc.exe having -m32/-m64 option.<br><br>
</div>
<blockquote>----- message d'origine -----<br>De : <span dir="ltr">"gus knight"</span> <span dir="lrt">&lt;waddlesplash@...&gt;</span><br>date lun. 27/07/2015 18:25 (GMT +02:00)<br>&Agrave; : <span dir="ltr">"TinyCC ML"</span> <span dir="lrt">&lt;tinycc-devel@...&gt;</span><br>Objet : [Tinycc-devel] [RFC] Moving source code to "src"<br><br>Hi,<br><br>ATM the root directory of TinyCC is a bit cluttered, mostly because<br>the core of TinyCC's code is there. I propose moving it to a "src"<br>subdirectory.<br><br>-gus<br><br>_______________________________________________<br>Tinycc-devel mailing list<br>Tinycc-devel@...<br>https://lists.nongnu.org/mailman/listinfo/tinycc-devel<br>
</blockquote>
</div>
gus knight | 27 Jul 18:24 2015
Picon

[RFC] Moving source code to "src"

Hi,

ATM the root directory of TinyCC is a bit cluttered, mostly because
the core of TinyCC's code is there. I propose moving it to a "src"
subdirectory.

-gus

David Mertens | 27 Jul 17:37 2015
Picon

When does a CType's ref contain a valid pointer?

Hello everyone,

While working on symbol table copying, I have run into trouble copying type.ref pointers that point to garbage. Suppose we have a type struct called "type_to_check". Then I thought the following check would ensure that the .ref field was valid:

int btype = type_to_check->type.t & VT_BTYPE;
if (btype == VT_PTR || btype == VT_STRUCT || btype == VT_FUNC) {
  /* type_to_check.ref is a valid pointer */
}

Yet I seem to run into trouble. Does this look correct?

David

--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
<div><div dir="ltr">
<div>
<div>
<div>Hello everyone,<br><br>
</div>While working on symbol table copying, I have run into trouble copying type.ref pointers that point to garbage. Suppose we have a type struct called "type_to_check". Then I thought the following check would ensure that the .ref field was valid:<br>
</div>
<br>int btype = type_to_check-&gt;type.t &amp; VT_BTYPE;<br>if (btype == VT_PTR || btype == VT_STRUCT || btype == VT_FUNC) {<br>
</div>&nbsp; /* type_to_check.ref is a valid pointer */<br><div>}<br><br>
</div>
<div>Yet I seem to run into trouble. Does this look correct?<br><br>
</div>
<div>David<br clear="all">
</div>
<div><div><div><div>
<br>-- <br><div class="gmail_signature">&nbsp;"Debugging is twice as hard as writing the code in the first place.<br>
 &nbsp; Therefore, if you write the code as cleverly as possible, you are,<br>
 &nbsp; by definition, not smart enough to debug it." -- Brian Kernighan<br>
</div>
</div></div></div></div>
</div></div>
David Mertens | 27 Jul 17:34 2015
Picon

Types, and references to other types

Hello everyone,

I have been playing with symbol table copying and ran into some trouble with uninitialized pointers. I figured my troubles arose because I didn't fully understand the uses of Sym objects, so I thought I'd read through tcc-doc. While reading I came across references to the .t field of Syms, in particular:

"When a reference to another type is needed (for pointers, functions and structures), the 32 - VT_STRUCT_SHIFT high order bits are used to store an identifier reference."

This seems out of date. The current Sym struct does not have a .t field. It has a .type field, which is a CType, which itself has a .t field, but also a .ref field. The .ref is a pointer to the referenced type's Sym. I then grepped through the source. The only code that seems to think that the a type's higher-order bits have a type reference is il-gen.c. Any other shifting of the type.t field assumes that the high bits contain bit field offsets.

Is the tcc-doc.texi out of date?

David

--
 "Debugging is twice as hard as writing the code in the first place.
  Therefore, if you write the code as cleverly as possible, you are,
  by definition, not smart enough to debug it." -- Brian Kernighan
<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div>Hello everyone,<br><br>
</div>I have been playing with symbol table copying and ran into some trouble with uninitialized pointers. I figured my troubles arose because I didn't fully understand the uses of Sym objects, so I thought I'd read through tcc-doc. While reading I came across references to the .t field of Syms, in particular:<br><br>"When a reference to another type is needed (for pointers, functions and structures), the 32 - VT_STRUCT_SHIFT high order bits are used to store an identifier reference."<br><br>
</div>This seems out of date. The current Sym struct does not have a .t field. It has a .type field, which is a CType, which itself has a .t field, but also a .ref field. The .ref is a pointer to the referenced type's Sym. I then grepped through the source. The only code that seems to think that the a type's higher-order bits have a type reference is il-gen.c. Any other shifting of the type.t field assumes that the high bits contain bit field offsets.<br><br>
</div>Is the tcc-doc.texi out of date?<br><br>
</div>
<div>David<br clear="all">
</div>
</div>
<div><div><div><div><div><div>
<br>-- <br><div class="gmail_signature">&nbsp;"Debugging is twice as hard as writing the code in the first place.<br>
 &nbsp; Therefore, if you write the code as cleverly as possible, you are,<br>
 &nbsp; by definition, not smart enough to debug it." -- Brian Kernighan<br>
</div>
</div></div></div></div></div></div>
</div></div>
Carlos Jacobo Puga Medina | 20 Jul 20:10 2015
Picon

TCC fails to build on FreeBSD/amd64

Hi,

I tried to build tcc from git source, but currently it fails to build.

% uname -a
FreeBSD bsdbox 10.1-RELEASE-p13 FreeBSD 10.1-RELEASE-p13 #0: Thu Jun 18
12:13:18 CEST 2015     cjpm <at> bsdbox:/usr/obj/usr/src/sys/GENERIC  amd64

<snip>
../tcc -B.. -c bcheck.c -o x86_64/bcheck.o -I..  -Wall -g -O0 
-Wdeclaration-after-statement -Wno-deprecated-declarations -Wno-strict
-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -Wno
-uninitialized -fno-strict-aliasing -fPIC -DTCC_TARGET_X86_64
In file included from bcheck.c:21:
/usr/include/stdio.h:63: error: ';' expected (got "va_list")
Makefile:116: recipe for target 'x86_64/bcheck.o' failed
gmake[1]: *** [x86_64/bcheck.o] Error 1
gmake[1]: Leaving directory '/usr/home/cjpm/github/tinycc/lib'
Makefile:259: recipe for target 'libtcc1.a' failed
gmake: *** [libtcc1.a] Error 2

Any thoughts about how to handle this?

If you need more info, please let me know.

Regards,
-- 
Carlos Jacobo Puga Medina <cpm@...>

Attachment (tcc-git.log): text/x-log, 6502 bytes
Hi,

I tried to build tcc from git source, but currently it fails to build.

% uname -a
FreeBSD bsdbox 10.1-RELEASE-p13 FreeBSD 10.1-RELEASE-p13 #0: Thu Jun 18
12:13:18 CEST 2015     cjpm <at> bsdbox:/usr/obj/usr/src/sys/GENERIC  amd64

<snip>
../tcc -B.. -c bcheck.c -o x86_64/bcheck.o -I..  -Wall -g -O0 
-Wdeclaration-after-statement -Wno-deprecated-declarations -Wno-strict
-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -Wno
-uninitialized -fno-strict-aliasing -fPIC -DTCC_TARGET_X86_64
In file included from bcheck.c:21:
/usr/include/stdio.h:63: error: ';' expected (got "va_list")
Makefile:116: recipe for target 'x86_64/bcheck.o' failed
gmake[1]: *** [x86_64/bcheck.o] Error 1
gmake[1]: Leaving directory '/usr/home/cjpm/github/tinycc/lib'
Makefile:259: recipe for target 'libtcc1.a' failed
gmake: *** [libtcc1.a] Error 2

Any thoughts about how to handle this?

If you need more info, please let me know.

Regards,
--

-- 
Carlos Jacobo Puga Medina <cpm@...>

Chris Marshall | 17 Jul 00:08 2015
Picon

build perl5 with tcc?

I would like to integrate tcc with some perl5 programs to the best extent possible.
Has anyone tried and/or reported being able to build perl5 with tcc?

Thanks,
Chris
<div><div dir="ltr">
<div>
<div>
<div>I would like to integrate tcc with some perl5 programs to the best extent possible.<br>
</div>Has anyone tried and/or reported being able to build perl5 with tcc?<br><br>
</div>Thanks,<br>
</div>Chris<br>
</div></div>
Chris Marshall | 16 Jul 15:41 2015
Picon

complex number support for tcc

I notice in the tcc-0.9.26 TODO file that C99 complex number
support is not present.  Has there been any further work to
support complex arithmetic and/or what the required level of
effort would be?

Thanks,
Chris
<div><div dir="ltr">
<div>
<div>
<div>
<div>
<div>I notice in the tcc-0.9.26 TODO file that C99 complex number<br>
</div>support is not present.&nbsp; Has there been any further work to<br>
</div>support complex arithmetic and/or what the required level of<br>
</div>effort would be?<br><br>
</div>Thanks,<br>
</div>Chris<br>
</div></div>
Chris Marshall | 16 Jul 15:38 2015
Picon

Re: support for OOP in C

I'm new to the tcc-devel list but the thread last month at

  http://lists.nongnu.org/archive/html/tinycc-devel/2015-06/msg00002.html

is directly relevant to my interest in tcc which is to enable
JIT computing to the Perl Data Language along with a new,
symmetric framework for computation so that routines can
be defined either at the "C" level or at the Perl level and
called from either.

The basis for this capability would bea C level OOP such as
the one discussed in the abovethread.  The good news is
that the author of the OOP in C book has implemented a
couple of iterations in his studies.  The latest is COS (the
C Object System) which is documented as the replacement
for all the previous implementations.
The features and capability look very good and I believe
will be sufficient for PDL development save the fact that
it apparently doesn't work on windows without some
sort of POSIX layer (cygwin or such).  From studying
the code, it appears that restriction is actually the build
and not the library which only needs C99 preprocessor
and C89 or greater compiler.

The license is Apache.

Regards,
Chris
 
<div><div dir="ltr">
<div>
<div>
<div>
<div></div>I'm new to the tcc-devel list but the thread last month at<br><br>&nbsp; <a href="http://lists.nongnu.org/archive/html/tinycc-devel/2015-06/msg00002.html">http://lists.nongnu.org/archive/html/tinycc-devel/2015-06/msg00002.html</a><br><br>
</div>is directly relevant to my interest in tcc which is to enable<br>
</div>JIT computing to the Perl Data Language along with a new,<br>
</div>
<div>symmetric framework for computation so that routines can<br>
</div>
<div>be defined either at the "C" level or at the Perl level and<br>
</div>
<div>called from either.<br><br>The basis for this capability would bea C level OOP such as<br>the one discussed in the abovethread.&nbsp; The good news is<br>
</div>
<div>that the author of the OOP in C book has implemented a<br>
</div>
<div>couple of iterations in his studies.&nbsp; The latest is COS (the<br>
</div>
<div>C Object System) which is documented as the replacement<br>
</div>
<div>for all the previous implementations.<br>
</div>
<div><div><div><div><div>
<div>
<br>&nbsp; <a href="http://ldeniau.web.cern.ch/ldeniau/cos.html">http://ldeniau.web.cern.ch/ldeniau/cos.html</a><br>&nbsp; <a href="https://github.com/CObjectSystem/COS">https://github.com/CObjectSystem/COS</a><br><br>
</div>
<div>The features and capability look very good and I believe<br>
</div>
<div>will be sufficient for PDL development save the fact that<br>
</div>
<div>it apparently doesn't work on windows without some<br>
</div>
<div>sort of POSIX layer (cygwin or such).&nbsp; From studying<br>
</div>
<div>the code, it appears that restriction is actually the build<br>
</div>
<div>and not the library which only needs C99 preprocessor<br>
</div>
<div>and C89 or greater compiler.<br><br>
</div>
<div>The license is Apache.<br><br>
</div>
<div>Regards,<br>
</div>
<div>Chris<br>
</div>
<div>&nbsp; <br>
</div>
</div></div></div></div></div>
</div></div>
Andrés Ramírez | 6 Jul 17:20 2015

segmentation fault when linking with newt

Hi guys.

I am trying this simple example (which fails on the line with newtFormAddComponents):

#include <newt.h>
#include <stdio.h>
#include <stdlib.h>
/* tcc -g -o button.bin button.c -lnewt */
/* gdb --annotate=3 -i=mi --args  button.bin  */
void main(void) {
  int left, top, width, height;

  newtComponent form, b1, b2, b3, b4, bback;
  newtInit();
  newtCls();

  left = 10;
  top = 5;
  width = 40;
  height = 10;
  newtOpenWindow(left, top, width, height, "Shell Buttons");

  b1 = newtCompactButton(left, 1, "Uno");
  b2 = newtCompactButton(left, 2, "Dos");
  b3 = newtCompactButton(left, 3, "Tres");
  b4 = newtCompactButton(left, 4, "Cuatro");
  bback = newtButton(left, 6, "Back");
  form = newtForm(NULL, NULL, 0);
  /* newtFormAddComponents fails with tcc */
  newtFormAddComponents(form, b1, b2, b3, b4, bback);

  newtRunForm(form);

  newtFormDestroy(form);
  newtFinished();
}

Let me know. If You need any other info. Best Regards 

Aharon Robbins | 1 Jul 05:04 2015

mob regression - compiling gawk

Hi.

The current mob on x86_64 no longer compiles gawk correctly. The
generated executable does a stunning job of failing the test suite,
dumping core multiple times.

	wget http://ftp.gnu.org/gnu/gawk/gawk-4.1.3.tar.gz # latest release
	tar -xpvzf gawk-4.1.3.tar.gz
	./configure CC=tcc && make
	make check		# KABOOM!

I'm using a version from mid-May and that works fine, so something
broke in the past 6 or 7 weeks.

Can someone look into this please?

Thanks,

Arnold


Gmane