[Bug libfortran/23760] New: gfortran incorrectly succeeds on record overflow
The following testcase from gfortran.dg/g77/1832.f runs successfully with
gfortran. With g77 it goes into a spin cycle.
This was discovered while testing new patches for array_io in 4.1 branch. With
new patches, gfortran correctly gives am end-of-record error.
Test case should be dropped or revised for new correct error message.
c { dg-do run }
character*120 file
character*5 string
file = "c:/dos/adir/bdir/cdir/text.doc"
write(string, *) "a ", file
if (string .ne. ' a') call abort
C-- The leading space is normal for list-directed output
C-- "file" is not printed because it would overflow "string".
end
--
Summary: gfortran incorrectly succeeds on record overflow
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: libfortran
AssignedTo: jvdelisle at verizon dot net
ReportedBy: jvdelisle at verizon dot net
CC: gcc-bugs at gcc dot gnu dot org
GCC host triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23760
[Bug tree-optimization/21636] Missed ccp optimization
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 04:46 --- Actually there needs some improvements to ccp_fold to do this fully. -- What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |05/msg02649.html| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21636
[Bug tree-optimization/23588] CCP not fully propagating constants
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 04:19 --- (In reply to comment #3) > And then we hit an assert if we change evaluate_stmt to be always call > fold_ccp. > The assert is in set_lattice_value, when we are changing from VARRYING to > CONSTANT which should > be a valid transition. Only if the VARRYING is the default state. Before the TCB, this was allowed: /* VARYING -> CONSTANT is an invalid state transition, except for objects which start off in a VARYING state. */ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23588
[Bug awt/21598] rendering problem with button text
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 04:09 --- This is actually a GTK bug; a GtkButton doesn't center its child vertically when the child's size requisition exceeds its size allocation. I'm going to write a GTK test case and submit a bug report and patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21598
[Bug tree-optimization/23588] CCP not fully propagating constants
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 03:51 --- (In reply to comment #2) > The first thing is that ccp_initialize sets DONT_SIMULATE_AGAIN on the > statement so don't simulate > that statement and then we don't call fold_ccp on them. And then we hit an assert if we change evaluate_stmt to be always call fold_ccp. The assert is in set_lattice_value, when we are changing from VARRYING to CONSTANT which should be a valid transition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23588
[Bug tree-optimization/23588] CCP not fully propagating constants
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 03:46 --- The first thing is that ccp_initialize sets DONT_SIMULATE_AGAIN on the statement so don't simulate that statement and then we don't call fold_ccp on them. -- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23588
[Bug target/23704] gcc.dg/rs6000-fpint.c fails
--- Additional Comments From rth at gcc dot gnu dot org 2005-09-07 01:55 --- You could also disable the test for lp64, if you felt that better. But then you should document that the various isa extension options are non-functional. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23704
[Bug rtl-optimization/23684] Combine stores for non strict alignment targets
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07 01:42 --- Also even when -mstrict-align if using typedef char align_char __attribute__ ((aligned (4))); void foo (align_char *input) ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23684
[Bug target/23704] gcc.dg/rs6000-fpint.c fails
--- Additional Comments From amodra at bigpond dot net dot au 2005-09-07 01:26 --- Indeed, that is what is happening. -m64 ought to normally imply -mpowerpc-gfxopt, because all powerpc64 capable chips also support the insns enabled by -mpowerpc-gfxopt as far as I know. However, I guess there's not much harm in preventing -m64 from overriding a prior -mno-powerpc-gfxopt. Index: gcc/config/rs6000/rs6000.c === RCS file: /cvs/gcc/gcc/gcc/config/rs6000/rs6000.c,v retrieving revision 1.866 diff -u -p -r1.866 rs6000.c --- gcc/config/rs6000/rs6000.c 6 Sep 2005 02:04:59 - 1.866 +++ gcc/config/rs6000/rs6000.c 7 Sep 2005 01:11:56 - @@ -1620,9 +1620,9 @@ rs6000_handle_option (size_t code, const #else case OPT_m64: #endif - target_flags |= MASK_POWERPC64 | MASK_POWERPC | MASK_PPC_GFXOPT; - target_flags_explicit |= MASK_POWERPC64 | MASK_POWERPC - | MASK_PPC_GFXOPT; + target_flags |= MASK_POWERPC64 | MASK_POWERPC; + target_flags |= ~target_flags_explicit & MASK_PPC_GFXOPT; + target_flags_explicit |= MASK_POWERPC64 | MASK_POWERPC; break; #ifdef TARGET_USES_AIX64_OPT -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23704
[Bug libgcj/21741] Need configure option to set java.library.path
--- Additional Comments From fitzsim at redhat dot com 2005-09-07 01:07 --- It turns out that Sun handles this in a strange way. To ensure that libjawt.so is found automatically, Sun's java executable prepends $JAVA_HOME/jre/lib/i386 to LD_LIBRARY_PATH then re-exec's itself within the new environment. I've just added a java command to java-gcj-compat that does the same thing only exec's gij instead of re-exec'ing itself. java.library.path has nothing to do with LD_LIBRARY_PATH except that its user-visible value defaults to the contents of LD_LIBRARY_PATH. The argument to -Djava.library.path= should be added to the dynamic library loader's search path. So we also need to support running JAWT apps like this: java -Djava.library.path=. gnu.classpath.examples.jawt.DemoJAWT Currently this doesn't work. Though the initial problem is fixed now, I won't close this bug until this usage pattern is also supported. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21741
[Bug libstdc++/23734] [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list too long
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca
2005-09-07 01:01 ---
Subject: Re: [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list
too long
> It looks like there are some patches to increase ARG_MAX on HP-UX 10.* OS
> releases. They might provide a workaround.
>
> >From HP Chart/bug report JAGaa11744:
>
> A patch has been provided which will allow the kernel to
> accept upto 200k chars (as the max combined size of arg/env
> strings) in a single call to EXEC.
>
> The patch ids are:PHKL_8282 (700 series)
> PHKL_8283 (800 series)
>
> =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>
> The following patches extend the maximum combined size of
> arg/env strings to 2048000 bytes (including the null
> terminators) in a single call to EXEC.
>
> The patch ids are:PHKL_10176 (10.20 S700)
> PHKL_10177 (10.20 S800)
>
> PHKL_10270 (10.10 S700)
> PHKL_10271 (10.10 S800)
I have PHKL_16750 installed which superceded PHKL_10176. It claims
the following:
The internal buffer within the kernel was created with a
length of 20480 bytes, with no provision for increasing its
size. This patch provides for up to 100 such buffers, with
all but the first allocated only if required (that is, if
more than 20480 bytes of argv/env information is found).
Thus, exec() now supports up to 2048000 bytes of argv/env
information.
I tried the following:
#include
int
main ()
{
printf ("arg_max = %u\n", sysconf (_SC_ARG_MAX));
return 0;
}
bash-3.00$ ./arg_max
arg_max = 20478
Thus, system is advertising that it supports 2048000 bytes of argv/env
info. Looking at PHKL_16750, I see that I need to enable large_ncargs_enabled.
I'm going to give this a try.
Dave
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23734
[Bug libgcj/23758] java::lang::ConcreteProcess::nativeSpawn unsafe
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 00:49 --- Confirmed based on: http://www.opengroup.org/onlinepubs/009695399/functions/xsh_chap02_04.html -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 GCC build triplet|*-*-linux-gnu | GCC host triplet|*-*-linux-gnu | GCC target triplet|*-*-linux-gnu and others|POSIX Last reconfirmed|-00-00 00:00:00 |2005-09-07 00:49:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23758
[Bug target/23759] powerpc-unknown-eabialtivec-cpp runs out of memory
--- Additional Comments From Daniel dot Davies at xerox dot com 2005-09-07 00:49 --- Any idea when 4.1.0 will be released? Comments on gcc.gnu.org from July says Stage 3 will complete on Thursday. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23759
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From x at xman dot org 2005-09-07 00:47 --- Created an attachment (id=9676) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9676&action=view) Removed unneeded #include I realized the sample test.ii output was including the header even though it wasn't necessary. -- What|Removed |Added Attachment #9674 is|0 |1 obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug c++/20812] contextual overload resolution failure for a member name found in two base classes
--- Additional Comments From bangerth at dealii dot org 2005-09-07 00:38 --- gcc is correct. Ambiguation of base class members does not happen based on assigning to different types. W. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20812
[Bug target/19411] Simple program causes gcc to run out of memory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 00:25 --- *** Bug 23759 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||Daniel dot Davies at xerox ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19411
[Bug target/23759] powerpc-unknown-eabialtivec-cpp runs out of memory
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-07 00:24 --- This is a dup of bug 19411. This is fixed in 4.1.0 by a re-implementation of altivec functions. *** This bug has been marked as a duplicate of 19411 *** -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|preprocessor|target Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23759
[Bug preprocessor/23759] New: powerpc-unknown-eabialtivec-cpp runs out of memory
I'm cross compiling for an embedded PowerPC/Altivec processor on an i386 solaris box. When cpp is invoked on the file attached to this report, the system thrashes the disk for few minutes, then runs out of memory. I tried increasing swap space, but the preprocessor really shouldn't need about 3 GB to compile this program. I've included the recommended invocation of gcc with -v -save-temps, but the same thing happens with powerpc-unknown- eabialtivec-cpp without the -v and -save-temps flags. -- $ powerpc-unknown-eabialtivec-gcc -v -save-temps -std=gnu9x - isystem /tool/gcc/4.0.1/i386-pc-solaris2.10-ppc-eabi/powerpc-unknown- eabialtivec/include -o results.txt testit.c Using built-in specs. Target: powerpc-unknown-eabialtivec Configured with: /tool/gcc/4.0.1/gcc-4.0.1/configure -- prefix=/tool/gcc/4.0.1/i386-pc-solaris2.10-ppc-eabi --target=powerpc-unknown- eabialtivec --with-cpu=7450 --with-float=hard --with- sysroot=/tool/gcc/4.0.1/newlib-1.13.0 --enable-altivec --with-dwarf2 Thread model: single gcc version 4.0.1 /tool/gcc/4.0.1/i386-pc-solaris2.10-ppc-eabi/libexec/gcc/powerpc-unknown- eabialtivec/4.0.1/cc1 -E -quiet -v -isystem /tool/gcc/4.0.1/i386-pc- solaris2.10-ppc-eabi/powerpc-unknown-eabialtivec/include testit.c -mcpu=7450 - mhard-float -std=gnu9x -fpch-preprocess -o testit.i ignoring nonexistent directory "/tool/gcc/4.0.1/newlib- 1.13.0/usr/local/include" ignoring duplicate directory "/tool/gcc/4.0.1/i386-pc-solaris2.10-ppc- eabi/lib/gcc/powerpc-unknown-eabialtivec/4.0.1/../../../../powerpc-unknown- eabialtivec/include" #include "..." search starts here: #include <...> search starts here: /tool/gcc/4.0.1/i386-pc-solaris2.10-ppc-eabi/powerpc-unknown- eabialtivec/include /tool/gcc/4.0.1/i386-pc-solaris2.10-ppc-eabi/lib/gcc/powerpc-unknown- eabialtivec/4.0.1/include /tool/gcc/4.0.1/newlib-1.13.0/usr/include End of search list. cc1: out of memory allocating 987240500 bytes after a total of 1921990656 bytes $ - The program includes You'll have to change the -isystem flag to point to your system include files. This code works fine with CodeWarrior, though CW obviously doesn't include . Most of the test file is a macro. This macro is used to supply an optimized implementation for one of the many sub-cases of bitblt or rasterOp. There are several such macros. Macros are used to avoid duplicating the same code for each of the flavors of bitblt. -- Summary: powerpc-unknown-eabialtivec-cpp runs out of memory Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Daniel dot Davies at xerox dot com CC: gcc-bugs at gcc dot gnu dot org GCC build triplet: i386-pc-solaris2.10 GCC host triplet: i386-pc-solaris2.10 GCC target triplet: powerpc-unknown-eabialtivec http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23759
[Bug libgcj/23758] New: java::lang::ConcreteProcess::nativeSpawn unsafe
java::lang::ConcreteProcess::nativeSpawn appears to call several functions that are not async-signal-safe between the fork and exec in the child, including _Jv_Malloc. This is unsafe by Posix rules. I'm unsure whether it can deadlock on Linux. These actions should be performed before the fork() call. I don't see why that would be particularly difficult to do here. To my knowledge, the problem may never have been observed in practice. I noticed it while reading the code, and didn't want it to get lost. -- Summary: java::lang::ConcreteProcess::nativeSpawn unsafe Product: gcc Version: 4.1.0 Status: UNCONFIRMED Severity: minor Priority: P2 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: Hans dot Boehm at hp dot com CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu dot org GCC build triplet: *-*-linux-gnu GCC host triplet: *-*-linux-gnu GCC target triplet: *-*-linux-gnu and others http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23758
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
-- What|Removed |Added Known to fail||2.95 3.4.0 4.0.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug libstdc++/23734] [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list too long
--- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2005-09-07 00:14 --- Subject: Re: [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list too long > It looks like there are some patches to increase ARG_MAX on HP-UX 10.* OS > releases. They might provide a workaround. Thanks. I thought that I had every relevant patch for 10.20 installed ;) Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23734
[Bug c++/22252] [4.0/4.1 Regression] pragma interface/implementation still break synthesized methods
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |mark at codesourcery dot com |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22252
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06 23:56 --- ICC also produces the same output. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug libgcj/22211] [4.0 only] Thread.interrupt sometimes causes abort if thread is already dead
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 23:55 --- Subject: Bug 22211 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 23:53:46 Modified files: libjava: ChangeLog libjava/java/lang: Thread.java natThread.cc Log message: PR libgcj/22211: * java/lang/natThread.cc (finish_): Synchronize when updating alive_flag. (_Jv_AttachCurrentThread): Likewise. (interrupt): Only call _Jv_ThreadInterrupt if thread is alive. * java/lang/Thread.java (isAlive): Now synchronized. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.95&r2=1.3391.2.96 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/Thread.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.35&r2=1.35.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natThread.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.30&r2=1.30.8.1 --- Additional Comments From tromey at gcc dot gnu dot org 2005-09-06 23:56 --- Fix on branch as well. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22211
[Bug libgcj/22211] [4.0 only] Thread.interrupt sometimes causes abort if thread is already dead
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 23:55 --- Subject: Bug 22211 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 23:53:46 Modified files: libjava: ChangeLog libjava/java/lang: Thread.java natThread.cc Log message: PR libgcj/22211: * java/lang/natThread.cc (finish_): Synchronize when updating alive_flag. (_Jv_AttachCurrentThread): Likewise. (interrupt): Only call _Jv_ThreadInterrupt if thread is alive. * java/lang/Thread.java (isAlive): Now synchronized. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.95&r2=1.3391.2.96 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/Thread.java.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.35&r2=1.35.8.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natThread.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.30&r2=1.30.8.1 --- Additional Comments From tromey at gcc dot gnu dot org 2005-09-06 23:56 --- Fix on branch as well. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22211
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From x at xman dot org 2005-09-06 23:55 --- Realized this should be filed against libstdc++ -- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug c++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From x at xman dot org 2005-09-06 23:53 --- This bug seems to exist in the version of g++4 included with RHEL4. I haven't tested against the latest release, but I'm guessing it's still there. -- What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug libstdc++/23757] iostreams hex formatting for signed integers treats than as unsigned
-- What|Removed |Added Component|c++ |libstdc++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug c++/23757] iostreams hex formatting for signed integers treats than as unsigned
--- Additional Comments From x at xman dot org 2005-09-06 23:51 --- Created an attachment (id=9674) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=9674&action=view) Preprocessed file from g++ --save-temp This is what the sample program looks like after running it through the preprocessor. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug c++/23757] New: iostreams hex formatting for signed integers treats than as unsigned
I will attach the test.ii file later, but here's the sample source code:
#include
using namespace std;
int main()
{
cout << dec << -1 << endl;
cout << hex << -1 << endl;
return 0;
}
The expected output is:
-1
-1
The actual output is:
-1
I found the problem in local_facets.tcc in the version of __int_to_char around
line 900. This is the one that takes a flag indicating if the integer is
negative or not. While the decimal case uses modular arithmetic and actually
checks the negative flag, the octal and hex cases use bitwise operators and
never check the negative flag. The octal and hex cases clearly assume they are
working with an unsigned integer, even though the templated types for the
function clearly allow for the case of a signed integer.
My current work around is to do the two's compliments math to convert the number
to it's postitive unsigned equivalent and then print out the "-" sign myself.
Something like:
cout << hex << (static_cast(~aSession.getCount())+1) << endl;
--
Summary: iostreams hex formatting for signed integers treats than
as unsigned
Product: gcc
Version: 3.4.3
Status: UNCONFIRMED
Severity: minor
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: x at xman dot org
CC: gcc-bugs at gcc dot gnu dot org
GCC build triplet: i386-unknown-linux
GCC host triplet: i386-unknown-linux
GCC target triplet: i386-unknown-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23757
[Bug fortran/21986] Bad .mod file, ICE upon USE
--- Additional Comments From pault at gcc dot gnu dot org 2005-09-06 23:09 --- (In reply to comment #0) This is incorrect code, which should generate an error, rather than an ICE. As ifort9.0 puts it: fortcom: Error: ../pr21986.f90, line 11: This procedure cannot be PUBLIC since it has argument(s) whose derived type(s) are PRIVATE. [SIZE] The example compiles and runs correctly with gfortran and ifort if public:: dummysub is changed to public:: dummysub, intwrapper. I do not see why this is marked as resolved duplicate, since it behaves in the same way that it always did. -- What|Removed |Added Status|RESOLVED|REOPENED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21986
[Bug libfortran/23419] unformatted complex I/O with kind=10
--- Additional Comments From sje at cup dot hp dot com 2005-09-06 22:53 --- It looks like this is the same kind of bug as PR 23556 but in a different place. I fixed convert_real in io/read.c to resolve PR 23556, this is extract_real in io/write.c. I will submit a patch in the next day or so unless someone else beats me to it. This is a buffer alignment issue, not a problem with padding real*10 values. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23419
[Bug middle-end/23756] Missed optimization for PIC code with internal visibility
-- What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23756
[Bug java/23754] [3.4/4.0/4.1 Regression]: tree check error in check_inner_circular_reference
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06 22:43 --- Confirmed. -- What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed||1 Keywords||ice-on-valid-code Known to fail||3.4.0 4.0.0 4.1.0 Known to work||3.3.3 Last reconfirmed|-00-00 00:00:00 |2005-09-06 22:43:06 date|| Summary|4.1 ICE: tree check error in|[3.4/4.0/4.1 Regression]: |check_inner_circular_referen|tree check error in |ce |check_inner_circular_referen ||ce http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23754
[Bug libstdc++/23734] [4.1 Regression] make[4]: execvp: /usr/local/bin/bash: Arg list too long
--- Additional Comments From sje at cup dot hp dot com 2005-09-06 22:35 --- It looks like there are some patches to increase ARG_MAX on HP-UX 10.* OS releases. They might provide a workaround. >From HP Chart/bug report JAGaa11744: A patch has been provided which will allow the kernel to accept upto 200k chars (as the max combined size of arg/env strings) in a single call to EXEC. The patch ids are: PHKL_8282 (700 series) PHKL_8283 (800 series) =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- The following patches extend the maximum combined size of arg/env strings to 2048000 bytes (including the null terminators) in a single call to EXEC. The patch ids are: PHKL_10176 (10.20 S700) PHKL_10177 (10.20 S800) PHKL_10270 (10.10 S700) PHKL_10271 (10.10 S800) -- What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23734
[Bug target/8973] [arc-7-elf] the interupt handler does not return properly, uses j.d insted of j.d.f
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 22:29 --- Subject: Bug 8973 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 22:29:46 Modified files: gcc: ChangeLog gcc/config/arc : arc.c Log message: 2005-09-06 Saurabh Verma <[EMAIL PROTECTED]> PR target/8973 * config/arc/arc.c (arc_output_function_epilogue): Update flags while returning from an interrupt handler. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9909&r2=2.9910 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arc/arc.c.diff?cvsroot=gcc&r1=1.74&r2=1.75 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8973
[Bug target/8973] [arc-7-elf] the interupt handler does not return properly, uses j.d insted of j.d.f
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06 22:29 --- Fixed on the mainline for 4.1.0. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8973
[Bug target/8972] [arc-7-elf] the c code ' x << i' causes infinite loop when i = 0
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 22:27 --- Subject: Bug 8972 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 22:26:59 Modified files: gcc: ChangeLog gcc/config/arc : arc.c Log message: 2005-09-06 Saurabh Verma <[EMAIL PROTECTED]> PR target/8972 * config/arc/arc.c (output_shift): Add check for loop count when optimizing. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9908&r2=2.9909 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/arc/arc.c.diff?cvsroot=gcc&r1=1.73&r2=1.74 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8972
[Bug target/8972] [arc-7-elf] the c code ' x << i' causes infinite loop when i = 0
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06 22:26 --- Fixed on the mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=8972
[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-06 22:03 --- The "floating constant exceeds range" message comes from interpret_float in c-lex.c, which does test just "pedantic", rather than CPP_PEDANTIC(pfile). So, while the preprocessor warning about use of a hexadecimal floating constant does seem to be like the other PRs, the actual pedwarn/error is coming from the fact the C++ front end is pre-lexing tokens. I agree that disabling warnings in expansions of macros from system headers is a good idea, independently of whether or not any other changes might be appropriate to deal with other uses of __extension__. There are certain to be system headers not using __extension__ in macro definitions, on some systems. I guess we could have the preprocessor insert a special token to mark the start/stop of a macro expansion, with an indicator of the location of the macro definition, including its system-headerness. Then, the front end could clear/reset pedantic when seeing these tokens. This would also allow us to issue diagnostics based on the location of the macro, rather than its user, if we wanted. A more brutal approach would be to have the preprocessor simulate #include'ing the file from which the macro came when doing the expansion. That would not require updating the front-ends, but would be more confusing to users. -- What|Removed |Added CC||mark at codesourcery dot ||com, joseph at codesourcery ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139
[Bug fortran/15809] ICE Using Pointer Functions
--- Additional Comments From erik dot edelmann at iki dot fi 2005-09-06 21:10 --- With my patch, the reduced testcase by Tobi compiles, but this slightly longer testcase doesn't: $ cat bug7.f90 SUBROUTINE A(p,LEN) CHARACTER(LEN=LEN), DIMENSION(:), POINTER :: p IF ( .NOT. ASSOCIATED(p) ) THEN allocate(p(1)) END IF END SUBROUTINE A $ gfortran bug7.f90 bug7.f90: In function 'a': bug7.f90:1: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. I'm not yet sure if it is because my patch doesn't solve the bug after all, or if this is yet another unrelated bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15809
[Bug swing/16540] GlassPane intercepting of MouseEvents flaky.
--- Additional Comments From abalkiss at redhat dot com 2005-09-06 20:52 --- The proposed patch is incorrect, changes should instead be made in JComponent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16540
[Bug c/23756] Missed optimization for PIC code with internal visibility
-- What|Removed |Added Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23756
[Bug c++/23755] template class inheritance
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06
20:42 ---
Read http://gcc.gnu.org/gcc-3.4/changes.html:
In a template definition, unqualified names will no longer find members of a
dependent base (as
specified by [temp.dep]/3 in the C++ standard). For example,
template struct B {
int m;
int n;
int f ();
int g ();
};
int n;
int g ();
template struct C : B {
void h ()
{
m = 0; // error
f (); // error
n = 0; // ::n is modified
g (); // ::g is called
}
};
You must make the names dependent, e.g. by prefixing them with this->. Here is
the corrected
definition of C::h,
template void C::h ()
{
this->m = 0;
this->f ();
this->n = 0
this->g ();
}
As an alternative solution (unfortunately not backwards compatible with GCC
3.3), you may use using
declarations instead of this->:
template struct C : B {
using B::m;
using B::f;
using B::n;
using B::g;
void h ()
{
m = 0;
f ();
n = 0;
g ();
}
};
In templates, all non-dependent names are now looked up and bound at definition
time (while parsing
the code), instead of later when the template is instantiated. For instance:
void foo(int);
template struct A {
static void bar(void){
foo('a');
}
};
void foo(char);
int main()
{
A<0>::bar();// Calls foo(int), used to call foo(char).
}
--
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23755
[Bug c++/23755] template class inheritance
-- What|Removed |Added CC||urz at beep dot hu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23755
[Bug c/23756] New: Missed optimization for PIC code with internal visibility
This bug-report is in fact a wishlist for an optimization described in GCC
manual, yet not implemented unfortunately (at least not for x86). About the
"internal" visibility of a symbol, the manual states: "By indicating that a
symbol cannot be called from outside the module, GCC may for instance omit the
load of a PIC register since it is known that the calling function loaded the
correct value."
This is a great idea, since loading the GOT register on x86 is a costly
operation. Even with "-march=pentium3" (it prevents the return address predictor
of the processor from going into lalaland because of the load), the PIC version
of the testcase still runs twice as slow. Although g() has already loaded the
GOT address in the %ebx callee-save register, f() will load it once again in
%ecx.
The optimization described for the "internal" visibility would prevent such a
reload, since GCC would have complete control over the callers. I did not see
anything in the psABI that would disallow such an optimization. Hence this
wishlist. This was tested with GCC 4.0.2 and compiled by "gcc -O -fPIC" (or
-fpic).
Testcase:
extern int a;
__attribute__((visibility("internal")))
void f(void) { ++a; }
void g(void) { a = 0; f(); }
Excerpt from the generated assembly code:
080483c9 :
80483c9: 55 push %ebp
80483ca: 89 e5 mov%esp,%ebp
80483cc: 53 push %ebx
80483cd: e8 00 00 00 00 call 80483d2 \
80483d2: 5b pop%ebx | first load
80483d3: 81 c3 2e 12 00 00 add$0x122e,%ebx /
80483d9: 8b 83 f8 ff ff ff mov0xfff8(%ebx),%eax
80483df: c7 00 00 00 00 00 movl $0x0,(%eax)
80483e5: e8 c6 ff ff ff call 80483b0
...
080483b0 :
80483b0: 55 push %ebp
80483b1: 89 e5 mov%esp,%ebp
80483b3: e8 00 00 00 00 call 80483b8 \
80483b8: 59 pop%ecx | second load
80483b9: 81 c1 48 12 00 00 add$0x1248,%ecx /
80483bf: 8b 81 f8 ff ff ff mov0xfff8(%ecx),%eax
80483c5: ff 00 incl (%eax)
80483c7: 5d pop%ebp
80483c8: c3 ret
Note: it is impossible to specify both the "internal" visibility and the
"static" qualifier (GCC complains). And using only "static" does not help here
either.
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,java,f95,objc,ada,treelang --prefix=/usr
--enable-shared --with-system-zlib --libexecdir=/usr/lib --enable-nls
--without-included-gettext --enable-threads=posix --program-suffix=-4.0
--enable-__cxa_atexit --enable-libstdcxx-allocator=mt --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-gc=boehm --enable-java-awt=gtk
--enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.0-1.4.2.0/jre
--enable-mpfr --disable-werror --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)
--
Summary: Missed optimization for PIC code with internal
visibility
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: guillaume dot melquiond at ens-lyon dot fr
CC: gcc-bugs at gcc dot gnu dot org
GCC target triplet: i486-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23756
[Bug c++/23755] New: template class inheritance
Inheritance in template classes seems to have a critical bug.
The compliler fails to find both inherited functions and inherited member
variables.
The attached code is compiling fine in gcc-3.3 [g++-3.3 (GCC) 3.3.6 (Debian
1:3.3.6-9)].
g++-4.0 -o main main.cpp
temp_child.h: In member function 'void CFC_tSortArray::Add
(long int)':
temp_child.h:24: error: there are no arguments to 'InitChk' that depend on a
template parameter, so a declaration of 'InitChk' must be available
temp_child.h:24: error: (if you use '-fpermissive', G++ will accept your code,
but allowing the use of an undeclared name is deprecated)
temp_child.h:25: error: 'm_dwItemCount' was not declared in this scope
make: *** [main] Error 1
The issue first appears in gcc-3.4 [
g++-3.4 (GCC) 3.4.5 20050821 (prerelease) (Debian 3.4.4-8)] and gcc-4.0 [g++-
4.0 (GCC) 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)]
ATTACHED:
temp_base.h
#ifndef _CFC_ARRAY_H_INCLUDED
#define _CFC_ARRAY_H_INCLUDED
template < class TYPE, long dwTemplAlloc = 0> class CFC_tArray
{
public:
CFC_tArray( long dwAllocItems = 0 )
{
m_pArray = 0;
m_dwItemCount = 0;
}
virtual ~CFC_tArray()
{
if (m_pArray)
{
free(m_pArray);
}
}
inline boolIsActive() const { return m_dwItemCount != 0; };
inline voidInitChk () const { if ( !IsActive() ) throw((long)
1); };
protected:
TYPE* m_pArray;
longm_dwItemCount;
};
#endif // _CFC_ARRAY_H_INCLUDED
--
end of temp_base.h
temp_child.h
--
#ifndef _CFC_ARRAY1_H_INCLUDED
#define _CFC_ARRAY1_H_INCLUDED
#include "temp_base.h"
template< class TYPE, long dwTemplAlloc = 0 > class CFC_tSortArray : public
CFC_tArray
{
public:
CFC_tSortArray( long dwAllocItems, bool fAutoSort = false, bool
fSortable = false)
{
m_fSortable = fSortable;
m_fAutoSort = fAutoSort;
m_fSorted = false;
}
virtual ~CFC_tSortArray()
{
}
void Add( long a)
{
InitChk();
m_dwItemCount += a;
}
protected:
boolm_fSortable;
boolm_fSorted;
boolm_fAutoSort;
};
#endif // _CFC_ARRAY1_H_INCLUDED
--
end of temp_child.h
main.cpp
--
#include
#include "temp_child.h"
int main(int argc, char** argv)
{
CFC_tSortArraya(1);
a.Add(12);
return 0;
}
--
end of main.cpp
--
Summary: template class inheritance
Product: gcc
Version: 4.0.2
Status: UNCONFIRMED
Severity: critical
Priority: P2
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: compi at freemail dot hu
CC: gcc-bugs at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23755
[Bug middle-end/23741] Segfault 3.4.3->3.4.4/4.1.0-beta in insn_default_latency
--- Additional Comments From spamfuckers at wp dot pl 2005-09-06 20:26 --- ok, i've checked it on Slamd64 using GCC 3.4.4 to compile GCC 3.4.4 (without any extra patches) and it also SegFaults on insn_attrtab, so it doesn't look like gentoo fault. i can provide preprocessed sources from Slack if needed. i found four more cases: http://bugs.gentoo.org/show_bug.cgi?id=103874, http:// bugs.gentoo.org/show_bug.cgi?id=104183, http://bugs.gentoo.org/show_bug.cgi? id=73422. it seems to be random however, both on Slamd and Gentoo in my case. sometimes it can pass flawlessly, sometimes it gives ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23741
[Bug java/23754] New: 4.1 ICE: tree check error in check_inner_circular_reference
With certain invalid code, the 4.1 branch of gcj produces an ICE after giving
the correct error message. For example:
$ cat T5.java
final class T6 {
}
class T5 extends T6 {
}
$ gcj -C T5.java
T5.java:3: error: Can't subclass final classes: T6.
class T5 extends T6 {
^
T5.java:0: internal compiler error: tree check: expected tree that contains
‘decl minimal’ structure, have ‘identifier_node’ in
check_inner_circular_reference, at ./gcc/java/parse.y:5389
Please submit a full bug report,[...]
This problem happens with latest CVS and the 4.1-20050515 snapshot but not
4.0.1. It sounds similar to bug 4715, and it seems to have a similar workaround
to the one given there; adding
if (TREE_CODE (su) == POINTER_TYPE)
continue;
to check_inner_circular_reference() makes the problem go away.
--
Summary: 4.1 ICE: tree check error in
check_inner_circular_reference
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wmahan at gmail dot com
CC: gcc-bugs at gcc dot gnu dot org,java-prs at gcc dot gnu
dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23754
[Bug c/23075] [4.0/4.1 Regression] Redundant / bogus warning
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06 20:14 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug target/22362] [3.4 Regression] static function calls and global register variables
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06 20:13 --- Still a latent bug/regression on the 3.4 branch. -- What|Removed |Added Known to fail||4.0.0 4.0.1 Known to work||3.3.3 4.0.2 4.1.0 Summary|[3.4/4.0/4.1 Regression]|[3.4 Regression] static |static function calls and |function calls and global |global register variables |register variables Target Milestone|4.0.2 |3.4.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22362
[Bug c/23075] [4.0/4.1 Regression] Redundant / bogus warning
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 20:11 --- Subject: Bug 23075 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 20:11:09 Modified files: gcc: ChangeLog c-typeck.c tree-cfg.c gcc/cp : ChangeLog cp-tree.h semantics.c typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: pr23075.C gcc/testsuite/gcc.dg: pr23075.c Log message: PR c/23075 * c-typeck.c (c_finish_return): Set TREE_NO_WARNING on RETURN_EXPR if "return with no value, in function returning non-void" warning has been issued. * tree-cfg.c (execute_warn_function_return): Don't look at RETURN_EXPRs with TREE_NO_WARNING set. * typeck.c (check_return_expr): Add no_warning argument. Set *no_warning to true if "return-statement with no value, in function returning" warning has been issued. * cp-tree.h (check_return_expr): Adjust prototype. * semantics.c (finish_return_stmt): Set TREE_NO_WARNING if check_return_expr set *no_warning to true. * gcc.dg/pr23075.c: New test. * g++.dg/warn/pr23075.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.415&r2=2.7592.2.416 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.419.2.12&r2=1.419.2.13 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.151.2.3&r2=2.151.2.4 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.94&r2=1.4648.2.95 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1106.2.14&r2=1.1106.2.15 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.463.2.8&r2=1.463.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.616.2.17&r2=1.616.2.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.386&r2=1.5084.2.387 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/pr23075.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr23075.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug c/23075] [4.0/4.1 Regression] Redundant / bogus warning
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 20:07 --- Subject: Bug 23075 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 20:07:13 Modified files: gcc: ChangeLog c-typeck.c tree-cfg.c gcc/cp : ChangeLog cp-tree.h semantics.c typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/warn: pr23075.C gcc/testsuite/gcc.dg: pr23075.c Log message: PR c/23075 * c-typeck.c (c_finish_return): Set TREE_NO_WARNING on RETURN_EXPR if "return with no value, in function returning non-void" warning has been issued. * tree-cfg.c (execute_warn_function_return): Don't look at RETURN_EXPRs with TREE_NO_WARNING set. * typeck.c (check_return_expr): Add no_warning argument. Set *no_warning to true if "return-statement with no value, in function returning" warning has been issued. * cp-tree.h (check_return_expr): Adjust prototype. * semantics.c (finish_return_stmt): Set TREE_NO_WARNING if check_return_expr set *no_warning to true. * gcc.dg/pr23075.c: New test. * g++.dg/warn/pr23075.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9906&r2=2.9907 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/c-typeck.c.diff?cvsroot=gcc&r1=1.478&r2=1.479 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/tree-cfg.c.diff?cvsroot=gcc&r1=2.218&r2=2.219 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4875&r2=1.4876 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1162&r2=1.1163 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/semantics.c.diff?cvsroot=gcc&r1=1.486&r2=1.487 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.651&r2=1.652 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6020&r2=1.6021 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/warn/pr23075.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.dg/pr23075.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23075
[Bug target/22362] [3.4/4.0/4.1 Regression] static function calls and global register variables
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 20:03 --- Subject: Bug 22362 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 20:03:28 Modified files: gcc: ChangeLog gcc/config/i386: i386.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: pr22362.c Log message: PR target/22362 * config/i386/i386.c (ix86_function_regparm): Make sure automatic regparm for internal functions doesn't use registers used by global registers variables. Use fewer register parameters if there are global register variables. * gcc.target/i386/pr22362.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.414&r2=2.7592.2.415 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.795.6.10&r2=1.795.6.11 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.385&r2=1.5084.2.386 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr22362.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22362
[Bug target/22362] [3.4/4.0/4.1 Regression] static function calls and global register variables
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 19:58 --- Subject: Bug 22362 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 19:57:57 Modified files: gcc: ChangeLog gcc/config/i386: i386.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: pr22362.c Log message: PR target/22362 * config/i386/i386.c (ix86_function_regparm): Make sure automatic regparm for internal functions doesn't use registers used by global registers variables. Use fewer register parameters if there are global register variables. * gcc.target/i386/pr22362.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9905&r2=2.9906 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&r1=1.857&r2=1.858 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6019&r2=1.6020 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr22362.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22362
[Bug middle-end/14997] ncurses build fails with Ada
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-06 19:50 --- See http://gcc.gnu.org/ml/gcc-patches/2005-09/msg00324.html -- What|Removed |Added URL|http://gcc.gnu.org/ml/gcc- | |patches/2005- | |09/msg00324.html| Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14997
[Bug middle-end/14997] ncurses build fails with Ada
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 19:47 --- Subject: Bug 14997 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 19:47:09 Modified files: gcc: ChangeLog expr.c Log message: PR middle-end/14997 * expr.c (expand_expr_real) : Force op0 to mem when we would be extracting outside its bit span (bitpos+bitsize larger than its mode), possible with some VIEW_CONVERT_EXPRs from Ada unchecked conversions. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.9904&r2=2.9905 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/expr.c.diff?cvsroot=gcc&r1=1.814&r2=1.815 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14997
[Bug c++/23056] [4.0/4.1 regression] ICE in write_template_arg_literal, at cp/mangle.c
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 19:46 --- Subject: Bug 23056 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 19:46:41 Modified files: gcc/cp : ChangeLog typeck.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/opt: pr23056.C Log message: PR c++/23056 * typeck.c (ignore_overflows): New helper function. (build_static_cast_1): Use it. * g++.dg/opt/pr23056.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.93&r2=1.4648.2.94 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.616.2.16&r2=1.616.2.17 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.384&r2=1.5084.2.385 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/opt/pr23056.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23056
[Bug rtl-optimization/23098] [4.1 Regression] store of 0.0 to float
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 19:45 --- Subject: Bug 23098 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 19:44:45 Modified files: gcc: ChangeLog cse.c rtl.h simplify-rtx.c gcc/config/i386: i386.md gcc/testsuite : ChangeLog Added files: gcc/testsuite/gcc.target/i386: pr23098.c Log message: PR rtl-optimization/23098 * cse.c (fold_rtx): Call delegitimize_address target hook. * simplify-rtx.c (constant_pool_reference_p): New function. * rtl.h (constant_pool_reference_p): New prototype. * config/i386/i386.md (pushf split, mov[sdx]f split): Use constant_pool_reference_p in condition and avoid_constant_pool_reference in preparation statements. * gcc.target/i386/pr23098.c: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.413&r2=2.7592.2.414 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cse.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.345.2.2&r2=1.345.2.3 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/rtl.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.536&r2=1.536.4.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/simplify-rtx.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.230.2.7&r2=1.230.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.md.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.618.4.5&r2=1.618.4.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.383&r2=1.5084.2.384 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr23098.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.2.2.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug rtl-optimization/23098] [4.1 Regression] store of 0.0 to float
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 19:39 --- Subject: Bug 23098 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 19:38:59 Modified files: gcc/testsuite : ChangeLog gcc/testsuite/gcc.target/i386: pr23098.c Log message: PR rtl-optimization/23098 * gcc.target/i386/pr23098.c: Add dg-require-effective-target ilp32. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6018&r2=1.6019 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/gcc.target/i386/pr23098.c.diff?cvsroot=gcc&r1=1.1&r2=1.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23098
[Bug fortran/23677] -fno-automatic does not accept legal save statements
-- What|Removed |Added CC||dir at lanl dot gov http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23677
[Bug fortran/23677] -fno-automatic does not accept legal save statements
--- Additional Comments From dir at lanl dot gov 2005-09-06 19:31 --- I have the same problem (g77 does not complain) - [dranta:~/tests/gfortran-D] dir% g77 -c -fno-automatic save.f [dranta:~/tests/gfortran-D] dir% gfortran -c -fno-automatic save.f In file save.f:2 save lastcol 1 Error: Duplicate SAVE attribute specified at (1) [dranta:~/tests/gfortran-D] dir% cat save.f subroutine gdpstc(ifxn,xa,ya) save lastcol return end [dranta:~/tests/gfortran-D] dir% gfortran --v Using built-in specs. Target: powerpc-apple-darwin7.9.0 Configured with: ./configure --prefix=/Users/dir/gfortran --enable-languages=c,f95 Thread model: posix gcc version 4.1.0 20050906 (experimental) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23677
[Bug middle-end/22207] Spurious 'might be used uninitialized' warnings in STL headers with -O2
--- Additional Comments From ian at airs dot com 2005-09-06 18:59 --- Confirmed that this happens with 3.4 for the i686-pc-cygwin target, though not for the i686-pc-linux-gnu target. It is fixed in current mainline for both targets. -- What|Removed |Added CC||ian at airs dot com Status|UNCONFIRMED |NEW Ever Confirmed||1 Known to fail||3.4.4 Known to work||4.1.0 Last reconfirmed|-00-00 00:00:00 |2005-09-06 18:59:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22207
[Bug swing/20015] JMenu stays open but should not
--- Additional Comments From langel at redhat dot com 2005-09-06 18:40 --- fixed -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20015
[Bug libfortran/23356] FLT_EVAL_METHOD not defined on openbsd3.4
--- Additional Comments From ian at airs dot com 2005-09-06 17:48 --- Andrew Pinski pointed out that the problem is due to the setting of USER_H in config/t-openbsd to an empty string. That is most likely incorrect. (The only other target which tries to set USER_H at all it i386-netware, and that one is probably also wrong.) -- What|Removed |Added CC||ian at airs dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23356
[Bug libfortran/23380] [mingw32] cpu_time intrinsic malfunction
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-06 17:21 --- Well, I don't know what went wrong here, but: it works for me, with the 2005-08-05 binaries (downloaded the installer, etc.) Moreover, as the source of the binaries, I checked my config.h file, and it is indeed correct. $ cat cputime.f90 real x call cpu_time (x) print *, x end $ ./bin/gfortran.exe cputime.f90 && a -1.00 Well, perhaps "nothing's wrong" is a bit too optimistic since cpu_time does conform to the standard but is still not fully... satisfactory. Keeping this PR open to track the new issue (correct by Danny's win32 code). -- What|Removed |Added CC||fxcoudert at gcc dot gnu dot ||org GCC target triplet||i686-pc-mingw32 Last reconfirmed|2005-08-13 21:55:29 |2005-09-06 17:21:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23380
[Bug preprocessor/23751] cpp -P emits two newlines
--- Additional Comments From schwab at suse dot de 2005-09-06 16:14 --- cpp is barely the right tool for processing something that cannot tolerate extra whitespace. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23751
[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code
--- Additional Comments From gdr at integrable-solutions dot net 2005-09-06 16:12 --- Subject: Re: [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code "mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The problem behind both diagnostics fact that the C++ front-end pre-lexes the | entire source file. As a result, the lexing routines, which depends on the | setting of pedantic to determine whether or not to issue errors, are | called when pedantic is set, even though we are within an | __extension__ block. Because the parsing of __extension__ blocks is | complex, we need to either (a) eliminate the up-front lexing, or (b) | defer issuing diagnostics until we are actually in | position to know the correct value of pedantic. In long term, I believe (b) is a better alternative. -- Gaby -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139
Re: [Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code
"mmitchel at gcc dot gnu dot org" <[EMAIL PROTECTED]> writes: | The problem behind both diagnostics fact that the C++ front-end pre-lexes the | entire source file. As a result, the lexing routines, which depends on the | setting of pedantic to determine whether or not to issue errors, are | called when pedantic is set, even though we are within an | __extension__ block. Because the parsing of __extension__ blocks is | complex, we need to either (a) eliminate the up-front lexing, or (b) | defer issuing diagnostics until we are actually in | position to know the correct value of pedantic. In long term, I believe (b) is a better alternative. -- Gaby
[Bug libgcj/23739] JNI: IsAssignableFrom reverses arguments
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-06 16:04 --- Fix checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23739
[Bug libgcj/23739] JNI: IsAssignableFrom reverses arguments
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 16:03 --- Subject: Bug 23739 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 16:03:12 Modified files: libjava: ChangeLog jni.cc Log message: PR libgcj/23739: * jni.cc (_Jv_JNI_IsAssignableFrom): Reversed arguments. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.3391.2.94&r2=1.3391.2.95 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/jni.cc.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.95.2.1&r2=1.95.2.2 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23739
[Bug libgcj/23739] JNI: IsAssignableFrom reverses arguments
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 16:01 --- Subject: Bug 23739 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 16:01:32 Modified files: libjava: ChangeLog jni.cc link.cc prims.cc libjava/java/lang: natClass.cc libjava/java/lang/reflect: natMethod.cc libjava/testsuite: Makefile.in Added files: libjava/testsuite/libjava.jni: pr23739.c pr23739.java pr23739.out Log message: PR libgcj/23739: * testsuite/libjava.jni/pr23739.c: New file. * testsuite/libjava.jni/pr23739.java: New file. * testsuite/libjava.jni/pr23739.out: New file. * jni.cc (_Jv_JNI_IsAssignableFrom): Reversed arguments. * java/lang/reflect/natMethod.cc (invoke): Updated. * java/lang/natClass.cc (isAssignableFrom): Updated. (isInstance): Likewise. (_Jv_IsAssignableFrom): Reversed arguments. (_Jv_IsInstanceOf): Updated. (_Jv_CheckCast): Likewise. (_Jv_CheckArrayStore): Likewise. (_Jv_IsAssignableFromSlow): Reversed arguments. (_Jv_InterfaceAssignableFrom): Likewise. * link.cc (verify_type_assertions): Updated. * prims.cc (_Jv_CheckAccess): Updated. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/ChangeLog.diff?cvsroot=gcc&r1=1.3733&r2=1.3734 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/jni.cc.diff?cvsroot=gcc&r1=1.99&r2=1.100 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/link.cc.diff?cvsroot=gcc&r1=1.17&r2=1.18 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/prims.cc.diff?cvsroot=gcc&r1=1.112&r2=1.113 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/natClass.cc.diff?cvsroot=gcc&r1=1.89&r2=1.90 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/java/lang/reflect/natMethod.cc.diff?cvsroot=gcc&r1=1.46&r2=1.47 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/Makefile.in.diff?cvsroot=gcc&r1=1.86&r2=1.87 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/pr23739.c.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/pr23739.java.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/libjava/testsuite/libjava.jni/pr23739.out.diff?cvsroot=gcc&r1=NONE&r2=1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23739
[Bug preprocessor/23751] cpp -P emits two newlines
--- Additional Comments From johann dot glaser at gmx dot at 2005-09-06 15:59 --- Sure, but without -P no additional newlines are printed, so these two are clearly "to much". Since cpp is often used for other things than C preprocessing, newlines are annoying or even kill tools relying on it. I found this bug because we have a script sending emails which uses cpp to preprocess the mail content. Since the first few lines of the mail contain the header, no additional newlines are acceptable, because /usr/sbin/sendmail will interpret these as header-body-delimiter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23751
[Bug fortran/19269] transpose(reshape(...)) of character array segfaults.
--- Additional Comments From rsandifo at gcc dot gnu dot org 2005-09-06 15:54 --- There seem to be two problems here. First, gfc_simplify_reshape doesn't set the result's typespec correctly (it doesn't include a character length). Second, we're passing character lengths to the transpose library function, which only wants array descriptors. I'm testing a patch for the first problem. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-06-06 00:30:05 |2005-09-06 15:54:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19269
[Bug middle-end/19183] [3.4 Regression] ICE with -fPIC
--- Additional Comments From ebotcazou at gcc dot gnu dot org 2005-09-06 15:53 --- > No kidding. I guess you can probably refrain from posting such a comment. I think it should be possible to work around the problem by using renaming constructs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19183
[Bug preprocessor/23751] cpp -P emits two newlines
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-06 15:50 --- Why do you think this is a bug, really cpp can emit many different things with -P, -P just makes not emitting the line markers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23751
[Bug preprocessor/23751] New: cpp -P emits two newlines
The proeprocessor now emits two senseless newlines when used with the '-P' option. Reproduce: $ cpp -P asdfasdf ^D asdfasdf $ Versions prior to 4.0.1 didn't emit these two newlines. Probably 4.0.0. also didn't, but I can't test that here. The following verisions don't have this bug: gcc-Version 3.4.2 20041017 (Red Hat 3.4.2-6.fc3) gcc version 3.3.5 (Debian 1:3.3.5-13) These versions do have the bug: gcc version 4.0.1 (Debian 4.0.1-2) gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6) -- Summary: cpp -P emits two newlines Product: gcc Version: 4.0.1 Status: UNCONFIRMED Severity: normal Priority: P2 Component: preprocessor AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: johann dot glaser at gmx dot at CC: gcc-bugs at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23751
[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code
--- Additional Comments From joseph at codesourcery dot com 2005-09-06 15:42 --- Subject: Re: [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code On Tue, 6 Sep 2005, mmitchel at gcc dot gnu dot org wrote: > The problem behind both diagnostics fact that the C++ front-end pre-lexes the > entire source file. As a result, the lexing routines, which depends on the > setting of pedantic to determine whether or not to issue errors, are called > when > pedantic is set, even though we are within an __extension__ block. Because > the > parsing of __extension__ blocks is complex, we need to either (a) eliminate > the > up-front lexing, or (b) defer issuing diagnostics until we are actually in > position to know the correct value of pedantic. The lexing diagnostics depend on the preprocessor's setting of pedantic (which doesn't take account of parser context in any case), not the compiler's. This looks just like 7263/11931 for which I still prefer (c) handle specially expansions of macros defined in system headers. A fixinclude for definitions of HUGE_VAL as a hex float constant is a possible workaround. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139
[Bug fortran/23261] [meta-bug] [mingw32] gfortran testsuite bugs
-- Bug 23261 depends on bug 23265, which changed state. Bug 23265 Summary: [mingw32] Error in floating point output with BN edit descriptor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23265 What|Old Value |New Value Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23261
[Bug libfortran/23265] [mingw32] Error in floating point output with BN edit descriptor
--- Additional Comments From fxcoudert at gcc dot gnu dot org 2005-09-06 15:37 --- This bug is due to the sprintf-patch for mingw, not yet commited into mainline. Closing this, and I will submit a corrected patch. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23265
[Bug c++/23139] [3.4/4.0/4.1 Regression] -pedantic -ffast-math breaks working code
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-06 15:29 --- The problem behind both diagnostics fact that the C++ front-end pre-lexes the entire source file. As a result, the lexing routines, which depends on the setting of pedantic to determine whether or not to issue errors, are called when pedantic is set, even though we are within an __extension__ block. Because the parsing of __extension__ blocks is complex, we need to either (a) eliminate the up-front lexing, or (b) defer issuing diagnostics until we are actually in position to know the correct value of pedantic. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23139
[Bug c++/19253] [3.4/4.0/4.1 regression] bad error message / ICE for invalid template parameter
-- Bug 19253 depends on bug 18738, which changed state. Bug 18738 Summary: [3.4 Regression] typename not allowed with non-dependent qualified name http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18738 What|Old Value |New Value Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19253
[Bug c++/18738] [3.4 Regression] typename not allowed with non-dependent qualified name
--- Additional Comments From reichelt at gcc dot gnu dot org 2005-09-06 15:27 --- Fixed also on the 3.4 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18738
[Bug c++/18738] [3.4 Regression] typename not allowed with non-dependent qualified name
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 15:25 --- Subject: Bug 18738 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-3_4-branch Changes by: [EMAIL PROTECTED] 2005-09-06 15:25:13 Modified files: gcc/cp : ChangeLog decl.c parser.c gcc/testsuite : ChangeLog gcc/testsuite/g++.dg/parse: friend2.C Added files: gcc/testsuite/g++.dg/template: typename8.C Log message: Backport: 2004-12-14 Mark Mitchell <[EMAIL PROTECTED]> PR c++/18738 * decl.c (make_typename_type): Do not handle namespace-scoped names here. (tag_name): Handle typename_type. (check_elaborated_type_specifier): Handle typenames. * parser.c (cp_parser_diagnose_invalid_type_name): Do not call make_typename_type for namespace-scoped names here. (cp_parser_elaborated_type_specifier): Use cp_parser_diagnose_invalid_type_name. * g++.dg/template/typename8.C: New test. * g++.dg/parse/friend2.C: Tweak error message. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.239&r2=1.3892.2.240 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/decl.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1174.2.39&r2=1.1174.2.40 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.61&r2=1.157.2.62 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.432&r2=1.3389.2.433 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/template/typename8.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.46.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/friend2.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.1&r2=1.1.28.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18738
[Bug c++/21440] [4.0/4.1 Regression] ICE with statement-as-expression
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-06 15:15 --- *** Bug 23636 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||gj at pointblue dot com dot ||pl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21440
[Bug c++/23636] [4.0/4.1 Regression] crashes on ThreadWeaver compilation
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-06 15:15 --- *** This bug has been marked as a duplicate of 21440 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23636
[Bug c++/9782] [4.0/4.1 Regression] constructor not called on higher-dimensional arrays of template types
--- Additional Comments From mmitchel at gcc dot gnu dot org 2005-09-06 15:04 --- Fixed in 4.0.2. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9782
[Bug c++/9782] [4.0/4.1 Regression] constructor not called on higher-dimensional arrays of template types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 15:01 --- Subject: Bug 9782 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 15:01:04 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog call.c cp-tree.h init.c rtti.c tree.c typeck.c Added files: gcc/testsuite/g++.dg/expr: cast6.C gcc/testsuite/g++.dg/init: new15.C Log message: * cp-tree.h (rvalue): New function. * call.c (build_conditional_expr): Use it. * init.c (build_new_1): Likewise. * rtti.c (build_dynamic_cast_1): Likewise. * tree.c (rvalue): New function. * typeck.c (build_unary_op): Use it. (build_static_cast_1): Likewise. * g++.dg/expr/cast6.C: New test. PR c++/9782 * init.c (build_new_1): Make sure the entire array type is complete, not just its element types. PR c++/9782 * g++.dg/init/new15.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.5084.2.381&r2=1.5084.2.382 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/expr/cast6.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/new15.C.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=NONE&r2=1.1.2.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.4648.2.92&r2=1.4648.2.93 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.531.2.6&r2=1.531.2.7 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.1106.2.13&r2=1.1106.2.14 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.412.2.8&r2=1.412.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.210.6.1&r2=1.210.6.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.427.2.4&r2=1.427.2.5 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.616.2.15&r2=1.616.2.16 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9782
[Bug c++/9782] [4.0/4.1 Regression] constructor not called on higher-dimensional arrays of template types
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 14:55 --- Subject: Bug 9782 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 14:55:06 Modified files: gcc/testsuite : ChangeLog gcc/cp : ChangeLog call.c cp-tree.h init.c rtti.c tree.c typeck.c Added files: gcc/testsuite/g++.dg/expr: cast6.C gcc/testsuite/g++.dg/init: new15.C Log message: * cp-tree.h (rvalue): New function. * call.c (build_conditional_expr): Use it. * init.c (build_new_1): Likewise. * rtti.c (build_dynamic_cast_1): Likewise. * tree.c (rvalue): New function. * typeck.c (build_unary_op): Use it. (build_static_cast_1): Likewise. * g++.dg/expr/cast6.C: New test. PR c++/9782 * init.c (build_new_1): Make sure the entire array type is complete, not just its element types. PR c++/9782 * g++.dg/init/new15.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.6016&r2=1.6017 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/expr/cast6.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/init/new15.C.diff?cvsroot=gcc&r1=NONE&r2=1.1 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4874&r2=1.4875 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/call.c.diff?cvsroot=gcc&r1=1.550&r2=1.551 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/cp-tree.h.diff?cvsroot=gcc&r1=1.1161&r2=1.1162 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/init.c.diff?cvsroot=gcc&r1=1.428&r2=1.429 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/rtti.c.diff?cvsroot=gcc&r1=1.220&r2=1.221 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/tree.c.diff?cvsroot=gcc&r1=1.441&r2=1.442 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/typeck.c.diff?cvsroot=gcc&r1=1.650&r2=1.651 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9782
[Bug ada/23427] latent bug with array type size check
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-06 14:42 --- Patch looks good to me (and you should be able to test Ada now). The code is there on "unexpected" cases anyway, so it's not surprising that it is hard or even maybe impossible to trigger it. Arno -- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23427
[Bug ada/15604] Ambiguous aggregate -- Accepts invalid
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-06 14:34 --- Pathological case, so changing severity. -- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15604
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From tromey at gcc dot gnu dot org 2005-09-06 14:23 --- Fix checked in to 4.0 branch and trunk. -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Version|4.0.1 |4.0.2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 14:22 --- Subject: Bug 23662 CVSROOT:/cvs/gcc Module name:gcc Changes by: [EMAIL PROTECTED] 2005-09-06 14:22:01 Modified files: boehm-gc : ChangeLog boehm-gc/include/private: gcconfig.h Log message: PR libgcj/23662: * include/private/gcconfig.h (LINUX_STACKBOTTOM): Use instead of HEURISTIC1 on ARM. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/ChangeLog.diff?cvsroot=gcc&r1=1.230&r2=1.231 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/include/private/gcconfig.h.diff?cvsroot=gcc&r1=1.46&r2=1.47 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug boehm-gc/23662] Binaries generated by arm-linux-gcj segfault on execution on arm target
--- Additional Comments From cvs-commit at gcc dot gnu dot org 2005-09-06 14:21 --- Subject: Bug 23662 CVSROOT:/cvs/gcc Module name:gcc Branch: gcc-4_0-branch Changes by: [EMAIL PROTECTED] 2005-09-06 14:21:25 Modified files: boehm-gc : ChangeLog boehm-gc/include/private: gcconfig.h Log message: PR libgcj/23662: * include/private/gcconfig.h (LINUX_STACKBOTTOM): Use instead of HEURISTIC1 on ARM. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.219.2.7&r2=1.219.2.8 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/boehm-gc/include/private/gcconfig.h.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.39.18.4&r2=1.39.18.5 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23662
[Bug ada/22387] GCC Ada compiler crash
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-06 14:08 --- I agree that this is not a regression. If you could put less generic summary line, that would be really helpful. Imagine that everyone getting a compiler crash used the same summary: things would get very confused... Arno -- What|Removed |Added Summary|[4.0/4.1 Regression] GCC Ada|GCC Ada compiler crash |compiler crash. | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22387
[Bug middle-end/19183] [3.4 Regression] ICE with -fPIC
--- Additional Comments From ddavenpo at ball dot com 2005-09-06 14:07 --- Subject: Re: [3.4 Regression] ICE with -fPIC No kidding. On Sep 6, 2005, at 2:24 AM, ebotcazou at gcc dot gnu dot org wrote: > > --- Additional Comments From ebotcazou at gcc dot gnu dot org > 2005-09-06 08:24 --- > Not really working on this. > > > -- >What|Removed |Added > --- > - > CC||ebotcazou at gcc dot > gnu dot >||org > AssignedTo|ebotcazou at gcc dot gnu dot|unassigned at gcc dot > gnu >|org |dot org > Status|ASSIGNED|NEW > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19183 > > --- You are receiving this mail because: --- > You reported the bug, or are watching the reporter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19183
[Bug ada/22413] Cross build fails (multiple blank lines)
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-06 14:04 --- Probably a set up issue on your side. I would guess you are not using a consistent set of sources/native compiler. Arno -- What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22413
[Bug ada/23319] crash with interface as generic formal parameter
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-06 14:02 --- Not a regression: 4.0 simply did not support/recognize interfaces, so what you are getting is really ana Ada 95 error message. Code looks valid Ada 2005 at first sight, so removing keyword. Arno -- What|Removed |Added Keywords|ice-on-invalid-code | Summary|[4.1 Regression] Compiler |crash with interface as |crash with interface as |generic formal parameter |generic formal parameter| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23319
[Bug ada/15798] Bug box in Gigi, code=201, on legal program with tasking
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-06 13:36 --- Program has no semantic meaning, so lowering severity. -- What|Removed |Added Severity|normal |minor http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15798
[Bug ada/20596] Bug Box, combination of Ada 2005, dotted notation, Hash_Maps, and Unbounded_String
--- Additional Comments From charlet at gcc dot gnu dot org 2005-09-06 13:32 --- Now works fine on mainline. Arno -- What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20596
