[Bug tree-optimization/53239] [4.7/4.8 Regression] VRP vs named value return opt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53239 David Kastrup changed: What|Removed |Added CC||dak at gnu dot org --- Comment #12 from David Kastrup 2012-05-07 13:31:03 UTC --- Unrelated question: this kind of code is quite common in connection with user-defined arithmetic classes. While I understand that changing the bug priority from "P3 normal" will likely do nothing with regard to which releases of gcc the fix will appear in, it might make a difference for distributors that tend to cherry-pick important fixes ahead of regular releases. For example, the next release of Fedora is slated to be delivered using gcc 4.7.0, and its miscompilation of LilyPond, a bonafide application, was what triggered this report. Given that the triggering pattern is quite typical for C++ and the problem being present on all architectures, it might make sense to adjust the priority.
[Bug c++/51323] New: g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 Bug #: 51323 Summary: g++ confuses this with function argument in optimized call Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gnu.org Created attachment 25921 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25921 Boiled down source code. Bad code for last function. The following boiled down code produces a jmp to Grob::internal_set_property where the implicit first call argument (this) is equal to the explicit second call argument instead of the actual this pointer. The guilty code sequence is .L4: movl%ebx, 40(%esp) movl%ebx, 32(%esp) movl%eax, 36(%esp) addl$24, %esp .cfi_remember_state .cfi_def_cfa_offset 8 popl%ebx .cfi_def_cfa_offset 4 .cfi_restore 3 jmp_ZN4Grob21internal_set_propertyEPvS0_ Version is Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) Compilation options are -O2 This is from Lilypond source code and causes a segfault.
[Bug c++/51323] g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 --- Comment #1 from David Kastrup 2011-11-28 11:32:46 UTC --- -fno-optimize-sibling-calls avoids the problematic optimization. For no good reason at all, -fkeep-inline-functions, documented to do a completely unrelated non-optimization (namely emitting inline functions even when all uses of them had been inlined), will also switch off the problematic tail call optimization.
[Bug c++/51323] g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 David Kastrup changed: What|Removed |Added Known to work|4.5.0 |4.5.2 --- Comment #2 from David Kastrup 2011-11-28 12:17:52 UTC --- This particular code generation bug is responsible for at least half a dozen problems in the code base of Lilypond and causes a number of regression test failures. We will have to add respective compiler options based on the version number of gcc. If anybody knowing the responsible compiler internals can construct a self-contained test case that does not require manually inspecting the generated code for errors, we could at least add an autoconf test specifically tailored to the occurence of this bug instead of basing the workaround compiler options on the version number.
[Bug c++/51333] New: cxxabi.h incompatible with -fkeep-inline-functions at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51333 Bug #: 51333 Summary: cxxabi.h incompatible with -fkeep-inline-functions at link time Classification: Unclassified Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@gnu.org Created attachment 25935 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25935 File failing at link time The following file fails, when compiled with -fkeep-inline-functions, at link time with the error g++ -fkeep-inline-functions abi.cc /tmp/ccI7H3ZL.o: In function `__gnu_cxx::recursive_init_error::recursive_init_error()': abi.cc:(.text._ZN9__gnu_cxx20recursive_init_errorC2Ev[_ZN9__gnu_cxx20recursive_init_errorC5Ev]+0x16): undefined reference to `vtable for __gnu_cxx::recursive_init_error' collect2: ld returned 1 exit status Compilation exited abnormally with code 1 at Mon Nov 28 14:41:24 Version is Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-linux-gnu/4.6.1/lto-wrapper Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.6.1-9ubuntu3' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3)
[Bug c++/51333] cxxabi.h incompatible with -fkeep-inline-functions at link time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51333 David Kastrup changed: What|Removed |Added Known to work|4.5.2 | --- Comment #2 from David Kastrup 2011-11-28 15:25:03 UTC --- I am more surprised that actual demangling applications work without -lsupc++ as long as -fkeep-inline-functions is not used. It is good to have a solution (even if its necessity depends on the compilation options in a non-obvious way), but the actual error message certainly does not particularly help in figuring out the problem. I have to take back "works with 4.5.2" since I forgot that I used -fkeep-inline-functions only once I needed to work around a 4.6.1 bug. So I actually have no data point when this option would have worked with the given test file. Probably that renders this particular report "invalid", but somebody really should try making the link error message more intelligible.
[Bug middle-end/51323] g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 --- Comment #4 from David Kastrup 2011-11-28 18:24:10 UTC --- I can confirm that my version of gcc identifying itself as gcc version 4.6.1 (Ubuntu/Linaro 4.6.1-9ubuntu3) makes your test program abort under -O2. If you _cannot_ confirm this with your version 4.6.1 but with the trunk, it would appear that Ubuntu 11.10 (or its upstream Debian) has imprudently integrated unstable code from the 4.7 branch into the version of gcc they choose to distribute with the release. If your test program can reasonably be considered as perfectly correlated with the occurence of the bug (I don't have the expertise), I'll be using it as an autoconf test in Lilypond for deciding whether to compile with -fno-optimize-sibling-calls instead of the current test just checking the version. Thanks.
[Bug middle-end/51323] g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 --- Comment #5 from David Kastrup 2011-11-28 19:33:26 UTC --- Question: the proposed fix is in gcc/calls.c which looks somewhat architecture independent. Am I right in assuming that this means that the bug may manifest itself under architectures different from i686 given different conditions? In that case, I would tend to just unconditionally do -fno-optimize-sibling-calls in our autoconf checks for all respective gcc versions independent from tests and architecture since I don't have the hardware for other platforms in order to figure out compiler bugs, and since the bug tends to hide its cause in the resulting segfault, as it occurs only with tail jumps, meaning that the responsible function is not even visible in the stack traceback.
[Bug middle-end/51323] g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 --- Comment #7 from David Kastrup 2011-11-29 09:43:44 UTC --- I agree that the real fix is to force an upgrade of the compiler to a fixed version. However, Ubuntu 11.10 has been released and is in circulation, so we can't reasonably implement that solution until the buggy compilers have had a reasonable chance to be replaced everywhere. I have reported this bug to Ubuntu. If you are right that it can't be found in 4.6 proper, they will have acquired it via distribution specific patches. What that means for stability and security of the entire current Ubuntu code base, one can only guess. Regarding Lilypond, we have chosen to use -fno-optimize-sibling-calls based on the gcc version number instead of an actual test, without consideration of the architecture. Tracking this bug down has cost us several weeks of developer time and brought down our build infrastructure for a while until the first workaround, -fkeep-inline-functions, has been discovered by chance. Lilypond is a C++ application with considerable parts written in Guile, so segfaults usually are a problem of forgetting garbage collection protection measures. As far as I know, I am the only active programmer with a system programming background. When the bug manifests itself in a segfault, the responsible function is no longer visible in the stack backtrace. This makes finding the culprit extremely unfunny. In our case, the problem was exacerbated because the last visible caller in the stack backtrace made its call via a function pointer table, this table was a C++ vector, and accessing the vector in gdb was not possible because operator[] had been inlined. Specifying -fkeep-inline-function, which is according to its documentation supposed to _only_ additionally emit (unused) inline function instantiations that could have been used for accessing that table in the debugger, made the bug disappear. There is no sane reason that -fkeep-inline-functions turns off sibling call optimization, but while sabotaging the debugging of this problem, it at least gave us a workaround. So we simply can't afford dealing with this kind of situation more than once. We don't have the skill sets. In contrast, the positive results of this optimization are negligible for us since we don't employ systematic call chaining (like a P code interpreter using function pointer tables likely would).
[Bug middle-end/51323] [4.6/4.7 Regression] g++ confuses this with function argument in optimized call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51323 --- Comment #9 from David Kastrup 2011-11-29 11:13:21 UTC --- Code review is at http://codereview.appspot.com/5431088>, the discussion of the bug is at http://code.google.com/p/lilypond/issues/detail?id=1997>. As you can see, the proposed workaround is restricted to g++ versions of 4.6.x. I trust that it will be fixed by the time 4.7 gets released, and once we have conclusive evidence about versions of 4.6.x that are unaffected, those will likely not get the fix either. As a suggestion: it might be sensible to have a meta option -fdebug that will disable all options significantly interfering with post mortem debugging. While -g by itself should not change code generation, having a supporting option that helps debugging might be nice. The option set I currently think of is something like -fno-crossjumping -fkeep-inline-functions -fno-optimize-sibling-calls. Also optimization of noreturn functions, in particular of abort, would be disabled since clobbering the stack traceback is not really helpful for debugging. But that's a different issue.
[Bug c++/63268] New: Ambiguous non-specialized static template scope is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63268
Bug ID: 63268
Summary: Ambiguous non-specialized static template scope is
accepted
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dak at gnu dot org
The following code
template
class Bass {
T elt;
public:
static void bing () { }
};
class Deriv : Bass
{
void boing ()
{
Bass::bing ();
}
};
compiles without warning. However, Bass::bing, calling a static member
function of a templated class, is ambiguous. It should be Bass:: or
Bass:: or whatever since being a static member and explicitly resolved
it is no longer tied to the class hierarchy of Deriv and thus it should not
matter that Bass is a base class of Deriv.
I was hit by this when our project did a crosscompilation with an older version
of g++ (no idea about the exact version, but should be in the 4.4 range or so)
and balked at code like this that went unnoticed by g++ 4.8. Specifying the
template argument class explicitly placated both 4.8 and whatever the older
compiler version was.
I think that the older compiler version was correct rejecting this.
[Bug c++/63268] Ambiguous non-specialized static template scope is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63268
David Kastrup changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from David Kastrup ---
class Deriv is not a class template. Deriv is an ordinary class with one base
class being the specialized Bass.
Your argument (and the references) would be valid for
template class Deriv : Bass { ... }
but that's not what the report is about. Digging through the C++11 draft
standard, I don't actually see that case covered at all (but then the draft
standard tends to give me a headache pretty fast).
I see no reason why in a non-template class definition the unspecialized
template name of a specialized base class should have any special state.
Assuming that you get further in the standard before headaches set in than I
do, could you cite the section that you derive your opinion from?
[Bug c++/63268] Ambiguous non-specialized static template scope is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63268 David Kastrup changed: What|Removed |Added Resolution|INVALID |FIXED --- Comment #5 from David Kastrup --- Ok, I bow to your analysis. What I consider irksome in both standard text as well as DR176 and G++ issue descriptions and examples is that the writers choose to obfuscate matters by mixing in an orthogonal class template as the derived class that has nothing to do with the actual issue. That sort of gratuitous complexity seriously contributes to the headache inducing factors of C++ language descriptions. Thanks
