[Bug target/45726] Thumb2 instruction emitted for incompatible CPU
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45726 --- Comment #18 from Ryan Hill dirtyepic at gentoo dot org 2010-12-26 08:03:51 UTC --- Ignore that.
[Bug fortran/47065] New: Replace trim(a) by a(1:len_trim(a))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47065 Summary: Replace trim(a) by a(1:len_trim(a)) Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: tkoe...@gcc.gnu.org In many cases, it is possible to replace trim(a) by a(1:len_trim(a)). This is a win because it saves trim from creating a temporary.
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 bruno at clisp dot org changed: What|Removed |Added CC||bruno at clisp dot org --- Comment #17 from bruno at clisp dot org 2010-12-26 18:06:15 UTC --- Note that the use of values-xpg6.o leads to unexpected behaviour when considering shared libraries: 1) The behaviour of a shared library also depends on whether the executable is linked with or without values-xpg6.o. The author of the shared library may not expect this and may not have tested in this situation. 2) The behaviour of an executable also depends on whether some of the shared libraries was built with values-xpg6.o. The author of the program may not expect this. This leads to real bugs: http://lists.gnu.org/archive/html/autoconf/2010-02/msg00013.html More details in http://lists.gnu.org/archive/html/autoconf/2010-12/msg00059.html For this reason, I would find it bad if gcc -std=c99 or gcc -std=gnu99 would cause values-xpg6.o to be included in the link. Please close this issue as Won't fix. Programs which wish to have POSIX compliant behaviour of system functions can use GNU gnulib; it doesn't rely on values-xpg6.o.
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 --- Comment #18 from Paolo Carlini paolo.carlini at oracle dot com 2010-12-26 18:35:49 UTC --- Rainer, can you have another look to this issue and possibly actually close it?
[Bug fortran/47065] Replace trim(a) by a(1:len_trim(a))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47065 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2010.12.26 21:31:55 AssignedTo|unassigned at gcc dot |tkoenig at gcc dot gnu.org |gnu.org | Ever Confirmed|0 |1
[Bug fortran/47065] Replace trim(a) by a(1:len_trim(a))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47065 --- Comment #1 from Thomas Koenig tkoenig at gcc dot gnu.org 2010-12-26 21:34:14 UTC --- Created attachment 22852 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=22852 Partial patch This appears to work for the cases where there is no substring reference.
[Bug target/40411] -std=c99 does not enable c99 mode in Solaris C library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40411 --- Comment #19 from Jonathan Wakely redi at gcc dot gnu.org 2010-12-26 21:52:07 UTC --- (In reply to comment #17) For this reason, I would find it bad if gcc -std=c99 or gcc -std=gnu99 would cause values-xpg6.o to be included in the link. Please close this issue as Won't fix. Programs which wish to have POSIX compliant behaviour of system functions can use GNU gnulib; it doesn't rely on values-xpg6.o. I don't entirely agree with this line of reasoning. If the system provides a POSIX compliant C library it's reasonable to want to use it and users will want some way to tel the compiler to do so. Whether using it is enabled via -std or not, linking to values-xpg6.o can cause unexpected behaviour for applications or shared objects. It does seem reasonable to expect -std=c99 to enable C99 features if the system supports them, and similarly for -std=c++0x
[Bug middle-end/44081] Incorrect nonnull assumed in code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44081
Valeriy nordq at ya dot ru changed:
What|Removed |Added
CC||nordq at ya dot ru
--- Comment #11 from Valeriy nordq at ya dot ru 2010-12-26 22:57:48 UTC ---
/*
nonnull_2.c
gcc -O0 nonnull_2.c
gcc -O1 nonnull_2.c
gcc -O3 nonnull_2.c
if (0 or 8) - Ok
0004 else
0008 if (0 or 8)
gcc -O2 nonnull_2.c
gcc -Os nonnull_2.c
else - Error
0004 else
0008 if (0 or 8)
*/
#include stdio.h
static void attribute_nonnull_2(int i1, int *i2, int *i3)
__attribute__((__nonnull__(2)));
static void attribute_nonnull_2(int i1, int *i2, int *i3) {
*i2 = i1;
if (i3 == 0 || i3 == (int *) 8)
printf(%p if (0 or 8)\n, i3);
else
printf(%p else \n, i3);
}
int i2a;
int main(int argc, char *argv[]) {
attribute_nonnull_2(1, i2a, (int *) 0);
attribute_nonnull_2(2, i2a, (int *) 4);
attribute_nonnull_2(3, i2a, (int *) 8);
return 0;
}
[Bug fortran/18584] --std=f would be nice
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18584 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||thenlich at users dot ||sourceforge.net --- Comment #9 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-26 23:55:46 UTC --- *** Bug 47039 has been marked as a duplicate of this bug. ***
[Bug fortran/47039] Support warnings/errors for non-F features.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47039 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dfranke at gcc dot gnu.org Resolution||DUPLICATE --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-26 23:55:46 UTC --- The last request for F was closed as WONTFIX well over two years ago (after sitting there for 4 years without anyone bothering) ... *** This bug has been marked as a duplicate of bug 18584 ***
[Bug fortran/46979] Possible false may be used uninitialized in this function warning
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46979 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dfranke at gcc dot gnu.org Known to work||4.6.0 Resolution||FIXED --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:02:21 UTC --- Closing.
[Bug fortran/46917] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46917 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dfranke at gcc dot gnu.org Resolution||INVALID --- Comment #5 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:05:53 UTC --- Closing as INVALID due to comments #1 to #4. Please reopen if you feel that this PR should live on.
[Bug fortran/46917] ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46917 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||michael.a.richmond at nasa ||dot gov --- Comment #6 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:09:46 UTC --- *** Bug 46825 has been marked as a duplicate of this bug. ***
[Bug fortran/46825] ICE compiling modules with MinGW build dated 20101204
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46825 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||dfranke at gcc dot gnu.org Resolution||DUPLICATE --- Comment #3 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:09:46 UTC --- Closing. Please see comments #1 to #4 in PR46917 for further details. Please reopen if you feel that this PR should live on. *** This bug has been marked as a duplicate of bug 46917 ***
[Bug fortran/46874] [OpenMP] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c:147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46874 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.27 00:15:55 CC||dfranke at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #8 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:15:55 UTC --- Jakub, is there anything left here or can this report be closed?
[Bug fortran/46703] Wrong I/O output (only) when running under valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46703 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.27 00:23:27 CC||dfranke at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:23:27 UTC --- (In reply to comment #1) Maybe yet another of x86's extra floating point precision effects. I suppose where valgrind needs to do its verifications, it interrupts the program and saves/restores the registers (to memory), thus losing the extra precision. Seconded. Simple test: does -ffloat-store change the output as well?
[Bug fortran/46405] Preprocessor generated code can exceed 132 characters
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46405 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING
[Bug fortran/46411] MOVE_ALLOC wrongly rejected as impure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46411 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.27 00:30:19 CC||dfranke at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #4 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:30:19 UTC --- Tobias, is there anything left or can this report be closed?
[Bug fortran/46520] [4.6 Regression] libquadmath: fails at link test on bare irons
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46520 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2010.12.27 00:33:08 CC||dfranke at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #8 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:33:08 UTC --- Tobias, anything left here or can this report be closed?
[Bug fortran/45909] [4.4/4.5] internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45909 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||dfranke at gcc dot gnu.org Summary|f951.exe: internal compiler |[4.4/4.5] internal compiler |error: Segmentation fault |error --- Comment #2 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:50:35 UTC --- Set to WAITING. If nobody picks this up in a while, this PR shall be closed.
[Bug testsuite/45988] gfortran.dg/vect/fast-math-pr38968.f90 times out on 32-bit Solaris 10/x86
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45988 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||dfranke at gcc dot gnu.org Component|fortran |testsuite --- Comment #1 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 00:52:44 UTC --- Doesn't seem to be overly fortran related?! Reassigning to component 'testsuite', assuming that it's more likely that someone may pick it up.
[Bug fortran/46703] Wrong I/O output (only) when running under valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46703 --- Comment #3 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2010-12-27 01:03:55 UTC --- -ffloat-store is the first thing I tried and no change. However, the run-time side, libgfortran, is not compiled normally with -ffloat-store so maybe we should try that.
[Bug fortran/45676] Move array assignments out of loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45676 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||dfranke at gcc dot gnu.org --- Comment #4 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 01:22:56 UTC --- Ha! I knew I have seen this before. Dupe of #30409?
[Bug fortran/40876] OpenMP private variable referenced in a statement function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||dfranke at gcc dot gnu.org
[Bug fortran/40876] OpenMP private variable referenced in a statement function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40876 --- Comment #8 from Bill Long longb at cray dot com 2010-12-27 01:42:20 UTC --- I am out of the office until Monday, January 3, 2011. Send technical questions to spsl...@cray.com.
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||dfranke at gcc dot gnu.org --- Comment #7 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 02:04:07 UTC --- I had the vague impression that FINAL was already completed, so I gave it a try ... polytest.f90:28.22: SUBROUTINE free(this) 1 Error: Argument of FINAL procedure at (1) must be of type 'abstract_weight' for SUBROUTINE free(this) CLASS(abstract_weight), INTENT(inout) :: this ! ... END SUBROUTINE Placing the error marker at CLASS() and rewording to must be of 'TYPE(abstract_weight)' might ease some confusion. It took me a while to figure out what's wrong ^^ However, any plans to get this completed in the foreseeable future?
[Bug fortran/45827] mio_component_ref(): Component not found when mixing f90 and f03 in large projects
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45827 Daniel Franke dfranke at gcc dot gnu.org changed: What|Removed |Added CC||dfranke at gcc dot gnu.org --- Comment #32 from Daniel Franke dfranke at gcc dot gnu.org 2010-12-27 02:22:45 UTC --- Same error for this testcase: MODULE abstract_weight_policy TYPE, ABSTRACT :: abstract_weight PRIVATE INTEGER :: n REAL(8), ALLOCATABLE :: w(:) CONTAINS PROCEDURE(create), DEFERRED :: create PROCEDURE :: get PROCEDURE :: destroy END TYPE ABSTRACT INTERFACE SUBROUTINE create(this, n, s, I) IMPORT abstract_weight CLASS(abstract_weight), INTENT(inout) :: this INTEGER, INTENT(in) :: n REAL(8), INTENT(in) :: s(n), I(n) END SUBROUTINE END INTERFACE CONTAINS PURE FUNCTION get(this) CLASS(abstract_weight), INTENT(in) :: this REAL(8), DIMENSION(this%n) :: get get = this%w END FUNCTION SUBROUTINE destroy(this) CLASS(abstract_weight), INTENT(inout) :: this IF (ALLOCATED(this%w)) DEALLOCATE(this%w) this%n = 0 END SUBROUTINE END MODULE MODULE myweights_policy USE abstract_weight_policy END MODULE $ gfortran-svn -Wall -W polytest.f90 polytest.f90:36.28: USE abstract_weight_policy 1 Internal Error at (1): mio_component_ref(): Component not found $ gfortran-svn -v gcc version 4.6.0 20101226 (experimental) (GCC) The error is consistent and reproducible for me, nothing fishy from valgrind. Although the error is identical, no idea if the reason to trigger it is the same as the reporter's.
[Bug target/47066] New: HOST=i386-unknown-freebsd6.2, TARGET=arm--elf, cpu=arm7tdmi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47066 Summary: HOST=i386-unknown-freebsd6.2, TARGET=arm--elf, cpu=arm7tdmi Product: gcc Version: 4.5.1 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: nos...@unixguru.com arm--elf-ld: ERROR: /arm--elf/lib/libgcc-thumb.a(_thumb1_case_uqi.o) uses hardware FP, whereas test uses software FP The message above is generated from the following configure script for gcc-4.5.1 # The gcc driver likes to know the arguments it was configured with. TOPLEVEL_CONFIGURE_ARGUMENTS=../src/configure --with-gmp=/usr/local --enable-languag es=c --enable-stage1-languages=c --enable-stage1-checking=c --disable-lto --disable- libada --disable-libssp --disable-build-with-cxx --target=arm--elf --with-prefix=/ar m--elf --with-suffix=-arm --with-build-time-tools=/arm--elf/arm--elf/bin/ --with-as= /arm--elf/arm--elf/bin/as --with-ar=/arm--elf/arm--elf/bin/ar --with-ld=/arm--elf/ar m--elf/bin/ld The arm7tdmi processor from Analog Devices does not have a FPU and I have been unable to locate an option or flag to prevent arm.o from being created with hard-float. The application I'm porting to the arm7tdmi is mixed mode (arm/thumb). I would appreciate any hints on how to build libgcc.c with soft-float and thumb-interwork Thanks for your assistance. - Evan Brown
[Bug target/47066] HOST=i386-unknown-freebsd6.2, TARGET=arm--elf, cpu=arm7tdmi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47066 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2010-12-27 06:29:13 UTC --- You really should be using arm-eabi. Also arm7 does not require interworking at all. The processor supports switching between thumb and arm without extra work.
