[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] -Wl,-rpath not passed through?

2016-06-06 Thread Steffen Nurpmeso
Michael Matz  wrote:
 |On Mon, 6 Jun 2016, Steffen Nurpmeso wrote:

 |I think this leaks memory when opath contains a string already.  pbuf is 

Indeed, pbuf comes from copy_linker_arg(), i sublimely overlooked
it, but indeed see now.  I'm sorry.


--steffen
commit 2a28638 (HEAD -> refs/heads/i)
Author: Steffen (Daode) Nurpmeso 
AuthorDate: 2016-06-04 15:48:15 +0200
Commit: Steffen (Daode) Nurpmeso 
CommitDate: 2016-06-06 21:50:26 +0200

Allow multiple -rpath linker arguments
---
 libtcc.c | 25 -
 1 file changed, 24 insertions(+), 1 deletion(-)

diff --git a/libtcc.c b/libtcc.c
index 12ee171..dd1789c 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1834,6 +1834,29 @@ static char *copy_linker_arg(const char *p)
 return pstrncpy(tcc_malloc(q - p + 1), p, q - p);
 }
 
+static char *concat_linker_arg_path(char *opath, const char *p)
+{
+size_t plen, ol;
+char *npath, *pbuf;
+
+pbuf = copy_linker_arg(p);
+
+if (opath != NULL) {
+ol = strlen(opath);
+plen = strlen(pbuf) +1;
+npath = tcc_malloc(ol + 1 + plen);
+
+memcpy(npath, opath, ol);
+tcc_free(opath);
+
+npath[ol++] = ':';
+memcpy([ol], pbuf, plen);
+tcc_free(pbuf);
+} else
+npath = pbuf;
+return npath;
+}
+
 /* set linker options */
 static int tcc_set_linker(TCCState *s, const char *option)
 {
@@ -1880,7 +1903,7 @@ static int tcc_set_linker(TCCState *s, const char *option)
 } else if (link_option(option, "O", )) {
 ignoring = 1;
 } else if (link_option(option, "rpath=", )) {
-s->rpath = copy_linker_arg(p);
+s->rpath = concat_linker_arg_path(s->rpath, p);
 } else if (link_option(option, "section-alignment=", )) {
 s->section_align = strtoul(p, , 16);
 } else if (link_option(option, "soname=", )) {
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] -Wl,-rpath not passed through?

2016-06-06 Thread Michael Matz
Hi,

On Mon, 6 Jun 2016, Steffen Nurpmeso wrote:

> Bäh!
> Take this one, please, the other one deleted an option.
> Ciao!

I think this leaks memory when opath contains a string already.  pbuf is 
allocated memory, you free the opath, copy pbuf into npath, but then leak 
pbuf itself (it's not leaked when opath is NULL, then it's freed in the 
next call as opath).  valgrind should find it.  Fix that and push to mob 
I'd say.


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


Re: [Tinycc-devel] -Wl,-rpath not passed through?

2016-06-06 Thread Steffen Nurpmeso
Bäh!
Take this one, please, the other one deleted an option.
Ciao!

--steffen
commit 2b59c82 (HEAD -> refs/heads/i)
Author: Steffen (Daode) Nurpmeso 
AuthorDate: 2016-06-04 15:48:15 +0200
Commit: Steffen (Daode) Nurpmeso 
CommitDate: 2016-06-06 13:59:30 +0200

Allow multiple -rpath linker arguments
---
 libtcc.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/libtcc.c b/libtcc.c
index 12ee171..07a3fad 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1834,6 +1834,28 @@ static char *copy_linker_arg(const char *p)
 return pstrncpy(tcc_malloc(q - p + 1), p, q - p);
 }
 
+static char *concat_linker_arg_path(char *opath, const char *p)
+{
+size_t plen, ol;
+char *npath, *pbuf;
+
+pbuf = copy_linker_arg(p);
+
+if (opath != NULL) {
+ol = strlen(opath);
+plen = strlen(pbuf) +1;
+npath = tcc_malloc(ol + 1 + plen);
+
+memcpy(npath, opath, ol);
+tcc_free(opath);
+
+npath[ol++] = ':';
+memcpy([ol], pbuf, plen);
+} else
+npath = pbuf;
+return npath;
+}
+
 /* set linker options */
 static int tcc_set_linker(TCCState *s, const char *option)
 {
@@ -1880,7 +1902,7 @@ static int tcc_set_linker(TCCState *s, const char *option)
 } else if (link_option(option, "O", )) {
 ignoring = 1;
 } else if (link_option(option, "rpath=", )) {
-s->rpath = copy_linker_arg(p);
+s->rpath = concat_linker_arg_path(s->rpath, p);
 } else if (link_option(option, "section-alignment=", )) {
 s->section_align = strtoul(p, , 16);
 } else if (link_option(option, "soname=", )) {
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] -Wl,-rpath not passed through?

2016-06-06 Thread Steffen Nurpmeso
Sorry, forgot the diff:

--steffen
commit db263ba (HEAD -> refs/heads/i)
Author: Steffen (Daode) Nurpmeso 
AuthorDate: 2016-06-04 15:48:15 +0200
Commit: Steffen (Daode) Nurpmeso 
CommitDate: 2016-06-06 13:37:03 +0200

Allow multiple -rpath linker arguments
---
 libtcc.c | 26 +++---
 1 file changed, 23 insertions(+), 3 deletions(-)

diff --git a/libtcc.c b/libtcc.c
index 12ee171..ed9662d 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1834,6 +1834,28 @@ static char *copy_linker_arg(const char *p)
 return pstrncpy(tcc_malloc(q - p + 1), p, q - p);
 }
 
+static char *concat_linker_arg_path(char *opath, const char *p)
+{
+size_t plen, ol;
+char *npath, *pbuf;
+
+pbuf = copy_linker_arg(p);
+
+if (opath != NULL) {
+ol = strlen(opath);
+plen = strlen(pbuf) +1;
+npath = tcc_malloc(ol + 1 + plen);
+
+memcpy(npath, opath, ol);
+tcc_free(opath);
+
+npath[ol++] = ':';
+memcpy([ol], pbuf, plen);
+} else
+npath = pbuf;
+return npath;
+}
+
 /* set linker options */
 static int tcc_set_linker(TCCState *s, const char *option)
 {
@@ -1880,9 +1902,7 @@ static int tcc_set_linker(TCCState *s, const char *option)
 } else if (link_option(option, "O", )) {
 ignoring = 1;
 } else if (link_option(option, "rpath=", )) {
-s->rpath = copy_linker_arg(p);
-} else if (link_option(option, "section-alignment=", )) {
-s->section_align = strtoul(p, , 16);
+s->rpath = concat_linker_arg_path(s->rpath, p);
 } else if (link_option(option, "soname=", )) {
 s->soname = copy_linker_arg(p);
 #ifdef TCC_TARGET_PE
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel


Re: [Tinycc-devel] realpath(x, NULL) doesn't work with tcc(1)

2016-06-06 Thread Steffen Nurpmeso
Good morning! :)

Michael Matz  wrote:
 |On Thu, 2 Jun 2016, Steffen Nurpmeso wrote:
 |> Well, have i yet asked this?  I think no...
 |> It's like that for a long time, ever since i use tcc(1) (autumn
 |> last year):
 |>
 |>  ?0[steffen@wales tmp]$ cat t.c
 |>  #include 
 |>  int main(void){
 |> char *x = realpath(".", NULL);
 |>
 |> return (x != NULL) ? 0 : 1;
 |>}
 |>  ?0[steffen@wales tmp]$ for i in clang gcc tcc; do \
 |>$i -o zt t.c && ./zt; echo $i: $?;\
 |>  done
 |>  clang: 0
 |>  gcc: 0
 |>  tcc: 1
 |>
 |> tcc(1) only gets realpath(3) with buffer argument right, i wonder
 |> what that can be?
 |
 |Wow.  You've run into the result of an unimplemented feature of tcc, which 
 |I never thought would matter in practice ;-)  I'll explain, bear with me: 

 |accepting NULL as second argument.  But glibc also has a strict no change 
 |in interfaces policy, and this was a visible change, so symbol versioning 
 |had to be used to provide the old behaviour for old applications (those 

 |"when it supports symbol versions" is of course the crucial part: tcc as 
 |ELF linker doesn't.  So it leaves in an unversioned reference to 
 |'realpath' in the executable and so the dynamic linker is free to choose 
 |any.  Now the usual ld.so uses a (normally) sensible heuristic for 
 |choosing which one when there are several: for references from dlsym it 
 |uses the newest available one, for references from applications that have 
 |no symbol version information whatsoever it uses the oldest symbol 
 |version, on the grounds that apps without any symversion info must have 
 |been created before the ELF implementation provided them, i.e. they must 
 |be very very old applications.
 |
 |This reasoning breaks down with an incomplete link editor like tcc.  It 
 |creates new applications that are regarded as very old by ld.so.  So, what 
 |you see is ld.so resolving to the old implementation of realpath, instead 
 |of the current one.

Thanks for your time and the whole picture!  Hm, symbol versioning
didn't really enter my world yet -- i know in FreeBSD you now even
find linker scripts what should be some "beefy library", well.
Terribly non-understandable choices regarding dlsym(3)/normal
link!  But now i see, this is the reason for dlvsym(3), a-ha.
I never tried, but i assume it doesn't take a POSIX/xy version
string (and what should that really be).  Please excuse that i'm
too lazy to find and look through the source code.

 |Short of implementing proper ELF symbol versioning in tcc there's only an 
 |ugly work-around: you could use a different link editor.  Perhaps there's 
 |somewhen a rainy weekend when the former can be done.

I'm even a little bit hooked to look somewhat deeper into ELF,
i have the standards laying around for a lng time:

  ?0[steffen@wales ]$ ll ~/arena/docs.coding/elf-*
  .. 525024 18 Apr  2012 /home/steffen/arena/docs.coding/elf-v1.2.pdf
  .. 630410  8 May  2012 /home/steffen/arena/docs.coding/elf-tls-abi.pdf

That is unbelievable four years; maybe in the summer; would
actually be nice to have it in tcc(1), too, since it is so much
faster than clang/gcc!

Ciao,

--steffen

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


Re: [Tinycc-devel] -Wl,-rpath not passed through?

2016-06-06 Thread Steffen Nurpmeso
Hello.

David Mertens  wrote:
 |Also, I am not sure what others think about the first line in which y\
 |ou declare two integers and initialize them with the return values of\
 | function 
 |calls. I guess that's fine, but I don't see it often in the codebase.\
 | @Everyone, do we have a coding standard about this?

The attached diff generalizes via a new function that could be
reused.  I hope this is a bit better!
Ciao,

--steffen

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