Re: Machine Description Template?

[Martin Guy]

On 6/5/09, Graham Reitz  wrote:
> I have been working through sections 16 & 17 of the gccint.info
> document and also read through Hans' 'Porting GCC for Dunces'.

There is also "Incremental Machine Descriptions for GCC"
http://www.cse.iitb.ac.in/~uday/soft-copies/incrementalMD.pdf
which describes creation of a new, clean machine description from scratch

M

Re: several installed gcc, or libdir should depend upon -program-suffix...

[Gerald Pfeifer]

On Tue, 9 Jun 2009, Basile STARYNKEVITCH wrote:
> How do you folks have several GCC installed at the same prefix?

Yes, I have been doing this for the FreeBSD ports for years, and what
I am using there is the following

  --program-suffix=${SUFFIX} \
  --libdir=${TARGLIB} \
  --libexecdir=${LIBEXEC} \
  --with-gxx-include-dir=${TARGLIB}/include/c++/

with

  TARGLIB=${PREFIX}/lib/gcc${SUFFIX}
  LIBEXEC=${PREFIX}/libexec/gcc${SUFFIX}

Gerald

Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Joseph S. Myers]

On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:

> Perhaps the only safe way to create the value, even in the presence of
> rounding mode changes, is to use conj(3.I) ?

Setting the __real__ and __imag__ parts of a temporary variable should 
always be reliable for making a complex number out of arbitrary real and 
imaginary parts.

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

Bootstrap failures on solaris

[Art Haas]

Hi.

I've had no luck with recent bootstraps on both i386-pc-solaris2.10 and
sparc-sun-solaris2.10. The error messages below are from builds performed
after updating my repo this morning.

i386-pc-solaris:

cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function 
'loop_prefetch_arrays':
/export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error: 
format '%ld' expects type 'long int', but argument 5 has type 'long long int'
make[3]: *** [tree-ssa-loop-prefetch.o] Error 1
make[3]: *** Waiting for unfinished jobs


sparc-sun-solaris2.10:

/export/home/arth/src/gcc.git/libgcc/../gcc/unwind-dw2-fde.c: In function 
'__register_frame_table':
/export/home/arth/src/gcc.git/libgcc/../gcc/unwind-dw2-fde.c:154:1: internal 
compiler error: in dwarf2out_begin_epilogue, at dwarf2out.c:2753
Please submit a full bug report, with preprocessed source if appropriate.

Anyone else seeing failures like this?

Art Haas

Re: git mirror at infradead?

[Jason Merrill]

Bernie Innocenti wrote:

On 06/07/09 12:40, Ralf Wildenhues wrote:

Is this mirror an independent conversion from the infradead one (i.e., I
have to throw away the repo and re-download a full repo?  Or can I reuse
objects)?  


It's an independent mirror, and I wouldn't recommend switching to it yet.

There are permissions problems, and I might end up rsyncing the whole
infradead repository rather than fixing things locally.


Please please do *not* rsync the infradead repository.  The repository 
on gcc.gnu.org is set up so that I can switch back and forth between 
pulling from git and using git-svn directly; the infradead repository is 
not.


For one thing, the infradead repository uses svn://gcc.gnu.org/svn/gcc, 
which makes it impossible to use git-svn to check in changes; the 
gcc.gnu.org git repository uses svn+ssh://gcc.gnu.org/svn/gcc, as is 
right and proper.  Also the remotes are in a different place from where 
git-svn puts them, though I suppose that's easy enough to adjust when 
fetching.


Jason

Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Kaveh R. Ghazi]

From: "Joseph S. Myers" 


On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:


Perhaps the only safe way to create the value, even in the presence of
rounding mode changes, is to use conj(3.I) ?


Setting the __real__ and __imag__ parts of a temporary variable should
always be reliable for making a complex number out of arbitrary real and
imaginary parts.


Well yes, but I meant for compile-time expressions that are exposed to fold 
even at -O0.  (Recall that I'm writing testcases for the MPC stuff.)  I'm 
not 100% confident that the temporary variable will always fold and it's too 
verbose when repeatedly used in a testcase.  With conj, the builtin will 
always fold 3.I and won't do anything unexpected with rounding modes.


I was just wondering why -3.I was evaluating differently than 0-3.I and 
whether it was a bug.  Your explanation was very useful.


   Thanks,
   --Kaveh

Re: What is -3.I (as opposed to 0-3.I) supposed evaluate to?

[Richard Guenther]

On Tue, Jun 9, 2009 at 11:26 AM, Kaveh R. Ghazi wrote:
> From: "Joseph S. Myers" 
>
>> On Mon, 8 Jun 2009, Kaveh R. Ghazi wrote:
>>
>>> Perhaps the only safe way to create the value, even in the presence of
>>> rounding mode changes, is to use conj(3.I) ?
>>
>> Setting the __real__ and __imag__ parts of a temporary variable should
>> always be reliable for making a complex number out of arbitrary real and
>> imaginary parts.
>
> Well yes, but I meant for compile-time expressions that are exposed to fold
> even at -O0.  (Recall that I'm writing testcases for the MPC stuff.)  I'm
> not 100% confident that the temporary variable will always fold and it's too
> verbose when repeatedly used in a testcase.  With conj, the builtin will
> always fold 3.I and won't do anything unexpected with rounding modes.

It should always be folded via CCP / value-numbering.  If not that is a bug
that needs to be fixed.

Richard.

> I was just wondering why -3.I was evaluating differently than 0-3.I and
> whether it was a bug.  Your explanation was very useful.



>       Thanks,
>       --Kaveh
>
>

Re: Bootstrap failures on solaris

[Revital1 Eres]

Hello,

> i386-pc-solaris:
>
> cc1: warnings being treated as errors
> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function
> 'loop_prefetch_arrays':
> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error:

> format '%ld' expects type 'long int', but argument 5 has type 'long long
int'
> make[3]: *** [tree-ssa-loop-prefetch.o] Error 1
> make[3]: *** Waiting for unfinished jobs

I get this error on ppc also.

Revital
>
>
> sparc-sun-solaris2.10:
>
> /export/home/arth/src/gcc.git/libgcc/../gcc/unwind-dw2-fde.c: In function

> '__register_frame_table':
> /export/home/arth/src/gcc.git/libgcc/../gcc/unwind-dw2-fde.c:154:1:
internal
> compiler error: in dwarf2out_begin_epilogue, at dwarf2out.c:2753
> Please submit a full bug report, with preprocessed source if appropriate.
>
> Anyone else seeing failures like this?
>
> Art Haas

Re: Bootstrap failures on solaris

[Kaveh R. GHAZI]

On Tue, 9 Jun 2009, Art Haas wrote:

>
> Hi.
>
> I've had no luck with recent bootstraps on both i386-pc-solaris2.10 and
> sparc-sun-solaris2.10. The error messages below are from builds performed
> after updating my repo this morning.
>
> i386-pc-solaris:
>
> cc1: warnings being treated as errors
> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function 
> 'loop_prefetch_arrays':
> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error: 
> format '%ld' expects type 'long int', but argument 5 has type 'long long int'
> make[3]: *** [tree-ssa-loop-prefetch.o] Error 1
> make[3]: *** Waiting for unfinished jobs

The above should be easy to fix using HOST_WIDE_INT_PRINT_DEC instead of
"%ld".  You'll have to pry apart the format string and insert the macro
via compile-time string contatenation.  See other uses for examples.

--Kaveh

Re: Bootstrap failures on solaris

[Adam Nemet]

Revital1 Eres  writes:
> Hello,
>
>> i386-pc-solaris:
>>
>> cc1: warnings being treated as errors
>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In function
>> 'loop_prefetch_arrays':
>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7: error:
>
>> format '%ld' expects type 'long int', but argument 5 has type 'long long
> int'
>> make[3]: *** [tree-ssa-loop-prefetch.o] Error 1
>> make[3]: *** Waiting for unfinished jobs
>
> I get this error on ppc also.

See http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00712.html

Adam

increasing the number of GCC reviewers

[Basile STARYNKEVITCH]

Hello All,

I am unfortunately not attending the GCC summit which happens right now 
in Montreal.


But apparently, there seems to be a lack of code reviewers for GCC. The 
few people who do review code seems to have a lot of review in their 
batch queue.


Perhaps could be discussed at the summit some way to increase the set of 
reviewers, i.e. the set of people able to say Ok to a patch submitted on 
gcc-patches@


Or is that question a steering committee priviledge? If it is, could 
someone ask it to them (the SC members)?


I am wrong in believing that code review is a real bottleneck today?

Regards.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: increasing the number of GCC reviewers

[Andrew Haley]

Basile STARYNKEVITCH wrote:

> I am unfortunately not attending the GCC summit which happens right now
> in Montreal.
> 
> But apparently, there seems to be a lack of code reviewers for GCC. The
> few people who do review code seems to have a lot of review in their
> batch queue.
> 
> Perhaps could be discussed at the summit some way to increase the set of
> reviewers, i.e. the set of people able to say Ok to a patch submitted on
> gcc-patches@

As I understand it, the set of reviewers allowed to say OK to a patch is
limited to the set of people capable of reviewing these patches.  That is,
there is a limited set of people with enough real knowledge of gcc to
approve a patch.  Adding people who do not really understand gcc will
not help.

Andrew.

Re: increasing the number of GCC reviewers

[Basile STARYNKEVITCH]

Andrew Haley wrote:

Basile STARYNKEVITCH wrote:


Perhaps could be discussed at the summit some way to increase the set of
reviewers, i.e. the set of people able to say Ok to a patch submitted on
gcc-patches@



As I understand it, the set of reviewers allowed to say OK to a patch is
limited to the set of people capable of reviewing these patches.  That is,
there is a limited set of people with enough real knowledge of gcc to
approve a patch.  


I know a lot of people who fully understand many of the patches I did 
submit, and who are not able to say Ok (because' their plain maintainer 
status disallows that).
And there are some patches which I did comment about, which I believe I 
did understand, and of course which I am not allowed to approve. I am 
certainly not alone in that case!


My feeling is on the contrary that the set of people having a real 
knowledge of gcc (or at least of substantial parts of it [*]) is much 
bigger than the set of reviewers allowed to say OK.


Regards.

PS. [note *] GCC is a huge software, so understanding well a part of it 
could be enough to understand some patches. And GCC is a huge software, 
so the set of people understanding all of it is shrinking; perhaps even 
it could be empty! (I never met any person claiming to understand all of 
GCC; for sure I will never understand all of it.).


--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: increasing the number of GCC reviewers

[Basile STARYNKEVITCH]

Basile STARYNKEVITCH wrote:

Andrew Haley wrote:
Basile STARYNKEVITCH wrote: 


PS. [note *] GCC is a huge software, so understanding well a part of 
it could be enough to understand some patches. 



And GCC is a huge software
I meant GCC is growing a lot. Its increase rate (about 1MLOC in less 
than 3 years) is impressive.
so the set of people understanding all of it is shrinking; perhaps 
even it could be empty! (I never met any person claiming to understand 
all of GCC; for sure I will never understand all of it.).





--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: increasing the number of GCC reviewers

[Andrew Haley]

Basile STARYNKEVITCH wrote:
> Andrew Haley wrote:
>> Basile STARYNKEVITCH wrote:
>>>
>>> Perhaps could be discussed at the summit some way to increase the set of
>>> reviewers, i.e. the set of people able to say Ok to a patch submitted on
>>> gcc-patches@
>>
>> As I understand it, the set of reviewers allowed to say OK to a
>> patch is limited to the set of people capable of reviewing these
>> patches.  That is, there is a limited set of people with enough
>> real knowledge of gcc to approve a patch.

> I know a lot of people who fully understand many of the patches I
> did submit, and who are not able to say Ok (because' their plain
> maintainer status disallows that).

> And there are some patches which I did comment about, which I
> believe I did understand, and of course which I am not allowed to
> approve. I am certainly not alone in that case!

Well, maybe.  But it's not what you know, it's what you know that ain't
so.  And I am pretty sure that I'm more cautious today about some of the
patches I believe I understand than I was when I started many years go.

> My feeling is on the contrary that the set of people having a real
> knowledge of gcc (or at least of substantial parts of it [*]) is much
> bigger than the set of reviewers allowed to say OK.

That's certainly true, but there's a big difference between having real
knowledge of gcc and having enough real knowledge to approve a patch.

It is quite possibly the case that some maintainers should be "promoted".
But it isn't sufficient to have a blanket policy of "let's have more
reviewers".  We need something more like "I think Fred Bloggs knows gcc
well enough to approve patches to reload" or "I am Fred Bloggs and I
know gcc well enough to approve patches to reload."

That would be much more productive.

Andrew.

Re: increasing the number of GCC reviewers

[Adam Nemet]

Andrew Haley  writes:
> We need something more like "I think Fred Bloggs knows gcc well enough
> to approve patches to reload" or "I am Fred Bloggs and I know gcc well
> enough to approve patches to reload."

And whom should such email be sent to?  The SC is best reached on gcc@
but I don't think that recommending someone publicly is necessarly a
good idea.  E.g. what if the SC does not appoint the person; does that
mean that the SC decided that he or she was not qualified enough?

IMO the best way would be to nominate someone to the SC directly and
then if the SC decides to support the nomination they can check with the
person if he or she would accept the appointment.

Adam

Re: increasing the number of GCC reviewers

[Andrew Haley]

Adam Nemet wrote:
> Andrew Haley  writes:
>> We need something more like "I think Fred Bloggs knows gcc well enough
>> to approve patches to reload" or "I am Fred Bloggs and I know gcc well
>> enough to approve patches to reload."
> 
> And whom should such email be sent to?  The SC is best reached on gcc@
> but I don't think that recommending someone publicly is necessarly a
> good idea.  E.g. what if the SC does not appoint the person; does that
> mean that the SC decided that he or she was not qualified enough?
> 
> IMO the best way would be to nominate someone to the SC directly and
> then if the SC decides to support the nomination they can check with the
> person if he or she would accept the appointment.

I think it's a much better idea to contact Fred (or Freda, for that matter)
Bloggs to ask them if they want to maintain reload.  :-)

If you really need to contact any SC members in private, you can do
that.  It's not as though their identities are secret.

Andrew.

RE: Bootstrap failures on solaris

[Arthur Haas]

>Revital1 Eres  writes:
>> Hello,
>>
>>> i386-pc-solaris:
>>>
>>> cc1: warnings being treated as errors
>>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c: In
function
>>> 'loop_prefetch_arrays':
>>> /export/home/arth/gnu/gcc.git/gcc/tree-ssa-loop-prefetch.c:1589:7:
error:
>>>
>>> format '%ld' expects type 'long int', but argument 5 has type 'long
long
>> int'
>>> make[3]: *** [tree-ssa-loop-prefetch.o] Error 1
>>> make[3]: *** Waiting for unfinished jobs
>>
>> I get this error on ppc also.
>
> See http://gcc.gnu.org/ml/gcc-patches/2009-06/msg00712.html

Hi.

Now that this patch has been commited, the build on i386-pc-solaris2.10
succeeds when building tree-ssa-loop-prefetch.o file but fails later on:

cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/gcc.c: In function 'compare_files':
/export/home/arth/gnu/gcc.git/gcc/gcc.c:6635:2: error: request for
implicit conversion from 'void *' to 'caddr_t' not permitted in C++
make[3]: *** [gcc.o] Error 1
make[3]: *** Waiting for unfinished jobs

The error is in an munmap() call, and a look at the  header
shows that the funcation arguments can be either 'void *' or 'caddr_t *'
depending on preprocessor values.

Art Haas

Re: increasing the number of GCC reviewers

[Basile STARYNKEVITCH]

FWIW, I am not taking this question personally (I don't really claim 
that I could become any kind of reviewer; I believe in general that 
reviewing abilities should be evaluated by others.). I just think the 
set of reviewers should significantly grow.



Andrew Haley wrote:


  

My feeling is on the contrary that the set of people having a real
knowledge of gcc (or at least of substantial parts of it [*]) is much
bigger than the set of reviewers allowed to say OK.



  
I am not at the summit. So I don't know if my perception "there are not 
enough reviewers" [0] is shared by others or not. I suppose it is agreed 
(that the set of reviewers should be increased [1])  If not, ignore the 
rest. I really don't know if other people believe (as I do) that the set 
of reviewers should significantly increase.


My perception is that many reviewers have too much reviews [2] in their 
queue, and that these tasks might overwhelm or bore them. But since I am 
not a reviewer, I cannot reliably understand what it is to be one. For 
instance, my feeling is that Diego Novillo -whom I know, and I admire a 
lot- (and some other GCC gurus) is almost exhausted by his pending 
review queue.



That's certainly true, but there's a big difference between having real
knowledge of gcc and having enough real knowledge to approve a patch.
  
What might perhaps be discussed at the summit is possibly this (perhaps 
too strong) requirement on the reviewer's level. If there are too few 
reviewers, and if making a big lot of reviews is boring (or just too 
demanding or too tiring) to them, then we might consider lowering the 
threshold to become a reviewer (e.g. dispatch review abilities to more 
people, or perhaps define some fine grain policy on future reviewers; I 
could imagine that some people could review just a few GCC source files).

It is quite possibly the case that some maintainers should be "promoted".
But it isn't sufficient to have a blanket policy of "let's have more
reviewers".  
But we first should agree on the wish than an increase of the set of 
reviewers is desirable.



We need something more like "I think Fred Bloggs knows gcc
well enough to approve patches to reload" or "I am Fred Bloggs and I
know gcc well enough to approve patches to reload."
  


I am not sure to parse correctly this sentence. Sorry, English is a 
foreign language to me. Is "reload" some functionality (PCH?) you refer 
inside GCC, or is it the task of making reviews on patches submitted on 
gcc-patches@ ? I was just thinking about stuff like "Fred Bloggs knows 
enough to approve patches submitted on gcc-patches@ to files gcc/ggc*.[ch]"



And it could happen that the plugin infrastructure might in the future 
move some code out of GCC core (and into plugins). In that future 
situation, the set of reviewers might not need to increase.


Regards.

Note 0: for me a reviewer is any person admitted to say ok to some (even 
very few) patches.


Note 1: My intuition is that the number of reviewers should be 
proportional (at least; and one could believe to O(n log n) where n is 
the size of GCC) to the GCC source size. I am not sure (& I don't know 
if) it has increased by 30% in 3 years, as did the source code!


Note 2: I have no idea if the patch-to-be-reviewed queue of each 
reviewer has increased since 2 years ago! I intuitively feel it did 
increase a lot, i.e. reviewers have much more pressure on them. Maybe I 
am wrong!


--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: increasing the number of GCC reviewers

[Paolo Bonzini]

My feeling is on the contrary that the set of people having a real
knowledge of gcc (or at least of substantial parts of it [*]) is much
bigger than the set of reviewers allowed to say OK.


That's certainly true, but there's a big difference between having real
knowledge of gcc and having enough real knowledge to approve a patch.


It's also a matter of time.  I wouldn't trust myself with the ability to 
review patches in broader areas, because I wouldn't have enough time to 
do it properly.


Paolo

Re: increasing the number of GCC reviewers

[Richard Guenther]

On Tue, Jun 9, 2009 at 2:10 PM, Basile
STARYNKEVITCH wrote:
> FWIW, I am not taking this question personally (I don't really claim that I
> could become any kind of reviewer; I believe in general that reviewing
> abilities should be evaluated by others.). I just think the set of reviewers
> should significantly grow.
>
>
> Andrew Haley wrote:
>>
>>
>>>
>>> My feeling is on the contrary that the set of people having a real
>>> knowledge of gcc (or at least of substantial parts of it [*]) is much
>>> bigger than the set of reviewers allowed to say OK.
>>>
>>
>>
>
> I am not at the summit. So I don't know if my perception "there are not
> enough reviewers" [0] is shared by others or not. I suppose it is agreed
> (that the set of reviewers should be increased [1])  If not, ignore the
> rest. I really don't know if other people believe (as I do) that the set of
> reviewers should significantly increase.
>
> My perception is that many reviewers have too much reviews [2] in their
> queue, and that these tasks might overwhelm or bore them. But since I am not
> a reviewer, I cannot reliably understand what it is to be one. For instance,
> my feeling is that Diego Novillo -whom I know, and I admire a lot- (and some
> other GCC gurus) is almost exhausted by his pending review queue.
>
>> That's certainly true, but there's a big difference between having real
>> knowledge of gcc and having enough real knowledge to approve a patch.
>>
>
> What might perhaps be discussed at the summit is possibly this (perhaps too
> strong) requirement on the reviewer's level. If there are too few reviewers,
> and if making a big lot of reviews is boring (or just too demanding or too
> tiring) to them, then we might consider lowering the threshold to become a
> reviewer (e.g. dispatch review abilities to more people, or perhaps define
> some fine grain policy on future reviewers; I could imagine that some people
> could review just a few GCC source files).
>>
>> It is quite possibly the case that some maintainers should be "promoted".
>> But it isn't sufficient to have a blanket policy of "let's have more
>> reviewers".
>
> But we first should agree on the wish than an increase of the set of
> reviewers is desirable.
>
>> We need something more like "I think Fred Bloggs knows gcc
>> well enough to approve patches to reload" or "I am Fred Bloggs and I
>> know gcc well enough to approve patches to reload."
>>
>
> I am not sure to parse correctly this sentence. Sorry, English is a foreign
> language to me. Is "reload" some functionality (PCH?) you refer inside GCC,
> or is it the task of making reviews on patches submitted on gcc-patches@ ? I
> was just thinking about stuff like "Fred Bloggs knows enough to approve
> patches submitted on gcc-patches@ to files gcc/ggc*.[ch]"
>
>
> And it could happen that the plugin infrastructure might in the future move
> some code out of GCC core (and into plugins). In that future situation, the
> set of reviewers might not need to increase.
>
> Regards.
>
> Note 0: for me a reviewer is any person admitted to say ok to some (even
> very few) patches.
>
> Note 1: My intuition is that the number of reviewers should be proportional
> (at least; and one could believe to O(n log n) where n is the size of GCC)
> to the GCC source size. I am not sure (& I don't know if) it has increased
> by 30% in 3 years, as did the source code!
>
> Note 2: I have no idea if the patch-to-be-reviewed queue of each reviewer
> has increased since 2 years ago! I intuitively feel it did increase a lot,
> i.e. reviewers have much more pressure on them. Maybe I am wrong!

You are wrong.

;)

Richard.

> --
> Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
> email: basilestarynkevitchnet mobile: +33 6 8501 2359
> 8, rue de la Faiencerie, 92340 Bourg La Reine, France
> *** opinions {are only mines, sont seulement les miennes} ***
>
>

Re: increasing the number of GCC reviewers

[Andrew Haley]

Basile STARYNKEVITCH wrote:
> FWIW, I am not taking this question personally (I don't really claim
> that I could become any kind of reviewer; I believe in general that
> reviewing abilities should be evaluated by others.). I just think the
> set of reviewers should significantly grow.

But that needs more experts.  The set of reviewers is not limited by
the steering committee but by the number of experts in the world that
are willing to review patches.

>>> My feeling is on the contrary that the set of people having a real
>>> knowledge of gcc (or at least of substantial parts of it [*]) is much
>>> bigger than the set of reviewers allowed to say OK.

>>   
> I am not at the summit. So I don't know if my perception "there are not
> enough reviewers" [0] is shared by others or not. I suppose it is agreed
> (that the set of reviewers should be increased [1])  If not, ignore the
> rest. I really don't know if other people believe (as I do) that the set
> of reviewers should significantly increase.

Everyone agrees that life would be better if there were more suitably
qualified gcc maintainers to approve patches.  I don't have to ask
anyone to know that.

>> It is quite possibly the case that some maintainers should be "promoted".
>> But it isn't sufficient to have a blanket policy of "let's have more
>> reviewers".  
> But we first should agree on the wish than an increase of the set of
> reviewers is desirable.

It's not in any doubt.  What is in doubt is that we should reduce
the quality threshold in order to get them.

>> We need something more like "I think Fred Bloggs knows gcc
>> well enough to approve patches to reload" or "I am Fred Bloggs and I
>> know gcc well enough to approve patches to reload."

> I am not sure to parse correctly this sentence. Sorry, English is a
> foreign language to me. Is "reload" some functionality (PCH?) you refer
> inside GCC, or is it the task of making reviews on patches submitted on
> gcc-patches@ ? I was just thinking about stuff like "Fred Bloggs knows
> enough to approve patches submitted on gcc-patches@ to files gcc/ggc*.[ch]"

This is going to sound rude, but if you don't know what reload is
you're not able to talk about gcc maintenance.

Andrew.

New Moxie port and maintainer

[Gerald Pfeifer]

It is my pleasure to announce that the steering committee is
appointing Anthony Green as maintainer of the new Moxie port
that has been approved from a technical perspective as well.

Please adjust the MAINTAINERS file accordingly, Anthony, and
happy hacking!  And of course, go ahead and commit the thing. :-)

Gerald

Re: increasing the number of GCC reviewers

[Basile STARYNKEVITCH]

Andrew Haley wrote:

Basile STARYNKEVITCH wrote:
  

FWIW, I am not taking this question personally (I don't really claim
that I could become any kind of reviewer; I believe in general that
reviewing abilities should be evaluated by others.). I just think the
set of reviewers should significantly grow.
I am not sure to parse correctly this sentence. Sorry, English is a
foreign language to me. Is "reload" some functionality (PCH?) you refer
inside GCC, or is it the task of making reviews on patches submitted on
gcc-patches@ ? I was just thinking about stuff like "Fred Bloggs knows
enough to approve patches submitted on gcc-patches@ to files gcc/ggc*.[ch]"



This is going to sound rude, but if you don't know what reload is
you're not able to talk about gcc maintenance.

  


Reload is probably in the register allocator, which indeed is in the 
backend part I know nothing about (and I don't care much).


Your opinion is not rude, but I still believe one don"t need to 
understand all of the GCC internals to talk about the review process. I 
even believe that some people (e.g. those working on other big software 
like Gnome/GTK, KDE/QT, Mozilla, ...) could have valid opinions & 
suggestions on it without even knowing anything about GCC, but only 
understanding the review procedures.


I even disagree on your opinion. I believe I might even become in a few 
years some kind of gcc/ggc*.[ch] secondary reviewer. I don't want to 
become one (being a reviewer is probably more a burden than an honor, 
and probably consume a lot of time, and might be often boring.). 
However, I am pretty sure that nobody needs to understand register 
allocation to review GGC related patches, or Ada or C++ front end 
patches, or Fortran front-end patches, or CPP patches, or perhaps even 
some gcc/passes.c or gcc/tree-passes.h patches like the plugin related 
ones.).


This is precisely my point. It should be perfectly acceptable that some 
people be authorized to approve some few patches without understanding 
the whole of GCC, and even without knowing all of it.


Now, I understand you or others can disagree with my opinion. You may 
think that most reviewers should know most of GCC (I disagree with that).


My point is that GCC could quite soon grow to 5 or 6MLOC, and the set of 
people understanding all of them (or simply more than half of them) 
will, if it is not yet empty, decrease dramatically.


Perhaps some GCC decision making people (SC?) might even want to really 
decrease the size of core GCC. This could be possible with the plugin 
feature. As an extreme & silly example, they (or is it we?) could decide 
to move out of GCC core and into future GCC plugins all the 
optimizations done only at -O3 or only with explicit -f* flags. I don't 
really advocate that (again I don't have any informed opinion; I almost 
never used -O3 and know few people who do use it!) but it could be possible.



Regards

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: git mirror at infradead?

[Bernie Innocenti]

On 06/09/09 16:17, Jason Merrill wrote:
> Bernie Innocenti wrote:
>> On 06/07/09 12:40, Ralf Wildenhues wrote:
>>> Is this mirror an independent conversion from the infradead one (i.e., I
>>> have to throw away the repo and re-download a full repo?  Or can I reuse
>>> objects)?  
>>
>> It's an independent mirror, and I wouldn't recommend switching to it yet.
>>
>> There are permissions problems, and I might end up rsyncing the whole
>> infradead repository rather than fixing things locally.
> 
> Please please do *not* rsync the infradead repository.  The repository
> on gcc.gnu.org is set up so that I can switch back and forth between
> pulling from git and using git-svn directly; the infradead repository is
> not.
>
> For one thing, the infradead repository uses svn://gcc.gnu.org/svn/gcc,
> which makes it impossible to use git-svn to check in changes; the
> gcc.gnu.org git repository uses svn+ssh://gcc.gnu.org/svn/gcc, as is
> right and proper.  Also the remotes are in a different place from where
> git-svn puts them, though I suppose that's easy enough to adjust when
> fetching.

I won't re-create the repository from scratch, then.

Though I would still need an updated version of git to enable lots of
branches and tags without wasting too much hard disk space.

Can a sourceware admin please install (or build) git 1.6.3.x?  If there
are concerns of breaking other things, I could install a local copy in
~/bin.

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs   - http://sugarlabs.org/

Re: increasing the number of GCC reviewers

[Joe Buck]

On Tue, Jun 09, 2009 at 10:54:06AM -0700, Adam Nemet wrote:
> Andrew Haley  writes:
> > We need something more like "I think Fred Bloggs knows gcc well enough
> > to approve patches to reload" or "I am Fred Bloggs and I know gcc well
> > enough to approve patches to reload."
> 
> And whom should such email be sent to?  The SC is best reached on gcc@
> but I don't think that recommending someone publicly is necessarly a
> good idea.  E.g. what if the SC does not appoint the person; does that
> mean that the SC decided that he or she was not qualified enough?

> IMO the best way would be to nominate someone to the SC directly and
> then if the SC decides to support the nomination they can check with the
> person if he or she would accept the appointment.

You could contact any SC member by private mail if you think the topic
is too sensitive to discuss in public.  It would work best to pick an
SC member who is familiar with the nominee's work (and we'd have to
know that Fred Bloggs wants the job).

Re: increasing the number of GCC reviewers

[Andrew Haley]

Basile STARYNKEVITCH wrote:
> Andrew Haley wrote:
>> Basile STARYNKEVITCH wrote:
>>
>> This is going to sound rude, but if you don't know what reload is
>> you're not able to talk about gcc maintenance.
> 
> Reload is probably in the register allocator, which indeed is in the
> backend part I know nothing about (and I don't care much).

OK, that's pretty close.

> Your opinion is not rude, but I still believe one don"t need to
> understand all of the GCC internals to talk about the review process.

No, they don't.  But they need to have some kind of a clue about how
it works, and what the pieces are.

> I even disagree on your opinion. I believe I might even become in a few
> years some kind of gcc/ggc*.[ch] secondary reviewer.

Sure, I don't see why not.  It'll take work, but it's perfectly possible.

> This is precisely my point. It should be perfectly acceptable that some
> people be authorized to approve some few patches without understanding
> the whole of GCC, and even without knowing all of it.

GCC isn't really like that.  Changes in one part can affect things much
later on, and you really have to know why.  That doesn't mean you have
to understand all of the compiler, but you need to have a lot of
knowledge.

> Now, I understand you or others can disagree with my opinion. You may
> think that most reviewers should know most of GCC (I disagree with that).

No-one knows most of GCC.  At least, I very much doubt it.

Rather than saying "the set of reviewers should significantly grow", let me
challenge you.  Suggest someone who should be added to that set.

Andrew.

plugin callbacks after compiler errors

[Taras Glek]

While developing my plugin I've noticed that many callbacks need to be 
guarded with "if (errorcount)" or the plugin will cause a gcc crash due 
to receiving less complete data than it expected.


Should the plugin API guard callbacks in invoke_plugin_callbacks() to 
avoid 99% of plugins running into this issue?


Taras

Re: plugin callbacks after compiler errors

[Basile STARYNKEVITCH]

Taras Glek wrote:
While developing my plugin I've noticed that many callbacks need to be 
guarded with "if (errorcount)" or the plugin will cause a gcc crash 
due to receiving less complete data than it expected.


Should the plugin API guard callbacks in invoke_plugin_callbacks() to 
avoid 99% of plugins running into this issue? 



I am not sure this should be a fixed, wired (ie built-in) policy. One 
could imagine some plugins whose main role is precisely to issue 
additional errors (and IIRC, your TreeHydra did something similar to that).


Maybe we should just fix the documentation, saying that plugins should 
care (and plugin writers should think of) previously detected errors.


Maybe we might differentiate errors found by other passes and error 
found by plugins.


Maybe we should also extend the API so that some plugins get disabled 
when errorcount is >0. I tend to believe it should not become a general 
policy (but at least tunable plugin by plugin) but I may be wrong.


Regards.

--
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: Expanding a load instruction

[Jean Christophe Beyler]

Dear all,

I've moved forward on this issue. Again, the problem is not that the
data is not aligned but that the compiler tries to generate this
instruction:

(set (reg:HI 141) (mem/s/j:HI (plus:DI (reg:DI 134 [ ivtmp.23 ])
 (const_int 1 [0x1])) [0 .geno+0 S2 A16]))

And, in my target architecture, this is not authorized. I want to
transform this into:

(set (reg:DI 135) (plus:DI (reg:DI 134 [ ivtmp.23 ])
 (const_int 1 [0x1])) [0 .geno+0 S2 A16]))
(set (reg:HI 141) (mem/s/j:HI (reg:DI 135))


I've tried playing with define_expand, I can detect this problem, I
can emit my first move and then the second but for some reason, the
compiler reassembles them back together.

Any ideas why I am getting that? Am I doing anything wrong? After I
expand this, I use the DONE macro...
Thanks,
Jc

On Fri, Jun 5, 2009 at 1:17 PM, Jean Christophe
Beyler wrote:
> It's already at 1 actually. The problem isn't really that the data
> itself is unaligned but that the offset of the load must be a power of
> 2 (multiple of 2 for a HI mode, multiple of 4 for a SI, ...).
>
> Therefore, that macro does not seem to apply to me (and it's already at 1!).
>
> Thanks, I'm continuing to look into this issue,
> Jc
>
> On Fri, Jun 5, 2009 at 11:48 AM, Dave Korn
>  wrote:
>> fearyourself wrote:
>>
>>> In the instruction set of my architecture, the offsets of a half-load
>>> (HImode) have to be multiples of 2. However, if I set up a structure
>>> in a certain way, the compiler will generate:
>>>
>>> (mem/s/j:HI (plus:DI (reg:DI 134 [ ivtmp.23 ])
>>>         (const_int 1 [0x1])) [0 .geno+0 S2 A16])
>>>
>>> As the memory operand for the load.
>>>
>>> Now, one solution I am going to try to fix this is to use
>>> define_expand and add a move into another register before this load
>>> and then load from that register (thus removing the offset of 1).
>>>
>>> My question is: Is that how it should be done or is there another solution?
>>
>>  This looks like what you need:
>>
>>  -- Macro: STRICT_ALIGNMENT
>>     Define this macro to be the value 1 if instructions will fail to
>>     work if given data not on the nominal alignment.  If instructions
>>     will merely go slower in that case, define this macro as 0.
>>
>>    cheers,
>>      DaveK
>>
>>
>

Re: increasing the number of GCC reviewers

[Diego Novillo]

Basile,

You don't need to convince us that we need more reviewers.  We all
agree on that.  You simply need to suggest a reviewer for some set of
files that

- Knows that set of files very well
- Is familiar with GCC development
- Is willing to review patches and be a maintainer for those files
- Has made enough contributions to those files and whose work is well
regarded by the developer community

You'll quickly find out that this makes for a fairly small set of
people.  Long term, I don't think we would do us a service if we
relaxed any of those requirements too much.


Diego.

Re: increasing the number of GCC reviewers

[Gabriel Dos Reis]

On Tue, Jun 9, 2009 at 3:22 PM, Diego Novillo wrote:

> You'll quickly find out that this makes for a fairly small set of
> people.  Long term, I don't think we would do us a service if we
> relaxed any of those requirements too much.

Excellent summary.

-- Gaby

Re: Bootstrap failures on solaris

[Ian Lance Taylor]

"Arthur Haas"  writes:

> Now that this patch has been commited, the build on i386-pc-solaris2.10
> succeeds when building tree-ssa-loop-prefetch.o file but fails later on:
>
> cc1: warnings being treated as errors
> /export/home/arth/gnu/gcc.git/gcc/gcc.c: In function 'compare_files':
> /export/home/arth/gnu/gcc.git/gcc/gcc.c:6635:2: error: request for
> implicit conversion from 'void *' to 'caddr_t' not permitted in C++
> make[3]: *** [gcc.o] Error 1
> make[3]: *** Waiting for unfinished jobs
>
> The error is in an munmap() call, and a look at the  header
> shows that the funcation arguments can be either 'void *' or 'caddr_t *'
> depending on preprocessor values.

I believe that POSIX specifices that munmap takes a void * argument.  Is
there some preprocessor define we can use to direct the Solaris header
files to compile in POSIX mode?  If so, it should work to add it to
CFLAGS (using +=) in TOPLEVEL/config/mh-solaris.

Ian

Re: increasing the number of GCC reviewers

[Tom Tromey]

> "Basile" == Basile STARYNKEVITCH  writes:

Basile> I believe I might even become in a few years some kind of
Basile> gcc/ggc*.[ch] secondary reviewer. I don't want to become one
Basile> (being a reviewer is probably more a burden than an honor, and
Basile> probably consume a lot of time, and might be often boring.)

This is probably part of the problem.
Maybe there are other people who don't want to do it :-)

Tom

Re: increasing the number of GCC reviewers

[Ian Lance Taylor]

Basile STARYNKEVITCH  writes:

> I am unfortunately not attending the GCC summit which happens right
> now in Montreal.
>
> But apparently, there seems to be a lack of code reviewers for
> GCC. The few people who do review code seems to have a lot of review
> in their batch queue.
>
> Perhaps could be discussed at the summit some way to increase the set
> of reviewers, i.e. the set of people able to say Ok to a patch
> submitted on gcc-patches@
>
> Or is that question a steering committee priviledge? If it is, could
> someone ask it to them (the SC members)?

Your e-mail was raised (by Richi) during the SC panel discussion.  The
discussion in the room was much like the discussion on the list: we
would all like to have more reviewers; the problem is finding people who
are willing and able to do the job.  The SC is not a bottleneck here.

During the panel discussion, Mark Mitchell said that if anybody wants to
raise an issue with the SC, they can send him e-mail directly and he
will raise it.  I'm sure that is true of other SC members as well.

I believe that the most useful immediate thing we could do to speed up
gcc development would be to move to a distributed version control
system.  That should make it much easier for people to swap patches
around.  It should make it possible for reviewers to take a patch, make
some changes themselves, and send it back to the original submitter for
more work.  It would make it much simpler for people to reliably test
other people's patches, singly or in combination.  None of this would
eliminate the traditional role of maintainers in the gcc system;
however, I believe it would make some decisions simpler.

Ian

Re: plugin callbacks after compiler errors

[Diego Novillo]

On Tue, Jun 9, 2009 at 15:33, Taras Glek wrote:
> While developing my plugin I've noticed that many callbacks need to be
> guarded with "if (errorcount)" or the plugin will cause a gcc crash due to
> receiving less complete data than it expected.

More details please.  What exactly is the error and how is errorcount related?

> Should the plugin API guard callbacks in invoke_plugin_callbacks() to avoid
> 99% of plugins running into this issue?

At the point that plugins are invoked, they should be able to deal
with whatever state the IL is at that moment.  I'd favor flexibility
over protection here.  But I'd like to see more details on what you're
after here.


Diego.

Re: Expanding a load instruction

[Dave Korn]

Jean Christophe Beyler wrote:
> Dear all,
> 
> I've moved forward on this issue. Again, the problem is not that the
> data is not aligned but that the compiler tries to generate this
> instruction:
> 
> (set (reg:HI 141) (mem/s/j:HI (plus:DI (reg:DI 134 [ ivtmp.23 ])
>  (const_int 1 [0x1])) [0 .geno+0 S2 A16]))
> 
> And, in my target architecture, this is not authorized. I want to
> transform this into:
> 
> (set (reg:DI 135) (plus:DI (reg:DI 134 [ ivtmp.23 ])
>  (const_int 1 [0x1])) [0 .geno+0 S2 A16]))
> (set (reg:HI 141) (mem/s/j:HI (reg:DI 135))
> 
> 
> I've tried playing with define_expand, I can detect this problem, I
> can emit my first move and then the second but for some reason, the
> compiler reassembles them back together.
> 
> Any ideas why I am getting that? Am I doing anything wrong? After I
> expand this, I use the DONE macro...


  How about forbidding the form you don't allow in GO_IF_LEGITIMATE_ADDRESS?

cheers,
  DaveK

gcc-4.4-20090609 is now available

[gccadmin]

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

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

You'll find:

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

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

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

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

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

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

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

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

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

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

Re: Bootstrap failures on solaris

[Jonathan Wakely]

2009/6/9 Ian Lance Taylor:
>
> I believe that POSIX specifices that munmap takes a void * argument.  Is
> there some preprocessor define we can use to direct the Solaris header
> files to compile in POSIX mode?  If so, it should work to add it to
> CFLAGS (using +=) in TOPLEVEL/config/mh-solaris.

I tripped up on the same issue a while ago, this should work:

-D_XOPEN_SOURCE -D_XOPEN_SOURCE_EXTENDED=1

See http://www.kayari.org/doc/c++/suncc.html for other options.

Jonathan

Re: git mirror at infradead?

[Daniel Berlin]

On Tue, Jun 9, 2009 at 3:16 PM, Bernie Innocenti wrote:
> On 06/09/09 16:17, Jason Merrill wrote:
>> Bernie Innocenti wrote:
>>> On 06/07/09 12:40, Ralf Wildenhues wrote:
 Is this mirror an independent conversion from the infradead one (i.e., I
 have to throw away the repo and re-download a full repo?  Or can I reuse
 objects)?
>>>
>>> It's an independent mirror, and I wouldn't recommend switching to it yet.
>>>
>>> There are permissions problems, and I might end up rsyncing the whole
>>> infradead repository rather than fixing things locally.
>>
>> Please please do *not* rsync the infradead repository.  The repository
>> on gcc.gnu.org is set up so that I can switch back and forth between
>> pulling from git and using git-svn directly; the infradead repository is
>> not.
>>
>> For one thing, the infradead repository uses svn://gcc.gnu.org/svn/gcc,
>> which makes it impossible to use git-svn to check in changes; the
>> gcc.gnu.org git repository uses svn+ssh://gcc.gnu.org/svn/gcc, as is
>> right and proper.  Also the remotes are in a different place from where
>> git-svn puts them, though I suppose that's easy enough to adjust when
>> fetching.
>
> I won't re-create the repository from scratch, then.
>
> Though I would still need an updated version of git to enable lots of
> branches and tags without wasting too much hard disk space.
>
> Can a sourceware admin please install (or build) git 1.6.3.x?  If there
> are concerns of breaking other things, I could install a local copy in
> ~/bin.
+overseers

I don't see a problem doing this (we definitely don't want two
versions installed), but there are real live git projects on
sourceware so we should be a bit careful.

Re: increasing the number of GCC reviewers

[Ben Elliston]

On Tue, 2009-06-09 at 19:00 +0100, Andrew Haley wrote:

> I think it's a much better idea to contact Fred (or Freda, for that matter)
> Bloggs to ask them if they want to maintain reload.  :-)

Wouldn't it be Alan Smithee to maintain reload? :-)

Ben

Re: git mirror at infradead?

[Ian Lance Taylor]

Daniel Berlin  writes:

> I don't see a problem doing this (we definitely don't want two
> versions installed), but there are real live git projects on
> sourceware so we should be a bit careful.

fche has already installed git 1.6.3.2 in /usr/local/bin on sourceware.
That is now the one you will get if you connect to port "git".  Hope
nothing breaks.

Ian

Re: increasing the number of GCC reviewers

[Ben Elliston]

On Tue, 2009-06-09 at 21:13 +0200, Basile STARYNKEVITCH wrote:

> This is precisely my point. It should be perfectly acceptable that some 
> people be authorized to approve some few patches without understanding 
> the whole of GCC, and even without knowing all of it.

I sympathise with this point of view, Basile.  Over the time I have
worked on GCC, there has been a lot of modularity improvements and
improving the robustness of interfaces throughout the compiler.  If this
continues, it should be possible to understand changes in more
isolation.  While there will always be consequences that need to be
understood, but that should not apply to every change.

Ben

Re: increasing the number of GCC reviewers

[Joseph S. Myers]

On Tue, 9 Jun 2009, Ian Lance Taylor wrote:

> I believe that the most useful immediate thing we could do to speed up
> gcc development would be to move to a distributed version control
> system.

We haven't even finished the last version control system transition 
(wwwdocs is still using CVS), it's not long since we started it and there 
is as yet no one clear winner in the world of DVCSes, so another 
transition would seem rather premature.

> That should make it much easier for people to swap patches
> around.

I don't see what the present difficulty here is supposed to be.  For small 
to moderate-sized self-contained patches the precise system used makes 
little difference.  For large to huge patch series from contributors with 
write access, they are already able to create whatever branches they may 
wish.  Distributed systems would facilitate large series from contributors 
without write access, but in practice I think such contributions from 
non-regular contributors tend to run into other unrelated issues (and 
hosting a public tree the size of GCC isn't really something to consider 
"easy" whatever system is used).

> It should make it possible for reviewers to take a patch, make
> some changes themselves, and send it back to the original submitter for
> more work.

This is already possible, but I don't think difficulties with it are a 
significant problem with patch review at present.  If the original 
submitter is to submit further patches then having them understand the 
deficiencies enough to fix them themselves is generally better than fixing 
them for them.  (The simpler case of fixing the submitted patch and 
committing the fixed version is already quite common.)

> It would make it much simpler for people to reliably test
> other people's patches, singly or in combination.

As I observe it difficulties in dealing with other people's patches arise 
not because of version control choices but because of interactions between 
logical changes expressed textually in patches, especially global 
mechanical changes, and semantic patch tools seem to me to be more 
promising to help in such areas.

I have observed patch review and its failures in action through following 
the main GCC lists since the start of EGCS.  It's not the large and 
complicated patches than in my experience have difficulty getting 
reviewed; those generally come from people with extensive experience of 
GCC development, and if those people cannot approve their own patches 
there are other people with sufficient interest in them who do so.  It's 
smaller patches, and patches from outsiders, that have the greater 
difficulty, while it's complicated patches from sophisticated developers 
that more advanced version control systems help more with.

If a patch does not attract the interest and attention of reviewers when 
posted, there is no system (human or technical) to notice this and to 
track that it still needs review and who might be a suitable reviewer, 
other than the submitter pinging it.  If a patch is submitted by an 
outsider who hasn't followed all the documentation on submitting patches, 
and may not have properly tested it, or described how it was tested, or 
written a proper ChangeLog entry, or formatted it according to the coding 
standards, or followed the correct abstractions, the fact it doesn't look 
like a normal submission and requires greater effort to review makes it 
less likely to be reviewed.  If a patch from an outsider is nevertheless 
approved, the approver will typically say it is OK, and it will be up to 
the outsider to reply that they don't have write access and get someone to 
commit it.

At the human level I suspect it would help to have people who watch for 
submissions from non-regulars (including those attached to Bugzilla) and 
help them prepare patches following all the usual conventions and get them 
reviewed (checking for copyright assignments at an early stage as needed) 
and make sure the submissions don't get lost.  At the technical level, 
while submissions on gcc-patches take a wide variety of forms, approvals 
are more restricted; it ought to be possible for software to do a 
reasonably good job of tracking which submissions have been reviewed / 
approved / committed (including noticing people trying to submit patches 
through Bugzilla), and of identifying the most likely relevant maintainers 
to review patches, aided by humans in keeping the data clean.

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

skip_evaluation

[Ian Lance Taylor]

I have a question for C++ language lawyers.  The common part of the
C/C++ frontends has a global variable named skip_evaluation.  Both
frontends set this variable while parsing an expression inside sizeof
and friends.  This has the effect of disabling various warnings which
are irrelevant for code which is not going to be executed.  The C
frontend also sets skip_evaluation for constructs like (0 ? x : y) when
parsing the portion of the expression which will never be executed.  The
C++ frontend does not do this.

My question is whether it would be OK for the C++ frontend to also set
skip_evaluation for (0 ? x : y) or whether I should introduce a
different variable.


In asking this, I'm particularly puzzled by code like this in
build_base_path in cp/class.c:

  /* Don't bother with the calculations inside sizeof; they'll ICE if the
 source type is incomplete and the pointer value doesn't matter.  */
  if (skip_evaluation)
{
  expr = build_nop (build_pointer_type (target_type), expr);
  if (!want_pointer)
expr = build_indirect_ref (EXPR_LOCATION (expr), expr, NULL);
  return expr;
}

Presumably the early return is OK within a sizeof expression; it is OK
within an expression like (0 ? x : y)?


I want to handle this one way or another in the C++ frontend in order to
handle expressions like this in the generated file insn-modes.c:

#define MODE_MASK(m)  \
  ((m) >= HOST_BITS_PER_WIDE_INT) \
   ? ~(unsigned HOST_WIDE_INT) 0  \
   : ((unsigned HOST_WIDE_INT) 1 << (m)) - 1

When m >= HOST_BITS_PER_WIDE_INT is true, this generates a warning "left
shift count >= width of type".  In C this warning is disabled by
skip_evaluation.  I would like to implement the same feature in C++.

Ian

Re: git mirror at infradead?

[Angela Marie Thomas]

i...@google.com wrote:

> Daniel Berlin  writes:
> 
> > I don't see a problem doing this (we definitely don't want two
> > versions installed), but there are real live git projects on
> > sourceware so we should be a bit careful.
> 
> fche has already installed git 1.6.3.2 in /usr/local/bin on sourceware.
> That is now the one you will get if you connect to port "git".  Hope
> nothing breaks.

Someone should rpm -e the git RPMs as well.

--Angela

Re: increasing the number of GCC reviewers

[Ian Lance Taylor]

"Joseph S. Myers"  writes:

> At the human level I suspect it would help to have people who watch for 
> submissions from non-regulars (including those attached to Bugzilla) and 
> help them prepare patches following all the usual conventions and get them 
> reviewed (checking for copyright assignments at an early stage as needed) 
> and make sure the submissions don't get lost.  At the technical level, 
> while submissions on gcc-patches take a wide variety of forms, approvals 
> are more restricted; it ought to be possible for software to do a 
> reasonably good job of tracking which submissions have been reviewed / 
> approved / committed (including noticing people trying to submit patches 
> through Bugzilla), and of identifying the most likely relevant maintainers 
> to review patches, aided by humans in keeping the data clean.

I agree, and I think it is in fact precisely at this step where a
distributed version control system can be most helpful.  But I'm not
going to belabor the point.

Ian

Re: increasing the number of GCC reviewers

[Tom Tromey]

> "Joseph" == Joseph S Myers  writes:

Ian> I believe that the most useful immediate thing we could do to speed up
Ian> gcc development would be to move to a distributed version control
Ian> system.

Joseph> We haven't even finished the last version control system
Joseph> transition (wwwdocs is still using CVS), it's not long since
Joseph> we started it and there is as yet no one clear winner in the
Joseph> world of DVCSes, so another transition would seem rather
Joseph> premature.

There will never be a clear winner.  git and hg are in wide use on big
projects.  Either one would probably work reasonably for gcc.  Neither
is likely to kill off the other.

Tom

Re: increasing the number of GCC reviewers

[Dave Korn]

Ben Elliston wrote:
> On Tue, 2009-06-09 at 19:00 +0100, Andrew Haley wrote:
> 
>> I think it's a much better idea to contact Fred (or Freda, for that matter)
>> Bloggs to ask them if they want to maintain reload.  :-)
> 
> Wouldn't it be Alan Smithee to maintain reload? :-)
> 
> Ben

  Burn, Reload, Burn?

cheers,
  DaveK

Re: plugin callbacks after compiler errors

[Taras Glek]

Diego Novillo wrote:

On Tue, Jun 9, 2009 at 15:33, Taras Glek wrote:
  

While developing my plugin I've noticed that many callbacks need to be
guarded with "if (errorcount)" or the plugin will cause a gcc crash due to
receiving less complete data than it expected.



More details please.  What exactly is the error and how is errorcount related?

  

Should the plugin API guard callbacks in invoke_plugin_callbacks() to avoid
99% of plugins running into this issue?



At the point that plugins are invoked, they should be able to deal
with whatever state the IL is at that moment.  I'd favor flexibility
over protection here.  But I'd like to see more details on what you're
after here.
  
This is more of a polish issue than anything else. Trouble is that one 
may never see these bugs during plugin development unless the plugins 
are tested on files that have syntax errors.


   Test command: /home/bradh/devel/gcc-build/gcc/cc1 -quiet -O1
-ftest-coverage -fplugin=../gcc_dehydra.so -o /dev/null
-fplugin-arg-gcc_dehydra-=test_numinfo.js numinfo.cc
   Failure msg: Expected 'OK' output; Errors:
numinfo.cc:14:6: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’
before ‘boolvar’
numinfo.cc:19:7: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before
‘enumvar’
numinfo.cc:21:7: error: expected identifier or ‘(’ before ‘&’ token
numinfo.cc:22:21: error: ‘enumvar’ undeclared here (not in a function)
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
EventPlugins
PLUGIN_FINISH_TYPEgcc_dehydra 
PLUGIN_FINISH_UNITgcc_dehydra 
PLUGIN_CXX_CP_PRE_GENERICIZEgcc_dehydra 
PLUGIN_FINISHgcc_dehydra 
PLUGIN_EVENT_LASTgcc_dehydra 
plugin_initgcc_dehydra 
numinfo.cc:22:1: internal compiler error: tree check: expected class ‘type’,

have ‘exceptional’ (error_mark) in process_type, at dehydra_plugin.c:139
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Stuff like FINISH_TYPE, PLUGIN_CXX_CP_PRE_GENERICIZE, etc can end up with error 
nodes instead of what is normally expected to be there.

I can't imagine a usecase for when it would be useful for a plugin to 
have the error marker node.


As I said, it's a minor polish issue. It may be sufficient to just have 
a note in the documentation as Basil suggested.



Taras

Re: increasing the number of GCC reviewers

[Daniel Berlin]

On Tue, Jun 9, 2009 at 8:51 PM, Joseph S. Myers wrote:
> On Tue, 9 Jun 2009, Ian Lance Taylor wrote:
>
>> I believe that the most useful immediate thing we could do to speed up
>> gcc development would be to move to a distributed version control
>> system.
>
> We haven't even finished the last version control system transition
> (wwwdocs is still using CVS), it's not long since we started it and there
> is as yet no one clear winner in the world of DVCSes, so another
> transition would seem rather premature.
There will never be a clear winner here, because none of them is
"better enough" than the others, nor is it likely they ever will be.
At least hg and git have significant mindshare, and seem to attract
different kinds of communities.

Personally, I think at this point, moving to git would make the most
sense (as much as I love hg). It's much more forgiving than it used to
be, most things support it, and there are some cool possibilities,
like gerrit (http://code.google.com/p/gerrit/).  It is precisely built
to handle the problem of finding the right reviewers, making sure
patches don't fall through the cracks, while still making sure it's
easy to submit patches and have maintainers merge them.
I'm happy to set up a demo if anyone wants to see it.

As for advantages, having used both hg and git, the only thing i ever
use svn for anymore is to occasionally patch into a clean tree to do a
commit.

Lastly, as for wwwdocs, it's more a case of "migration of wwwdocs was
left to those who care about it", which is a very small set of people.
Combined with the fact that it has a bunch of preprocessing/etc
scripts that get run over it, and nobody wants to do the conversion.

Re: sched2, ret, use, and VLIW bundling

[DJ Delorie]

> The problem may be in the dependency cost between the SET (insn 27)
> and the USE (insn 30) being >= 1.  Have you tried using
> targetm.sched.adjust_cost() hook to set the cost of USE to 0?

It doesn't get called for those two insns.

> Anyway, this seems strange, the scheduler should just output the
> USEs as soon as they are ready.

It does - that's the problem.  The SET is setting the register that
the USE is using, so the scheduler won't pack them together.

I want to disable that, since *I* know that the USE is only there to
keep the return value from being optimized away; the value isn't an
actual dependency *there*.

Re: sched2, ret, use, and VLIW bundling

[DJ Delorie]

Some progress... the scheduler is willing to schedule them together if
I define the SCHED_REORDER2 hook (just SCHED_REORDER was
insufficient), and always return the number of ready insns.  In my
case, the VLIW packing restrictions are fully defined by a DFA; I
don't need to further restrict packing.

Re: Please update http://gcc.gnu.org/gcc-4.3/buildstat.html

[Tom Christensen]

Dennis Clarke wrote:

Re: http://gcc.gnu.org/gcc-4.3/buildstat.html

I was looking for testsuite results to compare with on Solaris and I saw
that nearly every report for GCC 4.3.3 was done by Tom G. Christensen.

All GCC 4.3.3 reports on Solaris from one person :



You better get cracking on 4.4.0 aswell since I posted most of those 
reports too ;)



I think it is great we have any report at all but for the sake of
diversity and some comparison data I'll add mine in there :


More testresults are always welcome.


Results for 4.3.3 (GCC) testsuite on sparc-sun-solaris2.8
http://gcc.gnu.org/ml/gcc-testresults/2009-06/msg00501.html


Thank you.


I'll get the i386 reports later this week.


Sounds good.

The testresults will be added with the next round of updates which I 
plan to do early next week.


-tgc

Re: New Moxie port and maintainer

[Anthony Green]

Gerald Pfeifer wrote:

It is my pleasure to announce that the steering committee is
appointing Anthony Green as maintainer of the new Moxie port
that has been approved from a technical perspective as well.

Please adjust the MAINTAINERS file accordingly, Anthony, and
happy hacking!  And of course, go ahead and commit the thing. :-)

Gerald
  

Thanks!  I just checked it in.

AG