apply for the relevant forms

[liqin]

Dear maintainer,

Our Co. have a new 32b embedded processor, and we have ported the gcc 
backend for it(support c/c++), now we want add its backend code into gcc 
packages. i read the "Contributing to GCC " pages that we must sign some 
forms, can you kindly send the forms to me?

Best Regards
Liqin

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Wolfgang Mües]

Paul,

On Sunday 04 June 2006 17:57, Paul Brook wrote:
> Because then you have several different patterns for the same
> operation. The different variants of movsi should be part of the same
> pattern so that the compiler can change its mind which variant it
> wants to use.

Together with the comments of Rask Ingemann (Thanks, Rask!), I 
understand now what you mean.

But regarding the fact that swpb() needs a temporary register - or 
alternative - clobber the input register - how can I model this 
behaviour in a single insn? 

> You're confusing constraints and predicates. general_operand is the
> predicate. The predicate says under which conditions the insn will
> match. The constraints tell regalooc/reload how to make sure the
> operands of the instruction are valid.

Yes, my wording was incorrect. But I know already the difference from 
the manual.

> Tightening the predicates isn't sufficient (and may not even be
> neccessary). You need to set the constraints so that the compiler
> knows *how* to fix invalid instructions.

And if I have 4 different constraints in a single insn, and only one of 
them is needing a temporary register, how do I model this?
This may be the biggest problem. And because byte writes are so common, 
it deserves a good implementation. I can't waste a temporary register 
for each load/store.

> The compilcation is that while constraints give sufficient
> information for the compiler to generate correct code they don't help
> generating good code. There are often non-obvious target specific
> ways of reloading invalid addresses. So reload has additional hooks
> (eg. GO_IF_LEGITIMATE_ADDRESS) to provice clever ways of fixing
> invalid operands.

I will look into this region of code to understand what's going on 
there.

Thanks, Paul.

regards

Wolfgang
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Richard Earnshaw]

On Sun, 2006-06-04 at 22:01, Rask Ingemann Lambertsen wrote:
> On Sun, Jun 04, 2006 at 12:24:53PM +0100, Paul Brook wrote:
> 
> > For the record these hacks are unlikely to ever be acceptable in mainline 
> > gcc. 
> > They're relatively invasive changes who's only purpose is to support 
> > fundamentally broken hardware.
> 
> We don't yet know if they'll be invasive. There's a good chance that they
> won't be more than a few new insn patterns, a secondary output reload
> to provide a scratch register and a pair of new options.
> 
I'm confident right now that these will be too invasive to include in
mainline.

> There are other targets with targets specific options to work around this or
> that bug, quirk, defect or errata. In this case, why would two options
> -mno-byte-writes and -mbyte-writes, with the latter being the default, be
> unlikely to be acceptable? In particular, the MT port has these two options:

The changes that tend to get incorporated into the compiler are to work
around bugs in the CPU, not bugs in some H/W developer's use of the
CPU.  The former affect all users of the processor, the latter only that
one case.

If we started putting in hacks for the latter the compiler back-ends
would become unmaintainable in almost no time at all.

Sorry, it's just not going to happen.

R.

PS.  Using swp is a bad idea IMO, this instruction is *very* slow on
some CPU implementations because of the way it interacts with caches. 
It certainly isn't suitable as a generic solution to this sort of issue.

Re: A reload failure which I can't figure out

[Rask Ingemann Lambertsen]

On Tue, May 30, 2006 at 08:23:34PM +0200, Rask Ingemann Lambertsen wrote:
> Hi.
> 
> I have problems figuring out why reload gives up on this:
> 
> reload failure for reload 1
> ../../../cvssrc/gcc/gcc/libgcc2.c: In function '__moddi3':
> ../../../cvssrc/gcc/gcc/libgcc2.c:1101: error: unable to find a register to
> spill in class 'DX_REGS'
> ../../../cvssrc/gcc/gcc/libgcc2.c:1101: error: these are the reloads for
> insn # 425:
> Reload 0: reload_in (HI) = (reg:HI 4 d [+2 ])
> reload_out (HI) = (reg:HI 0 c [199])
> AX_REGS, RELOAD_OTHER (opnum = 0)
> reload_in_reg: (reg:HI 4 d [+2 ])
> reload_out_reg: (reg:HI 0 c [199])
> Reload 1: reload_out (HI) = (scratch:HI)
> DX_REGS, RELOAD_FOR_OUTPUT (opnum = 3)
> reload_out_reg: (scratch:HI)
> ../../../cvssrc/gcc/gcc/libgcc2.c:1101: error: this is the insn:
> (insn 425 422 432 30 ../../../cvssrc/gcc/gcc/libgcc2.c:911 (parallel [
> (set (reg:HI 0 c [199])
> (mult:HI (reg:HI 4 d [+2 ])
> (reg:HI 6 b [orig:629 __d0 ] [629])))
> (clobber (scratch:HI))
> (clobber (reg:CC 12 cc))
> ]) 309 {*mulhi3} (nil)
> (expr_list:REG_UNUSED (reg:CC 12 cc)
> (expr_list:REG_UNUSED (scratch:HI)
> (expr_list:REG_DEAD (reg:HI 4 d [+2 ])
> (expr_list:REG_UNUSED (reg:CC 12 cc)
> (expr_list:REG_UNUSED (scratch:HI)
> (nil)))
> ../../../cvssrc/gcc/gcc/libgcc2.c:1101: internal compiler error: in
> spill_failure, at reload1.c:1915
> 
> The *mulhi3 pattern is this:
> (define_insn "*mulhi3"
> [(set (match_operand:HI 0 "single_register_operand" "=a")
>   (mult:HI (match_operand:HI 1 "single_register_operand" "%0")
>(match_operand:HI 2 "general_operand" "rm")))
>  (clobber (match_scratch:HI 3 "=d"))
>  (clobber (reg:CC CC_REG))]
> ""
> "mulw\t%2"
> )
> 
> where the constraint "a" matches the register class AX_REGS consiting of
> (reg:HI 2 a), the constraint "d" matches the register class DX_REGS
> consiting of (reg:HI 4 d)

What happens is that global.c:reg_dies() sets (reg:HI 4 "d") in
&chain->dead_or_set. Later, reload1.c:order_regs_for_reload() add these
registers to bad_spill_regs. Finally, reload1.c:find_reg() decides that
registers in bad_spill_regs are not usable and registers other than those
of the constraints register class are also not usable. Since both consist of
(reg:HI 4 d), all registers are now marked not usable. So reload fails.

There is at least one fault with the reasoning of global/reload here. Since
(reg:HI 4 d) dies in this instruction, it is perfectly fine to use it for an
output reload. That's different from the case where (reg:HI 4 d) is set and
the value used afterwards. So why are these two cases handled the same way?

Also, since (reg:HI 4 d) doesn't match the constraint "a", it
doesn't really die in this instruction, but in the instruction
(set (reg:HI 2 a) (reg:HI 4 a)) which reload is about to insert before
*mulhi3. Maybe that's ok.

-- 
Rask Ingemann Lambertsen

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Wolfgang Mües]

Hello Dave ;-)

On Monday 05 June 2006 02:12, Dave Murphy wrote:
> I was just about to ask about this very thing since I'm quite sure
> that there would be interest in adding this to devkitARM.

You are following the process in dslinux, don't you?

In fact, devkitARM is my current build environment. The first thing that 
will happen is a patch to devkitARM.

>  How much work would it be to implement these switches?

Good question ;-)

>  I assume that the toolchain would need multilibs for these options in
>  order to use newlib etc.

I have not looked into library issues now. Compiler comes first.
We will need an asm macro for 8bit writes to the hardware registers.

And the devkitARM libraries *must* implement writeback caching for the 
GBA slot ROM area.

regards
Wolfgang

-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Wolfgang Mües]

Richard,

On Monday 05 June 2006 12:06, Richard Earnshaw wrote:
> I'm confident right now that these will be too invasive to include in
> mainline.

As said before, this is OK for me. 

> The changes that tend to get incorporated into the compiler are to
> work around bugs in the CPU, not bugs in some H/W developer's use of
> the CPU.  The former affect all users of the processor, the latter
> only that one case.
>
> If we started putting in hacks for the latter the compiler back-ends
> would become unmaintainable in almost no time at all.

Agreed.

> PS.  Using swp is a bad idea IMO, this instruction is *very* slow on
> some CPU implementations because of the way it interacts with caches.

Yes, swp forces a cache load. But in this particular case, forcing a 
cache load is the ONLY way to circumvent the hardware problem.
If there is a block write, cache loads are forced only each 32 byte 
accesses.

Other possible solutions:

a) code a 16bit read-modify-write. This will also cause a cache load,
   and will need much more code, because it will have to look at the
   LSB of the address to know where to insert the byte into the word.

b) use the protection unit and make a data abort for a write to that 
memory region. This has the advantage of affecting ONLY the critical 
memory region (not all the other ones), but the disadvantages are big:
all memory writes are affected, and a data abort handler is very slow. 
This solution was implemented before, it was 100 times slower than 
native access. Unusable.

regards

Wolfgang
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Wolfgang Mües]

Hello,

my first little success...

in arm.h, I have changed

> /* Output the address of an operand.  */
> #define ARM_PRINT_OPERAND_ADDRESS(STREAM, X)  \
> { \
> int is_minus = GET_CODE (X) == MINUS; 
> \
>   \
> if (GET_CODE (X) == REG)  \
>   asm_fprintf (STREAM, "[%r, #0]", REGNO (X));
> \

into

> /* Output the address of an operand.  */
> #define ARM_PRINT_OPERAND_ADDRESS(STREAM, X)  \
> { \
> int is_minus = GET_CODE (X) == MINUS; 
> \
>   \
> if (GET_CODE (X) == REG)  \
>   asm_fprintf (STREAM, "[%r]", REGNO (X));
> \

I don't know why the form "[%r, #0]" was coded before, because the 
assembler understands "[%r]" very well for all instructions. The form 
"[%r]" has a wider usage because it covers swp too.

On Sunday 04 June 2006 23:36, Rask Ingemann Lambertsen wrote:
> On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
> > > (define_insn "*arm_movqi_insn"
> > >   [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
> > >   (match_operand:QI 1 "general_operand" "rI,K,m,r"))]

> I think you should go back to this (i.e. the unmodified version) and
> only change the "m" into "Q" in the fourth alternative of operand 0.
> See if that works, i.e. generates addresses that are valid for the
> swp instruction.

No, that doesn't work:

> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c: In function
> __register_frame_info_table_bases':
> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: error: insn does not
> satisfy its constraints: (insn 63 28 29 0
> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:136 (set (mem/s/j:QI (plus:SI
> (reg/v/f:SI 1 r1 [orig:102 ob ] [102]) (const_int 16 [0x10])) [0 S1
> A32])
> (reg:QI 12 ip)) 155 {*arm_movqi_insn} (nil)
> (nil))
> ../../../gcc-4.0.2/gcc/unwind-dw2-fde.c:146: internal compiler error:
> in reload_ cse_simplify_operands, at postreload.c:391

Also, I wonder what the "Q" constraint really means:

from the GCC manual:

> Q
> A memory reference where the exact address is in a single register
> (``m'' is preferable for asm statements)

but in arm.h:

> /* For the ARM, `Q' means that this is a memory operand that is just
>an offset from a register.
> #define EXTRA_CONSTRAINT_STR_ARM(OP, C, STR)  \
>((C) == 'Q') ? (GET_CODE (OP) == MEM   
> \
>&& GET_CODE (XEXP (OP, 0)) == REG) :   \

Obviously, GCC tries to implement REG+CONSTANT with Q.

Maybe I must define a new constraint?

regards

Wolfgang
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Richard Earnshaw]

On Mon, 2006-06-05 at 12:47, Wolfgang Mües wrote:

> > /* Output the address of an operand.  */
> > #define ARM_PRINT_OPERAND_ADDRESS(STREAM, X)\
> > {   \
> > int is_minus = GET_CODE (X) == MINUS;   
> > \
> > \
> > if (GET_CODE (X) == REG)
> > \
> >   asm_fprintf (STREAM, "[%r]", REGNO (X));  
> > \
> 
> I don't know why the form "[%r, #0]" was coded before, because the 
> assembler understands "[%r]" very well for all instructions. The form 
> "[%r]" has a wider usage because it covers swp too.

Historical reasons.  In the past gas would incorrectly assemble '[rn]'
as '[rn], #0' which was unpredictable if rn appeared in the load/store
target.  However, this bug was fixed several years ago now, so it's
probably safe to switch back to the short form.

R.

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Paul Brook]

> > Tightening the predicates isn't sufficient (and may not even be
> > neccessary). You need to set the constraints so that the compiler
> > knows *how* to fix invalid instructions.
>
> And if I have 4 different constraints in a single insn, and only one of
> them is needing a temporary register, how do I model this?
> This may be the biggest problem. And because byte writes are so common,
> it deserves a good implementation. I can't waste a temporary register
> for each load/store.

You use "X" constraints on the scratch for the other alternatives.
Not that this means your "*arm_movqi" pattern now has three operands, so 
doesn't mathc the named "movqi" pattern. You'll probably have to make the 
movqi expander allocate a pseudo for the scratch, and also implement 
reload_inq/reload_outqi for the cases where no new pseudos are allowed. As I 
mentioned before the Alpha backend is probably a good reference for these.

Paul

Objective C++ Bundling

[Ranjit Mathew]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi,

  I found out recently that with just the gcc-core and
gcc-g++ files, bootstrapping with --enable-languages=c,c++
fails since "gcc/objcp" was being processed without
Objective C front-end and runtime files being there in
the source tree.

I think something like the following patch should be applied
to the gcc_release script - I'm not submitting this as a
formal patch since I don't know how to use this script
and I just use the variables defined by it (JAVA_DIRS,
TESTSUITE_DIRS, etc.) to create a reduced snapshot of GCC
sources for myself.
- -- 8< --
Index: gcc_release
===
- --- gcc_release   2006-06-05 17:45:51.0 +0530
+++ gcc_release 2006-06-05 17:46:19.0 +0530
@@ -581,5 +581,5 @@ FORTRAN_DIRS="gcc/f libf2c"
 FORTRAN95_DIRS="gcc/fortran libgfortran"
 JAVA_DIRS="gcc/java libjava libffi fastjar zlib boehm-gc"
- -OBJECTIVEC_DIRS="gcc/objc libobjc"
+OBJECTIVEC_DIRS="gcc/objc gcc/objcp libobjc"
 TESTSUITE_DIRS="gcc/testsuite"

- -- 8< --
Thanks,
Ranjit.

- --
Ranjit Mathew  Email: rmathew AT gmail DOT com

Bangalore, INDIA.Web: http://rmathew.com/


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2.2 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFEhCJwYb1hx2wRS48RAh23AJsEX55xF9UEisIniv6ziNKDdNfcOQCggm52
oTB8a8hjV+o/MW3KBZ+oUvA=
=mRde
-END PGP SIGNATURE-

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Rask Ingemann Lambertsen]

On Mon, Jun 05, 2006 at 01:47:10PM +0200, Wolfgang Mües wrote:

> I don't know why the form "[%r, #0]" was coded before, because the 
> assembler understands "[%r]" very well for all instructions. The form 
> "[%r]" has a wider usage because it covers swp too.

Does GCC happen to accept "[%r, #0]" for swp?

> Also, I wonder what the "Q" constraint really means:
> 
> from the GCC manual:
> 
> > Q
> > A memory reference where the exact address is in a single register
> > (``m'' is preferable for asm statements)
> 
> but in arm.h:
> 
> > /* For the ARM, `Q' means that this is a memory operand that is just
> >an offset from a register.
> > #define EXTRA_CONSTRAINT_STR_ARM(OP, C, STR)\
> >((C) == 'Q') ? (GET_CODE (OP) == MEM 
> > \
> >  && GET_CODE (XEXP (OP, 0)) == REG) :   \

I think the comment in arm.h is wrong. The manual seems to agree with the
code.

> Obviously, GCC tries to implement REG+CONSTANT with Q.
> 
> Maybe I must define a new constraint?

I tried 'V' instead, but it looks as if reload completely ignores the
meaning of the constraint. There is already a comment in arm.md about that.
It should be investigated further.

Meanwhile, I changed arm_legitimate_address_p() to enforce the correct
address form. This hurts byte loads too, though.

Index: gcc/config/arm/arm.c
===
--- gcc/config/arm/arm.c(revision 114119)
+++ gcc/config/arm/arm.c(working copy)
@@ -3509,6 +3509,9 @@
   if (arm_address_register_rtx_p (x, strict_p))
 return 1;
 
+  if (TARGET_ARM && TARGET_SWP_BYTE_WRITES && mode == QImode && outer == SET)
+return 0;
+
   use_ldrd = (TARGET_LDRD
  && (mode == DImode
  || (mode == DFmode && (TARGET_SOFT_FLOAT || TARGET_VFP;

Index: gcc/config/arm/arm.opt
===
--- gcc/config/arm/arm.opt  (revision 114119)
+++ gcc/config/arm/arm.opt  (working copy)
@@ -153,3 +153,7 @@
 mwords-little-endian
 Target Report RejectNegative Mask(LITTLE_WORDS)
 Assume big endian bytes, little endian words
+
+mswp-byte-writes
+Target Report Mask(SWP_BYTE_WRITES)
+Use the swp instruction for byte writes

Index: gcc/config/arm/arm.md
===
--- gcc/config/arm/arm.md   (revision 114119)
+++ gcc/config/arm/arm.md   (working copy)
@@ -5158,7 +5158,7 @@
 (define_insn "*arm_movqi_insn"
   [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
(match_operand:QI 1 "general_operand" "rI,K,m,r"))]
-  "TARGET_ARM
+  "TARGET_ARM && !TARGET_SWP_BYTE_WRITES
&& (   register_operand (operands[0], QImode)
|| register_operand (operands[1], QImode))"
   "@
@@ -5170,6 +5170,44 @@
(set_attr "predicable" "yes")]
 )
 
+; This is for the Nintendo DS external RAM.
+(define_insn "*arm_movqi_insn_swp"
+  [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,Q")
+   (match_operand:QI 1 "general_operand" "rI,K,m,r"))]
+  "TARGET_ARM && TARGET_SWP_BYTE_WRITES
+   && (   register_operand (operands[0], QImode)
+   || register_operand (operands[1], QImode))"
+  "@
+   mov%?\\t%0, %1
+   mvn%?\\t%0, #%B1
+   ldr%?b\\t%0, %1
+   swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
+  [(set_attr "type" "*,*,load1,store1")
+   (set_attr "predicable" "yes")]
+)
+
+(define_insn "*arm_movqi_insn_swp_clobber"
+  [(set (match_operand:QI 0 "memory_operand" "=Q")
+(match_operand:QI 1 "register_operand" "r"))
+   (clobber (match_operand:QI 2 "register_operand" "=r"))]
+  "TARGET_ARM && TARGET_SWP_BYTE_WRITES"
+  "swp%?b\\t%2, %1, %0"
+  [(set_attr "type" "store1")
+   (set_attr "predicable" "yes")]
+)
+
+; Avoid reading the stored value back if we have a spare register.
+(define_peephole2
+  [(match_scratch:QI 2 "r")
+   (set (match_operand:QI 0 "memory_operand" "")
+(match_operand:QI 1 "register_operand" ""))]
+  "TARGET_ARM && TARGET_SWP_BYTE_WRITES"
+  [(parallel [
+(set (match_dup 0) (match_dup 1))
+(clobber (match_dup 2))]
+  )]
+)
+
 (define_insn "*thumb_movqi_insn"
   [(set (match_operand:QI 0 "nonimmediate_operand" "=l,l,m,*r,*h,l")
(match_operand:QI 1 "general_operand"  "l, m,l,*h,*r,I"))]

This seems to work as intended on a small test case:

struct foobar
{
int  i1;
char c1;
char c2;
int  i2;
};

void bytewritetest (struct foobar *x)
{
x->i2 = x->i1;
x->i1 = x->c1 + x->c2;
x->c2 ^= x->c1;
}

With just -O2:

bytewritetest:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldrbr3, [r0, #5]@ zero_extendqisi2
ldrbr2, [r0, #4]@ zero_extendqisi2
ldr ip, [r0, #0]
eor r1, r3, r2
add r3, r3, r2
@ lr needed for prologue
strbr1, 

Re: Why are we installing libtool files now?

[Tom Tromey]

> "Richard" == Richard Guenther <[EMAIL PROTECTED]> writes:

>> On 6/4/06, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
>> I noticed that with a full build (including all of GCJ and libgcj),
>> we now install a bootload of libtool files into $PREFIX/share:

Richard> PR27818

Thanks.  I fixed this.

Tom

Re: Objective C++ Bundling

[Mike Stump]

On Jun 5, 2006, at 5:24 AM, Ranjit Mathew wrote:

I found out recently that with just the gcc-core and
gcc-g++ files, bootstrapping with --enable-languages=c,c++
fails since "gcc/objcp" was being processed without
Objective C front-end and runtime files being there in
the source tree.


I think this patch looks ok, but, things like this should be reviewed  
by the people that run them.

Re: Objective C++ Bundling

[Paolo Bonzini]

Mike Stump wrote:

On Jun 5, 2006, at 5:24 AM, Ranjit Mathew wrote:

I found out recently that with just the gcc-core and
gcc-g++ files, bootstrapping with --enable-languages=c,c++
fails since "gcc/objcp" was being processed without
Objective C front-end and runtime files being there in
the source tree.


I think this patch looks ok, but, things like this should be reviewed by 
the people that run them.


The patch transfers the burden on people (maybe fewer than people 
downloading gcc-core and gcc-g++) that only download gcc-core and gcc-objc.


I'll work on the issue as soon as somebody confirms that the patch 
attached to PR26188 fixes that issue (I cannot work on too many things 
at a time right now).  There is an open bug about this issue, but I 
don't remember the PR number; feel free to assign it to me.


Paolo

Re: Solaris 2.8 build failure for 4.1.1 (libtool/libjava)

[Jim Wilson]

Joe Buck wrote:

It's GNU ld version 2.16.1.  This is strange; I would have expected the
linker to get just -rpath: -Wl should tell gcj to pass the following
option to the linker.


Known problem.  See PR 21206.
--
Jim Wilson, GNU Tools Support, http://www.specifix.com

Re: GCC 4.2 Status Report (2006-06-04)

[Joern RENNECKE]

In http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html, you wrote:


As fwprop is no longer on the table for 4.2, and as the vectorizer
improvements seem to have stalled due to a combination of lack of review
and Dorit's leave, I think it's time to declare 4.2 feature-complete.


I am still waiting for review of by auto-increment patches, and for Berndt
to complete the cross-jump part struct-equiv patches, so that I can post an
updated patch for the if-conversion part. 


That leaves us looking at regressions.


The patch queue also includes some patches for bugs that are not strictly 
speaking regressions.

Where is the egg?

[Steven Bosscher]

Hi Gerald,

Your updates to gcc.gnu.org are, ehm, not my taste, but I guess
we have to follow www.gnu.org.

But is it really necessary to remove the egg too?  Can we have
it back? Pleaeaeaeaese? :-)

Gr.
Steven

which cctool on Darwin?

[Jack Howarth]

I noticed that Xcode 2.3 seems to have a cctools with a higher
version that that in the infrastructure directory at the gcc ftp
site. Should we be using the Xcode 2.3 version instead of that
20060413 copy for building gcc trunk?
   Jack

[wwwdocs] Complete revamp of our web site

[Gerald Pfeifer]

The following patchset renovates our web presence, adopting the current
style from www.gnu.org and bringing the Java and libstdc++ pages in sync
so that we now have one common style.

Feedback welcome!  (Steven, I've seen yours already and will respond. ;-)


Compress the navigation bar vertically, such that it no longer dominates
our vertical extent.
Move the gcc-announce subscription form from the navigation bar to the
body and restructure the lower half of the body into two columns, the
left one for announcements, the right one for subscription and search.
Disable the old logo and move the navigation bar from the left side to
the right side.
Adjust the Java and libstdc++ pages similarly by moving the navigation
bar to the right side.  Adjust the style in those two areas to our new
global style.

Gerald

Index: index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision 1.562
diff -u -r1.562 index.html
--- index.html  5 Jun 2006 10:46:26 -   1.562
+++ index.html  5 Jun 2006 20:26:46 -
@@ -6,10 +6,12 @@
 
 
 
-
-
 GCC, the GNU Compiler Collection
 
+
+
 The GNU Compiler Collection includes front ends for
 C, C++, Objective-C, Fortran,
 Java, and Ada, as well as libraries for these
@@ -85,6 +87,9 @@
 
 -->
 
+
+
+
 News/Announcements
 
 
@@ -124,7 +129,24 @@
 | http://gcc.gnu.org/onlinedocs/g77/News.html";>Fortran 77 status
 | Older news and announcements...
 
+
+
+Get our announcements:
+
+  http://gcc.gnu.org/cgi-bin/ml-request";>
+
+
+
+
+
+  
+
+Search our site
+
 
 
+
+
+
 
 
Index: style.mhtml
===
RCS file: /cvs/gcc/wwwdocs/htdocs/style.mhtml,v
retrieving revision 1.89
diff -u -r1.89 style.mhtml
--- style.mhtml 5 Jun 2006 00:17:20 -   1.89
+++ style.mhtml 5 Jun 2006 20:34:25 -
@@ -12,23 +12,12 @@
   
 >
 
-;;; For the "java/" pages, we have a different color scheme.
+;;; For the "java/" pages, we want the navigation bar.
 
  "java/[^/]*.html">
  
   
-   bgcolor="#B0D0FF" 
-   bgcolor="#E0F0FF" 
-  
-   
-
-   
-   %body
-   
-
-   
-  
  >
 >
 
@@ -121,7 +110,17 @@
   
   
 
- 
+ 
+ >
+>
+
+%body
+
+
+ 
+
+  
   
 
"java/[^/]*.html">
@@ -148,17 +147,15 @@
"libstdc../[^/]*.html">

-
+ >
 libstdc++ v3
 
-
-
+ >
 libstdc++ Home
 GCC Home
 http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.html";>FAQ
 (http://gcc.gnu.org/onlinedocs/libstdc++/faq/index.txt";>text)
 http://gcc.gnu.org/onlinedocs/libstdc++/documentation.html";>Documentation
-
 
 
>
@@ -169,14 +166,12 @@
   About GCC
   
>
-  
   Mission Statement
   Releases
   Snapshots
   Mailing lists
   http://gcc.gnu.org/onlinedocs/gcc/Contributors.html";>Contributors
   Steering Committee
-  
   
   
 
@@ -185,15 +180,12 @@
   Documentation
   
>
-  
-  http://gcc.gnu.org/install/";>Installation
   · http://gcc.gnu.org/install/specific.html";>Platforms
   · http://gcc.gnu.org/install/test.html";>Testing
   Manual
   FAQ
   http://gcc.gnu.org/wiki";>Wiki
   Further Readings
-  
   
   
  
@@ -202,10 +194,8 @@
   Download
   
>
-  
   Mirror sites
   http://gcc.gnu.org/install/binaries.html";>Binaries
-  
   
   
 
@@ -214,11 +204,9 @@
   "Live" Sources
   
>
-  
   SVN read access
   Rsync read access
   SVN write access
-  
   
   
 
@@ -227,7 +215,6 @@
   Development
   
>
-  
   Development Plan
   · (tentative timeline)
   Contributing
@@ -237,7 +224,6 @@
   Back ends
   Extensions
   Benchmarks
-  
   
   
 
@@ -246,37 +232,15 @@
   Bugs
   
>
-  
   Known bugs
   How to report
   http://gcc.gnu.org/bugzilla/";>Bug database
   ...Management
-  
-  
-  http://gcc.gnu.org/cgi-bin/ml-request";>
-Get our announcements:
-
-
-
-
-
-
-  
   
   
 
   
-  
-
-
- >
->
-
-%body
-
-
-
+   
 
   
   

Re: which cctool on Darwin?

[Geoffrey Keating]

On 05/06/2006, at 1:44 PM, Jack Howarth wrote:


I noticed that Xcode 2.3 seems to have a cctools with a higher
version that that in the infrastructure directory at the gcc ftp
site. Should we be using the Xcode 2.3 version instead of that
20060413 copy for building gcc trunk?


Yes.



smime.p7s
Description: S/MIME cryptographic signature

Re: [wwwdocs] Complete revamp of our web site

[Martin Michlmayr]

* Gerald Pfeifer <[EMAIL PROTECTED]> [2006-06-05 22:51]:
>  GCC, the GNU Compiler Collection

How about a dash here rather than a comma?  Looks nicer imho:
|  GCC - the GNU Compiler Collection
-- 
Martin Michlmayr
[EMAIL PROTECTED]

Re: [wwwdocs] Complete revamp of our web site

[DJ Delorie]

> Feedback welcome!

Right-side navigation bars are nonstandard.  It should be moved to the
left side.  Don't accept the search engine excuse; that's easily
fixable.  Also, by fixing the search engine issue you punish Lynx
users; the navigation menu is now near (but not at) the end of the
text.

Sidebars should have some enclosing detail, such as a border or a
shading, so set them off from the rest of the page.  Don't rely on
whitespace to do this job.

"Platforms" and "Testing" have bullets; no other item in that list
does.

Re: [wwwdocs] Complete revamp of our web site

[Tom Tromey]

> "Gerald" == Gerald Pfeifer <[EMAIL PROTECTED]> writes:

Gerald> The following patchset renovates our web presence, adopting
Gerald> the current style from www.gnu.org and bringing the Java and
Gerald> libstdc++ pages in sync so that we now have one common style.

Looking better!  I like it much more.

Gerald> Feedback welcome!

Since you asked...

For the gcj pages I think there are still some things that would be
nice to change.  Some is content, some is layout, and some is
technology.  Overall the pages (and the gcc main page is included
here) are too cluttered.

Content:

The "what is gcj" section is too verbose.  It should be a single
paragraph, and then a link to "more info" or something like that.

Layout:

The font is too big.  The news section should be visible when you
first visit the page, without scrolling.  In particular I think the
news should be along the left, the "what is gcj?" thing in the middle,
and the navigation on the right (or reversed if the navigation is on
the left... I don't really care where that ends up).

Technology:

We should have an RSS feed for the news.  Ideally any gcj hacker could
add a news entry without a cvs commit, but I don't insist on that :).
The news column for gcj should come from this feed, and the news
column for the main gcc page should subscribe to it.

Take a look at the mono main page if you want to see something that
looks nice, is clean, and remains useful.

Tom

Re: Where is the egg?

[Gabriel Dos Reis]

Steven Bosscher <[EMAIL PROTECTED]> writes:

| But is it really necessary to remove the egg too?  Can we have
| it back? Pleaeaeaeaese? :-)

yes, please let's have the egg back.

-- Gaby

Re: which cctool on Darwin?

[Jack Howarth]

Geoff,
   Would the ld64 in the cctools of Xcode 2.3 happen to resolve
PR 27121?
   Jack

Re: which cctool on Darwin?

[Geoffrey Keating]

On 05/06/2006, at 2:58 PM, Jack Howarth wrote:


Geoff,
   Would the ld64 in the cctools of Xcode 2.3 happen to resolve
PR 27121?
   Jack


27121 was originally reported as a bug which can only be resolved by  
cctools, not ld64 which is not part of cctools.  I see there was some  
additional commentary added to that bug after it was closed, trying  
to report a different issue.


However, yes, the ld64 in Xcode 2.3 will resolve the newly-reported  
problem.

smime.p7s
Description: S/MIME cryptographic signature

Re: GCC 4.2 Status Report (2006-06-04)

[Mark Mitchell]

Joern RENNECKE wrote:
> In http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html, you wrote:
> 
>> As fwprop is no longer on the table for 4.2, and as the vectorizer
>> improvements seem to have stalled due to a combination of lack of review
>> and Dorit's leave, I think it's time to declare 4.2 feature-complete.
> 
> I am still waiting for review of by auto-increment patches, and for Berndt
> to complete the cross-jump part struct-equiv patches, so that I can post an
> updated patch for the if-conversion part.

Depending on how quickly that goes, and how quickly other things go,
those things may or may not make 4.2.  We'll have to take it case by case.

> The patch queue also includes some patches for bugs that are not
> strictly speaking regressions.

As usual, I think we should permit the inclusion of already submitted
patches.

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

Re: which cctool on Darwin?

[Jack Howarth]

Geoff,
Could you update the cctools (particularly the source version)
in infrastructure to the newer version? Both Fink and OpenDarwin
build odcctools packages to insure that a current cctools is
available for their g95 and gcc packages regardless of what Xcode
is installed. Currently fink is building gcc 4.2 snapshots (to
provide macintel gfortran compilers) using --disable-multilib
because of the buggy ld64 in the version of cctools currently
in infrastructure.
  Jack

Re: which cctool on Darwin?

[Geoffrey Keating]

On 05/06/2006, at 6:09 PM, Jack Howarth wrote:


Geoff,
Could you update the cctools (particularly the source version)
in infrastructure to the newer version?


I see no reason to do this.

You can get the last released version of cctools at

along with much other open source.


Both Fink and OpenDarwin
build odcctools packages to insure that a current cctools is
available for their g95 and gcc packages regardless of what Xcode
is installed.


That's their choice, of course, but I wouldn't do that.  They run the  
risk that their cctools might be old and not capable of  
understanding, say, crt1.o.



Currently fink is building gcc 4.2 snapshots (to
provide macintel gfortran compilers) using --disable-multilib
because of the buggy ld64 in the version of cctools currently
in infrastructure.


There is no ld64 in any version of cctools.  There never has been.   
cctools only contains the 32-bit linker.  I do not intend to start  
providing ld64 updates unless I create a patch which requires one.

smime.p7s
Description: S/MIME cryptographic signature

Re: which cctool on Darwin?

[Jack Howarth]

Geoff,
   Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to build
it using the same fink packaging script used for odcctools. However I get
a build failure of...

cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp 
-fno-builtin-round -D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ 
-D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_  -static -DRLD -DSA_RLD 
-fno-builtin -finline -fno-keep-inline-functions -fsigned-bitfields 
-force_cpusubtype_ALL -msoft-float -nostdinc 
-I/System/Library/Frameworks/Kernel.framework/PrivateHeaders/libsa 
-I/System/Library/Frameworks/Kernel.framework/PrivateHeaders 
-I/System/Library/Frameworks/Kernel.framework/Headers/libsa 
-I/System/Library/Frameworks/Kernel.framework/Headers/bsd 
-I/System/Library/Frameworks/Kernel.framework/Headers -DKERNEL -DKERNEL_PRIVATE 
-DAPPLE -DNeXT -DLIBSA_PRIVATE -c \
-MD -dependency-file ./get_toc_byte_sex.d \
-o ./get_toc_byte_sex.o ../get_toc_byte_sex.c
../get_toc_byte_sex.c:25:16: error: ar.h: No such file or directory
../get_toc_byte_sex.c: In function 'get_toc_byte_sex':

which has been apparently been reported on the darwin lists without
replies...

http://lists.apple.com/archives/darwin-userlevel/2006/Jan/msg00016.html

Any suggestions for working around this problem?
Jack

Re: which cctool on Darwin?

[Geoffrey Keating]

On 05/06/2006, at 6:55 PM, Jack Howarth wrote:


Geoff,
   Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to  
build
it using the same fink packaging script used for odcctools. However  
I get

a build failure of...

cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp - 
fno-builtin-round - 
D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ - 
D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_  -static -DRLD - 
DSA_RLD -fno-builtin -finline -fno-keep-inline-functions -fsigned- 
bitfields -force_cpusubtype_ALL -msoft-float -nostdinc -I/System/ 
Library/Frameworks/Kernel.framework/PrivateHeaders/libsa -I/System/ 
Library/Frameworks/Kernel.framework/PrivateHeaders -I/System/ 
Library/Frameworks/Kernel.framework/Headers/libsa -I/System/Library/ 
Frameworks/Kernel.framework/Headers/bsd -I/System/Library/ 
Frameworks/Kernel.framework/Headers -DKERNEL -DKERNEL_PRIVATE - 
DAPPLE -DNeXT -DLIBSA_PRIVATE -c \

-MD -dependency-file ./get_toc_byte_sex.d \
-o ./get_toc_byte_sex.o ../get_toc_byte_sex.c
../get_toc_byte_sex.c:25:16: error: ar.h: No such file or directory
../get_toc_byte_sex.c: In function 'get_toc_byte_sex':

which has been apparently been reported on the darwin lists without
replies...

http://lists.apple.com/archives/darwin-userlevel/2006/Jan/ 
msg00016.html


Any suggestions for working around this problem?


You probably need to have Xcode 2.3 installed to build this version  
of cctools.  You may also need to use the 10.4u SDK or be working on  
an Intel machine (My installation of Xcode 2.3 has an ar.h in at  
least /Developer/SDKs/MacOSX10.4u.sdk/usr/include/ar.h).




smime.p7s
Description: S/MIME cryptographic signature

Recent VCG changes break gfortran's -std=f95 option

[Steve Kargl]

I have the simple program 

  program a
  call random_seed()
  end program a

in the files a.f90 and b.f90.  That is, a.f90 and b.f90
are identical.

gfortran -o a -fdump-tree-all a.f90 
gfortran -o b -fdump-tree-all -std=f95 b.f90 


--- a.f90.003t.original Mon Jun  5 19:09:22 2006
+++ b.f90.003t.original Mon Jun  5 19:09:15 2006
@@ -1,6 +1,6 @@
 MAIN__ ()
 {
-  _gfortran_set_std (70, 127, 0);
+  _gfortran_set_std (2, 11, 0);
   _gfortran_random_seed (0B, 0B, 0B);
 
 

--- a.f90.004t.gimple   Mon Jun  5 19:09:22 2006
+++ b.f90.004t.gimple   Mon Jun  5 19:09:15 2006
@@ -1,6 +1,6 @@
 MAIN__ ()
 {
-  _gfortran_set_std (70, 127, 0);
+  _gfortran_set_std (2, 11, 0);
   _gfortran_random_seed (0B, 0B, 0B);
 }
 

--- a.f90.007t.vcg  Mon Jun  5 19:09:22 2006
+++ b.f90.007t.vcg  Mon Jun  5 19:09:15 2006
@@ -3,7 +3,6 @@
 node: { title: "EXIT" label: "EXIT" }
 edge: { sourcename: "ENTRY" targetname: "2" linestyle: solid priority: 100 }
 
-node: { title: "2" label: "#2\ncall_expr (1)\nreturn_expr (2)"}
-edge: { sourcename: "2" targetname: "EXIT" priority: 100 linestyle: solid }
+node: { title: "2" label: "#2\ncall_expr (1)\ncall_expr (2)"}
 }
 

--- a.f90.022t.cfg  Mon Jun  5 19:09:22 2006
+++ b.f90.022t.cfg  Mon Jun  5 19:09:15 2006
@@ -5,10 +5,9 @@
 {
   # BLOCK 2
   # PRED: ENTRY (fallthru)
-  _gfortran_set_std (70, 127, 0);
+  _gfortran_set_std (2, 11, 0);
   _gfortran_random_seed (0B, 0B, 0B);
-  return;
-  # SUCC: EXIT
+  # SUCC:
 
 }
 

These last two seem to be related to the infinite recursion 
that I see.  The diff for the assembly is

--- a.s Mon Jun  5 19:25:59 2006
+++ b.s Mon Jun  5 19:26:12 2006
@@ -1,4 +1,4 @@
-   .file   "a.f90"
+   .file   "b.f90"
.text
 .globl MAIN__
.type   MAIN__, @function
@@ -9,15 +9,13 @@
movq%rsp, %rbp
 .LCFI1:
movl$0, %edx
-   movl$127, %esi
-   movl$70, %edi
+   movl$11, %esi
+   movl$2, %edi
call_gfortran_set_std
movl$0, %edx
movl$0, %esi
movl$0, %edi
call_gfortran_random_seed
-   leave
-   ret
 .LFE2:
.size   MAIN__, .-MAIN__
.section.eh_frame,"a",@progbits

The absense of "leave" and "ret" can't be a Good Thing.

-- 
Steve

Re: Recent VCG changes break gfortran's -std=f95 option

[Andrew Pinski]

> 
> I have the simple program 
> 
>   program a
>   call random_seed()
>   end program a

Something is marking random_seed as noreturn.

-- Pinski

Re: Recent VCG changes break gfortran's -std=f95 option

[Steve Kargl]

On Mon, Jun 05, 2006 at 10:33:40PM -0400, Andrew Pinski wrote:
> > 
> > I have the simple program 
> > 
> >   program a
> >   call random_seed()
> >   end program a
> 
> Something is marking random_seed as noreturn.

OK, so where do I start to look?   AFAICT, this
problem only occurs if -std=f95, and intrinsics/random.c
does not use the flag.

-- 
Steve

Re: which cctool on Darwin?

[Shantonu Sen]

Building cctools from source is like stabbing yourself in the kidney.  
You should use darwinbuild if you want to build the Apple-provided  
source only, or use odcctools if you want additional portability  
patches to build on multiple OSes and versions and have relocatable -- 
prefix support.


I've already imported Apple cctools-590.42.1 and Apple ld64-47.2 into  
odcctools CVS, and will release a snapshot after some more work.


Shantonu

On Jun 5, 2006, at 7:08 PM, Geoffrey Keating wrote:



On 05/06/2006, at 6:55 PM, Jack Howarth wrote:


Geoff,
   Okay. I downloaded the cctools-590.42.1.tar.gz and attempted to  
build
it using the same fink packaging script used for odcctools. However  
I get

a build failure of...

cc -O -g -I../../include -Wall -Wno-long-double -no-cpp-precomp - 
fno-builtin-round - 
D_MACH_I386_THREAD_STATUS_FPSTATE_LEGACY_FIELD_NAMES_ - 
D_ARCHITECTURE_I386_FPU_FPSTATE_LEGACY_FIELD_NAMES_  -static -DRLD - 
DSA_RLD -fno-builtin -finline -fno-keep-inline-functions -fsigned- 
bitfields -force_cpusubtype_ALL -msoft-float -nostdinc -I/System/ 
Library/Frameworks/Kernel.framework/PrivateHeaders/libsa -I/System/ 
Library/Frameworks/Kernel.framework/PrivateHeaders -I/System/ 
Library/Frameworks/Kernel.framework/Headers/libsa -I/System/Library/ 
Frameworks/Kernel.framework/Headers/bsd -I/System/Library/ 
Frameworks/Kernel.framework/Headers -DKERNEL -DKERNEL_PRIVATE - 
DAPPLE -DNeXT -DLIBSA_PRIVATE -c \

-MD -dependency-file ./get_toc_byte_sex.d \
-o ./get_toc_byte_sex.o ../get_toc_byte_sex.c
../get_toc_byte_sex.c:25:16: error: ar.h: No such file or directory
../get_toc_byte_sex.c: In function 'get_toc_byte_sex':

which has been apparently been reported on the darwin lists without
replies...

http://lists.apple.com/archives/darwin-userlevel/2006/Jan/msg00016.html

Any suggestions for working around this problem?


You probably need to have Xcode 2.3 installed to build this version  
of cctools.  You may also need to use the 10.4u SDK or be working on  
an Intel machine (My installation of Xcode 2.3 has an ar.h in at  
least /Developer/SDKs/MacOSX10.4u.sdk/usr/include/ar.h).

Re: Where is the egg?

[Stephan T. Lavavej]

[Steven Bosscher]
> But is it really necessary to remove the egg too?
> Can we have it back? Pleaeaeaeaese? :-)

[Gabriel Dos Reis]
> yes, please let's have the egg back.

If y'all need a differently sized egg, I can generate one. (I was the one
who traced the old JPEG to make the clean PNG.) I've still got the high-res
master lying around.

Boy, my hand was shaky back then.

Stephan T. Lavavej

Re: [wwwdocs] Complete revamp of our web site

[Andrew Pinski]

On Jun 5, 2006, at 2:26 PM, DJ Delorie wrote:




Feedback welcome!


Right-side navigation bars are nonstandard.  It should be moved to the
left side.  Don't accept the search engine excuse; that's easily
fixable.  Also, by fixing the search engine issue you punish Lynx
users; the navigation menu is now near (but not at) the end of the
text.


I was going to say the same thing.

Also what about moving the News up to a noticeable spot since right now
it is down in a corner so it looks out of place.  In fact on my screen
which is set to 1024x768, I have to scroll to get to the news.

The release info should be at the same level as the news.

Thanks,
Andrew Pinski

Re: [MinGW] Set NATIVE_SYSTEM_HEADER_DIR relative to configured prefix

[Ross Ridge]

Ranjit Mathew wrote:
> Danny, I'm using the same configure flags that you have used for GCC
>3.4.5 MinGW release (*except* for --prefix=/mingw, which is something
>like --prefix=/j/mingw/mgw for me), but the GCC I get is not relocatable
>at all, while I can put the MinGW GCC 3.4.5 release anywhere on the
>filesystem and it still works. :-(

The GCC I get from my native MinGW build of the trunk is relocatable:

e:\util\mygcc.new\bin\gcc -v -E -o nul -x c x.c
Using built-in specs.
Target: mingw32
Configured with: ../gcc/configure --prefix=/src/gcc/runtime --target=mingw32 
--host=mingw32 --enable-languages=c,c++ --enable-threads=win32 
--with-win32-nlsapi=unicode --enable-bootstrap --disable-werror 
--with-ld=/src/gcc/runtime/bin/ld --with-as=/src/gcc/runtime/bin/as
Thread model: win32
gcc version 4.2.0 20060513 (experimental)
 e:/util/mygcc.new/bin/../libexec/gcc/mingw32/4.2.0/cc1.exe -E -quiet -v 
-iprefix e:\util\mygcc.new\bin\../lib/gcc/mingw32/4.2.0/ x.c -o nul.exe 
-mtune=i386
ignoring nonexistent directory 
"e:/util/mygcc.new/bin/../lib/gcc/mingw32/4.2.0/../../../../mingw32/include"
ignoring nonexistent directory "/src/gcc/runtime/include"
ignoring nonexistent directory "/src/gcc/runtime/include"
ignoring nonexistent directory "/src/gcc/runtime/lib/gcc/mingw32/4.2.0/include"
ignoring nonexistent directory "/src/gcc/runtime/mingw32/include"
ignoring nonexistent directory "/mingw/include"
#include "..." search starts here:
#include <...> search starts here:
 e:/util/mygcc.new/bin/../lib/gcc/mingw32/4.2.0/../../../../include
 e:/util/mygcc.new/bin/../lib/gcc/mingw32/4.2.0/include
End of search list.

It picks up the "system include directory" without a problem.  What
exactly is the error you're getting that indicates that your compiled
version of GCC isn't relocatable?

Ross Ridge

Re: [MinGW] Set NATIVE_SYSTEM_HEADER_DIR relative to configured prefix

[Ross Ridge]

Ross Ridge wrote:
>The GCC I get from my native MinGW build of the trunk is relocatable:

Hmm... I should have sent that to gcc-patches, sorry.

Ross Ridge

Re: Modifying ARM code generator for elimination of 8bit writes - need help

[Wolfgang Mües]

Rask,

On Monday 05 June 2006 16:16, Rask Ingemann Lambertsen wrote:
> On Mon, Jun 05, 2006 at 01:47:10PM +0200, Wolfgang Mües wrote:
> Does GCC happen to accept "[%r, #0]" for swp?

No. But no problem here to change that.

> I think the comment in arm.h is wrong. The manual seems to agree with
> the code.

Just to make it easy for beginners...

> I tried 'V' instead, but it looks as if reload completely ignores the
> meaning of the constraint. There is already a comment in arm.md about
> that. It should be investigated further.

Hmmm... I have searched 'Q' in the arm files. Not used in arm.md, only 
for some variants of arm (cirrus). Maybe only implemented for them?

> Meanwhile, I changed arm_legitimate_address_p() to enforce the
> correct address form. This hurts byte loads too, though.

I assume there is no way to tell the direction in 
arm_legitimate_address_p() ? Hmmm.

> Index: gcc/config/arm/arm.opt
> ===
> --- gcc/config/arm/arm.opt(revision 114119)
> +++ gcc/config/arm/arm.opt(working copy)
> @@ -153,3 +153,7 @@
>  mwords-little-endian
>  Target Report RejectNegative Mask(LITTLE_WORDS)
>  Assume big endian bytes, little endian words
> +
> +mswp-byte-writes
> +Target Report Mask(SWP_BYTE_WRITES)
> +Use the swp instruction for byte writes

In my environment (gcc 4.0.2), this is different. But I was able to find 
the definitions in arm.h and implement these changes. Easyer than 
expected...

(The DSLINUX team is not using gcc 4.1 because of compile problems with 
the 2.6.14er kernel).

> +   swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"

You should get a price for cleverness here!

> +; Avoid reading the stored value back if we have a spare register.
> +(define_peephole2
> +  [(match_scratch:QI 2 "r")
> +   (set (match_operand:QI 0 "memory_operand" "")
> +(match_operand:QI 1 "register_operand" ""))]
> +  "TARGET_ARM && TARGET_SWP_BYTE_WRITES"
> +  [(parallel [
> +(set (match_dup 0) (match_dup 1))
> +(clobber (match_dup 2))]
> +  )]
> +)

As far as I can tell now, this works good. But I think there are many 
cases in which the source operand is not needed after the store. Is 
there a possibility to clobber the source operand and not using another 
register?

Hmmm. Most of the code I have seen in the first tests have no problem 
with this extra register...it's available.

> With -O2 -mswp-byte-writes:
>
> bytewritetest:
>   @ args = 0, pretend = 0, frame = 0
>   @ frame_needed = 0, uses_anonymous_args = 0
>   str lr, [sp, #-4]!
>   add r2, r0, #4
>   add lr, r0, #5
>   ldrbr3, [lr, #0]@ zero_extendqisi2
>   ldrbr1, [r2, #0]@ zero_extendqisi2
>   eor r2, r1, r3
>   add r3, r3, r1
>   ldr ip, [r0, #0]
>   str r3, [r0, #0]
>   swpbr3, r2, [lr, #0]
>   str ip, [r0, #8]
>   ldr pc, [sp], #4
>
>
> The register allocator chooses to use the lr register, in turn
> causing link register save alimination to fail, which doesn't help.

I can't understand this without explanation... is it bad?

Rask, thank you very much for your work.

regards
Wolfgang
-- 
We're back to the times when men were men 
and wrote their own device drivers.

(Linus Torvalds)

Re: Recent VCG changes break gfortran's -std=f95 option

[FX Coudert]

Something is marking random_seed as noreturn.


As far as I understand, symbols are marked as noreturn by use of  
TREE_THIS_VOLATILE, which is done on a few selected trees and is also  
done whenever a symbol has the noreturn attribute. This noreturn  
attribute can be set to 1 by make_noreturn, but nothing ever sets it  
to 0, which is probably why we're experiencing this problem.


I have to go and not enough time to check it in detail, but perhaps  
we should change that here:


Index: intrinsic.c
===
--- intrinsic.c (revision 114340)
+++ intrinsic.c (working copy)
@@ -254,6 +254,7 @@
   next_sym->resolve = resolve;
   next_sym->specific = 0;
   next_sym->generic = 0;
+  next_sym->attr.noreturn = 0;
   break;
 default:

Re: Recent VCG changes break gfortran's -std=f95 option

[FX Coudert]

My first patch didn't even compile :(

Here's a new one.


Something is marking random_seed as noreturn.


As far as I understand, symbols are marked as noreturn by use of  
TREE_THIS_VOLATILE, which is done on a few selected trees and is  
also done whenever a symbol has the noreturn attribute. This  
noreturn attribute can be set to 1 by make_noreturn, but nothing  
ever sets it to 0, which is probably why we're experiencing this  
problem.


I have to go and not enough time to check it in detail, but perhaps  
we should change that here:


Index: intrinsic.c
===
--- intrinsic.c (revision 114340)
+++ intrinsic.c (working copy)
@@ -254,6 +254,7 @@
   next_sym->resolve = resolve;
   next_sym->specific = 0;
   next_sym->generic = 0;
+  next_sym->noreturn = 0;
   break;
 default: