[Bug c++/35396] New: possible incorrect opitmization due to missed dependency
configured with ../gcc-4.3-20080208/configure --enable-languages=c,c++,java
The same issue was also observed on i686-pc-linux x86-64 platforms.
>Description:
when an assignment to a variable is followed by 'cmpxchg' on the
variable, there exists a dependency between the two statements.
thus, the store has to complete before cmpxchg on the variable would
be issued.
The issue was not seen with -O0. It was seen when compiled with -O2.
I have not tried -O1, though.
For examples, when we have
inline bool LockByte( volatile unsigned char &flag ) {
volatile void *f = &flag;
if ( CompareAndSwap1(f,1,0) != 0) {
do {
__asm__ __volatile__("pause;");
} while ( CompareAndSwap1(f,1,0) != 0) ;
}
return 0;
}
main(...) {
...
char x = 0;
LockByte(x);
...
}
even with a single thread, LockByte() hangs i.e., spins forever.
It appears that the compiler misses the dependency and does not
generate the store to the memory location.
>How-To-Repeat:
Compile the following program with -O2 option. i.e.,
g++ -O2 . It hangs. g++ generates an executable
that completes and prints 'done'.
#include
#include
#define DECL_CMPSWP(S,T,X) \
static inline T machine_cmpswp##S (volatile void *ptr, T value, T comparand ) \
{ \
T result; \
\
__asm__ __volatile__("lock\ncmpxchg" X " %2,%1" \
: "=a"(result), "=m"(*(T *)ptr) \
: "q"(value), "0"(comparand) \
: "memory"); \
return result; \
}
DECL_CMPSWP(1,unsigned char,"b");
#define CompareAndSwap1(a,b,c) machine_cmpswp1(a,b,c)
inline bool LockByte( volatile unsigned char &flag ) {
volatile void *f = &flag;
if ( CompareAndSwap1(f,1,0) != 0) {
do {
__asm__ __volatile__("pause;");
} while ( CompareAndSwap1(f,1,0) != 0) ;
}
return 0;
}
static void TestTinyLock() {
unsigned char flags[16];
for( int i=0; i<16; ++i )
flags[i] = i;
flags[8] = 0;
LockByte(flags[8]);
for( int i=0; i<16; ++i )
assert( flags[i]==(i==8?1:i) );
}
int main( int argc, char* argv[] ) {
try {
TestTinyLock();
} catch(...) {
}
printf("done\n");
return 0;
}
-
'g++ -O2 -S' output
pushl %ecx
leal-16(%ebp), %eax
subl$88, %esp
movl%eax, -52(%ebp)
leal-84(%ebp), %eax
movl$___gxx_personality_sj0, -60(%ebp)
movl$LLSDA6, -56(%ebp)
movl$L13, -48(%ebp)
movl%esp, -44(%ebp)
movl%eax, (%esp)
call__Unwind_SjLj_Register
call___main
xorl%eax, %eax
leal-32(%ebp), %edx
.p2align 4,,7
L2:
movb%al, (%edx,%eax)
addl$1, %eax
cmpl$16, %eax
jne L2
leal-24(%ebp), %ebx
xorl%eax, %eax
movl$1, %edx
/APP
# 44 "test_test.cpp" 1
lock
cmpxchgb %dl,(%ebx)
# 0 "" 2
/NO_APP
testb %al, %al
je L3
movl$1, %ecx
xorl%edx, %edx
.p2align 4,,7
L14:
/APP
# 52 "test_test.cpp" 1
pause;
# 0 "" 2
/NO_APP
movl%edx, %eax
/APP
# 44 "test_test.cpp" 1
lock
cmpxchgb %cl,(%ebx)
# 0 "" 2
/NO_APP
testb %al, %al
jne L14
L3:
movl$0, -88(%ebp)
jmp L8
.p2align 4,,7
L6:
movzbl %al, %eax
cmpl%edx, %eax
je L7
movl$LC0, 8(%esp)
movl$66, 4(%esp)
movl$LC1, (%esp)
movl$1, -80(%ebp)
call___assert
L7:
addl$1, -88(%ebp)
cmpl$16, -88(%ebp)
je L9
L8:
>Fix:
The work-around is to declare the variabe to be 'volatile'
If we do
* (volatile unsigned char *) &flags[8] = 0;
instead, the generated executable completes.
--
Summary: possible incorrect opitmization due to missed dependency
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kimwooyoung at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35396
[Bug c++/35396] possible incorrect opitmization due to missed dependency
--- Comment #1 from kimwooyoung at gmail dot com 2008-02-28 06:35 --- Created an attachment (id=15240) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15240&action=view) a test file to re-produce the issue to reproduce the issue, compile it with 'g++ -O2 ' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35396
[Bug fortran/58904] New: ICE: accessing a component field of an unavailable type results in a seg fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58904 Bug ID: 58904 Summary: ICE: accessing a component field of an unavailable type results in a seg fault Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kimwooyoung at gmail dot com The following code causes gfortran 4.8.2 to die with a seg fault. (Ubuntu 12.10, intel64 (i.e., 64-bit x86) ) MODULE mymod CONTAINS TYPE(mytype) FUNCTION create_sort_range(b) result(r) INTEGER b r%b = b END FUNCTION create_sort_range END MODULE mymod The compiler produces the correct error message if the statement 'r%b = b' is commented out. $ gfortran -c repro.F90 f951: internal compiler error: Segmentation fault 0x869cbf crash_signal ../../gcc-4.8.2/gcc/toplev.c:332 0x555765 gfc_match_varspec(gfc_expr*, int, bool, bool) ../../gcc-4.8.2/gcc/fortran/primary.c:1944 0x555d31 match_variable ../../gcc-4.8.2/gcc/fortran/primary.c:3304 0x537eb9 gfc_match(char const*, ...) ../../gcc-4.8.2/gcc/fortran/match.c:1115 0x53925c gfc_match_assignment() ../../gcc-4.8.2/gcc/fortran/match.c:1292 0x54cb69 match_word ../../gcc-4.8.2/gcc/fortran/parse.c:65 0x54db6b match_word ../../gcc-4.8.2/gcc/fortran/parse.c:327 0x54db6b decode_statement ../../gcc-4.8.2/gcc/fortran/parse.c:327 0x54f154 next_free ../../gcc-4.8.2/gcc/fortran/parse.c:783 0x54f154 next_statement ../../gcc-4.8.2/gcc/fortran/parse.c:976 0x54f8ed parse_spec ../../gcc-4.8.2/gcc/fortran/parse.c:2760 0x551738 parse_progunit ../../gcc-4.8.2/gcc/fortran/parse.c:4124 0x551ac0 parse_contained ../../gcc-4.8.2/gcc/fortran/parse.c:4063 0x552c7f parse_module ../../gcc-4.8.2/gcc/fortran/parse.c:4322 0x552c7f gfc_parse_file() ../../gcc-4.8.2/gcc/fortran/parse.c:4593 0x58e365 gfc_be_parse_file ../../gcc-4.8.2/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug fortran/58906] New: SELECT TYPE with CLASS IS generates ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58906 Bug ID: 58906 Summary: SELECT TYPE with CLASS IS generates ICE Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kimwooyoung at gmail dot com The code fragment causes gfortan to die with a seg fault. Using 'TYPE IS' instead of 'CLASS IS' seems o.k. MODULE mymod TYPE base CONTAINS END TYPE base TYPE, EXTENDS(base) :: child CLASS(*), DIMENSION(:), POINTER :: arr CONTAINS END TYPE child CONTAINS SUBROUTINE f(r) CLASS(base), INTENT(INOUT) :: r SELECT TYPE ( r ) CLASS IS ( child ) !TYPE IS ( child ) SELECT TYPE( iarr=>r%arr ) TYPE IS ( INTEGER ) CALL func( iarr ) END SELECT END SELECT END SUBROUTINE f END MODULE mymod $ gfortran -c reprod2.F90 f951: internal compiler error: Segmentation fault 0x869cbf crash_signal ../../gcc-4.8.2/gcc/toplev.c:332 0x56a244 resolve_select_type ../../gcc-4.8.2/gcc/fortran/resolve.c:8367 0x56b7cc resolve_code ../../gcc-4.8.2/gcc/fortran/resolve.c:10379 0x56d24e resolve_codes ../../gcc-4.8.2/gcc/fortran/resolve.c:15047 0x55ddb2 gfc_resolve ../../gcc-4.8.2/gcc/fortran/resolve.c:15075 0x56b940 gfc_resolve ../../gcc-4.8.2/gcc/fortran/resolve.c:15066 0x56b940 resolve_block_construct ../../gcc-4.8.2/gcc/fortran/resolve.c:9367 0x56b940 resolve_code ../../gcc-4.8.2/gcc/fortran/resolve.c:10383 0x56a0fb gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-4.8.2/gcc/fortran/resolve.c:9449 0x56adf3 resolve_code ../../gcc-4.8.2/gcc/fortran/resolve.c:10193 0x56a0fb gfc_resolve_blocks(gfc_code*, gfc_namespace*) ../../gcc-4.8.2/gcc/fortran/resolve.c:9449 0x56ab1f resolve_select_type ../../gcc-4.8.2/gcc/fortran/resolve.c:8681 0x56b7cc resolve_code ../../gcc-4.8.2/gcc/fortran/resolve.c:10379 0x56d24e resolve_codes ../../gcc-4.8.2/gcc/fortran/resolve.c:15047 0x56d157 resolve_codes ../../gcc-4.8.2/gcc/fortran/resolve.c:15033 0x55ddb2 gfc_resolve ../../gcc-4.8.2/gcc/fortran/resolve.c:15075 0x552486 gfc_parse_file() ../../gcc-4.8.2/gcc/fortran/parse.c:4614 0x58e365 gfc_be_parse_file ../../gcc-4.8.2/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
[Bug fortran/59024] New: ICE: after printing certain error messages, the compiler seg faults.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59024 Bug ID: 59024 Summary: ICE: after printing certain error messages, the compiler seg faults. Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: kimwooyoung at gmail dot com This reproducer causes the compiler to seg fault. The compiler exits normally with the commented-out version. The reproducer is not a legal fortran program, but the compiler should not die with a seg fault. MODULE mtc USE ISO_C_BINDING PRIVATE PUBLIC :: tc, not_present1, & TYPE tc END TYPE tc INTERFACE tc MODULE PROCEDURE tc_ctor END INTERFACE tc CONTAINS ! TYPE(tc) FUNCTION tc_ctor() result(t) ! END FUNCTION tc_ctor FUNCTION tc_ctor() result(t) TYPE(tc) t END FUNCTION tc_ctor END MODULE mtc === gfortran -c gf_reprod.F90 gf_reprod.F90:6.6: TYPE tc 1 Error: Syntax error in PUBLIC statement at (1) gf_reprod.F90:7.5: END TYPE tc 1 Error: Expecting END MODULE statement at (1) gf_reprod.F90:15.12: TYPE(tc) t 1 Error: Derived type 'tc' at (1) is being used before it is defined f951: internal compiler error: Segmentation fault 0x869cbf crash_signal ../../gcc-4.8.2/gcc/toplev.c:332 0x50b3fb show_locus ../../gcc-4.8.2/gcc/fortran/error.c:310 0x50bc90 show_loci ../../gcc-4.8.2/gcc/fortran/error.c:434 0x50bc90 error_print ../../gcc-4.8.2/gcc/fortran/error.c:666 0x50c778 gfc_error(char const*, ...) ../../gcc-4.8.2/gcc/fortran/error.c:961 0x5144f7 check_interface0 ../../gcc-4.8.2/gcc/fortran/interface.c:1477 0x516dd4 check_sym_interfaces ../../gcc-4.8.2/gcc/fortran/interface.c:1589 0x57e693 do_traverse_symtree ../../gcc-4.8.2/gcc/fortran/symbol.c:3575 0x516ebc gfc_check_interfaces(gfc_namespace*) ../../gcc-4.8.2/gcc/fortran/interface.c:1699 0x55d51e resolve_types ../../gcc-4.8.2/gcc/fortran/resolve.c:14989 0x55dda0 gfc_resolve ../../gcc-4.8.2/gcc/fortran/resolve.c:15073 0x552486 gfc_parse_file() ../../gcc-4.8.2/gcc/fortran/parse.c:4614 0x58e365 gfc_be_parse_file ../../gcc-4.8.2/gcc/fortran/f95-lang.c:189 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions.
