http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52734
Bug #: 52734
Summary: Incorrect optimization of uClibc sbrk()
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52734
--- Comment #5 from michael at talamasca dot ocis.net 2012-03-27 07:57:02 UTC ---
Created attachment 27009
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27009
Typescript of Michael running Mikael's version of the testcase
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52734
--- Comment #6 from michael at talamasca dot ocis.net 2012-03-27 08:05:06 UTC ---
Created attachment 27011
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27011
Assembly output of Mikael's testcase, from Michael's compute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326
Summary: Target attribute leaks from function pointers
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassig..
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55589
--- Comment #4 from michael at talamasca dot ocis.net 2012-12-13 23:36:53 UTC ---
The patch doesn't compile. At __wrap_pthread_create, it starts erroring
because the pthread_t and pthread_attr_t types do not exist.
It appears that
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326
--- Comment #2 from michael at talamasca dot ocis.net 2013-03-30 00:26:53 UTC ---
The bug itself seems to have been silently fixed in 4.7.2 or earlier, maybe.
My testcase no longer causes cmov to be emitted, although this could be an
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55589
Bug #: 55589
Summary: Failure compiling "generic-morestack-thread.c",
without threads
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCON
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55589
--- Comment #2 from michael at talamasca dot ocis.net 2012-12-05 08:38:49 UTC ---
My usual GCC recipe is this:
configure
--build=i386-pc-linux-uclibc
--prefix=/usr
--sysconfdir=/etc
--sharedstatedir=/var/com
--localstatedir=/var
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018
Bug #: 57018
Summary: Miscompilation of bison 2.7.1 under "-Os
-fomit-frame-pointer"
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57018
--- Comment #2 from michael at talamasca dot ocis.net 2013-04-21 04:36:34 UTC ---
I've always been in the habit of specifying --host=i386-... so that my binaries
don't vary based on where I compile them.
I tried a few -march
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48326
--- Comment #5 from michael at talamasca dot ocis.net ---
Do I have to file a separate bug report in order to fix the problem that
current GCC releases can't be expected to bootstrap up if the starting compiler
is GCC 4.7.0 (among several
ty: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: michael at talamasca dot ocis.net
On my system, the following C++ code refuses to compile:
#include
int foo (void)
{
return std::getchar();
}
The immediat
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: michael at talamasca dot ocis.net
Consider the following invalid C code:
#define FALSE 0
#define TRUE 1
enum {FALSE = 0, TRUE = 1} BOOL;
Given in a single file, GCC produces a meaningful error
13 matches
Mail list logo
