date:20091019

GCC 4.4.2 Released

2009-10-19 Thread Jakub Jelinek

The GNU Compiler Collection version 4.4.2 has been released. 

GCC 4.4.2 is a bug-fix release containing fixes for regressions and
serious bugs in GCC 4.4.1.  This release is available from the
FTP servers listed at:

  http://www.gnu.org/order/ftp.html

Please do not contact me directly regarding questions or comments about
this release.  Instead, use the resources available from
http://gcc.gnu.org.

As always, a vast number of people contributed to this GCC release -- far
too many to thank individually!

Re: i370 port - constructing compile script

2009-10-19 Thread Paul Edwards


.../configure --target=i370-mvs --prefix=... --with-sysroot=...  \
  --enable-languages=c

where prefix points to the directory where the cross-compiler
should be installed, and sysroot points to the directory where
the MVS libraries and header are installed.


Ok, I used

../configure --target=i370-mvspdp --prefix=/devel/mvscross --with-sysroot=/devel/mvshead 
--enable-languages=c


plus make and make install

then I went to

mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx

and replaced it with a script that does:

i370-mvspdp-xxx -S $*


For step 3 (cross-building a native compiler), you'd need
something along the lines of

 .../configure --build=i686-linux --host=i370-mvs --target=i370-mvs \
   --prefix=... --with-build-sysroot=... --enable-languages=c


./configure --build-i686-linux --host=i370-mvspdp --target=i370-mvspdp --prefix=/devel/mvshost 
--with-build-sysroot=/devel/mvshead --enable-languages=c


I wasn't sure if that --with-build-sysroot was right - pointing to
the same headers, but couldn't think of anything else to do with it!


This configure run will then use the i370-mvs-gcc cross-compiler
you built in step 2 in order to detect MVS host properties.


Ok, it (3.4.6 I am using) got as far as:

checking size of void *... configure: error: cannot determine a size of void 
*

make: *** [configure-gcc] Error 1

I haven't had a chance to investigate what it's trying to do there, to
see if I can devise a workaround.

I know that it seems to try to compile with -g all the time which
gives a warning about it not being supported, but I don't think
warnings produce bad return codes like that.

BFN.  Paul.

char drawstrings[DRAW_MAX][] = { .. give error

2009-10-19 Thread Bernd Roesch

Hi, 

I compile an old code which use this and i think its compile with Gcc 2.95
and the
PPC GCC 1998 or 1999
it fail to compile with newer compiler.

#define DRAW_MAX4
char drawstrings[DRAW_MAX][] = {
Number of points drawn using 3D hardware:,
Number of lines drawn using 3D hardware:,
Number of triangles drawn using 3D hardware:,
Number of quads drawn using 3D hardware:};

give error on GCC3.4.0

98 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h elements
of array `drawstrings' have incomplete type 

gcc4.5.0 report this.

6 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h:98 array
type has incomplete element type 

Is this a GGC Bug, or is that syntax no longer support ?.

I change code to this, thats more easy and it compile ok but must check if
its same.

const char * drawstrings[] = {
Number of points drawn using 3D hardware:,
Number of lines drawn using 3D hardware:,
Number of triangles drawn using 3D hardware:,
Number of quads drawn using 3D hardware:
};

Bye

Re: i370 port - constructing compile script

2009-10-19 Thread Ulrich Weigand

Paul Edwards wrote:

 Ok, I used
 
 ../configure --target=i370-mvspdp --prefix=/devel/mvscross 
 --with-sysroot=/devel/mvshead 
  --enable-languages=c
 
 plus make and make install
 
 then I went to
 
 mvscross/bin and renamed i370-mvspdp-gcc to i370-mvspdp-xxx
 
 and replaced it with a script that does:
 
 i370-mvspdp-xxx -S $*

Maybe a more generic way to work around the missing assembler and linker
would be to provide dummy scripts i370-mvspdp-as and i370-mvspdp-ld, where
the assembler would simply copy the assembler source input as text to the
object file output, and the linker would collect all input files into
a tar file (or some other archive) as executable output ...

This would allow usual build processes (including make) to proceed as
expected.

  For step 3 (cross-building a native compiler), you'd need
  something along the lines of
 
   .../configure --build=i686-linux --host=i370-mvs --target=i370-mvs \
 --prefix=... --with-build-sysroot=... --enable-languages=c
 
 ./configure --build-i686-linux --host=i370-mvspdp --target=i370-mvspdp 
 --prefix=/devel/mvshost 
  --with-build-sysroot=/devel/mvshead --enable-languages=c
 
 I wasn't sure if that --with-build-sysroot was right - pointing to
 the same headers, but couldn't think of anything else to do with it!

That should be fine.  (The --with-build-sysroot option may actually not
be required at all when building just a C compiler.)

 Ok, it (3.4.6 I am using) got as far as:
 
 checking size of void *... configure: error: cannot determine a size of void 
 *
 make: *** [configure-gcc] Error 1
 
 I haven't had a chance to investigate what it's trying to do there, to
 see if I can devise a workaround.

The compiler error output found in the config.log file should hopefully
point to the problem ...

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  ulrich.weig...@de.ibm.com

Re: attribute((optimize)) and fast-math related oddities

2009-10-19 Thread Ian Lance Taylor

tbp tbp...@gmail.com writes:

 Merrily trying to make a test-case showing how unmanageable it is to
 try to override *math* flags per function, i soon had to stop
 because...

Please file a bug report.

__attribute__((optimize())) is definitely only half-baked.

Ian

Re: --enable-plugin option overloaded

2009-10-19 Thread Ian Lance Taylor

Andrew Haley a...@redhat.com writes:

 Matthias Klose wrote:
 --enable-plugin is used by classpath (part of libjava) and now by GCC
 itself. disabling the build of the gcjwebplugin now disables plugin
 support in GCC as well. Please could the option for enabling GCC plugin
 support be renamed to something like --enable-plugins,
 --enable-gcc-plugin, --enable-gcc-plugins ? The only reason for not
 renaming the existing libjava option is that it was there first, and
 that it is part of an imported tree.

 That doesn't seem like a good enough reason to me.  We should rename
 the libjava option --enable-web-plugin or --enable-browser-plugin .

We could rename in the top leve configure/Makefile if we don't want to
touch the classpath sources.

Ian

Re: char drawstrings[DRAW_MAX][] = { .. give error

2009-10-19 Thread Ian Lance Taylor

Bernd Roesch nospamn...@gmx.de writes:

 I compile an old code which use this and i think its compile with Gcc 2.95
 and the
 PPC GCC 1998 or 1999
 it fail to compile with newer compiler.

 #define DRAW_MAX4
 char drawstrings[DRAW_MAX][] = {
 Number of points drawn using 3D hardware:,
 Number of lines drawn using 3D hardware:,
 Number of triangles drawn using 3D hardware:,
 Number of quads drawn using 3D hardware:};

 give error on GCC3.4.0

 98 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h elements
 of array `drawstrings' have incomplete type 

 gcc4.5.0 report this.

 6 E:\amiga\AmiDevCpp\bernd\StormMesaNew\src\AMIGA\src\ADisp_HW.h:98 array
 type has incomplete element type 

 Is this a GGC Bug, or is that syntax no longer support ?.

 I change code to this, thats more easy and it compile ok but must check if
 its same.

 const char * drawstrings[] = {
 Number of points drawn using 3D hardware:,
 Number of lines drawn using 3D hardware:,
 Number of triangles drawn using 3D hardware:,
 Number of quads drawn using 3D hardware:
 };

This question is not appropriate for the gcc@gcc.gnu.org mailing
list.  It would be appropriate for gcc-h...@gcc.gnu.org.  Please take
any followups to gcc-help.  Thanks.

Your program is not valid C, and I don't see how it could ever have
been compiled by any C compiler.  Changing it to something like
char drawstrings[DRAW_MAX][80]
would work.

Ian

Re: --enable-plugin option overloaded

2009-10-19 Thread Andrew Haley

Ian Lance Taylor wrote:
 Andrew Haley a...@redhat.com writes:
 
 Matthias Klose wrote:
 --enable-plugin is used by classpath (part of libjava) and now by GCC
 itself. disabling the build of the gcjwebplugin now disables plugin
 support in GCC as well. Please could the option for enabling GCC plugin
 support be renamed to something like --enable-plugins,
 --enable-gcc-plugin, --enable-gcc-plugins ? The only reason for not
 renaming the existing libjava option is that it was there first, and
 that it is part of an imported tree.
 That doesn't seem like a good enough reason to me.  We should rename
 the libjava option --enable-web-plugin or --enable-browser-plugin .
 
 We could rename in the top leve configure/Makefile if we don't want to
 touch the classpath sources.

That sounds like a nice solution.

Andrew.

Re: attribute((optimize)) and fast-math related oddities

2009-10-19 Thread H.J. Lu

On Mon, Oct 19, 2009 at 10:34 AM, Ian Lance Taylor i...@google.com wrote:
 tbp tbp...@gmail.com writes:

 Merrily trying to make a test-case showing how unmanageable it is to
 try to override *math* flags per function, i soon had to stop
 because...

 Please file a bug report.

 __attribute__((optimize())) is definitely only half-baked.


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565


-- 
H.J.

RE: Understanding IRA

2009-10-19 Thread Ian Bolton

Hi Jeff and Vladimir.

Jeff: I'd be interested in trying the patch if you can send it my way.

Vladimir: Today I have seen reasonable improvements on
progressively-trimmed-down versions of a *single* test case by applying
some cost adjustments in the case when an operand wants one of our
bottom registers and IRA is considering giving it an alternative
register or memory.  I will be experimenting with different values for
these two new costs and some more test cases tomorrow.

I wonder if the optimal register allocator will just end up being one
that tries all the algorithms and picks the best output for a given
case?  When it comes to optimisation, I prefer to bend the rules if at
all possible!

Best regards,
Ian

-Original Message-
From: Jeff Law [mailto:l...@redhat.com] 
Sent: 16 October 2009 16:45
To: Vladimir Makarov
Cc: Ian Bolton; gcc@gcc.gnu.org
Subject: Re: Understanding IRA

On 10/16/09 08:53, Vladimir Makarov wrote:

 The biggest problem of GCC RA is still reload pass.  It frequently 
 changes decisions of IRA not in a good way.
Agreed.  Not only may reload make a bad choice, it's horribly 
unpredictable.  Trivial changes often lead to drastically different 
reloading decisions which in turn drastically change the final output.

One of my favorites right now is the round-robin selection of spill 
registers to encourage reload inheritance.  While I certainly understand

the reasoning behind the code, it's amazingly frustrating to watch 
reload choose the worst possible spill register simply because of the 
round-robin selection.

I've got a little hack in the reload-v2 branch which queries IRA to 
mitigate this problem, but it's merely a short-term hack until I can 
make reload inheritance go away.

jeff

Re: C++ Plugins

2009-10-19 Thread Benjamin Smedberg

On 10/11/09 12:13 PM, Terrence Miller wrote:
 (Version 4.5.0)
 
 There are plugin callbacks which trigger at the end of processing types
 and C++ functions,
 but I can not find a clean way for plugin code to notice a top-level
 variable declaration.
 
 I'm hoping that the answer does not require the plugin shared library to
 bind to global symbols of the compiler (i.e. global_namespace).

Why not? That's what dehydra does: it enumerates through the items in
global_namespace in PLUGIN_FINISH_UNIT.

--BDS

Re: Understanding IRA

2009-10-19 Thread Vladimir Makarov


Ian Bolton wrote:

Hi Jeff and Vladimir.

Jeff: I'd be interested in trying the patch if you can send it my way.

Vladimir: Today I have seen reasonable improvements on
progressively-trimmed-down versions of a *single* test case by applying
some cost adjustments in the case when an operand wants one of our
bottom registers and IRA is considering giving it an alternative
register or memory.  I will be experimenting with different values for
these two new costs and some more test cases tomorrow.

I wonder if the optimal register allocator will just end up being one
that tries all the algorithms and picks the best output for a given
case?  When it comes to optimisation, I prefer to bend the rules if at
all possible!

  
 I did not try progressive register allocator (in which I have some 
doubts) but I did a lot of experiments recently (last year) with ILP 
based register allocators: from simple spill model (which pseudos should 
be spilled) to RA with coalescing, live range splitting, 
rematerialization, and code selection (it needs  models on hard reg 
levels) including some models closed to Apel's and two Wilken's approaches.


 The simplest model can be only used to solve medium-size functions in 
reasonable time (about 10 minutes).  But even this model can not be used 
for function like reload.c::find_reloads.  More complex model problems 
can not be solved even for many tiny benchmarks (like heapsort) in 
reasonable time.  Although I used GLPK which is much slower than the 
best package (CPLEX).  Other algorithms for soliving ILP (like Balas' 
one) are even much worse.  The improvement for the simplest model was 
not significant unless profiling was used (in this case some SPECInt2000 
benchmarks were improved upto 20% on x86).


 In any case, I did not find optimal RA based on ILP is practical.  
About 4 years ago, I tried QAP (quadratic assignment problem) model 
approaches with the same conclusion.  Although I did not try multi 
commodity flow network approach for which there are better specialized 
algorithms because there are no good GPL-based packages for this 
(unfortunately the best one MCF has no such license). It could be an 
interesting research.

Re: C++ Plugins

2009-10-19 Thread Terrence Miller


response at end
Benjamin Smedberg wrote:

On 10/11/09 12:13 PM, Terrence Miller wrote:
  

(Version 4.5.0)

There are plugin callbacks which trigger at the end of processing types
and C++ functions,
but I can not find a clean way for plugin code to notice a top-level
variable declaration.

I'm hoping that the answer does not require the plugin shared library to
bind to global symbols of the compiler (i.e. global_namespace).


Why not? That's what dehydra does: it enumerates through the items in
global_namespace in PLUGIN_FINISH_UNIT.

--BDS
  
Because it makes the name global_namespace and the list 
order(TREE_CHAIN (t) points  to  a declaration
located earlier in the file than t) be part of the plugin interface and 
these two items are not documented.  Also
you end up with one way of handling top-level types (PLUGIN_FINISH_TYPE) 
and functions
(PLUGIN_CXX_CP_PRE_GENERICIZE) and a different way of handling 
variables.  A better scheme (IMO)
would be to have a plugin triggered when the declaration of a variable 
is complete and another pair of plugins

for scope entry/exit.


  Terrence

Improving code with no offset addressing

2009-10-19 Thread Michael Hope

Hi there.  The architecture I'm working on porting gcc to has indirect
addressing but no constant offset or register offset versions.  Code
like this:

void fill(int* p)
{
  p[0] = 0;
  p[1] = 0;
  p[2] = 0;
  p[3] = 0;

Turns into:
 X = p
 *X = 0
 X = X + 4
 *X = 0
 X = p
 X = X + 8
 *X = 0
 X = p
 X = X + 12
 *X = 0

at both -O and -O2.  Note that the first step recognises that X
contains p and correctly increases it instead of rebuilding it.

I'd like to generate the following code instead:
 X = p
 *X = 0
 X = X + 4
 *X = 0
 X = X + 4
 *X = 0
 X = p
 X = X + 4
 *X = 0

What is the best way to approach this?  It seems to be common across
ports (see the note on ia64 and ARM Thumb below).  Is there a cost
function I can change?  Will changing LEGITIMIZE_ADDRESS fix it?  Is
there some type of value tracking that could be turned on/added?

I've checked the ia64, which also only has indirect addressing, and
ARM Thumb which has limited offsets.  ia64 generates the same reload
base/add offset as mine:

mov r14 = r32
;;
st4 [r14] = r0, 4
;;
st4 [r14] = r0
adds r14 = 8, r32
;;
st4 [r14] = r0
adds r14 = 12, r32
;;
st4 [r14] = r0
adds r14 = 16, r32

ARM Thumb does the same when the offset is large (p[70] and p[71] in this case):

str r3, [r0] ; p[0]
str r3, [r0, #4] ; p[1]
str r3, [r0, #8] ; p[2]
str r3, [r0, #12] ; p[3]
mov r2, #140
mov r3, #0
lsl r2, r2, #1
str r3, [r0, r2] ; p[70]
mov r2, #142
lsl r2, r2, #1
str r3, [r0, r2] ; p[71]

Thanks for any pointers,

-- Michael

Re: When did arc-elf last build?

2009-10-19 Thread Joel Sherrill

Joern Rennecke wrote:

Quoting Joel Sherrill joel.sherr...@oarcorp.com:

Hi,

I got a random unsolicited email about arc-elf since
I pop up in google a lot asking cross compiler questions.
I decided to try to build it and as PR41747 indicates
4.3.4, 4.4.1, and the head all fail building libgcc2.c
in the same way. T

I did a search for arc-elf in the test results mail
list archives and found none.

The arc-elf port in mainline gcc is for the architecture used by the
ARCtangent-A4 and older cores, which has been superseded by the
ARCompact
architecture. The first article that a Google search turned up
suggests that this was in 2001:

1 2 >

1 - 100 of 115 matches

Mail list logo