gcc-ss-20011203 is now available

gcc-ss-20011203 is now available

[gccadmin]

gcc-ss-20011203 is now available on 
  ftp://gcc.gnu.org/pub/gcc/snapshots/2001-12-03
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the current development mainline
which is going to become GCC 3.1.

You'll find:

  gcc-20011203.tar.gz                  The full gcc snapshot, including all
                                       languages runtime libraries.

  gcc-core-20011203.tar.gz             Just the C front end and core compiler.

  gcc-tests-20011203.tar.gz            The GCC testsuite.

  gcc-g++-20011203.tar.gz              The g++ language and runtime.

  gcc-g++-tests-20011203.tar.gz	       The testsuite for G++.

  gcc-g77-20011203.tar.gz              The g77 language and runtime.
   
  gcc-g77-testsuite-20011203.tar.gz    The testsuite for G77.

  gcc-objc-20011203.tar.gz             The Objective-C front end and runtime.

  gcc-java-20011203.tar.gz             The Java front end.

  gcc-chill-20011203.tar.gz            The Chill front end and runtime.

If you are using an x86 GNU/Linux system that uses RPMs to handle
installation, you may find the daily RPM snapshots at:

http://www.codesourcery.com/gcc-snapshots.html

easier to install.


Diffs from 20011126 are available.

Note at times you may find newer directories on the server with limited
permissions.  These represent snapshots that have not yet been verified
as correct, or are known to be incorrect.

When a particular snapshot is ready for public consumption the directory
permissions are relaxed, the LATEST-IS- file is updated and a message is
sent to the gcc list.

Using a snapshot before it's officially made available is an unwise thing
to do since it may become impossible to update to an official snapshot.

The "gcc_latest_snapshot" tag has been moved.  You can use
cvs update -rgcc_latest_snapshot to update your CVS tree to the latest
official snapshot.

Re: gcc-ss-20011203 is now available

[Andreas Schwab]

gccadmin@sources.redhat.com writes:

|> gcc-ss-20011203 is now available on 
|>   ftp://gcc.gnu.org/pub/gcc/snapshots/2001-12-03
|> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

Seems like the snapshot has been made in the middle of a checkin, because
ia64 does not build due to missing "prefetch" rtx code.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: gcc-ss-20011203 is now available

[Joseph S. Myers]

On 4 Dec 2001, Andreas Schwab wrote:

> gccadmin@sources.redhat.com writes:
> 
> |> gcc-ss-20011203 is now available on 
> |>   ftp://gcc.gnu.org/pub/gcc/snapshots/2001-12-03
> |> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
> 
> Seems like the snapshot has been made in the middle of a checkin, because
> ia64 does not build due to missing "prefetch" rtx code.

In the middle of a series of 19 checkins, you mean.  Could people please
ensure that they commit each logical patch (such that users should not try
to build an intermediate state) in a single commit with all relevant files
named on the command line?

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: gcc-ss-20011203 is now available

[guerby]

> In the middle of a series of 19 checkins, you mean

May be the snapshot script could use a stable checkout, if 
the script is using contrib/gcc_build checkout I can propose
a patch to implement a stable-checkout option. Algorithm:

checkout
for I in 1 .. MAX loop
   wait X
   update
   exit when no files updated
end loop

With X being something like 10 or 15 minutes, it should be *very*
unlikely to get something inconsistent due to a serie of checkins, and
it would probably also survive an ooops commit / revert cycle, at the
cost of some wait.  MAX could be set so that X * MAX < time between
automatic run / 2.

-- 
Laurent Guerby <guerby@acm.org>

Re: gcc-ss-20011203 is now available

[Joseph S. Myers]

On Tue, 4 Dec 2001 guerby@acm.org wrote:

> > In the middle of a series of 19 checkins, you mean
> 
> May be the snapshot script could use a stable checkout, if 
> the script is using contrib/gcc_build checkout I can propose
> a patch to implement a stable-checkout option. Algorithm:

It is maintainer-scripts/gcc_release, it tags the snapshot (which takes
over ten minutes - this is a heavily loaded machine and tagging involves
writing to all files in the tree) then checks out on the tag (also slow).

The established practice is that snapshots may sometimes be broken and
people using them should just wait for the next snapshot in that case.
However, it helps everyone using CVS if people (a) scrupulously test their
patches following the instructions, including on multiple platforms for
anything potentially destabilising and (b) check in all files that are
part of a patch, and only those files, having verified that the output of
cvs diff on those files includes the intended changes and no others, with
a single commit command naming those files, if possible.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: gcc-ss-20011203 is now available

[Phil Edwards]

On Tue, Dec 04, 2001 at 08:24:14PM +0000, Joseph S. Myers wrote:
> On Tue, 4 Dec 2001 guerby@acm.org wrote:
> > May be the snapshot script could use a stable checkout, if 
> > the script is using contrib/gcc_build checkout I can propose
> > a patch to implement a stable-checkout option. Algorithm:

Alternative algorithm:

look at maintainer-scripts/crontab
look at wall clock
if TIME near Sunday 4:40 PM Pacific timezone
    wait until the snapshot is finished
end if
checkin

:-)


> The established practice is that snapshots may sometimes be broken and
> people using them should just wait for the next snapshot in that case.

Doesn't gcc_release do a build in order to ensure the generated source
files are there?  It's certainly no guarantee, but it should prevent
snapshots from going out that don't build on, say, i596-linux.

(I don't think it would help Ada or IA-64, though.)


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: gcc-ss-20011203 is now available

[Joseph S. Myers]

On Tue, 4 Dec 2001, Phil Edwards wrote:

> look at maintainer-scripts/crontab
> look at wall clock
> if TIME near Sunday 4:40 PM Pacific timezone

Monday.

> Doesn't gcc_release do a build in order to ensure the generated source
> files are there?  It's certainly no guarantee, but it should prevent
> snapshots from going out that don't build on, say, i596-linux.

It only does a build for releases, not snapshots.  Given the load on 
gcc.gnu.org, doing a build for snapshots does not seem wise.  Instead we 
simply require people building from snapshots to have the necessary tools 
intalled to build generated files they'd need when building from CVS.

Besides, patching generated files that aren't in CVS doesn't really work
well - there isn't a "release mode" for gcc_update that will clean up
timestamps on (say) Bison-generated files after applying a patch, despite
those files being in CVS and so not meant to be touched for CVS checkouts.

Including Info and Bison-generated files would also substantially bulk up 
diffs.

-- 
Joseph S. Myers
jsm28@cam.ac.uk

Re: gcc-ss-20011203 is now available

[Phil Edwards]

On Tue, Dec 04, 2001 at 08:36:41PM +0000, Joseph S. Myers wrote:
> On Tue, 4 Dec 2001, Phil Edwards wrote:
> > if TIME near Sunday 4:40 PM Pacific timezone
> 
> Monday.

Thinko.

> > Doesn't gcc_release do a build in order to ensure the generated source
> > files are there?  It's certainly no guarantee, but it should prevent
> > snapshots from going out that don't build on, say, i596-linux.
> 
> It only does a build for releases, not snapshots.  Given the load on 
> gcc.gnu.org, doing a build for snapshots does not seem wise.

Ah, okay.  Maybe once the pserver load is off to some other machine.
But then there sre still...

> Besides, patching generated files that aren't in CVS doesn't really work
> well - there isn't a "release mode" for gcc_update that will clean up
> timestamps on (say) Bison-generated files after applying a patch, despite
> those files being in CVS and so not meant to be touched for CVS checkouts.
> 
> Including Info and Bison-generated files would also substantially bulk up 
> diffs.

...these issues.  Hmmm.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Assembly in Gcc

[Mark Cuss]

Hello all,

I am new to doing inline asembly in gcc and have a few questions - hopefully
someone can help me out.

I read the section of the manual on the doing inline assembly.  It is quite
different than the old Borland compiler I used to use on DOS - I could just
put an "asm " and enclose all of my Intel syntax assmebly instructions
inside there.  Is there any way to do this in gcc?  I found the intel_syntax
directive and passed that in, but it seems that I still need to put %' s in
front of register names, etc.

The project I am working on involves integrating a large chunk (~ 40 pages)
of Intel assembly instructions into a program which I must compile with gcc.
So, my goal is to be able to do something like this:

    asm {
                mov dx, 378
                mov al, FF
                out dx, al
        } ;

 ... Without reformatting the code.  Is this possible?

Thanks in advance

Mark

Mark Cuss, B. Sc.
Junior Real Time Systems Analyst
CDL Systems Ltd
3553 - 31 Street NW
Calgary, Alberta
(403) 289-1733 ext 226
mcuss@cdlsystems.com

Re: Assembly in Gcc

[Graham Stott]

Mark,

Mark Cuss wrote:
> 
> Hello all,
> 
> I am new to doing inline asembly in gcc and have a few questions - hopefully
> someone can help me out.
> 
> I read the section of the manual on the doing inline assembly.  It is quite
> different than the old Borland compiler I used to use on DOS - I could just
> put an "asm " and enclose all of my Intel syntax assmebly instructions
> inside there.  Is there any way to do this in gcc?  I found the intel_syntax
> directive and passed that in, but it seems that I still need to put %' s in
> front of register names, etc.
> 
You might like to try ".intel_syntax noprefix" that avoids the needs to the %
on register names.

> The project I am working on involves integrating a large chunk (~ 40 pages)
> of Intel assembly instructions into a program which I must compile with gcc.
> So, my goal is to be able to do something like this:
> 
>     asm {
>                 mov dx, 378
>                 mov al, FF
>                 out dx, al
>         } ;
> 
>  ... Without reformatting the code.  Is this possible?
> 
Not as things currently stand you have to convert the asm { ... } form into
GCC's own asm construct.

Now it just so happens that I'm working on adding support of MS style inline
assembler in to GCC for the x86. It's in an advanced state and almost ready
to be submitted. 

> Thanks in advance
> 

> Mark

Graham

Re: Assembly in Gcc

[Mark Cuss]

> Now it just so happens that I'm working on adding support of MS style
inline
> assembler in to GCC for the x86. It's in an advanced state and almost
ready
> to be submitted.

Graham,

That would definately make life much much easier :)  If you could let me
know when you think your converter will be ready that would be great.

Mark

Re: Assembly in Gcc

[Tim Prince]

Much as I dislike the MSVC style, this would be a valuable contribution.
----- Original Message -----
From: "Graham Stott" <grahams@redhat.com>
To: <mcuss@cdlsystems.com>
Cc: <gcc@gcc.gnu.org>
Sent: Tuesday, December 04, 2001 1:03 PM
Subject: Re: Assembly in Gcc


> Mark,
>
> Mark Cuss wrote:
> >
> > Hello all,
> >
> > I am new to doing inline asembly in gcc and have a few questions -
hopefully
> > someone can help me out.
> >
> > I read the section of the manual on the doing inline assembly.  It is
quite
> > different than the old Borland compiler I used to use on DOS - I could
just
> > put an "asm " and enclose all of my Intel syntax assmebly instructions
> > inside there.  Is there any way to do this in gcc?  I found the
intel_syntax
> > directive and passed that in, but it seems that I still need to put %' s
in
> > front of register names, etc.
> >
> You might like to try ".intel_syntax noprefix" that avoids the needs to
the %
> on register names.
>
> > The project I am working on involves integrating a large chunk (~ 40
pages)
> > of Intel assembly instructions into a program which I must compile with
gcc.
> > So, my goal is to be able to do something like this:
> >
> >     asm {
> >                 mov dx, 378
> >                 mov al, FF
> >                 out dx, al
> >         } ;
> >
> >  ... Without reformatting the code.  Is this possible?
> >
> Not as things currently stand you have to convert the asm { ... } form
into
> GCC's own asm construct.
>
> Now it just so happens that I'm working on adding support of MS style
inline
> assembler in to GCC for the x86. It's in an advanced state and almost
ready
> to be submitted.
>
> > Thanks in advance
> >
>
> > Mark
>
> Graham

Re: gcc-ss-20011203 is now available

[Mark Mitchell]

> Doesn't gcc_release do a build in order to ensure the generated source
> files are there?

Yes.

I added this both to reduce the amount of logic necessary to create
releases and also as a final sanity check.  The script does a full
bootstrap.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com

Embedded Assembly and MMX in GCC

[Mark Cuss]

Hello All,

I've been playing around with the MMX instructions with some inline code
(using GCC 2.96, AS v 2.11.90.0.8).

I'm able to do simple stuff (moves, adds, etc) between the 32 bit registers
on the CPU like eax, etc.

However, I can't seem to do any 64 bit stuff.  For example, The following
fails:

__asm__("movq $1, %mm0);

The assembler says "suffix or operands invalid for 'mov1' "

Also, If I create a 64 bit variable (like an unsigned long long int) and
move it into an mmx register, it seems that I only get the first 32 bits
moving into the register.  Also, the packed adding stuff (like PADDW)
doesn't seem to work.

I realize that "movq" is an actual intel assembly command, and all the other
movs in AT&T (movb, movw) were added to specify the size of the value being
moved, so I see where the "q" stuff could cause troubles.  I'm pretty sure
there just must be some configuration thing I need to set up or something,
but I can't seem to find it...

If anyone has any hints they would be greatly appreciated.

Thanks in Advance,

Mark

Re: Embedded Assembly and MMX in GCC

[Alexandre Oliva]

On Dec 11, 2001, "Mark Cuss" <mcuss@cdlsystems.com> wrote:

> __asm__("movq $1, %mm0);

I suppose you're missing a `"' after `%mm0'.

Note that `%' is an active character in inline assembly, mostly like
printf.  If you want a `%' to get through to the output assembly,
double it.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Embedded Assembly and MMX in GCC

[Mark Cuss]

Yes, I did have the closing double quote - I forgot to type it into the
message......

 If I put two %'s in front of mm0, the assembler returns "bad register name
`%%mm0` "

With the one %, it says "suffix or operands invalid for `movq`"

It seems that on an inline statement, I need to put only 1 % in front of reg
names if there are no input or output variables, and 2 %'s if there are...

Mark


----- Original Message -----
From: "Alexandre Oliva" <aoliva@redhat.com>
To: <mcuss@cdlsystems.com>
Cc: <grahams@redhat.com>; <gcc@gcc.gnu.org>
Sent: Tuesday, December 11, 2001 1:27 PM
Subject: Re: Embedded Assembly and MMX in GCC


> On Dec 11, 2001, "Mark Cuss" <mcuss@cdlsystems.com> wrote:
>
> > __asm__("movq $1, %mm0);
>
> I suppose you're missing a `"' after `%mm0'.
>
> Note that `%' is an active character in inline assembly, mostly like
> printf.  If you want a `%' to get through to the output assembly,
> double it.
>
> --
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me
>

Re: Embedded Assembly and MMX in GCC

[Alexandre Oliva]

On Dec 11, 2001, "Mark Cuss" <mcuss@cdlsystems.com> wrote:

>  If I put two %'s in front of mm0, the assembler returns "bad register name
> `%%mm0` "

> With the one %, it says "suffix or operands invalid for `movq`"

> It seems that on an inline statement, I need to put only 1 % in front of reg
> names if there are no input or output variables, and 2 %'s if there are...

Ah, yes, indeed!  I had mis-read your report.  If the message comes
from the assembler, then it seems to be the case that the assembler
doesn't support the opcode you're using, or it expects it to be
written in a different way.  In either case, the GCC mailing list is
not the best place to discuss assembler issues: the binutils mailing
list is (as long as you're using GNU as :-).

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist    *Please* write to mailing lists, not to me

Re: Embedded Assembly and MMX in GCC

[Mark Cuss]

Ok,  I will ask my question there - thanks!

Mark

----- Original Message -----
From: "Alexandre Oliva" <aoliva@redhat.com>
To: <mcuss@cdlsystems.com>
Cc: <gcc-return-42668-mcuss=cdlsystems.com@gcc.gnu.org>; <gcc@gcc.gnu.org>
Sent: Tuesday, December 11, 2001 2:12 PM
Subject: Re: Embedded Assembly and MMX in GCC


> On Dec 11, 2001, "Mark Cuss" <mcuss@cdlsystems.com> wrote:
>
> >  If I put two %'s in front of mm0, the assembler returns "bad register
name
> > `%%mm0` "
>
> > With the one %, it says "suffix or operands invalid for `movq`"
>
> > It seems that on an inline statement, I need to put only 1 % in front of
reg
> > names if there are no input or output variables, and 2 %'s if there
are...
>
> Ah, yes, indeed!  I had mis-read your report.  If the message comes
> from the assembler, then it seems to be the case that the assembler
> doesn't support the opcode you're using, or it expects it to be
> written in a different way.  In either case, the GCC mailing list is
> not the best place to discuss assembler issues: the binutils mailing
> list is (as long as you're using GNU as :-).
>
> --
> Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
> Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
> CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
> Free Software Evangelist    *Please* write to mailing lists, not to me
>
>

Re: Embedded Assembly and MMX in GCC

[Craig Rodrigues]

On Tue, Dec 11, 2001 at 11:30:39AM -0700, Mark Cuss wrote:
> 
> __asm__("movq $1, %mm0");
> 
> The assembler says "suffix or operands invalid for 'mov1' "

I think there is a problem with your assembler, but I am
not enough of an assembler guru to say what.

This works for me with gcc 3.0.2 and binutils 2.10.91.0.2-3:

__asm__("movq %mm2,%mm0"); 


I recommend you look at the tutorials on:
http://www.linuxassembly.org

And also the binutils mailing list:
http://sources.redhat.com/binutils/
-- 
Craig Rodrigues        
http://www.gis.net/~craigr    
rodrigc@mediaone.net          

Re: Embedded Assembly and MMX in GCC

[Andreas Schwab]

Alexandre Oliva <aoliva@redhat.com> writes:

|> On Dec 11, 2001, "Mark Cuss" <mcuss@cdlsystems.com> wrote:
|> 
|> > __asm__("movq $1, %mm0);
|> 
|> I suppose you're missing a `"' after `%mm0'.
|> 
|> Note that `%' is an active character in inline assembly, mostly like
|> printf.  If you want a `%' to get through to the output assembly,
|> double it.

Only if the asm has parameters.  Without parameters no % directives are
processed.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: gcc-ss-20011203 is now available

[Andreas Schwab]

kenner@vlsi1.ultra.nyu.edu (Richard Kenner) writes:

|>     Could people please ensure that they commit each logical patch (such
|>     that users should not try to build an intermediate state) in a single
|>     commit with all relevant files named on the command line?
|> 
|> I certainly agree with that.  However, it is important to point out that it's
|> not always possible to put them all on the command line due to command-line
|> length restrictions on some systems.  I've run into that myself once a
|> few months ago.
|> 
|> So this sort of inconsistency is inevitable, though hopefully rare.

No problem with me, I can cope with it.

Andreas.

-- 
Andreas Schwab                                  "And now for something
Andreas.Schwab@suse.de				completely different."
SuSE Labs, SuSE GmbH, Schanzäckerstr. 10, D-90443 Nürnberg
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5

Re: gcc-ss-20011203 is now available

[Richard Kenner]

    Could people please ensure that they commit each logical patch (such
    that users should not try to build an intermediate state) in a single
    commit with all relevant files named on the command line?

I certainly agree with that.  However, it is important to point out that it's
not always possible to put them all on the command line due to command-line
length restrictions on some systems.  I've run into that myself once a
few months ago.

So this sort of inconsistency is inevitable, though hopefully rare.