This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676
- From: "rdapp at linux dot vnet.ibm.com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 28 Nov 2017 09:10:29 +0000
- Subject: [Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676
- Auto-submitted: auto-generated
- References: <bug-83069-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83069
rdapp at linux dot vnet.ibm.com changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |rdapp at linux dot vnet.ibm.com
--- Comment #11 from rdapp at linux dot vnet.ibm.com ---
416.gamess fails on S390 as well since r254888.
I didn't immediately get what the
if (freq_max < 16)
freq_max = 16;
part of the patch is supposed to achieve. When freq_max < 16, tmp will later be
larger than BLOCK_INFO (bb)->frequency which wasn't the case before. In the
worst case we approach max_count by 4 bits every time.
Why do we need a minimum freq_max? To ensure some scaling even for low
frequencies?