cast to pointer from integer of different size

[Jack Howarth]

Geoff,
   Is this a potential problem in the compilation of libgcj on Darwin PPC
at -m64? I am seeing the following warning...

/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/xgcc 
-B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/ 
-B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ 
-B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem 
/sw/lib/gcc4/powerpc-apple-darwin8/include -isystem 
/sw/lib/gcc4/powerpc-apple-darwin8/sys-include -m64 -DHAVE_CONFIG_H 
-I/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/boehm-gc/include 
-fexceptions -Iinclude -I././targ-include -I.//libc/include -O2 -g -O2 
-fexceptions -Iinclude -I././targ-include -I.//libc/include -c 
../../../../gcc-4.2-20060915/boehm-gc/darwin_stop_world.c  -fno-common -DPIC -o 
.libs/darwin_stop_world.o
../../../../gcc-4.2-20060915/boehm-gc/darwin_stop_world.c: In function 
'FindTopOfStack':
../../../../gcc-4.2-20060915/boehm-gc/darwin_stop_world.c:76: warning: cast to 
pointer from integer of different size

which is the line...

frame = (StackFrame *)stack_start;

FYI,
   Jack

cast to pointer from integer of different size again

[Jack Howarth]

Geoff,
We seem to have the same issue in libffi when compiled on Darwin PPC
at -m64...

/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/xgcc 
-B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/./gcc/ 
-B/sw/lib/gcc4/powerpc-apple-darwin8/bin/ 
-B/sw/lib/gcc4/powerpc-apple-darwin8/lib/ -isystem 
/sw/lib/gcc4/powerpc-apple-darwin8/include -isystem 
/sw/lib/gcc4/powerpc-apple-darwin8/sys-include -m64 -DHAVE_CONFIG_H -I. 
-I../../../../gcc-4.2-20060915/libffi -I. -I. 
-I../../../../gcc-4.2-20060915/libffi/include -Iinclude 
-I../../../../gcc-4.2-20060915/libffi/src -Wall -g -fexceptions -O2 -g -O2 -m64 
-MT src/powerpc/ffi_darwin.lo -MD -MP -MF src/powerpc/.deps/ffi_darwin.Tpo -c 
../../../../gcc-4.2-20060915/libffi/src/powerpc/ffi_darwin.c  -fno-common -DPIC 
-o src/powerpc/.libs/ffi_darwin.o
../../../../gcc-4.2-20060915/libffi/src/powerpc/ffi_darwin.c: In function 
'ffi_prep_args':
../../../../gcc-4.2-20060915/libffi/src/powerpc/ffi_darwin.c:117: warning: cast 
from pointer to integer of different size

which is the line...

*next_arg++ = (unsigned)(char *)ecif->rvalue;

FYI,
  Jack

Re: Merging identical functions in GCC

[Michael Popov]

Mark Mitchell wrote:
Anyhow, I think that a combination of compiler/linker help and 
programmer help are useful.  There are some cases where you can do this 
automatically, and others where you might need programmer help.  Just as 
-ffast-math is useful, so might -fmerge-functions or 
__attribute__((mergeable)), even if that resulted in non-standard 
handling of function pointers.

Maybe combination of -fmerge-functions and __attribute__((unmergeable))
could be better? If programmer decide to use -fmerge-functions, he would
only like to mark functions that should not be touched by this optimization.
Otherwise, marking only mergeable functions in large project become a trouble.

Re: Merging identical functions in GCC

[Michael Popov]

Daniel Berlin wrote:

Actually, even for non-POD types, it catches a lot of templatized
member functions that mainly depend on size (but they are still
container classes).

Just another ( maybe stupid :-) ) idea. What about "partial merge"?

static int x = 0;
void a()
{
printf( "aaa" );
x = x + 1;
return;
}
void b()
{
printf( "bbb" );
x = x + 1;
return;
}

In sample code functions a() and b() aren't identical, but
after push of first printf's argument they become identical.
So, setting JMP in b() into a()'s code should produce valid code.

Re: Type yielded by TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD hook?

[Dorit Nuzman]

> I'm trying to add a hook for aligning vectors for loads.
>
> I'm using the altivec rs6000 code as a baseline.
>
> However, the instruction is like the iwmmxt_walign instruction in the
> ARM port; it takes
> a normalish register and uses the bottom bits... it doesn't use a
> full-width vector.
>
> GCC complains when my builtin pointed to by
> TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD yields a QImode result, because
> it has no way of converting that to the vector moe it is expecting.  I

Looks like it's a bug in the vectorizer - we treat both the return value of
the mask_for_load builtin, and the 3rd argument to the realign_load stmt
(e.g. Altivec's vperm), as variables of type 'vectype', instead of
obtaining the type from the target machine description. All we need to care
about is that these two variables have the same type. I'll look into that

dorit

> think the altivec side would have a similar problem, as the expected
> RTX output RTX is:
>
> (reg:V8HI 131 [ vect_var_.2540 ])
>
> but it changes that to:
>
> (reg:V16QI 160)
>
> for the VLSR instruction.  V16QImode is what VPERM expects, and I
> think since V8HI and V16QI mode are the same size everyone is happy.
>
> Is there a way to tell GCC what the type of the
> TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD should be?  Looking at
> http://gcc.gnu.org/onlinedocs/gcc-4.1.1/gccint/Addressing-Modes.
> html#Addressing-Modes
> it reads like it must merely match the last operand of the
> vec_realign_load_ pattern.
>
> --
> Why are ``tolerant'' people so intolerant of intolerant people?

Re: -ftree-vectorize can't vectorize plus?

[Dorit Nuzman]

"Devang Patel" <[EMAIL PROTECTED]> wrote on 11/09/2006 07:30:17 PM:

> > Can these type casts (from uchar to schar and back) be cleaned away
> > by some pass before vectorization, or do we need to teach the
vectorizer
> > to ignore such type casts?
>
> This was considered as tree-combiner's responsibility. However, I do not
> know what is the current state and plan of tree-combiner pass.
tree-combiner
> pass, along with other combining activites, will remove unnecessary
> cast (if possible).
>

so the stuff in tree-ssa-forwprop:eliminate_unnecessary_casts in
autovect-branch is supposed to go under this tree-combiner pass as well, or
do you plan to merge it to mainline some time?

I could add this pattern to the vectorizer's idiom-recognition pass - it's
like a tree-combiner I guess, except it's enabled from within the
vectorizer (and looks only for patterns that can help the vectorizer), and
doesn't change anything if the code doesn't end up getting vectorized. I
imagine this should be only a temporary solution, cause this cleanup is
potentially useful regardless of vectorization.

dorit

> -
> Devang

Re: Building gfortran with gcc-4.2-20060906 also freezes

[Vincent Lefevre]

On 2006-09-07 14:30:50 -0500, Chris Talley wrote:
> Thanks for the tip. I'll try to recompile GMP and MPFR. GMP and MPFR  
> are VERY difficult to compile correctly on a Darwin system. Any hints  
> on proper configure settings for GMP-4.2.1 / MPFR-2.2.0-patched on  
> Darwin?
> 
> On Sep 7, 2006, at 12:03 PM, Andrew Pinski wrote:
> >The freeze usually means the GMP you have installed is broken.

I don't know if you solved your problem, but the main problems with
GMP on Darwin are due to bugs in GCC (see the GMP bugs mailing-list).

-- 
Vincent Lefèvre <[EMAIL PROTECTED]> - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arenaire project (LIP, ENS-Lyon)

Re: Building gfortran with gcc-4.2-20060906 also freezes

[Jack Howarth]

   I don't recall the exact problem Chir was having but I would
mention that on fink for MacOS X 10.4, we package our gmp 4.2.1
using a build with the following patch...

http://swox.com/list-archives/gmp-discuss/2006-May/002333.html
http://swox.com/list-archives/gmp-discuss/2006-May/002344.html

Maybe that would help as well.
 Jack

Darwin doesn't install libgcjgc from boehm-gc

[Jack Howarth]

Has anyone noticed that on Darwin PPC we are building
the shared library libgcjgc.1.0.2.dylib in the boehm-gc
subdirectory but it never is installed? Isn't this a bug?
 Jack

objc linkage problems on Darwin PPC with -m64

[Jack Howarth]

 I finally got around to building and testing the objc 
support in gcc on Darwin PPC at -m64. The results aren't good
with 634 additional failures compared to the 10 at -m32. These
seem to be linkage issues of the form below as shown in...

http://gcc.gnu.org/ml/gcc-testresults/2006-09/msg00844.html


testcase 
/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/gcc/testsuite/objc/compile/compile.exp
 completed in 2
 seconds
Running 
/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/gcc/testsuite/objc/execute/exceptions/exceptions.exp
 .
..
set_ld_library_path_env_vars: 
ld_library_path=.::/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink
.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.
build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.b
uild/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.bu
ild/gcc4-4.1.-20060915/darwin_objdir/gcc
Executing on host: 
/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc4-4.1.-20
060915/darwin_objdir/gcc/ 
/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/gcc/testsuite/objc/execute/exception
s/catchall-1.m  -w  -O0  -fobjc-exceptions  -lobjc -lm   -m64 -o 
/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/
gcc/testsuite/objc/catchall-1.x0(timeout = 300)
ld64 warning: in /usr/lib/libobjc.dylib, file is not of required architecture
Undefined symbols:
  _objc_exception_throw, referenced from:
  _test in ccVj9eiG.o
  _test in ccVj9eiG.o
  _objc_exception_try_exit, referenced from:
  _test in ccVj9eiG.o
  _objc_exception_extract, referenced from:
  _test in ccVj9eiG.o
  _test in ccVj9eiG.o
  .objc_class_name_Object, referenced from:
  [EMAIL PROTECTED]@[EMAIL PROTECTED] in ccVj9eiG.o
  .objc_class_name_Frob in ccVj9eiG.o
  _objc_exception_try_enter, referenced from:
  _test in ccVj9eiG.o
  _test in ccVj9eiG.o
  _objc_msgSend, referenced from:
  _test in ccVj9eiG.o
  _objc_exception_match, referenced from:
  _test in ccVj9eiG.o
ld64-59.2 failed: symbol(s) not found
collect2: ld returned 1 exit status
compiler exited with status 1
output is:
ld64 warning: in /usr/lib/libobjc.dylib, file is not of required architecture
Undefined symbols:
  _objc_exception_throw, referenced from:
  _test in ccVj9eiG.o
  _test in ccVj9eiG.o
  _objc_exception_try_exit, referenced from:
  _test in ccVj9eiG.o
  _objc_exception_extract, referenced from:
  _test in ccVj9eiG.o
  _test in ccVj9eiG.o
  .objc_class_name_Object, referenced from:
  [EMAIL PROTECTED]@[EMAIL PROTECTED] in ccVj9eiG.o
  .objc_class_name_Frob in ccVj9eiG.o
  _objc_exception_try_enter, referenced from:
  _test in ccVj9eiG.o
  _test in ccVj9eiG.o
  _objc_msgSend, referenced from:
  _test in ccVj9eiG.o
  _objc_exception_match, referenced from:
  _test in ccVj9eiG.o
ld64-59.2 failed: symbol(s) not found
collect2: ld returned 1 exit status
FAIL: objc/execute/exceptions/catchall-1.m compilation,  -O0 
UNRESOLVED: objc/execute/exceptions/catchall-1.m execution,  -O0 

I should mention that I don't have this build of gcc trunk
installed so it is being tested out of the build directory.
However, it should be smart enough to at least look in a
ppc64 subdirectory for the required libobjc.dylib, no?
  Jack
ps I'll file a PR on this shortly. I imagine this is all a
Makefile issue so we really should try to fix it for gcc 4.2.

RE: objc linkage problems on Darwin PPC with -m64

[Jack Howarth]

Another observation regarding the previous failure I
reported in the objc testsuite. If I manually execute...

/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/ 
/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/gcc/testsuite/objc/execute/exceptions/catchall-1.m
 -w -O0 -fobjc-exceptions 
/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/powerpc-apple-darwin8/ppc64/libobjc/.libs/libobjc-gnu.2.0.0.dylib
 -lm -m64 -o catchall-1.x0
Undefined symbols:
  _objc_exception_try_exit, referenced from:
  _test in ccxxZxk2.o
  _objc_exception_extract, referenced from:
  _test in ccxxZxk2.o
  _test in ccxxZxk2.o
  .objc_class_name_Object, referenced from:
  [EMAIL PROTECTED]@[EMAIL PROTECTED] in ccxxZxk2.o
  .objc_class_name_Frob in ccxxZxk2.o
  _objc_exception_try_enter, referenced from:
  _test in ccxxZxk2.o
  _test in ccxxZxk2.o
  _objc_msgSend, referenced from:
  _test in ccxxZxk2.o
  _objc_exception_match, referenced from:
  _test in ccxxZxk2.o
ld64-59.2 failed: symbol(s) not found
collect2: ld returned 1 exit status

I get that error instead. So while we still end up with a linker error, we at
least end up linking against the libobjc we actually built (which has a 
different
base name). 
I do notice that the correct path is provided for linking in -lobjc at -m32,
HOWEVER the ***WRONG basename is used. So I think we are currently testing
all of the objc testsuite against the Apple supplied libobjc and NOT the proper
libobjc-gnu one built.

testcase 
/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/gcc/testsuite/objc/compile/compile.exp
 completed in 8
 seconds
Running 
/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/gcc/testsuite/objc/execute/exceptions/exceptions.exp
 .
..
set_ld_library_path_env_vars: 
ld_library_path=.::/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink
.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/powerpc-apple-dar
win8/./libobjc/.libs
Executing on host: 
/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/xgcc 
-B/sw/src/fink.build/gcc4-4.1.-20
060915/darwin_objdir/gcc/ 
/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/gcc/testsuite/objc/execute/exception
s/catchall-1.m  -w  -O0  -fgnu-runtime -fobjc-exceptions 
-I/sw/src/fink.build/gcc4-4.1.-20060915/gcc-4.2-20060915/gcc
/testsuite/../../libobjc 
-L/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/powerpc-apple-darwin8/./libobjc/.libs
 
 -lobjc -lm   -m32 -o 
/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc/testsuite/objc/catchall-1.x0
(timeou
t = 300)
PASS: objc/execute/exceptions/catchall-1.m compilation,  -O0  -fgnu-runtime
Setting LD_LIBRARY_PATH to 
.::/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.build/gcc4-4.1.999
9-20060915/darwin_objdir/gcc:/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/powerpc-apple-darwin8/./libobjc/.lib
s:.::/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/gcc:/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/
gcc:/sw/src/fink.build/gcc4-4.1.-20060915/darwin_objdir/powerpc-apple-darwin8/./libobjc/.libs
receivePort = 0x0
sendPort = 0x
cleanupPorts = 1
---
receivePort = 0x
sendPort = 0x
cleanupPorts = 1
---
receivePort = 0x0
sendPort = 0x0
cleanupPorts = 0
---
Exception caught by correct handler.
receivePort = 0x0 (expected 0x0)
sendPort = 0x0 (expected 0x0)
cleanupPorts = 0 (expected 0)
---PASS: objc/execute/exceptions/catchall-1.m execution,  -O0  -fgnu-runtime

I'll file a PR now for both problems.
  Jack

Re: Type yielded by TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD hook?

[Dorit Nuzman]

"Erich Plondke" <[EMAIL PROTECTED]> wrote on 16/09/2006 05:26:50 PM:

> On 9/16/06, Dorit Nuzman <[EMAIL PROTECTED]> wrote:
> > Looks like it's a bug in the vectorizer - we treat both the return
value of
> > the mask_for_load builtin, and the 3rd argument to the realign_load
stmt
> > (e.g. Altivec's vperm), as variables of type 'vectype', instead of
> > obtaining the type from the target machine description. All we need to
care
> > about is that these two variables have the same type. I'll look into
that
>
> When I undefined mask_for_load, I got a pointer type as my 3rd
> argument in the realign_load statement... so I made the expander there
> generate the extra code sequence for setting up the shift value.
>

right - if a target doesn't define a mask_for_load, the default is to pass
realign_load a pointer to the location accessed in each iteration.

> Actually, I wonder why this wasn't done for altivec... couldn't you
> make the realign_load expander generate the lvsr?  Or does the
> mask_for_load help it to be eliminated when the offset is
> loop-invariant (which would help here also)?

exactly - the mask_for_load stuff is loop invariant and takes place before
the loop (as opposed to the default solution when mask_for_load is not
defined).

dorit

> Or is it just that it
> takes a whole addressing mode instead of a single address?

BFD Error a regression?

[Jerry DeLisle]

With latest svn trunk and Bud's splay patch.  I don't think this is related to 
Bud's patch because regression testing and NIST testing passed fine.


While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the following 
error message:


I am not sure I can reduce the case. But I can try if this is something new.

Look familiar?

Regards,

Jerry

BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at ../../bfd/elfcode.h 
line 190 in bfd_elf32_swap_symbol_in


BFD: Please report this bug.

make[1]: *** [complex16] Error 1
make[1]: *** Waiting for unfinished jobs
BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at ../../bfd/elfcode.h 
line 190 in bfd_elf32_swap_symbol_in


BFD: Please report this bug.

make[1]: *** [double] Error 1
make[1]: Leaving directory `/home/jerry/fortran/lapack/SRC'
make: *** [lapacklib] Error 2

Why test objc at -m64 for Darwin8?

[Jack Howarth]

   Shouldn't we have something in gcc/testsuite/lib/objc*.exp
to short-circuit out of running any of those -m64 testsuites
for Darwin8 and earlier? If we won't have 64-bit objc runtimes
in Darwin until Leopard, it seems rather pointless to test
-m64 for objc at all, no? Also, I am baffled as to how
much of it actually passes considering there isn't even
the correct architecture of runtime.
 Jack

Re: BFD Error a regression?

[Nick Clifton]

Hi Jerry,

While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the 
following error message:


BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at 
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in


If you are able to reproduce this bug, then please try using the latest 
version of the binutils from the mainline of the CVS repository.  If the 
bug still exists there please submit a binutils bug report (at: 
http://sourceware.org/bugzilla/) and we will be happy to investigate. 
(If you can include a simple test case that reproduces the problem, 
preferably without needing to build a special compiler, that will help 
immensely).


Cheers
  Nick

gcc-4.2-20060916 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 116995

You'll find:

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

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

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

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

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

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

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

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

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

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

Re: BFD Error a regression?

[Tim Prince]

Jerry DeLisle wrote:



BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at 
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in


BFD: Please report this bug.

make[1]: *** [complex16] Error 1
make[1]: *** Waiting for unfinished jobs
BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at 
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in


BFD: Please report this bug.



BFD is acknowledging that it may be buggy.  Does this occur with current 
binutils, e.g. from ftp.kernel.org?  Are you able to build g++ and 
libstdc++ without hitting this or similar bug?  Buggy binutils is a 
chronic problem with RHEL, and is generally not fixed without 6 months 
effort by an OEM with more influence than my employer.  If you hit it 
with a small test case, surely it will be hit with real applications 
sooner or later.

Re: Merging identical functions in GCC

[Ross Ridge]

Ross Ridge writes:
>No, and I can't see how how you've came up with such an abusurd
>misintepretation of what I said.  As I said clearly and explicity,
>the example I gave was where you'd want to use function merging.

Daniel Berlin writes:
>Whatever.  Why would you turn on function merging if you are trying to
>specifically get the compiler to produce different code for your
>functions than it did before?

Because I as already said, you want to merge the funtions that happen
to be same.  You don't want to merge the ones that aren't the same.
Sometimes using different compiler options (eg. for CPU architecture)
generates different code, sometimes it doesn't.  If you could always
predict what the exact code the compiler was going generate you'd might
as well write your code in assembly.

>As an FYI, you already have this situation with linkonce functions.

No, linkonce functions get merged because they have same name.

>>I think this is best done by linker which
>>can much more reliably compare the contents of functions to see if they
>>are the same.
>
>No it can't. It has no idea what a function consists of other than a
>bunch of bytes, in pretty much all cases.  ... Stupid byte
>comparisons of functions generally won't save you anything truly
>interesting.

Microsoft's implementation has proven that "stupid" byte comparions can
generate significant savings. 

Ross Ridge

Re: BFD Error a regression?

[Jerry DeLisle]

Nick Clifton wrote:

Hi Jerry,

While compiling LAPACK with -O3 -funroll-loops -march=nocona I got the 
following error message:


BFD: BFD 2.16.91.0.6 20060212 internal error, aborting at 
../../bfd/elfcode.h line 190 in bfd_elf32_swap_symbol_in


If you are able to reproduce this bug, then please try using the latest 
version of the binutils from the mainline of the CVS repository.  If the 
bug still exists there please submit a binutils bug report (at: 
http://sourceware.org/bugzilla/) and we will be happy to investigate. 
(If you can include a simple test case that reproduces the problem, 
preferably without needing to build a special compiler, that will help 
immensely).


Cheers
  Nick

I observed that ar and ranlib are invoked by make to build the LAPACK libraries. 
 I was using make -j3 to do this.  When I do not use the -j option the build 
proceeds normally, so I am OK here.


There are several hundred object files being pulled together here.  I don't 
think I can reproduce the problem with a smaller set.  I will just avoid the option.


Thanks,

Jerry

Re: Merging identical functions in GCC

[Gabriel Dos Reis]

Ross Ridge <[EMAIL PROTECTED]> writes:

[...]

| >>I think this is best done by linker which
| >>can much more reliably compare the contents of functions to see if they
| >>are the same.
| >
| >No it can't. It has no idea what a function consists of other than a
| >bunch of bytes, in pretty much all cases.  ... Stupid byte
| >comparisons of functions generally won't save you anything truly
| >interesting.
| 
| Microsoft's implementation has proven that "stupid" byte comparions can
| generate significant savings. 

Not very logn ago I spoke with the VC++ manager about this, and he
said that their implementation currently is not conforming -- but
they are working on it.  The issue has to with f and f
required to have difference addresses -- which is violated by their
implementation. 

-- Gaby

Re: BFD Error a regression?

[Andrew Pinski]

On Sat, 2006-09-16 at 10:57 -0700, Tim Prince wrote:
> BFD is acknowledging that it may be buggy.  Does this occur with current 
> binutils, e.g. from ftp.kernel.org?  

Don't even dare use those binutils.  Those are not the official binutils
at all.  Those are HJL's crazy patched binutils which most of the time
don't work anyways.  I really Hate how people tell others to use them.
Anyways the current released binutils version is 2.17 which can be
grabbed from http://www.sourceware.org/binutils/.

Thanks,
Andrew Pinski

Re: Merging identical functions in GCC

[Ross Ridge]

Gabriel Dos Reis write:
>Not very logn ago I spoke with the VC++ manager about this, and he
>said that their implementation currently is not conforming -- but
>they are working on it.  The issue has to with f and f
>required to have difference addresses -- which is violated by their
>implementation. 

Yes, this issue has already been mentioned in this thread and is a problem
regardless of how you compare functions to find out if they are the same.
The compiler also needs to be able to detect when its safe to merge
functions that are identical.

Ross Ridge

Re: Merging identical functions in GCC

[Daniel Berlin]

>No it can't. It has no idea what a function consists of other than a
>bunch of bytes, in pretty much all cases.  ... Stupid byte
>comparisons of functions generally won't save you anything truly
>interesting.

Microsoft's implementation has proven that "stupid" byte comparions can
generate significant savings.


No they haven't.
But have fun implementing it in your linker, and still making it safe
if that's what you really want.
I'm not going to do that, and I don't believe it is a good idea.

Re: Merging identical functions in GCC

[Ross Ridge]

Ross Ridge writes:
>Microsoft's implementation has proven that "stupid" byte comparions can
>generate significant savings.

Daniel Berlin wrtes:
>No they haven't.

So Microsoft and everyone who says they've got significant savings using
it is lying?

>But have fun implementing it in your linker, and still making it safe
>if that's what you really want.
>I'm not going to do that, and I don't believe it is a good idea.

I'm not asking you to do anything.  I'm just telling you that I don't
think your idea is any good. 

Ross Ridge

Re: Merging identical functions in GCC

[Gabriel Dos Reis]

"Daniel Berlin" <[EMAIL PROTECTED]> writes:

| > >No it can't. It has no idea what a function consists of other than a
| > >bunch of bytes, in pretty much all cases.  ... Stupid byte
| > >comparisons of functions generally won't save you anything truly
| > >interesting.
| >
| > Microsoft's implementation has proven that "stupid" byte comparions can
| > generate significant savings.
| >
| No they haven't.
| But have fun implementing it in your linker, and still making it safe
| if that's what you really want.
| I'm not going to do that, and I don't believe it is a good idea.

Agreed.

-- Gaby

Re: Merging identical functions in GCC

[Daniel Berlin]

On 9/16/06, Ross Ridge <[EMAIL PROTECTED]> wrote:

Ross Ridge writes:
>Microsoft's implementation has proven that "stupid" byte comparions can
>generate significant savings.

Daniel Berlin wrtes:
>No they haven't.

So Microsoft and everyone who says they've got significant savings using
it is lying?

Over what?

Do you really want me to sit here and knock down every single one of
your arguments?

Let's take your misunderstanding of my point about linkonce functions:
You posited a scenario where you want to optimize a function multiple
times using a different compiler flags and cpu architectures, and say
that they may produce the same rtl but different assembly.
Even though this argument is moot in the face of hashing compiler
options as well, you run into the exact same problem with linkonce
functions.  Your functions you are trying to optimize for multiple cpu
types and compiled with different flags may be output as linkonce
functions.  The linker is simply going to pick one, regardless of what
CPU architecture or assembly it generated, the same way hashing RTL
*without* including compiler options would.  This is the point. You've
*already* got this problem you claim would occur in my scheme.  Does
this also make linkonce functions an idea that is not "any good"?

You also say "

Microsoft's implementation has proven that "stupid" byte comparions can
generate significant savings."


The fact is that Microsoft's implementation rarely generates
significant savings over that given by linkonce functions,  and when
it does, it will in no way compare to anything that does *more* than
stupid byte comparisons will give you.


>But have fun implementing it in your linker, and still making it safe
>if that's what you really want.
>I'm not going to do that, and I don't believe it is a good idea.

I'm not asking you to do anything.  I'm just telling you that I don't
think your idea is any good.

That's nice.  It's the only way to do it sanely and correctly in all
cases, without having to teach the linker how to look at code, or to
control the linker (which we don't on some platforms), and output a
side channel explaining what it is allowed to eliminate, at which
point, you might as well do it in the compiler!

You can believe what you like about the idea.  Until you are willing
to implement something *you* believe will help, or at the least
explain how you forsee it being done safely (which Microsoft
doesn't!), it's very hard to take you seriously.


--Dan

Missing elements in VECTOR_CST

[Andrew Pinski]

The documention on VECTOR_CST is not clear if we can have missing
elements in that the remaining elements are zero.  Right we produce such
VECTOR_CST for things like:
#define vector __attribute__((vector_size(16) ))
vector int a = {1, 2};

But is that valid?  We currently produce a VECTOR_CST with just two
elements instead of 4.  Should we always have the same number of
elements in a VECTOR_CST as there are elements in the vector type?

This is why PR 29091 is failing currently.  output_constant assumes
VECTOR_CST have the correct number of elements but the C front-end via
digest_init creates a VECTOR_CST with only 2 elements.

Thanks,
Andrew Pinski

Re: Merging identical functions in GCC

[Ross Ridge]

Daniel Berlin writes
>Do you really want me to sit here and knock down every single one of
>your arguments?

Why would you think I would've wanted your "No, it isn't" responses
instead?

>Your functions you are trying to optimize for multiple cpu
>types and compiled with different flags may be output as linkonce
>functions.  The linker is simply going to pick one, regardless of what
>CPU architecture or assembly it generated...

No, in the example I gave, the functions have different names.

>The fact is that Microsoft's implementation rarely generates
>significant savings over that given by linkonce functions, and when
>it does, it will in no way compare to anything that does *more* than
>stupid byte comparisons will give you.

No, "linkonce" function discarding is always done by the Microsoft
toolchain and can't be disabled.  The reported savings are the result of
comparing the results of enabling and disabling identical COMDAT folding.
I don't see how your "intelligent" hashing can do significantly better
except by merging functions that aren't really identical. 

>That's nice.  It's the only way to do it sanely and correctly in all
>cases, without having to teach the linker how to look at code, or to
>control the linker (which we don't on some platforms), and output a
>side channel explaining what it is allowed to eliminate, at which
>point, you might as well do it in the compiler!

How does hashing the RTL and using that as the COMDAT label solve this
problem?  You're telling the linker you know it's safe to merge when you
don't know if the function's address is compared in another compilation
unit or not.

>You can believe what you like about the idea.  Until you are willing
>to implement something *you* believe will help, or at the least
>explain how you forsee it being done safely (which Microsoft
>doesn't!), it's very hard to take you seriously

As I've already said, it can be made safe by communicating to the linker
which functions have had their address taken.  Yes, this requires special
support from the linker, but then so has linkonce on some platforms.
If that special support isn't available you're still left with an unsafe
but very useful optimization for applications that don't compare function
pointers.

Ross Ridge

Removing the use of CONSTRUCTOR for Vectors

[Andrew Pinski]

I just got crazy idea, since we really don't like CONSTRUCTOR that much
and we already know the lengths of Vectors, we can have a VECTOR_EXPR
which we could then use instead of CONSTRUCTORs.

This would also save some memory as then we don't need a real
VEC(constructor_elt) but more like what TREE_VEC is.

So we have:
struct tree_vector GTY(())
{
  struct tree_common common;
  tree ((length ("TYPE_VECTOR_SUBPARTS (TREE_TYPE ((tree)&%h))")))
elements[1];
};

This will be the structure for both VECTOR_CST and VECTOR_EXPR.

What do people think about this idea?

Thanks,
Andrew Pinski