Re: gcc will become the best optimizing x86 compiler

[Agner Fog]

Dennis Clarke wrote:
>The Sun Studio 12 compiler with Solaris 10 on AMD Opteron or
>UltraSparc beats GCC in almost every single test case that I have
>seen.

This is memcpy on Solaris:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/i386/gen/memcpy.s

It uses exactly the same method as memcpy on gcc libc, with only minor 
differences that have no influence on performance.


Also, you have provided no data at all.  


I have linked to the data rather than copying it here to save space on 
the mailing list. Here is the link again:

http://www.agner.org/optimize/optimizing_cpp.pdf  section 2.6, page 12.


So your assertions are those of a marketing person at the moment.


Who sounds like a marketing person, you or me? :-)

> Please post some code that can be compiled and then tested with high 
resolution timers and perhaps

> we can compare notes.

Here is my code, again:
http://www.agner.org/optimize/asmlib.zip
My test results, referred to above, uses the "core clock cycles" 
performance counter on Intel and RDTSC on AMD. It's the highest 
resolution you can get. Feel free to do you own tests, it's as simple as 
linking my library into your test program.


Tim Prince wrote:
>you identify the library you tested only as "ubuntu g++ 4.2.3."
Where can I see the libc version?

>The corresponding 64-bit linux will see vastly different levels of 
performance, depending on the

>glibc version, as it doesn't use a builtin string move.
Yes, this is exactly what my tests show. 64-bit libc is better than 
32-bit libc, but still 3-4 times slower than the best library for 
unaligned operands on an Intel.


>Certain newer CPUs aim to improve performance of the 32-bit gcc 
builtin string moves, but don't

> entirely eliminate the situations where it isn't optimum.

The Intel manuals are not clear about this. Intel Optimization reference 
manual says:
>In most cases, applications should take advantage of the default 
memory routines provided by Intel compilers.
What an excellent advice - the Intel compiler puts in a library with an 
automatic run-slowly-on-AMD feature!

The Intel library does not use rep movs when running on an Intel CPU.

The AMD software optimization guide mentions specific situations where 
rep movs is optimal. However, my tests on an Opteron (K8) tell that rep 
movs is never optimal on AMD either. I have no access to test it on the 
new AMD K10, but I expect the XMM register code to run much faster on 
K10 than on K8 because K10 has 128-bit data paths where K8 has only 64-bit.


Evidently, the problem with memcpy has been ignored for years, see 
http://softwarecommunity.intel.com/Wiki/Linux/719.htm

gcj/sparc64?

[Jay]

This is an incomplete bug report.

 unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: 


  -bash-3.00$ gcc -v  
  Using built-in specs.  
  Target: sparc-sun-solaris2.10  
  Configured with: /home/jay/src/gcc/configure  
  Thread model: posix  
  gcc version 4.3.1 (GCC)  


  ~/src/gcc/configure sparc64-sun-solaris2.10 -disable-multilib 
-disable-bootstrap  \
   -disable-nls sparc64-sun-solaris2.10 CFLAGS=-m64 MAKEINFO=echo && make \
   MAKEINFO=echo CFLAGS=-m64  


  libtool: compile:  /home/jay/obj/gcc.1/gcc/gcj 
-B/home/jay/obj/gcc.1/sparc64-sun  
  -solaris2.10/libjava/ -B/home/jay/obj/gcc.1/gcc/ -Usun -fclasspath= 
-fbootclassp  
  ath=/home/jay/src/gcc/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated 
-fb  
  ootstrap-classes -g -O2 -c 
-fsource-filename=/home/jay/obj/gcc.1/sparc64-sun-sol  
  aris2.10/libjava/classpath/lib/classes -MT 
gnu/javax/swing/text/html/parser/HTML  
  _401F.lo -MD -MP -MF gnu/javax/swing/text/html/parser/HTML_401F.deps 
@gnu/javax/  
  swing/text/html/parser/HTML_401F.list  -fPIC -o 
gnu/javax/swing/text/html/parser  
  /.libs/HTML_401F.o  
  gcj: Internal error: Segmentation Fault (program jc1)  
  Please submit a full bug report.  
  See  for instructions.  
  make[3]: *** [gnu/javax/swing/text/html/parser/HTML_401F.lo] Error 1  
  make[3]: Leaving directory 
`/home/jay/obj/gcc.1/sparc64-sun-solaris2.10/libjava'  


  make[2]: *** [all-recursive] Error 1  
  make[2]: Leaving directory 
`/home/jay/obj/gcc.1/sparc64-sun-solaris2.10/libjava'  


  make[1]: *** [all-target-libjava] Error 2  
  make[1]: Leaving directory `/home/jay/obj/gcc.1'  
  make: *** [all] Error 2  


  -bash-3.00$ uname -a  
  SunOS unknown 5.10 Generic_118833-17 sun4u sparc SUNW,Sun-Blade-100  



 The build gcc -v itself was built with the output of "half Canadian" cross 
from 
 Cygwin. ie: target==host (==sparc-sun-solaris2.10), but target!=build 
(i686-pc-cygwin). 
 That should be all I need, but is having some problems, so I figured I'd just 
it to build native. 
 (I also had to rename away the output of fixincl, as they used the undefined 
macro _PARAMS.) 


 I'll try again with just -enable-languages=c,c++,fortran,objc.


 Perhaps I should suck it up, ignore the "biarch-ness" and:  


  ~/src/gcc/configure \
  -host=sparc64-sun-solaris2.10 \
  -target=sparc64-sun-solaris2.10 \
  -enable-languages=c,c++,fortran,objc \
  -disable-nls \
  -disable-multilib \
  MAKEINFO=echo && make MAKEINFO=echo 


  but that fails:  
checking whether byte ordering is bigendian... unknown  
configure: error: unknown endianness  
presetting ac_cv_c_bigendian=no (or yes) will help  
make[1]: *** [configure-libiberty] Error 1  
make[1]: Leaving directory `/home/jay/obj/gcc.1'  
make: *** [all] Error 2


I shouldn't need this MAKEINFO=echo, but I do for some reason.
btw, it'd be cool if one could easily add languages later, remove 
-disable-multilib later, etc.
  ie: "reconfigure slightly differently/larger && make" and have it be super 
duper smart about what to rebuild 
And -disable-libiconv would be nice.


 - Jay

Re: gcc will become the best optimizing x86 compiler

[Zoltán Kócsi]

> [...]
> I have made a few optimized functions myself and published them as a 
> multi-platform library (www.agner.org/optimize/asmlib.zip). It is
> faster than most other libraries on an Intel Core2 and up to ten
> times faster than gcc using builtin functions. My library is
> published with GPL license, but I will allow you to use my code in
> gnu libc if you wish (Sorry, I don't have the time to work on the gnu
> project myself, but you may contact me for details about the code).
> [...]

But then it's not gcc that is the best optimising compiler, but it's 
the best library *hand optimised so that gcc compiles it very well*.

Here's an example:

void foo( void )
{
unsigned x;

for ( x = 0 ; x < 200 ; x++ ) func();
}

void bar( void )
{
unsigned x;

for ( x = 201 ; --x ; ) func();
}

foo() and bar() are completely equivalent, they call func() 200
times and that's all. Yet, if you compile them with -O3 for arm-elf
target with version 4.0.2 (yes, I know, it's an ancient version, but
still) bar() will be 6 insns long with the loop itself being 3 while
foo() compiles to 7 insns of which 4 is the loop. In fact, the compiler
is clever enough to transform bar()'s loop from

for ( x = 201 ; --x ; ) func();
to
x = 200; do func() while ( --x );

internally, the latter form being shorter to evaluate and since x is
not used other than as the loop counter it doesn't matter. However, it
is not clever enough to figure out that foo()'s loop is doing exactly
what bar()'s is doing. Since x is only the loop counter, gcc could
transform foo()'s loop to bar()'s freely but it doesn't. It generates
the equivalent of this:

x = 0; do { x += 1; func(); } while ( x != 240 );

that is not as efficient as what it generates from bar()'s code.

Of course you get surprised when you change -O3 to -Os, in which case
gcc suddenly realises that foo() can indeed be transformed to the
internal representation that it used for bar() with -O3. Thus, we have
foo() now being only 6 insns long with a 3 insn loop. Unfortunately,
bar() is not that lucky. Although it's loop remains 3 insns long, the
entire function is increased by an additional instruction, for bar()
internally now looks like this:

   x = 201;
   goto label;
   do {
  func();
label:
   } while ( --x );

You can play with gcc and see which one of the equivalent C
constructs it compiles to better code with any particular -O level
(and if you have to work  with severely constrained embedded systems
you often do) but then hand-crafting your C code to fit gcc's taste is
actually not that good an idea. With the next release, when different
constructs will be recognised, you may end up with larger and/or slower
code (as it happened to me when changing 4.0.x -> 4.3.x and before when
going from 2.9.x to 3.1.x).

Gcc will be the best optimising compiler when it will generate
faster/shorter code that the other compilers on the majority of
a large set of arbitrary, *not* hand-optimised sources. Preferrably 
for most targets, not only for the x86, if possible :-)

Zoltan

RE: gcc will become the best optimizing x86 compiler

[Dave Korn]

Agner Fog wrote on 24 July 2008 09:04:

> Tim Prince wrote:
>  >you identify the library you tested only as "ubuntu g++ 4.2.3."
> Where can I see the libc version?

  Use whichever package manager ubuntu provides to check the version of the
glibc package.  Here's an example fron a centos (using rpm):

[EMAIL PROTECTED] ~]$ rpm -q glibc
glibc-2.3.4-2.36
glibc-2.3.4-2.36
[EMAIL PROTECTED] ~]$ 


cheers,
  DaveK
-- 
Can't think of a witty .sigline today

fixincludes takes wrong files? (possible sysroot/build-sysroot confusion?)

[Jay]

 starting from build i686-pc-cygwin 
  build native 
  build host i686-pc-cygwin target sparc-sun-solaris2.10 -with-sysroot 
  and then host sparc-sun-solaris2.10 target sparc-sun-solaris2.10 
   installing with destdir = /usr/local/sparc-sun-solaris2.10/install 

 fixincludes took 

  d:\cygwin\usr\include\math.h 

 instead of:  

 D:\cygwin\usr\local\sparc-sun-solaris2.10\sys-root\usr\include\math.h 

 and produced: 

 
D:\cygwin\usr\local\sparc-sun-solaris2.10\install\usr\local\lib\gcc\sparc-sun-solaris2.10\4.3.1\include-fixed\math.h
  

which didn't work, of course (for a simple reason -- _PARAMS via _ansi.h vs. 
__P locally)

Perhaps the third toolset should be built -with-sysroot=/ 
-with-build-sysroot=/usr/local/sparc-sun-solaris2.10/sys-root? 

Anyway, I renamed the include-fixed away and am rebuilding native.
I'll have to dig around and plan to start over "from scratch" anyway and see.
I realize these incorrect headers, or what all they are a sign of, *might* have 
"infected" the tools.

The -sysroot stuff is still confusing me some.
The other day I found it useful to symlink /usr/local//sys-root to / in order 
to "fake something out".
The -build-sysroot doc says it is only useful with -sysroot, but it seems to me 
that may be false.

I wish sysroot could be validated early, in configure, and user new to 
cross/etc. builds given a little more hand holding, oh well.

 - Jay

Status of the tuples branch - request for primary/secondary taget maintainers help

[Richard Guenther]

The tuples branch is ready for merging to trunk if we can address a
few remaining issues.  The branch currently bootstraps and tests
on i586-linux, x86_64-linux, ppc-linux, ppc64-linux, ia64-linux
and s390x-linux.  It fails to bootstrap on s390-linux (it fails
during stage3 gcc configure, appearantly all function arguments
get passed in %r2 instead of %r2 and %r3 for a call to fopen.  Andreas,
can you have a look here?). I'll be posting testresults of these
targets shortly.

I would ask the maintainers of the non-covered primary and
secondary targets to have a look at the status of their target
on the branch as we do not have access to all kind of hardware
to cover these targets.

Thanks,
Richard.

Re: gcc will become the best optimizing x86 compiler

[Basile STARYNKEVITCH]

Dave Korn wrote:

Agner Fog wrote on 24 July 2008 09:04:


Tim Prince wrote:
 >you identify the library you tested only as "ubuntu g++ 4.2.3."
Where can I see the libc version?


  Use whichever package manager ubuntu provides to check the version of the
glibc package.  Here's an example fron a centos (using rpm):



On most Linux systems, in addition of using the package manager, the 
libc.so file is executable, and when executed, shows info, so on my 
Debian/Sid/AMD64 I'm getting


 % /lib/libc.so.6
GNU C Library stable release version 2.7, by Roland McGrath et al.
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 4.3.1 20080523 (prerelease).
Compiled on a Linux >>2.6.25-2-amd64<< system on 2008-06-02.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
For bug reporting instructions, please see:
.


Of course, on Ubuntu & Debian, you can query the package system
% dpkg -l libc6
Desired=Unknown/Install/Remove/Purge/Hold
| 
Status=Not/Inst/Cfg-files/Unpacked/Failed-cfg/Half-inst/trig-aWait/Trig-pend
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err: 
uppercase=bad)

||/ Name   VersionDescription
+++-==-==-
ii  libc6  2.7-12 GNU C Library: Shared libraries

Regarding the original thread (performance of GCC & standard functions) 
it should be stressed that gcc would probably compile them better if 
passed machine specific flags.


At last, at the recent (july 2008) GCC summit, someone (sorry I forgot 
who, probably someone from SuSE) proposed in a BOFS to have architecture 
and machine specific hand-tuned (or even hand-written assembly) low 
level libraries for such basic things as memset etc..


Thanks for reading
--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

RE: gcc will become the best optimizing x86 compiler

[Dave Korn]

Basile STARYNKEVITCH wrote on 24 July 2008 11:28:

> On most Linux systems, in addition of using the package manager, the
> libc.so file is executable, and when executed, shows info, so on my
> Debian/Sid/AMD64 I'm getting
> 
>   % /lib/libc.so.6
> GNU C Library stable release version 2.7, by Roland McGrath et al. 
[snip!]

  oooh, nice - that's loads more informative than "This program cannot be
run in DOS mode"  ;-)

  Thanks for the tip!

cheers,
  DaveK
-- 
Can't think of a witty .sigline today

endian problems using the pack(1) pragma for data structure by the powerpc compiler

[Thomas Korn]

Hello all,

I have endian problems using the reference operator (&),
the deference  operator (*) or the element deference  operator (->)
together witch data structs which are compiled using pack(1).
The problems appear onlx if these data structs are located within
the litlle endian part of the memory RAM.

These are the failure patterns using the various referencing mechanisms 
(& or * or ->) for float values:


write1:  testLE1 = (testT1*)LITTLE_ENDIAN_ADDRESS;
   testLE1->floatvalue = 50.0;

read_1a:   var = testLE1->floatvalue   ok
read_1b:   f = &testLE1->floatvalue;
   var = *f;failure

write2:  testLE1 = (testT1*)LITTLE_ENDIAN_ADDRESS;
   f = &testLE1->floatvalue;
   *f = 50.0;

read_2a:   var = testLE1->floatvalue   failure
read_2b:   f = &testLE1->floatvalue;
   var = *f;ok


Used hardware (target):
Taishan board with PowerPC 440gx processor (big endian)

Development environment:
DENX Linux version 2.6.25.4
DENX ELDK version 4.1 build 2007-01-19
gcc release 4.0.0

Due to historical reasons the Linux kernel is configured so that a
small part of the memory can be used as an automated converter between 
little endian <-> big endian.
It is possible to write to a little endian address and read from the big 
endian address and vice versa.


I tried several possible invocations of the compiler, all show the same 
result :


 gcc -mcpu=440 -mno-strict-align -pedantic -Wall -O0 -o 
endian_float_pack1a endian_float_pack1a.c
 gcc -mcpu=405 -mno-strict-align -pedantic -Wall -O0 -o 
endian_float_pack1a endian_float_pack1a.c
 gcc -mcpu=405 -mno-strict-align-Wall -O0 -o 
endian_float_pack1a endian_float_pack1a.c
 gcc -mcpu=405  -Wall -O0 
-o endian_float_pack1a endian_float_pack1a.c



My additional comment for the following code sample :



All accesses within the big endian part work well, regardsless of using 
pack(1) or pack(4).
Writing and reading of data structure elements with pack(4) within the 
little endian part is also ok -

but my program needs pack(1).


This is my code sample using pack(1) :

#include 
#include 
#include 


#define BIG_ENDIAN_ADDRESS  0xB000
#define LITTLE_ENDIAN_ADDRESS   0xB020
#define ENDIAN_SIZE 0x10

//#pragma pack(4)
#pragma pack(1)
typedef struct test1
{
 char  mist;
 int   intvalue;
 float floatvalue;
} testT1;
#pragma pack(0)

int main(int argc, char *argv[])
{
 testT1 *testLE1;
 float  *f, float1, float2;
 char   *ch;

 testLE1 = (testT1*)LITTLE_ENDIAN_ADDRESS;
 testLE1->floatvalue = 50.0;

 ch = (char*)&testLE1->floatvalue;
 f = &testLE1->floatvalue;
 printf("(1) %9f %9f [%02x,%02x,%02x,%02x] ", testLE1->floatvalue, *f, 
ch[0], ch[1], ch[2], ch[3]);

 float1 = testLE1->floatvalue;
 ch = (char*)&float1;
 printf("%9f [%02x,%02x,%02x,%02x] ", float1, ch[0], ch[1], ch[2], ch[3]);
 float2 = *f;
 ch = (char*)&float2;
 printf("%9f [%02x,%02x,%02x,%02x] ", float2, ch[0], ch[1], ch[2], ch[3]);
 printf("%9f\n", *(&testLE1->floatvalue));

 testLE1 = (testT1*)LITTLE_ENDIAN_ADDRESS;
 f = &testLE1->floatvalue;
 *f = 50.0;
 ch = (char*)&testLE1->floatvalue;
 f = &testLE1->floatvalue;
 printf("(2) %9f %9f [%02x,%02x,%02x,%02x] ", testLE1->floatvalue, *f, 
ch[0], ch[1], ch[2], ch[3]);

 float1 = testLE1->floatvalue;
 ch = (char*)&float1;
 printf("%9f [%02x,%02x,%02x,%02x] ", float1, ch[0], ch[1], ch[2], ch[3]);
 float2 = *f;
 ch = (char*)&float2;
 printf("%9f [%02x,%02x,%02x,%02x] ", float2, ch[0], ch[1], ch[2], ch[3]);
 printf("%9f\n", *(&testLE1->floatvalue));

 return 0;
}

If I run the program the console outputs are different :

Output onto the console using pack(4): The values in the brackets [] 
show the byte ordering
(1) 50.00 50.00 [00,00,48,42] 50.00 [42,48,00,00] 50.00 
[42,48,00,00] 50.00
(2) 50.00 50.00 [00,00,48,42] 50.00 [42,48,00,00] 50.00 
[42,48,00,00] 50.00


Output onto the console using pack(1): The values in the brackets [] 
show the byte ordering
(1) 50.00  0.00 [42,48,00,00] 50.00 [42,48,00,00]  0.00 
[00,00,48,42] 50.00
(2)  0.00 50.00 [00,00,48,42]  0.00 [00,00,48,42] 50.00 
[42,48,00,00]  0.00



regards
Thomas

--

Thomas Korn
ifp - Ingenieurbüro für Prozessautomatisierung
Friedrich Werber Str. 44

D-78315 Radolfzell
Tel: (+49) 7732 98 27 89 - 13
Fax: (+49) 7732 98 27 89 - 44

Internet: www.ifp-beisch.com
EMail:[EMAIL PROTECTED]

Re: gcc will become the best optimizing x86 compiler

[Richard Guenther]

On Thu, Jul 24, 2008 at 3:28 PM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Basile STARYNKEVITCH wrote:
>>At last, at the recent (july 2008) GCC summit, someone (sorry I forgot who,
>> probably someone from SuSE)

That was me and Michael Matz.

Richard.

machine cheat

[Jason mclaughlin]

Say pieces on a board, make each piece a pair with another piece.

like...

|55|33|66|
|44|66|55|
|33|44|22|
|22|11|11|

a piece can only be figured out to move one way...


pick any piece, try to move it somewhere...

have the chosen piece move to another piece, it moves there and makes
the other piece have to move too.

when a piece is moved to another piece, it becomes a pair with the
piece it moves to.
any piece that is moved has to have it's pair move at the same time.

any piece to move to another piece is a piece that moved at the same
time as it's pair, and moved to another piece that

moved at the same time as it's pair too. A piece that moves to another
piece becomes a pair with it, and the other of the pair
has moved to become a pair with another piece.

try anyway, works in one way where a piece can move back to the piece
to move first.


A common type of problem, I forget what it's called.


A piece always goes where a piece leaves, the first piece has the last
piece go where it left.

You can't move a piece that moves where the piece came from.

There is no such thing as a free space, a piece always moves to another piece.

A pair never moves to a pair.

A piece works out to move where another piece can get back to where a
piece moves from.

The last move has to be known for the first move to be made, because
the first move can't be understood until
the last move is. That's because the first move is where a piece moves
to and it works around to the last move, and the
last move is where a piece can work getting to from the first move.

so try this...

draw starting at each piece a line that shows the piece it moves to,
and each piece to move for how a piece moves back
where it starts.

see this as a machine diagram.

move a piece then figure the machine diagram again, it's the same
machine though...

see how every other piece moves another way now?

what happened for how the machine moved?


_how did the machine move though_ 

Re: gcc will become the best optimizing x86 compiler

[Joseph S. Myers]

On Thu, 24 Jul 2008, Basile STARYNKEVITCH wrote:

> At last, at the recent (july 2008) GCC summit, someone (sorry I forgot who,
> probably someone from SuSE) proposed in a BOFS to have architecture and
> machine specific hand-tuned (or even hand-written assembly) low level
> libraries for such basic things as memset etc..

I don't recall seeing any BOF minutes on this list yet this year.  Are 
people going to be posting them?

I don't know if it was proposed in this context, but the ARM EABI has 
various __aeabi_mem* functions for calls known to have particular 
alignment and the idea is relevant to other platforms if you provide such 
functions with the compiler.  The compiler could also generate calls to 
different functions depending on the -march options and so save the 
runtime CPU check cost (you could have options to call either generic 
versions, or versions for a particular CPU, depending on whether you are 
building a generic binary for CPU-X-or-newer or a binary just for CPU X).

As usual in this area, careful negotiation with the FSF at an early stage 
to be able to reuse glibc versions of the functions where useful would be 
a good idea.  Reusing the glibc testcases for string functions (that e.g. 
they don't access beyond the memory they are allowed to access at the end 
of a page) would be a good idea as well, and doesn't have the problems 
with changing licenses that reusing the functions themselves does.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: gcj/sparc64?

[Tom Tromey]

> "Jay" == Jay  <[EMAIL PROTECTED]> writes:

Jay> This is an incomplete bug report.
Jay>  unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: 
Jay>   -bash-3.00$ gcc -v  
Jay>   Using built-in specs.  
Jay>   Target: sparc-sun-solaris2.10  

[...]
Jay>   /.libs/HTML_401F.o  
Jay>   gcj: Internal error: Segmentation Fault (program jc1)  
Jay>   Please submit a full bug report.  

Knowing this particular file, maybe gcj just ran out of memory.
Anyway, please file in bugzilla.  If you can include a jc1 stack
trace, that would be helpful.

Jay> I shouldn't need this MAKEINFO=echo, but I do for some reason.
Jay> btw, it'd be cool if one could easily add languages later, remove
Jay> -disable-multilib later, etc.  ie: "reconfigure slightly
Jay> differently/larger && make" and have it be super duper smart
Jay> about what to rebuild And -disable-libiconv would be nice.

Send bug reports and/or patches...
Thanks.

Tom

Need a pointer for debugging

[Mohamed Shafi]

Hello all,

I am involved in the porting of GCC 4.1.2 for a 16 bit target. The
target doenst have any SImode comparisons. Most of the time SImode
comparisons are synthesized using HImode comparisons. But some in some
instances SImode patterns are generated like that, where the code is
expanded in the pattern template. During the regression i got a ICE
related to SImode comparisons, more specifically in
unroll_and_peel_loops().

In unroll_loop_runtime_iterations called from unroll_and_peel_loops ()
the following piece of code

"
  for (i = 0; i < n_peel; i++)
{
  /* Peel the copy.  */
  sbitmap_zero (wont_exit);
  if (i != n_peel - 1 || !last_may_exit)
SET_BIT (wont_exit, 1);
  ok = duplicate_loop_to_header_edge (loop, loop_preheader_edge (loop),
  loops, 1,
  wont_exit, desc->out_edge,
  remove_edges, &n_remove_edges,
  DLTHE_FLAG_UPDATE_FREQ);
  gcc_assert (ok);

  /* Create item for switch.  */
  j = n_peel - i - (extra_zero_check ? 0 : 1);
  p = REG_BR_PROB_BASE / (i + 2);

  preheader = loop_split_edge_with (loop_preheader_edge (loop), NULL_RTX);
  branch_code = compare_and_jump_seq (copy_rtx (niter), GEN_INT (j), EQ,
  block_label (preheader), p,
  NULL_RTX);

  swtch = loop_split_edge_with (single_pred_edge (swtch), branch_code);
  set_immediate_dominator (CDI_DOMINATORS, preheader, swtch);
  single_pred_edge (swtch)->probability = REG_BR_PROB_BASE - p;
  e = make_edge (swtch, preheader,
 single_succ_edge (swtch)->flags & EDGE_IRREDUCIBLE_LOOP);
  e->probability = p;
}

"

generated SImode comparisons from 'compare_and_jump_seq()'. This
SImode comparisons are synthesized using HImode comparisons. This
results is the generation of two jump instructions and the ICE is
because both jump instructions end up in the same basic block.

>From  bug.c.21.loop2_unroll
"
;; Start of basic block 26, registers live: (nil)
(note 248 174 245 26 [bb 26] NOTE_INSN_BASIC_BLOCK)

(jump_insn 245 248 246 26 (set (pc)
(if_then_else (ne:CC (subreg:HI (reg:SI 113) 0)
(const_int 0 [0x0]))
(label_ref 247)
(pc))) -1 (nil)
(nil))

(jump_insn 246 245 247 26 (set (pc)
(if_then_else (eq:CC (subreg:HI (reg:SI 113) 2)
(const_int 0 [0x0]))
(label_ref 244)
(pc))) -1 (nil)
(nil))

(code_label 247 246 224 26 18 "" [0 uses])
;; End of basic block 26, registers live:
 (nil)
"

Note that if i compile a code which has SImode EQ comparisons the
basic blocks and code is generated properly. Right now i am stuck in
debugging.
Could anybody please provide me with any pointers?

Regards,
Shafi

Re: gcc will become the best optimizing x86 compiler

[Agner Fog]

Joseph S. Myers wrote:

>I don't know if it was proposed in this context, but the ARM EABI has
>various __aeabi_mem* functions for calls known to have particular
>alignment and the idea is relevant to other platforms if you provide such
>functions with the compiler. The compiler could also generate calls to
>different functions depending on the -march options and so save the
>runtime CPU check cost (you could have options to call either generic
>versions, or versions for a particular CPU, depending on whether you are
>building a generic binary for CPU-X-or-newer or a binary just for CPU X).

memcpy in the Intel and Mac libraries, as well as my own code, have 
different branches for different alignments and different CPU 
instruction sets. The runtime cost for this branching is negligible 
compared to the gain, even when the byte count is small. No need to 
bother the programmer with different versions.


You can just copy the code from the Mac library, or from me.

collect2: ld returned 12 exit status

[Shlom Marom]

Hi,
I'm trying to compile and link a product that was already compiled and
linked successfully before, on AIX5.3 with gcc3.4.6, but I got the
following link err:
"collect2: ld returned 12 exit status"

Pls note that this happens to me only when not using  the strip flag
(-s) since I need the symbols for debugging...
=> I can link only the release version.

I didn't see any memory/space problem on my machine, but I'm whilling
to try evrything you suggest, since I'm stuck with this problem for
too long.


thank,
Pls send you respose ALSO to the following email address: [EMAIL PROTECTED]

Re: gcc will become the best optimizing x86 compiler

[Agner Fog]

Basile STARYNKEVITCH wrote:
>At last, at the recent (july 2008) GCC summit, someone (sorry I forgot 
who, probably someone from SuSE)
> proposed in a BOFS to have architecture and machine specific 
hand-tuned (or even hand-written assembly) low

> level libraries for such basic things as memset etc..

That's exactly what I meant. The most important memory, string and math 
functions should use hand-tuned assembly with CPU dispatching for the 
latest instruction sets. My experiments show that the speed can be 
improved by a factor 3 - 10 for unaligned memcpy on Intel processors 
(http://www.agner.org/optimize/optimizing_cpp.pdf page 12).


There will be more hand-tuning work to do when the 256-bit YMM registes 
become available in a few years - and more to gain in speed.

lto gimple types and debug info

[Kenneth Zadeck]

I have been working on a design for gimple types.  The overall plan is
to gimplify the types, as we gimplify the executable code.   Then we
can release the front end types and recover the space.

There are difficulties with this plan and most of them have to do with
the generation of debug information.  The first problem arises
because several passes in the existing compiler, and possibly more
passes in the future, modify the types.  The existing passes that
modify the types are the structure peeling and reorg passes as well as
the matrix reorg pass.

In talking to people, there appear to be 4 ways to go here.

  1) Screw the debugging.  The motivation behind this option is that
  not only is it easy, but the reality is that we have changed the
  program so much that even if we did "fix up the types" so that the
  matched the generated program, that the code is so different from
  what the user expected that (s)he could not even debug if anyway.
  If the compiler peels field x out of structure y, the user cannot
  look at y.x.  I do not know if the debuggers and the dwarf could be
  taught to hide this, they currently do not.  (Note that teaching
  the debuggers to do a good job with this would be a good topic for
  a paper.)

  2) Generate the debugging for the types early, and then add an
  interface that would parse and regenerate the debugging info with
  the changes.  It is quite likely that this would lock gcc
  completely into dwarf, but that appears to only be a problem for
  AIX at this point, so that may not be that much of a problem.

  3) Generate the debugging for the types late.  The problem here is
  that we want the gimple type system to be stripped of the front end
  specific information, so any front end specific info that is only
  necessary for the debugging, will both bulk up the gimple type
  system and make it less language independent.

  4) Do mostly (3) but generate the debugging info for the fe
  dependent things like typedef and templates in the front ends.


Richi has been an advocate for (1).  I actually think that if these
optimizations become important, people will add the smarts to the
dwarf and the debuggers to hide this from the programmer so I
personally want to avoid designing this so that we cannot even get
this right if we want to.  However, I agree that the problems are hard
and are not going to be solved soon.

Diego suggested (2).   I do not know if he was just throwing it out or
if he is really an advocate of this.   This will be a lot of work and
will be costly to do in the lto1 pass of whopr.

I am leaning to (4).  According to richi and jason, we could (and may
be now) generate the typedefs so that they just point the underlying
type.  This means that the front ends could generate the typedefs, and
we would not need to carry any of that into the gimple type system
except for some dwarf reference.  Then all that we would need is to
add a field to decls that contains the reference of the typedef so that
when the debugging for the decl is generated and the type of the decl
was a typedef, we can generate the debugging info pointing to the
typedef rather than the type.

Richi also advocated not having the type names at the gimple level.
However the type names are necessary for doing type merging for lto
and are important for alias analysis in languages with stronger type
systems than C or C++, so I believe that the type names are going to
be a necessary part of the gimple type system.

In this same vein, I am very interested in using the gimple type
system as a way to start moving gcc from being a C compiler that
accommodates other languages to a compiler that handles different
languages on an equal footing.  The freedom that C and C++ "enjoy" to
basically take a pointer to one type and convert it to a pointer to
almost any other type is not something that is allowed by the other
languages that gcc supports.  Fortran seems to require (and this
should be confirmed by a fortran expert) a very disciplined use of
pointers, even restricting pointers to only being able to point to
variables that are declared to be targets of pointers.  In java it is
also impossible to transform a pointer into another type except in
very restrictive ways.   I would expect that we should be able to
distinguish types as being only advisory as in C and C++ from types
that represent a contract between a programmer and the compiler.
I do not know how Objc and Ada fit into this mesh, it would be nice to
know exactly what those languages could utilize.

What doing (4) does mean is that many of the attributes like "private"
are going to also have to be attached to the gimple types.  I do not
see this as bad as long as it is not too bulky, because again, we
should be able to utilize some of this information in the middle ends
if it is packaged correctly.   



As a general principal, the debugging information and lto do not play
well together, especially where whopr comes into play.  The problem i

Bootstrap failures on ToT, changes with no ChangeLog entry?

[Steve Ellcey]

All of my bootstraps except x86 Linux failed last night.   Both 
HP-UX builds and my IA64 Linux build.  This was with version 
138102.  I tried to find out when the failure started and ran
into some odd things.  If I go back to version 138070 and
then update my tree to 138076 I see a bunch of files in trunk/gcc
that are changed but ChangeLog does get changed during this
update.

I do get the failure with version 138076, I am still testing
138070.

Is anyone else seeing bootstrap failures with ToT?  Does anyone
know what is going on with ChangeLog?

I also tried updating to 138077 at one point and that version number
doesnt' seem to exist:

$ svn update -r138077
svn: Target path does not exist

At least I think that is what this error means.

What is going on?

Steve Ellcey
[EMAIL PROTECTED]

Re: lto gimple types and debug info

[Arnaud Charlet]

> In this same vein, I am very interested in using the gimple type
> system as a way to start moving gcc from being a C compiler that
> accommodates other languages to a compiler that handles different
> languages on an equal footing.  The freedom that C and C++ "enjoy" to
> basically take a pointer to one type and convert it to a pointer to
> almost any other type is not something that is allowed by the other
> languages that gcc supports.  Fortran seems to require (and this
> should be confirmed by a fortran expert) a very disciplined use of
> pointers, even restricting pointers to only being able to point to
> variables that are declared to be targets of pointers.

I do not know Fortran, but from the description above, this is similar in Ada:
you cannot freely mix different pointers, and you cannot make a pointer out
of any variable, unless variables are marked 'aliased'. This semantic is
already expressed today in GCC trees, so I'm not sure what more/different
you're suggesting though.

Arno

Re: Bootstrap failures on ToT, changes with no ChangeLog entry?

[H.J. Lu]

Hi Steve,

That is

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


H.J.
On Thu, Jul 24, 2008 at 9:35 AM, Steve Ellcey <[EMAIL PROTECTED]> wrote:
>
> All of my bootstraps except x86 Linux failed last night.   Both
> HP-UX builds and my IA64 Linux build.  This was with version
> 138102.  I tried to find out when the failure started and ran
> into some odd things.  If I go back to version 138070 and
> then update my tree to 138076 I see a bunch of files in trunk/gcc
> that are changed but ChangeLog does get changed during this
> update.
>
> I do get the failure with version 138076, I am still testing
> 138070.
>
> Is anyone else seeing bootstrap failures with ToT?  Does anyone
> know what is going on with ChangeLog?
>
> I also tried updating to 138077 at one point and that version number
> doesnt' seem to exist:
>
>$ svn update -r138077
>svn: Target path does not exist
>
> At least I think that is what this error means.
>
> What is going on?
>
> Steve Ellcey
> [EMAIL PROTECTED]
>



-- 
H.J.

Re: Bootstrap failures on ToT, changes with no ChangeLog entry?

[Andreas Schwab]

Steve Ellcey <[EMAIL PROTECTED]> writes:

> I also tried updating to 138077 at one point and that version number
> doesnt' seem to exist:
>
>   $ svn update -r138077
>   svn: Target path does not exist
>
> At least I think that is what this error means.
>
> What is going on?

Definitely something fishy around that time.  svn log says:


r138082 | meissner | 2008-07-23 13:18:03 +0200 (Mi, 23 Jul 2008) | 1 line

Add missing ChangeLog from 138075

r138078 | meissner | 2008-07-23 13:06:42 +0200 (Mi, 23 Jul 2008) | 1 line

undo 138077

r138075 | meissner | 2008-07-23 12:28:06 +0200 (Mi, 23 Jul 2008) | 1 line

Add ability to set target options (ix86 only) and optimization options on a func


And svn diff says:

$ svn diff -c138078
svn: Unable to find repository location for '' in revision 138077
$ svn diff -c138077
svn: The location for '' for revision 138077 does not exist in the repository 
or refers to an unrelated object

Apparently the repository has some issues with revision 138077.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Bootstrap failures on ToT, changes with no ChangeLog entry?

[Daniel Jacobowitz]

On Thu, Jul 24, 2008 at 06:48:56PM +0200, Andreas Schwab wrote:
> $ svn diff -c138078
> svn: Unable to find repository location for '' in revision 138077
> $ svn diff -c138077
> svn: The location for '' for revision 138077 does not exist in the repository 
> or refers to an unrelated object
> 
> Apparently the repository has some issues with revision 138077.

Yes, this has happened before: that's what it looks like in svn when
someone deletes and restores trunk.  Fortunately it doesn't break much
else; and it was restored correctly.

r138077 | meissner | 2008-07-23 07:01:39 -0400 (Wed, 23 Jul 2008) | 1
line
Changed paths:
   D /trunk

Delete working copy of function-specific to be replaced with a copy of
the mainline after it was checked in

r138078 | meissner | 2008-07-23 07:06:42 -0400 (Wed, 23 Jul 2008) | 1
line
Changed paths:
   A /trunk (from /trunk:138076)

undo 138077

-- 
Daniel Jacobowitz
CodeSourcery

Re: lto gimple types and debug info

[Chris Lattner]

On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote:


3) Generate the debugging for the types late.  The problem here is
 that we want the gimple type system to be stripped of the front end
 specific information, so any front end specific info that is only
 necessary for the debugging, will both bulk up the gimple type
 system and make it less language independent.


I thought the whole idea of the LTO project was to keep as much  
language specific type information as late as possible.  If you start  
stripping out useful information about types, it becomes harder to do  
high level optimizations like devirtualization and other source- 
specific transformations.  This is one of the major advantages of LTO,  
no?


-Chris

Re: Bootstrap failures on ToT, changes with no ChangeLog entry?

[Peter Bergner]

On Thu, 2008-07-24 at 18:48 +0200, Andreas Schwab wrote:
> Definitely something fishy around that time.  svn log says:
> 
> 
> r138082 | meissner | 2008-07-23 13:18:03 +0200 (Mi, 23 Jul 2008) | 1 line
> 
> Add missing ChangeLog from 138075
> 
> r138078 | meissner | 2008-07-23 13:06:42 +0200 (Mi, 23 Jul 2008) | 1 line
> 
> undo 138077
> 
> r138075 | meissner | 2008-07-23 12:28:06 +0200 (Mi, 23 Jul 2008) | 1 line
> 
> Add ability to set target options (ix86 only) and optimization options on a 
> func
> 
> 
> And svn diff says:
> 
> $ svn diff -c138078
> svn: Unable to find repository location for '' in revision 138077
> $ svn diff -c138077
> svn: The location for '' for revision 138077 does not exist in the repository 
> or refers to an unrelated object
> 
> Apparently the repository has some issues with revision 138077.

Maybe it's related to this #gcc comment:

 [snip]
   However, I did accidentily delete the trunk when I was trying to 
delete
   the branch, and did a copy from the previous version.  Is there 
anyway on
   the svn pre-commits to prevent somebody deleting the trunk?

Peter

Re: gcc will become the best optimizing x86 compiler

[Basile STARYNKEVITCH]

Joseph S. Myers wrote:

On Thu, 24 Jul 2008, Basile STARYNKEVITCH wrote:


At last, at the recent (july 2008) GCC summit, someone (sorry I forgot who,
probably someone from SuSE) proposed in a BOFS to have architecture and
machine specific hand-tuned (or even hand-written assembly) low level
libraries for such basic things as memset etc..


I don't recall seeing any BOF minutes on this list yet this year.  Are 
people going to be posting them?



for the BOFS I did propose, the summary is on the wiki.

http://gcc.gnu.org/wiki/MakingGCCEasierToLearn

(I agree that my summary is not very good. Feel free to improve it)

Regards.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: gcc will become the best optimizing x86 compiler

[Raksit Ashok]

On Thu, Jul 24, 2008 at 1:03 AM, Agner Fog <[EMAIL PROTECTED]> wrote:
> Dennis Clarke wrote:
>>The Sun Studio 12 compiler with Solaris 10 on AMD Opteron or
>>UltraSparc beats GCC in almost every single test case that I have
>>seen.
>
> This is memcpy on Solaris:
> http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/i386/gen/memcpy.s
>
> It uses exactly the same method as memcpy on gcc libc, with only minor
> differences that have no influence on performance.

There is a more optimized version for 64-bit:
http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/lib/libc/amd64/gen/memcpy.s

I think this looks similar to your implementation, Agner.

-raksit

>
>> Also, you have provided no data at all.
>
> I have linked to the data rather than copying it here to save space on the
> mailing list. Here is the link again:
> http://www.agner.org/optimize/optimizing_cpp.pdf  section 2.6, page 12.
>
>> So your assertions are those of a marketing person at the moment.
>
> Who sounds like a marketing person, you or me? :-)
>
>> Please post some code that can be compiled and then tested with high
>> resolution timers and perhaps
>> we can compare notes.
>
> Here is my code, again:
> http://www.agner.org/optimize/asmlib.zip
> My test results, referred to above, uses the "core clock cycles" performance
> counter on Intel and RDTSC on AMD. It's the highest resolution you can get.
> Feel free to do you own tests, it's as simple as linking my library into
> your test program.
>
> Tim Prince wrote:
>>you identify the library you tested only as "ubuntu g++ 4.2.3."
> Where can I see the libc version?
>
>>The corresponding 64-bit linux will see vastly different levels of
>> performance, depending on the
>>glibc version, as it doesn't use a builtin string move.
> Yes, this is exactly what my tests show. 64-bit libc is better than 32-bit
> libc, but still 3-4 times slower than the best library for unaligned
> operands on an Intel.
>
>>Certain newer CPUs aim to improve performance of the 32-bit gcc builtin
>> string moves, but don't
>> entirely eliminate the situations where it isn't optimum.
>
> The Intel manuals are not clear about this. Intel Optimization reference
> manual says:
>>In most cases, applications should take advantage of the default memory
>> routines provided by Intel compilers.
> What an excellent advice - the Intel compiler puts in a library with an
> automatic run-slowly-on-AMD feature!
> The Intel library does not use rep movs when running on an Intel CPU.
>
> The AMD software optimization guide mentions specific situations where rep
> movs is optimal. However, my tests on an Opteron (K8) tell that rep movs is
> never optimal on AMD either. I have no access to test it on the new AMD K10,
> but I expect the XMM register code to run much faster on K10 than on K8
> because K10 has 128-bit data paths where K8 has only 64-bit.
>
> Evidently, the problem with memcpy has been ignored for years, see
> http://softwarecommunity.intel.com/Wiki/Linux/719.htm
>
>

Re: lto gimple types and debug info

[Kenneth Zadeck]

Chris Lattner wrote:


On Jul 24, 2008, at 9:26 AM, Kenneth Zadeck wrote:


3) Generate the debugging for the types late.  The problem here is
 that we want the gimple type system to be stripped of the front end
 specific information, so any front end specific info that is only
 necessary for the debugging, will both bulk up the gimple type
 system and make it less language independent.


I thought the whole idea of the LTO project was to keep as much 
language specific type information as late as possible.  If you start 
stripping out useful information about types, it becomes harder to do 
high level optimizations like devirtualization and other 
source-specific transformations.  This is one of the major advantages 
of LTO, no?


I think that there is a lot of front end information in the types that 
really is not useful to the middle ends.   That can be stripped away.  I 
certainly do not want to strip anything that could be used for something 
like devirtualization.  

As a (possibly flawed example), the private attribute in c++ is 
completely useless for optimization because it is legal for functions 
that otherwise have no access to a private field to gain access by 
pointer arithmetic.  However, in a truly strongly typed language, the 
private attribute can be used to limit the scope of a variable to a 
single compilation unit. 

The reason that this example is flawed, is that we will have to keep 
this "weak" private attribute if we generate the debugging info late so 
that the debugger could see it (assuming it cares).



-Chris

Re: lto gimple types and debug info

[Kenneth Zadeck]

Arnaud Charlet wrote:

In this same vein, I am very interested in using the gimple type
system as a way to start moving gcc from being a C compiler that
accommodates other languages to a compiler that handles different
languages on an equal footing.  The freedom that C and C++ "enjoy" to
basically take a pointer to one type and convert it to a pointer to
almost any other type is not something that is allowed by the other
languages that gcc supports.  Fortran seems to require (and this
should be confirmed by a fortran expert) a very disciplined use of
pointers, even restricting pointers to only being able to point to
variables that are declared to be targets of pointers.



I do not know Fortran, but from the description above, this is similar in Ada:
you cannot freely mix different pointers, and you cannot make a pointer out
of any variable, unless variables are marked 'aliased'. This semantic is
already expressed today in GCC trees, so I'm not sure what more/different
you're suggesting though.

Arno
  
I was more interested in the types rather that the variables and i was 
imprecise because I did not have access to good fortran information. The 
issue that i was trying to get to was that in c and c++ the types do 
really restrict what you can get to from a pointer, while in java they 
do.   I suspect that in fortran they also do to but i do not know the 
language. 


kenny

Re: RFC: Bug in specs processing

[Mark Mitchell]

Andrew Pinski wrote:


 gcc -c -ohw.o hw.c



This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11810 .
There was a patch posted here:


Thanks for the information.  In looking at this further, I think I've 
found a simple way to solve the problem.


In particular, we already have a macro SWITCHES_NEED_SPACES.  This macro 
applies when gcc is parsing the command-line options, before we start 
any specs processing.  If SWITCHES_NEED_SPACES contains the letter "o", 
then we will split "-ofoo.o" into "-o foo.o", and from that point 
forward everything just works.


The SWITCHES_NEED_SPACES macro is presently defined to a non-empty 
string only for Alpha OSF and MIPS IRIX; in both cases it contains only 
the letter "o".


So, I propose we just make the default definition of the macro contain 
the letter "o" instead of being the empty string.  The only case this 
will break is if there are assemblers/linkers out there that *require* 
the "-ofoo.o" form.  We know the GNU assembler and linker are happy with 
either form.  Does anyone actually know of a tool that requires the 
other form?  If there is such a tool, we could have a specs spelling 
that says "substitute the option and the argument, collapsing them into 
a single argument" so that a spec for such a tool could still exist.


In other words, my proposed solution is to make the canonical spelling 
inside gcc be the two-argument "-o foo.o" spelling, and -- if necessary 
-- to collapse the spelling for the output.  If there really are tools 
that require "-ofoo.o" this will improve the user experience, since 
presently saying "-o foo.o" will not work on such platforms.  (Because 
that's true, I doubt there exist such tools; lots of Makefiles would die 
there.)


Thoughts?

--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713

Re: Bootstrap failures on ToT, changes with no ChangeLog entry?

[Daniel Berlin]

The easiest way to not delete trunk is to not delete trunk.


On Thu, Jul 24, 2008 at 10:06 AM, Peter Bergner <[EMAIL PROTECTED]> wrote:
> On Thu, 2008-07-24 at 18:48 +0200, Andreas Schwab wrote:
>> Definitely something fishy around that time.  svn log says:
>>
>> 
>> r138082 | meissner | 2008-07-23 13:18:03 +0200 (Mi, 23 Jul 2008) | 1 line
>>
>> Add missing ChangeLog from 138075
>> 
>> r138078 | meissner | 2008-07-23 13:06:42 +0200 (Mi, 23 Jul 2008) | 1 line
>>
>> undo 138077
>> 
>> r138075 | meissner | 2008-07-23 12:28:06 +0200 (Mi, 23 Jul 2008) | 1 line
>>
>> Add ability to set target options (ix86 only) and optimization options on a 
>> func
>> 
>>
>> And svn diff says:
>>
>> $ svn diff -c138078
>> svn: Unable to find repository location for '' in revision 138077
>> $ svn diff -c138077
>> svn: The location for '' for revision 138077 does not exist in the 
>> repository or refers to an unrelated object
>>
>> Apparently the repository has some issues with revision 138077.
>
> Maybe it's related to this #gcc comment:
>
>  [snip]
>   However, I did accidentily delete the trunk when I was trying to 
> delete
>   the branch, and did a copy from the previous version.  Is there 
> anyway on
>   the svn pre-commits to prevent somebody deleting the trunk?
>
> Peter
>
>
>
>

Re: RFC: Adding non-PIC executable support to MIPS

[Daniel Jacobowitz]

On Thu, Jul 24, 2008 at 12:16:20PM -0400, Daniel Jacobowitz wrote:
> I have attached

Let's all pretend I attached this glibc patch, instead of the one in
my previous message, please.

-- 
Daniel Jacobowitz
CodeSourcery
2008-07-24  Mark Shinwell  <[EMAIL PROTECTED]>
	Daniel Jacobowitz  <[EMAIL PROTECTED]>
	Richard Sandiford  <[EMAIL PROTECTED]>

	* sysdeps/mips/dl-lookup.c: New.
	* sysdeps/mips/do-lookup.h: New.
	* sysdeps/mips/dl-machine.h (ELF_MACHINE_NO_PLT): Remove
	definition.
	(ELF_MACHINE_JMP_SLOT): Alter definition and update comment.
	(elf_machine_type_class): Likewise.
	(ELF_MACHINE_PLT_REL): Define.
	(elf_machine_fixup_plt): New.
	(elf_machine_plt_value): New.
	(elf_machine_reloc): Handle jump slot and copy relocations.
	(elf_machine_lazy_rel): Point relocation place at PLT if
	required.
	(RESOLVE_GOTSYM): Take a relocation type argument.
	(elf_machine_got_rel): Bind lazy stubs directly to their target if
	!lazy.  Skip lazy binding for PLT symbols.
	(elf_machine_runtime_setup): Fill in .got.plt header.
	* sysdeps/mips/dl-trampoline.c (IFNEWABI): New macro.
	(_dl_runtime_pltresolve): New.
	* sysdeps/mips/bits/linkmap.h: New file.
	* sysdeps/mips/tls-macros.h: Load $gp as required.  Merge 32-bit and
	64-bit versions.

	* sysdeps/unix/sysv/linux/mips/mips32/sysdep.h (SYSCALL_ERROR_LABEL):
	Delete definition.
	* sysdeps/unix/sysv/linux/mips/nptl/sysdep-cancel.h (PSEUDO_CPLOAD,
	PSEUDO_ERRJMP, PSEUDO_SAVEGP, PSEUDO_LOADGP): Define.
	(PSEUDO): Use them.  Move outside __PIC__.
	(PSEUDO_JMP): New.
	(CENABLE, CDISABLE): Use it.

Index: sysdeps/unix/sysv/linux/mips/mips32/sysdep.h
===
--- sysdeps/unix/sysv/linux/mips/mips32/sysdep.h	(revision 213009)
+++ sysdeps/unix/sysv/linux/mips/mips32/sysdep.h	(working copy)
@@ -35,15 +35,7 @@
 # define SYS_ify(syscall_name)	__NR_/**/syscall_name
 #endif
 
-#ifdef __ASSEMBLER__
-
-/* We don't want the label for the error handler to be visible in the symbol
-   table when we define it here.  */
-#ifdef __PIC__
-# define SYSCALL_ERROR_LABEL 99b
-#endif
-
-#else   /* ! __ASSEMBLER__ */
+#ifndef __ASSEMBLER__
 
 /* Define a macro which expands into the inline wrapper code for a system
call.  */
Index: sysdeps/unix/sysv/linux/mips/nptl/sysdep-cancel.h
===
--- sysdeps/unix/sysv/linux/mips/nptl/sysdep-cancel.h	(revision 213009)
+++ sysdeps/unix/sysv/linux/mips/nptl/sysdep-cancel.h	(working copy)
@@ -25,28 +25,38 @@
 
 #if !defined NOT_IN_libc || defined IS_IN_libpthread || defined IS_IN_librt
 
-#ifdef __PIC__
+# ifdef __PIC__
+#  define PSEUDO_CPLOAD .cpload t9;
+#  define PSEUDO_ERRJMP la t9, __syscall_error; jr t9;
+#  define PSEUDO_SAVEGP sw gp, 32(sp); cfi_rel_offset (gp, 32);
+#  define PSEUDO_LOADGP lw gp, 32(sp);
+# else
+#  define PSEUDO_CPLOAD
+#  define PSEUDO_ERRJMP j __syscall_error;
+#  define PSEUDO_SAVEGP
+#  define PSEUDO_LOADGP
+# endif
+
 # undef PSEUDO
 # define PSEUDO(name, syscall_name, args)  \
   .align 2;  \
   L(pseudo_start):			  \
   cfi_startproc;			  \
-  99: la t9,__syscall_error;		  \
-  jr t9;  \
+  99: PSEUDO_ERRJMP			  \
   .type __##syscall_name##_nocancel, @function;  \
   .globl __##syscall_name##_nocancel;	  \
   __##syscall_name##_nocancel:		  \
 .set noreorder;			  \
-.cpload t9;  \
+PSEUDO_CPLOAD			  \
 li v0, SYS_ify(syscall_name);	  \
 syscall;  \
 .set reorder;			  \
-bne a3, zero, SYSCALL_ERROR_LABEL;			   		  \
+bne a3, zero, 99b;	   		  \
 ret;  \
   .size __##syscall_name##_nocancel,.-__##syscall_name##_nocancel;	  \
   ENTRY (name)  \
 .set noreorder;			  \
-.cpload t9;  \
+PSEUDO_CPLOAD			  \
 .set reorder;			  \
 SINGLE_THREAD_P(v1);		  \
 bne zero, v1, L(pseudo_cancel);	  \
@@ -54,17 +64,16 @@
 li v0, SYS_ify(syscall_name);	  \
 syscall;  \
 .set reorder;			  \
-bne a3, zero, SYSCALL_ERROR_LABEL;			   		  \
+bne a3, zero, 99b;	   		  \
 ret;  \
   L(pseudo_cancel):			  \
 SAVESTK_##args;		  \
 sw ra, 28(sp);			  \
 cfi_rel_offset (ra, 28);		  \
-sw gp, 32(sp);			  \
-cfi_rel_offset (gp, 32);		  \
+PSEUDO_SAVEGP			  \
 PUSHARGS_##args;			/* save syscall args */	  	  \
 CENABLE;  \
-lw gp, 32(sp);			  \
+PSEUDO_LOADGP			  \
 sw v0, 44(sp);			/* save mask */			  \
 POPARGS_##args;			/* restore syscall args */	  \
 .set noreorder;			  \
@@ -75,12 +84,12 @@
 sw a3, 40(sp);			/* save syscall error flag */	  \
 lw a0, 44(s

Re: RFC: Adding non-PIC executable support to MIPS

[Richard Sandiford]

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> - Richard's ld -r support is an addition to the ABI, but does not
> conflict with anything else, so I included it.  I discovered two
> potential problems:
>
>   - If a symbol with STO_MIPS_PIC is localized using objcopy,
>   binutils will ignore the flag.  I don't think this is presently
>   worth implementing but it might be wise to add an error message.
>   I haven't done that yet.
>
>   - Superfluous la25 stubs are suppressed when a PIC2 file uses jal.
>   This is an optimization performed by gcc -mno-shared.  It will not
>   work after ld -r into a non-PIC file; the jump will appear to come
>   from a non-PIC object and be redirected to a new stub.  This is only
>   a minor performance pessimization and I do not plan to fix it.

Yeah, for the record, this second one was actually a deliberate choice.
There's no real object-level information to indicate -mno-sharedness
(unlike "PIC"ness), so any attempt to recognise it would simply be a
heuristic.

The ld -r support was really there for the same reason as the la $25
stubs: to allow "real" PIC and "new" non-PIC to be linked together.
It seems unlikely that you'd have much -mno-shared code to link in if
you're using a "new"-PIC-compatible sysroot.

> - It would be nice to generate, in some cases, both a .MIPS.stubs lazy
> binding stub and a PLT entry.  However, I determined that considerable
> additional work would be required to do this; most likely we'd need
> two entries for the same symbol in the dynamic symbol table so that
> the GOT entry could be associated with the lazy loading stub.  As
> things stand it is possible to link non-PIC and PIC code together, and
> if both call the same function and the non-PIC code takes its address,
> calls to the function from PIC code will be penalized.  I do not
> expect this case to matter.  Most applications will be predominantly
> PIC or non-PIC.

Yeah, FWIW, I think we discussed this in the original three-way thread
last year.  (I think the original proposal was to use PLTs all the time
for "new-PIC" executables.  I remember arguing in favour of keeping
.MIPS.stubs as an option because they're more efficient when handling
the cases they can.  I certainly agree that's it not worth trying to
use both .MIPS.stubs and PLTs for the same function.)

> - I've dropped support for a non-fixed $gp.  This is a handy
> optimization, but it was getting in the way and it was the part of the
> GCC patch Richard had the most comments on.  I can resubmit it after
> everything else is merged.

That's a shame.  It was also the bit I liked best ;)  What went wrong?

(My comments were only minor.)

> - Richard's implementation had __PIC__ mean abicalls.  Our patch
> changed __PIC__ to mean pic2 abicalls only.  I've included that in
> this patch.  My reasoning is that most non-pic non-abicalls code works
> properly even with pic0 abicalls; the only problem is indirect calls
> through a register other than $25.  This lets glibc automatically use
> some more efficient sequences in static applications.

Hmm, OK.  It's the less conservative choice, but I agree it's also
the best performance-wise.

> - I added pointer_equality_needed support to binutils to suppress
> setting st_value to the PLT entry in most cases.
>
> - The GCC new-static-chain.patch causes nested-func-4.exe to fail.
> _mcount is called through a PLT entry, which clobbers $15.  I believe
> we need to add this to MIPS_SAVE_REG_FOR_PROFILING_P.  I didn't fix
> this yet.
>
> - no-fn-name-already-declared.patch removed the call to
> ASM_OUTPUT_TYPE_DIRECTIVE for Linux.  .ent has similar effect, but is
> suppressed by flag_inhibit_size_directive.  This caused glibc's _init
> to be STT_OBJECT, and not get a PIC call stub.  I've changed GCC to
> emit .type for all platforms; Richard, if this should be restricted
> to the status quo (i.e. Linux) let me know.

No, that sounds right to me FWIW.

> Also the STT_FUNC check in the linker was unnecessary now that we only
> use la25 stubs for jump relocations.

Agreed.

Sorry for the bugs, and thanks for fixing them.  I'll try to have
a look at the patches over the weekend.

Richard

Re: RFC: Adding non-PIC executable support to MIPS

[Daniel Jacobowitz]

On Thu, Jul 24, 2008 at 09:24:48PM +0100, Richard Sandiford wrote:
> > - I've dropped support for a non-fixed $gp.  This is a handy
> > optimization, but it was getting in the way and it was the part of the
> > GCC patch Richard had the most comments on.  I can resubmit it after
> > everything else is merged.
> 
> That's a shame.  It was also the bit I liked best ;)  What went wrong?
> 
> (My comments were only minor.)

Nothing big: but it made up the bulk of our GCC patch, and I was
rebasing on top of yours.  We had a lot of trouble getting that bit to
work, so I took the conservative path and dropped it.  Don't worry - I
definitely will return to this as soon as the remaining patches are
merged; I liked it too.

Originally, we were also going to make small data work with non-PIC
abicalls.  I'd like to discuss that with you at some later date too.
We ran into a lot of trouble combining small data with a non-fixed
$gp; I believe it was because reload may introduce small data loads
very late.  I'd have to try it again before I had anything more
sensible to say, though.

> Sorry for the bugs, and thanks for fixing them.  I'll try to have
> a look at the patches over the weekend.

No problem, and thank you for looking at them - and for your patches;
I'm really pretty happy with the combined work.

-- 
Daniel Jacobowitz
CodeSourcery

Re: gimple type system

[Gaius Mulley]

Kenneth Zadeck <[EMAIL PROTECTED]> writes:

> >> Anyway, there must be other uses of types in either the existing middle end
> >> or that people have dreams of adding to the middle end in the future.   Now
> >> is the time to raise your hand before the design has been started.

Hi,

for me its great use will be to introduce set type debugging into gm2.
At the very minimum it would be nice to be able to define a word sized
bit set which the middle and back end can consider it to have the
properties of "unsigned int" however the debugging info emitted needs
to say that this word is really a set type of some lower and upper
bounds and subtype.

But how this is done via an API is up to you :-).  My initial thoughts
would be for the front end to be able to define this unsigned int
"fake" type and obtain a unique handle.  The front end would then need
to also maintain the debugging stubs for the type (say dwarf2 and
stabs) which will be invoked by some call back mechanism during the
back end.  But I readily admit this is a little messy..

regards,
Gaius

Re: lto gimple types and debug info

[Chris Lattner]

On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
I thought the whole idea of the LTO project was to keep as much  
language specific type information as late as possible.  If you  
start stripping out useful information about types, it becomes  
harder to do high level optimizations like devirtualization and  
other source-specific transformations.  This is one of the major  
advantages of LTO, no?


I think that there is a lot of front end information in the types  
that really is not useful to the middle ends.   That can be stripped  
away.  I certainly do not want to strip anything that could be used  
for something like devirtualization.
As a (possibly flawed example), the private attribute in c++ is  
completely useless for optimization because it is legal for  
functions that otherwise have no access to a private field to gain  
access by pointer arithmetic.  However, in a truly strongly typed  
language, the private attribute can be used to limit the scope of a  
variable to a single compilation unit.


Ok, but how do you decide whether something is important or not to  
keep?  Why go through the work of removing the information if you may  
need it later?  How much will you really be able to take out?  Is this  
about removing a bit here and a bit there, or is there a large volume  
of the info that can be removed?


-Chris

Re: lto gimple types and debug info

[Daniel Berlin]

On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
> On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:
>>>
>>> I thought the whole idea of the LTO project was to keep as much language
>>> specific type information as late as possible.  If you start stripping out
>>> useful information about types, it becomes harder to do high level
>>> optimizations like devirtualization and other source-specific
>>> transformations.  This is one of the major advantages of LTO, no?
>>>
>> I think that there is a lot of front end information in the types that
>> really is not useful to the middle ends.   That can be stripped away.  I
>> certainly do not want to strip anything that could be used for something
>> like devirtualization.
>> As a (possibly flawed example), the private attribute in c++ is completely
>> useless for optimization because it is legal for functions that otherwise
>> have no access to a private field to gain access by pointer arithmetic.
>>  However, in a truly strongly typed language, the private attribute can be
>> used to limit the scope of a variable to a single compilation unit.
>
> Ok, but how do you decide whether something is important or not to keep?
>  Why go through the work of removing the information if you may need it
> later?  How much will you really be able to take out?  Is this about
> removing a bit here and a bit there, or is there a large volume of the info
> that can be removed?

I dunno, this seems like a thing you could better figure out by trying
it and seeing where the problems are than by trying to anticipate
every single possible problem
(not that there should be no design, but that it would be better to
start with a design and iterate it than try to figure out perfect
ahead of time).
>
> -Chris
>

Re: lto gimple types and debug info

[Arnaud Charlet]

>> I do not know Fortran but from the description above, this is similar in Ada:
>> you cannot freely mix different pointers, and you cannot make a pointer out
>> of any variable, unless variables are marked 'aliased'. This semantic is
>> already expressed today in GCC trees, so I'm not sure what more/different
>> you're suggesting though.
>> 
>> Arno
>>   
> I was more interested in the types rather that the variables and i was 

I was describing both types and variables for Ada.

> imprecise because I did not have access to good fortran information. The 
> issue that i was trying to get to was that in c and c++ the types do really 
> restrict what you can get to from a pointer, while in java they do.   I 

I assume you meant 'do not really restrict' above.

> suspect that in fortran they also do to but i do not know the language.

In Ada as well.

Arno

Re: lto gimple types and debug info

[Kenneth Zadeck]

Daniel Berlin wrote:

On Thu, Jul 24, 2008 at 2:13 PM, Chris Lattner <[EMAIL PROTECTED]> wrote:
  

On Jul 24, 2008, at 10:16 AM, Kenneth Zadeck wrote:


I thought the whole idea of the LTO project was to keep as much language
specific type information as late as possible.  If you start stripping out
useful information about types, it becomes harder to do high level
optimizations like devirtualization and other source-specific
transformations.  This is one of the major advantages of LTO, no?



I think that there is a lot of front end information in the types that
really is not useful to the middle ends.   That can be stripped away.  I
certainly do not want to strip anything that could be used for something
like devirtualization.
As a (possibly flawed example), the private attribute in c++ is completely
useless for optimization because it is legal for functions that otherwise
have no access to a private field to gain access by pointer arithmetic.
 However, in a truly strongly typed language, the private attribute can be
used to limit the scope of a variable to a single compilation unit.
  

Ok, but how do you decide whether something is important or not to keep?
 Why go through the work of removing the information if you may need it
later?  How much will you really be able to take out?  Is this about
removing a bit here and a bit there, or is there a large volume of the info
that can be removed?



I dunno, this seems like a thing you could better figure out by trying
it and seeing where the problems are than by trying to anticipate
every single possible problem
(not that there should be no design, but that it would be better to
start with a design and iterate it than try to figure out perfect
ahead of time).
  
I agree that it is pointless to go thru the information bit by bit.  On 
the other hand there may be other things like the typedefs that serve no 
purpose in the middle end but do take a lot of space and require time to 
traverse. 

However, at some point we are going to have to get down to the 
discussion of what it means for two types declared in two different 
compilation units to be "the same"  and the less baggage that we have 
dragged in that is not relevant to that decision, the less unpleasant 
that process will be.




-Chris

Re: lto gimple types and debug info

[Kenneth Zadeck]

Arnaud Charlet wrote:

I do not know Fortran but from the description above, this is similar in Ada:
you cannot freely mix different pointers, and you cannot make a pointer out
of any variable, unless variables are marked 'aliased'. This semantic is
already expressed today in GCC trees, so I'm not sure what more/different
you're suggesting though.

Arno
  
  
I was more interested in the types rather that the variables and i was 



I was describing both types and variables for Ada.

  
imprecise because I did not have access to good fortran information. The 
issue that i was trying to get to was that in c and c++ the types do really 
restrict what you can get to from a pointer, while in java they do.   I 



I assume you meant 'do not really restrict' above.

  

yes.

suspect that in fortran they also do to but i do not know the language.



In Ada as well.

Arno
  


When danny and it wrote the ipa-type-escape pass, mark mitchell was all 
over us because we assumed that the type system had some semantic 
meaning.  We ended up with a pass that generally finds nothing useful.  
I would very much like to redo that pass once we can mark a type as 
coming from a language with a real type system.

Re: Bootstrap failures on ToT, changes with no ChangeLog entry?

[Michael Meissner]

On Thu, Jul 24, 2008 at 09:35:26AM -0700, Steve Ellcey wrote:
> 
> All of my bootstraps except x86 Linux failed last night.   Both 
> HP-UX builds and my IA64 Linux build.  This was with version 
> 138102.  I tried to find out when the failure started and ran
> into some odd things.  If I go back to version 138070 and
> then update my tree to 138076 I see a bunch of files in trunk/gcc
> that are changed but ChangeLog does get changed during this
> update.
> 
> I do get the failure with version 138076, I am still testing
> 138070.
> 
> Is anyone else seeing bootstrap failures with ToT?  Does anyone
> know what is going on with ChangeLog?
> 
> I also tried updating to 138077 at one point and that version number
> doesnt' seem to exist:
> 
>   $ svn update -r138077
>   svn: Target path does not exist
> 
> At least I think that is what this error means.
> 
> What is going on?
> 
> Steve Ellcey
> [EMAIL PROTECTED]

I made two mistakes when I submitted the function specific patch (138075).  The
first mistake was I was trying to move the current tree to the branch, and
accidently deleted the trunk instead of the branch (138077), and fixed this by
copying 138076 back to the trunk and submitted it as 138078.  Then I discovered
that I had not submitted the ChangeLog as part of 138075, and submitted that
afterwards (the changelog entry was in the patch sent to gcc-patches).

I submitted another patch yesterday that fixed building objective C libraries.

I'm working on a fix for the IA-64 right now, and the IA-64 fix will likely
need to be replicated in the other ports that define OVERRIDE_OPTIONS
(basically a lot of ports do lots of stuff in OVERRIDE_OPTIONS, but the
hot/cold attribute stuff which now calls the optimzie attribute, which in turn
needs to call the parts of OVERRIDE_OPTIONS that are safe to do more than once
(adding a SECONDARY_OVERRIDE_OPTIONS).

Mea culpa.  I'm sorry for problems I've caused with the addition of function
specific optimizations.

-- 
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org

Re: Bootstrap failures on ToT, changes with no ChangeLog entry?

[Michael Meissner]

On Thu, Jul 24, 2008 at 12:48:30PM -0700, Daniel Berlin wrote:
> The easiest way to not delete trunk is to not delete trunk.

Yes of course, but mistakes do happen.

-- 
Michael Meissner
email: [EMAIL PROTECTED]
http://www.the-meissners.org

Re: Scratch register in "jump" instruction ?

[Stelian Pop]

Le lundi 21 juillet 2008 à 15:37 +0200, Stelian Pop a écrit :

> I have a problem with the jump instructions: my direct jumps are very
> limited in displacements, and I want to always generate indirect jumps
> instead.

Ok, no answer yet.

Does this mean that my question is really dumb ?

Or does this mean that it should work just fine and I need to debug
deeper to see what happens here ?

Thanks,

-- 
Stelian Pop <[EMAIL PROTECTED]>

You make my world beautiful

[flaro088]

I want to be with you http://209.62.250.161/

gcc-4.3-20080724 is now available

[gccadmin]

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

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

You'll find:

gcc-4.3-20080724.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080724.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080724.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080724.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080724.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080724.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080724.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080724.tar.bz2The GCC testsuite

Diffs from 4.3-20080717 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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: machine cheat

[Ben Elliston]

OK, I give up.  What is the point of your messages and why is it the GCC
list that you've chosen to bother with them?

Ben

Re: machine cheat

[Martin Michlmayr]

* Ben Elliston <[EMAIL PROTECTED]> [2008-07-25 09:17]:
> OK, I give up.  What is the point of your messages and why is it the
> GCC list that you've chosen to bother with them?

FWIW, he sent the same (at least) to debian-devel.  I'd just ignore it.
-- 
Martin Michlmayr
http://www.cyrius.com/

Re: lto gimple types and debug info

[Chris Lattner]

I dunno, this seems like a thing you could better figure out by  
trying

it and seeing where the problems are than by trying to anticipate
every single possible problem
(not that there should be no design, but that it would be better to
start with a design and iterate it than try to figure out perfect
ahead of time).

I agree that it is pointless to go thru the information bit by bit.   
On the other hand there may be other things like the typedefs that  
serve no purpose in the middle end but do take a lot of space and  
require time to traverse.
However, at some point we are going to have to get down to the  
discussion of what it means for two types declared in two different  
compilation units to be "the same"  and the less baggage that we  
have dragged in that is not relevant to that decision, the less  
unpleasant that process will be.


Sure, typedefs in C/C++ seem clearly useless.  I'm just curious how  
you plan to go about deciding whether things are useless in a more  
general context.  How fine of a granularity do you intend to inspect  
bits?  Trees have lots of random stuff that are hard to identify and  
unify.  Hopefully this will be a good step towards making LTO actually  
be able to work with source files that come from different languages.   
Does this mean that all language-specific type info will be removed?


More generally, can you detail what your plan is?  Is it to remove  
specific pieces (like typedefs, what else?) or just hack and slash  
random stuff if it gets in your way?  I'm more curious about your  
approach and "threshold for usefulness" than an abstract statement  
about how you will remove useless stuff and keep the useful stuff :)


-Chris

--sysroot=yes

[Jay]

I think this one is an actual bug, somewhat "predictable" (easy to realize what 
the problem is roughly),
easy for the appropriate folks to fix, easy for affected folks to workaround.

It goes *like* (this is a paraphrase!): 

  get a "working" system -- cygwin gcc 3.x in my case, but the problem is 
probably very portable, as long as you don't have an integrated newlib/glibc 
providing the "sysroot" (e.g. Solaris, djgpp, *bsd?)  
  merged source tree gcc 4.3.1 (release)/binutils 2.18 (release)/gmp/mpfr 
  get a sparc-sun-solaris2.10 sysroot, at 
/usr/local/sparc-sun-solaris2.10/sys-root  
   This is the default for said target, if you say just -with-sysroot or 
-with-build-sysroot. 
   The problem is that such defaulting sometimes leads to a value of "yes" 
instead of the default path.  
  mkdir /obj  
  mkdir /obj/native 
  mkdir /obj/cross   
  mkdir /obj/cross-to-native # what to call this?   
  cd /obj/native 
  /src/gcc/configure && make && make install  
  cd /obj/cross   
  /src/gcc/configure -with-sysroot -host i686-pc-cygwin -target 
sparc-sun-solaris2.10  && make && make install 
  cd /obj/cross-to-native  
  /src/gcc/configure -with-build-sysroot -host sparc-sun-solaris2.10  -target 
sparc-sun-solaris2.10  && make && make install 
DESTDIR=/usr/local/sparc-sun-solaris2.10/install 


Yields:


  make[4]: Entering directory 
`/obj/gcc.2/sparc-sun-solaris2.10/sparc-sun-solaris2
  .10/sparc-sun-solaris2.10/sparcv9/libgcc'  
  # If this is the top-level multilib, build all the other  
  # multilibs.  
  sparc-sun-solaris2.10-gcc 
-L/obj/gcc.2/sparc-sun-solaris2.10/sparc-sun-solaris2.  
  10/./ld -O2 -g -g -O2 --sysroot=yes -m64 -O2  -O2 -g -g -O2 --sysroot=yes  
-DIN_  
  GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes 
-Wold-s  
   tyle-definition  -isystem ./include  -fPIC -g -DHAVE_GTHR_DEFAULT 
-DIN_LIBGCC2 -  
  D__GCC_FLOAT_NOT_NEEDED   -I. -I. -I../../.././gcc -I/src/gcc/libgcc 
-I/src/gcc/  
  libgcc/. -I/src/gcc/libgcc/../gcc -I/src/gcc/libgcc/../include  -DHAVE_CC_TLS 
-o  
   _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c 
/src/gcc/libgcc/.  
  ./gcc/libgcc2.c \  
  -fvisibility=hidden -DHIDE_EXPORTS  
  In file included from /src/gcc/libgcc/../gcc/libgcc2.c:33:  
  /src/gcc/libgcc/../gcc/tsystem.h:90:19: error: stdio.h: No such file or 
director  
  y  
  /src/gcc/libgcc/../gcc/tsystem.h:93:23: error: sys/types.h: No such file or 
dire  
  ctory  
  /src/gcc/libgcc/../gcc/tsystem.h:96:19: error: errno.h: No such file or 
director  
  y  
  /src/gcc/libgcc/../gcc/tsystem.h:103:20: error: string.h: No such file or 
direct  
  ory  
  /src/gcc/libgcc/../gcc/tsystem.h:104:20: error: stdlib.h: No such file or 
direct  
  ory  
  /src/gcc/libgcc/../gcc/tsystem.h:105:20: error: unistd.h: No such file or 
direct  
  ory  
  In file included from 
/usr/local/lib/gcc/sparc-sun-solaris2.10/4.3.1/include-fix  
  ed/syslimits.h:7,  
 from 
/usr/local/lib/gcc/sparc-sun-solaris2.10/4.3.1/include-fix  
  ed/limits.h:11,  
 from /src/gcc/libgcc/../gcc/tsystem.h:108,  
 from /src/gcc/libgcc/../gcc/libgcc2.c:33:  
  /usr/local/lib/gcc/sparc-sun-solaris2.10/4.3.1/include-fixed/limits.h:122:61: 
er  
  ror: no include path in which to search for limits.h  
  In file included from /src/gcc/libgcc/../gcc/libgcc2.c:33:  
  /src/gcc/libgcc/../gcc/tsystem.h:111:18: error: time.h: No such file or 
directory  


 The problem is, if you look closely at the command line, is --sysroot=yes. 
 I configured with just -with-syroot or -with-build-sysroot.


  You can sort of repro it via "emulation", like:  


/src/gcc/configure -with-sysroot -host i686-pc-cygwin -target 
sparc-sun-solaris2.10  && make && make install   
echo "#include "> 1.c   
  
 sparc-sun-solaris2.10-gcc -c 1.c   
 sparc-sun-solaris2.10-gcc --sysroot=yes -c 1.c  


My actual configure commands are a bit longer:

  $ /src/gcc/configure -host i686-pc-cygwin -target sparc-sun-solaris2.10 -verbo
se -without-libiconv-prefix -disable-nls -disable-intl -disable-po -with-gnu-as
-with-gnu-ld -disable-bootstrap -enable-threads -enable-rpath -enable-cld -enabl
e-version-specific-runtime-libs -disable-checking -disable-win32-registry -enabl
e-64-bit-bfd -with-sysroot -enable-languages=c,c++


and

  $ /src/gcc/configure -host sparc-sun-solaris2.10 -target sparc-sun-solaris2.10
 -verbose -without-libiconv-prefix -disable-nls -disable-intl -disable-po -with-
gnu-as -with-gnu-ld -disable-bootstrap -enable-threads -enable-rpath -enable-cld
 -enable-version-specific-runtime-libs -disable-checking -disable-win32-registry
 -enable-64-bit-bfd -with-build-sysroot -enable-languages=c,c++

Note that I don't really want -with-build-sysroot, not for compiling and 
linking the target libraries.
I was trying to point fixincludes at the correct files.
Not that fixincludes hasn't already run as part of the cross build.

Workaround could be, like:
  -with-build-sysroot=/u

RE: gcj/sparc64?

[Jay]

Sorry Tom, I find opening bugs often tedious..sign up an account, fill in a 
bunch of fields..
I'll try to get more details "later" (if it repros consistently, callstack in a 
debugger) 
 
 - Jay

> To: Jayk 
> CC: gcc 
> Subject: Re: gcj/sparc64? 
> From: Tom  
> Date: Thu, 24 Jul 2008 08:49:13 -0600 
> 
>> Jay writes:
> 
> Jay> This is an incomplete bug report.
> Jay> unified gcc 4.3.1/binutils 2.18/gmp/mpfr tree: 
> Jay> -bash-3.00$ gcc -v 
> Jay> Using built-in specs. 
> Jay> Target: sparc-sun-solaris2.10 
> 
> [...]
> Jay> /.libs/HTML_401F.o 
> Jay> gcj: Internal error: Segmentation Fault (program jc1) 
> Jay> Please submit a full bug report. 
> 
> Knowing this particular file, maybe gcj just ran out of memory.
> Anyway, please file in bugzilla. If you can include a jc1 stack
> trace, that would be helpful.