Re: Documentation for loop infrastructure

[Ira Rosen]

> 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

[gccadmin]

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

You'll find:

gcc-4.2-20060906.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.2-20060906.tar.bz2 C front end and core compiler

gcc-ada-4.2-20060906.tar.bz2  Ada front end and runtime

gcc-fortran-4.2-20060906.tar.bz2  Fortran front end and runtime

gcc-g++-4.2-20060906.tar.bz2  C++ front end and runtime

gcc-java-4.2-20060906.tar.bz2 Java front end and runtime

gcc-objc-4.2-20060906.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.2-20060906.tar.bz2The GCC testsuite

Diffs from 4.2-20060902 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.2
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Nested namespaces extension

[Václav Haisman]

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

[Eric Botcazou]

> 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
> ===
> --- gcc/gcse.c(revision 116085)
> +++ gcc/gcse.c(working copy)
> @@ -5319,6 +5319,16 @@
> else
>   ptr->invalid = 1;
>   }
> +   else if (GET_CODE (dest) == ZERO_EXTRACT)
> + {
> +   dest = XEXP (dest, 0);
> +   if (MEM_P (dest) && simple_mem (dest))
> + {
> +   ptr = ldst_entry (dest);
> +   ptr->invalid = 1;
> + }
> +
> + }
>   }
> else
>   invalidate_any_buried_refs (PATTERN (insn));

Why not simply mimicing the "load" case and calling invalidate_any_buried_refs 
on DEST, with a comment mentioning the (ZERO_EXTRACT (MEM)) corner case?

-- 
Eric Botcazou

Re: [tuples] gimple-tuples-branch created

[Andrew Pinski]

> 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 the new branch?

Thanks,
Andrew Pinski

Re: [tuples] gimple-tuples-branch created

[Daniel Berlin]

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


I think this patch may have fried your brain slightly:

  (get_modify_stmt_operands): Rename from get_modify_stmt_operands.

:) :) :) :)

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

[Hans-Peter Nilsson]

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 condition code register. But I have no
> idea what it means to set that register to a constant (such as
> STORE_FLAG_VALUE).

I'm not sure I understand the question correctly (answer being a
bit on the obvious side), but for me the answer is "the
truthvalue of (argp[1] > 0) in the representation the target
uses for CCmode".  It's not strictly STORE_FLAG_VALUE at this
level; only when "translated" into an ordinary integer mode.
When in CCmode it's just the condition code flags; whatever goes
in reg 13 when being the (possibly implicit) target of that
compare insn.  Hope this helps.

brgds, H-P

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

[Chris Talley]

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:


../gcc-4.1-20060901/configure --prefix=/usr/local/gcc41x --program- 
suffix=-41x --mandir=/usr/local/share/man --infodir=/usr/local/share/ 
info --with-gmp=/usr/local/gmp421/ --with-mpfr=/usr/local/mpfr220/ -- 
enable-languages=c,c++,fortran --enable-werror --disable-multilib -- 
enable-shared --enable-static --with-included-gettext


I've attached a gzip copy of the make file outout showing where it  
got stuck. I've never previously had this problem when I compiled GCC  
4.1.1 with gfortran support.




Thanks,

Chris Talley




gcc41x_make.log.gz
Description: GNU Zip compressed data

Re: gcc-4.2-20060906 is now available

[Gerald Pfeifer]

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 was
broken (on BSD, at least), and I want to give current SVN HEAD as
much exposure as possible I reran the snapshot script manually and
updated the lang/gcc42 port in FreeBSD which is undergoing testing
right now.

Obviously, this is something we shouldn't do every other day, but if
any of you at one point needs a one-off snapshot for some similar reason, 
I'll be happy to help.

Gerald

Re: gcc-4.2-20060906 is now available

[Joseph S. Myers]

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.
> 
> In case anybody wonders about this: since last weeks snapshot was
> broken (on BSD, at least), and I want to give current SVN HEAD as
> much exposure as possible I reran the snapshot script manually and
> updated the lang/gcc42 port in FreeBSD which is undergoing testing
> right now.

So that explains why there's a huge diff mostly reordering the MD5SUMS 
file (the locale when logged in interactively must be different from that 
under cron).  (Perhaps the script should set LC_ALL=C to avoid such 
variation.)

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [tuples] gimple-tuples-branch created

[Aldy Hernandez]

> 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

[Michael Eager]

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

--
Michael Eager[EMAIL PROTECTED]
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077

DWARF2 DW_TAG_base_type for void?

[Ron McCall]

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_TAG_base_type entry for void.  Is that
intentional?

In this program there are only DW_TAG_pointer_type
entries linking to this DW_TAG_typedef entry.  Without
the typedef, I would have expected (perhaps naively)
that the DW_TAG_pointer_type would link to a
DW_TAG_base_type for void (in the case of a void *
pointer type).  Is that not the case?

I am using gcc 4.0.3 and binutils 2.16.1 in case that
matters.

Just curious.

Ron McCall

Re: DWARF2 DW_TAG_base_type for void?

[Daniel Jacobowitz]

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 entry for void.  Is that
> intentional?

Yes, this is the convention we use.

> In this program there are only DW_TAG_pointer_type
> entries linking to this DW_TAG_typedef entry.  Without
> the typedef, I would have expected (perhaps naively)
> that the DW_TAG_pointer_type would link to a
> DW_TAG_base_type for void (in the case of a void *
> pointer type).  Is that not the case?

Void isn't a base type.  The DWARF 3 standard way to represent this is
DW_TAG_unspecified_type.

-- 
Daniel Jacobowitz
CodeSourcery

Re: Linker scripts

[Paul Brook]

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 to GCC which says to not pass
> the predefined linker script to the linker?

Fix the config so it doesn't add the default script when the user specifies a 
linker script.

You whould probably be using -T, not -Wl,-T.

Paul

Re: DWARF2 DW_TAG_base_type for void?

[Ron McCall]

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

[Serge Bögeholz]

-- 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 writing some code to test the  toupper(ch) library function that
is found in the cctype library.

I noticed I had not entered the line

#include 

in my C++ program,  yet my program compiled and ran correctly as though I had.

**
I've included the source file as an attachment to this email, and here is the 
output of the program:


% a.out
temp = h
To upper conversion: H
 *

Why did this work - all the C++ books I've read state that you need to
include the cctype library if you want to use the toupper(..) function.

Also, is there any documentation on this matter. (I've look around the GNU site 
and am at a loss as to where to look/find this type of information)


Kind regards
serge#include
using namespace std;

int main()
{
  char temp = 'h';

  cout << "temp = " << temp << endl;

  cout << "To upper conversion: " << char(toupper(temp)) << endl;

  return 0;
}

Re: Linker scripts

[Andrew Pinski]

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 to GCC which says to not pass
> the predefined linker script to the linker?

sysv4.h has "%{!Wl,-T*: %{!T*: %(link_start) }}" which should mean don't
do link_start (which contains the -T for -mads) when supplying -T or
-Wl,-T.  Now is it really working is different story.

Thanks,
Andrew Pinski

A difficult question about locale_mutex uninitialized

[FCG WANG Baohua]

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 an uninitialized mutex (at 0x00b27988) was presented to
 the kernSEH: Information about current process "core_supervisor"
SEH: Pid 0x0001000b bid 0x00010008 progpid 0x
SEH: Callstack backtrace:
SEH: FrameAddress ReturnAddress FrameSize
SEH:  0x0aa54390   - -
SEH: Analyzing pool of faulty process

After looked up our system.map file, we found that it always refer the 
following pointer:

 .bss0x00b27988   0x20 
/vobs/rtosdev/OSE/gcc_solaris2_powerpc_3.4.2/powerpc-eabi/lib/nof/libstdc++.a(locale_init.o)
 0x00b27988  __gnu_internal::locale_mutex

I want to know how to find the bug? 
It is the problem of the libstdc++ or our application ? 
How to rightly initialize the locale_mutex ? 
Why it isn't initialized in  libstdc++.a under OSE ?

thanks a lot.

Federal provincial funds available

[shop127]

gcc@gcc.gnu.org



CSDGIF.GIF
Description: Binary data

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

[Ben Elliston]

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

-Walways-true does handle some warnings in this way, but the warning you refer 
to is not one of them:

  warning (0, "comparison is always true due to limited range of data type");

This could and should be fixed.

Cheers, Ben