RE: Why doesn't libgcc define _chkstk on MinGW?

[Danny Smith]

[Resend]
From: Mark Mitchell
Sent: Saturday, 4 November 2006 9:28 a.m.
> 
> I recently tried to use a MinGW GCC (built from FSF sources) to link 
> with a .lib file that had been compiled with MSVC, and got link-time 
> errors about _chkstk.  After some searching, I understand what this 
> function is for (it's a stack-probing thing that MSVC generates when 
> allocating big stack frames), and that GCC has an equivalent 
> in libgcc 
> (called _alloca).  There also seems to be widespread belief 
> that in fact 
> the libgcc routine is compatible with _chkstk.  

That's what my experience indicates.

And, there 
> are lots of 
> people that have reported link failures involving _chkstk.
> 
> So, my (perhaps naive) question is: why don't we define _chkstk as an 
> alias for _alloca in MinGW, so that we can link with these 
> MSVC libraries?
> 

I have also run into converse problem -- using GCC-compiled static libs
in MSVC projects
and getting an undefined reference to libgcc's _alloca.

Now there is an _alloca exported from win32api libs, but it really is
alloca rather than
a helper function _alloca_probe/_chkstk, so libgcc's symbol does have an
unfortunate name.


I see no reason why we can't use more MSVC-compatible aliases.
 
Danny


> Thanks,
> 
> -- 
> Mark Mitchell

RE: [PATCH] trivial fix for typo in gcc/configure.ac

[Danny Smith]

> 
> 2006-11-06  Jan van Dijk  <[EMAIL PROTECTED]>
> 
>   * configure.ac: Fixed typo in case statement: :: changed to ;;
> 


Sorry, that was my typo.  I have committed your patch, with additional 
  * configure: Regenerate.

as obvious.  Thanks.

Danny

RE: symbol names are not created with stdcall syntax: MINGW, (GCC) 4.3.0 20061021

[Danny Smith]

> 
> On mingw, I get the following:
> 
> $ cat a.c
> int foo(int x) { return x+1; }
> $ gcc.exe -mrtd a.c -shared -o a.dll
> $ nm a.dll | grep foo
> 100011c0 T _foo
> 
> $ cat b.c
> int __stdcall foo(int x) { return x+1; }
> $ gcc.exe b.c -shared -o b.dll
> $ nm b.dll | grep foo
> 100011c0 T [EMAIL PROTECTED]
> $ gcc.exe b.c -shared -o b.dll -mrtd
> $ nm b.dll | grep foo
> 100011c0 T [EMAIL PROTECTED]
> 
> I think -mrtd doesn't change the name. 

Correct.

Maybe GCC needs another option
> to add the name decoration automatically? CCing the GCC list and Danny
> S. for this question.
> 

IMO, anybody who uses -mrtd (with or without decorations) is asking for
trouble.
Unless you are planning to use a gfortran dll in a VisualBasic app, I
can see little reason to change from the default "C" calling convention.


Danny

> FX
> 

RE: Is "FTZ/DAZ for SSE via fast math" available for x86 arch other than Linux?

[Danny Smith]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Zuxy Meng
> Sent: Wednesday, 7 March 2007 12:36 a.m.

> 
> I've uploaded a proposed patch for this bug 
> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13151&action=diff).
> Putting 
> crtfastmath.o in the endfile section of specs causes undefined
reference to 
> memset, so I moved it to the startfile section. Anyone to review this?
Quite 
> trivial anyway.

Hello Zuxy, 

crtfasmath.o is an endfile for a reason.  _set_fast_math is run from the
.ctors section.  It needs to be run before other constructors that might
use fastmath, so is made an end ctor (ctors are run from right to left).

The reference to memset does not occur on trunk with  optimization.  It
can be avoided with 4.2.0 by adding -minline-all-stringops to rule for
(T)crtfastmath.o 


Danny
-- 
Zuxy 

RE: i386: Problems with references to import symbols.

[Danny Smith]

Richard Henderson wrote
> On Wed, Mar 21, 2007 at 04:16:20PM -, Dave Korn wrote:
> >   Presumably there would be no problem in just waiting 
> until runtime to
> > initialise the my_malloc_hook variable dynamically instead 
> of trying to
> > statically initialise it?
> 
> Dunno.  One could also wait to expand *__imp_foo, for functions,
> until expanding the function call.  And then this variable would
> receive the address of the import library thunk.
> 
> What does VC++ do?  I'm mostly wondering about what pointer 
> equality guarantees we can make.
> 
> 
For code like this

extern __declspec(dllimport)  void foo();
void Bar() { return foo();}
void (* pfn_myfoo)(void) = foo;
void my_Bar() { return *pfn_myfoo();}

VC++6  uses the __imp__foo reference to resolve the call in Bar, but 
an  import lib thunk  _foo to resolve pfn_myfoo and the call in  my_Bar.



The mingw/cygwin workaround has been to add -mno-fun-dllimport to
command line to avoid the problem.

Danny


> r~
> 

Re: Failure building Ada on i686-pc-mingw32

[Danny Smith]

> Ada fails in stage1; the offender is gnatbind.exe. It crashes even if invoked
with no command-line arguments. > Gdb provides the following information:
>
>
> ( gdb) run
> Starting program: C:\gcc401install\gccbuild\gcc\stage1/gnatbind.exe

>Program received signal SIGSEGV,
> Segmentation fault.
> 0x004034b7 in __gnat_install_SEH_handler (ER=0x)
> at ../../gcc-4.0.1/gcc/ada/seh_init.c:219
> 219 ((int *)ER)[0] = (int)ptr; /* previous handler */

Known  bug,  fixed on trunk but not on 4.0 branch
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20226

Danny

RE: PING [4.1 regression, patch] build i686-pc-mingw32

[Danny Smith]

 From: Christopher Faylor
 Sent: Tuesday, July 26, 2005 9:33 AM
> 
> On Mon, Jul 25, 2005 at 05:23:54PM -0400, DJ Delorie wrote:
> >>Maybe one solution would be to patch pex-win32 for mingw so that it 
> >>could understand '#!' style shell scripts?  That would at 
> least allow 
> >>bootstrapping.
> >
> >That would be wonderful, and that's exactly the right place 
> to put it 
> >too.  I'm assuming I can persuade one of you to do that?  ;-)
> >
> >I'm going to define pex-win32.c as being within the realm of 
> the mingw 
> >maintainership (if you hadn't assumed that already).
> 
> I'd be happy to implement this.  I'd like to get Danny's 
> opinion on this first, though, in case I missed something.

Thanks Chris,  
I don't see any obvious problems. yet.
Danny
> 
> cgf
> 

Re: Problems bootstrapping mainline on cygwin: warning: ./cc1-checksum.o ./cc1obj-checksum.o ./cc1plus-checksum.o libgcc/_chkstk.o differ

[Danny Smith]

Christian Joensson wrote

> I haven't bootstrapped gcc on cygwin for a while now... but, using gcc
> cvs trunk LAST_UPDATED: Fri Aug 5 09:05:37 UTC 2005, I get comparison
> warnings...:

> warning: ./cc1-checksum.o differs
> warning: ./cc1obj-checksum.o differs
> warning: ./cc1plus-checksum.o differs

ld inserts an 4 byte timestamp into the "Image File Header" (offset 4
bytes) of pe-coff executables. I believe that genchecksum.c takes that
into account at line 46:

 /* Some executable formats have timestamps in the first 16 bytes, yuck.  */
  if (fseek (f, 16, SEEK_SET) != 0)

But ld also inserts a 4-byte checksum of its own further down, (offset
64 bytes into the Image Optional Header).  Changes in timestamps between
stages will cause changes in the Optional Header checksums. GCC's
genchecksum doesn't take that into account.

I'd  guess that the checksum diff for libgcc/_chkstk.o is due to
differences in the name of the preprocessor-generated temp *.s
assembly file in .stabstr section

Danny

Send instant messages to your online friends http://au.messenger.yahoo.com 

Re: [Patch, libfortran] PR 40812 Large file support on MinGW

[Danny Smith]

On Wed, Dec 2, 2009 at 7:18 AM, Janne Blomqvist
 wrote:
> Hi,
>
> the attached patch should make gfortran support > 2 GB files on MinGW.
> I don't have a windows installation to test on, so I don't know if
> this works or not. Though I regtested on x86_64-unknown-linux-gnu to
> make sure that non-MinGW targets didn't change (it's all behind
> #ifdefs, but just to be sure).
>
> Another caveat is that it uses features from the Win32 API that
> according to MSDN are available only as of w2k and newer, so with this
> patch we effectively drop support for pre-w2k targets on MinGW. I
> don't know if anybody cares about such platforms any longer, if so
> maybe the interested party could step up to the plate and contribute
> some configure checks or somesuch so that we could fall back to the
> old ftruncate or chsize functions?

I care about pre-w2k WinNT at least.  Please hold off on this while I
test a simple modification that doesn't require the newer API.
Danny

RE: Patch for mingw stdint information

[Danny Smith]

> Hi all,
> 
> Please find attached a patch I built to add stdint-related 
> information  
> to GCC configuration for the mingw target (see 
> http://gcc.gnu.org/ml/gcc/2009-04/msg0.html 
>   for more details about why).

Thanks for this.  I am just in the process of doning a testsuite run on exactly 
the the
same patch as yours 
(main diff is that I put everything in "mingw-stdint.h" for sanity reason.  I 
will need
Kai's help on 32/64 bit #ifdefs  

> I hope this can help,
It does of course.

Danny

Re: Problem with pex-win32.c

[Danny Smith]

Mark Mitchell wrote at  http://gcc.gnu.org/ml/gcc/2006-03/msg00441.html

> Here is a sample program which does the right thing (no spurious
console
> windows, all output visible) when run either from a console or from a
> console-free environment, such as a Cygwin xterm.  This is the code
> we'll be working into libiberty -- unless someone has a better
solution!

In my experience, following test is not necessary.  Win9x just ignores
the CREATE_NO_WINDOWS flag so setting it is a harmless no-op on these
platforms.

>   version_info.dwOSVersionInfoSize = sizeof (version_info); 
>   GetVersionEx (&version_info);
>   if (version_info.dwPlatformId == VER_PLATFORM_WIN32_WINDOWS)
> /* On Windows 95/98/ME the CREATE_NO_WINDOW flag is not
>supported, so we cannot avoid creating a console window.  */
> dwCreationFlags = 0;


See also 

http://gcc.gnu.org/ml/java-patches/2003-q4/msg00260.html

Danny

RFC: __cxa_atexit for mingw32

[Danny Smith]

Hello,

One of things mingw32 C runtime lacks is an implementation of
__cxa_atexit.
However, as explained in the comment below, some of the behaviour of
__cxa_atexit is already in the  C runtime  atexit implementation.

Adding the object below to libstdc++ or libgcc.a and configuring with
__cxa_atexit enabled produces PASSES for the three __cxa_atexit
dependent testcases. It works fine in tests with destruction of objects
in dll's too, whether these dlls are unloaded at process exit or by
earlier calls to UnloadLibrary. (No, it doesn't allow exceptions to be
thrown and caugtht across dll boundaries -- thats another story for gcc
4.3 -- but it removes one obstacle.)

Although this  keeps the changes local to mingw32 code, I don't really
like adding a fake __cxa_atexit to a runtime lib. So, the other option
would be to add a 'if (flag_use_dllonexit)' code to cp/decl.c and
decl2.c to parallel flag_use_cxa_atexit.

Adding a real __cxa_atexit to mingw runtime is of course also possible,
but I thought I'd attempt the easy options first.

I would appreciate any comments.


Danny

/* mingw32-cxa_atexit.c
   Contributed by Danny Smith ([EMAIL PROTECTED])
   Copyright (C) 2006   Free Software Foundation, Inc.

This file is part of GCC.

GCC is free software; you can redistribute it and/or modify it under
the terms of the GNU General Public License as published by the Free
Software Foundation; either version 2, or (at your option) any later
version.

GCC is distributed in the hope that it will be useful, but WITHOUT ANY
WARRANTY; without even the implied warranty of MERCHANTABILITY or
FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
for more details.

You should have received a copy of the GNU General Public License
along with GCC; see the file COPYING.  If not, write to
the Free Software Foundation, 51 Franklin Street, Fifth Floor,
Boston, MA 02110-1301, USA.  */
 
/* On mingw32, each dll has its own on-exit table, which is initialized 
   on dll load, Calls to atexit or onexit will register functions in the
   on-exit table of the containing module. Each dll-specific on-exit
table
   runs when that dll unloads. The calls to atexit from the main app,
(ie,
   including all static libs) are finalized at process exit.

   cc1plus currently ignores the argument to __cxa_atexit-registered
   functions.   If that changes, we will need to replace this with a
real
   __cxa_atexit implementation in mingw runtime.  */

#include 

/* We don't need an explicit dll handle. The handle is always 'this'. */
void* __dso_handle = NULL;

int __mingw_cxa_atexit (void (*)(void *), void *, void *);

int __mingw_cxa_atexit (void (*func)(void *),
void *arg __attribute__((unused)),
void *d __attribute__((unused)))
{
  return atexit ((void (*) (void)) func);
}


int __cxa_atexit (void (*)(void *), void *, void *)
  __attribute__ ((alias ("__mingw_cxa_atexit")));

RE: RFC: __cxa_atexit for mingw32

[Danny Smith]

> From: Ranjit Mathew
> Sent: Sunday, June 25, 2006 1:28 PM
> Danny Smith wrote:
> > Adding a real __cxa_atexit to mingw runtime is of course also
> > possible, but I thought I'd attempt the easy options first.
> 
> When you say "runtime", do you mean libstdc++ or something like 
> libmingwex.a in "mingw-runtime"? If you mean the former, you can add 
> this in for GCC 4.2 and work on a real
> __cxa_atexit() for GCC 4.3, if you want.
>

A real __cxa_atexit solution needs to be integrated into the
"mingw-runtime". The initialization and finalization of the at-exit
tables needs to be handled by mainCRTStartup/DllMainCRTStartup and the C
runtime functions _onexit, atexit and possibly dllonexit need to
rewritten as wrappers around cxa_atexit.  As it turns out, that is
fairly simple: eg.,  the version of __cxa_atexit and friends that is in
the STLPort library translate to mingw quite easily with a few minor
tweaks to accomodate the win32 API.  And  integrating atexit/_onexit
into cxa_atexit is facilitated by the fact that the msvcrt versions of
these functions are exported only as "_imp__"   prefixed indirect
references, so that we can avoid getting mixed up with MS version of
these functions.I have tested all that with a basic single-threaded
implementation and no problems.

But that won't happen before 4.2 is released.  I don't know how
difficult it will be  to convince other mingw developers that this idea
is a good thing: replace an ISO standard-conformant and perfectly
adequate  atexit function already supplied by OS vendor with a new
version, perhaps with some licensing strings attached.  I expect the
fake cxa_atexit hack I illustrated earlier would meet less resistance,
and that is why I considered it the easier option.

Me?  The __cxa_atexit behaviour is documented.  AFAICT, the
msvcrt-specific behaviour of the atexit and dllonexit functions is not,
and was 'discovered' by a lot of trial and error. So, today, I'd prefer
to implement a real __cxa_atexit and point users to the ABI specs.  

Thanks for replying to this thread, Ranjit.  We'll see if any other
mingw developers read this list.

Danny
 
> Thanks,
> Ranjit.
> 
>

Re: RFC: __cxa_atexit for mingw32

[Danny Smith]

At 
Mark Mitchell wrote: 


> I think it would be better to adopt [mingw-targetted] G++ to use
> whatever method Microsoft uses to handle static destructions.
> Ultimately, I would like to see G++ support the Microsoft C++ ABI --
> unless we can convince Microsoft to support the cross-platform C++
ABI. :-)


FWIW, looking at assembly produced by MS cl.exe for the
old-deja/g++.other testcases init5.C, init18.C, init19.C, the
destructors are registered with atexit, Ditto if I replace main
with DllMain and compile as dll.

I have a patch that allows use of atexit for destructors in the same way
as
__cxa_atexit in cp/decl.c and decl2.c and will submit in Stage1 next.

Danny

RE: Searching configured and relocated prefix.

[Danny Smith]

Mark Mitchell wrote:
> Sent: Monday, July 24, 2006 4:59 AM
> 
> Andrew Pinski wrote:
> > 
> > On Jul 14, 2006, at 1:17 PM, Carlos O'Donell wrote:
> > 
> >> We currently search both the relocated compilers prefix and the 
> >> originally configured prefix. Should a relocated compiler be 
> >> searching both directories?
> > 
> > Yes because someone might have just relocated the compiler 
> but not the 
> > rest of the tools.  The main use of this is that untar a common 
> > sysroot and use different
> > versions of the compiler which normally would be installed 
> under that
> > common location.
> 
> There are benefits and costs in either direction.
> 
> 1. If we search both locations (i.e., for a relocated 
> compiler, search the configured-time prefix and the 
> installation-time prefix), we get the following set of problems:
> 
> (a) If the configure-time prefix exists (for unrelated 
> reasons) the compiler finds files in the configure-time 
> prefix, even though neither the system administrator or user 
> expects that.
> 

1(a) is reported quite reguarly on mingw32 user lists.  I think I hit it
myself when I first started comparing different versions of the
compiler.

This is a typical scenario on windows

Configure-time prefix set to /mingw by binary release manager
User installs in C:\mingw
A new release is made available. Configure-time prefix is again /mingw,
since the release manger just reused the old build script.
User chooses to install in, say, C:\gcc-3.4.5-2\mingw, to keep thing
from getting confused. 
The new compiler, run from C:,  looks in /mingw first and gets it wrong.

Confused user reports a  bug.

So my response to  "Should a relocated compiler be  searching both
directories on mingw32?", would be

No, preferably only the relative-prefix.  The --enable-win32-registry
option, combined with an install-time  regedit script,  could still be
used to force a common, absolute 'sysroot'.

Danny

[cygwin/mingw32] DBX_REGISTER_NUMBER vs DWARF2_FRAME_REF_OUT

[Danny Smith]

Currently in config/i386/cygming.h we have this:

#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n) (write_symbols == DWARF2_DEBUG   \
? svr4_dbx_register_map[n]  \
: dbx_register_map[n])

This is fine as long as we assume that cygwin and mingw32 will always
use only SjLj EH model. However, once we move to Dwarf 2 unwind, it will
cause serious problems with exception handling when we mix objects with
DW2_DEBUG with objects with other or no debug info: The register mapping
for unwind frames (and in particular for SP and BP) will not be
consistent across objects.

A testcase for this is already present in g++.dg/eh/spbp.C

One 'easy' solution to the EH problem is to simply use the default i386
dbx_register_map regardless of the type of debug info. Or since a change
to DW2 unwind is a pretty major ABI change anyway, we could make the
svr4 dwarf2 mapping the new standard if DWARF_UNWIND_INFO.

Finally, we could do what x86-darwin does and do a remapping back from
the svr4 dwarf debug map to a default EH frame map, like so:

/* Unfortunately, the 32-bit EH information also doesn't use the
standard
   DWARF register numbers.  */
#define DWARF2_FRAME_REG_OUT(n, for_eh)
\
  (! (for_eh) || write_symbols != DWARF2_DEBUG || TARGET_64BIT ? (n)
\
   : (n) == 5 ? 4
\
   : (n) == 4 ? 5
\
   : (n) >= 11 && (n) <= 18 ? (n) + 1
\
   : (n))


Any other ideas?  What is likely GDB fallout?

Danny

RE: [cygwin/mingw32] DBX_REGISTER_NUMBER vs DWARF2_FRAME_REF_OUT

[Danny Smith]

> > Date: Thu, 27 Jul 2006 09:46:36 +1200
> > From: Danny Smith <[EMAIL PROTECTED]>
> > 
> > From: Mark Kettenis
> > Sent: Thursday, July 27, 2006 9:34 AM
> > 
> > > The best thing to do is probably to define
> > > DWARF2_FRAME_REG_OUT to always use the SVR4 register map.
> > 
> > Thanks for that advice.  I'm in process of testing with
> > the simple one-line change:
> > 
> > #define DBX_REGISTER_NUMBER(n) svr4_dbx_register_map[n]
> 
> That'd be bad, since it will break debugging code compiled 
> with -gstabs in a very confusing way.  And it would be 
> impossible to fix in GDB without screwing over people that 
> are still using older versions of GCC.
> 
It certainly is bad.
This hasn't caused any problems yet.

/* Maintain compatibility with old -gstabs code.  */
#undef DBX_REGISTER_NUMBER
#define DBX_REGISTER_NUMBER(n) (write_symbols == DWARF2_DEBUG   \
  ? svr4_dbx_register_map[(n)]
\
  : dbx_register_map[(n)])

/* Map gcc register number to DWARF 2 CFA column number.  
   Always use the svr4_dbx_register_map for DWARF .eh_frame even
   if we don't use DWARF for debugging.  */
#undef DWARF_FRAME_REGNUM
#define DWARF_FRAME_REGNUM(n) svr4_dbx_register_map[(n)] 

Danny

> Mark
> 

RE: pr27650 - dllimport of virtual methods broken.

[Danny Smith]

> From: Mark Mitchell 
> Carlos O'Donell wrote:
> > Is any of you able to give some comments on pr27650
> > 
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27650
> > 
> > In particular I am interested in an opinion of Danny's fix.
> > 
> > http://gcc.gnu.org/ml/gcc-patches/2006-05/msg01504.html
> > 
> The cp/decl2.c change also seems less than ideal.  The key 
> invariant is 
> that virtual functions can't be dllimport'd.  So, I think we 
> should mark 
> them that way when they're declared, perhaps in grokfndecl or in 
> cp_finish_decl.
> 
> It could be that I'm missing something, though; Danny might want to 
> debate my conclusions.

The problem I had was with the second case below.  We don't know if a
method is implicitly virtual
until search.c:look_for_overrides_r).  Would t be better to unset
DECL_DLLIMPORT_P (and remove the attribute as well) there?

// Don't import explicitly virtual method.
struct base
{
  virtual void key_method();
  __attribute__((dllimport)) virtual ~base();
};

void base::key_method() {}


// Nor an implicitly virtual method.
struct derived : public base
{
  void key_method(); 
  __attribute__((dllimport)) ~derived();
};

void derived::key_method() {} 

Danny

RE: pr27650 - dllimport of virtual methods broken.

[Danny Smith]

> From: Mark Mitchell [mailto:[EMAIL PROTECTED] 
> Sent: Thursday, September 14, 2006 3:38 PM
> Danny Smith wrote:
> 
> > The problem I had was with the second case below.  We don't 
> know if a 
> > method is implicitly virtual until search.c:look_for_overrides_r).  
> > Would t be better to unset DECL_DLLIMPORT_P (and remove the 
> attribute 
> > as well) there?
> 
> Ah, right, good point.  I always forget that case,.partly because I 
> really think that processing should be done when the function is 
> declared.  We can know whether it's virtual at that point, so 
> I think we 
> should.  But, that's not how things work now. :-(
> 
> So, perhaps the best place would be in check_for_override.  That's 
> called for all methods when the class is complete.
> 

Revised patch. 

Tested on i686-pc-mingw32

Danny

cp/ChangeLog

PR target/27650
* class.c (check_for_override): Remove dllimport from virtual
methods.

testsuite/Changelog
PR target/27650
* g++.dg/ext/dllimport12.C: New file.


Index: cp/class.c
===
*** cp/class.c  (revision 117005)
--- cp/class.c  (working copy)
*** check_for_override (tree decl, tree ctyp
*** 2342,2347 
--- 2342,2357 
if (!DECL_VINDEX (decl))
DECL_VINDEX (decl) = error_mark_node;
IDENTIFIER_VIRTUAL_P (DECL_NAME (decl)) = 1;
+   if (DECL_DLLIMPORT_P (decl))
+   {
+ /* When we handled the dllimport attribute we may not have
known
+that this function is virtual   We can't use dllimport
+semantics for a virtual method because we need to
initialize
+the vtable entry with a constant address.  */
+ DECL_DLLIMPORT_P (decl) = 0;
+ DECL_ATTRIBUTES (decl)
+   = remove_attribute ("dllimport", DECL_ATTRIBUTES (decl));
+   }
  }
  }
Index: testsuite/g++.dg/ext/dllimport12.C
===
*** testsuite/g++.dg/ext/dllimport12.C  (revision 0)
--- testsuite/g++.dg/ext/dllimport12.C  (revision 0)
***
*** 0 
--- 1,22 
+ // PR target/27650
+ // Don't use dllimport semantics on virtual methods
+ // { dg-do compile { target i?86-*-cygwin* i?86-*-mingw*} }
+ 
+ // Don't import explicitly virtual method.
+ struct base
+ {
+   virtual void key_method();
+   __attribute__((dllimport)) virtual ~base();
+ };
+ 
+ void base::key_method() {}
+ 
+ 
+ // Nor an implicitly virtual method.
+ struct derived : public base
+ {
+   void key_method(); 
+   __attribute__((dllimport)) ~derived();
+ };
+ 
+ void derived::key_method() {}

Re: bootstrap broken on mingw

[Danny Smith]

On Feb 18, 2008 10:59 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
>
> gcc/ChangeLog:
> 2008-02-17  Ralf Wildenhues  <[EMAIL PROTECTED]>
>
> PR bootstrap/35218
> * Makefile.in (build_file_translate): New.
> (gcc-vers.texi): Use it for translating $(abs_srcdir).
> * config.build (build_file_translate): Set to `CMD //c' on MinGW.
> * configure.ac (build_file_translate): Substitute it.
> * configure: Regenerate.
>

This patch breaks native bootstrap on mingw systems that use
cygwin1.dll-dependent bash and development tools.  As such, that would
be a regression against all versions of gcc since at least 2.95.3

The  ' CMD  //c' (with 2 slashes preceding the switch  rather than the
one documented for cmd by Micrsosoft) is a MSYS-ism that causes
problems  with non-MSYS shells (including the one provided by MS in
its SFU package)


GCC corrently bootstaps just fine (with or without the earlier
abs_srcdir patch) on mingw using the cygwin bash shell, make and
configure. Using cygwin shell rather than the MSYS shell means that
DejaGnu testsuite can be run.  The last time I checked this was not
possible.  with MSYS.

Danny

Re: bootstrap broken on mingw

[Danny Smith]

On Feb 20, 2008 10:02 PM, Danny Smith <[EMAIL PROTECTED]> wrote:
> On Feb 18, 2008 10:59 AM, Ralf Wildenhues <[EMAIL PROTECTED]> wrote:
> >
> > gcc/ChangeLog:
> > 2008-02-17  Ralf Wildenhues  <[EMAIL PROTECTED]>
> >
> > PR bootstrap/35218
> > * Makefile.in (build_file_translate): New.
> > (gcc-vers.texi): Use it for translating $(abs_srcdir).
> > * config.build (build_file_translate): Set to `CMD //c' on MinGW.
> > * configure.ac (build_file_translate): Substitute it.
> > * configure: Regenerate.
> >
>
> This patch breaks native bootstrap on mingw systems that use
> cygwin1.dll-dependent bash and development tools.  As such, that would
> be a regression against all versions of gcc since at least 2.95.3
>
> The  ' CMD  //c' (with 2 slashes preceding the switch  rather than the
> one documented for cmd by Micrsosoft) is a MSYS-ism that causes
> problems  with non-MSYS shells (including the one provided by MS in
> its SFU package)
>
>
> GCC corrently bootstaps just fine (with or without the earlier
> abs_srcdir patch) on mingw using the cygwin bash shell, make and
> configure. Using cygwin shell rather than the MSYS shell means that
> DejaGnu testsuite can be run.  The last time I checked this was not
> possible.  with MSYS.
>



I just noticed that this has been committed.  Should I open a new bug
report?  The use of 'CMD //c' should be restricted to those systems
that understand it.

> Danny
>

RE: Bootstrap failure on native mingw32

[Danny Smith]

Committed as obvious.
This was already in my sources (for another reason) when I tested Kai's patch.
Sorry for not noticing.

Danny

* libgcc2.c [L_trampoline]: Remove unnecessary prototype for
Windows VirtualProtect function.

Index: libgcc2.c
===
--- libgcc2.c   (revision 134329)
+++ libgcc2.c   (working copy)
@@ -2058,10 +2058,6 @@
 #endif
 }

-#ifdef __i386__
-extern int VirtualProtect (char *, int, int, int *) __attribute__((stdcall));
-#endif
-
 int
 mprotect (char *addr, int len, int prot)
 {

> -Original Message-
> From: FX [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, 16 April 2008 12:28 a.m.
> To: GCC Development; Danny Smith
> Subject: Bootstrap failure on native mingw32
> 
> 
> I'm not exactly sure how this one was introduced, but a bootstrap on
> native i686-pc-mingw32 dies in stage1 libgcc with:
> 
> ../../../trunk/libgcc/../gcc/libgcc2.c:2052: warning: no previous
> prototype for 'getpagesize'
> ../../../trunk/libgcc/../gcc/libgcc2.c:2062: error: conflicting types
> for 'VirtualProtect'
> c:/MinGW/include/winbase.h:1995: error: previous declaration of
> 'VirtualProtect' was here
> ../../../trunk/libgcc/../gcc/libgcc2.c:2066: warning: no previous
> prototype for 'mprotect'
> 
> The prototype for VirtualProtect in libgcc2.c is:
>   extern int VirtualProtect (char *, int, int, int *) 
> __attribute__((stdcall));
> 
> In , it is:
>   BOOL __attribute__((__stdcall__)) 
> VirtualProtect(PVOID,DWORD,DWORD,PDWORD);
> with:
>   typedef unsigned long DWORD;
>   typedef int WINBOOL;
>   typedef WINBOOL BOOL;
>   typedef DWORD *PDWORD;
>   typedef void *PVOID;
> 
> 
> Does that ring a bell to anyone? Any idea why it's showing up now even
> though it looks like this code wasn't modified in the recent past (and
> my winbase.h hasn't changed since my last successful bootstrap, a
> month ago).
> 
> Thanks,
> FX
> 
> 
> PS: My exact configure line is: ../trunk/configure --prefix=/mingw
> --enable-languages=c,fortran --with-gmp=/home/FX/local
> --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror
> --enable-bootstrap --enable-threads --disable-nls
> --build=i586-pc-mingw32 --enable-libgomp --disable-shared
> 
> -- 
> FX Coudert
> http://www.homepages.ucl.ac.uk/~uccafco/

RE: Combined tree builds for mingw32

[Danny Smith]

> > 
> > > The failing command is trying to compile the PCH.  This means that
> > > we're including a large number of libstdc++ headers in a 
> row.  One of
> > > the first ones pulls in c++config.h, which has #undef 
> max; but so far,
> > > nothing has included .  Later, something includes
> > > gthr-default.h; on this platform that pulls in , which
> > > eventually #define's min.  Then later we get , 
> which now sees
> > > the definition.
> > >  
> > I see, but I still don't get why this is worse than time 
> ago, when the undefs 
> > where placed in the middle of stl_algobase.h and nowhere 
> else. Do you?
> 
> I am just guessing, but I suspect that something before the middle of
> stl_algobase.h caused  to be included.  Here's the ugly
> patch I'm using right now to get past this:
> 

You've probably discovered this already, but...

 should not be included by default in libstdc++ on mingw
target.
That is taken care of by config/os/mingw32/os_defines.h.  
min/max macros also are taken care of there, but I see the comment is
out-of-date.

Most people I know who build mingw-targeted  gcc/binutils natively or
cross, preinstall the
mingw runtime headers and libraries in $(prefix).  Unlike other systems,
mingw32 does not have 
a standard location for headers or libraries, but uses the
make_relative_prefix dance to find the local dirs.

Danny

RE: trimming excess errors from -Werror

[Danny Smith]

> 
> cc1plus: warnings being treated as errors
> 
> /cygdrive/e/gnu/gcc-4.3-20070511/libstdc++-v3/testsuite/17_int
> ro/headers/all_c++200x_compatibility.cc:1:
> error: -ffunction-sections may affect debugging on some targets
> 

This is actually a useful warning, since  -ffunction-sections not only
affects debugging but also adds unnecessary size to executables on
PE-COFF targets (and others where ld does not support --gc-sections).
One way to avoid is to add --enable-cxx-flags='-fno-function-sections
-fno-data-sections' to configure

Danny  

RE: trimming excess errors from -Werror

[Danny Smith]

> 
> libstdc++ configure is already probing to see if the target 
> supports the 
> use of this flag without errors. It thinks AIX and cygwin can 
> use this 
> flag without errors or warnings, which is clearly wrong.
> 
> So, something needs to be fixed.
> 
> Can you try
> 
> int i;
> 
> with "-Werror -ffunction-sections -fdata-sections" and see if 
> you get an 
> error with g++?

With GNU C++ version 4.3.0 20070513 (experimental) (i686-pc-mingw32dw2)
No error.  i is put in its own section .data$i
> 
> if not, can you try
> 
> int i;
> void bar() { }
> 
> with the same flags and see if you get the error?
> 
No error.  bar is put in .text$_Z3barv

Danny

RE: trimming excess errors from -Werror

[Danny Smith]

> > Can you try
> > 
> > int i;
> > 
> > with "-Werror -ffunction-sections -fdata-sections" and see if 
> > you get an 
> > error with g++?
> 
> With GNU C++ version 4.3.0 20070513 (experimental) 
> (i686-pc-mingw32dw2)
> No error.  i is put in its own section .data$i

But error when I add "-g" to above

> > 
> > if not, can you try
> > 
> > int i;
> > void bar() { }
> > 
> > with the same flags and see if you get the error?
> > 
> No error.  bar is put in .text$_Z3barv

And also error when I add "-g"

Danny

RE: use of %n in genmodes.c causes trouble on Vista

[Danny Smith]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Simon Brenner
> Sent: Thursday, 7 June 2007 2:40 a.m.

> > > Or just add a call to _set_printf_count_output in the relevant
> > > place, since AFAIK %n is still a standard-mandated printf format
> > > flag.
> >
> > Where is the "relevant place"?  This would be a really 
> messy host-dependent
> > call and I think it far better to eliminate the usage in 
> *some* way than
> > to do this.
> 
> Perhaps it could be something for libiberty to take care of?

Unless I'missing soemthing, this is 'just' a build issue in genmode.c.
GCC builds fine for Vista target on WindowsXP. 
So the fix needs to be build dependent, not host dependent.  

Danny

RE: use of %n in genmodes.c causes trouble on Vista

[Danny Smith]

Ian Lance Taylor
Friday, 8 June 2007 1:52 a.m.
> 
> At the very least there should be a compiler option for standard
> conformant behaviour in this area.  I didn't see one in the MSDN docs.
> I would say that gets is much more dangerous than %n in printf, but
> presumably Microsoft does not disable gets.
> 

The MSVCRT version of printf is non-conformant in several ways. In
addition to the new '%n' behaviour, there is the old problems with the
requirement to use 'I64' format flag  in place of 'll',  failure to
handle long double, non-C99-conformant return value for vsnprintf.  I
believe that thef first two of these are represented by open GCC
Bugzilla PR's.

A GCC target option (say, -malt-ISO-printf) for mingw that causes calls
to printf family to be mapped to a mingw_printf, mingw_snprintf, etc  is
one possibilty.  I have an experimntal a ISO-C99 compliant
mingw_vsnprintf that I was planning to contribute to mingw's libmingex.a
runtime extension library.   The main reason for writing this was to
allow long double output in libstdc++ and libgfortran. Wrapping that in
_set_printf_count_output (or adding a ctor that calls
_set_printf_count_output to a new startfile object) if we are using
Vista's MSVCRT.dll would avoid this problem in genmodes. 

Although, the alternate versions of *printf could be enabled in other
ways, having a compiler switch take care of it would  be nice.

Danny



> Ian
> 

RE: RFC: Make dllimport/dllexport imply default visibility

[Danny Smith]

> -Original Message-
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On 
> Behalf Of Mark Mitchell
> Sent: Saturday, 16 June 2007 11:47 a.m.
> 
> Chris Lattner wrote:
> 
> > This construct seems like it should be rejected by the C++ 
> front-end. 
> > The source is making two contradictory claims: the struct 
> is not visible
> > outside this library, but part of it is implemented outside of it.
> 
> I don't think there's a contradiction.  The declaration on 
> the structure
> is the default for the members and applies to the vtable and 
> other class
> data.  There's no reason the members shouldn't be implemented 
> elsewhere,
> and there's certainly existing code (in Windows, SymbianOS, and other
> DLL-based operating systems, whether or not there is on 
> GNU/Linux) that
> implements different class members in different DLLs, while still not
> exporting the class from its home DLL.  One situation where this is
> useful is when the class members are actually shared between multiple
> classes, or are also callable as C functions, etc.
> 
>


In windows dll's the default visibility of a symbol is hidden (GNU ld as
--export-all-extension to override this default, but that is not the
compiler's fault). 
So this, in a dll module source:
>> Consider:
>>
>>  struct __attribute__((vsibility ("hidden"))) S {
>>void __declspec(dllimport) f();
>>  };

is equivalent to 

>>  struct __attribute__ S {
>>void __declspec(dllimport) f();
>>  };


And certainly that is meaningful  on window's  targets

Danny

RE: Decimal float and the Cygwin build of GFortran.

[Danny Smith]

Angelo Graziosi
Wednesday, 4 July 2007 7:19 p.m.
> 
> 
> 
> I have build GFortran under Cygwin configuring with:
> 
>  ./configure --prefix=${prefix_dir} \
>  --enable-languages=c,fortran \
>--enable-bootstrap \
>--enable-libgomp \
>--enable-threads \
>--enable-sjlj-exceptions \
>--enable-version-specific-runtime-libs \
>--enable-nls \
>--enable-werror \
>--enable-checking=release \
>--disable-libmudflap \
>--disable-shared \
>--disable-win32-registry \
>--with-system-zlib \
>  --without-included-gettext \
>--without-x 
> 
> 
> The build gives, a few times, this warning:
> 
> 
> ---
> ...
> checking for valgrind.h... no
> configure: WARNING: decimal float is not supported for this target
>^^^
> checking whether make sets $(MAKE)... yes
> ...
> ---
> 
> A few months ago this did not happen (same building procedure).
> 
> 
> So, have you an idea about this ?

Adding --enable-decimal-float=bid works for me
Danny

RFC: Enabling DFP/libbid on dditional target (mingw32)

[Danny Smith]

Hello

On i686-pc-mingw32 I can build  a libbid-enabled libgcc by  adding
--enable-decimal-float=bid to configure and
setting ENABLE_DFP=1 in environment when running make bootstrap.

make -k check-gcc RUNSTESTFLAGS='dfp.exp" sets
check_effective_target_dfprt as true abd gives:

=== gcc Summary ===

# of expected passes591
# of unsupported tests  1
/develop/svn/trunk/build/gcc/xgcc  version 4.3.0 20070705 (experimental)

That looks promising.

Can somebody please advise of further test harness(es) for libbid?  Or
am I missing a more fundamental reason for the limited range of targets
supporting DFP?


Danny

RE: RFC: Enabling DFP/libbid on dditional target (mingw32)

[Danny Smith]

> 
> > Or
> > am I missing a more fundamental reason for the limited 
> range of targets
> > supporting DFP?
> 
> 
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf

Thanks.  

Danny

RE: Crossbuild problem x86_64-pc-mingw32 related to crtbegin & crtend

[Danny Smith]

Kai Tietz
Tuesday, 10 July 2007 11:19 p.m.
> 
> Hi,
> 
> I tried to build the cross-compiler for the target 
> x86_64-pc-mingw32 and 
> noticed some trouble about the crtbegin and crtend for this 
> target. To the 
> specfile this object was introduced by the patch of Danny 
> Smith from the 
> 14th of Jine 2007. The problem is, that those objects are not 
> compiled and 
> they seems to be not even build for i?86 AFAICS.
>
The builds are specified in libgcc/config.host for i?86 mingw and cygwin.
What happens if you do the same for x86_64-*-mingw*?

 May somebody can help me for this problem. Is it ok to simply 
> remove the 
> crt*.o from spec file for this target, or should these files 
> be builded 
> for it ? 
> 

How else can you initialize and clean up the Dwarf2 unwind registrations on 
x86_64-pc-mingw32?

Danny