[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #5 from paulthomas2 at wanadoo dot fr 2006-05-13 07:23 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work Bo, >> >> >> >You're very welcome, but actually thanks in Swedish spells "tack". > > I had guessed you to be Norwegian >Due to this bug I'm currently stuck with using g95, but I'm looking >forward to be able to move >to gfortran instead. > > With your testcase, on i386, I obtain the following output: s1 = "ABCDEFGH" ia = 1145258561 1212630597 s2 = "ABCDEFGH" s1 = "AB " ia =538985025 538976288 s2 = "AB " which looks good to me. Are you using a 64bit machine, by any chance? - see PR27449. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-13 07:30 --- (In reply to comment #5) > which looks good to me. Are you using a 64bit machine, by any chance? - > see PR27449. Only some targets will see the issue in PR 27449. x86_64 or PPC64 will not see the issue at all because alignment does not matter on those targets. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug inline-asm/23200] [4.0/4.1/4.2 regression] rejects "i"(&var + 1)
--- Comment #21 from stsp at users dot sourceforge dot net 2006-05-13 08:27 --- Hi guys. A question: are there any hopes to get this to work with -fpic? I mean, even the "i"(&var) doesn't work with -fpic. The "info gcc" says that all the constant addresses are resolved by the dynamic linker if -fpic is used. So I wonder, why can't it resolve also the addresses that are used inside the asm() block? Am I missing something obvious, or it is a bug too? -- stsp at users dot sourceforge dot net changed: What|Removed |Added CC||stsp at users dot ||sourceforge dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23200
[Bug c++/25845] want optional warning for non-constant declarations that could be constant
--- Comment #20 from sigra at home dot se 2006-05-13 08:44 ---
I see that the feature I asked for has been implemented in the Ada frontend of
GCC. This program:
with Ada.Text_IO; use Ada.Text_IO;
procedure Prov is
A : Natural := 0;
begin
Put_Line ("A =" & A'Img);
end Prov;
compiled with "gnatmake -gnatwa prov" will give the following warning:
prov.adb:3:04: warning: "A" is not modified, could be declared constant
Many thanks for this!
However I have to use other languages as well, especially C++. Therefore I want
the feature there too. You may think that Ada is for serious development while
C++ is just for ugly hacks and therefore does not need the kind of code
checking features that Ada has. But there are still people trying to do serious
development in C++. Why not try to make their work a little mor comfortable
too?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25845
[Bug target/26726] -fivopts producing out of bounds array refs
--- Comment #14 from uros at kss-loka dot si 2006-05-13 08:46 --- (In reply to comment #13) > This is now a target specific problem, on i?86 and x86_64 we are left with an > offset of -4B and so referencing &a[5] in the exit condition. > This is PR target/24669. -- uros at kss-loka dot si changed: What|Removed |Added BugsThisDependsOn||24669 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26726
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #7 from paulthomas2 at wanadoo dot fr 2006-05-13 09:31 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work Bo (and Andrew), I think that I have lost such few marbles as I ever had! Having converted to using the cl->backen_decl for one argument, it might be a good idea to do the same on the others..? I just have taken delivery of 5 tonnes of we concrete - as soon as it is spread, I will implement this. I will be back. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug target/27571] [4.2 regression] alpha: ICE in get_attr_usegp, at config/alpha/alpha.md:171
--- Comment #2 from steven at gcc dot gnu dot org 2006-05-13 09:45 --- Index: alpha.c === --- alpha.c (revision 113736) +++ alpha.c (working copy) @@ -7410,6 +7410,7 @@ alpha_does_function_need_gp (void) for (; insn; insn = NEXT_INSN (insn)) if (INSN_P (insn) + && ! JUMP_TABLE_DATA_P (insn) && GET_CODE (PATTERN (insn)) != USE && GET_CODE (PATTERN (insn)) != CLOBBER && get_attr_usegp (insn)) ? -- steven 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-05-13 09:45:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27571
[Bug fortran/27583] New: ICE for (invalid) save on automatic object
The following invalid program --- program test_save call foo(3) contains subroutine foo(n) implicit none integer :: n real, dimension(n), save :: r ! ERROR: save and variable-dependent dim r = 1.0 write(*,*) r end subroutine foo end program test_save --- Should emit a nice error message. However, it creates an ICE: test.f90: In function foo: test.f90:7: internal compiler error: in gfc_trans_auto_array_allocation, at fortran/trans-array.c:3418 Please submit a full bug report, g95 does: In file test.f90:7 real, dimension(n), save :: r 1 Error: Automatic variable 'r' at (1) cannot have the SAVE attribute and ifort does: fortcom: Error: test.f90, line 7: An automatic object must not appear in a SAVE statement or be declared with the SAVE attribute. [R] real, dimension(n), save :: r --^ -- Summary: ICE for (invalid) save on automatic object Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27583
[Bug fortran/27584] New: ICE on invalid "associate(x,(y))"
I get an ICE using: -- program test implicit none real, pointer :: x real, target :: y if(ASSOCIATED(X,(Y))) print *, 'Hello' end program test -- (If one corrects the error and uses associated(x,y), gfortran is happy.) test2.f90:0: internal compiler error: in gfc_check_associated, at fortran/check.c:535 g95: In file test2.f90:5 if(ASSOCIATED(X,(Y))) print *, 'Hello' 1 Error: 'target' argument of 'associated' intrinsic at (1) must be a POINTER or a TARGET ifort: fortcom: Error: test2.f90, line 5: The TARGET argument must have the POINTER or TARGET attribute. [ASSOCIATED] if(ASSOCIATED(X,(Y))) print *, 'Hello' ^ NAGf95: Error: test2.f90, line 5: TARGET arg to ASSOCIATED intrinsic not pointer/target -- Summary: ICE on invalid "associate(x,(y))" Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27584
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #8 from pault at gcc dot gnu dot org 2006-05-13 11:25 --- Created an attachment (id=11450) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11450&action=view) Potential fix for this PR (regtested FC5/Athlon1700) Bo, Would you give this a try, please? Tack Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Attachment #11445|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #9 from pault at gcc dot gnu dot org 2006-05-13 11:27 --- Created an attachment (id=11451) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11451&action=view) Testcase for the patch This is a slight development of your test; I wanted to be sure that non-trivial expressions would work. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug c/27558] Wrong type in warning
--- Comment #2 from jm at bourguet dot org 2006-05-13 11:40 --- Subject: Re: Wrong type in warning pinskia at gcc dot gnu dot org a écrit : >--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-11 15:55 >--- >I cannot reproduce this in "4.1.0 20060208" or "4.2.0 20060507". > >t.c:5: warning: format '%s' expects type 'char *', but argument 3 has type >'char (*)[40]' > I've just recompiled 4.1.0 from the release tarball here -- I had no 4.1.0 build on this computer -- and I get the same message as you. I reproduced the problem here with version gcc 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9) When I'll have time, I'll check the behaviour on the computer I was using when I reported the problem. Yours, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27558
[Bug fortran/27586] New: Compile-time warn if arguments don't match in terms of precision
The following test case uses single precision arguments to a double precision function. Expected: Warn during compiling Actual: No warning is given. ./a.out shows: 0.00 3.0132665E+23 ! initialized with 2 & sqrt(2) In order to make it work across files, the .mod file should contain such information (and it should be used). >From http://www.polyhedron.com/pb05/linux/diagnose.html For the following file gfortran should issue a warning as x,y are once real and once double precision. --- ! argument mismatch - same file program arg1 call sub(x,y) print * , x,y end subroutine sub(x,y) double precision x,y x = 2.0 y = sqrt(x) end gfortran-4.2 -Wall -pedantic -fbounds-check ARG1.F produces no warning Whereas ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk ARG1.F fortcom: Error: ARG1.F, line 3: The type of the actual argument differs from the type of the dummy argument. [X] call sub(x,y) ---^ fortcom: Error: ARG1.F, line 3: The type of the actual argument differs from the type of the dummy argument. [Y] call sub(x,y) -^ g95 -Wall -pedantic -fbounds-check -ftrace=full ARG1.F In file ARG1.F:3 call sub(x,y) 1 In file ARG1.F:6 subroutine sub(x,y) 2 Warning (155): Inconsistent types (REAL(4)/REAL(8)) in actual argument lists at (1) and (2) NAG: f95 -C=all -C=undefined -info -g -gline ARG1.F Error: /tmp/ARG1.020753.f: Argument X (no. 1) in reference to SUB from ARG1 has the wrong data type Error: /tmp/ARG1.020753.f: Argument Y (no. 2) in reference to SUB from ARG1 has the wrong data type A meaner test is the following: -- ! argument mismatch - different file program arg2 call sub(x,y) print * , x,y end --- -- ! argument mismatch - different file subroutine sub(x,y) double precision x,y x = 2.0 y = sqrt(x) end --- gfortran does not catch the problem either, of g95, ifort and NAGf95 only the Intel compiler catches this - when compiling ARG2B.F ARG2A.F. (ARG2A.F ARG2B.F no compiler catches.) Actually, none of the compilers catches this at run time either. ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk ARG2B.F ARG2A.F fortcom: Error: ARG2A.F, line 3: The type of the actual argument differs from the type of the dummy argument. [X] call sub(x,y) ---^ fortcom: Error: ARG2A.F, line 3: The type of the actual argument differs from the type of the dummy argument. [Y] call sub(x,y) -^ compilation aborted for ARG2A.F (code 1) -- Summary: Compile-time warn if arguments don't match in terms of precision Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27586
[Bug fortran/27587] New: Warn when Scalar constant passed to array dummy argument
Taken from http://www.polyhedron.com/pb05/linux/diagnose.html --- real function same(x) implicit none real x(1) same = x(1) end program xtwice implicit none real same external same print*,same(10.0) print*,'Bug not caught!' end -- Current behaviour: prints 10.0 Expected: Warn/error that argument is not an array. ~> gfortran-4.2 -Wall -pedantic -fbounds-check ARG7.F ARG7.F:34: warning: no newline at end of file ~> ./a.out 10.0 Bug not caught! Comparison with other compilers: ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk ARG7.F fortcom: Error: ARG7.F, line 31: If the actual argument is scalar, the corresponding dummy argument shall be scalar unless the actual argu ment is an element of an array that is not an assumed-shape or pointer array, or a substring of such an element. [X] print*,same(10.0) -^ compilation aborted for ARG7.F (code 1) NAG: f95 -C=all -C=undefined -info -g -gline ARG7.F Error: /tmp/ARG7.022067.f: Argument X (no. 1) in reference to SAME from XTWICE is not an array [f95 error termination] -- Summary: Warn when Scalar constant passed to array dummy argument Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27587
[Bug fortran/27588] New: -fbounds-check should catch substring out of range accesses
Taken from http://www.polyhedron.com/pb05/linux/diagnose.html - ! character bound error - local variable program cbnd1 character*10 zz i = 2 j = i+9 zz(i:j) = 'abcdef' print * , zz end -- gfortran-4.2 -Wall -pedantic -fbounds-check CBND1.F ./a.out ^Aabcdef Expected: Issue a run-time error message. Examples of other compilers: ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk CBND1.F ./a.out forrtl: severe (408): fort: (4): Variable ZZ has substring ending point 11 which is greater than the variable length of 10 g95 -Wall -pedantic -fbounds-check -ftrace=full CBND1.F ./a.out At line 6 of file CBND1.F Traceback: (Innermost first) Fortran runtime error: Substring reference out of bounds: (2:11) in string of length 10 NAG: f95 -C=all -C=undefined -info -g -gline CBND1.F Out of range: substring ending position 11 is greater than length 10 Program terminated by fatal error In CBND1, line 6 of CBND1.F The following is even detected at compile time by the intel and NAGf95 compilers (gfortran does not detect it at compile or runtime): -- ! Check character bound error - assign to dummy argument which is larger than actual arg program cbnd3 character*10 zz,zzz common /aaa/zz,zzz zz = '00' zzz = '11' call sub(zz) print * , zzz end subroutine sub(zz) character*11 zz zz = 'abcdef' print * , zz end --- -- Summary: -fbounds-check should catch substring out of range accesses Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug fortran/27588] -fbounds-check should catch substring out of range accesses
-- tobias dot burnus at physik dot fu-berlin dot de changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27588
[Bug fortran/27589] New: Add compiler flag to check for uninitalized values at runtime
Currently, gfortran does not seem to have any option to catch uninitialized variables at run time. Example (from http://www.polyhedron.com/pb05/linux/diagnose.html): program uin1 integer x,y,a,b x=y a=b print *,x,a b=1 end --- Other compilers have an options to catch those, e.g.: ifort64-9.1 -C -check all -warn all,nodec,interfaces -gen_interfaces -traceback -fpe0 -fpstkchk UIN1.F ./a.out forrtl: severe (193): Run-Time Check Failure. The variable 'uin1_$Y' is being used without being defined NAG: f95 -C=all -C=undefined -info -g -gline UIN1.F ./a.out Reference to undefined variable Y Program terminated by fatal error In UIN1, line 5 of UIN1.F -- Summary: Add compiler flag to check for uninitalized values at runtime Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug fortran/27589] Add compiler flag to check for uninitalized values at runtime
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-13 14:17 --- Post scriptum: In this case, using -Wuninitialized -O the compiler detects that the variable is uninitialized; however, for the other UIN*.FOR examples at polyhdron.com they are not detected at compile-time. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27589
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #10 from bo dot berggren at glocalnet dot net 2006-05-13 15:50 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work pault at gcc dot gnu dot org skrev: > --- Comment #8 from pault at gcc dot gnu dot org 2006-05-13 11:25 --- > Created an attachment (id=11450) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11450&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11450&action=view) > Potential fix for this PR (regtested FC5/Athlon1700) > > Bo, > > Would you give this a try, please? > > Tack > > Paul > > > Should I download the latest source code snapshot and apply the patch on that ? Bo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug java/27590] New: [regression] ICE when compiling catalina.jar from tomcat 5.0.30
When compiling catalina.jar to a shared library (using BC ABI) I get an ICE. /usr/bin/gcj-4.1 -shared -O2 -fPIC -findirect-dispatch -fjni -Wl,-Bsymbolic ./org.eclipse.tomcat_5.0.30/catalina.jar -o /home/mkoch/Debian/java/eclipse/eclipse-3.1.2/debian/tmp//usr/lib/gcj-4.1/./org.eclipse.tomcat_5.0.30/catalina.jar.so org/apache/catalina/core/StandardServer.java: In class 'org.apache.catalina.core.StandardServer': org/apache/catalina/core/StandardServer.java: In method 'org.apache.catalina.core.StandardServer.storeConfig()': org/apache/catalina/core/StandardServer.java:0: 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. For Debian GNU/Linux specific bug reporting instructions, see . To make it easier to debug this I uploaded the catalina.jar to http://people.debian.org/~mkoch/catalina.jar -- Summary: [regression] ICE when compiling catalina.jar from tomcat 5.0.30 Product: gcc Version: 4.1.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: java AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: konqueror at gmx 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=27590
[Bug java/27590] [regression] ICE when compiling catalina.jar from tomcat 5.0.30
--- Comment #1 from konqueror at gmx dot de 2006-05-13 17:22 --- $ gcj-4.1 -v Using built-in specs. Reading specs from /usr/lib/gcc/i486-linux-gnu/4.1.1/../../../libgcj.spec rename spec lib to liborig Target: i486-linux-gnu Configured with: ../src/configure -v --enable-languages=c,c++,java --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --program-suffix=-4.1 --enable-__cxa_atexit --enable-clocale=gnu --enable-java-awt=gtk-default --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-4.1-1.4.2.0/jre --with-tune=i686 --enable-checking=release i486-linux-gnu Thread model: posix gcc version 4.1.1 20060428 (prerelease) (Debian 4.1.0-2j1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27590
[Bug java/27590] [regression] ICE when compiling catalina.jar from tomcat 5.0.30
--- Comment #2 from konqueror at gmx dot de 2006-05-13 17:27 --- I tried with -O0 and -O1. The bug doesnt happen with -O0 but with -O1 and -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27590
[Bug fortran/27021] Problem with nearest(tiny(o),-1.0)/2.0
-- kargl at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|kargl at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27021
[Bug tree-optimization/27590] [regression] ICE when compiling catalina.jar from tomcat 5.0.30
-- aph at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-05-13 17:54:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27590
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #11 from bo dot berggren at glocalnet dot net 2006-05-13 18:01 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work pault at gcc dot gnu dot org skrev: > --- Comment #8 from pault at gcc dot gnu dot org 2006-05-13 11:25 --- > Created an attachment (id=11450) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11450&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11450&action=view) > Potential fix for this PR (regtested FC5/Athlon1700) > > Bo, > > Would you give this a try, please? > > Tack > > Paul > > > Should I download the latest source code snapshot and apply the patch on that ? Bo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug debug/26754] [4.0/4.1/4.2 Regression] Wrong debug info for variable accessed non-locally
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2006-05-13 18:55 --- Patch in preparation. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-03-20 07:54:11 |2006-05-13 18:55:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26754
[Bug tree-optimization/25737] [4.1/4.2 Regression] ACATS c974001 c974013 hang with struct aliasing
-- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added 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=25737
[Bug middle-end/20722] select_section invoked with argument "unlikely"
--- Comment #2 from roger at eyesopen dot com 2006-05-13 18:59 ---
This is the correct documented behaviour. See the section entitled
"USE_SELECT_SECTION_FOR_FUNCTIONS" in doc/tm.texi, which reads:
> @defmac USE_SELECT_SECTION_FOR_FUNCTIONS
> Define this macro if you wish TARGET_ASM_SELECT_SECTION to be called
> for @code{FUNCTION_DECL}s as well as for variables and constants.
>
> In the case of a @code{FUNCTION_DECL}, @var{reloc} will be zero if the
> function has been determined to be likely to be called, and nonzero if
> it is unlikely to be called.
> @end defmac
This is also cross referenced from the TARGET_ASM_SELECT_SECTION target
hook documentation, as the semantics for selecting function sections.
The only backend(s) that define USE_SELECT_SECTION_FOR_FUNCTIONS, darwin,
appears to implement the semantics as described above.
The two calls in function_section and current_function_section are guarded
by #ifdef USE_SELECT_SECTION_FOR_FUNCTIONS. Admittedly, this could have
been implemented by a second target hook, and/or the variable names in the
varasm functions could be less confusing, but this isn't a bug, and certainly
not P1.
--
roger at eyesopen dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20722
[Bug c/27558] Wrong type in warning
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-13 19:02 --- So this was fixed in 4.1.0 proper. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27558
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #12 from paulthomas2 at wanadoo dot fr 2006-05-13 19:09 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work bo, >Should I download the latest source code snapshot and apply the patch on >that ? > > > No, that will not help. With the patch applied, could you compile the testcase with -fdump-tree-original, please? You will find a file with your_file_name.f90.some_stuff.original in the current directory. Send me that please. If that does not do the job, we will have to start looking at the assembly output. What is your cpu? Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug c++/27591] New: Compiler crash with typeid(typeid(*a))
The crash is during compilation.
I run a Debian with the Linux kernel 2.6.14
The error is (with the recommended command line):
** BEGINNING OF GCC OUTPUT **
$ gcc -v -save-temps -o ti_bug ti_bug.cc Err 1
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
--without-included-gettext --enable-threads=posix --enable-nls
--program-suffix=-4.0 --enable-__cxa_atexit --enable-clocale=gnu
--enable-libstdcxx-debug --enable-java-awt=gtk-default --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 --with-tune=i686 --enable-checking=release i486-linux-gnu
Thread model: posix
gcc version 4.0.4 20060422 (prerelease) (Debian 4.0.3-2)
/usr/lib/gcc/i486-linux-gnu/4.0.4/cc1plus -E -quiet -v -D_GNU_SOURCE ti_bug.cc
-mtune=i686 -fpch-preprocess -o ti_bug.ii
ignoring nonexistent directory "/usr/local/include/i486-linux-gnu"
ignoring nonexistent directory "/usr/include/i486-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/i486-linux-gnu
/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/backward
/usr/local/include
/usr/lib/gcc/i486-linux-gnu/4.0.4/include
/usr/include
End of search list.
/usr/lib/gcc/i486-linux-gnu/4.0.4/cc1plus -fpreprocessed ti_bug.ii -quiet
-dumpbase ti_bug.cc -mtune=i686 -auxbase ti_bug -version -o ti_bug.s
GNU C++ version 4.0.4 20060422 (prerelease) (Debian 4.0.3-2) (i486-linux-gnu)
compiled by GNU C version 4.0.4 20060422 (prerelease) (Debian 4.0.3-2).
GGC heuristics: --param ggc-min-expand=90 --param ggc-min-heapsize=113348
ti_bug.cc: In function 'int main()':
ti_bug.cc:10: internal compiler error: in create_tmp_var, at gimplify.c:368
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
For Debian GNU/Linux specific bug reporting instructions,
see .
** END OF GCC OUTPUT **
And here is the preprocessed file that cause the bug (there is nothing
afterward) :
# 1 "ti_bug.cc"
# 1 ""
# 1 ""
# 1 "ti_bug.cc"
# 1 "/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/typeinfo"
1 3
# 38 "/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/typeinfo"
3
# 1 "/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/exception"
1 3
# 40
"/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/exception" 3
#pragma GCC visibility push(default)
extern "C++" {
namespace std
{
# 54
"/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/exception" 3
class exception
{
public:
exception() throw() { }
virtual ~exception() throw();
virtual const char* what() const throw();
};
class bad_exception : public exception
{
public:
bad_exception() throw() { }
virtual ~bad_exception() throw();
};
typedef void (*terminate_handler) ();
typedef void (*unexpected_handler) ();
terminate_handler set_terminate(terminate_handler) throw();
void terminate() __attribute__ ((__noreturn__));
unexpected_handler set_unexpected(unexpected_handler) throw();
void unexpected() __attribute__ ((__noreturn__));
# 102
"/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/exception" 3
bool uncaught_exception() throw();
}
namespace __gnu_cxx
{
# 117
"/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/exception" 3
void __verbose_terminate_handler ();
}
}
#pragma GCC visibility pop
# 39 "/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/typeinfo"
2 3
#pragma GCC visibility push(default)
extern "C++" {
namespace __cxxabiv1
{
class __class_type_info;
}
# 59 "/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/typeinfo"
3
namespace std
{
class type_info
{
public:
virtual ~type_info();
private:
type_info& operator=(const type_info&);
type_info(const type_info&);
protected:
const char *__name;
protected:
explicit type_info(const char *__n): __name(__n) { }
public:
const char* name() const
{ return __name; }
# 105
"/usr/lib/gcc/i486-linux-gnu/4.0.4/../../../../include/c++/4.0.4/typeinfo" 3
bool before(const type_info& __arg) const
{ return __name < __arg.__name; }
bool operator==(const type_info& __arg) const
{ return __name == __arg.__name; }
bool operator!=(const type_info& __arg) const
{ return !operator==(__arg); }
public:
virtual bool __is_pointer_p() const;
virtual bool __is_function_p() const;
virtual bool __do_catch(const type_info *__thr_type, void **__thr_obj,
unsigned __outer)
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #13 from bo dot berggren at glocalnet dot net 2006-05-13 19:42 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work pault at gcc dot gnu dot org skrev: > --- Comment #8 from pault at gcc dot gnu dot org 2006-05-13 11:25 --- > Created an attachment (id=11450) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11450&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11450&action=view) > Potential fix for this PR (regtested FC5/Athlon1700) > > Bo, > > Would you give this a try, please? > > Tack > > Paul > > > Yes, now it works!! Tack så mycket (thanks a lot) Bo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-05-13 19:44 --- Hmm, there are two switch tables in main which is causing the problem. Right now I have 139 line testcase and I am still reducing it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #14 from bo dot berggren at glocalnet dot net 2006-05-13 19:44 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work paulthomas2 at wanadoo dot fr skrev: > --- Comment #12 from paulthomas2 at wanadoo dot fr 2006-05-13 19:09 > --- > Subject: Re: Transfer of character to integer array and > vice versa still doesn't work > > bo, > > >> Should I download the latest source code snapshot and apply the patch on >> that ? >> >> >> >> > No, that will not help. With the patch applied, could you compile the > testcase with -fdump-tree-original, please? You will find a file > with your_file_name.f90.some_stuff.original in the current > directory. Send me that please. If that does not do the job, we will > have to start looking at the assembly output. > > What is your cpu? > > Paul > > Paul, I have only tried gfortran on 32 bit cpus. I downloaded the latest subversion snapshot, applied the patch and compiled the compilers. Now the test case works!! Thanks, Bo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug tree-optimization/27003] [4.0 Regression] ivcanon bug
--- Comment #3 from rakdver at gcc dot gnu dot org 2006-05-13 19:46 --- Subject: Bug 27003 Author: rakdver Date: Sat May 13 19:45:56 2006 New Revision: 113742 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113742 Log: PR tree-optimization/27003 * tree.c (build_int_cst_type): Avoid shift by size of type. * gcc.dg/pr27003.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr27003.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/testsuite/ChangeLog branches/gcc-4_0-branch/gcc/tree.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27003
[Bug fortran/27155] Transfer of character to integer array and vice versa still doesn't work
--- Comment #15 from paulthomas2 at wanadoo dot fr 2006-05-13 20:00 --- Subject: Re: Transfer of character to integer array and vice versa still doesn't work bo, >Paul, >I have only tried gfortran on 32 bit cpus. I downloaded the latest >subversion snapshot, applied the patch and compiled the compilers. >Now the test case works!! > >Thanks, >Bo > > > > What???!!! That is truly bizarre. What version of gcc were you working with? It can only be that there has been some backend change which has enabled this. I use nothing from gfortran that has not been in place for some months. Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27155
[Bug c++/27592] New: dynamic cast failure
The code below fails during the 7th loop iteration with an exception
'bad_cast':
#include
using namespace std;
class A
{
public:
virtual ~A()
{}
};
class B :
public A
{
};
int main()
{
string arg = "something";
int n = 0;
while (true)
{
cout << "n=" << ++n << endl;
A* a = new B;
B& ret = dynamic_cast(*a);
}
}
The output is the following:
n=1
n=2
n=3
n=4
n=5
n=6
n=7
terminate called after throwing an instance of 'std::bad_cast'
what(): St8bad_cast
Aborted
It fails on x86_64-unknown-linux-gnu, gcc version 4.2.0 20060513.
It does work on i686-pc-linux-gnu and seems to work on earlier versions of the
4.2.0 branch.
It also works correctly when the seemingly unrelated line
string arg = "something";
is removed.
--
Summary: dynamic cast failure
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: ingo dot josopait at gmx dot de
GCC host triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug c/27593] New: bad code generation
Hello,
I hope that I'm at the right place here.
I'm using debian gcc-avr:
Package: gcc-avr
Version: 1:4.1.0-1
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (850, 'testing'), (600, 'unstable'), (1, 'experimental')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/dash
Kernel: Linux 2.6.15-1-k7
Locale: LANG=de_AT, LC_CTYPE=de_AT (charmap=ISO-8859-1)
Versions of packages gcc-avr depends on:
ii binutils-avr 2.16.1-1 Binary utilities that support Atme
ii libc6 2.3.6-7GNU C Library: Shared libraries
gcc-avr recommends no packages.
-- no debconf information
This piece of code gets compiled incorrectly.
SIGNAL(SIG_INTERRUPT0)
{
if (PIND & _BV(PD2))
{
low_period=TCNT1;
}
else
{
high_period=TCNT1;
}
}
The result is:
SIGNAL(SIG_INTERRUPT0)
{
294: 1f 92 pushr1
296: 0f 92 pushr0
298: 0f b6 in r0, 0x3f; 63
29a: 0f 92 pushr0
29c: 11 24 eor r1, r1
29e: 2f 93 pushr18
2a0: 8f 93 pushr24
2a2: 9f 93 pushr25
if (PIND & _BV(PD2))
2a4: 4a 9b sbis0x09, 2 ; 9
2a6: 09 c0 rjmp.+18; 0x2ba <__vector_1+0x26>
{
// now H
high_period=TCNT1;
2a8: 80 91 84 00 lds r24, 0x0084
2ac: 90 91 85 00 lds r25, 0x0085
2b0: 90 93 0c 01 sts 0x010C, r25
2b4: 80 93 0b 01 sts 0x010B, r24
2b8: 08 c0 rjmp.+16; 0x2ca <__vector_1+0x36>
}
else
{
low_period=TCNT1;
2ba: 20 91 84 00 lds r18, 0x0084
2be: 30 91 85 00 lds r19, 0x0085
2c2: 30 93 0e 01 sts 0x010E, r19
2c6: 20 93 0d 01 sts 0x010D, r18
2ca: 9f 91 pop r25
2cc: 8f 91 pop r24
2ce: 2f 91 pop r18
2d0: 0f 90 pop r0
2d2: 0f be out 0x3f, r0; 63
2d4: 0f 90 pop r0
2d6: 1f 90 pop r1
2d8: 18 95 reti
- r0, r1 are pushed/popped, r1 is zeroed.
If 0x3f really needs to be saved, it could be done by
another register, which has to be used anyway.
(or instead of (r18, r19, r24, r25) (r0,r1) should be used.)
- r19 is modified, but not saved
- this whole construct could be optimized very much better.
- -Os, as already used, is much better than without. -O7 or -O2
give the same result as -Os.
Please see the attached files for details.
Thank you.
--
Summary: bad code generation
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: philipp at marek dot priv dot at
GCC build triplet: i486-linux-gnu
GCC host triplet: i486-linux-gnu
GCC target triplet: avr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27593
[Bug c/27593] bad code generation
--- Comment #1 from philipp at marek dot priv dot at 2006-05-13 20:09 --- Created an attachment (id=11452) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11452&action=view) The C file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27593
[Bug c/27593] bad code generation
--- Comment #2 from philipp at marek dot priv dot at 2006-05-13 20:09 --- Created an attachment (id=11453) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11453&action=view) The Makefile -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27593
[Bug c/27593] bad code generation
--- Comment #3 from philipp at marek dot priv dot at 2006-05-13 20:10 --- Created an attachment (id=11454) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11454&action=view) The preprocessor output -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27593
[Bug c/27593] bad code generation
--- Comment #4 from philipp at marek dot priv dot at 2006-05-13 20:11 --- Created an attachment (id=11455) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11455&action=view) The output (dump) file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27593
[Bug c++/27591] Compiler crash with typeid(typeid(*a))
--- Comment #1 from fang at csl dot cornell dot edu 2006-05-13 21:01 --- Very reminiscent of PR 25357. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27591
[Bug c++/27591] Compiler crash with typeid(typeid(*a))
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-13 21:21 --- And it is as this works in 4.1.0 and above. *** This bug has been marked as a duplicate of 25357 *** -- 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=27591
[Bug c++/25357] [4.0 Regression] ICE in typeid
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-13 21:21 --- *** Bug 27591 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||p dot barbierdereuille at ||free dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25357
[Bug c++/27592] [4.2 Regression] dynamic cast failure
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-13 21:38 --- - D.30091 = __dynamic_cast (a.85, &_ZTI1A, &_ZTI1B, 0); - if (D.30091 != 0B) goto ; else goto ; + D.30521 = __dynamic_cast (a.82, &_ZTI1A, &_ZTI1B, 0); + D.30522 = (bool) D.30521; - is 4.1 and + is 4.2. That is interesting. I am thinking D.30521 is at this point a&0xFF == 0 so we get the bug. D.30521 is a void* here. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2006-05-13 21:38:34 date|| Summary|dynamic cast failure|[4.2 Regression] dynamic ||cast failure Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27592
[Bug c++/27581] [4.0/4.1/4.2 regression] ICE using this-pointer in static member function
--- Comment #1 from patchapp at dberlin dot org 2006-05-13 21:46 --- Subject: Bug number PR c++/27581 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-05/msg00538.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27581
[Bug c++/27582] [4.0/4.1/4.2 regression] ICE with invalid template parameter
--- Comment #1 from patchapp at dberlin dot org 2006-05-13 21:46 --- Subject: Bug number PR c++/27582 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-05/msg00537.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27582
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-05-13 21:56 --- We are losing a REG_LABEL somewhere. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-13 21:59 ---
(insn 317 243 301 (set (reg/f:SI 19 %l3 [167])
(lo_sum:SI (reg/f:SI 19 %l3 [167])
(label_ref:SI 123))) 39 {*movsi_lo_sum} (nil)
(nil))
There is no REG_LABEL on that instruction which causes us to delete that label.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-13 22:05 --- Hmmm, it seems like it is an expand bug, as REG_LABEL is not added at expand time: (insn 36 35 37 (set (reg:SI 134) (high:SI (label_ref:SI 42))) -1 (nil) (nil)) (insn 37 36 38 (set (reg/f:SI 133) (lo_sum:SI (reg:SI 134) (label_ref:SI 42))) -1 (nil) (expr_list:REG_EQUAL (label_ref:SI 42) (nil))) (This expand is actually the first switch table and not the second and both don't have REG_LABEL). -- pinskia 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-05-13 22:05:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug target/27531] [4.2 regression] sparc: undefined reference to .LL226 with -O2
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-05-13 22:06
---
Here is the reduced testcase as I could get it (LL20 is not recorded here as
being used):
typedef struct _IO_FILE FILE;
extern char const *RCSname;
extern struct rcslock *Locks;
extern struct hshentry * Head;
struct Revpairs{
struct Revpairs * rnext;
};
static void getrevpairs (char*);
static int branchflag;
static struct Revpairs *revlist, *Revlst;
char *t;
int main (int argc, char **argv)
{
FILE *out;
char *a, **newargv;
struct Datepairs *currdate;
int descflag, selectflag;
int onlylockflag;
int onlyRCSflag;
int shownames;
descflag = selectflag = shownames = 1;
onlylockflag = onlyRCSflag = 0;
while (a = *++argv, 0<--argc)
{
switch (*a++)
{
case 'L':
onlylockflag = 1;
case 'N':
shownames = 0;
case 'R':
t = a;
case 'b':
branchflag = 1;
case 'r':
getrevpairs(a);
}
if (onlylockflag && !Locks)
aprintf(out, "%s\n", RCSname);
if (shownames)
while( currdate)
recentdate(Head, currdate);
}
}
void getrevpairs(char *argv)
{
char c;
struct Revpairs * nextrevpair;
int separator;
if (strchr(argv,':'))
separator = ':';
else
{
if (strchr(argv,'-') )
warn("`-' is obsolete in `-r%s'; use `:' instead", argv);
separator = '-';
}
for (;;)
{
nextrevpair->rnext = revlist;
for (;; c = *++argv)
{
switch (c)
{
default:
continue;
case ' ':
case '\t':
case '\n':
break;
case ':':
case '-':
if (c == separator)
continue;
}
break;
}
if (!c)
break;
error("missing `,' near `%c%s'", c, argv+1);
}
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27531
[Bug rtl-optimization/27335] [4.0/4.1 regression] ICE in get_loop_body
--- Comment #7 from rakdver at gcc dot gnu dot org 2006-05-13 22:11 --- Subject: Bug 27335 Author: rakdver Date: Sat May 13 22:10:56 2006 New Revision: 113746 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113746 Log: PR rtl-optimization/27335 * loop-unroll.c (peel_loops_completely): Use loops->parray to walk the loops. * gcc.dg/pr27335.c: New test. Added: branches/gcc-4_0-branch/gcc/testsuite/gcc.dg/pr27335.c Modified: branches/gcc-4_0-branch/gcc/ChangeLog branches/gcc-4_0-branch/gcc/loop-unroll.c branches/gcc-4_0-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug rtl-optimization/27335] [4.0/4.1 regression] ICE in get_loop_body
--- Comment #8 from rakdver at gcc dot gnu dot org 2006-05-13 22:12 --- Subject: Bug 27335 Author: rakdver Date: Sat May 13 22:12:13 2006 New Revision: 113747 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113747 Log: PR rtl-optimization/27335 * loop-unroll.c (peel_loops_completely): Use loops->parray to walk the loops. * gcc.dg/pr27335.c: New test. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr27335.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/loop-unroll.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug rtl-optimization/27335] [4.0/4.1 regression] ICE in get_loop_body
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-05-13 22:16 --- Fixed. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27335
[Bug fortran/27594] New: Warn/Error when number of arguments of a function does not match
The following testcase has a function with 13 arguments, but 14 are passed. gfortran-4.2 -Wall does not show a warning. Other compilers: NAG's f95 (no options): Error: test2.f: Wrong number of arguments to TRNS from TEST: 14 found, 13 expected g95 (Default-on warning): In file test2.f:19 & ,NCNF1,ACNF1,ICNF1,ACNF2,ICNF2,NORD) 12 Warning (154): Inconsistent number of arguments in reference to 'trns' at (1) and (2) Testfile: -- SUBROUTINE TRNS(NCNF ,ACNF,ICNF,NTRN,ATRN,NORD,AORD,IORD & ,NCNF1,ACNF1,ICNF1,ACNF2,ICNF2) PARAMETER(NCNFM=5,NORDM=100) CHARACTER*16 ACNF(NCNFM),ACNF1(NCNFM),ACNF2(NCNFM),AORD(NORDM) DIMENSIONICNF(NCNFM),ICNF1(NCNFM),ICNF2(NCNFM),IORD(NORDM) CHARACTER*16 ATRN,AT,AC,APPND DIMENSIONIW(100) END SUBROUTINE TRNS PROGRAM TEST IMPLICIT REAL*8 (A-H,O-Z) PARAMETER(NCNFM=5,IUIN=3,IUOUT=1,NORDM=100) CHARACTER*16 ACNF(NCNFM),ACNF1(NCNFM),ACNF2(NCNFM),ATRN(100) &,AORD(NORDM) DIMENSIONICNF(NCNFM),ICNF1(NCNFM),ICNF2(NCNFM),ITRN(100) &,IORD(NORDM) CALL TRNS(NCNF,ACNF,ICNF,ITRN(L),ATRN(L),NORD,AORD,IORD & ,NCNF1,ACNF1,ICNF1,ACNF2,ICNF2,NORD) END PROGRAM TEST -- -- Summary: Warn/Error when number of arguments of a function does not match Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tobias dot burnus at physik dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27594
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-05-13 22:25 --- *** Bug 27594 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug fortran/27594] Warn/Error when number of arguments of a function does not match
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-13 22:25 --- Just a note, I already filed a bug about this. IFC does not even warn or error out when this happens which does not help people trying to convert their code from IFC to any other good compiler. *** This bug has been marked as a duplicate of 26227 *** -- 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=27594
[Bug fortran/27586] Compile-time warn if arguments don't match in terms of precision
--- Comment #1 from tobias dot burnus at physik dot fu-berlin dot de 2006-05-13 23:01 --- The following is also not caught: - subroutine foo(y) character(len=20) :: y y = 'hello world' end program test character(len=10) :: x call foo(x) write(*,*) 'X=',x pause end - NAG's f95 spits out this error: Error: test17.f90: Argument Y (no. 1) in reference to FOO from TEST is too short a character string -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27586
[Bug fortran/27586] Compile-time warn if arguments don't match in terms of precision
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-13 23:05 --- This is really a dup of bug 26227. *** This bug has been marked as a duplicate of 26227 *** -- 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=27586
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-05-13 23:05 --- *** Bug 27586 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug fortran/27587] Warn when Scalar constant passed to array dummy argument
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-13 23:18 --- This is another dup of bug 26227. *** This bug has been marked as a duplicate of 26227 *** -- 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=27587
[Bug fortran/26227] accepts invalid fortran, different dummy types/number
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-05-13 23:18 --- *** Bug 27587 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26227
[Bug fortran/27583] ICE for (invalid) save on automatic object
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-13 23:25 --- *** This bug has been marked as a duplicate of 23091 *** -- 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=27583
[Bug fortran/23091] ICE in gfc_trans_auto_array_allocation
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-05-13 23:25 --- *** Bug 27583 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||tobias dot burnus at physik ||dot fu-berlin dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23091
[Bug libgcj/27024] Implement URLConnection.getFileNameMap
--- Comment #3 from tromey at gcc dot gnu dot org 2006-05-13 23:27 --- Quick note on the status of this -- after the next Classpath import, we should simply remove our copy of URLConnection and also our copy of gnu.java.net.DefaultContentHandlerFactory -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27024
[Bug target/27596] New: [4.2 Regression] build failure on cgwin
http://gcc.gnu.org/ml/gcc/2006-05/msg00297.html http://gcc.gnu.org/ml/gcc-patches/2006-05/msg00500.html -- Summary: [4.2 Regression] build failure on cgwin Product: gcc Version: 4.2.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: pinskia at gcc dot gnu dot org GCC target triplet: i?86-*-cygwin http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27596
[Bug target/27596] [4.2 Regression] build failure on cgwin
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |blocker Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27596
[Bug target/27596] [4.2 Regression] build failure on cgwin
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-05-13 23:31 --- Confirmed on those two emails. -- pinskia 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-05-13 23:31:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27596
[Bug debug/26754] [4.0/4.1/4.2 Regression] Wrong debug info for variable accessed non-locally
--- Comment #4 from patchapp at dberlin dot org 2006-05-14 03:02 --- Subject: Bug number PR debug/26754 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-05/msg00581.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26754
[Bug libgcj/22579] URLClassLoader re-merge plan
--- Comment #2 from tromey at gcc dot gnu dot org 2006-05-14 03:03 --- I have a patch. -- tromey at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tromey at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-07-20 20:42:53 |2006-05-14 03:03:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22579
[Bug target/27596] [4.2 Regression] build failure on cgwin
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-05-14 03:52 --- Fixed by: 2006-05-13 Richard Guenther <[EMAIL PROTECTED]> * config.host : Append i386/x-cygwin to host_xmake_file. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27596
[Bug middle-end/26729] [4.0/4.1 regression] bad bitops folding
--- Comment #17 from sayle at gcc dot gnu dot org 2006-05-14 04:19 --- Subject: Bug 26729 Author: sayle Date: Sun May 14 04:19:32 2006 New Revision: 113755 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=113755 Log: PR middle-end/26729 * fold-const.c (fold_truthop): Check integer_nonzerop instead of !integer_zerop to avoid problems with TREE_OVERFLOW. * gcc.dg/pr26729-1.c: New test case. Added: branches/gcc-4_1-branch/gcc/testsuite/gcc.dg/pr26729-1.c Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/fold-const.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26729
[Bug target/27599] New: [4.2 Regression] build failure on mingw
Bootstrapping GCC fails with MinGW with the following error: make[2]: *** No rule to make target `driver-i386.o', needed by `xgcc.exe'. Stop . This is the same bug as in pr27596, but apparently it needs to be reported and fixed on target by target basis. -- Summary: [4.2 Regression] build failure on mingw Product: gcc Version: 4.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rridge at csclub dot uwaterloo dot ca GCC build triplet: i386-pc-mingw32 GCC host triplet: i386-pc-mingw32 GCC target triplet: i386-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27599
[Bug target/27599] [4.2 Regression] build failure on mingw
--- Comment #1 from rridge at csclub dot uwaterloo dot ca 2006-05-14 06:45 --- Created an attachment (id=11458) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11458&action=view) Suggested patch for fixing the bug on all targets This patch also hardens config.host against similar bugs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27599
[Bug target/27599] [4.2 Regression] build failure on mingw
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Target Milestone|--- |4.2.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27599
