public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
* gcc 3.2.3 splay tree issue
@ 2024-02-06  0:43 Paul Edwards
  0 siblings, 0 replies; only message in thread
From: Paul Edwards @ 2024-02-06  0:43 UTC (permalink / raw)
  To: GCC Development

[-- Attachment #1: Type: text/plain, Size: 4586 bytes --]

I normally use gcc 3.2.3 to build executables that
work with msvcrt.dll, which has 32-bit int, long and ptr.

I tried changing long to 64 bits and the new compiler
encountered the following issue when attempting to
build itself. Documented and fixed below, unless
someone has a better fix. Note that I maintain this
version to support the i370 target, and I spent a lot
of effort making this source code C90-compliant
(instead of being riddled with Posix dependencies),
so don't bother asking "why don't you update to a
version of gcc that isn't even written in C, and has no
aim to be C90-compliant?".

BFN. Paul.



Index: gcc/c-lex.c
===================================================================
RCS file: \cvsroot/gcc/gcc/c-lex.c,v
retrieving revision 1.9
diff -c -r1.9 c-lex.c
*** gcc/c-lex.c 23 Nov 2022 10:03:57 -0000 1.9
--- gcc/c-lex.c 6 Feb 2024 00:22:30 -0000
***************
*** 108,114 ****
    struct c_fileinfo *toplevel;

    /* Set up filename timing.  Must happen before cpp_read_main_file.  */
!   file_info_tree = splay_tree_new ((splay_tree_compare_fn)strcmp,
    0,
    (splay_tree_delete_value_fn)free);
    toplevel = get_fileinfo ("<top level>");
--- 108,114 ----
    struct c_fileinfo *toplevel;

    /* Set up filename timing.  Must happen before cpp_read_main_file.  */
!   file_info_tree = splay_tree_new (splay_tree_compare_strings,
    0,
    (splay_tree_delete_value_fn)free);
    toplevel = get_fileinfo ("<top level>");
Index: gcc/cppfiles.c
===================================================================
RCS file: \cvsroot/gcc/gcc/cppfiles.c,v
retrieving revision 1.24
diff -c -r1.24 cppfiles.c
*** gcc/cppfiles.c 8 Nov 2022 03:07:45 -0000 1.24
--- gcc/cppfiles.c 6 Feb 2024 00:24:03 -0000
***************
*** 150,156 ****
       cpp_reader *pfile;
  {
    pfile->all_include_files
!     = splay_tree_new ((splay_tree_compare_fn) strcmp,
       (splay_tree_delete_key_fn) free,
       destroy_node);
  }
--- 150,156 ----
       cpp_reader *pfile;
  {
    pfile->all_include_files
!     = splay_tree_new (splay_tree_compare_strings,
       (splay_tree_delete_key_fn) free,
       destroy_node);
  }
Index: include/splay-tree.h
===================================================================
RCS file: \cvsroot/gcc/include/splay-tree.h,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 splay-tree.h
*** include/splay-tree.h 15 Feb 2006 10:23:44 -0000 1.1.1.1
--- include/splay-tree.h 6 Feb 2024 00:21:02 -0000
***************
*** 40,47 ****
--- 40,61 ----
     these types, if necessary.  These types should be sufficiently wide
     that any pointer or scalar can be cast to these types, and then
     cast back, without loss of precision.  */
+
+ /* _cpp_init_includes() in cppfiles.c and init_c_lex in c-lex.c
+    are setting the comparison function to strcmp, which takes pointers,
+    and in a 32-bit pointer and 64-bit long environment, the second
+    pointer to strcmp ends up as NULL. Rather than kludging here to make
+    pointer size match some integer size (assuming that is even possible),
+    I instead created another comparison function
+    (splay_tree_compare_strings). This issue appears to still exist in
+    gcc 3.4.6 */
+ #if 0 /* !defined(__64BIT__) && defined(__LONG64__) */
+ typedef unsigned int splay_tree_key;
+ typedef unsigned int splay_tree_value;
+ #else
  typedef unsigned long int splay_tree_key;
  typedef unsigned long int splay_tree_value;
+ #endif

  /* Forward declaration for a node in the tree.  */
  typedef struct splay_tree_node_s *splay_tree_node;
***************
*** 146,151 ****
--- 160,167 ----
  splay_tree_key));
  extern int splay_tree_compare_pointers  PARAMS((splay_tree_key,
  splay_tree_key));
+ extern int splay_tree_compare_strings   PARAMS((splay_tree_key,
+ splay_tree_key));

  #ifdef __cplusplus
  }
Index: libiberty/splay-tree.c
===================================================================
RCS file: \cvsroot/gcc/libiberty/splay-tree.c,v
retrieving revision 1.1.1.1
diff -c -r1.1.1.1 splay-tree.c
*** libiberty/splay-tree.c 15 Feb 2006 10:23:47 -0000 1.1.1.1
--- libiberty/splay-tree.c 6 Feb 2024 00:28:03 -0000
***************
*** 33,38 ****
--- 33,39 ----
  #endif

  #include <stdio.h>
+ #include <string.h>

  #include "libiberty.h"
  #include "splay-tree.h"
***************
*** 557,559 ****
--- 558,570 ----
    else
      return 0;
  }
+
+ /* Splay-tree comparison function, treating the keys as strings.  */
+
+ int
+ splay_tree_compare_strings (k1, k2)
+      splay_tree_key k1;
+      splay_tree_key k2;
+ {
+   return (strcmp((char *)k1, (char *)k2));
+ }

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2024-02-06  0:43 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-02-06  0:43 gcc 3.2.3 splay tree issue Paul Edwards

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).