Re: Works on dev-c..
beradero wrote: Hello, It's the code: http://www.nabble.com/file/p16128572/1.c 1.c Try enter the number 0010 (number then), 00010, etc.. and see the bizarre output.. Your code is buggy. This is an obvious string overflow problem. You can't fit a 6 character string into a 4 character array. Jim
[Bug debug/35615] Debug information for .debug_loc section incorrect
--- Comment #11 from wilson at tuliptree dot org 2008-03-20 06:56 --- Subject: Re: Debug information for .debug_loc section incorrect deuling at de dot ibm dot com wrote: --- Comment #6 from deuling at de dot ibm dot com 2008-03-18 16:52 --- ./readelf --debug-dump=line give I get a little different output on the executable you attached to the PR, but the same effective result that the filename is missing. The Directory Table is empty. The File Name Table: Entry Dir TimeSizeName 1 0 0 0 Oh, wait, after I pasted it in here I see that I have a non-printing control character which wasn't obvious earlier. Anyways, I don't see this problem when I compile the file myself. The filename is there in the .s file and in the .o file, and in the executable. So there seems to be something wrong with your setup. You could try tracking down exactly where it fails. Look for a .file 1 tmp.F directive in the .s file. Look at the readelf --debug-dump=line output for the .o file. We already know that it is missing in the executable. Depending on where it first goes missing, this is either a compiler problem, an assembler problem, or a linker problem. As before, I do not see any compiler or binutils problem here. Jim -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
[Bug target/12395] Suboptimal code with global variables
--- Comment #12 from rguenth at gcc dot gnu dot org 2008-03-20 09:28 --- This bug is just a dup of the tree-PRE doesn't work for globals bug (if we have one for that). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12395
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #4 from irar at il dot ibm dot com 2008-03-20 09:30 --- I reproduced the failures with revision 133362 (and without --disable-multilib). Reverting our patch (revision 133134) didn't help, I still see the failures even without it. Ira -- irar at il dot ibm dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-20 09:30:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug ada/35645] ICE in gimplify_expr, at gimplify.c:6120
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-20 09:33 ---
This means there is an unhandled tree in gimplify_expr, which is in this case
probably PLACEHOLDER_EXPR(?):
pak1.t1ip (_init, x1)
{
_init.x1 = (integer) x1;
_init.x2 = PLACEHOLDER_EXPR struct pak1__t1.x1;
goto D.509;
D.509:;
return _init;
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2008-03-20 09:33:00
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35645
[Bug target/35646] gcc is not using the overflow flag
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-20 09:41 --- I believe the backend currently does not model flags in a way that allow the combining with the intermediate store (we might even have a bug about this already). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||uros at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC host triplet|x86_64-unknown-linux-gnu| GCC target triplet|x86_64-unknown-linux-gnu|i?86-*-* x86_64-*-* Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2008-03-20 09:41:34 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35646
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #5 from victork at gcc dot gnu dot org 2008-03-20 09:42 --- I see same failures using compiler boostrapped with vectorization enabled using BOOT_CFLAGS=-g -O2 -ftree-vectorize -maltivec -mabi=altivec Tests fail because some loops were not vectorized: home/victork/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-vfa-03.c:26: note: vect_is_simple_use: operand 2 /home/victork/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-vfa-03.c:26: note: op not supported by target. /home/victork/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-vfa-03.c:26: note: vect_is_simple_use: operand D.2114_11 * 2 /home/victork/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-vfa-03.c:26: note: not ssa-name. /home/victork/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-vfa-03.c:26: note: use not simple. /home/victork/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-vfa-03.c:26: note: not vectorized: relevant stmt not supported: D.2115_12 = D.2114_11 * 2 /home/victork/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-vfa-03.c:26: note: bad operation or unsupported loop bound. /home/victork/mainline/gcc/gcc/testsuite/gcc.dg/vect/vect-vfa-03.c:23: note: vectorized 0 loops in function. In above case vect_is_simple_use() has a problem with constant operand, which is very strange. Looks like a memory overwrite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #34 from ubizjak at gmail dot com 2008-03-20 09:49 --- (In reply to comment #33) Anyway iam glad ffmpeg compiles fine under icc. Me to. Now you will troll in their support lists. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug libfortran/32972] performance of pack/unpack
--- Comment #16 from dominiq at lps dot ens dot fr 2008-03-20 09:54 --- gfortran.dg/internal_pack_3.f90 looks invalid and fails: FAIL: gfortran.dg/internal_pack_3.f90 -O0 (test for excess errors) WARNING: gfortran.dg/internal_pack_3.f90 -O0 compilation failed to produce executable FAIL: gfortran.dg/internal_pack_3.f90 -O1 (test for excess errors) WARNING: gfortran.dg/internal_pack_3.f90 -O1 compilation failed to produce executable FAIL: gfortran.dg/internal_pack_3.f90 -O2 (test for excess errors) WARNING: gfortran.dg/internal_pack_3.f90 -O2 compilation failed to produce executable FAIL: gfortran.dg/internal_pack_3.f90 -O3 -fomit-frame-pointer (test for excess errors) WARNING: gfortran.dg/internal_pack_3.f90 -O3 -fomit-frame-pointer compilation failed to produce executable FAIL: gfortran.dg/internal_pack_3.f90 -O3 -fomit-frame-pointer -funroll-loops (test for excess errors) WARNING: gfortran.dg/internal_pack_3.f90 -O3 -fomit-frame-pointer -funroll-loops compilation failed to produce executable FAIL: gfortran.dg/internal_pack_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions (test for excess errors) WARNING: gfortran.dg/internal_pack_3.f90 -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions compilation failed to produce executable FAIL: gfortran.dg/internal_pack_3.f90 -O3 -g (test for excess errors) WARNING: gfortran.dg/internal_pack_3.f90 -O3 -g compilation failed to produce executable FAIL: gfortran.dg/internal_pack_3.f90 -Os (test for excess errors) WARNING: gfortran.dg/internal_pack_3.f90 -Os compilation failed to produce executable The following changes seem to work: --- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/internal_pack_3.f90 2008-03-19 16:56:40.0 +0100 +++ internal_pack_3_db.f90 2008-03-20 10:46:16.0 +0100 @@ -13,6 +13,7 @@ end program main subroutine sub_ik(i) + integer,parameter :: k = selected_int_kind (range (0_8) + 1) integer(kind=k), dimension(2) :: i if (i(1) /= -1) call abort if (i(2) /= -3) call abort or --- /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/internal_pack_3.f90 2008-03-19 16:56:40.0 +0100 +++ internal_pack_3_db_1.f902008-03-20 10:48:28.0 +0100 @@ -10,12 +10,15 @@ ik = (/ -1, 1, -3 /) call sub_ik(ik(1:3:2)) if (any(ik /= (/ 3, 1, 2 /))) call abort -end program main -subroutine sub_ik(i) - integer(kind=k), dimension(2) :: i - if (i(1) /= -1) call abort - if (i(2) /= -3) call abort - i(1) = 3 - i(2) = 2 -end subroutine sub_ik +contains + + subroutine sub_ik(i) +integer(kind=k), dimension(2) :: i +if (i(1) /= -1) call abort +if (i(2) /= -3) call abort +i(1) = 3 +i(2) = 2 + end subroutine sub_ik + +end program main -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug testsuite/35647] New: FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
The tests gcc.dg/cpp/cmdlne-d(I|M)-M.c fails on (powerpc|i686)-apple-darwin9 with: Executing on host: /opt/gcc/i686-darwin/gcc/xgcc -B/opt/gcc/i686-darwin/gcc/ /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.dg/cpp/cmdlne-dI-M.c -dI -M -fno-show-column -E -o cmdlne-dI-M.i(timeout = 300) PASS: gcc.dg/cpp/cmdlne-dI-M.c (test for excess errors) PASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file-not (^|\\n)#define foo bar($|\\n) PASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file-not variable FAIL: gcc.dg/cpp/cmdlne-dI-M.c scan-file (^|\\n)cmdlne-dI-M.*:[^\\n]*cmdlne-dI-M.c Executing on host: /opt/gcc/i686-darwin/gcc/xgcc -B/opt/gcc/i686-darwin/gcc/ /opt/gcc/gcc-4.4-work/gcc/testsuite/gcc.dg/cpp/cmdlne-dM-M.c -dM -M -fno-show-column -E -o cmdlne-dM-M.i(timeout = 300) PASS: gcc.dg/cpp/cmdlne-dM-M.c (test for excess errors) PASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file (^|\\n)#define foo bar($|\\n) PASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file-not variable FAIL: gcc.dg/cpp/cmdlne-dM-M.c scan-file (^|\\n)cmdlne-dM-M[^\\n]*:[^\\n]*cmdlne-dM-M.c -- Summary: FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35647
[Bug target/35646] gcc is not using the overflow flag
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-03-20 10:09 ---
Ok, usually combine does the transformation, but it doesn't match
(insn 7 4 8 2 t.c:2 (parallel [
(set (reg:SI 58 [ D.1549 ])
(plus:SI (reg/v:SI 60 [ b ])
(mem:SI (reg/v/f:DI 59 [ a ]) [2 S4 A32])))
(clobber (reg:CC 17 flags))
]) 249 {*addsi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 8 7 9 2 t.c:2 (set (mem:SI (reg/v/f:DI 59 [ a ]) [2 S4 A32])
(reg:SI 58 [ D.1549 ])) 47 {*movsi_1} (expr_list:REG_DEAD (reg/v/f:DI
59 [ a ])
(nil)))
(insn 9 8 10 2 t.c:2 (set (reg:CC 17 flags)
(compare:CC (reg/v:SI 60 [ b ])
(reg:SI 58 [ D.1549 ]))) 5 {*cmpsi_1_insn} (expr_list:REG_DEAD
(reg/v:SI 60 [ b ])
(expr_list:REG_DEAD (reg:SI 58 [ D.1549 ])
(nil
because insn 7 has a memory operand which is clobbered inbetween the
comparison and the addition.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35646
[Bug testsuite/35647] FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
--- Comment #1 from hp at gcc dot gnu dot org 2008-03-20 10:17 --- It fails everywhere, due to commit 133342. Author is informed and CC:ed. -- hp at gcc dot gnu dot org changed: What|Removed |Added CC||hp at gcc dot gnu dot org, ||hubicka at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35647
[Bug target/35646] gcc is not using the overflow flag
--- Comment #3 from rguenth at gcc dot gnu dot org 2008-03-20 10:18 ---
It works if you rewrite addto to
void addto(unsigned int *a,unsigned int b) {
if ((*a+b)b) exit(0);
*a+=b;
}
because the store is no longer required in the path to exit(0).
addto:
.LFB3:
subq$8, %rsp
.LCFI0:
movl%esi, %eax
addl(%rdi), %eax
jb .L5
movl%eax, (%rdi)
addq$8, %rsp
ret
.L5:
xorl%edi, %edi
callexit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35646
[Bug target/35646] gcc is not using the overflow flag
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35646
[Bug testsuite/35647] FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
-- hp at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-20 10:19:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35647
[Bug testsuite/35647] FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
--- Comment #2 from hubicka at ucw dot cz 2008-03-20 10:32 --- Subject: Re: FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c It fails everywhere, due to commit 133342. Author is informed and CC:ed. Sorry for all the breakage. There used to be xfail, but since I've removed at least one bug in implementation (-dM was interpretted as both GCC debugging option and preprocesor directive), I've removed the xfail assuming that the problem is fixed. It seems to pass for me: Executing on host: /root/trunk-an/build/gcc/xgcc -B/root/trunk-an/build/gcc/ /root/trunk-an/gcc/testsuite/gcc.dg/cpp/cmdlne-dI-M.c -dI -M -fno-show-column -E -o cmdlne-dI-M.i(timeout = 300) PASS: gcc.dg/cpp/cmdlne-dI-M.c (test for excess errors) PASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file-not (^|\\n)#define foo bar($|\\n) PASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file-not variable PASS: gcc.dg/cpp/cmdlne-dI-M.c scan-file (^|\\n)cmdlne-dI-M.*:[^\\n]*cmdlne-dI-M.c Executing on host: /root/trunk-an/build/gcc/xgcc -B/root/trunk-an/build/gcc/ /root/trunk-an/gcc/testsuite/gcc.dg/cpp/cmdlne-dM-M.c -dM -M -fno-show-column -E -o cmdlne-dM-M.i(timeout = 300) PASS: gcc.dg/cpp/cmdlne-dM-M.c (test for excess errors) PASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file (^|\\n)#define foo bar($|\\n) PASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file-not variable PASS: gcc.dg/cpp/cmdlne-dM-M.c scan-file (^|\\n)cmdlne-dM-M[^\\n]*:[^\\n]*cmdlne-dM-M.c Executing I didn't check, perhaps it was xpassing for me previously too, but why the testcase works for me and fails everywhere else? Reverting the xfail removal is probably proper fix here. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35647
[Bug libfortran/32972] performance of pack/unpack
--- Comment #17 from tkoenig at gcc dot gnu dot org 2008-03-20 10:54 --- Subject: Bug 32972 Author: tkoenig Date: Thu Mar 20 10:54:04 2008 New Revision: 133368 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133368 Log: 2008-03-20 Thomas Koenig [EMAIL PROTECTED] PR libfortran/32972 * gfortran.dg/internal_pack_3.f90: Add missing parameter in subroutine. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/internal_pack_3.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug testsuite/35647] FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
--- Comment #3 from hp at gcc dot gnu dot org 2008-03-20 10:55 --- (In reply to comment #2) Sorry for all the breakage. No worries, it's not a *breakage*. why the testcase works for me and fails everywhere else? I have: cmdlne-dM-M.o: \ /tmp/hpautotest-gcc1/gcc/gcc/testsuite/gcc.dg/cpp/cmdlne-dM-M.c so I'm not sure. Shouldn't that match (^|\\n)cmdlne-dM-M[^\\n]*:[^\\n]*cmdlne-dM-M.c? Is this a case of distribution-having-local-dejagnu-fixes-not-in-pristine-dejagnu-1.4.4 thing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35647
[Bug fortran/35152] Implicit procedure with keyword=argument is accepted
--- Comment #4 from dominiq at lps dot ens dot fr 2008-03-20 11:24 ---
With this revision the following code gives an error:
[ibook-dhum] f90/bug% cat rename_use_1.f90
! { dg-do compile }
module foo_base_mod
type foo_dmt
real(kind(1.d0)), allocatable :: rv(:)
integer, allocatable :: iv1(:), iv2(:)
end type foo_dmt
type foo_zmt
complex(kind(1.d0)), allocatable :: rv(:)
integer, allocatable :: iv1(:), iv2(:)
end type foo_zmt
type foo_cdt
integer, allocatable :: md(:)
integer, allocatable :: hi(:), ei(:)
end type foo_cdt
end module foo_base_mod
module bar_prt
use foo_base_mod, only : foo_dmt, foo_zmt, foo_cdt
type bar_dbprt
type(foo_dmt), allocatable :: av(:)
real(kind(1.d0)), allocatable :: d(:)
type(foo_cdt):: cd
end type bar_dbprt
type bar_dprt
type(bar_dbprt), allocatable :: bpv(:)
end type bar_dprt
type bar_zbprt
type(foo_zmt), allocatable :: av(:)
complex(kind(1.d0)), allocatable :: d(:)
type(foo_cdt):: cd
end type bar_zbprt
type bar_zprt
type(bar_zbprt), allocatable :: bpv(:)
end type bar_zprt
end module bar_prt
module bar_pr_mod
use bar_prt
interface bar_pwrk
subroutine bar_dppwrk(pr,x,y,cd,info,trans,work)
use foo_base_mod
use bar_prt
type(foo_cdt),intent(in):: cd
type(bar_dprt), intent(in) :: pr
real(kind(0.d0)),intent(inout):: x(:), y(:)
integer, intent(out) :: info
character(len=1), optional:: trans
real(kind(0.d0)),intent(inout), optional, target :: work(:)
end subroutine bar_dppwrk
subroutine bar_zppwrk(pr,x,y,cd,info,trans,work)
use foo_base_mod
use bar_prt
type(foo_cdt),intent(in):: cd
type(bar_zprt), intent(in) :: pr
complex(kind(0.d0)),intent(inout) :: x(:), y(:)
integer, intent(out) :: info
character(len=1), optional:: trans
complex(kind(0.d0)),intent(inout), optional, target :: work(:)
end subroutine bar_zppwrk
end interface
end module bar_pr_mod
module foo_pr_mod
use bar_prt,
foo_dbprt = bar_dbprt,
foo_zbprt = bar_zbprt,
foo_dprt = bar_dprt,
foo_zprt = bar_zprt
use bar_pr_mod,
foo_pwrk = bar_pwrk
end module foo_pr_mod
Subroutine foo_sub(a,pr,b,x,eps,cd,info)
use foo_base_mod
use foo_pr_mod
Implicit None
!!$ parameters
Type(foo_dmt), Intent(in) :: a
Type(foo_dprt), Intent(in) :: pr
Type(foo_cdt), Intent(in):: cd
Real(Kind(1.d0)), Intent(in) :: b(:)
Real(Kind(1.d0)), Intent(inout):: x(:)
Real(Kind(1.d0)), Intent(in) :: eps
integer, intent(out) :: info
!!$ Local data
Real(Kind(1.d0)), allocatable, target :: aux(:),wwrk(:,:)
Real(Kind(1.d0)), allocatable :: p(:), f(:)
info = 0
Call bar_pwrk(pr,p,f,cd,info,work=aux)
return
End Subroutine foo_sub
[ibook-dhum] f90/bug% gfc rename_use_1.f90
rename_use_1.f90:114.36:
Call bar_pwrk(pr,p,f,cd,info,work=aux)
1
Error: Keyword argument requires explicit interface for procedure 'bar_pwrk' at
(1)
If 'Call bar_pwrk(pr,p,f,cd,info,work=aux)' is replaced by 'Call
foo_pwrk(pr,p,f,cd,info,work=aux)' the error disappears. Note that I did not
write the code, but only kept it and I don't know if the code is valid or not.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35152
[Bug testsuite/35647] FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
--- Comment #4 from hp at gcc dot gnu dot org 2008-03-20 11:39 --- For the record, related discussion in http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01194.html (somewhat threading-challenged). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35647
[Bug c++/35648] New: -Wall includes -Wwrite-strings
This was changed in response to bug 8586, but the manual still says -Wwrite-strings ... Otherwise, it will just be a nuisance; this is why we did not make -Wall request these warnings. Btw: How do I turn the warnings from write-strings into errors together with -Wall? -- Summary: -Wall includes -Wwrite-strings Product: gcc Version: 4.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: martin at oneiros dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35648
[Bug libfortran/32972] performance of pack/unpack
--- Comment #18 from tkoenig at gcc dot gnu dot org 2008-03-20 11:58 --- (In reply to comment #16) gfortran.dg/internal_pack_3.f90 looks invalid and fails: Again, thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32972
[Bug c/35649] New: Incorrect printf warning: expect double has float
With the -Wformat option The code
void foo( float a )
{
printf(%f,a);
}
give the warning:
foo.c:3: warning: format '%f' expects type 'double', but argument 2 has type
'float'
I believe this is unnecessary because float is promoted to double in variadic
functions.
--
Summary: Incorrect printf warning: expect double has float
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: 6yxwfq202 at sneakemail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
[Bug fortran/35152] Implicit procedure with keyword=argument is accepted
--- Comment #5 from dfranke at gcc dot gnu dot org 2008-03-20 12:15 --- I don't know if the code is valid or not IMO, it is not: module foo_pr_mod use bar_pr_mod, foo_pwrk = bar_pwrk end module foo_pr_mod Subroutine foo_sub(a,pr,b,x,eps,cd,info) use foo_pr_mod ... Call bar_pwrk(pr,p,f,cd,info,work=aux) end subroutine The module renames 'bar_pwrk' to 'foo_pwrk'. When the subroutine uses the module it only sees 'foo_pwrk', not 'bar_pwrk'. Hence, 'bar_pwrk' has an implicit interface within 'foo_sub'. IMO, the warning is correct and the code ahould be fixed :) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35152
[Bug fortran/35152] Implicit procedure with keyword=argument is accepted
--- Comment #6 from burnus at gcc dot gnu dot org 2008-03-20 12:17 --- With this revision the following code gives an error: Call bar_pwrk(pr,p,f,cd,info,work=aux) The error is correct; bar_pwrk is known in module bar_pr_mod, that module is then imported in module foo_pr_mod but under the name foo_pwrk. Subroutine foo_sub now uses the module foo_pr_mod and thus only the symbol foo_pwrk and not bar_pwrk is use associated. Therefore, bar_pwrk has an implicit interface, which per C1225 may not use the keyword= syntax. (All compilers I tried give the same error as gfortran.) (I have to admit that I miss an option to enforce that the name of a non-intrinsic subroutine has to be made available before using PROCEDURE, EXTERNAL, INTERFACE or being use/host associated. Unfortunately, IMPLICIT NONE does not enforce this.) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35152
[Bug fortran/35627] [4.3 regression] namelist read error
-- burnus at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.3.0 4.4.0 |4.3.0 Known to work|4.2.2 4.1.3 |4.2.2 4.1.3 4.4.0 Priority|P3 |P4 Summary|[4.3, 4.4 regression] |[4.3 regression] namelist |namelist read error |read error Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug other/35648] -Wall includes -Wwrite-strings
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-20 12:38 --- -Werror=write-strings should do the trick. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |other Keywords||documentation http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35648
[Bug c/35649] Incorrect printf warning: expect double has float
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-20 12:40 --- Works for me. Which target? Obviously you may need a prototype of printf available for -Wformat to work at all. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
[Bug debug/35615] Debug information for .debug_loc section incorrect
--- Comment #12 from deuling at de dot ibm dot com 2008-03-20 13:01 --- The error disappeared :-) I neither changed the compiler nor anything else in the setup. I just rebuild neg_array and the error is gone. (gdb) br MAIN__ Breakpoint 1 at 0x80485bd: file neg_array.F, line 1. (gdb) I also have a different Directory Table now. With gfortran 4.1.2 the value fortran was seen in Directory Table ?!? (see comment #6) The Directory Table: ../../../gcc-4.3.0/libgfortran /home/deuling/gcc/gcc-4.3.0-build/./gcc/include The File Name Table: Entry Dir TimeSizeName 1 1 0 0 fmain.c 2 1 0 0 libgfortran.h 3 2 0 0 stddef.h This looks correct to me now. I have no idea what was the cause of that errors. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35615
[Bug testsuite/35621] gcc.target/i386/ssse3-*.c violates C/C++ aliasing rules
--- Comment #12 from hjl dot tools at gmail dot com 2008-03-20 13:27 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2008-03/msg01203.html -- hjl dot tools at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hjl dot tools at gmail dot |dot org |com URL||http://gcc.gnu.org/ml/gcc- ||patches/2008- ||03/msg01203.html Status|SUSPENDED |ASSIGNED Last reconfirmed|2008-03-18 20:24:29 |2008-03-20 13:27:41 date|| Summary|gcc.target/i386/ssse3- |gcc.target/i386/ssse3-*.c |psignw.c fails at -O3 |violates C/C++ aliasing |(violates C/C++ aliasing|rules |rules) | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35621
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #6 from jsm28 at gcc dot gnu dot org 2008-03-20 13:29 --- Created an attachment (id=15349) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15349action=view) Gimplification-time patch Changing at build_unary_op time runs into OpenMP problems - the OpenMP code needs the trees to correspond more directly to the increments and decrements in the source code. Changing at gimplification time, as in the attached patch, avoids that problem, but a number of gcc.dg/vect tests regress because of the changes to the code for increment/decrement of types that get promoted. FAIL: gcc.dg/vect/pr18536.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/pr30771.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-iv-8a.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/vect-multitypes-11.c scan-tree-dump-times vect vectorized 1 loops 2 FAIL: gcc.dg/vect/vect-reduc-dot-u16a.c scan-tree-dump-times vect vectorized 1 loops 2 FAIL: gcc.dg/vect/slp-21.c scan-tree-dump-times vect vectorized 1 loops 1 FAIL: gcc.dg/vect/no-scevccp-outer-13.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-14.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-16.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-17.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-19.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-21.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 FAIL: gcc.dg/vect/no-scevccp-outer-7.c scan-tree-dump-times vect OUTER LOOP VECTORIZED. 1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug testsuite/35647] FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
--- Comment #5 from schwab at gcc dot gnu dot org 2008-03-20 13:32 --- Subject: Bug 35647 Author: schwab Date: Thu Mar 20 13:31:25 2008 New Revision: 133373 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133373 Log: PR testsuite/35647 * gcc.dg/cpp/cmdlne-dI-M.c: Match optional continuation. * gcc.dg/cpp/cmdlne-dM-M.c: Likewise. * gcc.dg/cpp/cmdlne-dN-M.c: Match correct file name and optional continuation and remove xfail. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/cpp/cmdlne-dI-M.c trunk/gcc/testsuite/gcc.dg/cpp/cmdlne-dM-M.c trunk/gcc/testsuite/gcc.dg/cpp/cmdlne-dN-M.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35647
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #7 from rguenth at gcc dot gnu dot org 2008-03-20 13:39 ---
Thanks. I guess the vect fallout needs to be dealt with separately. Now, I
think gimplification time is not the best here, can we maybe move this to
general gimplification code if we change the {PRE,POST}{IN,DE}CREMENT_EXPR
to have the type the increment is done in (and the expression result) be
TREE_TYPE of that expression? This way the generic gimplification code
would need to make sure to lower it properly.
Diego, I suppose this lowering is before tuples come into play and we loose
this extra type, right?
Of course this may need auditing of the FEs wrt correctness of the type
in this expression but feels like a more general fix?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dnovillo at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #8 from rguenth at gcc dot gnu dot org 2008-03-20 13:41 --- Now, I think gimplification time is not the best here Now, if we think ... is the best here obviously ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug testsuite/35647] FAIL: gcc.dg/cpp/cmdlne-d(I|M)-M.c scan-file (^|\\n)cmdlne-d(I|M)-M[^\\n]*:[^\\n]*cmdlne-d(I|M)-M.c
--- Comment #6 from schwab at suse dot de 2008-03-20 13:43 --- Fixed. -- schwab at suse dot de changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35647
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #6 from victork at gcc dot gnu dot org 2008-03-20 13:43 --- After some regression hunting, I see that failures of vectorizer testcases started after this patch: r133144 | bonzini | 2008-03-12 17:33:45 +0200 (Wed, 12 Mar 2008) | 14 lines 2008-03-12 Paolo Bonzini [EMAIL PROTECTED] PR tree-opt/35422 * fold-const.c (fold_unary) NOP_EXPR: Distribute a narrowing conversion to the operands of a multiplication. testsuite: 2008-03-12 Paolo Bonzini [EMAIL PROTECTED] PR tree-opt/35422 * gcc.dg/vect/slp-7.c: Change target keywords required for vectorizing third loop. * gcc.target/i386/pr35422.c: New. -- victork at gcc dot gnu dot org changed: What|Removed |Added CC||victork at gcc dot gnu dot ||org, bonzini at gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #1 from danglin at gcc dot gnu dot org 2008-03-20 13:46 --- I see the same failures on i686-apple-darwin9. -- danglin at gcc dot gnu dot org changed: What|Removed |Added CC||danglin at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-20 13:46:25 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #7 from bonzini at gnu dot org 2008-03-20 13:51 --- Indeed my patch exposes additional vectorization abilities (which was unexpected). Kenny, can you run the failing testcase under valgrind? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug target/31110] Problem while compiling gcc for mn10300-elf
--- Comment #3 from mstein dot lists at googlemail dot com 2008-03-20 13:55 --- patch: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg01458.html -- mstein dot lists at googlemail dot com changed: What|Removed |Added CC||law at redhat dot com, nickc ||at redhat dot com Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31110
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-20 13:56 --- Subject: Re: Massive failures of objc on i686-apple-darwin9 Attached .i file. Dave --- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2008-03-20 13:56 --- Created an attachment (id=15350) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15350action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #8 from zadeck at naturalbridge dot com 2008-03-20 13:59 --- Subject: Re: heisenbug in tree vectorizer bonzini at gnu dot org wrote: --- Comment #7 from bonzini at gnu dot org 2008-03-20 13:51 --- Indeed my patch exposes additional vectorization abilities (which was unexpected). Kenny, can you run the failing testcase under valgrind? I did run it under valgrind and found no problems. However, i am a little skeptical about regression hunting for these failures. I have found that they come and go based on small changes to other parts of the compiler, i.e. they are symptomatic of some uninitialized variable problem or a storage overwriting. in particular, with the release that i specified in message 1, the failures were there if the compiler was not bootstrapped and were there if it was bootstrapped. Also, changes that i made to that release in the register allocator, which is far downstream of the tree vectorizer caused the problems to hit for both bootstrapped and not bootstrapped builds. I would suggest that you go roll back to that release mentioned in message 1, where you have exactly the same code base for bootstrapped and non bootstrapped compiler and run the two compilers in parallel until you find the place where they diverge. It could very well be that this may be that this is a problem with someone elses code, but you are the occam's razor first choice. kenny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug tree-optimization/35642] heisenbug in tree vectorizer
--- Comment #9 from bonzini at gnu dot org 2008-03-20 14:07 --- Subject: Re: heisenbug in tree vectorizer I would suggest that you go roll back to that release mentioned in message 1, where you have exactly the same code base for bootstrapped and non bootstrapped compiler and run the two compilers in parallel until you find the place where they diverge. Definitely agreed. Paolo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35642
[Bug objc/35165] Massive failures of objc on i686-apple-darwin9
--- Comment #4 from danglin at gcc dot gnu dot org 2008-03-20 14:12 ---
@interface Protocol : Object
{
@private
char *protocol_name OBJC2_UNAVAILABLE;
struct objc_protocol_list *protocol_list OBJC2_UNAVAILABLE;
struct objc_method_description_list *instance_methods OBJC2_UNAVAILABLE;
struct objc_method_description_list *class_methods OBJC2_UNAVAILABLE;
}
/* Obtaining attributes intrinsic to the protocol */
- (const char *)name OBJC2_UNAVAILABLE;
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35165
[Bug libstdc++/35256] Bad link on http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-03-20 14:21 --- Subject: Bug 35256 Author: bkoz Date: Thu Mar 20 14:20:49 2008 New Revision: 133378 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133378 Log: 2008-03-19 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/35256 * doc/xml/manual/parallel_mode.xml: Correct configuration documentation. * doc/html/manual/bk01pt12ch31s04.html: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html trunk/libstdc++-v3/doc/xml/manual/parallel_mode.xml -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35256
[Bug libstdc++/35256] Bad link on http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html
--- Comment #4 from bkoz at gcc dot gnu dot org 2008-03-20 14:28 --- Subject: Bug 35256 Author: bkoz Date: Thu Mar 20 14:27:34 2008 New Revision: 133379 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133379 Log: 2008-03-19 Benjamin Kosnik [EMAIL PROTECTED] PR libstdc++/35256 * doc/xml/manual/parallel_mode.xml: Correct configuration documentation. * doc/html/manual/bk01pt12ch31s04.html: Regenerate. Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/doc/html/manual/bk01pt12ch31s04.html branches/gcc-4_3-branch/libstdc++-v3/doc/xml/manual/parallel_mode.xml -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35256
[Bug libstdc++/35256] Bad link on http://gcc.gnu.org/onlinedocs/libstdc++/parallel_mode.html
--- Comment #5 from bkoz at gcc dot gnu dot org 2008-03-20 14:29 --- Fixed. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35256
[Bug testsuite/35621] gcc.target/i386/ssse3-*.c violates C/C++ aliasing rules
--- Comment #13 from hjl at gcc dot gnu dot org 2008-03-20 14:41 --- Subject: Bug 35621 Author: hjl Date: Thu Mar 20 14:40:10 2008 New Revision: 133380 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133380 Log: 2008-03-20 H.J. Lu [EMAIL PROTECTED] PR testsuite/35621 * gcc.target/i386/ssse3-pabsb.c: Add -fno-strict-aliasing. * gcc.target/i386/ssse3-pabsd.c: Likewise. * gcc.target/i386/ssse3-pabsw.c: Likewise. * gcc.target/i386/ssse3-palignr.c: Likewise. * gcc.target/i386/ssse3-phaddd.c: Likewise. * gcc.target/i386/ssse3-phaddsw.c: Likewise. * gcc.target/i386/ssse3-phaddw.c: Likewise. * gcc.target/i386/ssse3-phsubd.c: Likewise. * gcc.target/i386/ssse3-phsubsw.c: Likewise. * gcc.target/i386/ssse3-phsubw.c: Likewise. * gcc.target/i386/ssse3-pmaddubsw.c: Likewise. * gcc.target/i386/ssse3-pmulhrsw.c: Likewise. * gcc.target/i386/ssse3-pshufb.c: Likewise. * gcc.target/i386/ssse3-psignb.c: Likewise. * gcc.target/i386/ssse3-psignd.c: Likewise. * gcc.target/i386/ssse3-psignw.c: Likewise. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/i386/ssse3-pabsb.c trunk/gcc/testsuite/gcc.target/i386/ssse3-pabsd.c trunk/gcc/testsuite/gcc.target/i386/ssse3-pabsw.c trunk/gcc/testsuite/gcc.target/i386/ssse3-palignr.c trunk/gcc/testsuite/gcc.target/i386/ssse3-phaddd.c trunk/gcc/testsuite/gcc.target/i386/ssse3-phaddsw.c trunk/gcc/testsuite/gcc.target/i386/ssse3-phaddw.c trunk/gcc/testsuite/gcc.target/i386/ssse3-phsubd.c trunk/gcc/testsuite/gcc.target/i386/ssse3-phsubsw.c trunk/gcc/testsuite/gcc.target/i386/ssse3-phsubw.c trunk/gcc/testsuite/gcc.target/i386/ssse3-pmaddubsw.c trunk/gcc/testsuite/gcc.target/i386/ssse3-pmulhrsw.c trunk/gcc/testsuite/gcc.target/i386/ssse3-pshufb.c trunk/gcc/testsuite/gcc.target/i386/ssse3-psignb.c trunk/gcc/testsuite/gcc.target/i386/ssse3-psignd.c trunk/gcc/testsuite/gcc.target/i386/ssse3-psignw.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35621
[Bug testsuite/35621] gcc.target/i386/ssse3-*.c violates C/C++ aliasing rules
--- Comment #14 from hjl at gcc dot gnu dot org 2008-03-20 14:42 --- Subject: Bug 35621 Author: hjl Date: Thu Mar 20 14:41:51 2008 New Revision: 133381 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133381 Log: 2008-03-20 H.J. Lu [EMAIL PROTECTED] Backport from mainline: 2008-03-20 H.J. Lu [EMAIL PROTECTED] PR testsuite/35621 * gcc.target/i386/ssse3-pabsb.c: Add -fno-strict-aliasing. * gcc.target/i386/ssse3-pabsd.c: Likewise. * gcc.target/i386/ssse3-pabsw.c: Likewise. * gcc.target/i386/ssse3-palignr.c: Likewise. * gcc.target/i386/ssse3-phaddd.c: Likewise. * gcc.target/i386/ssse3-phaddsw.c: Likewise. * gcc.target/i386/ssse3-phaddw.c: Likewise. * gcc.target/i386/ssse3-phsubd.c: Likewise. * gcc.target/i386/ssse3-phsubsw.c: Likewise. * gcc.target/i386/ssse3-phsubw.c: Likewise. * gcc.target/i386/ssse3-pmaddubsw.c: Likewise. * gcc.target/i386/ssse3-pmulhrsw.c: Likewise. * gcc.target/i386/ssse3-pshufb.c: Likewise. * gcc.target/i386/ssse3-psignb.c: Likewise. * gcc.target/i386/ssse3-psignd.c: Likewise. * gcc.target/i386/ssse3-psignw.c: Likewise. Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-pabsb.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-pabsd.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-pabsw.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-palignr.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-phaddd.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-phaddsw.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-phaddw.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-phsubd.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-phsubsw.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-phsubw.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-pmaddubsw.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-pmulhrsw.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-pshufb.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-psignb.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-psignd.c branches/gcc-4_3-branch/gcc/testsuite/gcc.target/i386/ssse3-psignw.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35621
[Bug testsuite/35621] gcc.target/i386/ssse3-*.c violates C/C++ aliasing rules
--- Comment #15 from hjl dot tools at gmail dot com 2008-03-20 14:46 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35621
[Bug fortran/35632] [Regression] stream io broken on FreeBSD due to ftruncate changes.
--- Comment #8 from tkoenig at gcc dot gnu dot org 2008-03-20 14:47 --- (In reply to comment #7) Any chance, you'll revert the offending patch? The patch fixed a wrong-code PR, so by reverting the patch, we would introduce a wrong-code regression. I think it would be better to see what the underlying issue is for FreeBSD, then fix that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35632
[Bug libstdc++/35029] problem with -prefer-pic in comparing stages 2 and 3
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-03-20 15:26 --- Is this an issue in the released 4.3.0, or some temporary glitch? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35029
[Bug c++/35637] tr1::function fails with const member function pointer
--- Comment #1 from pcarlini at suse dot de 2008-03-20 15:42 --- Interestingly, current mainline is not affected. Thus, either the mainline compiler regressed (that is the library is actually buggy and the mainline compiler should reject the code, like the 4_3-branch compiler does), or something should be backported from mainline to the 4_3-branch compiler. In either case, it seems to me the C++ compiler should be checked first, both in mainline and 4_3-branch. -- pcarlini at suse dot de changed: What|Removed |Added Component|libstdc++ |c++ http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug c++/35637] tr1::function fails with const member function pointer
--- Comment #2 from pcarlini at suse dot de 2008-03-20 15:49 --- In mainline, -pedantic-errors is needed. That seems weird to me, maybe Maunel can help here. On the other hand, a problem with library code seems also likely. -- pcarlini at suse dot de changed: What|Removed |Added CC||manu at gcc dot gnu dot org, ||pcarlini at suse dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug c/35649] Incorrect printf warning: expect double has float
--- Comment #2 from 6yxwfq202 at sneakemail dot com 2008-03-20 16:04 --- Target is h8300-elf running on pc-windows or pc-cygwin printf prototype: extern int printf( const char * fmt, ...); -- 6yxwfq202 at sneakemail dot com changed: What|Removed |Added GCC target triplet||h8300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35649
[Bug libstdc++/35597] libstdc++ -ffunction-sections -fdata-sections disabled on AIX
--- Comment #3 from bkoz at gcc dot gnu dot org 2008-03-20 16:16 --- From: http://gcc.gnu.org/ml/gcc-patches/2007-05/msg01135.html 2007-05-17 Benjamin Kosnik [EMAIL PROTECTED] * acinclude.m4 (GLIBCXX_CHECK_COMPILER_FEATURES): Add -g to compile flags, move code to test to global scope. * configure: Regenerate. David says that -ffunction-sections -g works on AIX. Presumably this means that it should also not warn. Question to me is, what is the behavior on cygwin? Does -ffunction-sections -g work? Does it warn? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35597
Your training plans - a new online service can help meet all of your IT training needs.
Dear Colleague, When planning IT training initiatives, remember that ALISON: The Free Global Learning Experience (http://alison.com/go/march/home.html) is now one of the world's leading providers of basic IT skills training online. All courses use high-quality interactive multimedia, are standards or certification-based, and can help learners achieve a credential such as the European or International Computer Driving Licence (ECDL/ICDL). ALISON also provides courses in Touch Typing, Health Safety (10 courses), and Financial Literacy, as well as Psychometric and Business English tests. While any individual can register and learn for free; businesses, schools and other organizations can purchase a low-cost 'ALISON Manager' account. This will allow you to enrol your learners within a monitored ALISON course from which you can generate customizable progress reports ALISON Manager provides you with the tools needed for genuine transparency and accountability within the learning process. Contact me directly for any further information or simply register at http://alison.com/go/march/register.html to take look for yourself. You�ll be amazed at what can actually be provided at no cost! I look forward to welcoming you to our learning community! James -- James Hereward Learner Outreach Team ALISON I have forwarded you this e-mail in the belief that our free learning services via ALISON will be of professional interest to you. If it is not or it is unlikely to be as we expand our free learning portfolio in the future, please let me know by clicking on the following unsubscribe link: http://learn-on-alison.com/u?Z2NjLWJ1Z3NAZ2NjLmdudS5vcmc= This e-mail was sent to [EMAIL PROTECTED] This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. Please contact ALISON at its registered address: Galway Technology Centre, Mervue Business Park, Galway, Ireland. ALISON/Advance Learning. CAPERNAUM LIMITED 383734.
[Bug target/31232] Problem while compiling gcc for xstormy16-elf
--- Comment #1 from mstein dot lists at googlemail dot com 2008-03-20 17:02 --- building xstormy16 now fails in: /home/mstein/combined-trunk/libiberty/cp-demangle.c: In function 'cplus_demangle_type': /home/mstein/combined-trunk/libiberty/cp-demangle.c:2059: internal compiler error: in xstormy16_print_operand_address, at config/stormy16/stormy16.c:1718 -- mstein dot lists at googlemail dot com changed: What|Removed |Added CC||nickc at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31232
[Bug target/14552] compiled trivial vector intrinsic code is inefficient
--- Comment #35 from michaelni at gmx dot at 2008-03-20 17:18 --- Subject: Re: compiled trivial vector intrinsic code is inefficient On Thu, Mar 20, 2008 at 09:49:22AM -, ubizjak at gmail dot com wrote: --- Comment #34 from ubizjak at gmail dot com 2008-03-20 09:49 --- (In reply to comment #33) Anyway iam glad ffmpeg compiles fine under icc. Me to. Now you will troll in their support lists. No, truth be, i dont plan to switch to icc yet. Somehow i do prefer to use free tools. Of course if the gap becomes too big i as well as most others will switch to icc ... Also ffmpeg uses almost entirely asm() instead of intrinsics so this alone is not so much a problem for ffmpeg than it is for others who followed the recommandition of intrinsics are better than asm. About trolling, well i made no attempt to reply politely and diplomatic, no. But solving a problem in some use case by droping support for that use case is kinda extreem. The way i see it is that * Its non trivial to place emms optimally and automatically * there needs to be a emms between mmx code and fpu code The solutions to this would be any one of A. let the programmer place emms like it has been in the past B. dont support mmx at all C. dont support x87 fpu at all D. place emms after every bunch of mmx instructions E. solve a quite non trivial problem and place emms optimally The solution which has been selected apparently is B., why was that choosen? Instead of lets say A.? If i do write SIMD code then i do know that i need an emms on x86. Its trivial for the programmer to place it optimally. [...] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14552
[Bug c/35634] [4.1/4.2/4.3/4.4 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #9 from rguenth at gcc dot gnu dot org 2008-03-20 17:56 --- I did a quick scan and Ada, C++ and C ever build these operations. Also a few backends do (mips, rs6000 and s390). So IMHO changing the semantics of these to /* Nodes for ++ and -- in C. The second arg is how much to increment or decrement by. For a pointer, it would be the size of the object pointed to. The type of the expression specifies the type the increment is performed on and the type of the result. This type does not need to match the type of the first argument, instead that is properly size-/zero-extended before the arithmetic operation. */ DEFTREECODE (PREDECREMENT_EXPR, predecrement_expr, tcc_expression, 2) DEFTREECODE (PREINCREMENT_EXPR, preincrement_expr, tcc_expression, 2) DEFTREECODE (POSTDECREMENT_EXPR, postdecrement_expr, tcc_expression, 2) DEFTREECODE (POSTINCREMENT_EXPR, postincrement_expr, tcc_expression, 2) is reasonable. Note that expansion no longer handles these tree codes, they are expected to only survive until gimplification. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug c++/35650] New: Can't bind ref-to-function through using-decl. in namespace
Consider:
void f();
namespace N { using ::f; }
void h()
{
void ( a)() = f; // ok
void ( b)() = N::f;
// error: invalid initialization of non-const reference of
// type âvoid ()()â from a temporary of type âvoid ()()â
}
Since in h, f and N::f are simply two ways of naming the same function, the
error seems unwarranted to me.
Comeau 4.3.9 accepts the code.
--
Summary: Can't bind ref-to-function through using-decl. in
namespace
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc-bugzilla at contacts dot eelis dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35650
[Bug target/35651] New: gcc 4.3.0 ICE compiling libgcc2.c for target 68HC12
Build fails. Command repeated: [EMAIL PROTECTED] libgcc]$ /usr/src/jsm/hc12/gccout430/./gcc/xgcc -B/usr/src/jsm/hc12/gccout430/./gcc/ -B/usr/src/jsm/hc12/install/m6812-elf/bin/ -B/usr/src/jsm/hc12/install/m6812-elf/lib/ -isystem /usr/src/jsm/hc12/install/m6812-elf/include -isystem /usr/src/jsm/hc12/install/m6812-elf/sys-include -O2 -g -g -O2 -m68hc11 -Os -mrelax -DUSE_GAS -DIN_GCC -Dinhibit_libc -g -DIN_LIBGCC2 -I. -I. -I../../.././gcc -I../../../../gcc-4.3.0/libgcc -I../../../../gcc-4.3.0/libgcc/. -I../../../../gcc-4.3.0/libgcc/../gcc -I../../../../gcc-4.3.0/libgcc/../include -DHAVE_CC_TLS -o _negdi2.o -MT _negdi2.o -MD -MP -MF _negdi2.dep -DL_negdi2 --save-temps -c ../../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c ../../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c: In function __negdi2: ../../../../gcc-4.3.0/libgcc/../gcc/libgcc2.c:80: internal compiler error: Segmentation fault configured as: ../gcc-4.3.0/configure --target=m6812-elf --prefix=/usr/src/jsm/hc12/install --program-prefix=m6812-elf- --enable-languages=c 4.3-20080313 fails in exactly the same place. The following releases build ok with the same configure options: 3.3.6 (with Stephane Carrez patches) 3.4.6 4.0.0 4.2.0 4.2.3 4.2-20080319 I built against binutils-2.18 with equivalent configure options. --save-temps creates output (attached shortly) -- Summary: gcc 4.3.0 ICE compiling libgcc2.c for target 68HC12 Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: major Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jsm at jsm-net dot demon dot co dot uk GCC build triplet: i386-redhat-linux GCC host triplet: i386-redhat-linux GCC target triplet: m6812-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35651
[Bug target/35651] gcc 4.3.0 ICE compiling libgcc2.c for target 68HC12
--- Comment #1 from jsm at jsm-net dot demon dot co dot uk 2008-03-20 18:28 --- Created an attachment (id=15351) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15351action=view) libgcc2.i libgcc2.i : output from -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35651
[Bug target/35651] gcc 4.3.0 ICE compiling libgcc2.c for target 68HC12
--- Comment #2 from jsm at jsm-net dot demon dot co dot uk 2008-03-20 18:28 --- Created an attachment (id=15352) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15352action=view) libgcc2.s libgcc2.s : output from -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35651
[Bug testsuite/34168] runtime tests in gfortran.dg/vect fail for unsupported [non-SSE2] targets
--- Comment #5 from uros at gcc dot gnu dot org 2008-03-20 19:44 --- Subject: Bug 34168 Author: uros Date: Thu Mar 20 19:43:56 2008 New Revision: 133393 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133393 Log: PR testsuite/34168 * lib/target-supports.exp (check_sse2_hw_available): New procedure. * gcc.dg/vect/vect.exp: Set dg-do-what-default to compile if SSE2 hardware is not available. * g++.dg/vect/vect.exp: Update target-dependent overrides to match gcc.dg/vect/vect.exp. * gfortran.dg/vect/vect.exp: Ditto. (check_effective_target_lp64_or_vect_no_align): Remove procedure. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/vect/vect.exp trunk/gcc/testsuite/gcc.dg/vect/vect.exp trunk/gcc/testsuite/gfortran.dg/vect/vect.exp trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34168
[Bug c++/35650] [4.1/4.2/4.3/4.4 Regression] Can't bind ref-to-function through using-decl. in namespace
--- Comment #1 from rguenth at gcc dot gnu dot org 2008-03-20 19:55 --- Confirmed. Fails since 3.4. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||rejects-valid Known to fail||3.4.6 Known to work||3.3.6 Last reconfirmed|-00-00 00:00:00 |2008-03-20 19:55:23 date|| Summary|Can't bind ref-to-function |[4.1/4.2/4.3/4.4 Regression] |through using-decl. in |Can't bind ref-to-function |namespace |through using-decl. in ||namespace Target Milestone|--- |4.1.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35650
[Bug libstdc++/35637] tr1::function fails with const member function pointer
--- Comment #3 from pcarlini at suse dot de 2008-03-20 19:57 --- I'm fixing the library bits. -- pcarlini at suse dot de changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pcarlini at suse dot de |dot org | Status|UNCONFIRMED |ASSIGNED Component|c++ |libstdc++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-20 19:57:31 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] tr1::function fails with const member function pointer
--- Comment #4 from paolo at gcc dot gnu dot org 2008-03-20 20:29 --- Subject: Bug 35637 Author: paolo Date: Thu Mar 20 20:28:54 2008 New Revision: 133395 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133395 Log: 2008-03-20 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/35637 * include/tr1_impl/type_traits (struct __in_array): Add back. (is_function): Use it. * testsuite/tr1/4_metaprogramming/is_function/35637.cc: New. Added: trunk/libstdc++-v3/testsuite/tr1/4_metaprogramming/is_function/35637.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/tr1_impl/type_traits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] tr1::function fails with const member function pointer
--- Comment #5 from paolo at gcc dot gnu dot org 2008-03-20 20:30 --- Subject: Bug 35637 Author: paolo Date: Thu Mar 20 20:29:21 2008 New Revision: 133396 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133396 Log: 2008-03-20 Paolo Carlini [EMAIL PROTECTED] PR libstdc++/35637 * include/tr1_impl/type_traits (struct __in_array): Add back. (is_function): Use it. * testsuite/tr1/4_metaprogramming/is_function/35637.cc: New. Added: branches/gcc-4_3-branch/libstdc++-v3/testsuite/tr1/4_metaprogramming/is_function/35637.cc Modified: branches/gcc-4_3-branch/libstdc++-v3/ChangeLog branches/gcc-4_3-branch/libstdc++-v3/include/tr1_impl/type_traits -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
-- pcarlini at suse dot de changed: What|Removed |Added Target Milestone|--- |4.3.1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug c++/35652] New: Location information incorrect on string bounds warning
The following demonstrates a location error in a string bounds warning message:
$ cat /tmp/c.cc
#include string
int main() {
// blank line padding, could also be code...
//
//
//
//
//
//
//
//
//
std::string s = ;
s += 'x' + y; // bogus
}
$ g++ -O2 -c /tmp/c.cc
/tmp/c.cc: In function 'int main()':
/tmp/c.cc:2: warning: offset outside bounds of constant string
/tmp/c.cc:2: warning: offset outside bounds of constant string
/tmp/c.cc:2: warning: offset outside bounds of constant string
/tmp/c.cc:2: warning: offset outside bounds of constant string
/tmp/c.cc:2: warning: offset outside bounds of constant string
/.../i686-unknown-linux-gnu/include/c++/4.3.0/bits/char_traits.h:262: warning:
offset outside bounds of constant string
/.../i686-unknown-linux-gnu/include/c++/4.3.0/bits/char_traits.h:262: warning:
offset outside bounds of constant string
The erroneous line is line 14, but g++ reports the problem (multiple times) at
line 2 and in an STL header file. The same behavior occurs in g++ 4.2.1,
4.1.1, 4.0.3, and 4.0.2. It does not occur in gcc 3.4.5.
Also, there is no warning emitted with -O0, for some reason.
--
Summary: Location information incorrect on string bounds warning
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: simon_baldwin at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug fortran/34813] ICE on incorrect nested type constructor (fold-const.c (fold_convert):2629)
--- Comment #1 from dfranke at gcc dot gnu dot org 2008-03-20 21:42 --- Simplified testcase: SUBROUTINE kd_tree_init_default() TYPE :: kd_tree_node INTEGER :: dummy END TYPE TYPE :: kd_tree TYPE(kd_tree_node) :: root END TYPE TYPE(kd_tree) :: tree tree = kd_tree(null()) END SUBROUTINE -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Known to fail|4.1.2 4.2.3 4.3.0 |4.1.2 4.2.3 4.3.0 4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34813
[Bug libstdc++/35597] libstdc++ -ffunction-sections -fdata-sections disabled on AIX
--- Comment #4 from brian at dessent dot net 2008-03-20 22:19 ---
Subject: Re: libstdc++ -ffunction-sections -fdata-sections
disabled on AIX
bkoz at gcc dot gnu dot org wrote:
Question to me is, what is the behavior on cygwin? Does -ffunction-sections -g
work? Does it warn?
Yes it warns, and yes this warning needs to die. I see no problem
debugging with -ffunction-sections on Cygwin:
$ cat EOF tc.c
int func1 (int a)
{
return a + 1;
}
int func2 (int a)
{
return a + 1;
}
int func3 (int a)
{
return a + 1;
}
int func4 (int a)
{
return a + 1;
}
int func5 (int a)
{
return a + 1;
}
int func6 (int a)
{
return a + 1;
}
int func7 (int a)
{
return a + 1;
}
int func8 (int a)
{
return a + 1;
}
int main (int argc, char **argv)
{
return func5 (func6 (func7 (func8 (argc *
func4 (func3 (func2 (func1 (argc;
}
EOF
$ gcc -ggdb3 -ffunction-sections -fdata-sections -c tc.c -o tc.o
tc.c:1: warning: -ffunction-sections may affect debugging on some
targets
$ objdump -h tc.o | egrep '\.text'
0 .text 2**4
7 .text$func1 000c 0e8b 2**2
8 .text$func2 000c 0e97 2**2
9 .text$func3 000c 0ea3 2**2
10 .text$func4 000c 0eaf 2**2
11 .text$func5 000c 0ebb 2**2
12 .text$func6 000c 0ec7 2**2
13 .text$func7 000c 0ed3 2**2
14 .text$func8 000c 0edf 2**2
15 .text$main0080 0eeb 2**2
$ gcc tc.o -o tc
$ gdb --quiet tc
(gdb) start
Breakpoint 1 at 0x4013c6: file tc.c, line 43.
[New thread 3064.0xee4]
[New thread 3064.0x19a4]
main (argc=1, argv=0x6aa1a8) at tc.c:43
43 {
(gdb) rbreak func[1-8]
Breakpoint 2 at 0x401343: file tc.c, line 4.
int func1(int);
Breakpoint 3 at 0x40134f: file tc.c, line 9.
int func2(int);
Breakpoint 4 at 0x40135b: file tc.c, line 14.
int func3(int);
Breakpoint 5 at 0x401367: file tc.c, line 19.
int func4(int);
Breakpoint 6 at 0x401373: file tc.c, line 24.
int func5(int);
Breakpoint 7 at 0x40137f: file tc.c, line 29.
int func6(int);
Breakpoint 8 at 0x40138b: file tc.c, line 34.
int func7(int);
Breakpoint 9 at 0x401397: file tc.c, line 39.
int func8(int);
(gdb) disp/i $pc
(gdb) c
Breakpoint 9, func8 (a=1) at tc.c:39
39return a + 1;
1: x/i $pc
0x401397 func8+3: mov0x8(%ebp),%eax
(gdb)
Breakpoint 8, func7 (a=2) at tc.c:34
34return a + 1;
1: x/i $pc
0x40138b func7+3: mov0x8(%ebp),%eax
(gdb)
Breakpoint 7, func6 (a=3) at tc.c:29
29return a + 1;
1: x/i $pc
0x40137f func6+3: mov0x8(%ebp),%eax
(gdb)
Breakpoint 6, func5 (a=4) at tc.c:24
24return a + 1;
1: x/i $pc
0x401373 func5+3: mov0x8(%ebp),%eax
(gdb)
Breakpoint 2, func1 (a=1) at tc.c:4
4 return a + 1;
1: x/i $pc
0x401343 func1+3: mov0x8(%ebp),%eax
(gdb)
Breakpoint 3, func2 (a=2) at tc.c:9
9 return a + 1;
1: x/i $pc
0x40134f func2+3: mov0x8(%ebp),%eax
(gdb)
Breakpoint 4, func3 (a=3) at tc.c:14
14return a + 1;
1: x/i $pc
0x40135b func3+3: mov0x8(%ebp),%eax
(gdb)
Breakpoint 5, func4 (a=4) at tc.c:19
19return a + 1;
1: x/i $pc
0x401367 func4+3: mov0x8(%ebp),%eax
(gdb)
Program exited with code 014400.
(gdb) quit
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35597
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
--- Comment #6 from manu at gcc dot gnu dot org 2008-03-20 23:26 --- (In reply to comment #2) In mainline, -pedantic-errors is needed. That seems weird to me, maybe Maunel can help here. On the other hand, a problem with library code seems also likely. Why is it weird to need pedantic-errors to get an error for a pedantic warning? According to the comments in the code this is well-formed although it still requires a diagnostic. /* This was an error in C++98 (cv-qualifiers cannot be added to a function type), but DR 295 makes the code well-formed by dropping the extra qualifiers. */ Again, from GCC 4.4 on, -pedantic/-pedantic-errors should work the same as for the C front-end, that is, -pedantic enables warnings, -pedantic-errors converts those warnings into errors. What is the problem then? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
--- Comment #7 from pcarlini at suse dot de 2008-03-20 23:49 --- (In reply to comment #6) Again, from GCC 4.4 on, -pedantic/-pedantic-errors should work the same as for the C front-end, that is, -pedantic enables warnings, -pedantic-errors converts those warnings into errors. What is the problem then? The problem I was noticing was simply that the behavior of 4_3 was not the same as the behavior of 4_4: the former, as noticed by submitter, errors with -pedantic, the latter errors with -pedantic-errors. You are explaining that this is really the behavior we want, Ok with me! -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
--- Comment #8 from manu at gcc dot gnu dot org 2008-03-20 23:54 --- OK. I see now what the problem is: -pedantic nothing, -pedantic-errors gives an error. The pedantic warning is in a system header, so it doesn't get emitted. When using -pedantic-errors, it is an error, so it gets through. This is an issue also for the C front-end that nobody noticed until now. The problem is in diagnostics.c (diagnostic_report_diagnostic) which tests for DK_WARNING whether they are inhibited by -w or within system headers, while pedwarn() is passing a DK_ERROR when -pedantic-errors is enabled. In my opinion, neither should give diagnostics for system headers unless requested (so I would add -Wsystem-headers to your testcases). The fix is that pedwarn() always passes a DK_WARNING type, while -pedantic-errors reclassifies -pedantic warnings to emit errors. In other words, -pedantic-errors would behave internally like -Werror=pedantic. I don't have time to work on this (or anything else in GCC) at the moment but I will keep it in my TODO list. Again, I would recommend adding -Wsystem-headers to your testcases to get diagnostics about system headers. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
--- Comment #9 from manu at gcc dot gnu dot org 2008-03-20 23:56 --- Reopened. There is a bug here. The only difference between -pedantic and -pedantic-errors should be the type of diagnostic, not the amount. This bug was latent in diagnostics.c. Probably not a regression. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug libstdc++/35637] [4.3 Regression] tr1::function fails with const member function pointer
--- Comment #10 from pcarlini at suse dot de 2008-03-21 00:01 --- Thanks. Note, I cannot really use -Wsystem-headers in library testcases, because in that way other, completely, unrelated warnings are always triggered. I think we should not do much more at this stage for 4_3-branch (in particular in the library side), for 4_4 certainly there are many options. If the present issue gets fixed we can for instance revert completely the library change, testcase included. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35637
[Bug fortran/35632] [Regression] stream io broken on FreeBSD due to ftruncate changes.
--- Comment #9 from kargl at gcc dot gnu dot org 2008-03-21 00:16 --- (In reply to comment #8) (In reply to comment #7) Any chance, you'll revert the offending patch? The patch fixed a wrong-code PR, so by reverting the patch, we would introduce a wrong-code regression. I think it would be better to see what the underlying issue is for FreeBSD, then fix that. Your first sentence is also illogical. gfortran 4.2 and 4.3 work fine on FreeBSD. This patch breaks gfortran on FreeBSD. It is therefore a regression. The patch should be reverted and the wrong-code PR re-opened. You can't have a regression within trunk. If I understood Jerry correctly on IRC, the committed code actually addresses 3 independent issues, which makes it rather hard for me to undo only portions of what was committed because I don't know which parts address which problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35632
[Bug fortran/35632] [Regression] stream io broken on FreeBSD due to ftruncate changes.
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-03-21 00:41 --- I have been working with Steve on IRC in the evenings when we can. We are attempting to isolate this issue. Stay tuned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35632
[Bug fortran/35617] [4.3 Regression] read namelist error
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2008-03-21 01:30 --- Subject: Bug 35617 Author: jvdelisle Date: Fri Mar 21 01:29:30 2008 New Revision: 133411 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133411 Log: 2008-03-20 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/35627 Backport from trunk. * io/list_read.c (free_line): Clear the line buffer enable flag and reset the index into line_buffer, aka item_count. (next_char): Cleanup whitespace. (read_logical): Use unget_char to assure that the first character of the bad logical is saved in case it is part of an object name. Remove the clearing of index and flag that is now in free_line. (read_real): Likewise. PR libfortran/35617 Backport from trunk. * io/list_read.c (eat_separator): If next character after eatline is '!' then eatline again. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35617
[Bug fortran/35627] [4.3 regression] namelist read error
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2008-03-21 01:30 --- Subject: Bug 35627 Author: jvdelisle Date: Fri Mar 21 01:29:30 2008 New Revision: 133411 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133411 Log: 2008-03-20 Jerry DeLisle [EMAIL PROTECTED] PR libfortran/35627 Backport from trunk. * io/list_read.c (free_line): Clear the line buffer enable flag and reset the index into line_buffer, aka item_count. (next_char): Cleanup whitespace. (read_logical): Use unget_char to assure that the first character of the bad logical is saved in case it is part of an object name. Remove the clearing of index and flag that is now in free_line. (read_real): Likewise. PR libfortran/35617 Backport from trunk. * io/list_read.c (eat_separator): If next character after eatline is '!' then eatline again. Modified: branches/gcc-4_3-branch/libgfortran/ChangeLog branches/gcc-4_3-branch/libgfortran/io/list_read.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug fortran/35617] [4.3 Regression] read namelist error
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2008-03-21 01:38 --- Subject: Bug 35617 Author: jvdelisle Date: Fri Mar 21 01:37:38 2008 New Revision: 133413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133413 Log: 2008-03-20 Jerry DeLisle [EMAIL PROTECTED] Backport from trunk: PR libfortran/35627 * gfortran.dg/namelist_46.f90: New test. PR libfortran/35617 * gfortran.dg/namelist_45.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_45.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35617
[Bug fortran/35627] [4.3 regression] namelist read error
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2008-03-21 01:38 --- Subject: Bug 35627 Author: jvdelisle Date: Fri Mar 21 01:37:38 2008 New Revision: 133413 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=133413 Log: 2008-03-20 Jerry DeLisle [EMAIL PROTECTED] Backport from trunk: PR libfortran/35627 * gfortran.dg/namelist_46.f90: New test. PR libfortran/35617 * gfortran.dg/namelist_45.f90: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gfortran.dg/namelist_45.f90 Modified: branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
[Bug fortran/35617] [4.3 Regression] read namelist error
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-03-21 03:10 --- Fixed on 4.3 -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35617
[Bug fortran/35627] [4.3 regression] namelist read error
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2008-03-21 03:13 --- I typoed the file name on the commit of namelist_46.f90, but it is there. Fixed on 4.3. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35627
