> For reference, the last test results posted for either of these seem to be
> yours last July, so given your deprecation proposal we can take it there
> is no evidence of current GCC users for these platforms at present. If
> these targets are removed, I believe we can remove
> --enable-threa
On 1/21/08, John David Anglin <[EMAIL PROTECTED]> wrote:
> > The following target architectures have seen no test results posted in
> > the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
> > score, stormy16, vax.
>
> Regarding vax, I don't have the time to maintain it. HPPA has tak
On 1/21/08, Benjamin Kosnik <[EMAIL PROTECTED]> wrote:
>
> Hello all!
>
> Jason Merrill, Doug Gregor, and I invite all interested GCC hackers to
> discuss implementation of the compiler and library parts of the
> C++0x concepts proposals. This is to be a brainstorming session, where
> we discuss th
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user base, or just
developer base?
Neither, actually. It's tester base that counts the most.
Paolo
On Tue, 2008-01-22 at 04:06 -0500, NightStrike wrote:
> I work for a company that makes significant use of gcc to target vax.
> The people involved are users, not developers, of gcc. Does any part
> of the deprecation requirements take into account user base, or just
> developer base?
What GCC ve
On Mon, 21 Jan 2008, Matt Thomas wrote:
> We would. I have gcc working with gcc4.3 but gcc's use mpfr/gmp has made
> native test impossible since neither work on vax/elf. I don't have time
> to make them work.
They don't work even with --host=none-unknown-netbsdelf to use the generic
C code in
On Tue, 22 Jan 2008, Paolo Bonzini wrote:
> > I work for a company that makes significant use of gcc to target vax.
> > The people involved are users, not developers, of gcc. Does any part
> > of the deprecation requirements take into account user base, or just
> > developer base?
>
> Neither, a
On 1/18/08 9:16 AM, Ruan Beihong wrote:
How can I get help about modifying the gcc code?
A have referred to the gcc internal manual, but it didn't help.
Have you also read the various tutorials and articles on the wiki?
http://gcc.gnu.org/wiki/GettingStarted contains various helpful pointers.
NightStrike wrote:
On 1/21/08, John David Anglin <[EMAIL PROTECTED]> wrote:
The following target architectures have seen no test results posted in
the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
score, stormy16, vax.
Regarding vax, I don't have the time to maintain it. HPPA
Manuel López-Ibáñez wrote:
On 22/01/2008, Andrew Haley <[EMAIL PROTECTED]> wrote:
NightStrike wrote:
I work for a company that makes significant use of gcc to target vax.
The people involved are users, not developers, of gcc. Does any part
of the deprecation requirements take into account user
On 22/01/2008, Andrew Haley <[EMAIL PROTECTED]> wrote:
> NightStrike wrote:
> >
> > I work for a company that makes significant use of gcc to target vax.
> > The people involved are users, not developers, of gcc. Does any part
> > of the deprecation requirements take into account user base, or jus
> Will you allow people to call in as an observer, and not a
> participater?
Yes, as long as we have enough lines for full participants.
Please note that I'll summarize this call in email afterward, so that
mechanism will also be available to lurkers.
-benjamin
Dave Korn wrote:
On 22 January 2008 14:06, Manuel López-Ibáñez wrote:
I note the lack of anyone posting test results for
uClinux, OpenBSD or RTEMS, and suggest that users of those operating
systems should try to post test results for at least some target
architectures.
Sorry. For RTE
On 22 January 2008 14:06, Manuel López-Ibáñez wrote:
> I agree that weighing the user base doesn't make any practical sense.
> But I can't understand the reason for removing something that works
> fine because it may rot in the future.
It's particularly with the lack of test results that that
Will you allow people to call in as an observer, and not a
participater?
You beat me to the post! I'm primarily interested in listening in, or
reading a transcript at the very least.
Yes, as long as we have enough lines for full participants.
Please note that I'll summarize this call in em
Emmanuel Fleury wrote:
> Joe Buck wrote:
>> Nothing final has been decided. There are some efforts under way of
>> finding ways to reassure RMS that it's possible to do plugins in a way
>> that doesn't open the door to unrestricted use of gcc internals by
>> proprietary compilers, so it would be c
On Tue, Jan 22, 2008 at 10:49:19AM +0100, Paolo Bonzini wrote:
>
> >I work for a company that makes significant use of gcc to target vax.
> >The people involved are users, not developers, of gcc. Does any part
> >of the deprecation requirements take into account user base, or just
> >developer ba
> Neither, actually. It's tester base that counts the most.
I had a discussion with Jan-Benedict Glaw last night about this. He
has been working on a linux port. He said:
> The damn thing is that we need a working kernel + userland. Irrelevant
> of the actual operating system. Maybe it would b
Andrew Hutchinson <[EMAIL PROTECTED]> writes:
> The alternative, perhaps, would be to set each length attribute
> dynamically in each pattern - if that was possible. But that looks
> like way more work.
That is certainly the best way. Search for "length" in mips.md for
one example of how it can
> Is there a chance of any sort of streaming audio broadcast instead of
> having to dial in?
Not for this call, sorry.
-benjamin
On 1/22/08 12:49 PM, Emmanuel Fleury wrote:
Emmanuel Fleury wrote:
Can we count on the fact that the SVN branch will be synced from time to
time to the mainline ?
synchronized ...from... the mainline...
Yes.
Diego.
Can we count on the fact that the SVN branch will be synced from time to
time to the mainline ?
synchronized ...from... the mainline...
Yes.
When you say it will be synchronized from time to time, is it possible
to make it so that at least for each mainline GCC release we could
produce a
Brendon Costa wrote:
Can we count on the fact that the SVN branch will be synced from
time to
time to the mainline ?
synchronized ...from... the mainline...
Yes.
When you say it will be synchronized from time to time, is it possible
to make it so that at least for each mainline GCC relea
> On Tue, Jan 22, 2008 at 10:01:55AM +1100, Ben Elliston wrote:
> > My understanding is that NetBSD port to the vax is very much alive and
> > maintained. Thus, I expect that those users (eg Matt Thomas) would like
> > to see the GCC port retained.
>
> How can we encourage the NetBSD folks to par
Thank you greatly for the feedback
I took at look at mips.md - and we already use the conditional "length"
for some instruction.
However, some effective AVR instruction lengths are vastly complicated
by operands, length and addressing modes. (After all we emulate 16 and
32 bit operations wit
On Jan 22, 2008 5:50 PM, Brendon Costa <[EMAIL PROTECTED]> wrote:
> When you say it will be synchronized from time to time, is it possible
> to make it so that at least for each mainline GCC release we could
> produce a corresponding GCC plugin branch release or tag which is the
> same but with th
"Joseph S. Myers" <[EMAIL PROTECTED]> 写于 01/22/2008 03:06:52 AM:
> The following target architectures have seen no test results posted in
> the past year: arc, c4x (as listed above), crx, iq2000, mt, pdp11,
> score, stormy16, vax. Of these targets, score appears to be actively
> maintained; I sug
Andrew Hutchinson <[EMAIL PROTECTED]> writes:
> As I say above, the logic already exists as c function. If we could
> call these directly to determine the attribute value, it would be much
> easier!
You can. Use symbol_ref. Again, examples in mips.md. Note how the
default value for the "length
On Tue, 2008-01-22 at 15:06 +0100, Manuel López-Ibáñez wrote:
> I agree that weighing the user base doesn't make any practical sense.
> But I can't understand the reason for removing something that works
> fine because it may rot in the future.
Every port, working or not, imposes a certain amount
I guess that the argument of the user defined command in gdbinit.in
should be $arg0. Also, due to the changes of the structure tree node,
ptc should be,
define ptc
-output (enum tree_code) $.common.code
+output (enum tree_code) $arg0.base.code
echo \n
end
Here's the patch,
--- gcc/gdbinit.in
30 matches
Mail list logo
