[Bug c++/28345] New: static const "class" initialisation causes core dump
A declaration
static const Bad constBad = {
...
}
causes a core dump, fixed by removing the "const" keyword.
Example source file "b.cxx"
#include
class Base {
public:
};
class Derived : public Base {
public:
int a, b, c, d;
};
class Bad {
public:
int Base::*mpField0;
int Base::*mpField1;
};
class Good {
public:
int Derived::*mpField0;
int Derived::*mpField1;
};
int main( int argc, char *argv[] )
{
static const Goodgood = {
(int (Base::*)) &Derived::b,
(int (Base::*)) &Derived::c
};
printf( "good.mpField0 = %d\n", good.mpField0 );
printf( "good.mpField1 = %d\n", good.mpField1 );
static Bad bad = {
(int (Base::*)) &Derived::b,
(int (Base::*)) &Derived::c
};
printf( "bad.mpField0 = %d\n", bad.mpField0 );
printf( "bad.mpField1 = %d\n", bad.mpField1 );
// This initialisation generates a CORE dump!
static const Bad constBad = {
(int (Base::*)) &Derived::b,
(int (Base::*)) &Derived::c
};
printf( "constBad.mpField0 = %d\n", constBad.mpField0 );
printf( "constBad.mpField1 = %d\n", constBad.mpField1 );
return 0;
}
g++ -v -save-temps -o b b.cxx
===
Reading specs from /opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/specs
Configured with: /homes/spelis/dopt/gnu/gcc-3.4.1/configure
--prefix=/opt/s2tools/native
Thread model: posix
gcc version 3.4.1
/opt/s2tools/native/libexec/gcc/i686-pc-linux-gnu/3.4.1/cc1plus -E -quiet -v
-D_GNU_SOURCE b.cxx -mtune=pentiumpro -o b.ii
ignoring nonexistent directory
"/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../include/c++/3.4.1
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../include/c++/3.4.1/i686-pc-linux-gnu
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../include/c++/3.4.1/backward
/usr/local/include
/opt/s2tools/native/include
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/include
/usr/include
End of search list.
/opt/s2tools/native/libexec/gcc/i686-pc-linux-gnu/3.4.1/cc1plus -fpreprocessed
b.ii -quiet -dumpbase b.cxx -mtune=pentiumpro -auxbase b -version -o b.s
GNU C++ version 3.4.1 (i686-pc-linux-gnu)
compiled by GNU C version 3.2.3 20030502 (Red Hat Linux 3.2.3-49).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../i686-pc-linux-gnu/bin/as
-V -Qy -o b.o b.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1
/opt/s2tools/native/libexec/gcc/i686-pc-linux-gnu/3.4.1/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o b
/usr/lib/crt1.o /usr/lib/crti.o
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/crtbegin.o
-L/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1
-L/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../../../i686-pc-linux-gnu/lib
-L/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/../../.. b.o -lstdc++ -lm
-lgcc_s -lgcc -lc -lgcc_s -lgcc
/opt/s2tools/native/lib/gcc/i686-pc-linux-gnu/3.4.1/crtend.o /usr/lib/crtn.o
--
Summary: static const "class" initialisation causes core dump
Product: gcc
Version: 3.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28345
[Bug c++/38818] New: C++ bitfield static initialisation problem
The following program seems to show a
compiler bug on x86 using 4.3.2 compilers
The correct output should be;
giChannelTiming0.Setup 0xff
giChannelTiming0.Recover 0xff00
which occurs only when no optimiser or -O is used.
When -O2 or greater is used the mask's are incorrectly
computed and print as 0.
It is known also not to work on 4.1.2 compilers.
It works perfectly with all optimisation levels on 3.2.3
compilers.
/* */
#include
#include
typedef struct giChannelTiming {
#if BYTE_ORDER == BIG_ENDIAN
/* Bits 24..31 */ unsigned Recover : 8 ;
/* Bits 16..23 */ unsigned Hold : 8 ;
/* Bits 8..15 */ unsigned Pulse : 8 ;
/* Bits 0.. 7 */ unsigned Setup : 8 ;
#else
/* Bits 0.. 7 */ unsigned Setup : 8 ;
/* Bits 8..15 */ unsigned Pulse : 8 ;
/* Bits 16..23 */ unsigned Hold : 8 ;
/* Bits 24..31 */ unsigned Recover : 8 ;
#endif
giChannelTiming(long l = 0) { *(unsigned long *)this=l; }
operator unsigned long *(void) { return((unsigned long *)this) ; }
operator unsigned long (void) { return(*(unsigned long *)this) ; }
} t_giChannelTiming ;
#define FIO_LOCATED(n) 0
#define ID_GEN_giChannelTiming0Setup 0
#define ID_GEN_giChannelTiming0Recover 0
#define GI_REG_F(field,reg) { #reg "." #field, ID_GEN_##reg##field, \
{ FIO_LOCATED(reg), (gr.reg=0, gr.reg.field =~0, (unsigned long)gr.reg)}}
struct gen_registers {
t_giChannelTiming giChannelTiming0;
} ;
static gen_registers gr ;
struct regs {
const char *name ;
int id ;
struct masks {
int locn ;
unsigned long mask ;
} s ;
} r[] = {
GI_REG_F(Setup, giChannelTiming0),
GI_REG_F(Recover, giChannelTiming0)
} ;
main() {
printf("%s 0x%lx\n", r[0].name, r[0].s.mask);
printf("%s 0x%lx\n", r[1].name, r[1].s.mask);
}
/* - */
--
Summary: C++ bitfield static initialisation problem
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
GCC build triplet: i386-redhat-linux
GCC host triplet: i386-redhat-linux
GCC target triplet: i386-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38818
[Bug c++/38818] C++ bitfield static initialisation problem
--- Comment #2 from john dot spelis at 3dlabs dot com 2009-01-12 22:16 --- Subject: Re: C++ bitfield static initialisation problem Thank you. (I'm suitably humbled). Cheers On 12 Jan 2009, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2009-01-12 21:37 > --- > *(unsigned long *)this=l; > > You are violating C/C++ aliasing rules which invokes undefined behavior as you > are accessing a giChannelTiming as a unsigned long. > > Either use -fno-strict-aliasing or memcpy or unions or the attribute may_alias > to fix your code > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38818 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38818
[Bug c/37609] New: Pointer arithmetic yields strange result
An expression using ptr arithmetic yields an unusual result
unless a cast is applied;
The problematic expression;
MaxTimings = ((EDIDDetailed *) &pExt->checksum) - pDTD;
works only when cast as;
MaxTimings = (((uintptr_t) &pExt->checksum) - ((uintptr_t)
pDTD))/sizeof(*pDTD);
This occurs on compilers back to 3.0.3 when testing on a x86. It's also present
in a cross compiler built using 4.3.0 source
Works on a Sun/Solaris compiler.
A test program is attached
--
Summary: Pointer arithmetic yields strange result
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug c/37609] Pointer arithmetic yields strange result
--- Comment #1 from john dot spelis at 3dlabs dot com 2008-09-21 16:01 --- Created an attachment (id=16372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16372&action=view) A standalone program which illustrates the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug c/37609] Pointer arithmetic yields strange result
--- Comment #5 from john dot spelis at 3dlabs dot com 2008-09-22 20:40 --- Subject: Re: Pointer arithmetic yields strange result Apologies; never realised that pointer arithmetic was defined in that fashion (i.e. must always be a multiple of the object size). Sorry to have bothered you. Best Regards. On 22 Sep 2008, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #4 from pinskia at gcc dot gnu dot org 2008-09-22 19:54 > --- > This is invalid code as the difference between ((EDIDDetailed *) > &pExt->checksum) - pDTD is 88 which is not a multiple of 18. This happens the > same way on powerpc. > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|NEW |RESOLVED > Component|target |c > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37609
[Bug c++/38027] New: bitfields and -O2 or greater
The following program when compiled with gcc 4.1.2 works but with 4.3.0 it
produces incorrect output at optimisation level O2 or greater.
/ * -- */
#include
#include
using namespace std;
typedef unsigned int uint32_t;
typedef unsigned short uint16_t;
typedef unsigned char uint8_t;
class CColourARGB;
class CColourARGB
{
public :
union
{
struct
{
uint32_t mBlue : 8;
uint32_t mGreen : 8;
uint32_t mRed : 8;
uint32_t mAlpha : 8;
} mBits;
uint32_t mWord;
} mCol;
CColourARGB(const CColourARGB &rhs);
};
class CColourARGB
{
public :
union
{
struct
{
uint16_t mBlue : 4;
uint16_t mGreen : 4;
uint16_t mRed : 4;
uint16_t mAlpha : 4;
} mBits;
uint16_t mWord;
} mCol;
public :
/// CColourARGB constructor
CColourARGB(const uint8_t &alpha, const uint8_t &red, const uint8_t
&green, const uint8_t &blue)
{ mCol.mBits.mAlpha = alpha; mCol.mBits.mRed = red; mCol.mBits.mGreen =
green; mCol.mBits.mBlue = blue; }
};
__inline CColourARGB::CColourARGB(const CColourARGB &rhs)
{
mCol.mBits.mRed = ((rhs.mCol.mBits.mRed << 4) & 0xF0) |
rhs.mCol.mBits.mRed;
mCol.mBits.mGreen = ((rhs.mCol.mBits.mGreen << 4) & 0xF0) |
rhs.mCol.mBits.mGreen;
mCol.mBits.mBlue = ((rhs.mCol.mBits.mBlue << 4) & 0xF0) |
rhs.mCol.mBits.mBlue;
mCol.mBits.mAlpha = ((rhs.mCol.mBits.mAlpha << 4) & 0xF0) |
rhs.mCol.mBits.mAlpha;
printf("Constructing CColourARGB %x from CColourARGB %x\n",
mCol.mWord, rhs.mCol.mWord);
}
void broken()
{
for (uint8_t y = 0; y < 4; ++y) {
for (uint8_t x = 0; x < 4; ++x) {
CColourARGB c4(0xF, x, y, 0);
CColourARGB c8(c4);
}
}
}
CColourARGB myfoo(uint8_t XT, uint8_t YT) {
return CColourARGB(0xF, XT, YT, 0);
}
void ok()
{
for (uint8_t y = 0; y < 4; ++y) {
for (uint8_t x = 0; x < 4; ++x) {
CColourARGB c4 = myfoo(x, y);
CColourARGB c8(c4);
}
}
}
int main()
{
printf("this\n");
ok();
printf("that\n");
broken();
}
/* --- end --- */
When not working the bit fields have not been updated, e.g. a broken case
output is;
Constructing CColourARGB ff00 from CColourARGB f330
When working the output has updated bitfields, e.g.
Constructing CColourARGB ff00 from CColourARGB f330
--
Summary: bitfields and -O2 or greater
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
GCC build triplet: i686-pc-linux
GCC host triplet: i686-pc-linux
GCC target triplet: i686-pc-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38027
[Bug c++/36122] New: Arm EABI C++ optimiser handles bit fields incorrectly
{
uint32_t count = 0x10;
uint32_t size = 0x40;
BugType bits1, bits2;
bits1.word = 0x0030;
bits2.word = 0x8030;
if( doRead(count, size, bits1, bits2) ) {
printf( "Passed.\n" );
return 0;
}
printf( "Failed!\n" );
return 42;
}
bool doRead( const uint32_t count, const uint32_t size, BugType bits1, BugType
bits2 )
{
if( (bits1.field.a + count) >= size ) {
bits1.field.b = !bits1.field.b;
bits1.field.a -= size;
}
bits1.field.a += count;
if( bits1.field.b == bits2.field.b ) {
if( bits1.field.a > bits2.field.a ) {
return false;
}
} else {
if( bits1.field.a < bits2.field.a ) {
return false;
}
}
return true;
}
--
Summary: Arm EABI C++ optimiser handles bit fields incorrectly
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
GCC build triplet: i686-pc-linux-gcc
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-*-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36122
[Bug c++/36122] Arm EABI C++ optimiser handles bit fields incorrectly
--- Comment #2 from john dot spelis at 3dlabs dot com 2008-05-07 11:14 --- Subject: Re: Arm EABI C++ optimiser handles bit fields incorrectly Thanks pinskia. I ported the 4.3.0 compilers and that's a confirmed fix to the issue. Best Regards On 5 May 2008, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-05 04:50 > --- > This is most likely a dup of bug 33887 and has been fixed for GCC 4.3.0. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36122 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36122
[Bug c++/36170] New: enum variable operation behaviour and -O2
continue;
case Options::Id::eNoSync:
opts.bSingleBuffer = true;
continue;
case Options::Id::eNoTCSET:
opts.bUseTCSET = false;
continue;
case Options::Id::eDemo:
if( gVerbose ) printf( "Running with demo options.\n" );
opts.bFixedAspect = true;
opts.bFullScreen = true;
opts.bAnimate = true;
opts.bSetMode = true;
opts.loopCount= 1;
opts.offset[0]= ~0U;
opts.offset[1]= ~0U;
opts.size[0] = 272;
opts.size[1] = 272;
continue;
case Options::Id::eBackground:
sscanf( optarg, "%d", &i );
opts.background = (Background::Type) i;
printf( "Background style set to %d\n",
opts.background );
continue;
case Options::Id::eRotate:
sscanf( optarg, "%d", &opts.vidRotate );
printf( "Video rotation set to %d\n",
opts.vidRotate );
continue;
case Options::Id::eStall:
opts.bStall = true;
continue;
case Options::Id::eBench:
if( optarg )
sscanf( optarg, "%d", &opts.benchmarkMode );
else
opts.benchmarkMode = 1;
printf( "Benchmark mode set to %d\n", opts.benchmarkMode );
continue;
default:
break;
}
fprintf(stderr, ANSI_BOLD ANSI_RED "Got unknown option id: %d!"
ANSI_RESET "\n", optEnum);
bSuccess = false;
}
return bSuccess;
#else
fprintf(stderr, ANSI_BOLD ANSI_RED "No getopt. Ignoring command line
arguments!" ANSI_RESET "\n");
return true;
#endif
}
int main( int argc, char *argv[] )
{
boolbSuccess = true;
const char *env;
class Options opts ;
if( !processArgs(argc, argv, opts) ) {
fprintf( stderr, ANSI_BOLD ANSI_RED "Failed to process command
line arguments!" ANSI_RESET "\n" );
bSuccess = false;
}
return(0) ;
}
--
Summary: enum variable operation behaviour and -O2
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36170
[Bug c++/36170] enum variable operation behaviour and -O2
--- Comment #2 from john dot spelis at 3dlabs dot com 2008-05-07 18:38 --- Subject: Re: enum variable operation behaviour and -O2 Thanks for ending that issue. Best Regards On 7 May 2008, pinskia at gcc dot gnu dot org wrote: > > > --- Comment #1 from pinskia at gcc dot gnu dot org 2008-05-07 17:23 > --- > And C++ standard says if the value is out of range of the enum, the behavior > is > undefined so this is not a bug. > > > -- > > pinskia at gcc dot gnu dot org changed: > >What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36170 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36170
[Bug c/36209] New: arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7
-fpreprocessed sysinfo.i -quiet -dumpbase sysinfo.c -mcpu=arm926ej-s -auxbase-strip proc/sysinfo.o -O2 -W -Wall -Wshadow -Wcast-align -Wredundant-decls -Wbad-function-cast -Wcast-qual -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wdeclaration-after-statement -Wpadded -Wstrict-aliasing -version -fno-common -ffast-math -fweb -frename-registers -fomit-frame-pointer -fno-inline-functions -fpic -o sysinfo.s GNU C (GCC) version 4.3.0 (arm-3d-linux-gnueabi) compiled by GNU C version 4.3.0, GMP version 4.2.2, MPFR version 2.3.0. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 7c3f80f5d14a419f1f92cb195c805d22 proc/sysinfo.c: In function �et_pid_digits� proc/sysinfo.c:896: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. -- Summary: arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot spelis at 3dlabs dot com GCC build triplet: i686-pc-linux GCC host triplet: i686-pc-linux GCC target triplet: arm-*-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36209
[Bug c/36209] arm-*-linux-gnueabi-gcc (4.3.0) segment fault during build of procps-3.2.7
--- Comment #1 from john dot spelis at 3dlabs dot com 2008-05-11 13:32 --- Created an attachment (id=15625) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15625&action=view) The sysinfo.i output for the segment fault compilation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36209
[Bug c++/36920] New: internal compiler error building libicu package
Building libicu from
http://packages.ubuntu.com/hardy/libicu38
using
configure --build=i686-pc-linux-gnu --host=arm-3d-linux-gnueabi
make
Configured and built without issue for a while then blew up;
arm-3d-linux-gnueabi-g++ -D_REENTRANT \
-I../common -I/tmp/icu/icu-3.8/icu/source/i18n \
-I/tmp/icu/icu-3.8/icu/source/common \
-DU_I18N_IMPLEMENTATION -g -O2 -fvisibility=hidden \
-c -DPIC -fPIC -o rematch.o \
/tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp
/tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp: In member function
void icu_3_8::RegexMatcher::MatchAt(int32_t, UErrorCode&):
/tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp:2290:
error: unrecognizable insn:
(insn 4205 1393 1395 183 /tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp:1462
(set (reg:SI 8 r8)
(plus:SI (reg:SI 3 r3 [971])
(mult:SI (reg/v:SI 14 lr [orig:254 opValue.2027 ] [254])
(const_int 32 [0x20] -1 (nil))
/tmp/icu/icu-3.8/icu/source/i18n/rematch.cpp:2290:
internal compiler error: in extract_insn, at recog.c:1990
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[1]: *** [rematch.o] Error 1
make[1]: Leaving directory `/tmp/icu/icu-3.8/icu/work/i18n'
make: *** [all-recursive] Error 2
Workaround:
Avoid using "-O2" on the compile line for the rematch.cpp source.
This can be done in the pre-configured source by patching;
icu-3.8/icu/source/i18n/Makefile.in
after the entry
"all-local: $(ALL_TARGETS)"
add
rematch.o: $(srcdir)/rematch.cpp
$(CXX) $(CPPFLAGS) $(DEFS) -c -o $@ $<
--
Summary: internal compiler error building libicu package
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot spelis at 3dlabs dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-3d-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36920
[Bug c++/36920] internal compiler error building libicu package
--- Comment #1 from john dot spelis at 3dlabs dot com 2008-07-24 20:01 --- Created an attachment (id=15954) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15954&action=view) save-temps file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36920
[Bug target/36920] internal compiler error building libicu package
--- Comment #2 from john dot spelis at 3dlabs dot com 2008-07-24 20:01 --- Created an attachment (id=15955) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15955&action=view) save-temps output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36920
[Bug target/36920] internal compiler error building libicu package
--- Comment #3 from john dot spelis at 3dlabs dot com 2008-07-24 20:02 --- Created an attachment (id=15956) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15956&action=view) output file from save-temp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36920
[Bug c++/26378] New: register aliasing causes stale data to be used
ing point ( -mfpu=softvfp ) which allows the problem to be identified by assembler output. arm-3d-linux-gcc -v -save-temps -Os -S brokenPointer.cxx Reading specs from /homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/specs Configured with: /homes/spelis/dopt/gnu/gcc-3.4.5/configure --prefix=/homes/spelis2/3.4.5gcc --with-gnu-as --with-gnu-ld --with-as=/opt/s2tools/lx/bin/arm-3d-linux-as --with-ld=/opt/s2tools/lx/bin/arm-3d-linux-ld --srcdir=/homes/spelis/dopt/gnu/gcc-3.4.5 --target=arm-3d-linux --with-cpu=arm926ejs --enable-languages=c,c++ --disable-shared --without-newlib --disable-threads Thread model: single gcc version 3.4.5 /homes/spelis2/3.4.5gcc/libexec/gcc/arm-3d-linux/3.4.5/cc1plus -E -quiet -v -D_GNU_SOURCE brokenPointer.cxx -mcpu=arm926ejs -Os -o brokenPointer.ii ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../include/c++/3.4.5" ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../include/c++/3.4.5/arm-3d-linux" ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../include/c++/3.4.5/backward" ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../arm-3d-linux/sys-include" ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../arm-3d-linux/include" #include "..." search starts here: #include <...> search starts here: /homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/include End of search list. brokenPointer.cxx:1:19: stdio.h: No such file or directory federation!spelis 19 ^Cm-3d-linux-gcc -v -save-temps -Os -S brokenPointer.cxx > federation!spelis 19 vi brokenPointer.cxx federation!spelis 20 arm-3d-linux-gcc -v -save-temps -Os -S brokenPointer.cxx > Reading specs from /homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/specs Configured with: /homes/spelis/dopt/gnu/gcc-3.4.5/configure --prefix=/homes/spelis2/3.4.5gcc --with-gnu-as --with-gnu-ld --with-as=/opt/s2tools/lx/bin/arm-3d-linux-as --with-ld=/opt/s2tools/lx/bin/arm-3d-linux-ld --srcdir=/homes/spelis/dopt/gnu/gcc-3.4.5 --target=arm-3d-linux --with-cpu=arm926ejs --enable-languages=c,c++ --disable-shared --without-newlib --disable-threads Thread model: single gcc version 3.4.5 /homes/spelis2/3.4.5gcc/libexec/gcc/arm-3d-linux/3.4.5/cc1plus -E -quiet -v -D_GNU_SOURCE brokenPointer.cxx -mcpu=arm926ejs -Os -o brokenPointer.ii ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../include/c++/3.4.5" ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../include/c++/3.4.5/arm-3d-linux" ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../include/c++/3.4.5/backward" ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../arm-3d-linux/sys-include" ignoring nonexistent directory "/homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/../../../../arm-3d-linux/include" #include "..." search starts here: #include <...> search starts here: /homes/spelis2/3.4.5gcc/lib/gcc/arm-3d-linux/3.4.5/include End of search list. /homes/spelis2/3.4.5gcc/libexec/gcc/arm-3d-linux/3.4.5/cc1plus -fpreprocessed brokenPointer.ii -quiet -dumpbase brokenPointer.cxx -mcpu=arm926ejs -auxbase brokenPointer -Os -version -o brokenPointer.s GNU C++ version 3.4.5 (arm-3d-linux) compiled by GNU C version 3.4.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 >Fix: Our workarounds include (i) not using the optimiser, or (ii) using a union instead of the "*((uint32_t *) &sy" style to obtain the floating point (result) pattern. -- Summary: register aliasing causes stale data to be used Product: gcc Version: 3.4.5 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: john dot spelis at 3dlabs dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: arm-3d-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26378
