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.or
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
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)
Targ
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
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!
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436
Conrad changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
--- Comment
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 functio
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57163
Conrad changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
--- Comment
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 co
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
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 h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
Conrad S changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
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 ?
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 b
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55436
Conrad changed:
What|Removed |Added
CC||redi at gcc dot gnu.org
--- Comment #4
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
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
?
: 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
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 ?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60035
Conrad changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
--- Comment
++
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
stru
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?"
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 << ope
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 th
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
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
consecuti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62255
Conrad changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
--- Comment
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]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62659
Conrad changed:
What|Removed |Added
CC||conradsand.arma at gmail dot
com
--- Comment
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
31 matches
Mail list logo
