Re: [Tinycc-devel] A Patch for -dumpmachine Option

[Christian Jullien]

I don't know if your patch will reach mob or not but, if it does, IMHO, to be 
useful, the output string should match what gcc/clang currently reports.

For example:

RPi 32bit reports:
$ gcc -dumpmachine
arm-linux-gnueabihf

RPi 64bit reports:
$ gcc -dumpmachine
aarch64-linux-gnu

Windows reports:
gcc -dumpmachine
x86_64-pc-cygwin

or

clang -dumpmachine
x86_64-pc-windows-msvc

macOS:
jullien@mobley:~ $ clang -dumpmachine
arm64-apple-darwin21.4.0
jullien@mobley:~ $ clang -arch x86_64 -dumpmachine
x86_64-apple-darwin21.4.0

etc...

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Ziyao
Sent: Thursday, March 24, 2022 11:36
To: Tinycc-devel@nongnu.org
Subject: [Tinycc-devel] A Patch for -dumpmachine Option

Hi list,

I have made a small patch which adds option "-dumpmachine" support to
TinyCC.This option is widely supported by both gcc and clang.Some configure
scripts detect the platform information by passing this option to the
C compiler,such as musl libc.

And by the way,what is the proper way to contribute? Just send patches to
this maillist or what?Should I send a normal patch or formatted patch?
Thanks for answering.

(To avoid messing the plaintext mail readers up,I add my patch to the bottom
of this mail.)

Cheers,
Ziyao

--

diff --git a/libtcc.c b/libtcc.c
index b6dbb01..6e5cf17 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1456,6 +1456,7 @@ enum {
 TCC_OPTION_g,
 TCC_OPTION_c,
 TCC_OPTION_dumpversion,
+TCC_OPTION_DUMPMACHINE,
 TCC_OPTION_d,
 TCC_OPTION_static,
 TCC_OPTION_std,
@@ -1488,7 +1489,7 @@ enum {
 TCC_OPTION_MMD,
 TCC_OPTION_x,
 TCC_OPTION_ar,
-TCC_OPTION_impdef,
+TCC_OPTION_impdef
 };
 
 #define TCC_OPTION_HAS_ARG 0x0001
@@ -1518,6 +1519,7 @@ static const TCCOption tcc_options[] = {
 { "g", TCC_OPTION_g, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "c", TCC_OPTION_c, 0 },
 { "dumpversion", TCC_OPTION_dumpversion, 0},
+{ "dumpmachine", TCC_OPTION_DUMPMACHINE , 0 },
 { "d", TCC_OPTION_d, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "static", TCC_OPTION_static, 0 },
 { "std", TCC_OPTION_std, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
@@ -1952,6 +1954,8 @@ reparse:
 printf ("%s\n", TCC_VERSION);
 exit(0);
 break;
+case TCC_OPTION_DUMPMACHINE:
+return OPT_DUMPMACHINE;
 case TCC_OPTION_x:
 x = 0;
 if (*optarg == 'c')
diff --git a/tcc.c b/tcc.c
index 42a251b..ed9c143 100644
--- a/tcc.c
+++ b/tcc.c
@@ -95,6 +95,7 @@ static const char help2[] =
 "  -isystem dir  add 'dir' to system include path\n"
 "  -static   link to static libraries (not 
recommended)\n"
 "  -dumpversion  print version\n"
+"  -dumpmachine  print platform information\n"
 "  -print-search-dirsprint search paths\n"
 "  -dt   with -run/-E: auto-define 'test_...' 
macros\n"
 "Ignored options:\n"
@@ -289,6 +290,47 @@ redo:
 return 0;
 ++opt;
 }
+
+if (opt == OPT_DUMPMACHINE) {
+fputs(
+#ifdef TCC_TARGET_I386
+"i386"
+#elif defined TCC_TARGET_X86_64
+"x86_64"
+#elif defined TCC_TARGET_C67
+"c67"
+#elif defined TCC_TARGET_ARM
+"arm"
+# ifdef TCC_ARM_EABI
+" eabi"
+#  ifdef TCC_ARM_HARDFLOAT
+"hf"
+#  endif
+# endif
+#elif defined TCC_TARGET_ARM64
+"aarch64"
+#elif defined TCC_TARGET_RISCV64
+"riscv64"
+#endif
+   "-"
+#ifdef TCC_TARGET_PE
+"windows"
+#elif defined(TCC_TARGET_MACHO)
+"darwin"
+#elif TARGETOS_FreeBSD || TARGETOS_FreeBSD_kernel
+"freebsd"
+#elif TARGETOS_OpenBSD
+"openbsd"
+#elif TARGETOS_NetBSD
+"netbsd"
+#else
+"linux"
+#endif
+"-tcc\n",stdout);
+return 0;
+
+}
+
 if (opt == OPT_HELP2) {
 fputs(help2, stdout);
 return 0;
diff --git a/tcc.h b/tcc.h
index 9724848..3812241 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1279,6 +1279,7 @@ ST_FUNC char *tcc_load_text(int fd);
 #define OPT_PRINT_DIRS 4
 #define OPT_AR 5
 #define OPT_IMPDEF 6
+#define OPT_DUMPMACHINE 7
 #define OPT_M32 32
 #define OPT_M64 64


___
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] A Patch for -dumpmachine Option

[Domingo Alvarez Duarte]

Looking at the patch I think that somehow it can be a good idea to 
create a new header/source to hold all (or as much as possible) of the 
platforms machinery in one place instead of spread through everywhere, 
like the functionality of "-dumpmachine" would be on that header/source.


On 24/3/22 11:35, Ziyao wrote:

Hi list,

I have made a small patch which adds option "-dumpmachine" support to
TinyCC.This option is widely supported by both gcc and clang.Some configure
scripts detect the platform information by passing this option to the
C compiler,such as musl libc.

And by the way,what is the proper way to contribute? Just send patches to
this maillist or what?Should I send a normal patch or formatted patch?
Thanks for answering.

(To avoid messing the plaintext mail readers up,I add my patch to the bottom
of this mail.)

Cheers,
Ziyao

--

diff --git a/libtcc.c b/libtcc.c
index b6dbb01..6e5cf17 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1456,6 +1456,7 @@ enum {
  TCC_OPTION_g,
  TCC_OPTION_c,
  TCC_OPTION_dumpversion,
+TCC_OPTION_DUMPMACHINE,
  TCC_OPTION_d,
  TCC_OPTION_static,
  TCC_OPTION_std,
@@ -1488,7 +1489,7 @@ enum {
  TCC_OPTION_MMD,
  TCC_OPTION_x,
  TCC_OPTION_ar,
-TCC_OPTION_impdef,
+TCC_OPTION_impdef
  };
  
  #define TCC_OPTION_HAS_ARG 0x0001

@@ -1518,6 +1519,7 @@ static const TCCOption tcc_options[] = {
  { "g", TCC_OPTION_g, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
  { "c", TCC_OPTION_c, 0 },
  { "dumpversion", TCC_OPTION_dumpversion, 0},
+{ "dumpmachine", TCC_OPTION_DUMPMACHINE , 0 },
  { "d", TCC_OPTION_d, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
  { "static", TCC_OPTION_static, 0 },
  { "std", TCC_OPTION_std, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
@@ -1952,6 +1954,8 @@ reparse:
  printf ("%s\n", TCC_VERSION);
  exit(0);
  break;
+case TCC_OPTION_DUMPMACHINE:
+return OPT_DUMPMACHINE;
  case TCC_OPTION_x:
  x = 0;
  if (*optarg == 'c')
diff --git a/tcc.c b/tcc.c
index 42a251b..ed9c143 100644
--- a/tcc.c
+++ b/tcc.c
@@ -95,6 +95,7 @@ static const char help2[] =
  "  -isystem dir  add 'dir' to system include path\n"
  "  -static   link to static libraries (not 
recommended)\n"
  "  -dumpversion  print version\n"
+"  -dumpmachine  print platform information\n"
  "  -print-search-dirsprint search paths\n"
  "  -dt   with -run/-E: auto-define 'test_...' 
macros\n"
  "Ignored options:\n"
@@ -289,6 +290,47 @@ redo:
  return 0;
  ++opt;
  }
+
+if (opt == OPT_DUMPMACHINE) {
+fputs(
+#ifdef TCC_TARGET_I386
+"i386"
+#elif defined TCC_TARGET_X86_64
+"x86_64"
+#elif defined TCC_TARGET_C67
+"c67"
+#elif defined TCC_TARGET_ARM
+"arm"
+# ifdef TCC_ARM_EABI
+" eabi"
+#  ifdef TCC_ARM_HARDFLOAT
+"hf"
+#  endif
+# endif
+#elif defined TCC_TARGET_ARM64
+"aarch64"
+#elif defined TCC_TARGET_RISCV64
+"riscv64"
+#endif
+   "-"
+#ifdef TCC_TARGET_PE
+"windows"
+#elif defined(TCC_TARGET_MACHO)
+"darwin"
+#elif TARGETOS_FreeBSD || TARGETOS_FreeBSD_kernel
+"freebsd"
+#elif TARGETOS_OpenBSD
+"openbsd"
+#elif TARGETOS_NetBSD
+"netbsd"
+#else
+"linux"
+#endif
+"-tcc\n",stdout);
+return 0;
+
+}
+
  if (opt == OPT_HELP2) {
  fputs(help2, stdout);
  return 0;
diff --git a/tcc.h b/tcc.h
index 9724848..3812241 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1279,6 +1279,7 @@ ST_FUNC char *tcc_load_text(int fd);
  #define OPT_PRINT_DIRS 4
  #define OPT_AR 5
  #define OPT_IMPDEF 6
+#define OPT_DUMPMACHINE 7
  #define OPT_M32 32
  #define OPT_M64 64


___
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] A Patch for -dumpmachine Option

[Ziyao]

Hi list,

I have made a small patch which adds option "-dumpmachine" support to
TinyCC.This option is widely supported by both gcc and clang.Some configure
scripts detect the platform information by passing this option to the
C compiler,such as musl libc.

And by the way,what is the proper way to contribute? Just send patches to
this maillist or what?Should I send a normal patch or formatted patch?
Thanks for answering.

(To avoid messing the plaintext mail readers up,I add my patch to the bottom
of this mail.)

Cheers,
Ziyao

--

diff --git a/libtcc.c b/libtcc.c
index b6dbb01..6e5cf17 100644
--- a/libtcc.c
+++ b/libtcc.c
@@ -1456,6 +1456,7 @@ enum {
 TCC_OPTION_g,
 TCC_OPTION_c,
 TCC_OPTION_dumpversion,
+TCC_OPTION_DUMPMACHINE,
 TCC_OPTION_d,
 TCC_OPTION_static,
 TCC_OPTION_std,
@@ -1488,7 +1489,7 @@ enum {
 TCC_OPTION_MMD,
 TCC_OPTION_x,
 TCC_OPTION_ar,
-TCC_OPTION_impdef,
+TCC_OPTION_impdef
 };
 
 #define TCC_OPTION_HAS_ARG 0x0001
@@ -1518,6 +1519,7 @@ static const TCCOption tcc_options[] = {
 { "g", TCC_OPTION_g, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "c", TCC_OPTION_c, 0 },
 { "dumpversion", TCC_OPTION_dumpversion, 0},
+{ "dumpmachine", TCC_OPTION_DUMPMACHINE , 0 },
 { "d", TCC_OPTION_d, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
 { "static", TCC_OPTION_static, 0 },
 { "std", TCC_OPTION_std, TCC_OPTION_HAS_ARG | TCC_OPTION_NOSEP },
@@ -1952,6 +1954,8 @@ reparse:
 printf ("%s\n", TCC_VERSION);
 exit(0);
 break;
+case TCC_OPTION_DUMPMACHINE:
+return OPT_DUMPMACHINE;
 case TCC_OPTION_x:
 x = 0;
 if (*optarg == 'c')
diff --git a/tcc.c b/tcc.c
index 42a251b..ed9c143 100644
--- a/tcc.c
+++ b/tcc.c
@@ -95,6 +95,7 @@ static const char help2[] =
 "  -isystem dir  add 'dir' to system include path\n"
 "  -static   link to static libraries (not 
recommended)\n"
 "  -dumpversion  print version\n"
+"  -dumpmachine  print platform information\n"
 "  -print-search-dirsprint search paths\n"
 "  -dt   with -run/-E: auto-define 'test_...' 
macros\n"
 "Ignored options:\n"
@@ -289,6 +290,47 @@ redo:
 return 0;
 ++opt;
 }
+
+if (opt == OPT_DUMPMACHINE) {
+fputs(
+#ifdef TCC_TARGET_I386
+"i386"
+#elif defined TCC_TARGET_X86_64
+"x86_64"
+#elif defined TCC_TARGET_C67
+"c67"
+#elif defined TCC_TARGET_ARM
+"arm"
+# ifdef TCC_ARM_EABI
+" eabi"
+#  ifdef TCC_ARM_HARDFLOAT
+"hf"
+#  endif
+# endif
+#elif defined TCC_TARGET_ARM64
+"aarch64"
+#elif defined TCC_TARGET_RISCV64
+"riscv64"
+#endif
+   "-"
+#ifdef TCC_TARGET_PE
+"windows"
+#elif defined(TCC_TARGET_MACHO)
+"darwin"
+#elif TARGETOS_FreeBSD || TARGETOS_FreeBSD_kernel
+"freebsd"
+#elif TARGETOS_OpenBSD
+"openbsd"
+#elif TARGETOS_NetBSD
+"netbsd"
+#else
+"linux"
+#endif
+"-tcc\n",stdout);
+return 0;
+
+}
+
 if (opt == OPT_HELP2) {
 fputs(help2, stdout);
 return 0;
diff --git a/tcc.h b/tcc.h
index 9724848..3812241 100644
--- a/tcc.h
+++ b/tcc.h
@@ -1279,6 +1279,7 @@ ST_FUNC char *tcc_load_text(int fd);
 #define OPT_PRINT_DIRS 4
 #define OPT_AR 5
 #define OPT_IMPDEF 6
+#define OPT_DUMPMACHINE 7
 #define OPT_M32 32
 #define OPT_M64 64


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

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[Christian Jullien]

Sorry but it was supposed to be a private email.

I asked David if he thinks the latest FreeBSD patch is ready to be committed.
IMHO it clearly improves all FreeBSD ports.

Sorry again for this French message.

C.


-Original Message-
From: Christian Jullien [mailto:eli...@orange.fr] 
Sent: Tuesday, February 15, 2022 10:52
To: 'tinycc-devel@nongnu.org'
Subject: RE: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

Bonjour David,

Le dernier patch semble minimal et complet.
Comme tu en es à l'initiative, tu peux le pousser dans mob.

Si Grischka proteste, il n'avait qu'à réagir mais franchement, je ne vois pas 
pourquoi il le ferait.

Bonne journée.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David CARLIER
Sent: Wednesday, February 02, 2022 18:13
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.

Kind regards.
-- Forwarded message -
From: David CARLIER 
Date: Sun, 30 Jan 2022 at 18:35
Subject: Re: [PATCH] freebsd support update proposal
To: 


> new version considering feedbacks. Cheers.

___
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] Fwd: [PATCH] freebsd support update proposal

[Christian Jullien]

Bonjour David,

Le dernier patch semble minimal et complet.
Comme tu en es à l'initiative, tu peux le pousser dans mob.

Si Grischka proteste, il n'avait qu'à réagir mais franchement, je ne vois pas 
pourquoi il le ferait.

Bonne journée.

-Original Message-
From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of David CARLIER
Sent: Wednesday, February 02, 2022 18:13
To: tinycc-devel@nongnu.org
Subject: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.

Kind regards.
-- Forwarded message -
From: David CARLIER 
Date: Sun, 30 Jan 2022 at 18:35
Subject: Re: [PATCH] freebsd support update proposal
To: 


> new version considering feedbacks. Cheers.

___
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] Fwd: [PATCH] freebsd support update proposal

[Christian Jullien]

I think this one is good.

 

Thanks for your review.

 

C.

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Herman ten Brugge via Tinycc-devel
Sent: Wednesday, February 09, 2022 08:14
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

 

On 2/9/22 06:45, Christian Jullien wrote:

Hi Herman,

 

As just tested, your recent patch fixes the __Thread_local issue we have 
otherwise with 

 

I think, the two following patches proposed by David are also needed, wdyt?

 

diff --git a/include/tccdefs.h b/include/tccdefs.h

index 2d42bea..1bef382 100644

--- a/include/tccdefs.h

+++ b/include/tccdefs.h

@@ -91,6 +91,11 @@

# if __SIZEOF_POINTER__ == 8

 /* FIXME, __int128_t is used by setjump */

 #define __int128_t struct { unsigned char _dummy[16] 
__attribute((aligned(16))); }

+#define __SIZEOF_SIZE_T__ 8

+#define __SIZEOF_PTRDIFF_T__ 8

+#else

+#define __SIZEOF_SIZE_T__ 4

+#define __SIZEOF_PTRDIFF_T__ 4

# endif

 #elif defined __FreeBSD_kernel__

diff --git a/lib/bcheck.c b/lib/bcheck.c

index 0379b6e..3f66b1c 100644

--- a/lib/bcheck.c

+++ b/lib/bcheck.c

@@ -226,10 +226,13 @@ typedef struct alloca_list_struct {

#elif defined(__OpenBSD__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_getthrid)

-#elif defined(__FreeBSD__) || defined(__NetBSD__)

+#elif defined(__FreeBSD__)

#define BOUND_TID_TYPE   pid_t

-#define BOUND_GET_TID0

-#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)

+#define BOUND_GET_TIDsyscall (SYS_thr_self)

+#elif defined(__NetBSD__)

+#define BOUND_TID_TYPE   pid_t

+#define BOUND_GET_TIDsyscall (SYS_lwp_self)

+#elif defined(__linux__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_gettid)

#else

 

There is a typo in the netbsd part. See attached corrected patch.
The other parts are ok.

Herman



 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Herman ten Brugge via Tinycc-devel
Sent: Tuesday, February 08, 2022 19:03
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

 

On 2/7/22 10:54, grischka wrote:

David CARLIER wrote: 




Hi if nobody objects, I may apply the last aforementioned patch 
sometime next week. 


Since you asked: 





--- a/tests/tests2/46_grep.c 
+++ b/tests/tests2/46_grep.c 
@@ -14,6 +14,9 @@ 
  * included and reference made to  the  fact  that  reproduction 
  * privileges were granted by DECUS. 
  */ 
+#if defined(__FreeBSD__) 
+#include  
+#endif 
 #include  
 #include  
 #include // tolower() 


- what is this (nobody will know without a comment) 
- sys/cdefs.h is not that a user file should include 
- 46_grep.c looks really "innocent" enough that it should compile 
  OOTB on any C and platform 
- in general, when tests fail, we want the problem be fixed, not the test 

Maybe you can find a better solution, or maybe someone else can... 

-- gr 


I checked the stdio.h file on freebsd 12.2 and 13.0 and see:

.
#ifndef _STDIO_H_ 
#define _STDIO_H_ 

#include 
.

So the file is included in stdio.h for freebsd.
What version of freebsd are you using?

Herman

PS:
I just added a fix for freebsd 13.0 in mob.











Kind regards. 

 

 

 

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

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[Herman ten Brugge via Tinycc-devel]

On 2/9/22 06:45, Christian Jullien wrote:


Hi Herman,

As just tested, your recent patch fixes the __Thread_local issue we 
have otherwise with 


I think, the two following patches proposed by David are also needed, 
wdyt?


diff --git a/include/tccdefs.h b/include/tccdefs.h

index 2d42bea..1bef382 100644

--- a/include/tccdefs.h

+++ b/include/tccdefs.h

@@ -91,6 +91,11 @@

# if __SIZEOF_POINTER__ == 8

/* FIXME, __int128_t is used by setjump */

#define __int128_t struct { unsigned char _dummy[16] 
__attribute((aligned(16))); }


+ #define __SIZEOF_SIZE_T__ 8

+ #define __SIZEOF_PTRDIFF_T__ 8

+#else

+ #define __SIZEOF_SIZE_T__ 4

+ #define __SIZEOF_PTRDIFF_T__ 4

# endif

 #elif defined __FreeBSD_kernel__

diff --git a/lib/bcheck.c b/lib/bcheck.c

index 0379b6e..3f66b1c 100644

--- a/lib/bcheck.c

+++ b/lib/bcheck.c

@@ -226,10 +226,13 @@ typedef struct alloca_list_struct {

#elif defined(__OpenBSD__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TID    syscall (SYS_getthrid)

-#elif defined(__FreeBSD__) || defined(__NetBSD__)

+#elif defined(__FreeBSD__)

#define BOUND_TID_TYPE   pid_t

-#define BOUND_GET_TID    0

-#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)


+#define BOUND_GET_TID    syscall (SYS_thr_self)

+#elif defined(__NetBSD__)

+#define BOUND_TID_TYPE   pid_t

+#define BOUND_GET_TID    syscall (SYS_lwp_self)

+#elif defined(__linux__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TID    syscall (SYS_gettid)

#else


There is a typo in the netbsd part. See attached corrected patch.
The other parts are ok.

    Herman


*From:*Tinycc-devel 
[mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] *On Behalf 
Of *Herman ten Brugge via Tinycc-devel

*Sent:* Tuesday, February 08, 2022 19:03
*To:* tinycc-devel@nongnu.org
*Cc:* Herman ten Brugge
*Subject:* Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

On 2/7/22 10:54, grischka wrote:

David CARLIER wrote:

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.


Since you asked:


--- a/tests/tests2/46_grep.c
+++ b/tests/tests2/46_grep.c
@@ -14,6 +14,9 @@
  * included and reference made to  the  fact  that reproduction
  * privileges were granted by DECUS.
  */
+#if defined(__FreeBSD__)
+#include 
+#endif
 #include 
 #include 
 #include     // tolower()


- what is this (nobody will know without a comment)
- sys/cdefs.h is not that a user file should include
- 46_grep.c looks really "innocent" enough that it should compile
  OOTB on any C and platform
- in general, when tests fail, we want the problem be fixed, not
the test

Maybe you can find a better solution, or maybe someone else can...

-- gr


I checked the stdio.h file on freebsd 12.2 and 13.0 and see:

.
#ifndef _STDIO_H_
#define _STDIO_H_

#include 
.

So the file is included in stdio.h for freebsd.
What version of freebsd are you using?

    Herman

PS:
I just added a fix for freebsd 13.0 in mob.





Kind regards.

diff --git a/include/tccdefs.h b/include/tccdefs.h
index 2d42bea..83e3c38 100644
--- a/include/tccdefs.h
+++ b/include/tccdefs.h
@@ -88,9 +88,15 @@
 #define __GNUC_PATCHLEVEL__ 0
 #define __GNUC_STDC_INLINE__ 1
 #define __NO_TLS 1
+#define __RUNETYPE_INTERNAL 1
 # if __SIZEOF_POINTER__ == 8
 /* FIXME, __int128_t is used by setjump */
 #define __int128_t struct { unsigned char _dummy[16] 
__attribute((aligned(16))); }
+#define __SIZEOF_SIZE_T__ 8
+#define __SIZEOF_PTRDIFF_T__ 8
+#else
+#define __SIZEOF_SIZE_T__ 4
+#define __SIZEOF_PTRDIFF_T__ 4
 # endif
 
 #elif defined __FreeBSD_kernel__
diff --git a/lib/bcheck.c b/lib/bcheck.c
index 0379b6e..91b7b12 100644
--- a/lib/bcheck.c
+++ b/lib/bcheck.c
@@ -226,10 +226,13 @@ typedef struct alloca_list_struct {
 #elif defined(__OpenBSD__)
 #define BOUND_TID_TYPE   pid_t
 #define BOUND_GET_TIDsyscall (SYS_getthrid)
-#elif defined(__FreeBSD__) || defined(__NetBSD__)
+#elif defined(__FreeBSD__)
 #define BOUND_TID_TYPE   pid_t
-#define BOUND_GET_TID0
-#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)
+#define BOUND_GET_TIDsyscall (SYS_thr_self)
+#elif defined(__NetBSD__)
+#define BOUND_TID_TYPE   pid_t
+#define BOUND_GET_TIDsyscall (SYS__lwp_self)
+#elif defined(__linux__)
 #define BOUND_TID_TYPE   pid_t
 #define BOUND_GET_TIDsyscall (SYS_gettid)
 #else
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[Christian Jullien]

Hi Herman,

 

As just tested, your recent patch fixes the __Thread_local issue we have 
otherwise with 

 

I think, the two following patches proposed by David are also needed, wdyt?

 

diff --git a/include/tccdefs.h b/include/tccdefs.h

index 2d42bea..1bef382 100644

--- a/include/tccdefs.h

+++ b/include/tccdefs.h

@@ -91,6 +91,11 @@

# if __SIZEOF_POINTER__ == 8

 /* FIXME, __int128_t is used by setjump */

 #define __int128_t struct { unsigned char _dummy[16] 
__attribute((aligned(16))); }

+#define __SIZEOF_SIZE_T__ 8

+#define __SIZEOF_PTRDIFF_T__ 8

+#else

+#define __SIZEOF_SIZE_T__ 4

+#define __SIZEOF_PTRDIFF_T__ 4

# endif

 #elif defined __FreeBSD_kernel__

diff --git a/lib/bcheck.c b/lib/bcheck.c

index 0379b6e..3f66b1c 100644

--- a/lib/bcheck.c

+++ b/lib/bcheck.c

@@ -226,10 +226,13 @@ typedef struct alloca_list_struct {

#elif defined(__OpenBSD__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_getthrid)

-#elif defined(__FreeBSD__) || defined(__NetBSD__)

+#elif defined(__FreeBSD__)

#define BOUND_TID_TYPE   pid_t

-#define BOUND_GET_TID0

-#elif defined(__i386__) || defined(__x86_64__) || defined(__arm__) || 
defined(__aarch64__) || defined(__riscv)

+#define BOUND_GET_TIDsyscall (SYS_thr_self)

+#elif defined(__NetBSD__)

+#define BOUND_TID_TYPE   pid_t

+#define BOUND_GET_TIDsyscall (SYS_lwp_self)

+#elif defined(__linux__)

#define BOUND_TID_TYPE   pid_t

#define BOUND_GET_TIDsyscall (SYS_gettid)

#else

 

 

 

From: Tinycc-devel [mailto:tinycc-devel-bounces+eligis=orange...@nongnu.org] On 
Behalf Of Herman ten Brugge via Tinycc-devel
Sent: Tuesday, February 08, 2022 19:03
To: tinycc-devel@nongnu.org
Cc: Herman ten Brugge
Subject: Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

 

On 2/7/22 10:54, grischka wrote:

David CARLIER wrote: 



Hi if nobody objects, I may apply the last aforementioned patch 
sometime next week. 


Since you asked: 




--- a/tests/tests2/46_grep.c 
+++ b/tests/tests2/46_grep.c 
@@ -14,6 +14,9 @@ 
  * included and reference made to  the  fact  that  reproduction 
  * privileges were granted by DECUS. 
  */ 
+#if defined(__FreeBSD__) 
+#include  
+#endif 
 #include  
 #include  
 #include // tolower() 


- what is this (nobody will know without a comment) 
- sys/cdefs.h is not that a user file should include 
- 46_grep.c looks really "innocent" enough that it should compile 
  OOTB on any C and platform 
- in general, when tests fail, we want the problem be fixed, not the test 

Maybe you can find a better solution, or maybe someone else can... 

-- gr 


I checked the stdio.h file on freebsd 12.2 and 13.0 and see:

.
#ifndef _STDIO_H_ 
#define _STDIO_H_ 

#include 
.

So the file is included in stdio.h for freebsd.
What version of freebsd are you using?

Herman

PS:
I just added a fix for freebsd 13.0 in mob.









Kind regards. 

 

 

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

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[Herman ten Brugge via Tinycc-devel]

On 2/7/22 10:54, grischka wrote:

David CARLIER wrote:

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.


Since you asked:


--- a/tests/tests2/46_grep.c
+++ b/tests/tests2/46_grep.c
@@ -14,6 +14,9 @@
  * included and reference made to  the  fact  that reproduction
  * privileges were granted by DECUS.
  */
+#if defined(__FreeBSD__)
+#include 
+#endif
 #include 
 #include 
 #include     // tolower()


- what is this (nobody will know without a comment)
- sys/cdefs.h is not that a user file should include
- 46_grep.c looks really "innocent" enough that it should compile
  OOTB on any C and platform
- in general, when tests fail, we want the problem be fixed, not the test

Maybe you can find a better solution, or maybe someone else can...

-- gr


I checked the stdio.h file on freebsd 12.2 and 13.0 and see:

.
#ifndef _STDIO_H_
#define _STDIO_H_

#include 
.

So the file is included in stdio.h for freebsd.
What version of freebsd are you using?

    Herman

PS:
I just added a fix for freebsd 13.0 in mob.





Kind regards.



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

Re: [Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[grischka]

David CARLIER wrote:

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.


Since you asked:


--- a/tests/tests2/46_grep.c
+++ b/tests/tests2/46_grep.c
@@ -14,6 +14,9 @@
  * included and reference made to  the  fact  that  reproduction
  * privileges were granted by DECUS.
  */
+#if defined(__FreeBSD__)
+#include 
+#endif
 #include 
 #include 
 #include// tolower()


- what is this (nobody will know without a comment)
- sys/cdefs.h is not that a user file should include
- 46_grep.c looks really "innocent" enough that it should compile
  OOTB on any C and platform
- in general, when tests fail, we want the problem be fixed, not the test

Maybe you can find a better solution, or maybe someone else can...

-- gr



Kind regards.



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

[Tinycc-devel] Fwd: [PATCH] freebsd support update proposal

[David CARLIER]

Hi if nobody objects, I may apply the last aforementioned patch
sometime next week.

Kind regards.
-- Forwarded message -
From: David CARLIER 
Date: Sun, 30 Jan 2022 at 18:35
Subject: Re: [PATCH] freebsd support update proposal
To: 


> new version considering feedbacks. Cheers.

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

Re: [Tinycc-devel] a patch

[Michael B. Smith]

Thank you for the information.

Where is the internals document? ☺

From: avih [mailto:avih...@yahoo.com]
Sent: Tuesday, December 19, 2017 4:09 AM
To: Michael B. Smith; tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] a patch

It's not a matter of validity.

TCC_TARGET_PE is defined while compiling e.g. tcc.c if the resulting tcc
binary generates windows (32, 64, or CE) binaries. This can be either if the
resulting tcc is a "normal" windows compiler, or if it's a cross compiler which
target windows (e.g. runs on linux but creates windows binaries).

_WIN32 is defined when the resulting tcc binary itself is a windows executable
(which doesn't guarantee it's a native windows compiler - it can be a cross
compiler which runs on windows and generates linux binaries).

So if one of _WIN32/TCC_TARGET_PE is defined but the other isn't, it means it's
a cross compiler from/to windows - which should disable -run by making sure
none of the inner tests ever get the chance to define TCC_IS_NATIVE .

On Tuesday, December 19, 2017 3:34 AM, Michael B. Smith 
<mich...@smithcons.com<mailto:mich...@smithcons.com>> wrote:

Forgive me for my ignorance. What targets is TCC_TARGET_PE valid for?

From: Tinycc-devel 
[mailto:tinycc-devel-bounces+michael=theessentialexchange@nongnu.org] On 
Behalf Of avih
Sent: Monday, December 18, 2017 8:15 PM
To: tinycc-devel@nongnu.org<mailto:tinycc-devel@nongnu.org>
Subject: Re: [Tinycc-devel] a patch

I don't think so, or else you'll disable -run on any non-win32 platform.

As far as I can tell, the goal of this condition is to test that it's not
a win32 cross compiler, i.e. either native win32 binary which targets win32, or
not win32 binary and not targeting win32.

On Tuesday, December 19, 2017 2:18 AM, Michael B. Smith 
<mich...@smithcons.com<mailto:mich...@smithcons.com>> wrote:

tcc.h line 153 should be:

#if defined _WIN32 && defined TCC_TARGET_PE

Sorry. I don’t have git set up yet. Working on it.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org<mailto: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] a patch

[Michael B. Smith]

Forgive me for my ignorance. What targets is TCC_TARGET_PE valid for?

From: Tinycc-devel 
[mailto:tinycc-devel-bounces+michael=theessentialexchange@nongnu.org] On 
Behalf Of avih
Sent: Monday, December 18, 2017 8:15 PM
To: tinycc-devel@nongnu.org
Subject: Re: [Tinycc-devel] a patch

I don't think so, or else you'll disable -run on any non-win32 platform.

As far as I can tell, the goal of this condition is to test that it's not
a win32 cross compiler, i.e. either native win32 binary which targets win32, or
not win32 binary and not targeting win32.

On Tuesday, December 19, 2017 2:18 AM, Michael B. Smith 
<mich...@smithcons.com<mailto:mich...@smithcons.com>> wrote:

tcc.h line 153 should be:

#if defined _WIN32 && defined TCC_TARGET_PE

Sorry. I don’t have git set up yet. Working on it.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org<mailto: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] a patch

[avih]

I don't think so, or else you'll disable -run on any non-win32 platform.
As far as I can tell, the goal of this condition is to test that it's not
a win32 cross compiler, i.e. either native win32 binary which targets win32, or
not win32 binary and not targeting win32. 

On Tuesday, December 19, 2017 2:18 AM, Michael B. Smith 
 wrote:
 

  tcc.h line 
153 should be:    #ifdefined_WIN32&_TARGET_PE    Sorry. I don’t have 
git set up yet. Working on it. ___
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] a patch

[Michael B. Smith]

tcc.h line 153 should be:

#if defined _WIN32 && defined TCC_TARGET_PE

Sorry. I don't have git set up yet. Working on it.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] RFC [PATCH] win: libm: fix "unknown constraint 't'", missing fpclassify/round/etc

[Sergey Korshunoff]

Hi avih!
> To address these issues, code which used inline asm with 't' was replaced with
> a C implementation, and the missing __fpclassify functions were added

A patch attached for the "t" issue. It is much faster
Don't throw an asm code away. A C implementation can be as an option
Please test.


win-math-h.patch
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

[Tinycc-devel] RFC [PATCH] win: libm: fix "unknown constraint 't'", missing fpclassify/round/etc

[avih]

I've noticed that for many years now there have been a recurring Windowsrelated 
complaint about "Error: unknown constraint 't'" message, which goes asearly as 
2007, e.g. 
https://lists.nongnu.org/archive/html/tinycc-devel/2007-07/msg00013.html

There appears to be a patch for it (didn't test it), but it seems it was never 
taken:http://lists.gnu.org/archive/html/tinycc-devel/2014-08/msg00024.html
I decided to approach it from a different direction, and while at it also add 3 
missing libmfunctions. Following these changes, at least 2 medium sized 
projects which tcc couldn'tbuilt on windows (using the windows official 
distribution package), now build and appearto be working well (mujs and 
Duktape).
If there are no objections, I'll push that to the mob branch soon. The patch is 
attached,and that's the commit 
message:--
win: libm: fix "unknown constraint 't'", missing  fpclassify/round/etc

Some libm functions were broken at win32/include/math.h in few ways:

1. Unknown constraint 't': a similar piece of code was used in several inline
   functions at math.h (from mingw), and currently the tcc asm doesn't support
   it. This broke __fpclassifyl, __isnan* and __signbit*, and indirectly broke
   the macros fpclassify, isfinite, isinf, isnan, isnormal and signbit.

2. Even if 't' was supported by tcc's asm, there were no definitions for
   __fpclassify and __fpclassifyf, therefore breaking the macro fpclassify.
   Newer mingw(w64) math.h doesn't have this issue, but still uses 't' in asm.

3. Other than the above, some common libm functions werere not implemented
   anywhere in the tcc Windows distribution package - mainly fmin/fmax/round.
   Newer mingw(64) math.h stil doesn't include these implementations.

To address these issues, code which used inline asm with 't' was replaced with
a C implementation, and the missing __fpclassify functions were added.

The code is mostly taken from MUSL rs-1.0 (MIT) [*], and is placed as inline
functions at win32/include/tcc/tcc_libm.h, which is now included from math.h,
and is also copied to the win32 install target.

Future enhancements:
- Support 't' contraint in asm. Newer mingw headers still use it, and it would
  make future porting of mingw headers easier.
- Enumerate the still-missing libm functions (if there are such) and add missing
  implementations. Most should be simple and will add good value to tcc.
- Possibly move the code at tcc/tcc_libm.h to a C file and create an actual
  libm.a library, or just create a dummy libm. For build procedures which expect
  libm, this could allow to complete successfully, assuming no yet-unimplemented
  functions are used.
- Add some tests for common libm functions.

[*] - http://git.musl-libc.org/cgit/musl/tree/src/math?h=rs-1.0
    - MUSL's license: http://git.musl-libc.org/cgit/musl/tree/COPYRIGHT?h=rs-1.0
From 67b64295332c11641ccdcd582edbb040a5e528e0 Mon Sep 17 00:00:00 2001
From: "Avi Halachmi (:avih)" 
Date: Sun, 1 Nov 2015 18:47:03 +0200
Subject: [PATCH] win: libm: fix "unknown constraint 't'", missing
 fpclassify/round/etc

Some libm functions were broken at win32/include/math.h in few ways:

1. Unknown constraint 't': a similar piece of code was used in several inline
   functions at math.h (from mingw), and currently the tcc asm doesn't support
   it. This broke __fpclassifyl, __isnan* and __signbit*, and indirectly broke
   the macros fpclassify, isfinite, isinf, isnan, isnormal and signbit.

2. Even if 't' was supported by tcc's asm, there were no definitions for
   __fpclassify and __fpclassifyf, therefore breaking the macro fpclassify.
   Newer mingw(w64) math.h doesn't have this issue, but still uses 't' in asm.

3. Other than the above, some common libm functions werere not implemented
   anywhere in the tcc Windows distribution package - mainly fmin/fmax/round.
   Newer mingw(64) math.h stil doesn't include these implementations.

To address these issues, code which used inline asm with 't' was replaced with
a C implementation, the missing __fpclassify functions were added, as well as
fmin/fmax/round and their variants.

The code is mostly taken from MUSL rs-1.0 (MIT) [*], and is placed as inline
functions at win32/include/tcc/tcc_libm.h, which is now included from math.h,
and is also copied to the win32 install target.

Future enhancements:
- Support 't' contraint in asm. Newer mingw headers still use it, and it would
  make future porting of mingw headers easier.
- Enumerate the still-missing libm functions (if there are such) and add missing
  implementations. Most should be simple and will add good value to tcc.
- Possibly move the code at tcc/tcc_libm.h to a C file and create an actual
  libm.a library, or just create a dummy libm. For build procedures which expect
  libm, this could allow to complete successfully, assuming no yet-unimplemented
  functions are used.
- Add some tests for common libm functions.

[*] - 

Re: [Tinycc-devel] [BUG] [PATCH] v2, tcc and INT64: wrong result of comparison (a test included)

[Sergey Korshunoff]

This is version 2 of the patch. A changed lines are

-if (is_signed  (-n ==  0x8000ULL))
+   if (is_signed  (n  0x8000ULL))
+   is_long_long = 1;
+
+   if (is_signed  (n  0x8000ULL))
+tcc_error(long long constant overflow);

This is because a scanned constant is positive (a sign will be applied latter)
If a sign bit is used by constant, then a bigger size is needed to
store such constant.


2015-01-05 17:47 GMT+03:00, Sergey Korshunoff sey...@gmail.com:
 tccpp(parse_number): changes to detect a constat type correctly.
 This patch is tested with a nimrod compiler build process. All works.

 2015-01-05 2:03 GMT+03:00, Sergey Korshunoff sey...@gmail.com:
 There is another approach: assume the constant is negative by default.
 This is the method used in nimrod to scan a constants:
 lib/pure/parseutils.nim(rawparse)

 proc rawParseInt(s: string, b: var BiggestInt, start: int = 0): int =
 var
 sign: BiggestInt = -1 # minus by defaul
 i = start
   if s[i] == '+': inc(i)
   elif s[i] == '-':
 inc(i)
 sign = 1
   if s[i] in {'0'..'9'}:
 b = 0
 while s[i] in {'0'..'9'}:
   b = b * 10 - (ord(s[i]) - ord('0')) #!  the point
   inc(i)
   while s[i] == '_': inc(i) # underscores are allowed and ignored
 b = b * sign
 result = i - start


 Sun, 04 Jan 2015 16:51 +, Thomas Preud'homme robo...@celest.fr:
 Le dimanche 4 janvier 2015, 19:18:34 Sergey Korshunoff a écrit :
 By replacing a -2147483648 with a -2147483647 I can succesfully build
 a working nim compiler. But this is not so good...

 The bug is in tccpp.c parse_number. The function tries to guess what
 should
 be
 the size and sign of the litteral before parsing the suffix (which might
 not

 exist).

 /* XXX: not exactly ANSI compliant */
 if ((n  0xLL) != 0) {
 if ((n  63) != 0)
 tok = TOK_CULLONG;
 else
 tok = TOK_CLLONG;
 } else if (n  0x7fff) {
 tok = TOK_CUINT;
 } else {
 tok = TOK_CINT;
 }

 In your case it will pass in the first else if and set tok to TOK_CUINT.
 So
 far
 so good.

 Then it will parse the suffix and when it sees the second L it does
 this:

 if (tok == TOK_CINT)
 tok = TOK_CLLONG;
 else if (tok == TOK_CUINT)
 tok = TOK_CULLONG;

 So here it will set the value to TOK_CULLONG while it should set it to
 TOK_CLLONG and warn if the value is too big.

 My feeling is that the automatic guess for the size and sign should be
 done

 after trying to look for a suffix.

 The algorithm would be something like:

 1) Set tok to TOK_CINT and suffix_found to false.
 2) Then look for a L or U suffix with unchanged code except for setting
 a
 suffix_found variable if any such suffix is found.
 3) Then if suffix_found is false try automatic detection, otherwise warn
 of

 overflow and possibly process the overflow (what does GCC does in this
 case?) Be
 careful about the sign when checking for overflow.

 Do you want to take a stab at it?

 Best regards,

 Thomas





2015-01-05-3-tccpp-parse-number.patch
Description: Binary data
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Small patch

[Thomas Preud'homme]

Le jeudi 31 janvier 2013 02:07:36, Domingo Alvarez Duarte a écrit :
 Also here :
 
 static void asm_expr_logic(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;
 
 asm_expr_prod(s1, pe);
 for(;;) {
 op = tok;
 if (op != ''  op != '|'  op != '^')
 break;
 next();
 asm_expr_prod(s1, e2);
 if (pe-sym || e2.sym)
 tcc_error(invalid operation with label);
 switch(op) {
 case '':
 pe-v = e2.v;
 break;
 case '|':
 pe-v |= e2.v;
 break;
 default:
 case '^':  ///what this case
 after default mean 
 pe-v ^= e2.v;
 break;
 }
 }
 }

Looks weird indeed but I am reluctant to change it when I don't know why it 
was done this way in the first place. Since the file was commited in one go, I 
can't see if this result from a mistake or if it was intentional. We can 
consider changing this and the other such example right after the release.

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] Small patch

[Thomas Preud'homme]

Le jeudi 31 janvier 2013 00:08:19, Ivo van Poorten a écrit :
 Error:
 
 $ ./configure --cc=tcc
 Binary  directory   /usr/local/bin
 TinyCC directory/usr/local/lib/tcc
 Library directory   /usr/local/lib
 Include directory   /usr/local/include
 Manual directory/usr/local/share/man
 Info directory  /usr/local/share/info
 Doc directory   /usr/local/share/doc/tcc
 Target root prefix
 Source path  /home/ivo/git/tinycc
 C compiler   tcc
 Target OSLinux
 CPU  x86
 Big Endian   no
 gprof enabledno
 cross compilers  no
 use libgcc   no
 Creating config.mak and config.h
 $ make
 [..snip..]
 gcc -c lib/bcheck.c -o bcheck.o -I. -I/home/ivo/git/tinycc -Wall -g -O2
 -mpreferred-stack-boundary=2 -m386 -malign-functions=0 -m32 cc1: error:
 unrecognized command line option -m386
 
 
 88888888
 
 diff --git a/Makefile b/Makefile
 index d257464..0333ebe 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -232,7 +232,7 @@ libtcc1.a : FORCE
  lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
 @$(MAKE) -C lib cross TARGET=$*
  bcheck.o : lib/bcheck.c
 -   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 +   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  FORCE:
 
  # install

Unfortunetely it still breaks because of a wrong detection of GCC_MAJOR. 
Because the test to determine the major version number of gcc fails, GCC_MAJOR 
is set to 2. I made the following patch but I'm still not sure how to handle 
flags when the compiler is not gcc.

Shall no flag be set and the project fail because of missing -I for instance?

I don't have a clear idea for now.

Best regards,

Thomas
diff --git a/Makefile b/Makefile
index d6a0a28..ce37592 100644
--- a/Makefile
+++ b/Makefile
@@ -13,6 +13,7 @@ CFLAGS_P=$(CFLAGS) -pg -static
 LIBS_P=
 LDFLAGS_P=$(LDFLAGS)
 
+ifdef GCC_MAJOR
 ifneq ($(GCC_MAJOR),2)
 CFLAGS+=-fno-strict-aliasing
 ifneq ($(GCC_MAJOR),3)
@@ -30,6 +31,7 @@ CFLAGS+=-march=i386 -falign-functions=0
 endif
 endif
 endif
+endif
 
 ifdef CONFIG_WIN64
 CONFIG_WIN32=yes
@@ -234,7 +236,7 @@ libtcc1.a : FORCE
 lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
 	@$(MAKE) -C lib cross TARGET=$*
 bcheck.o : lib/bcheck.c
-	gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
+	$(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 FORCE:
 
 # install
diff --git a/configure b/configure
index fa2c97d..289b8ca 100755
--- a/configure
+++ b/configure
@@ -231,6 +231,21 @@ esac
 
 fi
 
+# check compiler is gcc
+cat  $TMPC EOF
+int main(void) {
+#ifdef __GNUC__
+return 0;
+#else
+#error compiler is not gcc
+#endif
+}
+EOF
+
+if $cc -o $TMPO $TMPC 2 /dev/null ; then
+gcc_major=2
+fi
+
 # check gcc version
 cat  $TMPC EOF
 int main(void) {
@@ -242,7 +257,6 @@ return 0;
 }
 EOF
 
-gcc_major=2
 if $cc -o $TMPO $TMPC 2 /dev/null ; then
 gcc_major=3
 fi
@@ -409,11 +423,13 @@ print_var2 CONFIG_TCC_LIBPATHS $tcc_libpaths
 print_var2 CONFIG_TCC_CRTPREFIX $tcc_crtprefix
 print_var2 CONFIG_TCC_ELFINTERP $tcc_elfinterp
 
-echo #define GCC_MAJOR $gcc_major  $TMPH
+if [ x$gcc_major != x ] ; then
+echo #define GCC_MAJOR $gcc_major  $TMPH
+echo GCC_MAJOR=$gcc_major  config.mak
+fi
 
 cat  config.mak EOF
 CC=$cc
-GCC_MAJOR=$gcc_major
 HOST_CC=$host_cc
 AR=$ar
 STRIP=$strip -s -R .comment -R .note


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] Small patch

[Thomas Preud'homme]

Le jeudi 31 janvier 2013 02:19:38, Domingo Alvarez Duarte a écrit :
 Here is some that I found simple to make:
 
 Author: mingodad mingo...@gmail.com  2013-01-31 01:17:50
 Committer: mingodad mingo...@gmail.com  2013-01-31 01:17:50
 Parent: 1b1e7ee1fd2f269872128dc5e8b830bd55dfa80c (Fix cross-compilation
 out-of-tree build)
 Branch: vio_patch
 Follows: release_0_9_25
 Precedes:
 
 Alerts found using Coverity Scan
 
 --- libtcc.c
 ---
 index b0a9b1a..69d9e0d 100644
 @@ -479,8 +479,7 @@ ST_FUNC void put_extern_sym2(Sym *sym, Section
 *section, case TOK_strlen:
  case TOK_strcpy:
  case TOK_alloca:
 -strcpy(buf, __bound_);
 -strcat(buf, name);
 +snprintf(buf, sizeof(buf), __bound_%s, name);
  name = buf;
  break;
  }

strcpy and strcat are C89 and C99 while snprintf is only C99.

 
 --- tccelf.c
 ---
 index a4dee19..479b2fa 100644
 @@ -114,7 +114,7 @@ ST_FUNC int put_elf_sym(Section *s, uplong value,
 unsigned long size,
  if (ELFW(ST_BIND)(info) != STB_LOCAL) {
  /* add another hashing entry */
  nbuckets = base[0];
 -h = elf_hash(name) % nbuckets;
 +h = name ? elf_hash(name) % nbuckets : 0;
  *ptr = base[2 + h];
  base[2 + h] = sym_index;
  base[1]++;

Fixed (see just pushed commits)

 @@ -3052,7 +3052,7 @@ static int ld_add_file_list(TCCState *s1, const char
 *cmd, int as_needed)
  ret = -1;
  goto lib_parse_error;
  }
 -strcpy(libname, filename[1]);
 +snprintf(libname, sizeof(libname), %s, filename[1]);
  libname_to_filename(s1, libname, filename);
  } else if (t != LD_TOK_NAME) {
  tcc_error_noabort(filename expected);

C99

 
 --- tccgen.c
 ---
 index 4300403..e06a932 100644
 @@ -361,6 +361,7 @@ void vpush64(int ty, unsigned long long v)
  CValue cval;
  CType ctype;
  ctype.t = ty;
 +ctype.ref = 0;
  cval.ull = v;
  vsetc(ctype, VT_CONST, cval);
  }
 @@ -1734,6 +1735,7 @@ ST_FUNC void gen_op(int op)
  }
  vswap();
  type1.t = t;
 +type1.ref = 0;
  gen_cast(type1);
  vswap();
  /* special case for shifts and long long: we keep the shift as
 @@ -2717,6 +2719,7 @@ static void struct_decl(CType *type, int u)
  v = anon_sym++;
  }
  type1.t = a;
 +type1.ref = 0;
  /* we put an undefined size for struct/union */
  s = sym_push(v | SYM_STRUCT, type1, 0, -1);
  s-r = 0; /* default alignment is zero as gcc */
 @@ -3396,6 +3399,7 @@ static void gfunc_param_typed(Sym *func, Sym *arg)
  /* default casting : only need to convert float to double */
  if ((vtop-type.t  VT_BTYPE) == VT_FLOAT) {
  type.t = VT_DOUBLE;
 +type.ref = 0;
  gen_cast(type);
  }
  } else if (arg == NULL) {
 @@ -3592,6 +3596,7 @@ ST_FUNC void unary(void)
  if ((vtop-r  (VT_VALMASK | VT_LVAL | VT_SYM)) == VT_CONST) {
  CType boolean;
  boolean.t = VT_BOOL;
 +boolean.ref = 0;
  gen_cast(boolean);
  vtop-c.i = !vtop-c.i;
  } else if ((vtop-r  VT_VALMASK) == VT_CMP)
 @@ -4101,6 +4106,7 @@ static void expr_cond(void)
  CType boolean;
  int c;
  boolean.t = VT_BOOL;
 +boolean.ref = 0;
  vdup();
  gen_cast(boolean);
  c = vtop-c.i;

All fixed.

 @@ -5574,7 +5580,7 @@ ST_FUNC void gen_inline_functions(void)
  str = fn-token_str;
  fn-sym = NULL;
  if (file)
 -strcpy(file-filename, fn-filename);
 +snprintf(file-filename, sizeof(file-filename), %s,
 fn-filename);
  sym-r = VT_SYM | VT_CONST;
  sym-type.t = ~VT_INLINE;

C99


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] Small patch

[Stephan Beal]

On Thu, Jan 31, 2013 at 12:07 PM, Thomas Preud'homme robo...@celest.frwrote:

  -strcpy(buf, __bound_);
  -strcat(buf, name);
  +snprintf(buf, sizeof(buf), __bound_%s, name);


strcpy and strcat are C89 and C99 while snprintf is only C99.


The semantics of the above variants are not the same, are they? strcpy()
and strcat() are both writing to the same address in buf, i.e. strcat is
overwriting what strcpy() copied into buf. So the end result, unless i'm
sorely mistaken, is a copy of the name with the __bound_ prefix. strncat()
is c89, BTW.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Small patch

[Thomas Preud'homme]

Le jeudi 31 janvier 2013 12:34:27, Stephan Beal a écrit :
 On Thu, Jan 31, 2013 at 12:07 PM, Thomas Preud'homme 
robo...@celest.frwrote:
   -strcpy(buf, __bound_);
   -strcat(buf, name);
   +snprintf(buf, sizeof(buf), __bound_%s, name);
 
 strcpy and strcat are C89 and C99 while snprintf is only C99.
 
 
 The semantics of the above variants are not the same, are they? strcpy()
 and strcat() are both writing to the same address in buf, i.e. strcat is
 overwriting what strcpy() copied into buf. So the end result, unless i'm
 sorely mistaken, is a copy of the name with the __bound_ prefix. strncat()
 is c89, BTW.

strcat copy the second argument at the end of the string pointed at by the 
first argument.

So after strcpy you'll have __bound_ and then the strcat will add name at the 
end of this string.

Did I misunderstand what you said?

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] Small patch

[grischka]

Thomas Preud'homme wrote:

 bcheck.o : lib/bcheck.c
-   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
+   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)


Unfortunetely it still breaks because of a wrong detection of GCC_MAJOR. 
Because the test to determine the major version number of gcc fails, GCC_MAJOR 
is set to 2. I made the following patch but I'm still not sure how to handle 
flags when the compiler is not gcc.


Shall no flag be set and the project fail because of missing -I for instance?

I don't have a clear idea for now.


Maybe we should just put bcheck.o into libtcc1.a (and thus make via
the rules of lib/Makefile).  Unless there is a reason why we
shouldn't.


-h = elf_hash(name) % nbuckets;
+h = name ? elf_hash(name) % nbuckets : 0;


This is counterproductive IMO because when you read this you get
the wrong impression that there are cases where name is NULL.
But in fact there is no such case.  So the naive reader is misled,
while the knowledgeable reader must conclude that the writer didn't
know what s/he was doing.


 boolean.t = VT_BOOL;
+boolean.ref = 0;


Also redundant because type.ref is used with type.t = VT_FUNC only.

I'm not completely opposed to make this look more solid but then
such patch should address the problem systematically such that the
code becomes smaller, not bigger.


-parse_btype(btype, ad);
+if (parse_btype(btype, ad))
+expect(type);


Breaks tcc.  Never push without test, in particular not during the
calm down period before release. ;)


 -strcpy(buf, __bound_);
 -strcat(buf, name);
 +snprintf(buf, sizeof(buf), __bound_%s, name);


There are cases where we might want to use pstrcpy instead of strcpy.
This is no such case because __bound_memcpy cannot overflow buf[32].
Same with
pstrcpy(buf, sizeof buf, a.out);
Because a.out cannot overflow buf[1024].

--- grischka


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

Re: [Tinycc-devel] Small patch

[Thomas Preud'homme]

Le jeudi 31 janvier 2013 13:19:59, grischka a écrit :
 Thomas Preud'homme wrote:
   bcheck.o : lib/bcheck.c
  
  -   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  +   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  
  Unfortunetely it still breaks because of a wrong detection of GCC_MAJOR.
  Because the test to determine the major version number of gcc fails,
  GCC_MAJOR is set to 2. I made the following patch but I'm still not sure
  how to handle flags when the compiler is not gcc.
  
  Shall no flag be set and the project fail because of missing -I for
  instance?
  
  I don't have a clear idea for now.
 
 Maybe we should just put bcheck.o into libtcc1.a (and thus make via
 the rules of lib/Makefile).  Unless there is a reason why we
 shouldn't.

Yes but that doesn't change the general assumption that we are compiling tcc 
with gcc. If --cc is specified at configure time, then CFLAGS and CPPFLAGS 
should be set when running make (make CPPFLAGS=foo CFLAGS=bar)

 
  -h = elf_hash(name) % nbuckets;
  +h = name ? elf_hash(name) % nbuckets : 0;
 
 This is counterproductive IMO because when you read this you get
 the wrong impression that there are cases where name is NULL.
 But in fact there is no such case.  So the naive reader is misled,
 while the knowledgeable reader must conclude that the writer didn't
 know what s/he was doing.

Well, the test at the top of the function suggested me name could be NULL. I 
suppose it can't be NULL when the symbol is global or common. What about a 
malformed elf file?

 
   boolean.t = VT_BOOL;
  
  +boolean.ref = 0;
 
 Also redundant because type.ref is used with type.t = VT_FUNC only.
 
 I'm not completely opposed to make this look more solid but then
 such patch should address the problem systematically such that the
 code becomes smaller, not bigger.

Can you develop about what you have in mind?

 
  -parse_btype(btype, ad);
  +if (parse_btype(btype, ad))
  +expect(type);
 
 Breaks tcc.  Never push without test, in particular not during the
 calm down period before release. ;)

Yes, you are absolutely right. I tried on a simple example (where tcc fails to 
issue a warning) and I was obviously wrong. You were right from the beginning, 
I shall stop doing any commits unless a very serious bug is reported and keep 
things for after the release.

 
   -strcpy(buf, __bound_);
   -strcat(buf, name);
   +snprintf(buf, sizeof(buf), __bound_%s, name);
 
 There are cases where we might want to use pstrcpy instead of strcpy.
 This is no such case because __bound_memcpy cannot overflow buf[32].
 Same with
   pstrcpy(buf, sizeof buf, a.out);
 Because a.out cannot overflow buf[1024].

sprintf could be used  then to save some space

 
 --- 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] Small patch

[Domingo Alvarez Duarte]

On Thu, Jan 31, 2013 at 12:19 PM, grischka gris...@gmx.de wrote:



  -h = elf_hash(name) % nbuckets;
 +h = name ? elf_hash(name) % nbuckets : 0;


 This is counterproductive IMO because when you read this you get
 the wrong impression that there are cases where name is NULL.
 But in fact there is no such case.  So the naive reader is misled,
 while the knowledgeable reader must conclude that the writer didn't
 know what s/he was doing.


I totally agree with you !
But look some lines above on this same function !

/* return the symbol number */
ST_FUNC int put_elf_sym(Section *s, uplong value, unsigned long size,
int info, int other, int shndx, const char *name)
{
int name_offset, sym_index;
int nbuckets, h;
ElfW(Sym) *sym;
Section *hs;

sym = section_ptr_add(s, sizeof(ElfW(Sym)));
if (name)
/ This mean
name can be null ?
name_offset = put_elf_str(s-link, name);
else
name_offset = 0;
/* XXX: endianness */
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Small patch

[Domingo Alvarez Duarte]

On Thu, Jan 31, 2013 at 12:36 PM, Thomas Preud'homme robo...@celest.frwrote:

 Le jeudi 31 janvier 2013 13:19:59, grischka a écrit :
 
-strcpy(buf, __bound_);
-strcat(buf, name);
+snprintf(buf, sizeof(buf), __bound_%s, name);
 
  There are cases where we might want to use pstrcpy instead of strcpy.
  This is no such case because __bound_memcpy cannot overflow buf[32].
  Same with
pstrcpy(buf, sizeof buf, a.out);
  Because a.out cannot overflow buf[1024].

 sprintf could be used  then to save some space

 
  --- grischka


Maybe you didn't noticed that snprintf guarantee no buffer overflow while
sprintf doesn't 
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
https://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Small patch

[grischka]

Vincent Lefevre wrote:

On 2013-01-31 10:52:14 +0100, Thomas Preud'homme wrote:

Le jeudi 31 janvier 2013 02:07:36, Domingo Alvarez Duarte a écrit :

switch(op) {
case '':
pe-v = e2.v;
break;
case '|':
pe-v |= e2.v;
break;
default:
case '^':  ///what this case
after default mean 
pe-v ^= e2.v;
break;
}
Looks weird indeed but I am reluctant to change it when I don't know why it 
was done this way in the first place. Since the file was commited in one go, I 
can't see if this result from a mistake or if it was intentional. We can 
consider changing this and the other such example right after the release.


Perhaps there was a default: by default the author forgot to remove.
And as it is probably just useless (if op can only be '', '|' or '^'),
no-one noticed it.


I guess it was to avoid a compiler warning such as
case X not handled in switch

--- grischka


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

Re: [Tinycc-devel] Small patch

[Vincent Lefevre]

On 2013-01-31 13:22:22 +0100, grischka wrote:
 Vincent Lefevre wrote:
 Perhaps there was a default: by default the author forgot to remove.
 And as it is probably just useless (if op can only be '', '|' or '^'),
 no-one noticed it.
 
 I guess it was to avoid a compiler warning such as
   case X not handled in switch

In such a case, a default: at the end with an assertion failure
would have been better.

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

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

Re: [Tinycc-devel] Small patch

[Thomas Preud'homme]

Le jeudi 31 janvier 2013 13:45:28, Domingo Alvarez Duarte a écrit :
 
 Maybe you didn't noticed that snprintf guarantee no buffer overflow while
 sprintf doesn't 

I didn't. Grischka just explained how no overflow can occured so sprintf is 
fine.

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] Small patch

[grischka]

Vincent Lefevre wrote:

On 2013-01-31 13:22:22 +0100, grischka wrote:

Vincent Lefevre wrote:

Perhaps there was a default: by default the author forgot to remove.
And as it is probably just useless (if op can only be '', '|' or '^'),
no-one noticed it.

I guess it was to avoid a compiler warning such as
case X not handled in switch


In such a case, a default: at the end with an assertion failure
would have been better.



No.  An assertion only makes sense to make sure about what we aren't
entirely sure.  In this case we are sure (that default never happens).

--- grischka


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

Re: [Tinycc-devel] Small patch

[grischka]

Thomas Preud'homme wrote:

Maybe we should just put bcheck.o into libtcc1.a (and thus make via
the rules of lib/Makefile).  Unless there is a reason why we
shouldn't.


Yes but that doesn't change the general assumption that we are compiling tcc 
with gcc. If --cc is specified at configure time, then CFLAGS and CPPFLAGS 
should be set when running make (make CPPFLAGS=foo CFLAGS=bar)


Sure, but if you want to solve the --cc=tcc/clang problem then the
question with using what compiler for libtcc1.a needs to be answered,
and also whether it makes sense to treat bcheck.o separately.

Well, the test at the top of the function suggested me name could be NULL. I 
suppose it can't be NULL when the symbol is global or common. What about a 
malformed elf file?


Are you sure that putting an hash link to an not-existing name entry
is the right way to deal with a malformed elf file?


 boolean.t = VT_BOOL;

+boolean.ref = 0;

Also redundant because type.ref is used with type.t = VT_FUNC only.

I'm not completely opposed to make this look more solid but then
such patch should address the problem systematically such that the
code becomes smaller, not bigger.


Can you develop about what you have in mind?


No, I just suspect.  There is mostly always a better way than
to copy  paste equivalent statements into several places, the
more if the statements are altogether logically redundant.


Same with
pstrcpy(buf, sizeof buf, a.out);
Because a.out cannot overflow buf[1024].


sprintf could be used  then to save some space


I pushed some changes to that.

--- grischka


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

Re: [Tinycc-devel] Small patch

[Vincent Lefevre]

On 2013-01-31 14:50:38 +0100, grischka wrote:
 Vincent Lefevre wrote:
 On 2013-01-31 13:22:22 +0100, grischka wrote:
 Vincent Lefevre wrote:
 Perhaps there was a default: by default the author forgot to remove.
 And as it is probably just useless (if op can only be '', '|' or '^'),
 no-one noticed it.
 I guess it was to avoid a compiler warning such as
 case X not handled in switch
 
 In such a case, a default: at the end with an assertion failure
 would have been better.
 
 No.  An assertion only makes sense to make sure about what we aren't
 entirely sure.  In this case we are sure (that default never happens).

You are sure *now*. But imagine that in the future you modify the if
at the beginning of the loop to add a 4th operator but you forget to
modify the switch...

BTW, since you are sure now and think an assert is useless anyway,
removing the default: (or adding an empty default: at the end)
now should be completely safe.

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

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

Re: [Tinycc-devel] Small patch

[Thomas Preud'homme]

Le jeudi 31 janvier 2013 14:53:42, grischka a écrit :
 Thomas Preud'homme wrote:
  Maybe we should just put bcheck.o into libtcc1.a (and thus make via
  the rules of lib/Makefile).  Unless there is a reason why we
  shouldn't.
  
  Yes but that doesn't change the general assumption that we are compiling
  tcc with gcc. If --cc is specified at configure time, then CFLAGS and
  CPPFLAGS should be set when running make (make CPPFLAGS=foo CFLAGS=bar)
 
 Sure, but if you want to solve the --cc=tcc/clang problem then the
 question with using what compiler for libtcc1.a needs to be answered,
 and also whether it makes sense to treat bcheck.o separately.

Sure.

 
 Are you sure that putting an hash link to an not-existing name entry
 is the right way to deal with a malformed elf file?

No, again you're right. I got over zealous in trying to address anything that 
was shown to me. I should have taken the cautious approach and later look at 
all the surrounding code. Thanks for your vigilance ;)

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] Small patch

[Michael Matz]

Hi,

On Thu, 31 Jan 2013, Vincent Lefevre wrote:

  In such a case, a default: at the end with an assertion failure
  would have been better.
  
  No.  An assertion only makes sense to make sure about what we aren't
  entirely sure.  In this case we are sure (that default never happens).
 
 You are sure *now*. But imagine that in the future you modify the if
 at the beginning of the loop to add a 4th operator but you forget to
 modify the switch...
 
 BTW, since you are sure now and think an assert is useless anyway,
 removing the default: (or adding an empty default: at the end)
 now should be completely safe.

It will lead to slower and/or larger code to add a default case with a
separate body.  The current way of doing it is IMO the exactly correct
way.  If people are really confused by that, put a comment next to the
'default:'.

Generally stylistic warnings of coverity (and actually not just
stylistic things) have to be taken with a huge amount of salt.


Ciao,
Michael.

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

Re: [Tinycc-devel] Small patch

[Vincent Lefevre]

On 2013-01-31 15:56:34 +0100, Michael Matz wrote:
 It will lead to slower and/or larger code to add a default case with a
 separate body.  The current way of doing it is IMO the exactly correct
 way.  If people are really confused by that, put a comment next to the
 'default:'.

OK (until compilers become smart enough to track possible values
of variables). I would rather see the case '^' as a comment
rather than code. Or add a special assert that would be checked
only in some debug mode.

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

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

Re: [Tinycc-devel] Small patch

[grischka]

Vincent Lefevre wrote:

No.  An assertion only makes sense to make sure about what we aren't
entirely sure.  In this case we are sure (that default never happens).


You are sure *now*. But imagine that in the future you modify the if
at the beginning of the loop to add a 4th operator but you forget to
modify the switch...


If I'd add that 4th operator then I'm sure it would actually work.


BTW, since you are sure now and think an assert is useless anyway,
removing the default: (or adding an empty default: at the end)
now should be completely safe.


Geez.  Everybody knows that TinyCC isn't the recommended way to
write a compiler.

--- grischka


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

[Tinycc-devel] Small patch

[Ivo van Poorten]

Error:

$ ./configure --cc=tcc
Binary  directory   /usr/local/bin
TinyCC directory/usr/local/lib/tcc
Library directory   /usr/local/lib
Include directory   /usr/local/include
Manual directory/usr/local/share/man
Info directory  /usr/local/share/info
Doc directory   /usr/local/share/doc/tcc
Target root prefix  
Source path  /home/ivo/git/tinycc
C compiler   tcc
Target OSLinux
CPU  x86
Big Endian   no
gprof enabledno
cross compilers  no
use libgcc   no
Creating config.mak and config.h
$ make
[..snip..]
gcc -c lib/bcheck.c -o bcheck.o -I. -I/home/ivo/git/tinycc -Wall -g -O2
-mpreferred-stack-boundary=2 -m386 -malign-functions=0 -m32 cc1: error:
unrecognized command line option -m386


88888888

diff --git a/Makefile b/Makefile
index d257464..0333ebe 100644
--- a/Makefile
+++ b/Makefile
@@ -232,7 +232,7 @@ libtcc1.a : FORCE
 lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
@$(MAKE) -C lib cross TARGET=$*
 bcheck.o : lib/bcheck.c
-   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
+   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 FORCE:
 
 # install

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

Re: [Tinycc-devel] Small patch

[Domingo Alvarez Duarte]

Hello !
I'm looking again on the reports done with Coverity Scan and found several
things one of it is this:

static void asm_expr_prod(TCCState *s1, ExprValue *pe)
{
int op;
ExprValue e2;

asm_expr_unary(s1, pe);
for(;;) {
op = tok;
if (op != '*'  op != '/'  op != '%' 
op != TOK_SHL  op != TOK_SAR)
break;
next();
asm_expr_unary(s1, e2);
if (pe-sym || e2.sym)
tcc_error(invalid operation with label);
switch(op) {
case '*':
pe-v *= e2.v;
break;
case '/':
if (e2.v == 0) {
div_error:
tcc_error(division by zero);
}
pe-v /= e2.v;
break;
case '%':
if (e2.v == 0)
goto div_error;
pe-v %= e2.v;
break;
case TOK_SHL:
pe-v = e2.v;
break;
default:
case TOK_SAR:this case
after default what does it mean ??
pe-v = e2.v;
break;
}
}
}



On Wed, Jan 30, 2013 at 11:08 PM, Ivo van Poorten ivo...@gmail.com wrote:

 Error:

 $ ./configure --cc=tcc
 Binary  directory   /usr/local/bin
 TinyCC directory/usr/local/lib/tcc
 Library directory   /usr/local/lib
 Include directory   /usr/local/include
 Manual directory/usr/local/share/man
 Info directory  /usr/local/share/info
 Doc directory   /usr/local/share/doc/tcc
 Target root prefix
 Source path  /home/ivo/git/tinycc
 C compiler   tcc
 Target OSLinux
 CPU  x86
 Big Endian   no
 gprof enabledno
 cross compilers  no
 use libgcc   no
 Creating config.mak and config.h
 $ make
 [..snip..]
 gcc -c lib/bcheck.c -o bcheck.o -I. -I/home/ivo/git/tinycc -Wall -g -O2
 -mpreferred-stack-boundary=2 -m386 -malign-functions=0 -m32 cc1: error:
 unrecognized command line option -m386


 88888888

 diff --git a/Makefile b/Makefile
 index d257464..0333ebe 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -232,7 +232,7 @@ libtcc1.a : FORCE
  lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
 @$(MAKE) -C lib cross TARGET=$*
  bcheck.o : lib/bcheck.c
 -   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 +   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  FORCE:

  # install

 ___
 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] Small patch

[Domingo Alvarez Duarte]

Here is some that I found simple to make:

Author: mingodad mingo...@gmail.com  2013-01-31 01:17:50
Committer: mingodad mingo...@gmail.com  2013-01-31 01:17:50
Parent: 1b1e7ee1fd2f269872128dc5e8b830bd55dfa80c (Fix cross-compilation
out-of-tree build)
Branch: vio_patch
Follows: release_0_9_25
Precedes:

Alerts found using Coverity Scan

--- libtcc.c
---
index b0a9b1a..69d9e0d 100644
@@ -479,8 +479,7 @@ ST_FUNC void put_extern_sym2(Sym *sym, Section *section,
 case TOK_strlen:
 case TOK_strcpy:
 case TOK_alloca:
-strcpy(buf, __bound_);
-strcat(buf, name);
+snprintf(buf, sizeof(buf), __bound_%s, name);
 name = buf;
 break;
 }

--- tccelf.c
---
index a4dee19..479b2fa 100644
@@ -114,7 +114,7 @@ ST_FUNC int put_elf_sym(Section *s, uplong value,
unsigned long size,
 if (ELFW(ST_BIND)(info) != STB_LOCAL) {
 /* add another hashing entry */
 nbuckets = base[0];
-h = elf_hash(name) % nbuckets;
+h = name ? elf_hash(name) % nbuckets : 0;
 *ptr = base[2 + h];
 base[2 + h] = sym_index;
 base[1]++;
@@ -3052,7 +3052,7 @@ static int ld_add_file_list(TCCState *s1, const char
*cmd, int as_needed)
 ret = -1;
 goto lib_parse_error;
 }
-strcpy(libname, filename[1]);
+snprintf(libname, sizeof(libname), %s, filename[1]);
 libname_to_filename(s1, libname, filename);
 } else if (t != LD_TOK_NAME) {
 tcc_error_noabort(filename expected);

--- tccgen.c
---
index 4300403..e06a932 100644
@@ -361,6 +361,7 @@ void vpush64(int ty, unsigned long long v)
 CValue cval;
 CType ctype;
 ctype.t = ty;
+ctype.ref = 0;
 cval.ull = v;
 vsetc(ctype, VT_CONST, cval);
 }
@@ -1734,6 +1735,7 @@ ST_FUNC void gen_op(int op)
 }
 vswap();
 type1.t = t;
+type1.ref = 0;
 gen_cast(type1);
 vswap();
 /* special case for shifts and long long: we keep the shift as
@@ -2717,6 +2719,7 @@ static void struct_decl(CType *type, int u)
 v = anon_sym++;
 }
 type1.t = a;
+type1.ref = 0;
 /* we put an undefined size for struct/union */
 s = sym_push(v | SYM_STRUCT, type1, 0, -1);
 s-r = 0; /* default alignment is zero as gcc */
@@ -3396,6 +3399,7 @@ static void gfunc_param_typed(Sym *func, Sym *arg)
 /* default casting : only need to convert float to double */
 if ((vtop-type.t  VT_BTYPE) == VT_FLOAT) {
 type.t = VT_DOUBLE;
+type.ref = 0;
 gen_cast(type);
 }
 } else if (arg == NULL) {
@@ -3592,6 +3596,7 @@ ST_FUNC void unary(void)
 if ((vtop-r  (VT_VALMASK | VT_LVAL | VT_SYM)) == VT_CONST) {
 CType boolean;
 boolean.t = VT_BOOL;
+boolean.ref = 0;
 gen_cast(boolean);
 vtop-c.i = !vtop-c.i;
 } else if ((vtop-r  VT_VALMASK) == VT_CMP)
@@ -4101,6 +4106,7 @@ static void expr_cond(void)
 CType boolean;
 int c;
 boolean.t = VT_BOOL;
+boolean.ref = 0;
 vdup();
 gen_cast(boolean);
 c = vtop-c.i;
@@ -5574,7 +5580,7 @@ ST_FUNC void gen_inline_functions(void)
 str = fn-token_str;
 fn-sym = NULL;
 if (file)
-strcpy(file-filename, fn-filename);
+snprintf(file-filename, sizeof(file-filename), %s,
fn-filename);
 sym-r = VT_SYM | VT_CONST;
 sym-type.t = ~VT_INLINE;




On Thu, Jan 31, 2013 at 1:13 AM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Also on this function:

 CID 968150 (#1 of 1): Unchecked return value (CHECKED_RETURN)6.
 check_return: Calling function parse_btype(CType *, AttributeDef *)
 without checking return value (as is done elsewhere 7 out of 8 times).


 /* enum/struct/union declaration. u is either VT_ENUM or VT_STRUCT */
 static void struct_decl(CType *type, int u)
 {
 ...
 bit_pos = 0;
 offset = 0;
 while (tok != '}') {
 parse_btype(btype, ad);  no check made here
 ?
 while (1) {
 bit_size = -1;
 v = 0;
 type1 = btype;



 On Thu, Jan 31, 2013 at 1:07 AM, Domingo Alvarez Duarte 
 mingo...@gmail.com wrote:

 Also here :

 static void asm_expr_logic(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;

 asm_expr_prod(s1, pe);

 for(;;) {
 op = tok;
 if (op != ''  op != '|'  op != '^')
 break;
 next();
 

Re: [Tinycc-devel] Small patch

[Domingo Alvarez Duarte]

Also on this function:

CID 968150 (#1 of 1): Unchecked return value (CHECKED_RETURN)6.
check_return: Calling function parse_btype(CType *, AttributeDef *)
without checking return value (as is done elsewhere 7 out of 8 times).


/* enum/struct/union declaration. u is either VT_ENUM or VT_STRUCT */
static void struct_decl(CType *type, int u)
{
...
bit_pos = 0;
offset = 0;
while (tok != '}') {
parse_btype(btype, ad);  no check made here
?
while (1) {
bit_size = -1;
v = 0;
type1 = btype;



On Thu, Jan 31, 2013 at 1:07 AM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Also here :

 static void asm_expr_logic(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;

 asm_expr_prod(s1, pe);

 for(;;) {
 op = tok;
 if (op != ''  op != '|'  op != '^')
 break;
 next();
 asm_expr_prod(s1, e2);

 if (pe-sym || e2.sym)
 tcc_error(invalid operation with label);
 switch(op) {
 case '':
 pe-v = e2.v;
 break;
 case '|':
 pe-v |= e2.v;
 break;
 default:
 case '^':  ///what this case
 after default mean 
 pe-v ^= e2.v;
 break;
 }
 }
 }



 On Thu, Jan 31, 2013 at 1:06 AM, Domingo Alvarez Duarte 
 mingo...@gmail.com wrote:

 Hello !
 I'm looking again on the reports done with Coverity Scan and found
 several things one of it is this:

 static void asm_expr_prod(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;

 asm_expr_unary(s1, pe);
 for(;;) {
 op = tok;
 if (op != '*'  op != '/'  op != '%' 
 op != TOK_SHL  op != TOK_SAR)
 break;
 next();
 asm_expr_unary(s1, e2);
 if (pe-sym || e2.sym)
 tcc_error(invalid operation with label);
 switch(op) {
 case '*':
 pe-v *= e2.v;
 break;
 case '/':
 if (e2.v == 0) {
 div_error:
 tcc_error(division by zero);
 }
 pe-v /= e2.v;
 break;
 case '%':
 if (e2.v == 0)
 goto div_error;
 pe-v %= e2.v;
 break;
 case TOK_SHL:
 pe-v = e2.v;
 break;
 default:
 case TOK_SAR:this
 case after default what does it mean ??
 pe-v = e2.v;
 break;
 }
 }
 }



 On Wed, Jan 30, 2013 at 11:08 PM, Ivo van Poorten ivo...@gmail.comwrote:

 Error:

 $ ./configure --cc=tcc
 Binary  directory   /usr/local/bin
 TinyCC directory/usr/local/lib/tcc
 Library directory   /usr/local/lib
 Include directory   /usr/local/include
 Manual directory/usr/local/share/man
 Info directory  /usr/local/share/info
 Doc directory   /usr/local/share/doc/tcc
 Target root prefix
 Source path  /home/ivo/git/tinycc
 C compiler   tcc
 Target OSLinux
 CPU  x86
 Big Endian   no
 gprof enabledno
 cross compilers  no
 use libgcc   no
 Creating config.mak and config.h
 $ make
 [..snip..]
 gcc -c lib/bcheck.c -o bcheck.o -I. -I/home/ivo/git/tinycc -Wall -g -O2
 -mpreferred-stack-boundary=2 -m386 -malign-functions=0 -m32 cc1: error:
 unrecognized command line option -m386


 88888888

 diff --git a/Makefile b/Makefile
 index d257464..0333ebe 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -232,7 +232,7 @@ libtcc1.a : FORCE
  lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
 @$(MAKE) -C lib cross TARGET=$*
  bcheck.o : lib/bcheck.c
 -   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 +   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  FORCE:

  # install

 ___
 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] Small patch

[Domingo Alvarez Duarte]

Also here :

static void asm_expr_logic(TCCState *s1, ExprValue *pe)
{
int op;
ExprValue e2;

asm_expr_prod(s1, pe);
for(;;) {
op = tok;
if (op != ''  op != '|'  op != '^')
break;
next();
asm_expr_prod(s1, e2);
if (pe-sym || e2.sym)
tcc_error(invalid operation with label);
switch(op) {
case '':
pe-v = e2.v;
break;
case '|':
pe-v |= e2.v;
break;
default:
case '^':  ///what this case
after default mean 
pe-v ^= e2.v;
break;
}
}
}



On Thu, Jan 31, 2013 at 1:06 AM, Domingo Alvarez Duarte
mingo...@gmail.comwrote:

 Hello !
 I'm looking again on the reports done with Coverity Scan and found several
 things one of it is this:

 static void asm_expr_prod(TCCState *s1, ExprValue *pe)
 {
 int op;
 ExprValue e2;

 asm_expr_unary(s1, pe);
 for(;;) {
 op = tok;
 if (op != '*'  op != '/'  op != '%' 
 op != TOK_SHL  op != TOK_SAR)
 break;
 next();
 asm_expr_unary(s1, e2);
 if (pe-sym || e2.sym)
 tcc_error(invalid operation with label);
 switch(op) {
 case '*':
 pe-v *= e2.v;
 break;
 case '/':
 if (e2.v == 0) {
 div_error:
 tcc_error(division by zero);
 }
 pe-v /= e2.v;
 break;
 case '%':
 if (e2.v == 0)
 goto div_error;
 pe-v %= e2.v;
 break;
 case TOK_SHL:
 pe-v = e2.v;
 break;
 default:
 case TOK_SAR:this case
 after default what does it mean ??
 pe-v = e2.v;
 break;
 }
 }
 }



 On Wed, Jan 30, 2013 at 11:08 PM, Ivo van Poorten ivo...@gmail.comwrote:

 Error:

 $ ./configure --cc=tcc
 Binary  directory   /usr/local/bin
 TinyCC directory/usr/local/lib/tcc
 Library directory   /usr/local/lib
 Include directory   /usr/local/include
 Manual directory/usr/local/share/man
 Info directory  /usr/local/share/info
 Doc directory   /usr/local/share/doc/tcc
 Target root prefix
 Source path  /home/ivo/git/tinycc
 C compiler   tcc
 Target OSLinux
 CPU  x86
 Big Endian   no
 gprof enabledno
 cross compilers  no
 use libgcc   no
 Creating config.mak and config.h
 $ make
 [..snip..]
 gcc -c lib/bcheck.c -o bcheck.o -I. -I/home/ivo/git/tinycc -Wall -g -O2
 -mpreferred-stack-boundary=2 -m386 -malign-functions=0 -m32 cc1: error:
 unrecognized command line option -m386


 88888888

 diff --git a/Makefile b/Makefile
 index d257464..0333ebe 100644
 --- a/Makefile
 +++ b/Makefile
 @@ -232,7 +232,7 @@ libtcc1.a : FORCE
  lib/%/libtcc1.a : FORCE $(PROGS_CROSS)
 @$(MAKE) -C lib cross TARGET=$*
  bcheck.o : lib/bcheck.c
 -   gcc -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
 +   $(CC) -c $ -o $@ $(CPPFLAGS) $(CFLAGS)
  FORCE:

  # install

 ___
 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] introduction, patch, and bug report

[Damian Gryski]

On Fri, Sep 2, 2011 at 2:08 AM, grischka gris...@gmx.de wrote:
 My patch adds support for Ubuntu 11.04 x86_64, and possibly others.

 Looks acceptable.

 Maybe instead of TCC_TARGET_UBUNTU (which sounds too specific and
 ubuntu is not a processor target really) you could use something
 like
        CONFIG_MULTIARCHDIR=\x86_64-linux-gnu\

   I was using the 'TCC_TARGET_X86_64_CENTOS' #define as my guide, as
it seemed to be performing a similar function but for Centos.  Since
the symbols aren't used anywhere else, it probably makes sense to
define them as feature tags, rather than platform tags, and then use
the feature tags when construction the ldddir lines.

   I'll see about combining these features into a single,
non-distro-named something.

   Do you have any suggestions on how I could start hunting down the
parse error I encountered while building Go?

   Damian

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

Re: [Tinycc-devel] introduction, patch, and bug report

[grischka]

Damian Gryski wrote:

Hi,

I've submitted some bug reports and patches for TCC in the past, and I
figured I'd introduce myself before pushing a fix to the mob branch.


You're welcome.



My patch adds support for Ubuntu 11.04 x86_64, and possibly others.


Looks acceptable.

Maybe instead of TCC_TARGET_UBUNTU (which sounds too specific and
ubuntu is not a processor target really) you could use something
like
CONFIG_MULTIARCHDIR=\x86_64-linux-gnu\

But feel free to do as you see fit.

--- grischka


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

[Tinycc-devel] about patch: support c99 for-loop init decls

[grischka]

This patch:
http://repo.or.cz/w/tinycc.git/commitdiff/e23194a1fa2ca176c9151964a2e035f36736e650

moves code that belongs to block()
  -gexpr();
  -vpop();
into decl0()
  +gexpr();
  +vpop();

which is structurally un-nice.

I'd rather let decl0() just do the c99 case and return a value, and then
use like this in block():

 if (tok != ';') {
   if (!decl0(VT_LOCAL, 1)) { /* c99 loop variable */
 gexpr();
 vpop();
   }
 }

Also no need to wrap into a function for only one use, IMO.

Thanks,

--- grischka


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

Re: [Tinycc-devel] about patch: support c99 for-loop init decls

[Joe Soroka]

On Tue, Mar 8, 2011 at 6:00 AM, grischka gris...@gmx.de wrote:
 I'd rather let decl0() just do the c99 case and return a value

Yes... I wanted to do that, but it didn't seem to fit with the rest of the
code.  I thought this way was more tcc-like.  Please feel free to
change it however you see fit.

Thanks.
Joe

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

Re: [Tinycc-devel] about patch: support c99 for-loop init decls

[Joe Soroka]

On Tue, Mar 8, 2011 at 9:15 AM, Joe Soroka tin...@joesoroka.com wrote:
 On Tue, Mar 8, 2011 at 6:00 AM, grischka gris...@gmx.de wrote:
 I'd rather let decl0() just do the c99 case and return a value

 Yes... I wanted to do that, but it didn't seem to fit with the rest of the
 code.  I thought this way was more tcc-like.  Please feel free to
 change it however you see fit.

I'm sorry, I didn't understand you precisely at first.  I've figured
it out now.  I'll make the changes you've suggested.

Thanks.
Joe

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

Re: [Tinycc-devel] about patch: support c99 for-loop init decls

[grischka]

Joe Soroka wrote:

On Tue, Mar 8, 2011 at 6:00 AM, grischka gris...@gmx.de wrote:

I'd rather let decl0() just do the c99 case and return a value


Yes... I wanted to do that, but it didn't seem to fit with the rest of the
code.  I thought this way was more tcc-like.  


tcc-like in how?  Any evidence of analogous hacks elsewhere in the code?


Please feel free to change it however you see fit.


Maybe I will.  Until then feel free to fix incorrect variable scope ;)

int i = -1;
for (int i = 0; i  4; ++i)
printf(i = %d\n, i);
printf(i = %d\n, i);

--- grischka

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

Re: [Tinycc-devel] about patch: support c99 for-loop init decls

[Joe Soroka]

On Tue, Mar 8, 2011 at 1:24 PM, grischka gris...@gmx.de wrote:
 I'd rather let decl0() just do the c99 case and return a value

 Yes... I wanted to do that, but it didn't seem to fit with the rest of the
 code.  I thought this way was more tcc-like.

 tcc-like in how?  Any evidence of analogous hacks elsewhere in the code?

I just meant leaving decl() alone and creating a decl0() so the other
callsites wouldn't have to change, and I do see evidence of that sort
of thing elsewhere in tcc.  But that's not what you were getting at,
and now I understand.

 Please feel free to change it however you see fit.
 Maybe I will.

I didn't want to seem ornery, I just meant that I thought I understood
what you were getting at, but that I had absolutely no problem with
someone else committing over top of me, and certainly you would do a
better job than me of expressing your internal concept in code.  Plus
you obviously have more ownership than just about anyone else, so I
was merely deferring to your eminence.

 Until then feel free to fix incorrect variable scope ;)
 [example code]

Darn.  Thank you.  I'm doubly embarrassed now.

Joe

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

[Tinycc-devel] Re: [PATCH 7/7] tcc -E: Let output_default be file.o instead of a.out

[Kirill Smelkov]

On Fri, Jun 18, 2010 at 09:24:28PM +0200, grischka wrote:
 Did you consider pushing the feature(s) on the tinycc mob branch?

Yes. And I though mob was a bit destabilized by last member of union
patches, so I decided not to continue that.

Yes, I've read tinycc.git intro text about mob, and it's really up to
you on how to pick patches. I just though posting by mail is also ok,
and as your comments show, having a look on them before inclusion allows
(hopefully) to merge them in a bit more good shape.

 Some suggestions:
 
 +/* compute default outfile name */
 +{
 +char *ext;
 +
 Put that into a function.

Yes. I'm putting it into libtcc API as

LIBTCCAPI const char *tcc_default_target(TCCState *s)

 +/* dump collected dependencies */
 +if (gen_deps) {
 +  ...
 Put that into a function.

Ok,

LIBTCCAPI void tcc_gen_makedeps(TCCState *s, const char *target, const char 
*filename)

 +ext = strrchr(buf, '.');
 +ext = ext ? ext : strchr(buf, 0);
 Use tcc_fileextension().

Yes and thanks. I've though about tcc_fileextension(), but wrongly
decided that it's not for me because call to tcc_basename.

Thanks for suggestions - I'll repost reworked patches soon.


Kirill

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

[Tinycc-devel] Re: [PATCH 7/7] tcc -E: Let output_default be file.o instead of a.out

[grischka]

Did you consider pushing the feature(s) on the tinycc mob branch?

Some suggestions:


+/* compute default outfile name */
+{
+char *ext;
+

Put that into a function.


+/* dump collected dependencies */
+if (gen_deps) {
+  ...

Put that into a function.


+ext = strrchr(buf, '.');
+ext = ext ? ext : strchr(buf, 0);

Use tcc_fileextension().

--- grischka

Kirill Smelkov wrote:

This affectes where `tcc -E -MD file.c` will place generated dependency
information -- previously, for `tcc -E` output_default was a.out, and so
deps were put into a.d .

Avoid this behaviour, by treating `tcc -E` as `tcc -c` with respect to
output_default computation.

This will not hurt anything else (preprocessor outputs to either stdout,
or to explicitely given (-o file) destination, so no default filename
is used here), and on the other hand `tcc -E -MD file.c` now puts
dependencies into file.d (the same behaviour as for gcc -E).
---
 tcc.c |4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/tcc.c b/tcc.c
index a4b610d..2526d9d 100644
--- a/tcc.c
+++ b/tcc.c
@@ -467,7 +467,9 @@ int main(int argc, char **argv)
 strcpy(ext, .exe);
 else
 #endif
-if (output_type == TCC_OUTPUT_OBJ  !reloc_output  *ext)
+if ((output_type == TCC_OUTPUT_OBJ ||
+ output_type == TCC_OUTPUT_PREPROCESS)
+ !reloc_output  *ext)
 strcpy(ext, .o);
 else
 pstrcpy(outfile_default, sizeof(outfile_default), a.out);


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

[Tinycc-devel] Selinux patch fixup.

[Henry Kroll III]

I fixed my selinux patch, so it's better integrated into the way tcc
does things. It was really quite terrible. Now it works with programs
that use libtcc, if ever there be ones...

I also pushed a script to build a win32 version of libtcc1.a for
cross-compiling on x86 and x86_64 arch.

And another patch for making a shared lib, libtcc.so.1 which has not
made it into the install: target yet. I need to add simlinks to it as
well. My distro wants shared, not static libs. Too busy to finish and my
folks think I'm spending way too much time on the computer, so I hope
this will at least give somebody ideas. :)



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

[Tinycc-devel] Re: [PATCH] CVS - Git

[Kirill Smelkov]

On Tue, Apr 13, 2010 at 06:55:43PM +0200, grischka wrote:
 Kirill Smelkov wrote:
 By the way, do you have an idea about when 0.9.26 is going to happen?
 Even approximate timing helps...
 
 Can happen whenever people want.  You'd just agree on a revision
 number that is reasonably stable and you can have it tomorrow ;)

Wow! As to me, I vote for making release from latest mob (if it is ok)
and then there will be some chance to get 0.9.26 into Debian squeeze.

But then, I'd better ask input from other people who use Tcc - whether
it is stable enough for them or not.


Thanks,
Kirill


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

[Tinycc-devel] Re: [PATCH] CVS - Git

[Kirill Smelkov]

On Tue, Apr 13, 2010 at 02:34:36PM +0200, grischka wrote:
 I'm not sure whether Fabrice Bellard reads this but we can tell
 him at next release.

Ok, thanks.

By the way, do you have an idea about when 0.9.26 is going to happen?
Even approximate timing helps...

 Perhaps just
Savannah project page and source repository
 would be more future safe ;)

Indeed, so that you could always change Git for something else and leave
that main page intact :)

It's up to you how to do it. I just had an eyebrow seeing CVS on
titlepage, and wondered why it is still there and saw it's now totally
untrue.

Someone (hear hear) should be almost happy, but until title page is
changend we are not 100% there yet :)


Good luck and thanks!
Kirill


 --- grischka
 
 Kirill Smelkov wrote:
 It's been 1.5 years already [1], and Tinycc Savannah project page
 references only Git without CVS [2], so let's maybe do
 
 diff --git a/http://bellard.org/tcc/ b/http://bellard.org/tcc/
 --- http://bellard.org/tcc/
 +++ http://bellard.org/tcc/
 @@ -1,7 +1,7 @@
  Links
  
o TinyCC mailing list 
 -  o Savannah project page and CVS repository 
 +  o Savannah project page and Git repository 
o OTCC - The smallest self compiling pseudo C compiler 
o NumCalc.com - The Scientific Web Calculator 
o TinyCC fork by Rob Landley
 
 ?
 
 Thanks,
 Kirill
 
 
 [1] http://www.mail-archive.com/tinycc-devel%40nongnu.org/msg01873.html
 [2] https://savannah.nongnu.org/projects/tinycc


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

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[Joshua Phillips]

stricmp is Microsoft's version of strcasecmp.
strcasecmp is identical, iirc, and was introduced in POSIX.1-2001.

On Wednesday 15 April 2009 05:25:12 lostgallifreyan wrote:
 grischka gris...@gmx.de wrote:
 (14/04/2009 21:04)

 http://repo.or.cz/w/tinycc.git?a=shortlog;h=92c58361
 
 Links to shapsnots are at the rightmost end of the lines.

 Where are you getting stricmp from? I got some C reference PDF's that say
 only strcmp and people here told me when I asked, that to do a force or an
 insensitive compare I'd have to iterate over each character. You're doing
 something no-one mentioned, so what is it?



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




signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[Joshua Phillips]

stricmp or strcasecmp would be provided by the C library. Tcc is only a 
compiler - it doesn't include a C library. Therefore, the presence of stricmp 
or strcasecmp will be determined by the C library you're using (GNU libc or 
MSVCRT or other)

On Wednesday 15 April 2009 12:37:29 lostgallifreyan wrote:
 Joshua Phillips jp.sittingd...@gmail.com wrote:
 (15/04/2009 10:32)

 stricmp is Microsoft's version of strcasecmp.
 strcasecmp is identical, iirc, and was introduced in POSIX.1-2001.

 I checked that, at least, I tried substituting it to see if strcasecmp()
 would work. It didn't. What I'm getting at though, is how strict is TCC's
 C? As TCC can compile itself, I thought it would be strict, maybe to the
 point that Lua is strict: ANSI C wherever possible for best compatibilty
 with many platforms. Neither stricmp() or strcasecmp() is ANSI C.

 For the record, Griska's method is the first thing I wanted, and tried. I
 only settled for a single placement of an iterative case forcer because I
 was told there was no dedicated function for it in C. So I guess I'm not
 alone in thinking TCC's C isn't as strict as I (we) first assumed. I also
 did what I did precisely because it was strict ANSI C and I thought that
 was preferred.




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




signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[Joshua Phillips]

TCC can only compile C. If it were to be able to compile C++, it would need a 
lot more work (it would need to compile C++ language features: classes, 
templates, etc. etc.). Since it's still rather buggy at being a C compiler, 
extending it to compile C++ probably wouldn't be very helpful.
Secondly, C++ is not a superset of C. It is more like an extension of C. C++ 
made some changes to the semantics of the C bits (for example, implicit casts 
of void pointers) which were necessary for other features of C++ to work. So, 
it is not true that *any* C program is a valid C++ program, although some are 
(i.e. there is a large common subset).

On Wednesday 15 April 2009 13:11:08 lostgallifreyan wrote:
 Joshua Phillips jp.sittingd...@gmail.com wrote:
 (15/04/2009 13:46)

 stricmp or strcasecmp would be provided by the C library. Tcc is only a
 compiler - it doesn't include a C library. Therefore, the presence of
  stricmp or strcasecmp will be determined by the C library you're using
  (GNU libc or MSVCRT or other)

 Ok, that makes sense, but if it were only the library that determines
 what's there, TCC might compile C++. As it doesn't I assume it's not just
 the library that determines this. (That remark is based in my possibly
 erroneous assumption that C++ is a kind of superset of C with a lot more
 dedicated functions). In short, doesn't the compiler have to 'understand'
 what it's compiling?



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




signature.asc
Description: This is a digitally signed message part.
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[grischka]

lostgallifreyan wrote:

Joshua Phillips jp.sittingd...@gmail.com wrote:
(15/04/2009 13:46)

stricmp or strcasecmp would be provided by the C library. Tcc is only a 
compiler - it doesn't include a C library. Therefore, the presence of stricmp 
or strcasecmp will be determined by the C library you're using (GNU libc or 
MSVCRT or other)




Ok, that makes sense, but if it were only the library that determines what's 
there, TCC might compile C++. As it doesn't I assume it's not just the library 
that determines this.
(That remark is based in my possibly erroneous assumption that C++ is a kind of 
superset of C with a lot more dedicated functions).
In short, doesn't the compiler have to 'understand' what it's compiling?


In short, yes and no.  The initial vocabulary (keywords) of a
C compiler is rather small:

 char short int long float double enum void
 signed unsigned
 typedef struct union sizeof
 const extern static
 if else while do for
 continue break goto return switch case default

And some others.  The complete list for TCC is in tcctok.h.

A C++ compiler knows a few additional keywords, like
 bool class new delete
 ...

However the compiler learns more words as it reads the include
files and the program text.  E.g. with TinyCC it learns pstrcat
and dynarray_add and put_ext_sym2 and whatnot.

It learns enough about these words to speak them, but it doesn't
understand their meaning.  It understands the meaning of its own
keywords though.



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

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[lostgallifreyan]

Charlie Gordon t...@chqrlie.org wrote:
(14/04/2009 11:28)

I don't think this is going in the right direction:
- Command line arguments should not be changed
- Why restrict this behaviour to full paths with a drive letter ?
- instead of matching filename extensions in a case independent manner ?


You miss the point. Look at the GCC specs for commandlines, as I was told to 
do. How do you propose to handle .s and .S on Windows? The patch would bloat 
uncontrollably if any attempt was made to solve this that way, and code for 
that exists already, the written arguments' case is taken literally by TCC. As 
TCC tends to use lower case commands and filespecs, except where upper case is 
required, the simplest thing to do is make the DOS paths lower case, while 
testing for existing lowercase to disable the patch if any is found. I'm a 
newcomer to C, and TCC, yet was urged to jump in the deep end and suggest a 
solution! So that is what I did, and I had to figure out the best placement of 
the patch for myself. And it works. If you want to specify an exact case for an 
extension, you can. All this patch is meant to do is prevent DOS's all-caps 
habits from breaking filespecs as normally expected by TCC, while being 
irrelevant to non-windows users, and being easily bypassed by Windows users.

Also more importantly, do not pass char arguments to tolower/toupper and
islower/isupper functions.  'char' may be signed whereas these functions 
expect
an int parameter with a value among those of type unsigned char or EOF.
The argument to these functions should at least be cast to (unsigned char),
and so should the value you compare their result to.

if (*p != toupper(*p))

if ((unsigned char)*p != toupper((unsigned char)*p)

*p = tolower(*p);

*p = tolower((unsigned char)*p);

If you don't like the resulting code (quite ugly in my opinion),
you should use a temporary variable:

int c = (unsigned char)*p;
if (toupper(c) != c) ...

*p = tolower(c);


I went with advice given, as best I could. As the variable isn't assigned any 
negative values it's not going to be an issue, as I guess was why I was advised 
as I was. Actually I forgot the unsigned char bit but even so, it compiled 
without error or warning and it worked. Not sure why you put all those 
unsigned chars in there like that, or want an extra variable, I just tried 
unsigned char *p; as the initial declaration and it worked fine. (See Dave 
Dodge's mail in the earlier thread, he does the same).


But all things considered, I still argue that the correct approach to the 
problem
you are trying to fix, is to perform case insensitive matching on filename 
extensions
wherever these occur.  A simple way to do this is to identify all 
occurrences of such
matching and use call function with a platform dependent implementation.


No, logically it's the same thing. Though while I could have forced case only 
on the TEST value that made no sense in practise, as DOS already does force 
case in shortname paths! I would have not have solved the problem by doing the 
same thing, or its inverse. And to do so goes right against the GCC specs that 
TCC is emulating. The correct way is to force lower case for this singular 
instance to reverse Windows' forced upper case. Keep it simple. If further 
refined exceptions must be made, add them. For example, as .c requires 
preprocessing, while .S as opposed to .s also requires it for assembler code, 
it might be worth adding a line to re-forece the singular extension .s to upper 
case on Windows to invoke the right response from TCC. But in the interests of 
keeping code size down, it seems wise to limit the patch's behaviour to a 
simple easily predicted action that is extremely easy to over-ride in the 
extremely limited situations where it can even act at all. :) This I have done.



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

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[grischka]

Ivo wrote:
Why don't you just implement gcc's -x command line option instead of this 
ifdeffery? It's also useful on other platforms and it solves the .s/.S 
problem, too:


-x c
-x cpp-output
-x assembler
-x assembler-with-cpp

etc...



I wouldn't say no if we can get it.

However that wouldn't stop windows users from asking why they
can't type TCC FILE.C, I'm afraid.

--- grischka


--Ivo


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





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

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[lostgallifreyan]

grischka gris...@gmx.de wrote:
(14/04/2009 18:18)

Ivo wrote:
 Why don't you just implement gcc's -x command line option instead of this 
 ifdeffery? It's also useful on other platforms and it solves the .s/.S 
 problem, too:
 
 -x c
 -x cpp-output
 -x assembler
 -x assembler-with-cpp
 
 etc...
 

I wouldn't say no if we can get it.

However that wouldn't stop windows users from asking why they
can't type TCC FILE.C, I'm afraid.


Nope, probably not. But they wouldn't have to ask if it were GCC, because those 
paths work there. This is why I kept it simple. This patch is not trying to do 
clever things, just meant to reduce what you seem to want reduced. If you 
decided to add it, that MIGHT stop those questions in future. No way to be sure 
it won't cause others but they'd be fewer, and come from people who'd 
progressed far enough to ask more interesting questions.



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

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[grischka]

lostgallifreyan wrote:

However that wouldn't stop windows users from asking why they
can't type TCC FILE.C, I'm afraid.



Nope, probably not. But they wouldn't have to ask if it were GCC, because those 
paths work there. This is why I kept it simple. This patch is not trying to do 
clever things, just meant to reduce what you seem to want reduced. If you 
decided to add it, that MIGHT stop those questions in future. No way to be sure 
it won't cause others but they'd be fewer, and come from people who'd 
progressed far enough to ask more interesting questions.



Okay, let's move on.
http://repo.or.cz/w/tinycc.git?a=shortlog;h=92c58361

Links to shapsnots are at the rightmost end of the lines.

--- grischka



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

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[Dave Dodge]

On Tue, Apr 14, 2009 at 06:37:49PM +0100, lostgallifreyan wrote:
 Dave Dodge dodo...@dododge.net wrote:
 If the filename string contains any high-valued characters, such as
 accented letters, then accessing it with a char* might produce a
 negative char value, and passing that to isupper/islower can be a
 problem.
 
 Ok. Point taken about undefined behaviour. Is the unsigned char *p
 declaration enough though?

Yes.  Dereferencing a valid (unsigned char *) will produce an
(unsigned char), which by definition is safe to pass to isupper.

 One mail suggested using unsigned at every subsequent use of the
 variable.

That's because p was a (char *), and therefore *p was producing a
possibly-signed value.  Casting the dereferenced value to (unsigned
char) is another way of ensuring isupper gets a usable value, but I
think simply changing p to an (unsigned char *) is cleaner.

BTW it's worth noting that casting from a signed integer to an
unsigned integer is a well-defined operation, but casting from
unsigned to signed is implementation-defined.

  -Dave Dodge


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

Re: [Tinycc-devel] Basic patch for passing W9X short DOS paths to TCC.

[lostgallifreyan]

grischka gris...@gmx.de wrote:
(14/04/2009 21:04)

http://repo.or.cz/w/tinycc.git?a=shortlog;h=92c58361

Links to shapsnots are at the rightmost end of the lines.


Where are you getting stricmp from? I got some C reference PDF's that say only 
strcmp and people here told me when I asked, that to do a force or an 
insensitive compare I'd have to iterate over each character. You're doing 
something no-one mentioned, so what is it?



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

[Tinycc-devel] Re: [PATCH] tcc -E falls into a loop and runs out of memory with vim7.1, osdef0.c

[Joshua Phillips]

Erm, oh, I seem to have overlooked that one.

On Friday 30 November 2007 14:42:58 Marc Andre Tanner wrote:
 Sometimes i really wonder whether you actually *READ* the mailing list?


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

Re: [Tinycc-devel] Sample patch from Mercurial repository

[Gregg Reynolds]

On 11/2/07, KHMan [EMAIL PROTECTED] wrote:
 grischka wrote:
  Do you think it is possible and/or makes sense to extract all
  changesets from Rob's repo into single patches first, with an
  automatic script or something?

In case you're not aware of it, check out Mercurial Queues
(http://hgbook.red-bean.com/hgbookch12.html#x16-26500012) which might
be helpful for this sort of thing.

-gregg


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

Re: [Tinycc-devel] Sample patch from Mercurial repository

[grischka]

From: KHMan:
 However I think some of David Dodge's patches have already been
 applied, and bits of documentation has been updated in CVS, so I
 guess that some hg patches will not apply cleanly. 

Yes, might happen, but we can deal with technical questions later. 

 I am doing this
 on cygwin and using WinMerge for visual diff where necessary.

Yes, WinMerge is good, using it myself. 

 As for changesets, my plan is to name them using the revision
 numbers, like cvs395.diff. I will keep a set of hg exports, like
 hg395.diff. This is to preserve commit order. 

Hm, I don't understand exactly. Why do we need two sets of files?

Well, just had another idea. Instead of renaming the patches
we could use a meta-text-file with descriptions and references 
like:

patch: 395.diff
shortname: empty for now
description: changelog entry here
link: link into tinycc mail archive, if available

patch: 396.diff
shortname: 
description: ...
link: ...



Then we would just edit that meta-file, move entries around etc, 
and, if useful, eventually with another script build a patch-file 
tree from that meta-file. Do you think your coming perl script 
could generate such meta-file along with the diffs? :-)

 I see a lot of work on files like tcc.c, so I assume changesets
 need to be applied in order (as the lowest common denominator),
 moreso with what appears to be some refactoring work done by Rob.
 So, well, perhaps they can be named like
 cvs395_Does_foo_bar.diff or something like that. Can the
 changesets be mixed about and later applied in non-chronological
 order? I'm not sure about this, so I am doing this conservatively.

I don't think the order will be a big problem. The patch program
has some options, and if nothing works then we would just patch it
manually. Also, tcc.c looks more different than it actually is due
to some mere formal changes. 

 I'm not really sure about the details part, because I can't really
 do any quality assurance or assessment of the patches. 

Yes, that's what I mean our own order is for. First priority to 
undoubtful and neccessary patches, bug fixes etc. Then feature 
extensions and everything else to make as many people happy to see 
in tcc-0.9.24 as possible. The rest put back after the release, 
that would be in my opinion mere formal changes, untested patches 
and side-features that cause to much changes for the benefit.

 The list only need to agree to keep pumping patches into the CVS, 
 in order to keep tcc in virtually one piece.

Well, I think we can and should present the edited meta-file to the 
list and have some discussion. Also we might still find other patches 
that Rob doesn't have yet. If we want to step towards distributed 
development then it is useful to do things in public. 

Cheers,

--- grischka



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

Re: [Tinycc-devel] Sample patch from Mercurial repository

[KHMan]

grischka wrote:
 From: KHMan:
 I will push patches to grischka, and check every few patches with
 Ubuntu make all, and the two trees should come together. 
 
 Do you think it is possible and/or makes sense to extract all 
 changesets from Rob's repo into single patches first, with an 
 automatic script or something?

That's easy to do with hg's export. I am using something like:

  hg export 395

Appears to work. I'll write a perl script to do the job.

 Then we could give names to the patches, put them into some 
 order, group them in sub-directories etc. 

However I think some of David Dodge's patches have already been
applied, and bits of documentation has been updated in CVS, so I
guess that some hg patches will not apply cleanly. I am doing this
on cygwin and using WinMerge for visual diff where necessary.

This weekend I will make some time for it.

As for changesets, my plan is to name them using the revision
numbers, like cvs395.diff. I will keep a set of hg exports, like
hg395.diff. This is to preserve commit order. I'll send you a
tarball of both, a bunch at a time.

I see a lot of work on files like tcc.c, so I assume changesets
need to be applied in order (as the lowest common denominator),
moreso with what appears to be some refactoring work done by Rob.
So, well, perhaps they can be named like
cvs395_Does_foo_bar.diff or something like that. Can the
changesets be mixed about and later applied in non-chronological
order? I'm not sure about this, so I am doing this conservatively.

I'm not really sure about the details part, because I can't really
do any quality assurance or assessment of the patches. I was
thinking, just pump them into the CVS, never mind the details, and
the Mercurial bundle can be the starting point of new development.
After all, I agree that next-generation version control is much
more flexible than plain old CVS. The list only need to agree to
keep pumping patches into the CVS, in order to keep tcc in
virtually one piece.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

Re: [Tinycc-devel] Sample patch from Mercurial repository

[Dave Dodge]

On Fri, Nov 02, 2007 at 09:31:23AM -0600, Gregg Reynolds wrote:
 On 11/2/07, KHMan [EMAIL PROTECTED] wrote:
  grischka wrote:
   Do you think it is possible and/or makes sense to extract all
   changesets from Rob's repo into single patches first, with an
   automatic script or something?
 
 In case you're not aware of it, check out Mercurial Queues
 (http://hgbook.red-bean.com/hgbookch12.html#x16-26500012) which might
 be helpful for this sort of thing.

Also see quilt (http://savannah.nongnu.org/projects/quilt) if you
want to manage patches without Mercurial.  Quilt can be used with svn.

Mercurial Queues (mq) are basically just a direct reimplementation of
quilt, with several improvements because the patch stack and diffing
is integrated into the Mercurial revision history.  If you configure
mq to use git-format patches it can even properly track renames and
other corner cases via patch files.

At work I used to use svn+quilt for all of my development; now I use
mq instead and it's noticably nicer.

  -Dave Dodge


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

Re: [Tinycc-devel] Sample patch from Mercurial repository

[Dave Dodge]

On Mon, Oct 29, 2007 at 02:59:15AM +0800, KHMan wrote:
 Attached is a sample patch based on the Mercurial repository. I
 assume revisions up to 395 is already in the official CVS,

Just a quick note about mercurial: revision numbers such as 395 are
just a convenience and are locally assigned to each copy of the
repository.  They aren't guaranteed to be the same for each user; in
fact local commits will quickly knock them out of sync.  Changeset IDs
such as f357b2f8add5 _are_ kept globally consistent, so if you want to
specify a particular change you can use those.

  -Dave Dodge





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

Re: [Tinycc-devel] Sample patch from Mercurial repository

[KHMan]

Dave Dodge wrote:
 On Mon, Oct 29, 2007 at 02:59:15AM +0800, KHMan wrote:
 Attached is a sample patch based on the Mercurial repository. I
 assume revisions up to 395 is already in the official CVS,
 
 Just a quick note about mercurial: revision numbers such as 395 are
 just a convenience and are locally assigned to each copy of the
 repository.  They aren't guaranteed to be the same for each user; in
 fact local commits will quickly knock them out of sync.  Changeset IDs
 such as f357b2f8add5 _are_ kept globally consistent, so if you want to
 specify a particular change you can use those.

Thanks, I understand, I know some git and I am reading hgbook now.
It was just more convenient with those numbers assuming Seo's
Mercurial bundle is a frozen unit. I guess hg/git people can
correctly say that my brain has been lobotomized by the notion of
SVN revision numbers... :-)

I will be contacting David Wheeler to see if he is interested in
accepting them patches.

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia


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

[Tinycc-devel] Sample patch from Mercurial repository

[KHMan]

Hi all,

Attached is a sample patch based on the Mercurial repository. I
assume revisions up to 395 is already in the official CVS, so
perhaps I shall try and see how many trivial patches I can make
from revision 396 onwards, versus current Savannah CVS. No quality
assurance beyond trying a make all on Ubuntu. Comments?

-- 
Cheers,
Kein-Hong Man (esq.)
Kuala Lumpur, Malaysia

# HG changeset patch
# User [EMAIL PROTECTED]
# Date 1160276413 14400
# Node ID 928147ea8ab65f7f295692021e37586251c3bce6
# Parent  f357b2f8add53b403bfe7edd71c519b4709a1515
Fix invalid relocation entry problem on ubuntu.  Fix from Bernhard
Fischer: http://lists.gnu.org/archive/html/tinycc-devel/2005-09/msg00051.html

diff -urN tinycc_cvs/tccelf.c tinycc_new/tccelf.c
--- tinycc_cvs/tccelf.c 2007-10-29 00:03:55.171875000 +0800
+++ tinycc_new/tccelf.c 2007-10-29 02:38:33.296875000 +0800
@@ -1874,7 +1874,6 @@
 
 /* second short pass to update sh_link and sh_info fields of new
sections */
-sm = sm_table;
 for(i = 1; i  ehdr.e_shnum; i++) {
 s = sm_table[i].s;
 if (!s || !sm_table[i].new_section)
@@ -1888,6 +1887,7 @@
 s1-sections[s-sh_info]-reloc = s;
 }
 }
+sm = sm_table;
 
 /* resolve symbols */
 old_to_new_syms = tcc_mallocz(nb_syms * sizeof(int));
@@ -1949,9 +1949,11 @@
 if (sym_index = nb_syms)
 goto invalid_reloc;
 sym_index = old_to_new_syms[sym_index];
-if (!sym_index) {
+   /* ignore link_once in rel section. */
+if (!sym_index  !sm-link_once) {
 invalid_reloc:
-error_noabort(Invalid relocation entry);
+error_noabort(Invalid relocation entry [%2d] '%s' @ %.8x,
+i, strsec + sh-sh_name, rel-r_offset);
 goto fail;
 }
 rel-r_info = ELF32_R_INFO(sym_index, type);
___
Tinycc-devel mailing list
Tinycc-devel@nongnu.org
http://lists.nongnu.org/mailman/listinfo/tinycc-devel