[Bug c++/45284] New: sort accesses memory before first iterator
Hello!
I am trying to sort an array in my program:
#include cstdlib
#include cstdio
#include algorithm
#include stdint.h
using namespace std;
class E
{
public:
int64_t x;
int a;
bool operator(const E e2) const
{
return x != e2.x ? x e2.x : a;
}
};
E *e;
void alloc()
{
e = new E[100100];
}
int32_t main()
{
freopen(bad_array, r, stdin);
int n = 10;
alloc();
for(int i = 0; i n; ++i)
{
scanf(%lld %d, e[i].x, e[i].a);
}
sort(e, e + n);
}
I am getting a segmentation fault in std::sort, when trying to sort a bad
array:
bori...@vaio:~/gcc-bug$ g++ -o bug bug.cpp -g3
bori...@vaio:~/gcc-bug$ gdb ./bug
GNU gdb (GDB) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type show copying
and show warranty for details.
This GDB was configured as x86_64-slackware-linux.
For bug reporting instructions, please see:
http://www.gnu.org/software/gdb/bugs/...
Reading symbols from /home/borisko/gcc-bug/bug...done.
(gdb) run
Starting program: /home/borisko/gcc-bug/bug
Program received signal SIGSEGV, Segmentation fault.
0x004007e3 in E::operator (this=0x7fffdd60, e2=...) at bug.cpp:15
15 return x != e2.x ? x e2.x : a;
(gdb) p e
$1 = (E *) 0x77e4b010
(gdb) p e2
$2 = (const E *) 0x77e4aff0
Also, valgrind notices incorrect accesses to memory like
bori...@vaio:~/gcc-bug$ valgrind ./bug
==8890== Invalid read of size 8
==8890==at 0x4007E3: E::operator(E const) const (bug.cpp:15)
==8890==by 0x400B22: E* std::__unguarded_partitionE*, E(E*, E*, E)
(stl_algo.h:2212)
==8890==by 0x400921: void std::__introsort_loopE*, long(E*, E*, long)
(stl_algo.h:2268)
==8890==by 0x40085C: void std::sortE*(E*, E*) (stl_algo.h:5220)
==8890==by 0x40079E: main (bug.cpp:40)
==8890== Address 0x5947030 is 16 bytes before a block of size 1,601,600
alloc'd
==8890==at 0x4C262A4: operator new[](unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8890==by 0x4006E9: alloc() (bug.cpp:23)
==8890==by 0x40071F: main (bug.cpp:33)
or
==8890== Invalid read of size 8
==8890==at 0x400DBF: void std::__unguarded_linear_insertE*, E(E*, E)
(stl_algo.h:2069)
==8890==by 0x400C4D: void std::__unguarded_insertion_sortE*(E*, E*)
(stl_algo.h:2148)
==8890==by 0x4009CA: void std::__final_insertion_sortE*(E*, E*)
(stl_algo.h:2179)
==8890==by 0x40086F: void std::sortE*(E*, E*) (stl_algo.h:5222)
==8890==by 0x40079E: main (bug.cpp:40)
==8890== Address 0x5947030 is 16 bytes before a block of size 1,601,600
alloc'd
==8890==at 0x4C262A4: operator new[](unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8890==by 0x4006E9: alloc() (bug.cpp:23)
==8890==by 0x40071F: main (bug.cpp:33)
or
==8890== Invalid write of size 8
==8890==at 0x400DC9: void std::__unguarded_linear_insertE*, E(E*, E)
(stl_algo.h:2069)
==8890==by 0x400C4D: void std::__unguarded_insertion_sortE*(E*, E*)
(stl_algo.h:2148)
==8890==by 0x4009CA: void std::__final_insertion_sortE*(E*, E*)
(stl_algo.h:2179)
==8890==by 0x40086F: void std::sortE*(E*, E*) (stl_algo.h:5222)
==8890==by 0x40079E: main (bug.cpp:40)
==8890== Address 0x5947038 is 8 bytes before a block of size 1,601,600 alloc'd
==8890==at 0x4C262A4: operator new[](unsigned long) (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==8890==by 0x4006E9: alloc() (bug.cpp:23)
==8890==by 0x40071F: main (bug.cpp:33)
Is it a bug, or I am doing something wrong?
The problem doesn't appear on all arrays, I will attach the bad array in the
next message.
bori...@vaio:~/gcc-bug$ LC_ALL=C g++ -v
Reading specs from /usr/lib64/gcc/x86_64-slackware-linux/4.4.4/specs
Target: x86_64-slackware-linux
Configured with: ../gcc-4.4.4/configure --prefix=/usr --libdir=/usr/lib64
--enable-shared --enable-bootstrap
--enable-languages=ada,c,c++,fortran,java,objc --enable-threads=posix
--enable-checking=release --with-system-zlib
--with-python-dir=/lib64/python2.6/site-packages --disable-libunwind-exceptions
--enable-__cxa_atexit --enable-libssp --with-gnu-ld --verbose
--disable-multilib --target=x86_64-slackware-linux
--build=x86_64-slackware-linux --host=x86_64-slackware-linux
Thread model: posix
gcc version 4.4.4 (GCC)
bori...@vaio:~/gcc-bug$ uname -a
Linux vaio 2.6.34.1 #9 SMP Tue Aug 3 13:01:34 MSD 2010 x86_64 Intel(R) Core(TM)
i5 CPU M 520 @ 2.40GHz GenuineIntel GNU/Linux
--
Summary: sort accesses memory before first iterator
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: major
Priority: P3
[Bug c++/45284] sort accesses memory before first iterator
--- Comment #1 from boris at dolgov dot name 2010-08-14 07:37 --- Created an attachment (id=21476) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21476action=view) The array, where sort fails -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45284
[Bug c++/45284] sort accesses memory before first iterator
--- Comment #2 from schwab at linux-m68k dot org 2010-08-14 08:44 --- Your operator is not strict (!operator(x,x) for all x). -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45284
A question about gcc bugs
Hello, Recently I am investigating gcc bugs. I wonder whether the position of bugs that have been fixed are recorded. For example, in A file, there is a B bug. Do you record the line number of the B bug after you fix it? I went over the Bugzilla, but I only see that the state of a bug instead of the specific occurence of the bug. Thus I come up with this question. I guess the position of a bug is important for researchers and other people who want to investigate the maintenance of gcc. Thank you for your help!
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
--- Comment #8 from burnus at gcc dot gnu dot org 2010-08-14 09:03 --- Another test case, which requires PR45170 (allocable string lengths); it should print |cdef| (found at c.l.f in the thread Problem with automatic reallocation of allocatable scalar on assignment) program tst character(len=:), allocatable :: S S='abcdef' S=S(3:) write(*,'(|,A,|)')S end program tst -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810
[Bug fortran/37829] Incorrect name mangling with iso_c_binding
--- Comment #14 from burnus at gcc dot gnu dot org 2010-08-14 09:31 ---
Cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/887251d8cd64eb02
Lightly tested patch. The ts.is_c_interop is only set when via
verify_bind_c_derived_type, which is called by resolve.c - and thus comes too
late.
I am not sure whether this now allows DT which are not BIND(C) and whether one
thus should add an !attr.resolved, but I assume that incompatibilities between
the BIND(C) attribute for the DT and the actual DT will be found at resolution
time. Thus, the patch should be fine.
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (Revision 163239)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -991,7 +991,7 @@ verify_c_interop_param (gfc_symbol *sym)
/* Make personalized messages to give better feedback. */
if (sym-ts.type == BT_DERIVED)
gfc_error (Type '%s' at %L is a parameter to the BIND(C)
- procedure '%s' but is not C interoperable
+ procedure '%s' but is not C interoperable
because derived type '%s' is not C interoperable,
sym-name, (sym-declared_at),
sym-ns-proc_name-name,
@@ -3612,7 +3612,8 @@ gfc_try
verify_c_interop (gfc_typespec *ts)
{
if (ts-type == BT_DERIVED ts-u.derived != NULL)
-return (ts-u.derived-ts.is_c_interop ? SUCCESS : FAILURE);
+return (ts-u.derived-ts.is_c_interop || ts-u.derived-attr.is_bind_c)
+ ? SUCCESS : FAILURE;
else if (ts-is_c_interop != 1)
return FAILURE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #52 from rogerio at rilhas dot com 2010-08-14 13:17 --- Do you really want me to go away? You are not using the right formula for that. You know I have a problem and I can't resist. Everytime you post a message you're just calling me back! (In reply to comment #49) You're rude, ignorant and annoying. Yes I am. But a little bit less every day, thanks to (respectively) my mom, your clarifications about the standards, and my 12-step program. (In reply to comment #51) There you go, you are now famous. http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism Why did you remove the post? Do you think something there is not true? You said it, why is it not true? Are you recanting? Wikipedia is the place to post true statements, it if is the truth then it should be there. Don't tell me now that you are ashamed of what you said, are you? Please: you and your friends keep of from removing a perfectly valid criticism that I backed up with your statements. You think you can just keep on removing, but I'll just keep on putting it back. Until I get bored and take it up to Wilkipedia. Why didn't you remove the other guy's criticism about GCC being buggy and producing crappy code? Is his criticism better than mine? Is it better substantiated than mine? Thank you, that's encouraging, I just hope the language of that article won't be changed too much to also mention everyone else who has a clue. No, from the time I posted it first I changed it only once because I realised (based on it being undefined right now) that the code could break at any time, not just with future releases of GCC. Because, you see, I'm of course very excited about me being famous now and about being the only one who knows the truth, but OTOH I fear there were some other clever people that happen to agree with me, and I now see a real danger of those replacing me in that wikipedia article. I don't see where you are getting at. I don't want you to be the only one who knows the truth, I want everyone to know about it. Duhh!! Why else would I post it on Wikipedia?? I don't want GCC to keep any secret pitfalls from anyone, is that alright with you? Even worse would be that the list of names would be too large to mention in wikipedia and that the list would be replaced by some more unspecific phrases like people who actually understood the standard or the like. Ah, I see. You are afraid of someone removing your name from the post? I won't do that, I promise. And while the reference to your comment is there you will always have a place among the stars. So be sure to try your best to keep it there!! The comunity has been warned about GCC. Everybody who reads Wikipedia. Some of them are programmers. Which community? Rogerio-cdecl church followers? Possibly. In between our other rituals. My followers use their prayer time as they like, many of them use that time to seek enlightment. They can get it from wherever they like, including Wikipedia. Or C standards. Or bugzilla bug reports. Whatever. In that case I'm happy, because I'll expect less bug-reports from supporters of that specific religion. Sure, you already shut me up. And I thanked you, remember? (I still have the same opinion of you, but your error rate dropped a little more... still impressivly high, though). I confessed that I did learn from your post (not being sarcastic, I really did). I'll continue to feel sorry for them (especially because I've learned over the conversation that you might actually influence new programmers, which is a terrible thing to do for you) but am not particularly looking forward to seeing misguided and crippled attempts of creating meagre imitations of stumbling pseudo bug-reports, especially because we can have the best there is: Rilhas bugs! Yup. I now realize why my bug reports aren't really bug report. Just some side-effect of me not realizing the full impact of GCC just following standards. It claims is cdecl conformant, but even without optimizations it doesn't place parameters on the stack as cdecl states. My bad, GCC does not guarantee cdecl anywhere, you are right. So I'll just shut up with that. And getting the address of parameters? You are right, not defined in the standards. You are right too. So I'll just shut up with that too. So, the 2 bug reports are, thus, squashed as invalid. (not being sarcastic either). As for Rilhas' bugs? None, as long as I steer clear of GCC. And my code works? Yes. And am I good at what I do? Yes? How do I know? My mom tells me so all the time (and besides I continuously get paid very well, which is my second strongest indicator that I do a good job). Am I afraid of doing non-standard things? No, standards have to keep up with the real world and with special pusher compilers, like MSC. If one day some standard realizes that what MSC does is clever and adopts it then GCC will eventually follow. If not then I'll just keep on
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #53 from redi at gcc dot gnu dot org 2010-08-14 13:55 ---
(In reply to comment #52)
(In reply to comment #51)
There you go, you are now famous.
http://en.wikipedia.org/wiki/GNU_Compiler_Collection#Criticism
Why did you remove the post? Do you think something there is not true? You
said
it, why is it not true? Are you recanting? Wikipedia is the place to post true
statements, it if is the truth then it should be there. Don't tell me now that
you are ashamed of what you said, are you?
Look at the page history, it was removed by someone else, probably because your
comment is badly written and not suitable for the Wikipedia page.
As with most of your comments, they are unfounded and easily refuted by
checking facts, but you're so sure you know them that you don't need to check.
As you've said before, learn to read.
Please: you and your friends keep of from removing a perfectly valid criticism
that I backed up with your statements. You think you can just keep on
removing,
but I'll just keep on putting it back. Until I get bored and take it up to
Wilkipedia. Why didn't you remove the other guy's criticism about GCC being
buggy and producing crappy code? Is his criticism better than mine? Is it
better substantiated than mine?
Wikipedia editors are our friends now? Are you paranoid?
I don't see where you are getting at. I don't want you to be the only one who
knows the truth, I want everyone to know about it. Duhh!! Why else would I
post
it on Wikipedia?? I don't want GCC to keep any secret pitfalls from anyone, is
that alright with you?
Noone wants it to be a secret, everyone in the GCC project would prefer if no
users shared your incorrect beliefs.
It claims is cdecl conformant, but even without optimizations it doesn't place
parameters on the stack as cdecl states. My bad, GCC does not guarantee cdecl
anywhere, you are right. So I'll just shut up with that.
Check your favourite reference - the Wikipedia entry on cdecl says GCC is the
de facto standard for caling conventions on Linux - so by definition what GCC
does is correct. It must be true, Wikipedia says so.
Was Microsoft wrong? No, us in the real world love it. In fact, this code:
class Color;
class Vector;
virtual func(Color c=Color(WHITE), Vector v=Vector(VECTOR_Z));
Has no workaround for in GCC. Why? Because GCC can't initialize parameters
that
are classes. MSC can. So this code (which I needed to do, no real practical
alternative), cannot be compiled in GCC. Why? Because GCC doesn't go beyond
standards. Period.
What are you talking about? You were originally talking about initializing
non-const references with temporaries. The code above would work fine, if
you'd defined Color and Vector.
class Color { public: Color(int); };
class Vector { public: Vector(int); };
const int WHITE = 0;
const int VECTOR_Z = 0;
class Idiot {
virtual void func(Color c = Color(WHITE), Vector v = Vector(VECTOR_Z));
};
GCC compiles that fine, try it.
GCC compiles that because it's valid C++.
What is your point?
Keep this up, future employers will love to see you making an idiot of yourself
so publicly.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45284] sort accesses memory before first iterator
--- Comment #3 from redi at gcc dot gnu dot org 2010-08-14 14:00 ---
You probably want something like
bool operator(const E e2) const
{
return x != e2.x ? x e2.x : a e2.a;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45284
[Bug target/45206] [4.6 regression] ICE on __builtin_eh_return at -Os
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-08-14 14:01 --- Recategorizing after: 2010-08-12 H.J. Lu hongjiu...@intel.com Uros Bizjak ubiz...@gmail.com * config.gcc: Handle --enable-frame-pointer. * configure.ac: Add --enable-frame-pointer. * configure: Regenerated. * config/i386/i386.c (USE_IX86_FRAME_POINTER): Default to 0. (override_options): If not configured with --enable-frame-pointer, enable -fomit-frame-pointer (but not for TARGET_MACHO or when optimizing for size), -fasynchronous-unwind-tables and -maccumulate-outgoing-args by default. The option -Os (or -mno-accumulate-outgoing-args) is now needed: e...@new-host:~/gnat/gnat-head/native32 gcc/xgcc -Bgcc -S pr45206.c -Os pr45206.c: In function '_Unwind_RaiseException': pr45206.c:8:1: internal compiler error: in ix86_expand_epilogue, at config/i386/i386.c:10177 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |major Component|bootstrap |target GCC build triplet|i586-*-*|ix86-*-* GCC host triplet|i586-*-*|ix86-*-* GCC target triplet|i586-*-*|ix86-*-* Last reconfirmed|2010-08-06 11:06:16 |2010-08-14 14:01:27 date|| Summary|[4.6 regression] ICE in |[4.6 regression] ICE on |ix86_expand_epilogue|__builtin_eh_return at -Os |compiling libgcc| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #54 from redi at gcc dot gnu dot org 2010-08-14 14:25 --- (In reply to comment #53) GCC compiles that fine, try it. Sorry, I forgot my manners, what I meant is... Why don't you think before shooting off some crap. So I have shown you talk crap. Do you like it? Better get used to it, I'm a mean sonofagun and I'll keep showing you why you're wrong. You're an idiot. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #55 from rogerio at rilhas dot com 2010-08-14 14:31 ---
(In reply to comment #53)
(In reply to comment #52)
(In reply to comment #51)
Look at the page history, it was removed by someone else, probably because
your
comment is badly written and not suitable for the Wikipedia page.
I thought that was your mom, sorry. We are alright then. When the guy removes
it again I'll tell him to ask you if it is true. If you don't recant he will
know I'm telling the truth.
As with most of your comments, they are unfounded and easily refuted by
checking facts, but you're so sure you know them that you don't need to check.
As you've said before, learn to read.
Right, that must be it. As if I didn't backed it up with your own comment #35.
Boy, it will sure be easy to prove my post to be unfounded!!!
Noone wants it to be a secret, everyone in the GCC project would prefer if no
users shared your incorrect beliefs.
So do I. I don't want anyone sharing my incorrect beliefs. Did we just agree on
something here? So I'll tell the guy to talk to ask you.
Check your favourite reference - the Wikipedia entry on cdecl says GCC is the
de facto standard for caling conventions on Linux - so by definition what GCC
does is correct. It must be true, Wikipedia says so.
... unless it was your post! You tend to miss more than you hit. But yeah,
you've shut me up on that too. I just wrote that in my previous post.
What are you talking about? You were originally talking about initializing
non-const references with temporaries.
Yes, that is right. GCC gave me the same error in both cases (aren't default
parameters initialized with classes the same as parameters initialized with
classes?). Probably my bad.
The code above would work fine, if
you'd defined Color and Vector.
class Color { public: Color(int); };
class Vector { public: Vector(int); };
const int WHITE = 0;
const int VECTOR_Z = 0;
class Idiot {
virtual void func(Color c = Color(WHITE), Vector v = Vector(VECTOR_Z));
};
GCC compiles that fine, try it.
Yeah, you are right, your class does. But mine don't, the diference is that
mine are a bit more complex and derive a lot... but you were right, yours does
compile. And I was right, my code with GCC would have given me more trouble to
deliver to the client. But you are right, I posted an Idiot class. (see how
easy it is to admit when we are wrong? .. if you tried it you would quickly
gain a lot of practice! ... anyway, good job in reducing your error rate, it is
now close to a normal person!)
GCC compiles that because it's valid C++.
What is your point?
Keep this up, future employers will love to see you making an idiot of
yourself
so publicly.
No, the worse is being wrong and don't admit it. When we admit we learn, so
I've been learning quite a lot with you guys. You didn't admit anything, so in
your mind LDT read accesses a still prohibitive, and crap like that. Or did you
think I would forget all the crap that you said that I shot down and you didn't
admit?? Your future employers (if any!) will see that your ability to learn
simple stuff is impaired.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #56 from rogerio at rilhas dot com 2010-08-14 14:34 --- (In reply to comment #54) (In reply to comment #53) GCC compiles that fine, try it. Sorry, I forgot my manners, what I meant is... Why don't you think before shooting off some crap. So I have shown you talk crap. Do you like it? Better get used to it, I'm a mean sonofagun and I'll keep showing you why you're wrong. You're an idiot. Yeah, I've seen you show me I said crap that I didn't study well enough before saying it. I learned, it will never be repeated. All the rap you said that I shot down didn't make you learn anything. We are both idiots, but I'm a little bit less every day. I've left you behind a long time ago. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug bootstrap/45285] New: Bootstrap failure on Cygwin
Bootstrap comparison failure! i686-pc-cygwin/libgomp/.libs/bar.o differs i686-pc-cygwin/libgomp/.libs/barrier.o differs i686-pc-cygwin/libgomp/.libs/critical.o differs i686-pc-cygwin/libgomp/.libs/env.o differs i686-pc-cygwin/libgomp/.libs/iter.o differs i686-pc-cygwin/libgomp/.libs/iter_ull.o differs i686-pc-cygwin/libgomp/.libs/lock.o differs i686-pc-cygwin/libgomp/.libs/loop.o differs i686-pc-cygwin/libgomp/.libs/loop_ull.o differs i686-pc-cygwin/libgomp/.libs/ordered.o differs i686-pc-cygwin/libgomp/.libs/parallel.o differs i686-pc-cygwin/libgomp/.libs/proc.o differs i686-pc-cygwin/libgomp/.libs/sections.o differs i686-pc-cygwin/libgomp/.libs/single.o differs i686-pc-cygwin/libgomp/.libs/task.o differs i686-pc-cygwin/libgomp/.libs/team.o differs i686-pc-cygwin/libgomp/.libs/work.o differs i686-pc-cygwin/libgomp/bar.o differs i686-pc-cygwin/libgomp/barrier.o differs i686-pc-cygwin/libgomp/critical.o differs i686-pc-cygwin/libgomp/env.o differs i686-pc-cygwin/libgomp/iter.o differs i686-pc-cygwin/libgomp/iter_ull.o differs i686-pc-cygwin/libgomp/lock.o differs i686-pc-cygwin/libgomp/loop.o differs i686-pc-cygwin/libgomp/loop_ull.o differs i686-pc-cygwin/libgomp/ordered.o differs i686-pc-cygwin/libgomp/parallel.o differs i686-pc-cygwin/libgomp/proc.o differs i686-pc-cygwin/libgomp/sections.o differs i686-pc-cygwin/libgomp/single.o differs i686-pc-cygwin/libgomp/task.o differs i686-pc-cygwin/libgomp/team.o differs i686-pc-cygwin/libgomp/work.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/Jerry/gcc/objdir' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/Jerry/gcc/objdir' make: *** [all] Error 2 I am trying a non-bootstrap build now to see if I can get something working, then I will go back to bootstrap attempt. Stay tuned -- Summary: Bootstrap failure on Cygwin Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jvdelisle at gcc dot gnu dot org GCC host triplet: Cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45285
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #18 from danglin at gcc dot gnu dot org 2010-08-14 14:37 --- Subject: Bug 34544 Author: danglin Date: Sat Aug 14 14:36:47 2010 New Revision: 163242 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163242 Log: Revert: 2010-08-10 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR boehm-gc/34544 * gthr-posix.h (__gthread_start): Delete. (__gthread_active_init): Use pthread_default_stacksize_np instead of pthread_create to determine if hpux pthreads are active. * gthr-posix95.h (__gthread_start): Delete. (__gthread_active_init): Likewise use pthread_default_stacksize_np. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/gthr-posix.h branches/gcc-4_3-branch/gcc/gthr-posix95.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #19 from danglin at gcc dot gnu dot org 2010-08-14 14:43 --- Subject: Bug 34544 Author: danglin Date: Sat Aug 14 14:42:43 2010 New Revision: 163243 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163243 Log: Revert: 2010-08-08 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR boehm-gc/34544 * gthr-posix.h (__gthread_start): Delete. (__gthread_active_init): Use pthread_default_stacksize_np instead of pthread_create to determine if hpux pthreads are active. * gthr-posix95.h (__gthread_start): Delete. (__gthread_active_init): Likewise use pthread_default_stacksize_np. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/gthr-posix.h branches/gcc-4_4-branch/gcc/gthr-posix95.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug boehm-gc/34544] pthread_default_stacksize_np failed.
--- Comment #20 from danglin at gcc dot gnu dot org 2010-08-14 14:45 --- Subject: Bug 34544 Author: danglin Date: Sat Aug 14 14:45:20 2010 New Revision: 163244 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163244 Log: Revert: 2010-08-08 John David Anglin dave.ang...@nrc-cnrc.gc.ca PR boehm-gc/34544 * gthr-posix.h (__gthread_start): Delete. (__gthread_active_init): Use pthread_default_stacksize_np instead of pthread_create to determine if hpux pthreads are active. * gthr-posix95.h (__gthread_start): Delete. (__gthread_active_init): Likewise use pthread_default_stacksize_np. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/gthr-posix.h branches/gcc-4_5-branch/gcc/gthr-posix95.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34544
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #57 from redi at gcc dot gnu dot org 2010-08-14 15:09 --- (In reply to comment #55) (In reply to comment #53) Look at the page history, it was removed by someone else, probably because your comment is badly written and not suitable for the Wikipedia page. I thought that was your mom, sorry. Good way to make a convincing argument. You've tried to turn this into a your mom argument in three replies now, but noone seems to be rising to the bait. No, the worse is being wrong and don't admit it. When we admit we learn, so I've been learning quite a lot with you guys. You didn't admit anything, so in your mind LDT read accesses a still prohibitive, and crap like that. Or did you think I would forget all the crap that you said that I shot down and you didn't admit?? Your future employers (if any!) will see that your ability to learn simple stuff is impaired. Are you confusing me with Michael? I've not said anything about LDT. What am I supposed to admit? That GCC compiles valid C++ code? That I've wasted time replying to you? That's true, but it's my weekend and I'm waiting for a GCC testsuite run to finish so I have time. You keep accusing GCC of not compiling useful C++ code, but haven't shown a valid example yet. I am happy to learn but I don't see anything worth learning from you, your opinions or your debating style. Even your trolling skills are poor, and you started so well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #12 from armin76 at gentoo dot org 2010-08-14 15:33 --- Any news? :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #58 from rogerio at rilhas dot com 2010-08-14 16:02 --- Why?? Why do you keep calling me back?? I was just going out and I heard the new e-mail sound! Now I'm going to be late!! (In reply to comment #57) Good way to make a convincing argument. You've tried to turn this into a your mom argument in three replies now, but noone seems to be rising to the bait. Not an argument. I said I was sorry to think it was you or one of your friends (is Chris your friend?). Anyway, I understand why you got confused and missed my apology, I inserted the mom joke. My bad, it was not funny at all, and you thought it was an argument. My bad. Are you confusing me with Michael? I've not said anything about LDT. Yes I am. I'm sorry for that, I really am. I got mixed up. We were discussing the post and I didn't check the sender. There are just too many of you guys. I'm sorry, this comment wasn't meant for you (I must be getting tired). What am I supposed to admit? That GCC compiles valid C++ code? You don't have to admit anything really. But in your comment #34 to bug #45249 you missed the point entirely and just spewed out standards. You missed the point really, as I was saying GCC can't, and it really can't. Spewing out standards just to explain GCC can't because insert standards here was not really useful for that discussion. Does not make an idiot out of you though. Then you claimed What a charming idea, that a compiler could become perfect by doing what I said it should. And that is very close to making an idiot out of you, because you deflected without getting the background for the conversation straight. I had to show you (again) that you failed to see that what I say is what C99+cdecl say. These all don't make an idiot out of you yet. Adding them all together was borderline-idiot, but still safe. Then, for this bug, your comment #45 missed the point. You didn't understand why I posted it on Wikipedia, although it is well explained there. But ok, I'll grant you that that also does not make an idiot out of you. ... then, from comment #53 on we really looked to me like Michael, so I lost it. Here I go, back to being more of an idiot, and there you go not an idiot yet. That I've wasted time replying to you? That's true, but it's my weekend and I'm waiting for a GCC testsuite run to finish so I have time. You keep accusing GCC of not compiling useful C++ code, but haven't shown a valid example yet. Yes I have. It is there on Wikipedia. The code compiled is not valid (in a functional sense) because the programmer cannot trust the pointer difference. Maybe at this point you get confused because you didn't type valid [according to standards] example, but you didn't type it. So valid is open for discussion. And I say that is valid if it returns 0x4000-0x3000=0x1000. So there you go, now you're an idiot like Michael (well, still less, your error rate is much lower and of much less significance). You are an idiot because you don't know what valid is to everyone, you just think you do because you know of some standard that says what is valid in a given context. I do assembly inside my C code with MSC, is that not valid because it is not defined in any C standard? Nope. It is valid, no matter how much you kick and scream. With the same train of thought I could talk about initializing classes as parameters to functions as in comment #25 of bug #45249 (as another example I posted and that you didn't see), because, again, you didn't explain what the valid word in your text was supposed to mean. I know you mean standards, but there is more to it. But this one does not make an idiot out of you because valid is much harder to define here. So I'm am not in a position to spot the level of idiocy in your comment (I'll just assume it is none). So I say valid (outside in the real world) and you say invalid (based on C standards), but none of us are idiots for it. I am happy to learn but I don't see anything worth learning from you, your opinions or your debating style. Even your trolling skills are poor, and you started so well. That's my point. You keep proving my point. You don't feel the need to learn anything from me because you are all cosy inside your standards box and look down on the other kids playing outside in the real world. You wear all your silk-based standards shirts and mock the dumb kids in the playground that use silk+cotton immitations. You call them idiots even after they've shown you that when you are outside silk doesn't cover all the needs. You don't even realize that I'm right that GCC thus alienates memory mapped device programmers, thus making it inferior to many others. You're stuck in idiot-land. I still don't know what a troll is. English is not my native language. Checking the web it seems like a troll is someone whose primary purpose when posting comments is to provoke disruption. I don't feel like that, I posted what I thought to be actual bugs
[Bug fortran/37829] Incorrect name mangling with iso_c_binding
--- Comment #15 from burnus at gcc dot gnu dot org 2010-08-14 16:24 --- Ignore comment 14 - that's PR fortran/45211. Sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829
[Bug fortran/45211] C interoperable error when compiling BIND(C) function in a module.
--- Comment #3 from burnus at gcc dot gnu dot org 2010-08-14 16:24 ---
Cf.
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/887251d8cd64eb02
Lightly tested patch. The ts.is_c_interop is only set when via
verify_bind_c_derived_type, which is called by resolve.c - and thus comes too
late.
I am not sure whether this now allows DT which are not BIND(C) and whether one
thus should add an !attr.resolved, but I assume that incompatibilities between
the BIND(C) attribute for the DT and the actual DT will be found at resolution
time. Thus, the patch should be fine.
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (Revision 163239)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -991,7 +991,7 @@ verify_c_interop_param (gfc_symbol *sym)
/* Make personalized messages to give better feedback. */
if (sym-ts.type == BT_DERIVED)
gfc_error (Type '%s' at %L is a parameter to the BIND(C)
- procedure '%s' but is not C interoperable
+ procedure '%s' but is not C interoperable
because derived type '%s' is not C interoperable,
sym-name, (sym-declared_at),
sym-ns-proc_name-name,
@@ -3612,7 +3612,8 @@ gfc_try
verify_c_interop (gfc_typespec *ts)
{
if (ts-type == BT_DERIVED ts-u.derived != NULL)
-return (ts-u.derived-ts.is_c_interop ? SUCCESS : FAILURE);
+return (ts-u.derived-ts.is_c_interop || ts-u.derived-attr.is_bind_c)
+ ? SUCCESS : FAILURE;
else if (ts-is_c_interop != 1)
return FAILURE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45211
[Bug target/45070] Miscompiled c++ class with packed attribute on ARM with -Os optimizations (Qt 4.6.2)
--- Comment #13 from siarhei dot siamashka at gmail dot com 2010-08-14 16:28 --- (In reply to comment #12) Any news? :) http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00894.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45070
[Bug c++/45265] GCC has an intermittent bug when computing the address of function parameters
--- Comment #59 from redi at gcc dot gnu dot org 2010-08-14 17:10 ---
(In reply to comment #58)
(is Chris your friend?)
Of course not. I have no idea who he is.
Are you confusing me with Michael? I've not said anything about LDT.
Yes I am. I'm sorry for that, I really am. I got mixed up. We were discussing
the post and I didn't check the sender. There are just too many of you guys.
I'm sorry, this comment wasn't meant for you (I must be getting tired).
See, you talk crap? (I'm responding like that because that's your manner of
response, you attack and you insult and you aren't even paying attention to
what you're replying to.)
What am I supposed to admit? That GCC compiles valid C++ code?
You don't have to admit anything really. But in your comment #34 to bug #45249
you missed the point entirely and just spewed out standards. You missed the
point really, as I was saying GCC can't, and it really can't. Spewing out
standards just to explain GCC can't because insert standards here was not
really useful for that discussion. Does not make an idiot out of you though.
GCC *could* compile invalid code, if we wanted it to, but it doesn't. That's by
design, not due to accident or inability to make it work.
Several other C++ compilers don't compile it either.
The reason is because they aim to follow the relevant standards. And so that's
why I referenced the standard.
Then you claimed What a charming idea, that a compiler could become perfect
by
doing what I said it should. And that is very close to making an idiot out
of you, because you deflected without getting the background for the
conversation straight. I had to show you (again) that you failed to see that
what I say is what C99+cdecl say.
Yes, that was sarcasm, in the (apparently wrong) hope that you'd get a hint and
go away.
You keep accusing GCC of not compiling useful C++ code, but haven't shown a
valid example yet.
Yes I have. It is there on Wikipedia. The code compiled is not valid (in a
functional sense) because the programmer cannot trust the pointer difference.
Maybe at this point you get confused because you didn't type valid [according
to standards] example, but you didn't type it. So valid is open for
discussion. And I say that is valid if it returns 0x4000-0x3000=0x1000.
The ISO C and C++ standards say what's valid in this context, not you.
So there you go, now you're an idiot like Michael (well, still less, your
error
rate is much lower and of much less significance). You are an idiot because
you
don't know what valid is to everyone, you just think you do because you know
of some standard that says what is valid in a given context. I do assembly
inside my C code with MSC, is that not valid because it is not defined in
any
C standard? Nope. It is valid, no matter how much you kick and scream.
No, in the context of a compiler which tries to conform to the ISO standard,
the ISO standard is the definition of what's valid.
With the same train of thought I could talk about initializing classes as
parameters to functions as in comment #25 of bug #45249 (as another example I
posted and that you didn't see), because, again, you didn't explain what the
valid word in your text was supposed to mean. I know you mean standards, but
there is more to it. But this one does not make an idiot out of you because
valid is much harder to define here. So I'm am not in a position to spot the
level of idiocy in your comment (I'll just assume it is none). So I say
valid
(outside in the real world) and you say invalid (based on C standards), but
none of us are idiots for it.
You are welcome to use any definition of valid in your personal conversations,
but in the context of a compiler which aims to conform to the ISO standards you
don't get to decide what the definition of valid is. And this bugzilla is,
most certainly, in the context of GCC.
If you want to discuss other uses of valid or non-standard code, do it
somewhere else, such as the comp.lang.c newsgroup.
G++ doesn't compile that code because the code is invalid, and binding
non-const references to rvalues is unsafe, and C++ experts have decided that a
conforming compiler should not allow it. One reason for that is the following:
class X { int i; }
X f(X x) { return x; }
int main()
{
X x1 = f( X() );
return x.i;
}
This code is unsafe because it accesses X::i after it has been freed.
The standard says it's not allowed, and G++ implements that. You are free to
say it should be different, but noone will agree with you.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45265
[Bug target/45084] configure: error: no 8-bit type
--- Comment #4 from burgess at greeneridge dot com 2010-08-14 18:36 --- I just encountered the identical error (same library, same line number, same message) while compiling arm-elf-gcc 4.5.1 under Mac OS X Snow Leopard 10.6.4. I am not a expert at compiling gnu tools and am running scripts obtained elsewhere. However I did change two things and then reattempted the compile -- and the entire build process completed normally! The two things I did were: (1) update my Darwin gcc compiler executable with the recent XCode update released in August 2010. However the update did not change the Darwin gcc version substantially (it is now 4.2.1) and I don't think it made the difference. (2) the build script I use compiles arm-elf-gcc twice, once before and then again after compiling newlib. It was during the second gcc compile that the error occurred. However I had not completely cleaned my build environment since the last build many months ago and the script was skipping the recompile of newlib. After I thoroughly cleaned my build environment, the script then rebuilt newlib as intended before going on to compile arm-elf-gcc the second time -- now successfully. I regret my experience with compiling gnu tools is too sparse to understand what happened or even to know what information you all need to understand. But hopefully this at least sheds some light on the issue. -- burgess at greeneridge dot com changed: What|Removed |Added CC||burgess at greeneridge dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45084
[Bug fortran/44931] For INPUT_UNIT, INQUIRE NAME= should not return stdin
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2010-08-14 18:59 --- Subject: Bug 44931 Author: jvdelisle Date: Sat Aug 14 18:59:18 2010 New Revision: 163245 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163245 Log: 2010-08-14 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/44931 * io/inquire.c (inquire_via_unit): Add special case for __MINGW32__ to return special file names CONIN$, CONOUT$, and CONERR$. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/inquire.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44931
[Bug target/43358] [4.5/4.6 Regression] IRA: internal compiler error: in pool_free, at alloc-pool.c:335
--- Comment #9 from rsandifo at gcc dot gnu dot org 2010-08-14 19:59 --- Subject: Bug 43358 Author: rsandifo Date: Sat Aug 14 19:59:13 2010 New Revision: 163249 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163249 Log: gcc/ PR rtl-optimization/43358 * ira-lives.c (process_single_reg_class_operands): Adjust the costs of a single hard register, using simplify_subreg_regno to decide what that register should be. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-lives.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43358
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- Comment #2 from redi at gcc dot gnu dot org 2010-08-14 20:01 --- Subject: Bug 45283 Author: redi Date: Sat Aug 14 20:00:55 2010 New Revision: 163250 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163250 Log: 2010-08-14 Jonathan Wakely jwakely@gmail.com PR libstdc++/45283 * testsuite/performance/30_threads/future/polling.cc: Replace calls to shared_future::is_ready. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug target/43358] [4.5 Regression] IRA: internal compiler error: in pool_free, at alloc-pool.c:335
--- Comment #10 from rsandifo at gcc dot gnu dot org 2010-08-14 20:07 --- Fixed in trunk. I'll wait to see how it affects other targets before backporting to 4.5. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added CC|rdsandiford at googlemail | |dot com | Summary|[4.5/4.6 Regression] IRA: |[4.5 Regression] IRA: |internal compiler error: in |internal compiler error: in |pool_free, at alloc-|pool_free, at alloc- |pool.c:335 |pool.c:335 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43358
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- Comment #3 from paolo dot carlini at oracle dot com 2010-08-14 21:36 --- Thanks a lot Jon: now check-performance should be clean again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug target/45206] [4.6 regression] ICE on __builtin_eh_return at -Os
--- Comment #9 from hjl dot tools at gmail dot com 2010-08-14 22:23 ---
assert is too strong as shown in the testcase.
This patch works for me:
--
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index b925122..863c9bf 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -10030,7 +10030,11 @@ ix86_expand_epilogue (int style)
rtx t;
if (frame.nregs)
- ix86_emit_restore_regs_using_mov (frame.reg_save_offset, style == 2);
+ {
+ix86_emit_restore_regs_using_mov (frame.reg_save_offset,
+ style == 2);
+m-fs.sp_valid = true;
+ }
/* eh_return epilogues need %ecx added to the stack pointer. */
if (style == 2)
--
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45206
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- Comment #4 from redi at gcc dot gnu dot org 2010-08-15 00:36 --- Subject: Bug 45283 Author: redi Date: Sun Aug 15 00:36:16 2010 New Revision: 163259 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163259 Log: 2010-08-15 Jonathan Wakely jwakely@gmail.com PR libstdc++/45283 * testsuite/performance/30_threads/future/polling.cc: Replace calls to shared_future::is_ready. Modified: branches/gcc-4_5-branch/libstdc++-v3/ChangeLog branches/gcc-4_5-branch/libstdc++-v3/testsuite/performance/30_threads/future/polling.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug libstdc++/45283] performance/30_threads/future/polling.cc fails at compile time
--- Comment #5 from redi at gcc dot gnu dot org 2010-08-15 00:37 --- Fixed for 4.5.2 and 4.6.0 -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45283
[Bug c/45286] New: kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
http://bugs.gentoo.org/show_bug.cgi?id=283470 kact.sa_restorer = restore_rt; get miss compile with -fPIE with -fPIC the code get 48 8d 05 2e ff ff fflea-0xd2(%rip),%rax # 10 __restore_rt and with -fPIE it get 48 8b 05 2e ff ff ffmov-0xd2(%rip),%rax # 10 __restore_rt Later on when we try to use the function in some code it segfault. so it would seem gcc is miscompiling the x86_64 sigaction.c code. specifically, this bit of sysdeps/unix/sysv/linux/x86_64/sigaction.c -- Summary: kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64 Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zorry at ume dot nu GCC target triplet: x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
[Bug target/37734] Missing optimization: gcc fails to reuse flags from already calculated expression for condition check with zero
--- Comment #2 from siarhei dot siamashka at gmail dot com 2010-08-15
01:01 ---
Here is another test example, now with some performance numbers for gcc 4.5.1
on 64-bit Intel Atom:
$ cat fibbonachi.c
/***/
#include stdlib.h
int fib(int n)
{
int sum, previous = -1, result = 1;
n++;
while (--n = 0)
{
sum = result + previous;
previous = result;
result = sum;
}
return result;
}
int main(void)
{
if (fib(10) != 1532868155)
abort();
return 0;
}
/***/
$ gcc -O2 -march=atom -o fibbonachi-O2 fibbonachi.c
$ gcc -Os -march=atom -o fibbonachi-Os fibbonachi.c
$ time ./fibbonachi-O2
real0m3.722s
user0m3.652s
sys 0m0.000s
$ time ./fibbonachi-Os
real0m3.078s
user0m3.044s
sys 0m0.000s
Loop code for -O2 optimizations on x86-64:
18: 89 d1 mov%edx,%ecx
1a: 89 c2 mov%eax,%edx
1c: 8d 7f fflea-0x1(%rdi),%edi
1f: 8d 04 0alea(%rdx,%rcx,1),%eax
22: 83 ff ffcmp$0x,%edi
25: 75 f1 jne18 fib+0x18
Loop code for -Os optimizations on x86-64:
c: 8d 0c 10lea(%rax,%rdx,1),%ecx
f: 89 c2 mov%eax,%edx
11: 89 c8 mov%ecx,%eax
13: ff cf dec%edi
15: 79 f5 jnsc fib+0xc
Also on ARM, loop code is suboptimal in all cases (just subs + bge could be
used without any need for cmn/cmp):
-O2 on ARM:
10: e2433001sub r3, r3, #1
14: e0820001add r0, r2, r1
18: e3730001cmn r3, #1
1c: e1a01002mov r1, r2
20: e1a02000mov r2, r0
24: 1af9bne 10 fib+0x10
-Os on ARM:
c: e0831002add r1, r3, r2
10: e241sub r0, r0, #1
14: e1a02003mov r2, r3
18: e1a03001mov r3, r1
1c: e350cmp r0, #0
20: aaf9bge c fib+0xc
-Os -mthumb on ARM:
8: 1899addsr1, r3, r2
a: 3801subsr0, #1
c: 461amov r2, r3
e: 460bmov r3, r1
10: 2800cmp r0, #0
12: daf9bge.n 8 fib+0x8
There are still similarities between x86 and ARM here. When using -O2
optimizations, the redundant comparison is performed with -1 constant in both
cases.
--
siarhei dot siamashka at gmail dot com changed:
What|Removed |Added
Known to fail||4.5.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37734
[Bug c/45286] kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
--- Comment #1 from zorry at ume dot nu 2010-08-15 01:02 --- Created an attachment (id=21477) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21477action=view) compile with -fPIE This file is compile with -fPIE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
[Bug c/45286] kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
--- Comment #2 from zorry at ume dot nu 2010-08-15 01:04 --- Created an attachment (id=21478) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21478action=view) compile with -fPIC -DSHARED file compiled with -fPIC -DSHARED -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
[Bug c/45286] kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
--- Comment #3 from hjl dot tools at gmail dot com 2010-08-15 02:25 --- (In reply to comment #0) http://bugs.gentoo.org/show_bug.cgi?id=283470 kact.sa_restorer = restore_rt; get miss compile with -fPIE with -fPIC the code get 48 8d 05 2e ff ff fflea-0xd2(%rip),%rax # 10 __restore_rt and with -fPIE it get 48 8b 05 2e ff ff ffmov-0xd2(%rip),%rax # 10 __restore_rt It doesn't necessarily mean wrong. Later on when we try to use the function in some code it segfault. so it would seem gcc is miscompiling the x86_64 sigaction.c code. specifically, this bit of sysdeps/unix/sysv/linux/x86_64/sigaction.c Please extract a small static testcase which shows the miscompiled sigaction.c when linking with a libc.a. I want to know how sigaction.c is compiled. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
[Bug c/45286] kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
--- Comment #4 from vapier at gentoo dot org 2010-08-15 04:41 --- what are you looking for ? miscompiled objects ? linking sigaction.c with a libc.a doesnt make sense as the libc.a already contains sigaction.o. or you want an example app linked against a miscompiled libc.a ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
[Bug c/45286] kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
--- Comment #5 from hjl dot tools at gmail dot com 2010-08-15 05:40 --- Please help me reproduce it with a run-time testcase. I can build libc.a. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
[Bug c/45286] kact.sa_restorer = restore_rt; in sigaction.c glibc get miss compile with -fPIE on x86_64
--- Comment #6 from vapier at gentoo dot org 2010-08-15 05:49 --- Created an attachment (id=21479) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21479action=view) signaler.c register a signal handler that goes though __libc_sigaction(), then trigger that signal and attempt to return. since glibc set the sa_restorer field by reading the data at the address of __rt_sigaction instead of using the address itself, the kernel sets the return address to an invalid address. here is a semi-overly-complicated example: gcc -o signaler signaler.c -static ./signaler set a break point at *sigvtalarm and look at the return address: (gdb) x/1g $rsp 0x7fffd1f8: 0x0f000fc0c748 that's because gcc generated a mov insn which loaded the 64bits at the address of __restore_rt instead of storing the address of __restore_rt itself: 0010 __restore_rt: 10: 48 c7 c0 0f 00 00 00mov$0xf,%rax 17: 0f 05 syscall -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
