From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9989 invoked by alias); 15 Jan 2003 22:46:03 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 9975 invoked by uid 71); 15 Jan 2003 22:46:02 -0000 Date: Wed, 15 Jan 2003 22:46:00 -0000 Message-ID: <20030115224602.9974.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Wolfgang Bangerth Subject: Re: c++/9313: [Mingw] Internal compiler error in rest_of_compilation, at toplev.c:3491 Reply-To: Wolfgang Bangerth X-SW-Source: 2003-01/txt/msg00987.txt.bz2 List-Id: The following reply was made to PR target/9313; it has been noted by GNATS. From: Wolfgang Bangerth To: gcc-gnats@gcc.gnu.org Cc: Subject: Re: c++/9313: [Mingw] Internal compiler error in rest_of_compilation, at toplev.c:3491 Date: Wed, 15 Jan 2003 16:36:12 -0600 (CST) ---------- Forwarded message ---------- Date: Wed, 15 Jan 2003 21:59:24 +0100 From: Bernd Becker To: Wolfgang Bangerth Subject: Re[3]: c++/9313: [Mingw] Internal compiler error in rest_of_compilation, at toplev.c:3491 Hi, << > After changing the name of the variable to DLL_BUILD the code compiled > again. I don't quite understand the conclusion: do you say I should close the report as erroneous? >> Sorry, for the confusion. The variable was named DLL_BUILD at first, then I thought I had to change it to something specific for each lib but it later became obvious that I had to use specifically named macros in each lib while the variable's name could stay the same. I therefore renamed the variable back to the original "DLL_BUILD" in the headers and the makefiles - except for the one for this project, of course. The code/data that was defined by the help of those macros therefore defined them as 'dllimport' instead of 'dllexport' as the variable it was checking didn't exist just like as if the header is included by program using the lib; meaning GCC gets told the code/data resides in an external DLL but the code/data gets defined in the .hpp/.cpp of the source read by GCC. Which is what confuses GCC, I guess. << After all, an internal compiler error is always a bug in the compiler, independent of the fact that the code that you want it to compile may be bogus. >>> You're right. And to be honest I'm not sure. This is the first time I got a compiler error. Maybe adding the symptoms and the cure in a FAQ or the known bugs list would be enough ?? It won't happen often enough to warrant to try to find a fix for this Windows specific 'problem' IMHO. cu, -- Bernd