[Bug libfortran/37707] Namelist read of array of derived type incorrect
--- Comment #32 from burnus at gcc dot gnu dot org 2008-10-23 06:18 --- (In reply to comment #31) Fixed on trunk, backport to 4.3? I think it is simple enough to be OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37707
regression: definition of system-.h-declared function disables all warnings
When I define a function that is already declared in a system header
file (same signature, of course), all warnings are disabled not only
in that function, but any following function definitions in the same
compilation unit.
For example, with this code,
cat 'EOF' k.c
#include stdlib.h
int clearenv (void) {}
int bar (int i) { return 0; int j; return j; }
EOF
I would expect compiling with -W -Wall -Wdeclaration-after-statement
to warn about the decl-after-stmt and the unused parameter, but get
neither:
$ gcc -O -W -Wall -Wdeclaration-after-statement -c k.c
$ gcc --version
gcc (GCC) 4.3.2 20081007 (Red Hat 4.3.2-6)
gcc-4.2 does what I expect:
$ gcc-4.2 -c -O -W -Wall -Wdeclaration-after-statement random_r.c
random_r.c: In function 'srandom_r':
random_r.c:4: warning: unused parameter 'seed'
random_r.c:4: warning: unused parameter 'buf'
random_r.c: In function 'bar':
random_r.c:15: warning: ISO C90 forbids mixed declarations and code
random_r.c:15: warning: unused variable 'i'
FYI, just filed as:
http://bugzilla.redhat.com/468145
[Bug c++/36391] Compilation never ends
--- Comment #9 from ivan at vc dot cvut dot cz 2008-10-23 07:57 --- Subject: Re: Compilation never ends Quoting manu at gcc dot gnu dot org [EMAIL PROTECTED]: --- Comment #6 from manu at gcc dot gnu dot org 2008-10-21 21:25 --- I cannot compile this testcase with GCC 4.3.2 or a recent revision of GCC 4.4. Could you recreate the prepocessed source with those compilers? I can can confirm, that GCC 4.3.2 compiles that source succefully and very fast. There seem to be some problem with boost library. A newer version of boost is needed to produce preprocessed source. Can can create it if you want. Ivan -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36391 --- You are receiving this mail because: --- You are on the CC list for the bug, or are watching someone who is. You reported the bug, or are watching the reporter. This message was sent using IMP, the Internet Messaging Program. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36391
[Bug c++/37901] New: Fortran compiler bug or lost some files during installation openSuse11.0
Hallo, can you help me?? this bug i have never seen !! email to: [EMAIL PROTECTED] OS: Linux OpenSuse 11.0 This Fortran-program was tested ! program test open(6,file='test.aus') write(6,100) 100 format(10x,'testprogramm') close(6) end Start fortran in Terminal: [EMAIL PROTECTED]:~/programs gcc -o test.out test.for Now the Bug: /usr/lib/gcc/i586-suse-linux/4.3/../../../crt1.o: In function `_start': (.text+0x18): undefined reference to `main' /tmp/ccWiTwqk.o: In function `MAIN__': test.for:(.text+0x19): undefined reference to `_gfortran_set_options' test.for:(.text+0x63): undefined reference to `_gfortran_st_open' test.for:(.text+0xad): undefined reference to `_gfortran_st_write' test.for:(.text+0xbb): undefined reference to `_gfortran_st_write_done' test.for:(.text+0xf1): undefined reference to `_gfortran_st_close' collect2: ld returned 1 exit status end of bug [EMAIL PROTECTED]:~/programs gcc -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=i586-suse-linux Thread model: posix gcc version 4.3.3 20081002 (prerelease) [gcc-4_3-branch revision 140831] (SUSE Linux) kindly W.Patscher -- Summary: Fortran compiler bug or lost some files during installation openSuse11.0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wpatscher at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37901
[Bug java/37893] [4.4 Regression] ICE in java during bootstrap at revision 141303
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-23 07:59 --- I can reproduce this too, on i686-linux, make -j48. gcj is invoked with -fsource-filename=/usr/src/gcc/obj19/i686-pc-linux-gnu/libjava/classpath/tools/all-classes.lst but that file doesn't exist. If you look at the changes Mathias committed yesterday, they are clearly buggy. all-classes.lst is used always: grep all-classes.lst libjava/Makefile* libjava/Makefile.am:libgcj_tools_la_GCJFLAGS = $(AM_GCJFLAGS) -findirect-dispatch -fno-indirect-classes -fsource-filename=$(here)/classpath/tools/all-classes.lst libjava/Makefile.in:libgcj_tools_la_GCJFLAGS = $(AM_GCJFLAGS) -findirect-dispatch -fno-indirect-classes -fsource-filename=$(here)/classpath/tools/all-classes.lst but is only generated in --enable-libjava-maintainer-mode: grep all-classes.lst libjava/classpath/tools/Makefile* libjava/classpath/tools/Makefile.am:cat classes.lst asm.lst vm-tools.lst all-classes.lst libjava/classpath/tools/Makefile.am:rm -rf $(TOOLS_ZIP) classes classes.lst asm asm.lst all-classes.lst libjava/classpath/tools/Makefile.in:@JAVA_MAINTAINER_MODE_TRUE@ cat classes.lst asm.lst vm-tools.lst all-classes.lst libjava/classpath/tools/Makefile.in:rm -rf $(TOOLS_ZIP) classes classes.lst asm asm.lst all-classes.lst Before that commit, it has been generated always. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||doko at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37893
[Bug fortran/37901] Fortran compiler bug or lost some files during installation openSuse11.0
--- Comment #1 from paolo dot carlini at oracle dot com 2008-10-23 08:06 --- If you are compiling Fortran, use gfortran, not gcc. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|c++ |fortran Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37901
[Bug java/37893] [4.4 Regression] ICE in java during bootstrap at revision 141303
--- Comment #3 from jakub at gcc dot gnu dot org 2008-10-23 08:28 --- Patch posted. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||10/msg00978.html Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-10-23 08:28:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37893
[Bug java/37893] [4.4 Regression] ICE in java during bootstrap at revision 141303
--- Comment #4 from jakub at gcc dot gnu dot org 2008-10-23 08:28 --- *** Bug 37899 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37893
[Bug bootstrap/37899] [4.4 Regression]: Gcc failed to bootstrap
--- Comment #2 from jakub at gcc dot gnu dot org 2008-10-23 08:28 --- *** This bug has been marked as a duplicate of 37893 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37899
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #17 from Joey dot ye at intel dot com 2008-10-23 08:42 --- CPU2006/454.calculix has about 10% regression with IRA + core2 + fpmath=sse on Core2 ix86: IRAIRA_core2 NO_IRA_core2 454.calculix 1.00 0.901.01 Revision: trunk 140514 Options in detail: IRA= -m32 -O2 -mssse3 -mfpmath=sse IRA_core2= $IRA -mtune=core2 NO_IRA_core2= $IRA_core2 -fno-ira -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug java/37893] [4.4 Regression] ICE in java during bootstrap at revision 141303
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-23 09:24 --- Subject: Bug 37893 Author: jakub Date: Thu Oct 23 09:23:00 2008 New Revision: 141320 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141320 Log: PR java/37893 * tools/Makefile.am (tools.zip): Generate *.lst files always, not just in JAVA_MAINTAINER_MODE. * tools/Makefile.in: Regenerated. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/tools/Makefile.am trunk/libjava/classpath/tools/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37893
[Bug java/37893] [4.4 Regression] ICE in java during bootstrap at revision 141303
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-23 09:26 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37893
[Bug c++/37741] [C++0x] ICE with shared_ptr in initializer-list of new-expression
--- Comment #2 from florian dot goujeon at wanadoo dot fr 2008-10-23 10:00 --- Seems to be fixed, now. -- florian dot goujeon at wanadoo dot fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37741
[Bug other/37897] decNumber functions break strict-aliasing rules
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-10-23 10:10 --- Branches are likely affected as well. There we might consider just building the affected files with -fno-strict-aliasing? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37897
[Bug middle-end/37902] New: [4.3 Regression] in_system_header bug
See http://gcc.gnu.org/ml/gcc-bugs/2008-10/msg01511.html
/* { dg-options -O -W -Wall -Wdeclaration-after-statement -fpreprocessed }
# 1 my.c 1
# 1 my.h 1 3 4
void foo (void);
# 2 my.c 2
void
foo (void)
{
}
int
bar (void)
{
return 0;
int j;
return j;
}
doesn't warn in bar, supposedly in_system_header hasn't been cleared when done
with foo function.
This is fixed on the trunk supposedly by
http://gcc.gnu.org/ml/gcc-patches/2008-07/msg01264.html
but that patch is definitely not backportable to 4.3 branch.
--
Summary: [4.3 Regression] in_system_header bug
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37902
[Bug middle-end/37902] [4.3 Regression] in_system_header bug
--- Comment #1 from jakub at gcc dot gnu dot org 2008-10-23 12:40 --- The regression has been introduced by PR32256, before that in_system_header flag wasn't saved/restored in push_cfun/pop_cfun. The issue seems to be that allocate_struct_function call in store_parm_decls doesn't seem to have a corresponding set_cfun (NULL); call, so when push_cfun during gimplification is called, it doesn't save in_system_header (as cfun is already non-NULL) and more importantly, pop_cfun at the end of gimplification pops to the same cfun, which means in_system_header remains 1 when leaving the gimplifier and is then used by subsequent parsing of bar function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37902
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #10 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-23
13:25 ---
Subject: Re: [4.4 Regression] Small structs are not passed correctly on
hppa64-*-*
--- function.c.jj10 2008-09-30 16:57:11.0 +0200
+++ function.c 2008-10-22 17:32:26.0 +0200
@@ -2436,7 +2436,9 @@ assign_parm_remove_parallels (struct ass
if (GET_CODE (entry_parm) == PARALLEL GET_MODE (entry_parm) != BLKmode)
{
rtx parmreg = gen_reg_rtx (GET_MODE (entry_parm));
- emit_group_store (parmreg, entry_parm, NULL_TREE,
+ emit_group_store (parmreg, entry_parm,
+ data-nominal_mode == data-passed_mode
+ ? data-passed_type : NULL_TREE,
GET_MODE_SIZE (GET_MODE (entry_parm)));
entry_parm = parmreg;
}
patch fixes this for me (at least, from eyeballing assembly and/or RTL from a
cross compiler), though I'm not sure if data-passed_type or
data-nominal_type
should be used and whether the data-nominal_mode == data-passed_mode guard
is
needed or not.
This fixes the PR. I will try the version without the guard when the
testsuite run completes this morning.
Thanks,
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug fortran/36091] false positive in bounds checking with forall
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-10-23 14:37 --- (In reply to comment #3) I am not 100% sure that the following is due to the patch in comment #1, There is already something wrong on trunk, but I agree that the patch makes it worse. As a side note I'm really impressed by how fast you found a not-working case to my slowly and laboriously prepared code. I've been playing a bit with the testcase on trunk. This: write(*,*) foo([1]+i) produces this code fragment: integer(kind=8) A.4[2]; struct array1_integer(kind=8) atmp.3; atmp.3.dtype = 521; atmp.3.dim[0].stride = 1; atmp.3.dim[0].lbound = 0; atmp.3.dim[0].ubound = 1; atmp.3.data = (void *) A.4; atmp.3.offset = 0; while this: write(*,*) foo(i+[1]) produces this code fragment: integer(kind=8) A.4[1]; struct array1_integer(kind=8) atmp.3; atmp.3.dtype = 521; atmp.3.dim[0].stride = 1; atmp.3.dim[0].lbound = 0; atmp.3.dim[0].ubound = 0; atmp.3.data = (void *) A.4; atmp.3.offset = 0; As you can see, the first case's array temporary has a size of 2, while it should be of size 1. The code however is correct as only the first element of the array is used. With the patch, it is... wrong. To be continued. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #31 from jakub at gcc dot gnu dot org 2008-10-23 15:13 --- Both testcases involve passing of small structures, so might as well be the PA small struct passing bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug tree-optimization/35518] [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above
--- Comment #32 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-23 16:00 --- Subject: Re: [4.4 Regression] FAIL: gcc.c-torture/execute/20040709-1.c execution at -O2 and above Both testcases involve passing of small structures, so might as well be the PA small struct passing bug. Both testcases are fixed by Jakub's proposed fix for PR middle-end/37316. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35518
[Bug middle-end/37320] [4.4 Regression] gcc.dg/compat execute test fails
--- Comment #2 from danglin at gcc dot gnu dot org 2008-10-23 16:04 --- *** This bug has been marked as a duplicate of 37316 *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37320
[Bug middle-end/37318] [4.4 Regression] gcc.dg/compat//scalar-by-value-4_x.c:72: ICE: in emit_group_store, at expr.c:2084
--- Comment #8 from danglin at gcc dot gnu dot org 2008-10-23 16:05 --- *** This bug has been marked as a duplicate of 37316 *** -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37318
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #12 from danglin at gcc dot gnu dot org 2008-10-23 16:05 --- *** Bug 37318 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #11 from danglin at gcc dot gnu dot org 2008-10-23 16:04 --- *** Bug 37320 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #13 from danglin at gcc dot gnu dot org 2008-10-23 16:15 --- Looking at the test results with the fix proposed in comment #10, I see we still have the failure of the following two tests: FAIL: gcc.dg/compat/scalar-by-value-4 c_compat_x_tst.o-c_compat_y_tst.o execute FAIL: gcc.dg/compat/struct-by-value-12 c_compat_x_tst.o-c_compat_y_tst.o execute See http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01604.html. This didn't happen with Daniel's changes reverted. See for example http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01144.html. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug other/37897] decNumber functions break strict-aliasing rules
--- Comment #2 from janis at gcc dot gnu dot org 2008-10-23 16:16 --- The code in question is in the 4.3 branch but not 4.2. The changes are very minimal, so the patch is probably appropriate for the 4.3 branch. I had already planned to ask to put it there as well as mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37897
[Bug fortran/37903] New: wrong-code for complicated vector subscripts
Modified code from a comment for PR36091 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091#c3 integer :: i(-1:1) = 1, j(3) = 1, k(3) k = j((/1,1,1/)+i) end Wrong code, the temporary array generated is too small. -- Summary: wrong-code for complicated vector subscripts Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael dot morin at tele2 dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug c++/37904] New: internal compiler error: Segmentation fault (C++ destructor)
The g++ compiler reports the error internal compiler error: Segmentation fault when the attached (reduced) file is compiled. The fault seems to depend on inclusion of a destructor (last (only) method in the file). If the destructor is omitted, the file compiles. The error originally occurred when a single space was added to a string -- the attached, preprocessed, file was reduced from the original by a process of elimination. g++ version info: g++ (GCC) 4.3.0 20080428 (Red Hat 4.3.0-8) I have not been able to test this on a later version of the compiler. Attached file: gcc_fault_example.ii(preprocessed) -- Summary: internal compiler error: Segmentation fault (C++ destructor) 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 roden at wanadoo dot fr GCC host triplet: i686-pc-linux GCC target triplet: i686-pc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37904
[Bug c++/37904] internal compiler error: Segmentation fault (C++ destructor)
--- Comment #1 from john dot roden at wanadoo dot fr 2008-10-23 19:01 --- Created an attachment (id=16533) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16533action=view) Test Case -- preprocessed code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37904
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #9 from lucier at math dot purdue dot edu 2008-10-23 19:20 --- I bootstrapped and regtested the suggested patch. There was one fewer FAIL in the gcc tests: FAIL: gcc.c-torture/execute/nestfunc-6.c execution, -O0 and one more failure in the libgomp tests: FAIL: libgomp.fortran/crayptr2.f90 -O3 -fomit-frame-pointer -funroll-loops execution test However, it's not clear to me from the output of gdb implies that this may is a problem with the compiled code (the command lines are taken from the log file): [descartes:powerpc64-apple-darwin9.5.0/libgomp/testsuite] lucier% /Users/lucier/programs/gcc/objdirs/mainline/gcc/xgcc -B/Users/lucier/programs/gcc/objdirs/mainline/gcc/ /Users/lucier/programs/gcc/mainline/libgomp/testsuite/libgomp.fortran/crayptr2.f90 -B/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/./libgomp/ -I/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/./libgomp -I/Users/lucier/programs/gcc/mainline/libgomp/testsuite/.. -shared-libgcc -fmessage-length=0 -fopenmp -O3 -fomit-frame-pointer -funroll-loops -fopenmp -fcray-pointer -static-libgcc -L/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/./libgomp/.libs -lgomp -L/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/./libgomp/../libgfortran/.libs -lgfortranbegin -lgfortran -lm -mcpu=970 -m64 -o ./crayptr2.exe [descartes:powerpc64-apple-darwin9.5.0/libgomp/testsuite] lucier% env LD_LIBRARY_PATH=.:/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/./libgomp/.libs:/Users/lucier/programs/gcc/objdirs/mainline/gcc:/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/./libgomp/../libgfortran/.libs:.:/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/./libgomp/.libs:/Users/lucier/programs/gcc/objdirs/mainline/gcc:/Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/./libgomp/../libgfortran/.libs gdb ./crayptr2.exe GNU gdb 6.3.50-20050815 (Apple version gdb-962) (Sat Jul 26 08:17:57 UTC 2008) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as powerpc-apple-darwin...Reading symbols for shared libraries done (gdb) run Starting program: /Users/lucier/programs/gcc/objdirs/mainline/powerpc64-apple-darwin9.5.0/libgomp/testsuite/crayptr2.exe warning: posix_spawn failed, trying execvp, error: 86 Reading symbols for shared libraries +++.. done Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x 0x00011678 in MAIN__.omp_fn.0 () (gdb) where #0 0x00011678 in MAIN__.omp_fn.0 () #1 0x0001187c in MAIN__ () #2 0x000118e4 in main (argc=1, argv=value temporarily unavailable, due to optimizations) at ../../../../mainline/libgfortran/fmain.c:21 It is completely reproducible, however. Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug libgcj/37893] [4.4 Regression] ICE in java during bootstrap at revision 141303
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|java|libgcj Keywords||build Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37893
[Bug middle-end/37886] [graphite] ICE: Segmentation fault
--- Comment #5 from grosser at gcc dot gnu dot org 2008-10-23 20:04 --- Subject: Bug 37886 Author: grosser Date: Thu Oct 23 20:02:59 2008 New Revision: 141328 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141328 Log: 2008-10-23 Tobias Grosser [EMAIL PROTECTED] PR middle-end/37886 * graphite.c (gloog): Replace EXIT_BLOCK_PTR with scop exit. Modified: branches/graphite/gcc/ChangeLog.graphite branches/graphite/gcc/graphite.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37886
[Bug middle-end/37851] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3617
--- Comment #3 from grosser at gcc dot gnu dot org 2008-10-23 20:09 --- It seems we do not have implemented all cases in expand_scalar_variables_expr() Backtrace for f951 -O2 -fgraphite-identity. #1 0x081f3461 in fancy_abort (file=Could not find the frame base for fancy_abort. ) at ../../../git/gcc/diagnostic.c:712 #2 0x08a11e58 in expand_scalar_variables_expr (type=0x290a42d8, op0=0x290d09b0, code=COMPONENT_REF, op1=0x0, gbb=0x8e32fa0, scop=0x8e0df10, old_loop_father=0x29140160) at ../../../git/gcc/graphite.c:3617 #3 0x08a11e37 in expand_scalar_variables_expr (type=0x290a42d8, op0=0x29131738, code=SSA_NAME, op1=0x0, gbb=0x8e32fa0, scop=0x8e0df10, old_loop_father=0x29140160) at ../../../git/gcc/graphite.c:3612 #4 0x08a11ef4 in expand_scalar_variables_stmt (stmt=0x291283c0, gbb=0x8e32fa0, scop=0x8e0df10, old_loop_father=0x29140160) at ../../../git/gcc/graphite.c:3639 #5 0x08a12083 in expand_scalar_variables (gbb=0x8e32fa0, scop=0x8e0df10, old_loop_father=0x29140160) at ../../../git/gcc/graphite.c:3666 #6 0x08a125bb in translate_clast (scop=0x8e0df10, context_loop=0x291331b8, stmt=0x8ed2450, next_e=0x29143938, ivstack=0xbfbfe8c0) at ../../../git/gcc/graphite.c:3791 #7 0x08a128bd in translate_clast (scop=0x8e0df10, context_loop=0x291331b8, stmt=0x8e9c540, next_e=0x29135d70, ivstack=0xbfbfe8c0) at ../../../git/gcc/graphite.c:3843 #8 0x08a1253d in translate_clast (scop=0x8e0df10, context_loop=0x291331b8, stmt=0x8eb1ff0, next_e=0x29135d70, ivstack=0xbfbfe8c0) at ../../../git/gcc/graphite.c:3777 #9 0x08a147b2 in gloog (scop=0x8e0df10, stmt=0x8eb1ff0) at ../../../git/gcc/graphite.c:4366 Here we miss: COMPONENT_REF -- grosser at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |grosser at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-10-22 20:05:58 |2008-10-23 20:09:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37851
[Bug middle-end/37851] [graphite] ICE in expand_scalar_variables_expr, at graphite.c:3617
--- Comment #4 from grosser at gcc dot gnu dot org 2008-10-23 20:11 --- Created an attachment (id=16534) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16534action=view) Testcase fails because of missing INDIRECT_REF #0 internal_error (gmsgid=0x8ae0d27 in %s, at %s:%d) at ../../../git/gcc/diagnostic.c:656 #1 0x081d0c01 in fancy_abort (file=Could not find the frame base for fancy_abort. ) at ../../../git/gcc/diagnostic.c:712 #2 0x089d98c8 in expand_scalar_variables_expr (type=0x290f4820, op0=0x29073b20, code=INDIRECT_REF, op1=0x0, gbb=0x8d32400, scop=0x8d320a0, old_loop_father=0x29106d68) at ../../../git/gcc/graphite.c:3617 #3 0x089d98a7 in expand_scalar_variables_expr (type=0x290f4820, op0=0x29104348, code=SSA_NAME, op1=0x0, gbb=0x8d32400, scop=0x8d320a0, old_loop_father=0x29106d68) at ../../../git/gcc/graphite.c:3612 #4 0x089d9964 in expand_scalar_variables_stmt (stmt=0x290f73c0, gbb=0x8d32400, scop=0x8d320a0, old_loop_father=0x29106d68) at ../../../git/gcc/graphite.c:3639 #5 0x089d9af3 in expand_scalar_variables (gbb=0x8d32400, scop=0x8d320a0, old_loop_father=0x29106d68) at ../../../git/gcc/graphite.c:3666 #6 0x089da02b in translate_clast (scop=0x8d320a0, context_loop=0x29106f20, stmt=0x8d8cd10, next_e=0x2910d050, ivstack=0xbfbfe880) at ../../../git/gcc/graphite.c:3791 #7 0x089da24b in translate_clast (scop=0x8d320a0, context_loop=0x29106d10, stmt=0x8d33d00, next_e=0x290c2ac8, ivstack=0xbfbfe880) at ../../../git/gcc/graphite.c:3827 #8 0x089d9fad in translate_clast (scop=0x8d320a0, context_loop=0x29106d10, stmt=0x8d8c5d0, next_e=0x290c2ac8, ivstack=0xbfbfe880) at ../../../git/gcc/graphite.c:3777 #9 0x089dc222 in gloog (scop=0x8d320a0, stmt=0x8d8c5d0) at ../../../git/gcc/graphite.c:4366 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37851
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #1 from burnus at gcc dot gnu dot org 2008-10-23 20:11 --- Works with 4.1/4.2... -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-10-23 20:11:43 date|| Summary|wrong-code for complicated |[4.3/4.4 Regression] wrong- |vector subscripts |code for complicated vector ||subscripts http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #14 from jakub at gcc dot gnu dot org 2008-10-23 20:25 --- Can you please look at the testcases why they fail (what is passed differently) and try to minimize them as much as possible? Finding a bug in RTL or assembly without knowing what you are looking for is certainly harder than when you have a debugger and can see what is passed differently... Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #2 from dominiq at lps dot ens dot fr 2008-10-23 20:30 --- Modified code from a comment for PR36091 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091#c3 First the code came from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31610#c16 Second, if I change the lower bound of 'i' as in integer :: i(-9:1) = 1, j(11) = 1, k(11) k = j((/1,1,1,1,1,1,1,1,1,1,1/)+i) print *, k end the size of the temporary does not change: the lower bound is probably not taken into account. Third 4.2 uses 2 temporaries (of the right size). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug fortran/36091] false positive in bounds checking with forall
--- Comment #5 from dominiq at lps dot ens dot fr 2008-10-23 20:34 --- As a side note I'm really impressed by how fast you found a not-working case to my slowly and laboriously prepared code. Don't worry, it is always much easier to find (others') bugs than to fix them. The problem was detected by my own quick and dirty test suite which cover some cases not covered by the gfortran one. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36091
[Bug middle-end/37316] [4.4 Regression] Small structs are not passed correctly on hppa64-*-*
--- Comment #15 from dave at hiauly1 dot hia dot nrc dot ca 2008-10-23 20:47 --- Subject: Re: [4.4 Regression] Small structs are not passed correctly on hppa64-*-* Can you please look at the testcases why they fail (what is passed differently) and try to minimize them as much as possible? Finding a bug in RTL or assembly without knowing what you are looking for is certainly harder than when you have a debugger and can see what is passed differently... Will do. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37316
[Bug target/37878] [4.4 regression] PPC64 ldu command generated with invalid offset
--- Comment #10 from lucier at math dot purdue dot edu 2008-10-23 21:25 --- This patch fixes my original problem and the reduced test case. The two testresults reports I referred to earlier are at http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01616.html and http://gcc.gnu.org/ml/gcc-testresults/2008-10/msg01427.html Thanks! Brad -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37878
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #3 from mikael dot morin at tele2 dot fr 2008-10-23 21:27
---
Quickfix (understand: not regression tested):
Index: trans-array.c
===
--- trans-array.c (révision 141321)
+++ trans-array.c (copie de travail)
@@ -3380,7 +3380,7 @@
{
/* The frontend has worked out the size for us. */
loopspec[n] = ss;
- continue;
+ break;
}
if (ss-type == GFC_SS_CONSTRUCTOR)
This forces to use the array constructor's ss to setup the loop.
As it is zero-based, the upper bounds has the proper value and the array has
the proper size.
I suspect this is only hiding the problem though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug rtl-optimization/37363] [4.4 Regression] Fix for PR 36090 causes libstdc++ regressions
--- Comment #5 from rsandifo at gcc dot gnu dot org 2008-10-23 22:07 --- Ooops, I should have claimed this PR sooner. As HP says, I have the ball, unless or until the approach I'm advocating is rejected. HP linked to the proposed patches. I can't really submit them in good conscience until the following ARM patch is sorted out: http://gcc.gnu.org/ml/gcc-patches/2008-10/msg00456.html I've pinged the patch a couple of times now. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-09-04 10:01:47 |2008-10-23 22:07:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37363
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #4 from mikael dot morin at tele2 dot fr 2008-10-23 22:31 --- There is this comment at the beginning of gfc_trans_create_temp_array. /* TODO: Investigate why if (n loop-temp_dim) gcc_assert (integer_zerop (loop-from[n])); fails here. */ This is the case here: n=0, loop-temp_dim=1, loop.from[0]=lbound(i)=-1 I don't understand the use of the (n = loop-temp_dim) condition preventing the loop bounds from being moved (to be zero-based). The problem arises farther in the function, when gfc_index_zero_node is used instead of loop.from, and only the (wrong) loop.to is taken into account. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
[Bug middle-end/37882] [4.3/4.4 Regression] Bitfield miscompilation
--- Comment #6 from eric dot weddington at atmel dot com 2008-10-23 23:21 --- New test case fails for AVR target, as test case assumes that an integer is 32-bits. An integer on the AVR is 16 bits and the test case fails for -O[0123s] with: /gcc/testsuite/gcc.c-torture/execute/pr37882.c:5: error: width of 'a' exceeds its type -- eric dot weddington at atmel dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37882
[Bug middle-end/37882] [4.3/4.4 Regression] Bitfield miscompilation
--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-23 23:33 --- Guess you can leave the int a : 21; line completely out, the testcase used to fail apparently even without that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37882
[Bug c/456] constant expressions constraints (gcc.dg/c90-const-expr-1)
--- Comment #14 from jsm28 at gcc dot gnu dot org 2008-10-24 00:06 --- Testing a patch for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-10 04:20:41 |2008-10-24 00:06:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=456
[Bug c/5675] const variables wrongly considered part of constant expressions (gcc.dg/c9[09]-const-expr-3.c)
--- Comment #12 from jsm28 at gcc dot gnu dot org 2008-10-24 00:06 --- Testing a patch for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-10 05:43:26 |2008-10-24 00:06:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5675
[Bug c/19976] integer division by zero in subexpression should be overflow
--- Comment #11 from jsm28 at gcc dot gnu dot org 2008-10-24 00:07 --- Testing a patch for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-12-18 01:39:17 |2008-10-24 00:07:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19976
[Bug c/29116] Failure to diagnose violation of constraint 6.7.5.2p2
--- Comment #3 from jsm28 at gcc dot gnu dot org 2008-10-24 00:08 --- Testing a patch for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-09-17 15:26:28 |2008-10-24 00:08:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29116
[Bug c/31871] C99 failure to diagnose non-integer cast
--- Comment #3 from jsm28 at gcc dot gnu dot org 2008-10-24 00:08 --- Testing a patch for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-24 03:46:49 |2008-10-24 00:08:51 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31871
[Bug c/35198] [4.2/4.3/4.4 Regression] missed evaluation of VM array type when used as a cast
--- Comment #8 from jsm28 at gcc dot gnu dot org 2008-10-24 00:09 --- Testing a patch for 4.5. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-02-14 21:42:39 |2008-10-24 00:09:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35198
build gcc-4.4.0 20081022 failed on loongson2f
Hello, When I try to build gcc-4.4.0 20081022 on loongson2f machine, an error occurs on the stage3, /home/xmj/tools/build-svn-gcc/./prev-gcc/xgcc -B/home/xmj/tools/build-svn-gcc/./prev-gcc/ -B/home/xmj/install/svn-gcc/mipsel-linux/bin/ -c -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../svn-gcc/gcc -I../../svn-gcc/gcc/. -I../../svn-gcc/gcc/../include -I../../svn-gcc/gcc/../libcpp/include -I/home/xmj/install/gmp-4.2.2//include -I/home/xmj/install/mpfr-2.3.1//include -I../../svn-gcc/gcc/../libdecnumber -I../../svn-gcc/gcc/../libdecnumber/dpd -I../libdecnumber ../../svn-gcc/gcc/sel-sched.c -o sel-sched.o In file included from ../../svn-gcc/gcc/sel-sched.c:50: ../../svn-gcc/gcc/sel-sched-ir.h: In function 'T.2585': ../../svn-gcc/gcc/sel-sched-ir.h:1312: 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. make[3]: *** [sel-sched.o] Error 1 make[3]: Leaving directory `/home/xmj/tools/build-svn-gcc/gcc' make[2]: *** [all-stage3-gcc] Error 2 make[2]: Leaving directory `/home/xmj/tools/build-svn-gcc' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/xmj/tools/build-svn-gcc' make: *** [all] Error 2 Gcc is configured with, [EMAIL PROTECTED]:build-svn-gcc$ prev-gcc/xgcc -v Using built-in specs. Target: mipsel-linux Configured with: ../svn-gcc/configure --prefix=/home/xmj/install/svn-gcc --build=mipsel-linux --host=mipsel-linux --target=mipsel-linux --enable-languages=c,c++ --with-gmp=/home/xmj/install/gmp-4.2.2/ --with-mpfr=/home/xmj/install/mpfr-2.3.1/ Thread model: posix gcc version 4.4.0 20081022 (experimental) (GCC) $uname -a Linux tini-boy 2.6.18.1-fl2f-pc-v1.1.0 #66 Fri Sep 12 13:03:52 EDT 2008 mips64 GNU/Linux Is it a bug? Eric Fisher 2008-10-24
[Bug target/37905] New: m68k coldfire uses bad mode when extending long long
Compile the following code with: m68k-elf-gcc -c -O2 -mcpu=5272 lltest.c
--save-temps -v
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
long long fred;
void broken(int b)
{
fred = (long long)b;
}
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
The assembler will correctly report:
lltest.s:9: Error: operands mismatch -- statement `move.l 8(%fp),fred+4'
ignored
This is because this combination of modes ( move.l (d16,Ax),(xxx).L ) is
invalid on coldfires. You'll get the same error if you specify a different cpu.
The problem is in extendsidi2_mem in m68k.md. The change was introduced by
Roman Zippel here: http://gcc.gnu.org/ml/gcc-patches/2007-01/msg02475.html
I was able to work around the problem, and will attach the patch. The patch may
not be ideal in all circumstances but I believe it does fix the problem.
Jifl
--
Summary: m68k coldfire uses bad mode when extending long long
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jifl-bugzilla at jifvik dot org
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: m68k-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37905
[Bug target/37905] m68k coldfire uses bad mode when extending long long
--- Comment #1 from jifl-bugzilla at jifvik dot org 2008-10-24 02:39 --- Created an attachment (id=16535) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16535action=view) Fix/workaround -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37905
[Bug java/35485] libjava is disabled by default
--- Comment #4 from dje at gcc dot gnu dot org 2008-10-24 02:45 --- Subject: Bug 35485 Author: dje Date: Fri Oct 24 02:44:26 2008 New Revision: 141335 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141335 Log: PR target/35485 * configure.ac: AIX threads are Posix threads. Set signal handler to aix-signal.h * configure: Regenerate. * classpath/native/fdlibm/fdlibm.h: Undef hz. * include/aix-signal.h: New file. * sysdep/powerpc/locks.h: Avoid GNU Assembler syntax. Added: trunk/libjava/include/aix-signal.h Modified: trunk/libjava/ChangeLog trunk/libjava/classpath/native/fdlibm/fdlibm.h trunk/libjava/configure trunk/libjava/configure.ac trunk/libjava/sysdep/powerpc/locks.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35485
[Bug libstdc++/37906] New: has_trivial_default_constructor vs. deleted copy ctor
The following:
#include type_traits
struct b
{
b() = default;
b(const b) = delete;
};
void test01()
{
typedef b test_type;
// typedef std::is_standard_layouttest_type standard_layout_p;
typedef std::has_trivial_default_constructortest_type ctor_p;
typedef std::has_trivial_destructortest_type dtor_p;
// static_assert(standard_layout_p::value, not standard_layout);
static_assert(ctor_p::value, default ctor not trivial);
static_assert(dtor_p::value, dtor not trivial);
}
Gives:
%$bld/H-x86-gcc.20081020/bin/g++ -std=gnu++0x -c standard_layout.cc
standard_layout.cc: In function 'void test01()':
standard_layout.cc:40: error: static assertion failed: default ctor not
trivial
Removing the copy constructor makes the error go away.
--
Summary: has_trivial_default_constructor vs. deleted copy ctor
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
GCC host triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37906
[Bug libstdc++/37907] New: type_trait: missing is_standard_layout
Already known, can be considered a feature request.
#include type_traits
struct b
{
int b;
b() = default;
b(const b) = delete;
};
void test01()
{
typedef b test_type;
typedef std::is_standard_layouttest_type standard_layout_p;
static_assert(standard_layout_p::value, not standard_layout);
}
--
Summary: type_trait: missing is_standard_layout
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bkoz at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37907
[Bug c/37908] New: atomic NAND op generate wrong code; __sync_nand_and_fetch, __sync_fetch_and_nand
Hello,
I discovered a failure relating to atomic NAND operation on x86 platform,
which can be confirmed using the included test-case. The test was done with
gcc 4.2.4, using 8-, 16-, 32- and 64-bit data width. Test cases on other logic
atomic operators passes all width-size except NAND. I have read through the
assembly code generated and confirm that some wrong codes are generated when
no-optimization and -O.
I ) Test case :
/*
Compile using:
gcc -c -march=i686 test.c
To get assembly listing:
gcc -S -march=i686 test.c
To get mix c and assembly listing:
gcc -c -g -Wa,-a,-ad -march=i686 test.c test-xxx.lst
*/
#include stddef.h
#include stdlib.h
#include stdio.h
typedef unsigned char BYTE;
typedef unsigned short WORD;
typedef unsigned long DWORD;
typedef unsigned long long QWORD;
int main(void)
{
WORD xLoc; /* change xLoc type to BYTE, WORD, DWORD, QWORD to test
different data-width */
typeof(xLoc)xIn, xOut, xExpect, i = 1;
xLoc = xIn = (typeof(xIn)) ~ (1i);
xExpect = (typeof(xIn)) ~(xIn ((typeof(xIn)) 0x7F));
/* Both __sync_nand_and_fetch and __sync_fetch_and_nand have the same
problem */
xOut = __sync_nand_and_fetch(xLoc, (typeof(xIn)) 0x7F);
if (xOut!=xExpect)
printf(__sync_nand_and_fetch():; wrong result; i(%d) xIn(%x)
xExpect(%x) xOut(%x) xLoc(%x)\n,
i, xIn, xExpect, xOut, xLoc);
return 0;
}
II ) Output of gcc -v -save-temps
gcc -o test_bug -v -save-temps -march=i686 test_nand_bug.c
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.2.4/configure --prefix=/opt/gcc-4.2.4
--host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
Thread model: posix
gcc version 4.2.4
/opt/gcc-4.2.4/libexec/gcc/i686-pc-linux-gnu/4.2.4/cc1 -E -quiet -v
test_nand_bug.c -march=i686 -fpch-preprocess -o test_nand_bug.i
ignoring nonexistent directory
/opt/gcc-4.2.4/lib/gcc/i686-pc-linux-gnu/4.2.4/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/include
/opt/gcc-4.2.4/include
/opt/gcc-4.2.4/lib/gcc/i686-pc-linux-gnu/4.2.4/include
/usr/include
End of search list.
/opt/gcc-4.2.4/libexec/gcc/i686-pc-linux-gnu/4.2.4/cc1 -fpreprocessed
test_nand_bug.i -quiet -dumpbase test_nand_bug.c -march=i686 -auxbase
test_nand_bug -version -o test_nand_bug.s
GNU C version 4.2.4 (i686-pc-linux-gnu)
compiled by GNU C version 4.2.4.
GGC heuristics: --param ggc-min-expand=47 --param ggc-min-heapsize=32052
Compiler executable checksum: 383821529167afc2e47a93836e3831a4
as -V -Qy -o test_nand_bug.o test_nand_bug.s
GNU assembler version 2.13.90.0.18 (i386-redhat-linux) using BFD version
2.13.90.0.18 20030206
/opt/gcc-4.2.4/libexec/gcc/i686-pc-linux-gnu/4.2.4/collect2 --eh-frame-hdr -m
elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o test_bug /usr/lib/crt1.o
/usr/lib/crti.o /opt/gcc-4.2.4/lib/gcc/i686-pc-linux-gnu/4.2.4/crtbegin.o
-L/opt/gcc-4.2.4/lib/gcc/i686-pc-linux-gnu/4.2.4
-L/opt/gcc-4.2.4/lib/gcc/i686-pc-linux-gnu/4.2.4/../../.. test_nand_bug.o -lgcc
-lgcc_eh -lc -lgcc -lgcc_eh
/opt/gcc-4.2.4/lib/gcc/i686-pc-linux-gnu/4.2.4/crtend.o /usr/lib/crtn.o
--
Summary: atomic NAND op generate wrong code;
__sync_nand_and_fetch, __sync_fetch_and_nand
Product: gcc
Version: 4.2.4
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kokseng at ieee dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37908
[Bug fortran/37903] [4.3/4.4 Regression] wrong-code for complicated vector subscripts
--- Comment #5 from dominiq at lps dot ens dot fr 2008-10-24 05:48 --- Quickfix (understand: not regression tested): ... With the patch the temporary has the right size, but there is one regression: FAIL: gfortran.dg/array_constructor_15.f90 -O scan-tree-dump-times original atmp 0 If I understand the test correctly, it just checks that no temporary has been created. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37903
