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.
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
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 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
> 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 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
> 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
> 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
> 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.
> 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
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
> 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
> 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
> 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
14 matches
Mail list logo
