[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #7 from dberlin at gcc dot gnu dot org 2007-07-24 07:16 --- Didn't you commit the shared bitmap fix? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug target/32853] [4.3 regression] failing libjava testcases
--- Comment #1 from debian-gcc at lists dot debian dot org 2007-07-24 07:21 --- glibc 2.6 related? unreproducible with a glibc downgraded to 2.5 Matthias -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32853
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #139 from jv244 at cam dot ac dot uk 2007-07-24 07:22 --- (In reply to comment #138) > I'll > start a new test with current trunk. Tue Jul 24 06:32:19 UTC 2007 (revision 126866) is also passing the test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-24 07:30 --- Subject: Bug 32723 Author: rguenth Date: Tue Jul 24 07:30:47 2007 New Revision: 126867 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126867 Log: 2007-07-24 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/32723 Backport from mainline: 2007-03-09 Daniel Berlin <[EMAIL PROTECTED]> * tree-ssa-structalias.c (shared_bitmap_info_t): New structure. (shared_bitmap_table): New variable. (shared_bitmap_hash): New function. (shared_bitmap_eq): Ditto (shared_bitmap_lookup): Ditto. (shared_bitmap_add): Ditto. (find_what_p_points_to): Rewrite to use shared bitmap hashtable. (init_alias_vars): Init shared bitmap hashtable. (delete_points_to_sets): Delete shared bitmap hashtable. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/tree-ssa-structalias.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug tree-optimization/32723] [4.2 Regression] memory hog in solve_graph
--- Comment #9 from rguenth at gcc dot gnu dot org 2007-07-24 07:31 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32723
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #140 from pault at gcc dot gnu dot org 2007-07-24 07:45 --- (In reply to comment #139) > (In reply to comment #138) > > I'll > > start a new test with current trunk. > Tue Jul 24 06:32:19 UTC 2007 (revision 126866) is also passing the test. You were right about the options: "-O3 -ffast-math -march=native" triggers the crash on PIV/Cygwin_NT, whereas "-O1" does not. I'll retry latter with -march=native, which I suspect from past experiences. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug bootstrap/31776] Bootstrap fails with "error: conflicting types for strsignal"
--- Comment #8 from dorit at gcc dot gnu dot org 2007-07-24 07:50 ---
Subject: Bug 31776
Author: dorit
Date: Tue Jul 24 07:50:10 2007
New Revision: 126868
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126868
Log:
2007-07-23 Dorit Nuzman <[EMAIL PROTECTED]>
merge revision 124373 from trunk:
2007-05-02 Brooks Moses <[EMAIL PROTECTED]>
PR bootstrap/31776
* system.h: Remove inclusion of double-int.h
* tree.h: Include double-int.h
* gengtype.c: Likewise
* cfgloop.h: Likewise
* Makefile.in: Adjust dependencies on double-int.h
Modified:
branches/autovect-branch/ (props changed)
branches/autovect-branch/gcc/ChangeLog.autovect
branches/autovect-branch/gcc/Makefile.in
branches/autovect-branch/gcc/cfgloop.h
branches/autovect-branch/gcc/gengtype.c
branches/autovect-branch/gcc/system.h
branches/autovect-branch/gcc/tree.h
Propchange: branches/autovect-branch/
('svnmerge-integrated' modified)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31776
[Bug fortran/31205] aliased operator assignment produces wrong result
--- Comment #7 from patchapp at dberlin dot org 2007-07-24 07:55 --- Subject: Bug number PR31205 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/2007-07/msg01709.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #141 from jv244 at cam dot ac dot uk 2007-07-24 08:44 --- (In reply to comment #140) > You were right about the options: "-O3 -ffast-math -march=native" triggers the > crash on PIV/Cygwin_NT, whereas "-O1" does not. I'll retry latter with > -march=native, which I suspect from past experiences. I tried (on an opteron): -m32 -O3 -ffast-math -march=pentium4 -m32 -O3 -ffast-math -march=nocona (any other suggestion ?) but couldn't get a crash. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #13 from patchapp at dberlin dot org 2007-07-24 08:45 --- Subject: Bug number PR32867 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/2007-07/msg01713.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug c/32874] New: Strange global register allocation, depends on order of functions
I have 3 global register variables, 1 pointer to a struct and 2 unsigned integers. Next I have 2 functions, each working on the pointer and on one of the integers. The generated output looks strange in the first place, and is dependant on the order of the two functions in the input .c file. -- Summary: Strange global register allocation, depends on order of functions Product: gcc Version: 4.1.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ecd at brainaid dot de GCC build triplet: sparc-linux-gnu GCC host triplet: sparc-linux-gnu GCC target triplet: sparc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
[Bug tree-optimization/32093] BOOT_CFLAGS="-O2 -g -msse2 -ftree-vectorize" causes dfp tests to fail
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-24 08:50 --- > i'm wondering if this could be related to a problem we're seeing with > segfaults > caused by misaligned movdqa instructions in zlib compiled with > -ftree-vectorize. A fix for PR25413 was committed to mainline. Ryan, could you please check if it solves the zlib miscompilation? Andrew, would you plase check if it solves the libgcc miscompilation that you are seeing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32093
[Bug c/32874] Strange global register allocation, depends on order of functions
--- Comment #1 from ecd at brainaid dot de 2007-07-24 08:51 --- Created an attachment (id=13955) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13955&action=view) Input file to trigger the problem -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
[Bug c/32874] Strange global register allocation, depends on order of functions
--- Comment #2 from ecd at brainaid dot de 2007-07-24 08:52 --- Created an attachment (id=13956) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13956&action=view) Input file to trigger the problem with order of functions reversed -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
[Bug c/32874] Strange global register allocation, depends on order of functions
--- Comment #3 from ecd at brainaid dot de 2007-07-24 08:52 --- Created an attachment (id=13957) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13957&action=view) Output number 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
[Bug c/32874] Strange global register allocation, depends on order of functions
--- Comment #4 from ecd at brainaid dot de 2007-07-24 08:53 --- Created an attachment (id=13958) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13958&action=view) Output number 2 (function order reversed) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
--- Comment #5 from dorit at gcc dot gnu dot org 2007-07-24 08:53 --- (In reply to comment #4) > I just tried to reproduce this bug on IA64 Linux (and HP-UX) with ToT sources > (version 126242) and was not able to. Can anyone else reproduce this with ToT > sources? does the fact that no one has responded yet means that this failure cannot be reproduced anymore? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug c/32874] Strange global register allocation, depends on order of functions
--- Comment #5 from ecd at brainaid dot de 2007-07-24 08:54 --- Command line to compile the samples: gcc -Wall -O2 -ffixed-i0 -ffixed-i1 -ffixed-i2 -ffixed-i3 -fno-strict-aliasing-fno-delayed-branch -fno-reorder-blocks -fno-optimize-sibling-calls -Wa,-Av9a -I. -D_GNU_SOURCE -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE -save-temps -da -c op.c -o op.o gcc -v output: Using built-in specs. Target: sparc-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,fortran,objc,obj-c++,treelang --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-libstdcxx-debug --enable-mpfr --with-cpu=v8 --enable-checking=release sparc-linux-gnu Thread model: posix gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32874
[Bug fortran/32875] New: Not Implemented: complex character array constructor
write(6,*) (/(S1(i),i=1,3,-1)/) CONTAINS FUNCTION S1(i) CHARACTER(LEN=1) :: S1 INTEGER :: I S1="123456789"(i:i) END FUNCTION S1 END -- Summary: Not Implemented: complex character array constructor Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32875
[Bug tree-optimization/32824] Missed reduction vectorizer after store to global is LIM'd
--- Comment #4 from dorit at gcc dot gnu dot org 2007-07-24 08:59 --- Just for the record - as we discussed last week, there are two ways to solve this problem - either have LIM leave behind it cleaner code (smthing like copy-prop + dce to eliminate the extra copy stmts), or improve the reduction detection code in the vectorizer, which is something we want to do anyway. Actually this looks like a duplicate of PR25621. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32824
[Bug target/25413] wrong alignment or incorrect address computation in vectorized code on Pentium 4 SSE
--- Comment #13 from dorit at gcc dot gnu dot org 2007-07-24 09:05 --- David, can you confirm that this PR can now be closed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25413
[Bug c++/30535] [4.2 regression] ICE with invalid template operator
--- Comment #4 from paolo at gcc dot gnu dot org 2007-07-24 09:18 --- Subject: Bug 30535 Author: paolo Date: Tue Jul 24 09:18:39 2007 New Revision: 126871 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126871 Log: /cp 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/30535 * pt.c (unify): Never pass error_mark_node to template_decl_level. /testsuite 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/30535 * g++.dg/template/operator10.C: New. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/template/operator10.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/pt.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30535
[Bug c++/30535] [4.2 regression] ICE with invalid template operator
--- Comment #5 from pcarlini at suse dot de 2007-07-24 09:20 --- Fixed for 4.2.2. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30535
[Bug libfortran/32841] [4.3 regression libfortran] HUGE(1.0d0) is written a +Infinity on Darwin8
--- Comment #11 from dominiq at lps dot ens dot fr 2007-07-24 09:31 --- The regression occured between revisions 123612 and 123624, see: http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00300.html http://gcc.gnu.org/ml/gcc-testresults/2007-04/msg00311.html The most likely candidate is revision 123623, though I did not see anything obviously wrong. Note that writing HUGE(1.0) gives the expected result: print *, huge(1.0), huge(1.0d0) end 3.4028235E+38 +Infinity -- dominiq at lps dot ens dot fr changed: What|Removed |Added Component|testsuite |libfortran Summary|FAIL: |[4.3 regression libfortran] |gfortran.dg/edit_real_1.f90 |HUGE(1.0d0) is written a |on Darwin8 |+Infinity on Darwin8 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32841
[Bug fortran/25071] dummy argument larger than actual argument
--- Comment #6 from burnus at gcc dot gnu dot org 2007-07-24 09:42 --- I believe this is fixed by PR30940. The first example gives: Warnung: Actual argument contains too few elements for dummy argument 'i' (4/6) at (1) The second example: Warnung: Character length of actual argument shorter than of dummy argument 'y' (10/20) at (1) It currently gives only warnings since I failed to get any comments when an error and when only a warning should be given. Missing is the check for array element designators: PR32616. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||burnus at gcc dot gnu dot ||org Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25071
[Bug bootstrap/32829] CVS bootstrap failure with as: unrecognised option -Qy
--- Comment #6 from brian dot sidebotham at gmail dot com 2007-07-24 10:05 --- I can successfully build gcc cvs if I have the install dir in my $PATH so I expect this is my fault. Apologies for taking up anyone's time! -- brian dot sidebotham at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32829
[Bug fortran/32875] Not Implemented: complex character array constructor
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 10:09 --- Error message: fatal error: gfc_todo: Not Implemented: complex character array constructors compilation terminated. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-24 10:09:58 date|| Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32875
[Bug c/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-24 10:11 ---
The problem seems to be a backend one(?). What happens is that for
signed char return_sc (signed char sc)
{
return sc;
}
the return value is now zero-extended instead of sign-extended (the sign
extension was done in the C frontend code). The C standard in 6.8.6.4
specifies that for the return statement _only_ if the expression has
a different type from the return type of the function then
'the value is converted as if by assignment to an object having the return
type of the function'. Which reading either way doesn't specify whether
the return value is implicitly sign-extended or not (AFAIK whether in
this case the value is sign or zero extended should be / is specified by the
target ABI).
On x86_64 we get
return_sc:
.LFB12:
movl%edi, %eax
ret
...
movl$-127, %edi
callreturn_sc
which is why we may be lucky here(?). On i686 we pass on the stack like
return_sc:
pushl %ebp
movl%esp, %ebp
movzbl 8(%ebp), %eax
popl%ebp
ret
...
movl$-127, (%esp)
callreturn_sc
explicitly doing zero-extension. Now the libffi testcase explicitly checks
for sign-extension(!) of the return value:
for (sc = (signed char) -127;
sc < (signed char) 127; sc++)
{
ffi_call(&cif, FFI_FN(return_sc), &rint, values);
CHECK(rint == (ffi_arg) sc);
}
as rint is of type ffi_arg (unsigned long) and sc is signed char. I wonder
whether this is desired or not. Andreas?
Micha, how is promotion of the return value specified in the x86 ABI?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||matz at suse dot de,
||andreast at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug c/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-24 10:13 ---
The following is a function that is now differently compiled on both x86_64 and
i686:
signed char return_sc (signed char *sc)
{
return *sc;
}
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2007-07-24 10:13:13
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-24 10:25 --- So, my final conclusion would be that this is a testsuite bug because whether we do zero or sign extension for returns in a register does not matter for valid uses of this return value. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |testsuite http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-24 10:27 ---
Index: return_sc.c
===
--- return_sc.c (revision 126678)
+++ return_sc.c (working copy)
@@ -30,7 +30,7 @@ int main (void)
sc < (signed char) 127; sc++)
{
ffi_call(&cif, FFI_FN(return_sc), &rint, values);
- CHECK(rint == (ffi_arg) sc);
+ CHECK((signed char) rint == sc);
}
exit(0);
}
?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug c++/32561] [4.3 regression] ICE with duplicate template parameter
--- Comment #2 from paolo at gcc dot gnu dot org 2007-07-24 11:08 --- Subject: Bug 32561 Author: paolo Date: Tue Jul 24 11:08:27 2007 New Revision: 126873 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126873 Log: /cp 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/29001 * typeck.c (check_return_expr): Do not pass a null argument to null_ptr_cst_p. 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32561 * decl.c (redeclaration_error_message): Call DECL_ANON_UNION_VAR_P only on VAR_DECL. /testsuite 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/29001 * g++.dg/init/new22.C: New. 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32561 * g++.dg/template/crash67.C: New. Added: trunk/gcc/testsuite/g++.dg/init/new22.C trunk/gcc/testsuite/g++.dg/template/crash67.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32561
[Bug c++/29001] ICE on invalid return from operator new
--- Comment #3 from paolo at gcc dot gnu dot org 2007-07-24 11:08 --- Subject: Bug 29001 Author: paolo Date: Tue Jul 24 11:08:27 2007 New Revision: 126873 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126873 Log: /cp 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/29001 * typeck.c (check_return_expr): Do not pass a null argument to null_ptr_cst_p. 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32561 * decl.c (redeclaration_error_message): Call DECL_ANON_UNION_VAR_P only on VAR_DECL. /testsuite 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/29001 * g++.dg/init/new22.C: New. 2007-07-24 Paolo Carlini <[EMAIL PROTECTED]> PR c++/32561 * g++.dg/template/crash67.C: New. Added: trunk/gcc/testsuite/g++.dg/init/new22.C trunk/gcc/testsuite/g++.dg/template/crash67.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29001
[Bug c++/32561] [4.3 regression] ICE with duplicate template parameter
--- Comment #3 from pcarlini at suse dot de 2007-07-24 11:09 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32561
[Bug c++/29001] ICE on invalid return from operator new
--- Comment #4 from pcarlini at suse dot de 2007-07-24 11:09 --- Fixed. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29001
[Bug fortran/32842] User operator / allocateable array: Wrong code
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 11:20 --- Patch: http://gcc.gnu.org/ml/gcc-patches/2007-07/msg01709.html See also PR 31205. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32842
[Bug testsuite/32843] [4.3 Regression] : libffi.call/return_sc.c
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-07-24 11:47 --- The 32bit psABI specifies Integral Arguments as 'Functions pass all integer-valued arguments as words, expanding or padding signed or unsigned bytes and halfwords as needed'. For return values the best I can find is 'A function that returns an integral or pointer value places its result in register %eax.' Both are not exactly clear whether sign- or zero-extension is required. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32843
[Bug middle-end/32856] Invalid optimization in the face of aliasing
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-07-24 12:09 ---
You may only access union members through the union, not through other
pointers.
GCC is perfectly valid in caching n->next in the first example. So, for
comment #4, it is true that &u.a.n.next == &u.b.n.prev, but you have to do
accesses to n->next and n->prev through the _union_, otherwise the example
is not valid. So you you would need
struct node {
union u *prev;
union u *next;
};
union {
struct {
void* unused;
struct node n;
} a;
struct node b;
} u;
or another creative way of doing all accesses to ->prev and ->next through
the union type.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32856
[Bug tree-optimization/32825] Reduction with nonzero start (arbitrary also) causes an extra add to happen
--- Comment #3 from dorit at gcc dot gnu dot org 2007-07-24 13:05 --- (In reply to comment #1) > ... We actually had both options in the vectorizer for a while > (guarded by ADJUST_IN_EPILOG hard-coded #define), however we didn't know how > to > choose between the two options (cost wise), so we just arbitrarily chose one. > Now that we're starting to build a cost model we may try to evaluate which of > the two options to generate. for the record - this was the patch that removed the second option: 2007-04-18 Dorit Nuzman <[EMAIL PROTECTED]> * tree-vect-transform.c (get_initial_def_for_reduction): Clean away the unused code for reduction without adjust-in-epilog to simplify the function. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32825
[Bug fortran/31259] ICE on elemental character function
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 13:28 ---
The following patch works for the original example; it also works in principle
for the additional example, but there the error message is printed three times.
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c (revision 126873)
+++ gcc/fortran/expr.c (working copy)
@@ -2397,6 +2397,15 @@
break;
}
+ if (sym->attr.dummy && sym->ns->proc_name != NULL
+ && sym->ns->proc_name->attr.elemental)
+ {
+ gfc_error ("Dummy argument '%s' of elemental function '%s' "
+"cannot appear in a specification expression at %L",
+sym->name, sym->ns->proc_name->name, &e->where);
+ break;
+ }
+
/* gfc_is_formal_arg broadcasts that a formal argument list is being
processed in resolve.c(resolve_formal_arglist). This is done so
that host associated dummy array indices are accepted (PR23446).
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 126873)
+++ gcc/fortran/resolve.c (working copy)
@@ -3771,7 +3779,7 @@
if (!seen)
{
if (specification_expr)
- gfc_error ("Variable '%s',used in a specification expression, "
+ gfc_error ("Variable '%s', used in a specification expression,
"
"is referenced at %L before the ENTRY statement "
"in which it is a parameter",
sym->name, &cs_base->current->loc);
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
CC||burnus at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31259
[Bug fortran/29962] Initialization expressions checking in gfc_intrinsic_func_interface
--- Comment #9 from burnus at gcc dot gnu dot org 2007-07-24 13:31 --- Daniel, could you update the bug status; e.g. mark it as fixed or write what still needs to be done. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug fortran/32876] New: Wrongly accepts private items in public NAMELISTs
integer,private :: i namelist /c/ i is correctly diagnosed as invalid: "PRIVATE symbol '%s' cannot be member of PUBLIC namelist at %L"; however, for derived types this fails. Note that NAG f95 only gives an error for "B" and not for "A": Error: mod.f90, line 14: PUBLIC NAMELIST /B/ has member T2 with PRIVATE components (I don't know in how far "A" is valid or what happens if T1 or T2 contains other type(*)s which are private.) module x type tp1 integer, private :: i end type tp1 type tp2 private integer :: i end type tp2 type(tp1) :: t1 type(tp2) :: t2 integer :: j1,j2 namelist /a/ t1,j namelist /b/ t2,j end module x -- Summary: Wrongly accepts private items in public NAMELISTs 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: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32876
[Bug fortran/32682] [4.3 Regression] ICE in gfc_trans_array_constructor, at fortran/trans-array.c:1664
--- Comment #5 from dfranke at gcc dot gnu dot org 2007-07-24 13:45 --- Paul, any plans to get the fix from comment #3 into trunk? -- dfranke at gcc dot gnu dot org changed: What|Removed |Added CC||dfranke at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32682
[Bug fortran/31818] Wrongly accepts namelists with assumed-sized arrays
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 13:49 ---
Index: resolve.c
===
--- resolve.c (revision 126873)
+++ resolve.c (working copy)
@@ -7040,6 +7044,13 @@ resolve_fl_namelist (gfc_symbol *sym)
/* Reject namelist arrays that are not constant shape. */
for (nl = sym->namelist; nl; nl = nl->next)
{
+ if (nl->sym->as->type != AS_EXPLICIT)
+ {
+ gfc_error ("Variable '%s' at %L must have an explicit shape to "
+"be in a NAMELIST", nl->sym->name, &sym->declared_at);
+ return FAILURE;
+ }
+
if (is_non_constant_shape_array (nl->sym))
{
gfc_error ("The array '%s' must have constant shape to be "
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31818
[Bug c++/32877] New: Cannot make GCC
While making GCC 3.4.6 I am Getting the following error * ERROR * creating config.h config.h is unchanged echo timestamp > cstamp-h cp ./libgnuintl.h libintl.h cc -c -g -DHAVE_CONFIG_H -I. -I. bindtextdom.c "/usr/include/iso/stddef_iso.h", line 62: invalid type combination cc: acomp failed for bindtextdom.c make[1]: *** [bindtextdom.o] Error 2 make[1]: Leaving directory `/GCC/346GCC/gcc-3.4.6/intl' make: *** [all-intl] Error 2 -- Summary: Cannot make GCC Product: gcc Version: 3.4.6 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: duraivelanc at yahoo dot co dot in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32877
[Bug java/32774] GCJ dumps core when semicolon placed to wrong place (x86, arm_le)
--- Comment #3 from tromey at gcc dot gnu dot org 2007-07-24 14:31 --- Fixed in 4.3. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32774
[Bug java/32758] ecj1 hangs
--- Comment #5 from tromey at gcc dot gnu dot org 2007-07-24 14:33 --- Can you try running ecj with -help or something like that? I'm wondering whether it works at all. Perhaps the bootstrap java interpreter is broken on your machine, or something like that. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-24 14:33:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32758
[Bug libgcj/32836] infinite loop (SIGSEGV) in java::lang::Throwable::fillInStackTrace
--- Comment #6 from tromey at gcc dot gnu dot org 2007-07-24 14:34 --- Yeah, I've seen problems like this as well on occasion. I'm not sure what to do about them however. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-24 14:34:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32836
[Bug libgcj/21821] MAXPATHLEN usage in libjava
--- Comment #9 from tromey at gcc dot gnu dot org 2007-07-24 14:36 --- Sorry I missed this for so long. Please submit these patches to the java-patches mailing list. Thanks. -- tromey at gcc dot gnu dot org changed: What|Removed |Added CC||tromey at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21821
[Bug java/32846] GNU/Hurd fixups
--- Comment #3 from tromey at gcc dot gnu dot org 2007-07-24 14:36 --- FYI -- please submit patches to the java-patches mailing list. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32846
[Bug libstdc++/32878] New: FAIL: 23_containers/bitset/cons/16020.cc execution test
Executing on host: /home/dave/gnu/gcc-4.3/objdir/./gcc/g++ -shared-libgcc -B/hom e/dave/gnu/gcc-4.3/objdir/./gcc -nostdinc++ -L/home/dave/gnu/gcc-4.3/objdir/hppa -linux/libstdc++-v3/src -L/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/ src/.libs -B/home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/bin/ -B/home/dave/opt/gn u/gcc/gcc-4.3.0/hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-l inux/include -isystem /home/dave/opt/gnu/gcc/gcc-4.3.0/hppa-linux/sys-include -g -O2 -D_GLIBCXX_ASSERT -ffunction-sections -fdata-sections -fmessage-length=0 -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gnu/gcc-4.3/objdir/h ppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gnu/gcc-4.3/objdir/hppa-l inux/libstdc++-v3/include -I/home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/libsupc++ -I /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/include/backward -I/home/dave/gnu/gcc-4. 3/gcc/libstdc++-v3/testsuite/util -Wl,--gc-sections /home/dave/gnu/gcc-4.3/gcc/l ibstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc-include bits/stdc++ .h ./libtestc++.a -lm -o ./16020.exe(timeout = 600) PASS: 23_containers/bitset/cons/16020.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gnu/gcc-4.3/objdir/gcc:/home/dave/gnu/gcc -4.3/objdir/hppa-linux/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc-4.3/objdir/g cc:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/./libstdc++-v3/src/.libs:/home/dave/ gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/.libs:/home/dave/gnu/gcc-4.3/objdir/h ppa-linux/libmudflap/.libs:/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libssp/.libs :/home/dave/gnu/gcc-4.3/objdir/hppa-linux/libgomp/.libs:/home/dave/gnu/gcc-4.3/o bjdir/./gcc:/home/dave/gnu/gcc-4.3/objdir/./prev-gcc FAIL: 23_containers/bitset/cons/16020.cc execution test This fail appeared between 20070715 (revision 126659) and 20070716 (revision 126694). -- Summary: FAIL: 23_containers/bitset/cons/16020.cc execution test Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
[Bug middle-end/21137] Convert (a >> 2) & 1 != 0 into a & 4 != 0
--- Comment #9 from rask at sygehus dot dk 2007-07-24 14:56 ---
This is not fully fixed yet. Compile these two functions with -O2
-fdump-tree-original:
void test5_1(int e)
{
if ((e >> 31) & 64)
foo();
}
typedef int myint;
void test5_2(myint e)
{
if ((e >> 31) & 64)
foo();
}
On x86_64-unknown-linux-gnu, I get (4.2.0, 4.2.1 and mainline):
;; Function test5_1 (test5_1)
;; enabled by -tree-original
{
if (e < 0)
{
foo ();
}
}
;; Function test5_2 (test5_2)
;; enabled by -tree-original
{
if (((int) (e >> 31) & 64) != 0)
{
foo ();
}
}
We should get identical dumps for the two functions. I noticed this problem
while trying to fix the original testcase to work targets where an int is
not exactly 32 bits wide. The attached patch to fix the testcase revealed
the problem.
--
rask at sygehus dot dk changed:
What|Removed |Added
CC||rask at sygehus dot dk
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
[Bug middle-end/21137] Convert (a >> 2) & 1 != 0 into a & 4 != 0
--- Comment #10 from rask at sygehus dot dk 2007-07-24 15:00 --- Created an attachment (id=13959) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13959&action=view) Patch to fix testcase when int isn't exactly 32 bits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21137
[Bug target/32878] FAIL: 23_containers/bitset/cons/16020.cc execution test
--- Comment #1 from pcarlini at suse dot de 2007-07-24 15:00 --- I think there is no reason to categorize as libstdc++: almost nothing changed in the library in that timespan (and definitely nothing related) and, AFAICS, all the other targets are fine. Also, I would suggest adding to the report a miminum of additional info about the failure, for the benefit of interested people not having available an hppa-linux system. -- pcarlini at suse dot de changed: What|Removed |Added Component|libstdc++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
[Bug fortran/32879] New: Document algorithm used for random generator
gfortran has: irand() - g77 rand() - g77 random_number() - Fortran 90 The algorithm used is different. Expected: - State something about the used algorithm - Point rand() users to random_number() as this algorithm is seemingly better. (or make at least clear(er) that the algorithms are different) Cf. http://gcc.gnu.org/ml/fortran/2007-07/msg00454.html > There are two random number generators in gfortran, one is a simple modulo > generator that is there for compatibility with g77, this is what you get when > you call RAND(). > > The other is the RNG that implements the Fortran 90 RANDOM_NUMBER intrinsic. > [...] George Marsaglia's KISS (Keep It Simple Stupid) -- Summary: Document algorithm used for random generator Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: documentation 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=32879
[Bug java/32862] bug in EnumMap implementation
--- Comment #2 from cvs-commit at developer dot classpath dot org 2007-07-24 15:27 --- Subject: Bug 32862 CVSROOT:/cvsroot/classpath Module name:classpath Changes by: Tom Tromey 07/07/24 15:26:36 Modified files: . : ChangeLog java/util : EnumMap.java Log message: PR java/32862: * java/util/EnumMap.java (get): Special case emptySlot. (clone): Rewrote. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&r1=1.9354&r2=1.9355 http://cvs.savannah.gnu.org/viewcvs/classpath/java/util/EnumMap.java?cvsroot=classpath&r1=1.4&r2=1.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32862
[Bug target/32878] FAIL: 23_containers/bitset/cons/16020.cc execution test
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-24 15:40 --- Subject: Re: FAIL: 23_containers/bitset/cons/16020.cc execution test > I think there is no reason to categorize as libstdc++: almost nothing changed > in the library in that timespan (and definitely nothing related) and, AFAICS, > all the other targets are fine. Also, I would suggest adding to the report a > miminum of additional info about the failure, for the benefit of interested > people not having available an hppa-linux system. I'm forced to pick a category when reporting a bug. The bug occurred in the libstdc++ testsuite, so I picked that... Personally, I don't like having to categorize bugs on the initial report as this tends to assign responsibility. I avoid picking "target" as essentially all bugs then become the responsibility of the target maintainer. At least 90% of the time, the bug isn't in the backend but the target maintainer has to do the leg work to debug and categorize the bug. On review of the changes in the period, I agree that nothing in libstdc++ changed in the timespan. The only GCC change that might have had an effect is revision 126692. It's possible that this failure was introduced by an update to Debian libc6 version 2.6-2. That could explain why others aren't seeing this problem. I'm not seeing the failure on hpux. I'll provide more info when available. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
[Bug target/29517] Exception handling not thread-safe on AIX5.x and HP-UX
--- Comment #10 from chris at cdnorthamerica dot com 2007-07-24 15:51 --- It doesn't seem to fail using g++ 4.2. Fix or fluke? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug c++/22369] C++ produces mis-matched types with pointers to member functions
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-07-24 15:55 --- This seems to be fixed at least with the patches I have pending. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-05 04:46:23 |2007-07-24 15:55:53 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22369
[Bug fortran/32880] New: User operator & allocatable TYPE components: wrong deallocate
The following program comes - as PR 32842 - from Lawrie Schonfeld's
ISO_VARYING_STRING testsuite. Note this bug remains after the patch for PR
32842 has been applied.
The dump shows:
_gfortran_deallocate (res.chars.data
op_assign_vs_ch (&res, (char[1:10] *) &char_a[5]{lb: 1 sz: 1}, 1);
_gfortran_deallocate (res.chars.data
res = op_concat_vs_ch (&res, (char[1:10] *) &char_a[5]{lb: 1 sz: 1}, 1);
The second deallocate is wrong.
(If you don't have an ISO_VARYING_STRING, you can get it from:
http://www.fortran.com/iso_varying_string.f95 )
program VST28 ! (C) copyright J.L.Schonfelder 1998
use ISO_VARYING_STRING
character(len=10) :: char_a
type(VARYING_STRING) :: res
char_a = "1234567890"
res = char_a(5:5)
res = res//char_a(5:5)
! if(char(res) /= "55") then
!write(*,'(a,''"'',a,''", '',i0)') 'ERROR:Expect "55", got:',char(res),len(res)
! end if
end program VST28
--
Summary: User operator & allocatable TYPE components: wrong
deallocate
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=32880
[Bug c++/22451] C++ front-end produces mis-match types in MODIFY_EXPR (pointer to member functions)
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-24 15:57 --- This seems to be fixed with the patches I have pending. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-12-07 04:28:20 |2007-07-24 15:57:05 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22451
[Bug target/32878] FAIL: 23_containers/bitset/cons/16020.cc execution test
--- Comment #3 from danglin at gcc dot gnu dot org 2007-07-24 16:01 --- The program is segfaulting when compiled at -O2. It doesn't fail at -O0 or -O1. I added -static to make debugging easier. Starting program: /home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/testsuite/16020.xg Program received signal SIGSEGV, Segmentation fault. 0x00010450 in __gnu_debug::_Safe_iterator_base::_M_detach_single ( this=0xc016a081) at ../../../../gcc/libstdc++-v3/src/debug.cc:245 245 if (_M_next) (gdb) bt #0 0x00010450 in __gnu_debug::_Safe_iterator_base::_M_detach_single ( this=0xc016a081) at ../../../../gcc/libstdc++-v3/src/debug.cc:245 #1 0x00010690 in __gnu_debug::_Safe_sequence_base::_M_detach_all ( this=0xc016ab2c) at ../../../../gcc/libstdc++-v3/src/debug.cc:127 #2 0x0001037c in test01 () at /home/dave/gnu/gcc-4.3/objdir/hppa-linux/libstdc++-v3/include/debug/safe_base.h:185 #3 0x00010408 in main () at /home/dave/gnu/gcc-4.3/gcc/libstdc++-v3/testsuite/23_containers/bitset/cons/16020.cc:40 (gdb) p/x $pc $1 = 0x10450 (gdb) disass 0x10440 0x10460 Dump of assembler code from 0x10440 to 0x10460: 0x00010440 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+16>: ldw c(r26),ret0 0x00010444 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+20>: stw ret0,c(r19) 0x00010448 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+24>: ldw c(r26),r20 0x0001044c <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+28>: cmpiclr,= 0,r20,r0 0x00010450 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+32>: stw r19,8(r20) 0x00010454 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+36>: ldw 4(r21),ret0 0x00010458 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+40>: cmpb,=,n r26,ret0,0x10494 <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+100> 0x0001045c <_ZN11__gnu_debug19_Safe_iterator_base16_M_detach_singleEv+44>: ldw 0(r21),ret0 End of assembler dump. (gdb) p/x $r20 $3 = 0x61736800 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
[Bug fortran/32817] inline (pure) accessor functions
--- Comment #3 from jb at gcc dot gnu dot org 2007-07-24 16:03 --- Confirmed. Gfortran should IMHO not do any inlining itself, rather somehow tell the middle-end when inlining is allowed, and let the middle-end optimizer decide when to actually inline. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-24 16:03:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32817
[Bug libstdc++/32851] Sort of vector of template class fails
--- Comment #3 from klra67 at freenet dot de 2007-07-24 16:10 ---
Subject: Re: Sort of vector of template class fails
Am Montag, 23. Juli 2007 23:55 schrieb pinskia at gcc dot gnu dot org:
> This is correct, you need to mark operator< as taking a const this
> variable. Like:
> bool operator<(const card & A)const { return this->id < A.id;};
>
> Once doing that, the program compiles.
You are right, sorry. I am not a C++ expert, and this worked without const on
another compiler, so I got confused. BTW, I find the error message unclear
and not helpful, even now that I understand what is going on.
Thanks!
klaus
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32851
[Bug fortran/32881] New: PURE attribute escapes from contained procedure
The following testcase is AFAICT legal: subroutine foo () integer, pointer :: p => NULL() contains pure function bar (a) integer, intent(in) :: a integer :: bar bar = a end function bar end subroutine foo gfortran refuses to compile it, complaining pure-escape.f90:2.23: integer, pointer :: p => NULL() 1 Error: Bad pointer object in PURE procedure at (1) Remove the pure attribute from the contained function "bar", or the "=> NULL()" initialization of the pointer, and it compiles. Both ifort and the Lahey online checker accept the code, and I can't really see how the standard could say otherwise. My guess is that gfortran thinks foo is also pure, and hence initializing p means that it's saved and thus it complains. -- Summary: PURE attribute escapes from contained procedure Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jb at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32881
[Bug c++/32882] New: Mismatched types with pointer to member functions and -fstrict-aliasing
8.0.min.ii:15: error: non-trivial conversion at assignment
struct
{
X:: * const __pfn;
long int __delta;
} * const *
struct
{
X:: * const __pfn;
long int __delta;
} * const &
__ptr = __ptr.24
which is gimplified from the INIT_EXPR
__ptr = (struct
{
X:: * const __pfn;
long int __delta;
} * const *) _M_access ((union _Any_data *) __source)
where __ptrs type is structurally equivalent to the type the _M_access
return value is converted to, but it has no relationship to it.
The backtrace where this INIT_EXPR is created from is
#0 build2_stat (code=INIT_EXPR, tt=0x2b9977879270, arg0=0x2b997792abb0,
arg1=0x2b99778c2440)
at /space/rguenther/src/svn/pointer_plus/gcc/tree.c:3064
#1 0x004faa41 in split_nonconstant_init (dest=0x2b997792abb0,
init=0x2b99778c2440)
at /space/rguenther/src/svn/pointer_plus/gcc/cp/typeck2.c:553
#2 0x004faea8 in store_init_value (decl=0x2b997792abb0,
init=0x2b99778c2440)
at /space/rguenther/src/svn/pointer_plus/gcc/cp/typeck2.c:626
#3 0x00445eaf in check_initializer (decl=0x2b997792abb0,
init=0x2b99778c2440, flags=0, cleanup=0x7fff34377270)
at /space/rguenther/src/svn/pointer_plus/gcc/cp/decl.c:4892
#4 0x00448f10 in cp_finish_decl (decl=0x2b997792abb0,
init=0x2b99778c2440, init_const_expr_p=0 '\0', asmspec_tree=0x0, flags=0)
at /space/rguenther/src/svn/pointer_plus/gcc/cp/decl.c:5291
#5 0x004498e4 in finish_decl (decl=0x2b997792abb0,
init=0x2b99778c2440, asmspec_tree=0x0)
at /space/rguenther/src/svn/pointer_plus/gcc/cp/decl.c:5452
#6 0x004c4289 in tsubst_expr (t=0x2b9977823480, args=0x2b9977717510,
complain=tf_warning_or_error, in_decl=0x2b9977815d00,
integral_constant_expression_p=0 '\0')
at /space/rguenther/src/svn/pointer_plus/gcc/cp/pt.c:9850
#7 0x004c3353 in tsubst_expr (t=0x2b997780f930, args=0x2b9977717510,
) at /space/rguenther/src/svn/pointer_plus/gcc/cp/pt.c:9771
#8 0x004c5877 in tsubst_expr (t=0x2b997780c7d0, args=0x2b9977717510,
complain=tf_warning_or_error, in_decl=0x2b9977815d00,
integral_constant_expression_p=0 '\0')
at /space/rguenther/src/svn/pointer_plus/gcc/cp/pt.c:9912
#9 0x004ee15b in instantiate_decl (d=0x2b997791bf00, defer_ok=0,
expl_inst_class_mem_p=0 '\0')
at /space/rguenther/src/svn/pointer_plus/gcc/cp/pt.c:14415
#10 0x004eea19 in instantiate_pending_templates (retries=0)
at /space/rguenther/src/svn/pointer_plus/gcc/cp/pt.c:14520
#11 0x0054d6b0 in cp_write_global_declarations ()
at /space/rguenther/src/svn/pointer_plus/gcc/cp/decl2.c:3057
#12 0x00a71ed6 in compile_file ()
at /space/rguenther/src/svn/pointer_plus/gcc/toplev.c:1057
#13 0x00a73aa8 in do_compile ()
at /space/rguenther/src/svn/pointer_plus/gcc/toplev.c:2151
#14 0x00a73b0c in toplev_main (argc=15, argv=0x7fff3437a0f8)
at /space/rguenther/src/svn/pointer_plus/gcc/toplev.c:2183
#15 0x006f17f3 in main (argc=15, argv=0x7fff3437a0f8)
at /space/rguenther/src/svn/pointer_plus/gcc/main.c:35
The strange thing is that w/o -fstrict-aliasing only the trees of
other functions than _M_get_pointer are changed (they get some
change_dynamic_type expressions).
--
Summary: Mismatched types with pointer to member functions and -
fstrict-aliasing
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
OtherBugsDependingO 22368
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
[Bug c++/32882] Mismatched types with pointer to member functions and -fstrict-aliasing
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-07-24 16:19 --- Created an attachment (id=13960) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13960&action=view) testcase (slightly reduced from tr1/3_function_objects/function/8.cc) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
[Bug fortran/32880] User operator & allocatable TYPE components: wrong deallocate
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 16:20 --- Created an attachment (id=13961) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13961&action=view) Reduced test case Reduced test case which does not depend anymore on external files. Coredumps with gfortran, works with NAG f95 and g95. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32880
[Bug target/29517] Exception handling not thread-safe on AIX5.x and HP-UX
--- Comment #11 from dave at hiauly1 dot hia dot nrc dot ca 2007-07-24 16:25 --- Subject: Re: Exception handling not thread-safe on AIX5.x and HP-UX > It doesn't seem to fail using g++ 4.2. Fix or fluke? There were some changes to config/pa/hpux-unwind.h in 2006 that improved unwinding over stubs. If using 4.1 is important, you might try back porting these changes to see if that helps. The 4.1 branch is essentially closed at this point in time. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29517
[Bug c++/32882] Mismatched types with pointer to member functions and -fstrict-aliasing
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-07-24 16:28 --- ./cc1plus -fpreprocessed 8.0.min.ii -quiet -dumpbase 8.cc -auxbase 8 -version -fmessage-length=0 -o /dev/null -std=c++0x -fstrict-aliasing -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
[Bug fortran/32879] Document algorithm used for random generator
--- Comment #1 from jb at gcc dot gnu dot org 2007-07-24 16:30 --- Confirmed, thought the documentation for RANDOM_NUMBER already mentions that it uses KISS, so this applies only to the legacy intrinsics. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-24 16:30:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32879
[Bug c++/32883] New: Regression: reverse_iterator produces valgrind errors
When this code is run with : valgrind --tool=memcheck a.out 5 it produces quite
a few errors. I confirmed this with 4.2.0. The problem is not present in 3.2.2.
Valgrind version is 3.2.3:
#include
using namespace std;
int main()
{
set c;
c.insert(1);
c.insert(2);
c.insert(3);
c.insert(4);
set::reverse_iterator i = c.rbegin();
c.erase((++i).base());
*i;
return 0;
}
A collegue of mine who actually encountered this problem had posted about it
here:
http://groups.google.com/group/comp.lang.c++.moderated/browse_thread/thread/402c7fb95f649314/a58fd22549a56fca
--
Summary: Regression: reverse_iterator produces valgrind errors
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: Raimund dot Merkert at baesystems dot com
GCC host triplet: g++ (GCC) 3.4.3 20050227 (Red Hat 3.4.3-22.1)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32883
[Bug c++/32882] Mismatched types with pointer to member functions and -fstrict-aliasing
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-07-24 16:33 --- Created an attachment (id=13962) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13962&action=view) testcase (more reduced) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32882
[Bug c++/32883] Regression: reverse_iterator produces valgrind errors
--- Comment #1 from Raimund dot Merkert at baesystems dot com 2007-07-24 16:40 --- If I replace *i with ++i, I get basically the same result. It has struck me as weird that this would be the "preferred way" according to Scott Myers, but looking at the implementation bits/stl_iterator.h, this code should definitely not work. So, perhaps it is not a bug after all? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32883
[Bug fortran/32879] Document algorithm used for random generator
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 16:44 --- > Confirmed, thought the documentation for RANDOM_NUMBER already mentions that > it > uses KISS, so this applies only to the legacy intrinsics. Is KISS clear enough? If yes then it indeed only applies to RAND(). http://gcc.gnu.org/onlinedocs/gfortran/IRAND.html http://gcc.gnu.org/onlinedocs/gfortran/RAND.html http://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fNUMBER.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32879
[Bug fortran/32778] pedantic warning: intrinsics that are GNU extensions not part of -std=gnu
--- Comment #2 from dfranke at gcc dot gnu dot org 2007-07-24 16:45 --- Subject: Bug 32778 Author: dfranke Date: Tue Jul 24 16:45:32 2007 New Revision: 126881 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126881 Log: gcc/fortran: 2007-07-24 Daniel Franke <[EMAIL PROTECTED]> PR fortran/32778 * intrinsic.c (add_sym): Do not exclude any symbols, even if not part of the selected standard. (make generic): Likewise. (make alias): Likewise, set standard the alias belongs to. (add_subroutines): Call make_noreturn unconditionally. (check_intrinsic_standard): Change return value to try. (gfc_intrinsic_func_interface): Check return value of above function. (gfc_intrinsic_sub_interface): Likewise. gcc/testsuite: 2007-07-24 Daniel Franke <[EMAIL PROTECTED]> PR fortran/32778 * gfortran.dg/imag_2.f: Removed * gfortran.dg/warn_std_1.f90: New test. * gfortran.dg/warn_std_2.f90: New test. * gfortran.dg/warn_std_3.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/warn_std_1.f90 trunk/gcc/testsuite/gfortran.dg/warn_std_2.f90 trunk/gcc/testsuite/gfortran.dg/warn_std_3.f90 Removed: trunk/gcc/testsuite/gfortran.dg/imag_2.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/intrinsic.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32778
[Bug fortran/32778] pedantic warning: intrinsics that are GNU extensions not part of -std=gnu
--- Comment #3 from dfranke at gcc dot gnu dot org 2007-07-24 16:49 --- Closing as fixed. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32778
[Bug c++/32883] Regression: reverse_iterator produces valgrind errors
--- Comment #2 from pcarlini at suse dot de 2007-07-24 16:54 --- This code is invalid, as Carl Barron, Greg Herlihy and others explained very carefully in that thread. -- pcarlini at suse dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32883
[Bug fortran/32867] [4.3 Regression] 459.GemsFDTD in SPEC CPU 2006 fails to compile
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-07-24 16:57 --- Subject: Bug 32867 Author: dfranke Date: Tue Jul 24 16:57:02 2007 New Revision: 126882 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126882 Log: gcc/fortran: 2007-07-24 Daniel Franke <[EMAIL PROTECTED]> PR fortran/32867 * expr.c (check_init_expr): Simplify matched functions. gcc/testsuite: 2007-07-24 Daniel Franke <[EMAIL PROTECTED]> PR fortran/32867 * fortran.dg/initialization_10.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/initialization_10.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug fortran/32867] [4.3 Regression] ICE on nested initialization expressions
--- Comment #15 from dfranke at gcc dot gnu dot org 2007-07-24 16:59 --- Changed the title to reflect the actual problem. Closing as fixed. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.3 Regression]|[4.3 Regression] ICE on |459.GemsFDTD in SPEC CPU|nested initialization |2006 fails to compile |expressions Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32867
[Bug c++/32877] Cannot make GCC
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|blocker |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32877
[Bug fortran/32884] New: ICE: Accessing non-local variable in PURE function
Using the following invalid program, one gets an ICE NAG f95: Assignment to Z in PURE procedure BAR gfortran: segmentation fault. subroutine foo () integer :: z contains pure function bar (a) integer, intent(in) :: a integer :: bar z = 45 ! <<< bar = a end function bar end subroutine foo -- Summary: ICE: Accessing non-local variable in PURE function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32884
[Bug fortran/32881] PURE attribute escapes from contained procedure
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 17:22 ---
Confirmed.
The problem is that gfc_pure(NULL) is called and thus
sym = gfc_current_ns->proc_name;
is used as procedure symbol, which is "bar" and not "foo".
The following patch fixes this, but I have not regtested it.
Index: expr.c
===
--- expr.c (Revision 126873)
+++ expr.c (Arbeitskopie)
@@ -2734,7 +2743,7 @@
return FAILURE;
}
- is_pure = gfc_pure (NULL);
+ is_pure = gfc_pure (lvalue->symtree->n.sym->ns->proc_name);
if (is_pure && gfc_impure_variable (lvalue->symtree->n.sym))
{
--
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
Keywords||ice-on-invalid-code,
||rejects-valid
Last reconfirmed|-00-00 00:00:00 |2007-07-24 17:22:47
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32881
[Bug target/32878] FAIL: 23_containers/bitset/cons/16020.cc execution test
--- Comment #4 from danglin at gcc dot gnu dot org 2007-07-24 17:27 ---
(gdb) p _M_iterators
$20 = (__gnu_debug::_Safe_iterator_base *) 0xd4820
(gdb) p *_M_iterators
$21 = {_M_sequence = 0x0, _M_version = 0, _M_prior = 0x0, _M_next = 0x0}
(gdb) p _M_const_iterators
$19 = (__gnu_debug::_Safe_iterator_base *) 0xc06be750
(gdb) p *_M_const_iterators
$18 = {_M_sequence = 0xc06be000, _M_version = 0, _M_prior = 0xc06be049,
_M_next = 0xc06be081}
It looks like _M_const_iterators may not be properly initialized.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32878
[Bug fortran/32884] ICE: Accessing non-local variable in PURE function
--- Comment #1 from burnus at gcc dot gnu dot org 2007-07-24 17:33 --- Seemingly the error is detected and only on writing the error the segmentation fault occurs: ==494== Invalid read of size 8 ==494==at 0x41D398: show_locus (error.c:171) ==494==by 0x41D29D: error_print (error.c:521) ==494==by 0x41DB1E: gfc_error (error.c:759) ==494==by 0x45B930: resolve_code (resolve.c:5871) ==494==by 0x45BB10: resolve_codes (resolve.c:8472) ==494==by 0x45BACF: resolve_codes (resolve.c:8464) ==494==by 0x45BB54: gfc_resolve (resolve.c:8491) ==494==by 0x44E507: gfc_parse_file (parse.c:3271) ==494==by 0x472FBD: gfc_be_parse_file (f95-lang.c:301) ==494==by 0x6B4BC3: toplev_main (toplev.c:1044) ==494==by 0x52BEB43: (below main) (in /lib64/libc-2.6.so) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32884
[Bug fortran/32884] ICE: Accessing non-local variable in PURE function
--- Comment #2 from burnus at gcc dot gnu dot org 2007-07-24 18:28 --- Others cannot reproduce it (on i686 & x86_64), but here I can with gfortran-4.1 & 4.2 of SUSE, with the vanilla 4.2 and with 4.3. The problem is for whatever reason the "&code->expr->where" argument to gfc_error(). In error_print the "loc" argument is not NULL, but loc->lb->* point to invalid locations, which gave an memory access error (segfault) in show_locus when accessing lb->file. 484 loc = va_arg (argp, locus *); 486 if (have_l1) (gdb) p loc $8 = (locus *) 0xfdc13a (gdb) p loc->lb $9 = (gfc_linebuf *) 0x610072616200736e (gdb) p loc->lb->file Cannot access memory at address 0x6100726162007376 (gdb) p loc->lb->line Cannot access memory at address 0x610072616200738a (gdb) p loc->lb->file Cannot access memory at address 0x6100726162007376 But no problem for others. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32884
[Bug c/32885] New: Internal compiler error when using -fopenmp -O3 -fno-unit-at-a-time option
Hi, I was trying to compile my Openmp parallel code, and see the effects of turning of f of some optimization parameters. I get an internal compiler error. The whole error is attached below. miner-02:/files4/berkin/kmeans % make OPTFLAGS="-O3 -fno-unit-at-a-time -v -save-temps" /files4/berkin/gcc-4.2.1/bin/gcc -fopenmp -O3 -fno-unit-at-a-time -v -save-temps -c fuzzy_kmeans.c Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../gcc/configure --prefix=/files4/berkin/gcc-4.2.1 --enable-threads Thread model: posix gcc version 4.2.1 /files4/berkin/gcc-4.2.1/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1 -E -quiet -v -D_REENTRANT fuzzy_kmeans.c -mtune=generic -fopenmp -fno-unit-at-a-time -O3 -fpch-preprocess -o fuzzy_kmeans.i ignoring nonexistent directory "/files4/berkin/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/include /files4/berkin/gcc-4.2.1/include /files4/berkin/gcc-4.2.1/lib/gcc/i686-pc-linux-gnu/4.2.1/include /usr/include End of search list. /files4/berkin/gcc-4.2.1/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1 -fpreprocessed fuzzy_kmeans.i -quiet -dumpbase fuzzy_kmeans.c -mtune=generic -auxbase fuzzy_kmeans -O3 -version -fopenmp -fno-unit-at-a-time -o fuzzy_kmeans.s GNU C version 4.2.1 (i686-pc-linux-gnu) compiled by GNU C version 4.2.1. GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 80e6f10ad3e2beca945f13dba64821c7 fuzzy_kmeans.c: In function 'fuzzy_kmeans_cluster': fuzzy_kmeans.c:111: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. make: *** [fuzzy_kmeans.o] Error 1 -- Summary: Internal compiler error when using -fopenmp -O3 -fno- unit-at-a-time option Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: boz283 at ece dot northwestern dot edu GCC build triplet: i686-pc-linux-gnu GCC host triplet: AMD Athlon 2.2ghz GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32885
[Bug bootstrap/32877] Cannot make GCC
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-07-24 18:29 --- >"/usr/include/iso/stddef_iso.h", line 62: invalid type combination What target are you trying to build on? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |bootstrap http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32877
[Bug c/32885] Internal compiler error when using -fopenmp -O3 -fno-unit-at-a-time option
--- Comment #1 from boz283 at ece dot northwestern dot edu 2007-07-24 18:36 --- Created an attachment (id=13963) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13963&action=view) The intermediate file for the problematic source file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32885
[Bug target/32218] [4.2/4.3 Regression] segfault with -O1 -ftree-vectorize
--- Comment #6 from tbm at cyrius dot com 2007-07-24 18:37 --- (In reply to comment #5) > does the fact that no one has responded yet means that this failure cannot be > reproduced anymore? I'll try next week and let you know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32218
[Bug middle-end/32885] Internal compiler error when using -fopenmp -O3 -fno-unit-at-a-time option
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-07-24 18:39 --- Is there a reason why you are using -fno-unit-at-a-time ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32885
[Bug fortran/29962] Initialization expressions
--- Comment #10 from dfranke at gcc dot gnu dot org 2007-07-24 18:41 --- Changed the title as init expressions are not restricted to the previously named function. The following is a list of items I am aware of that need to be done before init expressions are complete: TODO for F95, 7.1.6.1: * nothing?! TODO for F2003, 7.1.6, Specification Inquiry: * "(7)a type parameter inquiry (6.1.3)" TODO for F2003, 7.1.7: * simplifiers for transformational intrinsics other than those listed by F95 * anything related to IEEE (see also PR29383) * "(9) A kind type parameter of the derived type being defined" Please add to this list whatever I may have missed :) -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Summary|Initialization expressions |Initialization expressions |checking in | |gfc_intrinsic_func_interface| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29962
[Bug middle-end/32852] [4.3 Regression] g++.old-deja/g++.jason/synth7.C
--- Comment #3 from hjl at lucon dot org 2007-07-24 18:42 --- It should be fixed by http://gcc.gnu.org/ml/gcc-cvs/2007-07/msg00744.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32852
[Bug middle-end/32885] Internal compiler error when using -fopenmp -O3 -fno-unit-at-a-time option
--- Comment #3 from boz283 at ece dot northwestern dot edu 2007-07-24 18:49 --- I was trying to see how different optimizations effect execution speed of the application, i.e. trying to see if removing that compiler optimization increases/decreases the execution time. Currently i am trying the options specified in the gcc manual, and one of my applications compiles properly, while the one submitted here doesn't. (In reply to comment #2) > Is there a reason why you are using -fno-unit-at-a-time ? > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32885
[Bug fortran/32884] ICE: Accessing non-local variable in PURE function
--- Comment #3 from burnus at gcc dot gnu dot org 2007-07-24 18:53 --- This is a translation bug: msgid "Cannot assign to variable '%s' in PURE procedure at %L" msgstr "In PURE-Prozedur bei %L kann nicht an Variable »%s« zugewiesen werden" As %L / %s is reverted, gfortran crashes. Solution: Replace %L ... %s by %2$L ... %1$s I reported the bug to the DE language team. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32884
[Bug libfortran/32858] printf-capabilities for runtime_error()
--- Comment #1 from jb at gcc dot gnu dot org 2007-07-24 19:06 --- Confirmed. Also, st_sprintf could be directly replaced by s(n)printf. -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-07-24 19:06:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32858
[Bug regression/32849] Unnecessary %esp inc/decrements in trivial code
--- Comment #8 from pbrook at gcc dot gnu dot org 2007-07-24 19:11 --- You can use -mpreferred-stack-boundary=2 to disable this feature if you know you're never going to need the additional stack alignment. The compiler has know way of knowing whet the rest of your application does, so has to make conservative assumptions. If 16-byte alignment is needed anywhere then all functions must preserve that alignment. Dynamic stack realignment is sufficiently expensive that it's much better to not allow the stack to get misaligned in the first place. -- pbrook at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32849
[Bug fortran/31205] aliased operator assignment produces wrong result
--- Comment #8 from pault at gcc dot gnu dot org 2007-07-24 19:15 --- Subject: Bug 31205 Author: pault Date: Tue Jul 24 19:15:27 2007 New Revision: 126885 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126885 Log: 2007-07-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31205 PR fortran/32842 * trans-expr.c (gfc_conv_function_call): Remove the default initialization of intent(out) derived types. * symbol.c (gfc_lval_expr_from_sym): New function. * matchexp.c (gfc_get_parentheses): Return argument, if it is character and posseses a ref. * gfortran.h : Add prototype for gfc_lval_expr_from_sym. * resolve.c (has_default_initializer): Move higher up in file. (resolve_code): On detecting an interface assignment, check if the rhs and the lhs are the same symbol. If this is so, enclose the rhs in parenetheses to generate a temporary and prevent any possible aliasing. (apply_default_init): Remove code making the lval and call gfc_lval_expr_from_sym instead. (resolve_operator): Give a parentheses expression a type- spec if it has no type. * trans-decl.c (gfc_trans_deferred_vars): Apply the a default initializer, if any, to an intent(out) derived type, using gfc_lval_expr_from_sym and gfc_trans_assignment. Check if the dummy is present. 2007-07-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31205 * gfortran.dg/alloc_comp_basics_1.f90 : Restore number of "deallocates" to 24, since patch has code rid of much spurious code. * gfortran.dg/interface_assignment_1.f90 : New test. PR fortran/32842 * gfortran.dg/interface_assignment_2.f90 : New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/matchexp.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31205
[Bug fortran/32842] User operator / allocateable array: Wrong code
--- Comment #4 from pault at gcc dot gnu dot org 2007-07-24 19:15 --- Subject: Bug 32842 Author: pault Date: Tue Jul 24 19:15:27 2007 New Revision: 126885 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126885 Log: 2007-07-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31205 PR fortran/32842 * trans-expr.c (gfc_conv_function_call): Remove the default initialization of intent(out) derived types. * symbol.c (gfc_lval_expr_from_sym): New function. * matchexp.c (gfc_get_parentheses): Return argument, if it is character and posseses a ref. * gfortran.h : Add prototype for gfc_lval_expr_from_sym. * resolve.c (has_default_initializer): Move higher up in file. (resolve_code): On detecting an interface assignment, check if the rhs and the lhs are the same symbol. If this is so, enclose the rhs in parenetheses to generate a temporary and prevent any possible aliasing. (apply_default_init): Remove code making the lval and call gfc_lval_expr_from_sym instead. (resolve_operator): Give a parentheses expression a type- spec if it has no type. * trans-decl.c (gfc_trans_deferred_vars): Apply the a default initializer, if any, to an intent(out) derived type, using gfc_lval_expr_from_sym and gfc_trans_assignment. Check if the dummy is present. 2007-07-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31205 * gfortran.dg/alloc_comp_basics_1.f90 : Restore number of "deallocates" to 24, since patch has code rid of much spurious code. * gfortran.dg/interface_assignment_1.f90 : New test. PR fortran/32842 * gfortran.dg/interface_assignment_2.f90 : New test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/matchexp.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/fortran/trans-decl.c trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/alloc_comp_basics_1.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32842
[Bug fortran/32842] User operator / allocateable array: Wrong code
--- Comment #5 from pault at gcc dot gnu dot org 2007-07-24 19:16 --- Subject: Bug 32842 Author: pault Date: Tue Jul 24 19:16:36 2007 New Revision: 126886 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=126886 Log: 2007-07-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31205 PR fortran/32842 * trans-expr.c (gfc_conv_function_call): Remove the default initialization of intent(out) derived types. * symbol.c (gfc_lval_expr_from_sym): New function. * matchexp.c (gfc_get_parentheses): Return argument, if it is character and posseses a ref. * gfortran.h : Add prototype for gfc_lval_expr_from_sym. * resolve.c (has_default_initializer): Move higher up in file. (resolve_code): On detecting an interface assignment, check if the rhs and the lhs are the same symbol. If this is so, enclose the rhs in parenetheses to generate a temporary and prevent any possible aliasing. (apply_default_init): Remove code making the lval and call gfc_lval_expr_from_sym instead. (resolve_operator): Give a parentheses expression a type- spec if it has no type. * trans-decl.c (gfc_trans_deferred_vars): Apply the a default initializer, if any, to an intent(out) derived type, using gfc_lval_expr_from_sym and gfc_trans_assignment. Check if the dummy is present. 2007-07-24 Paul Thomas <[EMAIL PROTECTED]> PR fortran/31205 * gfortran.dg/alloc_comp_basics_1.f90 : Restore number of "deallocates" to 24, since patch has code rid of much spurious code. * gfortran.dg/interface_assignment_1.f90 : New test. PR fortran/32842 * gfortran.dg/interface_assignment_2.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/interface_assignment_1.f90 trunk/gcc/testsuite/gfortran.dg/interface_assignment_2.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32842
