Snapshot gcc-10-20221013 is now available on
https://gcc.gnu.org/pub/gcc/snapshots/10-20221013/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 10 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch
On Thu, Oct 13, 2022 at 2:11 PM Vineet Gupta wrote:
> Hi Hans,
>
> On 10/13/22 13:54, Hans Boehm wrote:
>
> The generated code here is correct in both cases. In the RISC--V case, I
> believe it is conservative, at a minimum, in that atomics should not imply
> IO ordering. We had an earlier discus
On Thu, Oct 13, 2022 at 11:14 PM Vineet Gupta wrote:
>
>
>
> On 10/13/22 13:30, Uros Bizjak wrote:
>
> OTOH, for x86 (same default toggles) there's no barriers at all.
>
> _Z10bar_seqcstiPi:
> endbr64
> movlg(%rip), %eax
> movl%eax, (%rsi)
> movl
On 10/13/22 16:14, Arsen Arsenović wrote:
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
I was arguing that we don't need the new flag; there shouldn't be any
need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have ve
On 10/13/22 13:30, Uros Bizjak wrote:
OTOH, for x86 (same default toggles) there's no barriers at all.
_Z10bar_seqcstiPi:
endbr64
movlg(%rip), %eax
movl%eax, (%rsi)
movla(%rip), %eax
addl%edi, %eax
ret
Regardin
Hi Hans,
On 10/13/22 13:54, Hans Boehm wrote:
The generated code here is correct in both cases. In the RISC--V case,
I believe it is conservative, at a minimum, in that atomics should not
imply IO ordering. We had an earlier discussion, which seemed to have
consensus in favor of that opinion.
The generated code here is correct in both cases. In the RISC--V case, I
believe it is conservative, at a minimum, in that atomics should not imply
IO ordering. We had an earlier discussion, which seemed to have consensus
in favor of that opinion. I believe clang does not enforce IO ordering.
You
On Thu, Oct 13, 2022 at 9:31 PM Vineet Gupta wrote:
>
> Hi,
>
> I have a testcase (from real workloads) involving C++ atomics and trying
> to understand the codegen (gcc 12) for RVWMO and x86.
> It does mix atomics with non-atomics so not obvious what the behavior is
> intended to be hence some ex
On Thu, 13 Oct 2022 at 20:31, Vineet Gupta wrote:
>
> Hi,
>
> I have a testcase (from real workloads) involving C++ atomics and trying
> to understand the codegen (gcc 12) for RVWMO and x86.
> It does mix atomics with non-atomics so not obvious what the behavior is
> intended to be hence some expli
On Thursday, 13 October 2022 19:24:41 CEST Jason Merrill wrote:
> I was arguing that we don't need the new flag; there shouldn't be any
> need to turn it off.
At the time, I opted to go with a more conservative route; I haven't
been around enough to have very strong opinions ;) I certainly can't
Hi,
I have a testcase (from real workloads) involving C++ atomics and trying
to understand the codegen (gcc 12) for RVWMO and x86.
It does mix atomics with non-atomics so not obvious what the behavior is
intended to be hence some explicit CC of subject matter experts
(apologies for that in adv
Re: https://sourceware.org/pipermail/overseers/2022q4/018981.html
On Wed, Oct 12, 2022 at 12:43:09PM -0400, Carlos O'Donell wrote:
>The GNU Toolchain project leadership supports the proposal[1] to move the
>services for the GNU Toolchain to the Linux Foundation IT under the auspices of
>the Toolch
On Thursday, 13 October 2022 19:10:10 CEST Jakub Jelinek wrote:
> Don't we have such a test already elsewhere? If not, then certain
> "warn for main" part should be removed or replaced...
Whoops, missed that comment. There is actually an equivalent test that
I overlooked (noreturn-1.c), so mayb
On 10/13/22 13:02, Arsen Arsenović wrote:
Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
* gcc.dg/noreturn-4.c: Likewise.
I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing sp
On Thu, Oct 13, 2022 at 07:03:24PM +0200, Arsen Arsenović wrote:
> @@ -1,10 +1,10 @@
> /* Check for "noreturn" warning in main. */
> /* { dg-do compile } */
> -/* { dg-options "-O2 -Wmissing-noreturn -ffreestanding" } */
> +/* { dg-options "-O2 -Wmissing-noreturn" } */
> extern void exit (int) _
On Mon, 2022-10-10 at 16:21 -0400, Jason Merrill wrote:
> On 10/4/22 11:11, Ben Boeckel wrote:
> > This patch adds initial support for ISO C++'s [P1689R5][], a format
> > for
> > describing C++ module requirements and provisions based on the
> > source
> > code. This is required because compiling C
Hi,
On Friday, 7 October 2022 15:51:31 CEST Jason Merrill wrote:
> > * gcc.dg/noreturn-4.c: Likewise.
>
> I'd be inclined to drop this test.
That seems like an odd choice, why do that over using another function
for the test case? (there's nothing specific to main in this test, and
it doesn
17 matches
Mail list logo
