How to remove the option -Qy to as

[Andrea Marongiu]

Hi,

 

 I'm trying to build a cross-compiler from GCC 4.2.0 source. I've

 built the binutils as cross tools and launched the configure script

 for gcc source as follows:

 

 [gcc-source]/configure --build=i686-pc-linux-gnu

 --host=i686-pc-linux-gnu --target=arm-elf --prefix=[toolchain-prefix]

 --enable-interwork --enable-multilib --enable-languages="c,c++"

 --with-newlib --with-headers=[newlib-source]/newlib/libc/include

 

 When I try "make arm-gcc" I get the following error

 

 make[1]: Entering directory

 `/home/marongiu/Desktop/GCC-4.2.1/ARM/BUILD/GCC/gcc'

 (SHLIB_LINK='' \

 SHLIB_MULTILIB=''; \

 gcc -c -g -O2 -DIN_GCC -DCROSS_COMPILE -W -Wall

 -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes

 -Wold-style-definition -Wmissing-format-attribute -DHAVE_CONFIG_H

 -I. -I. -I../../../gcc-4.2.0/gcc -I../../../gcc-4.2.0/gcc/.

 -I../../../gcc-4.2.0/gcc/../include

 -I../../../gcc-4.2.0/gcc/../libcpp/include

 -I../../../gcc-4.2.0/gcc/../libdecnumber -I../libdecnumber

 -DSTANDARD_STARTFILE_PREFIX=\"../../../\"

 -DSTANDARD_EXEC_PREFIX=\"/home/marongiu/Desktop/GCC-4.2.1/ARM/LOCAL/lib/gcc/\"

 
-DSTANDARD_LIBEXEC_PREFIX=\"/home/marongiu/Desktop/GCC-4.2.1/ARM/LOCAL/libexec/g\

 cc/\"

 -DDEFAULT_TARGET_VERSION=\"4.2.0\"

 -DDEFAULT_TARGET_MACHINE=\"arm-elf\"

 -DSTANDARD_BINDIR_PREFIX=\"/home/marongiu/Desktop/GCC-4.2.1/ARM/LOCAL/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../../../gcc-4.2.0/gcc

 -I../../../gcc-4.2.0/gcc/. -I../../../gcc-4.2.0/gcc/../include

 -I../../../gcc-4.2.0/gcc/../libcpp/include

 -I../../../gcc-4.2.0/gcc/../libdecnumber -I../libdecnumber

 ../../../gcc-4.2.0/gcc/cp/g++spec.c)

 /home/marongiu/Desktop/GCC-4.2.1/ARM/LOCAL/arm-elf/bin/as:

 unrecognized option `-Qy'

 make[1]: *** [g++spec.o] Error 1

 make[1]: Leaving directory

 `/home/marongiu/Desktop/GCC-4.2.1/ARM/BUILD/GCC/gcc'

 make: *** [all-gcc] Error 2

 

It seems to be using the correct as (arm-elf-as) which anyhow doesn't support 
the -Qy option.

I tried to remove it from the specs file but I get the same error.

 Can anybody help me?

 

 Thanks

 Andrea





  L'email della prossima generazione? Puoi averla con la nuova Yahoo! 
Mail









  ___ 
L'email della prossima generazione? Puoi averla con la nuova Yahoo! Mail: 
http://it.docs.yahoo.com/nowyoucan.html

Re: Bug or feature? C++ code that no longer compiles under GCC 4.2

[Daniel Drake]

On Thu, 2007-08-30 at 10:05 +1000, Jonathan Adamczewski wrote:
> I don't have gcc-4.2 handy - does changing this to a const reference 
> solve the problem? i.e
> 
> template
> void foo(const Op& op) { op(); }

Thanks for the suggestion, it doesn't help:

test.cpp: In member function 'void My::test()':
test.cpp:12: error: invalid initialization of non-const reference of
type 'void (&)()' from a temporary of type 'void ()()'
test.cpp:4: error: in passing argument 1 of 'void foo(const Op&) [with
Op = void ()()]'

-- 
Daniel Drake
Brontes Technologies, A 3M Company
http://www.brontes3d.com/opensource

Krister Walfridsson appointed NetBSD OS port maintainer

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Krister Walfridsson as NetBSD OS port maintainer.

Please join me in congratulating Krister on his new role.
Krister, please update your listing in the MAINTAINERS file.

Happy hacking!
David

Re: question about rtl loop-iv analysis

[Kenneth Zadeck]

Michael Matz wrote:
> Hi,
>
> On Wed, 29 Aug 2007, Bernd Schmidt wrote:
>
>   
>>> Apart from that I agree that in the case of conditional defs multiple 
>>> ones might reach a use.  I disagree for partial defs, if one dominates 
>>> the other. For most cases (except register allocation) a partial def 
>>> is just a complete killing def, which happens to leave some contents 
>>> unchanged (by conceptually copying that part from what was in there 
>>> before, hence the usual read-mod-write dependency from a partial def 
>>> which generates also a use). But the use doesn't care for this, for 
>>> all it knows that def is the one changing the contents, hence a 
>>> use-def chain should not contain a def dominating other defs (partial 
>>> or not).  The relationship between both defs will be described by the 
>>> use-def chain hanging off the implicit use generated by the partial 
>>> def.
>>>   
>> I completely agree, and I've tried very hard to argue that with Kenneth 
>> last year when I spotted this kind of bogosity in the dataflow code, but 
>> 
>
> I initially implemented giving out partial defs in df.c on the new-ra 
> branch because I needed it for precise subreg register allocation.  
> Before that df.c was doing simply the read-mod-write scheme (i.e. 
> generating a use-ref and a def-ref for each partial write).  That code 
> later also landed in mainline, with new-ra being removed somewhat later, 
> but not the df.c changes (but they were still conditional on some flag, 
> that you really wanted those partial defs, for exclusive use of a reg 
> allocator).  I believe that code was ported forward in all later df*.c 
> rewrites and extensions, and hence still is there.
>
> If that is true, then I can say for sure that I definitely never intended 
> to expose partial defs without use-refs to the outside except for very 
> constrained use cases, namely register allocation, or generally any pass 
> which might be interested in exact subreg life times _and_ is prepared to 
> handle them, which most usual code is not, simply because it doesn't 
> matter for them.  Because if they aren't prepared to handle them they will 
> become confused as to what is and what is not a "complete" definition (in 
> the sense that between that def and the use in question no contents from 
> before that bordering def remain; in fact they have no concept of that) 
> and be surprised by uses reached by two defs where one dominates the other 
> (e.g. because both are in the same basic block).
>
> 
>
> If df*.c is now doing that for all it's callers I'm pretty sure that just 
> started as an artifact and later transformed into the normal way of doing 
> things.  It would be wrong nevertheless.
>
>
> Ciao,
> Michael.
>   
Michael and Bernd,

I you look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224 you will
see that this bug has nothing to do with the type of def.  It is pilot
error on the author of the loop unrolling code.  They are looking in the
wrong places in the bitvectors.

Kenny

Re: question about rtl loop-iv analysis

[Michael Matz]

Hi,

On Thu, 30 Aug 2007, Kenneth Zadeck wrote:

> Michael and Bernd,
> 
> I you look at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33224 you will 
> see that this bug has nothing to do with the type of def.  It is pilot 
> error on the author of the loop unrolling code.  They are looking in the 
> wrong places in the bitvectors.

Yes, but I wasn't talking about the specific bug in loop-iv, sorry if that 
didn't become clear.  I was specifically reacting to your claim that 
multiple partial defs might reach one use even if one dominates the other 
and that this is the correct thing to happen.  IMO it is not and it would 
be a mistake if df*.c let this happen.  I tried to explain why I think so, 
and again wasn't refering in any way to the loop-iv bug.


Ciao,
Michael.

Why is LIMITS_H_TEST defined in cris/t-linux? It caused cross-compiler build errors

[Stephen M. Kenton]

Can anyone explain why LIMITS_H_TEST is defined in cris/t-linux, while 
it is not defined for any other linux target?  It's a relatively recent 
change. "ChangeLog-2005" line 5810 says


"2005-10-12  Hans-Peter Nilsson  <[EMAIL PROTECTED]> config/cris/t-linux 
(LIMITS_H_TEST): Define."


It breaks building of a cross-compiler when inhibit_libc is defined, and 
the comment in the code


# We *know* we have a limits.h in the glibc library, with extra
# definitions needed for e.g. libgfortran.

is certainly wrong in this case.  It it just an optimization?  Can it be 
done some other way that does not break building a cross-compiler? A 
one-liner to comment this out allows me to build a cris cross-compiler.


Segher - If remember right, cris was one of the targets that did not 
build for you. This might help.


Steve

Re: Krister Walfridsson appointed NetBSD OS port maintainer

[Krister Walfridsson]

On Thu, 30 Aug 2007, David Edelsohn wrote:


I am pleased to announce that the GCC Steering Committee has
appointed Krister Walfridsson as NetBSD OS port maintainer.

Please join me in congratulating Krister on his new role.
Krister, please update your listing in the MAINTAINERS file.


Thanks!

Updated as follows.

   /Krister

2007-08-30  Krister Walfridsson  <[EMAIL PROTECTED]>

* MAINTAINERS (OS Port Maintainers): Add myself as NetBSD maintainer.
(Write After Approval): Remove myself.


Index: MAINTAINERS
===
--- MAINTAINERS (revision 127935)
+++ MAINTAINERS (working copy)
@@ -105,6 +105,7 @@ hpuxDave Anglin [EMAIL 
PROTECTED]
 hpux   Steve Ellcey[EMAIL PROTECTED]
 irix, osf  Rainer Orth [EMAIL PROTECTED]
 netbsd Jason Thorpe[EMAIL PROTECTED]
+netbsd Krister Walfridsson [EMAIL PROTECTED]
 sco5, unixware, sco udkKean Johnston   [EMAIL PROTECTED]
 sh-linux-gnu   Kaz Kojima  [EMAIL PROTECTED]
 RTEMS PortsJoel Sherrill   [EMAIL PROTECTED]
@@ -413,7 +414,6 @@ Caroline Tice   [EMAIL 
PROTECTED]
 Michael Tiemann[EMAIL PROTECTED]
 David Ung  [EMAIL PROTECTED]
 Jonathan Wakely[EMAIL PROTECTED]
-Krister Walfridsson[EMAIL PROTECTED]
 Feng Wang  [EMAIL PROTECTED]
 Stephen M. Webb[EMAIL PROTECTED]
 John Wehle [EMAIL PROTECTED]

Re: Bug or feature? C++ code that no longer compiles under GCC 4.2

[Magnus Fromreide]

On ons, 2007-08-29 at 16:42 -0400, Daniel Drake wrote:
> Hi,
> 
> Take the following code sample:
> 
> 
> #define BREAK_GCC4_2
> 
> template
> void foo(Op& op) { op(); }
> 
> class My {
> public:
>   static void myOp() { }
> 
>   void test() {
> #ifdef BREAK_GCC4_2
> foo(myOp);
> #else
> foo(My::myOp);
> #endif
>   }
> };
> 
> 
> It compiled fine under GCC 4.1 but fails under 4.2.0:
> $ g++ -c test.cpp
> test.cpp: In member function 'void My::test()':
> test.cpp:12: error: invalid initialization of non-const reference of
> type 'void (&)()' from a temporary of type 'void ()()'
> test.cpp:4: error: in passing argument 1 of 'void foo(Op&) [with Op =
> void ()()]'
> 
> We found an alternative way to make the code compile (comment out the
> first line) which works with both versions, but I'm wondering whether
> this should be reported as a bug or if it was intentional.

I think this is a feature, and your old code were buggy.

ISO 14882:1998 states (§5.3.1p3)

> A pointer to member is only formed when an explicit & is used and its
> operand is a qualified-id not enclosed in parentheses.

and then goes on to say (in a note, so this isn't normative)

> Nor is &unqualified-id a pointer to member, even within the scope of 
> the unqualified-id's class.

/MF

Re: Bug or feature? C++ code that no longer compiles under GCC 4.2

[Joe Buck]

On ons, 2007-08-29 at 16:42 -0400, Daniel Drake wrote:
> > #define BREAK_GCC4_2
> > 
> > template
> > void foo(Op& op) { op(); }
> > 
> > class My {
> > public:
> >   static void myOp() { }
> > 
> >   void test() {
> > #ifdef BREAK_GCC4_2
> > foo(myOp);
> > #else
> > foo(My::myOp);
> > #endif
> >   }
> > };

On Thu, Aug 30, 2007 at 10:51:03PM +0200, Magnus Fromreide wrote:
> I think this is a feature, and your old code were buggy.
> 
> ISO 14882:1998 states (§5.3.1p3)
> 
> > A pointer to member is only formed when an explicit & is used and its
> > operand is a qualified-id not enclosed in parentheses.

But taking the address of myOp does not produce a pointer-to-member,
as it is a static function; &My::myOp is a pointer to an ordinary
function.

Just the same, you need the & to make an ordinary pointer-to-function
as well.  Then the other problem is the attempt to bind a non-lvalue
to a non-const reference.  If I fix both of those problems, I get

template
void foo(const Op& op) { op();}

class My {
public:
static void myOp() {}
void test() {
foo(&myOp);
}
};

and 4.2.1 accepts it.  However, if I omit the ampersand and write

template
void foo(const Op& op) { op();} // line 2

class My {
public:
static void myOp() {}
void test() {
foo(myOp);  // line 8
}
};

I get

foop_noamp.cpp: In member function 'void My::test()':
foop_noamp.cpp:8: error: invalid initialization of non-const reference of type 
'void (&)()' from a temporary of type 'void ()()'
foop_noamp.cpp:2: error: in passing argument 1 of 'void foo(const Op&) [with Op 
= void ()()]'

The error message here is bogus; there is no non-const reference.

So for users, the message is to use an ampersand to form the
pointer-to-function or pointer-to-member, and to use a const reference
if you aren't passing an lvalue.

Re: Why is LIMITS_H_TEST defined in cris/t-linux? It caused cross-compiler build errors

[Hans-Peter Nilsson]

> Date: Thu, 30 Aug 2007 14:24:36 -0500
> From: "Stephen M. Kenton" <[EMAIL PROTECTED]>

> Can anyone explain why LIMITS_H_TEST is defined in cris/t-linux, while 
> it is not defined for any other linux target?

A STFW would have given you
.

I can't tell you why it's "not defined on any other linux
target" though.

If you have a method to not define it with inhibit_libc, I'd
certainly be ok with that, but then you should automatically
disable building fortran. (And perhaps all languages but C -
which will again break when C++ is required for building gcc,
see other discussion but which BTW I'm not interested in being
CC'd about.)

brgds, H-P

Re: Why is LIMITS_H_TEST defined in cris/t-linux? It caused cross-compiler build errors

[Segher Boessenkool]

Segher - If remember right, cris was one of the targets that did not 
build for you. This might help.


No idea if it would help or not -- it currently dies with
an ICE while building __mulvdi3:

/home/segher/src/gcc/libgcc/../gcc/libgcc2.c: In function '__mulvdi3':
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:404: error: unrecognizable 
insn:
(call_insn 353 352 354 38 
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:403 (parallel [
(call (mem:QI (symbol_ref:SI ("abort") [flags 0x41] 
) [0 S1 A8])

(const_int 0 [0x0]))
(clobber (reg:SI 16 srp))
]) -1 (expr_list:REG_NORETURN (const_int 0 [0x0])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil)))
(nil))
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:404: internal compiler 
error: in ex

tract_insn, at recog.c:1990


Segher

Re: How to remove the option -Qy to as

[Jim Wilson]

Andrea Marongiu wrote:

It seems to be using the correct as (arm-elf-as) which anyhow doesn't support 
the -Qy option.


No, it is using the wrong assembler.  There are two compilers here, the
native x86 linux one, and the cross compiler.  You have the native x86
linux compiler using the arm-elf-as assembler, which won't work.

The solution is to remove $toolchain-prefix/arm-elf/bin from your path.
 It is unnecessary and undesirable.  Do put $toolchain-prefix/bin on
your path though.

Jim

Re: Why is LIMITS_H_TEST defined in cris/t-linux? It caused cross-compiler build errors

[Hans-Peter Nilsson]

> From: Segher Boessenkool <[EMAIL PROTECTED]>
> Date: Fri, 31 Aug 2007 02:31:07 +0200

> > Segher - If remember right, cris was one of the targets that did not 
> > build for you. This might help.
> 
> No idea if it would help or not -- it currently dies with
> an ICE while building __mulvdi3:

What revision, what host?  My autotester reports no regressions
as recent as r127936, cross from x86_64-unknown-linux-gnu
(Debian etch).

In any case, please enter a bug report and assign it to me.

brgds, H-P

Re: Stage 2 project: upgrade decNumber

[Mark Mitchell]

Janis Johnson wrote:

>> But it looks like libdecnumber is processed in stage 1.  What if the
>> stage 1 compiler doesn't handle C++ comments?
> 
> Right, decNumber is used in the C compiler and it's the C++ comments
> that convinced me of the need to modify the sources.  While I'm at it I
> might as well get rid of CRLF (col does that nicely), and after that
> it's no more work to run it through indent so it will look like our
> other code.

I think it's fine to put this upgrade in, assuming all the usual testing.

FWIW, keeping this as much like the upstream sources as possible seems
desirable to me; I'd probably do the C++ comments and leave it at that,
just to ease future merges.  But, that's just my two cents.

Thanks,

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

Stage 2 project: new interference graph representation.

[Peter Bergner]

As a somewhat related follow on to Kenny's new interference graph
builder patch (which is still waiting for a full review):

http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01729.html

I'd like to squeeze in a new representation of the interference graph
that in some cases can save a significant amount of memory. The actual
amount of memory savings can vary, depending on the function we're
compiling, but in the worst case, we save just over half the space
(n * (n - 1)) / 2 versus n * n.  In some cases, we can save a lot more.
For example, using the test case attached to:

http://gcc.gnu.org/PR33237

the old interference graph uses just over 20 Mbytes of space, while
the new representation uses only 806 Kbytes.  There's also the
possibility we can save even more space in the future.

I should have a patch ready to post tomorrow for people to look at.

Peter

Re: Why is LIMITS_H_TEST defined in cris/t-linux? It caused cross-compiler build errors

[Steve Kenton]

Interesting.  I built it (along with 22 others) today and it worked 
using gcc 4.2.1 and binutils 2.18 on x86_64 to build a 4.2.1 criss 
cross-compiler on top of the inhibit_libc check for linux-unwind.h I 
posted yesterday.  I need to rework that one a bit,
but it got alpha, sparc, and several others building for me.  The one 
liner LIMITS_H_TEST got cris-gcc building for me. It is probably not 
ready for prime time either, but it works for me.


I had a similar looking ICE on v850 which was the only one I have not 
gotten to work yet although ia64 comes and goes, I'm not sure exactly 
why yet.  I started to reduce the list of things I'm --disabling or 
doing --without and now I have yet another similar looking error in frv 
that was not there earlier today.  I looked into what I would need for a 
bug report, but time for judo class rolled around and I left work before 
I made any real progress on it.  Not much difference to the config 
commands.  I moved the --enable-languages up a bit and got rid of 
--disable-checking.  The --with-sysroot and --with-newlib were already 
commented out and ignored earlier.  Something is definitely rotten.


Here is the config that produced criss-gcc and frv-gcc but got an ice 
building v850-gcc
> $CONFIG_SHELL $source/gcc-$gcc/configure --quiet --prefix=$prefix 
--disable-nls --build=$thisystem --host=$thisystem --target=$target 
--enable-targets-all --program-prefix=$arch-linux- 
--with-local-prefix=$prefix -disable-shared --disable-multilib 
--disable-threads --disable-libssp --disable-libmudflap 
--disable-libgomp --disable-decimal-float --disable-checking 
--enable-languages=c  #--with-sysroot=$prefix/$arch-linux --with-newlib


Here is the config that produces criss-gcc but got an ice building 
frv-gcc and another ice building v850-gcc
< $CONFIG_SHELL $source/gcc-$gcc/configure --quiet --prefix=$prefix 
--disable-nls --build=$thisystem --host=$thisystem --target=$target 
--enable-targets-all --program-prefix=$arch-linux- 
--with-local-prefix=$prefix --enable-languages=c $gccoptions 
-disable-shared --disable-multilib --disable-threads --disable-libssp 
--disable-libmudflap --disable-libgomp --disable-decimal-float 
#--disable-checking


/snap/build/src/gcc-4.2.1/gcc/libgcc2.c: In function '__divsc3':
/snap/build/src/gcc-4.2.1/gcc/libgcc2.c:1910: internal compiler error: 
in default_secondary_reload, at targhooks.c:532

Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [libgcc/./_divsc3.o] Error 1
make[3]: Leaving directory `/snap/build/obj/gcc-4.2.1/frv/gcc'


fp-bit.c: In function '__fixsfsi':
fp-bit.c:1445: error: unrecognizable insn:
(insn 136 8 137 2 fp-bit.c:1423 (set (reg/f:SI 3 sp)
   (plus:SI (reg/f:SI 3 sp)
   (const_int 4294967256 [0xffd8]))) -1 (nil)
   (nil))
fp-bit.c:1445: internal compiler error: in extract_insn, at recog.c:2077
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
make[3]: *** [libgcc/./_sf_to_si.o] Error 1
make[3]: Leaving directory `/snap/build/obj/gcc-4.2.1/v850/gcc'


Segher Boessenkool wrote:
Segher - If remember right, cris was one of the targets that did not 
build for you. This might help.


No idea if it would help or not -- it currently dies with
an ICE while building __mulvdi3:

/home/segher/src/gcc/libgcc/../gcc/libgcc2.c: In function '__mulvdi3':
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:404: error: 
unrecognizable insn:
(call_insn 353 352 354 38 
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:403 (parallel [
(call (mem:QI (symbol_ref:SI ("abort") [flags 0x41] 
) [0 S1 A8])

(const_int 0 [0x0]))
(clobber (reg:SI 16 srp))
]) -1 (expr_list:REG_NORETURN (const_int 0 [0x0])
(expr_list:REG_EH_REGION (const_int 0 [0x0])
(nil)))
(nil))
/home/segher/src/gcc/libgcc/../gcc/libgcc2.c:404: internal compiler 
error: in ex

tract_insn, at recog.c:1990


Segher

Re: Why is LIMITS_H_TEST defined in cris/t-linux? It caused cross-compiler build errors

[Rask Ingemann Lambertsen]

On Thu, Aug 30, 2007 at 11:39:57PM -0500, Steve Kenton wrote:

[v850]
> fp-bit.c: In function '__fixsfsi':
> fp-bit.c:1445: error: unrecognizable insn:
> (insn 136 8 137 2 fp-bit.c:1423 (set (reg/f:SI 3 sp)
>(plus:SI (reg/f:SI 3 sp)
>(const_int 4294967256 [0xffd8]))) -1 (nil)
>(nil))

   A bugzilla search would have led you to bug target/32558.

-- 
Rask Ingemann Lambertsen