This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]
- From: Jeff Law <law at redhat dot com>
- To: Tamar Christina <Tamar dot Christina at arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, nd <nd at arm dot com>, "joseph at codesourcery dot com" <joseph at codesourcery dot com>, "bonzini at gnu dot org" <bonzini at gnu dot org>, "dj at redhat dot com" <dj at redhat dot com>, "neroden at gcc dot gnu dot org" <neroden at gcc dot gnu dot org>, "aoliva at redhat dot com" <aoliva at redhat dot com>, "Ralf dot Wildenhues at gmx dot de" <Ralf dot Wildenhues at gmx dot de>
- Date: Thu, 19 Jul 2018 11:31:52 -0600
- Subject: Re: [PATCH][GCC][front-end][build-machinery][opt-framework] Allow setting of stack-clash via configure options. [Patch (4/6)]
- References: <20180711112233.GA15865@arm.com> <5640622e-c73e-5148-69c6-b7328f5c8ff0@redhat.com> <20180712174503.GB24275@arm.com> <HE1SPR8PMB313619F632C7C70234D9740FF520@HE1SPR8PMB313.eurprd08.prod.outlook.com>
On 07/19/2018 06:55 AM, Tamar Christina wrote:
>>>
>>> What's the purpose of including auto-host in params-list and
>>> params-options? It seems like you're putting a property of the target
>>> (guard size) into the wrong place (auto-host.h).
>>>
>>
>> The reason for this is because there's a test gcc.dg/params/blocksort-part.c
>> that uses these params-options to generate test cases to perform parameter
>> validation. However because now the params.def file can contain a CPP
>> macro these would then fail.
>>
>> CPP is already called to create params-options and params-list so the easiest
>> way to fix this test was just to include auto-host which would get it the values
>> from configure.
>>
>> This test is probably not needed anymore after my second patch series as
>> parameters are validated by the front-end now, so they can never go out of
>> range.
Right, but I don't immediately see a way to avoid the test. ie, it just
walks down everything in params.options and except for a couple
exceptional values the test gets run.
I wonder if all this is an indication that having CPP constants in the
options isn't going to work well as we're mixing the distinction between
host/target.
>>
>>> It's also a bit unclear to me why this is necessary at all. Are we
>>> planning to support both the 4k and 64k guards? My goal (once the
>>> guard was configurable) was never for supporting multiple sizes on a
>>> target but instead to allow experimentation to find the right default.
>>>
>
> Having talked to people I believe we do need to support both 4k and 64k guards.
> For the Linux/Glibc world it wouldn't matter much, either 4 or 64k would do, though Glibc has settled on 64k pages.
>
> However other systems like (open/free)BSD or musl based systems do not want
> 64k pages but want 4k ones. So we're ending up having to support both as a compromise.
Understood. Thanks for verifying. I wonder if we could just bury this
entirely in the aarch64 config files and not expose the default into
params.def?
jeff