Re: gcc will become the best optimizing x86 compiler

Denys Vlasenko wrote: I tend to doubt that odd-byte aligned large memcpys are anywhere near typical. malloc and mmap both return well-aligned buffers (say, 8 byte aligned). Static and on-stack objects are also at least word-aligned 99% of the time. memcpy can just use "relatively simple" code fo

Re: gcc will become the best optimizing x86 compiler

On Tue, Jul 29, 2008 at 04:14:49PM +1000, Ben Elliston wrote: >> Since there is no libc mailing list, I thought that the gcc list is the >> place to contact the maintainers of libc. Am I on the wrong list? Or are >> there no maintainers of libc? > >See: > http://sources.redhat.com/glibc/ > >You

gcc-4.2-20080730 is now available

Snapshot gcc-4.2-20080730 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080730/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches

Re: gcc will become the best optimizing x86 compiler

On Wednesday 30 July 2008 19:14, Agner Fog wrote: > I agree that the OpenSolaris memcpy is bigger than necessary. However, > it is necessary to have 16 branches for covering all possible alignments > modulo 16. This is because, unfortunately, there is no XMM shift > instruction with a variable c

Re: gcc will become the best optimizing x86 compiler

On Wed, Jul 30, 2008 at 5:14 PM, Agner Fog <[EMAIL PROTECTED]> wrote: > Denys Vlasenko wrote: >>> >>> 3164 line source file which implements memcpy(). >>> You got to be kidding. >>> How much of L1 icache it blows away in the process? >>> I bet it performs wonderfully on microbenchmarks though. >>>

Re: Pedantic error on address-of main breaks libjava bootstrap

Manuel López-Ibáñez wrote: > 2008/7/30 Aaron W. LaFramboise <[EMAIL PROTECTED]>: >> Andrew Haley wrote: >>> Aaron W. LaFramboise wrote: When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails with: > ./sysdep/backtrace.h: In function '_Unwind_Reason_Code > fall

Re: Pedantic error on address-of main breaks libjava bootstrap

2008/7/30 Aaron W. LaFramboise <[EMAIL PROTECTED]>: > Andrew Haley wrote: >> >> Aaron W. LaFramboise wrote: >>> >>> When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails >>> with: >>> ./sysdep/backtrace.h: In function '_Unwind_Reason_Code fallback_backtrace(_Unwind_Reason

Re: gcc will become the best optimizing x86 compiler

Denys Vlasenko wrote: 3164 line source file which implements memcpy(). You got to be kidding. How much of L1 icache it blows away in the process? I bet it performs wonderfully on microbenchmarks though. I agree that the OpenSolaris memcpy is bigger than necessary. However, it is necessary t

Re: gcc emit wrong symbols in multiple inheritance case

Brian Dessent wrote: Benjamin Smedberg wrote: For what it's worth, Bo is my intern in the Google SoC and has traced this back to being a code-generation error (missed stdcall mangling) in the mingw backend. I will work with him to narrow the problem and reformulate the question.. Isn't this <

Re: Pedantic error on address-of main breaks libjava bootstrap

Andrew Haley wrote: Aaron W. LaFramboise wrote: When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails with: ./sysdep/backtrace.h: In function '_Unwind_Reason_Code fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*), _Jv_UnwindState*)': ./sysdep/backtrace.h:107:

Re: gcc emit wrong symbols in multiple inheritance case

Benjamin Smedberg wrote: > For what it's worth, Bo is my intern in the Google SoC and has traced this > back to being a code-generation error (missed stdcall mangling) in the mingw > backend. I will work with him to narrow the problem and reformulate the > question.. Isn't this

Re: gcc emit wrong symbols in multiple inheritance case

Ian Lance Taylor wrote: "Bo Yang" <[EMAIL PROTECTED]> writes: Could anybody give some advice on this? Thanks! The mailing list gcc@gcc.gnu.org is for gcc developers, who mostly do not use cygwin. Try asking on [EMAIL PROTECTED] and/or [EMAIL PROTECTED] For what it's worth, Bo is my intern

Re: unsigned comparison warning

Thanks Ian. I will raise this in gcc-help mailing list. Cheers Hari Ian Lance Taylor wrote: Hariharan <[EMAIL PROTECTED]> writes: I found something rather strange with the unsigned comparison warnings in GCC. This is the wrong mailing list. The mailing list gcc@gcc.gnu.org is for gcc devel

Re: gcc will become the best optimizing x86 compiler

On Wed, Jul 30, 2008 at 5:57 PM, Denys Vlasenko <[EMAIL PROTECTED]> wrote: > On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog <[EMAIL PROTECTED]> wrote: >> Raksit Ashok wrote: >>>There is a more optimized version for 64-bit: >>>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/

Re: gcc will become the best optimizing x86 compiler

On Fri, Jul 25, 2008 at 9:08 AM, Agner Fog <[EMAIL PROTECTED]> wrote: > Raksit Ashok wrote: >>There is a more optimized version for 64-bit: >>http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s >>I think this looks similar to your implementation, Agner. > > Yes

Re: gcc will become the best optimizing x86 compiler

On Wed, Jul 30, 2008 at 3:23 PM, Eus <[EMAIL PROTECTED]> wrote: > Hi Ho! > > --- On Tue, 7/29/08, "Dennis Clarke" <[EMAIL PROTECTED]> wrote: > >> hold on .. on the NEWS page I see ... okay .. how very user friendly. >> Sort of the thing one would put on the project homepage I would think. > > Do yo

Re: std::isfinite broken?

Hi ho, ho!! ;) It worked with me. Try a recent gcc (eg, 4.3.x) and you will get the same, actually expected, result of the original poster. Paolo.

Re: frameworklet to assess the quality of debug information

On Mon, Jul 28, 2008 at 06:39:40PM -0300, Alexandre Oliva wrote: > Here's my first cut at trying to tell how well or how bad we perform > in terms of debug info, that can be dropped into the GCC run-time test > infrastructure and used by means of #include in new tests that add > GUALCHK* annotation

Re: gcc will become the best optimizing x86 compiler

Hi Ho! --- On Tue, 7/29/08, "Dennis Clarke" <[EMAIL PROTECTED]> wrote: > hold on .. on the NEWS page I see ... okay .. how very user friendly. > Sort of the thing one would put on the project homepage I would think. Do you mind to tell me what you saw? I was looking for the interesting part on t

Re: std::isfinite broken?

Hi Ho! --- On Tue, 7/29/08, "Neal Becker" <[EMAIL PROTECTED]> wrote: > Paolo Carlini wrote: > > > ... ah, ok, now I see what you meant, you meant that x is *not* finite, > > still, std::isfinite(x) != 0. Still, testcase badly needed... > > > > Paolo. > #include > #include > > int main () { >

Re: Support for OpenVMS host supports

I'm including Doug Rupp who is our VMS expert and is one of the people at AdaCore maintaining the VMS port. > I stumbled in this while looking at how x-* host files are used. There are > two files in this configuration that "must be compiled with DEC C". > > One is vcrt0.o, which has about 5 li

Support for OpenVMS host supports

I stumbled in this while looking at how x-* host files are used. There are two files in this configuration that "must be compiled with DEC C". One is vcrt0.o, which has about 5 lines of executable code. This makes me think that it would be best if someone with access to the OS would compile

Re: failure notice

G Shyam Sundar wrote: > Hi, >I am working with a kernel module, which was compiled using GCC > 4.X, for x86_64 platform. >After dis-assembling the module object file, I see that the callq > function is always called with the next instruction of the code as the > target address(based on IP o

RE: failure notice

G Shyam Sundar wrote on 30 July 2008 10:24: >What I want to understand is, how function calls work here? Google "linking". > I am not sure if this is the right list for this query. Please point > me to the right one if this is not. This is a binutils question really. cheers,

Re: failure notice

Hi, I am working with a kernel module, which was compiled using GCC 4.X, for x86_64 platform. After dis-assembling the module object file, I see that the callq function is always called with the next instruction of the code as the target address(based on IP only), as the offset feild followin

Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types

2008/5/27 Andrew Pinski <[EMAIL PROTECTED]>: > On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote: >> Thank you for the explanation! I didn't realize the difference. >> >> OTOH, do you think that those arithmetic warnings are practical (as opposed >> to being correct)? > > I t

Re: gcc 4.3.0, -Wconversion: assignment-by operators for shorter types

2008/5/28 Andriy Gapon <[EMAIL PROTECTED]>: > on 27/05/2008 22:00 Andrew Pinski said the following: >> >> On Tue, May 27, 2008 at 11:56 AM, Andriy Gapon <[EMAIL PROTECTED]> wrote: >>> >>> Thank you for the explanation! I didn't realize the difference. >>> >>> OTOH, do you think that those arithmeti

Re: frameworklet to assess the quality of debug information

On Tue, Jul 29, 2008 at 9:01 PM, Alexandre Oliva <[EMAIL PROTECTED]> wrote: > On Jul 29, 2008, "Richard Guenther" <[EMAIL PROTECTED]> wrote: > >> why not pair the testcase with a gdb script directly? > > Mostly a matter of convenience. Writing code and adding "test this > here, etc", and not havin

Re: Pedantic error on address-of main breaks libjava bootstrap

Aaron W. LaFramboise wrote: > When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails > with: > >> ./sysdep/backtrace.h: In function '_Unwind_Reason_Code >> fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*), >> _Jv_UnwindState*)': >> ./sysdep/backtrace.h:107: error