[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-26 09:31 --- Caused by http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01059.html aka r154354. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #5 from jakub at gcc dot gnu dot org 2009-11-26 09:42 --- The problem seems to be the new set_underlying_type call called from build_self_reference. Apparently the objc-act.c expects that type variants at that point are only created for some other purpose (don't know objc, so have no idea for what), and that they have TYPE_OBJC_INFO allocated, which is not the case for these self reference variants. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #6 from jakub at gcc dot gnu dot org 2009-11-26 09:47 --- Created an attachment (id=19152) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19152action=view) gcc45-pr42156.patch Untested patch. I'm not familiary with ObjC/ObjC++, so have no idea whether it is the right fix or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-26 09:56 ---
Aliasing rules are indeed broken because you access a union of anonymous type
through a pointer to a union of type ieee_double_extract.
I think you want
union { union ieee_double_extract d; unsigned long long i; } x;
x.d.d = 0.0 / 0.0;
printf (d = %g [%llx]\n, x.d.d, x.d.i);
printf (exp = %x\n, (unsigned int) x.d.s.exp);
return 0;
or even simplified.
--
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=42179
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #2 from d dot g dot gorbachev at gmail dot com 2009-11-26 11:02 --- note that there are no warnings A warning is issued with -Wstrict-aliasing=1 or -Wstrict-aliasing=2, but no warning with -Wstrict-aliasing=3 (or -Wall). I see there are already a few bug reports about this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-26 11:25 --- Correct. We can either produce possibly lots of false positives or not warn. Warning in the cases where we can prove your code is wrong would be pointless as in that case we'd better take measures to not miscompile it (and we then can do so as we were able to detect the situation). With 4.4 one alias warning machinery did exactly this (warn but then not miscompile - but then it didn't warn in cases where it _did_ miscompile). It's generally impossible to please all folks here ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
[Bug libstdc++/42182] New: memory errors using valarrays
The valarray mask_array implementation creates out of bound memory accesses when the number of the True bits is smaller that the size of array, although this is perfect legal. This produce valgrin error at best, sometime segfaults, or infinite loops. To reproduce, compile the attached test: g++ -O0 va0.cxx gnx2439$ valgrind ./a.out==1547== Memcheck, a memory error detector ==1547== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==1547== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==1547== Command: ./a.out ==1547== ==1547== Invalid read of size 1 ==1547==at 0x80489D1: void std::__valarray_copyint(std::_Arrayint, unsigned int, std::_Arrayint, std::_Arraybool) (in /home/bruel/tmp/a.out) ==1547==by 0x804889A: std::mask_arrayint::operator=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1547==by 0x80485C9: main (in /home/bruel/tmp/a.out) ==1547== Address 0x4129061 is 0 bytes after a block of size 1 alloc'd ==1547==at 0x40061CC: operator new(unsigned int) (vg_replace_malloc.c:214) ==1547==by 0x8048644: std::__valarray_get_memory(unsigned int) (in /home/bruel/tmp/a.out) ==1547==by 0x80488E6: bool* restrict std::__valarray_get_storagebool(unsigned int) (in /home/bruel/tmp/a.out) ==1547==by 0x80486EE: std::valarraybool::valarray(bool const, unsigned int) (in /home/bruel/tmp/a.out) ==1547==by 0x804857B: main (in /home/bruel/tmp/a.out) ==1547== ==1547== Invalid write of size 4 ==1547==at 0x80489E3: void std::__valarray_copyint(std::_Arrayint, unsigned int, std::_Arrayint, std::_Arraybool) (in /home/bruel/tmp/a.out) ==1547==by 0x804889A: std::mask_arrayint::operator=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1547==by 0x80485C9: main (in /home/bruel/tmp/a.out) ==1547== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd ==1547== ==1547== ==1547== HEAP SUMMARY: ==1547== in use at exit: 0 bytes in 0 blocks ==1547== total heap usage: 3 allocs, 3 frees, 9 bytes allocated ==1547== ==1547== All heap blocks were freed -- no leaks are possible ==1547== ==1547== For counts of detected and suppressed errors, rerun with: -v ==1547== ERROR SUMMARY: 56 errors from 2 contexts (suppressed: 19 from 10) -- Summary: memory errors using valarrays Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: christian dot bruel at st dot com GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #1 from christian dot bruel at st dot com 2009-11-26 11:32 --- Created an attachment (id=19153) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19153action=view) reduced case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #2 from christian dot bruel at st dot com 2009-11-26 11:35 --- Created an attachment (id=19154) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19154action=view) computed assignment test case compiled with g++ -O0 gnx2439$ valgrind ./a.out==1599== Memcheck, a memory error detector ==1599== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==1599== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==1599== Command: ./a.out ==1599== ==1599== Invalid read of size 1 ==1599==at 0x8048A0B: void std::_Array_augmented___plusint(std::_Arrayint, std::_Arraybool, std::_Arrayint, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_arrayint::operator+=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129061 is 0 bytes after a block of size 1 alloc'd ==1599==at 0x40061CC: operator new(unsigned int) (vg_replace_malloc.c:214) ==1599==by 0x804867E: std::__valarray_get_memory(unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x8048920: bool* restrict std::__valarray_get_storagebool(unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x8048728: std::valarraybool::valarray(bool const, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x804857B: main (in /home/bruel/tmp/a.out) ==1599== ==1599== Invalid read of size 4 ==1599==at 0x8048A18: void std::_Array_augmented___plusint(std::_Arrayint, std::_Arraybool, std::_Arrayint, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_arrayint::operator+=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd ==1599== ==1599== Invalid write of size 4 ==1599==at 0x8048A24: void std::_Array_augmented___plusint(std::_Arrayint, std::_Arraybool, std::_Arrayint, unsigned int) (in /home/bruel/tmp/a.out) ==1599==by 0x80488D4: std::mask_arrayint::operator+=(std::valarrayint const) const (in /home/bruel/tmp/a.out) ==1599==by 0x80485E9: main (in /home/bruel/tmp/a.out) ==1599== Address 0x4129108 is not stack'd, malloc'd or (recently) free'd -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #3 from paolo dot carlini at oracle dot com 2009-11-26 11:35 --- Hey, this is pointless, the issue is well known and Gaby is the reference person in this area. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #4 from christian dot bruel at st dot com 2009-11-26 11:38 --- Created an attachment (id=19155) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19155action=view) controversal testcase compile with -O0, Segfaults on x86 with gcc version 4.5.0 20091119 (experimental) [trunk revision 154332] (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #5 from christian dot bruel at st dot com 2009-11-26 11:40 --- Created an attachment (id=19156) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19156action=view) Proposed patch 2009-11-23 Christian Bruel christian.br...@st.com * include/bits/mask_array.h (mask_array_Tp::operator=): Use _M_sz. (mask_array_Tp::operator _Op##): Likewise. * testsuite/26_numerics/valarray/mask_array.cc: New test. This patch makes the valarray_copy interates on the number of true elements rather than on the array size. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #6 from christian dot bruel at st dot com 2009-11-26 12:08 --- (In reply to comment #3) Hey, this is pointless, the issue is well known and Gaby is the reference person in this area. no problem, if the issue is known it can be recorded for the reference, a link to Gaby authoritative answer http://gcc.gnu.org/ml/libstdc++/2009-11/msg00099.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #7 from paolo dot carlini at oracle dot com 2009-11-26 12:15 --- What I meant, exactly, is that if any issue is well known to the concerned people, there is no need for a Bugzilla, in particular an invalid one ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #8 from christian dot bruel at st dot com 2009-11-26 12:18 --- (In reply to comment #7) What I meant, exactly, is that if any issue is well known to the concerned people, there is no need for a Bugzilla, in particular an invalid one ;) Well I still need to be convinced that va0.cxx here is invalid : it is a 5 lines of simple conforming code that produces a segfault. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-26 12:57 --- The point is that the code is not conforming. In any case, conforming or not, in the future please do not open Bugzilla for issues already known to the maintainers, thanks in advance. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-11-26 13:02 --- This is what I would call a very fundamental bug, at the soul of what fortran is suppose to do. I am looking at it but think it would go better with a team effort here. Anyone have any thoughts about it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2009-11-26 14:35 --- I think we need to gfc_walk_op_expr before we try to gfc_conv_array_transpose -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug tree-optimization/41905] [4.5 Regression] ICE with __attribute__((noreturn))
--- Comment #3 from matz at gcc dot gnu dot org 2009-11-26 14:50 --- I have a patch. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-06 09:32:52 |2009-11-26 14:50:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41905
[Bug c++/42183] New: internal compiler error: verify_stmts failed
Compiling of qt-x11-opensource-src-4.5.3/src/3rdparty/webkit/WebCore/rendering/RenderMenuList.cpp failed with the following compiler call g++ -c -fpreprocessed -m32 -O2 RenderMenuList.1.i RenderMenuList.1.i: In member function 'WebCore::RenderMenuList::controlClipRect(int, int) const': RenderMenuList.1.i:45546:9: error: address taken, but ADDRESSABLE bit not set retval RenderMenuList.1.i:1514:19: note: in statement # .MEM_119 = VDEF .MEM_117 WebCore::IntRect::intersect (retval, innerBox); RenderMenuList.1.i:45546:9: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- Summary: internal compiler error: verify_stmts failed Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mario-baumann at web dot de GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug c++/42183] internal compiler error: verify_stmts failed
--- Comment #1 from mario-baumann at web dot de 2009-11-26 15:07 --- Created an attachment (id=19157) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19157action=view) preprocessed cpp file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug c++/42183] internal compiler error: verify_stmts failed
--- Comment #2 from mario-baumann at web dot de 2009-11-26 15:08 --- uname -a Linux yoda.intec.dom 2.6.18-164.el5 #1 SMP Thu Sep 3 03:28:30 EDT 2009 x86_64 x86_64 x86_64 GNU/Linux rpm -qa glibc* | grep -e 'glibc-[0-9]' | sort -u glibc-2.5-42 g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/opt/gcc/4.5.0-20091126-svn154671/x86_64/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ./configure --with-cloog=/opt/gcc/svn/aux --with-gmp=/opt/gcc/svn/aux --with-mpc=/opt/gcc/svn/aux --with-mpfr=/opt/gcc/svn/aux --with-ppl=/opt/gcc/svn/aux --disable-nls --enable-languages=c,c++,fortran --prefix=/opt/gcc/4.5.0-20091126-svn154671/x86_64 Thread model: posix gcc version 4.5.0 20091126 (experimental) (GCC) ld -v GNU ld (GNU Binutils) 2.20.51.20091126 g++ -c -fpreprocessed -m32 -O2 RenderMenuList.1.i RenderMenuList.1.i: In member function 'WebCore::RenderMenuList::controlClipRect(int, int) const': RenderMenuList.1.i:45546:9: error: address taken, but ADDRESSABLE bit not set retval RenderMenuList.1.i:1514:19: note: in statement # .MEM_119 = VDEF .MEM_117 WebCore::IntRect::intersect (retval, innerBox); RenderMenuList.1.i:45546:9: internal compiler error: verify_stmts failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. NOTES: (1) g++ -c -fpreprocessed -m32 RenderMenuList.1.i works -- mario-baumann at web dot de changed: What|Removed |Added CC||mario-baumann at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug tree-optimization/42027] [4.5 Regression] Performance regression in convolution loop optimization
--- Comment #3 from nbenoit at tuxfamily dot org 2009-11-26 15:08 --- Using integer instead of double, the performance difference is even more noticeable : * with -O1 GCC 4.4.2 7475 ms GCC-trunk-r154672 9390 ms -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42027
[Bug tree-optimization/39806] incorrect pointer hashing in ipa-struct-reorg.c
--- Comment #3 from olga at il dot ibm dot com 2009-11-26 15:35 --- Potential patch (as Andew suggested). Please check for your platform. http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01467.html Thanks, Olga -- olga at il dot ibm dot com changed: What|Removed |Added CC||bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39806
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #4 from vincent at vinc17 dot org 2009-11-26 15:53 --- (In reply to comment #1) Aliasing rules are indeed broken because you access a union of anonymous type through a pointer to a union of type ieee_double_extract. OK, the real code in MPFR is a double accessed through a pointer to a union of type ieee_double_extract, but I suppose this is the same problem. BTW, could my testcase be used to improve GCC's -Wstrict-aliasing=3 (i.e. to have fewer false negatives without introducing more false positives), or is it too difficult / not possible? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
[Bug tree-optimization/41905] [4.5 Regression] ICE with __attribute__((noreturn))
--- Comment #4 from matz at gcc dot gnu dot org 2009-11-26 15:58 --- Fixed in r154674. -- matz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41905
[Bug c++/10690] [DR 115] Even when used within typeid(), a template-id generating an overload set with only one function should silently decay to a pointer to function
--- Comment #8 from jason at gcc dot gnu dot org 2009-11-26 16:00 --- Subject: Bug 10690 Author: jason Date: Thu Nov 26 15:59:52 2009 New Revision: 154675 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154675 Log: PR c++/10690 * rtti.c (get_tinfo_decl_dynamic): Call resolve_nondeduced_context. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/rtti.c trunk/gcc/testsuite/g++.dg/template/explicit-args2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10690
[Bug c++/10690] [DR 115] Even when used within typeid(), a template-id generating an overload set with only one function should silently decay to a pointer to function
--- Comment #9 from jason at gcc dot gnu dot org 2009-11-26 16:04 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10690
[Bug c/42184] New: Same literal behaves differently as a double than as a long double
One would assume that the following program prints the same number four times,
but instead 1 0 1 0 is printed. I compiled it with options -std=c99 -lm.
#include stdio.h
#include math.h
#include stdlib.h
int main(void)
{
long double value1 = 1.6646342e21;
long double value2 = 1.6646342e21L;
long double value3 = strtod(1.6646342e21, NULL);
long double value4 = strtold(1.6646342e21, NULL);
long double divisor = 1.25L;
printf(%Lg %Lg %Lg %Lg\n,
fmodl(value1, divisor), fmodl(value2, divisor),
fmodl(value3, divisor), fmodl(value4, divisor));
return 1;
}
--
Summary: Same literal behaves differently as a double than as a
long double
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: warp at iki dot fi
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42184
[Bug c/42179] Incorrect optimization (-O2) yields wrong code (regression)
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-26 16:39 --- The frontend code should indeed be able to unconditionally warn for ((union ieee_double_extract *)(x.d))-s.exp because it can see both the underlying object and the access through the non-conflicting type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42179
[Bug c++/42183] internal compiler error: verify_stmts failed
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-26 16:41 --- reducing. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42183
[Bug c++/41906] [4.5 Regression] ICE with catch(...) and -fpermissive
--- Comment #2 from matz at gcc dot gnu dot org 2009-11-26 16:51 --- I have a patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01474.html -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-11-05 15:58:18 |2009-11-26 16:51:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41906
[Bug middle-end/42185] New: [4.5 Regression] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820
gfortran -c -fgraphite -O1 -ffast-math bug.f90 bug.f90: In function __powell_MOD_trsapp: bug.f90:4:0: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cat bug.f90 MODULE powell INTEGER, PARAMETER :: dp=8 CONTAINS SUBROUTINE trsapp (n,npt,xopt,xpt,gq,hq,pq,delta,step,d,g,hd,hs,crvmin) REAL(dp), DIMENSION(*), INTENT(INOUT):: step, d, g, hd, hs LOGICAL :: jump1, jump2 REAL(dp) :: alpha, angle, angtest, bstep, cf, cth, dd, delsq, dg, dhd, reduc, sg, sgk, shs, ss, sth, temp, tempa, tempb DO i=1,n dd=dd+d(i)**2 END DO mainloop : DO IF ( .NOT. jump2 ) THEN IF ( .NOT. jump1 ) THEN bstep=temp/(ds+SQRT(ds*ds+dd*temp)) IF (alpha bstep) THEN IF (ss delsq) CYCLE mainloop END IF IF (gg = 1.0e-4_dp*ggbeg) EXIT mainloop END IF END IF END DO mainloop END SUBROUTINE trsapp END MODULE powell details gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/data03/vondele/gcc_trunk/build/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: /data03/vondele/gcc_trunk/gcc/configure --disable-bootstrap --prefix=/data03/vondele/gcc_trunk/build --enable-languages=c,c++,fortran --disable-multilib --with-ppl=/data03/vondele/gcc_trunk/build/ --with-cloog=/data03/vondele/gcc_trunk/build/ --with-libelf=/data03/vondele/libelf-0.8.12/build/ --enable-gold --enable-lto --enable-plugins Thread model: posix gcc version 4.5.0 20091126 (experimental) [trunk revision 154675] (GCC) -- Summary: [4.5 Regression] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42185
[Bug middle-end/42181] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-26 17:02 --- *** Bug 41051 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/41051] -O1/-O2/-O3 -fgraphite-identity -floop-interchange miscompiles air.f90
--- Comment #2 from jv244 at cam dot ac dot uk 2009-11-26 17:02 --- *** This bug has been marked as a duplicate of 42181 *** -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41051
[Bug middle-end/42181] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #2 from jv244 at cam dot ac dot uk 2009-11-26 17:04 --- the following is a testcase for the ICE (derived from CP2K bug crashes in the same place): cat bug.f90 MODULE powell INTEGER, PARAMETER :: dp=8 CONTAINS SUBROUTINE newuob (n,npt,x,rhobeg,rhoend,maxfun,xbase, xopt,xnew,xpt,fval,gq,hq,pq,bmat,zmat,ndim,d,vlag,w,opt) REAL(dp), DIMENSION(npt, *), INTENT(inout) :: xpt REAL(dp), DIMENSION(*), INTENT(inout):: fval, gq, hq, pq 120 IF (dsq = 1.0e-3_dp*xoptsq) THEN DO k=1,npt DO i=1,n gq(i)=gq(i)+temp*xpt(k,i) END DO END DO END IF END SUBROUTINE newuob END MODULE powell gfortran -fgraphite -O1 bug.f90 bug.f90: In function __powell_MOD_newuob: bug.f90:4:0: internal compiler error: in scan_tree_for_params, at graphite-sese-to-poly.c:853 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug middle-end/42181] [4.5 Regression] -fgraphite-identity miscompiles or ICEs on air.f90
--- Comment #3 from jv244 at cam dot ac dot uk 2009-11-26 17:05 --- the ice is absent in 4.4 but present in 4.5 trunk -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-26 17:05:43 date|| Summary|-fgraphite-identity |[4.5 Regression] -fgraphite- |miscompiles or ICEs on |identity miscompiles or ICEs |air.f90 |on air.f90 Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42181
[Bug c++/42026] [DR 239] g++ violate [basic.lookup.argdep]
-- 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|2009-11-13 10:24:51 |2009-11-26 17:11:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug target/41077] [avr] excessive prologue/epilogue for interrupt handler
--- Comment #1 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:12 --- R1 and R0 are used at assembler level outside of compiler scope. R1 is always expected to contain as a zero value - to avoid using a register to load this common value. R1 maybe used in assembler for other purposes - but must be restored to zero. R0 is used as a temporary - to get around awkward situation created by compiler like a = *a; Thus any ISR will always save these values - and clear r1. Gcc cannot see either r1 or r0 or otherwise track usage. While we may debate the merits of this approach. It has been this way from day one and will not change. :-( -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41077
[Bug c/42184] Same literal behaves differently as a double than as a long double
--- Comment #1 from kargl at gcc dot gnu dot org 2009-11-26 17:13 --- I think that you may be looking at a library issue and the conversion of a decimal string to binary. Add printf(%La\n%La\n%La\n%La\n, value1, value2, value3, value4); to your program yields REMOVE:kargl[209] ./z 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa36p+70 1 1 1 0 on FreeBSD. If I replace 1.6646342e21 everywhere in your program with 0x1.68f5c2c528fa3p+70, I get the result you expect, ie., REMOVE:kargl[212] ./z 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 0x1.68f5c2c528fa3p+70 1 1 1 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42184
[Bug target/21080] Excecution test failure for avr for pr17377 test case.
--- Comment #6 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:20 --- Fixed on 4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21078 -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21080
[Bug target/37081] [avr] FAIL: gcc.dg/pr36998.c
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:25 --- Author: hutchinsonandy Date: Mon Nov 23 21:38:32 2009 New Revision: 154467 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154467 Log: * gcc.dg/pr36998.c: Frame pointer required for avr target. * gcc.dg/debug/pr41264-1.c: Use long if int size 16bit or smaller. * gcc.dg/pr39226.c: Use smaller bitfield if int size is 16bit. * gcc.dg/pr41340.c: Test requires long pointer target. * gcc.dg/profile-generate-3.c: Test requires profiling support. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/debug/pr41264-1.c trunk/gcc/testsuite/gcc.dg/pr36998.c trunk/gcc/testsuite/gcc.dg/pr39226.c trunk/gcc/testsuite/gcc.dg/pr41340.c trunk/gcc/testsuite/gcc.dg/profile-generate-3.c -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37081
[Bug testsuite/38202] [avr] FAIL: gcc.dg/torture/pr37868.c
--- Comment #3 from hutchinsonandy at gcc dot gnu dot org 2009-11-26 17:29 --- Fixed 4.5 Author: hutchinsonandy Date: Mon Nov 23 22:21:21 2009 New Revision: 154474 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154474 Log: * gcc.dg/torture/pr37868.c: Use smaller bitfield for 16bit int targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/torture/pr37868.c -- hutchinsonandy at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38202
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #10 from christian dot bruel at st dot com 2009-11-26 17:44 --- Paolo, I entered this defect for user reference, since the problem that originates the thread occurs in many public places such as testsuites (perenial Sec26/P26774) or class books (http://www.linux-kheops.com/doc/casteyde/cours_cpp-1.40.1/htm/x5866.htm#AEN6045) 14-21. Digging on the net, it's not difficult to find other instances of the same problem, All fail for the same reason: out of bound access from the mask array or exibit a valgrind error. FYU they pass with the proposed patch, I'm glad that it was not a bug with the library, and to have opened the discussion. just wanted to avoid future duplicate reports on the same problem an extra analysis. I didn't want to add extra burden to the maintainers of course, sorry if it was the case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-11-26 17:50 --- Removing the assert appears to fix this. Testing now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug libstdc++/42182] memory errors using valarrays
--- Comment #11 from paolo dot carlini at oracle dot com 2009-11-26 18:00 --- Yes, but remember our policy in the future, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42182
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #12 from janus at gcc dot gnu dot org 2009-11-26 19:01 --- Subject: Bug 42048 Author: janus Date: Thu Nov 26 19:01:02 2009 New Revision: 154679 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154679 Log: 2009-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/42048 PR fortran/42167 * gfortran.h (gfc_is_function_return_value): New prototype. * match.c (gfc_match_call): Use new function 'gfc_is_function_return_value'. * primary.c (gfc_is_function_return_value): New function to check if a symbol is the return value of an encompassing function. (match_actual_arg,gfc_match_rvalue,match_variable): Use new function 'gfc_is_function_return_value'. * resolve.c (resolve_common_blocks,resolve_actual_arglist): Ditto. 2009-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/42048 PR fortran/42167 * gfortran.dg/select_type_10.f03: New test case. * gfortran.dg/typebound_call_11.f03: Extended test case. Added: trunk/gcc/testsuite/gfortran.dg/select_type_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/typebound_call_11.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug fortran/42167] [OOP] SELECT TYPE with function return value
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-26 19:01 --- Subject: Bug 42167 Author: janus Date: Thu Nov 26 19:01:02 2009 New Revision: 154679 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154679 Log: 2009-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/42048 PR fortran/42167 * gfortran.h (gfc_is_function_return_value): New prototype. * match.c (gfc_match_call): Use new function 'gfc_is_function_return_value'. * primary.c (gfc_is_function_return_value): New function to check if a symbol is the return value of an encompassing function. (match_actual_arg,gfc_match_rvalue,match_variable): Use new function 'gfc_is_function_return_value'. * resolve.c (resolve_common_blocks,resolve_actual_arglist): Ditto. 2009-11-26 Janus Weil ja...@gcc.gnu.org PR fortran/42048 PR fortran/42167 * gfortran.dg/select_type_10.f03: New test case. * gfortran.dg/typebound_call_11.f03: Extended test case. Added: trunk/gcc/testsuite/gfortran.dg/select_type_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/match.c trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/typebound_call_11.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42167
[Bug fortran/42167] [OOP] SELECT TYPE with function return value
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-26 19:05 --- Fixed with r154679. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42167
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-11-26 19:05 --- Subject: Bug 41278 Author: jvdelisle Date: Thu Nov 26 19:05:37 2009 New Revision: 154680 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154680 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41278 * trans-array.c (gfc_conv_array_transpose): Delete unnecessary assert. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-array.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug debug/42186] New: [4.5 Regression] internal compiler error: verify_ssa failed
gfortran -c -fgraphite-identity -g -O3 -ffast-math bug.f90 bug.f90: In function calerf: bug.f90:3:0: error: definition in block 11 does not dominate use in block 4 for SSA_NAME: xden_2 in statement: D.1562_21 = D.1561_20 + xden_2; bug.f90:3:0: internal compiler error: verify_ssa failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. cat bug.f90 MODULE erf_fn CONTAINS SUBROUTINE CALERF(ARG,RESULT,JINT) DIMENSION A(5),B(4),C(9),D(8),P(6),Q(5) IF (Y = THRESH) THEN DO I = 1, 3 XNUM = (XNUM + A(I)) * YSQ XDEN = (XDEN + B(I)) * YSQ END DO RESULT = X * (XNUM + A(4)) / (XDEN + B(4)) END IF END SUBROUTINE CALERF END MODULE erf_fn -- Summary: [4.5 Regression] internal compiler error: verify_ssa failed Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42186
[Bug debug/42186] [4.5 Regression] internal compiler error: verify_ssa failed
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42186
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2009-11-26 19:10 --- Subject: Bug 41278 Author: jvdelisle Date: Thu Nov 26 19:10:29 2009 New Revision: 154681 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154681 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41278 * gfortran.dg/array_function_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/array_function_5.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug middle-end/42185] [4.5 Regression] expected gimple_assign(error_mark), have gimple_call() in gimple_assign_rhs_code, at gimple.h:1820
--- Comment #1 from jv244 at cam dot ac dot uk 2009-11-26 19:11 --- pretty similar in this case gfortran -c -fgraphite-identity -g -O3 -ffast-math bug.f90 bug.f90 bug.f90: In function psi: bug.f90:4:0: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs_code, at gimple.h:1820 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. bug.f90: In function psi: bug.f90:4:0: internal compiler error: gimple check: expected gimple_assign(error_mark), have gimple_nop() in gimple_assign_rhs_code, at gimple.h:1820 Please submit a full bug report, with preprocessed source if appropriate. cat bug.f90 MODULE beta_gamma_psi INTEGER, PARAMETER :: dp=KIND(0.0D0) CONTAINS FUNCTION psi(xx) RESULT(fn_val) REAL(dp) :: aug, den, dx0 = 1.461632144968362341262659542325721325e0_dp, p1(7) = (/ .895385022981970e-02_dp, .477762828042627e+01_dp, .142441585084029e+03_dp, .118645200713425e+04_dp, .363351846806499e+04_dp,.413810161269013e+04_dp, -.648157123766197e+00_dp /), piov4 = .785398163397448e0_dp, q1(6) = (/ .448452573429826e+02_dp, .520752771467162e+03_dp, .221000799247830e+04_dp, .364127349079381e+04_dp, .546117738103215e+02_dp, .88548522962e+01_dp /) DO i = 1, 5 den = (den + q1(i)) * x upper = (upper + p1(i+1)) * x END DO aug = upper / (den + q2(4)) - 0.5e0_dp / x + aug 350 fn_val = aug + LOG(x) END FUNCTION psi END MODULE beta_gamma_psi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42185
[Bug objc++/42156] [4.5 Regression] Hundreds of objc++ testsuite regressions
--- Comment #7 from howarth at nitro dot med dot uc dot edu 2009-11-26 19:29 --- This patch on x86_64-apple-darwin10 returns the obj-c++ testsuite results back to their previous results of... === obj-c++ Summary === # of expected passes398 # of unexpected failures52 # of unexpected successes 3 # of expected failures 15 # of unresolved testcases 1 # of unsupported tests 1 so it seems to be working fine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42156
[Bug c++/42187] New: ice when inlined_to pointer set for noninline callers
I just tried to compile package boswars-2.5 with the GNU C++ compiler version 4.5 snapshot 20091119 and the compiler said engine/guichan/widgets/textbox.cpp:595:1: error: inlined_to pointer set for noninline callers engine/guichan/widgets/textbox.cpp:595:1: error: multiple inline callers std::basic_string_CharT, _Traits, _Alloc::size_type std::basic_string_CharT, _Traits, _Alloc::_M_check(std::basic_string_CharT, _Traits, _Alloc::size_type, const char*) const [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar, std::basic_string_CharT, _Traits, _Alloc::size_type = long unsigned int]/423(-1) @0x7ff593464aa0 (inline copy in virtual bool gcn::TextBox::keyPress(const gcn::Key)/340) availability:available 5 time, 15 benefit 7 size, 6 benefit reachable body finalized inlinable called by: std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::insert(std::basic_string_CharT, _Traits, _Alloc::size_type, const std::basic_string_CharT, _Traits, _Alloc, std::basic_string_CharT, _Traits, _Alloc::size_type, std::basic_string_CharT, _Traits, _Alloc::size_type) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar, std::basic_string_CharT, _Traits, _Alloc::size_type = long unsigned int]/449 (1.00 per call) (can throw external) std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::insert(std::basic_string_CharT, _Traits, _Alloc::size_type, const std::basic_string_CharT, _Traits, _Alloc, std::basic_string_CharT, _Traits, _Alloc::size_type, std::basic_string_CharT, _Traits, _Alloc::size_type) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar, std::basic_string_CharT, _Traits, _Alloc::size_type = long unsigned int]/435 (0.00 per call) (inlined) (can throw external) calls: void std::__throw_out_of_range(const char*)/642 (can throw external) engine/guichan/widgets/textbox.cpp:595:1: internal compiler error: verify_cgraph_node failed Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required. -- Summary: ice when inlined_to pointer set for noninline callers Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: x86_64-suse-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42187
[Bug c++/42187] ice when inlined_to pointer set for noninline callers
--- Comment #1 from dcb314 at hotmail dot com 2009-11-26 20:05 --- Created an attachment (id=19158) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19158action=view) C++ source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42187
[Bug c++/35112] [4.3/4.4/4.5 regression] ICE and broken diagnostic with ambiguous class name
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35112
[Bug c++/42026] [DR 239] g++ violate [basic.lookup.argdep]
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-26 20:58 --- Subject: Bug 42026 Author: jason Date: Thu Nov 26 20:58:47 2009 New Revision: 154686 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154686 Log: PR c++/42026, DR 239 * parser.c (cp_parser_postfix_expression): A local extern also prevents arg-dependent lookup. Added: trunk/gcc/testsuite/g++.dg/lookup/koenig8.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug fortran/42188] New: F03:C612. The leftmost part-name shall be the name of a data object.
Follow-up to PR42048. Consider the following code: module grid_module implicit none type grid contains procedure :: new_grid procedure :: new_int end type contains subroutine new_grid(this) class(grid) :: this end subroutine integer function new_int(this) class(grid) :: this new_int = 42 end function end module module field_module use grid_module implicit none type field type(grid) :: mesh end type contains type(field) function new_field() end function subroutine test integer :: i type(grid) :: g g = new_field()%mesh call new_field()%mesh%new_grid() i = new_field()%mesh%new_int() end subroutine end module which is currently rejected with test.f90:41.3: g = new_field()%mesh 1 Error: Unclassifiable statement at (1) test.f90:42.19: call new_field()%mesh%new_grid() 1 Error: Syntax error in CALL statement at (1) test.f90:43.3: i = new_field()%mesh%new_int() 1 Error: Unclassifiable statement at (1) Rejecting it is fine, I think, but the error messages should be improved. ifort says error #6837: The leftmost part-ref in a data-ref can not be a function reference. The relevant parts from the standard are: R612 data-ref is part-ref [ % part-ref ] ... R613 part-ref is part-name [ ( section-subscript-list ) ] C612 (R612) The leftmost part-name shall be the name of a data object. 2.4.3.1 Data object A data object (often abbreviated to object) is a constant (4.1.2), a variable (6), or a subobject of a constant. -- Summary: F03:C612. The leftmost part-name shall be the name of a data object. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42188
[Bug fortran/42048] [F03] Erroneous syntax error message on TBP call
--- Comment #13 from janus at gcc dot gnu dot org 2009-11-26 21:05 --- Comment #4 is fixed with r154679. For the issues in comment #6 to #10 I have opened PR42188, so this one can be closed. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42048
[Bug c++/42026] [DR 239] g++ violate [basic.lookup.argdep]
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-26 21:11 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42026
[Bug c/42184] Same literal behaves differently as a double than as a long double
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-11-26 21:11 --- Well FreeBSD has slightly different default x87 precision setting . -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42184
[Bug c/42184] Same literal behaves differently as a double than as a long double
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-26 21:15 --- 1.6646342e21 will produce a double and then that is extended into long double. On the other hand 1.6646342e21L is a long double so it is parsed what you expect into a long double. 1 0 1 0 is the correct value for x87 (80bit long double). -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42184
[Bug rtl-optimization/38582] excessive time in rename registers
--- Comment #5 from bernds at gcc dot gnu dot org 2009-11-26 21:35 --- Subject: Bug 38582 Author: bernds Date: Thu Nov 26 21:35:35 2009 New Revision: 154687 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154687 Log: PR rtl-opt/38582 * regrename.c (struct du_chain): Remove member earlyclobber. (scan_rtx_reg): Don't set it. Remove argument earlyclobber, all callers changed. (scan_rtx): Remove argument earlyclobber, all callers changed. (hide_operands, restore_operands, record_out_operands): New functions, broken out of build_def_use. (build_def_use): Call them as necessary. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38582
[Bug rtl-optimization/38582] excessive time in rename registers
--- Comment #6 from bernds at gcc dot gnu dot org 2009-11-26 21:41 --- Subject: Bug 38582 Author: bernds Date: Thu Nov 26 21:41:42 2009 New Revision: 154688 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154688 Log: PR rtl-opt/38582 * regrename.c (struct du_head): New members id, conflicts, hard_conflicts and cannot_rename. (enum scan_actions): Remove terminate_all_read and terminate_overlapping_read; add mark_all_read. (scan_actions_name): Likewise. (du_head_p): New typedef. Define a vector type for it. (id_to_chain): New static variable. (note_sets, clear_dead_regs): Delete functions. (free_chain_data): New function. (merge_overlapping_regs): Simply walk the conflicts bitmap. Remove argument B, all callers changed. (regrename_optimize): Allocate id_to_chain. Ignore chains that have the cannot_rename bit set. Update regno and nregs of a renamed chain. Call free_chain_data when done. (do_replace): Remove death notes when the renamed reg is set in the last insn; add them if not. (mark_conflict, note_sets_clobbers): New static function. (fail_current_block, current_id, open_chains_set, live_hard_regs): New static variables. (scan_rtx_reg): Keep track of conflicts between chains, and between chains and hard regs. Don't terminate chains when we find a read we can't handle, mark it unrenameable instead. For terminate_write, terminate chains that are written with an exact match or a superset of registers. Set fail_current_block if multi-word lifetimes are too complex to handle. (scan_rtx_address): Use mark_all_read instead of terminate_all_read. (build_def_use): Initialize current_id, live_chains and live_hard_regs; free memory for them when done. Rearrange the steps so that earlyclobbers are noted before reads are processed. Add new steps to keep track of hard register lifetimes outside insn operands. Modified: trunk/gcc/ChangeLog trunk/gcc/regrename.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38582
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #9 from burnus at gcc dot gnu dot org 2009-11-26 21:46 --- The following assert is wrong: gcc_assert (src_info-dimen == 2); (and has been removed in the comment patch of comment 7). I only want to link to an email which gives the reason why. http://gcc.gnu.org/ml/fortran/2009-11/msg00212.html -- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #27 from jvdelisle at gcc dot gnu dot org 2009-11-26 21:53 --- Subject: Bug 41807 Author: jvdelisle Date: Thu Nov 26 21:52:52 2009 New Revision: 154690 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154690 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41807 * trans-const.c (gfc_conv_const): Set se-expr to a constant on error. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/42131] Weird translation of DO loops
--- Comment #13 from tkoenig at gcc dot gnu dot org 2009-11-26 21:56
---
Created an attachment (id=19159)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19159action=view)
patch that implements the multiplication idea
This generates
if (D.1339 0)
{
if (D.1338 D.1337)
{
goto L.2;
}
else
{
step_sign.2 = 1;
}
}
else
{
if (D.1338 D.1337)
{
goto L.2;
}
else
{
step_sign.2 = -1;
}
}
countm1.1 = (((character(kind=4)) D.1338 - (character(kind=4)) D.1337) *
(character(kind=4)) step_sign.2) / (character(kind=4)) (step_sign.2 * D.1339);
implementing the multiplication idea outlined above, and passes at
least do_3.F90.
Better?
--
tkoenig at gcc dot gnu dot org changed:
What|Removed |Added
Attachment #19104|0 |1
is obsolete||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2009-11-26 21:57 --- Subject: Bug 41807 Author: jvdelisle Date: Thu Nov 26 21:57:32 2009 New Revision: 154691 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154691 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41807 Backport from mainline. * trans-const.c (gfc_conv_const): Fix typo in comment. Replace assert with error message if not constant. Set se-expr to a constant on error. * resolve.c (next_data_value): Delete check for constant. Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/resolve.c branches/gcc-4_4-branch/gcc/fortran/trans-const.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/42189] New: gfc_is_constant_expr has unacceptable side effects
Follow up to PR 41807 - based on the comment at http://gcc.gnu.org/ml/fortran/2009-11/msg00181.html cf. also http://gcc.gnu.org/ml/fortran/2009-11/msg00208.html it is both unacceptable and unanticipated that gfc_is_constant_expr have side effects like that. Should we, perhaps copy the expression within gfc_is_constant_expr, test that and free the new expression before exiting? and in http://gcc.gnu.org/ml/fortran/2009-11/msg00185.html I think we have some other bugs lurking here. For example, why could we simplify the original expr in get_array_index and not it's copy. gfc_copy_expr is missing something. The gfc_is_constant_expr issue is down in gfc_constant_ac. I think we may be trying to expand the constructors in more than one place, in gfc_constant_ac and somewhere else. -- Summary: gfc_is_constant_expr has unacceptable side effects Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42189
[Bug fortran/42131] Weird translation of DO loops
--- Comment #14 from kargl at gcc dot gnu dot org 2009-11-26 22:07 --- (In reply to comment #13) } countm1.1 = (((character(kind=4)) D.1338 - (character(kind=4)) D.1337) * (character(kind=4)) step_sign.2) / (character(kind=4)) (step_sign.2 * D.1339); implementing the multiplication idea outlined above, and passes at least do_3.F90. Better? Looks much better than the current situation. Is there a valid reason for the character(kind=4) casts? I would have thought that this should be a integer(kind=4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug ada/42190] New: instantiation incorrectly considered allocation for restrictions check
The following program pragma Restrictions (No_Local_Allocators); procedure Restrict_Bug is generic package Generic_Pkg is I : Integer; end Generic_Pkg; package Instance is new Generic_Pkg; begin null; end Restrict_Bug; creates the error message: gnatmake -v restrict_bug GNATMAKE 4.4.2 Copyright (C) 1995-2008, Free Software Foundation, Inc. restrict_bug.ali being checked ... - restrict_bug.ali missing. gcc -c restrict_bug.adb restrict_bug.adb:10:04: violation of restriction No_Local_Allocators at line 1 End of compilation gnatmake: restrict_bug.adb compilation error -- Summary: instantiation incorrectly considered allocation for restrictions check Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rolf dot ebert dot gcc at gmx dot de GCC host triplet: MinGW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42190
[Bug fortran/41278] internal compiler error related to matmul and transpose
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:11 --- Just a note of appreciation to Chris for reporting this bug and providing a simple and extremely useful test case. When I get a moment, I will add Chris to the test case as recognition. Shall we backport this fix to 4.4? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41278
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:18 --- Subject: Bug 41807 Author: jvdelisle Date: Thu Nov 26 22:18:36 2009 New Revision: 154692 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154692 Log: 2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/41807 * gfortran.dg/data_value_1.f90: Update test. * gfortran.dg/array_constructor_32.f90: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/array_constructor_32.f90 Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/data_value_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug fortran/41807] [4.5/4.4 Regression] data statement with nested type constructors
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:21 --- Fixed on trunk and 4.4. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #85 from howarth at nitro dot med dot uc dot edu 2009-11-26
22:35 ---
Created an attachment (id=19160)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19160action=view)
combined patch that fixes dsymutil asserts
Combined patches...
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01329.html
http://gcc.gnu.org/ml/gcc-patches/2009-11/msg01452.html
with hand merge of section...
@@ -15719,17 +15705,19 @@ add_location_or_const_value_attribute (d
a constant value. That way we are better to use
add_const_value_attribute
rather than expanding constant value equivalent. */
loc_list = lookup_decl_loc (decl);
- if (loc_list loc_list-first loc_list-first == loc_list-last)
+ if (loc_list loc_list-first loc_list-first == loc_list-last
+ loc_list-first-var_loc_note
+ NOTE_VAR_LOCATION (loc_list-first-var_loc_note)
+ NOTE_VAR_LOCATION_LOC (loc_list-first-var_loc_note))
{
enum var_init_status status;
struct var_loc_node *node;
node = loc_list-first;
status = NOTE_VAR_LOCATION_STATUS (node-var_loc_note);
- rtl = NOTE_VAR_LOCATION (node-var_loc_note);
- if (GET_CODE (rtl) == VAR_LOCATION
- GET_CODE (XEXP (rtl, 1)) != PARALLEL)
- rtl = XEXP (XEXP (rtl, 1), 0);
+ rtl = NOTE_VAR_LOCATION_LOC (node-var_loc_note);
+ if (GET_CODE (rtl) != PARALLEL)
+ rtl = XEXP (rtl, 0);
if ((CONSTANT_P (rtl) || GET_CODE (rtl) == CONST_STRING)
add_const_value_attribute (die, rtl))
return true;
against current gcc trunk. This patch eliminates all of the asserts in dsymutil
during a bootstrap of gcc trunk.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug fortran/42131] Weird translation of DO loops
--- Comment #15 from tkoenig at gcc dot gnu dot org 2009-11-26 23:43 --- (In reply to comment #14) Looks much better than the current situation. Is there a valid reason for the character(kind=4) casts? I would have thought that this should be a integer(kind=4). The casts are generated for unsigned types, which we need because the difference between two integers can be larger than huge(integer). Beats me why this is character instead of unsigned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42131
[Bug target/41473] [4.5 Regression] dsymutil Assertion failed ...
--- Comment #86 from howarth at nitro dot med dot uc dot edu 2009-11-27
00:07 ---
Checking all of the object files in a build of gcc trunk with the combined
proposed patches from comment 85 with...
/usr/bin/dwarfdump --verbose --show-form *.o | grep -C5
'AT_location.*FORM_block[^]' | grep 0x | grep breg7
that picks of the current representation of null AT locations in the shipping
dwarfdump reveals that none of the object files now have these dwarf codes
emitted into them. So the fix appears to be complete.
Note that these null AT locations currently would appear in dwarfdump as...
0x04cf: TAG_variable [20]
0x04d0: AT_name[FORM_string] ( darwin_constructor )
0x04e3: AT_decl_file[FORM_data1] ( 0x01 (
/sw/src/fink.build/gcc45-4.4.999-20091123/gcc-4.5-20091123/libjava/darwin.cc
) )
0x04e4: AT_decl_line[FORM_data1] ( 0x50 ( 80 ) )
0x04e5: AT_type[FORM_ref4] ( cu + 0x0264 = {0x0264} (
darwin_constructor_s ) )
0x04e9: AT_location[FORM_block1] (
0x - 0x0001: breg7 +8
0x0001 - 0x0016: breg7 +16
0x0016 - 0x003b: breg7 +32
0x003b - 0x003c: breg7 +16
0x003c - 0x003d: breg7 +8 )
if present.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41473
[Bug libstdc++/42191] New: operator(istream , double ) overwrites value upon failure
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla
--enable-bootstrap --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre
--enable-libgcj-multifile --enable-java-maintainer-mode
--with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib
--with-ppl --with-cloog --with-tune=generic --with-arch_32=i586
--build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.0 20090506 (Red Hat 4.4.0-4) (GCC)
libstdc++ v4.4.0 (6.0.11).
cin y overwrites y and set failbit if there is no double on the stream:
#include iostream
#include sstream
using namespace std;
int main ()
{
stringstream s (hello);
stringstream t (hello);
int x = 1;
double y = 1.0;
// these fail, do x/y get overwritten?
s x;
t y;
cout x= x y= y endl;
}
with g++ 4.4.0 libstdc++ 6.0.11 this produces:
x=1 y=0
with g++ 4.1.2 libstdc++ 6.0.8 this produces:
x=1 y=1
--
Summary: operator(istream , double ) overwrites value upon
failure
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakethompson1 at gmail dot com
GCC build triplet: x86_64-redhat-linux
GCC host triplet: x86_64-redhat-linux
GCC target triplet: x86_64-redhat-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42191
[Bug c++/42187] ice when inlined_to pointer set for noninline callers
--- Comment #2 from hjl dot tools at gmail dot com 2009-11-27 05:52 --- It is caused by revision 154200: http://gcc.gnu.org/ml/gcc-cvs/2009-11/msg00421.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-27 05:52:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42187
[Bug other/42192] New: Regression: build with --enable-build-with-cxx failed
GCC 4.5.0 20091126 /usr/local/bin/ld: tree-mudflap.o: in function mf_xform_derefs_1(gimple_stmt_iterator*, tree_node**, unsigned int, tree_node*):../../gcc-4.5/gcc/tree-mudflap.c:573: error: undefined reference to 'set_immediate_dominator(cdi_direction, basic_block_def*, basic_block_def*)' /usr/local/bin/ld: tree-mudflap.o: in function mf_xform_derefs_1(gimple_stmt_iterator*, tree_node**, unsigned int, tree_node*):../../gcc-4.5/gcc/tree-mudflap.c:574: error: undefined reference to 'set_immediate_dominator(cdi_direction, basic_block_def*, basic_block_def*)' /usr/local/bin/ld: libbackend.a(cfghooks.o): in function _Z11split_blockP15basic_block_defPv.clone.1:../../gcc-4.5/gcc/cfghooks.c:445: error: undefined reference to 'set_immediate_dominator(cdi_direction, basic_block_def*, basic_block_def*)' /usr/local/bin/ld: libbackend.a(cfghooks.o): in function redirect_edge_and_branch_force(edge_def*, basic_block_def*):../../gcc-4.5/gcc/cfghooks.c:403: error: undefined reference to 'set_immediate_dominator(cdi_direction, basic_block_def*, basic_block_def*)' set_immediate_dominator is inlined and not compiled as a standalone function. -- Summary: Regression: build with --enable-build-with-cxx failed Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: d dot g dot gorbachev at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42192
[Bug other/42192] Regression: build with --enable-build-with-cxx failed
--- Comment #1 from d dot g dot gorbachev at gmail dot com 2009-11-27 07:17 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00730.html. -- d dot g dot gorbachev at gmail dot com changed: What|Removed |Added Keywords||build http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42192
[Bug middle-end/42193] New: [4.5 Regression] 454.calculix in SPEC CPU 2006 failed to compile at -O3
On Linux/x86-64, revision 154673 gave: gfortran -c -o umat_single_crystal.o -ISPOOLES -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64 umat_single_crystal.f umat_single_crystal.f: In function 'umat_single_crystal_': umat_single_crystal.f:19:0: internal compiler error: vector VEC(gimple,base) rep lace domain error, in vect_create_mask_and_perm at tree-vect-slp.c:1677 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Revision 154665 is OK. -- Summary: [4.5 Regression] 454.calculix in SPEC CPU 2006 failed to compile at -O3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42193
[Bug fortran/20923] gfortran slow for large array constructors
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-11-27 07:31 --- Created an attachment (id=19161) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19161action=view) Preliminary patch This patch cuts the compilation time of the original test case in half. It passes all regression tests except initialization_20.f90. I think this is an example of case that relies on a side effect to work. If we can resilve this one regression we will make substantial progress. The failing test case needs expansion/reduction. I just need to find the spot, which I suspect is in expr.c (gfc_reduce_init_expr) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20923
[Bug c/39985] Type qualifiers not actually ignored on function return type
--- Comment #3 from anders at kaseorg dot com 2009-11-27 07:33 ---
my inclination is that we should eliminate the inconsistent attempts to give
rvalues qualified types in some cases, and say that if the operand of typeof
is not an lvalue it never has a qualified type.
Should typeof ever return a qualified type? It is easy to add qualifiers to a
type if they are desired (const typeof(foo)), but seems difficult to remove
them.
For example, seemingly reasonable macros like
#define MAX(__x, __y) ({ \
typeof(__x) __ret = __x; \
if (__y __ret) __ret = __y; \
__ret; \
})
currently fail when given a qualified argument:
const int c = 42;
MAX(c, 17); /* error: assignment of read-only variable __ret */
This bug report was motivated by my attempts to fix a macro like this, by
replacing typeof(__x) with something that strips qualifiers. These all fail to
strip qualifiers:
typeof( ({ __x; }) )
typeof( ((typeof(__x)(*)(void)) 0)() )
typeof( (typeof(__x)) (__x) )
This seems to work, but only for numeric and pointer types:
typeof( (typeof(__x)) 0 )
This succeeds at stripping qualifiers for numeric types, but for some reason it
promotes char and short to int, and it fails to strip qualifiers for
non-numeric types:
typeof( 1 ? (__x) : (__x) )
Much confusion would be avoided if typeof(__x) just stripped qualifiers to
begin with.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39985
[Bug c/35503] Warning about restricted pointers?
--- Comment #2 from scovich at gmail dot com 2009-11-27 07:45 --- I've also run into this. Perhaps the machinery which tracks strict aliasing (and generates best-effort warnings) could be used here? ... adding this comment instead of filing a duplicate :P -- scovich at gmail dot com changed: What|Removed |Added CC||scovich at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35503
