Re: Shipping gmp and mpfr with gcc-4.0?

[Vincent Lefevre]

On 2005-02-17 01:15:29 +0100, Marcin Dalecki wrote:
> On 2005-02-16, at 12:32, Vincent Lefevre wrote:
> >Do not use the MPFR version that comes with GMP. It is too old.
> >Remember that you can override the default by setting CFLAGS.
> 
> The documentation doesn't say this. The configure scripts don't
> check for it.

Concerning CFLAGS, this is something standard, documented in the
manual of "make". For consistency, the configure script shouldn't
try to override it (if it is set).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Added myself to MAINTAINERS (write after approval)

[Ira Rosen]

Index: MAINTAINERS
===
RCS file: /cvs/gcc/gcc/MAINTAINERS,v
retrieving revision 1.395
diff -c -3 -p -r1.395 MAINTAINERS
*** MAINTAINERS 14 Feb 2005 11:21:09 -  1.395
--- MAINTAINERS 17 Feb 2005 08:50:31 -
*** Volker Reichelt
[EMAIL PROTECTED]
*** 287,292 
--- 287,293 
  Tom Rix   [EMAIL PROTECTED]
  Craig Rodrigues   [EMAIL PROTECTED]
  Gavin Romig-Koch  [EMAIL PROTECTED]
+ Ira Rosen   [EMAIL PROTECTED]
  Ira Ruben [EMAIL PROTECTED]
  Douglas Rupp  [EMAIL PROTECTED]
  Matthew Sachs [EMAIL PROTECTED]

GCC problem with using "-fprofile-arcs"

[Wei . Feng]

Hi, there:
I tried using the "-fprofile-arcs" and "-fbranch-probabilities" to build a 
profile based optimized binary, but got some complain about the .da files.

The OS: Red Hat Enterprise Linux WS release 3 (Taroon Update 3) Kernel 
2.4.21-20.ELsmp on an x86_64
The GCC: gcc (GCC) 3.2.3 20030502 (Red Hat Linux 3.2.3-34)

I use "-fprofile-arcs' to compile and build the instrumented binary, 
command is sth. like:
gcc -c -pipe -m64 -fno-omit-frame-pointer -fprofile-arcs -p -O -D... -I... 
-o treeprint.o treeprint.c 

Then run the binary, more than 900 .da file created. (A big application)

Finally, use "-fbranch-probabilities" to build again, most of the files 
got success, only 5 failed. Command is sth. like:
gcc -c -pipe -m64 -fno-omit-frame-pointer -fbranch-probabilities -p -O 
-D... -I... -o treeprint.o treeprint.c 

The fail message is:
/usr/include/bits/sigset.h: At top level:
/usr/include/bits/sigset.h:119: .da file contents not exhausted
...failed Cc treeprint.o ...


I wonder if this is a known issue of GCC (A Bug)?
Or there are some limitations of using "-fprofile-arcs"? 
Such as you can not combine it with "-O", "-O2" etc. Or you can not have 
"goto" in the source files etc.?

Thanks
Wei

Re: SVN Test Repo updated

[Vincent Lefevre]

On 2005-02-17 01:48:37 +0100, Marc Espie wrote:
> Dare I say it ?
> I don't want any locale behavior in a version control system.
> Specifically because there are client/server issues, and you never
> know which is which.  I've seen enough trouble with cvs timestamps.
> 
> If/when gcc switches to svn, please, please, please try very hard to
> ensure that any time coming out of svn or going in is in UTC by default,
> and that the user will have to push very hard to get local time.

It depends on the commands/features. For instance, the Date keyword gets
the local time (a bad idea IMHO, for keywords), and the Id keyword gets
the UTC time. "svn log" gives the local time. You can still use aliases
and/or wrappers to set TZ=UTC and always get UTC time.

> I remember trying to find a bug by dichotomy, and having a real hard
> time figuring out which parts of the log were in Mountain Time, which
> were in GMT, how to convert between the two, while trying to actually
> find that darn bug.

AFAIK, Subversion uses UTC time internally, but always works with the
local time of the user for the interface (I don't know what happens for
ambiguous dates, due to summer/winter times). Anyway, Subversion has
global revisions, so that doing a dichotomy is much easier than with
CVS, and using times is not necessary.

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

gcc@gcc.gnu.org

[Richard Guenther]

On Wed, 16 Feb 2005 10:51:58 -0500, Andrew Pinski
<[EMAIL PROTECTED]> wrote:
> 
> On Feb 16, 2005, at 10:49 AM, Theodore Papadopoulo wrote:
> 
> > Then, I must add that I do not know much about the compiler's
> > internals...
> 
> If a[-1] os converted to a[(unsigned)-1], this is fine iff unsigned is
> the same size as pointers.

Ok, as the conversion is done to (int *) which is unsigned and of
course of size of pointers
it came to my mind that just casting back that one to signed for the
index arithmetic should work.
I'll try that.

Thanks for all the suggestions,
Richard.

Problem in GCC porting...

[vivek]

Hello All

We are trying to fix the already ported GCC 2.95 on the ABACUS processor.
ABACUS processor is very much similar to SPARC from SUN.

We are facing 2 major problems in the fixing.

1. Variable initialization within block: If we declare and initialize a
variable within a block in the function, initialization happens only at
the first time, not every time, if code enters that block again.

main()
{
---
---
   {
   int a = 10;
   a += 10;
   }
---
---
}

In the above case if we enter the block inside main for second time or
more the value of 'a' get continued as of 'static' variable.

2. Function  pointer returning some value:
In case of function pointers returning something we are not able to
collect the same in the return register or variable.

These 2 errors in the compiler is causing problems in other activities also.

If anyone could through some light on these issues this will help me a lot.

Please send me reply on my ID [EMAIL PROTECTED] as I am not a member of
this group.

Thanks in anticipation...

VIVEK

RE: Accessing the subversion repository

[Andrew STUBBS]

> Recent versions of openssh support multiple connections through one
> single authentication token (`master' connection)

That might work, but you need version OpenSSH 3.9 I think. svn.toolchain.org
is running 3.8.1p1 and gcc.gnu.org is running 3.6.1p2.

I assume both ends need to support it but I can't easily test that
assumption because I don't have 3.9 locally either.

Thanks anyway

-- 
Andrew Stubbs

Re: SVN Test Repo updated

[Marc Espie]

In article <[EMAIL PROTECTED]> you write:
>AFAIK, Subversion uses UTC time internally, but always works with the
>local time of the user for the interface (I don't know what happens for
>ambiguous dates, due to summer/winter times). Anyway, Subversion has
>global revisions, so that doing a dichotomy is much easier than with
>CVS, and using times is not necessary.

Bottom-line: it's very easy to shoot oneself in the foot while writing
wrapper scripts. The default interface will give you local time listing,
anything  you generate from that will have localtime listing, so any
`nice' meta-generated information can have issues.

Bad decision, IMO. And something to REALLY watch out for when/if GCC
switches to subversion.

Bug status in Bugzilla

[Michael Cieslinski]

Hello,
I reported 2 bugs (bug19951 and bug19952) on Monday which were
apparently reproduced the same day.
However their status remains UNCONFIRMED.

As far as I understand the bugzilla system the status of a bug is set
to NEW if it is verified that this is indeed a bug.

Also if their status would be changed to NEW they would show up in the
list of open bugs and could be easily found by other users which would
avoid duplicate bug reports.

Michael Cieslinski

Re: Bug status in Bugzilla

[Giovanni Bajo]

Michael Cieslinski <[EMAIL PROTECTED]> wrote:

> I reported 2 bugs (bug19951 and bug19952) on Monday which were
> apparently reproduced the same day.
> However their status remains UNCONFIRMED.


It must have been an oversight on our side.

Giovanni Bajo

Re: GCC 4.0 Status Report (2005-02-03)

[Gerald Pfeifer]

On Wed, 9 Feb 2005, Mark Mitchell wrote:
> As for making all proposals public, some people have asked that they be 
> kept confidential because they didn't want to put out ideas publicly 
> that were going to have no chance of being included.

Personally, that sounds somewhat strange for contributions to an open 
source project, and I would strongly prefer all proposals to be public
to counter any FUD anyone might spread on our processes.

(That said, I'll note that I found your description of the process in 
develop.html very well done; that certainly is very useful, thanks.)

Gerald

TYPE_MIN_VALUE and pointer types

[Richard Guenther]

Hi!

I'm getting an ICE in

/net/pherkad/scratch/rguenth/gcc/gcc/testsuite/gcc.dg/pr18241-2.c: In
function 'radix_tree_tag_clear':
/net/pherkad/scratch/rguenth/gcc/gcc/testsuite/gcc.dg/pr18241-2.c:24:
internal compiler error: tree check: expected integer_type or
enumeral_type or boolean_type or char_type or real_type, have pointer_type
in int_fits_type_p, at tree.c:4903

this is because I'm feeding int_fits_type_p a (constant) pointer type:

 constant
invariant 1>

i.e. I'm calling

  if ((TREE_CODE (delta) == INTEGER_CST
   && ! int_fits_type_p (delta, itype))

am I supposed not to do this if delta is a pointer type ever?  Who
is wrong here?  TYPE_MIN_VALUE does

#define TYPE_MIN_VALUE(NODE) (NUMERICAL_TYPE_CHECK (NODE)->type.minval)

and NUMERICAL_TYPE_CHECK

#define NUMERICAL_TYPE_CHECK(T) \
  TREE_CHECK5 (T, INTEGER_TYPE, ENUMERAL_TYPE, BOOLEAN_TYPE,\
   CHAR_TYPE, REAL_TYPE)

Any ideas, other than converting delta to the equivalent integer type?

Thanks,
Richard.

--
Richard Guenther 
WWW: http://www.tat.physik.uni-tuebingen.de/~rguenth/

__LDBL_MAX__ exceeds range of 'long double'

[Jonathan Wakely]

I'm hoping someone knows what this is due to, can't see anything in bugzilla.

$ cat bug.c
long double f = __LDBL_MAX__;
$ gcc4x -c bug.c
$ gcc4x -c bug.c -pedantic -save-temps
bug.c: In function 'main':
bug.c:1: error: floating constant exceeds range of 'long double'

I only get the error with -pedantic /and/ -save-temps, compiles fine if
only one of those options is used.

This is with mainline on i386-unknown-freebsd4.8, also seen with a week
old mainline build.

gcc4x -E -dM gives:
#define __LDBL_MAX__ 1.18973149535723176502e+4932L
Which is the same as for a 3.4.4 20050118 build I have which compiles
the code above fine.

Any ideas?

jon

-- 
"The tools we use have a profound (and devious!) influence on our
 thinking habits, and, therefore, on our thinking abilities."
- Edsger Dijkstra

TYPE_MIN_VALUE and pointer types

[Paul Schlie]

> Richard Guenther wrote:
> I'm getting an ICE in
> this is because I'm feeding int_fits_type_p a (constant) pointer type:

- Wonder if because it was assumed that a pointer may most typically never
  numerically "fit" an (signed) int without overflow, but as I think you're
  relying on the numerical overflow to get the correct sign result when
  casting to an equivalent sized integer, maybe that's what you want to
  assure, i.e. assure that you do cast to an equivalent sized integer type.

  (although int_fits_type_p should likely handle pointer arguments as well
  for completeness, even if not likely not applicable to your purpose)?

Re: TYPE_MIN_VALUE and pointer types

[Richard Guenther]

On Thu, 17 Feb 2005, Paul Schlie wrote:

> > Richard Guenther wrote:
> > I'm getting an ICE in
> > this is because I'm feeding int_fits_type_p a (constant) pointer type:

Actually I was feeding it a constant integer trying to ask if it would
fit a pointer type.  This makes TYPE_MIN_VALUE fail.  All this index
typing really is a mess - I'll post a current-status patch if it
bootstraps and regtests on at least one 32bit and one 64bit platform.

If only everyone would build4 ARRAY_REFs with TYPE_DOMAIN (..)
typed indices...

Richard.

Re: __LDBL_MAX__ exceeds range of 'long double'

[Jonathan Wakely]

On Thu, Feb 17, 2005 at 01:22:30PM +, Jonathan Wakely wrote:

> 
> I'm hoping someone knows what this is due to, can't see anything in bugzilla.
> 
> $ cat bug.c
> long double f = __LDBL_MAX__;
> $ gcc4x -c bug.c
> $ gcc4x -c bug.c -pedantic -save-temps
> bug.c: In function 'main':
> bug.c:1: error: floating constant exceeds range of 'long double'
> 
> I only get the error with -pedantic /and/ -save-temps, compiles fine if
> only one of those options is used.

Actually, I get a warning with -pedantic -save-temps, error with
-pedantic-errors -save-temps (or with g++ -pedantic -save-temps)

Sorry for any confusion

jon

-- 
"The easy confidence with which I know another man's religion is Folly
 leads me to suspect that my own is also."
- Mark Twain

LC_COLLATE (was Re: SVN Test Repo updated)

[Paolo Bonzini]

The sort alghorithm has nothing to do with ls, but with your selection of
LC_COLLATE.  But then, BSD (at least the variant used in MacOSX) is way
behind current l10n standards.
At least they do not break s/[A-Z]// which on "well-internationalized" 
OSes is case-insensitive with most locales other than C.

I still haven't dug enough to understand if the responsible for this is 
the POSIX specification for localization, the ANSI specification for 
strcoll, or somebody in the glibc team.  But I know that it was the 
most-reported sed "bug" before I explicitly flagged it as a non-bug in 
the manual.

I can only guess the outcry if Perl started obeying LC_COLLATE.
Paolo

Re: SVN Test Repo updated

[Vincent Lefevre]

On 2005-02-17 12:48:03 +0100, Marc Espie wrote:
> Bottom-line: it's very easy to shoot oneself in the foot while writing
> wrapper scripts. The default interface will give you local time listing,
> anything  you generate from that will have localtime listing, so any
> `nice' meta-generated information can have issues.

You can still set TZ to UTC, so that localtime = UTC time. Subversion
is not the only program that deals with local time.

Also note that Subversion provides timezone information (except for
svn ls -v).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

Re: SVN Test Repo updated

[Daniel Berlin]

On Thu, 2005-02-17 at 12:48 +0100, Marc Espie wrote:
> In article <[EMAIL PROTECTED]> you write:
> >AFAIK, Subversion uses UTC time internally, but always works with the
> >local time of the user for the interface (I don't know what happens for
> >ambiguous dates, due to summer/winter times). Anyway, Subversion has
> >global revisions, so that doing a dichotomy is much easier than with
> >CVS, and using times is not necessary.
> 
> Bottom-line: it's very easy to shoot oneself in the foot while writing
> wrapper scripts. The default interface will give you local time listing,
> anything  you generate from that will have localtime listing, so any
> `nice' meta-generated information can have issues.

> Bad decision, IMO. And something to REALLY watch out for when/if GCC
> switches to subversion.

All of the "meant to be parsable" outputs (ie svn ls --xml) give you
time zone info. If you shoot yourself in the foot after being given
explicit information about what the time zone is for a given date, well,
then, ...
:)

Quick Question

[Rajkishore Barik]

Hi,

Is there a way to determine if the given RTX is 
accessing an array element or not? If yes, how do I determine the 
static size of that array from the given RTX?

Thanks a lot in advance.
regards,
Raj

gcc #pragma pack(push[,n]) target spesific ?

[Matthew J Fletcher]

Hi

on my i486-unknown-elf target i am unable to use #pragma pack(push[,n]) / 
#pragma pop(n), which happen to be the same as Microsofts #pragma syntax.

this is because HANDLE_PRAGMA_PACK_PUSH_POP is only defined for 
linux/i386/alpha/sparc freebsd and others.

Is this correct ?, comments in the appropreate config.h files indicate that 
HANDLE_PRAGMA_PACK_PUSH_POP, is mostly used for wine compatablity, but is 
there any reason why HANDLE_PRAGMA_PACK_PUSH_POP is not present on all 
targets ? also there is not a configure option.

i note that in gcc4 only djgpp and cygming targets have 
HANDLE_PRAGMA_PACK_PUSH_POP defined, also the gcc4 documentation does not say 
these #pragmas are target spesific.

regards
---
Matthew J Fletcher
Embedded Software
Serck Controls Ltd
---
**
Serck Controls Ltd, Rowley Drive, Coventry, CV3 4FH, UK
Tel: +44 (0) 24 7630 5050   Fax: +44 (0) 24 7630 2437
Web: www.serck-controls.com  Admin: [EMAIL PROTECTED]
A subsidiary of Serck Controls Pty. Ltd. Reg. in England No. 4353634
**
This email and files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the above. Any views or opinions presented are those of the author
and do not necessarily represent those of Serck Controls Ltd.


This message has been checked by MessageLabs
**

Re: g++ compile-time error with template arguments in 4.0 CVS?

[Benjamin Redelings I]

 > Please add your testcase to PR19883 and mention that this is 
breaking boost.
Giovanni Bajo
OK, done!
-BenRI

Re: GCC problem with using "-fprofile-arcs"

[Joe Buck]

On Thu, Feb 17, 2005 at 05:09:55PM +0800, [EMAIL PROTECTED] wrote:
> Hi, there:
> I tried using the "-fprofile-arcs" and "-fbranch-probabilities" to build a 
> profile based optimized binary, but got some complain about the .da files.
> ...
> The fail message is:
> /usr/include/bits/sigset.h: At top level:
> /usr/include/bits/sigset.h:119: .da file contents not exhausted
> ...failed Cc treeprint.o ...

The most common reason for this message is that you have .da files left
over from previous runs, and they have counts for code that no longer
exists.  In your case you rebuilt with a different set of flags; that
might produce similar symptoms.

Try removing all the .da files and re-running the program (which will
recreate the .da files).

Re: GCC 4.0 Status Report (2005-02-03)

[Joe Buck]

On Wed, 9 Feb 2005, Mark Mitchell wrote:
> > As for making all proposals public, some people have asked that they be 
> > kept confidential because they didn't want to put out ideas publicly 
> > that were going to have no chance of being included.

I wish that people didn't feel that way; off-the-wall ideas sometimes lead
to better ideas even if the original proposal is completely unsuitable,
and things that aren't realistic to include in a short time frame can
work out OK long-term.

On Thu, Feb 17, 2005 at 01:56:59PM +0100, Gerald Pfeifer wrote:
> Personally, that sounds somewhat strange for contributions to an open 
> source project, and I would strongly prefer all proposals to be public
> to counter any FUD anyone might spread on our processes.

It depends.  If someone wants a confidential "sanity check" on a proposal
before making it public, I don't much care (though Mark might find himself
overburdened if he's in charge of all sanity checking, because people mail
only him).  But any private communication between a proposer and Mark
should only be a first step; real development discussions should take
place on this list.

Re: __register_frame_info and unwinding shared libraries

[Andrew Haley]

Jakub Jelinek writes:

 > >  > While I still like using dl_iterate_phdr instead of
 > >  > __register_frame_info_bases for totally aesthetic reasons, there
 > >  > have been changes made to the dl_iterate_phdr interface since the
 > >  > gcc support was written that would allow the dl_iterate_phdr
 > >  > results to be cached.
 > > 
 > > That would be nice.  Also, we could fairly easily build a tree of
 > > nodes, one for each loaded object, then we wouldn't be doing a linear
 > > search through them.  We could do that lazily, so it wouldn't kick in
 > > 'til needed.
 > 
 > Here is a rough patch for what you can do.

Thanks very much.  I'm working on it.

Andrew.

OT: combinatorial source line swapper test

[Davide Rossetti]

Hello,
I remember I read on this mlist about a testing tool. a script or 
something which took a source file in input and tried to swap lines and 
compile it, then reported results... can't google it exacly.. any help ??
best regards

Re: Quick Question

[Richard Henderson]

On Thu, Feb 17, 2005 at 11:26:21AM -0500, Rajkishore Barik wrote:
> Is there a way to determine if the given RTX is 
> accessing an array element or not? If yes, how do I determine the 
> static size of that array from the given RTX?

In general, you don't.


r~

Re: GCC 4.0 Status Report (2005-02-03)

[Mark Mitchell]

Joe Buck wrote:
It depends.  If someone wants a confidential "sanity check" on a proposal
before making it public, I don't much care (though Mark might find himself
overburdened if he's in charge of all sanity checking, because people mail
only him).  But any private communication between a proposer and Mark
should only be a first step; real development discussions should take
place on this list.
I completely agree.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Mostly successful build and install

[Scott Glass]

./config.guess
i686-pc-linux-gnu
gcc -v
Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.3/specs
Configured with: /Data/MyDownloads/gcc-3.4.3/configure
Thread model: posix
gcc version 3.4.3
languages enabled
all
/etc/issue
Red Hat Enterprise Linux WS release 3 (Taroon Update 4)
uname -a
Linux localhost.localdomain 2.4.21-27.ELsmp #1 SMP Wed Dec 1 21:59:02 EST 
2004 i686 i686 i386 GNU/Linux

rpm -q glibc
glibc-2.3.2-95.30
Here are the errors that I got during the check tests:
FAIL: gcc.c-torture/execute/va-arg-25.c execution,  -Os (in gcc tests)
In libstdc++-v3 check-abi, 7 missing symbols & 7 incompatible symbols
FAIL: linking simple (in libjava tests)
_
On the road to retirement? Check out MSN Life Events for advice on how to 
get there! http://lifeevents.msn.com/category.aspx?cid=Retirement

Re: GCC 4.0 Status Report (2005-02-03)

[Dorit Naishlos]

>
> Substantial progress has been made towards GCC 4.0 over the past
> several weeks.  There are now 103 open regressions targeted at 4.0,
> including 13 wrong-code bugs, and 31 rejects-valid or
> ice-on-valid-code bugs.
>
> That means that we are very nearly at the point where we can create
> the GCC 4.0 release branch.
>
> However, before that happens, it is important that we have a coherent
> strategy for GCC 4.1.  There are a number of major branches (and
> perhaps done on work that is not on a branch) that people will want to
> integrate, and we must do that in an orderly fashion.
>
> Therefore, we will use the same proposal-based procedure that we used
> (late) in the GCC 4.0 timeframe.  If you have already completed, or
> are planning to complete, a substantial project that you would like to
> include in GCC 4.1, please send me the following information:
>

* Project Title: Autovectorization enhancements
* Project Contributors:
  Ira Rosen, Devang Patel, Dorit Naishlos, Keith Besaw.
* Dependencies: None.
* Description and Delivery Dates

1- Cleanups and improvement of existing functionality
  1.1 Incrementally preserve ssa form when vectorizing (Keith)
  - Description: define the virtual operands of newly
generated vector statements so that the ssa
form is preserved.
  - Benefit: avoid call to rewrite_into_ssa
  - Date: already in autovect; can be submitted when
4.1 opens.
  1.2 Incrementally preserve loop-closed form when vectorizing (Dorit)
  - Description: maintain loop-closed form when doing
loop-peeling in the vectorizer.
  - Benefit: avoid call to rewrite_into_loop_closed_ssa
  - Date: already in autovect; can be submitted when 4.1 opens.
  1.3 Improvements to peeling for alignment (Dorit)
  - Description: handle known-misalignment case more
efficiently; detect accesses with the same alignment.
  - Benefits: improved code quality; increased vectorization
potential (for targets that don't support misalignment).
  - Date: already in autovect; can be submitted when 4.1 opens.
  1.4 Consider dependence distance in the vectorizer (Devang)
  - Description: allow vectorization in the presence of
dependency if the dependence distance is safe.
  - Benefits: more loops vectorized.
  - Date: already in autovect; can be submitted when 4.1 opens.
  1.5 Externalize generic parts of dataref analysis (Ira)
  - Description: Make available generic parts of the dataref
analysis to other passes.
  - Benefits: Share functionality with other passes.
  - Date: By end of March.

  For all of the above:
  - parts of the compiler: tree-vectorizer.c
  (and tree-data-ref.c for item 1.5)
  - risks: More loops vectorized is more potential for problems.

2- New functionality
  2.1 Loop versioning for alignment (Keith)
  - Description: generate a vector version and a non-vector
version of a loop with entry controlled by alignment tests
  - Benefits: vectorize loops where alignment is unknown at
compile time
  - Parts of the compiler: tree-vectorizer.c
  - Risks: code bloat
  - Date: already in autovect; can be submitted when 4.1 opens.
  2.2 Reduction support (Dorit)
  - Description: vectorize computations like 's+=a[i]'
  - Benefits: increase potential for vectorization
  - Parts of the compiler: tree-vectorizer.c, new tree-codes/optabs,
target specific files (.md).
  - Risks: more loops vectorized is more potential for problems.
  - Date: By end of March.
  2.3 Vectorization of conditional code (Devang)
  - Description: Vectorize loops with conditional code.
  - Benefits: Increase potential for vectorization.
  - Parts of the compiler: tree-vectorizer.c, config/rs6000.c
(other back ends may need some work to support this).
  - Risks: more loops vectorized is more potential for problems.
  - Date: Already in autovect; can be submitted when 4.1 opens.

3- Additional items we're considering (or planning to do but not sure when)
include:
   3.1 #pragma support to guide autovectorizer (Devang)
  - Description: Allow user to guide compiler when to vectorize
and when not to vectorize particular loop using #pragma.
Intel compiler provides similar functionality.
  - Benefits: Give user more choices. It also helps vectorizer
when it can't prove there is no data dependency but user
knows that.
  - Parts of the compiler: ?
  - Risks: ?
  - Date: ?
  3.2 Loop versioning to eliminate data dependence (Keith)
  - Description: generate a vector version and a
non-vector version of a loop with entry
controlled by data dependence tests.
  - Benefits: vectorize loops where data dependence
is unknown at compile time.
  - Parts of the compiler: tree-vectorizer.

Re: OT: combinatorial source line swapper test

[Mike Stump]

On Feb 17, 2005, at 9:52 AM, Davide Rossetti wrote:
I remember I read on this mlist about a testing tool. a script or 
something which took a source file in input and tried to swap lines 
and compile it, then reported results... can't google it exacly.. any 
help ??
best regards
http://gcc.gnu.org/ml/gcc/2004-06/msg00528.html
If your memory if really good, there was another one called slice, 
though google and searching my email archive aren't turning up the 
right hits.

Re: RFC: Appropriate method for target-specific mode-substititutes in libgcc2

[Björn Haase]

Am Donnerstag, 17. Februar 2005 03:11 schrieb James E Wilson:
> James E Wilson wrote:
> > Björn Haase wrote:
> >> #ifndef TARGET_SPECIFIC_SUBSTITUE_FOR_MODE_DF
>
> I see now that this is PR 19920.  This message would have made more
> sense if you had included that important info.
>
> Anyways, I see that Richard Henderson has added a reasonable fix for it
> now along the lines I suggested, e.g. adding ifdefs to control when the
> bigger modes are used.
Indeed with Richard Henderson's patches the problem for the h8 and the avr 
targets no longer exists. Never the less thank you for your answer. I'll be 
more explicit to the exact PR number next time.

Yours,

Björn

Re: OT: combinatorial source line swapper test

[Don Lindsay]

> On Feb 17, 2005, at 9:52 AM, Davide Rossetti wrote:
> > I remember I read on this mlist about a testing tool. a script or 
> > something which took a source file in input and tried to swap lines 
> > and compile it, then reported results... can't google it exacly.. any 
> > help ??

Here's something vaguely related: a quick hack for shrinking testcases,
when you're looking for a cutdown that still exhibits some
still-mysterious failure.

Its stupidity makes it slow. But you can run it while you're asleep.



#! /usr/bin/env python

"""
thinloop.py

Expects infile is C source.
Loops, writing successively "thinned" version of infile to tmpfiles.
After each tmpfile is written, does system(" "),
with a 15 second timeout. If that doesn't time out, examines
. If it's zero length, assumes the thinned version
was a failure, and tries a different version. If it's nonzero,
assumes the thinned version was a success, and bases the next
thinning on that version.
Runs forever, or until 100 fails in a row.
Prints "+" or "_" (success or fail) on each iteration.
The most recent successful output is kept as file ".keep".
The most recent file that hung the tester is file ".hung".

Thinning algorithm:
Deletes one randomly chosen source line, under the rules:
1) doesn't delete lines containing "{" or "}"
2) finds a text line containing ";"
3) deletes that line, and all preceding lines up-to the 
preceding candidate line (as defined by rules 1 and 2).

"""
from __future__ import nested_scopes

import sys,os
import os.path
import random
import tempfile
import copy
import signal

pid = 0
#-
def handlerfunc( signum, obj ):
"""Post this as the signal handler.
   Expects pid is valid.
"""
global pid
signal.alarm( 0 )
if signum == signal.SIGALRM:
# Caught a timeout signal, so kill the pid.
os.kill( pid, signal.SIGKILL )

signal.signal( signal.SIGCHLD, handlerfunc)
signal.signal( signal.SIGALRM, handlerfunc)

#-
def tag_of( line ):
"""Given a text lines, returns:
0 - preserve (contains '{' or '}'
1 - target (contains ';')
2 - freefire (not either of above)
"""
if '{' in line: return 0
if '}' in line: return 0
if ';' in line: return 1
return 2
#-
def slim_list( line_list):
""" Returns a slimmed copy of line_list"""

# Get a shallow copy (ie same strings, but new ptrs)
line_list = copy.copy( line_list )

# Get a random in the range 0..N-1
target = random.choice(xrange(len(line_list)))

try:
# If we run off the end of arrays, just punt,
# and make no change.

# Search forward from random startpoint for a semicolon
while ';' not in line_list[target]:
target += 1

# Search backward for all freefire's leading up to target
freefire = target
while tag_of( line_list[freefire-1]) == 2:
freefire -= 1

# delete all lines freefire upthu target
# (Note each del renumbers them.)
while freefire <= target:
del line_list[freefire]
target -= 1

except:
pass
return line_list

#-
def main( infile_name, tester, success_file ):

global pid
line_list = open(infile_name).readlines()
fail_count = 0;
while 1:

# Get a shortened file
short_list = slim_list( line_list )

# Emit the remaining lines to a tmpfile
outfile_name = tempfile.mktemp(".c")
outfile = open( outfile_name, "w")
outfile.writelines(short_list)
outfile.close()

# Invoke the tester, after setting timeout
signal.alarm( 15 )
pid = os.spawnv( os.P_NOWAIT, tester, [tester,outfile_name] )

# Wait for the tester to finish, turning any error from a KILL
# into a bool. See handlerfunc, who expects we've set the pid.
ok = 1
try:
os.wait()
except OSError:
ok = 0

# Check the tester's success criteria, maybe keep the change
if ok and os.path.getsize( success_file ) != 0:
# Success: the change was good.
line_list = short_list
os.system( "/bin/cp -f %s %s.keep" % 
( outfile_name, infile_name))
sys.stderr.write("+")
fail_count = 0
else:
   

Re: PATCH: TR1 unordered associative containers

[Paolo Carlini]

Hi Matt,
I'm sure there are still lots of horrible bugs, which will only be  
found with a more complete test suite.  But the core functionality  
works, and at this point I think it'll improve faster in the CVS 
server  than sitting on my hard disk.

OK to commit to mainline?
As far as I'm concerned, your contribution is absolutely welcome: 
thanks! Only a few days ago, I was asking to Benjamin: any news about 
Matt's unordered containers implementation? ;)

By the way, it's up to you what to do exactly with libstdc++/19554...
Thanks again,
Paolo.
P.S. The document, solicitated by Joe Buck, describing the experimental 
tr1 facilities in 4.0 is becoming more and more urgent!

Re: PATCH: TR1 unordered associative containers

[Mike Stump]

On Feb 17, 2005, at 3:47 PM, Matt Austern wrote:
I'm sure there are still lots of horrible bugs

OK to commit to mainline?
Please, the copyright seems wrong.  I think that should be fixed before 
it goes in.

Re: PATCH: TR1 unordered associative containers

[Paolo Carlini]

Matt Austern wrote:
OK to commit to mainline?
... before going to sleep, two very simple, slighlty less enthusiastic 
comments ;)
1- Please add 2005 to the copyrights.
2- I see that the table of primes assumes that unsigned long is 32-bit: 
we should do something about this, sooner or later...

Paolo.

Re: PATCH: TR1 unordered associative containers

[Benjamin Kosnik]

> I'm sure there are still lots of horrible bugs, which will only be  
> found with a more complete test suite.  But the core functionality  
> works, and at this point I think it'll improve faster in the CVS server  
> than sitting on my hard disk.

Yep.

> OK to commit to mainline?

Sounds like a good idea to me. (Some of the copyright years should include 
2005).

Thanks for agreeing to worry about linkage later!

-benjamin

Re: PATCH: TR1 unordered associative containers

[Paolo Carlini]

Matt Austern wrote:
OK to commit to mainline?
About your rethoric question: you made the mistake of creating the CVS 
dirs before actually asking, thus making the nice surprise a little less 
effective ;) ;)

Paolo.

Re: PATCH: TR1 unordered associative containers

[Joe Buck]

On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
> I'm sure there are still lots of horrible bugs, which will only be  
> found with a more complete test suite.  But the core functionality  
> works, and at this point I think it'll improve faster in the CVS server  
> than sitting on my hard disk.
> 
> OK to commit to mainline?

A namespace purity nitpick:

You define a macro named tr1_hashtable_define_trivial_hash.  Shouldn't
that be __tr1_hashtable_define_trivial_hash or something similar?

Re: PATCH: TR1 unordered associative containers

[Chris Jefferson]

Joe Buck wrote:
On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
 

I'm sure there are still lots of horrible bugs, which will only be  
found with a more complete test suite.  But the core functionality  
works, and at this point I think it'll improve faster in the CVS server  
than sitting on my hard disk.

OK to commit to mainline?
   

A namespace purity nitpick:
You define a macro named tr1_hashtable_define_trivial_hash.  Shouldn't
that be __tr1_hashtable_define_trivial_hash or something similar?
 

Having just read through, everything seems very reasonable to me, but I 
think there is a general need a liberal splattering of __ here, there 
and everywhere :) It would be very nice if we could stop having to 
prefix everything with __ and just pop it into a namespace instead, but 
fixing that is perhaps something for another day :)

Chris

Re: PATCH: TR1 unordered associative containers

[Joe Buck]

Joe Buck wrote:
> >A namespace purity nitpick:
> >
> >You define a macro named tr1_hashtable_define_trivial_hash.  Shouldn't
> >that be __tr1_hashtable_define_trivial_hash or something similar?

On Fri, Feb 18, 2005 at 12:23:12AM +, Chris Jefferson wrote:
> Having just read through, everything seems very reasonable to me, but I 
> think there is a general need a liberal splattering of __ here, there 
> and everywhere :) It would be very nice if we could stop having to 
> prefix everything with __ and just pop it into a namespace instead, but 
> fixing that is perhaps something for another day :)

I only singled out the macro, because namespaces have no effect on macros.

Re: LC_COLLATE (was Re: SVN Test Repo updated)

[Kai Henningsen]

[EMAIL PROTECTED] (Paolo Bonzini)  wrote on 17.02.05 in <[EMAIL PROTECTED]>:

> > The sort alghorithm has nothing to do with ls, but with your selection of
> > LC_COLLATE.  But then, BSD (at least the variant used in MacOSX) is way
> > behind current l10n standards.
>
> At least they do not break s/[A-Z]// which on "well-internationalized"
> OSes is case-insensitive with most locales other than C.
>
> I still haven't dug enough to understand if the responsible for this is
> the POSIX specification for localization, the ANSI specification for
> strcoll, or somebody in the glibc team.  But I know that it was the
> most-reported sed "bug" before I explicitly flagged it as a non-bug in
> the manual.
>
> I can only guess the outcry if Perl started obeying LC_COLLATE.

What do you mean, "started"? It's been doing that for years now.

MfG Kai

Re: LC_COLLATE (was Re: SVN Test Repo updated)

[Vincent Lefevre]

On 2005-02-17 20:29:00 +0200, Kai Henningsen wrote:
> [EMAIL PROTECTED] (Paolo Bonzini)  wrote on 17.02.05 in <[EMAIL PROTECTED]>:

> > I can only guess the outcry if Perl started obeying LC_COLLATE.
> 
> What do you mean, "started"? It's been doing that for years now.

Not by default. From the perllocale(1) man page:

   By default, Perl ignores the current locale.  The "use locale" pragma
   tells Perl to use the current locale for some operations:
[...]

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / SPACES project at LORIA

The Linux binutils 2.15.94.0.2.2 is released

[H. J. Lu]

This is the beta release of binutils 2.15.94.0.2.2 for Linux, which is
based on binutils 2004 1220 in CVS on sources.redhat.com plus various
changes. It is purely for Linux.

Please report any bugs related to binutils 2.15.94.0.2.2 to [EMAIL PROTECTED]

and

http://www.sourceware.org/bugzilla/

If you don't use

# rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2

to compile the Linux binutils, please read patches/README in source
tree to apply Linux patches if there are any.

Changes from binutils 2.15.94.0.2:

1. Fix greater than 64K section support in linker.
2. Properly handle i386 and x86_64 protected symbols in linker.
3. Fix readelf for LEB128 on 64bit hosts.
4. Speed up readelf for section group process.
5. Include ia64 texinfo pages.
6. Change ia64 assembler to check hint.b for Montecito.
7. Improve relaxation failure report in ia64 linker.
8. Fix ia64 linker to allow relax backward branch in the same section.

Changes from binutils 2.15.94.0.1:

1. Update from binutils 2004 1220.
2. Fix strip for TLS symbol references.

Changes from binutils 2.15.92.0.2:

1. Update from binutils 2004 1121.
2. Put ia64 .ctors/.dtors sections next to small data section for
Intel ia64 compiler.
3. Fix -Bdynamic/-Bstatic handling for linker script.
4. Provide more information on relocation overflow.
5. Add --sort-section to linker.
6. Support icc 8.1 unwind info in readelf.
7. Fix the infinite loop bug on bad input in the ia64 assembler.
8. Fix ia64 SECREL relocation in linker.
9. Fix a section group memory leak in readelf.

Changes from binutils 2.15.91.0.2:

1. Update from binutils 2004 0927.
2. Work around a section header bug in Intel ia64 compiler.
3. Fix an unwind directive bug in the ia64 assembler.
4. Fix various PPC bugs.
5. Update ARM support.
6. Fix an x86-64 linker warning while building Linux kernel.

Changes from binutils 2.15.91.0.1:

1. Update from binutils 2004 0727.
2. Fix the x86_64 linker to prevent non-PIC code in shared library.
3. Fix the ia64 linker to warn the relotable files which can't be
relaxed.
4. Fix the comdat group support. Allow mix single-member comdat group
with linkonce section.
5. Added --add-needed/--no-add-needed options to linker.
6. Fix the SHF_LINK_ORDER support.
7. Fix the ia64 assembler for multiple sections with the same name and
SHT_IA_64_UNWIND sections.
8. Fix the ia64 assembler for merge section and relaxation.

Changes from binutils 2.15.90.0.3:

1. Update from binutils 2004 0527.
2. Fix -x auto option in the ia64 assembler.
3. Add the AR check in the ia64 assembler.
4. Fix the section group support.
5. Add a new -z relro linker option.
6. Fix an exception section placement bug in linker.
7. Add .serialize.data and .serialize.instruction to the ia64
assembler.

Changes from binutils 2.15.90.0.2:

1. Update from binutils 2004 0415.
2. Fix the linker for weak undefined symbol handling.
3. Fix the ELF/Sparc and ELF/Sparc64 linker for statically linking PIC
code.

Changes from binutils 2.15.90.0.1.1:

1. Update from binutils 2004 0412.
2. Add --as-needed/--no-as-needed to linker.
3. Fix -z defs in linker.
4. Always reserve the memory for ia64 dynamic linker.
5. Fix a race condition in ia64 lazy binding.

Changes from binutils 2.15.90.0.1:

1. Fixed an ia64 assembler bug.
2. Install the assembler man page.

Changes from binutils 2.14.90.0.8:

1. Update from binutils 2004 0303.
2. Fixed linker for undefined symbols with non-default visibility.
3. Sped up linker weakdef symbol handling.
4. Fixed mixing ELF32 and ELF64 object files in archive.
5. Added ia64 linker brl optimization.
6. Fixed ia64 linker to disallow invalid dynamic relocations.
7. Fixed DT_TEXTREL handling in ia64 linker.
8. Fixed alignment handling in ia64 assembler.
9. Improved ia64 assembler unwind table handling. 

Changes from binutils 2.14.90.0.7:

1. Update from binutils 2004 0114.
2. Fixed an ia64 assembler unwind table bug. 
3. Better handle IPF linker relaxation overflow.
4. Fixed misc PPC bugs.

Changes from binutils 2.14.90.0.6:

1. Update from binutils 2003 1029.
2. Allow type changes for undefined symbols.
3. Fix EH frame optimization.
4. Fix the check for undefined versioned symbol with wildcard.
5. Support generating code for Itanium.
6. Detect and warn bad symbol index.
7. Update IPF assemebler DV check.

Changes from binutils 2.14.90.0.5:

1. Update from binutils 2003 0820.
2. No longer use section names for ELF section types nor flags.
3. Fix some ELF/IA64 linker bugs.
4. Fix some ELF/ppc bugs.
5. Add archive support to readelf.

Changes from binutils 2.14.90.0.4.1:

1. Update from binutils 2003 0722.
2. Fix an ELF/mips linker bug.
3. Fix an ELF/hpppa linker bug.
4. Fix an ELF/ia64 assembler bug.
5. Fix a linkonce support with C++ debug.
6. A new working C++ demangler.
7. Various alpha, mips, ia64, ... bug fixes.
8. Support for the current gcc and glibc.

Changes from binutils 2.14.90.0.4:
 
1. Fix an ia64 assembler [EMAIL PROTECTED] bug.
2. Support Intel Prescott New Instructions.

Changes from 

Re: PATCH: TR1 unordered associative containers

[Gabriel Dos Reis]

Joe Buck <[EMAIL PROTECTED]> writes:

| On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
| > I'm sure there are still lots of horrible bugs, which will only be  
| > found with a more complete test suite.  But the core functionality  
| > works, and at this point I think it'll improve faster in the CVS server  
| > than sitting on my hard disk.
| > 
| > OK to commit to mainline?
| 
| A namespace purity nitpick:
| 
| You define a macro named tr1_hashtable_define_trivial_hash.  Shouldn't
| that be __tr1_hashtable_define_trivial_hash or something similar?

I think that may not be necessary.  TR1 is experimental and people
know what they are playing with and they just have to avoid evil
macros when programming with C++.  In that respect, TR1 is not 
different from ordinary third party library.  More to the  point, I
hope that by the time we get to finalize the details in getting TR1
into the Working Paper, we also get to have equivalent of the #nospam
preprocessor directive to  limit the nuisance power of macros.

-- Gaby

Error while building gcc-3.4.3 !

[Syed Shabir Zakiullah]

While building gcc-3.4.3 I am getting following error during make stage. 

../../../libiberty/cplus-dem.c:55: error: conflicting types for 'malloc'
../../../libiberty/cplus-dem.c:55: error: conflicting types for 'malloc'
../../../libiberty/cplus-dem.c: In function `code_for_qualifier':
../../../libiberty/cplus-dem.c:630: warning: implicit declaration of function 
`abort'
../../../libiberty/cplus-dem.c: In function `squangle_mop_up':
../../../libiberty/cplus-dem.c:1154: warning: implicit declaration of function 
`free'
../../../libiberty/cplus-dem.c: In function `demangle_qualified':
../../../libiberty/cplus-dem.c:3310: warning: implicit declaration of function 
`atoi'
make: *** [cplus-dem.o] Error 1


Can any one help me to fix this error, I searched net but didnot find any 
information on this. BTW: I am using Glibc-2.3.4 with NPTL+LinuxThreads.


Thanks in Advance!!




Syed Shabir Zakiullah
Programmer 
Registered Linux User #374309

Re: PATCH: TR1 unordered associative containers

[Matt Austern]

On Feb 17, 2005, at 4:18 PM, Joe Buck wrote:
On Thu, Feb 17, 2005 at 03:47:03PM -0800, Matt Austern wrote:
I'm sure there are still lots of horrible bugs, which will only be
found with a more complete test suite.  But the core functionality
works, and at this point I think it'll improve faster in the CVS 
server
than sitting on my hard disk.

OK to commit to mainline?
A namespace purity nitpick:
You define a macro named tr1_hashtable_define_trivial_hash.  Shouldn't
that be __tr1_hashtable_define_trivial_hash or something similar?
That was deliberate---perhaps a wrong choice, but deliberate.  I didn't 
uglify any of the names.

Rationale: I don't believe uglification is a practical issue, but a 
standards-conformance issue.  TR1 components aren't part of the 
standard, so that issue doesn't apply.

--Matt

Re: PATCH: TR1 unordered associative containers

[Matt Austern]

On Feb 17, 2005, at 4:03 PM, Paolo Carlini wrote:
Matt Austern wrote:
OK to commit to mainline?
... before going to sleep, two very simple, slighlty less enthusiastic 
comments ;)
1- Please add 2005 to the copyrights.
Fixed.
2- I see that the table of primes assumes that unsigned long is 
32-bit: we should do something about this, sooner or later...
Yep.  Or more precisely, it assumes we don't care about having more 
than 4 billion buckets even on 64-bit systems.  I agree that this is 
something to take care of.  But much more urgent is figuring out a way 
to have .cc files for TR1 components, not just header files, so we 
don't have to include that table in every translation unit that wants t 
use hashtables.

--Matt

Re: PATCH: TR1 unordered associative containers

[Matt Austern]

On Feb 17, 2005, at 3:57 PM, Paolo Carlini wrote:
Hi Matt,
I'm sure there are still lots of horrible bugs, which will only be  
found with a more complete test suite.  But the core functionality  
works, and at this point I think it'll improve faster in the CVS 
server  than sitting on my hard disk.

OK to commit to mainline?
As far as I'm concerned, your contribution is absolutely welcome: 
thanks! Only a few days ago, I was asking to Benjamin: any news about 
Matt's unordered containers implementation? ;)
Done!
By the way, it's up to you what to do exactly with libstdc++/19554...
I think I agree with you: no point in fixing enhancement requests in 
obsolete components.

--Matt

Re: LC_COLLATE (was Re: SVN Test Repo updated)

[Paolo Bonzini]

I can only guess the outcry if Perl started obeying LC_COLLATE.
What do you mean, "started"? It's been doing that for years now.
   By default, Perl ignores the current locale.  The "use locale" pragma
   tells Perl to use the current locale for some operations:
and these do not include regex character ranges.  LC_COLLATE would only 
be used for sorting and for string comparisons.

Paolo