> Ok, but the converse — if the general_operand is accessed by more
> than one instruction, it is not safe — is correct, right?
In general, I'd agree, but the ISO spec talks about "sequence points"
and there are times when you *can* access a volatile multiple times as
long as the state is correct
> On Jan 5, 2015, at 4:11 PM, DJ Delorie wrote:
>
>
>> To try to generalize from that: it looks like the operating
>> principle is that an insn that expands into multiple references to a
>> given operand isn’t volatile-safe, but one where there is only a
>> single reference is safe?
>
> No, if
> To try to generalize from that: it looks like the operating
> principle is that an insn that expands into multiple references to a
> given operand isn’t volatile-safe, but one where there is only a
> single reference is safe?
No, if the expanded list of insns does "what the standard says, no
mo
The “news” section first link points to "https://gcc.gnu.org/gcc-5/“ which
comes up “forbidden”. The other release links seem to be fine.
paul
> On Jan 5, 2015, at 1:47 PM, DJ Delorie wrote:
>
>
>> One question: do you have an example of a non-volatile-safe machine so
>> I can get a feel for the problems one might encounter? At best I can
>> imagine a machine that optimizes "add 0, [mem]" to avoid the
>> read/write, but I'm not aware
> I looked in the documentation and didn’t see this described.
AFAIK it's not documented. Only recently was it agreed (and even
then, reluctantly) that the ISO spec could be met by such opcodes.
> One question: do you have an example of a non-volatile-safe machine so
> I can get a feel for the problems one might encounter? At best I can
> imagine a machine that optimizes "add 0, [mem]" to avoid the
> read/write, but I'm not aware of such an ISA.
For example, the MSP430 backend uses a ma
> On Jan 5, 2015, at 1:24 PM, DJ Delorie wrote:
>
>
>> What is involved with the auditing?
>
> Each pattern that (directly or indirectly) uses general_operand,
> memory_operand, or nonimmediate_operand needs to be checked to see if
> it's volatile-safe. If so, you need to change the predicate
On Mon, Jan 5, 2015 at 11:53 AM, DJ Delorie wrote:
>
> Matt Godbolt writes:
>> GCC's code generation uses a "load; add; store" for volatiles, instead
>> of a single "add 1, [metric]".
>
> GCC doesn't know if a target's load/add/store patterns are
> volatile-safe, so it must avoid them. There are
> What is involved with the auditing?
Each pattern that (directly or indirectly) uses general_operand,
memory_operand, or nonimmediate_operand needs to be checked to see if
it's volatile-safe. If so, you need to change the predicate to
something that explicitly accepts volatiles.
There's been t
On Mon, Jan 5, 2015 at 12:53 PM, DJ Delorie wrote:
>
> Matt Godbolt writes:
>> GCC's code generation uses a "load; add; store" for volatiles, instead
>> of a single "add 1, [metric]".
>
> GCC doesn't know if a target's load/add/store patterns are
> volatile-safe, so it must avoid them. There are
Matt Godbolt writes:
> GCC's code generation uses a "load; add; store" for volatiles, instead
> of a single "add 1, [metric]".
GCC doesn't know if a target's load/add/store patterns are
volatile-safe, so it must avoid them. There are a few targets that have
been audited for volatile-safe-ness s
On 01/02/15 16:40, Joel Sherrill wrote:
Hi
While looking for something else, I spotted this spelling error
in configure.ac:
"I suspect your system does not have 32-bit developement"
Since this is in the top level directory, I wanted to make sure
changing this didn't have to be coordinated with
Hello there,
Since my email program won't allow me to send emails directly to this
address only, I guess I'll have to send them by hand. Is there any way
I could help with GCC development? I'd really like to help this
compiler progress and anything I can do would be nicely appreciated.
14 matches
Mail list logo
