On Mon, Nov 19, 2018 at 12:59:29PM +, Michael Matz wrote:
> Hi,
>
> On Fri, 16 Nov 2018, Segher Boessenkool wrote:
>
> > > I.e. like volatile they can arbitrarily change their value. I don't
> > > know if other peoples mind model is similar, but it certainly is the
> > > model that is impl
Hi,
On Fri, 16 Nov 2018, Segher Boessenkool wrote:
> > I.e. like volatile they can arbitrarily change their value. I don't
> > know if other peoples mind model is similar, but it certainly is the
> > model that is implemented in the GIMPLE pipeline (and if memory serves
> > well of the RTL pi
Hi!
On Thu, Nov 15, 2018 at 03:54:03PM +, Michael Matz wrote:
> On Wed, 14 Nov 2018, Alexander Monakov wrote:
> > On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> > > Yeah, using local register vars to access global registers only works
> > > by accident. It does work currently though, and pe
Hi,
On Fri, 16 Nov 2018, Alexander Monakov wrote:
> > Not really, it ignores the fact that 'a' can change at any time, which
> > is what happens.
>
> Are you saying that local register variables, in your model, are
> essentially unfit for passing operands to inline asm on specific
> registers
On Fri, 16 Nov 2018, Michael Matz wrote:
> > This follows both your model
>
> Not really, it ignores the fact that 'a' can change at any time, which is
> what happens.
Are you saying that local register variables, in your model, are essentially
unfit for passing operands to inline asm on specifi
Hi,
On Thu, 15 Nov 2018, Alexander Monakov wrote:
> Reading the documentation certainly does not make that impression to me.
> In any case, can you elaborate a bit further please:
>
> 1. Regarding the comparison to 'volatile' qualifier. Suppose you have an
> automatic variable 'int v;' in a co
On 11/14/2018 02:39 AM, Alexander Monakov wrote:
On Tue, 13 Nov 2018, Martin Sebor wrote:
In PR 88000 the reporter expects to be able to use an explicit
register local variable in a context where it isn't supported
i.e., for something other than an input or output of an asm
statement: namely to
On 11/14/2018 02:47 AM, Jakub Jelinek wrote:
On Tue, Nov 13, 2018 at 09:11:41PM -0700, Martin Sebor wrote:
--- gcc/c-family/c-warn.c (revision 266086)
+++ gcc/c-family/c-warn.c (working copy)
@@ -2609,3 +2609,39 @@ warn_for_multistatement_macros (location_t body_lo
inform (guard
On Thu, 15 Nov 2018, Michael Matz wrote:
> I disagree that there's something to fix. My mental model for local reg
> vars has always been that such vars are actually an alias for that
> register, not comparable to normal automatic variables (so, much like
> global reg vars, except that they don
Hi,
On Wed, 14 Nov 2018, Alexander Monakov wrote:
> On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> > Yeah, using local register vars to access global registers only works
> > by accident. It does work currently though, and people apparently use
> > it, so we shouldn't break it :-/
>
> In the
On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> Yeah, using local register vars to access global registers only works
> by accident. It does work currently though, and people apparently use
> it, so we shouldn't break it :-/
In the proposed approach (copying from/to pseudos just before/after the
On Wed, Nov 14, 2018 at 06:50:38PM +0300, Alexander Monakov wrote:
> On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> > > I think with "=g" rather than "+g" this example is ok.
> >
> > No, it needs the register var as an input. That is the whole *point*.
>
> Hm. I think I see what you meant, but
On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> > I think with "=g" rather than "+g" this example is ok.
>
> No, it needs the register var as an input. That is the whole *point*.
Hm. I think I see what you meant, but "+g" is not correct either: the
asm, by intent, depends *on the current value
On Wed, Nov 14, 2018 at 03:33:43PM +0300, Alexander Monakov wrote:
> On Wed, 14 Nov 2018, Jakub Jelinek wrote:
>
> > On Wed, Nov 14, 2018 at 06:22:51AM -0600, Segher Boessenkool wrote:
> > > Btw, if you just add
> > >
> > > void *
> > > retsp (void)
> > > {
> > > register void *sp __asm ("sp");
On Wed, Nov 14, 2018 at 01:27:26PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 14, 2018 at 06:22:51AM -0600, Segher Boessenkool wrote:
> > Btw, if you just add
> >
> > void *
> > retsp (void)
> > {
> > register void *sp __asm ("sp");
> > asm ("" : "+g" (sp)); // <-- this line
> > return sp;
>
On Wed, 14 Nov 2018, Jakub Jelinek wrote:
> On Wed, Nov 14, 2018 at 06:22:51AM -0600, Segher Boessenkool wrote:
> > Btw, if you just add
> >
> > void *
> > retsp (void)
> > {
> > register void *sp __asm ("sp");
> > asm ("" : "+g" (sp)); // <-- this line
> > return sp;
> > }
> >
> > everyt
On Wed, Nov 14, 2018 at 06:22:51AM -0600, Segher Boessenkool wrote:
> Btw, if you just add
>
> void *
> retsp (void)
> {
> register void *sp __asm ("sp");
> asm ("" : "+g" (sp)); // <-- this line
> return sp;
> }
>
> everything works fine.
Even in what you are proposing, i.e. handle the v
Btw, if you just add
void *
retsp (void)
{
register void *sp __asm ("sp");
asm ("" : "+g" (sp)); // <-- this line
return sp;
}
everything works fine.
Segher
On Wed, Nov 14, 2018 at 06:11:37AM -0600, Segher Boessenkool wrote:
> It doesn't "break" anything because it currently isn't guaranteed to work
> either. There is __builtin_frame_address(0) for this of course (well,
> almost the same semantics, and it is actually well-defined and actually
> works)
On Wed, Nov 14, 2018 at 01:00:43PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 14, 2018 at 05:50:39AM -0600, Segher Boessenkool wrote:
> > > You mean for all local hard register variables living across function
> > > calls
> > > save them into temporary and restore them around the calls?
> > > One i
On Wed, Nov 14, 2018 at 05:50:39AM -0600, Segher Boessenkool wrote:
> > You mean for all local hard register variables living across function calls
> > save them into temporary and restore them around the calls?
> > One issue is that those variables aren't in SSA form, so liveness analysis
> > is h
On Wed, Nov 14, 2018 at 12:40:01PM +0100, Jakub Jelinek wrote:
> On Wed, Nov 14, 2018 at 05:35:06AM -0600, Segher Boessenkool wrote:
> > On Wed, Nov 14, 2018 at 10:47:57AM +0100, Jakub Jelinek wrote:
> > > This makes no sense to me. There is nothing unsupported in passing
> > > a local hard regist
On Wed, Nov 14, 2018 at 05:35:06AM -0600, Segher Boessenkool wrote:
> On Wed, Nov 14, 2018 at 10:47:57AM +0100, Jakub Jelinek wrote:
> > This makes no sense to me. There is nothing unsupported in passing
> > a local hard register variable to a function, that is well defined,
> > and as your testca
On Wed, Nov 14, 2018 at 10:47:57AM +0100, Jakub Jelinek wrote:
> This makes no sense to me. There is nothing unsupported in passing
> a local hard register variable to a function, that is well defined,
> and as your testcase changes show, you broke quite some completely valid
> testcases with that
On Tue, Nov 13, 2018 at 09:11:41PM -0700, Martin Sebor wrote:
> --- gcc/c-family/c-warn.c (revision 266086)
> +++ gcc/c-family/c-warn.c (working copy)
> @@ -2609,3 +2609,39 @@ warn_for_multistatement_macros (location_t body_lo
> inform (guard_loc, "some parts of macro expansion are not
On Tue, 13 Nov 2018, Martin Sebor wrote:
> In PR 88000 the reporter expects to be able to use an explicit
> register local variable in a context where it isn't supported
> i.e., for something other than an input or output of an asm
> statement: namely to pass it as argument to a user-defined
> fun
In PR 88000 the reporter expects to be able to use an explicit
register local variable in a context where it isn't supported
i.e., for something other than an input or output of an asm
statement: namely to pass it as argument to a user-defined
function. GCC emits unexpected object code in this ca
27 matches
Mail list logo
