Re: Incomplete instatitiation of virtual registers

[Martin Koegler]

On Tue, May 03, 2005 at 05:44:47PM -0700, James E Wilson wrote:
> Martin Koegler wrote:
> >I notice, that your last change in function.c forgets virtual
> >registers in the RTL in some conditions. In older version (the last I used 
> >was 20050412),
> >this has not happend.
> 
> Patches should go to gcc-patches instead of the gcc list.
> 
> If you want us to continue accepting patches from you, then you need to 
> fill out a copyright assignment form.
> 
> Recursively calling instantiate_virtual_regs_in_insn does not look 
> right.  We need a better explanation of what is going wrong here.  Since 
> we don't have a copy of your port, you will have to explain in detail 
> what happens as virtual register instantiation is happening, in order to 
> explain how this occurs.  Normally, we would ask for a testcase, but 
> that won't work in this case.

In that case, I didn't want to get this patch in GCC. In only wanted to
inform, that the code forgets some registers and that a rerun of 
instantiate_virtual_regs_in_insn solves the problem. I don't know, 
if a bug report is ok in such a case (as I have not reproduced it in
a offical version), so I send a mail to Richard Henderson, who did
the last change with CC to the GCC list.

> It is also possible that this is a bug in your port, if you are 
> accidentally emitting the virtual register yourself somehow during or 
> after virtual register instantiation.

I discovered the problem, while running a regression test, after
I have updated the GCC core. Many compilations failed in
refers_to_regno_for_reload_p. It turned out, that the instantiations
forget some registers. Adding the two lines of code, it worked again.

For that instruction, instantiate_virtual_regs_in_insn
enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS 
is entered, where if (safe_insn_predicate (insn_code, 1, new) is entered.
It then jumps to verify, without changing the destination, because it is
MEM expression. After the verify label, no more change of the destination will 
happen.

As far as I have seen, instantiate_virtual_regs_in_insn is called
for each instruction only once.

Richard Henderson wrote:
> I'd like to see the define_insn for {addhi3}.  I'm a bit confused as
> to how I could have missed iterating over what appears like it ought
> to be match_operand 0.

(define_insn_and_split "addhi3"
[(set (match_operand:HI 0 "regmemptne_operand" "=&rATQ,&rRBU,&rRBU")
  (plus:HI
(match_operand:HI 1 "regmemimmpt_operand" "rATQi,0,rATQI")
(match_operand:HI 2 "regmemimmst_operand" "rRBUi,rRBUi,0")
))]
)


I put the patches and new files for the m68hc05 Port again CVS Versions
of GCC, Binutils, GDB and newlib of 20050501 at:
http://www.auto.tuwien.ac.at/~mkoegler/m68hc05/m68hc05.tar.gz (120k)

It is a development shapshot and requires still a lot of work.
I have some not yet published documenations about the internals of the GCC port 
(predicates, constraints,...),
if it is needed.

Patching and compiling everything, except GCC, is described at
http://www.auto.tuwien.ac.at/~mkoegler/index.php/bcus and nested pages.

For compiling m68hc05-gcc, a patch (gcc.patch) plus the files in 
gcc/config/m68hc05 are needed.
(In addition to config.sub.patch for adding the processor)

mfg Martin Kögler
[EMAIL PROTECTED]

Re: Incomplete instatitiation of virtual registers

[Richard Henderson]

On Wed, May 04, 2005 at 09:50:49AM +0200, Martin Koegler wrote:
> For that instruction, instantiate_virtual_regs_in_insn
> enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS 
> is entered, where if (safe_insn_predicate (insn_code, 1, new) is entered.
> It then jumps to verify, without changing the destination, because it is
> MEM expression. After the verify label, no more change of the destination
> will happen.

Ah, yes.  Try the following patch.


r~




Index: function.c
===
RCS file: /cvs/gcc/gcc/gcc/function.c,v
retrieving revision 1.620
diff -u -p -r1.620 function.c
--- function.c  4 May 2005 01:38:14 -   1.620
+++ function.c  4 May 2005 08:01:11 -
@@ -1317,7 +1317,7 @@ instantiate_virtual_regs_in_insn (rtx in
 {
   HOST_WIDE_INT offset;
   int insn_code, i;
-  bool any_change;
+  bool any_change = false;
   rtx set, new, x, seq;
 
   /* There are some special cases to be handled first.  */
@@ -1374,6 +1374,7 @@ instantiate_virtual_regs_in_insn (rtx in
}
 
   extract_insn (insn);
+  insn_code = INSN_CODE (insn);
 
   /* Handle a plus involving a virtual register by determining if the
 operands remain valid if they're modified in place.  */
@@ -1387,7 +1388,9 @@ instantiate_virtual_regs_in_insn (rtx in
  offset += INTVAL (recog_data.operand[2]);
 
  /* If the sum is zero, then replace with a plain move.  */
- if (offset == 0)
+ if (offset == 0
+ && REG_P (SET_DEST (set))
+ && REGNO (SET_DEST (set)) > LAST_VIRTUAL_REGISTER)
{
  start_sequence ();
  emit_move_insn (SET_DEST (set), new);
@@ -1400,7 +1403,6 @@ instantiate_virtual_regs_in_insn (rtx in
}
 
  x = gen_int_mode (offset, recog_data.operand_mode[2]);
- insn_code = INSN_CODE (insn);
 
  /* Using validate_change and apply_change_group here leaves
 recog_data in an invalid state.  Since we know exactly what
@@ -1411,15 +1413,17 @@ instantiate_virtual_regs_in_insn (rtx in
  *recog_data.operand_loc[1] = recog_data.operand[1] = new;
  *recog_data.operand_loc[2] = recog_data.operand[2] = x;
  any_change = true;
- goto verify;
+
+ /* Fall through into the regular operand fixup loop in
+order to take care of operands other than 1 and 2.  */
}
}
 }
   else
-extract_insn (insn);
-
-  insn_code = INSN_CODE (insn);
-  any_change = false;
+{
+  extract_insn (insn);
+  insn_code = INSN_CODE (insn);
+}
 
   /* In the general case, we expect virtual registers to appear only in
  operands, and then only as either bare registers or inside memories.  */
@@ -1503,7 +1507,6 @@ instantiate_virtual_regs_in_insn (rtx in
   any_change = true;
 }
 
- verify:
   if (any_change)
 {
   /* Propagate operand changes into the duplicates.  */

Re: volatile semantics

[Nathan Sidwell]

Dale Johannesen wrote:
And we don't have to document the behavior at all; it is not documented 
now.
I disagree.  It's not documented explicitly in gcc now, because it is doing
what the std permits, and so documented there. We should document either
a) that current gcc is not breaking the std, and Mike's example is invalid
code, if one expects a volatile read.  This would be a FAQ like thing.
b) amend the compiler to do a volatile read, and document the extension.
This should go in extend.texi
Documentation for (b) is necessary so that programmers can rely on the
extension (and understand why some other compiler might not do what they
want) _and_ so that gcc maintainers know about it.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Incomplete instatitiation of virtual registers

[Martin Koegler]

On Wed, May 04, 2005 at 01:02:18AM -0700, Richard Henderson wrote:
> On Wed, May 04, 2005 at 09:50:49AM +0200, Martin Koegler wrote:
> > For that instruction, instantiate_virtual_regs_in_insn
> > enters if(set), then if (GET_CODE (SET_SRC (set)) == PLUS 
> > is entered, where if (safe_insn_predicate (insn_code, 1, new) is entered.
> > It then jumps to verify, without changing the destination, because it is
> > MEM expression. After the verify label, no more change of the destination
> > will happen.
> 
> Ah, yes.  Try the following patch.

For the test case, I analyzed, this patch works. I have started a regression 
test.
Will take some time, before I can tell you the final result.

mfg Martin Kögler

restrict and char pointers

[Jeroen Dobbelaere]

Hi,

I have a question concerning '__restrict__' :

With gcc-4.0.0 (-O3 -fomit-frame-pointer, on i686), following piece of code :


void test_1(unsigned long* __restrict__ bar, unsigned long* __restrict__ bas)
{
  unsigned long tmp = *bar;
  *bas = 0;
  *bar = tmp;
}

void test_2(unsigned long* __restrict__ bar, char* __restrict__ bas)
{
  unsigned long tmp = *bar;
  *bas = 0;
  *bar = tmp;
}


compiles to :

_Z6test_1PmS_:
movl8(%esp), %edx
movl$0, (%edx)
ret


_Z6test_2PmPc:
movl4(%esp), %eax
movl8(%esp), %edx
movl(%eax), %ecx
movb$0, (%edx)
movl%ecx, (%eax)
ret



I would expect that the second case compiles to :
movl8(%esp), %edx
movb$0, (%edx)
ret


Greetings,
-- 
Jeroen Dobbelaere

Re: volatile semantics

[Andrew Haley]

Nathan Sidwell writes:
 > Dale Johannesen wrote:
 > 
 > > And we don't have to document the behavior at all; it is not documented 
 > > now.
 > I disagree.  It's not documented explicitly in gcc now, because it is doing
 > what the std permits, and so documented there. We should document either
 > 
 > a) that current gcc is not breaking the std, and Mike's example is invalid
 > code, if one expects a volatile read.  This would be a FAQ like thing.
 > 
 > b) amend the compiler to do a volatile read, and document the extension.
 > This should go in extend.texi
 > 
 > Documentation for (b) is necessary so that programmers can rely on the
 > extension (and understand why some other compiler might not do what they
 > want) _and_ so that gcc maintainers know about it.

And it is difficult to specify exactly where volatile casts should be
preserved and where they may legitimately be optimized away, so we may
well make mistakes in doing so, and end up with an ill-defined
extension.  The C Standard already has well-defined semantics for
this, and we are not AFAIAA in the business of redesigning C.  What
matters is the volatility of the _object_, and this is at least
reasonably easy to understand.

This is a bad extension to gcc and will cause much trouble, just like
the old guarantee to preserve empty loops.

Andrew.

Re: GCC 4.1: Buildable on GHz machines only?

[Andrew Haley]

Joe Buck writes:
 > On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote:
 > > At this point, it doesn't feel like switching to 1.5.16 is worth the
 > > effort.  2.0 should be far more maintainable, and hopefully
 > > significantly more efficient on hosts where the use of shell functions
 > > optimized for properties of the build machine and/or the host
 > > machine can bring us such improvement.
 > 
 > > Thoughts?
 > 
 > Richard Henderson showed that the libjava build spends 2/3 of its time
 > in libtool, and that his hand-hacked (but not portable) modification to
 > invoke the appropriate binutils commands directly gave a huge speedup.

Yes, but please bear in mind that this *only* happens when you have a
machine with huge RAM.  For other people with small RAM, the link
itself is an important factor.  Also, other people have found that the
libtool script consumes a smaller part of total execution time: rth's
measurements are at one extreme of the scale.

Andrew.

Re: Packing booleans?

[Nathan Sidwell]

Sam Lauber wrote:
Would it be possible to have a -fpack-bools option that packs booleans into
the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register
(or memory, as the case may be)?
why would you want to do this?  Seems to me you might save up to 7 bytes
of data memory at a vastly greater expansion of code size and reduction
in performance.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: volatile semantics

[Gabriel Dos Reis]

Andrew Haley <[EMAIL PROTECTED]> writes:

| Nathan Sidwell writes:
|  > Dale Johannesen wrote:
|  > 
|  > > And we don't have to document the behavior at all; it is not documented 
|  > > now.
|  > I disagree.  It's not documented explicitly in gcc now, because it is doing
|  > what the std permits, and so documented there. We should document either
|  > 
|  > a) that current gcc is not breaking the std, and Mike's example is invalid
|  > code, if one expects a volatile read.  This would be a FAQ like thing.

I vote for (a).

[...]

| This is a bad extension to gcc and will cause much trouble, just like
| the old guarantee to preserve empty loops.

Hear, hear, hear.

-- Gaby

gij problem (3.4.4)

[Thorsten Glaser]

Hello,

I've got Java classes from source ("99 bottles of beer") compiled
to bytecode and from source or bytecode to a dynamically linked
executable working just fine, also Sun's JDK works on the generated
bytecode - however, gij does not, even without boehm-gc (which
prevented it from working before):

[EMAIL PROTECTED]:/home/tg/tmp $ gdb --args /usr/bin/gij bottles
GNU gdb 6.3.50.20050107
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-ecce-mirbsd8"...(no debugging symbols found)

(gdb) r
Starting program: /usr/bin/gij bottles
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)

Program received signal SIGSEGV, Segmentation fault.
0x02b88fa6 in _Jv_ClassReader::handleFieldsEnd () from /usr/lib/libgcj.so.5.0
(gdb) bt
#0  0x02b88fa6 in _Jv_ClassReader::handleFieldsEnd () from 
/usr/lib/libgcj.so.5.0
#1  0x02b8c408 in _Jv_ClassReader::read_fields () from /usr/lib/libgcj.so.5.0
#2  0x02b8c749 in _Jv_ClassReader::parse () from /usr/lib/libgcj.so.5.0
#3  0x02b8c974 in _Jv_DefineClass () from /usr/lib/libgcj.so.5.0
#4  0x02bab6eb in java::lang::VMClassLoader::defineClass () from 
/usr/lib/libgcj.so.5.0
#5  0x02bbb57a in java::lang::ClassLoader::defineClass () from 
/usr/lib/libgcj.so.5.0
#6  0x02cb6e37 in java::security::SecureClassLoader::defineClass () from 
/usr/lib/libgcj.so.5.0
#7  0x02c9d201 in java::net::URLClassLoader::findClass () from 
/usr/lib/libgcj.so.5.0
#8  0x02ba34e6 in gnu::gcj::runtime::VMClassLoader::findClass () from 
/usr/lib/libgcj.so.5.0
#9  0x02bbb748 in java::lang::ClassLoader::loadClass () from 
/usr/lib/libgcj.so.5.0
#10 0x02babae4 in _Jv_FindClass () from /usr/lib/libgcj.so.5.0
#11 0x02bab32b in java::lang::Class::forName () from /usr/lib/libgcj.so.5.0
#12 0x02bab44d in java::lang::Class::forName () from /usr/lib/libgcj.so.5.0
#13 0x02c27199 in gnu::gcj::runtime::FirstThread::run () from 
/usr/lib/libgcj.so.5.0
#14 0x02bb1962 in _Jv_ThreadRun () from /usr/lib/libgcj.so.5.0
#15 0x02b7d998 in _Jv_RunMain () from /usr/lib/libgcj.so.5.0
#16 0x1c000ade in ?? ()
#17 0x1c000870 in ?? ()
#18 0x0002 in ?? ()
#19 0xcfbf4540 in ?? ()
#20 0xcfbf454c in ?? ()
#21 0x1c000d40 in ?? ()
#22 0x in ?? ()
(gdb) disas 0x02b88fa6
Dump of assembler code for function _ZN15_Jv_ClassReader15handleFieldsEndEv:
0x02b88ea8 <_ZN15_Jv_ClassReader15handleFieldsEndEv+0>: push   %ebp
0x02b88ea9 <_ZN15_Jv_ClassReader15handleFieldsEndEv+1>: mov%esp,%ebp
0x02b88eab <_ZN15_Jv_ClassReader15handleFieldsEndEv+3>: push   %edi
0x02b88eac <_ZN15_Jv_ClassReader15handleFieldsEndEv+4>: push   %esi
0x02b88ead <_ZN15_Jv_ClassReader15handleFieldsEndEv+5>: sub$0x40,%esp
0x02b88eb0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+8>: mov0x8(%ebp),%eax
0x02b88eb3 <_ZN15_Jv_ClassReader15handleFieldsEndEv+11>:movl   
$0x0,0xffe0(%ebp)
0x02b88eba <_ZN15_Jv_ClassReader15handleFieldsEndEv+18>:mov
%eax,0xffe4(%ebp)
0x02b88ebd <_ZN15_Jv_ClassReader15handleFieldsEndEv+21>:mov
0x1c(%eax),%edx
0x02b88ec0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+24>:movswl 
0x34(%edx),%eax
0x02b88ec4 <_ZN15_Jv_ClassReader15handleFieldsEndEv+28>:lea
0x(%eax),%esi
0x02b88ec7 <_ZN15_Jv_ClassReader15handleFieldsEndEv+31>:mov
0x80(%edx),%ecx
0x02b88ecd <_ZN15_Jv_ClassReader15handleFieldsEndEv+37>:cmp
%esi,0xffe0(%ebp)
0x02b88ed0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+40>:mov
0x2c(%edx),%edi
0x02b88ed3 <_ZN15_Jv_ClassReader15handleFieldsEndEv+43>:mov
%ecx,0xffdc(%ebp)
0x02b88ed6 <_ZN15_Jv_ClassReader15handleFieldsEndEv+46>:jge
0x2b88fa0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+248>
0x02b88edc <_ZN15_Jv_ClassReader15handleFieldsEndEv+52>:mov
0xffe0(%ebp),%eax
0x02b88edf <_ZN15_Jv_ClassReader15handleFieldsEndEv+55>:shl$0x4,%eax
0x02b88ee2 <_ZN15_Jv_ClassReader15handleFieldsEndEv+58>:testb  
$0x8,0x8(%eax,%edi,1)
0x02b88ee7 <_ZN15_Jv_ClassReader15handleFieldsEndEv+63>:je 
0x2b88fc8 <_ZN15_Jv_ClassReader15handleFieldsEndEv+288>
0x02b88eed <_ZN15_Jv_ClassReader15handleFieldsEndEv+69>:incl   
0xffe0(%ebp)
0x02b88ef0 <_ZN15_Jv_ClassReader15handleFieldsEndEv+72>:cmp
%esi,0xffe0(%ebp)
0x02b88ef3 <_ZN15_Jv_ClassReader15handleFieldsEndEv+75>:jl 
0x2b88edc <_ZN15_Jv_ClassReader15handleFieldsEndEv+52>
0x02b88ef5 <_ZN15_Jv_ClassReader15handleFieldsEndEv+77>:lea
0x0(%esi),%esi
0x02b88ef8 <_ZN15_Jv_ClassReader15handleFieldsEndEv+80>:cmp
%esi,0xffe0(%ebp)
0x02b88efb <_ZN15_

Re: gij problem (3.4.4)

[Andrew Haley]

Thorsten Glaser writes:
 > 
 > 
 > A quick look into CVSweb shows me _Jv_ClassReader::handleFieldsEnd ()
 > is still the same as in 3.4.4. Does anyone have an idea where this
 > SIGSEGV could come from?

No, but I do know that I would not even attempt to start looking at
this with no debugging info in libgcj.  libgcj builds by default with
full debugging info, so something (someone) must have removed it.

Andrew.

Re: [gomp] OpenMP IL design notes

[Biagio Lucini]

On Tuesday 03 May 2005 21.16, Diego Novillo wrote:
>
> On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
>
> >   we have to extend the gfortran internal representation also
>
> Yes, initially most of the effort will be in C/C++ since that's
> the only parser we have so far.
>

Is there any obstruction in principle to have the so-called sentinel directive
(!$OMP) recognised by the gfortran parser? Talking with Lars, I have 
understood that at the moment some misbehaviour of the front-end prevents it, 
but I don't quite understand what the problem is. Can anyone shed some light?

Also, talking about IR, since OpenMP is mostly unique, probably we just need 
to link the gfortran parser to the work in the middle-end that is currently 
being done, with perhaps a few (hopefully no) exception.

Biagio

Re: Packing booleans?

[Nix]

On 4 May 2005, Sam Lauber stipulated:
> Would it be possible to have a -fpack-bools option that packs booleans into
> the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register
> (or memory, as the case may be)?

How could you do that without breaking the semantics of the program?

Among other things, you couldn't take the address of such a packed
boolean: if the idea is to quietly suppress boolean packing for booleans
whose address is taken, then this will suppress packing for any boolean
shared between translation units, or possibly even between procedures.

-- 
`End users are just test loads for verifying that the system works, kind of
 like resistors in an electrical circuit.' - Kaz Kylheku in c.o.l.d.s

Re: Packing booleans?

[Mattias Karlsson]

On Wed, 4 May 2005, Nathan Sidwell wrote:
Sam Lauber wrote:
Would it be possible to have a -fpack-bools option that packs booleans into
the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a 
register
(or memory, as the case may be)?
why would you want to do this?  Seems to me you might save up to 7 bytes
of data memory at a vastly greater expansion of code size and reduction
in performance.
Unless you are using an architecture with btst, bset, bclr instructions.

Re: Packing booleans?

[Richard Guenther]

On 5/4/05, Sam Lauber <[EMAIL PROTECTED]> wrote:
> Would it be possible to have a -fpack-bools option that packs booleans into
> the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a register
> (or memory, as the case may be)?

Why don't you use bitfields then?

Richard.

Re: Packing booleans?

[Nathan Sidwell]

Mattias Karlsson wrote:
On Wed, 4 May 2005, Nathan Sidwell wrote:
Sam Lauber wrote:
Would it be possible to have a -fpack-bools option that packs 
booleans into
the smallest form possible (8 booleans -> 1 8-bit reg, etc.) into a 
register
(or memory, as the case may be)?

why would you want to do this?  Seems to me you might save up to 7 bytes
of data memory at a vastly greater expansion of code size and reduction
in performance.

Unless you are using an architecture with btst, bset, bclr instructions.
True, they'd have to have memory operands to be a win though. Otherwise it'd
be a
load
bset
store
or
load
btst
sequence, rather than
store
or
load
Of course, one might be able to amortize the load and store over several
bit operations, but you'd still end up with at least one extra instruction
over not packing, and that will cost you 4 bytes (or thereabouts).
If this were being done at the level of register allocation, why would
one need a user visible option?  'Just' rearrange the register file to look
like a set of single bit registers overlaid on a more conventional register
file.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: [gomp] OpenMP IL design notes

[Diego Novillo]

On Wed, May 04, 2005 at 12:15:18PM +, Biagio Lucini wrote:

> Also, talking about IR, since OpenMP is mostly unique, probably
> we just need to link the gfortran parser to the work in the
> middle-end that is currently being done, with perhaps a few
> (hopefully no) exception.
> 
Yes, the FEs emit GENERIC.  Lowering and code generation is all
common code.  Some constructs like workshare will only be
generated by Fortran, but that will also be handled by common
code.


Diego.

Re: C54x port: some general technical questions

[Paul Koning]

> "James" == James E Wilson  writes:

 James> Jonathan Bastien-Filiatrault wrote:
 >> * We have defined BIT_PER_WORD to 16 and UNITS_PER_WORD to 1. On
 >> this DSP, there are two 40-bits accumulators. How do we make GCC
 >> take advantage of this and which machine mode do we use ?

 James> GCC has little support for non-power-of-2 sized
 James> accumulators. 

I wonder if the work-in-progress PDP10 port
(http://pdp10.nocrew.org/gcc/) might help with this.

  paul

Re: gij problem (3.4.4)

[Thorsten Glaser]

Andrew Haley dixit:

>No, but I do know that I would not even attempt to start looking at
>this with no debugging info in libgcj.  libgcj builds by default with
>full debugging info, so something (someone) must have removed it.

Yes, our libraries are stripped by default. I can build one with
full debugging information (and, if requested, -O0) if someone
wants to help looking into this. I don't have much experience
with either Java(TM) or gdb myself, though.

//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: [gomp] OpenMP IL design notes

[Paul Brook]

On Wednesday 04 May 2005 13:15, Biagio Lucini wrote:
> On Tuesday 03 May 2005 21.16, Diego Novillo wrote:
> > On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
> > >   we have to extend the gfortran internal representation also
> >
> > Yes, initially most of the effort will be in C/C++ since that's
> > the only parser we have so far.
>
> Is there any obstruction in principle to have the so-called sentinel
> directive (!$OMP) recognised by the gfortran parser?

I have no objections. It'd be nice to have OpenMP support, but it's not 
currently a high priority for me.

> Talking with Lars, I 
> have understood that at the moment some misbehaviour of the front-end
> prevents it, but I don't quite understand what the problem is. Can anyone
> shed some light?

Basically the fortran parser does trial-and-error pattern matching, and can 
end up parsing a single comment many times.

Paul

Re: GCC 4.1: Buildable on GHz machines only?

[H. J. Lu]

On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
> Joe Buck writes:
>  > On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote:
>  > > At this point, it doesn't feel like switching to 1.5.16 is worth the
>  > > effort.  2.0 should be far more maintainable, and hopefully
>  > > significantly more efficient on hosts where the use of shell functions
>  > > optimized for properties of the build machine and/or the host
>  > > machine can bring us such improvement.
>  > 
>  > > Thoughts?
>  > 
>  > Richard Henderson showed that the libjava build spends 2/3 of its time
>  > in libtool, and that his hand-hacked (but not portable) modification to
>  > invoke the appropriate binutils commands directly gave a huge speedup.
> 
> Yes, but please bear in mind that this *only* happens when you have a
> machine with huge RAM.  For other people with small RAM, the link
> itself is an important factor.  Also, other people have found that the
> libtool script consumes a smaller part of total execution time: rth's
> measurements are at one extreme of the scale.
> 

We have been working on linker speed. If you have a number to show
that the GNU linker is very slow on certain things, I will take a
look.


H.J.

Re: GCC 4.1: Buildable on GHz machines only?

[Andrew Haley]

H. J. Lu writes:
 > On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
 > > Joe Buck writes:
 > >  > On Tue, May 03, 2005 at 04:57:10PM -0300, Alexandre Oliva wrote:
 > >  > > At this point, it doesn't feel like switching to 1.5.16 is worth the
 > >  > > effort.  2.0 should be far more maintainable, and hopefully
 > >  > > significantly more efficient on hosts where the use of shell functions
 > >  > > optimized for properties of the build machine and/or the host
 > >  > > machine can bring us such improvement.
 > >  > 
 > >  > > Thoughts?
 > >  > 
 > >  > Richard Henderson showed that the libjava build spends 2/3 of its time
 > >  > in libtool, and that his hand-hacked (but not portable) modification to
 > >  > invoke the appropriate binutils commands directly gave a huge speedup.
 > > 
 > > Yes, but please bear in mind that this *only* happens when you have a
 > > machine with huge RAM.  For other people with small RAM, the link
 > > itself is an important factor.  Also, other people have found that the
 > > libtool script consumes a smaller part of total execution time: rth's
 > > measurements are at one extreme of the scale.
 > 
 > We have been working on linker speed. If you have a number to show
 > that the GNU linker is very slow on certain things, I will take a
 > look.

I haven't, no.  Ian Taylor reported the problem.

Andrew.

Re: gij problem (3.4.4)

[Andrew Haley]

Thorsten Glaser writes:
 > Andrew Haley dixit:
 > 
 > >No, but I do know that I would not even attempt to start looking at
 > >this with no debugging info in libgcj.  libgcj builds by default with
 > >full debugging info, so something (someone) must have removed it.
 > 
 > Yes, our libraries are stripped by default. I can build one with
 > full debugging information (and, if requested, -O0) if someone
 > wants to help looking into this. I don't have much experience
 > with either Java(TM) or gdb myself, though.

In which case it would be best to post a bug report at
gcc.gnu.org/bugzilla and attach both source and class files.

Andrew.

gcc 3.4.2 stack variable lifetime analysis

[Earl Chew]

Can anyone tell me if there is a patch for this problem?
Consider:
void bar(char*);
void foo(int x)
{
if (x) { char y[4096]; bar(y); }
else   { char z[4096]; bar(z); }
}
Cygwin gcc 3.4.2 -O2 yields:
pushl   %ebp
movl$8216, %eax   /* Should be about 4k */
movl%esp, %ebp
call__alloca
PPC cross compiler 3.4.2 -O2 yields:
cmpwi 7,3,0
mflr 0
stwu 1,-8208(1)  /* Should be about 4k */
Earl

operand swapping in get_expr_operands.

[Andrew MacLeod]

Why is it we try to swap operands in get_expr_operands, where we are
otherwise simply parsing not modifying?

/* If it would be profitable to swap the operands, then do so to
   canonicalize the statement, enabling better optimization.
   By placing canonicalization of such expressions here we
   transparently keep statements in canonical form, even
   when the statement is modified.  */


Is this statement still true? and if so, who is counting on it?  DOM? 
And does it need to be done in update_stmt?  Its been a minor wart
everytime I turn around that we are modifying the stmt when in the
middle of building operands. I'm curious if we still need to do it here,
now its making comparing operands more difficult.

I believe it basically attempts to have the first operand of a pair be
the lower ssa_name index... ie, so commutative or comparision pairs are
sorted. 

Andrew

Re: gcc 3.4.2 stack variable lifetime analysis

[Steven Bosscher]

On Wednesday 04 May 2005 16:22, Earl Chew wrote:
> Can anyone tell me if there is a patch for this problem?

The patch is called GCC 4.0.

Gr.
Steven

Re: gcc 3.4.2 stack variable lifetime analysis

[Jakub Jelinek]

On Wed, May 04, 2005 at 07:22:12AM -0700, Earl Chew wrote:
> Can anyone tell me if there is a patch for this problem?

Yes, there is:
ftp://sources.redhat.com/pub/gcc/releases/gcc-4.0.0/diffs/gcc-3.4.3-4.0.0.diff.bz2

FYI, this is PR middle-end/9997

> Consider:
> 
> void bar(char*);
> 
> void foo(int x)
> {
> if (x) { char y[4096]; bar(y); }
> else   { char z[4096]; bar(z); }
> }
> 
> Cygwin gcc 3.4.2 -O2 yields:
> 
> pushl   %ebp
> movl$8216, %eax   /* Should be about 4k */
> movl%esp, %ebp
> call__alloca
> 
> PPC cross compiler 3.4.2 -O2 yields:
> 
> cmpwi 7,3,0
> mflr 0
> stwu 1,-8208(1)  /* Should be about 4k */

Jakub

Can't build 3.3.5 without getting java?

[Hugh Sasse]

I'm trying to bring an old machine (Solaris 2.5.1, Sparc, Sun4c) up
to date.  It has been my experience that I can't build GCC with a
version of gcc that is too old.  Thus, to reach gcc-3.4.3 I'm trying
to build gcc-3.3.5 first, with 2.95.2
I have a build script 


#!/bin/sh -x
PATH=/bin:/usr/sbin:/usr/ccs/bin:/etc:/usr/local/bin:/opt/sfw/bin:/usr/openwin/bin
export PATH
CONFIG_SHELL=/bin/sh
export CONFIG_SHELL
BUILDINGVER=3.3.5
BUILD_DIR=/apps/hgs/gcc-build
GCC_SOURCE_DIR=/apps/hgs/gcc-${BUILDINGVER}
# CC="/progs/SUNWspro/bin/cc -xildoff -xarch=v9" options only needed
# for 64 bit...
# CC="/progs/SUNWspro/bin/cc"
CC=gcc
export CC
CXX=g++
export CXX
MAKE=/usr/local/bin/gmake
export MAKE
ASOPT="--with-as=/usr/local/bin/as"
LDOPT="--with-ld=/usr/local/bin/ld"
# LANGOPT="--enable-languages=c,c++,f77,java,objc"
LANGOPT="--enable-languages=c,c++,f77"
cd $BUILD_DIR
/bin/rm -rf ./*
${GCC_SOURCE_DIR}/configure $ASOPT $LDOPT $LANGOPTS --disable-nls \
--with-local-prefix=/tmp/gcc-local --without-libjava --without-gcj
&& \
# gmake --jobs=5 bootstrap-lean && \
gmake  bootstrap-lean && \
gmake check

But it insists on building libjava and doing work with gcj --

make[2]: Entering directory
`/apps/hgs/gcc-build/sparc-sun-solaris2.5.1/libjava'
/apps/hgs/gcc-build/gcc/gcj
-B/apps/hgs/gcc-build/sparc-sun-solaris2.5.1/libjava/
-B/apps/hgs/gcc-build/gcc/ --encoding=UTF-8 -C -g -classpath ''
-bootclasspath
/apps/hgs/gcc-build/sparc-sun-solaris2.5.1/libjava:/apps/hgs/gcc-3.3.5/libjava
\
 -d /apps/hgs/gcc-build/sparc-sun-solaris2.5.1/libjava 
/apps/hgs/gcc-3.3.5/libjava/java/lang/Class.java

and so forth.
This takes abour 5 hours, gmake check fails, and I don't need
anything java and didn't ask for it.  What options should I be using
for this?  --disable-libjava, perhaps?
Why isn't --enable-languages=c,c++,f77 sufficient to stop this?
I stuck the --without options on the command line as an attempt to
stop this, but it will take another 5 hours to try any alternatives.
I'd appreciate it if someone could save me waiting another 5 hours
for another failure
   Thank you,
   Hugh

Re: operand swapping in get_expr_operands.

[Jeffrey A Law]

On Wed, 2005-05-04 at 10:28 -0400, Andrew MacLeod wrote:
> Why is it we try to swap operands in get_expr_operands, where we are
> otherwise simply parsing not modifying?
> 
> /* If it would be profitable to swap the operands, then do so to
>canonicalize the statement, enabling better optimization.
>By placing canonicalization of such expressions here we
>transparently keep statements in canonical form, even
>when the statement is modified.  */
> 
> 
> Is this statement still true? and if so, who is counting on it?  DOM? 
> And does it need to be done in update_stmt?  Its been a minor wart
> everytime I turn around that we are modifying the stmt when in the
> middle of building operands. I'm curious if we still need to do it here,
> now its making comparing operands more difficult.
Any code which is hashing expressions is probably dependent on this
to some extent.

> I believe it basically attempts to have the first operand of a pair be
> the lower ssa_name index... ie, so commutative or comparision pairs are
> sorted. 
That's its primary purpose -- to ensure that SSA_NAMEs appear in a 
predictable order within an expression.

An alternate approach would be to twiddle the hashing code -- that works
OK for commutative operands, but not necessarily for things like LT_EXPR
where putting things into canonical form involves changing the tree 
code.

jeff

g++, initialization of Array if its is a class member.

[Wlodzimierz Lipert]

Hi!

template < typename T, int S >
class A{

public:
T _V[S ];
int a;
}

template < typename T >
class B : public A< T, 2 /* const */ >
{
B( T t ) : A::V[0]( t ), A::V[1] /* ERROR reported by
compiler. Why? */
, a( 1 ) /* no error */ {};

B( T t1, T t2 ){
A::V[0] = t1; // no error.
}

};

It apears that index operator [] is not treated properly during initialization.

Re: g++, initialization of Array if its is a class member.

[Wlodzimierz Lipert]

 Hi! A little mistake during copy/paste. :)
 
 template < typename T, int S >
 class A{
 
 public:
 T _V[S ];
 int a;
 }
 
 template < typename T >
 class B : public A< T, 2 /* const */ >
 {
 B( T t ) : A::V[0]( t ), A::V[1] ( t ) /* ERROR reported by
 compiler. Why? */
 , a( 1 ) /* no error */ {};
 
 B( T t1, T t2 ){
 A::V[0] = t1; // no error.
 }

 };
 
 It apears that index operator [] is not treated properly during initialization.

Re: operand swapping in get_expr_operands.

[Andrew MacLeod]

On Wed, 2005-05-04 at 11:07, Jeffrey A Law wrote:
> On Wed, 2005-05-04 at 10:28 -0400, Andrew MacLeod wrote:
> > Why is it we try to swap operands in get_expr_operands, where we are
> > otherwise simply parsing not modifying?
> > 
> > /* If it would be profitable to swap the operands, then do so to
> >canonicalize the statement, enabling better optimization.
> >By placing canonicalization of such expressions here we
> >transparently keep statements in canonical form, even
> >when the statement is modified.  */
> > 

> An alternate approach would be to twiddle the hashing code -- that works
> OK for commutative operands, but not necessarily for things like LT_EXPR
> where putting things into canonical form involves changing the tree 
> code.

I'll leave it as is for now. It seriously uglified the stmt verifier
tho, as it has to look for swapped operands :-)

Oh well.

Andrew

Re: g++, initialization of Array if its is a class member.

[Jonathan Wakely]

On Wed, May 04, 2005 at 05:18:56PM +0200, Wlodzimierz Lipert wrote:

>  Hi! A little mistake during copy/paste. :)
>  
>  template < typename T, int S >
>  class A{
>  
>  public:
>  T _V[S ];
>  int a;
>  }

You're missing a ';' here.

>  
>  template < typename T >
>  class B : public A< T, 2 /* const */ >
>  {
>  B( T t ) : A::V[0]( t ), A::V[1] ( t ) /* ERROR reported by

This is not legal C++

The initialisation list must name base classes and members.

A::V is not a member of B, so cannot be initialised here.
A::V[0] is also not a member, and you cannot initialise the
elements of an array like this anyway.

>  compiler. Why? */
>  , a( 1 ) /* no error */ {};

Are you sure?  This is an error. 'a' is not a member of B.

>  
>  B( T t1, T t2 ){
>  A::V[0] = t1; // no error.
>  }
> 
>  };
>  
>  It apears that index operator [] is not treated properly during 
> initialization.

-- 
"All that we are is the result of what we have thought;
 it is compounded of our thoughts, made up of our thoughts."
- Dhammapada, Verse I

Re: [gomp] OpenMP IL design notes

[Biagio Lucini]

On Wednesday 04 May 2005 13.34, Paul Brook wrote:
>
> On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
>
> > I  have understood that at the moment some misbehaviour of the front-end
> > prevents it, but I don't quite understand what the problem is. Can anyone
> > shed some light?
>
> Basically the fortran parser does trial-and-error pattern matching, and can
> end up parsing a single comment many times.
>

Is this a permanent feature or something that can be removed? The reason why I 
am asking is that I would like to experiment with this front-end a little 
bit.

Thanks
Biagio 

-- 
=

Biagio Lucini 
Institut Fuer Theoretische Physik
ETH Hoenggerberg  
CH-8093 Zuerich - Switzerland   
Tel. +41 (0)1 6332562  
 
=

Re: [gomp] OpenMP IL design notes

[Steven Bosscher]

On Wednesday 04 May 2005 17:40, Biagio Lucini wrote:
> On Wednesday 04 May 2005 13.34, Paul Brook wrote:
> > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
> >
> > > I  have understood that at the moment some misbehaviour of the
> > > front-end prevents it, but I don't quite understand what the problem
> > > is. Can anyone shed some light?
> >
> > Basically the fortran parser does trial-and-error pattern matching, and
> > can end up parsing a single comment many times.
>
> Is this a permanent feature or something that can be removed? The reason
> why I am asking is that I would like to experiment with this front-end a
> little bit.

You could rewrite the parser...  ;-)

Gr.
Steven

Re: [gomp] OpenMP IL design notes

[Paul Brook]

On Wednesday 04 May 2005 16:40, Biagio Lucini wrote:
> On Wednesday 04 May 2005 13.34, Paul Brook wrote:
> > On Wednesday 04 May 2005 13:15, Biagio Lucini wrote
> >
> > > I  have understood that at the moment some misbehaviour of the
> > > front-end prevents it, but I don't quite understand what the problem
> > > is. Can anyone shed some light?
> >
> > Basically the fortran parser does trial-and-error pattern matching, and
> > can end up parsing a single comment many times.
>
> Is this a permanent feature or something that can be removed? The reason
> why I am asking is that I would like to experiment with this front-end a
> little bit.

It's more of an implementation wart than a feature.
I don't think anyone's particularly attached to our current parser. If it 
needs significant changes to support OpenMP then I've no real objections, as 
long as it still works :-)

Paul

3rd Annual - GCC & GNU Toolchain Developers' Summit

[Andrew J. Hutton]

 Forwarded Message 
From: Andrew J. Hutton <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: 3rd Annual - GCC & GNU Toolchain Developers' Summit
Date: Wed, 04 May 2005 11:53:40 -0400
The 3rd Annual GCC & GNU Toolchain Developers' Summit will be taking
place June 22nd ~ 24th, 2005 at the Ottawa Congress Centre in Ottawa,
Canada.

We focus on providing a vendor neutral environment to encourage open
dialog, technology demonstrations, as well as long term technical
roadmap development. 

The Summit is a unique opportunity for developers and serious
enthusiasts from all over the world to meet, present their work and to
work together to advance the state of Free Software development
technology.

More information and a registration page is available at
http://www.gccsummit.org/2005 also feel free to send any questions
directly to me at ajh at gccsummit.org.

P.S. We're about half-filled now and hope to complete registration in
the next few weeks.

Please post this announcement to any relevant forum and pass it on to 
those you feel may be interested in attending the event.

Re: GCC 4.1: Buildable on GHz machines only?

[Joe Buck]

On Wed, May 04, 2005 at 06:41:59AM -0700, H. J. Lu wrote:
> On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
> > Joe Buck writes:
> >  > Richard Henderson showed that the libjava build spends 2/3 of its time
> >  > in libtool, and that his hand-hacked (but not portable) modification to
> >  > invoke the appropriate binutils commands directly gave a huge speedup.
> > 
> > Yes, but please bear in mind that this *only* happens when you have a
> > machine with huge RAM.  For other people with small RAM, the link
> > itself is an important factor.  Also, other people have found that the
> > libtool script consumes a smaller part of total execution time: rth's
> > measurements are at one extreme of the scale.
> 
> We have been working on linker speed. If you have a number to show
> that the GNU linker is very slow on certain things, I will take a
> look.

I'm glad you're looking at speeding up the linker.  Please make sure to
look at memory consumption as well, since performance falls off a cliff
once the working set exceeds physical memory.  A good test would be to
bootstrap gcc on a machine with 256M, or that is artificially limited to
256M (I seem to recall that you can tell a Linux kernel you have only a
given amount of memory).

Re: gij problem (3.4.4)

[Thorsten Glaser]

Andrew Haley dixit:

>In which case it would be best to post a bug report at
>gcc.gnu.org/bugzilla and attach both source and class files.

What for? I'm 99% sure nobody else has got the bug, since
most probably haven't even heard of the MirOS operating
system. And it's only in the latest snapshot.

The source is at http://www.99-bottles-of-beer.net//j.html#Java

//mirabile
-- 
> Hi, does anyone sell openbsd stickers by themselves and not packaged
> with other products?
No, the only way I've seen them sold is for $40 with a free OpenBSD CD.
-- Haroon Khalid and Steve Shockley in gmane.os.openbsd.misc

Re: GCC 4.1: Buildable on GHz machines only?

[H. J. Lu]

On Wed, May 04, 2005 at 09:00:05AM -0700, Joe Buck wrote:
> On Wed, May 04, 2005 at 06:41:59AM -0700, H. J. Lu wrote:
> > On Wed, May 04, 2005 at 11:23:20AM +0100, Andrew Haley wrote:
> > > Joe Buck writes:
> > >  > Richard Henderson showed that the libjava build spends 2/3 of its time
> > >  > in libtool, and that his hand-hacked (but not portable) modification to
> > >  > invoke the appropriate binutils commands directly gave a huge speedup.
> > > 
> > > Yes, but please bear in mind that this *only* happens when you have a
> > > machine with huge RAM.  For other people with small RAM, the link
> > > itself is an important factor.  Also, other people have found that the
> > > libtool script consumes a smaller part of total execution time: rth's
> > > measurements are at one extreme of the scale.
> > 
> > We have been working on linker speed. If you have a number to show
> > that the GNU linker is very slow on certain things, I will take a
> > look.
> 
> I'm glad you're looking at speeding up the linker.  Please make sure to
> look at memory consumption as well, since performance falls off a cliff
> once the working set exceeds physical memory.  A good test would be to
> bootstrap gcc on a machine with 256M, or that is artificially limited to
> 256M (I seem to recall that you can tell a Linux kernel you have only a
> given amount of memory).

Given the current hardware, I would say 512MB is a reasonable number.
If I need to more than 256M to get 5% speed up, I will take it.

BTW, for gcc 4.0, I got

11687.92user 2089.89system 2:11:43elapsed 174%CPU (0avgtext+0avgdata
0maxresident)k

for bootstrap

9710.54user 2628.79system 1:52:03elapsed 183%CPU (0avgtext+0avgdata
0maxresident)k

for "make check" on a dual P3 550MHz with 512MB with everything except
for Ada.


H.J.

Re: gij problem (3.4.4)

[Andrew Haley]

Thorsten Glaser writes:
 > Andrew Haley dixit:
 > 
 > >In which case it would be best to post a bug report at
 > >gcc.gnu.org/bugzilla and attach both source and class files.
 > 
 > What for? I'm 99% sure nobody else has got the bug, since
 > most probably haven't even heard of the MirOS operating
 > system. And it's only in the latest snapshot.

Do you have any reason to suspect this might be MirOS specific?

Andrew.

Re: GCC 4.1: Buildable on GHz machines only?

[Joe Buck]

I wrote:
> > I'm glad you're looking at speeding up the linker.  Please make sure to
> > look at memory consumption as well, since performance falls off a cliff
> > once the working set exceeds physical memory.  A good test would be to
> > bootstrap gcc on a machine with 256M, or that is artificially limited to
> > 256M (I seem to recall that you can tell a Linux kernel you have only a
> > given amount of memory).

On Wed, May 04, 2005 at 09:17:19AM -0700, H. J. Lu wrote:
> Given the current hardware, I would say 512MB is a reasonable number.
> If I need to more than 256M to get 5% speed up, I will take it.

We're not talking about 5% speedup; if the linker starts thrashing because
of insufficient memory you pay far more than that.  And certainly anyone
with an older computer who is dissatified with its performance, but
doesn't have a lot of money, should look into getting more memory before
anything else.  Still, the GNU project shouldn't be telling people in the
third world with cast-off machines that they are out of luck; to many of
them, 256M is more than they have.

So the basic issue is this: why the hell does the linker need so much
memory?  Sure, if you have tons available, it pays to trade memory for
time, mmap everything, then build all the hashes you want to look up
relationships in every direction.  But if it doesn't really fit, it's
a big lose.  Ideally ld, ar and the like could detect and adapt if there
isn't enough physical memory to hold everything.

RE: Can't build 3.3.5 without getting java?

[Dave Korn]

Original Message
>From: Hugh Sasse
>Sent: 04 May 2005 15:45


> # LANGOPT="--enable-languages=c,c++,f77,java,objc"
> LANGOPT="--enable-languages=c,c++,f77"
> 
> cd $BUILD_DIR
> /bin/rm -rf ./*
> ${GCC_SOURCE_DIR}/configure $ASOPT $LDOPT $LANGOPTS --disable-nls \
> --with-local-prefix=/tmp/gcc-local --without-libjava --without-gcj
> && \
> # gmake --jobs=5 bootstrap-lean && \
> gmake  bootstrap-lean && \
> gmake check
> 
> 

> Why isn't --enable-languages=c,c++,f77 sufficient to stop this?


  Because you assigned that to $LANGOPT (no trailing 'S'), but the configure
command line has it spelt as $LANGOPTS (note trailing 'S'!), so it didn't
_actually_ get passed to the configure command?


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

Re: Dirac, GCC-4.0.0 and SIMD optimisations on x86 architecture

[Anuradha Suraparaju]

I've attached a sample file to this email. The class defined in the cpp
file is a cut down and modfied version of the class used in Dirac.

I compiled it using the following options:
g++ -mmmx -g -O3  test_mmx_diff4.cpp


The run time comparison is attached to this email as well.

Hope this helps.

Regards
A. Suraparaju

On Tue, 2005-05-03 at 16:29 -0700, James E Wilson wrote:
> Anuradha Suraparaju wrote:
> > My question is how do I report this as a bug? What information do I
> > need to provide in the bug report? Did anybody else face similar
> > problems with GCC-4.0.0 and MMX-enabled programs.
> 
> See
>  http://gcc.gnu.org/bugs.html
> for info on reporting bugs.
> 
> If you can narrow this down to a small testcase, then you are more 
> likely to get a solution from us.  If you want us compile the entire 
> Dirac project and take a look, we probably won't bother.
> 
> There have been changes to the MMX support in gcc, but without specific 
> details about your testcase, it is hard to say anything definite.  For 
> instance, we don't know what the Dirac --enable-mmx option does.  Which 
> specific gcc options does it enable?
> 
> What about SSE?  The SSE support is generally preferred over the older 
> MMX support.  Does Dirac make any use of this?  If not, perhaps it should.
-- 
#include 
#ifdef __MMX__
#include 
#endif

typedef short **PicArray;

PicArray refdata;
PicArray picdata;


class SimpleBlockDiff
{
public:
  //! Default lConstructor
SimpleBlockDiff( const PicArray &pic_data, const PicArray &ref_data, int rows, int cols) : pic_data(picdata), ref_data(ref_data), xl(cols), yl(rows)
	{}

//! Do the actual difference without bounds checking
int Diff();

private:
//! Private, bodyless copy-constructor: class should not be copied
SimpleBlockDiff(const SimpleBlockDiff& cpy);

   //! Private, bodyless assignment=: class should not be assigned
SimpleBlockDiff& operator=(const SimpleBlockDiff& rhs);

		PicArray pic_data, ref_data;
		int xl, yl;

};

int SimpleBlockDiff::Diff ()
{
#ifdef __MMX__
__m64 sum = _mm_set_pi32(0, 0);

   	for (int j=0 ; j < yl ; j++)
	{
		short *p = &pic_data[j][0];
		short *r = &ref_data[j][0];

   		for (int i=0 ; i < xl ; i+=4, p +=4, r+=4 )
{
   __m64 pic = *(__m64 *)p;
   __m64 ref = *(__m64 *)r;
// pic - ref
pic = _mm_sub_pi16 (pic, ref);
// abs (pic - ref)
ref = _mm_srai_pi16(pic, 15);
pic = _mm_xor_si64(pic, ref);
pic = _mm_sub_pi16 (pic, ref);
// sum += abs(pic -ref)
ref = _mm_xor_si64(ref, ref);
ref = _mm_unpackhi_pi16(pic, ref);
pic = _mm_unpacklo_pi16(pic, pic);
pic = _mm_srai_pi32 (pic, 16);
//ref = _mm_srai_pi32 (ref, 16);
pic = _mm_add_pi32 (pic, ref);
sum = _mm_add_pi32 (sum, pic);
}
}
int *result = (int *) ∑
_mm_empty();

return result[0] + result[1];
#else
	int sum = 0;

	for (int j=0; j < yl; j++)
	{
		for (int i=0; i < xl; i++)
		{
			sum += std::abs(pic_data[j][i] - ref_data[j][i]);
		}
	}
	return sum;
#endif
}

void setup_data()
{
	short *pic_data = new short [12*12];
	short *ref_data = new short [12*12];

	picdata = new short *[12];
	refdata = new short *[12];
	for (int j = 0; j<12; j++)
	{
		picdata[j] = pic_data + j*12;
		for (int i = 0; i < 12; i++)
			picdata[j][i] = 2;
	}

	for (int j = 0; j<12; j++)
	{
		refdata[j] = ref_data + j*12;
		for (int i = 0; i < 12; i++)
			refdata[j][i] = 1;
	}
}

void cleanup()
{
	delete [] refdata[0];
	delete [] picdata[0];

	
	delete[] picdata;
	delete[] refdata;
}

extern int main (int argc, char **argv)
{

	setup_data();

	SimpleBlockDiff diff (picdata, refdata, 12, 12);

	std::cout << diff.Diff () << std::endl;

 	for (int i = 0; i < 400 ; i++)
 	{
		diff.Diff ();
 	}

}
Compile line
g++ -mmmx -g -O3  test_mmx_diff4.cpp

Tests conducted using gcc3.4.3 and gcc 4.0.1 20050503 (prerelease)


1. AMD Dual Opteron Processor, Suse 9.2 (32 bit)

Results:

gcc-3.4.3  gcc-4.0.1 20050503 (prerelease)

real 1.25  real 2.87
user 1.24  user 2.87
sys 0.00   sys 0.00


2. Intel Dual Xeon 3.0 GHz, Suse 9.2 64 bit

Results:

gcc-3.4.3  gcc-4.0.0

real 1.09  real 1.58
user 1.09  user 1.54
sys 0.00   sys 0.00

3. Pentium 4 2.66GHz, Suse 9.2

Results:

gcc3.3 20030226gcc-4.0.0

real 1.35  real 4.98
user 1.32  user 4.96
sys 0.00   sys 0.00


gcc-4.0.0 performed worse than gcc-3.3.3 or gcc3.4.3 even for this simple 
program. The test results using Dirac were similar to this.

Re: GCC 4.1: Buildable on GHz machines only?

[Ian Lance Taylor]

Joe Buck <[EMAIL PROTECTED]> writes:

> So the basic issue is this: why the hell does the linker need so much
> memory?  Sure, if you have tons available, it pays to trade memory for
> time, mmap everything, then build all the hashes you want to look up
> relationships in every direction.  But if it doesn't really fit, it's
> a big lose.  Ideally ld, ar and the like could detect and adapt if there
> isn't enough physical memory to hold everything.

At present the linker provides command line options --no-keep-memory
and --reduce-memory-overheads to significantly reduce the amount of
memory required during the link.

It should be possible in principle to partially adapt to available
memory based on, e.g., physmem_total.  The linker could keep track of
how much memory it has allocated via bfd_alloc and bfd_malloc.  If
that total gets to be 75% of physmem_total, or something like that,
the linker could switch to --no-keep-memory.

Unfortunately the decisions made by --reduce-memory-overhead apply at
the start of the link.  At that time it is difficult to tell how much
memory will be needed.

Ian

RE: Can't build 3.3.5 without getting java?

[Hugh Sasse]

On Wed, 4 May 2005, Dave Korn wrote:

Why isn't --enable-languages=c,c++,f77 sufficient to stop this?

 Because you assigned that to $LANGOPT (no trailing 'S'), but the configure
command line has it spelt as $LANGOPTS (note trailing 'S'!), so it didn't
_actually_ get passed to the configure command?
Thank you!  Sometimes there's nothing like a fresh pair of eyes.
I've been staring at this so long

   cheers,
 DaveK
Thank you,
Hugh

Re: volatile semantics

[Dale Johannesen]

On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:
Andrew Haley <[EMAIL PROTECTED]> writes:
| Nathan Sidwell writes:
|  > Dale Johannesen wrote:
|  >
|  > > And we don't have to document the behavior at all; it is not 
documented
|  > > now.
|  > I disagree.  It's not documented explicitly in gcc now, because 
it is doing
|  > what the std permits, and so documented there. We should document 
either
|  >
|  > a) that current gcc is not breaking the std, and Mike's example 
is invalid
|  > code, if one expects a volatile read.  This would be a FAQ like 
thing.
Both behaviors are standard-compliant.  Treating a reference as 
volatile when
you don't have to just means strictly following the rules of the 
abstract machine;
it can never break anything.

I vote for (a).
[...]
| This is a bad extension to gcc and will cause much trouble, just like
| the old guarantee to preserve empty loops.
I see a difference between a documented extension, and quietly choosing
from among standard-compliant behaviors the one which is most 
convenient for
users.

question on semantics

[Chris Friesen]

I'm not sure who I should address this to...I hope this is correct.
If I share memory between two processes, and protect access to the 
memory using standard locking (fcntl(), for instance), do I need to 
specify that the memory is volatile?  Or is the fact that I'm using 
fcntl() enough to force the compiler to not optimise away memory accesses?

As an example, consider the following code, with / 
replaced with the appropriate fcntl() code:

int *b;
int test()
{
b=;
while(1) {

if (*b) {
break;
}

}

return *b;
}
Without the locks, the compiler is free to only load *b once (and in 
fact gcc does so).  Is the addition of the locks sufficient to force *b 
to be re-read each time, or do I need to declare it as

volatile int *b;
Thanks,
Chris

Re: volatile semantics

[Paul Koning]

> "Dale" == Dale Johannesen <[EMAIL PROTECTED]> writes:

 Dale> On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:

 >> Andrew Haley <[EMAIL PROTECTED]> writes:
 >> 
 >> | Nathan Sidwell writes: | > Dale Johannesen wrote:
 >> |  >
 >> | > > And we don't have to document the behavior at all; it is not
 >> documented | > > now.  | > I disagree.  It's not documented
 >> explicitly in gcc now, because it is doing | > what the std
 >> permits, and so documented there. We should document either
 >> |  >
 >> | > a) that current gcc is not breaking the std, and Mike's
 >> example is invalid | > code, if one expects a volatile read.  This
 >> would be a FAQ like thing.

 Dale> Both behaviors are standard-compliant.  Treating a reference as
 Dale> volatile when you don't have to just means strictly following
 Dale> the rules of the abstract machine; it can never break anything.

 >> I vote for (a).
 >> 
 >> [...]
 >> 
 >> | This is a bad extension to gcc and will cause much trouble, just
 >> like | the old guarantee to preserve empty loops.

 Dale> I see a difference between a documented extension, and quietly
 Dale> choosing from among standard-compliant behaviors the one which
 Dale> is most convenient for users.

I agree, but I would put it more strongly -- choose the interpretation
which (a) satisfies the principle of least astonishment, (b) matches
previous version behavior, and (c) will keep existing user code
working rather than breaking it in hard to debug ways.

paul

Re: C54x port: some general technical questions

[James E Wilson]

On Wed, 2005-05-04 at 06:00, Paul Koning wrote:
> I wonder if the work-in-progress PDP10 port
> (http://pdp10.nocrew.org/gcc/) might help with this.

Interesting, but a hobbyist port for a 36-bit machine that was
end-of-lifed about 2 decades ago has little chance of success, unless
there are some very dedicated volunteers willing to maintain it and
champion it.  That doesn't seem to be the case, as the web site hasn't
been updated in 2 years, and the NetBSD port seems to have been dormant
for 2 years.

There are also possible copyright assignment issues here.  Do we know if
all of the contributors have valid copyright assignment papers?  If not,
then it isn't safe to borrow any code from there.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: GCC 4.1: Buildable on GHz machines only?

[Joe Buck]

On Wed, May 04, 2005 at 12:43:46PM -0400, Ian Lance Taylor wrote:
> At present the linker provides command line options --no-keep-memory
> and --reduce-memory-overheads to significantly reduce the amount of
> memory required during the link.
> 
> It should be possible in principle to partially adapt to available
> memory based on, e.g., physmem_total.  The linker could keep track of
> how much memory it has allocated via bfd_alloc and bfd_malloc.  If
> that total gets to be 75% of physmem_total, or something like that,
> the linker could switch to --no-keep-memory.
> 
> Unfortunately the decisions made by --reduce-memory-overhead apply at
> the start of the link.  At that time it is difficult to tell how much
> memory will be needed.

If the number gets much above 100%, it would probably be faster for the linker
to quit and start over than to proceed, and such an approach wouldn't be
hard to implement.

successful build of GCC 4.0.0 on Mac OS 10.3.9 (bootstrap, only C)

[Bojan Antonovic]

Note:
- I could build GCC 4.0.0 only with Fortran95 and C.
- with C++ and Java building failed.
- I will try to build GCC 4.0 with itself, now with (nearly) all languages.
gcc -v
Using built-in specs.
Target: powerpc-apple-darwin7.9.0
Configured with: ../gcc-4.0.0/configure --program-suffix=-4.0.0c 
--enable-languages=c
Thread model: posix
gcc version 4.0.0

./config.guess
powerpc-apple-darwin7.9.0
uname -a
Darwin Bojan-Antonovics-Computer.local 7.9.0 Darwin Kernel Version 
7.9.0: Wed Mar 30 20:11:17 PST 2005; 
root:xnu/xnu-517.12.7.obj~1/RELEASE_PPC  Power Macintosh powerpc

gcc -v
Reading specs from /usr/local/lib/gcc/powerpc-apple-darwin7.6.0/3.4.3/specs
Configured with: ../gcc-3.4.3/configure --program-suffix=-3.4.3 
--enable-languages=c,c++,objc,java,f77
Thread model: posix
gcc version 3.4.3

greetings
   Bojan

Re: question on semantics

[Diego Novillo]

On Wed, May 04, 2005 at 11:59:49AM -0600, Chris Friesen wrote:

> Without the locks, the compiler is free to only load *b once (and in 
> fact gcc does so).  Is the addition of the locks sufficient to force *b 
> to be re-read each time, or do I need to declare it as
> 
As long as you keep 'b' pointing to memory outside the current
compilation unit, GCC will consider the calls to  and
 as clobbering *b.  So, you shouldn't need to mark it
volatile.

However, you could get into trouble if you somehow managed to get
a local stack slot shared between threads:


int test()
{
int *b;
int a;

b=&a;

while(1) {

if (*b) {
break;
}

}


return *b;
}

If you arrange things so that

- Threads share the same stack.
- The address of 'a' does not escape the current function

Then GCC will remove the second load from *b.  In fact, it will
change '*b'  to 'a'.

I very much doubt you can create that situation, however.
Sharing stack between threads will give you tons of other races
and you will always need to make the address of 'a' escape the
function somehow (e.g. when placing it in shared memory).

Since it is very unlikely for the compiler to inline the calls to
 and , the optimizers will treat those calls as
black boxes and will assume *b clobbered.


Diego.

Re: question on semantics

[chris jefferson]

Chris Friesen wrote:
I'm not sure who I should address this to...I hope this is correct.
If I share memory between two processes, and protect access to the 
memory using standard locking (fcntl(), for instance), do I need to 
specify that the memory is volatile?  Or is the fact that I'm using 
fcntl() enough to force the compiler to not optimise away memory 
accesses?

As an example, consider the following code, with / 
replaced with the appropriate fcntl() code:

int *b;
int test()
{
b=;
while(1) {

if (*b) {
break;
}

}

return *b;
}
Without the locks, the compiler is free to only load *b once (and in 
fact gcc does so).  Is the addition of the locks sufficient to force 
*b to be re-read each time, or do I need to declare it as

volatile int *b;
Offically you have to declare volatile int *b. Although I can't be sure 
however, looking at this sample of code gcc will re-read the values 
anyway, as if fcntl are included in a seperate binary, gcc will probably 
not be able to tell that the value *b couldn't be changed by the call 
the fcntl, so will dump it to memory before the function call and read 
it back afterwards. While it's a little dodgy, in the past I've often 
made sure gcc re-reads memory locations by passing a pointer to them to 
a function compiled in a seperate unit. If gcc ever gets some kind of 
super-funky cross-unit binary optimisation, then this might get 
optimised away, but I wouldn't expect such a thing soon :)

Chris

Thanks,
Chris

Re: C54x port: some general technical questions

[Paul Koning]

> "James" == James E Wilson  writes:

 James> On Wed, 2005-05-04 at 06:00, Paul Koning wrote:
 >> I wonder if the work-in-progress PDP10 port
 >> (http://pdp10.nocrew.org/gcc/) might help with this.

 James> Interesting, but a hobbyist port for a 36-bit machine that was
 James> end-of-lifed about 2 decades ago has little chance of success,
 James> unless there are some very dedicated volunteers willing to
 James> maintain it and champion it.  That doesn't seem to be the
 James> case, as the web site hasn't been updated in 2 years, and the
 James> NetBSD port seems to have been dormant for 2 years.

 James> There are also possible copyright assignment issues here.  Do
 James> we know if all of the contributors have valid copyright
 James> assignment papers?  If not, then it isn't safe to borrow any
 James> code from there. 

True.  FWIW, I know that both the PDP10 and the PDP11 target support
in binutils were contributed by that gentleman.

By the way, I don't believe that "hobbyist port" is a correct
characterization of the pdp10 port work.

   paul

Re: Dirac, GCC-4.0.0 and SIMD optimisations on x86 architecture

[James E Wilson]

On Wed, 2005-05-04 at 09:37, Anuradha Suraparaju wrote:
> I've attached a sample file to this email. The class defined in the cpp
> file is a cut down and modfied version of the class used in Dirac.

That is a fine bug report.  You just need to put it in bugzilla if you
want us to do anything about it.

I took a quick look at it.  It appears to be a register allocation
issue.  The gcc mainline compiled code I looked at uses 3 mmx registers,
and ends up putting one variable on the stack, thus needing two extra
loads and stores in the inner loop.  The gcc-3.3.3 compiled code I
looked at put everything in registers, using 7 mmx registers, and no
unnecessary loads/stores in the inner loop.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: question on semantics

[Mike Stump]

On May 4, 2005, at 10:59 AM, Chris Friesen wrote:
I'm not sure who I should address this to...I hope this is correct.
If I share memory between two processes, and protect access to the  
memory using standard locking (fcntl(), for instance), do I need to  
specify that the memory is volatile?
It is safer to.  People might compile your whole app at once for  
better optimization, and the compiler might be just smart enough to  
optimize it away.  This would be in conjunction with the compiler  
getting smarter about libc style functions, and what they read and  
write.  Both of these can happen in the next 5 years in my book.   
Betting on the optimizer not getting smart, is a dangerous bet,  
better to just state what you want to do.

Re: volatile semantics

[Nathan Sidwell]

Dale Johannesen wrote:
Both behaviors are standard-compliant.
I don't think anyone's disagreeing with that.  The point is that the
user *requires* a volatile read, but the std *does not* guarantee it.
> Treating a reference as volatile when you don't have to just means
> strictly following the rules of the abstract machine; it can never
> break anything.
ok then, this can be achieved with the -O0 flag :)  I doubt that's
what is desired though.
I see a difference between a documented extension, and quietly choosing
from among standard-compliant behaviors the one which is most convenient 
for users.
I see your point, but I think it is wrong.  How can the programmer rely
on gcc adhering more strictly to the abstract machine than the std
requires, unless the behaviour is documented?  How can the gcc developers
make sure optimizations are not breaking such a promise, unless it is
documented?
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: question on semantics

[Chris Friesen]

Mike Stump wrote:
On May 4, 2005, at 10:59 AM, Chris Friesen wrote:

If I share memory between two processes, and protect access to the  
memory using standard locking (fcntl(), for instance), do I need to  
specify that the memory is volatile?

It is safer to.  People might compile your whole app at once for  better 
optimization, and the compiler might be just smart enough to  optimize 
it away.
One problem with using volatile is that it can destroy performance.  I 
only need to really read it in from memory the first time after I take a 
lock, and flush it out to memory at the time I give up the lock.  If I 
specify it as volatile, I force the compiler to read/write memory on 
*every* access, even when it's not necessary.

Also, what about threads and pthread locking?  Do I need to use volatile 
there?  If not, then what about using pthread locking between processes?

So far I've gotten answers all over the map from people who all claim to 
know what's going on.  It's a pain.

Chris

Missing type info in debug data in 4.0.0

[Paul Koning]

I'm doing some tests to see if 4.0.0 will improve our debug
experience, which is mixed indeed with complex C++ code and 3.3.3.

So far it looks like things are MUCH worse.  I built my application
and looked at it with GDB.  Many of the structure names are missing.

I did some checking with readelf, looking at one of the object files.
I dumped the debug data (-w) searching for the struct names in that
output.  Some of them showed up, some did not.  In a bunch of cases,
out of three struct types defined one right after the other in a
header file, one showed up and the other two were missing.

Any ideas?

Host is netbsd-intel, target netbsd-mips, binutils 2.15.  I'll do a
build with binutils 2.16 but I don't expect any difference, since the
missing typenames don't show up when I look at the assembler output
from gcc, either.

 paul

Re: Missing type info in debug data in 4.0.0

[Daniel Jacobowitz]

On Wed, May 04, 2005 at 03:53:35PM -0400, Paul Koning wrote:
> I'm doing some tests to see if 4.0.0 will improve our debug
> experience, which is mixed indeed with complex C++ code and 3.3.3.
> 
> So far it looks like things are MUCH worse.  I built my application
> and looked at it with GDB.  Many of the structure names are missing.
> 
> I did some checking with readelf, looking at one of the object files.
> I dumped the debug data (-w) searching for the struct names in that
> output.  Some of them showed up, some did not.  In a bunch of cases,
> out of three struct types defined one right after the other in a
> header file, one showed up and the other two were missing.
> 
> Any ideas?

Are they both used and defined in the program?  Currently GCC only
outputs full debug info for classes at the point where the key method
is emitted.  There's some discussion about this in the archives.

> Host is netbsd-intel, target netbsd-mips, binutils 2.15.  I'll do a
> build with binutils 2.16 but I don't expect any difference, since the
> missing typenames don't show up when I look at the assembler output
> from gcc, either.

No ideas without concrete examples and testcase, sorry.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: question on semantics

[Diego Novillo]

On Wed, May 04, 2005 at 01:47:20PM -0600, Chris Friesen wrote:

> Also, what about threads and pthread locking?  Do I need to use volatile 
> there?  If not, then what about using pthread locking between processes?
> 
Same reply I gave you before.  As long as the address of your
shared memory is outside of the function and the pointer is
itself a global variable or gets its value from the heap, then
calls to functions that cannot be inlined will be considered to
clobber dereferences to the pointer.

Things will only break for you when GCC pulls in function bodies
at link time.  At that point, yes, you will need to declare your
pointed-to area as volatile.

If, further down the road we add multithreading semantics to the
optimizers, then you won't need volatile.

> So far I've gotten answers all over the map from people who all claim to 
> know what's going on.  It's a pain.
> 
tree-ssa-alias.c:compute_points_to_and_addr_escape and
tree-ssa-alias.c:compute_may_aliases have the final answer.  I
can guide you through the code if you'd like.


Diego.

Re: Missing type info in debug data in 4.0.0

[Paul Koning]

> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

 Daniel> On Wed, May 04, 2005 at 03:53:35PM -0400, Paul Koning wrote:
 >> I'm doing some tests to see if 4.0.0 will improve our debug
 >> experience, which is mixed indeed with complex C++ code and 3.3.3.
 >> 
 >> So far it looks like things are MUCH worse.  I built my
 >> application and looked at it with GDB.  Many of the structure
 >> names are missing.
 >> 
 >> I did some checking with readelf, looking at one of the object
 >> files.  I dumped the debug data (-w) searching for the struct
 >> names in that output.  Some of them showed up, some did not.  In a
 >> bunch of cases, out of three struct types defined one right after
 >> the other in a header file, one showed up and the other two were
 >> missing.
 >> 
 >> Any ideas?

 Daniel> Are they both used and defined in the program?  Currently GCC
 Daniel> only outputs full debug info for classes at the point where
 Daniel> the key method is emitted.  There's some discussion about
 Daniel> this in the archives.

OUCH.

Some of the types in question are probably not used in the program --
they are there for debugging.  It's disturbing to see this sort of
incompatibility.

The rule for "used" clearly has problems.  One of the types missing is
a struct that is referenced by way of casts, e.g.,
  struct foo { int x; int y; };
  bar = ((struct foo *)0x1234000)->x;

and that usage apparently is not enough to get gcc 4.0.0 to drop the
definition of "struct foo" into the output.  

So what does gcc consider "use" of a type?  If the number of omissions
is small enough, I might be able to hunt them down and do a
workaround.  Then again, I'd prefer GCC to use the old rule.  It seems
reasonable to assume that, if I mention a type in the source code, I
might want to refer to it in the debugger.  If that can't be the
default, at least there should be an option to force that behavior.

   paul

Re: Missing type info in debug data in 4.0.0

[Daniel Jacobowitz]

On Wed, May 04, 2005 at 04:15:53PM -0400, Paul Koning wrote:
> OUCH.
> 
> Some of the types in question are probably not used in the program --
> they are there for debugging.  It's disturbing to see this sort of
> incompatibility.

-fno-eliminate-unused-debug-types?

> The rule for "used" clearly has problems.  One of the types missing is
> a struct that is referenced by way of casts, e.g.,
>   struct foo { int x; int y; };
>   bar = ((struct foo *)0x1234000)->x;
> 
> and that usage apparently is not enough to get gcc 4.0.0 to drop the
> definition of "struct foo" into the output.  

Is there not even a DW_AT_declaration for struct foo?  If so, it's a
bug.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: question on semantics

[Diego Novillo]

On Wed, May 04, 2005 at 04:15:41PM -0400, Diego Novillo wrote:

> Same reply I gave you before.  As long as the address of your
> shared memory is outside of the function and the pointer is
> itself a global variable or gets its value from the heap, then
> calls to functions that cannot be inlined will be considered to
> clobber dereferences to the pointer.
> 
In your specific case, the pointer will have to be a global
variable (not static, but truly global).  The calls to
lock/unlock will not take the pointer nor the shared variable as
arguments, so GCC will get too smart for your taste.


Diego.

Re: Missing type info in debug data in 4.0.0

[Paul Koning]

> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

 Daniel> On Wed, May 04, 2005 at 04:15:53PM -0400, Paul Koning wrote:
 >> OUCH.
 >> 
 >> Some of the types in question are probably not used in the program
 >> -- they are there for debugging.  It's disturbing to see this sort
 >> of incompatibility.

 Daniel> -fno-eliminate-unused-debug-types?

Oh.  Missed that, will try it.

 >> The rule for "used" clearly has problems.  One of the types
 >> missing is a struct that is referenced by way of casts, e.g.,
 >> struct foo { int x; int y; }; bar = ((struct foo *)0x1234000)->x;
 >> 
 >> and that usage apparently is not enough to get gcc 4.0.0 to drop
 >> the definition of "struct foo" into the output.

 Daniel> Is there not even a DW_AT_declaration for struct foo?  If so,
 Daniel> it's a bug.

I'll see about creating a small test case for a PR.

 paul

Re: question on semantics

[David Daney]

Chris Friesen wrote:
Mike Stump wrote:

It is safer to.  People might compile your whole app at once for  
better optimization, and the compiler might be just smart enough to  
optimize it away.

One problem with using volatile is that it can destroy performance.  I 
only need to really read it in from memory the first time after I take a 
lock, and flush it out to memory at the time I give up the lock.  If I 
specify it as volatile, I force the compiler to read/write memory on 
*every* access, even when it's not necessary.
If you are concerned about this, why not explicitly code it by copying 
the value in to a non-volatile temporary variable?  Or make the variable 
non-volatile and protect access with proper synchronization primitives.

I expect the compiler to do the best optimization possible within the 
bounds of the language specification.  As earlier posters have 
expressed, I don't think it is wise to count on the compiler doing a 
poor job of optimization in order to obtain desired program behavior.

David Daney

Re: restrict and char pointers

[James E Wilson]

Jeroen Dobbelaere wrote:
void test_2(unsigned long* __restrict__ bar, char* __restrict__ bas)
{
  unsigned long tmp = *bar;
  *bas = 0;
  *bar = tmp;
}
The optimization in the first example happens in the postreload cse 
pass, and is relying on RTL alias analysis info.

The optimization does not happen for this example because we apparently 
have no way to represent an alias set for a restricted char pointer. 
char * and void * are allowed to alias anything.  That is alias set 0 
internally.  A restricted char pointer can alias anything except another 
restricted pointer, which would require making a subset of alias set 0, 
but that is invalid.  So we give up and just ignore the use of restrict 
here.

See in alias.c, where it does
if (pointed_to_alias_set == 0)
  /* It's not legal to make a subset of alias set zero.  */
  DECL_POINTER_ALIAS_SET (decl) = 0;
We also don't handle restricted pointers to aggregate types.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: question on semantics

[Chris Friesen]

Diego Novillo wrote:
On Wed, May 04, 2005 at 01:47:20PM -0600, Chris Friesen wrote:

Also, what about threads and pthread locking?  Do I need to use volatile 
there?  If not, then what about using pthread locking between processes?

Things will only break for you when GCC pulls in function bodies
at link time.  At that point, yes, you will need to declare your
pointed-to area as volatile.
Dave Butenhof (author of "Programming with POSIX Threads") seems to 
disagree with that position:

"In general, use of "volatile" for variables that are simply shared 
between threads is unnecessary and wasteful. Proper synchronization is 
necessary and sufficient; there is no substitute short of coding 
carefully with specific knowledge of the memory architecture of a 
specific platform."

In multiple messages to comp.programming.threads he has stated that 
volatile is not necessary between threads if you use the posix locking 
functions, and in fact that one of the main purposes of the posix locks 
is to ensure correct memory visibility between threads.

Chris

Re: question on semantics

[Diego Novillo]

On Wed, May 04, 2005 at 02:47:14PM -0600, Chris Friesen wrote:

> In multiple messages to comp.programming.threads he has stated that 
> volatile is not necessary between threads if you use the posix locking 
> functions, and in fact that one of the main purposes of the posix locks 
> is to ensure correct memory visibility between threads.
> 
That still assumes that the compiler isn't pulling the body of
pthread_mutex_lock, deciding that it doesn't really clobber any
globals and proceeding to consider it a read-only function.  At
this point in time, and for the foreseeable future this will
remain to be true.

For instance,

-
#include 

static int shared_var;

foo ()
{
  int *p = &shared_var;
  pthread_mutex_t lock = PTHREAD_MUTEX_INITIALIZER;

  pthread_mutex_lock (&lock);
  *p += 3;
  pthread_mutex_unlock (&lock);

  return *p;
}
-

roughly translates to this IL after alias analysis (i've removed
some chunks for clarity):

-
 1  p_1 = &shared_var;
 2  
 3  #   shared_var_10 = V_MAY_DEF ;
 4  #   lock_11 = V_MAY_DEF ;
 5  pthread_mutex_lock (&lock);
 6  
 7  #   VUSE ;
 8  D.1668_5 = *p_1;
 9  D.1669_6 = D.1668_5 + 3;
10  
11  #   shared_var_12 = V_MAY_DEF ;
12  *p_1 = D.1669_6;
13  
14  #   shared_var_13 = V_MAY_DEF ;
15  #   lock_14 = V_MAY_DEF ;
16  pthread_mutex_unlock (&lock);
17  
18  #   VUSE ;
19  D.1670_7 = *p_1;
20  
21  return D.1670_7;
-

See the calls to pthread_mutex_lock and pthread_mutex_unlock?
Those V_MAY_DEF operators you see above them are there to
indicate that those calls may clobber those variables.

So, lines 3 and 4 indicate that the compiler thinks that
pthread_mutex_lock will clobber shared_var and lock.  Similarly
with lines 14 and 15 and pthread_mutex_unlock.

Now, suppose that the compiler grows enough capabilities to pull
in the bodies of pthread_mutex_lock/pthread_mutex_unlock into the
current compilation unit.  It examines them and determines that
neither function really writes to shared_var, so you end up with:

-
 1  [ ... ]
 2  #   shared_var_12 = V_MAY_DEF ;
 3  *p_1 = D.1669_6;
 4  
 5  #   lock_14 = V_MAY_DEF ;
 6  pthread_mutex_unlock (&lock);
 7  
 8  #   VUSE ;
 9  D.1670_7 = *p_1;
10  [ ... ]
-

Notice how the load from *p_1 at line 8 is reading from
shared_var_12, which is the very same shared_var_12 stored to in
line 2.  At that point, you've lost.  The compiler will happily
move D.1669_6 into line 9.

Since GCC is a sequential compiler and we haven't told it
anything about the semantics of pthread_mutex_lock (in fact, I
don't see pthread.h marking them in any particular way), it
doesn't know that they're memory flushing sites.

The real future-proof fix is to mark them as such and have the
compiler recognize that attribute.  This means adding concurrency
semantics to the compiler.  Something that we are in the process
of doing.



Diego.

Re: restrict and char pointers

[Jeroen Dobbelaere]

On 5/4/05, James E Wilson <[EMAIL PROTECTED]> wrote:
[..]
> The optimization does not happen for this example because we apparently
> have no way to represent an alias set for a restricted char pointer.
> char * and void * are allowed to alias anything.  That is alias set 0
> internally.  A restricted char pointer can alias anything except another
> restricted pointer, which would require making a subset of alias set 0,
> but that is invalid.  So we give up and just ignore the use of restrict
> here.
> 
[..]

Is this correct ? I don't have a version of the C99 standard, but
looking at explanations of the 'restrict' keyword, I see in
 and in
,
it seems that the definition of a restricted pointer is, that it does
not alias with anything else (for the time it is being used), and that
all accesses to the object it points to, should go through this
restricted pointer only.

This would mean that a restricted char pointer should not alias
something else. (no other restricted pointers, but also no
non-restricted pointers).

Does this 'definition' conflict with the standards definition ??

Greetings,
-- 
Jeroen Dobbelaere

Re: question on semantics

[Chris Friesen]

Diego Novillo wrote:
On Wed, May 04, 2005 at 02:47:14PM -0600, Chris Friesen wrote:

In multiple messages to comp.programming.threads he has stated that 
volatile is not necessary between threads if you use the posix locking 
functions, and in fact that one of the main purposes of the posix locks 
is to ensure correct memory visibility between threads.

That still assumes that the compiler isn't pulling the body of
pthread_mutex_lock, deciding that it doesn't really clobber any
globals and proceeding to consider it a read-only function.  At
this point in time, and for the foreseeable future this will
remain to be true.
Right.  I suspect that he would consider such behaviour as rendering 
that version of GCC as non POSIX compliant.

The real future-proof fix is to mark them as such and have the
compiler recognize that attribute.  This means adding concurrency
semantics to the compiler.  Something that we are in the process
of doing.
Cool.  Thanks for all the explanations.  I'm going to be giving an 
internal talk on programming for concurrency, and I've learned way more 
doing the research for the talk than most of the attendees will 
currently be able to appreciate.

Chris

Re: question on semantics

[Mike Stump]

On May 4, 2005, at 12:47 PM, Chris Friesen wrote:
One problem with using volatile is that it can destroy performance.
Gosh, I was going to elaborate and give the more complete answer, but  
decided against it, I was wrong.

only need to really read it in from memory the first time after I  
take a lock, and flush it out to memory at the time I give up the  
lock.
I was going to say, you can insert memory barriers inside the, near  
the lock/unlock (or even, inside the lock/unlock code.  If your lock/ 
unlock author has put them in there for you, then, trivially, you  
don't even need them.  Since this list doesn't cover pthreads, we are  
the wrong people to answer that question.

Example:
int i;
int main() {
  int j;
  while (i)
{
  asm volatile ("" : : : "memory");
}
}
Here, i is treated as volatile, though, not marked as such, because  
of the memory barrier.  You can put the barriers anywhere you need them.

Also, bear in mind this list isn't about how to program using  
pthreads...

My uneducated guess is that any pthreads implementations should have  
memory barriers, and so, you could always use them and no amount of  
getting better of the optimizer would ever break this.  I'd guess  
that this would be a bug in the phreads code, if it failed to have  
such a barrier.

Re: question on semantics

[Chris Friesen]

Mike Stump wrote:
On May 4, 2005, at 12:47 PM, Chris Friesen wrote:

One problem with using volatile is that it can destroy performance.

Gosh, I was going to elaborate and give the more complete answer, but  
decided against it, I was wrong.
Heh...sorry.  I've been trying to figure out who's responsible for what 
guarantees.  It's a bit confusing.

I was going to say, you can insert memory barriers inside the, near  the 
lock/unlock (or even, inside the lock/unlock code.  If your lock/ unlock 
author has put them in there for you, then, trivially, you  don't even 
need them.  Since this list doesn't cover pthreads, we are  the wrong 
people to answer that question.
Okay, that makes sense.  Thanks for your comments.
Chris

Re: restrict and char pointers

[James E Wilson]

On Wed, 2005-05-04 at 14:27, Jeroen Dobbelaere wrote:
> Is this correct ?

I was only trying to explain how gcc works for the one example that you
posted.  I was not trying to explain precise semantics of how restrict
works according to the ISO C standard, and my message should not be
construed as such.  I didn't think you were asking that question.  I
probably can't answer that question very well.

The standard says "A translator is free to ignore any or all aliasing
implications of restrict".  So there is no conflict with the standard
here.  We are free to do as little optimization as we want, and in the
case of a restricted char pointer, we do none.

Just above the section of code I pointed at earlier is this comment
which explains how we handle restrict in the gcc RTL aliasing code:
  /* No two restricted pointers can point at the same thing.
 However, a restricted pointer can point at the same thing
 as an unrestricted pointer, if that unrestricted pointer
 is based on the restricted pointer.  So, we make the
 alias set for the restricted pointer a subset of the
 alias set for the type pointed to by the type of the
 decl.  */
Perhaps more advanced alias analysis code can do better, but this is
what we do for now in the RTL aliasing code, and it is known to be safe.

There is also tree aliasing code, which is more advanced than the RTL
aliasing code, but I don't think it has any support for restrict yet. 
So effectively we are ignoring restrict there, which is allowed by the
standard.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: restrict and char pointers

[Jeroen Dobbelaere]

On 5/4/05, James E Wilson wrote:
[..]
> The standard says "A translator is free to ignore any or all aliasing
> implications of restrict".  So there is no conflict with the standard
> here.  We are free to do as little optimization as we want, and in the
> case of a restricted char pointer, we do none.

I'm aware of that. The reason are asked for more clarity is that I
think gcc should
do better (as in the example I gave), but I want to be sure that this
is still allowed
by the standard.

[..]
>   /* No two restricted pointers can point at the same thing.
>  However, a restricted pointer can point at the same thing
>  as an unrestricted pointer, if that unrestricted pointer
>  is based on the restricted pointer.  So, we make the
>  alias set for the restricted pointer a subset of the
>  alias set for the type pointed to by the type of the
>  decl.  */
[..]

>From what I found on these pages I refered to, this could be made more strict :
accesses through restricted pointers would not interfere with other accesses,
which would allow some more aggressive optimizations.

Greetings,
-- 
Jeroen Dobbelaere

Re: GCC 4.1: Buildable on GHz machines only?

[Per Bothner]

Mark Mitchell wrote:
Building libjava takes forever on any platform, relative to the rest of 
the compiler build.
In addition to fixing/replacing libtool (could it be rewritten as a C
program?) there are a number of other known gcj performance problems.
When compiling A.java, gcj needs to read a lot of other classes that A
depends on.  It seems to be reason a lot more classes than it needs to:
it is a lot less agressive about loading a class than it should be.
On the other hand, much time spend improving gcj performance might
be wasteful it it will be replaced by Tom's new gcjx.
One way to speed up libcgj compilation by quite a bit would be to
compile more than one .java file at a time.  For example:
  gcj -c java/util/*.java -o java-util.o
This reduces libtool overhead, reduces the duplication in reading
dependencies, and probably reduces link overheads.  It can also
produce better code, since intermodule references get trurned into
intramodule references.  This just requires Makefile-hacking.
Disadvantages:
- Static linking (which we don't really support very well anyway)
might causes some classes to be needlessly linked in.
- Compiling multiple classes at once might increase virtual memory use.
I think the net benefit could be large - an experiment would be
quite worthwhile.  Perhaps somebody could write a post-configure
script to munge the Makefile and give us some numbers.
Ideally, there'd be a configure flag to control "chunking".
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: restrict and char pointers

[James E Wilson]

On Wed, 2005-05-04 at 16:24, Jeroen Dobbelaere wrote:
> I'm aware of that. The reason are asked for more clarity is that I
> think gcc should
> do better (as in the example I gave), but I want to be sure that this
> is still allowed
> by the standard.

Certainly gcc can and should do better, and this is allowed by the
standard, but implementing better support here is definitely
non-trivial.

> >From what I found on these pages I refered to, this could be made more 
> >strict :
> accesses through restricted pointers would not interfere with other accesses,
> which would allow some more aggressive optimizations.

I took a look at the standard, and gcc seems to be in line with it.  The
problem is that you can have something like
  int sub (int * __restrict__ a) { int *b = a; ... }
and now a and b alias each other, even though one pointer was declared
restrict.  If you can track these relationships, then this isn't a
problem.  If you can't track these relationships, then you have to use
the semantics that gcc currently uses, which is only that different
restricted pointers don't alias each other.  We can perhaps handle this
well in the tree-aliasing code (if it handled restrict at all), but it
would be difficult to handle this well in the RTL aliasing code.
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

gcc-3.3-20050504 is now available

[gccadmin]

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

This snapshot has been generated from the GCC 3.3 CVS branch
with the following options: -rgcc-ss-3_3-20050504 

You'll find:

gcc-3.3-20050504.tar.bz2  Complete GCC (includes all of below)

gcc-core-3.3-20050504.tar.bz2 C front end and core compiler

gcc-ada-3.3-20050504.tar.bz2  Ada front end and runtime

gcc-g++-3.3-20050504.tar.bz2  C++ front end and runtime

gcc-g77-3.3-20050504.tar.bz2  Fortran 77 front end and runtime

gcc-java-3.3-20050504.tar.bz2 Java front end and runtime

gcc-objc-3.3-20050504.tar.bz2 Objective-C front end and runtime

gcc-testsuite-3.3-20050504.tar.bz2The GCC testsuite

Diffs from 3.3-20050427 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-3.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: restrict and char pointers

[Diego Novillo]

On Wed, May 04, 2005 at 05:08:23PM -0700, James E Wilson wrote:

> We can perhaps handle this well in the tree-aliasing code (if
> it handled restrict at all), but it would be difficult to
> handle this well in the RTL aliasing code.
>
It doesn't.  Mostly for similar reasons.

Perhaps we could be more aggressive with the new aliasing changes
coming down the line, but it's certainly non-trivial to take
advantage of restrict.  A shame, really.


Diego.

Re: GCC 4.1: Buildable on GHz machines only?

[David Daney]

Per Bothner wrote:
One way to speed up libcgj compilation by quite a bit would be to
compile more than one .java file at a time.  For example:
  gcj -c java/util/*.java -o java-util.o
This reduces libtool overhead, reduces the duplication in reading
dependencies, and probably reduces link overheads.  It can also
produce better code, since intermodule references get trurned into
intramodule references.  This just requires Makefile-hacking.
I was going to recommend the same thing.
We have taken this approach with a fairly large program (about 1000 
classes) and it does speed things up considerably.  We see a 75% 
reduction in total build times (12 minutes vs 48).

David Daney

Re: Packing booleans?

[Sam Lauber]

> Unless you are using an architecture with btst, bset, bclr instructions.
Pretty much any architechure that could be called a binary computer has 
something like that ;-)

Samuel Lauber
-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

Re: Packing booleans?

[Sam Lauber]

> If this were being done at the level of register allocation, why would
> one need a user visible option?  'Just' rearrange the register file to look
> like a set of single bit registers overlaid on a more conventional register
> file.
As someone pointed out, this might change semantics (read: screw up ;-)
of the * and & operators: &somebool, though it would be placed into memory,
wouldn't deserve an address, since most[1] architechures aren't bit-
adressable.  

Samuel Lauber

[1] I said ``some'', not ``all'', because the TMS340x0 port is.  
-- 
___
Surf the Web in a faster, safer and easier way:
Download Opera 8 at http://www.opera.com

Powered by Outblaze

Re: gij problem (3.4.4)

[Thorsten Glaser]

Andrew Haley dixit:

>Do you have any reason to suspect this might be MirOS specific?

We have to patch a lot. Some of it is OpenBSD legacy, some from
NetBSD, some from newer GNU tools, some patches are build system
specific. And since it happened on execution of a class with only
one page source code, I think it's specific to my configuration.

//mirabile
-- 
Hey, I just realized that OpenBSD CDs are $45.  Any chance I could get
you to update your sig?
-- Steve Shockley after reading my previous signature

Re: GCC 4.1: Buildable on GHz machines only?

[Alan Modra]

On Wed, May 04, 2005 at 09:29:44AM -0700, Joe Buck wrote:
> So the basic issue is this: why the hell does the linker need so much
> memory?

- long symbol names and lots of symbols
- lots of sections
- optimizations that edit section contents, requiring the contents to
  be kept in memory.  eg. string merging, relaxation.

-- 
Alan Modra
IBM OzLabs - Linux Technology Centre

GCC 4.1 Status Report (2005-05-04)

[Mark Mitchell]

GCC 4.1 is going rather well thus far.
Technically, Stage 1 ended on April 25th, though I failed to announce 
that.  There are a few stage 1 tasks that have not made it in yet, 
according to the Wiki:

# Autovectorization Enhancements
Items 1.4, 2.1, 2.3 (1.3)
# CFG Transparent Inlining, Profile-Guided Inlining (1.3)
# Compilation Level Analysis of Types and Static Variables (1.3)
# Pre-Inline Optimizations (1.3)
# Structure Aliasing Part II (1.3)
# Profiling on Trees, gcov on Trees (1.2)
Which of these have not yet been submitted?  For those that have not 
been submitted, is a submission forthcoming shortly?  If not, I'm going 
to have to drop these from the 4.1 release plan.

Certainly, we should consider ourselves in Stage 2 at this point. 
Significant changes are still fair game, but not *major* changes. 
Generally, things big enough to need their own branch should now be 
considered on hold for 4.2.

Stage 2 was scheduled to end June 25th -- which happens to be during the 
GCC Summit.  That doesn't seem like a good idea, so let's push it back 
to July 8th.

Regressions targeted at 4.1 -- but not any previous release -- number 
"only" 80.  However, a casual look suggests that there are at least some 
of those that should not in fact have a release target.  We do still 
have a lot of 4.0 regressions, though, that also apply to 4.1; I would 
encourage people to particularly target PRs that apply to both releases.

--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: C54x port: some general technical questions

[Paul Schlie]

> James E Wilson
>> Jonathan Bastien-Filiatrault wrote:
>> * We have defined BIT_PER_WORD to 16 and UNITS_PER_WORD to 1. On this
>> DSP, there are two 40-bits accumulators. How do we make GCC take
>> advantage of this and which machine mode do we use ?
>
> GCC has little support for non-power-of-2 sized accumulators. Traditionally
> this would be done by using PSImode (because your target has a 64-bit SImode),
> which you can enable by using the undocumented PARTIAL_INT_MODE(SI) macro in
> your target modes.def file. See other targets for existing examples of this.
>
> Also, gcc has little support for targets with BITS_PER_UNIT != 8. I think the
> (ti)c4x is the only one currently supported, and it is being obsoleted due to
> lack of maintenance.

A basic thought (as no GCC language presently directly supports the full
semantics offered by the c54's ISA and various modes, including notion of
"guard bits" extending it's otherwise natural 32-bit wide accumulators);
it may be simplest to treat the accumulator as a 32 bit word composed of
a 16-bit hi and lo halves, ignoring the guard-bits, thereby more simply
modeling the c54 as a basic 16-bit machine with 16-bit char's and ints, and
32-bit long and long-longs?

Leaving the predominant remaining problem of identifying which mode maps to
which corresponding type. Personally I believe it would be most ideal if GCC
didn't presume that QImode size == BITS_PER_UNIT, but rather introduced the
definition that QImode size == BITS_PER_BYTE, where then BITS_PER_UNIT may
then more flexibly define the minimally sized addressable datum relative to
it, thereby enabling for example: (although requiring some GCC refinement)

#define BITS_PER_BYTE 8 /* or whatever */

#define QI_MODE_SIZE  1 /* BYTES, not units */
#define BITS_PER_QI_MODE (1 * BITS_PER_BYTE)
#define HI_MODE_SIZE  2 /* BYTES, not units */
#define BITS_PER_HI_MODE (2 * BITS_PER_BYTE)
#define SI_MODE_SIZE  4 /* BYTES, not units */
#define BITS_PER_SI_MODE (4 * BITS_PER_BYTE)
...

#define UNIT_SIZE HI_MODE_SIZE /* minimum naturally addressable mode size */
#define BITS_PER_UNIT (UNIT_SIZE * BITS_PER_BYTE)

#define WORD_SIZE HI_MODE_SIZE /* maximum naturally addressable mode size */
#define BITS_PER_WORD (WORD_SIZE * BITS_PER_BYTE)

#define CHAR_SIZE HI_MODE_SIZE
#define BITS_PER_CHAR (CHAR_SIZE * BITS_PER_BYTE)
#define INT_SIZE HI_MODE_SIZE
#define BITS_PER_INT (INT_SIZE * BITS_PER_BYTE)
#define LONG_SIZE SI_MODE_SIZE
#define BITS_PER_LONG (LONG_SIZE * BITS_PER_BYTE)
#define LONG_LONG_SIZE SI_MODE_SIZE
#define BITS_PER_LONG_LONG (LONG_LONG_SIZE * BITS_PER_BYTE)
...

Re: GCC 4.1: Buildable on GHz machines only?

[Ranjit Mathew]

Per Bothner wrote:
> Mark Mitchell wrote:
> 
>>Building libjava takes forever on any platform, relative to the rest of 
>>the compiler build.

[...]

> One way to speed up libcgj compilation by quite a bit would be to
> compile more than one .java file at a time.  For example:
>gcj -c java/util/*.java -o java-util.o
> This reduces libtool overhead, reduces the duplication in reading
> dependencies, and probably reduces link overheads.  It can also
> produce better code, since intermodule references get trurned into
> intramodule references.  This just requires Makefile-hacking.

[...]

> Ideally, there'd be a configure flag to control "chunking".

Note that libgcj already supports an "--enable-libgcj-multifile"
configuration option that coarsely attempts to do the above.

See:

  http://gcc.gnu.org/ml/java-patches/2003-q3/msg00658.html

Ranjit.

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://ranjitmathew.hostingzero.com/

Re: [gomp] OpenMP IL design notes

[Dmitry Kurochkin]

Hi.

Looks good to me.

Also I hope to post new pragma handling mechanism patch in near
future. Currently I'm trying to find sparc/solaris box to make some
tests. This will require some minor changes to the parser. In
particular I plan to remove threadprivate handler from FE to a
separate handler which just sets TLS flag.

-- 
  Dmitry

Re: GCC 4.1 Status Report (2005-05-04)

[Dorit Naishlos]

> GCC 4.1 is going rather well thus far.
>
> Technically, Stage 1 ended on April 25th, though I failed to announce
> that.  There are a few stage 1 tasks that have not made it in yet,
> according to the Wiki:
>
> # Autovectorization Enhancements
> Items 1.4, 2.1, 2.3 (1.3)

Items 1.4 and 2.3 are in, right Devang?

2.1 depends on resolving the ssa-renaming issues that were raised in
several threads recently (related to assigning alias sets to pointers
created during vectorization I think?). Keith is working on this.

I also realized I left out part of Item 1.3 -
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01285.html:
"(2) Generate better code when different accesses are known to have the
same
misalignment, even if the misalignment amount itself is unknown.  This part
is deferred to stage 1.3 as it depends on:
[item 1.4] Consider dependence distance in the vectorizer (Devang)"
By the time Item 1.4 went in I totally forgot about this (sorry!). I think
this bit is also appropriate for stage 2 - it's really far from being a
major change. I'll be away for the next two weeks, Keith may submit it as
he may need this bit for Item 2.1 (versioning for alignment).

dorit


> # CFG Transparent Inlining, Profile-Guided Inlining (1.3)
> # Compilation Level Analysis of Types and Static Variables (1.3)
> # Pre-Inline Optimizations (1.3)
> # Structure Aliasing Part II (1.3)
> # Profiling on Trees, gcov on Trees (1.2)
>
> Which of these have not yet been submitted?  For those that have not
> been submitted, is a submission forthcoming shortly?  If not, I'm going
> to have to drop these from the 4.1 release plan.
>
> Certainly, we should consider ourselves in Stage 2 at this point.
> Significant changes are still fair game, but not *major* changes.
> Generally, things big enough to need their own branch should now be
> considered on hold for 4.2.
>
> Stage 2 was scheduled to end June 25th -- which happens to be during the
> GCC Summit.  That doesn't seem like a good idea, so let's push it back
> to July 8th.
>
> Regressions targeted at 4.1 -- but not any previous release -- number
> "only" 80.  However, a casual look suggests that there are at least some
> of those that should not in fact have a release target.  We do still
> have a lot of 4.0 regressions, though, that also apply to 4.1; I would
> encourage people to particularly target PRs that apply to both releases.
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> [EMAIL PROTECTED]
> (916) 791-8304