[Bug target/43613] Some architecture-dependent codes

[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.

[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

[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

--- 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

[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

[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

[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 #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

[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 #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

[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