“x--” would self-add before opration "--" ？

[pem]

Hello list,

Yestoday I encounter this problem during a test:

1int x = 11;
2std::cout<< x <<  x-- << ++x;

I think it should be :
11 11 11


I wrote the fellowing code :

#include 

int main() {
int x = 11;
std::cout<< x <<  x-- << ++x << std::endl;
}

compile the code above with g++ 4.5.0, after run, it gives:
11 12 11


#include 

int main() {
   int x = 11;
   printf("%d %d %d\n", x, x--, ++x);
}

the c code compiled with gcc gives the same result.


But when I use clang and clang++ to compile the codes above, I get:
11 11 11. 

I am not familar with both c++ and compiler implementation, donot konw 
why the results are differnt for gcc and clang. Anyone could help and 
explain this difference for me?


Thanks,

Ryan Ren

Re: “x--” would self-add before opration "--" ？

[Paolo Bonzini]

On 06/07/2010 09:38 AM, pem wrote:

I am not familar with both c++ and compiler implementation, donot konw
why the results are differnt for gcc and clang. Anyone could help and
explain this difference for me?


First of all, this would be a question for gcc-h...@gcc.gnu.org.  This 
mailing list is for development _of_ gcc, not _with_ gcc.


Your question is answered by the documentation of -Wsequence-point:

`-Wsequence-point'
 Warn about code that may have undefined semantics because of
 violations of sequence point rules in the C and C++ standards.

 The C and C++ standards defines the order in which expressions in
 a C/C++ program are evaluated in terms of "sequence points", which
 represent a partial ordering between the execution of parts of the
 program: those executed before the sequence point, and those
 executed after it.  These occur after the evaluation of a full
 expression (one which is not part of a larger expression), after
 the evaluation of the first operand of a `&&', `||', `? :' or `,'
 (comma) operator, before a function is called (but after the
 evaluation of its arguments and the expression denoting the called
 function), and in certain other places.  Other than as expressed
 by the sequence point rules, the order of evaluation of
 subexpressions of an expression is not specified.  All these rules
 describe only a partial order rather than a total order, since,
 for example, if two functions are called within one expression
 with no sequence point between them, the order in which the
 functions are called is not specified.  However, the standards
 committee have ruled that function calls do not overlap.

 It is not specified when between sequence points modifications to
 the values of objects take effect.  Programs whose behavior
 depends on this have undefined behavior; the C and C++ standards
 specify that "Between the previous and next sequence point an
 object shall have its stored value modified at most once by the
 evaluation of an expression.  Furthermore, the prior value shall
 be read only to determine the value to be stored.".  If a program
 breaks these rules, the results on any particular implementation
 are entirely unpredictable.

 Examples of code with undefined behavior are `a = a++;', `a[n] =
 b[n++]' and `a[i++] = i;'.  Some more complicated cases are not
 diagnosed by this option, and it may give an occasional false
 positive result, but in general it has been found fairly effective
 at detecting this sort of problem in programs.

 The standard is worded confusingly, therefore there is some debate
 over the precise meaning of the sequence point rules in subtle
 cases.  Links to discussions of the problem, including proposed
 formal definitions, may be found on the GCC readings page, at
 `http://gcc.gnu.org/readings.html'.

 This warning is enabled by `-Wall' for C and C++.

In general, I suggest that you always use the -Wall option, so that you 
will get warnings for dobious code such as the one you pointed out.


Paolo

Re: “x--” would self-add before opration "--" ？

[pem]

Sorry for missing version info of my compiler:

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-
wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --prefix=/usr --enable-
languages=c,c++,fortran,objc,obj-c++,ada --enable-shared --enable-
threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-lto --
enable-gnu-unique-object --disable-multilib --disable-libstdcxx-pch --
with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --
libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
Thread model: posix
gcc version 4.5.0 (GCC) 

$ clang -v
clang version 1.1 (branches/release_27)
Target: x86_64-unknown-linux-gnu
Thread model: posix

MPFR 3.0.0 RC2 and GCC build (was: GNU MPFR 3.0.0 Release Candidate 2)

[Vincent Lefevre]

On 2010-06-06 22:34:50 +0200, Vincent Lefevre wrote:
> Here's a second release candidate. As there should not be new
> platform-specific problems, the final release is delayed by a
> few days only.
> 
> http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.xz
> http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.bz2
> http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.gz
> http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.zip
> 
> The MD5's:
> fd030e33d11ceb3063e2623400f881f9  mpfr-3.0.0-rc2.tar.bz2
> 3077131f0941f49ca0ab7874d90f87fa  mpfr-3.0.0-rc2.tar.gz
> df8df9d5f68e26d6a476235608e12eda  mpfr-3.0.0-rc2.tar.xz
> 955797eb38032d0af7613bba742fc465  mpfr-3.0.0-rc2.zip
> 
> The signatures:
> http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.xz.asc
> http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.bz2.asc
> http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.tar.gz.asc
> http://www.mpfr.org/mpfr-3.0.0/mpfr-3.0.0-rc2.zip.asc
> 
> Changes from versions 2.4.* to version 3.0.0:
[...]

There's also the following change:

- The detection of a GMP build directory (more precisely, the internal
  header files of GMP) was previously done separately from the use of
  the --with-gmp-build configure option. This was not consistent with
  the documentation and with other parts of the configure script. So,
  as of MPFR 3.0.0, the internal header files of GMP are now used if
  and only if the --with-gmp-build configure option is given.

Due to this correction, some user had problems to build MPFR for GCC
(he had no problems with MPFR 2.4.2). Could you also try to build
the MPFR 3.0.0 release candidate for GCC, according to the various
ways of doing that?

I'm not sure whether something needs to be done in MPFR.

Thanks in advance,

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

Reminder: trunk frozen starting late tonight for gc-improv merge

[Laurynas Biveinis]

Hi all,

Just a reminder, as discussed on thread starting at
http://gcc.gnu.org/ml/gcc/2010-06/msg00092.html

-- 
Laurynas

Re: “x--” would self-add before opration "-- " ？

[Andi Hellmund]

> I am not familar with both c++ and compiler implementation, donot konw
> why the results are differnt for gcc and clang. Anyone could help and
> explain this difference for me?

The ISO C standard says that the evaluation order of function arguments is
unspecified [ISO C99, 6.5.2.2-11], though the implementation (GCC vs.
clang) is free to choose which evaluation order to use. That's why you see
these differences between GCC and clang.

Andi

Re: Patch pinging

[NightStrike]

On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo  wrote:
> On Wed, Jun 2, 2010 at 14:09, NightStrike  wrote:
>
>> threads that haven't been addressed.  I offered to Ian to do the same
>> thing for the whole mailing list if we can make it a policy that
>> people who commit changes do what Kai is doing so that it's clear that
>> the thread is done with.  I don't mind throwing a few pings down, and
>> I already have the whole ML tagged with a gmail label.
>
> Seems like a good idea to me.  I do not usually read the list every
> day (or every week some times), so if a patch is in my area and I had
> not been directly CC'd, it can take me up to 2 weeks to get to it.
>
> Most of the areas I'm on had good coverage (particularly since I share
> much with richi who is a very prolific patch reviewer), so it's not
> too much of a problem.

Ok.  Is one person responding enough for me to start doing that?  I
don't know how this sort of approval / acceptance process works for
GCC.

Re: Patch pinging

[Martin Guy]

On 6/7/10, NightStrike  wrote:
> On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo  wrote:
>  > On Wed, Jun 2, 2010 at 14:09, NightStrike  wrote:
>  >
>  >> threads that haven't been addressed.  I offered to Ian to do the same
>  >> thing for the whole mailing list if we can make it a policy that
>  >> people who commit changes do what Kai is doing so that it's clear that
>  >> the thread is done with.  I don't mind throwing a few pings down, and
>  >> I already have the whole ML tagged with a gmail label.
>  >
>  > Seems like a good idea to me.  I do not usually read the list every
>  > day (or every week some times), so if a patch is in my area and I had
>  > not been directly CC'd, it can take me up to 2 weeks to get to it.
>  >
>  > Most of the areas I'm on had good coverage (particularly since I share
>  > much with richi who is a very prolific patch reviewer), so it's not
>  > too much of a problem.
>
>  Ok.  Is one person responding enough for me to start doing that?  I
>  don't know how this sort of approval / acceptance process works for
>  GCC.

Excellent idea and thanks for volunteering..

M

Re: GNU MPFR 3.0.0 Release Candidate 2

[David Edelsohn]

powerpc-ibm-aix5.3.0.0
gcc-4.4.3
gmp-4.3.1
configured using --with-gmp-build=

configure failed with missing longlong.h and gmp-impl.h.  Manually
copying those header files to the build directory allowed configure
and build to succeed.


All 156 tests passed


David

gfortran requires input files for linking?

[Peter O'Gorman]

Hi,

The libtool-2.2.8 testsuite fails some tests on darwin10 with gfortran 
because it makes use of Apple ld's -force_load flag to load all members 
of convenience archives. One of the tests creates link lines like:


gfortran -dynamiclib -Wl,-undefined -Wl,dynamic_lookup -o 
.libs/liba12.0.dylib   -Wl,-force_load,./.libs/liba1.a 
-Wl,-force_load,./.libs/liba2.a -install_name /notexist/liba12.0.dylib 
-compatibility_version 1 -current_version 1.0 -Wl,-single_module


For which gfortran complains:
gfortran: no input files; unwilling to write output files

and exits with error.

On my linux system, it has a link line that, while similar, passes 
gfortran's test for input files:
gfortran -shared  -Wl,--whole-archive ./.libs/liba1.a ./.libs/liba2.a 
-Wl,--no-whole-archive  -L/usr/lib/gcc/i686-redhat-linux/4.4.4 
-L/usr/lib/gcc/i686-redhat-linux/4.4.4/../../.. -lgfortranbegin 
-lgfortran -lm -lc -lgcc_s-Wl,-soname -Wl,liba12.so.0 -o 
.libs/liba12.so.0.0.0


The only difference being that the archives are not -Wl, quoted.

Would the maintainers accept a patch that either
a) removes any checking for input files
or
b) warns instead of errors if it sees no input files

and which would be preferred?

Thanks,
Peter

Re: Patch pinging

[Ian Lance Taylor]

NightStrike  writes:

> On Wed, Jun 2, 2010 at 3:17 PM, Diego Novillo  wrote:
>> On Wed, Jun 2, 2010 at 14:09, NightStrike  wrote:
>>
>>> threads that haven't been addressed.  I offered to Ian to do the same
>>> thing for the whole mailing list if we can make it a policy that
>>> people who commit changes do what Kai is doing so that it's clear that
>>> the thread is done with.  I don't mind throwing a few pings down, and
>>> I already have the whole ML tagged with a gmail label.
>>
>> Seems like a good idea to me.  I do not usually read the list every
>> day (or every week some times), so if a patch is in my area and I had
>> not been directly CC'd, it can take me up to 2 weeks to get to it.
>>
>> Most of the areas I'm on had good coverage (particularly since I share
>> much with richi who is a very prolific patch reviewer), so it's not
>> too much of a problem.
>
> Ok.  Is one person responding enough for me to start doing that?  I
> don't know how this sort of approval / acceptance process works for
> GCC.

I would say that since you did not get any objections, you should try
it.  Of course, you may well get objections at that point, in which
case we should take the conversation back here.

Thanks for volunteering.

Ian

GCC 4.6 secondary platform update

[Paolo Bonzini]

From http://gcc.gnu.org/ml/gcc/2009-09/msg00501.html:


we looked at the current list of primary and
secondary targets and suggested (again) to demote i686-apple-darwin to
a secondary platform on the base that it is unmaintained.  We
recognize that it is used and gets many bugs filed against.
It was suggested to drop powerpc-apple-darwin from the list of
secondary platforms.


This was done.


It was also suggested to change hppa2.0w-hp-hpux11.11
to ia64-hpux and to change s390-linux-gnu to s390x-linux-gnu in the
list of secondary targets.


Shall we proceed?

Paolo

Re: GNU MPFR 3.0.0 Release Candidate 2

[Vincent Lefevre]

On 2010-06-07 10:17:18 -0400, David Edelsohn wrote:
> powerpc-ibm-aix5.3.0.0
> gcc-4.4.3
> gmp-4.3.1
> configured using --with-gmp-build=
> 
> configure failed with missing longlong.h and gmp-impl.h.  Manually
> copying those header files to the build directory allowed configure
> and build to succeed.

The --with-gmp-build option was meant to use GMP's internal header
files and assumed that GMP was built in its source directory. With
MPFR 2.4.2, it didn't fail, but GMP's internal header files weren't
used in the above case.

What if you do not use --with-gmp-build?

Note: you can use --with-gmp-include and --with-gmp-lib if need be.

Is this OK?

Or should --with-gmp-build only set CPPFLAGS and LDFLAGS, without
considering GMP internal header files (in such as case, a new option
e.g. --with-gmp-internals could be added)?

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

Re: Patch pinging

[Eric Botcazou]

> Recently on #gcc, I have been conversing with several others on the
> topic of patches lost in the tides of the gcc-patches mailing list.  I
> flagged Jeff Downs' recent message as an example of a patch that has
> been waiting since November
> (http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00177.html).  I then
> volunteered to be a patch pinger, to watch the mailing list and ping
> patches that don't get responses.  I currently do this for Win64 work
> anyway, so I already read most of the mailing list as it is.

I'd avoid sending random "Ping.. was this committed" messages though, that's 
rather annoying.  The gcc-cvs archives are http://gcc.gnu.org/ml/gcc-cvs/

-- 
Eric Botcazou

[Patch,Fortran,Committed] Re: Incorrect format of copyright statement for Fortran manuals

[Tobias Burnus]

Gerald Pfeifer wrote:
> It has been reported via the FSF that 'gfortran.info' is copyrighted by 
> the FSF '1999-2008', although it should be under the form '1999, 2000, 
> [other years], 2008'.
>
> Would you mind changing this accordingly?
>   

Fixed in Rev. 160390 using the attached patch.

Thanks for the report!

Tobias
2010-06-07  Tobias Burnus  

	* gfc-internals.texi (copyrights-gfortran): Fix copyright year format.
	* gfortran.texi (copyrights-gfortran): Ditto.

diff --git a/gcc/fortran/gfc-internals.texi b/gcc/fortran/gfc-internals.texi
index f01393e..cee34a0 100644
--- a/gcc/fortran/gfc-internals.texi
+++ b/gcc/fortran/gfc-internals.texi
@@ -1,7 +1,7 @@
 \input texinfo  @c -*-texinfo-*-
 @c %**start of header
 @setfilename gfc-internals.info
-...@set copyrights-gfortran 2007-2010
+...@set copyrights-gfortran 2007, 2008, 2009, 2010
 
 @include gcc-common.texi
 
diff --git a/gcc/fortran/gfortran.texi b/gcc/fortran/gfortran.texi
index a7f6fba..96a912e 100644
--- a/gcc/fortran/gfortran.texi
+++ b/gcc/fortran/gfortran.texi
@@ -1,7 +1,7 @@
 \input texinfo  @c -*-texinfo-*-
 @c %**start of header
 @setfilename gfortran.info
-...@set copyrights-gfortran 1999-2010
+...@set copyrights-gfortran 1999, 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010
 
 @include gcc-common.texi
 

Re: Patch pinging

[NightStrike]

On Mon, Jun 7, 2010 at 1:01 PM, Eric Botcazou  wrote:
>> Recently on #gcc, I have been conversing with several others on the
>> topic of patches lost in the tides of the gcc-patches mailing list.  I
>> flagged Jeff Downs' recent message as an example of a patch that has
>> been waiting since November
>> (http://gcc.gnu.org/ml/gcc-patches/2010-06/msg00177.html).  I then
>> volunteered to be a patch pinger, to watch the mailing list and ping
>> patches that don't get responses.  I currently do this for Win64 work
>> anyway, so I already read most of the mailing list as it is.
>
> I'd avoid sending random "Ping.. was this committed" messages though, that's
> rather annoying.  The gcc-cvs archives are http://gcc.gnu.org/ml/gcc-cvs/

Annoying or not, I wasn't offering to sift through svn commit logs.
It's very trivial for me to read through a mailing list that I already
read, and scan for messages that say "committed to branch B at
revision R."  It's a lot more complicated to find out if something has
been committed myself, for every single patch out there, when the
committer already knows and can send his followup message saying that
the patch went in.  Ideally, after a day of this, people will start
sending such messages to effectively close threads, and then you'll
see very few messages from me.

Re: Patch pinging

[Eric Botcazou]

> Annoying or not, I wasn't offering to sift through svn commit logs.
> It's very trivial for me to read through a mailing list that I already
> read, and scan for messages that say "committed to branch B at
> revision R."  It's a lot more complicated to find out if something has
> been committed myself, for every single patch out there, when the
> committer already knows and can send his followup message saying that
> the patch went in.

Then browse the ChangeLog files.

> Ideally, after a day of this, people will start sending such messages to
> effectively close threads, and then you'll see very few messages from me.

Please no, that's just a sheer waste of time/bandwidth/storage.

-- 
Eric Botcazou

Re: Patch pinging

[Paolo Carlini]

On 06/07/2010 09:23 PM, NightStrike wrote:
> Annoying or not, I wasn't offering to sift through svn commit logs.
> It's very trivial for me to read through a mailing list that I already
> read, and scan for messages that say "committed to branch B at
> revision R."  It's a lot more complicated to find out if something has
> been committed myself, for every single patch out there, when the
> committer already knows and can send his followup message saying that
> the patch went in.  Ideally, after a day of this, people will start
> sending such messages to effectively close threads, and then you'll
> see very few messages from me.
>   
I'm seeing all those "did you commit it yet?" without even attempting to
check yourself if the patch has been actually committed (it's trivial).
IMO, it doesn't make sense. To be clear, you will *never* get replies
from me.

Paolo.

Re: Patch pinging

[Steven Bosscher]

On Mon, Jun 7, 2010 at 9:23 PM, NightStrike  wrote:
>  Ideally, after a day of this, people will start
> sending such messages to effectively close threads, and then you'll
> see very few messages from me.

That's a one way trip to my bozo bin...

Ciao!
Steven

Re: Patch pinging

[NightStrike]

On Mon, Jun 7, 2010 at 4:23 PM, Joern Rennecke
 wrote:
> Quoting NightStrike :
>
>> Annoying or not, I wasn't offering to sift through svn commit logs.
>
> How about requiring that a patch should have an associated open PR with the
> patch keyword to be considered for pinging.
> Then you can do a bugzilla search for all open PRs with the patch keyword.
>

I suggested that a long time ago on irc, but was brutally shot down
for it.  Apparently, most people hate bugzilla :(  To be clear, what I
suggested was that every patch should have a PR.  There is way too
much duplication of purpose between bugzilla, gcc-bugs, and
gcc-patches.

TBH, I was sort of doing this manually to start for Jakub's patches
that had a PR with "Fixed" at the bottom of them.  I didn't ping on
any of those.  That was extra work, but it was doable.

Reading gcc-cvs, or ChangeLogs, or other things like that is just way
too much time.

Re: Patch pinging

[Ian Lance Taylor]

Paolo Carlini  writes:

> On 06/07/2010 09:23 PM, NightStrike wrote:
>> Annoying or not, I wasn't offering to sift through svn commit logs.
>> It's very trivial for me to read through a mailing list that I already
>> read, and scan for messages that say "committed to branch B at
>> revision R."  It's a lot more complicated to find out if something has
>> been committed myself, for every single patch out there, when the
>> committer already knows and can send his followup message saying that
>> the patch went in.  Ideally, after a day of this, people will start
>> sending such messages to effectively close threads, and then you'll
>> see very few messages from me.
>>   
> I'm seeing all those "did you commit it yet?" without even attempting to
> check yourself if the patch has been actually committed (it's trivial).
> IMO, it doesn't make sense. To be clear, you will *never* get replies
> from me.

The gcc project currently has a problem: when people who are not
regular gcc developers send in a patch, those patches often get
dropped.  They get dropped because they do not get reviewed, and they
get dropped because after review they do not get committed.  This
discourages new developers and it means that the gcc project does not
move as fast as it could.

Nightstrike volunteered to implement one approach which could improve
matters: http://gcc.gnu.org/ml/gcc/2010-06/msg00154.html .  It
requires a change in process: after committing a patch, we send a
"committed" message on the thread on gcc-patches.  Some people already
do this.

Note that the plethora of patch pings will not continue if people
routinely send "committed" messages.

The question we face now is: are we willing to change our process in
order to improve it?  And, if we are willing, is this specific change
a reasonable one to make?

It is certainly true that this could be done in different ways.
However, nobody is volunteering to implement those other ways.
Somebody is volunteering to implement this way.  Are we willing to try
this, since we have a volunteer?  Or should we do nothing until and
unless somebody is willing to volunteer to implement something else?

Ian

Re: Patch pinging

[Paolo Carlini]

On 06/07/2010 10:31 PM, Ian Lance Taylor wrote:
> The question we face now is: are we willing to change our process in
> order to improve it?
Maybe. Currently, I have zero problems with it.
>   And, if we are willing, is this specific change
> a reasonable one to make?
>   
No.

Paolo.

Re: Patch pinging

[Joseph S. Myers]

On Mon, 7 Jun 2010, NightStrike wrote:

> I suggested that a long time ago on irc, but was brutally shot down
> for it.  Apparently, most people hate bugzilla :(  To be clear, what I
> suggested was that every patch should have a PR.  There is way too
> much duplication of purpose between bugzilla, gcc-bugs, and
> gcc-patches.

For the record: I don't care for requiring Bugzilla for all submissions, 
but having it as an optional way of submitting patches, especially those 
for bugs that already have PRs, seems a good idea to me *if* it can be 
made to send the *full text* of any patch attachment and any replies to it 
in the body of a message to gcc-patches, not just gcc-bugs.

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

Re: Patch pinging

[Jeff Law]

On 06/07/10 14:31, Ian Lance Taylor wrote:

The gcc project currently has a problem: when people who are not
regular gcc developers send in a patch, those patches often get
dropped.  They get dropped because they do not get reviewed, and they
get dropped because after review they do not get committed.  This
discourages new developers and it means that the gcc project does not
move as fast as it could.

   
So perhaps the thing to do is somehow separate patches from regular 
contributors and irregular contributors.  A relatively easy way to do 
this would be for a regular contributor to include a keyword in their 
message to gcc-patches to mark the thread as not needing 3rd party 
tracking/pings.


Just thinking out loud,
Jeff

Re: Patch pinging

[Paolo Carlini]

On 06/07/2010 11:05 PM, Jeff Law wrote:
> On 06/07/10 14:31, Ian Lance Taylor wrote:
>> The gcc project currently has a problem: when people who are not
>> regular gcc developers send in a patch, those patches often get
>> dropped.  They get dropped because they do not get reviewed, and they
>> get dropped because after review they do not get committed.  This
>> discourages new developers and it means that the gcc project does not
>> move as fast as it could.
> So perhaps the thing to do is somehow separate patches from regular
> contributors and irregular contributors.  A relatively easy way to do
> this would be for a regular contributor to include a keyword in their
> message to gcc-patches to mark the thread as not needing 3rd party
> tracking/pings.
This makes sense. Thinking out loud myself, even for irregular
contributors, the idea of a ping-man doesn't really sound right, it's a
boring and error-prone task. Can anybody think of a way to automate the
job? For patches corresponding to Bugzilla entries we already have, more
or less, a complete procedure in place, I wonder if we could do
something for the other contributions...

Paolo.

Re: Patch pinging

[Ian Lance Taylor]

Paolo Carlini  writes:

> On 06/07/2010 10:31 PM, Ian Lance Taylor wrote:
>> The question we face now is: are we willing to change our process in
>> order to improve it?
> Maybe. Currently, I have zero problems with it.

I understand that you have no problems with the current process.  As I
said in the e-mail to which you are replying, the problems arise for
people who are not familiar with the process.  It is difficult for
people who are not regular gcc contributors to contribute to gcc.  I
think it is important for the long-term health of the project for us
to continue looking for ways to lower the barriers for new
contributors.


>>   And, if we are willing, is this specific change
>> a reasonable one to make?
>>   
> No.

Can you expand?  What kinds of process changes would be reasonable to
make?

Ian

Re: Patch pinging

[Paolo Carlini]

On 06/07/2010 11:16 PM, Ian Lance Taylor wrote:
> Can you expand? What kinds of process changes would be reasonable to
> make?
>   
Following the terminology "irregular contributor", per Jeff message, I
would not consider unreasonable for irregular contributions to use more
extensively and consistently the patch-queue, which we have been using
for some time. In that way all the patches would be perfectly tracked,
as far as I can see. The last days I have been traveling, thus sorry if
I missed parts of the discussion, but I don't understand why the
patch-queue mechanism is not being seriously considered...

Paolo.

Re: Patch pinging

[Ian Lance Taylor]

Paolo Carlini  writes:

> This makes sense. Thinking out loud myself, even for irregular
> contributors, the idea of a ping-man doesn't really sound right, it's a
> boring and error-prone task. Can anybody think of a way to automate the
> job? For patches corresponding to Bugzilla entries we already have, more
> or less, a complete procedure in place, I wonder if we could do
> something for the other contributions...

I am 100% in favor of automating the job, but there is little point in
discussing how we can automate the job unless somebody is prepared to
volunteer to actually do the work.  We do have a volunteer willing to
be a ping-man.

Would anybody care to volunteer to implement something?

Ian

Re: Patch pinging

[Andrew Pinski]

On Mon, Jun 7, 2010 at 2:21 PM, Paolo Carlini  wrote:
> On 06/07/2010 11:16 PM, Ian Lance Taylor wrote:
>> Can you expand? What kinds of process changes would be reasonable to
>> make?
>>
> Following the terminology "irregular contributor", per Jeff message, I
> would not consider unreasonable for irregular contributions to use more
> extensively and consistently the patch-queue, which we have been using
> for some time. In that way all the patches would be perfectly tracked,
> as far as I can see. The last days I have been traveling, thus sorry if
> I missed parts of the discussion, but I don't understand why the
> patch-queue mechanism is not being seriously considered...

Here are my two cents on this issue.
I think we have several issues we are trying to solve.
1) Some patches which have been approved are not applied.
As far as I can see this issue is what is trying to solve with the
"committed at revision XYZ" emails

2) Some patches are not been reviewed and being skipped/dropped on the floor.


Both of these issues are big issues with encouraging people to stay in
the community.

Now I don't have the numbers to submit my next statement but I think
the second issue is a bigger issue than the first issue.

Solving the first issue is up to the reviewer side rather than doing
any technical.  We should encourage the reviewers when they don't
recognize the developer who submitted the patch ask when reviewing the
patch if they have write after approval.

Now the second issue is a much bigger issue and I don't know how to
solve it because even if we have some semi automatic way of getting a
patch in a queue; some patches can still be dropped on the floor.
Having a queue of emails threads that need to be looked through is a
good start but then again we will have the same issue as we have with
bug reports of getting reviewers to review the "unconfirmed" email
threads.  I think we can improve on having a queue but this does not
solve the non technical issue of getting reviewers to review patches.

I think a big way of solving this is through a non technical solution
of having a person who just go through patches and mentors the "non
regular" developers.  Maybe reviewers will do the same later on.  I
know that Ian has done this before so have many other folks and the
ones who had been mentored are still coming back and have become
regular developers and in other cases reviewers.  Though there are
some which thought that the mentoring was an attack against them
rather than trying to help them.

Also change just for the name of change is a bad thing and will just
confuse people even more as evidence of this thread now.

Thanks,
Andrew Pinski

Re: Patch pinging

[Ian Lance Taylor]

Paolo Carlini  writes:

> On 06/07/2010 11:16 PM, Ian Lance Taylor wrote:
>> Can you expand? What kinds of process changes would be reasonable to
>> make?
>>   
> Following the terminology "irregular contributor", per Jeff message, I
> would not consider unreasonable for irregular contributions to use more
> extensively and consistently the patch-queue, which we have been using
> for some time. In that way all the patches would be perfectly tracked,
> as far as I can see. The last days I have been traveling, thus sorry if
> I missed parts of the discussion, but I don't understand why the
> patch-queue mechanism is not being seriously considered...

The patch tracker (http://gcc.gnu.org/wiki/GCC_Patch_Tracking) is not
currently operating.

Would anybody like to volunteer to get it working again?

Ian

Re: pic+64bit+sun assembler+unwind-tables => illegal cross section subtraction

[Rainer Orth]

Jay K  writes:

> I haven't tried 4.5.0 yet.

You should, all those bugs should be fixed in 4.5.0, but not all of the
fixes have been backported to the 4.4 branch yet.

> -bash-4.1$ /opt/csw/gcc4/bin/g++ -v
> Using built-in specs.
> Target: i386-pc-solaris2.10
> Configured with: ../gcc-4.3.3/configure --prefix=/opt/csw/gcc4 
> --exec-prefix=/op
> t/csw/gcc4 --with-gnu-as --with-as=/opt/csw/bin/gas --without-gnu-ld 
> --with-ld=/
> usr/ccs/bin/ld --enable-nls --with-included-gettext 
> --with-libiconv-prefix=/opt/
> csw --with-x --with-mpfr=/opt/csw --with-gmp=/opt/csw --enable-java-awt=xlib 
> --e
> nable-libada --enable-libssp --enable-objc-gc --enable-threads=posix 
> --enable-st
> age1-languages=c --enable-languages=ada,c,c++,fortran,java,objc
> Thread model: posix
> gcc version 4.3.3 (GCC)

This version is ancient history, I don't even test it anymore: mainline + 4.4
and 4.5 branches is more than enough.

> /opt/csw/gcc4/bin/g++ 1.cpp -fPIC -S -m64
> "1.s", line 117 : Warning: Illegal subtraction - symbols from 
> different sections: ".LFB2", ".DOT-2"
> "1.s", line 120 : Warning: Illegal subtraction - symbols from 
> different sections: ".LLSDA2", ".DOT-3"
> void F1();
> void F2()
> {
>   try { F1(); } catch(...) {F2(); }
> }
>
>  
>  /usr/ccs/bin/as -xarch=amd64 1.s

There's something wrong here: while the gcc above is configured to use
gas, those warnings are from Sun as.  You cannot expect to assemble
compiler output for one assembler with another one.  There is a common
subset, but syntax or capabilties are different in some cases.

> or similar:
> -bash-4.1$ cat 2.c
> void F1() { }
>  
>
>/opt/csw/gcc4/bin/gcc -fPIC -S -funwind-tables -m64 2.c
>/usr/ccs/bin/as -xarch=amd64 2.s
> Assembler: 2.c
> "2.s", line 38 : Warning: Illegal subtraction - symbols from 
> different sections: ".LFB2", ".DOT-1"

Driver error: don't do this.

> I'm aware of this thread:
> http://gcc.gnu.org/ml/gcc-patches/2006-07/msg00908.html

This has been fixed since

2009-01-29  Rainer Orth  

* config/i386/sol2-10.h [!HAVE_AS_IX86_DIFF_SECT_DELTA]
(ASM_OUTPUT_DWARF_PCREL): Define.

> I think I'll switch to GNU as, or omit -funwind-tables for now.
>   Or see if 4.5.0 fixes it.
> Sparc32, sparc64, x86 work.

Please have a look the relevant sections of Installing GCC to find out
about tools requirements.

> -gstabs+ also generated .stabd that Sun assembler didn't like.

Shouldn't happen anymore since

2010-02-24  Rainer Orth  

* config/i386/sol2.h (NO_DBX_BNSYM_ENSYM): Define.
* config/i386/sol2-gas.h: New file.
* config.gcc (i[34567]86-*-solaris2*): Use it.

> I switched to -gstabs.
> Maybe I messed up something though, as it looks like gcc is aware not to 
> output .stabd to non-gas.
>   More reason to use GNU assembler, understood.

Not necessarily, see above for current recommendations.

> http://gcc.gnu.org/install/specific.html#ix86-x-solaris210
>  could be a bit more precise:
>   >> Recent versions of the Sun assembler in /usr/ccs/bin/as work almost as 
> well, though. 
>
>  
> "almost as well"?
> Maybe that should say more, like, use -g or -gstabs instead of -gstabs+, 
> don't use 64bit+pic+unwind-tables or 64bit+pic+exceptions

No, all those issues are fixed at least in mainline and 4.5.  And the
installation instructions on gcc.gnu.org are from mainline, so might be
newer than the latest released version.

> I switched to Sun assembler because I'm seeing GNU as installed in different 
> places on different machines.
>   Some people don't install /usr/sfw and the install elsewhere.

If you build gcc yourself, either stay with Sun as (as you can) or
install GNU as from recent binutils.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: Patch pinging

[Paolo Carlini]

On 06/07/2010 11:40 PM, Andrew Pinski wrote:
> I think a big way of solving this is through a non technical solution
> of having a person who just go through patches and mentors the "non
> regular" developers.
>   
The only point I want to stress again, or maybe clarify, is that if a
*person* is going to do that, I expect the "entity" to behave like a
person, thus intelligently, thus not sending out standardized requests
about patches which obviously have been committed already, as any
*human* can quickly understand looking at gcc-cvs, svn, whatever. If you
tell me that it would be a rather stressful job, I agree, and that's why
I think we should find a way to automate it, assuming it's a real issue
to somebody.

Paolo.

Re: Patch pinging

[Manuel López-Ibáñez]

On 8 June 2010 00:21, Paolo Carlini  wrote:
> On 06/07/2010 11:40 PM, Andrew Pinski wrote:
>> I think a big way of solving this is through a non technical solution
>> of having a person who just go through patches and mentors the "non
>> regular" developers.
>>
> The only point I want to stress again, or maybe clarify, is that if a
> *person* is going to do that, I expect the "entity" to behave like a
> person, thus intelligently, thus not sending out standardized requests
> about patches which obviously have been committed already, as any
> *human* can quickly understand looking at gcc-cvs, svn, whatever. If you
> tell me that it would be a rather stressful job, I agree, and that's why
> I think we should find a way to automate it, assuming it's a real issue
> to somebody.

http://gcc.gnu.org/ml/gcc/2010-04/msg00667.html
http://gcc.gnu.org/ml/gcc/2010-04/msg00670.html
http://gcc.gnu.org/ml/gcc/2010-04/msg00681.html
http://gcc.gnu.org/ml/gcc/2010-04/msg00637.html
http://gcc.gnu.org/ml/gcc/2010-04/msg00666.html

All those from a single recent thread in the gcc@ list. Not a place
where I would expect to find people that have given up on contributing
to GCC. I think you could obtain a more representative sample if you
asked in llvmdev or cfe-dev.

That said, I don't think pinging patches (or even faster reviews)
would solve the lack of GCC contributors. Potential contributors
actually give up much earlier.

Perhaps not an issue for anyone that is already a GCC developer, and
even less of an issue if they are paid to do so (at least until their
boss or their clients put them to work on some other free compiler or
libc++ library). But perhaps the lack of contributors is an issue for
the GCC project as a whole.

Cheers,

Manuel

Re: Patch pinging

[Manuel López-Ibáñez]

On 7 June 2010 23:23, Ian Lance Taylor  wrote:
> Paolo Carlini  writes:
>
>> This makes sense. Thinking out loud myself, even for irregular
>> contributors, the idea of a ping-man doesn't really sound right, it's a
>> boring and error-prone task. Can anybody think of a way to automate the
>> job? For patches corresponding to Bugzilla entries we already have, more
>> or less, a complete procedure in place, I wonder if we could do
>> something for the other contributions...
>
> I am 100% in favor of automating the job, but there is little point in
> discussing how we can automate the job unless somebody is prepared to
> volunteer to actually do the work.  We do have a volunteer willing to
> be a ping-man.

Perhaps NightStrike can fine-tune his approach. For example, only ping
on behalf of people that are not regular GCC developers (I think it is
pretty obvious after a while who those are).

Still, a patch tracker that:

* Allowed to submit patches via web and checked them for basic stuff
(changelog, formatting, perhaps even building and testing) and
automatically send them to gcc-patches for review with an appropriate
subject line.

* Tracked reviews in gcc-patches and updated the status in the tracker.

* Tracked commits and updated the status accordingly.

would be a superb contribution!

Patchwork is the closest I have found: http://ozlabs.org/~jk/projects/patchwork/
but it lacks categories/components. Others listed in
http://gcc.gnu.org/wiki/GCC_Patch_Tracking are either too complex or
too simple.

Cheers,

Manuel.

Re: Patch pinging

[Paolo Carlini]

On 06/08/2010 02:20 AM, Manuel López-Ibáñez wrote:
> Perhaps NightStrike can fine-tune his approach.
By the way, I wonder how many contributors can even think taking
seriously a message coming from "NightStrike". Not me, for sure...

Paolo.

Re: Patch pinging

[Ben White]

Ian Lance Taylor wrote:


Paolo Carlini  writes:

 


This makes sense. Thinking out loud myself, even for irregular
contributors, the idea of a ping-man doesn't really sound right, it's a
boring and error-prone task. Can anybody think of a way to automate the
job? For patches corresponding to Bugzilla entries we already have, more
or less, a complete procedure in place, I wonder if we could do
something for the other contributions...
   



I am 100% in favor of automating the job, but there is little point in
discussing how we can automate the job unless somebody is prepared to
volunteer to actually do the work.  We do have a volunteer willing to
be a ping-man.

Would anybody care to volunteer to implement something?

Ian

 

Would a modestly modified copy of Bugzilla be workable for that something? 
I.E. Patchzilla?


AllParadox
Ben White

Re: Patch pinging

[Basile Starynkevitch]

On Mon, 2010-06-07 at 15:05 -0600, Jeff Law wrote:
> On 06/07/10 14:31, Ian Lance Taylor wrote:
> > The gcc project currently has a problem: when people who are not
> > regular gcc developers send in a patch, those patches often get
> > dropped.  They get dropped because they do not get reviewed, and they
> > get dropped because after review they do not get committed.  This
> > discourages new developers and it means that the gcc project does not
> > move as fast as it could.
> >
> >
> So perhaps the thing to do is somehow separate patches from regular 
> contributors and irregular contributors.  A relatively easy way to do 
> this would be for a regular contributor to include a keyword in their 
> message to gcc-patches to mark the thread as not needing 3rd party 
> tracking/pings.


I am not sure what does that mean in practice. I am only a write after
approval contributor, so I cannot formally approve any patch (except
perhaps to my MELT branch). However, I definitely can follow some
patches (and I even do have an intern, Jeremie Salvucci, who did all the
legal framework and wants to become a GCC contributor).

It seems that perhaps you are suggesting a status in between reviewers &
W.A.A. contributors.

Cheers
-- 
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: Patch pinging

[Chiheng Xu]

On Tue, Jun 8, 2010 at 9:14 AM, Ben White  wrote:
> Would a modestly modified copy of Bugzilla be workable for that something?
> I.E. Patchzilla?

Think about mercurial or git.  Every one can commit on his/her own
local repository, and "publish" his/her repository.  Every one can
pull other people's changes into his/her own repository, and can
selectively merge interesting/valuable changes. Every patch have it's
own branch. So called "approved patches" will be those patches whose
branches have been merged. Then, you only need to think whether or not
merge the branches the patches reside.

If you use mercurial or git, every change will not be lost, every one
can review and selectively merge any branch on his/her convenience.




-- 
Chiheng Xu
Wuhan,China