[Bug target/45637] Suspicious code for bit fields

[sebastian dot huber at embedded-brains dot de]

--- 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 be doing the largest available (up to the register size) 
> size.
> 
> This is different from the ARM ABI which says the opposite.
> 

Thank you very much for your comments.  I will investigate the PowerPC ABI
issue and contact the manufacturer.  Ironically they produced the ABI and these
register definitions.


-- 

sebastian dot huber at embedded-brains dot de changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637

[Bug target/45637] Suspicious code for bit fields

[sebastian dot huber at embedded-brains dot de]

--- 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 was not good.  If you expand foo [1] to foo [4] you still
have this behavior.

> 
> >In any case byte accesses should be used.
> Why, word access is just as fast (if not faster) than a byte access on PPC.
> 

Yes, but we have 'volatile struct type1 *varN;'.  For volatile fields we should
use accesses of the appropriate width.

The background is that a major hardware manufacturer provided structure
definitions like the above test case for register definitions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45637

[Bug c/45637] New: Suspicious code for bit fields

[sebastian dot huber at embedded-brains dot de]

Please have a look at this test case:

#include 

struct type1 {
union {
uint8_t reg;
struct {
uint8_t : 7;
uint8_t b : 1;
} bit;

} foo [1];
uint8_t bar;
};

volatile struct type1 *var1;

void f1(int i)
{
var1->foo [i].bit.b = 1;
var1->foo [0].bit.b = 1;
}

struct type2 {
union {
uint8_t reg;
struct {
uint8_t : 7;
uint8_t b : 1;
} bit;

} foo [1];
uint16_t bar;
};

volatile struct type2 *var2;

void f2(int i)
{
var2->foo [i].bit.b = 1;
var2->foo [0].bit.b = 1;
}

struct type3 {
union {
uint8_t reg;
struct {
uint8_t : 7;
uint8_t b : 1;
} bit;

} foo [1];
uint32_t bar;
};

volatile struct type3 *var3;

void f3(int i)
{
var3->foo [i].bit.b = 1;
var3->foo [0].bit.b = 1;
}

And the produced assembler file generated with (powerpc-rtems4.11-gcc -O2 -c
-mcpu=8540 -meabi -msdata -fno-common -save-temps):

.file   "bitfields.c"
.gnu_attribute 4, 2
.gnu_attribute 8, 1
.gnu_attribute 12, 1
.section".text"
.align 2
.globl f1
.type   f1, @function
f1:
lwz 9,v...@sda21(0)
lbzx 0,9,3
ori 0,0,1
stbx 0,9,3
lbz 0,0(9)
ori 0,0,1
stb 0,0(9)
blr
.size   f1, .-f1
.align 2
.globl f2
.type   f2, @function
f2:
lwz 9,v...@sda21(0)
lbzx 0,9,3
ori 0,0,1
stbx 0,9,3
lhz 0,0(9)
ori 0,0,256
sth 0,0(9)
blr
.size   f2, .-f2
.align 2
.globl f3
.type   f3, @function
f3:
lwz 9,v...@sda21(0)
li 11,1
lbzx 0,9,3
ori 0,0,1
stbx 0,9,3
lwz 0,0(9)
rlwimi 0,11,24,7,7
stw 0,0(9)
blr
.size   f3, .-f3
.globl var1
.globl var2
.globl var3
.section.sbss,"aw",@nobits
.align 2
.type   var1, @object
.size   var1, 4
var1:
.zero   4
.type   var2, @object
.size   var2, 4
var2:
.zero   4
.type   var3, @object
.size   var3, 4
var3:
.zero   4
.ident  "GCC: (GNU) 4.5.1 20100731 (RTEMS
gcc-4.5.1-5.suse11.2/newlib-1.18.0-20.suse11.2)"

Here you can see, that the access to the 'foo' field depends on

1. index is constant or variable, and
2. the 'bar' field type.

I think that both dependencies are wrong.  In any case byte accesses should be
used.


-- 
   Summary: Suspicious code for bit fields
   Product: gcc
   Version: 4.5.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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=45637

[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian dot huber at embedded-brains dot de]

--- 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 r3, #0
strbr3, [r4, #7]
add r4, r4, #7
ldr r3, [r0]
mov r1, r4
mov r2, #1
bl  doStreamReadBlock
add sp, sp, #8
ldrbr0, [r4]
@ sp needed for prologue
pop {r4}
pop {r1}
bx  r1
.size   readStream, .-readStream
.ident  "GCC: (GNU) 4.6.0 20100807 (experimental)"


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug libstdc++/43852] Embedded systems friendly libstdc++

[sebastian dot huber at embedded-brains dot de]

--- 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

[Bug libstdc++/43852] Embedded systems friendly libstdc++

[sebastian dot huber at embedded-brains dot de]

--- 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=20995&action=view)
Implementation, configure and documentation

Sorry, the config.h.in was missing.


-- 

sebastian dot huber at embedded-brains dot de changed:

   What|Removed |Added

  Attachment #20993|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852

[Bug libstdc++/43852] Embedded systems friendly libstdc++

[sebastian dot huber at embedded-brains dot de]

--- 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=20993&action=view)
Implementation, configure and documentation

Is libstdc++-v3/doc/xml/manual/configure.xml the main source for documentation?


-- 

sebastian dot huber at embedded-brains dot de changed:

   What|Removed |Added

  Attachment #20463|0   |1
is obsolete||
  Attachment #20471|0   |1
is obsolete||


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852

[Bug libstdc++/44647] std::nothrow and std::bad_alloc are coupled

[sebastian dot huber at embedded-brains dot de]

--- 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=20987&action=view)
Moves std::bad_alloc implementation into new file bad_alloc.cc

I don't know how to regenerate the Makefile.in.  A simple automake invocation
changes a lot in the Makefile.in.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647

[Bug libstdc++/44647] std::nothrow and std::bad_alloc are coupled

[sebastian dot huber at embedded-brains dot de]

--- 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,  is required to declare bad_alloc, so if
> bad_alloc was moved to a separate file, the parts of the library which need
> nothrow_t, new_handler and operator new etc. would still have to include 
> ,
> which would still have to include bad_alloc.
> 
> The way to achieve what you want is to put everything except bad_alloc in a
> separate file, and include that file instead of  when bad_alloc is not
> needed.
> 

There is nothing wrong with .  The problem is new_handler.cc.

Suppose you use

#include 

int *p = new (std::nothrow) int;

this will use the operator new implementation in new_opnt.cc.  This one uses
__new_handler which is now coupled with std::bad_alloc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647

[Bug libstdc++/44647] New: std::nothrow and std::bad_alloc are coupled

[sebastian dot huber at embedded-brains dot de]

The definitions of std::nothrow, __new_handler and std::bad_alloc are in the
same file.  This is bad since the std::bad_alloc definition pulls in the
exception support.  The std::bad_alloc definitions should be placed into a
separate file.


-- 
   Summary: std::nothrow and std::bad_alloc 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://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647

[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian dot huber at embedded-brains dot de]

--- 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 special case code to avoid the
evil consequences.  If it is a middle-end bug it should draw more attention by
the middle-end developers.  You cannot detect this bug through simple test
cases like a flow control or math problem.  With normal unit tests you will
likely not find this bug in your application.  You need at least two threads of
execution and you have to do certain things in between a wee bit of machine
instructions.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug rtl-optimization/38644] Optimization flag -O1 -fschedule-insns2 causes wrong code

[sebastian dot huber at embedded-brains dot de]

--- 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 on ARM/Thumb.  I am a bit irritated why this bug survived the 4.4.0
and 4.5.0 release.  In a multi threaded environment it is pretty hard to find
these kind of problems.  The time frame in which an interrupt can corrupt the
stack frame lies between two instructions.

Is -fno-schedule-insns2 a workaround for this problem?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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=20654&action=view)
Difference between bdbuf.s in revsions 130051 and 130052

This clearly shows how the frame usage sequence changed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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
r130056 BROKEN
r130052 BROKEN
r130051 OK
r130050 OK
r130048 OK
r130032 OK
r13 OK


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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
  Broken:
GCC 4.3.2 20080827
GCC 4.4.4 20100429
GCC 4.5.0 20100414
  Works:
GCC 4.2.4

Flags: -march=armv7 -mthumb -Os
  Works:
GCC 4.5.0 20100414

Flags: -march=armv5t -mthumb -O2
  Suspicious:
GCC 4.5.0 20100414

Suspicious means that the epilogue sequence is this:

.L577:
mov sp, r7
add sp, sp, #36
mov r0, r4
/*
 * Here we don't have a problem since r0 comes from r4
 * and not from the stack frame.  Is this always the case?
 */
@ sp needed for prologue
pop {r2, r3, r4, r5}
mov r8, r2
mov r9, r3
mov sl, r4
mov fp, r5
pop {r4, r5, r6, r7, pc}


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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=44091

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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, r5, r6, r7, pc}

You can see here that the mov/add and ldr instructions are in the right order.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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=20643&action=view)
Generated assembler file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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=20642&action=view)
Preprocessed source file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091

[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

--- 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=20641&action=view)
Log.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091

[Bug c/44091] New: [ARM/Thumb] Invalid stack frame usage at -Os

[sebastian dot huber at embedded-brains dot de]

GCC generates an invalid stack frame usage sequence in a function epilogue.

Function prologue with comments:

.align  2
.global rtems_bdbuf_read
.code   16
.thumb_func
.type   rtems_bdbuf_read, %function
rtems_bdbuf_read:
push{r4, r5, r6, r7, lr}
sub sp, sp, #60
add r7, sp, #8
/*
 * We have now reserved a stack frame in a two step process.  The
 * non-volatile register r7 will be use as an local variable anchor.
 */
str r3, [r7, #4]
mov r3, #0
str r3, [r7, #48]
str r3, [r7, #44]
str r3, [r7, #40]
mov r3, r7
add r3, r3, #44
str r3, [sp]
sub r3, r3, #4
str r3, [sp, #4]
add r3, r3, #8
bl  rtems_bdbuf_obtain_disk
str r0, [r7, #12]
cmp r0, #0
beq .LCB3661
b   .L520   @long jump
.LCB3661:

Function epilogue with comments:
.L520:
mov sp, r7
add sp, sp, #52
/*
 * Here we released the second part of our stack frame which contains
 * local variables.
 */
ldr r0, [r7, #12]
/*
 * Here we used the second part of our stack frame which contains local
 * variables.  We read a status variable from the stack frame that will
 * be returned now.  That means we use a part of the frame that we
 * already released.  In case an interrupt happens between these two
 * instructions (add and ldr) we may have a big problem.  These two
 * instructions are in the wrong order, the reverse order is correct.
 */
@ sp needed for prologue
pop {r4, r5, r6, r7, pc}

Attached files follow.


-- 
   Summary: [ARM/Thumb] Invalid stack frame usage at -Os
   Product: gcc
   Version: 4.4.4
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: 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: arm-rtems4.10


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091

[Bug libstdc++/43863] Unused recursive_init_error class defined with -fno-exceptions

[sebastian dot huber at embedded-brains dot de]

--- 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?  That mode would also change the ABI, but would have
> to be explicitly requested by users, and would be documented as changing the
> ABI.
> 
> Am I right in thinking that putting recursive_init_error in a separate file
> would only help when using static linking?
> 

Yes, it helps only if you use static linking.

>From my point of view moving this class implementation into a separate
compilation unit would help in case size really matters.  In these situations
you likely use static linking, because otherwise you need a runtime
infrastructure for dynamic linking which is also not that trivial.

If you suppose that users who care about size always choose the "quiet" mode
then this change is virtually unnecessary, but not optimal.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863

[Bug libstdc++/43863] C++ without exceptions is deficient

[sebastian dot huber at embedded-brains dot de]

--- 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 be?
> 

Sorry for the misunderstanding.  The build works fine, but the library is not
as small as it could be.  This is due to the inclusion of the unused
__gnu_cxx::recursive_init_error class.  For small target systems this is
dramatic.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863

[Bug libstdc++/43852] Embedded systems friendly libstdc++

[sebastian dot huber at embedded-brains dot de]

--- 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=20471&action=view)
Lets call it quiet.

Configure option may be --enable-quiet-cxx.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852

[Bug libstdc++/43852] Embedded systems friendly libstdc++

[sebastian dot huber at embedded-brains dot de]

--- 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

[Bug c++/43865] C++ in freestanding environment

[sebastian dot huber at embedded-brains dot de]

--- 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=20470&action=view)
Compile errors from above "$ make -i".


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43865

[Bug c++/43865] New: C++ in freestanding environment

[sebastian dot huber at embedded-brains dot de]

You can disable the requirement of a hosted environment for C++ and use the
freestanding environment via a configure option:

--disable-hosted-libstdcxx

This leads to build errors.  The configure command line was:

"$source_dir/configure" \
"--prefix=/opt/rtems-4.10" \
"--target=arm-rtems4.10" \
--verbose \
--enable-serial-configure \
--with-gnu-as \
--with-gnu-ld \
--with-newlib \
--disable-libstdcxx-pch \
--disable-nls \
--without-included-gettext \
--disable-win32-registry \
--enable-version-specific-runtime-libs \
--enable-threads \
--enable-newlib-io-c99-formats \
--enable-languages=c,c++ \
--disable-hosted-libstdcxx

The first observation is that the build looked successful (no errors from
make), but a

$ find -name libstdc++.a

reveals that no such library exists in the build tree.  Now lets try this

$ cd arm-rtems4.10/libstdc++-v3/src
$ make

and we have a compile error.  Output from

$ make -i

follows.


-- 
   Summary: C++ in freestanding environment
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  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

[Bug c++/43863] C++ without exceptions is deficient

[sebastian dot huber at embedded-brains dot de]

--- 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=20468&action=view)
Proposed changes.

An alternative is to define this class in a separate file.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43863

[Bug c++/43863] New: C++ without exceptions is deficient

[sebastian dot huber at embedded-brains dot de]

You can use the configure option

--enable-cxx-flags=-fno-exceptions

to create a C++ compiler without exceptions for the standard C++ library and
the built in new/delete operators.

In some cases you want this to save code space.  Unfortunately this goal cannot
be achieved.  In guard.cc the class __gnu_cxx::recursive_init_error is defined
which pulls in pure.cc via std::exception which depends on the IO libary.


-- 
   Summary: C++ without exceptions is deficient
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  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=43863

[Bug c++/43852] Embedded systems friendly libstdc++

[sebastian dot huber at embedded-brains dot de]

--- 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=20463&action=view)
Example how to implement it


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43852

[Bug c++/43852] New: Embedded systems friendly libstdc++

[sebastian dot huber at embedded-brains dot de]

You can configure the standard C++ library in two ways to reduce the code size
and dependencies on external libraries:

1. --enable-cxx-flags=-fno-exceptions

This does currently not work, due to an error in guard.cc which defines
recursive_init_error::~recursive_init_error() and this results in a dependency
on pure.cc and this one pulls in the IO library.

2. --disable-hosted-libstdcxx

This is also broken currently (try to build it).

Embedded targets may provide a hosted C environment, but in some cases it is
useless to provide output messages.  Also the IO library is quite huge.  Two
files in libstdc++/libsupc++ pull in the IO library: pure.cc and
eh_term_handler.cc (via vterminate.cc).  It would be nice to have a configure
option (like --enable-verbose-cxx) to enable or disable the output generation
in these files.


-- 
   Summary: Embedded systems friendly libstdc++
   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/bugzilla/show_bug.cgi?id=43852

[Bug target/41780] File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545

[sebastian dot huber at embedded-brains dot de]

--- 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

[Bug target/41780] File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545

[sebastian dot huber at embedded-brains dot de]

--- 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 |Added

 CC||rguenther at suse dot de


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780

[Bug target/41780] File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545

[sebastian dot huber at embedded-brains dot de]

--- 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 version 4.5.0 20091015 (experimental) (GCC)

Test program (test.c):

volatile unsigned a = 0;

int main()
{
a /= 123;

return 0;
}

arm-elf-gcc -mthumb test.c

/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/bin/ld:
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/thumb/libgcc.a(_dvmd_tls.o)(__div0):
warning: interworking not enabled.
  first occurrence:
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/thumb/libgcc.a(_udivsi3.o): arm call
to thumb
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/../../../../arm-elf/bin/ld:
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/thumb/libgcc.a(_udivsi3.o)(__udivsi3):
warning: interworking not enabled.
  first occurrence:
/opt/tool-chain-elf/lib/gcc/arm-elf/4.5.0/thumb/libgcc.a(_udivsi3.o): arm call
to thumb


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780

[Bug target/41780] File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545

[sebastian dot huber at embedded-brains dot de]

--- 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=18852&action=view)
Fix proposal

This works at least for me.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780

[Bug target/41780] New: File "gcc/config/arm/lib1funcs.asm" broken for THUMB version 1 since r150545

[sebastian dot huber at embedded-brains dot de]

I suppose the file "gcc/config/arm/lib1funcs.asm" does not work when compiled
for THUMB version 1 with an architecture other than __ARM_ARCH_6M__ since
r150545.  I got a link error:

/opt/rtems-4.10-gcc/bin/../lib/gcc/arm-rtems4.10/4.5.0/../../../../arm-rtems4.10/bin/ld:
/opt/rtems-4.10-gcc/bin/../lib/gcc/arm-rtems4.10/4.5.0/thumb/soft/libgcc.a(_dvmd_tls.o)(__div0):
warning: interworking not enabled.
  first occurrence:
/opt/rtems-4.10-gcc/bin/../lib/gcc/arm-rtems4.10/4.5.0/thumb/soft/libgcc.a(_udivsi3.o):
arm call to thumb


-- 
   Summary: File "gcc/config/arm/lib1funcs.asm" broken for THUMB
version 1 since r150545
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC target triplet: arm-rtems4.10


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41780

[Bug debug/40521] [4.4/4.5 Regression] -g causes GCC to generate .eh_frame

[sebastian dot huber at embedded-brains dot de]

--- 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 true? In 4.4.2 20091008 the problem is
still present.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40521

[Bug target/39784] Provide more machine builtin defines

[sebastian dot huber at embedded-brains dot de]

--- Comment #1 from sebastian dot huber at embedded-brains dot de  
2009-04-16 10:02 ---
Created an attachment (id=17648)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17648&action=view)
Proposal for trunk


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39784

[Bug target/39784] New: Provide more machine builtin defines

[sebastian dot huber at embedded-brains dot de]

Hi,

the file gcc/config/m68k/m68k-devices.def contains a nice overview of 68000 and
ColdFire CPU variants and there specific capabilities.  Some of these are
exported via builtin defines like __mcffpu__.  It would be useful if such
defines are also available for the other features of the ColdFire like the EMAC
etc.


-- 
   Summary: Provide more machine builtin defines
   Product: gcc
   Version: 4.5.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
 GCC build triplet: *
  GCC host triplet: *
GCC target triplet: m68k-*


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39784