https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036
Alexander Dubov changed:
What|Removed |Added
CC||oakad at yahoo dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814
Alexander Dubov changed:
What|Removed |Added
CC||oakad at yahoo dot com
--- Comment #1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
Alexander Dubov changed:
What|Removed |Added
CC||oakad at yahoo dot com
--- Comment #12 from oakad at yahoo dot com 2010-08-09 06:02 ---
(In reply to comment #11)
> Fixed for 4.5.2.
>
Thanks.
I've been looking into rope data structure per your advice, and indeed, it
needs a lot of fixes. It can probably use canned smart pointers and vstring
--- Comment #5 from oakad at yahoo dot com 2010-07-16 19:21 ---
Why is rope super-legacy? It had not enough attention to it, true, but it's a
very convenient class in certain cases.
Does the bug resolution means that no more changes/updates are expected for gcc
supplied rop
std::back_inserter in c++0x mode
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oakad at yahoo dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: x86_64-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44963
r
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oakad at yahoo dot com
GCC build triplet: x86_64-pc-linux-gnu
--- Comment #4 from oakad at yahoo dot com 2009-11-12 15:09 ---
Indeed so.
I've read a roadmap for e200 just minutes after my previous post. :-)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
--- Comment #2 from oakad at yahoo dot com 2009-11-12 02:51 ---
I understand that changing a triplet behavior is not a good idea.
However, it seems quite unfortunate, that important, performance affecting
feature depends on obscure gcc configuration flag in situation where most
: oakad at yahoo dot com
GCC target triplet: powerpc-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
--- Comment #6 from oakad at yahoo dot com 2008-08-20 06:34 ---
Created an attachment (id=16104)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16104&action=view)
Full assembler output of cfi_flash.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
--- Comment #5 from oakad at yahoo dot com 2008-08-20 06:33 ---
Created an attachment (id=16103)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16103&action=view)
Preprocessed cfi_flash.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
--- Comment #4 from oakad at yahoo dot com 2008-08-20 06:32 ---
(In reply to comment #3)
> Can you provide the preprocessed source which you can get via the -save-temps
> option. Also does using -fno-strict-aliasing fix the issue?
>
-fno-strict-aliasing appears to have no
--- Comment #2 from oakad at yahoo dot com 2008-08-13 08:10 ---
Created an attachment (id=16064)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16064&action=view)
Assembly of the problematic function
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
--- Comment #1 from oakad at yahoo dot com 2008-08-13 08:10 ---
Created an attachment (id=16063)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16063&action=view)
Original source file
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
ReportedBy: oakad at yahoo dot com
GCC build triplet: x86_64-pc-linux-gnu
GCC host triplet: x86_64-pc-linux-gnu
GCC target triplet: powerpc-linux-gnuspe
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
--- Additional Comments From oakad at yahoo dot com 2005-08-23 10:27
---
I was dealing with packed structs in this case. Are you sure that
-mstrict-align will not break packing? And I'm talking of both inter- and
intra-struct packing, as in packed array of packed st
--- Additional Comments From oakad at yahoo dot com 2005-08-17 16:47
---
Thanks, I will check it tomorrow. However, this behavior is different from the
gcc 3, documented nowhere and broke (in a very bad way) a large program with
good reliability record (so far). Can this be mentioned
--- Additional Comments From oakad at yahoo dot com 2005-08-17 16:31
---
Sorry, I misunderstood you. The function is a part of a large project (namely,
u-boot-1.1.3).
What about this:
//--
char str1[]="123456789";
char str2[10];
i
--- Additional Comments From oakad at yahoo dot com 2005-08-17 15:50
---
Preprocessed source:
//--
void board_init_f (ulong bootflag)
{
register volatile gd_t *gd asm ("r29");
bd_t *bd;
ulong len, addr, addr_sp;
--
What|Removed |Added
GCC target triplet|powerpc-eabi-unknown|powerpc-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23444
--
What|Removed |Added
GCC target triplet|powerpc-eabi-gcc|powerpc-eabi-unknown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23444
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oakad at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet:
--- Additional Comments From oakad at yahoo dot com 2005-06-27 13:43
---
I also have this bug with gcc-4.0.0 (powerpc-eabi on cygwin). It always happens
when msdata flag is present (eabi or sysv - same result). It is caused by the
attempt to initialize a global float/double variable
--- Additional Comments From oakad at yahoo dot com 2005-02-21 10:39
---
I would like to notice that the issue only arises with packed structs, which
are mostly found in places where exception handling is undesirable. Non-packed
structs are always aligned anyway.
--
http
--- Additional Comments From oakad at yahoo dot com 2005-02-20 21:16
---
Three points:
1. Handling of this case shall be consistent. When dealing with global
variables compiler emits byte by byte copy code. With automatic variables,
compiler emits single lfs/stfs.
2. I believe that
Version: 3.4.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: oakad at yahoo dot com
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i686-pc-cygwin
GC
27 matches
Mail list logo
