Re: basic asm and memory clobbers
On 20/11/15 01:23, David Wohlferd wrote:
> I tried to picture the most basic case I can think of that uses
> something clobber-able:
>
> for (int x=0; x < 1000; x++)
>asm("#stuff");
>
> This generates very simple and highly performant code:
>
> movl$1000, %eax
> .L2:
> #stuff
> subl$1, %eax
> jne .L2
>
> Using extended asm to simulate the clobberall gives:
>
> movl$1000, 44(%rsp)
> .L2:
> #stuff
> subl$1, 44(%rsp)
> jne .L2
>
> It allocates an extra 4 bytes, and changed everything to memory accesses
> instead of using a register.
Can you show us your code? I get
xx:
movl$1000, %eax
.L2:
#stuff
subl$1, %eax
jne .L2
rep; ret
for
void xx() {
for (int x=0; x < 1000; x++)
asm volatile("#stuff" : : : "memory");
}
What you're describing looks like a bug: x doesn't have its address
taken.
Andrew.
Re: basic asm and memory clobbers
On 11/20/2015 2:17 AM, Andrew Haley wrote:
On 20/11/15 01:23, David Wohlferd wrote:
I tried to picture the most basic case I can think of that uses
something clobber-able:
for (int x=0; x < 1000; x++)
asm("#stuff");
This generates very simple and highly performant code:
movl$1000, %eax
.L2:
#stuff
subl$1, %eax
jne .L2
Using extended asm to simulate the clobberall gives:
movl$1000, 44(%rsp)
.L2:
#stuff
subl$1, 44(%rsp)
jne .L2
It allocates an extra 4 bytes, and changed everything to memory accesses
instead of using a register.
Can you show us your code? I get
xx:
movl$1000, %eax
.L2:
#stuff
subl$1, %eax
jne .L2
rep; ret
for
void xx() {
for (int x=0; x < 1000; x++)
asm volatile("#stuff" : : : "memory");
}
What you're describing looks like a bug: x doesn't have its address
taken.
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such being the case, "memory" is not sufficient:
#define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11",
"r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"
int main()
{
for (int x=0; x < 1000; x++)
asm("#":::CLOBBERALL);
}
dw
Re: basic asm and memory clobbers
On 11/19/2015 7:14 PM, Segher Boessenkool wrote:
On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote:
For that reason, I'd like to propose adding 2 new clobbers to extended
asm as part of this work:
"clobberall" - This gives extended the same semantics as whatever the
new basic asm will be using.
"clobbernone" - This gives the same semantics as the current basic asm.
I don't think this is necessary or useful. They are also awful names:
"clobberall" cannot clobber everything (think of the stack pointer),
I'm not emotionally attached to the names. But providing the same
capability to extended that we are proposing for basic doesn't seem so
odd. Shouldn't extended be able to do (at least) everything basic does?
My first thought is that it allows people to incrementally start
migrating from (new) basic to extended (something I think we should
encourage). Or use it as a debug tool to see if the failure you are
experiencing from your asm is due to a missing clobber. Since the
capability will already be implemented for basic, providing a way to
access it from extended seems trivial (if we can agree on a name).
As you say, clobbering the stack pointer presents special challenges
(although gcc has a specific way of dealing with stack register
clobbers, see 52813). This is why I described the feature as having
"the same semantics as whatever the new basic asm will be using."
and "clobbernone" does clobber some (those clobbered by any asm),
Seems like a quibble. Those other things (I assume you mean things like
pipelining?) most users aren't even aware of (or they wouldn't be so
eager to use inline asm in the first place). Would it be more palatable
if we called it "v5BasicAsmMode"? "ClobberMin"?
Clobbernone may seem redundant, since not specifying any clobbers should
do the same thing. But actually it doesn't, at least on i386. At
present, there is no way for extended asm to not clobber "cc". I don't
know if other platforms have similar issues.
Some do. The purpose is to stay compatible with asm written for older
versions of the compiler.
Backward compatibility is important. I understand that due to the cc0
change in x86, existing code may have broken without always clobbering
cc. This was seen as the safest way to ensure that didn't happen.
However no solution was/is available for people who correctly knew
whether their asm clobbers the flags.
Mostly I'm ok with that. All the ways that I can think of to try to
re-allow people to start using the cc clobber are just not worth it. I
simply can't believe there are many cases where there's going to be a
benefit.
But as I said: backward compatibility is important. Providing a way for
people who need/want the old basic asm semantics seems useful. And I
don't believe we can (quite) do that without clobbernone.
When basic asm changes, I expect that having a way to "just do what it
used to do" is going to be useful for some people.
24414 says the documented behaviour hasn't been true for at least
fourteen years. It isn't likely anyone is relying on that behaviour.
?
To my knowledge, there was no documentation of any sort about what basic
asm clobbered until I added it. But what people are (presumably)
relying on is that whatever it did in the last version, it's going to
continue to do that in the next. And albeit with good intentions, we
are planning on changing that.
but perhaps the solution here is to just say that it doesn't
clobber flags (currently the most common case?), and update the docs if
and when people complain? Yes, that's bad, but saying nothing at all
isn't any better. And we know it's true for at least 2 platforms.
Saying nothing at all at least is *correct*.
We don't know that saying "it doesn't clobber flags" is wrong either.
All we know is that jeff said "I suspect this isn't consistent across
targets."
But that's neither here nor there. The real question is, if we can't
say that, what can we say?
- If 24414 is going in v6, then we can doc that it does the clobber and
be vague about the old behavior.
- If 24414 isn't going in v6, then what? I suppose we can say that it
can vary by platform. We could even provide your sample code as a means
for people to discover their platform's behavior.
It isn't necessary for users to know what registers the compiler
considers to be clobbered by an asm, unless they actually clobber
something in the assembler code themselves.
I'm not sure I follow.
If someone has code that uses a register, currently they must restore
the value before exiting the asm or risk disaster. So they might write
asm("push eax ; DoSomethingWith eax ; pop eax"). However if you know
that the compiler is going to clobber eax, then the push/pop is just a
waste of cycles and memory.
To write efficient code, it seems like you do need to know what the
compiler clobbers.
They can write extended asm in that case.
I agree that
Re: basic asm and memory clobbers
On 20/11/15 10:37, David Wohlferd wrote: > The intent for 24414 is to change basic asm such that it will become > (quoting jeff) "an opaque blob that read/write/clobber any register or > memory location." Such being the case, "memory" is not sufficient: > > #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", > "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory" Hmm. I would not be at all surprised to see this cause reload failures. You certainly shouldn't clobber the frame pointer on any machine which needs one. Andrew.
Re: basic asm and memory clobbers
On 11/20/2015 3:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such being the case, "memory" is not sufficient:
#define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11",
"r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"
Hmm. I would not be at all surprised to see this cause reload
failures. You certainly shouldn't clobber the frame pointer on
any machine which needs one.
If I don't clobber ebp, gcc just uses it:
movl$1000, %ebp
.L2:
#
subl$1, %ebp
jne .L2
The original purpose of this code was to attempt to show that this kind
of "clobbering everything" behavior (the proposed new behavior for basic
asm) could have non-trivial impact on existing routines. While I've been
told that changing the existing "clobber nothing" approach to this kind
of "clobber everything" is "less intrusive than you might think," I'm
struggling to believe it. It seems to me that one asm("nop") thrown
into a driver routine to fix a timing problem could end up making a real
mess.
But actually we're kind of past that. When Jeff, Segher, (other) Andrew
and Richard all say "this is how it's going to work," it's time for me
to set aside my reservations and move on.
So now I'm just trying my best to make sure that if it *is* an issue,
people have a viable solution readily available. And to make sure it's
all correctly doc'ed (which is what started this whole mess).
dw
GCC 5.3 Status Report (2015-11-20)
Status == We plan to do a GCC 5.3 release candidate at the end of next week followed by the actual release a week after that. So now is the time to look at your regression bugs in bugzilla and do some backporting for things already fixed on trunk. Quality Data Priority # Change from last report --- --- P10 P2 121+ 30 P3 20- 8 P4 87+ 2 P5 32+ 2 --- --- Total P1-P3 141+ 22 Total 260+ 24 Previous Report === https://gcc.gnu.org/ml/gcc/2015-07/msg00197.html
Re: basic asm and memory clobbers
On 11/20/2015 01:38 PM, David Wohlferd wrote:
On 11/20/2015 3:14 AM, Andrew Haley wrote:
On 20/11/15 10:37, David Wohlferd wrote:
The intent for 24414 is to change basic asm such that it will become
(quoting jeff) "an opaque blob that read/write/clobber any register or
memory location." Such being the case, "memory" is not sufficient:
#define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11",
"r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory"
Hmm. I would not be at all surprised to see this cause reload
failures. You certainly shouldn't clobber the frame pointer on
any machine which needs one.
If I don't clobber ebp, gcc just uses it:
movl$1000, %ebp
.L2:
#
subl$1, %ebp
jne .L2
I believe you'd have to have magic in there to conditionally clobber the
register if it isn't being used as a frame pointer.
That said...
The original purpose of this code was to attempt to show that this kind of
"clobbering everything" behavior (the proposed new behavior for basic asm)
could have non-trivial impact on existing routines. While I've been told that
changing the existing "clobber nothing" approach to this kind of "clobber
everything" is "less intrusive than you might think," I'm struggling to believe
it. It seems to me that one asm("nop") thrown into a driver routine to fix a
timing problem could end up making a real mess.
But actually we're kind of past that. When Jeff, Segher, (other) Andrew and
Richard all say "this is how it's going to work," it's time for me to set aside
my reservations and move on.
So now I'm just trying my best to make sure that if it *is* an issue, people
have a viable solution readily available. And to make sure it's all correctly
doc'ed (which is what started this whole mess).
I'd be perfectly happy to deprecate and later completely remove basic asm
within functions.
Because IMO it's essentially useless. It has no inputs, no outputs, and no way
to tell the compiler what machine state has been changed. We can say that "it
clobbers everything", but that's not actually useful, and quite difficult as
you're finding out.
It seems to me that it would be better to remove the feature, forcing what must
be an extremely small number of users to audit and update to extended asm.
r~
Broken Link
Hey, I wanted to reach out and let you know about this link which isn’t working - http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/, I found it on this page - http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html. You’re link includes this text - "Objective-C Language Description", if that helps you find it. We’ve put together a guide to Objective C, which includes a brief history, some useful online resources and books, and an introduction to Swift, the successor to Objective C > http://wiht.link/objectivecguide. I thought that it might make a suitable alternative to point your site visitors to. All the best, Melissa
Re: GCC 5.3 Status Report (2015-11-20)
On Fri, Nov 20, 2015 at 7:53 AM, Richard Biener wrote: > > Status > == > > We plan to do a GCC 5.3 release candidate at the end of next week > followed by the actual release a week after that. > > So now is the time to look at your regression bugs in bugzilla and > do some backporting for things already fixed on trunk. I'm still waiting for approval of the libtool change to support AIX TLS symbols (PR 68192). There has been no response on Libtool patches mailing list. I again request permission to apply the patches to GCC trunk and 5-branch. Thanks, David
Re: Broken Link
On 20 November 2015 at 13:12, wrote: > Hey, > > I wanted to reach out and let you know about this link which isn’t working - > http://developer.apple.com/documentation/Cocoa/Conceptual/ObjectiveC/, I > found it on this page - > http://gd.tuwien.ac.at/.vhost/www.gnu.org/software/gcc/readings.html. You’re > link includes this text - "Objective-C Language Description", if that helps > you find it. That page is not hosted by the GCC project. The official version of the page has a working link: http://www.gnu.org/software/gcc/readings.html
Re: basic asm and memory clobbers
On Fri, Nov 20, 2015 at 02:45:05AM -0800, David Wohlferd wrote: > On 11/19/2015 7:14 PM, Segher Boessenkool wrote: > >On Thu, Nov 19, 2015 at 05:23:55PM -0800, David Wohlferd wrote: > >>For that reason, I'd like to propose adding 2 new clobbers to extended > >>asm as part of this work: > >> > >>"clobberall" - This gives extended the same semantics as whatever the > >>new basic asm will be using. > >>"clobbernone" - This gives the same semantics as the current basic asm. > >I don't think this is necessary or useful. They are also awful names: > >"clobberall" cannot clobber everything (think of the stack pointer), > > I'm not emotionally attached to the names. Names should be succinct, clear, and give a good indication of what the thing named does. If it is hard to make a good name it is likely that the interface isn't so well designed. > But providing the same > capability to extended that we are proposing for basic doesn't seem so > odd. Shouldn't extended be able to do (at least) everything basic does? But that would be logical! Can't have that. Heh. > As you say, clobbering the stack pointer presents special challenges > (although gcc has a specific way of dealing with stack register > clobbers, see 52813). Yeah. Actually, basic asm is handled specially in many places, too. > >and "clobbernone" does clobber some (those clobbered by any asm), > > Seems like a quibble. Those other things (I assume you mean things like > pipelining?) most users aren't even aware of (or they wouldn't be so > eager to use inline asm in the first place). Would it be more palatable > if we called it "v5BasicAsmMode"? "ClobberMin"? I meant things like x86 "cc". > >>Clobbernone may seem redundant, since not specifying any clobbers should > >>do the same thing. But actually it doesn't, at least on i386. At > >>present, there is no way for extended asm to not clobber "cc". I don't > >>know if other platforms have similar issues. > >Some do. The purpose is to stay compatible with asm written for older > >versions of the compiler. > > Backward compatibility is important. I understand that due to the cc0 > change in x86, existing code may have broken without always clobbering > cc. This was seen as the safest way to ensure that didn't happen. > However no solution was/is available for people who correctly knew > whether their asm clobbers the flags. > > Mostly I'm ok with that. All the ways that I can think of to try to > re-allow people to start using the cc clobber are just not worth it. I > simply can't believe there are many cases where there's going to be a > benefit. Exactly. The asm still can be moved "over" other uses of CC, it does not limit transformations much at all. > But as I said: backward compatibility is important. Providing a way for > people who need/want the old basic asm semantics seems useful. And I > don't believe we can (quite) do that without clobbernone. > > >>When basic asm changes, I expect that having a way to "just do what it > >>used to do" is going to be useful for some people. > >24414 says the documented behaviour hasn't been true for at least > >fourteen years. It isn't likely anyone is relying on that behaviour. > > ? 24414 says these things haven't worked since at least 2.95.3, which is fourteen years old now. > >It isn't necessary for users to know what registers the compiler > >considers to be clobbered by an asm, unless they actually clobber > >something in the assembler code themselves. > > I'm not sure I follow. If the assembler code does not clobber some register, but GCC treats it as if it does, things will work correctly. Segher
Re: basic asm and memory clobbers
On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
> I'd be perfectly happy to deprecate and later completely remove basic asm
> within functions.
>
> Because IMO it's essentially useless. It has no inputs, no outputs, and no
> way to tell the compiler what machine state has been changed. We can say
> that "it clobbers everything", but that's not actually useful, and quite
> difficult as you're finding out.
>
> It seems to me that it would be better to remove the feature, forcing what
> must be an extremely small number of users to audit and update to extended
> asm.
Should asm("bla"); then be an extended asm with no input, no outputs,
no (non-automatic) clobbers? That would be the most straightforward and
logical semantics, but will it break user code?
Segher
Re: basic asm and memory clobbers
On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
I'd be perfectly happy to deprecate and later completely remove basic asm
within functions.
Because IMO it's essentially useless. It has no inputs, no outputs, and no
way to tell the compiler what machine state has been changed. We can say
that "it clobbers everything", but that's not actually useful, and quite
difficult as you're finding out.
It seems to me that it would be better to remove the feature, forcing what
must be an extremely small number of users to audit and update to extended
asm.
Should asm("bla"); then be an extended asm with no input, no outputs,
no (non-automatic) clobbers? That would be the most straightforward and
logical semantics, but will it break user code?
I'm suggesting that we don't accept that at all inside a function. One must
audit the source and make a conscious decision to write asm("bla" : ); instead.
Accepting basic asm outside of a function is perfectly ok, since that's just a
mechanism by which one can inject complete assembly routines into a C
translation unit.
r~
Graphite header order
Sebastian,
I have tried to build GCC with Graphite and ISL on AIX and encountered
two problems:
(1) isl/ctx.h
typedef enum {
isl_stat_error = -1,
isl_stat_ok = 0,
} isl_stat;
GCC complains about the comma in "isl_stat_ok = 0,". This seems like
a general bug that should appear on all targets.
(2) All of the graphite*.c files include ISL headers first. This
order is not supported by GCC development and creates conflicts for
types and definitions provided / overridden by GCC headers, especially
system.h and its dependent headers like hwint.h.
I presume that ISL headers are included first is they use calloc() and
strdup(), which are poisoned by GCC in system.h.
I am uncertain of the exact header dependencies, but the primary
dependency seems to be that the ISL headers must be included before
graphite-poly.h. The identifier poisoning problem needs to be
addressed by not poisoning the identifiers for files that include ISL
headers. The Graphite files need some sort of a macro like
#define IN_GRAPHITE
or
#define IN_ISL
and system.h must not poison the identifiers when that macro is present.
I am going to try with a hack of bracketing system.h with #undef
IN_GCC / #define IN_GCC in the graphite files.
Thanks, David
Re: basic asm and memory clobbers
On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> On 11/20/2015 04:20 PM, Segher Boessenkool wrote:
> >On Fri, Nov 20, 2015 at 02:05:01PM +0100, Richard Henderson wrote:
> >>I'd be perfectly happy to deprecate and later completely remove basic asm
> >>within functions.
> >>
> >>Because IMO it's essentially useless. It has no inputs, no outputs, and no
> >>way to tell the compiler what machine state has been changed. We can say
> >>that "it clobbers everything", but that's not actually useful, and quite
> >>difficult as you're finding out.
> >>
> >>It seems to me that it would be better to remove the feature, forcing what
> >>must be an extremely small number of users to audit and update to extended
> >>asm.
> >
> >Should asm("bla"); then be an extended asm with no input, no outputs,
> >no (non-automatic) clobbers? That would be the most straightforward and
> >logical semantics, but will it break user code?
>
> I'm suggesting that we don't accept that at all inside a function. One must
> audit the source and make a conscious decision to write asm("bla" : );
> instead.
>
> Accepting basic asm outside of a function is perfectly ok, since that's just
> a mechanism by which one can inject complete assembly routines into a C
> translation unit.
Isn't that going to break too much code though? I mean, e.g. including
libgcc...
Jakub
Re: basic asm and memory clobbers
On 11/20/2015 04:34 PM, Jakub Jelinek wrote: Isn't that going to break too much code though? I mean, e.g. including libgcc... I don't know. My suspicion is very little. But that's actually what I'd like to know before we start adjusting code in other ways wrt basic asms. r~
Re: Graphite header order
On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> Sebastian,
>
> I have tried to build GCC with Graphite and ISL on AIX and encountered
> two problems:
>
> (1) isl/ctx.h
>
> typedef enum {
> isl_stat_error = -1,
> isl_stat_ok = 0,
> } isl_stat;
>
> GCC complains about the comma in "isl_stat_ok = 0,". This seems like
> a general bug that should appear on all targets.
Sven, is there a way to fix this problem in ISL 0.15?
Thanks,
Sebastian
Re: basic asm and memory clobbers
On Fri, Nov 20, 2015 at 04:29:50PM +0100, Richard Henderson wrote:
> >>It seems to me that it would be better to remove the feature, forcing what
> >>must be an extremely small number of users to audit and update to extended
> >>asm.
> >
> >Should asm("bla"); then be an extended asm with no input, no outputs,
> >no (non-automatic) clobbers? That would be the most straightforward and
> >logical semantics, but will it break user code?
>
> I'm suggesting that we don't accept that at all inside a function. One
> must audit the source and make a conscious decision to write asm("bla" : );
> instead.
Ah, or excepting asm("bla") and treating it just like asm("bla" : ), but
giving a warning? That will get people to migrate at least.
> Accepting basic asm outside of a function is perfectly ok, since that's
> just a mechanism by which one can inject complete assembly routines into a
> C translation unit.
Of course. You cannot have extended asm outside of functions at all.
Segher
Re: Graphite header order
On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
> > Sebastian,
> >
> > I have tried to build GCC with Graphite and ISL on AIX and encountered
> > two problems:
> >
> > (1) isl/ctx.h
> >
> > typedef enum {
> > isl_stat_error = -1,
> > isl_stat_ok = 0,
> > } isl_stat;
> >
> > GCC complains about the comma in "isl_stat_ok = 0,". This seems like
> > a general bug that should appear on all targets.
>
> Sven, is there a way to fix this problem in ISL 0.15?
Which version of gcc complains about the comma and why does it complain?
AFAIU, the final comma is perfectly valid in C99.
skimo
Re: Graphite header order
Thanks David for reporting these problems. On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote: > (2) All of the graphite*.c files include ISL headers first. This > order is not supported by GCC development and creates conflicts for > types and definitions provided / overridden by GCC headers, especially > system.h and its dependent headers like hwint.h. > > I presume that ISL headers are included first is they use calloc() and > strdup(), which are poisoned by GCC in system.h. Yes, I do remember we had problems including the isl headers after system.h. > > I am uncertain of the exact header dependencies, but the primary > dependency seems to be that the ISL headers must be included before > graphite-poly.h. The identifier poisoning problem needs to be > addressed by not poisoning the identifiers for files that include ISL > headers. The Graphite files need some sort of a macro like > > #define IN_GRAPHITE > > or > > #define IN_ISL > > and system.h must not poison the identifiers when that macro is present. > > I am going to try with a hack of bracketing system.h with #undef > IN_GCC / #define IN_GCC in the graphite files. I don't understand why these symbols are poisoned in GCC. If there is a good reason to poison these functions, why would they be fine to be used in Graphite and ISL? Would it be possible to relax these constraints and remove the poisoning of these functions in GCC? Thanks, Sebastian
Re: Graphite header order
On Fri, Nov 20, 2015 at 10:23 AM, Sven Verdoolaege wrote:
> On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>> > Sebastian,
>> >
>> > I have tried to build GCC with Graphite and ISL on AIX and encountered
>> > two problems:
>> >
>> > (1) isl/ctx.h
>> >
>> > typedef enum {
>> > isl_stat_error = -1,
>> > isl_stat_ok = 0,
>> > } isl_stat;
>> >
>> > GCC complains about the comma in "isl_stat_ok = 0,". This seems like
>> > a general bug that should appear on all targets.
>>
>> Sven, is there a way to fix this problem in ISL 0.15?
>
> Which version of gcc complains about the comma and why does it complain?
> AFAIU, the final comma is perfectly valid in C99.
On my system, gcc is compiled by g++ -std=gnu++98, then bootstrap uses
-std=gnu++11.
Sebastian
Re: Graphite header order
On Fri, Nov 20, 2015 at 11:31 AM, Sebastian Pop wrote:
> On Fri, Nov 20, 2015 at 10:23 AM, Sven Verdoolaege
> wrote:
>> On Fri, Nov 20, 2015 at 10:14:47AM -0600, Sebastian Pop wrote:
>>> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote:
>>> > Sebastian,
>>> >
>>> > I have tried to build GCC with Graphite and ISL on AIX and encountered
>>> > two problems:
>>> >
>>> > (1) isl/ctx.h
>>> >
>>> > typedef enum {
>>> > isl_stat_error = -1,
>>> > isl_stat_ok = 0,
>>> > } isl_stat;
>>> >
>>> > GCC complains about the comma in "isl_stat_ok = 0,". This seems like
>>> > a general bug that should appear on all targets.
>>>
>>> Sven, is there a way to fix this problem in ISL 0.15?
>>
>> Which version of gcc complains about the comma and why does it complain?
>> AFAIU, the final comma is perfectly valid in C99.
>
> On my system, gcc is compiled by g++ -std=gnu++98, then bootstrap uses
> -std=gnu++11.
Sven,
It's a C++ warning that is treated as an error during the GCC build.
This presumably is a problem on all configurations of GCC.
In file included from
/gsa/yktgsa/home/e/d/edelsohn/install/include/isl/list.h:13:0,
from
/gsa/yktgsa/home/e/d/edelsohn/install/include/isl/aff_type.h:4,
from
/gsa/yktgsa/home/e/d/edelsohn/install/include/isl/local_space.h:4,
from
/gsa/yktgsa/home/e/d/edelsohn/install/include/isl/constraint.h:13,
from /nasfarm/edelsohn/src/src/gcc/graphite.c:36:
/gsa/yktgsa/home/e/d/edelsohn/install/include/isl/ctx.h:83:17:
warning: comma at end of enumerator list [-Wpedantic]
isl_stat_ok = 0,
^
Thanks, David
Re: basic asm and memory clobbers
On 11/20/2015 04:14 AM, Andrew Haley wrote: On 20/11/15 10:37, David Wohlferd wrote: The intent for 24414 is to change basic asm such that it will become (quoting jeff) "an opaque blob that read/write/clobber any register or memory location." Such being the case, "memory" is not sufficient: #define CLOBBERALL "eax", "ebx", "ecx", "edx", "r8", "r9", "r10", "r11", "r12", "r13", "r14", "r15", "edi", "esi", "ebp", "cc", "memory" Hmm. I would not be at all surprised to see this cause reload failures. You certainly shouldn't clobber the frame pointer on any machine which needs one. Right. It'll cause other issues as well. It's the only reason why I didn't change the code internally to stomp every hard register back in 1999. jeff
Re: Graphite header order
On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop wrote: > Thanks David for reporting these problems. > > On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote: >> (2) All of the graphite*.c files include ISL headers first. This >> order is not supported by GCC development and creates conflicts for >> types and definitions provided / overridden by GCC headers, especially >> system.h and its dependent headers like hwint.h. >> >> I presume that ISL headers are included first is they use calloc() and >> strdup(), which are poisoned by GCC in system.h. > > Yes, I do remember we had problems including the isl headers after system.h. > >> >> I am uncertain of the exact header dependencies, but the primary >> dependency seems to be that the ISL headers must be included before >> graphite-poly.h. The identifier poisoning problem needs to be >> addressed by not poisoning the identifiers for files that include ISL >> headers. The Graphite files need some sort of a macro like >> >> #define IN_GRAPHITE >> >> or >> >> #define IN_ISL >> >> and system.h must not poison the identifiers when that macro is present. >> >> I am going to try with a hack of bracketing system.h with #undef >> IN_GCC / #define IN_GCC in the graphite files. > > I don't understand why these symbols are poisoned in GCC. > If there is a good reason to poison these functions, why would they > be fine to be used in Graphite and ISL? > > Would it be possible to relax these constraints and remove the > poisoning of these functions in GCC? GCC should use xmalloc, xcalloc, xstrdup, etc. https://gcc.gnu.org/ml/gcc-patches/2001-03/msg00484.html We cannot change ISL, so the poisoning should be lifted for those files instead of including headers in the wrong order. GCC similarly removes the restrictions for Flex and Bison. - David
Re: Graphite header order
On Fri, Nov 20, 2015 at 10:43 AM, David Edelsohn wrote: > On Fri, Nov 20, 2015 at 11:28 AM, Sebastian Pop wrote: >> Thanks David for reporting these problems. >> >> On Fri, Nov 20, 2015 at 9:31 AM, David Edelsohn wrote: >>> (2) All of the graphite*.c files include ISL headers first. This >>> order is not supported by GCC development and creates conflicts for >>> types and definitions provided / overridden by GCC headers, especially >>> system.h and its dependent headers like hwint.h. >>> >>> I presume that ISL headers are included first is they use calloc() and >>> strdup(), which are poisoned by GCC in system.h. >> >> Yes, I do remember we had problems including the isl headers after system.h. >> >>> >>> I am uncertain of the exact header dependencies, but the primary >>> dependency seems to be that the ISL headers must be included before >>> graphite-poly.h. The identifier poisoning problem needs to be >>> addressed by not poisoning the identifiers for files that include ISL >>> headers. The Graphite files need some sort of a macro like >>> >>> #define IN_GRAPHITE >>> >>> or >>> >>> #define IN_ISL >>> >>> and system.h must not poison the identifiers when that macro is present. >>> >>> I am going to try with a hack of bracketing system.h with #undef >>> IN_GCC / #define IN_GCC in the graphite files. >> >> I don't understand why these symbols are poisoned in GCC. >> If there is a good reason to poison these functions, why would they >> be fine to be used in Graphite and ISL? >> >> Would it be possible to relax these constraints and remove the >> poisoning of these functions in GCC? > > GCC should use xmalloc, xcalloc, xstrdup, etc. > > https://gcc.gnu.org/ml/gcc-patches/2001-03/msg00484.html > > We cannot change ISL, so the poisoning should be lifted for those > files instead of including headers in the wrong order. Thanks for the explanation, that makes sense now.
Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
On Tue, 17 Nov 2015, Joseph Myers wrote: > > Any or all of these options may have effects beyond propagating the IEEE > > Std 754 compliance mode down to the assembler and the linker. In > > particular `-mieee=strict' is expected to guarantee code generated to > > fully comply to IEEE Std 754 rather than only as far as NaN representation > > is concerned. > > "guarantee" seems rather strong given the various known issues with (lack > of) Annex F support in GCC. Well, but aren't these current implementation shortcomings (i.e. bugs) rather than a design principle? I can weaken the language here, but if the former is the case, then I think we don't need to factor in the existence of bugs into an interface specification. > Do you have any actual configuration in mind it would affect, > MIPS-specific or otherwise? For non-architecture-specific things, -std= > options for C standards conformance are meant to enable whatever options > are required (e.g. they disable the default -ffp-contract=fast), without > affecting things not required by the standards by default (so they don't > enable -frounding-math or -fsignaling-nans, for example). The target audience for the `-mieee=strict' option is in my idea a non-technical user, say a physicist, who does not necessarily know or is fluent with the guts of computer hardware and who has the need to build and reliably run their software which uses IEEE Std 754 arithmetic. Rather than giving such a user necessarily lengthy explanations as to the complexity of the situation I'd prefer to give them this single option to guarantee (modulo bugs, as noted above) that a piece of software built with this option will either produce correct (as in "standard-compliant") results or refuse to run. There is also a corresponding `--with-ieee=strict' configure-time option for users who want to build their own compiler system which guarantees such compliance by default. I think the `-std=' options are a little bit too broad in that they control more than just the IEEE Std 754 aspect of standards compliance. Of course the setting of `-mieee=' may in fact be a one-way dependency of `-std=', up to a further override. I haven't implemented such a dependency in my prototype, however I think it might be a good idea to have it. What I have implemented is a dependency between `-mieee=' and the internal option to control the compliance mode for NaN encodings. That has encountered an unexpected complication though which I was not able to resolve without turning the option handling machinery upside down, and I found that code really hard to follow. So I decided to defer it as not the main scope of the matter and proceed with the rest of the feature. Once the option handling has been sorted out, a similar dependency can be introduced between `-std=' and `-mieee='. I'll post the details of the option handling issue with the GCC patches. Does this answer address your concerns? Maciej
Re: basic asm and memory clobbers
On 11/20/2015 06:05 AM, Richard Henderson wrote: I'd be perfectly happy to deprecate and later completely remove basic asm within functions. Because IMO it's essentially useless. It has no inputs, no outputs, and no way to tell the compiler what machine state has been changed. We can say that "it clobbers everything", but that's not actually useful, and quite difficult as you're finding out. And even more difficult to document exactly what happens, largely because the implementation in GCC isn't consistent across passes and there's differences in behaviour that are dependent on the target implementation as well. Unfortunately there's not a single place where we can ensure consistent behaviour, so each pass has had to handle ASMs independently, and I'm pretty sure they all get it wrong to varying degrees. It seems to me that it would be better to remove the feature, forcing what must be an extremely small number of users to audit and update to extended asm. That might be a little drastic. Though if we want to go this direction, the first step is to deprecate for a major release cycle. It would be interesting to see how much stuff would complain/break. jeff
Re: [RFC] MIPS ABI Extension for IEEE Std 754 Non-Compliant Interlinking
On Fri, 20 Nov 2015, Maciej W. Rozycki wrote: > The target audience for the `-mieee=strict' option is in my idea a > non-technical user, say a physicist, who does not necessarily know or is > fluent with the guts of computer hardware and who has the need to build > and reliably run their software which uses IEEE Std 754 arithmetic. > Rather than giving such a user necessarily lengthy explanations as to the > complexity of the situation I'd prefer to give them this single option to > guarantee (modulo bugs, as noted above) that a piece of software built > with this option will either produce correct (as in "standard-compliant") > results or refuse to run. This does not make any sense. The correspondence between IEEE 754 operations and source code in C or other languages is extremely complicated. If the user thinks of C as some form of portable assembler for IEEE 754 operations, that is not something effectively supportable. Can we assume that if the user depends on rounding modes, they will use the FENV_ACCESS pragma (not implemented, of course) or -frounding-math? Can we assume that their dependence on the absence of contraction of expressions is in accordance with ISO C rules (again, FP_CONTRACT isn't implemented but -ffp-contract=off is)? Can we assume that they don't depend on signaling NaNs? Can we assume they don't depend on trap handlers that count the number of times a given exception occurs, since that is explicitly unsupported by ISO C? An option like that has to be defined in terms of existing C bindings for IEEE 754, not in terms of supporting users who don't know what they are doing and are unfamiliar with how C source code constructs are mapped to IEEE 754 operations and what features the C standard allows non-default pragmas or options to be required for. > Does this answer address your concerns? No, the option concept as described seems too irremediably vague. -- Joseph S. Myers jos...@codesourcery.com
Re: basic asm and memory clobbers
> On Nov 20, 2015, at 1:24 PM, Jeff Law wrote: > > On 11/20/2015 06:05 AM, Richard Henderson wrote: > >> ... >> It seems to me that it would be better to remove the feature, forcing >> what must be an extremely small number of users to audit and update to >> extended asm. > That might be a little drastic. Though if we want to go this direction, the > first step is to deprecate for a major release cycle. It would be > interesting to see how much stuff would complain/break. I would expect: a lot. I've seen plenty of people writing asm statements (in small quantities, admittedly) who have never heard of extended asm. paul
Re: basic asm and memory clobbers
On 11/20/2015 07:56 AM, Segher Boessenkool wrote: When basic asm changes, I expect that having a way to "just do what it used to do" is going to be useful for some people. 24414 says the documented behaviour hasn't been true for at least fourteen years. It isn't likely anyone is relying on that behaviour. ? 24414 says these things haven't worked since at least 2.95.3, which is fourteen years old now. That's not a good reason to leave things as-is. The problem is that optimizers continue to improve. So an old-style asm that worked in the past may mysteriously start failing as folks move forward with their compiler -- because we haven't properly implemented the right semantics of old-style asms, which is in part because certain aspects were never documented properly and partly because of reload issues :( If we keep old style asms, then we need to properly document what their behaviour is supposed to be, and continue to fix bugs where we do not honor that behaviour. The latter is somewhat painful because we don't have a single place where we can audit & fix any semantic problems. It's scattered in various optimizers throughout GCC. And I suspect most are getting it wrong in one way or another. Jeff
Re: basic asm and memory clobbers
> On Nov 20, 2015, at 3:01 PM, Jeff Law wrote: > > On 11/20/2015 07:56 AM, Segher Boessenkool wrote: > > When basic asm changes, I expect that having a way to "just do what it > used to do" is going to be useful for some people. 24414 says the documented behaviour hasn't been true for at least fourteen years. It isn't likely anyone is relying on that behaviour. >>> >>> ? >> >> 24414 says these things haven't worked since at least 2.95.3, which is >> fourteen years old now. > That's not a good reason to leave things as-is. > > The problem is that optimizers continue to improve. So an old-style asm > that worked in the past may mysteriously start failing as folks move forward > with their compiler -- because we haven't properly implemented the right > semantics of old-style asms, which is in part because certain aspects were > never documented properly and partly because of reload issues :( > > If we keep old style asms, then we need to properly document what their > behaviour is supposed to be, and continue to fix bugs where we do not honor > that behaviour. Yes. I know I've run into cases before where certain documented properties were not honored. I can't find the details right now; I think it was "old style asm always behaves as if marked 'volatile'. " paul
Re: basic asm and memory clobbers
On 11/20/2015 8:14 AM, Richard Henderson wrote: On 11/20/2015 04:34 PM, Jakub Jelinek wrote: Isn't that going to break too much code though? I mean, e.g. including libgcc... I don't know. My suspicion is very little. But that's actually what I'd like to know before we start adjusting code in other ways wrt basic asms. I can provide a little data here. In an effort to gain some perspective, I've been looking at inline asm usage in the linux kernel (4.3). Clearly this isn't "typical usage," but it is probably one of the biggest users of inline asm, and likely has the best justifications for doing so (being an OS and all). There are ~5,711 instances of inline asm in use. Of those, ~4,833 are extended and ~878 are basic. I don't have any numbers about how many are top level vs in function, but let me see what I can do. A quick look at libgcc shows that there are 109 extended and 45 basic asm statements. I'll see how many end up being top-level, but it looks like most of them. dw
