> We could uniquify exception names in Ada, since they have only a static
> nesting identify, not a dynamic one (e.g. the exception XYZ declared
> within a recursive procedure is the same at all levels of recursion).
>
> That would be an easy change if it would help ...
Yes, but only in Ada. I su
Eric Botcazou wrote:
> Note that the type_info object itself (_ZTIZ3foovE1S) is local. What is not
> local is the indirect reference to it through DW.ref._ZTIZ3foovE1S. So,
> while the 2 DW.ref._ZTIZ3foovE1S symbols are advertised as being identical,
> their contents would *not* be identical
Alexandre Oliva wrote:
> If the strings turn out to be identical and the linker merges them, we
> fail...
The linker should not do that. These are not random string literals;
these are the equivalent of the
static char c[12] = "..."
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916)
On Oct 28, 2005, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> In general, comparison of type_info objects is supposed to be done by
> checking for address equality of the type info strings.
> In the situation where we
> do not use strcmp, I would not expect to see that bug -- because I would
> expe
Eric Botcazou wrote:
I think it can happen for all targets that use DW_EH_PE_indirect incoding.
And it happens in Ada too because, like in C++, local exceptions are not
expected to be visible outside the compilation (translation) unit so they are
not uniquified.
We could uniquify exception
> Yes, that's wrong. I'd expect that to be a front-end bug, but if it
> doesn't happen on all platforms, then, maybe it's not?
I think it can happen for all targets that use DW_EH_PE_indirect incoding.
And it happens in Ada too because, like in C++, local exceptions are not
expected to be visi
Eric Botcazou wrote:
> .hidden DW.ref._ZTIZ3foovE1S
> .weak DW.ref._ZTIZ3foovE1S#
> .section.gnu.linkonce.s.DW.ref._ZTIZ3foovE1S,"aws",@progbits
> .align 8
> .type DW.ref._ZTIZ3foovE1S#, @object
> .size DW.ref._ZTIZ3foovE1S#, 8
> DW.ref
> This test case is valid, and the results observed are in incorrect; in
> other words, yes, there is a bug.
Thanks for confirming.
> In general, comparison of type_info objects is supposed to be done by
> checking for address equality of the type info strings. On systems
> without weak symbols,
Eric Botcazou wrote:
>>The name here would seem to imply that we *are* mangling the type
>>name: "typeinfo for foo()::S". Which begs the question of why you're
>>seeing something different for ia64.
>
>
> Both names are mangled identically (either on IA-32 or IA-64) because they
> are
> suppos
> The name here would seem to imply that we *are* mangling the type
> name: "typeinfo for foo()::S". Which begs the question of why you're
> seeing something different for ia64.
Both names are mangled identically (either on IA-32 or IA-64) because they are
supposed to be local to the translation
On Thu, Oct 27, 2005 at 11:10:10PM +0200, Eric Botcazou wrote:
> > Try again on ia32 with -fpic. That should go through
> > dw2_force_const_mem just the same.
>
> Right, but the problem doesn't trigger, probably because of the relative
> encoding:
>
> .LLSDACSE3:
> .byte 0x1
>
> I'm not sure that the C++ testcase is in fact valid. A lawyer would
> have to actually weigh in on that claim.
OK. But we have valid Ada testcases exhibiting the problem.
> Try again on ia32 with -fpic. That should go through
> dw2_force_const_mem just the same.
Right, but the problem doesn
On Thu, Oct 27, 2005 at 10:21:08PM +0200, Eric Botcazou wrote:
> We have run into an exception propagation problem on IA-64/Linux. An
> admittedly contrived C++ testcase is attached.
I'm not sure that the C++ testcase is in fact valid. A lawyer would
have to actually weigh in on
Hi,
We have run into an exception propagation problem on IA-64/Linux. An
admittedly contrived C++ testcase is attached.
[EMAIL PROTECTED]:~/EA27-007> g++ -v
Using built-in specs.
Target: ia64-sgi-linux-gnu
Configured with: /home01/botcazou/cvs/gcc/configure ia64-sgi-linux-gnu
--pre
14 matches
Mail list logo
