On 11/23/23 10:05, Hans-Peter Nilsson wrote:
From: Hans-Peter Nilsson <h...@axis.com>
Date: Thu, 16 Nov 2023 05:24:06 +0100
From: Martin Uecker <uec...@tugraz.at>
Date: Tue, 07 Nov 2023 06:56:25 +0100
Am Montag, dem 06.11.2023 um 21:01 -0700 schrieb Jeff Law:
On 11/6/23 20:58, Hans-Peter Nilsson wrote:
This patch caused a testsuite regression: there's now an
"excess error" failure for gcc.dg/Wnonnull-4.c for 32-bit
targets (and 64-bit targets testing with a "-m32" option)
after your r14-5115-g6e9ee44d96e5. It's logged as PR112419.
It caused failures for just about every target ;( Presumably it worked
on x86_64...
I do not think this is a true regression
just a problem with the test on 32-bit which somehow surfaced
due to the change.
The excess error is:
FAIL: gcc.dg/Wnonnull-4.c (test for excess errors)
Excess errors:
/home/tcwg-buildslave/workspace/tcwg_gnu_6/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/Wnonnull-4.c:144:3:
warning: 'fda_n_5' specified size 4294967256 exceeds maximum object size
2147483647 [-Wstringop-overflow=]
I think the warning was suppressed before due to the other (nonnull)
warning which I removed in this case.
I think the simple fix might be to to turn off -Wstringop-overflow.
No, that trigs many of the dg-warnings that are tested.
(I didn't pay attention to the actual warning messages and
tried to pursue that at first.)
Maybe think it's best to actually expect the warning, like
so.
Maintainers of 16-bit targets will have to address their
concerns separately. For example, they may choose to not
run the test at all.
Ok to commit?
Subject: [PATCH] gcc.dg/Wnonnull-4.c: Handle new overflow warning for 32-bit
targets [PR112419]
PR testsuite/112419
* gcc.dg/Wnonnull-4.c (test_fda_n_5): Expect warning for exceeding
maximum object size for 32-bit targets.
---
gcc/testsuite/gcc.dg/Wnonnull-4.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/gcc/testsuite/gcc.dg/Wnonnull-4.c
b/gcc/testsuite/gcc.dg/Wnonnull-4.c
index 1f14fbba45df..d63e76da70a2 100644
--- a/gcc/testsuite/gcc.dg/Wnonnull-4.c
+++ b/gcc/testsuite/gcc.dg/Wnonnull-4.c
@@ -142,6 +142,7 @@ void test_fda_n_5 (int r_m1)
T ( 1); // { dg-bogus "argument 2 of variable length array
'double\\\[n]\\\[5]' is null but the corresponding bound argument 1 value is 1" }
T ( 9); // { dg-bogus "argument 2 of variable length array
'double\\\[n]\\\[5]' is null but the corresponding bound argument 1 value is 9" }
T (max); // { dg-bogus "argument 2 of variable length array
'double\\\[n]\\\[5]' is null but the corresponding bound argument 1 value is \\d+" }
+// { dg-warning "size 4294967256 exceeds maximum object size" "" { target
ilp32 } .-1 }
}
Unfortunately I think we need to go back to the original issue that
Martin (I think) dismissed.
Specifically, this is a regression. It's very clear that prior to the
patch in question there was no diagnostic about the size of the
requested memory allocation and after the patch in question we get the
"exceeds maximum object size" diagnostic.
Now one explanation could be that the diagnostic is warranted and it was
a bug that the diagnostic hadn't been emitted prior to Martin's patch.
In this case some kind of dg-blah is warranted, but I don't think anyone
has made this argument.
Jeff
