public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: c++/9313: [Mingw] Internal compiler error in rest_of_compilation, at toplev.c:3491
@ 2003-01-15 22:46 Wolfgang Bangerth
  0 siblings, 0 replies; 2+ messages in thread
From: Wolfgang Bangerth @ 2003-01-15 22:46 UTC (permalink / raw)
  To: nobody; +Cc: gcc-prs

The following reply was made to PR target/9313; it has been noted by GNATS.

From: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
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 <munin@munin.inka.de>
 To: Wolfgang Bangerth <bangerth@ticam.utexas.edu>
 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
 


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: c++/9313: [Mingw] Internal compiler error in rest_of_compilation, at toplev.c:3491
@ 2003-01-14 23:45 bangerth
  0 siblings, 0 replies; 2+ messages in thread
From: bangerth @ 2003-01-14 23:45 UTC (permalink / raw)
  To: gcc-bugs, gcc-prs, munin, nobody

Old Synopsis: "Internal compiler error in rest_of_compilation, at toplev.c:3491"
New Synopsis: [Mingw] Internal compiler error in rest_of_compilation, at toplev.c:3491

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Tue Jan 14 15:45:13 2003
State-Changed-Why:
    Not reproducible on Linux (no surprise). Can you say which
    version of gcc you used (I assume a present CVS snapshot),
    and with which flags you compiled the file?
    
    Thanks
      Wolfgang

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9313


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2003-01-15 22:46 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-01-15 22:46 c++/9313: [Mingw] Internal compiler error in rest_of_compilation, at toplev.c:3491 Wolfgang Bangerth
  -- strict thread matches above, loose matches on Subject: below --
2003-01-14 23:45 bangerth

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).