--- 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 t
--- 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 mo
--- 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
--- 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 (mayb
--- 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
--- 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=393
--- 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|UNCONFIR
--- 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
--- 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
--- 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
--- 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
--- 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 165641
--- 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 pro
--- 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
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39345
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-mingw3
--- 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 200
--
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
--- 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
---
--- 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-
--- 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 w
--- 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
---
--- 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
--- 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.
--
h
--- 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 spec
--- 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.
--- 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 oppos
--- 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
--- 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
--- 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|
--- 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
--- 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
--- 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/3
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
--- 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:
Wh
--- 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
-
--- 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-inl
--- 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
--- 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): Upda
--- 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
--- 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
--- 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|NE
--- 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_templat
--- 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 orderi
--- 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:
--- 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 M2
--- 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 d
--- 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 temp
--- 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|
--- 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
--- 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
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();
}
=
--
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
--- 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
-
--- 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
--- 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
--- 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 |Ad
--- 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
---
--- 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
--- 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 d
--- 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
--
--- 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
--- 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
--
--- 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
--- 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
--
--- 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
Assigne
--- 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
--- 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
-
--- 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
--
--- 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
---
--
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
--- 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
--- 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
--- 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
--- 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
--- 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(); }
--- 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 wi
--- 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
--- 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 yo
--- 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
--- 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
--- 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
St
--- 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|UNCONFIRME
--- 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-bou
84 matches
Mail list logo
