Re: Is there a way to specify profile data file directory?

[Nathan Sidwell]

H. J. Lu wrote:
Yes, that will work. Is anyone working on this? If not, we can take a
look.
I have not heard anything back from the original enquirer/volunteer over
a month ago.  I suggest GCOV_PREFIX as the variable name and simply
concatenate it to the absolute paths in the object file.  I'm not sure
about whether mkdir calls should be automatically performed, probably
yes.
You might want or need to get cleverer and have some way of indicating
how many initial directory names to strip off the hardwired absolute
paths.  Maybe this should be done by string matching or level counting.
Perhaps GCOV_PREFIX_STRIP would be a suitable name.
Use alloca rather than malloc, if at all possible please.  Thanks for
taking this up.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Merging stmt_ann_d into tree_statement_list_node

[Zdenek Dvorak]

Hello,

> I am thinking about merging stmt_ann_d into tree_statement_list_node.
>
> Background
> --
> 
> tree_statement_list_node is a linked list node defined like so
> 
> struct tree_statement_list_node {
>   struct tree_statement_list_node *prev;
>   struct tree_statement_list_node *next;
>   tree stmt;
> };
> 
> stmt_ann_d is an annotation for a statement ("stmt" above) that
> includes operand cache, the basic block that the statement belongs to,
> and various flags among other things.

guessing from (*) below, you probably just forgot to mention that it also
involves changing SSA_NAME_DEF_STMT to point to the
tree_statement_list_node rather than the statement itself,
otherwise there is no way how to get the
annotation for SSA_NAME_DEF_STMT (name)?

> Justifications
> --
> 
> o We have a 1:1 correspondence between tree_statement_list_node and
>   stmt_ann_d.  Why have separate data structures?
> 
> o Cache win.  Calling bsi_stmt loads tree_statement_list_node into
>   memory, which might in turn bring members of stmt_ann_d into cache.
>   Note that it's very common to call bsi_stmt and then do something
>   with operand cache while walking statements in a basic block.
> 
> o bsi_for_stmt becomes an O(1) operation.

(*)

>   Steven Bosscher says that
>   the CFG inliner will hit bsi_for_stmt hard.

This is just because CFG inliner is badly written; Honza has already
fixed that in his private tree.

> o Less memory management overhead.
> 
> o One step closer to a flat statement structure (or a tuple form if
>   you like).  It's a bit silly that we have GIMPLE, but we still do
>   not have a flat structure.
> 
> o We can probably remove get_stmt_ann and replace all uses of
>   stmt_ann.  No more lazy stmt_ann allocation.
> 
> Thoughts?

It is definitely a good idea, IMHO.

Zdenek

Re: Merging stmt_ann_d into tree_statement_list_node

[Steven Bosscher]

On Monday 25 April 2005 10:48, Zdenek Dvorak wrote:
> >   the CFG inliner will hit bsi_for_stmt hard.
>
> This is just because CFG inliner is badly written; Honza has already
> fixed that in his private tree.

The CFG inliner is badly written, sure, but the problem is before
that.  It's finding the calls to inline.  Right now we need to walk
the entire function looking for calls to inline.  That's dupli

Submission Status: CRX port ?

[Paul Woegerer]

Hi,

two weeks ago i've posted a new port to gcc-patches and it seems
that no global maintainer took a look at it so far. Maybe now that
the 4.0 is released there is someone who can take a look at it :)

I think i did a clean port that utilizes most of the latest machine
descripion standards (md-macros, md-predicates) and does not use any
deprecated mechanisms so it shouldn't be too painful to look at it.

I would also like to contribute to the GCC internals manual which
is very good but could be improved on some places (i used it alot
and i remember well were things were unclear to me - parts of my
port could also be used there as simple examples).

Thanks,
Paul



Paul Woegerer phone:  +49-8141-35-1385
CRTools Development   fax:+49-8141-35-1403
Cores Development Group   mailto: [EMAIL PROTECTED]

National Semiconductor GmbH
Livry-Gargan Str. 10
82256 Fuerstenfeldbruck, Germany
internet: http://www.national.com

Register allocation in GCC 4

[Jon Beniston]

Hi,

I'm updating a GCC port to 4.0.0. I am seeing a problem whereby registers
that are set to 1 in fixed_regs are being used. The problem is occuring
quite early on in the compiler, as the registers appear in the 00.expand
dump. The problem seems to occur for a DCmode value that is being allocated
to several registers. The first 4 of these registers are not in fixed_regs,
but the last 4 are (regs are 16-bit). I have made sure HARD_REGNO_MODE_OK
for all these registers returns 0, but that hasn't had an effect. Can anyone
suggest where I need to be looking to track this down? 

Cheers,
Jon

Re: Proposal: GCC core changes for different address spaces

[Etienne Lorrain]

Paul Schlie wrote:
> My impression is that there are 3 fundamental types of memory references:
>
> - literal-code (call/goto code-label/ptr)
> - literal-data (mem static-const-symbol/ptr)
> - runtime-data (mem non-static-const-symbol/ptr)
>
> As such it seems likely sufficient to simply enable the memory reference
> to these data classes to be identifiable during target specific linking
> and code generation to enable a broad class of Harvard memory architecture
> machines to be supported in addition to unified memory Von-Newman
> machines.

  I see a lot more address space than that in generic processors, not only
 embedded systems with EEPROM.

 For ia32, there is the IO port memory space, and it seem logical for me
 to do:
struct UART_str {
  unsigned char buffer;
  unsigned char flags;
  unsigned short speed;
  } __attribute__ ((section(IOPORT)));
 You have also the "Machine State Registers" (MSR) and the performance
 counters (PeMo) stuff. I would add segment relative address (cs, ds, fs,
 gs based address space) are separate - but just for my own set of problems.

 For PowerPC, you have the "Special Function Registers", accessed
 with mtspr/mfspr assembly instruction, and the "Device Control Register",
 accessed with mtdcr/mfdcr assembly instruction. Those regiters form
 complex data structure which are worth describing by C structures and
 bitfields if you do not want hundred of pages of #defines for masks
 and addresses. Note that the real reason they are in an orthogonal data
 space is that they shall not be cached like standard memory.

 I see also PCI space as a different memory space, you can have 32 or
 64 bits address space behind a pair of address/data "registers", and
 also PCI malloc-able area when you are looking for a free address range
 to map a device.

  That is not exactly what is being discussed here, I do not know how
 it fits the problem - but these are different address space, and having
 an address in one of those "memory space" is a valid concept, having
 some debug information for the debugger to display bits and enums
 in a human understandable form would be nice.

  Etienne.






__
Découvrez le nouveau Yahoo! Mail : 250 Mo d'espace de stockage pour vos mails ! 
Créez votre Yahoo! Mail sur http://fr.mail.yahoo.com/

Re: Built gcc 4.0.0, without C++ support

[Rainer Orth]

"Joseph S. Myers" <[EMAIL PROTECTED]> writes:

> I recommend using GNU as and Sun ld.  /usr/sfw/bin/as should be a suitable 
> version of the GNU assembler, or try the 2.15.97 binutils snapshot (from 
> ftp://gcc.gnu.org/pub/binutils/snapshots/) for an assembler which should 
> also be sufficiently recent (soon to be released as 2.16); I don't know if 

At least 2.15.96 gas didn't work for me with Sun ld: it failed building
libstdc++.so as Jeroen describes in a subsequent message.

> the 2.15 release is recent enough.  The version of GCC distributed in 
> /usr/sfw/bin is configured with
> 
> --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld 
> --without-gnu-ld --enable-languages=c,c++ --enable-shared
> 
> which should be a configuration which works for 4.0.0 and mainline, as 
> well as for csl-sol210-3_4-branch from which /usr/sfw/bin/gcc comes.

An unmodified gas from binutils 2.15 won't work since it doesn't support
x86_64.  That's what the CSL-built /usr/sfw/bin/gas (slightly modified
version of gas 2.15) adds.

Rainer

-- 
-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Built gcc 4.0.0, without C++ support

[Rainer Orth]

Jeroen Scheerder <[EMAIL PROTECTED]> writes:

> Partial success only.  I think I'll be able to build it without C++
> support, but compilation per your instruction does choke on 
> libstdc++.so.6.0.4.

I've had the same problem and think I know what's going on.

> ld: fatal: relocation error: file: .libs/stdexcept.o section: .rel.debug_info 
> symbol: : relocation against a discarded symbol,
> symbol is part of discarded section: 
> .gnu.linkonce.t._ZNSt12out_of_rangeD0Ev

If I compare stdexcept.s when building with /usr/sfw/bin/gas vs. gas
2.15.96, I see differences like the following:

 .Ltext0:
.weak   _ZTISt11logic_error
-   .section.gnu.linkonce.r._ZTISt11logic_error,"a",@progbits
+   .section
.gnu.linkonce.r._ZTISt11logic_error,"aG",@progbits,_ZTISt11logic_error,comdat

Comparing gcc/auto-host.h between bootstraps with those different gas
versions, I find:

 /* Define 0/1 if your assembler supports COMDAT group. */
-#define HAVE_GAS_COMDAT_GROUP 0
+#define HAVE_GAS_COMDAT_GROUP 1

So obviously Sun ld doesn't have the necessary support for COMDAT groups
(even with GNU ld, a quite recent version seems to be required).
Unfortunately, gcc's configure.ac doesn't check for this, but should.

Rainer

-- 
-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Built gcc 4.0.0, without C++ support

[Jeroen Scheerder]

Rainer Orth:

> Jeroen Scheerder <[EMAIL PROTECTED]> writes:
> 
> > Partial success only.  I think I'll be able to build it without C++
> > support, but compilation per your instruction does choke on 
> > libstdc++.so.6.0.4.
> 
> I've had the same problem and think I know what's going on.
> 
> > ld: fatal: relocation error: file: .libs/stdexcept.o section: 
> > .rel.debug_info symbol: : relocation against a discarded symbol,
> > symbol is part of discarded section: 
> > .gnu.linkonce.t._ZNSt12out_of_rangeD0Ev
> 
> If I compare stdexcept.s when building with /usr/sfw/bin/gas vs. gas
> 2.15.96, I see differences like the following:
> 
>  .Ltext0:
> .weak   _ZTISt11logic_error
> -   .section.gnu.linkonce.r._ZTISt11logic_error,"a",@progbits
> +   .section
> .gnu.linkonce.r._ZTISt11logic_error,"aG",@progbits,_ZTISt11logic_error,comdat
> 
> Comparing gcc/auto-host.h between bootstraps with those different gas
> versions, I find:
> 
>  /* Define 0/1 if your assembler supports COMDAT group. */
> -#define HAVE_GAS_COMDAT_GROUP 0
> +#define HAVE_GAS_COMDAT_GROUP 1
> 
> So obviously Sun ld doesn't have the necessary support for COMDAT groups
> (even with GNU ld, a quite recent version seems to be required).
> Unfortunately, gcc's configure.ac doesn't check for this, but should.

Your analysis is very convincing.  So an ugly workaround would be to
toggle HAVE_GAS_COMDAT_GROUP?

Re: Register allocation in GCC 4

[Nathan Sidwell]

Jon Beniston wrote:
Hi,
I'm updating a GCC port to 4.0.0. I am seeing a problem whereby registers
that are set to 1 in fixed_regs are being used. The problem is occuring
quite early on in the compiler, as the registers appear in the 00.expand
dump. The problem seems to occur for a DCmode value that is being allocated
to several registers. The first 4 of these registers are not in fixed_regs,
but the last 4 are (regs are 16-bit). I have made sure HARD_REGNO_MODE_OK
for all these registers returns 0, but that hasn't had an effect. Can anyone
suggest where I need to be looking to track this down? 
If I understand correctly the DCmode value occupies 8 registers, the last 4
of which are fixed regs.
HARD_REGNO_MODE_OK should return 0 for the first 4 too.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Register allocation in GCC 4

[Nathan Sidwell]

Nathan Sidwell wrote:
Jon Beniston wrote:
Hi,
I'm updating a GCC port to 4.0.0. I am seeing a problem whereby registers
that are set to 1 in fixed_regs are being used. The problem is occuring
quite early on in the compiler, as the registers appear in the 00.expand
dump. The problem seems to occur for a DCmode value that is being 
allocated
to several registers. The first 4 of these registers are not in 
fixed_regs,
but the last 4 are (regs are 16-bit). I have made sure HARD_REGNO_MODE_OK
for all these registers returns 0, but that hasn't had an effect. Can 
anyone
suggest where I need to be looking to track this down? 

If I understand correctly the DCmode value occupies 8 registers, the last 4
of which are fixed regs.
HARD_REGNO_MODE_OK should return 0 for the first 4 too.
oh, sorry you said that :)
stick a breakpoint where that rtl is being created.  I guess it must be
to do with function calling or some target machine thingy, as those are the
only places hard regs get mentioned before register allocation.
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: Built gcc 4.0.0, without C++ support

[Rainer Orth]

Jeroen Scheerder writes:

> > So obviously Sun ld doesn't have the necessary support for COMDAT groups
> > (even with GNU ld, a quite recent version seems to be required).
> > Unfortunately, gcc's configure.ac doesn't check for this, but should.
> 
> Your analysis is very convincing.  So an ugly workaround would be to
> toggle HAVE_GAS_COMDAT_GROUP?

I'd expect this to work, yes.

Rainer

Successful gcc4.0.0 build (Redhat 9. Kernel 2.4.25)

[Jeff Clifford]

make bootstrap successful build info:
config.guess states:
i686-pc-linux-gnu
gcc -v states:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /tmp/downloads/gcc-4.0.0/configure 
--prefix=/apps/Linux/gcc400 --program-suffix=400 
--with-local-prefix=/usr/include --enable-threads
Thread model: posix
gcc version 4.0.0

/etc/issue states:
Red Hat Linux release 9 (Shrike)
Kernel \r on an \m
uname -a states:
Linux parsley 2.4.25-3dneg #1 SMP Tue Sep 7 11:16:44 BST 2004 i686 i686 
i386 GNU/Linux  -- (This is essentially the 2.4.25 kernel with some nfs 
patches)

rpm -q glibc states:
glibc-2.3.2-11.9

Notes:
This build worked for installing sitewide over nfs fine.  --prefix and 
--program-suffix worked fine.

--with-local-prefix=/usr/include had to be specified as the default of 
/usr/local/include is not right for certain Linux distributions (like 
Redhat).


Jeff Clifford

RE: Register allocation in GCC 4

[Jon Beniston]

Hi Nathan,

> I guess 
> it must be to do with function calling 

Good call. I screwed up the conversion from FUNCTION_ARG_PARTIAL_NREGS to
TARGET_ARG_PARTIAL_BYTES.

Cheers,
Jon

Re: RFC: ms bitfields of aligned basetypes

[Joern RENNECKE]

Danny Smith wrote:
Jim Wilson wrote http://gcc.gnu.org/ml/gcc/2005-04/msg01172.html
 

Joern RENNECKE wrote: 
   

required for Tal16bool. Should we enforce that any storage element
 

allocated
 

for a run of ms-bitfields get the full alignment of the basetype,
 

even when it exceeds
 

the size of the basetype and of BIGGEST_ALIGNMENT? 
 

Obviously, we should do the exact same thing that the microsoft
   

compiler
 

does. That is the whole point of -mms-bitfields.
If we can't generate an equivalent testcase for the microsoft
   

compiler,
 

because it doesn't have aligned attributes or equivalent, then we can
   

do
 

whatever seems to make sense.
   

I believe the MS equivalent is __declspec (align (16)).  Could you test
the following patch to 
i386/cygming.h to see if you come closer to MS behaviour (I don't have a
MS compiler handy). 

Sorry, my time is currently taken up by some other work.
The background of my query was this: while doing regression the 
sh-elf-4_1 branch,
I found that some of the struct-layout superficial regressions were 
actually due to use of
unitialized memory in the ms-bitfield code, as reported before in PR 
middle-end/20371.
After applying the patch from December to the branch. I found some new 
regressions,
which led me to write an additional patch, which can be found in the PR 
as attachment
from the 15th April.  This new patch contains an gcc_assert that checks that
actual_align >= type_align whenever storage for a new run of bitfields 
is allocated.
This assert triggered for a number of the struct-layout cases, which 
lead to my query.
I found that a run of bitfields was allocated to only 64 bit alignment, 
even though the
type said it should be 128 bit aligned (although baed on bool).

I don't have a cygwin test platform, I have been doing sh64-elf 
regression tests using the
simulator available in the contrib directory of gdb.

Re: how small can gcc get?

[Paul Koning]

> "PhilipG" == Philip George <[EMAIL PROTECTED]> writes:

 >> What did you really mean?
 PhilipG> I need to install gcc into a disk image that will accompany
 PhilipG> a gui application i'm writing.

 PhilipG> ...the entire package (gui app + disk image with gcc) will be
 PhilipG> downloadable, so obviously i'm gonna need to get that gcc
 PhilipG> install down into the kilobytes range if possible...

Sounds hard.

Maybe you should start with pcc instead?  Or some other older
compiler?

paul

Re: GCC 4.0 RC2 Available

[Richard Earnshaw]

On Wed, 2005-04-20 at 01:18, Josh Conner wrote:
> On Apr 18, 2005, at 3:12 PM, Julian Brown wrote:
> 
> > Results for arm-none-elf, cross-compiled from i686-pc-linux-gnu 
> > (Debian)
> > for C and C++ are here:
> >
> > http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg01301.html
> >
> > Relative to RC1, there are several new tests which pass, and:
> >
> > g++.dg/warn/Wdtor1.C (test for excess errors)
> >
> > works whereas it didn't before.
> >
> > Julian
> >
> 
> Has there been any discussion of builtin-bitops-1.c failing for 
> arm-none-elf with RC1 + RC2?  It's a moderately serious regression from 
> 3.4.3 -- we're no longer correctly calculating the size of load double 
> instructions, and so the constant pool is generated at an address that 
> is out of range of the instructions that use them.  It will show up in 
> moderately large functions that use double word constants.

It's fixed on mainline and I'll probably backport the patch to 4.0.1. 
As I said at the time I committed the mainline patch, it was too
invasive to commit right before 4.0.0 was released.

It's been on mainline for a couple of weeks now, and I don't think it's
shown up any problems, so now is probably the right time to be
back-porting it.

R.

tree-cleanup-branch is now closed

[Diego Novillo]

The only thing left in the branch is the reorganization of the
pass pipeline, which is just a small patchlet.

The branch is now closed.


Diego.

Index: cvs.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/cvs.html,v
retrieving revision 1.189
diff -d -u -p -r1.189 cvs.html
--- cvs.html22 Apr 2005 15:05:49 -  1.189
+++ cvs.html25 Apr 2005 14:51:27 -
@@ -177,16 +177,6 @@ generally of the form "gcc-X_Y
   Daniel Berlin and Michael Matz are working on an implementation
   of a graph-coloring register allocator on this branch. It is known to
   bootstrap under x86-linux-gnu and ppc-linux-gnu.
-
-  tree-cleanup-branch
-  This branch contains improvements and reorganization to the
-  tree optimizers that were not ready in time for GCC 4.0.  The
-  goal is to cleanup the tree optimizers and improve the sequencing
-  of the passes.  The branch is maintained by Diego Novillo.
-  Patches and discussion related to the branch should be marked
-  with the tag [tcb] in the subject line.  The usual
-  contribution and testing rules apply.  Patches should be CC'd
-  to Diego Novillo for final approval.
  
   structure-aliasing-branch
   This branch contains improvements to the tree optimizers ability 
@@ -468,6 +458,12 @@ be prefixed with the initials of the dis
   This branch was for changes to G++ to be more compatible with
   ABI bugs in the HP-UX C++ compiler.  It is now unmaintained.
 
+  tree-cleanup-branch
+  This branch contained improvements and reorganization to the
+  tree optimizers that were not ready in time for GCC 4.0.  The
+  goal was to cleanup the tree optimizers and improve the sequencing
+  of the passes.  It has now been merged into mainline for the
+  4.1 release.
 
 
 Web pages

Propagating attributes for to structure elements (needed for different address spaces)

[Martin Koegler]

My current aproach, checking for the eeprom attribute in the GCC calculated 
types,
is not sufficient in some situations:
struct y1 {
int x;
};
struct x {
struct y1 y;
};
typedef struct x ax __attribute__ ((eeprom));
void test1(ax* x)
{
x->y.x=1;
}
In this case, while expanding x->y.x=1, the type of x->y is integer.
Even the expression, which the MEM_EXPR gets, contains not the information,
that the eeprom attribute is present. Similar problems occure, if pointers
to elements of structures (or pointer to array elements) are used.

The solution would be to add also for the base type of an array the eeprom 
attribute.
Additonally all elements of structures and unions must also have the eeprom 
attribute added.

As this is quite complicated to handle for a programmer, I tried to do this 
automatically
in the attribute handler:
static tree
m68hc05_handle_eeprom_attribute (tree * node, tree name,
 tree args ATTRIBUTE_UNUSED,
 int flags ATTRIBUTE_UNUSED,
 bool * no_add_attrs)
{
  gcc_assert(TYPE_P(*node));

  tree* type = (node);
  tree attr = tree_cons (name, args, NULL_TREE);
  tree* field;
  switch(TREE_CODE(*type))
{
case ARRAY_TYPE:
  *type=copy_node(*type);
  decl_attributes(&TREE_TYPE(*type),attr,0);
  break;
case RECORD_TYPE:
case UNION_TYPE:
case QUAL_UNION_TYPE:
  *type=copy_node(*type);
  for (field = &TYPE_FIELDS (*type); *field; field = &TREE_CHAIN (*field))
{
  decl_attributes(field,attr,0);
}
}

  return NULL_TREE;
}
This code is not correct, as it does not handle a lot of side effects and 
problems.
If I neglect the problems (DWARF-2 output totally broken, pointer type 
warnings,...), it
makes GCC pass the type information with the neccessary attribute information to
the RTL expanders.

Another alternative would be to implement backend specific qualifiers (like 
volatile) in the tree representation.
This would need large changes in GCC (at each location, where a new tree 
expression is created, these qualifiers
would also need to be set).

Any better ideas, how to solve this?

mfg Martin Kögler

Re: Built gcc 4.0.0, without C++ support

[Daniel Jacobowitz]

On Mon, Apr 25, 2005 at 12:28:18PM +0200, Rainer Orth wrote:
> If I compare stdexcept.s when building with /usr/sfw/bin/gas vs. gas
> 2.15.96, I see differences like the following:
> 
>  .Ltext0:
> .weak   _ZTISt11logic_error
> -   .section.gnu.linkonce.r._ZTISt11logic_error,"a",@progbits
> +   .section
> .gnu.linkonce.r._ZTISt11logic_error,"aG",@progbits,_ZTISt11logic_error,comdat
> 
> Comparing gcc/auto-host.h between bootstraps with those different gas
> versions, I find:
> 
>  /* Define 0/1 if your assembler supports COMDAT group. */
> -#define HAVE_GAS_COMDAT_GROUP 0
> +#define HAVE_GAS_COMDAT_GROUP 1
> 
> So obviously Sun ld doesn't have the necessary support for COMDAT groups
> (even with GNU ld, a quite recent version seems to be required).
> Unfortunately, gcc's configure.ac doesn't check for this, but should.

So you're using gas with the Sun linker?  Yes, the configure check
definitely needs to test both as and ld.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Built gcc 4.0.0, without C++ support

[Jeroen Scheerder]

Daniel Jacobowitz:

[...]

> > So obviously Sun ld doesn't have the necessary support for COMDAT groups
> > (even with GNU ld, a quite recent version seems to be required).
> > Unfortunately, gcc's configure.ac doesn't check for this, but should.
> 
> So you're using gas with the Sun linker?  Yes, the configure check
> definitely needs to test both as and ld.

Yes, I do, per Joseph S. Myers' instructions:

""
I recommend using GNU as and Sun ld.  /usr/sfw/bin/as should be a suitable
version of the GNU assembler, or try the 2.15.97 binutils snapshot (from
ftp://gcc.gnu.org/pub/binutils/snapshots/) for an assembler which should
also be sufficiently recent [..]
""

Note that no other combination will even bootstrap.  GNU ld stumbles
upon a Sun-supplied crt*.o file, and Sun's as chokes on the generated
assembly (x86_64 instructions it fails to handle?).


Regards, Jeroen.

Re: Built gcc 4.0.0, without C++ support

[Rainer Orth]

Daniel Jacobowitz writes:

> > So obviously Sun ld doesn't have the necessary support for COMDAT groups
> > (even with GNU ld, a quite recent version seems to be required).
> > Unfortunately, gcc's configure.ac doesn't check for this, but should.
> 
> So you're using gas with the Sun linker?  Yes, the configure check
> definitely needs to test both as and ld.

Indeed: at least for a Solaris 10/x86 multilib configuration, the native as
doesn't work yet, and even if running 32-bit only with --disable-multilib,
one needs the still unreviewed patch

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02101.html

for bootstrap to succeed.

Unfortunately, I have no idea of the exact requirements from ld to develop
a configure check myself.

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Built gcc 4.0.0, without C++ support

[Daniel Jacobowitz]

On Mon, Apr 25, 2005 at 05:05:32PM +0200, Jeroen Scheerder wrote:
> Daniel Jacobowitz:
> 
> [...]
> 
> > > So obviously Sun ld doesn't have the necessary support for COMDAT groups
> > > (even with GNU ld, a quite recent version seems to be required).
> > > Unfortunately, gcc's configure.ac doesn't check for this, but should.
> > 
> > So you're using gas with the Sun linker?  Yes, the configure check
> > definitely needs to test both as and ld.
> 
> Yes, I do, per Joseph S. Myers' instructions:
> 
> ""
> I recommend using GNU as and Sun ld.  /usr/sfw/bin/as should be a suitable
> version of the GNU assembler, or try the 2.15.97 binutils snapshot (from
> ftp://gcc.gnu.org/pub/binutils/snapshots/) for an assembler which should
> also be sufficiently recent [..]
> ""
> 
> Note that no other combination will even bootstrap.  GNU ld stumbles
> upon a Sun-supplied crt*.o file, and Sun's as chokes on the generated
> assembly (x86_64 instructions it fails to handle?).

GNU ld ought to work; what's the error look like?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Merging stmt_ann_d into tree_statement_list_node

[Andrew MacLeod]

On Mon, 2005-04-25 at 04:48, Zdenek Dvorak wrote:
> Hello,
> 
> > I am thinking about merging stmt_ann_d into tree_statement_list_node.
> >
> > Background
> > --
> > 
> > tree_statement_list_node is a linked list node defined like so
> > 
> > struct tree_statement_list_node {
> >   struct tree_statement_list_node *prev;
> >   struct tree_statement_list_node *next;
> >   tree stmt;
> > };
> > 
> > stmt_ann_d is an annotation for a statement ("stmt" above) that
> > includes operand cache, the basic block that the statement belongs to,
> > and various flags among other things.
> 
> guessing from (*) below, you probably just forgot to mention that it also
> involves changing SSA_NAME_DEF_STMT to point to the
> tree_statement_list_node rather than the statement itself,
> otherwise there is no way how to get the
> annotation for SSA_NAME_DEF_STMT (name)?

It will also involve figuring out what to do with DOM, which has some
hacks via a call to create_ssa_artficial_load_stmt() which causes a
non-stmt to have a stmt annotation and operands created for it.  I've
been bugging Diego to replace the parts of DOM which use this so we can
remove the hideous abberation, but it still exists at this point. 

I believe DOM uses the routine to create a dummy expression for a store
which looks like a load. This load is then entered into the equivalency
tables such that the store of the expression also shows up as a load
allowing subsequent loads to be subsumed.  Or something like that
anyway.  Bottom line is it creates a stmt annotation and operands for an
expression which is not in any stmt list.

Andrew

Re: Built gcc 4.0.0, without C++ support

[Jeroen Scheerder]

Daniel Jacobowitz:

[...]

> > Note that no other combination will even bootstrap.  GNU ld stumbles
> > upon a Sun-supplied crt*.o file, and Sun's as chokes on the generated
> > assembly (x86_64 instructions it fails to handle?).
> 
> GNU ld ought to work; what's the error look like?

/usr/lib/amd64/crti.o: file not recognized: File format not recognized

This is with ld 2.15.97, the most recent one I could find.

Re: Built gcc 4.0.0, without C++ support

[Rainer Orth]

Jeroen Scheerder writes:

> Note that no other combination will even bootstrap.  GNU ld stumbles
> upon a Sun-supplied crt*.o file, and Sun's as chokes on the generated
> assembly (x86_64 instructions it fails to handle?).

There are several issues with the native as, discussed in

http://gcc.gnu.org/ml/gcc-patches/2004-11/msg00908.html

where I tried to bootstrap the csl-sol210-branch with Sun as.  A few of
them can easily be avoided

http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02101.html

but several more probably require as changes from Sun.

Rainer

-
Rainer Orth, Faculty of Technology, Bielefeld University

Re: Propagating attributes for to structure elements (needed for different address spaces)

[Joseph S. Myers]

On Mon, 25 Apr 2005, Martin Koegler wrote:

> The solution would be to add also for the base type of an array the 
> eeprom attribute. Additonally all elements of structures and unions must 
> also have the eeprom attribute added.

The solution is to implement DTR18037 named address spaces.  Naturally 
such implementation involves implementing the proper semantics for the 
types of structure element references.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Proposal: GCC core changes for different address spaces

[Paul Schlie]

> Etienne Lorrain <[EMAIL PROTECTED]> wrote:
> I see a lot more address space than that in generic processors, not only
> embedded systems with EEPROM.

- Almost, but they aren't "memory spaces" in the sense that programming
  languages expect them to be, as they impose implied restrictive semantics
  that are not understood by the languages/compilers. Therefore are truly
  distinct. For example, what do these declarations mean? At what addresses
  would you expect them to be allocated to? The problem is that it matters,
  as they aren't truly memory spaces which correspond to distinct classes
  of objects which the language already understands.
  
EEPROM static int * x;
IOPORT complex y;

  And may already be satisfied by defining target specific functions which
  map logical program values to specific semantics, satisfy all examples
  below even if it requires the specification of target specific assembly
  I/O routines to act as an interface; so it's not clear if anything further
  is required. i.e. : (write_i_o dest value), or may be specified somewhat
  more naturally in C++ by overloading operators, to understand what to do
  when an IO type object is written for example.
  
  Which is very different from saying for example that a back end should
  be able to map (independently of the language) code into one address
  space, literal data into another, and runtime allocated variables into
  a third for example, which only requires that such declarations and
  corresponding references be visible during code generation (which can't
  be satisfied without internal cooperation from the complier with the
  target specific code generator).

> For ia32, there is the IO port memory space, and it seem logical for me
> to do:
> struct UART_str {
>  unsigned char buffer;
>  unsigned char flags;
>  unsigned short speed;
>  } __attribute__ ((section(IOPORT)));
> You have also the "Machine State Registers" (MSR) and the performance
> counters (PeMo) stuff. I would add segment relative address (cs, ds, fs,
> gs based address space) are separate - but just for my own set of problems.
>
> For PowerPC, you have the "Special Function Registers", accessed
> with mtspr/mfspr assembly instruction, and the "Device Control Register",
> accessed with mtdcr/mfdcr assembly instruction. Those regiters form
> complex data structure which are worth describing by C structures and
> bitfields if you do not want hundred of pages of #defines for masks
> and addresses. Note that the real reason they are in an orthogonal data
> space is that they shall not be cached like standard memory.
>
> I see also PCI space as a different memory space, you can have 32 or
> 64 bits address space behind a pair of address/data "registers", and
> also PCI malloc-able area when you are looking for a free address range
> to map a device.
>
>  That is not exactly what is being discussed here, I do not know how
> it fits the problem - but these are different address space, and having
> an address in one of those "memory space" is a valid concept, having
> some debug information for the debugger to display bits and enums
> in a human understandable form would be nice.

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Zdenek,

> guessing from (*) below, you probably just forgot to mention that it also
> involves changing SSA_NAME_DEF_STMT to point to the
> tree_statement_list_node rather than the statement itself,
> otherwise there is no way how to get the
> annotation for SSA_NAME_DEF_STMT (name)?

I am not planning to change SSA_NAME_DEF_STMT yet.  If stmt_ann is
embedded into tree_statement_list_node, we can compute the address of
tree_statement_list_node from that of stmt_ann.  I am planning to keep
a pointer from a statement proper to a stmt_ann for now.

> It is definitely a good idea, IMHO.

Thanks!

I might need your help later as a loop optimizer expert.  I just found
yesterday that tree-ssa-loop-im.c:schedule_sm is using stmt_ann before
a statement proper is linked to a basic block.  Specifically, it
creates a statement, attaches a stmt_ann, and puts it on edge.  We
probably have to one of the following.

1) delay the creation of stmt_ann until after a statement is linked,

2) create a stmt_ann just like we do now, and then copy its contents
   to stmt_ann embedded in tree_statement_list_node, or

3) create a tree_statement_list_node in schedule_sm, which contains
   stmt_ann, and link it to a basic block.  (This option would require
   bigger changes as we are currently supposed to put a statement in
   PENDING_STMT, not a tree_statement_list_node.  Plus, bsi_insert_*
   and tsi_link_* stuff all expect a statement.)

Right now I am just instrumenting stmt_ann to see where people are
using stmt_ann while a statement is not linked to a basic block.

Kazu Hirata

Re: Merging stmt_ann_d into tree_statement_list_node

[Andrew MacLeod]

On Mon, 2005-04-25 at 11:32, Kazu Hirata wrote:

> I might need your help later as a loop optimizer expert.  I just found
> yesterday that tree-ssa-loop-im.c:schedule_sm is using stmt_ann before
> a statement proper is linked to a basic block.  Specifically, it
> creates a statement, attaches a stmt_ann, and puts it on edge.  We
> probably have to one of the following.
> 
> 1) delay the creation of stmt_ann until after a statement is linked,
> 
> 2) create a stmt_ann just like we do now, and then copy its contents
>to stmt_ann embedded in tree_statement_list_node, or
> 
> 3) create a tree_statement_list_node in schedule_sm, which contains
>stmt_ann, and link it to a basic block.  (This option would require
>bigger changes as we are currently supposed to put a statement in
>PENDING_STMT, not a tree_statement_list_node.  Plus, bsi_insert_*
>and tsi_link_* stuff all expect a statement.)
> 
> Right now I am just instrumenting stmt_ann to see where people are
> using stmt_ann while a statement is not linked to a basic block.

These are in fact issues with immediate_uses too.  I fixed the ones I
found that were causing problems, but the stmt annotation and operands
should *NOT* be created until a stmt is actually linked the program via
a bsi_ routine or some such thing. 

Andrew

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Andrew,

> It will also involve figuring out what to do with DOM, which has some
> hacks via a call to create_ssa_artficial_load_stmt() which causes a
> non-stmt to have a stmt annotation and operands created for it.  I've
> been bugging Diego to replace the parts of DOM which use this so we can
> remove the hideous abberation, but it still exists at this point. 
> 
> I believe DOM uses the routine to create a dummy expression for a store
> which looks like a load. This load is then entered into the equivalency
> tables such that the store of the expression also shows up as a load
> allowing subsequent loads to be subsumed.  Or something like that
> anyway.  Bottom line is it creates a stmt annotation and operands for an
> expression which is not in any stmt list.

Does this standalone stmt_ann end up in the instruction stream?  That
is, are we going to have a statement as a part of a basic block whose
stmt_ann is the one created in create_ssa_artficial_load_stmt?

If not, I guess we can let DOM do what it wants to do because I am
currently thinking about simply embedding stmt_ann into
tree_statement_list_node like so.

struct tree_statement_list_node
  GTY ((chain_next ("%h.next"), chain_prev ("%h.prev")))
{
  struct tree_statement_list_node *prev;
  struct tree_statement_list_node *next;
  tree stmt;
  struct stmt_ann_d ann;
};

Though leaving this standalone stmt_ann as isn't probably the cleanest
thing to do.  Eventually, I want to completely hide
creation/destruction of stmt_ann from applications (or optimizers if
you like) of the infrastructure.

If this standalone stmt_ann does end up in the instruction stream, we
could structure-copy stmt_ann for the time being (yuck!).

Kazu Hirata

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Andrew,

> > I might need your help later as a loop optimizer expert.  I just found
> > yesterday that tree-ssa-loop-im.c:schedule_sm is using stmt_ann before
> > a statement proper is linked to a basic block.  Specifically, it
> > creates a statement, attaches a stmt_ann, and puts it on edge.  We
> > probably have to one of the following.
> > 
> > 1) delay the creation of stmt_ann until after a statement is linked,
> > 
> > 2) create a stmt_ann just like we do now, and then copy its contents
> >to stmt_ann embedded in tree_statement_list_node, or
> > 
> > 3) create a tree_statement_list_node in schedule_sm, which contains
> >stmt_ann, and link it to a basic block.  (This option would require
> >bigger changes as we are currently supposed to put a statement in
> >PENDING_STMT, not a tree_statement_list_node.  Plus, bsi_insert_*
> >and tsi_link_* stuff all expect a statement.)
> > 
> > Right now I am just instrumenting stmt_ann to see where people are
> > using stmt_ann while a statement is not linked to a basic block.
> 
> These are in fact issues with immediate_uses too.  I fixed the ones I
> found that were causing problems, but the stmt annotation and operands
> should *NOT* be created until a stmt is actually linked the program via
> a bsi_ routine or some such thing. 

Ah, so we should go with 1) above wherever possible.  Once these uses
of stmt_ann are fixed, we can arrange things so that we *CANNOT
POSSIBLY* create stmt_ann and operands (except maybe in
create_ssa_artficial_load).  Then the actual work of embedding
stmt_ann into tree_statement_list_node shouldn't be difficult.

Kazu Hirata

Re: Propagating attributes for to structure elements (needed for different address spaces)

[Martin Koegler]

On Mon, Apr 25, 2005 at 03:22:31PM +, Joseph S. Myers wrote:
> On Mon, 25 Apr 2005, Martin Koegler wrote:
> 
> > The solution would be to add also for the base type of an array the 
> > eeprom attribute. Additonally all elements of structures and unions must 
> > also have the eeprom attribute added.
> 
> The solution is to implement DTR18037 named address spaces.  Naturally 
> such implementation involves implementing the proper semantics for the 
> types of structure element references.

As I don't know DTR18037 and have no access to it (even Google finds nothing 
useable about it), I
cannot say something about it.

I intend to create different address spaces in GCC using attributes, with only 
small changes in the core.
As I test my ideas on my m68hc05 port, I describe my intended semantics using 
it,
which is (apart for the problem with the incorrect types) already working:


// shortcut for the attribute to write more compact
#define E __attribute__ ((eeprom))

// An integer in the eeprom
// for my port, I do the section selection using an other attribute
int x E;

typedef int eint E;
struct x{
int x;
int y;
}
struct y{
int x;
struct x y;
}
typedef struct y ey E;

struct y z E;
struct y z1;
int a[5] E;

eint* a1;
int* a2;
int tmp;

tmp=z.y.x; //do a load from the eeprom, in my case the same as a normal load
z.y.x=2; //do a store to the eeprom

a2=&z.y.x; //assignment of incompatible pointers
*a2=1; //undefined

a1=&z.y.x; 
*a1=1; // write to eeprom at z.y.x

a[2]=1; // write to eeprom
a1=a+1; // ok
*a1=3; // write to a[1] in eeprom
a2=a+1 //assignment of incomatible pointers
*a1=3 //undefined
 
void test(ey* ptr)
{
ptr->x=1; // write to eeprom
}

test(&z); //call test with z -> write 1 to z.x in the eeprom.

z1=z // fails currently with a type error, but this should also work (copy from 
eeprom to z1)

In the case of my port, a read using a normal pointer, which is load from a 
eeprom pointer, will succeed,
in the case of AVR, such a operation will also be undefined.

mfg Martin Kögler
[EMAIL PROTECTED]

Re: Merging stmt_ann_d into tree_statement_list_node

[Andrew MacLeod]

On Mon, 2005-04-25 at 12:00, Kazu Hirata wrote:
> Hi Andrew,

> > I believe DOM uses the routine to create a dummy expression for a store
> > which looks like a load. This load is then entered into the equivalency
> > tables such that the store of the expression also shows up as a load
> > allowing subsequent loads to be subsumed.  Or something like that
> > anyway.  Bottom line is it creates a stmt annotation and operands for an
> > expression which is not in any stmt list.
> 
> Does this standalone stmt_ann end up in the instruction stream?  That
> is, are we going to have a statement as a part of a basic block whose
> stmt_ann is the one created in create_ssa_artficial_load_stmt?

no. It never gets linked in, and as such, the immediate use info never
gets entered either (which is the way we want it). its a hack of the
grandest sort. 

> 
> If not, I guess we can let DOM do what it wants to do because I am
> currently thinking about simply embedding stmt_ann into
> tree_statement_list_node like so.
> 
> struct tree_statement_list_node
>   GTY ((chain_next ("%h.next"), chain_prev ("%h.prev")))
> {
>   struct tree_statement_list_node *prev;
>   struct tree_statement_list_node *next;
>   tree stmt;
>   struct stmt_ann_d ann;
> };
> 

well, there isnt a tree_statement_list_node right... DOM simply has an
expression, and we end up calling create_stmt_ann.  I guess you would
have to create a completely detached stmt_list node for this case.  what
are you planning to have create_stmt_ann do? 
 
> Though leaving this standalone stmt_ann as isn't probably the cleanest
> thing to do.  Eventually, I want to completely hide
> creation/destruction of stmt_ann from applications (or optimizers if
> you like) of the infrastructure.
> 

I eventually want to see this entire routine go away. The only reason
DOM wants it is so that it can scan the operands like it does for a real
stmt. noone else needs to do such a thing.. Presumably the overhead of
actually inserting these loads immediately after the store and deleting
them later is too high...   Ive never looked at the details of what DOM
does with the info.  if it only needs the operands for a short time, a
different interface could be provided which returns the operands in a 
VEC or something. I just never felt like looking at DOM too heavily.


> If this standalone stmt_ann does end up in the instruction stream, we
> could structure-copy stmt_ann for the time being (yuck!).

well, if it ended up in the instruction stream, it wouldn't matter,
because then it would simply be another stmt like any other. The fact
that it isnt a stmt, and DOM insists on treating it like it is, is what
causes the problem. 

Andrew

Re: Propagating attributes for to structure elements (needed for different address spaces)

[Joseph S. Myers]

On Mon, 25 Apr 2005, Martin Koegler wrote:

> As I don't know DTR18037 and have no access to it (even Google finds nothing 
> useable about it), I
> cannot say something about it.

The current version is WG14 N1095 
.  It's the 
standard way of describing named address spaces, insofar as there is one.

-- 
Joseph S. Myers   http://www.srcf.ucam.org/~jsm28/gcc/
[EMAIL PROTECTED] (personal mail)
[EMAIL PROTECTED] (CodeSourcery mail)
[EMAIL PROTECTED] (Bugzilla assignments and CCs)

Re: Build of GCC 4.0.0 successful

[Janis Johnson]

On Fri, Apr 22, 2005 at 02:36:38PM -0400, William Beebe wrote:
> I've bootstrap built GCC 4.0.0 on Fedora Core 3.
> 
> [EMAIL PROTECTED] ~]$ gcc -v
> Using built-in specs.
> Target: athlon-fedora-linux

What is the output of config.guess?

Re: IA64 Pointer conversion question / convert code already wrong?

[Steve Ellcey]

> Also, I think convert_memory_address ought to have a
>   gcc_assert (GET_MODE (x) == to_mode);
> in the #ifndef case.

Interesting, I put this assertion in my code and I now cannot bootstrap
on HPPA.  Looking at the HPPA builds (where POINTERS_EXTEND_UNSIGNED if
not defined) I see the assertion fail because I enter
convert_memory_address with to_mode set to SImode and x set to
'(const_int 0 [0x0])'.

The call to convert_memory_address is being made from memory_address
(explow.c:404).

I am not sure if this is a bug, or if convert_memory_address should
allow this by doing nothing (current behaviour) or if
convert_memory_address should be changed so that it does the same
conversion on const_int values when POINTERS_EXTEND_UNSIGNED is
undefined as it does when POINTERS_EXTEND_UNSIGNED is defined.

Steve Ellcey
[EMAIL PROTECTED]

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Andrew,

> well, there isnt a tree_statement_list_node right... DOM simply has an
> expression, and we end up calling create_stmt_ann.  I guess you would
> have to create a completely detached stmt_list node for this case.  what
> are you planning to have create_stmt_ann do? 

I am thinking about leaving create_stmt_ann as is just for
create_ssa_artficial_load_stmt.  Other than that, I don't want to call
create_stmt_ann.  I am planning to allocate stmt_ann as a part of
tree_statement_list_node.  That is, if I have this

struct tree_statement_list_node
  GTY ((chain_next ("%h.next"), chain_prev ("%h.prev")))
{
  struct tree_statement_list_node *prev;
  struct tree_statement_list_node *next;
  tree stmt;
  struct stmt_ann_d ann;
};

then tsi_link_after and tsi_link_before would allocate the right
amount of memory because they have

  head = ggc_alloc (sizeof (*head));

where head is a a pointer to tree_statement_list_node.  I still have
to initialize members of stmt_ann_d.  I believe all I have to do is

  memset (ann, 0, sizeof (ann));
  ann.common.type = STMT_ANN;
  ann.modified = true;

> I eventually want to see this entire routine go away. The only reason
> DOM wants it is so that it can scan the operands like it does for a real
> stmt. noone else needs to do such a thing.. Presumably the overhead of
> actually inserting these loads immediately after the store and deleting
> them later is too high...   Ive never looked at the details of what DOM
> does with the info.  if it only needs the operands for a short time, a
> different interface could be provided which returns the operands in a 
> VEC or something. I just never felt like looking at DOM too heavily.

I guess we can come back to this once stmt_ann is merged into
tree_statement_list_node.  I don't feel like mixing infrastructure
work and optimizer work.

By the way, I just realized you were planning to do "New SSA Operand
Cache Implementation" in stage 2, which is starting tomorrow.  Would I
be stepping on your toes?  I am not planning to change the members of
stmt_ann, so hopefully my work won't interfere with yours, but if it
does, please let me know.

Kazu Hirata

Re: IA64 Pointer conversion question / convert code already wrong?

[Richard Kenner]

> Also, I think convert_memory_address ought to have a
>   gcc_assert (GET_MODE (x) == to_mode);
> in the #ifndef case.

Interesting, I put this assertion in my code and I now cannot
bootstrap on HPPA.  Looking at the HPPA builds (where
POINTERS_EXTEND_UNSIGNED if not defined) I see the assertion fail
because I enter convert_memory_address with to_mode set to SImode and
x set to '(const_int 0 [0x0])'.

This is fine, but not a case I thought about when I suggested the above.

The correct is
gcc_assert (GET_MODE (x) == to_mode || GET_MODE (x) == VOIDmode);

Sorry!

Re: Merging stmt_ann_d into tree_statement_list_node

[Andrew MacLeod]

On Mon, 2005-04-25 at 14:37, Kazu Hirata wrote:
> Hi Andrew,
> 
> > well, there isnt a tree_statement_list_node right... DOM simply has an
> > expression, and we end up calling create_stmt_ann.  I guess you would
> > have to create a completely detached stmt_list node for this case.  what
> > are you planning to have create_stmt_ann do? 
> 
> I am thinking about leaving create_stmt_ann as is just for
> create_ssa_artficial_load_stmt.  Other than that, I don't want to call
> create_stmt_ann.  I am planning to allocate stmt_ann as a part of
> tree_statement_list_node.  That is, if I have this

How is the get_stmt_ann (stmt) going to work from the caller of
create_ssa_artificial_load_stmt() when it goes to look at the operands
for its new "stmt"?   

The annotation was simply attached to the stmt before, so it was easy to
locate.  There is no bsi_for_stmt() since it isnt a real stmt, so you
can't get to a stmt_list node that way either.  Im not sure how you 
would locate the annoation for a fake stmt like this.  
 
And DOM treats it like a real stmt by calling the same routines, so I
dont know how you could change this without first making DOM do
something different.


> 
> I guess we can come back to this once stmt_ann is merged into
> tree_statement_list_node.  I don't feel like mixing infrastructure
> work and optimizer work.
> 

Im not sure you can do it in that order without breaking DOM.


> By the way, I just realized you were planning to do "New SSA Operand
> Cache Implementation" in stage 2, which is starting tomorrow.  Would I
> be stepping on your toes?  I am not planning to change the members of
> stmt_ann, so hopefully my work won't interfere with yours, but if it
> does, please let me know.


I have the patch done, I'm evaluating whether its worth using or not.

I doubt you would be stepping on my toes any more than the annoyance of
diffs not applying all over the place like they did with
get_stmt_operands() being removed.

Andrew

Re: Merging stmt_ann_d into tree_statement_list_node

[Zdenek Dvorak]

Hello,

> > o One step closer to a flat statement structure (or a tuple form if
> >   you like).  It's a bit silly that we have GIMPLE, but we still do
> >   not have a flat structure.

on a side note, I am currently working on cleaning up gimplification
(mostly to enable embedding of simple and fast cleanup passes like local
value numbering, copy/constant propagation and unreachable code
removal).  As a side effect, this will cause gimplifier to directly
produce gimple statements instead of gradually rewriting the function
tree.  I will tell more about this project on GCC summit.

Once this is done, I would like to start working on moving gimple out of
trees to the "flat" structure.

Zdenek

Store scheduling with DFA scheduler

[Jon Beniston]

Hi,

I'm trying to get the DFA scheduler in GCC 4.0.0 to schedule loads and
stores, but I can only get it to work for loads. I have an automaton defined
as follows:

(define_automaton "cpu")

(define_cpu_unit "x" "cpu")
(define_cpu_unit "m" "cpu")

(define_insn_reservation "arith" 1 (eq_attr "type" "arith") "x")
(define_insn_reservation "loads" 2 (eq_attr "type" "load") "x,m")
(define_insn_reservation "stores" 3 (eq_attr "type" "store") "x,m*2")

All instructions take one cycle in "x". Loads then take one "m" cycle, while
stores take two "m" cycles. Basically stores aren't fully pipelined.

If I compile the following code:

int x, y, z, w;
void main()
{
 x = x + 1;
 y = y + 1;
 z = z + 1;
 w = w + 1;
}

I get the following output:

 lhu  r4, [x]
 lhu  r5, [y]
 lhu  r6, [z]
 lhu  r7, [w]
 add  r4, 1  
 add  r5, 1  
 add  r6, 1  
 add  r7, 1  
 sh   [x], r4
 sh   [y], r5
 sh   [z], r6
 sh   [w], r7

This therefore seems to be scheduling loads correctly, as before I added the
automaton I was getting adds immediately following loads, but doesn't seem
to be scheduling the stores correctly, as they are scheduledin consequtive
slots. I would expect the optimial schedule to be something along the lines
of:

 lhu  r4, [x]
 lhu  r5, [y]
 lhu  r6, [z]
 lhu  r7, [w]
 add  r4, 1  
 sh   [x], r4 
 add  r5, 1  
 sh   [y], r5
 add  r6, 1  
 sh   [z], r6
 add  r7, 1  
 sh   [w], r7

I'd be greatful for any suggestions as to what the problem might be.

Cheers,
Jon

Side-effect latency in DFA scheduler

[Jon Beniston]

Hi,

How is the latency of instructions that have side effects modeled in the DFA
scheduler. For example, define_insn_reservation only has one latency value,
yet instructions such as loads with post increment addressing have two
outputs, possibly with different latencies. Do both outputs get the same
latency?

Is there an option similar to -dp that outputs what latency the compiler has
used for each instruction?

Cheers,
Jon

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Zdenek,

> Once this is done, I would like to start working on moving gimple out of
> trees to the "flat" structure.

Very cool!  I am glad you'll be working on this!

Kazu Hirata

Re: The subreg question

[James E Wilson]

Ling-hua Tseng wrote:
   (Does (high:SI ...) have the semantic of clearing LSB 16-bit ? )
Storing an SImode value into an SImode reg will set the entire register, 
unless you are using subreg/zero_extract/etc on the destination.  So 
yes, this will clear the low order bits, where the number of low order 
bits cleared is machine dependent.

   [(set (high:SI (match_operand:SI 0 "register_operand" "=r"))
   (high:SI (match_operand:SI 1 "immediate_operand" "i")))
You can't use HIGH in a destination.  Do something like this:
   (set (op 0)
 (ior:SI (high:SI (op 1)
 (zero_extend:SI (subreg:HI (op 0)
   3. set LSB 16-bit and clear MSB 16-bit to zero
   [(set (match_operand:SI 0 "register_operand" "=r")
   (match_operand:HI 1 "immediate_operand" "i"))]
You can't mix modes like this.  The source and destination have to have 
the same mode.  Also, immediates don't have modes, so trying to take an 
HImode immediate makes no sense.  This should just be something like
  (set (match_op:SI 0 ... "=r")
   (match_op:SI 1 ... "J"))
where 'J' is defined via CONST_OK_FOR_LETTER_P to be a constant that can 
fit in 16 bits (zero extended).

   4. set LSB 16-bit and unchange/keep LSB 16-bit
   [(set (strict_lowpart (subreg:HI (match_operand:SI 0 
"register_operand" "=r") 0))
   (match_operand:HI "immediate_operand" "i"))]
   (Would it better than use (lo_sum:SI ...) ? )
Using strict_low_part like this is OK.
Using lo_sum is probably not useful here, since you aren't doing an 
addition.

lo_sum is primarily useful when setting an entire register with two 
operations, one of which is a high.  E.g. if you have
  (set (op 0) (high: (op 1)))
  (set (op 0) (lo_sum (op 0) (op 1)))
then the RTL optimizatize will know that this is equivalent to
  (set (op 0) (op 1))
If you mix high with strict_low_part, the optimizer will not be able to 
do anything with this.

Even though your instructions technically isn't an add, use of lo_sum is 
probably safe here.  The optimizer doesn't do anything else with a 
lo_sum other than simplify it with high, and since high clears the low 
bits, conceptually an addition is safe here as it can't overflow the low 
bits if you are adding with zero.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Some small optimization issues with gcc 4.0 20050418

[James E Wilson]

Sebastian Biallas wrote:
You don't need to reserve a stack slot for the return address on x86.
The stack slot will be allocated implicitly by the "call" instruction.
OK, then this must be a similar issue to the register saves in the 
prologue.  There is confusion between calculating the frame size, and 
calculating the amount to subtract from the stack pointer.  These are 
not the same on x86 because some values are being pushed on the stack.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Is there a way to specify profile data file directory?

[H. J. Lu]

On Mon, Apr 25, 2005 at 08:47:50AM +0100, Nathan Sidwell wrote:
> H. J. Lu wrote:
> 
> >
> >Yes, that will work. Is anyone working on this? If not, we can take a
> >look.
> 
> I have not heard anything back from the original enquirer/volunteer over
> a month ago.  I suggest GCOV_PREFIX as the variable name and simply
> concatenate it to the absolute paths in the object file.  I'm not sure
> about whether mkdir calls should be automatically performed, probably
> yes.

make_class_file_name in gcc/java/jcf-write.c creates a directory if it
doesn't exist. Should we create a new file for it in gcc or in
libiberty?

> 
> You might want or need to get cleverer and have some way of indicating
> how many initial directory names to strip off the hardwired absolute
> paths.  Maybe this should be done by string matching or level counting.
> Perhaps GCOV_PREFIX_STRIP would be a suitable name.

Level counting sounds good to me. We can have GCOV_PREFIX_STRIP=N
and make N == 0 as the default.

> 
> Use alloca rather than malloc, if at all possible please.  Thanks for
> taking this up.
> 



H.J.

Re: Some small optimization issues with gcc 4.0 20050418

[Sebastian Biallas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

James E Wilson wrote:
> Sebastian Biallas wrote:
> 
>> You don't need to reserve a stack slot for the return address on x86.
>> The stack slot will be allocated implicitly by the "call" instruction.
> 
> OK, then this must be a similar issue to the register saves in the
> prologue.  There is confusion between calculating the frame size, and
> calculating the amount to subtract from the stack pointer.  These are
> not the same on x86 because some values are being pushed on the stack.

It's already fixed in the mainline, so we can ignore the stack issue.

Sebastian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBQm1UDf81M8QtvOSJAQK1nggAg4E1602S2x3BGnwBJDvn2/HbkanpWMH5
MMfKdqicpG5v2MlsXrqGTMMJbVueBY0d63KM0QdykPBg05kERlTGlj0FHwFuEnVS
X/akXDPKItDrlqnJzAKzV94zHxZlc+MQbMEY4eGpz1bIHl6rzLNrjsKF7+KmYSfG
wNEsDz5N3j2fs3AFcfnUwwlZsswQQwuFyOqmMq0CRbZnpBtuIlnPxs351M4Kdmd8
4Suh/7SvrNFy4ynFFs9S/JqAdqoXhZEx3pl7qZA7yYYfiODyvY9z5lNmhGBtxfJY
vu6w4zph8rdCgVQyNxTgtqPiuKCfXSUWVpDTqcSn7MRhyoUO96epLw==
=OBpd
-END PGP SIGNATURE-

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Andrew,

> How is the get_stmt_ann (stmt) going to work from the caller of
> create_ssa_artificial_load_stmt() when it goes to look at the operands
> for its new "stmt"?   

I am going to replace that particular call to get_stmt_ann with a call
to create_stmt_ann.  The beginning of create_ssa_artficial_load_stmt
would look like

  /* Make sure we don't have a stmt_ann already.  */
  gcc_assert (stmt_ann (stmt) == NULL);

  /* Create a standalone stmt_ann that is not a part of
 tree_statement_list_node.  */
  create_stmt_ann (stmt);

> The annotation was simply attached to the stmt before, so it was
> easy to locate.  There is no bsi_for_stmt() since it isnt a real
> stmt, so you can't get to a stmt_list node that way either.  Im not
> sure how you would locate the annoation for a fake stmt like this.

I am going to keep stmt_ann() so that you can get to stmt_ann from
stmt even for a fake statement.

Eventually, we might want to replace stmt_ann() with
stmt_ann_from_bsi() so that you can get to stmt_ann from bsi directly
without going through a statement proper.  I think this is a good
follow-up project and should be a good preparation for Zdenek's flat
statement tree project.

> And DOM treats it like a real stmt by calling the same routines, so I
> dont know how you could change this without first making DOM do
> something different.

Again, I'll let DOM create its own instance of stmt_ann_d for stores.
Since it's only used for look-ups and never entered into the
instruction stream, I don't think that would cause a problem.

> I have the patch done, I'm evaluating whether its worth using or not.
> 
> I doubt you would be stepping on my toes any more than the annoyance of
> diffs not applying all over the place like they did with
> get_stmt_operands() being removed.

OK.  Meanwhile I'll sit here quietly, collecting information like
which places do weird things with stmt_ann and thinking about how to
go about the transition.

Kazu Hirata

Re: Is there a way to specify profile data file directory?

[H. J. Lu]

On Mon, Apr 25, 2005 at 01:32:03PM -0700, H. J. Lu wrote:
> On Mon, Apr 25, 2005 at 08:47:50AM +0100, Nathan Sidwell wrote:
> > H. J. Lu wrote:
> > 
> > >
> > >Yes, that will work. Is anyone working on this? If not, we can take a
> > >look.
> > 
> > I have not heard anything back from the original enquirer/volunteer over
> > a month ago.  I suggest GCOV_PREFIX as the variable name and simply
> > concatenate it to the absolute paths in the object file.  I'm not sure
> > about whether mkdir calls should be automatically performed, probably
> > yes.
> 
> make_class_file_name in gcc/java/jcf-write.c creates a directory if it
> doesn't exist. Should we create a new file for it in gcc or in
> libiberty?
> 

Never mind. They are slightly different and may not be easy to be
shared.


H.J.

Where did the include files go?

[=?ISO-8859-1?Q?=D8ystein_Johansen?=]

This may be a silly question, but I just can't help my curiosity:
I've done a cvs checkout on msys 1.0.10 and made a good/working build of 
GCC 4.1. gcc version 4.1.0 20050424 (experimental). I did configure with 
--prefix=/gcc4.1. I did a 'make bootstrap' and a 'make install' and 
everything seems fine. All executables and libraries are installed in 
/gcc4.1. I even tested the compiler and it compiles my stuff fine.

But why is the /gcc4.1/include/ directory empty?
I expected to see that directory filled with *.h files and a sys/ directory.
It's not there? Which files are included when I compile my stuff?
cd /gcc4.1
find . -name 'stdio.h' -print
-Øystein

Re: Where did the include files go?

[Mike Stump]

On Apr 25, 2005, at 3:24 PM, Øystein Johansen wrote:
This may be a silly question,
gcc-help is for silly questions...
But why is the /gcc4.1/include/ directory empty?
Why not?
I expected to see that directory filled with *.h files and a sys/  
directory.
Ok, but why?
It's not there?
Right.
Which files are included when I compile my stuff?
gcc -E will tell you this, as will -H, as documented in the manual.
try
ls /usr/include
maybe there are some headers in that directory.

Re: Merging stmt_ann_d into tree_statement_list_node

[Andrew MacLeod]

On Mon, 2005-04-25 at 17:55, Kazu Hirata wrote:
> Hi Andrew,
> 
> > How is the get_stmt_ann (stmt) going to work from the caller of
> > create_ssa_artificial_load_stmt() when it goes to look at the operands
> > for its new "stmt"?   
> 
> I am going to replace that particular call to get_stmt_ann with a call
> to create_stmt_ann.  The beginning of create_ssa_artficial_load_stmt
> would look like
> 
>   /* Make sure we don't have a stmt_ann already.  */
>   gcc_assert (stmt_ann (stmt) == NULL);
> 
>   /* Create a standalone stmt_ann that is not a part of
>  tree_statement_list_node.  */
>   create_stmt_ann (stmt);
> 
> > The annotation was simply attached to the stmt before, so it was
> > easy to locate.  There is no bsi_for_stmt() since it isnt a real
> > stmt, so you can't get to a stmt_list node that way either.  Im not
> > sure how you would locate the annoation for a fake stmt like this.
> 
> I am going to keep stmt_ann() so that you can get to stmt_ann from
> stmt even for a fake statement.

OK, let me word it a different way.  What is create_stmt_ann (stmt)
going to do with the annotation it creates? You are moving the
stmt_ann_t pointer from the stmt node to the tree_statement_list_node...
so there will be nothing in the stmt node to attach the annotation to
like there is now.

  Having the annotation hanging in space isnt going to help when DOM's
equivalency routine takes a stmt and asks for the USE_OPS of that stmt. 
Some of those stmts it is looking at will be real stmts, and some will
be these fake stmts.. it doesn't know which is which, but it needs a
consistant place to find the operand cache.


I though the whole point of this exercise was to remove the stmt_ann_t
pointer from the stmt node, and put it directly in the
tree_statement_list_node.  Im saying that will not work until you either
change DOM to not use these fake stmt's, or figure out some way of
associating a stmt_ann to these fake stmts.


Andrew

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Andrew,

> OK, let me word it a different way.  What is create_stmt_ann (stmt)
> going to do with the annotation it creates? You are moving the
> stmt_ann_t pointer from the stmt node to the tree_statement_list_node...
> so there will be nothing in the stmt node to attach the annotation to
> like there is now.

Ah, OK.  I am going to keep

  union tree_ann_d *ann;

in tree_common.  So create_stmt_ann will store a pointer to stmt_ann_d
in ann in tree_common just like before.  In other words, for normal
cases, we would have

  tree_statement_list_node+stmt_ann_d
  |  ^
  | via stmt | via ann in tree_common
  v  |
MODIFY_EXPR -+

For DOM's case, we would have

   stmt_ann_d
 ^
 | via ann in tree_common
 |
MODIFY_EXPR -+

So stmt_ann_d won't be hanging in space.

> I though the whole point of this exercise was to remove the
> stmt_ann_t pointer from the stmt node, and put it directly in the
> tree_statement_list_node.  Im saying that will not work until you
> either change DOM to not use these fake stmt's, or figure out some
> way of associating a stmt_ann to these fake stmts.

No, I would like to remove stmt_ann_t pointer from the stmt node, but
not yet.  All I want to do in this project is to put
tree_statement_list_node and stmt_ann_d next to each other in memory
while doing necessary adjustments in the compiler.  Nothing more than
that.

Yes, it is nice to get rid of stmt_ann_t pointer from the stmt node,
and I want to eventually get that, but not in this project.  I think
there are so many places that use "stmt" instead of "bsi".  They may
either pass it to subroutines or put it in some internal data
structures, so I would like to do that separately.  So if you like,
the roadmap might be something like

1. Put tree_statement_list_node and stmt_ann_d next to each other in
   memory while doing necessary adjustments.

2. Provide stmt_ann_from_bsi(), a function that gives you stmt_ann
   given bsi.

3. Let everybody use stmt_ann_from_bsi(), replace stmt_ann(), and
   remove the stmt_ann_t pointer from the stmt node (if these are
   possible at all).

4. Hand off to Zdenek for his flat statement project.

I hope this message clarifies things.

Kazu Hirata

Re: Unnesting of nested subreg expressions

[James E Wilson]

Björn Haase wrote:
misses therefore a lot of optimizations. I am presently trying to remove the 
define_insn for the HImode and SImode operations by implementing the lowering 
to QImode at expand or at least after reload (for those operations that leave 
the condition code in a useable state like addsi3 ).
optabs.c can do some of this work for you.  E.g., if there is an andqi 
pattern but not andhi pattern, and word_mode == QImode, then 
expand_binop will automatically synthesize an andhi operation from the 
andqi pattern.  So the easy solution here is to simply not define andhi. 
 If the RTL you get isn't optimal, then you can add your own pattern 
that uses machine dependent instructions.  This shouldn't be necessary 
for and, but may be necessary for add.

Take a look at how this code in expand_binop works.  It uses 
operand_subword/operand_subword_force, which is the standard way to 
extract sub-words from a multiple word value.

  [(set (subreg:QI (match_dup 0) 0)
(and:QI (subreg:QI (match_dup 1) 0)
(subreg:QI (match_dup 2) 0)))
   (set (subreg:QI (match_dup 0) 1)
(and:QI (subreg:QI (match_dup 1) 1)
(subreg:QI (match_dup 2) 1)))]
The explicit subregs in the RTL here isn't a good idea.  It is probably 
better to make these be QImode match_operands, and then generate RTL for 
the operands includes the SUBREGs.

The REG_P check should prevent any subreg from getting through to here, 
so it isn't clear how your nested subreg happened.  Anyways, I think the 
answer here is "operand_subword" instead of gen_lowpart/gen_highpart.  I 
 don't remember if operand_subword works for constants though, it might 
only be right for the register/subreg case.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Merging stmt_ann_d into tree_statement_list_node

[Andrew MacLeod]

On Mon, 2005-04-25 at 19:01, Kazu Hirata wrote:
> Hi Andrew,

> No, I would like to remove stmt_ann_t pointer from the stmt node, but
> not yet.  All I want to do in this project is to put
> tree_statement_list_node and stmt_ann_d next to each other in memory
> while doing necessary adjustments in the compiler.  Nothing more than
> that.
> 

does that buy us much?

> Yes, it is nice to get rid of stmt_ann_t pointer from the stmt node,
> and I want to eventually get that, but not in this project.  I think
> there are so many places that use "stmt" instead of "bsi".  They may
> either pass it to subroutines or put it in some internal data
> structures, so I would like to do that separately.  So if you like,
> the roadmap might be something like
> 
> 1. Put tree_statement_list_node and stmt_ann_d next to each other in
>memory while doing necessary adjustments.
> 
> 2. Provide stmt_ann_from_bsi(), a function that gives you stmt_ann
>given bsi.
> 
> 3. Let everybody use stmt_ann_from_bsi(), replace stmt_ann(), and
>remove the stmt_ann_t pointer from the stmt node (if these are
>possible at all).
> 
> 4. Hand off to Zdenek for his flat statement project.
> 
> I hope this message clarifies things.
> 

Then why not simply shorten this to:

1) put stmt annoation directly in the tree_statement_list_node

2) replace stmt_ann_t pointer in stmt with a pointer to its BSI, or the
tree_statement_list_node.  This makes bsi_from_stmt O(1) immediately.

3) all stmts now have access to the stmt_ann directly in the
stmt_list_node, nothing changes except get_stmt_ann() returns the
address of the stmt ann within the tree_stmt_list_node.

4) For fake stmts you will have to allocate a fake tree_stmt_list_node
which isnt linked with anything, and set the bsi pointer to that... then
you have the annotation and access to it from the stmt.

that seems like a quicker more direct approach then phasing it in
slowly, with less impact to anyone, and gives you immediate benefits. I
would think the patch to do this would be fairly small and
non-intrusive.

Andrew

Re: gcc-4.0.0 build problem on solaris

[James E Wilson]

Don Lindsay wrote:
	fatal: libiconv.so.2: open failed: No such file
You have a copy of GNU iconv in /usr/local.  This is apparently a common 
problem with Solaris.
http://gcc.gnu.org/ml/gcc/2005-04/msg01092.html
http://gcc.gnu.org/ml/gcc/2005-04/msg01030.html
give two possible solutions to the problem, in order of preference.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: http://gcc.gnu.org/gcc-3.4/changes.html

[Giovanni Bajo]

Gerald Pfeifer <[EMAIL PROTECTED]> wrote:

>> Here is a unified diff for the proposed change (I think).
>
> Johan, Giovanni, I just noticed that this one apparently feel trough
> the cracks?
>
> I had assumed that Giovanni would just go ahead an apply it since he's
> an expert in that area and the patch even was rather short, but I do
> not see it in CVS, so I just committed it.

I either forgot about it or waited for an approval. Either way, thank you for
taking care of this!


Giovanni Bajo

Re: emit_no_conflict_block breaks some conditional moves

[James E Wilson]

Greg McGary wrote:
That will do fine for ports that have conditional move, but without
movsicc, you'll have this case:
cmpsi ...
bcc 1f
movsi target, ...
  1:
cmpsi ...
bcc 2f
movsi target, ...
  2:

Thanks for the additional details.  I had to remind myself what 
emit_no_conflict_block does.

Looking at emit_no_conflict_block, I see that it already tests for 
!NONJUMP_INSN_P, and returns without emitting a no conflict block in 
that case, which looks like the right solution to me.  So this case with 
branches is not a problem.

That just leaves the case with multiple compares and conditional moves.
I think there are possible register allocation problems here, as a 
REG_NO_CONFLICT block note is really only supposed to be attached to 
insns that set a word of the output using a word of the input.  If we 
attach them to other instructions, that might confuse the register 
allocator into failing.  Also, REG_NO_CONFLICT is supposed to be 
attached to every instruction inside a no conflict block, and some 
passes look for that, so fixing the code to emit REG_NO_CONFLICT on only 
some of the instructions doesn't seem safe either.

I think this has to be fixed by not emitting the no conflict block, just 
as we already handle the branching case.  So this means adding a check 
where we also check !NONJUMP_INSN_P to handle this case.  You didn't get 
a sample sequence for this case, so it isn't clear what the exact 
criteria should be.  I suggested earlier checking for a hard reg CCmode 
dest.  Alternatively, maybe checking for a conditional move insn would 
make sense, i.e. an insn with if_then_else in the source.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

gcc 4.0.0 optimization vs. id strings (RCS, SCCS, etc.)

[Bruce Lilly]

Hi,

Earlier versions of gcc retain static character strings in object files
which can be used for identification via ident (RCS) or what (SCCS).
Gcc 4.0.0 removes them above optimization level 1.  Global strings
are retained, of course, but that may lead to namespace collisions.
#ident doesn't work on some architectures, and functionality can't
be determined at preprocessor time.  #sccs doesn't work at all.  The
bottom line is that identification which worked with earlier versions
of gcc is broken under 4.0.0.  See attached C source code example.
/* the following works with SCCS (what) and RCS et al (ident) with gcc 3.x and
  earlier 
   string symbol is local (static) to object file and does not clash
  with symbols similarly defined in other files in the same package
  or in library archives used with a package
   gcc 4.0.0 with optimization level 2 or greater elides the symbol and string,
  breaking identification; -fkeep-static-consts is ineffective with
  optimization turned on
*/
static const char rcs_sccs_id[] =
"$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string1\\ $";

/* the following works with gcc 4.0.0, but leaves a globally-visible symbol in
  object files where it can clash with other symbols in a package or in an
  object file in a library archive
*/
const char idtest_c_rcs_sccs_id2[] =
"$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string2\\ $";

/* gross hack as a workaround for gcc 4.0.0 issue; ID string
  symbol is static, but this won't work for a file with no
  externally-visible executable functions (e.g. a version file)
*/
static const char idtest_c_rcs_sccs_id3[] =
"$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string3\\ $";
void some_function(void); /* prototype to shut gcc TF up */
void some_function(void) {
const char *unused = idtest_c_rcs_sccs_id3; /* workaround for gcc 4.0.0 issue */
/* ... */ /* real code goes here */
}

/* the following doesn't work on all architectures, and is non-standard
   there is no way to test whether it will work at preprocessing time (so that
  one of the other methods might be used)
   if -fno-ident is specified, it is ineffective even if supported on an
  architecture
*/
#ident "$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string4 $"

/* the following doesn't work at all with gcc; it's also non-standard
*/
#sccs "$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string5 $"

Re: Stack frame question on x86 code generation

[James E Wilson]

Gang-Ryung Uh wrote:
Could anyone help me understand what is the gcc 
strategy to prepare the stack frame?
You didn't mention the gcc version, or the gcc target.  Different gcc 
versions and targets will give different answers.  Even different x86 
targets work differently.

  printf("0x%x=return address, *ret);
You are missing a quote here.
question1: Why the stack frame size is 56?
A bug.  It is 40 in current gcc development sources, or rather, I should 
say that it is 40 that gets subtracted from the stack pointer.  The 
actual frame size also includes stuff that is being pushed.

This is probably the same issue as discussed in the thead here
http://gcc.gnu.org/ml/gcc/2005-04/msg01191.html
   Then, why they adding 16 bytes padding?
Probably the same bug.  I get "leal-9(%ebp), %eax" which makes sense 
 for a 5 byte array, with 4 bytes of data allocated ahead of it.

question2: Why gcc makes the stack frame bigger before
   the function call printf?
This is probably to maintain 16-byte stack alignment when we reach 
printf.  We maintain 16-byte stack alignment so that MMX/SSE 
instructions will work.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: spill_failure

[James E Wilson]

Rajkishore Barik wrote:
./mul_mdmd_md.c:343: error: unable to find a register to spill in class 
âAD_REGSâ
Compile with -da, look at the .greg dump file, it will have a bunch of 
messages saying "reloads for insn ...".  Find the one for the insn that 
is failing.  Look at the .lreg dump to find the pre-reload version of 
the insn.  These two pieces of info together should give you a clue 
where to look next.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Adnrew,

> > No, I would like to remove stmt_ann_t pointer from the stmt node, but
> > not yet.  All I want to do in this project is to put
> > tree_statement_list_node and stmt_ann_d next to each other in memory
> > while doing necessary adjustments in the compiler.  Nothing more than
> > that.
> 
> does that buy us much?

I have to try, but it seems to be the lowest hanging fruit as far as
the instruction chain infrastructure goes.

> Then why not simply shorten this to:
> 
> 1) put stmt annoation directly in the tree_statement_list_node
> 
> 2) replace stmt_ann_t pointer in stmt with a pointer to its BSI, or the
> tree_statement_list_node.  This makes bsi_from_stmt O(1) immediately.
> 
> 3) all stmts now have access to the stmt_ann directly in the
> stmt_list_node, nothing changes except get_stmt_ann() returns the
> address of the stmt ann within the tree_stmt_list_node.
> 
> 4) For fake stmts you will have to allocate a fake tree_stmt_list_node
> which isnt linked with anything, and set the bsi pointer to that... then
> you have the annotation and access to it from the stmt.
> 
> that seems like a quicker more direct approach then phasing it in
> slowly, with less impact to anyone, and gives you immediate benefits. I
> would think the patch to do this would be fairly small and
> non-intrusive.

This looks like a better approach.  How would we do your step 1?  We
have var_ann and tree_ann in addition to stmt_ann.  Shall we put a
type field at the beginning of tree_statement_list_node+stmt_ann_d so
that an annotation node can identify itself?  (Since all these tree
annotations already have a field for annotation type, it's more like
appending tree_statement_list_node to stmt_ann_d.)

Kazu Hirata

Re: gcc 4.0.0 optimization vs. id strings (RCS, SCCS, etc.)

[Sebastian Biallas]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Bruce Lilly wrote:
> Hi,
> 
> Earlier versions of gcc retain static character strings in object files
> which can be used for identification via ident (RCS) or what (SCCS).
> Gcc 4.0.0 removes them above optimization level 1.  Global strings
> are retained, of course, but that may lead to namespace collisions.
> #ident doesn't work on some architectures, and functionality can't
> be determined at preprocessor time.  #sccs doesn't work at all.  The
> bottom line is that identification which worked with earlier versions
> of gcc is broken under 4.0.0.  See attached C source code example.
> 
> 
> 
> 
> /* the following works with SCCS (what) and RCS et al (ident) with gcc 3.x and
>   earlier 
>string symbol is local (static) to object file and does not clash
>   with symbols similarly defined in other files in the same package
>   or in library archives used with a package
>gcc 4.0.0 with optimization level 2 or greater elides the symbol and 
> string,
>   breaking identification; -fkeep-static-consts is ineffective with
>   optimization turned on
> */
> static const char rcs_sccs_id[] =
> "$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string1\\ $";

Use
static const char rcs_sccs_id[] __attribute__((used)) = ".."

Sebastian
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iQEVAwUBQm2Md/81M8QtvOSJAQKPxgf+N6Q6iKedLaWOwrYRcC2rrDo2/iqDTc36
aIlIJQN5I41T8JRt0R0T5vnxRdTGx6v2VIpYf6Xw/wMigbA22ANUhp/r6DnYaJS0
ieKzyEf4BPlL3xuMfhIU7UzUI3ogzF8lsFhiAgtvm/1bu1IeFIUevlyfj57ZfV7H
2Vl3CuQ8SFLBLj+k6FJV1svcCnzo52msvBggZwvLRd9CizpDaJ41cyeH+StFNaXo
BQRQYnsoZhbhvCFGSCmHOKdaMB10XE1R6QNL86f/YYEDrX/slY4Kxc1pr4heBC/M
FLY1hnj1+MPK0Ch5HyAzLlMNDBG9gUR8MvY9UCIEXonpt6QspjWKXg==
=jy0E
-END PGP SIGNATURE-

Re: benchmark call malloc a lot?

[James E Wilson]

Zhenyu Guo wrote:
Any bechmarks which are dynamic storage alloca intensive? Or
call malloc like func a lot?
gcc makes a nice benchmark, and has lots of allocation calls. 
Otherwise, this doesn't seem to be a gcc question.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Merging stmt_ann_d into tree_statement_list_node

[Zdenek Dvorak]

Hello,

> > Then why not simply shorten this to:
> > 
> > 1) put stmt annoation directly in the tree_statement_list_node
> > 
> > 2) replace stmt_ann_t pointer in stmt with a pointer to its BSI, or the
> > tree_statement_list_node.  This makes bsi_from_stmt O(1) immediately.
> > 
> > 3) all stmts now have access to the stmt_ann directly in the
> > stmt_list_node, nothing changes except get_stmt_ann() returns the
> > address of the stmt ann within the tree_stmt_list_node.
> > 
> > 4) For fake stmts you will have to allocate a fake tree_stmt_list_node
> > which isnt linked with anything, and set the bsi pointer to that... then
> > you have the annotation and access to it from the stmt.
> > 
> > that seems like a quicker more direct approach then phasing it in
> > slowly, with less impact to anyone, and gives you immediate benefits. I
> > would think the patch to do this would be fairly small and
> > non-intrusive.
> 
> This looks like a better approach.  How would we do your step 1?  We
> have var_ann and tree_ann in addition to stmt_ann.  Shall we put a
> type field at the beginning of tree_statement_list_node+stmt_ann_d so
> that an annotation node can identify itself?  (Since all these tree
> annotations already have a field for annotation type, it's more like
> appending tree_statement_list_node to stmt_ann_d.)

I would go just for having

union
{
  struct stmt_list_node *container; /* For gimple statements.  */
  tree_ann_t ann;   /* For everything else.  */
}

(Plus some GTY annotations around that enable the garbage collector to
recognize this case; as far as my memory serves, I needed something
similar once and it was doable).  This way you won't waste space
for the useless tree_statement_list_node "type field".

Zdenek

Re: about how to write makefile.in config-lang.in for a frontend

[James E Wilson]

zouq wrote:
> i am now writing a frontend in gcc, but i don`t understand the rule
> to write the makefile.in, config-lang.in

There is a section in the docs that describe config-lang.in.  Try
looking at it.  Also, try looking at the config-lang.in files for other
language front ends.

As for makefile.in, well, try reading some documentation on the "make"
program.  Try "info make".
-- 
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc 4.0.0 optimization vs. id strings (RCS, SCCS, etc.)

[Andrew Pinski]

On Apr 25, 2005, at 8:15 PM, Bruce Lilly wrote:
Hi,
Earlier versions of gcc retain static character strings in object files
which can be used for identification via ident (RCS) or what (SCCS).
Gcc 4.0.0 removes them above optimization level 1.  Global strings
are retained, of course, but that may lead to namespace collisions.
#ident doesn't work on some architectures, and functionality can't
be determined at preprocessor time.  #sccs doesn't work at all.  The
bottom line is that identification which worked with earlier versions
of gcc is broken under 4.0.0.  See attached C source code example.

The following is correct way of saying that the variable is used in 3.3
and above:
static const char rcs_sccs_id[] __attribute__((used)) =
"$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string1\\ $";
-- Pinski

Re: c54x port

[James E Wilson]

Bryan Richter wrote:
Can someone assist me in getting the necessary copyright assignment
forms? 
See
http://gcc.gnu.org/ml/gcc/2003-06/msg02298.html
for info on how to get the process started.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc 4.0.0 optimization vs. id strings (RCS, SCCS, etc.)

[Zack Weinberg]

Bruce Lilly <[EMAIL PROTECTED]> writes:

> Earlier versions of gcc retain static character strings in object
> files which can be used for identification via ident (RCS) or what
> (SCCS).  Gcc 4.0.0 removes them above optimization level 1.

The first observation I'd like to make is that we (the GCC developers,
collectively) don't really understand the need for this.  We don't put
$Id$ strings in our own source code, never mind the object files.  The
attitude is that the version number of the program as a whole suffices
to figure out which release branch to go looking for the bug in.
Therefore, I hesitate to give you any sort of advice, because as long
as there's no one on the GCC team who understands why this needs to
work, people are going to continue to break it.

I do have three suggestions for you:

1) The current way to tell the compiler not to throw away
   apparently-unused data is __attribute__((used)), like this:

  static const char __attribute__((used)) rcs_sccs_id[] =
  "$Id: @(#)%M% %I% 20%E% %U% copyright 2005 %Q% string1\\ $";

   You can hide this behind a macro so it doesn't interfere with other
   compilers.

2) #ident currently does something useful if and only if the back-end
   defines what to do with it.  However, we could define a sensible
   default, e.g. converting it to a global string declaration like the
   one above.  I'd be happy to take a patch that made that change.

   However, the purpose of -fno-ident is to make #ident do nothing;
   we're not going to change that.  I'm a little confused why you even
   bring it up.

3) #sccs does nothing because no one has ever told me what it was
   supposed to do, or even what its argument syntax was.  From what
   you write, it's functionally identical to #ident; I'd be happy to
   take a patch that made #sccs an alias for #ident.

zw

Re: tips on debugging a GCC 3.4.3 MIPS RTL optim problem?

[James E Wilson]

Gary Funck wrote:
(call_insn 84 66 141 (call_placeholder 77 67 0 0 (call_insn 83 82 0 (parallel [
call_placeholder is a special kind of RTL.  It contains 3 instruction 
sequences for the 3 different possible kinds of calls: a normal call, a 
tail call, and a sibling call.  These aren't printed in the dumps, but 
you can print them inside the debugger.  See the docs for 
call_placeholder (look at rtl.def in particular).

The missing instructions you are looking for are all inside the 
call_placeholder.

This stuff is already gone in gcc-4.0, so we no longer have this problem.
Am I wrong in assuming that the two digits in the names of the RTL
dump files indicate the sequence of the RTL passes?
You are not wrong.
Any tips on debugging this codegen issue would be appreciated.
Try putting breakpoints in make_insn_raw, conditional on the instruction 
numbers for the insns that load the arguments, then go up the call stack 
to see how the values were computed.

Try looking at the decls for the local variables to see what address 
they were allocated to.

Make sure decls are being properly marked as used.  -funit-at-a-time is 
much better at optimizing away that appears to be unused.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Merging stmt_ann_d into tree_statement_list_node

[Andrew MacLeod]

On Mon, 2005-04-25 at 20:32, Kazu Hirata wrote:
> Hi Adnrew,

> This looks like a better approach.  How would we do your step 1?  We
> have var_ann and tree_ann in addition to stmt_ann.  Shall we put a
> type field at the beginning of tree_statement_list_node+stmt_ann_d so
> that an annotation node can identify itself?  (Since all these tree
> annotations already have a field for annotation type, it's more like
> appending tree_statement_list_node to stmt_ann_d.)

thats one option. Simply make the stmt_ann node the first thing in the
tree_statement_list_node, and then it does look exactly like appending
tree_statement_list_node to stmt_ann_d. Then the fields for GTY should
all work out ok, and it is minimum impact.  There doesn't appear to be
any ordering implied in the tree_statement_list_node.   

 Improvements could be made later once that is working when someone
wants to figure out the vagarities of var_ann vs the stmt list node.

Andrew

Re: object code execution statistics

[James E Wilson]

Sergei Tovpeko wrote:
Is there any util that would produce result containing the asm code
execution staticstics ???
I assume you want assembly instruction execution counts.  You could 
produce this info from gcov with a bit of work, as gcov already gives 
you execution counts for basic blocks.  You just need to disassemble the 
code, apply the counts to the assembly instructions, and then print 
whatever statistics you want.  Probably not easy, but feasible.

Otherwise, there is nothing in gcc that will help you here.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Merging stmt_ann_d into tree_statement_list_node

[Kazu Hirata]

Hi Zdenek,

> > This looks like a better approach.  How would we do your step 1?  We
> > have var_ann and tree_ann in addition to stmt_ann.  Shall we put a
> > type field at the beginning of tree_statement_list_node+stmt_ann_d so
> > that an annotation node can identify itself?  (Since all these tree
> > annotations already have a field for annotation type, it's more like
> > appending tree_statement_list_node to stmt_ann_d.)
> 
> I would go just for having
> 
> union
> {
>   struct stmt_list_node *container;   /* For gimple statements.  */
>   tree_ann_t ann; /* For everything else.  */
> }

Err, I don't see how to tell the garbage collector about this without
a type field.  We cannot rely on TREE_CODE (stmt) because CALL_EXPR
may appear by itself or as an rhs of MODIFY_EXPR.

Kazu Hirata

Re: gcc-4.0 non-local variable uses anonymous type warning

[James E Wilson]

William S Fulton wrote:
test.cxx:15: warning: non-local variable ‘:: 
::Instance’ uses anonymous type
Just grepping the sources for the warning, I find this comment
  /* [basic.link]: A name with no linkage (notably, the name of a class
 or enumeration declared in a local scope) shall not be used to
 declare an entity with linkage.
 Only check this for public decls for now.  */
Also this:
  /* DRs 132, 319 and 389 seem to indicate types with
 no linkage can only be used to declare extern "C"
 entities.  Since it's not always an error in the
 ISO C++ 90 Standard, we only issue a warning.  */
  static enum { foo, bar = 10 } Instance;
The "public decls" comment above means that we deliberately don't emit 
the warning for static variables, but it is possible this may change in 
the future.  It may depend on how the defect reports get resolved.

I'm not a C++ expert, and don't have a copy of the C++ standard, so I 
can't comment further.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Ada and bad configury architecture.

[Nathanael Nerode]

Arno commented in a bug report:
> Also, having the TOOLS_TARGET_PAIRS being now set in configure.ac is
> more painful to maintain than having the list in Makefile.in, what about
> reverting this change ? It would make life simpler when adding support
> for a new target (no need to worry about rerunning configure, configure
> version, configure syntax errors, etc...)
This can't be reverted without abandoning all efforts to make
gnattools/gnatlib build like other target tools/libraries.

Actually, I was going to try to convince y'all to allow the *configury*
to be put in the *configure* files.  All of it.  The current scheme of
stuffing the configury in the Makefile, although I know the Ada
maintainers like it, is just trouble, and is fundamentally the source of
most or all of the endless Ada cross-build problems.

We could certainly create a file much like config.gcc in gcc, so that
'autoconf' doesn't need to be rerun, but 'configure' *should* need to be
rerun to change configuration.

Re: Fixing of bug 18877

[James E Wilson]

Martin Koegler wrote:
The fix is quite simple and was included in the bug report about 4 month ago.
I raised also this issue on gcc-patches 
(http://gcc.gnu.org/ml/gcc-patches/2004-12/msg01390.html),
but the problem still remains in the mainline cvs version.
What can I do, to get the fix in the CVS?
You can "ping" a patch that hasn't been reviewed after two weeks.  Plus 
there are also some other procedural details that need to be followed 
here, please see
http://gcc.gnu.org/contribute.html
for more info on submitting patches.

I'll reply to the gcc-patches message.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: Regression involving COMMON(?)

[Andrew Pinski]

On Apr 26, 2005, at 12:56 AM, Paul Thomas wrote:
Something did common in last night:
I see testsuite failures on g77/960628_x.f (for x=0-10), common_4.f90 
and g77/980701-1.f thus bumping unexpected failures up to 79.  The 
common feature, if you will excuse the play on words, is common.
I think this is caused by:
2005-04-25  Nathan Sidwell  <[EMAIL PROTECTED]>
* tree-ssa-alias.c (fieldoff_t): Remove.
(fieldoff_s): typedef the structure itself.  Create a vector of
objects.
(push_fields_onto_fieldstack): Return count of fields pushed.
Remove peeling of first field.  Adjust.
(fieldoff_compare): Adjust.
(create_overlap_variables_for): Adjust.
by the way Paul, what is the error?
-- Pinski

Successful Build Report for GCC 4.0.0 C and C++

[Simon G Best]

Hello!
Here is a report of a successful build of GCC 4.0.0's C and C++
compilers on a RedHat 9 system.
[Report starts here.]
Basic information:-
'config.guess':
i686-pc-linux-gnu
'gcc -v' (actual command was 'gcc-4 -v'):
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.0.0/configure --program-suffix=-4
-enable-languages=c,c++
Thread model: posix
gcc version 4.0.0
Languages:
Full distribution downloaded, but only C and C++ languages selected
during configuration.
Linux information:-
OS Distribution: Red Hat Linux release 9 (Shrike)
Linux kernel version ('uname -a'):
Linux localhost.localdomain 2.4.20-31.9custom-olympus-1 #2 Tue Nov 30
22:46:13 GMT 2004 i686 i686 i386 GNU/Linux
glibc version ('rpm -q glibc'):
glibc-2.3.2-27.9.7
Additional information:-
*  After 'make install', I also had to carry out the following,
additional steps:
1.  add the line '/usr/local/lib' to the end of '/etc/ld.so.conf';
2.  run 'ldconfig' as root.
Without performing those final steps, C++ executables wouldn't run, as
there were shared libraries that couldn't be found.
*  Made with 'make bootstrap-lean'.
*  The '--program-suffix=-4' configure option was used to avoid name
clashes with RedHat 9's GCC.
*  The kernel is built from RedHat's kernel-source-2.4.20-31.9 RPM
package, which came through their Update Agent as an update.  The
configuration is customised to suit my particular system, but is
otherwise a normal RedHat Linux kernel.
[Report ends here.]
Thanks again for providing the world with a Free, good C++ compiler!
Simon G Best

Re: Merging stmt_ann_d into tree_statement_list_node

[Zdenek Dvorak]

Hello,

> > > This looks like a better approach.  How would we do your step 1?  We
> > > have var_ann and tree_ann in addition to stmt_ann.  Shall we put a
> > > type field at the beginning of tree_statement_list_node+stmt_ann_d so
> > > that an annotation node can identify itself?  (Since all these tree
> > > annotations already have a field for annotation type, it's more like
> > > appending tree_statement_list_node to stmt_ann_d.)
> > 
> > I would go just for having
> > 
> > union
> > {
> >   struct stmt_list_node *container; /* For gimple statements.  */
> >   tree_ann_t ann;   /* For everything else.  */
> > }
> 
> Err, I don't see how to tell the garbage collector about this without
> a type field.  We cannot rely on TREE_CODE (stmt) because CALL_EXPR
> may appear by itself or as an rhs of MODIFY_EXPR.

in the later case, they don't have annotations?  But OK, there may be
some other case I am forgetting now, so perhaps making it safe and
having a type field is a better idea.

Zdenek