Richard Kenner wrote:
So I am not sure I understand Richard's points above, so let me be clear
about what ASIS is.
It is a set of libraries, and a well defined API, that allows generic
tools to be written that have full access to the semantic information
discovered by the compiler. This API is f
> So I am not sure I understand Richard's points above, so let me be clear
> about what ASIS is.
>
> It is a set of libraries, and a well defined API, that allows generic
> tools to be written that have full access to the semantic information
> discovered by the compiler. This API is fully documen
Richard Kenner wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| It's interestinng to note that in the Ada world, there is an ISO
| standard for plugins, which is compiler/vendor neutral (at least
| in theory, in practice there are some implementation dependencies).
| That's the ASIS interface (
Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| It's interestinng to note that in the Ada world, there is an ISO
| standard for plugins, which is compiler/vendor neutral (at least
| in theory, in practice there are some implementation dependencies).
| That's the ASIS interface
Gabriel Dos Reis wrote:
Robert Dewar <[EMAIL PROTECTED]> writes:
| It's interestinng to note that in the Ada world, there is an ISO
| standard for plugins, which is compiler/vendor neutral (at least
| in theory, in practice there are some implementation dependencies).
| That's the ASIS interface
Here http://gcc.gnu.org/develop.html#timeline , it's not a future roadmap,
it's a past roadmap.
Why doesn't it publish a "future roadmap", "ToDo", "plans",
or "ideas to be improved" ... in the GCC's development?
Sincerely, J.C. Pizarro
1. Have you many plans "ToDo" for GCC-4.4? Where are there "ToDo" for GCC-4.4?
Where are there postings of plans wanted by the GCC's developers?
I like read it.
How can we post ideas, plans (with/wout reputations/dislikes to
understand), ...?
2. What is the current roadmap's status when we
> Robert Dewar <[EMAIL PROTECTED]> writes:
>
> | It's interestinng to note that in the Ada world, there is an ISO
> | standard for plugins, which is compiler/vendor neutral (at least
> | in theory, in practice there are some implementation dependencies).
> | That's the ASIS interface (Ada Semantic
Robert Dewar <[EMAIL PROTECTED]> writes:
| It's interestinng to note that in the Ada world, there is an ISO
| standard for plugins, which is compiler/vendor neutral (at least
| in theory, in practice there are some implementation dependencies).
| That's the ASIS interface (Ada Semantic Interface S
On Mon, 2007-11-12 at 13:19 +, Rob Quill wrote:
> I have started by trying to remove #include "decimal32.c" from
> /libdecnumber/bid/decimal32.c, but I believe this is a case of the
> above. In which case, is there a general way to go about removing such
> cases, and also why is it necessary t
Tom Tromey wrote:
> Bernd> In my view, plugins will bitrot quickly as GCC's interface
> Bernd> changes; and they won't even help with the learning curve -
> Bernd> does anyone believe for a second you won't have to understand
> Bernd> compiler internals to write a plugin?
>
> Plugins are about dep
On Nov 18, 2007 10:29 PM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> I think the answer is that the patch is not a priori unacceptable.
>
> But, given that we're talking about a relatively large change, I think
> the bar should be set higher than for a change to just a few lines of
> code. In part
On Nov 18, 2007 8:32 PM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Sun, 18 Nov 2007, Steven Bosscher wrote:
>
> > 2. But *I will not work on it* now (or ask help from others) if it is *a
> > priori* not acceptable for stage 3.
>
> As I parse your sentence, you were asking if your patch would b
Kaveh R. GHAZI wrote:
>> Kaveh> I think the answer is "maybe". In the past we have counted
>> compile-time
>> Kaveh> savings as appropriate for stage3 regression fixes.
Yes, we have, and I continue to believe that's reasonable. If the
patches provide compile-time improvements, then I think th
> I opened a bug
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34144
Thanks!
--
Eric Botcazou
Jim Wilson wrote:
> Dave Korn wrote:
>> First places to look would be GO_IF_LEGITIMATE_ADDRESS and
>> REG_OK_FOR_BASE_P, wouldn't they? Particularly in conjunction with
>> REG_OK_STRICT.
>
> This could be a REG_OK_STRICT issue, but it isn't the usual case of
> accepting an unallocated pseudo in
On Sun, Nov 18, 2007 at 06:59:03PM +0100, Eric Botcazou wrote:
> > No, that's not correct. Configuring with --disable-checking is
> > perfectly reasonable in some circumstances. For instance, when testing
> > the effect of a patch without the assertion noise.
>
> Not sure what you call the "asse
Diego Novillo wrote:
No, this argument is fallacious. Plug-ins and poor documentation are
not, and should not be related. Poor documentation is an orthogonal
problem which ALSO needs to be addressed.
Actually to me if you have plug-ins, good documentation of the plug-in
interface is absolut
William Maddox wrote:
> Sharing beteen the debug info and the LTO info is a very a good thing, and
> I feel that we should not adopt a solution that breaks that. I'd really
> rather
> leave 'strip --strip-debug' broken than bloat up the object files. The sort
> of
> solution I would favor woul
Hello!
What am I doing wrong if building the trunk natively on i686-pc-gnu-linux
with ``--disable-nls --enable-languages=c --with-arch=i586'' has been
failing as follows for several days already?
#v+
[...]
/home/thomas/tmp/source/gcc/clean/trunk.build/./gcc/xgcc
-B/home/thomas/tmp/source/gcc/cle
On Sun, 18 Nov 2007, David Edelsohn wrote:
> > Kaveh R GHAZI writes:
>
> Kaveh> I think the answer is "maybe". In the past we have counted
> compile-time
> Kaveh> savings as appropriate for stage3 regression fixes. However IMHO you
> Kaveh> would need to provide some measurement of the impr
On Sun, 18 Nov 2007, Steven Bosscher wrote:
> 2. But *I will not work on it* now (or ask help from others) if it is *a
> priori* not acceptable for stage 3.
As I parse your sentence, you were asking if your patch would be
automatically (a priori) rejected for stage3. If I say it may be
acceptabl
> No, that's not correct. Configuring with --disable-checking is
> perfectly reasonable in some circumstances. For instance, when testing
> the effect of a patch without the assertion noise.
Not sure what you call the "assertion noise", (reasonable) assertions in a
compiler are a feature, --dis
On 11/17/07 09:16, Eric Botcazou wrote:
I'm still seeing the same failure on x86_64-unknown-linux-gnu, is this
going to get fixed?
You're not supposed to configure the compiler with --disable-checking as this
disables the internal assertions, use --enable-checking=release instead.
No, that's
> Kaveh R GHAZI writes:
Kaveh> I think the answer is "maybe". In the past we have counted compile-time
Kaveh> savings as appropriate for stage3 regression fixes. However IMHO you
Kaveh> would need to provide some measurement of the improvements (memory saved,
Kaveh> speed timings) so the RM
On Nov 18, 2007 7:28 AM, Kaveh R. GHAZI <[EMAIL PROTECTED]> wrote:
> On Fri, 16 Nov 2007, Steven Bosscher wrote:
>
> > Question is, whether this kind of rather large changes is acceptable
> > for stage 3 or not. Me, I call it a "regression fix" if it reduces
> > compile time. But I will not work
26 matches
Mail list logo
