[Bug tree-optimization/29925] Wrong code with -ftree-vectorize
--- Comment #9 from patchapp at dberlin dot org 2007-03-05 08:01 --- Subject: Bug number PR tree-optimization/29925 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00254.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29925
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #36 from michael dot klein at fazi dot de 2007-03-05 08:43 --- Subject: Re: Discarded Linkonce sections in .rodata >> One possible workaround is to reorder the objects during link, so that those >> with .gnu.linkonce.r.* come first. >> >> If this a compiler or a linker bug? (I'd blame the linker ;)) > > It is most likely a Solaris specific compiler bug. Erm, this bug was originally reported for i686-pc-linux-gnu, and none of the 33 previous comments refers to Solaris. Forgot to mention that the bug exhibits only with GNU ld, Solaris ld links fine without object reordering or other tricks. /Michael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug tree-optimization/31040] New: unroll/peel loops not aggressive enough
Looking at the asm for the program below, there plenty of loops left after compiling with > gfortran -S -march=native -O3 -funroll-loops -funroll-all-loops -fpeel-loops > test.f90 or any combination of these options. A full unrolling (and in that case a return of the value 3) would be possible and much faster. > cat test.f90 INTEGER FUNCTION lxy() lxy=0 DO lxa=0,1 DO lxb=0,0 DO lya=0,1-lxa DO lyb=0,0-lxb lxy=lxy+1 ENDDO ENDDO ENDDO ENDDO END FUNCTION write(6,*) lxy() END -- Summary: unroll/peel loops not aggressive enough Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
--- Comment #5 from bonzini at gnu dot org 2007-03-05 09:17 --- On 4.3, it is still there at -O1 -- bonzini at gnu dot org changed: What|Removed |Added Known to fail||4.2.0 4.3.0 Known to work||4.1.2 Summary|[4.2 regression] asm operand|[4.2/4.3 regression] asm |has impossible constraints. |operand has impossible ||constraints. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug inline-asm/30505] [4.2/4.3 regression] asm operand has impossible constraints.
-- bonzini at gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-05 09:18:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30505
[Bug fortran/29441] [4.1/4.2 only] non-constant parameter (constant) accepted
--- Comment #10 from burnus at gcc dot gnu dot org 2007-03-05 09:29 --- (In reply to comment #9) Tobias Schlüter wrote: > Fixed on all release branches. This sounds as if should have been marked as FIXED. Did so. Please reopen if it should not have been closed. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug tree-optimization/24309] [4.1/4.2/4.3 Regression] ICE with -O3 -ftree-loop-linear
--- Comment #15 from irar at il dot ibm dot com 2007-03-05 09:30 --- I tried the reduced testcase on powerpc with -ftree-loop-linear and both -O2 and -O3 on 4.1, 4.2 and 4.3, and it works fine. Ira -- irar at il dot ibm dot com changed: What|Removed |Added CC||irar at il dot ibm dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24309
[Bug tree-optimization/29922] [4.3 Regression] [Linux] ICE in insert_into_preds_of_block
--- Comment #19 from tbm at cyrius dot com 2007-03-05 10:13 --- > I will try to get back to this bug this week. I was fighting some > other fights last week, i apologize. Danny, any update on this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29922
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-05 10:18 --- We don't unroll non-innermost loops at the moment. I don't know if sccp can be taught to handle this case (and if it's worth it). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org, rakdver at gcc dot gnu ||dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||missed-optimization Last reconfirmed|-00-00 00:00:00 |2007-03-05 10:18:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug tree-optimization/21463] min/max and references
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21463
[Bug c/31041] New: ice for legal code with -O2 -ftree-vectorize
I just tried to compile a Suse Linux package
with the GNU C++ compiler version 4.3 snapshot 20070302.
The compiler said
utrie.c: In function 'utrie_open_3_4':
utrie.c:51: error: invalid operand to binary operator
(int) j_93;
utrie.c:51: error: incorrect sharing of tree nodes
vect_cst_.1224_132 = {(int) j_93, stmp_var_.1221_129, stmp_var_.1222_130,
stmp_var_.1223_131};
(int) j_93;
utrie.c:51: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
Preprocessed source code attached. Flags -O2 -ftree-vectorize required.
--
Summary: ice for legal code with -O2 -ftree-vectorize
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug c/31041] ice for legal code with -O2 -ftree-vectorize
--- Comment #1 from dcb314 at hotmail dot com 2007-03-05 10:50 --- Created an attachment (id=13144) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13144&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug tree-optimization/26420] -ftree-vectorizer-verbose=1 prints unvectorized loops information
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-05 10:57 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26420
[Bug tree-optimization/26420] -ftree-vectorizer-verbose=1 prints unvectorized loops information
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-05 10:57 --- Subject: Bug 26420 Author: rguenth Date: Mon Mar 5 10:57:09 2007 New Revision: 122544 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122544 Log: 2007-03-05 Richard Guenther <[EMAIL PROTECTED]> Dorit Nuzman <[EMAIL PROTECTED]> PR tree-optimization/26420 * tree-vectorizer.c (vectorize_loops): Bail out early if there are no loops in the function. Only print the number of vectorized loops if it is greater than zero or we are supposed to print information about unvectorized loops. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vectorizer.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26420
[Bug target/30961] [4.2 regression] redundant reg/mem stores/moves
--- Comment #1 from pluto at agmk dot net 2007-03-05 11:11 --- 3.4.6 generates a nice code: _Z7convertj: movl%edi, -4(%rsp) movss -4(%rsp), %xmm0 ret _Z4loadPv: movzwl (%rdi), %eax ret -- pluto at agmk dot net changed: What|Removed |Added Known to fail||4.2.0 Known to work||3.4.6 Summary|redundant reg/mem |[4.2 regression] redundant |stores/moves|reg/mem stores/moves http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30961
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #2 from jv244 at cam dot ac dot uk 2007-03-05 11:47 --- (In reply to comment #1) > We don't unroll non-innermost loops at the moment. I don't know if sccp can > be taught to handle this case (and if it's worth it). such small loops are quite typical for some quantum chemistry integral routines. I'm just experimenting rewriting the kernel mentioned in PR 31021. If I do this unrolling by hand I get quite a speedup on the full kernel: hand unrolled: # best time5.260329 loops: # best time6.616413 which is quite impressive because these loops take at most 30% of the kernel total time: The actual code in question is: coef(:,:)=0.0_wp lxy=0 ; lx=0 DO lxa=0,1 DO lxb=0,1 lx = lx + 1 g1=0.0_wp g2=0.0_wp g1k=0.0_wp g2k=0.0_wp DO lya=0,1-lxa DO lyb=0,1-lxb lxy=lxy+1 g1=g1+pyx(1,lxy)*dpy(lyb,lya,jg) g2=g2+pyx(1,lxy)*dpy(lyb,lya,jg2) g1k=g1k+pyx(2,lxy)*dpy(lyb,lya,jg) g2k=g2k+pyx(2,lxy)*dpy(lyb,lya,jg2) ENDDO ENDDO DO icoef=1,3 coef(icoef,1)=coef(icoef,1)+alpha(icoef,lx)*g1 coef(icoef,2)=coef(icoef,2)+alpha(icoef,lx)*g2 coef(icoef,3)=coef(icoef,3)+alpha(icoef,lx)*g1k coef(icoef,4)=coef(icoef,4)+alpha(icoef,lx)*g2k ENDDO ENDDO ENDDO and the hand-unrolling just explicitly expands all loops to the loop free version of exactly the same statements: coef(:,:)=0.0_wp g1=0.0_wp g2=0.0_wp g1k=0.0_wp g2k=0.0_wp g1=g1+pyx(1,1)*dpy(0,0,jg) g2=g2+pyx(1,1)*dpy(0,0,jg2) g1k=g1k+pyx(2,1)*dpy(0,0,jg) g2k=g2k+pyx(2,1)*dpy(0,0,jg2) g1=g1+pyx(1,2)*dpy(1,0,jg) g2=g2+pyx(1,2)*dpy(1,0,jg2) g1k=g1k+pyx(2,2)*dpy(1,0,jg) g2k=g2k+pyx(2,2)*dpy(1,0,jg2) g1=g1+pyx(1,3)*dpy(0,1,jg) g2=g2+pyx(1,3)*dpy(0,1,jg2) g1k=g1k+pyx(2,3)*dpy(0,1,jg) g2k=g2k+pyx(2,3)*dpy(0,1,jg2) g1=g1+pyx(1,4)*dpy(1,1,jg) g2=g2+pyx(1,4)*dpy(1,1,jg2) g1k=g1k+pyx(2,4)*dpy(1,1,jg) g2k=g2k+pyx(2,4)*dpy(1,1,jg2) coef(01,01)=coef(01,01)+alpha(1,1)*g1 coef(01,02)=coef(01,02)+alpha(1,1)*g2 coef(01,03)=coef(01,03)+alpha(1,1)*g1k coef(01,04)=coef(01,04)+alpha(1,1)*g2k coef(02,01)=coef(02,01)+alpha(2,1)*g1 coef(02,02)=coef(02,02)+alpha(2,1)*g2 coef(02,03)=coef(02,03)+alpha(2,1)*g1k coef(02,04)=coef(02,04)+alpha(2,1)*g2k coef(03,01)=coef(03,01)+alpha(3,1)*g1 coef(03,02)=coef(03,02)+alpha(3,1)*g2 coef(03,03)=coef(03,03)+alpha(3,1)*g1k coef(03,04)=coef(03,04)+alpha(3,1)*g2k g1=0.0_wp g2=0.0_wp g1k=0.0_wp g2k=0.0_wp g1=g1+pyx(1,5)*dpy(0,0,jg) g2=g2+pyx(1,5)*dpy(0,0,jg2) g1k=g1k+pyx(2,5)*dpy(0,0,jg) g2k=g2k+pyx(2,5)*dpy(0,0,jg2) g1=g1+pyx(1,6)*dpy(0,1,jg) g2=g2+pyx(1,6)*dpy(0,1,jg2) g1k=g1k+pyx(2,6)*dpy(0,1,jg) g2k=g2k+pyx(2,6)*dpy(0,1,jg2) coef(01,01)=coef(01,01)+alpha(1,2)*g1 coef(01,02)=coef(01,02)+alpha(1,2)*g2 coef(01,03)=coef(01,03)+alpha(1,2)*g1k coef(01,04)=coef(01,04)+alpha(1,2)*g2k coef(02,01)=coef(02,01)+alpha(2,2)*g1 coef(02,02)=coef(02,02)+alpha(2,2)*g2 coef(02,03)=coef(02,03)+alpha(2,2)*g1k coef(02,04)=coef(02,04)+alpha(2,2)*g2k coef(03,01)=coef(03,01)+alpha(3,2)*g1 coef(03,02)=coef(03,02)+alpha(3,2)*g2 coef(03,03)=coef(03,03)+alpha(3,2)*g1k coef(03,04)=coef(03,04)+alpha(3,2)*g2k g1=0.0_wp g2=0.0_wp g1k=0.0_wp g2k=0.0_wp g1=g1+pyx(1,7)*dpy(0,0,jg) g2=g2+pyx(1,7)*dpy(0,0,jg2) g1k=g1k+pyx(2,7)*dpy(0,0,jg) g2k=g2k+pyx(2,7)*dpy(0,0,jg2) g1=g1+pyx(1,8)*dpy(1,0,jg) g2=g2+pyx(1,8)*dpy(1,0,jg2) g1k=g1k+pyx(2,8)*dpy(1,0,jg) g2k=g2k+pyx(2,8)*dpy(1,0,jg2) coef(01,01)=coef(01,01)+alpha(1,3)*g1 coef(01,02)=coef(01,02)+alpha
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #3 from rakdver at atrey dot karlin dot mff dot cuni dot cz 2007-03-05 11:49 --- Subject: Re: unroll/peel loops not aggressive enough > We don't unroll non-innermost loops at the moment. I don't know if sccp can > be taught to handle this case (and if it's worth it). It is fairly easy to make gcc completely unroll non-innermost loops, I am working on that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug tree-optimization/31040] unroll/peel loops not aggressive enough
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-05 12:22 --- Note that in addition to unrolling the outermost loop you can experiment with adjusting the --param max-completely-peeled-insns param. Also I wonder if DO lxb=0,0 is really common (if so, the frontend might want to lower this differently). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31040
[Bug c++/31042] New: Instantiation with const pointer to member
Dear all,
I would like to post a bug report for the GNU C/C++ compiler 3.3-e500.
We use the compiler to generate code for a PowerPC processor.
Used invokation line for the GNU C++ compiler:
ccppc -c -x c++ -ansi -Wall -Werror -mcpu=8540 -fverbose-asm -mbig
-fmerge-templates -mmultiple -mno-string -mstrict-align -O3
-fno-exceptions -fno-rtti -fno-builtin-printf
-I
-D
X.CPP -oX.O
// file X.CPP
class X;
template
int X::** f1 () { return static_cast(0); }
int X::** f2 () { return f1(); }
The compiler gives the following error messages:
X.CPP: In function `int X::** f1() [with T_ = int X::*]':
X.CPP:6: instantiated from here
X.CPP:4: error: invalid conversion from `int X::**' to `int X::**'
BTW, function f1 is instantiated with 'T_ = int X::* const'
and not with 'T_ = int X::*'.
Kind regards
W. Roehrl
--
Summary: Instantiation with const pointer to member
Product: gcc
Version: 3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wolfgang dot roehrl at gi-de dot com
GCC build triplet: sparc-sun-solaris2.5.1
GCC host triplet: i386-pc-mingw32
GCC target triplet: powerpc-wrs-vxworks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31042
[Bug fortran/30968] [4.1, 4.2 only] Bogus warning with continued lines of concatenated strings
--- Comment #5 from burnus at gcc dot gnu dot org 2007-03-05 12:58 --- Subject: Bug 30968 Author: burnus Date: Mon Mar 5 12:58:14 2007 New Revision: 122547 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122547 Log: 2007-03-05 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30968 * primary.c (next_string_char): Correct reading a character after the delimiter. (match_string_constant): Print warning message only once. 2007-03-05 Tobias Burnus <[EMAIL PROTECTED]> PR fortran/30968 * gfortran.dg/continuation_7.f90: New test. Added: branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/continuation_7.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/primary.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug fortran/30968] [4.1 only] Bogus warning with continued lines of concatenated strings
--- Comment #6 from burnus at gcc dot gnu dot org 2007-03-05 12:59 --- Fixed in 4.2 (and 4.3). I don't think it is worth to porting to 4.1. -> close bug. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Summary|[4.1, 4.2 only] Bogus |[4.1 only] Bogus warning |warning with continued lines|with continued lines of |of concatenated strings |concatenated strings http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30968
[Bug c/31041] ice for legal code with -O2 -ftree-vectorize
--- Comment #2 from tbm at cyrius dot com 2007-03-05 13:09 ---
Reduced testcase:
typedef int int32_t;
struct UNewTrie
{
int32_t index[(0x11 >> 1)];
};
typedef struct UNewTrie UNewTrie;
utrie_open_3_4 ()
{
UNewTrie *trie;
int32_t i, j;
{
i = 0;
do
{
trie->index[i++] = j;
j += 1;
}
while (i < 5);
}
}
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug c/31041] [4.3 Regression] ice (verify_stmts failed: invalid operand to binary operator) with -O2 -ftree-vectorize
--- Comment #3 from tbm at gcc dot gnu dot org 2007-03-05 13:11 --- confirmed with GCC 4.3.0 20070303. 4.2.0 works. -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||ice-on-valid-code Known to work||4.2.0 Last reconfirmed|-00-00 00:00:00 |2007-03-05 13:11:16 date|| Summary|ice for legal code with -O2 |[4.3 Regression] ice |-ftree-vectorize|(verify_stmts failed: ||invalid operand to binary ||operator) with -O2 -ftree- ||vectorize Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug fortran/29441] [4.1/4.2 only] non-constant parameter (constant) accepted
--- Comment #11 from tobi at gcc dot gnu dot org 2007-03-05 13:14 --- Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29441
[Bug middle-end/30364] [4.1/4.2 Regression] Wrong variable ranges due to constant folding
--- Comment #13 from rguenth at gcc dot gnu dot org 2007-03-05 13:15 --- Subject: Bug 30364 Author: rguenth Date: Mon Mar 5 13:15:25 2007 New Revision: 122548 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122548 Log: 2007-03-05 Richard Guenther <[EMAIL PROTECTED]> Backport from mainline: 2007-02-28 Richard Guenther <[EMAIL PROTECTED]> PR middle-end/30364 * fold-const.c (fold_binary): Do not associate expressions with more than one variable for integer types that do not wrap. * gcc.dg/torture/pr30364-1.c: New testcase. * gcc.dg/torture/pr30364-2.c: Likewise. * gcc.dg/torture/pr30364-3.c: Likewise. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-1.c - copied unchanged from r122414, trunk/gcc/testsuite/gcc.dg/torture/pr30364-1.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-2.c - copied unchanged from r122414, trunk/gcc/testsuite/gcc.dg/torture/pr30364-2.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/torture/pr30364-3.c - copied unchanged from r122414, trunk/gcc/testsuite/gcc.dg/torture/pr30364-3.c Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/fold-const.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug middle-end/30364] [4.1 Regression] Wrong variable ranges due to constant folding
--- Comment #14 from rguenth at gcc dot gnu dot org 2007-03-05 13:16 --- And the 4.2 branch. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.1.2 Summary|[4.1/4.2 Regression] Wrong |[4.1 Regression] Wrong |variable ranges due to |variable ranges due to |constant folding|constant folding http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30364
[Bug c++/31042] Instantiation with const pointer to member
--- Comment #1 from rguenth at gcc dot gnu dot org 2007-03-05 13:27 ---
Your code is invalid. Valid is
class X;
template
int X::* const * f1 () { return static_cast(0); }
int X::* const * f2 () { return f1(); }
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31042
[Bug libstdc++/30675] [4.2/4.3 Regression] libstdc++ testsuite hardcodes "ar" and "ranlib"
--- Comment #2 from jsm28 at gcc dot gnu dot org 2007-03-05 13:41 --- Working on a fix. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jsm28 at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-05 13:41:26 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30675
[Bug c/31041] [4.3 Regression] verify_stmts failed: invalid operand to binary operator with -O2 -ftree-vectorize
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-05 13:46 ---
Two times invalid gimple:
:;
stmp_var_.41_63 = (int) j_34 + 1;
stmp_var_.42_64 = stmp_var_.41_63 + 1;
stmp_var_.43_65 = stmp_var_.42_64 + 1;
vect_cst_.44_66 = {(int) j_34, stmp_var_.41_63, stmp_var_.42_64,
stmp_var_.43_65};
in tree-vect-transform.c:get_initial_def_for_induction we fail to gimplify
the init_expr.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
CC||dorit at il dot ibm dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug c++/31042] Misleading error message with instantiation with const pointer to member
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-05 14:10 --- Reopen ... -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Keywords||diagnostic Resolution|INVALID | Summary|Instantiation with const|Misleading error message |pointer to member |with instantiation with ||const pointer to member http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31042
[Bug c++/31042] Misleading error message with instantiation with const pointer to member
--- Comment #3 from rguenth at gcc dot gnu dot org 2007-03-05 14:10 --- ... to mark as fixed in 3.4.0. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |3.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31042
gcc-bugs@gcc.gnu.org
--- Comment #5 from paolo at gcc dot gnu dot org 2007-03-05 14:12 --- Subject: Bug 31031 Author: paolo Date: Mon Mar 5 14:12:29 2007 New Revision: 122549 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122549 Log: 2007-03-05 Paolo Carlini <[EMAIL PROTECTED]> PR libstdc++/31031 * include/bits/istream.tcc: Inhibit implicit instantiation of the _M_insert helpers. * include/bits/ostream.tcc: Likewise for _M_extract. * testsuite/27_io/basic_ostream/inserters_arithmetic/char/ 31031.cc: New. * testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/ 31031.cc: Likewise. Added: branches/gcc-4_2-branch/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/char/31031.cc branches/gcc-4_2-branch/libstdc++-v3/testsuite/27_io/basic_ostream/inserters_arithmetic/wchar_t/31031.cc Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/include/bits/istream.tcc branches/gcc-4_2-branch/libstdc++-v3/include/bits/ostream.tcc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
gcc-bugs@gcc.gnu.org
--- Comment #6 from pcarlini at suse dot de 2007-03-05 14:13 --- Fixed for 4.2.0. -- pcarlini at suse dot de changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31031
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #37 from hjl at lucon dot org 2007-03-05 14:19 --- (In reply to comment #36) > Subject: Re: Discarded Linkonce sections in .rodata > > >> One possible workaround is to reorder the objects during link, so that > >> those > >> with .gnu.linkonce.r.* come first. > >> > >> If this a compiler or a linker bug? (I'd blame the linker ;)) > > > > It is most likely a Solaris specific compiler bug. > > Erm, this bug was originally reported for i686-pc-linux-gnu, and none of > the 33 previous comments refers to Solaris. > > Forgot to mention that the bug exhibits only with GNU ld, > Solaris ld links fine without object reordering or other tricks. > > /Michael > Can I reproduce it on Linux? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug other/31043] New: duplicated data in .rodata / .rodata.cst sections.
$ cat pi.cpp
#include
extern double const pi = M_PI;
extern double foo() { return pi; }
.section.rodata.cst8,"aM",@progbits,8
.align 8
.LC0: .long 1413754136
.long 1074340347
.globl pi
.section.rodata
.align 8
pi: .long 1413754136
.long 1074340347
_Z3foov:
pushl %ebp
movl%esp, %ebp
fldl.LC0
popl%ebp
ret
--
Summary: duplicated data in .rodata / .rodata.cst sections.
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86*-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31043
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #38 from hidden_peak at mail dot ru 2007-03-05 14:53 --- (In reply to comment #37) > > Can I reproduce it on Linux? > May be comment #21 help you? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #39 from hjl at lucon dot org 2007-03-05 15:25 --- (In reply to comment #38) > (In reply to comment #37) > > > > Can I reproduce it on Linux? > > > > May be comment #21 help you? > That is an old compiler bug which has been fixed since then. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #40 from michael dot klein at fazi dot de 2007-03-05 16:20 --- Subject: Re: Discarded Linkonce sections in .rodata On Mon, 5 Mar 2007, hjl at lucon dot org wrote: > Can I reproduce it on Linux? Using gcc 4.1.1 with binutils-070227 I can also reproduce it on Linux, binutils 2.15 from Debian Sarge do not exhibit this problem. As this is a closes source application I can't upload the source code. Would the generated asm code be of any help? The smallest testcase I have is currently ~500k lines asm, split accross two files. /Michael -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug tree-optimization/19637] Missed VRP and FRE opportunities in the presence of casts
--- Comment #11 from patchapp at dberlin dot org 2007-03-05 16:30 --- Subject: Bug number PR19637 A patch for this bug has been added to the patch tracker. The mailing list url for the patch is http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00295.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19637
[Bug c++/16625] Discarded Linkonce sections in .rodata
--- Comment #41 from hjl at lucon dot org 2007-03-05 16:38 --- (In reply to comment #40) > Subject: Re: Discarded Linkonce sections in .rodata > > On Mon, 5 Mar 2007, hjl at lucon dot org wrote: > > > Can I reproduce it on Linux? > > Using gcc 4.1.1 with binutils-070227 I can also reproduce it on Linux, > binutils 2.15 from Debian Sarge do not exhibit this problem. > > As this is a closes source application I can't upload the source code. > Would the generated asm code be of any help? > > The smallest testcase I have is currently ~500k lines asm, split accross > two files. > > /Michael > Assembly files will help. Please make them available. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16625
[Bug c++/31044] New: Compilation fails on definition of a static template class member
The following sample fails to compile:
template
class Container
{
static const _Type Value = _Val;
};
template
class Test
{
static const uint Value = 2;
static const Container<_Type, Value> m_Test;
};
template
const Container<_Type, Test<_Type>::Value> Test<_Type>::m_Test;
The compiler says:
Test.cpp:29: error: conflicting declaration 'const Container<_Type,
Test<_Type>::Value> Test<_Type>::m_Test'
Test.cpp:24: error: 'Test<_Type>::m_Test' has a previous declaration as 'const
Container<_Type, 2> Test<_Type>::m_Test'
Test.cpp:29: error: declaration of 'const Container<_Type, 2>
Test<_Type>::m_Test' outside of class is not definition
The problem is the Test<_Type>::Value in the definition - if i replace it with
2 it is working. I tried the sample above with Visual Studio 2005 and Comeau
4.3.3 (Online) and both compile without any error.
--
Summary: Compilation fails on definition of a static template
class member
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: indiana dot jones at gmx dot at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31044
[Bug tree-optimization/23777] Does not remove all references to var
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-03-05 16:55 --- Subject: Bug 23777 Author: rguenth Date: Mon Mar 5 16:55:23 2007 New Revision: 122558 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122558 Log: 2007-03-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/23777 * gcc.dg/tree-ssa/pr23777.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr23777.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23777
[Bug tree-optimization/23777] Does not remove all references to var
--- Comment #8 from rguenth at gcc dot gnu dot org 2007-03-05 16:56 --- This is fixed now on the mainline. Supposedly by Author: dnovillo Date: Fri Mar 2 19:20:14 2007 New Revision: 122484 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122484 Log: * tree-ssa-structalias.c (could_have_pointers): Tidy. (get_constraint_for): Likewise. (do_structure_copy): Likewise. (find_func_aliases): Fix references to MODIFY_EXPR. (intra_create_variable_infos): Tidy. * tree-ssa-operands.c (add_virtual_operand): Add argument IS_CALL_SITE. When adding members of alias sets, if IS_CALL_SITE is true and the symbol is not call-clobbered, skip it. Adjust all callers. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.3.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23777
[Bug c++/31045] New: gcc4.1. has problems with pointers
Hi ,
The following simple testcase does not compile using GCC4.1.1
#include
int main() {
char **const p = (char **)std::malloc(sizeof*p);
return !p;
}
--
Summary: gcc4.1. has problems with pointers
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31045
[Bug c++/31045] gcc4.1. has problems with pointers
--- Comment #1 from satyaakam at yahoo dot co dot in 2007-03-05 16:58 --- Created an attachment (id=13145) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13145&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31045
[Bug tree-optimization/14052] Combiner weakness
--- Comment #5 from rguenth at gcc dot gnu dot org 2007-03-05 17:03 --- It was fixed by the fix for PR15911. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||15911 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14052
[Bug tree-optimization/14052] Combiner weakness
--- Comment #6 from rguenth at gcc dot gnu dot org 2007-03-05 17:03 --- Subject: Bug 14052 Author: rguenth Date: Mon Mar 5 17:03:14 2007 New Revision: 122559 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122559 Log: 2007-03-05 Richard Guenther <[EMAIL PROTECTED]> PR tree-optimization/14052 * gcc.dg/tree-ssa/vrp33.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/vrp33.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14052
[Bug fortran/30929] -pedantic-error produced only warnings and no errors
--- Comment #3 from manu at gcc dot gnu dot org 2007-03-05 17:05 --- I am not sure if gfortran diagnostics are different, but... are you sure that particular warning is a pedantic warning and not simply an unconditional warning? AFAIK, pedantic-errors will turn only pedantic warnings into errors, other warnings will still be warnings unless -Werror. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug middle-end/26198] Unfolded comparison after cfg_cleanup
--- Comment #4 from rguenth at gcc dot gnu dot org 2007-03-05 17:07 --- Depends on (and is partly fixed by) PR30965. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||30965 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26198
[Bug middle-end/31046] New: some i386-pf-sse-1.c started to fail on 3/3/07
Before bootstrapping on 3/3/07, the i386-pf-sse-1.c test passed for me. Now, I get the following: PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3 scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium3m scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium-m scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4 scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=pentium4m scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=prescott scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler prefetcht2 PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=athlon-4 scan-assembler-not prefetchw PASS: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=c3-2 (test for excess errors) FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=c3-2 scan-assembler prefetchnta FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=c3-2 scan-assembler prefetcht0 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686 -mtune=c3-2 scan-assembler prefetcht1 FAIL: gcc.misc-tests/i386-pf-sse-1.c -march=i686
[Bug c++/31047] New: GCC 4.1.1 has template bug
We've uncovered a GCC 4.1.1 template bug when we compile using GCC4.1.1,This
simple testcase shows the issue.
#include
template< typename T > void foo( T var) { std::cout << "T" << std::endl; }
template < typename T> void doit( T var ) { foo(var); }
void foo(const int& var) { std::cout << "INT" << std::endl; }
int main() {
doit(3); // prints T
return 0;
}
/// temp.cpp
Run the example with gcc 3.2.3
rm -f a.out
$/v3.2.3/bin/g++ -Wall temp.cpp
LD_LIBRARY_PATH=/v3.2.3/lib:$LD_LIBRARY_PATH; a.out
[~/test]$ gcc3
INT
Now run with GCC 4.1.1
[~/test]$ more gcc4
rm -f a.out
$/v4.1.1/bin/g++ -Wall temp.cpp
LD_LIBRARY_PATH=/v4.1.1/lib:$LD_LIBRARY_PATH; a.out
[EMAIL PROTECTED] ~/test]$ gcc4
T
We can fix this particular example by moving
void foo(const int& var) { std::cout << "INT" << std::endl; }
to the top of the function. However, this won't work in more complex cases.
--
Summary: GCC 4.1.1 has template bug
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31047
[Bug c++/31047] GCC 4.1.1 has template bug
--- Comment #1 from satyaakam at yahoo dot co dot in 2007-03-05 17:11 --- Created an attachment (id=13146) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13146&action=view) test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31047
[Bug c++/31048] New: G++ 4.1.1 forgets to allocate memory (skips part of user code)
Hi,
We have problems using gcc 4.1.1. we are trying to compile a code in file
case17.cpp (see attached in testcase area). The problem is that compiler
forgets to call malloc and forgets to check the return value (see case17.s) and
it also forgets to initialize pointer called color. That is we do not see the
following lines reflected in the assembly output:
char **const colorTable = (char **)std::malloc(ncolors*sizeof*colorTable),
**volatile color=colorTable;
if(colorTable); else { return *oldct = 0; }
--
Summary: G++ 4.1.1 forgets to allocate memory (skips part of user
code)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31048
[Bug c++/31049] New: G++ 4.1.1 forgets to allocate memory (skips part of user code)
Hi,
We have problems using gcc 4.1.1. we are trying to compile a code in file
case17.cpp (see attached in testcase area). The problem is that compiler
forgets to call malloc and forgets to check the return value and it also
forgets to initialize pointer called color. That is we do not see the following
lines reflected in the assembly output:
char **const colorTable = (char **)std::malloc(ncolors*sizeof*colorTable),
**volatile color=colorTable;
if(colorTable); else { return *oldct = 0; }
--
Summary: G++ 4.1.1 forgets to allocate memory (skips part of user
code)
Product: gcc
Version: 4.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: satyaakam at yahoo dot co dot in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31049
[Bug c++/31049] G++ 4.1.1 forgets to allocate memory (skips part of user code)
--- Comment #1 from satyaakam at yahoo dot co dot in 2007-03-05 17:17 --- Created an attachment (id=13147) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13147&action=view) case17 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31049
[Bug c++/31045] gcc4.1. has problems with pointers
--- Comment #2 from tbm at cyrius dot com 2007-03-05 17:48 ---
This works just fine here. Can you please show the exact error message you get
and the output of g++ -v
20816:[EMAIL PROTECTED]: ~/tmp/src] cat t.c
#include
int main() {
char **const p = (char **)std::malloc(sizeof*p);
return !p;
}
20817:[EMAIL PROTECTED]: ~/tmp/src] g++-4.1 -c t.c
20818:[EMAIL PROTECTED]: ~/tmp/src] g++-4.1 -c -O2 t.c
20819:[EMAIL PROTECTED]: ~/tmp/src]
--
tbm at cyrius dot com changed:
What|Removed |Added
CC||tbm at cyrius dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31045
[Bug c++/31048] G++ 4.1.1 forgets to allocate memory (skips part of user code)
--- Comment #1 from tbm at gcc dot gnu dot org 2007-03-05 17:51 --- *** This bug has been marked as a duplicate of 31049 *** -- tbm at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31048
[Bug c++/31049] G++ 4.1.1 forgets to allocate memory (skips part of user code)
--- Comment #2 from tbm at gcc dot gnu dot org 2007-03-05 17:51 --- *** Bug 31048 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31049
[Bug c++/31045] gcc4.1. has problems with pointers
--- Comment #3 from satyaakam at yahoo dot co dot in 2007-03-05 17:58 --- error we get is as follows case16.cpp: In function 'int main()': case16.cpp:5: error: in argument to unary ! $/grid/common/pkgs/gcc/v4.1.1/bin/g++ -v Using built-in specs. Target: x86_64-redhat-linux Configured with: /grid/sfi/ct_src/gcc-v4.1.1/platforms/rh_64/matrix_bootstrap_000/gcc-4.1.1/configure --prefix=/grid/common/pkgs/gcc/v4.1.1 --mandir=/grid/common/pkgs/gcc/v4.1.1/man --infodir=/grid/common/pkgs/gcc/v4.1.1/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --with-gnu-as --with-as=/grid/common/pkgs/gcc/v4.1.1/bin/as --with-gnu-ld --with-ld=/grid/common/pkgs/gcc/v4.1.1/bin/ld --disable-libgcj --with-local-prefix=/grid/common/pkgs/gcc/v4.1.1 --enable-clocale=gnu --with-gmp=/grid/common/pkgs/gmp/v4.1.4 --enable-languages=c,c++,objc,f95 --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31045
[Bug tree-optimization/31034] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:267
--- Comment #6 from ian at gcc dot gnu dot org 2007-03-05 18:01 --- Subject: Bug 31034 Author: ian Date: Mon Mar 5 18:01:00 2007 New Revision: 122562 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122562 Log: PR tree-optimization/31034 * tree-vrp.c (extract_range_from_assert): Don't try to handle a half-range if the other side is an overflow infinity. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-vrp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31034
[Bug fortran/30929] -pedantic-error produced only warnings and no errors
--- Comment #4 from burnus at gcc dot gnu dot org 2007-03-05 18:08 ---
> I am not sure if gfortran diagnostics are different,
I think gfortran handles the warnings quite different, not that I know much
about the details of the C frontend.
> but... are you sure that particular warning is a pedantic warning and not
> simply an unconditional warning?
primary.c: if (x_hex && pedantic
primary.c- && (gfc_notify_std (GFC_STD_GNU, "Extension: Hexadecimal "
This gives only an error with pedantic set (and -std=f95 or -std=f2003).
Otherwise, -pedantic is quite interwoven with the rest: options.c, e.g.:
if (pedantic)
{
gfc_option.warn_ampersand = 1;
gfc_option.warn_tabs = 0;
}
No idea how to untangle -pedantic from -Wtabs or -Wampersand if
-pedantic-errors has been given, but -Werror has not.
Silently accepting and ignoring it, seems not to be the right way. The simple
solution is not to accept -pedantic-errors (and to point to -Werror) or to turn
on -Werror for -pedantic-errors. Both are rather easy solutions - and feel a
bit clumsy. It needs presumably quite a lot of work to support -pedantic-errors
properly.
First and simpler step should be to change "Warning:" into "Error:" for -Werror
to be in line with the C front end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug fortran/30929] -pedantic-error produced only warnings and no errors
--- Comment #5 from manu at gcc dot gnu dot org 2007-03-05 18:15 --- (In reply to comment #4) > > I am not sure if gfortran diagnostics are different, > > I think gfortran handles the warnings quite different, not that I know much > about the details of the C frontend. > Ah, OK. Then forget anything that I said. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC|manu at gcc dot gnu dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929
[Bug c++/31047] GCC 4.1.1 has template bug
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-05 18:31 --- Actually this is not a bug. The overloaded set for foo in doit is only the template foo and nothing else. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Summary|GCC 4.1.1 has template bug |GCC 4.1.1 has template bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31047
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
-- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |brooks at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-11-06 19:41:39 |2007-03-05 18:57:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug other/31050] New: gcc --version reports wrong year.
As per a message by David Taylor on gcc-patches, "gcc --version" reports the wrong copyright year: > ../bin-4.2/bin/gcc --version gcc (GCC) 4.2.0 20070305 (prerelease) Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. He proposes a patch, but notes that he does not have access to the repository; see: http://gcc.gnu.org/ml/gcc-patches/2007-03/msg00296.html -- Summary: gcc --version reports wrong year. Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: blocker Priority: P3 Component: other AssignedTo: brooks at gcc dot gnu dot org ReportedBy: brooks at gcc dot gnu dot org GCC build triplet: i686-pc-linux-gnu GCC host triplet: i686-pc-linux-gnu GCC target triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug other/31050] gcc --version reports wrong year.
-- brooks at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-05 19:38:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug other/31050] gcc --version reports wrong year.
--- Comment #1 from pinskia at gcc dot gnu dot org 2007-03-05 19:39 --- Note the patch is obvious. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug middle-end/29361] Code seg faults
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-05 19:42 --- No feedback in over 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29361
[Bug bootstrap/29382] Bootstrap comparison failure!
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-05 19:43 --- No feedback in 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29382
[Bug c++/29829] arm-linux-g++: Internal error: Killed (program cc1plus)
--- Comment #2 from pinskia at gcc dot gnu dot org 2007-03-05 19:44 --- No feedback in over 3 months so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29829
[Bug tree-optimization/31034] [4.3 Regression] ICE in set_value_range, at tree-vrp.c:267
--- Comment #7 from ian at airs dot com 2007-03-05 19:55 --- Fixed on mainline. -- ian at airs dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31034
[Bug tree-optimization/31041] [4.3 Regression] verify_stmts failed: invalid operand to binary operator with -O2 -ftree-vectorize
--- Comment #5 from dorit at il dot ibm dot com 2007-03-05 20:15 --- I'm travelling now, but can prepare a fix when I'm back (next week). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31041
[Bug fortran/30437] [4.1/4.2 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #11 from brooks at gcc dot gnu dot org 2007-03-05 20:17 --- Subject: Bug 30437 Author: brooks Date: Mon Mar 5 20:17:23 2007 New Revision: 122572 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122572 Log: fortran/ PR fortran/30437 Backport from trunk: 2007-01-25 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> * lang.opt (Wall): Remove RejectNegative. * options.c (gfc_handle_option): Wall can be disabled. (set_Wall): Add a parameter for disabling Wall. testsuite/ PR fortran/30437 Backport from trunk: 2007-01-25 Manuel Lopez-Ibanez <[EMAIL PROTECTED]> * gcc.dg/Wall.c: New. * gcc.dg/Wno-all.c: New. * gfortran.dg/Wall.f90: New. * gfortran.dg/Wno-all.f90: New. Added: branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/Wall.c branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/Wno-all.c branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/Wall.f90 branches/gcc-4_2-branch/gcc/testsuite/gfortran.dg/Wno-all.f90 Modified: branches/gcc-4_2-branch/gcc/fortran/ChangeLog branches/gcc-4_2-branch/gcc/fortran/lang.opt branches/gcc-4_2-branch/gcc/fortran/options.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug fortran/30437] [4.1 Regression] -Wno-all is rejected (even when fortran is not included)
--- Comment #12 from brooks at gcc dot gnu dot org 2007-03-05 20:18 --- Fixed in 4.2. -- brooks at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|brooks at gcc dot gnu dot |unassigned at gcc dot gnu |org |dot org Status|ASSIGNED|NEW Summary|[4.1/4.2 Regression] -Wno- |[4.1 Regression] -Wno-all is |all is rejected (even when |rejected (even when fortran |fortran is not included)|is not included) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30437
[Bug fortran/23538] gfortran hangs on old cray fortran 66 program
--- Comment #13 from brooks at gcc dot gnu dot org 2007-03-05 20:20 --- As of now, -fmax-errors has been backported to 4.2; it was committed to trunk some months ago. This at least masks this bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23538
[Bug other/31050] gcc --version reports wrong year.
--- Comment #2 from brooks at gcc dot gnu dot org 2007-03-05 20:37 --- Subject: Bug 31050 Author: brooks Date: Mon Mar 5 20:37:05 2007 New Revision: 122574 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122574 Log: PR 31050 * gcc.c: Correct copyright date in --version output. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/gcc.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug other/31050] [4.1/4.3] gcc --version reports wrong year.
--- Comment #3 from brooks at gcc dot gnu dot org 2007-03-05 20:43 --- Fixed in 4.2; currently regtesting in mainline. -- brooks at gcc dot gnu dot org changed: What|Removed |Added CC||brooks at gcc dot gnu dot ||org Status|NEW |ASSIGNED Known to work||4.2.0 Last reconfirmed|2007-03-05 19:38:45 |2007-03-05 20:43:42 date|| Summary|gcc --version reports wrong |[4.1/4.3] gcc --version |year. |reports wrong year. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug bootstrap/30589] [4.3 regression] C99 extern inline patch broke bootstrap on i386-pc-mingw32
--- Comment #9 from tkoenig at gcc dot gnu dot org 2007-03-05 20:58 --- This is really important. We need to be able to support mingw for gfortran, at least. Setting priority. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30589
[Bug other/31050] [4.1/4.3] gcc --version reports wrong year.
--- Comment #4 from brooks at gcc dot gnu dot org 2007-03-05 21:36 --- An identical bug also affects gfortran --version. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug libstdc++/30675] [4.2/4.3 Regression] libstdc++ testsuite hardcodes "ar" and "ranlib"
--- Comment #3 from jsm28 at gcc dot gnu dot org 2007-03-05 22:07 --- Subject: Bug 30675 Author: jsm28 Date: Mon Mar 5 22:07:09 2007 New Revision: 122576 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122576 Log: PR libstdc++/30675 * testsuite/lib/libstdc++.exp (v3-build_support): Use [transform "ar"] and [transform "ranlib"]. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/lib/libstdc++.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30675
[Bug libstdc++/30675] [4.2/4.3 Regression] libstdc++ testsuite hardcodes "ar" and "ranlib"
--- Comment #4 from jsm28 at gcc dot gnu dot org 2007-03-05 22:08 --- Subject: Bug 30675 Author: jsm28 Date: Mon Mar 5 22:08:03 2007 New Revision: 122577 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122577 Log: PR libstdc++/30675 * testsuite/lib/libstdc++.exp (v3-build_support): Use [transform "ar"] and [transform "ranlib"]. Modified: branches/gcc-4_2-branch/libstdc++-v3/ChangeLog branches/gcc-4_2-branch/libstdc++-v3/testsuite/lib/libstdc++.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30675
[Bug fortran/31051] New: gfortran bug with x and t format descriptors.
There is some kind of bug associated with use of x and t formats together. See example below. Counting characters, you can see the 1st line of output is wrong, while the 2nd and 3rd lines are correct. If the 1x is omitted from the format, the output is correct. This bug is observed both with Windows 20061021 version, and linux-X86_64 20070305 version of gfortran. --- C:\source\test>type tft.f95 program t integer, parameter :: N = 9 character(len=40) :: fmt character(len=2), dimension(N) :: y y = 'a ' fmt = '(a,1x,(t7, 3a))' write(*, fmt) '', (y(i), i = 1,N) end program t C:\source\test>gfortran -o tft tft.f95 C:\source\test>tft a a a a a a a a a C:\source\test> -- Summary: gfortran bug with x and t format descriptors. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gay at sfu dot ca GCC host triplet: wtf does 'host triplet' mean? http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31051
[Bug libfortran/31052] New: Bad IOSTAT values when readings NAMELISTs past EOF
Hi, the attached problem showed up after PR 30918 got fixed. (Thanks, Jerry!) When reading a namelist again and again, even after EOF, then suddenly the IOSTAT values jumps from -1 to 5008. This does not happen with other compilers. The namelist file fort.10 is the same as in PR 30918. Output of test run: NAMELIST /REPORT/ after iteration 1: &REPORT TYPE=SYNOP , USE=active , MAX_PROC= 20, / Number of reports: 1 Last status = -1 Number of reports: 0 Last status = -1 Number of reports: 0 Last status =5008 Cheers, -ha -- Summary: Bad IOSTAT values when readings NAMELISTs past EOF Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #1 from anlauf at gmx dot de 2007-03-05 22:26 --- Created an attachment (id=13148) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13148&action=view) Demo code The namelist file is here: http://gcc.gnu.org/bugzilla/attachment.cgi?id=13088 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug fortran/31053] New: print file name when file cannot be opened for writing
On Windows, if a file is open in Excel, one cannot write to it in a Fortran program. So if "junk.csv" is opened in Excel and I compile and run the code program xopen ! check what happens when program tries to open file already open implicit none integer, parameter :: iu = 20 character (len=*), parameter :: xfile="junk.csv" open (unit=iu,file=xfile,action="write",status="replace") end program xopen gfortran Target: i386-pc-mingw32 Configured with: ../trunk/configure --prefix=/mingw --enable-languages=c,fortran --with-gmp=/home/coudert/local --disable-nls --with-ld=/mingw/bin/ld --with-as=/mingw/bin/as --disable-werror --enable-bootstrap --enable-threads --host=i386-pc-mingw32 --disable-shared --enable-libgomp Thread model: win32 gcc version 4.3.0 20061021 (experimental) says At line 6 of file xopen_error.f90 Fortran runtime error: Permission denied I'd like it to say that file "junk.csv" could not be opened, to make debugging easier for the user. For example, Intel Visual Fortran says forrtl: The process cannot access the file because it is being used by another process. forrtl: severe (30): open failure, unit 20, file U:\vrao\fortran\junk.csv Image PCRoutineLineSource ifort_xopen_error 0044382E Unknown Unknown Unknown ifort_xopen_error 00440AEC Unknown Unknown Unknown ifort_xopen_error 00405DFA Unknown Unknown Unknown ifort_xopen_error 00405A17 Unknown Unknown Unknown ifort_xopen_error 00401C81 Unknown Unknown Unknown ifort_xopen_error 0040106F _MAIN__ 6 xopen_error.f90 ifort_xopen_error 00449970 Unknown Unknown Unknown ifort_xopen_error 0042EBB8 Unknown Unknown Unknown kernel32.dll 7C816FD7 Unknown Unknown Unknown -- Summary: print file name when file cannot be opened for writing Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: vivekrao4 at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31053
[Bug tree-optimization/21596] [4.0/4.1/4.2/4.3 Regression] extra temporaries when using global register variables
--- Comment #7 from amacleod at redhat dot com 2007-03-05 22:43 --- Created an attachment (id=13149) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13149&action=view) proposed patch for 4.3 This patch removes one of the temporary copies. With this minor tuning of one of TERs heuristics, the tree optimizers produce: reg.27 = reg - 4B; reg = reg.27; return *reg.27 <= 0; Getting rid of the remaining middle copy is slightly little tricker, because it involves a VDEF. On mainline, this produces the (I think) desired assembly: subl$4, %edi xorl%eax, %eax cmpl$0, -4(%edi) setle %al ret -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug tree-optimization/21596] [4.0/4.1/4.2/4.3 Regression] extra temporaries when using global register variables
--- Comment #8 from amacleod at redhat dot com 2007-03-05 22:52 ---
Created an attachment (id=13150)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13150&action=view)
proposed patch for 4.2
This is the same patch for the 4.2 compiler. Unfortunately, its not quite good
enough because the rtl optimizers still manage to do the wrong thing.
In mainline, life recognizes that the register is dead in the copy:
(insn 7 5 8 2 (parallel [
(set (reg:SI 58 [ reg.27 ])
(plus:SI (reg/v:SI 5 di [ reg ])
(const_int -4 [0xfffc])))
(clobber (reg:CC 17 flags))
]) 148 {*addsi_1} (nil)
(expr_list:REG_DEAD (reg/v:SI 5 di [ reg ])
(expr_list:REG_UNUSED (reg:CC 17 flags) (nil
(insn 8 7 9 2 (set (reg/v:SI 5 di [ reg ])
(reg:SI 58 [ reg.27 ])) 34 {*movsi_1} (insn_list:REG_DEP_TRUE 7 (nil))
(expr_list:REG_DEAD (reg:SI 58 [ reg.27 ])
(nil)))
and combine turns it into:
(insn 8 7 9 2 (parallel [
(set (reg/v:SI 5 di [ reg ])
(plus:SI (reg/v:SI 5 di [ reg ])
(const_int -4 [0xfffc])))
(clobber (reg:CC 17 flags))
]) 148 {*addsi_1} (nil)
on the 4.2 branch, we don't seem to get it right and combine, nor anyone else I
suppose, manages to get merge the 2 insns. so we end up aith the same
assembly.
Unless someone sees something in the RTL optimizers that can be tweaked that
can figure this out, there isn't much point in applying this to 4.2.
Im not planning to look into the RTL side myself, but I will see if there is
anything else TER can do to get rid of this situation in 4.2.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21596
[Bug c++/30895] [4.1/4.2/4.3 regression] ICE with complex values in template parameter
--- Comment #5 from simartin at gcc dot gnu dot org 2007-03-05 22:56 --- Subject: Bug 30895 Author: simartin Date: Mon Mar 5 22:55:58 2007 New Revision: 122578 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122578 Log: 2007-03-05 Simon Martin <[EMAIL PROTECTED]> PR c++/30895 * tree.c (cp_tree_equal): Properly handle COMPLEX_CST trees. Added: branches/gcc-4_1-branch/gcc/testsuite/g++.dg/parse/template23.C Modified: branches/gcc-4_1-branch/gcc/cp/ChangeLog branches/gcc-4_1-branch/gcc/cp/tree.c branches/gcc-4_1-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30895
[Bug c++/30895] [4.1/4.2/4.3 regression] ICE with complex values in template parameter
--- Comment #6 from simartin at gcc dot gnu dot org 2007-03-05 23:05 --- Subject: Bug 30895 Author: simartin Date: Mon Mar 5 23:05:29 2007 New Revision: 122579 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122579 Log: 2007-03-05 Simon Martin <[EMAIL PROTECTED]> PR c++/30895 * tree.c (cp_tree_equal): Properly handle COMPLEX_CST trees. Added: branches/gcc-4_2-branch/gcc/testsuite/g++.dg/parse/template23.C Modified: branches/gcc-4_2-branch/gcc/cp/ChangeLog branches/gcc-4_2-branch/gcc/cp/tree.c branches/gcc-4_2-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30895
[Bug libfortran/31052] Bad IOSTAT values when readings NAMELISTs past EOF
--- Comment #2 from kargl at gcc dot gnu dot org 2007-03-05 23:27 --- The value 5008 is listed in libgfortran.h as ERROR_ENDFILE. The -1 corresponds to ERROR_END. So, the return value of 5008 is telling you that you are trying to (initiate a?) read beyond the end of the file, which you admit to doing. AFAIK, the IOSTAT values aren't documented in gfortran.texi. Someday, someone will get around to documenting them. -- kargl at gcc dot gnu dot org changed: What|Removed |Added CC||kargl at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31052
[Bug debug/29614] [4.2 Regression] DWARF information for function static variable is missing after unrelated code addition
--- Comment #6 from sje at gcc dot gnu dot org 2007-03-05 23:52 --- Subject: Bug 29614 Author: sje Date: Mon Mar 5 23:52:09 2007 New Revision: 122583 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122583 Log: Backported from mainline PR debug/29614 * cgraph.h (cgraph_varpool_last_needed_node): Make global. * cgraph.c (cgraph_varpool_last_needed_node): Ditto. * cgraphunit.c (cgraph_varpool_assemble_pending_decls): Set cgraph_varpool_last_needed_node to NULL. Modified: branches/gcc-4_2-branch/gcc/ChangeLog branches/gcc-4_2-branch/gcc/cgraph.c branches/gcc-4_2-branch/gcc/cgraph.h branches/gcc-4_2-branch/gcc/cgraphunit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29614
[Bug other/31050] [4.1/4.3] gcc --version reports wrong year.
--- Comment #5 from kargl at gcc dot gnu dot org 2007-03-05 23:54 --- Subject: Bug 31050 Author: kargl Date: Mon Mar 5 23:54:46 2007 New Revision: 122584 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=122584 Log: 2007-03-05 Brooks Moses <[EMAIL PROTECTED]> PR 31050 * gfortranspec.c (lang_specific_driver): Update program name and copyright date. Modified: branches/gcc-4_1-branch/gcc/fortran/ChangeLog branches/gcc-4_1-branch/gcc/fortran/gfortranspec.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31050
[Bug debug/29614] [4.2 Regression] DWARF information for function static variable is missing after unrelated code addition
--- Comment #7 from pinskia at gcc dot gnu dot org 2007-03-05 23:56 --- Fixed. -- 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=29614
[Bug target/31054] New: 80387 constants not emitted in 64-bit mode.
$ cat fpu.c
long double emit_fldlg2()
{ return 0.3010299956639811952256464283594894482L; }
long double emit_fldln2()
{ return 0.6931471805599453094286904741849753009L; /* or M_LN2l */ }
long double emit_fldl2e()
{ return 1.4426950408889634073876517827983434472L; /* or M_LOG2El */ }
long double emit_fldl2t()
{ return 3.3219280948873623478083405569094566090L; }
long double emit_fldpi()
{ return 3.1415926535897932385128089594061862044L; /* or M_PIl */ }
for 32-bit mode we get nice output:
$ gcc fpu.c -O1 -c -m32 -fomit-frame-pointer && objdump -d fpu.o
:
0: d9 ec fldlg2
2: c3 ret
0003 :
3: d9 ed fldln2
5: c3 ret
0006 :
6: d9 ea fldl2e
8: c3 ret
0009 :
9: d9 e9 fldl2t
b: c3 ret
000c :
c: d9 eb fldpi
e: c3 ret
for 64-bits mode we get only memory loads :/
$ gcc fpu.c -O1 -c -m64 && objdump -d fpu.o
:
0: db 2d 00 00 00 00 fldt 0(%rip)# 6
6: c3 retq
0007 :
7: db 2d 00 00 00 00 fldt 0(%rip)# d
d: c3 retq
000e :
e: db 2d 00 00 00 00 fldt 0(%rip)# 14
14: c3 retq
0015 :
15: db 2d 00 00 00 00 fldt 0(%rip)# 1b
1b: c3 retq
001c :
1c: db 2d 00 00 00 00 fldt 0(%rip)# 22
22: c3 retq
--
Summary: 80387 constants not emitted in 64-bit mode.
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: pluto at agmk dot net
GCC target triplet: x86_64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31054
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #34 from gcc at troy dot rollo dot name 2007-03-06 03:51
---
The problem looks like a bug in GCC's optimisation in 4.1.1 - for the following
code:
152 while (--delete_count>=0) {
153 zval *q = *(zval **)(--p);
154 *p = NULL;
(gdb) l
155 zval_ptr_dtor(&q);
156 }
157 EG(argument_stack).top_element = p;
('p' is declared as void **)
it is producing:
add %fp, -20, %l3
L1 clr %g1
add %l0, -4, %l0
st %g1, [ %fp + -20 ]
clr [ %l0 ]
call 0x261ea4 <_zval_ptr_dtor>
mov %l3, %o0
inc %l1
cmp %l2, %l1
bne L1
%l0 contains the pointer "p". %l3 contains &q (q is at %fp-20).
Notice that %g1 (which is set to 0 at L1) is always being stored
in "q".
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug fortran/31051] gfortran bug with x and t format descriptors.
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-03-06 06:08 --- Well we have not had one of these for a while. I will look into it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31051
[Bug fortran/31051] gfortran bug with x and t format descriptors.
-- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-06 06:24:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31051
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #35 from ebotcazou at gcc dot gnu dot org 2007-03-06 06:59
---
> The problem looks like a bug in GCC's optimisation in 4.1.1 - for the
> following code:
>
> 152 while (--delete_count>=0) {
> 153 zval *q = *(zval **)(--p);
> 154 *p = NULL;
> (gdb) l
> 155 zval_ptr_dtor(&q);
> 156 }
> 157 EG(argument_stack).top_element = p;
>
> ('p' is declared as void **)
Thanks for investigating. The above code is illegal as per the ISO C standard
because it violates the type-based aliasing rules: you're not allowed to read
a void** object through a zval** lvalue, so the code is equivalent to
152 while (--delete_count>=0) {
--p;
zval *q = NULL;
*p = NULL;
155 zval_ptr_dtor(&q);
156 }
157 EG(argument_stack).top_element = p;
and the compiler correctly optimizes it. You must compile such code with
-fno-strict-aliasing (see the entry for this option in the manual).
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|FIXED |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #36 from ebotcazou at gcc dot gnu dot org 2007-03-06 06:59 --- As per previous analysis. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
[Bug c/30819] php 5.2.1 / gcc 4.1.1 / solaris 2.9 / 64 bit
--- Comment #37 from ebotcazou at gcc dot gnu dot org 2007-03-06 07:03 --- > Thanks for investigating. The above code is illegal as per the ISO C standard > because it violates the type-based aliasing rules: you're not allowed to read > a void** object through a zval** lvalue I meant a void* object through a zval* lvalue... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30819
