Michael Matz | 18 Sep 17:46 2014
Picon

Re: Fallout from commit 01c041923474750a236da02561f0f8835445848b

Hi,

On Tue, 9 Sep 2014, Thomas Preud'homme wrote:

> 1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT 
> relocations but the computation you added ignore the possible addend at 
> *ptr by doing a simple assignment. Is that normal? Did I miss something?

This is per the ABI.  The addend for both relocations (when using REL 
form) is (and must be) always zero.  I didn't bother checking for this, 
but rather just ignored anything that was in there.

> 2) When creating a GOT and PLT entry for a R_ARM_PC24, R_ARM_CALL or 
> R_ARM_JUMP24 you add the offset of the PLT entry to the place being relocated. 
> I'm not sure I got it right but it seems to me that the relocation will be 
> processed again in relocate_section and seems the symbol referenced is still 
> the target function (and not the PLT entry created) as the index in the r_info 
> field of the relocation has remained unchanged. Also this put some relocation 
> computation in build_got_entries. Why not change the initial relocation to 
> make it resolve to the PLT entry.

It might be that I got some of the logic wrong, though I obviously did 
check tcc on arm with itself (and IIRC gawk).  I'll need to reproduce the 
problem somewhen.  Are you positive that it was my commit that broke it?  
Hmm, or it might be that I also hit an error but somehow convinced myself 
that it was a pre-existing but possibly hidden problem.  Man, it's long 
ago :)

> 3) I don't see any test for the type of output when deciding what type of 
> relocation to add. So even when the output is in memory reloc_type will be 
(Continue reading)

Thomas Preud'homme | 18 Sep 16:37 2014
Picon

Re: sizeof (long double) vs sizeof (double)

Le dimanche 07 septembre 2014, 13:47:39 Mads a écrit :
> So basically, I should be able to get additional 2 bytes? And I suppose it
> will be stored as 12 bytes to maintain data structure alignment?

LDOUBLE_SIZE is defined to be 16 so you should have 16 bytes for long double 
(twice that of double).

> 
> Reading through the code as well as changelogs, x87 is indeed implemented,
> which means I should be able to use long double with higher precision than
> double.
> Correct me if I'm wrong, but shouldn't long double precision be like that
> declared in floats.h (see below __i386__ / __x86_64__ ).
> 
> (sorry for the hassle, but long double as extended precision is a necessary
> evil for me).
> 
> *From include\floats.h*
> /* horrible intel long double */
> #if defined __i386__ || defined __x86_64__
> 
> #define LDBL_MANT_DIG 64
> #define LDBL_DIG 18
> #define LDBL_EPSILON 1.08420217248550443401e-19L
> #define LDBL_MIN_EXP (-16381)
> #define LDBL_MIN 3.36210314311209350626e-4932L
> #define LDBL_MIN_10_EXP (-4931)
> #define LDBL_MAX_EXP 16384
> #define LDBL_MAX 1.18973149535723176502e+4932L
> #define LDBL_MAX_10_EXP 4932
(Continue reading)

Vadim Ushakov | 12 Sep 11:50 2014
Picon

[patch] tcc reports wrong file name for static inline functions

Hello!

tcc reports wrong file name when an error occurs in a static inline function,
if that function is the last in a file. Here is an example:

test.c:
> #include "test.h"
> int test(void)
> {
>     return foo();
> }

test.h:
> static inline int foo(void)
> {
>     wrong_type_t t = 0;
>     return t + 1;
> }

result:
> $ tcc -o test test.c
> test.c:3: error: 'wrong_type_t' undeclared

tcc says it is test.c, however the error is in test.h.

The bug seems to be in decl0(). When it sees a static inline declaration,
it _first_ reads the function body and _then_ saves the body and the file
name in tcc_state->inline_fns.

If the function is the last declaration, the parser pops the file from the
(Continue reading)

Simon Blomberg | 10 Sep 09:48 2014
Picon

Make tries to install cross compilers

Yesterday i tried to build tcc with:
$ ./configure --prefix=../pref --cc=tcc

everything worked fine until i issued
$ make install
and it tried to install the cross compilers which weren't built:
...
install -m755 tcc x86_64-tcc i386-win32-tcc x86_64-win32-tcc arm-fpa-tcc arm-fpa-ld-tcc arm-vfp-tcc arm-eabi-tcc  "../pref/bin"
install: cannot stat ‘x86_64-tcc’: No such file or directory
install: cannot stat ‘i386-win32-tcc’: No such file or directory
install: cannot stat ‘x86_64-win32-tcc’: No such file or directory
install: cannot stat ‘arm-fpa-tcc’: No such file or directory
install: cannot stat ‘arm-fpa-ld-tcc’: No such file or directory
install: cannot stat ‘arm-vfp-tcc’: No such file or directory
install: cannot stat ‘arm-eabi-tcc’: No such file or directory
make: *** [install] Error 1

i looked through the Makfile and found this part:

ifeq ($(CC),tcc)
    $(INSTALL) -m755 $(PROGS) $(PROGS_CROSS_LINK) "$(bindir)"
else

When i removed $(PROGS_CROSS_LINK) the installation worked fine.
i don't know it this is a bug or if there is something strange with my setup
but i thought i'd mention it here anyways.

Simon Blomberg
<div><div dir="ltr">
<div>
<div>
<div>Yesterday i tried to build tcc with:<br>$ ./configure --prefix=../pref --cc=tcc<br>
</div>
<br>everything worked fine until i issued <br>
</div>$ make install <br>
</div>and it tried to install the cross compilers which weren't built:<br><div>
<div>
<div>...<br>install -m755 tcc x86_64-tcc i386-win32-tcc x86_64-win32-tcc arm-fpa-tcc arm-fpa-ld-tcc arm-vfp-tcc arm-eabi-tcc&nbsp; "../pref/bin"<br>install: cannot stat &lsquo;x86_64-tcc&rsquo;: No such file or directory<br>install: cannot stat &lsquo;i386-win32-tcc&rsquo;: No such file or directory<br>install: cannot stat &lsquo;x86_64-win32-tcc&rsquo;: No such file or directory<br>install: cannot stat &lsquo;arm-fpa-tcc&rsquo;: No such file or directory<br>install: cannot stat &lsquo;arm-fpa-ld-tcc&rsquo;: No such file or directory<br>install: cannot stat &lsquo;arm-vfp-tcc&rsquo;: No such file or directory<br>install: cannot stat &lsquo;arm-eabi-tcc&rsquo;: No such file or directory<br>make: *** [install] Error 1<br><br>
</div>
<div>i looked through the Makfile and found this part:<br><br>ifeq ($(CC),tcc)<br>&nbsp;&nbsp;&nbsp; $(INSTALL) -m755 $(PROGS) $(PROGS_CROSS_LINK) "$(bindir)"<br>else<br><br>
</div>
<div>When i removed $(PROGS_CROSS_LINK) the installation worked fine.<br><div>i don't know it this is a bug or if there is something strange with my setup<br>
</div>
<div>but i thought i'd mention it here anyways.<br>
</div>
<div><br></div>
</div>
</div>
<div><div>Simon Blomberg<br>
</div></div>
</div>
</div></div>
Thomas Preud'homme | 9 Sep 16:17 2014
Picon

Fallout from commit 01c041923474750a236da02561f0f8835445848b

Hi Michael,

A recent upload of tcc in Debian showed a self test failure [1] due to a 
failed R_ARM_PC24 relocation. The two bits with the smallest weight are 0 so 
it's a problem of out of range branch.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=tcc&arch=armhf&ver=0.9.27%7Egit20140907.87d879a-1&stamp=1410110433

The biggest change in this code was your commits to get rid of 
runtime_plt_and_got so I took a closer look at it. A few things surprised me 
so I wanted to ask you some questions.

1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT relocations 
but the computation you added ignore the possible addend at *ptr by doing a 
simple assignment. Is that normal? Did I miss something?

2) When creating a GOT and PLT entry for a R_ARM_PC24, R_ARM_CALL or 
R_ARM_JUMP24 you add the offset of the PLT entry to the place being relocated. 
I'm not sure I got it right but it seems to me that the relocation will be 
processed again in relocate_section and seems the symbol referenced is still 
the target function (and not the PLT entry created) as the index in the r_info 
field of the relocation has remained unchanged. Also this put some relocation 
computation in build_got_entries. Why not change the initial relocation to 
make it resolve to the PLT entry.

3) I don't see any test for the type of output when deciding what type of 
relocation to add. So even when the output is in memory reloc_type will be 
JUMP_SLOT which will lead to a PLT entry being created. This seems to 
contradict the comment near the end of put_got_entry. The comment seems wrong 
as I don't see how a branch could be relocated without a PLT entry.

4) the jump table that was removed in subsequent patch was only available when 
outputing to memory. But now a PLT and GOT entry is created no matter what 
type of output (see 3) above).

Best regards,

Thomas
Hi Michael,

A recent upload of tcc in Debian showed a self test failure [1] due to a 
failed R_ARM_PC24 relocation. The two bits with the smallest weight are 0 so 
it's a problem of out of range branch.

[1] 
https://buildd.debian.org/status/fetch.php?pkg=tcc&arch=armhf&ver=0.9.27%7Egit20140907.87d879a-1&stamp=1410110433

The biggest change in this code was your commits to get rid of 
runtime_plt_and_got so I took a closer look at it. A few things surprised me 
so I wanted to ask you some questions.

1) You added the support for R_ARM_GLOB_DAT and R_ARM_JUMP_SLOT relocations 
but the computation you added ignore the possible addend at *ptr by doing a 
simple assignment. Is that normal? Did I miss something?

2) When creating a GOT and PLT entry for a R_ARM_PC24, R_ARM_CALL or 
R_ARM_JUMP24 you add the offset of the PLT entry to the place being relocated. 
I'm not sure I got it right but it seems to me that the relocation will be 
processed again in relocate_section and seems the symbol referenced is still 
the target function (and not the PLT entry created) as the index in the r_info 
field of the relocation has remained unchanged. Also this put some relocation 
computation in build_got_entries. Why not change the initial relocation to 
make it resolve to the PLT entry.

3) I don't see any test for the type of output when deciding what type of 
relocation to add. So even when the output is in memory reloc_type will be 
JUMP_SLOT which will lead to a PLT entry being created. This seems to 
contradict the comment near the end of put_got_entry. The comment seems wrong 
as I don't see how a branch could be relocated without a PLT entry.

4) the jump table that was removed in subsequent patch was only available when 
outputing to memory. But now a PLT and GOT entry is created no matter what 
type of output (see 3) above).

Best regards,

Thomas
raphael.londeix | 9 Sep 15:12 2014
Picon

APPARTEMENT DISPONIBLE

Hello !

Je libère mon appartement le 1er octobre, si vous êtes interessé,
contactez moi en privé, sinon diffusez !

loyer 970E + 145E de charges

45 m2 au 1er étage du 3 rue eugene Jumin (19e).

3 pieces (ideal coloc) avec cuisine séparée, salle de bain avec baignoire, toilettes séparées.

1 min du métro, 3 min du parc de la Villette, 10 min du parc des buttes chaumont.


Contactez moi au 06 31 39 22 98

Bisous !

Raphael Londeix

<div>
<p>Hello !</p>
<p>

</p>
<p>Je lib&egrave;re mon appartement le 1er octobre, si vous &ecirc;tes interess&eacute;,
<br>contactez moi en priv&eacute;, sinon diffusez !</p>

<p>loyer 970E + 145E de charges</p>
<p>45 m2 au 1er &eacute;tage du 3 rue eugene Jumin (19e).</p>
<p>3 pieces (ideal coloc) avec cuisine s&eacute;par&eacute;e, salle de bain avec baignoire, toilettes s&eacute;par&eacute;es.</p>
<p>1 min du m&eacute;tro, 3 min du parc de la Villette, 10 min du parc des buttes chaumont.</p>

<br><p>Contactez moi au 06 31 39 22 98</p>

<p>Bisous !</p>

<p>Raphael Londeix</p>
</div>
Mads | 6 Sep 16:38 2014
Picon

sizeof (long double) vs sizeof (double)

I wish to use extended precision in functions compiled by tcc during execution.
Unfortunately, it appears that for any functions compiled by tcc, sizeof (double) == sizeof (long double)  - and I haven't got the slightest clue whether it's intended, if it's a bug or if I'm missing some flags.

Specifications:
tcc (latest version 2014-08-01 http://repo.or.cz/w/tinycc.git/shortlog ) compiled with msys mingw (using command: ./configure [--prefix installpath])
Test code ( http://pastebin.com/yiSDFfYU ) is compiled with gcc (codeblocks, 64bit, windows 7).

tcc-compiled code:
char my_program[] =
"int GetLongDoubleSize(int n)\n"
"{\n"
"    return sizeof(long double);\n" //returns 8
"}\n"
"int GetDoubleSize(int n)\n"
"{\n"
"    return sizeof(double);\n" //returns 8
"}\n";

Output:
----- tcc compiled 'char program':
Long Double size: 8
Double size: 8
----- gcc compiled functions:
gcc Long Double size: 12
gcc Double size: 8

<div><div dir="ltr">
<div>I wish to use extended precision in functions compiled by tcc during execution.</div>
<div>Unfortunately, it appears that for any functions compiled by tcc, sizeof (double) == sizeof (long double) &nbsp;- and I haven't got the slightest clue whether it's intended, if it's a bug or if I'm missing some flags.</div>
<div><br></div>
<div>Specifications:</div>
<div>tcc (latest version 2014-08-01 <a href="http://repo.or.cz/w/tinycc.git/shortlog">http://repo.or.cz/w/tinycc.git/shortlog</a> ) compiled with msys mingw (using command: ./configure [--prefix installpath])</div>
<div>Test code ( <a href="http://pastebin.com/yiSDFfYU">http://pastebin.com/yiSDFfYU</a> ) is compiled with gcc (codeblocks, 64bit, windows 7).</div>
<div><br></div>
<div>tcc-compiled code:</div>
<div>
<div>char my_program[] =</div>
<div>"int GetLongDoubleSize(int n)\n"</div>
<div>"{\n"</div>
<div>" &nbsp; &nbsp;return sizeof(long double);\n" //returns 8</div>
<div>"}\n"</div>
<div>"int GetDoubleSize(int n)\n"</div>
<div>"{\n"</div>
<div>" &nbsp; &nbsp;return sizeof(double);\n" //returns 8</div>
<div>"}\n";</div>
</div>
<div><br></div>
<div>Output:<br><div>----- tcc compiled 'char program':</div>
<div>Long Double size: 8</div>
<div>Double size: 8</div>
<div>----- gcc compiled functions:</div>
<div>gcc Long Double size: 12</div>
<div>gcc Double size: 8</div>
<div><br></div>
</div>
</div></div>
jiang | 21 Aug 18:52 2014

Re: tcc grammar problems

Sorry, I made ​​a mistake, there are some questions I have not clear.

Jiang

在 2014年08月22日 00:00, tinycc-devel-request <at> nongnu.org 写道:
> unsigned int xi = 0;

_______________________________________________
Tinycc-devel mailing list
Tinycc-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
jiang | 21 Aug 17:55 2014

回复: tcc grammar problems

I recently some busy I may have to next week to give you write a letter. more than me some time, because I found
tcc other bug. the following statement can not compile:
unsigned int xi = 0;
Error: too many basic types.

Best regards,
jiang

Thomas Preud'homme <robotux <at> celest.fr>编写:

>Le mardi 19 août 2014, 21:28:52 Thomas Preud'homme a écrit :
>> 
>> Ok, I'll take a look at this one later this week.
>
>Sorry, I wanted to do it today but it's already too late. Maybe this WE 
>otherwise next week.
>
>Best regards,
>
>Thomas
_______________________________________________
Tinycc-devel mailing list
Tinycc-devel <at> nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Mohamed Rezgui | 21 Aug 08:04 2014
Picon

Problem to compile with visual studio 2010 project

Dear Sir,

I have an issue,
I cannot compile with visual studio 2010 project generated by CMakeList
with the last revision on git repository

=> LINK : fatal error LNK1104: cannot open file 'Debug\tcc.lib'

Can you help me please ?

--

-- 
Best Regards,
Mohamed REZGUI

YX Hao | 12 Aug 17:42 2014

Win: Advise a "spliting the crt source files" thing

Hi grischka,

As you say before:
"I'd agree with separate code, but not with separate sources."
I think there is reason.

Here as the title I have a new discovery.
Useless functions are also added when linking the executable file.

You can complie my attached file, and then take a look at the disassemble 
codes using a debugger. To the "wincrt1.c", it is the same:
"_runwinmain" for "-run" mode is linked in an exe output file, and 
"_winstart" could be in the memery of "-run" mode. It will be the same 
situation to an Unicode version.

I have made a patch and confirmed that.
As TCC does NOT do an optimization, we do for it, although the reduce of 
useless codes could not be many. :p

Attach my previous standalone version of the whole files, just for your 
convenient to confirm that.

What do you think? Hope hearing from you.

Regards,
YX 
Attachment (view_useless_code.c): application/octet-stream, 304 bytes
Attachment (wincrt1.c): application/octet-stream, 1168 bytes
Attachment (wincrt1_w.c): application/octet-stream, 1259 bytes
Attachment (wincrt0.c): application/octet-stream, 592 bytes
Attachment (wincrt0_w.c): application/octet-stream, 690 bytes
Hi grischka,

As you say before:
"I'd agree with separate code, but not with separate sources."
I think there is reason.

Here as the title I have a new discovery.
Useless functions are also added when linking the executable file.

You can complie my attached file, and then take a look at the disassemble 
codes using a debugger. To the "wincrt1.c", it is the same:
"_runwinmain" for "-run" mode is linked in an exe output file, and 
"_winstart" could be in the memery of "-run" mode. It will be the same 
situation to an Unicode version.

I have made a patch and confirmed that.
As TCC does NOT do an optimization, we do for it, although the reduce of 
useless codes could not be many. :p

Attach my previous standalone version of the whole files, just for your 
convenient to confirm that.

What do you think? Hope hearing from you.

Regards,
YX 

Gmane