First PPL 0.10.1 release candidate

[Roberto Bagnara]

We have uploaded the first PPL 0.10.1 release candidate to

  ftp://ftp.cs.unipr.it/pub/ppl/snapshots/

You can check the NEWS file via Gitweb:

  
http://www.cs.unipr.it/git/gitweb.cgi?p=ppl/ppl.git;a=blob_plain;f=NEWS;hb=ppl-0_10-branch

If all goes well, the release of PPL 0.10.1 will happen on April 14, 2009.
In case problems arise, the above mentioned snapshot will be replaced by
a new one and only announced on ppl-de...@cs.unipr.it (of course the real
release will be properly announced).

Please report any problem you may encounter to ppl-de...@cs.unipr.it

Beta-testing is especially important on this occasion because PPL 0.10.1
will be the last release in the PPL 0.10 series.  The following release
will be PPL 0.11.

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: Merging the alias-improvements branch

[Richard Guenther]

On Mon, 6 Apr 2009, Toon Moene wrote:

> I wrote:
> 
> > Richard Guenther wrote:
> > 
> > > I plan to merge the alias-improvements branch next weekend (in 7 days)
> > > if all goes well.  I will do bootstrap & regtesting on the archs
> > > I have available (x86_64, i?86, ppc, ppc64, ia64, s390 and s390x).
> > 
> > I am absolutely thrilled to test it on our weather forecasting system. The
> > top routine in our profile looks a *lot* like the loop you got such an
> > improvement on in SPEC's mgrid ...
> 
> Unfortunately, the improvement is not as large as I had hoped:
> 
> Before the merge of the alias-improvements branch into mainline:
> 00 UTC run 20090405, last file produced:
> 
> -rw-r--r-- 1 hirlam hirlam  21492000 2009-04-05 08:31 fc20090405_00+048ve
> 
> After the merge of the alias-improvements branch into mainline:
> 00 UTC run 20090406, last file produced:
> 
> -rw-r--r-- 1 hirlam hirlam  21648000 2009-04-06 08:29 fc20090406_00+048ve
> 
> So the improvement is 2 minutes for a 3.5 hour run (~ 1%).

Well, I certainly didn't expect any magic ;)  The overall SPEC FP
improvement is in the 3% range (depending on target and optimization
options).

Richard.

[cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Paolo Bonzini]

I created the cond-optab svn branch and finished committing the
cond-optab patches to it.  I also documented it in svn.html.

The branch was bootstrapped i686-pc-linux-gnu and is identical to the
tree that Kaz bootstrapped on sh4-linux.

The rest of this message details the plans for merging and further
testing of the branch.

(Sorry for the continuous spamming of updates---but I really need
reviewers now...)

1. PATCHES READY TO BE MERGED
=

The following patches can be transported to mainline independent of the
completion of the project.  I would like to merge these patches one at a
time, so reviews for these are welcome now.

r145593: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (i386)
r145594: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (s390)
r145595: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00546.html (expand)
r145596: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00548.html (i386,
s390, expand)
r145597, r145598, r145599:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00947.html (gen*)
r145600: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00497.html (expand)
r145601: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01215.html (RTL)
r145603: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00496.html (gen*, RTL)
r145611: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00547.html (expand)
r145655: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00492.html (testsuite)

They have basically zero interdependencies, so you can start reviewing
patches in your field *now*.  :-)


2. SECOND PART OF THE MERGE
===

This includes everything else that is not in the list above.  While I
separated the patches on the branch to ease review and posting, they
will have to be committed together on trunk.

r145606: the big patch to expand, basically the fusion of everything
else I posted
r145610: the big patch to targets
r145656: fixlet for MIPS, thanks Richard for spotting it

All targets except PA and S390 produce the same or better code on the
tests of r145655 (I have patches to fix PA and S390).  The tests I
posted are quite complete, especially thanks to H-P and Bernd whose
early testing gave hints for improvements.  I fixed the reported issues
on Blackfin.

To aid testing, I'd like people to help bootstrapping bootstrappable
targets -- arm, alpha, ia64, pa, s390, x86_64.

For embedded targets, all supported targets build newlib but I can and
want to finish my long-promised assembly comparison tests; I hope to
fire it today and it will take a day or two to finish.  So if you test
the branch and realize you wasted your time, you were warned (but then
again, I don't think you'll waste your time) since the results are quite
promising:


3. AFTER THE MERGE
==

A little more cleanup will be done directly on the mainline.  In
particular, in order of priority:

a. fixing PA and S390 pessimizations (patch ready)

b. improving the expansion of FP comparisons unsupported on the target
(same patch as a.)

c. tuning a few straight-line expansions in emit_store_flag which are
now performed more often

d. getting rid of useless target code due to item b.

That's all.

Paolo
Index: svn.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/svn.html,v
retrieving revision 1.118
diff -u -r1.118 svn.html
--- svn.html3 Apr 2009 21:52:05 -   1.118
+++ svn.html7 Apr 2009 08:05:43 -
@@ -344,6 +344,14 @@
   Patches should be marked with the tag [no-undefined-overflow]
   in the subject line.  The branch is maintained by Richard Guenther.
 
+  cond-optab
+  This branch is to clean up and simplify the implementation of
+  conditional operations (branches, stores, moves, etc.) in expand
+  and in the machine descriptions.  Patches should be marked with the tag
+  [cond-optab] in the subject line.  The branch is maintained
+  by Paolo Bonzini.  Pending further testing, the branch is ready to be
+  merged into mainline and only bug and documentation fixes should be
+  committed.
 
 
 Architecture-specific

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Richard Guenther]

On Tue, Apr 7, 2009 at 11:55 AM, Paolo Bonzini  wrote:
> I created the cond-optab svn branch and finished committing the
> cond-optab patches to it.  I also documented it in svn.html.
>
> The branch was bootstrapped i686-pc-linux-gnu and is identical to the
> tree that Kaz bootstrapped on sh4-linux.
>
> The rest of this message details the plans for merging and further
> testing of the branch.
>
> (Sorry for the continuous spamming of updates---but I really need
> reviewers now...)
>
> 1. PATCHES READY TO BE MERGED
> =
>
> The following patches can be transported to mainline independent of the
> completion of the project.  I would like to merge these patches one at a
> time, so reviews for these are welcome now.
>
> r145601: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01215.html (RTL)

This is also ok.

Thanks,
Richard.

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Ramana Radhakrishnan]

> To aid testing, I'd like people to help bootstrapping bootstrappable
> targets -- arm, alpha, ia64, pa, s390, x86_64.

I'm bootstrapping the branch on an arm-linux-gnueabi target.

Ramana

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Laurent GUERBY]

On Tue, 2009-04-07 at 12:37 +0200, Uros Bizjak wrote:
> On Tue, Apr 7, 2009 at 11:55 AM, Paolo Bonzini  wrote:
> 
> > I created the cond-optab svn branch and finished committing the
> > cond-optab patches to it.  I also documented it in svn.html.
> 
> > To aid testing, I'd like people to help bootstrapping bootstrappable
> > targets -- arm, alpha, ia64, pa, s390, x86_64.
> 
> I can bootstrap on CompileFarm alpha machine. Unfortunatelly, the
> machine ran out of disk space, so I'm actually waiting for a quota
> update to re-run the bootstrap. Added Laurent to Cc.

There's currently 4.3 GB free on gcc30:/home so you should
be able to bootstrap.

Sincerely,

Laurent

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Richard Guenther]

On Tue, Apr 7, 2009 at 11:55 AM, Paolo Bonzini  wrote:
> I created the cond-optab svn branch and finished committing the
> cond-optab patches to it.  I also documented it in svn.html.
>
> The branch was bootstrapped i686-pc-linux-gnu and is identical to the
> tree that Kaz bootstrapped on sh4-linux.
>
> The rest of this message details the plans for merging and further
> testing of the branch.
>
> (Sorry for the continuous spamming of updates---but I really need
> reviewers now...)
>
> 1. PATCHES READY TO BE MERGED
> =
>
> The following patches can be transported to mainline independent of the
> completion of the project.  I would like to merge these patches one at a
> time, so reviews for these are welcome now.
>

> r145595: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00546.html (expand)

This is ok.

> r145596: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00548.html (i386,
> s390, expand)

This is ok given no objection from the two affected targets maintainers
within 48h.

> r145600: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00497.html (expand)

This is ok.

> r145611: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00547.html (expand)

This is ok.

Supposed they bootstrap/test ok on trunk of course.

Thanks,
Richard.

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Uros Bizjak]

On Tue, Apr 7, 2009 at 11:55 AM, Paolo Bonzini  wrote:

> I created the cond-optab svn branch and finished committing the
> cond-optab patches to it.  I also documented it in svn.html.

> To aid testing, I'd like people to help bootstrapping bootstrappable
> targets -- arm, alpha, ia64, pa, s390, x86_64.

I can bootstrap on CompileFarm alpha machine. Unfortunatelly, the
machine ran out of disk space, so I'm actually waiting for a quota
update to re-run the bootstrap. Added Laurent to Cc.

Uros.

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Uros Bizjak]

On Tue, Apr 7, 2009 at 11:55 AM, Paolo Bonzini  wrote:

> The following patches can be transported to mainline independent of the
> completion of the project.  I would like to merge these patches one at a
> time, so reviews for these are welcome now.
>
> r145593: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (i386)

i386 part of the patch is OK (the patch also includes sparc and s390 bits).

Thanks,
Uros.

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Paolo Bonzini]

>> r145601: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01215.html (RTL)
> 
> This is also ok.

Thanks, I won't commit this until the final merge though because I
cannot really test it separately.

Paolo

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Paolo Bonzini]

Thanks, this leaves out:

r145593: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (i386)
r145594: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (s390)
r145597, r145598, r145599:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00947.html (gen*)
r145603: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00496.html (gen*, RTL)
r145655: http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00492.html (testsuite)

Paolo

Need some help with fixincludes.

[Dominique Dhumieres]

Hi,

FX Coudert has sent me the following patch for fixincludes/inclhack.def:

--- ../_gcc_clean/fixincludes/inclhack.def  2009-03-31 22:37:57.0 
+0200
+++ fixincludes/inclhack.def2009-04-06 19:50:43.0 +0200
@@ -1023,6 +1023,35 @@
 
 
 /*
+ *  Fix stdint.h header on Darwin.
+ */
+fix = {
+hackname  = darwin_stdint;
+files = stdint.h;
+sed = "/#define[ \t]+INTPTR_MIN[\t]+INT64_MIN/#define INTPTR_MIN 
((intptr_t) INT64_MIN)/";
+sed = "/#define[ \t]+INTPTR_MIN[\t]+INT32_MIN/#define INTPTR_MIN 
((intptr_t) INT32_MIN)/";
+sed = "/#define[ \t]+INTPTR_MAX[\t]+INT64_MAX/#define INTPTR_MAX 
((intptr_t) INT64_MAX)/";
+sed = "/#define[ \t]+INTPTR_MAX[\t]+INT32_MAX/#define INTPTR_MAX 
((intptr_t) INT32_MAX)/";
+sed = "/#define[ \t]+UINTPTR_MIN[\t]+INT64_MIN/#define UINTPTR_MIN 
((uintptr_t) INT64_MIN)/";
+sed = "/#define[ \t]+UINTPTR_MIN[\t]+INT32_MIN/#define UINTPTR_MIN 
((uintptr_t) INT32_MIN)/";
+sed = "/#define[ \t]+UINTPTR_MAX[\t]+INT64_MAX/#define UINTPTR_MAX 
((uintptr_t) INT64_MAX)/";
+sed = "/#define[ \t]+UINTPTR_MAX[\t]+INT32_MAX/#define UINTPTR_MAX 
((uintptr_t) INT32_MAX)/";
+sed = "/#define[ \t]+SIZE_MAX[\t]+INT32_MAX/#define SIZE_MAX ((size_t) 
INT32_MAX)/";
+sed = "/#define[ \t]+SIZE_MAX[\t]+INT64_MAX/#define SIZE_MAX ((size_t) 
INT64_MAX)/";
+sed = "/#define[ \t]+UINT8_C(v)[\t]+(v ## U)/#define[\t]+UINT8_C(v) (v)/";
+sed = "/#define[ \t]+UINT16_C(v)[\t]+(v ## U)/#define[\t]+UINT16_C(v) 
(v)/";
+test_text = "#define INTPTR_MININT64_MIN\n"
+   "#define INTPTR_MAXINT64_MAX\n"
+   "#define UINTPTR_MIN   UINT64_MIN\n"
+   "#define UINTPTR_MAX   UINT64_MAX\n"
+   "#define SIZE_MAX  UINT64_MAX\n"
+   "#define UINT8_C(v)   (v ## U)\n"
+   "#define UINT16_C(v)  (v ## U)\n";
+
+};
+
+
+/*
  *  Fix  on Digital UNIX V4.0:
  *  It contains a prototype for a DEC C internal asm() function,
  *  clashing with gcc's asm keyword.  So protect this with __DECC.

I have succeeded to regenerate fixincludes/fixincl.x using fixincludes/genfixes.
After that, I bootstrapped without problem, but the test gcc.dg/c99-stdint-1.c
is still broken and if I run "make check" in /fixincludes I get

...
Fixed:  wchar.h
Missing header fix:  stdint.h

There were fixinclude test FAILURES
make: *** [check] Error 1

Is the FX's patch correct? If no, what should I change? If yes, what did I miss?

TIA

Dominique

Re: Need some help with fixincludes.

[Dave Korn]

Dominique Dhumieres wrote:

> FX Coudert has sent me the following patch for fixincludes/inclhack.def:

[ snipped all but one representative line. ]

> +sed = "/#define[ \t]+INTPTR_MIN[\t]+INT64_MIN/#define INTPTR_MIN 
> ((intptr_t) INT64_MIN)/";

> I have succeeded to regenerate fixincludes/fixincl.x using
> fixincludes/genfixes. After that, I bootstrapped without problem, but the
> test gcc.dg/c99-stdint-1.c is still broken and if I run "make check" in
> /fixincludes I get
> 
> ... Fixed:  wchar.h Missing header fix:  stdint.h
> 
> There were fixinclude test FAILURES make: *** [check] Error 1
> 
> Is the FX's patch correct? If no, what should I change? If yes, what did I
> miss?


  I don't know what it's trying to tell you with the fixincludes FAIL.  Did
you verify manually if the fixes perhaps didn't match against the stdint.h you
have on your release of the O/S?  Is stdint.h in some non-standard place where
it didn't get found?

  If you tell me which line the c99-stdint-1.c failure(s) is/are on, I could
parse it/them for you.  (I suspect that the example lines I quoted above might
cause problems if they /did/ get applied, because I think you're not allowed
to use casts in these definitions; or at least, I think I remember having read
something to that effect, but I can't remember if it was in a list email or a
comment in the source code, I'll see if I can dig up anything more concrete.)

cheers,
  DaveK

Re: [cond-optab] svn branch created, looking for reviews for the "cleanup" parts

[Uros Bizjak]

On Tue, Apr 7, 2009 at 12:46 PM, Laurent GUERBY  wrote:

>> > I created the cond-optab svn branch and finished committing the
>> > cond-optab patches to it.  I also documented it in svn.html.
>>
>> > To aid testing, I'd like people to help bootstrapping bootstrappable
>> > targets -- arm, alpha, ia64, pa, s390, x86_64.
>>
>> I can bootstrap on CompileFarm alpha machine. Unfortunatelly, the
>> machine ran out of disk space, so I'm actually waiting for a quota
>> update to re-run the bootstrap. Added Laurent to Cc.
>
> There's currently 4.3 GB free on gcc30:/home so you should
> be able to bootstrap.

I have started a bootstrap of cond-optab branch on gcc-30. I would
like to ask other cfarm users to stay away of gcc30 for 4-5 days (it
takes this time for a bootstrap + regtest if everything goes OK).

Thanks,
Uros.

Re: [Fwd: ICE with crx-elf-gcc 4.5.0 20090407]

[Dave Korn]

M R Swami Reddy wrote:
> Below issue observed with -O3 -funroll-all-loops option.

  This is not a patch.  Therefore it should not be sent to the -patches list.
  If you are ever in doubt, there is an explanation of the intended purpose
for the lists at

   http://gcc.gnu.org/lists.html

and since it is to do with the compiler internals, it would be suitable for
the main gcc list.  (I adjusted the Cc: line).

 It is indeed a serious bug, and the best thing that you can do to help the
maintainer fix it would be to file a bug report in the GCC bugzilla, in
particular supplying pre-processed source of your testcase so that the
maintainer can reproduce and analyze the problem.

> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

  Please do accept this advice from the compiler!  The page listed should tell
you everything you need to know about submitting a bugzilla PR.

cheers,
  DaveK

Re: Need some help with fixincludes.

[Dominique Dhumieres]

Dave,

Thanks for the quick answer.

>   I don't know what it's trying to tell you with the fixincludes FAIL.  Did
> you verify manually if the fixes perhaps didn't match against the stdint.h you
> have on your release of the O/S?

AFAICT the patch looks fine, but I cannot rule out typos. I'll try to look more
carefully.

>   If you tell me which line the c99-stdint-1.c failure(s) is/are on, I could
> parse it/them for you.

I have reported the error in pr445#15 and explained in comment #6:

/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function 
'test_ptr':
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:186: error: 
initialization from incompatible pointer type
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:186: error: 
initialization from incompatible pointer type
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:189: error: 
initialization from incompatible pointer type
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function 
'test_misc_limits':
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:217: error: 
initialization from incompatible pointer type
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function 
'test_constants':
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer 
targets in initialization differ in signedness
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer 
targets in initialization differ in signedness
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:230: error: pointer 
targets in initialization differ in signedness
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer 
targets in initialization differ in signedness
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer 
targets in initialization differ in signedness
/opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:231: error: pointer 
targets in initialization differ in signedness

Cheers

Dominique

problem with incremental build with Ada

[Arnaud Charlet]

Laurent,

I keep getting the following error when doing an incremental build (the first
time from scratch it works, and then it always fails):

ln -s ../.././gcc/ada/rts adainclude
ln -s ../.././gcc/ada/rts adalib
ln: creating symbolic link `adalib/rts' to `../.././gcc/ada/rts': File exists
make[2]: *** [gnatlib-shared] Error 1
make[2]: Leaving directory 
`/saumur.a/users/charlet/fsf/obj/x86_64-unknown-linux-gnu/libada'
make[1]: *** [all-target-libada] Error 2
make[1]: Leaving directory `/saumur.a/users/charlet/fsf/obj'
make: *** [all] Error 2

This seems to be related to some of the changes you made to support
multilibs. Can you please advise on how to fix this?

Is anyone else seeing these errors?

Thanks in advance.

Arno

Re: problem with incremental build with Ada

[Laurent GUERBY]

It's a procedural mistake on my side: I commited the wrong
iteration of the libada/Makefile.in patch, it is missing the pair of "rm
-rf". I checked and the version on 4.4 doesn't have the issue.

I've commited the right version of libada/Makefile.in
as revision 145673, it should fix incremental build, sorry for the mess.

Laurent

On Tue, 2009-04-07 at 15:25 +0200, Arnaud Charlet wrote:
> Laurent,
> 
> I keep getting the following error when doing an incremental build (the first
> time from scratch it works, and then it always fails):
> 
> ln -s ../.././gcc/ada/rts adainclude
> ln -s ../.././gcc/ada/rts adalib
> ln: creating symbolic link `adalib/rts' to `../.././gcc/ada/rts': File exists
> make[2]: *** [gnatlib-shared] Error 1
> make[2]: Leaving directory 
> `/saumur.a/users/charlet/fsf/obj/x86_64-unknown-linux-gnu/libada'
> make[1]: *** [all-target-libada] Error 2
> make[1]: Leaving directory `/saumur.a/users/charlet/fsf/obj'
> make: *** [all] Error 2
> 
> This seems to be related to some of the changes you made to support
> multilibs. Can you please advise on how to fix this?
> 
> Is anyone else seeing these errors?
> 
> Thanks in advance.
> 
> Arno
> 

Re: Need some help with fixincludes.

[Dave Korn]

Dominique Dhumieres wrote:

> I have reported the error in pr445#15 and explained in comment #6:

  PR448, to be precise.  I see Joseph is back from his AFK and has added
comment#16.

> /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c: In function
> 'test_ptr': /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:186:
> error: initialization from incompatible pointer type 
> /opt/gcc/gcc-4.5-work/gcc/testsuite/gcc.dg/c99-stdint-1.c:186: error:
> initialization from incompatible pointer type 

  So, for example, these two errors come from:

   186CHECK_SIGNED_LIMITS_2(intptr_t, INTPTR_MIN, INTPTR_MAX, -0x7fff,
0x7fff);

  The possibilities are either that the limits are incorrect (too big or too
large numerically, or you might find that the limits are right and the
intptr_t type is defined incorrectly to hold them) - do you have 32- or 64-bit
pointers? - or, and this is what I found most commonly in the other ports that
I've looked at, that there is an incorrect suffix on the integer constant -
e.g. 'll' for something that is assigned to a variable that is actually long,
a 'u' suffix on a limit for a signed type or a missing 'u' suffix on a signed
type.

  There are only a few possibilities to consider and if you look at all the
definitions for the types and limits that appear on the line where the error
is reported you should see one of these inconsistencies.  I found it well
worthwhile rerunning the testcase manually, adding --save-temps to get a look
at the actual expanded macros as the compiler sees them in-situ.

cheers,
  DaveK

Re: lookup_name

[Eduardo Cruz]

> I assume you mean the function in the C frontend, in c-decl.c.
thats correct!

thanks a lot!

2009/4/7 Ian Lance Taylor :
> Eduardo Cruz  writes:
>
>> does the function lookup_name distinguish the identifier between
>> different contexts?
>
> I assume you mean the function in the C frontend, in c-decl.c.  That
> function looks up the name in the current scope, so, yes, it will return
> different DECL nodes when appropriate.
>
> Ian
>

Re: First PPL 0.10.1 release candidate

[Roberto Bagnara]

Dave Korn wrote:

Roberto Bagnara wrote:


We have uploaded the first PPL 0.10.1 release candidate to



Please report any problem you may encounter to ppl-devel


Hi Roberto and team,

  I am sorry to report some problems encountered.


Hi Dave,

thanks for the report.  We will investigate it immediately.


Target: i686-pc-cygwin, cygwin-1.7.0-42, gcc-4.3.2, ppl configured with
--enable-shared --disable-static, no -fexceptions, no --enable-cxx.


I am not following here. There are no "-fexceptions" and "--enable-cxx"
in the PPL configuration procedure.  In contrast, "--enable-cxx"
is an option of GMP's configuration procedure.  Moreover, if GMP was
not compiled with the C++ interface enabled there is no way the PPL
can work (even though compilation should fail in such case).

Can you send us more details about which version of GMP you are using
and how it was configured?  We also need the files config.log and
config.h generated by PPL's configure script.
Thanks again,

   Roberto

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: Call for testers: MPC-0.6 released

[Kaveh R. Ghazi]

From: "Kaveh R. Ghazi" 

I've been relaying the messages, (but I haven't seen the MPC webpage 
updated to reflect this yet).


Okay it's updated, we've got a pretty comprehensive list of platforms.

http://www.multiprecision.org/index.php?prog=mpc&page=platforms

Thanks everyone for your test results!

I think we're just missing AIX5.2.  Ralf you did that last time for the svn 
tarball.  Would you please repeat your testing with mpc-0.6?


   Thanks,
   --Kaveh

Re: First PPL 0.10.1 release candidate

[Dave Korn]

Roberto Bagnara wrote:
> Dave Korn wrote:

>> Target: i686-pc-cygwin, cygwin-1.7.0-42, gcc-4.3.2, ppl configured with
>> --enable-shared --disable-static, no -fexceptions, no --enable-cxx.
> 
> I am not following here. There are no "-fexceptions" and "--enable-cxx"
> in the PPL configuration procedure.  In contrast, "--enable-cxx"
> is an option of GMP's configuration procedure.  Moreover, if GMP was
> not compiled with the C++ interface enabled there is no way the PPL
> can work (even though compilation should fail in such case).

  Apologies for being unclear.  This is the commandline I used to configure
with (from my bash history):

  456  ./configure  --prefix=/opt/gcc-tools -v --disable-static
--enable-shared 2>&1 | tee conf.log

  This is the tail of conf.log

configure: WARNING: CANNOT PROPAGATE EXCEPTIONS BACK FROM GMP:
*** MEMORY EXHAUSTION MAY RESULT IN ABRUPT TERMINATION.
*** This is OK, if you do not plan to use the bounded memory capabilities
*** offered by the PPL.  Otherwise, if you are using GCC or the Intel C/C++
*** compiler, please make sure you use a version of GMP compiled with the
*** `-fexceptions' compiler option.
*** To build such a version, you can configure GMP as follows:
*** CPPFLAGS=-fexceptions ./configure --enable-cxx --prefix=/usr/local

  I just meant to say that I had seen this warning and /not/ acted on it.

> Can you send us more details about which version of GMP you are using
> and how it was configured?  

  These are the versions:

$ cygcheck -c gmp mpfr
Cygwin Package Information
Package  VersionStatus
gmp  4.2.4-2OK
mpfr 2.4.1-2OK

  As I did not built them myself I do not know what the configuration was, but
I found these lines in /usr/include/gmp.h:

/* Instantiated by configure. */
#if ! defined (__GMP_WITHIN_CONFIGURE)
/* #undef _LONG_LONG_LIMB */
#define __GMP_LIBGMP_DLL  1
#endif

> We also need the files config.log and
> config.h generated by PPL's configure script.

  Do you still want these in light of the above information?

cheers,
  DaveK

Re: Call for testers: MPC-0.6 released

[Dave Korn]

Kaveh R. Ghazi wrote:
> From: "Kaveh R. Ghazi" 
> 
>> I've been relaying the messages, (but I haven't seen the MPC webpage
>> updated to reflect this yet).
> 
> Okay it's updated, we've got a pretty comprehensive list of platforms.
> 
> http://www.multiprecision.org/index.php?prog=mpc&page=platforms
> 
> Thanks everyone for your test results!

  Oh, I see I forgot to give you all my version details for the table!  Here
is the information:

$ cygcheck -c gmp mpfr gcc4
Cygwin Package Information
Package  VersionStatus
gcc4 4.3.2-2OK
gmp  4.2.4-2OK
mpfr 2.4.1-2OK

(Note that the trailing -N suffix is the Cygwin distro sub-release number and
can be ignored here.)

cheers,
  DaveK

Re: [PPL-devel] First PPL 0.10.1 release candidate

[Roberto Bagnara]

Dave Korn wrote:

Roberto Bagnara wrote:

Dave Korn wrote:



Target: i686-pc-cygwin, cygwin-1.7.0-42, gcc-4.3.2, ppl configured with
--enable-shared --disable-static, no -fexceptions, no --enable-cxx.

I am not following here. There are no "-fexceptions" and "--enable-cxx"
in the PPL configuration procedure.  In contrast, "--enable-cxx"
is an option of GMP's configuration procedure.  Moreover, if GMP was
not compiled with the C++ interface enabled there is no way the PPL
can work (even though compilation should fail in such case).


  Apologies for being unclear.  This is the commandline I used to configure
with (from my bash history):

  456  ./configure  --prefix=/opt/gcc-tools -v --disable-static
--enable-shared 2>&1 | tee conf.log


I assume --disable-static is OK for Cygwin.


  This is the tail of conf.log

configure: WARNING: CANNOT PROPAGATE EXCEPTIONS BACK FROM GMP:
*** MEMORY EXHAUSTION MAY RESULT IN ABRUPT TERMINATION.
*** This is OK, if you do not plan to use the bounded memory capabilities
*** offered by the PPL.  Otherwise, if you are using GCC or the Intel C/C++
*** compiler, please make sure you use a version of GMP compiled with the
*** `-fexceptions' compiler option.
*** To build such a version, you can configure GMP as follows:
*** CPPFLAGS=-fexceptions ./configure --enable-cxx --prefix=/usr/local

  I just meant to say that I had seen this warning and /not/ acted on it.


That's OK.  I mean, CLooG does not use that capabilities, so there is no
problem here.


We also need the files config.log and
config.h generated by PPL's configure script.


  Do you still want these in light of the above information?


Yes, please.
Thanks,

   Roberto

--
Prof. Roberto Bagnara
Computer Science Group
Department of Mathematics, University of Parma, Italy
http://www.cs.unipr.it/~bagnara/
mailto:bagn...@cs.unipr.it

Re: First PPL 0.10.1 release candidate

[Dave Korn]

Dave Korn wrote:

  OMG.  Sorry everyone, it didn't occur to me to check the size of the log
file until after I sent it and I simply didn't think it could be as much as
half a meg.

cheers,
  DaveK

Re: Need some help with fixincludes.

[Dominique Dhumieres]

Dave,

I have looked more closely to the sed part and it is probably incorrect,
i.e. doing nothing. I'll coninue to experiment, but if you or someone else
have idea, I'll be glad to use it.

Thanks,

Dominique

Re: Need some help with fixincludes.

[Paolo Bonzini]

Dominique Dhumieres wrote:
> Dave,
> 
> I have looked more closely to the sed part and it is probably incorrect,
> i.e. doing nothing. I'll coninue to experiment, but if you or someone else
> have idea, I'll be glad to use it.


sed does not have +.  You need to use [ \t][ \t]* assuming that autogen
replaces \t (I think it does).


Paolo

Re: IRIX stdint patch

[Rainer Orth]

Hi FX,

> Here's a patch to add knowledge about C99 stdint.h types to the target  
> configuration for IRIX. I did that from the system headers of a  
> IRIX6.5 box, but can't bootstrap or regtest (I have very limited  
> access, can't run anything on it). If you can bootstrap and confirm  
> that tests gcc.dg/c99-stdint-*.c do not fail.

thanks for the patch.  This was on my agenda anyway.  A quick manual check
indicates that the patch is reasonable, with one exception: IRIX 5 doesn't
have a native , so use_gcc_stdint needs to be set to provide
there.

I'll regtest the patch and commit if it tests ok.

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Need some help with fixincludes.

[Dominique Dhumieres]

Paolo,

> sed does not have +.

Thanks for the hint. Apparently GNU sed version 4.1.5 has it, provided you use 
-r,
but I was wondering what to do since I did not see it in fixincl.x.
So I will use [ \t][ \t]*.

Dominique

Missing data alignment on MIPS

[Paul Koning]

This relates to bug 13167
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13617)

It looks like the compiler is generating appropriate code but gas
isn't doing the right thing with it, at least not consistently. 

With this test program, compiled with GCC 4.1.2 mipsel-netbsdelf:

int i = 3;
char foo[17] __attribute__ ((aligned(32)));

I get .bss aligned 2**4.

If I change the second line:

int i = 3;
static char foo[17] __attribute__ ((aligned(32)));

I get .bss aligned 2**5, which is what it should be.

The assembly files are basically the same; the only difference is a 
".local foo":

.file   1 "test.c"
.section .mdebug.abi32
.previous
.abicalls
.globl  i
.data
.align  2
.type   i, @object
.size   i, 4
i:
.word   3
.local  foo
.comm   foo,17,32
.ident  "GCC: (GNU) 4.1.2"

Should this be a binutils bug report, or can/should GCC work around
this?  As it stands, this is a "wrong code" bug, variables end up not
being aligned as requested.

  paul

Re: Need some help with fixincludes.

[Paolo Bonzini]

>> sed does not have +.
>
> Thanks for the hint. Apparently GNU sed version 4.1.5 has it, provided you 
> use -r,

It also has \+ without -r, but neither -r nor \+ are portable.

Paolo

Re: [PPL-devel] First PPL 0.10.1 release candidate

[Dave Korn]

Roberto Bagnara wrote:
>>   456  ./configure  --prefix=/opt/gcc-tools -v --disable-static
>> --enable-shared 2>&1 | tee conf.log
> 
> I assume --disable-static is OK for Cygwin.

  Yes, it certainly should be, and is required because our distro ships only a
DLL version of GMP, and no static lib.

> That's OK.  I mean, CLooG does not use that capabilities, so there is no
> problem here.

  Thanks, I was wondering.

>>> We also need the files config.log and
>>> config.h generated by PPL's configure script.
>>
>>   Do you still want these in light of the above information?
> 
> Yes, please.

  Sure, will send them off-list to reduce the server traffic :)

cheers,
  DaveK

Re: IRIX stdint patch

[Tom Christensen]

Rainer Orth wrote:

Hi FX,

Here's a patch to add knowledge about C99 stdint.h types to the target  
configuration for IRIX. I did that from the system headers of a  
IRIX6.5 box, but can't bootstrap or regtest (I have very limited  
access, can't run anything on it). If you can bootstrap and confirm  
that tests gcc.dg/c99-stdint-*.c do not fail.


thanks for the patch.  This was on my agenda anyway.  A quick manual check
indicates that the patch is reasonable, with one exception: IRIX 5 doesn't
have a native , so use_gcc_stdint needs to be set to provide
there.


All of IRIX 6.x is not equal and stdint.h was not added until IRIX 6.5.

Please consider extending the patch to wrap stdint.h for any IRIX < 6.5 
and not just IRIX 5.


-tgc

Re: Call for testers: MPC-0.6 released

[Ralf Wildenhues]

* Kaveh R. Ghazi wrote on Tue, Apr 07, 2009 at 05:32:14PM CEST:
>
> I think we're just missing AIX5.2.  Ralf you did that last time for the 
> svn tarball.  Would you please repeat your testing with mpc-0.6?

Sorry for the delay.  Issues on AIX 5.2:

- This time, I had an old version of mpc installed.  This caused this
failure:

Error: header and library do not match
mpc_get_version: "0.6-dev"
MPC_VERSION_STRING: "0.6"
FAIL: tget_version

Hmm, I don't quite see yet how that could have happened (and I ran "make
install" before analyzing this, so the failure is gone now.


- I still needed to set OBJECT_MODE=64 before running make,
otherwise libmpc is not created.

- These lines in configure are not portable:

   GMP_CC="`$CPP $CPPFLAGS conftest.c 2> /dev/null | $EGREP MPC_OPTION | $SED -e
 's/MPC_OPTION //g' | $SED -e 's/"//g'`"

  GMP_CFLAGS="`$CPP $CPPFLAGS conftest.c 2> /dev/null | $EGREP MPC_OPTION | 
$SED -e 's/MPC_OPTION //g'| $SED -e 's/"//g'`"

and cause these errors:
  sed: Function s/"//g"`" cannot be parsed.
  ../mpc-0.6/configure[4212]: //g| $SED -e s///g':  not found
  yes CC= CFLAGS=

  ../mpc-0.6/configure[4201]: syntax error at line 4258 : `(' unexpected

Please replace them with these lines, respectively:

  GMP_CC=`$CPP $CPPFLAGS conftest.c 2> /dev/null | $EGREP MPC_OPTION | $SED -e 
's/MPC_OPTION //g' | $SED -e 's/"//g'`

  GMP_CFLAGS=`$CPP $CPPFLAGS conftest.c 2> /dev/null | $EGREP MPC_OPTION | $SED 
-e 's/MPC_OPTION //g'| $SED -e 's/"//g'`

You never need to put the right hand side of a shell assignment in
double quotes; see here for a detailed explanation:


(I thought we've already fixed this before?)

Cheers,
Ralf

Re: Missing data alignment on MIPS

[Andreas Schwab]

Paul Koning  writes:

> It looks like the compiler is generating appropriate code but gas
> isn't doing the right thing with it, at least not consistently. 
>
> With this test program, compiled with GCC 4.1.2 mipsel-netbsdelf:
>
> int i = 3;
> char foo[17] __attribute__ ((aligned(32)));
>
> I get .bss aligned 2**4.

That's not a bug.  The symbol is defined in the COMMON section, not the
.bss section.  You can use -fno-common to tell the compiler to put the
symbol into the .bss section.  But either way the final linked
executable should have the symbol properly aligned.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

gcc-4.4-20090407 is now available

[gccadmin]

Snapshot gcc-4.4-20090407 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090407/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 145701

You'll find:

gcc-4.4-20090407.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20090407.tar.bz2 C front end and core compiler

gcc-ada-4.4-20090407.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20090407.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20090407.tar.bz2  C++ front end and runtime

gcc-java-4.4-20090407.tar.bz2 Java front end and runtime

gcc-objc-4.4-20090407.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20090407.tar.bz2The GCC testsuite

Diffs from 4.4-20090331 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
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.

Re: [SOLVED] Re: stdint.h type information needed

[Joseph S. Myers]

On Fri, 3 Apr 2009, Dave Korn wrote:

>   Got it: the key is that the types we use in our stdint.h target files have
> to match the exact wording used at the top of c_common_nodes_and_builtins:

This requirement is documented in tm.texi (under SIZE_TYPE, to which the 
documentation of the other target macros refers).

If the target macros for such types are converted to target hooks in 
future, I imagine they'd return an enum value from enum integer_type_kind 
instead of a string, and take an enum value from enum tree_index or enum 
c_tree_index or some other similar enum to identify the typedef in 
question instead of having one hook per type.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Revised GCC Runtime Library Exception

[Joseph S. Myers]

On Thu, 2 Apr 2009, Paolo Bonzini wrote:

> > The "Compilation Process" transforms code entirely represented in
> > non-intermediate languages designed for human-written code,
> > and/or in Java Virtual Machine byte code, into Target Code.
> 
> Two months for this???  And what about CLR (Mono, .NET) bytecode for 
> example???

If someone wishes to add a front end (for C#, say) to GCC that works like 
GCJ, by using a non-GPLv3-compatible external program to compile source 
code into CLR bytecode that is then treated as input to GCC, then no doubt 
the FSF can consider changing the exception accordingly.  The special case 
for JVM byte code deals with the issue of GCJ using ECJ to compile Java 
source.

-- 
Joseph S. Myers
jos...@codesourcery.com

Fixing the pre-pass scheduler on x86 (Bug 38403)

[Shobaki, Ghassan]

Hi,

I am considering working on fixing the pre-pass scheduling problem on
x86 (Bug 38403). The pre-pass instruction scheduler currently increases
register pressure to a degree that causes the register allocator to
fail. Before I commit to this task, I would like to gather as much
information as possible about the problem. What does the GCC community
know about the complexity of this problem? Has anyone ever worked on
fixing it? If yes, did they come up with any interesting findings that I
should be aware of? 

In theory, the problem can be fixed by adding a heuristic that keeps
track of register pressure during scheduling and favors the scheduling
decisions that lead to less register pressure. I have done some initial
investigation and found that the scheduler already has a heuristic that
attempts to do that, but apparently this heuristic does not work as
expected. The code I am referring to is in the function
rank_for_schedule in haifa-sched.c. I have modified the code in that
function to make this register-weight heuristic the top-priority
heuristic but that did not make a big difference (the number of passing
CPU2006 benchmarks only went up from 5 to 6 out of 29 benchmarks). 

So, my current hypothesis is that the problem can be fixed by developing
a more effective register pressure heuristic. To keep the problem
simpler, I plan on initially limiting my work to basic-block scheduling
(i.e., setting the maximum number of basic blocks in a scheduling region
to 1). We have reasons to believe that even with this limitation,
pre-pass scheduling can give 1-2% performance improvement on x86.

Any known information about this problem?

Thank you in advance!

-Ghassan

Re: Patch for mingw stdint information

[Joseph S. Myers]

On Sat, 4 Apr 2009, FX wrote:

> find failures of c99-stdint-1.c, it means the mingw headers need fixing (I'm
> particularly worried about int_fast8_t, which is "char" rather than "signed
> char", and I suspect this could spell trouble).

These types being plain "char" fails to conform to C99, but the compiler 
code allows it (and the testcases allow it) because of use in Solaris 
headers (and changing for an existing system would break compatibility of 
C++ mangling for any code using the type).  (Plain "char" is not a "signed 
integer type" or "unsigned integer type" in C99 terms, and the types are 
required to be signed integer types or unsigned integer types.)

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: update_version_svn (was: Minimum required GNAT version for bootstrap of GNAT on gcc trunk)

[Joseph S. Myers]

On Sat, 4 Apr 2009, Gerald Pfeifer wrote:

> 2009-04-04  Gerald Pfeifer  
> 
>   * update_web_docs_svn: Run this script under plain /bin/sh
>   as opposed to /bin/sh -x.

I think this is OK.  -x was probably more useful before the script used 
set -e to exit on errors.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Bootstrap broken on sparc-linux trunk between 145310:145425 because of new genattrtab.c va_arg (p, HOST_WIDE_INT) warning

[Joseph S. Myers]

On Sun, 5 Apr 2009, Laurent GUERBY wrote:

> I'm thinking of changing my auto tester to report a broken bootstrap
> (the first time a bootstrap fails), is there a normalized way to
> report such failures to gcc-testresults@ or g...@?

The "regression" component in Bugzilla exists for automatic reports from 
regression testers (mainly for testsuite regressions rather than bootstrap 
failures, I think), but using it without enough people who are going to 
follow up actively with updates on the reports, closing them once fixed, 
moving to appropriate components after further investigation, marking 
duplicates, etc., would be a bad idea.  I also don't know if there's a 
better way of using it automatically than interacting with the web 
interface to Bugzilla via screen scraping.

The existing "bootstrap" component needs people going through past reports 
and establishing if the issues reported are still present; bugs tend just 
to languish there.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Need some help with fixincludes.

[Joseph S. Myers]

On Tue, 7 Apr 2009, Dominique Dhumieres wrote:

> +sed = "/#define[ \t]+INTPTR_MIN[\t]+INT64_MIN/#define INTPTR_MIN 
> ((intptr_t) INT64_MIN)/";
> +sed = "/#define[ \t]+INTPTR_MIN[\t]+INT32_MIN/#define INTPTR_MIN 
> ((intptr_t) INT32_MIN)/";
> +sed = "/#define[ \t]+INTPTR_MAX[\t]+INT64_MAX/#define INTPTR_MAX 
> ((intptr_t) INT64_MAX)/";
> +sed = "/#define[ \t]+INTPTR_MAX[\t]+INT32_MAX/#define INTPTR_MAX 
> ((intptr_t) INT32_MAX)/";
> +sed = "/#define[ \t]+UINTPTR_MIN[\t]+INT64_MIN/#define UINTPTR_MIN 
> ((uintptr_t) INT64_MIN)/";
> +sed = "/#define[ \t]+UINTPTR_MIN[\t]+INT32_MIN/#define UINTPTR_MIN 
> ((uintptr_t) INT32_MIN)/";
> +sed = "/#define[ \t]+UINTPTR_MAX[\t]+INT64_MAX/#define UINTPTR_MAX 
> ((uintptr_t) INT64_MAX)/";
> +sed = "/#define[ \t]+UINTPTR_MAX[\t]+INT32_MAX/#define UINTPTR_MAX 
> ((uintptr_t) INT32_MAX)/";
> +sed = "/#define[ \t]+SIZE_MAX[\t]+INT32_MAX/#define SIZE_MAX ((size_t) 
> INT32_MAX)/";
> +sed = "/#define[ \t]+SIZE_MAX[\t]+INT64_MAX/#define SIZE_MAX ((size_t) 
> INT64_MAX)/";
> +sed = "/#define[ \t]+UINT8_C(v)[\t]+(v ## U)/#define[\t]+UINT8_C(v) 
> (v)/";
> +sed = "/#define[ \t]+UINT16_C(v)[\t]+(v ## U)/#define[\t]+UINT16_C(v) 
> (v)/";

This is the fix proper.  It's not *correct*, in that the macros must be 
usable in #if conditions which means they must not contain casts, although 
the testcases may not cover this issue accurately.

> +test_text = "#define INTPTR_MININT64_MIN\n"
> + "#define INTPTR_MAXINT64_MAX\n"
> + "#define UINTPTR_MIN   UINT64_MIN\n"
> + "#define UINTPTR_MAX   UINT64_MAX\n"
> + "#define SIZE_MAX  UINT64_MAX\n"
> + "#define UINT8_C(v)   (v ## U)\n"
> + "#define UINT16_C(v)  (v ## U)\n";

This is one half of the testcase for the fix: text taken from the broken 
system header.

The other half of the testcase for the fix is updates to 
tests/base/stdint.h to show what the output should be for that input from 
the broken system header.  You don't include that diff.  Typically you 
generate it by running the fixincludes testsuite and copying the output 
header it generates into your source tree after verifying that fixincludes 
did indeed make the desired changes to the test text.

-- 
Joseph S. Myers
jos...@codesourcery.com

RE: Missing data alignment on MIPS

[Paul Koning]

> Paul Koning  writes:
> 
> > It looks like the compiler is generating appropriate code but gas
> > isn't doing the right thing with it, at least not consistently.
> >
> > With this test program, compiled with GCC 4.1.2 mipsel-netbsdelf:
> >
> > int i = 3;
> > char foo[17] __attribute__ ((aligned(32)));
> >
> > I get .bss aligned 2**4.
> 
> That's not a bug.  The symbol is defined in the COMMON section, not
the
> .bss section.  You can use -fno-common to tell the compiler to put the
> symbol into the .bss section.  But either way the final linked
> executable should have the symbol properly aligned.

You're right, it appears that it does.

Thanks for setting me straight.

paul

Re: update_version_svn

[Gerald Pfeifer]

On Wed, 8 Apr 2009, Joseph S. Myers wrote:
>> 2009-04-04  Gerald Pfeifer  
>> 
>>  * update_web_docs_svn: Run this script under plain /bin/sh
>>  as opposed to /bin/sh -x.
> I think this is OK.  -x was probably more useful before the script used 
> set -e to exit on errors.

Thanks for having a look, Joseph!  I applied my change and also updated
the instance of this script on gcc.gnu.org.  Let's see wether the next
run in some 22 hours will again be able to push through a message to the
gccadmin list.  If not, let me know and I'll have another look what we
may be able to cut.

Gerald

Re: Fixing the pre-pass scheduler on x86 (Bug 38403)

[Vladimir Makarov]

Shobaki, Ghassan wrote:

Hi,

I am considering working on fixing the pre-pass scheduling problem on
x86 (Bug 38403). The pre-pass instruction scheduler currently increases
register pressure to a degree that causes the register allocator to
fail. Before I commit to this task, I would like to gather as much
information as possible about the problem. What does the GCC community
know about the complexity of this problem? Has anyone ever worked on
fixing it? If yes, did they come up with any interesting findings that I
should be aware of? 


In theory, the problem can be fixed by adding a heuristic that keeps
track of register pressure during scheduling and favors the scheduling
decisions that lead to less register pressure. I have done some initial
investigation and found that the scheduler already has a heuristic that
attempts to do that, but apparently this heuristic does not work as
expected. The code I am referring to is in the function
rank_for_schedule in haifa-sched.c. I have modified the code in that
function to make this register-weight heuristic the top-priority
heuristic but that did not make a big difference (the number of passing
CPU2006 benchmarks only went up from 5 to 6 out of 29 benchmarks). 

That is a wrong heuristic because it incorrectly calculates the insn 
impact on register pressure.  For example, we have


1. use a
2. use a, dead a

The heuristic believes that the 2nd insn decreases register pressure and 
prefers #2 to #1 and that is wrong because in this case a is not 
becoming dead.


Although this heuristic was reported to be working well for powerpc and 
therefore it was added to GCC.

So, my current hypothesis is that the problem can be fixed by developing
a more effective register pressure heuristic. To keep the problem
simpler, I plan on initially limiting my work to basic-block scheduling
(i.e., setting the maximum number of basic blocks in a scheduling region
to 1). We have reasons to believe that even with this limitation,
pre-pass scheduling can give 1-2% performance improvement on x86.

Any known information about this problem?


I've been working on register-pressure sensitive insn scheduling last 
two months and I hope to submit this work for gcc4.5.  I am implementing 
also a mode in insn-scheduler to do only live range shrinkage.  
Implementing register pressure insn scheduling is not easy.  I already 
mentioned one issue above about dead notes.  Another issue is necessity 
to simultaniously work with ready and queue (not only with ready) to 
choose insn to schedule.  A lot of communication with IRA should be 
added too.


The bug itself is also a complicated issue which needs a good knowledge 
of insn scheduler, RA, and even reload to fix this.  The most bug cases 
are like


1. insn containing pseudos
2. ax<- something

The 2nd insn is moved before the 1st one and the first insn needs ax 
(e.g. it is a division).


The reload problem is more complicated.  For example, the 1st insn has 
only one alternative requiring ax

 1st operand: =a, r, ...
 2nd operand:  0, 0, ...

if both operands (pseudos) got memory, than cost of reloading for the 
1st and 2nd alternative is the same.  Reload can choose the 1st 
alternative and we have the same problem as above.

Re: Fixing the pre-pass scheduler on x86 (Bug 38403)

[Steven Bosscher]

On Wed, Apr 8, 2009 at 5:19 AM, Vladimir Makarov  wrote:
> Shobaki, Ghassan wrote:
>>
>> Hi,
>>
>> I am considering working on fixing the pre-pass scheduling problem on
>> x86 (Bug 38403). The pre-pass instruction scheduler currently increases
>> register pressure to a degree that causes the register allocator to
>> fail. Before I commit to this task, I would like to gather as much
>> information as possible about the problem. What does the GCC community
>> know about the complexity of this problem? Has anyone ever worked on
>> fixing it? If yes, did they come up with any interesting findings that I
>> should be aware of?
>> In theory, the problem can be fixed by adding a heuristic that keeps
>> track of register pressure during scheduling and favors the scheduling
>> decisions that lead to less register pressure. I have done some initial
>> investigation and found that the scheduler already has a heuristic that
>> attempts to do that, but apparently this heuristic does not work as
>> expected. The code I am referring to is in the function
>> rank_for_schedule in haifa-sched.c. I have modified the code in that
>> function to make this register-weight heuristic the top-priority
>> heuristic but that did not make a big difference (the number of passing
>> CPU2006 benchmarks only went up from 5 to 6 out of 29 benchmarks).
>
> That is a wrong heuristic because it incorrectly calculates the insn impact
> on register pressure.  For example, we have
>
> 1. use a
> 2. use a, dead a
>
> The heuristic believes that the 2nd insn decreases register pressure and
> prefers #2 to #1 and that is wrong because in this case a is not becoming
> dead.
>
> Although this heuristic was reported to be working well for powerpc and
> therefore it was added to GCC.
>>
>> So, my current hypothesis is that the problem can be fixed by developing
>> a more effective register pressure heuristic. To keep the problem
>> simpler, I plan on initially limiting my work to basic-block scheduling
>> (i.e., setting the maximum number of basic blocks in a scheduling region
>> to 1). We have reasons to believe that even with this limitation,
>> pre-pass scheduling can give 1-2% performance improvement on x86.
>>
>> Any known information about this problem?
>>
>>
> I've been working on register-pressure sensitive insn scheduling last two
> months and I hope to submit this work for gcc4.5.  I am implementing also a
> mode in insn-scheduler to do only live range shrinkage.

Is all of this still necessary if the selective scheduler (with
register renaming) is made to work on i686/x86_64 after reload?

Ciao!
Steven

Intermittent/non-reproducible gcc testsuite failures

[Michael Eager]

Hi --

I'm running the gcc test suite on powerpc-unknown-eabisim
on the trunk and I get results which are different from
one run to the next.  When I run the failing tests by
hand, all pass.  Mike Stein also has noted that some of
the tests are intermittent failures.

There are only a few test cases which I've noticed this
non-reproducible behavior:
   gcc.c-torture/execute/builtins/fprintf.c
   gcc.c-torture/execute/builtins/fputs.c
   gcc.c-torture/execute/builtins/printf.c
   gcc.c-torture/execute/20020406-1.c
   gcc.c-torture/execute/fprintf-1.c
   gcc.c-torture/execute/fprintf-chk-1.c
   gcc.c-torture/execute/printf-chk-1.c
   gcc.c-torture/execute/va-arg-21.c
   gcc.c-torture/execute/vfprintf-1.c
   gcc.c-torture/execute/vfprintf-chk-1.c
   gcc.dg/packed-array.c
   gcc.dg/matrix/matrix-2.c

Clearly, something is not initialized or is being overwritten.

I'm assuming that this is a problem only on powerpc
and perhaps only powerpc-eabi.

Does anyone have any suggestions on how to get one of
these tests to fail consistently, or a different approach
to finding the cause of the intermittent failures?

--
Michael Eagerea...@eagercon.com
1960 Park Blvd., Palo Alto, CA 94306  650-325-8077