[Bug ipa/60306] New: Incorrect devirtualization pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306 Bug ID: 60306 Summary: Incorrect devirtualization pure virtual method called Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: bredelin at ucla dot edu Created attachment 32192 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32192action=edit File that exhibits the compilation error. When compiled with GCC 4.9, my C++ code gives: pure virtual method called terminate called without an active exception Aborted This goes away if I compile with -fno-devirtualize, or if I compile with GCC 4.8.2. I compiled with: % g++-4.9 -O3 main.C -std=c++11 -g % ./a.out
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 bredelin at ucla dot edu changed: What|Removed |Added CC||bredelin at ucla dot edu --- Comment #10 from bredelin at ucla dot edu --- It seems that these changes (see Sep 17th) also made the default constructor explicit. While this does follow the standard, it is the subject of this defect report: http://cplusplus.github.io/LWG/lwg-active.html#2193 Was this change intentional?
[Bug c++/51812] [4.7 regression] Virtual public inheritance and thunks leads to undefined reference in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 --- Comment #9 from bredelin at ucla dot edu 2012-01-29 18:30:43 UTC --- Thanks :-)
[Bug c++/51812] [4.7 regression] Virtual public inheritance and thunks leads to undefined reference in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 --- Comment #6 from bredelin at ucla dot edu 2012-01-23 22:46:47 UTC --- I will check this patch tomorrow (Jan 24th) to make sure that it fixes the problem on non-reduced test cases.
[Bug c++/51812] New: Virtual public inheritance leads to undefined reference in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 Bug #: 51812 Summary: Virtual public inheritance leads to undefined reference in header files. Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: brede...@ucla.edu Created attachment 26292 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26292 The c++ file that has linker errors. Hi, Using gcc 4.7 causes new linker errors that are not present in e.g. 4.5, 4.6, or clang. These linker errors make it impossible to use header files that do not fully define some classes entirely in the header file. The errors look like: % g++-4.7 all5.C /tmp/ccfEMWL0.o: In function `Object::print() const': all5.C:(.text._ZNK6Object5printEv[_ZNK6Object5printEv]+0x58): undefined reference to `demangle(std::string const)' /tmp/ccfEMWL0.o: In function `alphabet::compare(Object const) const': all5.C:(.text._ZNK8alphabet7compareERK6Object[_ZNK8alphabet7compareERK6Object]+0x81): undefined reference to `typeinfo for alphabet' all5.C:(.text._ZNK8alphabet7compareERK6Object[_ZNK8alphabet7compareERK6Object]+0xa5): undefined reference to `operator==(alphabet const, alphabet const)' /tmp/ccfEMWL0.o: In function `alphabet::~alphabet()': all5.C:(.text._ZN8alphabetD1Ev[_ZN8alphabetD1Ev]+0xe): undefined reference to `vtable for alphabet' all5.C:(.text._ZN8alphabetD1Ev[_ZN8alphabetD1Ev]+0x26): undefined reference to `vtable for alphabet' /tmp/ccfEMWL0.o: In function `Triplets::Triplets(Triplets const)': all5.C:(.text._ZN8TripletsC1ERKS_[_ZN8TripletsC1ERKS_]+0x3d): undefined reference to `VTT for Triplets' all5.C:(.text._ZN8TripletsC1ERKS_[_ZN8TripletsC1ERKS_]+0x51): undefined reference to `vtable for Triplets' all5.C:(.text._ZN8TripletsC1ERKS_[_ZN8TripletsC1ERKS_]+0x69): undefined reference to `vtable for Triplets' /tmp/ccfEMWL0.o:(.rodata._ZTV18AminoAcidsWithStop[_ZTV18AminoAcidsWithStop]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTV18AminoAcidsWithStop[_ZTV18AminoAcidsWithStop]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTV18AminoAcidsWithStop[_ZTV18AminoAcidsWithStop]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarraydouble const, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_10AminoAcids[_ZTV18AminoAcidsWithStop]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_10AminoAcids[_ZTV18AminoAcidsWithStop]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_10AminoAcids[_ZTV18AminoAcidsWithStop]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarraydouble const, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_8alphabet[_ZTV18AminoAcidsWithStop]+0x30): undefined reference to `typeinfo for alphabet' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_8alphabet[_ZTV18AminoAcidsWithStop]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_8alphabet[_ZTV18AminoAcidsWithStop]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTC18AminoAcidsWithStop0_8alphabet[_ZTV18AminoAcidsWithStop]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarraydouble const, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTV10AminoAcids[_ZTV10AminoAcids]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTV10AminoAcids[_ZTV10AminoAcids]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTV10AminoAcids[_ZTV10AminoAcids]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarraydouble const, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTC10AminoAcids0_8alphabet[_ZTV10AminoAcids]+0x30): undefined reference to `typeinfo for alphabet' /tmp/ccfEMWL0.o:(.rodata._ZTC10AminoAcids0_8alphabet[_ZTV10AminoAcids]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTC10AminoAcids0_8alphabet[_ZTV10AminoAcids]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTC10AminoAcids0_8alphabet[_ZTV10AminoAcids]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarraydouble const, double) const' /tmp/ccfEMWL0.o:(.rodata._ZTV3RNA[_ZTV3RNA]+0x48): undefined reference to `alphabet::print() const' /tmp/ccfEMWL0.o:(.rodata._ZTV3RNA[_ZTV3RNA]+0x60): undefined reference to `alphabet::setup_letter_classes()' /tmp/ccfEMWL0.o:(.rodata._ZTV3RNA[_ZTV3RNA]+0x70): undefined reference to `alphabet::get_frequencies_from_counts(std::valarraydouble const, double) const'
[Bug c++/51812] Virtual public inheritance leads to undefined reference in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 --- Comment #1 from bredelin at ucla dot edu 2012-01-10 14:32:46 UTC --- Created attachment 26293 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=26293 Preprocessed source
[Bug c++/51812] Virtual public inheritance leads to undefined reference in header files.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51812 --- Comment #2 from bredelin at ucla dot edu 2012-01-10 15:09:09 UTC --- Also note that the bug report is based on a snapshot of 4.7 that was taken on Jan 7, 2012. $ g++-4.7 -v Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.7 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7-20120107-1' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr --program-suffix=-4.7 --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.7 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc --with-arch-32=i586 --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.7.0 20120107 (experimental) [trunk revision 182981] (Debian 4.7-20120107-1)
[Bug tree-optimization/46302] New: Program with virtual public inheritance crashes at O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46302 Summary: Program with virtual public inheritance crashes at O3 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: brede...@ucla.edu The attached files gives a segfault when compiled at O3. It may result from trying to optimize out virtual function calls with a virtual public base class.
[Bug tree-optimization/46302] Program with virtual public inheritance crashes at O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46302 --- Comment #1 from bredelin at ucla dot edu 2010-11-04 13:17:47 UTC --- Created attachment 22275 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22275 source in multiple files
[Bug tree-optimization/46302] Program with virtual public inheritance crashes at O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46302 --- Comment #2 from bredelin at ucla dot edu 2010-11-04 13:18:48 UTC --- Created attachment 22276 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22276 source in single c++ file
[Bug tree-optimization/46302] Program with virtual public inheritance crashes at O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46302 --- Comment #3 from bredelin at ucla dot edu 2010-11-04 13:19:34 UTC --- Created attachment 22277 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22277 preprocessed source file
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #8 from bredelin at ucla dot edu 2010-10-08 15:58:49 UTC --- When you say segfault, I presume you mean abort? When I use the debugger, the problem appears to be in the call to new Parameters(*P); On x86_64, the problem occurs as follows: (x86_32 is different) In the copy constructor, Parameters::SuperModel2 is constructed OK. Then the copy constructor for Parameters::Probability_Model is called, which calls the copy constructor for Probability_Model::Model2, which calls the copy constructor for Model2::vectordouble. In the (synthesized) copy constructor vectordouble::vectordouble(const vectordouble __x), the debugger claims that this and __x are both optimized out, and won't let me inspect anything. The SIGABORT actually occurs because the __x has a __x.size() of 18446726482060379005. It should have a size of 0. (I can't call __x.size(), but I can access __n, which is initialized from __x.size()).
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #9 from bredelin at ucla dot edu 2010-10-08 16:37:15 UTC --- On x86_32, the problem occurs somewhat differently. All I did differently is add -m32. It seems that on x86_32, the copy constructor vectorint::vectorint(const vector __x) for SuperModel2::object fails, whereas it succeeded on x86_64. The values for this and __x are not optimized out for SuperModel2::object, so they can be inspected. The values for __x appear to be crazy. This leads to a large __n, and thus another abort because of an attempt to allocate too much memory. (__n should be 0). The error may be caused by the fact that __x points to the wrong memory location (0xd4a0, instead of the correct value 0xd484). I think the location of __x is wrong on x86_64 also, but it just so happens on x86_64 that __x._M_finish - __x._M_start is 0 for the wrong location of __x, whereas on x86_32 it does not happen to be 0. Does this help any?
[Bug middle-end/45699] [4.6 Regression] Incorrect copy constructor generated with -O
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699 --- Comment #5 from bredelin at ucla dot edu 2010-10-06 15:46:08 UTC --- This bug still existed as of Oct 4, 2010. gcc version 4.6.0 20101004 (experimental) [trunk revision 164952] (Ubuntu 20101004-0ubuntu1) After this bug is fixed, I'll be able to do some more testing of 4.6 for a large c++ program.
[Bug middle-end/45699] New: Incorrect copy constructor generated with -O
If you compile the attached file without optimization, it runs fine. However, if you compile with -O, then you get: $ ~/Devel/GCC/local/4.6/bin/g++-4.6 -g -O crash.C -o crash --save-temps $ ./crash terminate called after throwing an instance of 'std::bad_alloc' what(): std::bad_alloc Aborted Interestingly, 4.5 works fine. The version of 4.6 is revision 164339. $ ~/Devel/GCC/local/4.6/bin/g++-4.6 -v Using built-in specs. COLLECT_GCC=/home/bredelings/Devel/GCC/local/4.6/bin/g++-4.6 COLLECT_LTO_WRAPPER=/home/bredelings/Devel/GCC/local/4.6/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure --enable-languages=c,c++,fortran --prefix=/home/bredelings/Devel/GCC/local/4.6 --enable-shared --enable-linker-build-id --with-system-zlib --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --with-plugin-ld=ld.gold --with-tune=generic --disable-werror --enable-checking=yes --program-suffix=-4.6 Thread model: posix gcc version 4.6.0 20100916 (experimental) (GCC) The version of 4.5 is: $ g++-4.5 -v Using built-in specs. COLLECT_GCC=/usr/bin/g++-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.5.1/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.5.1-5' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --with-plugin-ld=ld.gold --enable-objc-gc --with-arch-32=i586 --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.5.1 (Debian 4.5.1-5) The crash seems to result from using the wrong location for SuperModel2::object in the generated copy constructor. -- Summary: Incorrect copy constructor generated with -O Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bredelin at ucla dot edu GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
[Bug middle-end/45699] Incorrect copy constructor generated with -O
--- Comment #1 from bredelin at ucla dot edu 2010-09-17 00:52 --- Created an attachment (id=21814) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21814action=view) The problem file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
[Bug middle-end/45699] Incorrect copy constructor generated with -O
--- Comment #2 from bredelin at ucla dot edu 2010-09-17 00:53 --- Created an attachment (id=21815) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21815action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45699
[Bug tree-optimization/41464] vector loads are unnecessarily split into high and low loads
--- Comment #9 from bredelin at ucla dot edu 2010-02-04 20:29 --- In reply to comment #8 So in the end all this boils down to the Frontend / middle-end issue of weak handling of aligned types. Would you mind giving a general idea of what the outlook for improvement on this front is? Also, this is interesting: http://eigen.tuxfamily.org/index.php?title=Benchmark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41464
[Bug tree-optimization/42846] New: GCC sometimes ignores information about pointer target alignment
GCC sometimes loses alignment information.
If we declare an aligned pointer type:
// These two lines work (together)
typedef real aligned_real __attribute__((aligned(16)));
typedef const aligned_real* SSE_PTR;
Then gcc generates aligned access here:
// This function uses ALIGNED accesses
real f(SSE_PTR p, SSE_PTR q,int n)
{
real sum = 0;
for(int i=0; in;i++)
sum += p[i] * q[i];
return sum;
}
But not here:
real f2a(const double* p_, const double* q_,int n)
{
SSE_PTR __restrict__ p = p_;
SSE_PTR __restrict__ q = q_;
real sum = 0;
for(int i=0; in;i++)
sum += p[i] * q[i];
return sum;
}
This could matter when the user know which things are aligned.
gcc version 4.5.0 20100119 (experimental) [trunk revision 156049] (Ubuntu
20100119-0ubuntu1)
gcc-4.5 -g -c test.C -O3 -ffast-math -msse3 -mtune=barcelona
-ftree-vectorizer-verbose=4
--
Summary: GCC sometimes ignores information about pointer target
alignment
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bredelin at ucla dot edu
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42846
[Bug tree-optimization/42846] GCC sometimes ignores information about pointer target alignment
--- Comment #1 from bredelin at ucla dot edu 2010-01-22 15:14 --- Created an attachment (id=19693) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19693action=view) Several simple examples for alignment in vectorization. The notes in the file about which functions contain aligned accesses were accurate around Dec 31, 2009. However, they have changed, and fewer things are aligned on Jan 22, 2010. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42846
[Bug c++/42555] New: 4.5 regression: 16-byte aligned double is disallowed only in templates
The following line of code is accepted: typedef double AlignedDoubleType __attribute__((aligned(16))); However, if I replace 'double' with a template parameter inside a template function, then I get the following error message: error: alignment of array elements is greater than element size I think that the template version of the typedef should be allowed also, as it is in 4.4. -- Summary: 4.5 regression: 16-byte aligned double is disallowed only in templates Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bredelin at ucla dot edu GCC build triplet: x86_64-linux-gnu GCC host triplet: x86_64-linux-gnu GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42555
[Bug c++/42555] 4.5 regression: 16-byte aligned double is disallowed only in templates
--- Comment #1 from bredelin at ucla dot edu 2009-12-30 19:00 --- Created an attachment (id=19425) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19425action=view) A testcase. To reproduce the error, compile the file (test5.C) with this command line: % g++-4.5 -c test5.C -O3 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42555
[Bug c++/42555] 4.5 regression: 16-byte aligned double is disallowed only in templates
--- Comment #2 from bredelin at ucla dot edu 2009-12-30 19:03 --- Also, I just noticed that the error occurs only if -ftree-vectorize is turned on. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42555
[Bug c++/28016] New: GCC 4.2 emitting static template constants as global symbols?
I have some software that uses the BOOST matrix library UBLAS (1.33.1). This
software compiles and links with GCC 4.1.1 (Debian Linux system - GNU ld) but
gives linking errors with GCC 4.2:
substitution.o:(.data+0x0): multiple definition of
`_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE'
alignment.o:(.data+0x0): first defined here
Here is from the definition of the static const member of a template class in
boost/numeric/ublas/functional.hpp:
templateclass T1, class T2
struct scalar_divides_assign:
public scalar_binary_assign_functorT1, T2 {
... stuff ...
};
templateclass T1, class T2
const bool scalar_divides_assignT1,T2::computed = true;
GCC 4.2, but not 4.1 actually emits this constant in the global data section.
With 4.2:
$ nm alignment.o | grep divides
0180 t
_GLOBAL__I__ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
D
_ZN5boost7numeric5ublas21scalar_divides_assignIT_T0_E8computedE
With 4.1 neither of these two symbols (or is it one symbol, mentioned twice?)
is emitted.
--
Summary: GCC 4.2 emitting static template constants as global
symbols?
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bredelin at ucla dot edu
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug c++/28016] GCC 4.2 emitting static template constants as global symbols?
--- Comment #1 from bredelin at ucla dot edu 2006-06-13 18:30 ---
Here is some source code that exhibits the problem:
begin a.C -
templateclass T1, class T2
struct scalar_divides_assign {
static const bool computed ;
};
templateclass T1, class T2
const bool scalar_divides_assignT1,T2::computed = true;
- end --
To see the problem do
$ g++-4.2 -c a.C
$ nm a.o | grep computed
D _ZN21scalar_divides_assignIT_T0_E8computedE
This symbol shouldn't be emitted, or at least not in this way.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28016
[Bug middle-end/20521] ICE in cgraph.C with C++
--- Additional Comments From bredelin at ucla dot edu 2005-03-20 15:57 --- Subject: Re: ICE in cgraph.C with C++ belyshev at depni dot sinp dot msu dot ru wrote: --- Additional Comments From belyshev at depni dot sinp dot msu dot ru 2005-03-20 11:25 --- This is with today's (Mar 17, 2005) CVS, with Richard's Guenther's patch to modify inlining heuristics. which one? please add references to all patches you installed or, better, try to reproduce ICE with clean tree by adding appropriate --param options. 1. For now, I will just include the patch: diff -r1.170 tree-inline.c 1249a1250 case TARGET_EXPR: 1250a1252,1253 if (DECL_P (x) DECL_IGNORED_P (x)) break; 1252d1254 case TARGET_EXPR: 2. However, it seems that as of Mar 18 CVS, the crash no longer occurs. This is probably because of this change: Fri Mar 18 10:00:16 2005 UTC by hubicka PR middle-end/20225 * cgraph.c (cgraph_mark_reachable_node): Assert that it is not called too late. * varasm.c (find_decl_and_mark_needed): Mark needed only when not called too late. 3. This patch might be reversed: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01869.html If the regression returns, I will try to find --param options that cause the ICE on a clean tree. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20521
[Bug middle-end/20521] New: ICE in cgraph.C with C++
While compiling a source file, I get the following error: smodel.C:1164:1: internal compiler error: in cgraph_mark_reachable_node, at cgraph.c:475 This is with today's (Mar 17, 2005) CVS, with Richard's Guenther's patch to modify inlining heuristics. These options trigger the ICE: % g++-cvs -O smodel.ii -c -- Summary: ICE in cgraph.C with C++ Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bredelin at ucla dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20521
[Bug middle-end/20521] ICE in cgraph.C with C++
--- Additional Comments From bredelin at ucla dot edu 2005-03-17 20:28 --- Created an attachment (id=8411) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8411action=view) This testcase is preprocessed source from the file that causes the ICE. Here is the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20521
[Bug c++/19883] [4.0 regression] Even more array bounds rejected as non-constant in template...
--- Additional Comments From bredelin at ucla dot edu 2005-02-17 16:45
---
Note that this bug breaks BOOST.
Here is a reduced testcase, which comes from
boost/mpl/aux_/integral_wrapper.hpp:
-- begin testcase
template typename T, T N
struct integral_c
{
static const T value = N;
typedef integral_c T, static_castT((value + 1)) next;
// typedef integral_c T, static_castT((value - 1)) prior;
// operator T() const { return static_castT(this-value); }
};
--- end testcase
% g++-cvs testcase.C
c.C:6: error: template argument 2 is invalid
The original error was obtained by including boost/numeric/ublas/matrix.hpp
The following error was recieved:
In file included from /usr/include/boost/config.hpp:35,
from /usr/include/boost/numeric/ublas/config.hpp:24,
from /usr/include/boost/numeric/ublas/matrix.hpp:20,
from a.C:1:
/usr/include/boost/config/compiler/gcc.hpp:92:7: warning: #warning Unknown
compiler version - please run the configure tests and report the results
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:72: error: template argument 2
is invalid
/usr/include/boost/mpl/aux_/integral_wrapper.hpp:73: error: template argument 2
is invalid
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19883
[Bug c++/19891] New: Covariant returns broke
Here is a testcase that fails in 4.0 CVS, but works in 3.4.
extern C void printf (const char*, ...);
struct Model {
bool full_tree; // if you remove this, the error goes away
virtual Model* clone() const =0;
virtual char *name() const =0;
virtual ~Model() {} // if you remove this, the error goes away
};
struct R: virtual public Model {
virtual R* clone() const =0;
};
struct A: virtual public Model {
virtual A* clone() const=0;
};
struct RA: public R, public A {
virtual RA* clone() const=0;
};
//- EQU Model //
struct EQU: public RA {
virtual EQU* clone() const {return new EQU(*this);}
char *name() const {return EQU;}
};
int main() {
Model* M1 = new EQU();
Model* M2 = M1-clone();
Model* M3 = M2-clone();
printf(subst model = %s \n, M1-name() );
printf(subst model = %s \n, M2-name() );
printf(subst model = %s \n, M3-name() );
return 0;
}
--
Summary: Covariant returns broke
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bredelin at ucla dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19891
[Bug libmudflap/19319] Mudflap produce many violations on simple, correct c++ program
--- Additional Comments From bredelin at ucla dot edu 2005-01-18 09:35 --- Note that this is not just a bug in mudflap, but a bug in the middle end: http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00579.html See follow-up on above message for a mention of a patch for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug libmudflap/19319] New: Mudflap produce many violations on simple, correct c++ program
/4.0.0/../../../../include/c++/4.0.0/bits/stl_iterator.h:603 (__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint ::__normal_iterator)' /usr/local/lib/libmudflap.so.0(__mf_check+0x48) [0x4001f6b8] ./test4(_ZN9__gnu_cxx17__normal_iteratorIPiSt6vectorIiSaIiEEEC1ERKS1_+0xf6) [0x804b728] ./test4(_ZNSt6vectorIiSaIiEE5beginEv+0x19) [0x804b8ff] Nearby object 1: checked region begins 32B before and ends 29B before mudflap object 0x80d5b88: name=`/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/vector.tcc:276 (std::vectorint, std::allocatorint ::_M_insert_aux) __gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint __new_finish' Nearby object 2: checked region begins 36B before and ends 33B before mudflap object 0x80d5b20: name=`/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/vector.tcc:275 (std::vectorint, std::allocatorint ::_M_insert_aux) __gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint __new_start' Nearby object 3: checked region begins 40B before and ends 37B before mudflap object 0x80d5570: name=`/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/vector.tcc:257 (std::vectorint, std::allocatorint ::_M_insert_aux) unnamed variable' Nearby object 8: checked region begins 237B after and ends 240B after mudflap dead object 0x80d66e0: name=`/usr/local/lib/gcc/i686-pc-linux-gnu/4.0.0/../../../../include/c++/4.0.0/bits/stl_uninitialized.h:252 (__uninitialized_copy_a__gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , __gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint , int) __gnu_cxx::__normal_iteratorint*, std::vectorint, std::allocatorint __result' number of nearby objects: 8 -- Summary: Mudflap produce many violations on simple, correct c++ program Product: gcc Version: 4.0.0 Status: UNCONFIRMED Severity: normal Priority: P2 Component: libmudflap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bredelin at ucla dot edu CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19319
[Bug rtl-optimization/19236] New: ICE compiling logp(x) with -ffast-math
The C compiler crashes upon seeing the 'log1p()' function, as follows:
$ gcc-snap -ffast-math -c test-logsum.c
test-logsum.c: In function 'test':
test-logsum.c:6: error: unrecognizable insn:
(insn 9 8 10 1 (set (reg:XF 63)
(float_extend:XF (reg:XF 61))) -1 (nil)
(expr_list:REG_DEAD (reg:XF 61)
(nil)))
test-logsum.c:6: internal compiler error: in extract_insn, at recog.c:2020
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://gcc.gnu.org/bugs.html for instructions.
Here is the (short) test-case file:
--
#include math.h
double test ()
{
return log1p(1.0);
}
--
$ gcc-snap -v
Using built-in specs.
Configured with: ../src/configure -v --enable-languages=c,c++,java,objc,ada
--prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --enable-nls
--enable-threads=posix --without-included-gettext --disable-werror
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
i486-linux-gnu
Thread model: posix
gcc version 4.0.0 20041231 (experimental)
NOTES:
1. BTW, this is a Debian snapshot. (2004-12-31)
2. The bug also occurs with a previous package:
$ gcc-4.0 -v
Reading specs from /usr/lib/gcc/i486-linux/4.0.0/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f95,objc,ada
--prefix=/usr --libexecdir=/usr/lib --enable-shared --with-system-zlib
--enable-nls --enable-threads=posix --without-included-gettext
--program-suffix=-4.0 --enable-__cxa_atexit --enable-libstdcxx-allocator=mt
--enable-clocale=gnu --enable-libstdcxx-debug --enable-java-gc=boehm
--enable-java-awt=gtk --enable-mpfr i486-linux
Thread model: posix
gcc version 4.0.0 20041205 (experimental) (Debian 4.0-0pre2)
3. I am *fairly* sure that the Debian version 4.0-0pre1 was in November and did
not have this problem.
4. The problem did not exist in HEAD in the beginning of October.
--
Summary: ICE compiling logp(x) with -ffast-math
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bredelin at ucla dot edu
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19236
