[Bug target/43613] New: Some architecture-dependent codes

[Bug target/43613] New: Some architecture-dependent codes

[aflyhorse at foxmail dot com]

Sorry to duplicately reporting this bug, but i failed to get a feedback after i
announced it after another small bug unfortunately.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43477


/libcpp/files.c: Line 609-614:
comparison is always false under win x64

and

/gcc/emit-rtl.c: Line 361:
/gcc/ggc-common.c: Line 310:
/gcc/graphite-dependences.c: Line 107:
/gcc/src/gcc/ira-conflicts.c: Line 125:
/gcc/src/gcc/pointer-set.c: Line 67:
/gcc/src/gcc/tree dump: Line 168:
/gcc/src/gcc/cp/class.c: Line 6740, 6742, 6764, 6767, 6900:

all have host-dependent code such as explictly cast a pointer to long (in win
x64 means long long to long) and use %ld or &lx to fprintf a pointer.

they cause the cc1 treat warnings as error and stop the make procedure, though
they are easy to fix manually but quite annoying while making bootstrap.

maybe needs to change their type to be ssize_t & size_t?

(These are gcc 4.5.0 20100322 version source)


-- 
           Summary: Some architecture-dependent codes
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: aflyhorse at foxmail dot com
 GCC build triplet: x86_64-w64-mingw32
  GCC host triplet: x86_64-w64-mingw32
GCC target triplet: x86_64-w64-mingw32


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

[Bug target/43613] Some architecture-dependent codes

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2010-04-01 01:15 -------
>gcc/src/gcc/ira-conflicts.c: Line 125:
That is printing out a long correctly (has no pointers in it, though it does
have a sizeof).

>gcc/src/gcc/tree-dump.c: Line 168:
/gcc/src/gcc/cp/class.c: Line 6740, 6742, 6764, 6767, 6900:
Yes those need to be fixed, %p should be used but I cannot remember if that was
in K&R C, we only require K&R C library while a C90 compiler :).

The others are used for hashes and should be changed but don't make a
difference.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

[Bug target/43613] Some architecture-dependent codes

[aflyhorse at foxmail dot com]

------- Comment #2 from aflyhorse at foxmail dot com  2010-04-01 08:23 -------
Got your ideas and be sorry for i chobber the building tree of my computer and
the tree of package, there shouldn't be /gcc/src in the path (I was confused
when i'm looking for the file myself)

that time i'm testing the  --enable-hash-synchronization option

And could you please tell me why I always fail to build libgcj (after make
install type "gcj -v" it tells me that libgcj.spec is missing and i find no
libgcj.a & .la in my lib directory) even if i added "--enable-libgcj
--enable-libjava" in configure?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

[Bug target/43613] Some architecture-dependent codes

[aflyhorse at foxmail dot com]

------- Comment #3 from aflyhorse at foxmail dot com  2010-04-01 08:26 -------
Also, the compiler do stopped and treat warnings as errors while compiling
ira-conflicts.c until i changed these 2 "%ld" to "%I64u"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

[Bug target/43613] Some architecture-dependent codes

[aflyhorse at foxmail dot com]

------- Comment #4 from aflyhorse at foxmail dot com  2010-04-12 10:44 -------
Maybe I should still choose the proprietary compiler of M$ for my
Win_x64-target platform...


-- 

aflyhorse at foxmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |WONTFIX


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

[Bug target/43613] Some architecture-dependent codes

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2010-04-12 14:12 -------
I don't get why you closed this bug. Anyways if you have a patch, post it to
gcc-patches@. 


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |UNCONFIRMED
         Resolution|WONTFIX                     |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

[Bug target/43613] Some architecture-dependent codes

[aflyhorse at foxmail dot com]

------- Comment #6 from aflyhorse at foxmail dot com  2010-04-13 10:58 -------
(In reply to comment #5)
> I don't get why you closed this bug. Anyways if you have a patch, post it to
> gcc-patches@. 

Sorry, I see nobody concerns this, and I'm more anxious about how to port the
libgcj (especially boehm-gc) to win64, so I closed it.
Maybe i should use the diff to release a patch for it~ (Since I'm a newbee I've
never done so :P)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

[Bug target/43613] Some architecture-dependent codes

[aflyhorse at foxmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

Chen Chen <aflyhorse at foxmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #11 from Chen Chen <aflyhorse at foxmail dot com> ---
Sure. After years I have to click "forgot my pwd" to regain this account.
Thanks for all the hard works done by everyone.

[Bug target/43613] Some architecture-dependent codes

[nightstrike at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

--- Comment #10 from nightstrike <nightstrike at gmail dot com> ---
Patch thread started here:

https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644674.html
https://inbox.sourceware.org/gcc-patches/4700e066-1b50-4e7b-92f7-d8c33a330bbf@gmail.com/

and ended with this solution:

https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644701.html
https://inbox.sourceware.org/gcc-patches/Zbu34FTR73081bMb@tucnak/


which was committed in r14-8898-g2bb4556220285e.

I believe based on comment 7, this can now be closed.

[Bug target/43613] Some architecture-dependent codes

[xry111 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

Xi Ruoyao <xry111 at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |xry111 at gcc dot gnu.org

--- Comment #9 from Xi Ruoyao <xry111 at gcc dot gnu.org> ---
(In reply to nightstrike from comment #8)
> (In reply to Andrew Pinski from comment #7)
> > So just this one left I think:
> > 
> > /gcc/src/gcc/ira-conflicts.c: Line 125:
> > 
> > Still there, size_t is long long (64bits) while long is 32bits.
> 
> Assuming this is now line 153:
> 
> ```
> diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc
> index a4d93c8d734..4f2c2bdfebc 100644
> --- a/gcc/ira-conflicts.cc
> +++ b/gcc/ira-conflicts.cc
> @@ -150,9 +150,9 @@ build_conflict_bit_table (void)
>    if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL)
>      fprintf
>        (ira_dump_file,
> -       "+++Allocating %ld bytes for conflict table (uncompressed size
> %ld)\n",
> -       (long) allocated_words_num * sizeof (IRA_INT_TYPE),
> -       (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE));
> +       "+++Allocating %zu bytes for conflict table (uncompressed size
> %zu)\n",
> +       (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)),
> +       (size_t)(object_set_words * ira_objects_num * sizeof
> (IRA_INT_TYPE)));
> 
>    objects_live = sparseset_alloc (ira_objects_num);
>    for (i = 0; i < ira_max_point; i++)
> ```
> 
> Perhaps that will address the remaining issue?

Post patches to gcc-patches instead of bugzilla.  The patches in bugzilla are
not considered candidates to be applied for trunk.

[Bug target/43613] Some architecture-dependent codes

[nightstrike at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

nightstrike <nightstrike at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nightstrike at gmail dot com

--- Comment #8 from nightstrike <nightstrike at gmail dot com> ---
(In reply to Andrew Pinski from comment #7)
> So just this one left I think:
> 
> /gcc/src/gcc/ira-conflicts.c: Line 125:
> 
> Still there, size_t is long long (64bits) while long is 32bits.

Assuming this is now line 153:

```
diff --git a/gcc/ira-conflicts.cc b/gcc/ira-conflicts.cc
index a4d93c8d734..4f2c2bdfebc 100644
--- a/gcc/ira-conflicts.cc
+++ b/gcc/ira-conflicts.cc
@@ -150,9 +150,9 @@ build_conflict_bit_table (void)
   if (internal_flag_ira_verbose > 0 && ira_dump_file != NULL)
     fprintf
       (ira_dump_file,
-       "+++Allocating %ld bytes for conflict table (uncompressed size %ld)\n",
-       (long) allocated_words_num * sizeof (IRA_INT_TYPE),
-       (long) object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE));
+       "+++Allocating %zu bytes for conflict table (uncompressed size %zu)\n",
+       (size_t)(allocated_words_num * sizeof (IRA_INT_TYPE)),
+       (size_t)(object_set_words * ira_objects_num * sizeof (IRA_INT_TYPE)));

   objects_live = sparseset_alloc (ira_objects_num);
   for (i = 0; i < ira_max_point; i++)
```

Perhaps that will address the remaining issue?

[Bug target/43613] Some architecture-dependent codes

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=53912

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
/gcc/emit-rtl.c: Line 361:
Fixed by r0-106223

/gcc/ggc-common.c: Line 310:
r0-120670 (PR 53912)

/gcc/graphite-dependences.c: Line 107:

Removed. 

/gcc/src/gcc/pointer-set.c: Line 67:

File full removed in 2014.

/gcc/src/gcc/tree-dump.c: Line 168:

Fixed by r0-120669 (53912)

/gcc/src/gcc/cp/class.c: Line 6740, 6742, 6764, 6767, 6900:
Fixed by r0-120604 (PR 53912)


So just this one left I think:

/gcc/src/gcc/ira-conflicts.c: Line 125:

Still there, size_t is long long (64bits) while long is 32bits.