[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-04-13 21:26:38 |2009-04-14 06:59:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
--- Comment #2 from gcc at abeckmann dot de 2009-04-14 07:04 ---
An updated testcase that compiles without errors on 4.4.0:
== 8 ==
template typename struct A ;
template typename T , typename = A T struct B
{ } ;
template class W , class struct D
{
typedef W X ;
A X * a ;
} ;
template class Y struct E
{
B Y * b ;
} ;
E int e ;
== 8 ==
--
gcc at abeckmann dot de changed:
What|Removed |Added
Known to fail||4.5.0
Known to work||4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug middle-end/39685] ICE: in copyprop_hardreg_forward_1, at regrename.c:1603
--- Comment #5 from bonzini at gnu dot org 2009-04-14 07:28 --- -O2 -frename-registers is enough actually. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39685
doc/gty.texi incomplete
In case anyone cares
The gcc version shipped with NetBSD 4.0.1 (gcc version 4.1.2 20061021
prerelease (NetBSD nb3 20061125)) has a doc/gty.texi that is rather
incomplete. Specifically, it lists three things that must be marked
for the garbage collector, with wording that implies the list is
exhaustive:
All @code{struct} and @code{union} declarations that define
data structures that are allocated under control of the garbage
collector must be marked. All global variables that hold
pointers to garbage-collected memory must also be marked.
Finally, all global variables that need to be saved and
restored by a precompiled header must be marked.
However, this is incomplete. I added a field to c_parser
c_lcs *lcs
but did not mark anything new with GTY because c_lcs is not a
garbage-collected type. (Whether or not this is a good design for my
purposes is irrelevant here.)
But then, upon trying to build the resulting source, gengtype fell
over, complaining unidentified type `c_lcs'. Obviously, there is
something else that needs marking somehow, beyond the things listed,
but it is not clear what, nor what the correct marking is. (It's
possible that the problem is that GCed memory may not contain pointers
to non-GCed memory, but if so that needs to be clearly specified; if
it's there now, I couldn't find it. The closest I could find was a
statement that [t]he type machinery expects all pointers to point to
the start of an object, which the pointer I added does.)
It's possible this is NetBSD damage; their import has damaged the gcc
tree in at least one known way (BUGS has disappeared), but it seems
unlikely to me that they'd ship the doc file for a different version
from the source. I don't see anything akin to source-code control IDs
in the files, so I'm not sure how to most usefully identify the exact
versions of individual files; if you believe this is NetBSD damage, let
me know and I'll file a NetBSD bug report for it, and if you can think
of a good way for me to identify the particular file version in
question, let me know that too and I can.
/~\ The ASCII Mouse
\ / Ribbon Campaign
X Against HTMLmo...@rodents-montreal.org
/ \ Email! 7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B
[Bug c/39759] New: bug in optimalization O2
gcc --version
gcc (SUSE Linux) 4.3.2 [gcc-4_3-branch revision 141291]
code a.c:
#include stdio.h
main() {
int i;
for (i = 1; i 0; i *= 2)
printf(%d\n,i);
}
1. build:
gcc -O a.c -o a
Run:
./a
1
2
4
...
4536870912
1073741824
2. build:
gcc -O2 a.c -o a
Run:
./a
1
2
4
...
4536870912
1073741824
0
0
0
0
...
--
Summary: bug in optimalization O2
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: vcelakv at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39759
[Bug fortran/39587] Reading integer from gives end-of-file instead of reading a 0
--- Comment #3 from burnus at gcc dot gnu dot org 2009-04-14 08:09 --- I think gfortran has this right. This is an attempt to read from an internal unit of length zero. Try the same operation from a zero length file. I'm not sure whether gfortran is right, but my program from comment 0 works with NAG f95, ifort, sunf95, openf95, g95, pathf95, pgf95 - and only fails with gfortran. The following program (using a zero-length file) works with all of the compilers above - and it also works with gfortran: implicit none character(len=5) :: str integer :: a str = '' a = 5 open(16,form='formatted') write(16,'(a)') '' rewind(16) read(16,'(5x,i1)') a close(16,status='delete') print *, a if(a /= 0) stop 'Error' end * * * The following vendor extension would be nice; it works with ifort, sunf95, openf95, pgf95, pathf95: implicit none character(len=5) :: str logical :: a str = '' a = .true. read(str,'(L1)') a ! Extension: Blanks are read as .false. print *, a if(a .neqv. .false.) stop 'error' end -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587
[Bug target/39722] [cond-optab] worse code with bitfields on v850, mn10300, avr
--- Comment #1 from bonzini at gnu dot org 2009-04-14 08:29 --- Seems to be caused by a failure to simplify (if_then_else (ne (zero_extract:SI (const_int 0 [0x0]) (const_int 1 [0x1]) (const_int 0 [0x0])) (const_int 0 [0x0])) (label_ref 71) (pc))) -- bonzini at gnu dot org changed: What|Removed |Added Summary|[cond-optab] worse code with|[cond-optab] worse code with |bitfields on v850 and |bitfields on v850, mn10300, |mn10300 |avr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39722
[Bug target/39760] New: register allocation costs are not well described on AVR
The same alternative can produce very different instruction sequences. For
example:
if (compare_sign_p (insn))
{
if (l) *l = 1;
return AS1 (tst,%B0);
}
if (reg_unused_after (insn, op)
compare_eq_p (insn))
{
/* Faster than sbiw if we can clobber the operand. */
if (l) *l = 1;
return AS2 (or,%A0,%B0);
}
if (test_hard_reg_class (ADDW_REGS, op))
{
if (l) *l = 1;
return AS2 (sbiw,%0,0);
}
if (l) *l = 2;
return (AS2 (cp,%A0,__zero_reg__) CR_TAB
AS2 (cpc,%B0,__zero_reg__));
--
Summary: register allocation costs are not well described on AVR
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
GCC target triplet: avr-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39760
[Bug tree-optimization/39761] New: ccp does not fully propagate constant real/imaginary parts
From this testcase:
void bar();
void foo(int i)
{
__complex__ int k = 0;
if (i)
k = 1;
if (k)
bar();
}
(cfr. gcc.c-torture/compile/pr35431.c) we get after cddce1:
# k_1 = PHI __complex__ (0, 0)(2), __complex__ (1, 0)(3)
D.1198_6 = REALPART_EXPR k_1;
if (D.1198_6 != 0)
goto bb 6;
else
goto bb 5;
bb 5:
D.1200_7 = IMAGPART_EXPR k_1;
if (D.1200_7 != 0)
goto bb 6;
else
goto bb 7;
and the IMAGPART_EXPR could be CCP'd or FRE'd to zero. Likewise the
REALPART_EXPR could be FRE'd to PHI 0(2), 1(3).
--
Summary: ccp does not fully propagate constant real/imaginary
parts
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: bonzini at gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug c/39759] bug in optimalization O2
--- Comment #1 from schwab at linux-m68k dot org 2009-04-14 09:33 --- Signed integer overflow is undefined in C. Use -fwrapv if you want wrapping semantics. -- schwab at linux-m68k dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39759
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-14 10:14 --- I also see this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug ada/39756] FAIL: c9a011b
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-14 10:14 --- I also see this repeatedly. This test should be XFAILed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39756
[Bug target/39740] unrecognizable insn on alpha using -O3 and -std=c99
--- Comment #10 from uros at gcc dot gnu dot org 2009-04-14 10:21 --- Subject: Bug 39740 Author: uros Date: Tue Apr 14 10:21:41 2009 New Revision: 146028 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146028 Log: Backport from mainline: 2009-04-12 Uros Bizjak ubiz...@gmail.com PR target/39740 * config/alpha/predicates.md (local_symbolic_operand): Return 1 for offseted label references. testsuite/ChangeLog: Backport from mainline: 2009-04-12 Uros Bizjak ubiz...@gmail.com PR target/39740 * gcc.target/alpha/pr39740.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/alpha/pr39740.c - copied, changed from r145985, trunk/gcc/testsuite/gcc.target/alpha/pr39740.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/alpha/predicates.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39740
[Bug tree-optimization/39612] [4.4/4.5 Regression] Incorrect warning issued Re variable *is* used uninitialized in this function
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
[Bug rtl-optimization/39762] New: [4.4/4.5 Regression] IRA ICE with -msoft-float
/* { dg-do compile } */
/* { dg-options -Os } */
/* { dg-options -Os -msoft-float { target { { i?86-* x86_64-* } ilp32 } }
} */
extern void bar (void);
void
foo (unsigned int x, unsigned int y, unsigned int z)
{
unsigned int a, b, d, e;
unsigned int f = (8 12) + 0.000122 * 4096;
b = (x 12) + 0.000122 * 4096;
e = (100 12) + 0.000122 * 4096;
b = (unsigned long long) (((b 13) / e) + 1) / 2;
a = (y / 8);
e = (a 12) + 0.000122 * 4096;
d = (unsigned long long) (b * e + 2048) 12;
d = (unsigned long long) (d * f + 2048) 12;
if (z = d)
bar ();
}
ICEs on i?86-linux (and x86_64-linux -m32) with -Os -msoft-float since r142892,
with -fno-ira it worked until that option has been removed.
--
Summary: [4.4/4.5 Regression] IRA ICE with -msoft-float
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jakub at gcc dot gnu dot org
GCC target triplet: i?86-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
[Bug target/39740] unrecognizable insn on alpha using -O3 and -std=c99
--- Comment #11 from uros at gcc dot gnu dot org 2009-04-14 10:31 --- Subject: Bug 39740 Author: uros Date: Tue Apr 14 10:31:29 2009 New Revision: 146030 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146030 Log: Backport from mainline: 2009-04-12 Uros Bizjak ubiz...@gmail.com PR target/39740 * config/alpha/predicates.md (local_symbolic_operand): Return 1 for offseted label references. testsuite/ChangeLog: Backport from mainline: 2009-04-12 Uros Bizjak ubiz...@gmail.com PR target/39740 * gcc.target/alpha/pr39740.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/alpha/pr39740.c - copied unchanged from r146028, branches/gcc-4_4-branch/gcc/testsuite/gcc.target/alpha/pr39740.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/alpha/predicates.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39740
[Bug target/39740] unrecognizable insn on alpha using -O3 and -std=c99
--- Comment #12 from ubizjak at gmail dot com 2009-04-14 10:37 --- Fixed also for 4.3 and 4.4. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39740
[Bug tree-optimization/39761] ccp does not fully propagate constant real/imaginary parts
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-14 10:06 --- It is done by DOM, VRP and/or phicprop. CCP cannot do it because the PHI node is varying. Complex lowering does not split PHI nodes into a real/imag part either. For the same reason as CCP FRE won't do it either. PRE should be able to phi-translate through the PHI and discover it, but there's nothing antic-in here. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug rtl-optimization/39762] [4.4/4.5 Regression] IRA ICE with -msoft-float
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
[Bug tree-optimization/39675] [4.4 Regression] ICE in vect_get_vec_def_for_operand, at tree-vect-transform.c:1999
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39675
[Bug tree-optimization/39604] [4.3/4.4/4.5 Regression] tree-ssa-sink breaks stack layout
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39604
[Bug c/39755] inline memcpy() incorrectly optimized on MIPS target
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-14 10:13 --- GCC 3.2.1 is no longer maintained, please reproduce with at least GCC 4.3.3. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39755
[Bug rtl-optimization/39762] [4.4/4.5 Regression] IRA ICE with -msoft-float
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39762
[Bug tree-optimization/39761] ccp does not fully propagate constant real/imaginary parts
--- Comment #1 from bonzini at gnu dot org 2009-04-14 08:57 --- This is currently caught by RTL jump bypassing, but not on all machines. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-14 08:57:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug tree-optimization/39761] PRE does not discover constant real/imaginary parts
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-04-14 12:00 ---
Huh? I see in .optimized
foo (int i)
{
bb 2:
if (i != 0)
goto bb 3;
else
goto bb 4;
bb 3:
Invalid sum of incoming frequencies 5000, should be 7231
bar (); [tail call]
bb 4:
Invalid sum of incoming frequencies 12231, should be 1
return;
}
since dom1.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug tree-optimization/39761] data-flow analysis does not discover constant real/imaginary parts
--- Comment #5 from bonzini at gnu dot org 2009-04-14 12:16 --- Right, sorry -- it is only at -Os that we don't get it. VRP and DOM say that the jump threading is not performed because the probability is too small, and PRE does not run at -Os at all. -- bonzini at gnu dot org changed: What|Removed |Added Summary|PRE does not discover |data-flow analysis does not |constant real/imaginary |discover constant |parts |real/imaginary parts http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug fortran/24878] subroutine getting called illegally as a function
--- Comment #3 from dominiq at lps dot ens dot fr 2009-04-14 12:20 --- At revision 145996, this error is not detected with the -fwhole-file option: [karma] f90/bug% gfc -fwhole-file pr24878_db.f90 [karma] f90/bug% a.out Did NOT catch this error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24878
[Bug tree-optimization/39761] data-flow analysis does not discover constant real/imaginary parts
--- Comment #6 from rguenther at suse dot de 2009-04-14 12:24 --- Subject: Re: data-flow analysis does not discover constant real/imaginary parts On Tue, 14 Apr 2009, bonzini at gnu dot org wrote: --- Comment #5 from bonzini at gnu dot org 2009-04-14 12:16 --- Right, sorry -- it is only at -Os that we don't get it. VRP and DOM say that the jump threading is not performed because the probability is too small, and PRE does not run at -Os at all. We could add this to CCP if we were able to build partially varying constants, for example with abusing error_mark_node (ugh). So say that the PHI is really constant, but with value __complex__ (error_mark_node, 0) and then be very anal about the error_mark_nodes leaking somewhere ... The same issue exists with VECTOR_CSTs of course. I'll play with that idea. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug tree-optimization/38785] [4.3/4.4/4.5 Regression] huge performance regression on EEMBC bitmnp01
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38785
[Bug tree-optimization/39761] data-flow analysis does not discover constant real/imaginary parts
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-14 12:40 --- Ok, doesn't work. We get lattice transitions CONSTANT - CONSTANT with different values which is unexpected (or even may break sth). If you remove that sanity check it substitutes the broken constant (huh, with zero!) (checks missing for that), but otherwise the propagation itself works. Too much of a hack... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug tree-optimization/39761] PRE does not discover constant real/imaginary parts
--- Comment #3 from bonzini at gnu dot org 2009-04-14 11:56 --- No, it survives to RTL :-( Adjusting subject. -- bonzini at gnu dot org changed: What|Removed |Added Summary|ccp does not fully propagate|PRE does not discover |constant real/imaginary |constant real/imaginary |parts |parts http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug tree-optimization/39761] data-flow analysis does not discover constant real/imaginary parts
--- Comment #8 from bonzini at gnu dot org 2009-04-14 13:00 --- It seems easier to lower complex phis. Though it doesn't work with vectors, it shouldn't matter since we do not have vector extraction yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug tree-optimization/39761] data-flow analysis does not discover constant real/imaginary parts
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-04-14 13:04 --- Created an attachment (id=17630) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17630action=view) hack Hack in-progress that even works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug c++/39763] New: -Wshadow reports shadowed declarations for parameters of unnamed temp objects
This is very similar to Bug 39526 except that the test-case there now (Fedora rawhide: gcc-4.4.0-0.32.x86_64) passes, while this similar one reports... g++ -c -Wshadow demo.cxx demo.cxx: In function int foo(): demo.cxx:11: warning: declaration of infoo shadows a previous local demo.cxx:10: warning: shadowed declaration is here -- Summary: -Wshadow reports shadowed declarations for parameters of unnamed temp objects Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: caolanm at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
[Bug c++/39763] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #1 from caolanm at redhat dot com 2009-04-14 13:06 --- Created an attachment (id=17631) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17631action=view) trivial demo -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
[Bug tree-optimization/39761] data-flow analysis does not discover constant real/imaginary parts
--- Comment #10 from rguenther at suse dot de 2009-04-14 13:08 --- Subject: Re: data-flow analysis does not discover constant real/imaginary parts On Tue, 14 Apr 2009, bonzini at gnu dot org wrote: --- Comment #8 from bonzini at gnu dot org 2009-04-14 13:00 --- It seems easier to lower complex phis. Though it doesn't work with vectors, it shouldn't matter since we do not have vector extraction yet. We do, via BIT_FIELD_REF. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug tree-optimization/39761] data-flow analysis does not discover constant real/imaginary parts
--- Comment #11 from bonzini at gnu dot org 2009-04-14 13:41 --- Yes, but programs cannot use it so it does not really count. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug tree-optimization/39761] data-flow analysis does not discover constant real/imaginary parts
--- Comment #12 from pinskia at gcc dot gnu dot org 2009-04-14 13:52 --- I Think the PRE/FRE part of this bug is really PR 38884 (for the complex) and PR 38885 (for the vector). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39761
[Bug rtl-optimization/39543] [4.4/4.5 Regression] Reload failure on mplayer from SVN
--- Comment #11 from bonzini at gnu dot org 2009-04-14 13:52 --- I don't see the connection to SSA expansion Well, now that you posted the patch my suppositions were partly true. The important thing is that now you have a way to get an SSA_NAME's RHS into expansion. So, if we can do a kind of mini-TER of values appearing into an ASM with the offending constraints, this would fix the bug even at -O0 or -fno-tree-ter. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug rtl-optimization/39543] [4.4/4.5 Regression] Reload failure on mplayer from SVN
--- Comment #12 from matz at gcc dot gnu dot org 2009-04-14 13:58 --- That's only possible sometimes and hence can't be relied upon. The RHS expression might not be available at the point of the use anymore (some operands might have been clobbered meanwhile, remember we aren't in SSA anymore). That's one of the reasons why TER doesn't forward all expressions even if they're used only once. To really fix this for good it needs a separate pass tracking lifetime (and introducing copies in case the operands aren't available) or working on SSA form (where lifetime isn't a problem and copies would be inserted by out-of-SSA). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug rtl-optimization/39543] [4.4/4.5 Regression] Reload failure on mplayer from SVN
--- Comment #13 from bonzini at gnu dot org 2009-04-14 14:02 --- Subject: Re: [4.4/4.5 Regression] Reload failure on mplayer from SVN That's one of the reasons why TER doesn't forward all expressions even if they're used only once. Yes -- indeed in this case we'd need forwarding of things used more than once. The infrastructure to inject definitions from an SSA_NAME was all that I was interested in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39543
[Bug middle-end/39744] component references with VIEW_CONVERT_EXPR should be canonicalized
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-14 14:02 ---
Testcase for the second case:
struct Y { int z; };
struct X { struct Y y; };
int foo()
{
int z = 1;
struct X *x = (struct X *)z;
return x-y.z;
}
a testcase for the first case is harder.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39744
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
--- Comment #4 from jason at redhat dot com 2009-04-14 14:07 --- Subject: Re: [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248 I wonder if it only works on 4.4 because tree checking is disabled on release branches. Jason -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug c++/38228] [4.3/4.4/4.5 regression] ICE with invalid use of bound member function
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2008-11-23 18:25:55 |2009-04-14 14:16:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug c++/39763] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #2 from jason at gcc dot gnu dot org 2009-04-14 14:25 --- I can't reproduce this with 4.4 or 4.5. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
[Bug c++/38228] [4.3/4.4/4.5 regression] ICE with invalid use of bound member function
--- Comment #8 from dodji at gcc dot gnu dot org 2009-04-14 14:34 --- Created an attachment (id=17632) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17632action=view) Fix candidate I am fully bootstrapping/regtesting this candidate patch at the moment ... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38228
[Bug c/39748] [4.5 regression] warning outside bounds of constant string not suppressed in dead code
--- Comment #2 from falk at debian dot org 2009-04-14 14:47 ---
The problem comes from some convoluted code that was apparently substituted for
strlen to special-case constant arguments. It boils down to:
int f(void) {
if (0)
return ((const char *) )[2];
return 0;
}
(without the cast, no warning is given).
--
falk at debian dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||diagnostic
Known to fail||4.5.0
Known to work||4.4.0
Summary|possible bogus offset |[4.5 regression] warning
|warning |outside bounds of constant
||string not suppressed in
||dead code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39748
[Bug fortran/20896] ambiguous interface not detected
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-04-14 14:49 --- Closing as WONTFIX. See http://gcc.gnu.org/ml/fortran/2009-04/msg00149.html for discussion. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20896
[Bug c++/35652] [4.3 Regression] offset warning should be given in the front-end
--- Comment #28 from pinskia at gcc dot gnu dot org 2009-04-14 14:50 --- *** Bug 39748 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||dcb314 at hotmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35652
[Bug c/39748] [4.5 regression] warning outside bounds of constant string not suppressed in dead code
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-14 14:50 --- *** This bug has been marked as a duplicate of 35652 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39748
[Bug middle-end/39764] New: ICE in set_lattice_value, at tree-ssa-ccp.c:468
$ cat ice.ii
class A;
class B { };
extern const double NaN;
B foo(A* exec, double d);
inline B baz(A* a) {
return foo(a, NaN);
}
B bar(A* a) {
return baz(a);
}
extern const double NaN = (__builtin_nanf());
$ ./xgcc -B. -m4 -ml -fvisibility=hidden -O2 -finline-functions ice.ii
ice.ii: In function 'B baz(A*)':
ice.ii:11: internal compiler error: in set_lattice_value, at tree-ssa-ccp.c:468
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ ./xgcc -v
Using built-in specs.
Target: sh4-unknown-linux-gnu
Configured with: ../configure --build=i486-build_pc-linux-gnu
--host=i486-build_pc-linux-gnu --target=sh4-unknown-linux-gnu
--prefix=/home/ryan/crosstool-ng-1.3.1/targets/sh4-unknown-linux-gnu/build/gcc-core-static
--with-local-prefix=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--disable-multilib
--with-sysroot=/home/ryan/x-tools/sh4-unknown-linux-gnu/sh4-unknown-linux-gnu/sys-root
--with-newlib --enable-threads=no --disable-shared --enable-__cxa_atexit
--disable-nls --enable-symvers=gnu --enable-languages=c++
--enable-target-optspace
Thread model: single
gcc version 4.5.0 20090413 (experimental) [trunk revision 146016] (GCC)
I also reproduced the ICE in 4.3.3 and 4.4.0
--
Summary: ICE in set_lattice_value, at tree-ssa-ccp.c:468
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rmansfield at qnx dot com
GCC build triplet: i486-build_pc-linux-gnu
GCC host triplet: i486-build_pc-linux-gnu
GCC target triplet: sh4-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39764
[Bug c++/39763] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #3 from jakub at gcc dot gnu dot org 2009-04-14 14:57 --- I certainly can, with e.g. fresly updated: GNU C++ (GCC) version 4.5.0 20090414 (experimental) (x86_64-unknown-linux-gnu) LC_ALL=C ./cc1plus -O2 -Wshadow z.C -quiet z.C: In function 'int foo()': z.C:11: warning: declaration of 'infoo' shadows a previous local z.C:10: warning: shadowed declaration is here -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
[Bug c++/39763] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #4 from jason at gcc dot gnu dot org 2009-04-14 15:04 --- Yeah, it would help to use -Wshadow... -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-14 15:04:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
[Bug fortran/20896] ambiguous interface not detected
--- Comment #14 from dfranke at gcc dot gnu dot org 2009-04-14 15:04 --- Reopen, closed wrong PR :( -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|WONTFIX | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20896
[Bug target/39601] xstormy16 target broken, cannot build newlib
--- Comment #1 from nickc at redhat dot com 2009-04-14 15:14 --- Created an attachment (id=17633) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17633action=view) Do not assume that comparisons with small integers will always produce a short branch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39601
[Bug target/39601] xstormy16 target broken, cannot build newlib
--- Comment #2 from nickc at redhat dot com 2009-04-14 15:15 --- Hi Paolo I am going to apply the uploaded patch to fix this problem. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39601
[Bug fortran/21203] gfortran doesn't work on targets/variants without two floating point types
--- Comment #31 from dfranke at gcc dot gnu dot org 2009-04-14 15:16 --- Closing as WONTFIX. See http://gcc.gnu.org/ml/fortran/2009-04/msg00149.html for discussion. -- dfranke at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21203
[Bug middle-end/39765] New: internal compiler error: in copyprop_hardreg_forward_1
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree if that
matters.
$ cris-linux-gcc -O2 -S buffer.i
/home/segher/src/kernel/fs/buffer.c: In function 'block_page_mkwrite':
/home/segher/src/kernel/fs/buffer.c:2409: error: insn does not satisfy its
constraints:
(insn 146 52 147 7 /home/segher/src/kernel/fs/buffer.c:2391 (set (reg/v:SI 1 r1
[orig:30 end ] [30])
(zero_extend:SI (reg:HI 16 srp))) 58 {zero_extendhisi2} (nil))
/home/segher/src/kernel/fs/buffer.c:2409: internal compiler error: in
copyprop_hardreg_forward_1, at regrename.c:1603
It needs -O2 or -O3 to fail, -Os is not enough.
--
Summary: internal compiler error: in copyprop_hardreg_forward_1
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: segher at kernel dot crashing dot org
GCC host triplet: x86_64-linux
GCC target triplet: cris-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39765
[Bug middle-end/39765] internal compiler error: in copyprop_hardreg_forward_1
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 15:30 --- Created an attachment (id=17634) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17634action=view) testcase, not minimised -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39765
[Bug debug/39766] New: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree if that matters. $ h8300-elf-gcc -mh -mint32 -g -fomit-frame-pointer -S read_write.i /home/segher/src/kernel/fs/read_write.c: In function 'sys_pwrite64': /home/segher/src/kernel/fs/read_write.c:455: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179 It needs all those options to fail. -- Summary: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org GCC host triplet: x86_64-linux GCC target triplet: h8300-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39766
[Bug debug/39766] internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 15:50 --- Created an attachment (id=17635) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17635action=view) testcase, not minimised -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39766
[Bug bootstrap/39767] New: libgcc2.c:562: internal compiler error: RTL check: expected code 'reg', have 'ashiftrt' in rhs_regno, at rtl.h:1005
/home/segher/barc1/sh64/gcc/./gcc/xgcc -B/home/segher/barc1/sh64/gcc/./gcc/ -B/n/17/segher/cross-4.4.0-rc1/sh64-linux/bin/ -B/n/17/segher/cross-4.4.0-rc1/sh64-linux/lib/ -isystem /n/17/segher/cross-4.4.0-rc1/sh64-linux/include -isystem /n/17/segher/cross-4.4.0-rc1/sh64-linux/sys-include -g -O2 -mb -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -isystem ./include -fPIC -g -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -Dinhibit_libc -fpic -DNO_FPSCR_VALUES -I. -I. -I../../.././gcc -I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc -I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/. -I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc -I/n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../include -DHAVE_CC_TLS -o _muldi3.o -MT _muldi3.o -MD -MP -MF _muldi3.dep -DL_muldi3 -c /n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc/libgcc2.c \ /n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc/libgcc2.c: In function '__muldi3': /n/17/segher/src/gcc-4.4.0-RC-20090414/libgcc/../gcc/libgcc2.c:562: internal compiler error: RTL check: expected code 'reg', have 'ashiftrt' in rhs_regno, at rtl.h:1005 configured with: $ /n/17/segher/src/gcc-4.4.0-RC-20090414/configure --target=sh64-linux \ --enable-targets=all --prefix=/n/17/segher/cross-4.4.0-rc1 \ --with-mpfr=/opt/cfarm/mpfr-2.4.1 --enable-languages=c --without-headers \ --enable-sjlj-exceptions --with-system-libunwind --disable-nls --disable-threads \ --disable-shared --disable-libmudflap --disable-libssp --disable-libgomp \ --disable-decimal-float --enable-checking=yes,rtl,tree -- Summary: libgcc2.c:562: internal compiler error: RTL check: expected code 'reg', have 'ashiftrt' in rhs_regno, at rtl.h:1005 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org GCC host triplet: x86_64-linux GCC target triplet: sh64-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39767
[Bug target/39768] New: internal compiler error: RTL check: expected code 'const_int', have 'reg' in gen_rotlsi3, at config/bfin/bfin.md:1616
This is with 4.4.0-RC-20090414, with --enable-checking=yes,rtl,tree . $ bfin-uclinux-gcc -S random.i In file included from /home/segher/src/kernel/include/linux/kernel.h:16, from /home/segher/src/kernel/include/linux/sched.h:53, from /home/segher/src/kernel/include/linux/utsname.h:36, from /home/segher/src/kernel/drivers/char/random.c:227: /home/segher/src/kernel/include/linux/bitops.h: In function 'mix_pool_bytes_extract': /home/segher/src/kernel/include/linux/bitops.h:55: internal compiler error: RTL check: expected code 'const_int', have 'reg' in gen_rotlsi3, at config/bfin/bfin.md:1616 -- Summary: internal compiler error: RTL check: expected code 'const_int', have 'reg' in gen_rotlsi3, at config/bfin/bfin.md:1616 Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: segher at kernel dot crashing dot org GCC host triplet: x86_64-linux GCC target triplet: bfin-uclinux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39768
[Bug target/39768] internal compiler error: RTL check: expected code 'const_int', have 'reg' in gen_rotlsi3, at config/bfin/bfin.md:1616
--- Comment #1 from segher at kernel dot crashing dot org 2009-04-14 16:15 --- Created an attachment (id=17636) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17636action=view) testcase, not minimised -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39768
[Bug c++/39763] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #5 from jason at gcc dot gnu dot org 2009-04-14 17:04 --- Subject: Bug 39763 Author: jason Date: Tue Apr 14 17:04:04 2009 New Revision: 146053 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146053 Log: PR c++/39763 * name-lookup.c (pushdecl_maybe_friend): Avoid all warnings about shadowing by tentative parms. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/warn/Wshadow-4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
[Bug c++/39763] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #6 from jason at gcc dot gnu dot org 2009-04-14 17:14 --- Subject: Bug 39763 Author: jason Date: Tue Apr 14 17:14:04 2009 New Revision: 146054 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146054 Log: PR c++/39763 * name-lookup.c (pushdecl_maybe_friend): Avoid all warnings about shadowing by tentative parms. Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/name-lookup.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/g++.dg/warn/Wshadow-4.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
[Bug testsuite/39769] New: vmx tests fail due to reliance on floating point equality
3 of the vmx tests (3a-04.c, 3a-04m.c, and 3a-05.c) fail on different powerpc machines because the test relies on the Vector 2 Raised to the Exponent Estimate and Vector Reciprocal Estimate instructions producing the exact same bit value for each machine. Since these instructions are estitmate functions, different implementations of the powerpc architecture produce different results. Floating point equality should never have been used for these tests. I have patches to change the test to see whether the value produces is accurate to 4 decimal digits using greater than and less than tests, which I will attach shortly. -- Summary: vmx tests fail due to reliance on floating point equality Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: meissner at linux dot vnet dot ibm dot com GCC build triplet: powerpc64-unknown-linux-gnu GCC host triplet: powerpc64-unknown-linux-gnu GCC target triplet: powerpc64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39769
[Bug testsuite/39769] vmx tests fail due to reliance on floating point equality
--- Comment #1 from meissner at linux dot vnet dot ibm dot com 2009-04-14 17:48 --- Created an attachment (id=17637) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17637action=view) Patch to fix the tests not to use floating point equality. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39769
[Bug c++/39763] -Wshadow reports shadowed declarations for parameters of unnamed temp objects
--- Comment #7 from jason at gcc dot gnu dot org 2009-04-14 18:54 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39763
[Bug c++/39770] New: Function template can find a struct in same namespace/other namespace but not inside a function
The following code does not compile ( error: no matching function for call to
`unnamed::A::print(main()::B) ):
#include iostream
namespace {
struct A {
templateclass C void print(C c)
{
c.print();
}
};
}
int main()
{
A a;
struct B {
void print()
{
std::cout whee!;
}
};
B b;
a.print(b);
}
However, defining B in the same namespace as A, in a different namespace, or
even in the global namespace compiles and works as expected. I don't know the
standard well enough to say if this is correct behavior, but it seems like an
odd rule.
--
Summary: Function template can find a struct in same
namespace/other namespace but not inside a function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: mlybbert at users dot sourceforge dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39770
[Bug c++/39770] Function template can find a struct in same namespace/other namespace but not inside a function
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-14 19:24 --- Local classes cannot be template arguments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39770
[Bug c++/39770] Function template can find a struct in same namespace/other namespace but not inside a function
--- Comment #2 from paolo dot carlini at oracle dot com 2009-04-14 19:26 --- Yes. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39770
[Bug middle-end/39771] New: ftrapv does not work
The following program doesn't generate a trap AFAICT, even though there is a signed overflow on a multiplication CALL FOO(100) END SUBROUTINE FOO(a) INTEGER :: a write(6,*) a*a END SUBROUTINE FOO gfortran -ftrapv test.f90 ./a.out -727379968 fails for both gcc version 4.4.0 20090414 (prerelease) [gcc-4_4-branch revision 146034] (GCC) gcc version 4.5.0 20090414 (experimental) [trunk revision 146031] (GCC) -- Summary: ftrapv does not work Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: jv244 at cam dot ac dot uk GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39771
[Bug middle-end/39771] ftrapv does not work
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-14 19:59 --- *** This bug has been marked as a duplicate of 35412 *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39771
[Bug middle-end/35412] Correctness with -ftrapv depended on libcall notes
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-14 19:59 --- *** Bug 39771 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jv244 at cam dot ac dot uk http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
[Bug target/9831] [ARM] Peephole for multiple load/store could be more effective.
--- Comment #4 from alexandre dot nunes at gmail dot com 2009-04-14 20:04 --- Created an attachment (id=17638) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17638action=view) Testcase for gcc 4.4.0 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
[Bug target/9831] [ARM] Peephole for multiple load/store could be more effective.
--- Comment #5 from alexandre dot nunes at gmail dot com 2009-04-14 20:07
---
See the attached pqp.c file.
With gcc 4.3.3, on such simplistic examples, peephole ldm and stm works:
sum:
ldr r2, .L3
ldmia r2, {r1, r3}@ phole ldm
add r3, r0, r3
add r0, r0, r1
stmia r2, {r0, r3}@ phole stm
bx lr
With gcc 4.4.0 branch, built on 20090413, it fails:
sum:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L3
ldr r2, [r3, #0]
ldr r1, [r3, #4]
add r2, r0, r2
add r1, r0, r1
str r1, [r3, #4]
str r2, [r3, #0]
bx lr
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
[Bug middle-end/35412] Correctness with -ftrapv depended on libcall notes
--- Comment #7 from jv244 at cam dot ac dot uk 2009-04-14 20:08 --- I'm reopening this report. -ftrapv is still documented, so can be expected to work by users. For the particular problem I have right now, a functional version of this option would be a great thing to have. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2008-02-29 23:33:53 |2009-04-14 20:08:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35412
[Bug target/9831] [ARM] Peephole for multiple load/store could be more effective.
--- Comment #6 from alexandre dot nunes at gmail dot com 2009-04-14 20:11
---
(In reply to comment #5)
See the attached pqp.c file.
[cut]
With gcc 4.4.0 branch, built on 20090413, it fails:
This seems to be caused by the register order allocation. If I replace the
source code lines to operate in the reverse order:
hehe.y += pqp;
hehe.x += pqp;
Then 4.4.0 20090413 generates optimized code:
ldr r3, .L3
ldmia r3, {r1, r2}@ phole ldm
add r2, r0, r2
add r1, r0, r1
stmia r3, {r1, r2}@ phole stm
bx lr
While gcc 4.3.3 does not :-) Funny thing isn't it?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9831
[Bug target/39678] complex type isn't passed correctly
--- Comment #33 from hjl at gcc dot gnu dot org 2009-04-14 20:27 --- Subject: Bug 39678 Author: hjl Date: Tue Apr 14 20:27:30 2009 New Revision: 146061 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146061 Log: gcc/ 2009-04-14 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-09 H.J. Lu hongjiu...@intel.com PR target/39678 * config/i386/i386.c (classify_argument): Handle SCmode with (bit_offset % 64) != 0. gcc/testsuite/ 2009-04-14 H.J. Lu hongjiu...@intel.com Backport from mainline: 2009-04-09 H.J. Lu hongjiu...@intel.com PR target/39678 * g++.dg/torture/pr39678.C: New. * gcc.dg/compat/struct-complex-2.h: Likewise. * gcc.dg/compat/struct-complex-2_main.c: Likewise. * gcc.dg/compat/struct-complex-2_x.c: Likewise. * gcc.dg/compat/struct-complex-2_y.c: Likewise. * gcc.dg/torture/pr39678.c: Likewise. * gcc.target/i386/pr39678.c: Likewise. * gcc.dg/compat/struct-complex-1_x.c: Add -Wno-psabi. * gcc.dg/compat/struct-complex-1_y.c: Likewise. * gcc.target/x86_64/abi/test_passing_structs.c: Include complex.h. Add tests for structure with complex float. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/torture/pr39678.C - copied unchanged from r146060, trunk/gcc/testsuite/g++.dg/torture/pr39678.C branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/compat/struct-complex-2.h - copied unchanged from r146060, trunk/gcc/testsuite/gcc.dg/compat/struct-complex-2.h branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/compat/struct-complex-2_main.c - copied unchanged from r146060, trunk/gcc/testsuite/gcc.dg/compat/struct-complex-2_main.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/compat/struct-complex-2_x.c - copied unchanged from r146060, trunk/gcc/testsuite/gcc.dg/compat/struct-complex-2_x.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/compat/struct-complex-2_y.c - copied unchanged from r146060, trunk/gcc/testsuite/gcc.dg/compat/struct-complex-2_y.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/torture/pr39678.c - copied unchanged from r146060, trunk/gcc/testsuite/gcc.dg/torture/pr39678.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/i386/pr39678.c - copied unchanged from r146060, trunk/gcc/testsuite/gcc.target/i386/pr39678.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/i386/i386.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/compat/struct-complex-1_x.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/compat/struct-complex-1_y.c branches/gcc-4_4-branch/gcc/testsuite/gcc.target/x86_64/abi/test_passing_structs.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39678
[Bug fortran/39772] New: add a correctness check for the size intrinsic to -fbounds-check
the following program INTEGER*8 :: N INTEGER, DIMENSION(:), ALLOCATABLE :: data N=2_8**32 write(6,*) N ALLOCATE(data(N)) write(6,*) SIZE(data,1) END prints 4294967296 0 It would be useful if a check for overflow of size could be added to e.g. -fbounds-check (a rather natural place I would say) so that this kind of undefined behavior could be detected at run time. I'm aware of the fact that this is fixed more fundamentally with F2003. -- Summary: add a correctness check for the size intrinsic to - fbounds-check Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran 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=39772
[Bug fortran/39772] add a correctness check for the size intrinsic to -fbounds-check
-- jv244 at cam dot ac dot uk changed: What|Removed |Added Severity|normal |enhancement http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39772
[Bug c/39773] New: error: object with variably modified type must have no linkage
new with GCC TRUNK: LANG=C /home/marcus/projects/gcc.trunk/BIN/bin/gcc -m32 -c -O2 ~/generated.i /home/marcus/generated.i: In function 'test_pack_ABC': /home/marcus/generated.i:12: error: object with variably modified type must have no linkage This built fine with previous gcc. -- Summary: error: object with variably modified type must have no linkage Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: marcus at jet dot franken dot de GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39773
[Bug target/34780] Bootstrapping libstdc++-v3 failed
--- Comment #14 from Ralf dot Wildenhues at gmx dot de 2009-04-14 21:50 --- Subject: Re: Bootstrapping libstdc++-v3 failed * dominiq at lps dot ens dot fr wrote on Sun, Apr 12, 2009 at 10:17:24AM CEST: Is comment #11 still true? No, I cannot reproduce it any more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
[Bug c++/39770] Function template can find a struct in same namespace/other namespace but not inside a function
--- Comment #3 from mlybbert at users dot sourceforge dot net 2009-04-14 21:56 --- Thank you. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39770
[Bug target/34780] Bootstrapping libstdc++-v3 failed
--- Comment #15 from dominiq at lps dot ens dot fr 2009-04-14 22:04 --- No, I cannot reproduce it any more. So I close this PR as fixed. Please reopen if the failure reappears. -- dominiq at lps dot ens dot fr changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34780
[Bug c/39773] error: object with variably modified type must have no linkage
--- Comment #1 from marcus at jet dot franken dot de 2009-04-14 22:06 --- Created an attachment (id=17639) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17639action=view) generated.i gcc -c -O2 generated.i -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39773
[Bug c/39773] error: object with variably modified type must have no linkage
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-04-14 22:08 --- (((long)(unsigned int)(((ABC *)0)-abcC)) is not a valid C90/C99 constant expression. Use the offsetof macro from stdlib.h. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39773
[Bug middle-end/38694] gcc.c-torture/compile/pr11832.c and pr33009.c -frtl-abstract-sequences ICE on arm-linux-gnueabi on 4.3.2 and trunk
--- Comment #5 from jingyu at google dot com 2009-04-14 22:35 --- I found that gcc.c-torture/compile/pr11832.c and pr33009.c were deleted from gcc trunk on 2009-03-31. 2009-03-31 Ramana Radhakrishnan ramana.radhakrish...@arm.com * gcc.c-torture/compile/pr33009.c: Delete. * gcc.c-torture/compile/pr11832.c: Likewise. However, these two files are still in gcc-4.4 branch (gcc version 4.4.0 20090414 (prerelease)). Could someone delete these two files from gcc-4.4 branch? Thanks! -- jingyu at google dot com changed: What|Removed |Added CC||jingyu at google dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38694
[Bug middle-end/38694] gcc.c-torture/compile/pr11832.c and pr33009.c -frtl-abstract-sequences ICE on arm-linux-gnueabi on 4.3.2 and trunk
--- Comment #6 from pinskia at gcc dot gnu dot org 2009-04-14 22:41 --- -frtl-abstract-sequences was removed from the trunk so closing as won't fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38694
[Bug testsuite/39769] vmx tests fail due to reliance on floating point equality
--- Comment #2 from meissner at gcc dot gnu dot org 2009-04-14 22:56 --- Subject: Bug 39769 Author: meissner Date: Tue Apr 14 22:55:52 2009 New Revision: 146068 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146068 Log: PR testsuite/39769 Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/vmx/3a-04.c trunk/gcc/testsuite/gcc.dg/vmx/3a-04m.c trunk/gcc/testsuite/gcc.dg/vmx/3a-05.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39769
[Bug testsuite/39769] vmx tests fail due to reliance on floating point equality
--- Comment #3 from meissner at gcc dot gnu dot org 2009-04-14 22:57 --- Subject: Bug 39769 Author: meissner Date: Tue Apr 14 22:56:52 2009 New Revision: 146070 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146070 Log: PR testsuite/39769 Modified: branches/ibm/power7-meissner/gcc/testsuite/ChangeLog.power7 branches/ibm/power7-meissner/gcc/testsuite/gcc.dg/vmx/3a-04.c branches/ibm/power7-meissner/gcc/testsuite/gcc.dg/vmx/3a-04m.c branches/ibm/power7-meissner/gcc/testsuite/gcc.dg/vmx/3a-05.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39769
[Bug testsuite/39769] vmx tests fail due to reliance on floating point equality
--- Comment #4 from meissner at gcc dot gnu dot org 2009-04-14 22:58 --- Subject: Bug 39769 Author: meissner Date: Tue Apr 14 22:57:51 2009 New Revision: 146071 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=146071 Log: PR testsuite/39769 Modified: branches/ibm/gcc-4_3-branch/gcc/testsuite/ChangeLog branches/ibm/gcc-4_3-branch/gcc/testsuite/gcc.dg/vmx/3a-04.c branches/ibm/gcc-4_3-branch/gcc/testsuite/gcc.dg/vmx/3a-04m.c branches/ibm/gcc-4_3-branch/gcc/testsuite/gcc.dg/vmx/3a-05.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39769
[Bug testsuite/39774] New: New: FAIL: g++/g++.dg-struct-layout-1//t004_x.C on arm target
The toolchain is built with newlib C.
2 g++ failures in dejaGNU tests:
FAIL tmpdir-g++.dg-struct-layout-1/t004 cp_compat_x_tst.o compile
FAIL tmpdir-g++.dg-struct-layout-1/t004 cp_compat_y_tst.o compile
Compiler error:
In file included from
/usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-trunk/gcc/testsuite/g++/g++.dg-struct-layout-1//t004_x.C:9:
/usr/local/google/tmp/gcc4.4_dejagnu/obj/gcc-trunk/gcc/testsuite/g++/g++.dg-struct-layout-1//t004_test.h:6:
note: Offset of packed bit-field 'S805::c' has changed in GCC 4.4
enum E3 c:8 in t004_test.h is causing this dejagnu compiler error.
According to the GCC 4.4 Changes
(http://www.gnu.org/software/gcc/gcc-4.4/changes.html),
the behaviors related to bit-packed of type 'char' are changed on some targets
(e.g. ARM).
This results in warnings like note: Offset of packed bit-field XXX has changed
in GCC 4.4.
Details from the GCC 4.4 Changes document: Packed bit-fields of type char were
not properly bit-packed on many targets prior to GCC 4.4. On these targets, the
fix in GCC 4.4 causes an ABI change. For example there is no longer a 4-bit
padding between field a and b in this structure:
struct foo
{
char a:4;
char b:8;
} __attribute__ ((packed));
There is a new warning to help identify fields that are affected:
foo.c:5: note: Offset of packed bit-field 'b' has changed in GCC 4.4
Suggested Fix: Add '// { dg-warning Offset of packed bit-field { target
arm-*-*-* } }' to this test.
Note that these two tests SUCCESSFULLY PASSED on x86 without causing any error
in the log. So we just want to fix on the arm side.
--
Summary: New: FAIL: g++/g++.dg-struct-layout-1//t004_x.C on arm
target
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sliao at google dot com
GCC build triplet: i686-linux-gnu
GCC host triplet: i686-linux-gnu
GCC target triplet: arm-unknown-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39774
[Bug fortran/39587] Reading integer from gives end-of-file instead of reading a 0
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2009-04-15 02:16 --- Without trying it. Your example is not a zero length file. You have written at least a LF or CR-LF. I am not convinced yet. I just want to know the basis. Is this standard conforming or is it an extension? Is it consistent? I have not add any time lately to look at anything in detail. The overwhelming majority is obviously a clue. (Or is it?) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39587
[Bug target/39758] FAIL: gcc.dg/initpri1.c, g++.dg/special/initpri1.C on arm target
--- Comment #1 from jingyu at google dot com 2009-04-15 03:44 --- Created an attachment (id=17640) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17640action=view) assembly of gcc.dg/initpri1.c This assembly was generated by this command: $arm-eabi-gcc gcc.dg/initpri1.c -S -o initpri1.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39758
[Bug target/39758] FAIL: gcc.dg/initpri1.c, g++.dg/special/initpri1.C on arm target
--- Comment #2 from jingyu at google dot com 2009-04-15 03:45 --- $arm-eabi-gcc -v Using built-in specs. Target: arm-eabi Configured with: /usr/local/google/nightly/sources/arm_toolchain/gcc-4.4/configure --prefix=/usr/local/google/tmp/gcc4.4_dejagnu/install --target=arm-eabi --build=x86_64-linux-gnu --host=x86_64-linux-gnu --with-gmp=/usr/local/google/tmp/gcc4.4_dejagnu/install --with-mpfr=/usr/local/google/tmp/gcc4.4_dejagnu/install --enable-multilib --with-newlib --with-gnu-as --with-gnu-ld --enable-languages=c,c++ Thread model: single gcc version 4.4.0 20090414 (prerelease) (GCC) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39758
[Bug target/39767] libgcc2.c:562: internal compiler error: RTL check: expected code 'reg', have 'ashiftrt' in rhs_regno, at rtl.h:1005
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-04-15 04:46 --- I'd like to add Jakub to the CC list because it's a build failure on 4.4.0-rc1 anyway, though I don't think this is a blocker. sh64 targets maybe not even tertiary. The patch below will fix the problem. Jakub, please ignore this if there are no other issues on 4.4.0-rc1. --- trunk/gcc/config/sh/predicates.md~ 2009-04-05 21:43:22.0 +0900 +++ trunk/gcc/config/sh/predicates.md 2009-04-15 12:20:18.0 +0900 @@ -112,6 +112,7 @@ || satisfies_constraint_Css (op)) return 1; else if (GET_CODE (op) == TRUNCATE + GET_CODE (XEXP (op, 0)) == REG ! system_reg_operand (XEXP (op, 0), VOIDmode) (mode == VOIDmode || mode == GET_MODE (op)) (GET_MODE_SIZE (GET_MODE (op)) -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org, jakub at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2009-04-15 04:46:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39767
[Bug libgomp/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
--- Comment #7 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-15 05:07 --- Subject: Re: [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above Attached .i. Dave --- Comment #8 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-15 05:07 --- Created an attachment (id=17641) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17641action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39746
[Bug middle-end/39764] ICE in set_lattice_value, at tree-ssa-ccp.c:468 with -ffinite-math-only
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-04-15 05:14 --- NaN requires -mieee for SH target and you could avoid the ICE with -mieee or -fno-finite-math-only. Although the test case doesn't make much sense for this target without these options, the ICE might show the compiler problem anyway. I've confirmed that the provided test fails similarly with -O -ffinite-math-only also for i686-pc-linux-gnu on the trunk. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added CC||kkojima at gcc dot gnu dot ||org GCC target triplet|sh4-unknown-linux-gnu | Keywords||ice-on-valid-code Summary|ICE in set_lattice_value, at|ICE in set_lattice_value, at |tree-ssa-ccp.c:468 |tree-ssa-ccp.c:468 with - ||ffinite-math-only http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39764
