Re: [Tinycc-devel] RFC: Colored warnings/errors ?

On 2024-05-12 07:20:13 +, avih via Tinycc-devel wrote: > Personally I don't think this is required, but I don't pretend to > represent the tinycc maintainers' opinion. If it is added, however, > then the following should probably be taken into account: > > - This mostly works, but it won't

Re: [Tinycc-devel] Major bug in the pow function resulting in: 0.993013 = 0.860892

Hi, On 2024-01-05 13:47:25 +0100, Aurélie Tisson (BastaPrint) wrote: > The same calculation gives me 2 different values : 0.993013 0.860892 > wheras it should give 0.993013 only (tells GCC). Well, your code is not portable. > #include > #include > int main(){ > double s = .7; > double a =

Re: [Tinycc-devel] A double-to-float conversion bug

On 2023-07-30 16:07:29 +0600, Viktor M wrote: > Hello everyone. So today I stumbled upon this bug when doing math > involving conversions between float and double. A minimal example: [...] Not really minimal. I could simplify it even further: #include struct V { int x, y, z; }; struct V

Re: [Tinycc-devel] randomly failing tests

On 2022-12-28 10:07:19 -0500, NightStrike wrote: > On Wed, Dec 28, 2022, 06:46 Vincent Lefevre wrote: > > Perhaps, but the issue with ".NOTPARALLEL" is that it applies to > > the full Makefile, in case one just wants to serialize some tests. > > You can gi

Re: [Tinycc-devel] randomly failing tests

On 2022-12-28 06:00:11 -0500, NightStrike wrote: > On Wed, Dec 28, 2022, 03:31 Christian Jullien wrote: > > diff --git a/Makefile b/Makefile > > index c220879..c718d7a 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -447,14 +447,16 @@ config.mak: > > $(if $(wildcard $@),,@echo "Please

Re: [Tinycc-devel] randomly failing tests

On 2022-12-27 08:30:52 +0100, Herman ten Brugge via Tinycc-devel wrote: > Are you using parallel build? Yes, I have a shell function "make" that uses the -j option (with the number of available cores). > This does not work for the testsuite . If this doesn't work for the testsuite, why not

Re: [Tinycc-devel] randomly failing tests

On 2022-12-07 16:12:22 +0100, Vincent Lefevre wrote: > The cause seems to be that the generated executable name is fixed > to "a.exe" instead of depending on the test name: > > 113_btdll.test: T1 = \ > $(TCC) -bt $1 -shared -D DLL=1 -o a1$(DLLSUF) && \ >

Re: [Tinycc-devel] randomly failing tests

On 2022-12-07 16:06:27 +0100, Vincent Lefevre wrote: > Tests are failing randomly on Debian/x86_64: > > [...] > Test: 107_stack_safe... > Test: 108_constructor... > Test: 109_float_struct_calling... > Test: 110_average... > Test: 111_conversion.

[Tinycc-devel] randomly failing tests

Tests are failing randomly on Debian/x86_64: [...] Test: 107_stack_safe... Test: 108_constructor... Test: 109_float_struct_calling... Test: 110_average... Test: 111_conversion... Test: 112_backtrace... --- 108_constructor.expect 2022-12-07 15:57:51.358297673 +0100 +++ 108_constructor.output

Re: [Tinycc-devel] Unicode letter escape

On 2022-08-05 13:32:04 +0200, Samir Ribić via Tinycc-devel wrote: > Tcc supports \u escape sequence inside L"" but I have no idea how to > overcome this problem: > The code inside parse_escape_string function, in this part > >case 'x': > case 'u': > case 'U': >

Re: [Tinycc-devel] Unicode letter escape

On 2022-08-05 13:32:04 +0200, Samir Ribić via Tinycc-devel wrote: > Tcc supports \u escape sequence inside L"" but I have no idea how to > overcome this problem: > The code inside parse_escape_string function, in this part > >case 'x': > case 'u': > case 'U': >

Re: [Tinycc-devel] sizeof("string literal") is very wrong ~ On ARM or Apple Silicon

On 2022-08-05 09:22:42 +0200, Karl Yerkes wrote: > That did not help. It seems that there is a problem on ARM or Apple > Silicon, specifically: > > #include > int main() { > printf("%%lu: %lu\n", sizeof("this is a string")); > printf("%%d: %d\n", sizeof("this is a string")); >

Re: [Tinycc-devel] Broken commit e460f7dbb216

On 2022-08-01 14:13:09 +0200, grischka wrote: > On 30.07.2022 20:13, Vincent Lefevre wrote: > > On 2022-07-30 19:48:29 +0200, grischka wrote: > > > Sorry, what? Are you saying that (n & (n - 1)) with n == 1 -> (1 & 0) > > > and with n == 0 -> (0 & -1

Re: [Tinycc-devel] Broken commit e460f7dbb216

On 2022-07-30 19:48:29 +0200, grischka wrote: > On 30.07.2022 12:45, Vincent Lefevre wrote: > > I changed the & to && because it is more correct and makes more sense, > > but note that this is not really redundant because n is signed and > > n & (n - 1) is

Re: [Tinycc-devel] Broken commit e460f7dbb216

Hi, On 2022-07-30 11:02:39 +0200, grischka wrote: > On 28.07.2022 16:34, Detlef Riekenberg wrote: > > Hi grischka. > > > > Hi Detlef, > > Please try to be more precise. For example, in your last commit, > you wrote: > >"Do not fail with _Alignas(0) and _Alignas(1), used by autotools" >

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

On 2022-07-13 20:12:25 +0200, grischka wrote: > On 13.07.2022 17:17, Vincent Lefevre wrote: > > On 2022-07-13 12:01:57 +0200, grischka wrote: > > > There was no bug here in tcc, it was/is just different behavior, fully > > > intentional and even

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

On 2022-07-13 12:01:57 +0200, grischka wrote: > There was no bug here in tcc, it was/is just different behavior, fully > intentional and even documented with a test case. There was a bug in tcc: the ISO C standard requires a diagnostic. > Is it necessary or a good idea to remove that

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

On 2022-07-11 21:57:45 +0800, Ziyao wrote: > The simpliest example is like below: > > #if 0 > " > #if 0 > " > #endif > #endif Going back to this example, even if GCC doesn't give an error, consider a slight variation: #if 0 R"-( #if 0 )-" #endif #endif This time, one gets an error with gcc

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

On 2022-07-12 05:35:50 +0200, Vincent Lefevre wrote: > On 2022-07-12 10:31:26 +0800, Ziyao wrote: > > So is it better to throw an error and then stop > > compiling here like gcc? > > With GCC, this is an error only with -pedantic-errors or similar. > But there is at leas

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

On 2022-07-12 10:31:26 +0800, Ziyao wrote: > - Original Message - > From: "Vincent Lefevre" > To: tinycc-devel@nongnu.org > Sent: Tue, 12 Jul 2022 02:44:50 +0200 > Subject: Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 > blocks > > T

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

On 2022-07-12 06:57:41 +0800, Ziyao wrote: > On Mon, Jul 11, 2022 at 05:47:31PM +0200, Domingo Alvarez Duarte wrote: > > Hello Ziyao ! > > > > Although gcc compiles a file containing your example with warnings, I'm not > > sure it's worth try to do the same in TiinyCC the preprocessor probably

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

On 2022-07-12 06:56:34 +0800, Ziyao wrote: > > while with tcc: > > > > zira:~> tcc -E err.c > > # 1 "err.c" > > # 1 "" 1 > > # 2 "err.c" 2 > > > > > > " > > FOO > > " > > "FOO" > > > > which makes more sense as an extension, IMHO. But tcc doesn't give > > any diagnostic there, and I think that

Re: [Tinycc-devel] Bug that TinyCC Analyses Strings inside #if 0 blocks

On 2022-07-11 17:47:31 +0200, Domingo Alvarez Duarte wrote: > Although gcc compiles a file containing your example with warnings, I'm not > sure it's worth try to do the same in TiinyCC the preprocessor probably uses > TOKENS from the lexer to decide to skip till the end of the initial "#if 0" >

Re: [Tinycc-devel] Constant Initializer for Static Variables

On 2022-04-13 18:56:55 -0700, Elijah Stone wrote: > const vars are not integer constant expressions; your code is not guaranteed > to work. Some gnu exts are implemented; this one is not. Note that this is more an implemention-defined feature than an extension. The C standard says: 6.6

Re: [Tinycc-devel] NULL pointer dereference due to unchecked return from fdopen()

On 2022-02-28 10:50:29 +0100, grischka wrote: > Christian Jullien wrote: > > Thanks, > > This is unfortunately not the only case where returned value is not tested, > > just for fdopen, if maintainers agree, we can probably apply: > > Wdyt? > > The rule is, as always: don't write code that you

Re: [Tinycc-devel] manually inlining functions

On 2021-04-30 20:50:36 -0700, Elijah Stone wrote: > On Sat, 1 May 2021, Yakov wrote: > > > having to write macros for performance feels so obsolete, double > > evaluation hiding in dark corners etc. And function calls are so > > expensive in tight loops. > > Calls are fairly cheap, on modern

Re: [Tinycc-devel] manually inlining functions

On 2021-05-01 00:43:27 +, Kyryl Melekhin wrote: > Yakov wrote: > > > Kyryl you cannot inline everything because you will get code > > explosion, often infinite code explosion when functions have a > > circular dependency on each other. I am just talking about inlining > > certain functions

Re: [Tinycc-devel] Warning message about string assignment

On 2021-04-25 03:08:44 +0300, Stefanos wrote: > I use `tcc version 0.9.27 - 1432574 (x86_64 Linux)` and the code I'm testing > is: > > #include > #include > > int main(void) > { > char *s = "Hello, world!"; > printf("String length is %zu characters long.\n",

Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e

On 2021-04-19 17:57:04 +0200, Michael Matz wrote: > On Mon, 19 Apr 2021, Michael Matz wrote: > > I'm not sure what "this" refers to here, but we basically need to accept > > any of these forms of decls and defs of main: > > > > int main(); > > int main() { ... } > > void main(); > > void main() {

Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e

On 2021-04-18 13:01:05 +0300, Stefanos wrote: > On Sun, 18 Apr 2021 06:35:22 +0200 > "Christian Jullien" wrote: > > So it does not make difference if main is defined with or without (void) > > Allow me to disagree here. > > A simple example taken from >

Re: [Tinycc-devel] Clarification about log message in commit 48df89e10e

On 2021-04-17 19:12:38 +0300, Stefanos wrote: > The reason I asked this question is because I was reading the C standard and > found the following parts at 5.1.2.2.1 [1] and at 6.7.5.3/14 [2]: [...] > An identifier list declares only the identifiers of the > parameters of the function. An

Re: [Tinycc-devel] __LINE__ and #line undelying type

On 2021-04-16 14:52:50 +0100, Edmund Grimley Evans wrote: > Riddle me this: > > $ gcc --version | head -n 1 > gcc (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 > $ printf '#line 60129542143\n__LINE__' | gcc -E - | grep -v ^# > 4294967295 > $ printf '#line 60129542144\n__LINE__' | gcc -E - | grep -v ^#

Re: [Tinycc-devel] __LINE__ and #line undelying type

On 2021-04-16 07:11:27 +0200, Christian Jullien wrote: > C standard says nothing about line int overflow so tcc can't be > declared as wrong. I've looked at the C standard, and I could see nowhere that an implementation is allowed to restrict the line number to the int type. Actually, it more or

Re: [Tinycc-devel] __LINE__ and #line undelying type

On 2021-04-16 07:11:27 +0200, Christian Jullien wrote: > Even more strange, __LINE__ type changes as it overflows on clang, and gcc: > > int > main() { > #line 2147483647 > printf("__LINE__: %s\n", TYPEOF(__LINE__)); > #line 30 > printf("__LINE__: %s\n", TYPEOF(__LINE__)); > } > >

Re: [Tinycc-devel] Regarding Long double Constant

On 2021-02-11 13:49:48 +0100, Christian Jullien wrote: > No, I think he probably meant (1F-1F) to get 0.0F value? In the other function, f1 is a variable. I don't see why (1F-1F) would be used: 0.0F would be simpler, and even that, there should be no difference with 0.0, because the zero is

Re: [Tinycc-devel] Assertion Failed

On 2021-02-11 11:58:52 +, Zhuo Zhang wrote: > I use tcc at commit fbef90a7039b994907db34fde50f6fa5e46ab535, > because I cannot successfully compile tcc with the newest commit. 405aef9155fb66e280dac82ce521d5d2ea06f2ab should be reverted. It is definitely wrong. -- Vincent Lefèvre - Web:

Re: [Tinycc-devel] Regarding Long double Constant

On 2021-02-11 09:27:30 +0100, Ayush Varshney wrote: > *Long double constant problem* is for storing the value of 0.0, tcc > stores 0.0 in memory as long double value but long double value in > tcc takes only 10 bytes but the source code stores 0.0 value in 12 > bytes. The extra two bytes creates

Re: [Tinycc-devel] [bootstrappable] Re: Re: wip-full-source-bootstrap: from a 357-byte `hex0' to 'hello'

On 2021-01-08 13:36:26 +, Orians, Jeremiah (DTMB) wrote: > > If so, is libc malloc supposed to ensure alignment of allocated memory? > > According to https://man7.org/linux/man-pages/man3/malloc.3.html yes. > > @Janneke: So our mes libc malloc should be aligning the stuff--but it's not > >

Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs

On 2021-01-04 04:59:28 +0100, Michael Matz wrote: > Hello, > > On Mon, 4 Jan 2021, Vincent Lefevre wrote: > > > > - > > > #include > > > #include > > > #include > > > > > > int main(int argc, char

Re: [Tinycc-devel] x86_64 tcc doesn't set sign bit on NaNs

On 2021-01-03 21:17:03 +0200, Arnold Robbins wrote: > 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

Re: [Tinycc-devel] A possible bug in TCC

On 2020-12-13 14:40:17 +0300, Anton Shepelev wrote: > Hello, all > > During the recent exercise in comp.lang.c in writing a C > program to strip comments from a C source, I have > encountered what seems to be a bug in TCC. It is manifest > when compiling looser drug's entry with TCC and feeding

Re: [Tinycc-devel] Request for "fix float to u64 intrinsics"

On 2020-09-11 18:01:36 +0200, Vincent Lefevre wrote: > On 2020-09-11 11:11:47 +, Kyryl Melekhin wrote: > > If this is undefined behavior, then this line is straight up also UB. > > https://repo.or.cz/tinycc.git/blobdiff/55f8963dfab5c543f7f34589d

Re: [Tinycc-devel] Request for "fix float to u64 intrinsics"

On 2020-09-11 11:11:47 +, Kyryl Melekhin wrote: > If this is undefined behavior, then this line is straight up also UB. > https://repo.or.cz/tinycc.git/blobdiff/55f8963dfab5c543f7f34589d3ef9d3f2da3db14..310e3b428cfd181b51723276e6563b90d670da06:/tccgen.c > And because that line is UB, then it

Re: [Tinycc-devel] Request for "fix float to u64 intrinsics"

On 2020-09-11 10:32:06 +, Kyryl Melekhin wrote: > I guess I'll explain the bug here as well. > consider this code: > > float a = -123.987; > printf("%lu", (unsigned long int)a); > > Before the patch output would be 123. > After the patch output would be 18446744073709551493. There's no bug.

Re: [Tinycc-devel] Distribute TCC as a single binary, or make it portable enough to work outside the environment

On 2020-09-04 16:18:13 +0200, Samir Ribić wrote: > I do not think that C compiler since K days is designed to work as a > single binary, although I like this feature. The very first line in every C > program #include means that you need to append a separate file from disk > into your source. No,

Re: [Tinycc-devel] aarch64: subnormal double to long double conversion bug

On 2020-07-15 23:15:59 +0200, Michael Matz wrote: > Hello, > > On Wed, 15 Jul 2020, Vincent Lefevre wrote: > > > With TCC mob on aarch64, the double to long double conversion > > is buggy on subnormal values. This makes a MPFR test fail > > (reported by C

[Tinycc-devel] the format of the __TINYC__ macro should be documented

The TCC manual just says about the __TINYC__ macro: * '__TINYC__' is a predefined macro to indicate that you use TCC. But it actually contains the version, computed with sprintf(buffer, "%d", a*1 + b*100 + c); This should be documented (this is not obvious without reading the source

[Tinycc-devel] aarch64: subnormal double to long double conversion bug

With TCC mob on aarch64, the double to long double conversion is buggy on subnormal values. This makes a MPFR test fail (reported by Christian Jullien). Testcase: #include int main (void) { volatile double d = 0x0.88p-1022; /* subnormal */ printf ("d = %a\n", d); printf ("d = %.40g\n",

Re: [Tinycc-devel] Regression building GMP with tcc, bisected

On 2020-07-05 21:22:27 -0400, John Scott wrote: > tcc 0.9.27 works, but current mob fails during GMP's configure step. For GMP > I > use --disable-assembly and --disable-static, and it fails on > checking how to define a 32-bit word... configure: error: cannot determine > how > to define a

[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

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

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

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

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

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

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

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

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.

[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

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

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

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

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

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

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:

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

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

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

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

[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

[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

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

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

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

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

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

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 <vinc...@vinc17.net> wrote: > > > IMHO, nowadays, it would be better for the user if compilers reject > > > implicit declaration of functions by default, since warnings can > &

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

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

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

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

[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; }

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

[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

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 vinc...@vinc17.net - Web: https://www.vinc17.net/ 100% accessible

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 matz@frakked.de 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

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 this case?

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 that manually). I've submitted

[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

Re: [Tinycc-devel] [PATCH] tccgen.c: Optimise 0x, 0x, -1x, x0, 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

  1   2   >