[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #35 from Joey dot ye at intel dot com 2009-03-04 01:41 --- (In reply to comment #32) > I don't see the reason for && optimize_function_for_size_p (cfun), care to > back > up with benchmarks that forcing dynamic realignment for long long variables > with -mpreferred-stack-boundary=2 improves performance rather than slows > things > down (because of the dynamic realignment)? Checking optimize_function_for_size_p is to avoid prologue/epilogue code size increase when -Os is used, which is initially complained by Jakub. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug c++/23227] SFINAE bug
--- Comment #13 from jason at gcc dot gnu dot org 2009-03-04 01:29 --- Invalid. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug c++/23227] SFINAE bug
--- Comment #12 from jason at gcc dot gnu dot org 2009-03-04 01:28 --- oops, wrong resolution. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug c++/23227] SFINAE bug
--- Comment #11 from jason at gcc dot gnu dot org 2009-03-04 01:28 --- This can't be a SFINAE issue, as the f's in question aren't templates. The compiler instantiates A in order to determine whether or not there's a conversion from double to A, and that instantiation fails. This isn't a bug. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23227
[Bug tree-optimization/39358] [4.4 regression] Wrong aliasing warning with lists
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-03-03 23:31 --- Well, if you define xyz() within the class the warning goes away. It stays (and is bogus) if you define the function in a different translation unit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39358
[Bug tree-optimization/39358] [4.4 regression] Wrong aliasing warning with lists
--- Comment #4 from reichelt at gcc dot gnu dot org 2009-03-03 23:02
---
> Actually if you do inlining you end up with the cast happening to &node in
> this
> case. Your reduced testcase is undefined because nothing can change y.prev
> between the constructor and the call to back so you end up with accessing a
> Node_base via a Node and there is no such data there.
That's not true. xyz's body can change prev.
In fact, if you define xyz() { prev=new Node, } the warning goes away.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39358
[Bug tree-optimization/39358] [4.4 regression] Wrong aliasing warning with lists
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-03-03 22:59 --- Ok, I think the problem is two fold. We optimize the code on one path to your reduced testcase. There is no way to tell if this path is going to be executed though. I think the diagnostic needs help to figure out if this path is always executed or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39358
[Bug tree-optimization/39358] [4.4 regression] Wrong aliasing warning with lists
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-03-03 22:55 --- Actually if you do inlining you end up with the cast happening to &node in this case. Your reduced testcase is undefined because nothing can change y.prev between the constructor and the call to back so you end up with accessing a Node_base via a Node and there is no such data there. The original testcase might not be, I have to look into the preprocessed source and the tree dumps to figure out if you reduced the testcase too far or really the original testcase is just undefined. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39358
[Bug tree-optimization/39358] [4.4 regression] Wrong aliasing warning with lists
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-03-03 22:49
---
Reduced testcase:
struct Node_base {};
struct Node : Node_base
{
int data;
};
struct List
{
Node_base node, *prev;
List() : prev(&node) { xyz(); }
void xyz();
int back() { return static_cast(prev)->data; }
};
struct A
{
virtual ~A();
};
A* foo();
void bar()
{
List y;
if (y.back())
delete foo();
}
To me it looks as if "prev(&node)" in List's ctor makes the middle-end
believe that prev points to a Node_base that is not a Node. However,
the function xyz might change "prev" to point to a real Node, so this
is not a valid assumption.
At least it's not list's fault, but really a problem in the middle-end.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39358
[Bug c++/21682] Disallowed using declaration
--- Comment #6 from jason at gcc dot gnu dot org 2009-03-03 22:31 --- The names in 26605 make it clearer that it's about SFINAE, but that seems to be what your testcase is trying to do as well: if the compiler accepts the using, you would end up with an ambiguous call except that one of the templates is discarded because only one of the templates has a nested type named "type" for int or double arguments. I don't see any reason why you would want to have multiple templates with the same parameters unless you were using SFINAE to remove all but one of them during the deduction phase of overload resolution. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug middle-end/39357] [4.4 Regression] gcc.dg/vect/vect-iv-6.c
--- Comment #2 from sje at cup dot hp dot com 2009-03-03 22:25 --- I think the test should be checking vect_int_mult instead of vect_int. I will test this overnight on my IA64 runs and submit a patch tomorrow if it looks good. -- sje at cup dot hp dot com changed: What|Removed |Added CC||sje at cup dot hp dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39357
[Bug c++/38522] g++ -Wconversion warnings
--- Comment #5 from oleg dot smolsky at riverbed dot com 2009-03-03 22:24 --- BTW, my comment was about the C++ frontend. IE: .../gcc44/bin/g++ -c -Wall -W -Wconversion test.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38522
[Bug c++/38522] g++ -Wconversion warnings
--- Comment #4 from revel at muub dot net 2009-03-03 22:14 --- As I'm still monitoring this bug, I'm reopening it as requested in comment #3. I did not try building 4.4 myself yet so I cannot confirm the issue. -- revel at muub dot net changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38522
[Bug c++/11094] incomplete static member breaks sizeof containing template class
-- 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|SUSPENDED |ASSIGNED Last reconfirmed|2005-12-11 23:09:54 |2009-03-03 22:08:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11094
[Bug c++/19092] [DR 561] template code does not ignore static functions overloads
--- Comment #11 from jason at gcc dot gnu dot org 2009-03-03 22:07 --- I'm supposed to be drafting this issue. It is not likely to be a bug under the eventual resolution. -- 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|SUSPENDED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19092
[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name
--- Comment #12 from jason at gcc dot gnu dot org 2009-03-03 22:01 --- *** Bug 13967 has been marked as a duplicate of this bug. *** -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||gianni at mariani dot ws http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
[Bug c++/13967] A warning could be emitted if a template parameter of a member template is begin shadowed by another member of the class
--- Comment #26 from jason at gcc dot gnu dot org 2009-03-03 22:01 --- *** This bug has been marked as a duplicate of 36019 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13967
[Bug c++/36019] [4.2/4.3/4.4 Regression] template parameter does not hide class name
--- Comment #11 from jason at gcc dot gnu dot org 2009-03-03 22:00 --- Incidentally, this is core issue 458. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36019
[Bug c++/13389] sizeof in template:unimplemented: call_expr cannot be mangled due to a defect in the C++ ABI
--- Comment #5 from jason at gcc dot gnu dot org 2009-03-03 21:49 --- Taking mangling issues. -- 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|SUSPENDED |ASSIGNED Last reconfirmed|2005-12-18 20:24:58 |2009-03-03 21:49:18 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13389
[Bug c++/12056] [DR 397] string literal in extern inline function not unique
--- Comment #6 from jason at gcc dot gnu dot org 2009-03-03 21:48 --- The DR is resolved (and is irrelevant to this testcase anyway) -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |NEW Last reconfirmed|2005-12-18 20:15:59 |2009-03-03 21:48:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12056
[Bug c++/11633] [DR 430] g++ does not initialize structures when auto-increment variables are used
--- Comment #13 from jason at gcc dot gnu dot org 2009-03-03 21:46 --- DR 430 is resolved; this is a bug. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|SUSPENDED |NEW Last reconfirmed|2005-12-11 23:22:55 |2009-03-03 21:46:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11633
[Bug c++/11094] incomplete static member breaks sizeof containing template class
--- Comment #5 from jason at gcc dot gnu dot org 2009-03-03 21:39 --- This is core issue 408, which I'm supposed to be drafting. -- jason 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=11094
[Bug c++/21783] [DR 409] Typename for required for qualified name?
--- Comment #9 from jason at gcc dot gnu dot org 2009-03-03 21:30 --- DR 409 was accepted in October 2004. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|SUSPENDED |NEW Last reconfirmed|2006-09-03 21:39:30 |2009-03-03 21:30:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21783
[Bug c++/6424] [DR 339] sizeof() with overload resolution
--- Comment #16 from jason at gcc dot gnu dot org 2009-03-03 21:28 --- Fixed by some of my recent mangling work. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6424
[Bug c++/5435] Resolution of templates with VLAs
--- Comment #9 from jason at gcc dot gnu dot org 2009-03-03 21:23 --- int (*)[argc] is not a valid template type argument, as it depends on a runtime value, and template arguments need to be known at compile time. If you want to pass your VLA to a template function, you need to let it decay to int*. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5435
[Bug c++/4926] C++ ABI needs clarification on mangling of complex expressions
--- Comment #5 from jason at gcc dot gnu dot org 2009-03-03 21:18 --- I've been dealing with mangling issues recently. -- 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|SUSPENDED |ASSIGNED Last reconfirmed|2006-03-05 03:33:24 |2009-03-03 21:18:02 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=4926
[Bug c++/9634] [DR224] Injected class name as qualifier should not make the name dependent
--- Comment #19 from jason at gcc dot gnu dot org 2009-03-03 21:15 --- Unsuspending, no complains about DR 224 have come to the attention of the committee. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|SUSPENDED |NEW Last reconfirmed|2006-03-05 03:53:17 |2009-03-03 21:15:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9634
[Bug c++/29607] [DR 224] [4.2/4.3/4.4 Regression] dependent name with base classes
--- Comment #15 from jason at gcc dot gnu dot org 2009-03-03 21:14 --- I don't see any justification for suspending DR 224 PRs when there isn't an open core issue about the alleged problems. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|SUSPENDED |NEW Priority|P4 |P3 Last reconfirmed|2008-01-08 16:17:08 |2009-03-03 21:14:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29607
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #15 from galtgendo at o2 dot pl 2009-03-03 21:13 --- It's a runtime error and there's no real testcase, as, for the time being, it's hard to say what exactly goes wrong. The only real analysis is in the upstream bug, but it's nothing conclusive (at least it doesn't seem that way). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug c++/21682] Disallowed using declaration
--- Comment #5 from dave at boost-consulting dot com 2009-03-03 21:11 --- I don't know that SFINAE has anything to do with this. Looks like I was just doing namespace composition. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682
[Bug c++/29469] [DR 224] [4.2/4.3/4.4 Regression] error: non-template 'pair' used as template
--- Comment #11 from jason at gcc dot gnu dot org 2009-03-03 21:10 --- I don't see any open issues about DR 224 since it went into the WP. Unsuspending, P3. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|SUSPENDED |NEW Priority|P4 |P3 Last reconfirmed|2008-01-08 16:16:42 |2009-03-03 21:10:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29469
[Bug tree-optimization/39358] [4.4 regression] Wrong aliasing warning with lists
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39358
[Bug tree-optimization/39358] New: [4.4 regression] Wrong aliasing warning with lists
The following valid code snippet triggers an invalid warning on trunk
when compiled (on i686 or x64) with "-O2 -Wall":
===
#include
struct A
{
virtual ~A();
};
A* foo();
void bar(std::list x)
{
std::list y = x;
if (*y.rbegin())
delete foo();
}
===
bug.cc: In function 'void bar(std::list >)':
bug.cc:13: warning: dereferencing pointer '' does break
strict-aliasing rules
.../gcc-4.4-20090226/include/c++/4.4.0/bits/stl_list.h:139: note: initialized
from here
The problem appeared (on i686) between 2008-11-20 and 2008-12-19.
To me it looks like something is wrong with alias computation,
although I cannot rule out that there might be something wrong
with our list implementationd instead.
In either case that's serious because the result could be wrong code.
--
Summary: [4.4 regression] Wrong aliasing warning with lists
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: diagnostic, monitored
Severity: normal
Priority: P3
Component: tree-optimization
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=39358
[Bug c++/36883] Overeager ADL again
--- Comment #2 from jason at gcc dot gnu dot org 2009-03-03 20:58 --- I agree this is a bug: [temp.dep.candidate] says For the part of the lookup using unqualified name lookup (3.4.1), only function declarations with external linkage from the template definition context are found. EDG also gets this wrong currently. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||accepts-invalid Last reconfirmed|-00-00 00:00:00 |2009-03-03 20:58:20 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36883
[Bug middle-end/39322] Missed aliasing warning
--- Comment #5 from reichelt at gcc dot gnu dot org 2009-03-03 20:55 --- > Actually this is not a bogus aliasing warning at all. You are accessing a > character type as an int which is an aliasing violation. Yeah, you're right. One can only access an int array via a char pointer, but not the other way round. Sorry for screwing things up. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39322
[Bug c++/17365] [DR 218] Should ADL find non-functions?
--- Comment #11 from jason at gcc dot gnu dot org 2009-03-03 20:48 --- Reopening. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|SUSPENDED |NEW Last reconfirmed|2005-10-02 20:58:27 |2009-03-03 20:48:57 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17365
[Bug c++/14916] [DR 291] Failure to apply round-trip conversion
--- Comment #7 from jason at gcc dot gnu dot org 2009-03-03 20:46 ---
Issue 291 was resolved, so this shouldn't be suspended anymore.
The testcase is invalid because it is copy-initializing a class which cannot be
copied; returning from test_returnable involves creating a move_only temporary
using the move_only(move_from) constructor, and then copying the temporary into
the return value, which fails because we can't call the copy constructor with
an rvalue argument. EDG also rejects the testcase in strict mode.
Reduced testcase:
template struct move_from { };
template move_from move(T& x);
struct move_only
{
move_only();
move_only(move_from);
private:
move_only(move_only& rhs) ;
};
move_only test_returnable()
{
move_only x;
return move(x);
}
--
jason at gcc dot gnu dot org changed:
What|Removed |Added
CC||jason at gcc dot gnu dot org
Status|SUSPENDED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14916
[Bug c++/13549] [4.2/4.3/4.4 regression] Problem compiling Boost.Python test
--- Comment #16 from jason at gcc dot gnu dot org 2009-03-03 20:02 --- I don't see a core issue about this question, but it seems pretty clear to me that since g is dependent, and [temp.arg.explicit]/8 says that we should do arg-dependent lookup for template-ids (which we don't seem to do currently; we get that example wrong), then we should do late lookup for g as well. We ought to accept this test. Unsuspending, re-marking as regression. -- jason at gcc dot gnu dot org changed: What|Removed |Added CC||jason at gcc dot gnu dot org Status|SUSPENDED |NEW Last reconfirmed|2005-12-18 20:25:55 |2009-03-03 20:02:52 date|| Summary|Problem compiling |[4.2/4.3/4.4 regression] |Boost.Python test |Problem compiling ||Boost.Python test http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13549
[Bug c++/38522] g++ -Wconversion warnings
--- Comment #3 from oleg dot smolsky at riverbed dot com 2009-03-03 19:40
---
I've just built gcc from the official SVN and it looks like this bug is not
fully fixed. The following code generates a warning when compiled with
-Wconversion:
#include
#define M10xC0u
#define M20x20u
unsigned char test(unsigned char a1, unsigned char a2)
{
unsigned char local = (a1 & M1) | (a2 & M2); // warn
return local;
}
Could someone re-open the bug please?
--
oleg dot smolsky at riverbed dot com changed:
What|Removed |Added
CC||gcc at gaul dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38522
[Bug c++/21682] Disallowed using declaration
--- Comment #4 from jason at gcc dot gnu dot org 2009-03-03 19:34 --- This is core issue 565, which has not been addressed by the committe, though John's comment makes sense to me. How important is this issue to SFINAE techniques? -- jason 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=21682
[Bug c++/15011] partial ordering failure?
--- Comment #15 from jason at gcc dot gnu dot org 2009-03-03 19:22 --- DR 214 does address this case; it says that the testcase in the original submission is ill-formed, as the two functions are both at least as specialized as the other. [temp.deduct.partial] says that for partial ordering, we strip the reference and any cv-qualifiers from the parameter types, so we are comparing T and T. EDG now gives the same error as G++. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15011
[Bug c++/14912] Do not print default template arguments in error messages
--- Comment #47 from jason at gcc dot gnu dot org 2009-03-03 18:55 --- Created an attachment (id=17392) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17392&action=view) updated patch that fixes ICE Here's an update of the patch that fixes the ICE; we need to set processing_template_decl around the call to tsubst_copy_and_build. -- jason at gcc dot gnu dot org changed: What|Removed |Added Attachment #8457 is|0 |1 obsolete|| Attachment #16380|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14912
[Bug middle-end/10109] documentation of target macro LIBCALL_VALUE
--- Comment #7 from sje at cup dot hp dot com 2009-03-03 18:35 --- Fixed on ToT for 4.4.0. -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10109
[Bug middle-end/10109] documentation of target macro LIBCALL_VALUE
--- Comment #6 from sje at gcc dot gnu dot org 2009-03-03 18:34 --- Subject: Bug 10109 Author: sje Date: Tue Mar 3 18:33:40 2009 New Revision: 144586 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144586 Log: PR middle-end/10109 * tm.texi (LIBCALL_VALUE): Update description. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/tm.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10109
[Bug middle-end/34443] The GCC manual about section variable attribute is incorrect
--- Comment #5 from sje at cup dot hp dot com 2009-03-03 18:30 --- Fixed on ToT for 4.4.0 -- sje at cup dot hp dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34443
[Bug middle-end/34443] The GCC manual about section variable attribute is incorrect
--- Comment #4 from sje at gcc dot gnu dot org 2009-03-03 18:28 --- Subject: Bug 34443 Author: sje Date: Tue Mar 3 18:27:42 2009 New Revision: 144582 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144582 Log: PR middle-end/34443 * doc/extend.texi (section): Update description. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34443
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #9 from hjl dot tools at gmail dot com 2009-03-03 18:27 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #8 from hjl at gcc dot gnu dot org 2009-03-03 18:08 --- Subject: Bug 39345 Author: hjl Date: Tue Mar 3 18:08:01 2009 New Revision: 144581 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144581 Log: 2009-03-03 H.J. Lu PR middle-end/39345 * tree-inline.c (remapped_type): New. (can_be_nonlocal): Call remapped_type instead of remap_type. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug target/39146] Unnecessary stack alignment
--- Comment #17 from hjl dot tools at gmail dot com 2009-03-03 17:36 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00159.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00159.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug middle-end/39357] [4.4 Regression] gcc.dg/vect/vect-iv-6.c
--- Comment #1 from hjl dot tools at gmail dot com 2009-03-03 17:25 --- It may be a testcase issue since gcc.dg/vect/vect-iv-6.c was changed by revision 144569 for PR 39248: http://gcc.gnu.org/ml/gcc-cvs/2009-03/msg00071.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||irar at il dot ibm dot com BugsThisDependsOn||39248 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39357
[Bug middle-end/39357] New: [4.4 Regression] gcc.dg/vect/vect-iv-6.c
On Linux/ia64, revision 144570 gave: FAIL: gcc.dg/vect/vect-iv-6.c scan-tree-dump-times vect "vectorized 1 loops" 1 Revision 144563 is OK. -- Summary: [4.4 Regression] gcc.dg/vect/vect-iv-6.c Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: hjl dot tools at gmail dot com GCC target triplet: ia64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39357
[Bug target/39146] Unnecessary stack alignment
--- Comment #16 from hjl at gcc dot gnu dot org 2009-03-03 17:14 --- Subject: Bug 39146 Author: hjl Date: Tue Mar 3 17:14:04 2009 New Revision: 144577 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144577 Log: 2009-03-03 Joey Ye H.J. Lu PR middle-end/39146 * gcc.target/i386/stackalign/pr39146.c: New. Added: branches/stack/gcc/testsuite/gcc.target/i386/stackalign/pr39146.c Modified: branches/stack/gcc/testsuite/ChangeLog.stackalign -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39146
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #14 from hjl dot tools at gmail dot com 2009-03-03 17:01 --- Is there a testcase to show run-time error or compile-time error? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug driver/39356] assembler isn't called
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-03-03 16:57 --- Huh. It's not even compiling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug fortran/39354] bad codegen for openmp atomics (Intel64 Fortran logical ops)
--- Comment #2 from jakub at gcc dot gnu dot org 2009-03-03 16:46 --- Fixed on the trunk. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39354
[Bug fortran/39354] bad codegen for openmp atomics (Intel64 Fortran logical ops)
--- Comment #1 from jakub at gcc dot gnu dot org 2009-03-03 16:44 --- Subject: Bug 39354 Author: jakub Date: Tue Mar 3 16:43:42 2009 New Revision: 144575 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144575 Log: PR fortran/39354 * gimplify.c (goa_stabilize_expr): Handle tcc_comparison, TRUTH_ANDIF_EXPR and TRUTH_ORIF_EXPR. * gfortran.dg/gomp/pr39354.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/gomp/pr39354.f90 Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39354
[Bug java/35923] gcj: error trying to exec 'ecj1': execvp: No such file or directory
--- Comment #8 from norm at nebcs dot com 2009-03-03 16:23 --- 4.3.3 on Solaris 2.8 has the problem also. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #13 from galtgendo at o2 dot pl 2009-03-03 16:22 --- On a not really related note: output of 'gcc -Q -O1 --help=optimizers' is quite inconsistent with the manpage. Among others, -finline-small-functions according to the manpage is turned on for -O1, -Q output claims the opposite. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #12 from galtgendo at o2 dot pl 2009-03-03 16:17 --- OK, a (perhaps) interesting result: '-fno-guess-branch-probability' works too, but as first to work was '-fno-inline-small-functions', this may simply be a case of this option making code big enough to hit inlining limit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug middle-end/39341] Feature request: function attribute to save all used registers
--- Comment #4 from a dot pignotti at sssup dot it 2009-03-03 16:08 --- i'm afraid i'm only experienced with x86/x86_64 and, to a lesser extent, MIPS. so i'm marking this request as x86 specific. For my purpose it would be enough to save all gp registers, excluding those that has a special meaning, for example the stack pointer. (%r[a-d]x, %r[ds]i, %r[9-15]) -- a dot pignotti at sssup dot it changed: What|Removed |Added GCC host triplet|platform indipendent|x86/x86_64 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39341
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #34 from jakub at gcc dot gnu dot org 2009-03-03 16:01 --- Yeah, unsigned long long l __attribute__ ((aligned(8))); won't be 64-bit aligned with -m32 -mpreferred-stack-boundary=2, but I think that's not a big deal and isn't a regression from 4.3 and earlier anyway. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #7 from paolo dot carlini at oracle dot com 2009-03-03 15:46 --- Thanks, Jason, now I see it. Then I'm Ok with the patch as-is. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #7 from hjl dot tools at gmail dot com 2009-03-03 15:25 --- A patch is posted at http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00153.html -- hjl dot tools at gmail dot com changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00153.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug middle-end/39333] gcc 4.3.3 miscompiles when -finline-small-functions is used
--- Comment #11 from galtgendo at o2 dot pl 2009-03-03 15:15 --- Changing those two to unsigned doesn't help (I have checked that even before comment 8). Actually, I changed a few ints to unsigned wherever it looked sane for this file and it still crashed. What's more, '-O1' works and when I decided to go down the man page and test by -fno-* all of the features listed as additionally turned on by -O2 (-fthread-jumps -falign-functions -falign-jumps -falign-loops -falign-labels -fcaller-saves -fcrossjumping -fcse-follow-jumps -fcse-skip-blocks -fdelete-null-pointer-checks -fexpensive-optimizations -fgcse -fgcse-lm -foptimize-sibling-calls -fpeephole2 -fregmove -freorder-blocks -freorder-functions -frerun-cse-after-loop -fsched-interblock -fsched-spec -fschedule-insns -fschedule-insns2 -fstrict-aliasing -fstrict-overflow -ftree-pre -ftree-vrp) neither of them worked on its own. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39333
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #33 from hjl dot tools at gmail dot com 2009-03-03 14:48
---
(In reply to comment #32)
> I don't see the reason for && optimize_function_for_size_p (cfun), care to
> back
> up with benchmarks that forcing dynamic realignment for long long variables
> with -mpreferred-stack-boundary=2 improves performance rather than slows
> things
> down (because of the dynamic realignment)?
>
> Also, I fail to see why 2 hunks in ix86_local_alignment are needed instead of
> just one. The second hunk won't catch !type case, where we have just mode
> (but
> no need to test type && there, type is always non-NULL).
>
> I think:
> --- i386.c2009-03-02 09:45:43.0 +0100
> +++ i386.c2009-03-03 11:35:21.0 +0100
> @@ -19351,6 +19351,14 @@ unsigned int
> ix86_local_alignment (tree type, enum machine_mode mode,
>unsigned int align)
> {
> + /* Don't do dynamic stack realignment for long long objects with
> + -mpreferred-stack-boundary=2. */
> + if (!TARGET_64BIT
> + && align == 64
> + && ix86_preferred_stack_boundary < 64
> + && (mode == DImode || (type && TYPE_MODE (type) == DImode)))
> +align = 32;
> +
>/* If TYPE is NULL, we are allocating a stack slot for caller-save
> register in MODE. We will return the largest alignment of XF
> and DF. */
>
> should be sufficient.
>
I am not against this patch. I just want to mention that
---
void foo (unsigned long long *);
void
bar (void)
{
unsigned long long l __attribute__ ((aligned(8)));
foo (&l);
}
---
won't work with -m32 -Os -mpreferred-stack-boundary=2 when
this patch is applied.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug target/39226] [4.4 Regression] gcc_assert (verify_initial_elim_offsets ()); ICE
--- Comment #6 from jakub at gcc dot gnu dot org 2009-03-03 14:25 --- http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00148.html patch posted. -- jakub at gcc dot gnu dot org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc- ||patches/2009- ||03/msg00148.html http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39226
[Bug fortran/39354] bad codegen for openmp atomics (Intel64 Fortran logical ops)
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Keywords||openmp Last reconfirmed|-00-00 00:00:00 |2009-03-03 14:23:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39354
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #16 from sergstesh at yahoo dot com 2009-03-03 14:15 --- (In reply to comment #15) > Subject: Re: Segmentation fault with -O1, out of memory > with -O2 > > On Tue, 3 Mar 2009, sergstesh at yahoo dot com wrote: > > > --- Comment #14 from sergstesh at yahoo dot com 2009-03-03 13:36 > > --- > > 'spiral' has produced another testcase which segfaults with -O2 - the > > original > > testcase segfaults with -O1. > > > > The testcase, though has half the points if terms of FFT, is big as a file: > > > > -rw-r--r-- 1 sergei users 1656419 2009-03-03 06:36 gap_CPEodL.c.bz2 > > > > , so I think I can't upload it directly, or can I ? > > > > I can send it as Email attachment to, say, rguenth. > > That would be fine. > > Richard. > I have just sent Richard an Email with 'gap_CPEodL.c.bz2' file attached. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug driver/39356] New: assembler isn't called
with any input gcc -v -o hello hello.c Es werden eingebaute Spezifikationen verwendet. Ziel: x86_64-pc-mingw32 Konfiguriert mit: ../../../src/gcc-trunk-svn/configure --prefix=/mingw/x86_64-pc-mingw32/mingw --with-gmp=/home/em/install/x86_64-pc-mingw32 --with-mpfr=/home/em/install/x86_64-pc-mingw32 --with-as=/mingw/x86_64-pc-mingw32/mingw/bin/as.exe --with-ld=/mingw/x86_64-pc-mingw32/mingw/bin/ld.exe --build=i686-pc-mingw32 --host=x86_64-pc-mingw32 --target=x86_64-pc-mingw32 --enable-checking=release --enable-languages=c Thread-Modell: win32 gcc-Version 4.4.0 20090225 (experimental) [trunk revision 144424] (GCC) COLLECT_GCC_OPTIONS='-v' '-o' 'hello.exe' '-mtune=generic' c:/mingw/x86_64-pc-mingw32/mingw/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/cc1.exe -quiet -v -iprefix c:\mingw\x86_64-pc-mingw32\mingw\bin\../lib/gcc/x86_64-pc-mingw32/4.4.0/ hello.c -quiet -dumpbase hello.c -mtune=generic -auxbase hello -version -o C:\DOCUME~1\em\LOCALS~1\Temp\cc5VXXpW.s doppeltes Verzeichnis »/mingw/x86_64-pc-mingw32/mingw/include« wird ignoriert doppeltes Verzeichnis »c:/mingw/x86_64-pc-mingw32/mingw/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/include« wird ignoriert doppeltes Verzeichnis »c:/mingw/x86_64-pc-mingw32/mingw/lib/gcc/../../lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed« wird ignoriert nicht vorhandenes Verzeichnis »c:/mingw/x86_64-pc-mingw32/mingw/lib/gcc/../../x86_64-pc-mingw32/include« wird ignoriert nicht vorhandenes Verzeichnis »/mingw/include64« wird ignoriert #include "..." - Suche beginnt hier: #include <...> - Suche beginnt hier: c:\mingw\x86_64-pc-mingw32\mingw\bin\../lib/gcc/x86_64-pc-mingw32/4.4.0/include c:\mingw\x86_64-pc-mingw32\mingw\bin\../lib/gcc/x86_64-pc-mingw32/4.4.0/include-fixed C:/MinGW/x86_64-pc-mingw32/mingw/include Ende der Suchliste. GNU C (GCC) Version 4.4.0 20090225 (experimental) [trunk revision 144424] (x86_64-pc-mingw32) kompiliert von GNU-C-Version 4.4.0 20090225 (experimental) [trunk revision 144424], GMP-Version 4.2.4, MPFR-Version 2.4.0. GGC-Heuristik: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: 51a3f1cecc6611139c0ed63114b596b6 COLLECT_GCC_OPTIONS='-v' '-o' 'hello.exe' '-mtune=generic' COMPILER_PATH=c:/mingw/x86_64-pc-mingw32/mingw/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../libexec/gcc/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/bin/ LIBRARY_PATH=c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/;c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../ COLLECT_GCC_OPTIONS='-v' '-o' 'hello.exe' '-mtune=generic' c:/mingw/x86_64-pc-mingw32/mingw/bin/../libexec/gcc/x86_64-pc-mingw32/4.4.0/collect2.exe -Bdynamic -o hello.exe c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/crt2.o c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/crtbegin.o -Lc:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0 -Lc:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc -Lc:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib -Lc:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../.. hello.c -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw32 -lgcc_eh -lgcc -lmoldname -lmingwex -lmsvcrt c:/mingw/x86_64-pc-mingw32/mingw/bin/../lib/gcc/x86_64-pc-mingw32/4.4.0/../../../../x86_64-pc-mingw32/lib/crtend.o hello.c: file not recognized: File format not recognized collect2: ld gab 1 als Ende-Status zurück -- Summary: assembler isn't called Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: r dot emrich at de dot tecosim dot com GCC build triplet: x86_64-pc-mingw32 GCC host triplet: x86_64-pc-mingw32 GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39356
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug tree-optimization/39345] [4.4 Regression] ICE in copy_tree_body_r, at tree-inline.c:1020
--- Comment #6 from rguenth at gcc dot gnu dot org 2009-03-03 13:58 --- HJ, your patch looks ok with an added function comment for have_remap_type. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #15 from rguenther at suse dot de 2009-03-03 13:48 --- Subject: Re: Segmentation fault with -O1, out of memory with -O2 On Tue, 3 Mar 2009, sergstesh at yahoo dot com wrote: > --- Comment #14 from sergstesh at yahoo dot com 2009-03-03 13:36 --- > 'spiral' has produced another testcase which segfaults with -O2 - the original > testcase segfaults with -O1. > > The testcase, though has half the points if terms of FFT, is big as a file: > > -rw-r--r-- 1 sergei users 1656419 2009-03-03 06:36 gap_CPEodL.c.bz2 > > , so I think I can't upload it directly, or can I ? > > I can send it as Email attachment to, say, rguenth. That would be fine. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug middle-end/39326] Segmentation fault with -O1, out of memory with -O2
--- Comment #14 from sergstesh at yahoo dot com 2009-03-03 13:36 --- 'spiral' has produced another testcase which segfaults with -O2 - the original testcase segfaults with -O1. The testcase, though has half the points if terms of FFT, is big as a file: -rw-r--r-- 1 sergei users 1656419 2009-03-03 06:36 gap_CPEodL.c.bz2 , so I think I can't upload it directly, or can I ? I can send it as Email attachment to, say, rguenth. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39326
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #6 from jason at redhat dot com 2009-03-03 13:08 --- Subject: Re: T const assumed to be compatible with int (A::*) (void) const paolo dot carlini at oracle dot com wrote: > it seems real strange to me that we cannot > implement anymore the is_member_pointer trait as an OR of the > is_member_object_pointer and the is_member_function_pointer traits. We can still implement it that way; that part of the patch is just an optimization. I'm can drop it if you prefer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
[Bug tree-optimization/39272] [4.4 Regression] -D_FORTIFY_SOURCE=2 no longer warns with new glibc headers
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-03 13:06 --- Fixed. -- 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=39272
[Bug tree-optimization/39272] [4.4 Regression] -D_FORTIFY_SOURCE=2 no longer warns with new glibc headers
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-03 13:06 --- Subject: Bug 39272 Author: rguenth Date: Tue Mar 3 13:05:53 2009 New Revision: 144573 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144573 Log: 2009-03-03 Richard Guenther PR middle-end/39272 * tree.c (tree_nonartificial_location): New function. * tree.h (tree_nonartificial_location): Declare. * builtins.c (expand_builtin_memory_chk): Provide location of the call location for artificial function pieces. (maybe_emit_chk_warning): Likewise. (maybe_emit_sprintf_chk_warning): Likewise. (maybe_emit_free_warning): Likewise. * expr.c (expand_expr_real_1): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/expr.c trunk/gcc/tree.c trunk/gcc/tree.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39272
[Bug debug/39355] [4.4 Regression] ICE at dwarf2out.c:10353 in loc_descriptor_from_tree_1
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-03-03 13:04 --- Honza, I'm sure this is yours. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||hubicka at gcc dot gnu dot ||org Summary|[4.4 Regression] ICE at |[4.4 Regression] ICE at |dwarf2out.c:10353 in|dwarf2out.c:10353 in |loc_descriptor_from_tree_1 |loc_descriptor_from_tree_1 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39355
[Bug libstdc++/39340] unnecessarily strict std::norm implementation
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-03-03 12:55 --- Closed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39340
[Bug libstdc++/39340] unnecessarily strict std::norm implementation
--- Comment #1 from highegg at gmail dot com 2009-03-03 11:49 --- I kindly request to remove this bug report. I've just learned that there are indeed numerical issues that I just failed to see. I'll try to supply a patch eventually. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39340
[Bug tree-optimization/39343] [4.4 Regression] Wrong result for __builtin_object_size (x, 1)
--- Comment #4 from jakub at gcc dot gnu dot org 2009-03-03 11:30 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39343
[Bug tree-optimization/39343] [4.4 Regression] Wrong result for __builtin_object_size (x, 1)
--- Comment #3 from jakub at gcc dot gnu dot org 2009-03-03 11:30 --- Subject: Bug 39343 Author: jakub Date: Tue Mar 3 11:29:51 2009 New Revision: 144571 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=144571 Log: PR tree-optimization/39343 * tree-ssa-ccp.c (maybe_fold_offset_to_address): Don't check if COMPONENT_REF t has ARRAY_TYPE. * gcc.dg/pr39343.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr39343.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-ccp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39343
[Bug target/39137] [4.4 Regression] -mpreferred-stack-boundary=2 causes lots of dynamic realign
--- Comment #32 from jakub at gcc dot gnu dot org 2009-03-03 10:36 ---
I don't see the reason for && optimize_function_for_size_p (cfun), care to back
up with benchmarks that forcing dynamic realignment for long long variables
with -mpreferred-stack-boundary=2 improves performance rather than slows things
down (because of the dynamic realignment)?
Also, I fail to see why 2 hunks in ix86_local_alignment are needed instead of
just one. The second hunk won't catch !type case, where we have just mode (but
no need to test type && there, type is always non-NULL).
I think:
--- i386.c2009-03-02 09:45:43.0 +0100
+++ i386.c2009-03-03 11:35:21.0 +0100
@@ -19351,6 +19351,14 @@ unsigned int
ix86_local_alignment (tree type, enum machine_mode mode,
unsigned int align)
{
+ /* Don't do dynamic stack realignment for long long objects with
+ -mpreferred-stack-boundary=2. */
+ if (!TARGET_64BIT
+ && align == 64
+ && ix86_preferred_stack_boundary < 64
+ && (mode == DImode || (type && TYPE_MODE (type) == DImode)))
+align = 32;
+
/* If TYPE is NULL, we are allocating a stack slot for caller-save
register in MODE. We will return the largest alignment of XF
and DF. */
should be sufficient.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39137
[Bug middle-end/39254] [4.4 Regression] gcc.c-torture/execute/va-arg-trap-1.c ICEs on powerpc-apple-darwin9
--- Comment #11 from amylaar at gcc dot gnu dot org 2009-03-03 09:40 --- (In reply to comment #10) > Mike, as far as I can tell, you originally (in 1997) added the code to > rs6000.md which is now in rs6000.c:rs6000_emit_move and emits a USE > for SYMBOL_REFS that are the source of a move. (Search for > "Emit a USE operation"). I have tried to #ifdef 0 this code in rs6000_emit_move, and a regression test on gcc40 (powerpc64-unknown-linux-gnu) shows only two differences, i.e. FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -O2 (internal compile r error) FAIL: gcc.c-torture/execute/va-arg-trap-1.c compilation, -Os (internal compile r error) from the baseline went away. I've used revision 144485 for my baseline, and after determining that a standard bootstrap did not work (probably a 32/64 bit ABI problem, I didn't think it was worth the trouble to hand-bootstrap to 64 bit considering this is probably not the OS we really need testing) I built / tested with: ( make all-gcc all-target-libgcc all-target-libobjc all-target-libstdc++-v3 all-target-libgfortran;make check) > make.out 2>&1 & baseline summaries: === gcc Summary === # of expected passes52951 # of unexpected failures23 # of expected failures 204 # of unresolved testcases 2 # of unsupported tests 615 === g++ Summary === # of expected passes19046 # of expected failures 140 # of unsupported tests 133 === gfortran Summary === # of expected passes29054 # of expected failures 11 # of unsupported tests 183 === libstdc++ Summary === # of expected passes5828 # of unexpected failures1 # of unexpected successes 4 # of expected failures 80 # of unsupported tests 333 Patched summary: === gcc Summary === # of expected passes52955 # of unexpected failures21 # of expected failures 204 # of unsupported tests 615 ; identical as baseline above for the other testsuites. I think this should be tested on a power or powerpc AIX target. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39254
[Bug libstdc++/39310] T const assumed to be compatible with int (A::*) (void) const
--- Comment #5 from paolo dot carlini at oracle dot com 2009-03-03 08:02 --- Hi. I'll try to catch up as soon as possible on the details of (the v3 bits of) this issue, but first blush it seems real strange to me that we cannot implement anymore the is_member_pointer trait as an OR of the is_member_object_pointer and the is_member_function_pointer traits. Can I have a quick "executive report" about the rationale of this part of the proposed fix? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39310
