Re: Documentation for loop infrastructure

> Here is the documentation for the data dependence analysis. I can add a description of data-refs creation/analysis if it is useful. Ira

gcc-4.2-20060906 is now available

Snapshot gcc-4.2-20060906 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060906/ 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/trunk

Nested namespaces extension

Hi, what is that status of this [1] extension being accepted into GCC? There was some discussion but it died out without a conclusion. [1] -- Vaclav Haisman signature.asc Description: OpenPGP digital signature

Re: problem with zero_extract during gcse

> Currently I'm testing the patch below, which simply invalidates the > load/store. Now I need some help from someone, who is more familiar with > this code, whether this is the correct approach. I don't see any other solution than invalidating the MEM. > Index: gcc/gcse.c > =

Re: [tuples] gimple-tuples-branch created

> Hi folks. > > I've created the gimple-tuples-branch. It is mainline as of Friday, plus > my patches ported to it. The branch is in severely broken mode, as it's > a work in progress. Merging into mainline just brought a whole new set of > bugs :). Can you make sure you update svn.html for th

Re: [tuples] gimple-tuples-branch created

On 9/6/06, Aldy Hernandez <[EMAIL PROTECTED]> wrote: Hi folks. I've created the gimple-tuples-branch. It is mainline as of Friday, plus my patches ported to it. The branch is in severely broken mode, as it's a work in progress. Merging into mainline just brought a whole new set of bugs :).

Re: Meaning of (set (reg:CC condition_codes_reg) (ge (op0) (op1)))

On Sat, 2 Sep 2006, Rask Ingemann Lambertsen wrote: >What does this instruction mean? > > (set (reg:CC 13 cc) > (ge (mem/c/i:HI (plus:HI (reg/f:HI 15 argp) > (const_int 2 [0x2])) [2 x+0 S2 A16]) > (const_int 0 [0x0]))) >... >The (reg:CC 13 cc) part is the condit

Bootstrap of gcc-4.1-20060901 freezes during building of libgfortran

I have tried to compile the last two 4.1 snapshots dated 20060825 and 20060901. In both cases the bootstrap gets stuck while in the section [configure-target-libgfortran]. I am building on a Dual G5 PowerMac running 10.4.7. The following are the configure settings used in the build: ../gc

Re: gcc-4.2-20060906 is now available

On Wed, 6 Sep 2006, [EMAIL PROTECTED] wrote: > Snapshot gcc-4.2-20060906 is now available on > ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060906/ > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. In case anybody wonders about this: since last weeks snapshot w

Re: gcc-4.2-20060906 is now available

On Wed, 6 Sep 2006, Gerald Pfeifer wrote: > On Wed, 6 Sep 2006, [EMAIL PROTECTED] wrote: > > Snapshot gcc-4.2-20060906 is now available on > > ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20060906/ > > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

Re: [tuples] gimple-tuples-branch created

> I think this patch may have fried your brain slightly: > > (get_modify_stmt_operands): Rename from get_modify_stmt_operands. Definitely! Good catch. Fixed.

Linker scripts

GCC passes a linker script to the linker for some targets (e.g., powerpc-eabi with -mads). If you specify a linker script using -Wl,-T,script.ld, you get both passed to the linker and there may be conflicts. Is there any option to GCC which says to not pass the predefined linker script to the li

DWARF2 DW_TAG_base_type for void?

Hi, I have some third party code with the following typedef: typedef void VOID; I found in the readelf dump of the .debug_info section that the corresponding DW_TAG_typedef entry had no DW_AT_type attribute (which usually links to a DW_TAG_base_type entry). It seems that gcc does not emit a DW_

Re: DWARF2 DW_TAG_base_type for void?

On Wed, Sep 06, 2006 at 04:23:58PM -0700, Ron McCall wrote: > I found in the readelf dump of the .debug_info section > that the corresponding DW_TAG_typedef entry had no > DW_AT_type attribute (which usually links to a > DW_TAG_base_type entry). It seems that gcc does not > emit a DW_TAG_base_type

Re: Linker scripts

On Wednesday 06 September 2006 23:00, Michael Eager wrote: > GCC passes a linker script to the linker for some > targets (e.g., powerpc-eabi with -mads). If you specify a > linker script using -Wl,-T,script.ld, you get both > passed to the linker and there may be conflicts. > > Is there any option

Re: DWARF2 DW_TAG_base_type for void?

On Wed, Sep 06, 2006 at 07:39:04PM -0400, Daniel Jacobowitz wrote: > Yes, this is the convention we use. > > Void isn't a base type. The DWARF 3 standard way to represent this is > DW_TAG_unspecified_type. OK, thanks! Ron

g++ question about what libraried

-- Forwarded message -- Date: Tue, 29 Aug 2006 14:38:28 +1000 (EST) From: Serge Bögeholz <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Subject: g++ question To whom it may concern, I'm currently using the following version of g++ g++ (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8) I was w

Re: Linker scripts

On Wed, 2006-09-06 at 15:00 -0700, Michael Eager wrote: > GCC passes a linker script to the linker for some > targets (e.g., powerpc-eabi with -mads). If you specify a > linker script using -Wl,-T,script.ld, you get both > passed to the linker and there may be conflicts. > > Is there any option t

A difficult question about locale_mutex uninitialized

Dear All: We met a problem when using GCC libstdc++.a on PowerPC-OSE platform(it use cross-compile tool with GCC 3.4.1). When starting our application("core_supervisor"), the OSE operation system always outputs the following message: SEH: System call: ose_mutex_lock SEH: Error: A pointer to a

Federal provincial funds available

gcc@gcc.gnu.org CSDGIF.GIF Description: Binary data

Re: comparison is always true due to limited range of data type

On Mon, Aug 14, 2006 at 11:43:29AM +0200, Marcin 'Qrczak' Kowalczyk wrote: > I was told in January that the "comparison is always true due to > limited range of data type" warning has been guarded by > -Walways-true in gcc-4.2.0. But it's still issued unconditionally in > gcc-4.2.0-0.20060806r1159