headers
John David Anglin | 1 Sep 2005 04:37
Picon

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

> Used full distribution + make bootstrap. Used egcs-2.91.57 and binutils-2.11.2 to compile gcc.

If you are interested in much improved C++ support, upgrade binutils to
2.16 or later and rebuild GCC with the new binutils.  This provides
one-only support under HP-UX 10.20.  You also need the latest (last)
HP linker patch for 10.20.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 501 comments |
headers
Peter O'Gorman | 1 Sep 2005 05:16
Favicon
Gravatar

Re: Running ranlib after installation - okay or not?


Gerald Pfeifer wrote:
|>
|>Except that probably this has to get into libtool somehow or
|>something.  Hmmm.
|
|
| Ouch, now you got me scared.  I already started testing a patch to remove
| the ranlib invocations that are part of the installation, but I'm afraid
| that level of configury work described above execeed what I feel confident
| hacking.
|
| Is anyone else going to give it a try, or should it just file a Bugzilla?

Hi,
The problem is that libtool tries to run ranlib after install and that
ranlib can fail if the library is not writable? Note that on darwin running
ranlib on a 444 lib works and changes permissions to 644, remind me to file
a bug.

I would suggest continuing to run ranlib after install, but not failing if
it does not work. You need to look for the variable old_postinstall_cmds in
libtool.m4 and ltmain.m4sh (ltconfig and ltmain.sh in gcc??) and change
either how it is set or how it is run.

Another alternative would be to set RANLIB=: before configure if your system
does not need to ranlib anything.

Hope this helps,
Peter
(Continue reading)

Permalink | Reply | 14 comments |
headers
Peter O'Gorman | 1 Sep 2005 07:09
Favicon
Gravatar

Re: Running ranlib after installation - okay or not?


Peter O'Gorman wrote:
| The problem is that libtool tries to run ranlib after install and that
| ranlib can fail if the library is not writable?

[crosspost - beware - for context see
<http://gcc.gnu.org/ml/gcc/2005-08/msg00937.html>]

When I look more closely at this, I see in libtool.m4:
old_postinstall_cmds='chmod 644 $oldlib'

and a little later:
old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"

Should that be:
old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
??

Peter
Permalink | Reply | 5 comments |
headers
frankj | 1 Sep 2005 07:44

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

On Wed, 31 Aug 2005, John David Anglin wrote:
>> Used full distribution + make bootstrap. Used egcs-2.91.57 and binutils-2.11.2 to compile gcc.
>
> If you are interested in much improved C++ support, upgrade binutils to
> 2.16 or later and rebuild GCC with the new binutils.  This provides
> one-only support under HP-UX 10.20.  You also need the latest (last)
> HP linker patch for 10.20.

Thanks!  Do you know if this includes pthreads support in C++?

-Frank.
Permalink | Reply | 501 comments |
headers
Paolo Bonzini | 1 Sep 2005 09:24
Picon

Re: Regarding bug 22480, vectorisation of shifts

Uros Bizjak wrote (privately, but I forwarded to GCC in order to get help):

>Hello Paolo!
>
>I was looking at PR middle-end/22480 if there is something to fix at the i386 
>backend. However, there is no documentation at all regarding vec_shl_≤mode> and 
>vec_shr_≤mode> builtins.
>  
>
Heh, I'm quite at a loss regarding PR22480.  I don't know exactly what 
to do because i386 does not support, e.g. { 2, 4 } << { 1, 2 } (which 
would give {4, 16} as a result).  There is indeed a back-end problem, 
because ashl<mode>3 is supposed to have two operands of the same mode, 
not one vector and one SI!

On the other hand, I'm not keen on using vec_shl_≤mode> because these 
shift the *whole* register, not each byte/word/dword. i.e. { 0x40000000, 
0x80000000 } << 2 = { 2, 0 } which is not really what is expected.

One simple way to fix the PR could be *not* to define ashl<mode>3 insns 
for i386.  These however would lose vectorization of a shift by     
constant.

Another way could be to

1) in the vectorizer, check in the optab if the predicate for each 
operand of an insn accepts a register.  If not, refuse vectorization if 
the corresponding gimple operand is not constant.

2) and add a new predicate to i386 that only accepts CONST_VECTORs whose
(Continue reading)

Permalink | Reply | 2 comments |
headers
Eric Fisher | 1 Sep 2005 10:42
Picon

porting gcc can't compile libgcc2.c

Hello,

Here is a question about porting gcc.  After I modified machine.md and
other backend files, I can make cc1 and xgcc now. But libgcc2.o still
failed. I'd like to know does we must make libgcc2.o since the target
machine don't have float registers and 64bit registers.

Thanks a lot.

Eric
Permalink | Reply | 1 comment |
headers
Daniel Towner | 1 Sep 2005 12:12
Favicon

Incorrect use of anti-dependency to order instructions in the DFA scheduler

Hi all,

I maintain a port for a 16-bit VLIW machine, and I have encountered a 
problem with the DFA instruction scheduler. Consider the following two 
instructions:

BNE someLabel
STW R5,(R3) 0  // Mem[R3] := R5

The second instruction will only be executed if the branch isn't taken. 
However, when I switch on the DFA scheduler, the memory store is 
scheduled in the same cycle as the branch, using VLIW:

BNE someLabel    \    STW R5,R3(0)

which obviously changes the meaning of the code, as the store is now 
always performed, whereas previously it was conditional. I believe that 
this incorrect schedule is caused because an anti-dependence is used to 
enforce the ordering of the two instructions, and a VLIW machine allows 
anti-dependent instructions to be scheduled in the same cycle. I have 
attached the RTL code showing this anti-dependency below.

The problem isn't limited to having a memory store instruction following 
the branch. I see the same problem with other types of instruction as well.

Why is an anti-dependence used to enforce the ordering of the branch and 
the subsequent instruction? What type of dependency should I use 
instead, and if I changed it, would this break other ports?

thanks,
(Continue reading)

Permalink | Reply | 3 comments |
headers
Dave Korn | 1 Sep 2005 12:16
Favicon

RE: porting gcc can't compile libgcc2.c

----Original Message----
>From: Eric Fisher
>Sent: 01 September 2005 09:43

> Hello,
> 
> Here is a question about porting gcc.  After I modified machine.md and
> other backend files, I can make cc1 and xgcc now. But libgcc2.o still
> failed. I'd like to know does we must make libgcc2.o since the target
> machine don't have float registers and 64bit registers.
> 
> Thanks a lot.
> 
> Eric

  If it doesn't have float registers, get libgcc2 to use fp emulation:

-----------------------------<snip>-----------------------------
File: gccint.info,  Node: Target Fragment,  Next: Host Fragment,  Up:
Fragments

Target Makefile Fragments
=========================

   Target makefile fragments can set these Makefile variables.
-----------------------------<snip>-----------------------------
`Floating Point Emulation'
     To have GCC include software floating point libraries in `libgcc.a'
     define `FPBIT' and `DPBIT' along with a few rules as follows:
          # We want fine grained libraries, so use the new code
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 1 Sep 2005 13:52
Picon
Picon

Re: Running ranlib after installation - okay or not?

Hi Peter,

* Peter O'Gorman wrote on Thu, Sep 01, 2005 at 07:09:35AM CEST:
> Peter O'Gorman wrote:
> | The problem is that libtool tries to run ranlib after install and that
> | ranlib can fail if the library is not writable?

Thanks for the pointer.

> When I look more closely at this, I see in libtool.m4:
> old_postinstall_cmds='chmod 644 $oldlib'
> 
> and a little later:
> old_postinstall_cmds="\$RANLIB \$oldlib~$old_postinstall_cmds"
> 
> Should that be:
> old_postinstall_cmds="$old_postinstall_cmds~\$RANLIB \$oldlib"
> ??

Yes, I believe so (both CVS HEAD and branch-1-5).
Unless there exists ranlib's that change file mode..

> > The problem is that libtool tries to run ranlib after install and
> > that ranlib can fail if the library is not writable? Note that on
> > darwin running ranlib on a 444 lib works and changes permissions to
> > 644, remind me to file a bug.

Hmm.  The change to 644 should be OK.  What happens to libraries with
other modes (say, not group- or world-readable)?  So how about changing
the order as you suggest above, and filing a bug with darwin ranlib?
(Continue reading)

Permalink | Reply | 2 comments |
headers
John David Anglin | 1 Sep 2005 15:23
Picon

Re: Successfull gcc-3.4.4 build on hppa1.1-hp-hpux10.20

> Thanks!  Do you know if this includes pthreads support in C++?

There's support for the older DCE threads in 10.X.  This is dropped
in 11.X, but there's POSIX thread support.

Dave
--

-- 
J. David Anglin                                  dave.anglin <at> nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)
Permalink | Reply | 0 comments |

Gmane