[Bug fortran/35824] Overloading problems with derived type with allocatable array
--- Comment #5 from pault at gcc dot gnu dot org 2008-11-30 08:04 --- This is fixed for trunk and 4.3. I have prepared a testcase that will be committed tonight. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35824
[Bug bootstrap/38314] multilib bootstrap broken for x86_64-apple-darwin10
--- Comment #17 from andreast at gcc dot gnu dot org 2008-11-30 08:22 --- http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02671.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38314
[Bug fortran/35824] Overloading problems with derived type with allocatable array
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-30 08:50 --- Subject: Bug 35824 Author: pault Date: Sun Nov 30 08:48:51 2008 New Revision: 142292 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142292 Log: 2008-11-30 Paul Thomas [EMAIL PROTECTED] PR fortran/35824 * gfortran.dg/alloc_comp_assign_8.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/alloc_comp_assign_8.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35824
[Bug fortran/37469] Invalid GMP usage on gfortran.dg/parameter_array_init_3.f90
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:04 --- Visible on SPARC 64-bit. IMHO this is serious and should be fixed for 4.4.0. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC||ebotcazou at gcc dot gnu dot ||org Severity|normal |major Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-30 09:04:20 date|| Summary|Invalid GMP usage |Invalid GMP usage on ||gfortran.dg/parameter_array_ ||init_3.f90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37469
[Bug c/22020] poor error message for invalid cast in constant initializer
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:21 --- A little better with the current 4.4.0 compiler: t.c:3: warning: cast from pointer to integer of different size t.c:3: error: initializer element is not constant but not as good as with the Sun compiler. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2005-11-08 03:29:13 |2008-11-30 09:21:18 date|| Summary|Poor error message for |poor error message for |invalid cast in constant|invalid cast in constant |initializer |initializer http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22020
[Bug target/18580] vectorizer failures (max, unaligned)
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Priority|P2 |P3 Summary|Vectorizer failures (max, |vectorizer failures (max, |unaligned) |unaligned) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18580
[Bug ada/37799] SEGV compiling ada/ada.ads in stage2
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:27 --- Works for me on Solaris 10 as well. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37799
[Bug bootstrap/37279] bootstrap on sparc fails on genattrtab
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:30 --- *** This bug has been marked as a duplicate of 37344 *** -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37279
[Bug target/37344] [4.4 Regression] sparc bootstrap fails with Bus error in libgcc2.c
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:30 --- *** Bug 37279 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37344
[Bug testsuite/34253] Lots of failures in gcc.dg/vect
--- Comment #9 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:33 --- Presumably spurious. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34253
[Bug fortran/37469] invalid GMP usage on gfortran.dg/parameter_array_init_3.f90
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:37 --- Visible on SPARC 64-bit. And IA-64, s390x, x86_64-darwin, etc. So almost all 64-bit platforms. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Summary|Invalid GMP usage on|invalid GMP usage on |gfortran.dg/parameter_array_|gfortran.dg/parameter_array_ |init_3.f90 |init_3.f90 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37469
[Bug target/30280] SIGSEGV on operator==(valarraybool, bool)
--- Comment #15 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:43 --- Not reproducible. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30280
[Bug other/31536] sparc64 build fails with `unknown endianness' error.
--- Comment #8 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:45 --- Known to work. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31536
[Bug ada/34118] Please enable stack checking (-fstack-check) by default
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-30 09:46:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34118
[Bug target/33743] unwinding through signal frame
-- 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|NEW |ASSIGNED Last reconfirmed|2007-10-12 08:25:13 |2008-11-30 09:50:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33743
[Bug target/33331] FreeBSD __sparc64__ define no longer exists
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2008-11-30 09:54 --- What's the status of this patch exactly? -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=1
[Bug ada/38325] New: Long_Long_Float'Image returns a wrong value in some cases
The test case below shows a bug in the Long_Long_Float'Image function on FreeBSD 7: File test_float.adb; with Ada.Text_IO; use Ada.Text_IO; procedure Test_Float is L : Long_Long_Float := 1.000; LL : Long_Long_Float := 10.000; begin Put_Line (Long_Long_Float'Image (L/LL)); end Test_Float; Expected execution result: = 10:25 ~/dev% ./test_float 1.0E-01 Actual behavior with GNAT-GCC 4.3.2: 10:26 ~/dev% ./test_float 1.6E-01 (Note the trailing 6 after the zero's) GNAT version: = 10:20 ~/dev% gnatls -v GNATLS 4.3.2 Copyright (C) 1997-2007, Free Software Foundation, Inc. Source Search Path: Current_Directory /opt/packages/gnat-4.3.2/lib/gcc/i686-portbld-freebsd7/4.3.2/adainclude/ Object Search Path: Current_Directory /opt/packages/gnat-4.3.2/lib/gcc/i686-portbld-freebsd7/4.3.2/adalib/ Project Search Path: Current_Directory /opt/packages/gnat-4.3.2/lib/gnat/ GCC version: 10:20 ~/dev% gcc -v Using built-in specs. Target: i686-portbld-freebsd7 Configured with: ../gcc-4.3.2/configure --prefix=/[snip]/gcc_4.3.2_install --enable-languages=c,c++,ada --with-gmp=/[snip]/gmp_inst --with-mpfr=/[snip]/mpfr_inst --disable-nls --host=i686-portbld-freebsd7 --target=i686-portbld-freebsd7 --build=i686-portbld-freebsd7 --enable-checking=release --enable-threads=posix Thread model: posix gcc version 4.3.2 (GCC) -- Summary: Long_Long_Float'Image returns a wrong value in some cases Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bechir dot zalila at gmail dot com GCC build triplet: i686-portbld-freebsd7 GCC host triplet: i686-portbld-freebsd7 GCC target triplet: i686-portbld-freebsd7 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38325
[Bug ada/38325] Long_Long_Float'Image returns a wrong value in some cases
--- Comment #2 from bechir dot zalila at gmail dot com 2008-11-30 10:27 --- (In reply to comment #1) 0.1 is not exactly representable in a binary float format. Sure, but in former versions of GNAT-GCC (4.2.X), the expected value (1.0E-01) was displayed. -- bechir dot zalila at gmail dot com changed: What|Removed |Added CC||bechir dot zalila at gmail ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38325
[Bug target/38326] New: [4.3 regression] libjava build failure on ia64-linux-gnu
seen with 4.3 branch 20081115 20081122 /home/packages/gcc/gcj-4.3-4.3.2/build/ia64-linux-gnu/libjava$ /home/packages/gcc/gcj-4.3-4.3.2/build/gcc/gcj -B/home/packages/gcc/gcj-4.3-4.3.2/build/ia64-linux-gnu/libjava/ -B/home/packages/gcc/gcj-4.3-4.3.2/build/gcc/ -funwind-tables -fclasspath= -fbootclasspath=../../../src/libjava/classpath/lib --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -findirect-dispatch -fno-indirect-classes -fsource-filename=/home/packages/gcc/gcj-4.3-4.3.2/build/ia64-linux-gnu/libjava/classpath/tools/all-classes.lst -g -O2 -MT classpath/tools/libgcj_tools_la-tools.lo -MD -MP -MF classpath/tools/.deps/libgcj_tools_la-tools.Tpo -c classpath/tools/tools.zip -fPIC -o classpath/tools/.libs/libgcj_tools_la-tools.o jc1: internal compiler error: in java_parse_file, at java/jcf-parse.c:1957 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcj-4.3/README.Bugs for instructions. -- Summary: [4.3 regression] libjava build failure on ia64-linux-gnu Product: gcc Version: 4.3.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: doko at ubuntu dot com GCC target triplet: ia64-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
[Bug target/38326] [4.3 regression] libjava build failure on ia64-linux-gnu
--- Comment #1 from ebotcazou at gcc dot gnu dot org 2008-11-30 10:52 --- Do you have local changes? This works fine on SuSE: http://gcc.gnu.org/ml/gcc-testresults/2008-11/msg02676.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38326
[Bug ada/38325] Long_Long_Float'Image returns a wrong value in some cases
--- Comment #1 from schwab at suse dot de 2008-11-30 10:10 --- 0.1 is not exactly representable in a binary float format. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38325
[Bug target/38320] missed movd opcode (32bits mm - r/m32).
--- Comment #2 from pluto at agmk dot net 2008-11-30 10:23 --- (In reply to comment #1) You need -mtune=core to generate movd %xmm0, %rax. Gcc 4.4 works. is movd faster only on core2 architecture? and what about 32-bits? $ /opt/gcc44/bin/gcc movd.c -O2 -S -march=core2 -m32 foo:pushl %ebp movl%esp, %ebp subl$16, %esp movq%mm0, -16(%ebp)===? movd mm0, eax movl-16(%ebp), %eax===/ leave ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38320
[Bug middle-end/37843] [4.4 Regression] unaligned stack in main due to tail call optimization
--- Comment #19 from rguenther at suse dot de 2008-11-30 11:19 --- Subject: Re: [4.4 Regression] unaligned stack in main due to tail call optimization On Sat, 29 Nov 2008, hjl dot tools at gmail dot com wrote: --- Comment #18 from hjl dot tools at gmail dot com 2008-11-29 21:10 --- It isn't totally fixed: FAIL: gcc.target/i386/pr37843-3.c scan-assembler-not call[t ]*foo FAIL: gcc.target/i386/pr37843-3.c scan-assembler jmp[t ]*foo I only checked in x86 backend change Which is if course not the right thing to do without XFAILing the new testcases... Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37843
[Bug bootstrap/38302] inefficient use of strlen in for loop
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-30 11:33 --- Also the compiler is able to do this optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38302
[Bug target/38306] [4.4 Regression] 15% slowdown of computational kernel
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-30 11:38 --- Due to the high density of branches in the code this is easily a code layout and/or padding issue. Different architectures have different constraints on their decoders and branch predictors related to branch density. Core introduces other branch limitations for loops that engage the loop stream detector. We do not at all try to properly optimize (or even model) this apart from inserting nops. YMMV with -fschedule-insns. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug target/38320] missed movd opcode (32bits mm - r/m32).
--- Comment #3 from ubizjak at gmail dot com 2008-11-30 11:43 --- (In reply to comment #2) and what about 32-bits? The quote from i386.c: /* ??? This is a lie. We do have moves between mmx/general, and for mmx/sse2. But by saying we need secondary memory we discourage the register allocator from using the mmx registers unless needed. */ if (MMX_CLASS_P (class1) != MMX_CLASS_P (class2)) return true; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38320
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-30 11:56 --- Well, the middle-end thinks that *ap is clobbered by the calls to foo/bar (which it obviously is). The middle-end has no idea that the _vptr member of *ap is special and not clobbered (is it?). We do not have a suitable way to represent this either. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug c++/38297] O2 causes invalid code
--- Comment #13 from rguenth at gcc dot gnu dot org 2008-11-30 11:43
---
Note that the C standard forbids type-punning through a union. Basically it
says
that you may only read from a union member if you have previously written to
it.
It also says that all other bits apart from the ones you have written to
contain
undefined values after the write. So
union { int i; float f; } u;
u.i = 1;
x = u.f;
invokes undefined behavior in C (but not in GNU C because of the language
extension).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug target/38306] [4.4 Regression] 15% slowdown of computational kernel
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 11:48 --- Oh, maybe try -fno-tree-reassoc as well. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug tree-optimization/26307] load PRE creates type mismatches
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-11-30 12:01 --- PRE now does the correct thing: pretmp.13_12 = *entry_ptr_1(D); bb 5: # prephitmp.14_14 = PHI current_automata_list_3(D)(3), pretmp.13_12(4) D.1235_4 = prephitmp.14_14; D.1239_5 = (int *) D.1235_4; with pretmp and the prephitmp being (void *) pointers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26307
[Bug rtl-optimization/33249] [4.1 regression] -O3 and -O2 give wrong results
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-30 12:06 --- Works fine with GCC 4.2.x and later. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED GCC target triplet|sparc-sun-solaris |sparc-sun-solaris2.* Keywords||wrong-code Known to work||3.4.4 4.2.4 4.3.3 4.4.0 Resolution||FIXED Summary|-O3 and -O2 give wrong |[4.1 regression] -O3 and -O2 |results with gcc 4.1.2 on |give wrong results |solaris sparc | Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33249
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 12:09 --- Note that we also do not CSE OBJ_TYPE_REF trees which seem to be valid gimple in place of the call in GIMPLE_CALLs so they do not get a separate value-number. (not that we would do anything useful with them if they were standalone, testcase for that welcome) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug c++/32344] crash with EH on multiprocessor machines
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-11-30 12:16:09 date|| Summary|Exception handling crash in |crash with EH on |multi-threaded program |multiprocessor machines http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32344
[Bug c++/32344] crash with EH on multiprocessor machines
-- 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|2008-11-30 12:16:09 |2008-11-30 12:24:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32344
[Bug fortran/37254] Reject valid PROCEDURE statement with implicit interface
--- Comment #6 from janus at gcc dot gnu dot org 2008-11-30 12:28 --- I'm not sure the codes in comment #1 and #3 are actually valid, or if gfortran is right to reject them. See also PR33162 comment #9, where Jerry concludes that a similar thing should be rejected (this is proc_decl_8.f90 is the testsuite). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37254
[Bug fortran/35937] Wrong type for charlength of function
--- Comment #10 from pault at gcc dot gnu dot org 2008-11-30 13:13 --- (In reply to comment #9) I might as well take it too:-) Since I cannot reproduce the bug, even at -m32, I am unassigning myself. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|pault 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=35937
[Bug ada/38327] New: Rejects legal program involving T'Class'Read
with Ada.Streams; package pak1 is type T3 is abstract new Ada.Streams.Root_Stream_Type with null record; type T3_access is access T3; end pak1; with pak1; procedure test is type T1 is tagged null record; type T2 is new T1 with null record; x1: pak1.T3_access; x2: T2; begin T1'Class'Read( x1, x2 ); -- line 10 end; test.adb:10:23: expected type T1 defined at line 4 test.adb:10:23: found type T2 defined at line 5 T1'Class'Read is supposed to dispatch on the tag of x2 because x2 belongs to T1'Class. The compiler should accept this program. -- Summary: Rejects legal program involving T'Class'Read Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38327
[Bug tree-optimization/38328] New: Massive performance regression for jpeg_idct_islow
First of all, I'm using Debian's gcc-snapshot package: gcc version 4.4.0 20081117 (experimental) [trunk revision 141948] (Debian 20081117-1) Let me know if I should try to rebuild with another GCC version. I tested my image scaler (http://bzr.sesse.net/qscale/) and libjpeg with 4.4 vs. 4.3, and got the following oprofile graph for the same load in both cases. 4.3: samples %app name symbol name 5182 21.8484 libjpeg.so.62.0.0jpeg_idct_islow 5150 21.7135 libjpeg.so.62.0.0decode_mcu 3582 15.1025 qscale vscale 1237 5.2154 libjpeg.so.62.0.0jpeg_fill_bit_buffer 592 2.4960 qscale hscale 4.4: samples %app name symbol name 7054 31.9056 qscale jpeg_idct_islow 4401 19.9059 qscale decode_mcu 3584 16.2106 qscale vscale 1352 6.1152 qscale jpeg_fill_bit_buffer 606 2.7410 qscale hscale Note that decode_mcu is 17% faster (probably due to better register allocation), but jpeg_idct_islow is 36% slower! jpeg_fill_bit_buffer is also a tiny bit slower, but that's not as critical. (The overall effect is that the JPEG decoding as a whole runs slower.) I have not looked at the generated code, but it's definitely not good. FWIW, it's repeatable between runs -- the sample counts change very little (1-2%, perhaps). -- Summary: Massive performance regression for jpeg_idct_islow Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sgunderson at bigfoot dot com GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug ada/38329] New: Illegal program not detected, private with in a generic package
package pak1 is end pak1; package pak1.pak2 is x1: integer; end pak1.pak2; private with pak1.pak2; generic package pak1.pak3 is x2 : integer := pak1.pak2.x1; -- ERROR: pak2 is not visible x3 : integer := pak2.x1;-- ERROR: pak2 is not visible end pak1.pak3; In Pak1.Pak3, Pak2 should be visible only in the private part, therefore invisible in the public part. Thus the two declarations (x2 and x3) are illegal. -- Summary: Illegal program not detected, private with in a generic package Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38329
[Bug ada/38330] New: Illegal program not detected, RM 4.3.1(16/2)
generic type T1 is tagged private; package pak1 is type T2 is new T1 with record i,j: integer; end record; x1: T2 := T2'(2,3);-- ERROR: x2: T2 := T2'(T1 with 2,3);-- OK end pak1; The declaration of x1 is illegal because the record_aggregate does not include all components of x1, violating 4.3.1(16/2). In this particular case, since the components inherited from T1 are unknown, the only legal kind of aggregate is a record_extension_aggregate, as done for x2. The compiler accepts this illegal program. -- Summary: Illegal program not detected, RM 4.3.1(16/2) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38330
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #1 from hjl dot tools at gmail dot com 2008-11-30 15:00 --- Can you try -fno-ira to see if it fixes the problem? -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #2 from sgunderson at bigfoot dot com 2008-11-30 15:06 --- OK, I looked at the source. The issue here seems to be that 4.4 likes to compile this: z3 = ((z3) * (- ((INT32) 16069))); into this: 10 0.0403 : 805cc87: lea(%ecx,%ecx,4),%ebx : 805cc8a: lea(%ebx,%ebx,4),%ebx 20 0.0805 : 805cc8d: lea(%ebx,%ebx,4),%ebx 7 0.0282 : 805cc90: lea(%ecx,%ebx,2),%ebx 3 0.0121 : 805cc93: shl$0x4,%ebx 38 0.1530 : 805cc96: add%ecx,%ebx 8 0.0322 : 805cc98: lea(%ecx,%ebx,4),%esi 4.3 uses imul here, which is a lot faster. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug ada/38331] New: Illegal program not detected, = not predefined for class-wide types, ARM 4.5.2(6) and AI05-71
generic type Item () is private; with function = (L, R : Item) return Boolean is ; package pak1 is end pak1; with pak1; package pak2 is type T is tagged null record; package new_pak1a is new pak1 (Item = T'Class);--OK by AI05-71 package new_pak1b is new pak1 (Item = T'Class, = = =); --ERROR: package new_pak1c is new pak1 (Item = T'Class, = = pak2.=); --ERROR: end pak2; The compiler accepts this program; it should reject new_pak1b and new_pak1c because function = (L, R : T'Class) does not exist. The equality operator is defined only for specific type T that is not limited, and not an anonymous access type (ARM 4.5.2(6)); class-wide types are not specific per ARM 3.9(3). The reason why new_pak1a is legal is because of the special rule in AI05-71 which only applies when _not_ specifying an actual for the generic formal =. -- Summary: Illegal program not detected, = not predefined for class-wide types, ARM 4.5.2(6) and AI05-71 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38331
[Bug ada/38331] Illegal program not detected, = not predefined for class-wide types, ARM 4.5.2(6) and AI05-71
--- Comment #1 from ludovic at ludovic-brenta dot org 2008-11-30 15:16 --- *** This bug has been marked as a duplicate of 16094 *** -- ludovic at ludovic-brenta dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38331
[Bug ada/16094] Illegal program not detected, RM 3.4.1(5)
--- Comment #2 from ludovic at ludovic-brenta dot org 2008-11-30 15:16 --- *** Bug 38331 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16094
[Bug c++/20423] Warning -Woverloaded-virtual triggers to often
--- Comment #7 from Woebbeking at web dot de 2008-11-30 15:36 --- Any progress on this? This warning could be really useful if only 1) would be handled. In its current state I can't use it as I get too many false positives :-( -- Woebbeking at web dot de changed: What|Removed |Added CC||Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20423
[Bug c++/38297] O2 causes invalid code
--- Comment #14 from joseph at codesourcery dot com 2008-11-30 15:37
---
Subject: Re: O2 causes invalid code
On Sun, 30 Nov 2008, rguenth at gcc dot gnu dot org wrote:
Note that the C standard forbids type-punning through a union.
Basically it says that you may only read from a union member if you have
previously written to it. It also says that all other bits apart from
the ones you have written to contain undefined values after the write.
So
union { int i; float f; } u;
u.i = 1;
x = u.f;
invokes undefined behavior in C (but not in GNU C because of the language
extension).
Note that C99 TC3 adds a footnote: *) If the member used to access the
contents of a union object is not the same as the member last used to
store a value in the object, the appropriate part of the object
representation of the value is reinterpreted as an object representation
in the new type as described in 6.2.6 (a process sometimes called type
punning). This might be a trap representation.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38297
[Bug ada/38332] New: Program fails to raise Constraint_Error as mandated by ARM 4.7(4)
with Text_io; use Text_io; procedure test1 is type Root (K : boolean) is tagged null record; type Root_Access is access Root'Class; type Child is new Root (K = True) with null record; Var : Root_Access; begin begin Var := new Child'(K = False); put_line(FAILED Boolean'Image(Var.K)); exception when Constraint_Error = Put_line(PASSED); end; end; Per ARM 3.7(26), type Root is unconstrained because it has a known_discriminant_part. Per 3.4(6), Child is unconstrained because its parent is unconstrained. However, its parent_subtype_indication does specify a constraint. The allocator new Child'(K = False) uses a qualified_expression that violates this constraint; therefore its evaluation should raise Constraint_Error at run time, per 4.7(4). The program should print PASSED but instead prints FAILED FALSE. As a quality of implementation issue, it would be nice if GNAT would warn at compile time of this constraint violation. -- Summary: Program fails to raise Constraint_Error as mandated by ARM 4.7(4) Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38332
[Bug ada/38333] New: Illegal program not detected, ARM 6.1(20): pragma Import illegal for abstract subprograms
package pak1 is type T1 is abstract tagged null record; procedure p1(X : T1) is abstract; pragma Import (Ada, p1);--ERROR: can't complete an abstract subprogram end pak1; B.1(22) says that an Import pragma must be the completion of a declaration, and 6.1(20) says that a completion is not allowed for an abstract subprogram declaration. The compiler accepts this program. -- Summary: Illegal program not detected, ARM 6.1(20): pragma Import illegal for abstract subprograms Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ludovic at ludovic-brenta dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38333
[Bug c++/17920] add __attribute__((reimpl)) as a replacement for the (optional) virtual keyword for reimplementations of virtual functions
--- Comment #10 from Woebbeking at web dot de 2008-11-30 15:46 --- And if you've many overloads of a virtual function and override only one you also get a warning. And in some projects this happens very often :-( So I also support this suggestion! -- Woebbeking at web dot de changed: What|Removed |Added CC||Woebbeking at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17920
[Bug target/38306] [4.4 Regression] 15% slowdown of computational kernel
--- Comment #4 from jv244 at cam dot ac dot uk 2008-11-30 16:17 --- (In reply to comment #2) Due to the high density of branches in the code this is easily a code layout and/or padding issue. Different architectures have different constraints on their decoders and branch predictors related to branch density. Core introduces other branch limitations for loops that engage the loop stream detector. We do not at all try to properly optimize (or even model) this apart from inserting nops. YMMV with -fschedule-insns. I'm not expert enough to understand this, but you have it right. However, it remains a regression (on opteron) 4.4: -O3 -march=native -funroll-loops -ffast-math == 5.064s -O3 -march=native -funroll-loops -ffast-math -fschedule-insns == 4.396 4.3: -O3 -march=native -funroll-loops -ffast-math == 4.376 -O3 -march=native -funroll-loops -ffast-math -fschedule-insns == 3.372 -fno-tree-reassoc has no effect. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 16:23 --- Which tuning are you using? Try enabling -mtune=generic (possibly by default). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug target/38306] [4.4 Regression] 15% slowdown of computational kernel
--- Comment #5 from jv244 at cam dot ac dot uk 2008-11-30 16:26 --- (In reply to comment #4) 4.3: -O3 -march=native -funroll-loops -ffast-math == 4.376 -O3 -march=native -funroll-loops -ffast-math -fschedule-insns == 3.372 strangely: http://gcc.gnu.org/onlinedocs/gcc-4.3.2/gcc/Optimize-Options.html#Optimize-Options suggests -fschedule-insns is enabled by default at -O3 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug middle-end/38283] FAIL: libgomp.fortran/pr25162.f
--- Comment #7 from danglin at gcc dot gnu dot org 2008-11-30 16:37 --- Subject: Bug 38283 Author: danglin Date: Sun Nov 30 16:35:59 2008 New Revision: 142293 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142293 Log: PR middle-end/38283 * varasm.c (emutls_finish): Fix common registration. Modified: trunk/gcc/ChangeLog trunk/gcc/varasm.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38283
[Bug target/38306] [4.4 Regression] 15% slowdown of computational kernel
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-30 16:39 --- Not on all targets though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38306
[Bug middle-end/38283] FAIL: libgomp.fortran/pr25162.f
--- Comment #8 from danglin at gcc dot gnu dot org 2008-11-30 16:42 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38283
[Bug rtl-optimization/38272] [4.4 Regression] Revision 142207 caused libgomp.fortran/threadprivate2.f90
--- Comment #9 from hjl at gcc dot gnu dot org 2008-11-30 16:49 --- Subject: Bug 38272 Author: hjl Date: Sun Nov 30 16:48:00 2008 New Revision: 142294 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142294 Log: 2008-11-30 H.J. Lu [EMAIL PROTECTED] PR rtl-optimization/38272 * reload1.c (do_input_reload): Don't use a spill for memory if it is different from the register to be reloaded into. Modified: branches/ira-merge/gcc/ChangeLog.ira branches/ira-merge/gcc/reload1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38272
[Bug c++/38334] New: pmf accesses violate strict-aliasing rules
For g++.dg/opt/pmf1.C we generate struct Container t; ... bb 3: D.1857_10 = (int (*__vtbl_ptr_type) (void) * *) t; D.1858_11 = *D.1857_10; a strict-aliasing warning is created if SRA is enabled and PR36509 is fixed. The frontend should probably use a ref-all pointer for the access. -- Summary: pmf accesses violate strict-aliasing rules Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rguenth at gcc dot gnu dot org OtherBugsDependingO 36509 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38334
[Bug fortran/37254] Reject valid PROCEDURE statement with implicit interface
--- Comment #7 from janus at gcc dot gnu dot org 2008-11-30 17:42 --- Regarding the validity see also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/5d2154a34072eb72/d9d7f1edde9aaa5b -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37254
[Bug fortran/36704] Procedure pointer as function result
--- Comment #2 from janus at gcc dot gnu dot org 2008-11-30 17:50 --- Created an attachment (id=16793) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16793action=view) patch v1 Attached is a minimal patch, which makes the simple case work where a separate result variable is used, like in this example: procedure(real),pointer :: p p = foo() print *,p(1.0) contains function foo() result(bar) procedure(real),pointer :: bar bar = sin end function end -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
[Bug target/27432] -fschedule-insns -O2 -march=athlon cause compilation error
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-11-30 17:55 --- The testcase in this PR works since GCC 4.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27432
[Bug middle-end/36509] [4.4 Regression]: gcc.dg/Wstrict-aliasing-float-ptr-int-obj.c
--- Comment #6 from rguenth at gcc dot gnu dot org 2008-11-30 18:50 --- Created an attachment (id=16794) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16794action=view) patch re-enabling the warning So we have a new blocker here... attaching the otherwise working patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36509
[Bug c++/38335] New: Code warning
Add warning about modifying an index in a for loop.
Without this warning the kind of errors introduced in code are likely to be
very difficult to debug (core dump).
Example code to reproduce below. Current commandline used to compile: -ansi
-pedantic -Wall -O.
#include iostream
using namespace std;
int main(int argc, char** argv) {
int loopndx;
int indexes[10];
for( loopndx=0 ; loopndx =10 ; loopndx++) {
if (loopndx==5) {
loopndx=66;
}
cout indexes[loopndx];
}
return (EXIT_SUCCESS);
}
--
Summary: Code warning
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adam dot c dot scott at gmail dot com
GCC build triplet: dmd
GCC host triplet: cyg
GCC target triplet: gdc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38335
[Bug target/38287] [4.1/4.2/4.3 regression] segfault at -O2 -fPIC -mcpu=v8
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:20 --- Subject: Bug 38287 Author: ebotcazou Date: Sun Nov 30 19:19:06 2008 New Revision: 142295 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142295 Log: PR target/38287 * config/sparc/sparc.md (divsi3 expander): Remove constraints. (divsi3_sp32): Add new alternative with 'K' for operand #2. (cmp_sdiv_cc_set): Factor common string. (udivsi3_sp32): Add new alternative with 'K' for operand #2. Add TARGET_V9 case. (cmp_udiv_cc_set): Factor common string. Added: trunk/gcc/testsuite/g++.dg/opt/reload3.C Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38287
[Bug target/38287] [4.1/4.2/4.3 regression] segfault at -O2 -fPIC -mcpu=v8
--- Comment #4 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:22 --- Subject: Bug 38287 Author: ebotcazou Date: Sun Nov 30 19:21:10 2008 New Revision: 142296 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142296 Log: PR target/38287 * config/sparc/sparc.md (divsi3 expander): Remove constraints. (divsi3_sp32): Add new alternative with 'K' for operand #2. (cmp_sdiv_cc_set): Factor common string. (udivsi3_sp32): Add new alternative with 'K' for operand #2. Add TARGET_V9 case. (cmp_udiv_cc_set): Factor common string. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/opt/reload3.C Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/sparc/sparc.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38287
[Bug target/38287] [4.1/4.2/4.3 regression] segfault at -O2 -fPIC -mcpu=v8
--- Comment #5 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:23 --- Subject: Bug 38287 Author: ebotcazou Date: Sun Nov 30 19:22:40 2008 New Revision: 142297 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142297 Log: PR target/38287 * config/sparc/sparc.md (divsi3 expander): Remove constraints. (divsi3_sp32): Add new alternative with 'K' for operand #2. (cmp_sdiv_cc_set): Factor common string. (udivsi3_sp32): Add new alternative with 'K' for operand #2. Add TARGET_V9 case. (cmp_udiv_cc_set): Factor common string. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/opt/reload3.C Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/sparc/sparc.md branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38287
[Bug target/38287] [4.1/4.2/4.3 regression] segfault at -O2 -fPIC -mcpu=v8
--- Comment #6 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:24 --- Subject: Bug 38287 Author: ebotcazou Date: Sun Nov 30 19:23:38 2008 New Revision: 142298 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142298 Log: PR target/38287 * config/sparc/sparc.md (divsi3 expander): Remove constraints. (divsi3_sp32): Add new alternative with 'K' for operand #2. (cmp_sdiv_cc_set): Factor common string. (udivsi3_sp32): Add new alternative with 'K' for operand #2. Add TARGET_V9 case. (cmp_udiv_cc_set): Factor common string. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/sparc/sparc.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38287
[Bug target/38287] [4.1/4.2/4.3 regression] segfault at -O2 -fPIC -mcpu=v8
--- Comment #7 from ebotcazou at gcc dot gnu dot org 2008-11-30 19:27 --- Thanks for the reduced testcase. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||11/msg01526.html Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.3 Version|4.3.3 |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38287
Re: [Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
I think this bug is invalid since the type can change via a placement new which will change the vtable. Sent from my iPhone On Nov 30, 2008, at 4:09 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 12:09 --- Note that we also do not CSE OBJ_TYPE_REF trees which seem to be valid gimple in place of the call in GIMPLE_CALLs so they do not get a separate value-number. (not that we would do anything useful with them if they were standalone, testcase for that welcome) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #4 from pinskia at gmail dot com 2008-11-30 19:29 --- Subject: Re: Missing CSE/PRE for memory operations involved in virtual call. I think this bug is invalid since the type can change via a placement new which will change the vtable. Sent from my iPhone On Nov 30, 2008, at 4:09 AM, rguenth at gcc dot gnu dot org [EMAIL PROTECTED] wrote: --- Comment #3 from rguenth at gcc dot gnu dot org 2008-11-30 12:09 --- Note that we also do not CSE OBJ_TYPE_REF trees which seem to be valid gimple in place of the call in GIMPLE_CALLs so they do not get a separate value-number. (not that we would do anything useful with them if they were standalone, testcase for that welcome) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug middle-end/35560] Missing CSE/PRE for memory operations involved in virtual call.
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-30 19:38 --- Yeah, that definitely complicates matters. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35560
[Bug c++/38335] Code warning
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-30 19:50 --- You mean like g++ -S -O2 t.C -Wall t.C: In function int main(int, char**): t.C:12: warning: array subscript is above array bounds ? Seriously, there is too many code around modifying the induction variable in a valid way. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38335
[Bug fortran/32512] efficiency of RESHAPE and SPREAD
--- Comment #6 from pault at gcc dot gnu dot org 2008-11-30 19:53 ---
Index: libgfortran/generated/reshape_r4.c
===
--- libgfortran/generated/reshape_r4.c (revision 142291)
+++ libgfortran/generated/reshape_r4.c (working copy)
@@ -81,7 +81,7 @@
const GFC_REAL_4 *src;
int n;
int dim;
- int sempty, pempty, shape_empty;
+ int sempty, pempty, shape_empty, contiguous_data;
index_type shape_data[GFC_MAX_DIMENSIONS];
rdim = shape-dim[0].ubound - shape-dim[0].lbound + 1;
@@ -100,6 +100,24 @@
}
}
+ contiguous_data = 1;
+
+ for (n = 0; n GFC_DESCRIPTOR_RANK(source); n++)
+{
+ if (n == 0)
+ {
+if (source-dim[n].stride != 1)
+ contiguous_data = 0;
+ }
+ else if (contiguous_data)
+ {
+ int del = source-dim[n-1].ubound - source-dim[n-1].lbound + 1;
+if (source-dim[n].stride != del)
+ contiguous_data = 0;
+ }
+}
+ st_printf (data %d\n, (int)contiguous_data);
+
if (ret-data == NULL)
{
rs = 1;
@@ -112,6 +130,11 @@
rs *= rex;
}
ret-offset = 0;
+ if (contiguous_data)
+ {
+ ret-data = source-data;
+ return;
+ }
ret-data = internal_malloc_size ( rs * sizeof (GFC_REAL_4));
ret-dtype = (source-dtype ~GFC_DTYPE_RANK_MASK) | rdim;
}
Was an experiment to see if an improvement to reshape could easily be
implemented in the library. It fails completely, of course, because the source
is freed! This does show that a flag in the descriptor to say that 'this'
cannot be freed would be a boon.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32512
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #4 from sgunderson at bigfoot dot com 2008-11-30 20:32 --- Subject: Re: Massive performance regression for jpeg_idct_islow On Sun, Nov 30, 2008 at 04:23:31PM -, rguenth at gcc dot gnu dot org wrote: Which tuning are you using? Try enabling -mtune=generic (possibly by default). The compile flags are -g -O2 -D_REENTRANT, IIRC. No weird compile options. /* Steinar */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-30 20:37 --- What is the gcc output if you append -v? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #5 from domob at gcc dot gnu dot org 2008-11-30 20:37 --- Subject: Bug 37779 Author: domob Date: Sun Nov 30 20:36:10 2008 New Revision: 142299 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142299 Log: 2008-11-30 Daniel Kraft [EMAIL PROTECTED] PR fortran/37779 * gfortran.h (struct gfc_entry_list): Fixed typo in comment. * resolve.c (is_illegal_recursion): New method. (resolve_procedure_expression): Use new is_illegal_recursion instead of direct check and handle function symbols correctly. (resolve_actual_arglist): Removed useless recursion check. (resolve_function): Use is_illegal_recursion instead of direct check. (resolve_call): Ditto. 2008-11-30 Daniel Kraft [EMAIL PROTECTED] PR fortran/37779 * gfortran.dg/recursive_check_1.f: Changed expected error message to the more general new one. * gfortran.dg/recursive_check_2.f90: Ditto. * gfortran.dg/entry_18.f90: Ditto. * gfortran.dg/recursive_check_4.f03: Do the same check also for FUNCTIONS, as this is different in details from SUBROUTINES. * gfortran.dg/recursive_check_6.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/recursive_check_6.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/entry_18.f90 trunk/gcc/testsuite/gfortran.dg/recursive_check_1.f trunk/gcc/testsuite/gfortran.dg/recursive_check_2.f90 trunk/gcc/testsuite/gfortran.dg/recursive_check_4.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug fortran/37779] Missing RECURSIVE not detected
--- Comment #6 from domob at gcc dot gnu dot org 2008-11-30 20:40 --- This second commit detects cases like the one mentioned by Tobias in comment #2 on trunk/4.4 I'm going to work on a optional runtime-recursion checking feature now as last part for this PR. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37779
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #6 from sgunderson at bigfoot dot com 2008-11-30 20:40 --- Subject: Re: Massive performance regression for jpeg_idct_islow On Sun, Nov 30, 2008 at 08:37:31PM -, rguenth at gcc dot gnu dot org wrote: --- Comment #5 from rguenth at gcc dot gnu dot org 2008-11-30 20:37 --- What is the gcc output if you append -v? fugl:~ /usr/lib/gcc-snapshot/bin/gcc -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20081117-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,c++,java,fortran,objc,obj-c++,ada --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --disable-plugin --with-java-home=/usr/lib/gcc-snapshot/java-1.5.0-gcj-4.4-1.5.0.0/jre --enable-java-home --with-jvm-root-dir=/usr/lib/gcc-snapshot/jvm --with-jvm-jar-dir=/usr/lib/gcc-snapshot/jvm-exports --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --disable-werror --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.0 20081117 (experimental) [trunk revision 141948] (Debian 20081117-1) /* Steinar */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #26 from steven at gcc dot gnu dot org 2008-11-30 20:45 --- Resurrecting regmove is not an option. Time is better spent on figuring out what regmove does, that makes a difference, and see if IRA can be taught to do the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #27 from hjl dot tools at gmail dot com 2008-11-30 20:52 --- (In reply to comment #26) Resurrecting regmove is not an option. Time is better spent on figuring out what regmove does, that makes a difference, and see if IRA can be taught to do the same. x86 has (define_insn *movdi_1_rex64 [(set (match_operand:DI 0 nonimmediate_operand =r,r ,r,m ,!m,*y,*y,?r ,m ,?*Ym,?*y,*x,*x,?r ,m,?*Yi,*x,?*x,?*Ym) (match_operand:DI 1 general_operand Z ,rem,i,re,n ,C ,*y,*Ym,*y,r ,m ,C ,*x,*Yi,*x,r ,m ,*Ym,*x))] TARGET_64BIT !(MEM_P (operands[0]) MEM_P (operands[1])) The alternative with * is available for regmove, but not for IRA/reload. I don't know how you can resolve it without a different pass. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-11-30 21:04 --- Append -v to the command-line you use for compiling ;) Seriously, if using -mtune=generic works then this is a Debian packaging issue of their gcc-snapshot compiler. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug middle-end/38336] New: fold_builtin_memory_op generates invalid GIMPLE
See http://gcc.gnu.org/ml/fortran/2008-11/msg00398.html for details.
With some gfortran allocatation patch, the middle end generates invalid GIMPLE
at any optimization level (but -O0). The difference between two
-fdump-tree-original (-O0 and with optimization) looks as follows:
ERRMSG.12 = Attempt to deallocate an unallocated object[1]{lb: 1 sz:
1};
-ERRMSG.12 = stat.11 != 0 ? (void) __builtin_memcpy ((void *) err, (void
*) ERRMSG.12, 30) : (void) 0;
+ERRMSG.12 = stat.11 != 0 ? err = *(character(kind=1)[1:30] * {ref-all})
ERRMSG.12 : (void) 0;
The invalid GIMPLE later generates an ICE of the kind:
a.f90:16: internal compiler error: verify_gimple failed
Richard wrote:
(see builtins.c:fold_builtin_memory_op)
--
Summary: fold_builtin_memory_op generates invalid GIMPLE
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38336
[Bug middle-end/38336] fold_builtin_memory_op generates invalid GIMPLE
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-11-30 21:15 --- The failure is that fold_builtin_memory_op forgets to properly make the return value available if 'ignore' is passed as true. This confuses COND_EXPR gimplification. The fix may be non-trivial. -- 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 Last reconfirmed|-00-00 00:00:00 |2008-11-30 21:15:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38336
[Bug middle-end/38336] fold_builtin_memory_op generates invalid GIMPLE
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-11-30 21:17 --- Btw, ERRMSG.12 = stat.11 != 0 ? (void) __builtin_memcpy ((void *) err, (void *) ERRMSG.12, 30) : (void) 0; doesn't make sense. You assign void to ERRMSG.12 which is not void. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38336
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #28 from steven at gcc dot gnu dot org 2008-11-30 21:18 --- You're not explaining what regmove does. What transformation do these alternatives with * enable regmove to do? I'm not saying that a separate pass is not an option. Perhaps a regmove-like pass is necessary. In fact it probably is, I think even Vlad already acknowledged so. But not regmove as-we-know-it, which is a friggin' mess that ought to go away. What we should figure out IMHO, is which transformation(s) it is (are) that regmove does, which are helpful here. Maybe we can add a simple pre-regalloc pass that does these transformations, or make it part of an existing pass, using clean infrastructure (cfg, df) instead of the ad-hoc mess of regmove. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #8 from sgunderson at bigfoot dot com 2008-11-30 21:19 --- Subject: Re: Massive performance regression for jpeg_idct_islow On Sun, Nov 30, 2008 at 09:04:07PM -, rguenth at gcc dot gnu dot org wrote: Append -v to the command-line you use for compiling ;) Seriously, if using -mtune=generic works then this is a Debian packaging issue of their gcc-snapshot compiler. fugl:~/nmu/libjpeg6b-6b /usr/lib/gcc-snapshot/bin/gcc -D_REENTRANT -g -Wall -O2 -g -I. -c ./jidctint.c -fPIC -DPIC -o .libs/jidctint.o -v Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 20081117-1' --with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs --enable-languages=c,c++,java,fortran,objc,obj-c++,ada --prefix=/usr/lib/gcc-snapshot --enable-shared --with-system-zlib --disable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-java-awt=gtk --enable-gtk-cairo --disable-plugin --with-java-home=/usr/lib/gcc-snapshot/java-1.5.0-gcj-4.4-1.5.0.0/jre --enable-java-home --with-jvm-root-dir=/usr/lib/gcc-snapshot/jvm --with-jvm-jar-dir=/usr/lib/gcc-snapshot/jvm-exports --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --disable-werror --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.4.0 20081117 (experimental) [trunk revision 141948] (Debian 20081117-1) COLLECT_GCC_OPTIONS='-D_REENTRANT' '-g' '-Wall' '-O2' '-g' '-I.' '-c' '-fPIC' '-DPIC' '-o' '.libs/jidctint.o' '-v' '-mtune=i486' /usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/4.4.0/cc1 -quiet -v -I. -D_REENTRANT -DPIC ./jidctint.c -quiet -dumpbase jidctint.c -mtune=i486 -auxbase-strip .libs/jidctint.o -g -g -O2 -Wall -version -fPIC -o /tmp/cc5hqg0m.s ignoring nonexistent directory /usr/local/include/i486-linux-gnu ignoring nonexistent directory /usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.4.0/../../../../i486-linux-gnu/include ignoring nonexistent directory /usr/include/i486-linux-gnu #include ... search starts here: #include ... search starts here: . /usr/local/include /usr/lib/gcc-snapshot/include /usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.4.0/include /usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.4.0/include-fixed /usr/include End of search list. GNU C (Debian 20081117-1) version 4.4.0 20081117 (experimental) [trunk revision 141948] (i486-linux-gnu) compiled by GNU C version 4.4.0 20081117 (experimental) [trunk revision 141948], GMP version 4.2.2, MPFR version 2.3.2. GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: 445209552aa2d93e7e967b7473e83cd6 COLLECT_GCC_OPTIONS='-D_REENTRANT' '-g' '-Wall' '-O2' '-g' '-I.' '-c' '-fPIC' '-DPIC' '-o' '.libs/jidctint.o' '-v' '-mtune=i486' as -V -Qy -o .libs/jidctint.o /tmp/cc5hqg0m.s GNU assembler version 2.18.0 (i486-linux-gnu) using BFD version (GNU Binutils for Debian) 2.18.0.20080103 COMPILER_PATH=/usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/4.4.0/:/usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/4.4.0/:/usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/:/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.4.0/:/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/:/usr/lib/gcc/i486-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.4.0/:/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.4.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc-snapshot/lib/gcc/i486-linux-gnu/4.4.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-D_REENTRANT' '-g' '-Wall' '-O2' '-g' '-I.' '-c' '-fPIC' '-DPIC' '-o' '.libs/jidctint.o' '-v' '-mtune=i486' -mtune=generic still produces these long series of leas. /* Steinar */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #9 from sgunderson at bigfoot dot com 2008-11-30 21:22 --- Subject: Re: Massive performance regression for jpeg_idct_islow On Sun, Nov 30, 2008 at 09:19:08PM -, sgunderson at bigfoot dot com wrote: -mtune=generic still produces these long series of leas. Sorry, I objdumped the wrong file. -mtune=generic appears to fix it (although I haven't checked the performance). /* Steinar */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #10 from rguenth at gcc dot gnu dot org 2008-11-30 21:29 --- /usr/lib/gcc-snapshot/libexec/gcc/i486-linux-gnu/4.4.0/cc1 -quiet -v -I. -D_REENTRANT -DPIC ./jidctint.c -quiet -dumpbase jidctint.c -mtune=i486 -auxbase-strip .libs/jidctint.o -g -g -O2 -Wall -version -fPIC -o /tmp/cc5hqg0m.s so it uses -mtune=i486 - this optimizes the multiplication for i486 where imul is slow. The difference to 4.3 is a packaging issue in Debian. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug target/37364] [4.4 Regression] IRA generates inefficient code due to missing regmove pass
--- Comment #29 from steven at gcc dot gnu dot org 2008-11-30 21:32 ---
The insns 8 in comment #0 show the regmove transformation that matters here:
With regmove disabled::
(insn:HI 8 7 14 2 ../../include/mmintrin.h:300 (set (reg:V2SI 61)
(plus:V2SI (reg:V2SI 63 [ x ])
(mem/c/i:V2SI (symbol_ref:DI (y) var_decl 0x7f66abfb5c80 y) [2
y
+0 S8 A64]))) 992 {*mmx_addv2si3} (expr_list:REG_DEAD (reg:V2SI 63 [ x ])
(nil)))
vs. with regmove enabled:
(insn:HI 8 7 14 2 ../../include/mmintrin.h:300 (set (reg:V2SI 63 [ x ])
(plus:V2SI (reg:V2SI 63 [ x ])
(mem/c/i:V2SI (symbol_ref:DI (y) var_decl 0x7fd36e03cc80 y) [2
y+0 S8 A64]))) 992 {*mmx_addv2si3} (nil))
This is a textbook example of a regmove transformation (where the use of the
word textbook is an insult to all textbooks ever written, since nothing in
regmove is textbook, but oh well...). It's turned a 3-address instruction
into a 2-address instruction, and this is precisely the transformation that
regmove was originally written for.
In IRA, I would've expected reg 61 and reg 63 to be coalesced to give the same
result.
Vlad already commented on this in comment #6. It's clear from his description
why IRA did not coalesce reg 61 and reg 63.
Other compilers do this kind of transformation via reverse copy propagation.
GCC could perhaps add something like that too, when it transforms a 3-address
insn to a 2-address insn.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37364
[Bug fortran/36704] Procedure pointer as function result
--- Comment #3 from janus at gcc dot gnu dot org 2008-11-30 22:00 --- Created an attachment (id=16795) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16795action=view) patch v2 This updated patch passes the testsuite without regressions and adds some additional checks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36704
[Bug tree-optimization/38328] Massive performance regression for jpeg_idct_islow
--- Comment #11 from sgunderson at bigfoot dot com 2008-11-30 22:48 --- Subject: Re: Massive performance regression for jpeg_idct_islow On Sun, Nov 30, 2008 at 09:29:29PM -, rguenth at gcc dot gnu dot org wrote: so it uses -mtune=i486 - this optimizes the multiplication for i486 where imul is slow. The difference to 4.3 is a packaging issue in Debian. Thanks! I'll file a bug against the package. /* Steinar */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38328
[Bug tree-optimization/38072] [4.3 Regression] ICE during inlining of valid code
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38072
[Bug middle-end/37861] [4.3 Regression] Bogus array bounds warning
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37861
[Bug c++/36654] [4.2/4.3 Regression] Inlined con/de-structor breaks virtual inheritance dllimport classes
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3 regression] Inlined|[4.2/4.3 Regression] Inlined |con/de-structor breaks |con/de-structor breaks |virtual inheritance |virtual inheritance |dllimport classes |dllimport classes Target Milestone|4.3.3 |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36654
[Bug c++/37314] [4.2/4.3/4.4 Regression] seg violation
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Priority|P3 |P2 Last reconfirmed|2008-09-01 15:53:55 |2008-11-30 23:06:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37314
[Bug target/32344] crash with EH on multiprocessor machines
--- Comment #2 from pinskia at gcc dot gnu dot org 2008-12-01 00:10 --- Hmm, shouldn't the unwinder using pthreads mutex's already? What is the output of gcc -v is the thread model set to single? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32344
[Bug driver/38316] The --help=xxx option does not play well with -pipe or -save-temps
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-01 00:14 --- Confirmed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-12-01 00:14:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38316
[Bug preprocessor/38322] ICE in gcc.dg/cpp/trad/include.c -fno-show-column at -m32 and -m64
--- Comment #1 from pinskia at gcc dot gnu dot org 2008-12-01 00:17 --- I had the same thing for the PS3 compiler, it turned out due to C++ style comments in the system headers. This was causing libcpp to abort. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |preprocessor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38322
[Bug fortran/38323] gfortran.dg/parameter_array_init_3.f90 -O compilation test ICEs at -m32 and -m64
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2008-12-01 02:11 --- Try this: gdb --args f951 parameter_array_init_3.f90 r bt My experiance with this bug is that it segfaults at a place away from where the actual bug is. This one has been very very elusive. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38323
[Bug rtl-optimization/38280] [4.4 regression] Revision 142207 breaks 416.gamess/481.wrf in SPEC CPU 2006
--- Comment #8 from Joey dot ye at intel dot com 2008-12-01 02:18 --- Yes. It fixes 416/481 on 32 bits and 481 on 64 bits. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38280
