public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: mps@sonartech.com.au To: gcc-gnats@gcc.gnu.org Subject: c++/1738: template function with volatile formal parameter confuses compiler Date: Sun, 01 Apr 2001 00:00:00 -0000 [thread overview] Message-ID: <20010123025456.28984.qmail@sourceware.cygnus.com> (raw) >Number: 1738 >Category: c++ >Synopsis: template function with volatile formal parameter confuses compiler >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: rejects-legal >Submitter-Id: net >Arrival-Date: Mon Jan 22 18:56:00 PST 2001 >Closed-Date: >Last-Modified: >Originator: Michael Shepanski >Release: 2.95.2 19991024 >Organization: >Environment: AIX power-pc >Description: template <class T> void f (volatile T x) {} main () { volatile int *vip = 0; // the following instantiation of f should // have T="int *", and therefore have a // formal parameter type of "volatile int *", // which matches the actual parameter. // So why does g++ reject it? f<int *> (vip); } >How-To-Repeat: Compile the code given in the "Description:" box. >Fix: Please >Release-Note: >Audit-Trail: >Unformatted: >From pedwards@disaster.jaj.com Sun Apr 01 00:00:00 2001 From: Phil Edwards <pedwards@disaster.jaj.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org Subject: Re: c++/1571: g++ is confused with by code that typedef's wchar_t. Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010107050600.2279.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg00070.html Content-length: 1095 The following reply was made to PR c++/1571; it has been noted by GNATS. From: Phil Edwards <pedwards@disaster.jaj.com> To: cgd@sibyte.com Cc: gcc-gnats@gcc.gnu.org, don@pixstream.com Subject: Re: c++/1571: g++ is confused with by code that typedef's wchar_t. Date: Sun, 7 Jan 2001 00:07:22 -0500 On Sat, Jan 06, 2001 at 01:37:55AM -0000, cgd@sibyte.com wrote: > >Description: > g++ seems to to mishandle code which typedef's wchar_t, > emitting an error when none is appropriate. Sure it's appropriate. In C++, wchar_t is a builtin type, like 'int' and 'char'. You can't typedef it. > (Several of NetBSD's headers typedef wchar_t as > appropriate.) For C, wchar_t is typedef'd, but not for C++. There should be conditional complication guards around such typedefs, e.g., #ifndef __cplusplus typedef wchar_t int; #endif -- pedwards at disaster dot jaj dot com | pme at sources dot redhat dot com devphil at several other less interesting addresses in various dot domains The gods do not protect fools. Fools are protected by more capable fools. >From etienne.lorrain@masroudeau.com Sun Apr 01 00:00:00 2001 From: etienne.lorrain@masroudeau.com To: gcc-gnats@gcc.gnu.org Subject: c/1995: position dependency in asm("" : ... : : ) Date: Sun, 01 Apr 2001 00:00:00 -0000 Message-id: <20010215101145.3117.qmail@sourceware.cygnus.com> X-SW-Source: 2001-q1/msg01302.html Content-length: 1687 >Number: 1995 >Category: c >Synopsis: position dependency in asm("" : ... : : ) >Confidential: no >Severity: serious >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Thu Feb 15 02:16:01 PST 2001 >Closed-Date: >Last-Modified: >Originator: Etienne LORRAIN >Release: unknown-1.0 >Organization: >Environment: gcc version 2.97 20010212 on i386/Linux (www.codesourcery.com) for "inconsistent operand constraints in an `asm'" Seen with error "asm too many reload" on gcc-2.95-2 >Description: Compile with or without -DASM_TOO_MANY_RELOAD, _and_ with at least -O for inlines, this code (the only difference is that the "+r" parameter is the last output or not): extern unsigned dummy; unsigned dummyfct (unsigned); extern inline unsigned xchgl (unsigned adr, unsigned value) { unsigned short scratch; #ifdef ASM_TOO_MANY_RELOAD asm volatile (" pushl %2 popw %w0 popw %%fs xchgl %%fs:(%w0),%1 " : "=bSDB" (scratch), "+r" (value) : "g" (adr) : "memory"); #else asm volatile (" pushl %2 popw %w1 popw %%fs xchgl %%fs:(%w1),%0 " : "+r" (value), "=bSDB" (scratch) : "g" (adr) : "memory"); #endif return value; } unsigned fct (unsigned irq, unsigned fct_faradr) { if (dummy) return dummyfct (irq); else return xchgl (4*irq, fct_faradr); } >How-To-Repeat: http://www.codesourcery.com/cgi-bin/gcc-compile.py See compiler messages, with: "-O -DASM_TOO_MANY_RELOAD" or "-O" >Fix: >Release-Note: >Audit-Trail: >Unformatted:
reply other threads:[~2001-04-01 0:00 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20010123025456.28984.qmail@sourceware.cygnus.com \ --to=mps@sonartech.com.au \ --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).