[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #135 from jv244 at cam dot ac dot uk 2007-07-10 07:05 --- new bogus errors compiling all.f90 ... FX, how's the nightly tester setup going? cat out all.f90:23538.44: USE util,ONLY: sort 1 Error: Symbol 'sort' referenced at (1) not found in module 'util' [...] Tue Jul 10 06:45:07 UTC 2007 (revision 126510) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug java/32712] New: error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type
I am compiling a program and the Makefile wants to use Javac. I _did_ use the "1.5" option but still got an error about "SuppressWarnings cannot be resolved to a type". I decided to see what GCC 4.3 had to say about the file. I have 4.3 installed in /usr/test . /usr/test/bin/gcc /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java gcc: error trying to exec 'ecj1': execvp: No such file or directory Typing "locate ecj1" finds nothing. Typing "locate ecj" finds many hits (mostly "ecj" is part of a DOCs name) and I do have a "/usr/bin/ecj" but no "/usr/test/bin/ecj". So lets try the GCC (4.1) that does have an ecj it could use. # gcc /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java:40: error: Invalid character '@' in input. @SuppressWarnings("serial") ^ /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java:20: error: Class or interface 'edu.rice.cs.hpcviewer.view.HPCViewerWindow' not found in import. import edu.rice.cs.hpcviewer.view.HPCViewerWindow; ^ 2 errors Since I need 5 for the annotation I pursue 4.1 no further, lets "-v" it. gcc -v /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java ... /usr/libexec/gcc/i686-pc-linux-gnu/4.2.0/jc1 /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java -quiet -dumpbase ApplicationActions.java -mtune=athlon-xp -march=athlon-xp -auxbase ApplicationActions -version -o /tmp/ccsDPdP6.s ... So that means GCC (at least 4.1 version, maybe not 4.3) wants to use "jc1" and NOT "ejc1". I locate that here: "/usr/test/libexec/gcc/i686-pc-linux-gnu/4.3.0/jc1". The driver must look there for "jc1" and not look anywhere for "ejc1" (unless the GCC 4.3 build would like to create and install "ejc1". If I try to run "jc1" with the options from above I get: # /usr/test/libexec/gcc/i686-pc-linux-gnu/4.3.0/jc1 /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java -o ApplicationActions.s /opt/HPCToolkit-OneStopShopping-TRUNK-4.9.0_810/hpcviewer/src/edu/rice/cs/hpcviewer/app/ApplicationActions.java:0: warning: no input file specified Execution times (seconds) parser: 0.00 ( 0%) usr 0.00 ( 0%) sys 0.01 (33%) wall 0 kB ( 0%) ggc TOTAL : 0.02 0.00 0.03 1230 kB So lets try help ... # /usr/test/libexec/gcc/i686-pc-linux-gnu/4.3.0/jc1 --help The following options are specific to the language Ada: -feliminate-unused-debug-types[enabled] -gnat The following options are specific to the language C: No options with the desired characteristics were found The following options are specific to the language C++: No options with the desired characteristics were found The following options are specific to the language Fortran: -J -Waliasing -Wampersand -Wcharacter-truncation -Wimplicit-interface -Wline-truncation ... It then prints all the Fortran options (how useful), the Java options, even some langtree options (and I did not specify langtree to the configure!). It continues to list every "-W", "-f", "--param option", "-W" again, then "-f" options, "target specific" options, "language-independent" options and a whole lot more. Could it be a bit less verbose? Looking through those dozen pages of (no) help it is not very clear why "jc1" says "no input file specified". So the bug is that I can't use an installed copy of GCC 4.3 to compile a ".java" file by typing "gcc file.java" because the driver looks for an executable that does not exist. Trying "-v" with GCC 4.1 to guess what to type with 4.3 gives a suggestion that does not work with 4.3 - so I'm a bit stuck trying to help myself. I can see something is wrong with the setup. To top it off. Even through I can not compile this file I can get it pre-compiled as a ".jar" file off the website at: http://www.hipersoft.rice.edu/hpctoolkit/examples.html The file is http://www.hipersoft.rice.edu/hpctoolkit/examples/HPCViewer.jar.gz (and you will likely want on of the data files to examine, they are small). When I click on that Jar file with WinXP it runs fine (Sun JDK) but if I try to open it on GNU/Linux with Iceweasel it won't work (but other Java seems OK - weeks ago). If I start Iceweasel and click on the jar file I get this message: Exception in thread "main" java.lang.NoClassDefFoundError: /opt/HPCToolkit-OneStopShopping-TRUNK-4/9/0=810/hpcviewer/build-unix/HPCViewer/jar With GCC 4.2 gij I get this message: # gij -jar HPCViewer.jar (.:5821): Gtk-WAR
[Bug tree-optimization/32705] [4.3 Regression] ICE in set_ssa_val_to, at tree-ssa-sccvn.c:1022
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2007-07-10 08:11 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 17:36:22 |2007-07-10 08:11:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32705
[Bug fortran/32707] mismatched character lengths in array
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-10 08:16 --- See also: PR29267. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32707
[Bug tree-optimization/32713] New: [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550
Once PR tree-opt/32589 is fixed, the next hurdle on 32-bit plaforms is: /home/eric/build/gcc/native32/./gcc/xgcc -B/home/eric/build/gcc/native32/./gcc/-B/home/eric/install/gcc/i586-suse-linux/bin/ -B/home/eric/install/gcc/i586-suse-linux/lib/ -isystem /home/eric/install/gcc/i586-suse-linux/include -isystem /home/eric/install/gcc/i586-suse-linux/sys-include -c -g -O2 -fPIC -W -Wall -gnatpg a-numaux.adb -o a-numaux.o +===GNAT BUG DETECTED==+ | 4.3.0 20070708 (experimental) (i586-suse-linux-gnu) GCC error: | | in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550 | | Error detected at a-numaux.adb:572:1 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html. -- Summary: [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ebotcazou at gcc dot gnu dot org BugsThisDependsOn: 32589 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713
[Bug c++/32714] New: Wrong optimisation for -O3
Overview: When using optimisation level -O3 the code generated from attached example is wrong. It is accumalating the stream increment and thus the function readFloat reads twice the same number and then it skips two in a row. Problem seems to be in this line const float val = *(const float *&)stream; when I change it to const float val = *(const float *)stream; it starts working even on -O3. Steps to reproduce: Compile this code with -O3. #include float readFloat(const char *&stream) { const float val = *(const float *&)stream; stream += sizeof(float); return val; } int main(int argc, char **argv) { float stream[] = { 2.0f, 1.0f, 2.0f, 3.0f, 4.0f, 5.0f, 6.0f }; const char *stream2 = (const char *) stream; for (float i = 0, n = readFloat(stream2); i <= n; i += 1.0f) { const float x = readFloat(stream2); const float y = readFloat(stream2); printf("%f,%f\n", x,y); } return 0; } Actual results: Prints: 1.00,1.00 3.00,3.00 5.00,5.00 Expected results: to print: 1.00,2.00 3.00,4.00 5.00,6.00 Build date & platform: gcc (GCC) 4.1.2 20070626 (Red Hat 4.1.2-13) Additional Builds and Platforms: gcc (GCC) 4.0.2 gcc (GCC) 4.1.1 gcc (GCC) 4.2.0 This bug is not reproducible on gcc 3.3 series. -- Summary: Wrong optimisation for -O3 Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: honza at jikos dot cz 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=32714
[Bug middle-end/26900] Number of iterations not know for simple loop
--- Comment #17 from spop at gcc dot gnu dot org 2007-07-10 08:30 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26900
[Bug tree-optimization/30730] -Wunsafe-loop-optimizations gives too many warnings
--- Comment #4 from spop at gcc dot gnu dot org 2007-07-10 08:31 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30730
[Bug tree-optimization/31343] ICE in data-refs dependence testing
--- Comment #4 from spop at gcc dot gnu dot org 2007-07-10 08:34 --- Fixed. -- spop at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31343
[Bug middle-end/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 09:14 --- Fixed testcase: #include __m128i int2vector(int i) { return _mm_cvtsi32_si128(i); } int vector2int(__m128i i) { return _mm_cvtsi128_si32(i); } __m128i long2vector(long long i) { return _mm_cvtsi64x_si128(i); } long long vector2long(__m128i i) { return _mm_cvtsi128_si64x(i); } mainline generates: int2vector: .LFB525: pxor%xmm0, %xmm0 movq%rdi, -8(%rsp) movq-8(%rsp), %xmm1 movss %xmm1, %xmm0 ret .LFE525: .size int2vector, .-int2vector .p2align 4,,15 .globl long2vector .type long2vector, @function long2vector: .LFB527: movq%rdi, -8(%rsp) movq-8(%rsp), %mm0 movq2dq %mm0, %xmm0 ret .LFE527: .size long2vector, .-long2vector .p2align 4,,15 .globl vector2long .type vector2long, @function vector2long: .LFB528: movq%xmm0, -16(%rsp) movq-16(%rsp), %rax ret .LFE528: .size vector2long, .-vector2long .p2align 4,,15 .globl vector2int .type vector2int, @function vector2int: .LFB526: movd%xmm0, -12(%rsp) movl-12(%rsp), %eax ret -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-07-10 09:14:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug testsuite/25241] DejaGNU does not distinguish between errors and warnings
--- Comment #57 from manu at gcc dot gnu dot org 2007-07-10 09:17 --- Subject: Bug 25241 Author: manu Date: Tue Jul 10 09:17:01 2007 New Revision: 126511 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126511 Log: 2007-07-10 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> PR testsuite/25241 * gcc.dg/pch/counter-2.c: Match every message with its appropriate directive. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/pch/counter-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25241
[Bug c/21920] aliasing violations
--- Comment #118 from rguenth at gcc dot gnu dot org 2007-07-10 09:23 --- *** Bug 32714 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||honza at jikos dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21920
[Bug c++/32714] Wrong optimisation for -O3
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 09:23 --- You violate C/C++ aliasing rules by reading/storing a value of type (char *) to a memory location of type (float *). *** This bug has been marked as a duplicate of 21920 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32714
[Bug middle-end/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #2 from pluto at agmk dot net 2007-07-10 09:23 --- this looks like a dup of PR30961. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug fortran/32715] New: improve diagnostics of attempted allocation of non-array
$> cat allocate.f90 INTEGER :: i ALLOCATE(i(3)) end $> gfortran-svn -g -Wall allocate.f90 allocate.f90:2.10: ALLOCATE(i(3)) 1 Error: Syntax error in ALLOCATE statement at (1) A message as "variable 'i' at (1) not a pointer or allocatable array" would be preferable. -- Summary: improve diagnostics of attempted allocation of non-array Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32715
[Bug middle-end/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-10 09:37 --- I don't think so, the _mm_ intrinsics are expanded via target builtins. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug c++/32716] New: Wrong code generation. Inlining problem.
Generating wrong code for the following code snippet (test.C) using namespace std; #include class A { public:int a;}; class B: public virtual A { public: A::a;}; class C : public virtual A { public:A::a;}; class D : public C, public B {}; void h ( D &x ) { x.a++; } int main () { int result ; D d; d.a = 0; h (d); result = !(d.a==1); result ? cout<<"FAILED": cout <<"SUCCESS"; return 0; } $>arm-none-eabi-g++ -O3 test.C $> arm-none-eabi-run a.out FAILED $>arm-none-eabi-g++ -O3 test.C -fno-inline-functions $> arm-none-eabi-run a.out SUCCESS $>arm-none-eabi-g++ --version arm-none-eabi-g++ (GCC) 4.3.0 20070703 (experimental) Copyright (C) 2007 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. -- Summary: Wrong code generation. Inlining problem. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pranav dot bhandarkar at gmail dot com GCC target triplet: arm-none-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug c++/32716] Wrong code generation. Inlining problem.
--- Comment #1 from pranav dot bhandarkar at gmail dot com 2007-07-10 10:02 --- Created an attachment (id=13876) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13876&action=view) Dump of the early inline pass, that highlights the problem with the inliner h() gets inlined into main but the result of the increment in h() is not used in main after inlining causing 0 to be assigned to result. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug middle-end/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #4 from ubizjak at gmail dot com 2007-07-10 10:36 --- (In reply to comment #0) > long2vector() should use a simple MOVQ instruction the way int2vector() uses > MOVD. It appears that the reason for the stack access is that the original > code > used a reg64->mem->mm->xmm path, which the optimizer partly noticed; > gcc-4.3-20070617 leaves the full path in place. > > Also, do the vector2() functions really need to access the stack? Stack access is the remain of partially implemented TARGET_INTER_UNIT_MOVES, and this was fully fixed in 4.3. The fact that gcc-4.3 leaves full path in place is due to missing pattern for vec_concat:V2DI (implemented in the patch below) where 64bit registers can be concatenated with zero (for 64bit targets) using movq instruction. With attached patch, 4.3 generates: long2vector: .LFB4: movq%rdi, %xmm0 ret .LFE4: for -march=core2 (TARGET_INTER_UNIT_MOVES allowed) and long2vector: .LFB4: movq%rdi, -8(%rsp) movq-8(%rsp), %xmm0 ret .LFE4: for -march=k8 (no TARGET_INTER_UNIT_MOVES allowed). > Finally, I've noticed several places where instructions involving 64-bit > values > use the "d/l" suffix (e.g. "long i = 0" ==> "xorl %eax, %eax"), or 32-bit > operations that use 64-bit registers (e.g. "movd %xmm0, %rax" above). Are > those > generally features, bugs, or a "who cares?" These are "who cares", produced by reload to satisfy register constraints (i.e. certain alternatives missing as an attempt to solve INTER_UNIT_MOVES requirements). They are harmles. Index: sse.md === --- sse.md (revision 126510) +++ sse.md (working copy) @@ -4717,7 +4717,7 @@ (vec_concat:V2DI (match_operand:DI 1 "nonimmediate_operand" " m,*y ,0 ,0,0,m") (match_operand:DI 2 "vector_move_operand" " C, C,Yt,x,m,0")))] - "TARGET_SSE" + "!TARGET_64BIT && TARGET_SSE" "@ movq\t{%1, %0|%0, %1} movq2dq\t{%1, %0|%0, %1} @@ -4728,6 +4728,23 @@ [(set_attr "type" "ssemov,ssemov,sselog,ssemov,ssemov,ssemov") (set_attr "mode" "TI,TI,TI,V4SF,V2SF,V2SF")]) +(define_insn "*vec_concatv2di_rex" + [(set (match_operand:V2DI 0 "register_operand" "=Yt,Yi,!Yt,Yt,x,x,x") + (vec_concat:V2DI + (match_operand:DI 1 "nonimmediate_operand" " m,r ,*y ,0 ,0,0,m") + (match_operand:DI 2 "vector_move_operand" " C,C ,C ,Yt,x,m,0")))] + "TARGET_64BIT" + "@ + movq\t{%1, %0|%0, %1} + movq\t{%1, %0|%0, %1} + movq2dq\t{%1, %0|%0, %1} + punpcklqdq\t{%2, %0|%0, %2} + movlhps\t{%2, %0|%0, %2} + movhps\t{%2, %0|%0, %2} + movlps\t{%1, %0|%0, %1}" + [(set_attr "type" "ssemov,ssemov,ssemov,sselog,ssemov,ssemov,ssemov") + (set_attr "mode" "TI,TI,TI,TI,V4SF,V2SF,V2SF")]) + (define_expand "vec_setv2di" [(match_operand:V2DI 0 "register_operand" "") (match_operand:DI 1 "register_operand" "") -- 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 Last reconfirmed|2007-07-10 09:14:14 |2007-07-10 10:36:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug c++/31743] [4.1/4.2/4.3 regression] ICE with invalid use of new
--- Comment #12 from reichelt at gcc dot gnu dot org 2007-07-10 10:44 --- > If you will tell me how to remove the flag, I will take care of it. To clean the exectuable flag on "file" you can do svn propdel svn:executable file and then commit the change. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug target/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
-- ubizjak at gmail dot com changed: What|Removed |Added Component|middle-end |target Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug preprocessor/32717] New: def value is ignored
Appeared from July 6th: For instance, if .S file has line: cmpl $FFI_TYPE_INT,%ecx and $FFI_TYPE_INT is included from ffi.h as #define FFI_TYPE_INT1 def value is ignored, and only name after dollar sign is recognized. Defines for assembler are just a string after $. As the result, linker throws undefined references: libffi_convenience.a/win32.o:../../../gcc-4.3-July7th/libffi/src/x86/win32.S:77: undefined reference to `FFI_TYPE_FLOAT' and for all other defined values. Snapshot from June 29th compiled fine. Drazen -- Summary: def value is ignored Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: drazen dot zeman at kr dot htnet dot hr GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32717
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-10 11:29 --- This is an aliasing problem (or rather a C++ FE problem): # SFT.41_31 = VDEF d.D.2508.a = 0; x.0_10 = (struct A *) &d; ... D.2747_16 = x.0_10 + D.2746_15; # VUSE D.2748_17 = D.2747_16->a; D.2749_18 = D.2748_17 + 1; # SFT.44_34 = VDEF D.2747_16->a = D.2749_18; # VUSE D.2707_1 = d.D.2508.a; D.2706_2 = D.2707_1 != 1; return D.2706_2; note how we don't identify the contrived access through the virtual base with the zero-initialization and use in main(). Instead, it seems to alias with iftmp.1_6 = (int (*__vtbl_ptr_type) (void) *) D.2735_5; # SFT.44_21 = VDEF d.D.2504._vptr.C = iftmp.1_6; ... # SFT.44_27 = VDEF d.D.2504._vptr.C = &_ZTV1D[3]; Of course the original trees created for the virtual base access is "somewhat" contrieved: (void) ((struct A *) (struct D *) x + (long unsigned int) *(long int *) (((struct D *) x)->D.2504._vptr.C + 0xffe8))->a++ ; while in main() we manage to do: struct D d; <>> >>; <>> >>; <>> >>; return = d.D.2508.a != 1; -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org, rguenth at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|arm-none-eabi | Keywords||alias, wrong-code Known to fail||4.2.0 4.2.1 4.3.0 Known to work||4.1.2 Last reconfirmed|-00-00 00:00:00 |2007-07-10 11:29:31 date|| Summary|Wrong code generation. |[4.2/4.3 Regression] Wrong |Inlining problem. |code generation. Alias and ||C++ virtual bases problem. Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug preprocessor/32717] def value is ignored
--- Comment #1 from schwab at suse dot de 2007-07-10 11:58 --- *** This bug has been marked as a duplicate of 32670 *** -- schwab at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32717
[Bug preprocessor/32670] [4.3 Regression] '$' is handled as a part of identifiers in asm
--- Comment #3 from schwab at suse dot de 2007-07-10 11:58 --- *** Bug 32717 has been marked as a duplicate of this bug. *** -- schwab at suse dot de changed: What|Removed |Added CC||drazen dot zeman at kr dot ||htnet dot hr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32670
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-10 12:52 --- Fixed with "take3.diff". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug tree-optimization/32694] [4.1/4.2 Regression] ICE in chain_of_csts_start
--- Comment #5 from jakub at gcc dot gnu dot org 2007-07-10 13:10 --- This got fixed by http://gcc.gnu.org/ml/gcc-patches/2006-11/msg00206.html on the trunk. Even is subset of those changes fixes this on 4.2 branch: --- gcc/tree-ssa-ccp.c.jj 2007-03-20 00:22:09.0 +0100 +++ gcc/tree-ssa-ccp.c 2007-07-10 14:49:15.0 +0200 @@ -2063,12 +2063,13 @@ fold_stmt_r (tree *expr_p, int *walk_sub tem = fold_binary (TREE_CODE (op0), TREE_TYPE (op0), TREE_OPERAND (op0, 0), TREE_OPERAND (op0, 1)); - set = tem && is_gimple_condexpr (tem); + set = tem && set_rhs (expr_p, tem); fold_undefer_overflow_warnings (set, fold_stmt_r_data->stmt, 0); if (set) - TREE_OPERAND (expr, 0) = tem; - t = expr; - break; + { + t = *expr_p; + break; + } } default: --- gcc/tree-ssa-propagate.c.jj 2007-03-20 00:22:09.0 +0100 +++ gcc/tree-ssa-propagate.c2007-07-10 14:55:18.0 +0200 @@ -571,7 +571,8 @@ set_rhs (tree *stmt_p, tree expr) ssa_op_iter iter; /* Verify the constant folded result is valid gimple. */ - if (TREE_CODE_CLASS (code) == tcc_binary) + if (TREE_CODE_CLASS (code) == tcc_binary + || TREE_CODE_CLASS (code) == tcc_comparison) { if (!is_gimple_val (TREE_OPERAND (expr, 0)) || !is_gimple_val (TREE_OPERAND (expr, 1))) which prevents in this case generating invalid gimple. On gcc-4_1-branch, even just the tree-ssa-propagate.c chunk cures this. Is this something which can safely be changed on the release branches? -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||dnovillo at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32694
[Bug fortran/29804] segfault with -fbounds-check on allocatable derived type components
--- Comment #7 from tkoenig at gcc dot gnu dot org 2007-07-10 13:20 --- (In reply to comment #6) > Salvatore, could you please recheck this one? I can not observe any problems, > neither on dt_bnd.f90 nor on the reduced testcase. Neither can I, it seems to have fixed itself. Should we put it into the test suite to make sure there's no regression? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29804
Re: [Bug fortran/29804] segfault with -fbounds-check on allocatable derived type components
Have you looked with valgrind or similar to see if there are errors occurring? Please definitely put in the testsuite. There may be something we don't see yet going on here.
[Bug fortran/29804] segfault with -fbounds-check on allocatable derived type components
--- Comment #8 from jvdelisle at verizon dot net 2007-07-10 13:43 --- Subject: Re: segfault with -fbounds-check on allocatable derived type components Have you looked with valgrind or similar to see if there are errors occurring? Please definitely put in the testsuite. There may be something we don't see yet going on here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29804
[Bug c++/32718] New: g++ looping on bad __label__ declaration
Following standalone code will make the compiler (g++) loop: void test() { __label__ 0; } command line: "g++ lbl.c". However "gcc lbl.c" works (with ONE error report) ! output with g++ will be: lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant lbl.c:5: error: expected `,' before numeric constant lbl.c:5: error: expected identifier before numeric constant ... output with gcc: gcc lbl.c lbl.c: In function 'test': lbl.c:5: error: parse error before numeric constant -- Summary: g++ looping on bad __label__ declaration Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tony at rogvall dot se GCC build triplet: i686-apple-darwin8 GCC host triplet: i686-apple-darwin8 GCC target triplet: i686-apple-darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32718
[Bug c++/32718] g++ looping on bad __label__ declaration
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 13:49 --- Fixed in 4.0.2. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32718
[Bug c/32719] New: ICE when compiling c-format.c
With this configure and make: [descartes:gcc/objdirs/objdir-mainline] gcc-test% cat ../../mainline/build-and-check-gcc #!/bin/tcsh /bin/rm -rf *; env CC=/pkgs/gcc-4.2.0-64/bin/gcc ../../mainline/configure --build=powerpc64-apple-darwin8.9.0 --host=powerpc64-apple-darwin8.9.0 --target=powerpc64-apple-darwin8.9.0 --with-gmp=/pkgs/gmp-4.2.1-64/ --with-mpfr=/pkgs/gmp-4.2.1-64/ --prefix=/pkgs/gcc-4.3.0-64; make -j 4 bootstrap BOOT_LDFLAGS='-Wl,-search_paths_first' >& build.log && (make install) && (make -k -j 8 check RUNTESTFLAGS="--target_board 'unix{-mcpu=970/-m64}'" >& check.log ; make mail-report.log) and with this version of gcc: [descartes:~/programs/gcc/mainline] gcc-test% cat LAST_UPDATED Mon Jul 9 12:08:01 EDT 2007 Mon Jul 9 16:08:01 UTC 2007 (revision 126488M) bootstrap fails with /Users/gcc-test/programs/gcc/objdirs/objdir-mainline/./prev-gcc/xgcc -B/Users/gcc-test/programs/gcc/objdirs/objdir-mainline/./prev-gcc/ -B/pkgs/gcc-4.3.0-64/powerpc64-apple-darwin8.9.0/bin/ -c -g -O2 -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 -Werror -fno-common -DHAVE_CONFIG_H -I. -I. -I../../../mainline/gcc -I../../../mainline/gcc/. -I../../../mainline/gcc/../include -I./../intl -I../../../mainline/gcc/../libcpp/include -I/pkgs/gmp-4.2.1-64//include -I/pkgs/gmp-4.2.1-64//include -I../../../mainline/gcc/../libdecnumber -I../../../mainline/gcc/../libdecnumber/dpd -I../libdecnumber ../../../mainline/gcc/c-format.c -o c-format.o ../../../mainline/gcc/c-format.c: In function 'check_format_info_main': ../../../mainline/gcc/c-format.c:2109: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[3]: *** [c-format.o] Error 1 make[2]: *** [all-stage3-gcc] Error 2 make[1]: *** [stage3-bubble] Error 2 make: *** [bootstrap] Error 2 -- Summary: ICE when compiling c-format.c Product: gcc Version: lno Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: lucier at math dot purdue dot edu GCC build triplet: powerpc64-apple-darwin8.9.0 GCC host triplet: powerpc64-apple-darwin8.9.0 GCC target triplet: powerpc64-apple-darwin8.9.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32719
[Bug java/32712] error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-10 15:13 --- This is not a bug, please read: http://gcc.gnu.org/gcc-4.3/changes.html Java (GCJ) gcj now uses the Eclipse Java compiler for its Java parsing needs. This enables the use of all 1.5 language features, and fixes most existing front end bugs. And also read: http://gcc.gnu.org/ml/java/2006-12/msg00070.html -- 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=32712
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #4 from ramana dot radhakrishnan at celunite dot com 2007-07-10 15:14 --- (In reply to comment #3) > Fixed with "take3.diff". > Did you forget to attach take3.diff ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #5 from rguenther at suse dot de 2007-07-10 15:32 --- Subject: Re: [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem. On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote: > --- Comment #4 from ramana dot radhakrishnan at celunite dot com > 2007-07-10 15:14 --- > (In reply to comment #3) > > Fixed with "take3.diff". > > > > Did you forget to attach take3.diff ? No, that was a hint to Danny ;) Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug fortran/32720] New: No coalesce ssa_names
Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror --disable-libunwind-exceptions --disable-checking --disable-decimal-float --enable-shared --enable-tls --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=fortran --with-cpu=pentium3 --with-system-zlib Thread model: posix gcc version 4.3.0 20070710 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 lexlin.f90 -quiet -dumpbase lexlin.f90 -mtune=pentium3 -auxbase lexlin -O2 -version -fintrinsic-modules-path /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/finclude -o lexlin.s GNU F95 version 4.3.0 20070710 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070710 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Unable to coalesce ssa_names 1 and 86 which are marked as MUST COALESCE. ichr_1(ab) and ichr_86(ab) lexlin.f90: In function 'lexlin': lexlin.f90:1: internal compiler error: SSA corruption Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. -- Summary: No coalesce ssa_names Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rosana07a at gmail dot com GCC build triplet: i686 GCC host triplet: i686 GCC target triplet: i686 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug tree-optimization/32721] New: CCP removes volatile qualifiers.
With today's trunk on a private port . consider the following testcase. volatile int spinlock[2]; void main (void) { volatile int * spinlock0; volatile int * spinlock1; spinlock0 = &spinlock[0]; spinlock1 = &spinlock[1]; *spinlock0 = 0; *spinlock1 = 0; while (*spinlock0); } CCP folds this into the following form Simulating block 4 Simulating block 3 Substituing values and folding statements Folded statement: *spinlock0_1 = 0; into: spinlock[0] = 0; Folded statement: *spinlock1_2 = 0; into: spinlock[1] = 0; Folded statement: D.1498_3 = *spinlock0_1; into: D.1498_3 = spinlock[0]; main () { volatile int * spinlock1; volatile int * spinlock0; int D.1498; : spinlock0_1 = &spinlock[0]; spinlock1_2 = &spinlock[1]; spinlock[0] = 0; spinlock[1] = 0; : D.1498_3 = spinlock[0]; ---> This folding seems to be wrong. if (D.1498_3 != 0) goto ; else goto ; : return; } -- Summary: CCP removes volatile qualifiers. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ramana dot radhakrishnan at celunite dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug fortran/32720] No coalesce ssa_names
--- Comment #1 from rosana07a at gmail dot com 2007-07-10 16:07 --- Created an attachment (id=13877) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13877&action=view) failing *.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug fortran/32720] No coalesce ssa_names
--- Comment #2 from rosana07a at gmail dot com 2007-07-10 16:08 --- Created an attachment (id=13878) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13878&action=view) 1st req *.mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug fortran/32720] No coalesce ssa_names
--- Comment #3 from rosana07a at gmail dot com 2007-07-10 16:09 --- Created an attachment (id=13879) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13879&action=view) 2nd req *.mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug fortran/32720] No coalesce ssa_names
--- Comment #4 from rosana07a at gmail dot com 2007-07-10 16:10 --- Created an attachment (id=13880) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13880&action=view) 3rd req *.mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug fortran/32720] No coalesce ssa_names
--- Comment #5 from rosana07a at gmail dot com 2007-07-10 16:11 --- Created an attachment (id=13881) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13881&action=view) 4th req *.mod -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug java/32712] error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type
--- Comment #2 from drow at gcc dot gnu dot org 2007-07-10 16:12 --- Subject: Re: error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type On Tue, Jul 10, 2007 at 03:13:42PM -, pinskia at gcc dot gnu dot org wrote: > This is not a bug, please read: http://gcc.gnu.org/gcc-4.3/changes.html > Java (GCJ) > > gcj now uses the Eclipse Java compiler for its Java parsing needs. This > enables > the use of all 1.5 language features, and fixes most existing front end bugs. > > And also read: > http://gcc.gnu.org/ml/java/2006-12/msg00070.html It Would Be Nice if it were easier to figure out what you had to do, though. Non-gcj-hackers don't know to look in contrib for a magic script. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32712
[Bug fortran/32720] No coalesce ssa_names
--- Comment #6 from rosana07a at gmail dot com 2007-07-10 16:14 --- Works with -O0 Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc-4.3.0/configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --disable-nls --disable-multilib --disable-werror --disable-libunwind-exceptions --disable-checking --disable-decimal-float --enable-shared --enable-tls --enable-threads=posix --enable-bootstrap --enable-__cxa_atexit --enable-clocale=gnu --enable-languages=fortran --with-cpu=pentium3 --with-system-zlib Thread model: posix gcc version 4.3.0 20070710 (experimental) /usr/libexec/gcc/i686-pc-linux-gnu/4.3.0/f951 lexlin.f90 -quiet -dumpbase lexlin.f90 -mtune=pentium3 -auxbase lexlin -O0 -version -fintrinsic-modules-path /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/finclude -o lexlin.s GNU F95 version 4.3.0 20070710 (experimental) (i686-pc-linux-gnu) compiled by GNU C version 4.3.0 20070710 (experimental), GMP version 4.2.1, MPFR version 2.2.1-p5. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /usr/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/bin/as -V -Qy -o lexlin.o lexlin.s GNU assembler version 2.17.50.0.16 (i686-pc-linux-gnu) using BFD version (Linux/GNU Binutils) 2.17.50.0.16.20070511 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug tree-optimization/32721] CCP removes volatile qualifiers.
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 16:15 --- Indeed. CCP propagates the constant addresses &spinlock and &spinlock[1] to the deref sides which loses the volatile qualifier from the access. Disabling that leads to VRP which does the same. Then DOM which does the same. Then store-ccp which is not disabled by -fno-tree-ccp. So, finally, -O2 -fno-tree-ccp -fno-tree-vrp -fno-tree-dominator-opts -fno-tree-store-ccp makes it work. Maybe this one is stretching what we want to support... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-10 16:15:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug tree-optimization/32721] CCP removes volatile qualifiers.
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-10 16:19 --- As the decl is volatile as well this is clearly a bogus optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug tree-optimization/32722] New: [4.3 Regression] Bootstrap failure with -fno-tree-store-copy-prop
Bootstrap fails compiling tree-ssa-structalias.c with a verify_ssa failure: ../../gcc/gcc/tree-ssa-structalias.c: In function 'build_pred_graph': ../../gcc/gcc/tree-ssa-structalias.c:940: error: definition in block 5 follows the use for SSA_NAME: D.36231_29 in statement: D.36230_26 = D.36231_29; ../../gcc/gcc/tree-ssa-structalias.c:940: 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. this doesn't reduce easily but with --param ggc-min-expand=0 --param ggc-min-heapsize=0 so this is likely GC related. See also PR32636 for a similar issue that got latent again. Testcase is still reducing. -- Summary: [4.3 Regression] Bootstrap failure with -fno-tree-store- copy-prop Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, GC 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=32722
[Bug tree-optimization/32722] [4.3 Regression] Bootstrap failure with -fno-tree-store-copy-prop
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-10 16:36 --- The verify_ssa failure is after PRE. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32722
[Bug c++/32716] [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem.
--- Comment #6 from dberlin at gcc dot gnu dot org 2007-07-10 16:59 --- Subject: Re: [4.2/4.3 Regression] Wrong code generation. Alias and C++ virtual bases problem. On 10 Jul 2007 15:32:51 -, rguenther at suse dot de <[EMAIL PROTECTED]> wrote: > > > --- Comment #5 from rguenther at suse dot de 2007-07-10 15:32 --- > Subject: Re: [4.2/4.3 Regression] Wrong code generation. > Alias and C++ virtual bases problem. > > On Tue, 10 Jul 2007, ramana dot radhakrishnan at celunite dot com wrote: > > > --- Comment #4 from ramana dot radhakrishnan at celunite dot com > > 2007-07-10 15:14 --- > > (In reply to comment #3) > > > Fixed with "take3.diff". > > > > > > > Did you forget to attach take3.diff ? > > No, that was a hint to Danny ;) You never told me whether omnetpp/xalanbmc were still failing with it or not :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32716
[Bug libgcj/32651] [4.2/4.3 regression] libjava fails to build on IRIX 6.5
--- Comment #2 from ro at gcc dot gnu dot org 2007-07-10 17:00 --- Mine. -- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-10 17:00:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32651
[Bug libgcj/32651] [4.2/4.3 regression] libjava fails to build on IRIX 6.5
--- Comment #3 from ro at gcc dot gnu dot org 2007-07-10 17:01 --- Subject: Bug 32651 Author: ro Date: Tue Jul 10 17:01:47 2007 New Revision: 126515 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126515 Log: PR libgcj/32651 * configure.host (mips-sgi-irix6*): Set sysdeps_dir. Disable interpreter. Modified: trunk/libjava/ChangeLog trunk/libjava/configure.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32651
[Bug libgcj/32651] [4.2/4.3 regression] libjava fails to build on IRIX 6.5
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-10 17:03 --- Subject: Bug 32651 Author: ro Date: Tue Jul 10 17:02:57 2007 New Revision: 126516 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126516 Log: PR libgcj/32651 * configure.host (mips-sgi-irix6*): Set sysdeps_dir. Disable interpreter. Modified: branches/gcc-4_2-branch/libjava/ChangeLog branches/gcc-4_2-branch/libjava/configure.host -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32651
[Bug tree-optimization/32720] No coalesce ssa_names
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-07-10 17:03 --- Even though this is a tree-opt bug, the Fortran front-end implementation of select of a string could be improved not to use indirect gotos. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32720
[Bug libgcj/32651] [4.2/4.3 regression] libjava fails to build on IRIX 6.5
--- Comment #5 from ro at gcc dot gnu dot org 2007-07-10 17:04 --- Fixed for 4.2.1, 4.3. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32651
[Bug java/32712] error trying to exec 'ecj1' - also - SuppressWarnings cannot be resolved to a type
--- Comment #3 from rob1weld at aol dot com 2007-07-10 17:09 --- I was told in my other bug report to file my 'java problem' seperatly - so I did. gcc-4.2 file.java gcc: error trying to exec 'ecj1': execvp: No such file or directory How is it "not a bug" for GCC 4.3 to attempt to execute a non-existant file? If the gcc driver should run "gcj" or "ejc" then be my guest but what is the point of attempting to execuate a non-existant file ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32712
[Bug tree-optimization/32722] [4.3 Regression] Bootstrap failure with -fno-tree-store-copy-prop
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32722
[Bug tree-optimization/32635] [4.3 Regression] gfortran - internal compiler error: verify_ssa failed
--- Comment #1 from dir at lanl dot gov 2007-07-10 17:23 --- Also fails on suse linux and intel macintosh. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32635
[Bug libgcj/28190] [4.2/4.3 Regression] libjava bootstrap failure on IRIX 6.5: stdint.h misdetection
--- Comment #5 from ro at gcc dot gnu dot org 2007-07-10 17:55 --- Subject: Bug 28190 Author: ro Date: Tue Jul 10 17:55:20 2007 New Revision: 126518 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126518 Log: PR libgcj/28190 * inclhack.def (irix_stdint_c99): New fix. * fixincl.x: Regenerate. * tests/base/stdint.h: New test. Added: branches/gcc-4_2-branch/fixincludes/tests/base/stdint.h Modified: branches/gcc-4_2-branch/fixincludes/ChangeLog branches/gcc-4_2-branch/fixincludes/fixincl.x branches/gcc-4_2-branch/fixincludes/inclhack.def -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28190
[Bug c++/31743] [4.1/4.2 regression] ICE with invalid use of new
--- Comment #13 from mmitchel at gcc dot gnu dot org 2007-07-10 17:57 --- OK, I've removed the executable property. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.1/4.2/4.3 regression] ICE|[4.1/4.2 regression] ICE |with invalid use of new |with invalid use of new http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31743
[Bug libgcj/28190] [4.2/4.3 Regression] libjava bootstrap failure on IRIX 6.5: stdint.h misdetection
--- Comment #6 from ro at gcc dot gnu dot org 2007-07-10 17:57 --- Fixed for 4.2.1, 4.3. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28190
[Bug target/32538] All libgomp tests fail to link on IRIX 6: copysignl undefined
--- Comment #4 from ro at gcc dot gnu dot org 2007-07-10 18:02 --- Subject: Bug 32538 Author: ro Date: Tue Jul 10 18:02:30 2007 New Revision: 126520 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126520 Log: PR target/32538 * config/mips/iris6.h (LIBGCC_SPEC): Add libm. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/iris6.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32538
[Bug target/32538] All libgomp tests fail to link on IRIX 6: copysignl undefined
--- Comment #5 from ro at gcc dot gnu dot org 2007-07-10 18:03 --- Subject: Bug 32538 Author: ro Date: Tue Jul 10 18:03:28 2007 New Revision: 126521 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126521 Log: PR target/32538 * config/mips/iris6.h (LIBGCC_SPEC): Add libm. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/mips/iris6.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32538
[Bug target/32538] All libgomp tests fail to link on IRIX 6: copysignl undefined
--- Comment #6 from ro at gcc dot gnu dot org 2007-07-10 18:04 --- Fixed for 4.2.1, 4.3. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32538
[Bug tree-optimization/32723] New: [4.2 Regression] memory hog in solve_graph
with the attached test case, solve_graph makes memory consumptation goes higher than 1GB, whereas it compiles fine with <50MB on gcc 4.1 and 4.3 the test case was created from tomoe-dict-unihan.c (https://sourceforge.jp/projects/tomoe/) which uses 11MB .h data file -- Summary: [4.2 Regression] memory hog in solve_graph Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pixel at mandriva dot com GCC build triplet: i586-mandriva-linux-gnu GCC host triplet: i586-mandriva-linux-gnu GCC target triplet: i586-mandriva-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #1 from pixel at mandriva dot com 2007-07-10 18:16 --- Created an attachment (id=13882) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13882&action=view) memory hog test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug fortran/32724] New: ICE on statement function in specfication part of module
$> cat ice.f90 MODULE stmt f(x) = x**2! invalid END MODULE PROGRAM xx USE stmt print *, f(3) END PROGRAM $> gfortran-svn -g -Wall stmt.f90 stmt.f90:7.13: print *, f(3) 1 Error: Type/rank mismatch in argument 'x' at (1) stmt.f90:7.10: print *, f(3) 1 stmt.f90:0: internal compiler error: Segmentation fault Backtrace: Program received signal SIGSEGV, Segmentation fault. error_string (p=0x0) at ../../../gcc/gcc/fortran/error.c:110 110 while (*p) (gdb) bt #0 error_string (p=0x0) at ../../../gcc/gcc/fortran/error.c:110 #1 0x08063909 in error_print (type=0x8722662 "Error:", format0=0x872f870 "Function '%s' at %L cannot call itself, as it is not RECURSIVE", argp=) at ../../../gcc/gcc/fortran/error.c:565 #2 0x08063ed4 in gfc_error (nocmsgid=0x872f870 "Function '%s' at %L cannot call itself, as it is not RECURSIVE") at ../../../gcc/gcc/fortran/error.c:759 #3 0x0809be96 in gfc_resolve_expr (e=0x8934a88) at ../../../gcc/gcc/fortran/resolve.c:2074 #4 0x0809f326 in resolve_code (code=0x8934af8, ns=0x8934200) at ../../../gcc/gcc/fortran/resolve.c:5711 #5 0x080a290a in gfc_resolve_blocks (b=0x8934b38, ns=0x8934200) at ../../../gcc/gcc/fortran/resolve.c:5644 #6 0x0809f30c in resolve_code (code=0x8934bb8, ns=0x8934200) at ../../../gcc/gcc/fortran/resolve.c:5703 #7 0x080a0e1c in resolve_codes (ns=0x8934200) at ../../../gcc/gcc/fortran/resolve.c:8399 #8 0x080a0e53 in gfc_resolve (ns=0x8934200) at ../../../gcc/gcc/fortran/resolve.c:8418 #9 0x080932d0 in gfc_parse_file () at ../../../gcc/gcc/fortran/parse.c:3263 #10 0x080b879d in gfc_be_parse_file (set_yydebug=0) at ../../../gcc/gcc/fortran/f95-lang.c:301 #11 0x0832a5b8 in toplev_main (argc=2, argv=0xbff8ad44) at ../../../gcc/gcc/toplev.c:1051 #12 0x080ffdcf in main (argc=1869771333, argv=0x46203a72) at ../../../gcc/gcc/main.c:35 $> gfortran-svn -v gcc version 4.3.0 20070710 (experimental) -- Summary: ICE on statement function in specfication part of module Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32724
[Bug fortran/30814] non-conforming array sizes in PACK should raise an error
--- Comment #1 from tkoenig at gcc dot gnu dot org 2007-07-10 19:16 --- A nice m4 project :-) I'll do this. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tkoenig at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-02-16 16:08:46 |2007-07-10 19:16:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30814
[Bug c++/23472] [hammer] __attribute__((constructor)) called twice with -funit-at-a-time
--- Comment #3 from pcarlini at suse dot de 2007-07-10 19:25 --- Hi Michael, I'm wondering if we still care about this PR... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23472
[Bug target/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #5 from uros at gcc dot gnu dot org 2007-07-10 19:27 --- Subject: Bug 32708 Author: uros Date: Tue Jul 10 19:26:58 2007 New Revision: 126523 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126523 Log: PR target/32708 * config/i386/sse.md (vec_concatv2di): Disable for TARGET_64BIT. (*vec_concatv2di_rex): New insn pattern. testsuite/ChangeLog: PR target/32708 * gcc.target/i386/pr32708-1.c: New test. * gcc.target/i386/pr32708-2.c: Ditto. * gcc.target/i386/pr32708-3.c: Ditto. Added: trunk/gcc/testsuite/gcc.target/i386/pr32708-1.c trunk/gcc/testsuite/gcc.target/i386/pr32708-2.c trunk/gcc/testsuite/gcc.target/i386/pr32708-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug target/32708] _mm_cvtsi64x_si128() and _mm_cvtsi128_si64x() inefficient
--- Comment #6 from ubizjak at gmail dot com 2007-07-10 19:38 --- (In reply to comment #0) > long2vector() should use a simple MOVQ instruction the way int2vector() uses > MOVD. It appears that the reason for the stack access is that the original > code > used a reg64->mem->mm->xmm path, which the optimizer partly noticed; > gcc-4.3-20070617 leaves the full path in place. A note to the reporter: unless a noticeable performance regression is found, missed-optimization bugs should be reported vs. mainline gcc. Usually, mainline sources implement new infrastructure to support new optimizations, and this infrastructure is rarely backported to release branches. Sometimes requested optimization is already implemented in the mainline, again with little or no chances of being backported. If you have a particular (complex) application, you are most welcomed to try to compile it with latest gcc sources. This way, compile-time, runtime and performance issues can be fixed early in gcc development cycle, benefiting your application, as well as gcc development. Otherwise, the patch is committed to mainline. Not a regression on branches. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32708
[Bug tree-optimization/32721] CCP removes volatile qualifiers.
--- Comment #3 from ramana dot radhakrishnan at celunite dot com 2007-07-10 20:14 --- (In reply to comment #2) > As the decl is volatile as well this is clearly a bogus optimization. > Putting a breakpoint on evaluate_stmt in tree-ssa-ccp.c shows that stmt_ann of the stmt does not have has_volatile_ops set to true. (gdb) p stmt (gdb) pt sizes-gimplified unsigned SI size unit size align 32 symtab 0 alias set -1 canonical type 0xb7d44bd0> visited var def_stmt version 1> arg 1 constant invariant arg 0 arg 0 arg 1 >> try.c:5> (gdb) (gdb) p *(stmt->base->ann) $17 = {common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0}, vdecl = { common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0}, out_of_ssa_tag = 0, base_var_processed = 0, used = 0, need_phi_state = NEED_PHI_STATE_NO, in_vuse_list = 1, in_vdef_list = 0, is_heapvar = 0, call_clobbered = 1, noalias_state = NO_ALIAS_GLOBAL, mpt = 0xb7cb6804, symbol_mem_tag = 0x0, partition = 0, base_index = 0, current_def = 0x0, subvars = 0x0, escape_mask = 3084210192}, fdecl = { common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0}, reference_vars_info = 0xb7eed528}, stmt = {common = {type = STMT_ANN, aux = 0x0, value_handle = 0x0}, bb = 0xb7eed528, operands = { def_ops = 0xb7cb6804, use_ops = 0x0, vdef_ops = 0x0, vuse_ops = 0x0, stores = 0x0, loads = 0x0}, addresses_taken = 0xb7d55010, uid = 0, references_memory = 0, modified = 0, has_volatile_ops = 0, makes_clobbering_call = 0}} Shouldn't has_volatile_ops get set to true in this case because the stmt essentially has one volatile operand here ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32721
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-10 20:22 --- What exact version of 4.2.1 are you using? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug fortran/32703] ICE with [trim(character_variable)]
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-10 20:54 --- My coming character patch fixes this. I'll take it. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-07-09 18:32:53 |2007-07-10 20:54:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32703
[Bug fortran/32179] Ensure that ss->string_length is always set [TODO item]
--- Comment #2 from pault at gcc dot gnu dot org 2007-07-10 20:57 --- Since i have taken on this stuff - actually the kludge has now gone in the latest incarnation of the character patch - one more to go! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2007-06-13 20:52:58 |2007-07-10 20:57:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32179
[Bug middle-end/29749] [4.0/4.1/4.2/4.3 regression] Missing byte swap optimizations
--- Comment #3 from dougkwan at google dot com 2007-07-10 22:18 --- I'm working on a patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29749
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #3 from pixel at mandriva dot com 2007-07-10 22:21 --- tested with rc1 and svn -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug middle-end/32725] New: Unnecessary reg-reg moves
Compiling the following code // g++-4.3-070710 -O3 -msse3 -mtune=core2 -S #include typedef unsigned long long u64; void foo(int* dest, unsigned short* src, long* indexes, __m128i _m1, __m128i _e, __m128i _m2) { // required by the API, and makes the bug worse u64 e = _mm_cvtsi128_si64x(_e); u64 m1 =_mm_cvtsi128_si64x(_m1); u64 m2 = _mm_cvtsi128_si64x(_m2); for(long i=0; i < 3; i++) { u64 data = src[indexes[i]]; __uint128_t result = (__uint128_t) (data & m1) * e; dest[i] = (result >> 64) & m2; } } Produces redundant reg-reg moves _Z3fooPiPtPlU8__vectorxS2_S2_: .LFB527: pushq %rbx .LCFI0: movq%rdx, %r11 movd%xmm1, %r10 movd%xmm0, %r8 movd%xmm2, %r9 movq(%rdx), %rax movzwl (%rsi,%rax,2), %eax movq%rax, %rbx << 1 andq%r8, %rbx movq%rbx, %rax << 2 mulq%r10 movl%r9d, %eax << 3 andl%edx, %eax movl%eax, (%rdi) movq8(%r11), %rax movzwl (%rsi,%rax,2), %eax movq%rax, %rbx << 1 andq%r8, %rbx movq%rbx, %rax << 2 popq%rbx mulq%r10 movl%r9d, %eax << 3 andl%edx, %eax movl%eax, 4(%rdi) movq16(%r11), %rax movzwl (%rsi,%rax,2), %eax andq%rax, %r8 << Almost what 1 should be movq%r8, %rax << 2 mulq%r10 andl%edx, %r9d << Essentially what 3 should be movl%r9d, 8(%rdi) ret The output of a single iteration should look something like this (33% fewer instructions): movq8(%r11), %rax movzwl (%rsi,%rax,2), %eax andq%r8, %rax mulq%r10 andl%r9d, %edx movl%edx, 4(%rdi) Methinks cases (2) and (3) are related to bug 15158 and bug 21202, but that case (1) is something else. There's also that odd choice to use %rbp, even though there are plenty of call-clobber regs to use instead... -- Summary: Unnecessary reg-reg moves Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: scovich at gmail dot com GCC target triplet: x86_64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32725
[Bug fortran/32594] substring simplification leads to ICE
--- Comment #5 from fxcoudert at gcc dot gnu dot org 2007-07-10 22:44 --- It's a larger problem. The patch above avoids this ICE, but we have another one when using substring references of type string(:). The following code, with patched compiler, yields the other ICE: character(*), parameter :: chrs = '-+.0123456789eEdD' character(*), parameter :: expr = '-+.0123456789eEdD' print *, index(chrs(:), expr) print *, index(chrs(14:), expr) print *, index(chrs(:12), expr) print *, index(chrs, expr(:)) print *, index(chrs, expr(1:)) print *, index(chrs, expr(:1)) contains function foo(expr) character(*), intent(in) :: expr character(*), parameter :: chrs = '-+.0123456789eEdD' integer :: foo foo = index(chrs(:), expr) foo = index(chrs(14:), expr) foo = index(chrs(:12), expr) foo = index(chrs, expr(:)) foo = index(chrs, expr(1:)) foo = index(chrs, expr(:1)) end function foo end This is because expr->ref is NULL in that later case (there's a comment somewhere to that effect), which is not dealt with later during translation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32594
[Bug fortran/32357] MVBITS gives wrong-code on big-endian with -fdefault-integer-8
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2007-07-10 22:46 --- (In reply to comment #6) > Sorry, I *do* see the problem on powerpc. > > (sid)832:[EMAIL PROTECTED]: ~/src] gfortran -fdefault-integer-8 t.f90 ; > ./a.out > i = 0 > (sid)833:[EMAIL PROTECTED]: ~/src] gfortran t.f90 ; ./a.out > i = 1 Could you (or some other interested party) compile t.f90 with -fdump-tree-original, both with and without -fdefault-integer-8, and post the t.f90.003t.original file produced in each case? This would help us understand where the problem is, without having access to a powerpc machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32357
[Bug bootstrap/32617] explow.c references DECL_ALIGN of a FUNCTION_DECL
--- Comment #2 from geoffk at gcc dot gnu dot org 2007-07-10 23:09 --- Subject: Bug 32617 Author: geoffk Date: Tue Jul 10 23:08:52 2007 New Revision: 126529 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126529 Log: 2007-07-09 Geoffrey Keating <[EMAIL PROTECTED]> PR 32617 * c-common.c (c_alignof_expr): Look at DECL_ALIGN of FUNCTION_DECLs. (handle_aligned_attribute): Allow use on FUNCTION_DECLs. * varasm.c (assemble_start_function): Honor DECL_ALIGN for FUNCTION_DECLs. Don't use align_functions_log if DECL_USER_ALIGN. * print-tree.c (print_node): Print DECL_ALIGN and DECL_USER_ALIGN even for FUNCTION_DECLs. * c-decl.c (merge_decls): Propagate DECL_ALIGN even for FUNCTION_DECLs. * tree.h (DECL_ALIGN): Update for new location of 'align'. (DECL_FUNCTION_CODE): Update for new location and name of 'function_code'. (DECL_OFFSET_ALIGN): Update for new location of 'off_align'. (struct tree_decl_common): Move 'align' and 'off_align' out of union, ensure they're still on a 32-bit boundary. Remove other fields in union 'u1'. (struct tree_function_decl): Add field 'function_code' replacing 'u1.f' in tree_decl_common. * tree.c (build_decl_stat): Set initial value of DECL_ALIGN. * doc/extend.texi (Function Attributes): Add 'aligned' attribute. (Variable Attributes): Cross-reference 'aligned' attribute to Function Attributes. * flags.h (force_align_functions_log): Delete. * toplev.c (force_align_functions_log): Delete. Index: gcc/testsuite/ChangeLog 2007-07-09 Geoffrey Keating <[EMAIL PROTECTED]> PR 32617 * gcc.c-torture/execute/align-3.c: New. Index: gcc/java/ChangeLog 2007-07-09 Geoffrey Keating <[EMAIL PROTECTED]> PR 32617 * lang.c (java_init): Remove setting of force_align_functions_log. * class.c (add_method_1): Set DECL_ALIGN of non-static method to cope with ptrmemfunc_vbit_in_pfn. Index: gcc/cp/ChangeLog 2007-07-09 Geoffrey Keating <[EMAIL PROTECTED]> PR 32617 * decl.c (cxx_init_decl_processing): Don't set force_align_functions_log. (grokfndecl): Honour ptrmemfunc_vbit_in_pfn. * typeck.c (cxx_alignof_expr): When alignof is used on a plain FUNCTION_DECL, return its alignment. Added: trunk/gcc/testsuite/gcc.c-torture/execute/align-3.c Modified: trunk/gcc/ChangeLog trunk/gcc/c-common.c trunk/gcc/c-decl.c trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/doc/extend.texi trunk/gcc/flags.h trunk/gcc/java/ChangeLog trunk/gcc/java/class.c trunk/gcc/java/lang.c trunk/gcc/print-tree.c trunk/gcc/testsuite/ChangeLog trunk/gcc/toplev.c trunk/gcc/tree.c trunk/gcc/tree.h trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32617
[Bug fortran/31608] wrong types in character array/scalar binop
--- Comment #13 from pinskia at gcc dot gnu dot org 2007-07-10 23:36 --- I think this was fixed with http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01471.html aka PR32140. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31608
[Bug bootstrap/32726] New: ICE when compiling emit-rtl.c
r126521 on ppc64-linux bootstrap fails with /home/eres/test_again/build/./gcc/xgcc -B/home/eres/test_again/build/./gcc/ -B/home/eres/test_again/build/powerpc64-unknown-linux-gnu/bin/ -B/home/eres/test_again/build/powerpc64-unknown-linux-gnu/lib/ -isystem /home/eres/test_again/build/powerpc64-unknown-linux-gnu/include -isystem /home/eres/test_again/build/powerpc64-unknown-linux-gnu/sys-include -g -fkeep-inline-functions -m32 -fPIC -mstrict-align -O2 -O2 -g -O2 -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -mno-minimal-toc -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -mlong-double-128 -I. -I. -I../../.././gcc -I../../../../gcc/libgcc -I../../../../gcc/libgcc/. -I../../../../gcc/libgcc/../gcc -I../../../../gcc/libgcc/../include -I../../../../gcc/libgcc/../libdecnumber/dpd -I../../../../gcc/libgcc/../libdecnumber -I../../../libdecnumber -DHAVE_CC_TLS -o _floatdisf.o -MT _floatdisf.o -MD -MP -MF _floatdisf.dep -DL_floatdisf -c ../../../../gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../../gcc/libgcc/../gcc/libgcc2.c: In function â__floatdisfâ: ../../../../gcc/libgcc/../gcc/libgcc2.c:1530: internal compiler error: in gen_reg_rtx, at emit-rtl.c:785 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make[5]: *** [_floatdisf.o] Error 1 -- Summary: ICE when compiling emit-rtl.c Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: eres at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726
[Bug fortran/32727] New: [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
as discussed in PR 29975, with gcc version 4.3.0 20070710 (experimental) I get: gfortran -c test.f90 test.f90:784.44: USE util,ONLY: sort 1 -- Summary: [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util' Product: gcc Version: 4.3.0 Status: UNCONFIRMED 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=32727
[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
--- Comment #1 from jv244 at cam dot ac dot uk 2007-07-11 05:27 --- Created an attachment (id=13883) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13883&action=view) testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #136 from jv244 at cam dot ac dot uk 2007-07-11 05:48 --- (In reply to comment #135) > new bogus errors compiling all.f90 ... filed as PR 32727 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
--- Comment #2 from jv244 at cam dot ac dot uk 2007-07-11 05:49 --- FYI, all three modules are needed to trigger the bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727
[Bug tree-optimization/32713] [4.3 regression] ICE in copy_reference_ops_from_ref, at tree-ssa-sccvn.c:550
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2007-07-11 06:12 --- Investigating. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-11 06:12:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32713
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #5 from brooks at gcc dot gnu dot org 2007-07-11 06:25 --- Subject: Bug 31823 Author: brooks Date: Wed Jul 11 06:25:47 2007 New Revision: 126538 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126538 Log: Backport from trunk: PR fortran/31823 * intrinsic.texi (CMPLX): Document result kind. (COMPLEX): Add documentation. Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/intrinsic.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/31823] [4.2 regression] COMPLEX not documented
--- Comment #6 from brooks at gcc dot gnu dot org 2007-07-11 06:34 --- Fixed, as per the above commit. -- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31823
[Bug fortran/32727] [4.3 regression] bogus error: Error: Symbol 'sort' referenced at (1) not found in module 'util'
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-11 06:38 --- Working: 2007-07-09-r126478 Failing: 2007-07-10-r126510 I believe it is due to the patch r126509 | pault | 2007-07-10 07:11:00 +0200 (Di, 10 Jul 2007) | 28 lines PR 32634 [...] * module.c (write_generic): Write the local name of the interface. but I might be wrong and it is one of: r126486 | dfranke | 2007-07-09 16:56:49 +0200 (Mon, 09 Jul 2007) | 14 lines r126493 | kargl | 2007-07-09 21:41:37 +0200 (Mon, 09 Jul 2007) | 6 lines r126496 | fxcoudert | 2007-07-10 00:00:52 +0200 (Tue, 10 Jul 2007) | 6 lines The error message is: USE util,ONLY: sort 1 Error: Symbol 'sort' referenced at (1) not found in module 'util' Reduced test case: MODULE kinds INTEGER, PARAMETER :: dp = SELECTED_REAL_KIND ( 14, 200 ) END MODULE kinds MODULE util USE kinds, ONLY: dp INTERFACE sort MODULE PROCEDURE sort2 END INTERFACE CONTAINS SUBROUTINE sort2 ( ) END SUBROUTINE sort2 END MODULE util MODULE graphcon USE util,ONLY: sort END MODULE graphcon -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32727
[Bug bootstrap/32726] ICE when compiling emit-rtl.c
--- Comment #1 from dorit at gcc dot gnu dot org 2007-07-11 06:43 --- (In reply to comment #0) > r126521 on ppc64-linux > bootstrap fails with r126512 passed bootstrap on powerpc64, so I guess the problem was introduced somewhere in between -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726
[Bug bootstrap/32726] ICE when compiling emit-rtl.c
--- Comment #2 from eres at il dot ibm dot com 2007-07-11 06:51 --- The problem seems to be fixed. See - http://gcc.gnu.org/ml/gcc/2007-07/msg00352.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32726