[Bug c++/40843] New: private access violation: compile bad code
// Illegal access to private member not detected, program compiles silently.
// bug found in:
// g++ (GCC) 4.1.2 20080704 (Red Hat 4.1.2-44)
// g++ (Ubuntu 4.3.3-5ubuntu4) 4.3.3
#include
class A {
enum { value=1 }; // private
};
template // bug appears only if B is a template
struct B {
enum { value=A::value }; // <- silently access private member
};
int main() {
std::cout << B<1>::value << std::endl;
return 0;
}
--
Summary: private access violation: compile bad code
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sipych at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40843
[Bug c++/40843] access violation not detected for non dependent qualified enum value
--- Comment #2 from sipych at gmail dot com 2009-07-23 22:08 --- (In reply to comment #1) > I think this is a duplicate of bug 21008. > Not shure, A::value may not be accessible neither at the template definition, nor at the instantiation time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40843
[Bug c++/40843] access violation not detected for non dependent qualified enum value
--- Comment #3 from sipych at gmail dot com 2009-07-23 22:46 --- Also present in gcc 4.4.0 -- sipych at gmail dot com changed: What|Removed |Added Known to fail||4.1.2 4.3.3 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40843
[Bug c++/40843] access violation not detected for non dependent qualified enum value
--- Comment #4 from sipych at gmail dot com 2009-07-24 00:00 ---
// More similar cases. Static members also may be accessed
#include
class A {
enum { value=1 }; // private
static const int ci=2;
static int fi() { return 3; }
};
template // bug appears only if B is a template
struct B {
enum { value=A::value }; // <- silently access private member
// enum { v2=A::ci };// this error is detected @ any instantiation
static const int v3=A::value; // not detected
static const int v4=A::ci; // not detected
static int f5() { return A::value; } // not detected
static int f6() { return A::ci; } // detected only if f6() accessed
static int f7() { return A::fi(); }// detected only if f7() accessed,
reported twice
};
int main() {
std::cout << B<1>::value << B<1>::v3 << B<1>::v4 << B<1>::f5()
// << B<1>::f6()// error will be detected
// << B<1>::f7()// error will be detected, and reported TWICE
<< std::endl;
return 0;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40843
[Bug lto/51642] New: Weak variable reference triggers ICE with -flto option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51642
Bug #: 51642
Summary: Weak variable reference triggers ICE with -flto option
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sip...@gmail.com
The following program triggers ICE when compiled with -flto switch.
Tested on:
- GCC 4.6.2 and 4.6.1 on ARM target;
- GCC 4.6.2 x86 target (Fedora-16, x86_64)
NOTE: trying to add/remove -fnodefaultlibs option,
trying to add __attribute__(used) to "config_np" -
just the same ICE.
extern const int config_board;
const int config_np = 1;
#pragma weak config_board = config_np
int main(void)
{
return config_board;
}
Logs:
## Case 1: cross-gcc for ARM
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -o test.ax t00x0.c -O3 -nodefaultlibs
-flto
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
lto-wrapper: /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc returned 1 exit status
/opt/arm/gnuarm-4.6.2/lib/gcc/arm-eabi/4.6.2/../../../../arm-eabi/bin/ld:
lto-wrapper failed
collect2: ld returned 1 exit status
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/arm/gnuarm-4.6.2/libexec/gcc/arm-eabi/4.6.2/lto-wrapper
Target: arm-eabi
Configured with: ../../src/gcc-4.6.2/configure --target=arm-eabi
--prefix=/opt/arm/gnuarm-4.6.2 --enable-multilib --enable-interwork
--enable-biendian --enable-fpu --with-newlib --with-gnu-ld --with-gnu-as
--disable-nls --disable-shared --with-arch=armv5te --with-fpu=vfp
--with-float=softfp --with-abi=aapcs-linux --enable-lto
--enable-languages=c,c++ --disable-threads --enable-ppl --enable-cloog
--enable-gmp --enable-mpfr --enable-lto
-with-headers=/opt/arm/gnuarm-4.6.2/arm-eabi/include
Thread model: single
gcc version 4.6.2 (GCC)
## Case 2: Native gcc, Fedora-16
$ gcc -o test.ax t00x0.c -O3 -nodefaultlibs -flto
lto1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
lto-wrapper: /usr/bin/gcc returned 1 exit status
/usr/bin/ld: lto-wrapper failed
collect2: ld returned 1 exit status
$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.6.2/lto-wrapper
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-gnu-unique-object
--enable-linker-build-id
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin
--enable-java-awt=gtk --disable-dssi
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i686
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.6.2 20111027 (Red Hat 4.6.2-1) (GCC)
[Bug rtl-optimization/51643] New: Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643
Bug #: 51643
Summary: Incorrect code produced for tail-call of weak function
with -O2/-O3 option
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sip...@gmail.com
A tail-call of weak function produces incorrect code, compiled with -O2 or -O3.
Target: arm-eabi
Version: GCC 4.6.2 and 4.6.1
* Test case: t00x1.c
<
extern void __attribute__((weak)) wfunc(void);
void main(void)
{
wfunc(); // tail weak call fails!!!
// __asm__ volatile ("nop":::"memory"); // workaround
}
>
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -c -S -o t00x1.S -O2 t00x1.c
* Contents of t00x1.S:
.file"t00x1.c"
.section.text.startup,"ax",%progbits
.align2
.globalmain
.typemain, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
bwfunc <<< Will be replaced by "NOP" in linker!!
so, no return sequence!
.sizemain, .-main
.weakwfunc
.ident"GCC: (GNU) 4.6.2"
* Disassembled (objdump) code: t00x1.lst:
0240 :
240:e1a0 nop; (mov r0, r0) really, NOP
0244 <__do_global_dtors_aux>:
244:e92d4010 push{r4, lr}
248:e59f4028 ldrr4, [pc, #40]; 278
...
**
Call to function "wfunc" was converted to NOP by linker, as expected.
As a result, no return sequence from main(), falling througt to next code line.
For reference: the same program compiled with -O1
***
.file"t00x1.c"
.text
.align2
.globalmain
.typemain, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfdsp!, {r3, lr}
blwfunc
ldmfdsp!, {r3, pc}
.sizemain, .-main
.weakwfunc
.ident"GCC: (GNU) 4.6.2"
Code with workaround, compiled with -O2 correct:
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -c -S -o t00x1.S -O2 t00x1.c
***
.file"t00x1.c"
.section.text.startup,"ax",%progbits
.align2
.globalmain
.typemain, %function
main:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
stmfdsp!, {r3, lr}
blwfunc
@ 5 "t00x1.c" 1
nop
@ 0 "" 2
ldmfdsp!, {r3, pc}
.sizemain, .-main
.weakwfunc
.ident"GCC: (GNU) 4.6.2"
***
Compiler options:
$ /opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=/opt/arm/gnuarm-4.6.2/bin/arm-eabi-gcc
COLLECT_LTO_WRAPPER=/opt/arm/gnuarm-4.6.2/libexec/gcc/arm-eabi/4.6.2/lto-wrapper
Target: arm-eabi
Configured with: ../../src/gcc-4.6.2/configure --target=arm-eabi
--prefix=/opt/arm/gnuarm-4.6.2 --enable-multilib --enable-interwork
--enable-biendian --enable-fpu --with-newlib --with-gnu-ld --with-gnu-as
--disable-nls --disable-shared --with-arch=armv5te --with-fpu=vfp
--with-float=softfp --with-abi=aapcs-linux --enable-lto
--enable-languages=c,c++ --disable-threads --enable-ppl --enable-cloog
--enable-gmp --enable-mpfr --enable-lto
-with-headers=/opt/arm/gnuarm-4.6.2/arm-eabi/include
Thread model: single
gcc version 4.6.2 (GCC)
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #3 from Alexander Osipenko 2011-12-20 21:39:11 UTC --- This behavior is explicitly defined in ARM RealView compiler, and GCC seems try to follow this convention.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #4 from Alexander Osipenko 2011-12-20 21:58:39 UTC --- >From ARM EABI specification (doc: ARM IHI 0044A) "On platforms that do not support dynamic pre-emption of symbols an unresolved weak reference to a symbol relocated by R_ARM_CALL shall be treated as a jump to the next instruction (the call becomes a no-op). The behaviour of R_ARM_JUMP24 in these conditions is unspecified." At least, tail call + epilogue shall not be replaced by (undefined) JUMP.
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #6 from Alexander Osipenko 2011-12-20 23:33:06 UTC --- It seems reasonable to expect minimal consistency, either generating invalid (zero for example) reference for any direct weak function call, better marking it with "warning" or even "error" message, or not depending on the optimization options. In any case, the semantics of weak referencies is beyond of the C standard scope, so even "if( wfunc ) wfunc();" may be treated only in terms of reasonable consistency. EABI specification follows a simple rule: "call to undefined weak function do nothing". Just the same do "if( wfunc ) wfunc();", a little bit longer, if we believe that undefined wfunc == 0 always, but not 0xDEADBEEF eventually when optimized.
[Bug lto/51642] Weak variable reference triggers ICE with -flto option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51642 Alexander Osipenko changed: What|Removed |Added Known to work||4.7.0 --- Comment #2 from Alexander Osipenko 2011-12-21 20:44:35 UTC --- No ICE in the recent snapshot: svn://gcc.gnu.org/svn/gcc/trunk Revision: 182598 $ /opt/arm/gnuarm-4.7.0/bin/arm-eabi-gcc -v Using built-in specs. COLLECT_GCC=/opt/arm/gnuarm-4.7.0/bin/arm-eabi-gcc COLLECT_LTO_WRAPPER=/opt/arm/gnuarm-4.7.0/libexec/gcc/arm-eabi/4.7.0/lto-wrapper Target: arm-eabi Configured with: ../../src/gcc-4.7.0/configure --target=arm-eabi --prefix=/opt/arm/gnuarm-4.7.0 --enable-multilib --enable-interwork --enable-biendian --enable-fpu --with-newlib --with-gnu-ld --with-gnu-as --disable-nls --disable-shared --with-arch=armv5te --with-fpu=vfp --with-float=softfp --with-abi=aapcs-linux --enable-lto --enable-languages=c,c++ --disable-threads --enable-ppl --enable-cloog --enable-gmp --enable-mpfr --enable-lto -with-headers=/opt/arm/gnuarm-4.7.0/arm-eabi/include Thread model: single gcc version 4.7.0 20111221 (experimental) (GCC)
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #13 from Alexander Osipenko 2011-12-22 21:31:56 UTC --- Thanks, Richard! It now works fine with -mabi=aapcs Perhaps I don't understand some details, could you tell me why the -mabi=aapcs-linux is not included in this fix?
[Bug target/51643] Incorrect code produced for tail-call of weak function with -O2/-O3 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51643 --- Comment #15 from Alexander Osipenko 2011-12-23 00:40:13 UTC --- Oh, I see, thanks!
