Re: new requirement of "constexpr" for static const float data members is too restrictive
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 >> -pedantic-errors. We could decide to carry the extension forward to >> -std=gnu++0x. Or we could decide to carry the extension forward to >> -std=gnu++0x when -fpermissive is used. Or we could decide to just drop >> the extension. >> >> The main problem with the last option is that it complicates the >> migration of existing gnu++98 programs to gnu++0x. It becomes necessary >> to add constexpr to use gnu++0x. Unfortunately, gnu++98 rejects >> constexpr. So there is no simple way to modify this program to be both >> valid gnu++98 and valid gnu++0x. That makes the transition more >> difficult. >> >> It seems to me that it would be better for our users to accept this code >> in gnu++0x mode with -fpermissive. > > I agree. > > I used to use this feature a lot, and indeed that was the primary reason > I _didn't_ use -pedantic-errors. > > It's nice that C++0x has an official way to support this feature (it > seems very silly that C++98 didn't), but there are surely many projects > that don't want to commit to C++0x just yet. > > [Recently I went through and changed all my uses of "static const float" > fields to use inline static methods instead, which is at least portable, > but yuck, how ugly is that...] 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? > > BTW, if it's decided that `-fpermissive' should be necessary, I think > the error message should note that ... > > -Miles > > -- > Once, adj. Enough. > >
Re: new requirement of "constexpr" for static const float data members is too restrictive
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. Cat is peace.
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 (inline) the underlying values. then write even simple code: dispense with the class stuff and use bona fide `const float' at namespace scope. It works with all compilers and all versions of GCC/g++.
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 class stuff and use > bona fide `const float' at namespace scope. It works with all compilers > and all versions of GCC/g++. Right, but I want it in the class namespace. 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 have to make such an annoying choice any more... -Miles -- XML is like violence. If it doesn't solve your problem, you're not using enough of it.
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 values. >> >> then write even simple code: dispense with the class stuff and use >> bona fide `const float' at namespace scope. It works with all compilers >> and all versions of GCC/g++. > > Right, but I want it in the class namespace. > > 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 have to make such an > annoying choice any more... hmm, that sounds like an awful lot of effort put into something that looked to me as simple code to write using standard functionalities. Though I have to confess I do not understand why the class must be right and the namespace must be wrong. (Maybe I have not seen the real code, I don't know.) Good luck.
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 have to make such an >> annoying choice any more... > > hmm, that sounds like an awful lot of effort put into something that looked > to me as simple code to write using standard functionalities. Though > I have to confess I do not understand why the class must be right and the > namespace must be wrong. (Maybe I have not seen the real code, I > don't know.) Exactly. Which is "right" or "acceptable" depends on the details and programming style, and is subjective to some degree. Anyway, what's important is whether existing code _may_ have chosen to use this gcc feature, and may not consider pre-c++0x alternatives palatable. The point was made that this feature was already deprecated -- but I think given that a more-palatable option will be available in c++0x[*], it would be nice to give users a certain amount of overlap during which both the old (deprecated) and new features are both supported. That would suggest keeping this feature for a while still... [If there were no such c++0x feature coming, I guess it would matter less when the deprecation actually changed to removal.] [*] "more palatable" because only definitions need be updated, not uses, all attributes of the existing gcc-only code are maintained (inheritance by subclasses, etc), and there's no need for a change in programming style. -Miles -- Learning, n. The kind of ignorance distinguishing the studious.
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 (inline) the underlying values.
I think it'll do that with initializing the member outside of the class as well.
struct X { static float const v; };
const float X::v = 1;
int main()
{
return (int)X::v;
}
at least works for me (even when not optimizing - huh).
Richard.
> -Miles
>
> --
> Cat is power. Cat is peace.
>
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 I want the compiler to be able to use (inline) the underlying values.
I think it'll do that with initializing the member outside of the class as well.
struct X { static float const v; };
const float X::v = 1;
int main()
{
return (int)X::v;
}
at least works for me (even when not optimizing - huh).
I don't know the OP's code, but X would typically be in a header file,
included in several translation units. And there is no static or inline
you can write in front of "const float X::v = 1;" to help with that.
(with LTO the optimizations might still happen with X::v defined
separately)
--
Marc Glisse
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 member outside of the class as
> well.
>
> struct X { static float const v; };
> const float X::v = 1;
> int main()
> {
> return (int)X::v;
> }
That'll work if you only have one file ... but the only way that
definition of X::v would be visible to many users in a typical prog is
if it were in a header file -- and then you'll get a mulitple-definition
error for X::v when linking
-miles
--
Justice, n. A commodity which in a more or less adulterated condition the
State sells to the citizen as a reward for his allegiance, taxes and personal
service.
Revisit of pr38212 regarding restrict definition
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
distinguish between a
function call and an equivalent nested block. With one exception, only
''outer-to-inner'' assignments
between restricted pointers declared in nested blocks have defined behavior.
{
int * restrict p1;
int * restrict q1;
p1 = q1; // undefined behavior
{
int * restrict p2 = p1; // valid
int * restrict q2 = q1; // valid
p1 = q2; // undefined behavior
p2 = q2; // undefined behavior
}
}
pr38212.c
int __attribute__((noinline))
foo (int *__restrict p, int i)
{
int *__restrict q;
int *__restrict r;
int v, w;
q = p + 1;
r = q - i;
v = *r;
*p = 1;
w = *r;
return v + w;
}
extern void abort (void);
int main()
{
int i = 0;
if (foo (&i, 1) != 1)
abort ();
return 0;
}
Isn't that "r = q - i" undefined? "q = p + 1" may be also undefined,
depending whether we regard parameter p from outer or inner block.
Cheers,
Bingfeng
Re: Revisit of pr38212 regarding restrict definition
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 rule limiting assignments between restricted pointers does not
> distinguish between a
> function call and an equivalent nested block. With one exception, only
> ''outer-to-inner'' assignments
> between restricted pointers declared in nested blocks have defined behavior.
> {
> int * restrict p1;
> int * restrict q1;
> p1 = q1; // undefined behavior
> {
> int * restrict p2 = p1; // valid
> int * restrict q2 = q1; // valid
> p1 = q2; // undefined behavior
> p2 = q2; // undefined behavior
> }
> }
>
> pr38212.c
> int __attribute__((noinline))
> foo (int *__restrict p, int i)
> {
> int *__restrict q;
> int *__restrict r;
> int v, w;
> q = p + 1;
> r = q - i;
> v = *r;
> *p = 1;
> w = *r;
> return v + w;
> }
> extern void abort (void);
> int main()
> {
> int i = 0;
> if (foo (&i, 1) != 1)
> abort ();
> return 0;
> }
>
> Isn't that "r = q - i" undefined?
Why? r is based on q which is based on p. If you write the source
as r = p + 1 - i; it'll have the same effect (and then it's clearly based on p).
"q = p + 1" may be also undefined,
> depending whether we regard parameter p from outer or inner block.
you can avoid all the named temporaries by substituting the
pointer arithmetic into the dereferences.
Of course the middle-end may not do optimizations based on what
C thinks are "blocks".
Richard.
> Cheers,
> Bingfeng
>
>
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 good to document that a feature is deprecated. It is even better to give a warning at compile time before it's gone. Roman
RE: Revisit of pr38212 regarding restrict definition
> -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,
> > 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 distinguish between a
> > function call and an equivalent nested block. With one exception,
> only ''outer-to-inner'' assignments
> > between restricted pointers declared in nested blocks have defined
> behavior.
> > {
> > int * restrict p1;
> > int * restrict q1;
> > p1 = q1; // undefined behavior
> > {
> > int * restrict p2 = p1; // valid
> > int * restrict q2 = q1; // valid
> > p1 = q2; // undefined behavior
> > p2 = q2; // undefined behavior
> > }
> > }
> >
> > pr38212.c
> > int __attribute__((noinline))
> > foo (int *__restrict p, int i)
> > {
> > int *__restrict q;
> > int *__restrict r;
> > int v, w;
> > q = p + 1;
> > r = q - i;
> > v = *r;
> > *p = 1;
> > w = *r;
> > return v + w;
> > }
> > extern void abort (void);
> > int main()
> > {
> > int i = 0;
> > if (foo (&i, 1) != 1)
> > abort ();
> > return 0;
> > }
> >
> > Isn't that "r = q - i" undefined?
>
> Why? r is based on q which is based on p. If you write the source
> as r = p + 1 - i; it'll have the same effect (and then it's clearly
> based on p).
>
But standard just plainly says it is undefined when you assign one
restrict pointer to another restrict pointer in the same block level.
"If P is assigned the value of a pointer expression E that is based
on another restricted pointer object P2, associated with block B2,
then either the execution of B2 shall begin before the execution of B,
or the execution of B2 shall end prior to the assignment. If these
requirements are not met, then the behavior is undefined."
Whether r is based on p is not important, IMO. Suppose p is not
restrict qualified. If we write
int *__restrict r = p + 1 - i;
Programmer just assumes that access through r won't be aliased
with any other pointer, including p. If it turns out that i = 1
and r is indeed aliased with p. It is not compiler's fault to
miscompile code, but programmer's fault to write wrong code.
> "q = p + 1" may be also undefined,
> > depending whether we regard parameter p from outer or inner block.
>
> you can avoid all the named temporaries by substituting the
> pointer arithmetic into the dereferences.
>
If we remove all the restricted temporary pointers, there is nothing
undefined here and is a valid test for sure.
int __attribute__((noinline))
foo (int *__restrict p, int i)
{
int v, w;
v = *(p + 1 - i);
*p = 1;
w = *(p + 1 - i);
return v + w;
}
Bingfeng
> Of course the middle-end may not do optimizations based on what
> C thinks are "blocks".
>
> Richard.
>
> > Cheers,
> > Bingfeng
> >
> >
Re: Revisit of pr38212 regarding restrict definition
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 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 rule limiting assignments between restricted pointers
>> does not distinguish between a
>> > function call and an equivalent nested block. With one exception,
>> only ''outer-to-inner'' assignments
>> > between restricted pointers declared in nested blocks have defined
>> behavior.
>> > {
>> > int * restrict p1;
>> > int * restrict q1;
>> > p1 = q1; // undefined behavior
>> > {
>> > int * restrict p2 = p1; // valid
>> > int * restrict q2 = q1; // valid
>> > p1 = q2; // undefined behavior
>> > p2 = q2; // undefined behavior
>> > }
>> > }
>> >
>> > pr38212.c
>> > int __attribute__((noinline))
>> > foo (int *__restrict p, int i)
>> > {
>> > int *__restrict q;
>> > int *__restrict r;
>> > int v, w;
>> > q = p + 1;
>> > r = q - i;
>> > v = *r;
>> > *p = 1;
>> > w = *r;
>> > return v + w;
>> > }
>> > extern void abort (void);
>> > int main()
>> > {
>> > int i = 0;
>> > if (foo (&i, 1) != 1)
>> > abort ();
>> > return 0;
>> > }
>> >
>> > Isn't that "r = q - i" undefined?
>>
>> Why? r is based on q which is based on p. If you write the source
>> as r = p + 1 - i; it'll have the same effect (and then it's clearly
>> based on p).
>>
>
> But standard just plainly says it is undefined when you assign one
> restrict pointer to another restrict pointer in the same block level.
>
> "If P is assigned the value of a pointer expression E that is based
> on another restricted pointer object P2, associated with block B2,
> then either the execution of B2 shall begin before the execution of B,
> or the execution of B2 shall end prior to the assignment. If these
> requirements are not met, then the behavior is undefined."
>
> Whether r is based on p is not important, IMO. Suppose p is not
> restrict qualified. If we write
>
> int *__restrict r = p + 1 - i;
>
> Programmer just assumes that access through r won't be aliased
> with any other pointer, including p. If it turns out that i = 1
> and r is indeed aliased with p. It is not compiler's fault to
> miscompile code, but programmer's fault to write wrong code.
>
>> "q = p + 1" may be also undefined,
>> > depending whether we regard parameter p from outer or inner block.
>>
>> you can avoid all the named temporaries by substituting the
>> pointer arithmetic into the dereferences.
>>
>
> If we remove all the restricted temporary pointers, there is nothing
> undefined here and is a valid test for sure.
> int __attribute__((noinline))
> foo (int *__restrict p, int i)
> {
> int v, w;
> v = *(p + 1 - i);
> *p = 1;
> w = *(p + 1 - i);
> return v + w;
> }
The middle-end will see exactly the same (temporaries with restrict
qualification being assigned a pointer that is restrict qualified).
The testcase basically models what the middle-end has to expect
and deal with, it doesn't try to be literally compliant with the C
standard.
Richard.
>
> Bingfeng
>
>> Of course the middle-end may not do optimizations based on what
>> C thinks are "blocks".
>>
>> Richard.
>>
>> > Cheers,
>> > Bingfeng
>> >
>> >
>
>
>
const char wd[6] = "Wednes", is that legal?
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
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 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 member outside of the class as
> well.
>
> struct X { static float const v; };
> const float X::v = 1;
> int main()
> {
> return (int)X::v;
> }
>
> at least works for me (even when not optimizing - huh).
I agree. I think we have a case here where people will
say anything to justify a (mis)feature that leads to brittle
codes, and even more so a deprecated extension.
If people are worried about multiple translation units, they
will still have to provide a definition outside the class -- most
likely. Which makes me really doubtful that the in-class initialization
provides a better alternative than the standard namespace scope
constant idiom.
Anyway, all this started as a confusion, and as far as I'm concerned
it is a non-issue. It is up to you guys to decide what you do with it --
I don't think it really is a service to keep it.
-- Gaby
EPIC9 Call for Papers (Chamonix, France, April 2nd or 3rd, 2011)
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 from both academia and industry are invited to share their latest research findings in the area of EPIC architectures and compiler technology. The EPIC style of architecture was developed to enable new levels of instruction-level parallelism not achieved with traditional architectures. By allowing the compiler to express program parallelism and other relevant information directly to the processor, EPIC architectures can overcome hardware complexity issues that limit performance in traditional microprocessors. The major challenge in realizing the full potential of EPIC architectures is developing compiler and runtime optimization technologies that effectively deploy explicitly defined hardware mechanisms, and deliver performance for both commercial and scientific applications. This workshop will focus on promising research concepts that enable the EPIC architecture model. TOPICS OF INTEREST Topics of interest include, but are not limited to: Compiler Optimizations: - Instruction scheduling, software pipelining, predication, control and data speculation, register allocation - Thread-level parallelization - Versioning approaches to dynamically adapt to runtime behavior - Techniques to mitigate in-order memory stalls, like prefetching, helper threads, and load clustering - Compiler-directed memory-hierarchy and cache-coherency management - Methods of program analysis and verification that are related to EPIC - Higher-level optimizations that are related to EPIC - Validation of compiler optimizations Binary Translation: - Methods of binary translation applicable to EPIC architectures - Hardware support of binary translation Feedback-Directed Optimizations: - Especially performance monitoring unit (PMU) driven optimizations - Dynamic optimizations Microarchitecture: - Novel architectures and microarchitectures - In-order versus out-of-order designs, hybrid approaches - Multi-threaded and multi-core EPIC architectures - Power and energy aware computing techniques for EPIC machines Advanced Uses of EPIC Architectures: - Virtualization and Secure Computing - Special purpose applications Performance Analysis of EPIC Architectures: - Commercial and scientific workload studies for EPIC models - Effects of architectural features on workload behavior - Experimental evaluation of Itanium microprocessors - Performance comparisons with other architectures - Tools for analysis, instrumentation, and architecture experiments CHAIR Andrey Bokhanko, Intel andrey.s.bokha...@intel.com IMPORTANT DATES SUBMISSION DEADLINE: Friday, February 4, 2011 Acceptances Mailed: February 18, 2011 Final Version Due: March 11, 2011 Workshop Date: April 2 or 3 (TBD), 2011 (half day workshop) SUBMISSION GUIDELINES Full papers of up to 22 pages or extended abstracts of up to 8 pages can be submitted (8.5"x11" double-spaced pages, using 11pt or larger font). Clearly describe the nature of the work, its significance and the current status of the research. Include a title page containing the title of the paper, list of authors and their affiliations, addresses, telephone and fax numbers, email addresses and the name of the corresponding author. papers will be published on EPIC-9 web-site (the copyright will remain with the author). http://www.cgo.org/cgo2011/epic9/
Re: const char wd[6] = "Wednes", is that legal?
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 the implied trailing "\0". In C whoever, it's legal -- you obtain an array of 6 characters, without a trailing "\0" ... Axel
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 still have to provide a definition outside the class -- most > likely Why? Certainly as in my experience, that's not true. In C++ "static const" is a way of defining constants, and the fact that integral class "constants" were allowed whereas floating-point class "constants" were not was just a wart. It's nice that c++0x has fixed this wart, but there was nothing wrong with gcc's different method of doing so, beyond its lack of portability. -Miles -- Cat is power. Cat is peace.
Re: new requirement of "constexpr" for static const float data members is too restrictive
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 definition is needed. > Certainly as in my experience, that's not true. That is extra-ordinary, not the norm. > > In C++ "static const" is a way of defining constants, and the fact > that integral class "constants" were allowed whereas floating-point > class "constants" were not was just a wart. This misfeature of in-class initialization is a 15-year old debate. I doubt, it will be resolved on GCC development list.
Re: Fw: new requirement of "constexpr" for static const float data members is too restrictive
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 >> -pedantic-errors. We could decide to carry the extension forward to >> -std=gnu++0x. Or we could decide to carry the extension forward to >> -std=gnu++0x when -fpermissive is used. Or we could decide to just drop >> the extension. >> >> The main problem with the last option is that it complicates the >> migration of existing gnu++98 programs to gnu++0x. It becomes necessary >> to add constexpr to use gnu++0x. Unfortunately, gnu++98 rejects >> constexpr. So there is no simple way to modify this program to be both >> valid gnu++98 and valid gnu++0x. That makes the transition more >> difficult. >> >> It seems to me that it would be better for our users to accept this code >> in gnu++0x mode with -fpermissive. > > 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. I don't think it is very helpful for us to drop a deprecated feature which we don't even warn about. If we take this path, can somebody write a patch for 4.6 to add a -Wdeprecated warning for this? Ian
Build problems on AIX
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 total of 4161654796 bytes make[3]: *** [s-attrtab] Error 1 make[3]: Leaving directory `/mnt/local1/piotrw/projects/build/gcc-4.4.5/objdir/gcc' The build compiler is GCC 4.2.3 in 32-bit mode. The source trees have been configured as: ../configure --prefix=/opt/tools32/gcc-4.4.5 --with-gmp=/opt/tools32 --with-mpfr=/opt/tools32 --with-mpc=/opt/tools32 --with-as=/opt/tools32/bin/as --with-ld=/opt/tools32/bin/ --enable-languages=c,c++ --enable-threads --enable-version-specific-runtime-libs I use the newest GMP/MPFR/MPC libraries. What can be the problem and how do I fix that? Best regards, Piotr Wyderski
Re: Build problems on AIX
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
ppc: const data not in RO section
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?
[Patch,quadmath] PR 46543: Add first documentation
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 - which is in line with http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Documentation.html - Added LICENCES which lists the other licences which apply to the code (as suggested by Matthias, trying to follow GLIBC) - Minor changes: uses AC_ARG_ENABLE, tailing white space removed, uses @need 800 (all suggested by Ralf); add one-line description to the math functions Build on x86-64-linux. OK for the trunk? Tobias 2010-11-30 Tobias Burnus PR fortran/46543 * LICENCES: Add. * configure.ac: Add texinfo checks. * Makefile.am: Handle .texi documentation. * libquadmath.texi: New. * configure: Regenerated. * Makefile.in: Regenerated. Index: configure.ac === --- configure.ac (Revision 167307) +++ configure.ac (Arbeitskopie) @@ -41,6 +41,14 @@ GCC_NO_EXECUTABLES +# See if makeinfo has been installed and is modern enough +# that we can use it. +ACX_CHECK_PROG_VER([MAKEINFO], [makeinfo], [--version], + [GNU texinfo.* \([0-9][0-9.]*\)], + [4.[4-9]*|4.[1-9][0-9]*|[5-9]*|[1-9][0-9]*]) +AM_CONDITIONAL(BUILD_INFO, test $gcc_cv_prog_makeinfo_modern = "yes") + + # Configure libtool AM_PROG_LIBTOOL AC_SUBST(enable_shared) @@ -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 the rest of the +# sources. Therefore we have --enable-generated-files-in-srcdir to do +# just that. +AC_MSG_CHECKING([for --enable-generated-files-in-srcdir]) +AC_ARG_ENABLE(generated-files-in-srcdir, no, , + [put copies of generated files in source dir intended for creating source +tarballs for users without texinfo bison or flex.], + permit yes|no) +AC_MSG_RESULT($enable_generated_files_in_srcdir) +AM_CONDITIONAL(GENINSRC, test "$enable_generated_files_in_srcdir" = yes) + + AC_CONFIG_FILES(Makefile) AC_OUTPUT Index: Makefile.am === --- Makefile.am (Revision 167307) +++ Makefile.am (Arbeitskopie) @@ -105,4 +105,46 @@ MAKEOVERRIDES= +# AM_CONDITIONAL on configure option --generated-files-in-srcdir +if GENINSRC +STAMP_GENINSRC = stamp-geninsrc +else +STAMP_GENINSRC = endif + +# AM_CONDITIONAL on configure check ACX_CHECK_PROG_VER([MAKEINFO]) +if BUILD_INFO +STAMP_BUILD_INFO = stamp-build-info +else +STAMP_BUILD_INFO = +endif + + +all-local: $(STAMP_GENINSRC) + +stamp-geninsrc: libquadmath.info + cp -p $(top_builddir)/libquadmath.info $(srcdir)/libquadmath.info + @touch $@ + +libquadmath.info: $(STAMP_BUILD_INFO) + +stamp-build-info: libquadmath.texi + $(MAKEINFO) $(AM_MAKEINFOFLAGS) $(MAKEINFOFLAGS) -I $(srcdir) -o libquadmath.info $(srcdir)/libquadmath.texi + @touch $@ + +CLEANFILES = $(STAMP_GENINSRC) $(STAMP_BUILD_INFO) libquadmath.info +MAINTAINERCLEANFILES = $(srcdir)/libquadmath.info + +endif + + +# Automake Documentation: +# If your package has Texinfo files in many directories, you can use the +# variable TEXINFO_TEX to tell Automake where to find the canonical +# `texinfo.tex' for your package. The value of this variable should be +# the relative path from the current `Makefile.am' to `texinfo.tex'. +TEXINFO_TEX = ../gcc/doc/include/texinfo.tex + +# Defines info, dvi, pdf and html targets +MAKEINFOFLAGS = -I $(srcdir)/../gcc/doc/include +info_TEXINFOS = libquadmath.texi Index: LICENCES === --- LICENCES (Revision 0) +++ LICENCES (Revision 0) @@ -0,0 +1,69 @@ +This file contains the copying permission notices for various files in the +GCC Quad-Precision Math Library distribution that have copyright owners other +than the Free Software Foundation. These notices all require that a copy of +the notice be included in the accompanying documentation and be distributed with +binary distributions of the code, so be sure to include this file along +with any binary distributions derived from the GCC Quad-Precision Math Library. + + +The code incorporated from gdtoa is distributed under the following +license: + +The author of this software is David M. Gay. + +Copyright (C) 1998-2001 by Lucent Technologies +All Rights Reserved + +Permission to use, copy, modify, and distribute this software and +its documentation for any purpose and without fee is hereby +granted, provided that the above copyright notice appear in all +copies and that both that the copyright notice and this +permission notice and warranty disclaimer appear in supporting +documentation, and that the name of Lucent or
[c++0x] cannot return a constant
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 lot of code where I do not want to modify x [accidentally]
}
return x;
}
$ g++ -c -std=c++0x test1.cc
test1.cc: In function 'X test()':
test1.cc:13:10: error: use of deleted function 'X::X(const X&)'
test1.cc:4:3: error: declared here
Another related example:
$ cat test2.cc
struct U {
U();
U(U&&);
U(U const&);
};
struct X {
U const u;
X()=default;
X(X&&)=default;
//100 other members
};
X test() {
X a={};
return a;
}
$ g++ -c -std=c++0x test2.cc
test2.cc: In function 'X test()':
test2.cc:16:10: error: use of deleted function 'X::X(X&&)'
test2.cc:10:3: error: 'X::X(X&&)' is implicitly deleted because the default
definition would be ill-formed:
test2.cc:10:3: error: non-static data member 'X::u' does not have a move
constructor or trivial copy constructor
In both examples, g++0x forces removing "const" (in "X const x={};" and
"U const u;") or doing some other ugly things like const_cast. In
general, it is not good to discourage using "const" for a number of
reasons. Additionally, if I have to have constness, I need to add
additional clutter reducing readability.
Can nothing be done to preserve "const"? Does the Standard really make
this code invalid? Gcc v4.5 was friendlier in this respect.
Re: [Patch,quadmath] PR 46543: Add first documentation
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 the rest of the > +# sources. Therefore we have --enable-generated-files-in-srcdir to do > +# just that. > +AC_MSG_CHECKING([for --enable-generated-files-in-srcdir]) > +AC_ARG_ENABLE(generated-files-in-srcdir, no, , > + [put copies of generated files in source dir intended for creating source > +tarballs for users without texinfo bison or flex.], > + permit yes|no) That's not a valid use of AC_ARG_ENABLE. Did you mean GCC_ENABLE? Andreas. -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: [c++0x] cannot return a constant
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-copyable content
> };
>
> X test() {
> X const x={};
> {
> //a lot of code where I do not want to modify x [accidentally]
> }
> return x;
> }
>
> $ g++ -c -std=c++0x test1.cc
> test1.cc: In function 'X test()':
> test1.cc:13:10: error: use of deleted function 'X::X(const X&)'
> test1.cc:4:3: error: declared here
How do you expect to return a non-copyable object by value?
You could change it to return std::move(x) but you can't move from a const.
> Another related example:
>
> $ cat test2.cc
> struct U {
> U();
> U(U&&);
> U(U const&);
> };
>
> struct X {
> U const u;
> X()=default;
> X(X&&)=default;
> //100 other members
> };
>
> X test() {
> X a={};
> return a;
> }
>
> $ g++ -c -std=c++0x test2.cc
> test2.cc: In function 'X test()':
> test2.cc:16:10: error: use of deleted function 'X::X(X&&)'
> test2.cc:10:3: error: 'X::X(X&&)' is implicitly deleted because the default
> definition would be ill-formed:
> test2.cc:10:3: error: non-static data member 'X::u' does not have a move
> constructor or trivial copy constructor
This clearly tells you what's wrong.
> In both examples, g++0x forces removing "const" (in "X const x={};" and
> "U const u;") or doing some other ugly things like const_cast. In
> general, it is not good to discourage using "const" for a number of
> reasons. Additionally, if I have to have constness, I need to add
> additional clutter reducing readability.
>
> Can nothing be done to preserve "const"? Does the Standard really make
> this code invalid? Gcc v4.5 was friendlier in this respect.
GCC 4.5 did not implement the current C++0x rules.
However, that doesn't change the fact you're trying to move from a
const object, which is obviously wrong.
Re: [c++0x] cannot return a constant
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&&)=default;
>> X(X const&)=delete;
>> //some very large or non-copyable content
>> };
>>
>> X test() {
>> X const x={};
>> {
>> //a lot of code where I do not want to modify x [accidentally]
>> }
>> return x;
>> }
>>
>> $ g++ -c -std=c++0x test1.cc
>> test1.cc: In function 'X test()':
>> test1.cc:13:10: error: use of deleted function 'X::X(const X&)'
>> test1.cc:4:3: error: declared here
>
> How do you expect to return a non-copyable object by value?
>
> You could change it to return std::move(x) but you can't move from a const.
To fix this broken code, either
1) do not delete the copy constructor, you need it to return by value.
or
2) do not make 'x' const, and move from it with return std::move(x)
>> Another related example:
>>
>> $ cat test2.cc
>> struct U {
>> U();
>> U(U&&);
>> U(U const&);
>> };
>>
>> struct X {
>> U const u;
>> X()=default;
>> X(X&&)=default;
>> //100 other members
>> };
>>
>> X test() {
>> X a={};
>> return a;
>> }
>>
>> $ g++ -c -std=c++0x test2.cc
>> test2.cc: In function 'X test()':
>> test2.cc:16:10: error: use of deleted function 'X::X(X&&)'
>> test2.cc:10:3: error: 'X::X(X&&)' is implicitly deleted because the default
>> definition would be ill-formed:
>> test2.cc:10:3: error: non-static data member 'X::u' does not have a move
>> constructor or trivial copy constructor
>
> This clearly tells you what's wrong.
To fix this broken code,
1) do not define the X move constructor as defaulted, because the
default definition attempts to move from U, which is const so the
default definition is ill-formed
and
2) define a copy constructor, explicitly-defaulted if you wish.
Re: [c++0x] cannot return a constant
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 code where I do not want to modify x [accidentally]
>> }
>> return x;
>> }
>>
>> $ g++ -c -std=c++0x test1.cc
>> test1.cc: In function 'X test()':
>> test1.cc:13:10: error: use of deleted function 'X::X(const X&)'
>> test1.cc:4:3: error: declared here
>
>How do you expect to return a non-copyable object by value?
If x is not const, the move constructor allows returning x. Gcc is
even allowed to elide the movement and construct x directly into the
return value.
>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.
Re: [c++0x] cannot return a constant
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={};
>>> {
>>> //a lot of code where I do not want to modify x [accidentally]
>>> }
>>> return x;
>>> }
>
>To fix this broken code, either
>1) do not delete the copy constructor, you need it to return by value.
Cannot do it because of "//some very large or non-copyable content".
>or
>2) do not make 'x' const, and move from it with return std::move(x)
With x being non-const, move() is not required. And I really like using
"const" for a number of reasons. This is the crux of the question.
>>> $ cat test2.cc
>>> struct U {
>>> U();
>>> U(U&&);
>>> U(U const&);
>>> };
>>>
>>> struct X {
>>> U const u;
>>> X()=default;
>>> X(X&&)=default;
>>> //100 other members
>>> };
>>>
>>> X test() {
>>> X a={};
>>> return a;
>>> }
>
>To fix this broken code,
>1) do not define the X move constructor as defaulted, because the
>default definition attempts to move from U, which is const so the
>default definition is ill-formed
>and
Without the defaulted constructor I would have to type the code moving
all "//100 other members".
>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?
Thanks
Re: [c++0x] cannot return a constant
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 the objects are about to be destroyed makes it reasonable to bind an rvalue reference to them -- but it doesn't make it reasonable to bind any kind of non-const reference to them (and an rvalue-ref-to-const is a strange and largely useless beast). If you want to be able to change an object during its lifetime, don't make it const. -- James
Re: [Patch,quadmath] PR 46543: Add first documentation
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 from .texi file following the suggestion of Matthias - > which is in line with > http://www.gnu.org/prep/maintain/html_node/License-Notices-for-Documentation.html I think you have misunderstood. If you don't have a license text then there is no permission to distribute the document at all. You need to include a notice about GFDL licensing, and the text of the GFDL. What you can omit is cover texts and invariant sections, in manuals of under 400 pages that are not published by the FSF on paper. -- Joseph S. Myers jos...@codesourcery.com
Re: [Patch,quadmath] PR 46543: Add first documentation
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 manual does, for example).
--
Joseph S. Myers
jos...@codesourcery.com
Re: [c++0x] cannot return a constant
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
>>> };
>>>
>>> X test() {
>>> X const x={};
>>> {
>>> //a lot of code where I do not want to modify x [accidentally]
>>> }
>>> return x;
>>> }
>>>
>>> $ g++ -c -std=c++0x test1.cc
>>> test1.cc: In function 'X test()':
>>> test1.cc:13:10: error: use of deleted function 'X::X(const X&)'
>>> test1.cc:4:3: error: declared here
>>
>>How do you expect to return a non-copyable object by value?
>
> If x is not const, the move constructor allows returning x.
exactly as expected.
> Gcc is
> even allowed to elide the movement and construct x directly into the
> return value.
copy elision does not waive verification of viable copy-constructor.
>
>>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.
>
yes, but that ir orthogonal to moving from a const object -- those are
standard rules.
Re: [c++0x] cannot return a constant
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
Re: [c++0x] cannot return a constant
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 currently present in the C++0x WD) that g++ gets wrong.
operator new[] overflow (PR 19351)
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 told how to change the patch to make it more
suitable for inclusion ("change the middle end type system so that
this can be expressed in a better way" is just not realistic for me,
and apparently anyone else):
So how can we fix this, more than eight years after it was reported as
a security issue, more than ten years after the defect in the standard
was identified, and more than twenty years after it was introduced
into GCC?
Re: [c++0x] cannot return a constant
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-destroyed. isn't that a question for C++ forums?
Re: [c++0x] cannot return a constant
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. :)
Re: [c++0x] cannot return a constant
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 for C++ forums? > > I hoped you knew the answer. :) 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.
Re: [c++0x] cannot return a constant
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 which part of the standard makes the mentioned code invalid? I'm not complaining and I like the language. My point is that I'm trying to find a loophole in the standard so that g++, without violating the standard, could allow move-and-destroy of constants. Thanks.
Re: operator new[] overflow (PR 19351)
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 case, but it has not been
> approved, nor have I been told how to change the patch to make it more
> suitable for inclusion ("change the middle end type system so that
> this can be expressed in a better way" is just not realistic for me,
> and apparently anyone else):
>
>
My suggestion at
wasn't to change the type system; it was to add new GENERIC / GIMPLE codes
within the existing type system.
Saturating arithmetic keeps coming up in one context or another. It's
generally relevant if you want to exploit various instructions on various
processors - or if you want to support vector intrinsics (which may
include saturating operations) even when the vector instructions aren't
present (see recent discussions of doing that for SSE intrinsics, for
example). Sooner or later I expect someone will decide to do the work for
at least one target.
Related to the "operator new[]" issue, I'm concerned that saturation alone
may not be enough to solve problems with overflows in allocation. If on a
32-bit system you allocate 2GB or more of memory, then differences between
addresses in / just after that array cannot be calculated reliably as they
may excess the range of ptrdiff_t. Thus actually malloc ought to reject
allocations that take half or more of the address space, to avoid
undefined behavior arising in the calling code (such allocations simply
cannot be used reliably in C or C++). But I don't see anything in glibc's
malloc to do so; it seems quite possible that it could allocate over 2GB
in a single allocation on a 32-bit system. (See PR 45779, but I think the
only sensible place to fix this is the implementation of malloc.)
--
Joseph S. Myers
jos...@codesourcery.com
Re: [c++0x] cannot return a constant
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 language, complain >>somewhere else. >> > > Then please tell me which part of the standard makes the mentioned code > invalid? > > I'm not complaining and I like the language. My point is that I'm trying > to find a loophole in the standard so that g++, without violating the > standard, could allow move-and-destroy of constants. if you are trying to find a loophole in the standard, then: 1. I would have expected that you are studying the standard, and therefore can cite appropriate references that support your interpretation 2. if you make the premise that g++ correctly implements the standard, then you should be asking your questions in C++ standards forums as they clearly are not about GCC development 3. there are better ways of using people's times than making a statement (not supported by anything) and asking them to prove your wrong.
Re: operator new[] overflow (PR 19351)
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 generation issue?
>> I've created a patch, together with a test case, but it has not been
>> approved, nor have I been told how to change the patch to make it more
>> suitable for inclusion ("change the middle end type system so that
>> this can be expressed in a better way" is just not realistic for me,
>> and apparently anyone else):
>>
>>
>
> My suggestion at
> wasn't to change the type system; it was to add new GENERIC / GIMPLE codes
> within the existing type system.
>
> Saturating arithmetic keeps coming up in one context or another. It's
> generally relevant if you want to exploit various instructions on various
> processors - or if you want to support vector intrinsics (which may
> include saturating operations) even when the vector instructions aren't
> present (see recent discussions of doing that for SSE intrinsics, for
> example). Sooner or later I expect someone will decide to do the work for
> at least one target.
>
> Related to the "operator new[]" issue, I'm concerned that saturation alone
> may not be enough to solve problems with overflows in allocation. If on a
> 32-bit system you allocate 2GB or more of memory, then differences between
> addresses in / just after that array cannot be calculated reliably as they
> may excess the range of ptrdiff_t. Thus actually malloc ought to reject
> allocations that take half or more of the address space, to avoid
> undefined behavior arising in the calling code (such allocations simply
> cannot be used reliably in C or C++). But I don't see anything in glibc's
> malloc to do so; it seems quite possible that it could allocate over 2GB
> in a single allocation on a 32-bit system. (See PR 45779, but I think the
> only sensible place to fix this is the implementation of malloc.)
>
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.
-- Gaby
Re: [c++0x] cannot return a constant
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 know >>>GCC implements correctly. If you don't like the language, complain >>>somewhere else. >>> >> >> Then please tell me which part of the standard makes the mentioned code >> invalid? >> >> I'm not complaining and I like the language. My point is that I'm trying >> to find a loophole in the standard so that g++, without violating the >> standard, could allow move-and-destroy of constants. > > if you are trying to find a loophole in the standard, then: > 1. I would have expected that you are studying the > standard, and therefore can cite appropriate > references that support your interpretation > > 2. if you make the premise that g++ correctly implements > the standard, then you should be asking your questions > in C++ standards forums as they clearly are not about > GCC development > > 3. there are better ways of using people's times than making > a statement (not supported by anything) and asking them to prove > your wrong. I was going to refer to the relevant paragraph in the standard but I prefer this answer, thanks, Gaby.
Re: [c++0x] cannot return a constant
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 hoped you knew the answer. :) That would be reasonable on the mailing list gcc-h...@gcc.gnu.org, but not on the mailing list g...@gcc.gnu.org. gcc@gcc.gnu.org is for the development of gcc itself. Please take any future questions about using gcc to gcc-help. Thanks. Ian
[c++0x] inconsistent behaviour with defaulted move constructor
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 compile. Is it a
bug or am I misuse gcc?
Thanks.
$ cat test1.cc
struct U {
U();
U(U const&);
};
struct X {
U const u;
X()=default;
X(X&&)=default;
};
X test() {
X a={};
return a;
}
$ g++ -c -std=c++0x test1.cc
test1.cc: In function 'X test()':
test1.cc:14:10: error: use of deleted function 'X::X(X&&)'
test1.cc:9:3: error: 'X::X(X&&)' is implicitly deleted because the default
definition would be ill-formed:
test1.cc:9:3: error: non-static data member 'X::u' does not have a move
constructor or trivial copy constructor
$ cat test2.cc
struct U {
U();
U(U const&);
};
struct X {
U const u;
X()=default;
X(X&&);
};
X::X(X&&)=default;
X test() {
X a={};
return a;
}
$ g++ -c -std=c++0x test2.cc && echo $?
0
gcc-4.4-20101130 is now available
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/gcc-4_4-branch revision 167318 You'll find: gcc-4.4-20101130.tar.bz2 Complete GCC (includes all of below) MD5=0c238374676b82d97a120d6fb7585409 SHA1=39f6252e882d7dc6596e7e6b3ce45eb7bc424e60 gcc-core-4.4-20101130.tar.bz2C front end and core compiler MD5=5180b485194a69fb52d829aeea079b7f SHA1=5cc8895b043156c7bcd52b58090f92bca7edf743 gcc-ada-4.4-20101130.tar.bz2 Ada front end and runtime MD5=9707a337c85f72e987593bc5744d7228 SHA1=1d6d85501c52b49ac9122af0c81d3cbaa8ed4ed6 gcc-fortran-4.4-20101130.tar.bz2 Fortran front end and runtime MD5=86b4048b9ec9a535374098385b3e1173 SHA1=db3eb278dba2a5f260d05e9d1be9d2b5189f7eaa gcc-g++-4.4-20101130.tar.bz2 C++ front end and runtime MD5=2a8500e8754fe337ce63a110649e440e SHA1=c52a8f82b111d18c37fc1d7ddea885767371e9f4 gcc-java-4.4-20101130.tar.bz2Java front end and runtime MD5=0e8de03d589cd0f4e3923a1b8cdb466b SHA1=0c35532769654b2cb37274cee697383797ac2006 gcc-objc-4.4-20101130.tar.bz2Objective-C front end and runtime MD5=0da705c0d35307fcbdcdc05aab47e261 SHA1=faec91c6caa9bbb43101b2953e71eae609472004 gcc-testsuite-4.4-20101130.tar.bz2 The GCC testsuite MD5=cce31665940049a27a6451f8404bf5f3 SHA1=2b41c6a9f73753e58f076006dd7ace7e4c7cee85 Diffs from 4.4-20101123 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: operator new[] overflow (PR 19351)
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. ... which suggests strongly that GCC should fix it. Too bad the ABI is frozen; if the internal ABI kept the two values (the size of the type, and the number of values) separate and passed two arguments to the allocation function, it would be easy to do the right thing (through bad_alloc if the multiplication overflows).
Re: [c++0x] inconsistent behaviour with defaulted move constructor
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. > > The first program does not compile. The second does compile. Is it a > bug or am I misuse gcc? Such questions are off-topic on this mailing list which is for development of gcc, please take questions about using gcc to the gcc-h...@gcc.gnu.org list, or if you think you've found a bug report it to bugzilla. If it's a bug, discussing how to fix it would be appropriate on this list, but "is this a bug" questions are not.
gcc-4.5-20101125: minor bug & test results
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 failures 179 # of unsupported tests 801 Executing on host: /usr/local/src/gcc_collection/gcc-4.5-20101125-build/gcc/xgcc -v(timeout = 300) spawn /usr/local/src/gcc_collection/gcc-4.5-20101125-build/gcc/xgcc -v Using built-in specs. COLLECT_GCC=/usr/local/src/gcc_collection/gcc-4.5-20101125-build/gcc/xgcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i686-pc-linux-gnu/4.5.2/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../gcc-4.5-20101125/configure --prefix=/usr --enable-shared --enable-languages=c,c++ --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --program-suffix=-4.5 Thread model: posix gcc version 4.5.2 20101125 (prerelease) (GCC) /usr/local/src/gcc_collection/gcc-4.5-20101125-build/gcc/xgcc version 4.5.2 20101125 (prerelease) (GCC) runtest completed at Tue Nov 30 12:38:20 2010 === g++ Summary === # of expected passes23404 # of expected failures 151 # of unsupported tests 115 /usr/local/src/gcc_collection/gcc-4.5-20101125-build/gcc/testsuite/g++/../../g++ version 4.5.2 20101125 (prerelease) (GCC) Hope this helps, Russ
Partial hookization / PR46738 (Was: Re: RFA: partially hookize *_TYPE_SIZE)
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 you say this. Partial conversions have much lower chance of breaking things when the macro is set up in complicated ways, and you also trivially avoid performance regressions at non-converted call site. At the same time, frontends show a lot of instability because of the way they interact with target macros, and this can be eliminated with a partial conversion to target hook. For example for PR46738, I think it is best to change the two current users of ASM_OUTPUT_IDENT - c-family/c-lex.c and ada/gcc-interface/trans.c to use a hook, and define the hook in targhooks.c in terms of ASM_OUTPUT_IDENT, but leave it for stage1 to sort out the mess of #defines #ifdefs / #undefs that govern the definition of this macro.
