Re: [Tinycc-devel] Call for testing
Le samedi 26 janvier 2013 07:09:11, Feng Nauh a écrit : tinycc/tests: on archlinux x86_64, make weaktest, result as: ... tcctest.c:391:5: note: use option -std=c99 or -std=gnu99 to compile your code make: *** [weaktest] Error 1 I think the weaktest is not included in the default tests precisely because it's broken. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Works fine on the BeagleBone as long as configured with --with-libgcc. I ran the make test many times, no Segmentation faults. Omitting --with-libgcc and building still result in this, however: Test: 11_precedence... tcc: error: undefined symbol '__aeabi_idiv' But I am very happy with the way the new release candidate works on both the Pi and the Bone. Clearly the Segmentation faults are fixed. Thanks to all for your great work on this. Regards, Jerry On Wed, Jan 30, 2013 at 10:59 AM, Thomas Preud'homme robo...@celest.frwrote: Le samedi 26 janvier 2013 07:09:11, Feng Nauh a écrit : tinycc/tests: on archlinux x86_64, make weaktest, result as: ... tcctest.c:391:5: note: use option -std=c99 or -std=gnu99 to compile your code make: *** [weaktest] Error 1 I think the weaktest is not included in the default tests precisely because it's broken. Best regards, Thomas ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel -- Interested in bats? Check out my blog at: http://www.karaokebats.com/ ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas, Le jeudi 24 janvier 2013 11:35:30, Thomas Preud'homme a écrit : I finally got around to look in this last failure. I just started but the good news is that it's limited to the -run function. There is no problem when compiling the example. Objdump shows it's the exact same code in both case. So it's probably a relocation bug. Ok got it. Fix attached. I'm not sure about the comments though, as I don't have all the details in my mind. Let me explain a bit what's going on and you might have idea about the details. Worked for me. Thank you for the fix! $ git pull ... From git://repo.or.cz/tinycc e92dbe4..de35a33 mob- origin/mob Updating e92dbe4..de35a33 ... $ gcc --version gcc (Gentoo 4.6.3 p1.9, pie-0.5.2) 4.6.3 Copyright (C) 2011 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ ./configure --prefix=/usr/local/ make clean all test (all tests passed) $ su # make install # exit $ CC=/usr/local/bin/tcc LD=/usr/local/bin/tcc ./configure \ --prefix=/usr/local/ $ make clean all test CC=/usr/local/bin/tcc LD=/usr/local/bin/tcc (all tests passed) $ su # make install # exit $ CC=/usr/local/bin/tcc LD=/usr/local/bin/tcc ./configure \ --prefix=/usr/local/ $ make clean all test CC=/usr/local/bin/tcc LD=/usr/local/bin/tcc (all tests passed) Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le jeudi 24 janvier 2013 11:35:30, Thomas Preud'homme a écrit :
I finally got around to look in this last failure. I just started but the
good news is that it's limited to the -run function. There is no problem
when compiling the example. Objdump shows it's the exact same code in both
case. So it's probably a relocation bug.
Ok got it. Fix attached. I'm not sure about the comments though, as I don't
have all the details in my mind. Let me explain a bit what's going on and you
might have idea about the details.
The segfault happens when calling a function whose symbol is resolved by
calling a function first (symbol is of type STT_GNU_IFUNC) and that you resolve
the symbol later via a call to dlsym. In the case of the 28_strings test, tcc
was calling strcpy and then while doing -run, it performed a dlsym for the
first symbol it encountered in 28_strings.c: strcpy.
The problem is that tcc, when linking, was copying the type for functions
symbol (STT_FUNC and STT_GNU_IFUNC) in the resulting executable.
I'm not sure about the details but what happens is that the first call to
strcpy will save call the dynamic resolver which will call the function to
decide which version of strcpy to use (like strcpy_sse2 or strcpy__ssse3) and
then the resulting address was stored somewhere (I always forget the details
about where is the results stored, is it just in the GOT of the executable?).
Then, the dlsym would take the address stored and do the relocation again.
Except that this time the adress points to one of the implementation of strcpy
(strcpy_ssse3 on my computer) which would get executed to get the final
address. So strcpy would be executed with whatever happens to be in the
registers at the time of calling dlsym. Setting the symbol as STT_FUNC in the
executable would mean that the dlsym would get the address of the resolving
function which would return the address of the right variant of strcpy.
So, all I can say is that using STT_FUNC instead of STT_GNU_IFUNC in the
*executable* only affects the normal call, which would store the address of the
resolving strcpy function instead of the strcpy variant directly.
If someone can throw some light to where are things stored or suggest me a
comment, I'd be very happy.
Best regards,
Thomas
diff --git a/tccelf.c b/tccelf.c
index da81d03..76a8002 100644
--- a/tccelf.c
+++ b/tccelf.c
@@ -1633,7 +1633,7 @@ static int elf_output_file(TCCState *s1, const char *filename)
type = ELFW(ST_TYPE)(esym-st_info);
if ((type == STT_FUNC) || (type == STT_GNU_IFUNC)) {
put_got_entry(s1, R_JMP_SLOT, esym-st_size,
- ELFW(ST_INFO)(STB_GLOBAL,type),
+ ELFW(ST_INFO)(STB_GLOBAL,STT_FUNC),
sym - (ElfW(Sym) *)symtab_section-data);
} else if (type == STT_OBJECT) {
unsigned long offset;
signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le vendredi 25 janvier 2013 18:53:28, Thomas Preud'homme a écrit : The problem is that tcc, when linking, was copying the type for functions symbol (STT_FUNC and STT_GNU_IFUNC) in the resulting executable. I think I got how it works. The dynamic resolver works in 2 steps. First it search for the symbol value and then if it's a symbol of STT_GNU_IFUNC type, it'll call the resulting symbol to get the final symbol value. This is what happens on the first call when it find the definition in the glibc. The second, via dlsym, will see get the value from the executable itself since it has already been resolved. The dynamic resolver will then not call the function as part of the resolution since the symbol is marked STT_FUNC in the executable. I shall now be able to find a nice comment but let me know if I'm wrong. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas Preud'homme wrote: I just started but the good news is that it's limited to the -run function. There is no problem when compiling the example. Ok got it. Fix attached. diff --git a/tccelf.c b/tccelf.c index da81d03..76a8002 100644 --- a/tccelf.c +++ b/tccelf.c @@ -1633,7 +1633,7 @@ static int elf_output_file(TCCState *s1, const char *filename) Without knowing any details, I just notice that the proposed fix doesn't match the analysis of the problem: A change within elf_output_file() has no effect for tcc -run. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le vendredi 25 janvier 2013 19:37:38, grischka a écrit : Thomas Preud'homme wrote: I just started but the good news is that it's limited to the -run function. There is no problem when compiling the example. Ok got it. Fix attached. diff --git a/tccelf.c b/tccelf.c index da81d03..76a8002 100644 --- a/tccelf.c +++ b/tccelf.c @@ -1633,7 +1633,7 @@ static int elf_output_file(TCCState *s1, const char *filename) Without knowing any details, I just notice that the proposed fix doesn't match the analysis of the problem: A change within elf_output_file() has no effect for tcc -run. That's because the bug is not in tcc -run but manifest here. The bug is when compiling a program with a call to ifunc function followed by dlsym with the same function (ex strcpy() followed by (dlsym(RTLD_DEFAULT, strcpy)). Here the bug manifested in tcc -run because tcc was compiled with tcc. Since the code doing the relocation in -run was using dlsym and the input program contained a strcpy, it was trying to dlsym strcpy which was already executed by tcc itself. Exactly the same pattern. So there is no bug in tcc -run functions, only a bug in the linker. :) --- grischka Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
tinycc/tests: on archlinux x86_64, make weaktest, result as: ... tcctest.c:391:5: note: use option -std=c99 or -std=gnu99 to compile your code make: *** [weaktest] Error 1 add -std=gnu99 to CFLAGS, result as: cp ../include/tcclib.h . gcc -o tcctest.gcc tcctest.c -I. -I. -I/root/shared/tinycc -w -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -m64 -DTCC_TARGET_X86_64-std=gnu99 -O0 -fno-omit-frame-pointer ./tcctest.gcc test.ref ../tcc -B.. -DTCC_TARGET_X86_64-c tcctest.c -o weaktest.tcc.o -I. -I/root/shared/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -m64 gcc -c tcctest.c -o weaktest.gcc.o -I. -I. -I/root/shared/tinycc -w -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -m64 -std=gnu99 objdump -t weaktest.tcc.o | grep ' w ' | sed -e 's/.* \([a-zA-Z0-9_]*\)$/\1/' | LC_ALL=C sort weaktest.tcc.o.txt objdump -t weaktest.gcc.o | grep ' w ' | sed -e 's/.* \([a-zA-Z0-9_]*\)$/\1/' | LC_ALL=C sort weaktest.gcc.o.txt diff weaktest.gcc.o.txt weaktest.tcc.o.txt echo Weak Auto Test OK 18d17 weak_toolate make: *** [weaktest] Error 1 on win32(mingw), make weaktest, as: ../tcc -B.. -DTCC_TARGET_I386 -DTCC_TARGET_PE -I /e/shared/tinycc/win32/incl ude -L -c tcctest.c -o weaktest.tcc.o -I. -I/e/shared/tinycc -Wall -g -O2 -fno-s trict-aliasing -Wno-pointer-sign -Wno-sign-compare -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 tcctest.c:1933: warning: implicit declaration of function 'putchar' tcctest.c:2087: warning: implicit declaration of function 'strlen' tcc: error: undefined symbol 'strtof' tcc: error: undefined symbol 'strtold' tcc: error: undefined symbol 'weak_f1' tcc: error: undefined symbol 'weak_v1' tcc: error: undefined symbol 'weak_fpa' tcc: error: undefined symbol 'weak_fpb' tcc: error: undefined symbol 'weak_fpc' tcc: error: undefined symbol 'weak_asm_f1x' tcc: error: undefined symbol 'weak_asm_f2x' tcc: error: undefined symbol 'weak_asm_f3x' tcc: error: undefined symbol 'weak_asm_v1x' tcc: error: undefined symbol 'weak_asm_v2x' tcc: error: undefined symbol 'weak_asm_v3x' make: *** [weaktest] Error 1 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas, I finally got around to look in this last failure. I just started but the good news is that it's limited to the -run function. There is no problem when compiling the example. Objdump shows it's the exact same code in both case. So it's probably a relocation bug. Thanks again for all your tests. As you saw, you helped fixing many bugs. You're welcome! Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Domingo Alvarez Duarte wrote: Please someone here that administer this project can open a free account for opensource projects on http://scan.coverity.com/ and submit tinycc build to verify for defects, I did with my account and I've got this: There is much more details available about this problems on the account pages, if someone want to see then tell me and I can add a new user to see then on my account. Is there a way to let everyone participate? If so I'd suggest to just post the details here. Thanks, --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
I didn't found a way to get a report like the one bellow using clang-build make CC=/usr/share/clang/scan-build/ccc-analyzer. Here we have another set of problems and anyone can install clang and run it. tinycc-dad-git - scan-build resultsUser:mingo@mingo-Aspire-5315 Working Directory:/home/mingo/dev/tinycc-dad-git Command Line:make CC=/usr/share/clang/scan-build/ccc-analyzer Date:Fri Jan 18 19:57:11 2013 Bug SummaryBug TypeQuantityDisplay? All Bugs31 API Argument with 'nonnull' attribute passed null1 Dead code Idempotent operation6 Dead store Dead assignment5 Logic error Assigned value is garbage or undefined2 Dereference of null pointer14 Division by zero1 Result of operation is garbage or undefined2 ReportsBug GroupBug Type ▾FileLinePath Length APIArgument with 'nonnull' attribute passed nulltcc.c367 22View ReportReport BugOpen File Logic errorAssigned value is garbage or undefinedtccgen.c 334711View ReportReport BugOpen File Logic errorAssigned value is garbage or undefinedi386-asm.c 92158View ReportReport BugOpen File Dead storeDead assignmenttccgen.c1571View Report Report BugOpen File Dead storeDead assignmenti386-asm.c13081View Report Report BugOpen File Dead storeDead assignmenttccgen.c12671View Report Report BugOpen File Dead storeDead assignmenti386-asm.c8621View Report Report BugOpen File Dead storeDead assignmenti386-gen.c7871View Report Report BugOpen File Logic errorDereference of null pointertccpp.c276434View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c466727 View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c485136 View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c385369 View ReportReport BugOpen File Logic errorDereference of null pointertcc.c42922View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c48108View ReportReport BugOpen File Logic errorDereference of null pointertccpp.c275033View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c583357 View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c48347View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c454015 View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c464326 View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c552311 View ReportReport BugOpen File Logic errorDereference of null pointertccgen.c454717 View ReportReport BugOpen File Logic errorDereference of null pointertccpp.c31178View ReportReport BugOpen File Logic errorDivision by zerotccasm.c15311View Report Report BugOpen File Dead codeIdempotent operationi386-asm.c5075View ReportReport BugOpen File Dead codeIdempotent operationi386-asm.c3575View ReportReport BugOpen File Dead codeIdempotent operationi386-gen.c6261View ReportReport BugOpen File Dead codeIdempotent operationi386-asm.c3617View ReportReport BugOpen File Dead codeIdempotent operationi386-gen.c6954View ReportReport BugOpen File Dead codeIdempotent operationi386-asm.c3596View ReportReport BugOpen File Logic errorResult of operation is garbage or undefinedi386-asm.c 87757View ReportReport BugOpen File Logic errorResult of operation is garbage or undefinedi386-asm.c 81448View ReportReport BugOpen File On Fri, Jan 18, 2013 at 6:33 PM, grischka gris...@gmx.de wrote: Domingo Alvarez Duarte wrote: Please someone here that administer this project can open a free account for opensource projects on http://scan.coverity.com/ and submit tinycc build to verify for defects, I did with my account and I've got this: There is much more details available about this problems on the account pages, if someone want to see then tell me and I can add a new user to see then on my account. Is there a way to let everyone participate? If so I'd suggest to just post the details here. Thanks, --- grischka __**_ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/**mailman/listinfo/tinycc-develhttps://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le jeudi 17 janvier 2013 01:48:01, Michael Matz a écrit : Hi, Pointer to integer conversions (and back) are implementation defined, the only requirement being that if the integer type is (u)intptr_t that a pointer converted to that one and back to a pointer shall compare equal to the original pointer. So, depending on how the compiler implements this conversion (and documents this) one might get different results: $ gcc -o long_long long_long.c ./long_long [SNIP gcc warnings] -66 -66 -66 -66 -66 -66 This is a correct result for ILP32 (i.e. 32bit code). GCC sign extends pointers when the pointer representation needs fewer bits than the target type. $ clang -o long_long long_long.c ./long_long -66 -66 -66 -66 4294967230 4294967230 And this is also a correct result for 32bit code, when the compiler defines pointer to integer conversion to be zero-extending when the target type has more bits than a pointer. IMO sign-extending is more useful, and as GCC set the precedent a long time ago I would declare clang to at least have an QoI issue with compatibility with GCC. In other words: tcc has no bug here. Thanks a lot for your explaination Michael. There is also the p -= 0x7042; assignment which is compiler-specific for C11 (not sure for C99) I think because nothing in the standard say there should be overflow. The compiler can do crazy things with it, as explained in http://lwn.net/Articles/511259/. Ok so no bug on tcc here, good :) Ciao, Michael. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Please someone here that administer this project can open a free account for opensource projects on http://scan.coverity.com/ and submit tinycc build to verify for defects, I did with my account and I've got this: There is much more details available about this problems on the account pages, if someone want to see then tell me and I can add a new user to see then on my account. CIDTypeImpactStatusFirst DetectedOwner ClassificationSeverityActionComponentCategoryFile Function 968207Uninitialized scalar variableHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOther Uninitialized variables/tccgen.cvpush64 968206Uninitialized scalar variableHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOther Uninitialized variables/tccgen.cunary 968205Uninitialized pointer readHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherMemory - illegal accesses/tccgen.cstruct_decl 968204Uninitialized scalar variableHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOther Uninitialized variables/tccgen.cgv 968203Uninitialized scalar variableHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOther Uninitialized variables/tccgen.cgfunc_param_typed 968202Uninitialized scalar variableHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOther Uninitialized variables/tccgen.cgen_op 968201Uninitialized scalar variableHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOther Uninitialized variables/tccgen.cexpr_cond 968200Uninitialized scalar variableHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOther Uninitialized variables/tccgen.cexpr_cond 968199Untrusted loop boundMediumNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherInsecure data handling/win32/tools/tiny_libmaker.cmain 968198Untrusted loop boundMediumNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherInsecure data handling/win32/tools/tiny_impdef.cget_export_names 968197Untrusted array index readMediumNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherInsecure data handling/tccpp.cnext_nomacro1 968196VariousMediumNew1/17/2013Unassigned UnclassifiedUnspecifiedUndecidedOtherInsecure data handling/tccpe.cpe_load_res 968195VariousMediumNew1/17/2013Unassigned UnclassifiedUnspecifiedUndecidedOtherInsecure data handling/tccelf.ctcc_load_object_file 968194VariousMediumNew1/17/2013Unassigned UnclassifiedUnspecifiedUndecidedOtherInsecure data handling/tccelf.ctcc_load_dll 968193Untrusted loop boundMediumNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherInsecure data handling/tccelf.ctcc_load_alacarte 968192Destination buffer too smallHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherMemory - corruptions/tccpe.cpe_write 968191Copy into fixed size bufferLowNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity best practices violations/tccpe.cpe_load_def 968190Copy into fixed size bufferLowNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity best practices violations/tccpe.cpe_find_import 968189Copy into fixed size bufferLowNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity best practices violations/tccpe.cpe_assign_addresses 968188Copy into fixed size bufferLowNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity best practices violations/tccgen.cgen_inline_functions 968187Copy into fixed size bufferLowNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity best practices violations/tccelf.cld_add_file_list 968186Copy into fixed size bufferLowNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherSecurity best practices violations/libtcc.cput_extern_sym2 968185String not null terminatedHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherMemory - illegal accesses/win32/tools/tiny_libmaker.cmain 968184String not null terminatedHighNew1/17/2013 UnassignedUnclassifiedUnspecifiedUndecidedOtherMemory - illegal accesses/tccelf.c
Re: [Tinycc-devel] Call for testing
Le dimanche 6 janvier 2013 11:28:39, Didier Barvaux a écrit :
=== Build of TCC GIT with Clang 3.2 ===
Build OK (with some warnings, I can provide them to you if you want).
[SNIP]
With the 'return' statement removed from the cmp_comparison_test()
function, tests seem to be still KO. Example with 'test1':
test1
../tcc -B.. -DTCC_TARGET_I386 -run tcctest.c test.out1
--- test.ref 2013-01-06 10:59:06.0 +0100
+++ test.out1 2013-01-06 10:59:06.0 +0100
@@ -299,7 +299,7 @@
sizeof(+(char)'a') = 4
sizeof(-(char)'a') = 4
sizeof(~(char)'a') = 4
--66 -66 -66 -66 4294967230 4294967230
+-66 -66 -66 -66 -66 -66
0x1 0xf0f0 (nil) 0xfff0
bitfield_test:sizeof(st1) = 8
3 -1 15 -8 121
I can do other tests and/or try patches to fix that problem if you want.
Interesting. I misread that first but the line with -- is the output of clang.
It seems clang and gcc disagree:
$ cat long_long.c
#include stdio.h
int main(void)
{
char *p = NULL;
p -= 0x7042;
/* from pointer to integer types */
printf(%d %d %ld %ld %lld %lld\n,
(int)p, (unsigned int)p,
(long)p, (unsigned long)p,
(long long)p, (unsigned long long)p);
return 0;
}
$ gcc -o long_long long_long.c ./long_long
[SNIP gcc warnings]
-66 -66 -66 -66 -66 -66
$ clang -o long_long long_long.c ./long_long
-66 -66 -66 -66 4294967230 4294967230
So at least tcc is consistent to gcc. I'm not sure what the correct value (if
any) should be though.
Best regards,
Thomas Preud'homme
signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Hi,
On Wed, 16 Jan 2013, Thomas Preud'homme wrote:
$ cat long_long.c
#include stdio.h
int main(void)
{
char *p = NULL;
p -= 0x7042;
/* from pointer to integer types */
printf(%d %d %ld %ld %lld %lld\n,
(int)p, (unsigned int)p,
(long)p, (unsigned long)p,
(long long)p, (unsigned long long)p);
return 0;
}
Pointer to integer conversions (and back) are implementation defined, the
only requirement being that if the integer type is (u)intptr_t that a
pointer converted to that one and back to a pointer shall compare equal to
the original pointer.
So, depending on how the compiler implements this conversion (and
documents this) one might get different results:
$ gcc -o long_long long_long.c ./long_long
[SNIP gcc warnings]
-66 -66 -66 -66 -66 -66
This is a correct result for ILP32 (i.e. 32bit code). GCC sign extends
pointers when the pointer representation needs fewer bits than the target
type.
$ clang -o long_long long_long.c ./long_long
-66 -66 -66 -66 4294967230 4294967230
And this is also a correct result for 32bit code, when the compiler
defines pointer to integer conversion to be zero-extending when the target
type has more bits than a pointer. IMO sign-extending is more useful, and
as GCC set the precedent a long time ago I would declare clang to at least
have an QoI issue with compatibility with GCC. In other words: tcc has no
bug here.
Ciao,
Michael.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le dimanche 6 janvier 2013 17:03:28, grischka a écrit : Other candidates for reversion (OTOH): - http://repo.or.cz/w/tinycc.git/commitdiff/fc574f14984d11f1ead50560d1bdc5ae 0eaf6d8d The headers from include are copied to win32/include during install I'm not sure to understand why _STATIC_ASSERT was modified. Are you just claiming the fix is subobptimal because of the code duplication or the fix is useless? - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5ab ee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. Indeed. I followed the chain of changes when I noticed that patch and it led to your commit f366cb20fe06396609a5438756c3c49662b7316c. However, I didn't read into details the content of the for loops at that time. I just assumed a bug was noticed by someone and that was the fix. Now, I see the if (0 == *p) and realize it was indeed intentional. Reverted. signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Hi Akim, Le dimanche 13 janvier 2013 23:30:49, Thomas Preud'homme a écrit : In the case we had some warnings I'd still prefer to not use -D_FORTIFY_SOURCE 0. The first reason is that _FORTIFY_SOURCE does 2 things: it hardens the source by adding some buffer overflow checks and it adds more warnings. Setting _FORTIFY_SOURCE to 0 would stop the warning but also stop all the hardening which could be wanted. Secondly, turning off warnings globally to avoid some false positives would mean we miss real cases where someone forgot to test the return value of a function. Also, someone please test the functionality of the install. (I suspect libtcc.h might be missing). Good catch. It seems it comes from commit e79281f58ec302e8cc9dfc7d00e06f426fcd2acd. Can you explain me what is the purpose of second part of the sed command used to create symlink to Makefile: s,[^/]*/,../,g I'm trying to build from tmp/tcc-builddir while the source are in tmp/tcc. The first part of the sed command correctly transform ../tcc/./ into ../tcc/ but then the second part change it into ../../ I suppose that was not the intended behavior but I don't see what was expected. Best regards, Thomas Preud'homme signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le 14 janv. 2013 à 17:55, Thomas Preud'homme robo...@celest.fr a écrit : Hi Akim, Hi Thomas, If there were other messages for me, I might have missed them :( Can you explain me what is the purpose of second part of the sed command used to create symlink to Makefile: s,[^/]*/,../,g The thing is that cp 1/2 3/4/ and ln 1/2 3/4/ have nothing in common: in the ln case, it is equivalent to cd 3/4 ln 1/2 .. Absolute paths are resolved from the destination, not from the current directory. So if I mean to ln 1/2 3/4/ in the way cp does, I need to ln ../../1/2 3/4/. I'm trying to build from tmp/tcc-builddir while the source are in tmp/tcc. The first part of the sed command correctly transform ../tcc/./ into ../tcc/ but then the second part change it into ../../ I suppose that was not the intended behavior but I don't see what was expected. This is the kind of things that Autoconf provides bullet proof :( I don't know why there is the trailing ./, I guess it should suffice to cleanup the directories first, i.e., removing things like ./. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le lundi 14 janvier 2013 18:01:08, Akim Demaille a écrit : Le 14 janv. 2013 à 17:55, Thomas Preud'homme robo...@celest.fr a écrit : Hi Akim, Hi Thomas, If there were other messages for me, I might have missed them :( Can you explain me what is the purpose of second part of the sed command used to create symlink to Makefile: s,[^/]*/,../,g The thing is that cp 1/2 3/4/ and ln 1/2 3/4/ have nothing in common: in the ln case, it is equivalent to cd 3/4 ln 1/2 .. Absolute paths are resolved from the destination, not from the current directory. So if I mean to ln 1/2 3/4/ in the way cp does, I need to ln ../../1/2 3/4/. I'm trying to build from tmp/tcc-builddir while the source are in tmp/tcc. The first part of the sed command correctly transform ../tcc/./ into ../tcc/ but then the second part change it into ../../ I suppose that was not the intended behavior but I don't see what was expected. This is the kind of things that Autoconf provides bullet proof :( I don't know why there is the trailing ./, I guess it should suffice to cleanup the directories first, i.e., removing things like ./. What do you think of the proposed fix? It works for me at least. It first look at the directory in which the symlink is to be done and strip entirely the path if it's ./. Else, it will look like path/to/symlink and it will replace each subdirectory by .., as in your original patch. At this stage you get the correct number of .. to go down from the directory where a given symlink is to be created to the directory in which configure was called. You just need to add the relative path to the source root + the path to the Makefile needing to be symlinked. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas Preud'homme wrote: Le dimanche 6 janvier 2013 17:03:28, grischka a écrit : Other candidates for reversion (OTOH): - http://repo.or.cz/w/tinycc.git/commitdiff/fc574f14984d11f1ead50560d1bdc5ae 0eaf6d8d The headers from include are copied to win32/include during install I'm not sure to understand why _STATIC_ASSERT was modified. Are you just claiming the fix is subobptimal because of the code duplication or the fix is useless? Done. The code duplication was wrong. The _STATIC_ASSERT fix looks ok. It was to compile the vswap patch. Reverted that too (leaving a comment in the source). --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le 14 janv. 2013 à 18:23, Thomas Preud'homme robo...@celest.fr a écrit : What do you think of the proposed fix? It works for me at least. It first look at the directory in which the symlink is to be done and strip entirely the path if it's ./. Else, it will look like path/to/symlink and it will replace each subdirectory by .., as in your original patch. yes, this is what I meant by cleaning. At this stage you get the correct number of .. to go down from the directory where a given symlink is to be created to the directory in which configure was called. You just need to add the relative path to the source root + the path to the Makefile needing to be symlinked. This part is expected to be correct in what I had submitted. IIRC, only the cleanup part is needed, right? You might have intended to attach a patch for review :) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le lundi 14 janvier 2013 18:47:12, Akim Demaille a écrit : Le 14 janv. 2013 à 18:23, Thomas Preud'homme robo...@celest.fr a écrit : What do you think of the proposed fix? It works for me at least. It first look at the directory in which the symlink is to be done and strip entirely the path if it's ./. Else, it will look like path/to/symlink and it will replace each subdirectory by .., as in your original patch. yes, this is what I meant by cleaning. At this stage you get the correct number of .. to go down from the directory where a given symlink is to be created to the directory in which configure was called. You just need to add the relative path to the source root + the path to the Makefile needing to be symlinked. This part is expected to be correct in what I had submitted. IIRC, only the cleanup part is needed, right? You might have intended to attach a patch for review :) Yes, only the cleanup was needed but it was easier (at least it seemed easier to me) to build the path differently, hence this last part changed as well, but the principle remain the same. You can find the patch in the web VCS interface at: http://repo.or.cz/w/tinycc.git/commitdiff/f7b417723ed6875684b3591845e93ae1f49813d3?hp=a4e630c7d94f64af160ffaabf290735b7374c8ec signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Akim Demaille wrote: This is the kind of things that Autoconf provides bullet proof :( Maybe it does something but there is no way to know how. And so we prefer transparency over bullets, nowadays. ;) --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le dimanche 6 janvier 2013 17:03:28, grischka a écrit : /usr/bin/gcc-4.0.4 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 I think some people might not feel comfortable to see their absolute paths exposed. Also it makes command lines longer/uglier than necessary and is redundant here anyway (same as -I.). -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 Do we need both -march=i386 and -m32? Also, what about removing -mpreferred-stack-boundary=2 and -falign-functions=0 ? We can. I don't know why they were added in the first place and when that's the case I just leave things untouched. cc1: error: unrecognized command line option -Wno-unused-result make: *** [tcc.o] Error 1 Maybe we could test supported switches by running the compiler in configure. Normally all tests about the environment should go to configure. Also it should be possible to set everything in configure as well since tcc could be built by cross-compilation and in this case the host environment is irrelevant. But at least that part should wait for after the release. As to testing the switch, I don't have much motivation right now and I prefer to spend my free time on fixing bugs first. Also what about using -D_FORTIFY_SOURCE=0 when -Wno-unused-result is not supported? I don't think that's a good idea. It seems I built with a custom CFLAGS because I don't have any warnings if I build without that switch so we can just remove -Wno-unused-result. In the case we had some warnings I'd still prefer to not use -D_FORTIFY_SOURCE 0. The first reason is that _FORTIFY_SOURCE does 2 things: it hardens the source by adding some buffer overflow checks and it adds more warnings. Setting _FORTIFY_SOURCE to 0 would stop the warning but also stop all the hardening which could be wanted. Secondly, turning off warnings globally to avoid some false positives would mean we miss real cases where someone forgot to test the return value of a function. Also, someone please test the functionality of the install. (I suspect libtcc.h might be missing). Good catch. It seems it comes from commit e79281f58ec302e8cc9dfc7d00e06f426fcd2acd. Compilation on Windows with MSC fails in tccgen.c:vswap(): ../tccgen.c(476) : error C2143: syntax error : missing ';' before 'type' [more ...] Oh, C99ism. Fixed After moving declarations before statements, it fails like this: ../tccgen.c(490) : warning C4308: negative integral constant converted to unsigned type ../tccgen.c(490) : warning C4307: '*' : integral constant overflow ../tccgen.c(490) : warning C4307: '+' : integral constant overflow ../tccgen.c:481: error: incompatible types for redefinition of '__static_assert_t' [more ...] I'd suggest to move that optimization into its own function void memswap(void *p1, void *p2, size_t n); or otherwise to revert it. I'll check this and the rest later. Free time over for today :) Other candidates for reversion (OTOH): - http://repo.or.cz/w/tinycc.git/commitdiff/fc574f14984d11f1ead50560d1bdc5ae 0eaf6d8d The headers from include are copied to win32/include during install - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5ab ee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. - http://repo.or.cz/w/tinycc.git/commitdiff/3d409b08893873b917ccb8c34398bc41 a4e84d7c The patch doesn't fix the real problem which is not duplicate -I's by the user but the very obviously crappy handling of #include_next itself. Of course the patch fixes something, but if we keep it chances are that we'll never see a correct solution. Thanks for fixing this one. I didn't look at the diff yet, even less tried the fix but I know you did some good job. I'll take a look in a day or two, - ETOOBUSY right now. --- grischka Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
2013/1/7 grischka gris...@gmx.de: Roy Tam wrote: 2013/1/7 Roy Tam roy...@gmail.com: 2013/1/7 grischka gris...@gmx.de: - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5abee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. Did you tried reverting this commit and try linking with -luser32? Without this commit, you can't link to user32 even if you specify -luser32. ... so tcc restricting people not linking to user32 and gdi32 when writing PE_CLI programs, and ignoring users -l switches is definitely a bug to users. If tcc would ignore -l switches that would be a serious problem indeed, but neither do I see such problem nor do I see how your patch is supposed to fix it. As I read the patch it has no effect on -l processing ??? It is a workaround, but I can't reproduce it in the latest git, so feel free to revert it. (but gcc, dmc, msvc doesn't restrict people not linking to user32 when linking console applications, does it necessary to have it in tcc?) --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Hi Thomas. TCC on the mob branch has progressed quite a lot. I use it for testing compilation of gawk (GNU Awk). It is quite fast, which is a significant pleasure compared to gcc or clang. The released version did compile gawk but many tests would fail. I use it on x86_64 Linux. All of the tests compile, but there is a known issue with relocations when building shared libraries such that two of the tests based on shared libraries fail. I personally would love to see that issue fixed before a release, but I understand that it may not happen. If you wish to test: git clone git://git.savannah.gnu.org/gawk.git cd gawk ./configure CC=tcc make make check Thanks, Arnold Robbins ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas, In preparation of the upcoming release of tinycc 0.9.26, I would like to have reports about how tcc build and works to be sure it is as stable as possible.I tried quickly on my arm machine and will continue to do experiment on that machine and my amd64 machine but I'd welcome any test from other people with different usage. In particular, I would appreciate to have people build tcc for other platform than Linux, for instance Windows (Grishka ;) or Mac OS (I think there was some work to make tcc work on Mac OS but I'm not sure). I performed some tests on a Linux x86 system with the various compilers available on that system. For all tests, GIT revision was fc574f14984d11f1ead50560d1bdc5ae0eaf6d8d === Build of TCC GIT with GCC 4.0.4 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.0.4 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option -Wno-unused-result make: *** [tcc.o] Error 1 === Build of TCC GIT with GCC 4.1.2 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.1.2 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option -Wno-unused-result make: *** [tcc.o] Error 1 === Build of TCC GIT with GCC 4.3.6 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.3.6 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option -Wno-unused-result make: *** [tcc.o] Error 1 === Build of TCC GIT with GCC 4.4.7 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.5.4 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.6.3 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.7.2 === Build OK. Tests OK. === Build of TCC GIT with Clang 3.2 === Build OK (with some warnings, I can provide them to you if you want). Tests KO (see traces below). libtest ./libtcc_test lib_path=.. Hello World! fib(32) = 2178309 add(32, 64) = 96 cp ../include/tcclib.h . /usr/bin/clang -o tcctest.gcc tcctest.c -I. -I. -I/home/didier/documents/tech/dev/tcc/tinycc -w -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 -DTCC_TARGET_I386 -std=gnu99 -O0 -fno-omit-frame-pointer tcctest.c:2585:3: error: void function 'cmp_comparison_test' should not return a value [-Wreturn-type] return 0; ^ ~ 1 error generated. make[1]: *** [test.ref] Error 1 make[1]: Leaving directory `/home/didier/documents/tech/dev/tcc/tinycc/tests' make: *** [test] Error 2 With the 'return' statement removed from the cmp_comparison_test() function, tests seem to be still KO. Example with 'test1': test1 ../tcc -B.. -DTCC_TARGET_I386 -run tcctest.c test.out1 --- test.ref2013-01-06 10:59:06.0 +0100 +++ test.out1 2013-01-06 10:59:06.0 +0100 @@ -299,7 +299,7 @@ sizeof(+(char)'a') = 4 sizeof(-(char)'a') = 4 sizeof(~(char)'a') = 4 --66 -66 -66 -66 4294967230 4294967230 +-66 -66 -66 -66 -66 -66 0x1 0xf0f0 (nil) 0xfff0 bitfield_test:sizeof(st1) = 8 3 -1 15 -8 121 I can do other tests and/or try patches to fix that problem if you want. === Build of TCC GIT with TCC GIT === Build OK. Tests KO. make -C tests2 test make[1]: Entering directory `/home/didier/documents/tech/dev/tcc/tinycc/tests2' Test: 00_assignment... Test: 01_comment... Test: 02_printf... Test: 03_struct... Test: 04_for... Test: 05_array... Test: 06_case... Test: 07_function... Test: 08_while... Test: 09_do_while... Test: 10_pointer... Test: 11_precedence... Test: 12_hashdefine... Test: 13_integer_literals... Test: 14_if... Test: 15_recursion... Test: 16_nesting... Test: 17_enum... Test: 18_include... Test: 19_pointer_arithmetic... Test: 20_pointer_comparison... Test: 21_char_array... Test: 22_floating_point... Test: 23_type_coercion... Test: 24_math_library... Test: 25_quicksort... Test: 26_character_constants... Test: 27_sizeof... Test: 28_strings... /bin/sh: line 5: 5741 Segmentation fault ../tcc -B.. -run 28_strings.c 21 28_strings.output make[1]: *** [28_strings.test] Error 139 make[1]: Leaving directory `/home/didier/documents/tech/dev/tcc/tinycc/tests2' make: *** [test] Error 2 I can do other tests and/or try patches to fix that problem if you want. === Build of ROHC library with TCC
Re: [Tinycc-devel] Call for testing
Le dimanche 6 janvier 2013 09:36:05, Aharon Robbins a écrit : Hi Thomas. TCC on the mob branch has progressed quite a lot. I use it for testing compilation of gawk (GNU Awk). It is quite fast, which is a significant pleasure compared to gcc or clang. The released version did compile gawk but many tests would fail. I use it on x86_64 Linux. All of the tests compile, but there is a known issue with relocations when building shared libraries such that two of the tests based on shared libraries fail. I personally would love to see that issue fixed before a release, but I understand that it may not happen. If you wish to test: git clone git://git.savannah.gnu.org/gawk.git cd gawk ./configure CC=tcc make make check Yes, this bug is on my radar but I don't plan to work on it for 0.9.26. I'd love to see it fixed but since it's not a regression (it wasn't working with 0.9.25 neither) I prefer to not delay the release further. This release cycle has been very long and I think it's better to get it release as soon as possible. I should have mention that my focus is on regressions. Be sure though that it's high on my TODO list for 0.9.27. Thanks, Arnold Robbins Thanks Arnold. Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le dimanche 6 janvier 2013 11:28:39, Didier Barvaux a écrit : Thomas, Hi Olivier, I performed some tests on a Linux x86 system with the various compilers available on that system. For all tests, GIT revision was fc574f14984d11f1ead50560d1bdc5ae0eaf6d8d thanks for all these tests, it's much welcome. === Build of TCC GIT with GCC 4.0.4 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.0.4 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option -Wno-unused-result make: *** [tcc.o] Error 1 === Build of TCC GIT with GCC 4.1.2 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.1.2 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option -Wno-unused-result make: *** [tcc.o] Error 1 === Build of TCC GIT with GCC 4.3.6 === Build failed because of -Wno-unused-result being unknown. /usr/bin/gcc-4.3.6 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 cc1: error: unrecognized command line option -Wno-unused-result make: *** [tcc.o] Error 1 Can you try thi fix in eb028a8f423d2623cc174ab4d3c5a80fd8efbdde ? If you have access to llvm, can you give me its output to -dumpversion ? === Build of TCC GIT with GCC 4.4.7 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.5.4 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.6.3 === Build OK. Tests OK. === Build of TCC GIT with GCC 4.7.2 === Build OK. Tests OK. === Build of TCC GIT with Clang 3.2 === Build OK (with some warnings, I can provide them to you if you want). Tests KO (see traces below). libtest ./libtcc_test lib_path=.. Hello World! fib(32) = 2178309 add(32, 64) = 96 cp ../include/tcclib.h . /usr/bin/clang -o tcctest.gcc tcctest.c -I. -I. -I/home/didier/documents/tech/dev/tcc/tinycc -w -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 -DTCC_TARGET_I386 -std=gnu99 -O0 -fno-omit-frame-pointer tcctest.c:2585:3: error: void function 'cmp_comparison_test' should not ret urn a value [-Wreturn-type] return 0; ^ ~ 1 error generated. make[1]: *** [test.ref] Error 1 make[1]: Leaving directory `/home/didier/documents/tech/dev/tcc/tinycc/test s' make: *** [test] Error 2 Fixed in mob. With the 'return' statement removed from the cmp_comparison_test() function, tests seem to be still KO. Example with 'test1': test1 ../tcc -B.. -DTCC_TARGET_I386 -run tcctest.c test.out1 --- test.ref 2013-01-06 10:59:06.0 +0100 +++ test.out1 2013-01-06 10:59:06.0 +0100 @@ -299,7 +299,7 @@ sizeof(+(char)'a') = 4 sizeof(-(char)'a') = 4 sizeof(~(char)'a') = 4 --66 -66 -66 -66 4294967230 4294967230 +-66 -66 -66 -66 -66 -66 0x1 0xf0f0 (nil) 0xfff0 bitfield_test:sizeof(st1) = 8 3 -1 15 -8 121 I can do other tests and/or try patches to fix that problem if you want. Looks like long long behave like a long. Depending on wether it was present or not in the previous release I'll see the time I can spend on this. It might be quick though. === Build of TCC GIT with TCC GIT === Build OK. Tests KO. make -C tests2 test make[1]: Entering directory `/home/didier/documents/tech/dev/tcc/tinycc/tes ts2' Test: 00_assignment... Test: 01_comment... Test: 02_printf... Test: 03_struct... Test: 04_for... Test: 05_array... Test: 06_case... Test: 07_function... Test: 08_while... Test: 09_do_while... Test: 10_pointer... Test: 11_precedence... Test: 12_hashdefine... Test: 13_integer_literals... Test: 14_if... Test: 15_recursion... Test: 16_nesting... Test: 17_enum... Test: 18_include... Test: 19_pointer_arithmetic... Test: 20_pointer_comparison... Test: 21_char_array... Test: 22_floating_point... Test: 23_type_coercion... Test: 24_math_library... Test: 25_quicksort... Test: 26_character_constants... Test: 27_sizeof... Test: 28_strings... /bin/sh: line 5: 5741 Segmentation fault ../tcc -B.. -run 28_strings.c 21 28_strings.output make[1]: *** [28_strings.test] Error 139 make[1]: Leaving directory `/home/didier/documents/tech/dev/tcc/tinycc/test s2' make: *** [test] Error 2 I can do other tests and/or try patches to
Re: [Tinycc-devel] Call for testing
Hi Olivier, My name's Didier :) === Build of TCC GIT with GCC 4.0.4 === Build failed because of -Wno-unused-result being unknown. [...] === Build of TCC GIT with GCC 4.1.2 === Build failed because of -Wno-unused-result being unknown. [...] === Build of TCC GIT with GCC 4.3.6 === Build failed because of -Wno-unused-result being unknown. [...] Can you try thi fix in eb028a8f423d2623cc174ab4d3c5a80fd8efbdde ? If you have access to llvm, can you give me its output to -dumpversion ? Build and tests are now OK for GCC 4.0.4, 4.1.2, and 4.3.6. Thanks! === Build of TCC GIT with Clang 3.2 === Build OK (with some warnings, I can provide them to you if you want). Tests KO (see traces below). libtest ./libtcc_test lib_path=.. Hello World! fib(32) = 2178309 add(32, 64) = 96 cp ../include/tcclib.h . /usr/bin/clang -o tcctest.gcc tcctest.c -I. -I. -I/home/didier/documents/tech/dev/tcc/tinycc -w -Wall -g -O2 -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 -DTCC_TARGET_I386 -std=gnu99 -O0 -fno-omit-frame-pointer tcctest.c:2585:3: error: void function 'cmp_comparison_test' should not ret urn a value [-Wreturn-type] return 0; ^ ~ 1 error generated. make[1]: *** [test.ref] Error 1 make[1]: Leaving directory `/home/didier/documents/tech/dev/tcc/tinycc/test s' make: *** [test] Error 2 Fixed in mob. I confirm. Regards, Didier signature.asc Description: PGP signature ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
/usr/bin/gcc-4.0.4 -o tcc.o -c tcc.c -DTCC_TARGET_I386 -I. -I/home/didier/documents/tech/dev/tcc/tinycc -Wall -g -O2 I think some people might not feel comfortable to see their absolute paths exposed. Also it makes command lines longer/uglier than necessary and is redundant here anyway (same as -I.). -fno-strict-aliasing -Wno-pointer-sign -Wno-sign-compare -Wno-unused-result -mpreferred-stack-boundary=2 -march=i386 -falign-functions=0 -m32 Do we need both -march=i386 and -m32? Also, what about removing -mpreferred-stack-boundary=2 and -falign-functions=0 ? cc1: error: unrecognized command line option -Wno-unused-result make: *** [tcc.o] Error 1 Maybe we could test supported switches by running the compiler in configure. Also what about using -D_FORTIFY_SOURCE=0 when -Wno-unused-result is not supported? Also, someone please test the functionality of the install. (I suspect libtcc.h might be missing). Compilation on Windows with MSC fails in tccgen.c:vswap(): ../tccgen.c(476) : error C2143: syntax error : missing ';' before 'type' [more ...] After moving declarations before statements, it fails like this: ../tccgen.c(490) : warning C4308: negative integral constant converted to unsigned type ../tccgen.c(490) : warning C4307: '*' : integral constant overflow ../tccgen.c(490) : warning C4307: '+' : integral constant overflow ../tccgen.c:481: error: incompatible types for redefinition of '__static_assert_t' [more ...] I'd suggest to move that optimization into its own function void memswap(void *p1, void *p2, size_t n); or otherwise to revert it. Other candidates for reversion (OTOH): - http://repo.or.cz/w/tinycc.git/commitdiff/fc574f14984d11f1ead50560d1bdc5ae0eaf6d8d The headers from include are copied to win32/include during install - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5abee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. - http://repo.or.cz/w/tinycc.git/commitdiff/3d409b08893873b917ccb8c34398bc41a4e84d7c The patch doesn't fix the real problem which is not duplicate -I's by the user but the very obviously crappy handling of #include_next itself. Of course the patch fixes something, but if we keep it chances are that we'll never see a correct solution. --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
grischka wrote: - http://repo.or.cz/w/tinycc.git/commitdiff/3d409b08893873b917ccb8c34398bc41a4e84d7c The patch doesn't fix the real problem which is not duplicate -I's by the user but the very obviously crappy handling of #include_next itself. Of course the patch fixes something, but if we keep it chances are that we'll never see a correct solution. Ok, I did that one. http://repo.or.cz/w/tinycc.git/commitdiff/2358b378b3cd526956713f033f5a0ecaa5f63951 ;=) ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Le dimanche 6 janvier 2013 17:25:59, grischka a écrit : grischka wrote: - http://repo.or.cz/w/tinycc.git/commitdiff/3d409b08893873b917ccb8c34398bc 41a4e84d7c The patch doesn't fix the real problem which is not duplicate -I's by the user but the very obviously crappy handling of #include_next itself. Of course the patch fixes something, but if we keep it chances are that we'll never see a correct solution. Ok, I did that one. http://repo.or.cz/w/tinycc.git/commitdiff/2358b378b3cd526956713f033f5a0ecaa 5f63951 ;=) Wow, that was super fast. Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Thomas Preud'homme wrote: Ok, I did that one. http://repo.or.cz/w/tinycc.git/commitdiff/2358b378b3cd526956713f033f5a0ecaa 5f63951 ;=) Wow, that was super fast. Don't be scared. I found a sketch in an old private branch. ;) --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
2013/1/7 grischka gris...@gmx.de: - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5abee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. Did you tried reverting this commit and try linking with -luser32? Without this commit, you can't link to user32 even if you specify -luser32. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
2013/1/7 Roy Tam roy...@gmail.com: 2013/1/7 grischka gris...@gmx.de: - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5abee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. Did you tried reverting this commit and try linking with -luser32? Without this commit, you can't link to user32 even if you specify -luser32. ... so tcc restricting people not linking to user32 and gdi32 when writing PE_CLI programs, and ignoring users -l switches is definitely a bug to users. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Call for testing
Roy Tam wrote: 2013/1/7 Roy Tam roy...@gmail.com: 2013/1/7 grischka gris...@gmx.de: - http://repo.or.cz/w/tinycc.git/commitdiff/943574aba54713ca4a17fe33aadde5abee233b53 Obviously (if you look at the code) this was not a bug but intended behavior. Did you tried reverting this commit and try linking with -luser32? Without this commit, you can't link to user32 even if you specify -luser32. ... so tcc restricting people not linking to user32 and gdi32 when writing PE_CLI programs, and ignoring users -l switches is definitely a bug to users. If tcc would ignore -l switches that would be a serious problem indeed, but neither do I see such problem nor do I see how your patch is supposed to fix it. As I read the patch it has no effect on -l processing ??? --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] Call for testing
Greetings dear fellow tinycc developers and enthousiasts, In preparation of the upcoming release of tinycc 0.9.26, I would like to have reports about how tcc build and works to be sure it is as stable as possible.I tried quickly on my arm machine and will continue to do experiment on that machine and my amd64 machine but I'd welcome any test from other people with different usage. In particular, I would appreciate to have people build tcc for other platform than Linux, for instance Windows (Grishka ;) or Mac OS (I think there was some work to make tcc work on Mac OS but I'm not sure). I would also welcome any possible benchmark of building a significant piece of code for both the current version on the mob branch and the version 0.9.25. This would tell me if there is performance regression or on the contrary some improvement which could be put forward in the release announce. Best regards, Thomas signature.asc Description: This is a digitally signed message part. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
