[Bug c++/53549] g++ and armadillo 3.2.0, operator() is inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549 --- Comment #3 from Conrad 2012-06-01 13:27:47 UTC --- arma::ivec3 from Armadillo works under gcc 4.4.6 20110731 (Red Hat 4.4.6-3). This bug might be related to 52470 and 52685: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52470 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52685 However, Christoffer mentioned that arma::ivec3 doesn't work with gcc-snapshot 4.8.20120520, while bug 52685 seems to be resolved as of 2012-03-29.
[Bug c++/53549] g++ and armadillo 3.2.0, operator() is inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549 --- Comment #4 from Conrad 2012-06-12 08:59:54 UTC --- Created attachment 27607 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27607 pre-processed source exposing the bug bug confirmed on Fedora 17, using gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) attached is "arma.ii.gz", generated using: g++ -v -save-temps -O2 -o arma arma.cpp output of g++ -v: Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.7.0/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --disable-build-with-cxx --disable-build-poststage1-with-cxx --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-ppl --with-cloog --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.7.0 20120507 (Red Hat 4.7.0-5) (GCC)
[Bug c++/53549] [4.7/4.8 Regression] g++ and armadillo 3.2.0, operator() is inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549 --- Comment #6 from Conrad 2012-06-12 09:42:08 UTC --- bug not present when compiling with Clang 3.0 (I've found clang to often have more thorough/readable diagnostics than gcc) output of clang -v: clang version 3.0 (tags/RELEASE_30/final) Target: x86_64-unknown-linux-gnu Thread model: posix
[Bug c++/53549] [4.7/4.8 Regression] g++ and armadillo 3.2.0, operator() is inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549 --- Comment #10 from Conrad 2012-07-10 07:22:00 UTC --- Created attachment 27769 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27769 arma323.ii.gz Retested with gcc 4.7.1 and Armadillo 3.2.3 (latest upstream version). This time a related but different bug in GCC is exposed. arma323.ii.gz is the attached pre-processed source. Code compiles fine on gcc 4.4.6 and clang 3.0. /usr/local/bin/g++ arma323.cpp -o arma323 -O2 -Wall -pedantic In file included from /usr/include/armadillo:141:0, from arma323.cpp:2: /usr/include/armadillo_bits/Mat_bones.hpp:545:26: error: no members matching ‘arma::Mat::operator=’ in ‘class arma::Mat’ /usr/include/armadillo_bits/Mat_bones.hpp:546:27: error: no members matching ‘arma::Mat::operator()’ in ‘class arma::Mat’ In file included from /usr/include/armadillo:142:0, from arma323.cpp:2: /usr/include/armadillo_bits/Col_bones.hpp:175:27: error: no members matching ‘arma::Col::operator()’ in ‘class arma::Col’ In file included from /usr/include/armadillo:143:0, from arma323.cpp:2: /usr/include/armadillo_bits/Row_bones.hpp:173:27: error: no members matching ‘arma::Row::operator()’ in ‘class arma::Row’ GCC 4.7.1 was compiled directly from sources, using GCC 4.7.0 on a Fedora 17 machine. /usr/local/bin/g++ -v Using built-in specs. COLLECT_GCC=/usr/local/bin/g++ COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure Thread model: posix gcc version 4.7.1 (GCC)
[Bug c++/53549] [4.7/4.8 Regression] g++ and armadillo 3.2.0, operator() is inaccessible
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53549 --- Comment #14 from Conrad 2012-07-23 05:25:29 UTC --- (In reply to comment #13) > Fixed. Thanks!
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 Conrad changed: What|Removed |Added CC||conradsand.arma at gmail dot com --- Comment #9 from Conrad --- Paolo, any reason for twice removing my address from the CC list for this bug?
[Bug c++/59364] New: C++11 extern thread_local breaks linking: undefined reference to TLS init function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
Bug ID: 59364
Summary: C++11 extern thread_local breaks linking: undefined
reference to TLS init function
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: conradsand.arma at gmail dot com
Short description:
Declaring a variable as extern thread_local in a C++11 program leads to
"undefined reference to `TLS init function for ..." during linking.
Long description:
Consider three files: rng.hpp, a.cpp and b.cpp, listed below.
Compile using:
g++ a.cpp -c -o a.o -std=c++11
g++ b.cpp -c -o b.o -std=c++11
g++ a.o b.o -o prog -std=c++11
b.o: In function `TLS wrapper function for rng_instance':
b.cpp:(.text._ZTW12rng_instance[_ZTW12rng_instance]+0x5): undefined reference
to `TLS init function for rng_instance'
Things only work if thread_local is removed.
gcc version 4.8.2 20131017 (Red Hat 4.8.2-1) on Fedora 19 (x86-64).
---
rng.hpp:
#include
class rng {
public:
std::mt19937_64 engine;
std::uniform_real_distribution distr;
double get_val() { return distr(engine); }
};
---
a.cpp:
#include "rng.hpp"
thread_local rng rng_instance;
---
b.cpp:
#include
#include "rng.hpp"
extern thread_local rng rng_instance;
int main(int argc, char** argv)
{
std::cout << "val: " << rng_instance.get_val() << std::endl;
return 0;
}
---
[Bug c++/57163] Link failure with thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163 Conrad changed: What|Removed |Added CC||conradsand.arma at gmail dot com --- Comment #4 from Conrad --- Confirmed for gcc 4.8.2
[Bug c++/59364] C++11 extern thread_local breaks linking: undefined reference to TLS init function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364 --- Comment #2 from Conrad --- I wouldn't call the method presented in the comments to bug #55800 as a workaround. Quote: "at least adding .globl _ZTWN3xyz3blaE _ZTWN3xyz3blaE = __tls_init manually at the end of the assembly seems to make the code do what it is supposed to" Editing the assembly is not a workaround -- it's a one off hack.
[Bug c++/59364] C++11 extern thread_local breaks linking: undefined reference to TLS init function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364
--- Comment #3 from Conrad ---
Reduced test case. Compile with:
g++ a.cpp -c -o a.o -std=c++11
g++ b.cpp -c -o b.o -std=c++11
g++ a.o b.o -o prog -std=c++11
file foo.hpp:
class foo
{
public:
inline foo() {}
inline ~foo() {}
inline double bar() { return 123.456; }
};
file a.cpp:
#include "foo.hpp"
thread_local foo foo_instance;
file b.cpp:
#include "foo.hpp"
extern thread_local foo foo_instance;
int main(int argc, char** argv)
{
double bar = foo_instance.bar();
return 0;
}
[Bug c++/59364] C++11 extern thread_local breaks linking: undefined reference to TLS init function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364 --- Comment #4 from Conrad --- Created attachment 31406 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31406&action=edit reduced test case Attached reduced_test_case.tar.gz No need for pre-processed input, as it doesn't include any system headers.
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 Conrad S changed: What|Removed |Added CC||conradsand.arma at gmail dot com --- Comment #28 from Conrad S --- More fallout, this time with C++ code: https://bugzilla.redhat.com/show_bug.cgi?id=1709538 +1 for "Maintaining binary compatibility (even if it is bug compatibility) with existing packages"
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #37 from Conrad S --- Thanks for the workaround. Will the patches be backported to gcc 8.x and 9.x ?
[Bug fortran/90329] Incompatibility between gfortran and C lapack calls
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329 --- Comment #39 from Conrad S --- > A better question might be: Are you going to fix your code? Yes [1], but that's besides the point here. I can certainly fix my code, but that leaves 99% of other software. Backports to gcc 8.x and 9.x would be very beneficial. [1] in progress: https://gitlab.com/conradsnicta/armadillo-code/issues/123
[Bug c++/55436] New: g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436
Bug #: 55436
Summary: g++ compiles invalid code with child class of nested
class in template class
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: conradsand.a...@gmail.com
Created attachment 28760
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28760
test.cpp: source for invalid code that compiles under g++
The code below compiles under g++ 4.7.2 and 4.4.6, but is apparently invalid,
ie. it is not rejected by g++.
We initially thought this was a bug in the clang compiler, but the clang folks
are saying that this is a bug in g++ (ie. gcc shouldn't be accepting this
code).
Related clang bugzilla bug entry:
http://llvm.org/bugs/show_bug.cgi?id=14402
The clang folks are quoting this part of the standard:
See [temp.dep]p3: "In the definition of a class or class template, if a base
class depends on a template-parameter, the base class scope is not examined
during unqualified name lookup either at the point of definition of the class
template or member or during an instantiation of the class template or member."
#include
template
class A
{
public:
void m() { std::cout << "A::m()" << std::endl; }
void z() { m(); }
class B
{
public:
void m() { std::cout << "B::m()" << std::endl; }
void y() { m(); }
};
class C : public B
{
public:
void x() { m(); }
};
};
int main()
{
A a;
a.z();
A::B b;
b.y();
A::C c;
c.x();
}
Clang 3.1 reports the following error:
test.cpp:20:16: error: call to non-static member function 'm' of 'A' from
nested
type 'C'
void x() { m(); }
Shouldn't g++ also report a similar error?
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 Conrad changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #4 from Conrad 2012-12-18 08:55:23 UTC --- Compiling the invalid test.cpp (original attachment) under 4.8.0 20121209 (x86_64) also works, when it shouldn't. The code presented in Comment #3 by Jonathan Wakely also results in a linked error when using 4.8.0 20121209. Should this bug be upgraded to P2, given its wide ranging effects ?
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 Conrad changed: What|Removed |Added Version|4.7.2 |4.8.0 --- Comment #6 from Conrad 2012-12-18 14:54:50 UTC --- > If it was a serious problem it would have been reported before by more people. I'm not sure if the degree of popularity of a bug should diminish its seriousness. This is an "accepts-invalid, rejects-valid, wrong-code" bug, which is pretty nasty as far as bugs go. The use of C++ is expanding (including GCC's own code base), meaning this bug is going to bite more people as time goes on. However, I do understand that bugs which affect more people right now should get looked at first. Furthermore, given its wide ranging impact, perhaps fixing this bug in 4.7.x would not be doable (ie. too invasive). As such, I'll reassign this bug to 4.8.0.
[Bug c++/55436] g++ compiles invalid code with child class of nested class in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436 --- Comment #8 from Conrad 2013-01-09 06:03:07 UTC --- Can we change this bug status to _confirmed_, and the target milestone to 4.8.0 ?
[Bug c++/59994] New: [meta-bug] thread_local
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59994 Bug ID: 59994 Summary: [meta-bug] thread_local Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: conradsand.arma at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58672 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55800 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163
[Bug c++/59364] thread_local link error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59364 --- Comment #6 from Conrad --- Any chance of a backport of this fix to gcc 4.8.3 ?
[Bug libgomp/60035] [PATCH] make it possible to use OMP on both sides of a fork (without violating standard)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035 Conrad changed: What|Removed |Added CC||conradsand.arma at gmail dot com --- Comment #1 from Conrad --- It would be a good idea to post this to the gcc-patches mailing list. See http://gcc.gnu.org/lists.html
[Bug c++/64870] New: value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870
Bug ID: 64870
Summary: value not set via reference
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: conradsand.arma at gmail dot com
Created attachment 34624
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34624&action=edit
rebug.cpp
gcc 4.9.2 fails to set a value through a reference.
Consider the following code:
#include
struct blah {
inline double setval(unsigned int& x) const
{
x = 123;
return 456.0;
}
};
int
main(int argc, char** argv) {
blah blah_instance;
unsigned int val = ;
std::cout << blah_instance.setval(val) << " val: " << val << std::endl;
std::cout << blah_instance.setval(val) << " val: " << val << std::endl;
return 0;
}
when compiled with gcc 4.9.2, the above program produces the following output:
456 val:
456 val: 123
when compiled with clang 3.5:
456 val: 123
456 val: 123
[Bug c++/64870] value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870 --- Comment #2 from Conrad --- Notwithstanding loopholes in C++ legalese, the expected result is to evaluate things left to right, just like reading words and sentences. clang produces the least surprising result. With gcc we end up with "wtf?" What is the benefit in changing the expected order of evaluation? Not trying to pick a fight here -- I genuinely want to know whether there is a good reason to change the order.
[Bug c++/64870] value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870 --- Comment #4 from Conrad --- (In reply to Marc Glisse from comment #3) > > Except when there is an = sign, where you expect the right hand side to be > evaluated before the left? And maybe a few other cases? For iostreams which use the << operator for printing, the expected order is to print things left-to-right, and hence evaluate left-to-right. > > What is the benefit in changing the expected order of evaluation? > > Performance. Is there a benchmark to support the re-ordering? If we're talking 1%-2% here and there, is this really worth the "wtf" moments?
[Bug c++/64870] value not set via reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64870 --- Comment #6 from Conrad --- (In reply to Andrew Pinski from comment #5) > No, that is not how C++ defines it. As mentioned before C++ does not define > the order of the execution of the operands. I agree this is not how C++ defines it. At the same time, changing the order from left-to-right "just because we can" is not a good strategy either, especially for iostreams. > There is no wtf moments. This is not Java which has well defined behavior > :). Ha :-) I'd still like to see some concrete benchmarks to support re-ordering. Otherwise it can be argued that the re-ordering is actually counter productive, given its unintuitive behaviour. Given a choice between gcc and clang, I'd pick clang because it's simply better behaved. This is not to dismiss the great effort put into gcc, but user-friendliness is important.
[Bug c++/64410] New: gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 Bug ID: 64410 Summary: gcc 25% slower than clang 3.5 for adding complex numbers Product: gcc Version: 4.9.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: conradsand.arma at gmail dot com Created attachment 34336 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34336&action=edit cxaddspeed.cpp gcc 4.9.2 has worse performance than clang 3.5 when dealing with complex numbers. Attached is a simple program which adds two vectors with complex numbers. Compiled with -O3 on x86-64 (i7), Fedora 21, gcc 4.9.2 and clang 3.5.0. $ time ./cxaddspeed_gcc 5000 100 5.364u 0.002s 0:05.36 100.0% $ time ./cxaddspeed_clang 5000 100 4.417u 0.001s 0:04.41 100.0% ie. gcc is about 25% slower. inner loop produced by gcc: .L52: movsd(%r15,%rax), %xmm1 movsd8(%r15,%rax), %xmm0 addsd0(%rbp,%rax), %xmm1 addsd8(%rbp,%rax), %xmm0 movsd%xmm1, (%rbx,%rax) movsd%xmm0, 8(%rbx,%rax) addq$16, %rax cmpq%rsi, %rax jne.L52 inner loop produced by clang: .LBB0_145: movupd-16(%rbx), %xmm0 movupd-16(%rax), %xmm1 addpd%xmm0, %xmm1 movupd%xmm1, -16(%rdi) movupd(%rbx), %xmm0 movupd(%rax), %xmm1 addpd%xmm0, %xmm1 movupd%xmm1, (%rdi) addq$2, %rbp addq$32, %rbx addq$32, %rax addq$32, %rdi addl$-2, %ecx jne.LBB0_145
[Bug c++/64410] gcc 25% slower than clang 3.5 for adding complex numbers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64410 --- Comment #2 from Conrad --- (In reply to Marc Glisse from comment #1) > 3) the ABI for complex uses 2 separate double instead of a vector of 2 > double. Technically yes, but in practice aren't the 2 separate doubles guaranteed to be consecutive in memory?
[Bug c++/62255] Introducing an unrelated template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255 Conrad changed: What|Removed |Added CC||conradsand.arma at gmail dot com --- Comment #1 from Conrad --- Confirmed on g++ 4.8.3, Fedora 20, 64 bit. gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)
[Bug c++/62255] Introducing an unrelated template parameter causes compilation to fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255
--- Comment #2 from Conrad ---
When the irrelevant template parameter is used (arma_template_test.ii), g++
thinks that "value" in the following code can't be determined at compile time:
template
struct is_Col_fixed_only
{
typedef char yes[1];
typedef char no[2];
template static yes& check(typename X::Col_fixed_type*);
template static no& check(...);
static const bool value = ( sizeof(check(0)) == sizeof(yes) );
};
[Bug c++/62659] [4.9/5 regression] Regression in template argument substitution in 4.9+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62659 Conrad changed: What|Removed |Added CC||conradsand.arma at gmail dot com --- Comment #2 from Conrad --- Possibly related template bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255
[Bug c++/117993] New: inherited variables and functions not found in nested class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117993 Bug ID: 117993 Summary: inherited variables and functions not found in nested class Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: conradsand.arma at gmail dot com Target Milestone: --- Created attachment 59831 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59831&action=edit short program with templated and nested classes Using the attached program, GCC 15 20241208 complains with: gcc15bug.cpp: In member function ‘void B::C::bar()’: gcc15bug.cpp:23:13: error: ‘struct B::C’ has no member named ‘foo’ [-Wtemplate-body] 23 | (*this).foo(); | ^~~ gcc15bug.cpp:24:13: error: ‘struct B::C’ has no member named ‘x’ [-Wtemplate-body] 24 | (*this).x = T(3); Class C inherits the member function foo() and variable x from class A via class B, so this should work. GCC 14.2 and clang 18.1.8 (both from Fedora 40) compile this program without problems, suggesting this is a regression in GCC 15.
