Gabriel Dos Reis wrote:
>> Joe Buck wrote:
Now, this being a conscious decision for ODR violation, it would
probably need to be documented because then we may have
typeinfo1 != typeinfo2
and yet
!typeinfo1.before(typeinfo2) && !typeinfo2.before(typeinfo1)
There are probably other incon
Daniel Jacobowitz wrote:
I just don't get it. Why should it matter whether a member function is
virtual or not in order to be able to call it from outside this shared
object? Either you can access the public members of the class, or you
can't. Being able to access some of them and get link err
This is repost of my slightly earlier post, with a critical and
confusing misstatement corrected.
Well, I agree with what you said about your example, but it's not what
I am meaning. See below.
Ian Lance Taylor wrote:
"Rodney M. Bates" <[EMAIL PROTECTED]> writes:
I don't understand this.
Tristan Wibberley <[EMAIL PROTECTED]> writes:
> But I think it is important that there are three places where
> visibility is a factor (as a concept of "being able to see things"
> rather than the attribute).
I think it would help if you wrote down the rules for the visibility
attributes as appli
That said, I'm not happy with a builtin function. I think that we
should make every effort to make
union { TYPE a[COUNT]; VECTOR v; } u;
u.v = v;
x = u.a[0];
use vec_extract, because in the absence of operator[] that is the
natural way for people to extract an element from a vector.
Jim Wilson <[EMAIL PROTECTED]> writes:
> Andrew Pinski wrote:
> > I have been trying to figure out when the pattern vec_extract is
> > invoked.
>
> I looked at this when I worked on the mips simd support. In
> config/mips/mips-ps-3d.md I wrote
> ;; ??? This is only generated if we perform a vect
Gabriel Dos Reis wrote:
Tristan Wibberley <[EMAIL PROTECTED]> writes:
[...]
| I am suggesting that visibility attributes should *not* touch the C++
| type system in any way.
But then, at the same time you're talking of polymorphic types
(e.g. vtables).
vtables happen to just work with typ
Gabriel Dos Reis wrote:
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
| > 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
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
Joe Buck <[EMAIL PROTECTED]> writes:
| On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
| > 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
On Thu, Jul 13, 2006 at 01:36:46AM +0200, Gabriel Dos Reis wrote:
> 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?
Well, there are
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
| lin
Gabriel Dos Reis wrote:
Tristan Wibberley <[EMAIL PROTECTED]> writes:
| Mike Stump wrote:
| > On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
| >> "the client code needs to know about the existence of this type so
| >> it can get pointers and references to instances and pass them back
| >
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 i
Tristan Wibberley <[EMAIL PROTECTED]> writes:
[...]
| I am suggesting that visibility attributes should *not* touch the C++
| type system in any way.
But then, at the same time you're talking of polymorphic types
(e.g. vtables).
| Since C++ doesn't have a notion of module a
| class that the C
Tristan Wibberley <[EMAIL PROTECTED]> writes:
| Mike Stump wrote:
| > On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
| >> "the client code needs to know about the existence of this type so
| >> it can get pointers and references to instances and pass them back
| >> in later and maybe be ab
Well, I agree with what you said about your example, but it's not what
I am meaning. See below.
Ian Lance Taylor wrote:
"Rodney M. Bates" <[EMAIL PROTECTED]> writes:
I don't understand this. A pointer to anywhere in an activation record
(or even outside it, if outside by a fixed offset) all
Jason Merrill wrote:
OK, you've convinced me that the compiler shouldn't override or complain
about explicit visibility attributes. Do you have a problem with
implicit propagation of visibility in the absence of an attribute?
Specifically:
Do you agree with implicitly giving template instan
(copying your mail to the gcc mailing list again)
Benjamin Smedberg wrote:
Jason Merrill wrote:
It seems that you have a different mental model of type visibility.
The way I was thinking about it, if a type has hidden visibility, we
can't refer to it from outside its object. Thus, it doesn'
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 07:49:21PM +0100, Tristan Wibberley wrote:
No, that's why we need programmer provided attributes. The programmer says:
"the client code needs to know about the existence of this type so it
can get pointers and references to instances and pass th
Gabriel Dos Reis wrote:
Tristan Wibberley <[EMAIL PROTECTED]> writes:
| The programmer says:
|
| "the client code needs to know about the existence of this type so it
| can get pointers and references to instances and pass them back in
| later and maybe be able to call virtual member functio
Mike Stump wrote:
On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
"the client code needs to know about the existence of this type so it
can get pointers and references to instances and pass them back in
later and maybe be able to call virtual member functions and access
non-static membe
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
If the programmer had intended that the type should appear to not exist.
it wouldn't be defined in a header #include-able by client code. The
GCC doesn't know if the header is includable by client code
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
[...]
| I just don't get it. Why should it matter whether a member function is
| virtual or not in order to be able to call it from outside this shared
| object? Either you can access the public members of the class, or you
| can't. Being able to a
Tristan Wibberley <[EMAIL PROTECTED]> writes:
| Daniel Jacobowitz wrote:
| > On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
| >> If the programmer had intended that the type should appear to not
| >> exist. it wouldn't be defined in a header #include-able by client
| >> code. T
On Jul 12, 2006, at 11:49 AM, Tristan Wibberley wrote:
"the client code needs to know about the existence of this type so
it can get pointers and references to instances and pass them back
in later and maybe be able to call virtual member functions and
access non-static members" by putting i
On Wed, Jul 12, 2006 at 07:49:21PM +0100, Tristan Wibberley wrote:
> No, that's why we need programmer provided attributes. The programmer says:
>
> "the client code needs to know about the existence of this type so it
> can get pointers and references to instances and pass them back in later
>
Richard Kenner wrote on 07/12/06 14:33:
>> I don't understand what you are exactly trying to do, but I guess you
>> want to "virtualize" the lang-hooks? The proper way to get rid of them
>> is to encode the information they provide in the IL, not to encode the
>> source language in the trees.
>
>
I'm taking the wiki down for a few days because
1. It's getting attacked again, and the current software doesn't make
fixing this easy.
2. I'm currently not at home, and have a lot of meetings, so i probably
won't finish converting it until i get back home. :)
Sorry about this.
--Dan
Daniel Jacobowitz wrote:
On Wed, Jul 12, 2006 at 02:04:37AM +0100, Tristan Wibberley wrote:
If the programmer had intended that the type should appear to not exist.
it wouldn't be defined in a header #include-able by client code. The
GCC doesn't know if the header is includable by client code
Andrew Pinski wrote:
I have been trying to figure out when the pattern vec_extract is
invoked.
I looked at this when I worked on the mips simd support. In
config/mips/mips-ps-3d.md I wrote
;; ??? This is only generated if we perform a vector operation that has
to be
;; emulated. There is n
> I don't understand what you are exactly trying to do, but I guess you
> want to "virtualize" the lang-hooks? The proper way to get rid of them
> is to encode the information they provide in the IL, not to encode the
> source language in the trees.
I strongly agree and was going to say so in res
On 7/12/06, Joern RENNECKE <[EMAIL PROTECTED]> wrote:
As was discussed at the summit, we'd like to get rid of global language
callbacks so that we can
safely inline from different source languages.
AFAICS, this can be archived by using the space occupied by the
lang_flags to store a language
tag
> Benjamin Kosnik writes:
>> My patch to fix this isn't at all obvious that it is correct to me.
>> There are no signs that it will be reviewed anytime soon,
Benjamin> That's because you've buried it in an SOS message about bootstrap
Benjamin> breaking.
Benjamin> Please post your patch o
> My patch to fix this isn't at all obvious that it is correct to me.
> There are no signs that it will be reviewed anytime soon,
That's because you've buried it in an SOS message about bootstrap
breaking.
Please post your patch on gcc-patches with a sane and descriptive
subject, and put also
Hi Ulrich.
Few months ago I has analyzed PR19636 (avr specific bug) and found
that it's a reload related problem. I has started the thread
http://gcc.gnu.org/ml/gcc/2006-02/msg00213.html but nobody commented the
problem.
Can you comment the problem as reload maintainer ?
Denis.
As was discussed at the summit, we'd like to get rid of global language
callbacks so that we can
safely inline from different source languages.
AFAICS, this can be archived by using the space occupied by the
lang_flags to store a language
tag in each tree node.
I.e., while the frontend does pro
On Jul 11, 2006, at 10:58 AM, Benjamin Kosnik wrote:
I don't know what to do about the ICE: it looks like Mike has a patch.
My patch to fix this isn't at all obvious that it is correct to me.
There are no signs that it will be reviewed anytime soon, so, I'd say
please revert the patch that
On Jul 12, 2006, at 10:04 AM, Tristan Wibberley wrote:
This isn't "type" visibility. Shared objects don't export "types"
they export "symbols". The types are defined in headers and are
thus known to exist - no visibility attributes will or should
change that.
Actually in C++, they are e
Andrew Pinski wrote:
I have been trying to figure out when the pattern vec_extract is
invoked. I understand it is invoked from extract_bit_field but I
don't see how it can be invoked. For both SSE and altivec I have
tried the following code (which I thought would cause vec_extract
pattern to be
I have been trying to figure out when the pattern vec_extract is
invoked. I understand it is invoked from extract_bit_field but I
don't see how it can be invoked. For both SSE and altivec I have
tried the following code (which I thought would cause vec_extract
pattern to be called) but on both,
41 matches
Mail list logo
