[Bug c++/37540] [4.4 regression] ICE on __decltype of method call in function template
--- Comment #6 from jakub at gcc dot gnu dot org 2008-11-19 08:42 --- Jason, how could we avoid creating the type dependent CALL_EXPR_FN? It is created by build_new_method_call, but for templates both args and instance are going through build_non_dependent_expr which modifies them. -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37540
[Bug c++/38175] New: Explicit instantiation of a template hides symbols with the default visibility attribute
The complete, though minimal, sample code will be attached to the bug report.
Since the problem only occurs when using multiple compilation units, the tar
contains multiple files. Note that the code is entirely self-contained. The tar
file contains a script BuildFail.sh that reproduces the error.
System info can be found at the bottom of the description.
I've tested using GCC 4.1.3,4.2.4,4.3.2 and the snapshot 4.4 20081114.
The problem is related to using -fvisibility=hidden and explicit template
instantiation.
Consider two template classes:
template typename _T class TemplatedClass
{
public:
TemplatedClass ();
};
template typename _T class DependentTemplatedClass
{
public:
DependentTemplatedClass ();
_T m_Member;
};
Suppose both are explicitly instantiated in separate compilation units (this is
essential!):
In one compilation unit do:
template class LIBRARY_EXPORT TemplatedClass int ;
And in another:
template class LIBRARY_EXPORT DependentTemplatedClass TemplatedClass int
;
The macro LIBRARY_EXPORT, defined in Export.h, gives default visibility to the
instantiations.
Note that in the second instantiation the template argument is precisely the
class that is instantiated in the first compilation unit.
Running the following commands:
g++ -DLIBRARY_EXPORTS -fvisibility=hidden -fPIC -o LibraryInst1.cpp.o -c
LibraryInst1.cpp
g++ -DLIBRARY_EXPORTS -fvisibility=hidden -fPIC -o LibraryInst2.cpp.o -c
LibraryInst2.cpp
g++ -fPIC -fvisibility=hidden -shared -Wl,-soname,libLibrary.so -o
libLibrary.so LibraryInst1.cpp.o LibraryInst2.cpp.o
g++ -fvisibility=hidden -o Application.cpp.o -c Application.cpp
g++ -fvisibility=hidden -fPIC Application.cpp.o -o Application -rdynamic
libLibrary.so
yields:
Application.cpp.o: In function `main':
Application.cpp:(.text+0x11): undefined reference to
`TemplatedClassint::TemplatedClass()'
collect2: ld returned 1 exit status
Upon closer inspection using:
nm -C libLibrary.so | grep Templated
04f2 t TemplatedClassint::TemplatedClass()
04ec W TemplatedClassint::TemplatedClass()
050c W DependentTemplatedClassTemplatedClassint
::DependentTemplatedClass()
04f8 W DependentTemplatedClassTemplatedClassint
::DependentTemplatedClass()
it appears that the constructor of TemplatedClassint appears twice, but the
first instance is in the hidden .text section. Therefore the linker can't find
it.
I have found a workaround by defining the class using the LIBRARY_EXPORT macro:
template typename _T class LIBRARY_EXPORT TemplatedClass
{
public:
TemplatedClass ();
};
However, such a solution makes it impossible to use a single macro to export
symbols using GCC and MSVC (I won't go into the details, but MSVC does not
accept a dllimport compiler directive when using manual instantiation). So
this workaround is not suitable for me.
The problem seems to be that the instantiation of
DependentTemplatedClassTemplatedClassint induces an instantiation of
TemplatedClass int (which is contained as a member. However, this time the
default visibility is not honored.
Here is some information about my system:
version used: snapshot gcc 4.4-20081114
commands to build the snapshot:
../../gcc-4.4-20081114/configure
--prefix=/home/wijnhout/Projects/gcc/install/4.4-20081114 --disable-libgcj
--enable-languages=c,c++
make
make -j4
make install
system info:
Intel(R) Core(TM)2 Quad CPUQ6600 @ 2.40GHz
Ubuntu 8.10
$ uname -a
Linux 2-lkeb-mri-jwij 2.6.27-8-generic #1 SMP Thu Nov 6 17:33:54 UTC 2008 i686
GNU/Linux
--
Summary: Explicit instantiation of a template hides symbols with
the default visibility attribute
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: j dot s dot wijnhout at lumc dot nl
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=38175
[Bug java/38176] New: Java: 4 * use of toUpperCase/toLowerCase().equals()
I just had a look at some of the source code of the Java package in the GNU gcc version 4.4.0 snapshot 20081114 gcc-4.4-20081114/libjava/classpath/gnu/classpath/jdwp/transport/SocketTransport.java:99 Using equalsIgnoreCase() is cleaner than using toUpperCase/toLowerCase().equals(). gcc-4.4-20081114/libjava/classpath/java/awt/Font.java:276 Using equalsIgnoreCase() is cleaner than using toUpperCase/toLowerCase().equals(). gcc-4.4-20081114/libjava/classpath/java/awt/Font.java:281 Using equalsIgnoreCase() is cleaner than using toUpperCase/toLowerCase().equals(). gcc-4.4-20081114/libjava/classpath/java/awt/Font.java:286 Using equalsIgnoreCase() is cleaner than using toUpperCase/toLowerCase().equals(). I have checked the source code and I agree. Suggest use equalsIgnoreCase() in preference to toUpperCase/toLowerCase().equals() -- Summary: Java: 4 * use of toUpperCase/toLowerCase().equals() Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dcb314 at hotmail dot com GCC host triplet: suse-linux-x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38176
[Bug c++/38175] Explicit instantiation of a template hides symbols with the default visibility attribute
--- Comment #1 from j dot s dot wijnhout at lumc dot nl 2008-11-19 10:37 --- Created an attachment (id=16721) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16721action=view) Self-contained example reproducing the error. Self-contained example reproducing the error. Scripts to invoke the compiler and linker (one showing the error: BuildFail.sh and one that shows the workaround BuildWorkaround.sh). The output of nm is shown in Log.txt. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38175
[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions
--- Comment #11 from ams at gcc dot gnu dot org 2008-11-19 12:03 --- The patch just committed should fix this issue. The patch discussion is here: http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00641.html -- ams at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36133
[Bug fortran/38171] [regression] equivalence and nested modules broken
--- Comment #6 from dominiq at lps dot ens dot fr 2008-11-19 12:40 --- I don't know if the code in comment #0 is valid or not, but if the file h5global.mod does not exist compiling it with gfortran r141995 gives: pr38171.f90:2.14: USE H5GLOBAL 1 Fatal Error: Can't open module file 'h5global.mod' for reading at (1): No such file or directory This error disappears if the module order is changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug fortran/38114] unneeded temp
--- Comment #2 from jv244 at cam dot ac dot uk 2008-11-19 13:08 --- (In reply to comment #1) SUBROUTINE S(b,i,j) INTEGER, DIMENSION(:) :: b integer res(1) INTEGER :: i,j res = MINLOC(b(i:j)) END SUBROUTINE S right.. the 'orginal' testcase was. Actually, these temps are all derived for CP2K sources. SUBROUTINE S(b,i,j) INTEGER, DIMENSION(:) :: b integer res INTEGER :: i,j res = SUM(MINLOC(b(i:j))) END SUBROUTINE S -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38114
[Bug fortran/38111] unneeded temporary
--- Comment #2 from jv244 at cam dot ac dot uk 2008-11-19 13:18 --- (In reply to comment #1) Do you know of any compilers that catch this? As you say, it is not so easy to fix. I believe ifort gets this right (compiled with 'ifort -S -heap-arrays 64), but this is just looking at the assembly, which normally contains calls to for_allocate if a temp is generated: s1_: # parameter 1: %rdi ..B1.1: # Preds ..B1.0 ..___tag_value_s1_.1: #1.12 movq 48(%rdi), %rsi#4.1 movl $1, %r8d #4.1 testq %rsi, %rsi#4.1 jle ..B1.5# Prob 10% #4.1 # LOE rbx rbp rsi rdi r8 r12 r13 r14 r15 ..B1.2: # Preds ..B1.1 movq (%rdi), %rax #4.1 movq 56(%rdi), %rcx#4.1 movq %rcx, %rdx#4.1 subq %rcx, %rax# # LOE rax rdx rcx rbx rbp rsi r8 r12 r13 r14 r15 ..B1.3: # Preds ..B1.3 ..B1.2 movl %r8d, (%rdx,%rax) #4.1 addq %rcx, %rdx#4.1 addq $1, %r8 #4.1 cmpq %rsi, %r8 #4.1 jle ..B1.3# Prob 82% #4.1 # LOE rax rdx rcx rbx rbp rsi r8 r12 r13 r14 r15 ..B1.5: # Preds ..B1.3 ..B1.1 ret #5.1 .align2,0x90 BTW you say that this another case where an unneeded temp is created. I can see your PRs after this. Which ones come before? I've added a number of these as blocking PR36854. As mentioned before, all derived from CP2K. I believe these are relatively important to fix, the performance inpact of generating an unneeded temp can be very large. Joost Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38111
[Bug target/36133] GCC creates suboptimal ASM : Code includes unneeded TST instructions
--- Comment #10 from ams at gcc dot gnu dot org 2008-11-19 11:25 --- Subject: Bug 36133 Author: ams Date: Wed Nov 19 11:23:28 2008 New Revision: 141999 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141999 Log: 2008-11-19 Andrew Stubbs [EMAIL PROTECTED] gcc/ PR target/36133 * config/m68k/m68k.h (CC_OVERFLOW_UNUSABLE, CC_NO_CARRY): New defines. * config/m68k/m68k.c (notice_update_cc): Set cc_status properly for shift instructions. * config/m68k/m68k.md: Adjust all conditional branches that use the carry and overflow flags so they understand CC_OVERFLOW_UNUSABLE. gcc/testsuite/ PR target/36133 * gcc.target/m68k/pr36133.c: New test. Added: trunk/gcc/testsuite/gcc.target/m68k/pr36133.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/m68k/m68k.c trunk/gcc/config/m68k/m68k.h trunk/gcc/config/m68k/m68k.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36133
[Bug tree-optimization/36038] [4.4 Regression] miscompiled loop in perlbmk for -Os
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-19 13:05 --- Subject: Bug 36038 Author: jakub Date: Wed Nov 19 13:03:43 2008 New Revision: 142000 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142000 Log: PR tree-optimization/36038 * gcc.c-torture/compile/pr36038.c: Moved to... * gcc.c-torture/execute/pr36038.c: ... here. Added: trunk/gcc/testsuite/gcc.c-torture/execute/pr36038.c - copied unchanged from r141997, trunk/gcc/testsuite/gcc.c-torture/compile/pr36038.c Removed: trunk/gcc/testsuite/gcc.c-torture/compile/pr36038.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
[Bug testsuite/37326] gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized conststaticvariable 1
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2008-11-19 14:51 --- Subject: Re: gcc.dg/tree-ssa/ssa-store-ccp-3.c scan-tree-dump-times optimized conststaticvariable 1 --- Comment #6 from jakub at gcc dot gnu dot org 2008-11-18 23:17 --- IMHO if a target generates position independent code by default, but not flag_shlib by default, then it should define __pie__ and/or __PIE__ macro, but not __pic__ and/or __PIC__, as the latter implies both flag_pic and flag_shlib, while the former only pic code, which can't be overridden. Clearing 4.4 Regression, as per #c4 and #c5. Defining __pie__ and/or __PIE__ would appear somewhat misleading as HP-UX ld and dld.sl don't support position-independent executables. All executables are linked to start at a fixed address. On linux, PIE excutables are supported. In the 32-bit runtime, the linker converts memory accesses using the PIC register to accesses using the global pointer when an PIC object is linked into a final executable. The global pointer and the PIC register are the same in the 64-bit runtime, so this isn't needed. However, in both cases, a PIC object can be linked into a final executable. Thus, we need to distinguish PIC code compiled for linking into a shared library from PIC code compiled for linking into a final executable. We also need PIE suport for linux. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37326
[Bug c++/20681] [4.2/4.3/4.4 Regression] wrong control reaches warning with switches
--- Comment #22 from karol at mikronika dot com dot pl 2008-11-19 15:13
---
(In reply to comment #2)
Reduced testcase:
struct a{~a();a();};
int GetMetaCombination (int a2)
{
a bi;
switch (a2)
{
case 1:
return 18;
break;//removing this works around the warning
default:
return 0;
}
}
This also fails in gcc-4.2 (GCC) 4.2.4
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20681
[Bug bootstrap/37915] bootstrap broken for cygwin
--- Comment #4 from murali dot vemulapati at gmail dot com 2008-11-19 15:38 --- I updated to svn rev 141991 which has the above changes and did a bootstrap. The problem with compiling stc++.h seems to have been resolved. I get another error as follows in libssp: libtool: link: /home/vmk/gccdev/gcctr11/gccobj/./gcc/xgcc -B/home/vmk/gccdev/gcctr11/gccobj/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -shared .libs/ssp.o .libs/gets-chk.o .libs/memcpy-chk.o .libs/memmove-chk.o .libs/mempcpy-chk.o .libs/memset-chk.o .libs/snprintf-chk.o .libs/sprintf-chk.o .libs/stpcpy-chk.o .libs/strcat-chk.o .libs/strcpy-chk.o .libs/strncat-chk.o .libs/strncpy-chk.o .libs/vsnprintf-chk.o .libs/vsprintf-chk.o -Wl,--version-script=/home/vmk/gccdev/gcctr11/gcc/libssp/ssp.map -o .libs/cygssp-0.dll -Wl,--enable-auto-image-base -Xlinker --out-implib -Xlinker .libs/libssp.dll.a Creating library file: .libs/libssp.dll.a .libs/ssp.o: In function `fail': /home/vmk/gccdev/gcctr11/gcc/libssp/ssp.c:109: undefined reference to `___chkstk' .libs/gets-chk.o: In function `__gets_chk': /home/vmk/gccdev/gcctr11/gcc/libssp/gets-chk.c:66: undefined reference to `___chkstk' collect2: ld returned 1 exit status make[3]: *** [libssp.la] Error 1 make[3]: Leaving directory `/home/vmk/gccdev/gcctr11/gccobj/i686-pc-cygwin/libssp' make[2]: *** [all] Error 2 make[2]: Leaving directory `/home/vmk/gccdev/gcctr11/gccobj/i686-pc-cygwin/libssp' make[1]: *** [all-target-libssp] Error 2 make[1]: Leaving directory `/home/vmk/gccdev/gcctr11/gccobj' make: *** [bootstrap] Error 2 ]0;~/gccdev/gcctr11/gccobj -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37915
[Bug tree-optimization/38156] gcc.dg/tree-ssa/update-unswitch-1.c fails when compiled with -ftree-parallelize-loops=4
--- Comment #2 from razya at il dot ibm dot com 2008-11-19 16:00 --- (In reply to comment #1) (In reply to comment #0) testsuite/gcc.dg/tree-ssa/update-unswitch-1.c is failing when compiled with -ftree-parallelize-loops=4 In function âblaâ: /Develop/mainline_parallel/gcc/gcc/testsuite/gcc.dg/tree-ssa/update-unswitch-1.c:4: internal compiler error: Segmentation fault There are reduction patterns in this tescase, for which the field are not recorded properly. Would like to be assigned for this bug. Razya patch : http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00882.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38156
[Bug tree-optimization/38156] gcc.dg/tree-ssa/update-unswitch-1.c fails when compiled with -ftree-parallelize-loops=4
--- Comment #3 from razya at gcc dot gnu dot org 2008-11-19 16:09 --- Subject: Bug 38156 Author: razya Date: Wed Nov 19 16:08:01 2008 New Revision: 142004 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142004 Log: 2008-11-19 Razya Ladelsky [EMAIL PROTECTED] PR target/38156 * tree-parloops.c (loop_parallel_p): NULL vect_dump. (separate_decls_in_region): Create shared struct even when there are only reductions. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-parloops.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38156
[Bug fortran/38171] [regression] equivalence and nested modules broken
--- Comment #7 from pault at gcc dot gnu dot org 2008-11-19 16:21 --- (In reply to comment #6) I don't know if the code in comment #0 is valid or not, but if the file h5global.mod does not exist compiling it with gfortran r141995 gives: pr38171.f90:2.14: USE H5GLOBAL 1 Fatal Error: Can't open module file 'h5global.mod' for reading at (1): No such file or directory Yes, the reporter had obviously already compiled the code so that the module was present:-) It is correct when it's the right way round and it's pukka fortran. Paul This error disappears if the module order is changed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38171
[Bug fortran/38152] ICE for procedure pointer assignment
--- Comment #5 from dominiq at lps dot ens dot fr 2008-11-19 16:29 --- On powerpc-apple-darwin9 I have the same kind of error as reported in comment #4: /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:21:non-relocatable subtraction expression, _procptr minus L001$pb /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:21:symbol: _procptr can't be undefined in a subtraction expression /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:19:non-relocatable subtraction expression, _procptr minus L001$pb /var/folders/FK/FKCVPmNbH5SNynFQmqGomk+++TI/-Tmp-//cctJDhJw.s:19:symbol: _procptr can't be undefined in a subtraction expression in this case for 32 and 64 bit modes. The errors disappear if I compile with -fno-PIC (ppc/intel). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38152
[Bug other/38177] New: Internal compiler error during gcc build with -march=amdfam10
During a compile of gcc 4.3.2 through gentoo's portage with or without gentoo-specific patches, and cflags of -march=native -O2 -pipe on an amdfam10 processor, an internal compiler error occurs consistently: /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/sbitmap.c: In function 'sbitmap_popcount': /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/sbitmap.c:1047: internal compiler error: in memory_address_length, at config/i386/i386.c:16380 make[3]: *** [sbitmap.o] Error 1 make[3]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.3.2/work/build/gcc' make[2]: *** [all-stageprofile-gcc] Error 2 make[2]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.3.2/work/build' make[1]: *** [stageprofile-bubble] Error 2 make[1]: Leaving directory `/var/tmp/portage/sys-devel/gcc-4.3.2/work/build' make: *** [profiledbootstrap] Error 2 The command executed to build that file is: /var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/xgcc -B/var/tmp/portage/sys-devel/gcc-4.3.2/work/build/./prev-gcc/ -B/usr/i686-pc-linux-gnu/bin/ -c -O2 -march=native -pipe -fprofile-generate -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/. -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../include -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libcpp/include -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libdecnumber -I/var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/../libdecnumber/bid -I../libdecnumber /var/tmp/portage/sys-devel/gcc-4.3.2/work/gcc-4.3.2/gcc/sbitmap.c -o sbitmap.o This error *does* occur with the cflags -O1 -march=native -pipe (-O1 rather than -O2) and does *not* occur with cflags of -O1 -pipe - leading me to believe that the problem lies in the native optimizations for the processor (AMD Phenom 9850 Quad-Core). I have not attempted to build gcc outside of portage, or with -march=amdfam10 (rather than native) in cflags. I have only attempted to reproduce this within a VM (VMWare Workstation 6.5), but I don't believe that is relevant due to its design - these instructions should be executed natively. I can, with significant effort, try this build outside of a VM if absolutely necessary. I can help reproduce, test, or provide information about this problem as needed. -- Summary: Internal compiler error during gcc build with - march=amdfam10 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: special at dereferenced dot net 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=38177
[Bug middle-end/37742] [4.4 Regression] ICE in vectorizer with restrict pointer
--- Comment #19 from rguenther at suse dot de 2008-11-19 17:43 --- Subject: Re: [4.4 Regression] ICE in vectorizer with restrict pointer On Tue, 18 Nov 2008, jakub at gcc dot gnu dot org wrote: --- Comment #18 from jakub at gcc dot gnu dot org 2008-11-18 20:13 --- Created an attachment (id=16719) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16719action=view) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16719action=view) incremental patch This fixed matmul_i2.c, DR_BASE_ADDRESS wasn't in this case TYPE_RESTRICT, nor SSA_NAME, but POINTER_PLUS_EXPR, yet in the end was based on a restrict pointer. Unfortunately other matmul*.c stuff in libgfortran is still broken. I'm wondering if the strict alias checking introduced in r140781 isn't too eager when restricted pointers are used... It can/should be relaxed to do an alias_sets_conflict_p check instead of the subset check. No idea if that helps - but also the patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00286.html should fix all of the current issues (maybe not optimally though). Note that I added the alias checks to catch wrong-code issues. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37742
[Bug c++/37352] thunks for virtual function should work on lto
--- Comment #2 from espindola at google dot com 2008-11-19 17:49 --- To reproduce: g++ -O2 -c thunk.C -flto-single -o thunk-lto.o g++ -O2 -c thunk.C -o thunk.o readelf -s thunk.o | grep Th 35: 6 FUNCWEAK DEFAULT 19 _ZThn8_N1C1fEv readelf -s thunk-lto.o | grep Th 26: 0 NOTYPE GLOBAL DEFAULT UND _ZThn8_N1C1fEv -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37352
[Bug c++/37352] thunks for virtual function should work on lto
--- Comment #3 from espindola at google dot com 2008-11-19 17:53 --- This case can be easily fixed by setting targetm.asm_out.can_output_mi_thunk to NULL. This will introduce a performance regression. The only case that will be missing is varg functions. The llvm equivalent bug is http://llvm.org/bugs/show_bug.cgi?id=2861. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37352
[Bug c++/37352] thunks for virtual function should work on lto
--- Comment #1 from espindola at google dot com 2008-11-19 17:47 --- Created an attachment (id=16722) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16722action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37352
[Bug middle-end/37565] __optimize__ attribute doesn't work correctly
--- Comment #8 from hjl dot tools at gmail dot com 2008-11-19 18:09 --- I think we need to break OVERRIDE_OPTIONS into 2 parts: 1. Execute only once for a given input. 2. Execute every time after all optimization options are processed. with things like OVERRIDE_OPTIONS_ONCE and OVERRIDE_OPTIONS_ALWAYS. Then OVERRIDE_OPTIONS can be defined as #define OVERRIDE_OPTIONS \ OVERRIDE_OPTIONS_ALWAYS; \ OVERRIDE_OPTIONS_ONCE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565
[Bug c++/38178] New: devirtualization is missing in lto
we have to fix g++.dg/opt/devirt1.C -- Summary: devirtualization is missing in lto Product: gcc Version: lto Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: espindola at google dot com 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=38178
[Bug target/29987] libgomp.c++/ctor-9.C failure
--- Comment #9 from ro at techfak dot uni-bielefeld dot de 2008-11-19 18:05 --- Subject: Re: libgomp.c++/ctor-9.C failure ro at techfak dot uni-bielefeld dot de writes: jakub at gcc dot gnu dot org writes: Anyway, the following patch fixes this in a cross from x86_64-linux to sparc*-sun-solaris10. Can somebody please bootstrap/regtest it? will do, thanks. Bootstrap with the patch completed (unlike the situation without, where libgomp.so failed to link). Testresults are still hampered by the following gld 2.19 warning /vol/gcc/lib/gld-2.19: warning: section `.bss' type changed to PROGBITS which I'll investigate. There's something in http://sourceware.org/bugzilla/show_bug.cgi?id=7027 (Comments #18 - 24). It seems like Sun as doesn't mark .bss.* sections as NOBITS. Probably another bug to take up with Sun. Does i?86-sun-solaris* as have the same bug or not? I'll have to check this. Currently, one cannot use Sun as for x86_64, so the default config will use gas instead. I'll try the non-multilib config and see if it is affected as well. Apart from the problems reported in Comment #8, Sun as heavily chokes on the tls conftest_s in gcc/configure.ac: * as is invoked with the gas-only --fatal-warnings, which lets Sun as choke. * The test itself uses the gas .section syntax that Sun as doesn't understand. To properly handle this, one would need to have two sections as in the sparc-*-solaris2* case. Right now, it doesn't make much sense to pursue this. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29987
[Bug other/37463] [4.4 regression] All Solaris/x86 eh tests fail
--- Comment #13 from ebotcazou at gcc dot gnu dot org 2008-11-19 18:51
---
I'm a bit unsure how to test this right now: what I find is that C objects
have read-only .eh_frame sections and use .cfi* directives, while C++, Java
and Ada objects have read-write .eh_frame sections and still use .eh_frame
sections directly emitted by the compiler.
The decision is made in dwarf2out_do_cfi_asm:
/* Decide whether to emit frame unwind via assembler directives. */
int
dwarf2out_do_cfi_asm (void)
{
int enc;
#ifdef MIPS_DEBUGGING_INFO
return false;
#endif
if (!flag_dwarf2_cfi_asm || !dwarf2out_do_frame ())
return false;
if (!eh_personality_libfunc)
return true;
if (!HAVE_GAS_CFI_PERSONALITY_DIRECTIVE)
return false;
/* Make sure the personality encoding is one the assembler can support.
In particular, aligned addresses can't be handled. */
enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/2,/*global=*/1);
if ((enc 0x70) != 0 (enc 0x70) != DW_EH_PE_pcrel)
return false;
enc = ASM_PREFERRED_EH_DATA_FORMAT (/*code=*/0,/*global=*/0);
if ((enc 0x70) != 0 (enc 0x70) != DW_EH_PE_pcrel)
return false;
return true;
}
On Solaris with Sun ld, ASM_PREFERRED_EH_DATA_FORMAT is defined so that at
least one of the 2 tests will always return false. Therefore the only way
to have dwarf2out_do_cfi_asm return true is
if (!eh_personality_libfunc)
return true;
The C++, Java and Ada compilers unconditionally register their personality
routine, whereas the C compiler doesn't, even with -fexceptions: if there
is no EH action in the code, it doesn't register it. Hence the discrepancy.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37463
[Bug c/38179] New: need a warning: macro parameter is not a whole expression within macro body
This affects both C and C++ (and probably Objective C that I never used)
(In fact, I propose two warnings:
1. macro parameter is not a whole expression within macro body
2. expanded macro body is not a whole expression within macro use context
)
I propose to add a warning (and include it in -Wall) for the following sort of
bugs:
#define FLAGA 1
#define FLAGB 2
#define MYMACRO(x) x 0xFF00 ? dothis(x) : dothat(x)
int t = MYMACRO(FLAGA|FLAGB);
The expanded text is
int t = FLAGA|FLAGB 0xFF00 ? dothis(FLAGA|FLAGB) : dothat(FLAGA|FLAGB);
and it is obvious that due to the bug the conditional expression is evaluated
to true while it should have been false, and the right branch will not be
chosen.
(this would produce the macro parameter is not a whole expression within macro
body warning)
The same applies to
int t = 10 + MYMACRO(FLAGA|FLAGB);
where 10 will be a part of the conditional expression.
(this would produce the expanded macro body is not a whole expression within
macro use context warning)
But: it is important not to produce such warnings when the macro parameter or
body in principle cannot be a whole expression, for example, contains ; or
{.
-
AN APPROACH TO IMPLEMENTATION
I would suggest something like weak parens, say, #( and #)
int t = MYMACRO(FLAGA|FLAGB);
would expand to
int t = #( FLAGA|FLAGB #) 0xFF00 ? dothis( #( FLAGA|FLAGB #) ) : dothat(
#( FLAGA|FLAGB #) );
Here we can issue a warning because when we compare the tree parsed as weak
parens as parens vs the tree parsed as weak parens are spaces, we get
different results.
Surrounding the whole expression with weak parens #{ and #} would solve the
problem of expanded macro text broken by higher-priority operators:
int t = 10 + MYMACRO(FLAGA|FLAGB);
would expand to
int t = 10 + #{ #( FLAGA|FLAGB #) 0xFF00 ? dothis( #( FLAGA|FLAGB #) ) :
dothat( #( FLAGA|FLAGB #) ) #} ;
and, again, replacing #{ #} with parens or spaces we get different trees.
And what about
#define OH_MY_GOD 20; y=
x = OH_MY_GOD 10;
?
It expands to
x = #{ 20; y = #} 10;
We must just ignore weak parens that are not balanced (both #{ #} and #( #) ).
At least, options enabled via -Wall and -Wextra *MUST_NOT* produce warnings for
such cases.
The same about SOME_MACRO(x();y(), z();t()), weak parens cannot be replaced by
parens here.
I do not think that checking possible replacement of weak parens by braces { }
is that important, we can live without it.
Example of a case that is not so important:
#define SOME_MACRO(x,y)if(my_boolean)x;else y;
SOME_MACRO(x();y(), z();t())
--
Summary: need a warning: macro parameter is not a whole
expression within macro body
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mlg7 at yandex dot ru
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38179
[Bug c/38179] need a warning: macro parameter is not a whole expression within macro body
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-19 18:57 --- The expanded text for the first one is: int t = 1|2 0xFF00 ? dothis(1|2) : dothat(1|2); Maybe I am missing something here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38179
[Bug c++/37256] [4.4 Regression] extern template / explicit instantiation broken in 4.4.0-pre
--- Comment #8 from jason at gcc dot gnu dot org 2008-11-19 19:29 --- Subject: Bug 37256 Author: jason Date: Wed Nov 19 19:27:29 2008 New Revision: 142014 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142014 Log: PR c++/37256 * pt.c (instantiate_decl): Don't require a definition of a template that is explicitly instantiated 'extern'. Added: trunk/gcc/testsuite/g++.dg/cpp0x/extern_template-3.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37256
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #12 from ubizjak at gmail dot com 2008-11-19 19:32 --- Created an attachment (id=16723) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16723action=view) Da patch. Jack, can you try attached patch? -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #14 from tkoenig at gcc dot gnu dot org 2008-11-19 19:33 --- The problem is fixed on trunk, I think we can close this after backporting. Mikael, if you think the problem you mentioned in comment #4 warrants its own PR, maybe you could open it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug c++/37563] [4.3/4.4 regression] Trouble calling qualified member function
--- Comment #3 from jason at gcc dot gnu dot org 2008-11-19 19:38 --- Subject: Bug 37563 Author: jason Date: Wed Nov 19 19:36:38 2008 New Revision: 142015 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142015 Log: PR c++/37563 * parser.c (cp_parser_pseudo_destructor_name): A pseudo-destructor name is not a declaration. Added: trunk/gcc/testsuite/g++.dg/template/pseudodtor5.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37563
[Bug c++/37256] [4.4 Regression] extern template / explicit instantiation broken in 4.4.0-pre
--- Comment #9 from jason at gcc dot gnu dot org 2008-11-19 19:41 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37256
[Bug tree-optimization/38180] New: CCP does not propagate through constant initializers
While constant initializer reads are folded CCP doesn't propagate the following
in one invocation but requires a second CCP pass to clean up.
/* { dg-do compile } */
/* { dg-options -O -fdump-tree-ccp1 } */
static const int x;
int foo()
{
int *p = x;
int y = *p;
return y + 1;
}
/* { dg-final { scan-tree-dump return 1; ccp1 } } */
/* { dg-final { cleanup-tree-dump ccp1 } } */
--
Summary: CCP does not propagate through constant initializers
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38180
[Bug tree-optimization/38180] CCP does not propagate through constant initializers
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-19 20:01 --- Mine. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Severity|normal |enhancement Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-19 20:01:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38180
[Bug tree-optimization/38180] CCP does not propagate through constant initializers
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-19 20:02 --- Visiting statement: p_1 = x; which is likely CONSTANT Lattice value changed to CONSTANT x. Adding SSA edges to worklist. Visiting statement: y_2 = *p_1; which is likely CONSTANT Lattice value changed to VARYING. Adding SSA edges to worklist. ccp_fold doesn't handle folding the initializer from *x. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38180
[Bug fortran/38181] New: calls to SIZE not optimized out of loops
in the function F1 below, gfortran generates calls to _gfortran_size1 which (I believe) makes that function about a factor 2-3 slower than should be. In principle the optimizer should/could realize that size(a) is invariant, and at least move it out of the loop. cat test.f90 INTEGER FUNCTION F1(a) integer :: a(:,:) F1=0 DO k=1,SIZE(a,2) DO j=1,SIZE(a,1) F1=F1+a(j,k) ENDDO ENDDO END FUNCTION F1 [EMAIL PROTECTED]:~ cat main.f90 INTERFACE INTEGER FUNCTION F1(a) integer :: a(:,:) END FUNCTION END INTERFACE INTEGER :: a(2,2),i,s a=0 DO i=1,1 s=s+F1(a) ENDDO END [EMAIL PROTECTED]:~ ifort -O3 -xW test.f90 main.f90 ; time ./a.out main.f90(9): (col. 1) remark: (irrelevant) LOOP WAS VECTORIZED. real0m1.381s user0m1.376s sys 0m0.004s [EMAIL PROTECTED]:~ gfortran -O3 -march=native test.f90 main.f90 ; time ./a.out real0m3.578s user0m3.576s sys 0m0.000s -- Summary: calls to SIZE not optimized out of loops Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran 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=38181
[Bug c/38182] stddef.h assumes machinee/ansi.h defines _ANSI_H_
--- Comment #1 from aran at 100acres dot us 2008-11-19 20:32 --- Created an attachment (id=16724) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16724action=view) Patch for stddef.h This patch ensures that _ANSI_H_ is defined after including machine/ansi.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug c/38182] New: stddef.h assumes machinee/ansi.h defines _ANSI_H_
GCC fails on NetBSD 5.x because stddef.h assumes that machine/ansi.h defines _ANSI_H_ as its code guard. This prevents the definition of size_t. -- Summary: stddef.h assumes machinee/ansi.h defines _ANSI_H_ Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: aran at 100acres dot us GCC build triplet: i386-unknown-netbsdelf5.99.02 GCC host triplet: i386-unknown-netbsdelf5.99.02 GCC target triplet: i386-unknown-netbsdelf5.99.02 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38182
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-19 20:39 --- Why is size1 not always inlined? Why is a new temporary array descriptor constructed and passed instead of using that for a? Note that the latter cannot be optimized by the compiler. Note that this is also the reason that even marking both functions pure probably does not make this loop invariant. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-19 20:39:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug c/38183] New: Useless move to memory when passing small structs to functions
Consider the following:
struct s { double x; double y; };
double f(struct s s) { return s.x + s.y; }
When compiled with optimisation, this generates:
f:
movsd %xmm1, -8(%rsp)
addsd %xmm1, %xmm0
ret
What is the movsd doing here ?
--
Summary: Useless move to memory when passing small structs to
functions
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jch at pps dot jussieu dot fr
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38183
[Bug c/38183] Useless move to memory when passing small structs to functions
-- jch at pps dot jussieu dot fr changed: What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38183
[Bug target/38183] Useless move to memory when passing small structs to functions
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-11-19 20:49 --- It works on the trunk for x86_64 darwin. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38183
[Bug fortran/38184] New: invariant RESHAPE not expanded if SOURCE is empty
This is a clone of PR38135. Reduced (a bit) testcase: integer, parameter :: N = 3 integer A(N,N) A(1:N,1:N)=reshape([integer::],[N,N],[1,2,2,2]) write(*,'(3i5)') A end -- Summary: invariant RESHAPE not expanded if SOURCE is empty Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: mikael at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38184
[Bug fortran/38135] RESHAPE gives wrong result
--- Comment #15 from mikael at gcc dot gnu dot org 2008-11-19 20:56 --- (In reply to comment #14) Mikael, if you think the problem you mentioned in comment #4 warrants its own PR, maybe you could open it. PR 38184 opened for that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38135
[Bug fortran/38184] invariant RESHAPE not expanded if SOURCE is empty
--- Comment #1 from mikael at gcc dot gnu dot org 2008-11-19 20:57 --- (In reply to comment #0) This is a clone of PR38135. Path posted there: Index: simplify.c === --- simplify.c (révision 141833) +++ simplify.c (copie de travail) @@ -3410,9 +3410,6 @@ is_constant_array_expr (gfc_expr *e) if (e-expr_type != EXPR_ARRAY || !gfc_is_constant_expr (e)) return false; - if (e-value.constructor == NULL) -return false; - for (c = e-value.constructor; c; c = c-next) if (c-expr-expr_type != EXPR_CONSTANT) return false; -- mikael at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mikael at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-19 20:57:43 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38184
[Bug c++/37563] [4.3 regression] Trouble calling qualified member function
--- Comment #4 from jason at gcc dot gnu dot org 2008-11-19 21:01 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37563
[Bug c++/37563] [4.3 regression] Trouble calling qualified member function
--- Comment #5 from jason at gcc dot gnu dot org 2008-11-19 21:01 --- Subject: Bug 37563 Author: jason Date: Wed Nov 19 21:00:23 2008 New Revision: 142016 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142016 Log: PR c++/37563 * parser.c (cp_parser_pseudo_destructor_name): A pseudo-destructor name is not a declaration. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/pseudodtor5.C - copied unchanged from r142015, trunk/gcc/testsuite/g++.dg/template/pseudodtor5.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/parser.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37563
[Bug middle-end/22141] [4.2/4.3/4.4 Regression] Missing optimization when storing structures
--- Comment #15 from jakub at gcc dot gnu dot org 2008-11-19 21:12 ---
The advantage of such a RTL pass (or just adding such optimization to another
RTL pass) would be that it would handle also say:
struct S
{
char a;
char b;
char c;
char d;
} u __attribute__((aligned));
void
f1 (void)
{
u = (struct S) { 1, 2, 3, 4 };
}
void
f2 (void)
{
u.a = 1;
u.b = 2;
u.c = 3;
u.d = 4;
}
void
f3 (void)
{
u.d = 4;
u.b = 2;
u.a = 1;
u.c = 3;
}
where only f1 used to be optimized into a single store by 3.2/3.3. The
question is, do we want to do this only if constants are stored into
neighbouring wordsize MEMs? Do we need to use cselib to canonicalize the
addresses (similarly how DSE does it), or could we just rely on
MEM_EXPR/MEM_OFFSET/MEM_SIZE? If bitfields are involved, combiner often helps
with merging adjacent bitfield stores into a single store, so this pass would
be desirable after the combiner (and probably before register allocation).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22141
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #13 from ubizjak at gmail dot com 2008-11-19 21:17 --- (In reply to comment #12) Created an attachment (id=16723) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16723action=view) [edit] Da patch. Jack, can you try attached patch? Patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg01010.html It looks we still fail va_arg cases. But number of failures with the original testcase drops from 10 to 4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug middle-end/37790] limits-fnargs.c takes very long time to compile at -O2
--- Comment #4 from vmakarov at gcc dot gnu dot org 2008-11-19 21:22 --- Subject: Bug 37790 Author: vmakarov Date: Wed Nov 19 21:20:44 2008 New Revision: 142017 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142017 Log: 2008-11-15 Vladimir Makarov [EMAIL PROTECTED] PR bootstrap/37790 * ira-int.h (ira_copy_allocno_live_range_list, ira_merge_allocno_live_ranges, ira_allocno_live_ranges_intersect_p, ira_finish_allocno_live_range_list): New prototypes. (ira_allocno_live_ranges_intersect_p, ira_pseudo_live_ranges_intersect_p): Remove. * ira-conflicts.c (ira_allocno_live_ranges_intersect_p, ira_pseudo_live_ranges_intersect_p): Rename to allocnos_have_intersected_live_ranges_p and pseudos_have_intersected_live_ranges_p. Move them from here to ... * ira-color.c: ... here (coalesced_allocno_conflict_p): Use allocnos_have_intersected_live_ranges_p. (coalesced_allocnos_living_at_program_points, coalesced_allocnos_live_at_points_p, set_coalesced_allocnos_live_points): Remove. (slot_coalesced_allocnos_live_ranges, slot_coalesced_allocno_live_ranges_intersect_p, setup_slot_coalesced_allocno_live_ranges): New. (coalesce_spill_slots): Use ranges of coalesced allocnos. (ira_sort_regnos_for_alter_reg): Use allocnos_have_intersected_live_ranges_p. (ira_reuse_stack_slot): Use pseudos_have_intersected_live_ranges_p. * global.c (pseudo_for_reload_consideration_p): Check flag_ira_share_spill_slots too. * ira-build.c (copy_allocno_live_range_list): Rename to ira_copy_allocno_live_range_list. Make it external. (merge_ranges): Rename to ira_merge_allocno_live_ranges. Make it external. (ira_allocno_live_ranges_intersect_p): New. (ira_finish_allocno_live_range_list): New. (finish_allocno): Use it. (remove_unnecessary_allocnos): Use ira_merge_allocno_live_ranges. (copy_info_to_removed_store_destinations): Ditto. Use ira_copy_allocno_live_range_list. (ira_flattening): Use ira_merge_allocno_live_ranges. * ira.c (too_high_register_pressure_p): New function. (ira): Switch off sharing spill slots if the pressure is too high. Modified: trunk/gcc/ChangeLog trunk/gcc/global.c trunk/gcc/ira-build.c trunk/gcc/ira-color.c trunk/gcc/ira-conflicts.c trunk/gcc/ira-int.h trunk/gcc/ira.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37790
[Bug bootstrap/37859] Bootstrap failure on mips64octeon-unknown-linux-gnu
--- Comment #3 from vmakarov at gcc dot gnu dot org 2008-11-19 21:26 --- Subject: Bug 37859 Author: vmakarov Date: Wed Nov 19 21:25:00 2008 New Revision: 142018 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142018 Log: 2008-11-19 Vladimir Makarov [EMAIL PROTECTED] PR bootstrap/37859 * ira-int.h (struct ira_loop_tree_node): New member entered_from_non_parent_p. * ira-color.c (print_loop_title): Print loop bbs. * ira-emit.c (entered_from_non_parent_p, setup_entered_from_non_parent_p): New functions. (not_modified_p): Rename to store_can_be_removed_p. Check there is no side entries. (generate_edge_moves): Use store_can_be_removed_p instead of not_modified_p. (ira_emit): Call setup_entered_from_non_parent_p. * ira-build.c (copy_info_to_removed_store_destinations): Accumulate CALL_FREQ, CALL_CROSSED_NUM, and ALLOCNO_EXCESS_PRESSURE_POINTS_NUM. (ira_flattening): Don't CHECK MEM_OPTIMIZED_DEST[_P], always update all accumulated attributes. Modified: trunk/gcc/ChangeLog trunk/gcc/ira-build.c trunk/gcc/ira-color.c trunk/gcc/ira-emit.c trunk/gcc/ira-int.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37859
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #7 from dodji at gcc dot gnu dot org 2008-11-19 21:27 --- Posted a patch at http://gcc.gnu.org/ml/gcc-patches/2008-11/msg00956.html -- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-08-17 09:28:13 |2008-11-19 21:27:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug c++/36410] [4.2/4.3/4.4 Regression] ICE with transparent union
--- Comment #3 from jason at gcc dot gnu dot org 2008-11-19 21:28 --- Member version of PR 35315. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug bootstrap/37859] Bootstrap failure on mips64octeon-unknown-linux-gnu
--- Comment #4 from nemet at gcc dot gnu dot org 2008-11-19 21:35 --- Fixed. -- nemet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37859
[Bug c++/36410] [4.2/4.3/4.4 Regression] ICE with transparent union
--- Comment #4 from jason at gcc dot gnu dot org 2008-11-19 21:36 --- Subject: Bug 36410 Author: jason Date: Wed Nov 19 21:35:27 2008 New Revision: 142019 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142019 Log: PR c++/36410 * decl2.c (grokfield): Pass ATTR_FLAG_TYPE_IN_PLACE for a typedef that names a class for linkage purposes. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/attrib32.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #2 from dominiq at lps dot ens dot fr 2008-11-19 21:38 --- It seems that the problem is a missed vectorization. For INTEGER FUNCTION F1(a) integer :: a(:,:), m, n m=SIZE(a,1) n=SIZE(a,2) F1=0 DO k=1,n DO j=1,m F1=F1+a(j,k) ENDDO ENDDO END FUNCTION F1 I get with gfortran pr38181_2.f90:6: note: not vectorized: too many BBs in loop. pr38181_2.f90:7: note: not vectorized: data ref analysis failed D.1605_54 = (*a.0_10)[D.1604_53]; pr38181_2.f90:1: note: vectorized 0 loops in function. while ifort reports: pr38181_2.f90(9): (col. 3) remark: LOOP WAS VECTORIZED. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #61 from jason at gcc dot gnu dot org 2008-11-19 21:42 --- Created an attachment (id=16725) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16725action=view) Compiler patch to allow try/catch and rethrow under -fno-exceptions I've attached a proposed patch to ignore try/catch/rethrow in the compiler with a warning, which should make the libstdc++ header unnecessary. Comments? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug c++/36410] [4.2/4.3 Regression] ICE with transparent union
--- Comment #5 from jason at gcc dot gnu dot org 2008-11-19 21:47 --- Fixed in 4.4. Reopen the bug if you want it fixed in 4.3 as well. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.2/4.3/4.4 Regression] ICE|[4.2/4.3 Regression] ICE |with transparent union |with transparent union http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
Graphite merge regressed PR 35107 ?
PR 35107 appears to have regressed on mainline. It was originally fixed on the trunk and 4.3 back in February: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35107 http://gcc.gnu.org/ml/gcc-patches/2008-02/msg00187.html The summary is that gmp and mpfr and unnecessarily linked into all executables (e.g. xgcc, gcov) whereas they should only be used for programs that are linked with libbackend.a like cc1. It matters when gmp/mpfr are shared libs. There's no reason to slow down the startup of all programs we provide by dynamically loading these libraries. During the graphite merge, $GMPLIBS was added back to the generic $LIBS variable and gets linked into everything. Is this really necessary? http://gcc.gnu.org/viewcvs/trunk/gcc/Makefile.in?r1=139854r2=139893 If it's not necessary, IMHO this should be fixed again before we branch 4.4. I think CLOOGLIBS and PPLLIBS need to be moved to the right places, but I don't have those libraries to test it myself. Since it would touch all the places my original patch did, perhaps it would be best to create a BACKENDLIBS and/or BACKENDDEPS variable and hook GMPLIBS, CLOOGLIBS and PPLLIBS in there. Thanks, --Kaveh -- Kaveh R. Ghazi [EMAIL PROTECTED]
[Bug c++/36410] [4.2/4.3 Regression] ICE with transparent union
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.2.4 4.3.3 Known to work||4.4.0 Target Milestone|4.2.5 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36410
[Bug c++/37540] [4.4 regression] ICE on __decltype of method call in function template
--- Comment #7 from jason at gcc dot gnu dot org 2008-11-19 21:56 --- I'll poke at this. -- 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-09-16 17:09:22 |2008-11-19 21:56:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37540
[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error
--- Comment #8 from dodji at gcc dot gnu dot org 2008-11-19 22:28 --- Subject: Bug 35405 Author: dodji Date: Wed Nov 19 22:26:56 2008 New Revision: 142022 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142022 Log: gcc/cp/ChangeLog: 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/35405 * pt.c (lookup_template_class): Check pointers before dereferencing Them. * error.c (dump_template_decl): Likewise. gcc/testsuite/ChangeLog: 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/35405 * g++.dg/template/crash84.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/crash84.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
[Bug fortran/38181] calls to SIZE not optimized out of loops
--- Comment #3 from jakub at gcc dot gnu dot org 2008-11-19 22:32 --- Certainly in this case inlining size1 is a good idea and easily doable. The reason why the actual argument's descriptor isn't used is that it might have different lower bounds (while size doesn't care about that, other functions do). Inlining size0 on the other side might not be always the best idea, as it can be pretty large. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38181
[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error
--- Comment #9 from dodji at gcc dot gnu dot org 2008-11-19 22:37 --- Subject: Bug 35405 Author: dodji Date: Wed Nov 19 22:36:31 2008 New Revision: 142023 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142023 Log: gcc/cp/ChangeLog: 2008-11-18 Dodji Seketeli [EMAIL PROTECTED] PR c++/35405 * pt.c (lookup_template_class): Check pointers before dereferencing Them. * error.c (dump_template_decl): Likewise. gcc/testsuite/ChangeLog 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/35405 * g++.dg/template/crash84.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/crash84.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/error.c branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
[Bug libstdc++/25191] exception_defines.h #defines try/catch
--- Comment #62 from l dot lunak at suse dot cz 2008-11-19 22:41 --- (In reply to comment #60) -fno-exceptions is a big hammer. It will break exceptions trying to pass through code compiled with that flag whether or not that code has any try/catch constructs. If you might have some code that throws, you shouldn't use -fno-exceptions; that's what broke your package. In that case I suggest you remove -fno-exceptions altogether, because it's virtually impossibly for any non-trivial C++ application to make sure it doesn't use any code that might throw, starting with operator new. Sorry, but it's about as sensible argument as yours. Let me put it simply: -fno-exceptions is an optimization that saves generating code that would not be used, in line with the C++ rule of not paying for what one does not use. So it simply makes sense to use it in projects (or parts thereof) that do no use exceptions in order to get some savings (does somebody use -fno-exceptions in any other way?). Now, such code calls code from elsewhere that may throw, and so the programmer uses also try-catch, but does not actually test that specific part, since a) it's trivial code, b) he's too busy and we're just people, c) getting an exception should be exceptional. And we have perfectly fine code that compiles, but, when it eventually comes, does not work. It may not happen in your perfect world but in the real one it does. Getting an error on try would have helped you find that problem, but that doesn't mean it's the right answer for all situations; And what other situations are there, except for people who write code with exception handling, who make sure it works even without exceptions, who are too lazy to run sed few times, who will be explicitly aware of this and who presumably will be just a handful of people in total compared to the rest? What's the problem with giving these people -fstrip-exceptions or whatever and leaving the rest as it is (with fixing libstdc++)? if I'm writing code that may be used by other programs, I should write it to be exception-safe even if I don't throw any exceptions myself. Irrelevant, this is the other way around. Perhaps we could just warn once if we see try/catch outside library headers with -fno-exceptions. I'd love to live in your perfect world. Sadly, I don't, so I'm looking forward to having to take care of code that will not have -Wexceptions in its flag (since it needs to be explicitly enabled, right?) or where one warning will get easily overlooked for whatever reason. I really fail to see what's so complicated about not letting one shoot themselves in the foot just because of lazy people with special needs. Thanks for trying, anyway. -- l dot lunak at suse dot cz changed: What|Removed |Added CC|l dot lunak at suse dot cz | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25191
[Bug c++/35405] [4.2/4.3/4.4 Regression] Internal compiler error
--- Comment #10 from dodji at gcc dot gnu dot org 2008-11-19 22:49 --- Fixed in trunk and gcc-4_3-branch. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35405
[Bug tree-optimization/38072] [4.3 Regression] ICE during inlining of valid code
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-19 22:57 --- We are remapping (gdb) up #4 0x08330b6c in remap_type_1 (type=0xb7d835b0, id=0xbfbe96a4) at /home/richard/src/gcc-4_3-branch/gcc/tree-inline.c:403 403 walk_tree (TYPE_SIZE_UNIT (new), copy_body_r, id, NULL); which contains an SSA_NAME that is in the freelist. Both size and unit-size are expressions. iftmp.1_6 = (struct TestObjC[0:size.0 + -1] *) D.1854_5 it looks like that we do not gimplify all of the parameter types. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38072
[Bug c++/38185] New: Wrong register used to get struct information
Setup: gcc version: 4.2.3 system: Linux RedHat 4, x86-64 CPU, kernel 2.6.9-67.ELsmp To reproduce: Compile attached program as follows: g++ -m32 -O2 -g a.ii and run a.out. You'll see assert failure on line 11669 of a.ii. If you use -O1 instead of -O2, the program passes. I verified that the correct behaviour for the program is to pass. When I traced the execution in the debugger, I found that a wrong register (edx instead of eax) is used to access a variable. It seems GCC has lost track what edx register refers to when it calls get_r_or_f() for the second time. On a high level, the program iterates over a two-element linked list. It looks at the first element, decides to increment the iterator, then looks at the second element. In the correct behaviour, the iterator (B::list_iter) is left pointing to the second element. In buggy behaviour, the iterator is incremented twice, left pointing to the end iterator. In buggy version, while looking at the content of the second list element, the program uses wrong register to access one of the values (bsi.m_type on line 11,627). Instead of getting second list element's m_type, it gets it from the first! This bug reproduces exactly on 4.2.1. It does not reproduce on 4.3.0. However, the assembly code on 4.3.0 looks very different from 4.2.3. This bug shows up and disappears with tiniest unrelated changes to the code. E.g. printing if list_iter == end_iter at the beginning of is_legal_position() would make the bug go away. Please let me know if there is a work-around for the issue with gcc 4.2.3. I'm currently using -O1 and don't mind using it if I'm sure that the bug is caused by a -O2-specific optimization (and not simply re-jigs the code). -- Summary: Wrong register used to get struct information Product: gcc Version: 4.2.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ddenisen at altera dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38185
[Bug c++/38185] Wrong register used to get struct information
--- Comment #1 from ddenisen at altera dot com 2008-11-19 23:57 --- Created an attachment (id=16726) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16726action=view) Compile with g++ -m32 -O2 a.ii to reproduce the crash The source code that shows the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38185
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #8 from dodji at gcc dot gnu dot org 2008-11-20 00:02 --- Subject: Bug 37142 Author: dodji Date: Thu Nov 20 00:00:39 2008 New Revision: 142025 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142025 Log: gcc/testsuite/ChangeLog: 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/37142 * g++.dg/template/crash85.C: New test. gcc/cp/ChangeLog 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/37142 * pt.c (coerce_template_template_parm): Use the more robust uses_template_parms instead of dependent_type_p. Added: trunk/gcc/testsuite/g++.dg/template/crash85.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #9 from dodji at gcc dot gnu dot org 2008-11-20 00:06 --- Subject: Bug 37142 Author: dodji Date: Thu Nov 20 00:05:04 2008 New Revision: 142026 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142026 Log: gcc/cp/ChangeLog: 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/37142 * pt.c (coerce_template_template_parm): Use the more robust uses_template_parms instead of dependent_type_p. gcc/testsuite/ChangeLog: 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/37142 * g++.dg/template/crash79.C: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/crash79.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/pt.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #10 from dodji at gcc dot gnu dot org 2008-11-20 00:14 --- Subject: Bug 37142 Author: dodji Date: Thu Nov 20 00:13:15 2008 New Revision: 142027 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142027 Log: gcc/cp/ChangeLog: 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/37142 * pt.c (coerce_template_template_parm): Use the more robust uses_template_parms instead of dependent_type_p. gcc/testsuite/ChangeLog/ 2008-11-19 Dodji Seketeli [EMAIL PROTECTED] PR c++/37142 * g++.dg/template/crash71.C: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/crash71.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug c++/37142] [4.2/4.3/4.4 Regression] ICE: in dependent_type_p, at cp/pt.c:15585
--- Comment #11 from dodji at gcc dot gnu dot org 2008-11-20 00:15 --- Fixed in trunk, 4.3 and 4.2 branches. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37142
[Bug rtl-optimization/37263] [4.3 Regression] extra code for doloop with unsigned 32bit types on LP64
--- Comment #7 from cnstar9988 at gmail dot com 2008-11-20 00:58 --- ping... 4.3.3? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37263
[Bug target/38151] structures with _Complex arguments are not passed correctly
--- Comment #14 from howarth at nitro dot med dot uc dot edu 2008-11-20 01:10 --- The patch from Comment 13 when applied to gcc trunk (without a complete bootstrap) eliminates the failures in gcc.dg-struct-layout-1 at -m64 while not introducing any at -m32 on i686-apple-darwin9. I am doing a complete bootstrap and make check against current gcc trunk. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38151
[Bug c++/36631] [4.3/4.4 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-20 01:48 --- Subject: Bug 36631 Author: jakub Date: Thu Nov 20 01:47:10 2008 New Revision: 142033 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142033 Log: PR c++/36631 * gimplify.c (gimplify_call_expr): Defer most of the cannot inline checking until GIMPLE lowering. * gimple-low.c (check_call_args): New function. (lower_stmt) case GIMPLE_CALL: Call it. * g++.dg/template/call5.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/call5.C Modified: trunk/gcc/ChangeLog trunk/gcc/gimple-low.c trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36631
[Bug c++/36631] [4.3 Regression] attribute always_inline - sorry, unimplemented: recursive inlining
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Known to work|4.2.4 |4.2.4 4.4.0 Last reconfirmed|2008-08-07 15:25:00 |2008-11-20 01:51:15 date|| Summary|[4.3/4.4 Regression]|[4.3 Regression] attribute |attribute always_inline - |always_inline - sorry, |sorry, unimplemented: |unimplemented: recursive |recursive inlining |inlining http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36631
[Bug c/38186] New: when using gcc compile the code with option -g3, I find the inline assemble code are palced in section .debug_macinfo
the source code sample: ... ULONG MON_OnCallGetIndex(); __asm__ (MON_OnCallGetIndex:lwz 3, 0(1)\n\ lwz 4, 4(3)\n\ lwz 3, 124(4)\n\ blr); ... -- Summary: when using gcc compile the code with option -g3, I find the inline assemble code are palced in section .debug_macinfo Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zuogang at huawei dot com GCC host triplet: dell workstation x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38186
[Bug c/38187] New: when using gcc compile the code with option -g3, I find the inline assemble code are palced in section .debug_macinfo
the source code sample: ... ULONG MON_OnCallGetIndex(); __asm__ (MON_OnCallGetIndex:lwz 3, 0(1)\n\ lwz 4, 4(3)\n\ lwz 3, 124(4)\n\ blr); ... -- Summary: when using gcc compile the code with option -g3, I find the inline assemble code are palced in section .debug_macinfo Product: gcc Version: 3.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zuogang at huawei dot com GCC host triplet: dell workstation x http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38187
[Bug fortran/38082] string truncated on return from subroutine (calling mkdtemp bind(c))
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2008-11-20 02:38 --- Sounds like it's fixed. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38082
[Bug fortran/38188] New: Inconsistent function results depending on irrelevant write statement
I am getting unreliable results from a small function using the latest prepackaged Mac OS build (PPC) available from the wiki download page. The function behaves correctly if an otherwise irrelevant write statement is added. When the statement is removed, the function returns gibberish. This is ancient code which worked on older versions of gfortran, so hopefully I haven't overlooked an obvious problem... $ uname -a Darwin Numenor 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386 $ gfortran --version GNU Fortran (GCC) 4.4.0 20080823 (experimental) [trunk revision 139508] $ cat xx.f program xx real xa(102) do 10 i=1,100 10 xa(i)=float(i) call scale (xa,23.,100,1) write (*,*) xa(101), xa(102) end subroutine scale(arr,axlen,npts,kcycle) real :: arr(*),axlen,minval,maxval,val integer :: npts,kcycle minval = +INF maxval = -INF do i=0,npts-1 val=arr(1+kcycle*i) minval=amin1(val,minval) maxval=amax1(val,maxval) end do arr(npts*kcycle+1)=minval arr(npts*kcycle+kcycle+1)=(maxval-minval)/axlen c If the following line is uncommented, the function will work c write (*,*) 3 end subroutine scale # Correct function result (write statement is left in) $ gfortran -o xx xx.f $ xx 3 0.000 4.3478260 # Incorrect function result (write statement is commented out) $ gfortran -o xx xx.f $ xx -2.13906214E+09 1.86005408E+08 -- Summary: Inconsistent function results depending on irrelevant write statement Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dojo at masterleep dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
Re: [Bug fortran/38188] New: Inconsistent function results depending on irrelevant write statement
I don't think INF is the same as infinity. It is most like implict declared variable with an undefined value. Sent from my iPhone On Nov 19, 2008, at 10:52 PM, dojo at masterleep dot com [EMAIL PROTECTED] wrote: I am getting unreliable results from a small function using the latest prepackaged Mac OS build (PPC) available from the wiki download page. The function behaves correctly if an otherwise irrelevant write statement is added. When the statement is removed, the function returns gibberish. This is ancient code which worked on older versions of gfortran, so hopefully I haven't overlooked an obvious problem... $ uname -a Darwin Numenor 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386 $ gfortran --version GNU Fortran (GCC) 4.4.0 20080823 (experimental) [trunk revision 139508] $ cat xx.f program xx real xa(102) do 10 i=1,100 10 xa(i)=float(i) call scale (xa,23.,100,1) write (*,*) xa(101), xa(102) end subroutine scale(arr,axlen,npts,kcycle) real :: arr(*),axlen,minval,maxval,val integer :: npts,kcycle minval = +INF maxval = -INF do i=0,npts-1 val=arr(1+kcycle*i) minval=amin1(val,minval) maxval=amax1(val,maxval) end do arr(npts*kcycle+1)=minval arr(npts*kcycle+kcycle+1)=(maxval-minval)/axlen c If the following line is uncommented, the function will work c write (*,*) 3 end subroutine scale # Correct function result (write statement is left in) $ gfortran -o xx xx.f $ xx 3 0.000 4.3478260 # Incorrect function result (write statement is commented out) $ gfortran -o xx xx.f $ xx -2.13906214E+09 1.86005408E+08 -- Summary: Inconsistent function results depending on irrelevant write statement Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dojo at masterleep dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
[Bug fortran/38188] Inconsistent function results depending on irrelevant write statement
--- Comment #1 from pinskia at gmail dot com 2008-11-20 07:05 --- Subject: Re: New: Inconsistent function results depending on irrelevant write statement I don't think INF is the same as infinity. It is most like implict declared variable with an undefined value. Sent from my iPhone On Nov 19, 2008, at 10:52 PM, dojo at masterleep dot com [EMAIL PROTECTED] wrote: I am getting unreliable results from a small function using the latest prepackaged Mac OS build (PPC) available from the wiki download page. The function behaves correctly if an otherwise irrelevant write statement is added. When the statement is removed, the function returns gibberish. This is ancient code which worked on older versions of gfortran, so hopefully I haven't overlooked an obvious problem... $ uname -a Darwin Numenor 9.5.0 Darwin Kernel Version 9.5.0: Wed Sep 3 11:29:43 PDT 2008; root:xnu-1228.7.58~1/RELEASE_I386 i386 $ gfortran --version GNU Fortran (GCC) 4.4.0 20080823 (experimental) [trunk revision 139508] $ cat xx.f program xx real xa(102) do 10 i=1,100 10 xa(i)=float(i) call scale (xa,23.,100,1) write (*,*) xa(101), xa(102) end subroutine scale(arr,axlen,npts,kcycle) real :: arr(*),axlen,minval,maxval,val integer :: npts,kcycle minval = +INF maxval = -INF do i=0,npts-1 val=arr(1+kcycle*i) minval=amin1(val,minval) maxval=amax1(val,maxval) end do arr(npts*kcycle+1)=minval arr(npts*kcycle+kcycle+1)=(maxval-minval)/axlen c If the following line is uncommented, the function will work c write (*,*) 3 end subroutine scale # Correct function result (write statement is left in) $ gfortran -o xx xx.f $ xx 3 0.000 4.3478260 # Incorrect function result (write statement is commented out) $ gfortran -o xx xx.f $ xx -2.13906214E+09 1.86005408E+08 -- Summary: Inconsistent function results depending on irrelevant write statement Product: gcc Version: unknown Status: UNCONFIRMED Severity: major Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dojo at masterleep dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
[Bug fortran/38188] Inconsistent function results depending on irrelevant write statement
--- Comment #2 from burnus at gcc dot gnu dot org 2008-11-20 07:20 --- I don't think INF is the same as infinity. It is most like implict declared variable with an undefined value. Exactly. With IMPLICIT NONE one sees that INF is an (implicitly typed) integer variable, which has an undefined value. minval = +INF maxval = -INF How about: minval = huge(minval) ! largest finite value maxval = -huge(minval)! smallest finite value or shorter (untested) min = minval(arr( [(1+kcycle*i, i=0,npts-1)] ) max = maxval(arr( [(1+kcycle*i, i=0,npts-1)] ) where (g)Fortran does internally what you want. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38188
