From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62b.google.com (mail-ej1-x62b.google.com [IPv6:2a00:1450:4864:20::62b]) by sourceware.org (Postfix) with ESMTPS id E90793858001 for ; Thu, 2 Sep 2021 14:06:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E90793858001 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embecosm.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embecosm.com Received: by mail-ej1-x62b.google.com with SMTP id n27so4677453eja.5 for ; Thu, 02 Sep 2021 07:06:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=embecosm.com; s=google; h=mime-version:from:date:message-id:subject:to:cc; bh=O9IXfBGXlGKlzfmuYZA59z7COPXGdRvEM6+80nEUGlA=; b=bJE2BZtppFuO1tFJ1bLAT2Ixpwmn2YI8RYVQc+6eINy9VPonUNZlnmyBVO8jeagwbK mFw9BL/spUsja1hXa704/d8tKHw6O93F8eQGYyTUznKW/ODpbW5awSRdJT45E9oWGi3u QrxNE3pv9hN9+ZkOCy9EuZ98T6O9DgyHXB2jau/1/Oi/p6KBa1tIgv/kg4Yrc+d+7B+z GGLB1AlXPUlIIb3yh1JRrdQusvuGapetJqCp8rRCPSHV13vb6hsaJraJrciFFeBSiskb oVCq7EC+X6NNa8MDueO2rLDaU4hkhkaV5kbmYOXeAYa3fgOqHSYqqAHeRS46bZDdvBi4 MI5A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to:cc; bh=O9IXfBGXlGKlzfmuYZA59z7COPXGdRvEM6+80nEUGlA=; b=Jd82fzV6kKJ0URxRYIxOzX8NO+0bCTEx4YOeBSeqLgAoUumUNm6Y0vazeExnbim8tr IRlp5fGKIvE34JIxLcx7s9dPZMc9I1jC2mntytfVaiR2iBjEOIwYg1RaYF54GYnXNbvF 4kJpHwmGWHRKIre7gviC9IRNwoEyFMSVf9SZasY6uSzd3iEDSg6YUXr595TQj5+Xk9EJ 1TZNeL6OopTztdWuhSQEA4TvUZlHorBaUqGe6fn0AYmCcAWurFZNCDyPlhp6xwmWRM/+ shdmvOBb63o6suGzFqxtYJSVKkcZyxMUGXIIp+sIuBNNtkRLfNQ99xRsAGo4HKxixIoK vgqA== X-Gm-Message-State: AOAM533jqTiql1iTcS+xSGt2fAjPiaLZxkYRpNyiCf26F22cI0/BWXWf DBleZwL2MgxjmXqAaC3D9Q60Q+WbGGCw07kOfzaXkEhGwXM35lud X-Google-Smtp-Source: ABdhPJzGCYjbeiU+/wKY0Z53Gdto7ptJom023foRD8/nLc2/903QTiC+4qybev2jGHRznvSKNV7Wj2VRE6rM0+5AgKE= X-Received: by 2002:a17:906:abd7:: with SMTP id kq23mr4012026ejb.542.1630591604474; Thu, 02 Sep 2021 07:06:44 -0700 (PDT) MIME-Version: 1.0 From: Philip Herron Date: Thu, 2 Sep 2021 15:06:33 +0100 Message-ID: Subject: Rust Compatibility To: gcc-rust@gcc.gnu.org Cc: David Edelsohn , Brad Spengler , Ian Lance Taylor Content-Type: multipart/alternative; boundary="0000000000005bd7e805cb03b1b9" X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-rust@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: gcc-rust mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 02 Sep 2021 14:06:56 -0000 --0000000000005bd7e805cb03b1b9 Content-Type: text/plain; charset="UTF-8" Hi everyone, Yesterday this issue was posted to us on GitHub https://github.com/Rust-GCC/gccrs/issues/653, which revolves around strict-aliasing rules. The conversation was focused on what level of compatibility we are aiming for in the Rust language. This is important, and I don't believe we should allow specific language features/development outside the official Rust processes. This means we do not want to have any GCC specific attributes or language features and we won't provide a shortcut to bypass RFC processes. Though I believe we should always allow users to invoke GCC Rust however they wish (since the FE inherits the common GCC options), this is the point of free software to me. To mitigate any GCC vs Rustc incompatibility, our cargo-gccrs wrapper was always intended to map rust arguments over to the GCC version of these to get the intended Rustc behaviour. But still, when users want to invoke gccrs directly, it is up to them to choose what options they want, good or bad, including using gcc-plugins. Some of the feedback seems that if we allow users to compile code with or without strict aliasing, this may allow for code to compile with GCC but not with rustc which "splits the ecosystem". So I wanted to run this by you guys here to get feedback on what people think about allowing users to choose their GCC compilation options in general. Thanks --Phil --0000000000005bd7e805cb03b1b9 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi everyone,

Yesterday this issue was posted to us = on GitHub https://= github.com/Rust-GCC/gccrs/issues/653, which revolves around strict-alia= sing rules.

The conversation was focused on what level of compatibi= lity we are aiming for in the Rust language. This is important, and I don&#= 39;t believe we should allow specific language features/development outside= the official Rust processes. This means we do not want to have any GCC spe= cific attributes or language features and we won't provide a shortcut t= o bypass RFC processes.

Though I believe we should always allow use= rs to invoke GCC Rust however they wish (since the FE inherits the common G= CC options), this is the point of free software to me. To mitigate any GCC = vs Rustc incompatibility, our cargo-gccrs wrapper was always intended to ma= p rust arguments over to the GCC version of these to get the intended Rustc= behaviour. But still, when users want to invoke gccrs directly, it is up t= o them to choose what options they want, good or bad, including using gcc-p= lugins.

Some of the feedback seems that if we allow users to compile= code with or without strict aliasing, this may allow for code to compile w= ith GCC but not with rustc which "splits the ecosystem". So I wan= ted to run this by you guys here to get feedback on what people think about= allowing users to choose their GCC compilation options in general.

= Thanks

--Phil
--0000000000005bd7e805cb03b1b9--