Building gcc 4.5.1:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition -Wc++-compat -fno-common -DHAVE_
--- 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=21479&action=view)
signaler.c
register a signal handler that goes though __libc_sigaction(), then trigger
that signal and attempt to ret
--- 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
--- 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 ?
--
h
--- 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 # 1
--- 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=21478&action=view)
compile with -fPIC -DSHARED
file compiled with -fPIC -DSHARED
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
--- 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=21477&action=view)
compile with -fPIE
This file is compile with -fPIE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45286
--- 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
int fib(int n)
{
int sum, previous = -1, result =
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 o
--- 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
Sta
--- 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=gcc&view=rev&rev=163259
Log:
2010-08-15 Jonathan Wakely
PR libstdc++/45283
*
--- 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/i38
--- 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
--- 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
---
--- 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=gcc&view=rev&rev=163250
Log:
2010-08-14 Jonathan Wakely
PR libstdc++/45283
*
--- 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=gcc&view=rev&rev=163249
Log:
gcc/
PR rtl-optimization/43358
* ira-lives
--- 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=gcc&view=rev&rev=163245
Log:
2010-08-14 Jerry DeLisle
PR libfortran/4493
--- 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 scr
--- 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 a
--- 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
--- 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
--- 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
--- 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 i
--- 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
--- 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.
>
>
--- 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=gcc&view=rev&rev=163244
Log:
Revert:
2010-08-08 John David Anglin
--- 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=gcc&view=rev&rev=163243
Log:
Revert:
2010-08-08 John David Anglin
--- 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=gcc&view=rev&rev=163242
Log:
Revert:
2010-08-10 John David Anglin
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 diff
--- 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 c
--- 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
--- 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
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2010-08-14 14:01
---
Recategorizing after:
2010-08-12 H.J. Lu
Uros Bizjak
* config.gcc: Handle --enable-frame-pointer.
* configure.ac: Add --enable-frame-pointer.
* configure: Regenerated.
--- 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
--- 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 somet
--- 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'r
--- 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 - an
--- 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
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
inste
--- 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
---
--- 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=21476&action=view)
The array, where sort fails
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45284
Hello!
I am trying to sort an array in my program:
#include
#include
#include
#include
using namespace std;
class E
{
public:
int64_t x;
int a;
bool operator<(const E& e2) const
{
return x != e2.
42 matches
Mail list logo
