Re: [Tinycc-devel] Annoying new warning
Christian Jullien wrote: Especially if " LDOUBLE_SIZE != 8 is not possible in any arm config" why is there such a test in arm-gen.c code? The "arm-fpa-ld" variant gets LDOUBLE_SIZE=12 passed from the Makefile. -- gr ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Annoying new warning
So, gentlemen, it seems that at least one ARM configuration/option requires the offending code having test on an uninitialized value. Commenting using #if will fail if "arm-fpa-ld" is used. Can you please take a moment to investigate and propose the right fix. C. -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of grischka Sent: dimanche 7 mai 2017 11:11 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Annoying new warning Christian Jullien wrote: > Especially if " LDOUBLE_SIZE != 8 is not possible in any arm config" > why is there such a test in arm-gen.c code? The "arm-fpa-ld" variant gets LDOUBLE_SIZE=12 passed from the Makefile. -- gr ___ 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] Annoying new warning
Christian Jullien wrote: So, gentlemen, it seems that at least one ARM configuration/option requires the offending code having test on an uninitialized value. Commenting using #if will fail if "arm-fpa-ld" is used. Can you please take a moment to investigate and propose the right fix. Nope. We will not waste more of anyone's time with this. http://repo.or.cz/tinycc.git/commitdiff/44abffe33a10ee2bdc0d66f87ffa5e178182d6e6 Please test. Thanks, --- grischka ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Annoying new warning
Thank grischka, Be use I annoyed you with this warning because, to me, it exhibits a potential issue on arm. Your fix gives: make[1]: Entering directory '/home/jullien/tinycc/lib' ../tcc -c libtcc1.c -o libtcc1.o -DCONFIG_TRIPLET="arm-linux-gnueabihf" -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -B.. ../tcc -c armeabi.c -o armeabi.o -DCONFIG_TRIPLET="arm-linux-gnueabihf" -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -B.. ../tcc -c alloca-arm.S -o alloca-arm.o -DCONFIG_TRIPLET="arm-linux-gnueabihf" -DTCC_TARGET_ARM -DTCC_ARM_EABI -DTCC_ARM_HARDFLOAT -DTCC_ARM_VFP -B.. alloca-arm.S: error: unrecognized file type Makefile:67: recipe for target 'alloca-arm.o' failed -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of grischka Sent: dimanche 7 mai 2017 12:45 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Annoying new warning Christian Jullien wrote: > So, gentlemen, it seems that at least one ARM configuration/option > requires the offending code having test on an uninitialized value. > > Commenting using #if will fail if "arm-fpa-ld" is used. > > Can you please take a moment to investigate and propose the right fix. Nope. We will not waste more of anyone's time with this. http://repo.or.cz/tinycc.git/commitdiff/44abffe33a10ee2bdc0d66f87ffa5e178182 d6e6 Please test. Thanks, --- 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] Annoying new warning
Christian Jullien wrote: alloca-arm.S: error: unrecognized file type Ok, bottom of arm-gen.c, remove #ifndef TCC_IS_NATIVE thanks. Makefile:67: recipe for target 'alloca-arm.o' failed -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of grischka Sent: dimanche 7 mai 2017 12:45 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] Annoying new warning Christian Jullien wrote: So, gentlemen, it seems that at least one ARM configuration/option requires the offending code having test on an uninitialized value. Commenting using #if will fail if "arm-fpa-ld" is used. Can you please take a moment to investigate and propose the right fix. Nope. We will not waste more of anyone's time with this. http://repo.or.cz/tinycc.git/commitdiff/44abffe33a10ee2bdc0d66f87ffa5e178182 d6e6 Please test. Thanks, --- 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 ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] Annoying new warning
Ok, it works, including tests with:
jullien@sims3:~/tinycc $ git diff
diff --git a/arm-gen.c b/arm-gen.c
index a5dabd1..34e1ef2 100644
--- a/arm-gen.c
+++ b/arm-gen.c
@@ -2150,6 +2150,4 @@ ST_FUNC void gen_vla_alloc(CType *type, int align) {
#endif
/*/
-#ifndef TCC_IS_NATIVE
#include "arm-asm.c"
-#endif
-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
On Behalf Of grischka
Sent: dimanche 7 mai 2017 13:07
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] Annoying new warning
Christian Jullien wrote:
> alloca-arm.S: error: unrecognized file type
Ok, bottom of arm-gen.c, remove
#ifndef TCC_IS_NATIVE
thanks.
> Makefile:67: recipe for target 'alloca-arm.o' failed
>
> -Original Message-
> From: Tinycc-devel
> [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org]
> On Behalf Of grischka
> Sent: dimanche 7 mai 2017 12:45
> To: tinycc-devel@nongnu.org
> Subject: Re: [Tinycc-devel] Annoying new warning
>
> Christian Jullien wrote:
>> So, gentlemen, it seems that at least one ARM configuration/option
>> requires the offending code having test on an uninitialized value.
>>
>> Commenting using #if will fail if "arm-fpa-ld" is used.
>>
>> Can you please take a moment to investigate and propose the right fix.
>
> Nope. We will not waste more of anyone's time with this.
>
> http://repo.or.cz/tinycc.git/commitdiff/44abffe33a10ee2bdc0d66f87ffa5e
> 178182
> d6e6
>
> Please test. Thanks,
>
> --- 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
>
___
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] Add support of musl-libc to tinycc
Michael - On Sun, May 07, 2017 at 08:16:08AM +0200, Michael Matz wrote: > On debian, if you have libc6-dev and musl-dev installed you get a > [mess that doesn't work with tinycc]. > So, yeah, the detection/support of musl > is early and doesn't work with the split-mind approach that debian > is using. > > It does work for the setup of musl as the main libc, like with > alpine linux; so I'm not sure the detection should be disabled or > rather be improved (or there should perhaps be a configure option to > override the detection by users). OK, sounds good, as long as improving the test results in it being disabled by default in debian and similar systems. I'd hate to see noobs discouraged from using this otherwise really nice code base by broken-ness caused by a false-positive musl detector. > >gcc-4.7.4/gcc/c-family/c-opts.c:141: error: ';' expected (got "=") > Yeah, thanks for finding the cause downthread. extern file-scope > declarations with initializer are questionable style but indeed > allowed by the standard, i.e. the above rejection is a bug in TCC. > Fixed in mob. Confirmed, awesome, thanks! - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] ll-bitfield test on i386-linux
Hello grischka, parts of your last patch: * tcctest.c: remove outdated limitation for ll-bitfield test It always worked, there is no reason why it should not work in future. That's not true. The comment I've put there tried to explain it: -#ifndef __i386__ -/* on i386 we don't correctly support long long bit-fields. - The bitfields can straddle long long boundaries (at least with - GCC bitfield layout) and code generation isn't prepared for this - (would have to work with two words in that case). */ -/* bit sizes below must be bigger than 32 since GCC doesn't allow - long-long bitfields whose size is not bigger than int */ Note the reference to GCC bitfield layout. That (or PCC layout if you will) makes it so that the code generation of TCC can't cope with it (and never could). That's the default on linux systems (not on windows, though), so accordingly the test is now broken: --- test.ref2017-05-07 22:18:06.0 +0200 +++ test.out3 2017-05-07 22:18:06.0 +0200 @@ -378,7 +378,7 @@ 121 121 st1.f1 == -1 st1.f2 == -1 -4886718345 4026531841 120 +4886718345 4157519691776 536871032 ... Note, only on i386-linux (on windows and x86-64 it works). Let me know if I should just reinstate the ifdef or amend it with "&& defined(__linux__)". It's not so superlikely that I come around fixing code generation for this case until release of 0.9.27 (or at all, my interest in i386 is not very pronounced :) ). Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
[Tinycc-devel] tiny bit of lint
Esteemed tinycc maintainers - One of my hobbies is turning up the C compiler warning level in projects I'm interested in, and seeing what lint shows up. Tinycc is really pretty clean. Using gcc's -Wextra, I found 17 "unused parameter", which could be addressed by bloating the source code a bit (casting to void), and with no consequence on the binary. If anyone else thought that would be an improvement, I'd be happy to write and submit a patch. Using gcc's -Wextra, I found 23 "missing initializer for field", all generated by macros in x86_64-asm.h. I would not be able to test any attempt to improve that situation, so I'll leave it alone. Using gcc's -Wwrite-strings, I found one simple lack-of-const in tcctools.c, patch attached. The patch has zero effect on the code's functionality. That patch also adds "undef strict-prototypes write-strings" to the list of warning flags that will be used if present. I'm a fan of using the writer/editor paradigm, so I won't actually commit this to mob myself. I encourage someone in-tune with community values to put on their editor's hat, double-check that my patch makes sense and doesn't break anything, and then commit it or suggest changes. - Larry diff --git a/configure b/configure index 4182f9a..2327929 100755 --- a/configure +++ b/configure @@ -374,7 +374,7 @@ fi # a final configuration tuning $cc -v --help > cc_help.txt 2>&1 -W_OPTIONS="declaration-after-statement" +W_OPTIONS="declaration-after-statement undef strict-prototypes write-strings" for i in $W_OPTIONS; do O_PRESENT="$(grep -- -W$i cc_help.txt)" if test -n "$O_PRESENT"; then CFLAGS="$CFLAGS -W$i"; fi diff --git a/tcctools.c b/tcctools.c index 21aa2a7..ac6850c 100644 --- a/tcctools.c +++ b/tcctools.c @@ -101,7 +101,7 @@ ST_FUNC int tcc_tool_ar(TCCState *s1, int argc, char **argv) char tfile[260], stmp[20]; char *file, *name; int ret = 2; -char *ops_conflict = "habdioptxN"; // unsupported but destructive if ignored. +const char *ops_conflict = "habdioptxN"; // unsupported but destructive if ignored. int verbose = 0; i_lib = 0; i_obj = 0; // will hold the index of the lib and first obj ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tiny bit of lint
Hi, On Sun, 7 May 2017, Larry Doolittle wrote: Using gcc's -Wextra, I found 17 "unused parameter", which could be addressed by bloating the source code a bit (casting to void), and with no consequence on the binary. If anyone else thought that would be an improvement, I'd be happy to write and submit a patch. Some of those are public lib functions, where the parameter that's right now unused could conceivably be used in the future, so there it'd be appropriate to silence the warning. Some of them are internal and it's probably better if the unused parameter simply be removed. Some of them are functions with multiple implementations in different backends, where some do and others don't use the parameter, so there again it would have to be silenced. If the silencing really should happen (e.g. by void casting, as you say) I have no big opinion on. I'd like to look at the possible cleanup for internal functions first, though. Using gcc's -Wextra, I found 23 "missing initializer for field", all generated by macros in x86_64-asm.h. I would not be able to test any attempt to improve that situation, so I'll leave it alone. Just fixed in mob. This warning is borderline useless IMHO, but silencing it didn't require uglification, so I've done it. Using gcc's -Wwrite-strings, I found one simple lack-of-const in tcctools.c, patch attached. The patch has zero effect on the code's functionality. That patch also adds "undef strict-prototypes write-strings" to the list of warning flags that will be used if present. IMO: push to mob. Ciao, Michael. ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tiny bit of lint
Hi Larry, I share this hobby with you but only with my own projects. If you like to chase warnings in C, I invite you to forget those 'chicken' checks and to move to something stronger such as (from easier to stronger): * clang and --analyze * VC++ -analyse * smatch that helped to find ~3000 Linux kernel bugs * splint which is my favorite and much more parano that you can imagine in your dreams (or nightmares) => http://www.splint.org/ splint helped me to find real bugs hard to catch. Using splint is a sport. It makes you feel you are a C noob. I never use splint on projects that I don't own .. unless I'm ready to stop using them :o)) -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Larry Doolittle Sent: lundi 8 mai 2017 05:13 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] tiny bit of lint Esteemed tinycc maintainers - One of my hobbies is turning up the C compiler warning level in projects I'm interested in, and seeing what lint shows up. Tinycc is really pretty clean. Using gcc's -Wextra, I found 17 "unused parameter", which could be addressed by bloating the source code a bit (casting to void), and with no consequence on the binary. If anyone else thought that would be an improvement, I'd be happy to write and submit a patch. Using gcc's -Wextra, I found 23 "missing initializer for field", all generated by macros in x86_64-asm.h. I would not be able to test any attempt to improve that situation, so I'll leave it alone. Using gcc's -Wwrite-strings, I found one simple lack-of-const in tcctools.c, patch attached. The patch has zero effect on the code's functionality. That patch also adds "undef strict-prototypes write-strings" to the list of warning flags that will be used if present. I'm a fan of using the writer/editor paradigm, so I won't actually commit this to mob myself. I encourage someone in-tune with community values to put on their editor's hat, double-check that my patch makes sense and doesn't break anything, and then commit it or suggest changes. - Larry ___ Tinycc-devel mailing list Tinycc-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/tinycc-devel
Re: [Tinycc-devel] tiny bit of lint
Just to give you an example, trying splint only on x86_64-gen.c, I get > 2000 of warnings!! Something like: tcc.h: (in function is_space) tcc.h:1244:12: Operands of == have incompatible types (int, char): ch == ' ' A character constant is used as an int. Use +charintliteral to allow character constants to be used as ints. (This is safe since the actual type of a char constant is int.) tcc.h:1244:25: Operands of == have incompatible types (int, char): ch == '\t' arm64-gen.c:49:31: Initializer block for reg_classes has 28 elements, but declared as int [25]: 0x0001 | RC_R(0), 0x0001 | RC_R(1), 0x0001 | RC_R(2), 0x0001 | RC_R(3), 0x0001 | RC_R(4), 0x0001 | RC_R(5), 0x0001 | RC_R(6), 0x0001 | RC_R(7), 0x0001 | RC_R(8), 0x0001 | RC_R(9), 0x0001 | RC_R(10), 0x0001 | RC_R(11), 0x0001 | RC_R(12), 0x0001 | RC_R(13), 0x0001 | RC_R(14), 0x0001 | RC_R(15), 0x0001 | RC_R(16), 0x0001 | RC_R(17), 0x0001 | RC_R(18), RC_R30, 0x0002 | RC_F(0), 0x0002 | RC_F(1), 0x0002 | RC_F(2), 0x0002 | RC_F(3), 0x0002 | RC_F(4), 0x0002 | RC_F(5), 0x0002 | RC_F(6), 0x0002 | RC_F(7) Initializer block contains more elements than the size of a declared array. arm64-gen.c:300:30: Left operand of << may be negative (int): bas << 5 -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Christian Jullien Sent: lundi 8 mai 2017 07:48 To: tinycc-devel@nongnu.org Subject: Re: [Tinycc-devel] tiny bit of lint Hi Larry, I share this hobby with you but only with my own projects. If you like to chase warnings in C, I invite you to forget those 'chicken' checks and to move to something stronger such as (from easier to stronger): * clang and --analyze * VC++ -analyse * smatch that helped to find ~3000 Linux kernel bugs * splint which is my favorite and much more parano that you can imagine in your dreams (or nightmares) => http://www.splint.org/ splint helped me to find real bugs hard to catch. Using splint is a sport. It makes you feel you are a C noob. I never use splint on projects that I don't own .. unless I'm ready to stop using them :o)) -Original Message- From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On Behalf Of Larry Doolittle Sent: lundi 8 mai 2017 05:13 To: tinycc-devel@nongnu.org Subject: [Tinycc-devel] tiny bit of lint Esteemed tinycc maintainers - One of my hobbies is turning up the C compiler warning level in projects I'm interested in, and seeing what lint shows up. Tinycc is really pretty clean. Using gcc's -Wextra, I found 17 "unused parameter", which could be addressed by bloating the source code a bit (casting to void), and with no consequence on the binary. If anyone else thought that would be an improvement, I'd be happy to write and submit a patch. Using gcc's -Wextra, I found 23 "missing initializer for field", all generated by macros in x86_64-asm.h. I would not be able to test any attempt to improve that situation, so I'll leave it alone. Using gcc's -Wwrite-strings, I found one simple lack-of-const in tcctools.c, patch attached. The patch has zero effect on the code's functionality. That patch also adds "undef strict-prototypes write-strings" to the list of warning flags that will be used if present. I'm a fan of using the writer/editor paradigm, so I won't actually commit this to mob myself. I encourage someone in-tune with community values to put on their editor's hat, double-check that my patch makes sense and doesn't break anything, and then commit it or suggest changes. - Larry ___ 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
