[Tinycc-devel] Patch for review - duplicate case label checking in switches
Hello All.
Some time ago I left the list after a discussion about checking for
duplicate case labels, which didn't exist in tinycc. I was told that it
would slow down compilation times.
I recently added this checking to current mob. The patch is under 100
lines of straightforward code.
I saw no measurable difference in compilation times for gawk - 3 runs
without this patch and 3 runs with it.
Please review the patch - is there something I should do differently in
terms of use of internal tinycc support routines?
Is there a willingness to accept this patch into mob? If so, I'll push it.
Otherwise, I'll unsubscribe again and just continue to use my patched
version.
Thanks,
Arnold Robbins
>From 3d3a9b173cf11a832a95e581dbfddb2da092b08a Mon Sep 17 00:00:00 2001
From: "Arnold D. Robbins"
Date: Wed, 7 Sep 2016 06:42:22 +0300
Subject: [PATCH] Add duplicate case value checking to switch statements.
---
tccgen.c | 97
1 file changed, 97 insertions(+)
diff --git a/tccgen.c b/tccgen.c
index 9ebd80a..6b4c682 100644
--- a/tccgen.c
+++ b/tccgen.c
@@ -4876,6 +4876,99 @@ static void label_or_decl(int l)
decl(l);
}
+struct case_label {
+int value;
+struct case_label *next;
+size_t line;
+};
+
+struct switch_list {
+struct switch_list *outer;
+struct case_label *labels;
+size_t num_labels;
+} *switch_list = NULL;
+
+static int label_compare(const void *l, const void *r)
+{
+struct case_label **left = (struct case_label **) l;
+struct case_label **right = (struct case_label **) r;
+int ret;
+
+ret = ((*left)->value - (*right)->value);
+if (ret != 0)
+return ret;
+
+return ((*left)->line - (*right)->line);
+}
+
+static void switch_start()
+{
+struct switch_list *nsw = tcc_malloc(sizeof(struct switch_list));
+memset(nsw, 0, sizeof(*nsw));
+
+if (switch_list != NULL)
+nsw->outer = switch_list;
+
+switch_list = nsw;
+}
+
+static void switch_end()
+{
+struct case_label **labels = tcc_malloc(switch_list->num_labels *
sizeof(struct case_label *));
+int i;
+struct case_label *l = switch_list->labels;
+struct case_label *l2;
+struct switch_list *outer = switch_list->outer;
+static int have_dups = 0;
+
+for (i = 0; i < switch_list->num_labels; i++) {
+labels[i] = l;
+l = l->next;
+}
+
+qsort(labels, switch_list->num_labels, sizeof(struct case_label *),
label_compare);
+
+for (i = 1; i < switch_list->num_labels; i++) {
+if (labels[i-1]->value == labels[i]->value) {
+have_dups = 1;
+tcc_error_noabort("duplicate case label %d: lines %d and %d",
+labels[i]->value,
+labels[i-1]->line,
+labels[i]->line);
+}
+}
+
+/* release all the memory */
+tcc_free(labels);
+
+for (l = switch_list->labels; l != NULL; l = l2) {
+l2 = l->next;
+tcc_free(l);
+}
+
+tcc_free(switch_list);
+switch_list = outer;
+
+if (have_dups && outer == NULL)
+exit(1);
+}
+
+static void switch_add_case(int case_val)
+{
+struct case_label *label = tcc_malloc(sizeof(struct case_label));
+
+memset(label, 0, sizeof(*label));
+label->value = case_val;
+label->line = file->line_num;
+
+if (switch_list) {
+label->next = switch_list->labels;
+switch_list->labels = label;
+switch_list->num_labels++;
+} else
+tcc_free(label);
+}
+
static void block(int *bsym, int *csym, int *case_sym, int *def_sym,
int case_reg, int is_expr)
{
@@ -5152,7 +5245,9 @@ static void block(int *bsym, int *csym, int *case_sym,
int *def_sym,
a = 0;
b = gjmp(0); /* jump to first case */
c = 0;
+switch_start();
block(&a, csym, &b, &c, case_reg, 0);
+switch_end();
/* if no default, jmp after switch */
if (c == 0)
c = ind;
@@ -5167,10 +5262,12 @@ static void block(int *bsym, int *csym, int *case_sym,
int *def_sym,
expect("switch");
next();
v1 = expr_const();
+switch_add_case(v1);
v2 = v1;
if (gnu_ext && tok == TOK_DOTS) {
next();
v2 = expr_const();
+switch_add_case(v2);
if (v2 < v1)
tcc_warning("empty case range");
}
--
2.7.4
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Largish mob update from me
Michael Matz wrote: > Some recent change between bf692af3 (from 2016-11-12) and fe6453f8 (from > 2016-12-10) broke gawk (on x86-64), and that fail still exists with my > changes on the top; I haven't investigated that yet, but it's mostly > changes for separating out relocation processing (hello Thomas :) ). Sigh. I guess it's good I don't update tcc that frequently. Please let me know when it's fixed again. Thaks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Largish mob update from me
Michael Matz wrote: > gawk is fixed now. Seems to be good. Thanks for looking out for me. :-) Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Documentation Suggestion
Patrick wrote: > Last night I tried again but this time I did not alter my bashrc but > instead used ./configure disable-shared CC=tcc > > I guess TCC can't generate position independent code. I am having a lot > more luck now and I had a great time last night compiling several projects. I use it on x86_64 Linux to generate shared objects all the time (the extensions in gawk). Is this on Linux or some other OS? Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Documentation Suggestion
Patrick wrote: > I just re-tested ncurses and it compiles fine with and without > --disable-shared. > > However I tried to compile GnuCOBOL and libao and both will fail without > --disabled-shared and compile with this flag. I'll let the developers answer; I don't use TinyCC for anything but compiling gawk during development. Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] simple #ifdef causes "error: function pointer expected"
This isn't valid C. The preprocessor doesn't know about sizeof.
Arnold
Massimo Sala wrote:
> Hi
>
> Compiling the attached sample, tcc bails out with "error: function pointer
> expected"
> Pls, how can I fix ?
> Best regards, Massimo
>
> #include
> #include
> #include
>
> int main()
> {
> printf("ciao\n");
> #if sizeof(size_t) == 64
> printf("big boss\n");
> #endif
> return 0;
> }
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
"Christian Jullien" wrote: > I think that what annoys me the most is that standard ar and ranlib commands > do not work with tcc generated .o files. > For sure, I can drop ranlib calls and replace ar by "tcc -ar rcs" but this > must be done in every configure.ac and standard .m4 you have or use. > It means that you probably won't be able to use any open source package with > "CC=tcc ./configure". I build gawk that way on Linux all the time, for years. Including the static libray of support routines. So, are you sure? Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Major issue with current macos port. clang and tcc .o are not compatible
It's OK; I get the point.
Thanks,
Arnold
"Christian Jullien" wrote:
> Arnold, here is non-working example on macos (Catalina) with mob:
>
> --- foo.c
>
> int foo = 1;
>
>
>
> --- main.c
>
> #include
>
> extern int foo;
>
> int
>
> main() {
>
> printf("foo: %d\n", foo);
>
> }
>
>
>
> jullien@byas /tmp % tcc -o foo.o -c foo.c
>
> jullien@byas /tmp % ar cru libfoo.a foo.o
>
> jullien@byas /tmp % tcc -o foo main.c -L. -lfoo
>
> tcc: error: undefined symbol '_foo'
>
> jullien@byas /tmp % nm libfoo.a
>
>
>
> foo.o:
>
> D _foo
>
>
>
>
>
> But:
>
> jullien@byas /tmp % rm libfoo.a
>
> jullien@byas /tmp % tcc -ar cru libfoo.a foo.o
>
> jullien@byas /tmp % tcc -o foo main.c -L. -lfoo
>
> jullien@byas /tmp % ./foo
>
> foo: 1
>
> jullien@byas /tmp %
>
>
>
> -Original Message-
> From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of Christian Jullien
> Sent: Wednesday, June 24, 2020 16:37
> To: arn...@skeeve.com; tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and
> tcc .o are not compatible
>
>
>
> Sure that's also what I do on the different Linux that support tcc (x86,
>
> x86_64, arm, aarch64, riscv).
>
> On macos it does not work because it fails when trying to "ar *.o" as .o are
>
> not MACH-O but ELF. macOS version of ar silently drop them.
>
> To work, you have to adapt configure.ac to use "tcc -ar" instead of ar *AND*
>
> no longer call ranlib.
>
>
>
> C.
>
>
>
> -Original Message-
>
> From: arn...@skeeve.com [mailto:arn...@skeeve.com]
>
> Sent: Wednesday, June 24, 2020 16:29
>
> To: tinycc-devel@nongnu.org; jull...@eligis.com
>
> Subject: Re: [Tinycc-devel] Major issue with current macos port. clang and
>
> tcc .o are not compatible
>
>
>
> "Christian Jullien" wrote:
>
>
>
> > I think that what annoys me the most is that standard ar and ranlib
>
> commands do not work with tcc generated .o files.
>
> > For sure, I can drop ranlib calls and replace ar by "tcc -ar rcs" but this
>
> must be done in every configure.ac and standard .m4 you have or use.
>
> > It means that you probably won't be able to use any open source package
>
> with "CC=tcc ./configure".
>
>
>
> I build gawk that way on Linux all the time, for years. Including the
>
> static libray of support routines. So, are you sure?
>
>
>
> Arnold
>
>
>
>
>
> ___
>
> 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] Tiny c availability
I compile gawk with it all the time and gawk passes its test suite. I use it mainly when I want a quick build to test something. My big wish for tcc is that it'd produce debug info for use with GDB. Arnold Daniel Glöckner wrote: > On Thu, Jul 09, 2020 at 10:09:56AM +0200, Christian Jullien wrote: > > Many starts with more than one :o) > > Even the Pirahã appear to agree that many doesn't start before three. > > > Five BIG projects is not that bad. > > > > Let me start with few I very often (if not daily) compile: > > - OpenLisp (daily) > > - bigz (daily) > > - gnumake (every major version) > > - sqlite (daily - part of OpenLisp build) > > - tcc (almost daily) > > > > They already count for FIVE :o) > > But you talked about many people, not many projects, and you are only > one person, unless of course you have a split personality. :P > > > What about a page referencing projects that build with tcc? > > That would also be useful to show what tcc is capable of compiling. > > ___ > 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] Tiny c availability
> arn...@skeeve.com wrote in > <202007090906.069964j4023...@freefriends.org>: > |I compile gawk with it all the time and gawk passes its test suite. > |I use it mainly when I want a quick build to test something. > | > |My big wish for tcc is that it'd produce debug info for use with GDB. Steffen Nurpmeso wrote: > Oh please not as a regular built-in option. Why not? Why shouldn't I get fast compile with the option for debug info also? Why must I be forced to fall back to GCC just to debug? Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Tiny c availability
Michael Matz wrote: > Hello, > > On Thu, 9 Jul 2020, arn...@skeeve.com wrote: > > > I compile gawk with it all the time and gawk passes its test suite. > > I use it mainly when I want a quick build to test something. > > > > My big wish for tcc is that it'd produce debug info for use with GDB. > > Recent mob has some changes that make tcc emit some debug info also for > variables (it always had support for line numbers). E.g. this works fine: Cool! Thanks! I'll try it out. Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs
Michael Matz wrote: > Yeah, I think that's merely a typo in Arnolds email. The inconsistency is > there, applying unary '-' to a NaN doesn't change the sign of it in TCC. Yep, that was the issue. Sorry I wasn't clear. > So the current "-0.0-x" expansion of unary '-' needs a change. It turned > out to be a bit uglier than I wished for, but alas, fixed in mob. It now works for me. Thanks for the fix! > Thanks for the report, Arnold. You're welcome. Take it easy, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs
Vincent Lefevre wrote: > > But my point is that with the above testcase, you cannot know whether > the difference between gcc and tcc comes from strtod (which would be > valid, as strtod doesn't specify the sign or NaN) or the "d = -d;" > (which would be invalid). A printf should have been added between > the strtod and the "d = -d;" to be sure. It was definitely the "d = -d". Sorry I wasn't more clear. Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [bootstrappable] Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'
Jan Nieuwenhuizen wrote: > to the gawk-mesbot0 recipe also fixes "inc.awk". The pre > increment/decrement code looks like this: > > --8<---cut here---start->8--- > *lhs = make_number(lval + > (tree->type == Node_preincrement ? 1.0 : -1.0)); > > --8<---cut here---end--->8--- What in the world? That looks like gawk 3.x code, which is terribly ancient. What project is still using a version that old? Arnold (The gawk maintainer) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] enforced immutability - proposed research project
+ Do the work in a separate branch, not on mob which people use for production "Christian Jullien" wrote: > + project duration > > -Original Message- > From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] > On Behalf Of Christian Jullien > Sent: Tuesday, January 19, 2021 06:46 > To: tinycc-devel@nongnu.org > Subject: Re: [Tinycc-devel] enforced immutability - proposed research project > > Gentlemen, > I'm happy to see you have a lot of ideas. Here is what I propose: > - take time to think about the approach you want to implement this feature, > ask advices from maintainers if you like. > - move implementation discussion to another list > - THEN propose a research subject with: > * estimated compilation speed impact (goal/non goal) > * estimated execution speed impact (goal/non goal) > * availability/portability on OS/cpu/compiler (IMHO at least mainline > architectures, I would say Linux/[x64, aarch64, riscv 64], Windows x64 and > another un*x like *BSD) - Okay, riscv is not yet mainline but hope it will > soon. > * user interface (set using configure option, set using a compiler option, > new __attribute__ etc...) > * impact on current source code (mostly implemented in a new file, > dissimilated in source code with #if/#endif, with macro, ...) > * list gold ports (i.e. ports tested before any commits) and silver ports > (i.e. ports that also probably work after commits). > * nominate a coordinator for this project > - wait approval from maintainers. > > Sounds reasonable? > > Christian > > -Original Message- > From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] > On Behalf Of Elijah Stone > Sent: Tuesday, January 19, 2021 02:44 > To: tinycc-devel@nongnu.org > Subject: Re: [Tinycc-devel] enforced immutability - proposed research project > > On Tue, 19 Jan 2021, Bruno Haible wrote: > > > MAP_FIXED is a portability nightmare nowadays, where most OSes implement > > address space randomization and put the shared libraries at arbitrary > > and random locations in the address space. You better stay away from it. > > > > The implementation I pointed to therefore doesn't use MAP_FIXED, just > > plain MAP_SHARED. > > The problem is, without a fixed offset between the mutable and immutable > spaces, certain desirable semantics become harder to implement. For > example, we want mutable and immutable references to the same object to > compare equal. > > One potential solution is to rely on overcommit. Map a giant memory > region, and then remap the second portion (using MAP_FIXED) to alias the > first half. (Using MAP_FIXED to overwrite existing address space mappings > _is_ a supported usage.) > > -E > > > ___ > 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 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] I want to add more info with -v option
I think this is a good idea. "Christian Jullien" wrote: > Can I push this patch? > vvv > +TCC_GIT_DATE=$(shell which gut > /dev/null 2>&1 && git log -1 --format=%ad > --date=local || echo no) ^^^ You have a typo here. :-) Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Using TCC to generate API wrappers
TCC is the wrong tool for the job. Look into SWIG, which already does this for a number of langauges. HTH, Arnold Kevin Ingwersen via Tinycc-devel wrote: > Hello there! > > Quick and short question: Can I use libtcc to extract symbol information > (types, functions, structs, enums, unions) from a C header so that I can > then use it to generate a wrapper? My goal is to automate the process > of C interop generation for the V language, which uses TCC as one of > the mainly supported compilers - so the source is already accessible > even from a standard V installation, hence my thought of possibly taking > advantage of that to generate wrappers > Thank you in advance! > Kind regards, > Kevin Ingwersen ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] variable lenght array parameter declaration bug
Hi All.
Latest mob (and earlier) don't handle declaration of a variable length
array parameter when the length is specified by an earlier parameter. Here
is a test file:
---
#include
typedef struct { int x, y; } regex_t;
typedef struct { int x, y; } regmatch_t;
extern int regexec (const regex_t *__preg,
const char *__String, size_t __nmatch,
regmatch_t __pmatch[__nmatch],
int __eflags);
---
This goes through GCC, pcc, and clang with no problems. Can someone
fix this? After recent changes in GNULIB, I can no longer compile
gawk with tcc because of this issue.
Thanks!
Arnold
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] wrong interpreter on armhf
Try symlinking the existing file to what tcc wants. Sometimes we get lucky... :-) Arnold raingloom wrote: > Hi! I recently tried tcc on a postmarketOS (Alpine) device. It seems to > generate the correct binary for hello world and even -run worked, but > the resulting binary can't be run directly. > It expects /lib/ld-musl-arm.so.1, but only /lib/ld-musl-armhf.so.1 > exists. > > ___ > 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] Segfault on musl with '-run'
Arthur Williams via Tinycc-devel wrote: > when I changed the shebang to '#!/bin/tcc -run -g -bt4'. #! doesn't work that way; tcc won't get all those flags as separate arguments. Try running from the command line. Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] tinycc mob branch, x86_64, fails some tests with gnu awk
Hi. If someone has the time to look at this, I'd appreciate it. I occasionally use tinycc to compile gawk, just to use a different C compiler. The gawk sources are availble from savannah.gnu.org, and can be cloned with git. It would be best to use the gawk-4.0-stable branch. I build gawk with CC=tcc ./configure && make && make check A number of the gawk tests fail. If one of the tcc developers can look into this, it'd be great; I suspect the work would move TCC forward significantly. I am usingthe x86_64 architecture on Ubuntu 10.11. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tinycc mob branch, x86_64, fails some tests with gnu awk
Hi. I am using the mob branch compiiled from git, so it's up to date. I last tried a few days ago. It has been this way for a while, I just never found the cycles to report it. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] tcc x86-64 and gawk - progress
Hello All.
Kudos to whoever has been working on the x86_64 port. It now compiles
gawk with only one test failure! This is significant progress.
The one remaining test failure seems to be related to handling NaN
floating point values. Here is the diff of the test results.
It would be really cool to have gawk pass all its tests with tcc.
Can someone look at this? Instructions to replicate:
git clone git://git.savannah.gnu.org/gawk.git
cd gawk
git checkout gawk-4.0-stable# important!
./bootstrap.sh
./configure CC=tcc && make && make check
Thanks!
Arnold Robbins
Gawk maintainer
-
make[1]: Entering directory `/d/home/arnold/Gnu/gawk/gawk.git/test'
for i in _* ; \
do \
if [ "$i" != "_*" ]; then \
echo == $i = ; \
if [ -r ${i#_}.ok ]; then \
diff -c ${i#_}.ok $i ; \
else \
diff -c ./${i#_}.ok $i ; \
fi ; \
fi ; \
done | more
== _fmtspcl =
*** fmtspcl.ok Wed May 2 20:09:50 2012
--- _fmtspclWed May 2 20:09:50 2012
***
*** 1,7
gawk: ./fmtspcl.awk:10: warning: sqrt: called with negative argument -1
! gawk: ./fmtspcl.awk:3: warning: [s]printf: value -nan is out of range for
`%x' format
gawk: ./fmtspcl.awk:3: warning: [s]printf: value -nan is out of range for
`%d' format
! gawk: ./fmtspcl.awk:3: warning: [s]printf: value -nan is out of range for
`%x' format
gawk: ./fmtspcl.awk:3: warning: [s]printf: value -nan is out of range for
`%d' format
gawk: ./fmtspcl.awk:3: warning: [s]printf: value inf is out of range for `%x'
format
gawk: ./fmtspcl.awk:3: warning: [s]printf: value inf is out of range for `%d'
format
--- 1,9
gawk: ./fmtspcl.awk:10: warning: sqrt: called with negative argument -1
! sprintf(%s,-9223372036854775808) = -9223372036854775808 (!= -nan)
! sprintf(%x,-9223372036854775808) = (!= -nan)
gawk: ./fmtspcl.awk:3: warning: [s]printf: value -nan is out of range for
`%d' format
! sprintf(%s,-9223372036854775808) = -9223372036854775808 (!= -nan)
! sprintf(%x,-9223372036854775808) = (!= -nan)
gawk: ./fmtspcl.awk:3: warning: [s]printf: value -nan is out of range for
`%d' format
gawk: ./fmtspcl.awk:3: warning: [s]printf: value inf is out of range for `%x'
format
gawk: ./fmtspcl.awk:3: warning: [s]printf: value inf is out of range for `%d'
format
make[1]: Leaving directory `/d/home/arnold/Gnu/gawk/gawk.git/test'
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] X86_64 shared library relocation errors?
Hi. Occasionally I use tcc on x86_64 for testing building gawk with something that isn't GCC. I'm getting this: ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation ../gawk: Symbol `free' causes overflow in R_X86_64_PC32 relocation ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation ../gawk: Symbol `free' causes overflow in R_X86_64_PC32 relocation ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation I vaguely recall that this was discussed before. This is with the mob branch after a recent git pull. To reproduce, simply clone the gawk git repo and configure and build the master branch with tcc. Much thanks! Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] [PATCH v2] forbid invalid comparison of struct
Hitoshi Mitake wrote:
> +} else if (bt1 == VT_STRUCT || bt1 == VT_STRUCT) {
^^^ ^^^
Isn't this testing the same condition twice?
:-)
Arnold
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] latest mob badly broken on x86_64 ubuntu 12.04
> Le jeudi 31 janvier 2013 12:57:28, Aharon Robbins a écrit : > > Hi Guys. > > > > Something broke really bad: > > > > [ ... ] > > > > Please fix before the release... "Thomas Preud'homme" wrote: > Offending commit reverted. Checked it out - it works now. MUCH thanks!! Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] latest mob badly broken on x86_64 ubuntu 12.04
"Thomas Preud'homme" wrote: > Le jeudi 31 janvier 2013 13:53:05, arn...@skeeve.com a écrit : > > > > Checked it out - it works now. MUCH thanks!! > > > > Arnold > > There is really no thanks in order as I'm the one who broke it. On the other > hand it's great you reacted so quickly so the thanks are for you. > > Best regards, > > Thomas Glad to help. Once dynamic objects work I will probably switch to tcc as my default compiler for gawk development. :-) Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] test failure on Linux
"Thomas Preud'homme" wrote: > Why not but strike multiarch from that as I don't see how we could > detect it by compiling a C program. Use the output of ldd to tell you where the C library is. HTH, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] i386 build of gawk with tcc now broken
> > After pulling the latest on the mob branch, builds of gawk master using > > tcc generate lots of test failures. > > > > On an i386 linux system: > > > > git clone git://git.savannah.gnu.org/gawk.git > > cd gawk > > ./bootstrap.sh && configure CC=tcc && make > > make check # watch lots of things go kablooey > > > > This does not occur on x86-64. > > Does this also happen with tcc 0.9.26 and tcc 0.9.25 or just with the mob > branch? I'm pretty sure just the mob branch. I can double check tomorrow when I'm at the machine. Almost all the errors are related to floating point exceptions; I strongly suspect it has to do with the most recent changes. The recipe above will let you reproduce it a lot quicker than waiting for me... 0.9.25 won't be worth checking as it's tool old, FWIW. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Unable to link a binary on OS X
Kevin Ingwersen wrote: > Hey there. > > Another issue I’d like to report is, that TCC seems to be unable to > link on OS X. I belive its because Mac doesnt quite use ELF, as far as > I know. At least, that is what somebody said about objcopy. Mac OS X uses an object file format called "mach-o" which is largely unique to it. Someone would have to teach tcc how to generate and link this object file format. Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] shared libraries with tcc - any ETA?
"Thomas Preud'homme" wrote: > Le vendredi 10 janvier 2014, 09:08:22 Aharon Robbins a écrit : > > Hi. > > > > I've reported before, that on i386 and x86_64 Linux, tcc produces > > shared libraries that sometimes can't be used. This is in the context > > of gawk (GNU Awk). I get errors like this: > > > > ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation > > ../gawk: Symbol `free' causes overflow in R_X86_64_PC32 relocation > > ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation > > ../gawk: Symbol `free' causes overflow in R_X86_64_PC32 relocation > > ../gawk: Symbol `malloc' causes overflow in R_X86_64_PC32 relocation > > [ ... and many more ] > > > > This is the only thing preventing me from switching to tcc for everday > > development, which is a shame, as it is S O M U C H F A S T E R than > > gcc is. > > Nope sorry. Although it is one of the thing I want fixed the most there is no > ETA as nobody is working on it AFAIK. I'll probably take a look someday but > my > time is limited and I don't have an x86 machine at hand (I do have access > over > ssh though) so it makes it less convenient to work on this issue. I can test patches for you if it will help. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] latest mob badly broken on x86_64 linux
Hi. The tip of mob is badly broken. I used to could compile gawk with it but now any invocation of the compiled gawk segfaults. In the gawk sources (git cloned from savannah.gnu.org) it's enough to do ./bootstrap.sh && ./configure CC=tcc && make then jut run gawk without arguments and it segfaults. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] This commit causes segfaults on make test
> Does it also fixes the problem with awk Arnold? Yes, it does. I didn't follow the discussion in detail so I'll just say "thanks!". Any ETA on fixing the shared library issues? I can provide ssh access to an X86_64 linux system if it will help. Thanks again, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Compiling mupdf on X86_64 fails
> Le 2014-03-28 14:44, Aharon Robbins a écrit : > > If TCC would support generation of PIC code on x86_64, I would > > immediately > > switch to it as my default compiler for gawk development. Thomas Preudhomme wrote: > I know we get often asked about it. I wanted to do it in this > development cycle but that would delay the release quite a bit and I > think it's better to do a release soon. I can't promise anything but I > will try to look into it first after the release (albeit any segfault or > miscompiled bug discovered). OK Thomas, much thanks. I well understand about managing releases. If access to my x86_64 linux via ssh will help, let me know (offline). The system has a fairly powerful 4 core processor, is always on, and is idle most of the time. :-) Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] latest mob broken on gawk
Hello all. The latest mob x86_64 has stopped working on gawk. If you have a copy of the gawk repo cd gawk make distsclean git pull git checkout gawk-4.1-stable ./bootstrap.sh && ./configure CC=tcc && make Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] How to use char "\"
Evan Langlois wrote: > And off-topic, but you mentioned your code handled regex's. Google has > a lightning fast regex implementation. Its missing back references or > something, but the speed is pretty amazing. I forget the name of the > lib, but you can Google it. Maybe I'll see if it compiles under TCC :) It's called RE2, and is written in C++, so tcc won't handle it. Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] current mob broken on x86_64 linux
Hello. The current mob is broken; it builds an i386 compiler even thought I'm on an x86_64 platform. Somebody please fix this. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Straightening out x86_64 build?
Hi. Ubuntu 12.04 x86_64, latest mob. Plain ./configure && make It still builds an i386 cross compiler instead of a native compiler. Can whoever broke this P L E A S E fix it? Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] out of the box configuration on x86_64 ubuntu still broken
Hi. Latest mob, out of the box configuration on x86_64 ubuntu is still broken. Is anyone planning to fix this? Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] out of the box configuration on x86_64 ubuntu still broken
Sergey Korshunoff wrote: > Hi! Try the latest mob after the "quick fix for the native tcc on > debian/ubuntu" Nope. Just pulled. It still tries to build an i386 compiler. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] out of the box configuration on x86_64 ubuntu still broken
Sergey Korshunoff wrote: > I tested it on debian 7 x86_64 and all was OK. What the output of the > "uname -m" ? > There was many messages about building a i386 compiler. But no one > tell me the output of the "uname -m" on that systems. Thanks for letting me know what you need to know. This is interesting. My Ubuntu 12.04 box at home: $ uname -m x86_64 And indeed, tcc builds fine here. I will get the info from my work 14.04 box later today for you. Thank you for working to fix this! Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] out of the box configuration on x86_64 ubuntu still broken
Hi. > Sergey Korshunoff wrote: > > > I tested it on debian 7 x86_64 and all was OK. What the output of the > > "uname -m" ? > > There was many messages about building a i386 compiler. But no one > > tell me the output of the "uname -m" on that systems. arn...@skeeve.com wrote: > Thanks for letting me know what you need to know. > > This is interesting. My Ubuntu 12.04 box at home: > > $ uname -m > x86_64 > > And indeed, tcc builds fine here. I will get the info from my > work 14.04 box later today for you. On my Ubuntu-Mate 14.04 box at work, current mob: $ uname -m x86_64 arobbins@arobbins-ubuntu:~/Repos/tinycc$ ./configure --prefix=/tmp/tcc Binary directory /tmp/tcc/bin TinyCC directory/tmp/tcc/lib/tcc Library directory /tmp/tcc/lib Include directory /tmp/tcc/include Manual directory/tmp/tcc/share/man Info directory /tmp/tcc/share/info Doc directory /tmp/tcc/share/doc//tmp/tcc/lib/tcc Target root prefix Source path /home/arobbins/Repos/tinycc C compiler gcc cross compilers no Target CPU x86 Host OS Linux Target OSLinux Big Endian no gprof enabledno use libgcc no Creating config.mak and config.h config.h is unchanged That wasn't helpful. Sigh. $ uname -a Linux arobbins-ubuntu 3.13.0-46-generic #79-Ubuntu SMP Tue Mar 10 20:06:50 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux Here is the result of running sh -x configure. Thanks - Arnold $ sh -x ./configure --prefix=/tmp/tcc 2>&1 | tee configure.out + TMPN=./conftest-18474 + TMPH=./conftest-18474.h + build_cross=no + use_libgcc=no + enable_assert=no + prefix= + execprefix= + bindir= + libdir= + tccdir= + includedir= + mandir= + infodir= + sysroot= + cross_prefix= + cc=gcc + host_cc=gcc + ar=ar + strip=strip + cygwin=no + gprof=no + bigendian=no + mingw32=no + LIBSUF=.a + EXESUF= + tcc_sysincludepaths= + tcc_libpaths= + tcc_crtprefix= + tcc_elfinterp= + tcc_lddir= + confvars= + cpu= + host_os=Linux + uname -s + targetos=Linux + source_path=./ + source_path=. + source_path_used=yes + test -z . -o . = . + pwd + source_path=/home/arobbins/Repos/tinycc + source_path_used=no + eval opt="--prefix=/tmp/tcc" + opt=--prefix=/tmp/tcc + echo --prefix=/tmp/tcc + cut -d = -f 2 + prefix=/tmp/tcc + test -z + test -n i386 + cpu=i386 + classify_cpu i386 + cpu=i386 + cpu=x86 + test -z + CFLAGS=-Wall -g -O2 + test no = yes + test -z /tmp/tcc + test -z + sharedir=/tmp/tcc/share + test x = x + execprefix=/tmp/tcc + test x = x + tccdir=tcc + test x = x + libdir=/tmp/tcc/lib + test -n tcc + tccdir=/tmp/tcc/lib/tcc + test x86 = x86-64 + test x = x + bindir=/tmp/tcc/bin + test x = x + docdir=/tmp/tcc/share/doc//tmp/tcc/lib/tcc + test x = x + mandir=/tmp/tcc/share/man + test x = x + infodir=/tmp/tcc/share/info + test x = x + includedir=/tmp/tcc/include + test x = xyes + test gcc != tcc + ar=ar + cc=gcc + strip=strip + CONFTEST=./conftest + test -z + gcc -o ./conftest /home/arobbins/Repos/tinycc/conftest.c + ./conftest bigendian + bigendian=no + ./conftest version + gcc_major=4 + ./conftest minor + gcc_minor=8 + test no = no + ./conftest triplet + triplet=x86_64-linux-gnu + test -f /usr/lib/x86_64-linux-gnu/crti.o + tcc_lddir=lib + multiarch_triplet=x86_64-linux-gnu + test x86 = armv4l + test -f /lib/ld-uClibc.so.0 + W_OPTIONS=deprecated-declarations strict-aliasing pointer-sign sign-compare unused-result uninitialized + gcc -v --help + grep -- -Wdeprecated-declarations + O_PRESENT= -Wdeprecated-declarations Warn about uses of __attribute__((deprecated)) + test -n -Wdeprecated-declarations Warn about uses of __attribute__((deprecated)) + CFLAGS=-Wall -g -O2 -Wno-deprecated-declarations + gcc -v --help + grep -- -Wstrict-aliasing + O_PRESENT= -Wstrict-aliasing= Warn about code which might break strict aliasing -Wstrict-aliasing Warn about code which might break strict aliasing + test -n -Wstrict-aliasing= Warn about code which might break strict aliasing -Wstrict-aliasing Warn about code which might break strict aliasing + CFLAGS=-Wall -g -O2 -Wno-deprecated-declarations -Wno-strict-aliasing + gcc -v --help + grep -- -Wpointer-sign + O_PRESENT= -Wpointer-sign Warn when a pointer differs in signedness in an + test -n -Wpointer-sign Warn when a pointer differs in signedness in an + CFLAGS=-Wall -g -O2 -Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign + gcc -v --help + grep -- -Wsign-compare + O_PRESENT= -Wsign-compare Warn about signed-unsigned comparisons + test -n -Wsign-compare Warn about signed-unsigned comparisons + CFLAGS=-Wall -g -O2 -Wno-deprecated-declarations -Wno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare + gcc -v --help + grep -- -Wunused-result + O_PRESENT= -Wunused-result Warn if a caller of a function, marked with + test -n
Re: [Tinycc-devel] out of the box configuration on x86_64 ubuntu still broken
Hi all. > arn...@skeeve.com : > > > Here is the result of running sh -x configure. Thanks - Arnold > > > > $ sh -x ./configure --prefix=/tmp/tcc 2>&1 | tee configure.out > > > + test -z > > + test -n i386 > > + cpu=i386 Edmund Grimley Evans wrote: > Do you have ARCH=i386 already set in your environment when you run > ./configure? Indeed - defines set up long ago for running Java. :-( :-( Please excuse me while I try to simultaneously wipe egg off my face and take my foot out of my mouth. After removing this definition everything is working fine again. Thanks to everyone for your help! Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] modern c++ compiler written in C
Cfront was targeted at pre-ANSI C compilers. C++ introduced function prototypes and C89 got them from there. Arnold Sergey Korshunoff wrote: > Hi! > I'm currently playing with cfront. "Hello, World" is compiled. > A strange thing: > cfront change declaration of the C functions. > original declaration: > extern "C" void *malloc(unsigned); > after cfront-1: extern int *malloc(); > after cfront-3: extern char *malloc(); > > PS: u-tcc-u...@aetey.se, what doing your version in this regard? > Changing a yacc version don't helps. > > ___ > 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] Nevermind my previous comments. I just made an error.
> On 2016-01-10 02:36:45 -0800, Ben Hutchinson wrote: > > I was working with the atan2 function, and it kept glitching all over the > > place. Turns out I forgot to include this line at the top of my code: > > #include Vincent Lefevre wrote: > Is there any reason why tcc hasn't rejected the code because the > prototype wasn't declared? Because C default declares functions for you. It's as if it was declared int atan2(...); This may have gone away in C11 but I'm not sure. Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Nevermind my previous comments. I just made an error.
Vincent Lefevre wrote: > IMHO, nowadays, it would be better for the user if compilers reject > implicit declaration of functions by default, since warnings can > easily remain unnoticed since an implicit declaration is an obvious > bug or at least very poor & non-standard coding. Coding styles have changed over the years. I don't disagree with you, but remember that there are millions of lines of C code out there, written who knows how long ago. Compilers have to support such code bases, which is why the C standard didn't disallow implicit declarations. 'nuff said. Thanks, Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
Hi All.
On the latest mob:
$ cat foo.c
int main(int argc, char**argv)
{
int a;
switch (a) {
case 1:
case 2:
break;
case 3:
break;
case 1:
break;
default:
break;
}
return 0;
}
$ PATH=/tmp/tcc/bin:$PATH tcc foo.c
$
$ gcc foo.c -o foo
foo.c: In function ‘main’:
foo.c:11:2: error: duplicate case value
case 1:
^
foo.c:6:2: error: previously used here
case 1:
^
This is pretty serious
Thanks,
Arnold
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
Michael Matz wrote: > First, the bug can't be as MAJOR as > the subject wants to make us believe. After all it wasn't noticed since > the last $MANY years. The bug caused me to push bad code to gawk's repo. It's only luck that it wasn't noticed, but a bug is a bug. Geting the right answer a little more slowly is always better than getting the wrong answer super fast. The issue isn't just the lack of diagnostic - what kind of erroneous code is being generated in this case? TCC is valuable for being both fast and correct. Lose the correctness and you lose ALL the value. My two cents worth. Arnold ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate cases in switch statements
Amine Najahi wrote:
> Hi,
>
> The patch is not committed. It is just a hackish way I coded to explore how
> this cases "bug" could be addressed using tcc's api. It certainly does not
> handle the gnu "..." extension.
>
> My conclusions is that I agree with Michael's arguments. I, for one, use
> tcc for its speed, and I can live with it not diagnosing this issue.
> It is too costly for a one pass compiler.
>
> Cheers,
>
> Amine
>
>
> On Sat, Mar 12, 2016 at 5:00 AM, Michael B. Smith <
> mich...@theessentialexchange.com> wrote:
>
> > I am a rare poster here – but I think your patch leads to all sorts of
> > problems.
> >
> >
> >
> > Please revert it/don’t commit it.
> >
> >
> >
> > *From:* tinycc-devel-bounces+michael=theessentialexchange@nongnu.org
> > [mailto:tinycc-devel-bounces+michael=theessentialexchange@nongnu.org]
> > *On
> > Behalf Of *Amine Najahi
> > *Sent:* Friday, March 11, 2016 12:13 PM
> > *To:* tinycc-devel@nongnu.org
> > *Subject:* Re: [Tinycc-devel] MAJOR bug: tcc doesn't detect duplicate
> > cases in switch statements
> >
> >
> >
> > Hi Arnold and tcc folks,
> >
> >
> >
> > Perhaps surprisingly, correcting this bug is quite costly.
> >
> > Here is a tentative patch. I find it messy but working with dynamic data
> >
> > and passing the cases to the block function are necessary to handle
> >
> > an "unlimited number" of cases and nested switch blocks.
> >
> >
> >
> > Also, since the 'block' function is starting to have too many arguments, I
> >
> > suggest to create a structure that assembles related arguments such
> >
> > that def_sym, case_sym, cases, and cases_cnt, and any other...
> >
> >
> >
> > Does that sound ok?
> >
> >
> >
> > Regards,
> >
> > Amine
> >
> >
> >
> >
> >
> > On Thu, Mar 10, 2016 at 2:41 PM, wrote:
> >
> > Hi All.
> >
> > On the latest mob:
> >
> > $ cat foo.c
> > int main(int argc, char**argv)
> > {
> > int a;
> >
> > switch (a) {
> > case 1:
> > case 2:
> > break;
> > case 3:
> > break;
> > case 1:
> > break;
> > default:
> > break;
> > }
> >
> > return 0;
> > }
> > $ PATH=/tmp/tcc/bin:$PATH tcc foo.c
> > $
> >
> > $ gcc foo.c -o foo
> > foo.c: In function ‘main’:
> > foo.c:11:2: error: duplicate case value
> > case 1:
> > ^
> > foo.c:6:2: error: previously used here
> > case 1:
> > ^
> >
> > This is pretty serious
> >
> > Thanks,
> >
> > Arnold
> >
> > ___
> > 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
> >
> >
Whoever it was that posted the note about the standard requiring a
diagnostic was right on target. This is too fundamental a mistake not
to diagnose.
But since I don't make commits, I'll stop complaining. I will also most
likely stop using tcc, nor will I recommend it in the future.
Good luck folks, you're gonna need it.
Arnold
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Inline asm error while compiling i386 musl
I am aware that tcc officially does not support compiling musl, but I want
to throw caution to the wind and see if some changes can fix that. I'm
trying to build i386 musl, and I've already hacked around a few errors, but
this one has me totally stumped. For the syscall header
https://git.musl-libc.org/cgit/musl/tree/arch/i386/syscall_arch.h the
definition of __syscall3
static inline long __syscall3(long n, long a1, long a2, long a3)
{
unsigned long __ret;
#if !defined(__PIC__) || !defined(BROKEN_EBX_ASM)
__asm__ __volatile__ (SYSCALL_INSNS : "=a"(__ret) : "a"(n), "b"(a1),
"c"(a2), "d"(a3) : "memory");
#else
__asm__ __volatile__ (SYSCALL_INSNS_34 : "=a"(__ret) : "a"(n), "D"(a1),
"c"(a2), "d"(a3) : "memory");
#endif
return __ret;
}
results in "error: incorrect prefix"
But oddly, this only happen with syscall3. The definitions of syscall1 and
syscall2 work fine, and if I comment syscall3 out, so do the definitions of
syscall4, 5, 6. I have no idea what would be causing the error here, but if
any of the more experienced developers have an idea of the problem, I'd
really appreciate any advice.
Thanks,
John
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs
Hi.
I found this bug in current mob on the current gawk sources. Test case:
-
#include
#include
#include
int main(int argc, char **argv)
{
double d = strtod("-nan", NULL);
d = -d;
printf("%g, signbit(d) = %d\n", d, signbit(d));
return 0;
}
-
Results:
$ gcc foo.c -o foo && ./foo
-nan, signbit(d) = 1
$ tcc foo.c -o foo2 && ./foo2
nan, signbit(d) = 0
I get the same results as gcc with clang and pcc. tcc is the outlier.
Can we get this fixed please?
Thanks!
Arnold
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Bounds checking not working?
Hi,
I just subscribed to the devel-list so don't flame me if
I write this to the wrong list, please.
I will be teaching a course in C programming at the university
and was looking for a C compiler/interpreter that does
bound checking (for first year's students that seems to be a good idea).
After some googling, I found tcc. It seems to be perfect for what I
want, however after compiling it, I tried the following:
arn...@wingtip82:~$ cat outofbound.c
#include
int main(int argc, char **argv) {
int i, sum, tab[10];
printf ("Before\n");
sum = 0;
for(i=0;i<11;i++) {
sum += tab[i];
}
printf ("After\n");
return 0;
}
arn...@wingtip82:~$ uname -a
Linux wingtip82 2.6.26 #1 SMP Sun Mar 29 12:17:22 CEST 2009 i686
GNU/Linux
arn...@wingtip82:~$ tcc outofbound.c
arn...@wingtip82:~$ ./a.out
Before
After
arn...@wingtip82:~$ tcc -b -g outofbound.c
arn...@wingtip82:~$ ./a.out
Before
Segmentation fault
As you can see, the boundschecking version is somewhat different; it
crashes instead of running on without any error (as without checking).
However, I don't think this is the behaviour to be expected, or is it?
Regards,
Arnold Meijster
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel
