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

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-M

RE: Patch for mingw stdint information

> 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 e

RE: Bootstrap failure on native mingw32

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 >

Re: bootstrap broken on mingw

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/35

Re: bootstrap broken on mingw

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

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

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

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

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

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

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: ===

RE: Decimal float and the Cygwin build of GFortran.

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 \ >-

RE: RFC: Make dllimport/dllexport imply default visibility

> -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 contradi

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

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

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

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

RE: trimming excess errors from -Werror

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

RE: trimming excess errors from -Werror

> > 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 "-W

RE: trimming excess errors from -Werror

> > 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 on

RE: Combined tree builds for mingw32

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

RE: i386: Problems with references to import symbols.

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 al

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

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

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

> > 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 [EMA

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

> > 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: Why doesn't libgcc define _chkstk on MinGW?

[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

RE: pr27650 - dllimport of virtual methods broken.

> 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_override

RE: pr27650 - dllimport of virtual methods broken.

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

RE: [cygwin/mingw32] DBX_REGISTER_NUMBER vs DWARF2_FRAME_REF_OUT

> > 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 t

[cygwin/mingw32] DBX_REGISTER_NUMBER vs DWARF2_FRAME_REF_OUT

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

RE: Searching configured and relocated prefix.

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 > >> searc

Re: RFC: __cxa_atexit for mingw32

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 conv

RE: RFC: __cxa_atexit for mingw32

> 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 libs

RFC: __cxa_atexit for mingw32

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]

Re: Problem with pex-win32.c

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

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

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 diffe

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

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

Re: Failure building Ada on i686-pc-mingw32

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