[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-12 07:00 --- I'm not convinced that external (without pointer attribute) objects are allowed in the shared etc. clause lists. The OpenMP 3.0 standard says that a list item is a variable name or common block name. And the definition of variable is: "A named data storage block, whose value can be defined and redefined during the execution of a program." Does integer, external :: f satisfy this? What would it mean whether f is shared, private etc.? All you can do with that is call it. On the other side, integer, pointer, external :: fp I'd say is a variable, but internally in gfortran is FL_PROCEDURE too. The pointer can be changed to point to some other procedure, has associated storage, etc. So I guess a patch like #c1 that allows attr.external attr.pointer FL_PROCEDUREs. is something we want to do. Bu -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||longb at cray dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV
--- Comment #1 from fierevere at mail dot ru 2010-05-12 07:01 ---
Created an attachment (id=20640)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20640&action=view)
this file triggers ICE in cc1plus
i have exactly the same, affects 4.5.0 release and current gcc-4_5-branch
../${SRCDIR}/configure --prefix=/usr/local/gcc-4.5 --host=i586-sylvia-linux
--build=i586-sylvia-linux --with-pkgversion=/argenta/ --disable-nls
--with-cpu=pentium4 --with-arch=pentium4 --enable-languages=c,c++
--enable-threads --enable-tls
--with-host-libstdcxx='/usr/local/gcc-4.5/lib/libstdc++.a -lm'
--with-gmp=/var/tmp --with-mpfr=/var/tmp --with-ppl=/var/tmp
--with-cloog=/var/tmp --with-mpc=/var/tmp --with-libelf=/var/tmp --enable-lto
--with-fpmath=sse
libtool: compile: /var/tmp/gccbuild/./gcc/xgcc -shared-libgcc
-B/var/tmp/gccbuild/./gcc -nostdinc++
-L/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/src
-L/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/src/.libs
-B/usr/local/gcc-4.5/i586-sylvia-linux/bin/
-B/usr/local/gcc-4.5/i586-sylvia-linux/lib/ -isystem
/usr/local/gcc-4.5/i586-sylvia-linux/include -isystem
/usr/local/gcc-4.5/i586-sylvia-linux/sys-include
-I/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/include/i586-sylvia-linux
-I/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/include
-I/var/tmp/gcc-4.5.1pre_100512_r159302/libstdc++-v3/libsupc++
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -O2 -g
-march=pentium4 -D_GNU_SOURCE -c
../../../../gcc-4.5.1pre_100512_r159302/libstdc++-v3/src/pool_allocator.cc
-fPIC -DPIC -o .libs/pool_allocator.o
In file included from
../../../../gcc-4.5.1pre_100512_r159302/libstdc++-v3/src/pool_allocator.cc:31:0:
/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/include/ext/pool_allocator.h:
In constructor '__gnu_cxx::__pool_alloc<_Tp>::__pool_alloc() [with _Tp =
char]':
../../../../gcc-4.5.1pre_100512_r159302/libstdc++-v3/src/pool_allocator.cc:171:18:
instantiated from here
/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/include/ext/pool_allocator.h:140:30:
internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
make[4]: *** [pool_allocator.lo] Error 1
make[4]: Leaving directory
`/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3/src'
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory `/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3'
make[2]: *** [all] Error 2
make[2]: Leaving directory `/var/tmp/gccbuild/i586-sylvia-linux/libstdc++-v3'
make[1]: *** [all-target-libstdc++-v3] Error 2
make[1]: Leaving directory `/var/tmp/gccbuild'
make: *** [profiledbootstrap] Error 2
line 171: pool_allocator.cc
template class __pool_alloc;
line 140: pool_allocator.h
__pool_alloc() throw() { }
backtrace:
(gdb) set args -fpreprocessed pool_allocator.ii -quiet -dumpbase
pool_allocator.ii -march=pentium4 -auxbase pool_allocator -g -O2 -Wall -Wextra
-Wwrite-strings -Wcast-qual -version -fno-implicit-templates
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o
assembl.s
(gdb) show args
Argument list to give program being debugged when it is started is
"-fpreprocessed pool_allocator.ii -quiet -dumpbase pool_allocator.ii
-march=pentium4 -auxbase pool_allocator -g -O2 -Wall -Wextra -Wwrite-strings
-Wcast-qual -version -fno-implicit-templates -fdiagnostics-show-location=once
-ffunction-sections -fdata-sections -o assembl.s".
(gdb) run
Starting program: /tmp/cc1plus -fpreprocessed pool_allocator.ii -quiet
-dumpbase pool_allocator.ii -march=pentium4 -auxbase pool_allocator -g -O2
-Wall -Wextra -Wwrite-strings -Wcast-qual -version -fno-implicit-templates
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections -o
assembl.s
GNU C++ /argenta/ version 4.5.1 (i586-sylvia-linux)
compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ /argenta/ version 4.5.1 (i586-sylvia-linux)
compiled by GNU C version 4.5.1, GMP version 4.3.2, MPFR version 2.4.2,
MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 4b0d4a6436cff7650a243477151f465b
Program received signal SIGSEGV, Segmentation fault.
0x083b5d5a in build_new_method_call.clone.3 ()
(gdb) bt
#0 0x083b5d5a in build_new_method_call.clone.3 ()
#1 0x in ?? ()
(gdb)
not very long because on my gentoo system everything has been compiled with
-fomit-frame-pointer, but this GCC build which is "-O2 -g -march=pentium4",
with any other flags there is same ICE too
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085
[Bug c++/43085] Make profiledbootstrap fails with cc1plus catching SIGSEGV
--- Comment #2 from fierevere at mail dot ru 2010-05-12 07:05 --- Please change: component to bootstrap Host/Target and Build to i686-pc-linux-gnu set higher priority and severity, this problem makes profiledbootstrap make target unable to build and FDO-built GCC unusable, its definitely not "normal" severity and not really a P3 prio ! Tested on current rev 159302 from svn branches/gcc-4_5-branch -- fierevere at mail dot ru changed: What|Removed |Added CC||fierevere at mail dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43085
[Bug c/44091] New: [ARM/Thumb] Invalid stack frame usage at -Os
GCC generates an invalid stack frame usage sequence in a function epilogue.
Function prologue with comments:
.align 2
.global rtems_bdbuf_read
.code 16
.thumb_func
.type rtems_bdbuf_read, %function
rtems_bdbuf_read:
push{r4, r5, r6, r7, lr}
sub sp, sp, #60
add r7, sp, #8
/*
* We have now reserved a stack frame in a two step process. The
* non-volatile register r7 will be use as an local variable anchor.
*/
str r3, [r7, #4]
mov r3, #0
str r3, [r7, #48]
str r3, [r7, #44]
str r3, [r7, #40]
mov r3, r7
add r3, r3, #44
str r3, [sp]
sub r3, r3, #4
str r3, [sp, #4]
add r3, r3, #8
bl rtems_bdbuf_obtain_disk
str r0, [r7, #12]
cmp r0, #0
beq .LCB3661
b .L520 @long jump
.LCB3661:
Function epilogue with comments:
.L520:
mov sp, r7
add sp, sp, #52
/*
* Here we released the second part of our stack frame which contains
* local variables.
*/
ldr r0, [r7, #12]
/*
* Here we used the second part of our stack frame which contains local
* variables. We read a status variable from the stack frame that will
* be returned now. That means we use a part of the frame that we
* already released. In case an interrupt happens between these two
* instructions (add and ldr) we may have a big problem. These two
* instructions are in the wrong order, the reverse order is correct.
*/
@ sp needed for prologue
pop {r4, r5, r6, r7, pc}
Attached files follow.
--
Summary: [ARM/Thumb] Invalid stack frame usage at -Os
Product: gcc
Version: 4.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebastian dot huber at embedded-brains dot de
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: arm-rtems4.10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #1 from sebastian dot huber at embedded-brains dot de 2010-05-12 07:21 --- Created an attachment (id=20641) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20641&action=view) Log. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #2 from sebastian dot huber at embedded-brains dot de 2010-05-12 07:21 --- Created an attachment (id=20642) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20642&action=view) Preprocessed source file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #3 from sebastian dot huber at embedded-brains dot de 2010-05-12 07:22 --- Created an attachment (id=20643) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20643&action=view) Generated assembler file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #4 from burnus at gcc dot gnu dot org 2010-05-12 07:52 --- For information: Pathscale 3.2.99 and 3.9.99 and Portland pgf90 10.1-0 compile it without showing an error/warning. Using the Intel Fortran Compiler 11.1 (20090630), one gets: test.f90(10): error #6429: This name has already been used as a dummy function name. [F] !$OMP shared (a,n,f) --^ test.f90(10): error #7655: A variable is required in this OpenMP context. [F] !$OMP shared (a,n,f) --^ Sun Studio 12 and 12.1 (8.4 2009/06/03) show: !$OMP shared (a,n,f) ^ "test.f90", Line = 10, Column = 19: WARNING: Object F must be a variable to be in the SHARED clause of the PARALLEL directive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #5 from burnus at gcc dot gnu dot org 2010-05-12 08:13 --- (In reply to comment #4) > Using the Intel Fortran Compiler 11.1 (20090630), one gets: > test.f90(10): error #7655: A variable is required in this OpenMP context. Ditto for procedure pointers. > Sun Studio 12 and 12.1 (8.4 2009/06/03) show: Does not support procedure pointers. (In reply to comment #3) > I'm not convinced that external (without pointer attribute) objects are > allowed > in the shared etc. clause lists. The OpenMP 3.0 standard says that a list > item > is a variable name or common block name. And the definition of variable is: > "A named data storage block, whose value can be defined and redefined during > the execution of a program." (OpenMPv3, "1.2.4 Data Terminology") > On the other side, > integer, pointer, external :: fp > I'd say is a variable, but internally in gfortran is FL_PROCEDURE too. I think in terms of the Fortran standard it is not a variable: "A variable is either the data object denoted by designator or the target of expr." (Fortran2008, "6.2 Variable") - and 5.3.14 strictly distinguishes betwixt data and procedure pointers. However, that still does not tell whether OpenMPv3 allows procedure pointers; as OpenMP is based on Fortran 90/95, one cannot expect a real answer in the specification. Still, the definition for variable in OpenMPv3 seems to allow it. > is something we want to do. Bu But ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #6 from jakub at gcc dot gnu dot org 2010-05-12 08:29 --- Created an attachment (id=20644) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20644&action=view) gcc46-pr44036.patch Only very lightly tested patch. 1) allows dummy procedures and procedure pointers, disallows external procedures in the lists (the last ones definitely aren't variables and aren't even represented as such) 2) makes sure POINTER_TYPE to FUNCTION_TYPE isn't privatized by reference, this is wrong and causes crashes just about everywhere 3) had to tweak trans.c slightly to set input_location early, otherwise for b INDIRECT_REF is created with EXPR_LOCATION of the previous parallel. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug lto/44087] [4.6 Regression] New LTO test failures
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44087
[Bug c++/44092] New: Undefined Symbol: std::basic_string
If I compile a short Programm with g++ and I declare a STL-String (only
declare!), than it is ok ("g++ -c -Wall Progname.c").
But if I link the same programm with "g++ -o Progname Progname.o", than I get
an linker error:
ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::basic_string()
ld: 0711-317 ERROR: Undefined symbol: .std::basic_string, std::allocator >::~basic_string()
If I use some other STL-Funtions as e.g. "maps", "vectors", I get no errors.
I also have tried the "gcc-4.2.0", but the same problem (as with -> "gcc
4.0.0").
Even a linker option "-lstdc++" does not help.
--
Summary: Undefined Symbol: std::basic_string
Product: gcc
Version: 4.0.0
Status: UNCONFIRMED
Severity: blocker
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: stefanwin at gmx dot net
GCC host triplet: IBM PowercPC / AIX 5.3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
[Bug lto/44087] [4.6 Regression] New LTO test failures
--- Comment #1 from hubicka at gcc dot gnu dot org 2010-05-12 09:20 --- I believe this was temporary issue fixed by subsequent commit. Will double check. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44087
[Bug middle-end/44081] Incorrect nonnull assumed in code generation
--- Comment #8 from pmoulder at mail dot csse dot monash dot edu dot au 2010-05-12 09:25 --- OK, on careful reading, I agree re memcpy etc. (see below). Consequently, I amend my suggested change to the documentation to: - Add a sentence about implicit `this' argument (copied & pasted from the format_arg entry). - Although largely taken care of by the above, I'd still be inclined to rename the attribute parameter from âarg-indexâ to âarg-numberâ; and similarly to rename âstring-indexâ to âstring-arg-numberâ elsewhere in the texinfo node (in format and format_arg items). - Reword âargument index listâ to âargument number listâ (in the nonnull item). - Despite retracting the âwrongly used in glibcâ grounds, I think the concerns raised on the page I linked to are sufficient to merit giving more emphasis to the "The compiler may also choose to make optimizations based on the knowledge that certain function arguments will not be null" sentence: that it be put it in a paragraph by itself, and adding a warning that a consequence would be that any checks for NULL in the function may be optimized away. Coming back to memcpy etc.: As this is such an edge case, I'll give more detail for my (revised) reasoning (partly for the benefit of certain others that I intend to refer to this discussion): - C99 §7.21.2.1 [#2]: âThe memcpy function copies n [i.e. 0] characters from the object pointed to by s2 into the object pointed to by s1.â Text is similar for memcmp, memmove, memset, and their w- (wmemcmp etc.) counterparts, in each case referring to âthe object pointed to by s/s1/s2â; while text for qsort says âsorts an array of nmemb objects, the initial element of which is pointed to by baseâ. - C99 §6.3.2.3 [#3]: âSuch a pointer [as NULL], called a null pointer, is guaranteed to compare unequal to a pointer to any object or function.â Thus, if s/s1/s2 is a null pointer, then âthe object pointed to by s/s1/s2â isn't defined, so the sentence doesn't apply (despite copying/comparing only 0 bytes/characters from or to this undefined thing); and in each case there's no other text giving the behaviour when s/s1/s2 is a null pointer; so I conclude that the behaviour of these functions is indeed undefined when s/s1/s2 is a null pointer, so the âundefined behaviourâ provisions of §3.18 apply, and optimizing out the test for NULL is conformant behaviour as an instance of âignoring the situation [of s/s1/s2 == NULL] completely with unpredictable resultsâ (§3.18 [#2]). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
[Bug c++/44092] Undefined Symbol: std::basic_string
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-12 09:31 --- Something seems seriously broken in your setup, of course in a proper one this kind of problem would have blocked the release. Let's CC David... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||dje dot gcc at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #4 from sebastian dot huber at embedded-brains dot de 2010-05-12 09:40 --- GCC 4.5.0 20100414 has this problem too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
--- Comment #18 from ubizjak at gmail dot com 2010-05-12 09:46 --- FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some reason: gmake[4]: Entering directory `/home/uros/gcc-build/x86_64-unknown-linux-gnu/boehm-gc' Switched to incremental mode Emulating dirty bits with mprotect/signals Completed 3 tests Allocated 5705175 collectable objects Allocated 306 uncollectable objects Allocated 375 atomic objects Allocated 34440 stubborn objects Finalized 6679/6679 objects - finalization is probably ok Total number of bytes allocated is 327875152 Final heap size is 22253568 bytes Collector appears to work Completed 384 collections PASS: gctest Leaked composite object at 0x2b5d6f749ef0 (../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL) PASS: leaktest Final heap size is 131072 PASS: middletest PASS: staticrootstest == All 4 tests passed == -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug libgomp/44093] New: Linking libgomp.so fails on Solaris 9/x86 with Sun as: relocations remain
I recently tried to bootstrap the GCC 4.4.2 release on Solaris 9/x86 with Sun as and ld. The bootstrap failed linking libgomp.so: libtool: link: /vol/obj/gnu/gcc/gcc-4.4.2/9-gcc/./gcc/xgcc -B/vol/obj/gnu/gcc/gcc-4.4.2/9-gcc/./gcc/ -B/vol/gcc-4.4/i386-pc-solaris2.9/bin/ -B/vol/gcc-4.4/i386-pc-solaris2.9/lib/ -isystem /vol/gcc-4.4/i386-pc-solaris2.9/include -isystem /vol/gcc-4.4/i386-pc-solaris2.9/sys-include -shared -Wl,-z -Wl,text -Wl,-h -Wl,libgomp.so.1 -o .libs/libgomp.so.1.0.0 .libs/alloc.o .libs/barrier.o .libs/critical.o .libs/env.o .libs/error.o .libs/iter.o .libs/iter_ull.o .libs/loop.o .libs/loop_ull.o .libs/ordered.o .libs/parallel.o .libs/sections.o .libs/single.o .libs/task.o .libs/team.o .libs/work.o .libs/lock.o .libs/mutex.o .libs/proc.o .libs/sem.o .libs/bar.o .libs/ptrlock.o .libs/time.o .libs/fortran.o .libs/affinity.o -lrt -lc -pthread Text relocation remains referenced against symbol offset in file gomp_ialias_omp_set_dynamic 0x204 .libs/fortran.o [...] gomp_ialias_omp_test_nest_lock 0x22c .libs/fortran.o gomp_ialias_omp_get_num_procs 0x170 .libs/fortran.o gomp_ialias_omp_get_wtime 0x140 .libs/fortran.o gomp_ialias_omp_get_wtick 0x14c .libs/fortran.o ld: fatal: relocations remain against allocatable but non-writable sections collect2: ld returned 1 exit status make[4]: *** [libgomp.la] Error 1 This is obviously due to the fact that Sun as doesn't have visiblity support in Solaris 9. -- Summary: Linking libgomp.so fails on Solaris 9/x86 with Sun as: relocations remain Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgomp AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: i386-pc-solaris2.9 GCC host triplet: i386-pc-solaris2.9 GCC target triplet: i386-pc-solaris2.9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44093
[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line
--- Comment #2 from ro at gcc dot gnu dot org 2010-05-12 10:02 --- Mine. patch in progress. Using something like TARGET_SOLARIS is wrong: this is just a bug in older Sun as versions; a feature test macro to enable this will be autoconfigured. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Component|c |target Known to fail||4.4.2 4.5.0 Last reconfirmed|2010-05-11 08:26:22 |2010-05-12 10:02:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44074
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #5 from sebastian dot huber at embedded-brains dot de
2010-05-12 10:03 ---
GCC 4.2.4 does not have this problem.
Function epilogue:
.L672:
ldr r0, [r7, #4]
mov sp, r7
add sp, sp, #52
@ sp needed for prologue
pop {r4, r5, r6, r7, pc}
You can see here that the mov/add and ldr instructions are in the right order.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug fortran/37039] Cray pointer with pointee DIMENSION statement after POINTER statement
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-12 10:06 --- Another possible dupe: PR29813. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039
[Bug fortran/29813] -std=F95/F2003: Warn or error when using a non-declared variable with implicit none
--- Comment #5 from dfranke at gcc dot gnu dot org 2010-05-12 10:06 --- See also: PR31560, PR37039. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29813
[Bug fortran/40728] Bogus error "Error: Can't convert UNKNOWN to REAL(8) at (1)"
--- Comment #9 from dfranke at gcc dot gnu dot org 2010-05-12 10:12 --- Subject: Bug 40728 Author: dfranke Date: Wed May 12 10:11:50 2010 New Revision: 159306 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159306 Log: gcc/fortran/: 2010-05-12 Daniel Franke PR fortran/40728 * intrinc.c (gfc_is_intrinsic): Do not prematurely mark symbol as external. gcc/testsuite/: 2010-05-12 Daniel Franke PR fortran/40728 * gfortran.dg/selected_char_kind_3.f90: Fixed error message. * gfortran.dg/intrinsic_std_1.f90: Fixed bogus message. * gfortran.dg/intrinsic_std_5.f03: New. Added: branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/intrinsic_std_5.f03 Modified: branches/gcc-4_5-branch/gcc/fortran/ChangeLog branches/gcc-4_5-branch/gcc/fortran/intrinsic.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/intrinsic_std_1.f90 branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/selected_char_kind_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40728
[Bug fortran/40728] Bogus error "Error: Can't convert UNKNOWN to REAL(8) at (1)"
--- Comment #10 from dfranke at gcc dot gnu dot org 2010-05-12 10:12 --- Fixed in 4.5 and trunk. Closing. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40728
[Bug c++/44092] Undefined Symbol: std::basic_string
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-12 10:34 --- And neither 4.0.0 nor 4.2.x are maintained anymore nor do you provide a testcase to verify your failure. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44092
[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line
--- Comment #3 from jay dot krell at cornell dot edu 2010-05-12 10:50 --- > Using something like TARGET_SOLARIS is wrong: this is just a bug in older Sun I don't completely agree. - I regularly do cross builds. What will you do for that? Assume the old version? I think so. Since the result works the same on all versions. So you might as well just do that for cross and native imho. - I want to build a gcc on 2.10 that works on 2.9..er..well, that's not quite right. For that I'll build it on 2.9. But the cross build scenario is relevant. - Look at what Darwin/Macho does -- that is also only for older versions, but they just do it unconditionally. (Might be good to check for TARGET_64BIT though, since that probably implies a new enough assembler?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44074
[Bug c/44094] New: case xxx statement does not recognize const int value
switch(xxx)
{
case *(const int* const)"abc":
break;
}
does not get compiled. saying:
error: case label does not reduce to an integer constant
I think it is the bug.
--
Summary: case xxx statement does not recognize const int value
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: socketpair at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44094
[Bug middle-end/44081] Incorrect nonnull assumed in code generation
--- Comment #9 from hv at crypt dot org 2010-05-12 10:54 --- The direction of discussion has centred so far on the documentation, but as far as I can tell the only point at which the documentation confused someone was the triage at #3. Should there not be a separate bug opened for problems with the documentation? Can somone with access to a stock 4.5.0 confirm that the originally reported testcase does indeed show a bug? In #7, Jakub says: > 4.5.0 (rather than current 4.5 snapshots) had a bug with nonnull attribute > if a function is IPA optimized and some arguments are optimized out, but I > don't think that's the case here. Do you have a reference for this bug? What makes you think this isn't the same? Note that in the process of cutting down the original code to a testcase, one constant that I found had to be preserved was that the test() function be static, so that gcc had freedom to fiddle with the calling conventions; another was that the first parameter be preserved even though unused; another was that the second parameter needed its nonnull attribute. It sounds very similar to me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
[Bug java/44095] New: [4.5/4.6 regression] massive java failures due to -findirect-dispatch breakage on sparc64-linux
Java is severely broken on sparc64-linux with gcc 4.5/4.6, which is a major regression from 4.4: http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00853.html (4.6 broken) http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00681.html (4.5 broken) http://gcc.gnu.org/ml/gcc-testresults/2010-05/msg00472.html (4.4 works) The detailed test suite logs show that _every_ -findirect-dispatch test case SEGFAULTs shortly after startup. I've bisected trunk and identified r155622 as the cause: Author: jakub Date: Mon Jan 4 16:02:41 2010 New Revision: 155622 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155622 Log: PR driver/42442 * gcc.c (SWITCH_IGNORE_PERMANENTLY): Define. (do_self_spec): For switches with SWITCH_IGNORE set set also SWITCH_IGNORE_PERMANENTLY. (check_live_switch): Check SWITCH_IGNORE_PERMANENTLY instead of SWITCH_IGNORE. Let's compare installations of r155621 and r155622: > LD_LIBRARY_PATH=/mnt/scratch/install-r155621/lib: > /mnt/scratch/install-r155621/bin/gcj -v -findirect-dispatch > --main=ArrayStore2 ArrayStore2.jar ... /mnt/scratch/install-r155621/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/jc1 ArrayStore2.jar -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fPIC -fkeep-inline-functions -quiet -dumpbase ArrayStore2.jar -mcpu=v8 -auxbase ArrayStore2 -g1 -version -findirect-dispatch -fbootclasspath=./:/mnt/scratch/install-r155621/share/java/libgcj-4.5.0.jar -o /tmp/ccCkBmCp.s ... as -V -Qy -s -K PIC -32 -relax -o /tmp/ccgzZvpI.o /tmp/ccCkBmCp.s ... /mnt/scratch/install-r155621/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/jvgenmain -findirect-dispatch ArrayStore2main /tmp/ccwLkVQ4.i ... /mnt/scratch/install-r155621/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/cc1 /tmp/ccwLkVQ4.i -quiet -dumpbase ArrayStore2main.c -mcpu=v8 -g1 -version -fdollars-in-identifiers -o /tmp/ccCkBmCp.s ... as -V -Qy -s -32 -relax -o /tmp/cc8Sx4xt.o /tmp/ccCkBmCp.s ... > LD_LIBRARY_PATH=/mnt/scratch/install-r155621/lib: ./a.out index rhs java.lang.ArrayIndexOutOfBoundsException > LD_LIBRARY_PATH=/mnt/scratch/install-r155622/lib: > /mnt/scratch/install-r155622/bin/gcj -v -findirect-dispatch > --main=ArrayStore2 ArrayStore2.jar ... /mnt/scratch/install-r155622/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/jc1 ArrayStore2.jar -fuse-divide-subroutine -fuse-boehm-gc -fnon-call-exceptions -fPIC -fkeep-inline-functions -quiet -dumpbase ArrayStore2.jar -mcpu=v8 -auxbase ArrayStore2 -g1 -version -findirect-dispatch -fbootclasspath=./:/mnt/scratch/install-r155622/share/java/libgcj-4.5.0.jar -o /tmp/cc5XY9sD.s ... as -V -Qy -s -K PIC -32 -relax -o /tmp/cc626Pob.o /tmp/cc5XY9sD.s ... /mnt/scratch/install-r155622/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/jvgenmain -findirect-dispatch ArrayStore2main /tmp/ccLsDapM.i ... /mnt/scratch/install-r155622/libexec/gcc/sparc64-unknown-linux-gnu/4.5.0/cc1 /tmp/ccLsDapM.i -quiet -dumpbase ArrayStore2main.c -mcpu=v8 -g1 -version -fdollars-in-identifiers -o /tmp/cc5XY9sD.s ... as -V -Qy -s -K PIC -32 -relax -o /tmp/ccw9Ke7n.o /tmp/cc5XY9sD.s ... > LD_LIBRARY_PATH=/mnt/scratch/install-r155622/lib:. ./a.out Segmentation fault The main difference is that in the working compiler, the java classes are assembled with -K PIC but the generated main() is not, while in the broken compiler both the java classes and the generated main() are assembled with -K PIC. If I force -K PIC with the working compiler it too fails: > LD_LIBRARY_PATH=/mnt/scratch/install-r155621/lib: > /mnt/scratch/install-r155621/bin/gcj -findirect-dispatch --main=ArrayStore2 > -Wa,-K,PIC ArrayStore2.jar > LD_LIBRARY_PATH=/mnt/scratch/install-r155621/lib: ./a.out Segmentation fault I note that gcc/java/jvspec.c has %http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44095
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #6 from sebastian dot huber at embedded-brains dot de 2010-05-12 11:06 --- If you use GCC 4.5.0 20100414 with '-march=armv7' '-mthumb' '-Os' the function epilogue is also correct. It seems that this is a Thumb 1 problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug c/44096] New: Error because cfns.h is empty
Problem when building stage 2: cp/except.o: In function `nothrow_libfn_p': except.c:(.text+0x126d): undefined reference to `libc_name_p' collect2: ld gab 1 als Ende-Status zurück. I found the same problem in this message: http://gcc.gnu.org/ml/gcc-help/2009-10/msg00402.html When I checked cfns.h, which was mentioned as the cause of this problem, it turned out to be completely empty, both in Release 4.5.0 and in the svn top revision. After I copied cfns.h from Release 4.2.2 into directory gcc/cp compilation finished successfully -- Summary: Error because cfns.h is empty Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: knurt at geislersoftware dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44096
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #7 from sebastian dot huber at embedded-brains dot de 2010-05-12 11:13 --- GCC 4.3.2 20080827 has this problem too. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug c/44096] Error because cfns.h is empty
--- Comment #1 from knurt at geislersoftware dot de 2010-05-12 11:18 --- Correction: For my workaround I used the cfns.h file from Release 4.4.2, as I did not have this problem around the time 4.4.2 was released. -- knurt at geislersoftware dot de changed: What|Removed |Added CC|iant at google dot com, |knurt at geislersoftware dot |joseph at codesourcery dot |de |com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44096
[Bug java/44095] [4.5/4.6 regression] massive java failures due to -findirect-dispatch breakage on sparc64-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44095
[Bug c/44094] case xxx statement does not recognize const int value
--- Comment #1 from redi at gcc dot gnu dot org 2010-05-12 11:36 --- the case label must be an integer constant, this is not the same as a const int. the * operator is not allowed in an integer constant expression, so the code is invalid -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44094
[Bug c/44094] case xxx statement does not recognize const int value
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-05-12 11:37 --- Indeed -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44094
[Bug target/44075] __builtin_eh_return miscompiled
-- amodra at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |amodra at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-12 11:40:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44075
[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line
--- Comment #4 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-05-12 11:50 --- Subject: Re: Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line > --- Comment #3 from jay dot krell at cornell dot edu 2010-05-12 10:50 > --- > > Using something like TARGET_SOLARIS is wrong: this is just a bug in older > Sun > > I don't completely agree. > - I regularly do cross builds. >What will you do for that? Assume the old version? I think so. Since the > result works the same on all versions. So you might as well just do that for > cross and native imho. No, I just test if rep works or if rep; is required instead and use the result of that test. It works in both native and cross environments. > - I want to build a gcc on 2.10 that works on 2.9..er..well, that's not quite > right. For that I'll build it on 2.9. But the cross build scenario is > relevant. That's not going to work in the general case: the Solaris 10 gcc may well use features that just don't exist in the Solaris 9 assembler and/or linker, so you're out of luck. > - Look at what Darwin/Macho does -- that is also only for older versions, but > they just do it unconditionally. (Might be good to check for TARGET_64BIT > though, since that probably implies a new enough assembler?) This hardcoding is wrong in the general case, even if the Mach-O guys did otherwise. Why follow a bad example? And why use implicit tests if you can explicitly test for the feature (or bug) you're looking for? Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44074
[Bug middle-end/44081] Incorrect nonnull assumed in code generation
--- Comment #10 from joseph at codesourcery dot com 2010-05-12 11:52 --- Subject: Re: Incorrect nonnull assumed in code generation On Wed, 12 May 2010, pmoulder at mail dot csse dot monash dot edu dot au wrote: > Coming back to memcpy etc.: As this is such an edge case, I'll give more > detail > for my (revised) reasoning (partly for the benefit of certain others that I > intend to refer to this discussion): It's a case about which the standard is completely explicit. 7.21.1#2. "Where an argument declared as size_t n specifies the length of the array for a function, n can have the value zero on a call to that function. Unless explicitly stated otherwise in the description of a particular function in this subclause, pointer arguments on such a call shall still have valid values, as described in 7.1.4." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
[Bug target/44074] Solaris 2.9 x86 Sun assembler doesn't like rep/lock prefixes on same line
--- Comment #5 from jay dot krell at cornell dot edu 2010-05-12 12:02 --- Rainer, sorry, I meant cross build a native gcc. build=whatever host=target=solaris Not cross compiling with gcc itself (other than to build gcc). Old versions accept a certain syntax. New versions accept a superset. Just stick with old and it always works. It's not a bug. It's just that the syntax grew. The old syntax was ok. Not everything should be configurable. The environment/tool to probe is not necessarily available. Countless times besides I've seen the probe and later use disagree, like there are some #defines in the actual code that the configure didn't #define. Better just to minimize autoconf rather than forever chase these problems.] I think this feature testing may have gotten out of hand, and it fails extremely often in my experience. Some things should just work. This is an easy one. You don't even need if macho|solaris -- gas always is ok with the semicolon so you can just always put it in. Leaving just the att syntax or not, space or semicolon. I've already applied the #ifdef SOLARIS thing locally. I was curious how you'd handle this..where would the #define go, what name chosen. But I was pretty sure I was following a good example in the Macho thing, and still am. Previously I did have to probe my Darwin assembler and recommend an upgrade if it didn't allow "rep ". Now I can remove that since gcc just works with all versions. Anyway, your mail thread on this was very helpful to me. - Jay -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44074
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #8 from sebastian dot huber at embedded-brains dot de
2010-05-12 12:03 ---
A summary follows. Broken means bdbuf.i generates an invalid stack frame usage
sequence in a function epilogue. Works means that the corresponding area is
valid.
Flags: -march=armv5t -mthumb -Os
Broken:
GCC 4.3.2 20080827
GCC 4.4.4 20100429
GCC 4.5.0 20100414
Works:
GCC 4.2.4
Flags: -march=armv7 -mthumb -Os
Works:
GCC 4.5.0 20100414
Flags: -march=armv5t -mthumb -O2
Suspicious:
GCC 4.5.0 20100414
Suspicious means that the epilogue sequence is this:
.L577:
mov sp, r7
add sp, sp, #36
mov r0, r4
/*
* Here we don't have a problem since r0 comes from r4
* and not from the stack frame. Is this always the case?
*/
@ sp needed for prologue
pop {r2, r3, r4, r5}
mov r8, r2
mov r9, r3
mov sl, r4
mov fp, r5
pop {r4, r5, r6, r7, pc}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug debug/42278] [4.4/4.5/4.6 regression] incorrect dwarf data gcc-4.4.2
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-12 12:09 --- Subject: Bug 42278 Author: jakub Date: Wed May 12 12:08:34 2010 New Revision: 159315 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159315 Log: PR debug/42278 * dwarf2out.c (base_type_die): Don't add name attribute here. (modified_type_die): Instead of sizetype use its underlying original type. If a DW_TAG_base_type doesn't have name added, add __unknown__. (dwarf2out_imported_module_or_decl_1): Don't call base_type_die, always call force_type_die instead. Modified: trunk/gcc/ChangeLog trunk/gcc/dwarf2out.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42278
[Bug middle-end/44085] OpenMP - untied task accesses threadprivate - non-conforming but no msg
--- Comment #2 from jakub at gcc dot gnu dot org 2010-05-12 12:11 --- Subject: Bug 44085 Author: jakub Date: Wed May 12 12:11:00 2010 New Revision: 159316 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159316 Log: PR middle-end/44085 * gimplify.c (enum omp_region_type): Add ORT_UNTIED_TASK, change value of ORT_TASK. (new_omp_context): Handle ORT_UNTIED_TASK like ORT_TASK. (omp_notice_threadprivate_variable): New function. (omp_notice_variable): Call it for threadprivate variables. If enclosing ctx is a task, print enclosing task rather than enclosing parallel. Handle ORT_UNTIED_TASK like ORT_TASK. (gimplify_omp_task): Pass ORT_UNTIED_TASK instead of ORT_TASK if task has untied clause. * gcc.dg/gomp/pr44085.c: New test. * gfortran.dg/gomp/pr44085.f90: New test. Added: trunk/gcc/testsuite/gcc.dg/gomp/pr44085.c trunk/gcc/testsuite/gfortran.dg/gomp/pr44085.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44085
[Bug middle-end/44085] OpenMP - untied task accesses threadprivate - non-conforming but no msg
--- Comment #3 from jakub at gcc dot gnu dot org 2010-05-12 12:19 --- Subject: Bug 44085 Author: jakub Date: Wed May 12 12:18:55 2010 New Revision: 159317 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159317 Log: PR middle-end/44085 * gimplify.c (enum omp_region_type): Add ORT_UNTIED_TASK, change value of ORT_TASK. (new_omp_context): Handle ORT_UNTIED_TASK like ORT_TASK. (omp_notice_threadprivate_variable): New function. (omp_notice_variable): Call it for threadprivate variables. If enclosing ctx is a task, print enclosing task rather than enclosing parallel. Handle ORT_UNTIED_TASK like ORT_TASK. (gimplify_omp_task): Pass ORT_UNTIED_TASK instead of ORT_TASK if task has untied clause. * gcc.dg/gomp/pr44085.c: New test. * gfortran.dg/gomp/pr44085.f90: New test. Added: branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/gomp/pr44085.c branches/gcc-4_5-branch/gcc/testsuite/gfortran.dg/gomp/pr44085.f90 Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/gimplify.c branches/gcc-4_5-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44085
[Bug fortran/41218] Vendor extension: character assignment in DATA to non-character variables
--- Comment #1 from dfranke at gcc dot gnu dot org 2010-05-12 12:26 --- *** This bug has been marked as a duplicate of 33015 *** -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41218
[Bug fortran/33015] g77 extension: Implement support for DATA jhlf /'f'/
--- Comment #4 from dfranke at gcc dot gnu dot org 2010-05-12 12:26 --- *** Bug 41218 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33015
[Bug middle-end/44085] OpenMP - untied task accesses threadprivate - non-conforming but no msg
--- Comment #4 from jakub at gcc dot gnu dot org 2010-05-12 12:30 --- Subject: Bug 44085 Author: jakub Date: Wed May 12 12:30:21 2010 New Revision: 159318 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159318 Log: PR middle-end/44085 * gimplify.c (enum omp_region_type): Add ORT_UNTIED_TASK, change value of ORT_TASK. (new_omp_context): Handle ORT_UNTIED_TASK like ORT_TASK. (omp_notice_threadprivate_variable): New function. (omp_notice_variable): Call it for threadprivate variables. If enclosing ctx is a task, print enclosing task rather than enclosing parallel. Handle ORT_UNTIED_TASK like ORT_TASK. (gimplify_omp_task): Pass ORT_UNTIED_TASK instead of ORT_TASK if task has untied clause. * gcc.dg/gomp/pr44085.c: New test. * gfortran.dg/gomp/pr44085.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/gomp/pr44085.c branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/gomp/pr44085.f90 Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/gimplify.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44085
[Bug fortran/41922] Diagnostic: No location shown for overlappingly initialized EQUIVALENCEd character vars
--- Comment #2 from dfranke at gcc dot gnu dot org 2010-05-12 12:43 --- With current trunk (r159282), we have a locus - but not the right one: pr41922.f:11.72: end 1 Error: Overlapping unequal initializers in EQUIVALENCE at (1) (In reply to comment #0) > Using the commented version instead, it works: > > data cstore/2*4/ > 1 > Error: Overlapping unequal initializers in EQUIVALENCE at (1) IMO, this should point to the EQUIVALENCE, not one of the involved DATA statements. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-05-12 12:43:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41922
[Bug target/44088] -mavx doesn't generate always AVX instructions
--- Comment #2 from hjl at gcc dot gnu dot org 2010-05-12 12:48 --- Subject: Bug 44088 Author: hjl Date: Wed May 12 12:48:02 2010 New Revision: 159319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159319 Log: Support AVX for cmpss/cmpsd. gcc/ 2010-05-12 H.J. Lu PR target/44088 * config/i386/sse.md (*avx_vmmaskcmp3): New. gcc/testsuite/ 2010-05-12 H.J. Lu PR target/44088 * gcc.target/i386/avx-cmpsd-1.c: New. * gcc.target/i386/avx-cmpsd-2.c: Likewise. * gcc.target/i386/avx-cmpss-1.c: Likewise. * gcc.target/i386/avx-cmpss-2.c: Likewise. * gcc.target/i386/sse-cmpss-1.c: Likewise. * gcc.target/i386/sse2-cmpsd-1.c: Likewise. Added: trunk/gcc/testsuite/gcc.target/i386/avx-cmpsd-1.c trunk/gcc/testsuite/gcc.target/i386/avx-cmpsd-2.c trunk/gcc/testsuite/gcc.target/i386/avx-cmpss-1.c trunk/gcc/testsuite/gcc.target/i386/avx-cmpss-2.c trunk/gcc/testsuite/gcc.target/i386/sse-cmpss-1.c trunk/gcc/testsuite/gcc.target/i386/sse2-cmpsd-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44088
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #76 from jcea at hispasec dot com 2010-05-12 13:00 --- [Zlib-devel] HEADS UP: Apparent bad compilation under (just released) GCC 4.5.0 http://mail.madler.net/pipermail/zlib-devel_madler.net/2010-May/002267.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #77 from jcea at hispasec dot com 2010-05-12 13:14 --- Discussión in progress: http://mail.python.org/pipermail/python-dev/2010-May/100044.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug c++/44097] New: 'export' is supposed to be no keyword in gcc, but in practice it is
Try to define a simple function:
void export() {
// whatever
}
This will not compile, because 'export' is considered a keyword. After googling
a bit for this keyword, I found that there has been a long debate already
regarding this keyword. But everywhere I look it is claimed that the only
compiler that implements this keyword, is the EDG compiler. I couldn't find any
reference about this for gcc. The fact that gcc -did- implement the 'export'
keyword should be made more clearly in the documentation (or the keyword could
be dropped, as this is going to happen anyway for the new c++0x standard AFAIK)
--
Summary: 'export' is supposed to be no keyword in gcc, but in
practice it is
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakobsybren at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44097
[Bug c++/44097] 'export' is supposed to be no keyword in gcc, but in practice it is
--- Comment #1 from paolo dot carlini at oracle dot com 2010-05-12 13:57 --- Well, one thing is *reserving* a keyword, another implementing a semantics. About the next Standard, yes it could make sense to drop it from the set of keywords, but I don't think we should rush to do that, certainly not in the obsolete, and not maintained anymore, 4.1.x branch ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44097
[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.
--- Comment #15 from pluto at agmk dot net 2010-05-12 13:57 --- the problematic is eh_globals.o which was merged into libstlport.a. the TLS version of the get_globals causes memory corruption in my app. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug c++/44097] [C++0x] 'export' is supposed to be no keyword in gcc, but in practice it is
--- Comment #2 from redi at gcc dot gnu dot org 2010-05-12 14:15 --- export is still going to be a keyword in C++1x, even though the feature has been removed, so it should still be recognised as a keyword by GCC. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44097
[Bug c++/44097] [C++0x] 'export' is supposed to be no keyword in gcc, but in practice it is
--- Comment #3 from redi at gcc dot gnu dot org 2010-05-12 14:16 --- 2.12 Keywords [lex.key] 1 The identifiers shown in Table 3 are reserved for use as keywords (that is, they are unconditionally treated as keywords in phase 7) except in an attribute-token (7.6.1) [ Note: The export keyword is unused but is reserved for future use. end note ]: N.B. "unconditionally treated as keywords" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44097
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #7 from longb at cray dot com 2010-05-12 14:34 --- For what it's worth, the Cray compiler produces this message for the test code: !$OMP shared (a,n,f) ^ ftn-1473 crayftn: ERROR DP, File = test.f90, Line = 13, Column = 19 Object F must be a variable to be in the SHARED clause of the PARALLEL directive. Regarding Fortran terminology, a procedure pointer is a procedure, not a variable. The definition for "procedure pointer" is "procedure with the EXTERNAL and POINTER attributes". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug middle-end/44085] OpenMP - untied task accesses threadprivate - non-conforming but no msg
--- Comment #5 from jakub at gcc dot gnu dot org 2010-05-12 14:39 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44085
[Bug c/44098] New: -O3 causes quickInvSqrt() to return -inf.
I have tested the famous quickInvSqrt() algorithm uses in Quake, and it does
not compile correctly when compiling with -O3. It does however work completely
fine when compiling for -O0, -O1 and -O2.
The function goes like so:
float quickInvSqrt(float x)
{
float xhalf = 0.5f*x;
int i = *(int*)&x;
i = 0x5f3759df - (i>>1);
x = *(float*)&i;
x = x*(1.5f - xhalf*x*x);
return x;
}
--
Summary: -O3 causes quickInvSqrt() to return -inf.
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: maister at archlinux dot us
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug c/44098] -O3 causes quickInvSqrt() to return -inf.
--- Comment #1 from maister at archlinux dot us 2010-05-12 14:56 --- Created an attachment (id=20645) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20645&action=view) The test case. Actually, it's quite absurd, but trying to print out from 1 to 10 rather than 1 to 100 seemed to work, even with -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug c/44098] -O3 causes quickInvSqrt() to return -inf.
--- Comment #2 from maister at archlinux dot us 2010-05-12 15:00 --- Created an attachment (id=20646) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20646&action=view) ASM output with -O2 Assembly output using gcc -S -O2 invsqrt.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug c/44098] -O3 causes quickInvSqrt() to return -inf.
--- Comment #3 from maister at archlinux dot us 2010-05-12 15:01 --- Created an attachment (id=20647) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20647&action=view) ASM output with -O3 Assembly output with -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #8 from jakub at gcc dot gnu dot org 2010-05-12 15:01 --- Seems dummy procedures are already in F95 and therefore something that OpenMP 3.0 should take into account. So probably for them it would be better to keep rejecting them in the clause lists and ensure they aren't rejected by the middle-end with default(none). If they can't be changed, I guess making them behave internally like predetermined shared by handling PARM_DECLs with POINTER_TYPE to FUNCTION_TYPE in gfc_omp_predetermined_sharing to return OMP_CLAUSE_DEFAULT_FIRSTPRIVATE. As for procedure pointers, while perhaps Fortran doesn't call them variables, in the OpenMP terminology they IMHO behave like variables. They can be changed and thus some upcoming OpenMP standard version that covers Fortran 2003 will certainly need to allow them in the clauses - the user should have control over whether changing a procedure pointer in one thread affects other threads or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug c/44098] -O3 causes quickInvSqrt() to return -inf.
--- Comment #4 from paolo dot carlini at oracle dot com 2010-05-12 15:04 --- First blush, I can see some pretty serious aliasing violations... try -Wall -- paolo dot carlini at oracle dot com changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug c/44098] -O3 causes quickInvSqrt() to return -inf.
--- Comment #5 from paolo dot carlini at oracle dot com 2010-05-12 15:07 --- and then try -O3 -fno-strict-aliasing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug c/44098] -O3 causes quickInvSqrt() to return -inf.
--- Comment #6 from maister at archlinux dot us 2010-05-12 15:23 --- That worked (-O3 -fno-strict-aliasing). But why does this work on -O2 and not -O3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug c/44098] -O3 causes quickInvSqrt() to return -inf.
--- Comment #7 from paolo dot carlini at oracle dot com 2010-05-12 15:25 --- You are violating the aliasing rules, anything can happen, at any optimization level... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #9 from jakub at gcc dot gnu dot org 2010-05-12 15:25 --- Created an attachment (id=20648) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20648&action=view) gcc46-pr44036.patch Updated patch which implements that. I've split off the locus changes to a separate follow-up patch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Attachment #20644|0 |1 is obsolete|| AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug fortran/44036] I can't declare an external function in an OMP shared statement.
--- Comment #10 from jakub at gcc dot gnu dot org 2010-05-12 15:27 --- Created an attachment (id=20649) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20649&action=view) locus follow-up Follow-up patch to fix up the locus. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44036
[Bug c/21920] aliasing violations
--- Comment #151 from paolo dot carlini at oracle dot com 2010-05-12 15:29 --- *** Bug 44098 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||maister at archlinux dot us http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c/44098] -O3 causes quickInvSqrt() to return -inf.
--- Comment #8 from paolo dot carlini at oracle dot com 2010-05-12 15:29 --- *** This bug has been marked as a duplicate of 21920 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44098
[Bug other/43977] Patches from oldlto branch to be salvaged
--- Comment #6 from froydnj at gcc dot gnu dot org 2010-05-12 15:35 --- r114291, r114400, and r114401 have been committed as r159326. -- froydnj at gcc dot gnu dot org changed: What|Removed |Added CC||froydnj at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
[Bug middle-end/43853] [4.6 Regression] FAIL: gcc.dg/lto/20090126-1 c_lto_20090126-1_0.o-c_lto_20090126-1_0.o
--- Comment #3 from ro at gcc dot gnu dot org 2010-05-12 15:48 --- Also happens on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01]. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43853
[Bug tree-optimization/43924] [4.6 Regression] FAIL: gfortran.dg/array_constructor_11.f90 -O3 -g (internal compiler error)
--- Comment #7 from ro at gcc dot gnu dot org 2010-05-12 15:54 --- Also on i386-pc-solaris2.1[01] and sparc-sun-solaris2.1[01]. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43924
[Bug other/43977] Patches from oldlto branch to be salvaged
--- Comment #7 from froydnj at gcc dot gnu dot org 2010-05-12 15:56 --- r114547 and 114548 have been committed as r159328. r115342 has been committed as part of the CALL_EXPR changes that *did* make it in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
[Bug fortran/37039] Cray pointer with pointee DIMENSION statement after POINTER statement
--- Comment #3 from langton at gcc dot gnu dot org 2010-05-12 15:57 --- I don't think this is a dupe of either of those bugs. In this case, the dimension attribute isn't properly applied to 'tab' on line 5. The problem appears to be in variable_decl() (decl.c), where I kept an extra gfc_array_spec (cp_as) that isn't merged with current_as. I'm trying to recall why cp_as was necessary, and whether it's still necessary. -- langton at gcc dot gnu dot org changed: What|Removed |Added CC||langton2 at llnl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039
[Bug target/44099] New: ICE in g++.dg/debug/nullptr01.C test on Solaris 2/SPARC
The new g++.dg/debug/nullptr01.C test currently fails on Solaris 10/11 SPARC: FAIL: g++.dg/debug/nullptr01.C -gdwarf-2 -g1 (internal compiler error) FAIL: g++.dg/debug/nullptr01.C -gdwarf-2 -g1 (test for excess errors) ERROR: g++.dg/debug/nullptr01.C: error executing dg-final: couldn't open "nullp tr01.s": no such file or directory g++.log reveals: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/debug/nullptr01.C: In function 'std::nullptr_t g(T) [with T = A, std::nullptr_t = std::nullptr_t]': /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/debug/nullptr01.C:13:1: internal compiler error: in sparc_type_code, at config/sparc/sparc.c:7371 -- Summary: ICE in g++.dg/debug/nullptr01.C test on Solaris 2/SPARC Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: sparc-sun-solaris2.10 GCC host triplet: sparc-sun-solaris2.10 GCC target triplet: sparc-sun-solaris2.10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44099
[Bug c++/44100] New: [4.6 regression] ICE compiling g++.dg/init/struct2.C on Tru64 UNIX V5.1B
Between 20100422 and 20100507 there appeared a testsuite regression on Tru64 UNIX V5.1B: FAIL: g++.dg/init/struct2.C (internal compiler error) FAIL: g++.dg/init/struct2.C (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/g++.dg/init/struct2.C:20:5: internal compiler error: in decode_addr_const, at varasm.c:2854 -- Summary: [4.6 regression] ICE compiling g++.dg/init/struct2.C on Tru64 UNIX V5.1B Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44100
[Bug c++/44100] [4.6 regression] ICE compiling g++.dg/init/struct2.C on Tru64 UNIX V5.1B
--- Comment #1 from ro at gcc dot gnu dot org 2010-05-12 16:23 --- Created an attachment (id=20650) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20650&action=view) preprocessed source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44100
[Bug c++/44101] New: [4.6 regression] ICE compiling 25_algorithms/fill/4.cc on Tru64 UNIX V5.1B
Between there appeared two new testsuite failures on Tru64 UNIX V5.1B: FAIL: 25_algorithms/fill/4.cc (test for excess errors) WARNING: 25_algorithms/fill/4.cc compilation failed to produce executable Excess errors: /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/25_algorithms/fill/4.cc:27:1: error: non-trivial conversion at assignment const wchar_t[10] const int[10] A3 = *$LC0; /vol/gcc/src/hg/trunk/local/libstdc++-v3/testsuite/25_algorithms/fill/4.cc:27:1: internal compiler error: verify_gimple failed FAIL: 25_algorithms/fill_n/1.cc (test for excess errors) WARNING: 25_algorithms/fill_n/1.cc compilation failed to produce executable -- Summary: [4.6 regression] ICE compiling 25_algorithms/fill/4.cc on Tru64 UNIX V5.1B Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: alpha-dec-osf5.1b GCC host triplet: alpha-dec-osf5.1b GCC target triplet: alpha-dec-osf5.1b http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44101
[Bug c/44091] [ARM/Thumb] Invalid stack frame usage at -Os
--- Comment #9 from mikpe at it dot uu dot se 2010-05-12 16:34 --- Confirmed with cross to armv5tel-unknown-linux-gnueabi. 4.3/4.4/4.5/4.6 all generate the signal-unsafe epilogue. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44091
[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
--- Comment #19 from davek at gcc dot gnu dot org 2010-05-12 16:48 --- (In reply to comment #18) > FYI, the same failure happens on x86_64-pc-linux-gnu, but is silent for some > reason: > Leaked composite object at 0x2b5d6f749ef0 > (../../../gcc-svn/trunk/boehm-gc/tests/leak_test.c:16, sz=8, NORMAL) > > PASS: leaktest > Final heap size is 131072 No, as far as I can see it's OK and that's a successful PASS. The purpose of the test is to leak some memory and verify that the GC can *detect* the leak. As indeed it does in the other case as well, which now makes me suspect that the alpha FAIL is probably a false negative. The test code is rather old, declares main as an implict int function, and doesn't have a return statement in it. That could easily end up returning some random register contents as an exit status. Do you have time to check if adding a "return 0;" at the end of the main() function resolves the failure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug fortran/37039] Cray pointer with pointee DIMENSION statement after POINTER statement
--- Comment #4 from langton at gcc dot gnu dot org 2010-05-12 16:51 --- Created an attachment (id=20651) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20651&action=view) Possible fix (minimal testing) Removing cp_as entirely seems to work. I'll have to test this some more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039
[Bug bootstrap/44079] Bootstrap error about elf_getshdrstrndx when configure script does not detect elf_getshdrstrndx
--- Comment #1 from ro at gcc dot gnu dot org 2010-05-12 17:22 --- Could you please provide some more details, please: what system are you running on, what version of libelf is in use? And please provide config.log and configure output from the toplevel and from the gcc subdirectory, together with gcc/auto-host.h. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44079
[Bug target/44099] ICE in g++.dg/debug/nullptr01.C test on Solaris 2/SPARC
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2010-05-12 17:28 --- Isn't that again a C++ tree code that leaks into the back-end? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44099
[Bug target/44099] ICE in g++.dg/debug/nullptr01.C test on Solaris 2/SPARC
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-12 17:29 --- Yeah, another aspect of the same issue as 44048. *** This bug has been marked as a duplicate of 44048 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44099
[Bug bootstrap/44048] [4.6 Regression] building without C++ enabled fails
--- Comment #3 from jason at gcc dot gnu dot org 2010-05-12 17:29 --- *** Bug 44099 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44048
[Bug bootstrap/44048] [4.6 Regression] building without C++ enabled fails
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-05-10 22:11:21 |2010-05-12 17:30:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44048
[Bug c++/20669] Template candidates not listed in error message.
--- Comment #2 from jason at gcc dot gnu dot org 2010-05-12 17:35 --- Subject: Bug 20669 Author: jason Date: Wed May 12 17:34:55 2010 New Revision: 159335 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159335 Log: PR c++/20669 * call.c (add_template_candidate_real): If deduction fails, still add the template as a non-viable candidate. (equal_functions): Handle template candidates. (print_z_candidate): Likewise. (print_z_candidates): Likewise. (build_new_function_call): Likewise. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/conversion/op1.C trunk/gcc/testsuite/g++.dg/cpp0x/nullptr15.C trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C trunk/gcc/testsuite/g++.dg/cpp0x/temp_default2.C trunk/gcc/testsuite/g++.dg/cpp0x/trailing4.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex3.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex4.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-throw.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic35.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-35147.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-37737-1.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-37737-2.C trunk/gcc/testsuite/g++.dg/ext/visibility/anon8.C trunk/gcc/testsuite/g++.dg/ext/vla2.C trunk/gcc/testsuite/g++.dg/other/pr28114.C trunk/gcc/testsuite/g++.dg/other/ptrmem10.C trunk/gcc/testsuite/g++.dg/other/ptrmem11.C trunk/gcc/testsuite/g++.dg/overload/unknown1.C trunk/gcc/testsuite/g++.dg/parse/template7.C trunk/gcc/testsuite/g++.dg/parse/typename7.C trunk/gcc/testsuite/g++.dg/template/conv11.C trunk/gcc/testsuite/g++.dg/template/copy1.C trunk/gcc/testsuite/g++.dg/template/deduce3.C trunk/gcc/testsuite/g++.dg/template/dependent-expr5.C trunk/gcc/testsuite/g++.dg/template/friend.C trunk/gcc/testsuite/g++.dg/template/incomplete2.C trunk/gcc/testsuite/g++.dg/template/local4.C trunk/gcc/testsuite/g++.dg/template/local6.C trunk/gcc/testsuite/g++.dg/template/operator10.C trunk/gcc/testsuite/g++.dg/template/overload6.C trunk/gcc/testsuite/g++.dg/template/ptrmem2.C trunk/gcc/testsuite/g++.dg/template/ptrmem20.C trunk/gcc/testsuite/g++.dg/template/ptrmem8.C trunk/gcc/testsuite/g++.dg/template/sfinae2.C trunk/gcc/testsuite/g++.dg/template/ttp25.C trunk/gcc/testsuite/g++.dg/template/unify10.C trunk/gcc/testsuite/g++.dg/template/unify11.C trunk/gcc/testsuite/g++.dg/template/unify6.C trunk/gcc/testsuite/g++.dg/template/unify7.C trunk/gcc/testsuite/g++.dg/template/unify9.C trunk/gcc/testsuite/g++.dg/template/varmod1.C trunk/gcc/testsuite/g++.old-deja/g++.brendan/crash56.C trunk/gcc/testsuite/g++.old-deja/g++.law/operators32.C trunk/gcc/testsuite/g++.old-deja/g++.pt/crash28.C trunk/gcc/testsuite/g++.old-deja/g++.pt/crash60.C trunk/gcc/testsuite/g++.old-deja/g++.pt/explicit38.C trunk/gcc/testsuite/g++.old-deja/g++.pt/explicit39.C trunk/gcc/testsuite/g++.old-deja/g++.pt/explicit41.C trunk/gcc/testsuite/g++.old-deja/g++.pt/explicit67.C trunk/gcc/testsuite/g++.old-deja/g++.pt/explicit77.C trunk/gcc/testsuite/g++.old-deja/g++.pt/expr2.C trunk/gcc/testsuite/g++.old-deja/g++.pt/overload7.C trunk/gcc/testsuite/g++.old-deja/g++.pt/ptrmem6.C trunk/gcc/testsuite/g++.old-deja/g++.pt/spec5.C trunk/gcc/testsuite/g++.old-deja/g++.pt/spec6.C trunk/gcc/testsuite/g++.old-deja/g++.pt/t24.C trunk/gcc/testsuite/g++.old-deja/g++.pt/unify4.C trunk/gcc/testsuite/g++.old-deja/g++.pt/unify6.C trunk/gcc/testsuite/g++.old-deja/g++.pt/unify8.C trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb119.C trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb79.C trunk/gcc/testsuite/g++.old-deja/g++.robertl/eb98.C trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/20_util/auto_ptr/assign_neg.cc trunk/libstdc++-v3/testsuite/20_util/unique_ptr/assign/assign_neg.cc trunk/libstdc++-v3/testsuite/20_util/weak_ptr/comparison/cmp_neg.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20669
[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
--- Comment #20 from ubizjak at gmail dot com 2010-05-12 17:39 --- (In reply to comment #19) > As indeed it does in the other case as well, which now makes me suspect that > the alpha FAIL is probably a false negative. The test code is rather old, > declares main as an implict int function, and doesn't have a return statement > in it. That could easily end up returning some random register contents as an > exit status. Do you have time to check if adding a "return 0;" at the end of > the main() function resolves the failure? Yeah, adding "return 0;" fixes the failure! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
--- Comment #21 from ubizjak at gmail dot com 2010-05-12 17:46 --- Created an attachment (id=20652) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20652&action=view) GC testsuite fixes Patch that declares "int main" and adds "return 0;" to the tests. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug target/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
--- Comment #22 from ubizjak at gmail dot com 2010-05-12 17:50 --- Hm, I'm not able to run thread_test.c and thread_leak_test.c tests using "make -k check", so otherwise deadly trivial patch can't be fully tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug middle-end/44102] New: ICE with asm goto + __builtin_unreachable () in C++
// { dg-do compile }
// { dg-options "-O2" }
void baz (void);
struct A { A (); ~A (); };
static inline int
foo (void)
{
asm goto ("" : : : : l1, l2);
__builtin_unreachable ();
l1:
return 1;
l2:
return 0;
}
int
bar (int x)
{
if (x == 5)
{
A a, b;
baz ();
}
if (foo () || x == 6)
x = 1;
else
x = 2;
return x;
}
ICEs at -O2. The problem is that RTL EH pass deletes the empty basic block
before getting into cfglayout mode, and while deleting empty bbs in cfglayout
mode apparently works, it doesn't work in normal rtl mode (when BB_HEAD ==
BB_END). The following barrier is deleted too and nothing readds it after the
precious bb (the one ending with the asm goto).
--
Summary: ICE with asm goto + __builtin_unreachable () in C++
Product: gcc
Version: 4.6.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=44102
[Bug target/44099] ICE in g++.dg/debug/nullptr01.C test on Solaris 2/SPARC
--- Comment #3 from mikpe at it dot uu dot se 2010-05-12 19:15 --- I get the same errors with nullptr01.C on sparc64-unknown-linux-gnu. My build has c++ as an enabled language, and most other c++ and libstdc++ tests work, so I don't think this is a dupe of PR44048. -- mikpe at it dot uu dot se changed: What|Removed |Added CC||mikpe at it dot uu dot se http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44099
[Bug target/44099] ICE in g++.dg/debug/nullptr01.C test on Solaris 2/SPARC
--- Comment #4 from jason at gcc dot gnu dot org 2010-05-12 19:20 --- I marked it as a dupe because it has the same cause, though different specific effects. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC|jason at redhat dot com | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44099
[Bug fortran/37039] Cray pointer with pointee DIMENSION statement after POINTER statement
--- Comment #5 from langton at gcc dot gnu dot org 2010-05-12 19:37 --- The patch I posted isn't correct. It causes a regression in gfortran.dg/cray_pointers_2.f90. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37039
[Bug other/43977] Patches from oldlto branch to be salvaged
--- Comment #8 from froydnj at gcc dot gnu dot org 2010-05-12 19:52 --- r114536 has been committed as r159340. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43977
[Bug middle-end/44069] [4.5 Regression] optimization bug initializing from cast array
--- Comment #5 from rguenth at gcc dot gnu dot org 2010-05-12 20:16 --- So, the issue is that the loop copying vals to m looks like : D.21310_23 = r_22 * 4; D.21309_25 = D.21310_23 + c_24; D.21308_26 = (long unsigned int) D.21309_25; D.21305_29 = vals[0][D.21308_26]; m.m[D.21309_25] = D.21305_29; c_30 = c_24 + 1; : # c_24 = PHI if (c_24 <= 3) goto ; else goto ; : r_31 = r_22 + 1; : # r_22 = PHI <0(2), r_31(5)> if (r_22 <= 3) goto ; else goto ; : # c_32 = PHI <0(6)> goto ; where vals[0][D.21308_26] does not represent a use of vals[i][j] with i > 0. This is because get_ref_base_and_extent restricts the valid extent of D.21308_26 to 3. Note that the issue is exposed by re-constructing an array-reference from the pointer access in the inlined constructor. After inlining into main() we have : D.21310_23 = r_22 * 4; D.21309_25 = D.21310_23 + c_24; D.21308_26 = (long unsigned int) D.21309_25; D.21307_27 = D.21308_26 * 8; D.21306_28 = &vals[0][D.21308_26]; D.21305_29 = *D.21306_28; m.m[D.21309_25] = D.21305_29; c_30 = c_24 + 1; from the non-inlined variant : D.21286_7 = r_1 * 4; D.21287_8 = D.21286_7 + c_2; D.21286_9 = r_1 * 4; D.21287_10 = D.21286_9 + c_2; D.21288_11 = (long unsigned int) D.21287_10; D.21289_12 = D.21288_11 * 8; D.21290_14 = arr_13(D) + D.21289_12; D.21291_15 = *D.21290_14; this_16(D)->m[D.21287_10] = D.21291_15; c_17 = c_2 + 1; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |middle-end Keywords||wrong-code Summary|optimization bug|[4.5 Regression] |initializing from cast array|optimization bug ||initializing from cast array Target Milestone|--- |4.5.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44069
[Bug other/39979] [4.4/4.5/4.6 Regression] possible wrong code at all -0x levels.
--- Comment #16 from pluto at agmk dot net 2010-05-12 20:27 --- (In reply to comment #15) > the problematic is eh_globals.o which was merged into libstlport.a. > the TLS version of the get_globals causes memory corruption in my app. > strictly, the __thread based eh_globals.cc doesn't work with pthread based stlport-5.2.1. libsupc++ configured with --disable-tls (forced tls via pthread get/set specific) works fine with stlport again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
[Bug other/39979] [4.4/4.5/4.6 Regression] libsupc++(eh_globals.cc)/stlport TLS incompatibility.
--- Comment #17 from pinskia at gcc dot gnu dot org 2010-05-12 20:54 --- Not a bug, you need to configure libstdc++ and stlport the same if you want them to work together. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39979
