Re: GCC 4.9.0 Release Candidate available from gcc.gnu.org
Hi,
the opt_random.h header includes x86intrin.h unconditionally and
breaks crytopp build
(redefinition of _mm_shuffle_epi8 in cpu.h).
could you please add #ifdef __SSSE3__ around this include?
BR,
Paweł.
cpu.h @ cryptopp:
(...)
#if !defined(__GNUC__) || defined(__SSSE3__) ||
defined(__INTEL_COMPILER)
#include tmmintrin.h
#else
__inline __m128i __attribute__((__gnu_inline__, __always_inline__,
__artificial__))
_mm_shuffle_epi8 (__m128i a, __m128i b)
{
asm (pshufb %1, %0 : +x(a) : xm(b));
return a;
}
#endif
(...)
Re: GCC 4.9.0 Release Candidate available from gcc.gnu.org
W dniu 2014-04-17 12:13, Jonathan Wakely napisał(a):
On 17 April 2014 10:38, Paweł Sikora wrote:
Hi,
the opt_random.h header includes x86intrin.h unconditionally and
breaks
crytopp build
(redefinition of _mm_shuffle_epi8 in cpu.h).
could you please add #ifdef __SSSE3__ around this include?
Do you mean __SSE3__ not __SSSE3__?
yes, __SSE3__.
That's the macro that controls whether the
config/cpu/i486/opt/bits/opt_random.h header actually uses the
intrinsics or not:
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
#ifdef __SSE3__
template
templatetypename _UniformRandomNumberGenerator
void
normal_distributiondouble::
Re: GCC stack backtraces
On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote: I've spent the last couple of days working on a stack backtrace library. It uses the GCC unwind interface to collect a stack trace, and parses DWARF debug info to get file/line/function information. (Of course it's silly to write yet another DWARF reader, but I didn't find an existing reader that seemed wholly suitable.) isn't the libdwarf a good enough for reading? http://reality.sgiweb.org/davea/dwarf.html
Re: GCC stack backtraces
On Wednesday 29 of August 2012 11:37:07 Ian Lance Taylor wrote: On Wed, Aug 29, 2012 at 1:07 AM, Paweł Sikora pl...@agmk.net wrote: On Wednesday 29 of August 2012 00:22:55 Ian Lance Taylor wrote: I've spent the last couple of days working on a stack backtrace library. It uses the GCC unwind interface to collect a stack trace, and parses DWARF debug info to get file/line/function information. (Of course it's silly to write yet another DWARF reader, but I didn't find an existing reader that seemed wholly suitable.) isn't the libdwarf a good enough for reading? http://reality.sgiweb.org/davea/dwarf.html libdwarf is GPLv2, so it wouldn't work for libgo, which was one of my goals. libdwarf is on lgpl, dwarfdump tools are on gpl.
Re: C++98/C++11 ABI compatibility for gcc-4.7
On Thursday 31 of May 2012 22:58:32 Jonathan Wakely wrote: On 31 May 2012 22:39, Jonathan Wakely wrote: On 31 May 2012 22:35, James Y Knight wrote: I understand that the ABI changes generally cannot be avoided, but a lot of pain for a lot of people could be avoided by making things fail obviously with a link error, instead of sometimes, arbitrarily, if you're lucky, you'll get a segfault at runtime. Do you have any suggestions for how to do that? ... *without* breaking the current ABI, because if we weren't trying to keep it stable it would be much easier. If you want to you can configure with --enable-symvers=gnu-versioned-namespace and test that mode, which would allow everything to be put in something like std::__cxx2011::__8 for -std=c++11 mode, but AFAICT only one person seems to be trying that option out and giving feedback on it. the versioned namespace doesn't solve all problems. if you put c++11/std::list in the e.g., std::__8 namespace then you trig a nice linker error for incompatible objects that passes std::list as a function argument but std::list used as a return type won't be catched (return type is not mangled in function symbol). from the others side, someone can use -frecord-gcc-switches to detect mixed '-std=...' after final linking and report error in such cases.
Re: [cxx-conversion] New Hash Table (issue6244048)
On Friday 25 of May 2012 11:50:13 Gabriel Dos Reis wrote: On Fri, May 25, 2012 at 11:44 AM, Paweł Sikora pl...@agmk.net wrote: so, why you just don't use the hash table implementation from libstdc++? we have agreed on C++03 as a bootstrap compiler. There is unfortunately no hash table in C++03. can't you use implementation from tr1 for c++98/03 mode?
Re: Converting GCC to C++ - new branch cxx-conversion
On Wednesday 11 of April 2012 12:35:18 Diego Novillo wrote: I have created the SVN branch cxx-conversion to host all the mini-projects aimed at exploring the C++ conversion. Everyone is welcome to contribute to it. The branch has been configured to build in C++ mode by default. I have also created a wiki page to coordinate conversion efforts and document the status of the branch: http://gcc.gnu.org/wiki/cxx-conversion will this project use (new) gcc mailing list or should we poison ;) the core gcc@ list with [cxx-conversion] marker?
Re: Switching to C++ by default in 4.8
On Wednesday 11 of April 2012 11:43:36 Richard Guenther wrote: () The overloadable operator new means that memory can be _implicitly_ allocated in the right place. Implicit allocation is bad. In a compiler you want to _see_ where you spend memory. in c++ you can overload new/delete operators for each class and track all these allocations with provided allocator. please consider following example: http://pastebin.com/UmBGWMTH you can bind polls, gc or anything else you want for any class and just use the new/delete keywords in sources as usual. in pure C you need to call the right malloc_*/free_* variants for each class. () Class hierarchies also mean that programmers can distinguish in the pointer types that a function needs a decl parameter, without having to say 'all trees' versus 'a very specific tree'. The static type checking avoids run-time bugs. True. In a very limited set of cases. C++ is not powerful enough to express pointer-to-everything-that-would-be-considered-a-gimple-val. Maybe C++ is not the right choice after all? (I suppose C++ concepts would have helped here? pointer-to-tree-that-fulfils-is_gimple_val ... (though is_gimple_val is not be a static property). hmm :) the c# provides a nice constraints engine (google the 'where' keyword) and the so-called duck-typing (c# 4.0) which might simplfy the source code that operates on ast nodes.
Re: Switching to C++ by default in 4.8
On Tuesday 10 of April 2012 10:46:14 Jakub Jelinek wrote: On Mon, Apr 09, 2012 at 04:34:32PM -0700, Xinliang David Li wrote: Class hierarchy is one such feature that is useful. Assuming we have two hierarchies for gcc: one for values rooted at ValExp, and one for gimple stmts rooted at GimpInst. 1) For IR browsing, *) all the macro accessors can be eliminated -- a big plus for debugging; Not that clear, if all the macros are replaced by tons of inline functions, the debugging experience can be actually significantly worse. debugabilty can be improved with set of gdb python pretty printers which could present gcc's structures in human readable form (instead of union mix).
Re: Switching to C++ by default in 4.8
On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote: Concurrently with this, Lawrence and Ian are working on the C++ coding guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions. what about using http://astyle.sourceforge.net/astyle.html for code checkers? what about -Woverloaded-virtual [-Werror] by default?
Re: Switching to C++ by default in 4.8
On Tuesday 03 of April 2012 13:51:56 Ian Lance Taylor wrote: Paweł Sikora pl...@agmk.net writes: On Tuesday 03 of April 2012 13:37:50 Diego Novillo wrote: Concurrently with this, Lawrence and Ian are working on the C++ coding guidelines. The draft is stored at http://gcc.gnu.org/wiki/CppConventions. what about using http://astyle.sourceforge.net/astyle.html for code checkers? I don't think we want to automatically reformat the entire GCC codebase. Or at least, if we do, we don't want to confuse that with the C++ transition. i'm only suggesting that astyle (or another tool) can be used in svn pre-commit hook to verifying gnu formatting rules (incoming files can be extracted from svn transaction to /tmp and checked). manual formatting rules reviewing @gcc-patches is waste of time.
Re: Second GCC 4.7.0 Release Candidate available from gcc.gnu.org
On Wednesday 14 of March 2012 12:22:41 Richard Guenther wrote:
GCC 4.7.0 Release Candidate available from gcc.gnu.org
A second release candidate for GCC 4.7.0 is available from
ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120314
and shortly its mirrors. It has been generated from SVN revision 185376.
I have so far bootstrapped and tested the release candidate on
x86_64-linux. Please test it and report any issues to bugzilla.
i'd like to ask about simple code snipet rejected by 4.7.0-RC2:
#include boost/shared_ptr.hpp
#include map
#include string
typedef boost::shared_ptrstd::string HString;
typedef std::mapstd::string,HString StrAttribsT;
StrAttribsT m_str_attribs;
void foo(const char* attribName, const char* value)
{
m_str_attribs.insert(std::make_pair(attribName, new
std::string(value)));
}
it compiles cleanly with 'g++46 -std=gnu++0x' but 4.7 rejects this code.
is it an effect of 'name lookup changes'?
(http://gcc.gnu.org/gcc-4.7/porting_to.html)
BR,
Paweł.
Re: [debug/profile-mode] broken c++config.h
On Friday 16 of March 2012 14:29:21 Jonathan Wakely wrote:
2012/3/16 Paweł Sikora:
Hi,
during gcc build process there's some sed magic
(libstdc++-v3/include/Makefile.{am,in}) in action
which modifies libstdc++/include/bits/c++config.h (replaces '#define
_GLIBCXX_EXTERN_TEMPLATE'
according to --enable-extern-template=yes/no settings). in fact, this sed
rule also produces
a wrong '#define _GLIBCXX_EXTERN_TEMPLATE 1 -1' in line 293:
#if defined(_GLIBCXX_DEBUG) || defined(_GLIBCXX_PROFILE)
# define _GLIBCXX_STD_C __cxx1998
# define _GLIBCXX_BEGIN_NAMESPACE_CONTAINER \
namespace _GLIBCXX_STD_C { _GLIBCXX_BEGIN_NAMESPACE_VERSION
# define _GLIBCXX_END_NAMESPACE_CONTAINER \
} _GLIBCXX_END_NAMESPACE_VERSION
# undef _GLIBCXX_EXTERN_TEMPLATE
# define _GLIBCXX_EXTERN_TEMPLATE 1 -1 here
#endif
this broken macro causes runtime errors on mingw (see PR52540).
attached small patch fixes all weird runtime errors for me.
Should the addition be \$$ to escape it for the shell as well as for make?
(I know it works, but that might not be true for all shells.)
i don't think that $, could be expaneded by any shell.
The diff for Makefile.in is unnecessary, as it should be regenerated
from Makefile.am
Apart from that the patch looks good, I've CC'd gcc-patches, could you
provide a changelog entry?
attached. i hope it's correct :)
2012-03-16 Paweł Sikora pawel.sik...@agmk.net
PR libstdc++/52540
* include/Makefile.am (c++config.h): Fix sed rule to not break
the _GLIBCXX_EXTERN_TEMPLATE redefinition.
* include/Makefile.in: Regenerated.
Re: Prototype libatomic
On Tuesday 13 of March 2012 17:02:01 Richard Henderson wrote: So, I've got something put together. I think it should be fairly scalable. As a test I've thrown in some ARM overrides. See git://repo.or.cz/gcc/rth.git rth/libatomic which is a gcc tree with a libatomic subdir. Comments welcome. is this yet another libatomic implementation better than atomic_ops? http://www.hpl.hp.com/research/linux/atomic_ops/ https://github.com/ivmai/libatomic_ops/
Re: GCC 4.7.0 Release Candidate available from gcc.gnu.org
On Friday 02 of March 2012 14:44:45 Richard Guenther wrote: GCC 4.7.0 Release Candidate available from gcc.gnu.org The first release candidate for GCC 4.7.0 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.7.0-RC-20120302 and shortly its mirrors. It has been generated from SVN revision 184777. I have so far bootstrapped and tested the release candidate on x86_64-linux. Please test it and report any issues to bugzilla. If all goes well, I'd like to release 4.7.0 in about three weeks. it would be nice to see a fixincl update for 4.6/4.7 to support bits/string3.h header as a workaround for PR50916.
Re: weird optimization in sin+cos, x86 backend
On Friday 10 of February 2012 13:30:25 James Courtier-Dutton wrote: On 10 February 2012 10:42, Andrew Haley a...@redhat.com wrote: On 02/10/2012 10:07 AM, Richard Guenther wrote: The issue with libm in glibc here is that Drepper absolutely does not want new ABIs in libm - he believes that for example vectorized routines do not belong there (nor the SSE calling-convention variants for i686 I tried to push once). That's a good reason why we can't do this in glibc. I accept the point; it'll have to be GNU libm. Andrew. I think a starting point would be at least documenting correctly the accuracy of the current libm, because what is currently in the documents is obviously wrong. It certainly does not document that sin() is currently more accurate than sinl() on x86_64 platforms, even with -O0. I think the documentation should be along the lines of for Function name: sin(x) -pi/2 x pi/2, accuracy is +-N pi/2 x large number, accuracy is +-N large number x max_float, accuracy is +-N If a performance figure could also be added, so much the better. We could then know that implementation 1 is quicker than implementation 2 and the programmer can do the trade offs. And have the figures repeated for various options such as -ffast-math etc, and also repeated for different CPUs etc. it would be also nice to see functions for reducing argument range in public api. finally the end-user can use e.g. sin(reduce(x)) to get the best precision with some declared cpu overhead. Once we have the documentation, we can then ensure, using automated testing, that the libm actually performs as designed.
Re: weird optimization in sin+cos, x86 backend
On Friday 10 of February 2012 17:41:49 Andrew Haley wrote: On 02/10/2012 05:31 PM, Paweł Sikora wrote: it would be also nice to see functions for reducing argument range in public api. finally the end-user can use e.g. sin(reduce(x)) to get the best precision with some declared cpu overhead. Hmm. I'm not sure this is such a terrific idea: each function has its own argument reduction (e.g. to [0, pi/4], [0, pi/8] or even [0, some weird constant that looks arbitrary but just happens to be exactly representable in binary]). You really don't want double rounding, which is what would happen with sin(reduce(x)). hmm, maybe the math functions should contain an additioanal 'bool reduce' argument with some default (./configure-ed) value? with such approach the end-user can avoid double rounding and choose desired behaviour.
Re: -mavx option
On Thursday 26 of January 2012 09:52:22 Ulrich Drepper wrote: I think gcc is missing an option since -mavx controls two different things. First, the generation of VEX-encoded instructions. Second, the use of ymm registers. The latter is not always available when the former is and using VEX-encoded instructions by themselves can have an advantage. Currently, when OSXAVE is not available (use xgetbv to test etc etc) then I cannot use code which gcc generates with -mavx even though I am only interested in the VEX encoding. Could we have a -mvex option which is automatically implied in -mavx? there's a -msse2avx option. is it enough?
Re: Converting SIGSEGV etc. signals to exceptions
On Saturday 20 of August 2011 14:51:44 sudhakar govindavajhala wrote: Hi there, I am writing C++ code in Linux (2.6.18) using pthreads. glibc 2.5. gcc 4.1.2 2) I would like to translate SIGSEGV or SIGFPE to an exception in the program so that it can be caught at higher levels. Is there a default option to convert a SIGSEGV to an exception? For my tests, I provided a signal handler for SIGSEGV/SIGFPE that throws an int exception and it works. 1). for proper exception throwing from signal handler you need to have a quite new gcc (so called enterprise linux distros may have an old one) with unwinder that can properly walk through signal frame. 2). during e.g. sigsegv handling (broken program stack, broken glibc heap, etc.) you should throw c++ exception in the safe way, that means you should setup custom stack for signal handler with sigaction() and exception object should be constructible/copyable without heap usage (probably damaged). classic std::*_error exceptions use std::string with dynamic buffer :/ 3) Could someone point me to a sample to print the stack trace when an exception occurred? feel free to use and improve the http://svn.pld-linux.org/svn/backtracexx ps). use gcc-help mailinglist next time. BR, Paweł.
Re: GCC 4.6.1 Release Candidate available from gcc.gnu.org
On Monday, June 20, 2011 03:01:47 PM Jakub Jelinek wrote: The first release candidate for GCC 4.6.1 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/4.6.1-RC-20110620 and shortly its mirrors. It has been generated from SVN revision 175201. I have so far bootstrapped and tested the release candidate on x86_64-linux and i686-linux. Please test it and report any issues to bugzilla. PR49407 - mingw / impossible .dll debug. PR47308#c17 - mingw / problems with mixing dwarf-2/dwarf-4 objects.
Re: going from SunOS 5/SparcWorks - Linux/gcc
On Thursday 29 April 2010 20:35:23 Steven Bosscher wrote: The standard 1st questions are: 1) Did you compile with -Wall -Wextra and solve all warnings? 2) Did you try with -fno-strict-aliasing? for legacy code, the '-fwrapv' could be helpful.
Re: Why not contribute? (to GCC)
On Friday 23 April 2010 22:36:21 Manuel López-Ibáñez wrote: (...). In the free-software world, you can actually help to fix it. (...) we need more contributors. Wanna help? i haven't so much free time (c++work/family/studies) for learn internal gcc structures and non-trivial design to start full power contributing. i'm doing what i can at this point of my gcc knowledge and currently i'm focused on testing each gcc release on my work codebase and isolating testcases which is also hard and ugly piece of work. e.g, from few months i'm trying to isolate a fancy (i think) gcc wrong-code bug (at -O0! on 4.4/4.5 while -O2 on 4.3 works fine) that causes memory over(under)runs in very big C++/EDA software. long dancing in free time with gdb, valgrind and electric fence is my little contribution to the quality of g++ - my favourite compiler. from the rookie point of view i can say that the new gcc plugin framework is a fantastic tool for learning gcc internals on the fly via debugging when partial information on the onlinedocs/gccint/GENERIC are not enough. this process could be improved by gdb7 python based pretty printers which e.g. allow easier 'tree' union analyzing. In any case, I think coming from you it is a bit hurtful because I have personally fixed many of your bugs and I haven't seen a single beer yet! no offence please but that weren't my bugs but compiler bugs :-) your effort in fixing gcc-bad/false-warnings is great and keep the -Wall -Werror still usable for large projects. once again many thanks! btw. i have another PR in this area. wanna help? :-) Where is my beer? http://www.bigstockphoto.com/image-298233/stock-photo-beer-drinking-emoticon :-) BR, Pawel.
Re: Why not contribute? (to GCC)
On Friday 23 April 2010 22:05:56 HyperQuantum wrote: On Fri, Apr 23, 2010 at 9:58 PM, HyperQuantum hyperquan...@gmail.com wrote: On Fri, Apr 23, 2010 at 8:39 PM, Manuel López-Ibáñez lopeziba...@gmail.com wrote: What reasons keep you from contributing to GCC? The lack of time, for the most part. I submitted a feature request once. It's now four years old, still open, and the last message it received was two years ago. (PR26061) i'm trying to contribute to gcc/glibc via testing on my codebase and... i have abandoned/rejected long standing PRs too :( e.g: http://gcc.gnu.org/PR20128 http://gcc.gnu.org/PR28811 http://gcc.gnu.org/PR28854 http://gcc.gnu.org/PR36568 vs. http://sourceware.org/PR6693 people don't like wait for a years for bug classification/fixing ;)
[lto] elfutils-libelf-0.145 vs libelf-0.8.13?
hi, i would like to ask why the LTO forces libelf-0.8.x in configure.ac? linux/unix distros have well tested elfutils-libelf subpackage, so what is the point in forcing new library? i've just built (with little hack) gcc/trunk with elfutils-libelf and lto works fine. BR, Pawel.
Re: [lto] elfutils-libelf-0.145 vs libelf-0.8.13?
Dnia 11-03-2010 o 14:51:39 H.J. Lu hjl.to...@gmail.com napisał(a): checking for libelf/gelf.h... no checking for the correct version of libelf... yes I am using elfutils-libelf 0.145. ahh, right. i've accidentally used an older version 0.142 which libelf.h contains only: extern int elf_getshstrndx (Elf *__elf, size_t *__dst); the latest 0.145 have both signatures: extern int elf_getshdrstrndx (Elf *__elf, size_t *__dst); ^ lto requires exactly this one. extern int elf_getshstrndx (Elf *__elf, size_t *__dst) __attribute__ ((__deprecated__)); sorry for the noise :)
(un)aligned accesses on x86 platform.
hi, during development a cross platform appliacation on x86 workstation i've enabled an alignemnt checking [1] to catch possible erroneous code before it appears on client's sparc/arm cpu with sigbus ;) it works pretty fine and catches alignment violations but Jakub Jelinek had told me (on glibc bugzilla) that gcc on x86 can still dereference an unaligned pointer (except for vector insns). i suppose it means that gcc can emit e.g. movl for access a short int (or maybe others scenarios) in some cases and violates cpu alignment rules. so, is it possible to instruct gcc-x86 to always use suitable loads/stores like on sparc/arm? [1] AC bit - http://en.wikipedia.org/wiki/FLAGS_register_(computing) BR, Pawel.
Re: (un)aligned accesses on x86 platform.
On Monday 08 March 2010 16:46:10 Richard Guenther wrote: 2010/3/8 Paweł Sikora pl...@agmk.net: hi, during development a cross platform appliacation on x86 workstation i've enabled an alignemnt checking [1] to catch possible erroneous code before it appears on client's sparc/arm cpu with sigbus ;) it works pretty fine and catches alignment violations but Jakub Jelinek had told me (on glibc bugzilla) that gcc on x86 can still dereference an unaligned pointer (except for vector insns). i suppose it means that gcc can emit e.g. movl for access a short int (or maybe others scenarios) in some cases and violates cpu alignment rules. so, is it possible to instruct gcc-x86 to always use suitable loads/stores like on sparc/arm? Only by re-building it and setting STRICT_ALIGNMENT. oops, we have a problem with 4.4.x bootstrap ;) http://imgbin.org/index.php?page=imageid=1356
Re: GCC 4.3.2 Status Report (2008-06-22)
On Sunday 22 of June 2008 13:17:38 Joseph S. Myers wrote: Status == The GCC 4.3 branch is open for commits under normal release branch rules. The 4.3.2 release is expected around 2008-08-06. Quality Data Priority# Change from Last Report --- --- P1 8 +- 0 P2112 - 2 P3 2 +- 0 --- --- Total 122 - 2 there is one more bug reported in RedHat bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=451068
Re: gcc-in-cxx branch created
On Thursday 19 of June 2008 19:26:27 Ian Lance Taylor wrote: Jens-Michael Hoffmann [EMAIL PROTECTED] writes: No. I've flipped the branch to start compiling the source files in gcc with C++. Unfortunately a number of issues will need to be addressed before all the code will compile in C++. Most of this work can and will be contributed back to mainline gcc as well. I'll send out a note when everything on the branch compiles in C++. Is there a todo list? I would like to contribute to this branch, how can I help? Well, one approach would be to compile code on the branch. Where it fails, fix it so that it compiles. Then, if appropriate, move the patch back to mainline, test the patch there, and submit it for mainline. The other major TODO is to work out the details of using STL containers with GC allocated objects. there's also a http://www.aei.mpg.de/~peekas/tree/ that may be useful for modeling abstract trees used in compiler.
Re: Shared library without dependence on libgcc_s.so
6/6/2008, Arne Steinarson [EMAIL PROTECTED] napisał/a: The shared libraries themselves still have a dependency on libgcc_s.so: $ ldd libwx_gtk2ud_fwb_core-2.9.so.0 | grep gcc libgcc_s.so.1 = /lib/libgcc_s.so.1 (0xb6ee8000) you can use the -nodefaultlibs and manually add what you want. e.g. you can link a static stlport with static gcc stuff by: (...) -nodefaultlibs -lstlport -lpthread -lgcc_eh -lgcc -lsupc++ -lc and get e.g.: $ ldd libExample.so linux-vdso.so.1 = (0x7fff775fe000) libdl.so.2 = /lib64/libdl.so.2 (0x2b3933a4e000) libpthread.so.0 = /lib64/libpthread.so.0 (0x2b3933c53000) libm.so.6 = /lib64/libm.so.6 (0x2b3933e6e000) libc.so.6 = /lib64/libc.so.6 (0x2b39340ed000) /lib64/ld-linux-x86-64.so.2 (0x4000) as you can see there're only deps to the core system libraries and all these things related to the stl/gcc are linked in statically. ps). i'm using the stlport becuase libstdc++.a can't be linked statically into shared libs - http://gcc.gnu.org/PR28811
executable stack in gcc shared libs?
Hi all, I noticed (readelf -lW/grep) that some gcc libraries require executable stack: /usr/lib64/libffi.so.4.0.1 GNU_STACK 0x00 0x 0x 0x00 0x00 RWE 0x8 /usr/lib64/libgcj.so.8.0.0 GNU_STACK 0x00 0x 0x 0x00 0x00 RWE 0x8 /usr/lib64/libgmp.so.3.4.2 GNU_STACK 0x00 0x 0x 0x00 0x00 RWE 0x8 Is this expected marking or just missed `-z noexecstack` for assembly parts? BR, Paweł.
Re: 4.3.0-rc1 available
On Friday 22 of February 2008 21:08:10 Guillermo Ballester Valor wrote: ../../../native/jni/classpath/.libs/jcl.o -ljack -m32 -m32 -m32 -Wl,-soname -Wl,libgjsmdssi.so -o .libs/libgjsmdssi.so /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld : skipping incompatible /usr/lib64/libjack.so when searching for -ljack ^^ /usr/lib64/gcc/x86_64-suse-linux/4.2.1/../../../../x86_64-suse-linux/bin/ld : cannot find -ljack as far i can see you're trying to build libgcj multilib (32/64-bits) on x86_64 only enviroment. please try --disable-libjava-multilib option with this (or equivalent) patch: http://cvs.pld-linux.org/cgi-bin/cvsweb/SOURCES/gcc4-libjava-multilib.patch?rev=HEAD
Re: How widely used are ext/hash_set and ext/hash_map?
On Friday 26 of October 2007 19:40:34 Joe Buck wrote:
Some programs try to isolate the details of where the headers are by
having one header with #ifdefs that, in turn, does the #include of
ext/hash_{set,map}, but many others do not.
I think you shouldn't care about implementation specific #include ext/
I'm using libstdc++ and stlport in parallel and have suitable #ifdefs:
#if defined( _STLP_MSVC ) || defined( _STLP_UNIX )
#include hash_map
#define sgiext std
#elif defined( __GLIBCXX__ )
#include ext/hash_map
#define sgiext __gnu_cxx
#else
#error sgi::hash_map implementation not available?
#endif
sgiext::hash_map...
Re: GCC 4.2 RC2 Available
On Tuesday 01 of May 2007 20:08:25 Mark Mitchell wrote: GCC 4.2 RC2 is now available from: ftp://gcc.gnu.org/pub/gcc/prerelease-4.2.0-20070430 There is a known serious problem with RC2: Ada does not build. Therefore, there will be an RC3 shortly. there're two more 4.2-only problems with aliasing: PR30052, PR30252.
Re: Import GCC 4.2.0 PRs
On Monday 12 of March 2007 19:47:21 Mark Mitchell wrote: * PR 29906 (Oliva) -- This is a crash during DWARF generation for a small C++ test case. += PR 29202. ps). the PR 30052 (aliasing related) is still unconfirmed.
Re: GCC 4.2.0 Status Report (2007-02-19)
Richard Guenther napisał(a): On 2/20/07, Mark Mitchell [EMAIL PROTECTED] wrote: So, my feeling is that the best course of action is to set a relatively low threshold for GCC 4.2.0 and target 4.2.0 RC1 soon: say, March 10th. Then, we'll have a 4.2.0 release by (worst case, and allowing for lameness on my part) March 31. Feedback and alternative suggestions are welcome, of course. I'd vote for reverting the aliasing fixes on the 4.2 branch to get back the speed and the 4.1 bugs and release that. I expect that 4.2 will be made available in some form to openSUSE users because of gfortran and OpenMP improvements. Hi, Current development line of PLD-Linux uses 4.2 too. [ http://pld-linux.org/ThInfo ] ps). Mark, could you add the PR30052 to your 4.2-TODO ?
Re: Performance regression on the 4.3 branch?
François-Xavier Coudert napisał(a): $ gcc -march=pentium4 -O3 a.c time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 ./a.out 1.81s user 0.00s system 99% cpu 1.818 total $ gcc-4.3 -march=pentium4 -O3 a.c time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 ./a.out 2.40s user 0.01s system 87% cpu 2.746 total where gcc is gcc version 4.1.1 20070105 (Red Hat 4.1.1-51) and gcc-4.3 is gcc version 4.3.0 20070209 (experimental). I don't have a 4.1 or 4.2 compiler at hand, so I don't know if it's a 4.2 or 4.3 regression, or even if there's a special patch in redhat 4.1 that makes it lightning fast. But in any case, I wondered if it was known, and if it was worth opening a PR. I see this on 4.2 vs 4.3 on my k8 box. $ gcc42 -O3 a.c --save-temps time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 ./a.out 0.43s user 0.00s system 92% cpu 0.462 total $ gcc43 -O3 a.c --save-temps time ./a.out 064069fbc13963b920219c3e939225e38e38e38e3956d81c71c71c71c0ba0f00 ./a.out 0.60s user 0.00s system 98% cpu 0.610 total
Re: [c++] switch ( enum ) vs. default statment.
Mark Mitchell wrote:
For GCC, what happens (though we need not document it) is that the
value is converted to the underlying type -- but not masked down
to { 0, 1 }, because that masking would be costly.
So, ((int) e == 7) may be true after the assignment above.
(Perhaps, in some modes GCC may optimize away the assignment because
it will know that e cannot be 7,
hhmm :-) this can lead to another felix-like war ;-)
I DID NOT WRITE THE BROKEN CODE. (...)
IT DOES NOT MATTER WHAT THE ... STANDARD SAYS.
You broke code, people are suffering damage. Now revert it.
So, now, what should we do about the warning? I think there are good
arguments in both directions. On the one hand, portable programs
cannot assume that assigning out-of-range values to e does anything
predictable, so portable programs should never do that. So, if you've
written the entire program and are sure that it's portable, you don't
want the warning.
and this is exactly what i'm expecting - no warnings for pure c++ code.
moreover such warnings-on-valid code make -Werror unusable with -Wall.
On the other hand, if you are writing a portable library designed
to be used with other people's programs, you might every well want
the warning -- because you can't be sure that they're not going to
pass 7 in as the value of e, and you may want to be robust in
the face of this *unspecified* behavior.
sorry, i don't care about unspecified/undefined behavior triggered
by users glitches. it's not a problem of my library.
In practice, this warning from GCC is keyed off what it thinks the
effective range of E is. If it starts assuming that e can only
have the values { 0, 1 }, it will also stop warning about the missing
case. It would be hard to stop emitting the warning without making
that assumption, and it may not be easy to make the assumption, but
still avoid the expensive masking operations.
i'm not familiar with gcc internals. for me enum looks like a set
and detecting missed `case' is a basic operation from set theory.
finally, if PR/28236 is valid then (according to the current discussion)
it should be marked as suspended or resolved/wontfix with appropriate
note.
BR,
Pawel.
[c++] switch ( enum ) vs. default statment.
Hi,
Please consider following testcase which is a core of PR c++/28236.
typedef enum { X, Y } E;
int f( E e )
{
switch ( e )
{
case X: return -1;
case Y: return +1;
}
}
In this example g++ produces a warning:
e.cpp: In function ‘int f(E)’:
e.cpp:9: warning: control reaches end of non-void function
Adding `default' statemnet to `switch' removes the warning but
in C++ out-of-range values in enums are undefined.
I see no reason to handling any kind of UB ( especially this ).
IMHO this warning is a bug in C++ frontend.
Comments are appreciated.
BR,
Paweł.
Re: Possible bug with __attribute__((constructor)) and static libraries
Dnia wtorek, 29 sierpnia 2006 10:37, TongKe Xue napisał: If I make module.o into libmodule.a and then link libmodule.a, the function does not get called. use -Wl,-whole-archive (man ld)
Re: Possible bug with __attribute__((constructor)) and static libraries
$ make
g++ module.cpp -c -O2
ar cq libmodule.a module.o
g++ test.cpp module.o -o from-object
g++ test.cpp -Wl,--whole-archive libmodule.a -Wl,--no-whole-archive \
-o from-lib
$ ./from-object
Yay life is good.
$ ./from-lib
Yay life is good.
#include module.hpp
#include iostream
using namespace std;
void foo()
{
cout Yay life is good. endl;
}
#include module.hpp
int main()
{
return 0;
}
void foo() __attribute__((constructor));
default:
g++ module.cpp -c -O2
ar cq libmodule.a module.o
g++ test.cpp module.o -o from-object
g++ test.cpp -Wl,--whole-archive libmodule.a -Wl,--no-whole-archive -o from-lib
