Re: std::exception_ptr on Cygwin

[Dave Korn]

Piotr Wyderski wrote:
> Andrew Pinski wrote:
> 
>> i386 did not have atomic locks at all but 486 and above does.
> 
> Thanks, now it is obvious to me. So how should
> I configure my GCC-trunk build? It seems that
> --with-cpu is not enough:

  You need to look closer at the definition of -mcpu, -mtune and -march.  It's
the arch that selects which instructions may be generated, not the tune/cpu
setting which just controls scheduling optimisation and selection of best
instructions between equally available alternatives.  I use "--with-arch=i686
--with-tune=generic".

cheers,
  DaveK

Re: std::exception_ptr on Cygwin

[Piotr Wyderski]

Andrew Pinski wrote:

> i386 did not have atomic locks at all but 486 and above does.

Thanks, now it is obvious to me. So how should
I configure my GCC-trunk build? It seems that
--with-cpu is not enough:

$ gcc -v
Using built-in specs.
Target: i686-pc-cygwin
Configured with: ../configure --prefix=/opt/gcc-4.5-trunk -v --enable-bootstrap
--enable-version-specific-runtime-libs --enable-static --enable-shared --enable-
shared-libgcc --with-gnu-ld --with-gnu-as --enable-sjlj-exceptions --enable-lang
uages=c,c++ --disable-symvers --enable-libjava --disable-nls --with-cpu=core2 --
enable-threads=posix

Best regards
Piotr Wyderski

Re: std::exception_ptr on Cygwin

[Andrew Pinski]

On Thu, May 28, 2009 at 4:00 PM, Piotr Wyderski
 wrote:
> is not, as Cygwin does not use glibc. Its underlying
> processor architecture, however, supports the fullest
> set of atomic primitives, so is there really a need to
> make it glibc-dependent? If I enforce the macro
> definition from the command line, then the exception_ptr
> -dependent code compiles correctly (but does not link
> because of

Actually it is not due not to glibc but the default for i686-linux-gnu
and i686-cygwin is really targeting 386 and tuning for generic cpu.
i386 did not have atomic locks at all but 486 and above does.  This
has come up many times in the past too.

-- Pinski

Re: What does zero-length array mean at file scope?

[Dave Korn]

Joseph S. Myers wrote:
> On Sun, 24 May 2009, Dave Korn wrote:
> 
>>   So, is the testcase invalid, and should the compiler be warning about this
>> declaration?  I couldn't get any complaint out of it even with "-W -Wall
>> -Wextra -pedantic -std=c89"?  Or should the linker be allocating some space
>> for this zero-sized common?
> 
> I get "warning: ISO C forbids zero-size array 'i0'" with -pedantic.
> 

  Err.  Yes, so do I now.  It turns out you can't just tack a -W on a
cut-n-pasted command line to cancel out an earlier -w.

cheers,
  DaveK

std::exception_ptr on Cygwin

[Piotr Wyderski]

It is impossible to use std::exception_ptr and related
functionality on Cygwin in C++0x mode, despite the
fact the necessary classes seem to be implemented.
That is because in  there is a conditional
block:

#if (defined(__GXX_EXPERIMENTAL_CXX0X__) \
 && defined(_GLIBCXX_ATOMIC_BUILTINS_4))
#include 
#endif

The macro __GXX_EXPERIMENTAL_CXX0X__ is
defined correctly, as expected, but

_GLIBCXX_ATOMIC_BUILTINS_4

is not, as Cygwin does not use glibc. Its underlying
processor architecture, however, supports the fullest
set of atomic primitives, so is there really a need to
make it glibc-dependent? If I enforce the macro
definition from the command line, then the exception_ptr
-dependent code compiles correctly (but does not link
because of

 undefined reference to `std::__exception_ptr::exception_ptr::~exception_ptr()

and the other non-inline members. I presume
it is not the recommended way.

Best regards
Piotr Wyderski

Re: What does zero-length array mean at file scope?

[Dave Korn]

Joseph S. Myers wrote:
> On Sun, 24 May 2009, Andrew Haley wrote:
> 
>> Of course we have to fix the assembler output.  For ant two declarations
>> a and b, &a != &b, even when a is a zero-length array.  So, you have to
>> allocate at least one byte.
> 
> I don't think this is necessarily part of the semantics for the GNU 
> extensions of zero-length arrays and empty structures.  Certainly when 
> they are used in the middle of a structure they are not expected to take 
> up any space (so their address may be the same as that of the next 
> member).

  But by the time you're outputting an assembler (common or bss) symbol, if
it's still size zero, that's the final size of the whole object.  You may want
internal parts of the object to compare equal, but I think the data object as
a whole shouldn't match any other.

struct {
  char vla1[0];
  char vla2[0];
} a;

struct {
  char vla3[0];
} b;

  We want &a.vla1 == &a.vla2, but we don't want &a == &b.  No?

cheers,
  DaveK

gcc-4.5-20090528 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 147961

You'll find:

gcc-4.5-20090528.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.5-20090528.tar.bz2 C front end and core compiler

gcc-ada-4.5-20090528.tar.bz2  Ada front end and runtime

gcc-fortran-4.5-20090528.tar.bz2  Fortran front end and runtime

gcc-g++-4.5-20090528.tar.bz2  C++ front end and runtime

gcc-java-4.5-20090528.tar.bz2 Java front end and runtime

gcc-objc-4.5-20090528.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.5-20090528.tar.bz2The GCC testsuite

Diffs from 4.5-20090521 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.5
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.

Re: plugins & howto & generators

[Joseph S. Myers]

On Wed, 27 May 2009, Manuel López-Ibáñez wrote:

> > Should we tell them (the other users using the future gcc-4.5-dev Debian
> > package) in our documentation how to build a plugin (I mean what are the
> > actual commands to run, what kind of Makefile for them, what are the
> > required CFLAGS or -I... path, etc..), or should that be left to e.g. linux
> > distribution packagers?
> 
> A complete tutorial on how to create and build a generic plugin is
> perhaps more suited for the wiki than for the internals documentation.

However, sufficient documentation for building plugins should be included 
in the GCC sources so that it is branched with GCC, since it is likely 
there will be significant differences between GCC versions and so each GCC 
branch should include the associated plugin documentation.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: New GCC releases comparison and comparison of GCC4.4 and LLVM2.5 on SPEC2000

[Joseph S. Myers]

On Mon, 25 May 2009, Chris Lattner wrote:

> On May 13, 2009, at 5:26 AM, Duncan Sands wrote:
> 
> > Hi Richard,
> > 
> > > -mpc64 sets the x87 floating point control register to not use the 80bit
> > > extended precision.  This causes some x87 floating point operations
> > > to operate faster and there are no issues with the extra roundings you
> > > get when storing an 80bit precision register to a 64bit memory location.
> 
> However, this does break long double, right?

I already said in  that 
it is a purely link-time option that does not cause 
TARGET_96_ROUND_53_LONG_DOUBLE to be set; fixing that would make long 
double behave correctly, although not necessarily calls to libgcc, 
libstdc++, libm or other library functions that did not expect to be 
called in the different mode, unless extra multilibs built to expect that 
mode are added (and the source code to libraries such as libm adjusted to 
handle this).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: What does zero-length array mean at file scope?

[Joseph S. Myers]

On Sun, 24 May 2009, Andrew Haley wrote:

> Of course we have to fix the assembler output.  For ant two declarations
> a and b, &a != &b, even when a is a zero-length array.  So, you have to
> allocate at least one byte.

I don't think this is necessarily part of the semantics for the GNU 
extensions of zero-length arrays and empty structures.  Certainly when 
they are used in the middle of a structure they are not expected to take 
up any space (so their address may be the same as that of the next 
member).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: What does zero-length array mean at file scope?

[Joseph S. Myers]

On Sun, 24 May 2009, Dave Korn wrote:

>   So, is the testcase invalid, and should the compiler be warning about this
> declaration?  I couldn't get any complaint out of it even with "-W -Wall
> -Wextra -pedantic -std=c89"?  Or should the linker be allocating some space
> for this zero-sized common?

I get "warning: ISO C forbids zero-size array 'i0'" with -pedantic.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Is there a recursive debug_c_tree which decodes "variant tag"?

[Larry Evans]

On 05/28/09 11:42, Ian Lance Taylor wrote:
> Larry Evans  writes:
>
>> While attempting to debug the compiler on:
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
>>
>> I'm having great difficulty understanding the output
>> of debug_c_tree or debug_tree because the child
>> tree's are not shown.
>
> Can you give an example of what you mean?  debug_tree does show child
> trees as I understand it, although at each level down it shows less
> information.  If you want more information about a particular child,
> then you can see the address in the shortened information, and you can
> call debug_tree on that address.

Thanks Ian.  That helped.

>
>> Is there any such debug_tree function usable in
>> gdb or ddd which will show the actual tree
>> variant?
>
> Here again I don't understand what you mean.
>

From http://gcc.gnu.org/onlinedocs/gccint-html.tar.gz,
in Tree-overview.html#Tree-overview,
there's this:

  The central data structure used by the internal representation is
  the tree. These nodes, while all of the C type tree, are of many
  varieties. A tree is a pointer type, but the object to which it
  points may be of a variety of types.

A tree variant means one of these tree "varieties" mentioned in the
above quote.  I'm guessing the value returned by macro, TREE_CODE, is
some tag indicating which variety of tree.  What I meant by "show the
actual tree variant" is for the print function to decode the tag and
just print the particular variant for that tag.  However, I guess
decode_tree does that, but just prints the address of the child trees.
The user must manually call debug_tree on those children to see what
type they are.

I've tried that but it's not helping much.  The compiler is trying to
expand the pack expansion:

  integral_c
  < Integral
  , Values
  >...

in this template:

  template
  struct package_c
  : package
< integral_c
  < Integral
  , Values
  >...
>
  {
  };


at this instance:

 typedef
package_c< int, 1,2,3>
  ints_type
  ;

where:

  template
  struct integral_c
  {};

That works except when this is present:

template
< typename Package_C
>
  struct impl_front
  ;
template
< typename Integral
, Integral Head
, Integral... Tail
>
  struct impl_front
< package_c
  < Integral
  , Head
  , Tail...
  >
>
  {
  typedef
integral_c
  type
  ;
  };


So, I'm trying to see what the tree looks like.  AFAICT, the tree
should, somehow, reflect a pattern expansion:

  integral_c

and I was hoping, somehow, to see that or some error by using
debug_tree.  I expected to see a tree with children
representing Integral and Values, where Values was
a parameter pack. However, all I get at:

Breakpoint 3, make_pack_expansion (arg=0x7f62797cfe40) at 
/gcc/cp/pt.c:2692


is the following:

(gdb) p arg
$1 = (tree) 0x7f62797cfe40
(gdb) pt arg
 align 8 symtab 0 alias set -1 canonical type 0x7f62797c4cc0 context 


no-binfo use_template=1 interface-unknown
chain >

Then, using the call debug_tree on some addression shown above:

(gdb) call debug_tree(0x7f62797cff00)
 align 8 symtab 0 alias set -1 canonical type 0x7f62797c4cc0 
context 

no-binfo use_template=1 interface-unknown
chain >
public ignored decl_2 VOID file nested_integral_c_expansion.bug.cpp 
line 20 col 3

align 1 context >

I can't tell from this whether this is an expansion pattern or not.
Further use of call debug_tree on other addresses shown is equally
uninformative :(

I may have to wait till the variadic template experts get around to
this.

Thanks anyway, Ian.

-regards,
Larry

Re: Forgetting return values

[Jamie Prescott]

> From: Andrew Haley 
> To: Jamie Prescott 
> Cc: Adam Nemet ; "gcc-h...@gcc.gnu.org" 
> 
> Sent: Thursday, May 28, 2009 11:48:30 AM
> Subject: Re: Forgetting return values
> 
> Jamie Prescott wrote:
> >> From: Adam Nemet 
> 
> >>> Why is the memory clobber required, and why GCC does not understand to
> >>> sync the value to memory when passing the address to a function?
> >> Because you never inform GCC that you will use the value at
> >> address *NAME.  Try to use "m"(*name) rather than "a1"(name) in the asm.
> > 
> > That's 'data', not 'name'. But OK, got it. unfortunately, I cannot use "m" 
> since
> > that value need to go into a specific register.
> 
> This is not appropriate for gcc@, which is for gcc development.

Sorry, I posted to gcc@ because I thought it was a problem with my TARGET.


- Jamie


  

Re: Forgetting return values

[Adam Nemet]

Jamie Prescott writes:
> > From: Adam Nemet 
> > Jamie Prescott writes:
> > > static inline int set_prop(char const *path, char const *name,
> > >   void const *data, int size)
> > > {
> > > int error;
> > >
> > > asm volatile ("int\t11\n\t"
> > >   : "=a0" (error): "a0" (path), "a1" (name), "a2" 
> > > (data),
> > > "a3" (size));
> > >
> > > return error;
> > > }
> > >
> > > extern int calc(int);
> > >
> > > int proc(int i)
> > > {
> > > int j = calc(i);
> > >
> > > return set_prop(0, 0, &j, sizeof(int));
> > > }
> > ...
> > >
> > > Why is the memory clobber required, and why GCC does not understand to
> > > sync the value to memory when passing the address to a function?
> > 
> > Because you never inform GCC that you will use the value at
> > address *NAME.  Try to use "m"(*name) rather than "a1"(name) in the asm.
> 
> That's 'data', not 'name'. But OK, got it. unfortunately, I cannot use "m" 
> since
> that value need to go into a specific register.
> Any other solution?

You can also have it *in addition* as an argument to the asm that's never
used:

asm volatile ("int\t11\n\t"
  : "=a0" (error): "a0" (path), "a1" (name), "a2" (data),
"a3" (size), "m"(*data));

after changing data's type into something that can be dereferenced.

Adam

Re: Forgetting return values

[Jamie Prescott]

> From: Adam Nemet 
> To: Jamie Prescott 
> Cc: gcc@gcc.gnu.org
> Sent: Thursday, May 28, 2009 11:10:49 AM
> Subject: Re: Forgetting return values
> 
> Jamie Prescott writes:
> > static inline int set_prop(char const *path, char const *name,
> >   void const *data, int size)
> > {
> > int error;
> >
> > asm volatile ("int\t11\n\t"
> >   : "=a0" (error): "a0" (path), "a1" (name), "a2" 
> > (data),
> > "a3" (size));
> >
> > return error;
> > }
> >
> > extern int calc(int);
> >
> > int proc(int i)
> > {
> > int j = calc(i);
> >
> > return set_prop(0, 0, &j, sizeof(int));
> > }
> ...
> >
> > Why is the memory clobber required, and why GCC does not understand to
> > sync the value to memory when passing the address to a function?
> 
> Because you never inform GCC that you will use the value at
> address *NAME.  Try to use "m"(*name) rather than "a1"(name) in the asm.

That's 'data', not 'name'. But OK, got it. unfortunately, I cannot use "m" since
that value need to go into a specific register.
Any other solution?


- Jamie


  

Re: Forgetting return values

[Adam Nemet]

Jamie Prescott  writes:
> static inline int set_prop(char const *path, char const *name,
>   void const *data, int size)
> {
> int error;
>
> asm volatile ("int\t11\n\t"
>   : "=a0" (error): "a0" (path), "a1" (name), "a2" (data),
> "a3" (size));
>
> return error;
> }
>
> extern int calc(int);
>
> int proc(int i)
> {
> int j = calc(i);
>
> return set_prop(0, 0, &j, sizeof(int));
> }
...
>
> Why is the memory clobber required, and why GCC does not understand to
> sync the value to memory when passing the address to a function?

Because you never inform GCC that you will use the value at
address *NAME.  Try to use "m"(*name) rather than "a1"(name) in the asm.

Adam

Forgetting return values

[Jamie Prescott]

What am I missing?
I have a simple:

static inline int set_prop(char const *path, char const *name,
  void const *data, int size)
{
int error;

asm volatile ("int\t11\n\t"
  : "=a0" (error): "a0" (path), "a1" (name), "a2" (data),
"a3" (size));

return error;
}

extern int calc(int);

int proc(int i)
{
int j = calc(i);

return set_prop(0, 0, &j, sizeof(int));
}

The aX classes maps to the rX registers, no problem for GCC in there.
The code above, compiled with GCC 4.4.0 and -O3 produces:


 _proc:
pushFP
mov SP,FP
sub SP,4,SP
call   _calc
mov 0,r0
mov 4,r3
add FP,-4,r2
mov r0,r1
;   APP
; 69 ".c" 1
int 11

;   NO_APP
add SP,4,SP
pop FP
ret

GCC forgets about the calc() return value, and passes an address (FP-4) that
has never been written into.
buf if I add a "memory" clobber to the asm inline, everything comes back to
normal:

_proc:
pushFP
mov SP,FP
sub SP,4,SP
call   _calc
str.wr0,FP[-4]
mov 0,r0
mov 4,r3
add FP,-4,r2
mov r0,r1
;   APP
; 69 ".c" 1
int 11

;   NO_APP
add SP,4,SP
pop FP
ret

Why is the memory clobber required, and why GCC does not understand to
sync the value to memory when passing the address to a function?
Thanks,


- Jamie



  

Re: Is there a recursive debug_c_tree which decodes "variant tag"?

[Ian Lance Taylor]

Larry Evans  writes:

> While attempting to debug the compiler on:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40092
>
> I'm having great difficulty understanding the output
> of debug_c_tree or debug_tree because the child
> tree's are not shown.

Can you give an example of what you mean?  debug_tree does show child
trees as I understand it, although at each level down it shows less
information.  If you want more information about a particular child,
then you can see the address in the shortened information, and you can
call debug_tree on that address.

> Is there any such debug_tree function usable in
> gdb or ddd which will show the actual tree
> variant?

Here again I don't understand what you mean.

Ian

Is there a recursive debug_c_tree which decodes "variant tag"?

[Larry Evans]

While attempting to debug the compiler on:

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

I'm having great difficulty understanding the output
of debug_c_tree or debug_tree because the child
tree's are not shown.  The ddd debugger:

  http://www.gnu.org/software/ddd/

is some help; however, even there it's unclear
what the tree looks like because the tree is
some sort of variant and ddd apparently doesn't
know how to interpret the variant's tag.  Instead,
I have to trial and error what the variant is
and mostly miss the mark.

Is there any such debug_tree function usable in
gdb or ddd which will show the actual tree
variant?

Re: Accessing called function attributes in FUNCTION_ARG macro

[Georg-Johann Lay]

Weddington, Eric schrieb:

Hi All,

This may be a dumb question, but I'm having difficulty finding the answer to 
this.

I'm working on a back-end and I have a function being called for the 
FUNCTION_ARG macro, and in that function I need to find out the attributes of 
the called function as this will affect the calling convention. I've tried 
looking at many of the other ports to see if anyone else is doing anything 
similar but so far I haven't found any other port that does that.

Could someone could point me in the right direction to do this?


Hi Eric,

1) Scan for the attributes in INIT_CUMULATIVE_ARGS
   and set up some "call-cookie" that stores the
   information as part of CUMULATIVE_ARGS structure.
   To do this, scan the provided tree for the attribute:
  if (fntype && has_attribute_p (fntype)) cookie = ...
2) Update te cookie as needed in FUNCTION_ARG et al.
   resp. use it to generate the arguments' locations.
3) If FUNCTION_ARG et al. gets called with VOIDmode,
   return a CONST_INT representing the cookie.
   The CONST_INT will then appear as op2 resp op3
   in expander of call/sibcall resp call_value/sibcall_value
4) If insn output depends on the cookie, use it to print asm

The trouble is, that if FUNCTION_OK_FOR_SIBCALL depends on the
information gathered in CUMULATIVE_ARGS, calls.c doesn't pass
that information to the backend. This is important if a sibcall
must not be done depending on where callee's args are being passed.
sibcall patterns must not fail, so you had to hack around that.
Or more probably, I am just missing that part :-/

To look up the attribute, I am using code like

static bool has_attribute_p (tree func, const char *name)
{
tree a;
if (FUNCTION_DECL == TREE_CODE (func))
   func = TREE_TYPE (func);
gcc_assert (TREE_CODE (func) == FUNCTION_TYPE);
a = lookup_attribute (name, TYPE_ATTRIBUTES (func));

return a != NULL_TREE;
}

Georg-Johann

Accessing called function attributes in FUNCTION_ARG macro

[Weddington, Eric]

Hi All,

This may be a dumb question, but I'm having difficulty finding the answer to 
this.

I'm working on a back-end and I have a function being called for the 
FUNCTION_ARG macro, and in that function I need to find out the attributes of 
the called function as this will affect the calling convention. I've tried 
looking at many of the other ports to see if anyone else is doing anything 
similar but so far I haven't found any other port that does that.

Could someone could point me in the right direction to do this?

Thanks,
Eric Weddington