public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: khan@nanotech.wisc.edu To: gcc-gnats@gcc.gnu.org Subject: c++/3395: Attribute causes type lookup to fail. Regression. Date: Mon, 25 Jun 2001 00:36:00 -0000 [thread overview] Message-ID: <20010625072858.3980.qmail@sourceware.cygnus.com> (raw) >Number: 3395 >Category: c++ >Synopsis: Attribute causes type lookup to fail. Regression. >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: rejects-legal >Submitter-Id: net >Arrival-Date: Mon Jun 25 00:36:01 PDT 2001 >Closed-Date: >Last-Modified: >Originator: Mumit Khan >Release: 3.0 >Organization: >Environment: Cygwin, Mingw and other x86-win32 targets. Host independent. >Description: See attached file. >How-To-Repeat: Just compiling the provided testcase will trigger the problem. >Fix: None known. >Release-Note: >Audit-Trail: >Unformatted: ----gnatsweb-attachment---- Content-Type: text/plain; name="gcc-bug2.txt" Content-Disposition: inline; filename="gcc-bug2.txt" The following code causes the C++ front-end to report errors where there are none. Regression from 2.95.x, and unfortunately causes most of C++ code that uses/creates windows DLL to fail. struct __attribute__((dllexport)) c { void f () const; }; inline void c::f () const { } Here's what cc1plus says: $ ./cc1plus -quiet -version dll-bug2.ii GNU CPP version 3.0 (cpplib) (80386, BSD syntax) GNU C++ version 3.0 (i686-pc-cygwin) compiled by GNU C version 3.0. dll-bug2.ii:9: prototype for `void c::f() const' does not match any in class `c' dll-bug2.ii:4: candidate is: void c::f() const The problem happens when parsing the definition of c::f. PARSER -> ... -> check_classfn -> compparms -> same_type_p returns 0. See notes marked with >>>> and ^^^^^ below. Putting the attribute *before* the class/struct causes no errors, but that's not consistent with existing code. (gdb) b check_classfn (gdb) run dll-bug2.ii Starting program: /homes/khan/src/win32/cygwin/BUILD/orig-gcc3/gcc/cc1plus dll-bug2.ii Breakpoint 4, check_classfn (ctype=0x401715b0, function=0x40175888) at /home/khan/src/gnu/gcc-3.0/gcc/cp/decl2.c:1364 1364 tree fn_name = DECL_NAME (function); (gdb) b compparms Breakpoint 10 at 0x80bdbd6: file /home/khan/src/gnu/gcc-3.0/gcc/cp/typeck.c, line 1445. (gdb) c Continuing. Breakpoint 10, compparms (parms1=0x40174370, parms2=0x40174078) at /home/khan/src/gnu/gcc-3.0/gcc/cp/typeck.c:1445 1445 register tree t1 = parms1, t2 = parms2; (gdb) bt #0 compparms (parms1=0x40174370, parms2=0x40174078) at /home/khan/src/gnu/gcc-3.0/gcc/cp/typeck.c:1452 <<<< NOTE: parms1 and parms2 are different! Also, see note below, <<<< where TREE_VALUE (parms1) and TREE_VALUE (parms2) are different <<<< so that same_types_p returns 0. #1 0x809849a in check_classfn (ctype=0x401715b0, function=0x40175888) at /home/khan/src/gnu/gcc-3.0/gcc/cp/decl2.c:1432 #2 0x80662f8 in grokfndecl (ctype=0x401715b0, type=0x401717b8, declarator=0x401640c0, orig_declarator=0x401640c0, virtualp=0, flags=NO_SPECIAL, quals=0x40174320, raises=0x0, check=1, friendp=0, publicp=1, inlinep=1, funcdef_flag=1, template_count=0, in_namespace=0x0) at /home/khan/src/gnu/gcc-3.0/gcc/cp/decl.c:8987 #3 0x806ba2d in grokdeclarator (declarator=0x401640c0, declspecs=0x401742e4, decl_context=NORMAL, initialized=1, attrlist=0x0) at /home/khan/src/gnu/gcc-3.0/gcc/cp/decl.c:11605 #4 0x806fc8a in start_function (declspecs=0x401742e4, declarator=0x40167880, attrs=0x0, flags=0) at /home/khan/src/gnu/gcc-3.0/gcc/cp/decl.c:13334 #5 0x80df16c in begin_function_definition (decl_specs=0x401742e4, declarator=0x40167880) at /home/khan/src/gnu/gcc-3.0/gcc/cp/semantics.c:1614 #6 0x80aabf1 in yyparse_1 () at /usr/lib/bison.simple:804 #7 0x80fd26d in yyparse () at /home/khan/src/gnu/gcc-3.0/gcc/c-lex.c:158 #8 0x81026e3 in compile_file (name=0x844f207 "dll-bug2.ii") at /home/khan/src/gnu/gcc-3.0/gcc/toplev.c:2369 #9 0x81069c6 in main (argc=2, argv=0xbffff704) at /home/khan/src/gnu/gcc-3.0/gcc/toplev.c:4990 (gdb) p parms1 (gdb) pt <tree_list 0x40174370 side-effects value <pointer_type 0x40175958 ^^^^^^^^^^ (1) type <record_type 0x40171d00 c readonly type_1 type_5 QI size <integer_cst 0x4015e400 constant 8> unit size <integer_cst 0x4015eac0 constant 1> user align 8 symtab 0 alias set -1 attributes <tree_list 0x401740b4 purpose <identifier_node 0x40170380 dllexport bindings <binding 0x40163f14 scope 0x40162000>>> fields <type_decl 0x401716e8 c> X() X(constX&) this=(X&) n_parents 0 use_template=0 interface-unknown vtable-needs-writing member-functions <tree_vec 0x40170f00 elt 0 <overload 0x40173450> elt 2 <function_decl 0x40175270 operator=> elt 3 <overload 0x40173490> elt 4 <overload 0x40173470> elt 5 <function_decl 0x40171820 f>> pointer_to_this <pointer_type 0x40175958> reference_to_this <reference_type 0x40171d68>> unsigned SI size <integer_cst 0x4015eb20 constant 32> unit size <integer_cst 0x4015eb40 constant 4> align 32 symtab 0 alias set -1> chain <tree_list 0x40163668 tree_2 value <void_type 0x401656e8 void type_6 VOID align 8 symtab 0 alias set -1 pointer_to_this <pointer_type 0x40165750>>>> (gdb) p parms2 $9 = 0x40174078 (gdb) pt <tree_list 0x40174078 side-effects value <pointer_type 0x40171958 ^^^^^^^^^^ (2) See (1) above. type <record_type 0x40171888 c type <tree_list 0x40163f28 purpose <identifier_node 0x40170380 dllexport bindings <binding 0x40163f14 scope 0x40162000>>> readonly type_1 type_5 QI size <integer_cst 0x4015e400 constant 8> unit size <integer_cst 0x4015eac0 constant 1> user align 8 symtab 0 alias set -1 fields <type_decl 0x401716e8 c> X() X(constX&) this=(X&) n_parents 0 use_template=0 interface-unknown vtable-needs-writing member-functions <tree_vec 0x40170f00 elt 0 <overload 0x40173450> elt 2 <function_decl 0x40175270 operator=> elt 3 <overload 0x40173490> elt 4 <overload 0x40173470> elt 5 <function_decl 0x40171820 f>> pointer_to_this <pointer_type 0x40171958>> unsigned SI size <integer_cst 0x4015eb20 constant 32> unit size <integer_cst 0x4015eb40 constant 4> align 32 symtab 0 alias set -1> chain <tree_list 0x40163668 tree_2 value <void_type 0x401656e8 void type_6 VOID align 8 symtab 0 alias set -1 pointer_to_this <pointer_type 0x40165750>>>> (gdb)
next reply other threads:[~2001-06-25 0:36 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2001-06-25 0:36 khan [this message] 2001-07-11 18:20 rodrigc 2001-07-12 5:08 rodrigc 2001-08-12 7:45 lerdsuwa 2002-02-01 3:57 jason
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=20010625072858.3980.qmail@sourceware.cygnus.com \ --to=khan@nanotech.wisc.edu \ --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).