middle-end/6418: mangle.c #2199 (GCC3.04) - Emits *INTERNAL* when handling weak defined templates con- and destructors

msk@ignlabs.com msk@ignlabs.com
Tue Apr 23 05:23:00 GMT 2002


>Number:         6418
>Category:       middle-end
>Synopsis:       mangle.c #2199 (GCC3.04) - Emits *INTERNAL* when handling weak defined templates con- and destructors
>Confidential:   no
>Severity:       critical
>Priority:       medium
>Responsible:    unassigned
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue Apr 23 04:56:02 PDT 2002
>Closed-Date:
>Last-Modified:
>Originator:     IGNLabs OSResearch - DK
>Release:        3.00 - 3.04
>Organization:
>Environment:
Linux IA32 RH6.2-
>Description:
mangle.c outputs *INTERNAL* into assembler file weak sections, when handling weak defined template constructors and destructors in line 2199 (3.04) - write_string(" *INTERNAL* "); Only con- and destructors are affected. With no support for the export keyword this flaw is fatal when building libraries which uses common templates defined in headers.
>How-To-Repeat:
Make a derivative of UX2ListNode in a c++ file, and try to compile it. Now examine the assembler output - The weak sections at the end of it will contain: 
.weak "mangled constructorname" *INTERNAL* 
.weak "mangled destructorname" *INTERNAL* 
>Fix:
The comment above line 2199 in mangle.c states that the "*INTERNAL*" information should not be placed in the resulting assembler code, but it manages to end up in the asm code somehow. A quick fix is to change *INTERNAL* to #*INTERNAL* - The "not suppossed to be there statement" will now appear as comment to the assembler - not actually a fix to the problem, but a working for the moment solution.
>Release-Note:
>Audit-Trail:
>Unformatted:
----gnatsweb-attachment----
Content-Type: application/octet-stream; name="temptest.hpp"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="temptest.hpp"

I2RlZmluZSBGVU5DX1dFQUsoeCkgeCBfX2F0dHJpYnV0ZV9fKCh3ZWFrKSkKCnRlbXBsYXRlPGNs
YXNzIE4+IGNsYXNzIFVYMkxpc3ROb2Rlewpwcml2YXRlOgogIE4qIHByZXZpb3VzTm9kZTsKICBO
KiBuZXh0Tm9kZTsKcHJvdGVjdGVkOgpwdWJsaWM6CiAgRlVOQ19XRUFLKFVYMkxpc3ROb2RlKHZv
aWQpKTsKICBGVU5DX1dFQUsodm9pZCBzZXROZXh0KE4qIE5leHQpKTsKICBGVU5DX1dFQUsodm9p
ZCBzZXRQcmV2KE4qIFByZXYpKTsKICBGVU5DX1dFQUsoTiogZ2V0TmV4dCh2b2lkKSBjb25zdCk7
CiAgRlVOQ19XRUFLKE4qIGdldFByZXYodm9pZCkgY29uc3QpOwogIEZVTkNfV0VBSyh2aXJ0dWFs
IH5VWDJMaXN0Tm9kZSgpKTsKfTs=



More information about the Gcc-bugs mailing list