[RFC] Eliminate NESTED_ATTR_FUNC

[RFC] Eliminate NESTED_ATTR_FUNC

[Vladimir 'phcoder' Serbinenko]

Hello. NESTED_ATTR_FUNC was introduced 6 years ago to workaround a bug
in compiler. Now it creates only problems. In particular if they are
used wrong it creates a bug of argument passing. Such bugs are
difficult to find because it usually results in strange behaviour and
in grub-emu NESTED_FUNC_ATTR is exteneded to an empty string so gdb
and valgrind can't detect any error. Should we perhaps remove it
coupled with adding a requirement for at least gcc 4.2? Can I run
s/NESTED_FUNC_ATTR//g; on entire codebase and remove corresponding
entry in configure.ac?

-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Bean]

On Tue, Sep 1, 2009 at 9:42 PM, Vladimir 'phcoder'
Serbinenko<phcoder@gmail.com> wrote:
> Hello. NESTED_ATTR_FUNC was introduced 6 years ago to workaround a bug
> in compiler. Now it creates only problems. In particular if they are
> used wrong it creates a bug of argument passing. Such bugs are
> difficult to find because it usually results in strange behaviour and
> in grub-emu NESTED_FUNC_ATTR is exteneded to an empty string so gdb
> and valgrind can't detect any error. Should we perhaps remove it
> coupled with adding a requirement for at least gcc 4.2? Can I run
> s/NESTED_FUNC_ATTR//g; on entire codebase and remove corresponding
> entry in configure.ac?

Hi,

I make an assembly dump of the code generated by gcc-4.2. Apparently,
the "FIX" is achieved by ignoring the regparm attribute at all.
__attribute__ ((__regparm__ (3))) doesn't have any effect any more, it
always pass the parameters on the stack. This defeats the original
purpose of -mregparm=3, which passes parameters using register and
therefore reduce module size. In fact, if we are going to use stack,
we could just remove -mregparm=3 option, this works for all version of
gcc.

IMO, if we are to tackle the NESTED_FUNC_ATTR issue, we should do it
properly by removing nested function, this also has other advantages,
like allowing to run tools on systems like OSX that doesn't allow to
execute code in stack by default.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Robert Millan]

On Tue, Sep 01, 2009 at 11:43:10PM +0800, Bean wrote:
> On Tue, Sep 1, 2009 at 9:42 PM, Vladimir 'phcoder'
> Serbinenko<phcoder@gmail.com> wrote:
> > Hello. NESTED_ATTR_FUNC was introduced 6 years ago to workaround a bug
> > in compiler. Now it creates only problems. In particular if they are
> > used wrong it creates a bug of argument passing. Such bugs are
> > difficult to find because it usually results in strange behaviour and
> > in grub-emu NESTED_FUNC_ATTR is exteneded to an empty string so gdb
> > and valgrind can't detect any error. Should we perhaps remove it
> > coupled with adding a requirement for at least gcc 4.2? Can I run
> > s/NESTED_FUNC_ATTR//g; on entire codebase and remove corresponding
> > entry in configure.ac?
> 
> Hi,
> 
> I make an assembly dump of the code generated by gcc-4.2. Apparently,
> the "FIX" is achieved by ignoring the regparm attribute at all.
> __attribute__ ((__regparm__ (3))) doesn't have any effect any more, it
> always pass the parameters on the stack. This defeats the original
> purpose of -mregparm=3, which passes parameters using register and
> therefore reduce module size. In fact, if we are going to use stack,
> we could just remove -mregparm=3 option, this works for all version of
> gcc.

I have the impression that using stack isn't a good idea for GRUB, due to
size and speed improvements, except in cases where we can't avoid it.

If older versions of GCC ignore -mregparm, we need a configure check
(I prefer one that checks for the feature itself, but a version check
is also acceptable IMHO).

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Bean]

On Tue, Sep 1, 2009 at 11:43 PM, Bean<bean123ch@gmail.com> wrote:
> On Tue, Sep 1, 2009 at 9:42 PM, Vladimir 'phcoder'
> Serbinenko<phcoder@gmail.com> wrote:
>> Hello. NESTED_ATTR_FUNC was introduced 6 years ago to workaround a bug
>> in compiler. Now it creates only problems. In particular if they are
>> used wrong it creates a bug of argument passing. Such bugs are
>> difficult to find because it usually results in strange behaviour and
>> in grub-emu NESTED_FUNC_ATTR is exteneded to an empty string so gdb
>> and valgrind can't detect any error. Should we perhaps remove it
>> coupled with adding a requirement for at least gcc 4.2? Can I run
>> s/NESTED_FUNC_ATTR//g; on entire codebase and remove corresponding
>> entry in configure.ac?
>
> Hi,
>
> I make an assembly dump of the code generated by gcc-4.2. Apparently,
> the "FIX" is achieved by ignoring the regparm attribute at all.
> __attribute__ ((__regparm__ (3))) doesn't have any effect any more, it
> always pass the parameters on the stack. This defeats the original
> purpose of -mregparm=3, which passes parameters using register and
> therefore reduce module size. In fact, if we are going to use stack,
> we could just remove -mregparm=3 option, this works for all version of
> gcc.
>
> IMO, if we are to tackle the NESTED_FUNC_ATTR issue, we should do it
> properly by removing nested function, this also has other advantages,
> like allowing to run tools on systems like OSX that doesn't allow to
> execute code in stack by default.

Hi,

Oh BTW, I just remember a page comparing the benchmark of ubuntu, and
find major slowdown in various tests after Ubuntu 7.04. Note that
ubuntu 7.04 uses gcc 4.1, while ubuntu 8.04 uses gcc 4.2, could this
be caused by the fact that gcc 4.2 starts to ignore some optimization
flags ?

http://www.phoronix.com/scan.php?page=article&item=ubuntu_bench_2008&num=1

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]


Le 1 sept. 09 à 17:43, Bean a écrit :

> On Tue, Sep 1, 2009 at 9:42 PM, Vladimir 'phcoder'
> Serbinenko<phcoder@gmail.com> wrote:
>> Hello. NESTED_ATTR_FUNC was introduced 6 years ago to workaround a  
>> bug
>> in compiler. Now it creates only problems. In particular if they are
>> used wrong it creates a bug of argument passing. Such bugs are
>> difficult to find because it usually results in strange behaviour and
>> in grub-emu NESTED_FUNC_ATTR is exteneded to an empty string so gdb
>> and valgrind can't detect any error. Should we perhaps remove it
>> coupled with adding a requirement for at least gcc 4.2? Can I run
>> s/NESTED_FUNC_ATTR//g; on entire codebase and remove corresponding
>> entry in configure.ac?
>
> Hi,
>
> I make an assembly dump of the code generated by gcc-4.2. Apparently,
> the "FIX" is achieved by ignoring the regparm attribute at all.
> __attribute__ ((__regparm__ (3))) doesn't have any effect any more, it
> always pass the parameters on the stack. This defeats the original
> purpose of -mregparm=3, which passes parameters using register and
> therefore reduce module size. In fact, if we are going to use stack,
> we could just remove -mregparm=3 option, this works for all version of
> gcc.
>
> IMO, if we are to tackle the NESTED_FUNC_ATTR issue, we should do it
> properly by removing nested function, this also has other advantages,
> like allowing to run tools on systems like OSX that doesn't allow to
> execute code in stack by default.

Agree with Bean, it's the last "issue" that made that we can't run  
tool on OSX directly.

Regards,
Yves Blusseau

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[David Miller]

From: Yves Blusseau <blusseau@zetam.org>
Date: Tue, 1 Sep 2009 21:30:01 +0200

> 
> Le 1 sept. 09 à 17:43, Bean a écrit :
> 
>> IMO, if we are to tackle the NESTED_FUNC_ATTR issue, we should do it
>> properly by removing nested function, this also has other advantages,
>> like allowing to run tools on systems like OSX that doesn't allow to
>> execute code in stack by default.
> 
> Agree with Bean, it's the last "issue" that made that we can't run
> tool on OSX directly.

I agree too, fixing the root issue would be a much better
cure for this rather than alienating everyone who happens
to be using older tools on their computer.

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Vladimir 'phcoder' Serbinenko]

On Wed, Sep 2, 2009 at 12:26 AM, David Miller<davem@davemloft.net> wrote:
> From: Yves Blusseau <blusseau@zetam.org>
> Date: Tue, 1 Sep 2009 21:30:01 +0200
>
>>
>> Le 1 sept. 09 à 17:43, Bean a écrit :
>>
>>> IMO, if we are to tackle the NESTED_FUNC_ATTR issue, we should do it
>>> properly by removing nested function, this also has other advantages,
>>> like allowing to run tools on systems like OSX that doesn't allow to
>>> execute code in stack by default.
>>
>> Agree with Bean, it's the last "issue" that made that we can't run
>> tool on OSX directly.
>
> I agree too, fixing the root issue would be a much better
> cure for this rather than alienating everyone who happens
> to be using older tools on their computer.
>
I can't agree with designating nested functions as root issue. Imagine
tomorrow we discover a bug in "for" loop compiling. This wouldn't be a
reason to replace all "for"s with "while"s. The root issue is compiler
bug and it should be fixed
The root issue is a compil
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[David Miller]

From: "Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>
Date: Thu, 3 Sep 2009 17:08:34 +0200

> I can't agree with designating nested functions as root issue. Imagine
> tomorrow we discover a bug in "for" loop compiling. This wouldn't be a
> reason to replace all "for"s with "while"s. The root issue is compiler
> bug and it should be fixed

I can tell you that in kernel land when we encounter a compiler
bug we usually have to simply cope with it somehow, and if that
means rearranging some loop to not trigger a bug that is sometimes
what it indeed does mean.

Also, a small project using a pretty obscure feature of gcc was in a
way asking for trouble :-)

But if you want to decrease your testing base every time we hit some
compiler bug you don't particularly like, well I guess that's your
perogative then...

Fwd: [RFC] Eliminate NESTED_ATTR_FUNC

[Vladimir 'phcoder' Serbinenko]

---------- Forwarded message ----------
From: David Miller <davem@davemloft.net>
Date: Sun, Sep 6, 2009 at 12:23 AM
Subject: Re: [RFC] Eliminate NESTED_ATTR_FUNC
To: phcoder@gmail.com


From: "Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>
Date: Sat, 5 Sep 2009 23:04:00 +0200

> On Fri, Sep 4, 2009 at 1:17 AM, David Miller<davem@davemloft.net> wrote:
>> From: "Vladimir 'phcoder' Serbinenko" <phcoder@gmail.com>
>> Date: Thu, 3 Sep 2009 17:08:34 +0200
>>
>>> I can't agree with designating nested functions as root issue. Imagine
>>> tomorrow we discover a bug in "for" loop compiling. This wouldn't be a
>>> reason to replace all "for"s with "while"s. The root issue is compiler
>>> bug and it should be fixed
>>
>> I can tell you that in kernel land when we encounter a compiler
>> bug we usually have to simply cope with it somehow, and if that
>> means rearranging some loop to not trigger a bug that is sometimes
>> what it indeed does mean.
> I would consider this as shooting oneself in a foot - it encourages
> compilers not to fix bugs.

I would consider it a way to be considerate to one's users.

We do file the bugs, but we recognize that 1) the fix won't
propagate for months, if that and 2) requiring a compiler update
decreases our testing base which is the most important thing we
have.

Do you get that?  "The size of your tester base is the most
important thing you have."

> What about compiling with -mregparam=1 and displaying a warning if bug
> is detected? This way users still be yable to use older gcc's just
> with a cost of some core size

Sure, that might work.



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: Fwd: [RFC] Eliminate NESTED_ATTR_FUNC

[Robert Millan]

On Sun, Sep 06, 2009 at 07:12:45PM +0200, Vladimir 'phcoder' Serbinenko wrote:
> 
> We do file the bugs, but we recognize that 1) the fix won't
> propagate for months, if that and 2) requiring a compiler update
> decreases our testing base which is the most important thing we
> have.
> 
> Do you get that?  "The size of your tester base is the most
> important thing you have."

It's one of them.  Other things are important, too.

I believe the best response is to aim for balance.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Bean]

On Tue, Sep 1, 2009 at 11:43 PM, Bean<bean123ch@gmail.com> wrote:
> I make an assembly dump of the code generated by gcc-4.2. Apparently,
> the "FIX" is achieved by ignoring the regparm attribute at all.
> __attribute__ ((__regparm__ (3))) doesn't have any effect any more, it
> always pass the parameters on the stack. This defeats the original
> purpose of -mregparm=3, which passes parameters using register and
> therefore reduce module size. In fact, if we are going to use stack,
> we could just remove -mregparm=3 option, this works for all version of
> gcc.

Hi,

Oh, I was wrong previously, gcc does respect __attribute__
((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
to store value). And the bug is still there ! Try this test program:

#include <stdio.h>

void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
{
  b += a;
  hook (a, b, a + b);
}

void qq (int a)
{
  auto void q1 (int aa, int bb, int cc);
  void q1 (int aa, int bb, int cc)
    {
      printf ("%d %d %d\n", a, aa + bb, cc);
    }

  foo (a, a + 1, q1);
}

int main()
{
  qq (10);
}

Compile with:
gcc -m32 -mregparm=3 -Os test.c

./a.out
10 31 -6674368

gcc is 4.3.4 from debian.
---
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Yves Blusseau]

[-- Attachment #1: Type: text/plain, Size: 649 bytes --]


> Oh, I was wrong previously, gcc does respect __attribute__
> ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
> to store value). And the bug is still there ! Try this test program:
>
> Compile with:
> gcc -m32 -mregparm=3 -Os test.c
>
> ./a.out
> 10 31 -6674368
>
> gcc is 4.3.4 from debian.

Here the test on Mac OSX 10.5.7:

* with gcc 4.0.1:

gcc -m32 -fnested-functions test.c : 10 31 31

gcc -m32 -fnested-functions -mregparm=3 -Os test.c : 10 31 -1073744144


* with gcc 4.2.1

gcc-4.2 -m32 -fnested-functions test.c : 10 31 31

gcc-4.2 -m32 -fnested-functions -mregparm=3 -Os test.c : 10 31  
-1073744128

Regards,
Yves

[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 2455 bytes --]

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Vladimir 'phcoder' Serbinenko]

> Hi,
>
> Oh, I was wrong previously, gcc does respect __attribute__
> ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
> to store value). And the bug is still there ! Try this test program:
I confirm with gcc-4.4
This is a grave problem then. This check was added by Marco Gerards
(maintainer) in 2003. He added a workaround but I don't believe such
behaviour to be correct. We're both GNU projects. IMO the correct
action would have been to report the bug to gcc-devel and refuse to
compile unless bug is fixed. This way users would update to newer gcc
patchlevel (e.g. 4.2.(X+1) instead of 4.2.X) instead of compiling with
buggy compiler. One GNU project shouldn't have expensive workaround
(we had bugs because of NESTED_FUNC_ATTR misuse)
Now we're in feature freeze but I hope in the future we'll be able to
change to correct behaviour when freeze is over.
>
> #include <stdio.h>
>
> void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
> {
>  b += a;
>  hook (a, b, a + b);
> }
>
> void qq (int a)
> {
>  auto void q1 (int aa, int bb, int cc);
>  void q1 (int aa, int bb, int cc)
>    {
>      printf ("%d %d %d\n", a, aa + bb, cc);
>    }
>
>  foo (a, a + 1, q1);
> }
>
> int main()
> {
>  qq (10);
> }
>
> Compile with:
> gcc -m32 -mregparm=3 -Os test.c
>
> ./a.out
> 10 31 -6674368
>
> gcc is 4.3.4 from debian.
> ---
> Bean
>
> gitgrub home: http://github.com/grub/grub/
> my fork page: http://github.com/bean123/grub/
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Vladimir 'phcoder' Serbinenko]

On Thu, Sep 3, 2009 at 5:54 PM, Paolo Bonzini<bonzini@gnu.org> wrote:
>
>>> #include<stdio.h>
>>>
>>> void foo (int a, int b, void (*hook) (int aa, int bb, int cc))
>>> {
>>>  b += a;
>>>  hook (a, b, a + b);
>>> }
>>>
>>> void qq (int a)
>>> {
>>>  auto void q1 (int aa, int bb, int cc);
>>>  void q1 (int aa, int bb, int cc)
>>>    {
>>>      printf ("%d %d %d\n", a, aa + bb, cc);
>>>    }
>>>
>>>  foo (a, a + 1, q1);
>>> }
>>>
>>> int main()
>>> {
>>>  qq (10);
>>> }
>>>
>>> Compile with:
>>> gcc -m32 -mregparm=3 -Os test.c
>>>
>>> ./a.out
>>> 10 31 -6674368
>
> Ok, this was the only important part of the message to us GCC hackers. :-)
>
> Can you please report a bug in bugzilla, saying which versions work and
> which fail?  Also can you write in the report what was your analysis with
> respect to regparm?
Done by Robert Millan here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
>
> Thanks!
>
> Paolo
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Robert Millan]

On Wed, Sep 02, 2009 at 12:20:19PM +0800, Bean wrote:
> 
> Hi,
> 
> Oh, I was wrong previously, gcc does respect __attribute__
> ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
> to store value). And the bug is still there ! Try this test program:

Thanks Bean.  I have opened an entry in GCC bugzilla, and submitted your
test program in it:

  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246

Hopefully they'll fix it in later versions, and hopefully people will
upgrade soon.  In the meantime, we're stuck with it.

-- 
Robert Millan

  The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and
  how) you may access your data; but nobody's threatening your freedom: we
  still allow you to remove your data and not access it at all."

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Felix Zielcke]

Am Donnerstag, den 03.09.2009, 17:36 +0200 schrieb Robert Millan:
> On Wed, Sep 02, 2009 at 12:20:19PM +0800, Bean wrote:
> > 
> > Hi,
> > 
> > Oh, I was wrong previously, gcc does respect __attribute__
> > ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
> > to store value). And the bug is still there ! Try this test program:
> 
> Thanks Bean.  I have opened an entry in GCC bugzilla, and submitted your
> test program in it:
> 
>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
> 
> Hopefully they'll fix it in later versions, and hopefully people will
> upgrade soon.  In the meantime, we're stuck with it.
> 

Is there any reason why we fallback to regparm 1 and not to regparm 2?
According to the output of the testcase in the above bug report 2 seems
to work too?

-- 
Felix Zielcke
Proud Debian Maintainer

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Vladimir 'phcoder' Serbinenko]

On Thu, Sep 3, 2009 at 5:49 PM, Felix Zielcke<fzielcke@z-51.de> wrote:
> Am Donnerstag, den 03.09.2009, 17:36 +0200 schrieb Robert Millan:
>> On Wed, Sep 02, 2009 at 12:20:19PM +0800, Bean wrote:
>> >
>> > Hi,
>> >
>> > Oh, I was wrong previously, gcc does respect __attribute__
>> > ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
>> > to store value). And the bug is still there ! Try this test program:
>>
>> Thanks Bean.  I have opened an entry in GCC bugzilla, and submitted your
>> test program in it:
>>
>>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
>>
>> Hopefully they'll fix it in later versions, and hopefully people will
>> upgrade soon.  In the meantime, we're stuck with it.
>>
>
> Is there any reason why we fallback to regparm 1 and not to regparm 2?
> According to the output of the testcase in the above bug report 2 seems
> to work too?
>
The reason to use regparam(3) is to save space. If you analyse and
discover that a gain of regparam(3) as opposed to regparam(2) isn't
big we should could change to regparam(2). The only drawback is that
all asm helpers with >=3 arguments need an excplicit attribute
regparam(3)
> --
> Felix Zielcke
> Proud Debian Maintainer
>
>
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> http://lists.gnu.org/mailman/listinfo/grub-devel
>



-- 
Regards
Vladimir 'phcoder' Serbinenko

Personal git repository: http://repo.or.cz/w/grub2/phcoder.git

Re: [RFC] Eliminate NESTED_ATTR_FUNC

[Bean]

On Thu, Sep 3, 2009 at 11:49 PM, Felix Zielcke<fzielcke@z-51.de> wrote:
> Am Donnerstag, den 03.09.2009, 17:36 +0200 schrieb Robert Millan:
>> On Wed, Sep 02, 2009 at 12:20:19PM +0800, Bean wrote:
>> >
>> > Hi,
>> >
>> > Oh, I was wrong previously, gcc does respect __attribute__
>> > ((__regparm__ (3))) flag (I forget to add -Os so it still uses stack
>> > to store value). And the bug is still there ! Try this test program:
>>
>> Thanks Bean.  I have opened an entry in GCC bugzilla, and submitted your
>> test program in it:
>>
>>   http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41246
>>
>> Hopefully they'll fix it in later versions, and hopefully people will
>> upgrade soon.  In the meantime, we're stuck with it.
>>
>
> Is there any reason why we fallback to regparm 1 and not to regparm 2?
> According to the output of the testcase in the above bug report 2 seems
> to work too?

Hi,

If the first parameter is 64-bit, it will use two registers, so the
second parameter is %ecx, which conflicts with local environment
pointer. To see it in action, change parameter int aa to long long aa
in the test program and compile it with -mregparm=2.

-- 
Bean

gitgrub home: http://github.com/grub/grub/
my fork page: http://github.com/bean123/grub/