Missing features on Changes for GCC 4.3

Hello, I missed on the gcc changes page the new target x86_64-pc-mingw32 support for cross compilation. Also the new pragma feature for mingw (pragma push_macro/pop_macro) is missing, too. Is this intended to wait for mingw to provide a offical header-set for this, or was it simply forgotten ?

[cxx0x-branch] Rvalue references vs RVO

Hi, I have done some experiments with the rvalue reference feature on the cxx0x-branch. If I execute the following program: - #include struct A { A () { std::cout << "def ctor" << std::endl; } A (const A&) { std::cout << "normal copy" << std::endl; } A (A

Getting the name of the file to compile

Hi all, i'm writing a new option pass. For more reason, i have to know the name of the file .c to compile. For example: if the user writing in the shell the following command : - gcc filename.c i want to obtain the variable char* that contain the value filename. I have seen in the file gcc.c th

Re: Getting the name of the file to compile

Basile STARYNKEVITCH ha scritto: Maybe you just want the main_input_filename declared in gcc-trunk/gcc/input.h (near line 80)? Yes, exactly. Thank you so much.

Re: New wiki page on testing compile times and memory usage

Gerald Pfeifer wrote on 05/06/07 18:14: > Nice, thanks for sharing these. How about the patch below? Sure, thanks.

live insns deleted by delete_trivially_dead_insns()

I'm seeing miscompilation of newlib's memcmp() for my 16-bit ix86 port. The REG_RETVAL and REG_LIBCALL notes seem to play an important part in the failure. From the first subreg dump: ;; Function memcmp (memcmp) ; Splitting reg 73 -> 89 90 ; Splitting reg 74 -> 91 92 ; Splitting reg 75 -> 93 94 [

Re: Successful build of GCC 4.2.0 RC3 on latest Cygwin snapshot 20070427

Hi Aaron, One issue that might affect many some is that COM doesn't work. has a patch that is pending review I guess, but probably won't go into 4.2. Its not a very big patch, shame it cannot be reviewed in time. Does this effect XPCOM mean

libffi & powerpc

Hi there, I'm running an embedded platform based on a powerpc 405EP CPU and a gcc 4.1.0 cross-toolchain. My initial problem was that gcj compiled binaries crash at runtime when interpreting java bytecode ("Illegal instruction" message). After many investigations, it looks like the problem comes

Combined tree builds for mingw32

Has anyone tried a combined (src+gcc) tree build for i586-mingw32 lately? So far I've rediscovered that you need to manually specify --with-newlib; otherwise libstdc++ tries to run link tests. But I'm still failing to build libstdc++ in various different ways. The #undef min / #undef max in c++con

One more df-branch benchmarking on SPEC2000

This is one more df-branch comparison after the last merge branch (done 05/03) with the mainline on the merge point (r124382). There is a big progress since last my benchmarking on compilation speed of SPECFP2000 for PPC64. But whatever changed this does not work well for all platforms and ben

Re: Combined tree builds for mingw32

Hi, The #undef min / #undef max in c++config.h do not work if c++config.h is included before windows.h, which happens during a build of the PCH; I'm not sure to understand. Can you explain in better detail? Proviously, we had those undefs in the middle of stl_algobase.h, I don't see why tha

Re: Combined tree builds for mingw32

On Mon, May 07, 2007 at 07:25:25PM +0200, Paolo Carlini wrote: > Hi, > > > The #undef min / #undef max in c++config.h do not work if c++config.h > > is included before windows.h, which happens during a build of the PCH; > > > I'm not sure to understand. Can you explain in better detail? Provious

Re: Combined tree builds for mingw32

Daniel Jacobowitz wrote: 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.

Re: Combined tree builds for mingw32

Paolo Carlini wrote: 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; o

Re: Combined tree builds for mingw32

On Mon, May 07, 2007 at 01:37:51PM -0400, Daniel Jacobowitz wrote: > That third one does not define _U. It uses _UPPER instead. Does this > mean --with-newlib does not work for mingw32? (Note, you can't build > without it either.) That does appear to be the case. With --with-newlib, we get con

Re: Combined tree builds for mingw32

Paolo Carlini wrote: Forgot: in fact, I don't see why the specific scenario above can happen: now includes c++config.h, which (now, not in old releases) undefs #min and #max again... Never mind, c++config.h has been included before. May previous doubts stand however. Paolo.

Re: Combined tree builds for mingw32

Daniel Jacobowitz wrote: > 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-

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

David Daney <[EMAIL PROTECTED]> writes: > Kaz Kojima wrote: > > Hi, > > > > I've noticed that some libjava tests fail for SH on trunk and > > 4.2.0 RC3. > > > > New tests that FAIL: > > > > Divide_1 -O3 -findirect-dispatch output - bytecode->native test > > Divide_1 -O3 output - bytecode->native t

Re: Combined tree builds for mingw32

On Mon, May 07, 2007 at 07:47:01PM +0200, Paolo Carlini wrote: > Daniel Jacobowitz wrote: > > > 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

Re: Combined tree builds for mingw32

On Mon, May 07, 2007 at 10:55:38AM -0700, Brian Dessent wrote: > Well MinGW doesn't use any part of newlib so using --with-newlib sounds > like it's technically incorrect. The right way is probably to add > something that does the equivalent of > --with-headers=$top_srcdir/winsup/mingw/include (an

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

Ian Lance Taylor wrote: > This patch appears to fix the problem. I'm running the libjava tests > now. Does this look OK to the java maintainers for 4.2 branch and > mainline? Mark, should I commit to 4.2 branch? If this (or a variant) is approved by the Java maintainers, please do apply the sa

Re: Combined tree builds for mingw32

... should have explicitely added that changes to the mingw32 configure and mingw-specific config files are of course more than welcome: as soon as you are happy with a set of tweaks, just let the v3 people know! Paolo.

Re: One more df-branch benchmarking on SPEC2000

On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote: This is one more df-branch comparison after the last merge branch (done 05/03) with the mainline on the merge point (r124382). There is a big progress since last my benchmarking on compilation speed of SPECFP2000 for PPC64. But whatever

tuples: call for help

Hi Dan. Hi folks. People (ok, so it was Dan) had asked if there was anything they could do to help the tuples effort. The pretty print routines could definitely use a lot of cases (dump_gimple_stmt), and the work is very self contained. There is also the constructors and accessors for the IR.

Re: One more df-branch benchmarking on SPEC2000

Richard Guenther wrote: On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote: Compilation time SPECINT2000 (user time sec): **Mainline Branch Change x86_64139.39 148.48 +6.5% Itanium 446.00 484.56 +8.6% PPC64 374.33 399.72 +6.8%

Re: live insns deleted by delete_trivially_dead_insns()

>It isn't until the loop2_done dump that the problem shows up. > delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn > 62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully > replacing reg 92 with const_int 0, determines that the while libcall > sequen

Re: One more df-branch benchmarking on SPEC2000

On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote: Richard Guenther wrote: > On 5/7/07, Vladimir Makarov <[EMAIL PROTECTED]> wrote: > >> >> Compilation time SPECINT2000 (user time sec): >> **Mainline Branch Change >> >> x86_64139.39 148.48 +6.

Re: live insns deleted by delete_trivially_dead_insns()

Eric Botcazou wrote: It isn't until the loop2_done dump that the problem shows up. delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn 62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully replacing reg 92 with const_int 0, determines that the while l

Re: live insns deleted by delete_trivially_dead_insns()

On Mon, May 07, 2007 at 10:12:21PM +0200, Paolo Bonzini wrote: > Eric Botcazou wrote: > >> It isn't until the loop2_done dump that the problem shows up. > >>delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn > >>62 and seeing both the REQ_EQUAL and the REG_RETVAL note and

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: live insns deleted by delete_trivially_dead_insns()

On Mon, May 07, 2007 at 09:35:38PM +0200, Eric Botcazou wrote: > >It isn't until the loop2_done dump that the problem shows up. > > delete_trivially_dead_insns() is called. It calls dead_libcall_p() on insn > > 62 and seeing both the REQ_EQUAL and the REG_RETVAL note and successfully > > replac

Re: Combined tree builds for mingw32

On Tue, May 08, 2007 at 09:11:45AM +1200, Danny Smith wrote: > 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 se

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

> "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: Ian> This is a bug in C++ code in libjava. Thanks. We enabled -fwrapv for the interpreter but, I think, thought that perhaps the other C++ code was safe. Would the new warning have caught this? Ian> This patch appears to fix the proble

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

Mark Mitchell <[EMAIL PROTECTED]> writes: > Ian Lance Taylor wrote: > > > This patch appears to fix the problem. I'm running the libjava tests > > now. Does this look OK to the java maintainers for 4.2 branch and > > mainline? Mark, should I commit to 4.2 branch? > > If this (or a variant) is

Re: libjava Divide_1 and pr6388 fail on 4.2.0 RC3 for several targets

Tom Tromey <[EMAIL PROTECTED]> writes: > > "Ian" == Ian Lance Taylor <[EMAIL PROTECTED]> writes: > > Ian> This is a bug in C++ code in libjava. > > Thanks. We enabled -fwrapv for the interpreter but, I think, thought > that perhaps the other C++ code was safe. > Would the new warning have c

MinGW, GCC Vista,

Hi, Do you guys know if the problem with the access() standard library function has been worked around? Windows vista has an updated MSVCRT.DLL which returns false for access() using X_OK, this parameter was previously ignored, and returned true. MinGW / GCC does not work on Vista as a result. R

Re: live insns deleted by delete_trivially_dead_insns()

Because it's the semantics of libcall sequences. My take is that the lower subreg pass breaks it in this case. I could "fix" it at -O2 with -fno-split-wide-types or at -O1 with -fno-move-loop-invariants or -fno-split-wide-types. Can you also check -fno-forward-propagate? Yes. It'll