[Bug fortran/35959] Recursive function with allocatable array
--- Comment #1 from pault at gcc dot gnu dot org 2008-04-17 05:59 ---
Here is a further reduced version of the testcase:
program testprog
type :: t_type
integer, dimension(:), allocatable :: chars
end type t_type
integer, save :: callnb = 0
type(t_type) :: this
allocate ( this % chars ( 4))
print * , match :, recursivefunc ( this ), callnb
contains
recursive function recursivefunc ( this ) result ( match )
type(t_type), intent(in) :: this
type(t_type) :: subpattern
logical :: match
callnb = callnb + 1
match = (callnb == 10)
if ((.NOT. allocated (this % chars)) .OR. match) return
allocate ( subpattern % chars ( 4 ) )
match = recursivefunc ( subpattern )
end function recursivefunc
end program testprog
The code that the function produces is:
recursivefunc (struct t_type this)
{
logical(kind=4) match;
static struct t_type subpattern = {};
subpattern.chars.data = 0B;
callnb = callnb + 1;
match = callnb == 10;
if ((integer(kind=4)[0:] *) this-chars.data == 0B || match) goto
__return_recursivefunc;
{
void * D.998;
subpattern.chars.dtype = 265;
subpattern.chars.dim[0].lbound = 1;
subpattern.chars.dim[0].ubound = 4;
subpattern.chars.dim[0].stride = 1;
if (subpattern.chars.data == 0B)
{
{
void * D.999;
D.999 = __builtin_malloc (16);
if (D.999 == 0B)
{
_gfortran_os_error (Out of memory[1]{lb: 1 sz: 1});
}
D.998 = D.999;
}
}
else
{
_gfortran_runtime_error (Attempting to allocate already allocated
array[1]{lb: 1 sz: 1});
}
subpattern.chars.data = D.998;
subpattern.chars.offset = -1;
}
match = recursivefunc (subpattern);
__return_recursivefunc:;
if (subpattern.chars.data != 0B)
{
__builtin_free (subpattern.chars.data);
}
subpattern.chars.data = 0B;
return match;
}
Being a local variable in a recursive procedure, it is declared to be static.
Having allocatable components, it is nullified on entry to the procedure. This
explains the observed behaviour.
I believe that it is a bug but will have to take a close look at the standard
to confirm it - in fact, I have a suspicion that it might not be covered. If
the latter is the case, I would be inclined to modify gfortran because the
unexpectd behaviour.
Confirmed for now
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
CC||pault at gcc dot gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-04-17 05:59:41
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35959
[Bug bootstrap/27794] stack explosion
--- Comment #8 from cnstar9988 at gmail dot com 2008-04-17 06:55 --- gcc 4.2.2 hp ia64 11.23 Possible causes: insufficient memory or swap space, or stack size exceeded maxssiz. make[4]: *** [libgcc/hpux64/__divxf3.o] Segmentation fault (core dumped) make[4]: Leaving directory `/os/build/gcc-4.2.2-build/build/gcc' make[3]: *** [stmp-multilib] Error 2 make[3]: Leaving directory `/os/build/gcc-4.2.2-build/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/os/build/gcc-4.2.2-build/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/os/build/gcc-4.2.2-build/build' make: *** [all] Error 2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
[Bug fortran/35944] [4.3 Regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #8 from uros at gcc dot gnu dot org 2008-04-17 07:08 --- Subject: Bug 35944 Author: uros Date: Thu Apr 17 07:07:45 2008 New Revision: 134381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134381 Log: Backport from mainline: 2008-04-16 Uros Bizjak [EMAIL PROTECTED] PR target/35944 * config/i386/i386.md (fmodxf3): Copy operand 1 and operand 2 into temporary registers. Change operand predicate to general_operand. (remainderxf3): Ditto. testsuite/ChangeLog: Backport from mainline: 2008-04-16 Francois-Xavier Coudert [EMAIL PROTECTED] PR target/35944 * gfortran.dg/pr35944-1.f90: New test. * gfortran.dg/pr35944-2.f90: Ditto. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/pr35944-1.f90 - copied unchanged from r134359, trunk/gcc/testsuite/gfortran.dg/pr35944-1.f90 branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/pr35944-2.f90 - copied unchanged from r134359, trunk/gcc/testsuite/gfortran.dg/pr35944-2.f90 Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/i386/i386.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug fortran/35947] [4.3, 4.4 regression] wrong answers with array constructor argument to IEOR
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35947
[Bug fortran/35724] [4.3/4.4 Regression] Compile time segmentation fault for CSHIFT with negative third arg
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35724
[Bug target/35944] [4.3 Regression] wrong result for MOD with kind=10 for some array argument values
--- Comment #9 from ubizjak at gmail dot com 2008-04-17 07:10 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|fortran |target GCC target triplet||i686-pc-linux-gnu Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35944
[Bug bootstrap/27794] stack explosion
--- Comment #9 from cnstar9988 at gmail dot com 2008-04-17 07:18 --- gcc 4.2.2 hp ia64 11.23 build failed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #19 from jakub at gcc dot gnu dot org 2008-04-17 07:20 --- Bootstrapped/regtested on gcc-4_3-branch as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug fortran/34004] Accepts invalid: Ambigiuous interface with subroutine.
--- Comment #4 from fxcoudert at gcc dot gnu dot org 2008-04-17 07:30 --- More talk about that recently: http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ff402a68a17d2be9/543de4c347caa9d0 This is well described in the last example of C.11.2. -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-17 07:30:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34004
[Bug fortran/35946] [4.3, 4.4 regression] wrong result with array constructor as argument to ATAN2
--- Comment #2 from ubizjak at gmail dot com 2008-04-17 08:21 --- Marked as a regression. -- ubizjak at gmail dot com changed: What|Removed |Added Summary|wrong result with array |[4.3, 4.4 regression] wrong |constructor as argument to |result with array |ATAN2 |constructor as argument to ||ATAN2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35946
[Bug bootstrap/35933] local variable used before set in fold-const.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-17 08:34 --- This is fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35933
[Bug fortran/35962] New: Should warn about precision loss on integer conversions in fortran
If I assign a long integer to a short integer gfortran should warn about possible loss of precision, such as g95 does. Thanks, Jonathan. Full test case: [EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec $ gfortran-4.3 -Wall -pedantic -o test test.f90 [EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec $ ./test lvar =8589934592 svar =0 lvar =1073741824 svar = 1073741824 [EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec $ gfortran-4.3 -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --program-suffix=-4.3 Thread model: posix gcc version 4.3.0 (GCC) [EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec $ cat test.f90 program test implicit none integer, parameter :: short = kind(0) integer, parameter :: long = selected_int_kind(18) integer(short) :: svar integer(long) :: lvar lvar = 2_long**33 svar = lvar print *, lvar = , lvar print *, svar = , svar lvar = 2_long**30 svar = lvar print *, lvar = , lvar print *, svar = , svar end program -- Summary: Should warn about precision loss on integer conversions in fortran Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: J dot Hogg at rl dot ac dot uk 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=35962
[Bug fortran/35962] Should warn about precision loss on integer conversions in fortran
--- Comment #1 from burnus at gcc dot gnu dot org 2008-04-17 08:50 --- Can you try: -Wconversion Warn about implicit conversions between different types. It might be a bit verbose as it, e.g., also warns for complex(8) = real(8), which has no conversion problem, but otherwise it is ok. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35962
[Bug fortran/35946] [4.3, 4.4 regression] wrong result with array constructor as argument to ATAN2
--- Comment #3 from ubizjak at gmail dot com 2008-04-17 08:56 --- The second argument, passed to ATAN2 is off by one, i.e. instead of atan2(1,10), atan2 (1,9) is passed. atan2 (1,10) = 0.09967 (* expected) atan2 (1,9) = 0.11066 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35946
[Bug fortran/35946] [4.3, 4.4 regression] wrong result with array constructor as argument to ATAN2
--- Comment #4 from ubizjak at gmail dot com 2008-04-17 09:15 ---
The difference between non-working (---) and working (+++) asm is:
--- pr35946.s_ 2008-04-17 11:07:19.0 +0200
+++ pr35946.s 2008-04-17 11:07:28.0 +0200
@@ -188,7 +188,7 @@
.p2align 3
.L16:
movlA.7.603(%ebx), %eax
- fildl 4(%edi,%ebx)
+ fildl (%edi,%ebx)
fstps 4(%esp)
movl%eax, (%esp)
callatan2f
The problem can be seen in .003.t.orignal:
S.12 = 1;
while (1)
{
if (S.12 10) goto L.4;
dda1[S.12 + -1] = __builtin_atan2f (A.7[S.12 + -1], (real(kind=4))
(*(integer(kind=4)[10] *) atmp.8.data)[S.12]);
S.12 = S.12 + 1;
}
Please note off-by one in the last index.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35946
[Bug fortran/35962] Should warn about precision loss on integer conversions in fortran
--- Comment #2 from J dot Hogg at rl dot ac dot uk 2008-04-17 09:33 --- That seems to fix the original complaint with the following output: [EMAIL PROTECTED] ~/bugs/gfortran-4.3/ls_prec $ gfortran-4.3 -Wall -pedantic -Wconversion -o test test.f90 test.f90:10.20: lvar = 2_long**33 1 Warning: Conversion from INTEGER(4) to INTEGER(8) at (1) test.f90:16.20: lvar = 2_long**30 1 Warning: Conversion from INTEGER(4) to INTEGER(8) at (1) test.f90:11.10: svar = lvar 1 Warning: Conversion from INTEGER(8) to INTEGER(4) at (1) test.f90:17.10: svar = lvar 1 Warning: Conversion from INTEGER(8) to INTEGER(4) at (1) Apologies for wasting your time in that respect, though as you say it is a little verbose and a happy medium between the two would be appreciated. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35962
[Bug c/35963] New: [IRA] wrong
On the IRA branch (using revision 134357) compiling linux-2.6.24.4/arch/x86/video.c for i386 fails with: /there.pentium4/build_i386/staging_dir/usr/bin/i386-linux-uclibc-gcc -fomit-frame-pointer -Os -mtune=i386 -fira -c -o bug.o emitting_wrong_bpl_or_dil.c emitting_wrong_bpl_or_dil.c: Assembler messages: emitting_wrong_bpl_or_dil.c:23: Error: bad register name `%bpl' $ /there.pentium4/build_i386/staging_dir/usr/bin/i386-linux-uclibc-gcc -fomit-frame-pointer -Os -mtune=i386 -fira -c -o bug.o emitting_wrong_bpl_or_dil.c -DDIL emitting_wrong_bpl_or_dil.c: Assembler messages: emitting_wrong_bpl_or_dil.c:23: Error: bad register name `%dil' -- Summary: [IRA] wrong Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code, assemble-failure Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug c/35963] [IRA] uses wrong ops
--- Comment #1 from aldot at gcc dot gnu dot org 2008-04-17 10:01 --- Created an attachment (id=15484) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15484action=view) smallish testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug inline-asm/35963] [IRA] uses wrong ops
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-04-17 10:33 --- I think the inline-asm is wrong. asm volatile (movb %%fs:%1,%0:=r (v):m(*(unsigned char *) addr) ); =r is wrong here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |inline-asm http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug c/35963] [IRA] uses wrong ops
--- Comment #3 from aldot at gcc dot gnu dot org 2008-04-17 11:07 --- It compiles just fine with the old RA. If the =r is wrong, then shouldn't it be rejected also with -fno-ira? -- aldot at gcc dot gnu dot org changed: What|Removed |Added Component|inline-asm |c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug inline-asm/35963] [IRA] uses wrong ops
--- Comment #4 from aldot at gcc dot gnu dot org 2008-04-17 11:13 --- Sounds a little bit like PR6142 popped up again via IRA. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug c/35964] New: ICE with -funroll-loops on arm/arm eabi
Since the upgrade to gcc-4.3, gcc has started to ICE on selected packages. After some debugging, all cases so far seem to relate to using -funroll-loops, so I'll start putting all ICE's to same bugreport. Using built-in specs. Target: arm-linux-gnueabi Configured with: ../src/configure linux gnueabi Thread model: posix gcc version 4.3.1 20080401 (prerelease) (Debian 4.3.0-3) libcoveb: coveb-tree.i: $ gcc-4.3 -S -g -O2 -funroll-loops coveb-tree.i ../../../src/coveb-tree.c: In function 'coveb__ibq_remove': ../../../src/coveb-tree.c:1053: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. Removing -funroll-loops make compile succeed. john: $ gcc -S -Wall -O2 -fomit-frame-pointer -funroll-loops DES_bs.i DES_bs.c: In function 'DES_bs_cmp_all': DES_bs.c:175: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. Removing -funroll-loops make compile succeed. pymol: $ gcc -g -O2 -fwrapv -funroll-loops -S Match.i layer0/Match.c: In function 'MatchAlign': layer0/Match.c:578: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. removing either -funroll-loops or -fwrapv makes compile succeed. openarena: $ gcc -S -O3 -ffast-math -funroll-loops files.i code/qcommon/files.c: In function 'FS_Seek': code/qcommon/files.c:1454: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. Removing -funroll-loops make compile succeed. -- Summary: ICE with -funroll-loops on arm/arm eabi Product: gcc Version: 4.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: riku dot voipio at iki dot fi GCC build triplet: arm-linux-gnueabi GCC host triplet: arm-linux-gnueabi GCC target triplet: arm-linux-gnueabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug inline-asm/35963] [IRA] uses wrong ops
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-17 11:16 --- (In reply to comment #3) It compiles just fine with the old RA. If the =r is wrong, then shouldn't it be rejected also with -fno-ira? Why, the old RA is choosing just happens to be the right one. =q or =R is the correct constraint according to the manual. *** This bug has been marked as a duplicate of 35102 *** *** This bug has been marked as a duplicate of 35102 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug target/35102] i386-*gcc: bad register name `%sil'
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-17 11:16 --- *** Bug 35963 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aldot at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
[Bug inline-asm/35963] [IRA] uses wrong ops
--- Comment #6 from pinskia at gcc dot gnu dot org 2008-04-17 11:17 --- (In reply to comment #4) Sounds a little bit like PR6142 popped up again via IRA. If you read what the patch does there, it changes the constraints of the internal patterns from r to q so this is not a bug :). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #1 from riku dot voipio at iki dot fi 2008-04-17 11:19 --- Created an attachment (id=15485) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15485action=view) test case from libcoveb ICE when compiled as: gcc-4.3 -S -g -O2 -funroll-loops coveb-tree.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #2 from riku dot voipio at iki dot fi 2008-04-17 11:22 --- Created an attachment (id=15486) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15486action=view) test case from john gcc -S -Wall -O2 -fomit-frame-pointer -funroll-loops DES_bs.i DES_bs.c: In function 'DES_bs_cmp_all': DES_bs.c:175: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. Removing -funroll-loops make compile succeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #3 from riku dot voipio at iki dot fi 2008-04-17 11:23 --- Created an attachment (id=15487) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15487action=view) test case from openarena, a quake3 port gcc -S -O3 -ffast-math -funroll-loops files.i code/qcommon/files.c: In function 'FS_Seek': code/qcommon/files.c:1454: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. Removing -funroll-loops make compile succeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #4 from riku dot voipio at iki dot fi 2008-04-17 11:24 --- Created an attachment (id=15488) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15488action=view) test case from pymol $ gcc -g -O2 -fwrapv -funroll-loops -S Match.i layer0/Match.c: In function 'MatchAlign': layer0/Match.c:578: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.3/README.Bugs for instructions. removing either -funroll-loops or -fwrapv makes compile succeed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug middle-end/35964] ICE with -funroll-loops on arm/arm eabi
--- Comment #5 from riku dot voipio at iki dot fi 2008-04-17 11:32 --- Current debian/arm eabi gcc is built as: Package source: gcc-4.3 GCC version: 4.3.1 Base Debian version: 4.3 Configured with: -v --with-pkgversion='Debian 4.3.0-3' --with-bugurl='file:///usr/share/doc/gcc-4.3/README.Bugs' --enable-languages=c,c++,fortran,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-libffi --enable-mpfr --disable-libssp --disable-sjlj-exceptions --enable-checking=release --build=arm-linux-gnueabi --host=arm-linux-gnueabi --target=arm-linux-gnueabi Target: arm-linux-gnueabi Configured with: ../src/configure linux gnueabi Thread model: posix gcc version 4.3.1 20080401 (prerelease) (Debian 4.3.0-3) all6500-2:/usr/share/doc/gcc-4.3# -- riku dot voipio at iki dot fi changed: What|Removed |Added Keywords||ice-on-valid-code http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964
[Bug inline-asm/35963] [IRA] uses wrong ops
--- Comment #7 from aldot at gcc dot gnu dot org 2008-04-17 11:32 --- Changing the attached testcase to use either =q or =R makes no difference, it still tries to emit the wrong thing, thus reopening. -- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug c/35965] New: -fstack-protector produces segfaulting binaries on arm/armel
-snip-
#include stdio.h
main()
{
printf (Hello World!\n);
}
-snip-
$ gcc -save-temps -fstack-protector -fPIE hello.c -o hello
$ ./hello
$ Hello World!
$ gcc -save-temps -fstack-protector-all -fPIE helloall.c -o helloall
$ ./helloall
$ Segmentation fault
helloall.s segfaults, hello.s runs fine. if -fstack-protector isn't to
be supported on arm, it gcc should ignore the option like done on
mips/mipsel.
Package source: gcc-4.3
GCC version: 4.3.1
Base Debian version: 4.3
Configured with: -v
--with-pkgversion='Debian 4.3.0-3'
--with-bugurl='file:///usr/share/doc/gcc-4.3/README.Bugs'
--enable-languages=c,c++,fortran,obj-c++
--prefix=/usr
--enable-shared
--with-system-zlib
--libexecdir=/usr/lib
--without-included-gettext
--enable-threads=posix
--enable-nls
--with-gxx-include-dir=/usr/include/c++/4.3
--program-suffix=-4.3
--enable-clocale=gnu
--enable-libstdcxx-debug
--enable-libffi
--enable-mpfr
--disable-libssp
--disable-sjlj-exceptions
--enable-checking=release
--build=arm-linux-gnueabi
--host=arm-linux-gnueabi
--target=arm-linux-gnueabi
Target: arm-linux-gnueabi
Configured with: ../src/configure linux gnueabi
Thread model: posix
gcc version 4.3.1 20080401 (prerelease) (Debian 4.3.0-3)
--
Summary: -fstack-protector produces segfaulting binaries on
arm/armel
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: riku dot voipio at iki dot fi
GCC build triplet: arm-linux-gnueabi
GCC host triplet: arm-linux-gnueabi
GCC target triplet: arm-linux-gnueabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35965
[Bug c/35965] -fstack-protector produces segfaulting binaries on arm/armel
--- Comment #1 from riku dot voipio at iki dot fi 2008-04-17 11:48 --- Created an attachment (id=15489) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15489action=view) working arm assembly produced from hello world -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35965
[Bug c/35965] -fstack-protector produces segfaulting binaries on arm/armel
--- Comment #2 from riku dot voipio at iki dot fi 2008-04-17 11:49 --- Created an attachment (id=15490) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15490action=view) segfaulting arm assemble of hello world -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35965
[Bug target/35102] i386-*gcc: bad register name `%sil'
--- Comment #4 from aldot at gcc dot gnu dot org 2008-04-17 12:03 --- *** Bug 35963 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35102
[Bug inline-asm/35963] [IRA] uses wrong ops
--- Comment #8 from aldot at gcc dot gnu dot org 2008-04-17 12:03 --- fixing the constraint and all is well. Thanks, Andrew! *** This bug has been marked as a duplicate of 35102 *** -- aldot at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35963
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #20 from amodra at gcc dot gnu dot org 2008-04-17 12:28 --- Subject: Bug 35907 Author: amodra Date: Thu Apr 17 12:27:31 2008 New Revision: 134387 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134387 Log: PR target/35907 * config/rs6000/rs6000.c (rs6000_emit_epilogue): Restore vr and vrsave regs before frame pop when needed. If use_backchain_to_restore_sp then load backchain into a temp reg to restore vr and vrsave. Add code to restore vr after frame pop if possible. Modified: trunk/gcc/ChangeLog trunk/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #21 from amodra at gcc dot gnu dot org 2008-04-17 12:28 --- Subject: Bug 35907 Author: amodra Date: Thu Apr 17 12:27:56 2008 New Revision: 134388 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134388 Log: PR target/35907 * config/rs6000/rs6000.c (rs6000_emit_epilogue): Restore vr and vrsave regs before frame pop when needed. If use_backchain_to_restore_sp then load backchain into a temp reg to restore vr and vrsave. Add code to restore vr after frame pop if possible. Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug target/35907] [4.3/4.4 Regression] 64-bit power6 glibc miscompilation
--- Comment #22 from amodra at bigpond dot net dot au 2008-04-17 12:29 --- Fixed -- amodra at bigpond dot net dot au changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35907
[Bug fortran/35946] [4.3, 4.4 regression] wrong result with array constructor as argument to ATAN2
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35946
[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert
--- Comment #4 from bonzini at gnu dot org 2008-04-17 13:01 --- I wonder is PR34824 should be reverted then? -- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773
[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert
-- 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|2008-03-31 20:07:09 |2008-04-17 13:48:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773
[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert
--- Comment #5 from jason at gcc dot gnu dot org 2008-04-17 14:02 --- Subject: Bug 35773 Author: jason Date: Thu Apr 17 14:01:26 2008 New Revision: 134398 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134398 Log: PR c++/35773 * cp/call.c (build_user_type_conversion_1): Represent second step of copy-init with an rvalue conversion. (convert_like_real) [ck_user]: Don't implicitly add it here. * g++.dg/overload/autoptr1.C: New. Added: trunk/gcc/testsuite/g++.dg/overload/autoptr1.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773
[Bug c++/35966] New: array-subscript-above-bounds warning disappears when unrelated constructor definition is added
If I have the following three files:
/usr/include/blub.hpp:
struct Y { virtual ~Y(); };
struct X: Y { X(); };
t.cpp
#include blub.hpp
int main() { int i[3]; return i[3]; }
t2.cpp
#include blub.hpp
int main() { int i[3]; return i[3]; }
X::X() {}
then g++ -O2 -Wall -c t.cpp correctly warns
t.cpp:2: warning: array subscript is above array bounds
However, g++ -O2 -Wall -c t2.cpp is silent.
In other words, the warning disappears when X::X() is defined. This makes no
sense, because X has nothing to do with the array subscript.
Even weirder, the warning reappears if blub.hpp is either located elsewhere or
included manually by copy+paste-ing its contents.
Bug 35587 seems related, though it doesn't have the #include weirdness.
Problem is reproducible with gcc 4.3.0 20080106 (experimental) on SUSE 10.2,
and on Debian sid using the gcc-4.3 4.3.0-3 package.
--
Summary: array-subscript-above-bounds warning disappears when
unrelated constructor definition is added
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35966
[Bug c++/35966] array-subscript-above-bounds warning disappears when unrelated constructor definition is added
--- Comment #1 from chris at chris-lamb dot co dot uk 2008-04-17 14:26 --- Confirmed using 20080417's SVN HEAD under Debian unstable. -- chris at chris-lamb dot co dot uk changed: What|Removed |Added CC||chris at chris-lamb dot co ||dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35966
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #14 from rguenth at gcc dot gnu dot org 2008-04-17 15:09 --- Created an attachment (id=15491) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15491action=view) gimple semantics change patch This is the variant I thought about with changing the way types are interpreted for the *CREMENT_EXPRs. The usual problem with vectorizer tests appear as SCEV doesn't handle for example bb 3: # i_14 = PHI i_7(5), 0(2) D.1560_4 = (int) i_14; a[D.1560_4] = D.1560_4; D.1561_6 = D.1560_4 + 1; i_7 = (short int) D.1561_6; if (i_7 = 63) goto bb 5; else goto bb 4; but for correctness reasons we cannot do the increment in signed short int due to the undefined overflow issue. We can avoid the promotion if the result is truncated to an unsigned type (but this is an optimization that I didn't want to put into this patch addressing correctness only). I will re-test this patch, a slightly oder version tested ok apart from the vectorizer fallout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug bootstrap/35169] SIGSEGV for stack growth failure while building 4.2.3
--- Comment #6 from cnstar9988 at gmail dot com 2008-04-17 15:09 --- same as PR27794? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27794 confirmed, gcc 4.2.2 hp ia64 11.23 Possible causes: insufficient memory or swap space, or stack size exceeded maxssiz. make[4]: *** [libgcc/hpux64/__divxf3.o] Segmentation fault (core dumped) make[4]: Leaving directory `/os/build/gcc-4.2.2-build/build/gcc' make[3]: *** [stmp-multilib] Error 2 make[3]: Leaving directory `/os/build/gcc-4.2.2-build/build/gcc' make[2]: *** [all-stage1-gcc] Error 2 make[2]: Leaving directory `/os/build/gcc-4.2.2-build/build' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/os/build/gcc-4.2.2-build/build' make: *** [all] Error 2 -- cnstar9988 at gmail dot com changed: What|Removed |Added CC||cnstar9988 at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35169
[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert
--- Comment #6 from jason at gcc dot gnu dot org 2008-04-17 16:11 --- Subject: Bug 35773 Author: jason Date: Thu Apr 17 16:10:36 2008 New Revision: 134399 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134399 Log: PR c++/35773 * cp/call.c (build_user_type_conversion_1): Represent second step of copy-init with an rvalue conversion. (convert_like_real) [ck_user]: Don't implicitly add it here. * g++.dg/overload/autoptr1.C: New. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/overload/autoptr1.C - copied unchanged from r134398, trunk/gcc/testsuite/g++.dg/overload/autoptr1.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/call.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35773
[Bug c++/35773] [4.3/4.4 regression] auto_ptr references don't convert
--- Comment #7 from jakub at gcc dot gnu dot org 2008-04-17 16:29 --- Fixed, thanks. -- 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=35773
[Bug libgcj/35950] jar produces files ecj won't handle
--- Comment #5 from tromey at gcc dot gnu dot org 2008-04-17 17:16 --- Subject: Bug 35950 Author: tromey Date: Thu Apr 17 17:15:10 2008 New Revision: 134401 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134401 Log: PR libgcj/35950: * tools/gnu/classpath/tools/jar/Entry.java: New version from Classpath. * tools/classes/gnu/classpath/tools/jar/Entry.class: Update. Modified: branches/gcc-4_3-branch/libjava/classpath/ChangeLog.gcj branches/gcc-4_3-branch/libjava/classpath/tools/classes/gnu/classpath/tools/jar/Entry.class branches/gcc-4_3-branch/libjava/classpath/tools/gnu/classpath/tools/jar/Entry.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35950
[Bug libgcj/35950] jar produces files ecj won't handle
--- Comment #6 from tromey at gcc dot gnu dot org 2008-04-17 17:16 --- Subject: Bug 35950 Author: tromey Date: Thu Apr 17 17:16:09 2008 New Revision: 134402 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134402 Log: PR libgcj/35950: * tools/gnu/classpath/tools/jar/Entry.java: New version from Classpath. * tools/classes/gnu/classpath/tools/jar/Entry.class: Update. Modified: trunk/libjava/classpath/ChangeLog.gcj trunk/libjava/classpath/tools/classes/gnu/classpath/tools/jar/Entry.class trunk/libjava/classpath/tools/gnu/classpath/tools/jar/Entry.java -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35950
[Bug libgcj/35950] jar produces files ecj won't handle
--- Comment #7 from tromey at gcc dot gnu dot org 2008-04-17 17:18 --- Fixed on 4.3 branch and trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35950
[Bug c/35436] [4.1/4.2/4.3 regression] ICE with attribute format
--- Comment #4 from reichelt at gcc dot gnu dot org 2008-04-17 19:32 --- Subject: Bug 35436 Author: reichelt Date: Thu Apr 17 19:31:45 2008 New Revision: 134405 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134405 Log: PR c/35436 * c-format.c (init_dynamic_gfc_info): Ignore invalid locus type. * gcc.dg/format/gcc_gfc-2.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/format/gcc_gfc-2.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/c-format.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35436
[Bug c/35744] [4.1/4.2/4.3 regression] ICE attributes for invalid types
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-04-17 19:35 --- Subject: Bug 35744 Author: reichelt Date: Thu Apr 17 19:34:43 2008 New Revision: 134406 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134406 Log: PR c/35744 * attribs.c (decl_attributes): Return early on errorneous node. * gcc.dg/attr-error-1.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.dg/attr-error-1.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/attribs.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35744
[Bug objc++/35967] New: Local variables interpreted as volatile following a @try block
Test case:
- start file bug.mm
@interface TestClass
-(void) testMethod;
@end
void ff (int i)
{
}
@implementation TestClass
-(void) testMethod
{
int i = 1;
int iref = i;
@try
{}
@catch (id)
{}
@finally
{}
ff (i); // Bug
ff (iref); // OK
}
@end
- end file
gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build 5370)
gcc-4.0 -x objective-c++ -fobjc-exceptions -c bug.mm
bug.mm: In function 'void -[TestClass testMethod](TestClass*, objc_selector*)':
bug.mm:23: error: invalid initialization of reference of type 'int' from
expression of type 'volatile int'
bug.mm:5: error: in passing argument 1 of 'void ff(int)'
Summary:
Adding Obj-C try/catch/finally blocks causes i to be considered volatile
afterwards.
Workaround:
Create a reference to i and use that instead.
--
Summary: Local variables interpreted as volatile following a @try
block
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ymeroz at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967
[Bug c/35436] [4.1/4.2/4.3 regression] ICE with attribute format
--- Comment #5 from reichelt at gcc dot gnu dot org 2008-04-17 19:40 --- Subject: Bug 35436 Author: reichelt Date: Thu Apr 17 19:40:03 2008 New Revision: 134408 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134408 Log: PR c/35436 * c-format.c (init_dynamic_gfc_info): Ignore invalid locus type. * gcc.dg/format/gcc_gfc-2.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/format/gcc_gfc-2.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/c-format.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35436
[Bug c/35744] [4.1/4.2/4.3 regression] ICE attributes for invalid types
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-04-17 19:42 --- Subject: Bug 35744 Author: reichelt Date: Thu Apr 17 19:41:50 2008 New Revision: 134409 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134409 Log: PR c/35744 * attribs.c (decl_attributes): Return early on errorneous node. * gcc.dg/attr-error-1.c: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/attr-error-1.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/attribs.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35744
[Bug c/35436] [4.1 regression] ICE with attribute format
--- Comment #6 from reichelt at gcc dot gnu dot org 2008-04-17 19:47 --- Now also fixed on 4.3 and 4.2 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|reichelt at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.1/4.2/4.3 regression] ICE|[4.1 regression] ICE with |with attribute format |attribute format http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35436
[Bug c/35744] [4.1 regression] ICE attributes for invalid types
--- Comment #7 from reichelt at gcc dot gnu dot org 2008-04-17 19:48 --- Now also fixed on 4.3 and 4.2 branch. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|reichelt at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.1/4.2/4.3 regression] ICE|[4.1 regression] ICE |attributes for invalid types|attributes for invalid types http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35744
Re: [Bug objc++/35967] New: Local variables interpreted as volatile following a @try block
Sent from my iPhone
On Apr 17, 2008, at 12:37, ymeroz at earthlink dot net [EMAIL PROTECTED]
wrote:
Test case:
- start file bug.mm
@interface TestClass
-(void) testMethod;
@end
void ff (int i)
{
}
@implementation TestClass
-(void) testMethod
{
int i = 1;
int iref = i;
@try
{}
@catch (id)
{}
@finally
{}
ff (i); // Bug
ff (iref); // OK
}
@end
- end file
This is a side effect of how the next runtime implements their
exceptions.
gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5370)
gcc-4.0 -x objective-c++ -fobjc-exceptions -c bug.mm
bug.mm: In function 'void -[TestClass testMethod](TestClass*,
objc_selector*)':
bug.mm:23: error: invalid initialization of reference of type 'int'
from
expression of type 'volatile int'
bug.mm:5: error: in passing argument 1 of 'void ff(int)'
Summary:
Adding Obj-C try/catch/finally blocks causes i to be considered
volatile
afterwards.
Workaround:
Create a reference to i and use that instead.
--
Summary: Local variables interpreted as volatile following
a @try
block
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ymeroz at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967
[Bug objc++/35967] Local variables interpreted as volatile following a @try block
--- Comment #1 from pinskia at gmail dot com 2008-04-17 19:58 ---
Subject: Re: New: Local variables interpreted as volatile following a @try
block
Sent from my iPhone
On Apr 17, 2008, at 12:37, ymeroz at earthlink dot net
[EMAIL PROTECTED]
wrote:
Test case:
- start file bug.mm
@interface TestClass
-(void) testMethod;
@end
void ff (int i)
{
}
@implementation TestClass
-(void) testMethod
{
int i = 1;
int iref = i;
@try
{}
@catch (id)
{}
@finally
{}
ff (i); // Bug
ff (iref); // OK
}
@end
- end file
This is a side effect of how the next runtime implements their
exceptions.
gcc --version
i686-apple-darwin8-gcc-4.0.1 (GCC) 4.0.1 (Apple Computer, Inc. build
5370)
gcc-4.0 -x objective-c++ -fobjc-exceptions -c bug.mm
bug.mm: In function 'void -[TestClass testMethod](TestClass*,
objc_selector*)':
bug.mm:23: error: invalid initialization of reference of type 'int'
from
expression of type 'volatile int'
bug.mm:5: error: in passing argument 1 of 'void ff(int)'
Summary:
Adding Obj-C try/catch/finally blocks causes i to be considered
volatile
afterwards.
Workaround:
Create a reference to i and use that instead.
--
Summary: Local variables interpreted as volatile following
a @try
block
Product: gcc
Version: 4.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: objc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ymeroz at earthlink dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967
[Bug bootstrap/32497] Crosscomiling native sh3 gcc on a 64-bit host fails
--- Comment #1 from uwe at netbsd dot org 2008-04-17 20:14 --- Created an attachment (id=15492) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15492action=view) Suggested fix Attached patch makes NetBSD/landisk (sh4) cross-build complete successfully on NetBSD/amd64, where it used to fail before. Native gcc built as part of the system (host sh3 - target sh3) works and produces binaries identical to binaries produced by the native compiler w/out this patch (cross-compiled from i386). The patch basically defers the choice of L/LL suffix until the moment when insn-*.c is compiled with correct HOST_WIDE* defines (gen*.c uses build machine HOST_WIDE* values, not target machine). There's still the problem (marked with XXX in the patch) with the minimim host wide decimal constant that I'm not sure how to address properly, short of always generating -1/+1 hack for all negative values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32497
[Bug middle-end/35838] [4.4 Regression] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others
--- Comment #8 from rsandifo at gcc dot gnu dot org 2008-04-17 20:20 --- Subject: Bug 35838 Author: rsandifo Date: Thu Apr 17 20:20:13 2008 New Revision: 134411 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134411 Log: gcc/ PR rtl-optimization/35838 * dse.c (find_shift_sequence): Use subreg_lowpart_offset to work out the byte offset of the first subreg. Modified: trunk/gcc/ChangeLog trunk/gcc/dse.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35838
[Bug rtl-optimization/35838] [4.4 Regression] FAIL: 22_locale/num_get/get/char/16.cc execution test, and 76 others
--- Comment #9 from rsandifo at gcc dot gnu dot org 2008-04-17 20:21 --- Patch applied. -- rsandifo at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Component|middle-end |rtl-optimization Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35838
[Bug fortran/35959] Recursive function with allocatable array
--- Comment #2 from pault at gcc dot gnu dot org 2008-04-17 20:37 --- This is indeed a bug. A fix will be posted in half an hour or so. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-04-17 05:59:41 |2008-04-17 20:37:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35959
[Bug libstdc++/35968] New: nth_element fails to meet its complexity requirements
nth_element in 4.3.0 fails to meet its complexity requirements. This is basically intraselect by Dave Musser. The question is What algorithm should you switch to when quickselect fails? In the codebase __heapselect() is called. But this in O(N * log N). __heapselect() is O(middle-first) + O((last-middle) * log(last-first)) which is O(N * log N) and the C++ standard requires nth_element to be O(N). __heapselect() is no use at all here. Better still is median-of-medians of groups of 5 (and plenty of proofs that it is O(N)) or approximate median finding and that is still O(N) See www.cs.wpi.edu/~hofri/medsel.pdf In the best or average case, intraselect is O(N) partitioning + O(1) finding a suitable partition element In the worse case, intraselect is O(N) partitioning + O(N) finding a suitable partition element Stephen Howe -- Summary: nth_element fails to meet its complexity requirements Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sjhowe at dial dot pipex dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35968
[Bug preprocessor/34866] valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c
--- Comment #2 from tromey at gcc dot gnu dot org 2008-04-17 20:44 --- Testing a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2008-01-19 10:54:32 |2008-04-17 20:44:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34866
[Bug fortran/35960] run time abort with assignment of RESHAPEd zero sized array
--- Comment #1 from tkoenig at gcc dot gnu dot org 2008-04-17 21:58 --- Confirmed. I'll take a look at this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2008-04-17 21:58:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35960
[Bug fortran/27866] Warn when casting, e.g. assigning a double precision to a real
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-04-17 22:00 --- *** Bug 35962 has been marked as a duplicate of this bug. *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||J dot Hogg at rl dot ac dot ||uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27866
[Bug fortran/35962] Should warn about precision loss on integer conversions in fortran
--- Comment #3 from tkoenig at gcc dot gnu dot org 2008-04-17 22:00 --- This is pretty much addressed in PR 27866. Closing as a duplicate. *** This bug has been marked as a duplicate of 27866 *** -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35962
[Bug objc++/35967] Local variables interpreted as volatile following a @try block
--- Comment #2 from ymeroz at earthlink dot net 2008-04-17 23:41 --- (In reply to comment #1) This is a side effect of how the next runtime implements their exceptions. This is a language syntax issue, as I see it. Variable type can not change by itself in mid-scope in C++ or Obj-C. This is not an issue of runtime implementation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967
Re: [Bug objc++/35967] Local variables interpreted as volatile following a @try block
On Thu, Apr 17, 2008 at 4:41 PM, ymeroz at earthlink dot net [EMAIL PROTECTED] wrote: This is a language syntax issue, as I see it. Variable type can not change by itself in mid-scope in C++ or Obj-C. This is not an issue of runtime implementation. It is a little of both really. The way the runtime implements @throw is via setjmp/longjmp and the compiler has to change them to volatile variables. I told Apple not to do this but I guess they never understood how exceptions are used. Thanks, Andrew Pinski
[Bug objc++/35967] Local variables interpreted as volatile following a @try block
--- Comment #3 from pinskia at gmail dot com 2008-04-18 00:17 --- Subject: Re: Local variables interpreted as volatile following a @try block On Thu, Apr 17, 2008 at 4:41 PM, ymeroz at earthlink dot net [EMAIL PROTECTED] wrote: This is a language syntax issue, as I see it. Variable type can not change by itself in mid-scope in C++ or Obj-C. This is not an issue of runtime implementation. It is a little of both really. The way the runtime implements @throw is via setjmp/longjmp and the compiler has to change them to volatile variables. I told Apple not to do this but I guess they never understood how exceptions are used. Thanks, Andrew Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35967
[Bug preprocessor/34866] valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c
--- Comment #3 from tromey at gcc dot gnu dot org 2008-04-18 00:59 --- Fixed on trunk. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Known to work||4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34866
[Bug preprocessor/34866] valgrind error indication in testsuite from errors.c:156:cpp_error with gcc.dg/cpp/Wmissingdirs.c
--- Comment #4 from tromey at gcc dot gnu dot org 2008-04-18 00:59 --- Subject: Bug 34866 Author: tromey Date: Fri Apr 18 00:58:58 2008 New Revision: 134421 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134421 Log: PR libcpp/34866: * errors.c (cpp_error): Don't reference a token before the start of the current run. Modified: trunk/libcpp/ChangeLog trunk/libcpp/errors.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34866
[Bug bootstrap/27367] [4.2/4.3 Regression] gstdint.h in libdecnumber is not cleaned up with make distclean
--- Comment #5 from pinskia at gcc dot gnu dot org 2008-04-18 02:21 --- Fixed on the trunk with: http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01408.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||bje at gcc dot gnu dot org Summary|[4.2/4.3/4.4 Regression]|[4.2/4.3 Regression] |gstdint.h in libdecnumber is|gstdint.h in libdecnumber is |not cleaned up with make|not cleaned up with make |distclean |distclean http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27367
[Bug libstdc++/35969] New: GLIBCXX_DEBUG: list::merge triggers bad assert
The attached preprocessed source when compiled with -D_GLIBCXX_DEBUG encounters
a runtime assert at the final call to splice. According to
http://www.sgi.com/tech/stl/List.html, all iterators remain valid after a merge
operation. I believe that libstdc++ is not updating the _M_sequence members of
the safe iterators merged into list1.
I've also attached unpreprocessed source with comments indicating the problem.
To reproduce the problem:
% g++ -D_GLIBCXX_DEBUG list.ii
% ./a.out
/usr/include/c++/4.2/debug/list:350:error: attempt to splice an iterator
from a different container.
Objects involved in the operation:
iterator __i @ 0x0xbfd5ea30 {
type =
N11__gnu_debug14_Safe_iteratorINSt6__norm14_List_iteratorIiEENSt7__debug4listIiSaIiE
(mutable iterator);
state = dereferenceable;
references sequence with type `NSt7__debug4listIiSaIiEEE' @ 0x0xbfd5ea30
}
sequence __x @ 0x0xbfd5e9c4 {
type = NSt7__debug4listIiSaIiEEE;
}
Aborted
--
Summary: GLIBCXX_DEBUG: list::merge triggers bad assert
Product: gcc
Version: 4.2.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: greened at obbligato dot org
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #1 from greened at obbligato dot org 2008-04-18 03:12 --- Created an attachment (id=15493) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15493action=view) Preprocessed source -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #2 from greened at obbligato dot org 2008-04-18 03:13 --- Created an attachment (id=15494) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15494action=view) Unpreprocessed source Includes comments describing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-18 03:23 --- I don't know if the SGI website has been updated to take into account what the C++ standard says. Since STL was originally from HP/SGI, that page is old and might not reflect reality any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #4 from greened at obbligato dot org 2008-04-18 03:26 --- Subject: Re: GLIBCXX_DEBUG: list::merge triggers bad assert pinskia at gcc dot gnu dot org wrote: --- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-18 03:23 --- I don't know if the SGI website has been updated to take into account what the C++ standard says. Since STL was originally from HP/SGI, that page is old and might not reflect reality any more. Sure. But not everyone has a copy of the standard. :) Can we get a ruling on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug middle-end/35970] New: except.c:3382: error: 'struct eh_status' has no member named 'call
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribut e -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gc c -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gcc-4.4.0/include -I../../gcc/gcc/../libdecnumber -I../../gcc/g cc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/expmed.c -o expmed.o gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict- prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribut e -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I. -I. -I../../gcc/gc c -I../../gcc/gcc/. -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I/opt/gnu/gcc/gcc-4.4.0/include -I../../gcc/gcc/../libdecnumber -I../../gcc/g cc/../libdecnumber/dpd -I../libdecnumber ../../gcc/gcc/expr.c -o expr.o ../../gcc/gcc/except.c: In function 'dw2_size_of_call_site_table': ../../gcc/gcc/except.c:3382: error: 'struct eh_status' has no member named 'call _site_data_used' ../../gcc/gcc/except.c:3388: error: 'struct eh_status' has no member named 'call _site_data' ../../gcc/gcc/except.c: In function 'sjlj_size_of_call_site_table': ../../gcc/gcc/except.c:3398: error: 'struct eh_status' has no member named 'call _site_data_used' ../../gcc/gcc/except.c:3404: error: 'struct eh_status' has no member named 'call _site_data' make[3]: *** [except.o] Error 1 -- Summary: except.c:3382: error: 'struct eh_status' has no member named 'call Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35970
[Bug libstdc++/35969] GLIBCXX_DEBUG: list::merge triggers bad assert
--- Comment #5 from greened at obbligato dot org 2008-04-18 04:16 --- Ok, the closest thing I could find is the 1998 draft standard: http://www.kuzbass.ru:8086/docs/isocpp/lib-containers.html#lib.sequences It says that splice invalidates only the iterators and references to the spliced elements. There is no statement about iterators for merge. So it seems like the testcase is invalid not due to the merge but due to the splices. GLIBCXX_DEBUG mode doesn't catch the problem with the splices since the iterator is still considered valid after the splice. For example, the second splce doesn't assert on an invalid iterator being passed to it. Perhaps this was changed in the final standard. It seems odd to me that splice and merge would invalidate iterators as iterator stability is a prime reason for using std::list and these operations don't destroy any sequence values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35969
[Bug libstdc++/35954] [4.3/4.4 Regression] cannot build from read-only source tree
--- Comment #1 from rwild at gcc dot gnu dot org 2008-04-18 05:26 --- Isn't it this change that broke the tree? | 2006-07-13 Benjamin Kosnik [EMAIL PROTECTED] | | * include/Makefile.am (pch*_output_anchor): Add. | (pch*_output): Use. | (CLEANFILES): Use. | * include/Makefile.in: Regenerate. shown here: http://gcc.gnu.org/ml/libstdc++/2006-07/msg00080.html. Hmm, maybe it was exposed only later. Proposed patch at http://gcc.gnu.org/ml/gcc-patches/2008-04/msg01412.html. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-04-18 05:26:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35954
[Bug middle-end/35970] except.c:3382: error: 'struct eh_status' has no member named 'call
--- Comment #1 from jh at suse dot cz 2008-04-18 05:40 --- Subject: Re: except.c:3382: error: 'struct eh_status' has no member named 'call Hi, I've comitted the fix this morning, hope it is OK now. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35970
