I am chasing a problem with mudflap. Running off uptodate cvs head.
To this end I created a simple test program (attached) which does
many memory malloc/free in a heavily multithreaded environment.
The sample program aborts regularly, while the problem I am after
is different - I get register viola
On Mar 5, 2005, at 12:24 AM, [EMAIL PROTECTED] wrote:
static __inline__ void atomic_add(atomic_t *v, int i)
{
__asm__ __volatile__("addl %1,%0" : "+m" (*v) : "d" (i));
}
Then the compiler complains with:
/asm/atomic.h:33: warning: read-write constraint does not allow a
register
So is the
Waldek Hebisch wrote:
> > > 3) AFAIU dropping support for multiple backends is considered as a
> > > pre-condition to inclusion of GPC into GCC. GPC release wold be
> > > part of GCC release. People trying GPC snapshots would automatically
> > > get backend snapshot. I am affraid that for Pascal t
> static __inline__ void atomic_add(atomic_t *v, int i)
> {
> __asm__ __volatile__("addl %1,%0" : "+m" (*v) : "d" (i));
> }
>
> Then the compiler complains with:
>
> /asm/atomic.h:33: warning: read-write constraint does not allow a register
>
> So is the warning wrong?
Yes, the warning is wr
On Fri, Mar 04, 2005 at 08:06:27PM -0600, Chris Lattner wrote:
> In my mind, the times you want to silence the warning (without defining
> the virtual dtor) are when you *know* that it will never be used that way,
> because it's part of the contract of the class.
In my view, if a class defines v
On Fri, Mar 04, 2005 at 04:33:47PM -0800, Janis Johnson wrote:
> On Tue, Mar 01, 2005 at 04:35:54PM -0500, Daniel Jacobowitz wrote:
> > On Tue, Mar 01, 2005 at 10:29:45AM -0800, Janis Johnson wrote:
> > > Is command line processing relevant for embedded targets? (I have no
> > > idea.) Tests that
On Fri, 4 Mar 2005, Perrin Meyer wrote:
> As someone who writes a lot of computational acoustics code, I'd really like
> to start using these features, or at least have better explanation of what
> is broken and what isn't. I've been using _Complex variables in gcc for a
> while now, and as far as
For quite a while now, the C99 status page has said that both
variable-length arrays and complex (and) imaginary support in complex.h are
Broken.
As someone who writes a lot of computational acoustics code, I'd really like
to start using these features, or at least have better explanation of what
On Fri, 04 Mar 2005 19:15:41 -0600 (CST), Chris Lattner <[EMAIL PROTECTED]>
said:
> It's not a matter of warning vs not warning: it's a matter of
> emitting bogus warnings *sometimes* when you can emit the proper
> warning *all of the time*.
I don't think you can emit the proper warning all of t
On Fri, 4 Mar 2005, Mark Mitchell wrote:
Chris Lattner wrote:
I'm not sure I understand your point here. The library developer writes a
class, and does not *want* it to be destroyed through the base class. As a
library designer, I can intentionally make the dtor protected, making it
pretty cle
On Mar 4, 2005, at 6:57 PM, David Edelsohn wrote:
Edmar Wienskoski writes:
Edmar> I checked with several gcc versions. Some of the spec2k
Edmar> benchmarks has a considerable performance loss when
Edmar> the benchmark is compiled with a 64 bits tool.
Edmar> I looked into the assembler code generate
Chris Lattner wrote:
I'm not sure I understand your point here. The library developer writes
a class, and does not *want* it to be destroyed through the base class.
As a library designer, I can intentionally make the dtor protected,
making it pretty clear that delete should not be called on th
On Fri, 4 Mar 2005, Mark Mitchell wrote:
Chris Lattner wrote:
Age-old debate: better to warn early about possibly broken interfaces, or
late about definitely broken usage? I think that warning early, together
with what DJ is calling fine-grained warning control is the best solution.
I don't agre
Chris Lattner wrote:
Age-old debate: better to warn early about possibly broken interfaces,
or late about definitely broken usage? I think that warning early,
together with what DJ is calling fine-grained warning control is the
best solution.
I don't agree at all on this. It's not a matter of
On Fri, 4 Mar 2005, Mark Mitchell wrote:
I've run into this warning with C++ code as well, and it is quite annoying.
There are lots of possible reasons to want to do this sort of thing, and
adding a virtual dtor increases the size of the vtable for the class.
Yeah, there goes one whole pointer pe
> > 3) AFAIU dropping support for multiple backends is considered as a
> > pre-condition to inclusion of GPC into GCC. GPC release wold be
> > part of GCC release. People trying GPC snapshots would automatically
> > get backend snapshot. I am affraid that for Pascal that means
> > 6-8 months extra
Chris Lattner wrote:
I've run into this warning with C++ code as well, and it is quite
annoying. There are lots of possible reasons to want to do this sort of
thing, and adding a virtual dtor increases the size of the vtable for
the class.
Yeah, there goes one whole pointer per class in your pr
> Certainly porting to 4.x will require private tree codes - for example,
> SET_TYPE is no longer handled in the core code as not being used by any
> integrated language, so it will need to become a private Pascal tree code
> and be lowered in the Pascal gimplification code. There may be other
Snapshot gcc-3.4-20050304 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050304/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050304
You'll
On Tue, Mar 01, 2005 at 04:35:54PM -0500, Daniel Jacobowitz wrote:
> On Tue, Mar 01, 2005 at 10:29:45AM -0800, Janis Johnson wrote:
> > Is command line processing relevant for embedded targets? (I have no
> > idea.) Tests that pass options to the test program could be skipped
> > for embedded tar
> Edmar Wienskoski writes:
Edmar> I checked with several gcc versions. Some of the spec2k
Edmar> benchmarks has a considerable performance loss when
Edmar> the benchmark is compiled with a 64 bits tool.
Edmar> I looked into the assembler code generated for try_route (route.c)
Edmar> (compiled
I checked with several gcc versions. Some of the spec2k
benchmarks has a considerable performance loss when
the benchmark is compiled with a 64 bits tool.
Ex:
175.vpr using:
Reading specs from /usr/lib/gcc-lib/ppc64-yellowdog-linux/3.3.3/specs
Configured with: ../configure --prefix=/usr --mandir=/u
Devang Patel <[EMAIL PROTECTED]> writes:
> invoke.texi mentions following URL for further info on visibility
> #pragmas.
>http://www.nedprod.com/programs/gccvisibility.html
> but it does not exist.
Guess you should take it out, then.
>> Ugh, in the hopes of simplifying the example, I made it somewhat trivial...
>>
>> static __inline__ void atomic_add(atomic_t *v, int i)
>> {
>> __asm__ __volatile__("addl %2,%0" : "=m" (*v) : "m" (*v), "d" (i));
>> }
>>
>> Is that correct? And if so, then isn't the documentation wrong?
invoke.texi mentions following URL for further info on visibility
#pragmas.
http://www.nedprod.com/programs/gccvisibility.html
but it does not exist.
-
Devang
* Jonathan Wakely:
> e.g. this is undefined behaviour:
>
> class Base {};
> class Derived : public Base {};
>
> Base* p = new Derived;
> delete p;
Wouldn't it make more sense to issue the warning at the point of the
delete, then?
Karel Gardas wrote:
Yes, that's undefined, but I just define this class to be able to do:
Foo* f = dynamic_cast(x);
l = f->iiop_version();
there is nothing like delete involved. Anyway, I agree with you that
emit warning about this is probably the right thing to do and so I will
fix my code.
I've
On Fri, 4 Mar 2005, Jonathan Wakely wrote:
> On Fri, Mar 04, 2005 at 03:51:42PM +0100, Karel Gardas wrote:
>
> > I would like to ask if the behaviour of GCC 4.0.0 20050301 is correct or
> > not. I have for example abstract base class like:
> >
> > class Foo
> > {
> > public:
> > virtual unsign
Karel Gardas <[EMAIL PROTECTED]> writes:
> [...]
> class Foo
> {
> public:
> virtual unsigned short
> iiop_version() const = 0;
> };
>
> and when I compile it, GCC emits warning from subject, although this class
> is really abstract and will never be instantiated. [...]
I guess GCC assu
On Tue, Mar 01, 2005 at 11:50:04PM -0500, Peter Barada wrote:
>
> >> which seems to work, but I'm really concerned about the manuals
> >> warning of the input and output operads being in seperate places.
> >>
> >> Which form is correct?
> >
> >static __inline__ void atomic_inc(atomic_t *v)
> >{
>
> From: "E. Weddington" <[EMAIL PROTECTED]>
>> Paul Schlie wrote:
>> After having the chance to experiment a little, it would seem most ideal in
>> the short term to enable GCC to add an explicit target specific attribute to
>> the effective implied __FUNCTION__ declaration; in AVR's case for examp
On Fri, Mar 04, 2005 at 03:51:42PM +0100, Karel Gardas wrote:
> I would like to ask if the behaviour of GCC 4.0.0 20050301 is correct or
> not. I have for example abstract base class like:
>
> class Foo
> {
> public:
> virtual unsigned short
> iiop_version() const = 0;
> };
>
> and when
On Friday 04 March 2005 15:51, Karel Gardas wrote:
>
> Hello,
>
> I would like to ask if the behaviour of GCC 4.0.0 20050301 is correct or
> not. I have for example abstract base class like:
>
> class Foo
> {
> public:
> virtual unsigned short
> iiop_version() const = 0;
> };
hi Karel
Hello,
I would like to ask if the behaviour of GCC 4.0.0 20050301 is correct or
not. I have for example abstract base class like:
class Foo
{
public:
virtual unsigned short
iiop_version() const = 0;
};
and when I compile it, GCC emits warning from subject, although this class
is really
Paul Schlie wrote:
After having the chance to experiment a little, it would seem most ideal in
the short term to enable GCC to add an explicit target specific attribute to
the effective implied __FUNCTION__ declaration; in AVR's case for example:
#define ROM __attribute__((__progmem__)) /* an avr
Julian Brown wrote:
FWIW, a port I did used indirection for all function pointers, albeit
for a different reason, and I can report that it seems to work OK in
practice with a little linker magic. It wasn't really production-quality
code though, I admit.
Perhaps the indirection table can safely hold
하태준 wrote:
> can i convert RTL to original sorce ?
Why don't you say exactly what you
are interested in doing. If you are asking,
can I take the RTL and convert it back to
correct accurate source in any of the front
end languages supported by GCC the answer is
just plain no, but I suspect this is
can i convert RTL to original sorce ?
38 matches
Mail list logo
