Another algorithm for live-range shrinkage I am trying to restore
expression DAG and reorder insns in Sethi-Ulman enumeration style.
This would be done best in TER (actually, in place of TER but using the
same data structures it computes).
Paolo
On Fri, Apr 10, 2009 at 3:41 AM, Ian Lance Taylor i...@google.com wrote:
John Engelhart john.engelh...@gmail.com writes:
The easiest, and I think safest, course of action would be to add a
line in c_common_get_alias_set similar to the one I suggested. That
is, if it is a pointer to something
On Fri, Apr 10, 2009 at 12:03 AM, Eric Botcazou ebotca...@adacore.com wrote:
Hi,
we're almost ready to get rid of the awkward semantics that is implemented in
the middle-end and the optimizers for subtypes (INTEGER_TYPEs with a non-null
TREE_TYPE); this should overall simplify things, make
Dave Korn wrote:
Robert Dewar wrote:
The compiler
should not assume validity unless it can prove that the value is
actually in the declared range in my opinion.
We could add a -fstrict-validity= by analogy to -fstrict-alias=. Ada
and C would want to have different default settings I
Am Freitag, den 10.04.2009, 09:22 +0200 schrieb Richard Guenther:
On Fri, Apr 10, 2009 at 3:41 AM, Ian Lance Taylor i...@google.com wrote:
John Engelhart john.engelh...@gmail.com writes:
The easiest, and I think safest, course of action would be to add a
line in c_common_get_alias_set
TWIMC
I am an employee of Intel Corp. who will be making future contributions to gcc,
binutils, gdb and glibc. I am writing to request copyright assignment forms,
and other legal forms that are deemed necessary by FSF, which will enable me to
contribute to gcc, binutils, gdb and glibc.
Is this possible by any supported mechanism we currently have in the gcc
build system?
I want to add -Wl,-stack,0x800 to the link flags when building jc1, on
Cygwin only. Can I just do something like this
jc1$(exeext) : LDFLAGS += -Wl,-stack,0x800
in a tm frag and expect it to be
Blower, Melanie melanie.blo...@intel.com writes:
I am an employee of Intel Corp. who will be making future
contributions to gcc, binutils, gdb and glibc. I am writing to request
copyright assignment forms, and other legal forms that are deemed
necessary by FSF, which will enable me to
Hi,
I'm (still) porting GCC to a 16 bit microcontroller, and I'm having a few issues
with the way it handles memory accesses: this microcontroller can function in
two modes: in one of them the pointers are on 16 bit (a full register), in the
second one the pointers are on 32 bit and are stored in
In light of the foolhardy commitment I made, here are some reprehensible
diagnostic messages and the superb recanting of the obvious. As always, the
messaging and comments are gratuitously provided and I hope accepted in the
same manner.
Two notes (made before):
1: Some messages are
For two testresults now the cleanup tests are failing in both gcc and g++:
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01031.html
http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg00592.html
I waited for another testresults because there were some bug fixes in this
area after the eh
I'm seeing an issue with the top level configure code. Looking at it
requires juggling m4, guile, shell and make syntax in one's head, I'm
having some trouble so I'm seeking some assistance.
I'm running into the actual problem when I'm integrating the mpc library
with GCC and testing in-tree
Stelian Pop wrote:
Hi,
I'm (still) porting GCC to a 16 bit microcontroller, and I'm having a few
issues with the way it handles memory accesses: this microcontroller can
function in two modes: in one of them the pointers are on 16 bit (a full
register), in the second one the pointers are on
I am working on changing GCC for HP-UX to use the 'wrap' method for stdint
and doing the fixincludes work to make the system header more c99 compliant
and see if I can get the various c99-stdint-*.c tests to pass.
I have made some good progress but am currently running into this problem
cutdown
Arthur Schwarz wrote:
/*
* m3.cpp
*/
# include istream
# include istream
using namespace std;
ifstream x;
ifstream y();
If 'std::ifstream' not found, why is 'std::ifstream y();' legal?
Ooh, I know this one. It's because it's not a definition of an ifstream
object
Kaveh R. GHAZI gh...@caip.rutgers.edu writes:
What I would like to see is that the extra_configure_flags for mpfr
actually check whether gmp is being built in-tree before passing
--with-gmp-build=foo to mpfr's configure. But I don't get how to do that.
If the mpfr case could be fixed, I
This isn't a compiler question and I apologize for that. I'm having a devil of
a time getting an answer to my issues on the C/C++ forums I'm using and, sigh,
perhaps someone can direct me to a forum where the questions can be better
addressed.
I'm trying to redirect I/O in my C++ application
On Fri, 10 Apr 2009, Steve Ellcey wrote:
$ cat x.c
typedef unsigned char uint8_t;
void test_exact (void)
{
__typeof__(((255u))) a;
__typeof__((uint8_t)0 + 0) *b = a;
}
$ gcc -std=iso9899:1999 -pedantic-errors -fhosted -c x.c
x.c: In function 'test_exact':
x.c:5: error: pointer
(This question probably should be on gcc-help instead of this list.)
I'm trying to redirect I/O in my C++ application and am having some
difficulty. I am trying to use cout or a file for output based on some
condition. cout is an ostream object and file is an ofstream object.
The types are
On Fri, Apr 10, 2009 at 06:29:06PM +0100, Dave Korn wrote:
Stelian Pop wrote:
Hi,
I'm (still) porting GCC to a 16 bit microcontroller, and I'm having a few
issues with the way it handles memory accesses: this microcontroller can
function in two modes: in one of them the pointers are
Arthur Schwarz aschwarz1...@verizon.net writes:
# include fstream
# include istream
using namespace std;
ifstream x;
ifstream y = x;
int main(int argc, char** argv) {
y = x;
return 0;
}
g++.3.4.4 output
m1.cpp: In member function `std::basic_ioschar, std::char_traitschar
Simon Hill wrote:
C) Lastly, it would be nice if someone could indicate whether a
finished and fully functional version of this project would be likely
to make it into the mainline as I have seen requests for its
functionality many times, including on this mailing list, and it has
no downside:
-
On Apr 10, 2009, at 1:55 PM, Jason Merrill wrote:
My impression is that the C++ committee generally feel that
exception specifications are a failed feature, and nobody is
particularly interested in fixing them.
Hi Jason,
Have you seen this?
Chris Lattner wrote:
On Apr 10, 2009, at 1:55 PM, Jason Merrill wrote:
My impression is that the C++ committee generally feel that exception
specifications are a failed feature, and nobody is particularly
interested in fixing them.
Have you seen this?
operator=() is private in ios_base. Using private inheritance of ios_base the
program below fails in the constructor when '=' is used (but not during memory
initialization). I don't understand why assignment is prohibited.
art
Program 1 fails
# include ostream
using namespace std;
class
Arthur Schwarz aschwarz1...@verizon.net writes:
operator=() is private in ios_base. Using private inheritance of
ios_base the program below fails in the constructor when '=' is used
(but not during memory initialization). I don't understand why
assignment is prohibited.
Perhaps I
operator=() is private in ios_base. Using private inheritance of
ios_base the program below fails in the constructor when '=' is used
(but not during memory initialization). I don't understand why
assignment is prohibited.
art
Program 1 fails
# include ostream
using namespace std;
class
You understood me correctly. My (mis?)understanding comes from:
The Complete Reference,Fourth Edition
Herbert Schildt
Copyright 2003
ISBN 0-07-222680-3
Page 420 (And I Quote - don't you just love the phrase)
Remember: When a base class' access specifier is private, public and
Stelian Pop wrote:
Do I need to define movsi3(), addsi3() etc. patterns manually or should GCC
figure those by itself ?
Not sure I understand you. You always need to define movMM3 etc. GCC will
correctly select between movhi3 and movsi3 based on your Pmode macro when
handling pointers,
Arthur Schwarz aschwarz1...@verizon.net writes:
Remember: When a base class' access specifier is private, public and
protected members of the base become private members of the derived
class. This means that they are still accessible by members of the
derived class but cannot be accessed by
On Fri, Apr 10, 2009 at 05:28:50PM -0700, Arthur Schwarz wrote:
You understood me correctly. My (mis?)understanding comes from:
The Complete Reference,Fourth Edition
Herbert Schildt
Copyright 2003
ISBN 0-07-222680-3
gcc doesn't implement Schildt's book, it aims to implement the
One more thing to add ...
Program 1 fails
# include ostream
using namespace std;
class thing : private ios_base {
ostream xo;
public:
thing(ostream y) : xo(y) { xo = y; }
};
gcc.3.4.4 messaging
x.cpp: In member function `std::basic_ioschar, std::char_traitschar
std::basic_ioschar,
To all, I stand abashed - don't try this without a trained instructor. I
misread the Schildt quote and (I think) wasted your time(s).
Thank you
art
--- On Fri, 4/10/09, David Fang f...@csl.cornell.edu wrote:
From: David Fang f...@csl.cornell.edu
Subject: Re: operator=() issue
To: Arthur
On Fri, 10 Apr 2009, Ian Lance Taylor wrote:
Add a new shell variable in configure.ac extra_mpfr_configure_args. Set
it to what you want to pass to the mpfr configure. Call
AC_SUBST(extra_mpfr_configure_args). In Makefile.in add a line
EXTRA_MPFR_CONFIGURE_ARGS =
Kaveh R. GHAZI gh...@caip.rutgers.edu writes:
On Fri, 10 Apr 2009, Ian Lance Taylor wrote:
Add a new shell variable in configure.ac extra_mpfr_configure_args. Set
it to what you want to pass to the mpfr configure. Call
AC_SUBST(extra_mpfr_configure_args). In Makefile.in add a line
--
rwild at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rwild at gcc dot gnu dot org
|dot org
$g++ -v -save-temps test1.cpp
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.3-7'
--with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared
--enable-multiarch
--- Comment #1 from urykhy at gmail dot com 2009-04-10 06:11 ---
Created an attachment (id=17610)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17610action=view)
source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
--- Comment #2 from urykhy at gmail dot com 2009-04-10 06:12 ---
Created an attachment (id=17611)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17611action=view)
preprocessed code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
--- Comment #1 from rwild at gcc dot gnu dot org 2009-04-10 06:12 ---
patch at http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00769.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39710
--- Comment #3 from urykhy at gmail dot com 2009-04-10 06:15 ---
please, let me know if you need more information.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39711
--- Comment #2 from bonzini at gnu dot org 2009-04-10 06:42 ---
The Fortran problem is a real bug in the front-end that was masked by folding.
The problem is that we're folding less than without my patch. I'll prepare a
patch to both fix the Fortran problem and reestablish the
Hi, i have problem when compiling mplayer-svn.
TIA
==
bash-4.0$ cc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc/configure --prefix=/usr --libexecdir=/usr/lib
--enable-shared --enable-threads=posix
--- Comment #1 from happyarch at gmail dot com 2009-04-10 06:50 ---
Created an attachment (id=17612)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17612action=view)
preprocessed output
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39712
--- Comment #3 from bonzini at gnu dot org 2009-04-10 06:55 ---
The pr36901-* are correct to fail IMO -- they now give an initializer is not
constant error which they weren't giving before -- because you cannot know in
principle that sc 0 at compile-time, you have to wait for linking.
--- Comment #11 from jb at gcc dot gnu dot org 2009-04-10 07:23 ---
Subject: Bug 39665
Author: jb
Date: Fri Apr 10 07:23:25 2009
New Revision: 145875
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145875
Log:
2009-04-10 Janne Blomqvist j...@gcc.gnu.org
PR
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-10 08:18 ---
Likely due to my patch. I'll have a look.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-04-10 08:56 ---
Reduced testcase:
int is_table[2][16];
int is_table_lsf[2][2][16];
void compute_stereo()
{
int (*is_tab)[16];
is_tab = is_table;
}
interestingly removing the unrelated is_table_lsf decl makes the error go
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-10 09:40
---
This is illegal in C++03, because std::map has 4 template parameters, no matter
the defaults. Changing class A like the below works. In c++0x, thanks to
typedef templates neater solutions will be possible.
Since r141534 (PR37542), the following testcase segfaults during fre at -O1 and
higher:
template typename To, typename From
static inline To
bitwise_cast (From from)
{
union
{
From f;
To t;
} u;
u.f = from;
return u.t;
}
extern void foo (unsigned char *);
double
bar ()
{
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.4.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39713
--- Comment #3 from dodji at gcc dot gnu dot org 2009-04-10 11:46 ---
Subject: Re: No error reporting when function and variable
have the same name
alpha dot super-one at laposte dot net a écrit :
--- Comment #2 from alpha dot super-one at laposte dot net 2009-04-10
04:47
This bug groups testcases that worsen or (in one case) ICE on cond-optab
branch.
--
Summary: cond-optab fallout meta-bug
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
Priority: P3
--- Comment #3 from ayers at gcc dot gnu dot org 2009-04-10 12:43 ---
Created an attachment (id=17613)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17613action=view)
rewrite of dispatch table installation
I agree with the approach you describe, in that we need a look-a-side
/* -O1 -mthumb -march=armv5t */
struct foo
{
unsigned b31 : 1;
unsigned b30 : 1;
unsigned b29 : 1;
unsigned b28 : 1;
unsigned rest : 28;
};
foo(a)
struct foo a;
{
return a.b30;
}
should have only one lsl and lsr
--
Summary: [cond-optab] extra sign extensions on
/* -O1 -mthumb -march=armv6t2 -ffinite-math-only */
float repl1 (float varx)
{
if (varx 0.0)
return 0.0;
return varx;
}
--
Summary: [cond-optab] worse MAX_EXPR expansion for Thumb
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
--
ayers at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |ayers at gcc dot gnu dot org
|dot org
/* cris and mn10300 -O2 */
foo (float *c)
{
union
{
float r;
unsigned int i;
}
e;
e.r = c[0];
if (e.i 0x3f7f) return (e.r = e.r / 2.0f, e.i);
return ((int) e.i 0) ? 0 : 255;
}
Probably this is a duplicate too for vax:
int a, b;
int baz (short x) { return x; }
int
/* -O3 -funroll-loops */
int foo (long b, int c)
{
int d = 0, e;
while (b--)
{
e = 0;
if (!d) e = d = 1; else e = 0;
if (!(c 0x10) || !(c 0x4000) || !e) continue;
if (c 0x80) break;
}
}
--
Summary: [cond-optab] crash on crx in IRA
Note that this is a win on most targets:
int
foo ()
{
extern long long Y;
return (0 Y++);
}
--
Summary: [cond-optab] uses libcall instead of branch on m68hc11
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
/* -O1 mn10300 */
int f (int a, int b, int c, _Bool d, _Bool e, _Bool f, char g)
{
if (g != 1 || d != 1 || e != 1 || f != 1) abort ();
return a + b + c;
}
int main (void)
{
if (f (1, 2, -3, 1, 1, 1, '\001'))
abort ();
exit (0);
}
--
Summary: [cond-optab] combine does
--- Comment #8 from manu at gcc dot gnu dot org 2009-04-10 12:48 ---
Subject: Bug 20118
Author: manu
Date: Fri Apr 10 12:47:58 2009
New Revision: 145892
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145892
Log:
2009-04-10 Manuel López-Ibáñez m...@gcc.gnu.org
PR
/* -O2 */
int dialog_calendar(int state)
{
int *obj = (state == 1 ? state : 0);
return (obj == state);
}
--
Summary: [cond-optab] worse register allocation on mn10300
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
struct S
{
unsigned int s;
};
struct T
{
struct S t[2];
unsigned int u : 1;
};
void
foo (int x, int y, int z)
{
int i;
struct T t;
t.u = t.u;
for (i = 0; i x; i++)
if (z != 1)
t.t[i].s = y || t.u;
}
--
Summary: [cond-optab] worse code with bitfields on v850
--- Comment #9 from manu at gcc dot gnu dot org 2009-04-10 12:51 ---
Fixed in GCC 4.5
--
manu at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-10 12:54 ---
(In reply to comment #3)
The pr36901-* are correct to fail IMO -- they now give an initializer is not
constant error which they weren't giving before -- because you cannot know in
principle that sc 0 at
long long xlrandom (long long x)
{
int bits = 64;
do
{
unsigned b = (random () 15) + 1;
x = b; /* shift up 1-16 steps */
bits -= b;
}
while (bits = 0);
return x;
}
--
Summary: [cond-optab] worse code with long long shifts on
reload_cse_simplify_operandss likes to change (compare REG (const_int 0)) to a
compare between registers on VAX, when it has a register at hand whose value is
zero. This pessimizes code and in some cases even introduces spurious compares
instead of using CC0.
/* -Os */
f(int count,double
--- Comment #13 from dfranke at gcc dot gnu dot org 2009-04-10 14:04
---
Subject: Bug 25104
Author: dfranke
Date: Fri Apr 10 14:04:16 2009
New Revision: 145907
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145907
Log:
gcc/fortran/:
2009-04-10 Daniel Franke
--- Comment #1 from dfranke at gcc dot gnu dot org 2009-04-10 14:12 ---
Subject: Bug 38709
Author: dfranke
Date: Fri Apr 10 14:12:01 2009
New Revision: 145909
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145909
Log:
gcc/fortran/:
2009-04-10 Daniel Franke
--- Comment #2 from dfranke at gcc dot gnu dot org 2009-04-10 14:13 ---
Fixed in trunk. Not a regression, no backport.
Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
MIPS floating-point comparisons are sometimes improved, sometimes pessimized.
Here are the tests that are pessimized more:
gcc.c-torture/execute/ieee/compare-fp-1.c
gcc.c-torture/execute/ieee/compare-fp-4.c (-fno-trapping-math)
gcc.c-torture/unsorted/DFcmp.c
(not for all versions, but for
--- Comment #16 from dfranke at gcc dot gnu dot org 2009-04-10 14:04
---
Subject: Bug 29962
Author: dfranke
Date: Fri Apr 10 14:04:16 2009
New Revision: 145907
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145907
Log:
gcc/fortran/:
2009-04-10 Daniel Franke
--- Comment #13 from pault at gcc dot gnu dot org 2009-04-10 14:27 ---
(In reply to comment #12)
Comment #11 should probably go to PR38802.
Indeed - sorry.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38863
unsigned char v;
int baz (unsigned char u, unsigned char w)
{
if ((u - w) 0x80)
v = 1;
}
Combine does not like as much as for m68k the RTL produced by the optimizers,
because of the lack of byte operations:
(insn 10 9 11 f.c:5 (set (reg:QI 35)
-(and:QI (subreg:QI (reg:SI 34) 3)
double testit(double _Complex* t)
{
return *t==0.0?0.0:-*t;
}
includes useless sequence like
clr.l -(%sp);clr.l -(%sp);fdmove.d (%sp)+,%fp1
fdmove.d (%a0),%fp0
fcmp.d %fp1,%fp0
where the first and last line are useless -- GCC could instead be using the
flags as set by a
--- Comment #1 from bonzini at gnu dot org 2009-04-10 15:25 ---
Another testcase, this one failing at -O2:
void foo (unsigned int n)
{
int i, j = -1;
for (i = 0; i 10 j 0; i++)
if ((1UL i) == n)
j = i;
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39718
--- Comment #5 from hp at gcc dot gnu dot org 2009-04-10 15:28 ---
For the record, seeing the same regressions for cris-elf, 145839:145857.
Wrt. comment #3, if addresses were unsigned before (or this'd have failed),
they should still be so, and this still be constant true, right?
--- Comment #4 from alpha dot super-one at laposte dot net 2009-04-10
15:42 ---
I have not that's in lot of version, my code tested is here:
http://www.developpez.net/forums/m4191192-3/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39699
--- Comment #6 from bonzini at gnu dot org 2009-04-10 16:05 ---
We know it's not NULL.
I don't think the compiler can say so if not -fdelete-null-pointer-checks, and
the flag is off at -O0 and -O1 (which is a separate bug and a separate patch).
--
--- Comment #7 from bonzini at gnu dot org 2009-04-10 16:06 ---
Subject: Bug 39701
Author: bonzini
Date: Fri Apr 10 16:06:43 2009
New Revision: 145927
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145927
Log:
2009-04-10 Paolo Bonzini bonz...@gnu.org
PR
--- Comment #7 from hjl dot tools at gmail dot com 2009-04-10 17:35 ---
Fixed as of revision 145878.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-04-10 18:31 ---
I will have a looksee.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-10 18:43 ---
I am testing the following
Index: tree-ssa-sccvn.c
===
--- tree-ssa-sccvn.c(revision 145876)
+++ tree-ssa-sccvn.c(working copy)
@@ -257,9
--- Comment #9 from hjl at gcc dot gnu dot org 2009-04-10 18:56 ---
Subject: Bug 28301
Author: hjl
Date: Fri Apr 10 18:56:07 2009
New Revision: 145936
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145936
Log:
gcc/cp/
2009-04-10 Jason Merrill ja...@redhat.com
PR
--- Comment #13 from hjl at gcc dot gnu dot org 2009-04-10 18:58 ---
Subject: Bug 39701
Author: hjl
Date: Fri Apr 10 18:58:12 2009
New Revision: 145937
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145937
Log:
2009-04-10 H.J. Lu hongjiu...@intel.com
PR
--- Comment #10 from hjl at gcc dot gnu dot org 2009-04-10 19:01 ---
Subject: Bug 28301
Author: hjl
Date: Fri Apr 10 19:01:16 2009
New Revision: 145938
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145938
Log:
gcc/cp/
2009-04-10 H.J. Lu hongjiu...@intel.com
Backport
--- Comment #14 from pault at gcc dot gnu dot org 2009-04-10 19:06 ---
(In reply to comment #9)
The code in comment #1 still does not give the right result. I get
(intel-darwin):
No, it's not right. We have seen this before with module assignments involving
derived types.
It
--- Comment #11 from hjl at gcc dot gnu dot org 2009-04-10 19:36 ---
Subject: Bug 28301
Author: hjl
Date: Fri Apr 10 19:36:19 2009
New Revision: 145939
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=145939
Log:
gcc/cp/
2009-04-10 H.J. Lu hongjiu...@intel.com
Backport
--- Comment #12 from hjl dot tools at gmail dot com 2009-04-10 19:37
---
Fixed.
--
hjl dot tools at gmail dot com changed:
What|Removed |Added
--- Comment #1 from bonzini at gnu dot org 2009-04-10 20:06 ---
This was actually fixed already with local patches, at least above -O1.
--
bonzini at gnu dot org changed:
What|Removed |Added
For this test case:
# include fstream
# include istream
using namespace std;
ifstream x;
ifstream y = x;
int main(int argc, char** argv) {
y = x;
return 0;
}
current mainline g++ produces:
In file included from
For this C++ example:
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
current mainline g++ says this:
foo.cc:3: error: ifstream does not name a type
foo.cc:4: error: ifstream does not name a type
ifstream not only does not name a type, it
For this example:
# include istream
# include istream
using namespace std;
ifstream x;
ifstream y();
int main(int argc, char** argv) {
return 0;
}
current mainline g++ says:
foo.cc:6: error: aggregate std::ifstream x has incomplete type and cannot be
defined
This is accurate but
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 20:44
---
Is this still valid?
Is there a relation to PR21203?
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from dfranke at gcc dot gnu dot org 2009-04-10 20:50 ---
Dominique, any improvements here with -fwhole-file?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36553
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:03
---
Closing as this seems to be completed.
Please reopen if there's an issue left.
Thanks for the reports!
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #11 from dfranke at gcc dot gnu dot org 2009-04-10 21:23
---
Jerry, is this complete? If not, could you please summarize what's left?
Thanks.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |dfranke at gcc dot gnu dot
|dot org
--- Comment #10 from dfranke at gcc dot gnu dot org 2009-04-10 21:35
---
With the commit in comment #9 we get:
$ gfortran-svn -fwhole-file -Wall pr24886.f
[...]
pr24886.f:8.20:
call foo(x)
1
Warning: Character length of actual argument shorter than of
1 - 100 of 112 matches
Mail list logo
