http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
--- Comment #7 from tromey at gcc dot gnu dot org 2009-08-26 14:28 ---
Typedefs are found using lookup_name.
There is not really a separate mapping; instead the
trees are held directly in the identifier node.
These are reset as typedefs (or whatever) go out of scope,
though.
--
--- Comment #1 from dwitte at mozilla dot com 2009-08-26 02:09 ---
Created an attachment (id=18425)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18425action=view)
testcase
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
--- Comment #2 from dwitte at mozilla dot com 2009-08-26 02:13 ---
Also, this bug applies to ENUMERAL_TYPEs and UNION_TYPEs in addition to
RECORD_TYPEs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-08-26 03:18 ---
Unlike C++, C does not inject foo_t if used as struct foo_t.
So I think this is correct behavior and really does not matter.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41172
--- Comment #4 from dwitte at mozilla dot com 2009-08-26 04:25 ---
Then how does the compiler determine type equality? By looking at the variant
chain? By determining the originating type somehow? If you can point me to the
procedure it uses to do this, perhaps we can duplicate it in
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-08-26 04:28 ---
(In reply to comment #4)
Then how does the compiler determine type equality? By looking at the variant
chain?
Easy pointer equality on TYPE_MAIN_VARIANT :)
--
--- Comment #6 from dwitte at mozilla dot com 2009-08-26 05:52 ---
Well, if it's comparing two existing types, sure. :)
How does it work in the case where the parser is dealing with the declaration
|bar_t func()|, and it wants to determine if it's seen the declaration of
|bar_t|
