On Tue, Feb 05, 2019 at 01:47:57PM +0100, Martin Liška wrote:
>
> gcc/fortran/ChangeLog:
>
> 2019-01-24 Martin Liska
>
> * decl.c (gfc_match_gcc_builtin): Add support for filtering
> of builtin directive based on multilib ABI name.
>
> gcc/testsuite/ChangeLog:
>
> 2019-01-24 Ma
On 2/14/19 10:13 PM, Steve Ellcey wrote:
> On Wed, 2019-02-13 at 12:34 +0100, Martin Liška wrote:
>> May I please ping this so that we can reach mainline soon?
>>
>> Thanks,
>> Martin
>
> Martin, I can't approve this patch but I can say that I have used it on
> Aarch64 and created a follow up patc
On Wed, 2019-02-13 at 12:34 +0100, Martin Liška wrote:
> May I please ping this so that we can reach mainline soon?
>
> Thanks,
> Martin
Martin, I can't approve this patch but I can say that I have used it on
Aarch64 and created a follow up patch for aarch64 to create a
get_multilib_abi_name targ
On Tue, 5 Feb 2019, Martin Liška wrote:
> #ifdef NATIVE_SYSTEM_HEADER_DIR
>/* Then search: /usr/include/finclude/ */
>add_sysrooted_hdrs_prefix (&prefixes, NATIVE_SYSTEM_HEADER_DIR
> "/finclude/",
> - NULL, 0, 0, false);
> + NULL, 0, 0, 0
May I please ping this so that we can reach mainline soon?
Thanks,
Martin
On 2/5/19 1:48 PM, Martin Liška wrote:
> On 2/5/19 2:31 AM, Joseph Myers wrote:
>> My main comment here is that if you go with the approach of a single
>> header shared by multilibs, you should also update the driver code
On 2/5/19 2:31 AM, Joseph Myers wrote:
> My main comment here is that if you go with the approach of a single
> header shared by multilibs, you should also update the driver code so it
> no longer uses any sort of multilib suffix when searching for this header
> (it *should* still use the sysroo
On 2/4/19 11:10 AM, Jakub Jelinek wrote:
> On Thu, Jan 24, 2019 at 04:25:13PM +0100, Martin Liška wrote:
>> @@ -11361,6 +11365,13 @@ gfc_match_gcc_builtin (void)
>>else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
>> clause = SIMD_INBRANCH;
>>
>> + if (gfc_match (" if ( '%n' ) ", targ
On Mon, 4 Feb 2019, Jakub Jelinek wrote:
> > +!GCC$ builtin (sin) attributes simd (notinbranch) if('x86_64')
> > +!GCC$ builtin (sinf) attributes simd (notinbranch) if('i386')
>
> That is all from me, but I think you need a buy-in from the Fortran
> maintainers (if they are ok with such an extens
On Thu, Jan 24, 2019 at 04:25:13PM +0100, Martin Liška wrote:
> @@ -11361,6 +11365,13 @@ gfc_match_gcc_builtin (void)
>else if (gfc_match (" ( inbranch ) ") == MATCH_YES)
> clause = SIMD_INBRANCH;
>
> + if (gfc_match (" if ( '%n' ) ", target) == MATCH_YES)
Not sure if it is clean enoug
PING^1
On 1/24/19 4:25 PM, Martin Liška wrote:
> On 1/24/19 4:05 PM, Jakub Jelinek wrote:
>> On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin Liška wrote:
>>> --- a/gcc/config/i386/i386.c
>>> +++ b/gcc/config/i386/i386.c
>>> @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args
On 1/24/19 10:24 PM, Steve Ellcey wrote:
> On Thu, 2019-01-24 at 16:25 +0100, Martin Liška wrote:
>>
>>>
+ix86_get_multilib_abi_name (void)
+{
+ if (!(TARGET_64BIT_P (ix86_isa_flags)))
+return "i386";
+ else if (TARGET_X32_P (ix86_isa_flags))
+return "x32";
>
On Thu, 2019-01-24 at 16:25 +0100, Martin Liška wrote:
>
> >
> > > +ix86_get_multilib_abi_name (void)
> > > +{
> > > + if (!(TARGET_64BIT_P (ix86_isa_flags)))
> > > +return "i386";
> > > + else if (TARGET_X32_P (ix86_isa_flags))
> > > +return "x32";
> > > + else
> > > +return "x86_
On 1/24/19 4:05 PM, Jakub Jelinek wrote:
> On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin Liška wrote:
>> --- a/gcc/config/i386/i386.c
>> +++ b/gcc/config/i386/i386.c
>> @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t
>> cum_v, tree type)
>>cum->warn_empty = false
On Thu, Jan 24, 2019 at 03:57:56PM +0100, Martin Liška wrote:
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -29577,6 +29577,17 @@ ix86_warn_parameter_passing_abi (cumulative_args_t
> cum_v, tree type)
>cum->warn_empty = false;
> }
>
> +static const char *
Missing funct
On 1/23/19 2:07 AM, Joseph Myers wrote:
> On Tue, 22 Jan 2019, Richard Biener wrote:
>
>>> Or instead just come up with target specific strings to determine the ABI,
>>> say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000
>>> etc.
>>
>> Yeah, I would even suggest to use a t
On Wed, 2019-01-23 at 23:53 +0100, Jakub Jelinek wrote:
> External Email
>
> ---
> ---
> On Wed, Jan 23, 2019 at 09:56:21PM +, Steve Ellcey wrote:
> > I wonder if we even need to pass a string to the target
> > hook. Instead
> >
On Wed, Jan 23, 2019 at 09:56:21PM +, Steve Ellcey wrote:
> I wonder if we even need to pass a string to the target hook. Instead
> of:
>
> !GCC$ builtin (cos) attributes simd (notinbranch) if('x86_64-linux-gnu')
>
> We just have:
>
> !GCC$ builtin (cos) attributes simd (notinbranch) if_all
On Tue, 2019-01-22 at 13:18 +0100, Richard Biener wrote:
>
> Yeah, I would even suggest to use a target hook multilib_ABI_active_p
> (const char *)
> for this ... (where the hook should diagnose unknown multilib specifiers).
>
> Richard.
I wonder if we even need to pass a string to the target h
On Tue, 22 Jan 2019, Richard Biener wrote:
> > Or instead just come up with target specific strings to determine the ABI,
> > say i386, x86_64 and x32 for the 3 ABIs on x86, powerpc{,64}{,le} on rs6000
> > etc.
>
> Yeah, I would even suggest to use a target hook multilib_ABI_active_p
> (const cha
On Tue, Jan 22, 2019 at 12:15 PM Jakub Jelinek wrote:
>
> On Tue, Jan 22, 2019 at 12:01:29PM +0100, Martin Liška wrote:
> > I discussed with Jakub possibility of generating canonical triples that will
> > be then used in Fortran FE to filter the 'GCC$ builtin' directives. However,
> > the approach
On Tue, Jan 22, 2019 at 12:01:29PM +0100, Martin Liška wrote:
> I discussed with Jakub possibility of generating canonical triples that will
> be then used in Fortran FE to filter the 'GCC$ builtin' directives. However,
> the approach bring some possibilities and thus I enhanced the previous
> vers
On 1/21/19 3:25 PM, Joseph Myers wrote:
> On Mon, 21 Jan 2019, Martin Liška wrote:
>
>> I like the if('lp64'), if('ilp32') approach and I'm sending patch
>> candidate for that. Would it be accepted by glibc folks?
>
> Since glibc supports libmvec for x86_64, both 64-bit and x32, but not for
> 3
On Mon, 21 Jan 2019, Martin Liška wrote:
> I like the if('lp64'), if('ilp32') approach and I'm sending patch
> candidate for that. Would it be accepted by glibc folks?
Since glibc supports libmvec for x86_64, both 64-bit and x32, but not for
32-bit x86, those particular conditionals are insuffi
On Mon, Jan 21, 2019 at 10:36:20AM +0100, Martin Liška wrote:
> @@ -11338,7 +11339,7 @@ gfc_match_gcc_unroll (void)
>return MATCH_ERROR;
> }
>
> -/* Match a !GCC$ builtin (b) attributes simd flags form:
> +/* Match a !GCC$ builtin (b) attributes simd if(target) flags form:
>
> The para
On 1/21/19 10:19 AM, Jakub Jelinek wrote:
> On Mon, Jan 21, 2019 at 10:09:01AM +0100, Martin Liška wrote:
>> @@ -11351,6 +11352,7 @@ match
>> gfc_match_gcc_builtin (void)
>> {
>>char builtin[GFC_MAX_SYMBOL_LEN + 1];
>> + char target[GFC_MAX_SYMBOL_LEN + 1];
>>
>>if (gfc_match (" ( %n )
On Mon, Jan 21, 2019 at 10:09:01AM +0100, Martin Liška wrote:
> @@ -11351,6 +11352,7 @@ match
> gfc_match_gcc_builtin (void)
> {
>char builtin[GFC_MAX_SYMBOL_LEN + 1];
> + char target[GFC_MAX_SYMBOL_LEN + 1];
>
>if (gfc_match (" ( %n ) attributes simd", builtin) != MATCH_YES)
> re
On 1/21/19 8:58 AM, Jakub Jelinek wrote:
> On Mon, Jan 21, 2019 at 08:47:42AM +0100, Martin Liška wrote:
>> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
>> index 3314e176881..5c7c062574b 100644
>> --- a/gcc/fortran/decl.c
>> +++ b/gcc/fortran/decl.c
>> @@ -11351,6 +11351,7 @@ match
>> gfc_
On Mon, Jan 21, 2019 at 08:47:42AM +0100, Martin Liška wrote:
> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
> index 3314e176881..5c7c062574b 100644
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -11351,6 +11351,7 @@ match
> gfc_match_gcc_builtin (void)
> {
>char builtin[G
On 1/18/19 9:39 AM, Jakub Jelinek wrote:
> On Fri, Jan 18, 2019 at 09:18:33AM +0100, Martin Liška wrote:
>> What about something as simple as this:
>>
>> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
>> index 3314e176881..2f2b965f97d 100644
>> --- a/gcc/fortran/decl.c
>> +++ b/gcc/fortran/de
On Fri, Jan 18, 2019 at 09:18:33AM +0100, Martin Liška wrote:
> What about something as simple as this:
>
> diff --git a/gcc/fortran/decl.c b/gcc/fortran/decl.c
> index 3314e176881..2f2b965f97d 100644
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -11361,6 +11361,11 @@ gfc_match_gcc_bu
On 1/16/19 9:35 PM, Joseph Myers wrote:
> On Wed, 16 Jan 2019, Jakub Jelinek wrote:
>
>> Perhaps easier would be to add optional if clause to the !GCC$ builtin
>> with constant expression argument which if present and evaluates to .false.
>> would tell us to ignore the attribute. Or, add !GCC$ if
On Wed, 16 Jan 2019, Jakub Jelinek wrote:
> Perhaps easier would be to add optional if clause to the !GCC$ builtin
> with constant expression argument which if present and evaluates to .false.
> would tell us to ignore the attribute. Or, add !GCC$ if/else/end if which
> would act like preprocessi
On Wed, Jan 16, 2019 at 05:42:06PM +, Joseph Myers wrote:
> On Wed, 16 Jan 2019, Joseph Myers wrote:
>
> > On Wed, 16 Jan 2019, Jakub Jelinek wrote:
> >
> > > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4
> > > or
> > > defined(__ILP64__) and similar, but in these
On Wed, 16 Jan 2019, Joseph Myers wrote:
> On Wed, 16 Jan 2019, Jakub Jelinek wrote:
>
> > In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or
> > defined(__ILP64__) and similar, but in these headers we can't, as no
> > preprocessing is happening.
>
> (With such preproces
On Wed, 16 Jan 2019, Jakub Jelinek wrote:
> In normal C headers, we can #if __WORDSIZE == 32 or __SIZEOF_LONG__ == 4 or
> defined(__ILP64__) and similar, but in these headers we can't, as no
> preprocessing is happening.
(With such preprocessing, the mechanism glibc uses for gnu/stubs.h and
gnu/
On Wed, 16 Jan 2019, Martin Liška wrote:
> Now we should add the header file into glibc, I kicked a discussion here:
> https://sourceware.org/ml/libc-help/2018-11/msg00015.html
libc-help is for user questions. It's not suitable for glibc development
discussions.
--
Joseph S. Myers
jos...@code
On Wed, Jan 16, 2019 at 10:42:13AM +0100, Martin Liška wrote:
> On 1/15/19 6:45 PM, Joseph Myers wrote:
> > On Mon, 14 Jan 2019, Martin Liška wrote:
> >
> >> Thanks for review, fixed that in updated version of the patch.
> >>
> >> Patch can bootstrap on x86_64-linux-gnu and survives regression tes
37 matches
Mail list logo
