g++ and _DecimalXX types
#g++ --version | head -1
g++ (GCC) 4.4.3 20091228 (prerelease)
#cat test.cc
typedef _Decimal32 my_type;
#gcc -c test.cc
#g++ -c test.cc
test.cc:1: error: '_Decimal32' does not name a type
G++ is unfamiliar with the _DecimalXX types. Is it a "feature", bug or lack
of development?
#cat test.cc
typedef __decltype(0.0DF) my_type;
my_type foo(my_type v) { return v; }
#g++ -c test.cc
test.cc:2: internal compiler error: in write_builtin_type, at cp/mangle.c:1855
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
The same question.
Thanks :)
anti-optimization of _DecimalXX by -ffast-math
Hi,
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/home/rk/gcc/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/rk/gcc --enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20100112 (experimental) (GCC)
$ cat test.c
_Decimal64 foo(_Decimal64 a,_Decimal64 b) { return a+b; }
$ gcc -c -O3 -save-temps test.c
$ cat test.s
...
foo:subq$24, %rsp
movq%xmm0, 8(%rsp)
call__bid_a3
movq%xmm0, 8(%rsp)
addq$24, %rsp
ret
...
$ gcc -c -O3 -funsafe-math-optimizations -save-temps test.c
$ cat test.s
...
foo:subq$24, %rsp
movq%xmm0, 8(%rsp)
movq%xmm1, 8(%rsp)
movq8(%rsp), %rcx
movdqa %xmm0, %xmm1
movq%rcx, 8(%rsp)
movq8(%rsp), %xmm0
call__bid_a3
movq%xmm0, 8(%rsp)
addq$24, %rsp
ret
...
Is there a good reason to place something on the stack? Why does
-funsafe-math-optimizations (which is a part of -ffast-math) make things
even worse? It actually swaps the arguments for __bid_a3().
Thanks :)
missing C++ typeinfo for __float128
Hi,
Typeinfo for __float128 is undefined. Is it a bug?
Thanks.
$ cat test.cpp
#include
#include
int main() {
return strlen(typeid(__float128).name());
}
$ g++ test.cpp
/tmp/ccw01pnm.o: In function `main':
test.cpp:(.text+0x5): undefined reference to `typeinfo for __float128'
collect2: ld returned 1 exit status
$ g++ --version | head -1
g++ (GCC) 4.5.0 20100312 (experimental)
$ g++ -dumpmachine
x86_64-unknown-linux-gnu
$ ld --version | head -1
GNU ld (GNU Binutils) 2.20.1.20100303
Re: gmp 5.0.1 and gcc 4.5?
On Mon, 29 Mar 2010 12:55:47 -0400 Jack Howarth wrote: >I've not seen any discussion of testing gcc trunk > against the newer gmp 5.0 or 5.0.1 releases. Has anyone > done significant testing with the newer gmp releases > ... ? I use gcc 4.4.4 and 4.5.0 with gmp 5.0.1. I compile and use PostgreSQL and other stuff, and have not noticed any misbehavior related to gmp or mpfr. Although, I cannot say that I use gcc in a way that makes a lot of gmp or mpfr testing.
8x compilation time increase after r157834
Hi, r157834 of the trunk made compilation time almost 8(eight!) times longer. The time went from 38 to 291 seconds. $ svnversion ~/src/gcc 157833 $ make -C ~/src/gcc install ... $ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -Werror -Wno-unused \ -Wno-parentheses -I../ check.cpp -o check -MMD -lrt 37.65user 0.56system 0:38.26elapsed 99%CPU (0avgtext+0avgdata \ 0maxresident)k 0inputs+0outputs (0major+85545minor)pagefaults 0swaps $ svnversion ~/src/gcc 157834 $ make -C ~/src/gcc install ... $ /usr/bin/time g++ -std=c++0x -O2 -g -Wall -Werror -Wno-unused \ -Wno-parentheses -I../ check.cpp -o check -MMD -lrt 290.90user 0.63system 4:51.56elapsed 99%CPU (0avgtext+0avgdata \ 0maxresident)k 0inputs+0outputs (0major+101971minor)pagefaults 0swaps $ g++ -dumpmachine x86_64-unknown-linux-gnu Configured by $ ./configure --prefix=$HOME/gcc --disable-multilib Would it be acceptable to revert c157834 or it fixes an important bug? It is unclear from the commit log message and the 43593 bugzilla report. I did not notice any influence of c157834 to the compiled program performance. Thanks, Roman
Re: 8x compilation time increase after r157834
On 2010-04-02, 20:50 CDT, Richard Guenther said: >The patch is about debuginfo. Can you file a bugzilla and attach >preprocessed source for the testcase? $g++ -E -std=c++0x -I../ check.cpp | sed -r '/^( *|\#.*)$/d' | wc -l 24526 The preprocessed source has 24526 non-blank lines. Should I attach it? Should I make a new bugzilla or add a comment to #43593? Thanks, Roman
std::move() does not move a constant of a class type
Hello,
Is it a bug or am I missing something?
$ cat test.cpp
#include
struct X {
X()=default;
X(X&&)=default;
};
X test() {
X const a={};
return std::move(a);
}
$ g++ -c -std=c++0x test.cpp
test.cpp: In function 'X test()':
test.cpp:10:22: error: no matching function for call to
'X::X(std::remove_reference::type)'
test.cpp:5:4: note: candidates are: constexpr X::X(X&&)
test.cpp:4:4: note: constexpr X::X()
This is v4.6. v4.5 is happy here.
Thanks
Re: std::move() does not move a constant of a class type
On 2010-11-27, 16:37:07 -0800, James Dennett
wrote:
> 4.6 appears to be right -- you cannot bind an X&& to a const X (which
> is good, as otherwise you could change the const X).
Should this one emit the same error then? 4.6 compiles it.
typedef int X;
X test() {
X const& a={};
return std::move(a);
}
Thanks
Re: std::move() does not move a constant of a class type
On 2010-11-27, 20:22:02 -0600, Roman Kononov
wrote:
> Should this one emit the same error then? 4.6 compiles it.
>
> typedef int X;
> X test() {
>X const& a={};
>return std::move(a);
> }
Never mind. I've figured it out.
Thanks.
Fw: new requirement of "constexpr" for static const float data members is too restrictive
$ cat test.cc
struct X { static float const v=1; };
$ g++ -c -std=gnu++0x test.cc
test.cc:1:33: error: 'constexpr' needed for in-class initialization of
static data member 'v' of non-integral type
This will break a great deal of existing c++ code preventing easy
transition to c++0x. Maybe, the constexpr requirement should be relaxed
in gnu++0x mode.
Please see the trivial patch.
Thanks
Index: gcc/cp/decl.c
===
--- gcc/cp/decl.c (revision 167200)
+++ gcc/cp/decl.c (working copy)
@@ -7436,7 +7436,7 @@
in check_initializer. */
if (DECL_P (decl) && DECL_DECLARED_CONSTEXPR_P (decl))
return 0;
- else if (cxx_dialect >= cxx0x && !INTEGRAL_OR_ENUMERATION_TYPE_P (type))
+ else if (cxx_dialect >= cxx0x && !INTEGRAL_OR_ENUMERATION_TYPE_P (type) && flag_iso)
{
if (literal_type_p (type))
error ("% needed for in-class initialization of static "
Re: new requirement of "constexpr" for static const float data members is too restrictive
2010-11-29 13:25 CST, Andrew Pinski wrote: >well this code is not valid C++03 code to begin with. I agree. I mean "existing gnu++" if you will.
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
[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: [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
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
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
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.
[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
Re: Merging identical functions in GCC
On 09/15/2006 04:32 PM, Ross Ridge wrote:
Also, I don't think it's safe if you merge only functions in COMDAT
sections.
Consider:
#include
template T foo(T a) { return a; }
template T bar(T a) { return a; }
int
main() {
assert((int (*)(int)) foo != (int (*)(int)) bar);
}
Both foo and bar get put in their own COMDAT section and their
RTL and assembly are the same, but it's not safe to merge them.
Merge can be safely done like this:
If both functions A and B are not inlined functions, and they have single
entry points, and memcmp of their asm code is zero, and the code is large
enough, then the asm code of the functions B is replaced by "jmp A" instruction.
Regards,
Roman
