On Mon, Nov 29, 2010 at 11:51 PM, Miles Bader wrote:
> Ian Lance Taylor writes:
>> We could decide not to do anything about this, but I don't think it's a
>> non-issue. With -std=gnu++98 g++ accepts this invalid code. That is,
>> it is a g++ extension, and the code is properly rejected with
>>
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
wrote:
> If you are doing that, why don't you write a simpler code by
> just defining (e.g. initializing) the data member outside the class?
'cause I want the compiler to be able to use (inline) the underlying values.
-Miles
--
Cat is power. C
On Tue, Nov 30, 2010 at 2:17 AM, Miles Bader wrote:
> On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
> wrote:
>> If you are doing that, why don't you write a simpler code by
>> just defining (e.g. initializing) the data member outside the class?
>
> 'cause I want the compiler to be able to use
Gabriel Dos Reis writes:
>>> If you are doing that, why don't you write a simpler code by
>>> just defining (e.g. initializing) the data member outside the class?
>>
>> 'cause I want the compiler to be able to use (inline) the underlying values.
>
> then write even simple code: dispense with the c
On Tue, Nov 30, 2010 at 2:33 AM, Miles Bader wrote:
> Gabriel Dos Reis writes:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
>>>
>>> 'cause I want the compiler to be able to use (inline) the underlying v
Gabriel Dos Reis writes:
>> I.e., I can choose between various types of ugliness -- wrong namespace,
>> funny syntax, or (currently) gcc-dependence. I used to choose gcc-
>> dependence, but then switched to funny syntax. In the future when c++0x
>> support is more widespread, of course, I won't
On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader wrote:
> On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
> wrote:
>> If you are doing that, why don't you write a simpler code by
>> just defining (e.g. initializing) the data member outside the class?
>
> 'cause I want the compiler to be able to use
On Tue, 30 Nov 2010, Richard Guenther wrote:
On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader wrote:
On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
wrote:
If you are doing that, why don't you write a simpler code by
just defining (e.g. initializing) the data member outside the class?
'cause
Richard Guenther writes:
>>> If you are doing that, why don't you write a simpler code by
>>> just defining (e.g. initializing) the data member outside the class?
>>
>> 'cause I want the compiler to be able to use (inline) the underlying values.
>
> I think it'll do that with initializing the memb
Hi,
I am working on how to improve "restrict". I noticed
that my changes lead to failure of pr38212. After looking
at its code, I think the test may not be valid according
to c99 standard.
C99 standard 6.7.3.1:
EXAMPLE 4 The rule limiting assignments between restricted pointers does not
distin
On Tue, Nov 30, 2010 at 2:07 PM, Bingfeng Mei wrote:
> Hi,
> I am working on how to improve "restrict". I noticed
> that my changes lead to failure of pr38212. After looking
> at its code, I think the test may not be valid according
> to c99 standard.
>
> C99 standard 6.7.3.1:
>
> EXAMPLE 4 The ru
On 2010-11-29, 22:26:31 -0800, Andrew Pinski wrote:
>
> Except it is documented as a Deprecated feature already so it is
> different from a documented extension. I would say we should just
> drop it as it is documented already as deprecated.
Are you going to drop the feature from g++98?
It is
> -Original Message-
> From: Richard Guenther [mailto:richard.guent...@gmail.com]
> Sent: 30 November 2010 13:53
> To: Bingfeng Mei
> Cc: gcc@gcc.gnu.org
> Subject: Re: Revisit of pr38212 regarding restrict definition
>
> On Tue, Nov 30, 2010 at 2:07 PM, Bingfeng Mei wrote:
> > Hi,
> >
On Tue, Nov 30, 2010 at 3:29 PM, Bingfeng Mei wrote:
>
>
>> -Original Message-
>> From: Richard Guenther [mailto:richard.guent...@gmail.com]
>> Sent: 30 November 2010 13:53
>> To: Bingfeng Mei
>> Cc: gcc@gcc.gnu.org
>> Subject: Re: Revisit of pr38212 regarding restrict definition
>>
>> On
gcc 4.4.5, powerpc32 does not fail
const char wd[6] = "Wednes";
even though wd only has room for 6 chars. Is this intended?
Jocke
On Tue, Nov 30, 2010 at 5:39 AM, Richard Guenther
wrote:
> On Tue, Nov 30, 2010 at 9:17 AM, Miles Bader wrote:
>> On Tue, Nov 30, 2010 at 5:13 PM, Gabriel Dos Reis
>> wrote:
>>> If you are doing that, why don't you write a simpler code by
>>> just defining (e.g. initializing) the data member out
CALL FOR PAPERS
===
Ninth Workshop on Explicitly Parallel Instruction
Computing Architectures and Compiler Technology (EPIC-9)
April 2 or 3 (TBD), 2011
Chamonix, France
In conjunction with the IEEE/ACM International Symposium
on Code Generation and Optimization (CGO)
Researchers fr
Hi Joakim,
On Tue, Nov 30, 2010 at 03:40:12PM +0100, Joakim Tjernlund wrote:
> gcc 4.4.5, powerpc32 does not fail
> const char wd[6] = "Wednes";
> even though wd only has room for 6 chars. Is this intended?
Which language are you using? ;-)
In C++, it's forbidden (there has to be enough space for
On Tue, Nov 30, 2010 at 11:40 PM, Gabriel Dos Reis
wrote:
> I agree. I think we have a case here where people will
> say anything to justify a (mis)feature that leads to brittle
> codes
Why does it "lead to brittle codes"?
> If people are worried about multiple translation units, they
> will st
On Tue, Nov 30, 2010 at 9:07 AM, Miles Bader wrote:
>> If people are worried about multiple translation units, they
>> will still have to provide a definition outside the class -- most
>> likely
>
> Why?
Because its address may be silently taken (through
binding to references), therefore a defin
Andrew Pinski writes:
> On Mon, Nov 29, 2010 at 4:20 PM, Ian Lance Taylor wrote:
>> We could decide not to do anything about this, but I don't think it's a
>> non-issue. With -std=gnu++98 g++ accepts this invalid code. That is,
>> it is a g++ extension, and the code is properly rejected with
>
Hello,
I'm not able to build GCC (4.4.5 and 4.5.1 from the official releases) on AIX
(config.guess: powerpc-ibm-aix6.1.0.0). They both fail exactly the same way:
build/genattrtab ../../gcc/config/rs6000/rs6000.md \
insn-conditions.md > tmp-attrtab.c
out of memory allocating 16 bytes after a to
The problem was caused by ulimits, so please ignore my report.
I feel sorry for generating spurious input -- the platform is totally insane.
Best regards
Piotr Wyderski
Why is not
const char cstr[] = "mystr";
const int myint = 3;
added to a read only section?
Especially since
const int myarr[]={1,2,3};
is placed in .rodata.
hmm, -G 0 does place these in .rodata but why do I have to specify that?
This is a follow up / rediff to my previous patch at
http://gcc.gnu.org/ml/fortran/2010-11/msg00339.html, incorporating the
comments by Ralf and Matthias.
Changes:
- Parts of the patch have been committed separately
- Removed licence text from .texi file following the suggestion of
Matthias -
This is related to http://gcc.gnu.org/ml/gcc/2010-11/msg00623.html
I write about it again because the following seems too bad:
$ cat test1.cc
struct X {
X()=default;
X(X&&)=default;
X(X const&)=delete;
//some very large or non-copyable content
};
X test() {
X const x={};
{
//a l
Tobias Burnus writes:
> @@ -186,5 +194,20 @@
>multilib_arg=
> fi
>
> +
> +# We would like our source tree to be readonly. However when releases or
> +# pre-releases are generated, the flex/bison generated files as well as the
> +# various formats of manuals need to be included along with t
On 30 November 2010 20:33, Roman Kononov wrote:
> This is related to http://gcc.gnu.org/ml/gcc/2010-11/msg00623.html
>
> I write about it again because the following seems too bad:
>
> $ cat test1.cc
> struct X {
> X()=default;
> X(X&&)=default;
> X(X const&)=delete;
> //some very large or non-
On 30 November 2010 20:40, Jonathan Wakely wrote:
> On 30 November 2010 20:33, Roman Kononov wrote:
>> This is related to http://gcc.gnu.org/ml/gcc/2010-11/msg00623.html
>>
>> I write about it again because the following seems too bad:
>>
>> $ cat test1.cc
>> struct X {
>> X()=default;
>> X(X&&)=
2010-11-30 20:40 CST, Jonathan Wakely said:
>On 30 November 2010 20:33, Roman Kononov wrote:
>> $ cat test1.cc
>> struct X {
>> X()=default;
>> X(X&&)=default;
>> X(X const&)=delete;
>> //some very large or non-copyable content
>> };
>>
>> X test() {
>> X const x={};
>> {
>> //a lot of co
2010-11-30 20:46 CST, Jonathan Wakely said:
>On 30 November 2010 20:40, Jonathan Wakely wrote:
>>> $ cat test1.cc
>>> struct X {
>>> X()=default;
>>> X(X&&)=default;
>>> X(X const&)=delete;
>>> //some very large or non-copyable content
>>> };
>>>
>>> X test() {
>>> X const x={};
>>> {
>>>
On Tue, Nov 30, 2010 at 12:53 PM, Roman Kononov wrote:
> 2010-11-30 20:40 CST, Jonathan Wakely said:
>>However, that doesn't change the fact you're trying to move from a
>>const object, which is obviously wrong.
>
> Not really, because the 2 const objects are about to be destroyed.
The fact that
On Tue, 30 Nov 2010, Tobias Burnus wrote:
> This is a follow up / rediff to my previous patch at
> http://gcc.gnu.org/ml/fortran/2010-11/msg00339.html, incorporating the
> comments by Ralf and Matthias.
>
> Changes:
> - Parts of the patch have been committed separately
> - Removed licence text fr
On Tue, 30 Nov 2010, Tobias Burnus wrote:
> +Bugs in the GCC Quad-Precision Math Library implementation should be
> +reported via @uref{http://gcc.gnu.org/bugzilla/, bugzilla}.
Do not hardcode bug reporting URLs like this. You should allow them to
vary with --with-bugurl (see what the main GCC
On Tue, Nov 30, 2010 at 2:53 PM, Roman Kononov wrote:
> 2010-11-30 20:40 CST, Jonathan Wakely said:
>>On 30 November 2010 20:33, Roman Kononov wrote:
>>> $ cat test1.cc
>>> struct X {
>>> X()=default;
>>> X(X&&)=default;
>>> X(X const&)=delete;
>>> //some very large or non-copyable content
>>
2010-11-30 13:03 CST, James Dennett said:
>
>If you want to be able to change an object during its lifetime, don't
>make it const.
I exactly want to be unable to change an object during its lifetime
except when it is moved-and-destroyed.
Thanks
On Tue, Nov 30, 2010 at 3:02 PM, Roman Kononov wrote:
>>2) define a copy constructor, explicitly-defaulted if you wish.
>
> What if the copy constructor is too expensive and I have to use move
> constructor?
the discussion would be less confused if you identify clearly the
language semantics (as
Mozilla seems to receive a report of an exploitable operator new[]
overflow every couple of months now. Obviously, this is not good.
What is necessary so that GCC can fix this code generation issue?
I've created a patch, together with a test case, but it has not been
approved, nor have I been tol
On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov wrote:
> 2010-11-30 13:03 CST, James Dennett said:
>>
>>If you want to be able to change an object during its lifetime, don't
>>make it const.
>
> I exactly want to be unable to change an object during its lifetime
> except when it is moved-and-destr
2010-11-30 15:13 CST, Gabriel Dos Reis
said:
>On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov wrote:
>> I exactly want to be unable to change an object during its lifetime
>> except when it is moved-and-destroyed.
>
>isn't that a question for C++ forums?
I hoped you knew the answer. :)
On 30 November 2010 21:18, Roman Kononov wrote:
> 2010-11-30 15:13 CST, Gabriel Dos Reis
> said:
>>On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov wrote:
>>> I exactly want to be unable to change an object during its lifetime
>>> except when it is moved-and-destroyed.
>>
>>isn't that a question f
2010-11-30 21:20 CST, Jonathan Wakely said:
>We do. The point is your question is off-topic on this list, because
>you are complaining about the C++0x language, which as far as we know
>GCC implements correctly. If you don't like the language, complain
>somewhere else.
>
Then please tell me whic
On Tue, 30 Nov 2010, Florian Weimer wrote:
> Mozilla seems to receive a report of an exploitable operator new[]
> overflow every couple of months now. Obviously, this is not good.
>
> What is necessary so that GCC can fix this code generation issue?
> I've created a patch, together with a test c
On Tue, Nov 30, 2010 at 3:34 PM, Roman Kononov wrote:
> 2010-11-30 21:20 CST, Jonathan Wakely said:
>>We do. The point is your question is off-topic on this list, because
>>you are complaining about the C++0x language, which as far as we know
>>GCC implements correctly. If you don't like the lan
On Tue, Nov 30, 2010 at 3:38 PM, Joseph S. Myers
wrote:
> On Tue, 30 Nov 2010, Florian Weimer wrote:
>
>> Mozilla seems to receive a report of an exploitable operator new[]
>> overflow every couple of months now. Obviously, this is not good.
>>
>> What is necessary so that GCC can fix this code g
On 30 November 2010 21:45, Gabriel Dos Reis wrote:
> On Tue, Nov 30, 2010 at 3:34 PM, Roman Kononov wrote:
>> 2010-11-30 21:20 CST, Jonathan Wakely said:
>>>We do. The point is your question is off-topic on this list, because
>>>you are complaining about the C++0x language, which as far as we kno
Roman Kononov writes:
> 2010-11-30 15:13 CST, Gabriel Dos Reis
> said:
>>On Tue, Nov 30, 2010 at 3:11 PM, Roman Kononov wrote:
>>> I exactly want to be unable to change an object during its lifetime
>>> except when it is moved-and-destroyed.
>>
>>isn't that a question for C++ forums?
>
> I hope
The two programs below differ by the location of =default applied to
the move constructor. In the first program, it is defaulted inside
the class during declaration. In the second program, it is defaulted
outside the class in the definition.
The first program does not compile. The second does comp
Snapshot gcc-4.4-20101130 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20101130/
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
On Tue, Nov 30, 2010 at 01:49:23PM -0800, Gabriel Dos Reis wrote:
> The existing GCC behaviour is a bit more perverse than the
> C malloc() case as in
>
>new T[n]
>
> there is no multiplication that could be credited to careless programmer.
> The multiplication is introduced by GCC.
...
On 30 November 2010 22:51, Roman Kononov wrote:
> The two programs below differ by the location of =default applied to
> the move constructor. In the first program, it is defaulted inside
> the class during declaration. In the second program, it is defaulted
> outside the class in the definition.
>
Hi
Minor build bug: The cpp sanity check fails because it is looking for cpp
in /lib instead of /usr/bin
Summary of test results:
=== gcc Summary ===
# of expected passes72577
# of unexpected failures22
# of unexpected successes 32
# of expected fai
Quoting Richard Guenther :
Btw, I think these partial conversions are not appropriate for stage3
and if accepted for stage1 you should commit yourself to do a
transition that at least allows converting targets (thus, I don't like
your incremental patches at all).
I don't understand what makes
53 matches
Mail list logo
