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
