[Bug target/43613] Some architecture-dependent codes

2024-02-19 Thread aflyhorse at foxmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

Chen Chen  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #11 from Chen Chen  ---
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

2024-02-17 Thread nightstrike at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

--- Comment #10 from nightstrike  ---
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-d8c33a330...@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

2024-01-15 Thread xry111 at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

Xi Ruoyao  changed:

   What|Removed |Added

 CC||xry111 at gcc dot gnu.org

--- Comment #9 from Xi Ruoyao  ---
(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

2024-01-15 Thread nightstrike at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #8 from nightstrike  ---
(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

2021-09-19 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43613

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
/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

2010-04-13 Thread 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-patc...@. 

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

2010-04-12 Thread 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

2010-04-12 Thread 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-patc...@. 


-- 

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

2010-04-01 Thread 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

2010-04-01 Thread 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

2010-03-31 Thread 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 KR C, we only require KR 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