: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: powerpc-rtems4.11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:43 ---
(In reply to comment #1)
1. index is constant or variable, and
Yes that is correct.
2. the 'bar' field type.
The alignment of the access is different in those cases.
Sorry, the test case
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-09-10 15:59 ---
(In reply to comment #3)
For volatile fields we should use accesses of the appropriate width.
The PowerPC ABI has specific rules for accessing volatile bitfields and IIRC
it
says they should
--- Comment #18 from sebastian dot huber at embedded-brains dot de
2010-08-12 08:19 ---
This bug is still present in GCC 4.6.0 20100807 (arm-eabi-gcc -O1
-fschedule-insns2 -mthumb):
readStream:
push{r4, lr}
sub sp, sp, #8
mov r4, sp
mov
--- Comment #7 from sebastian dot huber at embedded-brains dot de
2010-06-24 09:41 ---
Created an attachment (id=20993)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20993action=view)
Implementation, configure and documentation
Is libstdc++-v3/doc/xml/manual/configure.xml
--- Comment #9 from sebastian dot huber at embedded-brains dot de
2010-06-24 10:09 ---
Created an attachment (id=20995)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20995action=view)
Implementation, configure and documentation
Sorry, the config.h.in was missing.
--
sebastian
--- Comment #12 from sebastian dot huber at embedded-brains dot de
2010-06-24 12:49 ---
(In reply to comment #11)
[...]
I'll get this and Bug 44647 done for 4.6.0
Please have a look at Bug 43863 also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
are coupled
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-06-23 15:02 ---
(In reply to comment #1)
(In reply to comment #0)
The std::bad_alloc definitions should be placed into a
separate file.
IIUC that wouldn't work, new is required to declare bad_alloc, so
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-06-23 15:20 ---
Created an attachment (id=20987)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20987action=view)
Moves std::bad_alloc implementation into new file bad_alloc.cc
I don't know how to regenerate
--- Comment #17 from sebastian dot huber at embedded-brains dot de
2010-06-10 07:13 ---
Thank you for your investigations. A special case fix is better than nothing.
I am not a GCC expert but it seems that this kind of bug appears quite
regularly on different platforms and all use
--- Comment #14 from sebastian dot huber at embedded-brains dot de
2010-05-17 09:04 ---
This bug is present since r130052 which is related to:
http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01814.html
If this is a generic bug or not is quite irrelevant since this is a very
serious bug
--- Comment #10 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:42 ---
Binary search through trunk revisions yield:
r159321 BROKEN
r15 BROKEN
r14 BROKEN
r135000 BROKEN
r132500 BROKEN
r131024 BROKEN
r130512 BROKEN
r130256 BROKEN
r130128 BROKEN
r130064 BROKEN
--- Comment #11 from sebastian dot huber at embedded-brains dot de
2010-05-13 09:50 ---
Created an attachment (id=20654)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20654action=view)
Difference between bdbuf.s in revsions 130051 and 130052
This clearly shows how the frame usage
dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:21 ---
Created an attachment (id=20641)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20641action=view)
Log.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:21 ---
Created an attachment (id=20642)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20642action=view)
Preprocessed source file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2010-05-12 07:22 ---
Created an attachment (id=20643)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20643action=view)
Generated assembler file.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-05-12 09:40 ---
GCC 4.5.0 20100414 has this problem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2010-05-12 10:03 ---
GCC 4.2.4 does not have this problem.
Function epilogue:
.L672:
ldr r0, [r7, #4]
mov sp, r7
add sp, sp, #52
@ sp needed for prologue
pop {r4
--- Comment #6 from sebastian dot huber at embedded-brains dot de
2010-05-12 11:06 ---
If you use GCC 4.5.0 20100414 with '-march=armv7' '-mthumb' '-Os' the function
epilogue is also correct. It seems that this is a Thumb 1 problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #7 from sebastian dot huber at embedded-brains dot de
2010-05-12 11:13 ---
GCC 4.3.2 20080827 has this problem too.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
--- Comment #8 from sebastian dot huber at embedded-brains dot de
2010-05-12 12:03 ---
A summary follows. Broken means bdbuf.i generates an invalid stack frame usage
sequence in a function epilogue. Works means that the corresponding area is
valid.
Flags: -march=armv5t -mthumb -Os
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-23 06:55 ---
Created an attachment (id=20468)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20468action=view)
Proposed changes.
An alternative is to define this class in a separate file.
--
http
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43865
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:14 ---
Created an attachment (id=20470)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20470action=view)
Compile errors from above $ make -i.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43865
--- Comment #4 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:16 ---
Bug report for 1. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863.
Bug report for 2. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43865
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:20 ---
Created an attachment (id=20471)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20471action=view)
Lets call it quiet.
Configure option may be --enable-quiet-cxx.
--
http://gcc.gnu.org
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2010-04-23 09:28 ---
(In reply to comment #2)
In Bug 43852 I thought you meant building with -fno-exceptions fails, but it
works for me ... do you just mean the resulting library is not as small as it
could
--- Comment #6 from sebastian dot huber at embedded-brains dot de
2010-04-23 10:59 ---
(In reply to comment #5)
Simply removing this class now would break the ABI, which is not acceptable.
If Bug 43852 was resolved by adding a quiet mode, would that make this
enhancement unnecessary
++
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
http://gcc.gnu.org
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2010-04-22 14:25 ---
Created an attachment (id=20463)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20463action=view)
Example how to implement it
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852
--- Comment #3 from sebastian dot huber at embedded-brains dot de
2009-12-04 12:15 ---
The problem is still present with:
arm-elf-gcc (GCC) 4.5.0 20091203 (experimental)
--
sebastian dot huber at embedded-brains dot de changed:
What|Removed
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2009-12-04 13:31 ---
This one works:
arm-elf-gcc (GCC) 4.4.3 20091201 (prerelease)
I think that r150545 introduced the problem.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
--- Comment #2 from sebastian dot huber at embedded-brains dot de
2009-10-26 10:22 ---
Target: arm-elf
Configured with: /home/sh/gcc-4.5-20091015/configure
--prefix=/opt/tool-chain-elf --target=arm-elf --verbose --with-gnu-as
--with-gnu-ld --enable-languages=c
Thread model: single
gcc
huber at embedded-brains dot de
GCC target triplet: arm-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780
--- Comment #1 from sebastian dot huber at embedded-brains dot de
2009-10-21 09:30 ---
Created an attachment (id=18852)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18852action=view)
Fix proposal
This works at least for me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #15 from sebastian dot huber at embedded-brains dot de
2009-10-12 11:36 ---
(In reply to comment #13)
Thanks for clarifying the !eh_personality_libfunc requirement. I'll do some
experiments to see which solution works best in 4.4.
Is the target milestone 4.4.2 still
39 matches
Mail list logo
