Re: In current gcc trunk: warning: dereferencing type-punned pointer will break strict-aliasing rules

Christian Joensson wrote: I'd just like to ask if this is noticed: /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:324: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:789: warning: dereferencing type-punned pointer will break stric

Re: Software pipelining capabilities

> Vasanth writes: Vasanth> My question is, am I expecting the wrong version of GCC to be doing Vasanth> this. I saw the following thread about SMS. Vasanth> http://gcc.gnu.org/ml/gcc/2003-09/msg00954.html Vasanth> that seems relevant. Would GCC 4.x be a better version for my Vasanth> requir

strange double comparison results with -O[12] on x86(-32)

Hello, last weekend I got some strange results from a C-program doing some comparisons on double-values. I know, usually it's no good idea to compare two doubles with "==". But when they are calculated from the same values with the same operations, both doubles should have the same value, shouldn'

Re: strange double comparison results with -O[12] on x86(-32)

On Jun 13, 2005, at 10:21 AM, Christian Bodenstedt wrote: last weekend I got some strange results from a C-program doing some comparisons on double-values. I know, usually it's no good idea to compare two doubles with "==". But when they are calculated from the same values with the same operat

Re: strange double comparison results with -O[12] on x86(-32)

On 2005-06-13 10:22:34 -0400, Andrew Pinski wrote: > On Jun 13, 2005, at 10:21 AM, Christian Bodenstedt wrote: > >last weekend I got some strange results from a C-program doing some > >comparisons on double-values. I know, usually it's no good idea to > >compare two doubles with "==". But when they

RFA: Integrate ABI testsuite in GCC

Hi, I have this x86-64 ABI testsuite I worked on lately again (after some years lingering around, it was first written when we did the port on simulators still). It currently lies on cvs.x86-64.org in the 'abitest' module, for the curious (it has anoncvs too). I would like to somehow integrat

Re: strange double comparison results with -O[12] on x86(-32)

* Andrew Pinski: > This is known as GCC PR 323 which is not a bug: > . It is a bug in GCC, the C standard, or the x86 FP hardware. I'm leaning towards the C standard or the hardware. 8-)

RE: Big differences on SpecFP results for gcc and icc

Steven, > > An interesting examples are: > > -177.mesa (this is a c test), where icc is almost 40% faster > > It would be interesting to look into this one. A combination of SSE instead of x87, vectorization, vectorized math library, and very good whole-program IPA. -- _

Re: Big differences on SpecFP results for gcc and icc

On Mon, Jun 13, 2005 at 11:20:24AM -0500, Menezes, Evandro wrote: > A combination of SSE instead of x87, vectorization, vectorized > math library, > Yes. > and very good whole-program IPA. > Not at -O2. Diego.

RE: Big differences on SpecFP results for gcc and icc

Robert, > > I know that these graphs don't show the results of most aggresive > > optimization options for gcc, but that is also the case > with icc (only > > -O2). However, it looks that gcc and icc are not even in the same > > class regarding FP performance. Perhaps there is some critical

GCC 4.0.1 Status (2005-06-13)

Those who have been watching carefully will note that there is no sign of an actual 4.0.1 release. There are two blocking issues at the moment: 1. Benjamin Kosnik reports that there are ABI and/or version-symbol problems between 3.4.x and 4.0.x version of libstdc++, and is trying to sort out

Re: Big differences on SpecFP results for gcc and icc

Menezes, Evandro wrote: > Each HPC application tends to be unlike others, making it difficult > to optimize GCC for an elusive typical FP application. Not that > there isn't room for improvement though. The performance of almost any HPC application can be isolated to specific key loops, and every

Re: GCC 4.0.1 Status (2005-06-13)

Mark Mitchell wrote: > 2. Jakub Jelinek reports that we're miscompiling GLIBC. > > The latter problem seems to me to be as severe as the KDE bug that was > the impetus for this release. The libstdc++ problem also seems serious. Agreed. I've had mixed reports from folks over in the Gentoo univers

GCC port for the TI TMS320C5{4,5}x

Hello, We are currently looking for experienced GCC hackers to help implement and complete a GCC port for the Texas Instruments TMS320C54x. This chip is used in the Neuros music player, as well as in the Nokia 770 internet tablet. Joe Born of NeurosAudio is ready to compensate porters for their

RE: strange double comparison results with -O[12] on x86(-32)

Original Message >From: Florian Weimer >Sent: 13 June 2005 16:08 > * Andrew Pinski: > >> This is known as GCC PR 323 which is not a bug: >> . > > It is a bug in GCC, the C standard, or the x86 FP hardware. I'm > leaning towards the C standard or the hardware. 8

Re: strange double comparison results with -O[12] on x86(-32)

* Dave Korn: >> It is a bug in GCC, the C standard, or the x86 FP hardware. I'm >> leaning towards the C standard or the hardware. 8-) > > > ... or it's a bug in the libc/crt-startup, which is where the > hardware rounding mode is (or should be) set up ... I think you'd still experience latent

Problem with recompute_tree_invarant_for_addr_expr

Hello, I have run into the following problem: recompute_tree_invarant_for_addr_expr says that address of a decl is invariant if it is a decl in the current function: if (decl_function_context (node) == current_function_decl) ... /* set TREE_INVARIANT */ This has a small flaw -- in case NODE

Re: Tracking down source of libgcc_s.so compatibility?

On Thu, 09 Jun 2005 15:47:31 +0200, Marcin Dalecki wrote: > NTPL vers. non NTPL signal handling differences. The FC3 compiler contains > some "backward compatibility" shims at quite a few places, which are > allowing old binaries to execute. However stuff compiled with the FC3 > version of the comp

Re: Problem with recompute_tree_invarant_for_addr_expr

On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote: > This has a small flaw -- in case NODE has variable size, it gets > allocated on stack dynamically, it may be allocated and deallocated > several times, and its address is no longer an invariant. > > So I tried to fix the code as foll

Re: GCC 4.0.1 Status (2005-06-13)

Scott Robert Ladd wrote: Mark Mitchell wrote: 2. Jakub Jelinek reports that we're miscompiling GLIBC. [I think this is http://gcc.gnu.org/PR22043 ] The latter problem seems to me to be as severe as the KDE bug that was the impetus for this release. ... Agreed. I've had mixed reports from

Re: Problem with recompute_tree_invarant_for_addr_expr

Hello, > On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote: > > This has a small flaw -- in case NODE has variable size, it gets > > allocated on stack dynamically, it may be allocated and deallocated > > several times, and its address is no longer an invariant. > > > > So I tried to

Re: rationale for bss patterns in default_section_type_flags ?

On Jun 10, 2005, at 6:04 PM, Brett Porter wrote: Doing an exact match on that name in default_section_type_flags_1 is a nice solution for our needs. Ok, sounds good. The reason for our query was twofold: are there standards (of any form :) that such a choice would be incompatible with? If

PATCH: Explicitly pass --64 to assembler on AMD64 targets

This patch makes x86-64.h pass "--64" to the assembler when compiling in 64-bit mode. There are several advantages: 1. For a bi-arch compiler for which 32-bit code is the default, we no longer need to override ASM_SPEC. 2. We get earlier failure and better error messages from the assembler

Re: Tracking down source of libgcc_s.so compatibility?

Mike Hearn wrote: On Thu, 09 Jun 2005 15:47:31 +0200, Marcin Dalecki wrote: NTPL vers. non NTPL signal handling differences. The FC3 compiler contains some "backward compatibility" shims at quite a few places, which are allowing old binaries to execute. However stuff compiled with the FC3 versi

Re: Big differences on SpecFP results for gcc and icc

Scott Robert Ladd wrote: > > My conclusion is the composite switches like -O2 are good only for > general-purpose code. Anyone explicitly interested in squeezing out the > most performance needs to do analysis and use application-specific switches. > Probably this situation is created by the fac

Re: rationale for bss patterns in default_section_type_flags ?

Mike, Thanks for the feedback. We'll continue along the path we seem to agree upon... hoping we don't run into any hitches. Brett

[PATCH] Change bb-reorder.c to use succ block frequency

The following patch fixes the code to match the commentary of the algorithm such that block frequency is used instead of edge frequency. The change is pretty much neutral on SPEC, max differences of +/- 1% with most showing no difference. Bootstrapped and regtested on powerpc64-unknown-linux-

Re: ld: common symbols not allowed with MH_DYLIB output format with the -multi_module option

> Sigh. #2 doesn't work as the compiler can synthesize common > variables that you can't control, and when it does this, things > won't work. Forcing people to use -single_module strikes me as > wrong. I don't know why it was set up like that. Come to think of it, this would probably be a rea

Re: In current gcc trunk: warning: dereferencing type-punned pointer will break strict-aliasing rules

Nathan Sidwell <[EMAIL PROTECTED]> wrote: > Christian Joensson wrote: >> I'd just like to ask if this is noticed: >> >> /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:324: warning: dereferencing >> type-punned pointer will break strict-aliasing rules >> /usr/local/src/trunk/gcc/gcc/unwind-dw2.c:789: wa

Re: RFA: Integrate ABI testsuite in GCC

> I have this x86-64 ABI testsuite I worked on lately again (after some > years lingering around, it was first written when we did the port on > simulators still). It currently lies on cvs.x86-64.org in the 'abitest' > module, for the curious (it has anoncvs too). > I would like to somehow integra

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote: > 1. For a bi-arch compiler for which 32-bit code is the default, we no >longer need to override ASM_SPEC. Well, this is the only way this patch applies, because... > 2. We get earlier failure and better error messages from the as

Re: [PATCH] Change bb-reorder.c to use succ block frequency

On Mon, Jun 13, 2005 at 02:06:38PM -0500, Pat Haugen wrote: > The following patch fixes the code to match the commentary of the algorithm > such that block frequency is used instead of edge frequency. Why? It seems to me that edge frequency is what's going to matter to the cpu when considering th

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

On Mon, Jun 13, 2005 at 12:56:36PM -0700, Richard Henderson wrote: > On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote: > > 1. For a bi-arch compiler for which 32-bit code is the default, we no > >longer need to override ASM_SPEC. > > Well, this is the only way this patch applies,

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

On Mon, Jun 13, 2005 at 04:03:15PM -0400, Daniel Jacobowitz wrote: > How would you feel about a patch that made us always pass --64 > as appropriate, at least if the assembler in question is gas? I have no problem with that. r~

Re: Problem with recompute_tree_invarant_for_addr_expr

Hello, > On Mon, Jun 13, 2005 at 07:39:33PM +0200, Zdenek Dvorak wrote: > > This has a small flaw -- in case NODE has variable size, it gets > > allocated on stack dynamically, it may be allocated and deallocated > > several times, and its address is no longer an invariant. > > > > So I tried to

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

* Daniel Jacobowitz: > How would you feel about a patch that made us always pass --64 > as appropriate, at least if the assembler in question is gas? I > periodically bootstrap on a 64-bit kernel with a 32-bit root FS. But > the assembler and linker are biarch, and the 64-bit libs are installed,

Re: Use of check_vect() in vectorizer testsuite

On Jun 10, 2005, at 2:01 PM, Dorit Naishlos wrote: Devang, is vect-dv-2.c a duplicate of vect-ifcvt-1.c or are they both there on purpose? It is duplicate. I'll remove vect-dv-2.c tomorrow, unless I hear otherwise. - Devang

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

Daniel Jacobowitz wrote: On Mon, Jun 13, 2005 at 12:56:36PM -0700, Richard Henderson wrote: On Mon, Jun 13, 2005 at 11:16:04AM -0700, Mark Mitchell wrote: 1. For a bi-arch compiler for which 32-bit code is the default, we no longer need to override ASM_SPEC. Well, this is the only way thi

[gomp] New branch for OpenMP: gomp-20050608-branch

After two false starts, we now have enough bits to start adding real OpenMP support to GCC. Since CVS branches slow down as time goes by, it is better to start with a brand new branch. I cut gomp-20050608-branch last week and added Dmitry's parser, Richard's libgomp and some initial IL bits to co

Re: GCC 4.0.1 Status (2005-06-05)

Mark Mitchell <[EMAIL PROTECTED]> writes: > Andrew Pinski wrote: > > On Jun 5, 2005, at 1:41 PM, Devang Patel wrote: > > > >> > >> On Jun 5, 2005, at 10:18 AM, Mark Mitchell wrote: > >> > >>> Here are three bugs I'd really like to see fixed. > >>> > >>> * 21528: SRA and/or aliasing problem. > >>>

Re: A Suggestion for Release Testing

On Jun 12, 2005, at 10:51 AM, Gerald Pfeifer wrote: Note, though, that this is only one part of the equation. A most significant amount of work also goes into analysing and potentially fixing packages which do not compile any longer and submit fixes upstream. :-( Sometimes we wish that gcc ha

Re: strange double comparison results with -O[12] on x86(-32)

Florian Weimer wrote: * Andrew Pinski: This is known as GCC PR 323 which is not a bug: . It is a bug in GCC, the C standard, or the x86 FP hardware. I'm leaning towards the C standard or the hardware. 8-) Well it is only a bug in that you Florian have decided th

Re: strange double comparison results with -O[12] on x86(-32)

Dave Korn wrote: ... or it's a bug in the libc/crt-startup, which is where the hardware rounding mode is (or should be) set up ... Well if you think that the operations should reflect IEEE 64-bit semantics (which is the only rationale for mucking with the rounding mode in the startup), then

Re: Problem with recompute_tree_invarant_for_addr_expr

On Mon, Jun 13, 2005 at 10:54:23PM +0200, Zdenek Dvorak wrote: > OK, I remembered. I put > > if (is_gimple_min_invariant (t)) > > or > > if (is_gimple_val (t)) > { > shortcut; > } > > type constructs on some places in gimplification. With an aim toward speeding up gimplification, I gu

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

Mark Mitchell <[EMAIL PROTECTED]> writes: > I would be in favor of making the mode always explicit, as you suggest > -- but I would prefer that we not embed the assumption that the > default mode is 64-bit mode in x86-64.h so that we can continue to use > that file for 32-bit default compilers. (

Re: A Suggestion for Release Testing

I've been doing regular builds of Fink against Apple's branch, building our last release alongside our latest engineering build and comparing the two. See: http://cvs.sourceforge.net/viewcvs.py/fink/scripts/buildfink/ http://fink.opendarwin.org/build/2005-05-08/out/report.html

Re: A Suggestion for Release Testing

On Jun 13, 2005, at 10:36 PM, Matthew Sachs wrote: I've been doing regular builds of Fink against Apple's branch, building our last release alongside our latest engineering build and comparing the two. See: http://cvs.sourceforge.net/viewcvs.py/fink/scripts/buildfink/ http://fink.ope

Re: a "hello world" frontend

Em Sun 12 Jun 2005 23:58, James A. Morrison escreveu: > Was there anything in particular that you found hard to understand in the > treelang frontend. It is supposed to be the example/tutorial front-end. One thing is that the parser is very big and mixed with C code. I find it easier to read a p

Re: a "hello world" frontend

Rafael Ávila de Espíndola <[EMAIL PROTECTED]> writes: > Em Sun 12 Jun 2005 23:58, James A. Morrison escreveu: > > Was there anything in particular that you found hard to understand in the > > treelang frontend. It is supposed to be the example/tutorial front-end. > One thing is that the parser

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote: > Or, if GAS can be told which mode it should be in via directives in > its input (.code32/.code64?), then we could add something like > > fputs (TARGET_64BIT ? "\t.code64\n" : "\t.code32", > asm_out_file); > > to x86_file_s

Re: Use of check_vect() in vectorizer testsuite

Devang Patel <[EMAIL PROTECTED]> wrote on 14/06/2005 00:24:27: > > On Jun 10, 2005, at 2:01 PM, Dorit Naishlos wrote: > > > Devang, is vect-dv-2.c a duplicate of vect-ifcvt-1.c or are they > > both there > > on purpose? > > It is duplicate. I'll remove vect-dv-2.c tomorrow, unless I hear > othe

Re: A Suggestion for Release Testing

Scott Robert Ladd wrote: Given the recent problems with the 4.0.0 release and major packages like KDE and the kernel, has anyone considered testing releases by completely compiling a Linux system? I'm all for more testing -- but I have a standard rant about it being easier to run tests than to

Re: PATCH: Explicitly pass --64 to assembler on AMD64 targets

Richard Henderson <[EMAIL PROTECTED]> writes: > On Mon, Jun 13, 2005 at 07:17:24PM -0700, Zack Weinberg wrote: >> Or, if GAS can be told which mode it should be in via directives in >> its input (.code32/.code64?), then we could add something like >> >> fputs (TARGET_64BIT ? "\t.code64\n" : "\t.