This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug bootstrap/80447] Profiled LTO bootstrap fails on powerpc64le


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

--- Comment #11 from Martin Sebor <msebor at gcc dot gnu.org> ---
(In reply to Markus Trippelsdorf from comment #10)
> (In reply to Martin Sebor from comment #9)
> >
> > It's possible that the path is not reachable and GCC doesn't see it.
> 
> Well, 18 exabytes allocations or memsets would not go unnoticed for very
> long...

The other possibility is that the path is reachable but not exercised.

If it is not reachable GCC could be enhanced to see that (or to eliminate the
call/branch based on the fact that the excessive memset is invalid and would
surely fail).  If it is reachable, the code path leading up to it could be
changed to eliminate this case.  Either way, the warning suggests an
opportunity for improving the compiler.

Anyway, I've tried the two approaches I mentioned in comment #9.  As expected,
adding the assert eliminates the warning (I'm still running tests).  But
changing the type of rtvec_alloc's argument from int to unsigned causes GCC to
fail to allocate memory early on during bootstrap.  I don't know why yet.  I
could be missing something about how the argument or the function is used or
there could be some bug somewhere.

index 1f6a77a..b29c4e0 100644
--- a/gcc/rtl.c
+++ b/gcc/rtl.c
@@ -150,6 +150,8 @@ rtvec_alloc (int n)
 {
   rtvec rt;

+  gcc_assert (0 <= n);
+
   rt = ggc_alloc_rtvec_sized (n);
   /* Clear out the vector.  */
   memset (&rt->elem[0], 0, n * sizeof (rtx));

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]