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

2024-05-12 Thread Vincent Lefevre 
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 work on all terminals, for instance
>  the original DEC VT100 has bold but doesn't have colors.
> 
> - It's probably better to support disabling it by means other than
>  piping stderr into "cat" (so that stdout is not a tty). I.e. using
>  an option, probably with value always/never/auto. Preferably it
>  should also respect NO_COLOR by default. see https://no-color.org/ .

In any case, it should automatically detect whether colors are
supported by the terminal (something similar to what "tput colors"
does), something that GCC fails to do.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2024-01-05 Thread Vincent Lefevre 
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 = (1. - .1 * s) / (1. + .1 * s); 
  ^^^ ^^^
> double b = pow(a, .05); 
> double c = pow( ((1. - .1 * s) / (1. + .1 * s)), .05); 
^^^ ^^^

> printf("%f %f \n", b, c); 
> } 

You should not depend on contraction of FP expressions.
Here, GCC may generate a FMA, which generally increases
the accuracy of the results.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2023-07-30 Thread Vincent Lefevre 
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 vec(void)
{
  return (struct V) { 0, 0, 1 };
}

void func(float f, struct V v)
{
  printf("%f\n", f);
}

int main(void)
{
  float d = 5.0f;
  func(d, vec());
  return 0;
}

I get successively on x86_64:

-213.969727
-0.01
-0.00
44308718004014403453773152256.00

Putting the 5.0f in the argument instead of d, or reducing the
struct size, or changing float to double makes the bug disappear.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] randomly failing tests

2022-12-28 Thread Vincent Lefevre 
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 give it prerequisites to overcome that.

This is not possible. From the GNU make manual:

  '.NOTPARALLEL'

If '.NOTPARALLEL' is mentioned as a target, then this invocation of
'make' will be run serially, even if the '-j' option is given.  Any
recursively invoked 'make' command will still run recipes in
parallel (unless its makefile also contains this target).  Any
prerequisites on this target are ignored.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] randomly failing tests

2022-12-28 Thread Vincent Lefevre 
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 run ./configure." && exit 1)
> >
> >  # run all tests
> > +SERIALIZE = -j1
> > +
> >  test:
> > -   @$(MAKE) -C tests
> > +   @$(MAKE) $(SERIALIZE) -C tests
> >  # run test(s) from tests2 subdir (see make help)
> >  tests2.%:
> > -   @$(MAKE) -C tests/tests2 $@
> > +   @$(MAKE) $(SERIALIZE) -C tests/tests2 $@
> >
> >  testspp.%:
> > -   @$(MAKE) -C tests/pp $@
> > +   @$(MAKE) $(SERIALIZE) -C tests/pp $@
> >
> >  clean:
> > @rm -f tcc$(EXESUF) tcc_p$(EXESUF) *-tcc$(EXESUF) tags ETAGS *.pod
> 
> I think what you want is .NOTPARALLEL:
> 
> https://www.gnu.org/software/make/manual/html_node/Parallel-Disable.html

Perhaps, but the issue with ".NOTPARALLEL" is that it applies to
the full Makefile, in case one just wants to serialize some tests.

However, Herman ten Brugge fixed the issue yesterday in
commit 7ed9c95ae795dd71c624ffb0d82f267b2c9697af to allow
a parallel build. I've just checked that it works. Thanks!

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] randomly failing tests

2022-12-27 Thread Vincent Lefevre 
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 disabling the parallel
build of the testsuite?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] randomly failing tests

2022-12-07 Thread Vincent Lefevre 
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) && \
> $(TCC) -bt $1 -shared -D DLL=2 -o a2$(DLLSUF) && \
> $(TCC) -bt $1 a1$(DLLSUF) a2$(DLLSUF) -Wl,-rpath=. -o a.exe && \
> ./a.exe
> 
> T2 = $(if $(NORUN),$1 -o a.exe && ./a.exe,-run $1)
> 
> GEN-CC = $(CC) -w -std=gnu99 $(FLAGS) $1 -o a.exe && ./a.exe $(ARGS)

Changing the T2 line to

  T2 = $(if $(NORUN),$1 -o a-$1.exe && ./a-$1.exe,-run $1)

avoids the failures for me, but I don't know whether this is OK
everywhere or sufficient.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] randomly failing tests

2022-12-07 Thread Vincent Lefevre 
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...
> Test: 112_backtrace...
> --- 108_constructor.expect  2022-12-07 15:57:51.358297673 +0100
> +++ 108_constructor.output  2022-12-07 16:03:55.125155438 +0100
> @@ -1,3 +1 @@
> -constructor
> -main
> -destructor
> +/bin/sh: 1: ./a.exe: Text file busy
> make[3]: *** [Makefile:131: 108_constructor.test] Error 1
[...]

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) && \
$(TCC) -bt $1 -shared -D DLL=2 -o a2$(DLLSUF) && \
$(TCC) -bt $1 a1$(DLLSUF) a2$(DLLSUF) -Wl,-rpath=. -o a.exe && \
./a.exe

T2 = $(if $(NORUN),$1 -o a.exe && ./a.exe,-run $1)

GEN-CC = $(CC) -w -std=gnu99 $(FLAGS) $1 -o a.exe && ./a.exe $(ARGS)

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Tinycc-devel] randomly failing tests

2022-12-07 Thread Vincent Lefevre 
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  2022-12-07 16:03:55.125155438 +0100
@@ -1,3 +1 @@
-constructor
-main
-destructor
+/bin/sh: 1: ./a.exe: Text file busy
make[3]: *** [Makefile:131: 108_constructor.test] Error 1
Test: 113_btdll...
Test: 115_bound_setjmp...
Test: 114_bound_signal...
Test: 116_bound_setjmp2...
Test: 117_builtins...
Test: 118_switch...
Test: 119_random_stuff...
Test: 120_alias...
Test: 121_struct_return...
Test: 122_vla_reuse...
--- 114_bound_signal.expect 2022-12-07 15:57:51.358297673 +0100
+++ 114_bound_signal.output 2022-12-07 16:03:55.169155305 +0100
@@ -1,2 +1,5 @@
-start
-end
+in target function
+in target function
+in target function
+in target function
+in target function
make[3]: *** [Makefile:131: 114_bound_signal.test] Error 1
Test: 123_vla_bug...
Test: 124_atomic_counter...
[...]

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Unicode letter escape

2022-08-05 Thread Vincent Lefevre 
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':
> p++;
> n = 0;
> for(;;) {
> c = *p;
> if (c >= 'a' && c <= 'f')
> c = c - 'a' + 10;
> else if (c >= 'A' && c <= 'F')
> c = c - 'A' + 10;
> else if (isnum(c))
> c = c - '0';
> else
> break;
> n = n * 16 + c;
> p++;
> }
[...]

Note that tccpp.c already has code that selects the right number of
digits:

case 'x': i = 0; goto parse_hex_or_ucn;
case 'u': i = 4; goto parse_hex_or_ucn;
case 'U': i = 8; goto parse_hex_or_ucn;
parse_hex_or_ucn:
p++;
n = 0;
do {
c = *p;
if (c >= 'a' && c <= 'f')
c = c - 'a' + 10;
else if (c >= 'A' && c <= 'F')
c = c - 'A' + 10;
else if (isnum(c))
c = c - '0';
else if (i > 0)
expect("more hex digits in universal-character-name");
else {
c = n;
goto add_char_nonext;
}
n = n * 16 + c;
p++;
} while (--i);
cstr_u8cat(outstr, n);
continue;

Perhaps some code could be shared, possibly via an inline function...

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Unicode letter escape

2022-08-05 Thread Vincent Lefevre 
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':
> p++;
> n = 0;
> for(;;) {
> c = *p;
> if (c >= 'a' && c <= 'f')
> c = c - 'a' + 10;
> else if (c >= 'A' && c <= 'F')
> c = c - 'A' + 10;
> else if (isnum(c))
> c = c - '0';
> else
> break;
> n = n * 16 + c;
> p++;
> }
> 
> does not limit the size of the hexadecimal number written after the \u
> escape code. Why is this a problem? If the text with an unicode letter is
> followed by letters a,b, c, d, e or f, it will be part of the code itself.
> For example L"Mogu\u0107i" will display the word "Mogući" as should be,
> because the code 0107 is c acute.  However, the word L"Mogu\u0107e" will
> not display "Moguće" but "Moguၾ" because 107e is  Myanmar Shan Fa
> 
> Section 6.4.3 of C99 standard  ISO/IEC 9899:1999(E) -- Programming
> Languages -- C (uchile.cl)
>  states
> that \u escape sequence requires exactly four hexadecimal digits, so
> the code above needs  to be changed.

And exactly 8 hexadecimal digits for \U.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-08-05 Thread Vincent Lefevre 
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"));
>   printf("%%zu: %zu\n", sizeof("this is a string"));
> }

In any case, this code has undefined behavior. Just use %zu,
nothing else.

That said, if size_t has the same size as unsigned long, the first
line should have probably been correct in practice, and

> $ tcc tcc-string-literal-sizeof.c
> FIXME: handle reloc type 9 at 1052 [0x6155c032] to 1050

may be an issue with tcc (though this is conform to the standard).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Broken commit e460f7dbb216

2022-08-02 Thread Vincent Lefevre 
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) does not evaluate to 0 in both cases always
> > > necessarily, in C?
> > 
> > Yes, if the 0 happens to be a negative 0, 1 & 0 will give 1
> > in ones' complement, and 0 & -1 will also give non-zero in
> > both ones' complement and "sign and magnitude".
> 
> Okay, I was not thinking about that.  Still, nothing just "happens".
> 
> For example, 0 cannot "happen" to be a negative 0.  A negative 0
> needs to be generated, for example using the complement operator ~0.

Indeed, so that's not possible with n == 1, because 1 - 1 necessarily
generates a normal zero.

> We need to be precise.  When we are considering two cases, 1 and 0
> this clearly does not include a third case ~0.
> 
> What you maybe are trying to say is that we do not know whether
> n = expr_const();
> could maybe return a negative zero on an imaginary platform.

Yes, but not an imaginary platform (this is in the standard because
such platforms existed). Rather an obsolete platform. According to
Wikipedia: "Many early computers, including the UNIVAC 1101, CDC 160,
CDC 6600, the LINC, the PDP-1, and the UNIVAC 1107, used ones'
complement arithmetic. Successors of the CDC 6600 continued to use
ones' complement arithmetic until the late 1980s, and the descendants
of the UNIVAC 1107 (the UNIVAC 1100/2200 series) still do, but the
majority of modern computers use two's complement." Concerning the
UNIVAC 2200 series, Wikipedia mentions "UNISYS ClearPath Dorado 8300
introduced in 2015". If it still uses ones' complement (at least for
compatibility), this is not that old. However, this probably doesn't
concern tcc (unless someone tries to port tcc on these systems). And
about sign-magnitude, there was IBM 7090 according to Wikipedia.

> However this is not about tcc, it is about our knowledge about tcc
> pr the platform.   If we were interested we could update our knowledge
> and then we would make sure that unexpected negative zeros can never
> happen.
> 
> In conclusion I think we did prove that in both the existing as well
> as the imaginary tcc, the additional "(n > 1 &&" clause is and will
> remain redundant and unnecessary.

While I agree that unnecessary conditions should be avoided, this
case is particular, because the values n = 0 and 1 are particular
cases when one seeks to check that the code is correct (well, for
n = 1, it depends, but n = 0 is really a particular case). So the
"n > 1" condition could help to understand the code without having
to look at the various cases more closely.

Note that there are common advises that add unnecessary code, such as

  if (i != 0)

instead of

  if (i)

when i is an integer. And

  if (a = b)

is strongly discouraged ("gcc -Wall" gives a warning).

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Broken commit e460f7dbb216

2022-07-30 Thread Vincent Lefevre 
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 not portable when n = 0 or 1 if two's complement isn't
> > necessarily used, because 0 may have several representations (well,
> > tcc is not designed to work on such exotic platforms, but who knows
> > in the future... and moreover, because of this general portability
> > issue, compilers may issue warnings).
> 
> Sorry, what?  Are you saying that (n & (n - 1)) with n == 1 -> (1 & 0)
> and with n == 0 -> (0 & -1) does not evaluate to 0 in both cases always
> necessarily, in C?

Yes, if the 0 happens to be a negative 0, 1 & 0 will give 1
in ones' complement, and 0 & -1 will also give non-zero in
both ones' complement and "sign and magnitude".

ISO C17 says:

  It is unspecified whether these cases actually generate a
  negative zero or a normal zero, and whether a negative zero
  becomes a normal zero when stored in an object.

> > > As to the "n < 0 ||" clause by the way. the C-standards seem to say:
> > > 
> > >"Alignments are represented as values of the type size_t. Valid 
> > > alignments
> > > include only fundamental alignments, plus an additional 
> > > implementation-
> > > defined set of values, which may be empty.  Every valid alignment 
> > > value
> > > shall be a nonnegative integral power of two."
> > > 
> > > Well, when "size_t" means unsigned, how could it be not "nonnegative"
> > > then ?!?
> > 
> > I don't understand what you mean here. The fact is that in the code,
> > n is of type int, not size_t. So the case n < 0 needs to be taken
> > into account. Note that n comes from
> > 
> >n = expr_const();
> > 
> > thus may be negative.
> 
> Seems I have misunderstood what they are trying to say.  It seems that by
>"nonnegative integral power of two"
> they mean any powers 0..n of two, as in
> 2 ^ 0..n
> as opposed to
> 2 ^ -1.2
> for example.
> 
> That hasn't to do much with "int n = expr_const();" in tcc though because
> the 'n' there does not mean "2 ^ n", just as _Alignas(1) does not mean
> to align at 2 ^ 1.  It means to align at 2 ^ 0 = 1.

The point is that _Alignas(-2) is invalid.

> Therfor the combination
> 
> if (n < 0 || ...
> tcc_error("alignment must be a positive power of two");
> 
> still seems misleading.  "_Alignas(0x8000) int x;" is not an
> invalid declaration, per se.

Well, this depends on the implementation. If supported by tcc,
this is fine. But this should be documented, as this is an
implementation-defined feature.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Broken commit e460f7dbb216

2022-07-30 Thread Vincent Lefevre 
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"
> 
> But there wasn't anything wrong with _Alignas(1), to begin with.
> Also, the "(n > 1) &" part that you added in your one-line patch
> 
>-  if (n <= 0 || (n & (n - 1)) != 0)
>+  if (n < 0 || ((n > 1) & ((n & (n - 1)) != 0)))
> 
> is just redundant.  Unnecessary redundancy confuses the readers, and
> confused readers may add even more confusing stuff in sequence.
> (Now I see that "(n > 1) &" has changed to "(n > 1) &&" which, well,
> is still equally redundant.)

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 not portable when n = 0 or 1 if two's complement isn't
necessarily used, because 0 may have several representations (well,
tcc is not designed to work on such exotic platforms, but who knows
in the future... and moreover, because of this general portability
issue, compilers may issue warnings).

> As to the "n < 0 ||" clause by the way. the C-standards seem to say:
> 
>   "Alignments are represented as values of the type size_t. Valid alignments
>include only fundamental alignments, plus an additional implementation-
>defined set of values, which may be empty.  Every valid alignment value
>shall be a nonnegative integral power of two."
> 
> Well, when "size_t" means unsigned, how could it be not "nonnegative"
> then ?!?

I don't understand what you mean here. The fact is that in the code,
n is of type int, not size_t. So the case n < 0 needs to be taken
into account. Note that n comes from

  n = expr_const();

thus may be negative.

BTW, the condition seems incomplete because large values are forbidden.
ISO C17 says in 6.2.8p2:

  A fundamental alignment is a valid alignment less than or equal to
  _Alignof (max_align_t).

and in 6.7.5p3 (a constraint):

  The constant expression shall be an integer constant expression.
  It shall evaluate to a valid fundamental alignment, or to a valid
  extended alignment supported by the implementation for an object
  of the storage duration (if any) being declared, or to zero.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-07-13 Thread Vincent Lefevre 
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 documented with a test case.
> > 
> > There was a bug in tcc: the ISO C standard requires a diagnostic.
> 
> Well, define "bug" ...?
> 
> In my book, a bug is unwanted behavior in the sense of unwanted by
> the person who wrote the code.  It is when what I wrote (for example)
> doesn't do what I want.
> 
> Common sources of bugs are, beyond simple mistakes, that (1) I maybe don't
> really know what I want, or maybe that (2) I refuse to acknowledge that
> what I want, in combination, is logically impossible.
> 
> It is not a bug, per se, when tcc doesn't work like gcc, or when it doesn't
> conform to the standards in some aspect.  As long the behavior is on purpose
> and consistent.  In my book.

Well, in the tcc manual, there seems to be an intent to support C99:

  TCC implements many features of the new C standard: ISO C99.  Currently
  missing items are: complex and imaginary numbers.

The absence of required diagnostics is not a missing item.

And note that this is not listed as an extension either.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-07-13 Thread Vincent Lefevre 
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 behavior/feature now from tcc?
> I've seen no arguments.

Detect bugs in user code.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-07-12 Thread Vincent Lefevre 
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 (default GNU dialect or C++):

err.c:6:2: error: #endif without #if
6 | #endif
  |  ^

And the following code

#if 0
R"-(
#if 0
)-"
#endif

does not give any warning or error (the behavior is different
if one provides an option like -std=c99 to follow ISO C99).

This is due to the use of a "raw string literal", specified
by C++11 (and this can also be regarded as a C extension),
which allows newline characters.

This shows that you cannot ignore parsing in a skipped block.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-07-12 Thread Vincent Lefevre 
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 least a warning.

After more testing, without -pedantic-errors, a missing terminating
" character becomes an error when compiling. It is a warning only at
the preprocessor level. So, if the buggy code is in a skipped block
(e.g., under "#if 0"), then this remains a warning since the code is
skipped at the preprocessor level.

But due to the possible confusion with a different way of parsing
(as currently done by tcc), I think that an error would be better
than a warning also at the preprocessor level.

> > Or just print a warning?
> 
> Since one cannot rely on portable behavior (the code is really
> ambiguous, with no natural interpretation), I think that an error
> would be better.
> 
> I think that the fact that GCC just emits a warning is that it
> assumes that in practice, the preprocessor will not be involved.
> But it may be wrong and the result may be unexpected by the user.

Since one gets an error at compile time, there must be another
reason.

Note also that

#include 

#define FOO "1
2"

int main (void)
{
  char *s = FOO;
  puts (s);
  return 0;
}

compiles without warnings or errors with tcc, and

1
2

is output by the generated program.

First, this breaks the ISO C syntax rules, thus a diagnostic is
required by the standard. Moreover, a multiline #define like that
(without backslash + newline) is unintuitive. So I would say that
the code should be rejected.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-07-11 Thread Vincent Lefevre 
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
> >  That's why I said that there should be
> > a diagnostic. So the missing diagnostic with tcc is a bug.
> > If the program is not rejected, the behavior is undefined.
> 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 least a warning.

> Or just print a warning?

Since one cannot rely on portable behavior (the code is really
ambiguous, with no natural interpretation), I think that an error
would be better.

I think that the fact that GCC just emits a warning is that it
assumes that in practice, the preprocessor will not be involved.
But it may be wrong and the result may be unexpected by the user.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-07-11 Thread Vincent Lefevre 
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 uses
> > TOKENS from the lexer to decide to skip till the end of the initial "#if 0"
> > and '"' is not a valid token the error probably come from the lexer that
> > found a non terminated string.
> > 
> For conditional inclusion,C99 document says:
>   Only the first group whose control condition evaluates to true
>   (nonzero) is processed. If none of the conditions evaluates to true,
>   and there is a #else directive, the group controlled by the #else is
>   processed; lacking a #else directive, all the groups until the
>   #endif are skipped.1
> In my understanding,the skipped part should NOT be processed.

To be able to skip it, the compiler needs to parse it as described
in 6.10. So code like

#if 0
#if 1
#else
foo
#endif
#else
OK
#endif

should give OK. And if anything violates the syntax during parsing,
one should get a diagnostic.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-07-11 Thread Vincent Lefevre 
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 this is incorrect.
> 
> It seems that TinyCC parses the first three lines as a string
> literature,does't it?

Yes, tcc ends the string literal only at a terminating " character
and seems to accept anything before it. This can be seen on

#define FOO bar
"
FOO

which gives an error

  err.c:4: error: missing terminating " character

at line 4.

> But according to C99 standard,
> 
> string-literal:
>   " s-char-sequenceopt "
>   L" s-char-sequenceopt "
> s-char-sequence:
>   s-char
>   s-char-sequence s-char
> s-char:
>   any member of the source character set except the double-quote ",
>   backslash \, or new-line character
>   escape-sequence
> 
> New-line character cannot be included in a string literature.

For this reason, this violates a syntax rule, and the C standard
says "A conforming implementation shall produce at least one
diagnostic message [...] if a preprocessing translation unit
or translation unit contains a violation of any syntax rule
or constraint [...]". That's why I said that there should be
a diagnostic. So the missing diagnostic with tcc is a bug.

If the program is not rejected, the behavior is undefined.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-07-11 Thread Vincent Lefevre 
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"
> and '"' is not a valid token the error probably come from the lexer that
> found a non terminated string.

I agree that tcc should reject the code. It is too ambiguous to be
regarded as an extension. GCC's interpretation is rather ugly.

Consider a file "err.c":

#define FOO bar
"
FOO
"
"FOO"

zira:~> gcc -E err.c 2> /dev/null
# 0 "err.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "err.c"

"
bar
"
"FOO"

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 this is incorrect.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-04-14 Thread Vincent Lefevre 
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 Constant expressions
[...]
  10  An implementation may accept other forms of constant expressions.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2022-02-28 Thread Vincent Lefevre 
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 cannot test.

Various other error cases are probably not tested.
Has anyone checked code coverage?

Testing the code can be done once by adding "fp = NULL;" and checking
that the error is correctly handled. Otherwise, perhaps with LD_PRELOAD
to define a fdopen wrapper that will simulate an error for some calls.

> Can you?
> 
> Otherwise, can we stop suggesting sloppily crafted quick patches
> addressing non-existent problems?

fdopen() may fail. So this is a real problem. However, the check for
errors should be done on the other related function calls too.

Not checking errors may yield obscure errors in user code and/or
data loss/corruption (this happened to me with GCC, which did not
check some write errors, so that data were randomly silently missing
on NFS and my scripts were failing with errors difficult to debug).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] manually inlining functions

2021-05-01 Thread Vincent Lefevre 
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 architectures.  The performance impact of
> an inliner would be fairly marginal for tcc, compared with, say, a register
> allocator.

Inline functions have (at least) 3 advantages:

1. They eliminate the call, which is rather useful in case a call
   to a function of a shared library, as such calls can be very
   expensive. For very simple functions (e.g. accessing a field
   of a structure), there would be much overhead.

2. With the inline definition, the compiler can know what the function
   does (e.g. enabling value range propagation), so that it may be
   able optimize the code around.

3. A call to an inline function may have specific arguments, such
   as constant ones, so that the compiler may be able to optimize
   the code of the instantiated function, e.g. avoiding tests and
   eliminating dead code via constant propagation.

I think that tcc could benefit from these 3 points.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] manually inlining functions

2021-05-01 Thread Vincent Lefevre 
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 carefully chosen by a programmer.
> 
> Yeah, I get that. That's why it is so hard to make such a tool.
> Because recursion is hard to decompose, so the inliner has to be
> smart enough to actually rewrite the recursive solution iteratively
> otherwise it will blow up.

In general, programmers mark functions as inline only when this
does not involve a recursion, though they are not obliged to do so.
With function-like macros, the preprocessor automatically disables
recursion. I suppose that the compiler can do the same thing with
inline functions (but it may also choose a higher recursion level).
Since tcc obviously supports function-like macros, handling recursion
for inline functions would not introduce a new difficulty.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2021-04-24 Thread Vincent Lefevre 
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", strlen(s));
> }
> 
> I execute it with the following command:
> 
> tcc -Wall -std=c11 -o test_strlen test_strlen.c
> 
> The warning is 
> 
> tmp.c:6: error: assignment discards qualifiers from pointer target type
> 
> With GCC and Clang does not throw any warning message.
> 
> The command I used for both is:
> 
> gcc -Wall -Wextra -Wpedantic -std=c11 -o test_strlen test_strlen.c
> clang -Wall -Wextra -Wpedantic -std=c11 -o test_strlen test_strlen.c

zira:~> gcc -Wwrite-strings -o test_strlen test_strlen.c
test_strlen.c: In function ‘main’:
test_strlen.c:6:13: warning: initialization discards ‘const’ qualifier from 
pointer target type [-Wdiscarded-qualifiers]
6 |   char *s = "Hello, world!";
  | ^~~

Here's what the GCC man page says:

  -Wwrite-strings
When compiling C, give string constants the type "const char[length]"
so that copying the address of one into a non-"const" "char *" pointer
produces a warning.  These warnings help you find at compile time code
that can try to write into a string constant, but only if you have
been very careful about using "const" in declarations and prototypes.
Otherwise, it is just a nuisance.  This is why we did not make -Wall
request these warnings.

This allows one to detect buggy code like

#include 

int main(void)
{
  char *s = "Hello, world!";
  memcpy (s, "foo", 4);
}

zira:~> gcc -o test_strlen test_strlen.c
zira:~> ./test_strlen
zsh: segmentation fault (core dumped)  ./test_strlen

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2021-04-19 Thread Vincent Lefevre 
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() { ... }
> 
> Gah!  And of course also the ones with void (which does declare a prototype
> even outside of a function def, then, and hence must match a definition if
> there's a separate one):
> 
> int main(void);
> int main(void) { ... }
> void main(void);
> void main(void) { ... }
> 
> > int main(int argc, char *argv[]);
> > int main(int argc, char *argv[]) { ... }
> > void main(int argc, char *argv[]);
> > void main(int argc, char *argv[]) { ... }

But I think it should warn on the forms without a prototype,
like "int main();".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2021-04-18 Thread Vincent Lefevre 
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 
> https://www.geeksforgeeks.org/difference-int-main-int-mainvoid/ shows the 
> difference:
> 
> /* Without void in main() */
> 
> int printf(const char*, ...);
> 
> int main()
> {
> static int i = 5;
> if (--i) {
> printf("%d ", i);
> main(10);
> }
> }
>  
> $ gcc -Wall -Werror -std=c11 foo.c -o foo
> $ ./foo
> 4 3 2 1

This works with this ABI, but this doesn't prove that this will work
on every platform. As I've said, with main(), the compiler doesn't
check the prototype. So you won't get an error from the compiler due
to inconsistent definition / calls.

> -
> 
> /* With void in main() */
>   
> int printf(const char*, ...);
> 
> int main(void)
> {
> static int i = 5;
> if (--i) {
> printf("%d ", i);
> main(10);
> }
> }
> 
> $ gcc -Wall -Werror -std=c11 foo.c -o foo
> foo.c: In function ‘main’:
> foo.c:8:9: error: too many arguments to function ‘main’
> 8 | main(10);
>   | ^~~~
> foo.c:3:5: note: declared here
> 3 | int main(void)
>   | ^~~~

This time, the prototypes are checked, so that you get an error.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2021-04-17 Thread Vincent Lefevre 
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 empty list in a function
> declarator that is part of a definition of that function
> specifies that the function has no parameters. The empty list in
> a function declarator that is not part of a definition of that

> function specifies that no information about the number or types
> of the parameters is supplied.
> 
> 
> In other words, all the tests that use `int main()` are open to accept 
> any number of parameters, correct?

"int main ()" defines no prototype, meaning that the compiler cannot
check whether the code is correct or not. This is old K C and should
no longer be used in general. AFAIK, for a function definition, if you
do not declare parameters in the K way, this is equivalent to void.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2021-04-16 Thread Vincent Lefevre 
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 ^#
> :1:7: warning: line number out of range
> 0
> $ gdb
> (gdb) p/x 60129542143
> $1 = 0xd
> (gdb)

Well, providing a #line value larger than the maximum allowed by
the C standard is undefined behavior, and a diagnostic is not
required because this is not a constraint here. But here, this
is probably a bug in GCC.

$ printf '#line 4294967296\n__LINE__' | gcc -E - | grep -v "^#"
:1:7: warning: line number out of range
0
$ printf '#line 8589934591\n__LINE__' | gcc -E - | grep -v "^#"
4294967295
$ printf '#line 8589934592\n__LINE__' | gcc -E - | grep -v "^#"
:1:7: warning: line number out of range
0

I suspect that some bound test may be wrong. For instance, it
correctly detects the issue when converted to int, it gives a
nonnegative value, but not for negative values (and the output
seems to be done with an unsigned int).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2021-04-16 Thread Vincent Lefevre 
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 less implies the opposite, at least
in C99 (I don't know in previous versions):

6.10.4 Line control
[...]
 3  A preprocessing directive of the form

  # line digit-sequence new-line

causes the implementation to behave as if the following sequence
of source lines begins with a source line that has a line number
as specified by the digit sequence (interpreted as a decimal
integer). The digit sequence shall not specify zero, nor a number
greater than 2147483647.

So I suppose this means that values up to 2147483647 (and probably
the following ones, otherwise using 2147483647 would be useless)
need to be supported. In implementations with 16-bit int, this would
mean that the line number for such large values is represented by a
long (or long long).

Also note that __LINE__ expand to an integer constant, which doesn't
include negative integers.

> Now I agree with you that tcc should better handle those cases (as
> gcc does?)

It should just follow the C standard. In practice, it should at least
support values up to 2^32 - 1 (2147483647 is 2^31 - 1, so that
supporting 32-bit line numbers as positive integers is needed, and
it is highly unlikely that huge source files reach 33-bit values).
But of course, if you use a 64-bit type for the internal type, this
is fine.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2021-04-16 Thread Vincent Lefevre 
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__));
> }
> 
> jullien@sims4:~ $ gcc -std=c11 foo.c -o foo && ./foo
> __LINE__: int
> __LINE__: long long

I think that this is expected. The standard just says that it is an
integer constant, not that it has a fixed type (which could break
many applications, as the largest type would have to be chosen even
for small line numbers). In practice, it just probably gives a
sequence of decimal digits (without a suffix), and the type is
deduced as usual for integer constants.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Regarding Long double Constant

2021-02-11 Thread Vincent Lefevre 
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 converted to
long double (and this is why Ayush complained). Still, I don't
see the reason of the change.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Assertion Failed

2021-02-11 Thread Vincent Lefevre 
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: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Regarding Long double Constant

2021-02-11 Thread Vincent Lefevre 
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 variations in the output. The
> problem is solved using (f1-f1) instead of 0.0, it is semantically
> same and produces the same output. For example, Instead of
> ‘if(f2==0.0)’ use ‘if(f2==f1-f1)’
> 
> I have pushed my solution
> 
> and please let me know if you have any queries regarding it.

I don't understand. You just modify the tcc code. So you are just
complaining that the compiler used to compile tcc does not optimize.
The solution would be to fix this compiler.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2021-01-08 Thread Vincent Lefevre 
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 
> > doing it.  So it's a bug in our libc.
> 
> Looks like you'll have to waste 3.7bytes on average per malloc to
> always pad to the 8byte boundary.

Note that it's an 8-byte boundary for 32-bit systems, but a 16-byte
boundary for 64-bit systems:

  https://www.gnu.org/software/libc/manual/html_node/Aligned-Memory-Blocks.html

And about the average waste, this depends on other factors (the
main one may be that the block size is often a multiple of some
power of two).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
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

2021-01-05 Thread Vincent Lefevre 
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 **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.
> > 
> > AFAIK, the status of the sign bit of a NaN is unspecified, except
> > for some particular functions, but not strtod. So I don't see a
> > bug in tcc.
> > 
> > Note: for GCC, there's an inconsistency between your testcase
> > and the result.
> 
> 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.

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.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

___
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

2021-01-03 Thread Vincent Lefevre 
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 = -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.

AFAIK, the status of the sign bit of a NaN is unspecified, except
for some particular functions, but not strtod. So I don't see a
bug in tcc.

Note: for GCC, there's an inconsistency between your testcase
and the result.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-12-13 Thread Vincent Lefevre 
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 it
> the following test input (between --- markers):
> 
> ---
> a/\
> \
> \
> \
> /b
> ---
> 
> which causes the program to hang infinitely. When complied
> with other compilers (e.g. GCC), however, it processes the
> file correctly and terminates.  The source follows:
[...]

No issue with tcc 0.9.27+git20200814.62c30a4a-1 provided by Debian.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-09-12 Thread Vincent Lefevre 
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/55f8963dfab5c543f7f34589d3ef9d3f2da3db14..310e3b428cfd181b51723276e6563b90d670da06:/tccgen.c
> > And because that line is UB, then it causes even more bugs down the drain.
> > At least if the output for this UB matches what other compilers generate
> > some bugs can be eliminated.
> 
> Note that the output of some compilers may depend on the context
> and optimizations. IIRC, there was a bug in PARI with such a
> conversion.

FYI, this was the bug fixed in this commit:

https://pari.math.u-bordeaux.fr/cgi-bin/gitweb.cgi?p=pari.git;a=commit;h=f7de74a4677c9125020fa28c55dcc04b7f85f7f9

(16 years ago). I don't know which compiler was used (probably GCC),
but ia64, alpha, amd64, hppa64 and sparc64 all gave different answers
on some test code.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-09-11 Thread Vincent Lefevre 
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 causes even more bugs down the drain.
> At least if the output for this UB matches what other compilers generate
> some bugs can be eliminated.

Note that the output of some compilers may depend on the context
and optimizations. IIRC, there was a bug in PARI with such a
conversion.

> But what gets me the most is why doesn't gcc or clang compiler warn
> on any of this.

Yes, surprising.

> Also how come we can't represent a 32 bit float in a 64 bit number?
> On x86_64 we sure can.

This depends on the value. With a large exponent, the value will
not be representable.

> Then you are citing ISO 17 while we don't even have full support for
> C11.

I have cited the latest version to mean that this has not changed.
This has been like in previous versions of the standard too.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-09-11 Thread Vincent Lefevre 
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. That's undefined behavior (see ISO C17, 6.3.1.4)
because -123 is not representable in unsigned long int. So, any
behavior is correct.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-09-04 Thread Vincent Lefevre 
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, for the standard headers, this is not required by the C standard.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-07-15 Thread Vincent Lefevre 
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 Christian Jullien).
> 
> Thanks for the report, it was indeed unhandled in the support routines. I
> fixed this in mob for riscv64, but the routines are shared with aarch64 so
> it's likely also fixed there, please check.

Thanks. Everything is fine now.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-07-15 Thread Vincent Lefevre 
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 since a = 0 currently).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-07-15 Thread Vincent Lefevre 
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", d);
  volatile long double x = d;
  printf ("x = %La\n", x);
  printf ("x = %.40Lg\n", x);
  return 0;
}

With GCC (correct):

d = 0x0.88p-1022
d = 1.182070487331950734766686131082839659116e-308
x = 0x1.1p-1023
x = 1.182070487331950734766686131082839659116e-308

With TCC (incorrect):

d = 0x0.88p-1022
d = 1.182070487331950734766686131082839659116e-308
x = 0x1.88p-1023
x = 1.703572172919576058928459424207621861668e-308

I suspect that the code adds the usual implicit bit 1, but there is
no such bit with subnormals.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-07-06 Thread Vincent Lefevre 
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 32-bit word

The issue is that in the GMP test with the new tcc,
$gmp_cv_asm_label_suffix is empty instead of being ":", so that
the generated conftest.s is wrong and fails to assemble.

for gmp_tmp_op in .long .word data4; do
  cat >conftest.s &1
configure:25724: $? = 1
conftest.s:2: error: unknown opcode 'somelabel'
configure: failed program was:
.text
somelabel
conftest.s:2: error: unknown opcode 'somelabel'
trying :
configure:25721: tcc -c   conftest.s >conftest.out 2>&1
configure:25724: $? = 0
configure:25744: result: :

With the new one:

configure:25708: checking for assembler label suffix
trying 
configure:25721: tcc -c   conftest.s >conftest.out 2>&1
configure:25724: $? = 0
configure:25744: result: 

So, the issue is that the program

.text
somelabel

should fail while it doesn't (indeed, it does with gcc and old tcc,
but doesn't with the mod branch).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2020-06-17 Thread Vincent Lefevre 
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 several times (for instance, think of a macro to compute
min(x,y), avoiding a function call when x and y are constants). The
current tcc (8fb8d88 in mob branch) fails to behave correctly, as
shown on the following example.

#include 

#define FOO(X) (__builtin_constant_p (X) ? ((X), (X), (X)) : (X))

int main (void)
{
  int c = 0, i;

  i = FOO ((c++, 7));
  printf ("%d %d\n", c, i);
  return c == 1 && i == 7 ? 0 : 1;
}

With GCC and Clang, I get "1 7" since FOO ((c++, 7)) is replaced
by ((c++, 7)).

But with tcc, I get "3 7".

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Strange bug found?

2020-02-20 Thread Vincent Lefevre 
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 explain why this works in general).

> I found this using the last git commit (btw. git repo is currently not 
> working again) and also in official 0.9.27, both on Windows.
> 
> The output of the follwing short code is:
> 10 = 10 = 9, but of course should be 10 = 10 = 10
> The position of the marked line "double d = 0;" does not change the wrong 
> behaviour as long as it is before "double b[n];" Changing the line to "int i 
> = 0;" leads to correct behaviour.
> 
> #include 
> #define ARRAYSIZE(a) (1[&(a)] - (a))

This is syntactically equivalent to

#define ARRAYSIZE(a) ( *(&(a) + 1) - (a) )

The ISO C standard says in 6.5.3.2p4:

  The unary * operator denotes indirection. If the operand points to
  a function, the result is a function designator; if it points to
  an object, the result is an lvalue designating the object. If the
  operand has type “pointer to type”, the result has type “type”. If
  an invalid value has been assigned to the pointer, the behavior of
  the unary * operator is undefined.

The issue is that &(a) + 1 points to the end of the array, which is
neither a function, nor an object. Even though the * operator will
not read any value here, the conditions of the C standard are not
satisfied.

and this is confirmed by the end of 6.5.6p8 (about the + operator):

  If the result points one past the last element of the array object,
  it shall not be used as the operand of a unary * operator that is
  evaluated.

> void main() {
>   double a[10];
>   size_t n = 10;
>   double d = 0; // <-- no failure if this is removed
>   double b[n];
>   printf("%u = %u = %u\n", ARRAYSIZE(a), n,   ARRAYSIZE(b));

Note that you should cast the 3 values to unsigned int.

> }
> 
> Sincerely,
> Kernel

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] undefined sanitizer

2019-06-23 Thread Vincent Lefevre 
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 give information about the OS, the target architecture (e.g.
with -march=... with GCC), the target architecture for tuning
(e.g. with -mtune=... with GCC), whether some features are enabled
or not[*], the user choices (such as size vs performance), etc.
Then any of these macros can be used with #if.

[*] Some features may have stricter alignment constraints.

> The benefit of a warning is to question the developer about its code
> and possible way to fix it.

Spurious warnings are bad. Let the user/developer decide what he
wants.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] undefined sanitizer

2019-06-23 Thread Vincent Lefevre 
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 aligned (e.g. one where the natural alignment of all types is 1 is
> fully conforming).  Accessing something via an incorrectly aligned pointer
> is undefined, but what incorrectly aligned means is implementation defined.

Yes, but once the "correctly aligned" conditions have been defined
by the implementation, if a condition is not met, this falls under
-fsanitize=undefined.

Note also that the implementation can also decide that some alignment
condition is supported but deserves a warning.

> Probably everyone has already seen this blog post about GCC
> generating code that crashes if pointers to uint32_t are not aligned
> to 4, but I will post the URL just in case:
> 
> http://pzemtsov.github.io/2016/11/06/bug-story-alignment-on-x86.html

This shows again that one should rely on documentation from the
implementation (e.g. implementation-defined things) rather that
one can normally observe when running the code.

Thus -fsanitize=undefined may give warnings even if the generated
code actually works. In particular, optimizations can "break"
expectations by the user, e.g. due to additional alignment
requirement for automatic vectorization or dead-code detection.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] undefined sanitizer

2019-06-23 Thread Vincent Lefevre 
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 incorrect 
> alignment. Suppose I provide a portable C library which will be compiled with 
> on different architectures. As developer, I want what has a high risk to hang 
> on machines I'm not even aware of.

The code may have #ifdef's or similar code to enable misaligned
accesses only when supported. In such a case, a warning would not
be useful, unless explicitly requested.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] undefined sanitizer

2019-06-22 Thread Vincent Lefevre 
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.
> > > 
> > > I don't think we should care about alignment of 4 (when 8 would be 
> > > needed).
> > > The 64bit platforms we support all handle misaligned memory accesses quite
> > > fine, and doing it "correctly" just wastes space.
> > 
> > Even if there are no issues with the processor, undefined behavior
> > may yield the generation of bad code due to optimizations.
> 
> 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 aligned (e.g. one where the natural alignment of all types is 1 is
> fully conforming).  Accessing something via an incorrectly aligned pointer
> is undefined, but what incorrectly aligned means is implementation defined.

Yes, it's implementation defined, but I assume that -fsanitize=undefined
warns only when the implementation has decided that this was incorrectly
aligned.

> Usually that's ultimately dictated by the capabilities of the underlying
> hardware

No, I think that this is a decision from the ABI, which can cover
multiple kinds of hardware (e.g. some processors that can handle
alignment and others that can't). Some compiler options can also
relax requirements. For x86, GCC has -malign-double and -malign-data,
but I don't know how this will have an influence on the expected
requirements (i.e. if it just avoids misaligned accesses for its
generated code or if it also forbids misaligned accesses from how
the C source is written). For instance, the gcc(1) man page says:

   On x86-64, -malign-double is enabled by default.

(this covers "double", "long double" and "long long", but I'm
wondering about other 64-bit types such as pointers, as this
would make sense to have the same rule, IMHO).

> (and not by -fsanitize when it ignores those capabilities!). Our
> hosts support alignment of 4 even for 8byte quantities.
> 
> Now, you do have a point in that some compilers assume larger natural
> alignment (e.g. that a void* has alignment 8), and that there are
> transformations like bit propagation of low bits of addresses, or
> vectorization making use of instructions actually requiring large alignment,
> that might be affected by assumptions about alignment, leading to wrong code
> when those assumptions are violated.

Yes, that's what might happen and may be the reason why
-fsanitize=undefined complains (it may now know whether the
generated code is actually broken or not, but the UB is a
sufficient condition under which the code may be broken).

> When that actually happens we can revisit, until then I personally
> prefer the space savings.

I'm wondering whether some compiler option (see above) could ensure
that misaligned accesses will not trigger any problem. In this case,
such an option could be recommended to build tcc.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2019-06-22 Thread Vincent Lefevre 
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
> > > equivalent? Especially the changes in parse_escape_string look
> > > as if that's possible. (I consider such type change only better
> > > than casts, if the former doesn't cause further casts elsewhere,
> > > of course).
> > 
> > Changing signed integers to unsigned just to avoid casts for
> > printf-like functions is a bad idea. The reason is that in
> > some expressions, using unsigned types can silently modify
> > the value of a signed type when implicitly converted to
> > unsigned.
> 
> Sure.  Which is why I said "if [changing the type] ... is equivalent".  If
> it causes above issues it isn't equivalent.

Yes, but it can be equivalent now, but the unsigned version could
trigger bug later, when new code is added.

In general, I now tend to use signed integers for integers on which
standard integer arithmetic will be done (even when the value will
always be non-negative), except when the range is not sufficient
and the unsigned version would be sufficient (for instance, an
unsigned int can represent the sum of two non-negative int), but
these are quite particular cases. And I use unsigned integers when
they are intended for bitwise operations or modular arithmetic.

Even if I use printf with %x, this has no effect on the above
decision.

-- 
Vincent Lefèvre  - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] undefined sanitizer

2019-06-22 Thread Vincent Lefevre 
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 64bit platforms we support all handle misaligned memory accesses quite
> fine, and doing it "correctly" just wastes space.

Even if there are no issues with the processor, undefined behavior
may yield the generation of bad code due to optimizations.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2019-06-22 Thread Vincent Lefevre 
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 equivalent? Especially
> the changes in parse_escape_string look as if that's possible.
> (I consider such type change only better than casts, if the former doesn't
> cause further casts elsewhere, of course).

Changing signed integers to unsigned just to avoid casts for
printf-like functions is a bad idea. The reason is that in
some expressions, using unsigned types can silently modify
the value of a signed type when implicitly converted to
unsigned. This is very ugly. FYI, we had bugs like that in
GNU MPFR, and that's why we changed the precision type to
a signed integer type, even though its value is always
positive.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2019-06-21 Thread Vincent Lefevre 
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 build with clang already. Seems to work
> on Windows, too (not a windows user myself). Not to mention the code
> quality of clang/llvm vs gcc :)

Every compiler has its own benefits. That's why tcc still exists
in particular. :)

One thing GCC supports but not Clang is nested functions:

  https://bugs.llvm.org/show_bug.cgi?id=6378

FYI, this is used by GNU MPFR for (optional) logging support, and
there seems to be no way to do that in standard C.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2019-06-21 Thread Vincent Lefevre 
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 can just mean that your code will silently
be compiled in an unexpected way.

[...]
> int i = 256;
> 
> const char* s = "Hello";
> 
> const void* p = s;
> 
>  
> 
> printf("%x\n", i);
> 
> printf("%u %s\n", i, p);
[...]

> Only -Wformat (or -Wall) shows a warning on the 2nd printf, printf
> of i (a signed) is always Ok.

I don't think this is correct for i as int and unsigned int are not
compatible types... even though 256 has the same representation as
int and unsigned int (I think that the C standard should have been
more flexible in such a case).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2019-03-14 Thread Vincent Lefevre 
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 software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles
Updating goal targets
 File 'test' does not exist.
   File 'clean-s' does not exist.
  Must remake target 'clean-s'.
   File 'hello-exe' does not exist.
  Must remake target 'hello-exe'.
   File 'hello-run' does not exist.
  Must remake target 'hello-run'.
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 software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
 hello-exe 
../tcc -B.. -I../include -I.. -I.. ../examples/ex1.c -o hello && ./hello || 
(set -x; ../tcc -vv; ldd ../tcc; exit 1)
Updating makefiles
Updating goal targets
 File 'clean' does not exist.
Must remake target 'clean'.
Hello World
   File 'libtest' does not exist.
  Must remake target 'libtest'.
 hello-run 
../tcc -B.. -I../include -I.. -I.. -run ../examples/ex1.c || (set -x; ../tcc 
-vv; ldd ../tcc; exit 1)
Hello World
   File 'test3' does not exist.
 File 'test.ref' does not exist.
Must remake target 'test.ref'.
 libtest 
./libtcc_test -B.. -I../include -I.. -I..
make: ./libtcc_test: Command not found
make: *** [Makefile:74: libtest] Error 127
make: *** Waiting for unfinished jobs
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 software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles
Updating goal targets
 File 'clean' does not exist.
Must remake target 'clean'.
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 software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Reading makefiles...
Updating makefiles
Updating goal targets
 File 'clean' does not exist.
Must remake target 'clean'.

The reason was

all test : clean-s $(TESTS)

This makes no sense to clean and run the tests at the same time.
I've changed that to

all test :
$(MAKE) clean-s
$(MAKE) $(TESTS)

in order to clean *before* running the tests.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] tcc coding style question

2019-01-24 Thread Vincent Lefevre 
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/functions which are touched for "proper" reasons.

Actually this is not only style. There are technical issues with them.
Spaces at the end of a line can be lost, and tabs are automatically
converted to spaces in some contexts. Thus avoiding tabs and trailing
spaces makes patches more robust (e.g. if they appear on the web).
Moreover, tabs make diffs less readable.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] tcc coding style question

2019-01-24 Thread Vincent Lefevre 
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èvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2017-12-24 Thread Vincent Lefevre 
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 like musl's fallback definition (if not gcc) for NAN
> > in a constant, but tcc is fine with musl's INFINITY definition.
> 
> I think we could make an exception for 0.0/0.0 and always fold this into NaN
> (normally division by zero is indeed not allowable in constant expressions
> in c99).

AFAIK, the standard just implies that 0.0/0.0 is not specified as a
constant expression. But the standard also says: "An implementation
may accept other forms of constant expressions."

Moreover, if Annex F is supported, then FP division by zero is
well-defined. F7.4.2 gives examples with 0.0/0.0 in initializers,
such as:

  static float x = 0.0/0.0; // does not raise an exception

Nowadays, supporting Annex F is more or less a must.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] c89

2017-09-27 Thread Vincent Lefevre 
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.  Use --std=c89 under gcc-4.9.2 on x86_64
> > The result builds and passes self-tests.
> 
> I went through the tcc compile with --std=c89 -pedantic and
> --std=c99 -pedantic options.
[...]

Note that --std=c89 -pedantic(-errors) is not sufficient to detect all
use of non-C89 features (only those that require a diagnostic). In
particular, using  remains undetected by --std=c89 -pedantic
with the current GCC. And even in C99, the types int64_t and uint64_t
are optional (in case they are also used for bootstrapping).

BTW, in practice, compiler bugs may be more an issue than the
possible use of a C89 compiler.

So, about the use of old (and new) compilers, perhaps it could be
better to report issues when they are found.

You might want to try CompCert[*], which supports only a subset of C
(a very large subset of C89 + some C99 features, AFAIK).

[*] http://compcert.inria.fr/

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Annoying new warning

2017-05-05 Thread Vincent Lefevre 
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 sense on the ARM,
> > and issues would be detected at compile time) or have something like
> > an assert to abort if this function is called.
> 
> Let tcc insert a library function that will abort peoples' programs
> to me clearly sounds like a second to best solution. ;)

It should never be called on ARM, thus should never abort peoples'
programs. That's still better than generating broken code, which
could have security implications.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Annoying new warning

2017-05-05 Thread Vincent Lefevre 
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 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 sense on the ARM,
and issues would be detected at compile time) or have something like
an assert to abort if this function is called.

> Hopefully this email will not suffer the same problem.  Vincent: what mail
> client are you using?

Mutt. I choose to display the text/plain part by default (thus not
needing an HTML parser, with potential security issues).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Annoying new warning

2017-05-05 Thread Vincent Lefevre 
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% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Annoying new warning

2017-05-05 Thread Vincent Lefevre 
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/lib/libtcc1.c
> +++ b/lib/libtcc1.c
> @@ -577,6 +577,10 @@ unsigned long long __fixunsdfdi (double a1)
> 
>  unsigned long long __fixunsxfdi (long double a1)
>  {
> +#if defined(TCC_TARGET_ARM)
> +//(void)fprintf(stderr, "__fixunsxfdi(%g) called for TCC_TARGET_ARM\n",
> a1);
> +return 0;

Why should the result be 0 on ARM?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Annoying new warning

2017-05-03 Thread Vincent Lefevre 
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 uninitialized"
> 
> +W_OPTIONS="pointer-sign sign-compare unused-result"
> 
> Yeah, it helped.  Thanks for the all the hard work, after all ;)

IMHO, -Wuninitialized is very useful (as opposed to
-Wmaybe-uninitialized, which may give false positives).

> PS: As already suggested it appears that the function can simply
> be #ifdef'd out, for ARM that is.

The #ifdef may be the best solution as potential issues would be
detected at compile time. Alternatively, you can add an assert on
the sizes. This should make the -Wuninitialized warning disappear
(otherwise this would be a bug in GCC; if GCC isn't smart enough,
it should emit the warning only for -Wmaybe-uninitialized).

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Annoying new warning

2017-05-02 Thread Vincent Lefevre 
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 consequence
to hide real warnings (i.e. real bugs).

One solution would be to use the preprocessor to avoid defining
this function on platforms it cannot be called. This will also
have the advantage to generate (slightly) smaller code, and also
to make sure that the function will not be used when it mustn't.

> Note this warning is rather recent, like few weeks ago.

According to git blame, this is very old code (2002-07). Are you
sure this isn't due to a more recent version of your GCC compiler?
New warnings are regularly added in GCC.

Or this may be due to:

diff --git a/lib/libtcc1.c b/lib/libtcc1.c
index 0edfbd8..9195489 100644
--- a/lib/libtcc1.c
+++ b/lib/libtcc1.c
@@ -693,7 +693,7 @@ void *__va_arg(__va_list_struct *ap,
 }
 #endif /* __x86_64__ */
 
-#ifdef TCC_TARGET_ARM
+#if defined TCC_TARGET_ARM && !defined __TINYC__
 #define _GNU_SOURCE
 #include 
 #include 

on 2017-02-23.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Ready for Release 0.9.27

2017-02-09 Thread Vincent Lefevre 
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
> > >   
> > >   [...]
> > >   
> > >   If an int can represent all values of the original type (as
> > >   restricted by the width, for a bit-field), the value is converted
> > >   to an int; otherwise, it is converted to an unsigned int. These are
> > >   called the integer promotions.58) All other types are unchanged by
> > >   the integer promotions.
> > > 
> > > In my example of my Debian bug report:
> > >   struct { unsigned int a:3; } s = { 1 };
> > >   
> > >   s.a - 2
> > > 
> > > The original type (a 3-bit unsigned bit-field) contains the values
> > > from 0 to 7. An int can represent all of them. Thus s.a is converted
> > > to an int, and s.a - 2 gives -1 (as an int).
> > > 
> > > But according to the test, tcc seems to regard s.a - 2 as
> > > (unsigned int) (-1), i.e. UINT_MAX. However, tcc behaves correctly
> > > on ((unsigned char) 1 - 2), giving -1.
> > > 
> > > Note that GCC 6.3.0, ICC 15.0.0 and Clang 3.9.1 are correct on this
> > > test.
> > 
> > But note that MSVC still behaves like tcc, and that such behavior

MSVC is a C++ compiler. The rules with old C++ standards might be
different (possibly not intentionally). It seems to be confirmed
by <http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1260.htm>:

  For C++, other integral and enumeration types are allowed for
  bit-fields; it is explicit that bit-fields do not have special types
  ([class.bit], "The bit-field attribute is not part of the type of
  the class member.").

> > can be seen compliant to the standard too, at least before the rather
> > recent addition of the
> > 
> > ... (as restricted by the width, for a bit-field) ...
> > 
> > phrase, with the result that now basically every possible ':X' field-width
> > is supposed to define its own integral C type.
> 
> Indeed, this parenthesis is not prosent in C99. Without this it reads as if 
> the original type is the base type of the bitfield. Since tcc aims at C99 
> conformance I agree with grischka this is a "won't fix".

No, this is not really a change of the standard, but a clarification.
See: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_315.htm

  Last sentence of paragraph 2 of 6.3.1.1, add the words as restricted
  by the width, for a bit-field as follows:

If an int can represent all values of the original type (as
restricted by the width, for a bit-field), the type is converted
to an int;

This has been done for C11.

Note that according to C99, a bit-field is a type ("unsigned int" here
is just a type specifier). Just like an array is not the same type of
the type of its elements. See 6.7.2.1p9 in C99:

  A bit-field is interpreted as a signed or unsigned integer type
  consisting of the specified number of bits.107) [...]

  107) As specified in 6.7.2 above, if the actual type specifier
   used is int or a typedef-name defined as int, then it is
   implementation-defined whether the bit-field is signed or
   unsigned.

When interpreting the standard, it is important to consider the
*whole* standard, not just individual sentences, which may be
ambiguous.

FYI, GCC 6 behaves in the same way with -std=c89, -std=c99 and -std=c11.
Ditto for Clang 3.9.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Ready for Release 0.9.27

2017-02-09 Thread Vincent Lefevre 
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 checked carefully) but don't wait for me.

The C standard says:

  6.3.1.1 Boolean, characters, and integers

  [...]

  If an int can represent all values of the original type (as
  restricted by the width, for a bit-field), the value is converted
  to an int; otherwise, it is converted to an unsigned int. These are
  called the integer promotions.58) All other types are unchanged by
  the integer promotions.

In my example of my Debian bug report:

  struct { unsigned int a:3; } s = { 1 };

  s.a - 2

The original type (a 3-bit unsigned bit-field) contains the values
from 0 to 7. An int can represent all of them. Thus s.a is converted
to an int, and s.a - 2 gives -1 (as an int).

But according to the test, tcc seems to regard s.a - 2 as
(unsigned int) (-1), i.e. UINT_MAX. However, tcc behaves correctly
on ((unsigned char) 1 - 2), giving -1.

Note that GCC 6.3.0, ICC 15.0.0 and Clang 3.9.1 are correct on this
test.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-10-18 Thread Vincent Lefevre 
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/IHI0042F_aapcs.pdf
> section 7.1.7. But I don't know if we adhere to those rules when
> compiling for ARM.

"For the purposes of calculating the alignment of the aggregate the
type of the member shall be the Fundamental Data Type upon which the
bit-field is based.[1]

[1] The intent is to permit the C construct struct {int a:8; char b[7];}
to have size 8 and alignment 4."

Assuming that there are similar requirements for other architectures,
the behavior of GCC now makes sense to me.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-10-18 Thread Vincent Lefevre 
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 are correct.

> To me,
> struct t2 {
> uint32_t op_type:1;
> uint8_t op_flags;
> };
> 
> op_type uses a plain uint32_t to store only one bit as there is
> another field which is not a bit bitfield, C compile must allocate
> at least one extra byte in this struct. The minimal size I expect
> is 5!

I disagree. For the bit-field, a size 1 is sufficient for 1 bit.
So, the minimum size of the structure I would expect is 2 in all
of the 3 examples. Actually, even though the standard does not
require this, I would have expected the same size for all of these
3 examples, as this would have been more consistent, unless the
type of the bit-field is regarded as a hint for alignment choices.

> I changed you sample a little bit to see offset of op_flags:
> 
> #include 
> #include 
> #include 
> struct t1 {
> uint8_t op_type:1;
> uint8_t op_flags;
> };
> struct t2 {
> uint32_t op_type:1;
> uint8_t op_flags;
> };
> struct t3 {
> unsigned op_type:1;
> char op_flags;
> };
> 
> int main() {
> printf("t1 struct size: %ld\n", sizeof(struct t1));
> printf("t2 struct size: %ld\n", sizeof(struct t2));
> printf("t2 offset of op_flags: %ld\n", offsetof(struct t2, op_flags));
> printf("t3 struct size: %ld\n", sizeof(struct t3));
> return 0;
> }
> 
> Visual C++ gives:
> t1 struct size: 2
> t2 struct size: 8
> t2 offset of op_flags: 4
> t3 struct size: 8
> 
> While gcc gives
> c:\tmp>a.exe
> t1 struct size: 2
> t2 struct size: 4
> t2 offset of op_flags: 1
> t3 struct size: 4
> 
> Which IMHO is wrong. If later I change my mind with:
> struct t2 {
> uint32_t op_type:1;
> uint32_t op_other_field: 12;
> uint8_t op_flags;
> };

I see GCC's choice as OK. If you change your mind, the structure
changes and the offset of op_flags may change. I don't see anything
wrong here.

> I expect my struct will have the same size.

Different users have different expectations. For instance, I would
have expected the same size for the initial 3 examples. But as long
as the standard doesn't specify anything, the entire choices are
left to the implementation.

> I don't think we want tcc mimic this behavior. Doing this will break
> Windows code that depends on this behavior. The only solution is to
> add a compiler flag to ask for a specific behavior.

There are at least 2 things that should be specified: how offsets are
determined (i.e. how the unit sizes are determined), and how alignment
(which affects the size of the structure) is determined.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-07-05 Thread Vincent Lefevre 
-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,/home/vlefevre/software/mpfr/src/.libs -Wl,-rpath -Wl,/tmp/lib

but then I get failures:

$ ./ty1
./ty1: symbol lookup error: ./ty1: undefined symbol: mpfr_free_cache2

$ ldd ty1 | grep mpfr
libmpfr.so => /usr/lib/x86_64-linux-gnu/libmpfr.so (0x7f3a575ce000)

while without --prefix=/tmp, everything is fine, as tcc links against
the correct MPFR library:

$ ldd ty1 | grep mpfr
libmpfr.so => /home/vlefevre/software/mpfr/src/.libs/libmpfr.so 
(0x7f6f3cc03000)

So, it seems that above, the first -Wl,-rpath is ignored.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Tinycc-devel] incorrect bit-field behavior

2016-06-06 Thread Vincent Lefevre 
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
{
  unsigned long manl:32;
  unsigned long manh:20;
  unsigned long exp:11;
  unsigned long sig:1;
} s;
  double d;
};

int main (void)
{
  union ui xi;
  union ul xl;

  xi.d = 0.5;
  xl.d = 0.5;

  printf ("%d %lx\n", xi.s.exp - 1023 < 0, (unsigned long) (xi.s.exp - 1023));
  printf ("%d %lx\n", xl.s.exp - 1023 < 0, (unsigned long) (xl.s.exp - 1023));
  return 0;
}

With GCC and ICC, I get:

1 
1 

But with tcc, I get:

0 
0 

Since all the values of xi.s.exp and xl.s.exp are representable
in an int, the bit-field type should be converted to int for the
subtraction, so that the < 0 should be true in both cases.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-05-05 Thread Vincent Lefevre 
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 particular, on
invalid C, one should get diagnostics.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-04-28 Thread Vincent Lefevre 
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 look at the C99 standard right now, but I'd be
> surprised if there weren't a recommendation on this.

The recommendation is:

  Implementations should avoid imposing fixed translation limits
  whenever possible.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-04-27 Thread Vincent Lefevre 
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 this is fixed in CompCert 2.5, as the authors now agree that
the previous interpretation was wrong.

> But tcc with first patch outputs 0x10 0x1d (as user expects)

This may be the most intuitive behavior, but not conforming to the
ISO C standard. 0x1e-E is a preprocessing token (Clause 6.4.8), more
precisely a pp-number, and "each preprocessing token is converted
into a token" (Clause 5.1.1.2). Since the token is invalid, one gets
an error. Initially, CompCert didn't take Clause 5.1.1.2 into account
here: the pp-number 0x1e-E was further parsed (*after* preprocessing)
into 3 tokens 0x1e, - and E; hence the result 0x1e.

One may find the rules for pp-number awkward, but they have been
designed on purpose. According to the C rationale:

  The notion of preprocessing numbers was introduced to simplify the
  description of preprocessing. It provides a means of talking about
  the tokenization of strings that look like numbers, or initial
  substrings of numbers, prior to their semantic interpretation. In
  the interests of keeping the description simple, occasional spurious
  forms are scanned as preprocessing numbers. For example, 0x123E+1 is
  a single token under the rules. The C89 Committee felt that it was
  better to tolerate such anomalies than burden the preprocessor with
  a more exact, and exacting, lexical specification. It felt that this
  anomaly was no worse than the principle under which the characters
  a+b are tokenized as a ++ ++ + b (an invalid expression), even
  though the tokenization a ++ + ++ b would yield a syntactically
  correct expression. In both cases, exercise of reasonable precaution
  in coding style avoids surprises.

and it is also important that things like 1m be seen as a single
preprocessing token (thus a pp-number) so that the following code
yields an identifier:

  #define mkident(s) s ## 1m
  int mkident(int) = 0;

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-04-27 Thread Vincent Lefevre 
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 interpretation of
the C standard. An error is better than unexpected results due to the
choice done by pcc and CompCert. Here's an example:

#include 

int main(void)
{
  int E = 0;
#define E 1
  printf ("0x%x 0x%x\n", 0x11-E, 0x1e-E);
  return 0;
}

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. But this is not
what one gets (E yields 1 in 0x11-E, but 0 in 0x1e-E).

> If icc/gcc/clang. complain, then this is theire problem. eE is valid
> exp char only for decimal notation. And for hexadeciamal notation it
> is an ordinal digit char.

No, this is not what the C standard says. Transformations are described
in terms of tokentization.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-04-27 Thread Vincent Lefevre 
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 after macro expansion w/o syntax analize?

It seems that gcc adds a space only when the result would otherwise
a different pp-tokenization.

Another example, based on one from Section 6.4 of the ISO C standard:

#define P ++

int main(void)
{
  int a = 0, b = -1;
  return a P+P b;
}

"gcc -E" gives:

int main(void)
{
  int a = 0, b = -1;
  return a +++ ++ b;
}

while "tcc -E" incorrectly gives:

int main(void)
{
  int a = 0, b = -1;
  return a + b;
}

because + would be parsed as ++ ++ +.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-04-27 Thread Vincent Lefevre 
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 after macro expansion w/o syntax analize?

No syntax analysis is needed. This is just related to tokenization,
AFAIK.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-04-27 Thread Vincent Lefevre 
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 *format, ...);
> #define ACPI_TYPE_INVALID 0x1E
> #define NUM_NS_TYPES ACPI_TYPE_INVALID+1
> int array[NUM_NS_TYPES];
> #define n 0xe
> int main() {
> printf("n+1 = %d\n", n+1);
> }
> 
> prints 15
> And preprocessor output is
> ...
> printf("n+1 = %d\n", 0x1e+1);.

I'm not sure I understand. This preprocessor output is obviously
incorrect as it cannot be taken as input to a compiler. There
should be a space between 0x1e and +1 (see for instance, the
output of "gcc -E", "clang -E" and "icc -E").

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

2016-01-12 Thread Vincent Lefevre 
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
> > 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.

Implicit declarations dated back from K C, where prototypes were
not checked. Old code is not guaranteed to work with new compilers
anyway and may have security issues (which wasn't a problem in the
past). Rejecting implicit declarations would be safer in practice.
For compiling old code (which is still rather rare compared to the
usual use of compilers), a special option could be added, which the
user could choose if he doesn't want to clean up the code.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

2016-01-12 Thread Vincent Lefevre 
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 is undefined." Seeing as the old compiler was
> unable to check that condition (it involves comparing types between
> translation units), what are the chances of the programmer having got
> it right in all cases?

This is the problem of the programmer. There are good chances that
this will not work (except in particular cases, such as between char,
signed char and unsigned char), though the programmer and/or the user
may not see the problem immediately. But this is also a good reason
to require prototypes: this will help programmers to detect bugs.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

2016-01-11 Thread Vincent Lefevre 
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 seems to be a change in C99,
because the code is not rejected with -ansi -pedantic-errors.

By default, gcc doesn't reject the code, but emits a warning, which
is better than nothing. Well, tcc emits a warning too.

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.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

2016-01-10 Thread Vincent Lefevre 
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 declared?

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

2016-01-10 Thread Vincent Lefevre 
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:
> > > #include 
> 
> Vincent Lefevre <vinc...@vinc17.net> 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(...);

But I don't think that an implementation is disallowed to reject the
code. As I read the standard, the library functions are specified only
when the corresponding header is included. So, if the header is not
included, the implementation could complain that it doesn't know the
function.

Moreover, if the function types are not compatible like here, the
behavior is undefined. That's another reason...

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2016-01-09 Thread Vincent Lefevre 
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 the issue on both Fedora 21 and
> Fedora 22.
> 
> Here is the relevant output from make test off a fresh clone and build:
> 
> dcali-fedora (mob[release_0_9_26-611]=) ~/git/tinycc
> $ make test
> make: Warning: File 'config.mak' has modification time 0.031 s in the future
> make -C tests test 'PROGS_CROSS=i386-tcc i386-win-tcc x86_64-win-tcc
> arm-linux-fpa-tcc arm-linux-fpa-ld-tcc arm-linux-gnu-tcc
> arm-linux-gnueabi-tcc arm64-tcc c67-tcc arm-win-mingw32ce-tcc'
> make[1]: Entering directory '/home/dylan.cali/git/tinycc/tests'
> make[1]: Warning: File '../config.mak' has modification time 0.029 s
> in the future
>  hello-exe 
> ../tcc -B.. -I.. -I.. -I../include -L.. ../examples/ex1.c -o hello ||
> (../tcc -vv; exit 1) && ./hello
> Hello World
>  hello-run 
> ../tcc -B.. -I.. -I.. -I../include -L.. -run ../examples/ex1.c
> Makefile:94: recipe for target 'hello-run' failed
> make[1]: *** [hello-run] Segmentation fault
> make[1]: Leaving directory '/home/dylan.cali/git/tinycc/tests'
> Makefile:377: recipe for target 'test' failed
> make: *** [test] Error 2

This problem was due to new psABI relocation but should have been
fixed for x86_64 on 2015-12-17. At least the latest mob branch works
on my machines. Just in case, make sure that the following appears
in "git log":

commit f15c0a93336ef42cec51d00667b5fd60fb309cd5
Author: Michael Matz 
Date:   2015-12-17 19:41:20 +0100

x86-64: fix shared libs

The introduction of read32le everywhere created a subtle issue, going
from
   x = *(int*)p;
to
   x = read32le(p);
is not equivalent if x is a larger than 32bit quantity, like an
address on x86_64, because read32le returns an unsigned int.  The first
sign extends, the latter zero extends.  This broke shared library
creation for gawk.  It's enough to amend the case of the above
situation, cases like "write32le(p, read32le(p) +- something)" are okay,
no extensions happen or matter.

commit e264243adc0910fba204fd05292a8353e272bd0e
Author: Michael Matz 
Date:   2015-12-17 07:30:35 +0100

x86-64: Define symbol constant for new relocs

Whoops, we have our own  copy, so I can just as well add
the symbol defines for the relocs instead of hard-coding numbers
in tccelf.c.

commit c4d0498b3ae3483fa7726500bd03e1f411289fff
Author: Michael Matz 
Date:   2015-12-17 07:17:34 +0100

x86-64: Add support for new psABI relocations

R_X86_64_GOTPCRELX and R_X86_64_REX_GOTPCRELX can occur in object files
comiled by new binutils.  They are not dynamic relocations, so normally
wouldn't be a problem for tcc (one doesn't normally mix object files
created by different compiler/binutils, static archives are so out :)).
If it weren't for the glibc startup code, crt*.o, of course.  They now
do contain such relocs --> boom.  Handle them in the trivial way.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2015-12-24 Thread Vincent Lefevre 
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~git20140923.9d7fb33-3 Debian package) and mob. I wonder
> > > whether this is a bug in tcc or in the glibc.
> > 
> > According to Aurelien Jarno, this is actually due to new binutils
> > relocations (and the Debian glibc 2.21-4 package is built with a recent
> > binutils, hence the problem with it).
> > 
> > Details:
> > 
> >  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808008#22
> 
> Blaeh.  I didn't consider the case of the libc runtime startup .o files when
> agreeing to the new relocs.  Arguably those object files exposed to every
> linker trying to create user-space programs shouldn't use the new relocs
> (they provide a very minor performance benefit sometimes) even with new
> binutils (and so that's a QoI issue in glibc), but it's easy enough to deal
> with them in tcc.
> 
> Try newest mob again.

Works well. Thanks.

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2015-12-15 Thread Vincent Lefevre 
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% tcc conftest.c -o conftest
ypig% ./conftest
zsh: segmentation fault (core dumped)  ./conftest

In the "objdump -S" output of conftest, I notice the following
difference:

libc6 2.19:

00400430 <_init>:
  400430:   48 83 ec 08 sub$0x8,%rsp
  400434:   48 8b 05 4d 01 20 00mov0x20014d(%rip),%rax# 
600588 <_init+0x200158>
[...]

libc6 2.21:

004003f0 <_init>:
  4003f0:   48 83 ec 08 sub$0x8,%rsp
  4003f4:   48 8b 05 00 00 00 00mov0x0(%rip),%rax# 4003fb 
<_init+0xb>

The 0x20014d(%rip) has changed to 0x0(%rip).

My bug report for Debian:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808008

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2015-12-15 Thread Vincent Lefevre 
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 the
> glibc.

According to Aurelien Jarno, this is actually due to new binutils
relocations (and the Debian glibc 2.21-4 package is built with a
recent binutils, hence the problem with it).

Details:

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808008#22

-- 
Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/>
100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/>
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

[Tinycc-devel] parallel make failed

2015-12-15 Thread Vincent Lefevre 
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-deprecated-declarations -Wno-strict-aliasing 
-Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -Wno-uninitialized 
-fno-strict-aliasing -fPIC -DTCC_TARGET_X86_64
make[1]: ../tcc: Command not found
Makefile:116: recipe for target 'x86_64/libtcc1.o' failed
make[1]: *** [x86_64/libtcc1.o] Error 127
make[1]: Leaving directory '/home/vlefevre/software/tinycc/lib'
Makefile:259: recipe for target 'libtcc1.a' failed
make: *** [libtcc1.a] Error 2
make: *** Waiting for unfinished jobs
ln -sf x86_64-tcc tcc

I've just done a commit to solve this problem.
But please, check on various platforms.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2015-07-29 Thread Vincent Lefevre 
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 validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

Re: [Tinycc-devel] Source vandalism

2015-07-29 Thread Vincent Lefevre 
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 case, fix your editor settings.
 
 In some of the cases, it's obvious that whoever wrote the code was
 using 4 spaces per tab, but in others it's obvious they were using 8.
 It was kind of hard to determine which, and I had to second-guess
 about the surrounding code.

Anyway, tabs are incorrect: with tabs, various tools break
indentation, such as diff (thus patches may be difficult
to read) and git blame.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2015-05-22 Thread Vincent Lefevre 
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? Why exe produced
 by gcc use ./src/.libs/libmpfr.so and exe produced by tcc use one
 installed on the system?

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

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2015-05-22 Thread Vincent Lefevre 
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 a patch for libtool:

  http://lists.gnu.org/archive/html/libtool-patches/2015-05/msg0.html

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2015-05-21 Thread Vincent Lefevre 
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 like:

  libtool: link: tcc -O2 -o tzeta_ui tzeta_ui.o  -L../src/.libs 
./.libs/libfrtests.a -lm ../src/.libs/libmpfr.so -lgmp

The problem is that the MPFR library used at run time is not
../src/.libs/libmpfr.so but the one installed on the system.

-- 
Vincent Lefèvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

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

2015-03-06 Thread Vincent Lefevre 
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èvre vinc...@vinc17.net - Web: https://www.vinc17.net/
100% accessible validated (X)HTML - Blog: https://www.vinc17.net/blog/
Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)

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

  1   2   >