Hi Michael,
I'm on gcc 13.1 compiling for Windows x64, with the MinGW UCRT64 runtime
library
best regards,
Julian
On Thu, Jun 29, 2023 at 9:27 PM Michael Matz wrote:
> Hello,
>
> On Thu, 29 Jun 2023, Julian Waters via Gcc wrote:
>
> > int main() {
> > asm ("nop" "\n"
> > "\t"
Hello,
On Thu, 29 Jun 2023, Julian Waters via Gcc wrote:
> int main() {
> asm ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
>
> asm volatile ("nop" "\n"
> "\t" "nop" "\n"
> "\t" "nop");
> }
>
> objdump --disassemble-all -M intel -M
Hi Andrew,
Here is a simpler testcase, with the resulting assembly attached below
int main() {
asm ("nop" "\n"
"\t" "nop" "\n"
"\t" "nop");
asm volatile ("nop" "\n"
"\t" "nop" "\n"
"\t" "nop");
}
objdump --disassemble-all -M intel
On Wed, Jun 28, 2023 at 8:04 AM Michael Matz wrote:
>
> Hello,
>
> On Wed, 28 Jun 2023, Julian Waters via Gcc wrote:
>
> > On the contrary, code compiled with gcc with or without the applied patch
> > operates very differently, with only gcc with the applied patch producing a
> > fully correctly
Hello,
On Wed, 28 Jun 2023, Julian Waters via Gcc wrote:
> On the contrary, code compiled with gcc with or without the applied patch
> operates very differently, with only gcc with the applied patch producing a
> fully correctly operating program as expected. Even if the above inline
> assembly
Hi all,
I've revised the change to be much neater
>From 480954bc7d2b24e5d19a98260a2be0b49e112c42 Mon Sep 17 00:00:00 2001
From: TheShermanTanker
Date: Wed, 28 Jun 2023 19:11:34 +0800
Subject: [PATCH] asm not using extended syntax should always be volatile
---
gcc/cp/parser.cc | 2 +-
1 file
Hi Andrew,
On the contrary, code compiled with gcc with or without the applied patch
operates very differently, with only gcc with the applied patch producing a
fully correctly operating program as expected. Even if the above inline
assembly blocks never worked due to other optimizations however,
On Wed, Jun 28, 2023 at 12:32 AM Julian Waters wrote:
>
> Hi Andrew,
>
> On a Microsoft Windows target the following (placed inside a function of
> course) will only work correctly if volatile is specified in the basic asm
> block (or if the attached patch was applied to gcc):
These inline-asm
Hi Andrew,
On a Microsoft Windows target the following (placed inside a function of
course) will only work correctly if volatile is specified in the basic asm
block (or if the attached patch was applied to gcc):
asm ("1:" "\n"
"\t" ".seh_handler __C_specific_handler, @except" "\n"
On Tue, Jun 27, 2023 at 9:16 AM Julian Waters wrote:
>
> Perhaps this only affects compilation when GIMPLE isn't being used?
The only time GIMPLE is not used is if you supply -fsyntax-only so ...
Thanks,
Andrew
>
> On Wed, Jun 28, 2023 at 12:15 AM Julian Waters
> wrote:
>>
>> Hi Andrew,
>>
On Tue, Jun 27, 2023 at 9:15 AM Julian Waters wrote:
>
> Hi Andrew,
>
> That can't be right, on my system a test of asm vs asm volatile with -O3 and
> -flto=auto yields very different results, with only the latter being correct.
> The patch fixed it and caused gcc to emit correct assembly
Can
Perhaps this only affects compilation when GIMPLE isn't being used?
On Wed, Jun 28, 2023 at 12:15 AM Julian Waters
wrote:
> Hi Andrew,
>
> That can't be right, on my system a test of asm vs asm volatile with -O3
> and -flto=auto yields very different results, with only the latter being
>
Hi Andrew,
That can't be right, on my system a test of asm vs asm volatile with -O3
and -flto=auto yields very different results, with only the latter being
correct. The patch fixed it and caused gcc to emit correct assembly
best regards,
Julian
On Wed, Jun 28, 2023 at 12:08 AM Andrew Pinski
On Tue, Jun 27, 2023 at 9:03 AM Julian Waters via Gcc wrote:
>
> gcc's documentatation mentions that all basic asm blocks are always volatile,
> yet the parser fails to account for this by only ever setting
> volatile_p to true
> if the volatile qualifier is found. This patch fixes this by adding
My apologies, I sent this to the wrong list. I have already resent
it to the correct one
regards,
Julian
gcc's documentatation mentions that all basic asm blocks are always volatile,
yet the parser fails to account for this by only ever setting
volatile_p to true
if the volatile qualifier is found. This patch fixes this by adding a
special case check for extended_p before finish_asm_stmt is called
gcc's documentatation mentions that all basic asm blocks are always volatile,
yet the parser fails to account for this by only ever setting
volatile_p to true
if the volatile qualifier is found. This patch fixes this by adding a
special case check for extended_p before finish_asm_statement is
17 matches
Mail list logo
