[Bug fortran/47505] New: [OOP] Intrinsics which should operate on polymorphic objects (BT_CLASS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47505 Summary: [OOP] Intrinsics which should operate on polymorphic objects (BT_CLASS) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: ja...@gcc.gnu.org Bob (Robert Corbett of Oracle) reports at http://j3-fortran.org/pipermail/j3/2011-January/004136.html that most compilers do not return a BT_CLASS when invoking one of the following procedures; I have not checked - especially as polymorphic arrays are not yet supported. But I wouldn't be surprised if gfortran had the same problems: quote The Fortran standard explicitly indicates that a few intrinsic functions (EXTENDS_TYPE_OF, SAME_TYPE_AS, and STORAGE_SIZE) accept polymorphic arguments. The list of intrinsic procedures that satisfy these criteria are ALLOCATEDASSOCIATEDEXTENDS_TYPE_OF IMAGE_INDEX IS_CONTIGUOUS LBOUND LCOBOUND MOVE_ALLOCPRESENT SAME_TYPE_AS SHAPE SIZE STORAGE_SIZE THIS_IMAGEUBOUND UCOBOUND [...] This side thinks the following additional functions should accept polymorphic arguments CSHIFT EOSHIFT MERGE PACK RESHAPE SHAPE SIZE SPREAD TRANSFER TRANSPOSE UNPACK /quote And in a follow up: quote None of the implementations I tried treats the results of these intrinsic functions as polymorphic. Some implementations gave no diagnostic message for passing polymorphic acutal arguments to the intrinsic functions, but none allowed the results to be used in contexts that required polymorphism. I admit I find that strange. /quote
[Bug fortran/47506] New: [OOP][Fortran 90+] Assumed-size array checks (polymorphic and component)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47506 Summary: [OOP][Fortran 90+] Assumed-size array checks (polymorphic and component) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: accepts-invalid, diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org === a) Fortran 90 and later: === Aleks noted at http://j3-fortran.org/pipermail/j3/2011-January/004154.html the gfortran misses a diagnostic for the following program. Ifort prints: The upper bound shall not be omitted in the last dimension of a reference to an assumed size array. [X] call sub2(x%i) -^ NAG has: Error: line 16: Invalid appearance of assumed-size array name X Pathscale/open64 have: This whole array reference of an assumed-size array is not allowed. program test type :: t integer :: i real :: r end type type(t) :: x(10) call sub1(x) contains subroutine sub1(x) type(t) :: x(*) call sub2(x%i) ! WRONG: Should be, e.g., x(:10)%i end subroutine subroutine sub2(x) integer :: x(*) end subroutine end program === b) [OOP] Fortran 2003 and later === Bill noted at http://j3-fortran.org/pipermail/j3/2011-January/004148.html in the same thread that the standard (nor gfortran) reject: assumed-size poly actual - non-poly dummy although for most compilers (but IBM's?) it will not work. Sketched example: subroutine before(w) use typedef ! Interface for A here type(T) :: w(*) ! no descriptor here - size not known call A(w) end subroutine A (x) use typedef ! types T and extensions defined in here class(T) :: x(*) ... call B(x) ... end subroutine B(y) use typedef type(T) :: y(*) * * * Bob believes both are invalid - and covered by: An assumed-size array (5.3.6.5) is permitted to appear as a whole array in an executable construct or specification expression only as an actual argument in a procedure reference that does not require the shape.
[Bug fortran/47507] New: PURE functions with VALUE arguments invalidly rejectd
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47507 Summary: PURE functions with VALUE arguments invalidly rejectd Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The following is valid, but gfortran claims: Error: Argument 'x' of pure function 'f' at (1) must be INTENT(IN) C1276 The specification-part of a pure function subprogram shall specify that all its nonpointer dummy data objects have the INTENT (IN) or the VALUE attribute. (F2008 quote) pure function f(x) real, VALUE :: x real :: f f = sin(x) end function f
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062 --- Comment #26 from Xavier zazzou at gmail dot com 2011-01-28 09:11:27 UTC --- Thanks for your work. Question : I tried to build my own version, but i did not succeed. (1) gcc-4.5.2 : ok (2) gcc-4.5.2 + modified/added files from trunk (4.6) : compilation error on file match.c (3) gcc-4.6 (from trunk) : some errors... (I don't remerber) Is it normal that test (2) did not work ? Do i need to modify directly files related to this bug report ?
[Bug debug/47508] New: [4.6 Regression] -fcompare-debug failure with -ftracer for pr42918.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47508 Summary: [4.6 Regression] -fcompare-debug failure with -ftracer for pr42918.c Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassig...@gcc.gnu.org ReportedBy: ram...@gcc.gnu.org Target: arm-eabi Since last night I'm seeing this failure with -ftracer and -fcompare-debug on arm-eabi /arm/scratch/pdtltest/work/sandboxes/fsf/trunk/2011-01-26/build-a9softfpneon/gcc2/gcc/xgcc -B/arm/scratch/pdtltest/work/sandboxes/fsf/trunk/2011-01-26/build-a9softfpneon/gcc2/gcc/ /arm/scratch/pdtltest/work/sandboxes/fsf/trunk/source/gcc-fsf/gcc/testsuite/gcc.dg/pr42918.c -O2 -fcompare-debug -ftracer -DSTACK_SIZE=16384 -S -o pr42918.s (timeout = 800) xgcc: error: /arm/scratch/pdtltest/work/sandboxes/fsf/trunk/source/gcc-fsf/gcc/testsuite/gcc.dg/pr42918.c: -fcompare-debug failure compiler exited with status 1 output is: xgcc: error: /arm/scratch/pdtltest/work/sandboxes/fsf/trunk/source/gcc-fsf/gcc/testsuite/gcc.dg/pr42918.c: -fcompare-debug failure The difference in the .gkd files is : - 5) - 5) (note# 0 0 (lab) NOTE_INSN_DELETED_LABEL 3) (code_label 1 0 0 1 [1 uses])(code_label 1 0 0 1 [1 uses]) (note# 0 0 [bb 4] NOTE_INSN_BASIC_BLOCK)(note# 0 0 [bb 4] NOTE_INSN_BASIC_BLOCK) (insn# 0 0 (use (reg/i:SI 0 r0)) /arm/scratch/pdtltest/work/s (insn# 0 0 (use (reg/i:SI 0 r0)) /arm/scratch/pdtltest/work/s (nil)) (nil)) (note# 0 0 NOTE_INSN_EPILOGUE_BEG) (note# 0 0 NOTE_INSN_EPILOGUE_BEG) (jump_insn:TI# 0 0 (unspec_volatile [ (jump_insn:TI# 0 0 (unspec_volatile [ (return) (return) ] 1) /arm/scratch/pdtltest/work/sandboxes/fsf/trunk/s ] 1) /arm/scratch/pdtltest/work/sandboxes/fsf/trunk/s (nil)) (nil)) (barrier 0 0 0) (barrier 0 0 0) (code_label 5 0 0 5 [2 uses])(code_label 5 0 0 5 [2 uses]) (note# 0 0 [bb 5] NOTE_INSN_BASIC_BLOCK)(note# 0 0 [bb 5] NOTE_INSN_BASIC_BLOCK) (note# 0 0 (lab) NOTE_INSN_DELETED_LABEL 3)
[Bug bootstrap/47147] gcc 4.6 fails to compile on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47147 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-28 09:29:54 UTC --- patch posted for review: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00881.html
[Bug libstdc++/16896] Use of non-reserved names in stl_list.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16896 Benjamin Kosnik bkoz at gcc dot gnu.org changed: What|Removed |Added CC||bkoz at gcc dot gnu.org --- Comment #11 from Benjamin Kosnik bkoz at gcc dot gnu.org 2011-01-28 09:36:15 UTC --- FYI: this does fix it, and without symbol aliasing (so I guess it is supported on more platforms.) However, all these _List_node_base definitions are the same, the same, the same. A cleaner fix is to move __List_node_base out of std:: and into std::__detail to remove any lingering ADL issues, and to not include it in the inlined namespace for debug/parallel/profile etc mode. This had been hard to do in the past due to the complicated way the inlined namespaces were constructed. However, I have to fix this anyway for 36104 and so choose to clean this up as part of that. best, benjamin
[Bug libstdc++/16896] Use of non-reserved names in stl_list.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16896 --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-28 09:41:37 UTC --- Ok, if you have to do something different for 36104, makes sense. Otherwise, if you ask my opinion, being a temporary fix anyway, I would not be worried by that bit of code duplication, given that it works everywhere and it's straightforward.
[Bug rtl-optimization/47489] ICE in print_pattern, at sched-vis.c:602 (affecting mips, with slim RTL dumps)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47489
Andrey Belevantsev abel at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.01.28 09:43:05
CC||abel at gcc dot gnu.org
Ever Confirmed|0 |1
--- Comment #1 from Andrey Belevantsev abel at gcc dot gnu.org 2011-01-28
09:43:05 UTC ---
Confirmed. This is because we deliberately abort on SEQUENCEs here since 2002
(rev. 54497) because of:
2002-06-05 David S. Miller da...@redhat.com
Delete SEQUENCE rtl usage outside of reorg and ssa passes.
So either we reinstate the hunk deleted back there like with patch below, or we
document that slim dumps cannot be requested for machine reorg and later
passes.
diff --git a/gcc/sched-vis.c b/gcc/sched-vis.c
index 25a0b60..331ccbf 100644
--- a/gcc/sched-vis.c
+++ b/gcc/sched-vis.c
@@ -599,8 +599,19 @@ print_pattern (char *buf, const_rtx x, int verbose)
}
break;
case SEQUENCE:
- /* Should never see SEQUENCE codes until after reorg. */
- gcc_unreachable ();
+ {
+ int i;
+
+ sprintf (t1, %%{);
+ for (i = 0; i XVECLEN (x, 0); i++)
+ {
+ print_insn (t2, XVECEXP (x, 0, i), verbose);
+ sprintf (t3, %s%s;, t1, t2);
+ strcpy (t1, t3);
+ }
+ sprintf (buf, %s%%}, t1);
+ }
+ break;
case ASM_INPUT:
sprintf (buf, asm {%s}, XSTR (x, 0));
break;
[Bug libstdc++/46914] std::atomicint*::exchange(...) doesn't store correct value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46914 --- Comment #11 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-28 09:43:44 UTC --- Ok, with --with-arch-32=i486 in the configure options and -m32 on the command line the problem can be reproduced. Frankly, I don't understand what is going on: in that case, by default, everything should remain consistent and the _GLIBCXX_ATOMIC_BUILTINS_* used when building atomic.cc should be still the correct ones for user code too (if some different -march were used on the command line, then I could see possible troubles, again, because the atomic headers don't use macros sensitive to the actual command line options).
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062 --- Comment #27 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-28 09:45:58 UTC --- (In reply to comment #26) Question : I tried to build my own version, but i did not succeed. (1) gcc-4.5.2 : ok (2) gcc-4.5.2 + modified/added files from trunk (4.6) : compilation error on file match.c Is it normal that test (2) did not work ? Well, it is not surprising that just applying 4.6 patches do not work on 4.5. After all, one year of development is a lot. During that year the following, user-visible changes were done for Fortran: http://gcc.gnu.org/gcc-4.6/changes.html#fortran Thus, the chance that a patch applies without any changes to an older version is relatively low. Do i need to modify directly files related to this bug report ? Well, if applying the patch does not work and if you want to use 4.5, you seemingly have to. I assume that the changes to match.c are not difficult, but I have not tried it - and I do not plan to do so. (3) gcc-4.6 (from trunk) : some errors... (I don't remerber) Without error message, it is difficult to help (and this bug report is the wrong forum*). However, you could also try to use the nightly builds, which are available at http://gcc.gnu.org/wiki/GFortranBinaries * Mailing list, cf. http://gcc.gnu.org/lists.html try gcc-help@ or fortran@ but first glance at the instructions at http://gcc.gnu.org/install/
[Bug libstdc++/36104] [4.3/4.4/4.5/4.6 Regression] gnu-versioned-namespace is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36104 --- Comment #15 from Benjamin Kosnik bkoz at gcc dot gnu.org 2011-01-28 09:51:23 UTC --- Patches 1-3 restore gcc-4.2 behavior. Configure works, the library builds, most all of the tests pass regression, etc. Unfortunately, this is still annoyingly wrong on close inspection. Namespaces nested within std containing definitions will be mis-versioned. Using versioning + modes fails. The inline namespace code, which unfortunately includes most of the macros used to define namespaces in every libstdc++ header, was done as part of the initial work for this feature, nee namespace association. Then changes were made, nesting was made de rigeur, and the original macros were pushed and squeezed into submission. Yet more modes were added: parallel, profile. Yet another level of nesting was added for versioning, overloading the namespace macros with another condition. C++0x support starts to partition the std:: namespace into finer bits: chrono, regex, etc. All of these nested namespaces + current macros are wrong. Patch 4 fixes these issues, and provides a saner infrastructure for future debug/profile/parallel work.
[Bug rtl-optimization/47454] registers are not allocated according to its preferred order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47454 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.28 09:57:13 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 09:57:13 UTC --- (In reply to comment #0) Created attachment 23115 [details] testcase Note that register r8 is used many times, but register r2 is never used. In thumb2 r8 is high register, its usage will cause 32bit instructions. If we replace r8 with r2, a lot of code size will be reduced in this case. In arm.h REG_ALLOC_ORDER is defined as 3, 2, 1, 0, 12, 14, 4, 5, 6, 7, 8, 10, 9, 11, 13, 15 ... We can see that r2 should be used before r8, but the result is not. I have thought about doing work in IRA to address this, so that we impose a higher cost for the higher registers if we have not yet ventured into them. In this particular case, the issue will be with IRA's calculated register costs. The REG_ALLOC_ORDER is only used when costs are equal, which is why the allocated order is normally roughly inline with it. R2 must be given a high cost for some reason, which causes assign_hard_reg to prefer later registers with lower costs. The IRA dump will show you the costs. If you attach it to this, we could investigate further.
[Bug middle-end/44554] Stack space after sigsetjmp is reused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.28 10:03:46 Ever Confirmed|0 |1 --- Comment #17 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 10:03:46 UTC --- (In reply to comment #15) (In reply to comment #14) Created attachment 21901 [details] A patch that should fix it Please verify whether this fixes it. Hasn't it already been fixed in comment #11? My plan was to wait until release of gcc-4.4.5 and test then. Are additional changes required to fix this bug? gcc 4.4.5 was released in October. Please can you confirm if this is now fixed.
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 10:11:28 UTC --- I am using the last 4.6 that built ok as host compiler, a snapshot from 6th december last year. Binutils is the 2.11 release, but the build also failed with the 2.10 release. I configure with CFLAGS='-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -Wno-unused-but-set-variable -g -U_FORTIFY_SOURCE' ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java --enable-checking=yes --with-gxx-include-dir=/usr/include/c++/4.6 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ '--with-pkgversion=SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --program-suffix=-4.6 --enable-linux-futex --without-system-libunwind --with-plugin-ld=/usr/bin/gold --with-cpu=power4 --enable-secureplt --with-long-double-128 --build=powerpc64-suse-linux and build with make bootstrap-lean 'STAGE1_CFLAGS=-O -g' 'BOOT_CFLAGS=-fmessage-length=0 -O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind-tables -Wno-unused-but-set-variable -g -U_FORTIFY_SOURCE' -j6 -l12 I will try building the current snapshot with a 4.5 host compiler and see if that allows using itself as host compiler again. Unfortunately the builds are automated, so I do not have access to cse.o at the moment (but I'll recreate the problem locally if it persists with a current 4.6 host compiler)
[Bug c++/46317] Incorrect construction vtable on ARM in case of diamond shaped virtual inheritance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46317 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.28 10:19:03 CC||ibolton at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 10:19:03 UTC --- (In reply to comment #2) (In reply to comment #1) Does -fno-tree-sink fixes the issue? No it doesn't. The only flags that works are: -O0 or -fno-inline or -fno-unit-at-a-time or -fno-toplevel-reorder I can also make it work more or less by deactivating a certain number of optimisation flag, but the output code does not really work... (I have tried something like 58 different flags...) Out of interest, did you try any newer releases of gcc?
[Bug libstdc++/46914] std::atomicint*::exchange(...) doesn't store correct value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46914 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||bkoz at redhat dot com --- Comment #12 from Paolo Carlini paolo.carlini at oracle dot com 2011-01-28 10:22:27 UTC --- I'm making some progress: using --with-arch-32=i586 is fine, and the reason is, in that case the _GLIBCXX_ATOMIC_BUILTINS_* are *all* true (in the i486 case, _GLIBCXX_ATOMIC_BUILTINS_8 is false). Now, the testcase only uses ints, but in atomic_base.h we require either all true, or the special case of at least _GLIBCXX_ATOMIC_BUILTINS_1 true, that is _GLIBCXX_ATOMIC_PROPERTY == 1, or none true, that is _GLIBCXX_ATOMIC_PROPERTY == 0. Given that, I suppose, Ubuntu and Debian have been using -i486 only because of the crazyness old GCCs defaulting to i386 and now everything is different finally (essentially the current default is a bit more than pentium4), I don't consider this issue particularly serious. Still, it would be nice to understand why both _GLIBCXX_ATOMIC_PROPERTY == 1 (as this PR shows) and _GLIBCXX_ATOMIC_PROPERTY == 0 (as trying --with-arch-32=i386 shows), both don't work. Maybe Benjamin has ideas... Note: the command line per se doesn't seem to matter, is the way the *.so is built that matters.
[Bug middle-end/44554] Stack space after sigsetjmp is reused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554 Christian Eggers christian.eggers at kathrein dot de changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED --- Comment #18 from Christian Eggers christian.eggers at kathrein dot de 2011-01-28 10:29:12 UTC --- (In reply to comment #17) gcc 4.4.5 was released in October. Please can you confirm if this is now fixed. I think THIS bug is fixed in 4.4.5. Unfortunately I've still problems with wrong computations as already mentioned in comment #8. But this would either be related to PR40386 or it's another bug.
[Bug target/46762] gcc crosscompiled for arm optimises away volatile struct member access when -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46762 Ian Bolton ibolton at gcc dot gnu.org changed: What|Removed |Added CC||ibolton at gcc dot gnu.org Known to work||4.5.3, 4.6.0 Target Milestone|--- |4.5.3 --- Comment #1 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 10:36:23 UTC --- I have not yet confirmed that this occurs in gcc 4.5.1 (as opposed to the codesourcery release), but it is working correctly in gcc 4.5.3 (gcc 4.5 branch) and 4.6.0 (trunk).
[Bug bootstrap/47044] bootstrap comparison failure when -O2 defaults on -fgraphite-identity and --enable-build-with-cxx
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47044 Francois-Xavier Coudert fxcoudert at gcc dot gnu.org changed: What|Removed |Added Target|x86_64-apple-darwin10 | Status|UNCONFIRMED |NEW Keywords||build Last reconfirmed||2011.01.28 10:36:30 CC||fxcoudert at gcc dot ||gnu.org Host|x86_64-apple-darwin10 | Ever Confirmed|0 |1 Build|x86_64-apple-darwin10 |
[Bug c/47509] New: avr-gcc error: could not split insn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47509
Summary: avr-gcc error: could not split insn
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jh.gcc-bugzi...@plonk.de
(note: copied from See also https://bugzilla.redhat.com/show_bug.cgi?id=662054)
avr-gcc 4.5.1-2.fc14.1 stops with an error message:
avr-gcc -Wall -W -Wno-unused-parameter -Wno-sign-compare -Wno-char-subscripts
-g -Os -std=gnu99 -fdata-sections -ffunction-sections -funsigned-char
-funsigned-bitfields -fpack-struct -fshort-enums -mcall-prologues -fshort-enums
-fno-strict-aliasing -Iprotocols/usb/usbdrv -Iprotocols/usb -DAVR_BUILD
-DF_CPU=2000UL -mmcu=atmega644 -I. -c -o protocols/uip/uip.o
protocols/uip/uip.c
protocols/uip/uip.c: In function 'uip_udp_new':
protocols/uip/uip.c:570:1: error: could not split insn
(insn 106 105 107 protocols/uip/uip.c:554 (parallel [
(set (reg:HI 24 r24 [106])
(rotate:HI (reg:HI 24 r24 [orig:105 lastport ] [105])
(const_int 8 [0x8])))
(clobber (mem/c:QI (plus:HI (reg/f:HI 28 r28)
(const_int 1 [0x1])) [0 %sfp+1 S1 A8]))
]) 64 {*rotbhi} (expr_list:REG_EQUIV (mem/s/j:HI (plus:HI (reg/f:HI 26
r26 [103])
(const_int 4 [0x4])) [0 uip_udp_conns[D.4587_20].lport+0 S2
A8])
(nil)))
protocols/uip/uip.c:570:1: internal compiler error: in final_scan_insn, at
final.c:2650
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugzilla.redhat.com/ for instructions.
make: *** [protocols/uip/uip.o] Error 1
It compiles fine with 4.4.2-1.fc13 and also 4.3.3-3.fc11.
Version-Release number of selected component (if applicable):
avr-libc-1.7.0-1.fc14.noarch
avr-gcc-4.5.1-2.fc14.1.x86_64
Steps to Reproduce:
1. git clone git://github.com/ethersex/ethersex.git
2. cd ethersex/
3. make menuconfig
- Make sure that UDP support is activated in Network, then select Exit and
save the config
4. make
[Bug debug/47508] [4.6 Regression] -fcompare-debug failure with -ftracer for pr42918.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47508 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.6.0
[Bug tree-optimization/45122] [4.6 Regression] -funsafe-loop-optimizations causes FAIL: gcc.c-torture/execute/pr27285.c execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45122 --- Comment #12 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 10:57:31 UTC --- (In reply to comment #11) Richi, which one is “second”? The second I posted, or the second in the active attachment list? (the third posted superseded the first, becoming second in the list) The patch attached to comment #8, disabling the optimization for loops with more than one exit.
[Bug debug/47498] [4.6 Regression] -fcompare-debug failure with -fsched2-use-superblocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47498 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-28 10:58:03 UTC --- Indeed, sched2 here moves over the NOTE_INSN_FUNCTION_BEG before all real insns with -g, but keeps it where it was (and should be) with -g0.
[Bug c++/47504] some constexpr calculations erroneously overflow when using negative numbers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47504 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.28 10:59:58 Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 10:59:58 UTC --- Confirmed (with -fsigned-char, -funsigned-char works ok).
[Bug rtl-optimization/47477] [4.6 regression] Sub-optimal mov at end of method
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47477
--- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28
11:04:19 UTC ---
(In reply to comment #4)
Alternatively, this narrowing of word mode operations could as well be done
during tree optimizations. I think the FE is the only place which performs
them,
as can be seen if you modify your testcase to do:
void *
add (void *a, void *b)
{
return (void *)(__INTPTR_TYPE__) ((long long)(__INTPTR_TYPE__) a + ((long
long)(__INTPTR_TYPE__) b ~1L));
}
instead of
void *
add (void *a, void *b)
{
long long tmp = (long long)(__INTPTR_TYPE__) a + ((long
long)(__INTPTR_TYPE__) b ~1L);
return (void *)(__INTPTR_TYPE__) tmp;
}
But unfortunately we have nothing which performs this later on (gimple-fold?).
As it needs to combine several statements tree forwprop is our current
place to deal with this (as our tree combiner). Similar to the
new associate_plusminus code we should have combiners (not re-using fold)
to combine conversions.
[Bug debug/47510] New: DW_TAG_typedef can have children when designating a naming typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47510
Summary: DW_TAG_typedef can have children when designating a
naming typedef
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: do...@gcc.gnu.org
ReportedBy: do...@gcc.gnu.org
Consider this test case:
class C {
public:
C() {}
~C() {}
};
typedef struct {
C m;
} t;
typedef t s;
s v;
The DW_TAG_typedef DIE describing the typedef t has children DIEs. The
children DIEs are actually the DIEs representing the members of the
anonymous structure named by T.
What is happening is, since gen_typedef_die equates the anonymous
struct named by the typedef t with the DIE of the naming typedef,
get_context_die called with the type tree of the anonymous typedef
yields the DIE of the typedef.
[Bug middle-end/47496] HAS_DECL_ASSEMBLER_NAME_P and DECL_ASSEMBLER_NAME has some incosistency
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47496 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 11:12:52 UTC --- You should use if (HAS_DECL_ASSEMBLER_NAME_P (expr) DECL_ASSEMBLER_NAME_SET_P (expr)) DECL_ASSEMBLER_NAME (expr); calling decl_assembler_name on random things is not what you should do.
[Bug debug/47510] DW_TAG_typedef can have children when designating a naming typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47510 --- Comment #1 from Dodji Seketeli dodji at gcc dot gnu.org 2011-01-28 11:13:51 UTC --- Created attachment 23149 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23149 Candidate patch I am bootstrapping this patch at the moment.
[Bug fortran/47505] [OOP] Intrinsics which should operate on polymorphic objects (BT_CLASS)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47505 --- Comment #1 from janus at gcc dot gnu.org 2011-01-28 11:20:04 UTC --- I think the following ones should work fine (re-check?): * ALLOCATED * ASSOCIATED * EXTENDS_TYPE_OF * SAME_TYPE_AS * STORAGE_SIZE The array (+coarray?) intrinsics we can probably ignore for now, since we don't have polymorphic array support at this point. A few ones that are left to check might be: * MOVE_ALLOC * PRESENT * MERGE * ...?
[Bug middle-end/44554] Stack space after sigsetjmp is reused
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44554 --- Comment #19 from Ian Bolton ibolton at gcc dot gnu.org 2011-01-28 11:30:50 UTC --- (In reply to comment #18) (In reply to comment #17) gcc 4.4.5 was released in October. Please can you confirm if this is now fixed. I think THIS bug is fixed in 4.4.5. Unfortunately I've still problems with wrong computations as already mentioned in comment #8. But this would either be related to PR40386 or it's another bug. I think it's best to raise a new bug, and CC Vladimir Makarov and Jeff Law. It will help to hear about the specific issues you are still seeing within that bug report.
[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497 --- Comment #3 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 11:42:11 UTC --- Please specify the linker you are using and compile-flags you are using to build SPEC - you should know the information you gave is not enough to reproduce the problem.
[Bug rtl-optimization/44174] [4.4/4.5 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|i686-linux |i686-linux, ||i386-pc-solaris2.1[01] CC||ro at gcc dot gnu.org Known to fail||4.6.0 --- Comment #5 from Rainer Orth ro at gcc dot gnu.org 2011-01-28 11:59:27 UTC --- Between 20110121 and 20110127, the new gcc.target/i386/asm-6.c test started failing again on mainline (i386-pc-solaris2.1[01], 32-bit only): FAIL: gcc.target/i386/asm-6.c (test for excess errors) Excess errors: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/asm-6.c:14:3: error: can't find a register in class 'CLOBBERED_REGS' while reloading 'asm' /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.target/i386/asm-6.c:14:3: error: 'asm' operand has impossible constraints
[Bug c++/47511] New: [C++0x] ICE: unexpected ast of kind template_decl in potential_constant_expression_1, at cp/semantics.c:7711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47511
Summary: [C++0x] ICE: unexpected ast of kind template_decl in
potential_constant_expression_1, at
cp/semantics.c:7711
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: marc.gli...@normalesup.org
namespace N {
template typename T bool g( T ) {
return true;
}
struct A { };
}
template class T void f(const T) {
N::A x;
g(x) ;
}
$ c++ -std=gnu++0x -c a.cc
a.cc: In function 'void f(const T)':
a.cc:9:7: sorry, unimplemented: unexpected ast of kind template_decl
a.cc:9:7: internal compiler error: in potential_constant_expression_1, at
cp/semantics.c:7711
[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497 --- Comment #4 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 12:01:13 UTC --- Works for me with -O3 -ffast-math -funroll-loops and rpm -q binutils binutils-2.20.0-0.7.9 using gold as plugin-ld.
[Bug other/47512] New: ICE in queue_insn, at haifa-sched.c:1322
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47512 Summary: ICE in queue_insn, at haifa-sched.c:1322 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: j.j.vanderheij...@gmail.com worked: r169259 failed: r169260 Failed to bootstrap with an ICE while compiling natString.cc (libjava): janjaap@speedo:/xvm0/build/gcc/gcc-trunk/obj-irix6.5-no-lto/mips-sgi-irix6.5/64/libjava$ /build65/gcc/gcc-trunk/obj-irix6.5-no-lto/./gcc/xgcc -shared-libgcc -B/build65/gcc/gcc- trunk/obj-irix6.5-no-lto/./gcc -nostdinc++ -L/build65/gcc/gcc-trunk/obj-irix6.5-no-lto/mips-sgi-irix6.5/64/libstdc++-v3/src -L/build65/gcc/gcc-trunk/obj-irix6.5-no-lto/mips-sgi -irix6.5/64/libstdc++-v3/src/.libs -B/usr/local/gnu/mips-sgi-irix6.5/bin/ -B/usr/local/gnu/mips-sgi-irix6.5/lib/ -isystem /usr/local/gnu/mips-sgi-irix6.5/include -isystem /usr/ local/gnu/mips-sgi-irix6.5/sys-include -mabi=64 -DHAVE_CONFIG_H -I. -I/build65/gcc/gcc-trunk/src/libjava -I./include -I./gcj -I/build65/gcc/gcc-trunk/src/libjava -Iinclude -I/b uild65/gcc/gcc-trunk/src/libjava/include -I/build65/gcc/gcc-trunk/src/libjava/classpath/include -Iclasspath/include -I/build65/gcc/gcc-trunk/src/libjava/classpath/native/fdlibm -I/build65/gcc/gcc-trunk/src/libjava/../boehm-gc/include -I../boehm-gc/include -I/build65/gcc/gcc-trunk/src/libjava/libltdl -I/build65/gcc/gcc-trunk/src/libjava/libltdl -I/bui ld65/gcc/gcc-trunk/src/libjava/.././libjava/../gcc -I/build65/gcc/gcc-trunk/src/libjava/../zlib -I/build65/gcc/gcc-trunk/src/libjava/../libffi/include -I../libffi/include -fno- rtti -fnon-call-exceptions -fdollars-in-identifiers -Wswitch-enum -D_FILE_OFFSET_BITS=64 -Wextra -Wall -D_GNU_SOURCE -DPREFIX=\/usr/local/gnu\ -DTOOLEXECLIBDIR=\/usr/local/g nu/lib/../lib64\ -DJAVA_HOME=\/usr/local/gnu\ -DBOOT_CLASS_PATH=\/usr/local/gnu/share/java/libgcj-4.6.0.jar\ -DJAVA_EXT_DIRS=\/usr/local/gnu/share/java/ext\ -DGCJ_ENDORS ED_DIRS=\/usr/local/gnu/share/java/gcj-endorsed\ -DGCJ_VERSIONED_LIBDIR=\/usr/local/gnu/lib/../lib64/gcj-4.6.0-12\ -DPATH_SEPARATOR=\:\ -DECJ_JAR_FILE=\\ -DLIBGCJ_DEFAU LT_DATABASE=\/usr/local/gnu/lib/../lib64/gcj-4.6.0-12/classmap.db\ -DLIBGCJ_DEFAULT_DATABASE_PATH_TAIL=\gcj-4.6.0-12/classmap.db\ -g -O2 -mabi=64 -MT java/lang/natString.lo -MD -MP -MF java/lang/.deps/natString.Tpo -c /build65/gcc/gcc-trunk/src/libjava/java/lang/natString.cc -DPIC -o java/lang/.libs/natString.o -save-temps /build65/gcc/gcc-trunk/src/libjava/java/lang/natString.cc: In member function 'jint java::lang::String::indexOf(jstring, jint)': /build65/gcc/gcc-trunk/src/libjava/java/lang/natString.cc:832:1: internal compiler error: in queue_insn, at haifa-sched.c:1322 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Platform: mips-sgi-irix6.5 Build host: IRIX64 speedo 6.5 07202013 IP35 Operating system: IRIX 6.5 6.5.30f Configured with: /build65/gcc/gcc-trunk/src/configure -v --disable-werror --disable-lto --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --prefix=/usr/local/gnu --enable-shared --enable-threads=posix --enable-libgcj --enable-java-awt=xlib --disable-nls --with-gnu-as --with-as=/usr/local/gnu/mips-sgi-irix6.5/bin/as --without-gnu-ld --with-ld=/usr/bin/ld --with-arch-32=mips3 --with-tune-32=mips4 --with-arch-64=mips3 --with-tune-64=mips4 --with-mpfr-include=/usr/local/gnu/include --with-mpfr-lib=/usr/local/gnu/lib32 --enable-checking=release Using: GNU assembler (GNU Binutils) 2.21 Using: native linker Version 7.44.
[Bug rtl-optimization/44174] [4.4/4.5 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174 --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-28 12:36:54 UTC --- Between 20110121 and 20110127, the new gcc.target/i386/asm-6.c test started failing again on mainline (i386-pc-solaris2.1[01], 32-bit only): It probably never passed on Solaris.
[Bug other/47512] ICE in queue_insn, at haifa-sched.c:1322
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47512 --- Comment #1 from Jan-Jaap van der Heijden J.J.vanderHeijden at gmail dot com 2011-01-28 12:37:38 UTC --- Created attachment 23150 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23150 natString.ii
[Bug other/47512] ICE in queue_insn, at haifa-sched.c:1322
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47512 --- Comment #2 from Jan-Jaap van der Heijden J.J.vanderHeijden at gmail dot com 2011-01-28 12:38:13 UTC --- Created attachment 23151 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23151 natString.s
[Bug rtl-optimization/44174] [4.4/4.5 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174 --- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-01-28 12:40:52 UTC --- --- Comment #6 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-28 12:36:54 UTC --- Between 20110121 and 20110127, the new gcc.target/i386/asm-6.c test started failing again on mainline (i386-pc-solaris2.1[01], 32-bit only): It probably never passed on Solaris. You're right: I somehow misread the PR and though the test had already been introduced in november last year. Rainer
[Bug c/47400] Several UCN tests FAIL on Tru64 UNIX V5.1B and IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47400
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-01-26 15:33:03 UTC ---
From my reading of libiconv 1.13.1 libcharset/tools/{irix-6.5,
osf1-5.1}, it seems that there isn't any such locale. If this cannot be
helped, it seems that we should have some
dg-require-effective-target ascii-locale
(suggestions for a better name welcome) to disable the affected tests on
platforms like this.
Rainer
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-01-28 12:44:14 UTC ---
Rainer Orth r...@cebitec.uni-bielefeld.de writes:
From my reading of libiconv 1.13.1 libcharset/tools/{irix-6.5,
osf1-5.1}, it seems that there isn't any such locale. If this cannot be
helped, it seems that we should have some
dg-require-effective-target ascii-locale
(suggestions for a better name welcome) to disable the affected tests on
platforms like this.
Joseph, did you see that comment? The mail may not have gone out during
the Bugzilla/Perl snafu on gcc.gnu.org.
Anyway, on second thought this is a host, not a target issue, so this
should be something like dg-require-ascii-locale instead.
Rainer
[Bug c++/47513] New: [C++0x] [SFINAE] compiler rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47513
Summary: [C++0x] [SFINAE] compiler rejects valid code
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s.gesem...@gmail.com
I believe the following code should compile using the option -std=c++0x:
struct use_copy_ctor {};
struct prefer_clone_func : use_copy_ctor {};
templateclass T
auto clone(T const* ptr, prefer_clone_func)
- decltype(ptr-clone())
{ return ptr-clone(); }
templateclass T
auto clone(T const* ptr, use_copy_ctor)
- decltype(new T(*ptr))
{ return new T(*ptr); }
struct abc {
virtual ~abc() {}
virtual abc* clone() const =0;
};
struct derived : abc
{
derived* clone() const { return new derived(*this); }
};
int main()
{
derived d;
abc* p = d;
abc* q = clone(p,prefer_clone_func());
delete q;
}
As far as I can tell SFINAE applies during template argument deduction where
abc is substituted for T in decltype(new T(*ptr)). GCC complains about abc
being abstract -- which it is, of course -- but it should instead simply ignore
the second function template.
Related note: Assuming std::is_constructible is implemented in terms of
decltype, this would explain why std::is_constructible doesn't work either on
abstract class types.
[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Summary|[4.4/4.5 Regression] can't |[4.4/4.5/4.6 Regression] |find a register in class|can't find a register in |'CLOBBERED_REGS' while |class 'CLOBBERED_REGS' |reloading 'asm' |while reloading 'asm' --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-28 12:45:43 UTC --- You're right: I somehow misread the PR and though the test had already been introduced in november last year. It did pass with GCC 4.3 on Solaris too so this is a regression. Can you XFAIL it on Solaris for the time being?
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 --- Comment #5 from Peter Bergner bergner at gcc dot gnu.org 2011-01-28 12:48:34 UTC --- I assume the binutils 2.11 and 2.10 versions are typos and you meant 2.21 and 2.20? I'll fire off a build using your configure options and report back.
[Bug libfortran/47514] New: Source file over a certain size compiles but will not run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47514 Summary: Source file over a certain size compiles but will not run Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: brendanarn...@gmail.com Created attachment 23152 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23152 Source files mentioned in the report It seems there is a limit between 200kB and 500kB ish or perhaps the number of labels for FORMAT statements that causes source file 'a.f' to run fine but source file 'b.f' to crash. Note that both compile with no warnings/errors with '-Wall' enabled. Performed on Windows, gfortran 4.4.1. For comparison, both compile and run fine on Intel Linux using ifort 9.1
[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174
--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-01-28 13:04:36 UTC ---
--- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-28
12:45:43 UTC ---
You're right: I somehow misread the PR and though the test had already
been introduced in november last year.
It did pass with GCC 4.3 on Solaris too so this is a regression. Can you
XFAIL
it on Solaris for the time being?
Sure. The following patch does this:
2011-01-28 Rainer Orth r...@cebitec.uni-bielefeld.de
* gcc.target/i386/asm-6.c: XFAIL on i?86-pc-solaris2.1[0-9] ilp32.
diff -r a1670fd752ff gcc/testsuite/gcc.target/i386/asm-6.c
--- a/gcc/testsuite/gcc.target/i386/asm-6.cThu Jan 27 20:26:26 2011 +0100
+++ b/gcc/testsuite/gcc.target/i386/asm-6.cFri Jan 28 14:03:13 2011 +0100
@@ -3,6 +3,7 @@
/* { dg-do compile } */
/* { dg-options -O2 -fpic { target fpic } } */
+/* { dg-xfail-if { i?86-pc-solaris2.1[0-9] ilp32 } } */
int f0 (int, int, int, int, int);
int f1 (void);
Ok for mainline (I'll post to gcc-patches anyway)?
Rainer
[Bug libfortran/47514] Source file over a certain size compiles but will not run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47514 --- Comment #1 from Joost VandeVondele Joost.VandeVondele at pci dot uzh.ch 2011-01-28 13:33:41 UTC --- could be windows specific, since both testcases run fine here (x86_64-unknown-linux-gnu), with 4.3, 4.5 and 4.6
[Bug libfortran/47514] Source file over a certain size compiles but will not run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47514 Brendan brendanarnold at gmail dot com changed: What|Removed |Added Host||Windows XP - SP3 - Intel - ||MinGW Version|4.4.1 |4.4.0 --- Comment #2 from Brendan brendanarnold at gmail dot com 2011-01-28 13:40:06 UTC --- Here are some more details - note: I made a mistake with the version number is 4.4.0 not 4.4.1 C:\Documents and Settings\ba1224\Desktop\New Folder gfortran -v Using built-in specs. Target: mingw32 Configured with: ../gcc-4.4.0/configure --enable-languages=c,ada,c++,fortran,java,objc,obj-c++ --disable-sjlj-exceptions --enable-shared --enable-libgcj --enable-libgomp --with-dwarf2 --disable-win32-registry --enable-libstdcxx-debug --enable-version-specific-runtime-libs --prefix=/mingw --with-gmp=/mingw/src/gmp/root --with-mpfr=/mingw/src/mpfr/root --build=mingw32 Thread model: win32 gcc version 4.4.0 (GCC)
[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497 --- Comment #5 from H.J. Lu hjl.tools at gmail dot com 2011-01-28 13:46:06 UTC --- (In reply to comment #3) Please specify the linker you are using and compile-flags you are using to build SPEC - you should know the information you gave is not enough to reproduce the problem. I used -DSPEC_CPU -DNDEBUG -O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU_LP64 -fno-strict-aliasing I got the same error with gold 1.11 from CVS: # /export/regression/rrs/169284/usr/bin/g++ -B./ -O2 -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU_LP64 changesoplex.o didxset.o dsvector.o dvector.o enter.o example.o factor.o forest.o idxset.o leave.o lpcolset.o lprow.o lprowset.o message.o mpsinput.o nameset.o slufactor.o solve.o soplex.o spxaggregatesm.o spxbasis.o spxbounds.o spxchangebasis.o spxdefaultpr.o spxdefaultrt.o spxdefines.o spxdesc.o spxdevexpr.o spxequilisc.o spxfastrt.o spxgeneralsm.o spxharrisrt.o spxhybridpr.o spxid.o spxio.o spxlp.o spxlpfread.o spxmpsread.o spxmpswrite.o spxparmultpr.o spxquality.o spxredundantsm.o spxrem1sm.o spxscaler.o spxshift.o spxsolve.o spxsolver.o spxstarter.o spxsteeppr.o spxsumst.o spxvecs.o spxvectorst.o spxweightpr.o spxweightst.o ssvector.o svector.o svset.o timer.o unitvector.o update.o updatevector.o vector.o vsolve.o -o soplex /usr/local/bin/ld: /tmp/ccZ4RILg.ltrans8.ltrans.o: in function non-virtual thunk to soplex::SoPlex::~SoPlex():ccZ4RILg.ltrans8.o(.text._ZN6soplex6SoPlexD1Ev+0x8): error: undefined reference to '.LTHUNK0.11251' collect2: ld returned 1 exit status GCC is configured to use ppl-0.11 and cloog-0.16.1 with --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld --enable-shared --enable-threads=posix --enable-haifa --enable-checking --enable-languages=c,c++,fortran --enable-cloog-backend=isl --with-ppl-include=/opt/gnu/include --with-ppl-lib=/opt/gnu/lib64 --with-cloog-include=/opt/gnu/include --with-cloog-lib=/opt/gnu/lib64
[Bug go/47515] New: Issues porting libgo to IRIX 6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47515
Summary: Issues porting libgo to IRIX 6.5
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
AssignedTo: i...@airs.com
ReportedBy: r...@gcc.gnu.org
Host: mips-sgi-irix6.5
Target: mips-sgi-irix6.5
Build: mips-sgi-irix6.5
I just started a quick attempt porting libgo to IRIX 6.5. Here are the issues
I've found so far:
* runtime/mem.c fails to compile:
/vol/gcc/src/hg/trunk/irix/libgo/runtime/mem.c: In function 'runtime_SysAlloc':
/vol/gcc/src/hg/trunk/irix/libgo/runtime/mem.c:12:59: error: 'MAP_ANON'
undeclared (first use in this function)
/vol/gcc/src/hg/trunk/irix/libgo/runtime/mem.c:12:59: note: each undeclared
identifier is reported only once for each function it appears in
/vol/gcc/src/hg/trunk/irix/libgo/runtime/mem.c: In function
'runtime_SysMemInit':
/vol/gcc/src/hg/trunk/irix/libgo/runtime/mem.c:49:47: error: 'MAP_ANON'
undeclared (first use in this function)
make[4]: *** [mem.lo] Error 1
One could mmap /dev/zero instead, cf. gcc/acinclude.m4, gcc/ggc-{page,
zone}.c
* Of course, support for IRIX needs to be added to configure.ac and
Makefile.am.
* Several new OS-dependent files will be needed.
* Building libgo still depends on a linker supporting --whole-archive, but SGI
ld doesn't and GNU ld doesn't work due to PR target/43533.
* The dependency on objcopy needs at least to be documented in install.texi,
but
even better avoided.
* CC_FOR_BUILD, CFLAGS_FOR_BUILD are only passed in from toplevel, but if
one runs make in target/libgo, it fails in strange ways.
* I get several warnings from go1:
go1: warning: visibility attribute not supported in this configuration; ignored
[-Wattributes]
It would be good to only use protected visibility if the target supports
that.
Given the --whole-archive issue, I'll stop working on this for now, but could
probably deal with the rest if this is sorted out.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #8 from Paul Thomas pault at gcc dot gnu.org 2011-01-28 13:53:25 UTC --- Author: pault Date: Fri Jan 28 13:53:19 2011 New Revision: 169356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169356 Log: 2011-01-28 Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@gcc.gnu.org PR fortran/45170 PR fortran/35810 PR fortran/47350 * interface.c (compare_actual_formal): An allocatable or pointer deferred length actual is only allowed if the formal argument is also deferred length. Clean up whitespace. * trans-expr.c (gfc_conv_procedure_call): Pass string length for deferred character length formal arguments by reference. Do the same for function results. (gfc_trans_pointer_assignment): Do not do runtime check of lhs and rhs character lengths, if deferred length lhs. In this case set the lhs character length to that of the rhs. (gfc_conv_string_parameter): Remove assert that string length is an integer type. (is_scalar_reallocatable_lhs): New function. (alloc_scalar_allocatable_for_assignment): New function. (gfc_trans_assignment_1): Call above new function. If the rhs is a deferred character length itself, makes ure that the function is called before reallocation, so that the length is available. (gfc_trans_asssignment): Remove error about assignment to deferred length character variables. * gfortran.texi : Update entry about (re)allocation on assignment. * trans-stmt.c (gfc_trans_allocate): Add code to handle deferred length character variables. * module.c (mio_typespec): Transfer deferred characteristic. * trans-types.c (gfc_get_function_type): New code to generate hidden typelist, so that those character lengths that are passed by reference get the right type. * resolve.c (resolve_contained_fntype): Supress error for deferred character length functions. (resolve_function, resolve_fl_procedure) The same. (check_symbols): Remove the error that support for entity with deferred type parameter is not yet implemented. (resolve_fl_derived): The same. match.c (alloc_opt_list): Allow MOLD for deferred length object. * trans-decl.c (gfc_get_symbol_decl): For deferred character length dummies, generate a local variable for string length. (create_function_arglist): Hidden length can be a pointer. (gfc_trans_deferred_vars): For deferred character length results and dummies, assign the string length to the local variable from the hidden argument on entry and the other way round on exit, as appropriate. 2011-01-28 Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@gcc.gnu.org PR fortran/45170 PR fortran/35810 PR fortran/47350 * gfortran.dg/realloc_on_assign_3.f03: New test. * gfortran.dg/realloc_on_assign_4.f03: New test. * gfortran.dg/realloc_on_assign_5.f90: New test. * gfortran.dg/allocatable_function_5.f90: New test. * gfortran.dg/allocate_deferred_char_scalar_1.f90: New test. * gfortran.dg/deferred_type_param_2.f90: Remove two not yet implemented dg-errors. Added: trunk/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_3.f03 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/deferred_type_param_2.f90
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810 --- Comment #14 from Paul Thomas pault at gcc dot gnu.org 2011-01-28 13:53:25 UTC --- Author: pault Date: Fri Jan 28 13:53:19 2011 New Revision: 169356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169356 Log: 2011-01-28 Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@gcc.gnu.org PR fortran/45170 PR fortran/35810 PR fortran/47350 * interface.c (compare_actual_formal): An allocatable or pointer deferred length actual is only allowed if the formal argument is also deferred length. Clean up whitespace. * trans-expr.c (gfc_conv_procedure_call): Pass string length for deferred character length formal arguments by reference. Do the same for function results. (gfc_trans_pointer_assignment): Do not do runtime check of lhs and rhs character lengths, if deferred length lhs. In this case set the lhs character length to that of the rhs. (gfc_conv_string_parameter): Remove assert that string length is an integer type. (is_scalar_reallocatable_lhs): New function. (alloc_scalar_allocatable_for_assignment): New function. (gfc_trans_assignment_1): Call above new function. If the rhs is a deferred character length itself, makes ure that the function is called before reallocation, so that the length is available. (gfc_trans_asssignment): Remove error about assignment to deferred length character variables. * gfortran.texi : Update entry about (re)allocation on assignment. * trans-stmt.c (gfc_trans_allocate): Add code to handle deferred length character variables. * module.c (mio_typespec): Transfer deferred characteristic. * trans-types.c (gfc_get_function_type): New code to generate hidden typelist, so that those character lengths that are passed by reference get the right type. * resolve.c (resolve_contained_fntype): Supress error for deferred character length functions. (resolve_function, resolve_fl_procedure) The same. (check_symbols): Remove the error that support for entity with deferred type parameter is not yet implemented. (resolve_fl_derived): The same. match.c (alloc_opt_list): Allow MOLD for deferred length object. * trans-decl.c (gfc_get_symbol_decl): For deferred character length dummies, generate a local variable for string length. (create_function_arglist): Hidden length can be a pointer. (gfc_trans_deferred_vars): For deferred character length results and dummies, assign the string length to the local variable from the hidden argument on entry and the other way round on exit, as appropriate. 2011-01-28 Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@gcc.gnu.org PR fortran/45170 PR fortran/35810 PR fortran/47350 * gfortran.dg/realloc_on_assign_3.f03: New test. * gfortran.dg/realloc_on_assign_4.f03: New test. * gfortran.dg/realloc_on_assign_5.f90: New test. * gfortran.dg/allocatable_function_5.f90: New test. * gfortran.dg/allocate_deferred_char_scalar_1.f90: New test. * gfortran.dg/deferred_type_param_2.f90: Remove two not yet implemented dg-errors. Added: trunk/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_3.f03 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/deferred_type_param_2.f90
[Bug fortran/47350] Deferred string length: ALLOCATE should allow MOLD=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47350 --- Comment #1 from Paul Thomas pault at gcc dot gnu.org 2011-01-28 13:53:25 UTC --- Author: pault Date: Fri Jan 28 13:53:19 2011 New Revision: 169356 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=169356 Log: 2011-01-28 Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@gcc.gnu.org PR fortran/45170 PR fortran/35810 PR fortran/47350 * interface.c (compare_actual_formal): An allocatable or pointer deferred length actual is only allowed if the formal argument is also deferred length. Clean up whitespace. * trans-expr.c (gfc_conv_procedure_call): Pass string length for deferred character length formal arguments by reference. Do the same for function results. (gfc_trans_pointer_assignment): Do not do runtime check of lhs and rhs character lengths, if deferred length lhs. In this case set the lhs character length to that of the rhs. (gfc_conv_string_parameter): Remove assert that string length is an integer type. (is_scalar_reallocatable_lhs): New function. (alloc_scalar_allocatable_for_assignment): New function. (gfc_trans_assignment_1): Call above new function. If the rhs is a deferred character length itself, makes ure that the function is called before reallocation, so that the length is available. (gfc_trans_asssignment): Remove error about assignment to deferred length character variables. * gfortran.texi : Update entry about (re)allocation on assignment. * trans-stmt.c (gfc_trans_allocate): Add code to handle deferred length character variables. * module.c (mio_typespec): Transfer deferred characteristic. * trans-types.c (gfc_get_function_type): New code to generate hidden typelist, so that those character lengths that are passed by reference get the right type. * resolve.c (resolve_contained_fntype): Supress error for deferred character length functions. (resolve_function, resolve_fl_procedure) The same. (check_symbols): Remove the error that support for entity with deferred type parameter is not yet implemented. (resolve_fl_derived): The same. match.c (alloc_opt_list): Allow MOLD for deferred length object. * trans-decl.c (gfc_get_symbol_decl): For deferred character length dummies, generate a local variable for string length. (create_function_arglist): Hidden length can be a pointer. (gfc_trans_deferred_vars): For deferred character length results and dummies, assign the string length to the local variable from the hidden argument on entry and the other way round on exit, as appropriate. 2011-01-28 Paul Thomas pa...@gcc.gnu.org Tobias Burnus bur...@gcc.gnu.org PR fortran/45170 PR fortran/35810 PR fortran/47350 * gfortran.dg/realloc_on_assign_3.f03: New test. * gfortran.dg/realloc_on_assign_4.f03: New test. * gfortran.dg/realloc_on_assign_5.f90: New test. * gfortran.dg/allocatable_function_5.f90: New test. * gfortran.dg/allocate_deferred_char_scalar_1.f90: New test. * gfortran.dg/deferred_type_param_2.f90: Remove two not yet implemented dg-errors. Added: trunk/gcc/testsuite/gfortran.dg/allocate_deferred_char_scalar_1.f03 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_3.f03 trunk/gcc/testsuite/gfortran.dg/realloc_on_assign_4.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/interface.c trunk/gcc/fortran/match.c trunk/gcc/fortran/module.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/fortran/trans-types.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/deferred_type_param_2.f90
[Bug lto/47497] [4.6 Regression] SPEC CPU 2006 failed to link with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47497 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.28 14:07:32 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 14:07:32 UTC --- I can reproduce it. It seems to be an interaction of -fuse-linker-plugin and -fwhole-program. The combinations -fuse-linker-plugin and -fwhole-program -fno-use-linker-plugin work ok. I think mixing linker-plugin and whole-program does not make much sense (linker-plugin provides a more precise whole-program idea). Honza? Why is -fwhole-program not ignored, or why should it not be? Why does it make a difference at all here? I can't see how the patch should cause this btw, eventually it leads to different linker resolutions(?) or to different partitioning decisions. The issue also reproduces with -flto-partition=1to1 (but not with =none, though that doesn't go through the WPA path).
[Bug other/46567] [trans-mem] ipa_tm_decrement_clone_counts ICE at -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46567 --- Comment #5 from Patrick Marlier patrick.marlier at gmail dot com 2011-01-28 14:18:45 UTC --- Created attachment 23153 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23153 testcase with O0 With this testcase and -O0: $ gcc -fgnu-tm -O0 -S pr46567-2.i -o testcase.s pr46567-2.i: In function ‘readLoop’: pr46567-2.i:18:1: internal compiler error: in ipa_tm_decrement_clone_counts, at trans-mem.c:3748 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. Maybe not related to this bug?
[Bug rtl-optimization/44174] [4.4/4.5/4.6 Regression] can't find a register in class 'CLOBBERED_REGS' while reloading 'asm'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44174 --- Comment #10 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-28 14:29:30 UTC --- Ok for mainline (I'll post to gcc-patches anyway)? Sure, thanks.
[Bug rtl-optimization/47454] registers are not allocated according to its preferred order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47454 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-01-28 14:36:26 UTC --- I have thought about doing work in IRA to address this, so that we impose a higher cost for the higher registers if we have not yet ventured into them. -frename-registers should help for this issue on the ARM.
[Bug c++/47513] [C++0x] [SFINAE] compiler rejects valid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47513 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.28 14:43:43 Ever Confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-28 14:43:43 UTC --- I think you're right - so confirmed
[Bug debug/47508] [4.6 Regression] -fcompare-debug failure with -ftracer for pr42918.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47508 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Target|arm-eabi|arm-eabi, ||sparc-sun-solaris2.11 CC||ro at gcc dot gnu.org --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-01-28 14:45:45 UTC --- Between 20110121 and 20110127, the test also started to FAIL on Solaris 11/SPARC (both 32 and 64-bit): FAIL: gcc.dg/pr42918.c (test for excess errors) Excess errors: xgcc: error: /vol/gcc/src/hg/trunk/local/gcc/testsuite/gcc.dg/pr42918.c: -fcompare-debug failure
[Bug fortran/47350] Deferred string length: ALLOCATE should allow MOLD=
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47350 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-28 14:52:58 UTC --- FIXED for the 4.6 trunk.
[Bug debug/47508] [4.6 Regression] -fcompare-debug failure with -ftracer for pr42918.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47508 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||aoliva at gcc dot gnu.org, ||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-28 14:57:10 UTC --- Likely the same problem as PR47498 and PR47501.
[Bug fortran/47516] New: ICE with reallocate on assignment w/ --disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47516 Summary: ICE with reallocate on assignment w/ --disable-bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org, ja...@gcc.gnu.org Moved from bug 35810 comment 12. Janus wrote there the following; I have not tried to confirm it. Bug 35810 Comment 12 janus 2010-12-30 13:18:14 CET - Note: realloc_on_assign_2.f03 fails on current trunk when building with --disable-bootstrap (system compiler: gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292]): realloc_on_assign_2.f03: In function ‘test5’: realloc_on_assign_2.f03:101:0: internal compiler error: in fold_convert_loc, at fold-const.c:1906 Reduced test case: program test5 real, allocatable, dimension (:,:) :: xwrkt xwrkt = trs2a2 () contains function trs2a2 () real, dimension (1:2,1:2) :: trs2a2 trs2a2 = 0.0 end function end
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810 --- Comment #15 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-28 14:59:03 UTC --- Close as FIXED (for the 4.6 trunk). Left overs: - ICE mentioned in comment 12 - now PR 47516 - Assignment to polymorphic LHS, PR 43366
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-28 14:59:46 UTC --- really mark as FIXED.
[Bug target/44031] [4.4/4.5 Regression] ice in subst_reloads, at reload.c:6327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #9 from Mikael Pettersson mikpe at it dot uu.se 2011-01-28 15:02:42 UTC --- This test case stopped failing on 4.6 with r162726: Author: bernds Date: Fri Jul 30 23:50:00 2010 New Revision: 162726 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162726 Log: * rtlanal.c (simplify_subreg_regno): Don't treat HARD_FRAME_POINTER_REGNUM specially. Modified: trunk/gcc/ChangeLog trunk/gcc/rtlanal.c See also http://gcc.gnu.org/ml/gcc-patches/2010-07/msg00756.html
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 15:10:00 UTC --- Yes, the versions were typos. I seem to have been just unlucky with the specific host compiler version (I was then stuck with), building a current snapshot with 4.5 and using that built snapshot to build itself seems to work fine now (I'm now past the failure point and into stage2).
[Bug fortran/47516] ICE with reallocate on assignment w/ --disable-bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47516 --- Comment #1 from paul.richard.thomas at gmail dot com paul.richard.thomas at gmail dot com 2011-01-28 15:14:24 UTC --- gcc version 4.5.0 20100604??? version is marked as 4.6.0 Paul On Fri, Jan 28, 2011 at 3:59 PM, burnus at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47516 Summary: ICE with reallocate on assignment w/ --disable-bootstrap Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org, ja...@gcc.gnu.org Moved from bug 35810 comment 12. Janus wrote there the following; I have not tried to confirm it. Bug 35810 Comment 12 janus 2010-12-30 13:18:14 CET - Note: realloc_on_assign_2.f03 fails on current trunk when building with --disable-bootstrap (system compiler: gcc version 4.5.0 20100604 [gcc-4_5-branch revision 160292]): realloc_on_assign_2.f03: In function ‘test5’: realloc_on_assign_2.f03:101:0: internal compiler error: in fold_convert_loc, at fold-const.c:1906 Reduced test case: program test5 real, allocatable, dimension (:,:) :: xwrkt xwrkt = trs2a2 () contains function trs2a2 () real, dimension (1:2,1:2) :: trs2a2 trs2a2 = 0.0 end function end -- Configure bugmail: http://gcc.gnu.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are on the CC list for the bug.
[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325 --- Comment #13 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-01-28 15:15:37 UTC --- Is this going to be fixed for 4.6.0 or should we XFAIL the test? This PR has been open for 5 months now. Rainer
[Bug fortran/47517] New: Rallocate on assignment: Segfault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47517 Summary: Rallocate on assignment: Segfault Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org Created attachment 23154 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23154 James' allocate_assign.f90 Follow up to bug 35810 comment 0. The following program ends with a segfault and works with ifort (-assume realloc_lhs). I do not know whether the program is valid. Cf. also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7d5d1e7f4a48071c/7c63fef65ba5ea70?lnk=gstq=realloc_lhs The attached program - which is James program from c.l.f except that I drastically reduced the loop count and removed some line wraps, causes a segfault in gfortran. [...] x2(3)%headers(5)%parts = 1,2,3,4,5,6 size(x2(3)%headers(6)%parts) = 6 x2(3)%headers(6)%parts = 1,2,3,4,5,6 10 Segmentation fault (core dumped) Result with ifort -assume realloc_lhs: x2(3)%headers(5)%parts = 1,2,3,4,5,6 size(x2(3)%headers(6)%parts) = 6 x2(3)%headers(6)%parts = 1,2,3,4,5,6 1 0 1 0 1 2 [...] 1 39998 1 39998 4
[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325
--- Comment #14 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28
15:19:23 UTC ---
The test is invalid on i[345]86-*-* without also enabling -msse. A fix is to
add
/* { dg-options -msse { target i[345]86-*-* } } */
probably also for x86_64 with -m32. Or simply unconditionally as it is a
x86 specific test anyway.
A fix for the bug would instead issue a diagnostic.
[Bug c/47518] New: va_arg causes segmentation fault in case of variable length argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47518 Summary: va_arg causes segmentation fault in case of variable length argument Product: gcc Version: 4.2.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jur.p...@gmail.com To reproduce: gcc -Wall -g aap.c a.out Output: Segmentation fault (core dumped) Valgrind output ==4442== Memcheck, a memory error detector ==4442== Copyright (C) 2002-2009, and GNU GPL'd, by Julian Seward et al. ==4442== Using Valgrind-3.5.0 and LibVEX; rerun with -h for copyright info ==4442== Command: a.out ==4442== ==4442== Invalid read of size 1 ==4442==at 0x4C7E849: memcpy (mc_replace_strmem.c:482) ==4442==by 0x8048423: f (aap.c:19) ==4442==by 0x80484F4: main (aap.c:36) ==4442== Address 0x1ff is not stack'd, malloc'd or (recently) free'd Version information: Reading specs from /sysmnt/cadappl_linuxi386_nsvr1/gcc/4.2.2.1/bin/../lib/gcc/i686-pc-linux-gnu/4.2.2/specs Target: i686-pc-linux-gnu Configured with: /home/gcc/gcc/gcc-4.2.2.1/gcc-4.2.2.1/configure --prefix=/cadappl/gcc/4.2.2.1 --with-as=/cadappl/gcc/4.2.2.1/bin/as --with-ld=/cadappl/gcc/4.2.2.1/bin/ld --enable-__cxa_atexit --enable-threads=posix --with-march=i686 --with-tune=pentium4 --enable-languages=c,c++,fortran --with-gmp=/cadappl/gcc/4.2.2.1 --with-mpfr=/cadappl/gcc/4.2.2.1 Thread model: posix gcc version 4.2.2
[Bug c/47518] va_arg causes segmentation fault in case of variable length argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47518 --- Comment #1 from jur.pauw at gmail dot com 2011-01-28 15:26:41 UTC --- If gcc version 3.4.4 is used then the program executes correctly. Version information: Reading specs from /sysmnt/cadappl_linuxi386_nsvr1/gcc/3.4.4/bin/../lib/gcc/i686-pc-linux-gnu/3.4.4/specs Configured with: /home/gcc/gcc/gcc-3.4.4/gcc-3.4.4/configure --prefix=/cadappl/gcc/3.4.4 --enable-shared --enable-threads=posix --enable-__cxa_atexit --with-as=/cadappl/gcc/3.4.4/bin/as --with-ld=/cadappl/gcc/3.4.4/bin/ld --enable-languages=c,c++,f77,java Thread model: posix gcc version 3.4.4
[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325 --- Comment #15 from Dave Korn davek at gcc dot gnu.org 2011-01-28 15:28:33 UTC --- (In reply to comment #14) The test is invalid on i[345]86-*-* without also enabling -msse. Does the same apply to libcpp/lex.c? i.e. Is that code invalid unless compiled with -msse2? LTO bootstrap with arch=i686,tune=generic was still broken last time I checked.
[Bug fortran/47519] New: ICE on allocation of with deferred-length string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47519
Summary: ICE on allocation of with deferred-length string
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: pa...@gcc.gnu.org
Follow up to deferred-length string PR 45170.
Part of the thread referenced at bug 35810 comment 0,
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/7d5d1e7f4a48071c/7c63fef65ba5ea70?lnk=gstq=realloc_lhs
The following code of James ICEs with the current trunk:
foo.f90: In function ‘note7_35’:
foo.f90:9:0: internal compiler error: Segmentation fault
==7086== Invalid read of size 8
==7086==at 0x5B1C46: gfc_trans_allocate (trans-stmt.c:4527)
==7086==by 0x5656E7: trans_code (trans.c:1323)
==7086==by 0x583D91: gfc_generate_function_code (trans-decl.c:4708)
==7086==by 0x527CB7: gfc_parse_file (parse.c:4237)
==7086==by 0x560D75: gfc_be_parse_file (f95-lang.c:250)
==7086==by 0x867FCB: toplev_main (toplev.c:579)
==7086==by 0x64C7BBC: (below main) (libc-start.c:226)
==7086== Address 0x0 is not stack'd, malloc'd or (recently) free'd
In the last line of the following (shortened) excerpt the ICE happens:
else if (al-expr-ts.type == BT_CHARACTER
al-expr-ts.deferred code-expr3)
{
if (!code-expr3-ts.u.cl-backend_decl)
{
if (code-expr3-expr_type == EXPR_VARIABLE
|| code-expr3-expr_type == EXPR_CONSTANT)
else
{
gfc_conv_expr (se_sz, code-ext.alloc.ts.u.cl-length);
program note7_35
implicit none
character, allocatable :: name*(:)
character(*), parameter :: FIRST_NAME = 'Julius'
character(*), parameter :: SURNAME = 'No'
integer n
n = 10
allocate(name, SOURCE=repeat('x',n))
name = 'Dr. '//FIRST_NAME//' '//SURNAME
write(*,*) len(name), name
deallocate(name)
n = 10
allocate(name, SOURCE=repeat('x',n))
name(:) = 'Dr. '//FIRST_NAME//' '//SURNAME
write(*,*) len(name), name
end program note7_35
[Bug target/45325] [4.6 Regression] target attribute doesn't work with -march=i586
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325 --- Comment #16 from rguenther at suse dot de rguenther at suse dot de 2011-01-28 15:32:50 UTC --- On Fri, 28 Jan 2011, davek at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45325 --- Comment #15 from Dave Korn davek at gcc dot gnu.org 2011-01-28 15:28:33 UTC --- (In reply to comment #14) The test is invalid on i[345]86-*-* without also enabling -msse. Does the same apply to libcpp/lex.c? i.e. Is that code invalid unless compiled with -msse2? LTO bootstrap with arch=i686,tune=generic was still broken last time I checked. Yes. The code should be #ifdefed out when -msse is not enabled. Richard.
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-28 15:35:02 UTC --- TODO: - Function result variables which are character(len=:), pointer (according to http://gcc.gnu.org/ml/fortran/2011-01/msg00264.html item (v)) - Deferred-length string ARRAYS have still some issues - Deferred-length string as derived-type COMPONENTS are unimplemented - PR 47519 is an ICE
[Bug fortran/35810] [TR 15581 / F2003] Automatic reallocation on assignment to allocatable variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35810 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-28 15:35:05 UTC --- Another follow up: Bug 47517 - the example from c.l.f linked to from comment 0 fails
[Bug c/47518] va_arg causes segmentation fault in case of variable length argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47518 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.01.28 15:38:53 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-28 15:38:53 UTC --- please see http://gcc.gnu.org/bugs/ we need preprocessed source
[Bug c/47518] va_arg causes segmentation fault in case of variable length argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47518 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-01-28 15:39:50 UTC --- Also note that gcc 4.2 is no longer maintained, so even if there is a bug in that version it won't get fixed. Please try a newer release.
[Bug c/47520] New: [trans-mem] ICE Segmentation fault at 01
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47520 Summary: [trans-mem] ICE Segmentation fault at 01 Product: gcc Version: trans-mem Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: patrick.marl...@gmail.com CC: r...@gcc.gnu.org, al...@gcc.gnu.org, javier.ar...@bsc.es Created attachment 23155 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23155 testcase with O1 Hi, Reporting a bug found using RMSTM benchmark and optimization level 1. Attached a reduced test case. gcc -fgnu-tm -O1 -S hmmer-2.i hmmer-2.i: In function ‘ReadSeq’: hmmer-2.i:26:1: 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. Patrick.
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 Alan Modra amodra at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | --- Comment #7 from Alan Modra amodra at gmail dot com 2011-01-28 15:45:37 UTC --- Is the older 4.6 snapshot compiler still around on your system? If so, I'd really like to investigate the linker error, to make sure that powerpc64 ld isn't doing something stupid with toc partitioning..
[Bug bootstrap/47279] Bootstrap fails in stage1 with GCC 4.6
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47279 --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 15:48:08 UTC --- I don't have binaries anymore but it was built from SVN rev. 167488. So using a gcc 4.6 with that revision as host compiler should reproduce the problem.
[Bug c/47518] va_arg causes segmentation fault in case of variable length argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47518 --- Comment #4 from jur.pauw at gmail dot com 2011-01-28 15:54:10 UTC --- Created attachment 23156 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23156 preprocessed output that triggers va_arg segmentation fault
[Bug c/47518] va_arg causes segmentation fault in case of variable length argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47518 jur.pauw at gmail dot com changed: What|Removed |Added Version|4.2.2 |4.4.5 --- Comment #5 from jur.pauw at gmail dot com 2011-01-28 15:55:25 UTC --- Using built-in specs. Target: i686-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.4.4-14ubuntu5' --with-bugurl=file:///usr/share/doc/gcc-4.4/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.4 --enable-shared --enable-multiarch --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.4 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-targets=all --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu Thread model: posix gcc version 4.4.5 (Ubuntu/Linaro 4.4.4-14ubuntu5)
[Bug libfortran/47514] Source file over a certain size compiles but will not run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47514 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jvdelisle at gcc dot ||gnu.org Resolution||WORKSFORME --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-01-28 15:59:19 UTC --- I tried on windows with Cygwin and it works fine. Your version is really pretty old. I suggest you upgrade to a newer version. Closing as worksforme
[Bug c/47518] va_arg causes segmentation fault in case of variable length argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47518 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #6 from Richard Guenther rguenth at gcc dot gnu.org 2011-01-28 16:00:35 UTC --- You are using a different type for va_arg than you passed to the function.
[Bug debug/47510] DW_TAG_typedef can have children when designating a naming typedef
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47510 --- Comment #2 from Dodji Seketeli dodji at gcc dot gnu.org 2011-01-28 16:13:07 UTC --- Patch posted to http://gcc.gnu.org/ml/gcc-patches/2011-01/msg02118.html
[Bug c++/47049] [4.5/4.6 Regression] [C++0x] ICE in write_unnamed_type_name with lambda use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47049
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-28
16:33:07 UTC ---
Reduced testcase:
enum { E = 0, F = 1 };
template int N, int M = ((N == 1) ? F : E) class S;
template int N
struct T
{
static void
foo (SN *p)
{
SN u;
[u] ()-bool {};
}
};
[Bug libfortran/47514] Source file over a certain size compiles but will not run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47514 --- Comment #4 from Brendan brendanarnold at gmail dot com 2011-01-28 16:52:12 UTC --- Was using the MinGW bundled with PythonXY Now upgraded to version 4.5.2 and it works fine Thanks!
[Bug rtl-optimization/46235] inefficient bittest code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235 --- Comment #2 from Tony Poppleton tony.poppleton at gmail dot com 2011-01-28 16:55:48 UTC --- Based on Richard's comment, I tried a modified version of the code replacing the (1 x) with just (16). This shows that GCC (4.6 4.5.2) does perform an optimization similar to llvm, and uses the testb instruction: movl%edi, %eax movl$1, %edx testb $16, %al cmove %edx, %eax ret Therefore, perhaps it would be beneficial to not convert from a (n x) to (a x) n, in the special case where the value n is 1 (or a power of 2 potentially)? Incidentally, the above code could have been optimized further to remove the usage of edx entirely (will make a separate PR about that)
[Bug ada/47500] -G0 option not recognized by gnat1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47500 --- Comment #2 from Joel Sherrill joel at gcc dot gnu.org 2011-01-28 16:56:34 UTC --- (In reply to comment #1) Hints or tiny patch appreciated. You need to find out whether/how this works for the C compiler. What do you mean? It dictates the maximum size of objects placed in sbss and sdata sections. So -Gnumber is accepted by cc1.
[Bug rtl-optimization/46235] inefficient bittest code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235 --- Comment #3 from Tony Poppleton tony.poppleton at gmail dot com 2011-01-28 17:02:50 UTC --- Actually what I said above isn't correct - had it compiled down to bt $4, %al then it would make sense to do that special case, but as it used testb it is inconclusive.
[Bug c++/47511] [4.6 Regression] [C++0x] ICE: unexpected ast of kind template_decl in potential_constant_expression_1, at cp/semantics.c:7711
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47511 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.01.28 17:06:31 CC||jakub at gcc dot gnu.org Known to work||4.5.2 Target Milestone|--- |4.6.0 Summary|[C++0x] ICE: unexpected ast |[4.6 Regression] [C++0x] |of kind template_decl in|ICE: unexpected ast of kind |potential_constant_expressi |template_decl in |on_1, at|potential_constant_expressi |cp/semantics.c:7711 |on_1, at ||cp/semantics.c:7711 Ever Confirmed|0 |1 Known to fail||4.6.0 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-01-28 17:06:31 UTC --- Confirmed, 4.5 compiles this.
[Bug rtl-optimization/47521] New: Unnecessary usage of edx register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521
Summary: Unnecessary usage of edx register
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: tony.popple...@gmail.com
In testing PR46235 I noticed some minor inefficiency in the usage of an extra
register.
The C code is:
int foo(int a, int x, int y)
{
if (a (16))
return a;
return 1;
}
Which produces the asm:
movl%edi, %eax
movl$1, %edx
testb $16, %al
cmove %edx, %eax
ret
The above code could have been further optimized to remove the usage of edx:
movl$1, %eax
test$16, %edi
cmove %edi, %eax
ret
[Bug rtl-optimization/47521] Unnecessary usage of edx register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521 Tony Poppleton tony.poppleton at gmail dot com changed: What|Removed |Added Known to work||4.3.5 Known to fail||4.4.5, 4.5.2, 4.6.0 --- Comment #1 from Tony Poppleton tony.poppleton at gmail dot com 2011-01-28 17:23:19 UTC --- I probably meant testb $16, %dil above... GCC 4.3.5 avoids the usage of edx, although it too probably has 1 instruction too many: testb $16, %dil movl$1, %eax cmove %eax, %edi movl%edi, %eax ret
[Bug rtl-optimization/46235] inefficient bittest code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46235 --- Comment #4 from Tony Poppleton tony.poppleton at gmail dot com 2011-01-28 18:08:15 UTC --- As a quick test, I commented out the block with the following comment in fold-const.c: /* If this is an EQ or NE comparison with zero and ARG0 is (1 foo) bar, convert it to (bar foo) 1. Both require two operations, but the latter can be done in one less insn on machines that have only two-operand insns or on which a constant cannot be the first operand. */ This produces the following asm code: movl$1, %edx movl%edi, %eax movl%esi, %ecx movl%edx, %edi sall%cl, %edi testl %eax, %edi cmove %edx, %eax ret (using modified GCC 4.6.0 20110122) So whilst I was hoping for an easy quick-fix, it appears that the required optimization to convert it into a btl test isn't there later on in the compile. Incidentally, from looking at http://gmplib.org/~tege/x86-timing.pdf, it appears that bt is slow on P4 architecture (8 cycles if I am reading it correctly? which sounds slow), so the llvm code in the bug description isn't necessarily an optimization on this arch. Newer chips would probably still benefit though.
[Bug target/44031] [4.4/4.5 Regression] ice in subst_reloads, at reload.c:6327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031 --- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2011-01-28 18:28:11 UTC --- Backporting r162726 to 4.5.2 and 4.4.5 prevents the ICE there too.
[Bug fortran/47519] Deferred-length string wrong results with character intrinsic functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47519
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Summary|ICE on allocation of with |Deferred-length string
|deferred-length string |wrong results with
||character intrinsic
||functions
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2011-01-28
18:28:52 UTC ---
The problem is the line:
allocate(name, SOURCE=repeat('x',n))
A simplified (and not ICEing) version is:
n = 10
name = repeat('x',n)
name = repeat('x',4)
name = repeat('x',n)//123
For the first repeat len(name) is 0, for the second repear' one gets the
expected . The third one gives xxx.
In case of the allocate, the problem is that both
code-expr3-ts.u.cl-backend_decl
and
code-expr3-ts.u.cl-length
are NULL pointers. (code-expr3-expr_type is EXPR_FUNCTION)
[Bug target/44031] [4.4/4.5 Regression] ice in subst_reloads, at reload.c:6327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from Jeffrey A. Law law at redhat dot com 2011-01-28 18:42:34 UTC --- The patch Mikael references removes some bogus code which prevents simplification of a subreg of the frame pointer which was causing some problems for the ARM. This case (x86) shows the same failing behaviour, we have a subreg of the frame pointer which triggers a reload we're ultimately unable to handle. I'm going to go ahead and mark this as resolved since I believe Bernd nailed it which is reinforced by Mikael's comments that backporting that fix to the 4.5 and 4.4 branches fixes the problem on the branches as well.
[Bug target/44031] [4.4/4.5 Regression] ice in subst_reloads, at reload.c:6327
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031 --- Comment #12 from Jeffrey A. Law law at redhat dot com 2011-01-28 18:43:27 UTC --- -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/28/11 11:28, mikpe at it dot uu.se wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44031 --- Comment #10 from Mikael Pettersson mikpe at it dot uu.se 2011-01-28 18:28:11 UTC --- Backporting r162726 to 4.5.2 and 4.4.5 prevents the ICE there too. Thanks for verifiying this. That, in my mind seals the deal. jeff -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJNQw5FAAoJEBRtltQi2kC7D3cH/jgVewbZnt4E34iQ2omhb0js rmeyyJJslfr7WT2meajockBImFP/47qIDSX2e8f0wwXW8uQSBQ0FG7RLMQRipOE2 oH6reoXzLve1PFaRmtkKJ7+vcdEwGGf81YZnmBWR0cnqlecG1r3siTGlv+jHpKnp Xa/Q7JWP62aQe6yBcEbOC9IhNlFdx9dci7GrGB13Le8xvpFFjOiUw+nOP5E7pQHC El2IyPqt0wKdZraCcG/sroippAUjts1pL0otxP03EYgqHHVLGdBsFZm2H0ArhJha IK9SXqI0WBI3m5MNRKn/51qAMVZg/7FNUKQ4/kuha/7aGvvG0+H7btU7dp/nlqM= =Zdmq -END PGP SIGNATURE-
