[Bug fortran/30239] duplicate data type assignment not detected
--- Comment #3 from burnus at gcc dot gnu dot org 2006-12-18 07:49 --- > This was a fix for a PR about a year ago - the std=gnu is meant, obviously, to > enforce all versions of the standard on this. However, a number of other > compilers did/do permit this wrinkle on the standard and it even appears in > one > of Meissner's examples. Thus: Should we warn? Give an error (as ifort, NAG f95 and g95 do)? Or keep the status quo where an error is given only for -pedantic and -std=f95/f2003 ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
[Bug fortran/30236] alternate-return subroutine in generic interface causes ice/segfault
--- Comment #3 from patchapp at dberlin dot org 2006-12-18 07:10 --- Subject: Bug number PR30236 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01254.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30236
[Bug bootstrap/21544] xgcc fails (1rst stage) if binutils is not installed into --prefix directory
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-18 06:29 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21544
[Bug bootstrap/29102] mudflap's configure tries to link a binary and fails because I don
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-12-18 06:28 --- Use --disable-libmudflap while building the "stage1" gcc for the cross compiler. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29102
[Bug fortran/30239] duplicate data type assignment not detected
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-18 06:01 --- This was a fix for a PR about a year ago - the std=gnu is meant, obviously, to enforce all versions of the standard on this. However, a number of other compilers did/do permit this wrinkle on the standard and it even appears in one of Meissner's examples. > should all what is needed for this bug. > But this might break other cases were it is allowed. (I didn't check/though > about those, however). > Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
[Bug target/30243] New: avr-gcc 4.1.1: signbit() causes an internal compiler error
avr-gcc (GCC) 4.1.1 Compilation of next program (-W -Wall -Os -S): extern int signbit (double); int foo (double x) { return signbit (x); } causes an compilation abort with message: internal compiler error: in gen_lowpart_general, at rtlhooks.c:51 Older versions are work: 3.3.5, 3.4.4 - call of external signbit() function 4.0.2- inline-code -- Summary: avr-gcc 4.1.1: signbit() causes an internal compiler error Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dmixm at marine dot febras dot ru http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30243
[Bug preprocessor/30242] internal error in gcc break compilation
--- Comment #1 from sherpya at netfarm dot it 2006-12-18 03:31 --- I forgot to attach the error: cc1.exe: internal compiler error: in add_standard_paths, at c-incpath.c:173 so it's not in gcc but the preprocessor I've bootstrapped from 4.1.1 -- sherpya at netfarm dot it changed: What|Removed |Added Component|c |preprocessor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30242
[Bug c/30242] New: internal error in gcc break compilation
gcc 4.3 current svn branch revision 120001 it's not possible to have -save-temps since the compiler bombs while assembling cygwin.asm using gcc (uh?) /d/Download/Devel/MinGW/gcc-source/build/./gcc/xgcc -B/d/Download/Devel/MinGW/gcc-source/build/./gcc/ -L/d/Download/Devel/MinGW/gcc-source/build/mingw32/w insup/mingw -L/d/Download/Devel/MinGW/gcc-source/build/mingw32/winsup/w32api/lib -isystem /d/Download/Devel/MinGW/gcc-source/gcc/winsup/mingw/include -isyst em /d/Download/Devel/MinGW/gcc-source/gcc/winsup/w32api/include -B/mingw/mingw32/bin/ -B/mingw/mingw32/lib/ -isystem /mingw/mingw32/include -isystem /mingw/ mingw32/sys-include -O2 -I../../gcc/gcc/../winsup/w32api/include -O2 -g -O2 -DIN_GCC-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes - Wold-style-definition -isystem ./include -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. -I../../ gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../libdecnumber -DL_chkstk -xassembler-with-cpp -c ../../gcc/gcc/con fig/i386/cygwin.asm -o libgcc/./_chkstk.o -save-temps -- Summary: internal error in gcc break compilation Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sherpya at netfarm dot it GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30242
[Bug rtl-optimization/30213] Wrong code with optimized memset() (possible bug in RTL bbro optimizer)
--- Comment #2 from hubicka at gcc dot gnu dot org 2006-12-18 02:54 --- Mine, working on fix. Honza -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-18 02:54:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30213
[Bug middle-end/7651] Define -Wextra strictly in terms of other warning flags
--- Comment #8 from patchapp at dberlin dot org 2006-12-18 00:20 --- Subject: Bug number PR7651 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01244.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7651
[Bug tree-optimization/30233] internal compiler error: in vect_stmt_relevant_p, at tree-vect-analyze.c:1514 with -O3 -msse -ftree-loop-linear -ftree-vectorize
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-18 00:05 --- Fixed for 4.1.2, this is a bug with -ftree-loop-linear which was known to be broken for 4.1.1. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED Summary|internal compiler error: in |internal compiler error: in |vect_stmt_relevant_p, at|vect_stmt_relevant_p, at |tree-vect-analyze.c:1514|tree-vect-analyze.c:1514 ||with -O3 -msse -ftree-loop- ||linear -ftree-vectorize Target Milestone|--- |4.1.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30233
[Bug libgomp/29949] implement argument checking for user accessable runtime routines
--- Comment #5 from dfranke at gcc dot gnu dot org 2006-12-17 23:27 --- Subject: Bug 29949 Author: dfranke Date: Sun Dec 17 23:27:47 2006 New Revision: 119995 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119995 Log: 2006-12-18 Daniel Franke <[EMAIL PROTECTED]> Backport from mainline: 2006-12-04 Daniel Franke <[EMAIL PROTECTED]> PR libgomp/29949 * env.c (omp_set_num_threads): Set illegal thread count to 1. Backport from mainline: 2006-11-09 Uros Bizjak <[EMAIL PROTECTED]> * env.c (parse_schedule): Reject out of range values. (parse_unsigned_long): Reject out of range, negative or zero values. Modified: branches/gcc-4_2-branch/libgomp/ChangeLog branches/gcc-4_2-branch/libgomp/env.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29949
[Bug tree-optimization/30038] Call to sin(x), cos(x) should be transformed to sincos(x)
--- Comment #17 from burnus at gcc dot gnu dot org 2006-12-17 23:19 --- Using the patch of PR 30223 (add cbrt, cexpi and sincos to Fortran), I don't get any speed up (21.95s for fatigue). Using additionally http://gcc.gnu.org/ml/gcc-patches/2006-12/msg00958.html (folding of cexp ()) I get >20% speedup: 21.95s --> 17.851s This is much less than the 28.3s -> 18.3s change at http://www.suse.de/~gcctest/c++bench/polyhedron/polyhedron-summary.txt-2-0.html which presumably means I miss at least one patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30038
[Bug fortran/30146] Redefining do-variable in excecution cycle
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-17 21:20 --- > As long as the callee doesn't change the value it's probably valid, so this > would need some kind of interprocedural analysis to give a correct error. I think it is formally seen invalid as you have INTENT([IN]OUT) set. Actually, I just retested with NAG f95 and it gives: Error: test.f90, line 5: Active DO variable I passed to INTENT(OUT) argument I number 1 of MYSUB We could nontheless consider of giving a warning only, if you think the case of INTENT(OUT) with no assignment is much more common than a wrongly used do-variable. By the way, if no value is assigned to an INTENT(OUT) variable, gfortran should follow the other compilers and issue a warning: "INTENT(OUT) dummy argument I never set" "INTENT(OUT) variable 'i' at (1) is never set" "A dummy argument with an explicit INTENT(OUT) declaration is not given an explicit value." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
[Bug fortran/30207] [4.2/4.3 Regression] ICE in gfc_dep_resolver with where (a < 0) a(:) = 1
--- Comment #7 from deji_aking at yahoo dot ca 2006-12-17 21:10 --- Thanks Rogers and Steve for the resolution of this bug. I hope you'll not forget to commit it to the gcc-4.2 branch. PS: I've applied the patch cleanly to the 4.2 branch but have not got the opportunity to build and test it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30207
[Bug fortran/30146] Redefining do-variable in excecution cycle
--- Comment #1 from tobi at gcc dot gnu dot org 2006-12-17 20:56 --- As long as the callee doesn't change the value it's probably valid, so this would need some kind of interprocedural analysis to give a correct error. A warning may be in place, though. This shouldn't be to hard, we check that LHS' are not DO variables, so similar code is already there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30146
[Bug fortran/30235] missing alternate return argument with explicit interface causes segfault
--- Comment #3 from tobi at gcc dot gnu dot org 2006-12-17 20:37 --- Maybe we should add a new expression type EXPR_LABEL_REF or whatever better name you might come up with for the label references? This seems much less error-prone than checking for magic NULLs all over the compiler. -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235
[Bug fortran/30228] ICE: build_int_cst_wide, at tree.c:912 / invalid deallocate
--- Comment #1 from tobi at gcc dot gnu dot org 2006-12-17 20:34 --- I couldn't reproduce this, and Tobias Burnus thinks it coudl be an issue in his tree. tobias-schluters-computer:~/src/pr/30228 tobi$ cat t.f90 type pt integer, pointer :: p(:) end type pt type(pt), pointer :: t(:) integer i i = 1 allocate (t(1)) allocate (t(1)%p(0)) deallocate(t(1)%p(0)) end tobias-schluters-computer:~/src/pr/30228 tobi$ ~/src/trunk2/build/gcc/f951 t.f90 t.f90:9.12: deallocate(t(1)%p(0)) 1 Error: Expression in DEALLOCATE statement at (1) must be ALLOCATABLE or a POINTER Execution times (seconds) parser: 0.01 (100%) usr 0.00 ( 0%) sys 0.00 ( 0%) wall 111 kB (14%) ggc TOTAL : 0.01 0.01 0.01 822 kB Extra diagnostic checks enabled; compiler may run slowly. Configure with --disable-checking to disable checks. tobias-schluters-computer:~/src/pr/30228 tobi$ -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30228
[Bug fortran/30237] Alternate return arguments in intrinsic subroutine calls are ignored
--- Comment #1 from tobi at gcc dot gnu dot org 2006-12-17 20:22 --- >From the comment preceding remove_nullargs() I wonder why it's called in the beginning of sort_actual(). -- tobi at gcc dot gnu dot org changed: What|Removed |Added CC||tobi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30237
[Bug fortran/30239] duplicate data type assignment not detected
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-17 20:15 --- This is because in symbol.c's gfc_add_type there is const char *msg = "Symbol '%s' at %L already has basic type of %s"; if (!(sym->ts.type == ts->typesym->ts.type == ts->type && (sym->attr.flavor == FL_PROCEDURE || sym->attr.result)) || gfc_notification_std (GFC_STD_GNU) == ERROR || pedantic) { gfc_error (msg, sym->name, where, gfc_basic_typename (sym->ts.type)); return FAILURE; } The !(sym->ts.type == ts->type) prevents the error message. Removing this check should all what is needed for this bug. But this might break other cases were it is allowed. (I didn't check/though about those, however). -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-17 20:15:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
[Bug fortran/30238] associated(null-pointer, null-pointer) returns .true.
-- burnus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |burnus at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-17 19:11:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30238
[Bug fortran/30238] associated(null-pointer, null-pointer) returns .true.
--- Comment #1 from patchapp at dberlin dot org 2006-12-17 19:10 --- Subject: Bug number PR30238 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2006-12/msg01228.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30238
[Bug other/30241] __libc_stack_end is not portable between PPC distributions
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-17 19:04 --- This symbol has differing versions across platforms (GLIB_2.1 on Fedora Core, Yellow Dog Linux and GLIBC_PRIVATE on Debian/stable) And this is not a GCC bug really because glibc changed so really either this is a glibc bug or really a distro bug. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30241
[Bug other/30240] -fno-inline-functions does not work, and doc bugs
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-17 19:02 --- You want -fno-inline-functions-called-once which was added in 4.2.0 IIRC (it is in 4.3.0 for sure). http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Optimize-Options -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30240
[Bug fortran/30207] [4.2/4.3 Regression] ICE in gfc_dep_resolver with where (a < 0) a(:) = 1
--- Comment #6 from sayle at gcc dot gnu dot org 2006-12-17 18:28 --- Subject: Bug 30207 Author: sayle Date: Sun Dec 17 18:28:07 2006 New Revision: 119990 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119990 Log: 2006-12-17 Roger Sayle <[EMAIL PROTECTED]> Steven G. Kargl <[EMAIL PROTECTED]> PR fortran/30207 * dependency.c (gfc_full_array_ref_p): New function to test whether the given array ref specifies the entire array. (gfc_dep_resolver): Use gfc_full_array_ref_p to analyze AR_FULL array refs against AR_SECTION array refs, and vice versa. * dependency.h (gfc_full_array_ref_p): Prototype here. * trans-array.c (gfc_conv_expr_descriptor): Use gfc_full_array_ref_p. * gfortran.fortran-torture/execute/where21.f90: New test. Added: trunk/gcc/testsuite/gfortran.fortran-torture/execute/where21.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dependency.c trunk/gcc/fortran/dependency.h trunk/gcc/fortran/trans-array.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30207
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
--- Comment #29 from pertusus at free dot fr 2006-12-17 18:21 --- getarg intrinsic which was in g77 also seems to be unimplemented? -- pertusus at free dot fr changed: What|Removed |Added CC||pertusus at free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug other/30241] New: __libc_stack_end is not portable between PPC distributions
Hello, i'm not sure this is the right place to report this. Please direct me elsewhere if it's not. I'm trying to build generic binaries for lilypond (lilypond.org), using a x86 pc targetting linux/ppc. I'm building a cross-compiler against the Debian/stable libs/headers. My problem is that libgcc_s.so links in the __libc_stack_end symbol (ppc_linux_aux_vector () in config/rs6000/linux-unwind.h ) This symbol has differing versions across platforms (GLIB_2.1 on Fedora Core, Yellow Dog Linux and GLIBC_PRIVATE on Debian/stable), so it's not possible to build PPC binaries that run on all linux/ppc distributions. I could try patching GCC sources, to simulate a stupid PPC CPU, but it would be nice if this worked out of the box, ie. if ppc_fallback_frame_state() could determine CPU characteristics without looking at __libc_stack_end. -- Summary: __libc_stack_end is not portable between PPC distributions Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hanwen at xs4all dot nl GCC build triplet: i686-pc-linux-gnu GCC host triplet: powerpc-linux GCC target triplet: powerpc-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30241
[Bug other/30240] New: -fno-inline-functions does not work, and doc bugs
The -f(no-)inline-functions option does not work. Its documented effect is controlled by -f(no-)inline, both in gcc and g++. (Don't ask me how that jibes with Bug #27881:-) The doc says -finline-functions is only invoked by -O3. I suggest you preserve -O's current functionality: Move -finline-functions from -O3 to -O and document that (under -fno-inline-functions). The two first compile commands below work with gcc-3.4.4, but the third does not: -fno-inline -finline-functions does not inline foo(). That's possibly a doc bug: (gcc)Optimize Options says `-fno-inline' Don't pay attention to the `inline' keyword. Normally this option is used to keep the compiler from expanding any functions inline. (...) One of these sentences is wrong. Does -fno-inline only mean "ignore the inline keyword", or does it mean "inline nothing, regardless of other inlining options or keywords/attributes", or something else? Doc bugs in Info node (gcc)Inline: "(If you are writing a header file to be included in ISO C programs, write `__inline__' instead of `inline'...") Should now be "ISO C90" programs. "Some calls cannot be integrated for various reasons (in particular, calls that precede the function's definition cannot be integrated,..." Except with -funit-at-a-time. Which is also turned on by -O even though it's documented as an -O2 option. $ cat bug.c static int foo(void){ return 9; } int bar(void) { return foo(); } $ gcc -O -fno-inline-functions -S bug.c -o- .file "bug.c" .text .globl bar .type bar, @function bar: pushl %ebp movl%esp, %ebp movl$9, %eax popl%ebp ret .size bar, .-bar .ident "GCC: (GNU) 4.1.1" .section.note.GNU-stack,"",@progbits $ gcc -O -fno-inline -S bug.c -o- .file "bug.c" .text .type foo, @function foo: pushl %ebp movl%esp, %ebp movl$9, %eax popl%ebp ret .size foo, .-foo .globl bar .type bar, @function bar: pushl %ebp movl%esp, %ebp callfoo popl%ebp ret .size bar, .-bar .ident "GCC: (GNU) 4.1.1" .section.note.GNU-stack,"",@progbits $ gcc -O -fno-inline -finline-functions -S bug.c -o- -- Summary: -fno-inline-functions does not work, and doc bugs Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: h dot b dot furuseth at usit dot uio dot no GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30240
[Bug fortran/30239] New: duplicate data type assignment not detected
The Intel Fortan Compiler issues an error on the code below INTEGER FUNCTION foo() INTEGER :: foo foo = 0 END FUNCTION gfortran takes it without further notice. Letting "INTEGER :: foo" be "REAL :: foo" gives "Error: Symbol 'foo' at (1) already has basic type of INTEGER" on gfortran as well. $> gfortran-svn -v gcc version 4.3.0 20061128 (experimental) -- Summary: duplicate data type assignment not detected Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dfranke at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30239
[Bug fortran/30236] alternate-return subroutine in generic interface causes ice/segfault
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-17 15:46 --- Created an attachment (id=12821) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12821&action=view) Patch for PR This produces code that works correctly and is halfway through a regtest. I'll do the submit tonight. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30236
[Bug rtl-optimization/29858] regmove has been silently disabled
--- Comment #4 from steven at gcc dot gnu dot org 2006-12-17 14:57 --- That patch was already approved: http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01982.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29858
[Bug rtl-optimization/18995] delete_trivially_dead_insns fails to update the liveness information
--- Comment #4 from steven at gcc dot gnu dot org 2006-12-17 14:48 --- There will be no more delete_trivially_dead_insns when the dataflow branch is merged. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18995
[Bug rtl-optimization/20211] autoincrement generation is poor
--- Comment #35 from steven at gcc dot gnu dot org 2006-12-17 14:47 --- This should be fixed when the dataflow branch is merged. There is a new pass there dedicated to generating auto-inc/dec insns. If the pass in auto-inc-dec.c on the dataflow branch does not fix this issue, a proper fix for this bug will have to be implemented there instead of in regmove. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20211
[Bug fortran/30235] missing alternate return argument with explicit interface causes segfault
--- Comment #2 from pault at gcc dot gnu dot org 2006-12-17 14:27 --- (In reply to comment #1) > I think this patch fixes this; I'm testing it now: If it doesn't work, I'll eat my protective cranial wear... Good one! Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235
[Bug fortran/30236] alternate-return subroutine in generic interface causes ice/segfault
--- Comment #1 from pault at gcc dot gnu dot org 2006-12-17 14:23 --- Brooks, The standard has no problem with this, as you surmise. The first segfault is in count_types_test, where an attempt is made to use the non-existent formal symbol. This should be asy to fix - it's a matter of perspiration rather than inspiration. I'll give it a go tonight, since I am into an INTERFACE bee Thanks Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-17 14:23:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30236
[Bug tree-optimization/30233] internal compiler error: in vect_stmt_relevant_p, at tree-vect-analyze.c:1514
--- Comment #2 from nickols_k at mail dot ru 2006-12-17 14:18 --- Created an attachment (id=12820) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12820&action=view) preprocessed source file as requires bugs.html gcc's output on -v: gcc4: warning: -pipe ignored because -save-temps specified Using built-in specs. Target: i686-pc-linux-gnu Configured with: ./configure --prefix=/usr/local --with-gnu-as --enable-shared --with-gnu-ld --enable-threads=posix --disable-nls --enable-serial-all-configure Thread model: posix gcc version 4.1.1 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -E -quiet -v -I. -I. -I../.. -I../.. -I/opt/gtk/include/gtk-2.0 -I/opt/gtk/lib/gtk-2.0/include -I/opt/gtk/include/atk-1.0 -I/opt/gtk/include/pango-1.0 -I/opt/gtk/include/glib-2.0 -I/opt/gtk/lib/glib-2.0/include -I/usr/X11R6/include/cairo -I/usr/local/include -MD maze.d -MF .deps/maze.Tpo -MP -MT maze.o -MQ maze.o -DHAVE_CONFIG_H -DGIMP_DISABLE_DEPRECATED -DGDK_MULTIHEAD_SAFE -DGTK_MULTIHEAD_SAFE maze.c -m32 -mmmx -msse -m3dnow -msse -mfpmath=387,sse -mfancy-math-387 -march=athlon-xp -Wall -funroll-all-loops -floop-optimize2 -ftree-ccp -ftree-ch -ftree-combine-temps -ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-linear -ftree-loop-optimize -ftree-lrs -ftree-pre -ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp -ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version -ftree-vrp -fbranch-target-load-optimize2 -ftree-vectorize -ffast-math -fomit-frame-pointer -O3 -fpch-preprocess -o maze.i ignoring nonexistent directory "/usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/../../../../i686-pc-linux-gnu/include" ignoring duplicate directory "." ignoring duplicate directory "../.." ignoring duplicate directory "/usr/local/include" as it is a non-system directory that duplicates a system directory #include "..." search starts here: #include <...> search starts here: . ../.. /opt/gtk/include/gtk-2.0 /opt/gtk/lib/gtk-2.0/include /opt/gtk/include/atk-1.0 /opt/gtk/include/pango-1.0 /opt/gtk/include/glib-2.0 /opt/gtk/lib/glib-2.0/include /usr/X11R6/include/cairo /usr/local/include /usr/local/lib/gcc/i686-pc-linux-gnu/4.1.1/include /usr/include End of search list. /usr/local/libexec/gcc/i686-pc-linux-gnu/4.1.1/cc1 -fpreprocessed maze.i -quiet -dumpbase maze.c -m32 -mmmx -msse -m3dnow -msse -mfpmath=387,sse -mfancy-math-387 -march=athlon-xp -auxbase-strip maze.o -O3 -Wall -version -funroll-all-loops -floop-optimize2 -ftree-ccp -ftree-ch -ftree-combine-temps -ftree-copy-prop -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-fre -ftree-loop-im -ftree-loop-ivcanon -ftree-loop-linear -ftree-loop-optimize -ftree-lrs -ftree-pre -ftree-salias -ftree-sink -ftree-sra -ftree-store-ccp -ftree-store-copy-prop -ftree-ter -ftree-vect-loop-version -ftree-vrp -fbranch-target-load-optimize2 -ftree-vectorize -ffast-math -fomit-frame-pointer -o maze.s GNU C version 4.1.1 (i686-pc-linux-gnu) compiled by GNU C version 3.4.6. GGC heuristics: --param ggc-min-expand=99 --param ggc-min-heapsize=129532 Compiler executable checksum: e9d1412e4a46dfa64960e03d3f09c035 maze.c: In function 'run': maze.c:179: internal compiler error: in vect_stmt_relevant_p, at tree-vect-analyze.c:1514 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [maze.o] Îøèáêà 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30233
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #49 from doko at gcc dot gnu dot org 2006-12-17 13:57 --- Subject: Bug 11953 Author: doko Date: Sun Dec 17 13:57:31 2006 New Revision: 119988 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119988 Log: 2006-12-17 Matthias Klose <[EMAIL PROTECTED]> PR libstdc++/11953 * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/mips/linux.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #48 from doko at gcc dot gnu dot org 2006-12-17 13:53 --- Subject: Bug 11953 Author: doko Date: Sun Dec 17 13:53:07 2006 New Revision: 119987 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119987 Log: 2006-12-17 Matthias Klose <[EMAIL PROTECTED]> PR libstdc++/11953 * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/mips/linux.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug libstdc++/11953] _REENTRANT defined when compiling non-threaded code.
--- Comment #47 from doko at gcc dot gnu dot org 2006-12-17 13:47 --- Subject: Bug 11953 Author: doko Date: Sun Dec 17 13:46:58 2006 New Revision: 119986 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119986 Log: 2006-12-17 Matthias Klose <[EMAIL PROTECTED]> PR libstdc++/11953 * gcc/config/mips/linux.h (SUBTARGET_CPP_SPEC): Extend. Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/linux.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11953
[Bug fortran/30238] New: associated(null-pointer, null-pointer) returns .true.
For non-array calls, the "if" is directly created in trans-intrinsic.c's gfc_conv_associated. As one can see below, gfortran currently only checks whether two pointers are the same, it also should check whether they are NULL pointers. Example: integer, pointer :: a nullify(a) if(associated(a,a)) call abort() end and dump: int4 * a; _gfortran_set_std (70, 127, 0); a = 0B; if (a == a) { _gfortran_abort (); } -- Summary: associated(null-pointer, null-pointer) returns .true. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30238
[Bug fortran/30237] New: Alternate return arguments in intrinsic subroutine calls are ignored
Alternate-return arguments in argument lists are represented by a null symbol or expression pointer. In intrinsic.c, remove_nullargs() simply removes null-pointer symbols from the argument list handled by an intrinsic function or subroutine. Ergo, an alternate-return actual argument in an intrinsic subroutine call will simply be skipped over and ignored. The following code demonstrates this: --- debian-gfortran:~/test> cat ar1.f90 program ar1 real t1 call cpu_time(*20, t1) 20 write(*,*) t1 end debian-gfortran:~/test> ../bin-trunk/bin/gfortran ar1.f90 debian-gfortran:~/test> ./a.out 1.2997000E-02 debian-gfortran:~/test> ../bin-trunk/bin/gfortran --version GNU Fortran 95 (GCC) 4.3.0 20061128 (experimental) Copyright (C) 2006 Free Software Foundation, Inc. -- Summary: Alternate return arguments in intrinsic subroutine calls are ignored Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: accepts-invalid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30237
[Bug bootstrap/30136] bootstrap fail for 4.3-20061209
--- Comment #3 from dcb314 at hotmail dot com 2006-12-17 09:05 --- (In reply to comment #2) > I expect to try out 4.3-20061216. I tried it out and it is still broken. Is that three snapshots in a row that fail on x86_64 ? -- dcb314 at hotmail dot com changed: What|Removed |Added Status|WAITING |UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30136
[Bug fortran/30235] missing alternate return argument with explicit interface causes segfault
--- Comment #1 from brooks at gcc dot gnu dot org 2006-12-17 08:34 --- I think this patch fixes this; I'm testing it now: Index: interface.c === --- interface.c (revision 119980) +++ interface.c (working copy) @@ -1446,6 +1446,13 @@ { if (new[i] != NULL) continue; + if (f->sym == NULL) + { + if (where) + gfc_error ("Missing alternate return spec in subroutine call at %L", + where); + return 0; + } if (!f->sym->attr.optional) { if (where) -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-12-17 08:34:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30235