Andrew Pinski <[EMAIL PROTECTED]> writes:
> Now for the fix I have in mind (which might or might not work):
>
> If you are a maintainer of an area and you approve a patch which
> causes a regression in that new code, you have to fix it or have the
> person whos patch it was fix it or face losing yo
Mark Mitchell <[EMAIL PROTECTED]> writes:
> I'd suggest we leave backtrace() aside, and just talk about
> __builtin_frame_address(0), which does have well-defined semantics.
> _b_f_a(0) is currently broken on ARM, and we all agree we should fix it.
I don't want to fan the flames here, but I'm not
On 6/4/06, Richard Sandiford <[EMAIL PROTECTED]> wrote:
Even if it's not intended that way, your proposal is probably going to
be interpreted at some stage as a way of punishing maintainers.
And what is wrong with that? Maybe it would help clean up the long
list of maintainers who don't actual
[First, a warning: I'm neither an expert in TLS, nor in Windows nor
in GCC guts
can we have chance to solve the
problem of threadprivate by adding the TLS support to
mingw32?
The support for TLS (Thread Local Storage) would probably come from
the compiler itself. Windows has TLS (see for e
Hello Rask,
On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote:
> There may be a faster way of seeing if the modification is going to
> work for the DS at all. I noticed from the output template
> "swp%?b\\t%1, %1, [%M0]" that "swp" takes three operands. I don't
> know ARM assembler, but
FX Coudert wrote:
> Now, for an idea of how much work it represents... perhaps someone
>here can tell us?
It's not too hard but it requires changing GCC and binutils, plus a
bit of library support. In my implementation (more or less finished,
but I have had time to test it yet), I did the followi
On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> Hello Rask,
>
> On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote:
> > There may be a faster way of seeing if the modification is going to
> > work for the DS at all. I noticed from the output template
> > "swp%?b\\t%1, %1, [%M0]" that
On Sun, 4 Jun 2006, Steven Bosscher wrote:
> Maybe it would help clean up the long list of maintainers who don't
> actually do any maintenance. Then, at last, you get a more fair
> picture of the number of reviewers&maintainers that we really have.
Agreed. It will provide a clearer picture at l
FX Coudert wrote:
The support for TLS (Thread Local Storage) would probably come from
the compiler itself. Windows has TLS (see for example http://
dotnet.di.unipi.it/Content/sscli/docs/doxygen/pal/localstorage_8c-
source.html and http://www.ddj.com/dept/cpp/184403874, or the MSDN
documenta
Paul,
On Sunday 04 June 2006 13:24, Paul Brook wrote:
> On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> > Splitting the insn
> >
> > (define_insn "*arm_movqi_insn"
> > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
> > (match_operand:QI 1 "general_operand" "rI,K,m,r"))]
>
On Sunday 04 June 2006 16:26, Wolfgang Mües wrote:
> Paul,
>
> On Sunday 04 June 2006 13:24, Paul Brook wrote:
> > On Sunday 04 June 2006 11:31, Wolfgang Mües wrote:
> > > Splitting the insn
> > >
> > > (define_insn "*arm_movqi_insn"
> > > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,
Richard Sandiford wrote:
> Mark Mitchell <[EMAIL PROTECTED]> writes:
>> I'd suggest we leave backtrace() aside, and just talk about
>> __builtin_frame_address(0), which does have well-defined semantics.
>> _b_f_a(0) is currently broken on ARM, and we all agree we should fix it.
>
> I don't want to
On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote:
On 6/4/06, Richard Sandiford <[EMAIL PROTECTED]> wrote:
Even if it's not intended that way, your proposal is probably
going to
be interpreted at some stage as a way of punishing maintainers.
And what is wrong with that?
I have a different
On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote:
> Richard E. asked what possible uses this function might have.
> Obviously, GLIBC's backtrace() function is one, though I guess that's a
> weak example, in that we all agree one should really be using unwind
> information.
Which there
Daniel Jacobowitz wrote:
> On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote:
>> Richard E. asked what possible uses this function might have.
>> Obviously, GLIBC's backtrace() function is one, though I guess that's a
>> weak example, in that we all agree one should really be using unwi
I checked in a couple of patches, so now most front-ends work
more-or-less (i.e with some but not a large number of regressions).
The Java front-end compiles but fails to run, so bootstrapping fails if
java is enabled. I haven't looked into it. This is a regression -
it used to work. If the pro
On Sun, Jun 04, 2006 at 10:29:14AM -0700, Mark Mitchell wrote:
> Daniel Jacobowitz wrote:
> > On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote:
> >> Richard E. asked what possible uses this function might have.
> >> Obviously, GLIBC's backtrace() function is one, though I guess that's
Daniel Jacobowitz wrote:
> On Sun, Jun 04, 2006 at 10:29:14AM -0700, Mark Mitchell wrote:
>> Daniel Jacobowitz wrote:
>>> On Sun, Jun 04, 2006 at 09:54:25AM -0700, Mark Mitchell wrote:
Richard E. asked what possible uses this function might have.
Obviously, GLIBC's backtrace() function is
mmitchel at gcc dot gnu dot org writes:
>
>
> --- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-04 19:02
> ---
> Java is not release critical.
I protest. This is not a Java bug but an exception handling bug.
The simple fact that the test case for this bug is written
Andrew Haley wrote:
> mmitchel at gcc dot gnu dot org writes:
> >
> >
> > --- Comment #8 from mmitchel at gcc dot gnu dot org 2006-06-04 19:02
> ---
> > Java is not release critical.
>
> I protest. This is not a Java bug but an exception handling bug.
Do you have a C++ test-cas
Mark Mitchell <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> Mark Mitchell <[EMAIL PROTECTED]> writes:
>>> I'd suggest we leave backtrace() aside, and just talk about
>>> __builtin_frame_address(0), which does have well-defined semantics.
>>> _b_f_a(0) is currently broken on ARM, and we
Mike Stump <[EMAIL PROTECTED]> writes:
> On Jun 4, 2006, at 2:08 AM, Steven Bosscher wrote:
>> On 6/4/06, Richard Sandiford <[EMAIL PROTECTED]> wrote:
>>> Even if it's not intended that way, your proposal is probably
>>> going to
>>> be interpreted at some stage as a way of punishing maintainers.
On Jun 4, 2006, at 1:03 PM, Richard Sandiford wrote:
I agree. And I don't think a new gcc by-law is needed here (we
seem so
many of those already). Maintainers can already refuse to review a
"fun
new feature" patch until the submitter has fixed some problem with one
of the submitter's ea
On Sun, Jun 04, 2006 at 12:31:08PM +0200, Wolfgang Mües wrote:
> Hello Rask,
>
> On Friday 02 June 2006 09:24, Rask Ingemann Lambertsen wrote:
> > There may be a faster way of seeing if the modification is going to
> > work for the DS at all. I noticed from the output template
> > "swp%?b\\t%1, %1
Gerald Pfeifer <[EMAIL PROTECTED]> writes:
> However, we should account for periods of inactivity and reduced
> activity caused by personal issues, employer changes, illness,
> whatever.
Agreed.
> Other projects have a certain period of time (one year, eighteen months)
> after which inactive cont
This status report has been a long time coming, for which I apologize.
As fwprop is no longer on the table for 4.2, and as the vectorizer
improvements seem to have stalled due to a combination of lack of review
and Dorit's leave, I think it's time to declare 4.2 feature-complete.
That leaves us l
On Jun 4, 2006, at 1:19 PM, Richard Sandiford wrote:
I think a system of
punishing maintainers is going to make it less attractive for
less active maintainers to do anything at all.
You are not punishing the good maintainers, just not so good
ones. The idea is keep maintainers active in GCC a
Andrew Pinski <[EMAIL PROTECTED]> writes:
| On Jun 4, 2006, at 1:19 PM, Richard Sandiford wrote:
| > I think a system of
| > punishing maintainers is going to make it less attractive for
| > less active maintainers to do anything at all.
|
| You are not punishing the good maintainers, just not so
On Jun 4, 2006, at 1:11 PM, Andrew Pinski wrote:
Yes but that is not all the problem because a lot of the time
the maintainer is also the submitter. There is no way to discourage
the behavior of the maintainer on going on to other stuff while there
are known regressions to fix.
A wiki page of
On Jun 4, 2006, at 1:52 PM, Mike Stump wrote:
A wiki page of top regressions we care about? We could politely
request general agreement that the ones listed be given priority.
There is already a link from the main page of GCC to the regressions
and they are given priorities by the release ma
On Sun, Jun 04, 2006 at 12:24:53PM +0100, Paul Brook wrote:
> For the record these hacks are unlikely to ever be acceptable in mainline
> gcc.
> They're relatively invasive changes who's only purpose is to support
> fundamentally broken hardware.
We don't yet know if they'll be invasive. There
On Jun 4, 2006, at 1:43 PM, Gabriel Dos Reis wrote:
The trouble is there does not seem to be a clear gain in your
punishment system. At best it may just discourage people.
In a commercial organization, that might be a good system. For a free
project like GCC, it is not obvious where the long-
On Sun, Jun 04, 2006 at 05:26:42PM +0200, Wolfgang Mües wrote:
> Paul,
>
> On Sunday 04 June 2006 13:24, Paul Brook wrote:
>
> > You should just change the valid QImode memory addresses, adding a new
> > constraint if neccessary.
>
> H... I have tried this. I have changed the operand const
On Wed, May 31, 2006 at 10:49:35PM +0200, Wolfgang Mües wrote:
> > (define_insn "*arm_movqi_insn"
> > [(set (match_operand:QI 0 "nonimmediate_operand" "=r,r,r,m")
> > (match_operand:QI 1 "general_operand" "rI,K,m,r"))]
> > "TARGET_ARM
> >&& ( register_operand (operands[0], QImode)
>
I noticed that with a full build (including all of GCJ and libgcj),
we now install a bootload of libtool files into $PREFIX/share:
.../share/libtool/libltdl/COPYING.LIB
.../share/libtool/libltdl/Makefile.am
.../share/libtool/libltdl/Makefile.in
.../share/libtool/libltdl/README
.../share/
On 6/4/06, Gerald Pfeifer <[EMAIL PROTECTED]> wrote:
I noticed that with a full build (including all of GCJ and libgcj),
we now install a bootload of libtool files into $PREFIX/share:
.../share/libtool/libltdl/COPYING.LIB
.../share/libtool/libltdl/Makefile.am
.../share/libtool/libltdl/Make
On Jun 4, 2006, at 2:59 PM, Gerald Pfeifer wrote:
Is this really necessary? If so, I'd like to understand why?
It is a libtool/libltdl bug which was fixed after GCC imported
the new libltdl.
See
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27818
-- Pinski
Rask Ingemann Lambertsen wrote:
There are other targets with targets specific options to work around this or
that bug, quirk, defect or errata. In this case, why would two options
-mno-byte-writes and -mbyte-writes, with the latter being the default, be
unlikely to be acceptable? In particular, t
Dear maintainer,
Our Co. have a new 32b embedded processor, and we have ported the gcc
backend for it(support c/c++), now we want add its backend code into gcc
packages. i read the "Contributing to GCC " pages that we must sign some
forms, can you kindly send the forms to me?
Best Regards
Liqi
Mark Mitchell wrote:
> This status report has been a long time coming, for which I apologize.
>
> As fwprop is no longer on the table for 4.2, and as the vectorizer
> improvements seem to have stalled due to a combination of lack of review
> and Dorit's leave, I think it's time to declare 4.2 feat
40 matches
Mail list logo
