Re: GCC 4.0 RC1 Available

[Paolo Bonzini]

Kaveh R. Ghazi wrote:
Nathanael removed the surrounding for-stmt but left
the break inside the if-stmt.
http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html
 

I think it is enough to remove it.  bash does not complain if it finds a 
stray break, it seems.

Ok to commit to mainline (and src)?  Mark, if you decide to fix it in 
4.0, I think it is better that you do it yourself also because of the 
time zone difference (I'll be out of home this evening, which is 
morning/afternoon for you).

Paolo
2005-04-12  Paolo Bonzini  <[EMAIL PROTECTED]>
   * configure: Regenerate.
config:
2005-04-12  Paolo Bonzini  <[EMAIL PROTECTED]>
   * acx.m4 (ACX_PROG_GNAT): Remove stray break.
Index: acx.m4
===
RCS file: /cvs/gcc/gcc/config/acx.m4,v
retrieving revision 1.11
diff -p -u -r1.11 acx.m4
--- acx.m4  28 Feb 2005 13:25:55 -  1.11
+++ acx.m4  12 Apr 2005 07:04:16 -
@@ -212,7 +212,6 @@ acx_cv_cc_gcc_supports_ada=no
errors=`(${CC} -c conftest.adb) 2>&1 || echo failure`
if test x"$errors" = x && test -f conftest.$ac_objext; then
  acx_cv_cc_gcc_supports_ada=yes
-  break
fi
rm -f conftest.*])

Re: Getting rid of -fno-unit-at-a-time

[Thorsten Glaser]

Daniel Jacobowitz dixit:

>On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
>> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
>> or so... I still lean on that crutch.
>
>A user!  Can you explain why?

If you're "just" looking for users:

I need -fno-unit-at-a-time because -funit-at-a-time in 3.4 breaks
ProPolice. Of course, that's totally non-standard, and ProPolice
will have to be redesigned for gcc 4 anyway, IIRC.
(Also, with -funit-at-a-time, I get .L123 symbols in the generated
shared libraries, which I do not get without.)

Probably not too much importance, I just wanted to speak up
I guess.

bye,
//mirabile

Re: Getting rid of -fno-unit-at-a-time

[Andrew Pinski]

On Apr 12, 2005, at 3:14 AM, Thorsten Glaser wrote:
Daniel Jacobowitz dixit:
On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
BTW, I hope -fno-unit-at-a-time doesn't go away until at least 
gcc-4.1.1
or so... I still lean on that crutch.
A user!  Can you explain why?
If you're "just" looking for users:
I need -fno-unit-at-a-time because -funit-at-a-time in 3.4 breaks
ProPolice. Of course, that's totally non-standard, and ProPolice
will have to be redesigned for gcc 4 anyway, IIRC.
(Also, with -funit-at-a-time, I get .L123 symbols in the generated
shared libraries, which I do not get without.)
If it breaks ProPolice, then ProPolice is broken in the first place.
Since at the RTL level there should be no different between
no unit at a time and unit at a time.
Thanks,
Andrew Pinski

Re: Mainline build failure on i686-pc-linux-gnu

[Andrew Pinski]

On Apr 12, 2005, at 12:53 AM, Gabriel Dos Reis wrote:
Diego Novillo <[EMAIL PROTECTED]> writes:
| On Mon, Apr 11, 2005 at 10:59:46PM -0500, Gabriel Dos Reis wrote:
|
| >-c /home/gdr/redhat/egcs/gcc/crtstuff.c -DCRT_BEGIN \
| >   -o crtbegin.o
| > make[1]: *** [crtbegin.o] Aborted
| > make[1]: Leaving directory `/home/gdr/build/4.1/gcc'
| > make: *** [all-gcc] Error 2
| >
| What's your top-of-ChangeLog?  Works for me up to
|
| 2005-04-11  Diego Novillo  <[EMAIL PROTECTED]>
|
| PR tree-optimization/20933
| * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
|   [ ... ]
And what version of the compiler were you starting with?
If it was 4.1.0 between the following patches:
2005-04-08  Diego Novillo  <[EMAIL PROTECTED]>
Merge from tree-cleanup-branch: VRP, store CCP, store
copy-prop, incremental SSA updating of FUD chains and
newly exposed symbols.
and
 2005-04-11  Diego Novillo  <[EMAIL PROTECTED]>
 PR tree-optimization/20933
 * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
Then try with another compiler as 4.1.0 was broken during those two
dates really.
This was PR 20933 by the way.
Thanks,
Andrew Pinski

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

[Bernd Schmidt]

Zack Weinberg wrote:
The target macros described in the "Addressing Modes" section of the
internals manual are rather badly in need of cleaning up.
What's your status on this - would you mind very much if I made changes 
to those macros now?

Bernd

Re: Mainline build failure on i686-pc-linux-gnu

[Gabriel Dos Reis]

Andrew Pinski <[EMAIL PROTECTED]> writes:

| And what version of the compiler were you starting with?
| If it was 4.1.0 between the following patches:
| 2005-04-08  Diego Novillo  <[EMAIL PROTECTED]>
| 
|  Merge from tree-cleanup-branch: VRP, store CCP, store
|  copy-prop, incremental SSA updating of FUD chains and
|  newly exposed symbols.
| 
| and
|   2005-04-11  Diego Novillo  <[EMAIL PROTECTED]>
| 
|   PR tree-optimization/20933
|   * tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
| 
| Then try with another compiler as 4.1.0 was broken during those two
| dates really.

You're right on all counts.  Thanks!

-- Gaby

Re: GCC 4.0 RC1 Available

[Giovanni Bajo]

Andrew Haley <[EMAIL PROTECTED]> wrote:

> There was.  We are now, for the first time ever, in a position where
> we can run a large number of big Java applications using entirely free
> software.


This is a really great news!

So great that I wonder why changes.html does not mention it (and news.html
as well). Would you please prepare a patch about this?
-- 
Giovanni Bajo

Re: Bootstrap failure on i686-pc-linux-gnu since 2005-04-09 20:41UTC

[John David Anglin]

> The patch has just been submitted to gcc-patches for
> approval (the tests are nearly done and appear to
> be passing so far).

I'm travelling today, so I won't be able to test until tomorrow.

Thanks,
Dave
-- 
J. David Anglin  [EMAIL PROTECTED]
National Research Council of Canada  (613) 990-0752 (FAX: 952-6602)

OT: How is memory latency important on AMD64 box while compiling large C/C++ sources

[Karel Gardas]

Hello,

first of all, I'm sorry for off-topic, the question from subject might
look silly to you, since natural answer might be "it is very important",
but in the light of deciding what and how much memory will I need in AMD64
box, I've got into deciding troubles caused by the fact that I can not
test the hardware before purchase myself on my prefered benchmark (C++
(MICO) code compilation)

As some of the gcc developers seem to have AMD64 boxes, I would like to
ask for help or for sharing some experience here. I'm mainly interested in
the differences between T1 and T2 timmings and between memory modules
providing 2-2-2-5 and 2-3-3-6 latency. If the difference between let say
compiling libstdc++ with the best (2-2-2-5/T1 timming) and worst
(2-3-3-6/T2 timming) is lower than few percent, then this is no issue, but
if the difference is let say more than 10%, then I would like to "tune"
the hardware by using faster modules. Everything depends on how GCC is
using cache and how much cache it needs (I'm cosidering 512KB cache CPU
here either Winchester or Venice core) and that's the reason why I ask
here, since I've not been able so far to search by google for sufficient
answer for this question.

Thanks for any idea and sorry for off-topic!

Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

Re: GCC 4.0 RC1 Available

[Laurent GUERBY]

c,ada show no unexpected failure on x86 and x86_64 (SuSE 9.2), great!

A minor thing:

I configured with c,ada only (no C++) on x86 and x86_64-linux and got
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00791.html
http://gcc.gnu.org/ml/gcc-testresults/2005-04/msg00790.html
[...]
=== libmudflap tests ===


Running target unix
FAIL: libmudflap.c++/fail24-frag.cxx (test for excess errors)
WARNING: libmudflap.c++/fail24-frag.cxx compilation failed to produce executable
FAIL: libmudflap.c++/pass27-frag.cxx (test for excess errors)
WARNING: libmudflap.c++/pass27-frag.cxx compilation failed to produce executable
[...]

On surface, it looks like libmudflap is running C++ tests even
when C++ isn't there. Should I open a PR?

Laurent

Re: GCC 4.0 RC1 Available

[Laurent GUERBY]

FYI, on SuSE 9.2, on x86 and x86_64 starting with the system Ada compiler 
(3.3.3 based)
I get no such issue in configure:

checking whether we are using GNU C... yes
checking whether gcc accepts -g... yes
checking for gnatbind... gnatbind
checking whether compiler driver understands Ada... yes
checking how to compare bootstrapped objects... cmp --ignore-initial=16 $$f1 
$$f2
checking for correct version of gmp.h... no
The following languages will be built: c,ada
*** This configuration is not supported in the following subdirectories:
 target-libstdc++-v3 target-libgfortran target-libffi target-boehm-gc 
target-zlib target-libjava zlib fastjar target-libobjc
(Any other directories should still work fine.)

Ada then builds and install fine.

Laurent

On Mon, 2005-04-11 at 14:48 -0400, Kaveh R. Ghazi wrote:
>  > --- here --->
>  > checking whether compiler driver understands
>  > Ada... ../src/gcc-4.0.0-20050410/configure: line 2141: break: only
>  > meaningful in a `for', `while', or `until' loop
>  > yes
>  > checking how to compare bootstrapped objects... cmp
>  > --ignore-initial=16 $$f1 $$f2
>  > ...
>  > looks like there is a "break" without the (usual?) "for" around it.
>  > Georg
> 
> On closer inspection, I'm seeing the same thing on 4.0 and mainline.
> 
> I believe the offending "break" was added to config/acx.m4 here:
> http://gcc.gnu.org/ml/gcc/2004-02/msg00755.html
> Although it seems to be that Paolo simply moved existing code from
> gcc/aclocal.m4 to config/acx.m4.
> 
> Going back through aclocal.m4, the original breakage (no pun intended)
> occurred here when Nathanael removed the surrounding for-stmt but left
> the break inside the if-stmt.
> http://gcc.gnu.org/ml/gcc-patches/2003-11/msg02109.html
> 
> Nathanael, can you please take a look?

Re: Patches for coldfire v4e

[arcjai]

Hi,
 Sorry, I missed ChangeLog patches.

Regards,
C Jaiprakash
--- [EMAIL PROTECTED] wrote:
> Hi,
>   Attached are the patches for coldfire v4e. These
> changes are originally contributed by Peter Barada.
> I
> have migrated and tested these changes from gcc 3.04
> to gcc 3.4 and now to mainline. 
>   Since coldfire v4e has MMU we need to support
> m68k-linux target for coldfire v4e. To support
> m68k-linux for coldfire v4e I need to modify
> t-linux.
> But I suppose this is not desirable. In that case we
> might have to create another target, maybe
> coldfire-linux. Please give your
> comments/suggestions
> on this. Is it ok to modify t-linux or
> coldfire-linux
> should be created. 
> 
> Thanks and Best Regards,
> C Jaiprakash
> 
> 
>   
> __ 
> Do you Yahoo!? 
> Yahoo! Small Business - Try our new resources site!
> http://smallbusiness.yahoo.com/resources/



__ 
Yahoo! Mail Mobile 
Take Yahoo! Mail with you! Check email on your mobile phone. 
http://mobile.yahoo.com/learn/mail 

ChangeLog.patch
Description: ChangeLog.patch

Re: GCC 4.0 RC1 Available

[Joel Sherrill <[EMAIL PROTECTED]>]

Mark Mitchell wrote:
Marcus Meissner wrote:
Btw,
We still see some critical 4.0 problems, ordered by my view of 
importance:

PR/20126 triggers a miscompilation of python (i386 and x86_64 at least).
PR/20917 triggers a miscompilation of glibc (on s390).
PR/20739 triggers a --enable-checking problem triggering in ncurses 
(all platforms)
PR/20929 triggers a miscompilation of Mozilla.
Any chance of getting this m68k specific one added to the RC2
list?
18421 ICE in reload_cse_simplify_operands, at postreload.c:391
Those are all on the Wiki page as possible patches for an RC2.
Thanks,

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: GCC 4.0 RC1 Available

[Georg Bauhaus]

Laurent GUERBY wrote:
FYI, on SuSE 9.2, on x86 and x86_64 starting with the system Ada compiler 
(3.3.3 based)
I get no such issue in configure:
/bin/bash triggers the message, /bin/sh doesn't.
Debian/bash 2.05b; SuSE 9.2/bash 3.00.0(1),
if true; then break; fi
I had run
% bash ../src/gcc-4.0.0-20050410/configure ...
checking whether compiler driver understands Ada... yes

> --- here --->
> checking whether compiler driver understands
> Ada... ../src/gcc-4.0.0-20050410/configure: line 2141: break: only
> meaningful in a `for', `while', or `until' loop
> yes

Re: Patches for coldfire v4e

[Joel Sherrill <[EMAIL PROTECTED]>]

[EMAIL PROTECTED] wrote:
Hi,
  Attached are the patches for coldfire v4e. These
changes are originally contributed by Peter Barada. I
have migrated and tested these changes from gcc 3.04
to gcc 3.4 and now to mainline. 
  Since coldfire v4e has MMU we need to support
m68k-linux target for coldfire v4e. To support
m68k-linux for coldfire v4e I need to modify t-linux.
But I suppose this is not desirable. In that case we
might have to create another target, maybe
coldfire-linux. Please give your comments/suggestions
on this. Is it ok to modify t-linux or coldfire-linux
should be created. 
How many multilib's does adding the v4e support add?
I hate to see another entire toolset binary just to get 1
or 2 multilib variants.
GNU/Linux is not the only OS interested in the v4e.
There should be a generic elf target (m68k-elf) and
I know the RTEMS community would like this (m68k-rtems).
It might make sense to add the multilib to the t-* files
of interest and add coldfire-XXX targets for smaller
dedicated toolsets.  It shouldn't be much besides a
new t-XXX file and a config.gcc entry if you can get
binutils and gdb to match.
Thanks and Best Regards,
C Jaiprakash
		
__ 
Do you Yahoo!? 
Yahoo! Small Business - Try our new resources site!
http://smallbusiness.yahoo.com/resources/

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

Re: GCC 3.4.3

[Hugh Sasse Staff Elec Eng]

On Fri, 8 Apr 2005, Ray Holme wrote:
Many thanks to all for the lessons on how NOT to make things you don't
want.
After 56 hours teh full make bootstrap finished - make install failed
miserable as
install.sh was not where it belonged - so I copied the SRCDIR install.sh
in and that made the top level installs work, but the sub-sub directories
were still looking for ../install-sh - so I copied it down another level
Thanks again.
Ray Holme

So I am right in thinking one must copy gcc-3.4.3/install.sh into 
all of these, or is there a subset that will do?

gcc-3.4.3/boehm-gc
gcc-3.4.3/boehm-gc/Mac_files
gcc-3.4.3/boehm-gc/cord
gcc-3.4.3/boehm-gc/doc
gcc-3.4.3/boehm-gc/include
gcc-3.4.3/boehm-gc/include/private
gcc-3.4.3/boehm-gc/tests
gcc-3.4.3/config
gcc-3.4.3/contrib
gcc-3.4.3/contrib/reghunt
gcc-3.4.3/contrib/regression
gcc-3.4.3/fastjar
gcc-3.4.3/gcc
gcc-3.4.3/gcc/ada
gcc-3.4.3/gcc/cp
gcc-3.4.3/gcc/doc
gcc-3.4.3/gcc/f
gcc-3.4.3/gcc/config
gcc-3.4.3/gcc/fixinc
gcc-3.4.3/gcc/ginclude
gcc-3.4.3/gcc/java
gcc-3.4.3/gcc/objc
gcc-3.4.3/gcc/po
gcc-3.4.3/gcc/testsuite
gcc-3.4.3/gcc/treelang
gcc-3.4.3/include
gcc-3.4.3/intl
gcc-3.4.3/libf2c
gcc-3.4.3/libf2c/libF77
gcc-3.4.3/libf2c/libI77
gcc-3.4.3/libf2c/libU77
gcc-3.4.3/libffi
gcc-3.4.3/libffi/include
gcc-3.4.3/libffi/src
gcc-3.4.3/libffi/testsuite
gcc-3.4.3/libiberty
gcc-3.4.3/libiberty/config
gcc-3.4.3/libiberty/testsuite
gcc-3.4.3/libjava
gcc-3.4.3/libjava/doc
gcc-3.4.3/libjava/gcj
gcc-3.4.3/libjava/gnu
gcc-3.4.3/libjava/include
gcc-3.4.3/libjava/java
gcc-3.4.3/libjava/javax
gcc-3.4.3/libjava/jni
gcc-3.4.3/libjava/libltdl
gcc-3.4.3/libjava/org
gcc-3.4.3/libjava/scripts
gcc-3.4.3/libjava/sysdep
gcc-3.4.3/libjava/testsuite
gcc-3.4.3/libobjc
gcc-3.4.3/libobjc/objc
gcc-3.4.3/libstdc++-v3
gcc-3.4.3/libstdc++-v3/config
gcc-3.4.3/libstdc++-v3/docs
gcc-3.4.3/libstdc++-v3/include
gcc-3.4.3/libstdc++-v3/libmath
gcc-3.4.3/libstdc++-v3/po
gcc-3.4.3/libstdc++-v3/libsupc++
gcc-3.4.3/libstdc++-v3/scripts
gcc-3.4.3/libstdc++-v3/src
gcc-3.4.3/libstdc++-v3/testsuite
gcc-3.4.3/maintainer-scripts
gcc-3.4.3/zlib
gcc-3.4.3/zlib/amiga
gcc-3.4.3/zlib/nt
gcc-3.4.3/zlib/contrib
gcc-3.4.3/zlib/msdos
gcc-3.4.3/zlib/os2
Thank you,
Hugh

Re: 3.4.3 on Solaris9, boehm-gc probs.

[Hugh Sasse Staff Elec Eng]

On Thu, 7 Apr 2005, Hugh Sasse Staff Elec Eng wrote:
On Thu, 7 Apr 2005, Eric Botcazou wrote:
But to get the definitions we are after it should be looking in sys,
No,  is not directly included, only .
Oh, I see.   And I think I now understand what the
--with-local-prefix does, so I'll let you know the results in a few
hours.  I've put --with-local-prefix=/tmp/gcc-local which doesn't
exist.
This seems to have worked. I got a few Error 2 (ignored) but the
tests took place.  My script was:
#!/bin/bash -x
PATH=/bin:/usr/sbin:/usr/ccs/bin:/etc:/usr/local/bin:/opt/sfw/bin:/usr/openwin/bin
export PATH
CONFIG_SHELL=/bin/bash
export CONFIG_SHELL
BUILDINGVER=3.4.3
BUILD_DIR=/export/home/Scratch/hgs/gcc-build
GCC_SOURCE_DIR=/export/home/Scratch/hgs/gcc-${BUILDINGVER}
# CC="/progs/SUNWspro/bin/cc -xildoff -xarch=v9" options only needed
# for 64 bit...
# CC="/progs/SUNWspro/bin/cc"
CC=gcc
export CC
CXX=g++
export CXX
MAKE=/usr/local/bin/gmake
export MAKE
ASOPT="--with-as=/usr/local/bin/as"
LDOPT="--with-ld=/usr/local/bin/ld"
LANGOPT="--enable-languages=c,c++,f77,java,objc"
cd $BUILD_DIR
/bin/rm -rf ./*
${GCC_SOURCE_DIR}/configure $ASOPT $LDOPT $LANGOPTS --disable-nls \
--with-local-prefix=/tmp/gcc-local  && \
# gmake  bootstrap-lean && \\
gmake --jobs=5 bootstrap-lean && \
gmake check
for those who want to use this.
I now need to do the patching to make the install work properly, 
I'll followup to another message about that I think.

Thank you
Hugh

internal compiler error at dwarf2out.c:8362

[Martin Koegler]

I'm working on a GCC port and hit the error

x.c:2: internal compiler error: in modified_type_die, at dwarf2out.c:8362

while compiling 

typedef unsigned char GROUP9_T[3];
typedef GROUP9_T EGROUP9_T __attribute ((eeprom));

with dwarf-2 debugging information. The eeprom attribute is defined so:

static tree
m68hc05_handle_eeprom_attribute (tree * node, tree name,
 tree args ATTRIBUTE_UNUSED,
 int flags ATTRIBUTE_UNUSED,
 bool * no_add_attrs)
{
  if (DECL_P (*node))
{
  if (TREE_CODE (*node) == TYPE_DECL)
{
  /* This is really a decl attribute, not a type attribute,
 but try to handle it for GCC 3.0 backwards compatibility.  */

  tree type = TREE_TYPE (*node);
  tree attr = tree_cons (name, args, TYPE_ATTRIBUTES (type));
  tree newtype = build_type_attribute_variant (type, attr);

  TYPE_MAIN_VARIANT (newtype) = TYPE_MAIN_VARIANT (type);
  TREE_TYPE (*node) = newtype;
}
}
  return NULL_TREE;
}

const struct attribute_spec m68hc05_attribute_table[] = {
  /* { name, min_len, max_len, decl_req, type_req, fn_type_req, handler } */
  {"eeprom", 0, 0, false, true, false, m68hc05_handle_eeprom_attribute},
  {NULL, 0, 0, false, false, false, NULL}
};

Without dwarf-2 debugging, the file compiles.

Internal, the type looks so, when the function is called, which aborts:

Breakpoint 1, modified_type_die (type=0xb7f51288, is_const_type=0, 
is_volatile_type=0, context_die=0xb7f6bac4)
at ../.././gcc/dwarf2out.c:8258
8258  enum tree_code code = TREE_CODE (type);
(gdb) call debug_tree(type)
 
unit size 
align 8 symtab -1208530080 alias set -1 precision 8 min  max 
pointer_to_this >
BLK
size  
constant invariant 24>
unit size  constant invariant 3>
align 8 symtab 0 alias set -1
attributes >
domain 
unit size 
align 8 symtab -1208530132 alias set -1 precision 16 min 
 max >
HI size  unit size 
align 8 symtab 0 alias set -1 precision 16 min  max >>

The GCC core is gcc version 4.1.0 20050412 (experimental).

The bug only happens, if the base type of the second typedef is an array.

As I have not found the use of a port specific type attribute in GCC, I don't 
know,
how I can reproduce it on a official GCC port.

As I have not changed the tree based core and debugging output, the bug should 
be also present 
in the current CVS version.

Any ideas, how to handle this bug?

mfg Martin Kögler
[EMAIL PROTECTED]

Re: Mainline build failure on i686-pc-linux-gnu

[Diego Novillo]

On Tue, Apr 12, 2005 at 07:30:56AM +0200, Gabriel Dos Reis wrote:

> This might be due to the bootstrapping compiler -- I was using a
> compiler built from yesterday tree to bootstrap
> 
Oh, PR 20933.  Yes, the fix you see there should allow you to use
4.1 as a stage0 compiler again.  We were miscompiling libiberty.


Diego.

Re: GCC 3.4.3

[Ray Holme]

the install-sh is always referenced in the parent directory. 
(../install-sh)

so for all the first level directories in the install directory - one copy
at the top will do.

now for sub-sub directories - you must copy (or link) one into the parent
sub-directory.

I don't think there are any three level install directories (but don't
quote me).

Ray

Mainline has been broken for more than 3 days now

[Diego Novillo]

I have been using this crutch for the last couple of days to be
able to get mainline to bootstrap with java enabled.

Index: varasm.c
===
RCS file: /cvs/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.495
diff -u -3 -p -r1.495 varasm.c
--- varasm.c9 Apr 2005 20:41:49 -   1.495
+++ varasm.c10 Apr 2005 22:39:41 -
@@ -308,6 +308,7 @@ in_unlikely_text_section (void)
 
   ret_val = ((in_section == in_unlikely_executed_text)
 || (in_section == in_named
+&& cfun
 && cfun->unlikely_text_section_name
 && strcmp (in_named_name, 
cfun->unlikely_text_section_name) == 0));


I know we are in stage1 and all, but shouldn't the timer have
started already for whatever patch broke mainline on 2005-04-10?

>From the breakage, it seems that this change is at fault:

+2005-04-09  Caroline Tice  <[EMAIL PROTECTED]>
+
+   * bb-reorder.c (find_rarely_executed_basic_blocks_and_crossing_edges):
+   Remove targetm.have_named_sections test.
+   (fix_edges_for_rarely_executed_code): Likewise.
+   (insert_section_boundary_note): Likewise.
+   (reorder_basic_blocks): Check partitioning flag before calling
+   verify_hot_cold_block_grouping.
+   * dbxout.c (dbxout_function_end): Get hot/cold section labels from
+   the function struct rather than global variables.
+   * dwarf2out.c (COLD_TEXT_SECTION_LABEL): New macro.
+   (COLD_END_LABEL): Likewise
[ ... ]

But I'm not 100% sure that this is the case.


Diego.

RE: GCC 3.4.3

[Dave Korn]

Original Message
>From: Ray Holme
>Sent: 12 April 2005 13:42

> the install-sh is always referenced in the parent directory.
> (../install-sh)
> 
> so for all the first level directories in the install directory - one copy
> at the top will do.
> 
> now for sub-sub directories - you must copy (or link) one into the parent
> sub-directory.
> 
> I don't think there are any three level install directories (but don't
> quote me).



  Wouldn't it be an awful lot easier to just 

  A) apply the previously-mentioned fix to toplevel?

  B) use a full path to configure, since this only crops up when using a
relative path to the configure script?


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

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Eric Botcazou writes:
 > > which I see you've already committed a patch for, and a large number
 > > of Java failures.
 > >
 > > 
 > >
 > > for 4.0.0-20050410.
 > 
 > Same failure as on Solaris.
 > 
 > Andrew, do you have a Darwin machine at hand?

Surprisingly enough, yes.  But I'm having trouble finding a compiler
binary for it.

Andrew.

Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources

[Karel Gardas]

On Tue, 12 Apr 2005, Karel Gardas wrote:

> using cache and how much cache it needs (I'm cosidering 512KB cache CPU
> here either Winchester or Venice core) and that's the reason why I ask
> here, since I've not been able so far to search by google for sufficient
> answer for this question.

Also the reason why I'm asking here about this, is this Mike Stump's post:

http://gcc.gnu.org/ml/gcc/2005-04/msg00030.html

Especially: ``Currently gcc takes a cache miss every 20 instructions, or
some ungodly number, and that really saps performance.''

but I don't know if this is just an 1st April fool joke or the reality and
if I understand "cache miss" right and if this is L1 or L2 cache miss.

Thanks,
Karel
--
Karel Gardas  [EMAIL PROTECTED]
ObjectSecurity Ltd.   http://www.objectsecurity.com

Re: GCC 4.0 RC1 Available

[Geoff Keating]

On 12/04/2005, at 6:31 AM, Andrew Haley wrote:
Eric Botcazou writes:
which I see you've already committed a patch for, and a large number
of Java failures.

for 4.0.0-20050410.
Same failure as on Solaris.
Andrew, do you have a Darwin machine at hand?
Surprisingly enough, yes.  But I'm having trouble finding a compiler
binary for it.
Assuming it's a powerpc Darwin machine, you can get compiler binaries 
from .


smime.p7s
Description: S/MIME cryptographic signature

Re: GCC 4.0 RC1 Available

[Andrew Haley]

Geoff Keating writes:
 > 
 > On 12/04/2005, at 6:31 AM, Andrew Haley wrote:
 > 
 > > Eric Botcazou writes:
 > >>> which I see you've already committed a patch for, and a large number
 > >>> of Java failures.
 > >>>
 > >>> 
 > >>>
 > >>> for 4.0.0-20050410.
 > >>
 > >> Same failure as on Solaris.
 > >>
 > >> Andrew, do you have a Darwin machine at hand?
 > >
 > > Surprisingly enough, yes.  But I'm having trouble finding a compiler
 > > binary for it.
 > 
 > Assuming it's a powerpc Darwin machine, you can get compiler binaries 
 > from .

I'm there, but all I can see is Xcode and CHUD.  No compilers or other tools.

Andrew.

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[Kate Minola]

David,

> This probably says more about GCC 3.4.2 on AIX than about
> GCC 4.0 RC1.  See the messages to the gcc-testresults
> mailinglist about successful AIX 5.2 bootstrap of GCC 4.

Thanks.  I should have looked at gcc-testresults.

But even using xlc 

% xlc -qversion
@(#) IBM XL C/C++ Enterprise Edition V7.0 
% 

I still get the same error

: build/genattrtab 
/home/kate/gcc-4.0.0-20050410/src/gcc-4.0.0-20050410/gcc/config/rs6000/rs6000.md
 > tmp-attrtab.c
: 
: out of memory allocating 80016 bytes after a total of 4161645756 bytes
: make[2]: *** [s-attrtab] Error 1

I have tested on two different powerpc-ibm-aix5.2.0.0
machines on different networks (although administered by
the same system administrator).  The sys admin is usually
pretty good about keeping system patches up to date.

Any thoughts on what is different between our two machines?
Any suggestions for things to compare?

Kate Minola
University of Maryland, College Park

Re: GCC 4.0 RC1 Available

[Geoff Keating]

On 12/04/2005, at 6:47 AM, Andrew Haley wrote:
Geoff Keating writes:
On 12/04/2005, at 6:31 AM, Andrew Haley wrote:
Eric Botcazou writes:
which I see you've already committed a patch for, and a large 
number
of Java failures.


for 4.0.0-20050410.
Same failure as on Solaris.
Andrew, do you have a Darwin machine at hand?
Surprisingly enough, yes.  But I'm having trouble finding a compiler
binary for it.
Assuming it's a powerpc Darwin machine, you can get compiler binaries
from .
I'm there, but all I can see is Xcode and CHUD.  No compilers or other 
tools.
Xcode is Apple's name for IDE+compiler+debugger+binutils+etc.

smime.p7s
Description: S/MIME cryptographic signature

Re: GCC 4.0 RC1 Available

[Geoff Keating]

On 11/04/2005, at 11:23 PM, Ranjit Mathew wrote:
Geoffrey Keating wrote:
[...]
which I see you've already committed a patch for, and a large number
of Java failures.
You can see full test results at
[...]

for 4.0.0-20050410.
It might be helpful to put your "libjava.log" somewhere
or if all the Java failures seem similar, to post
the error messages around the "FAIL" lines from your
libjava.log.
Many seem to be NoClassDefFoundError exceptions.  Some examples of  
those plus all the unusual cases are:

Setting LD_LIBRARY_PATH to  
.:/Volumes/Unused/geoffk/gcc-4.0.0-20050410/powerpc-apple-darwin8.0.0/ 
./libjava/.libs:/Volumes/Unused/geoffk/gcc-4.0.0-20050410/gcc:.:/ 
Volumes/Unused/geoffk/gcc-4.0.0-20050410/powerpc-apple-darwin8.0.0/./ 
libjava/.libs:/Volumes/Unused/geoffk/gcc-4.0.0-20050410/gcc:.:/Volumes/ 
Unused/geoffk/gcc-4.0.0-20050410/powerpc-apple-darwin8.0.0/./libjava/ 
.libs:/Volumes/Unused/geoffk/gcc-4.0.0-20050410/gcc
Exception in thread "main" java.lang.RuntimeException: test failed:5
   <>
FAIL: Array_3 -O3 execution - bytecode->native test
UNTESTED: Array_3 -O3 output - bytecode->native test
...
Testing class `Class_1'...
Exception in thread "main" java.lang.NoClassDefFoundError: C
   <>
FAIL: Class_1 execution - gij test
...
Exception in thread "Thread-1" Exception in thread "Thread-2" Exception  
in thread "Thread-3" Exception in thread "Thread-4"  
java.lang.NoClassDefFoundError: SyncTest
   <>
java.lang.NoClassDefFoundError: SyncTest
   <>
java.lang.NoClassDefFoundError: SyncTest
   <>
java.lang.NoClassDefFoundError: SyncTest
   <>
fail: 0
FAIL: SyncTest execution - gij test
UNTESTED: SyncTest output - gij test
...
PASS: stringconst2 execution - gij test
FAIL: stringconst2 output - gij test

I can mail the full log to anyone interested, but I don't think the  
list needs it.


smime.p7s
Description: S/MIME cryptographic signature

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[David Edelsohn]

> Kate Minola writes:

Kate> Any thoughts on what is different between our two machines?
Kate> Any suggestions for things to compare?

Do you have all of the updates listed in the Target-specific
installation notes for AIX installed?

David

RE: GCC 3.4.3

[Hugh Sasse Staff Elec Eng]

On Tue, 12 Apr 2005, Dave Korn wrote:
Original Message
From: Ray Holme
Sent: 12 April 2005 13:42

the install-sh is always referenced in the parent directory.
(../install-sh)
so for all the first level directories in the install directory - one copy
at the top will do.
now for sub-sub directories - you must copy (or link) one into the parent
sub-directory.
I don't think there are any three level install directories (but don't
quote me).

 Wouldn't it be an awful lot easier to just
 A) apply the previously-mentioned fix to toplevel?
If I knew where it was mentioned, probably.
 B) use a full path to configure, since this only crops up when using a
relative path to the configure script?
This seems to be what happened in practice, but my :
cp gcc-3.4.3/install-sh gcc-3.4.3/boehm-gc
cp gcc-3.4.3/install-sh gcc-3.4.3/config
cp gcc-3.4.3/install-sh gcc-3.4.3/contrib
cp gcc-3.4.3/install-sh gcc-3.4.3/fastjar
cp gcc-3.4.3/install-sh gcc-3.4.3/gcc
cp gcc-3.4.3/install-sh gcc-3.4.3/include
cp gcc-3.4.3/install-sh gcc-3.4.3/intl
cp gcc-3.4.3/install-sh gcc-3.4.3/libf2c
cp gcc-3.4.3/install-sh gcc-3.4.3/libffi
cp gcc-3.4.3/install-sh gcc-3.4.3/libiberty
cp gcc-3.4.3/install-sh gcc-3.4.3/libjava
cp gcc-3.4.3/install-sh gcc-3.4.3/libobjc
cp gcc-3.4.3/install-sh gcc-3.4.3/libstdc++-v3
cp gcc-3.4.3/install-sh gcc-3.4.3/maintainer-scripts
cp gcc-3.4.3/install-sh gcc-3.4.3/zlib
didn't seem to break anything, and the install completed
successfully.  Anyway, hopefully any problem will vanish when
3.4.4 comes out.

   cheers,
 DaveK
Thank you,
Hugh

gcc for syntax check only (C): need to read source from stdin

[Dimitry Golubovsky]

Hi,

A program I am working on generates some C code on the fly, and I
would like to check its syntax right after generation. I might save
this code fragment in a temporary file and gun gcc -c over it,
watching for exit code (0: syntax OK, 1: incorrect). This is fine with
the one exception that I have to create temporary files and then clean
them up. Does there exist any way to accompilsh this with pipes
entirely? Output object file may be discarded: I don't need it. Or I
might even use -S option to only assemble, but again, output must be
stdout, not a file (or /dev/null which does not work either: the last
program in the pipeline tries to CREATE it, not to write into it, and
fails).

Looking for verbose output from gcc -v -pipe ... I noticed that all
the components (cpp, cc1, as) are pipe-connectable (at least in most
cases). It is only the gcc (driver) which says e. g.

gcc: -E required when input is from standard input

which limits me to using preprocessor as a pipe only.

I am afraid direct invocation of cc1 may not be good because I have no
idea how its command line options are stable across various versions
of gcc.

Does there exist an alternative driver/script doing same job as the
"stock" gcc, but allowing piping its input and output?

Thank you.

-- 
Dimitry Golubovsky

Anywhere on the Web

proposal: explicit context pointers in addition to trampolines in C frontend

[Clifford Wolf]

Hi,

I've been thinking about trampolines and nested functions in C the other
day. I really like using trampolines for callback functions, such as in

http://svn.clifford.at/spl/trunk/spl_modules/mod_xml.c

see:

  static struct spl_node *handler_xml2tree(struct spl_task *task, void *data)
  {
[...]

void XMLCALL element_start_hdl(void *data, const char *el, const char 
**attr)
{
[...]
}

[ ... ]

XML_SetElementHandler(p, element_start_hdl, element_end_hdl);
  }

sure - I could also pack all the stuff which should be shared between
handler_xml2tree() and its element_start_hdl() in a struct and pass a
pointer to that struct as first argument to element_start_hdl(). But it
simply is easier (faster to implement) to do that with the trampoline
mechanism.

But, on the other hand, trampolines aren't very portable and require
an executeable stack, which isn't nice. So, it would be cool to be able to
do something like the following:

  static struct spl_node *handler_xml2tree(struct spl_task *task, void *data)
  {
[...]

void XMLCALL element_start_hdl(void *data
__attribute__ (( contextpointer(handler_xml2tree) )),
const char *el, const char **attr)
{
[...]
}

[ ... ]

XML_SetElementHandler(p, element_start_hdl, element_end_hdl);
XML_SetUserData(p, __builtin_contextpointer(handler_xml2tree));
  }

so, because the 1st argument of element_start_hdl() has this new, fancy,
attributute, it is using it to access the stack frame of its
handler_xml2tree(). The __builtin_contextpointer() is used to generate this
context pointers and no trampoline is ever generated when using
element_start_hdl as function pointer.

It's not that I would really _need_ this feature. It just came to my mind
when thinking about the trampoline thread from some time ago and I didn't
want the idea to get lost...

"You can now flame me, I am full of love."  ;-)

yours,
 - clifford

-- 
/"\  ASCII Ribbon Campaign - against html email
\ /- against microsoft office attachments
 X - against text above fullquote below
/ \- against lines longer than 79 characters
 
"The generation of random numbers is too important to be left to chance."
 - Robert R. Coveyou, Oak Ridge National Laboratory.
 


pgp0aBSaSqqwi.pgp
Description: PGP signature

RE: GCC 3.4.3

[Dave Korn]

Original Message
>From: Hugh Sasse Staff Elec Eng
>Sent: 12 April 2005 14:49
 
>>  Wouldn't it be an awful lot easier to just
>> 
>>  A) apply the previously-mentioned fix to toplevel?
> 
> If I knew where it was mentioned, probably.

  Earlier in this very thread, Daniel Jacobowitz said (in reply to Joe Buck,
who had observed the same bug in binutils, and was wondering if it was fixed
yet)

"Yes, since the fix was in the top level.  I have already closed at
least two binutils PRs about this as FIXED - searching for product ==
binutils, subject containing install, state containing RESOLVED would
have shown them."

  This leads pretty directly to PRs 179 and 824, although to be fair on
closer look the discussion attached to PR179 contains the words "patch
posted", and a changelog entry, but no link to the actual patch nor a full
checkin revision log.

http://sourceware.org/bugzilla/show_bug.cgi?id=179

  However the date makes it easy enough to track down in the cvs:

http://sourceware.org/cgi-bin/cvsweb.cgi/src/configure.in?cvsroot=src#rev1.2
43

 
>>  B) use a full path to configure, since this only crops up when using a
>> relative path to the configure script?
> 
> This seems to be what happened in practice, but my :

  

> didn't seem to break anything, and the install completed
> successfully.

  Yep, they won't have done any harm.  The bug is that the configure process
uses the path to configure to then generate a relative path to the
install-sh script.  If the original path to configure was absolute, then
this derived path is also absolute, and hence valid for use in any
subdirectory makefile.  In the case where your original path to configure
uses relative directory paths, so does the path that is eventually generated
to install-sh, and that's why it fails in deeper subdirectories: it's no
longer ascending far enough up the tree.  So when you use a full path to
configure, the single copy of install-sh will be invoked through that path,
and there isn't even the slightest possibility of those files being invoked
instead.

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

Re: GCC 4.0 RC1 Available

[Andrew Pinski]

> On 11/04/2005, at 11:23 PM, Ranjit Mathew wrote:
> 
> > Geoffrey Keating wrote:
> > [...]
> >> which I see you've already committed a patch for, and a large number
> >> of Java failures.
> >>
> >> You can see full test results at
> > [...]
> >>
> >> 
> >>
> >> for 4.0.0-20050410.
> >
> > It might be helpful to put your "libjava.log" somewhere
> > or if all the Java failures seem similar, to post
> > the error messages around the "FAIL" lines from your
> > libjava.log.
> 
> Many seem to be NoClassDefFoundError exceptions.  Some examples of  
> those plus all the unusual cases are:

What I don't understand is why does this only show up in 4.0 branch and
not the mainline.


-- Pinski

RE: GCC 3.4.3

[Hugh Sasse Staff Elec Eng]

On Tue, 12 Apr 2005, Dave Korn wrote:
Original Message
From: Hugh Sasse Staff Elec Eng
Sent: 12 April 2005 14:49

 Wouldn't it be an awful lot easier to just
 A) apply the previously-mentioned fix to toplevel?
If I knew where it was mentioned, probably.
 Earlier in this very thread, Daniel Jacobowitz said (in reply to Joe Buck,
who had observed the same bug in binutils, and was wondering if it was fixed
yet)
"Yes, since the fix was in the top level.  I have already closed at
least two binutils PRs about this as FIXED - searching for product ==
binutils, subject containing install, state containing RESOLVED would
have shown them."
I didn't realise looking here would actually give me the fix, or I'd
have looked. Sorry.  I've only noticed the comments about the fixes.
 This leads pretty directly to PRs 179 and 824, although to be fair on
closer look the discussion attached to PR179 contains the words "patch
posted", and a changelog entry, but no link to the actual patch nor a full
checkin revision log.
http://sourceware.org/bugzilla/show_bug.cgi?id=179
 However the date makes it easy enough to track down in the cvs:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/configure.in?cvsroot=src#rev1.2
43
OK, thanks for these refs.

 B) use a full path to configure, since this only crops up when using a
relative path to the configure script?
This seems to be what happened in practice, but my :
 
didn't seem to break anything, and the install completed
successfully.
 Yep, they won't have done any harm.  The bug is that the configure process
uses the path to configure to then generate a relative path to the
install-sh script.  If the original path to configure was absolute, then
this derived path is also absolute, and hence valid for use in any
[...]
Thanks for the explanation.  I think I've bumped into a relative
path problem before, hence my makefile was constructed correctly.  I
really wanted to be sure that I'd covered this possibility so I didn't
end up with half an install, so when I saw this come up I jumped at
it.
   cheers,
 DaveK
Thank you
Hugh

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[Kate Minola]

David,

> > Kate Minola writes:
> 
> Kate> Any thoughts on what is different between our two machines?
> Kate> Any suggestions for things to compare?
> 
>   Do you have all of the updates listed in the Target-specific
> installation notes for AIX installed?

Err ... what target-specific installation notes for AIX?

When I look in gcc-4.0.0-20050410/INSTALL at specific.html
I see under powerpc:

  powerpc*-*-* powerpc-*-sysv4 
  powerpc-*-darwin* 
  powerpc-*-elf powerpc-*-sysv4 
  powerpc*-*-linux-gnu* 
  powerpc-*-netbsd* 
  powerpc-*-eabiaix 
  powerpc-*-eabisim 
  powerpc-*-eabi 

Nothing jumps out at me as being related to powerpc-ibm-aix5.2.0.0.

Where are you looking?

Kate Minola
University of Maryland, College Park

Re: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0

[David Edelsohn]

> Kate Minola writes:

Kate> Err ... what target-specific installation notes for AIX?

Kate> Where are you looking?

*-ibm-aix*

David

RE: GCC 3.4.3

[Dave Korn]

Original Message
>From: Hugh Sasse Staff Elec Eng
>Sent: 12 April 2005 15:40

>> "Yes, since the fix was in the top level.  I have already closed at
>> least two binutils PRs about this as FIXED - searching for product ==
>> binutils, subject containing install, state containing RESOLVED would
>> have shown them."
> 
> I didn't realise looking here would actually give me the fix, or I'd
> have looked. Sorry.  I've only noticed the comments about the fixes.

  No problem, it's just a bit of advice that I thought was generic to enough
situations to bear repeating: if you've got a bug, always check the
bugzilla, because someone might have already found it and if you're lucky
they'll even have fixed (or at least explained) it.

> Thanks for the explanation.  I think I've bumped into a relative
> path problem before

  Yes, I remembered you tend to be building on Solaris, and I think it's
particularly on Solaris that this bug has manifested - most other systems
supply their own install utility, and so the gcc build system never ends up
needing to use the subsitute script.

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

Packaging error in 4.0RC1 docs? [was RE: Problem compiling GCC 4.0 RC1 on powerpc-ibm-aix5.2.0.0 ]

[Dave Korn]

Original Message
>From: Kate Minola
>Sent: 12 April 2005 16:15

> When I look in gcc-4.0.0-20050410/INSTALL at specific.html

  Oh, BTW, it seems the internal links in that page are b0rked in the usual
sort of way, owing to the mangling of 'special' characters.  A link like:

*-ibm-aix*

doesn't actually link up with an anchor like



*-ibm-aix*

  Oh, and the back-links from chapters to TOC don't work either, because
there aren't any anchors in the TOC at all.

  Oh, and there are TOC entries for chapters that don't exist at all, such
as 

powerpc-*-eabiaix

  Not exactly a showstopper, I know, but I thought I'd mention it for
completeness' sake...

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

Re: Mainline has been broken for more than 3 days now

[Caroline Tice]

The patch for this has already been submitted to gcc-patches:
http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01240.html
-- Caroline Tice
[EMAIL PROTECTED]
On Apr 12, 2005, at 6:04 AM, Diego Novillo wrote:
I have been using this crutch for the last couple of days to be
able to get mainline to bootstrap with java enabled.
Index: varasm.c
===
RCS file: /cvs/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.495
diff -u -3 -p -r1.495 varasm.c
--- varasm.c9 Apr 2005 20:41:49 -   1.495
+++ varasm.c10 Apr 2005 22:39:41 -
@@ -308,6 +308,7 @@ in_unlikely_text_section (void)
   ret_val = ((in_section == in_unlikely_executed_text)
 || (in_section == in_named
+&& cfun
 && cfun->unlikely_text_section_name
 && strcmp (in_named_name,
cfun->unlikely_text_section_name) == 0));
I know we are in stage1 and all, but shouldn't the timer have
started already for whatever patch broke mainline on 2005-04-10?
From the breakage, it seems that this change is at fault:
+2005-04-09  Caroline Tice  <[EMAIL PROTECTED]>
+
+   * bb-reorder.c 
(find_rarely_executed_basic_blocks_and_crossing_edges):
+   Remove targetm.have_named_sections test.
+   (fix_edges_for_rarely_executed_code): Likewise.
+   (insert_section_boundary_note): Likewise.
+   (reorder_basic_blocks): Check partitioning flag before calling
+   verify_hot_cold_block_grouping.
+   * dbxout.c (dbxout_function_end): Get hot/cold section labels 
from
+   the function struct rather than global variables.
+   * dwarf2out.c (COLD_TEXT_SECTION_LABEL): New macro.
+   (COLD_END_LABEL): Likewise
[ ... ]

But I'm not 100% sure that this is the case.
Diego.

Pinapa: A SystemC front-end based on GCC

[Matthieu Moy]

Pinapa is a SystemC front-end based on GCC that I've developed during
my Ph. D.

You can download and/or read more about Pinapa here:

http://greensocs.sourceforge.net/pinapa/


Many thanks to the GCC team: I didn't have to write a complete C++
parser thanks to GCC ;-).

-- 
Matthieu

Re: gcc for syntax check only (C): need to read source from stdin

[Devang Patel]

Try -fsyntax-only
On Apr 12, 2005, at 7:10 AM, Dimitry Golubovsky wrote:
Hi,
A program I am working on generates some C code on the fly, and I
would like to check its syntax right after generation. I might save
this code fragment in a temporary file and gun gcc -c over it,
watching for exit code (0: syntax OK, 1: incorrect). This is fine with
the one exception that I have to create temporary files and then clean
them up. Does there exist any way to accompilsh this with pipes
entirely? Output object file may be discarded: I don't need it. Or I
might even use -S option to only assemble, but again, output must be
stdout, not a file (or /dev/null which does not work either: the last
program in the pipeline tries to CREATE it, not to write into it, and
fails).
Looking for verbose output from gcc -v -pipe ... I noticed that all
the components (cpp, cc1, as) are pipe-connectable (at least in most
cases). It is only the gcc (driver) which says e. g.
gcc: -E required when input is from standard input
which limits me to using preprocessor as a pipe only.
I am afraid direct invocation of cc1 may not be good because I have no
idea how its command line options are stable across various versions
of gcc.
Does there exist an alternative driver/script doing same job as the
"stock" gcc, but allowing piping its input and output?
Thank you.
--
Dimitry Golubovsky
Anywhere on the Web
-
Devang

Re: gcc for syntax check only (C): need to read source from stdin

[Devang Patel]

To read source from stdin use "-".
preprocessor man page says,
   Either infile or outfile may be -, which as infile means to  
read from
   standard input and as outfile means to write to standard output.

On Apr 12, 2005, at 7:10 AM, Dimitry Golubovsky wrote:
Hi,
A program I am working on generates some C code on the fly, and I
would like to check its syntax right after generation. I might save
this code fragment in a temporary file and gun gcc -c over it,
watching for exit code (0: syntax OK, 1: incorrect). This is fine with
the one exception that I have to create temporary files and then clean
them up. Does there exist any way to accompilsh this with pipes
entirely? Output object file may be discarded: I don't need it. Or I
might even use -S option to only assemble, but again, output must be
stdout, not a file (or /dev/null which does not work either: the last
program in the pipeline tries to CREATE it, not to write into it, and
fails).
Looking for verbose output from gcc -v -pipe ... I noticed that all
the components (cpp, cc1, as) are pipe-connectable (at least in most
cases). It is only the gcc (driver) which says e. g.
gcc: -E required when input is from standard input
which limits me to using preprocessor as a pipe only.
I am afraid direct invocation of cc1 may not be good because I have no
idea how its command line options are stable across various versions
of gcc.
Does there exist an alternative driver/script doing same job as the
"stock" gcc, but allowing piping its input and output?
Thank you.
--
Dimitry Golubovsky
Anywhere on the Web
-
Devang

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Andi Kleen]

Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

> On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
>> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
>> or so... I still lean on that crutch.
>
> A user!  Can you explain why?

The x86-64 2.4 linux kernel uses it too, because some code relies on 
the ordering between asm and several functions.
Other Linux ports might be similarly affected. 2.6 is fixed, but the
fix is a bit too big to merge into a stable-nearly-dead tree like 2.4.


-Andi

Re: gcc for syntax check only (C): need to read source from stdin

[Dimitry Golubovsky]

Devang,

Thanks for your relpy.

This addresses only compiler's action problem (no output produced),
but does not address the stdin problem.

When I try

% cat a.c | gcc -fsyntax-only  -

I get

gcc: -E required when input is from standard input

again

and when I use -E it only runs the preprocessor, nothing else.

i. e. gcc still does not want to do anything beyond preprocessing
using stdin as input.

On 4/12/05, Devang Patel <[EMAIL PROTECTED]> wrote:
> Try -fsyntax-only
-- 
Dimitry Golubovsky

Anywhere on the Web

Re: Semi-Latent Bug in tree vectorizer

[Jeffrey A Law]

On Sat, 2005-04-09 at 23:23 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> 
> > When we vectorize the store we copy the virtual operands from the
> > original statement to the new vectorized statement via this code:
> > 
> >   /* Copy the V_MAY_DEFS representing the aliasing of the original array
> >  element's definition to the vector's definition then update the
> >  defining statement.  The original is being deleted so the same
> >  SSA_NAMEs can be used.  */
> >   copy_virtual_operands (*vec_stmt, stmt);
> >   v_may_defs = STMT_V_MAY_DEF_OPS (*vec_stmt);
> >   nv_may_defs = NUM_V_MAY_DEFS (v_may_defs);
> > 
> >   for (i = 0; i < nv_may_defs; i++)
> > {
> >   tree ssa_name = V_MAY_DEF_RESULT (v_may_defs, i);
> >   SSA_NAME_DEF_STMT (ssa_name) = *vec_stmt;
> > }
> > 
> > This is safe if and only if the the operand scanning code will compute
> > the same V_MAY_DEFS for the original scalar statement and the new
> > vectorized statement.  ie, *D.1470 must have the same aliasing
> > properties as *vect_px.17.
> > 
> Right.  Both the vectorizer and ivopts have the side-effect of
> refining aliasing information.  Therefore, blindly copying
> virtual operands is not correct.
OK.  I can live with that.

> Could you try this patch?  It fixes your test case and doesn't
> produce new regressions in the vectorizer tests.  It's not
> bootstrapped nor tested otherwise.
I've got some other stuff spinning right now, so it'll be later
today before I can do anything significant with it.


> The idea is that we should treat both the vectorized statement
> and the old statement separately.  The virtual defs from the old
> statement are going away and the new one is getting brand new
> symbols exposed.  That's why we mark them separately.
Understood.

FWIW, you don't need a new testcase -- the one I posted is just
a cut down version of one already in the testsuite.


jeff

Re: RFC: Plan for cleaning up the "Addressing Modes" macros

[Zack Weinberg]

Bernd Schmidt <[EMAIL PROTECTED]> writes:

> Zack Weinberg wrote:
>> The target macros described in the "Addressing Modes" section of the
>> internals manual are rather badly in need of cleaning up.
>
> What's your status on this - would you mind very much if I made
> changes to those macros now?

I won't have time to work on this anytime soon, so go ahead and do as
you like.

zw

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Daniel Kegel]

Andi Kleen wrote:
Daniel Jacobowitz <[EMAIL PROTECTED]> writes:

On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
or so... I still lean on that crutch.
A user!  Can you explain why?

The x86-64 2.4 linux kernel uses it too, because some code relies on 
the ordering between asm and several functions.
Other Linux ports might be similarly affected. 2.6 is fixed, but the
fix is a bit too big to merge into a stable-nearly-dead tree like 2.4.
Last I checked, the live cvs tree for glibc
still used  -fno-unit-at-a-time.  Maybe Jakub can comment on
the timetable for getting rid of -fno-unit-at-a-time.
(And even if glibc-2.4.0 no longer needs -fno-unit-at-a-time,
there will still be people who want to build
oldish glibc's with new gcc's.  I tend to sympathize
with them, and explicitly support building gcc-4.0/glibc toolchains
with glibc-2.1.3 and up in crosstool.  Yeah, crosstool's a
bit obsessive -- there's no real reason to use the same gcc
for glibc as for user programs -- but it's simpler than
building an older gcc just to build glibc.)
- Dan

Re: gcc for syntax check only (C): need to read source from stdin

[Zack Weinberg]

Dimitry Golubovsky <[EMAIL PROTECTED]> writes:

> Devang,
>
> Thanks for your relpy.
>
> This addresses only compiler's action problem (no output produced),
> but does not address the stdin problem.
>
> When I try
>
> % cat a.c | gcc -fsyntax-only  -
>
> I get
>
> gcc: -E required when input is from standard input

In order to run the compiler as well, you have to tell it what
language it's getting, e.g.

$ cat a.c | gcc -x c -fsyntax-only -

Normally this is determined from the file extension, but that's not
available when reading stdin.  It doesn't matter (much) when running
the preprocessor, which is why it lets you do that without the -x c.

zw

RE: gcc for syntax check only (C): need to read source from stdin

[Dave Korn]

Original Message
>From: Zack Weinberg
>Sent: 12 April 2005 18:02

> Dimitry Golubovsky <[EMAIL PROTECTED]> writes:
> 
>> Devang,
>> 
>> Thanks for your relpy.
>> 
>> This addresses only compiler's action problem (no output produced),
>> but does not address the stdin problem.
>> 
>> When I try
>> 
>> % cat a.c | gcc -fsyntax-only  -
>> 
>> I get
>> 
>> gcc: -E required when input is from standard input
> 
> In order to run the compiler as well, you have to tell it what
> language it's getting, e.g.
> 
> $ cat a.c | gcc -x c -fsyntax-only -
> 
> Normally this is determined from the file extension, but that's not
> available when reading stdin.  It doesn't matter (much) when running
> the preprocessor, which is why it lets you do that without the -x c.
> 
> zw


  Then the error message *really* ought to say

gcc: -E or -x required when input is from standard input

since it is thoroughly obtuse and non-explanatory as it stands.  The
attached is against 4.0 RC1, but I imagine it'll apply cleanly to HEAD with
just a little fuzz, if people feel it's the right thing.  However, I must be
honest enough to warn that it _is_ untested! :-O  Conceivably it could break
a dg error or warning test, but I couldn't find the phrases "when input" or
"from standard" with "grep -R gcc/testsuite/*", and I eyeballed every
instance of the word "required" in the testsuite, and I couldn't find any
such test.



2005-12-04  Dave Korn  <[EMAIL PROTECTED]>

* gcc.c (default_compilers):  Clarify obscure error message.

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


obscure-error-msg-patch.diff
Description: Binary data

RE: gcc for syntax check only (C): need to read source from stdin

[Dave Korn]

Original Message
>From: Dave Korn
>Sent: 12 April 2005 18:19

> 
> 
> 2005-12-04  Dave Korn  <[EMAIL PROTECTED]>


  Oops.  Please forgive mixed-endian date!  It is of course the 12th of
April and not the 4th of December today!


2005-04-12  Dave Korn  <[EMAIL PROTECTED]>

* gcc.c (default_compilers):  Clarify obscure error message.


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

Re: gcc for syntax check only (C): need to read source from stdin

[Dimitry Golubovsky]

Zack,

Now this works. Thanks a lot.

And with -pipe, no temporary files at all (checked -v output).

Could this be possibly placed in some FAQ? I tried to google for this
first but did not get such a definitive (and simple) answer.

On 4/12/05, Zack Weinberg <[EMAIL PROTECTED]> wrote:

> In order to run the compiler as well, you have to tell it what
> language it's getting, e.g.
> 
> $ cat a.c | gcc -x c -fsyntax-only -
> 
> Normally this is determined from the file extension, but that's not
> available when reading stdin.  It doesn't matter (much) when running
> the preprocessor, which is why it lets you do that without the -x c.
> 
> zw
> 

-- 
Dimitry Golubovsky

Anywhere on the Web

Re: gcc for syntax check only (C): need to read source from stdin

[Zack Weinberg]

"Dave Korn" <[EMAIL PROTECTED]> writes:

>   Then the error message *really* ought to say
>
> gcc: -E or -x required when input is from standard input
>
> since it is thoroughly obtuse and non-explanatory as it stands.  The
> attached is against 4.0 RC1, but I imagine it'll apply cleanly to HEAD with
> just a little fuzz, if people feel it's the right thing.

Yes, I think this is the right thing.  Please test against mainline
and apply it there if successful.  I don't think it is important
enough to put into 4.0.0, but you should put it on the 4.0 branch
after the release, and maybe the 3.4 branch as well.

zw

RE: gcc for syntax check only (C): need to read source from stdin

[Dave Korn]

Original Message
>From: Zack Weinberg
>Sent: 12 April 2005 18:31

> Yes, I think this is the right thing.  Please test against mainline
> and apply it there if successful.  I don't think it is important
> enough to put into 4.0.0, but you should put it on the 4.0 branch
> after the release, and maybe the 3.4 branch as well.


  No write perms mate!  However I'll check out HEAD and do a
before-and-after testsuite run overnight, and get back to you in the morning
with the results (UK time).  Will "--enable-languages=c,c++" be enough, or
do you want me to test against all default languages?


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

Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources

[Mike Stump]

On Tuesday, April 12, 2005, at 06:38  AM, Karel Gardas wrote:
Especially: ``Currently gcc takes a cache miss every 20 instructions, 
or
some ungodly number, and that really saps performance.''

but I don't know if this is just an 1st April fool joke
Nope, no joke.  The exact number will vary from machine to machine, and 
testcase to testcase, but it is much lower than most workloads.

 or the reality and if I understand "cache miss" right and if this is 
L1 or L2 cache miss.
D3 miss as I recall.
cachegrind can also be used to estimate the number (though, not sure 
how accurate it is, possibly not very).  I use Shark to actually get 
the real number.

If you can get the SPEC ratings of the machine, you can then just pull 
out the gcc specint number, and have a rough guess what type of compile 
time performance you would get.  A open mosix cluster with 4 cheap 
machines I suspect will compile faster (prive/performance) than one 
big, expensive box (rough guess).

We talked about this before, see:
http://gcc.gnu.org/ml/gcc/2002-08/msg00853.html
http://gcc.gnu.org/ml/gcc/2002-08/msg00886.html
http://gcc.gnu.org/ml/gcc/2002-08/msg01174.html
http://gcc.gnu.org/ml/gcc/2002-08/msg00763.html
for examples...

GCC 4.0 RC2

[Mark Mitchell]

Sadly, it's become clear there's going to have to be a second release 
candidate.  In particular, there are some wrong-code bugs that are 
popping up on real packages on primary platforms.  Jason Merill is 
looking into some of the C++ issues, but he's in Lillehammer this week 
for the ISO meeting.

Therefore, I'm going to allow some of the queued patches into 4.0 at 
this time.  If your patch isn't on this list, but is here:

http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0
I'm still considering it.  I'll let you know if I've firmly decided that 
your patch will not be in RC2.

I don't have a date for RC2 yet; that will depend in part on when Jason 
is able to fix the C++ issues.  However, I would certainly hope that we 
could get it done shortly.

Here are the patches approved thus far for RC2:
* http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01108.html
  Patch to fix __builtin_apply_args on SPARC (specific).
* http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01036.html
  GLIBC does not compile on S390.
* http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01015.html
  Fortran fix.
* http://gcc.gnu.org/ml/java-patches/2005-q2/msg00088.html
  Java library patch.
Thanks,
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: gcc for syntax check only (C): need to read source from stdin

[Zack Weinberg]

"Dave Korn" <[EMAIL PROTECTED]> writes:

>   No write perms mate!  However I'll check out HEAD and do a
> before-and-after testsuite run overnight, and get back to you in the morning
> with the results (UK time).  Will "--enable-languages=c,c++" be enough, or
> do you want me to test against all default languages?

For this, c/c++ should be fine.

zw

Re: GCC 4.0 RC1 Available

[Mark Wielaard]

Hi,

On Mon, 2005-04-11 at 15:33 -0700, Per Bothner wrote:
> Printing getClass().getClassLoader() yields:
> gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
>parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> 
> Note the urls=[file:./].  Looks like it's ignoring the CLASSPATH
> environment option.

I tried to replicate this issue with some simple example, but all my
tries just work as expected. Could you give some information about your
system? How can I replicate this? (what do I download, how do I
compile/run it) What does the following program output for you?

public class CL
{
  public static void main(String[] args) throws Exception
  {
System.out.println(ClassLoader.getSystemClassLoader());
  }
}

$ gcj -C CL.java
$ CLASSPATH=.:/:/usr:/random gij CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:/,file:/usr/],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}

So on my system (Debian GNU/Linux testing/x86) setting CLASSPATH seems
to work as expected. (Note that /random gets dropped since it doesn't
exist.)

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part

Re: GCC 4.0 RC1 Available

[Per Bothner]

Mark Wielaard wrote:
I tried to replicate this issue with some simple example,
...
$ gcj -C CL.java
$ CLASSPATH=.:/:/usr:/random gij CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./,file:/,file:/usr/],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
Try compiling to native:
$ gcj -o CL CL.java --main=CL
$ CLASSPATH=.:/:/usr:/random ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./], 
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}

(Of course to be picky "file:/usr/" is not a valid URL ...)
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: about the parse tree

[Mike Stump]

On Monday, April 11, 2005, at 07:47  PM, zouq wrote:
i want very much to learn more about the parse tree in gcc.
tree.def is fairly dense and contains many of the details about trees.  
Have you read that?

can some one show me some way to learn it a little easier,
i have tried to debug it, but the structure is difficult to understand,
Did you use pt in gdb?  If you don't know about it, see .gdbinit.  pt 
and pr are sort of handy.

Did you read all of:
http://gcc.gnu.org/onlinedocs/gccint/index.html#toc_Trees
?
Give us examples of the type of specific questions your interested in, 
and we might be able to point at other places...

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Daniel Jacobowitz]

On Tue, Apr 12, 2005 at 06:34:29PM +0200, Andi Kleen wrote:
> Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
> 
> > On Mon, Apr 11, 2005 at 10:02:06AM -0700, Daniel Kegel wrote:
> >> BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
> >> or so... I still lean on that crutch.
> >
> > A user!  Can you explain why?
> 
> The x86-64 2.4 linux kernel uses it too, because some code relies on 
> the ordering between asm and several functions.
> Other Linux ports might be similarly affected. 2.6 is fixed, but the
> fix is a bit too big to merge into a stable-nearly-dead tree like 2.4.

Thanks.  I was under the impression that 2.4 doesn't build with GCC
HEAD, anyway - I saw some patches pile up and not get applied.

Does 2.6 still use the option?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

About the number of DOM's iterations.

[Kazu Hirata]

Hi,

Note that with -O1, we limit the number of iterations of DOM to 1 so
that we can get resonable compile time performance.  I was wondering
what happens if we do the same with -O2 now that we have passes like
copy-prop, VRP, and improved FRE as well as good and old CCP.

Numbers go first.  All of the following numbers are obtained from
compiling cc1-i files with -O2.

version #iters #blocks  %cov #thread

 v0   9097  514501 94.5%9438
 v1   8602  553685 95.5%   20868
 v2   8609  510618 96.3%   23236
 v3   8490  510734 97.2%   23262
 v4   7193  188793   N/A   18450

Legend
--

v0 : Vanilla mainline with the second and third runs of DOM disabled.
v1 : v0 with Jeff's patch in PR 19794
v2 : v1 with the following TCB-like tweak to the pass ordering

  NEXT_PASS (pass_ccp);
  NEXT_PASS (pass_copy_prop);
  NEXT_PASS (pass_fre);
  NEXT_PASS (pass_dce);
  NEXT_PASS (pass_vrp);
  NEXT_PASS (pass_merge_phi);
  NEXT_PASS (pass_dominator);

v3 : v2 with my queued VRP improvements
v4 : v3 with the number of DOM's iterations limited to 1

#iters : the number of times we iterate in the do-while loop in
tree-ssa-dom.c:tree_ssa_dominator_optimize.

#blocks : the number of blocks scanned by DOM.  This is done by adding
one line at the entrance of the aforementioned do-while loop.

  num_cfg_blocks += n_basic_blocks;

%cov : the percentage of invocations of DOM that finished its work
within 2 iterations.

#threaded : the number of edges threaded

Disclaimers
---

o I have not measured compile time performance.
o I have not done benchmark on generated code.
o I have not tried any other pass ordering.
o I have not considered other testcases or languages.

Justifications for v0, ..., v4 and columns
--

v0 is because I wanted to stay simple and focus on the initial basic
propagation.  v1 is because Jeff will soon remove various restrictions
on the jump threader that have been limiting jump threading.  For v2,
note that ccp, copy-prop, FRE, and VRP are all something that DOM does
to some extent.  I put my merge_phi right before DOM so that DOM can
find more jump threading opportunities in its first iteration.

#iter is mostly out of curiosity.  Functions that we compile come in
different size, so the number isn't that important.  For the same
reason, #blocks is more interesting.  It's a rough measure of how much
time DOM takes.

Now %cov.  Why 2 iterations?  Well, DOM has a fixed point operation,
meaning that the last iteration does not do anything.  More
specifically, the last iteration does not perform any jump threading.
Whenever jump threading opportunities are taken, cleanup_tree_cfg
called from tree_ssa_dominator_optimize always returns 1, triggering
the next iteration.

Observations


Even with v0, the vast majority of functions require at most two
iterations, so we are in diminishing returns territory to begin with.
With v3, we get impressive 97.2%, meaning that 97.2% of time, DOM
iterates at most two times, which in turn means that 97.2% of time, we
don't take any jump threading opportunity in DOM's second iteration.

Note that with v4, the number of blocks that DOM looks at goes down
significantly.  At the same time, the number of edges threaded also
goes down but is still close to the level of v1.

It's interesting that even if we let DOM iterate as many times as it
likes to iterate, there is a sizable difference between v1 and v2 as
far as the number of edges threaded.  Certain things cannot be
propagated using DOM.

Future work
---

o Address things listed in Disclaimers.
o Submit my queued VRP patches as soon as mainline gets a bit more
  stable.
o Speed up things like the incremental SSA update, and the propagator.
o Try out some ideas to get more out of the first iteration of DOM.
o Take advantage of value ranges in thread_across_edge.

Kazu Hirata

Re: Getting rid of -fno-unit-at-a-time [Was Re: RFC: Preserving order of functions and top-level asms via cgraph]

[Daniel Kegel]

Daniel Jacobowitz wrote:
BTW, I hope -fno-unit-at-a-time doesn't go away until at least gcc-4.1.1
or so... I still lean on that crutch.
A user!  Can you explain why?
The x86-64 2.4 linux kernel uses it too, because some code relies on 
the ordering between asm and several functions.
Other Linux ports might be similarly affected. 2.6 is fixed, but the
fix is a bit too big to merge into a stable-nearly-dead tree like 2.4.

Thanks.  I was under the impression that 2.4 doesn't build with GCC
HEAD, anyway - I saw some patches pile up and not get applied.
I haven't tried.
Guess I'll add a linux-2.4-with-gcc-4.0 column to
http://kegel.com/crosstool/current/buildlogs/
to shed some light on this.

RFC:Updated VEC API

[Nathan Sidwell]

Hi,
I promised to fix up the vector api, and there's a design decision
which needs to be made (incidentally, if we were in C++ land, we wouldn't
have to chose, as the right thing just happens).
The old API keyed the allocation strategy off the type name. This led to
the lovely
typedef tree tree_on_heap;
so we could have heap allocated vectors of trees (as well as the default
gc allocated ones).
We want to separate this, so you'd now say something like
DEF_VEC(tree,heap);
DEF_VEC(tree,gc);
...
VEC(tree,heap) *on_heap;
VEC(tree,gc)  *in_gc;
Now, certain vector accessors need to know the allocation mechanism (appending
for instance), and others don't (indexing, for instance).  We also need
to obey the one definition rule.
option1) Require the allocation mechanism to be mentioned in *all* vector API
calls.  So you'd have 'VEC_append (tree,gc,v,t)', but you'd also have
'VEC_length (tree,gc,v)', which is kind of annoying.
option2) Split the DEF_VEC operation into DEF_VEC and DEF_VEC_ALLOC parts.
The former would define all the non-allocation sensitive routines, and the
latter defines all the allocation specific ones. So now when defining a vector
type you'd have
DEF_VEC(tree); // define the common tree routines
DEF_VEC_ALLOC(tree,gc);  // define the gc tree routines
DEF_VEC_ALLOC(tree,heap);  // define the heap tree routines
But you can now say 'VEC_length (tree,v)', without caring whether it's
a gc'd or heap allocated vector.  Unfortunately, now there must be
*exactly* one invocation of DEF_VEC(tree), regardless of where the
DEF_VEC_ALLOC calls are, which is also annoying.
Option1 is more easy to implement. Option2 requires a little nested
structure jiggery pokery to retain type safety.
So which has the more annoying downside, or alternatively, the more
satisfactory upside?
Another option, is whether the type and allocation parameters of the
API calls are themselves parenthesized into a single macro argument,
as in
VEC_append ((tree,gc),v,t)
Would this be a suitable visual aid to make those stand out as
'not expressions'? (In C++ land, you'd write it as
'VEC_append (v,t)', if you really wanted a template-id-expr.
Mostly you'd just let template deduction DTRT and have a plain
'VEC_append (v,t)')
comments?
nathan
--
Nathan Sidwell::   http://www.codesourcery.com   :: CodeSourcery LLC
[EMAIL PROTECTED]:: http://www.planetfall.pwp.blueyonder.co.uk

Re: GCC 4.0 RC1 Available

[Mark Wielaard]

On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote:
> Try compiling to native:
> 
> $ gcj -o CL CL.java --main=CL
> $ CLASSPATH=.:/:/usr:/random ./CL
> gnu.gcj.runtime.SystemClassLoader{urls=[file:./], 
> parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}

Aha. Thanks. As a workaround you can use the GCJ_PROPERTIES environment
variable for now:

GCJ_PROPERTIES='java.class.path=../..' ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:../../],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}

I am looking for a real solution.

Cheers,

Mark


signature.asc
Description: This is a digitally signed message part

Re: GCC 4.0 RC2

[Steven Bosscher]

On Tuesday 12 April 2005 19:59, Mark Mitchell wrote:
> Therefore, I'm going to allow some of the queued patches into 4.0 at
> this time.  If your patch isn't on this list, but is here:
>
> http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0
>
> I'm still considering it.  I'll let you know if I've firmly decided that
> your patch will not be in RC2.

Could you add http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01107.html
to your list?  If the patch is OKed by rth (ping! :-), it would fix a
-fPIC ICE regression on IA32 and AMD64.

Gr.
Steven

Re: GCC 4.0 RC2

[Joel Sherrill <[EMAIL PROTECTED]>]

I know I asked late in the process but this fix for a m68k/coldfire 
failure just showed up:

[Bug target/18421] ICE in reload_cse_simplify_operands, at postreload.c:391
Any chance at it getting considered?
Thanks.
--joel
Mark Mitchell wrote:
Sadly, it's become clear there's going to have to be a second release 
candidate.  In particular, there are some wrong-code bugs that are 
popping up on real packages on primary platforms.  Jason Merill is 
looking into some of the C++ issues, but he's in Lillehammer this week 
for the ISO meeting.

Therefore, I'm going to allow some of the queued patches into 4.0 at 
this time.  If your patch isn't on this list, but is here:

http://gcc.gnu.org/wiki/Last-Minute%20Requests%20for%204.0.0
I'm still considering it.  I'll let you know if I've firmly decided that 
your patch will not be in RC2.

I don't have a date for RC2 yet; that will depend in part on when Jason 
is able to fix the C++ issues.  However, I would certainly hope that we 
could get it done shortly.

Here are the patches approved thus far for RC2:
* http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01108.html
  Patch to fix __builtin_apply_args on SPARC (specific).
* http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01036.html
  GLIBC does not compile on S390.
* http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01015.html
  Fortran fix.
* http://gcc.gnu.org/ml/java-patches/2005-q2/msg00088.html
  Java library patch.
Thanks,

--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED] On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
   Support Available (256) 722-9985

RE: gcc for syntax check only (C): need to read source from stdin

[Dave Korn]

Original Message
>From: Dave Korn
>Sent: 12 April 2005 18:45

>   No write perms mate!  However I'll check out HEAD and do a
> before-and-after testsuite run overnight, and get back to you in the
> morning with the results (UK time).  

  I spoke too soon.

[EMAIL PROTECTED] /gnu/testing/obj-HEAD> make check 2>&1 | tee check.log
make[1]: Entering directory `/davek/patch-gnu/testing/obj-HEAD/fixincludes'
autogen -T /gnu/testing/HEAD/gcc/fixincludes/check.tpl
/gnu/testing/HEAD/gcc/fix
includes/inclhack.def
autogen: not found
make[1]: *** [check] Error 127
make[1]: Leaving directory `/davek/patch-gnu/testing/obj-HEAD/fixincludes'
make: *** [check-fixincludes] Error 2
[EMAIL PROTECTED] /gnu/testing/obj-HEAD> make check 2>&1 | tee check.log



  How long has "make check" required autogen?  Or alternatively, how long
has "make check" required fixincludes?

  Autogen doesn't build on cygwin, or at least none of the versions I've
tried so far.  Nor is there any official cygwin autogen package available.

  So unless there's something me and google have overlooked, I don't think
anyone's going to be doing any testing of 4.x on cygwin.


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

gcc cache misses [was: Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources]

[Karel Gardas]

On Tue, 12 Apr 2005, Mike Stump wrote:

> On Tuesday, April 12, 2005, at 06:38  AM, Karel Gardas wrote:
> > Especially: ``Currently gcc takes a cache miss every 20 instructions,
> > or
> > some ungodly number, and that really saps performance.''
> >
> > but I don't know if this is just an 1st April fool joke
>
> Nope, no joke.  The exact number will vary from machine to machine, and
> testcase to testcase, but it is much lower than most workloads.
>
> >  or the reality and if I understand "cache miss" right and if this is
> > L1 or L2 cache miss.
>
> D3 miss as I recall.
>
> cachegrind can also be used to estimate the number (though, not sure
> how accurate it is, possibly not very).  I use Shark to actually get
> the real number.

Perhaps it's possible that cachegrind is wrong or cache misses differ from
platform to platform, but I would tell that I get very good numbers for
gcc running on x86 platform:

==2634== I   refs:  6,930,091,914
==2634== I1  misses:   21,057,598
==2634== L2i misses:1,748,958
==2634== I1  miss rate:  0.30%
==2634== L2i miss rate:   0.2%
==2634==
==2634== D   refs:  3,547,549,621  (2,283,456,901 rd + 1,264,092,720 wr)
==2634== D1  misses:   27,091,035  (   24,245,031 rd + 2,846,004 wr)
==2634== L2d misses:9,560,838  (7,447,877 rd + 2,112,961 wr)
==2634== D1  miss rate:   0.7% (  1.0%   +   0.2%  )
==2634== L2d miss rate:   0.2% (  0.3%   +   0.1%  )
==2634==
==2634== L2 refs:  48,148,633  (   45,302,629 rd + 2,846,004 wr)
==2634== L2 misses:11,309,796  (9,196,835 rd + 2,112,961 wr)
==2634== L2 miss rate:0.1% (  0.0%   +   0.1%  )
--2634--
--2634-- Distinct files:   161
--2634-- Distinct fns: 2988
--2634-- BB lookups:   296865
--2634-- With full  debug info: 96% (286724)
--2634-- With file/line debug info:  0% (0)
--2634-- With fn name   debug info:  2% (7538)
--2634-- With nodebug info:  0% (2603)
--2634-- BBs Retranslated: 0
--2634-- Distinct instrs:  243399
--2634-- TT/TC: 0 tc sectors discarded.
--2634--56030 chainings, 0 unchainings.
--2634-- translate: new 53466 (817978 -> 7795557; ratio 95:10)
--2634--discard 0 (0 -> 0; ratio 0:10).
--2634--  dispatch: 140800 jumps (bb entries), of which 229222501 (16%) 
were unchained.
--2634--28161/1069704 major/minor sched events.  540307 tt_fast 
misses.
--2634-- reg-alloc: 398 t-req-spill, 1509791+1072 orig+spill uis, 196410 
total-reg-r.
--2634--sanity: 28162 cheap, 1127 expensive checks.
--2634--ccalls: 243735 C calls, 81% saves+restores avoided (1183722 bytes)
--2634--379914 args, avg 0.71 setup instrs each (214802 bytes)
--2634--0% clear the stack (731205 bytes)
--2634--0 retvals, 100% of reg-reg movs avoided (0 bytes)


that's with valgrind 1.9.8 "simulating" AMD64 512KB L2 cache processor:

==2634== Startup, with flags:
==2634==--suppressions=/opt/valgrind/lib/valgrind/default.supp
==2634==--I1=65536,2,64
==2634==--D1=65536,2,64
==2634==--L2=524288,8,64
==2634==-v
==2634== Cache configuration used:
==2634==   I1: 65536B, 2-way, 64B lines
==2634==   D1: 65536B, 2-way, 64B lines
==2634==   L2: 524288B, 8-way, 64B lines


The running program is gcc3.4.2 compiling one of MICO demos (i.e. quite a
load of C++ headers). Just to be sute that my valgrind is reporting
"correct" numbers, I've tested compiling of simple C++ hello world
(iostream-based) on real Opteron and the numbers (obtained from valgrind
2.2.0 on FC3) were also quite optimistic (actually here gcc running is
3.3.x):


==4107== I   refs:  568,524,260
==4107== I1  misses:  3,448,484
==4107== L2i misses: 60,065
==4107== I1  miss rate:0.60%
==4107== L2i miss rate: 0.1%
==4107==
==4107== D   refs:  303,765,394  (187,496,999 rd + 116,268,395 wr)
==4107== D1  misses:  2,397,678  (  1,937,986 rd + 459,692 wr)
==4107== L2d misses:462,261  (141,702 rd + 320,559 wr)
==4107== D1  miss rate: 0.7% (1.0%   + 0.3%  )
==4107== L2d miss rate: 0.1% (0.0%   + 0.2%  )
==4107==
==4107== L2 refs: 5,846,162  (  5,386,470 rd + 459,692 wr)
==4107== L2 misses: 522,326  (201,767 rd + 320,559 wr)
==4107== L2 miss rate:  0.0% (0.0%   + 0.2%  )
--4107--
--4107-- Distinct files:   1
--4107-- Distinct fns: 221
--4107-- Distinct lines:   221
--4107-- Distinct instrs:  43222
--4107-- BB lookups:   192038
--4107-- With full  debug info:  0% (0)
--4107-- With file/line debug info:  0% (0)
--4107-- With fn name   debug info:  9% (18970)
--4107-- With nodebug info: 90% (173068)
--4107-- BBs Retranslated: 0
--4107-- TT/TC: 0 tc sectors discarded.
--4107--115853 tt_fast misses.
--4107-- translate: new 43222 (637547 -> 6316429; r

ada build failure?

[Richard Henderson]

Is anyone else seeing this?  I see the same with either 3.3 or 3.4
as the build compiler.

gcc -c -g  -gnatpg -gnata -I- -I. -Iada -I../../src-gcc/gcc/ada \
  ../../src-gcc/gcc/ada/exp_ch11.adb -o ada/exp_ch11.o
exp_ch11.adb:926:34: expected type "Char_Code_Base" defined at types.ads:531
exp_ch11.adb:926:34: found private type "Uint" defined at uintp.ads:50


r~

Re: ada build failure?

[Graham Stott]

Richard,
No but I haven't been able to bootstrap with Ada since Friday I'm  currently 
getting
stage1/xgcc -Bstage1/ -B/usr/local/NETGCC/i686-pc-linux-gnu/bin/ -c -O2 -g 
-fomit-frame-pointer
-gnatpg -gnata -I- -I. -Iada -I/src/gcc4.0/gcc/gcc/ada 
/src/gcc4.0/gcc/gcc/ada/ada.ads -o ada/ada.o
raised STORAGE_ERROR : stack overflow (or erroneous memory access)
Richard Henderson wrote:
Is anyone else seeing this?  I see the same with either 3.3 or 3.4
as the build compiler.
gcc -c -g  -gnatpg -gnata -I- -I. -Iada -I../../src-gcc/gcc/ada \
  ../../src-gcc/gcc/ada/exp_ch11.adb -o ada/exp_ch11.o
exp_ch11.adb:926:34: expected type "Char_Code_Base" defined at types.ads:531
exp_ch11.adb:926:34: found private type "Uint" defined at uintp.ads:50
r~

New optimisation idea ?

[Christophe Jaillet]

Reading point 3. of "Removal of duplicate effort at
http://gcc.gnu.org/wiki/Speedup%20areas, I got the following idea :

First of all, I don't think that it is actually done by gcc. If I'm wrong or
if this idea doesn't worse the effort, just forget about it.

+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=

Many function in real world coding look like :
 int foo()
{
   if ()
   return 0;

   ;
   return 1;
}

bar()
{
   ...
   foo(...);
   ...
}

That is to say :
* bar has to call foo, to check the parameters
* if the check fails, a call to a function, pushing and poping
arguments, stack adjustment, ... could have been avoided
* bar may already have some kind of checking before calling foo
(sometimes the parameters sent to foo are also parameters sent to bar, in
particular with NULL pointer checking and so on)
* if the test was performed in bar, the other passes of gcc (scheduler,
copy propagation, cse...) could maybe have more opportunities to do a better
job

So I think that gcc could :
* partially inline foo (if the beginning is *simple enough* and can have
a return before any real computation)
* insert the tests in the location where foo is called
* duplicate code of foo to have 2 versions of the code : the original
one and one without the already inlined code
* call the 2nd version of the function wherever code partially inlined
have been inserted.

So in the example, we would get :
/* still needed if the function is not static ? */
 int foo()
{
   if ()
   return 0;

   ;
   return 1;
}

 int foo_partially_inlined()
{
   ;
   return 1;
}

bar()
{
   ...
   if (! )
   foo_partially_inlined(...);
   ...
}



I hope I'm clear enough and that the basic idea is clear enough.

As I said, I don't know at all if this kind of transformation worse it and
if it is possible to implement it. Moreover, if code has to be duplicated,
code size could increase

Re: New optimisation idea ?

[Andrew Pinski]

On Apr 12, 2005, at 4:38 PM, Christophe Jaillet wrote:
Reading point 3. of "Removal of duplicate effort at
http://gcc.gnu.org/wiki/Speedup%20areas, I got the following idea :
First of all, I don't think that it is actually done by gcc. If I'm 
wrong or
if this idea doesn't worse the effort, just forget about it.
This is PR 10474, http://gcc.gnu.org/PR10474.
It was been on my plat to implement but I have not time to do it yet.
-- Pinski

Re: ada build failure?

[Laurent GUERBY]

Ada does not build on mainline right now, though it dies
much later than what you're seeing, see:

http://gcc.gnu.org/ml/gcc/2005-04/msg00527.html

Laurent

On Tue, 2005-04-12 at 13:11 -0700, Richard Henderson wrote:
> Is anyone else seeing this?  I see the same with either 3.3 or 3.4
> as the build compiler.
> 
> gcc -c -g  -gnatpg -gnata -I- -I. -Iada -I../../src-gcc/gcc/ada \
>   ../../src-gcc/gcc/ada/exp_ch11.adb -o ada/exp_ch11.o
> exp_ch11.adb:926:34: expected type "Char_Code_Base" defined at types.ads:531
> exp_ch11.adb:926:34: found private type "Uint" defined at uintp.ads:50
> 
> 
> r~
> 

Re: GCC 4.0 RC2

[Richard Sandiford]

Mark,

I tried running some MIPS16 tests against RC1 and found a regression
from 3.4.  The problem is the following hack in mips.h:


/* When generating mips16 code we want to put the jump table in the .text
   section.  In all other cases, we want to put the jump table in the .rdata
   section.  Unfortunately, we can't use JUMP_TABLES_IN_TEXT_SECTION, because
   it is not conditional.  Instead, we use ASM_OUTPUT_CASE_LABEL to switch back
   to the .text section if appropriate.  */
#undef ASM_OUTPUT_CASE_LABEL
#define ASM_OUTPUT_CASE_LABEL(FILE, PREFIX, NUM, INSN)  \
do {\
  if (TARGET_MIPS16)\
function_section (current_function_decl);   \
  (*targetm.asm_out.internal_label) (FILE, PREFIX, NUM);\
} while (0)


Obviously it would have been better if the author had changed
JUMP_TABLE_IN_TEXT_SECTION to be a run-time value instead.
And I suppose we should have noticed the hack during the
3.4 MIPS rewrite and cleaned it up then.  Alas, neither happened.

Anyhow, the hack no longer works, and we switch back to .rodata
after emitting the case label:


.rdata
.align  1
.text
$L10:   
.rdata
.half   $L3-$L10
.half   $L4-$L10
.half   $L5-$L10
.half   $L6-$L10
.half   $L7-$L10
.half   $L8-$L10
.half   $L9-$L10


So when using the jump table, we calculate an address using text
label $L10, but the contents of the table are actually in .rodata.
This causes quite a lot of failures in the C testsuite.

Thankfully, someone has since made JUMP_TABLE_IN_TEXT_SECTION a run-time
value, so we _can_ simply define JUMP_TABLE_IN_TEXT_SECTION for MIPS16.

The patch below does this and removes the definition of ASM_OUTPUT_CASE_LABEL.
The macro is used like this in final.c:


#ifdef ASM_OUTPUT_CASE_LABEL
  ASM_OUTPUT_CASE_LABEL (file, "L", CODE_LABEL_NUMBER (insn),
 next);
#else
  targetm.asm_out.internal_label (file, "L", CODE_LABEL_NUMBER 
(insn));
#endif


so the patch should have no effect for non-MIPS16 code.

The patch reduces the number of mips64 {-mips16}{-EL,-EB} C failures
from 203 to 58 with no regressions.  I'm still running normal mips-elf
tests.  If they pass, is this patch OK for RC2?  Or should it wait
until 4.0.1?

Sorry for not having picked up this before.

Richard

PS. mips.c has the following


/* Return the length of instruction INSN.

   ??? MIPS16 switch tables go in .text, but we don't define
   JUMP_TABLES_IN_TEXT_SECTION, so get_attr_length will not
   compute their lengths correctly.  */

static int
mips16_insn_length (rtx insn)


...which can probably go away after this patch.  That's just a
clean-up though.  I'm not suggesting it for 4.0.



* config/mips/mips.h (ASM_OUTPUT_CASE_LABEL): Delete.
(JUMP_TABLES_IN_TEXT_SECTION): Define.

Index: config/mips/mips.h
===
RCS file: /cvs/gcc/gcc/gcc/config/mips/mips.h,v
retrieving revision 1.388
diff -c -p -F^\([(a-zA-Z0-9_]\|#define\) -r1.388 mips.h
*** config/mips/mips.h  7 Apr 2005 18:04:42 -   1.388
--- config/mips/mips.h  12 Apr 2005 20:29:40 -
*** do {
\
*** 2576,2593 
 LOCAL_LABEL_PREFIX, VALUE);\
  } while (0)
  
! /* When generating mips16 code we want to put the jump table in the .text
!section.  In all other cases, we want to put the jump table in the .rdata
!section.  Unfortunately, we can't use JUMP_TABLES_IN_TEXT_SECTION, because
!it is not conditional.  Instead, we use ASM_OUTPUT_CASE_LABEL to switch 
back
!to the .text section if appropriate.  */
! #undef ASM_OUTPUT_CASE_LABEL
! #define ASM_OUTPUT_CASE_LABEL(FILE, PREFIX, NUM, INSN)
\
! do {  \
!   if (TARGET_MIPS16)  \
! function_section (current_function_decl); \
!   (*targetm.asm_out.internal_label) (FILE, PREFIX, NUM);  \
! } while (0)
  
  /* This is how to output an ass

Re: GCC 4.0 RC2

[Per Bothner]

Mark Mitchell wrote:
Sadly, it's become clear there's going to have to be a second release 
candidate.  In particular, there are some wrong-code bugs that are 
popping up on real packages on primary platforms.
I think there is a case for considering the bug discussed in this thread
release-critical:
http://gcc.gnu.org/ml/gcc/2005-04/msg00534.html
Summery: Native-compiled Java code ignores CLASSPATH
This is a recent regression, which prevents building Kawa.
Now there are Kawa work-arounds, but I believe there have been
reports of others seeing what might be the same problem.
Mark Wielard said he's looking into the problem.  Unfortunately,
we haven't heard anything from Tom Tromey, the auther of the big
patch that probably causes the problem.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: GCC 4.0 RC2

[Richard Sandiford]

Richard Sandiford <[EMAIL PROTECTED]> writes:
> PS. mips.c has the following
>
> 
> /* Return the length of instruction INSN.
>
>??? MIPS16 switch tables go in .text, but we don't define
>JUMP_TABLES_IN_TEXT_SECTION, so get_attr_length will not
>compute their lengths correctly.  */
>
> static int
> mips16_insn_length (rtx insn)
> 
>
> ...which can probably go away after this patch.  That's just a
> clean-up though.  I'm not suggesting it for 4.0.

Huh.  For the record: it can't.  get_attr_length() returns 0
for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION.  I'll update
the comment when applying the bug-fix patch to mainline.

But like I say, this is all independent of the RC2 RFA anyway.
Sorry for the noise.

Richard

Re: PowerPC sections ?

[James E Wilson]

Charles J Gillan wrote:
Is the GOT not sufficient to do this though ? I can’t see why 
it is necessary to define two new sections ?  What goes into those 
sections ?
The GOT is sufficient if you have a shared library loader that knows how 
to read ELF files and apply the relocations embedded within.

The -mrelocatable option tries to make this easier for embedded targets 
by emitting code that does the relocations for you, and storing the 
relocation info in regular object file data sections.  See the 
gcc/config/rs6000/eabi.asm file, in particular the __eabi_convert 
function and its callers, which uses the got2 and fixup sections to 
perform relocations when a program is loaded at a different address than 
it was linked for.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: GCC 4.0 RC1 Available

[Bryce McKinlay]

Mark Wielaard wrote:
On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote:
 

Try compiling to native:
$ gcj -o CL CL.java --main=CL
$ CLASSPATH=.:/:/usr:/random ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:./], 
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
   

Aha. Thanks. As a workaround you can use the GCJ_PROPERTIES environment
variable for now:
GCJ_PROPERTIES='java.class.path=../..' ./CL
gnu.gcj.runtime.SystemClassLoader{urls=[file:../../],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
I am looking for a real solution.
 

It looks like this was caused by this patch:
2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>
   PR libgcj/20090, PR libgcj/20526
   * gij.cc (nonstandard_opts_help): New function.
   (add_option): New function.
   (main): Support java options.  Set java.class.path.  Don't set
   _Jv_Jar_Class_Path.
...
Tom is working on a solution.
Regards
Bryce

Re: GCC 4.0 RC1 Available

[Mark Wielaard]

Hi Per,

On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote:
> I am looking for a real solution.

Does the following work for you?

2005-04-02  Mark Wielaard  <[EMAIL PROTECTED]>

* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPATH if not already set.

It is the most minimal, non-intrusive way to fix this issue without
needing to mess with the gij.cc launcher or prims.cc invocation
interface.

Running a clean bootstrap and make check now.

Cheers,

Mark
Index: java/lang/natRuntime.cc
===
RCS file: /cvs/gcc/gcc/libjava/java/lang/natRuntime.cc,v
retrieving revision 1.53
diff -u -r1.53 natRuntime.cc
--- java/lang/natRuntime.cc	2 Apr 2005 02:26:51 -	1.53
+++ java/lang/natRuntime.cc	12 Apr 2005 22:05:23 -
@@ -593,6 +593,18 @@
   // LD_LIBRARY_PATH, etc.
   SET ("java.library.path", "");
 }
+
+  // If java.class.path is still not set then set it according to the
+  // CLASSPATH environment variable if given.  See gij.cc main () and
+  // prims.cc _Jv_CreateJavaVM () for all the ways this could have
+  // been set much earlier.
+  path = newprops->getProperty(JvNewStringLatin1("java.class.path"));
+  if (!path)
+{
+  char *classpath = getenv("CLASSPATH");
+  if (classpath)
+	SET ("java.class.path", classpath);
+}
 }
 
 java::lang::Process *


signature.asc
Description: This is a digitally signed message part

Basic block reordering algorithm

[Pat Haugen]

I stumbled across the following and was interested in others thoughts
before I proceed any further.

The algorithm described in the comments of bb-reorder.c (and the paper
cited) talk about two parameters for controlling which blocks will be added
to traces.  "Branch threshhold" refers to the branch probabilty of the
successor edges for a given block and "Exec threshhold" refers to the
execution frequency of the blocks.  The problem is that the code in
find_traces_1_round() is grabbing the "EDGE_FREQUENCY" of a successor edge
for the frequency instead of the successor block's frequency.  Since edge
frequency is based off the source block's frequency (src blk freq * edge
prob), this means the code in better_edge_p() which compares frequencies if
edge probabilities are equivalent is useless (if probabilities are
equivalent then the edge frequencies will also be equivalent since they're
based off the same block frequency).

I made the obvious change to use the succ blk frequency instead of edge
frequency and noticed one situation which gave undesirable results with the
current code.  When we have a test block gating whether a loop should be
entered, the new block frequency check causes the code to pick the non-loop
path as the next block to add to the trace since the loop header block has
a higher frequency, and hence the loop gets moved out of line.

A thought I had for fixing this was to use dominance information in
better_edge_p() as follows:

  else if (freq < best_freq - diff_freq)
/* The edge and the temporary best edge  have almost equivalent
   probabilities.  The higher frequency of a successor now means
   that there is another edge going into that successor.
   This successor has lower frequency so it is better.  */
// is_better_edge = true;
is_better_edge = ! dominated_by_p (CDI_POST_DOMINATORS, e->dest,
cur_best_edge->dest);
  else if (freq > best_freq + diff_freq)
/* This successor has higher frequency so it is worse.  */
// is_better_edge = false;
is_better_edge = dominated_by_p (CDI_POST_DOMINATORS,
cur_best_edge->dest, e->dest);


This gives the desired effect for both cases, not picking the higher
frequency succ block when that additional frequency is due to some other
predecessor, and leaving loops in line.  An additional benefit of this
approach is that it should render useless the existing special case code in
find_traces_1_round() which looks for triangles in the flow graph to make
sure "then" legs are emitted in line.

Feedback I'm interested in hearing:

1) Flaws in my thinking/approach?
2) Thoughts on cost of computing dominance info for this


Thanks,
Pat

Re: GCC 4.0 RC1 Available

[Thomas Fitzsimmons]

On Tue, 2005-04-12 at 17:51 -0400, Bryce McKinlay wrote:
> Mark Wielaard wrote:
> 
> >On Tue, 2005-04-12 at 11:23 -0700, Per Bothner wrote:
> >  
> >
> >>Try compiling to native:
> >>
> >>$ gcj -o CL CL.java --main=CL
> >>$ CLASSPATH=.:/:/usr:/random ./CL
> >>gnu.gcj.runtime.SystemClassLoader{urls=[file:./], 
> >>parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> >>
> >>
> >
> >Aha. Thanks. As a workaround you can use the GCJ_PROPERTIES environment
> >variable for now:
> >
> >GCJ_PROPERTIES='java.class.path=../..' ./CL
> >gnu.gcj.runtime.SystemClassLoader{urls=[file:../../],
> >parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> >
> >I am looking for a real solution.
> >  
> >
> 
> It looks like this was caused by this patch:
> 
> 2005-04-01  Thomas Fitzsimmons  <[EMAIL PROTECTED]>
> 
> PR libgcj/20090, PR libgcj/20526
> * gij.cc (nonstandard_opts_help): New function.
> (add_option): New function.
> (main): Support java options.  Set java.class.path.  Don't set
> _Jv_Jar_Class_Path.
> ...
> 
> 
> Tom is working on a solution.
> 

Sorry, I missed this thread.  Mark Wielaard beat me to the fix.

Tom

Re: GCC 4.0 RC1 Available

[Per Bothner]

Mark Wielaard wrote:
Hi Per,
On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote:
I am looking for a real solution.

Does the following work for you?
2005-04-02  Mark Wielaard  <[EMAIL PROTECTED]>
* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPATH if not already set.
Yes, Kawa builds with this patch.  Thanks!
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: GCC 4.0 RC1 Available

[Per Bothner]

Per Bothner wrote:
2005-04-02  Mark Wielaard  <[EMAIL PROTECTED]>
* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPATH if not already set.

Yes, Kawa builds with this patch.  Thanks!
However, the Kawa testsuite fails, raising a ClassNotFoundException.
I'm looking into it.
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: RFC:Updated VEC API

[Daniel Berlin]

On Tue, 2005-04-12 at 19:42 +0100, Nathan Sidwell wrote:
> Hi,
> I promised to fix up the vector api, and there's a design decision
> which needs to be made (incidentally, if we were in C++ land, we wouldn't
> have to chose, as the right thing just happens).

> Option1 is more easy to implement. Option2 requires a little nested
> structure jiggery pokery to retain type safety.

I like option 2 from a writer perspective, but i don't know how much of
a pain in the ass it is for you.

> 
> So which has the more annoying downside, or alternatively, the more
> satisfactory upside?
> 

> Another option, is whether the type and allocation parameters of the
> API calls are themselves parenthesized into a single macro argument,
> as in
>   VEC_append ((tree,gc),v,t)
> Would this be a suitable visual aid to make those stand out as
> 'not expressions'? (In C++ land, you'd write it as
> 'VEC_append (v,t)', if you really wanted a template-id-expr.
> Mostly you'd just let template deduction DTRT and have a plain
> 'VEC_append (v,t)'

This is  just the push we need to move to C++.
:)


> )
> 
> comments?
> 
> nathan
> 

Re: HEAD regression: All java tests are failing with an ICE when optimized

[James E Wilson]

Andrew Haley wrote:
Oh, right.  I wonder why this happens only with Java?
Because Java defaults to -fnon-call-exceptions.  Add 
-fno-non-call-exceptions and it will work.  It looks to me like the 
REG_EH_REGION check in postreload-gcse.c is bogus.  We can have these 
notes here with -fnon-call-exceptions, and we will have to do something 
about them.  Perhaps just ignoring insns with a REG_EH_REGION note will 
work, which appears to be what gcse.c does.  I haven't haven't really 
looked at the code to see if this is the proper solution though.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: gcc cache misses [was: Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources]

[Nicholas Nethercote]

On Tue, 12 Apr 2005, Karel Gardas wrote:
cachegrind can also be used to estimate the number (though, not sure
how accurate it is, possibly not very).  I use Shark to actually get
the real number.
Perhaps it's possible that cachegrind is wrong or cache misses differ from
platform to platform, but I would tell that I get very good numbers for
gcc running on x86 platform:
In my experience Cachegrind can give pretty good numbers for L1 misses, 
espcially D1, but the L2 misses tend to vary more.  I saw this with 
comparisons against the real numbers reported by the performance counters 
on an Athlon.  However, Cachegrind certainly makes a number of 
approximations (see section 3.3.7 of 
http://www.valgrind.org/docs/phd2004.pdf) and so you shouldn't trust it 
too much.  It should give reasonable numbers though.

N

Re: gcc cache misses [was: Re: OT: How is memory latency important on AMD64 box while compiling large C/C++ sources]

[Mike Stump]

On Apr 12, 2005, at 12:59 PM, Karel Gardas wrote:
Either cachegrind is wrong, or gcc gets much better from that time?  
Or do
I interpret cachegrind provided data in the wrong way? What do you  
think
about it?
Or you're comparing x86 to power, and noticing that the x86 has to  
execute way more data movement instructions for silly little things,  
and it wins on most of the silly extra instructions?

Only collecting data side by side for the same work load and checking  
out the numbers between the two will probably yield the truth.

If cachegrind works on ppc yellow dog linux  one could compare  
those numbers...

If I run across any arch to arch numbers, I'll post them.

Re: RTL code

[James E Wilson]

Rajkishore Barik wrote:
Can someone tell me if there is a way to generate RTL code which does not
include use and def of the same pseudo in the same insn?
That depends on how you are generating RTL, but it should be pretty 
obvious that you can use gen_reg_rtx to generate a temp reg for use as a 
destination for most operations.

Or maybe your question is how to get everyone else to generate RTL code 
this way?  No, there isn't an easy way to do this.

There are also some reasons why it is impossible to do it everywhere. 
RTL matches hardware instructions, and some targets have instructions 
that require that source and destination operands match.  There are also 
some rtl operations that implicitly use and set the same register, such 
as bitfield inserts.  Some targets have complex operations that may 
require rtl that explicitly sets and uses the same register in order to 
adequately describe.  Etc.  You can't fix all of these cases by 
splitting apart instructions, at least not without losing performance.

There is also the issue of extended asms, which may use and set the same 
register.

In general, gcc does already try to use temporary regs in many places 
when optimizing, because we often get better code that way.  This is 
probably only true in very early rtl optimization passes though.  In 
later ones, the temps will have already been optimized away.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com

Re: GCC 4.0 RC1 Available

[Joseph S. Myers]

On Mon, 11 Apr 2005, Julian Brown wrote:

> Quite a few of the 4.0 RC1 tests FAIL, though I'm not sure how many of
> these are regressions, and how many are just new tests which fail.

And a new test which fails may or may not be a regression - finding out 
whether it is requires either testing the old compiler with the new 
testsuite (e.g. using contrib/test_installed, but that doesn't do 
libstdc++ testing), or running the tests manually with the old compiler.  
(Whether or not it is a regression, it is still worth a bug report in 
Bugzilla, as is any FAIL or XFAIL.)

-- 
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: GCC 4.0 RC1 Available

[Per Bothner]

Per Bothner wrote:
However, the Kawa testsuite fails, raising a ClassNotFoundException.
I'm looking into it.
Hm.  This fails, with or without the patch:
  clas = Class.forName(cname);
This works:
  clas = Class.forName(cname, true, getClass().getClassLoader());
This is with make all && make install in the libjav directory.
I'm doing a 'cvs update' and rebuild from a clean tree in case the
problem is an artifact of the way I just rebuilt part of the tree.
BTW, I've always though we should have the compiler rewrite:
  Class.forName(NAME)
to:
  Class.forName(NAME, true, getClass().getClassLoader())
to avoid the fragility and ugliness and performance lossage
of doing the stack trace ...
--
--Per Bothner
[EMAIL PROTECTED]   http://per.bothner.com/

Re: GCC 4.0 RC2

[Ian Lance Taylor]

Richard Sandiford <[EMAIL PROTECTED]> writes:

> Huh.  For the record: it can't.  get_attr_length() returns 0
> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION.  I'll update
> the comment when applying the bug-fix patch to mainline.

shorten_branches handles JUMP_TABLES_IN_TEXT_SECTION correctly.  You
don't need ADJUST_INSN_LENGTHS unless you need to call get_attr_length
somewhere else.

Ian

Re: GCC 4.0 RC1 Available

[Ian Lance Taylor]

Mark Mitchell <[EMAIL PROTECTED]> writes:

> If you are willing to help, please download the release candidate,
> build it on appropriate platforms, and post testresults by using
> contrib/test_summary.  Please use the release candidate itself, *not*
> the CVS 4.0 release branch, as part of the goal is to ensure that the
> packaging scripts are working.

Not a full test or a full report, but I downloaded RC1 (just gcc-core
and gcc-g++) on an NFS mounted directory, ran "make bootstrap" as
myself, and then ran "make install" as root.  Since the directory is
NFS mounted, root does not have write privileges on the object
directory.  The bootstrap went fine, but the install failed with:

Making install in testsuite
make[2]: Entering directory 
`/home/ian/gcc-4.0.0-20050410-objdir/i686-pc-linux-gnu/libstdc++-v3/testsuite'
touch testsuite_wchar_t
touch: cannot touch `testsuite_wchar_t': Permission denied
make[2]: *** [stamp_wchar] Error 1
make[2]: Leaving directory 
`/home/ian/gcc-4.0.0-20050410-objdir/i686-pc-linux-gnu/libstdc++-v3/testsuite'
make[1]: *** [install-recursive] Error 1
make[1]: Leaving directory 
`/home/ian/gcc-4.0.0-20050410-objdir/i686-pc-linux-gnu/libstdc++-v3'
make: *** [install-target-libstdc++-v3] Error 2

Does anybody else see this?  I imagine this would be fairly annoying
for some people.

Ian

Re: RFC:Updated VEC API

[Mark Mitchell]

Nathan Sidwell wrote:
option1) Require the allocation mechanism to be mentioned in *all* 
vector API
calls.  So you'd have 'VEC_append (tree,gc,v,t)', but you'd also have
'VEC_length (tree,gc,v)', which is kind of annoying.
I think that's more than annoying: it's dangerous.  We'll get it wrong 
on some functions, with unfortunate results.

option2) Split the DEF_VEC operation into DEF_VEC and DEF_VEC_ALLOC parts.
The former would define all the non-allocation sensitive routines, and the
latter defines all the allocation specific ones. So now when defining a 
vector
type you'd have
DEF_VEC(tree); // define the common tree routines
DEF_VEC_ALLOC(tree,gc);  // define the gc tree routines
DEF_VEC_ALLOC(tree,heap);  // define the heap tree routines
I like this one.  To me, that's just a C-ish way of doing inheritance 
from the "VEC" base class.

But you can now say 'VEC_length (tree,v)', without caring whether it's
a gc'd or heap allocated vector.  Unfortunately, now there must be
*exactly* one invocation of DEF_VEC(tree), regardless of where the
DEF_VEC_ALLOC calls are, which is also annoying.
I don't think that's so bad.  Heck, it means we'll have less code.
Another option, is whether the type and allocation parameters of the
API calls are themselves parenthesized into a single macro argument,
as in
VEC_append ((tree,gc),v,t)
I don't think it's necssary to do this bit, but I'm not particularly 
opposed.

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

Re: GCC 4.0 RC1 Available

[Mark Mitchell]

Per Bothner wrote:
Mark Wielaard wrote:
Hi Per,
On Tue, 2005-04-12 at 20:45 +0200, Mark Wielaard wrote:
I am looking for a real solution.

Does the following work for you?
2005-04-02  Mark Wielaard  <[EMAIL PROTECTED]>
* java/lang/natRuntime.cc (insertSystemProperties): Set
java.class.path to CLASSPATH if not already set.

Yes, Kawa builds with this patch.  Thanks!
This is OK for 4.0 if approved for mainline.
--
Mark Mitchell
CodeSourcery, LLC
[EMAIL PROTECTED]
(916) 791-8304

Re: About the number of DOM's iterations.

[Jeffrey A Law]

On Tue, 2005-04-12 at 14:36 -0400, Kazu Hirata wrote:
> Hi,
> 
> Note that with -O1, we limit the number of iterations of DOM to 1 so
> that we can get resonable compile time performance.  I was wondering
> what happens if we do the same with -O2 now that we have passes like
> copy-prop, VRP, and improved FRE as well as good and old CCP.
[ ... ]
Note that the iteration step is has two purposes.  One is to find more
jump threading opportunities.  Two is to find new redundancy elimination
and const/copy propagation opportnities that were exposed by jump
threading.

The latter is more important and more common than the former.  If you're
going to look at limiting the iteration, you really need to look at both
effects.  [ In fact, the latter effect is what got me looking at jump
threading in the first place! ]


I would also strongly suggest you look at my recent message to Diego
which outlines how I think we can eliminate the iteration step in favor
of a worklist approach which just looks at optimization of statements
that may now be redundant due to the effects of jump threading.

Jeff

Re: GCC 4.0 RC1 Available

[Ranjit Mathew]

> Exception in thread "main" java.lang.RuntimeException: test failed:5
> <>
> FAIL: Array_3 -O3 execution - bytecode->native test

This one is expected I think, though not XFAILed (it
fails only at -O3).

BTW, you keep getting "<>"
everywhere - is addr2line from binutils not present
somewhere in your default executable search path?

Beyond this, the other FAILs seem to be the
result of the Java interpreter (gij) getting confused
about loading classes.

You might try:

http://gcc.gnu.org/ml/java/2005-04/msg00075.html

but it might or might not help. Sorry for being
this vague, but without access to a Darwin
machine and any knowledge about that system,
I can't shed much light on these FAILs.

Ranjit.

PS: As Andrew Pinski remarked, I wonder why
you don't see these on mainline? Perhaps Tom
missed a hunk or two while backporting his
patch?

-- 
Ranjit Mathew  Email: rmathew AT gmail DOT com

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

Re: Patches for coldfire v4e

[Bernardo Innocenti]

[EMAIL PROTECTED] wrote:
> Hi,
>  Sorry, I missed ChangeLog patches.

There seems to be a bogus hunk in this patch.

The long lines need to be wrapped to 80 characters.
Also, one line is indented with spaces instead of
TABs.

-- 
  // Bernardo Innocenti - Develer S.r.l., R&D dept.
\X/  http://www.develer.com/

Re: GCC 4.0 RC2

[Richard Sandiford]

Ian Lance Taylor  writes:
> Richard Sandiford <[EMAIL PROTECTED]> writes:
>> Huh.  For the record: it can't.  get_attr_length() returns 0
>> for ADDR_VECs regardless of JUMP_IN_TEXT_SECTION.  I'll update
>> the comment when applying the bug-fix patch to mainline.
>
> shorten_branches handles JUMP_TABLES_IN_TEXT_SECTION correctly.  You
> don't need ADJUST_INSN_LENGTHS unless you need to call get_attr_length
> somewhere else.

The code I mentioned isn't related to ADJUST_INSN_LENGTHS.
It's a subroutine of the mips16 constant layout code.

As far as shorten_branches() goes: I realise that it handles text jump
tables correctly, but the mips16 layout code runs in reorg, before
shorten_branches() has been called.

I suppose we could call shorten_branches() from the mips16 layout
code, but I don't like the idea of relying on the cached results of
shorten_branches() in a pass that is specifically supposed to
_increase_ the distance between things.

Richard