other major .so version bumps?

[Jack Howarth]

  The libgfortran in trunk is slated to shortly have a version
bump from .1 to .2...

http://gcc.gnu.org/ml/fortran/2006-07/msg00128.html

I am wondering if any of the other shared libraries in gcc trunk
are slated to have major version bumps as well before gcc 4.2
branches? I ask because fink on MacOS X has been using gcc trunk
for the MacIntel support and they will have to cope with the
version bump of libgfortran. It would be nice to know if that is
going to be the only major sover change between gcc 4.1 and 4.2.
 Jack

Calling gimplify_to_stmt_list (...) on a statement containing a TARGET_MEM_REF node

[Roberto COSTA]

Hello,
I've just noticed that gimplify_expr () function (from gimplify.c) 
asserts when trying to gimplify a TARGET_MEM_REF.
TARGET_MEM_REF nodes are generated after the gimplification pass, this 
is why gimple_expr (...) doesn't expect any TARGET_MEM_REF at all.
However, gimplify_to_stmt_list (...) (which is based on gimple_expr) may 
be called much later in the compilation flow.
Does anybody calling gimplify_to_stmt_list (...) have to make sure there 
are no TARGET_MEM_REFs in the statement about to be gimplified?


Is it a bug... or am I trying to do something wrong?

Cheers,
Roberto

Re: Calling gimplify_to_stmt_list (...) on a statement containing a TARGET_MEM_REF node

[Andrew Pinski]

On Jul 14, 2006, at 11:01 PM, Roberto COSTA wrote:

Is it a bug... or am I trying to do something wrong?


Why are you trying to regimplify something which is in gimple?

Thanks,
Andrew Pinski

Re: Calling gimplify_to_stmt_list (...) on a statement containing a TARGET_MEM_REF node

[Roberto COSTA]

Andrew Pinski wrote:


On Jul 14, 2006, at 11:01 PM, Roberto COSTA wrote:


Is it a bug... or am I trying to do something wrong?



Why are you trying to regimplify something which is in gimple?


I'm trying to generate new code, which happens to contain TARGET_MEM_REF.
To do that, I find more convenient to generate a big and deep tree and 
to gimplify it later (I saw other passes follow this approach).
I haven't really generated the TARGET_MEM_REF myself, I'm just reusing 
an already existing expression (with no side effects).


Cheers,
Roberto

Re: Calling gimplify_to_stmt_list (...) on a statement containing a TARGET_MEM_REF node

[Daniel Berlin]

Roberto COSTA wrote:
> Andrew Pinski wrote:
>> On Jul 14, 2006, at 11:01 PM, Roberto COSTA wrote:
>>
>>> Is it a bug... or am I trying to do something wrong?
>>
>> Why are you trying to regimplify something which is in gimple?
> 
> I'm trying to generate new code, which happens to contain TARGET_MEM_REF.
> To do that, I find more convenient to generate a big and deep tree and 
> to gimplify it later (I saw other passes follow this approach).

Passes that absolutely need to do it, should, others probably shouldn't.
It generally is a waste of time and memory to do it if your pass can
simply generate piecewise GIMPLE expressions on it's own.

Anyway, ignoring Andrew's tangent for a moment, this is a bug.

:)

Re: x86_64 ABI

[Michael Matz]

Hi,

On Thu, 13 Jul 2006, Maurizio Vitale wrote:

> my understanding of the x86_64 ABI is that the following structure should be
> passed in registers:

Right.

> struct data {
>   unsigned int x;
>   unsigned int y;
>   unsigned long z;
> };
> 
> but when I compile:
> 
> #include 
> 
> struct data {
>  unsigned int  x   : 32;
>  unsigned int  y   : 32;
>  unsigned long dummy   : 64;
> } ;

Note that this contains bitfields, which sometimes is handled specially 
in the ABI.  It doesn't matter in this case, but I though I point it out.

> I get different results, depending on whether I compile it as C or C++ code.
> I'm using gcc 4.1.1 (but the same happens with 3.4.5).
> 
> In C I get:
> main:
> .LFB12:
>subq$8, %rsp
> .LCFI0:
>movl$1, d+8(%rip)
>movl$2, d+12(%rip)
>movqd(%rip), %rdi
>movqd+8(%rip), %rsi
>callfoo

That doesn't match the layout in the code presented.  It should set d+0 
and d+4 (members x and y are at the start of d).  But let's ignore that.  
The value is passed just fine in registers here, as expected and as you 
said already.

> But in C++ the result is different and the data structure is passed on the
> stack.
> main:
> .LFB13:
>subq$24, %rsp
> .LCFI0:
>movl$1, d+8(%rip)
>movqd(%rip), %rdi
>movl$2, d+12(%rip)
>movqd+8(%rip), %rsi
>movq%rdi, (%rsp)
>movq%rsi, 8(%rsp)
>callfoo

No, nothing is passed on the stack.  To see that you need to look from 
where 'foo' actually reads the arguments.  For a trivial foo I get this 
code:

int foo (data t)
{
  return t.x + t.y;
}

foo:
.LFB13:
movq%rdi, -16(%rsp)
movl-16(%rsp), %eax
addl-12(%rsp), %eax
ret

Reading from registers, exactly right.  What confused you were the writes 
to some stack memory, which _looks_ as if they are there to pass something 
on the stack.  In reality it's simply a dead store to a dead temporary 
which happened to be placed on the stack and gcc wasn't able to optimize 
away.  To see that look at the GIMPLE code generated by the gcc and g++ 
frontends.  (from t03.gimple).  gcc:

main (argc, argv)
{
  int D.2232;
  int D.2233;

  d.x = 1;
  d.y = 2;
  D.2232 = foo (d);

g++:

int main(int, char**) (argc, argv)
{
  struct data D.2838;
  int D.2839;
  int D.2840;

  d.x = 1;
  d.y = 2;
  D.2838 = d;
  D.2839 = foo (D.2838);

Note the extra temporary D.2838.  The stack write you see correspond to 
"D.2838 = d".  GCC then later was able to optimize the use of D.2838 (as 
call argument) away to directly use d (i.e. %rsi/%rdi which happen to 
contain the value of d after the writes to x and y), but not the store to 
the stack place allocated for D.2838.

That's an artifact how calls are generated in the c++ frontend (it's too 
eagerly using temporaries), but not error.


Ciao,
Michael.

Re: why are we not using const?

[Kaveh R. Ghazi]

 > "Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:
 > 
 > [...]
 > 
 > | I'd like to do for tree and rtx what I did for const char *,
 > | namely constify those tree/rtx functions that aren't supposed to
 > | modify their arguments.  This would require introducing the
 > | const_tree and const_rtx typedefs Tristan suggested.
 > 
 > Yes, totally agreed -- that would be more profitable.
 > -- Gaby

So I tried a quick start on const_tree, etc to see if there would be
any problems and found one.  The issue is the definition of the
TREE_CHECK macro when using gcc and checking is enabled, i.e.:

#define TREE_CHECK(T, CODE) __extension__ \
({  const tree __t = (T); \
if (TREE_CODE (__t) != (CODE)) \
  tree_check_failed (__t, __FILE__, __LINE__, __FUNCTION__, (CODE), 0); \
__t; })

Now imagine if I change the type of __t to const_tree like so:

typedef const union tree_node *const_tree;
#define TREE_CHECK(T, CODE) __extension__ \
({  const_tree const __t = (T); \
if (TREE_CODE (__t) != (CODE)) \
  tree_check_failed (__t, __FILE__, __LINE__, __FUNCTION__, (CODE), 0); \
__t; })

(And also assume that tree_check_failed() has had its first parameter
constified.)

Now the problem is that the statement expression in the TREE_CHECK
macro uses __t as it's "return value".  The TREE_CHECK macro is used
in both read and write situations of tree members.  So the "return
value" of this statement expression cannot be const or all the write
cases barf.

We may need two versions of this macro, a TREE_CHECK and a
CONST_TREE_CHECK, and we would have to create duplicate tree accessors
that use one or the other.  But that would require modifying the gcc
sources at every invocation of tree accesses to call an appropriate
macro depending on whether the intended operation was read or write.
Yuck.

Another easier solution would be to cast away the const-ness of __t
when returning like so:

typedef const union tree_node *const_tree;
#define TREE_CHECK(T, CODE) __extension__ \
({  const_tree const __t = (T); \
if (TREE_CODE (__t) != (CODE)) \
  tree_check_failed (__t, __FILE__, __LINE__, __FUNCTION__, (CODE), 0); \
(tree)__t; })


But this defeats the purpose of using const.  (It's sort of like using
strchr's return value, not const-safe.)  It will also generate
gillions of -Wcast-qual warnings if you add that flag.

Another solution might be to use the macro parameter as the return
type like so:

typedef const union tree_node *const_tree;
#define TREE_CHECK(T, CODE) __extension__ \
({  const_tree const __t = (T); \
if (TREE_CODE (__t) != (CODE)) \
  tree_check_failed (__t, __FILE__, __LINE__, __FUNCTION__, (CODE), 0); \
(T); })

Then if "T" isn't already const you can write to it.  But this
evaluates "T" twice so if there are side-effects potentially we get
hosed.


I guess I'm looking for something like how C++ lets you overload
functions based on const-ness of a parameter and change the
return-type's const-ness respectively.  Someone once told me C++
should have had two "strchr" functions.

extern const char *strchr(const char *, int);
extern char *strchr(char *, int);

Note the non-gcc non-checking TREE_CHECK macros are fine because they
just evaluate to the tree parameter "T" and do nothing.  So their
const-ness just works.  That means we're free to use gcc extensions to
work around this in the checking-enabled version of the macros.

Any ideas?

Thanks,
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

RE: why are we not using const?

[Dave Korn]

On 14 July 2006 18:22, Kaveh R. Ghazi wrote:

> Now imagine if I change the type of __t to const_tree like so:
> 
> typedef const union tree_node *const_tree;
> #define TREE_CHECK(T, CODE) __extension__ \
> ({  const_tree const __t = (T); \
> if (TREE_CODE (__t) != (CODE)) \
>   tree_check_failed (__t, __FILE__, __LINE__, __FUNCTION__, (CODE), 0);
> \ __t; })

> Now the problem is that the statement expression in the TREE_CHECK
> macro uses __t as it's "return value".  The TREE_CHECK macro is used
> in both read and write situations of tree members.  So the "return
> value" of this statement expression cannot be const or all the write
> cases barf.

  So just return T instead of _t.

> Another solution might be to use the macro parameter as the return
> type like so:

  Ah, I see you thought of that!
 
> typedef const union tree_node *const_tree;
> #define TREE_CHECK(T, CODE) __extension__ \
> ({  const_tree const __t = (T); \
> if (TREE_CODE (__t) != (CODE)) \
>   tree_check_failed (__t, __FILE__, __LINE__, __FUNCTION__, (CODE), 0);
> \ (T); })
> 
> Then if "T" isn't already const you can write to it.  But this
> evaluates "T" twice so if there are side-effects potentially we get
> hosed.

> Any ideas?

  Use /two/ locals like this?

typedef const union tree_node *const_tree;
#define TREE_CHECK(T, CODE) __extension__ \
({  \
  __typeof__(T) __t = (T); \
  const_tree const __ct = t; \
  if (TREE_CODE (__ct) != (CODE)) \
tree_check_failed (__ct, __FILE__, __LINE__, __FUNCTION__, (CODE), 0);
  \ __t; })


  So __ct is always const, and __t has the same const-ness as T.

  Hmm.  The docs don't specify whether typeof preserves CV-qualification.  We
could always add a __qualified_typeof__ that did if ordinary __typeof__
doesn't, I suppose.

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

Re: why are we not using const?

[Ian Lance Taylor]

"Kaveh R. Ghazi" <[EMAIL PROTECTED]> writes:

> #define TREE_CHECK(T, CODE) __extension__ \
> ({  const_tree const __t = (T); \

How about
typeof(T) const __t = (T);
?

Ian

Re: gcc visibility used by moz

[Geoffrey Keating]

Gabriel Dos Reis <[EMAIL PROTECTED]> writes:

> Jason Merrill <[EMAIL PROTECTED]> writes:
> 
> [...]
> 
> | > | - I don't recall suggesting that
> | > | multiple types with the same name should be able to exist.
> | > then you have to consider that suggestion and come with an answer.
> | 
> | I don't see why.  The point is that visibility is orthogonal to
> | linkage; a class S with external linkage is still required by the ODR
> | to be unique across multiple shared objects even if some of the
> | symbols that refer to it can't be referenced from outside their
> | defining object.  The visibility restrictions place practical limits
> | on how other objects can use the type, but that doesn't mean it isn't
> | the same type.
> 
> So, -concretely- what happens to a class S (e.g. associated type info object
> address, address of member functions, etc.) with external linkage,
> defined in multiple translation units, with say hidden visibility?

Under the current definition, this is impossible.  If you have a class
S defined in one object with hidden visibility, and you try to define
it in a different object, you get a different class named S, just as if
you'd defined it in a different namespace or similar.

Thus, the type info objects are different, the member functions have
different addresses, and so on.

This is achived by giving the various pieces hidden visibility.

Re: gcc visibility used by moz

[Geoffrey Keating]

Tristan Wibberley <[EMAIL PROTECTED]> writes:

> The types are defined in headers and are thus known
> to exist - no visibility attributes will or should change that.

The question here is not whether the types exist, but which types are
the same as which other types.

I think that what you want is a model of visibility in which all types
are always visible.  Although abstractly such a model is possible, I
think it's less useful than the current model, because it makes it
hard to isolate shared libraries from each other.  It is certainly
possible to emulate such a model with the current GCC, if it's what
you want, by simply not marking types as hidden.

Re: gcc visibility used by moz

[Geoffrey Keating]

Jason Merrill <[EMAIL PROTECTED]> writes:

> Benjamin Smedberg wrote:
> > Jason Merrill wrote:
> >
> >> Do you agree with implicitly giving template instantiations the
> >> minimum visibility of the template and arguments unless explicitly
> >> overridden?
> > This is not what I would naturally expect, coming from a
> > dllimport/export mindset, but I don't think it's a problem from the
> > mozilla POV: all of our exports are explicitly declared if/when we
> > use hidden visibility pragmas.
> > Is a pragma considered an explicit override? e.g.
> > class nsIAbstract {
> >   virtual void Bar();
> > };
> > #pragma GCC visibility push(default)
> > nsIAbstract* Getter();
> > #pragma GCC visibility pop
> 
> For a namespace-scope entity like this, yes (class members and
> template instantiations use the visibility of their class and template
> in preference to the current #pragma).
> 
> >> Also, do you agree with warning about a class with greater
> >> visibility than its data members/bases?
> > Sure... I would really like to disable this warning if possible,
> > since it will be produced thousands of times in a mozilla build ;-)
> 
> I find that surprising, since it sounds like VC++ gives the same
> warning about a dllexport class with a non-dllexport base.

I think that if the aim is to have VC++ compatibility, that should be
separate from the 'right' solution.  Apple has a flag,
-fvisibility-ms-compat, which attempts to achieve this, and which
we'll probably contribute for 4.3.

There are some things that this flag does which you definitely
wouldn't want in well-structured code and other things which the flag
does which may limit the C++ features you'll be able to use in future
(like serialisation if that ever gets standardized).

Re: gcc visibility used by moz

[Geoffrey Keating]

Joe Buck <[EMAIL PROTECTED]> writes:

> I wrote [for two classes S with visibility == hidden ]
> > | > | We can have two distinct
> > | > | classes named S, and no one can tell.  Each bit of code will see one
> > | > | definition of S.
> 
> Jason Merrill <[EMAIL PROTECTED]> writes:
> > | I think that Joe's point is that IF you have two classes named S, then
> > | they're hidden away in separate shared libraries and you can't compare
> > | them, because no piece of code knows about both of them.
> 
> Yes.  It is sometimes necessary with very large software systems to
> use tricks like this because someone was sloppy about naming (particularly
> in older code that comes from times before namespaces were universally
> available, and many of us do have to deal with 7-10 year old code on
> occasion).

I don't think you can say 'no piece of code knows about both of them'.
What you can say is that these two classes are both named S but
they're different, just as if they were in different namespaces.

> On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
> > I'm not clear about "you can't compare them".
> > 
> > Surely, I can take the address of typeid(S) and pass it around to
> > a function in another translation unit.  I can do
> > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes
> > from two such different translation units.
> > 
> > How the current visibility framework prevent that from happening?
> 
> By a note in the documentation telling the user "don't do that".

No, there's no such note.  The answer is that the two typeids have
different addresses, so one will be before the other, depending on
where the shared libraries got loaded, just as if the classes had
different names.

Re: gcc visibility used by moz

[Geoffrey Keating]

Jason Merrill <[EMAIL PROTECTED]> writes:

> Gabriel Dos Reis wrote:
> > Jason Merrill <[EMAIL PROTECTED]> writes:
> > So, -concretely- what happens to a class S (e.g. associated type
> > info object
> > address, address of member functions, etc.) with external linkage,
> > defined in multiple translation units, with say hidden visibility?
> 
> If it has hidden visibility then shared objects other than the one
> with the definition can't do much with it.  They can use inline
> interfaces and interfaces that are explicitly overridden to have
> default visibility.
> 
> Anything that relies on weak symbols to unify vague linkage entities
> across shared objects will break.

I don't think "break" is the right word here.  It will behave exactly
as documented.  If you were expecting the two classes to be the same,
then you'll find won't be, but this is not breakage, it is a fault of
your expectation---and remember, we have a perfectly good way to make
sure that the classes *are* the same, which is to give the classes
default visibility.

Re: gcc visibility used by moz

[Joe Buck]

On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
> > > I'm not clear about "you can't compare them".
> > > 
> > > Surely, I can take the address of typeid(S) and pass it around to
> > > a function in another translation unit.  I can do
> > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes
> > > from two such different translation units.
> > > 
> > > How the current visibility framework prevent that from happening?

Joe Buck <[EMAIL PROTECTED]> writes:
> > By a note in the documentation telling the user "don't do that".

On Fri, Jul 14, 2006 at 11:34:18AM -0700, Geoffrey Keating wrote:
> No, there's no such note.  The answer is that the two typeids have
> different addresses, so one will be before the other, depending on
> where the shared libraries got loaded, just as if the classes had
> different names.

We're in complete agreement.  What I meant was to say that if Gaby is
worried over user confusion on this point, we'd add a warning that
the result isn't defined, but I expressed it in a sloppy way.  I know
that the documentation currently says nothing on the matter.

Re: gcc visibility used by moz

[Geoffrey Keating]

Joe Buck <[EMAIL PROTECTED]> writes:

> On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
> > > > I'm not clear about "you can't compare them".
> > > > 
> > > > Surely, I can take the address of typeid(S) and pass it around to
> > > > a function in another translation unit.  I can do
> > > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes
> > > > from two such different translation units.
> > > > 
> > > > How the current visibility framework prevent that from happening?
> 
> Joe Buck <[EMAIL PROTECTED]> writes:
> > > By a note in the documentation telling the user "don't do that".
> 
> On Fri, Jul 14, 2006 at 11:34:18AM -0700, Geoffrey Keating wrote:
> > No, there's no such note.  The answer is that the two typeids have
> > different addresses, so one will be before the other, depending on
> > where the shared libraries got loaded, just as if the classes had
> > different names.
> 
> We're in complete agreement.  What I meant was to say that if Gaby is
> worried over user confusion on this point, we'd add a warning that
> the result isn't defined, but I expressed it in a sloppy way.  I know
> that the documentation currently says nothing on the matter.

Oh, I see.

The definition for 'before' in the standard says

> true if *this precedes rhs in the implementation's collation order.

and 'collation order' is not-specified as:

> The names, encoding rule, and collating sequence for types are all
> unspecified and may differ between programs.

I guess we could say that even for the same binary, the collating
sequence still might differ between runs of the binary (on systems
like Linux where the library load addresses vary randomly); or you
could just try to fit that under the definition of a 'program'.

However, this is not a visibility-related issue, since the exact same
thing happens even if you don't use any visibility control at all, and
just have two differently-named classes in different shared objects.

Searching configured and relocated prefix.

[Carlos O'Donell]

GCC,

We currently search both the relocated compilers prefix and the
originally configured prefix. Should a relocated compiler be searching
both directories?

Does anyone see a need to search *both* the configured prefix and the
relocated prefix?  You can end up finding things you don't mean to find,
you can get NFS time-outs, etc.

However, the strategy above will break situations where people expect to
find some of their bits in a directory indicated by GCC_EXEC_PREFIX, and
the rest in the configured prefix.  

Cheers,
Carlos.
-- 
Carlos O'Donell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x716

Re: gcc visibility used by moz

[Gabriel Dos Reis]

First of all, thank you for "seeing" the problem I was trying to
communicate. 

Geoffrey Keating <[EMAIL PROTECTED]> writes:

| Joe Buck <[EMAIL PROTECTED]> writes:
| 
| > I wrote [for two classes S with visibility == hidden ]
| > > | > | We can have two distinct
| > > | > | classes named S, and no one can tell.  Each bit of code will see one
| > > | > | definition of S.
| > 
| > Jason Merrill <[EMAIL PROTECTED]> writes:
| > > | I think that Joe's point is that IF you have two classes named S, then
| > > | they're hidden away in separate shared libraries and you can't compare
| > > | them, because no piece of code knows about both of them.
| > 
| > Yes.  It is sometimes necessary with very large software systems to
| > use tricks like this because someone was sloppy about naming (particularly
| > in older code that comes from times before namespaces were universally
| > available, and many of us do have to deal with 7-10 year old code on
| > occasion).
| 
| I don't think you can say 'no piece of code knows about both of them'.
| What you can say is that these two classes are both named S but
| they're different, just as if they were in different namespaces.

That would mirror how C++ handles classes in unnamed namspaces.  In
other words, the visibility would have to be part of the mangled name.

| > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| > > I'm not clear about "you can't compare them".
| > > 
| > > Surely, I can take the address of typeid(S) and pass it around to
| > > a function in another translation unit.  I can do
| > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes
| > > from two such different translation units.
| > > 
| > > How the current visibility framework prevent that from happening?
| > 
| > By a note in the documentation telling the user "don't do that".
| 
| No, there's no such note.  The answer is that the two typeids have
| different addresses, so one will be before the other, depending on
| where the shared libraries got loaded, just as if the classes had
| different names.

In the case where __GXX_MERGED_TYPEINFO_NAMES is not defined, that
would not be true.  Because the current definition of
type_info::before uses a strcmp() on their mangled name. 
To make the implementation correct, the mangled name need to
incorporate the visibility attribute.  

And even  where __GXX_MERGED_TYPEINFO_NAMES is defined, it appears to
me that it is also a Good Thing to incorporate the visibility in the
mangled name so that the result of before() becomes deterministic and
does not depend on the order of loading of shared libraries.

-- Gaby

Re: gcc visibility used by moz

[Gabriel Dos Reis]

Geoffrey Keating <[EMAIL PROTECTED]> writes:

| Joe Buck <[EMAIL PROTECTED]> writes:
| 
| > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| > > > > I'm not clear about "you can't compare them".
| > > > > 
| > > > > Surely, I can take the address of typeid(S) and pass it around to
| > > > > a function in another translation unit.  I can do
| > > > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2 comes
| > > > > from two such different translation units.
| > > > > 
| > > > > How the current visibility framework prevent that from happening?
| > 
| > Joe Buck <[EMAIL PROTECTED]> writes:
| > > > By a note in the documentation telling the user "don't do that".
| > 
| > On Fri, Jul 14, 2006 at 11:34:18AM -0700, Geoffrey Keating wrote:
| > > No, there's no such note.  The answer is that the two typeids have
| > > different addresses, so one will be before the other, depending on
| > > where the shared libraries got loaded, just as if the classes had
| > > different names.
| > 
| > We're in complete agreement.  What I meant was to say that if Gaby is
| > worried over user confusion on this point, we'd add a warning that
| > the result isn't defined, but I expressed it in a sloppy way.  I know
| > that the documentation currently says nothing on the matter.
| 
| Oh, I see.
| 
| The definition for 'before' in the standard says
| 
| > true if *this precedes rhs in the implementation's collation order.
| 
| and 'collation order' is not-specified as:
| 
| > The names, encoding rule, and collating sequence for types are all
| > unspecified and may differ between programs.
| 
| I guess we could say that even for the same binary, the collating
| sequence still might differ between runs of the binary (on systems
| like Linux where the library load addresses vary randomly); or you
| could just try to fit that under the definition of a 'program'.
| 
| However, this is not a visibility-related issue, since the exact same
| thing happens even if you don't use any visibility control at all, and
| just have two differently-named classes in different shared objects.

If we don't have visibility attribute comes into the picture, then I
think we don't have the problem in the first place precisely because
of the One Definition Rule.  My example of inconsistency was this:

  typeinfo1 != typeinfo2

   and yet

   !typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1)


The last conjuction should be false if we had the visibility stuff
correct.  I.e. one of typeinfo1 and typeinfo2 must be before the other,
but we can't say exactly which one.  The predictability is a QoI, and
holds only for platforms whether __GXX_MERGED_TYPEINFO_NAMES is not
defined.  Thats aspect is indeed independent of visibility.  However the
logical expression above becomes an issue when we have the visibility
attribute. 

-- Gaby

Re: gcc visibility used by moz

[Gabriel Dos Reis]

Geoffrey Keating <[EMAIL PROTECTED]> writes:

| Jason Merrill <[EMAIL PROTECTED]> writes:
| 
| > Gabriel Dos Reis wrote:
| > > Jason Merrill <[EMAIL PROTECTED]> writes:
| > > So, -concretely- what happens to a class S (e.g. associated type
| > > info object
| > > address, address of member functions, etc.) with external linkage,
| > > defined in multiple translation units, with say hidden visibility?
| > 
| > If it has hidden visibility then shared objects other than the one
| > with the definition can't do much with it.  They can use inline
| > interfaces and interfaces that are explicitly overridden to have
| > default visibility.
| > 
| > Anything that relies on weak symbols to unify vague linkage entities
| > across shared objects will break.
| 
| I don't think "break" is the right word here.  It will behave exactly
| as documented.  If you were expecting the two classes to be the same,
| then you'll find won't be, but this is not breakage, it is a fault of
| your expectation---and remember, we have a perfectly good way to make
| sure that the classes *are* the same, which is to give the classes
| default visibility.

I believe I did not communicate correctly the issue.  Consider the
(other version of)
current definiton of type_info::before:

#if !__GXX_MERGED_TYPEINFO_NAMES

bool
type_info::before (const type_info &arg) const
{
  return __builtin_strcmp (name (), arg.name ()) < 0;
}

#endif


This implementation will make the expression

!typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1)

holds for two such classes that you consider different.  That is
inconsistent. 

-- Gaby

Re: gcc visibility used by moz

[Gabriel Dos Reis]

Geoffrey Keating <[EMAIL PROTECTED]> writes:

| Gabriel Dos Reis <[EMAIL PROTECTED]> writes:
| 
| > Jason Merrill <[EMAIL PROTECTED]> writes:
| > 
| > [...]
| > 
| > | > | - I don't recall suggesting that
| > | > | multiple types with the same name should be able to exist.
| > | > then you have to consider that suggestion and come with an answer.
| > | 
| > | I don't see why.  The point is that visibility is orthogonal to
| > | linkage; a class S with external linkage is still required by the ODR
| > | to be unique across multiple shared objects even if some of the
| > | symbols that refer to it can't be referenced from outside their
| > | defining object.  The visibility restrictions place practical limits
| > | on how other objects can use the type, but that doesn't mean it isn't
| > | the same type.
| > 
| > So, -concretely- what happens to a class S (e.g. associated type info object
| > address, address of member functions, etc.) with external linkage,
| > defined in multiple translation units, with say hidden visibility?
| 
| Under the current definition, this is impossible.  If you have a class
| S defined in one object with hidden visibility, and you try to define
| it in a different object, you get a different class named S, just as if
| you'd defined it in a different namespace or similar.
| 
| Thus, the type info objects are different, the member functions have
| different addresses, and so on.
| 
| This is achived by giving the various pieces hidden visibility.

On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
is defined in terms of the mangled names of the types.  I'm unable to
find the mangled names are different.

-- Gaby

Re: gcc visibility used by moz

[Geoffrey Keating]

On 14/07/2006, at 3:01 PM, Gabriel Dos Reis wrote:



First of all, thank you for "seeing" the problem I was trying to
communicate.

Geoffrey Keating <[EMAIL PROTECTED]> writes:

| Joe Buck <[EMAIL PROTECTED]> writes:
|
| > I wrote [for two classes S with visibility == hidden ]
| > > | > | We can have two distinct
| > > | > | classes named S, and no one can tell.  Each bit of code  
will see one

| > > | > | definition of S.
| >
| > Jason Merrill <[EMAIL PROTECTED]> writes:
| > > | I think that Joe's point is that IF you have two classes  
named S, then
| > > | they're hidden away in separate shared libraries and you  
can't compare

| > > | them, because no piece of code knows about both of them.
| >
| > Yes.  It is sometimes necessary with very large software  
systems to
| > use tricks like this because someone was sloppy about naming  
(particularly
| > in older code that comes from times before namespaces were  
universally
| > available, and many of us do have to deal with 7-10 year old  
code on

| > occasion).
|
| I don't think you can say 'no piece of code knows about both of  
them'.

| What you can say is that these two classes are both named S but
| they're different, just as if they were in different namespaces.

That would mirror how C++ handles classes in unnamed namspaces.  In
other words, the visibility would have to be part of the mangled name.


Well, yes and no.  Actually, what I'd like C++ to do is to not have  
the mangled name for an anonymous namespace object contain the random  
string it currently contains.  I think Jason's changes now let me do  
this!



| > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| > > I'm not clear about "you can't compare them".
| > >
| > > Surely, I can take the address of typeid(S) and pass it  
around to

| > > a function in another translation unit.  I can do
| > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2  
comes

| > > from two such different translation units.
| > >
| > > How the current visibility framework prevent that from  
happening?

| >
| > By a note in the documentation telling the user "don't do that".
|
| No, there's no such note.  The answer is that the two typeids have
| different addresses, so one will be before the other, depending on
| where the shared libraries got loaded, just as if the classes had
| different names.

In the case where __GXX_MERGED_TYPEINFO_NAMES is not defined, that
would not be true.  Because the current definition of
type_info::before uses a strcmp() on their mangled name.
To make the implementation correct, the mangled name need to
incorporate the visibility attribute.


I'm not sure what you mean by the 'visibility attribute'.  I think  
that to make this work, you would need to have the mangled name  
contain a unique identifier (perhaps its load address) for the shared  
object instance in question, just as for anonymous namespace names we  
have the name contain a unique identifier for the translation unit in  
question.


However, getting this unique identifier is going to be a little  
tricky.  You can't do it at compile time (since this .o file might be  
in more than one shared object) or at link time (since this shared  
library might be loaded more than once, for instance using dlopen 
()).  So it has to be set up at load time.  So we're talking about  
strings in writable memory, linker and assembler and compiler changes  
to generate the relocations, binary incompatibility...  It seems like  
it would be just as easy to implement weak symbols and then have  
__GXX_MERGED_TYPEINFO_NAMES to be defined.


I don't believe there's any platform yet which has visibility but not  
weak symbols, so this is not a problem that needs to be solved at the  
moment.




smime.p7s
Description: S/MIME cryptographic signature

Re: gcc visibility used by moz

[Mike Stump]

On Jul 14, 2006, at 3:01 PM, Gabriel Dos Reis wrote:

That would mirror how C++ handles classes in unnamed namspaces.  In
other words, the visibility would have to be part of the mangled name.


Can't do that and preserve the abi, also, there is no concept in gcc  
currently to so name it, and what's worse, in general, it is just  
impossible given how people use gcc.  You'd require that the decision  
of which shared library a compilation unit is to go into be fixed  
before compilation, currently, that isn't so required.


All in all, we should just agree to not worry about non-merged  
typeinfo name, or remove support for it.

Re: gcc visibility used by moz

[Gabriel Dos Reis]

Geoffrey Keating <[EMAIL PROTECTED]> writes:

[...]

| > | I don't think you can say 'no piece of code knows about both of
| > them'.
| > | What you can say is that these two classes are both named S but
| > | they're different, just as if they were in different namespaces.
| >
| > That would mirror how C++ handles classes in unnamed namspaces.  In
| > other words, the visibility would have to be part of the mangled name.
| 
| Well, yes and no.  Actually, what I'd like C++ to do is to not have
| the mangled name for an anonymous namespace object contain the random
| string it currently contains.  I think Jason's changes now let me do
| this!

I'm all for the any predictable scheme that makes the mangled unique.

What I meant by "that would mirror the unnamed namespace case" is
that that no longer violates the ODR rule.  It makes the case defined.

| > | > On Thu, Jul 13, 2006 at 03:41:29PM +0200, Gabriel Dos Reis wrote:
| > | > > I'm not clear about "you can't compare them".
| > | > >
| > | > > Surely, I can take the address of typeid(S) and pass it
| > around to
| > | > > a function in another translation unit.  I can do
| > | > > typeinfo1->before(*typeinfo2), where typeinfo1 and typeinfo2
| > comes
| > | > > from two such different translation units.
| > | > >
| > | > > How the current visibility framework prevent that from
| > happening?
| > | >
| > | > By a note in the documentation telling the user "don't do that".
| > |
| > | No, there's no such note.  The answer is that the two typeids have
| > | different addresses, so one will be before the other, depending on
| > | where the shared libraries got loaded, just as if the classes had
| > | different names.
| >
| > In the case where __GXX_MERGED_TYPEINFO_NAMES is not defined, that
| > would not be true.  Because the current definition of
| > type_info::before uses a strcmp() on their mangled name.
| > To make the implementation correct, the mangled name need to
| > incorporate the visibility attribute.
| 
| I'm not sure what you mean by the 'visibility attribute'.  I think
| that to make this work, you would need to have the mangled name
| contain a unique identifier (perhaps its load address) for the shared
| object instance in question, just as for anonymous namespace names we
| have the name contain a unique identifier for the translation unit in
| question.
| 
| However, getting this unique identifier is going to be a little
| tricky.  You can't do it at compile time (since this .o file might be
| in more than one shared object) or at link time (since this shared
| library might be loaded more than once, for instance using dlopen ()).

Yes.

| So it has to be set up at load time.  So we're talking about  strings
| in writable memory, linker and assembler and compiler changes  to
| generate the relocations, binary incompatibility...  It seems like  it
| would be just as easy to implement weak symbols and then have
| __GXX_MERGED_TYPEINFO_NAMES to be defined.
| 
| I don't believe there's any platform yet which has visibility but not
| weak symbols, so this is not a problem that needs to be solved at the
| moment.

I seem to remember a PR posted by Adobe people kind of related to
this, but maybe I'm remembering wrong.  I have to dig up bugzilla.

-- Gaby

Re: gcc visibility used by moz

[Gabriel Dos Reis]

Mike Stump <[EMAIL PROTECTED]> writes:

[...]

| All in all, we should just agree to not worry about non-merged
| typeinfo name, or remove support for it.

If we remove support for it, then that indeed simplifies the issue.

-- Gaby

Re: gcc visibility used by moz

[Joe Buck]

On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
> On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
> is defined in terms of the mangled names of the types.  I'm unable to
> find the mangled names are different.

Which is why we should just say that it is unspecified behavior to
compare typeinfo objects in this case.

Re: gcc visibility used by moz

[Gabriel Dos Reis]

Joe Buck <[EMAIL PROTECTED]> writes:

| On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| > On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| > is defined in terms of the mangled names of the types.  I'm unable to
| > find the mangled names are different.
| 
| Which is why we should just say that it is unspecified behavior to
| compare typeinfo objects in this case.

What that concretely means is that it alienates, for example, codes
based on Factory desigbn pattern using typeinfo objects.  

-- Gaby

Re: gcc visibility used by moz

[Mike Stump]

On Jul 14, 2006, at 3:50 PM, Gabriel Dos Reis wrote:

I seem to remember a PR posted by Adobe people kind of related to
this, but maybe I'm remembering wrong.  I have to dig up bugzilla.


If it is a bug that describes how matching doesn't work across dylibs  
on older darwin systems (pre-tiger), well, let's just call that an OS  
bug that's been fixed.

Re: gcc visibility used by moz

[Mike Stump]

On Jul 14, 2006, at 4:03 PM, Gabriel Dos Reis wrote:

What that concretely means is that it alienates, for example, codes
based on Factory desigbn pattern using typeinfo objects.


I'd love some input from the MS VC++ programming crowd on this  
issue.  I don't see how they get past this issue.  I've had some  
claim, but it's a feature, not a bug.


The basic question is, are two unrelated types in different dlls the  
same, just because they have the same name?  How do you prevent them  
from being the same?

Re: gcc visibility used by moz

[Joe Buck]

On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote:
> Joe Buck <[EMAIL PROTECTED]> writes:
> 
> | On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
> | > On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
> | > is defined in terms of the mangled names of the types.  I'm unable to
> | > find the mangled names are different.
> | 
> | Which is why we should just say that it is unspecified behavior to
> | compare typeinfo objects in this case.
> 
> What that concretely means is that it alienates, for example, codes
> based on Factory desigbn pattern using typeinfo objects.  

No, it doesn't.  And I was doing pretty much exactly what you are talking
about back in 1992 (as part of what is now called Ptolemy Classic, see
http://ptolemy.eecs.berkeley.edu/ptolemyclassic/ ), adding new object code
to running executables to define new classes, with a Factory pattern
interface, long before we had typeinfo or the concept of design patterns
was introduced.  It only means that you can't do the job with typeinfo
comparison alone.  Since we didn't have typeinfo then, the classes had
to have a common base to implement the necessary support for type
identification, registration with the factory, and cloning.

To stay in the realm of defined behavior, you only need to avoid the
case where two distinct classes have the same name, because that's the
case where the typeinfo comparison's behavior is implementation-dependent.
This is easily done.

Re: gcc visibility used by moz

[Gabriel Dos Reis]

Joe Buck <[EMAIL PROTECTED]> writes:

| On Sat, Jul 15, 2006 at 01:03:46AM +0200, Gabriel Dos Reis wrote:
| > Joe Buck <[EMAIL PROTECTED]> writes:
| > 
| > | On Sat, Jul 15, 2006 at 12:19:40AM +0200, Gabriel Dos Reis wrote:
| > | > On platfoms where __GXX_MERGED_TYPEINFO_NAMES is not defined, before()
| > | > is defined in terms of the mangled names of the types.  I'm unable to
| > | > find the mangled names are different.
| > | 
| > | Which is why we should just say that it is unspecified behavior to
| > | compare typeinfo objects in this case.
| > 
| > What that concretely means is that it alienates, for example, codes
| > based on Factory desigbn pattern using typeinfo objects.  
| 
| No, it doesn't.  And I was doing pretty much exactly what you are talking
| about back in 1992 (as part of what is now called Ptolemy Classic, see
| http://ptolemy.eecs.berkeley.edu/ptolemyclassic/ ), adding new object code
| to running executables to define new classes, with a Factory pattern
| interface, long before we had typeinfo or the concept of design patterns
| was introduced. 

Yes, people were programming with classes in C long before they
switched to C++.  No offense, intended.

| It only means that you can't do the job with typeinfo
| comparison alone.  Since we didn't have typeinfo then, the classes had
| to have a common base to implement the necessary support for type
| identification, registration with the factory, and cloning.
| 
| To stay in the realm of defined behavior, you only need to avoid the
| case where two distinct classes have the same name, because that's the
| case where the typeinfo comparison's behavior is implementation-dependent.
| This is easily done.

-- Gaby

gcc-4.1-20060714 is now available

[gccadmin]

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

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

You'll find:

gcc-4.1-20060714.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.1-20060714.tar.bz2 C front end and core compiler

gcc-ada-4.1-20060714.tar.bz2  Ada front end and runtime

gcc-fortran-4.1-20060714.tar.bz2  Fortran front end and runtime

gcc-g++-4.1-20060714.tar.bz2  C++ front end and runtime

gcc-java-4.1-20060714.tar.bz2 Java front end and runtime

gcc-objc-4.1-20060714.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.1-20060714.tar.bz2The GCC testsuite

Diffs from 4.1-20060707 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.1
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: gcc visibility used by moz

[Gabriel Dos Reis]

Mike Stump <[EMAIL PROTECTED]> writes:

| On Jul 14, 2006, at 3:50 PM, Gabriel Dos Reis wrote:
| > I seem to remember a PR posted by Adobe people kind of related to
| > this, but maybe I'm remembering wrong.  I have to dig up bugzilla.
| 
| If it is a bug that describes how matching doesn't work across dylibs
| on older darwin systems (pre-tiger), well, let's just call that an OS
| bug that's been fixed.

I'm glad to hear that some of the problems can be traced back to OS
issues, not GCC!  I've been trying to locate the set of PRs I had in
mind, but for the moment it is such an amazing web!

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

That impressive and inistructive thread does not contain the other
case I seem to remember.

-- Gaby

Re: gcc visibility used by moz

[Gabriel Dos Reis]

Mike Stump <[EMAIL PROTECTED]> writes:

| On Jul 14, 2006, at 4:03 PM, Gabriel Dos Reis wrote:
| > What that concretely means is that it alienates, for example, codes
| > based on Factory desigbn pattern using typeinfo objects.
| 
| I'd love some input from the MS VC++ programming crowd on this  issue.

yes, that will be helfpul.  

If I understand correctly, MS VC++ does not use the mangle name, so it
would be interesting to hear how they implement operator== and
before() for type_infos.

| I don't see how they get past this issue.  I've had some  claim, but
| it's a feature, not a bug.
| 
| The basic question is, are two unrelated types in different dlls the
| same, just because they have the same name?  How do you prevent them
| from being the same?

it has been a kind of implicit garantee that two classes with external
linkage and with same mangled names refers to the same type.
Implementations have used that property -- which "leaks" into user
codes via type_info::operator== and type_info::before. 

My primary concern is to what extent that guarantee continues to hold
with the visibility stuff and without alienating coding patterns.  

When __GXX_MERGED_TYPEINFO_NAMES is defined, there is no problem as
things get separate addresses and comparisons are done on addresses.
Your earlier suggestion to discontinue support for
!__GXX_MERGED_TYPEINFO_NAMES may be a way out, unless a scheme
outlined by Geoff is implemented (that seems unlikely, as it is
complicated). 

-- Gaby

gcc inline assembly on x86 platform

[bluecoder]

hi,

Is it possible to use the register ebp in the input/output register list in 
gcc's inline assembly (for the x86 platform)? If so, how? If not, why not? I 
would like to use ebp just like the other general purpose registers, e.g. 
triggering a software interrupt 0x80 with value in eax:

__asm__ __volatile__("int $0x80"::"a" (value));

thanks for your help!
-- 


"Feel free" – 10 GB Mailbox, 100 FreeSMS/Monat ...
Jetzt GMX TopMail testen: http://www.gmx.net/de/go/topmail

Re: gcc inline assembly on x86 platform

[Mike Stump]

On Jul 14, 2006, at 4:23 PM, [EMAIL PROTECTED] wrote:
Is it possible to use the register ebp in the input/output register  
list


Wrong list.  Also, for trivial questions like this, ask the compiler,  
it will tell you.

gcc trunk vs python

[Jack Howarth]

   Has anyone tried building python 2.4.3 using gcc trunk? The current gcc 4.2
seems to introduce a new regression in the Python testsuite...

test_builtin
test test_builtin failed -- Traceback (most recent call last):
  File "/Users/howarth/Python-2.4.3/Lib/test/test_builtin.py", line 233, in 
test_divmod
(sys.maxint+1, 0))
AssertionError: (0, -2147483648) != (2147483648L, 0)

 Jack

RE:gcc trunk vs python

[Jack Howarth]

   I should have added that the gcc and python was built on MacOS X 10.4.
Jack

Re: Question about vec_extract

[James E Wilson]

On Wed, 2006-07-12 at 17:57, Ian Lance Taylor wrote:
> Personally, I think we should support operator[] for vectors.

Indeed, that was one of the most popular choices when I first brought
this topic up.  I contributed mips vector support in August 2004, and in
the multiple threads that patch spawned, there was some discussion of
this issue.

FYI there are a lot of problems with the current rtl vector support. 
Ambiguous under defined rtl operators.  Confusing, missing, undocumented
bi-endian support.  Operators that can't be generated.  Operators with
overlapping semantics, which makes canonical forms ambiguous.  Operators
that mean different things in different md files.  The whole thing is an
ugly mess.  Mostly it works because we have little or no optimizer
support, which means the vector ops don't really mean much more than
unspec does.  It needs someone to take a few steps back, write a
sensible design document, and then start auditing the code against the
design document.

I discussed some of the problems here
http://gcc.gnu.org/ml/gcc/2004-08/msg00327.html
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: why are we not using const?

[Kaveh R. Ghazi]

 > How about
 > typeof(T) const __t = (T);
 > ?
 > Ian

Oops, I didn't realize that using "typeof" preserves const-ness and
doesn't evaluate side-effects in "T".  After some quick testing it
turns out "typeof" is exactly what I needed.  I'm regtesting some
patches now.

Thanks!
--Kaveh
--
Kaveh R. Ghazi  [EMAIL PROTECTED]

Re: RFD: language hooks in GIMPLE / lang_flag?

[Mark Mitchell]

Diego Novillo wrote:
> That's relevant at the language
>> syntactic/semantic level of validing such things as parameter lists, but to
>> GIMPLE two types are compatible if and only if they would produce the
>> identical RTL.  So two integer types are compatible if they have the same
>> mode, precision, and bounds.  Two FIELD_DECLs are compatible if they have the
>> same positions, aligments, sizes, and compatible types, two record types are
>> compatible if they have the same sizes and alignment and all fields are
>> compatible.  Etc.
>>
>> The issue of debugging information is very different but I don't think in
>> the scope of this particular discussion.
>>
> Yup.  That's been the idea all along.  We represent all the FE language
> semantics in GIMPLE, much like we expose ctor/dtor in C++ or EH or any
> of the other language mechanisms.
> 
> Everything must be explicitly represented in the IL, totally independent
> from the input language.

FWIW, I agree.  However, I do not agree that two types are compatible
iff they would produce identical RTL.  GIMPLE should still know that
"int" and "long" are distinct types (even if both 32 bits) since that
permits alias analysis to do a better job.  Similarly, "struct S { int
i; }" and "struct T {int j; }" are not the same type.

So, what should happen is that the front end should make these
differences/similarities visible to the middle end via TYPE_ALIAS_SET,
or some other mechanism *in the IL itself* rather than via a callback.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: gcc visibility used by moz

[Mark Mitchell]

Jason Merrill wrote:
>
> It seems that you have a different mental model of type visibility. 

I've gotten a little lost in this thread.  Is there a clear proposal for
the semantics that we're leaning towards at this point?

One meta-note is that we're not the first people to consider this.  I
wonder if the rules beginning at page 19 (Inter-DLL symbol visibility
and linkage) of the ARM C++ ABI:

http://www.arm.com/miscPDFs/8033.pdf

might be helpful?  This is really about mapping dllexport/dllimport onto
ELF symbols, but there are some rules about how to decide whether
members of classes are exported.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> FWIW, I agree.  However, I do not agree that two types are compatible
> iff they would produce identical RTL.  GIMPLE should still know that
> "int" and "long" are distinct types (even if both 32 bits) since that
> permits alias analysis to do a better job.

Sure, but that's not what we currently use the compatible types hook for.
What you're essentially saying is that (int *) and (long *) are different
types, and that's correct.  But if we have a cast from "int" to "long"
or vice versa, that cast is not accomplishing anything and *could* be
deleted.

> Similarly, "struct S { int
> i; }" and "struct T {int j; }" are not the same type.

Likewise.  (struct T *) and (struct S *) aren't the same, but a
VIEW_CONVERT_EXPR from struct T to struct S isn't accomplishing anything
and can also be deleted.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Mark Mitchell]

Richard Kenner wrote:
>> FWIW, I agree.  However, I do not agree that two types are compatible
>> iff they would produce identical RTL.  GIMPLE should still know that
>> "int" and "long" are distinct types (even if both 32 bits) since that
>> permits alias analysis to do a better job.
> 
> Sure, but that's not what we currently use the compatible types hook for.
> What you're essentially saying is that (int *) and (long *) are different
> types, and that's correct.  But if we have a cast from "int" to "long"
> or vice versa, that cast is not accomplishing anything and *could* be
> deleted.

In RTL, sure.  In GIMPLE, I don't think so, as if you do that you lose
the type information about the result.  But, I'm not a GIMPLE expert;
maybe there's some magic way of handling this.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> In RTL, sure.  In GIMPLE, I don't think so, as if you do that you lose
> the type information about the result.  But, I'm not a GIMPLE expert;
> maybe there's some magic way of handling this.

The type of the "result" is always the type of the LHS.  Nothing would
be changing that.  And if you take the address of something, the type
of the ADDR_EXPR is the pointer type.  So I don't understand what you
mean here.  The alias set comes from the INDIRECT_REF or decl, not any
other node.

Re: RFD: language hooks in GIMPLE / lang_flag?

[Mark Mitchell]

Richard Kenner wrote:
>> In RTL, sure.  In GIMPLE, I don't think so, as if you do that you lose
>> the type information about the result.  But, I'm not a GIMPLE expert;
>> maybe there's some magic way of handling this.
> 
> The type of the "result" is always the type of the LHS. 

OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
that "int = long" would be well-formed gimple.

-- 
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
> that "int = long" would be well-formed gimple.

I thought that "type safe" meant *compatible* types ...

Re: RFD: language hooks in GIMPLE / lang_flag?

[Andrew Pinski]

On Jul 15, 2006, at 1:12 PM, Mark Mitchell wrote:

OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
that "int = long" would be well-formed gimple.


Right now it is for 32bit targets because of  
tree_ssa_useless_type_conversion_1's:

  /* If both the inner and outer types are integral types, then the
 conversion is not necessary if they have the same mode and
 signedness and precision, and both or neither are boolean.  Some
 code assumes an invariant that boolean types stay boolean and do
 not become 1-bit bit-field types.  Note that types with precision
 not using all bits of the mode (such as bit-field types in C)
 mean that testing of precision is necessary.  */
  else if (INTEGRAL_TYPE_P (inner_type)
   && INTEGRAL_TYPE_P (outer_type)
   && TYPE_UNSIGNED (inner_type) == TYPE_UNSIGNED (outer_type)
   && TYPE_PRECISION (inner_type) == TYPE_PRECISION  
(outer_type)
   && simple_cst_equal (TYPE_MAX_VALUE (inner_type),  
TYPE_MAX_VALUE (outer_type))
   && simple_cst_equal (TYPE_MIN_VALUE (inner_type),  
TYPE_MIN_VALUE (outer_type)))



Even right now we allow "int* = void*" without a cast.  I posted a patch
to fix that up at 

which I am still waiting for approval for.

Thanks,
Andrew Pinski

Re: RFD: language hooks in GIMPLE / lang_flag?

[Richard Kenner]

> OK.  But, GIMPLE is also supposed to be type-safe, so I wouldn't think
> that "int = long" would be well-formed gimple.

... or we *could* define it that way.

My point is just that whatever type "compatibility" might mean at the
GIMPLE level, it should just be a function of whether the types will produce
different code, not something at the language level.  The qustion of what
we use the compatible types test for is different.  I wasn't suggesting
(at this point at least!) that it be changed, but didn't research exactly
when it's used either.