How to debug .md file?

[DeepaBallari via gcc]

Hello,I'm a newbie to GCC.Have done some changes to .md file(specifically 
peephole.md) and the changes are not taking place.How to debug the .md file ?
Thanks!

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Laszlo Ersek]

On 06/05/18 08:04, Ard Biesheuvel wrote:
> On 4 June 2018 at 20:10, Laszlo Ersek  wrote:
>> Hi!
>>
>> Apologies if this isn't the right place for asking. For the problem
>> statement, I'll simply steal Ard's writeup [1]:
>>
>>> KVM on ARM refuses to decode load/store instructions used to perform
>>> I/O to emulated devices, and instead relies on the exception syndrome
>>> information to describe the operand register, access size, etc. This
>>> is only possible for instructions that have a single input/output
>>> register (as opposed to ones that increment the offset register, or
>>> load/store pair instructions, etc). Otherwise, QEMU crashes with the
>>> following error
>>>
>>>   error: kvm run failed Function not implemented
>>>   [...]
>>>   QEMU: Terminated
>>>
>>> and KVM produces a warning such as the following in the kernel log
>>>
>>>   kvm [17646]: load/store instruction decoding not implemented
>>>
>>> GCC with LTO enabled will emit such instructions for Mmio[Read|Write]
>>> invocations performed in a loop, so we need to disable LTO [...]
>>
>> We have a Red Hat Bugzilla about the (very likely) same issue [2].
>>
>> Earlier, we had to work around the same on AArch64 too [3].
>>
>> Would it be possible to introduce a dedicated -mXXX option, for ARM and
>> AArch64, that disabled the generation of such multi-operand
>> instructions?
>>
>> I note there are several similar instructions (for other architectures):
>> * -mno-multiple (ppc)
>> * -mno-fused-madd (ia64)
>> * -mno-mmx and a lot of friends (x86)
>>
>> Obviously, if the feature request is deemed justified, we should provide
>> the exact family of instructions to disable. I'll leave that to others
>> on the CC list with more ARM/AArch64 expertise; I just wanted to get
>> this thread started. (Sorry if the option is already being requested
>> elsewhere; I admit I didn't search the GCC bugzilla.)
>>
> 
> I am not convinced that tweaking GCC code generation is the correct
> approach here, to be honest.
> 
> The issue only occurs when load/store instructions trap into KVM,
> which (correct me if I am wrong) mostly only occurs when emulating
> MMIO. The case I have been looking into (UEFI) uses MMIO accessors
> correctly, but due to the way they are implemented (in C), LTO code
> generation may result in load/store instructions with multiple outputs
> to be used.
> 
> So first of all, I would like to understand the magnitude of the
> problem. If all cases we can identify involve performing MMIO using C
> memory references, I think we should fix the code rather than the
> compiler.

To my understanding, Daniel has the opposite preference; namely, the
above approach doesn't scale to a large and moving target like the
kernel. Because the instructions in question work on the bare metal
(IOW, the guest code is not "broken" in any sense of the word), people
will continue writing kernel MMIO code in C that "lures" gcc into
generating such ARM/AArch64 assembly that contains those instructions.

The RHBZ I linked earlier remains elusive; the issue is not easy to
trigger, and when it does trigger, one has to investigate the symptoms
(the guest code at the trap address) every time, trace it back to
C-language source code, and either tweak that C code, or else tweak the
compiler flags specifically for that code / module. AIUI Daniel prefers
to work around the KVM issue without having to analyze every guest site,
as they pop up over time. The expression "all cases we can identify" is
the core of the problem; it's not a well-defined set.

Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a
pin-point location; another possibility (that might scale better to
humans) is a new, lighter-weight flag, such as "-mno-multiple", that is
applied universally to a codebase.

Thanks!
Laszlo

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Ard Biesheuvel]

On 5 June 2018 at 10:16, Laszlo Ersek  wrote:
> On 06/05/18 08:04, Ard Biesheuvel wrote:
>> On 4 June 2018 at 20:10, Laszlo Ersek  wrote:
>>> Hi!
>>>
>>> Apologies if this isn't the right place for asking. For the problem
>>> statement, I'll simply steal Ard's writeup [1]:
>>>
 KVM on ARM refuses to decode load/store instructions used to perform
 I/O to emulated devices, and instead relies on the exception syndrome
 information to describe the operand register, access size, etc. This
 is only possible for instructions that have a single input/output
 register (as opposed to ones that increment the offset register, or
 load/store pair instructions, etc). Otherwise, QEMU crashes with the
 following error

   error: kvm run failed Function not implemented
   [...]
   QEMU: Terminated

 and KVM produces a warning such as the following in the kernel log

   kvm [17646]: load/store instruction decoding not implemented

 GCC with LTO enabled will emit such instructions for Mmio[Read|Write]
 invocations performed in a loop, so we need to disable LTO [...]
>>>
>>> We have a Red Hat Bugzilla about the (very likely) same issue [2].
>>>
>>> Earlier, we had to work around the same on AArch64 too [3].
>>>
>>> Would it be possible to introduce a dedicated -mXXX option, for ARM and
>>> AArch64, that disabled the generation of such multi-operand
>>> instructions?
>>>
>>> I note there are several similar instructions (for other architectures):
>>> * -mno-multiple (ppc)
>>> * -mno-fused-madd (ia64)
>>> * -mno-mmx and a lot of friends (x86)
>>>
>>> Obviously, if the feature request is deemed justified, we should provide
>>> the exact family of instructions to disable. I'll leave that to others
>>> on the CC list with more ARM/AArch64 expertise; I just wanted to get
>>> this thread started. (Sorry if the option is already being requested
>>> elsewhere; I admit I didn't search the GCC bugzilla.)
>>>
>>
>> I am not convinced that tweaking GCC code generation is the correct
>> approach here, to be honest.
>>
>> The issue only occurs when load/store instructions trap into KVM,
>> which (correct me if I am wrong) mostly only occurs when emulating
>> MMIO. The case I have been looking into (UEFI) uses MMIO accessors
>> correctly, but due to the way they are implemented (in C), LTO code
>> generation may result in load/store instructions with multiple outputs
>> to be used.
>>
>> So first of all, I would like to understand the magnitude of the
>> problem. If all cases we can identify involve performing MMIO using C
>> memory references, I think we should fix the code rather than the
>> compiler.
>
> To my understanding, Daniel has the opposite preference; namely, the
> above approach doesn't scale to a large and moving target like the
> kernel. Because the instructions in question work on the bare metal
> (IOW, the guest code is not "broken" in any sense of the word), people
> will continue writing kernel MMIO code in C that "lures" gcc into
> generating such ARM/AArch64 assembly that contains those instructions.
>
> The RHBZ I linked earlier remains elusive; the issue is not easy to
> trigger, and when it does trigger, one has to investigate the symptoms
> (the guest code at the trap address) every time, trace it back to
> C-language source code, and either tweak that C code, or else tweak the
> compiler flags specifically for that code / module. AIUI Daniel prefers
> to work around the KVM issue without having to analyze every guest site,
> as they pop up over time. The expression "all cases we can identify" is
> the core of the problem; it's not a well-defined set.
>
> Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a
> pin-point location; another possibility (that might scale better to
> humans) is a new, lighter-weight flag, such as "-mno-multiple", that is
> applied universally to a codebase.
>

That will affect *all* memory references, which will undoubtedly hurt
performance.

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Ard Biesheuvel]

(I hit 'Send' too soon, apologies for the two stage reply)

On 5 June 2018 at 10:18, Ard Biesheuvel  wrote:
> On 5 June 2018 at 10:16, Laszlo Ersek  wrote:
>> On 06/05/18 08:04, Ard Biesheuvel wrote:
>>> On 4 June 2018 at 20:10, Laszlo Ersek  wrote:
 Hi!

 Apologies if this isn't the right place for asking. For the problem
 statement, I'll simply steal Ard's writeup [1]:

> KVM on ARM refuses to decode load/store instructions used to perform
> I/O to emulated devices, and instead relies on the exception syndrome
> information to describe the operand register, access size, etc. This
> is only possible for instructions that have a single input/output
> register (as opposed to ones that increment the offset register, or
> load/store pair instructions, etc). Otherwise, QEMU crashes with the
> following error
>
>   error: kvm run failed Function not implemented
>   [...]
>   QEMU: Terminated
>
> and KVM produces a warning such as the following in the kernel log
>
>   kvm [17646]: load/store instruction decoding not implemented
>
> GCC with LTO enabled will emit such instructions for Mmio[Read|Write]
> invocations performed in a loop, so we need to disable LTO [...]

 We have a Red Hat Bugzilla about the (very likely) same issue [2].

 Earlier, we had to work around the same on AArch64 too [3].

 Would it be possible to introduce a dedicated -mXXX option, for ARM and
 AArch64, that disabled the generation of such multi-operand
 instructions?

 I note there are several similar instructions (for other architectures):
 * -mno-multiple (ppc)
 * -mno-fused-madd (ia64)
 * -mno-mmx and a lot of friends (x86)

 Obviously, if the feature request is deemed justified, we should provide
 the exact family of instructions to disable. I'll leave that to others
 on the CC list with more ARM/AArch64 expertise; I just wanted to get
 this thread started. (Sorry if the option is already being requested
 elsewhere; I admit I didn't search the GCC bugzilla.)

>>>
>>> I am not convinced that tweaking GCC code generation is the correct
>>> approach here, to be honest.
>>>
>>> The issue only occurs when load/store instructions trap into KVM,
>>> which (correct me if I am wrong) mostly only occurs when emulating
>>> MMIO. The case I have been looking into (UEFI) uses MMIO accessors
>>> correctly, but due to the way they are implemented (in C), LTO code
>>> generation may result in load/store instructions with multiple outputs
>>> to be used.
>>>
>>> So first of all, I would like to understand the magnitude of the
>>> problem. If all cases we can identify involve performing MMIO using C
>>> memory references, I think we should fix the code rather than the
>>> compiler.
>>
>> To my understanding, Daniel has the opposite preference; namely, the
>> above approach doesn't scale to a large and moving target like the
>> kernel. Because the instructions in question work on the bare metal
>> (IOW, the guest code is not "broken" in any sense of the word), people
>> will continue writing kernel MMIO code in C that "lures" gcc into
>> generating such ARM/AArch64 assembly that contains those instructions.
>>

Kernel MMIO code is not written in C, it used readl/writel and friends.

>> The RHBZ I linked earlier remains elusive; the issue is not easy to
>> trigger, and when it does trigger, one has to investigate the symptoms
>> (the guest code at the trap address) every time, trace it back to
>> C-language source code, and either tweak that C code, or else tweak the
>> compiler flags specifically for that code / module. AIUI Daniel prefers
>> to work around the KVM issue without having to analyze every guest site,
>> as they pop up over time. The expression "all cases we can identify" is
>> the core of the problem; it's not a well-defined set.
>>
>> Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a
>> pin-point location; another possibility (that might scale better to
>> humans) is a new, lighter-weight flag, such as "-mno-multiple", that is
>> applied universally to a codebase.
>>
>
> That will affect *all* memory references, which will undoubtedly hurt
> performance.

... given that it will prevent us from using load/store pair
instructions, which are used *everywhere*. Every function prologue
consists of a collection of ldp instructions, every function epilogue
has stp instructions. Optimized copy routines use ldp/stp as well.

So rebuilding the world with -mno-multiple is not going to fly, really.

We should probably start with improving the diagnostics produced by
KVM when this situation hits. And given that this is (imo) a bug in
the architecture, it should be up to KVM to work around it.

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Laszlo Ersek]

On 06/05/18 10:18, Ard Biesheuvel wrote:
> On 5 June 2018 at 10:16, Laszlo Ersek  wrote:
>> On 06/05/18 08:04, Ard Biesheuvel wrote:
>>> On 4 June 2018 at 20:10, Laszlo Ersek  wrote:
 Hi!

 Apologies if this isn't the right place for asking. For the problem
 statement, I'll simply steal Ard's writeup [1]:

> KVM on ARM refuses to decode load/store instructions used to perform
> I/O to emulated devices, and instead relies on the exception syndrome
> information to describe the operand register, access size, etc. This
> is only possible for instructions that have a single input/output
> register (as opposed to ones that increment the offset register, or
> load/store pair instructions, etc). Otherwise, QEMU crashes with the
> following error
>
>   error: kvm run failed Function not implemented
>   [...]
>   QEMU: Terminated
>
> and KVM produces a warning such as the following in the kernel log
>
>   kvm [17646]: load/store instruction decoding not implemented
>
> GCC with LTO enabled will emit such instructions for Mmio[Read|Write]
> invocations performed in a loop, so we need to disable LTO [...]

 We have a Red Hat Bugzilla about the (very likely) same issue [2].

 Earlier, we had to work around the same on AArch64 too [3].

 Would it be possible to introduce a dedicated -mXXX option, for ARM and
 AArch64, that disabled the generation of such multi-operand
 instructions?

 I note there are several similar instructions (for other architectures):
 * -mno-multiple (ppc)
 * -mno-fused-madd (ia64)
 * -mno-mmx and a lot of friends (x86)

 Obviously, if the feature request is deemed justified, we should provide
 the exact family of instructions to disable. I'll leave that to others
 on the CC list with more ARM/AArch64 expertise; I just wanted to get
 this thread started. (Sorry if the option is already being requested
 elsewhere; I admit I didn't search the GCC bugzilla.)

>>>
>>> I am not convinced that tweaking GCC code generation is the correct
>>> approach here, to be honest.
>>>
>>> The issue only occurs when load/store instructions trap into KVM,
>>> which (correct me if I am wrong) mostly only occurs when emulating
>>> MMIO. The case I have been looking into (UEFI) uses MMIO accessors
>>> correctly, but due to the way they are implemented (in C), LTO code
>>> generation may result in load/store instructions with multiple outputs
>>> to be used.
>>>
>>> So first of all, I would like to understand the magnitude of the
>>> problem. If all cases we can identify involve performing MMIO using C
>>> memory references, I think we should fix the code rather than the
>>> compiler.
>>
>> To my understanding, Daniel has the opposite preference; namely, the
>> above approach doesn't scale to a large and moving target like the
>> kernel. Because the instructions in question work on the bare metal
>> (IOW, the guest code is not "broken" in any sense of the word), people
>> will continue writing kernel MMIO code in C that "lures" gcc into
>> generating such ARM/AArch64 assembly that contains those instructions.
>>
>> The RHBZ I linked earlier remains elusive; the issue is not easy to
>> trigger, and when it does trigger, one has to investigate the symptoms
>> (the guest code at the trap address) every time, trace it back to
>> C-language source code, and either tweak that C code, or else tweak the
>> compiler flags specifically for that code / module. AIUI Daniel prefers
>> to work around the KVM issue without having to analyze every guest site,
>> as they pop up over time. The expression "all cases we can identify" is
>> the core of the problem; it's not a well-defined set.
>>
>> Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a
>> pin-point location; another possibility (that might scale better to
>> humans) is a new, lighter-weight flag, such as "-mno-multiple", that is
>> applied universally to a codebase.
>>
> 
> That will affect *all* memory references, which will undoubtedly hurt
> performance.
> 

No doubt; it will also make it easier for humans to support a codebase.
The flag is not being proposed to be enabled by default (for any
codebase); an organization can make a choice to build the code they ship
and support with the flag, trading some code performance for less
support (analysis) burden.

(NB personally I'm neutral on which approach is taken, I'm just trying
to convey the idea.)

Thanks,
Laszlo

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Laszlo Ersek]

On 06/05/18 10:23, Ard Biesheuvel wrote:
> On 5 June 2018 at 10:18, Ard Biesheuvel  wrote:
>> On 5 June 2018 at 10:16, Laszlo Ersek  wrote:

>>> To my understanding, Daniel has the opposite preference; namely, the
>>> above approach doesn't scale to a large and moving target like the
>>> kernel. Because the instructions in question work on the bare metal
>>> (IOW, the guest code is not "broken" in any sense of the word), people
>>> will continue writing kernel MMIO code in C that "lures" gcc into
>>> generating such ARM/AArch64 assembly that contains those instructions.
>>>
> 
> Kernel MMIO code is not written in C, it used readl/writel and friends.

Are we certain that all drivers, and all platform MMIO code, use
readl/writel?

>>> Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a
>>> pin-point location; another possibility (that might scale better to
>>> humans) is a new, lighter-weight flag, such as "-mno-multiple", that is
>>> applied universally to a codebase.
>>>
>>
>> That will affect *all* memory references, which will undoubtedly hurt
>> performance.
> 
> ... given that it will prevent us from using load/store pair
> instructions, which are used *everywhere*. Every function prologue
> consists of a collection of ldp instructions, every function epilogue
> has stp instructions. Optimized copy routines use ldp/stp as well.
> 
> So rebuilding the world with -mno-multiple is not going to fly, really.
> 
> We should probably start with improving the diagnostics produced by
> KVM when this situation hits.

That would indeed speed up things, on the analysis side.

> And given that this is (imo) a bug in
> the architecture, it should be up to KVM to work around it.

I've had a similar idea (not sure how correct I am to call it "similar",
let me say it is "related to virtualization" at the least) -- AIUI there
are various "paravirt ops" in the kernel, and readl/writel could be "KVM
friendly" when the kernel realizes it runs under KVM. Sorry if this is a
totally bogus idea; regardless, even if we did something similar at
build time that *only* penalized readl/writel (and not function
prologues, epilogues, or copy routines), the issue would remain whether
all drivers and platform MMIO code restricted themselves to readl/writel.

Thanks!
Laszlo

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Ard Biesheuvel]

On 5 June 2018 at 10:54, Laszlo Ersek  wrote:
> On 06/05/18 10:23, Ard Biesheuvel wrote:
>> On 5 June 2018 at 10:18, Ard Biesheuvel  wrote:
>>> On 5 June 2018 at 10:16, Laszlo Ersek  wrote:
>
 To my understanding, Daniel has the opposite preference; namely, the
 above approach doesn't scale to a large and moving target like the
 kernel. Because the instructions in question work on the bare metal
 (IOW, the guest code is not "broken" in any sense of the word), people
 will continue writing kernel MMIO code in C that "lures" gcc into
 generating such ARM/AArch64 assembly that contains those instructions.

>>
>> Kernel MMIO code is not written in C, it used readl/writel and friends.
>
> Are we certain that all drivers, and all platform MMIO code, use
> readl/writel?
>
 Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a
 pin-point location; another possibility (that might scale better to
 humans) is a new, lighter-weight flag, such as "-mno-multiple", that is
 applied universally to a codebase.

>>>
>>> That will affect *all* memory references, which will undoubtedly hurt
>>> performance.
>>
>> ... given that it will prevent us from using load/store pair
>> instructions, which are used *everywhere*. Every function prologue
>> consists of a collection of ldp instructions, every function epilogue
>> has stp instructions. Optimized copy routines use ldp/stp as well.
>>
>> So rebuilding the world with -mno-multiple is not going to fly, really.
>>
>> We should probably start with improving the diagnostics produced by
>> KVM when this situation hits.
>
> That would indeed speed up things, on the analysis side.
>
>> And given that this is (imo) a bug in
>> the architecture, it should be up to KVM to work around it.
>
> I've had a similar idea (not sure how correct I am to call it "similar",
> let me say it is "related to virtualization" at the least) -- AIUI there
> are various "paravirt ops" in the kernel, and readl/writel could be "KVM
> friendly" when the kernel realizes it runs under KVM. Sorry if this is a
> totally bogus idea; regardless, even if we did something similar at
> build time that *only* penalized readl/writel (and not function
> prologues, epilogues, or copy routines), the issue would remain whether
> all drivers and platform MMIO code restricted themselves to readl/writel.
>

The more I look into the BZ you quoted, the more I think the multiple
register thing is a red herring (in the conetext of that bug, mind
you)

I replied (and am about to reply again) there.

https://bugzilla.redhat.com/show_bug.cgi?id=1576593

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Laszlo Ersek]

On 06/05/18 10:56, Ard Biesheuvel wrote:
> On 5 June 2018 at 10:54, Laszlo Ersek  wrote:
>> On 06/05/18 10:23, Ard Biesheuvel wrote:
>>> On 5 June 2018 at 10:18, Ard Biesheuvel  wrote:
 On 5 June 2018 at 10:16, Laszlo Ersek  wrote:
>>
> To my understanding, Daniel has the opposite preference; namely, the
> above approach doesn't scale to a large and moving target like the
> kernel. Because the instructions in question work on the bare metal
> (IOW, the guest code is not "broken" in any sense of the word), people
> will continue writing kernel MMIO code in C that "lures" gcc into
> generating such ARM/AArch64 assembly that contains those instructions.
>
>>>
>>> Kernel MMIO code is not written in C, it used readl/writel and friends.
>>
>> Are we certain that all drivers, and all platform MMIO code, use
>> readl/writel?
>>
> Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a
> pin-point location; another possibility (that might scale better to
> humans) is a new, lighter-weight flag, such as "-mno-multiple", that is
> applied universally to a codebase.
>

 That will affect *all* memory references, which will undoubtedly hurt
 performance.
>>>
>>> ... given that it will prevent us from using load/store pair
>>> instructions, which are used *everywhere*. Every function prologue
>>> consists of a collection of ldp instructions, every function epilogue
>>> has stp instructions. Optimized copy routines use ldp/stp as well.
>>>
>>> So rebuilding the world with -mno-multiple is not going to fly, really.
>>>
>>> We should probably start with improving the diagnostics produced by
>>> KVM when this situation hits.
>>
>> That would indeed speed up things, on the analysis side.
>>
>>> And given that this is (imo) a bug in
>>> the architecture, it should be up to KVM to work around it.
>>
>> I've had a similar idea (not sure how correct I am to call it "similar",
>> let me say it is "related to virtualization" at the least) -- AIUI there
>> are various "paravirt ops" in the kernel, and readl/writel could be "KVM
>> friendly" when the kernel realizes it runs under KVM. Sorry if this is a
>> totally bogus idea; regardless, even if we did something similar at
>> build time that *only* penalized readl/writel (and not function
>> prologues, epilogues, or copy routines), the issue would remain whether
>> all drivers and platform MMIO code restricted themselves to readl/writel.
>>
> 
> The more I look into the BZ you quoted, the more I think the multiple
> register thing is a red herring (in the conetext of that bug, mind
> you)
> 
> I replied (and am about to reply again) there.
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1576593
> 

Thank you for helping out with it!
Laszlo

Re: __builtin_isnormal question

[Andrew Haley]

On 06/04/2018 09:44 PM, Steve Ellcey wrote:
> 0.0 is a normal (as opposed to a denormalized) number isn't
> it?  Or is zero special?

In addition to the other answers, yes, zero is special.  Normal numbers
in IEEE-754 have an implicit leading 1 bit.  Zero is a case of a denormal
number.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Ramana Radhakrishnan]

On Tue, Jun 5, 2018 at 9:16 AM, Laszlo Ersek  wrote:
> On 06/05/18 08:04, Ard Biesheuvel wrote:
>> On 4 June 2018 at 20:10, Laszlo Ersek  wrote:
>>> Hi!
>>>
>>> Apologies if this isn't the right place for asking. For the problem
>>> statement, I'll simply steal Ard's writeup [1]:
>>>
 KVM on ARM refuses to decode load/store instructions used to perform
 I/O to emulated devices, and instead relies on the exception syndrome
 information to describe the operand register, access size, etc. This
 is only possible for instructions that have a single input/output
 register (as opposed to ones that increment the offset register, or
 load/store pair instructions, etc). Otherwise, QEMU crashes with the
 following error

   error: kvm run failed Function not implemented
   [...]
   QEMU: Terminated

 and KVM produces a warning such as the following in the kernel log

   kvm [17646]: load/store instruction decoding not implemented

 GCC with LTO enabled will emit such instructions for Mmio[Read|Write]
 invocations performed in a loop, so we need to disable LTO [...]
>>>
>>> We have a Red Hat Bugzilla about the (very likely) same issue [2].
>>>
>>> Earlier, we had to work around the same on AArch64 too [3].
>>>
>>> Would it be possible to introduce a dedicated -mXXX option, for ARM and
>>> AArch64, that disabled the generation of such multi-operand
>>> instructions?
>>>
>>> I note there are several similar instructions (for other architectures):
>>> * -mno-multiple (ppc)
>>> * -mno-fused-madd (ia64)
>>> * -mno-mmx and a lot of friends (x86)
>>>
>>> Obviously, if the feature request is deemed justified, we should provide
>>> the exact family of instructions to disable. I'll leave that to others
>>> on the CC list with more ARM/AArch64 expertise; I just wanted to get
>>> this thread started. (Sorry if the option is already being requested
>>> elsewhere; I admit I didn't search the GCC bugzilla.)
>>>
>>
>> I am not convinced that tweaking GCC code generation is the correct
>> approach here, to be honest.
>>
>> The issue only occurs when load/store instructions trap into KVM,
>> which (correct me if I am wrong) mostly only occurs when emulating
>> MMIO. The case I have been looking into (UEFI) uses MMIO accessors
>> correctly, but due to the way they are implemented (in C), LTO code
>> generation may result in load/store instructions with multiple outputs
>> to be used.
>>
>> So first of all, I would like to understand the magnitude of the
>> problem. If all cases we can identify involve performing MMIO using C
>> memory references, I think we should fix the code rather than the
>> compiler.
>
> To my understanding, Daniel has the opposite preference; namely, the
> above approach doesn't scale to a large and moving target like the
> kernel. Because the instructions in question work on the bare metal
> (IOW, the guest code is not "broken" in any sense of the word), people
> will continue writing kernel MMIO code in C that "lures" gcc into
> generating such ARM/AArch64 assembly that contains those instructions.
>
> The RHBZ I linked earlier remains elusive; the issue is not easy to
> trigger, and when it does trigger, one has to investigate the symptoms
> (the guest code at the trap address) every time, trace it back to
> C-language source code, and either tweak that C code, or else tweak the
> compiler flags specifically for that code / module. AIUI Daniel prefers
> to work around the KVM issue without having to analyze every guest site,
> as they pop up over time. The expression "all cases we can identify" is
> the core of the problem; it's not a well-defined set.
>
> Your edk2 ArmVirtQemu patch adds a heavy-weight flag (-fno-lto) to a
> pin-point location; another possibility (that might scale better to
> humans) is a new, lighter-weight flag, such as "-mno-multiple", that is
> applied universally to a codebase.



I don't see enough detail to explain what the problem is in the first place.

LTO to me is a red-herring here and smells of a hack. There's no
guarantee that GCC won't use these instructions in non-LTO
configurations and infact will aggressively do this in a number of
situations. The -fno-lto fix and the fix for disabling load / store
multiple or load / store pair being suggested here both smell of an
underlying problem that needs to be understood in the various
sourcebases first.



Ramana

>
> Thanks!
> Laszlo

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Richard Biener]

On Mon, Jun 4, 2018 at 8:11 PM Laszlo Ersek  wrote:
>
> Hi!
>
> Apologies if this isn't the right place for asking. For the problem
> statement, I'll simply steal Ard's writeup [1]:
>
> > KVM on ARM refuses to decode load/store instructions used to perform
> > I/O to emulated devices, and instead relies on the exception syndrome
> > information to describe the operand register, access size, etc. This
> > is only possible for instructions that have a single input/output
> > register (as opposed to ones that increment the offset register, or
> > load/store pair instructions, etc). Otherwise, QEMU crashes with the
> > following error
> >
> >   error: kvm run failed Function not implemented
> >   [...]
> >   QEMU: Terminated
> >
> > and KVM produces a warning such as the following in the kernel log
> >
> >   kvm [17646]: load/store instruction decoding not implemented

This looks like a kvm/qemu issue to me.  Whatever that exception syndrome
thing is, it surely has a pointer to the offending instruction it could decode?

> >
> > GCC with LTO enabled will emit such instructions for Mmio[Read|Write]
> > invocations performed in a loop, so we need to disable LTO [...]
>
> We have a Red Hat Bugzilla about the (very likely) same issue [2].
>
> Earlier, we had to work around the same on AArch64 too [3].
>
> Would it be possible to introduce a dedicated -mXXX option, for ARM and
> AArch64, that disabled the generation of such multi-operand
> instructions?
>
> I note there are several similar instructions (for other architectures):
> * -mno-multiple (ppc)
> * -mno-fused-madd (ia64)
> * -mno-mmx and a lot of friends (x86)
>
> Obviously, if the feature request is deemed justified, we should provide
> the exact family of instructions to disable. I'll leave that to others
> on the CC list with more ARM/AArch64 expertise; I just wanted to get
> this thread started. (Sorry if the option is already being requested
> elsewhere; I admit I didn't search the GCC bugzilla.)
>
> Thanks!
> Laszlo
>
> [1] https://lists.01.org/pipermail/edk2-devel/2018-June/025476.html
> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1576593
> [3] https://github.com/tianocore/edk2/commit/2efbf710e27a

Re: aliasing between internal zero-length-arrays and other members

[Richard Biener]

On Tue, Jun 5, 2018 at 1:39 AM Martin Sebor  wrote:
>
> GCC silently (without -Wpedantic) accepts declarations of zero
> length arrays that are followed by other members in the same
> struct, such as in:
>
>struct A { char a, b[0], c; };
>
> Is it intended that accesses to elements of such arrays that
> alias other members be well-defined?

The middle-end assumes that fields in a structure do not overlap.
For overlaps you have to use a union.

In C++ I guess the rule that sizeof() of anything is at least 1 saves
you here so IMHO this is a C FE bug and we should probably simply
reject non-trailing empty arrays.

Note since b has size zero there isn't any real overlap, so ...

> In my tests, GCC assumes that neither read nor write accesses
> to elements of internal zero-length arrays alias other members,
> so assuming those aren't bugs I wonder if the documentation
> should be updated to make that clear and a warning added for
> such declarations (and perhaps also accesses).
>
> For example, the test in the following function is eliminated,
> implying that GCC assumes that the access to p->b does not modify
> p->c, even though with i set to 0 it would:
>
>void f (struct A *p, int i)
>{
>  int x = p->c;
>  p->b[i] = 1;
>  if (x != p->c)
>__builtin_abort ();

... your testcase simply invokes undefined behavior by accessing
b out of bounds.

Richard.

>}
>
> Martin

Re: aliasing between internal zero-length-arrays and other members

[Jakub Jelinek]

On Tue, Jun 05, 2018 at 01:38:21PM +0200, Richard Biener wrote:
> On Tue, Jun 5, 2018 at 1:39 AM Martin Sebor  wrote:
> >
> > GCC silently (without -Wpedantic) accepts declarations of zero
> > length arrays that are followed by other members in the same
> > struct, such as in:
> >
> >struct A { char a, b[0], c; };
> >
> > Is it intended that accesses to elements of such arrays that
> > alias other members be well-defined?
> 
> The middle-end assumes that fields in a structure do not overlap.
> For overlaps you have to use a union.
> 
> In C++ I guess the rule that sizeof() of anything is at least 1 saves
> you here so IMHO this is a C FE bug and we should probably simply
> reject non-trailing empty arrays.

The above is not flexible array member, but zero sized array, that is just
fine anywhere, at the toplevel as well as anywhere inside of the struct.
And yes, accessing it out of bounds is invalid, unless it is flexible-like,
i.e. at the end of the struct.

Jakub

Re: How to debug .md file?

[Martin Liška]

On 06/05/2018 09:14 AM, DeepaBallari via gcc wrote:
> Hello,I'm a newbie to GCC.Have done some changes to .md file(specifically 
> peephole.md) and the changes are not taking place.How to debug the .md file ?
> Thanks!
> 

Hi.

.md files are transformed using gen* tools into C files. There's small example 
(from insn-recog.c):

131239  static rtx_insn *
131240  peephole2_3 (rtx x1 ATTRIBUTE_UNUSED,
131241  rtx_insn *insn ATTRIBUTE_UNUSED,
131242  int *pmatch_len_ ATTRIBUTE_UNUSED)
131243  {
131244rtx * const operands ATTRIBUTE_UNUSED = &recog_data.operand[0];
131245rtx x2, x3, x4, x5, x6, x7, x8;
131246rtx_insn *res ATTRIBUTE_UNUSED;
131247x2 = PATTERN (peep2_next_insn (1));
131248if (GET_CODE (x2) != SET)
131249  return NULL;
131250x3 = XEXP (x2, 1);
131251if (GET_CODE (x3) != SUBREG
131252|| maybe_ne (SUBREG_BYTE (x3), 0)
131253|| GET_MODE (x3) != E_SImode)
131254  return NULL;
131255x4 = XEXP (x2, 0);
131256if (GET_CODE (x4) != ZERO_EXTRACT
131257|| GET_MODE (x4) != E_SImode)
131258  return NULL;
131259x5 = XEXP (x4, 1);
131260if (x5 != const_int_rtx[MAX_SAVED_CONST_INT + 8])
131261  return NULL;
131262x6 = XEXP (x4, 2);
131263if (x6 != const_int_rtx[MAX_SAVED_CONST_INT + 8])
131264  return NULL;
131265x7 = XEXP (x4, 0);
131266operands[2] = x7;
131267if (!ext_register_operand (operands[2], E_VOIDmode))
131268  return NULL;
131269x8 = XEXP (x3, 0);
131270if (!rtx_equal_p (x8, operands[0])
131271|| !
131272  #line 3125 "../../gcc/config/i386/i386.md"
131273  (TARGET_64BIT
131274 && peep2_reg_dead_p (2, operands[0])))
131275  return NULL;
131276*pmatch_len_ = 1;
131277return gen_peephole2_5 (insn, operands);
131278  }

As you can see, there are '#line' directives. These should be debugable in GDB:
$ break i386.md:3125.

Alternative approach is to put gcc_unreachable into a peephole and then you 
should
be able to debug that. Note that I would recommend to automatically load 
./gcc/gdbhooks.py file.

Martin

Re: Solaris issues

[Rainer Orth]

Hi Paul,

> I was only talking about adding support to aligned new/delete on Valgrind
> (here is the bugzilla entry I created if you are interested
> https://bugs.kde.org/show_bug.cgi?id=388787
> )
>
> On Solaris (I’m using 11.3) Valgrind is having problems because of the
> large number of .rodate sections. I haven’t seen this problem on Linux.
>
> Here again are the details:
>
>
> Currently Valgrind can’t cope with the .rodata sections that get generated
> (see bugzilla https://bugs.kde.org/show_bug.cgi?id=390871
>  >)
>
> Here’s an extract from the report
>
> --18142-- WARNING: Serious error when reading debug info
> --18142-- When reading debug info from
> /export/home/paulf/tools/gcc/lib/libstdc++.so.6.0.25:
> --18142-- Can't make sense of .rodata section mapping
>
> The cause appears to be hundreds of Elf32_Shdr (also Elf64_Shdr) with names
> .rodata and/or .rodata..  Sample:
> Section Headers:
>  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf 
> Al
>  [15] .rodata._ZNKSt10l PROGBITS00093a88 093a88 10 01 AMS  0   0  
> 1
>  [16] .rodata._ZNKSt12_ PROGBITS00093a98 093a98 08 01 AMS  0   0  
> 1
>  [17] .rodata._ZNKSt12_ PROGBITS00093aa0 093aa0 07 01 AMS  0   0  
> 1
>  [18] .rodata   PROGBITS00093ac0 093ac0 003504 00   A  0   0 
> 32
>  [19] .rodata._ZTSNSt12 PROGBITS00096fe0 096fe0 2c 00   A  0   0 
> 32
>  [20] .rodata._ZTSNSt12 PROGBITS00097020 097020 2b 00   A  0   0 
> 32
>  [21] .rodata._ZNSt6chr PROGBITS0009704b 09704b 01 00   A  0   0  
> 1
>  [22] .rodata._ZNSt6chr PROGBITS0009704c 09704c 01 00   A  0   0  
> 1
>  [23] .rodata._ZNKSt9ba PROGBITS0009704d 09704d 0f 01 AMS  0   0  
> 1
>  [24] .rodata._ZNKSt16b PROGBITS0009705c 09705c 16 01 AMS  0   0  
> 1
>  [25] .rodata._ZNKSt20b PROGBITS00097072 097072 1a 01 AMS  0   0  
> 1
>  [26] .rodata._ZNKSt8ba PROGBITS0009708c 09708c 0e 01 AMS  0   0  
> 1
>  [27] .rodata._ZNKSt10b PROGBITS0009709a 09709a 10 01 AMS  0   0  
> 1
>  [28] .rodata   PROGBITS000970ac 0970ac 0002b4 01 AMS  0   0  
> 4
>  [29] .rodata._ZNKSt9ex PROGBITS00097360 097360 0f 01 AMS  0   0  
> 1
> and there are 639 more .rodata* Sections in that one file.
>
> Inspection shows that the .rodata* are adjacent after considering
> alignment.  Therefore a workaround might be for the debuginfo reader to
> aggregate them all into a single internal .rodata section.  A simple
> proposed patch is:
> https://bugsfiles.kde.org/attachment.cgi?id=110638
> 
>  >
> The above patch does fix the problem.
> Any idea why so many sections are getting generated? (The test case is
> trivially small)

those sections are in libstdc++.so.  They can be found in the input
objects used to created libstdc++.so on Linux and Solaris alike, due to
the use of -fdata-sections (via SECTION_FLAGS) in libstdc++.

However, on Linux gld is usually used, which is driven by linker maps
that often coalesce sections based on section name patters.  OTOH,
Solaris ld (which I assume you used) usually doesn't care about section
names, but does the bulk of its work based on section attributes alone.
The ultimate result is the same (all .rodata* sections land in the
read-only text segment at runtime), since sections don't matter to the
kernel, only segments do.

You can read about the gory details on how Solaris ld does that part of
its work at

https://docs.oracle.com/cd/E37838_01/html/E36783/gjqaz.html#scrolltoc

(and doubtlessly somewhere on linker-aliens.org ;-)

In Solaris 11.4, there were some changes here for better GNU (bug)
compatibility, so there's only a single .rodata section here.  However,
there's nothing wrong with how Solaris ld behaved before: I'd claim this
is a scalability bug in valgrind: ELF objects can have very large
numbers of sections for all sorts of legitimate resons, so it needs to
cope with them.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: code-gen options for disabling multi-operand AArch64 and ARM instructions

[Laszlo Ersek]

On 06/05/18 13:30, Richard Biener wrote:
> On Mon, Jun 4, 2018 at 8:11 PM Laszlo Ersek  wrote:
>>
>> Hi!
>>
>> Apologies if this isn't the right place for asking. For the problem
>> statement, I'll simply steal Ard's writeup [1]:
>>
>>> KVM on ARM refuses to decode load/store instructions used to perform
>>> I/O to emulated devices, and instead relies on the exception syndrome
>>> information to describe the operand register, access size, etc. This
>>> is only possible for instructions that have a single input/output
>>> register (as opposed to ones that increment the offset register, or
>>> load/store pair instructions, etc). Otherwise, QEMU crashes with the
>>> following error
>>>
>>>   error: kvm run failed Function not implemented
>>>   [...]
>>>   QEMU: Terminated
>>>
>>> and KVM produces a warning such as the following in the kernel log
>>>
>>>   kvm [17646]: load/store instruction decoding not implemented
> 
> This looks like a kvm/qemu issue to me.  Whatever that exception syndrome
> thing is, it surely has a pointer to the offending instruction it could 
> decode?

I believe so -- the instruction decoding is theoretically possible (to
my understanding); KVM currently doesn't do it because it's super
complex (again, to my understanding).

Thanks
Laszlo

Salesforce Accounts

[Jennifer Schroeder]

Hi,

 

I am curious to know if you would be interested in acquiring Salesforce
Users List.

 

Information fields: Names, Title, Email, Phone, Company Name, Company URL,
Company physical address, SIC Code, Industry, Company Size (Revenue and
Employee).

 

We also have related product users like: 

*  Pipedrive

*  Freshsales

*  Insightly

*  Zoho CRM and many more.

 

Let me know if you are interested and I will get back to you with the counts
and pricing.

 

Regards,
Jennifer Schroeder

Pre-Sales Executive

 

To stop receiving future emails, please reply with UNSUBSCRIBE in the
Subject Line.  

 

Re: Solaris issues

[paulf]

- Original Message -
> Hi Paul,

[snip - lots of .rodata sections]
 
> 
> those sections are in libstdc++.so.  They can be found in the input
> objects used to created libstdc++.so on Linux and Solaris alike, due
> to
> the use of -fdata-sections (via SECTION_FLAGS) in libstdc++.
> 
> However, on Linux gld is usually used, which is driven by linker maps
> that often coalesce sections based on section name patters.  OTOH,
> Solaris ld (which I assume you used) usually doesn't care about
> section
> names, but does the bulk of its work based on section attributes
> alone.
> The ultimate result is the same (all .rodata* sections land in the
> read-only text segment at runtime), since sections don't matter to
> the
> kernel, only segments do.

I am indeed using Solaris ld - configured with "--without-gnu-ld 
--with-ld=/usr/ccs/bin/ld"


> You can read about the gory details on how Solaris ld does that part
> of
> its work at
> 
> https://docs.oracle.com/cd/E37838_01/html/E36783/gjqaz.html#scrolltoc

I'll have a look. I probably read an older version in the distant past.

> (and doubtlessly somewhere on linker-aliens.org ;-)
> 
> In Solaris 11.4, there were some changes here for better GNU (bug)
> compatibility, so there's only a single .rodata section here.
>  However,
> there's nothing wrong with how Solaris ld behaved before: I'd claim
> this
> is a scalability bug in valgrind: ELF objects can have very large
> numbers of sections for all sorts of legitimate resons, so it needs
> to
> cope with them.
> 
>   Rainer

Hmm OK. Do you know what change caused this?

Since there's a patch for Valgrind to fix it, it looks like that would be the 
best solution.

A+
Paul

Re: Solaris issues

[Rainer Orth]

Hi Paul,

>> In Solaris 11.4, there were some changes here for better GNU (bug)
>> compatibility, so there's only a single .rodata section here.
>>  However,
>> there's nothing wrong with how Solaris ld behaved before: I'd claim
>> this
>> is a scalability bug in valgrind: ELF objects can have very large
>> numbers of sections for all sorts of legitimate resons, so it needs
>> to
>> cope with them.
>> 
>>  Rainer
>
> Hmm OK. Do you know what change caused this?

what change to what?  ld, libstdc++, ...?  I see those multiple
.rodata.* sections as far back as the /usr/sfw/lib/libstdc++.so bundled
in Solaris 10.

> Since there's a patch for Valgrind to fix it, it looks like that would be
> the best solution.

Certainly: besides there's no reason for any artificial limit like it
currently has, they cannot expect everyone to upgrade to Solaris 11.4
once it's released.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Project Ranger

[Andrew MacLeod]

On 06/04/2018 11:21 AM, Richard Biener wrote:

On Mon, Jun 4, 2018 at 5:17 PM Richard Biener
 wrote:>

On Fri, Jun 1, 2018 at 10:38 PM Andrew MacLeod  wrote:

On 06/01/2018 05:48 AM, Richard Biener wrote:

On Wed, May 30, 2018 at 1:53 AM Andrew MacLeod  wrote:

bah, gmail now completely mangles quoting :/

Ah no, you sent a multipart mail and it showed the html variant.  Replying in
plain-text mode messes things up then.  And your mail likely got rejected
by the list anyway.


No mail got rejected.

Sorry.  I don't know what my mailer does sometimes.  I use thunderbird 
and gmail is the underlying service.
anything to the mailing list is suppose to go as plain-text only, 
according to my thunderbird settings.  maybe it sends different things 
to different recipients?


about once a year suddenly the mailing lists start rejecting my emails, 
and then I go poking through the settings trying to understand why, and 
then it just as suddenly stops :-P
I don't have the patience to understand. Maybe its a bug.  It was 
probably compiled with llvm. :-)


ooo. cheap shot.

Andrew

Re: Project Ranger

[Andrew MacLeod]

On 06/04/2018 11:17 AM, Richard Biener wrote:



It wont be perfect however as many of those routines are written with the 
assumption that ranges are either a single range or an anti range. we no longer 
have that restriction and we will diverge in those cases.

But having 1 single range or N ranges isn't different when it comes to
the core working routines.  Because if you have N ranges it's simply
apply the op N times and union the result.  Yes - the special case is




now that OP (range) can result in multiple ranges but currently
all interesting cases you likely implement are simply covered by
returning either a range or an anti-range.  Because more generally
Yeah, This applies to most of the arithmetic operations in particular.   
The range code indeed loops through the sub-ranges applying the 
operation to each one.
And yes most cases do result in a single range, which is why it is ripe 
for sharing.  But we also aren't limited to it.  There are times where 
we can provide different results, such as with AND.  for signed char X:
(X & 0xF0)    vrp produces   [-128, 112]  because it has to be a range 
or an anti range, and has to include 0.   with the 3 ranges we use right 
now, we generate  [-128, -16][0, 0][16, 112]
Even with 2 ranges, we could generate [-128,0][16,112]  (or 
[-128,-16][0,112]) , both of which are somewhat better.


And we can also do better in cases when ranges are combined, like
 if (x != 20 && x != 30) by producing  [-128, 19][21, 29][31, 127] 
signed char

you'd not want N ranges but some affine thing so you can handle even
more cases without blowing up storage.
Why don't we want N ranges?    when we exceed the  number of supported 
ranges in irange, it simply starts merging ranges.  In the AND example 
with 3 sub-ranges supported,  we produce [-128, -16][0, 0][16, 112] .  
If we try to add more sub-ranges than are supported, it simply starts 
merging them.  If we only supported 2 ranges instead of 3, the AND code 
would end up producing [-128,0][16,112]  or [-128,-16][0,112].  both of 
which are correct, just not as precise as if irange supported more. 
Class irange takes care of managing the storage and exact number of 
ranges, so none of the code in range-ops changes to deal with this.. it 
is just works on whatever it is given to produce the best result it can.



Extricating the code from the symbolic handling is also not straightforward 
some times as there are big switches which mix and match various bits of each 
case.

Yes.  Which is why I never really got far with dumping the symbolic
stuff because it's hard to come up with a replacement.  I guess
in reality you want to model symbolic ranges as constraints on affine
expressions and then have some constraint solver to
answer queries -- at least for symbolic ranges the interesting
transforms involve comparison simplifications (aka jump threading)
only.

Yeah its not trivial. The model I'm pursuing tracks  the symbolic 
relationships separately from the range constraints. It can use the 
range constraints if they are useful, but only if they help.


It focuses on the relationships between symbols generated by statements 
and combines sequentially encountered relationships together to 
determine a new relationship and make decisions.  And yes those are 
primarily are comparison points where we'll try to simplify the condition.


for instance
  i = j + 1
  if (i == j)

we don't need a range for 'i' or 'j' to determine this is never true, 
the relationship established in i = j + 1  is either (i != j) or (i < j) 
depending on the type and range of 'i' or 'j'.  Either result applied to 
the following (i == j) relationship makes it clear that the second 
condition can never be true.  We'll do it in the reverse order like the 
rangers current model...see the condition, decide it merits looking at 
for simplification, and look back to see if there are any relationships 
feeding it which can simplify it.


Anyway, thats the general direction I'm working in to resolve that set 
of problems.  And I plan to  integrate it with a copy/cast tracker which 
will allow us to see through copies and "equivalent" equivalencies so we 
don't get tricked :-)





Anyway, the "lateness" of he introduction is purely on me.  I like to get 
things working before talking about them especially when they start with half baked ideas.

I would have liked to see factoring out from current code first and
actually enhancing the current value-range represenation by removing
the
restriction on single ranges.


we started with something like that in mind, but the presence of 
symbolics embedded in the range made it incredibly awkward to add 
support for non-single ranges to the existing representation.


Factoring out the constant bounds aspects of the code is what Aldy is 
currently working on.  When he's finished the existing functions should 
contain just the symbolic processing part of the code, and they will 
call a common base to handle the constan

Re: For which gcc release is going to be foreseen the support for the Coroutines TS extension?

[Florian Weimer]

On 06/04/2018 07:36 PM, Jonathan Wakely wrote:

On 4 June 2018 at 18:32, Marco Ippolito wrote:

Hi all,

clang and VS2017 already support the Coroutines TS extensions.
For which gcc release is going to be foreseen the support for the
Coroutines TS extension?


This has been discussed recently, search the mailing list.

It will be supported after somebody implements it.


If it is in fact implementable on top of the GNU ABI.  Some variants of 
coroutines are not.


Florian