Christophe Lyon <christophe.l...@linaro.org> writes: > On Wed, 8 Apr 2020 at 11:48, Richard Sandiford > <richard.sandif...@arm.com> wrote: >> >> Christophe Lyon via Gcc-patches <gcc-patches@gcc.gnu.org> writes: >> > Hi, >> > >> > While checking Martin's fix for PR ipa/94445, he made me realize that >> > the cmse-15.c testcase still fails at -Os because ICF means that we >> > generate >> > nonsecure2: >> > b nonsecure0 >> > >> > which is OK, but does not match the currently expected >> > nonsecure2: >> > ... >> > bl __gnu_cmse_nonsecure_call >> > >> > (see https://gcc.gnu.org/pipermail/gcc-patches/2020-April/543190.html) >> > >> > The test has already different expectations for v8-M and v8.1-M. >> > >> > I've decided to try to use check-function-bodies to account for the >> > different possibilities: >> > - v8-M vs v8.1-M via two different prefixes >> > - code generation variants (-0?) via multiple regexps >> > >> > I've tested that the test now passes with >> > --target-board=-march=armv8-m.main >> > and --target-board=-march=armv8.1-m.main. >> > >> > I feel this a bit too much of a burden for the purpose, maybe there's >> > a better way of handling all these alternatives (in particular, >> > there's a lot of duplication since the expected code for the secure* >> > functions is the same for v8-M and v8.1-M). >> >> FWIW, an alternative is to give multiple versions with the same prefix >> and use { target ... } to select between them. E.g.: >> >> /* >> ** foo: { target a } >> ** ... >> */ >> /* >> ** foo: { target { ! a } } >> ** ... >> */ >> > > Ha indeed, that makes it simpler. Thanks for the example, I hadn't > fully understand how to use that scheme: I tried to add a third > alternative (different prefix) with no selector for cases where no > distinction was needed, but I realized that all alternatives need > their full matching description. > > However, {target { ! a } } does not work as is, so the attached patch > uses a non-greedy regexp to avoid trying "! a }" instead of "target { > ! a }"
Oops. This part is definitely OK, thanks. > If OK, maybe I should commit that as two separate patches? I don't really feel qualified to review the substance of the arm part of the patch, but given Andre's LGTM for that in the earlier version, a rubber-stamp OK for that too. I agree separate commits might be better. Thanks, Richard
