Quoting Ian Lance Taylor :
The scheme that Paolo describes avoids virtual functions. But for this
usage I personally would prefer virtual functions, since there is no
efficiency cost compared to a target hook.
Well, actually, there is: you first fetch the object pointer, then you
find the vta
Nathan Froyd writes:
> On Wed, Nov 17, 2010 at 03:40:39AM +0100, Paolo Bonzini wrote:
>> True, but you can hide that cast in a base class. For example you
>> can use a hierarchy
>>
>> Target // abstract base
>> TargetImplBase // provides strong typing
>>
Quoting Nathan Froyd :
I am admittedly a C++ newbie; the first thing I thought of was:
class gcc::cumulative_args {
virtual void advance (...) = 0;
virtual rtx arg (...) = 0;
virtual rtx incoming_arg (...) { return this->arg (...); };
virtual int arg_partial_bytes (...) = 0;
// ...and
On Wed, Nov 17, 2010 at 03:40:39AM +0100, Paolo Bonzini wrote:
> True, but you can hide that cast in a base class. For example you
> can use a hierarchy
>
> Target // abstract base
> TargetImplBase // provides strong typing
> TargetI386
On 11/17/2010 03:10 AM, Ian Lance Taylor wrote:
Joern Rennecke writes:
I don't see how going to a struct cumulative_args gets us closer
to a viable solution for a multi-target executable, even if you
threw in C++. Having the target describe a type, and shoe-horning
this through a target hook i
Joern Rennecke writes:
> I don't see how going to a struct cumulative_args gets us closer to
> a viable solution for a multi-target executable, even if you threw in
> C++. Having the target describe a type, and shoe-horning this through
> a target
> hook interface that is decribed in supposedly
Quoting Paolo Bonzini :
I think a multi-target executable would be just too ugly in C due to
issues such as this. I don't think it's worthwhile to sacrifice type
safety now, so a struct cumulative_args is preferrable.
I don't see how going to a struct cumulative_args gets us closer to
a viabl
On 11/16/2010 10:17 PM, Ian Lance Taylor wrote:
I don't know how we want to get there, but it seems to me that the place
we want to end up is with the target hooks defined to take an argument
of type struct cumulative_args * (or a better name if we can think of
one).
Actually, this doesn't work
> The gthreads portability layer is missing a function for destroying a
> __ghtread_recursive_mutex object.
>
> For pthreads-based models the recursive mutex type is the same as the
> normal mutex type so __gthread_mutex_destroy handles both, but they're
> distinct types for (at least) gthr-win32.
Snapshot gcc-4.4-20101116 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20101116/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.4 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Joern Rennecke writes:
> Quoting Ian Lance Taylor :
>
>> Joern Rennecke writes:
>>
>>> Before I go and make all these target changes & test them, is there at
>>> least agreemwent that this is the right approach, i.e replacing
>>> CUMULATIVE_ARG *
>>> with void *, and splitting up x_rtl into two
On 11/16/2010 11:24 AM, Dave Korn wrote:
> I think it's probably an over-engineered solution to a problem we could
> really address best by remembering to use []-tags in the subject lines.
OK, that seems to be as close to consensus as we're probably going to
get. Let's try and do that.
Thank
Quoting Ian Lance Taylor :
Joern Rennecke writes:
Before I go and make all these target changes & test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
I don't know how we want to get t
Quoting Ian Lance Taylor :
Joern Rennecke writes:
Before I go and make all these target changes & test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
I don't know how we want to get t
On 16/11/2010 17:29, Mark Mitchell wrote:
> I spoke with a partner today who suggested that perhaps it would be a
> bit easier to follow the voluminous GCC mailing list if we had separate
(Do you mean "the voluminous gcc-patches mailing list" perhaps?)
> lists for patches related to particular
On Tue, Nov 16, 2010 at 09:57, Richard Henderson wrote:
> I think that splitting things all the way down to $arch is probably
> not useful in that things that affect all backends will not get
> addressed promptly if backend reviewers are so narrowly focused.
Agreed. A backend specific list may
On 11/16/2010 09:29 AM, Mark Mitchell wrote:
> The idea here is that (as with libstdc++), we'd send patches to
> gcc-patches@ and gcc-$arch@, but that reviewers for a particular
> back-end would find it easier to keep track of things on the
> architecture-specific lists, and also that this would ma
On Tue, Nov 16, 2010 at 6:35 AM, Jan Hubicka wrote:
>> More FDO related performance numbers
>>
>> Experiment 1: trunk gcc O2 + FDO vs O2: FDO improves performance
>> by 5% geomean
>> Experiment 2: our internal gcc compiler (4.4.3 based with many local
>> patches) O2 + FDO vs O2 (trunk gcc):
On Tue, Nov 16, 2010 at 9:29 AM, Mark Mitchell wrote:
> What do people think about this idea?
I think this is really bad idea. A lot of the time, back-end patches
for one target inspires some folks to do patches for another target.
Or for an example, look at how FMA has been done recently. Thos
I spoke with a partner today who suggested that perhaps it would be a
bit easier to follow the voluminous GCC mailing list if we had separate
lists for patches related to particular back-ends (e.g., ARM, MIPS,
Power, SuperH, x86, etc.).
The idea here is that (as with libstdc++), we'd send patches
Hi,
I have been investigating a problem I have while building Qt-embedded
with GCC-4.5.0 for ARM/Linux, and managed to produce the reduced test
case as follows.
Consider this shared library (C++):
atomic.cxx
int atomicIncrement(int volatile* addend)
{ return _
On Tue, 16 Nov 2010, Nathan Froyd wrote:
> The saving grace here is that decimal float is not enabled by default
> for arm platforms, so there are likely very few, if any, users of
> decimal float on ARM; it might be worthwhile to go ahead and fix things,
> ignoring the fallout from earlier versio
Quoting Ian Lance Taylor :
Joern Rennecke writes:
Before I go and make all these target changes & test them, is there at
least agreemwent that this is the right approach, i.e replacing
CUMULATIVE_ARG *
with void *, and splitting up x_rtl into two variables.
I don't know how we want to get t
The easiest way to deal with the use of LIBGCC2_FLOAT_WORDS_BIG_ENDIAN
in libgcc is to define a preprocessor macro __FLOAT_WORD_ORDER__ similar
to how WORDS_BIG_ENDIAN was converted. That is, cppbuiltin.c will do:
cpp_define_formatted (FOO, "__FLOAT_WORD_ORDER__=%s",
(FL
> More FDO related performance numbers
>
> Experiment 1: trunk gcc O2 + FDO vs O2: FDO improves performance
> by 5% geomean
> Experiment 2: our internal gcc compiler (4.4.3 based with many local
> patches) O2 + FDO vs O2 (trunk gcc): FDO improves perf by 6.6%
> geomean
> Experiment 3: our
2010/11/16 Jan Hubicka :
>> On Mon, Nov 15, 2010 at 5:39 PM, Jan Hubicka wrote:
>> >> > Fortunately linker plugin solves the problem here and this is why I
>> >> > want to
>> >> > have it by default. GCC then can do effectively -fwhole-program for
>> >> > binaries
>> >> > (since linker knows wh
The gthreads portability layer is missing a function for destroying a
__ghtread_recursive_mutex object.
For pthreads-based models the recursive mutex type is the same as the
normal mutex type so __gthread_mutex_destroy handles both, but they're
distinct types for (at least) gthr-win32.h, so we can
On Mon, Nov 15, 2010 at 7:19 PM, Jay K wrote:
>
> I know it is debatable and I could be convinced otherwise, but I would
> suggest:
>
>
>
> #ifdef __cplusplus
> extern "C" {
> #endif
>
> ...
>
>
> #ifdef __cplusplus
> } /* extern "C" */
> #endif
>
>
> be applied liberally in gcc.
> Not "around" #
More FDO related performance numbers
Experiment 1: trunk gcc O2 + FDO vs O2: FDO improves performance
by 5% geomean
Experiment 2: our internal gcc compiler (4.4.3 based with many local
patches) O2 + FDO vs O2 (trunk gcc): FDO improves perf by 6.6%
geomean
Experiment 3: our internal gcc (4.
29 matches
Mail list logo
