[Bug c++/30108] internal compiler error: in make_decl_rtl, at varasm.c:890
--- Comment #7 from rhaschke at techfak dot uni-bielefeld dot de 2006-12-08 08:08 --- You are right. The return type of STATE and the actual methods differ. Actually they should have the same type, i.e.: typedef BaseRobot::STATE (BaseRobot::*STATE)(int); STATE ready (int); ... Because the recursive type definition for STATE is not supported, I need the detour using PseudoState. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30108
[Bug c++/29732] [4.0/4.1/4.2 regression] ICE on invalid friend declaration
--- Comment #3 from mmitchel at gcc dot gnu dot org 2006-12-08 08:10 --- Fixed in 4.3.0. -- mmitchel at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.0/4.1/4.2/4.3 regression]|[4.0/4.1/4.2 regression] ICE |ICE on invalid friend |on invalid friend |declaration |declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29732
[Bug libfortran/30114] Inquire formatted yields erroneous results
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-08 08:23 --- Created an attachment (id=12770) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12770&action=view) Test program With the program below I get with NAG f95, sunf95 and ifort: Inquire by UNIT Non-existing, closed file: FORMATTED = UNKNOWN UNFORMATTED = UNKNOWN FORM = UNDEFINED Existing, closed file: FORMATTED = UNKNOWN UNFORMATTED = UNKNOWN FORM = UNDEFINED Existing, opened file: FORMATTED = NO UNFORMATTED = YES FORM = UNFORMATTED Inquire by FILE NAME Non-existing, closed file: FORMATTED = UNKNOWN UNFORMATTED = UNKNOWN FORM = UNDEFINED Existing, closed file: FORMATTED = UNKNOWN UNFORMATTED = UNKNOWN FORM = UNDEFINED Existing, opened file: FORMATTED = NO UNFORMATTED = YES FORM = UNFORMATTED Whereas gfortran (and g95) give: Inquire by UNIT Non-existing, closed file: FORMATTED = UNKNOWN UNFORMATTED = UNKNOWN FORM = UNDEFINED Existing, closed file: FORMATTED = UNKNOWN UNFORMATTED = UNKNOWN FORM = UNDEFINED Existing, opened file: FORMATTED = YES UNFORMATTED = YES FORM = UNFORMATTED Inquire by FILE NAME Non-existing, closed file: FORMATTED = UNKNOWN UNFORMATTED = UNKNOWN FORM = UNDEFINED Existing, closed file: FORMATTED = YES UNFORMATTED = YES FORM = UNDEFINED Existing, opened file: FORMATTED = YES UNFORMATTED = YES FORM = UNFORMATTED The standard says: "The scalar-default-char-variable in the FORMATTED= specifier is assigned the value YES if FORMATTED is included in the set of allowed forms for the file, NO if FORMATTED is not included in the set of allowed forms for the file, and UNKNOWN if the processor is unable to determine whether or not FORMATTED is included in the set of allowed forms for the file." I have actually some problems to interpret this properly (cf. also PR 29578). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30114
Picasso Events Team
Take the Lead with Us! www.picassome.com
[Bug driver/30091] specs file: [EMAIL PROTECTED]' not documented
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-08 09:25 --- specs are an internal format really. It is very subject to change each release. Also some time in the future we might decide to get rid of the specs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30091
[Bug libfortran/30114] Inquire formatted yields erroneous results
--- Comment #2 from burnus at gcc dot gnu dot org 2006-12-08 09:25 --- I asked now at computer.lang.fortran for advise what is ment by by the (UN)FORMATTED specifier of INQUIRE http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/cd8524acdbea6b6e/ One reliable way to test whether a file is opened for (un)formatted read/write is the FORM specifier; its definition is unambiguious in the standard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30114
[Bug fortran/27546] IMPORT is broken
--- Comment #14 from burnus at gcc dot gnu dot org 2006-12-08 09:46 --- Subject: Bug 27546 Author: burnus Date: Fri Dec 8 09:45:44 2006 New Revision: 119651 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119651 Log: fortran/ 2006-12-08 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/27546 * trans-decl.f90 (gfc_create_module_variable): Allow imported symbols in interface bodys in modules. testsuite/ 2006-12-08 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/27546 * gfortran.dg/import4.f90: New test for IMPORT in modules. Added: trunk/gcc/testsuite/gfortran.dg/import4.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
[Bug fortran/27546] IMPORT is broken
--- Comment #15 from burnus at gcc dot gnu dot org 2006-12-08 09:50 --- Mark fixed. Hopefully, I didn't miss anything. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27546
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #16 from cvs-commit at developer dot classpath dot org 2006-12-08 10:30 --- Subject: Bug 29272 CVSROOT:/cvsroot/classpath Module name:classpath Branch: generics-branch Changes by: Mark Wielaard 06/12/08 10:30:10 Modified files: . : ChangeLog gnu/xml/dom: DomAttr.java DomNode.java gnu/xml/stream : SAXParser.java XMLStreamWriterImpl.java javax/xml/parsers: DocumentBuilderFactory.java javax/xml/validation: SchemaFactory.java Log message: 2006-12-06 Ben Konrath <[EMAIL PROTECTED]> Fixes PR 29853. * gnu/xml/dom/DomAttr.java: Don't report mutation if oldValue and newValue are the same. * gnu/xml/dom/DomNode.java: Set parent if null during mutation. 2006-12-06 Chris Burdess <[EMAIL PROTECTED]> Fixes PR 29272. * javax/xml/parsers/DocumentBuilderFactory.java: Fix broken Javadoc. * gnu/xml/stream/SAXParser.java: Fix file descriptor leak. 2006-12-06 Chris Burdess <[EMAIL PROTECTED]> Fixes PR 29264. * gnu/xml/stream/XMLStreamWriterImpl.java: Allow arbitrary text in writeDTD method. 2006-12-056 Chris Burdess <[EMAIL PROTECTED]> Fixes PR 28816. * javax/xml/validation/SchemaFactory.java: Use correct algorithm to discover schema factory implementation class. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&only_with_tag=generics-branch&r1=1.2386.2.358&r2=1.2386.2.359 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/dom/DomAttr.java?cvsroot=classpath&only_with_tag=generics-branch&r1=1.1.2.3&r2=1.1.2.4 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/dom/DomNode.java?cvsroot=classpath&only_with_tag=generics-branch&r1=1.1.2.10&r2=1.1.2.11 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/stream/SAXParser.java?cvsroot=classpath&only_with_tag=generics-branch&r1=1.14.2.4&r2=1.14.2.5 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/stream/XMLStreamWriterImpl.java?cvsroot=classpath&only_with_tag=generics-branch&r1=1.1.2.4&r2=1.1.2.5 http://cvs.savannah.gnu.org/viewcvs/classpath/javax/xml/parsers/DocumentBuilderFactory.java?cvsroot=classpath&only_with_tag=generics-branch&r1=1.1.2.5&r2=1.1.2.6 http://cvs.savannah.gnu.org/viewcvs/classpath/javax/xml/validation/SchemaFactory.java?cvsroot=classpath&only_with_tag=generics-branch&r1=1.1.2.5&r2=1.1.2.6 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug middle-end/29272] [4.2 Regression] memcpy optimization causes wrong-code
--- Comment #17 from cvs-commit at developer dot classpath dot org 2006-12-08 10:32 --- Subject: Bug 29272 CVSROOT:/cvsroot/classpath Module name:classpath Branch: classpath-0_93-branch Changes by: Mark Wielaard 06/12/08 10:31:50 Modified files: . : ChangeLog gnu/xml/dom: DomAttr.java DomNode.java gnu/xml/stream : SAXParser.java XMLStreamWriterImpl.java javax/xml/parsers: DocumentBuilderFactory.java javax/xml/validation: SchemaFactory.java Log message: 2006-12-06 Ben Konrath <[EMAIL PROTECTED]> Fixes PR 29853. * gnu/xml/dom/DomAttr.java: Don't report mutation if oldValue and newValue are the same. * gnu/xml/dom/DomNode.java: Set parent if null during mutation. 2006-12-06 Chris Burdess <[EMAIL PROTECTED]> Fixes PR 29272. * javax/xml/parsers/DocumentBuilderFactory.java: Fix broken Javadoc. * gnu/xml/stream/SAXParser.java: Fix file descriptor leak. 2006-12-06 Chris Burdess <[EMAIL PROTECTED]> Fixes PR 29264. * gnu/xml/stream/XMLStreamWriterImpl.java: Allow arbitrary text in writeDTD method. 2006-12-056 Chris Burdess <[EMAIL PROTECTED]> Fixes PR 28816. * javax/xml/validation/SchemaFactory.java: Use correct algorithm to discover schema factory implementation class. CVSWeb URLs: http://cvs.savannah.gnu.org/viewcvs/classpath/ChangeLog?cvsroot=classpath&only_with_tag=classpath-0_93-branch&r1=1.8897.2.14&r2=1.8897.2.15 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/dom/DomAttr.java?cvsroot=classpath&only_with_tag=classpath-0_93-branch&r1=1.3&r2=1.3.12.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/dom/DomNode.java?cvsroot=classpath&only_with_tag=classpath-0_93-branch&r1=1.16&r2=1.16.2.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/stream/SAXParser.java?cvsroot=classpath&only_with_tag=classpath-0_93-branch&r1=1.21&r2=1.21.4.1 http://cvs.savannah.gnu.org/viewcvs/classpath/gnu/xml/stream/XMLStreamWriterImpl.java?cvsroot=classpath&only_with_tag=classpath-0_93-branch&r1=1.5&r2=1.5.12.1 http://cvs.savannah.gnu.org/viewcvs/classpath/javax/xml/parsers/DocumentBuilderFactory.java?cvsroot=classpath&only_with_tag=classpath-0_93-branch&r1=1.5&r2=1.5.10.1 http://cvs.savannah.gnu.org/viewcvs/classpath/javax/xml/validation/SchemaFactory.java?cvsroot=classpath&only_with_tag=classpath-0_93-branch&r1=1.5&r2=1.5.6.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29272
[Bug c++/30111] Value-initialization of POD base class doesn't initialize members
--- Comment #4 from gcc-bugzilla at kayari dot org 2006-12-08 10:36 --- Richard, there's no difference between pod() and p() in this case, both are value-initialisations of a POD class, therefore all non-static data members should be value-initialised. I cited 8.5p5 for good reason :) Sun CC 6.1 and 8 and IBM xlC 6 get this right. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30111
[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'
--- Comment #7 from vz-gcc at zeitlins dot org 2006-12-08 11:07 --- Just for my personal education, could you please tell which target(s) pass "char *" differently from "void *" in this context? Thanks! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542
[Bug libgcj/29869] LogManager class loading failure with Tomcat
--- Comment #1 from twisti at complang dot tuwien dot ac dot at 2006-12-08 11:38 --- I can confirm the bug with CACAO and current CVS head. -- twisti at complang dot tuwien dot ac dot at changed: What|Removed |Added CC||twisti at complang dot ||tuwien dot ac dot at http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29869
[Bug testsuite/30119] New: libjava testsuite output is erratic and unhelpful
I have tested the patch for PR rtl-optimization/29858 in revision 119261 on gcc01 (i686-pc-linux-gnu) Compared to a pristine build of revision 119055, these are the additional failures: > FAIL: gcc.dg/visibility-11.c scan-assembler [EMAIL PROTECTED] 14a16,17 > FAIL: gcc.dg/vect/vect-pow-1.c scan-tree-dump pattern recognized > FAIL: gcc.dg/vect/vect-pow-2.c scan-tree-dump pattern recognized 107a111,112 > FAIL: PR18699 execution - gij test > FAIL: PR18699 execution - gij test compared to a pristine build of 119261 (the base version), this are the aditional failures: 110a111,115 > FAIL: PR18699 execution - gij test > FAIL: PR18699 execution - gij test > FAIL: SyncTest execution - gij test > FAIL: SyncTest execution - gij test > FAIL: SyncTest execution - gij test With failures in the gcc core or c++ / libstdc++ testsuite, reproducing failures is very straight forward : you cut & paste the appropriate line(s) from the log file in order, and can thus ovserve the failure interactively, and then use gdb and/or debugging dumps to further investigate. The log file shows this about the PR18699 failure: PASS: PR18699 -O3 output - source compiled test byte compile: /home/amylaar/bld/2006-11-27-29858/i686/gcc/gcj -B/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/ -B/home/amylaar/bld/2006-11-27-29858/i686/gcc/ --encoding=UTF-8 -C -I/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite/../libgcj-4.3.0.jar -g /home/amylaar/bld/2006-11-27-29858/srcw/libjava/testsuite/libjava.lang/PR18699.java -d /home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite 2>@ stdout PASS: PR18699 byte compilation PR18699PR18699 set_ld_library_path_env_vars: ld_library_path=.:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/./libjava/.libs:/home/amylaar/bld/2006-11-27-29858/i686/gcc Setting LD_LIBRARY_PATH to .:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/./libjava/.libs:/home/amylaar/bld/2006-11-27-29858/i686/gcc:.:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/./libjava/.libs:/home/amylaar/bld/2006-11-27-29858/i686/gcc:.:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/./libjava/.libs:/home/amylaar/bld/2006-11-27-29858/i686/gcc:/home/amylaar/bld/2006-11-27-29858/i686/./bfd/.libs:/home/amylaar/bld/2006-11-27-29858/i686/./prev-bfd/.libs:/home/amylaar/bld/2006-11-27-29858/i686/./opcodes/.libs:/home/amylaar/bld/2006-11-27-29858/i686/./prev-opcodes/.libs:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libstdc++-v3/.libs:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libmudflap/.libs:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libssp/.libs:/home/amylaar/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libgomp/.libs:/home/amylaar/bld/2006-11-27-29858/i686/./gcc:/home/amylaar/bld/2006-11-27-29858/i686/./prev-gcc FAIL: PR18699 execution - gij test When I cut & past the line above 'PASS: PR18699 byte compilation', a file named '@' is created, which contains: gcj: stdout: No such file or directory The only README file in the entire libjava testsuite is testsuite/libjava.verify/README.verify . The web documentation on testing http://gcc.gnu.org/install/test.html only has the basic meaning of PASS/ FAIL etc for the benefit of a person who installs the library without modifying any pieces of the GNU compiler collection. I should not be required to reverse-engineer the libjava testsuite before I can interpret/debug test results for my patches to the gcc core. There should be easy-to-follow documentation how I can get from the debugging log to reproducing the failure. Moreover, considering that there is no regession against the baseline for any other part of the GNU compiler collection, and the recent track record of libjava testing, it seems highly likely that the regressions are actually testsuite failures. -- Summary: libjava testsuite output is erratic and unhelpful Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org OtherBugsDependingO 29842,29858 nThis: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
--- Comment #1 from aph at gcc dot gnu dot org 2006-12-08 11:46 --- It's not necessary to do any I/O redirection when byte compiling: just execute the command itself without the "2>" etc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug other/30083] double quotes in Makefile confuse solaris /bin/sh
--- Comment #5 from marc dot glisse at normalesup dot org 2006-12-08 12:19 --- (In reply to comment #4) > Except you did not read instructions so what is the difference? Ok say you forget I mentionned solaris /bin/sh. I just believe it would be more consistant to use single quotes instead of double quotes everywhere a constant string is passed to sed (now it is done everywhere except in 3 places) in this file. The fact that it makes solaris /bin/sh work is a mere coincidence. It is just code cleanup. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30083
[Bug c/30120] New: silent miscompilation of argument passing(?)
Current mainline gcc appears to miscompile the following code:
==begin==
static void foo (double a, double weight, const double *ring, double *phase)
{
*phase = *ring * weight;
}
static void foo2 (void)
{ foo (0, 1, (double*)0, (double*)0); }
static void foo3 (void)
{ foo2(); }
void foo4 (void)
{ foo3(); }
int main(void)
{
double t1=1, c1;
foo(0,1,&t1,&c1);
return (c1>0.5) ? 1:0;
}
===end===
/scratch/martin/libpsht-0.2>gcc -v -O -ffast-math psht_test.c -lm
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: /scratch/martin/gcc/configure
--prefix=/afs/mpa/data/martin/ugcc --enable-languages=c
--enable-checking=release
Thread model: posix
gcc version 4.3.0 20061115 (experimental)
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/cc1 -quiet -v
psht_test.c -quiet -dumpbase psht_test.c -mtune=generic -auxbase psht_test -O
-version -ffast-math -o /tmp/ccSNsfEN.s
ignoring nonexistent directory
"/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/afs/mpa/data/martin/ugcc/include
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/include
/usr/include
End of search list.
GNU C version 4.3.0 20061115 (experimental) (i686-pc-linux-gnu)
compiled by GNU C version 4.3.0 20061115 (experimental).
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: e4c043f86c42a15259a6956a912800d1
as -V -Qy -o /tmp/cc424C9p.o /tmp/ccSNsfEN.s
GNU assembler version 2.16.1 (i686-pc-linux-gnu) using BFD version 2.16.1
/afs/mpa/data/martin/ugcc/libexec/gcc/i686-pc-linux-gnu/4.3.0/collect2
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o
/usr/lib/crti.o
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/crtbegin.o
-L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0
-L/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/../../..
/tmp/cc424C9p.o -lm -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc
--as-needed -lgcc_s --no-as-needed
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/crtfastmath.o
/afs/mpa/data/martin/ugcc/lib/gcc/i686-pc-linux-gnu/4.3.0/crtend.o
/usr/lib/crtn.o
/scratch/martin/libpsht-0.2>./a.out
/scratch/martin/libpsht-0.2>echo $?
0
The correct exit code would be 1.
I did some regression hunting, and the problem appears to have been
introduced to SVN with revision 118859 (introduction of -mx87regparm by Uros
Bizjak).
The compiled code behaves correctly if
- the "-ffast-math" flag is omitted, and/or
- the functions foo2() - foo4() (which are not called anyway) are removed
--
Summary: silent miscompilation of argument passing(?)
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: martin at mpa-garching dot mpg dot de
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=30120
[Bug c/30120] [4.3 Regression] silent miscompilation of argument passing
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-12-08 12:46 ---
Confirmed. Reduced testcase:
static void foo (double a, double weight, const double *ring, double *phase)
{
*phase = *ring * weight;
}
void foo2 (void)
{
foo (0, 1, (double*)0, (double*)0);
}
int main(void)
{
double t1=1, c1;
foo(0, 1,&t1,&c1);
return (c1>0.5) ? 1:0;
}
--
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 |2006-12-08 12:46:41
date||
Summary|silent miscompilation of|[4.3 Regression] silent
|argument passing(?) |miscompilation of argument
||passing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30120
[Bug tree-optimization/17687] sincos tree representation causes extra addressable vars
--- Comment #19 from patchapp at dberlin dot org 2006-12-08 13:10 --- Subject: Bug number PR17687 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/msg00536.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17687
[Bug c/30120] [4.3 Regression] silent miscompilation of argument passing
--- Comment #2 from ubizjak at gmail dot com 2006-12-08 13:54 --- (In reply to comment #1) > Confirmed. Reduced testcase: > We need straighten_stack() in convert_regs_entry() for the case where some arguments are left unused. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|NEW |ASSIGNED Last reconfirmed|2006-12-08 12:46:41 |2006-12-08 13:54:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30120
[Bug inline-asm/23200] [4.0/4.1/4.2/4.3 regression] rejects "i"(&var + 1)
--- Comment #26 from amacleod at redhat dot com 2006-12-08 14:32 --- The new version of TER was just checked into mainline. This should resolve this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug libfortran/30114] Inquire formatted yields erroneous results
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2006-12-08 14:58 --- Yes, the FORM= is what you use if you want to determine the current opened status of a file. We had discussion of this question on list just a few months ago. In the case of (un)formatted= there may be a file or device that would not support unformatted I/O due to internal restrictions on the data set, for example ASCII only. In that case unformatted would just not work. I am not sure whether this is just a legacy feature or whether the standard makers included this for completeness. Regardless, it doe not seem to be very useful. The fact that this has come up again indicates that maybe we need some documentation in the gfortran manual to explain this to users. Intuitively they want to grab the wrong specifier to find out if a file was opened for formatted or unformatted I/O. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30114
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
--- Comment #2 from amylaar at gcc dot gnu dot org 2006-12-08 14:59 --- (In reply to comment #1) > It's not necessary to do any I/O redirection when byte compiling: just execute > the command itself without the "2>" etc. > All right, that gives me a file 'PR18699.class' But how is this actually executed? The next two lines of the log file seem to be only about setting environment variables, and the very next line has the 'FAIL' message. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug rtl-optimization/30121] New: ICE on frtl-abstract-sequences and mthumb.
int i ;
int j;
int main (void)
{
if ( i == 0 )
j = 0xdeadbeef;
else
j = 0xcafebabe;
return j;
}arm-none-eabi-gcc-4.2.0 -frtl-abstract-sequences -O3 -mthumb ../hello.c -da
../hello.c: In function 'main':
../hello.c:14: error: unrecognizable insn:
(insn 87 0 0 (set (reg:SI 0 r0)
(symbol_ref:SI ("*.L6") [flags 0x2])) -1 (nil)
(nil))
../hello.c:14: internal compiler error: in insn_default_length, at
config/arm/arm.md:6051
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Configured with:
/mnt/tools/fsf/build/combined-arm-none-eabi-gcc-4_2-2006-12-08/configure
--target=arm-none-eabi
--prefix=/mnt/tools/fsf/install/arm-none-eabi-gcc-4_2-2006-12-08
--enable-languages=c,c++ --disable-nls --with-newlib --disable-gdbtk
--disable-libssp
Thread model: single
gcc version 4.2.0 20061208 (prerelease)
--
Summary: ICE on frtl-abstract-sequences and mthumb.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ramana dot radhakrishnan at codito dot com
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: arm-none-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30121
[Bug rtl-optimization/30121] ICE on frtl-abstract-sequences and mthumb.
--- Comment #1 from ramana dot radhakrishnan at codito dot com 2006-12-08 15:14 --- The ICE comes from compute_init_costs in rtl-factoring.c where rtx_store is set to be /* Pattern for storing address. */ rtx_store = gen_rtx_SET (VOIDmode, reg, gen_symbol_ref_rtx_for_label (label)); which results in the following pattern being generated which is unrecognizable for the thumb. We need to make compute_rtx_cost more robust to handle such cases. Maybe a recog on the instruction to see if the backend defines such an instruction would be useful. -- ramana dot radhakrishnan at codito dot com changed: What|Removed |Added Summary|ICE on frtl-abstract- |ICE on frtl-abstract- |sequences and mthumb. |sequences and mthumb. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30121
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
--- Comment #3 from aph at gcc dot gnu dot org 2006-12-08 15:20 --- Run it with the libjava/gij PR18699.class -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
--- Comment #4 from amylaar at gcc dot gnu dot org 2006-12-08 15:46 ---
(In reply to comment #3)
> Run it with the libjava/gij PR18699.class
ls -l PR18699.class
-rw-r--r-- 1 amylaar users 1688 2006-12-08 15:52 PR18699.class
[EMAIL
PROTECTED]:~/bld/2006-11-27-29858/i686/i686-pc-linux-gnu/libjava/testsuite$
../gij PR18699.class
Exception in thread "main" java.lang.NoClassDefFoundError: PR18699.class
at gnu.java.lang.MainThread.run(MainThread.java:102)
Caused by: java.lang.ClassNotFoundException: PR18699.class not found in
gnu.gcj.runtime.SystemClassLoader{urls=[file:./],
parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
at java.net.URLClassLoader.findClass(URLClassLoader.java:1080)
at gnu.gcj.runtime.SystemClassLoader.findClass(natSystemClassLoader.cc:27)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.ClassLoader.loadClass(ClassLoader.java:294)
at gnu.java.lang.MainThread.run(MainThread.java:98)
gcc01 does not have jcf-dump, but when I scp the file to my local machine,
I see after the constant table:
Access flags: 0x20 super
This class: 2=PR18699, super: 4=java.util.Observable
Interfaces (count: 2):
- Implements: 6=java.lang.Runnable
- Implements: 8=java.util.Observer
So is this a bug in gij not to find the class in PR18699.class?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug testsuite/30119] libjava testsuite output is erratic and unhelpful
--- Comment #5 from aph at gcc dot gnu dot org 2006-12-08 16:45 --- Set the classpath gij -classpath : PR18699 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30119
[Bug libfortran/30114] Inquire formatted yields erroneous results
--- Comment #4 from burnus at gcc dot gnu dot org 2006-12-08 17:17 --- (In reply to comment #3) > In the case of (un)formatted= there may be a file or device that would > not support unformatted I/O due to internal restrictions on the data set, for > example ASCII only. In that case unformatted would just not work. > I am not sure whether this is just a legacy feature or whether the standard > makers included this for completeness. Regardless, it doe not seem to be very > useful. Well, maybe one can see easily on some systems whether a given file is (un)formatted or not. In terms of values reported: gfortran/g95 say: YES if it can be opened, regardless whether it makes sense or not. -- this avoids false negatives and the file can indeed be opened that way. ifort/sunf95/f95 say: UNKNOWN or - if it is opened only YES to the type where they know that it is the right one. -- This is the (over)careful way to report nothing which could be wrong. I wonder whether it would make sense keep the current implementation for non-connected files and to return UNFORMATTED="NO" for a file, which has been opened as UNFORMATTED and vice versa. I think the number of (non-empty) files, which can be opened both as UNFORMATTED and as FORMATTED is very limited - and if it is opened, accessing it with the wrong method is also not such a good idea. This would make UNFORMATTED/FORMATTED more useful for opened files and be more compatible with legacy code. But this is of cause an implementation choice. (FORM is indeed the better choice and the original bug reported told me in a private mail that he is indeed now using the FORM specifier.) > The fact that this has come up again indicates that maybe we need some > documentation in the gfortran manual to explain this to users. Intuitively > they want to grab the wrong specifier to find out if a file was opened for > formatted or unformatted I/O. I think this is indeed a good idea. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30114
Re: [Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'
On Fri, 2006-12-08 at 11:07 +, vz-gcc at zeitlins dot org wrote: > Just for my personal education, could you please tell which target(s) > pass > "char *" differently from "void *" in this context? A made up target (at least for now). :) -- Pinski
[Bug c/26542] bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*'
--- Comment #8 from pinskia at gmail dot com 2006-12-08 18:17 --- Subject: Re: bogus diagnostic with -pedantic?: format '%p'; expects type 'void*', but argument 2 has type 'A*' On Fri, 2006-12-08 at 11:07 +, vz-gcc at zeitlins dot org wrote: > Just for my personal education, could you please tell which target(s) > pass > "char *" differently from "void *" in this context? A made up target (at least for now). :) -- Pinski -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26542
[Bug fortran/30123] New: Document INQUIRE, especially UNFORMATTED and FORMATTED
We currently don't have any documentation for the INQUIRE statement; it should not be put into the Intrinsic Procedures chapter as it is not an intrinsic procedure. Maybe create a "File Operation I/O Statements" chapter? Inquire should be straight forward (with the problem between Fortran 95 and Fortran 2003; the latter allows at least for all arguments now all kinds rather than only the default kind). Most important is to document the UNFORMATTED and the FORMATTED specifier. Their use is to return whether a file is unformatted or formatted, but this is in practice impossible to tell reliably. (This should be made clear in the documentation.) - possible values UNKNOWN, YES, NO. Returning always "UNKNOWN" would be the most correct answer ;-) Cf. http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/cd8524acdbea6b6e/ Implementation choice of gfortran for both formatted/unformatted: - UNIT of unconnected file (and only preconnected files?) and file name="": UNKNOWN - Filename of existing file (and connected files, queried via UNIT): YES - if it is a file (regular, block/character device, named pipe) NO - if it is a directory UNKNOWN - otherwise Other compilers have often: - UNKNOWN - for unconnected files - YES - for UNFORMATTED, if connected as UNFORMATTED - NO - for FORMATTED if connected as UNFORMATTED (and the last two vice versa if connected as FORMATTED) Most people using FORMATTED or UNFORMATTED actually want to use FORM, values: - UNDEFINED for unconnected files - FORMATTED for as formatted opened files - UNFORMATTED for as unformatted opened files -- Summary: Document INQUIRE, especially UNFORMATTED and FORMATTED 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=30123
[Bug libfortran/30114] Inquire formatted yields erroneous results
--- Comment #5 from burnus at gcc dot gnu dot org 2006-12-08 18:18 --- Close bug as won't fix. I opened PR 30123 for the documentation. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30114
[Bug target/30120] [4.3 Regression] silent miscompilation of argument passing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |target Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30120
[Bug target/30120] [4.3 Regression] silent miscompilation of argument passing
--- Comment #3 from uros at gcc dot gnu dot org 2006-12-08 18:20 --- Subject: Bug 30120 Author: uros Date: Fri Dec 8 18:20:25 2006 New Revision: 119663 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119663 Log: PR target/30120 * reg-stack.c (convert_regs_entry): Mark current argument passing registers as live. * config/i386/i386.h (X87_REGPARM_MAX): Set to 0 to disable passing of float arguments in x87 registers. testsuite/ChangeLog: * gcc.target/i386/x87regparm-1.c: XFAIL. * gcc.target/i386/x87regparm-2.c: XFAIL. * gcc.target/i386/x87regparm-3.c: XFAIL. * gcc.target/i386/x87regparm-4.c: XFAIL. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.h trunk/gcc/reg-stack.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/x87regparm-1.c trunk/gcc/testsuite/gcc.target/i386/x87regparm-2.c trunk/gcc/testsuite/gcc.target/i386/x87regparm-3.c trunk/gcc/testsuite/gcc.target/i386/x87regparm-4.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30120
[Bug rtl-optimization/30113] ICE in trunc_int_for_mode
-- rakdver at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rakdver at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-12-08 07:37:00 |2006-12-08 18:34:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30113
[Bug fortran/29975] [meta-bugs] ICEs with CP2K
--- Comment #27 from patchapp at dberlin dot org 2006-12-08 19:50 --- Subject: Bug number PR29975 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/msg00560.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975
[Bug libgcj/30110] classpath external missing from src.zip
--- Comment #2 from tromey at gcc dot gnu dot org 2006-12-08 20:30 --- Subject: Bug 30110 Author: tromey Date: Fri Dec 8 20:30:14 2006 New Revision: 119664 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119664 Log: 2006-12-08 Ben Konrath <[EMAIL PROTECTED]> PR libgcj/30110: * Makefile.am: Add contents of classpath/external to src.zip. * Makefile.in: Regenerate. Modified: branches/gcc-4_2-branch/libjava/ChangeLog branches/gcc-4_2-branch/libjava/Makefile.am branches/gcc-4_2-branch/libjava/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30110
[Bug libgcj/30110] classpath external missing from src.zip
--- Comment #3 from tromey at gcc dot gnu dot org 2006-12-08 20:33 --- Subject: Bug 30110 Author: tromey Date: Fri Dec 8 20:33:22 2006 New Revision: 119665 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119665 Log: 2006-12-08 Ben Konrath <[EMAIL PROTECTED]> PR libgcj/30110: * Makefile.am: Add contents of classpath/external to src.zip. * Makefile.in: Regenerate. Modified: branches/gcj/gcj-eclipse-merge-branch/libjava/ChangeLog branches/gcj/gcj-eclipse-merge-branch/libjava/Makefile.am branches/gcj/gcj-eclipse-merge-branch/libjava/Makefile.in -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30110
[Bug libgcj/30110] classpath external missing from src.zip
--- Comment #4 from tromey at gcc dot gnu dot org 2006-12-08 20:34 --- I checked it in to 4.2 and to the gcj-eclipse-merge-branch. The latter should be merged to trunk reasonably soon. -- tromey at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30110
[Bug fortran/30068] Ambigous interfaces not detected
--- Comment #11 from pault at gcc dot gnu dot org 2006-12-08 21:00 --- Created an attachment (id=12771) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12771&action=view) Fix for this and pr30096 This one regtests and fixes PR30096. I will submit it tomorrow. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #12768|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30068
[Bug fortran/30096] Interface bug: gfortran falsely detect ambigious interface, scoping problem?
--- Comment #4 from pault at gcc dot gnu dot org 2006-12-08 21:01 --- (In reply to comment #3) > (In reply to comment #2) Fixed by the latest version of the pr30068 patch. 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 Last reconfirmed|2006-12-06 22:20:49 |2006-12-08 21:01:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30096
[Bug tree-optimization/30092] Segmentation fault with -ftreevectorize and SQRT()
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-12-08 21:05 --- Hi Tobias, could write this into a test case for gfortran.dg? If it broke once, we should at make sure it doesn't break again. Thomas -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30092
[Bug c/30124] New: gcc/vec.h line 538 references "vec" which is undefined (should be vec_)
the code reads:
static inline size_t VEC_OP (T,base,embedded_size) \
(int alloc_) \
{ \
return offsetof (VEC(T,base),vec) + alloc_ * sizeof(T);\
} \ ^--- this makes it hardly compileable
--
Summary: gcc/vec.h line 538 references "vec" which is undefined
(should be vec_)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mankatob at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30124
[Bug c/30124] gcc/vec.h line 538 references "vec" which is undefined (should be vec_)
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-08 21:33 ---
offsetof (VEC(T,base),vec)
I see this:
typedef struct VEC(T,B) \
{ \
unsigned num; \
unsigned alloc; \
T vec[1]; \
} VEC(T,B)
There forgo this is invalid, we are looking for the offsetof of the vec element
in VEC(T, base).
--
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=30124
[Bug tree-optimization/30125] New: [4.3 regression] Wrong-code due to aliasing
Since 2006-12-05 the following test is failing (used to be PR 27768): FAIL: g++.dg/opt/alias4.C execution test According to the testresults mailing list, the bug appeared between rev. 119481 ( http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00154.html ) and rev. 119532 ( http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00197.html ) The testcase works correctly with -fno-strict-aliasing. -- Summary: [4.3 regression] Wrong-code due to aliasing Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: wrong-code, monitored Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30125
[Bug tree-optimization/30125] [4.3 regression] Wrong-code due to aliasing
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30125
[Bug tree-optimization/30125] [4.3 regression] Wrong-code due to aliasing
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-12-08 21:45 --- This should have been fixed by: 2006-12-05 Daniel Berlin <[EMAIL PROTECTED]> * tree-ssa-structalias.c (set_used_smts): Re-fix pr29156. Optimize to avoid marking more SMT's as used when they aren't. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30125
[Bug tree-optimization/30125] [4.3 regression] Wrong-code due to aliasing
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-08 21:46 --- In fact it was: http://gcc.gnu.org/ml/gcc-testresults/2006-12/msg00343.html -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30125
[Bug tree-optimization/30125] [4.3 regression] Wrong-code due to aliasing
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-08 22:16 --- Woops wrong testcase. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30125
[Bug tree-optimization/30125] [4.3 regression] Wrong-code due to aliasing
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Keywords||alias http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30125
[Bug tree-optimization/30087] regressions in the gfortran testsuite with -ftree-vectorize
--- Comment #1 from burnus at gcc dot gnu dot org 2006-12-08 22:25 --- Backtrace of the first (second looks similar) #5 0x0077ae99 in tree_class_check_failed (node=0x2b9044b37240, cl=tcc_expression, file=, line=2578, function=0xa8b500 "vect_permute_store_chain") at gcc/tree.c:6409 #6 0x008b7303 in vect_permute_store_chain (dr_chain=0xeb5830, length=2, stmt=0x2b9044b37240, bsi=0x7fff66b46230, result_chain=0x7fff66b46158) at gcc/tree-vect-transform.c:2578 #7 0x008bfcc3 in vectorizable_store (stmt=0x2b9044b37240, bsi=dwarf2_read_address: Corrupted DWARF expression. gcc/tree-vect-transform.c:2835 -- 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=30087
[Bug fortran/30115] allocate() interface pessimizes aliasing
--- Comment #5 from tkoenig at gcc dot gnu dot org 2006-12-08 22:54 ---
(In reply to comment #1)
>if (TYPE_PRECISION (gfc_array_index_type) == 32)
> {
>if (allocatable_array)
> - allocate = gfor_fndecl_allocate_array;
> + allocate = gfor_fndecl_internal_malloc;
>else
> - allocate = gfor_fndecl_allocate;
> + allocate = gfor_fndecl_internal_malloc;
This patch, as-is, will very likely violate the Fortran standard.
See, for example, multiple_allocation_1.f90:
allocate(a(4))
! This should set the stat code and change the size.
allocate(a(3),stat=i)
if (i == 0) call abort
if (.not. allocated(a)) call abort
if (size(a) /= 3) call abort
! It's OK to allocate pointers twice (even though this causes
! a memory leak)
allocate(b(4))
allocate(b(4))
The check wether size(a) is three isn't required by the standard.
The logic that is currently within the library would need to
be moved into the front end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30115
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #20 from jbuck at gcc dot gnu dot org 2006-12-08 23:10 --- I'd like to reopen this bug, as I'm seeing it on sparc-sun-solaris2.8. I have built the most recent GMP and MPFR versions and have the appropriate --with-gmp and --with-mpfr lines. At first, MPFR wouldn't build because GMP built a 64-bit version, so I rebuilt GMP explicitly specifying sparc-sun-solaris2.8 as the build platform. I use ksh. From the failing build: /bin/ksh /remote/atg5/jbuck/svn/4_2_branch/gcc/libgfortran/mk-kinds-h.sh '/remote/atg5/jbuck/sol2.tmp/./gcc/gfortran -B/remote/atg5/jbuck/sol2.tmp/./gcc/ -B/u/jbuck/cvs.sol2/4_2_branch/sparc-sun-solaris2.8/bin/ -B/u/jbuck/cvs.sol2/4_2_branch/sparc-sun-solaris2.8/lib/ -isystem /u/jbuck/cvs.sol2/4_2_branch/sparc-sun-solaris2.8/include -isystem /u/jbuck/cvs.sol2/4_2_branch/sparc-sun-solaris2.8/sys-include -I . -Wall -fno-repack-arrays -fno-underscoring ' > kinds.h || rm kinds.h /remote/atg5/jbuck/svn/4_2_branch/gcc/libgfortran/mk-kinds-h.sh: Unknown type grep '^#' < kinds.h > kinds.inc /bin/ksh: kinds.h: cannot open -- jbuck at gcc dot gnu dot org changed: What|Removed |Added CC||jbuck at gcc dot gnu dot org Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #21 from pinskia at gcc dot gnu dot org 2006-12-08 23:16 --- (In reply to comment #20) > I'd like to reopen this bug, as I'm seeing it on sparc-sun-solaris2.8. I have > built the most recent GMP and MPFR versions and have the appropriate > --with-gmp > and --with-mpfr lines. At first, MPFR wouldn't build because GMP built a > 64-bit version, so I rebuilt GMP explicitly specifying sparc-sun-solaris2.8 as > the build platform. Did you run make -k check for both GMP and MPFR? Some compiler versions are known to miscompile GMP which is most likely what is happening here. This is not a bug still as *** This bug has been marked as a duplicate of 29866 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug bootstrap/30126] New: ICE genautomata.c:6060
Fail in make bootstrap on FC6. Starting on r119634 through at least r119668. /mnt/share/bld/gcc/./prev-gcc/xgcc -B/mnt/share/bld/gcc/./prev-gcc/ -B/mnt/share/bld/H-x86-gcc/i686-pc-linux-gnu/bin/ -O2 -g -fomit-frame-pointer -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wmissing-format-attribute -Werror-DHAVE_CONFIG_H -DGENERATOR_FILE -o build/genrecog \ build/genrecog.o build/rtl.o build/read-rtl.o build/ggc-none.o build/vec.o build/min-insn-modes.o build/gensupport.o build/print-rtl.o build/errors.o .././libiberty/libiberty.a /mnt/share/src/gcc/gcc/genautomata.c: In function 'build_automaton': /mnt/share/src/gcc/gcc/genautomata.c:6060: 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[3]: *** [build/genautomata.o] Error 1 make[3]: *** Waiting for unfinished jobs rm gcov.pod gfdl.pod cpp.pod gpl.pod fsf-funding.pod gcc.pod make[3]: Leaving directory `/mnt/share/bld/gcc/gcc' make[2]: *** [all-stage2-gcc] Error 2 make[2]: Leaving directory `/mnt/share/bld/gcc' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/mnt/share/bld/gcc' make: *** [bootstrap-lean] Error 2 <[EMAIL PROTECTED]> /mnt/share/bld/gcc pre-processed as attached -- Summary: ICE genautomata.c:6060 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: bkoz at gcc dot gnu dot org 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=30126
[Bug libfortran/29866] building libgfortran fails because of kinds.h
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-08 23:16 --- *** Bug 26893 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||quanah at stanford dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29866
[Bug bootstrap/30126] ICE genautomata.c:6060
--- Comment #1 from bkoz at gcc dot gnu dot org 2006-12-08 23:17 --- Created an attachment (id=12772) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12772&action=view) pre-processed sources -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-08 23:20 --- What is interesting is that I don't get a segfault during my bootstrap but I do with your preprocessed source. #0 remove_phi_node (phi=0xb6f8fd20, prev=0x0) at /home/apinski/src/gcc-fsf/local/gcc/gcc/tree-phinodes.c:458 #1 0x081482e1 in remove_stmt_or_phi (t=Variable "t" is not available. ) at /home/apinski/src/gcc-fsf/local/gcc/gcc/tree-ssa-dom.c:2092 #2 0x0814be99 in eliminate_degenerate_phis () at /home/apinski/src/gcc-fsf/local/gcc/gcc/tree-ssa-dom.c:2494 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|bootstrap |tree-optimization Keywords||build, ice-on-valid-code Summary|ICE genautomata.c:6060 |[4.3 Regression] ICE ||genautomata.c:6060 Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug fortran/30123] Document INQUIRE, especially UNFORMATTED and FORMATTED
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2006-12-08 23:22 --- A quick look at the IBM Fortran manual on this states that the (un)formatted= specifier indicates whether or not a file may be connected or not as an (un)formatted file. The wording appears clearer than the Fortran standards. Not intending to copy that particular wording, but this does need some word engineering and probably some review by some of our experts. I think the particular implementation in gfortran is OK. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-08 23:28 --- Reducing ... I think slightly different glibc headers are causing you to see this issue. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added 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=30126
[Bug libfortran/26893] kinds.h not generated, causing failure
--- Comment #22 from jbuck at gcc dot gnu dot org 2006-12-08 23:34 --- Slow down, please! You don't need to set speed records for resolving bugs here. My report is not a duplicate of the bug you tried to attach it to, because I did not use -j at all! make -k check for gmp passes all tests. Still checking on mpfr; in the meantime, it won't kill you to leave it open a bit more. -- jbuck at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
[Bug fortran/30115] allocate() interface pessimizes aliasing
--- Comment #6 from tkoenig at gcc dot gnu dot org 2006-12-08 23:35 --- I forgot integer, allocatable :: a(:) integer, pointer :: b(:) :-) > allocate(a(4)) > ! This should set the stat code and change the size. > allocate(a(3),stat=i) > if (i == 0) call abort > if (.not. allocated(a)) call abort > if (size(a) /= 3) call abort > ! It's OK to allocate pointers twice (even though this causes > ! a memory leak) > allocate(b(4)) > allocate(b(4)) > > The check wether size(a) is three isn't required by the standard. > The logic that is currently within the library would need to > be moved into the front end. > -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30115
[Bug target/30039] HPPA: Incorrect code generated on 64bit host
--- Comment #2 from danglin at gcc dot gnu dot org 2006-12-08 23:41 --- Subject: Bug 30039 Author: danglin Date: Fri Dec 8 23:41:03 2006 New Revision: 119669 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119669 Log: PR target/30039 * pa.md (high:DI and lo_sum:DI): Handle 64-bit CONST_INTs in 32-bit patterns. Correct length of high:DI instruction sequence. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
[Bug libstdc++/30127] New: std::has_facet returns true for not installed derived facets
The program below is expected to run successfully to completion since there
is no MyCtype facet installed in the classic locale (and, in fact, no facet
of that type can exist since it doesn't have an accessible ctor).
$ cat u.cpp && g++ -dumpversion && g++ u.cpp -static && ./a.out
#include
#include
struct MyCtype: std::ctype { private: MyCtype (); };
int main ()
{
assert (std::has_facet >(std::locale::classic ()));
assert (!std::has_facet(std::locale::classic ()));
}
4.1.0
Assertion failed: !std::has_facet(std::locale::classic ()), file
u.cpp, line 9
Abort (core dumped)
--
Summary: std::has_facet returns true for not installed derived
facets
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sebor at roguewave dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30127
[Bug fortran/30068] Ambigous interfaces not detected
--- Comment #12 from burnus at gcc dot gnu dot org 2006-12-09 00:53 ---
Paul,
> Fix for this and pr30096
> This one regtests and fixes PR30096.
> I will submit it tomorrow.
Hmm, then I submitted too early. But you might save some time by doing simply a
reply to http://gcc.gnu.org/ml/fortran/2006-12/msg00124.html
I still would like to see the following change:
- gfc_warning ("Although not referenced, %s at %L has ambiguous "
+ gfc_warning ("Although not referenced, '%s' at %L has ambiguous "
"interfaces", sym->name, &sym->declared_at);
Otherwise it looks ok.
Tobias
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30068
[Bug c/30054] -Wc++-compat does not catch goto past initialization
--- Comment #1 from d3ck0r at gmail dot com 2006-12-09 01:02 --- Why is this even an error, since neither 'i' or 'j' are referenced after the goto point... I started to post a similar bug, but that the bug is this error is entirely inaccurate, and causes otherwise valid code to not be compilable. This is exactly the case, it's not that there's some sort of loop construct around the variable in question, it's top down sort of code like the example posted here, that initializes a variable, and uses that variable ABOVE the label, and not beyond the label. Thanx for checkin for this sort of thing, please allow valid instances to pass through without error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30054
[Bug c/30054] -Wc++-compat does not catch goto past initialization
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-09 01:05 --- (In reply to comment #1) > Why is this even an error, since neither 'i' or 'j' are referenced after the > goto point... Because that is what the C++ standard says ... C defines this case slightly different. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30054
[Bug c/19978] overflow in expression of constants should not cause multiple warnings
--- Comment #5 from patchapp at dberlin dot org 2006-12-09 01:10 --- Subject: Bug number PR c/19978 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/msg00588.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19978
[Bug c/30128] New: Strange code generated
The program...
/* --- */
#define GSF_LE_SET_GUINT32(p, dat) \
((*((char *)(p) + 0) = (char) ((dat)) & 0xff),\
(*((char *)(p) + 1) = (char) ((dat) >> 8) & 0xff),\
(*((char *)(p) + 2) = (char) ((dat) >> 16) & 0xff),\
(*((char *)(p) + 3) = (char) ((dat) >> 24) & 0xff))
void bar (void *);
void
foo (unsigned i)
{
char buffer[4];
unsigned len = i + 1;
GSF_LE_SET_GUINT32 (buffer, len + 1);
bar (buffer);
}
/* --- */
...generates the code below. Note, that there are two additions in the
generated code and that an extra register is used. It is as-if the least
significant byte is seen as unrelated to the three others.
foo:
pushl %ebp
movl%esp, %ebp
subl$24, %esp
movl8(%ebp), %eax
leal2(%eax), %edx <-- one addition into edx
addl$2, %eax <-- second one to eax
shrl$8, %eax
movb%al, -3(%ebp)
shrl$8, %eax
movb%al, -2(%ebp)
shrl$8, %eax
movb%al, -1(%ebp)
leal-4(%ebp), %eax
movb%dl, -4(%ebp)
movl%eax, (%esp)
callbar
leave
ret
--
Summary: Strange code generated
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: terra at gnome dot org
GCC build triplet: i586-suse-linux
GCC host triplet: i586-suse-linux
GCC target triplet: i586-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30128
[Bug target/30039] HPPA: Incorrect code generated on 64bit host
--- Comment #3 from danglin at gcc dot gnu dot org 2006-12-09 03:14 --- Subject: Bug 30039 Author: danglin Date: Sat Dec 9 03:14:42 2006 New Revision: 119683 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119683 Log: PR target/30039 * pa.md (high:DI and lo_sum:DI): Handle 64-bit CONST_INTs in 32-bit patterns. Correct length of high:DI instruction sequence. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
[Bug target/30039] HPPA: Incorrect code generated on 64bit host
--- Comment #4 from danglin at gcc dot gnu dot org 2006-12-09 03:19 --- Subject: Bug 30039 Author: danglin Date: Sat Dec 9 03:19:05 2006 New Revision: 119684 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119684 Log: PR target/30039 * pa.md (high:DI and lo_sum:DI): Handle 64-bit CONST_INTs in 32-bit patterns. Correct length of high:DI instruction sequence. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
[Bug target/30039] HPPA: Incorrect code generated on 64bit host
--- Comment #5 from danglin at gcc dot gnu dot org 2006-12-09 03:36 --- Subject: Bug 30039 Author: danglin Date: Sat Dec 9 03:35:43 2006 New Revision: 119685 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119685 Log: PR target/30039 * pa.md (high:DI and lo_sum:DI): Handle 64-bit CONST_INTs in 32-bit patterns. Correct length of high:DI instruction sequence. Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/config/pa/pa.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
[Bug tree-optimization/30126] [4.3 Regression] ICE genautomata.c:6060
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-12-09 03:36 --- This problem is weird. It is also hard to reduce. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30126
[Bug target/30039] HPPA: Incorrect code generated on 64bit host
--- Comment #6 from danglin at gcc dot gnu dot org 2006-12-09 03:52 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30039
[Bug debug/23551] dwarf records for inlines appear incomplete
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-12-09 05:43 --- Case 2 was filed as PR 29792 and was declared invalid. Though we get currently: .uleb128 0x2# (DIE (0x25) DW_TAG_subprogram) .ascii "foo\0" # DW_AT_name .byte 0x1 # DW_AT_decl_file (no-inlined-instance-record.c) .byte 0x2 # DW_AT_decl_line .byte 0x1 # DW_AT_prototyped .long 0x40# DW_AT_type .byte 0x3 # DW_AT_inline .long 0x40# DW_AT_sibling .uleb128 0x3# (DIE (0x36) DW_TAG_formal_parameter) .ascii "x\0"# DW_AT_name .byte 0x1 # DW_AT_decl_file (no-inlined-instance-record.c) .byte 0x1 # DW_AT_decl_line .long 0x40# DW_AT_type .byte 0x0 # end of children of DIE 0x25 Case 1, is also too hard to fix as it would make us lose a lot of optimizations. Really what GCC is producing is the best debugging you can get for these functions. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23551
[Bug tree-optimization/30098] missed value numbering optimization
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-09 06:30 --- Some of these have already been fixed. This one is the same as PR 19590. *** This bug has been marked as a duplicate of 19590 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30098
[Bug tree-optimization/19590] IVs with the same evolution not eliminated
--- Comment #15 from pinskia at gcc dot gnu dot org 2006-12-09 06:30 --- *** Bug 30098 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dann at godzilla dot ics dot ||uci dot edu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19590
[Bug tree-optimization/30099] missed value numbering optimization (conditional-based assertions)
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-12-09 06:32 --- Basically what needs here is that if we get i == j, then we need to also add asserts (in VRP) for all the uses of i and j, which makes it an almost useless to do :). There might be another bug about this filed by me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30099
[Bug tree-optimization/30105] reassoc can sometimes get in the way of PRE
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-12-09 06:51 --- This is just an reassiocation issue, if we have a_1 + b_2 + 1, we change it to be a_1 + 1 + b_2 which seems wrong. I wonder if we are trying to put the constant first but when calling fold, it puts it second in the first expression. j_15 = D.1620_12 + 1; i_16 = j_15 + D.1622_14; -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org Summary|missed PRE (add)|reassoc can sometimes get in ||the way of PRE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30105
[Bug fortran/30123] Document INQUIRE, especially UNFORMATTED and FORMATTED
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2006-12-09 07:25 --- There is a similar case with STREAM= -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30123
[Bug libfortran/30014] INQUIRE (iolength = xx) limited to kind=4
--- Comment #2 from patchapp at dberlin dot org 2006-12-09 07:35 --- Subject: Bug number PR30014 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/msg00600.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30014
