[Tinycc-devel] README file improvements

Hi, The tcc 0.9.25 tarball doesn't say where to send bug reports and doesn't even really mention this mailing-list. I think this should be done in the README file. Moreover the README file says: License: --- TCC is distributed under the GNU Lesser General Public License (see COPYING

[Tinycc-devel] incorrect generated code for == on x86_64

Hi, With tcc 0.9.25 on x86_64, x == x is regarded as true, even for NaN. I've looked at the generated code with "tcc -c" and "objdump -d" for: int main(void) { volatile double x = 0.0/0.0; return x == x ? 1 : 0; } It appears: [...] 37: 66 0f 2e 45 f8 ucomisd -0x8(%rbp),%xmm0

[Tinycc-devel] Re: incorrect generated code for == on x86_64

On 2010-04-08 16:55:25 +0200, Vincent Lefevre wrote: > If I understand correctly (I've never worked with x86/x86_64 asm > code), the jne tests the ZF flag, but this flag is set also for > unordered (the case of NaN). Hence the incorrect result. The fix is to add a jp. This is wh

[Tinycc-devel] FLT_EVAL_METHOD macro is not defined

Another problem with tcc 0.9.25: the FLT_EVAL_METHOD macro (specified by the ISO C standard) is not defined. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / Arénaire project (LIP, EN

Re: [Tinycc-devel] Addresses of variables

On 2010-04-11 02:37:22 -0900, Alexei wrote: > Isn't it a BUG? > > #include > int main(int argc, char **argv) > { > int first; > int second; > printf("&first=%08X &second=%08X",&first,&second); > return 0; > } > - > &first=0012FF94 &second=0012FF90 This isn

[Tinycc-devel] tcc 0.9.25 doesn't set the execution bit if the executable is overwritten

tcc 0.9.25 doesn't set the execution bit if the executable is overwritten. To reproduce the problem: ypig% touch tst ypig% ls -l tst -rw-r--r-- 1 vlefevre vlefevre 0 2010-04-14 00:53:30 tst ypig% tcc tst.c -o tst ypig% ls -l tst -rw-r--r-- 1 vlefevre vlefevre 3456 2010-04-14 00:53:38 tst -

[Tinycc-devel] Buggy left shift on x86_64

I've found the following bug when compiling and testing MPFR with Debian's tcc 0.9.26~git20120104.83d57c0-4 package. On x86_64 (but not on i386), the left shift is buggy: #include #include #define SH (CHAR_BIT * sizeof(unsigned long) / 2) int main (void) { unsigned long m; int sh = SH;

Re: [Tinycc-devel] Buggy left shift on x86_64

On 2012-03-13 16:20:21 +0100, Thomas Preud'homme wrote: > I'm pretty busy these days but I will look into it as soon as possible. > > I've checked that it is not Debian specific: the same error happen > with the code from mob branch. Anyway, the only x86-64 change done > compared to the raw tcc[de

Re: [Tinycc-devel] Buggy left shift on x86_64

On 2012-03-13 16:49:37 +0100, Vincent Lefevre wrote: > FYI, the problem occurs for shift counts from 32 to 63 (larger > shift counts are invalid in C, since the variable is on 64 bits). The bug disappears when I replace 1UL by: (unsigned long) 1 And the bug occurs with: m = (1UL &l

[Tinycc-devel] Incorrect shift result type with 64-bit ABI

Hi, The behavior on the following program is incorrect with Debian's tcc (at least up to 0.9.26~git20120612.ad5f375-3) on x86_64 (64-bit ABI). #include #define M1 (1 << (int) 1) #define M2 (1 << (unsigned int) 1) #define M3 (1 << (long) 1) #define M4 (1 << (unsigned long) 1) #define M5 (1 << (l

Re: [Tinycc-devel] Incorrect shift result type with 64-bit ABI

On 2012-06-26 15:07:57 +0200, Vincent Lefevre wrote: > ISO C99 TC3 says: [6.5.7#3] "The integer promotions are performed on > each of the operands. The type of the result is that of the promoted > left operand." I've written a patch (attached). Now the shift problems

Re: [Tinycc-devel] Incorrect shift result type with 64-bit ABI

On 2012-06-27 14:38:44 +0200, Thomas Preud'homme wrote: > Le mercredi 27 juin 2012 14:34:25, Milutin Jovanović a écrit : > > The patch looks good to me. I also did some basic tests, and the patch did > > not seem to break anything. I assumed you wanted it commited, so I did that > > in your name. >

Re: [Tinycc-devel] Incorrect shift result type with 64-bit ABI

Hi, On 2012-06-27 15:02:20 -0400, Milutin Jovanović wrote: > Would you mind adding your test into the test "suite". Pick tests or tests2 > which ever you find easier to add to. I hope it will take only minutes > since you already have them written. I've rewritten my tests to be added to the test

Re: [Tinycc-devel] Incorrect shift result type with 64-bit ABI

On 2012-07-06 13:33:23 +0200, Vincent Lefevre wrote: > I've rewritten my tests to be added to the test suite and improved > them. They show that my patch was actually incorrect when the > first argument is unsigned short: the type should by int, not > unsigned int. This needs to b

Re: [Tinycc-devel] Fwd: Bug#698351: tcc: FE_INVALID flag not set on comparison with NAN (unordered)

Hi, On 2013-01-17 15:57:50 +0100, Thomas Preud'homme wrote: > I've just received this bug report in Debian. I don't know about > this flag but if even gcc does the mistake, I think we can safely > delay the fix for after the release, unless it's an easy fix. The > bug report suggest there is just

Re: [Tinycc-devel] Small patch

On 2013-01-31 10:52:14 +0100, Thomas Preud'homme wrote: > Le jeudi 31 janvier 2013 02:07:36, Domingo Alvarez Duarte a écrit : > > switch(op) { > > case '&': > > pe->v &= e2.v; > > break; > > case '|': > > pe->v |= e2.v; > > bre

Re: [Tinycc-devel] Small patch

On 2013-01-31 13:22:22 +0100, grischka wrote: > Vincent Lefevre wrote: > >Perhaps there was a "default:" by default the author forgot to remove. > >And as it is probably just useless (if op can only be '&', '|' or '^'), > >no-one no

Re: [Tinycc-devel] Small patch

On 2013-01-31 14:50:38 +0100, grischka wrote: > Vincent Lefevre wrote: > >On 2013-01-31 13:22:22 +0100, grischka wrote: > >>Vincent Lefevre wrote: > >>>Perhaps there was a "default:" by default the author forgot to remove. > >>>And as it is

Re: [Tinycc-devel] Small patch

On 2013-01-31 15:56:34 +0100, Michael Matz wrote: > It will lead to slower and/or larger code to add a default case with a > separate body. The current way of doing it is IMO the exactly correct > way. If people are really confused by that, put a comment next to the > 'default:'. OK (until compi

[Tinycc-devel] tcc doesn't set the inexact flag on inexact compile-time int-to-float conversion

tcc doesn't set the inexact flag on inexact compile-time int-to-float conversion: #include #include #pragma STDC FENV_ACCESS ON void test1 (void) { volatile float c; c = 0x7fbf; printf ("c = %a, inexact = %d\n", c, fetestexcept (FE_INEXACT)); } void test2 (void) { volatile float

Re: [Tinycc-devel] RE : tcc doesn't set the inexact flag on inexact compile-time int-to-float conversion

On 2013-04-22 16:13:14 +0200, Christian JULLIEN wrote: > Pardon me if wrong, but tcc uses gcc lib.So you only reproduce > gcc lib bug not tcc compilation error. I've recompiled tcc 0.9.26, and the following is said by the configure script: use libgcc no and I still get the same error. --

Re: [Tinycc-devel] RE :Re: RE : tcc doesn't set the inexact flag on inexact compile-time int-to-float conversion

On 2013-04-22 17:42:44 +0200, Christian JULLIEN wrote: > From latest git pull:$ find . -exec grep fetestexcept {} \; -a > -printextern int __cdecl fetestexcept (int > excepts);./win32/include/fenv.hAs you can see it only exists > declared in win32 directory, so you uses the one from outside > tcc.

Re: [Tinycc-devel] Fwd: Bug#698351: tcc: FE_INVALID flag not set on comparison with NAN (unordered)

Hi Thomas, On 2014-01-03 10:30:15 +0800, Thomas Preud'homme wrote: > There is quite a few differences in the output about -0.0 where gcc > uses 0.0. > I'm not sure it's worth doing anything to change that since it's not > a bug but less divergence with gcc (and probably clang) could be > good. If

Re: [Tinycc-devel] Fwd: Bug#698351: tcc: FE_INVALID flag not set on comparison with NAN (unordered)

On 2014-01-04 20:59:18 +0800, Thomas Preud'homme wrote: > By the way, would you agree to put your test code under the MIT license > as tcc? It would be a nice addition to tcc's test suite. Yes, the MIT license is fine for me. -- Vincent Lefèvre - Web: 100% accessible va

[Tinycc-devel] compilation fails (git): conflicting types for gfunc_sret

Hi, I get the following error when compiling tcc from git: gcc -o x86_64-gen.o -c x86_64-gen.c -DCONFIG_LDDIR="\"lib\"" -DCONFIG_MULTIARCHDIR="\"x86_64-linux-gnu\"" -DTCC_TARGET_X86_64 -I. -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result x86_64-gen.c:106

[Tinycc-devel] incorrect permissions for some installed files on Unix

Some installed files have incorrect permissions (unneeded x bit set). I've just pushed a patch to "mob". -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

Re: [Tinycc-devel] add warning for signed unsigned comparisions

On 2014-01-10 10:48:12 +0100, Romain ... wrote: > It's strange because gcc haven't this behaviour. Concerning GCC, I've reported the following bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59753 For signed type T, the missing warning "overflow in implicit constant conversion" occurs only be

[Tinycc-devel] bug introduced by the latest changes

After the latest changes in the mob branch, the following program segfaults on Linux/x86_64: #include #include static char *val[] = { "1.0001@100" }; int main (void) { printf ("%s\n", val[0]); return 0; } Removing the "#include " line makes the bug disappear. -- Vincent Lefèvre - Web:

Re: [Tinycc-devel] bug introduced by the latest changes

On 2014-01-10 17:17:53 +0100, Vincent Lefevre wrote: > After the latest changes in the mob branch, the following program > segfaults on Linux/x86_64: > > #include > #include > > static char *val[] = { "1.0001@100" }; > > int main (void) > { > prin

Re: [Tinycc-devel] bug introduced by the latest changes

On 2014-01-11 22:39:28 +0800, Thomas Preud'homme wrote: > Can you try a git bisect to see what commit introduced this bug? The last two commits. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer a

[Tinycc-devel] signed zero handling is still buggy

On 2014-01-04 20:59:18 +0800, Thomas Preud'homme wrote: > Le vendredi 3 janvier 2014, 13:28:13 Thomas Preud'homme a écrit : > > Le vendredi 3 janvier 2014, 04:54:57 Vincent Lefevre a écrit : > > > Hi Thomas, > > > > > > On 2014-01-03 10:30:15 +08

Re: [Tinycc-devel] signed zero handling is still buggy

Hi, On 2014-01-12 04:59:06 +0100, Michael Matz wrote: > I think I've fixed that now on mob [1]. In particular +x is regarded as > no-op for floating point types (for integer types it's still x+0 so that the > promotions still happen automatically). And unary -x is now expanded as > subtract(-0,x

[Tinycc-devel] long double on x86-64

The LDBL_* macros of include/float.h were incorrect for x86-64: they corresponded to double precision instead of extended precision. I've fixed that in mob. FYI, the GNU MPFR trunk now passes all the tests on Linux/x86_64 when built with: ./configure --enable-assert=full --disable-shared CC=tcc

Re: [Tinycc-devel] tcc -E mangles >>

On 2014-03-31 12:51:45 +0100, Jay Foad wrote: > Instead of printing >>, this example prints the ASCII control character ^B: > > $ cat s.c > #define S >> > S > $ ./tcc -E s.c > # 2 "s.c" > ^B This bug has been introduced by: commit 0ac8aaab1bef770929e5592d02bc06d3a529952e Author: grischka Date:

Re: [Tinycc-devel] tcc -E mangles >>

On 2014-03-31 15:06:48 +0200, Vincent Lefevre wrote: > On 2014-03-31 12:51:45 +0100, Jay Foad wrote: > > Instead of printing >>, this example prints the ASCII control character ^B: > > > > $ cat s.c > > #define S >> > > S > > $ ./tcc -E s.c >

Re: [Tinycc-devel] macro expansion bug

On 2014-04-02 14:46:36 +0100, Jay Foad wrote: > With tcc I get: > > $ cat cat.c > #define CAT2(a,b) a##b > #define CAT(a,b) CAT2(a,b) > #define AB(x) CAT(x,y) > CAT(A,B)(x) > $ ./tcc -E cat.c > # 2 "cat.c" > > > CAT(x,y) > > But I think this is wrong, because gcc -E and clang -E both expand the

Re: [Tinycc-devel] Fwd: Bug#675024: tcc: errors "Symbol `mpfr_xxx' causes overflow in R_X86_64_PC32 relocation"

Hi, On 2014-04-02 21:45:54 +0200, Michael Matz wrote: > On Wed, 2 Apr 2014, Michael Matz wrote: > >>Another report about the current state of shared libraries produced by > >>tcc. Michael, I'm just copying it here because you asked. It's ok if you > >>don't want or can't work on this. > > > >Repor

Re: [Tinycc-devel] Fwd: Bug#675024: tcc: errors "Symbol `mpfr_xxx' causes overflow in R_X86_64_PC32 relocation"

On 2014-04-04 20:52:13 +0200, Michael Matz wrote: > Hi, > > On Fri, 4 Apr 2014, Vincent Lefevre wrote: > > >>Actually I just fixed a similar error for gawk (libtcc1.a containing non-PIC > >>code), which has exactly that symptom ('abort' and _PC32 reloc o

Re: [Tinycc-devel] What does 0xFF mean?

Hi, On 2014-06-27 19:51:37 +0800, YX Hao wrote: > Character "0xFF" was found in file "COPYING", and it is hard to > search the meaning without a proper keyword. I guess it has some > meaning for non-win applications. Can anyone give an explanation? > I am a win user, and view it by notepad2. Ther

Re: [Tinycc-devel] What does 0xFF mean?

On 2014-06-27 21:32:06 +0800, YX Hao wrote: > It is "0C" means form feed in "0A 0C 0A" showed "FF" with dark back > color that I made a misunderstanding. OK. I wonder why the FSF has put these Form Feed characters in this file. Their other raw-text license files don't have them. -- Vincent Lefèv

[Tinycc-devel] incorrect/missing license files

TCC is distributed with a file "COPYING", corresponding to the Lesser GPL. This is incorrect. Such a file is normally called "COPYING.LIB", and "COPYING" should contain the GPL. This is important because some files are distributed under the GPL only: il-opcodes.h lib/libtcc1.c texi2pod.pl

Re: [Tinycc-devel] What does 0xFF mean?

On 2014-06-27 21:56:39 +0800, YX Hao wrote: > > > I think I've already seen such a bug with some software, probably > > > because it wasn't detecting EOF (-1) correctly. > > Even if it is a "0xFF", it should not be the EOF, though many people > say it. You can make a file to test using my attachme

Re: [Tinycc-devel] incorrect/missing license files

On 2014-06-27 11:30:54 -0500, Evan Langlois wrote: > Stupid legal question. If TCC is GPL (rather than lesser GPL) and you > link with libtcc, then you would end up with software that was GPL. This > may be significant. Additionally, and start-up object files that TCC > generates may be consid

Re: [Tinycc-devel] incorrect/missing license files

On 2014-06-28 19:32:38 +0800, Thomas Preud'homme wrote: > Le vendredi 27 juin 2014, 20:45:55 Vincent Lefevre a écrit : > > I'm not sure, due to the GPL system library exception. > > There is some disagreement over what that exception means. As far as > I know, it onl

Re: [Tinycc-devel] incorrect/missing license files

On 2014-06-29 23:57:08 +0200, grischka wrote: > Change the FSF header in lib/libtcc1.c? I'm not sure they would > agree. However it allows being linked into any program anyway. How about *adding* the BSD copyright notice to this header? i.e. any future commit should be done under these two licen

Re: [Tinycc-devel] [PATCH] tccgen.c: Optimise 0<>x, -1>>x, x&0, x*0, x|-1, x%1.

On 2015-03-05 22:09:22 +, Edmund Grimley Evans wrote: > Do not optimise (0 / x) and (0 % x) here as x might be zero, though > for an architecture that does not generate an exception for division > by zero the back end might choose to optimise those. When x is 0, this is undefined behavior, so

Re: [Tinycc-devel] [PATCH] tccgen.c: Optimise 0<>x, -1>>x, x&0, x*0, x|-1, x%1.

On 2015-03-06 10:38:11 +, Edmund Grimley Evans wrote: > In general it is not allowed to write to one union member then > read from another and I don't know of an exception that covers > this particular case. It is legal: https://en.wikipedia.org/wiki/Type_punning#Use_of_union -- Vincent Lefè

Re: [Tinycc-devel] [PATCH] tccgen.c: Optimise 0<>x, -1>>x, x&0, x*0, x|-1, x%1.

On 2015-03-07 00:54:13 +0300, Sergey Korshunoff wrote: > 2015-03-06 12:48 GMT+03:00, Edmund Grimley Evans > : > > To explain a bit better what I mean: On a particular architecture I > > would like each of the following programs to do the same thing when > > invoked with no arguments, which isn't re

Re: [Tinycc-devel] CValue

On 2015-03-08 13:15:53 +0800, Thomas Preud'homme wrote: > If there is a lot of such union some space might be saved but I'm not > convinced it's significant. Setting a value in one field and accessing it in > another is forbidden by the C standard I think (aliasing?) It isn't forbidden, though t

Re: [Tinycc-devel] Dollar Sign in Identifiers Extension

On 2015-04-13 06:57:00 +0200, Christian Jullien wrote: > Good luck for nested function implementers that (as is Lisp :o) will > want to make this code working! Despite some users want C to be like LISP here, it must not be like in LISP. In C, a function is not an object, thus in particular, you ha

[Tinycc-devel] shared libraries and run-time path issues

I've reported the following problem for libtool 2.4.6: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=20622 but I wonder whether something can be improved on the tcc side (except by using static linking, which works). When I build GNU MPFR with CC=tcc LD=tcc and do "make check", I get things lik

Re: [Tinycc-devel] shared libraries and run-time path issues

On 2015-05-22 07:52:38 +0300, Sergey Korshunoff wrote: > > I wonder whether something can be improved on the tcc side > > The problem is that the MPFR library used at run time is not > > ../src/.libs/libmpfr.so but the one installed on the system. > > What the difference between gcc and tcc in thi

Re: [Tinycc-devel] shared libraries and run-time path issues

On 2015-05-22 10:51:47 +0200, Vincent Lefevre wrote: > With gcc, the run path is used with: > > -Wl,-rpath -Wl,/home/vlefevre/software/mpfr/src/.libs > > So, I assume that this is only a libtool bug, as libtool should generate > that too (this seems to work when I add tha

Re: [Tinycc-devel] Source vandalism

On 2015-07-29 08:56:47 -0400, gus knight wrote: > On Wed, Jul 29, 2015 at 8:50 AM, Michael Matz wrote: > > P.S: some of the reindendation changes look like as if you've replaced > > leading tabs with four spaces. That would have been wrong, tabs are eight > > spaces. If this is the case, fix you

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

On 2015-07-29 09:00:18 -0400, gus knight wrote: > Ah, oops. Looks like make didn't fail on the docs command as I expected it to. Also, don't forget to test out-of-tree builds with a read-only source directory. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML

[Tinycc-devel] parallel make failed

Hi, I got the following error when building tcc (mob branch) with a parallel "make" (make -j8) under Linux: [...] make[1]: Entering directory '/home/vlefevre/software/tinycc/lib' mkdir -p x86_64 ../tcc -B.. -c libtcc1.c -o x86_64/libtcc1.o -I.. -Wall -g -O0 -Wdeclaration-after-statement -Wno-dep

[Tinycc-devel] segmentation fault on any code compiled by tcc with glibc 2.21

With glibc 2.21 (Debian/unstable on x86_64), on any code compiled by tcc segfaults. This occurs with both old tcc (tcc 0.9.27~git20140923.9d7fb33-3 Debian package) and mob. I wonder whether this is a bug in tcc or in the glibc. For instance: ypig% cat conftest.c int main (void) { return 0; } ypig

Re: [Tinycc-devel] segmentation fault on any code compiled by tcc with glibc 2.21

On 2015-12-15 17:10:10 +0100, Vincent Lefevre wrote: > With glibc 2.21 (Debian/unstable on x86_64), on any code compiled by tcc > segfaults. This occurs with both old tcc (tcc 0.9.27~git20140923.9d7fb33-3 > Debian package) and mob. I wonder whether this is a bug in tcc or in th

Re: [Tinycc-devel] segmentation fault on any code compiled by tcc with glibc 2.21

On 2015-12-17 07:24:09 +0100, Michael Matz wrote: > Hi, > > On Tue, 15 Dec 2015, Vincent Lefevre wrote: > > > > With glibc 2.21 (Debian/unstable on x86_64), on any code compiled by > > > tcc segfaults. This occurs with both old tcc (tcc > > > 0.9.27~git201

Re: [Tinycc-devel] segfault when using tcc -run on Fedora 21 and 22

On 2016-01-09 15:02:11 -0500, Dylan Cali wrote: > tcc -run is segfaulting for me, and after inspecting the core dump the > cause is not obvious to me. I'm not sure if this is a tinycc bug or > something specific to my system. I'm inclined to think it's something > with tinycc, as I'm experiencing

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 Is there any reason why tcc hasn't rejected the code because the prototype wasn't decl

Re: [Tinycc-devel] Nevermind my previous comments. I just made an error.

On 2016-01-10 06:15:38 -0700, arn...@skeeve.com wrote: > > > 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: &

Re: [Tinycc-devel] Nevermind my previous comments. I just made an error.

On 2016-01-11 05:44:11 +0200, Aharon Robbins wrote: > C++ does reject the call. C is much more permissive. Try > > $ cat > hello.c > int main() { printf("hello, world\n"); return 0; } > ^D With the -pedantic-errors option (whose goal is to reject non-ISO programs), gcc rejects the code. This seem

Re: [Tinycc-devel] Nevermind my previous comments. I just made an error.

On 2016-01-11 20:49:53 -0700, arn...@skeeve.com wrote: > 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

Re: [Tinycc-devel] Nevermind my previous comments. I just made an error.

On 2016-01-12 10:38:18 +, Edmund Grimley Evans wrote: > For example, the ANSI spec says: "If the function is defined with a > type that does not include a prototype, and the types of the arguments > after promotion are not compatible with those of the parameters after > promotion, the behavior

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

On 2016-04-27 07:17:47 +0300, Sergey Korshunoff wrote: > 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 *fo

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

On 2016-04-25 13:29:46 +0300, Sergey Korshunoff wrote: > > 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

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

On 2016-04-25 13:29:46 +0300, Sergey Korshunoff wrote: > > 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

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

On 2016-04-27 13:06:14 +0300, Sergey Korshunoff wrote: > > 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. So does CompCert 2.4, but IMHO, this is an incorrect in

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

On 2016-04-27 18:21:11 +0300, Sergey Korshunoff wrote: > > 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. Note that

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

On 2016-04-29 00:50:59 +, Michael B. Smith wrote: > Don't you think it might it be a good idea to limit the possible > level of recursion? It seems that the standard doesn't provide a minimum limit for macro recursion. But it general, this is 63 nesting levels of [...]. > I don't have time to

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

On 2016-05-05 09:49:08 +0200, grischka wrote: > Btw, for tinyness I'd suggest to consider only valid C (which is not > "-" followed by ">" as two tokens, for example). I disagree. A preprocessing step followed by a compilation step should still follow the requirements from the C standard. In parti

[Tinycc-devel] incorrect bit-field behavior

tcc does not follow the integer promotion rules on bit-fields. For instance, consider the following code: #include union ui { struct { unsigned int manl:32; unsigned int manh:20; unsigned int exp:11; unsigned int sig:1; } s; double d; }; union ul { struct

[Tinycc-devel] multiple search paths (-Wl,-rpath)

-Wl,-rpath seems to be broken when this option is used several times. If I configure MPFR with: ./configure --prefix=/tmp CC=tcc LD=tcc CFLAGS=-O2 I get things like: libtool: link: tcc -O2 -o ty1 ty1.o -L../src/.libs ./.libs/libfrtests.a -lm ../src/.libs/libmpfr.so -lgmp -Wl,-rpath -Wl,/ho

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

On 2016-10-18 06:57:09 +0200, Christian Jullien wrote: > Hi all, > VC++ 32 and 64 both return: > t1 struct size: 2 > t2 struct size: 8 > t3 struct size: 8 > > Which IMHO is correct. I really don’t understand why gcc returns > t1 struct size: 2 > t2 struct size: 4 > t3 struct size: 4 AFAIK, both a

Re: [Tinycc-devel] Weird bitfield size handling, discrepancy with gcc

On 2016-10-18 09:59:36 +0200, Daniel Glöckner wrote: > On Tue, Oct 18, 2016 at 09:41:49AM +0200, Vincent Lefevre wrote: > > AFAIK, both are correct. > > It depends on the ABI. The ARM EABI defines those details in > http://infocenter.arm.com/help/topic/com.arm.doc.ihi0042f/

Re: [Tinycc-devel] Ready for Release 0.9.27

Hi, On 2017-02-08 23:09:05 +, Thomas Preud'homme wrote: > On mercredi 8 février 2017 20:15:10 GMT grischka wrote: > > Anyone else any patches that that 0.9.27 should still have? > > I'd like to fix > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=832759 (if it is > indeed a bug, I haven't

Re: [Tinycc-devel] Ready for Release 0.9.27

On 2017-02-09 21:01:11 +, Thomas Preud'homme wrote: > On jeudi 9 février 2017 18:40:13 GMT grischka wrote: > > Vincent Lefevre wrote: > > > The C standard says: > > > 6.3.1.1 Boolean, characters, and integers > > > > > > [...] > >

Re: [Tinycc-devel] Annoying new warning

On 2017-05-02 14:24:22 +0200, Christian Jullien wrote: > When I see this warning, it makes me think that application will produce > unpredictable results based on value on stack. > That's why I consider this as an annoying warning. Certainly, but providing fake initialization may have the conseque

Re: [Tinycc-devel] Annoying new warning

On 2017-05-03 11:39:16 +0200, grischka wrote: > Interesting. Obviously I removed the suppression of some warnings, > among them "uninitialized" ;) See the change in configure: > > -W_OPTIONS="deprecated-declarations strict-aliasing pointer-sign\ > sign-compare unused-result u

Re: [Tinycc-devel] Annoying new warning

On 2017-05-05 06:46:27 +0200, Christian Jullien wrote: > Ok, I tried this patch which allowed me to run my complete non-regression > test suite without problem on ARM. > > Do you agree I push this patch in mob? > > diff --git a/lib/libtcc1.c b/lib/libtcc1.c > index 9195489..bcdfb0b 100644 > --- a

Re: [Tinycc-devel] Annoying new warning

On 2017-05-05 09:21:08 +0200, Christian JULLIEN wrote: > ___ > Tinycc-devel mailing list > Tinycc-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/tinycc-devel Your message is empty. -- Vincent Lefèvre - Web: 100%

Re: [Tinycc-devel] Annoying new warning

On 2017-05-05 17:29:22 +1000, William Hales wrote: > This is his message, copied and pasted: > > > Hi Vincent, > > > > return 666; works equally well as it should not be called by ARM backend. > > > > This is a workaround to remove warning. But this can hide bugs, e.g. if in the future this fun

Re: [Tinycc-devel] Annoying new warning

On 2017-05-05 13:02:05 +0200, grischka wrote: > Vincent Lefevre wrote: > > But this can hide bugs, e.g. if in the future this function is called > > by the ARM backend. It would be better either not to define this > > function at all (best solution at it doesn't make

Re: [Tinycc-devel] c89

On 2017-09-26 20:14:25 -0700, Larry Doolittle wrote: > Friends - > > On Tue, Sep 26, 2017 at 03:49:09PM -0700, Larry Doolittle wrote: > > Someone asked about c89. I made a simple experiment on mob. > > 1. Replace 67 //-style comments with /* */ > > 2. #define inline __inline__ in tcc.h > > 3.

Re: [Tinycc-devel] NAN and INFINITY break in different ways

On 2017-12-24 13:18:38 +0100, Michael Matz wrote: > On Sat, 23 Dec 2017, avih wrote: > > Alpine: > > $ tcc test.c > > testinfs.c:2: error: division by zero in constant > > > > $ tcc test.c -E > > ... > > static const double infs[] = { (0.0f/0.0f), 1e5000f }; > > ... > > > > So clearly tcc doesn't

Re: [Tinycc-devel] tcc coding style question

On 2019-01-24 16:10:03 +, Michael Matz wrote: > On Thu, 24 Jan 2019, Christian Jullien wrote: > > > Question (to maintainers): do you allow me to fix them all? > > Please don't. It makes git blame unnecessarily hard. Doesn't the -w option of "git blame" solve this issue. -- Vincent Lefèvr

Re: [Tinycc-devel] tcc coding style question

On 2019-01-24 17:50:39 +, avih wrote: > While `git blame -w` does skip white spaces changes, not all > tools/editors use it. In this case, the user could use an alias "blame = blame -w" in his git configuration. > In general, I think it's better to not do style-only changes except > in lines/

[Tinycc-devel] FIX: "make -j test" failed

Hi, When running "make -j test", I always got an error. Basic debug information: $ make --debug=b -j2 test GNU Make 4.2.1 Built for x86_64-pc-linux-gnu Copyright (C) 1988-2016 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free

Re: [Tinycc-devel] match formats and arguments exactly

On 2019-06-21 15:33:24 +0200, Christian Jullien wrote: > If I read you correctly, you want to protest if type does not > strictly match format directive. > > This is something even gcc does NOT ensure by default: [...] This is undefined behavior, and the compiler is not required to complain. This

Re: [Tinycc-devel] match formats and arguments exactly

On 2019-06-21 18:25:29 +0200, Ivo van Poorten wrote: > clang/llvm. gcc is on its way out IMHO. Apple uses clang extensively > for both macOS and iOS. It's the default compiler. And the Android > Linux kernel already builds with clang and soon vanilla will, too. > There are distro's almost fully bu

Re: [Tinycc-devel] match formats and arguments exactly

On 2019-06-22 01:07:17 +0200, Michael Matz wrote: > On Fri, 21 Jun 2019, Pascal Cuoq wrote: > > If no-one objects, I will push in a few days the following patch, > > I don't object, but have a request: can you explore if changing the type of > the respective variable, instead of adding casts, is e

Re: [Tinycc-devel] undefined sanitizer

On 2019-06-22 00:43:48 +0200, Michael Matz wrote: > Hi, > > On Tue, 18 Jun 2019, Mike wrote: > > > I keep having fun. > > In attach compile report under -fsanitize=undefined in gcc or clang. > > Take care. > > I don't think we should care about alignment of 4 (when 8 would be needed). > The 64bi

Re: [Tinycc-devel] match formats and arguments exactly

On 2019-06-22 20:34:35 +0200, Michael Matz wrote: > Hi, > > On Sat, 22 Jun 2019, Vincent Lefevre wrote: > > > > I don't object, but have a request: can you explore if changing > > > the type of the respective variable, instead of adding casts, is > >

Re: [Tinycc-devel] undefined sanitizer

On 2019-06-22 20:59:57 +0200, Michael Matz wrote: > Hi, > > On Sat, 22 Jun 2019, Vincent Lefevre wrote: > > > > > I keep having fun. > > > > In attach compile report under -fsanitize=undefined in gcc or clang. > > > > Take care. > > >

Re: [Tinycc-devel] undefined sanitizer

On 2019-06-23 06:51:04 +0200, Christian Jullien wrote: > > Yes, it's implementation defined, but I assume that -fsanitize=undefined > > warns only when the implementation has decided that this was incorrectly > > aligned. > > It's nice to have this warning even if implementation supports incorre

Re: [Tinycc-devel] undefined sanitizer

On 2019-06-23 08:53:33 +, Pascal Cuoq wrote: > Indeed. The thing is that such "mis"-alignment isn't generically undefined > behaviour (and hence shouldn't even be part of -fsanitize=undefined). It's > implementation defined what it means for a pointer to an object type to be > correctly align

Re: [Tinycc-devel] undefined sanitizer

On 2019-06-23 12:56:34 +0200, Christian Jullien wrote: > #if does not help to deal with different processors when only some > of them have performance penalties. That's entirely the choice of the developer. Under various means (compiler options, configure script, etc.), macros can be defined to gi

Re: [Tinycc-devel] Strange bug found?

On 2020-02-20 07:08:48 +, K K wrote: > am I wrong or is the following a bug in tinycc? It may be a bug, but your example is based on undefined behavior (see below), thus it is difficult to say (I mean that tcc does not necessarily exploit the fact that this is undefined behavior, which can exp

[Tinycc-devel] __builtin_constant_p is buggy on argument with side effect and constant value

FYI, I hve reported the following bug: https://savannah.nongnu.org/bugs/?58606 When the evaluation of a __builtin_constant_p argument would have a side effect, this argument should not be regarded as a constant because in practice, it may be used in an expression that evaluates the argument sev

  1   2   >