On 3/31/23 19:31, Hans-Peter Nilsson wrote:
Date: Fri, 31 Mar 2023 15:48:22 -0400
From: Andrew MacLeod via Gcc-patches
Reply-To: Andrew MacLeod
commit 55bf4f0d443e5adbacfcdbbebf4b2e0c74d1dcc8
Author: Andrew MacLeod
Date: Fri Mar 31 15:42:43 2023 -0400
Adjust testcases to not produce
> Date: Fri, 31 Mar 2023 15:48:22 -0400
> From: Andrew MacLeod via Gcc-patches
> Reply-To: Andrew MacLeod
> commit 55bf4f0d443e5adbacfcdbbebf4b2e0c74d1dcc8
> Author: Andrew MacLeod
> Date: Fri Mar 31 15:42:43 2023 -0400
>
> Adjust testcases to not produce errors..
>
> tr
On 3/31/23 14:16, Andrew MacLeod wrote:
On 3/31/23 15:59, Jeff Law wrote:
On 3/31/23 13:48, Andrew MacLeod wrote:
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Go ahead and tweak the testcase. Unless you want to revamp it per
Jak
On 3/31/23 15:59, Jeff Law wrote:
On 3/31/23 13:48, Andrew MacLeod wrote:
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Go ahead and tweak the testcase. Unless you want to revamp it per
Jakub's suggestions.
not particularly :-)
On 3/31/23 13:48, Andrew MacLeod wrote:
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Go ahead and tweak the testcase. Unless you want to revamp it per
Jakub's suggestions.
jeff
should we do something like this to tweak the testcases? or does
someone have something else in mind?
Richi opened a PR for the STL failure (109350)
Andrew
On 3/31/23 13:37, Jakub Jelinek wrote:
On Fri, Mar 31, 2023 at 01:02:18PM -0400, Andrew MacLeod wrote:
I guess it figures the reci
On Fri, Mar 31, 2023 at 01:02:18PM -0400, Andrew MacLeod wrote:
> I guess it figures the recip is safe to put in, there will not be a divide
> by zero.
I think the problem was that 1/d was hoisted before the loop; as long as
it is guarded with the d > 0.01 or e > 0.005 condition, it is fine.
The t
On 3/31/23 12:20, Jeff Law wrote:
On 3/31/23 10:12, Hans-Peter Nilsson via Gcc-patches wrote:
Attached. I also removed the bogus warning in Walloc-13.c that no
longer
happens
Add recursive GORI recompuations with a depth limit.
PR tree-optimization/109154
On 3/31/23 10:12, Hans-Peter Nilsson via Gcc-patches wrote:
Attached. I also removed the bogus warning in Walloc-13.c that no longer
happens
Add recursive GORI recompuations with a depth limit.
PR tree-optimization/109154
gcc/
* gimple-rang
> Attached. I also removed the bogus warning in Walloc-13.c that no longer
> happens
> Add recursive GORI recompuations with a depth limit.
>
> PR tree-optimization/109154
> gcc/
> * gimple-range-gori.cc (gori_compute::may_recompute_p): Add depth
> li
On Thu, Mar 30, 2023 at 1:40 PM Andrew MacLeod via Gcc-patches
wrote:
>
> I committed it. ran it again for fun. sigh. Looks like its also
> triggering another issue now in g++.dg/warn/Wstringop-overflow-4.C
> where its issuing:
libstdc++v3's 23_containers/vector/bool/allocator/copy.cc fails m
I committed it. ran it again for fun. sigh. Looks like its also
triggering another issue now in g++.dg/warn/Wstringop-overflow-4.C
where its issuing:
b.C: In function ‘void test_strcpy_new_int16_t(size_t, const size_t*)’:
b.C:76:12: warning: ‘void* __builtin_memcpy(void*, const void*, long
On Thu, Mar 30, 2023 at 11:58:19AM -0400, Andrew MacLeod wrote:
>
> On 3/30/23 09:41, Jakub Jelinek wrote:
> > On Wed, Mar 29, 2023 at 01:22:27PM -0400, Andrew MacLeod wrote:
> > > however, as seems to be the case often, better ranges result in, I now
> > > get:
> > >
> > > FAIL: 23_containers/v
On 3/30/23 09:41, Jakub Jelinek wrote:
On Wed, Mar 29, 2023 at 01:22:27PM -0400, Andrew MacLeod wrote:
however, as seems to be the case often, better ranges result in, I now get:
FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
Our middle-end warnings are just badly
On Wed, Mar 29, 2023 at 01:22:27PM -0400, Andrew MacLeod wrote:
> however, as seems to be the case often, better ranges result in, I now get:
>
> FAIL: 23_containers/vector/bool/allocator/copy.cc (test for excess errors)
Our middle-end warnings are just badly designed :(, the better value ranges
On Wed, Mar 29, 2023 at 7:22 PM Andrew MacLeod wrote:
>
> The patch, or a slight variation (attached), in the PR allows us to
> generate better ranges be recomputing longer instruction sequences on
> outgoing edges.
>
> This in fact also fixes
> XPASS: gcc.dg/Walloca-13.c (test for bogus messages
The patch, or a slight variation (attached), in the PR allows us to
generate better ranges be recomputing longer instruction sequences on
outgoing edges.
This in fact also fixes
XPASS: gcc.dg/Walloca-13.c (test for bogus messages, line 11)
[local count: 1073741824]:
_1 = p_5(D) - q_6(D);
17 matches
Mail list logo
