[Bug c/87153] New: Confusing / Incorrect clobber warning with ISRA / -Wclobber
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87153 Bug ID: 87153 Summary: Confusing / Incorrect clobber warning with ISRA / -Wclobber Product: gcc Version: 8.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: chris at bubblescope dot net Target Milestone: --- Created attachment 44628 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44628=edit Preprocessed file which produces clobbering warning I am getting the following warning from code, compiling with -Os -Wclobbered src/read.c: In function ‘EvalRef.isra.25’: cc1: warning: argument ‘ISRA.312’ might be clobbered by ‘longjmp’ or ‘vfork’ [-Wclobbered] EvalRef is defined as: static UInt EvalRef(const LHSRef ref, Int needExpr) Which fdump-tree-all, preprocess.c.225t.switchlower shows as: EvalRef.isra.25 (const REFTYPE ISRA.310, const UInt ISRA.311, const UInt ISRA.312, Int needExpr) So, there are (I feel) two issues. Firstly, the warning isn't helpful as it references a gcc-introduced function. Also I still don't see how ISRA.312 could get clobbered, as it is const. Unfortunately I have tried and failed to produce a small reproducable case of this. I attach a preprocessed source file, made with gcc 8.0.1 on Ubuntu 18.04, from the current master branch of https://www.github.com/gap-system/gap
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 --- Comment #2 from Chris Jefferson chris at bubblescope dot net --- Investigating
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 --- Comment #3 from Chris Jefferson chris at bubblescope dot net --- Can I just confirm I am testing this code correctly? caj@caj-laptop ~/Downloads g++ BVH_Example.cpp -O0 caj@caj-laptop ~/Downloads ./a.out Brute force distance = 0.00428018, calls = 1 BVH distance = 0.00428018, calls = 756 caj@caj-laptop ~/Downloads g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.8/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.8.2-10' --with-bugurl=file:///usr/share/doc/gcc-4.8/README.Bugs --enable-languages=c,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.8 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.8 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.8-amd64 --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.8-amd64 --with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --with-arch-32=i586 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.8.2 (Debian 4.8.2-10)
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 --- Comment #5 from Chris Jefferson chris at bubblescope dot net --- Also tried with svn head, the code works (and passes using valgrind as well) caj@caj-laptop ~/Downloads /gcc-svn/bin/g++ -v Using built-in specs. COLLECT_GCC=/gcc-svn/bin/g++ COLLECT_LTO_WRAPPER=/gcc-svn/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-svn/configure --prefix=/gcc-svn --enable-languages=c,c++ Thread model: posix gcc version 4.9.0 20131219 (experimental) (GCC)
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 --- Comment #6 from Chris Jefferson chris at bubblescope dot net --- Wait a minute, I am getting my timeline wrong, sorry. This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58800 , which will be fixed for 4.8.3
[Bug libstdc++/59557] [4.8/4.9 Regression] Miscompilation after libstdc++ change
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59557 --- Comment #10 from Chris Jefferson chris at bubblescope dot net --- It's a dup -- debian have backported the fix to 4.8.2.
[Bug libstdc++/57916] Improve std::sort partitioning by explicitly employing the pivot
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57916 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net --- Comment #5 from Chris Jefferson chris at bubblescope dot net --- I have not carefully analysed this, but it might be worth changing the names of methods you change if interaction between the old and new methods could break std::sort, as when code compiled using different versions of the library is linked, the linker will choose one version of each function at random. As I say, I haven't looked carefully enough to see if this is a real problem (sorry).
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #13 from Chris Jefferson chris at bubblescope dot net --- Created attachment 30861 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30861action=edit Sort patch Wow, this an embarrassing bug to get through testing. Obviously not enough profiling done! This patch (I hope) gets performance back to g++-4.4 levels, and in my experiments slightly (but not noticeably) better. I would be interested in anyone trying out this patch on their own data. For the interested, here is a description of the bug. I will assume you understand quicksort! Quicksort requires taking a pivot, then partitioning the array by that pivot. Getting O(n log n) behaviour requires that you choose a good pivot. Like most people, in g++ we choose the median of the first, middle, and last value in the array as the pivot. In the C++03 world, after we chose the pivot we took a copy of it. In C++11, we cannot copy values in std::sort any more, only move and swap. Trying to keep track of the pivot as it moves around during the partitioning is horrible and inefficient. So, I had the bright idea to do swap(*first, *pivot). Now the pivot is at the first location in the array, and we can just partition [first+1, end) and the partitioning is fine. See the mistake yet? The bug comes when we recursively partition the first cell. We again choose the median from the first, mid and last of this cell, but *first is always the biggest thing in the cell (as we pivoted on it one level above), meaning our median calculation is unbalanced and often chooses terrible values, leading to us often hitting the O(n^2) behaviour of quicksort (actually we technically get o(n log n), as we switch to heapsort when things are going badly, but the time is still bad). There are a selection of ways of fixing this. This patch switches the median calculation from considering then first, mid, last locations to on first+1, mid, last-1 (there is no reason in this bug to consider last-1 instead of last, but I thought it wouldn't do any harm, and might avoid other issues of accidentally choosing a bad pivot.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #16 from Chris Jefferson chris at bubblescope dot net --- Indeed, if std::sort had never used lower-level partitioning to get the pivot in the correct location, we would never have had this problem in the first place! This is not too serious a problem performance-wise (as the pivot ends up in the right place fairly quickly), but it would certainly be better to do that in future. Unfortunately doing this requires changing quite a few functions, to make all code which uses partition skip over the pivot value. I would suggest my current patch (which is simpler than it looks from the diff) for previous versions, then investigate pivot. In general I would like to modernise the sort to match more modern thoughts on sorting such as making use of partly sorted data (which would include reverse-ordered). The only problem there is satisfying all the requirements of std::sort). (detail: -p doesn't help, you just get things like -110,16 +112,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION. Neither -u 10, -x -u 10 or -x -u 10 seem to work, I just get errors. If you can give me the exact svn diff command to run to get nicer output, I am happy to do so).
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #20 from Chris Jefferson chris at bubblescope dot net --- Created attachment 30867 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30867action=edit Performance tests for sort This is some performance tests for performance checking. Sorry for tar rather than patch, just pop them in performance/25_algorithms. I decided to check stable_sort and heap_sort as well as just sort, just to check nothing else got broken at the same time (turns out, nothing else did). Not sure exactly what the appropriate memory / time tradeoffs are for the performance test suite, so any comments welcome.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #7 from Chris Jefferson chris at bubblescope dot net --- I will look at this next week. Quicksorts are always suboptimal for mostly sorted (forwards or backwards) data, and it would be nice to fix that.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #19 from Chris Jefferson chris at bubblescope dot net --- (In reply to Mitsuru Kariya from comment #15) Created attachment 30775 [details] Patch For your convenience, I attached a patch for this problem. This algorithm is always scanned to reverse order. If a scan fails in less than enough, a re-scan is performed from the point that advanced necessary elements from the original starting point. For example, if __count is 20 and a scan fails after 18 elements succeeded, a re-scan is performed from the point that advanced 2 elements. This patch is good, but takes a different route., trying to always skip as far forwards as possible. On a small test (compiling the 'search_n/iterator.cc' test, disabling forward checking and bidirection tests, increasing TEST_DEPTH to 23, compiling -O3): Both implementations pass correctness and number of comparison tests. Mitsuru's code is about 1K smaller. My code is slightly faster (3.74sec vs 4.12sec) I think I might choose Mitsuru's code, as his code is smaller in terms of both source and binary, and the performance difference is not that big, but either would be fine.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #22 from Chris Jefferson chris at bubblescope dot net --- Her are some comparisons. Just to compare, I also checked doing away with skipping optimisations altogether. Binary sizes (-O3, stripped) current head: 11928 my code: 12248 Mitsuru: 11384 No skip: 10904 Timing: current head: 3.70 my code: 3.70 Mitsuru: 4.04 No skip: 15.37 So we clearly want to do skipping. The tradeoff is between same speed and bigger executables (my code) or ~10% slower but saving 1K or so binary and some source (Mitsuru's code). I don't know what gcc/libstdc++'s general direction in that area is. I actually would expect Mitsuru's code to be faster (as it tries harder to skip forwards), but it is hard to predict how these things interact with optimisers/caches/branch predictors at a low level.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #4 from Chris Jefferson chris at bubblescope dot net --- Just to say I see this, and fortunately it's not hard to keep the optimisation and meet the complexity requirements. Expect patch later today.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #6 from Chris Jefferson chris at bubblescope dot net --- I have a patch I believe fixes this, but trunk doesn't currently build on my machine (Bug 58340). I'll wait for that to get fixed. It is annoying there is still separate predicate and non-predicate copies of every function.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #13 from Chris Jefferson chris at bubblescope dot net --- Created attachment 30767 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30767action=edit Bug patch Patch attached. This features: 1) As well as checking backwards when we find a match, check forwards too. Improve so we never do more than n checks in an array of size n. 2) Improve the existing tester (which tries all arrays up to length 15) to check the number of predicate calls. 3) Add the test included in this bug as a new test, just for completeness.
[Bug libstdc++/58358] [4.7/4.8/4.9 Regression] search_n has a Complexity violation for random access iterator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58358 --- Comment #14 from Chris Jefferson chris at bubblescope dot net --- (In reply to Marc Glisse from comment #12) Chris, did you consider applying this optimized code to bidirectional iterators and not just random access iterators? We may end up doing a few more ++/-- than necessary, but not by more than a factor 2 I believe, and we would often save many calls to the predicate. Something may also be doable for forward iterators, but that's more complicated for less gain and couldn't share the same code. I considered this, but as you say this would slow things down in some cases, and I've found bugs which cause slowdowns in any situation tend to have serious problems getting accepted.
[Bug c++/57638] New: warning container: 'integer_cst’ not supported by dump_type#type error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57638
Bug ID: 57638
Summary: warning container: 'integer_cst’ not supported by
dump_type#type error
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris at bubblescope dot net
The following code (notice the function takes a long long, the template takes
an int. This code is invalid)
templateint x
struct S {};
templatelong long i
void g(Si);
void f()
{
S1000 t;
g(t);
}
Produces the warning (in svn head and 4.7.0)
t.cc: In function ‘void f()’:
t.cc:11:8: error: no matching function for call to ‘g(S1000)’
g(t);
^
t.cc:11:8: note: candidate is:
t.cc:6:6: note: templatelong long int i void g(Si)
void g(Si);
^
t.cc:6:6: note: template argument deduction/substitution failed:
t.cc:11:8: note: mismatched types ‘long long int’ and ‘#‘integer_cst’ not
supported by dump_type#type error’
g(t);
^
t.cc:11:8: note: ‘S1000’ is not derived from ‘Si’
[Bug libstdc++/56367] New: unordered containers behave badly with NaN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56367 Bug #: 56367 Summary: unordered containers behave badly with NaN Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: ch...@bubblescope.net After reading about a similar problem in Python, I decided to try putting multiple NaNs into an unordered_setdouble, and found that I can insert multiple NaNs. This is not surprising, as NaNs compare as not equal. I'm not sure what we should do about this. Based on my reading of the standard putting NaNs in unordered containers isn't legal, but we could add checks in debug mode. Certainly, users ending up with NaNs in containers causes all kinds of problems (although of course there are other standard issues with comparing doubles for equality anyway).
[Bug libstdc++/55841] Unexpected behavior from STL's queue
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55841 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #1 from Chris Jefferson chris at bubblescope dot net 2013-01-01 20:21:13 UTC --- I agree this behaviour might be annoying, but but there is no chance of it being changed, for efficency reasons. You will hey the same behaviour on all standard containers. For debugging purposes, look at the libstdc++ debugging mode, which will catch these types of errors. However, I would not recommend using debug mode in released applications.
[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 --- Comment #6 from Chris Jefferson chris at bubblescope dot net 2012-04-23 09:44:11 UTC --- Yes, will check.
[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 --- Comment #7 from Chris Jefferson chris at bubblescope dot net 2012-04-23 09:57:12 UTC --- While I haven't yet got a recent copy of gcc trunk compiled, it does indeed look like an out-of-bounds error, but just a 'testsuite' problem. At the top of both mem_check tests as a 'const int A[]' array with 29 elements, which we read 30 elements of. If doesn't matter what the extra element is, we just want an array of any 30 integers, which is why this hasn't caused problems before.
[Bug testsuite/53046] [4.8 Regression] New libstdc++ test failures
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53046 --- Comment #9 from Chris Jefferson chris at bubblescope dot net 2012-04-23 10:54:57 UTC --- Looking at the output of -fdump-tree-all, it looks like the compiler optimises the loop which accesses an array out of bounds to: while(true); Is this expected behaviour? That seems like terrible output for every situation...
[Bug libstdc++/51965] Redundant move constructions in heap algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51965 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #2 from Chris Jefferson chris at bubblescope dot net 2012-01-23 14:04:43 UTC --- From my memory of originally writing this, from the old non-moving version, these moves were originally copies. The reason I believe those moves are there is because in some cases the original location is written over. For example trace the behaviour of push_heap / __push_heap. I'm not saying your patch is wrong, and I can't currently compile a g++ svn head to check, but have you run the tester with your patch, and have you checked the logic carefully to make sure you can't scribble over the value in the algorithm? There may will still be a way of reducing the work to just one move of course, at the start of the algorithm. Sorry if you have already considered this, but I remember bits of this being subtle.
[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 --- Comment #36 from Chris Jefferson chris at bubblescope dot net 2012-01-09 21:45:10 UTC --- By your reasoning, FreeBSD really may as well take out code which requires __cplusplus == 201103L , as no compiler will support all of C++11 for several years I am sure. I would be happy to help work on a patch for that if you like.
[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 --- Comment #40 from Chris Jefferson chris at bubblescope dot net 2012-01-09 22:45:32 UTC --- There are several C++11 features which clang does not support, which g++ does. clang also defines __cplusplus == 201103L, despite not implementing large parts of the C++11 standard. Worse, clang does not have an equivalent of fixincludes, so if these g++-only features were used, with clang you would be stuck with uncompilable code. Perhaps the change to c++11 should have been done differently, but if we did what you suggest we would be no better off, as no compiler (not g++, not clang, not visual studio, not icc) would define __cplusplus == 201103L for several years. In fact, no open source compiler would yet have defined it for C++03! However, I can see this conversation is going around in circles.
[Bug bootstrap/51705] [4.7 Regression] FreeBSD uses unsupported C++11 features when __cplusplus == 201103L
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 --- Comment #43 from Chris Jefferson chris at bubblescope dot net 2012-01-09 22:59:49 UTC --- g++ only does this while compiling the C++ standard library. clang doesn't come (by default) with a C++ standard library, so you have to use either libstdc++ (from g++) or libc++. While compiling libc++ (which is clang's implementation of the standard library), clang is invoked with -std=c++0x. So clang is in exactly the same state as g++ it seems to me.
[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #3 from Chris Jefferson chris at bubblescope dot net 2011-12-29 20:56:20 UTC --- Better take out C++03 support as well, seeing as there is no support for the 'export' keyword. But seriously, the C++11 support is as complete as any other compiler, and in common usage. Further, parts of libstdc++ need to be built in C++0x mode.
[Bug libstdc++/51705] Build infrastructure should not use -std=c++0x until g++ properly supports it
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51705 --- Comment #8 from Chris Jefferson chris at bubblescope dot net 2011-12-29 22:21:35 UTC --- (In reply to comment #4) On Thu, Dec 29, 2011 at 08:56:20PM +, chris at bubblescope dot net wrote: Better take out C++03 support as well, seeing as there is no support for the 'export' keyword. But seriously, the C++11 support is as complete as any other compiler, and in common usage. Further, parts of libstdc++ need to be built in C++0x mode. Please, re-read Ed's comment #2. g++ is telling the OS that yes, I support C++11, when in fact it does not. For me, this means I can no longer work on gfortran until some work-around is in place to avoid this bug in g++. Please read my comment. You could make the same argument that using g++ should not report as supporting C++03, as it does not support the 'export' keyword and you could use this in headers. It is likely to be a very long time until g++ supports every single corner case of C++11. Based on our experience with C++03, it may never happen.
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 --- Comment #13 from Chris Jefferson chris at bubblescope dot net 2011-12-06 10:13:56 UTC --- You can if you like, but if you haven't started yet, I plan on having a patch ready in about... 2 hours?
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 --- Comment #16 from Chris Jefferson chris at bubblescope dot net 2011-12-06 14:25:24 UTC --- Created attachment 26006 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26006 Piecewise patch Patch to make piecewise_construct work properly on std::pair.
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 --- Comment #18 from Chris Jefferson chris at bubblescope dot net 2011-12-06 14:41:19 UTC --- 2011-12-06 Chris Jefferson ch...@bubblescope.net PR libstdc++/51183 * include/std/tuple (pair::pair): Add two constructors which use delegating constructors (pair::__cons, pair::__do_cons): Remove unused functions. * include/std/stl_pair.h (pair::pair): Add declarations for constructors which use delegating constructors. (pair::__cons, pair::__do_cons): Remove unused declarations. * testsuite/20_util/pair/51183.cc: New.
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 --- Comment #10 from Chris Jefferson chris at bubblescope dot net 2011-12-05 16:25:13 UTC --- Oh, and one other tiny detail, I've about given up trying to understand corner cases in the name look-up rules in C++, so I'd probably std:: qualify those 'get's, just to be on the safe side. Although I think this is one case where things are OK.
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 --- Comment #9 from Chris Jefferson chris at bubblescope dot net 2011-12-05 16:19:40 UTC --- The only difference in the version I wrote was that I passed the arguments into the explicit constructor as non-const references, rather than by value with std::move, which should be more efficent for types without a move constructor. However, there really isn't very much choice in how you implement this. Jonathan, if you are already off writing tests and ready to commit, I'm happy to let you finish, else I could write some tests and submit a patch.
[Bug libstdc++/51183] pair piecewise_construct_t constructor copies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51183 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #1 from Chris Jefferson chris at bubblescope dot net 2011-11-17 09:11:02 UTC --- This was necessary because (I believe) it is impossible to implement the piecewise_construct_t constructor without compiler support for forwarding constructors. Last time I checked, they hadn't been implemented yet. If they have been implemented, I can supply the code to make this work correctly.
[Bug c++/50462] New: Particularly painful error message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50462
Bug #: 50462
Summary: Particularly painful error message
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ch...@bubblescope.net
The following code (note that the call to 'size' is missing () ) produces a
particulaly painful error message:
#include iostream
struct V
{
int size() {};
int size() const {};
};
void print(V v)
{ std::cout v.size; }
Error message:
t.cc: In function ‘void print(V)’:
t.cc:10:18: error: no match for ‘operator’ in ‘std::cout v.V::size’
t.cc:10:18: note: candidates are:
/usr/include/c++/4.6/ostream:110:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::basic_ostream_CharT, _Traits::__ostream_type
(*)(std::basic_ostream_CharT, _Traits::__ostream_type)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:110:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to
‘std::basic_ostreamchar::__ostream_type
(*)(std::basic_ostreamchar::__ostream_type)’
/usr/include/c++/4.6/ostream:119:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::basic_ostream_CharT, _Traits::__ios_type
(*)(std::basic_ostream_CharT, _Traits::__ios_type)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar, std::basic_ostream_CharT,
_Traits::__ios_type = std::basic_ioschar]
/usr/include/c++/4.6/ostream:119:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to
‘std::basic_ostreamchar::__ios_type
(*)(std::basic_ostreamchar::__ios_type)’
/usr/include/c++/4.6/ostream:129:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(std::ios_base (*)(std::ios_base)) [with _CharT = char,
_Traits = std::char_traitschar, std::basic_ostream_CharT,
_Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:129:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘std::ios_base
(*)(std::ios_base)’
/usr/include/c++/4.6/ostream:167:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(long
int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:167:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘long int’
/usr/include/c++/4.6/ostream:171:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(long
unsigned int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:171:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘long unsigned int’
/usr/include/c++/4.6/ostream:175:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(bool)
[with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:175:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘bool’
/usr/include/c++/4.6/bits/ostream.tcc:93:5: note: std::basic_ostream_CharT,
_Traits std::basic_ostream_CharT, _Traits::operator(short int) [with
_CharT = char, _Traits = std::char_traitschar]
/usr/include/c++/4.6/bits/ostream.tcc:93:5: note: no known conversion for
argument 1 from ‘unresolved overloaded function type’ to ‘short int’
/usr/include/c++/4.6/ostream:182:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT, _Traits::operator(short
unsigned int) [with _CharT = char, _Traits = std::char_traitschar,
std::basic_ostream_CharT, _Traits::__ostream_type = std::basic_ostreamchar]
/usr/include/c++/4.6/ostream:182:7: note: no known conversion for argument 1
from ‘unresolved overloaded function type’ to ‘short unsigned int’
/usr/include/c++/4.6/bits/ostream.tcc:107:5: note: std::basic_ostream_CharT,
_Traits std::basic_ostream_CharT, _Traits::operator(int) [with _CharT =
char, _Traits = std::char_traitschar]
/usr/include/c++/4.6/bits/ostream.tcc:107:5: note: no known conversion for
argument 1 from ‘unresolved overloaded function type’ to ‘int’
/usr/include/c++/4.6/ostream:193:7: note: std::basic_ostream_CharT,
_Traits::__ostream_type std::basic_ostream_CharT,
_Traits::operator(unsigned int) [with _CharT = char, _Traits =
[Bug libstdc++/49559] [C++0x] stable_sort calls self-move-assignment operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49559 --- Comment #13 from Chris Jefferson chris at bubblescope dot net 2011-06-28 19:16:00 UTC --- I am on holiday until tomorrow night, and away from a computer. Once I get back, I promise to give this my full attention. This code got messy in the first place because I was trying to make minimal changes to already confusing code. I still see if this can be easily cleaned, our if we should use a different method.
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot ||net --- Comment #1 from Chris Jefferson chris at bubblescope dot net 2011-06-13 07:55:33 UTC --- max is a term defiend in the standard library. It is undefined behaviour if you #define it to something else when you are using standard library headers. Don't do that :)
[Bug libstdc++/49386] #undef min/max is dependent on order if #include
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49386 --- Comment #3 from Chris Jefferson chris at bubblescope dot net 2011-06-13 08:15:39 UTC --- Ah yes. This is unfortunate, and I believe tricky to fix at the gcc end. We could in principle add '#undef min, #undef max', but I worry that might break something else. If you '#define NOMINMAX' before including windows.h, that should stop the declarations, although it can break some windows libraries. The other option is to do: #include windows.h #ifdef min #undef min #endif #ifdef max #undef max #endif
[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038 --- Comment #9 from Chris Jefferson chris at bubblescope dot net 2011-03-09 11:28:13 UTC --- Just to say, I am looking at this. Thanks for the small test case.
[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038 --- Comment #14 from Chris Jefferson chris at bubblescope dot net 2011-03-09 11:51:24 UTC --- Ah yes, I see the problem now. The problem is to do with using move_iterator. When we compare two values which we dereference from a move_iterator, then we end up moving into the comparator, which breaks things. Hmm.. to be honest, this seems like a fairly serious practical flaw in move_iterator, removing most of the practical reasons for it's presence in the standard. I'm having a very quick think about the best way to fix this. Will report back shortly.
[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038 --- Comment #17 from Chris Jefferson chris at bubblescope dot net 2011-03-09 13:34:22 UTC --- Created attachment 23599 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23599 Patch to make stable_sort work with comparitors that take by value.
[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038 --- Comment #18 from Chris Jefferson chris at bubblescope dot net 2011-03-09 13:34:51 UTC --- Just to update: I have checked other users of MOVE_ITERATOR (there are only two) and they appear fine, as they do not use a comparator. Attached is an initial patch. Very sorry if the formatting (particular tabs) are off, I am using a different texteditor to normal and am having trouble configuring correctly. This patch might look quite long but it is actually fairly minimal. Basically we introduce methods __move_merge_backward and __move_merge, which act similarly to merge but move values. We call the comparitor methods without any moving, so they behave themselves. __merge_backward was only ever used with arguments that move, so I have renamed it to __move_merge_backward for clarity and changed the places it is called. Also introduce __move_merge which is identical to std::merge, except it moves values into place rather than copies them. Then fix all places which call merge or __merge_backward with MOVE_ITERATORS to use the new methods. Finally, there is a little testcase. As a sanity check, I would like to make sure that other types (the other sorts being the obvious target) also work correctly. I can't imagine why they wouldn't, but I'm very suprised this broke!
[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038 --- Comment #19 from Chris Jefferson chris at bubblescope dot net 2011-03-09 13:35:48 UTC --- Ignore that patch, there is a problem with it (tester wasn't working properly). Sorry.
[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038 Chris Jefferson chris at bubblescope dot net changed: What|Removed |Added Attachment #23599|0 |1 is obsolete|| --- Comment #20 from Chris Jefferson chris at bubblescope dot net 2011-03-09 15:25:19 UTC --- Created attachment 23602 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23602 Stable sort patch with testcases Corrected patch. This is designed the same as the first one, just with some typos fixed. I have added some more tests for the various sorting algorithms, just so we can keep an eye on things.
[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038 --- Comment #26 from Chris Jefferson chris at bubblescope dot net 2011-03-09 15:58:24 UTC --- But, the first line of the method (of all the methods) is: VERIFY(rh.ok); So, we know it's true. That might still look more consistent/clear. Very sorry about the formatting. If this can wait until tomorrow I can get to a computer with a better editor. It's time like this I wish I'd ever bothered to learn emacs or vim, or some other editor that runs on all machines and won't mangle tabs.
[Bug libstdc++/48038] [C++0x] stable_sort problem with C++0x and comparator by value
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48038 --- Comment #29 from Chris Jefferson chris at bubblescope dot net 2011-03-09 16:07:15 UTC --- Created attachment 23604 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23604 Changelog for stable sort change Changelog I've put Jonathan in here, because part of the test case is his example, copy+pasted.
[Bug c++/44623] ICE on invalid code
--- Comment #1 from chris at bubblescope dot net 2010-06-22 06:46 --- Created an attachment (id=20972) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20972action=view) ICEing invalid code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44623
[Bug c++/44623] New: ICE on invalid code
The attached invalid code causes an ICE on svn trunk. It passes on g++ 4.4.3 The error I get is: c...@nyanko:/dev/shm/clang-fuzzer$ /gccsvn/bin/g++ t.cc t.cc:3:137: warning: missing terminating character [enabled by default] t.cc:3:1: error: missing terminating character t.cc:3:20: error: two or more data types in declaration of â#128;#152;parameterâ#128;#153; t.cc:3:135: internal compiler error: in tsubst, at cp/pt.c:10121 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: ICE on invalid code Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44623
[Bug c++/44609] New: Invalid code causes ICE
The following code is reduced from a usage of boost, where one word was spelt incorrectly. My code reducer has done some very unusual things while reducing the size of the test case. The following code, on my code, causes g++ to spend 1 minute outputting 16 million lines, then eventually ICEing. It seems to be a problem with recursive templates, but it would be nicer if g++ gave up a little earlier. Confirmed on g++ 4.4 and svn trunk. -- Summary: Invalid code causes ICE Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug c++/44609] Invalid code causes ICE
--- Comment #1 from chris at bubblescope dot net 2010-06-21 11:50 --- Created an attachment (id=20959) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20959action=view) ICEing example -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug c++/44609] Invalid code causes ICE
--- Comment #3 from chris at bubblescope dot net 2010-06-21 12:10 --- Many apologises, the computer had a ulimit set which I had not noticed. Yes, I also get an infinite loop rather than an ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug c++/44609] Invalid template code causes infinite loop of error messages
--- Comment #6 from chris at bubblescope dot net 2010-06-21 14:35 --- Of course, there is a big difference between an ICE and an infinite loop. Also, bug which causes ICEs on one computer and not another need treating with great care, as that suggests unpredictable memory corruption may be occurring. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44609
[Bug libstdc++/44068] std::map deals with keys of objects that were not constructed
--- Comment #2 from chris at bubblescope dot net 2010-05-10 22:44 --- Your operator is not valid. It must be a strict-weak ordering. In particular, it must not be possible that A B and B A, but in your code this is possible. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44068
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #2 from chris at bubblescope dot net 2010-04-20 17:10 --- I think this is connected to the suppress warning is the standard library pragma starting to actually work. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #4 from chris at bubblescope dot net 2010-04-20 17:18 --- Yes, in C++0x mode, we should just add a deprication warning for auto_ptr full stop. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug libstdc++/43820] [4.4/4.5/4.6 Regression] auto_ptr used with incomplete type no longer triggers warning
--- Comment #9 from chris at bubblescope dot net 2010-04-20 18:53 --- I don't think it's a front-end issue. '#pragma GCC system_header' is specifically designed to stop warnings in headers. However, it stops 'good' warnings as well as 'bad' warnings. 'system_header' could be extended to allow (or disallow) specific warnings, but that seems like quite a major extension. Romain: -Wsystem-headers will enable warnings in standard library types. However note that you will get some warnings thrown up, which you won't be able to work around. The only real patch I can think of would be to avoid '#pragma GCC system_header' being defined in C++03 mode, in memory. That would be a simple patch like the below. The only problem is that this might left some other warnings sneak back in. Something like (untested, sorry). Index: memory === --- memory (revision 158569) +++ memory (working copy) @@ -44,7 +44,9 @@ #ifndef _GLIBCXX_MEMORY #define _GLIBCXX_MEMORY 1 +#ifdef __GXX_EXPERIMENTAL_CXX0X__ #pragma GCC system_header +#endif /** * @defgroup memory Memory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43820
[Bug libstdc++/43595] std::unique incorrectly assumes transitive property on functor, operator==
--- Comment #1 from chris at bubblescope dot net 2010-03-31 08:09 --- Fixing this would make std::unique quite a bit less efficient. I personally believe the intention was always to make it an equivalence relation and as you say C++0x tightens up the condition. If this had come up 5 or 6 years ago, I might have suggested fixing it, but changing it now would produce an incompatibility between our C++03 and C++0x implementations unnecessarily. Does any other compiler get this right? If they did that would make a more convincing case, but I'm fairly sure they don't. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43595
[Bug c++/43382] ICE on C++0x code
--- Comment #2 from chris at bubblescope dot net 2010-03-16 08:38 ---
Reduced testcase:
templateclass T
struct Container
{ T f() const; };
templateclass T
T deref(const T t)
{ return t; }
template class T, class... Args
auto
deref(const T u, int r, Args... args)
- decltype(deref(u.f(), args...))
{ return deref(u.f(), args...); }
int main(void)
{
ContainerContainerint v;
deref(v,1,2);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43382
[Bug c++/43382] New: Internal error on C++0x code
The following code causes an assert on a recent svn g++, with -std=c++0x. On
g++ 4.4 it produces an error. I believe the code to be valid, but am not 100%
positive.
#include vector
struct Range
{
int lb;
int ub;
Range(int i, int j) : lb(i), ub(j) {}
Range(const Range r) = default;
Range() = default;
};
templateclass T
T deref(const T t)
{ return t; }
template class T, template typename T, typename... class Cont,
class... Args
auto
deref(const ContT u, int i, Args... args)
- decltype(deref(u[i], args...))
{ deref(u[i], args...); }
template class T, template typename T, typename... class Cont,
class... Args
auto
deref(const ContT u, Range r, Args... args)
- Contdecltype(deref(u[0], args...))
{
typedef decltype(deref(u[0], args...)) member;
Contmember retval;
for(int i = r.lb; i = r.ub; ++i)
{
retval.push_back(deref(u[i], args...));
}
return retval;
}
int main(void)
{
std::vectorstd::vectorstd::vectorint v;
int i = deref(v, 1,2,3);
std::vectorint j = deref(v, 1, Range(1,2), 3);
}
--
Summary: Internal error on C++0x code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43382
[Bug c++/35722] [C++0x] Variadic templates expansion into non-variadic class template
--- Comment #12 from chris at bubblescope dot net 2010-01-22 09:11 ---
Just for anyone who comes to this bug, it can be worked around by doing
something like:
templatetemplate typename... T, typename... Args
struct Join
{ typedef TArgs... type; }
Although of course that isn't a fix (and unfortunately a fix is beyond me).
--
chris at bubblescope dot net changed:
What|Removed |Added
CC||chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35722
[Bug libstdc++/42374] 23_containers/map/operators/1_neg.cc fails test for errors on darwin10
--- Comment #1 from chris at bubblescope dot net 2009-12-15 08:54 --- I see you are building with fink. Looking on the fink website, they do not seem to have a gcc45 package. Where did you get it from? Or has it just not made it to the website yet? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42374
[Bug libstdc++/42242] vector::resize could be split up into two different functions
--- Comment #8 from chris at bubblescope dot net 2009-12-01 19:01 --- The only change in C++0x is that a new function is added, so it won't break any existing code, and we will be able to add it without moving to v7. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42242
[Bug libstdc++/42242] vector::resize could be split up into two different functions
--- Comment #10 from chris at bubblescope dot net 2009-12-01 19:07 --- Anyway, the result of this bug is that the fix to resize() given in the latest draft of C++0x should be applied. The resulting code would only be invoked if you ask the compiler to use C++0x mode, but if care about performance you should be doing this anyway, I suspect your types may well benefit from rvalue references. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42242
[Bug libstdc++/42242] vector::resize could be split up into two different functions
--- Comment #12 from chris at bubblescope dot net 2009-12-01 19:28 --- No need to wait, they are in g++ 4.3 and 4.4, use -std=c++0x to activate features from C++0x. Obviously they are all subject to change, but are now fairly close to standardised. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42242
[Bug c++/41997] [C++0x] constant initializer_list not optimised
--- Comment #2 from chris at bubblescope dot net 2009-11-10 08:14 ---
Sorry, one important thing I missed off my bug report. This problem seems to
just be connected to constant lists. The following is fully optimised away
int i = 1, j = 2;
return max_val({i,j});
As is the following, despite the fact the code never access the third element
of the initializer_list
int i = 1;
return max_val({1,2,i});
So this really seem to be some (mis)optimisation involving constant lists.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41997
[Bug c++/41997] New: constant initializer_list not optimised
In C++0x, constant initializer_lists do not seem visible to the optimiser,
leading to sub-optimal code. Consider as a simple example:
#include initializer_list
int max_val(std::initializer_listint il)
{
int i = *(il.begin());
int j = *(il.begin() + 1);
return (i j ? i : j);
}
int main(void)
{
return max_val({1,2});
}
I would expect 'main' to be reduced to just '2' at a suitable optimisation
level. At -O3 the body max_val is inlined the values {1,2} are not. Is there
some reason constant initalizer_lists cannot be made visible to optimisation?
--
Summary: constant initializer_list not optimised
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
GCC host triplet: i686-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41997
[Bug libstdc++/41803] Compiler forcing iterator to const
--- Comment #4 from chris at bubblescope dot net 2009-10-22 23:14 --- The reason that in general changing the Point a std::multisetPoint::iterator refers to is forbidden is that doing so will break the invariant on which the multiset is based, resulting in random crashes occuring later on. The standard does say, in 23.1.4 paragraph 5 Keys in an associative container are immutable.. Seeing as you know that actually your changes won't break the ordering, what you are doing is legal, and can be done in two ways: 1) Use mutable, as you were already suggesting. 2) Add a const_cast to the 'const point' you get out. I realise this is a little annoying, but it was considered the alternative was too buggy, as most people would just changes things in (multi)sets without realising in most cases it would lead to horribly broken code. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41803
[Bug libstdc++/41645] New: Massive failures in parallel test mode
In 'libstdc++-v3', type 'make check-parallel' and a huge number of tests fail. Some of these are expected, in particular several in 25_algorithm, to do with lack of c++0x support, but most of the failures seem to be related to a string problem. Taking one example (testsuite/26_numerics/complex/inserters_extractors/char/1.cc), I get the error: 1.exe(21140) malloc: *** error for object 0x100019ae0: pointer being freed was not allocated *** set a breakpoint in malloc_error_break to debug And backtrace: #0 0x7fff879fdb91 in malloc_error_break () #1 0x7fff87927083 in free () #2 0x000100094bfa in std::basic_stringbufchar, std::char_traitschar, std::allocatorchar ::overflow (this=0x7fff5fbff428, __c=40) at bits/basic_string.h:236 #3 0x00010009911c in std::basic_streambufchar, std::char_traitschar ::xsputn (this=0x7fff5fbff428, __s=value temporarily unavailable, due to optimizations, __n=13) at bits/streambuf.tcc:97 #4 0x00010008f4b5 in std::__ostream_insertchar, std::char_traitschar (__o...@0x7fff5fbff420, __s=value temporarily unavailable, due to optimizations, __n=13) at streambuf:427 #5 0x000100053aac in std::operator float, char, std::char_traitschar (__...@0x7fff5fbff420, __x=value temporarily unavailable, due to optimizations) at bits/basic_string.h:2539 #6 0x0001521d in test01 () #7 0x00015cd8 in main () All the errors seem to be similarly related to string. The standard 'make check' works fine, as does the compiler in general use. This problem seems to be connected to libtestc++.a (If I remove it when compiling the test, the result works fine), but I am not sufficiently expert on linking to figure out exactly what is going wrong. -- Summary: Massive failures in parallel test mode Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris at bubblescope dot net GCC build triplet: x86_64-apple-darwin10.0.0 GCC host triplet: x86_64-apple-darwin10.0.0 GCC target triplet: x86_64-apple-darwin10.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645
[Bug libstdc++/41645] Massive failures in parallel test mode
--- Comment #2 from chris at bubblescope dot net 2009-10-09 12:57 --- I shall try to track it down -- it wouldn't suprise me if this is a snow leopard bug, as there has been a few issues with the default system compiler switching from 32-bit to 64-bit. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645
[Bug libstdc++/41645] Massive failures in parallel test mode
--- Comment #4 from chris at bubblescope dot net 2009-10-09 13:21 ---
I have confirmed that after compiling with 'make check-parallel', the code:
#include string
int main(void)
{ string s; s = X; }
Fails when compiled with:
/gccsvn/bin/g++ test.cc libtestc++.a -fopenmp
Fails with the same error message.
I wonder if somehow this is connected to:
http://www.cocoabuilder.com/archive/message/cocoa/2009/9/17/245285, which
suggests on snow leopard the standard system library is built differently, with
_GLIBCXX_FULLY_DYNAMIC_STRING enabled. I would assume the system library
shouldn't be used at all however.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645
[Bug libstdc++/41645] Massive failures in parallel test mode
--- Comment #6 from chris at bubblescope dot net 2009-10-09 14:16 --- Ah yes, something I should have tried earlier. The resulting compiler generally works fine, until I add -D_GLIBCXX_PARALLEL, when things break. I only seem to get a problem when I have enough optimisation to inline functions. -O0 works fine -O1 breaks -O1 -fno-inline works fine Which is a shame, as it makes debugging that much harder. The same problem occurs with _GLIBCXX_DEBUG, so actually this isn't related to parallel, sorry for the false alarm. I assume it's related to extern templates, but I'm not sure how exactly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645
[Bug libstdc++/41645] Massive failures in parallel test mode
--- Comment #7 from chris at bubblescope dot net 2009-10-09 14:20 --- Further: If I add -D_GLIBCXX_FULLY_DYNAMIC_STRING, the code compiles fine! However, if I run otool on my executable, it says it is linked with: Load command 10 cmd LC_LOAD_DYLIB cmdsize 64 name /newgccsvn/lib/libstdc++.6.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 7.14.0 compatibility version 7.0.0 Load command 11 cmd LC_LOAD_DYLIB cmdsize 56 name /newgccsvn/lib/libgcc_s.1.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 1.0.0 compatibility version 1.0.0 Load command 12 cmd LC_LOAD_DYLIB cmdsize 56 name /usr/lib/libSystem.B.dylib (offset 24) time stamp 2 Thu Jan 1 01:00:02 1970 current version 124.1.1 compatibility version 1.0.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645
[Bug libstdc++/41645] Massive failures in parallel test mode
--- Comment #10 from chris at bubblescope dot net 2009-10-09 15:10 --- To sum up the current state, as things are getting confusing: Compiling 'testsuite/21_strings/basic_string/inserters_extractors/char/1.cc -I testsuite/util -O2' using /newgccsvn/bin/g++ (recent svn compile) or /usr/bin/g++ (Apple's gcc 4.2.1) No flags: Fine -D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG): Fails -D_GLIBCXX_PARALLEL (or _D_GLIBCXX_DEBUG) -D_GLIBCXX_FULLY_DYNAMIC_STRING : Works I built my compiler with: ../gccsvn/configure --enable-languages=c,c++ --prefix=/newgccsvn make make install Using otool -l (an Apple system utility), it looks like when I use the system compiler I get linked against /usr/lib/libstdc++.6.dylib, and when I use /newgccsvn/bin/g++ I get linked against /newgccsvn/lib/libstdc++.6.dylib So there seems to be two issues: 1) Someone in Apple has completely broken their standard library by turning on _GLIBCXX_FULLY_DYNAMIC_STRING and worse not putting that in the headers, which is breaking _GLIBCXX_DEBUG builds and I imagine will cause some other nastyness. 2) For some reason I cannot figure out, this is somehow 'leaking' into my build. Apologises for a few wild goose-cases along the way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645
[Bug libstdc++/41645] Massive failures in parallel test mode
--- Comment #12 from chris at bubblescope dot net 2009-10-09 17:51 --- LD_LIBRARY_PATH doesn't exist on Mac. Usually linking libraries together 'just works', but in this case it seems to have broken. By configuring with --enable-fully-dynamic-string, I get a working compiler (actually better than the system compiler, as now -D_GLIBCXX_DEBUG works) so I'm happy for now. Someone who is better with linking-fu than me should probably at some point look at just what Apple has managed to mess up however. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41645
[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement
--- Comment #26 from chris at bubblescope dot net 2009-10-04 21:50 --- Just to follow up on an earlier comment, I've tested this patch with a new improved std::rotate test (to be submitted shortly) which tests all rotations and positions up to length 20, and it passes fine. Further, it also passes all C++0x move-only tests, as it only uses iter_swap. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
[Bug libstdc++/41448] std::sort on std::vectorfloat with certain values leads to segfault in the vector destructor
--- Comment #8 from chris at bubblescope dot net 2009-09-29 11:04 --- Just to clarify, it is not a memory leak which is occurring, it is memory corruption. Basically when std::sort is given a type which is not totally ordered as required, it tends to corrupt the memory immediately before and after the given array. There are a few ways in which this could be detected, but if it was detected it's not obvious what the behaviour should then be, and obviously it would (slightly) slow down std::sort when given 'correct' types. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41448
[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement
--- Comment #19 from chris at bubblescope dot net 2009-09-15 14:45 --- I think this generally looks good. The testsuite could do with some improvement, there are quite a lot of cases for this algorithm, and it's probably worth testing they all work properly. I unfortunately cam't execute the code at the moment so I apologise if this is wrong, but it looks like the existing code works fine with std::rotate(NULL,NULL,NULL), while yours will break. It's not even completely clear if this should work, but as a QOI issue it would probably be nice if it did. In general, checking all rotates of length 0 to 10ish would I think be a nice check that your code works properly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement
--- Comment #1 from chris at bubblescope dot net 2009-09-14 07:24 --- In C++0x, this problem will go away, because move constructors will be used, which leads to the most efficient implementation for both large and small types (assuming they implement a move constructor at least as efficient as swap). However, the wording is misleading and I might see if it can be changed. In C++03, being pedantic, I'm not sure if we have to call std::swap, although as you say it would make things go faster for certain types. This wording is used in some other places, for example stable_partition, which cannot be implemented just with std::swap. While you have bought up a obvious case of inefficiency, I would advise leaving it as is, and compiling your code with -std=g++0x on a recent compiler. If you are using standard containers, this should give you faster code, without any changes at all. With your own code, it would require you defining the move constructor and move assignment operators. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement
--- Comment #5 from chris at bubblescope dot net 2009-09-14 17:00 --- You cannot assume the elements you are sorting have a default constructor. You can however certainly use a separate array of indices, and then swap at the end, so I withdraw that comment. However, this also only complicates the problem, as it suggests we should also fix stable_partition. A long time ago I tried improving the standard library to use whichever of swap or copy was more efficent, and ended up effectively reinventing rvalue references using template wrappers. Given any patches would only be in a new version of gcc, as this is not a regression, as we haw never done it properly, would you be happy instead using the c++0x support in those new compiler? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
[Bug libstdc++/41351] std::rotate on RAI does not conform to ISO complexity requirement
--- Comment #7 from chris at bubblescope dot net 2009-09-14 18:11 --- Only a svn copy of stl_algo.h has the rvalue reference stuff for stable_partition. We use a number of macros, like _GLIBCXX_MOVE, to wrap various parts of the algorithms, so they work in both c++03 and c++0x. It is a requirement of c++0x that algorithms like rotate and stable_partition work with move-only types, so the current implementations never copy at all. I believe, without evidence, that these rotate / stable_partition implementations will be as fast as maintaining a separate pointer list when sorting a range of vectorints, for example. Of course a new implementation of any algorithm which satisfies all the standard requirements, and is faster than the existing ones in all cases it was used, would I'm sure be greatfully accepted, modulo copyright assignments and the like. Of course this does not help people right now, using C++03. Certainly it is bad how long rotate takes, but similar problems have long existed, to a greater or lesser extent, with many other algorithms including sort and stable_sort. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41351
[Bug libstdc++/1773] __cplusplus defined to 1, should be 199711L
--- Comment #67 from chris at bubblescope dot net 2008-12-19 11:45 --- Sorry to come back to this again. With C++0x just around the corner, is there any chance of getting this fixed, seeing as I expect this should be the standard way of checking if we are in conforming C++0x mode, when it gets released? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1773
[Bug libstdc++/38466] std::swap does not use std::swap for the components of a std::pair
--- Comment #3 from chris at bubblescope dot net 2008-12-10 12:23 --- Sorry, I should have been clearer. the standard forbids this overload of swap by not listing it, unlike most other standard library types, which is lists an overload for. Personally, I'd be happy to just add the overload, but it wouldn't surprise me if it somehow broke someone's code, who had defined their own pair swap, or incorrectly defined swap on one of the members of their pair, although I don't have a good example on me. You can get pair swapping by the very heavy hammer of using a very recent release and -std=g++0x -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38466
[Bug libstdc++/38466] std::swap does not use std::swap for the components of a std::pair
--- Comment #1 from chris at bubblescope dot net 2008-12-09 23:30 --- I agree with you, but unfortunatly the standard doesn't allow std::swap to be defined for std::pair. Stupid I know. C++0x does require that. -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38466
[Bug libstdc++/36885] tuples branch bootstrap failure in libstdc++-v3
--- Comment #4 from chris at bubblescope dot net 2008-07-20 21:12 --- Surely this isn't a libstdc++ bug? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36885
[Bug libstdc++/36363] set_union and _GLIBCXX_DEBUG does not compile
--- Comment #1 from chris at bubblescope dot net 2008-05-29 08:54 --- This works fine for me on a couple of versions. Could you give us the output of ' g++ -v ' ? -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36363
[Bug bootstrap/35938] New: Fixincludes failure with 'make check'
return __stat32(__f, __p); } #if __cplusplus ! } #endif /* __cplusplus */ #endif #endif /* SCO_STATIC_FUNC_CHECK */ --- 56,62 return __stat32(__f, __p); } #if __cplusplus ! } #endif /* __cplusplus */ #endif #endif /* SCO_STATIC_FUNC_CHECK */ *** *** 65,72 /* macro to test for symbolic link */ #define S_ISLNK(mode) (((mode) S_IFMT) == S_IFLNK) fstat(), ! lstat(), /* THE INSERTION LINE FAILS ON BSD SYSTEMS */ #endif /* ULTRIX_STAT_CHECK */ --- 68,76 /* macro to test for symbolic link */ #define S_ISLNK(mode) (((mode) S_IFMT) == S_IFLNK) + fstat(), ! lstat(), /* THE INSERTION LINE FAILS ON BSD SYSTEMS */ #endif /* ULTRIX_STAT_CHECK */ unistd.h /Users/caj/gcc/fixincludes/tests/base/unistd.h differ: char 637, line 29 *** unistd.h2008-04-14 20:09:01.0 +0100 --- /Users/caj/gcc/fixincludes/tests/base/unistd.h 2008-02-26 18:15:40.0 + *** *** 26,33 #if defined( ULTRIX_UNISTD_CHECK ) @(#)unistd.h 6.1 (ULTRIX) getgroups(), ! getpagesize(), fork(), ! vfork(), #endif /* ULTRIX_UNISTD_CHECK */ --- 26,33 #if defined( ULTRIX_UNISTD_CHECK ) @(#)unistd.h 6.1 (ULTRIX) getgroups(), ! getpagesize(), fork(), ! vfork(), #endif /* ULTRIX_UNISTD_CHECK */ Missing header fix: pthread.h There were fixinclude test FAILURES make[2]: *** [check] Error 1 make[1]: *** [check-fixincludes] Error 2 make: *** [do-check] Error 2 -- Summary: Fixincludes failure with 'make check' Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris at bubblescope dot net GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35938
[Bug c++/35904] New: Poor error message
The code:
void grab(int i);
int main(void)
{ grab(1); }
Produces the useful and informative error:
invalid initialization of non-const reference of type int from a temporary
of type int
Whereas the code:
templatetypename T
void grab(T t, int i);
int main(void)
{ grab(1,1); }
Produces the much less useful
no matching function for call to grab(int, int)
Would it be possible to still get the error message about temporaries in the
templated case?
--
Summary: Poor error message
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35904
[Bug libstdc++/35622] Cannot declare vector of unordered_maps
--- Comment #2 from chris at bubblescope dot net 2008-03-18 15:02 ---
#include vector
#include tr1/unordered_map
using namespace std;
int main(void)
{
vectortr1::unordered_mapint,int v;
}
Runs fine here, using:
Using built-in specs.
Target: i386-apple-darwin9.2.0
Configured with: ../gcc/configure --enable-languages=c,c++
--prefix=/Users/caj/gccsvn/
Thread model: posix
gcc version 4.4.0 20080305 (experimental) (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35622
[Bug libstdc++/35541] Legal C++ program can't be compiled with -D_GLIBCXX_DEBUG
--- Comment #2 from chris at bubblescope dot net 2008-03-11 17:08 --- This used to work (works on Apple's gcc 4.0.1). The bug is an inconsistency between __check_sorted_set on lines 317 and 334 and the __check_sorted_set_aux on the lines before The 4 __check_sorted_set_aux methods expect to be pass all the parameters of __check_sorted_set, including the _InputIterator2, even though they never use it. However, it isn't passed by __check_sorted_set, so there is the incorrect number of parameters. As far as I can see, this code can have never worked.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35541
[Bug libstdc++/35541] Legal C++ program can't be compiled with -D_GLIBCXX_DEBUG
--- Comment #3 from chris at bubblescope dot net 2008-03-11 17:12 --- While I'm sure he will be along soon anyway, I shall add Paolo to the CC list of this bug. It looks to me like a simple typo was made while fixing 34730. -- chris at bubblescope dot net changed: What|Removed |Added CC||pcarlini at suse dot de, ||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35541
[Bug libstdc++/31247] std::vector::iterator::value_type is accessible
--- Comment #9 from chris at bubblescope dot net 2008-03-09 20:28 --- Sorry to be pedantic, but could this be added to _GLIBCXX_DEBUG_PEDANTIC. I've previously tended to assume that _GLIBCXX_DEBUG should change only flag code that should fail in non-debug mode, but fails to be detected, whereas _GLIBCXX_DEBUG_PEDANTIC ensures that the code is standards compliant. On another note, could this be added when just -pedantic is added? I think it's a useful flag to add, I'm just trying to avoid having to change a bunch of working, although non standards-complaint code :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31247
[Bug libstdc++/35480] Relational operators for tr1/tuple don't error on different sized tuples
--- Comment #6 from chris at bubblescope dot net 2008-03-06 17:11 --- While I agree that this is an issue of implementation detail, I thought there was code already there to stop this case, except it is broken :( Looking at the svn copy of tr1/tuple, you can see operator== (and others) delegate to _tuple_compare, passing the first parameter: tuple_size_Tp::value - tuple_size_Tp::value Which should be: tuple_size_Tp::value - tuple_size_Up::value The template which accepts this is only implemented for this value being 0, so any other value produces a compile time error. I broke this (woops) in r91171, back in 2004. The code has continued to be updated as tuple has changed, and no-one seems to have noticed it made no sense ;) -- chris at bubblescope dot net changed: What|Removed |Added CC||chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35480
[Bug libstdc++/34636] New: Parallel sort fails on darwin
With a recent trunk ( 4.3.0 20071231 (experimental) (GCC) ), I tried compiling
the following program:
#include vector
#include algorithm
using namespace std;
int main(void)
{
vectorvectorint v(10);
std::sort(v.begin(), v.end());
}
With:
/usr/gccsvn/bin/g++-svn temp.cc -g -W -D_GLIBCXX_PARALLEL -fopenmp
-march=native
The resulting program generates a 'non-aligned pointer being freed' error in:
__gnu_parallel::parallel_sort_mwms_pu__gnu_cxx::__normal_iteratorstd::__cxx1998::vectorint,
std::allocatorint *, std::__cxx1998::vectorstd::__cxx1998::vectorint,
std::allocatorint , std::allocatorstd::__cxx1998::vectorint,
std::allocatorint, std::lessstd::__cxx1998::vectorint,
std::allocatorint()
This could be some flaw in the way I have built things, but I can't find any
problems as of yet.
--
Summary: Parallel sort fails on darwin
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
GCC target triplet: i386-apple-darwin9.1.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34636
[Bug libstdc++/34636] Parallel sort fails on darwin
--- Comment #2 from chris at bubblescope dot net 2008-01-01 13:08 --- (In reply to comment #1) Is this related to libstdc++/34095? Good question, could be. That code also fails to run for me. Unfortunately I don't really have any good idea how to go about debugging this, as I know very little about parallel things. If someone more knowledgeable has some code they suggest running, or idea I should try, I'm happy to do it for them. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34636
[Bug c++/34217] New: Optimisation of virtual functions confused by inlining.
Consider the following code:
struct bar
{ virtual int get_val() { return 1; } };
int inline get_value(bar* b) { return b-get_val(); }
int main(void)
{
bar b;
//return (b)-get_val();#1
return get_value(b); #2
}
Using #1, the compiler optimises away all the code with -O. With #2, when
get_value is inlined into main, the optimiser seems to 'forget' it actually
knows exactly the type of b and performs an unnecessary virtual function call.
Chris
--
Summary: Optimisation of virtual functions confused by inlining.
Product: gcc
Version: 4.2.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34217
[Bug libstdc++/32907] Inefficent operator== in std::string and std::list
--- Comment #2 from chris at bubblescope dot net 2007-07-26 19:41 --- Ah, woops, many apologises. Too long since I've looked at list::size, I forgot which way around libstdc++ differed from the rest of the world :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
[Bug libstdc++/32908] Miss lexicographical_compare random access override
-- chris at bubblescope dot net changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libstdc++/32908] New: Miss lexicographical_compare random access override
lexicographical_compare is used to implement operator and friends on all containers. The code is not optimised for random_access iterators, where we can find which list is the longest before starting and save one comparison every loop. Replace the following line: for (; __first1 != __last1 __first2 != __last2; ++__first1, ++__first2) With: _InputIterator1 __newlast1 = __first1 + std::min(__last1 - __first1, __last2 - __first2); for (; __first1 != __newlast1; ++__first1, ++__first2) (or something similar. This produces a 15% speed improve on operator on vectorint. If this bug remains I will write up code myself, but I am unable to compile g++ from source at the moment. -- Summary: Miss lexicographical_compare random access override Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: chris at bubblescope dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32908
[Bug libstdc++/32907] New: Inefficent operator== in std::string and std::list
This is picked up from http://gcc.gnu.org/ml/gcc/2007-07/msg00681.html ,
apologises if it has already been dealt with.
Both std::string and std::list do not compare lengths before comparing elements
in operator==. In std::string this increases the chances of quitting early and
produces a small improvement even for equal length strings. For std::list this
produces a much larger gain. I believe the operator== for list should simply be
replaced implementation used for all the other containers:
{ return (__x.size() == __y.size()
std::equal(__x.begin(), __x.end(), __y.begin())); }
Which is efficent as list has a O(1) size.
--
Summary: Inefficent operator== in std::string and std::list
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32907
