4.8.1 fails to build on x86_64-unknown-linux-gnu
I have a set of the required libraries built and installed into
separate directories, so when gcc is configured with:
../configure --prefix=/opt/tools/gcc-4.8.1
--with-gmp=/opt/tools/gmp-5.1.2 --with-mpfr=/opt/tools/mpfr-3.2.1
--with-mpc=/opt/tools/mfr=/opt/tools/mpfr-3.2.1
--with-mpc=/opt/tools/mpc-1.0.1 --with-ppl=/opt/tools/ppl-1.1
--with-cloog=/opt/tools/cloog-0.18.0 --enable-languages=c,c++
--disable-multilib
during configure-stage1-target-libgcc:
configure: error: cannot compute suffix of object files: cannot compile
and config.log contains:
configure:3565: checking for suffix of object files
configure:3587: /mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/xgcc
-B/mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/
-B/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/bin/
-B/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/lib/ -isystem
/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/include -isystem
/opt/tools/gcc-4.8.1/x86_64-unknown-linux-gnu/sys-include-c -g -O2
conftest.c 5
/mnt/local/piotrw/build/gcc-4.8.1/objdir/./gcc/cc1: error while
loading shared libraries: libmpc.so.3: cannot open shared object file:
No such file or directory
configure:3591: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME GNU C Runtime Library
| #define PACKAGE_TARNAME libgcc
| #define PACKAGE_VERSION 1.0
| #define PACKAGE_STRING GNU C Runtime Library 1.0
| #define PACKAGE_BUGREPORT
| #define PACKAGE_URL http://www.gnu.org/software/libgcc/;
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| ;
| return 0;
| }
configure:3605: error: in
`/mnt/local/piotrw/build/gcc-4.8.1/objdir/x86_64-unknown-linux-gnu/libgcc':
configure:3608: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details.
which indicates that the configure scripts somehow failed to add the
mpc libpath to the command line.
Best regards, Piotr
Re: [C++] Possible GCC bug
Dodji Seketeli wrote:
That, and [dcl.typedef]/6 says:
In a given scope, a typedef specifier shall not be used to redefine
the name of any type declared in that scope to refer to a different
type.
So, I tend to think that GCC is right here.
Right *where*? In case of the snippet provided by Ulf -- yes, obviously.
In my case there is no that scope, i.e. I redefine the type super defined
in the *surrounding* scope, not in the very same, as Ulf did. It is exactly
the same situation as:
{ int i;
float i;
}
and:
{int i;
{ float i;}
}
Best regards, Piotr
[C++] Possible GCC bug
The following snippet:
class A {};
class B : public A {
typedef A super;
public:
class X {};
};
class C : public B {
typedef B super;
class X : public super::X {
typedef super::X super;
};
};
compiles without a warning on Comeau and MSVC, but GCC (4.6.1 and
4.7.1) failes with the following message:
$ gcc -c bug.cpp
bug.cpp:18:24: error: declaration of ‘typedef class B::X C::X::super’
[-fpermissive]
bug.cpp:14:14: error: changes meaning of ‘super’ from ‘typedef class B
C::super’ [-fpermissive]
Should I file a report?
Best regards, Piotr
Perfect forwarding seems not to be so perfect
Hello,
on gcc-4.6.2/x64/linux:
template typename... TA inline string format(const string fmt,
TA... args) {
string_formatter f;
f.format(fmt, std::forwardTA(args)...);
return f.get_result();
}
results in:
error: no matching function for call to 'forward(const char* const)'
note: candidates are:
/opt/a3d/stow/gcc-4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/move.h:62:5:
note: templateclass _Tp _Tp std::forward(typename
std::remove_reference_Tp::type)
/opt/a3d/stow/gcc-4.6.2/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.6.2/../../../../include/c++/4.6.2/bits/move.h:67:5:
note: templateclass _Tp _Tp std::forward(typename
std::remove_reference_Tp::type)
Should I report it as a standard library bug?
Best regards, Piotr
C++0x convertibility checking
Consider the folowing:
class XXX {
public:
XXX(char) {}
template typename T XXX(T) = delete;
};
fprintf(stderr, icchar::value = %i\n,
std::is_convertiblechar, XXX::value);
fprintf(stderr, icdouble::value = %i\n,
std::is_convertibledouble, XXX::value);
The code above doesn't compile on gcc 4.6:
In file included from /home/piotr.wyderski/f1/base/common.h:9:0,
from /home/piotr.wyderski/f1/main.cpp:8:
/opt/gcc-trunk-old2/bin/../lib/gcc/i686-pc-cygwin/4.6.0/include/c++/type_traits:
In instantiation of `const bool std::__is_convertible_helperdouble, XXX, false
::__value':
/opt/gcc-trunk-old2/bin/../lib/gcc/i686-pc-cygwin/4.6.0/include/c++/type_traits:
309:12: instantiated from `std::is_convertibledouble, XXX'
/home/piotr.wyderski/f1/main.cpp:219:81: instantiated from here
/home/piotr.wyderski/f1/main.cpp:186:31: error: deleted function `XXX::XXX(T) [w
ith T = double]'
/opt/gcc-trunk-old2/bin/../lib/gcc/i686-pc-cygwin/4.6.0/include/c++/type_traits:
302:71: error: used here
IMO it should result in an executable program which prints:
icchar::value =1
icdouble::value = 0
as double is obviously not convertible to XXX -- the template
typename T XXX(T) = delete;
idiom: is very similar to an example from the N2346 proposal:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2007/n2346.htm
Removing dangerous conversions is as important as removing undesired
language defaults.
struct type
{
type( long long ); // can initialize with an long long
type( long ) = delete; // but not anything less
};
extern void bar( type, long long ); // and the same for bad overloads
void bar( type, long ) = delete; // of free functions
Should I file a bug report or is it broken by design?
A proposed fix is to remove the current template-based detector in the
standard library and provide
a built-in function __is_convertible which would check such corner
cases in a much smarter way
than is possible with templates:
http://gcc.gnu.org/onlinedocs/gcc-4.4.2/gcc/Type-Traits.html#Type-Traits
Best regards,
Piotr Wyderski
Re: C++0x convertibility checking
Paolo Carlini wrote: The issue may even be known or already fixed in mainline and 4.6. I confirm, the issue has already been fixed on the released version of 4.6. It exists on gcc versions 4.5.1 (official release) and 4.6.0 20100609 (experimental) (GCC). Best regards, Piotr Wyderski
Specifying additional information of pointers
Hello, I'm implementing in C++ a semi-portable portable bit vector based on SIMD extensions available on the platform. GCC automatically vectorizes it to a large extent, but much better code could have been generated it there were a way to annotate the source code somehow. Namely, in many places I know that a pointer points to an 8-bytes aligned array of std::uint64_t (hence the compiler should use movdqu), but the number of elements is divisible by 2, so no fixup code needs to be generated and only the SSE2-based variant should be emitted. Is there a way to tell the compiler about it via some attribute or pragma? Of course a full-blown platform-specific variant of the source code is possible, but as the vectorizer does a good job (relatively to its limited knowledge), I would prefer to help it instead of reimplementing the vector. Best regards Piotr Wyderski
Re: More atomic functions please
Jakub Jelinek wrote: And that's the right thing to do. I concur. But the exchange case remains open. Please file an enhancement request in gcc bugzilla. Done, 48986. I have also noticed several other missing optimizations in this area, so I'm about to report them too. Best regards, Piotr Wyderski
More atomic functions please
Hello,
I'm not sure if it should be better handled as missed optimization,
but there is a certain lack of functionality in the GCC's __sync_*
function family.
When implementing a reference counting smart pointer, two operations
are of crucial importance:
void __sync_increment(T* p);
bool __sync_decrement_iszero(T* p);
The former only increments the location pointed to by p, the latter decrements
it and returns true if and only if the result was zero.
Both can be implemented in terms of existing __sync functions (and what
can't? -- since there is __sync_bool_compare_and_swap()), e.g.:
void __sync_increment(T* p) {
__sync_fetch_and_add(p, 1);
}
bool __sync_decrement(T* p) {
return __sync_fetch_and_add(p, -1) == 1;
}
Unfortunately, onx86/x64 both are compiled in a rather poor way:
__sync_increment:
lock addl $x01,(ptr)
which is longer than:
lock incl (ptr)
__sync_decrement:
movl -1, %rA
lock xadd %rA, (ptr)
cmpl $0x01, %rA
je/jne...
which is undoubtedly longer than lock dec and wastes a register.
I can optimally implement the increment function with a bit of inline
assembly, but decrement is not so lucky, as there is no way to
inform the compiler the result is in the flags register. One must retreat
to something like that:
lock decl (ptr)
sete %rA
which GCC will finally use to perform a comparison in if(), emitting:
lock decl (ptr)
sete %rA
testb %rA, %rA
je/jne...
which is hardly an improvement. On the other hand, the __sync functions
integrate perfectly with the flag system (i.e. the pairs like cmpxchg/jne),
so implementing the changes in the compiler gives far better opportunities
to emit an optimal sequence compared to what can inline assembly do.
As my code is to a high degree propelled by atomic power, I would like to
ask you to provide these functions or tweak the optimizer in order to notice
the aforementioned idioms.
There is also lack of generic __sync_exchange() -- quite an important operation
in lock-free programming. It could be implemented in terms of compare_exchange,
but many platforms have native support for it and thus it should be
exposed at the
API level, tweaking the optimizer is not the proper way IMHO.
Best regards,
Piotr Wydersk
Re: More atomic functions please
Jakub Jelinek wrote: /* X86_TUNE_USE_INCDEC */ ~(m_PENT4 | m_NOCONA | m_CORE2I7 | m_GENERIC | m_ATOM), So, if you say -mtune=bdver1 or -mtune=k8, it will generate incl, if addl is better (e.g. on Atom incl is very bad compared to addl $1), it will generate it. Why is lock inc/dec worse than add/sub on Core2I7? The only difference I know of is the way the carry flag is handled. Best regards, Piotr Wyderski
Re: GCC 4.6.0 Released
Jakub Jelinek ja...@redhat.com: The GNU Compiler Collection version 4.6.0 has been released. Compilation failure on Cygwin: ../../../libgcc/config/libbid/bid_decimal_globals.c:47:18: fatal error: fenv.h: No such file or directory compilation terminated. make[3]: *** [bid_decimal_globals.o] Error 1 Configured as: ../configure --prefix=/opt/gcc-4.6.0 -v --enable-bootstrap --enable-version-specific-runtime-libs --enable-static --enable-shared --enable-shared-libgcc --disable-__cxa_atexit --with-gnu-ld --with-gnu-as --with-dwarf2 --disable-sjlj-exceptions --enable-languages=c,c++ --disable-symvers --enable-libgomp --enable-libssp --enable-threads=posix --with-arch=core2 --with-tune=generic --enable-libgcj-sublibs Best regards Piotr Wyderski
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
Cross-platform build problem
Hello, I'm trying to compile a GCC toolchain with target=arm-elf and hosted on Cygwin/PC. Unfortunately, both GCC 4.5.1, taken from the official mirror, and 4.6 trunk taken from SVN fail to compile with the following error message: checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking for shl_load... configure: error: Link tests are not allowed after GCC_ NO_EXECUTABLES. make[1]: *** [configure-target-libstdc++-v3] Error 1 They were configured with: $ ../configure --prefix=/opt/arm/gcc-4.5.1 --target=arm-elf --enable-interwork --enable-multilib --enable-languages=c,c++ Best regards, Piotr Wyderski
Re: C99 and C++0x status pages
Andre Majorel wrote: Those are among the most useful pages of the site, it makes no sense to bury them 4+ levels deep. Google is your friend: when asked for g++ c++0x it returns the correct page as the first result. I always use it that way, because website messiness appears to be a de facto Internet standard and GNU is well known for its standard conformance. ;-) Best regards, Piotr
Re: No output files on 4.6/Cygwin
Dave Korn wrote: I've just updated my repo and will schedule a nightly build of trunk with configure settings taken from the bundled gcc4 compiler from Cygwin pack in order to see what will happen. That's the simplest way to guarantee compatibility. And now the compiler works correctly, so it is tempting to assume that the problem was related to SJLJ exceptions, as you conjectured. Thanks! Best regards Piotr Wyderski
No output files on 4.6/Cygwin
I have a problem with recent builds of GCC4.6 (trunk)
on Cygwin 1.7. The compiler itself builds correctly, but
when I run it on even the simplest input, e.g.
gcc in.c -o a.exe
with in.c = int main() {}, no executable file is created.
No oputput is created even with the -S and -E options.
The same used to happen with GCC 4.5 experimental
in its early development days, but later started to work
again. Is it a known issue of GCC or Cygwin? Has
anyone managed to get a working 4.6 build on Cygwin?
Best regards,
Piotr Wyderski
Re: No output files on 4.6/Cygwin
Wojciech Meyer wrote: Maybe a mismatched cygwin1.dll. Do you have the right version of cygwin1.dll on path? e.g the one against which gcc was compiled?. Cygwin fails silently to execute the image in case of a mismatched dll. I am not 100% sure that my Cygwin installation is OK, as it has been upgraded from 1.5 without uninstalling the latter (i.e. I wiped it out using a mere rm -rf), but the image itself works: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/opt/gcc-trunk/libexec/gcc/i686-pc-cygwin/4.6.0/lto-wrapper.exe Target: i686-pc-cygwin Configured with: ../configure --prefix=/opt/gcc-trunk -v --enable-bootstrap --enable-version-specific-runtime-libs --ena ble-shared --enable-shared-libgcc --with-gnu-ld --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --with-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages=c,c++ AM_CXXFLAGS=-w Thread model: posix gcc version 4.6.0 20100607 (experimental) (GCC) Best regards Piotr Wyderski
Re: No output files on 4.6/Cygwin
Dave, Are you sure you're picking up the newest version of cyggcc_s-1.dll (and all the other language runtimes) that got built with the compiler, rather than the standard system one(s)? How can I check that? You did a full make install and put the new $prefix/bin (if not using the standard prefix) at the head of your PATH? Yes: export PATH=/opt/gcc-trunk/bin/:$PATH Wasn't it last time because you didn't have --disable-sjlj-exceptions in your configure command and so you ended up with sjlj-based DLLs that didn't play nicely with the Cygwin distro's DW2-based ones? Yes, then it was the case. But doesn't my --enable-dwarf2-exceptions already imply --disable-sjlj-exceptions? It works with gcc-4.5. I've just updated my repo and will schedule a nightly build of trunk with configure settings taken from the bundled gcc4 compiler from Cygwin pack in order to see what will happen. Best regards Piotr Wyderski
Re: (un)aligned accesses on x86 platform.
Alexey Salmin wrote: I always thought that unaligned access is much slower than aligned one. It is not *MUCH* slower, just slower (unless you cross cache line boundary). Unaligned accesses are very useful for improving performance of, among other things, certain hash functions (e.g. Paul Hsieh's one). Best regards, Piotr Wyderski
Unroller gone wild
I have the following code:
struct bounding_box {
pack4sf m_Mins;
pack4sf m_Maxs;
void set(__v4sf v_mins, __v4sf v_maxs) {
m_Mins = v_mins;
m_Maxs = v_maxs;
}
};
struct bin {
bounding_box m_Box[3];
pack4si m_NL;
pack4sf m_AL;
};
static const std::size_t bin_count = 16;
bin aBins[bin_count];
for(std::size_t i = 0; i != bin_count; ++i) {
bin b = aBins[i];
b.m_Box[0].set(g_VecInf, g_VecMinusInf);
b.m_Box[1].set(g_VecInf, g_VecMinusInf);
b.m_Box[2].set(g_VecInf, g_VecMinusInf);
b.m_NL = __v4si{ 0, 0, 0, 0 };
}
where pack4sf/si are union-based wrappers for __v4sf/si.
GCC 4.5 on Core i7/Cygwin with
-O3 -fno-lto -msse -msse2 -mfpmath=sse -march=native -mtune=native
-fomit-frame-pointer
completely unrolled the loop into 112 movdqa instructions,
which is a bit too agressive. Should I file a bug report?
The processor has an 18 instructions long prefetch queue
and the loop is perfectly predictable by the built-in branch
prediction circuitry, so translating it as is would result in huge
fetch/decode bandwidth reduction. Is there something like
#pragma nounroll to selectively disable this optimization?
Best regards
Piotr Wyderski
Re: Useless conditional branches
Alain Ketterlin wrote: I've found code like this: xor %edx,%edx ; code with no effect on edx (see full code below) test %edx,%edx jne somewhere else I have experienced similar sequences where your code with no effect was a lot of SSE instructions, so I can confirm that the problem exists. Best regards Piotr Wyderski
Re: Change x86 default arch for 4.5?
H.J. Lu wrote: Default to SSE2 is a good first step. I concur; all the programs I'm working on require SSE2 and are not supposed to be back-portable to SSE or fpu. Simply too many vital optimizations require that ISA. Best regards Piotr Wyderski
Re: What's the policy for bug priorities, again
Richard Guenther wrote:
Note that all regressions from 4.4 that are visible with release
checking and valid input should be considered P1 first
I don't know, what is considered to be a showstopper,
but bad things happen inside 4.5 (x86-32/Cygwin + a
lot of SSE). In the last weekend I was able to:
a) ICE the compiler with a message SSA validation failed
or something like that;
b) in 32-bit mode generate an assembler error
~%bpl is not a recognized register when writing
to a volatile global variable;
c) to become 99.9% certain that the compiler generates
wrong code in at least one case, i.e.:
for(int i = k; i != 0;) {
if (fn(params)) {
continue;
}
gn();
}
gn() was not executed despite the fact fn() returned false.
d) 20100208 is not able to compile trunk (from yesterday),
because it gets stuck on, among other things, tree-ssa-structalias.o
I am not going to formally report these issues, as the testcases
are BIG, but IMHO there is no hurry to release 4.5, as it has
great chances to become a disaster, despite the fact of its wonderful
C++0x support.
Best regards
Piotr Wyderski
Re: Bugzilla and setting priorities
Steven Bosscher wrote: Only RMs may set priority. I beg your pardon? Where in the docs does it say that? I don't know that, but it's been discussed many times on this list. As a mere mortal I've used the priority setting combo a few times to specify (perceived) priority, which later was adjusted by a person reviewing bug reports (i.e. Andrew or Paolo), so, at least technically, it is available to anyone. Anyway, speaking of reporting bugs: what's the rule of specifying CCs? Especially to the submitter himself? I would like to be aware of the status of several bugs, so may I add myself to the CC list? Or is it supposed to be used only by the fixers? Best regards Piotr Wyderski
Re: Bugzilla and setting priorities
Paolo Carlini wrote: Thus, what's the point of submitter fiddling with those Bugzilla fields? Putting some sort of psychological pressure on people actually working on fixing the bugs? Well, that's true when it comes to high priorities, but the submitter should have the opportunity to specify lower priorities. For instance a typo is a bug which should be fixed, but certainly it isn't a showstopper, so it doesn't deserve to be classified as a normal priority report. submitters should essentially add to the audit trail or close bugs which cannot be reproduced anymore (maybe) very little else. Submitters should not be allowed to close bug reports themselves, otherwise it will wreak havoc. They should explain the reasons and ask somebody with sufficient credentials to do it on their behalf. Last, but not least, I wolud like to apologise you and Dave for unnecessary investigation of the first part of PR42880, which was obviously my fault. Best regards Piotr Wyderski
strict aliasing violation
I have a hash function hash(T v) overloaded for
all integral types. I want to provide a variant for
float and double, which should work as follows:
take the floating-point value, treat its binary
representation as uint32_t/uint64_t and use
the result as a parameter for an integral hash().
However, GCC warns me about strict aliasing
rules violation, which is technically correct, but
in this case is intended. How do I perform this
conversion ina GCC-friendly way? Even that
produces a warning:
inline hash_type hash(float v) {
return hash(*reinterpret_castconst
std::uint32_t*(reinterpret_castconst char*(v)));
}
but I expected char* to be allowed to alias anything.
Best regards
Piotr Wyderski
Re: strict aliasing violation
Andrew Haley wrote:
union { float f; uint32 i; } u = {.f = v};
return u.i;
Nope, that is not allowed either.
Of course it is allowed. It's a legitimate gcc extension, and it's
supported by many other compilers too.
It's a C extension, according to the documentation.
In C++ mode (-std=gnu++0x) the compiler does not
understand the u = {.f = v} statement. Is it a feature
or a bug? ;-)
Best regards
Piotr Wyderski
printf enhancement
Since it is possible to use the 0b prefix to specify a binary number in GCC/C++, will there be any resistance to add %b format specifier to the printf family format strings? Best regards Piotr Wyderski
Re: printf enhancement
Paolo Carlini wrote: This has absolutely nothing to do with GCC and its development, you understand. You sure? Isn't the implementation of printf formatting engine a part of GCC support libraries and doesn't adding an extension to it belong to the category development?
Re: printf enhancement
Paolo Carlini wrote: The C library, to which library printf belongs, is not part of the GCC project. In that case it certainly isn't a GCC issue.
GCC development plan
Hello, is there something like an unofficial documentation of trunk features or a more or less detailed development plan of the compiler? What I'm trying to say... how do you know what to work on and what are schedules? I'm particularly interested in C++0x, SIMDs and optimization plans. Best regards Piotr Wyderski
Re: GCC development plan
Tobias Burnus wrote: Well, for the new features in the trunk: Have a look at the release notes for the upcoming version 4.5 at http://gcc.gnu.org/gcc-4.5/changes.html For C++ 0x (1x?) have also a look at http://gcc.gnu.org/gcc-4.5/cxx0x_status.html Yes, I know those pages pretty well, as I check the C++0x implementation progress every other week. But, from the perspective of trunk, they describe what has already been done and I'm using that features happily. Of course I realize that there is no strict plan, as it is an Open Source project run by volunteers. I would like to know what is in progress or planned /speculated to be, but failed to find that information. The person who maintains the mentioned sites somehow knows what is going on under the hood, so I wonder whether that information is available to mere mortals, and -- if yes -- then how. No - there might be some (tentative) plan for some parts of the compiler and ideas what should implemented first That would be more than enough, but where can I find that? I read this list rather carefully, however not much information of that kind is disclosed here. Best regards Piotr Wyderski
Missing optimizations
on GCC-trunk/Cygwin/Core2 I observe the following behaviour.
g++ -std=gnu++0x -O2 -m32 -march=native -msse -msse2 -msse3 -Wall
-Werror -Wno-unused -Wno-strict-aliasing -march=native
-fomit-frame-pointer -Wno-pmf-conversions -g main.cpp
---8--
#include x86intrin.h
int test1(__m128i v) {
return _mm_cvtsi128_si32(v);
}
---8--
emits:
004012e0 __Z5test1U8__vectorx:
4012e0: 83 ec 0csub$0xc,%esp
4012e3: 66 0f 7e c0 movd %xmm0,%eax
4012e7: 83 c4 0cadd$0xc,%esp
4012ea: c3 ret
which shows that the stack pointer is being updated
without any purpose.
GCC also happens to lose the consition codes,
as shown here:
4011a0: 66 0f df 01 pandn (%ecx),%xmm0
4011a4: 39 d9 cmp%ebx,%ecx
4011a6: 66 0f 7f 0c 24 movdqa %xmm1,(%esp)
4011ab: 75 04 jne4011b1
__Z8popcountPKU8__vectorxjj+0x61
4011ad: 66 0f db c1 pand %xmm1,%xmm0
4011b1: 66 0f 6f 1d 90 28 40movdqa 0x402890,%xmm3
4011b8: 00
4011b9: 66 0f 6f 15 a0 28 40movdqa 0x4028a0,%xmm2
4011c0: 00
4011c1: 66 0f 6f f3 movdqa %xmm3,%xmm6
4011c5: 66 0f 6f fb movdqa %xmm3,%xmm7
4011c9: 66 0f db f0 pand %xmm0,%xmm6
4011cd: 66 0f df f8 pandn %xmm0,%xmm7
4011d1: 66 0f 6f ca movdqa %xmm2,%xmm1
4011d5: 66 0f 6f c7 movdqa %xmm7,%xmm0
4011d9: 66 0f 38 00 ce pshufb %xmm6,%xmm1
4011de: 66 0f 71 d0 04 psrlw $0x4,%xmm0
4011e3: 66 0f 6f f1 movdqa %xmm1,%xmm6
4011e7: 66 0f 6f fa movdqa %xmm2,%xmm7
4011eb: 39 d9 cmp%ebx,%ecx
4011ed: 66 0f 38 00 f8 pshufb %xmm0,%xmm7
4011f2: 66 0f fc f7 paddb %xmm7,%xmm6
4011f6: 66 0f ef ff pxor %xmm7,%xmm7
4011fa: 66 0f f6 f7 psadbw %xmm7,%xmm6
4011fe: 0f 84 be 00 00 00 je 4012c2
__Z8popcountPKU8__vectorxjj+0x172
The second cmp is superfluous, as the SSE instructions in between
do not modify CC.
Are these known issues?
Best regards
Piotr Wyderski
Re: Exception object access
Jonathan Wakely wrote:
Do you mean like std::current_exception(), available in c++0x mode?
No, the main purpose of std::exception_ptr is to allow
passing exceptions between threads, but it is pretty
useless if it comes to reasoning about the exception
itself (i.e. it's not dereferencable). What I mean is the
exception value itself, for example:
throw std::error(bug);
it will be a pointer to the std::error instance. But I was
partly wrong, the __cxa* functions are exported from
libstdc++, but in extern C mode. Now I have full access
to the __cxa_exception structure:
struct __cxa_exception {
std::type_info* exceptionType;
void (*exceptionDestructor) (void *);
std::unexpected_handler unexpectedHandler;
std::terminate_handler terminateHandler;
__cxa_exception*nextException;
int handlerCount;
int handlerSwitchValue;
const char* actionRecord;
const char* languageSpecificData;
void* catchTemp;
void* adjustedPtr;
_Unwind_Exception unwindHeader;
};
But a question arises: may I assume that the adjustedPtr
field is always correctly filled by the compiler in contexts like this:
void remap_exception() {
__cxa_eh_globals* const pEHGlobals = __cxa_get_globals();
__cxa_exception* const pEHDescriptor = pEHGlobals-caughtExceptions;
try {
throw;
} catch(...) {
auto p = pEHDescriptor-adjustedPtr;
// HERE
}
}
?
The ABI specification says that __cxa_get_exception_ptr()
should be called in order to get the unwrapped object, but
when explicitly called, it returns null. On the other hand it
says that catches emit a call to this function together with
__cxa_begin_catch() and store the value in the current
__cxa_exception instance. So the answer to my question
should be yes, the value of adjustedPtr is correct, but
it's better to ask in order to be sure.
Best regards
Piotr Wyderski
Exception object access
Hello, Is the a way to get access to the currently thrown C++ exception object? cxxabi.h gives me only access to its std::type_info via __cxa_current_exception_type(). On the other hand, the ABI documentation describes the struct __cxa_exception, but it is not accessible via cxxabi.h. Additionally, the function __cxa_get_globals() seems not to be is not exported by the runtime. Best regards Piotr Wyderski
Re: Bug in GCC 4.5 c++0x version of std::listT::merge()?
Benjamin Redelings wrote: since lvalues no longer bind to rvalue references When has it changed? Could you please give a reference to some paper/discussion about it? I'm asking, because my C++0x-based application stopped to compile on newer 4.5-s and one of the problems is mentioned above -- but I thought that it was a GCC issue, not a change in the Standard. Best regards Piotr Wyderski
ICE on unique_ptr
GCC-4.5-trunk/Cygwin ICEs in the following way: /opt/gcc-trunk/lib/gcc/i686-pc-cygwin/4.5.0/include/c++/bits/unique_ptr.h:233:5: internal compiler error: in finish_member_declaration, at cp/semantics.c:2416 I can't provide a testcase. Best regards Piotr Wyderski
Re: [C++0x]: non-public defaulted copy c-tor
Jonathan Wakely wrote:
It's under discussion
That's certainly a good news. Anyway, I'll wait
with porting my framework to the newest GCC,
until this issue is settled, as:
a) = default works as I expect on gcc 4.5-20090604
and maybe it will still do in the future;
b) gcc 4.5-20091119 reports so many ICEs it is almost
useless;
c) it seems to have problems with overload resolution.
I wanted lambdas, but it can wait -- the top of my
wish list, i.e. constructor inheritance/delegation is
not implemented yet anyway.
but relax, notice it says If it is explicitly
defaulted on its first declaration,
[...]
inline Base::Base() = default;
inline Base::~Base() = default;
Of course, I tried that and it works to some
extent, as on 20090604 defaulted virtual
destructors are not DLL-exported for some
reasons, but their {} counterparts are).
The point is that the only reason to have
defaulted functions is to provide comprehensive
syntax for obvious things. However:
inline Base::Base() {};
inline Base::~Base() {};
is even shorter than the defaulted version, not to mention:
class Base {
protected:
Base() {};
virtual ~Base() {};
};
which is the reason I dare to say the crippled version is useless.
What is the point of doing simple things in a complex way?
Best regards
Piotr Wyderski
Trunk fixes
Trunk 154492 is uncompilable on Cygwin because
of incorrect data types in LTO. It compiles with the
attached fixes, but I have no write access to the
repository. Could someone please apply them?
Best regards
Piotr Wyderski
Index: gcc/lto-streamer-out.c
===
--- gcc/lto-streamer-out.c (revision 154492)
+++ gcc/lto-streamer-out.c (working copy)
@@ -86,7 +86,7 @@
/* Free the string slot pointed-to by P. */
-static void
+static void
string_slot_free (void *p)
{
struct string_slot *slot = (struct string_slot *) p;
@@ -365,7 +365,7 @@
{
unsigned i;
REAL_VALUE_TYPE r;
-
+
r = TREE_REAL_CST (expr);
bp_pack_value (bp, r.cl, 2);
bp_pack_value (bp, r.decimal, 1);
@@ -758,7 +758,7 @@
lto_output_chain (struct output_block *ob, tree t, bool ref_p)
{
int i, count;
-
+
count = list_length (t);
output_sleb128 (ob, count);
for (i = 0; i count; i++)
@@ -1612,7 +1612,7 @@
output_phi (struct output_block *ob, gimple phi)
{
unsigned i, len = gimple_phi_num_args (phi);
-
+
output_record_start (ob, lto_gimple_code_to_tag (GIMPLE_PHI));
output_uleb128 (ob, SSA_NAME_VERSION (PHI_RESULT (phi)));
@@ -1732,7 +1732,7 @@
gimple stmt = gsi_stmt (bsi);
output_gimple_stmt (ob, stmt);
-
+
/* Emit the EH region holding STMT. */
region = lookup_stmt_eh_lp_fn (fn, stmt);
if (region != 0)
@@ -1785,14 +1785,14 @@
/* The entire header is stream computed here. */
memset (header, 0, sizeof (struct lto_function_header));
-
+
/* Write the header. */
header.lto_header.major_version = LTO_major_version;
header.lto_header.minor_version = LTO_minor_version;
header.lto_header.section_type = section_type;
-
+
header.compressed_size = 0;
-
+
if (section_type == LTO_section_function_body)
header.cfg_size = ob-cfg_stream-total_size;
header.main_size = ob-main_stream-total_size;
@@ -2037,7 +2037,7 @@
VEC_safe_push (tree, heap, encoder-trees, trees[j]);
encoder-next_index = n;
}
-
+
lto_free_section_data (file_data, LTO_section_function_body, name,
data, len);
free (output_stream);
@@ -2122,7 +2122,7 @@
};
-/* Write each node in encoded by ENCODER to OB, as well as those reachable
+/* Write each node in encoded by ENCODER to OB, as well as those reachable
from it and required for correct representation of its semantics.
Each node in ENCODER must be a global declaration or a type. A node
is written only once, even if it appears multiple times in the
@@ -2230,7 +2230,7 @@
unsigned i;
int32_t ref;
tree decl;
-
+
/* Write reference to FUNCTION_DECL. If there is not function,
write reference to void_type_node. */
decl = (state-fn_decl) ? state-fn_decl : void_type_node;
@@ -2280,7 +2280,7 @@
const char *name;
enum gcc_plugin_symbol_kind kind;
enum gcc_plugin_symbol_visibility visibility;
- int slot_num;
+ int32_t slot_num;
uint64_t size;
const char *comdat;
@@ -2442,7 +2442,7 @@
needed. */
output_unreferenced_globals (set);
- memset (header, 0, sizeof (struct lto_decl_header));
+ memset (header, 0, sizeof (struct lto_decl_header));
section_name = lto_get_section_name (LTO_section_decls, NULL);
lto_begin_section (section_name, !flag_wpa);
@@ -2488,7 +2488,7 @@
lto_output_data_stream (header_stream, header, sizeof header);
lto_write_stream (header_stream);
free (header_stream);
-
+
/* Write the main out-decl state, followed by out-decl states of
functions. */
decl_state_stream = ((struct lto_output_stream *)
@@ -2504,7 +2504,7 @@
lto_output_decl_state_refs (ob, decl_state_stream, fn_out_state);
}
lto_write_stream (decl_state_stream);
- free(decl_state_stream);
+ free(decl_state_stream);
lto_write_stream (ob-main_stream);
lto_write_stream (ob-string_stream);
Index: gcc/lto-streamer-in.c
===
--- gcc/lto-streamer-in.c (revision 154492)
+++ gcc/lto-streamer-in.c (working copy)
@@ -140,7 +140,7 @@
unsigned int len;
unsigned int loc;
const char *result;
-
+
loc = lto_input_uleb128 (ib);
LTO_INIT_INPUT_BLOCK (str_tab, data_in-strings, loc, data_in-strings_len);
len = lto_input_uleb128 (str_tab);
@@ -148,7 +148,7 @@
if (str_tab.p + len data_in-strings_len)
internal_error (bytecode stream: string too long for the string table);
-
+
result = (const char *)(data_in-strings + str_tab.p);
return result;
@@ -220,7 +220,7 @@
{
enum LTO_tags tag = (enum LTO_tags) lto_input_uleb128 (ib);
return tag;
-}
+}
/* Lookup STRING in file_name_hash_table. If found, return the existing
@@ -311,7 +311,7 @@
function scope for the read tree. */
static tree
-lto_input_tree_ref (struct lto_input_block *ib, struct
[C++0x]: non-public defaulted copy c-tor
After upgrade to trunk-20091124:
class C {
protected:
C(const C) = default;
};
main.cpp:1506:23: error: 'C::C(const C)' declared with non-public access cannot
be defaulted in the class body
But I can't find anything about it in the N3000 draft.
Should I file a GCC bug report or adjust my code?
Best regards
Piotr Wyderski
Re: [C++0x]: non-public defaulted copy c-tor
Jonathan Wakely wrote:
This is DR906
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#906
Thanks.
Note it shall be public
And what's the reason for such restrictions?
I've used the following construction as a very
useful idiom to create an abstract class:
class Base {
protected:
Base() = default;
virtual ~Base() = default;
};
class Derived : public Base {
public:
Derived() { ... }
virtual ~Derived() { ... }
};
Clean, simple and GCC used to happily accept that.
But now it is illegal because of 3 draft violations:
Base() shall be public, but is not
~Base() shall be public, but is not
~Base() shall not be virtual, but it is
IMHO this severely cripples defaulted functions,
making them almost useless -- the set of allowed
cases is too narrow. Is there any chance to fix the DR?
Best regards
Piotr Wyderski
Re: GCC 4.5 is uncompilable
Dave Korn wrote: If that doesn't fix it please let me know. The solution was correct, with binutils 2.20 the problem disappeared. There is another one, however on the snapshot 20091119: ../../gcc/lto-streamer-out.c: In function 'write_global_references': ../../gcc/lto-streamer-out.c:2201:7: error: passing argument 3 of 'lto_streamer_ cache_lookup' from incompatible pointer type ../../gcc/lto-streamer.h:790:13: note: expected 'int *' but argument is of type 'int32_t *' which is a source code bug: a local variable ref of type int32_t is passed by pointer to a function which takes int*. Don't know about trunk, as I just started building it. Best regards Piotr Wyderski
GCC 4.5 is uncompilable
An attempt to build either gcc-trunk or the most recent snapshot (20091119) with Cygwin (the build compiler is either GCC 4.4.0 or 4.5-20090604), configured as: $ ../configure --prefix=/opt/gcc-4.5-20091119 -v --enable-bootstrap --enable-ve rsion-specific-runtime-libs --enable-shared --enable-shared-libgcc --with-gnu-l d --with-gnu-as --enable-dwarf2-exceptions --disable-symvers --disable-nls --wi th-arch=core2 --with-tune=generic --enable-threads=posix --enable-languages=c,c ++ fails with the following message: [...] mv ./shlib/libgcc_s.dll.a.tmp ./shlib/libgcc_s.dll.a /usr/bin/ld: unrecognized -a option `ware' collect2: ld returned 1 exit status make[3]: *** [libgcc_s.dll] Error 1 make[3]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir/i 686-pc-cygwin/libgcc' make[2]: *** [all-stage1-target-libgcc] Error 2 make[2]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/home/piotr.wyderski/build/gcc-4.5-20091119/objdir' make: *** [all] Error 2
Re: GCC 4.5 is uncompilable
Kai Tietz wrote: This error you get is more related to used binutils version.The warning you get looks more like a cripled '-Wl,--tsaware'. Thanks, that looks like a good explanation. Which binutils version you are using? $ ld -v GNU ld (GNU Binutils) 2.18.50.20080625 I'll try to upgrade binutils and then repeat the build process. Best regards Piotr Wyderski
SIGILL on Sparc
Hello, I have a problem with a (big) C++ program compiled with gcc 4.4.0 on a 64-bit Sparc. Target: sparc-sun-solaris2.10 Configured with: /opt/sources/gnu/gcc-4.4.0/configure --prefix=/opt/gnu/gcc-4.4.0 --with-local-prefix=/opt/gnu/gcc-4.4.0 --enable-threads=posix --with-cpu=ultrasparc3 --enable-tls=yes --with-tune=ultrasparc3 --enable-languages=c,c++ --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --with-gmp=/opt/gnu/gmp-4.2.1 --with-mpfr=/opt/gnu/mpfr-2.4.1 --disable-nls Thread model: posix gcc version 4.4.0 (GCC) The compiler generated the following code (debug version): 0x751407b4 Functions+204: nop 0x751407b8 Functions+208: ldx [ %fp + 0x87f ], %o0 0x751407bc Functions+212: clr %o1 0x751407c0 Functions+216: call 0x7543bc00 _zn6parser8internal9functions11setcategoryens0_11eh_catego...@plt 0x751407c4 Functions+220: nop 0x751407c8 Functions+224: ta 5 === Here the SIGILL happens The function SetCategory(v) returns void and simply assigns the value of v to a class member, so there are no trap conditions. TA, on the other hand, stands for trap always, so the condition code is unimportant anyway. Why has the trap instruction been generated? Best regards Piotr Wyderski
Re: SIGILL on Sparc
Paolo Bonzini wrote: Usually this is because you have code with undefined behavior, that the compiler cannot make sense of. Yes, you were right, that was the case indeed. Thank you Paulo. Best regards Piotr Wyderski
The future of concepts
Concepts have recently been removed from the C++0x Standard Draft. Will the concepts branch be discontinued?
Auto-import problem
Trying to work-around PR40269 (which doesn't happen anymore on trunk, so you may close it) I've commented out the dllexport/dllimport section: #define BASE_DLLEXPORT /*__declspec(dllexport)*/ #define BASE_DLLIMPORT /*__declspec(dllimport)*/ Then the program compiled successfully, emitting a lot of auto-import warning messages, but crashed unexpectedly somewhere in the middle of execution. If these __declspecs are uncommented, then it works correctly, as expected. Is it a known auto-import bug or feature I should be aware of, or should I dig deeper into the subject and ask out a debbugger for a passionate afternoon session? Best regards Piotr Wyderski
std::exception_ptr on Cygwin
It is impossible to use std::exception_ptr and related functionality on Cygwin in C++0x mode, despite the fact the necessary classes seem to be implemented. That is because in exception there is a conditional block: #if (defined(__GXX_EXPERIMENTAL_CXX0X__) \ defined(_GLIBCXX_ATOMIC_BUILTINS_4)) #include exception_ptr.h #endif The macro __GXX_EXPERIMENTAL_CXX0X__ is defined correctly, as expected, but _GLIBCXX_ATOMIC_BUILTINS_4 is not, as Cygwin does not use glibc. Its underlying processor architecture, however, supports the fullest set of atomic primitives, so is there really a need to make it glibc-dependent? If I enforce the macro definition from the command line, then the exception_ptr -dependent code compiles correctly (but does not link because of undefined reference to `std::__exception_ptr::exception_ptr::~exception_ptr() and the other non-inline members. I presume it is not the recommended way. Best regards Piotr Wyderski
Re: std::exception_ptr on Cygwin
Andrew Pinski wrote: i386 did not have atomic locks at all but 486 and above does. Thanks, now it is obvious to me. So how should I configure my GCC-trunk build? It seems that --with-cpu is not enough: $ gcc -v Using built-in specs. Target: i686-pc-cygwin Configured with: ../configure --prefix=/opt/gcc-4.5-trunk -v --enable-bootstrap --enable-version-specific-runtime-libs --enable-static --enable-shared --enable- shared-libgcc --with-gnu-ld --with-gnu-as --enable-sjlj-exceptions --enable-lang uages=c,c++ --disable-symvers --enable-libjava --disable-nls --with-cpu=core2 -- enable-threads=posix Best regards Piotr Wyderski
Bugfix request
Hello,
I would like to kindly ask somebody to fix PR38064,
as the bug is very annoying -- it makes the use of
enum class virtually impossible. Most of my GCCBUG
workaround comments refer to this one.
For a quick reference:
enum class E { elem };
int main()
{
E e = E::elem;
if (e == E::elem);
return 1;
}
g++ -std=c++0x tc1.cpp
tc1.cpp: In function 'int main()':
tc1.cpp:6: error: invalid operands of types 'E' and 'E' to binary 'operator=='
Best regards
Piotr Wyderski
C++0x feature release plan
Could you please make a rough guess and specify when a preliminary implementation of these C++0x features can be expected to appear GCC4.5? - concepts - constructor inheritance - constructor delegation Is there a document which describes what are you working on now? I'm just curious :-) Best regards Piotr Wyderski
[C++] Inheritance chain enumeration
Consider a class hierarchy with single inheritance, as follows:
struct A {
virtual ~A() = default;
}
struct B : public A {
virtual ~B() = default;
};
and
A* p = new B();
then how can I get the type_info object of the base class of B?
Or, in other words, how do I enumerate the chain of base classes
starting with a pointer to an object? Of course I mean a GCC-internals
-aware way. The following short document:
http://www.codesourcery.com/public/cxx-abi/abi.html#rtti
says that
For similar reasons, we only keep direct base information about
a class type. Indirect base information can be found by chasing
type_info pointers (and care should be taken to determine
ambiguous base class types).
Namely, where do you keep the direct base information about
a class type and what data structures from libstdc++ should I
become familiar with? And the last question: is the format
expected to stable in terms of GCC development?
Best regards
Piotr Wyderski
Re: [C++] Inheritance chain enumeration
Dave Korn wrote: To find the base classes, look at the typeinfo for the class, which will be abi::__class_type_info or one of its derivatives as specified in the ABI doc It should be __si_class_type_info in my case. Beautiful! Many thanks Dave :-) BTW, how do you know what derivate is pointed to by a pointer during RTTI processing, especially in the context of exception handling? Is there a type_info for type_info, e.g. an enum? Best regards Piotr Wyderski
EH tree is invalid
On gcc-trunk my project fails with the following ICE. Whatever it means... /home/piotr.wyderski/topnotch/vm/test/main.cpp: In function 'int main(int, char**)': /home/piotr.wyderski/topnotch/vm/test/main.cpp:32: error: Wrong prev_try pointer in EH region 123 Eh tree: 100 catch tree_label:L141 may_contain_throw prev: 97 type: 102 must_not_throw tree_label:L143 may_contain_throw 101 cleanup tree_label:L142 may_contain_throw 97 catch tree_label:L137 may_contain_throw prev: 94 next 100 type:struct exception 99 must_not_throw tree_label:L139 may_contain_throw 98 cleanup tree_label:L138 may_contain_throw 94 catch tree_label:L134 may_contain_throw next 97 type:struct rc_ptr 96 must_not_throw tree_label:L136 may_contain_throw 95 cleanup tree_label:L135 may_contain_throw 1 try may_contain_throw catch regions: 94 97 100 93 must_not_throw tree_label:L132 may_contain_throw 2 cleanup tree_label:L131 may_contain_throw prev try:1 92 must_not_throw tree_label:L129 may_contain_throw 3 cleanup tree_label:L128 may_contain_throw prev try:1 91 must_not_throw tree_label:L126 may_contain_throw 4 cleanup tree_label:L125 may_contain_throw prev try:1 90 must_not_throw tree_label:L123 may_contain_throw 5 cleanup tree_label:L122 may_contain_throw prev try:1 89 must_not_throw tree_label:L120 may_contain_throw 6 cleanup tree_label:L119 may_contain_throw prev try:1 88 must_not_throw tree_label:L117 may_contain_throw 7 cleanup tree_label:L116 may_contain_throw prev try:1 87 must_not_throw tree_label:L114 may_contain_throw 8 cleanup tree_label:L113 may_contain_throw prev try:1 86 must_not_throw tree_label:L111 may_contain_throw 9 cleanup tree_label:L110 may_contain_throw prev try:1 85 must_not_throw tree_label:L108 may_contain_throw 10 cleanup tree_label:L107 may_contain_throw prev try:1 84 must_not_throw tree_label:L105 may_contain_throw 11 cleanup tree_label:L104 may_contain_throw prev try:1 83 must_not_throw tree_label:L102 may_contain_throw 34 cleanup tree_label:L101 may_contain_throw prev try:1 82 must_not_throw tree_label:L99 may_contain_throw 37 cleanup tree_label:L98 may_contain_throw prev try:1 81 must_not_throw tree_label:L96 may_contain_throw 40 cleanup tree_label:L95 may_contain_throw prev try:1 80 must_not_throw tree_label:L93 may_contain_throw 43 cleanup tree_label:L92 may_contain_throw prev try:1 79 must_not_throw tree_label:L90 may_contain_throw 46 cleanup tree_label:L89 may_contain_throw prev try:1 78 must_not_throw tree_label:L87 may_contain_throw 49 cleanup tree_label:L86 may_contain_throw prev try:1 77 must_not_throw tree_label:L84 may_contain_throw 52 cleanup tree_label:L83 may_contain_throw prev try:1 76 must_not_throw tree_label:L81 may_contain_throw 55 cleanup tree_label:L80 may_contain_throw prev try:1 75 must_not_throw 56 cleanup tree_label:L78 may_contain_throw prev try:1 74 must_not_throw tree_label:L76 may_contain_throw 57 cleanup tree_label:L75 may_contain_throw prev try:1 73 must_not_throw tree_label:L73 may_contain_throw 58 cleanup tree_label:L72 may_contain_throw prev try:1 72 must_not_throw tree_label:L70 may_contain_throw 59 cleanup tree_label:L69 may_contain_throw prev try:1 71 must_not_throw tree_label:L67 may_contain_throw 60 cleanup tree_label:L66 may_contain_throw prev try:1 70 must_not_throw tree_label:L64 may_contain_throw 61 cleanup tree_label:L63 may_contain_throw prev try:1 69 must_not_throw tree_label:L61 may_contain_throw 62 cleanup tree_label:L60 may_contain_throw prev try:1
Re: EH tree is invalid
Richard Guenther wrote: Please file a bugreport in bugzilla and attach preprocessed source. Impossible, the source code is proprietary. But perhaps I can try to prepare a simplified testcase though... Best regards Piotr Wyderski
Re: EH tree is invalid
Dave Korn wrote: Are you using SJLJ or DW2 exceptions? SJLJ only -- DW2 doesn't work on Windows if the exception handling scope crosses DLL boundaries. If SJLJ, does the patch at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg01628.html help the problem? Hm, it seems that rev 146517 does not build on Cygwin, so I am unable to check it right now. But I'll try the patch ASAB (as soon as buildable :D) make[3]: Entering directory `/home/piotr.wyderski/build/gcc-trunk/objdir/gcc' /home/piotr.wyderski/build/gcc-trunk/objdir/./prev-gcc/xgcc -B/home/piotr.wyders ki/build/gcc-trunk/objdir/./prev-gcc/ -B/opt/gcc-4.5-trunk/i686-pc-cygwin/bin/ - c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prot otypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribut e -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc -I../../gcc/. -I../../gcc/../in clude -I../../gcc/../libcpp/include -I../../gcc/../libdecnumber -I../../gcc/../ libdecnumber/dpd -I../libdecnumber../../gcc/sdbout.c -o sdbout.o cc1: warnings being treated as errors ../../gcc/sdbout.c: In function 'sdbout_symbol': ../../gcc/sdbout.c:773: error: enum conversion when passing argument 2 of 'elimi nate_regs' is invalid in C++ ../../gcc/reload.h:346: note: expected 'enum machine_mode' but argument is of ty pe 'int' ../../gcc/sdbout.c: In function 'sdbout_parms': ../../gcc/sdbout.c:1274: error: enum conversion when passing argument 2 of 'elim inate_regs' is invalid in C++ ../../gcc/reload.h:346: note: expected 'enum machine_mode' but argument is of ty pe 'int' Best regards Piotr Wyderski
Re: gcc-4.5-20090402 is now available
Snapshot gcc-4.5-20090402 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090402/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. When building on Cygwin/WinXP configured as: $ ../configure --prefix=/opt/gcc-4.5-20090402 -v --enable-bootstrap --enable-ve rsion-specific-runtime-libs --enable-static --enable-shared --enable-shared-lib gcc --with-gnu-ld --with-gnu-as --enable-sjlj-exceptions --enable-languages=c,c ++ --disable-symvers --enable-libjava --disable-nls --with-cpu=core2 --enable-t hreads=posix results in: In file included from /home/piotr.wyderski/build/gcc-4.5-20090402/libstdc++-v3/i nclude/precompiled/extc++.h:59: /home/piotr.wyderski/build/gcc-4.5-20090402/objdir/i686-pc-cygwin/libstdc++-v3/i nclude/ext/throw_allocator.h: In function 'std::ostream __gnu_cxx::operator(s td::ostream, const __gnu_cxx::throw_allocator_base)': /home/piotr.wyderski/build/gcc-4.5-20090402/objdir/i686-pc-cygwin/libstdc++-v3/i nclude/ext/throw_allocator.h:289: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Exactly the same happens on trunk. Best regards Piotr Wyderski
Re: GCC 4.4 is not able to build itself under Cygwin
Dave Korn wrote: Gah, yes of course, you showed the config in your first post. Well, that's the problem. Confirmed, with --enable-threads=posix the compiler builds correctly. Best regards, Piotr
GCC-only software
Hi, Quite a long time ago I have decided to use GCC as the only compiler for my C++* applications (mostly heavy-duty high volume data stream processing). There are many reasons, but the most important are listed below: 1. A GCC port is available for every platform I am interested in; 2. It is impossible to maintain portability between compilers of differerent vendors at the language feature level I am used to. Otherwise I would either need to select the lowest common denominator supported language subset or raise a heavy #ifdef orgy in my code. None of them is an option. 3. GCC has a lot of extremely useful extensions and ingenious integration with inline assembly. The compiler's abilities are very weak if it comes to autovectorization, but it at least seamlessly allows me to do things right manually -- a vital feature. 4. I need as much C++0x features as possible. Even the experimental support in GCC 4.x dramatically improved the quality of my code. It is also the reason I use gcc-trunk as the development platform. Having said that, I wonder what else can I win by sticking to the GNU compiler as closely as possible. There is a lot of officially documented extensions (computed gotos, attributes, PMF conversions etc.) I am aware of (and I continuously monitor the list), but the purpose of this mail is a kind request to shed some light on the grey zone. Could you please point me the under the hood features you think may be interesting for me? I mean (presumming that there are) the extended type info, class layout description (e.g. in order to implement reflections and GC), the __cxa* function ZOO, stable compiler-wide assumptions in the places where the language standard is unclear or anything like that. A reference to their documentation will be appreciated. Best regards, Piotr Wyderski *) Or, I should say G++0x...
Re: GCC-only software
Manuel López-Ibáñez wrote: Anyway, the documentation is there http://gcc.gnu.org/onlinedocs/ Yes, this is the official documentation I read frequently. Anything not documented there is likely to change or be removed in the future, so you should not rely on it. I can afford the process of perpetual adjustment in the critical parts :-) On the other hand, if you find some behaviour that you feel should be documented and it is not, please submit a documentation patch (or at least open a bug report). Well, the problem is that I don't know where to find the unofficial documentation, so it is hard to figure out the questions to be asked. I would not recommend relying on trunk (specially not during stages 1 or 2) for production code. Certainly. But for development it is perfectly acceptable. Best regards, Piotr
GCC 4.4 is not able to build itself under Cygwin
This build problem has been occuring for at least a month,
both on the most recent snapshots and on trunk.
The compiler is configured as follows:
../configure --prefix=/opt/gcc-4.4.0-20090227 -v --enable-bootstrap
--enable-version-specific-runtime-libs --enable-static --enable-shared
--enable-shared-libgcc --with-gnu-ld --with-gnu-as --enable-sjlj-exceptions
--enable-languages=c,c++ --disable-symvers --enable-libjava --disable-nls
--with-cpu-32=core2 --with-cpu-64=core2 --enable-threads=win32
There are actually two problems in libstdc++. The first one is is caused
by the existence of the min/max macros, injected by windows.h.
make CCXFLAGS=-DNOMINMAX
solves the issue. The next one is more serious. The file gthr-default.h,
line 620 contains the macro
#define CONST_CAST2(TOTYPE,FROMTYPE,X) ((__extension__(union {FROMTYPE
_q; TOTYPE _nq;})(X))._nq)
but the compiler claims that it is not allowed to declare a type within a cast.
I've temporarily replaced it with
#define CONST_CAST2(TOTYPE,FROMTYPE,X) ((TOTYPE)(X))
and that solved the issue, however, a cleaner patch should be applied.
Best regards,
Piotr Wyderski
Re: GCC 4.4 is not able to build itself under Cygwin
Richard Guenther wrote: Where is windows.h included? I am not 100% sure yet -- the build process is in progress right now, so I don't want to interfere. I suspect it is the one included by gthr-win32.h. It contains the following lines: #include windows.h /* Now undef the windows BOOL. */ #undef BOOL so I think that adding #undef MIN #undef MAX will solve the situation, but, as I said, I am not completely sure it's the troublemaker. Firstly I would like to check whether those are the only two bugs to be fixed. Additionally, I have no write access to trunk (or anything else in the tree), so somebody else should include the fix. During what part of compilation is CONST_CAST2 a problem? Stage 3 in libstdc++ Richard. Best regards, Piotr Wyderski
C++ constant expressions in __attribute__
Hello,
Is it possible to allow C++ constant expressions (currently static const,
and C++0x constexpr in the future) to be used as __attribute__ parameters
in the upcomming version of GCC? In my code I have the following construction:
namespace simd {
static const std::size_t vector_size = 16U;
};
but cannot use it in order to declare a variable like this:
std::uint8_t v[128] __attribute__((__aligned__(simd::vector_size)));
because GCC (4.4.0 snapshot from the end of January, x86/Cygwin)
complains that:
error: expected ')' before '::' token
rewritten to:
static const std::size_t len = 16;
std::uint8_t v[128] __attribute__((__aligned__(len)));
results in:
error: requested alignment is not a constant
One needs to introduce a preprocessor macro SIMD_VECTOR_SIZE
just in order to fix this particular issue.
Best regards
Piotr Wyderski
Re: C++ constant expressions in __attribute__
H.J. Lu wrote:
You can use __BIGGEST_ALIGNMENT__ for that purpose.
Yes, _for that purpose_ it works perfectly. However, I would
also like be able to align fields to cache line size. I have a set
of C++ template cache geometry descriptors which provide
a constant by the name of line_size:
namespace cache {
template std::size_t N_level class geometry;
// ---
template class geometry1 : private nonconstructible {
// Superclass
typedef nonconstructible super;
public:
static const std::size_t capacity = 32 * 1024;
static const std::size_t associativity = 8;
static const std::size_t line_size = 64;
};
// ---
template class geometry2 : private nonconstructible {
// Superclass
typedef nonconstructible super;
public:
static const std::size_t capacity = 3 * 1024 * 1024;
static const std::size_t associativity = 12;
static const std::size_t line_size = 64;
};
}
I would like to declare a level 1 data cache line size-aligned variable x:
int x __attribute__((__aligned__(cache::geometry1::line_size)));
which is not possible now. BTW, since GCC has -mtune=native, it
would be great to have a compiler-provided cache info in the form
of a bunch of target-dependent preprocessor definitions, e.g. for Core2:
__GCC_DCACHE_LEVELS 2
__GCC_ICACHE_LEVELS 2
__GCC_DCACHE_LINE_SIZE1 64
__GCC_DCACHE_LINE_SIZE2 64
__GCC_DCACHE_ASSOCIATIVITY1 8
__GCC_DCACHE_ASSOCIATIVITY2 12
etc. It would help in a lot of cases, e.g. lock-free algorithms, false
sharing avoidance, alignment calculations in custom allocators etc.
Best regards,
Piotr Wyderski
virtual destructors and operator delete
Hi,
I have an auto-duration only class X in C++0x:
class X {
void* operator new(std::size_t) = delete;
void operator delete(void*) = delete;
public:
virtual ~X() {}
};
But GCC 4.4 fails to compile it:
main.cpp: In destructor 'virtual X::~X()':
main.cpp:4140: error: deleted function 'static void X::operator delete(void*)'
main.cpp:4144: error: used here
Is it a bug? If not, then why is it needed?
I have a similar example with a missing unneeded copy constructor.
Best regards, Piotr
Stack traces and sections in PE/COFF
I would like to add stack traces to my program (Cygwin/MinGW, Windows XP). I've already implemented a stack walker, but there is an open problem with symbol name/line lookup. The compiler (GCC 4.4-trunk) emits DWARF2-compatible debug information, but I don't know how to reach the appropriate sections (especially .debug_info) within the executable. The PE header walker is able to dump PE sections, but they have strange, numeric names, e.g.: sec[0]: name = .text sec[1]: name = .data sec[2]: name = .rdata sec[3]: name = .bss sec[4]: name = .idata sec[5]: name = /4 sec[6]: name = /19 sec[7]: name = /35 sec[8]: name = /47 sec[9]: name = /61 sec[10]: name = /73 sec[11]: name = /86 sec[12]: name = /97 sec[13]: name = /108 On the other hand, the DWARF sections are available in the file -- a hexdump viewer can locate them, as well as objdump. Could somebody please tell me what should I do in order to get to the DWARF sections from this point? Any documentation will be appreciated. Best regards, Piotr Wyderski
Re: TLS on windows (was: Re: Gfortran on Windows (mingw32) with OpenMP)
FX Coudert wrote: The support for TLS (Thread Local Storage) would probably come from the compiler itself. Windows has TLS (see for example http:// dotnet.di.unipi.it/Content/sscli/docs/doxygen/pal/localstorage_8c- source.html and http://www.ddj.com/dept/cpp/184403874, or the MSDN documentation at http://msdn.microsoft.com/library/default.asp?url=/ library/en-us/dllproc/base/tlsalloc.asp), so you'd only need to teach GCC how to call that. fs:[0x14] is a per-thread 32-bit word available for applications, so you can store a pointer to your own TLS array there. fs:[0x2c] points to a Windows-specific TLS array, so you can make use of it, too, but you must conform to the limitations of the WinAPI constraints related with TLS management. IMO the best would be the offset 0x14 + a custom design of TLSes (BTW, it must be extremely fast! Many applications get their TLS values very often). Now, for an idea of how much work it represents... perhaps someone here can tell us? I don't know much about GCC internals, but I use my own implementation based on inline assembly and the implementation took, hm, 20 minutes? Best regards Piotr Wyderski
Atomic operations on Sparc in libstdc++
Hello, why there is no cas-based version of __exchange_and_add for 32-bit mode Sparcs in libstdc++, namely in config/cpu/sparc/atomicity.h ? There is spinlock-based generic code for all Sparcs, but V9 does support 32-bit cas, which can be used instead of a spinlock. This spinlock _Atomicity_lock__inst::_S_atomicity_lock causes serious scalability problems with std::string. On a machine with 4 processors our 32-bit code is only about 2.3 times faster that on a uniprocessor. When I hack atomicity.h, providing my own cas-based __exchange_and_add, it works nearly 4 times faster compared to a UP. Is it possible to replace __exchange_and_add with my code without patching libstdc++? Unfortunately it is impossible to provide a generic patch for atomicity.h, because GCC does not define __sparcv9 in 32-bit mode, as described in this thread: http://gcc.gnu.org/ml/gcc/2005-11/msg00842.html Best regards Piotr Wyderski
asm label generation bug?
HOST: AIX, 8 * IBM POWER2 CPU
COMPILER: GCC 4.0.1, GCC 3.4.4
I am trying to compile my low-level library, which contains
several inline assembly functions. It doesn't work, because
the compiler (4.0.1) does not replace local labels from the
assembly code (i.e. 0:, 1:, etc.) with their machine-specific
replacements (LCFI..4: and so on). It generates the labels
literally, i.e. the template
__asm__ __volatile__(0: bne 0b)
is translated into
[...]
0: bne 0b
instead of, for example,
L0: bne L0
and then the assembler fails. If I hardcode the label manually, it works.
Even this simple excerpt form Postgres SQL (to exclude my own mistakes)
doesn't compile because of the error described above:
typedef unsigned int word_t;
static __inline__ int
tas(volatile word_t *lock)
{
word_t _t;
int _res;
__asm__ __volatile__(
lwarx %0,0,%2 \n
cmpwi %0,0 \n
bne 1f \n
addi%0,%0,1 \n
stwcx. %0,0,%2 \n
beq 2f \n
1: li %1,1 \n
b 3f \n
2: \n
isync\n
li %1,0 \n
3: \n
: =r (_t), =r (_res)
: r (lock)
: cc, memory
);
return _res;
}
int main(int argc, char *argv[]) {
word_t x;
tas(x);
return 0;
}
Assembler:
/tmp//cckkGueR.s: line 54: 1252-142 Syntax error.
/tmp//cckkGueR.s: line 57: 1252-142 Syntax error.
/tmp//cckkGueR.s: line 58: 1252-142 Syntax error.
/tmp//cckkGueR.s: line 59: 1252-142 Syntax error.
/tmp//cckkGueR.s: line 60: 1252-142 Syntax error.
/tmp//cckkGueR.s: line 63: 1252-142 Syntax error.
which is exactly where the labels were emitted. GCC 3.4.4 has an
additional bug/misfeature related with some missing instruction patterns:
Assembler:
/tmp//ccgioejq.s: line 538: 1252-149 Instruction lwarx is not implemented in
the current assembly mode COM.
/tmp//ccgioejq.s: line 540: 1252-142 Syntax error.
/tmp//ccgioejq.s: line 542: 1252-149 Instruction stwcx. is not implemented
in the current assembly mode COM.
/tmp//ccgioejq.s: line 543: 1252-142 Syntax error.
/tmp//ccgioejq.s: line 544: 1252-142 Syntax error.
/tmp//ccgioejq.s: line 545: 1252-142 Syntax error.
/tmp//ccgioejq.s: line 546: 1252-142 Syntax error.
/tmp//ccgioejq.s: line 549: 1252-142 Syntax error.
/tmp//ccgioejq.s: line 619: 1252-149 Instruction stwcx. is not implemented
in the current assembly mode COM.
/tmp//ccgioejq.s: line 654: 1252-149 Instruction lwarx is not implemented in
the current assembly mode COM.
Best regards
Piotr Wyderski
Target processor detection
I am working on a portable low-level library of atomic operations, so I need to detect the exact type of the target processor, which is specified by -mcpu or -march. However, there are two problems. On a sparc-based platform (Sun Fire 880, Solaris 2.8, 4x UltraSparc III) this program #if defined(__arch64__) #warning 64-bit architecture #else #warning 32-bit architecture #endif #if defined(__sparcv9__) || defined(__sparc_v9__) || defined(__sparcv9) #warning Sparc V9 #endif compiled using GCC 3.4.1 g++ -mcpu=v9 -mv8plus -mvis -m32 main.cpp displays only #warning 32-bit architecture with g++ -mcpu=v9 -mv8plus -mvis -m64 main.cpp the result is #warning 64-bit architecture #warning Sparc V9 Why does __sparc_v9__ depend on the number of bits instead of the -mcpu? Is this a GCC bug? I've found an e-mail by Jakub Jelinek, which claims, that __sparc_v9__ macro is for -mcpu=ultrasparc or -mcpu=v9, which is implied by -m64, but can be used in 32-bit code as well. __sparc_v9__ means using v9 instructions, __sparc__ __arch64__ means 64-bit ABI with the exception of Solaris which uses __sparcv9. It seems that my interpretation is confirmed by the above text and that it is a GCC bug. Could you please clarify the exact meaning of __sparc_v9__? The second problem is more general. Is it possible to change the meaning of __i386, __sparc, etc. in the next release of GCC? It should return the number provided by the user in -mcpu, for example: -mcpu=i386 = __i386 = 300 -mcpu=i486 = __i386 = 400 -mcpu=i586 = __i386 = 500 -mcpu=pentiumpro = __i386 = 600 -mcpu=pentium2 = __i386 = 625 -mcpu=pentium3 = __i386 = 650 -mcpu=pentium4 = __i386 = 700 -mcpu=v8 = __sparc = 800 -mcpu=v8 -mv8plus = __sparc = 850 -mcpu=v9 = __sparc = 900 -mcpu=ultrasparc = __sparc = 1000 and so on. Currently it is just defined to 1, which doesn't help much if the programmer would like to use something very architecture-specific. This modification would be backward compatible, because the result of #if defined(__i386) is the same as in the current compiler version. Best regards Piotr Wyderski This email was checked on leaving Microgen for viruses, similar malicious code and inappropriate content by MessageLabs SkyScan. DISCLAIMER This email and any attachments transmitted with it are confidential and may contain privileged or copyright information. Any views or opinions expressed in this email are those of the individual sender, except where the sender specifically states them to be the views of Microgen. If you are not the named or intended recipient of this email you must not read, use or disseminate the information contained within it for any purpose other than to notify us. If you have received this email in error, please notify the sender immediately and delete this email from your system. It is your responsibility to protect your system from viruses and any other harmful code or device, we try to eliminate them from emails and attachments, but accept no liability for any which remain. We may monitor or access any or all emails sent to us. In the event of technical difficulty with this email, please contact the sender or [EMAIL PROTECTED] Microgen Information Management Solutions http://www.microgen.co.uk
Deinitialization of globals
I need to enforce a certain initialization and deinitialization order
of static variables in GCC, even between different translation units.
There is an extension called init_priority, which initializes my
variable first, but its deinitialization order is weird:
8--
#include stdio.h
struct A {
A() {
printf(A()\n);
}
~A() {
printf(~A()\n);
}
};
struct B {
B() {
printf(B()\n);
}
~B() {
printf(~B()\n);
}
};
struct C {
C() {
printf(C()\n);
}
~C() {
printf(~C()\n);
}
};
struct D {
D() {
printf(D()\n);
}
~D() {
printf(~D()\n);
}
};
static A a;
static B b;
static C c __attribute__((init_priority(101)));
static D d;
int main(int argc, char *argv[])
{
return 0;
}
8--
It produces:
C()
A()
B()
D()
~C() = deinitialization order error
~D()
~B()
~A()
But I expect:
C()
A()
B()
D()
~D()
~B()
~A()
~C()
Why isn't c destroyed at the very end? Is it a bug or a correct behaviour?
I don't see anything like attribute(deinit_priority), so how can I obtain
the
latter deinitialization order (nifty counters etc. are not allowed, because
third-party libraries do not include them)?
Best reagrds
Piotr Wyderski
Where have all the conditional moves gone?
Hello, I have disassembled my program produced by g++ 4.0.0 and I see a very strange behaviour -- the compiler doesn't generate cmov-s (-O3 -march=pentium3). G++ 3.4 generates them. So, how can I reactivate cmov-s in the newest version of the compiler? fif-conversion doesn't work... Best regards Piotr Wyderski
