Re: calculation of pi

[Mischa Baars]

On 11/02/2012 07:11 PM, Ian Lance Taylor wrote:

On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars  wrote:

I have been writing this piece of example code, but it seems that someone
has been modifying the compiler in the meantime such that arguments are now
passed in xmm registers instead of over the stack. Also the npx top of stack
pointer isn't handled alike for all three different types of real numbers on
function return any more.

I have not looked at your code.  However, I can tell you that on
32-bit x86 floating point function arguments are normally passed on
the stack and on 64-bit x86 floating point arguments are normally
passed in the xmm registers.  There are various ways that you can
change this default behaviour, but if you are seeing an unexpected
change then I would guess that you changed from 32-bit compilation to
64-bit compilation.

Ian


Probably I have. But when I pass the -m32 parameter I get an unexpected 
error:


/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such file 
or directory


which also prevents me from compiling the compiler under Fedora 17. This 
means that I am both not able to compile programs in 32-bit mode and 
help you with the compiler.


Is there a solution and what are the exact alternatives you refer to?

Mischa

Re: calculation of pi

[Mischa Baars]

On 11/02/2012 07:11 PM, Ian Lance Taylor wrote:

On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars  wrote:

I have been writing this piece of example code, but it seems that someone
has been modifying the compiler in the meantime such that arguments are now
passed in xmm registers instead of over the stack. Also the npx top of stack
pointer isn't handled alike for all three different types of real numbers on
function return any more.

I have not looked at your code.  However, I can tell you that on
32-bit x86 floating point function arguments are normally passed on
the stack and on 64-bit x86 floating point arguments are normally
passed in the xmm registers.  There are various ways that you can
change this default behaviour, but if you are seeing an unexpected
change then I would guess that you changed from 32-bit compilation to
64-bit compilation.

Ian


By the way, it seems this only holds for single and double real numbers. 
These are indeed passed in xmm registers, the long double however is 
still passed over the stack.


Do we have any compiler options that change this behaviour back to the 
original? The default behaviour in 64-bit mode is not even the same for 
all real number types.


Mischa.

[help]failed to generate PHI NODE in esra pass.

[Yangyueming]

Hi, all

I do the research of min max instructions recently. I find it is related with 
phiopt.

case1:
int foo(short a ,short b)
{
  if (a < b)
    a = b;  
  return a;
}

It is successed in pass phiopt1(-O2 with gcc 4.7.0). The MAX_EXPR can be 
generated.

foo (short int a, short int b)
{
  int D.2094;

:
  a_9 = MAX_EXPR ;
  D.2094_5 = (int) a_9;
  return D.2094_5;

} 

But when I do the test for a case with a little change, it is failed to 
generate MAX_EXPR in phiopt1.
The failed case2 :
int foo(short a ,short b)
{
  int c;
  if (a < b)
    a = b; 
  
  c = *(int *)&a;
  return c;
}

I find it is because of the esra pass failed to generate PHI NODE.
Dump of phifail.c.027t.esra:
foo (short int a, short int b)
{
  int c;
  short int a$0;

:
  a$0_1 = a;
  if (a$0_1 < b_2(D))
    goto ;
  else
    goto ;

:
  a = b_2(D);

:
  c_4 = MEM[(int *)&a];
  c_5 = c_4;
  return c_5;

}

Why it is failed and if there's a way to make it work?
Please give some help, thanks.
 
 Yang Yueming.

Re: calculation of pi

[Tim Prince]

On 11/3/2012 3:32 AM, Mischa Baars wrote:



/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such 
file or directory


which also prevents me from compiling the compiler under Fedora 17. 
This means that I am both not able to compile programs in 32-bit mode 
and help you with the compiler.


Normally, this means you didn't install the optional (32-bit) 
glibc-devel i386.


--
Tim Prince

Re: calculation of pi

[Mischa Baars]

On 11/03/2012 12:41 PM, Tim Prince wrote:

On 11/3/2012 3:32 AM, Mischa Baars wrote:



/usr/include/gnu/stubs.h:7:27: fatal error: gnu/stubs-32.h: No such 
file or directory


which also prevents me from compiling the compiler under Fedora 17. 
This means that I am both not able to compile programs in 32-bit mode 
and help you with the compiler.


Normally, this means you didn't install the optional (32-bit) 
glibc-devel i386.




Yes, you are right! You need to install both 'glibc-devel.i686' and 
'libgcc.i686', however you need to do this manually with 'yum' because 
they do not appear on the list of installable packages with the 
'add/remove software' applet.


Mischa.

GCC Phoning Home

[Bruce Korb]

I have realized that it would be real useful to know which fixinclude fixes
are actually in use so that old cruft can get retired.  Since nobody at all
has direct access to all the actively maintained platforms, it makes it
difficult to know.  Therefore, it seems reasonable to me to jigger up some
sort of automated email that could get automatically processed to let me
know which fixes are actively being triggered.  Consequently I propose adding
some infrastructure to GCC that will construct an email that users may, at
their option, actually send out.  It would go to some yet-to-be-defined but
well defined email address set up to automatically handle these reports.
The full GCC build would, as a final step, look to see if there were any
messages to be sent home.  If so, it would construct the full message,
including headers, and ask the person (or machine) doing the build to send
the email.

If this sounds reasonable, and if someone sets up the "gcc-repo...@gcc.gnu.org"
email address, then sometime in the next couple of months, I'll work up a
patch that will do what I am suggesting here.

Thank you.  Regards, Bruce

gcc-4.7-20121103 is now available

[gccadmin]

Snapshot gcc-4.7-20121103 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.7-20121103/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_7-branch 
revision 193127

You'll find:

 gcc-4.7-20121103.tar.bz2 Complete GCC

  MD5=cdef154c260085869dc5b18927e04c4a
  SHA1=bfb768d0ff4b263ffaafa4a2b2b4961bd864e93c

Diffs from 4.7-20121027 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Feature request: Attribute to delay evaluation of function argument

[Clinton Mead]

Hi All

This is a feature request. To explain, lets say I want to create a
TriBool type, like so:

enum TriBool { False, True, Unknown };

I now want to implement operator&&. I want operator&& to short
circuit, i.e. if the first argument is False the second argument
shouldn't be evaluated.

So I'll make operator&& take a function object for it's second
argument, like so:

TriBool operator&&
(
  TriBool x,
  const std::function& y
)
{
  if (x == False) { return False; }
  else
  {
TriBool y_ = y();
if (x == True) { return y_; }
else if (y_ == False) { return False; }
else { return Unknown; }
  }
}

This way if I have:

#define DELAY(x) [&]{ return x; }

TriBool f();
TriBool g();

I can do:

f() && DELAY(g())

and hence have short circuit evaluation.

However, what I'd like to have is just "f() && g()". It would be good
to be able to give the second argument an attribute which basically
wraps any argument passed to it with "DELAY()". Is this possible, or
has it already been done?

Regards,

Clinton

Re: Configure gcc with --multilib=... ?

[Matt Turner]

On Tue, Jun 14, 2011 at 9:26 AM, Joseph S. Myers
 wrote:
> On Tue, 14 Jun 2011, Matt Turner wrote:
>
>> I say this mail http://gcc.gnu.org/ml/gcc/2010-01/msg00063.html
>> suggesting the addition of a --multilib= configure option. Has such a
>> thing been added? Is there a way to configure gcc to build only n32
>
> No, the project has not yet reached that stage (right now 9000 lines of
> patches have been pending review for over two weeks
> 
> , which largely
> blocks subsequent patches) and the proposed option was a driver option,
> not a configure option; the proposal explicitly excluded issues with how
> the set of multilibs is configured.  There is no general configure support
> for adjusting the set of multilibs, although there are some fairly
> flexible options on SH and ad hoc options for other targets such as
> controlling 64-bit libraries on i686-pc-linux-gnu with
> --enable-targets=all (and see how HJ's x32 patches allow configuring
> whether x32 multilibs are enabled).
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

Hi Joseph,

I see that --with-multilib-list= is an option for AMD64 and SH. Are
there plans or patches for mips? Otherwise, have there been any
developments that will allow me to configure to build only n32 and
n64?

Thanks,
Matt

Re: Configure gcc with --multilib=... ?

[Andrew Pinski]

On Sat, Nov 3, 2012 at 5:50 PM, Matt Turner  wrote:

> Hi Joseph,
>
> I see that --with-multilib-list= is an option for AMD64 and SH. Are
> there plans or patches for mips? Otherwise, have there been any
> developments that will allow me to configure to build only n32 and
> n64?

I created my own subtarget for this like:
mips64-octeon-linux-gnu
and then use a t-octeon-linux which overrides the default t-linux64.
I also default to targeting octeon but that is a different reason.
You can do the same, it is not hard either.

Thanks,
Andrew Pinski

Re: Feature request: Attribute to delay evaluation of function argument

[Oleg Endo]

On Sun, 2012-11-04 at 11:02 +1100, Clinton Mead wrote:
> Hi All
> 
> This is a feature request. To explain, lets say I want to create a
> TriBool type, like so:
> 
> enum TriBool { False, True, Unknown };
> 
> I now want to implement operator&&. I want operator&& to short
> circuit, i.e. if the first argument is False the second argument
> shouldn't be evaluated.
> 
> So I'll make operator&& take a function object for it's second
> argument, like so:
> 
> TriBool operator&&
> (
>   TriBool x,
>   const std::function& y
> )
> {
>   if (x == False) { return False; }
>   else
>   {
> TriBool y_ = y();
> if (x == True) { return y_; }
> else if (y_ == False) { return False; }
> else { return Unknown; }
>   }
> }
> 
> This way if I have:
> 
> #define DELAY(x) [&]{ return x; }
> 
> TriBool f();
> TriBool g();
> 
> I can do:
> 
> f() && DELAY(g())
> 
> and hence have short circuit evaluation.
> 
> However, what I'd like to have is just "f() && g()". It would be good
> to be able to give the second argument an attribute which basically
> wraps any argument passed to it with "DELAY()". Is this possible, or
> has it already been done?
> 

I think this can be done without any additional features or extensions.
Have you tried 'class TriBool' with an 'explicit operator bool', instead
of overloading operator && for this purpose?

Cheers,
Oleg

LRA unaligned reloads

[David Miller]

On 32-bit sparc with LRA enabled we have the following (this
generated for gcc.dg/vect/pr51581-4.c with -flto):

(insn 252 142 165 4 (set (reg:HI 234 [ D.1511 ])
(mem/c:HI (plus:SI (reg/f:SI 1307)
(const_int 24 [0x18])) [4 b+24 S2 A64])) test.c:23 59 
{*movhi_insn}
 (expr_list:REG_EQUIV (mem/c:HI (plus:SI (reg/f:SI 1307)
(const_int 24 [0x18])) [4 b+24 S2 A64])
(expr_list:REG_EQUAL (mem/c:HI (const:SI (plus:SI (symbol_ref:SI 
("b.1425") [flags 0x2]  <\
var_decl 0xf7519740 b>)
(const_int 24 [0x18]))) [4 b+24 S2 A64])
(nil

 ...

(insn 255 221 233 4 (set (reg:SI 1285)
(ashift:SI (subreg:SI (reg:HI 234 [ D.1511 ]) 0)
(const_int 16 [0x10]))) test.c:23 306 {ashlsi3}
 (expr_list:REG_DEAD (reg:HI 234 [ D.1511 ])
(nil)))

When LRA does reloads for insn 255, it tries to strip the subregs
for pseudo 234 and use SImode moves.

(insn 1367 1732 1712 4 (set (reg:SI 12 %o4 [1425])
(mem/c:SI (plus:SI (reg/f:SI 3 %g3 [1307])
(const_int 22 [0x16])) [4 b+22 S4 A16])) test.c:23 61 
{*movsi_insn}
 (nil))
(insn 255 1712 1366 4 (set (reg:SI 12 %o4 [1285])
(ashift:SI (reg:SI 12 %o4 [1425])
(const_int 16 [0x10]))) test.c:23 306 {ashlsi3}
 (expr_list:REG_DEAD (reg:SI 12 %o4 [1425])
(nil)))
(insn 1366 255 1711 4 (set (reg:SI 12 %o4 [1285])
(reg:SI 12 %o4 [1285])) test.c:23 61 {*movsi_insn}
 (expr_list:REG_DEAD (reg:SI 12 %o4 [1285])
(nil)))

Unfortunately, this is illegal, because insn 1367 is an SImode
load to a non-4-byte-aligned location (%g3 + 22).

This does work, and might even be profitable, on non-STRICT_ALIGNMENT
targets.  But for those which are STRICT_ALIGNMENT, we cannot make
transformations like this.

Re: calculation of pi

[Ian Lance Taylor]

On Sat, Nov 3, 2012 at 12:55 AM, Mischa Baars  wrote:
> On 11/02/2012 07:11 PM, Ian Lance Taylor wrote:
>>
>> On Fri, Nov 2, 2012 at 8:13 AM, Mischa Baars 
>> wrote:
>>>
>>> I have been writing this piece of example code, but it seems that someone
>>> has been modifying the compiler in the meantime such that arguments are
>>> now
>>> passed in xmm registers instead of over the stack. Also the npx top of
>>> stack
>>> pointer isn't handled alike for all three different types of real numbers
>>> on
>>> function return any more.
>>
>> I have not looked at your code.  However, I can tell you that on
>> 32-bit x86 floating point function arguments are normally passed on
>> the stack and on 64-bit x86 floating point arguments are normally
>> passed in the xmm registers.  There are various ways that you can
>> change this default behaviour, but if you are seeing an unexpected
>> change then I would guess that you changed from 32-bit compilation to
>> 64-bit compilation.
>>
>> Ian
>
>
> By the way, it seems this only holds for single and double real numbers.
> These are indeed passed in xmm registers, the long double however is still
> passed over the stack.

Yes.

> Do we have any compiler options that change this behaviour back to the
> original? The default behaviour in 64-bit mode is not even the same for all
> real number types.

There is no "original."  The 32-bit and 64-bit ABIs are different.
The 64-bit ABI has always passed arguments in registers.  There is no
option to force the 64-bit compiler to pass arguments on the stack.

Ian