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 wi
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
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,o
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
Hi all,
Just a reminder, as discussed on thread starting at
http://gcc.gnu.org/ml/gcc/2010-06/msg00092.html
--
Laurynas
> 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 th
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
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
> >>
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
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
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
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 w
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 succ
> 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.h
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.
Than
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 Novemb
> 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 m
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 f
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
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 b
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
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.
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,
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 commit
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
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
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 consiste
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 alread
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
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
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/config
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 go
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 aga
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? F
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.
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 Bug
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, a
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'
38 matches
Mail list logo
