[Bug tree-optimization/103456] [12 Regression] gcc/gcc.c:9502:8: runtime error: load of address 0x0000009f5037 with insufficient space for an object of type 'const char' since r12-5548-g4a2007594cff78
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103456 Siddhesh Poyarekar changed: What|Removed |Added CC||siddhesh at gotplt dot org --- Comment #1 from Siddhesh Poyarekar --- I'm looking at this, I don't seem to have the right blessings to assign it to myself though.
[Bug middle-end/101397] [11 Regression] spurious warning writing to the result of stpcpy minus 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101397
Siddhesh Poyarekar changed:
What|Removed |Added
CC||siddhesh at gotplt dot org
--- Comment #7 from Siddhesh Poyarekar ---
(In reply to CVS Commits from comment #4)
> The master branch has been updated by Martin Sebor :
>
> https://gcc.gnu.org/g:8bf5b49ebd2176b8c535147377381dd07fbdd643
>
> commit r12-2422-g8bf5b49ebd2176b8c535147377381dd07fbdd643
> Author: Martin Sebor
> Date: Tue Jul 20 13:48:20 2021 -0600
>
> Correct stpcpy offset computation for -Warray-bounds et al. [PR101397].
This causes a crash with the following program due to an infinite recursion:
typedef __SIZE_TYPE__ size_t;
void
__attribute__ ((noinline))
foo (size_t x)
{
struct T { char buf[64]; char buf2[64]; } t;
char *p = [8];
char *r = t.buf2;
size_t i;
for (i = 0; i < x; i++)
{
r = __builtin_mempcpy (r, p, i);
p = r + 1;
}
}
$ cc1.r12-2422 -quiet -o - repro.c
.file "repro.c"
.text
Segmentation fault (core dumped)
[Bug middle-end/101836] __builtin_object_size(P->M, 1) where M is an array and the last member of a struct fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101836 Siddhesh Poyarekar changed: What|Removed |Added CC||siddhesh at gotplt dot org --- Comment #5 from Siddhesh Poyarekar --- Vim explicitly disables _FORTIFY_SOURCE to keep its use of 1-sized trailing arrays: https://github.com/vim/vim/issues/5581 so either they haven't tested with more recent gcc or they're hitting a corner case where __builtin_object_size does return the subscript value for the trailing member. I inherited the __builtin_object_size behaviour in __builtin_dynamic_object_size to remain consistent with current behaviour: ok: sizeof(*working) == 24 ok: sizeof(working->c) == 16 ok: __builtin_object_size(working, 1) == -1 ok: __builtin_object_size(working->c, 1) == 16 ok: __builtin_dynamic_object_size(working, 1) == -1 ok: __builtin_dynamic_object_size(working->c, 1) == 16 ok: sizeof(*broken) == 24 ok: sizeof(broken->c) == 16 ok: __builtin_object_size(broken, 1) == -1 WAT: __builtin_object_size(broken->c, 1) == -1 (expected 16) ok: __builtin_dynamic_object_size(broken, 1) == -1 WAT: __builtin_dynamic_object_size(broken->c, 1) == -1 (expected 16) However in theory if the pass can see the allocation, it should be able to build the right expression for object size. I'm updating the patchset to meld the two passes into one and I could add -fstrict-flex-arrays as one of the patches to make this stricter.
[Bug demangler/88783] integer overflow in libiberty, heap overflow will be triggered in nm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88783 Siddhesh Poyarekar changed: What|Removed |Added CC||siddhesh at gotplt dot org --- Comment #9 from Siddhesh Poyarekar --- gcc version of libiberty hasn't had this issue since the following change which removed the potential overflow. The POC also appears fixed with binutils 2.35; from code inspection it should be fixed in 2.32 and later. This ought to be closed. ommit 6c8120c5ff130e03d32ff15a8f0d0e703592a2af Author: Jason Merrill Date: Sat Dec 22 19:06:34 2018 -0500 Remove support for demangling GCC 2.x era mangling schemes. libiberty/ * cplus-dem.c: Remove cplus_mangle_opname, cplus_demangle_opname, internal_cplus_demangle, and all subroutines. (libiberty_demanglers): Remove entries for ancient GNU (pre-3.0), Lucid, ARM, HP, and EDG demangling styles. (cplus_demangle): Remove 'work' variable. Don't call internal_cplus_demangle. include/ * demangle.h: Remove support for ancient GNU (pre-3.0), Lucid, ARM, HP, and EDG demangling styles. From-SVN: r267363
[Bug target/87330] ICE in scan_rtx_reg, at regrename.c:1097
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87330 --- Comment #2 from Siddhesh Poyarekar --- Thanks, I'll take a look. Kyrill can you please assign the bug to me? I don't seem to have to chops to edit the bz.
[Bug c/84531] c/c++: bogus warning for functions with different argument lengths but compatible arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531 Siddhesh Poyarekar changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #5 from Siddhesh Poyarekar --- Yeah that doesn't look good. I had not done a cpython build; I had started with a gem5 build (which builds python modules) and only superficially looked at cpython. I thought about this over the weekend and agree that silencing the warning will only hold us back indefinitely. I'll look at the cpython build a bit closer and try to fix it there when I have time for it. Thanks for looking into this.
[Bug c/84531] c/c++: bogus warning for functions with different argument lengths but compatible arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531 --- Comment #2 from Siddhesh Poyarekar --- There's also a PyCFunctionWithoutArgs that takes just one parameter so it'll have to be one arg onwards but I don't know the impact on it's API. I'm going to test that when I get back home tonight and propose a fix in Python. I kinda understand the rationale behind not diluting the warning, but I'd like to keep this open pending conclusion of the discussion on the ML.
[Bug c/84531] New: c/c++: bogus warning for functions with different argument lengths but compatible arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531 Bug ID: 84531 Summary: c/c++: bogus warning for functions with different argument lengths but compatible arguments Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: siddhesh at gotplt dot org Target Milestone: --- gcc trunk throws a bogus warning about incompatible function cast when the cast target and the function have different argument lengths but the same arguments for the common subset. An example of this is the PyCFunction <-> PyCFunctionWithKeywords cast in python. Patch posted along with test case: https://gcc.gnu.org/ml/gcc-patches/2018-02/msg01315.html
[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83069 --- Comment #13 from Siddhesh Poyarekar --- (In reply to David Binderman from comment #7) > Maybe some more extensive testing of your patch would increase > the chances of it being accepted. make check just finished on aarch64 and saw no failures due to this patch. make check on aarch64 is almost on its last legs and shows now new failures either.
[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83069 --- Comment #12 from Siddhesh Poyarekar --- (In reply to rdapp from comment #11) > 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? I suppose the minimum frequency is to prevent loss of precision in the lower frequencies (they may get rounded off to 0 in the profile counts since they're integers) when the max_freq is greater than max_real_bb_freq. It is consistent with earlier behaviour and the higher max_real_bb_freq should give us a net win anyway.
[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83069 --- Comment #6 from Siddhesh Poyarekar --- (In reply to Siddhesh Poyarekar from comment #5) > This fixes the problem for me. freq_max < 1, i.e. freq_max of one of the > bbs in the function means that it ends up having a profile count larger than Sorry, that bit should read as "freq_max < 1, i.e. highest frequency among bbs in the function being higher than real_bb_freq_max means that the bb ends up with a profile count larger than real_bb_freq_max and then can go all the way up to and beyond profile_count::max_count".
[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83069 --- Comment #5 from Siddhesh Poyarekar --- This fixes the problem for me. freq_max < 1, i.e. freq_max of one of the bbs in the function means that it ends up having a profile count larger than 2^30 since the freq_max gets reset to 16. Dropping this reset makes sure that the profile counts are always correctly normalized to real_bb_freq_max: diff --git a/gcc/predict.c b/gcc/predict.c index 0f34956..ff9b5a9 100644 --- a/gcc/predict.c +++ b/gcc/predict.c @@ -3613,8 +3613,6 @@ estimate_bb_frequencies (bool force) freq_max = BLOCK_INFO (bb)->frequency; freq_max = real_bb_freq_max / freq_max; - if (freq_max < 16) - freq_max = 16; profile_count ipa_count = ENTRY_BLOCK_PTR_FOR_FN (cfun)->count.ipa (); cfun->cfg->count_max = profile_count::uninitialized (); FOR_BB_BETWEEN (bb, ENTRY_BLOCK_PTR_FOR_FN (cfun), NULL, next_bb)
[Bug middle-end/83069] [8 Regression] internal compiler error: in from_gcov_type, at profile-count.h:676
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83069
--- Comment #4 from Siddhesh Poyarekar ---
Reduced C test case:
#define MAX 98
void foo (unsigned long *res, unsigned long in)
{
for (unsigned long a = 0; a < MAX; a++)
for (unsigned long b = 0; b < MAX; b++)
for (unsigned long c = 0; c < MAX; c++)
for (unsigned long d = 0; d < MAX; d++)
for (unsigned long e = 0; e < MAX; e++)
for (unsigned long f = 0; f < MAX; f++)
for (unsigned long g = 0; g < MAX; g++)
*res += a * in;
}
foo.c: In function 'foo':
foo.c:13:1: internal compiler error: in from_gcov_type, at profile-count.h:676
}
^
0xaaf57f profile_count::from_gcov_type(long)
/home/siddhesh/src/gcc/gcc/profile-count.h:676
0xaaf57f estimate_bb_frequencies(bool)
/home/siddhesh/src/gcc/gcc/predict.c:3623
0xab40af tree_estimate_probability(bool)
/home/siddhesh/src/gcc/gcc/predict.c:2849
0xab45c3 execute
/home/siddhesh/src/gcc/gcc/predict.c:3760
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
