On 03/07/2007, at 9:18 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
Yes. __attribute__((visibility)) has consistent GNU semantics, and
other features (eg. -fvisibility-ms-compat, __dllspec) match other
compilers.
Geoffrey Keating wrote:
> On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
>
>> Geoffrey Keating wrote:
>>
>>> Yes. __attribute__((visibility)) has consistent GNU semantics, and
>>> other features (eg. -fvisibility-ms-compat, __dllspec) match other
>>> compilers.
>>
>> The only semantics that make
On 03/07/2007, at 7:37 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
Yes. __attribute__((visibility)) has consistent GNU semantics, and
other features (eg. -fvisibility-ms-compat, __dllspec) match other
compilers.
The only semantics that make sense on SymbianOS are the ones that
allow
Geoffrey Keating wrote:
> Yes. __attribute__((visibility)) has consistent GNU semantics, and
> other features (eg. -fvisibility-ms-compat, __dllspec) match other
> compilers.
The only semantics that make sense on SymbianOS are the ones that allow
default visibility within a hidden class. So, wh
On 03/07/2007, at 5:13 PM, Mark Mitchell wrote:
Geoffrey Keating wrote:
GCC's concept of visibility is very different to that of some other
compilers.
Yes, and that may be a problem. For some features, we want to have
GNU
semantics that are consistent that across platforms; for others, w
Geoffrey Keating wrote:
> GCC's concept of visibility is very different to that of some other
> compilers.
Yes, and that may be a problem. For some features, we want to have GNU
semantics that are consistent that across platforms; for others, we want
to match other compilers on a particular plat
Mark Mitchell <[EMAIL PROTECTED]> writes:
> But, the visibility attribute is only specified in terms of its effects
> on ELF symbols, not as having C++ semantics per se.
[Sorry I'm so late with this reply; I've been busy and am behind on reading
mailing lists.]
The documentation for the visibili
Chris Lattner wrote:
> This description also makes sense, but is different than what was
> described before. To me, this description/implementation is extremely
> problematic, because the extension cannot be described without
> describing the implementation (specifically presence of vtables etc),
On Jun 19, 2007, at 7:49 AM, Richard Earnshaw wrote:
On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
I suspect that the realview compiler accepts
this as an oversight or a bug, not as an intentional feature.
Let's ask.
Richard E., is the fact that RealView 3.0SP1 accepts:
class _
Richard Earnshaw wrote:
> On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
>>> I suspect that the realview compiler accepts
>>> this as an oversight or a bug, not as an intentional feature.
>> Let's ask.
>>
>> Richard E., is the fact that RealView 3.0SP1 accepts:
>>
>> class __declspec(not
On Mon, 2007-06-18 at 10:04 -0700, Mark Mitchell wrote:
> > I suspect that the realview compiler accepts
> > this as an oversight or a bug, not as an intentional feature.
>
> Let's ask.
>
> Richard E., is the fact that RealView 3.0SP1 accepts:
>
> class __declspec(notshared) S {
> __declsp
Chris Lattner wrote:
>>> That is a limited view of things based on the current implementation of
>>> GCC. When future developments (e.g. LTO) occur, this will change: types
>>> certainly do live in object files.
>>
>> I don't see how LTO changes this. Yes, type definitions will appear in
>> one o
That is a limited view of things based on the current
implementation of
GCC. When future developments (e.g. LTO) occur, this will change:
types
certainly do live in object files.
I don't see how LTO changes this. Yes, type definitions will
appear in
one or more object files. But, the i
Chris Lattner wrote:
[Richard E., please see below for a question re. RealView's behavior.]
>> You and Chris are taking the view that "the type" has a location. But,
>> a lot of people don't look at it this way. The things that have
>> locations are variables (including class data) and function
On Jun 17, 2007, at 6:40 PM, Dave Korn wrote:
On 17 June 2007 18:17, Ross Ridge wrote:
Daniel Jacobowitz writes:
The minimum I'd want to accept this code would be a complete and
useful
example in the manual; since Mark and Danny say this happens a lot
on Windows
I don't understand how th
On 17 June 2007 18:17, Ross Ridge wrote:
> Daniel Jacobowitz writes:
>> The minimum I'd want to accept this code would be a complete and useful
>> example in the manual; since Mark and Danny say this happens a lot
>> on Windows
>
> I don't understand how this issue can come up at all on Windows.
Daniel Jacobowitz writes:
>The minimum I'd want to accept this code would be a complete and useful
>example in the manual; since Mark and Danny say this happens a lot
>on Windows
I don't understand how this issue can come up at all on Windows. As far
I know, visibility is an ELF-only thing, while
On Sat, Jun 16, 2007 at 10:13:34PM -0700, Chris Lattner wrote:
> Because there is no standard to reference, I think it's important to consider
> these things in terms of explainability.
Chris said everything I could have said about this (better, too). I
want to particularly highlight this part.
On Jun 16, 2007, at 11:52 AM, Mark Mitchell wrote:
Daniel Jacobowitz wrote:
This doesn't make a lick of sense to me. If the type is hidden, how
on earth can it get a member function _of that type_ from another
library? That library would, by definition, have to have a type of
the same name.
> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
> Behalf Of Mark Mitchell
> Sent: Saturday, 16 June 2007 11:47 a.m.
>
> Chris Lattner wrote:
>
> > This construct seems like it should be rejected by the C++
> front-end.
> > The source is making two contradi
Daniel Jacobowitz wrote:
> This doesn't make a lick of sense to me. If the type is hidden, how
> on earth can it get a member function _of that type_ from another
> library? That library would, by definition, have to have a type of
> the same name... but it would be a "different" type.
You and
On Jun 15, 2007, at 4:47 PM, Mark Mitchell wrote:
Chris Lattner wrote:
This construct seems like it should be rejected by the C++ front-end.
The source is making two contradictory claims: the struct is not
visible
outside this library, but part of it is implemented outside of it.
I don't th
On Fri, Jun 15, 2007 at 04:47:04PM -0700, Mark Mitchell wrote:
> data. There's no reason the members shouldn't be implemented elsewhere,
> and there's certainly existing code (in Windows, SymbianOS, and other
> DLL-based operating systems, whether or not there is on GNU/Linux) that
> implements di
Andrew Pinski wrote:
>> In any case, in practice, ARM's RealView compiler accepts:
>>
>> struct __declspec(notshared) S {
>> __declspec(dllimport) void f();
>> void g();
>> };
>>
>> void S::g() {
>> f();
>> }
>>
>> And, there's a large body of code that uses this.
>
> Because
On 6/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
So, why not:
struct S __attribute__((visibility("hidden")) {
void f();
void g() __attribute__((dllimport));
};
void S::f() { S::g(); };
In any case, in practice, ARM's RealView compiler accepts:
struct __declspec(notshared) S
Andrew Pinski wrote:
> Well this allows for easier violating of ODR. I guess I am just a bit
> off of what is going on here but I agree with Chris in that this
> really should be rejected as you have stuff which is hidden and then
> you call a non hidden member function. How can the vtable be hi
On 6/15/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
I don't think there's a contradiction. The declaration on the structure
is the default for the members and applies to the vtable and other class
data. There's no reason the members shouldn't be implemented elsewhere,
and there's certainly ex
On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote:
Bill Wendling wrote:
Perhaps I'm mistaken, but the above seems to indicate to me that the
structure (and, therefore, all of its fields) are hidden, one of its
functions is from an external and visible source.
Yes. And, therefore, emitting a u
Chris Lattner wrote:
> This construct seems like it should be rejected by the C++ front-end.
> The source is making two contradictory claims: the struct is not visible
> outside this library, but part of it is implemented outside of it.
I don't think there's a contradiction. The declaration on
On Jun 15, 2007, at 3:45 PM, Mark Mitchell wrote:
Bill Wendling wrote:
On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
Consider:
struct __attribute__((vsibility ("hidden"))) S {
void __declspec(dllimport) f();
};
At present, we give "f" hidden visibility. That seems odd since the
Bill Wendling wrote:
> On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
>
>> Consider:
>>
>> struct __attribute__((vsibility ("hidden"))) S {
>>void __declspec(dllimport) f();
>> };
>>
>> At present, we give "f" hidden visibility. That seems odd since the
>> user has explicitly told us th
On Jun 15, 2007, at 12:48 AM, Mark Mitchell wrote:
Consider:
struct __attribute__((vsibility ("hidden"))) S {
void __declspec(dllimport) f();
};
At present, we give "f" hidden visibility. That seems odd since the
user has explicitly told us that the symbol is coming from another
shared l
Consider:
struct __attribute__((vsibility ("hidden"))) S {
void __declspec(dllimport) f();
};
At present, we give "f" hidden visibility. That seems odd since the
user has explicitly told us that the symbol is coming from another
shared library.
I'm planning to make any dllimport or dlle
33 matches
Mail list logo
