On 10/30/2015 04:54 AM, Bernd Schmidt wrote:
The counter is that when grepping, you should probably be using
find/xargs grep :-)
There's actually a tool called ack which automates that. But we've often
seen cases where people fail to spot occurrences in config/ directories.
We certainly have. Never saw "ack" before, I wonder if I can retrain
myself to use it over find/grep :-) And it does seem damn fast.
I think tests for things like bitmap or wide-int could well live at the
end of the respective source files - this would be the most convenient
location so that if you add a new bitmap function, you can immediately
add tests as well.
It has benefits as you noted above. What I don't like is the ifdefs
we'll need to ensure the testing bits don't bloat cc1 and friends.
I can live with any of the 3 proposals (in testsuite directory,
alongside sources, inside existing sources) with the explicit assumption
that if we try one and it does't work out that we might experiment with
another. In my mind we're very early in this process, so course
corrections may be necessary.
Do we even support plugins on every host?
I would think not :-)
The tests you have so far are focused mostly on high-level gimple/tree
tests where this limitation is probably not showing up very much, but I
think it would be better to have something that allows us to have more
in-depth tests.
Yes. But I think this level of testing is on another point in the
testing continuum and will probably require some significant work beyond
the unit testing being proposed by David.
Not sure about significant - it shouldn't take long to set up an extra
test-gcc build at the top-level if we decide to go with that and add a
-ftest option. I think it's worth spending some time thinking long-term
about what the best way to go about this would be.
If we look at the cfg tests you'll see one that we take down to
generation of RTL. But the pain in setting that up is significant IMHO.
Enough that I doubt many folks are willing to go to those lengths to
write RTL (or even most gimple) tests.
The first high level question is how do we envision writing those tests.
I don't think the style shown in the gimple test is sustainable long
term. We've got to get past hand creating cfgs, cfun, basic rtl and
tree nodes, etc etc. Which argues that true gimple & rtl testing ought
to be sucking in gimple/rtl to start (ie, gimple & rtl front-ends). So
until those are in place, I just don't see going very far with testing
at a level much higher than David's doing right now.
The other way would be to look at the pain of setting up all the
required state and say it's a failing in the APIs of GCC itself and that
if we had the right APIs in place, constructing enough state to do this
kind of testing would be relatively easy.
David has mentioned working on the gimple front-end as his next
significant project. I suspect we'll learn a ton from that work and
wiring it into a test harness -- lessons I'd like to have under our belt
prior to tacking the RTL testing side. Similarly I suspect we'll learn
a lot about weaknesses in our API interfaces trying to write tests at a
level just above what David's targeting right now.
Jeff
