public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: igusarov@mail.ru To: gcc-gnats@gcc.gnu.org Subject: c++/10332: Template classes are not instantiated correctly in presense of #pragma pack() Date: Mon, 07 Apr 2003 10:46:00 -0000 [thread overview] Message-ID: <20030407104517.22702.qmail@sources.redhat.com> (raw) >Number: 10332 >Category: c++ >Synopsis: Template classes are not instantiated correctly in presense of #pragma pack() >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Mon Apr 07 10:46:02 UTC 2003 >Closed-Date: >Last-Modified: >Originator: Akella corp. >Release: 3.2 >Organization: >Environment: System: FreeBSD gate.studio1001.akella.ru 4.4-RELEASE FreeBSD 4.4-RELEASE #11: Thu Jun 6 12:58:54 host: i386-unknown-freebsd4.4 build: i386-unknown-freebsd4.4 target: i386-unknown-freebsd4.4 configured with: /usr/src/gcc-3.2/configure --prefix=/usr >Description: The packing size used for class template instantiation is set by the #pragma pack directive which is in effect at the point of template instantiation (whether implicit or explicit), rather then by the #pragma pack directive which was in effect at the point of class template definition. This is not a correct behaviour, because in a complex program it's hard to control the point of implicit instantiation of any given template class. And the wrong packing size is leading to incorrect code generation if a given template class was instantiadet with different packing sizes in different translation units. Consider the code examples in Howtorepeat section. Related problem reports: other/4957 >How-To-Repeat: 1. Try to compile and run the following example (all code examples in this report could be compiled with "g++ file.cpp", no special command-line options are required) //---------------------------- begin example #include <stdio.h> #pragma pack(4) template <typename X > struct T { char x1; /* Usually 3 padding bytes are added after x1 member. */ int x2; }; #pragma pack(1) template T<int>; /* T<int> is instantiated here */ #pragma pack(4) template T<float>; /* T<float> is instantiated here */ int main() { printf("sizeof T<int> = %d\n", sizeof(T<int>)); printf("sizeof T<float> = %d\n", sizeof(T<float>)); } //---------------------------- end example (parameter types 'int' and 'float' are not used in any way, they are required just to separate two template instances) The output is: sizeof T<int> = 5 sizeof T<float> = 8 Which shows that the size (and member offsets) of the template class depends on the #pragma pack at place of instantiation. 2. There is a more complicated example which shows how to trigger this bug accidently. Unpack the attached archive and compile two sample translation units (tu01.cpp and tu02.cpp) in alignment_bug/case_02 directory. The only difference between these translation units is the order of #include directives which causes different implicit instantiation of the same template class (include guards are skipped in such simple case). This test case repeats the behaviour reported in other/4957. >Fix: Do not rely on implicit instantiation. Instantiate all desired template classes explicitly (sic!). >Release-Note: >Audit-Trail: >Unformatted: ----gnatsweb-attachment---- Content-Type: application/x-compressed; name="alignment_bug_02.tgz" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="alignment_bug_02.tgz" H4sIAGdSkT4AA+1ZXWvbMBTNs3/FJWWQlJFa8hcsXWHsuWywFvYwKIqtJGb+wpa7eqX/fVe2kziJ s4zNdVir85BE0tW9cq7Psa7FAn8RhTwSd7N8cTF4FoCpO5YFAwDiWER+I/T6u26AY5smNR3LsdCM Og4dgPU8y9lGngmWAgz8RZ6xNL4/ZPdjyXnQx4L6BdvKv8syfqeTju+DP8+/RQhx0Mwkjq7y3wfa 888fWJgEfOImSQcxiK5jcg/n37acFf8x7xTNbJMYA9A7iH0Urzz/Z37kBrnH4TITnh9Plleadpak bBEySJj7fWSONU1wvBuYQCNRJDxiIYevcKVlIs1dATfaoybT6C7lHynxQKb4eXEOt1nOgqAAA315 nh8tYFYIngFLOWAH94DNBU9xAoQ8nPF0AucXpTM/EvXd8UCn2tN0Z1VkvFnUzSUaX9URqwb4GXrA zEbCRxMPlhwjouu9a2t4mQcxk35KL1XjsB+5vpD50Wgsrz5JsT0fDTP/J4/nq0UAvIc33rdo+Baq gVE1MB5PW6bUEfenVANy0pPWef7b+E9Pqf+UlPpvm0r/+0B7/kWuk47Ef3Bc/6ltrPOPpmhmWSZR +t8HWvR/3TUMCzdgWTZZDrVGr09kR6NNdwzCIhYolJu5vxPL0XXxSVp/lNbjPfnbGi0lsHsNfM04 yH96Iv4TWvLfcBT/+8Df8J/u8J8o/v+3aOf/OvGdxDjGf2Kt+a9TYsj6T7ctxf8+0FbarSu766Lk 3U59h9XdVokmC7StcWNn3KwKuFNfqkILDvG/qeD/GuMY/8Gma/4TU77/cwgxFf/7wIbqm+esBu8g yWeB764UoHxtgTKgaPzS0M5/uaXrLsZR/lvr9z+6I3+jCOjq+d8LcG8e+BHX7mPf0+ZxPGoyHj6k C7llV5vuF4sD/Kd98p8a5ob/Rnn+56j6vx/snqqUWz587H/GNve+lJuDev/fOOAB8OoioHFQg51Y Cax6papUvdvO9gUGHp/KAmHv2OnU/42CgoKCgsJLxS9RufPqACgAAA==
next reply other threads:[~2003-04-07 10:46 UTC|newest] Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top 2003-04-07 10:46 igusarov [this message] 2003-04-11 1:16 ljrittle 2003-04-11 11:46 Igor A. Goussarov 2003-04-11 13:56 Momchil Velikov 2003-04-14 8:56 Igor A. Goussarov 2003-04-14 9:06 Momchil Velikov 2003-04-14 10:06 Igor A. Goussarov 2003-04-14 23:46 Loren James Rittle 2003-04-15 13:46 Igor A. Goussarov
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20030407104517.22702.qmail@sources.redhat.com \ --to=igusarov@mail.ru \ --cc=gcc-gnats@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).