From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112159 invoked by alias); 11 Apr 2018 10:45:52 -0000 Mailing-List: contact libffi-discuss-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libffi-discuss-owner@sourceware.org Received: (qmail 105287 invoked by uid 89); 11 Apr 2018 10:45:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: =?ISO-8859-1?Q?No, score=-1.4 required=5.0 tests=BAYES_00,HTML_MESSAGE,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,TIME_LIMIT_EXCEEDED autolearn=unavailable version=3.3.2 spammy=Green, H*Ad:U*libffi-discuss, promised, the=c2?= X-HELO: mail-lf0-f68.google.com Received: from mail-lf0-f68.google.com (HELO mail-lf0-f68.google.com) (209.85.215.68) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 11 Apr 2018 10:45:04 +0000 Received: by mail-lf0-f68.google.com with SMTP id b189-v6so1947468lfe.2 for ; Wed, 11 Apr 2018 03:45:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=x3BPSJmoYMRXIClyNUJ0SE7dONhnd2xfKQrlclNx4GE=; b=NBDvzdk153Q7ipUF/mN+9kdIFRsHDvKifqGe9AItsstmIwCROTr381E+6eWoW5IGO5 P8TxzpIpTrtXjr+frQ45K7mc7JZcDj4YIlr+JoPGOFV3cLIDmRMSIfxZhn/X9gCbNl3y 8+s/E1vaTAYelnpp51U2d8wCCpoqH96BFIAK0i+ZRtcN6FzKMR5E20be7VeXy4THhUs7 Gk5LPdguLvlO5I1yEvQdUR4u0pYHMhp8nQF4FPiCsOZ+kvcAAiKW7pp+Myf5ZdsEUfA9 WsBCjSoitaiOFn36JeeVdumUz3YAU8XDHS4fGSFvykhJsvYqiL11IVB+dvOEjuNP1acR ypeA== X-Gm-Message-State: ALQs6tB9/Ug2crcH7+4p76RR2G9aEN295qeCsu2//ZTSZP53J3F3pRYX gyOZXGHygMBVEdNVxvhZywUYiP764MzksiECFXcibA== X-Google-Smtp-Source: AIpwx49pETQJEnKzix1zn43/+e1g3o/XmcaKmS/aKJJWqI4/KZey61RqJ/UdgC5eylmxOpkiUG66VuHBliIqq8eKFCM= X-Received: by 10.46.65.210 with SMTP id d79mr2619359ljf.80.1523443502322; Wed, 11 Apr 2018 03:45:02 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a19:ce8d:0:0:0:0:0 with HTTP; Wed, 11 Apr 2018 03:45:01 -0700 (PDT) In-Reply-To: References: From: Anthony Green Date: Wed, 11 Apr 2018 10:45:00 -0000 Message-ID: Subject: Re: Travis build issue on PR #414 To: Teodor Dermendzhiev Cc: "libffi-discuss@sourceware.org" Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018/txt/msg00020.txt.bz2 Teodor, thank you for your contribution. I feel like we should discuss this change in the list rather than in the PR in order to get wider visibility, as this is an important change, and I'm hoping to elicit feedback from others. This patch adds support for clang's version of vectors, which are defined using the ext_vector attribute (which is a clang-ism). My understanding is that clang and GCC both have the concept of vectors that are roughly the same, as they are used for simd computations. My first thought was... why not just call it FFI_VECTOR instead of the clang specific FFI_EXT_VECTOR? It turns out that there's at least one important difference between the two compilers, and that it how vectors are aligned: https://github.com/android-ndk/ndk/issues/640 The implementation of this features has us introducing what is essentially a special case of FFI_STRUCT, which is handled differently when it comes to argument passing. Other than that, it is treated as an FFI_STRUCT -- which also means that you are required to set all of the element types. This seems suboptimal if we know that we're dealing with a vector of one type. libffi currently promises to set the size and alignment of your type (specifically, aggregate types) for you, as they vary by ABI. However, the current implementation allows you to set the size and alignment yourself, which would appear to be a requirement given the different alignment assumptions between GCC and clang. This is what your test cases do, although they don't distinguish between GCC and clang alignment assumptions. Is this correct? So, some important questions... 1. Should we have FFI_GCC_VECTOR and FFI_CLANG_VECTOR (or FFI_EXT_VECTOR), and have libffi fill in the size/alignment details as promised? 2. Should we just have FFI_VECTOR and force users to fill in the details themselves because none of this is standardized? 3. Should we have something altogether different, and -- for instance -- only require the definition of one element type for vectors? Also, at the very least, we need changes to libffi.texi to document whatever is finally merged in. Did I get this right? Any comments or suggestions from anyone? Thanks, AG On Tue, Apr 10, 2018 at 11:09 AM, Anthony Green wrote: > Thanks Teodor. I'll review your patch today. The travis errors are due > to the 32-bit x86 multi-ABI problems, and unrelated. > > AG > > > On Tue, Apr 10, 2018 at 10:42 AM, Teodor Dermendzhiev < > Teodor.Dermendzhiev@progress.com> wrote: > >> Hello, >> >> Couple of weeks ago I submitted a PR targetting arm64 support for SIMD >> types. After I fixed the errors from the Travis builds now it looks like >> there is a problem there and I am not sure it is related to my changes. >> Here (https://travis-ci.org/libffi/libffi/builds/364614226) you can see >> all the builds but one are successful. According to the error log its >> related to the log's size. It would be great to have some feedback on >> this. Thank you. >> >> Greetings, >> Teodor Dermendzhiev >> NativeScript >> > >