[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #22 from ubizjak at gmail dot com 2009-11-10 07:45 --- (In reply to comment #20) > Yes K6 is the best fallback for geode-lx, while pentium-mmx is the best one > for > geode. BTW, recommended fallback is K6-2. > I need to know if this new -march argument will be added so I edit the kernel > patch. Actually, according to gcc documentation, "-march=geode" is intended specifically for geode-lx and switches on features and tuning options for geode-lx. If you want to play with tuning options, you can check differences between m_PPRO and m_GEODE in i386.c, ix86_tune_features. By changing these settings, you can narrow down which flag causes a regression. I would suggest to start with flags that mention partial register stalls. OTOH, you can also play with "-march=geode, -mtune=i686" to switch on various tuning flags. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #7 from ghazi at gcc dot gnu dot org 2009-11-10 05:56 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2009-11/msg00488.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug debug/40599] [4.5 regression] GCC error in pre_and_rev_post_order_compute, at cfganal.c:1045
--- Comment #12 from oliver dot kellogg at eads dot com 2009-11-10 05:38 --- > Does this still happen with current trunk, esp. after the EH rewrite? Does not happen with trunk r154034. Thanks. -- oliver dot kellogg at eads dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599
[Bug libstdc++/41861] [C++0x] does not use monotonic_clock
--- Comment #6 from aaron at aarongraham dot com 2009-11-10 04:38 --- So it appears that the problem is gthreads. The monotonic_clock support is purely superficial in gcc until gthreads supports such a concept. Developers will need to create their own clock and modify the standard library headers to use it should they require a reasonable level of reliability in the face of a possibly-changing system clock. But I think the Howard/Detlef debate is a separate issue. I believe they have determined that a condition_variable (and mutex) must continue to use a specific clock once the object is created, and to sync all given time points to that clock, and are arguing over whether or not that is implementable. No big deal. I just don't believe there is any particular requirement that it be the system_clock (and, if there were, I would think that to be a big mistake). In almost every project I've worked on, our purposes would be much better served if a monotonic_clock were used instead. Rarely do we care what the epoch is. What we do care about is timer reliability even when NTP (or some other mechanism) is changing the clock. But that's just my experience. Thanks for looking into this. I'm hoping for a resolution that doesn't make and all but useless as provided by the standard library sans modification. The boost team has already made some egregious mistakes in this area. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41861
[Bug c++/36406] [4.3/4.4/4.5 regression] ICE with template delete operator
-- 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|NEW |ASSIGNED Last reconfirmed|2009-09-20 20:23:25 |2009-11-10 03:47:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36406
[Bug c++/34158] Template delete doesn't call if exception thrown in constructor
-- 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 Keywords||wrong-code Last reconfirmed|-00-00 00:00:00 |2009-11-10 03:47:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34158
[Bug bootstrap/40968] [4.5 Regression] ICE when compiling O2g.gch; problem with --enable-gather-detailed-mem-stats
--- Comment #4 from lucier at math dot purdue dot edu 2009-11-10 00:28 --- This is fixed, at least by the time of gcc version 4.5.0 20091109 (experimental) [trunk revision 154037] (GCC) -- lucier at math dot purdue dot edu changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40968
[Bug c++/41997] [C++0x] constant initializer_list not optimised
--- Comment #1 from paolo dot carlini at oracle dot com 2009-11-09 23:47 --- Let's CC Jason about this... -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu dot org Summary|constant initializer_list |[C++0x] constant |not optimised |initializer_list not ||optimised http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41997
[Bug c++/41997] New: constant initializer_list not optimised
In C++0x, constant initializer_lists do not seem visible to the optimiser,
leading to sub-optimal code. Consider as a simple example:
#include
int max_val(std::initializer_list il)
{
int i = *(il.begin());
int j = *(il.begin() + 1);
return (i > j ? i : j);
}
int main(void)
{
return max_val({1,2});
}
I would expect 'main' to be reduced to just '2' at a suitable optimisation
level. At -O3 the body max_val is inlined the values {1,2} are not. Is there
some reason constant initalizer_lists cannot be made visible to optimisation?
--
Summary: constant initializer_list not optimised
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: chris at bubblescope dot net
GCC host triplet: i686-apple-darwin10
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41997
[Bug c++/41090] [4.3/4.4/4.5 Regression] Using static label reference in c++ class constructor produces wrong code
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-09 22:43 --- Yeah, there's no way to get this right in general with our unconditional cloning. -- jason at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||3187 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41090
[Bug rtl-optimization/9085] Unable to find register to spill when optimizing
--- Comment #12 from reichelt at gcc dot gnu dot org 2009-11-09 22:13 --- The testcase from comment #7 doesn't crash since GCC 4.0.0. The testcase from comment #4 stopped crashing in August or September, so let's close the bug for good. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9085
[Bug c++/41972] [4.3/4.4/4.5 Regression] nondependent static member function as a reference template parameter fails
--- Comment #7 from jason at gcc dot gnu dot org 2009-11-09 22:02 --- 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=41972
[Bug c++/41972] [4.3/4.4/4.5 Regression] nondependent static member function as a reference template parameter fails
--- Comment #6 from jason at gcc dot gnu dot org 2009-11-09 22:01 --- Subject: Bug 41972 Author: jason Date: Mon Nov 9 22:01:09 2009 New Revision: 154053 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154053 Log: PR c++/41972 * parser.c (cp_parser_template_argument): Accept SCOPE_REF around VAR_DECL. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/template/ref4.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/parser.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41972
[Bug tree-optimization/40140] [4.5 Regression] ICE with -ftree-parallelize-loops
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-11-09 21:59 --- The second testcase stopped crashing in August or September. Because the first testcase stopped crashing although the bug wasn't really fixed, I thought it would maybe pop up again. But apparently it didn't. So let's close the bug for good. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40140
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #21 from rootkit85 at yahoo dot it 2009-11-09 21:59 --- Created an attachment (id=19001) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19001&action=view) A patch which adds Geode LX support to GCC -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/37093] [4.2/4.3 Regression] ICE with pointer to member template parameters
--- Comment #27 from reichelt at gcc dot gnu dot org 2009-11-09 21:54 --- After the reversion of the patch for on the 4.3 branch, it is only fixed for GCC 4.4.3 and later. But let's keep it closed since this is just an ice-on-invalid-code bug. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.5 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37093
[Bug c++/41994] [4.4/4.5 Regression] ICE with &A::operator T
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-11-09 21:43 --- Fixed for GCC 4.4.3. Thanks, Jason! -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
[Bug c++/38699] [4.3/4.4/4.5 regression] ICE using offsetof with pointer and array accesses
--- Comment #15 from reichelt at gcc dot gnu dot org 2009-11-09 21:42 --- The bug is not a regression, because the code snippet is invalid and was never correctly rejected since the introduction of __builtin_offsetof. Since it's fixed now we can close it. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|4.3.5 |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38699
[Bug c++/41972] [4.3/4.4/4.5 Regression] nondependent static member function as a reference template parameter fails
--- Comment #5 from jason at gcc dot gnu dot org 2009-11-09 20:28 --- Subject: Bug 41972 Author: jason Date: Mon Nov 9 20:28:18 2009 New Revision: 154050 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154050 Log: PR c++/41972 * parser.c (cp_parser_template_argument): Accept SCOPE_REF around VAR_DECL. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/ref4.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/parser.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41972
[Bug c++/41994] [4.4/4.5 Regression] ICE with &A::operator T
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-09 20:28 --- Subject: Bug 41994 Author: jason Date: Mon Nov 9 20:28:11 2009 New Revision: 154049 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154049 Log: PR c++/41994 * pt.c (tsubst_baselink): tsubst the name. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/conv10.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/pt.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #20 from rootkit85 at yahoo dot it 2009-11-09 20:25 --- Yes K6 is the best fallback for geode-lx, while pentium-mmx is the best one for geode. I need to know if this new -march argument will be added so I edit the kernel patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug middle-end/41963] [4.5 Regression] 177.mesa in SPEC CPU 2K is miscompiled
--- Comment #9 from pinskia at gcc dot gnu dot org 2009-11-09 19:45 --- Fixed so closing. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41963
[Bug middle-end/40946] [4.3 Regression] Spurious array subscript is above bounds warning
--- Comment #5 from jakub at gcc dot gnu dot org 2009-11-09 19:44 --- Fixed on the trunk and 4.4 branch. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Summary|[4.3/4.4/4.5 Regression]|[4.3 Regression] Spurious |Spurious array subscript is |array subscript is above |above bounds warning|bounds warning http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40946
[Bug middle-end/40946] [4.3/4.4/4.5 Regression] Spurious array subscript is above bounds warning
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-09 19:41 --- Subject: Bug 40946 Author: jakub Date: Mon Nov 9 19:40:56 2009 New Revision: 154047 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154047 Log: PR middle-end/40946 * gcc.dg/pr40946.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr40946.c Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40946
[Bug middle-end/41317] folding causes strict aliasing violation
--- Comment #5 from jakub at gcc dot gnu dot org 2009-11-09 19:38 --- Subject: Bug 41317 Author: jakub Date: Mon Nov 9 19:38:29 2009 New Revision: 154046 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154046 Log: PR middle-end/40946 Backport from mainline 2009-09-09 Richard Guenther PR middle-end/41317 * tree-ssa-ccp.c (maybe_fold_offset_to_component_ref): Remove code dealing with plain pointer bases. (maybe_fold_offset_to_reference): Likewise. (maybe_fold_stmt_addition): Adjust. PR middle-end/40946 * gcc.dg/pr40946.c: New test. Backport from mainline 2009-09-09 Richard Guenther PR middle-end/41317 * gcc.c-torture/execute/pr41317.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41317.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40946.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41317
[Bug middle-end/40946] [4.3/4.4/4.5 Regression] Spurious array subscript is above bounds warning
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-09 19:38 --- Subject: Bug 40946 Author: jakub Date: Mon Nov 9 19:38:29 2009 New Revision: 154046 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154046 Log: PR middle-end/40946 Backport from mainline 2009-09-09 Richard Guenther PR middle-end/41317 * tree-ssa-ccp.c (maybe_fold_offset_to_component_ref): Remove code dealing with plain pointer bases. (maybe_fold_offset_to_reference): Likewise. (maybe_fold_stmt_addition): Adjust. PR middle-end/40946 * gcc.dg/pr40946.c: New test. Backport from mainline 2009-09-09 Richard Guenther PR middle-end/41317 * gcc.c-torture/execute/pr41317.c: New testcase. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.c-torture/execute/pr41317.c branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/pr40946.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40946
[Bug debug/41679] [4.5 Regression] internal compiler error: in loc_cmp, at var-tracking.c:2433
--- Comment #4 from jakub at gcc dot gnu dot org 2009-11-09 18:42 ---
For:
(insn 78 77 16 2 rh528639.i:12 (cond_exec (eq (reg:CC 24 cc)
(const_int 0 [0x0]))
(set (reg:SI 0 r0 [orig:133 iftmp.0 ] [133])
(reg:SI 4 r4))) 2367 {neon_vornv2di+77} (expr_list:REG_DEAD (reg:CC
24 cc)
(nil)))
we have MO_VAL_SET with
(concat/v (concat:SI (value/s/u:SI 23753 @0x121b8f0/0x11da460)
(reg:SI 0 r0 [orig:133 iftmp.0 ] [133]))
(set (reg:QI 0 r0 [ iftmp.0 ])
(reg:QI 4 r4)))
The QImode comes from the realdecl being tracked being actually QImode, so
var_lowpart is called on the SET_SRC. VAL_NEEDS_RESOLUTION is true, so
val_resolve (out, val, SET_SRC (uloc), insn); is called which sets a QImode r4
as one of the locations for the VALUE:SI 23753. Then
5309 val_store (out, val, vloc, insn);
is called, and vloc here is SImode, so we have non-matching modes. Not sure
where the bug is, maybe vloc should be QImode as well in that case and
var_lowpart wasn't being called somewhere...
BTW, I wonder how well var-tracking.c handles COND_EXEC, I don't see it ever
mentioned in var-tracking.c, so I assume it handles all the stores as
unconditional.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug c++/41972] [4.3/4.4/4.5 Regression] nondependent static member function as a reference template parameter fails
--- Comment #4 from jason at gcc dot gnu dot org 2009-11-09 18:33 --- Subject: Bug 41972 Author: jason Date: Mon Nov 9 18:32:53 2009 New Revision: 154042 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154042 Log: PR c++/41972 * parser.c (cp_parser_template_argument): Accept SCOPE_REF around VAR_DECL. Added: trunk/gcc/testsuite/g++.dg/template/ref4.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41972
[Bug c++/41994] [4.4/4.5 Regression] ICE with &A::operator T
--- Comment #3 from jason at gcc dot gnu dot org 2009-11-09 18:32 --- Subject: Bug 41994 Author: jason Date: Mon Nov 9 18:32:44 2009 New Revision: 154041 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154041 Log: PR c++/41994 * pt.c (tsubst_baselink): tsubst the name. Added: trunk/gcc/testsuite/g++.dg/template/conv10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #19 from ubizjak at gmail dot com 2009-11-09 18:16 --- (In reply to comment #18) > As I did here? > > http://patchwork.kernel.org/patch/51410/ Yes, but I don't know if perhaps -march=k6-2 should be used as a fallback, as suggested in [1]. BTW: You can change optimization bitmasks and cost tables in gcc/config/i386.c to find out what effects runtime performace, but without access to a target processor, there is no way to resolve runtime regressions. [1] http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD#Geode_LX -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|ubizjak at gmail dot com|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|UNCONFIRMED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #10 from navinkumar+bugs at gmail dot com 2009-11-09 18:08 --- After review, I agree it is not a bug. Because _0_emptyB and _2_emptyB both inherent from empty_t, the compiler is obligated to ensure that static_cast(static_cast<_0_emptyB*>(compositeB2)) != static_cast(static_cast<_2_emptyB*>(compositeB2)). The zero-size base class optimization doesn't apply when the grandparent empty class is repeated. -- navinkumar+bugs at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #6 from ghazi at gcc dot gnu dot org 2009-11-09 17:56 ---
The bug is not latent and also it is not in GCC code related MPC. It lies in
the tree-based fallback code I wrote to handle complex division when MPC is not
used. This code will still persist even after the switch to MPC. E.g. I can
trigger it from a C testcase using "_Complex int" and this scenario will remain
after the cutover. I.e. the C testcase below crashes both with and without
MPC.
As for why the fortran testcase passes with MPC, I guess that it gets folded in
the fortran frontend, thus it's masked and the middle-end never sees it. I
believe I know what's wrong in fold and I'm working on a fix.
void qparm_colvar(void)
{
_Complex int ylm;
int nbond;
ylm = 0;
nbond = 0;
ylm = ylm / nbond;
}
--
ghazi at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ghazi at gcc dot gnu dot org
|dot org |
Status|UNCONFIRMED |ASSIGNED
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2009-11-09 17:56:11
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #9 from paolo dot carlini at oracle dot com 2009-11-09 17:51 --- For the record, the Intel compiler, also implementing the IA64 C++ ABI, behaves exactly the same as GCC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #8 from navinkumar+bugs at gmail dot com 2009-11-09 17:39 --- Created an attachment (id=19000) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19000&action=view) demonstrates scenarios when zero-size base class optimization fails, compile with flag: -std=c++0x -- navinkumar+bugs at gmail dot com changed: What|Removed |Added Attachment #18986|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug debug/41679] [4.5 Regression] internal compiler error: in loc_cmp, at var-tracking.c:2433
-- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Component|c |debug GCC build triplet|armv5tel-unknown-linux- | |gnueabi | GCC host triplet|armv5tel-unknown-linux- | |gnueabi | Keywords||ice-on-valid-code Target Milestone|--- |4.5.0 Version|4.4.1 |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug c/41679] internal compiler error: in loc_cmp, at var-tracking.c:2433
--- Comment #3 from jakub at gcc dot gnu dot org 2009-11-09 17:36 ---
/* { dg-do compile } */
/* { dg-options "-march=armv5te -g -O2" } */
extern int a;
extern char b;
extern int foo (void);
void
test (void)
{
int c;
b = foo () ? '~' : '\0';
while ((c = foo ()))
if (c == '7')
a = 0;
}
fails on the current trunk the same way, at least in the x86_64-linux ->
armv5tel-unknown-linux-gnueabi cross.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41679
[Bug c++/39981] zero-size base class optimization fails in certain scenarios
--- Comment #7 from navinkumar+bugs at gmail dot com 2009-11-09 17:35
---
(From update of attachment 18986)
>#include
>#include
>#include
>#include
>
>struct empty_t {
> template
> explicit empty_t(Arg arg) { }
>};
>
>template
>struct EmptyWrapperA {
> template
> explicit EmptyWrapperA(Arg arg) { }
> static_assert(std::is_empty::value, "sanity check");
>};
>
>template
>struct EmptyWrapperB : T {
> template
> explicit EmptyWrapperB(Arg arg) : T(arg) { }
> static_assert(std::is_empty::value, "sanity check");
>};
>
>template
>struct Member {
> T m_value;
> template
> explicit Member(Arg arg) : m_value(arg) { }
>};
>
>typedef EmptyWrapperA<0,empty_t> _0_emptyA; typedef EmptyWrapperB<0,empty_t>
>_0_emptyB;
>typedef Member<1,int> _1_member;
>typedef EmptyWrapperA<2,empty_t> _2_emptyA; typedef EmptyWrapperB<2,empty_t>
>_2_emptyB;
>
>static_assert(std::is_empty<_0_emptyA>::value, "sanity check");
>static_assert(std::is_empty<_0_emptyB>::value, "sanity check");
>static_assert(std::is_empty<_2_emptyA>::value, "sanity check");
>static_assert(std::is_empty<_2_emptyB>::value, "sanity check");
>class compositeA1 : _0_emptyA, _1_member, _2_emptyA { };
>class compositeA2 : _0_emptyA, _1_member { };
>class compositeB1 : _0_emptyB, _1_member { };
>class compositeB2 : _0_emptyB, _1_member, _2_emptyB { };
>class compositeB3 : _1_member, _2_emptyB { };
>
>int main(int argc, char** argv) {
> // output *should* be 4 since "int" is the only data member
> // something is wrong with GCC's zero-size base class optimization for
> compositeB1
> std::cout << "sizeA1: " << sizeof(compositeA1) << std::endl; // outputs
> 4
> std::cout << "sizeA2: " << sizeof(compositeA2) << std::endl; // outputs
> 4
> std::cout << "sizeB1: " << sizeof(compositeB1) << std::endl; // outputs
> 4
> std::cout << "sizeB2: " << sizeof(compositeB2) << std::endl; // outputs
> 8
> std::cout << "sizeB3: " << sizeof(compositeB3) << std::endl; // outputs
> 4
> return 0;
>}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39981
[Bug tree-optimization/41905] [4.5 Regression] ICE with __attribute__((noreturn))
--- Comment #2 from jason at gcc dot gnu dot org 2009-11-09 17:18 --- This is happening because in C++ mode the body of bar looks like D.1729 = foo (); D.1728 = D.1729; whereas in the C front end it looks like D.1986 = foo (); and so gimple_seq_may_fallthru says that the body can fall through in the first case, even though the first statement cannot fall through. This difference seems to be because the INIT_EXPR within the RETURN_EXPR is initializing a temporary in C++ vs. the RESULT_DECL in C. I'm not sure where we ought to be pruning the dead assignment to D.1728, but it doesn't seem like the front end's job. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Component|c++ |tree-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41905
[Bug bootstrap/41996] New: lto-elf.c fails to compile on IRIX 6.5
Current mainline as of 20091106 fails to compile on IRIX 6.5: /vol/gcc/src/gcc-dist/gcc/lto/lto-elf.c: In function 'lto_elf_file_open': /vol/gcc/src/gcc-dist/gcc/lto/lto-elf.c:561:28: error: expected ')' before 'PRId64' cc1: warnings being treated as errors /vol/gcc/src/gcc-dist/gcc/lto/lto-elf.c:561:28: error: spurious trailing '%' in format make[3]: *** [lto/lto-elf.o] Error 1 This was introduced by this patch: 2009-11-04 Richard Guenther Rafael Avila de Espindola * lto-elf.c (lto_elf_build_section_table): Add the base offset. (lto_elf_file_open): Handle offsets in arguments n...@offest. This happens because IRIX 6.5 provides the PRI* macros only in C99 mode, i.e. with -std=c99. Perhaps one could use both the config/inttypes-pri.m4 autoconf test and the code in intl/loadmsgcat.c to work around this? -- Summary: lto-elf.c fails to compile on IRIX 6.5 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: mips-sgi-irix6.5 GCC host triplet: mips-sgi-irix6.5 GCC target triplet: mips-sgi-irix6.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41996
[Bug ada/41912] FAIL: gnat.dg/null_pointer_deref1.adb execution test
--- Comment #2 from ebotcazou at gcc dot gnu dot org 2009-11-09 17:11 --- I see that it fails on HP-UX as well. That's probably because there is something missing in the fallback routines in config/pa, namely: fs->signal_frame = 1; just before return _URC_NO_REASON; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41912
[Bug c++/41995] Incorrect point of instantiation for function template
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-11-09 16:00 --- Actually this is a combition of two issues really. First is argument dependent lookup for fundamental types, do they have an assoicated namespaces (I think there is a bug report for that)? And then the other bug is the wrong place: PR 16635. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995
[Bug middle-end/41290] [4.5 regression] ICE: edge points to wrong declaration
--- Comment #10 from rguenth at gcc dot gnu dot org 2009-11-09 15:55 --- Confirmed. It passes if I add -fno-ipa-cp, maybe martin can have a look. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mjambor at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
[Bug middle-end/40946] [4.3/4.4/4.5 Regression] Spurious array subscript is above bounds warning
--- Comment #2 from rguenther at suse dot de 2009-11-09 15:51 --- Subject: Re: [4.3/4.4/4.5 Regression] Spurious array subscript is above bounds warning On Mon, 9 Nov 2009, jakub at gcc dot gnu dot org wrote: > --- Comment #1 from jakub at gcc dot gnu dot org 2009-11-09 15:47 --- > This got fixed on the trunk with PR41317 and on the 4.4 branch also works well > with the backport of that patch (which I'm using for roughly a month on > redhat/gcc-4_4-branch because it cured some __builtin_object_size issues too). > I think we should just backport PR41317 patch to 4.4 branch and add this > testcase to trunk/4.4. Richi, is that ok with you? Ok with me - it's a wrong-code fix anyway (I just didn't do it because it might affect code generation quality in subtle ways without the new oracle). So I was waiting for a "real" testcase. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40946
[Bug middle-end/40946] [4.3/4.4/4.5 Regression] Spurious array subscript is above bounds warning
--- Comment #1 from jakub at gcc dot gnu dot org 2009-11-09 15:47 --- This got fixed on the trunk with PR41317 and on the 4.4 branch also works well with the backport of that patch (which I'm using for roughly a month on redhat/gcc-4_4-branch because it cured some __builtin_object_size issues too). I think we should just backport PR41317 patch to 4.4 branch and add this testcase to trunk/4.4. Richi, is that ok with you? -- jakub 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=40946
[Bug c++/41972] [4.3/4.4/4.5 Regression] nondependent static member function as a reference template parameter fails
-- 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|NEW |ASSIGNED Last reconfirmed|2009-11-06 17:22:18 |2009-11-09 15:27:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41972
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #18 from rootkit85 at yahoo dot it 2009-11-09 15:26 --- As I did here? http://patchwork.kernel.org/patch/51410/ -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug middle-end/41290] [4.5 regression] C++ - libdirac don't want to compile
--- Comment #9 from reichelt at gcc dot gnu dot org 2009-11-09 15:19 --- Created an attachment (id=18999) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18999&action=view) Pre-processed version of previous testcase -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
[Bug middle-end/41290] [4.5 regression] C++ - libdirac don't want to compile
--- Comment #8 from reichelt at gcc dot gnu dot org 2009-11-09 15:16 --- Created an attachment (id=18998) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18998&action=view) Self-contained testcase that crashes with "-O3 -m32" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
[Bug middle-end/41290] [4.5 regression] C++ - libdirac don't want to compile
--- Comment #7 from reichelt at gcc dot gnu dot org 2009-11-09 15:15 --- Unfortunately the problem still persists, see following testcase which crashes in the same fashion when compiled with "-O3 -m32" on x86_64-unknown-linux-gnu. -- reichelt at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #17 from ubizjak at gmail dot com 2009-11-09 15:10 --- (In reply to comment #16) > Yes, it seems that even old Geode has such instructions: So, I guess they should be listed under in linux-2.6/arch/x86/Kconfig.cpu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/41994] [4.4/4.5 Regression] ICE with &A::operator T
-- 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|NEW |ASSIGNED Last reconfirmed|2009-11-09 10:18:39 |2009-11-09 15:06:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
[Bug tree-optimization/41957] [4.4/4.5 Regression] ICE with -ftree-loop-linear in initialize_matrix_A, at tree-data-ref.c:1912
--- Comment #4 from rguenth at gcc dot gnu dot org 2009-11-09 13:59 ---
Indeed. Same symptoms at least:
(gdb) call debug_generic_expr (chrec)
{0, +, {2, +, 1}_4}_4
This one fails for me with -m32 only though.
The chrec isn't quite {2, +, 1}_4 - I think the IV evolves as 0, 3, 4, 5, 6,
...
if I parse it correctly. That looks more like a loop like
for (i=0;; ++i)
for (j=i+3;; ++j)
...
where we somehow cleverly analyze this as a single loop... (?).
Sebastian - please have a look here and/or at PR40281.
*** This bug has been marked as a duplicate of 40281 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
GCC target triplet|x86*-unknown-linux-gnu |i?86-unknown-linux-gnu
Resolution||DUPLICATE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41957
[Bug middle-end/40281] [4.4/4.5 Regression] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-09 13:59 --- *** Bug 41957 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
[Bug middle-end/41290] [4.5 regression] C++ - libdirac don't want to compile
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-11-09 13:51 --- Seems to be fixed with current trunk. Please open if it is not. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41290
[Bug debug/40599] [4.5 regression] GCC error in pre_and_rev_post_order_compute, at cfganal.c:1045
--- Comment #11 from rguenth at gcc dot gnu dot org 2009-11-09 13:49 --- Does this still happen with current trunk, esp. after the EH rewrite? -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40599
[Bug middle-end/40281] [4.4/4.5 Regression] -fprefetch-loop-arrays: ICE: in initialize_matrix_A, at tree-data-ref.c:1887
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-09 13:48 ---
Hm.
(gdb) call debug_generic_expr (chrec)
{{1, +, {2, +, 1}_2}_1, +, 1}_2
how can this happen? Why does evolution_function_is_affine_multivariate_p
not reject this chrec?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Last reconfirmed|2009-09-28 20:52:51 |2009-11-09 13:48:47
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40281
[Bug libffi/35484] libffi doesn't support AIX 64bit
--- Comment #4 from shailen dot n dot jain at gmail dot com 2009-11-09 13:47 --- (In reply to comment #1) > Created an attachment (id=15274) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15274&action=view) [edit] > Add AIX 64bit support > I was trying to compile Mozilla Firefox latest build ( 3.7 a1pre) on AIX 64-bit. But I got a compiler/linker error while building libffi module ( https://bugzilla.mozilla.org/show_bug.cgi?id=527410 ). I tried applying this patch, but this did not resolve the linker error - undefined symbol .ffi_closure_helper_DARWIN. Adding the below lines in aix_closure.S did resolve the 'undefined symbol error - .ffi_closure_helper_DARWIN' # .text section .extern .ffi_closure_helper_DARWIN -- shailen dot n dot jain at gmail dot com changed: What|Removed |Added CC||shailen dot n dot jain at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35484
[Bug tree-optimization/40140] [4.5 Regression] ICE with -ftree-parallelize-loops
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-11-09 13:44 --- Neither testcase crashes for me anymore (x86-64, with and without -m32). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40140
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #16 from rootkit85 at yahoo dot it 2009-11-09 13:17 --- Yes, it seems that even old Geode has such instructions: # cat /proc/cpuinfo processor : 0 vendor_id : Geode by NSC cpu family : 5 model : 9 model name : Unknown stepping: 1 cpu MHz : 266.688 fdiv_bug: no hlt_bug : no f00f_bug: no coma_bug: no fpu : yes fpu_exception : yes cpuid level : 2 wp : yes flags : fpu tsc msr cx8 cmov mmx cxmmx bogomips: 534.07 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug middle-end/41992] ICE on invalid dereferencing of void *
--- Comment #2 from joseph at codesourcery dot com 2009-11-09 13:16 --- Subject: Re: ICE on invalid dereferencing of void * On Mon, 9 Nov 2009, rguenth at gcc dot gnu dot org wrote: > the C standard doesn't claim dereferencing a void pointer is invalid, so > the gimplifier should deal with this. It's not invalid in general, but if the value gets used (NB conditional expressions involving such dereferences, whose values don't get used, are OK; DR 106) then it is invalid and there should be an error; "void value not ignored as it ought to be" is used in some places. Though I note that if you change the dereference in the present testcase to use the return value of a function returning void, the resulting error "using result of function returning 'void'" comes from the gimplifier and not the front end, so making the gimplifier deal with this case as well would at least be consistent. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41992
[Bug c++/41994] [4.4/4.5 Regression] ICE with &A::operator T
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
[Bug middle-end/41963] [4.5 Regression] 177.mesa in SPEC CPU 2K is miscompiled
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41963
[Bug tree-optimization/41957] [4.4/4.5 Regression] ICE with -ftree-loop-linear in initialize_matrix_A, at tree-data-ref.c:1912
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41957
[Bug middle-end/41930] [4.5 regression] cc1 SEGV compiling maxval_r16.c
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41930
[Bug debug/41926] [4.5 Regression][VTA] internal compiler error: verify_ssa failed
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41926
[Bug c++/41906] [4.5 Regression] ICE with catch(...) and -fpermissive
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41906
[Bug c++/41905] [4.5 Regression] ICE with __attribute__((noreturn))
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41905
[Bug middle-end/41889] [4.5 Regression] ICE from '-O2 -fno-omit-frame-pointer -ftracer -fsched2-use-superblocks'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41889
[Bug debug/41888] [4.5 Regression] ICE from '-O -ftree-loop-distribution -fgraphite-identity -g'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41888
[Bug debug/41886] [4.5 Regression] ICE from '-O -ftree-loop-distribution -ftree-vectorize -g'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41886
[Bug middle-end/41883] [4.5 Regression] ICE from '-O -fprofile-arcs -fsched2-use-superblocks -ftree-vrp -fschedule-insns2 -freorder-blocks'
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41883
[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P2 Last reconfirmed|-00-00 00:00:00 |2009-11-09 13:03:36 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41879
[Bug middle-end/41674] [4.5 Regression] /usr/ccs/bin/ld: Unsatisfied symbols: _GLOBAL__I_65535_0_main
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-09 13:03:16 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41674
[Bug rtl-optimization/41619] [4.4/4.5 regression] ICE in insert_save (caller-save.c) for SPEC CPU2000's 252.eon
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41619
[Bug bootstrap/41491] [4.5 regression] ICE in set_value_range, at tree-vrp.c:386
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-11-09 13:02 --- Hm, a build issue. Let's make this P2 for now. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||build Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41491
[Bug c++/41995] Incorrect point of instantiation for function template
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-11-09 12:18 --- EDG accepts it in strict mode though I also think it's invalid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995
[Bug c++/41995] Incorrect point of instantiation for function template
--- Comment #1 from redi at gcc dot gnu dot org 2009-11-09 12:01 --- probably related to PR 23885 and/or PR 16635 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #15 from ubizjak at gmail dot com 2009-11-09 11:48 --- (In reply to comment #7) > -march=geode disables cmov because the real geode does not have cmov :). No, all geodes have cmov. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/41995] New: Incorrect point of instantiation for function template
I know this is nitpicky, but I haven't found references to it (or the whys) in
the database.
I am not a lawyer, but I think that according to [0][1], the following program
should not compile:
#include
template
void f (T t) {
g (t);
}
int main () {
f (42);
} // point of instantiation of f(), g(int) not yet visible
void g (int i) {
std::cout << i << '\n';
}
To my best knowlege, if function g would take a non-intrinsic type, this would
be correct, but with raw int, ADL should not take place, i.e. the call to
g(int) in f(int) refers to an unresolved symbol.
[0] Vandevoorde/Josuttis 10.3.2: Points of Instantiation
(http://books.google.de/books?id=EotSAwuBkJoC&pg=PA146&lpg=PA146&dq=vandevoorde+point+of+instantiation&source=bl&ots=iwJ0D7_jhd&sig=1yVPrdPe2Dx1AtoPFDpAkFKIe2Y&hl=de&ei=0WedSYORD42K0AXf24DgBQ&sa=X&oi=book_result&resnum=1&ct=result#PPA147,M1)
[1] ISO/IEC 14882:2003(draft) 14.6.4.1 Point of instantiation, Item 1
--
Summary: Incorrect point of instantiation for function template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: phresnel at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41995
[Bug bootstrap/37702] Stage 2- C compiler cannot create executables-recent svn
--- Comment #9 from davek at gcc dot gnu dot org 2009-11-09 11:09 --- Inactive for over a year, and was most likely a system or environment problem rather than a bug in gcc itself, so closing. HEAD currently builds fine. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37702
[Bug middle-end/41357] libgomp build fail
--- Comment #33 from davek at gcc dot gnu dot org 2009-11-09 11:05 --- This has been working fine for some time now, so closing. Verified by building r154011: no debuginfo problems. -- davek at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41357
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #14 from ubizjak at gmail dot com 2009-11-09 10:47 --- (In reply to comment #11) > There is also geode NX, IIRC it represents itself as Athlon, but someone > should > confirm this. According to [1], cpuid for Geode NX returns "AMD Geode NX 1750", and this string doesn't trigger our current detection logic for Geode architecture. [1] http://en.gentoo-wiki.com/wiki/Safe_Cflags/AMD#Athlon_XP.2FGeode_NX -- ubizjak at gmail dot com changed: What|Removed |Added BugsThisDependsOn||37179 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/41994] [4.4/4.5 Regression] ICE with &A::operator T
--- Comment #2 from jakub at gcc dot gnu dot org 2009-11-09 10:45 --- Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144618 -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #13 from ubizjak at gmail dot com 2009-11-09 10:34 --- Created an attachment (id=18997) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18997&action=view) Patch that introduces geode-lx CPU option Can you patch the compiler with attached patch? "gcc -march=native -### hello.c" should return -march=geode-lx somewhere for your target. Passing "-march=geode-lx" should generate fastest code. -- ubizjak at gmail dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ubizjak at gmail dot com |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #12 from ubizjak at gmail dot com 2009-11-09 10:28 --- Reopened to clear this geode mess. -- ubizjak at gmail dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #11 from ubizjak at gmail dot com 2009-11-09 10:28 --- OK, according to your benchmarks and documentation qoute, it looks we have to split "geode-lx" out of generic "geode" option. So, can you confirm, that the difference between generic geode and geode-lx is presence of CMOV bit? According to your documentation quote, it should use i686 pipeline with 3dNow! features. There is also geode NX, IIRC it represents itself as Athlon, but someone should confirm this. See also PR37179, geode LX does not implrement ffreep, so it is not Athlon. -- ubizjak at gmail dot com changed: What|Removed |Added Last reconfirmed|-00-00 00:00:00 |2009-11-09 10:28:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/41994] [4.4/4.5 Regression] ICE with &A::operator T
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-09 10:18 --- Confirmed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-11-09 10:18:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
[Bug middle-end/41992] ICE on invalid dereferencing of void *
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-11-09 10:16 ---
Which is because the gimplifier thinks this is an error for the frontend to
pass through:
Breakpoint 1, fancy_abort (
file=0x10b1ab8 "/space/rguenther/src/svn/trunk/gcc/gimplify.c", line=7173,
function=0x10b2ca4 "gimplify_expr")
at /space/rguenther/src/svn/trunk/gcc/diagnostic.c:728
728 internal_error ("in %s, at %s:%d", function, trim_filename (file),
line);
(gdb) up
#1 0x007fa0a5 in gimplify_expr (expr_p=0x76f07a48,
pre_p=0x7fffced8, post_p=0x7fffc558,
gimple_test_f=0x7b9486 , fallback=1)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:7173
7173 gcc_assert (!VOID_TYPE_P (TREE_TYPE (*expr_p)));
(gdb)
#2 0x007e9450 in gimplify_asm_expr (expr_p=0x77ede980,
pre_p=0x7fffced8, post_p=0x7fffc558)
at /space/rguenther/src/svn/trunk/gcc/gimplify.c:4896
4896 tret = gimplify_expr (&TREE_VALUE (link), pre_p, post_p,
the C standard doesn't claim dereferencing a void pointer is invalid, so
the gimplifier should deal with this.
Before tree-ssa we ICEd with
t5.c:3: internal compiler error: in int_mode_for_mode, at stor-layout.c:289
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html> for instructions.
or with 2.95 with
t5.c:3: Internal compiler error in `emit_move_insn_1', at expr.c:2835
so, not a regression.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Keywords||ice-on-invalid-code
Last reconfirmed|-00-00 00:00:00 |2009-11-09 10:16:57
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41992
[Bug tree-optimization/41987] [4.5 Regression] expected class �constant�, have �binary� (rdiv_expr) in build_complex, at tree.c:1485
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-11-09 10:09 --- It might be a latent issue even with MPC installed. Kaveh should investigate. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||ghazi at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41987
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #10 from ubizjak at gmail dot com 2009-11-09 09:34 --- (In reply to comment #8) > 1) define "real geode" > 2) what CPU do I have? http://en.wikipedia.org/wiki/Geode_%28processor%29#AMD_Geode -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #9 from rootkit85 at yahoo dot it 2009-11-09 09:01 --- Read here pag. 15: http://www.amd.com/files/connectivitysolutions/geode/geode_lx/33234F_LX_databook.pdf "The instruction set supported by the core is a combination of Intel Pentium® processor, AMD Athlon processor, and AMD Geode LX processor specific instructions. Specifi- cally, it supports the Pentium, Pentium Pro, AMD 3DNow! technology and MMX instructions for the AMD Athlon processor. It supports a subset of the specialized AMD Geode LX processor instructions including special SMM instructions. The CPU Core does not support the entire Katmai New Instruction (KNI) set as implemented in the Pentium 3. It does support the MMX instructions for the AMD Athlon processor, which are a subset of the Pentium 3 KNI instructions." -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug target/41989] Code optimized for AMD Geode is slower than generic
--- Comment #8 from rootkit85 at yahoo dot it 2009-11-09 08:55 --- 1) define "real geode" 2) what CPU do I have? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41989
[Bug c++/41994] [4.4/4.5 Regression] ICE with &A::operator T
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
[Bug c++/41994] New: [4.4/4.5 Regression] ICE with &A::operator T
The following valid code snippet triggers an ICE since GCC 4.4.0:
===
template struct A
{
operator T();
A() { T (A::*f)() = &A::operator T; }
};
A a;
===
bug.cc: In constructor 'A::A() [with T = int]':
bug.cc:7:8: instantiated from here
bug.cc:4:36: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
--
Summary: [4.4/4.5 Regression] ICE with &A::operator T
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41994
