Problem compiling GCC source code in AIX

[Kithsiri Lekamge]

Hi All,
I am in great difficult compiling GCC source code in AIX box.

I installed the binary of GCC 3.3.2 and using this compiler I started
to compile the GCC 3.4.6 source codes.

After 5 hrs of compiling  I received the following error.

46286 Segmentation fault:
Configure-target-libstdc++-v3

My AIX version is 5.1 and OS level is 5100-08 so I tried to install
the patches and noticed that all the patches are available in this OS
level.

So guys I am clueless and helpless, please help me to come up from
this problem.
I couldn't trace the core dump as I don't know is there any tool like
pstack is available in AIX.
--Kithsiri

[boehms-gc] Performance results

[Laurynas Biveinis]

Hi,

(This email is quite long; if you are not interested in performance
data, scroll down for my questions that you might be able to answer)

Below are some performance results with --with-gc=boehm. This
collector since the last posted results at
http://gcc.gnu.org/ml/gcc/2006-06/msg00729.html, has following further
changes:
http://gcc.gnu.org/ml/gcc/2006-07/msg00194.html
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00678.html
http://www.cs.aau.dk/~lauras/gcc-patch.txt

Additionally compilers [2] and [3], [5] and [6] differ in that [3] and [6] have
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00695.html

[A]: Peak GC mem usage
[B]: garbage collection, absolute usr time
[C]: garbage collection, % of usr time
[D]: user time
[E]: sys time
[F]: user bootstrap time
[G]: sys bootstrap time

All tested compilers are based on
gcc version 4.2.0 20060615 (experimental)

[1]: Cygwin baseline, ggc-page

Target: i686-pc-cygwin
Thread model: single

[2]: Cygwin ggc-boehm, with cache support, no "deletable" support

Target: i686-pc-cygwin
Thread model: single

[3]: Cygwin ggc-boehm, with cache support, with "deletable" support

Target: i686-pc-cygwin
Thread model: single

[4]: Linux baseline

Target: i686-pc-linux-gnu
Thread model: posix

[5]: Linux boehm (+cache, no "deletable" support)

Target: i686-pc-linux-gnu
Thread model: posix

[6]: Linux boehm (+cache, deletable)

Target: i686-pc-linux-gnu
Thread model: posix

---

Bootstrap:

4F: 33m51.280s 4G: 4m23.677s
5F: 35m12.730s 5G: 4m31.270s
6F: 35m14.948s 6G: 4m29.909s

reload.c:

1A: 10636K   1B: 0.50   1C: 6%   1D: 0m8.591s   1E: 0m0.405s
2A: 15908K   2B: 0.31   2C: 4%   2D: 0m8.309s   2E: 0m0.560s
3A: 16036K   3B: 0.90   3C: 4%   3D: 0m25.576s  3E: 0m1.389s

4D: 0m4.835s 4E: 0m0.581s
5D: 0m5.036s 5E: 0m0.633s
6D: 0m5.044s 6E: 0m0.599s

combine.c:

1A: 13921K   1B: 0.71   1C: 5%   1D: 0m13.559s  1E: 0m0.748s
2A: 21716K   2B: 0.50   2C: 4%   2D: 0m13.653s  2E: 0m0.591s
3A: 21716K   3B: 1.42   3C: 4%   3D: 0m39.310s  3E: 0m1.872s

4D: 0m7.498s4E: 0m0.832s
5D: 0m7.782s5E: 0m0.884s
6D: 0m7.778s6E: 0m0.848s

PR/8361 (C++, -g -O3)

1A: 67071K   1B: 5.95   1C: 9%   1D: 1m9.496s   1E: 0m2.122s
2A: 141988K  2B: 3.21   2C: 4%   2D: 1m22.169s  2E: 0m2.809s
3A: 131936K  3B: 8.64   3C: 4%   3D: 3m23.059s  3E: 0m6.138s

4D: 0m41.204s   4E: 0m3.167s
5: ICE
6: ICE

PR/19614 (C++, -g -O3)

1A: 139521K   1B: 4.42   1C: 17%   1D: 0m26.686s   1E: 0m0.873s
2A: 170848K   2B: 5.95   2C: 17%   2D: 0m35.108s   2E: 0m1.108s
3A: 170752K   3B: 10.75  3C: 15%   3D: 1m13.342s   3E: 0m1.920s

4D: 0m18.354s   4E: 0m0.400s
5D: 0m20.522s   5E: 0m0.472s
6D: 0m20.515s   6E: 0m0.456s


I hope you made sense of my A..G, 1..6 notation. Cygwin and Linux
numbers cannot be directly compared. Linux compilers were configured
with --disable-checking, Cygwin ones had default development checking
enabled. Now about the results:

1) The basic patch here for cache support with weak pointers is a big
improvement, shaving a 100M or so from C++ GC peak usage (compare with
http://gcc.gnu.org/ml/gcc/2006-06/msg00729.html)

2) The "deletable" support patch
http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00695.html gives me a lot
of headache. Mem usage: for C++ it reduces peak GC memory usage, in
some other cases it does not affect it, but I don't see how setting
things to NULL can actually increase peak GC memory usage? Its running
time is another headache on Cygwin, but fits my expectations on Linux.
I will try compilers on Linux without --disable-checking, in hope to
confirm that checking is the reason for such a long running time on
Cygwin.

3) OTOH, I don't fully get "deletable" GTY flag. Can anyone explain if
things marked with it must be cleared to NULL or is it OK to leave the
old value if the object pointed by it did not get collected?

4) I have configured Linux compilers with "--disable-checking". I was
quite surprised to see that GGC times have disappeared from the "-Q
-ftime-report -fmem-report" output. Is this expected by design
behaviour? What minimum configure options will cause GGC time to
reappear?

5) While peak GC memory usage is well decreased currently, still it
has a long way to go. I want to check if that's because of ordinary
data misintrepreted as pointers. Can anyone suggest what are the
biggest atomic data structures in GCC? I could check sources
file-by-file and replace calls to GC_malloc() to atomic version where
appropriate, but if anybody knows the what atomic data structures are
the biggest ones, it would save me a lot of time.

6) Are there any data objects in GCC, that the only pointers pointing
to them point to their interiors and not the beginning? If I could
disable Boehm's interior pointer support, that should boost
performance in all respects.

7) There are two ICEs, I'm looking into them.

--
Laurynas

Re: [boehms-gc] Performance results

[Andrew Pinski]

On Jul 24, 2006, at 1:45 AM, Laurynas Biveinis wrote:


4) I have configured Linux compilers with "--disable-checking". I was
quite surprised to see that GGC times have disappeared from the "-Q
-ftime-report -fmem-report" output. Is this expected by design
behaviour? What minimum configure options will cause GGC time to
reappear?


Yes that is expected, because the default gc params with checking on
are all the same across all targets and independent of the amount of
memory in your machine.  Now with checking turned off, you get the GC
params based on your machine, how much memory is in it.

-- Pinski

Re: [boehms-gc] Performance results

[Laurynas Biveinis]

> 4) I have configured Linux compilers with "--disable-checking". I was
> quite surprised to see that GGC times have disappeared from the "-Q
> -ftime-report -fmem-report" output. Is this expected by design
> behaviour? What minimum configure options will cause GGC time to
> reappear?

Yes that is expected, because the default gc params with checking on
are all the same across all targets and independent of the amount of
memory in your machine.  Now with checking turned off, you get the GC
params based on your machine, how much memory is in it.


So does that mean that there is no way to get GGC debug output with
--disable-checking? Is there any very cheap --enable-checking option
that would be give that or am I better off to hack GCC to do it with
--disable-checking?

--
Laurynas

Re: [boehms-gc] Performance results

[Andrew Pinski]

On Jul 24, 2006, at 4:22 AM, Laurynas Biveinis wrote:



So does that mean that there is no way to get GGC debug output with
--disable-checking? Is there any very cheap --enable-checking option
that would be give that or am I better off to hack GCC to do it with
--disable-checking?


No, GC is just not running as you have too much memory to cause it to
run with --disable-checking :).

-- Pinski

Re: [boehms-gc] Performance results

[Laurynas Biveinis]

2006/7/24, Andrew Pinski <[EMAIL PROTECTED]>:

No, GC is just not running as you have too much memory to cause it to
run with --disable-checking :).


Oh! Now my performance results have totally different interpretation
under Linux...

--
Laurynas

Re: MIPS RDHWR instruction reordering

[Atsushi Nemoto]

On 22 Jul 2006 20:58:16 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> OK, patch is approved, with a ChangeLog entry, and assuming it passes
> the testsuite.

Thanks, here is a patch with a ChangeLog entry.

I can cross-build gcc and glibc successfully, but unfortunately I can
not build and run the testsuite natively (in reasonable time) due to
limited CPU/memory resources on my target platform.  Is there good way
to run testsuite on cross environment?


2006-07-24  Atsushi Nemoto  <[EMAIL PROTECTED]>

partial PR target/28126
* config/mips/mips.md (tls_get_tp_): Set can_delay to no.

Index: gcc/config/mips/mips.md
===
--- gcc/config/mips/mips.md (revision 115370)
+++ gcc/config/mips/mips.md (working copy)
@@ -5450,6 +5450,9 @@
 ; MIPS 32r2 specification, but we use it on any architecture because
 ; we expect it to be emulated.  Use .set to force the assembler to
 ; accept it.
+; Since rdhwr always generate a trap for now, it should not be be put
+; on delay slot.  It it was on delay slot, the emulation will be
+; slower.
 
 (define_insn "tls_get_tp_"
   [(set (match_operand:P 0 "register_operand" "=v")
@@ -5458,6 +5461,7 @@
   "HAVE_AS_TLS && !TARGET_MIPS16"
   ".set\tpush\;.set\tmips32r2\t\;rdhwr\t%0,$29\;.set\tpop"
   [(set_attr "type" "unknown")
+   (set_attr "can_delay" "no")
(set_attr "mode" "")])
 
 ; The MIPS Paired-Single Floating Point and MIPS-3D Instructions.

Re: Problem compiling GCC source code in AIX

[David Edelsohn]

> Kithsiri Lekamge writes:

Kithsiri> I am in great difficult compiling GCC source code in AIX box.

Kithsiri> I installed the binary of GCC 3.3.2 and using this compiler I started
Kithsiri> to compile the GCC 3.4.6 source codes.

Kithsiri> After 5 hrs of compiling  I received the following error.

Kithsiri> 46286 Segmentation fault:
Kithsiri> Configure-target-libstdc++-v3

First, you probably should build and install a more recent version
of GCC than 3.4.6.

Second, please make sure that you are following the AIX
machine-specific directions for building GCC, such as using GNU Make and
using Bash as the SHELL and CONFIG_SHELL (unless you are on a very old,
slow machine, it should not take 5 hours unless you used the wrong shell.)

Third, the detailed output from the libstdc++-v3 configuration
process is in a file named config.log in the libstdc++-v3 build
directory. 

David

Re: MIPS RDHWR instruction reordering

[Andreas Schwab]

Atsushi Nemoto <[EMAIL PROTECTED]> writes:

> Index: gcc/config/mips/mips.md
> ===
> --- gcc/config/mips/mips.md   (revision 115370)
> +++ gcc/config/mips/mips.md   (working copy)
> @@ -5450,6 +5450,9 @@
>  ; MIPS 32r2 specification, but we use it on any architecture because
>  ; we expect it to be emulated.  Use .set to force the assembler to
>  ; accept it.
> +; Since rdhwr always generate a trap for now, it should not be be put

s/generate/&s/

> +; on delay slot.  It it was on delay slot, the emulation will be

"on a" (or "in a"?), s/It/If/

Andreas.

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

cross gcc - working gcc, but cannot compile C++

[Danny Backx]

Hi,

I'm trying to build a cross-development system and I'm 99% successful.
My host is a standard Linux PC, target is a PDA (arm-wince-pe).

Versions of all tools are below.

I can build a cross-gcc as long as I tell it to support only C. When
trying to get C++ compiled as well, I always end up getting the error
message below.

I've tried patching gas because I had the feeling that gcc is producing
an option that gas doesn't support any more, but somehow I couldn't get
that to work.

Is this a gcc bug ?

Danny


gmake \
  CFLAGS="-g -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute -fno-common " \
  CONFIG_H="config.h
auto-host.h 
/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../include/ansidecl.h"
 \
  MAKEOVERRIDES= \
  -f libgcc.mk all
gmake[1]: Entering directory
`/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/build/i686-pc-linux-gnu/arm-wince-pe/gcc/gcc'
gmake[1]: Nothing to be done for `all'.
gmake[1]: Leaving directory
`/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/build/i686-pc-linux-gnu/arm-wince-pe/gcc/gcc'
echo timestamp > stmp-multilib
(SHLIB_LINK='' \
SHLIB_MULTILIB=''; \
/tmp/gcc-4/bin/gcc -c   -g -DIN_GCC -DCROSS_COMPILE  -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wold-style-definition
-Wmissing-format-attribute -fno-common   -DHAVE_CONFIG_H -I. -I.
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc 
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/. 
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../include
 
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../libcpp/include
 -DSTANDARD_STARTFILE_PREFIX=\"../../../\" 
-DSTANDARD_EXEC_PREFIX=\"/usr/ppc/lib/gcc/\" 
-DSTANDARD_LIBEXEC_PREFIX=\"/usr/ppc/libexec/gcc/\" 
-DDEFAULT_TARGET_VERSION=\"4.1.0\" -DDEFAULT_TARGET_MACHINE=\"arm-wince-pe\" 
-DSTANDARD_BINDIR_PREFIX=\"/usr/ppc/bin/\" 
-DTOOLDIR_BASE_PREFIX=\"../../../../\"  `test "X${SHLIB_LINK}" = "X" || test 
"yes" != "yes" || echo "-DENABLE_SHARED_LIBGCC"` `test "X${SHLIB_MULTILIB}" = 
"X" || echo "-DNO_SHARED_LIBGCC_MULTILIB"` \
-I. -I.
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc 
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/. 
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../include
 
-I/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/../libcpp/include
  
/home/danny/src/cegcc/svn.berlios.de/cegcc/branches/linux-build/src/gcc/gcc/cp/g++spec.c)
/usr/ppc/bin/arm-wince-pe-as: unrecognized option `-Qy'
gmake: *** [g++spec.o] Error 1




Versions :
- gcc 4.1.0 from 
ftp://ftp.gnu.org/pub/gnu/gcc/gcc-4.1.0
gcc-core-4.1.0.tar.bz2
gcc-g++-4.1.0.tar.bz2

- newlib 1.14.0
ftp://sources.redhat.com/pub/newlib/index.html
ftp://sources.redhat.com/pub/newlib/newlib-1.14.0.tar.gz

- gdb 6.4
ftp://ftp.gnu.org/pub/gnu/gdb/gdb-6.4.tar.bz2

- binutils from cvs, 16 May 2006
We are using this version because there is no recent released
version of
binutils that works for arm-wince-pe target.
cvs -d :pserver:[EMAIL PROTECTED]:/cvs/src ...

- w32api 3.7

http://prdownloads.sourceforge.net/mingw/w32api-3.7-src.tar.gz?download

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


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

Re: MIPS RDHWR instruction reordering

[Richard Sandiford]

Thanks for tackling this.

Atsushi Nemoto <[EMAIL PROTECTED]> writes:
> On 22 Jul 2006 20:58:16 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> OK, patch is approved, with a ChangeLog entry, and assuming it passes
>> the testsuite.
>
> Thanks, here is a patch with a ChangeLog entry.
>
> I can cross-build gcc and glibc successfully, but unfortunately I can
> not build and run the testsuite natively (in reasonable time) due to
> limited CPU/memory resources on my target platform.  Is there good way
> to run testsuite on cross environment?

You can set up DejaGNU's unix.exp to use rsh and rcp.  It's usually
a case of creating a board file "foo.exp" like this:

load_generic_config "unix"
process_multilib_options ""
set_board_info hostname ""

You can use ssh and scp instead by adding:

set_board_info rsh_prog ssh
set_board_info rcp_prog rcp

and then running with "make -k check RUNTESTFLAGS='--target_board foo'".

FWIW, I can run a gcc test run for you on mips64-linux-gnu (and perhaps
glibc too, depending on the time).  I should have the results by the weekend.

> +; Since rdhwr always generate a trap for now, it should not be be put
> +; on delay slot.  It it was on delay slot, the emulation will be
> +; slower.

Andreas has already commented on this, but the tense sounds wrong too.
Maybe it would be better to have something like:

; Putting rdhwr in a delay slot would make the kernel's emulation
; of it much slower.

right above the "can_delay" line.  Whatever you feel is best though.

Richard

RE: cross gcc - working gcc, but cannot compile C++

[Dave Korn]

On 24 July 2006 18:31, Danny Backx wrote:


> I can build a cross-gcc as long as I tell it to support only C. When
> trying to get C++ compiled as well, I always end up getting the error
> message below.
> 
> I've tried patching gas because I had the feeling that gcc is producing
> an option that gas doesn't support any more, but somehow I couldn't get
> that to work.
> 
> Is this a gcc bug ?

  Looks like a problem with specs file generation, conceivably some kind of
old SysV option.  Might be informative to run "./xgcc -dumpspecs" in the build
directory.

> /usr/ppc/bin/arm-wince-pe-as: unrecognized option `-Qy'
> gmake: *** [g++spec.o] Error 1

  Whatever it is, it's been seen before  lots!

http://www.google.co.uk/search?q=unrecognized+option+Qy&btnG=Search&hl=en&clie
nt=firefox-a&rls=org.mozilla%3Aen-GB%3Aofficial

  Is it conceivable that you have another version of cross-binutils in your
path, ahead of the arm-wince-pe binutils, and aimed at a different target?
What exact configure options did you use when you configured gcc and binutils?


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

Documentation for loop infrastructure

[Zdenek Dvorak]

Hello,

this patch adds documentation for loop analysis and representation of
loops, as well as other loop-related analyses, and for functions to
manipulate loops.  As I am not a native English speaker, there are
probably many language errors in the document, so I would appreciate
if someone could read it and fix them.

Also, the sections regarding data dependence analysis and lambda
framework are missing.  Sebastian, Daniel, do you have time to write
them?  If not, I can write something, but since they are your code,
you probably have better understanding of them than I do.

Zdenek

Index: doc/loop.texi
===
*** doc/loop.texi   (revision 0)
--- doc/loop.texi   (revision 0)
***
*** 0 
--- 1,423 
+ @c Copyright (c) 2006 Free Software Foundation, Inc.
+ @c Free Software Foundation, Inc.
+ @c This is part of the GCC manual.
+ @c For copying conditions, see the file gcc.texi.
+ 
+ @c -
+ @c Loop Representation
+ @c -
+ 
+ @node Loop Representation
+ @chapter Analysis and Representation of Loops
+ 
+ GCC provides extensive infrastructure for work with natural loops,
+ i.e., strongly connected components of CFG with only one entry block.
+ This chapter describes representation of loops in GCC, both on trees
+ and in RTL, as well as the interfaces to loop-related analyses
+ (induction variable analysis and number of iterations analysis).
+ 
+ @menu
+ * Loop representation::   Representation and analysis of loops.
+ * Loop querying:: Getting information about loops.
+ * Loop manipulation:: Loop manipulation functions.
+ * LCSSA:: Loop-closed SSA form.
+ * Scalar evolutions:: Induction variables on trees.
+ * loop-iv::   Induction variables on RTL.
+ * Number of iterations::  Number of iterations analysis.
+ * Dependency analysis::   Data dependency analysis.
+ * Lambda::Linear loop transformations framework.
+ @end menu
+ 
+ @node Loop representation
+ @section Loop representation
+ @cindex Loop representation
+ @cindex Loop analysis
+ 
+ This chapter describes the representation of loops in GCC, and functions
+ that can be used to analyze them and construct and update this representation.
+ Most of the interfaces and data structures are declared in @file{cfgloop.h}.
+ At the moment, loop structures are analyzed and this information is updated
+ only by the optimization passes that deal with loops, but some efforts are
+ being made to make it available throughout most of the optimization passes.
+ 
+ In general form, the natural loop has one entry block (header) and possibly
+ several back edges (latches) leading to the header from the inside of the 
loop.
+ Loops with several latches may appear if several loops share a single header,
+ or if there is a branching in the middle of the loop.  The representation of
+ loops in GCC however allows only loops with a single latch.  During the loop
+ analysis, headers of such loops are split and forwarder blocks are created in
+ order to disambiguate their structures.  A heuristic based on profile
+ information is used to determine whether the latches correspond to sub-loops 
or
+ to control flow in a single loop.  This in particular means that the analysis
+ sometimes changes the CFG, and if you run it in the middle of an optimization
+ pass, you must be able to deal with the new blocks.
+ 
+ Natural loops form a tree defined by the subset relation, i.e., sons of a loop
+ are its immediate sub-loops.  This tree is represented by the @code{struct
+ loops} structure. The root of this tree is a fake loop that contains all 
blocks
+ in the function.  Each of the loops is represented in a @code{struct loop}
+ structure.  Each loop is assigned an index (@code{num} field of the
+ @code{struct loop} structure), and the pointer to the loop is stored in the
+ corresponding field of the @code{parray} field of the loops structure.  Index
+ of a sub-loop is always greater than the index of its super-loop.  The 
indices do
+ not have to be continuous, there may be empty (@code{NULL}) entries in the
+ @code{parray} created by deleting loops.  The index of a loop never changes.
+ The first unused index is stored in the @code{num} field of the loops
+ structure.
+ 
+ Each basic block contains the reference to the innermost loop it belongs to
+ (@code{loop_father}).  For this reason, it is only possible to have one
+ @code{struct loops} structure initialized at the same time for each CFG.  It 
is
+ recommended to use the global variable @code{current_loops} to contain the
+ @code{struct loops} structure, especially if the loop structures are updated
+ throughout several passes.  Many of the loop manipulation functions assume 
that
+ dominance information is

RE: cross gcc - working gcc, but cannot compile C++

[Danny Backx]

I've run ./xgcc -dumpspecs but I don't know what to look at. That one
doesn't contain the string "Qy". However, when I do the same with my
native gcc (the one I got from Mandriva), it does contain that :

*asm:
%{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}

You might have noted that the failing command (see my previous mail)
runs /tmp/gcc-4/bin/gcc (it basically ran "gcc" before, the /tmp path is
an attempt to see whether getting rid of my Mandriva compiler helped).
So it runs a normal gcc, but that ends up calling arm-wince-pe-as, which
is not something I would expect to happen.

Do I have another cross-binutils in my path ? No, I've taken great care
to remove all of it at the beginning of my build script. For your
reference, I'm including part of my build script as attachment, they
should give you an idea of (1) the order in which I am building things,
look at build.sh, (2) the exact parameters, look at settings.sh and
build-gcc.sh .

Thanks,

Danny

On Mon, 2006-07-24 at 19:33 +0100, Dave Korn wrote:
> On 24 July 2006 18:31, Danny Backx wrote:
> 
> 
> > I can build a cross-gcc as long as I tell it to support only C. When
> > trying to get C++ compiled as well, I always end up getting the error
> > message below.
> > 
> > I've tried patching gas because I had the feeling that gcc is producing
> > an option that gas doesn't support any more, but somehow I couldn't get
> > that to work.
> > 
> > Is this a gcc bug ?
> 
>   Looks like a problem with specs file generation, conceivably some kind of
> old SysV option.  Might be informative to run "./xgcc -dumpspecs" in the build
> directory.
> 
> > /usr/ppc/bin/arm-wince-pe-as: unrecognized option `-Qy'
> > gmake: *** [g++spec.o] Error 1
> 
>   Whatever it is, it's been seen before  lots!
> 
> http://www.google.co.uk/search?q=unrecognized+option+Qy&btnG=Search&hl=en&clie
> nt=firefox-a&rls=org.mozilla%3Aen-GB%3Aofficial
> 
>   Is it conceivable that you have another version of cross-binutils in your
> path, ahead of the arm-wince-pe binutils, and aimed at a different target?
> What exact configure options did you use when you configured gcc and binutils?
> 
> 
> cheers,
>   DaveK
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


build.sh
Description: application/shellscript


build-gcc.sh
Description: application/shellscript


settings.sh
Description: application/shellscript


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

RE: cross gcc - working gcc, but cannot compile C++

[Danny Backx]

Dave,

I'd used some search engines for the -Qy error but never really found
the solution. Your reply prompted me to do that yet again, and I found 

http://www.cygwin.com/ml/cygwin/1997-06/msg00457.html

which basically says

  configure creates a softlink in gcc object directory to the new
version of the cross assembler. Problem is that the native compiler
get confused and use the cross assembler instead of the native one.

So I looked inside the build/gcc/gcc directory and found a file
called "as" with the contents

#!/bin/sh
exec /usr/ppc/bin/arm-wince-pe-as "$@"

Renaming that file made the build progress beyond my initial problem.

I think this is a bug in gcc/g++. Right ?

Danny

On Mon, 2006-07-24 at 21:05 +0200, Danny Backx wrote:
> I've run ./xgcc -dumpspecs but I don't know what to look at. That one
> doesn't contain the string "Qy". However, when I do the same with my
> native gcc (the one I got from Mandriva), it does contain that :
> 
> *asm:
> %{v:-V} %{Qy:} %{!Qn:-Qy} %{n} %{T} %{Ym,*} %{Yd,*} %{Wa,*:%*}
> 
> You might have noted that the failing command (see my previous mail)
> runs /tmp/gcc-4/bin/gcc (it basically ran "gcc" before, the /tmp path is
> an attempt to see whether getting rid of my Mandriva compiler helped).
> So it runs a normal gcc, but that ends up calling arm-wince-pe-as, which
> is not something I would expect to happen.
> 
> Do I have another cross-binutils in my path ? No, I've taken great care
> to remove all of it at the beginning of my build script. For your
> reference, I'm including part of my build script as attachment, they
> should give you an idea of (1) the order in which I am building things,
> look at build.sh, (2) the exact parameters, look at settings.sh and
> build-gcc.sh .
> 
> Thanks,
> 
>   Danny
> 
> On Mon, 2006-07-24 at 19:33 +0100, Dave Korn wrote:
> > On 24 July 2006 18:31, Danny Backx wrote:
> > 
> > 
> > > I can build a cross-gcc as long as I tell it to support only C. When
> > > trying to get C++ compiled as well, I always end up getting the error
> > > message below.
> > > 
> > > I've tried patching gas because I had the feeling that gcc is producing
> > > an option that gas doesn't support any more, but somehow I couldn't get
> > > that to work.
> > > 
> > > Is this a gcc bug ?
> > 
> >   Looks like a problem with specs file generation, conceivably some kind of
> > old SysV option.  Might be informative to run "./xgcc -dumpspecs" in the 
> > build
> > directory.
> > 
> > > /usr/ppc/bin/arm-wince-pe-as: unrecognized option `-Qy'
> > > gmake: *** [g++spec.o] Error 1
> > 
> >   Whatever it is, it's been seen before  lots!
> > 
> > http://www.google.co.uk/search?q=unrecognized+option+Qy&btnG=Search&hl=en&clie
> > nt=firefox-a&rls=org.mozilla%3Aen-GB%3Aofficial
> > 
> >   Is it conceivable that you have another version of cross-binutils in your
> > path, ahead of the arm-wince-pe binutils, and aimed at a different target?
> > What exact configure options did you use when you configured gcc and 
> > binutils?
> > 
> > 
> > cheers,
> >   DaveK
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


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

why the difference of two global pointers is not a constant?

[Rafael Espíndola]

I am trying to build a table with offsets of global pointers from a
given pointer:

void *fs[] = {f1 - f1, f2 - f1};

where f1 and f2 are functions.

GCC is able to figure out that (f1 - f1) is 0, but says "initializer
element is not constant" when trying to compute (f2 - f1).

It is possible to solve the problem by declaring fs with an inline asm:

asm("fs:\n"
   ".quad   f1 - f1\n"
   ".quad   f2 - f1\n");

Is there a way to do it with C? It works in visual studio.

Sorry if this isn't the appropriate mailing list, but it looks like
this is an intentional design decision.

Thanks,
Rafael

Use of compound_literal_expr in c vs target_expr in c++ for compound literals

[Fariborz Jahanian]

gcc generates two separate trees for compound literals in c and c++.  
As in this test case:


struct S {
int i,j;
};
void foo (struct S);

int main ()
{
foo((struct S){1,1});
}


In c it generates compound_literal_expr and in c++ it generates  
target_expr. But gimplifier treats them differently in the following  
areas:


1) in routine mostly_copy_tree_v we don;t copy target_expr but we do  
copy compound_literal_expr. I see the following comment there:


/ * Similar to copy_tree_r() but do not copy SAVE_EXPR or  
TARGET_EXPR nodes.

   These nodes model computations that should only be done once.  If we
   were to unshare something like SAVE_EXPR(i++), the gimplification
   process would create wrong code.  */

Shouldn't compound_literal_expr be treated same as target_expr here?

2) gimplify_target_expr can be called more than once on the same  
target_expr node because first time around its TARGET_EXPR_INITIAL is  
set to NULL.
This works as a guard and prevents its temporary to be added to  
the temporary list more than once (when call is made to  
gimple_add_tmp_var).


On the other hand, such a guard does not exist for a  
compound_literal_expr and when gimple_add_tmp_var is called, it  
asserts. So, I added check for
!DECL_SEEN_IN_BIND_EXPR_P (decl) in  
gimplify_compound_literal_expr before call to gimple_add_tmp_var is  
made. As in the following diff:


% svn diff c-gimplify.c
Index: c-gimplify.c
===
--- c-gimplify.c(revision 116462)
+++ c-gimplify.c(working copy)
@@ -538,7 +538,7 @@
   /* This decl isn't mentioned in the enclosing block, so add it to  
the

  list of temps.  FIXME it seems a bit of a kludge to say that
  anonymous artificial vars aren't pushed, but everything else  
is.  */

-  if (DECL_NAME (decl) == NULL_TREE)
+  if (DECL_NAME (decl) == NULL_TREE && !DECL_SEEN_IN_BIND_EXPR_P  
(decl))

 gimple_add_tmp_var (decl);

This fixes the problem I am encountering. Is this a right approach in  
situations when compound_literal_expr is used to represent a compound  
literal in c and the expression is referenced in multiple places (by  
hanging off a save_expr call_expr tree)?


- Thanks, Fariborz ([EMAIL PROTECTED])

Re: Use of compound_literal_expr in c vs target_expr in c++ for compound literals

[Andrew Pinski]

> 
> 
> gcc generates two separate trees for compound literals in c and c++.  
> As in this test case:
> 
> struct S {
>  int i,j;
> };
> void foo (struct S);
> 
> int main ()
> {
>  foo((struct S){1,1});
> }

>  On the other hand, such a guard does not exist for a  
> compound_literal_expr and when gimple_add_tmp_var is called, it  
> asserts. So, I added check for
>  !DECL_SEEN_IN_BIND_EXPR_P (decl) in  
> gimplify_compound_literal_expr before call to gimple_add_tmp_var is  
> made. As in the following diff:

I think you are trying to fix PR 28418 which is an ICE in gimple_add_tmp_var 
with
compound literals in C.

Thanks,
Andrew Pinski

Re: Use of compound_literal_expr in c vs target_expr in c++ for compound literals

[Fariborz Jahanian]

On Jul 24, 2006, at 3:07 PM, Andrew Pinski wrote:




gcc generates two separate trees for compound literals in c and c++.
As in this test case:

struct S {
 int i,j;
};
void foo (struct S);

int main ()
{
 foo((struct S){1,1});
}



 On the other hand, such a guard does not exist for a
compound_literal_expr and when gimple_add_tmp_var is called, it
asserts. So, I added check for
 !DECL_SEEN_IN_BIND_EXPR_P (decl) in
gimplify_compound_literal_expr before call to gimple_add_tmp_var is
made. As in the following diff:


I think you are trying to fix PR 28418 which is an ICE in  
gimple_add_tmp_var with

compound literals in C.


Yes, looks like is similar to my problem.

- Thanks, Fariborz



Thanks,
Andrew Pinski

Re: Use of compound_literal_expr in c vs target_expr in c++ for compound literals

[Fariborz Jahanian]

On Jul 24, 2006, at 3:07 PM, Andrew Pinski wrote:




gcc generates two separate trees for compound literals in c and c++.
As in this test case:

struct S {
 int i,j;
};
void foo (struct S);

int main ()
{
 foo((struct S){1,1});
}



 On the other hand, such a guard does not exist for a
compound_literal_expr and when gimple_add_tmp_var is called, it
asserts. So, I added check for
 !DECL_SEEN_IN_BIND_EXPR_P (decl) in
gimplify_compound_literal_expr before call to gimple_add_tmp_var is
made. As in the following diff:


I think you are trying to fix PR 28418 which is an ICE in  
gimple_add_tmp_var with

compound literals in C.


My patch fixes the test case in PR 28418 as well. There are really  
two issues here:
Should we gimplify compound_literal_expr twice? Regardless of this  
issue, how do we avoid calling gimple_add_tmp_var on the same  
variable. My patch addresses the latter.


- Fariborz



Thanks,
Andrew Pinski

RE: Searching configured and relocated prefix.

[Eric Weddington]

-Original Message-
From: Ian Lance Taylor [mailto:[EMAIL PROTECTED] 
Sent: Sunday, July 23, 2006 3:57 PM
To: Andrew Pinski
Cc: Mark Mitchell; Carlos O'Donell; gcc@gcc.gnu.org
Subject: Re: Searching configured and relocated prefix.

Andrew Pinski <[EMAIL PROTECTED]> writes:

> On Jul 23, 2006, at 10:44 AM, Ian Lance Taylor wrote:
> 
> > "Me too."
> 
> Except now you have suggested that we change the current behavior 
> which you already suggested at the GCC summit we should not do at 
> least not for a couple of release for warning people.  You cannot have 
> it both ways, people already depend on this behavior, I am one 
> example.

My general point at the gcc summit was not one about changing the compiler,
although that was the context in which I raised it.  It was that we should
have more consideration of the needs of our users, and less consideration of
the needs of our developers.

As far as I am concerned, the relevant question on this issue is whether
anybody other than toolchain developers depends on the current behaviour.  I
believe the answer is no.  Since the current behaviour has various drawbacks
which are clearly evident in organizations which use NFS widely, and since
moreover I believe that most non-gcc- developers do not exepect the current
behaviour, I believe that we should change it.

Ian
--

All,

I'm glad to see this issue finally being addressed.

Especially since I've been trying to work around this since Nov. 2002.
Especially since I discussed this on this mailing list in the past and Mark
agreed that this problem should be fixed, hence the filing of bug report
(enhancement) #17621, in Sep. 2004:



I also strongly agree with Danny Smith's email about this.

There are precious few people who build their own compiler. Most people just
want to use a compiler, and would rather it be built by other people. Rarely
will an installed compiler be in the exact same location as where the
compiler was built. And you can just about guarantee that is the case when
it comes to Windows because of the compiler having to be built with either
Cygwin or MinGW/MSYS. In that scenario, it is absolutely stupid to have the
compiler search the built prefix. I'm sorry, but it's stupid for the FSF to
assume that the only way a user will use the software is that they build it
themselves. There should be an innate ability and a simple and easy method
for relocation of the software.

Eric Weddington
 

Re: why the difference of two global pointers is not a constant?

[Gabriel Dos Reis]

"Rafael Espíndola" <[EMAIL PROTECTED]> writes:

| I am trying to build a table with offsets of global pointers from a
| given pointer:
| 
| void *fs[] = {f1 - f1, f2 - f1};
| 
| where f1 and f2 are functions.
| 
| GCC is able to figure out that (f1 - f1) is 0, but says "initializer
| element is not constant" when trying to compute (f2 - f1).

because that is what the language standard says.

In general, the difference between two global pointers is something
known only to the linker -- too late to evaluate as constant
expression.

-- Gaby

Re: Documentation for loop infrastructure

[Daniel Berlin]

Zdenek Dvorak wrote:
> Hello,
> 
> this patch adds documentation for loop analysis and representation of
> loops, as well as other loop-related analyses, and for functions to
> manipulate loops.  As I am not a native English speaker, there are
> probably many language errors in the document, so I would appreciate
> if someone could read it and fix them.
> 
> Also, the sections regarding data dependence analysis and lambda
> framework are missing.  Sebastian, Daniel, do you have time to write
> them? 

I can write up something on lambda.

help installing gcc 4.0.3

[Gichuru Riria]

hi all, i help installing gcc 4.0.3

[Fwd: C++ cross-devel from Linux : success]

[Danny Backx]

Dave,

After removing the gcc/as file as I wrote yesterday, the build does work
and it is possible to cross-compile a working hello-world app.

Danny

 Forwarded Message 
> From: Danny Backx <[EMAIL PROTECTED]>
> To: CeGCC Development List <[EMAIL PROTECTED]>
> Subject: C++ cross-devel from Linux : success
> Date: Tue, 25 Jul 2006 08:44:19 +0200
> 
> FYI,
> 
> I've finally managed to get the C++ compiler to get built. It produces a
> working hello world application, haven't tested anything else yet.
> 
> This has taken a while because there appears to be a problem in the gcc
> configuration that causes the build to break. Removing one file fixes
> this :-(
> 
>   Danny
-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info


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