On Mon, 2006-03-20 at 19:47 -0700, Jeffrey A Law wrote:
On Sat, 2006-03-18 at 10:24 +0100, Laurent GUERBY wrote:
On Fri, 2006-03-17 at 12:51 -0700, Jeffrey A Law wrote:
I'm not suggesting the FEs deduce more types and track ranges;
that would be rather absurd. What I'm saying is that
I think that it is easy for back end to make good use of
TYPE_MIN_VALUE/TYPE_MAX_VALUE. Namely, consider the assignment
x := y + z * w;
where variables y, z and w have values in the interval [0,7] and
x have values in [0,1000]. Pascal converts the above to the
following C like
On 3/21/06, Andrew Pinski [EMAIL PROTECTED] wrote:
Take the following C code:
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
Shouldn't the aliasing set for the type atype be the same as atype1?
Im
Richard Guenther writes:
On 3/21/06, Andrew Pinski [EMAIL PROTECTED] wrote:
Take the following C code:
typedef long atype[];
typedef long atype1[];
int NumSift (atype *a, atype1 *a1)
{
(*a)[0] = 0;
(*a1)[0] = 1;
return (*a)[0];
}
Shouldn't the aliasing
On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
Do you happen to know off the top of your head when get_frame_size()
becomes valid?
You don't get a good first-pass estimate until after all rtl
generation has been done. Which is later than you need.
Another possibility is to
On Mon, Mar 20, 2006 at 04:19:52PM -, Dave Korn wrote:
However, I might still want to make it an option for cases where debugging
isn't going to be important; it seems to me that the generated code should
still be valid.
At which point you should tail call to abort and be done with it.
So
On Tuesday 21 March 2006 14:57, Richard Henderson wrote:
On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
Do you happen to know off the top of your head when get_frame_size()
becomes valid?
You don't get a good first-pass estimate until after all rtl
generation has been done.
On 21 March 2006 15:12, Paul Brook wrote:
On Tuesday 21 March 2006 14:57, Richard Henderson wrote:
On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
Do you happen to know off the top of your head when get_frame_size()
becomes valid?
You don't get a good first-pass estimate until
On 21 March 2006 14:58, Richard Henderson wrote:
On Mon, Mar 20, 2006 at 04:03:08PM -, Dave Korn wrote:
Do you happen to know off the top of your head when get_frame_size()
becomes valid?
You don't get a good first-pass estimate until after all rtl
generation has been done. Which is
scratchslot = argument
argument = stack frame size - small
sp += argument
argument = scratchslot
sp += small
This assumes you have a frame pointer or sp+large_offset addressing mode
for accessing scratchslot. In which case you could either use fp as
scratch storage
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
Hi Jeff, on the subject of seeing through typecasts, I was playing around
with VRP and noticed that the following if statement is not eliminated:
int u (unsigned char c) {
int i = c;
if (i 0 || i 255)
On Mar 21, 2006, at 11:15 AM, Jeffrey A Law wrote:
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
Hi Jeff, on the subject of seeing through typecasts, I was playing
around
with VRP and noticed that the following if statement is not
eliminated:
int u (unsigned char c) {
int
On 03/21/06 03:25, Laurent GUERBY wrote:
A casual read of tree-vrp.c showed that symbolic_range_p is mostly
used to do nothing, did I miss something? May be it's in another file.
That's correct. We mostly punt on symbolic ranges because they are
fairly expensive to track. We do try to use
On 21 March 2006 14:59, Richard Henderson wrote:
On Mon, Mar 20, 2006 at 04:19:52PM -, Dave Korn wrote:
However, I might still want to make it an option for cases where debugging
isn't going to be important; it seems to me that the generated code should
still be valid.
At which point
On Tuesday 21 March 2006 17:15, Jeffrey A Law wrote:
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
Hi Jeff, on the subject of seeing through typecasts, I was playing around
with VRP and noticed that the following if statement is not eliminated:
int u (unsigned char c) {
On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote:
Should it be? I was surprised to see that all ranges are initialised
to VR_VARYING in the vrp pass, since many types have natural ranges
associated with them, for example [0, 255] for the above unsigned char;
starting off with this
On Tuesday 21 March 2006 18:01, Jeffrey A Law wrote:
On Tue, 2006-03-21 at 17:41 +0100, Duncan Sands wrote:
Should it be? I was surprised to see that all ranges are initialised
to VR_VARYING in the vrp pass, since many types have natural ranges
associated with them, for example [0, 255]
Jeff == Jeffrey A Law [EMAIL PROTECTED] writes:
Jeff Note that this is closely related to some of the bounds checking
Jeff elimination we want to support for Java one day IIRC.
My understanding from the PR (21855) is that this is stuck on
aliasing, not VRP -- the VRP parts supposedly work.
Tom
On 03/21/06 12:14, Tom Tromey wrote:
Jeff == Jeffrey A Law [EMAIL PROTECTED] writes:
Jeff Note that this is closely related to some of the bounds checking
Jeff elimination we want to support for Java one day IIRC.
My understanding from the PR (21855) is that this is stuck on
aliasing, not
On Tue, 2006-03-21 at 18:13 +0100, Duncan Sands wrote:
Is memory use a problem here? VR_VARYING has the advantage of using
a bit less memory. On the other hand, I guess you could introduce the
convention that VR_RANGE with null min/mae means to use TYPE_MIN/
TYPE_MAX, or something along
Mark == Mark Mitchell [EMAIL PROTECTED] writes:
Mark I would prefer it go on savannah, which is more clearly unaffiliated
Mark with any particular commercial entity.
Ok, I submitted a request there.
Tom
At least as far as I have been able to find, there's no mention of these
anywhere in any version of the internals manual.
I think they should at least be mentioned and the similarities/differences
to ordinary call/call_value/call_pop/call_value_pop explained, because they
actually turn out
64-bit powerpc-darwin results be found here:
http://www.math.purdue.edu/~lucier/gcc/test-results/4_2-2006-03-20.gz
The mail-report-with-warnings.log file is again too large to be
accepted by the gcc-testresults mail list after quite a few weeks
when it was only about 125K long.
I'm
On Tue, 2006-03-21 at 11:29 -0500, Diego Novillo wrote:
On 03/21/06 03:25, Laurent GUERBY wrote:
A casual read of tree-vrp.c showed that symbolic_range_p is mostly
used to do nothing, did I miss something? May be it's in another file.
That's correct. We mostly punt on symbolic ranges
On Tue, 2006-03-21 at 10:14 +0100, Duncan Sands wrote:
Hi Jeff, on the subject of seeing through typecasts, I was playing around
with VRP and noticed that the following if statement is not eliminated:
int u (unsigned char c) {
int i = c;
if (i 0 || i 255)
On Tue, 2006-03-21 at 10:10 +0100, Richard Guenther wrote:
On 3/21/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote:
On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
It looks like sometime between 10/30 and 01/23 alias analysis got out
On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
On Tue, 2006-03-21 at 10:10 +0100, Richard Guenther wrote:
On 3/21/06, Andrew MacLeod [EMAIL PROTECTED] wrote:
On Mon, 2006-03-20 at 18:55 -0500, Andrew Pinski wrote:
On Mar 20, 2006, at 5:18 PM, Andrew MacLeod wrote:
It
On 3/21/06, Daniel Berlin [EMAIL PROTECTED] wrote:
On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
I seem to have narrowed it down to this patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00908.html
That's quite a while ago :).
Dan, this appear to *not* be compile
Maybe someone can have a look at the attribute((pointer_no_escape))
patch I posted a while ago. With some IPA machinery we could possibly
trim down the clobber lists quite a bit.
Well, let me confirm first that he is right. This requires a cpgram.ii
that compiles (none of the attachments
I don't know which version is correct, but the program below
compiles fine and works with g++-3.4.2, but fails with the following
error message when compiled with g++-4.1.0...
example.cpp: In function 'typename composeColl, Out::type fmap(typename
composeTem, Base::type, Out (*)(In)) [with
I'm working on a port that has instructions to move bits between
64-bit floating-point and 64-bit general-purpose regs. I say bits
because there's no conversion between float and int: the bit pattern
is unaltered. Therefore, it's possible to use scratch FPRs for
spilling GPRs vice-versa, and
On Tue, 2006-03-21 at 17:42 -0500, Daniel Berlin wrote:
On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
On T
I seem to have narrowed it down to this patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00908.html
That's quite a while ago :).
It was, I am suprised no one
On Tue, 2006-03-21 at 22:16 -0500, Andrew MacLeod wrote:
On Tue, 2006-03-21 at 17:42 -0500, Daniel Berlin wrote:
On Tue, 2006-03-21 at 17:30 -0500, Andrew MacLeod wrote:
On T
I seem to have narrowed it down to this patch:
http://gcc.gnu.org/ml/gcc-patches/2006-01/msg00908.html
On Tue, 2006-03-21 at 22:13 -0500, Andrew MacLeod wrote:
On Tue, 2006-03-21 at 18:00 -0500, Daniel Berlin wrote:
Maybe someone can have a look at the attribute((pointer_no_escape))
patch I posted a while ago. With some IPA machinery we could possibly
trim down the clobber lists quite a
On Mar 21, 2006, at 12:34 PM, Bradley Lucier wrote:
I'm curious about whether any of the changes recently proposed to
clean up the x86-darwin port can be applied to the 64-bit PowerPC
darwin compiler;
Like what? I haven't really seen many cleanups that were x86/darwin-
specific
I'm
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25435
--- Comment #3 from bonzini at gnu dot org 2006-03-21 08:25 ---
no, we should definitely document it.
--
bonzini at gnu dot org changed:
What|Removed |Added
--- Comment #25 from bonzini at gnu dot org 2006-03-21 08:27 ---
can we close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20070
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-03-21 09:28 ---
The 3.4 branch is closed, can you check 4.0.3 or 4.1.0 please?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-21 09:28 ---
The 3.4 branch is closed, can you check 4.0.3 or 4.1.0 please?
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-03-21 09:37 ---
Confirmed. Though the unreduced testcase does not build for me. The testcase
in question is
struct i2c_driver {
struct module *owner;
int (*command)(struct i2c_client *client,unsigned int cmd, void *arg);
--- Comment #4 from rguenth at gcc dot gnu dot org 2006-03-21 09:38 ---
3.4 is confused by earlier errors and bails out.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from tbm at cyrius dot com 2006-03-21 12:09 ---
We need a testcase to reproduce this.
We don't have a minimal test case yet but you can download the source of the
package which shows this problem and see for yourself. Maybe you can come up
with a smaller testcase.
--- Comment #1 from sam at quux dot dropbear dot id dot au 2006-03-21
12:29 ---
Created an attachment (id=11081)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11081action=view)
--save-temps output from compilation of example code
--
--- Comment #7 from pinskia at gcc dot gnu dot org 2006-03-21 15:31 ---
Mine, it is STRING_CST which is causing the ICE.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-03-21 15:31 ---
Reduced testcase:
void zconfdump(void)
{
char *p, *p2;
for (p2 = p; p2; )
{
char __a0, __a1, __a2;
__a0 = ((__const char *) (\\\))[0];
if (__a0)
return;
}
}
--
--- Comment #2 from paolo at gcc dot gnu dot org 2006-03-21 12:25 ---
Subject: Bug 25482
Author: paolo
Date: Tue Mar 21 12:25:11 2006
New Revision: 112247
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112247
Log:
2006-03-21 Paolo Carlini [EMAIL PROTECTED]
PR
The following code demonstrates the bug.
#include iostream
using namespace std;
int main() {
ios::sync_with_stdio(false);
streambuf *s=cin.rdbuf();
int c=s-sgetc();
s-pubseekoff(0,ios::cur,ios::in);
cout s;
}
When the resulting executable is run with standard input coming
When compiling the following reduced code, both GCC 4.0.3 and 4.1.0 clutter the
assembly code with some strange moves through SSE registers.
typedef union {
long long l;
double d;
} db_number;
double test(double x[3]) {
double th = x[1] + x[2];
if (x[2] != th - x[1]) {
db_number
--- Comment #6 from tbm at cyrius dot com 2006-03-21 15:33 ---
I think you're onto something here. Compiling xbsql with 4.1 against a
libxbase compiled with 4.1 works, but it fails against libxbase compiled with
4.0. So this may be an 4.0 issue - but it still leaves us with a binary
This error is generated by the example, given at the end of Metcalf, Reid and
Cohen; pointer.f90. The following reduced testcase, illustartes it:
module test
public sub
type, private :: t
! type :: t
integer :: i
end type t
contains
subroutine sub (arg)
integer arg
type(t)
--- Comment #3 from pcarlini at suse dot de 2006-03-21 12:26 ---
Fixed for 4.2.0.
--
pcarlini at suse dot de changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from christoph dot stueckjuergen at siemens dot com
2006-03-21 12:02 ---
We found out that our problem is not related to the toolchain but to the rlimit
settings of the kernel. Sorry if the bug caused confusion! Please mark the bug
as invalid.
--
--- Comment #5 from matz at suse dot de 2006-03-21 13:59 ---
There is no such thing as a hidden reference. A symbol can be hidden,
then it's not exported and all references from inside DSO are directly bound
to it. That's not the situation we have here. We have a global exported
Three times in a row I got this error while building OOo-2.0.2 from source
according to instructions at
http://www.linuxfromscratch.org/blfs/view/svn/xsoft/openoffice.html but
adapted for OOo-2.0.2
There is a suggestion to do a full report at gcc.gnu.org so I comply.
Output of gcc -v
--- Comment #1 from rguenth at gcc dot gnu dot org 2006-03-21 13:13 ---
I believe this is fallout from some of the regstack changes. It does indeed
look a bit silly. But using the *ps variants on an SSE1 target is ok - the xmm
registers are just used as temporary storage.
This one
--- Comment #26 from amylaar at gcc dot gnu dot org 2006-03-21 14:24
---
(In reply to comment #25)
can we close this?
No, we still have to actually re-enable the cross-jumping code,
and we haven't even gotten to the review of the if-conversion part.
--
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-21 14:28 ---
http://gcc.gnu.org/bugs.html
Please read the instructions there (in fact this should not have been pulled up
stream until then).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-21 13:25 ---
Closing as invalid as requested by the reporter.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2006-03-21 14:06 ---
Reading this bug report, leads me to think there is a bug in 4.0.x.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-21 14:07 ---
And we cannot do without a testcase as looking at the source which you gave
link to does not give any obvious answers.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26755
--- Comment #1 from gratbau at cantv dot net 2006-03-21 14:07 ---
Created an attachment (id=11082)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11082action=view)
Screen output for build command
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26780
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 14:21 ---
GNU C++ version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8) (x86_64-pc-linux-gnu)
compiled by GNU C version 4.0.2 (Gentoo 4.0.2-r3, pie-8.7.8).
This really should have been reported to gentoo first.
--
--
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
Looks like a mis-applied patch in create_component_ref_by_pieces.
--
Summary: ICE in tree-ssa-pre.c at create_component_ref_by_piec
Product: gcc
Version: 4.2.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c
On Tue, 2006-03-21 at 15:02 +, malitzke at metronets dot com wrote:
--- Comment #5 from malitzke at metronets dot com 2006-03-21 15:02
---
The two if (tree_code(genop) == VALUE_HANDLE) at lines 2190 of tree-ssa-pre.c
look suspicious to me.
They aren't suspicious at all.
--- Comment #3 from malitzke at metronets dot com 2006-03-21 14:51 ---
Created an attachment (id=11084)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11084action=view)
ICE combined output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
namespace A { namespace B {
template typename T void foo();
} }
struct S1;
struct S2;
namespace A { namespace B {
template void foo S1 (); // accepted
} }
template void A::B::foo S2 (); // rejected
$ g++ bug.cpp -c -Wall
error: specialization of #8216;templateclass T void
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-21 14:42 ---
This is not a mis applied patch (as I created the patch).
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from gratbau at cantv dot net 2006-03-21 15:00 ---
Subject: Re: Build fails while making ../../../unxlngi6.pro/slo/cellsuno.obj
on LFS6.1, kernel 2.6.14.3
Thanks, it was most certainly that condition. Restricting the number of
concurrent running programs solved the
--- Comment #3 from sam at quux dot dropbear dot id dot au 2006-03-21
14:59 ---
Sorry - I should have confirmed it on at least one other platform before
submitting.
So I've done so now!
Exactly the same behaviour occurs on a i386-redhat-linux host with gcc version
4.0.0 20050519 (Red
--- Comment #5 from hjl at lucon dot org 2006-03-21 15:09 ---
When I make a backend change, make at the top level still tries to rebuild
all libraries, even though nothing in library will be recompiled. When Java
is enabled, it may take a while just to check if libjava needs to be
--- Comment #5 from malitzke at metronets dot com 2006-03-21 15:02 ---
The two if (tree_code(genop) == VALUE_HANDLE) at lines 2190 of tree-ssa-pre.c
look suspicious to me.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
--- Comment #3 from gratbau at cantv dot net 2006-03-21 14:14 ---
Created an attachment (id=11083)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11083action=view)
Source file
This is the file last mentioned in the output before the fail
--
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 14:09 ---
g++: Internal error: Killed (program cc1plus)
This means it ran out of memory.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from dberlin at gcc dot gnu dot org 2006-03-21 15:14 ---
Subject: Re: [4.2 Regression] ICE in
tree-ssa-pre.c at create_component_ref_by_piec
On Tue, 2006-03-21 at 15:02 +, malitzke at metronets dot com wrote:
--- Comment #5 from malitzke at metronets
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-03-21 14:44 ---
Do you have a testcase?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26781
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-03-21 14:56 ---
Reducing.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
GCC build
--- Comment #7 from law at redhat dot com 2006-03-21 15:08 ---
This is a loop optimization issue, not a jump threading bug. To really
optimize this loop well we will likely need the kinds of analysis found
in Beyond Induction Variables, the classic paper describing loop flip-flops
and
--- Comment #6 from paolo dot bonzini at lu dot unisi dot ch 2006-03-21
15:53 ---
Subject: Re: stage build no longer works
hjl at lucon dot org wrote:
--- Comment #5 from hjl at lucon dot org 2006-03-21 15:09 ---
When I make a backend change, make at the top level still
--- Comment #2 from guillaume dot melquiond at ens-lyon dot fr 2006-03-21
15:27 ---
But using the *ps variants on an SSE1 target is ok - the xmm
registers are just used as temporary storage.
I can't really think of situations where it makes sense. If this a temporary
storage, it
--- Comment #9 from law at redhat dot com 2006-03-21 15:57 ---
We've got zero chance of threading the jump in this case until the
partially redundant load from i is removed.
Daniel -- there's a pretty obvious redundant load from the global
variable i in this testcase. I haven't
--- Comment #1 from pluto at agmk dot net 2006-03-21 15:58 ---
hmm $14.7.3/2 explains it very well.
sorry for the noise.
--
pluto at agmk dot net changed:
What|Removed |Added
--- Comment #12 from rguenth at gcc dot gnu dot org 2006-03-21 16:02
---
Any updates on this? It get's in the way of loop versioning conditionals which
I now have to decompose manually into chained if's :/
--
rguenth at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-21 16:05
---
(In reply to comment #9)
Daniel -- there's a pretty obvious redundant load from the global
variable i in this testcase. I haven't investigated why PRE
is missing this obvious redundancy.
Because tree level
--- Comment #7 from yannick dot podgorski at kuantic dot com 2006-03-21
16:08 ---
Hi, I have the same error.
I use :
- binutils-2.16.1,
- gcc 4.1.0,
- avr-libc 1.4.3
But it works with gcc 4.0.3.
I use the doc : www.nongnu.org/avr-libc/user-manual/install_tools.html
make[3]:
namespace foo {
class obj {
friend void create() { }
};
}
int main()
{
foo::create();
}
test.cpp: In function 'int main()':
test.cpp:9: error: 'create' is not a member of 'foo'
--
Summary: friend functions defined in-class not added to enclosing
--- Comment #9 from pinskia at gcc dot gnu dot org 2006-03-21 16:13 ---
And here is a testcase without a simplifing opportunity:
void zconfdump(__SIZE_TYPE__ i)
{
for (;;)
{
char __a0;
__a0 = (\\\)[i];
if (__a0)
return;
}
}
--
--- Comment #11 from jason at gcc dot gnu dot org 2006-03-21 16:15 ---
Subject: Bug 21581
Author: jason
Date: Tue Mar 21 16:15:25 2006
New Revision: 112250
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112250
Log:
PR c++/21581
* parser.c (cp_parser_declaration):
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-03-21 16:15 ---
Friend functions are not injected as declarations.
See http://gcc.gnu.org/gcc-4.1/changes.html.
This is invalid C++. Use -ffriend-injection to get back the old behavior.
--
pinskia at gcc dot gnu dot org
--- Comment #13 from dnovillo at gcc dot gnu dot org 2006-03-21 16:19
---
(In reply to comment #12)
Any updates on this? It get's in the way of loop versioning conditionals
which
I now have to decompose manually into chained if's :/
Nope. I'm unlikely to work on this any time
--- Comment #3 from jakub at gcc dot gnu dot org 2006-03-21 16:21 ---
Subject: Bug 26691
Author: jakub
Date: Tue Mar 21 16:21:24 2006
New Revision: 112251
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=112251
Log:
PR c++/26691
* cp-gimplify.c
--- Comment #10 from pinskia at gcc dot gnu dot org 2006-03-21 16:26
---
I am testing the following patch:
Index: tree-ssa-pre.c
===
--- tree-ssa-pre.c (revision 112250)
+++ tree-ssa-pre.c (working copy)
@@
--- Comment #7 from hjl at lucon dot org 2006-03-21 16:27 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|WAITING
--- Comment #8 from hjl at lucon dot org 2006-03-21 16:27 ---
Fixed.
--
hjl at lucon dot org changed:
What|Removed |Added
Status|UNCONFIRMED
--- Comment #12 from pinskia at gcc dot gnu dot org 2006-03-21 16:32
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-03-21 16:32 ---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #14 from rguenth at gcc dot gnu dot org 2006-03-21 16:48
---
And I'm getting lost in decomposing such a conditional into BBs and COND_EXPRs
and GOTOs and adding edges and whatnot. This sucks. Where's the helper
routine that I'm not finding?
--
--- Comment #4 from tbm at cyrius dot com 2006-03-21 16:48 ---
(In reply to comment #1)
On the mainline I get:
t.cc:1: error: template declaration of 'enum'
t.cc:2: error: multiple types in one declaration
There might be a dup of this bug somewhere.
Bug #16189 is the same and has
--- Comment #5 from pinskia at gcc dot gnu dot org 2006-03-21 16:50 ---
(In reply to comment #4)
Ok.
*** This bug has been marked as a duplicate of 16189 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 187 matches
Mail list logo
