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 inline string format(const string& fmt, TA&&... args) { string_formatter f; f.format(fmt, std::forward(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: template _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: template _Tp&& std::forward(typename std::remove_reference<_Tp>::type&&) Should I report it as a standard library bug? Best regards, Piotr
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
C++0x convertibility checking
Consider the folowing: class XXX { public: XXX(char) {} template XXX(T) = delete; }; fprintf(stderr, "ic::value = %i\n", std::is_convertible::value); fprintf(stderr, "ic::value = %i\n", std::is_convertible::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_helper::__value': /opt/gcc-trunk-old2/bin/../lib/gcc/i686-pc-cygwin/4.6.0/include/c++/type_traits: 309:12: instantiated from `std::is_convertible' /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: ic::value =1 ic::value = 0 as double is obviously not convertible to XXX -- the "template 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
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
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
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: GCC 4.6.0 Released
Jakub Jelinek : > 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
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
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
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
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: 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
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: (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 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
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
Re: Bugzilla and setting priorities
Paolo Carlini wrote: > Sure. Maybe it's also worth reminding that submitters don't need to add > explicitly themselves in CC. It's the reason I asked -- I've been recently removed from CC. So thanks for explanation. 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: 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
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_cast(reinterpret_cast(&v))); } but I expected char* to be allowed to alias anything. Best regards Piotr Wyderski
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.
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"?
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: 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
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
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 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::list
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
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
[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
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 @@ fu
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
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
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: 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
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 : nop 0x751407b8 : ldx [ %fp + 0x87f ], %o0 0x751407bc : clr %o1 0x751407c0 : call 0x7543bc00 <_zn6parser8internal9functions11setcategoryens0_11eh_catego...@plt> 0x751407c4 : nop 0x751407c8 : 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
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
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
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 there is a conditional block: #if (defined(__GXX_EXPERIMENTAL_CXX0X__) \ && defined(_GLIBCXX_ATOMIC_BUILTINS_4)) #include #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: Bugfix request
Robert Dewar wrote: > Since this is particularly important to you It is not "particularly important" to me, it's just a bug with a known workaround (i.e. a cast to the enum's base type). But a very annoying one. > why not take the opportunity to dig in and see if you > can figure out the necessary fix. Frankly: because I know nothing about GCC internals and am not interested in becoming a wizard GCC developer. I do enjoy writing my hobbyists asynchronous execution framework in C++0x using GCC as an excellent tool for the job (on many levels: as the primary code base compiler and a semi-dynamic code generator) but I do not enjoy writing the tool itself. GCC wishes to support C++0x as soon as possible, so the bug will eventually be fixed anyway. My message was merely a user feedback from the trenches of a large scale application of the experimental C++0x support in GCC, intended to help its real developers to assing an appropriate priority to the bug. Call it a profile -gudided prioritization if you wish. You may help fixing the bug or completely ignore this feedback -- both possibilities are perfectly OK, it's up to you. But I see nothing here to discuss about, so I rest my case. > Bugs only get fixed if someone volunteers to do the fix! Indeed. And, as you can see, there are volunteers who enjoy GCC development and share my opinion that the bug is quite important: its status has been rapidly changed to confirmed and a volunteer has been assigned to fix it. So I would like to thank these fellows very much. 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
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
[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: 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: 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
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: may_contain_throw prev: 97 type: 102 must_not_throw tree_label: may_contain_throw 101 cleanup tree_label: may_contain_throw 97 catch tree_label: may_contain_throw prev: 94 next 100 type:struct exception 99 must_not_throw tree_label: may_contain_throw 98 cleanup tree_label: may_contain_throw 94 catch tree_label: may_contain_throw next 97 type:struct rc_ptr 96 must_not_throw tree_label: may_contain_throw 95 cleanup tree_label: may_contain_throw 1 try may_contain_throw catch regions: 94 97 100 93 must_not_throw tree_label: may_contain_throw 2 cleanup tree_label: may_contain_throw prev try:1 92 must_not_throw tree_label: may_contain_throw 3 cleanup tree_label: may_contain_throw prev try:1 91 must_not_throw tree_label: may_contain_throw 4 cleanup tree_label: may_contain_throw prev try:1 90 must_not_throw tree_label: may_contain_throw 5 cleanup tree_label: may_contain_throw prev try:1 89 must_not_throw tree_label: may_contain_throw 6 cleanup tree_label: may_contain_throw prev try:1 88 must_not_throw tree_label: may_contain_throw 7 cleanup tree_label: may_contain_throw prev try:1 87 must_not_throw tree_label: may_contain_throw 8 cleanup tree_label: may_contain_throw prev try:1 86 must_not_throw tree_label: may_contain_throw 9 cleanup tree_label: may_contain_throw prev try:1 85 must_not_throw tree_label: may_contain_throw 10 cleanup tree_label: may_contain_throw prev try:1 84 must_not_throw tree_label: may_contain_throw 11 cleanup tree_label: may_contain_throw prev try:1 83 must_not_throw tree_label: may_contain_throw 34 cleanup tree_label: may_contain_throw prev try:1 82 must_not_throw tree_label: may_contain_throw 37 cleanup tree_label: may_contain_throw prev try:1 81 must_not_throw tree_label: may_contain_throw 40 cleanup tree_label: may_contain_throw prev try:1 80 must_not_throw tree_label: may_contain_throw 43 cleanup tree_label: may_contain_throw prev try:1 79 must_not_throw tree_label: may_contain_throw 46 cleanup tree_label: may_contain_throw prev try:1 78 must_not_throw tree_label: may_contain_throw 49 cleanup tree_label: may_contain_throw prev try:1 77 must_not_throw tree_label: may_contain_throw 52 cleanup tree_label: may_contain_throw prev try:1 76 must_not_throw tree_label: may_contain_throw 55 cleanup tree_label: may_contain_throw prev try:1 75 must_not_throw 56 cleanup tree_label: may_contain_throw prev try:1 74 must_not_throw tree_label: may_contain_throw 57 cleanup tree_label: may_contain_throw prev try:1 73 must_not_throw tree_label: may_contain_throw 58 cleanup tree_label: may_contain_throw prev try:1 72 must_not_throw tree_label: may_contain_throw 59 cleanup tree_label: may_contain_throw prev try:1 71 must_not_throw tree_label: may_contain_throw 60 cleanup tree_label: may_contain_throw prev try:1 70 must_not_throw tree_label: may_contain_throw 61 cleanup tree_label: may_contain_throw prev try:1 69 must_not_throw tree_label: may_contain_throw 62 cleanup tree_label: may_contain_throw prev try:1 68 must_not_throw tree_label: may_contain_throw 63 cleanup tree_label: may_contain_throw prev try:1
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-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-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 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
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 /* 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 >> >
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: 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 class geometry; // --- template <> class geometry<1> : 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 geometry<2> : 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::geometry<1>::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
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
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 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