[Bug c++/52036] C++11 allows template parameters to have internal linkage
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52036 Alexander Dubov oakad at yahoo dot com changed: What|Removed |Added CC||oakad at yahoo dot com --- Comment #10 from Alexander Dubov oakad at yahoo dot com --- Still an issue on GCC-4.9.2 (-std=c++11, c++14, gnu++1y). clang-3.4 compiles this and similar cases just fine.
[Bug c++/61814] [c++1y] cannot use decltype on captured arg-pack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61814
Alexander Dubov oakad at yahoo dot com changed:
What|Removed |Added
CC||oakad at yahoo dot com
--- Comment #1 from Alexander Dubov oakad at yahoo dot com ---
This problem still happens on 4.9.1.
For example, this example works:
int main(int argc, char **argv)
{
int a{5};
float z(0.5);
[a](float z_) - void {
decltype(a) b = a;
}(z);
return 0;
}
But this basic modification fails to compile (g++-4.9.1 -std=gnu++14):
int main(int argc, char **argv)
{
int a{5};
float z(0.5);
[a](auto z_) - void {
decltype(a) b = a;
}(z);
return 0;
}
[Bug c++/53137] [4.7/4.8 Regression] g++ segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53137
Alexander Dubov oakad at yahoo dot com changed:
What|Removed |Added
CC||oakad at yahoo dot com
--- Comment #14 from Alexander Dubov oakad at yahoo dot com 2012-11-29
15:31:46 UTC ---
Because this bug is so annoying, I thought it may be helpful if I add an
another example:
(clang-3.1 works in all cases)
template typename value_type
struct test {
test(std::initializer_listvalue_type l)
{
insert(l.begin(), l.end());
}
template typename input_iter_t
void insert(input_iter_t first, input_iter_t last)
{
std::for_each(
first, last, [this](value_type const v) - void {
// works on both gcc-4.6.3 and gcc-4.7.2
this-insert(v);
// won't compile on 4.6.3,
// ICE at tree-ssa-operands.c:1035 on 4.7.2
insert(v);
}
);
}
void insert(value_type const v)
{
std::cout v std::endl;
}
};
[Bug libstdc++/44963] [DR 1334] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode
--- 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 vstrings for added simplicity and it doesn't seem fully thread safe to me in its current form. Hopefully, I'll have some time soon to give a try at reimplementing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44963
[Bug libstdc++/44963] New: Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode
The example program below will exhibit the problem when compiled with
-std=c++0x or gnu++0x flag. The problem is particularly unfortunate, as rope is
designed for use with back_inserter style constructs.
Example program:
#include iostream
#include ext/rope
using namespace std;
int main(int argc, char **argv)
{
__gnu_cxx::crope line(test);
auto ii(back_inserter(line));
*ii++ = 'm';
*ii++ = 'e';
cout line endl;
return 0;
}
Compilation error message:
testrope1.cpp: In function #8216;int main(int, char**)#8217;:
testrope1.cpp:11: error: ambiguous overload for #8216;operator=#8217; in
#8216;ii.std::back_insert_iterator_Container::operator++ [with _Container =
__gnu_cxx::ropechar, std::allocatorchar
](0).std::back_insert_iterator_Container::operator* [with _Container =
__gnu_cxx::ropechar, std::allocatorchar ]() = 'm'#8217;
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_iterator.h:415:
note: candidates are: std::back_insert_iterator_Container
std::back_insert_iterator_Container::operator=(typename
_Container::const_reference) [with _Container = __gnu_cxx::ropechar,
std::allocatorchar ]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_iterator.h:423:
note: std::back_insert_iterator_Container
std::back_insert_iterator_Container::operator=(typename
_Container::value_type) [with _Container = __gnu_cxx::ropechar,
std::allocatorchar ]
testrope1.cpp:12: error: ambiguous overload for #8216;operator=#8217; in
#8216;ii.std::back_insert_iterator_Container::operator++ [with _Container =
__gnu_cxx::ropechar, std::allocatorchar
](0).std::back_insert_iterator_Container::operator* [with _Container =
__gnu_cxx::ropechar, std::allocatorchar ]() = 'e'#8217;
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_iterator.h:415:
note: candidates are: std::back_insert_iterator_Container
std::back_insert_iterator_Container::operator=(typename
_Container::const_reference) [with _Container = __gnu_cxx::ropechar,
std::allocatorchar ]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_iterator.h:423:
note: std::back_insert_iterator_Container
std::back_insert_iterator_Container::operator=(typename
_Container::value_type) [with _Container = __gnu_cxx::ropechar,
std::allocatorchar ]
--
Summary: Ambiguous function overload using __gnu_cxx::crope with
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
[Bug libstdc++/44963] [DR 1334] Ambiguous function overload using __gnu_cxx::crope with std::back_inserter in c++0x mode
--- 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 rope, so external implementation should be preferred? And if such is the case, shouldn't rope class be marked as deprecated, so that similar functionality class can be proposed for addition elsewhere, in boost, for instance? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44963
[Bug libstdc++/44708] New: Enabling -std=c++0x results in ambiguous function overload in ext/algorithm header
The example program below will exhibit the problem when compiled with
-std=c++0x or gnu++0x flag. The fix appears to be trivial, but requires a
change to ext/algorithm header.
Example program:
#include iostream
#include ext/rope
using namespace std;
int main(int argc, char **argv)
{
__gnu_cxx::crope line(test-test-test);
cout line.c_str() endl;
return 0;
}
Compilation error message:
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/ropeimpl.h:48,
from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/rope:2956,
from testrope.cpp:2:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/algorithm: In
function #8216;std::pair_InputIter, _ForwardIter
__gnu_cxx::copy_n(_InputIterator, _Size, _OutputIterator) [with _InputIterator
= char*, _Size = long unsigned int, _OutputIterator = char*]#8217;:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/ropeimpl.h:1090:
instantiated from #8216;static _CharT* __gnu_cxx::rope_CharT,
_Alloc::_S_flatten(__gnu_cxx::_Rope_RopeRep_CharT, _Alloc*, _CharT*) [with
_CharT = char, _Alloc = std::allocatorchar]#8217;
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/ropeimpl.h:1621:
instantiated from #8216;const _CharT* __gnu_cxx::rope_CharT, _Alloc::c_str()
const [with _CharT = char, _Alloc = std::allocatorchar]#8217;
testrope.cpp:10: instantiated from here
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/algorithm:127: error:
call of overloaded #8216;__copy_n(char*, long unsigned int, char*,
std::random_access_iterator_tag)#8217; is ambiguous
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/algorithm:78: note:
candidates are: std::pair_InputIter, _ForwardIter
__gnu_cxx::__copy_n(_InputIterator, _Size, _OutputIterator,
std::input_iterator_tag) [with _InputIterator = char*, _Size = long unsigned
int, _OutputIterator = char*]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/ext/algorithm:93: note:
std::pair_InputIter, _ForwardIter
__gnu_cxx::__copy_n(_RAIterator, _Size, _OutputIterator,
std::random_access_iterator_tag) [with _RAIterator = char*, _Size = long
unsigned int, _OutputIterator = char*]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_algo.h:1003:
note: _OutputIterator std::__copy_n(_RandomAccessIterator,
_Size, _OutputIterator, std::random_access_iterator_tag) [with
_RandomAccessIterator = char*, _Size = long unsigned int, _OutputIterator =
char*]
/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.2/include/g++-v4/bits/stl_algo.h:988:
note: _OutputIterator std::__copy_n(_InputIterator, _Size,
_OutputIterator, std::input_iterator_tag) [with _InputIterator = char*, _Size =
long unsigned int, _OutputIterator = char*]
--
Summary: Enabling -std=c++0x results in ambiguous function
overload in ext/algorithm header
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=44708
[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target
--- 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
[Bug driver/42007] Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target
--- 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 existing and all future chips of this type provide the necessary functionality. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
[Bug driver/42007] New: Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target
The problem applied both to building the compiler proper, as well as application on/for the given host triplet. Most (all?) Freescale SPE enabled cores these days are dual-precision capable e500v2, and this is the case for couple of years now. However, when building the compiler for the triplet in question, gcc internal libraries are only built with single precision SPE ops emitted. Making gcc to build these libraries with proper DP support requires setting of the *_FOR_TARGET variables during the build to contain -mfloat-gprs=double. Same applies for normal application compiles. Single precision FP instructions are used by default, unless the flag is set. It seems beneficial and probably not harmful (e500v1 was never too popular and rather short-lived) to make -mfloat-gprs=double a default behavior. -- Summary: Make -mfloat-gprs=double the default when compiling for powerpc-linux-gnuspe target Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: oakad at yahoo dot com GCC target triplet: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42007
[Bug middle-end/37107] Incorrect code generated after function inlining
--- 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 effect on issue. Different optimization level (-O2) still generates problematic code. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
[Bug middle-end/37107] Incorrect code generated after function inlining
--- 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=16103action=view) Preprocessed cfi_flash.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
[Bug middle-end/37107] Incorrect code generated after function inlining
--- 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=16104action=view) Full assembler output of cfi_flash.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
[Bug c/37107] New: Incorrect code generated after function inlining
In the attached file (cfi_flash.c), the function flash_detect_cfi is inlined into the function flash_get_size. flash_detect_cfi accepts (arg 2) a pointer to structure defined on stack in flash_get_size. Upon completion, some fields from the structure in question are referenced (lines 1731 - 1734). The generated code for the function (flash_get_size.asm, lines 63-70) does none of these, introducing a nasty runtime bug. Build parameters: powerpc-linux-gnuspe-gcc -g -Os -fPIC -ffixed-r14 -meabi -D__KERNEL__ -DTEXT_BASE=0xfffc -I/root/u-boot-1.3.3/include -fno-builtin -ffreestanding -nostdinc -isystem /usr/local/powerpc/lib/gcc/powerpc-linux-gnuspe/4.3.1/include -pipe -DCONFIG_PPC -D__powerpc__ -DCONFIG_MPC85xx -DCONFIG_E500 -ffixed-r2 -Wa,-me500 -msoft-float -mno-string -mno-spe -DCONFIG_E500=1 -DCONFIG_MPC85xx=1 -DCONFIG_MPC8548=1 -Wall -Wstrict-prototypes -c -o cfi_flash.o cfi_flash.c -- Summary: Incorrect code generated after function inlining Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c 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: powerpc-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
[Bug c/37107] Incorrect code generated after function inlining
--- 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=16063action=view) Original source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
[Bug c/37107] Incorrect code generated after function inlining
--- 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=16064action=view) Assembly of the problematic function -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37107
[Bug target/20102] Incorrect floating point code generated when assigning to packed structure
--- 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 structs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20102
[Bug c/23444] New: Volatile register access incorrectly optimized
For a code:
//
void board_init_f (ulong bootflag)
{
register volatile gd_t *gd asm (r29);
bd_t *bd;
ulong len, addr, addr_sp;
gd_t *id;
init_fnc_t **init_fnc_ptr;
gd=0xff55ff55;
__asm__ __volatile__(or 29, 29, 29);
memset ((void *) gd, 0, sizeof (gd_t));
//
the following assembly is generated:
//
fff88ec8 board_init_f:
fff88ec8: 94 21 ff d0 stwur1,-48(r1)
fff88ecc: 7c 08 02 a6 mflrr0
fff88ed0: be e1 00 0c stmwr23,12(r1)
fff88ed4: 90 01 00 34 stw r0,52(r1)
fff88ed8: 42 9f 00 05 bcl-20,4*cr7+so,fff88edcboard_init_f+0x14
fff88edc: 7f c8 02 a6 mflrr30
fff88ee0: 80 1e ff e8 lwz r0,-24(r30)
fff88ee4: 7f c0 f2 14 add r30,r0,r30
fff88ee8: 7c 7f 1b 78 mr r31,r3
/* problematic code here */
fff88eec: 7f bd eb 78 mr r29,r29
fff88ef0: 3c 60 ff 55 lis r3,-171
fff88ef4: 60 63 ff 55 ori r3,r3,65365
fff88ef8: 38 80 00 00 li r4,0
fff88efc: 38 a0 00 30 li r5,48
fff88f00: 4b ff f9 19 bl fff88818 memset
.
//
It is seen from here, that r29 does not get initialized, despite volatile
specifier for variable gd (gcc is called with -ffixed-r29). This bug is
present in gcc-4.0.0 too.
For reference: code generated by gcc-3.4.4:
//
fff88cb8 board_init_f:
fff88cb8: 94 21 ff d8 stwur1,-40(r1)
fff88cbc: 7c 08 02 a6 mflrr0
fff88cc0: bf 01 00 08 stmwr24,8(r1)
fff88cc4: 90 01 00 2c stw r0,44(r1)
fff88cc8: 42 9f 00 05 bcl-20,4*cr7+so,fff88cccboard_init_f+0x14
fff88ccc: 7f c8 02 a6 mflrr30
fff88cd0: 80 1e ff e8 lwz r0,-24(r30)
fff88cd4: 7f c0 f2 14 add r30,r0,r30
fff88cd8: 7c 78 1b 78 mr r24,r3
/* correct code */
fff88cdc: 3f a0 ff 55 lis r29,-171
fff88ce0: 63 bd ff 55 ori r29,r29,65365
fff88ce4: 7f bd eb 78 mr r29,r29
fff88ce8: 7f a3 eb 78 mr r3,r29
fff88cec: 38 80 00 00 li r4,0
fff88cf0: 38 a0 00 30 li r5,48
fff88cf4: 4b ff f8 ed bl fff885e0 memset
//--
--
Summary: Volatile register access incorrectly optimized
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: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: powerpc-eabi-gcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23444
[Bug c/23444] Volatile register access incorrectly optimized
-- What|Removed |Added GCC target triplet|powerpc-eabi-gcc|powerpc-eabi-unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23444
[Bug c/23444] Volatile register access incorrectly optimized
-- What|Removed |Added GCC target triplet|powerpc-eabi-unknown|powerpc-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23444
[Bug rtl-optimization/23444] Volatile register access incorrectly optimized
--- 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;
gd_t *id;
init_fnc_t **init_fnc_ptr;
# 360 board.c
gd=0xff55ff55;
__asm__ __volatile__(or 29, 29, 29);
memset ((void *) gd, 0, sizeof (gd_t));
.
//
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23444
[Bug rtl-optimization/23444] Volatile register access incorrectly optimized
--- 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];
int
main()
{
register volatile char* cptr asm (r29);
cptr=str1;
asm volatile (or 29,29,29); //optimization barrier, supposedly
memcpy(str2,cptr,10);
return (int)cptr; //just for fun
}
//---
Compile with -ffixed-r29.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23444
[Bug rtl-optimization/23444] Volatile register access incorrectly optimized
--- 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 somewhere in the gcc info? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23444
[Bug target/21571] ICE in rs6000.c with -msdata=default.
--- 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 with a constant, like this:
//
float a;
void foo() { a=0; } - gcc crashes
//
I worked round this problem for now with a code:
//
float f_zero=0; //putting const float here will make gcc crash
float a;
void foo() { a=f_zero; }
//
I consider this a severe bug. It does not depends on optimization level or on
other options as far as I checked (only on msdata).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21571
[Bug target/20102] Incorrect floating point code generated when assigning to packed structure
--- 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=20102
[Bug c/20102] New: Incorrect floating point code generated when assigning to packed structure
gcc generates incorrect code when assigning to stack residing struct
bearing packed attribute. Correct code is generated when assigning to global
struct of the same type.
Example:
//-
typedef struct
{
char x1;
char x2;
char x3;
float v1;
float v2;
float v3;
char x4;
char x5;
} __attribute__((packed,aligned(1))) ptype1;
ptype1 g;
void foo()
{
//
ptype1 p;
//
p.v1=g.v1;
p.v2=p.v3;
//
}
//-
When compiled with:
powerpc-eabi-gcc -std=gnu99 -mcpu=505 -fsingle-precision-constant -mmultiple -
mstring -fno-common -ffast-math -O3 -g3 -memb -msdata=eabi -G 26624
the following incorrect code is generated:
//---
lfs f3, -31984(r13) //g.v1
lfs f2, 395(r1) //p.v3 - incorrect misaligned load (throws exception)
stfs f3, 387(r1) //p.v1 - incorrect misaligned store (throws exception)
stfs f2, 391(r1) //p.v2 - incorrect misaligned store (throws exception)
//---
Desired behavior: at least error message; at most - consistent, byte by byte
load/store.
--
Summary: Incorrect floating point code generated when assigning
to packed structure
Product: gcc
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
GCC host triplet: i686-pc-cygwin
GCC target triplet: powerpc-eabi-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20102
[Bug target/20102] Incorrect floating point code generated when assigning to packed structure
--- 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 PPC architecture explicitly forbids unaligned floating loads and stores. 3. The whole point in my code sniplet is to accelerate some communication protocol. Exception handler invocation is obviously out of question. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20102
