> 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
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 imagine.
che
Arthur Schwarz wrote:
>
> (I've already provided an indication of a willingness to do something to
> Robert Dewar).
Does his wife know? :-O
cheers,
DaveK
(I'll get my coat)
Richard Kenner wrote:
There are many cases when you can prove the value can be treated as valid.
One interesting case is based on the fact that suppressing a
language-defined check is erroneous if that check would fail. So, for
A: = B + 1;
you *can* assume A is valid.
Yes, but I don
John Engelhart 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 that looks even remotely like an
> objective-c "object", then just assume that it can alias any
> 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 the support for invalid values in Ada more robust and expose
> more optimization
Snapshot gcc-4.5-20090409 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090409/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Shobaki, Ghassan wrote:
Thanks for everyone who has responded to this email thread!
That was quite informative for me although I am not yet familiar with
all the phases in GCC. I have worked on instruction scheduling and
register allocation in another compiler and am currently trying to
underst
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 the support for invalid
values in Ada more robust and expose more optimization op
On Wed, Apr 8, 2009 at 5:42 PM, Ian Lance Taylor wrote:
> John Engelhart writes:
>
>> Objective-C defines 'c_common_get_alias_set' as its language specific
>> alias set manager. c_common_get_alias_set() seems(?) to only
>> implement C's strict aliasing rules, with no provisions for
>> Objective-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello Matt,
Matt Hoosier a écrit :
> Hi,
>
> I'm having trouble compiling the following with g++ 4.2.1:
>
> class Uncopyable
> {
> public:
> Uncopyable(int x) {}
> private:
> Uncopyable(const Uncopyable & other) {}
> };
>
>
Thanks for everyone who has responded to this email thread!
That was quite informative for me although I am not yet familiar with
all the phases in GCC. I have worked on instruction scheduling and
register allocation in another compiler and am currently trying to
understand how things are done in
Hi,
I'm having trouble compiling the following with g++ 4.2.1:
class Uncopyable
{
public:
Uncopyable(int x) {}
private:
Uncopyable(const Uncopyable & other) {}
};
class User
{
public:
void foo(int x)
{
foo(Uncopyable(x));
}
void foo(
Arthur Schwarz writes:
> I didn't mean to volunteer. I'm retired and therefor am both
> unhireable and hove no free time. But if you really (really) want
> ... I'd be glad to contribute in any way that I can. Provide what you
> need that I can do, and a means to give you feedback and I'm yours.
I didn't mean to volunteer. I'm retired and therefor am both unhireable and
hove no free time. But if you really (really) want ... I'd be glad to
contribute in any way that I can. Provide what you need that I can do, and a
means to give you feedback and I'm yours.
(I've already provided an ind
On Thu, Apr 09, 2009 at 11:03:20AM -0700, Ian Lance Taylor wrote:
> Arthur Schwarz writes:
> > 2: Stream errors are tortuous to decode to find the cause of
> >error..Any thought to simplification?
> >
> >In particular: 'stream << something_wrong;' can produce a
> >multiline message wit
Hi David,
Thanks for the reply, I've managed to find a solution for my needs in
the end.
It turns out the Apple gcc compiler supports mixing C++ and Objective-C
in the same source file so I've been able to implement what I was
looking
for using operator overloading - a much more flexible sol
Arthur Schwarz writes:
> 1: Any thought to including column numbers with line numbers on
> ERROR messages? Looking at a diagnostic message for a complex
> statement without a column number has lead to making an
> incorrect assumption as to what in the line is faulty. A
> column nu
2009/4/8 Sylvain Pion :
> Maybe, but for exceptions which are relatively local, say, inside a given
> library, the user can assume that GCC has switched to the "local ABI" with
> fast internal exceptions, since he may have compiled the library as one
> translation unit, so he may be able to contro
Please take the comments as constructive and not adversarial. I use GCC
and have hopes of sending it a Valentine's Day gift.
1: Any thought to including column numbers with line numbers on
ERROR messages? Looking at a diagnostic message for a complex
statement without a column number has
> I am seeing a few regressions with respect to trunk of a recent vintage.
Thanks, they are not there on arm-elf but I could indeed reproduce them
with arm-linux-gnueabi. Here is a patch which I am committing to
cond-optab branch.
Paolo
2009-04-09 Paolo Bonzini
* optabs.c (prepare_c
Hi,
On Thu, 9 Apr 2009, Paolo Bonzini wrote:
> Fixed like this:
>
> Index: gcc/optabs.c
> ===
> --- gcc/optabs.c(branch cond-optab)
> +++ gcc/optabs.c(working copy)
> @@ -4026,6 +4026,8 @@ prepare_cmp_insn (rtx x, rt
Paolo,
Mike Stump's view was that darwin1 and darwin2 should be
ignored since they can't build FSF gcc for other reasons.
The idea was to fix these cases for the foreseeable future
by using darwin[921]* as the match. I also tested the patch
with a build of i686-apple-darwin9 and the results are
Hi,
i see simular lines in a program.
char buf[256] __attribute__((aligned(16)));
printf("%x\n",&buf[0]);
this short test program give no error or warning and do not align as
expect.i test with several 68k amigaos compilers (3.4.0 /4.3.2/4.4.0), and
i think this is no target problem.at least
>Mike Stump's recommendation on this issue is to use the match
> darwin[912]* to make sure that this is captured for darwin9 through
> darwin29. The idea is to not match darwin3 through darwin8. This usage
> is present in several places...
>
> http://gcc.gnu.org/ml/gcc-patches/2008-11/msg0033
On Thu, Apr 09, 2009 at 11:35:36AM +0200, Paolo Bonzini wrote:
> Jack Howarth wrote:
> >I see one place where breakage may have occured...
> >
> > http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/configure.ac?r1=144881&r2=144887
> >
> > --- trunk/configure.ac 2009/03/16 13:23:13 14
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Ramana Radhakrishnan
> Sent: 08 April 2009 23:30
> To: Paolo Bonzini
> Cc: GCC Development; Ian Lance Taylor; Andreas Krebbel; Uros Bizjak
> Subject: Re: [cond-optab] svn branch created, looki
Hi,
the problem below is still present in GCC version 4.4.0 20090407 (exact this
snapshot with no additional patches). The objdump is from Binutils version
2.19.
Sebastian Huber wrote:
> Hi,
>
> I use GCC cross compilers from the RTEMS project. They differ only in nuances
> from the official r
Paolo Bonzini wrote:
> Andreas Krebbel wrote:
>> Hi,
>>
>>> r145594: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (s390)
>
> Note this patch is unrelated and only affects sync.md patterns.
>
>> The cond-optab branch (rev. 145751) fails to bootstrap on s390x:
>>
>> /build2/gcc-condoptab
Paolo Bonzini wrote:
> Andreas Krebbel wrote:
>> Hi,
>>
>>> r145594: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (s390)
>
> Note this patch is unrelated and only affects sync.md patterns.
>
>> The cond-optab branch (rev. 145751) fails to bootstrap on s390x:
>>
>> /build2/gcc-condoptab
Andreas Krebbel wrote:
> Hi,
>
>> r145594: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (s390)
Note this patch is unrelated and only affects sync.md patterns.
> The cond-optab branch (rev. 145751) fails to bootstrap on s390x:
>
> /build2/gcc-condoptab/libgcc/../gcc/libgcc2.c: In func
Hi,
> r145594: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00545.html (s390)
The cond-optab branch (rev. 145751) fails to bootstrap on s390x:
/build2/gcc-condoptab/libgcc/../gcc/libgcc2.c: In function '__fixunsdfti':
/build2/gcc-condoptab/libgcc/../gcc/libgcc2.c:1266: internal compiler error: i
Jack Howarth wrote:
>I see one place where breakage may have occured...
>
> http://gcc.gnu.org/viewcvs/branches/gcc-4_4-branch/configure.ac?r1=144881&r2=144887
>
> --- trunk/configure.ac2009/03/16 13:23:13 144881
> +++ trunk/configure.ac2009/03/16 17:02:02 144887
> @@
33 matches
Mail list logo
