Re: C++ FE question: When is CLASSTYPE_VBASECLASSES valid?

[Doug Kwan (關振德)]

Thanks Mark.  I am using classes after they are defined. So it should
be okay for me.

-Doug

2008/3/19 Mark Mitchell <[EMAIL PROTECTED]>:
>
> Doug Kwan (關振德) wrote:
>
>  > I have a question about the validity of CLASSTYPE_VBASECLASSES.
>  > Due to templates, it is not possible to know if a class has virtual
>  > bases or not until the class is fully instantiated.  Is checking
>  > processing_template_decl sufficient to guarantee that
>  > CLASSTYPE_VBASECLASSES is valid?
>
>  No; if the class is presently being defined, that will not be set.
>  However, it should be safe to check that for a complete class when
>  !processing_template_decl.
>
>  --
>  Mark Mitchell
>  CodeSourcery
>  [EMAIL PROTECTED]
>  (650) 331-3385 x713
>
>

Re: [trunk] Addition to subreg section of rtl.text.

[Paolo Bonzini]

I think one reason is that allowing zero_extracts of multi-word modes is
(like this subreg thing) a little hard to pin down.  What happens when
WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN


Unless I had my grep wrong, the only such machines to do this are PDP11 
and ARM with special flags (-mbig-endian -mwords-little-endian) that 
were "for backward compatibility with older versions of GCC" in 1999 [1].


So, is this special case worth keeping?

Paolo

[1] 
http://www.ecos.sourceware.org/ecos/docs-1.2.1/ref/gnupro-ref/arm/index.html

Re: [trunk] Addition to subreg section of rtl.text.

[Richard Sandiford]

Sorry for snipping a lot, but I think the important bit was...

Joern Rennecke <[EMAIL PROTECTED]> writes:
> But the SUBREGS and ZERO_EXTRACTs should still mean the same with respect to
> selecting groups of bits.  You simply don't know which of them mean anything
> and what their positional value is, if any, but you shouldn't need to.
> So in that respect, it still behaves "as if" the natural byte order applies.

OK, so I think you're saying (here and elsewhere) that partial modes
behave "as if" their widths were rounded up to the next word boundary,
but that an unspecified collection of bits in the extended width will
read as undefined?  Thus just as:

  (set (subreg:HI (reg:QI ...) ...) (const_int 0))

does not guarantee that (subreg:HI (reg:QI ...) ...) has the value 0,
you're saying that, for any valid values of M and X:

  (set (subreg:M (reg:N ...) X) (const_int 0))

does not guarantee that (subreg:M (reg:N ...) ...) has the value 0
if N is a partial mode?

Sounds OK to me FWIW.  But we should spell this out in the
documentation.

>> Yes, MIPS is one such port, but we expressly forbid conversions
>> between full-width and partial-width modes for the very reason
>> given in mainline rtl.texi:
>> 
>> It is also not valid to access a single word of a multi-word value in a
>> hard register when less registers can hold the value than would be
>> expected from its size.  For example, some 32-bit machines have
>> floating-point registers that can hold an entire @code{DFmode} value.
>> If register 10 were such a register @code{(subreg:SI (reg:DF 10) 4)}
>> would be invalid because there is no way to convert that reference to
>> a single machine register.  The reload pass prevents @code{subreg}
>> expressions such as these from being formed.
>
> The reasoning there is flawed.  You could still identify a specific hard
> register when you are presented with a DFmode subreg of a DCmode or V2DFmode
> inner register.
> And @code{(subreg:SI (reg:DF 10) 0)} would be a natural way to express that
> you are using the floating point register as a 32 bit integer register,
> with writes clobbering the entire 64 bit of the register.

Yes, this is one possible definition.  But there's no reason in this
situation why you couldn't just use a single REG.  Why use subregs at all?

I thought in the earlier post, you were suggesting that it should be
OK to represent a doubleword register that has individually-addressable
words as a single register if most accesses were of the doubleword variety.
I thought you were then saying that you could use (subreg:SI (reg:DF ...) ...)
to refer to the individually-addressable parts.  In that scenario you
_wouldn't_ want (subreg:SI (reg:DF 10) 0) to clobber the whole register.

Which brings us back to Richard K's point about phasing out hard subregs
completely.

>> > IIRC you have to do something like (SUBREG:SI (SUBREG:DI (REG:DF...
>> > and even spread it across multiple instruction patterns.
>> > I don't see why we should be picky about the MODE_CLASS of inner or
>> > outer modes of SUBREGs.
>> 
>> My understanding was that nested subregs aren't allowed (any more).
>
> That's why I taked about spreading it across multiple instruction patterns.
> Unfortunately that can leave you with multiple machine instructions
> where one would do, just because the middle-end is in denial that these
> things might exist.

It just seems to me that, by the time you get to the stage of having
multiple instructions for a single write, you've lost any advantage
you've gained by avoiding unspecs.

Do any mainline ports do this, or are you talking about private ports?

>> > registers to make this work sanely.  Also, group spill allocation
>> > has extra costs in several ways, so if the predominant way to use the
>> > wide registers is to use them as a whole, it is still desirable to
>> > model them as wide registers and have the narrower accesses use
>> > SUBREG and/or zero_extract.
>> 
>> As above, I think the rtl.texi documentation makes this invalid (and this
>> is a long-standing restriction).
>
> Well, Kenny also asked 'are the rules we've got here right?'.

I think this was more a case of "do the rules we wrote reflect
the current situation correctly".  We weren't wanting to _change_
the semantics, but simply asking whether we'd pinned down the
current semantics.

> I think some of the rules are overly restrictive, and prevent gcc
> from archiving its full potential for generating efficient code.
> Moreover, if a port has an extv / insv pattern that matches in mode with the
> wide registers, it can legitimately use the zero_extract route.  It's
> reload that contradicts the documentation in changing registers into MEMs
> and thus creating zero_extracts from wide MEMs.

It sounds like you might be referring to both the subreg and extract
documentation here.  As far as the subreg documentation goes,
let's assume that what I said above about partial modes is right
(you'll hav

Re: [trunk] Addition to subreg section of rtl.text.

[Richard Sandiford]

Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> I think one reason is that allowing zero_extracts of multi-word modes is
>> (like this subreg thing) a little hard to pin down.  What happens when
>> WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN
>
> Unless I had my grep wrong, the only such machines to do this are PDP11 
> and ARM with special flags (-mbig-endian -mwords-little-endian) that 
> were "for backward compatibility with older versions of GCC" in 1999 [1].
>
> So, is this special case worth keeping?

Good question.  Unless I'm missing something, PDP11 isn't yet on the
deprecrated list.  Is that right?  If so, I suppose we can't remove
it before 4.5 at the earliest.

Richard

Re: [trunk] Addition to subreg section of rtl.text.

[Paolo Bonzini]

Richard Sandiford wrote:

Paolo Bonzini <[EMAIL PROTECTED]> writes:

I think one reason is that allowing zero_extracts of multi-word modes is
(like this subreg thing) a little hard to pin down.  What happens when
WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN
Unless I had my grep wrong, the only such machines to do this are PDP11 
and ARM with special flags (-mbig-endian -mwords-little-endian) that 
were "for backward compatibility with older versions of GCC" in 1999 [1].


So, is this special case worth keeping?


Good question.  Unless I'm missing something, PDP11 isn't yet on the
deprecrated list.  Is that right?  If so, I suppose we can't remove
it before 4.5 at the earliest.


It was in the 4.3 list, then Paul Koning stepped up to do some work on 
it but then nothing happened.


[context for Paul: PDP-11 is the last target for which BYTES_BIG_ENDIAN 
!= WORDS_BIG_ENDIAN]


http://gcc.gnu.org/ml/gcc/2008-01/msg00339.html

Paolo

Re: [trunk] Addition to subreg section of rtl.text.

[Paolo Bonzini]

(Yes, the documentation suggests byte_mode for MEMs, but the SH port
uses zero_extracts of SImode MEMs as well, so presumably we're supposed
to support other modes besides the documented ones.)


I think it is just that no one cares about a MEM's mode in this case.

Paolo

Re: [trunk] Addition to subreg section of rtl.text.

[Richard Kenner]

> > I think one reason is that allowing zero_extracts of multi-word modes is
> > (like this subreg thing) a little hard to pin down.  What happens when
> > WORDS_BIG_ENDIAN && !BYTES_BIG_ENDIAN
> 
> Unless I had my grep wrong, the only such machines to do this are PDP11 
> and ARM with special flags (-mbig-endian -mwords-little-endian) that 
> were "for backward compatibility with older versions of GCC" in 1999 [1].
> 
> So, is this special case worth keeping?

I'd argue yes, whether or not such machines exist because of
orthogonality concerns: there's value in supporting all four possibilities.

Obvious problem with Ada front-end patches handling

[Samuel Tardieu]

Samuel Tardieu wrote:

> I cannot seem to find an answer to this PING message from last
> December.
> 
> > Subject: [PATCH] ada: Do not let a type in an aggregate be an ancestor
> >  of itself
> > Date:Thu, 29 Nov 2007 11:43:44 +0100
> > URL: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01670.html
> > 
> > Subject: [PATCH] ada: Do not optimize X*(2**Y) in a modular context
> > Date:Tue, 20 Nov 2007 17:02:43 +0100
> > URL: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01215.html
> > 
> > Subject: [PATCH] ada: Simplify redundant test
> > Date:Sat, 17 Nov 2007 16:03:15 +0100
> > URL: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01216.html
> > 
> > Subject: [PATCH] ada: Do not save and restore environment if generic
> >  instance is a top-level one
> > Date:Tue, 20 Nov 2007 14:49:19 +0100
> > URL: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01214.html
> > 
> > Subject: [PATCH] ada: Do not allow "use" of something which is not a
> >  package
> > Date:Tue, 20 Nov 2007 15:56:08 +0100
> > URL: http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01212.html

Still no answer after two PING (December and February, for patches
submitted in November, and there are others not mentionned here). Is
there any Ada front-end maintainer handling patches proposals?

Since 2007-12-19, which is the date of the latest AdaCore batch
merge (three months ago), the Ada front end has only received the
following patches:

  - platform-specific and build-related patches

  - gigi (Ada structures -> GCC structures) patches from Éric Botcazou
in *.c files

  - typos and documentation patches

  - two patches from me:

  - one which happened to have been integrated in AdaCore version and
announced as a new feature on their web site without me
receiving a ACK (nor a NACK) to check it in the FSF tree
(http://thread.gmane.org/gmane.comp.gcc.patches/153380/focus=157411)

  - one which is a 4.3 regression for which I never received a ACK
(nor a NACK) to check it in the 4.3 branch
(http://thread.gmane.org/gmane.comp.gcc.patches/157121/focus=157407)

Most if not all other Ada front-end patches have received no answer.

Maybe the patches are wrong and need some more work, but it is really
frustrating to get no feedback at all. Not many people volunteer to
work on Ada-related bug reports from the community against the FSF
version, and when they do, it sometimes appears completely useless.

>From MAINTAINERS:

| Ada front end   Geert Bosch [EMAIL PROTECTED]
| Ada front end   Robert Dewar[EMAIL PROTECTED]
| Ada front end   Arnaud Charlet  [EMAIL PROTECTED]

I am perfectly fine with all three Ada front end maintainers being
from AdaCore, but at this time it looks like the FSF GNAT front end is
totally stalled because of this. I want to know if I am wasting my
time trying to get the FSF GNAT version in a better shape, in which
case I can certainly use it on something more productive.

 Sam
-- 
Samuel Tardieu -- [EMAIL PROTECTED] -- http://www.rfc1149.net/

Re: Obvious problem with Ada front-end patches handling

[Arnaud Charlet]

> Still no answer after two PING (December and February, for patches
> submitted in November, and there are others not mentionned here). Is
> there any Ada front-end maintainer handling patches proposals?

Yes, as can be seen by other discussions on other patches.

> Since 2007-12-19, which is the date of the latest AdaCore batch
> merge (three months ago), the Ada front end has only received the
> following patches:

Right, which is because GCC was in stage3 until recently, causing most
patches/development to be delayed.

I'm working on contributing many changes that were delayed because of
stage3, which is why your patches haven't been reviewed yet.

Once this part is done, we can evaluate where we are. Maybe some of your
changes will have already been addressed, or will need some small updates,
which is why it makes sense to wait a little bit.

Note that there are many patches that we've submitted in other parts of
GCC that also never receive any attention, so it's certainly not something
specific to Ada.

Concerning Ada, the situation is specific to the fact that stage3 (and in
particular the last few monthes in regression/fixes only) caused things to
be frozen, and we're now recovering from this state. I do not know if the
situation is similar for other patches (e.g. middle-end or back-end patches).

Arno

Re: Obvious problem with Ada front-end patches handling

[Joel Sherrill]

Did you ever get around to looking at my hardware
interrupt task patch?  I know it dates back to Nov/Dec
but I quite asking about it during stage 2.  I submitted
it a couple of times this month on gcc-patches and
filed this PR so it wouldn't get lost.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576

-joel

Arnaud Charlet wrote:

Still no answer after two PING (December and February, for patches
submitted in November, and there are others not mentionned here). Is
there any Ada front-end maintainer handling patches proposals?



Yes, as can be seen by other discussions on other patches.

  

Since 2007-12-19, which is the date of the latest AdaCore batch
merge (three months ago), the Ada front end has only received the
following patches:



Right, which is because GCC was in stage3 until recently, causing most
patches/development to be delayed.

I'm working on contributing many changes that were delayed because of
stage3, which is why your patches haven't been reviewed yet.

Once this part is done, we can evaluate where we are. Maybe some of your
changes will have already been addressed, or will need some small updates,
which is why it makes sense to wait a little bit.

Note that there are many patches that we've submitted in other parts of
GCC that also never receive any attention, so it's certainly not something
specific to Ada.

Concerning Ada, the situation is specific to the fact that stage3 (and in
particular the last few monthes in regression/fixes only) caused things to
be frozen, and we're now recovering from this state. I do not know if the
situation is similar for other patches (e.g. middle-end or back-end patches).

Arno
  



--
Joel Sherrill, Ph.D. Director of Research & Development
[EMAIL PROTECTED]On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
  Support Available (256) 722-9985

Re: Obvious problem with Ada front-end patches handling

[Arnaud Charlet]

> Did you ever get around to looking at my hardware
> interrupt task patch?  I know it dates back to Nov/Dec
> but I quite asking about it during stage 2.  I submitted

I reviewed it during stage 2 and gave you my comments (the patch was not quite
ready at this time).

> it a couple of times this month on gcc-patches and
> filed this PR so it wouldn't get lost.
> 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35576

Right, that's on the pipeline. There are other pending changes which are
actually older than that in s-interr-vxworks.adb, so I'm working on these
before getting to reviewing your patch, but do not worry, I haven't
ignored or forgotten it.

Arno

Re: [trunk] Addition to subreg section of rtl.text.

[Joern Rennecke]

On Thu, Mar 20, 2008 at 10:39:47AM +, Richard Sandiford wrote:
> you're saying that, for any valid values of M and X:
> 
>   (set (subreg:M (reg:N ...) X) (const_int 0))
> 
> does not guarantee that (subreg:M (reg:N ...) ...) has the value 0
> if N is a partial mode?

Yes.  Although it will be more common for 1 bits to change to zero, some bits
might actually differ between successive reads, when these bits are status
flags.  AFAICR there was even some processor that had a level-sensitive
I/O port bit mapped in its status register.

> > And @code{(subreg:SI (reg:DF 10) 0)} would be a natural way to express that
> > you are using the floating point register as a 32 bit integer register,
> > with writes clobbering the entire 64 bit of the register.
> 
> Yes, this is one possible definition.  But there's no reason in this
> situation why you couldn't just use a single REG.  Why use subregs at all?

Because before reload, you use pseudos.  And in order for
(subreg:SI (reg:DF ...) ...) to be viable, it still has to be viable between
hard register allocation and alter_reg.

> I thought in the earlier post, you were suggesting that it should be
> OK to represent a doubleword register that has individually-addressable
> words as a single register if most accesses were of the doubleword variety.
> I thought you were then saying that you could use (subreg:SI (reg:DF ...) ...)
> to refer to the individually-addressable parts.  In that scenario you
> _wouldn't_ want (subreg:SI (reg:DF 10) 0) to clobber the whole register.

Well, yes, but then it would be the exception, so you
could use strict_low_part.  Or zero_extract if we say that's OK.

> >> My understanding was that nested subregs aren't allowed (any more).
> >
> > That's why I taked about spreading it across multiple instruction patterns.
> > Unfortunately that can leave you with multiple machine instructions
> > where one would do, just because the middle-end is in denial that these
> > things might exist.
> 
> It just seems to me that, by the time you get to the stage of having
> multiple instructions for a single write, you've lost any advantage
> you've gained by avoiding unspecs.

You will at times see the various SUBREGs be generated from C code.
The restrictions on nested subregs and MODE_CLASS matching will mean
that the instructions using these SUBREGs cannot be combined by cse or
combine.

> > I think some of the rules are overly restrictive, and prevent gcc
> > from archiving its full potential for generating efficient code.
> > Moreover, if a port has an extv / insv pattern that matches in mode with the
> > wide registers, it can legitimately use the zero_extract route.  It's
> > reload that contradicts the documentation in changing registers into MEMs
> > and thus creating zero_extracts from wide MEMs.
> 
> It sounds like you might be referring to both the subreg and extract
> documentation here.  As far as the subreg documentation goes,
> let's assume that what I said above about partial modes is right
> (you'll have already corrected me by now if not).  If we change the
> rules to say that, what do you think is still overly restrictive?

- zero_extract officially only allowed for a specific mode.
- nested subregs not allowed, but neither are all subregs that
  would result from substituting a subreg into an inner reg of another
  subreg and simplifying allowed.
- highpart subregs not allowed (e.g. consider SH64 floating point registers:
  word_mode is 64, but the floating point registers are 32 bit.  How do
  you refer to the high part of a DFmode value, considering that the
  inner reg might be allocated to a floating value.  (Actually, generally
  want such an allocation).)
> A specific edit to our rtl.texi proposal would probaby be helpful
> at this stage.

Sorry, have to wait for Copyright Assignment :-(

> 
> E.g. one possibility would be to drop:
> 
> If @var{reg} is a hard register, the @code{subreg} must also represent
> the lowpart of a particular hard register, or represent one or more
> complete hard registers.
> 
> and instead say that the word-based semantics for pseudo registers also
> apply to hard registers, regardless of the number of hard registers in
> the inner register.  This would in some ways be simpler.

Yes.  If subword-writing semantics are wanted, and the SUBREG represents
an actual hard register, than the port has to use a proper hard reg instead.
And it makes semantics much saner when we do register allocation for a
pseudo where we don't know the register size to start with.
What would make this still somewhat saner, though, would be if we had
a mechanism to make the subreg mechanism use different word sizes for
different inner modes for the purpose of identifying regions that are
wholely clobbered.  So, if you have 64 bit word_mode, but 32 bit floating
point registers, you could say that SUBREGS for floating point modes should
behave like you had a 32 bit word_mode.
Conversely, if you have 128 bit vect

Re: Obvious problem with Ada front-end patches handling

[Arnaud Charlet]

> Since 2007-12-19, which is the date of the latest AdaCore batch
> merge (three months ago), the Ada front end has only received the
> following patches:
> 
>   - platform-specific and build-related patches
> 
>   - gigi (Ada structures -> GCC structures) patches from Éric Botcazou
> in *.c files

Note that to clarify this specific point: most of the last four monthes
where in stage3, which is why little changes were done in the Ada front-end,
as in other parts of GCC.

Since GCC is in stage1, there have also been several breakage of the Ada
compiler, that have also caused some delays in testing and synchronizing
our changes, since all our changes are also tested against the FSF test
suite of course.

In addition, Eric's changes are definitely part of AdaCore's regular
synchronizations to the FSF tree, and these represent quite a few critical
changes. So your impression that "no changes have been made to the FSF tree by
AdaCore for 3 monthes" is incorrect.

As I said, I am working on  putting many changes at the FSF tree right now,
which should happen within the next few weeks, and for a week or so, since there
are many patches to test and incorporate.

I hope this clarifies things.

Arno

Re: Obvious problem with Ada front-end patches handling

[Samuel Tardieu]

On 20/03, Arnaud Charlet wrote:

| > Since 2007-12-19, which is the date of the latest AdaCore batch
| > merge (three months ago), the Ada front end has only received the
| > following patches:
| > 
| >   - platform-specific and build-related patches
| > 
| >   - gigi (Ada structures -> GCC structures) patches from Éric Botcazou
| > in *.c files
| 
| In addition, Eric's changes are definitely part of AdaCore's regular
| synchronizations to the FSF tree, and these represent quite a few critical
| changes. So your impression that "no changes have been made to the FSF tree by
| AdaCore for 3 monthes" is incorrect.

Éric patches hardly belong to what I call "AdaCore batch merges", that is:

  - large merges done in a very short period of time
  - no corresponding test cases or non-regression tests
  - no reference to existing PR
  - no closing of corresponding bugzilla entries

As a consequence, the last two items require that other people retest
the Ada bugs in bugzilla and close them if they happen to have been
fixed by chance by the last jumbo merge. If people don't do that, the
bugzilla is clogged with old useless entries and those volunteering to
fix Ada bugs in GCC (as I do) lose a lot of time figuring out which bug
they should work on and whether it is still relevant or not.

Éric patches do reference PR and add corresponding tests, as is done in
the rest of GCC and as yourself require before accepting contributed
patches for the Ada front-end. Doing a

  egrep '(adacore.com|act-europe.fr|gnat.com)' gcc/testsuite/ChangeLog

and comparing this to the gcc/ada/ChangeLog speaks for itself. So no, I
was definitely not talking about Éric patches when writing about "AdaCore
batch merges".

Moreover, either you consider that Éric changes are part of the Ada
front-end and this means that it was possible to get changes in, or you
consider that they are not part of the front-end (but rather the middle-end)
which means that the front-end is really stalled.

| As I said, I am working on  putting many changes at the FSF tree right now,
| which should happen within the next few weeks, and for a week or so, since 
there
| are many patches to test and incorporate.

That is in itself good news.

| I hope this clarifies things.

This partially explains why external patches were not approved, but this
doesn't explain why they didn't receive *any* feedback in a reasonable
time.

I certainly appreciate all the very high quality support I get from
AdaCore when working on fixing a bug in GNAT or trying to get a new
feature in, they have always been of tremendous help and it is always
a real pleasure to work with them. What I am disatisfied with is the
way Ada front-end maintainers for the FSF GNAT tree have been handling
(or rather not handling) patches for a few months without any explanation
and how large changes are pushed in without taking care of proper GCC
procedures.

Maybe you think that there is no problem here, but from a volunteering
contributor point of view, there is.

  Sam

Re: Obvious problem with Ada front-end patches handling

[Arnaud Charlet]

>   - large merges done in a very short period of time
>   - no corresponding test cases or non-regression tests
>   - no reference to existing PR
>   - no closing of corresponding bugzilla entries

I'm sorry, but that's simply wrong. Test cases are posted, and when suitable,
are added to the test suite. PR are referenced when such reference is
known. Correpsonding bugzilla entries are closed (I have closed dozens
of bugzilla entries in the past).

You have probably been unlucky to stumble into a few cases where a fix
was made that was done in parallel to an existing PR and thus, the PR
was not closed at the same time, but when a fix is known to address a PR,
it is mentioned and the PR is closed.

> Moreover, either you consider that Éric changes are part of the Ada
> front-end

Definitely.

> and this means that it was possible to get changes in, or you

Eric, as others, had to delay his changes during batch 3 and has only
recently done these changes. Since the number of changes I am handling
is much larger, this takes some more time, and the few Ada breakages have
also caused additional delays.

> I certainly appreciate all the very high quality support I get from
> AdaCore when working on fixing a bug in GNAT or trying to get a new
> feature in, they have always been of tremendous help and it is always
> a real pleasure to work with them. What I am disatisfied with is the
> way Ada front-end maintainers for the FSF GNAT tree have been handling
> (or rather not handling) patches for a few months without any explanation

Maybe that's partly because you are not following closely the development of
GCC and are not familiar with the GCC stages. Submitting patches during
stage3 (in particular end of stage3) is not really the most appropriate time,
so it's often better to wait for stage 1 or stage 2 for such submissions.

> and how large changes are pushed in without taking care of proper GCC
> procedures.

That's really unfair, our procedures for merging try to be as close as possible
to "proper" GCC procedures.

Arno

Lexer/cpplib improvements

[Alexey Salmin]

Hello!
I want to join the gcc development process and I decided that
Lexer/cpplib will be a good place to start. It's quite interesting for
me, I have some experience in this theme in few projects, fortunately
there is a http://gcc.gnu.org/onlinedocs/cppinternals/";>special
manual and http://gcc.gnu.org/wiki/Speedup_areas";>some
work to do.
Also I'd like to participate in the Google Summer of Code with this
project. Is it enough complicated? Is there any sense of writing an
application? Who can be my mentor?
Even if i don't join the GSOC I still need a person who can help me
sometimes with this task.

Alexey Salmin

Have proposals for 2008 gcc summit been reviewed?

[H.J. Lu]

We submitted 2 proposals for 2008 gcc summit. We got one reply
for one proposal on Mar. 15. But we haven't heard anything on
the other. April 1 is the deadline for paper if proposal is
accepted. Today is Mar. 20. I was wondering if anyone on
gcc mailing list could help us figure out what happened to
our other proposal.

Thanks.


H.J.

Re: Have proposals for 2008 gcc summit been reviewed?

[Benjamin Kosnik]

Hi HJ! 

If you look at the website, it says that the paper deadline has been
extended to April 11. It also has abstracts of the accepted talks: if
you submitted a paper and it's not here:
http://www.gccsummit.org/2008/speakers.php?types=TALK

Then I think it's safe to say that it was not accepted.

best,
benjamin

Re: Obvious problem with Ada front-end patches handling

[Samuel Tardieu]

On 20/03, Arnaud Charlet wrote:

| Maybe that's partly because you are not following closely the development of
| GCC and are not familiar with the GCC stages. Submitting patches during
| stage3 (in particular end of stage3) is not really the most appropriate time,
| so it's often better to wait for stage 1 or stage 2 for such submissions.

I was under the impression that stage 3 was perfectly fine to
submit bug fixes. Of the 5 patches I mentionned in the first mail
of this thread, 4 were bug fixes fitting the description outlined in
http://gcc.gnu.org/develop.html: "the only (non-documentation) changes
that may be made are changes that fix bugs or new ports which do not
require changes to other parts of the compiler."

Asking contributors to wait for stage 1 or 2 to submit bug fixes to the
Ada compiler is not a good way to encourage contributions. As a result,
those four bugs are still present in GCC 4.3.0 while fixes were proposed
in November, and since they were not regressions, are not likely to be
fixed in GCC 4.3.x releases either and will have to wait for GCC 4.4.0.

  Sam

Is vec_init allowed to FAIL?

[Jan Hoogerbrugge]

Hi,

I am trying to define vec_init. I can only do splats on register
values. So
operands[1] of vec_init should be registers and those registers should
be the same.

Here is some code:

(define_expand "vec_init"
[(match_operand:VEC_MODE32 0 "register_operand" "")
 (match_operand 1 "register_operand" "")]
""
{
if(trimedia_expand_vector_init(operands[0], operands[1]))
DONE;
else
FAIL;
}
)

int
trimedia_expand_vector_init (rtx target, rtx vals)
{
  enum machine_mode mode = GET_MODE (target);
  enum machine_mode inner_mode = GET_MODE_INNER (mode);
  int n_elts = GET_MODE_NUNITS (mode);
  rtx elem, tmp1, tmp2;
  int i;

  for (i = 0; i < n_elts; ++i)
{
  elem = XVECEXP (vals, 0, i);
  if (CONSTANT_P (elem))
return 0;
  if (!rtx_equal_p (elem, XVECEXP (vals, 0, 0)))
return 0;
}

  tmp1 = gen_reg_rtx (SImode);
  tmp2 = gen_reg_rtx (SImode);

  if (GET_MODE_SIZE (mode) == 4)
{
  if (inner_mode == QImode)
{
  emit_insn (gen_packqi (tmp1, elem, elem));
  emit_insn (gen_packhi (target, tmp1, tmp1));
  return 1;
}
  else if (inner_mode == HImode)
{
  emit_insn (gen_packhi (target, elem, elem));
  return 1;
}
}
  else if (GET_MODE_SIZE (mode) == 8)
{
  if (inner_mode == QImode)
{
  emit_insn (gen_packqi (tmp1, elem, elem));
  emit_insn (gen_packhi (tmp2, tmp1, tmp1));
  emit_insn (gen_packsi (target, tmp2, tmp2));
  return 1;
}
  else if (inner_mode == HImode)
{
  emit_insn (gen_packhi (tmp2, elem, elem));
  emit_insn (gen_packsi (target, tmp2, tmp2));
  return 1;
}
}

  return 0;
}

I see however that no code is generated if trimedia_expand_vector_init()
returns 0 and the define_expand FAILs. I also see in other targets that a
vec_init always ends with a DONE. Could it be that vec_init is not allowed to
FAIL?

Regards,
Jan

Unaligned attribute

[Jan Hoogerbrugge]

Hi,

I am looking for a way to specify that data is not aligned and that therefore
word accesses should be expanded into byte accesses. For example:

void f(__unaligned int *a)
{
  *a = 0;
}

Expands into 4 byte stores. Any suggestions on how to implement this?

Regards,
Jan

Exception handling on AIX5.3 with gcc 3.4.6

[Shlom Marom]

Hi guys,

I have some weird problem with exception handling on AIX (gcc 3.4.6
with AIX5.3), which I couldn't find any solution for in the web.

-
Problem description:
-
When throwing an exception of some derived object type, catch it,
re-throw it and then try to catch it by the base object, the program
gets segmentation fault instead of being caught by the relevant catch.
BUT, please not to the weirdest problem:
If I compiled the program with shared lib-gcc and with the pthread
libstdc++ - everything works fine and also the base exception is being
caught as it should.

*Attached here a very small cpp file that contains a simple, for your
convenient, although I will also paste the code in the email body…

-
The code:
-
#include 
void fun(void)
{
printf("in fun() - before throwing int...\n");
throw 1;
}
int main(void)
{
try
{
try
{
fun();
}
catch(int i)
{
printf("catch int exception: %d, and re-throw...\n", i);
throw;
}
}
catch (...)
{
   printf("the re-throw was caught...\n");
}
return 0;
}


Compilation (and link) commands:

Shared linking: gcc -o tester_shared main.cpp -pthread -I.
-shared-libgcc -L/usr/lib -ldl -lpthread -lstdc++
Static linking: gcc -o tester_static main.cpp -L/usr/lib/threads
-pthread -I. -static-libgcc -L/usr/lib -ldl -lpthread `gcc
-print-file-name=libstdc++.a` -O
*** `gcc -print-file-name=libstdc++.a` returns
/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/../../../libstdc++.a


Executables ldd output:

Shared linking:

$ldd ./tester_shared
/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/../../../libgcc_s_pthread.a(shr.o)
/usr/local/lib/gcc/powerpc-ibm-aix5.3.0.0/3.4.6/../../../pthread/libstdc++.a(libstdc++.so.6)
/usr/lib/libpthread.a(shr_xpg5.o)
/usr/lib/libpthread.a(shr_comm.o)
./tester_shared
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libc.a(shr.o)

Static linking:

$ldd ./tester_static
/usr/lib/libpthread.a(shr_xpg5.o)
/usr/lib/libpthread.a(shr_comm.o)
./tester_static
/usr/lib/libcrypt.a(shr.o)
/usr/lib/libc.a(shr.o)


Executables output:

Shared linking:

in fun() - before throwing int...
catch int exception: 1, and re-throw...
the re-throw was caught...

Static linking:

in fun() - before throwing int...
catch int exception: 1, and re-throw...
Segmentation fault (core dumped)



My purpose:

I need to find a way to fully support exception handling and
statically link libgcc, since I don't want to distribute it with my
libs and executables, as part of my products



Notes:


1. The same problem happens when instead of re-throw int and catch
(...) , you re-trow derived and catch base...
2. The same code works fine on other UNIX os, such as Linux (RHEL,
Fedora, etc.…)


Thanks in advanced,

Shlom Marom
#include 

void fun(void)
{
printf("in fun() - before throwing int...\n");
throw 1;
}

int main(void)
{
try
{
try
{
fun();
}
catch(int i)
{
printf("catch int exception: %d, and re-throw...\n", i);
throw;
}
}
catch (...)
{
printf("the re-throw was caught...\n");
}
return 0;
}

Re: Unaligned attribute

[Daniel Jacobowitz]

On Thu, Mar 20, 2008 at 04:27:42PM +0100, Jan Hoogerbrugge wrote:
> Hi,
> 
> I am looking for a way to specify that data is not aligned and that therefore
> word accesses should be expanded into byte accesses. For example:
> 
> void f(__unaligned int *a)
> {
>   *a = 0;
> }
> 
> Expands into 4 byte stores. Any suggestions on how to implement this?

Try __attribute__((__packed__))?

-- 
Daniel Jacobowitz
CodeSourcery

Re: Unaligned attribute

[pluto]

20/3/2008, "Jan Hoogerbrugge" <[EMAIL PROTECTED]> napisał/a:

>Hi,
>
>I am looking for a way to specify that data is not aligned and that therefore
>word accesses should be expanded into byte accesses. For example:
>
>void f(__unaligned int *a)
>{
>  *a = 0;
>}
>
>Expands into 4 byte stores. Any suggestions on how to implement this?

$ cat 0.c

typedef struct { unsigned value __attribute__(( packed ));
}unaligned_uint;

void f( unaligned_uint* p ) { p->value = 0; }

$ sparc-sun-solaris2.9-gcc 0.c -O2 -S produces:

f:
stb %g0, [%o0+3]
stb %g0, [%o0]
stb %g0, [%o0+1]
jmp %o7+8
stb%g0, [%o0+2]

Re: [trunk] Addition to subreg section of rtl.text.

[Bernd Schmidt]

Joern Rennecke wrote:

And @code{(subreg:SI (reg:DF 10) 0)} would be a natural way to express that
you are using the floating point register as a 32 bit integer register,
with writes clobbering the entire 64 bit of the register.

Yes, this is one possible definition.  But there's no reason in this
situation why you couldn't just use a single REG.  Why use subregs at all?


Because before reload, you use pseudos.  And in order for
(subreg:SI (reg:DF ...) ...) to be viable, it still has to be viable between
hard register allocation and alter_reg.


Is that even valid?  Are there any known ports using this?  AFAIR the 
middle-end doesn't create this (although it will use (subreg:SF (reg:DI)).



Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: [trunk] Addition to subreg section of rtl.text.

[Paolo Bonzini]

Bernd Schmidt wrote:

Joern Rennecke wrote:
And @code{(subreg:SI (reg:DF 10) 0)} would be a natural way to 
express that

you are using the floating point register as a 32 bit integer register,
with writes clobbering the entire 64 bit of the register.

Yes, this is one possible definition.  But there's no reason in this
situation why you couldn't just use a single REG.  Why use subregs at 
all?


Because before reload, you use pseudos.  And in order for
(subreg:SI (reg:DF ...) ...) to be viable, it still has to be viable 
between

hard register allocation and alter_reg.


Is that even valid?  Are there any known ports using this?  AFAIR the 
middle-end doesn't create this (although it will use (subreg:SF (reg:DI)).


SPE has patterns for

[(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
  (subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 4))]

for example.

Paolo

Re: [trunk] Addition to subreg section of rtl.text.

[Richard Sandiford]

Joern Rennecke <[EMAIL PROTECTED]> writes:
> On Thu, Mar 20, 2008 at 10:39:47AM +, Richard Sandiford wrote:
>> you're saying that, for any valid values of M and X:
>> 
>>   (set (subreg:M (reg:N ...) X) (const_int 0))
>> 
>> does not guarantee that (subreg:M (reg:N ...) ...) has the value 0
>> if N is a partial mode?
>
> Yes.  Although it will be more common for 1 bits to change to zero, some bits
> might actually differ between successive reads, when these bits are status
> flags.  AFAICR there was even some processor that had a level-sensitive
> I/O port bit mapped in its status register.

Well, the part you've quoted was only an example of the earlier,
more general statement:

   ... partial modes behave "as if" their widths were rounded up to the
   next word boundary, but that an unspecified collection of bits in the
   extended width will read as undefined

which I think covers your case too.  It was more the general statement
that I was interested in, because it would form the basis of an updated
rtl.texi patch.

>> > I think some of the rules are overly restrictive, and prevent gcc
>> > from archiving its full potential for generating efficient code.
>> > Moreover, if a port has an extv / insv pattern that matches in mode with 
>> > the
>> > wide registers, it can legitimately use the zero_extract route.  It's
>> > reload that contradicts the documentation in changing registers into MEMs
>> > and thus creating zero_extracts from wide MEMs.
>> 
>> It sounds like you might be referring to both the subreg and extract
>> documentation here.  As far as the subreg documentation goes,
>> let's assume that what I said above about partial modes is right
>> (you'll have already corrected me by now if not).  If we change the
>> rules to say that, what do you think is still overly restrictive?
>
> - zero_extract officially only allowed for a specific mode.
> - nested subregs not allowed, but neither are all subregs that
>   would result from substituting a subreg into an inner reg of another
>   subreg and simplifying allowed.
> - highpart subregs not allowed (e.g. consider SH64 floating point registers:
>   word_mode is 64, but the floating point registers are 32 bit.  How do
>   you refer to the high part of a DFmode value, considering that the
>   inner reg might be allocated to a floating value.  (Actually, generally
>   want such an allocation).)

Sorry, my question was unclear.  I really meant: what in the proposed
rtl.texi rules is too restrictive _given what the current code is
supposed to allow_?  We're trying to write down what is currently
folklore, and we're trying to figure out if we've expressed the
folklore correctly.  Whereas the things you've listed above are not
supported by the current code; they're possible future extensions.

>> E.g. one possibility would be to drop:
>> 
>> If @var{reg} is a hard register, the @code{subreg} must also represent
>> the lowpart of a particular hard register, or represent one or more
>> complete hard registers.
>> 
>> and instead say that the word-based semantics for pseudo registers also
>> apply to hard registers, regardless of the number of hard registers in
>> the inner register.  This would in some ways be simpler.
>
> Yes.  If subword-writing semantics are wanted, and the SUBREG represents
> an actual hard register, than the port has to use a proper hard reg instead.
> And it makes semantics much saner when we do register allocation for a
> pseudo where we don't know the register size to start with.

Thanks.  So in summary, it's OK for these rules in the proposed
rtl.texi patch:

When @var{m1} is at least as narrow as @var{m2} the @code{subreg}
expressions is called @dfn{normal}.

Normal subregs restrict consideration to certain bits of @var{reg}.
There are two cases.  If @var{m1} is smaller than a word, the
@code{subreg} refers to the least-significant part (or @dfn{lowpart})
of one word of @var{reg}.  If @var{m1} is word-sized or greater, the
@code{subreg} refers to one or more complete words.

When @var{m2} is larger than a word, the subreg is a @dfn{multi-word
outer subreg}.  When used as an lvalue, @code{subreg} is a word-based
accessor.  Storing to a @code{subreg} modifies all the words of
@var{reg} that overlap the @code{subreg}, but it leaves the other
words of @var{reg} alone.

When storing to a normal @code{subreg} that is smaller than a word,
the other bits of the referenced word are usually left in an undefined
state.  This laxity makes it easier to generate efficient code for
such instructions.  To represent an instruction that preserves all the
bits outside of those in the @code{subreg}, use @code{strict_low_part}
or @code{zero_extract} around the @code{subreg}.

to apply to hard registers as well as pseudos, without the additional
restriction:

If @var{reg} is a hard register, the @code{subreg} must also represent
the lowpart of a particular har

RE: A proposal to align GCC stack

[Ye, Joey]

Ross, Christian,

Here are the patches to implement the idea we discussed before. Can you
take a look at it or try it?

http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01200.html
http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01199.html

Thanks - Joey

Re: GCC 4.3.0-20080228 (powerpc-linux-gnuspe) ICE on 20000718.c test

[Nathan Froyd]

On Mon, Mar 10, 2008 at 03:22:13PM +0300, Sergei Poselenov wrote:
> I've got the ICE on the gcc.c-torture/compile/2718.c test:
> powerpc-linux-gnuspe-gcc -c -O3 -funroll-loops 2718.c
> 2718.c: In function 'baz':
> 2718.c:14: internal compiler error: Segmentation fault
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.

I run the testsuite with --enable-e500_double all the time and have not
seen this bug before.  It's possible that the bug you're seeing would be
fixed by this patch:

http://gcc.gnu.org/ml/gcc-patches/2008-02/msg01045.html

which was committed on the 6th of March.  The bug is very sensitive to
the environment in which the compiler is run, which would explain why
nobody else is seeing it.

Please update your checkout and rebuild the compiler.  If it still
fails, then please file a bugreport.  And if the bugreport could include
a backtrace (obtained with GDB), that'd be even better.

Thanks,
-Nathan

executable stack in gcc shared libs?

[Paweł Sikora]

Hi all,

I noticed (readelf -lW/grep) that some gcc libraries require executable stack:

/usr/lib64/libffi.so.4.0.1 GNU_STACK  0x00 0x
   0x 0x00 0x00 RWE 0x8
/usr/lib64/libgcj.so.8.0.0 GNU_STACK  0x00 0x
   0x 0x00 0x00 RWE 0x8
/usr/lib64/libgmp.so.3.4.2 GNU_STACK  0x00 0x
   0x 0x00 0x00 RWE 0x8

Is this expected marking or just missed `-z noexecstack` for assembly parts?

BR,
Paweł.

Re: Lexer/cpplib improvements

[Ian Lance Taylor]

"Alexey Salmin" <[EMAIL PROTECTED]> writes:

> I want to join the gcc development process and I decided that
> Lexer/cpplib will be a good place to start. It's quite interesting for
> me, I have some experience in this theme in few projects, fortunately
> there is a http://gcc.gnu.org/onlinedocs/cppinternals/";>special
> manual and http://gcc.gnu.org/wiki/Speedup_areas";>some
> work to do.
> Also I'd like to participate in the Google Summer of Code with this
> project. Is it enough complicated? Is there any sense of writing an
> application? Who can be my mentor?
> Even if i don't join the GSOC I still need a person who can help me
> sometimes with this task.

We would be happy to have work in the lexer/cpplib area, as part of
Summer of Code or not.  For Summer of Code you should propose a
specific set of changes that you plan to do.  Make sure it is both
doable and not too small.  Also make sure to look at the comments on
the proposal when you make it--unfortunately I don't think the Summer
of Code application will send you e-mail about changes.  We will
figure out an appropriate mentor for you--there are several
possibilities, and it will depend on what other projects we receive.

Thanks!

Ian

Re: [trunk] Addition to subreg section of rtl.text.

[Bernd Schmidt]

Paolo Bonzini wrote:

SPE has patterns for

[(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
  (subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 4))]

for example.


What are they trying to do?  It's dubious for a number of reasons:
- SUBREG in the instruction pattern means that we'll eventually end up 
with SUBREG of a hard register

- Any insn that matches this pattern would also match movsi
- There shouldn't really be multiple movsi patterns


Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

Re: [trunk] Addition to subreg section of rtl.text.

[Joseph S. Myers]

On Thu, 20 Mar 2008, Bernd Schmidt wrote:

> Paolo Bonzini wrote:
> > SPE has patterns for
> > 
> > [(set (match_operand:SI 0 "rs6000_nonimmediate_operand" "+r,m")
> >   (subreg:SI (match_operand:SPE64TF 1 "register_operand" "r,r") 4))]
> > 
> > for example.
> 
> What are they trying to do?  It's dubious for a number of reasons:
> - SUBREG in the instruction pattern means that we'll eventually end up with
> SUBREG of a hard register

Yes.  For SPE, the subregs used in these *frob_* patterns represent 
concepts including the high-part of a register (only used by certain 
instructions that treat registers as 64 bits) and a DImode value stored in 
one 64-bit register (normal layout is in two) or a DFmode value on E500v2 
stored in the low parts of two registers (normal layout is in one 
register).  That is, the subregs of hard registers cannot be represented 
as single regs because they represent data laid out in registers in a 
different way from how a single reg in that mode is interpreted.  This 
works fine given the subreg_info infrastructure I added.

> - Any insn that matches this pattern would also match movsi

These insn patterns are here precisely because the compiler generates such 
patterns that do not match generic patterns in rs6000.md.  Thus, they are 
needed to match the RTL the compiler generates.

> - There shouldn't really be multiple movsi patterns

There seem to be quite a lot of *movsi_* patterns in rs6000.md, matching 
different sorts of RTL generated by the compiler.  These are more such 
patterns that happen to have different names; it doesn't matter whether a 
pattern's name starts *movsi or *frob.

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: [trunk] Addition to subreg section of rtl.text.

[Bernd Schmidt]

Joseph S. Myers wrote:
Yes.  For SPE, the subregs used in these *frob_* patterns represent 
concepts including the high-part of a register (only used by certain 
instructions that treat registers as 64 bits) and a DImode value stored in 
one 64-bit register (normal layout is in two) or a DFmode value on E500v2 
stored in the low parts of two registers (normal layout is in one 
register).  That is, the subregs of hard registers cannot be represented 
as single regs because they represent data laid out in registers in a 
different way from how a single reg in that mode is interpreted.  This 
works fine given the subreg_info infrastructure I added.


Let me ask a stupid question.  Do you need to use the rtx code SUBREG 
for this at all, or would an UNSPEC work just as well?  In other words, 
do these SUBREGs appear in other insns, or are they restricted to just 
these patterns?



Bernd
--
This footer brought to you by insane German lawmakers.
Analog Devices GmbH  Wilhelm-Wagenfeld-Str. 6  80807 Muenchen
Sitz der Gesellschaft Muenchen, Registergericht Muenchen HRB 40368
Geschaeftsfuehrer Thomas Wessel, William A. Martin, Margaret Seif

gcc-4.3-20080320 is now available

[gccadmin]

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

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

You'll find:

gcc-4.3-20080320.tar.bz2  Complete GCC (includes all of below)

gcc-core-4.3-20080320.tar.bz2 C front end and core compiler

gcc-ada-4.3-20080320.tar.bz2  Ada front end and runtime

gcc-fortran-4.3-20080320.tar.bz2  Fortran front end and runtime

gcc-g++-4.3-20080320.tar.bz2  C++ front end and runtime

gcc-java-4.3-20080320.tar.bz2 Java front end and runtime

gcc-objc-4.3-20080320.tar.bz2 Objective-C front end and runtime

gcc-testsuite-4.3-20080320.tar.bz2The GCC testsuite

Diffs from 4.3-20080313 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-4.3
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.

Re: [trunk] Addition to subreg section of rtl.text.

[Joseph S. Myers]

On Thu, 20 Mar 2008, Bernd Schmidt wrote:

> Joseph S. Myers wrote:
> > Yes.  For SPE, the subregs used in these *frob_* patterns represent concepts
> > including the high-part of a register (only used by certain instructions
> > that treat registers as 64 bits) and a DImode value stored in one 64-bit
> > register (normal layout is in two) or a DFmode value on E500v2 stored in the
> > low parts of two registers (normal layout is in one register).  That is, the
> > subregs of hard registers cannot be represented as single regs because they
> > represent data laid out in registers in a different way from how a single
> > reg in that mode is interpreted.  This works fine given the subreg_info
> > infrastructure I added.
> 
> Let me ask a stupid question.  Do you need to use the rtx code SUBREG for this
> at all, or would an UNSPEC work just as well?  In other words, do these
> SUBREGs appear in other insns, or are they restricted to just these patterns?

As I recall, these SUBREGs are what's generated by the core compiler.  If 
they are generated in the rs6000 back end, the code generating them 
applies for non-SPE as well (and SPE conditionals in the rs6000 back end 
are avoided where possible) - but for non-SPE they would end up reducing 
to plain regs.

So, these patterns need to match whatever RTL is generated elsewhere in 
the compiler.  Hypothetically the compiler might be changed no longer to 
generate the RTL these patterns match, but this shouldn't be done in a way 
that adds SPE conditionals unnecessarily.  I do not think SPE code 
generation is particularly good; it's certainly possible that different 
implementations of these patterns or different RTL would lead to better 
RTL optimization and better code (though I doubt UNSPECs would be 
particularly good for optimizability).  I do, however, think these 
patterns work reliably in the compiler at present (but they were written 
to generate working code, not necessarily efficient code).

-- 
Joseph S. Myers
[EMAIL PROTECTED]

Re: Have proposals for 2008 gcc summit been reviewed?

[Ben Elliston]

> We submitted 2 proposals for 2008 gcc summit. We got one reply
> for one proposal on Mar. 15. But we haven't heard anything on
> the other. April 1 is the deadline for paper if proposal is
> accepted. Today is Mar. 20. I was wondering if anyone on
> gcc mailing list could help us figure out what happened to
> our other proposal.

All notifications should now have been sent out (I believe whether they
were accepted or not).

Cheers, Ben