diff mbox series

[testsuite,committed] Require et alloca for Wstringop-overflow-3.c

Message ID aa1435b8-c05f-91f3-4b74-349a9c7ee0a7@mentor.com
State New
Headers show
Series [testsuite,committed] Require et alloca for Wstringop-overflow-3.c | expand

Commit Message

Tom de Vries Feb. 15, 2018, 2:10 p.m. UTC
Hi,

this patch requires effective target alloca for test-case 
Wstringop-overflow-3.c.

Committed.

Thanks,
- Tom

Comments

Martin Sebor Feb. 15, 2018, 6:01 p.m. UTC | #1
Thanks.  I've seen these fixes before but I still keep forgetting
to add the directive.  It would be nice if the test harness could
detect this automatically for us and remind us to add the directive
even on targets where alloca is supported.

Some sort of a script (or even DejaGnu itself) would do it for
explicit calls to alloca but I can't think of a solution for
VLAs.  Do you have any idea if that might be doable and how?

Martin

On 02/15/2018 07:10 AM, Tom de Vries wrote:
> Hi,
>
> this patch requires effective target alloca for test-case
> Wstringop-overflow-3.c.
>
> Committed.
>
> Thanks,
> - Tom
Tom de Vries Feb. 16, 2018, 8:14 a.m. UTC | #2
On 02/15/2018 07:01 PM, Martin Sebor wrote:
> Thanks.  I've seen these fixes before but I still keep forgetting
> to add the directive.

Hi,

I also forget about these directives when I do an x86_64 build-test-commit.

The alloca effective target is one of a bunch of effective targets that 
are formulated generically, but implementationwise are currently just a 
test for the nvptx target. So, I fix these test compilation fails when I 
run into them for nvptx target build & test.

> It would be nice if the test harness could
> detect this automatically for us and remind us to add the directive
> even on targets where alloca is supported.
> 

Agreed, that would be nice.

> Some sort of a script (or even DejaGnu itself) would do it for
> explicit calls to alloca but I can't think of a solution for
> VLAs.  Do you have any idea if that might be doable and how?
> 

I suppose it could be done by modifying the compiler: have the compiler 
print out the effective targets it requires for a test-case, if passed 
some switch, and have dejagnu pass the switch, parse the information, 
and emit a warning if an actually required effective target is not 
listed as required in the test-case.

It also could be done without modifying the compiler by dumping a tree 
file and grepping, but it sounds more fragile to me. Maybe for alloca 
the grepping method would work, but for other rarely-false effective 
targets it could be harder.

Thanks,
- Tom

> Martin
> 
> On 02/15/2018 07:10 AM, Tom de Vries wrote:
>> Hi,
>>
>> this patch requires effective target alloca for test-case
>> Wstringop-overflow-3.c.
>>
>> Committed.
>>
>> Thanks,
>> - Tom
>
Martin Sebor Feb. 16, 2018, 5 p.m. UTC | #3
On 02/16/2018 01:14 AM, Tom de Vries wrote:
> On 02/15/2018 07:01 PM, Martin Sebor wrote:
>> Thanks.  I've seen these fixes before but I still keep forgetting
>> to add the directive.
>
> Hi,
>
> I also forget about these directives when I do an x86_64 build-test-commit.
>
> The alloca effective target is one of a bunch of effective targets that
> are formulated generically, but implementationwise are currently just a
> test for the nvptx target. So, I fix these test compilation fails when I
> run into them for nvptx target build & test.
>
>> It would be nice if the test harness could
>> detect this automatically for us and remind us to add the directive
>> even on targets where alloca is supported.
>>
>
> Agreed, that would be nice.
>
>> Some sort of a script (or even DejaGnu itself) would do it for
>> explicit calls to alloca but I can't think of a solution for
>> VLAs.  Do you have any idea if that might be doable and how?
>>
>
> I suppose it could be done by modifying the compiler: have the compiler
> print out the effective targets it requires for a test-case, if passed
> some switch, and have dejagnu pass the switch, parse the information,
> and emit a warning if an actually required effective target is not
> listed as required in the test-case.
>
> It also could be done without modifying the compiler by dumping a tree
> file and grepping, but it sounds more fragile to me. Maybe for alloca
> the grepping method would work, but for other rarely-false effective
> targets it could be harder.

Yes, I also wondered about scanning some dump.  It seemed a bit
too much to have to do that for every test.  Maybe it wouldn't
be so bad but I suspect it may not be enough for all the others
kinds of optional things there are DejaGnu directives for.

Your first suggestion sounds much more robust and (IIUC) could
be used even beyond the test suite to detect target dependencies
in code and issue portability warnings.  It seems that it would
require tracking every optional or target-dependent feature as
it's encountered in source code and either issuing warnings or
printing their summary at the end of translation.

Another common mistake I run into, besides forgetting about VLA
and alloca, is embedding data-model assumptions into test cases
(typically LP64).  It would be great to be able to detect those
as well.

Let me think about this some more.

Thanks
Martin

>
> Thanks,
> - Tom
>
>> Martin
>>
>> On 02/15/2018 07:10 AM, Tom de Vries wrote:
>>> Hi,
>>>
>>> this patch requires effective target alloca for test-case
>>> Wstringop-overflow-3.c.
>>>
>>> Committed.
>>>
>>> Thanks,
>>> - Tom
>>
>
diff mbox series

Patch

[testsuite] Require et alloca for Wstringop-overflow-3.c

2018-02-15  Tom de Vries  <tom@codesourcery.com>

	* gcc.dg/Wstringop-overflow-3.c: Require effective target alloca.

---
 gcc/testsuite/gcc.dg/Wstringop-overflow-3.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.dg/Wstringop-overflow-3.c b/gcc/testsuite/gcc.dg/Wstringop-overflow-3.c
index 5901844..6c8cbf3 100644
--- a/gcc/testsuite/gcc.dg/Wstringop-overflow-3.c
+++ b/gcc/testsuite/gcc.dg/Wstringop-overflow-3.c
@@ -1,6 +1,7 @@ 
 /* PR tree-optimization/84238 */
 /* { dg-do compile } */
 /* { dg-options "-O2" } */
+/* { dg-require-effective-target alloca } */
 
 char a[1];
 int b;