> MIME-Version: 1.0 > X-Axis-User: NO > X-Axis-NonUser: YES > X-Virus-Scanned: Debian amavisd-new at bastet.se.axis.com > X-Spam-Score: 1.102 > X-Spam-Level: * > X-Spam-Status: No, score=1.102 required=5 tests=[DKIM_ADSP_CUSTOM_MED=0.001, > DKIM_INVALID=0.1, DKIM_SIGNED=0.1, FREEMAIL_FROM=0.001, > NML_ADSP_CUSTOM_MED=0.9, RCVD_IN_DNSWL_NONE=-0.0001] > autolearn=no autolearn_force=no > Authentication-Results: bastet.se.axis.com (amavisd-new); > dkim=fail (2048-bit key) reason="fail (message has been altered)" > header.d=gmail.com > DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=gmail.com; s=20161025; > h=mime-version:references:in-reply-to:from:date:message-id:subject:to > :cc; > bh=AAYGM2axRy+4hoUcsyx/QB2xNqS0+rKeO265TdzbaYs=; > b=EvVgla8PF8FUMiRf82HqSQYHX78PzrU+GiXPiqw2uC24Fqu/gGFiLDj4IBbKaszKDi > s8GoNR6NbyflH1aoj2GunbYJNvUI4VibPEVbviVNYdyTCHV0q6TGGYaE5cZoo2UWtcK/ > 0d/ZKMOM4Qjje9+r0rSTMIJZWTJ0/sVd0NS1euJuPthYVNmvVpb7AB/PhJh54CDHQDSR > 9PEhf7dFxqV92mf8+GI0tOCQ+nm9Y71dVZCwh1k/Tu0Y1TTwhuq5IepHmVE77z/yNuHA > A12vhQcQfjhAP8V+W/BMJHiJAHUDjZPzEH49e01LiYsbVAKr+KOdr5cNTz5Bv4ItW79W > D9dQ== > X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; > d=1e100.net; s=20161025; > h=x-gm-message-state:mime-version:references:in-reply-to:from:date > :message-id:subject:to:cc; > bh=AAYGM2axRy+4hoUcsyx/QB2xNqS0+rKeO265TdzbaYs=; > b=orrCZrV+/CuKSTflfzU8FAJQ7oMcW5ZSEWJODWJy4CHX8ZdR0RzkcWS/SullfhG1cJ > KEt3DVxCK9szmKsUkBXIXxmGvJEqma1RmybFDitV0kcN2VDh60YPdp75AcLkCfgD6Fez > epoB4IbjbyQMf20/pYpiyFRUEDVBa/UVkKvB5bzD5NxdNxQfL3x5J6fOvRhaGmk+1QzO > AfVcQ+gvpKxHLwyuDJzs4OG8YnGxbmGAae3xh0PWWj2sBx7Tb+8h49Eh4VRmMOi9JprK > 5mgGos8VM3rpyo6W3adAqrCgPy1MC/yITWetaawNdNP+l4aGsNSxqZBdQwZAfczwEMGg > rJGA== > X-Gm-Message-State: APjAAAU+9Bb82pA2/UKZGhKnzsPN9t+7zZadQNJrSS7iIplrqHOmuzm8 > bPGmBk4MWcN13b4Pjd316YowZiEFUVjiy8t8CTTqCg== > X-Google-Smtp-Source: > APXvYqxOm2u4IqYKwhXP3MEEu2jy+NePCHnhKcBVCF7HIHkdksucHqDhQPlCymvdaoRcj41yORfaHxfBZo5iaRZ8cv4= > X-Received: by 2002:a19:2981:: with SMTP id > p123mr22301587lfp.190.1559807980081; > Thu, 06 Jun 2019 00:59:40 -0700 (PDT) > References: <201906051938.x55jcssw016...@ignucius.se.axis.com> > <18571728.MIQ1nkMWVm@polaris> > From: Richard Biener <richard.guent...@gmail.com> > Date: Thu, 6 Jun 2019 09:59:29 +0200 > Cc: Hans-Peter Nilsson <h...@axis.com>, > GCC Patches <gcc-patches@gcc.gnu.org> > Old-Content-Type: text/plain; charset="UTF-8" > X-TM-AS-GCONF: 00 > X-TM-AS-Product-Ver: IMSVA-9.1.0.1817-8.5.0.1020-24660.005 > X-TMASE-Version: IMSVA-9.1.0.1817-8.5.1020-24660.005 > X-TMASE-Result: 10--13.361300-10.000000 > X-TMASE-MatchedRID: OCgf9vSZjhKtHGjI+4ePLkKGB4JJ2ELXO4rmf5nWGLY2lSfrRmNlMlOi > > wGvrPOJI/ye/3Hc9K1qfhUT+CqHntkvOGeNuCS0Sx5sgyUhLCNtrLj3DxYBIN1eIuu+Gkot87vf > > jHqfMw2LuANzOai4fLwLhmAWwrROCua8xKml5Zs2ar6Iu0UJj0ndYbPDVqm8dNgrwTjLio7iKXt > > SrhR1F6LfTxRyZysPB3S9otnhJMWXMgfjGGlvykOXSonB/2H+nF9s8UTYYetXNWDA/tkxh/2BSh > > v8puDpLUAsHThNBbWPj2iOyGc7mHghiPDSyUlz9L9Kx8SxUYHtBmlBF/IJ0fFdZsJXctXRjVVrM > > hkGIRMOxNUU9LT2EMIwve9GnFZLPHDOmeQqRrUyeAiCmPx4NwFkMvWAuahr8JnwEOk8wQnYqtq5 > > d3cxkNd6Gc5JbLppQbfv6+tC0kEv7tmrl9YnUIaKw1O9DfwWCpRyUja5VPhXrpcchznD6Bw== > X-TMASE-SNAP-Result: 1.821001.0001-0-1-12:0,22:0,33:0,34:0-0 > X-RBL-Checked: 10.0.5.15 10.0.5.26 10.0.5.60 10.20.1.11 127.0.0.1 > 209.85.167.48 > Content-Transfer-Encoding: 8bit > Content-Type: TEXT/plain; charset=iso-8859-1 > > On Wed, Jun 5, 2019 at 10:03 PM Eric Botcazou <ebotca...@adacore.com> wrote: > > > > > This issue exists, not just for targets that can have their > > > MAX_FIXED_MODE_SIZE more-or-less easily tweaked higher, but also > > > for the 'bit-container' targets where it *can't* be set higher. > > > > > > Let's please DTRT and correct the code here in the middle-end, > > > so we don't ICE for those targets and this line (gcc.dg/pr69973.c): > > > typedef int v4si __attribute__ ((vector_size (1 << 29))); > > > (all listed targets happen to have Pmode == SImode) > > > > > > So, considering that: ok to commit? > > > > You'd need to audit the effects on other targets though. Are we sure that > > we > > want to do bitsizetype calculations in a larger mode on very embedded > > targets? > > I didn't actually write it down but originally wanted - what about adding > a way for the target to specify what type to use for bitsize_type? > We do have SIZETYPE so say that if BITSIZETYPE is defined then > use that (otherwise fall back to the existing mechanism)? There may > not be a C type that maps to DImode for cris
(Again: 64-bit types work fine for CRIS, it's just the cooked-up middle-end expressions that shouldn't use 64-bit-entities. Like, extracting bytes out of a 8-byte vector type. Not sure if that actually happens, but MAX_FIXED_MODE_SIZE is used in situations like that, where the data wasn't originally a 64-bit scalar.) > and it's not that > I like those C type names very much (probably a way to make the > macros independent of the chosen multilib?), so eventually a > BITSIZEMODE or BITSIZE_LARGER_THAN_MAX_FIXED_MODE_SIZE > macro? That said, if BITSIZETYPE would work I'd prefer that just > for consistency. I kind of *like* this suggestion (and agree about BITSIZETYPE) only because it'd be a more specific mechanism. I don't know if it's the right way though, maybe it's totally unnecessary; I guess I should do some grepping and stalking of bitsizetype now. brgds, H-P PS: To celebrate the day: "grep" (noun) is Swedish for pitchfork. ;) (as a verb, "seized")
