[Bug c++/40183] New: g++.dg/tls/static-1.C, execution abort
# g++ static-1.C static-1a.cc -O2 # export LD_LIBRARY_PATH=/import/dr3/s10/gcc-4.4.0/lib/ # ./a.out Abort (core dumped) The error would be gone if /usr/sfw/lib/libstdc++.so.6 is linked. so I assume the error lives in the library libstdc++.so.6 that gcc 4.4 provides. Any information that you need, please let me know. # g++ -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /import/iropt5/lijuan/plain-gcc/gcc-git/configure --prefix=/import/dr3/s10/gcc-4.4.0 --enable-languages=c,c++,fortran --disable-gnattools --enable-shared --disable-static --with-system-zlib --enable-checking=release --disable-gnattools --enable-tls --disable-bootstrap Thread model: posix gcc version 4.4.0 20090421 (prerelease) (GCC) # uname -a SunOS clpt-v490-1 5.10 Generic_118833-33 sun4u sparc SUNW,Sun-Fire-V490 -- Summary: g++.dg/tls/static-1.C, execution abort Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40183
[Bug c++/40183] g++.dg/tls/static-1.C, execution abort
--- Comment #1 from hailijuan at gmail dot com 2009-05-18 10:07 --- Created an attachment (id=17885) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17885&action=view) static-1.C and static-1a.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40183
[Bug c/40471] New: __sync_fetch_and_add seems not working well for -march=i686
Hi,
Please take a look at the testcase faadd.c:
--
int foo (int * p, int i)
{
return __sync_fetch_and_add(p, i);
}
int n = 1;
int main()
{
printf("%d %d\n", foo (&n, n), n);
return 0;
}
--
It is expected to print "1 2". However gcc 4.4.0 for i386-solaris prints "1 1"
for it.
# gcc faadd.c -march=i686
faadd.c: In function 'main':
faadd.c:9: warning: incompatible implicit declaration of built-in function
'printf'
# ./a.out
1 1
# gcc -v
Using built-in specs.
Target: i386-pc-solaris2.11
Configured with: /import/iropt5/lijuan/plain-gcc/gcc-git/configure
--prefix=/import/dr3/i386/gcc-4.4.0 --enable-shared --disable-static
--disable-libtool-lock --disable-libada --enable-libssp
--enable-languages=c,c++,objc,fortran --enable-threads=posix --enable-tls=yes
--with-system-zlib --without-gnu-ld --with-ld=/usr/ccs/bin/ld
--with-as=/usr/sfw/bin/gas --enable-c99 --enable-nls --enable-wchar_t
--enable-libstdcxx-allocator=mt --with-pic --disable-bootstrap
Thread model: posix
gcc version 4.4.0 20090421 (prerelease) (GCC)
# uname -a
SunOS gcc-v20z-s04 5.11 snv_102 i86pc i386 i86pc
The assembly code for foo looks like as follows:
foo:
pushl %ebp
movl%esp, %ebp
movl12(%ebp), %edx
movl8(%ebp), %eax
lock xaddl %edx, (%eax)
movl%edx, %eax
popl%ebp
ret
I have also tried running it on other hosts. x86-solaris and x86-Linux both
printed "1 1" while sparc and powerpc machines both printed "1 2". Is it a real
defect agains gcc for x86-solaris or something wrong with -march? Thanks a lot,
-- Lijuan
--
Summary: __sync_fetch_and_add seems not working well for -
march=i686
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40471
[Bug c/40471] __sync_fetch_and_add seems not working well for -march=i686
--- Comment #2 from hailijuan at gmail dot com 2009-06-17 10:07 --- Subject: Re: __sync_fetch_and_add seems not working well for -march=i686 Yes, I have seen the difference. Thanks muchly. I will close it. 2009/6/17 jakub at gcc dot gnu dot org : > > > --- Comment #1 from jakub at gcc dot gnu dot org 2009-06-17 08:04 --- > That's undefined behavior, there is no sequence point between the the > evaluation of foo (&n, n) and evaluation of n passed as the next argument. > If foo (&n, n) is evaluated first, you will see 1 2 printed, if n is evaluated > first, you see 1 1. > > > -- > > jakub at gcc dot gnu dot org changed: > > What|Removed |Added > > Status|UNCONFIRMED |RESOLVED > Resolution||INVALID > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40471 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40471
[Bug regression/40483] New: gcc 4.x needs to utilize better COMDAT mechanism under Solaris
SHT_GROUP sections are used to fully support well controlled COMDAT, as detailed here: http://www.airs.com/blog/archives/52 The support for SHT_GROUP appeared in the gcc 4.x series. Since Solaris has supported SHT_GROUP since shortly after it was defined, once might assume that gcc 4.x would use SHT_GROUP under Solaris, as it does for Linux. However it's not true usually. The macro HAVE_COMDAT_GROUP is used for gcc to direct if SHT_GROUP support is available. It's found that the macro is set to 0 if configured gcc with Solaris linker and/or Solaris assembler, which means gcc has to rely on older mechanism for doing COMDAT sections known as "GNU linkonce". The assembly code as follows .section .text,"axG",@progbits,.foo,comdat is used for gcc configure to check if the specified assembler supports COMDAT group. Solaris assembler failed to assemble the code of GNU-style. For Solaris assembler for sparc, the format for COMDAT group looks like as follows: .group foo,".text%foo",#comdat .section ".text%foo" For Solaris assembler for x86, the format may look like as follows: .group __i686.get_pc_thunk.cx, .text.__i686.get_pc_thunk.cx%__i686.get_pc_thunk.cx, #comdat .section .text.__i686.get_pc_thunk.cx%__i686.get_pc_thunk.cx,"ax" __i686.get_pc_thunk.cx: Gcc 4.x assume linkers other than GNU ld don't support COMDAT group. However Solaris linkers do support it. It would be better for gcc to be able to use COMDAT group under Solaris. Besides, sparc_elf_asm_named_section in sparc/sparc.c and i386_solaris_elf_named_section in i386/i386.c have to generate COMDAT groups with satisfying format under Solaris. Any thoughts? Thanks, -- Lijuan -- Summary: gcc 4.x needs to utilize better COMDAT mechanism under Solaris Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40483
[Bug preprocessor/35055] New: missing path to finclude directory when compiling .F90 files
testcase: (a.F90)
#include "omp_lib.h"
call omp_set_dynamic (.false.)
call omp_set_num_threads(4)
!$omp parallel
print *, "t#:", omp_get_thread_num()
!$omp end parallel
end
#gfortran a.F90 -fopenmp
a.F90:1: error: omp_lib.h: No such file or directory
the file omp_lib.h is found in
/import/dr3/s10/gcc-4.3/bin/../lib/gcc/sparc-sun-solaris2.10/4.3.0/finclude.
"cc1 -E -lang-fortran -traditional-cpp -D_LANGUAGE_FORTRAN" is invoked to
preprocess a.F90. the array cpp_include_defaults defined in cppdefault.c has to
add in ***/finclude/ and its data structure has to be refined to mark the
include is for fortran.
--
Summary: missing path to finclude directory when compiling .F90
files
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35055
[Bug c++/35246] declaration of threadprivate variable considered first use
--- Comment #1 from hailijuan at gmail dot com 2008-02-18 04:37 --- the error message was raised in finish_omp_threadprivate (cp/semantics.c). It was the field TREE_USED set to 1 that trigered the error. build_aggr_init set TREE_USED of variable a. the call frame looks like: =>[1] build_aggr_init(exp = 0xfed99a00, init = 0xfee99ad0, flags = 0), line 1087 in "init.c" [2] check_initializer(decl = 0xfed99a00, init = 0xfee99ad0, flags = 0, cleanup = 0xffbff26c), line 4881 in "decl.c" [3] cp_finish_decl(decl = 0xfed99a00, init = 0xfee99ad0, init_const_expr_p = '\001', asmspec_tree = (nil), flags = 0), line 5292 in "decl.c" [4] cp_parser_init_declarator(parser = 0xfee973b0, decl_specifiers = (nil), checks = (nil), function_definition_allowed_p = '\001', member_p = '\0', declares_class_or_enum = 0, function_definition_p = (nil)), line 11359 in "parser.c" [5] cp_parser_simple_declaration(parser = 0xfee973b0, function_definition_allowed_p = '\001'), line 7433 in "parser.c" [6] cp_parser_block_declaration(parser = 0xfee973b0, statement_p = '\0'), line 7333 in "parser.c" [7] cp_parser_declaration(parser = 0xfee973b0), line 7249 in "parser.c" [8] cp_parser_declaration_seq_opt(parser = 0xfee973b0), line 7144 in "parser.c" [9] cp_parser_translation_unit(parser = 0xfee973b0), line 2847 in "parser.c" [10] c_parse_file(), line 19552 in "parser.c" [11] c_common_parse_file(set_yydebug = 0), line 1226 in "c-opts.c" [12] compile_file(), line 1040 in "toplev.c" [13] do_compile(), line 2037 in "toplev.c" [14] toplev_main(argc = 0, argv = 0xffbff804), line 2069 in "toplev.c" [15] main(argc = 17, argv = 0xffbff804), line 35 in "main.c" so we'd know if the variables actually used in the source lines before raising such error messages. -- hailijuan at gmail dot com changed: What|Removed |Added CC||hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35246
[Bug c++/35246] New: declaration of threadprivate variable considered first use
the simple omp-c++ testcase a.c caused g++ report error messages like
following:
# g++ -fopenmp a.c
a.c:14: error: 'a' declared 'threadprivate' after first use
# g++ -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /import/dr2/starlex/orig/trunk/configure
--prefix=/import/dr3/s10/gcc-4.3/ --enable-languages=c,c++,fortran
--disable-gnattools --with-mpfr=/ws/gccfss/tools --with-gmp=/ws/gccfss/tools
Thread model: posix
gcc version 4.3.0 20070912 (experimental) (GCC)
-- src of a.c --
#include
#include
class A {
public:
int i;
A()
{
i = 10;
};
};
A a;
#pragma omp threadprivate(a)
main()
{
omp_set_dynamic(false);
omp_set_num_threads(5);
#pragma omp parallel
{
printf("a.i = %d\n", a.i);
}
}
-- end --
--
Summary: declaration of threadprivate variable considered first
use
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35246
[Bug libstdc++/39775] New: ext/throw_allocator/check_delete.cc execution abort with mt_allocator
On Solaris 11, we observed execution abort for the testcase below: +libstdc++.sum:FAIL: ext/throw_allocator/check_delete.cc execution test The testcase check_delete.cc and its related header files are included in the attachment bug.tar. # g++ check_delete.cc -D_GLIBCXX_ASSERT -I. # ./a.out Assertion failed: bool(__gnu_test::check_delete()), file check_delete.cc, line 48 Abort (core dumped) The error is triggered by defining mt_allocator as the base class to std::allocator in c++allocator.h. It could be gone by including c++allocator.h in new/bits/ which define new_allocator as base class. # g++ check_delete.cc -D_GLIBCXX_ASSERT -I. -I./new # ./a.out We configured gcc 4.3.2 with --enable-libstdcxx-allocator=mt as well as other options as below. # g++ -v Using built-in specs. Target: sparc-sun-solaris2.11 Configured with: /import/iropt5/lijuan/plain-gcc/gcc-4.3.2/configure --prefix=/import/iropt5/lijuan/plain-gcc/compilers/gcc-4.3.2 --enable-shared --disable-static --with-system-zlib --enable-checking=release --enable-languages=c,c++ --disable-libobjc --with-cpu=v9 --with-ld=/usr/ccs/bin/ld --without-gnu-ld --with-as=/usr/ccs/bin/as --without-gnu-as --disable-gnattools --enable-tls --enable-libstdcxx-allocator=mt Thread model: posix gcc version 4.3.2 (GCC) # uname -a SunOS gccfss-v890-1 5.11 snv_111 sun4u sparc SUNW,Sun-Fire-V890 Please verify if it's a real bug in gcc or not. If you need any other information, please let me know. Thanks. -- Summary: ext/throw_allocator/check_delete.cc execution abort with mt_allocator Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39775
[Bug libstdc++/39775] ext/throw_allocator/check_delete.cc execution abort with mt_allocator
--- Comment #1 from hailijuan at gmail dot com 2009-04-15 07:43 --- Created an attachment (id=17642) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17642&action=view) check_delete.cc and its header files. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39775
[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86
--- Comment #4 from hailijuan at gmail dot com 2009-09-24 09:50 --- There is another problem with "gcc -m64 -pg" since 4.4.0, seen from below: # file /import/dr3/i386/gcc-4.4.0/lib/gcc/i386-pc-solaris2.11/4.4.0/amd64/gmon.o /import/dr3/i386/gcc-4.4.0/lib/gcc/i386-pc-solaris2.11/4.4.0/amd64/gmon.o: ELF 32-bit LSB relocatable 80386 Version 1 Seen from gcc building log, gcc didn't build gmon.o with m64 as expected. Since 4.4, gcc/config/i386/t-sol2 has been moved to libgcc/config/i386/t-sol2. However the flags for gmon.o turned to be empty. Any comments on the issue? Thanks, -- Lijuan (In reply to comment #3) > internal_mcount's from and self arguments were reversed from glibc's version. > Here's the full diff of gmon-sol2.c that produces correct output: > --- gcc/config/i386/gmon-sol2.c.origWed Jul 29 08:57:15 2009 > +++ gcc/config/i386/gmon-sol2.c Thu Jul 30 07:53:16 2009 > @@ -66,7 +66,7 @@ > extern void _mcleanup (void); > extern void internal_mcount ( > #ifdef __x86_64__ > -char *, unsigned short * > +unsigned short *, char * > #else > void > #endif > @@ -266,8 +266,8 @@ > "\tmovq\t%r9,0x30(%rsp)\n" > /* Get SELFPC (pushed by the call to this function) and > FROMPCINDEX (via the frame pointer. */ > -"\tmovq\t0x38(%rsp),%rdi\n" > -"\tmovq\t0x8(%rbp),%rsi\n" > +"\tmovq\t0x38(%rsp),%rsi\n" > +"\tmovq\t0x8(%rbp),%rdi\n" > "\tcallq\tinternal_mcount\n" > /* Restore the saved registers. */ > "\tmovq\t0x30(%rsp),%r9\n" > @@ -275,7 +275,7 @@ > "\tmovq\t0x20(%rsp),%rdi\n" > "\tmovq\t0x18(%rsp),%rsi\n" > "\tmovq\t0x10(%rsp),%rdx\n" > -"\tmovq\t0x08(%rsp),%rdx\n" > +"\tmovq\t0x08(%rsp),%rcx\n" > "\tmovq\t(%rsp),%rax\n" > "\taddq\t$0x38,%rsp\n" > "\tretq\n" > @@ -290,8 +290,8 @@ > void > internal_mcount ( > #ifdef __x86_64__ > -char *selfpc, > -unsigned short *frompcindex > +unsigned short *frompcindex, > + char *selfpc > #else > void > #endif > -- hailijuan at gmail dot com changed: What|Removed |Added CC||hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38085
[Bug fortran/33954] New: gfortran: incorrect output for array of dynamic bounds
the testcase is minimized as file d.f90: SUBROUTINE sub(a, n) REAL a(2:, 3:) DO i=2, n+1 DO j=3, n+2 a(j,i)= i+j ENDDO ENDDO RETURN END PROGRAM test INTERFACE SUBROUTINE sub(a,n) REAL a(2:,3:) INTEGER n END SUBROUTINE sub END INTERFACE REAL bigarray(4,4) CALL sub(bigarray(1:4:2,4:1:-2),2) PRINT *,bigarray END PROGRAM test micro# /import/dr3/s10/gcc-4.2/bin/gfortran -O3 d.f90 -o d micro# ./d 0.00 0.00 -2.5430994E+38 -2.4856564E+38 -2.4856564E+38 NaN 9.1908364E-41NaN 1.4012985E-45 -2.4595213E+38 9.3875787E-41 -2.5448664E+38 -2.5448664E+38 5.2214013E-35 6.00 0.00 micro# uname -a SunOS micro 5.10 Generic_118822-30 sun4u sparc SUNW,Sun-Blade-1000 micro# /import/dr3/s10/gcc-4.2/bin/gfortran -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /import/dr2/starlex/1/gcc-4.2-20070228/configure --prefix=/import/dr3/s10/gcc-4.2 --enable-languages=c,c++,fortran --enable-rpath --with-mpfr=/import/dr3/s10/gcc-4.2 --with-gmp=/import/dr3/s10/gcc-4.2 Thread model: posix gcc version 4.2.0 20070228 (prerelease) -- Summary: gfortran: incorrect output for array of dynamic bounds Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954
[Bug fortran/33954] gfortran: incorrect output for array of dynamic bounds
--- Comment #3 from hailijuan at gmail dot com 2007-10-31 05:46 --- Subject: Re: gfortran: incorrect output for array of dynamic bounds exactly! but why gfortran does that? is that permitted by fortran standards? thanks a lot. 31 Oct 2007 04:01:08 -, jvdelisle at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-10-31 04:01 > --- > gfortran does not initialize bigarray for you, so you get what is in memory > there at the moment. > > If I set bigarray = 0. I get: > > 0.000 0.000 0.000 0.000 0.000 > 0.000 0.000 0.000 0.000 0.000 > 0.000 0.000 0.000 0.000 6.000 > 0.000 > > With gfortran 4.2, 4.3, and Intel ifort and Sun F95 > > Is this what you expect to see? > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954
[Bug fortran/33954] gfortran: incorrect output for array of dynamic bounds
--- Comment #6 from hailijuan at gmail dot com 2007-10-31 06:17 --- Subject: Re: gfortran: incorrect output for array of dynamic bounds not like that. it's right to use a(j,i) which has j as lower dimension. memory layout of array(0:2, 0:1) is like: a(0,0), a(1,0), a(2,0), a(0,1), a(1,1), a(2,1) the testcase is invalid for gfortran. I would close the bug report. 31 Oct 2007 06:07:16 -, jvdelisle at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #5 from jvdelisle at gcc dot gnu dot org 2007-10-31 06:07 > --- > You have the array indexes reversed: > > a(j,i)= i+j should be a(i,j) = i+j > > To keep your references within the bounds of the array you defined. Use > -fbounds-check as Steve pointed out and you will get an error message. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954
[Bug fortran/33954] gfortran: incorrect output for array of dynamic bounds
--- Comment #8 from hailijuan at gmail dot com 2007-10-31 07:18 --- Subject: Re: gfortran: incorrect output for array of dynamic bounds running a.out compiled with -fbounds-check and then get following message: micro# ./a.out Fortran runtime error: Array reference out of bounds for array 'a', lower bound of dimension 2 exceeded (in file 'd.f90', at line 6) I have to say the testcase has been really confusing me. Anyway, thanks for your good explanation. Appreciate it. 31 Oct 2007 06:50:39 -, kargl at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #7 from kargl at gcc dot gnu dot org 2007-10-31 06:50 --- > (In reply to comment #6) > > Subject: Re: gfortran: incorrect output for array of dynamic bounds > > > > not like that. it's right to use a(j,i) which has j as lower dimension. > > memory layout of array(0:2, 0:1) is like: > > a(0,0), a(1,0), a(2,0), a(0,1), a(1,1), a(2,1) > > You're not even close to the want the code is doing. > > > the testcase is invalid for gfortran. I would close the bug report. > > > > The testcase is invalid for ALL Fortran compilers. How many times > does one need to tell you that the code is invalid Fortran. Period. > > Again, add -fbounds-check to the compiler options and see what happens. > Try your code with other compilers and their strictest conformance and > debugging options. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954
[Bug fortran/33954] gfortran: incorrect output for array of dynamic bounds
--- Comment #9 from hailijuan at gmail dot com 2007-10-31 07:20 --- invalid testcase. -- hailijuan at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33954
[Bug c++/34258] New: g++ inlined destructors incorrectly throw exception out of clean-up handler
without g++ FE inlining, ct.C (attached in the following)correctly called
my_terminate when an exception was thrown in a destructor called in a clean-up
exception handler. However, after FE inlining, this exception was propagate out
of the clean-up exception handler and reached the catch(...) block in the outer
caller function.
This bug seems to exist in g++ versions 3.4.3 up to 4.2.
-bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ ct.C
-bash-3.00$ ./a.out
throw 1
throw 2
ABC::~ABC()
PASS: my_terminate
-bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ ct.C -O
-bash-3.00$ ./a.out
throw 1
throw 2
ABC::~ABC()
ERROR: should not catch ...
-bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ ct.C -O -DNO_FE_INLINE
-bash-3.00$ ./a.out
throw 1
throw 2
ABC::~ABC()
PASS: my_terminate
-bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /import/dr2/starlex/1/gcc-4.2-20070228/configure
--prefix=/import/dr3/s10/gcc-4.2 --enable-languages=c,c++,fortran
--enable-rpath --with-mpfr=/import/dr3/s10/gcc-4.2
--with-gmp=/import/dr3/s10/gcc-4.2
Thread model: posix
gcc version 4.2.0 20070228 (prerelease)
-bash-3.00$ cat ct.C
// mimic ctype.C
// a constructor calls other functions
// its base class constructor can throw exception
// handler of that case should be allowed to unwind_resume?
#include
#include
#include
struct ABC
{
// ABC();
~ABC();
};
extern "C" void f2();
struct BASE
{
ABC tmp;
// BASE();
#if !defined(NO_FE_INLINE)
inline ~BASE() { f2(); }
#else
~BASE();
#endif
};
#if defined(NO_FE_INLINE)
BASE::~BASE() { f2(); }
#endif
struct CHILD: public BASE
{
#if defined(__GNUC__) && !defined(NO_FE_INLINE)
CHILD() __attribute__((noinline));
#else
CHILD();
#endif
// ~CHILD();
};
extern "C" void f1();
CHILD::CHILD()
{
f1();
}
extern "C" void f1()
{
printf("throw 1\n"); fflush(stdout);
throw 1;
}
extern "C" void f2()
{
printf("throw 2\n"); fflush(stdout);
throw 2;
}
void my_terminate()
{
printf("PASS: my_terminate\n");
exit(0);
}
int main()
{
std::set_terminate(my_terminate);
try {
CHILD tmp;
printf("ERROR: should not be here ...\n");
fflush(stdout);
} catch (...) {
printf("ERROR: should not catch ...\n");
fflush(stdout);
}
return 0;
}
ABC::~ABC()
{
printf("ABC::~ABC()\n");
fflush(stdout);
}
--
Summary: g++ inlined destructors incorrectly throw exception out
of clean-up handler
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34258
[Bug c++/34258] g++ inlined destructors incorrectly throw exception out of clean-up handler
--- Comment #1 from hailijuan at gmail dot com 2007-11-28 09:17 --- Created an attachment (id=14652) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14652&action=view) to address the bug in g++ exception handler -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34258
[Bug c++/34513] New: static variable not found for C++ OpenMP
g++ miss static variable for C++ OpenMP while gcc working well. testcase a.c attached to show the problem. static variable shrd is not found during linking. micro# g++ a.c -fopenmp Undefined first referenced symbol in file main::shrd /tmp/ccqOSjqL.o micro# gcc a.c -fopenmp micro# gcc -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /import/dr2/starlex/orig/trunk/configure --prefix=/import/dr3/s10/gcc-4.3/ --enable-languages=c,c++,fortran --disable-gnattools --with-mpfr=/ws/gccfss/tools --with-gmp=/ws/gccfss/tools Thread model: posix gcc version 4.3.0 20070912 (experimental) (GCC) -- Summary: static variable not found for C++ OpenMP Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34513
[Bug c++/34513] static variable not found for C++ OpenMP
--- Comment #1 from hailijuan at gmail dot com 2007-12-17 17:37 --- Created an attachment (id=14785) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14785&action=view) openmp testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34513
[Bug c++/34513] static variable not found for C++ OpenMP
--- Comment #3 from hailijuan at gmail dot com 2007-12-18 03:24 --- Subject: Re: static variable not found for C++ OpenMP no, failed even when compiling with "-O2 -g". could you show me your compiler version and options? thanks. 17 Dec 2007 18:13:37 -, pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #2 from pinskia at gcc dot gnu dot org 2007-12-17 18:13 > --- > This works with optimization turned on. > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34513 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34513
[Bug c++/34517] New: INCOROUT: C++ OpenMP lastprivate
testcase b.C attached to show the problem. "a.ai += addnum" refers to distinct objects therefore a.ai finally equals to 7 rather than 28 (now it is!) when reaching printf. micro# g++ b.C -fopenmp micro# ./a.out constructor constructor constructor constructor constructor ai: 28 exp: 7 af: 28.00 exp: 7 micro# g++ -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /import/dr2/starlex/orig/trunk/configure --prefix=/import/dr3/s10/gcc-4.3/ --enable-languages=c,c++,fortran --disable-gnattools --with-mpfr=/ws/gccfss/tools --with-gmp=/ws/gccfss/tools Thread model: posix gcc version 4.3.0 20070912 (experimental) (GCC) -- Summary: INCOROUT: C++ OpenMP lastprivate Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34517
[Bug c++/34517] INCOROUT: C++ OpenMP lastprivate
--- Comment #1 from hailijuan at gmail dot com 2007-12-18 06:07 --- Created an attachment (id=14789) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14789&action=view) C++ OpenMP testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34517
[Bug c++/34513] static variable not found for C++ OpenMP
--- Comment #7 from hailijuan at gmail dot com 2007-12-20 02:21 --- fixed in revision 131059 -- hailijuan at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34513
[Bug c++/36288] New: OpenMP-C++: segmentation fault in basic string constructors
the testcase b.cc is attached to show the problem. the error just happened with -m64. -bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ b.cc -m64 -fopenmp -bash-3.00$ export LD_LIBRARY_PATH=/import/dr3/s10/gcc-4.2/lib/sparcv9 -bash-3.00$ ./a.out Segmentation Fault (core dumped) -bash-3.00$ dbx a.out (dbx) run Running: a.out (process id 12660) Reading libc_psr.so.1 [EMAIL PROTECTED] ([EMAIL PROTECTED]) signal SEGV (no mapping at the fault address) in _memcpy at 0x7dc00ee0 0x7dc00ee0: _memcpy+0x0660: stda %f32, [%o0] 0xf0 dbx: internal error: signal SIGSEGV (no mapping at the fault address) dbx's coredump will appear in /tmp Abort (core dumped) -bash-3.00$ /import/dr3/s10/gcc-4.2/bin/g++ -v Using built-in specs. Target: sparc-sun-solaris2.10 Configured with: /import/dr2/starlex/1/gcc-4.2-20070228/configure --prefix=/import/dr3/s10/gcc-4.2 --enable-languages=c,c++,fortran --enable-rpath --with-mpfr=/import/dr3/s10/gcc-4.2 --with-gmp=/import/dr3/s10/gcc-4.2 Thread model: posix gcc version 4.2.0 20070228 (prerelease) -- Summary: OpenMP-C++: segmentation fault in basic string constructors Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hailijuan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288
[Bug c++/36288] OpenMP-C++: segmentation fault in basic string constructors
--- Comment #1 from hailijuan at gmail dot com 2008-05-21 08:41 --- Created an attachment (id=15660) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15660&action=view) C++ OpenMP program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288
[Bug c/36351] New: gcc handled OpenMP programs with uplevel reference wrongly
the testcase uplevi.c is to show that for OpenMP programs, gcc reference
uplevel variable by [%fp - 4] in each thread.
micro# cat uplevi.c
int main()
{
int i;
void sub()
{
printf("0x%x\n", &i);
}
#pragma omp parallel num_threads(4)
sub();
return 0;
}
micro# /import/dr3/s10/gcc-4.2/bin/gcc uplevi.c -fopenmp -w
micro# ./a.out
0xfeffbecc
0xfeefbecc
0xffbffa8c
0xff0fbecc
micro# /import/dr3/s10/gcc-4.2/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /import/dr2/starlex/1/gcc-4.2-20070228/configure
--prefix=/import/dr3/s10/gcc-4.2 --enable-languages=c,c++,fortran
--enable-rpath --with-mpfr=/import/dr3/s10/gcc-4.2
--with-gmp=/import/dr3/s10/gcc-4.2
Thread model: posix
gcc version 4.2.0 20070228 (prerelease)
--
Summary: gcc handled OpenMP programs with uplevel reference
wrongly
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36351
[Bug c/36354] New: gcc handled OpenMP programs with uplevel reference wrongly
the testcase uplevi.c is to show that for OpenMP programs, gcc reference
uplevel variable by [%fp - 4] in each thread.
micro# cat uplevi.c
int main()
{
int i;
void sub()
{
printf("0x%x\n", &i);
}
#pragma omp parallel num_threads(4)
sub();
return 0;
}
micro# /import/dr3/s10/gcc-4.2/bin/gcc uplevi.c -fopenmp -w
micro# ./a.out
0xfeffbecc
0xfeefbecc
0xffbffa8c
0xff0fbecc
micro# /import/dr3/s10/gcc-4.2/bin/gcc -v
Using built-in specs.
Target: sparc-sun-solaris2.10
Configured with: /import/dr2/starlex/1/gcc-4.2-20070228/configure
--prefix=/import/dr3/s10/gcc-4.2 --enable-languages=c,c++,fortran
--enable-rpath --with-mpfr=/import/dr3/s10/gcc-4.2
--with-gmp=/import/dr3/s10/gcc-4.2
Thread model: posix
gcc version 4.2.0 20070228 (prerelease)
--
Summary: gcc handled OpenMP programs with uplevel reference
wrongly
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hailijuan at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36354
[Bug middle-end/36288] OpenMP-C++: segmentation fault in basic string constructors
--- Comment #4 from hailijuan at gmail dot com 2008-05-28 08:54 --- Subject: Re: OpenMP-C++: segmentation fault in basic string constructors no. thanks for your comments. i have correct the testcase. the error is gone with gcc-4.2. thanks again. 2008/5/28 pinskia at gcc dot gnu dot org <[EMAIL PROTECTED]>: > > > --- Comment #3 from pinskia at gcc dot gnu dot org 2008-05-28 07:53 > --- > Is there a reason why you think this is well defined code? > > > -- > > pinskia at gcc dot gnu dot org changed: > > What|Removed |Added > > Component|c++ |middle-end > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36288
