> 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 wil
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 a
> 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 ...
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
> 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 tak
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, bu
> 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
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
wond
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, precis
> 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!
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 spawne
I should have added that the gcc and python was built on MacOS X 10.4.
Jack
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
tes
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.
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__
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 is
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 ac
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
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, befor
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 nam
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
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),
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.
|
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 unsp
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
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 mirro
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 wha
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
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
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 function
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 t
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 n
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 f
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 d
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 ty
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 tran
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 th
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 exp
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
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
"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
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_
> "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 typ
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
>
>
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_ME
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 con
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
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
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
49 matches
Mail list logo
