[Bug c++/40217] New: gcc-4.3.1 fails to produce an error message for out of memory condition
I accidentally ran my FreeBSD-71 system with 3GB RAM without the swap space and
compiled a large module with high degree of optimization.
I was getting this error:
{standard input}: Assembler messages:
{standard input}:68321: Warning: end of file not at end of a line; newline
inserted
{standard input}:69363: Error: undefined symbol `.LLSDACSE3986' in operation
{standard input}:69427: Error: undefined symbol `.LFB398' in operation
g++: Internal error: Killed: 9 (program cc1plus)
Please submit a full bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
This happened 100% of time, and error message stayed the same.
So gcc was getting memory allocation failure but instead of failing with the
relevant message it was passing wrong assembly to 'as'.
Adding swap cured the situation.
gcc-4.3.3 was failing in a similar way but with a bit different error message.
This should be fixed to make gcc more reliable in the random user environments.
Today by googling the above error messages you can get a lot of references of
similar situations happening to various people.
--
Summary: gcc-4.3.1 fails to produce an error message for out of
memory condition
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40217
[Bug c++/40560] New: Erroneous aliasing rules message
When I compile the following code with gcc-4.4.0 with "-O3 -Wall" flags I get
the messages below.
Testcase has 'union' between Z and char types therefore such type conversion
should be allowed by aliasing rules.
--- error message ---
pr.C: In member function Z& X::get():
pr.C:12: warning: dereferencing type-punned pointer will break strict-aliasing
rules
--- testcase ---
struct Z {int ii;};
struct X {
union {
Z objs[1];
char bb[20];
};
Z& get() {
return (*(Z*)&bb[0]); // <--- error message here
}
};
--
Summary: Erroneous aliasing rules message
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40560
[Bug c/25500] New: REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4
The following testcase when compiled with 'g++ -O3 -msse3 -o testcase
testcase.C'
finishes in 0m0.277s if compiled with gcc-3.4.4 and in 0m44.843s if compiled
with gcc-4.0.2 (similar on all 4.x.x).
Yuri
---
typedef float __v2df __attribute__ ((__vector_size__ (16)));
typedef __v2df __m128;
static __inline __m128 _mm_sub_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_subps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_add_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_addps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_setr_ps (float __Z, float __Y, float __X, float __W)
{ return __extension__ (__m128)(__v2df){ __Z, __Y, __X, __W }; }
struct FF {
__m128 d;
__inline FF() { }
__inline FF(__m128 new_d) : d(new_d) { }
__inline FF(float f) : d(_mm_setr_ps(f, f, f, f)) { }
__inline FF operator+(FF other) { return (FF(_mm_add_pd(d,other.d))); }
__inline FF operator-(FF other) { return (FF(_mm_sub_pd(d,other.d))); }
};
float f[1024*1024];
int main() {
int i;
for (i = 0; i < 1024*1024; i++) { f[i] = 1.f/(1024*1024 + 10 - i); }
FF total(0.f);
for (int rpt = 0; rpt < 1000; rpt++) {
FF p1(0.f), p2(0.), c;
__m128 *pf = (__m128*)f;
for (i = 0; i < 1024*1024/4; i++) {
FF c(*pf++);
total = total + c - p2 + p1;
p1 = p2;
p2 = c;
}
}
}
--
Summary: REGREGRESSION: SSE2 vectorized code is many times slower
on 4.x.x than on 3.4.4
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug c/25500] REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4
--- Comment #1 from yuri at tsoft dot com 2005-12-20 05:34 ---
actually it's the defect in this case: result is not used.
But runtimes are very different in any case.
44.9s on 4.x.x vs. 0m2.371s on 3.4.4
--- begin corrected testcase ---
#include
using namespace std;
typedef float __v2df __attribute__ ((__vector_size__ (16)));
typedef __v2df __m128;
static __inline __m128 _mm_sub_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_subps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_add_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_addps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_setr_ps (float __Z, float __Y, float __X, float __W)
{ return __extension__ (__m128)(__v2df){ __Z, __Y, __X, __W }; }
struct FF {
__m128 d;
__inline FF() { }
__inline FF(__m128 new_d) : d(new_d) { }
__inline FF(float f) : d(_mm_setr_ps(f, f, f, f)) { }
__inline FF operator+(FF other) { return (FF(_mm_add_pd(d,other.d))); }
__inline FF operator-(FF other) { return (FF(_mm_sub_pd(d,other.d))); }
};
float f[1024*1024];
union U {
__m128 m;
float f[4];
};
int main() {
int i;
FF gtotal(0.f);
for (i = 0; i < 1024*1024; i++) { f[i] = 1.f/(1024*1024 + 10 - i); }
FF total(0.f);
for (int rpt = 0; rpt < 1000; rpt++) {
FF p1(0.f), p2(0.), c;
__m128 *pf = (__m128*)f;
for (i = 0; i < 1024*1024/4; i++) {
FF c(*pf++);
total = total + c - p2 + p1;
p1 = p2;
p2 = c;
}
gtotal = gtotal + total;
}
U u;
u.m = gtotal.d;
cout << (u.f[0]) << endl;
}
--- end corrected testcase -
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug target/25500] REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4
--- Comment #3 from yuri at tsoft dot com 2005-12-20 06:01 --- Subject: Re: REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4 I run on Athlon64-3200 in i386 compatible mode. Strange. I had he problem with gcc-4.0.1, yesterday I compiled gcc-4.0.2 and same thing. Yuri pinskia at gcc dot gnu dot org wrote: >--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-20 05:55 >--- >I cannot reproduce this on an Athlon 64 running in either 32 or 64 bit mode. > >Everything I tried shows that 4.x is actually faster than 3.4.4. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug target/25500] REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4
--- Comment #4 from yuri at tsoft dot com 2005-12-20 06:03 --- Subject: Re: REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4 Also I use FreeBSD-6.0 if this even can make a difference. pinskia at gcc dot gnu dot org wrote: >--- Comment #2 from pinskia at gcc dot gnu dot org 2005-12-20 05:55 >--- >I cannot reproduce this on an Athlon 64 running in either 32 or 64 bit mode. > >Everything I tried shows that 4.x is actually faster than 3.4.4. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug target/25500] REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4
--- Comment #5 from yuri at tsoft dot com 2005-12-20 06:19 --- Subject: Re: REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4 Here's attachment with asms generated in both cases. testcase-old.s is 4.3.3 and testcase-new.s is 4.0.2 In testcase-new.s SSE2 code is kinda diluted with i386 assembly, notably 'rep movsl' which never occurs in 3.4.4 output. Yuri --- Comment #6 from yuri at tsoft dot com 2005-12-20 06:19 --- Created an attachment (id=10534) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10534&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug target/25500] REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4
--- Comment #9 from yuri at tsoft dot com 2005-12-20 06:51 --- Subject: Re: REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4 --- Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.4.4 [FreeBSD] 20050518 --- g++ -v (4.0.2) Using built-in specs. Target: i386-unknown-freebsd6.0 Configured with: ../gcc-4.0.2/configure --prefix=/usr/local/gcc-4.0.2 Thread model: posix gcc version 4.0.2 pinskia at gcc dot gnu dot org wrote: >--- Comment #8 from pinskia at gcc dot gnu dot org 2005-12-20 06:36 >--- >Can you show what the output of "gcc -v" for the 3.4 compiler and the 4.0 >compiler? > >This looks like just a different using arch by default. > >a Compiler compiled for i686 by default gives the good code but code compiled >for i386 give bad code. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug target/25500] REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4
--- Comment #11 from yuri at tsoft dot com 2005-12-20 07:40 --- Subject: Re: REGREGRESSION: SSE2 vectorized code is many times slower on 4.x.x than on 3.4.4 Now this huge runtime difference disappeared but now 4.0.2-generated code is always ~> 20% slower. Many memory accesses where they are not needed at all and did not exist for 3.4.4. I tried -march=i686 and -march=k8, both are slower than 3.4.4. Do I also have to recompile gcc with some special options? Yuri pinskia at gcc dot gnu dot org wrote: >--- Comment #10 from pinskia at gcc dot gnu dot org 2005-12-20 06:55 >--- >Oh, I looked a little more and yes it depends on the arch you are building for >but only for 4.x. > >Since you are using SSE, you should add also -march=i686 or -march=k8 so that >the code is also tuned for the processor you are using. > >Anyways the problem with i386 with 4.0 is really just PR 14295. > > > > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25500
[Bug c++/25525] New: 'const' modifier is ignored in static_cast specifier
The following code produces 'casting away constness' error on 'static_cast'
line. Should be no warning.
- code ---
struct A { };
struct B : A { };
template
const PTR mycast(const A *a) {
return (static_cast(a));
}
const B* mycast(const A *a) {
return (mycast(a));
}
--
Summary: 'const' modifier is ignored in static_cast specifier
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25525
[Bug c++/25610] New: 'invalid use of member' error on correct code with templates
The following testcase produces strange error message on the line 'vv.s1...':
error: invalid use of member (did you forget the '&' ?)
--- testcase ---
struct CC {
template CC s1(int m) { return (CC()); }
};
template
struct S {
static inline void exec1(A &vv) {
vv.s1<1>(1);
}
};
void f() {
CC v;
S::exec1(v);
}
--
Summary: 'invalid use of member' error on correct code with
templates
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25610
[Bug c++/33475] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
[Bug c++/33476] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33476
[Bug c++/33477] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33477
[Bug c++/33478] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33478
[Bug c++/33481] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33481
[Bug c++/33480] New: New warning suggestion: virtual functions called from constructors/destructors
I would like to suggest that gcc issues a warning (with -Wall) when any virtual functions are called from constructors and destructors of these objects. During construtors and destructors derived objects aren't complete and almost always virtual functions would be called on undefined derived classes. -- Summary: New warning suggestion: virtual functions called from constructors/destructors Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33480
[Bug c++/33483] New: New warning suggestion (for -Wall): sizeof() with non-lvalue has side effects that will not execute at runtime
#include
using namespace std;
Here is a very dangerous situation that compiler can catch illustrated by the
following example: when sizeof has non-lvalue argument.
--- example ---
int f() {
cout << "I am f" << endl;
return 5;
}
int main() {
cout << "sizeof=" << sizeof(f()) << endl; // HERE THE WARNING SHOULD BE
ISSUED
return (0);
}
--
Summary: New warning suggestion (for -Wall): sizeof() with non-
lvalue has side effects that will not execute at runtime
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33483
[Bug c++/33483] New warning suggestion (for -Wall): sizeof() with non-lvalue has side effects that will not execute at runtime
--- Comment #2 from yuri at tsoft dot com 2007-09-18 22:58 --- Warning should be issued in this case as well. Since this isn't an expected behavior to ignore "n++". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33483
[Bug c++/33475] New warning suggestion: virtual functions called from constructors/destructors
--- Comment #5 from yuri at tsoft dot com 2007-09-19 23:37 --- I would like to note that this isn't a clear-cut suggestion for the following reasons: * It's impossible to enforce such warning in all cases, only in case of virtual functions immediately called from constructor/destructor. * People often use virtual functions from destructors to uninitialize things. And in many cases it's semi-safe. But it's almost always wrong to call virtual functions from constructors. * It probably makes sense to add such warning to Valgrind as well to issue it based on the run-time analysis But still such warning in gcc can prevent many errors waiting to happen from happening. gcc must do as much as possible preventing dangerous coding patterns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33475
[Bug c++/33805] New: Static member of the class should be able to depend on classes size
I got this error and this made me thinking.
First example produces an error:
m.C:2: error: invalid application of 'sizeof' to incomplete type 'B'
But the second one doesn't.
Why if I take sizeof() of the current class when instantiating the object it's
an error and if I pass the type to the class A as a template parameter this
isn't an error. And class A can do with it's template parameter all it wants
and this is ok.
I think first example should compile w/out errors since static object doesn't
even change the size of B, so it shouldn't matter what it is.
this code produces an error
template struct A { };
struct B { static A a; };
this code compiles w/out errors
template struct A { };
struct B { static A a; };
--
Summary: Static member of the class should be able to depend on
classes size
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33805
[Bug c++/20275] New: Mandatory inlining of templetized class member fails for no reason
Compiling following code get error below.
Once I remove template<> from class R it inlines fine.
Yuri
--- begin code ---
#define inline __attribute__ ((__always_inline__))
template struct R { inline void R::r(int& c); };
template inline void R::r(int& c) { }
class BB {};
void f(R *rr) {
int i;
rr->r(i);
}
--- end code ---
--- begin error ---
i.C: In function `void f(R*)':
i.C:6: sorry, unimplemented: inlining failed in call to 'void R::r(int&)
[with T = BB]': function not inlinable
i.C:11: sorry, unimplemented: called from here
i.C: In function `void f(R*)':
i.C:6: sorry, unimplemented: inlining failed in call to 'void R::r(int&)
[with T = BB]': function not inlinable
i.C:11: sorry, unimplemented: called from here
--- end error ---
--
Summary: Mandatory inlining of templetized class member fails for
no reason
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20275
[Bug c++/20340] New: __always_inline__ fails on templetized function for no reason
Compiling code below (g++ -O5 -c) fails with the error message below.
This is the major source of performance loss since it leaves silly functions
like this called zillions of times w/out inlining.
Any workaround ?
Yuri
code
template __attribute__ ((__always_inline__)) T f(const T j) { return
(j); }
int x(int j) {
int r;
r = f(j);
return (r);
}
error message
i.C:2: sorry, unimplemented: inlining failed in call to 'T f(T) [with T = int]':
function not inlinable
i.C:6: sorry, unimplemented: called from here
--
Summary: __always_inline__ fails on templetized function for no
reason
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20340
[Bug c++/20340] __always_inline__ fails on templetized function for no reason
--- Additional Comments From yuri at tsoft dot com 2005-03-06 10:45 --- actually this one is fixed in 4.0, problem though is that 4.0 isn't usable yet -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20340
[Bug c++/20343] New: __always_inline__ fails on STL templetized function
Another example of failed inlining, now also existent in 4.0 as of 2005-02-13:
When I tried to compile with -O5 -Dinline=__attribute__\(\(__always_inline__\)\)
I get the error message below.
Interestingly there's no "inline" word here, it must have been taken from some
global declaration ?
--- code from include/c++/4.0.0/bits/ostream.tcc ---
template
basic_ostream<_CharT, _Traits>&
basic_ostream<_CharT, _Traits>::
operator<<(__ostream_type& (*__pf)(__ostream_type&))
{
...
--- error message ---
xxx.h|39| sorry, unimplemented: called from here
--
Summary: __always_inline__ fails on STL templetized function
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From yuri at tsoft dot com 2005-03-06 18:10 ---
Sorry about this, this appears to be more complex to reporduce than I thought.
Compile the following with the options:
-O5 -Dinline=__attribute__\(\(__always_inline__\)\)
to see the error message.
(gcc 4.0 cvs updeted on 2005-02-13 and compiled with default options)
What's strange is that error is only generated when both "vector" and "cout <<
endl;" parts are there
Yuri
--- code ---
#include
#include
using namespace std;
int main() {
vector v;
v.resize(100);
v[10] = atoi("5");
cout << endl;
return (10);
}
-- error ---
/usr/local/gcc-4.0-20050213/lib/gcc/i386-unknown-freebsd5.3/4.0.0/../../../../include/c++/4.0.0/bits/ostream.tcc:67:
sorry,unimplemented: inlining failed in call to 'std::basic_ostream<_CharT,
_Traits>& std::basic_ostream<_CharT,
_Traits>::operator<<(std::basic_ostream<_CharT, _Traits>&
(*)(std::basic_ostream<_CharT, _Traits>&)) [with _CharT = char, _Traits =
std::char_traits]': function not inlinable
m.C:9: sorry, unimplemented: called from here
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug c++/20343] __always_inline__ fails on STL templatized function
--- Additional Comments From yuri at tsoft dot com 2005-03-06 19:37 --- > You need to define inline as inline __attribute__((always_inline)) Did this, same error message. In my project I NEED to specify explicitely inlining of the functions. Including STL since vector::operator[] or similar is being called zillion times even when very aggressive gcc inlining options are set. Regular inlining decisions are not enough for me since I see performance gains with any new inline of functio in the performance path. I understand this causes code explosion -- it's ok w/in the current limits. So to solve the problem with vector::operator[] and similar I use __attribute__((always_inline)) but it fails. How can I solve the problem than ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20343
[Bug c++/35275] New: Operator<< for embedded class of templetized class isn't found
The following code produces an error on the second line inside of main:
error: no match for 'operator<<' in 'std::cout << C::E()'
C++ frontend fails to find the templetized operator<<.
-- begin code
#include
using namespace std;
template
struct C {
struct E {
};
};
template
ostream& operator<<(ostream &ss, const C &t) {
return (ss);
}
template
ostream& operator<<(ostream &ss, const typename C::E &t) {
return (ss);
}
main() {
cout << C(); // this compiles ok
cout << C::E(); // this fails
}
--
Summary: Operator<< for embedded class of templetized class isn't
found
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35275
[Bug c++/35578] New: Error about misplaced 'friend' word is issued on a wrong line
When I compile the code below I get:
x.C:3: error: 'friend' used outside of class
And 'friend' word is on the line #5.
=== code begins ===
int i() {
return (0);
} /*here an error is reported*/
friend void x() {
}
--
Summary: Error about misplaced 'friend' word is issued on a wrong
line
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35578
[Bug c/35694] New: Error about bad function argument isn't issued on the line of the argument but on the line where function ends
int i(int j, int *k);
void f() {
i(
0,
1 /*<--- here the error should be issued*/
); /*<--- here the error is issued*/
}
--
Summary: Error about bad function argument isn't issued on the
line of the argument but on the line where function ends
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35694
[Bug c/35776] New: Simple loop isn't optimized well
I have a C code:
void f();
void i(unsigned n) {
while (n-- > 0) {
f();
}
}
Which when compiled with -O3 on i586 produces the assembly:
i:
pushl %ebp
movl%esp, %ebp
pushl %esi
movl8(%ebp), %esi
pushl %ebx
testl %esi, %esi
je .L5
xorl%ebx, %ebx
.p2align 4,,7
.L4:
addl$1, %ebx
callf
cmpl%esi, %ebx
jne .L4
.L5:
popl%ebx
popl%esi
popl%ebp
ret
And obviously shorter assembly with one less instruction in the loop is:
i:
pushl %ebp
movl%esp, %ebp
pushl %esi
movl8(%ebp), %esi
testl %esi, %esi
je .L5
.p2align 4,,7
.L4:
callf
dec %esi
jl .L4
.L5:
popl%esi
popl%ebp
ret
This is a very short and basic loop occurring in programs many times.
That's why this should be optimized very well.
--
Summary: Simple loop isn't optimized well
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35776
[Bug c++/35876] New: Exceptions not working on FreeBSD
Basic exception example:
#include
#include
using namespace std;
int main() {
try {
throw string("String");
} catch (string s) {
cout << "Caught an exception \"" << s << "\"\n";
}
}
Compiled with:
g++ -fexceptions -Wall -o exception exception.cpp
Prints:
terminate called after throwing an instance of 'std::string'
Should print:
Caught an exception "String"
Exception is never caught.
--
Summary: Exceptions not working on FreeBSD
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug c++/39281] New: Error message 'multiple types in one declaration' need to be reworded
Usually this error message is issued when semicolon is missing after the
struct/class declaration.
Message itself is pretty obscure.
It's better to change it:
error: multiple types in one declaration, missing semicolon after type
declaration?
This will give users a clue and will likely eliminate the need to google the
error message.
--
Summary: Error message 'multiple types in one declaration' need
to be reworded
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39281
[Bug c++/39560] New: Erroneous wanings 'unused variable' in a templetated class method with union
This testcase has warnings:
--- begin testcase ---
struct X { };
class Z {
public:
X* cc(int c);
};
class F {
public:
typedef X* (Z::*MethO)(int);
typedef X* (F::*MethF)(int);
template
X* xwrapper(int i) {
union {
Z *z;
F *f;
};
f = this;
return ((z->*m)(i));
}
};
F::MethF meth = &F::xwrapper<&Z::cc>;
--- end testcase ---
warnings:
c.C: In member function X* F::xwrapper(int) [with X* (Z::* m)(int) = &Z::cc]:
c.C:23: instantiated from here
c.C:17: warning: unused variable z
c.C:17: warning: unused variable f
--
Summary: Erroneous wanings 'unused variable' in a templetated
class method with union
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39560
[Bug c++/93120] New: gcc-9 complains fails to see that switch handles all enum values, and still complains ' "control reaches end of non-void function" when there is no return after the switch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93120 Bug ID: 93120 Summary: gcc-9 complains fails to see that switch handles all enum values, and still complains ' "control reaches end of non-void function" when there is no return after the switch Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- Example: https://github.com/yurivict/nn-insight/blob/master/plugins/tf-lite/tf-lite.cpp#L33 gcc-9 complains: > /usr/ports/misc/nn-insight/work/nn-insight-0.1-3-g78a125f/plugins/tf-lite/tf-lite.cpp: > In function 'PluginInterface::PaddingType > Helpers::convertPaddingType(tflite::Padding)': > /usr/ports/misc/nn-insight/work/nn-insight-0.1-3-g78a125f/plugins/tf-lite/tf-lite.cpp:37:2: > warning: control reaches end of non-void function [-Wreturn-type] >37 | } > | ^
[Bug c++/56941] New: Thread conflict is reported by helgrind in _Unwind_IteratePhdrCallback
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56941 Bug #: 56941 Summary: Thread conflict is reported by helgrind in _Unwind_IteratePhdrCallback Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I get the following error from helgrind on heavily multi-threaded process throwing a lot of exceptions. gcc in use is 4.7.2 on amd64 architecture. Line unwind-dw2-fde-dip.c:212: prev_cache_entry->link = cache_entry->link; It looks like the error is due to an unprotected cache access. This should either be fixed, or there should be a good explanation why this should be considered a non-issue. Data race conditions reported by helgrind usually correspond to real issues. ---helgrind log--- ==83659== Possible data race during write of size 8 at 0x24FECC8 by thread #17 ==83659== Locks held: none ==83659==at 0x22FB1D9: _Unwind_IteratePhdrCallback (unwind-dw2-fde-dip.c:212) ==83659==by 0x14D41: dl_iterate_phdr (in /libexec/ld-elf.so.1) ==83659==by 0x22FB8B1: _Unwind_Find_FDE (unwind-dw2-fde-dip.c:451) ==83659==by 0x22F8D9A: uw_frame_state_for (unwind-dw2.c:1179) ==83659==by 0x22F91F6: uw_init_context_1 (unwind-dw2.c:1500) ==83659==by 0x22F96A6: _Unwind_RaiseException (unwind.inc:88) ==83659==by 0x1E1FAD0: __cxa_throw (eh_throw.cc:78) ==83659==<...user stack omitted...> ==83659== ==83659== This conflicts with a previous write of size 8 by thread #54 ==83659== Locks held: none ==83659==at 0x22FB1D5: _Unwind_IteratePhdrCallback (unwind-dw2-fde-dip.c:211) ==83659==by 0x14D41: dl_iterate_phdr (in /libexec/ld-elf.so.1) ==83659==by 0x22FB8B1: _Unwind_Find_FDE (unwind-dw2-fde-dip.c:451) ==83659==by 0x22F8D9A: uw_frame_state_for (unwind-dw2.c:1179) ==83659==by 0x22F970A: _Unwind_RaiseException (unwind.inc:99) ==83659==by 0x1E1FAD0: __cxa_throw (eh_throw.cc:78) ==83659==<...user stack omitted...>
[Bug java/41356] New: Circular dependencies between jars cause errors: jars order shouldn't matter
I am trying to compile many jars into one native executable with the following command: /usr/local/gcc/gcc-4.3.1-java/bin/gcj -combine -R /usr/local/gcc/gcc-4.3.1-java/lib --main=com.xxx.MyClass \ /usr/local/share/java/commons-logging-1.1.1.jar \ /usr/local/share/java/avalon-framework-4.2.0.jar \ I am getting this error: org/apache/commons/logging/impl/AvalonLogger.java: In class 'org.apache.commons.logging.impl.AvalonLogger': org/apache/commons/logging/impl/AvalonLogger.java: In constructor '(java.lang.String)': org/apache/commons/logging/impl/AvalonLogger.java:79: error: cannot find file for class org.apache.avalon.framework.logger.Logger If I swap the two first jars I get this error: org/apache/avalon/framework/logger/AbstractLoggable.java: In class 'org.apache.avalon.framework.logger.AbstractLoggable': org/apache/avalon/framework/logger/AbstractLoggable.java: In method 'org.apache.avalon.framework.logger.AbstractLoggable.setupLogger(java.lang.Object,java.lang.String)': org/apache/avalon/framework/logger/AbstractLoggable.java:80: error: cannot find file for class org.apache.log.Logger So either org/apache/avalon/framework can't find org.apache.log or the way around. Even before getting this error I noticed that depending jars should be specified after dependent ones. I believe this is wrong: jars actually can inter-depend on each other and should all be treated equally independent of their order in command line. -- Summary: Circular dependencies between jars cause errors: jars order shouldn't matter Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41356
[Bug java/41361] New: segmentation fault when class not found from gcj-built executable with indirect dispatch
I compile an executable: gcj --main=MyApp -findirect-dispatch --classpath=xxx MyApp.class -o my-app When I run my-app and class required by MyClass to run is missing I see Segmentation fault: 11. It should be a meaningful message, not just segv. FreeBSD-72. -- Summary: segmentation fault when class not found from gcj-built executable with indirect dispatch Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41361
[Bug c++/41368] New: Erroneous aliasing rules violation messages are issued
When the attached testcase is compiled with gcc-4.4.1 there are two aliasing error messages issued, that appear to be wrong. -- Summary: Erroneous aliasing rules violation messages are issued Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
[Bug c++/41368] Erroneous aliasing rules violation messages are issued
--- Comment #1 from yuri at tsoft dot com 2009-09-16 05:12 --- Created an attachment (id=18593) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18593&action=view) testcase command line: g++ -c -O5 -Wall pr.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
[Bug c++/41368] Erroneous aliasing rules violation messages are issued
--- Comment #2 from yuri at tsoft dot com 2009-09-16 05:17 --- gcc-4.3.1 didn't issue such warnings. I wasn't able to minimize the testcase more. Somehow if eee instance of Z is removed and just F::bbb() is called messages disappear. This is strange since code around lines in question is all the same in both cases. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41368
[Bug java/41372] New: Symbols in shared library compiled from jar/classes should not be local with -findirect-dispatch
When I compile jar into shared library all symbols become local when -findirect-dispatch is specified. Local symbols can't be found by dlsym. -findirect-dispatch options shouldn't change symbols from global to local since external callers may choose to import them regardless of this option. -- Summary: Symbols in shared library compiled from jar/classes should not be local with -findirect-dispatch Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41372
[Bug java/41375] New: Compiling native executable without -findirect-dispatch causes random SEGVs
I have a simple Java class that doesn't directly depend on anything except for java.lang.String, java.lang.reflect.Class and java.lang.reflect.Method. It loads other classes (from jars in my case) by name and invoked them through Class.forName()/Method.invoke() mechanism. But it only works when -findirect-dispatch is specified. Without -findirect-dispatch it crashes shortly into the run with the stack below. -findirect-dispatch should only impact the way how currently compiled unit links to other units. In case of the programs like mine (not dependent on anything else directly) -findirect-dispatch should have no impact at all. It should resolve classes and run them the same way, since in this scenario it's clear what should be done to load other classes. --- stack (debug info is not everywhere) --- 0x35ec31a7 in __error () from /lib/libthr.so.3 #1 0x35ec2d88 in __error () from /lib/libthr.so.3 #2 0x36005860 in ?? () #3 0x0008 in ?? () #4 0x0001 in ?? () #5 0x36005840 in ?? () #6 0x in ?? () #7 0x0001 in ?? () #8 0x33c718d4 in ?? () from /libexec/ld-elf.so.1 #9 0x35ec16df in pthread_setcancelstate () from /lib/libthr.so.3 #10 0x35ec0f7d in pthread_cond_signal () from /lib/libthr.so.3 #11 0x347e57e8 in _Jv_CondWait (cv=0x35e5b78c, mu=0x35e5b780, millis=0, nanos=0) at ../../../gcc-4.4.1/libjava/posix-threads.cc:212 #12 0x8c347cb0 in ?? () #13 0x35e5b78c in _ZL5mutex () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #14 0x35e5b780 in E () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #15 0x in ?? () #16 0x in ?? () #17 0x in ?? () #18 0x0001 in ?? () #19 0x33c4e998 in dladdr () from /libexec/ld-elf.so.1 -- Summary: Compiling native executable without -findirect-dispatch causes random SEGVs Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug java/41375] Compiling native executable without -findirect-dispatch causes random SEGVs
--- Comment #1 from yuri at tsoft dot com 2009-09-16 12:12 --- I should also add that one of the classes has native methods, and crash occurs shortly after the first such method is invoked. This may or may not be a factor in the issue. Testcase is quite large and I can't submit it here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug java/41375] Compiling native executable without -findirect-dispatch causes random SEGVs
--- Comment #2 from yuri at tsoft dot com 2009-09-16 20:01 --- Created an attachment (id=18599) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18599&action=view) Java proxy example that crashes without -findirect-dispatch Try making an executable with -findirect-dispatch and run some large application through it's 'main' method. I get SEGV from inside this application. FreeBSD-72-STABLE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41375
[Bug c/41462] New: redundant instructions with long double returned value
When I compile this function:
double f(long double i) {return (i);}
with gcc flags -S -O3, I get the assembly below.
There are two redundant FPU instructions there. double value is already in FPU
after fldt. No need to store it and load it back since difference between
double and long double is only in memory representation, and in FPU registers
they are the same.
asm output (relevant part)
f:
pushl %ebp
movl%esp, %ebp
subl$8, %esp < redundant related stack adjustment
fldt8(%ebp)
fstpl -8(%ebp) < redundant STORE
fldl-8(%ebp) < redundant LOAD
leave
ret
--
Summary: redundant instructions with long double returned value
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41462
[Bug c/41462] redundant instructions with long double returned value
--- Comment #1 from yuri at tsoft dot com 2009-09-24 17:25 --- Forgot to mention: 32-bit mode on i586 CPU. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41462
[Bug java/41745] New: Segmentation fault when ecj.jar is run as a binary compiled by gcj
I use this command line:
gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main
/usr/local/share/java/ecj.jar
to compile ecj.jar into native binary ecj.
However, when I try running resulting binary on Hello World Java program it
crashes. Original ecj.jar compiles HelloWorld successfully.
public class HelloWorld {
public static void main(String args[]) {
System.out.println("Hello World!");
}
}
--
Summary: Segmentation fault when ecj.jar is run as a binary
compiled by gcj
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #2 from yuri at tsoft dot com 2009-10-19 09:23 --- No, it doesn't work for me on FreeBSD-8.0: /usr/local/gcc/4.4.1-java/bin/gcj -o ecj --main=org.eclipse.jdt.internal.compiler.batch.Main /usr/local/share/java/ecj.jar LD_LIBRARY_PATH=/usr/local/gcc/4.4.1-java/lib ldd ./ecj ./ecj: libgcc_s.so.1 => /usr/local/gcc/4.4.1-java/lib/libgcc_s.so.1 (0x341ba000) libgcj.so.10 => /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 (0x341c6000) libm.so.5 => /lib/libm.so.5 (0x363d9000) libthr.so.3 => /lib/libthr.so.3 (0x363f3000) librt.so.1 => /usr/lib/librt.so.1 (0x36408000) libc.so.7 => /lib/libc.so.7 (0x3640d000) LD_LIBRARY_PATH=/usr/local/gcc/4.4.1-java/lib ./ecj HelloWorld.java Segmentation fault: 11 backtrace: #0 0x364041c7 in __error () from /lib/libthr.so.3 #1 0x36403da8 in __error () from /lib/libthr.so.3 #2 0x36606820 in ?? () #3 0x0008 in ?? () #4 0x0001 in ?? () #5 0x36606800 in ?? () #6 0x in ?? () #7 0xbf9fedd4 in ?? () #8 0x363fe1a5 in pthread_rwlock_unlock () from /lib/libthr.so.3 #9 0x36401fae in pthread_cond_signal () from /lib/libthr.so.3 #10 0x34d217e8 in _Jv_CondWait (cv=0x3639778c, mu=0x36397780, millis=0, nanos=0) at ../../../gcc-4.4.1/libjava/posix-threads.cc:212 #11 0x8c34d070 in ?? () #12 0x3639778c in _ZL5mutex () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #13 0x36397780 in E () from /usr/local/gcc/4.4.1-java/lib/libgcj.so.10 #14 0x in ?? () #15 0x in ?? () #16 0x in ?? () #17 0x0001 in ?? () #18 0x341795a8 in dladdr () from /libexec/ld-elf.so.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #4 from yuri at tsoft dot com 2009-10-19 17:20 --- I confirm this on FreeBSD-8.0 for gcc-4.5.0.20091001. I notified the maintainer of FreeBSD gcc port. But once the fix will be found it should go into gcj itself, not into port. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug java/41745] Segmentation fault when ecj.jar is run as a binary compiled by gcj
--- Comment #5 from yuri at tsoft dot com 2009-10-19 19:12 --- How to run testsuite for gcj? When I run 'gmake check-gcc' from the build directory it doesn't run gcj tests at all, and gcc/g++ tests summaries are all empty. Not sure what that means. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41745
[Bug c++/41804] New: testsuite breaks with DejaGnu messages
When I try running 'gmake check' after compile I get such log:
Running target unix
Using /usr/local/share/dejagnu/baseboards/unix.exp as board description file
for target.
Using /usr/local/share/dejagnu/config/unix.exp as generic interface file for
target.
Using /tmp/gcc-build/gcc-4.4.2/libstdc++-v3/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /tmp/gcc-build/gcc-4.4.2/libstdc++-v3/testsuite/libstdc++-abi/abi.exp
...
ERROR: (DejaGnu) proc "set_ld_library_path_env_vars" does not exist.
The error code is POSIX EINVAL {invalid argument}
The info on the error is:
could not readlink
"/tmp/gcc-build/gcc-4.4.2/libstdc++-v3/testsuite/data/istream_extractor_other-1.txt":
invalid argument
while executing
"file readlink $f"
--
Summary: testsuite breaks with DejaGnu messages
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41804
[Bug c++/47529] New: Visibility attributes not supported on Solaris i386 platform
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47529 Summary: Visibility attributes not supported on Solaris i386 platform Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I am porting project to Solaris. Same code that builds fine on Linux/BSD produces warnings on Solaris 10: warning: visibility attribute not supported in this configuration; ignored Compilation of modules succeeds with these warnings. But later linking of those object modules into the shared library fails with this message: ld: fatal: relocation error: R_386_GOTOFF: file /path/to/library/libmine.a(module.o): symbol : relocation must bind locally. collect2: ld returned 1 exit status I have built gcc-4.5.2 myself with the same options on both Linux and Solaris. Why wouldn't visibility attributes not be supported in Solaris configuration? Also reading some threads from the past I see that these two messages are somewhat related. Due to the lack of visibility attributes some symbol with R_386_GOTOFF becomes global and can't be linked into the shared library as global. How to solve such problem when c++ code defines some symbols with "hidden" attributes and Solaris version of gcc fails to support this?
[Bug c/46713] -fvisibility=hidden generates broken code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46713 --- Comment #6 from Yuri 2011-01-29 20:07:34 UTC --- Thanks! You can change the warning message to be a bit more proactive: "visibility attribute not supported in this configuration (as during configuration wasn't from binutils?); ignored"
[Bug c++/47536] New: gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 Summary: gcc-4.5.2 fails to build on Solaris 10 i386 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I downloaded gcc-core-4.5.2 and gcc-g++-4.5.2, configured with command: ../src/configure --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --prefix=/opt/local/gcc/4.5.2 Current binutils is in path. This is an error I am getting after a while: <...skiped...> checking for i386-pc-solaris2.10-gcc... /tmp/gcc-build/4.5.2/bld/./gcc/xgcc -B/tmp/gcc-build/4.5.2/bld/./gcc/ -B/opt/local/gcc/4.5.2/i386-pc-solaris2.10/bin/ -B/opt/local/gcc/4.5.2/i386-pc-solaris2.10/lib/ -isystem /opt/local/gcc/4.5.2/i386-pc-solaris2.10/include -isystem /opt/local/gcc/4.5.2/i386-pc-solaris2.10/sys-include -m64 checking for suffix of object files... configure: error: in `/tmp/gcc-build/4.5.2/bld/i386-pc-solaris2.10/amd64/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/tmp/gcc-build/4.5.2/bld' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build/4.5.2/bld' gmake: *** [all] Error 2 Its strange that there is an option -m64 that appears in the command line.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #2 from Yuri 2011-01-29 22:15:45 UTC --- Created attachment 23165 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23165 Requested config.log
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #3 from Yuri 2011-01-29 22:40:09 UTC --- Assembler complains on -xarch option. /opt/local/bin/as: unrecognized option `-xarch=generic64' But '/opt/local/bin/as --help' doeasn't list -xarch as the valid option. It has -march option.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #4 from Yuri 2011-01-30 11:17:32 UTC --- Passing --with-gnu-as option to configure fixes the problem. But why can't configure detect this by itself? GNU as has --version which clearly says that its GNU assembler. And original Solaris as doesn't have --version option.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #5 from Yuri 2011-01-30 21:53:47 UTC --- --with-gnu-as lets gcc build to succeed. But resulting g++ has the problem on all c++ modules: g++ -c m.cpp Assembler: m.cpp "/var/tmp//ccEysWY5.s", line 7 : Illegal mnemonic Near line: ".cfi_startproc" "/var/tmp//ccEysWY5.s", line 7 : Syntax error Near line: ".cfi_startproc" "/var/tmp//ccEysWY5.s", line 9 : Illegal mnemonic Near line: ".cfi_def_cfa_offset 8" "/var/tmp//ccEysWY5.s", line 9 : Syntax error Near line: ".cfi_def_cfa_offset 8" "/var/tmp//ccEysWY5.s", line 11 : Illegal mnemonic Near line: ".cfi_offset 5, -8" "/var/tmp//ccEysWY5.s", line 11 : Syntax error Near line: ".cfi_offset 5, -8" "/var/tmp//ccEysWY5.s", line 12 : Illegal mnemonic Near line: ".cfi_def_cfa_register 5" "/var/tmp//ccEysWY5.s", line 12 : Syntax error Near line: ".cfi_def_cfa_register 5" "/var/tmp//ccEysWY5.s", line 15 : Illegal mnemonic Near line: ".cfi_restore 5" "/var/tmp//ccEysWY5.s", line 15 : Syntax error Near line: ".cfi_restore 5" "/var/tmp//ccEysWY5.s", line 16 : Illegal mnemonic Near line: ".cfi_def_cfa 4, 4" "/var/tmp//ccEysWY5.s", line 16 : Syntax error Near line: ".cfi_def_cfa 4, 4" "/var/tmp//ccEysWY5.s", line 18 : Illegal mnemonic Near line: ".cfi_endproc" "/var/tmp//ccEysWY5.s", line 18 : Syntax error Near line: ".cfi_endproc" ba
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #7 from Yuri 2011-01-30 22:03:50 UTC --- Actually g++ produces the correct assembler file, but still calls original Sun assembler /usr/ccs/bin/as instead of the GNU one from the path, regardless of the option --with-gnu-as passed to gcc configure. Removing /usr/ccs/bin/as fixes the problem. So there are two issues with gcc-4.5.2 on Solaris: 1. Inability to detect GNU assembler in path (unwarranted requirement to pass --with-gnu-as). Broken build when either no GNU assembler in path or no option --with-gnu-as passed. 2. GNU assembler from path isn't used by g++, causing Sun assembler to fail on GNU-formatted assembler file.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #8 from Yuri 2011-01-30 22:06:50 UTC --- (In reply to comment #6) > Which is why it's recommended in the docs: > http://gcc.gnu.org/install/specific.html#ix86-x-solaris210 > > Please try using the suggested configuration There is nothing in these recommendations that configure can't do by itself. Please update configure so that all users don't have to stumble upon the same things over and over.
[Bug c++/47536] gcc-4.5.2 fails to build on Solaris 10 i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47536 --- Comment #10 from Yuri 2011-01-30 23:27:13 UTC --- (In reply to comment #9) > well if you don't want a working compiler feel free to ignore the docs and > refuse to try the options that might help I didn't refuse to try anything, I already got the working compiler. I have suggested the improvement of configure to avoid further user confusion.
[Bug c/47842] New: gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 Summary: gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment Product: gcc Version: 4.5.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com Linux made a decision to switch to 16-byte alignment, but not others. I know for a fact that Solaris is affected, I am not sure, but FreeBSD i386 might also be affected. Please turn this behavior back to the one prescribed by specification for Solaris (and FreeBSD if affected): http://www.sco.com/developers/devspecs/abi386-4.pdf section 3-10: "The stack is word aligned. Although the architecture does not require any alignment of the stack, software convention and the operating system requires that the stack be aligned on a word boundary." Or please refer to the Sun/Oracle decision to change this behavior.
[Bug target/47842] gcc forces 16-byte stack alignment on Solaris i386, when SYSV requires word alignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47842 --- Comment #3 from Yuri 2011-02-22 19:23:45 UTC --- If gcc would only set 16 byte alignment this wouldn't be that bad since, as you mentioned, it is still word aligned. The problem is that gcc assumes that stack is 16 aligned and creates code based on this. For example it places instruction like this 'movdqa %xmm0, 0x10(%esp)' which assumes 16 byte alignment. As a result, gcc compiled procedure crashes when called by ABI compliant code. gcc can't assume 16 byte alignment.
[Bug c++/31802] New: SSE2 performance is deteriorating when __m128 is placed in union
When I compile the following testcase with '-O3 -msse3' options it runs in
22.562sec, without 'union' clause it runs in 0.280sec. And should be the same
time.
-- begin testcase --
typedef float __v2df __attribute__ ((__vector_size__ (16)));
typedef __v2df __m128;
static __inline __m128 _mm_sub_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_subps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_add_pd (__m128 __A, __m128 __B) { return
(__m128)__builtin_ia32_addps ((__v2df)__A, (__v2df)__B); }
static __inline __m128 _mm_setr_ps (float __Z, float __Y, float __X, float __W)
{ return __extension__ (__m128)(__v2df){ __Z, __Y, __X, __W }; }
struct FF {
union {__m128 d; float f[4];}; // problem
// __m128 d; // no problem
__inline FF() { }
__inline FF(__m128 new_d) : d(new_d) { }
__inline FF(float f) : d(_mm_setr_ps(f, f, f, f)) { }
__inline FF operator+(FF other) { return (FF(_mm_add_pd(d,other.d))); }
__inline FF operator-(FF other) { return (FF(_mm_sub_pd(d,other.d))); }
};
float f[1024*1024];
int main() {
int i;
for (i = 0; i < 1024*1024; i++) { f[i] = 1.f/(1024*1024 + 10 - i); }
FF total(0.f);
for (int rpt = 0; rpt < 1000; rpt++) {
FF p1(0.f), p2(0.), c;
__m128 *pf = (__m128*)f;
for (i = 0; i < 1024*1024/4; i++) {
FF c(*pf++);
total = total + c - p2 + p1;
p1 = p2;
p2 = c;
}
}
}
-- end testcase
This bug has similar testcase as 25500 (that's fixed now). Only 'union' clause
was added.
Yuri
--
Summary: SSE2 performance is deteriorating when __m128 is placed
in union
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31802
[Bug fortran/88549] New: gcc doesn't install iso_c_binding.mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88549 Bug ID: 88549 Summary: gcc doesn't install iso_c_binding.mod Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- gcc doesn't install iso_c_binding.mod, and the pcmsolver project (https://github.com/PCMSolver/pcmsolver) fails: > F90-F-0004-Unable to open MODULE file iso_c_binding.mod > (/wrkdirs/usr/ports/science/pcmsolver/work/pcmsolver-1.2.1/src/metal/metal_sphere.F90: > 26) > F90/x86-64 FreeBSD Flang - 1.5 2017-05-01: compilation aborted Googling iso_c_binding.mod finds some more instances of a similar problem. See log: http://beefy6.nyi.freebsd.org/data/120amd64-default/487722/logs/pcmsolver-1.2.1_2.log FreeBSD 12 amd64
[Bug fortran/86566] New: The preprocessor cpp6 loses line concatenation on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86566 Bug ID: 86566 Summary: The preprocessor cpp6 loses line concatenation on FreeBSD Product: gcc Version: 8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Target Milestone: --- How to repeat: create the file a.f90 with this one line (it is also attached): > call iotk_strcat(string,trim(adjustl(tmpval))//" ",ierr) Run the command: > cpp8 a.f90 -o atmp.f90 The result isn't a valid fortran: > call iotk_strcat(string,trim(adjustl(tmpval)) The problem observed on gcc8 and gcc6. The FreeBSD port bug report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229855
[Bug fortran/86566] The preprocessor cpp6 loses line concatenation on FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86566 --- Comment #2 from Yuri --- Replacing cpp with gcc6 -cpp fails: $ gcc6 -cpp -fno-omit-frame-pointer -D__FFTW3 -I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/include -I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/FoX/finclude -I/usr/ports/science/quantum-espresso/work/q-e-qe-6.3/S3DE/iotk/include/ iotk_base.f90 -o iotk_base_tmp.f90 /usr/lib/crt1.o: In function `_start': /usr/src/lib/csu/amd64/crt1.c:(.text+0x17b): undefined reference to `main' collect2: error: ld returned 1 exit status It seems like it tries to link the executable?
[Bug rtl-optimization/24132] New: gcc-4.0.1 never finishes with aggressive optimization options
I use gcc on large project with the optimization options below.
gcc never finishes on some larger modules.
Options are rather large compared with default values, this is because
previously while experimenting I saw performance improvements when I kept
increasing them (using gcc-3.4.3). And speed is of exceptional importance on my
project.
Now I try gcc-4.0.1 with the same options. Compile times of 90% of the modules
~2-5 times longer but on some of them it never finishes (at least not within 3
days).
It's good if compile times are long. But it's not clear if I should keep waiting
in order to gain some more speed or gcc just looped.
Gcc should produce some (maybe activated by option) messages:
* progress indicator: around how long it can take, are there any improvements
made
* when it finishes did it give up or other improvements are possible if options
were more aggressive
I am eager to wait days if it gives few percents improvements. But when no
messages are coming it's just an uncertainty.
used options:
-O5 -finline-limit=5000 -funit-at-a-time --param max-inline-insns-single=5000
--param max-inline-insns-auto=1200 --param large-function-insns=3 --param
large-function-growth=2000 --param inline-unit-growth=1 -funroll-loops
-fpeel-loops -funswitch-loops
--
Summary: gcc-4.0.1 never finishes with aggressive optimization
options
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24132
[Bug rtl-optimization/24132] gcc-4.0.1 never finishes with aggressive optimization options
--- Additional Comments From yuri at tsoft dot com 2005-09-29 23:00 --- actually there are more potentially relavant options: -funroll-loops -fpeel-loops -funswitch-loops -fno-guess-branch-probability -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24132
[Bug rtl-optimization/24132] gcc-4.0.1 never finishes with aggressive optimization options
--- Additional Comments From yuri at tsoft dot com 2005-09-29 23:04 --- > Maybe it is better to just speed up GCC instead :). hopefully not by reducing optimization :-) > the processor indicated is not really useful as it would jump a lot. jumping indicator is better than no indicator because it at least gives some feel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24132
[Bug rtl-optimization/24132] gcc-4.0.1 never finishes with aggressive optimization options
--- Additional Comments From yuri at tsoft dot com 2005-09-29 23:16 --- > Nope but we cannot do it without a testcase. I will send you some fake code as testcase withing 1-2 days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24132
[Bug c++/24498] New: 'control may reach end of non-void function' warning coming from STL when -no-exceptions and -Wall is used
doesn't happen with gcc-3.4.2
--- begin testcase ---
#include
#include
using namespace std;
void p() {
vector().push_back("xxx");
}
end testcase ---
compiled with command:
/usr/local/gcc-4.0.1/bin/g++ -c v.C -O5 -Wall -fno-exceptions
--
Summary: 'control may reach end of non-void function' warning
coming from STL when -no-exceptions and -Wall is used
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24498
[Bug c/56099] New: Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099
Bug #: 56099
Summary: Empty static noinline functions aren't called from
optimized code
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com
The C testcase below, when compiled with gcc-4.7.1 with flag '-O2', doesn't
contain the noinline function at all. No body and no call.
gcc-4.2.1 did leave the body of such function, but also didn't have the call.
gcc should respect noinline attribute even on the empty functions and should
leave both body and call to it.
PS: I hit this while attempting to add the DTrace probes through adding of the
empty function. However, call to this function was never placed into code so
this technique doesn't work due to this bug.
---testcase---
__attribute__((noinline))
static int func_ni() {
return 1;
}
void func_exp() {
func_ni();
}
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #2 from Yuri 2013-01-24 19:06:12 UTC --- Created attachment 29267 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29267 asm of the testcase showing there is still no noinline function I am trying 'noclone' with gcc-4.7.1 but there is still no func_ni in the resulting output: /opt/gcc/4.7.1/bin/gcc -O2 -S ni.c See ni.s attached
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #4 from Yuri 2013-01-24 19:16:10 UTC --- You are saying I also need to place some __asm__ into this noinline function? Doesn't this look like working around some bugs in gcc? User doesn't need to know how gcc is doing this inside, weather it is cloning something or treats it as pure or not. noinline means do-not-inline, no matter what is inside. I originally asked for a simple basic thing, and so many gcc guts got exposed by this.
[Bug tree-optimization/56099] Empty static noinline functions aren't called from optimized code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56099 --- Comment #6 from Yuri 2013-01-24 19:24:43 UTC --- I think 'noinline' flag should be factored into the removal decision.
[Bug c++/43503] New: field in-place decrement isn't optimized
Decrementing of the field causes 3 instructions for what could be one on i686
target.
--- testcase ---
struct C { int fld; };
extern void a();
extern void b();
void f(C *c) {
if (--c->fld > 0) {
a();
} else {
a();
}
}
--- result of assembly with -O5 option ---
_Z1fP1C:
.LFB0:
pushl %ebp
.LCFI0:
movl%esp, %ebp
.LCFI1:
subl$8, %esp
.LCFI2:
movl8(%ebp), %edx
movl(%edx), %eax ; XXX
decl%eax ; XXX these three should be one insn
movl%eax, (%edx) ; XXX
leave
jmp _Z1av
--
Summary: field in-place decrement isn't optimized
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43503
[Bug c++/43503] field in-place decrement isn't optimized
--- Comment #2 from yuri at tsoft dot com 2010-03-24 01:14 --- I would put higher priority here over the other missed optimizations because this is the basic c/c++ construct and it's used very frequently. -- yuri at tsoft dot com changed: What|Removed |Added Component|middle-end |c++ Version|unknown |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43503
[Bug c++/43882] New: 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)
I have a c++ project with a lots of STL. It compiles fine with gcc 4.3.1 and 4.4.3, but with the new 4.5.0 I get those two missing symbols in linking: std::_List_node_base::_M_hook(std::_List_node_base*) std::_List_node_base::_M_unhook() libstdc++.so from 4.5.0 has those relevant symbols, and the ones not found are there: 000584c4 T std::_List_node_base::_M_hook(std::_List_node_base*) 000585bc T std::__norm::_List_node_base::_M_hook(std::__norm::_List_node_base*) 000ab3c8 T std::__cxx1998::_List_node_base::_M_hook(std::__cxx1998::_List_node_base*) 000584e0 T std::_List_node_base::_M_unhook() 000585d8 T std::__norm::_List_node_base::_M_unhook() 000ab3e4 T std::__cxx1998::_List_node_base::_M_unhook() -- Summary: 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...) Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: yuri at tsoft dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882
[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)
--- Comment #2 from yuri at tsoft dot com 2010-04-25 00:35 --- But linker produces messages like this: x.C:229: undefined reference to `std::_List_node_base::_M_hook(std::_List_node_base*)' New with the switch to 4.5.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882
[Bug c++/43882] 4.5.0 produces missing symbols (std::_List_node_base::_M_hook ...)
--- Comment #5 from yuri at tsoft dot com 2010-04-25 01:17 --- Sorry, my bad. It really was picking up the default libstdc++.so from the OS installation. I used -R/path/to/4.5.0/libstdc++.so to fix this library path. But it turns out that -L/path/to/4.5.0/libstdc++.so is also required in addition to this, otherwise the default libstdc++.so is looked up by linker. Maybe this is a bug in linker, don't know. But those new symbols revealed the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43882
[Bug c++/43884] New: Performance degradation of the simple example (fibonacci) 4.3.3->4.5.0
I ran this simple example with the argument 45 through various versions of gcc
(option -O3):
#include
#include
int fib(int AnArg) {
if (AnArg <= 2) return (1);
return (fib(AnArg-1)+fib(AnArg-2));
}
int main(int argc, char* argv[]) {
int n = atoi(argv[1]);
printf("fib(%i)=%i\n", n, fib(n));
}
Here are the average runtimes I got:
versiontime
4.3.1 3.930s
4.3.2 3.500s
4.3.3 3.470s
4.4.1 3.930s
4.4.3 3.940s
4.5.0 3.860s
I ran ~10 samples so values are approximate, but it's quite obvious that 4.5.0
has very significant degradation compared to 4.3.3.
Is there a performance suite for gcc that is ran for each release, are results
available online?
This case is pretty simple, basic. I would expect gcc to produce quite optimal
code for it.
--
Summary: Performance degradation of the simple example
(fibonacci) 4.3.3->4.5.0
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43884
[Bug c++/61652] New: Option --enable-libstdcxx-debug doesn't pass debug options to libstdc++.so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61652 Bug ID: 61652 Summary: Option --enable-libstdcxx-debug doesn't pass debug options to libstdc++.so Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: yuri at tsoft dot com Based on documentation here https://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html I configured gcc to build a debug version of libstdc++.so: $ ../src/configure --prefix=/opt/gcc/4.8.2/ --enable-libstdcxx-debug --enable-libstdcxx-debug-flags='-g3 -O0' $ gmake It did build another version of libstdc++.so with different size under lib/debug/, but both of them have local variables optimized away. I am interested in ../src/libstdc++-v3/libsupc++/dyncast.cc, touching it and rebuilding shows that -O0 hasn't been passed to the compile command, and it builds with -O2. Building gcc-4.8.2 on FreeBSD-10
[Bug c++/22355] New: Multiple local static variables initialization: missed optimization opportunity
Following code (f()) if compiled with -fno-exceptions should
produce only one initialization boolean for all local
static variables, not one per variable. This is since
they always initialized together provided there are no exceptions.
If exceptions are allowed then it should be driven by
the flag in constructors saying if they allow exceptions or not.
Yuri
---
struct C {
C();
int get();
};
int f() {
static C i;
static C j;
return (i.get() + j.get());
}
--
Summary: Multiple local static variables initialization: missed
optimization opportunity
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22355
[Bug c++/23594] New: namespace typedef kills non-namespace typedef when "using" it
I have the same typedef in global scope and in the namespace.
Also I have "using" clause for this namespace.
If both typedefs are in place further code doesn't see typedefed type at all.
See example below.
Yuri
--begin code--
typedef int COUNT;
namespace NN {
typedef int COUNT;
};
using namespace NN;
COUNT xx;
--end code--
gives an error:
error: `COUNT' does not name a type
--
Summary: namespace typedef kills non-namespace typedef when
"using" it
Product: gcc
Version: 3.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: FreeBSD on i386
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23594
[Bug c++/23594] namespace typedef and global typedef name the same type, using kills global
--- Additional Comments From yuri at tsoft dot com 2005-08-27 16:59 --- (In reply to comment #1) ... > PS. the semicolon after the end of the namespace really makes this code invalid but since this is not ... I didn't get why semicolon makes it invalid. I thought semicolon is allowed between any statements. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23594
[Bug c++/45917] New: Friend of friend is allowed the access to the private type through the template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45917
Summary: Friend of friend is allowed the access to the private
type through the template
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com
testcase below has struct R as private in class F.
class F declares class Q a friend, allowing it to see it's private members.
But operator<< is friend in Q, not in F.
Why is it allowed for operator<< to instantiate list but not R r? This is a
bug.
--- testcase ---
#include
#include
using namespace std;
class F {
private:
struct R {
}; // R
friend class Q;
class Q {
list l;
friend ostream& operator<<(ostream &os, const Q &q) {
// R r; // this breaks!
for (list::const_iterator it = q.l.begin(); it != q.l.end(); it++) {
// this doesn't break! Why?
}
return os;
}
}; // Q
}; // F
[Bug c++/45918] New: Lack of warning on meaningless unsigned to zero comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45918
Summary: Lack of warning on meaningless unsigned to zero
comparison
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: y...@tsoft.com
In this case idx
struct G {
void fn();
};
template
void G::fn() {
for (size_t idx = 0; idx;
[Bug c++/45918] Lack of warning on meaningless unsigned to zero comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45918 --- Comment #2 from Yuri 2010-10-06 23:16:21 UTC --- No warning in 4.2.1 for example.
[Bug c++/46109] New: gcc-4.5.0 fails to build on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46109 Summary: gcc-4.5.0 fails to build on Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I tried to build gcc-4.5.0 exactly the same way that succeeds on LInux and failed on Mac OS X. Darwin MacBook.local 10.4.0 Darwin Kernel Version 10.4.0: Fri Apr 23 18:28:53 PDT 2010; root:xnu-1504.7.4~1/RELEASE_I386 i386 --- build log --- <...skipped...> make "DESTDIR=" "RPATH_ENVVAR=DYLD_LIBRARY_PATH" "TARGET_SUBDIR=i386-apple-darwin10.4.0" "bindir=/usr/local/bin" "datadir=/usr/local/share" "exec_prefix=/usr/local" "includedir=/usr/local/include" "datarootdir=/usr/local/share" "docdir=/usr/local/share/doc/" "infodir=/usr/local/share/info" "pdfdir=/usr/local/share/doc/" "htmldir=/usr/local/share/doc/" "libdir=/usr/local/lib" "libexecdir=/usr/local/libexec" "lispdir=" "localstatedir=/usr/local/var" "mandir=/usr/local/share/man" "oldincludedir=/usr/include" "prefix=/usr/local" "sbindir=/usr/local/sbin" "sharedstatedir=/usr/local/com" "sysconfdir=/usr/local/etc" "tooldir=/usr/local/i386-apple-darwin10.4.0" "build_tooldir=/usr/local/i386-apple-darwin10.4.0" "target_alias=i386-apple-darwin10.4.0" "AWK=awk" "BISON=bison" "CC_FOR_BUILD=gcc" "CFLAGS_FOR_BUILD=-g -O2" "CXX_FOR_BUILD=g++" "EXPECT=expect" "FLEX=flex" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS_FOR_BUILD=" "LEX=flex" "M4=gm4" "MAKE=make" "RUNTEST=runtest" "RUNTESTFLAGS=" "SED=/usr/bin/sed" "SHELL=/bin/sh" "YACC=bison -y" "`echo 'ADAFLAGS=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "ADA_CFLAGS=" "AR_FLAGS=rc" "`echo 'BOOT_ADAFLAGS=-gnatpg -gnata' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "BOOT_CFLAGS=-g -O2 -fomit-frame-pointer" "BOOT_LDFLAGS=" "CFLAGS=-g -O2" "CXXFLAGS=-g -O2" "LDFLAGS=" "LIBCFLAGS=-g -O2" "LIBCXXFLAGS=-g -O2 -fno-implicit-templates" "STAGE1_CHECKING=--enable-checking=yes,types" "STAGE1_LANGUAGES=c" "GNATBIND=no" "GNATMAKE=no" "AR_FOR_TARGET=ar" "AS_FOR_TARGET=as" "CC_FOR_TARGET=/tmp/gcc-build/4.5.0/bld/./gcc/xgcc -B/tmp/gcc-build/4.5.0/bld/./gcc/" "CFLAGS_FOR_TARGET=-g -O2" "CPPFLAGS_FOR_TARGET=" "CXX_FOR_TARGET=/tmp/gcc-build/4.5.0/bld/./gcc/g++ -B/tmp/gcc-build/4.5.0/bld/./gcc/ -nostdinc++ -L/tmp/gcc-build/4.5.0/bld/i386-apple-darwin10.4.0/libstdc++-v3/src -L/tmp/gcc-build/4.5.0/bld/i386-apple-darwin10.4.0/libstdc++-v3/src/.libs" "CXXFLAGS_FOR_TARGET=-g -O2" "DLLTOOL_FOR_TARGET=dlltool" "FLAGS_FOR_TARGET=-B/usr/local/i386-apple-darwin10.4.0/bin/ -B/usr/local/i386-apple-darwin10.4.0/lib/ -isystem /usr/local/i386-apple-darwin10.4.0/include -isystem /usr/local/i386-apple-darwin10.4.0/sys-include" "GCJ_FOR_TARGET=" "GFORTRAN_FOR_TARGET=" "LD_FOR_TARGET=/usr/libexec/gcc/i686-apple-darwin10/4.2.1/ld" "LIPO_FOR_TARGET=lipo" "LDFLAGS_FOR_TARGET=" "LIBCFLAGS_FOR_TARGET=-g -O2" "LIBCXXFLAGS_FOR_TARGET=-g -O2 -fno-implicit-templates" "NM_FOR_TARGET=nm" "OBJDUMP_FOR_TARGET=objdump" "RANLIB_FOR_TARGET=ranlib" "STRIP_FOR_TARGET=strip" "WINDRES_FOR_TARGET=windres" "WINDMC_FOR_TARGET=windmc" "BUILD_CONFIG=bootstrap-debug" "`echo 'LANGUAGES=' | sed -e s'/[^=][^=]*=$/XFOO=/'`" "LEAN=false" "STAGE1_CFLAGS=-g -fkeep-inline-functions" "STAGE1_CXXFLAGS=-g -O2" "STAGE1_TFLAGS=" "STAGE2_CFLAGS=-g -O2 -fomit-frame-pointer -gtoggle" "STAGE2_CXXFLAGS=-g -O2" "STAGE2_TFLAGS=" "STAGE3_CFLAGS=-g -O2 -fomit-frame-pointer" "STAGE3_CXXFLAGS=-g -O2" "STAGE3_TFLAGS=" "STAGE4_CFLAGS=-g -O2 -fomit-frame-pointer" "STAGE4_CXXFLAGS=-g -O2" "STAGE4_TFLAGS=" "STAGEprofile_CFLAGS=-g -O2 -fomit-frame-pointer -gtoggle -fprofile-generate" "STAGEprofile_CXXFLAGS=-g -O2" "STAGEprofile_TFLAGS=" "STAGEfeedback_CFLAGS=-g -O2 -fomit-frame-pointer -fprofile-use" "STAGEfeedback_CXXFLAGS=-g -O2" "STAGEfeedback_TFLAGS=" "TFLAGS=" "CONFIG_SHELL=/bin/sh" "MAKEINFO=makeinfo --split-size=500 --split-size=500" compare rm -f stage_current Comparing stages 2 and 3 warning: gcc/cc1-checksum.o differs warning: gcc/cc1plus-checksum.o differs Bootstrap comparison failure! i386-apple-darwin10.4.0/libgomp/.libs/bar.o differs i386-apple-darwin10.4.0/libgomp/.libs/barrier.o differs i386-apple-darwin10.4.0/libgomp/.libs/env.o differs i386-apple-darwin10.4.0/libgomp/.libs/iter.o differs i386-apple-darwin10.4.0/libgomp/.libs/iter_ull.o differs i386-apple-darwin10.4.0/libgomp/.libs/lock.o differs i386-apple-darwin10.4.0/libgomp/.libs/loop.o differs i386-apple-darwin10.4.0/libgomp/.libs/loop_ull.o differs i386-apple-darwin10.4.0/libgomp/.libs/ordered.o differs i386-apple-darwin10.4.0/libgomp/.libs/parallel.o differs i386-apple-darwin10.4.0/libgomp/.libs/proc.o differs i386-apple-darwin10.4.0/libgomp/.libs/sections.o differs i386-apple-darwin10.4.0/libgomp/.libs/single.o differs i386-apple-darwin10.4.0/libgomp/.libs/task.o differs i386-apple-darwin10.4.0/libgomp/.libs/tea
[Bug c++/43960] New: Template redeclaration with different number of parameters is tolerated
This testcase redeclares template H::F with different number of parameters.
This should be illegal, but gcc-4.5.0 passes it.
--- testcase ---
namespace H {
template struct F;
}
;
class Z {
template friend struct H::F;
};
--
Summary: Template redeclaration with different number of
parameters is tolerated
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43960
[Bug c++/44285] New: Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
Consider the example below.
When compiled with flag -O3 methods meth_used and meth_unused aren't present in
the resulting assembly at all.
Now consider the situation when this class is a part of the package compiled
into the shared library and both meth_used and meth_unused are API of this
package.
Without the symbols for meth_used and meth_unused it's pretty much assumed that
the user will have c++ code that will recompile those function into the user
code. It's impossible to bind from other languages only knowing symbols without
c++ coding.
gcc should have an option, either compiler option, or the special keyword on
the method, that would guarantee the method presence in the object.
I looked into __attribute__ visibility. It only allows these values: "default",
"hidden", "protected" or "internal" and doesn't help in this situation.
Maybe "public" visibility should be added for this case?
-- example header: exp.h --
extern void zzz();
class Abc {
public:
void meth_used() {
zzz();
}
void meth_unused() {
zzz();
}
};
-- example header: exp.C --
#include "exp.h"
void my_exp() {
(new Abc)->meth_used();
}
--
Summary: Need an option that will create symbols for all public
c++ methods, not only for those which bodies are outside
the class declaration
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #4 from yuri at tsoft dot com 2010-05-26 16:37 --- Why this is useful, as I wrote above, to eliminate the need for c++ coding for binding with other languages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #5 from yuri at tsoft dot com 2010-05-26 16:43 --- -fkeep-inline-functions leaves them, but it will also leave all inline functions, not only public ones. This will, I guess, blow up the size of the object since there can be a lot of internal inlines that shouldn't appear in the object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44298] New: code addressed only by label with it's address taken is ignored
The testcase below passes the entry point to 'lll' call as an address of the
label ll_def. printf line disappears completely.
Obviously people should only use such code when they really know what they are
doing. But compilation result here is complately wrong and isn't usable in any
way.
--- testcase ---
#include
#include
__attribute__ ((noinline)) void lll(void*) {
}
void mainx() {
lll(&&ll_def);
return;
ll_def:
printf("default\n");
return;
}
--
Summary: code addressed only by label with it's address taken is
ignored
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44298
[Bug bootstrap/49306] New: 4.6.0 fails to build on Solaris 11 (i386)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49306 Summary: 4.6.0 fails to build on Solaris 11 (i386) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I have prerequisite gmp,mfrc,mpc and binutils installed under /opt/local. Configure command is: ../src/configure \ --with-gnu-as --with-as=/opt/local/bin/as \ --with-gnu-ld --with-ld=/opt/local/bin/ld \ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local \ --prefix=/usr/local/gcc/4.6.0 followed by gmake -j 2 causes the error: <...skiped...> checking for i386-pc-solaris2.11-gcc... /tmp/gcc-build/4.6.0/bld/./gcc/xgcc -B/tmp/gcc-build/4.6.0/bld/./gcc/ -B/usr/local/gcc/4.6.0/i386-pc-solaris2.11/bin/ -B/usr/local/gcc/4.6.0/i386-pc-solaris2.11/lib/ -isystem /usr/local/gcc/4.6.0/i386-pc-solaris2.11/include -isystem /usr/local/gcc/4.6.0/i386-pc-solaris2.11/sys-include checking for suffix of object files... configure: error: in `/tmp/gcc-build/4.6.0/bld/i386-pc-solaris2.11/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. gmake[2]: *** [configure-stage1-target-libgcc] Error 1 gmake[2]: Leaving directory `/tmp/gcc-build/4.6.0/bld' gmake[1]: *** [stage1-bubble] Error 2 gmake[1]: Leaving directory `/tmp/gcc-build/4.6.0/bld' gmake: *** [all] Error 2 File /tmp/gcc-build/4.6.0/bld/i386-pc-solaris2.11/libgcc/config.log has this error in it: configure:3268: /tmp/gcc-build/4.6.0/bld/./gcc/xgcc -B/tmp/gcc-build/4.6.0/bld/./gcc/ -B/usr/local/gcc/4.6.0/i386-pc-solaris2.11/bin/ -B/usr/local/gcc/4.6.0/i386-pc-solaris2.11/lib/ -isystem /usr/local/gcc/4.6.0/i386-pc-solaris2.11/include -isystem /usr/local/gcc/4.6.0/i386-pc-solaris2.11/sys-include-c -g -O2 conftest.c >&5 ld.so.1: cc1: fatal: libmpc.so.2: open failed: No such file or directory xgcc: internal compiler error: Killed (program cc1) Please submit a full bug report, with preprocessed source if appropriate. Workaround that I found is to remove all .so files from /opt/local/lib (libmpc.so.2 and others) After this build succeeds. I should note that I use Solaris 11 appliance ready to run in VirtualBox.
[Bug c/49685] New: libgcc_s.so not compiled without optimization when requested
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49685 Summary: libgcc_s.so not compiled without optimization when requested Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: y...@tsoft.com I need to have libgcc_s.so without optimization and with debug info. Following documentation on GCC own site http://gcc.gnu.org/onlinedocs/libstdc++/manual/debug.html, I ran make with overriding compilation flags: make CXXFLAGS='-g3 -fno-inline -O0' CFLAGS='-g3 -fno-inline -O0' all But the resulting libgcc_s.so is still optimized. I could see that "-O 2" was passed to all compiles. Actually, gcc build process should respect the given to the top-level make CFLAGS and CXXFLAGS and propagate them to all levels.
[Bug c++/35876] Exceptions not working on FreeBSD
--- Comment #1 from yuri at tsoft dot com 2008-04-09 18:06 --- After further investigation it appears to be some issue with exceptions in FreeBSD-STABLE-7.0 system g++ compiler. Exceptions don't work on FreeBSD with system compiler at all. System compiler is a version of gcc-4.2.1 tweaked by FreeBSD folks in some way so let's leave it alone. But gcc-4.3.0 was freshly compiled by me. And with gcc-4.3.0 exceptions only work when -pthread flag is set (on FreeBSD only). Without -pthread flag gcc-4.3.0 has a problem with exceptions (using it's own gcc-4.3.0 shared libraries). Error is: Abort trap: 6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35876
[Bug c++/35949] New: 'const' attribute applied to typedefed type in methods's return is ignored
In the following code 'const VR' in declaration of the return value of 'kk'
works as just 'VR', without constness.
In arguments 'const VR' is applied as const.
code example
typedef int X;
struct S {
typedef X& VR; // <--- VR is declared as X by-reference
X x;
// uncomment one of these two lines:
const VR kk(VR) const { return (x); } // <--- bug: first 'const' is
ignored and function is defined as returning *not* const causing compiler error
message
// const X& kk(VR) const { return (x); } // <--- ok: function is defined as
returning const by-reference
};
void f() {
typedef S::VR VR;
const X& (S::*fn)(VR) const; // <---: ask for the function returning
by-reference
fn = &S::kk; // <--- error message here
}
--
Summary: 'const' attribute applied to typedefed type in methods's
return is ignored
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: yuri at tsoft dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35949
