Re: Change x86 default arch for 4.5?

[Piotr Wyderski]

H.J. Lu wrote:

> Default to SSE2 is a good first step.

I concur; all the programs I'm working on
require SSE2 and are not supposed to be
back-portable to SSE or fpu. Simply too
many vital optimizations require that ISA.

Best regards
Piotr Wyderski

Re: is -fno-toplevel-reorder going to deprecate

[Richard Guenther]

On Mon, Feb 22, 2010 at 9:21 PM, Ian Lance Taylor  wrote:
> Sergey Yakoushkin  writes:
>
>> I'm cross-compiling glibc(eglibc) for new processor.
>> As far as I can see -fno-toplevel-reorder option is critical for
>> successful build.
>> Without option some files (initfini.c, source for crt*.o) can be miscompiled.
>>
>> I've heard that option might become deprecated in future gcc versions
>> (e.g. 4.6).
>> Although, I don't have any evidence. Could you please clarify?
>
> Where did you hear that?
>
> I have not heard of any plans to deprecate -fno-toplevel-reorder.  As
> you say, it is required for certains kinds of use.  The gcc build even
> uses it itself.
>
> It's possible that you have this confused with -fno-unit-at-a-time.
> That option is deprecated.  It is being replaced with
> -fno-toplevel-reorder and -fno-section-anchors.

-fno-toplevel-reorder is something that will likely not work with
link-time optimization for example.  Though we could simply
mark units compiled with -fno-toplevel-reorder ineligible for LTO.

Richard.

> Ian
>

Re: PR 42485 Delete both -b and -V options

[Richard Guenther]

On Tue, 23 Feb 2010, Manuel López-Ibáñez wrote:

> Bootstrapped and regression tested (it seems nothing was testing these
> options) on x86_64-unknown-linux-gnu.
> 
> OK?

This is ok if nobody has serious objections and at the same time
is willing to either fix these options for 4.5 or at least show
that they do work when special care is taken at configure and
install time and is willing to document those restrictions.

Please wait 48h to give people a chance and wait until an
eventual discussion dies down.

I just want to note that we as a GCC distributor use --program-suffix
to get different GCC versions to install in parallel but have
local patches to suffix manual and info pages and to have a versioned
textdomain namespace for localiztion (like Debian does, most patches
shamelessly copied from them).  We also install cross-compiler
drivers with transformed program names.

Thanks,
Richard.

> 2010-02-23  Manuel López-Ibáñez  
> 
>   PR 42485
>   * doc/invoke.texi (-b,-V): Delete.
>   * gcc.c (display_help): Delete -b and -V.
>   (process_command): Delete -b and -V.
>   * gcc.h (DEFAULT_SWITCH_TAKES_ARG): Delete -b and -V.

Re: PR 42485 Delete both -b and -V options

[Manuel López-Ibáñez]

On 23 February 2010 12:00, Richard Guenther  wrote:
> On Tue, 23 Feb 2010, Manuel López-Ibáñez wrote:
>
>> Bootstrapped and regression tested (it seems nothing was testing these
>> options) on x86_64-unknown-linux-gnu.
>>
>> OK?
>
> This is ok if nobody has serious objections and at the same time
> is willing to either fix these options for 4.5 or at least show
> that they do work when special care is taken at configure and
> install time and is willing to document those restrictions.
>
> Please wait 48h to give people a chance and wait until an
> eventual discussion dies down.

Actually, I haven't tested that -b does not work. I don't have any
cross-compiler or want to build one. Could any one test that?

I see that several Debian packages use (or have used) -b  but perhaps
those are fixed already.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318750

Cheers,

Manuel.

Re: Register Allocation Pref. in 3.3.3

[Paulo J. Matos]

On Mon, Feb 22, 2010 at 2:12 PM, Joern Rennecke
 wrote:
> Quoting "Paulo J. Matos" :
>
>> Hi,
>>
>> For anyone who still remembers what went on with 3.3.3, in global.c,
>> set_preference, why is there a bias to set preference for operand 0 of
>> src?
>
> I don't remember the detail of this specific code, but in general operand 0
> is mostly used as an output operand; if an output operand can be assigned
> a register, it is likely to be needed in a subsequent instruction to do
> something with it.
>

That would make sense if the rtx is a set but in this case it is not.
local-alloc.c:set_preference, line 1612 in particular, is called with:
CALL set_preference
dest:
(reg/f:QI 31)
src:
(plus:QI (reg/f:QI 6 Y)
(reg:QI 215))

operator[0] is a register, as is operator[1] of src. So what's the
reason for the bias?

>> - Does the order in which define_insn and define_expand rules show up
>> in the .md file bias the compiler to choose a rule in one way or the
>> other?
>
> You may not have more than one pattern with the same name.  define_insn
> patterns will not be used for instruction pattern nor split point
> recognition.
>
>> - If two define_insn patterns match the same insn, which one will be used?
>
> The first one to be recognized.  This is not necessarily the same as the
> first
> one in the file, because insn code numbers are cached, and in general not
> recomputed during or after reload.  If the insn code caching has an effect
> on eventual instruction selection, it is usually a bug in the machine
> description.
>

Thanks for the reply.

-- 
PMatos

Conditional clobbering

[Paulo J. Matos]

Hi all,

I have a situation in writing a specific condition on an md file.
I have an insn with 2 alternatives and then I use which_alternative to
generate the assembler code but if which_alternative == 1 I am
clobbering a register. How can I tell gcc that if it matches 1, a
given register is clobbered?

Cheers,

-- 
PMatos

Re: Register Allocation Pref. in 3.3.3

[Dave Korn]

On 23/02/2010 13:23, Paulo J. Matos wrote:

> That would make sense if the rtx is a set but in this case it is not.
> local-alloc.c:set_preference, line 1612 in particular, is called with:
> CALL set_preference
> dest:
> (reg/f:QI 31)
> src:
> (plus:QI (reg/f:QI 6 Y)
> (reg:QI 215))

  So precisely what are those the "src" and "dest" of, then, if not a set rtx?

cheers,
  DaveK

Re: Register Allocation Pref. in 3.3.3

[Paulo J. Matos]

On Tue, Feb 23, 2010 at 2:26 PM, Dave Korn
 wrote:
> On 23/02/2010 13:23, Paulo J. Matos wrote:
>
>> That would make sense if the rtx is a set but in this case it is not.
>> local-alloc.c:set_preference, line 1612 in particular, is called with:
>> CALL set_preference
>> dest:
>> (reg/f:QI 31)
>> src:
>> (plus:QI (reg/f:QI 6 Y)
>>             (reg:QI 215))
>
>  So precisely what are those the "src" and "dest" of, then, if not a set rtx?
>

Well, the dest and src are from a set, but the line setting preference
on operands[0] is doing it on the operands of src. So operand[0] of
src is (reg/f:QI 6 Y)!

>    cheers,
>      DaveK
>
>



-- 
PMatos

Hunting backend bugs

[garbett peter]

Hello there, this is my 1st post.

I have become responsible for a private port of GCC to a custom microprocessor.
It is a relatively simple 32 bit risc with delay slots.

I have modified the gcc 3.4.4 port to work against gcc 4.4.3.
This gives correct results against a set of gnat Ada acats tests,
but only for a limited set of optimizations.

An attempt to port to trunk results in an ICE when
 attempting to compile libgcc2
I am running binutils 2.20 and newlib 1.18.0, and
building as a combined tree.
I am running the autotools etc mentioned in the binutils
 README-maintainer mode and use --enable-maintaner-mode and
have used autoupdate/autoreconf

A closer look shows the code is in a infinite loop in dojump,
 ending in a segmentation fault.  I am using a host/build x84_64 machine.
Doing a binary chop on the libgcc2.c source shows it's the
lines containing the call __umulsidi3 (line 566) that cause the
problem to exhibit itself.

I have a some questions

1) What's the best way of finding out if the faults are down to my backend code?
2) Are the behaviors seen above at least consistent with the
immaturity of 4.4.3 and trunk?
i.e. should I just keep trying latest trunk?

3) How do I find out if I have missed something needed
to support __umulsidi3 (etc, similar items also crash)

Posting decent fault reports would not seem to be an option, unless I
 could exhibit the same faults on a supported architecture.

Re: PR 42485 Delete both -b and -V options

[Matthias Klose]

On 23.02.2010 12:10, Manuel López-Ibáñez wrote:

On 23 February 2010 12:00, Richard Guenther  wrote:

On Tue, 23 Feb 2010, Manuel López-Ibáñez wrote:


Bootstrapped and regression tested (it seems nothing was testing these
options) on x86_64-unknown-linux-gnu.

OK?


This is ok if nobody has serious objections and at the same time
is willing to either fix these options for 4.5 or at least show
that they do work when special care is taken at configure and
install time and is willing to document those restrictions.

Please wait 48h to give people a chance and wait until an
eventual discussion dies down.


Actually, I haven't tested that -b does not work. I don't have any
cross-compiler or want to build one. Could any one test that?

I see that several Debian packages use (or have used) -b  but perhaps
those are fixed already.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=318750


the given example uses this upstream, not just in the package. I didn't see many 
uses of this. However distributions tend to patch around this.


As a plus, removing -V could allow for not-changing paths in an installation 
across subminor releases.


  Matthias

Re: Register Allocation Pref. in 3.3.3

[Michael Matz]

Hi,

On Tue, 23 Feb 2010, Paulo J. Matos wrote:

> On Tue, Feb 23, 2010 at 2:26 PM, Dave Korn
>  wrote:
> > On 23/02/2010 13:23, Paulo J. Matos wrote:
> >
> >> That would make sense if the rtx is a set but in this case it is not.
> >> local-alloc.c:set_preference, line 1612 in particular, is called with:
> >> CALL set_preference
> >> dest:
> >> (reg/f:QI 31)
> >> src:
> >> (plus:QI (reg/f:QI 6 Y)
> >>             (reg:QI 215))
> >
> >  So precisely what are those the "src" and "dest" of, then, if not a set 
> > rtx?
> >
> 
> Well, the dest and src are from a set, but the line setting preference
> on operands[0] is doing it on the operands of src. So operand[0] of
> src is (reg/f:QI 6 Y)!

First I note that set_preference's comment explicitely says that it's not 
as aggressive as local-alloc in tying register operands together.  Then 
there might be at least the following reasons of why it looks at only the 
first source operand:

1) easier code: there will always be at least one operands for each RTX 
   that goes into src'set_preference.  To access the other codes you would 
   also have to check the length (i.e. if src is binary)
2) faster compile time: checking both operands of a binary is slower
3) two-address machines: Even though binary sets in RTL are three-address 
   form, some popular machines actually are two-address in hardware, with 
   the patterns usually (not always, though) written such that the first 
   source is to be placed into the same reg as the destination.  Hence, if 
   we want to look at only one operand, it usually is better to tie the 
   first source with the dest.  Tieing the second source with dest on a 
   two-address machine, on a non-commutative operation (e.g. minus) 
   actually then would generate worse code than tieing the first with dest 
   due to the necessary shuffle copies.

Especially (3) probably made it look worthless to try exceptionally hard 
to tie the second source with dest.


Ciao,
Michael.

How to update my SSH authorized_keys on gcc.gnu.org?

[H.J. Lu]

Hi,

Is there a way to update my SSH authorized_keys on gcc.gnu.org? I
tried

# scp -p authorized_keys gcc.gnu.org:.ssh/
Warning: Permanently added the RSA host key for IP address
'209.132.180.131' to the list of known hosts.
Permission denied (publickey,gssapi-with-mic).
lost connection

It didn't work.

Thanks.

-- 
H.J.

Re: How to update my SSH authorized_keys on gcc.gnu.org?

[Andreas Schwab]

"H.J. Lu"  writes:

> Is there a way to update my SSH authorized_keys on gcc.gnu.org?

See .

Andreas.

-- 
Andreas Schwab, sch...@redhat.com
GPG Key fingerprint = D4E8 DBE3 3813 BB5D FA84  5EC7 45C6 250E 6F00 984E
"And now for something completely different."

Re: How to update my SSH authorized_keys on gcc.gnu.org?

[Tobias Burnus]

Hi,

> Is there a way to update my SSH authorized_keys on gcc.gnu.org? I
> tried

As written at http://sourceware.org/cgi-bin/pdw/ps_form.cgi

ssh sourceware.org updatekey < ~/.ssh/id_dsa.pub

should do the deed.

Tobias

Re: How to update my SSH authorized_keys on gcc.gnu.org?

[H.J. Lu]

On Tue, Feb 23, 2010 at 9:22 AM, Andreas Schwab  wrote:
> "H.J. Lu"  writes:
>
>> Is there a way to update my SSH authorized_keys on gcc.gnu.org?
>
> See .
>

It doesn't work for me:

# ssh sourceware.org replacekey  < authorized_keys
Permission denied(publickey,gssapi-with-mic).

-- 
H.J.

Re: How to update my SSH authorized_keys on gcc.gnu.org?

[H.J. Lu]

On Tue, Feb 23, 2010 at 9:26 AM, Tobias Burnus  wrote:
> Hi,
>
>> Is there a way to update my SSH authorized_keys on gcc.gnu.org? I
>> tried
>
> As written at http://sourceware.org/cgi-bin/pdw/ps_form.cgi
>
> ssh sourceware.org updatekey < ~/.ssh/id_dsa.pub
>
> should do the deed.
>

Does it work for anyone? I got

# ssh sourceware.org updatekey < ~/.ssh/id_dsa.pub
Permission denied (publickey,gssapi-with-mic).



-- 
H.J.

Re: How to update my SSH authorized_keys on gcc.gnu.org?

[Christopher Faylor]

On Tue, Feb 23, 2010 at 09:27:35AM -0800, H.J. Lu wrote:
>On Tue, Feb 23, 2010 at 9:22 AM, Andreas Schwab  wrote:
>> "H.J. Lu"  writes:
>>
>>> Is there a way to update my SSH authorized_keys on gcc.gnu.org?
>>
>> See .
>>
>
>It doesn't work for me:
>
># ssh sourceware.org replacekey  < authorized_keys
>Permission denied(publickey,gssapi-with-mic).

That would imply that you are not using the right ssh key to access
sourceware.  You (of course?) need to be able to access the system to
execute the replacekey command.

cgf

Re: How to update my SSH authorized_keys on gcc.gnu.org?

[H.J. Lu]

On Tue, Feb 23, 2010 at 9:35 AM, Christopher Faylor
 wrote:
> On Tue, Feb 23, 2010 at 09:27:35AM -0800, H.J. Lu wrote:
>>On Tue, Feb 23, 2010 at 9:22 AM, Andreas Schwab  wrote:
>>> "H.J. Lu"  writes:
>>>
 Is there a way to update my SSH authorized_keys on gcc.gnu.org?
>>>
>>> See .
>>>
>>
>>It doesn't work for me:
>>
>># ssh sourceware.org replacekey  < authorized_keys
>>Permission denied(publickey,gssapi-with-mic).
>
> That would imply that you are not using the right ssh key to access
> sourceware.  You (of course?) need to be able to access the system to
> execute the replacekey command.
>

It works now.

Thanks.


-- 
H.J.

Re: Hunting backend bugs

[Joern Rennecke]

Quoting garbett peter :

1) What's the best way of finding out if the faults are down to my   
backend code?


It's most likely down to the lack thereof, in particular the lack of multiply
named patterns.  See md.texi .

Re: Conditional clobbering

[Joern Rennecke]

Quoting "Paulo J. Matos" :

I have a situation in writing a specific condition on an md file.
I have an insn with 2 alternatives and then I use which_alternative to
generate the assembler code but if which_alternative == 1 I am
clobbering a register. How can I tell gcc that if it matches 1, a
given register is clobbered?


You use a clobber with a matching constraint for alternative 1 and X for
other alternatives.  Make sure the patten is not named.

Re: Conditional clobbering

[Paulo Matos]

On 02/23/10 19:12, Joern Rennecke wrote:
> Quoting "Paulo J. Matos" :
>> I have a situation in writing a specific condition on an md file.
>> I have an insn with 2 alternatives and then I use which_alternative to
>> generate the assembler code but if which_alternative == 1 I am
>> clobbering a register. How can I tell gcc that if it matches 1, a
>> given register is clobbered?
> 
> You use a clobber with a matching constraint for alternative 1 and X for
> other alternatives.  Make sure the patten is not named.

Thanks!

-- 
PMatos

Re: Conditional clobbering

[Joern Rennecke]

Quoting Joern Rennecke :

You use a clobber with a matching constraint for alternative 1 and X for
other alternatives.  Make sure the patten is not named.


P.S.: Actually, named is fine if you use a match_scratch, or if it's not
a standard name.

gcc-4.4-20100223 is now available

[gccadmin]

Snapshot gcc-4.4-20100223 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20100223/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_4-branch 
revision 157020

You'll find:

gcc-4.4-20100223.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.4-20100223.tar.bz2 C front end and core compiler

gcc-ada-4.4-20100223.tar.bz2  Ada front end and runtime

gcc-fortran-4.4-20100223.tar.bz2  Fortran front end and runtime

gcc-g++-4.4-20100223.tar.bz2  C++ front end and runtime

gcc-java-4.4-20100223.tar.bz2 Java front end and runtime

gcc-objc-4.4-20100223.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.4-20100223.tar.bz2The GCC testsuite

Diffs from 4.4-20100216 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.4
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.