Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Sun, 2010-05-23 at 05:11 +0100, Martin Guy wrote:
> On 5/11/10, Mark Mitchell  wrote:
> > Richard Earnshaw wrote:
> >
> >  > Speaking of which, we should probably formally deprecate the old arm-elf
> >  > derived targets in 4.6 so that we can remove them in 4.7.
> >
> >  > Similarly, we should deprecate support for the FPA on ARM.
> >
> >  I agree.
> 
> No one seems to have succeeded in getting arm-elf to work for some
> years, so removing them seems to be no loss.
> 

If nobody is building and testing it, then this will happen.  It's why
we should deprecate it.  That way, users are aware of the fact that the
configuration might not work and will probably go away at some point.

> However, although no one currently sells FPA hardware, 

That's overstating it.  Currently?  I don't expect anyone to ever sell
it again.

> it is widely
> supported as the only floating point model emulated by the Linux
> kernel, and people have to use it when compiling stuff to run on OABI
> systems, which include boards currently on the market based on ARMv4
> (no t) such as the Balloon Board 2.0 as well as boards with more
> recent CPUs where the manufacturer only supplies a LInux port for a
> kernel version that predates EABI support such as the Armadillo range.

OABI should be on the deprecated list too, as should all ports that
derive from the APCS or ATPCS rules.  The point of this deprecation
process is to allow us to sort out a lot of historical kinks in the
compiler.

Lets face it: strongarm was the last v4 chip to be produced, that's now
15 years old.  If gcc-4.6 were to be the last compiler to support it,
then it would still be supported for at least two years following its
release in (presumably) 2011 ie until at least 2013, by which time it
will be 18 years old.  I think that ought to be enough of a life-span.

> 
> Dropping FPA support from GCC effectively makes the OABI unusable, and
> often we are forced to use that by the environment supplied to us. Are
> there significant advantages to removing FPA support, other than
> reducing the size of the ARM backend?

Debian dropped OABI after Lenny, I've not heard anybody complain about
that.  That was the last major distro to use it.

Don't forget that the cost is not just on GCC, it's on all the tools --
gas, gdb, binutils -- the list goes on.

As for technical difficulties, then there's the odd format of doubles
that makes for much confusion for users, the mess of the old attributes
used in the old ABI variants and the fact that they were implemented
incorrectly...

It's time we faced up to the fact that the old code is not going to be
sorted out properly; that there's a maintained and well specified
compiler port out there that is not only capable of supporting v4 but is
also future-proofed as much as we can make it; that the old ports are
not being tested, so are most likely buggy by now and that all this
legacy bloat has a cost that we all must bear if we keep refusing to do
anything about it.

R.

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell  wrote:
> > Martin Guy wrote:
> >
> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
> >> often we are forced to use that by the environment supplied to us. Are
> >> there significant advantages to removing FPA support, other than
> >> reducing the size of the ARM backend?
> >
> > I think that maintainability of the ARM backend is indeed the major
> > benefit to dropping it.
> 
> There are lots of other ports that could be dropped to improve
> maintainability of some backends, or even the whole of GCC. That has
> never been accepted as a good reason to drop anything if there are
> still users of it, no matter how few (see pdp11 / vax backends,
> osf/tru64 support, other random unmaintained backends, ...).
> 
> What is different about arm-elf?
> 

What's different is that there is a well-maintained arm-eabi port.  The
arm-elf port and all its legacy just gets in the way.

The vax back-end only affects VAX; likewise for the PDP11 port.

I think it's critical that we don't let the tail wag the dog here.

R.

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Steven Bosscher]

On 5/24/10, Richard Earnshaw  wrote:
>
> On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
>> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell 
>> wrote:
>> > Martin Guy wrote:
>> >
>> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
>> >> often we are forced to use that by the environment supplied to us. Are
>> >> there significant advantages to removing FPA support, other than
>> >> reducing the size of the ARM backend?
>> >
>> > I think that maintainability of the ARM backend is indeed the major
>> > benefit to dropping it.
>>
>> There are lots of other ports that could be dropped to improve
>> maintainability of some backends, or even the whole of GCC. That has
>> never been accepted as a good reason to drop anything if there are
>> still users of it, no matter how few (see pdp11 / vax backends,
>> osf/tru64 support, other random unmaintained backends, ...).
>>
>> What is different about arm-elf?
>>
>
> What's different is that there is a well-maintained arm-eabi port.  The
> arm-elf port and all its legacy just gets in the way.
>

Imho you are taking a too narrow view here, because...

> The vax back-end only affects VAX; likewise for the PDP11 port.

...all this legacy just gets in the way of gcc as a whole. So I still
don't see the difference.

Nb, I don't oppose deprecating any arm stuff, but I just would like to
know if the justification also applies to other backends/ports.
Patched from me and others were rejected in the past even though the
situation was similar. Under what criteria would such patches now get
support from the RMs?

> I think it's critical that we don't let the tail wag the dog here.

Don't know what this means...

Ciao!
Steven

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Mon, 2010-05-24 at 12:42 +0200, Steven Bosscher wrote:
> On 5/24/10, Richard Earnshaw  wrote:
> >
> > On Sun, 2010-05-23 at 23:15 +0200, Steven Bosscher wrote:
> >> On Sun, May 23, 2010 at 10:27 PM, Mark Mitchell 
> >> wrote:
> >> > Martin Guy wrote:
> >> >
> >> >> Dropping FPA support from GCC effectively makes the OABI unusable, and
> >> >> often we are forced to use that by the environment supplied to us. Are
> >> >> there significant advantages to removing FPA support, other than
> >> >> reducing the size of the ARM backend?
> >> >
> >> > I think that maintainability of the ARM backend is indeed the major
> >> > benefit to dropping it.
> >>
> >> There are lots of other ports that could be dropped to improve
> >> maintainability of some backends, or even the whole of GCC. That has
> >> never been accepted as a good reason to drop anything if there are
> >> still users of it, no matter how few (see pdp11 / vax backends,
> >> osf/tru64 support, other random unmaintained backends, ...).
> >>
> >> What is different about arm-elf?
> >>
> >
> > What's different is that there is a well-maintained arm-eabi port.  The
> > arm-elf port and all its legacy just gets in the way.
> >
> 
> Imho you are taking a too narrow view here, because...
> 
> > The vax back-end only affects VAX; likewise for the PDP11 port.
> 
> ...all this legacy just gets in the way of gcc as a whole. So I still
> don't see the difference.
> 

To a degree, yes, you are right.  However, the source for all that port
is in separate files.  For the ARM port this is all necessarily in one
place.

> Nb, I don't oppose deprecating any arm stuff, but I just would like to
> know if the justification also applies to other backends/ports.
> Patched from me and others were rejected in the past even though the
> situation was similar. Under what criteria would such patches now get
> support from the RMs?
> 

Can't really answer that one.  I don't remember the case; and anyway,
it's not me that gets to decide...


R

Re: [RFC] Quad-float support for gfortran

[Dennis Wassel]

2010/5/24 FX :
> Dear gfortranners,
>
> For some work-related issue, I find the need to switch my code regularly 
> between double precision real arithmetics and quad-float. I currently do that 
> with a proprietary compiler whose brand name matches the regexp 
> "^In{1,}[t]\x65l$", but I'd be even more happy to do that with gfortran (my 
> usual compiler) and that gives me an excuse to get to do something I've long 
> wanted to achieve for fun: quad-float integration in gfortran.

Nice!
I have occasionally missed it as well, and had to resort to things like XBLAS.

> [...] There is one more issue, which is how to best integrate this? [...]

I think it would be a boon to gfortran if this also supported
cross-compiling to targets which support mpfr, or at least does not
pursue an approach that makes this more difficult that it has to be.
Thus, option 2 has my vote, because people out there have built mpfr
for all kinds of targets where gcc runs natively, so the results of
their efforts can easily be re-used. Actually I like option 3, but
only as long as it does not collect bit-rot: I would always prefer
building mpfr myself over debugging the GCC build system.

Thinking about this some more, option 3 might actually make more
sense, because then the regular bootstrap is enough to produce a
quad-capable cross-gfortran, where otherwise you would have to
bootstrap, build target-mpfr and then edit the specs file accordingly
(assuming you don't have the crosstools lying around to build
target-mpfr before bootstrap). Yuck!

Cheers,
Dennis

GNU MPFR 3.0.0 Release Candidate

[Vincent Lefevre]

The release of GNU MPFR 3.0.0 ("boudin aux pommes") is imminent.
Please help to make this major release as good as possible by
downloading and testing this release candidate:

http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.xz
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.bz2
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.gz
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.zip

The MD5's:
72f578e1fce8e58172af31ec5c622ffe  mpfr-3.0.0-rc1.tar.bz2
b203a4c40aa70b19bd70edfeb615f9c9  mpfr-3.0.0-rc1.tar.gz
d46414be83f279ef791e5b410a96e79b  mpfr-3.0.0-rc1.tar.xz
0fdf8a21ecb132c9ac5f66fb5ed287af  mpfr-3.0.0-rc1.zip

The signatures:
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.xz.asc
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.bz2.asc
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.tar.gz.asc
http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc1.zip.asc

Changes from versions 2.4.* to version 3.0:
- MPFR 3.0 is binary incompatible with previous versions but (almost)
  API compatible. More precisely the obsolete functions mpfr_random
  and mpfr_random2 have been removed, and the return type of the
  functions mpfr_get_f and mpfr_get_z is now int instead of void.
  In practice, this should not break any existing code.
- MPFR is now distributed under the GNU Lesser General Public License
  version 3 or later (LGPL v3+).
- Rounding modes GMP_RNDx are now MPFR_RNDx (GMP_RNDx kept for
  compatibility).
- A new rounding mode (MPFR_RNDA) is available to round away from zero.
- The rounding mode type is now mpfr_rnd_t (as in previous versions,
  both mpfr_rnd_t and mp_rnd_t are accepted, but mp_rnd_t may be
  removed in the future).
- The precision type is now mpfr_prec_t (as in previous versions, both
  mpfr_prec_t and mp_prec_t are accepted, but mp_prec_t may be removed
  in the future) and it is now signed (it was unsigned in MPFR 2.*, but
  this was not documented). In practice, this change should not affect
  existing code that assumed nothing on the precision type.
- MPFR now has its own exponent type mpfr_exp_t, which is currently
  the same as GMP's mp_exp_t.
- Functions mpfr_random and mpfr_random2 have been removed.
- mpfr_get_f and mpfr_get_z now return a ternary value.
- mpfr_strtofr now accepts bases from 37 to 62.
- New functions mpfr_buildopt_tls_p and mpfr_buildopt_decimal_p giving
  information about options used at MPFR build time.
- New function mpfr_regular_p.
- New function mpfr_set_zero.
- New function mpfr_digamma.
- New function mpfr_ai (incomplete, experimental).
- New functions mpfr_set_flt and mpfr_get_flt to convert from/to the
  float type.
- New function mpfr_urandom.
- New function mpfr_set_z_2exp (companion to mpfr_get_z_2exp, which
  was renamed from mpfr_get_z_exp in previous versions).
- Speed improvement for large operands in the trigonometric functions
  (mpfr_sin, mpfr_cos, mpfr_tan, mpfr_sin_cos): speedup of about 2.5
  for 10^5 digits, of about 5 for 10^6 digits.
- Speed improvement for large operands of the inverse trigonometric
  functions (arcsin, arccos, arctan): about 2 for 10^3 digits, up to
  2.7 for 10^6 digits.
- Some documentation files are installed in $docdir.
- The configure script recognizes some extra "long double" formats
  (double big endian, double little endian, double-double big endian).
- MPFR manual: added "API Compatibility" section.
- Bug fixes.

Please send success and failure reports with "./config.guess" output
to .

If no problems are found, GNU MPFR 3.0.0 should be released
around 2010-06-07.

Regards,

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Joseph S. Myers]

(I've CC:ed the listed GCC maintainers for various OS ports whose ARM 
configurations in GCC do not appear to be using EABI, as well as Pedro for 
WinCE, given the discussions of deprecation.)  Deprecations are generally 
a matter for the relevant maintainers, which in this case means target 
maintainers together with OS maintainers (or target maintainers alone if 
noone is maintaining the OS ports to ARM).

On Mon, 24 May 2010, Richard Earnshaw wrote:

> OABI should be on the deprecated list too, as should all ports that
> derive from the APCS or ATPCS rules.  The point of this deprecation
> process is to allow us to sort out a lot of historical kinks in the
> compiler.

What ABI does WinCE use?  I don't think it's EABI-based; it's not even 
ELF.  When you're dealing with an OS not built with GCC, GCC gets to 
follow the ABI defined for that OS, just like the x86_64 Windows port has 
to deal with ABI differences from the ELF psABI for x86_64, for example.

For OSes built with GCC (which I think is all the non-WinCE ARM targets) 
there is more of a scope for transitioning to a new ABI and not supporting 
old OS versions (and so removing arm-linux, arm-elf).

I recently noted that VxWorks is not yet using EABI - but is certainly 
still supporting ARM.  Now, if it transitions, I think it was established 
some years ago that GCC does not generally try to support older VxWorks 
versions.

Is the ARM RTEMS port going to move to EABI?

Are the ARM ports of FreeBSD or NetBSD moving to EABI?  (I think we can 
kill the arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old 
a.out-based NetBSD - and more generally any other a.out BSD ports.)  Old 
in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI 
support.

Is there anyone maintaining arm*-*-ecos-elf?

I hope none of the above ports are using FPA.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Joseph S. Myers]

On Mon, 24 May 2010, Steven Bosscher wrote:

> > The vax back-end only affects VAX; likewise for the PDP11 port.
> 
> ...all this legacy just gets in the way of gcc as a whole. So I still
> don't see the difference.
> 
> Nb, I don't oppose deprecating any arm stuff, but I just would like to
> know if the justification also applies to other backends/ports.
> Patched from me and others were rejected in the past even though the
> situation was similar. Under what criteria would such patches now get
> support from the RMs?

I don't think it's generally an RM matter; it's a matter for the relevant 
architecture and OS port maintainers (and for bare-metal targets such as 
arm-elf that means the architecture maintainers; likewise for -linux-gnu* 
targets since there is no separate GNU/Linux target maintainer).

What the responsibilities of maintainers are - whether it can be expected 
that target maintainers (or maintainers of other components) will do some 
defined cleanup or API change in some defined time with the targets 
otherwise liable to deprecation - is certainly a reasonable topic for 
discussion.  We were going to deprecate the targets not updated for IRA, 
but then a solution was produced that didn't require each target to be 
updated by its maintainer to continue to build

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Deprecating ARM FPA support

[Joel Sherrill]

On 05/24/2010 06:33 AM, Joseph S. Myers wrote:

(I've CC:ed the listed GCC maintainers for various OS ports whose ARM
configurations in GCC do not appear to be using EABI, as well as Pedro for
WinCE, given the discussions of deprecation.)  Deprecations are generally
a matter for the relevant maintainers, which in this case means target
maintainers together with OS maintainers (or target maintainers alone if
noone is maintaining the OS ports to ARM).

On Mon, 24 May 2010, Richard Earnshaw wrote:

   

OABI should be on the deprecated list too, as should all ports that
derive from the APCS or ATPCS rules.  The point of this deprecation
process is to allow us to sort out a lot of historical kinks in the
compiler.
 

What ABI does WinCE use?  I don't think it's EABI-based; it's not even
ELF.  When you're dealing with an OS not built with GCC, GCC gets to
follow the ABI defined for that OS, just like the x86_64 Windows port has
to deal with ABI differences from the ELF psABI for x86_64, for example.

For OSes built with GCC (which I think is all the non-WinCE ARM targets)
there is more of a scope for transitioning to a new ABI and not supporting
old OS versions (and so removing arm-linux, arm-elf).

I recently noted that VxWorks is not yet using EABI - but is certainly
still supporting ARM.  Now, if it transitions, I think it was established
some years ago that GCC does not generally try to support older VxWorks
versions.

Is the ARM RTEMS port going to move to EABI?

   

We are watching this discussion and see where it leads us.
RTEMS targets are normally one side-step from XXX-elf and
that was what lead us to use arm-elf.  If it has issues that
make it not the preferred target for embedded ARM work,
then we will need to move.  We have transitioned from COFF
to ELF in the past for similar reasons.

I think I triggered this discussion by asking why so many
tests failed on arm-rtems that had nothing to do with
anything RTEMS could break.   If it takes moving to arm-eabi
to get a well supported target that passes tests, we will
move.  We compile everything from source.

The question we would like answered is what impact this
has on our code base.  What changes will we have to
make to accomodate this?  Register usage changes, stack
frame changes, etc.

Are the ARM ports of FreeBSD or NetBSD moving to EABI?  (I think we can
kill the arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old
a.out-based NetBSD - and more generally any other a.out BSD ports.)  Old
in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI
support.

Is there anyone maintaining arm*-*-ecos-elf?

I hope none of the above ports are using FPA.

   

--joel

Re: LTO and libelf (and FreeBSD)

[Richard Guenther]

On Mon, May 24, 2010 at 4:52 AM, Steve Kargl
 wrote:
> Kai,
>
> I tested your patch posted here:
>
> http://gcc.gnu.org/ml/gcc/2010-05/msg00445.html
>
> to address the issue
>
>   % cat x.c
>   int main() { }
>   % gccvs -flto x.c
>   % gccvs -fwhopr x.c
>   lto1: fatal error: elf_update() failed: Layout constraint violation
>   compilation terminated.
>   lto-wrapper: gccvs returned 1 exit status
>
> which is an appear imcompatibility between FreeBSD's libelf and
> gcc's lto.  My testing shows that your patch fixes all the problems
> I've observed.
>
> I do however share your concern that gcc may not be following the
> ELF spec.  Everything that I can find suggests that the alignment
> of a section must be the same for all data.  The statements on
> the web that I've found are of the form:
>
>  When deciding how to build the output file, elf_update obeys the
>  alignments of individual data buffers to create output sections.
>  A section's most strictly aligned data buffer controls the section's
>  alignment. The library also inserts padding between buffers, as
>  necessary, to ensure the proper alignment of each buffer.
>
>
> It's unclear to me whether FreeBSD libelf is too strict in its
> interpretation of the above or whether gcc is to too loose in
> its interpretation of what alignment of data means.

It would be nice to fix this on the GCC side (that is, align all
sections properly).  The reason it is done as now is because we do
not record the "true" size of a compressed section and when we
have tail-padding zlibg gets confused with the extra bytes.

So the issue is really that our compressed sections do not have
a header.

Richard.

> --
> Steve
>

Re: gfortran windows builds script

[Richard Guenther]

On Mon, May 24, 2010 at 1:50 AM, FX  wrote:
>> The current trunk does require flex.
>> The build dies pretty quickly unless flex is available.
>>
>
>
> Was the flex dependency recently reintroduced? It used to be that if you
> update trunk with contrib/gcc_update (instead of svn up), it sets the
> modifcation time of generated files so that flex and the autotools are not
> required.
>
> I'm forwarding this to the gcc list for others' insight.

That was always the case and is not a recent change.

Richard.

> FX
>

delay branch bug?

[Hariharan]

Hello all,
I found something a little odd with delay slot scheduling. If i had the 
following bit of code (Note that "get" builtin functions in picochip 
stand for port communication)


int mytest ()
{
 int a[5];
 int i;
 for (i = 0; i < 5; i++)
 {
   a[i] = (int) getctrlIn();
 }
 switch (a[3])
 {
   case 0:
   return 4;
   default:
   return 13;
 }
}

The relevant bit of assembly for this compiled at -Os is

_L2:
   GET 0,R[5:4]// R[5:4] := PORT(0)
_picoMark_LBE5=
_picoMark_LBE4=
   .loc 1 13 0
   STW R4,(R3)0// Mem((R3)0{byte}) := R4
   ADD.0 R3,2,R3   // R3 := R3 + 2 (HI)
   .loc 1 11 0
   SUB.0 R3,R2,r15 // CC := (R3!=R2)
   BNE _L2
   =-> LDW (FP)3,R5// R5 = Mem((FP)6{byte})
   .loc 1 22 0

=-> is the delay slot marker. Note that the LDW instruction has been 
moved into the delay slot. This corresponds to the load in "switch 
(a[3]" statement above. The first 3 times around this loop, LDW would be 
loading uninitialised memory. The loaded value is ignored until we come 
out of the loop and hence the code is functionally correct, but i am not 
sure introduction of uninitialised memory access by the compiler when 
there was none in the source is good.


I browsed around the delay branch code in reorg.c, but couldn't find 
anything that checks for this. Is this the intended behaviour? Can 
anyone familiar with delay branch code help?


Thanks
Hari

Re: Deprecating ARM FPA support

[Joseph S. Myers]

On Mon, 24 May 2010, Joel Sherrill wrote:

> The question we would like answered is what impact this
> has on our code base.  What changes will we have to
> make to accomodate this?  Register usage changes, stack
> frame changes, etc.

For ARM Linux, one change was dealing with __arm__ conditionals in code 
that related to the peculiarities of OABI structure layout - EABI is much 
more conventionally like other architectures in that regard.  I don't know 
whether that will apply to RTEMS (as I'm not familiar with the details of 
the various old ABIs).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Earnshaw]

On Mon, 2010-05-24 at 11:33 +, Joseph S. Myers wrote:
> (I've CC:ed the listed GCC maintainers for various OS ports whose ARM 
> configurations in GCC do not appear to be using EABI, as well as Pedro for 
> WinCE, given the discussions of deprecation.)  Deprecations are generally 
> a matter for the relevant maintainers, which in this case means target 
> maintainers together with OS maintainers (or target maintainers alone if 
> noone is maintaining the OS ports to ARM).
> 
> On Mon, 24 May 2010, Richard Earnshaw wrote:
> 
> > OABI should be on the deprecated list too, as should all ports that
> > derive from the APCS or ATPCS rules.  The point of this deprecation
> > process is to allow us to sort out a lot of historical kinks in the
> > compiler.
> 
> What ABI does WinCE use?  

Don't know.  Does a document specifying it even exist?  If we are
supporting an ABI, then I think we need to have a publicly available
SPEC.

> I don't think it's EABI-based; it's not even 
> ELF.  When you're dealing with an OS not built with GCC, GCC gets to 
> follow the ABI defined for that OS, just like the x86_64 Windows port has 
> to deal with ABI differences from the ELF psABI for x86_64, for example.
> 
> For OSes built with GCC (which I think is all the non-WinCE ARM targets) 
> there is more of a scope for transitioning to a new ABI and not supporting 
> old OS versions (and so removing arm-linux, arm-elf).
> 
> I recently noted that VxWorks is not yet using EABI - but is certainly 
> still supporting ARM.  Now, if it transitions, I think it was established 
> some years ago that GCC does not generally try to support older VxWorks 
> versions.
> 
> Is the ARM RTEMS port going to move to EABI?

Ask the maintainers.  Do they still want their OS to work on modern CPUs
with any degree of efficiency?  The current ABI diverged from the old
for good technical reasons, not just for the sake of being different.

> 
> Are the ARM ports of FreeBSD or NetBSD moving to EABI?  (I think we can 
> kill the arm*-*-netbsd* that don't match arm*-*-netbsdelf* - i.e., old 
> a.out-based NetBSD - and more generally any other a.out BSD ports.)  Old 
> in-tree GCC versions shouldn't be a limitation here - 4.1 has EABI 
> support.

The NetBSD developers said at the time that they moved to arm-netbsdelf
that the ABI was transitional and that they would move to the EABI once
it was finished.  They've not made much effort to do that move (though I
admit as a NetBSD developer, I've not done much pushing).  Consider this
the first heave :-)  I don't know about FreeBSD; and I'm not aware that
they've ever done anything other than follow NetBSD in this area.

> 
> Is there anyone maintaining arm*-*-ecos-elf?
> 
> I hope none of the above ports are using FPA.

I don't think so.  Certainly NetBSD doesn't; I can't speak for the rest.
In fact, I'm pretty sure that only the old linux ABI uses the FPA.

Certainly removing support for FPA (and any targets that require it) as
a first step would be an option; but we should also focus on where we
want to get to.  Setting our plans out would be the best option for
those who need to change, so that they have sufficient opportunity to
plan their own work and avoid unnecessary intermediate steps (it would
be very unfair, for example, to suggest to those who need to migrate
away from using the FPA to just move to using soft-float arm-elf if they
then find twelve months down the line that they have to move again
because arm-elf was going away as well.

R.

> 

Re: Deprecating ARM FPA support

[Richard Earnshaw]

On Mon, 2010-05-24 at 06:40 -0500, Joel Sherrill wrote:
> The question we would like answered is what impact this
> has on our code base.  What changes will we have to
> make to accomodate this?  Register usage changes, stack
> frame changes, etc.

By far the biggest change is to the layout of 64-bit data types.  These
now have 64-bit alignment and this has consequences for stack alignment,
struct layout and argument marshalling.  There are many other small
changes (probably too many to enumerate with any hope of not missing
one), but they are mostly small.

R.

Re: Deprecating ARM FPA support (was: ARM Neon Tests Failing on non-Neon Target)

[Richard Kenner]

> What's different is that there is a well-maintained arm-eabi port.  The
> arm-elf port and all its legacy just gets in the way.
> 
> The vax back-end only affects VAX; likewise for the PDP11 port.

I think that's a critical distinction.  I can't see removing a port
just because it's not used much (or at all) because it might be
valuable for historical reason or to show examples for how to do things.
If the maintenance burden of keeping that port is just doing some mechanical
changes a couple of times a year when the backend API changes, that
port should be kept even if there are ZERO known users.

But if it's interfering with the maintenance of an active port with
which it shares code, then I think it's retention has to meet a higher
standard of usefulness.

Re: Deprecating ARM FPA support

[Mark Mitchell]

Richard Earnshaw wrote:

> Don't know.  Does a document specifying it even exist?  If we are
> supporting an ABI, then I think we need to have a publicly available
> SPEC.

I disagree with that statement.  If a system is sufficiently popular, we
probably want to support it -- with or without a specification.  For
example, if x86 Windows didn't have a public ABI specification, we'd
still want to support it.

> I don't think so.  Certainly NetBSD doesn't; I can't speak for the rest.
> In fact, I'm pretty sure that only the old linux ABI uses the FPA.

I'm certain VxWorks makes no use of FPA.  However, whether it changes to
EABI or not is not purely up to the GCC maintainers; Wind River uses the
Diab compiler on VxWorks as well, and VxWorks is an environment where
stability over time is considered very important.  On the other hand,
it's going to be a long time before VxWorks gets to GCC 4.7, so there's
time to work this out.

> Certainly removing support for FPA (and any targets that require it) as
> a first step would be an option; but we should also focus on where we
> want to get to.

I agree with that.  But, it would also be interesting to know just how
broken that code is.  If, in fact, FPA and/or ARM ELF mostly work at
present, then there's less call for actually removing (as opposed to
deprecating) things.  If, on the other hand, they've been broken for
several releases, then there's good evidence that nobody really cares
about new versions of GCC supporting these things.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: delay branch bug?

[Jeff Law]

On 05/24/10 05:46, Hariharan wrote:

Hello all,
I found something a little odd with delay slot scheduling. If i had 
the following bit of code (Note that "get" builtin functions in 
picochip stand for port communication)


int mytest ()
{
 int a[5];
 int i;
 for (i = 0; i < 5; i++)
 {
   a[i] = (int) getctrlIn();
 }
 switch (a[3])
 {
   case 0:
   return 4;
   default:
   return 13;
 }
}

The relevant bit of assembly for this compiled at -Os is

_L2:
   GET 0,R[5:4]// R[5:4] := PORT(0)
_picoMark_LBE5=
_picoMark_LBE4=
   .loc 1 13 0
   STW R4,(R3)0// Mem((R3)0{byte}) := R4
   ADD.0 R3,2,R3   // R3 := R3 + 2 (HI)
   .loc 1 11 0
   SUB.0 R3,R2,r15 // CC := (R3!=R2)
   BNE _L2
   =-> LDW (FP)3,R5// R5 = Mem((FP)6{byte})
   .loc 1 22 0

=-> is the delay slot marker. Note that the LDW instruction has been 
moved into the delay slot. This corresponds to the load in "switch 
(a[3]" statement above. The first 3 times around this loop, LDW would 
be loading uninitialised memory. The loaded value is ignored until we 
come out of the loop and hence the code is functionally correct, but i 
am not sure introduction of uninitialised memory access by the 
compiler when there was none in the source is good.


I browsed around the delay branch code in reorg.c, but couldn't find 
anything that checks for this. Is this the intended behaviour? Can 
anyone familiar with delay branch code help?
It's not ideal, but there's no way for reorg to know that a particular 
memory location is uninitialized as a result trying to "fix" this 
problem would ultimately result in reorg not being allowed to fill delay 
slots with memory references except under very very restrictive 
circumstances.


From a correctness standpoint, the uninitialized value will never be 
used, so it should cause no ill effects on your code.  The biggest 
effect would be tools like valgrind & purify (if supported on your 
architecture) would report the uninitialized memory read.  [Which begs 
the question how does purify handle this on sparc-solaris? ]


Jeff


Thanks
Hari

Re: delay branch bug?

[Jakub Jelinek]

On Mon, May 24, 2010 at 08:14:13AM -0600, Jeff Law wrote:
> From a correctness standpoint, the uninitialized value will never be  
> used, so it should cause no ill effects on your code.  The biggest  
> effect would be tools like valgrind & purify (if supported on your  
> architecture) would report the uninitialized memory read.  [Which begs  
> the question how does purify handle this on sparc-solaris? ]

I believe valgrind doesn't report uninitialized memory reads, only tracks
that there is uninitialized value (or perhaps just some bits of it) in some
location and only reports when you actually use that somewhere (e.g. do a
conditional branch that depends on the uninitialized value etc.).

Jakub

Re: delay branch bug?

[Eric Botcazou]

> int mytest ()
> {
>   int a[5];
>   int i;
>   for (i = 0; i < 5; i++)
>   {
> a[i] = (int) getctrlIn();
>   }
>   switch (a[3])
>   {
> case 0:
> return 4;
> default:
> return 13;
>   }
> }
>
> The relevant bit of assembly for this compiled at -Os is
>
> _L2:
> GET 0,R[5:4]// R[5:4] := PORT(0)
> _picoMark_LBE5=
> _picoMark_LBE4=
> .loc 1 13 0
> STW R4,(R3)0// Mem((R3)0{byte}) := R4
> ADD.0 R3,2,R3   // R3 := R3 + 2 (HI)
> .loc 1 11 0
> SUB.0 R3,R2,r15 // CC := (R3!=R2)
> BNE _L2
> =-> LDW (FP)3,R5// R5 = Mem((FP)6{byte})
> .loc 1 22 0
>
> =-> is the delay slot marker. Note that the LDW instruction has been
> moved into the delay slot. This corresponds to the load in "switch
> (a[3]" statement above. The first 3 times around this loop, LDW would be
> loading uninitialised memory. The loaded value is ignored until we come
> out of the loop and hence the code is functionally correct, but i am not
> sure introduction of uninitialised memory access by the compiler when
> there was none in the source is good.

You'd need to define what "good" means here.  The generated code looks correct 
since (1) 'a' is on the stack and thus loading from it cannot trap (2) it is 
not marked volatile and (3) the result of the load is unused when the memory 
location is uninitialized.  So, from an external viewpoint, the generated 
code behaves as if there were no "problematic" loads and looks therefore OK.

-- 
Eric Botcazou

Re: delay branch bug?

[Hariharan Sandanagobalane]

Jeff Law wrote:

On 05/24/10 05:46, Hariharan wrote:

Hello all,
I found something a little odd with delay slot scheduling. If i had 
the following bit of code (Note that "get" builtin functions in 
picochip stand for port communication)


int mytest ()
{
 int a[5];
 int i;
 for (i = 0; i < 5; i++)
 {
   a[i] = (int) getctrlIn();
 }
 switch (a[3])
 {
   case 0:
   return 4;
   default:
   return 13;
 }
}

The relevant bit of assembly for this compiled at -Os is

_L2:
   GET 0,R[5:4]// R[5:4] := PORT(0)
_picoMark_LBE5=
_picoMark_LBE4=
   .loc 1 13 0
   STW R4,(R3)0// Mem((R3)0{byte}) := R4
   ADD.0 R3,2,R3   // R3 := R3 + 2 (HI)
   .loc 1 11 0
   SUB.0 R3,R2,r15 // CC := (R3!=R2)
   BNE _L2
   =-> LDW (FP)3,R5// R5 = Mem((FP)6{byte})
   .loc 1 22 0

=-> is the delay slot marker. Note that the LDW instruction has been 
moved into the delay slot. This corresponds to the load in "switch 
(a[3]" statement above. The first 3 times around this loop, LDW would 
be loading uninitialised memory. The loaded value is ignored until we 
come out of the loop and hence the code is functionally correct, but 
i am not sure introduction of uninitialised memory access by the 
compiler when there was none in the source is good.


I browsed around the delay branch code in reorg.c, but couldn't find 
anything that checks for this. Is this the intended behaviour? Can 
anyone familiar with delay branch code help?
It's not ideal, but there's no way for reorg to know that a particular 
memory location is uninitialized as a result trying to "fix" this 
problem would ultimately result in reorg not being allowed to fill 
delay slots with memory references except under very very restrictive 
circumstances.


From a correctness standpoint, the uninitialized value will never be 
used, so it should cause no ill effects on your code.  The biggest 
effect would be tools like valgrind & purify (if supported on your 
architecture) would report the uninitialized memory read.  [Which begs 
the question how does purify handle this on sparc-solaris? ]
The code compiled for picochip runs under a simulator. The simulator 
tracks uninitialised memory accesses and emits warnings and hence my 
question.  I would agree with you that turning off delay slot filling of 
memory references for this sake doesn't make sense.


Thanks for your help.

Cheers
Hari



Jeff


Thanks
Hari

Re: Where does the time go?

[Mark Mitchell]

Joseph S. Myers wrote:

>> All in all, perhaps not the most efficient representation for memory
>> foot print, and the pointer chasing probably doesn't help (cache!).
>> But changing it is a lot more difficult than the GIMPLE tuples
>> project. I don't think it can be done.
> 
> I don't see any reason technically why it can't be done.  There would be 
> several large projects, certainly, and nontrivial work in actually 
> producing a design for conversion, but there are also clear incremental 
> steps, such as static typing of some different kinds of RTL and moving to 
> more specific accessors for parts of an RTX in place of generic ones such 
> as XEXP used at present.  If it can't be done then that would be more for 
> economic reasons - no-one benefiting enough from the change, potential 
> benefits being gained more cheaply in other ways - than because of 
> intrinsic technical obstacles.

I completely agree.  This is a tractable problem, approximately on the
same scale as GIMPLE tuples.  I would guess approximately a person-year,
perhaps spread out over a longer time.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Build error with USE_MD_CONSTRAINTS vs. CONST_OK_FOR_CONSTRAINT_P

[Jeff Kuskin]

I've got a local port of GCC 4.5.0 to an in-house CPU.

I'm trying to remove *all* single-letter constraints from my cpu.md file and 
replace them with define_constraint entries that define *multi-letter* 
constraint names.  Example:  (define_constraint "aFOO" ...)

But I've found that when I remove all single-letter constraints, I see these 
errors when compiling GCC:

libbackend.a(ira-costs.o): In function `record_reg_classes':
/sw/gcc-4.5.0-lcl/gcc/ira-costs.c:471: undefined reference to 
`CONST_OK_FOR_CONSTRAINT_P'
libbackend.a(ira-lives.o): In function `single_reg_class':
/sw/gcc-4.5.0-lcl/gcc/ira-lives.c:680: undefined reference to 
`CONST_OK_FOR_CONSTRAINT_P'
/sw/gcc-4.5.0-lcl/gcc/ira-lives.c:684: undefined reference to 
`CONST_OK_FOR_CONSTRAINT_P'
libbackend.a(recog.o): In function `asm_operand_ok':
/sw/gcc-4.5.0-lcl/gcc/recog.c:1739: undefined reference to 
`CONST_OK_FOR_CONSTRAINT_P'
/sw/gcc-4.5.0-lcl/gcc/recog.c:1744: undefined reference to 
`CONST_OK_FOR_CONSTRAINT_P'
libbackend.a(recog.o):/sw/gcc-4.5.0-lcl/gcc/recog.c:1749: more undefined 
references to `CONST_OK_FOR_CONSTRAINT_P' follow
collect2: ld returned 1 exit status



I see in 'defaults.h' this code:

  /* If none of these macros are defined, the port must use the new
 technique of defining constraints in the machine description.
 tm_p.h will define those macros that machine-independent code
 still uses.  */
  #if  !defined CONSTRAINT_LEN\
&& !defined REG_CLASS_FROM_LETTER \
&& !defined REG_CLASS_FROM_CONSTRAINT \
&& !defined CONST_OK_FOR_LETTER_P \
&& !defined CONST_OK_FOR_CONSTRAINT_P \
&& !defined CONST_DOUBLE_OK_FOR_LETTER_P  \
&& !defined CONST_DOUBLE_OK_FOR_CONSTRAINT_P  \
&& !defined EXTRA_CONSTRAINT  \
&& !defined EXTRA_CONSTRAINT_STR  \
&& !defined EXTRA_MEMORY_CONSTRAINT   \
&& !defined EXTRA_ADDRESS_CONSTRAINT

  #define USE_MD_CONSTRAINTS


I do not define any of these macros in my cpu.h file, and I verified that 
'USE_MD_CONSTRAINTS' *IS* being defined by defaults.h, as expected.

However, I still see the above errors when I compile.  My reading of the 
ira-costs.c and ira-lives.c code seems to indicate that 
'CONST_OK_FOR_CONSTRAINT_P' is simply assumed to be defined and that there is 
no provision for doing something else if CONST_OK_FOR_CONSTRAINT_P is undefined 
but USE_MD_CONSTRAINTS is defined.

I *am* using the IRA, if that matters.

Am I *required* to define at least some of the single-letter constraints?  My 
reading of the "Operand Constraints" section of the GCC internals documentation 
is that this is not a requirement.

Suggestions?  Thanks for any help.



  

Re: [RFC] Quad-float support for gfortran

[Joseph S. Myers]

On Mon, 24 May 2010, FX wrote:

>1. assume that the user has compiled compile separately a quad-prec 
> math library (says libmathq; possible relying on MPFR, as the 
> implementation I propose) and arrange specs so that an option triggers 
> linking to it
>2. assume that the user has an MPFR target library compiled, and 
> include the quad math wrappers into libgfortran

There's also the possibility of dlopening a separate library or MPFR from 
libgfortran.  I suspect it would be hard to make dlopening MPFR work well 
(too much need to know about MPFR data types in the code using it), but it 
does avoid bringing a shared library into many programs that do not need 
it.  (So would building a separate libgfortranfloat128 library with the 
relevant code - built as part of GCC, linked against MPFR but not included 
in libgfortran.)  There was a discussion a while back of the 
undesirability of making libstdc++ depend on librt.

Certainly, "assume" seems wrong - test at configure time, rather, on the 
platforms supporting float128 libgcc functions, and disable the 
libgfortran functionality if MPFR isn't present.  It's expected that when 
bootstrapping cross tools for a GNU/Linux target you have shared libc 
present before building and configuring non-C runtime libraries (and so 
build the compiler more than once with a C-only compiler used to build 
glibc).  So this would add a rule that if you want MPFR support in 
libgfortran then you build MPFR with your C-only compiler before building 
the Fortran-enabled compiler.

MPFR requirements could be potentially problematic for bare-metal targets 
using static linking only (since MPFR is LGPL whereas GCC runtime 
libraries are GPL+exception) but that's less relevant for the targets that 
support __float128 at present, all of which support dynamic linking.

-- 
Joseph S. Myers
jos...@codesourcery.com

new mirror

[James Miller]

Dear Sir/Madam,

We have raised a new GCC mirror at http://gcc.parentinginformed.com.
The mirror is located in Canada and I am the contact point for it.

Thank you.

Best wishes,
James Miller

Re: Build error with USE_MD_CONSTRAINTS vs. CONST_OK_FOR_CONSTRAINT_P

[Ian Lance Taylor]

Jeff Kuskin  writes:

> I'm trying to remove *all* single-letter constraints from my cpu.md
> file and replace them with define_constraint entries that define
> *multi-letter* constraint names.  Example: (define_constraint "aFOO"
> ...)


> Am I *required* to define at least some of the single-letter
> constraints?  My reading of the "Operand Constraints" section of the
> GCC internals documentation is that this is not a requirement.

The goal should be that it is possible to not define any single-letter
constraints.  However, you are treading where no one else has dared to
tread, and you are encountering bugs.  I would encourage you to try to
fix them.

Ian

[wwwdocs] PATCH for Re: new mirror

[Gerald Pfeifer]

On Mon, 24 May 2010, James Miller wrote:
> We have raised a new GCC mirror at http://gcc.parentinginformed.com.
> The mirror is located in Canada and I am the contact point for it.

Thanks for setting up a mirror and letting us now.  I just added this
to our mirrors list at http://gcc.gnu.org/mirrors.html with the patch
below.

Gerald

Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.197
diff -u -3 -p -r1.197 mirrors.html
--- mirrors.html9 May 2010 19:54:39 -   1.197
+++ mirrors.html24 May 2010 18:52:39 -
@@ -34,6 +34,7 @@ Key fingerprint = 33C2 35A3 4C46 AA3F FB
 
 Austria: ftp://gd.tuwien.ac.at/gnu/gcc/";>gd.tuwien.ac.at, 
thanks to Antonin dot Sprinzl at tuwien dot ac dot at
 Bulgaria: http://gcc.igor.onlinedirect.bg/";>gcc.igor.onlinedirect.bg, thanks to 
igor at onlinedirect dot bg
+Canada: http://gcc.parentinginformed.com";>http://gcc.parentinginformed.com, 
thanks to James Miller (jmiller at parentinginformed dot com).
 Canada, Toronto: http://gcc-ca.internet.bs";>http://gcc-ca.internet.bs, thanks to 
Internet.bs (info at internet dot bs)
 China: ftp://linuxforum.net/ftp.gcc.gnu.org/";>ftp://linuxforum.net/ftp.gcc.gnu.org/,
 thanks to David Deng (david99deng at yahoo dot com)
 France (no snapshots): ftp://ftp.lip6.fr/pub/gcc/";>ftp.lip6.fr, thanks to ftpmaint at lip6 
dot fr

Re: Where does the time go?

[Steven Bosscher]

On Mon, May 24, 2010 at 6:20 PM, Mark Mitchell  wrote:
> Joseph S. Myers wrote:
>
>>> All in all, perhaps not the most efficient representation for memory
>>> foot print, and the pointer chasing probably doesn't help (cache!).
>>> But changing it is a lot more difficult than the GIMPLE tuples
>>> project. I don't think it can be done.
>>
>> I don't see any reason technically why it can't be done.  There would be
>> several large projects, certainly, and nontrivial work in actually
>> producing a design for conversion, but there are also clear incremental
>> steps, such as static typing of some different kinds of RTL and moving to
>> more specific accessors for parts of an RTX in place of generic ones such
>> as XEXP used at present.  If it can't be done then that would be more for
>> economic reasons - no-one benefiting enough from the change, potential
>> benefits being gained more cheaply in other ways - than because of
>> intrinsic technical obstacles.
>
> I completely agree.  This is a tractable problem, approximately on the
> same scale as GIMPLE tuples.

Great you all do semantics :-)

So I said "impossible". Perhaps I should have said "of course
technically feasible (for the non-faint of heart) but unlikely to
happen given the considerable investment required, the technical
complexity and risk involved, the unclear and uncertain
return-on-investment in both the short and long terms, and perhaps the
availability of better options such as the GIMPLE backend (xf.
http://gcc.gnu.org/wiki/gimplebackend)".

>  I would guess approximately a person-year,
> perhaps spread out over a longer time.

No-one will know for sure, but I think this approximation is a bit too
optimistic:

* Just in gcc/, all gimple/tree code is less than 200,000 lines of
code and all rtl code is >400,000 lines of code. I am not even going
to count in config/*.
*  For RTL if you access XEXP you don't know if you will see an
operand or an expression. The GIMPLE tuples project was relatively
easy because most GIMPLE passes already access operands through the
SSA operands system.
* For RTL, expressions can be of arbitrary complexity (machine
dependent forms), while for GIMPLE the number of instruction templates
is limited.
* For RTL, one would have to test many different configurations to
avoid breaking things. The code to be modified for GIMPLE tuples was
mostly target-independent (compared to all the RTL code in config/*).

The GIMPLE tuples work took man-years (note: plural). There was less
code to convert and the process of conversion was easier, relatively,
than the conversion of RTL would be. So your one person-year seems
grossly underestimated.

Not that I would discourage anyone from doing the work, but it seems
to me that resources would be better spent on something that actually
has clear pay-off in the hopefully shorter term (such as
http://gcc.gnu.org/wiki/ModularGCC, or indeed
http://gcc.gnu.org/wiki/gimplebackend).

Ciao!
Steven

Re: LTO and libelf (and FreeBSD)

[Gerald Pfeifer]

On Sun, 23 May 2010, Kai Wang wrote:
>> Based on this, it will be great if you can apply your patch to 
>> -CURRENT, 8-STABLE and 7-STABLE.
> I'll see what I can do.

Thanks!

> The elf_update() failure is caused by an alignment check inside
> FreeBSD elf_update(). [...]
> Anyway, I attached a patch for FreeBSD libelf which removes the
> d_align check against section aligment. Please try applying it to a
> vanilla FreeBSD 7.3 libelf (The patch includes the previous
> elf_getbase() change) and run the gcc test suite again...

This works like a charm, and we now go from 
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg02150.html
to
http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg02245.html
basically fixing all of LTO and WHOPR, see below for details:


=== g++ Summary === vanilla patched Richard's   latest
libelf  GCC patch   libelf+
Richard's

# of expected passes22876   23118   23118   23361
# of unexpected failures425 142 142 7 <===
# of expected failures  151 151 151 151
# of unresolved testcases   124 66  66  5 <===
# of unsupported tests  150 150 150 150

=== gcc Summary ===

# of expected passes64021   67099   67099   70184
# of unexpected failures380616671667102 <===
# of unexpected successes   1   1   1   1
# of expected failures  171 171 171 171
# of unresolved testcases   2580129212927 <===
# of unsupported tests  1284128412841284

=== gfortran Summary === (one test added for the last run)

# of expected passes34094   34122   34123   34145
# of unexpected failures48  27  27  11 <===
# of expected failures  22  22  22  22
# of unresolved testcases   37  16  16  0 <===
# of unsupported tests  266 266 266 266


What is your plan of applying these patches to libelf in FreeBSD?

Gerald

Re: Deprecating ARM FPA support

[Martin Guy]

On 5/24/10, Mark Mitchell  wrote:
>  > Certainly removing support for FPA (and any targets that require it) as
>  > a first step would be an option; but we should also focus on where we
>  > want to get to.
>
>  I agree with that.  But, it would also be interesting to know just how
>  broken that code is.  If, in fact, FPA and/or ARM ELF mostly work at
>  present, then there's less call for actually removing (as opposed to
>  deprecating) things.

FPA code generation is 100% good AFAIK, and has been used intensively
for years (as the FPU model for all gnu/linux ports before EABI).

Maverick is the one that has never worked since it was submitted; I
have patches that make it 100% good (well, ok, no known failure cases)
but don't know how to get them into mainline.

M

Re: Where does the time go?

[Mark Mitchell]

Steven Bosscher wrote:

> The GIMPLE tuples work took man-years (note: plural). There was less
> code to convert and the process of conversion was easier, relatively,
> than the conversion of RTL would be. So your one person-year seems
> grossly underestimated.

I dunno.  To get good project estimates, you have to break things down
into small enough subpieces that you have good confidence in the
estimates.  I certainly don't claim a high level of confidence in my
estimate.  But, it's a largely mechanical activity; we're not talking
about changing algorithms, but rather about changing data representations.

As to whether this is a better choice than working on GIMPLE back-ends,
I think that's unclear.  There's no question that a GIMPLE back-end
would be prettier.  I think it's a question of what your goals are.  If
your goal is a faster compiler with less memory usage, I bet converting
RTL to a better representation is a faster path to that solution.  If
your goal is to have one representation all the way through to ease
future maintenance and make it easier to do plugins at all stages of
compilation and so forth, then a better representation for RTL doesn't
really help you.

I'd accept either set of patches, if someone were to provide them.

-- 
Mark Mitchell
CodeSourcery
m...@codesourcery.com
(650) 331-3385 x713

Re: Where does the time go?

[Joseph S. Myers]

On Mon, 24 May 2010, Mark Mitchell wrote:

> As to whether this is a better choice than working on GIMPLE back-ends,
> I think that's unclear.  There's no question that a GIMPLE back-end
> would be prettier.  I think it's a question of what your goals are.  If

I don't think of the two as being mutually exclusive; the end point of a 
series of improvements to RTL types and datastructures could be that RTL 
ends up as a form of GIMPLE, if the changes are planned that way (and if 
you are making such changes to RTL, the advantages of moving towards 
low-GIMPLE are clear).

-- 
Joseph S. Myers
jos...@codesourcery.com

Sterling Augustine appointed Xtensa port maintainer

[David Edelsohn]

I am pleased to announce that the GCC Steering Committee has
appointed Sterling Augustine as maintainer of the Xtensa port.

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

Happy hacking!
David

unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel

[Philip Pemberton]

Hi guys,
About a month ago I opened a bug on Bugzilla:
  http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43805

This relates to gcc crashing out with an Internal Compiler Error when 
doing a build of Linux kernel 2.6.34-rc4. Basically, as soon as the 
build hits fs/timerfd.c, an ICE is thrown:


fs/timerfd.c: In function ‘timerfd_poll’:
fs/timerfd.c:105:1: error: unrecognizable insn:
(insn 44 43 45 5 fs/timerfd.c:94 (set (reg:SI 68)
(subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
(const_int 64 [0x40])) [0 S8 A64]) 4)) -1 (nil))
fs/timerfd.c:105:1: internal compiler error: in extract_insn, at 
recog.c:2103

Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Compiling without -O2 allows the build to get a little further, but it 
falls over on mm/filemap.c:


mm/filemap.c: In function ‘do_generic_file_read’:
mm/filemap.c:1171:1: error: unrecognizable insn:
(insn 402 401 403 20 mm/filemap.c:1029 (set (reg:SI 389)
(subreg:SI (mem/c/i:DI (plus:SI (reg/f:SI 33 virtual-stack-vars)
(const_int -52 [0xffcc])) [0 isize+0 S8 
A64])

4)) -1 (nil))
mm/filemap.c:1171:1: internal compiler error: in extract_insn, at 
recog.c:2103


The full details are in the bug report, along with the compiler command 
line, .i file and preprocessed source. Seeing as it's been over a month 
and nothing seems to have happened with the bug, I'd like to have a go 
at fixing it myself...


I have a couple of questions:

1) Who's the current maintainer for the lm32 port? Jon Beniston?
I can't see anything on the gcc website that says definitively "target X 
is maintained by $PERSON", and I really don't want to step on his/her 
toes and start a flame war, turf war or any other kind of war here...


2) What are these error messages telling me? Is there a "decoding ICE 
Error Messages HOWTO" for aspiring GCC developers?


3) I've established that the bug has been present in the lm32 port since 
it was merged into the mainline GCC source. What part of the gcc source 
should I start digging into first?


I guess ultimately I'm just asking for a few starting points from the 
gurus here... :)


Thanks,
Phil.

A question about _udivdi3.o in libgcc.a on Loongson platform

[Ling Kun]

Hi all,
   when deeply looking into the libgcc.a of
mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
_udivdi3.o. but when objdump this object file, no entry for function
_udivdi3 is found, only a __udivti3 function entry, and there are also
some other *di3.o file which only   *ti3  can find.
   However, in x86 platform, i686-pc-linux-gnu-gcc-4.4.3. I can find
_udivdi3 in _udivdi3.o .
  The question is why?
 why in mips64el.
$nm --print-armap libgcc.a
.
_udivdi3.o:
         U __clz_tab
 T __udivti3
.
while in i686-pc
$nm --print-armap libgcc.a
.
_udivdi3.o:
 T __udivdi3
..
I know there are some architecture difference, but  as in
gcc/doc/gccint.info says:
 -- Runtime Function: unsigned long __udivdi3 (unsigned long A,
          unsigned long B)
 -- Runtime Function: unsigned long long __udivti3 (unsigned long long
          A, unsigned long long B)
why mips64el doesn't   need a runtime function entry for _udivdi3  ?
Thanks,
Ling Kun
--
http://www.lingcc.com

Re: unrecognizable insn ICE in latticemico32 (lm32-elf) when building Linux kernel

[Ian Lance Taylor]

Philip Pemberton  writes:

> 1) Who's the current maintainer for the lm32 port? Jon Beniston?
> I can't see anything on the gcc website that says definitively "target
> X is maintained by $PERSON", and I really don't want to step on
> his/her toes and start a flame war, turf war or any other kind of war
> here...

The official list of maintainers is stored in the gcc source code in
the file MAINTAINERS.  Having said that, there is no maintainer listed
for lm32.  I assume that it must be, as you suggest, Jon Beniston.


> 2) What are these error messages telling me? Is there a "decoding ICE
> Error Messages HOWTO" for aspiring GCC developers?

That ICE is telling you that an RTL insn was generated for some reason
but there is no matching define_insn in the CPU MD file.  In this case
it is an SImode move using a SUBREG.

The address is unusual:

(subreg:SI (mem/s:DI (plus:SI (reg/v/f:SI 39 [ ctx ])
(const_int 64 [0x40])) [0 S8 A64]) 4)

Why isn't that simply

(mem/s:SI (plus:SI (reg/v/f:SI 39 [ ctx ])
   (const_int 68 [0x40])) [0 S8 A64])

That makes it look like something is creating a subreg without going
through simplify_gen_subreg.

It's also possible that the problem is simply that
lm32_legitimate_address_p needs to handle a SUBREG memory address.


> 3) I've established that the bug has been present in the lm32 port
> since it was merged into the mainline GCC source. What part of the gcc
> source should I start digging into first?

See above.

Ian

Re: A question about _udivdi3.o in libgcc.a on Loongson platform

[Ian Lance Taylor]

Ling Kun  writes:

>    when deeply looking into the libgcc.a of
> mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
> _udivdi3.o. but when objdump this object file, no entry for function
> _udivdi3 is found, only a __udivti3 function entry, and there are also
> some other *di3.o file which only   *ti3  can find.
>    However, in x86 platform, i686-pc-linux-gnu-gcc-4.4.3. I can find
> _udivdi3 in _udivdi3.o .
>   The question is why?

mips64 is a 64-bit target which i686 is a 32-bit target.  In general
the names of the files in libgcc are always based on 32-bit targets,
but the function names are based on twice the size of a register word.


> why mips64el doesn't   need a runtime function entry for _udivdi3  ?

Because mips64 has the ddivu instruction which implements unsigned
DImode division directly.

Ian

Re: A question about _udivdi3.o in libgcc.a on Loongson platform

[Ling Kun]

Thank you Ian Lance Taylor. Your reply helps me a lot :)

Ling Kun

On Tue, May 25, 2010 at 1:10 PM, Ian Lance Taylor  wrote:
> Ling Kun  writes:
>
>>    when deeply looking into the libgcc.a of
>> mips64el-unknown-linux-gnu-gcc-4.4.3, I found a object file
>> _udivdi3.o. but when objdump this object file, no entry for function
>> _udivdi3 is found, only a __udivti3 function entry, and there are also
>> some other *di3.o file which only   *ti3  can find.
>>    However, in x86 platform, i686-pc-linux-gnu-gcc-4.4.3. I can find
>> _udivdi3 in _udivdi3.o .
>>   The question is why?
>
> mips64 is a 64-bit target which i686 is a 32-bit target.  In general
> the names of the files in libgcc are always based on 32-bit targets,
> but the function names are based on twice the size of a register word.
>
>
>> why mips64el doesn't   need a runtime function entry for _udivdi3  ?
>
> Because mips64 has the ddivu instruction which implements unsigned
> DImode division directly.
>
> Ian
>



-- 
http://www.lingcc.com

RFC 2821 violation by GCC Bugzilla

[Andrew Church]

To whom it may concern:

I'm writing to let you know that the GCC Bugzilla appears to be
misconfigured such that it sends the following MAIL FROM line:

MAIL FROM:<"bugzilla-admin-daemon\n"@sourceware.org>

where the "\n" is a literal newline character (ASCII 10).  This violates
RFC 2821 section 4.1.2:

   Systems MUST NOT define mailboxes in such a way as to require the use
   in SMTP of non-ASCII characters (octets with the high order bit set
   to one) or ASCII "control characters" (decimal value 0-31 and 127).
   These characters MUST NOT be used in MAIL or RCPT commands or other
   commands that require mailbox names.

My MTA rejects return-path addresses containing control characters for
security reasons, and thus I am currently unable to change the E-mail
address for my GCC Bugzilla account (gcczil...@achurch.org, which appears
to have been harvested by a spammer so I am attempting to change it).

Could you please look into resolving this configuration problem?

Thanks in advance,

  --Andrew Church
achu...@achurch.org
http://achurch.org/