i'm working on the topic overhead and codesize in C and C++. The
goal of this work is to find out, why C++ is not as fast as normal C
code (in same application).
Why do you believe this is true?
But already by the beginning we found out something very interesting.
The Code:
int main(int
Paolo Carlini wrote:
Hi,
I mean, why a well designed application should refuse to listen to
ctrl-c when something goes wrong? Why every time for some reason it
gets
stuck, I have to kill it from another shell? That's definitely
annoying.
Paolo.
...
Looks like there's a read
...
The object type is uint8_t, but accessed as uint32_t. That is
undefined.
Unless uint8_t is a character type, as I understand it.
In which way does it make a difference? For aliasing consideration,
only the type of access matters.
The aliasing rules treat char specially because
...
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
struct in6_addr
{
uint8_t __s6_addr[16];
};
static inline int
address_in_use (unsigned char *a, struct in6_addr *in6)
{
if const uint32_t *)(a))[0]
== ((const uint32_t *)(in6-__s6_addr))[0]
This relates to bug 13167
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13617)
It looks like the compiler is generating appropriate code but gas
isn't doing the right thing with it, at least not consistently.
With this test program, compiled with GCC 4.1.2 mipsel-netbsdelf:
int i = 3;
Paul Koning paul_kon...@dell.com writes:
It looks like the compiler is generating appropriate code but gas
isn't doing the right thing with it, at least not consistently.
With this test program, compiled with GCC 4.1.2 mipsel-netbsdelf:
int i = 3;
char foo[17
Frank == Frank Ch Eigler f...@redhat.com writes:
[...] Since the FSF is the copyright owner, even if your reading
is held by someone to be correct, then the FSF's FAQ would count
as an additional permission. [...]
Frank Is anyone else uncomfortable that an important license is to
Frank
The other day there was a request for a compile error if you do:
int foo(void) { }
and the answer was the standard says that this is legal -- after all,
you can say 'foo();' so the return value isn't used and it doesn't
matter that it's missing.
That makes sense.
So how about:
int foo
Joe == Joe Buck joe.b...@synopsys.com writes:
Joe On Wed, Apr 01, 2009 at 10:18:32AM -0700, Paul Koning wrote:
The other day there was a request for a compile error if you do:
int foo(void) { }
and the answer was the standard says that this is legal -- after
all, you can say 'foo
quick == quick qu...@sparq.org writes:
quick I have two questions regarding the use on __restrict__
quick qualifiers for function arguments in C++:
quick 1) How does it interact with volatile?
quick Example, given:
quick void foo(volatile int* __restrict__ p1, volatile int*
quick
Rodrigo == Rodrigo Dominguez rodd...@hotmail.com writes:
Rodrigo H.J, Thanks for replying but this doesn't answer my
Rodrigo question. Shouldn't __asm__ generate the right code without
Rodrigo using the %b1 trick? The reason I am asking is I have a 350
Rodrigo line macro which I can't
Paolo == Paolo Bonzini bonz...@gnu.org writes:
Paolo These are all the !SHIFT_COUNT_TRUNCATED targets. For 4.5 I
Paolo would like to improve our RTL canonicalization so that no
Paolo out-of-range shifts are ever in the RTL representation.
Paolo This in turn means that the description given
I'm seeing messages on this list repeating over and over (several
minutes apart, maybe as much as 15 minutes or so). I'm not sure if
the are just messages from Manuel or also from others.
Is it just me? It seems to be specific to this list...
paul
Joe == Joe Buck [EMAIL PROTECTED] writes:
Joe Paul Koning [EMAIL PROTECTED] writes:
That's sufficient for live debugging but not for corefiles. In
that case you do want caller-saved registers, because they may
contain local variable values that don't live in memory at the
time
Joe == Joe Buck [EMAIL PROTECTED] writes:
Joe ...OK, consider this case:
Joe int func1(int); void func2(int); bool test(void); void
Joe func3(int);
Joe void func(int arg) { int v1 = func1(arg); func2(v1); if (test())
Joe { func3(v1); } }
Joe Here if we put v1 in a register, we obviously
Mark == Mark Kettenis [EMAIL PROTECTED] writes:
Date: Wed, 6 Aug 2008 11:27:36 -0400 From: Daniel Jacobowitz
[EMAIL PROTECTED]
On Wed, Aug 06, 2008 at 07:19:26PM +0400, Sergei Poselenov wrote:
(gdb) bt #0 0x4004ec0c in raise () from /lib/libc.so.6 #1
0x40050234 in abort () from
Joe == Joe Buck [EMAIL PROTECTED] writes:
Joe On Wed, Aug 06, 2008 at 11:54:42AM -0400, Paul Koning wrote:
I think the space savings in noreturn come from not having to
save caller-saved registers in the calling function. That savings
can add up if the noreturn function is called from
Joe == Joe Buck [EMAIL PROTECTED] writes:
Joe I wrote: There are several effects from noreturn. We would
Joe want some of these effects for abort, but not others, to get
Joe debuggable code without degrading compile-time warnings.
Joe On Wed, Aug 06, 2008 at 01:37:51PM -0400, Paul Koning
I was looking for GCC 3.3.3 just now, and noticed that it doesn't
exist on the generic GNU FTP server or its mirrors
(ftp://ftp.gnu.org/gnu/gcc for example). 3.3.2 and 3.3.4 are there,
as well as lots of other releases, but 3.3.3 is mysteriously missing.
It does exist on the specific GCC
Robert == Robert Dewar [EMAIL PROTECTED] writes:
Robert Another general point is that conceptually this is not an
Robert optimization issue at all.
Robert The programmer writes code that is undefined according to the
Robert standard. ...
Robert To me, the whole notion of this
Paul == Paul Schlie [EMAIL PROTECTED] writes:
Paul Mark Mitchell wrote:
...
And:
Addition or subtraction of a pointer into, or just beyond, an
array object and an integer type produces a result that does not
point into, or just beyond, the same array object (6.5.6).
is
Ian == Ian Lance Taylor [EMAIL PROTECTED] writes:
Ian Robert C. Seacord [EMAIL PROTECTED] writes:
What you really mean is, Use an older GCC or some other compiler
that is known not to take advantage of this optimization.
i think we mean what we say, which is *Avoid newer versions of
David == David Woodhouse [EMAIL PROTECTED] writes:
David On Thu, 2008-03-13 at 13:35 -0400, Daniel Berlin wrote:
If by really weird you mean nobody has any real complaints
about the way it works and are happy it is close to what they were
using before, then yes, they are using something
kai-gcc == kai-gcc [EMAIL PROTECTED] writes:
kai-gcc A. There's something similar in the C standard: see
kai-gcc sig_atomic_t. It might be possible to steal some wording
kai-gcc from there.
kai-gcc B. This guarantee - at least as I describe it below - cannot
kai-gcc work for every target.
I'm really wondering why this is being considered.
A documented property of the form GCC will use a single instruction
to do X when possible means exactly nothing. In particular, to call
such a statement a guarantee is seriously misleading.
If Linux needs the single-instruction property for
Andrew == Andrew Haley [EMAIL PROTECTED] writes:
We don't have atomic read or atomic write builtins (ok, you could
abuse __sync_fetch_and_add (x, 0) for atomic read and a loop with
__sync_compare_and_swap_val for atomic store, but that's a
horrible overkill. Being able to assume that
Segher == Segher Boessenkool [EMAIL PROTECTED] writes:
Segher Good point. Suggestions for better wording? How does
Segher any access to a naturally aligned scalar object in memory
Segher that is not a bit-field and fits in a general purpose integer
Segher machine register, will be
Segher == Segher Boessenkool [EMAIL PROTECTED] writes:
As I said before, I think any words of this form SHOULD NOT be
added. All it does is add words to the documentation that provide
NO guarantee of anything -- but in a way that will confuse those
who don't read it carefully enough
Hans-Peter == Hans-Peter Nilsson [EMAIL PROTECTED] writes:
Hans-Peter On Wed, 30 Jan 2008, Ian Lance Taylor wrote:
One issue here is that in some cases const and pure calls can get
combined and eliminated even with attribute noinline (unless this
changed recently). So in addition to
Joseph == Joseph S Myers [EMAIL PROTECTED] writes:
Joseph ... There is good coverage for
Joseph bare-metal ELF targets, but none for bare-metal a.out and
Joseph COFF targets (perhaps we should consider deprecating all of
Joseph those, on the presumption that bare-metal use has moved to
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.
Thanks David.
I fixed my gcc list subscriptions which had become lost at some point
due to malfunctions of internal mailers.
shreyas == shreyas krishnan [EMAIL PROTECTED] writes:
shreyas Hi , I am looking for an efficient data structure to map
shreyas from a range of addresses to a single address. As it is
shreyas used at runtime, I want it to be as efficient as possible,
shreyas with perhaps updaing more
Jonathan == Jonathan Day [EMAIL PROTECTED] writes:
Jonathan Hi, I am trying to compile a toolchain for a Broadcom SB1
Jonathan processor in big-endian mode with a host Operating System
Jonathan of Linux. (The SB1 is a MIPS64, but there is also a
Jonathan specific SB1 target.) So far, I'm
Mike == Mike Stump [EMAIL PROTECTED] writes:
Mike On Sep 6, 2005, at 6:16 PM, Gabriel Dos Reis wrote:
wrong-code generation that was fixed.
Mike Customers validate their app and are `happy' with the code
Mike generation, so this appears to not be a real an issue. Failure
Mike to compile
Richard == Richard Henderson [EMAIL PROTECTED] writes:
Richard On Tue, Aug 23, 2005 at 04:32:42PM -0400, Paul Koning wrote:
1. Why do _builtin_ia32_paddusb and similar functions take signed
vector arguments, when the hardware primitive is defined to
operate on unsigned vectors?
Richard
Two things I'm wondering about:
1. Why do _builtin_ia32_paddusb and similar functions take signed
vector arguments, when the hardware primitive is defined to operate
on unsigned vectors?
2. Why are there no sse equivalents of those functions, ones that
operate on 128 bit values (i.e.,
Mike == Mike Stump [EMAIL PROTECTED] writes:
Mike On Aug 12, 2005, at 10:39 AM, Dale Johannesen wrote:
We had a situation come up here where things are like this
(simplified, obviously):
c() { char x[100]; }
Mike I think we should turn off inlining for functions 100k stack
Mike
Shaun == Shaun Jackman [EMAIL PROTECTED] writes:
Shaun On 8/2/05, Paul Koning [EMAIL PROTECTED] wrote:
It sounds like the workaround is to avoid memcpy, and just use
variable assignment. Alternatively, cast the pointers to char*,
which should force memcpy to do the right thing. Ugh
One of the things that continues to baffle me (and my colleagues) is
the bizarre way in which attributes such as packed work when applied
to structs.
It would be natural to assume, as Shaun did, that marking a struct
packed (or, for that matter, packed,aligned(2)) would apply that
attribute to
Dave == Dave Korn [EMAIL PROTECTED] writes:
Dave Original Message
From: Shaun Jackman Sent: 02 August 2005 20:26
On 8/2/05, Paul Koning [EMAIL PROTECTED] wrote:
One of the things that continues to baffle me (and my colleagues)
is the bizarre way in which attributes
Shaun == Shaun Jackman [EMAIL PROTECTED] writes:
2) Is there padding between the struct members to maintain their
natural alignments (on the assumption that the struct's base
address is aligned.)
Shaun There is no padding. The structure is defined as
Shaun __attribute__((packed)) to
Vincent == Vincent Lefevre [EMAIL PROTECTED] writes:
Vincent On 2005-07-17 12:55:38 -0400, Paul Koning wrote:
Are you sayinvg that a-b is not always guaranteed to work when a
and b point to elements of the same array? That sounds wrong; can
you given an example or standards text
D == D Hugh Redelmeier [EMAIL PROTECTED] writes:
D This is true. And an abomination. But I will explain a bit more
D where this came from. ...
Thanks Doug.
Abomination is a good word for it.
paul
Vincent == Vincent Lefevre [EMAIL PROTECTED] writes:
Vincent On 2005-07-12 23:42:23 +0200, Erik Trulsson wrote:
Pointer subtraction is only well defined if both pointers point to
elements in the same array (or one past the end of the array).
Vincent I don't know what you mean by well
Matthew == Matthew Woodcraft [EMAIL PROTECTED] writes:
Matthew Paul Schlie wrote:
As optimization seems to be a non-argument, as by analogy all
optimizations which are available for unsigned arithmetic are
correspondingly available for signed integer operations; as any
signed value may
Paul == Paul Schlie [EMAIL PROTECTED] writes:
From: Robert Dewar [EMAIL PROTECTED]
Paul Schlie wrote:
What about optimising x*2/2 to x?
Given that C requires the above be evaluated as (x*2)/2, as the
language specifies that the syntax defines the precedence of the
operations, and
Falk == Falk Hueffner [EMAIL PROTECTED] writes:
$ alpha-unknown-linux-gnu-gcc -fno-common -ffreestanding -O2 \
-mno-fp-regs -ffixed-8 -msmall-data -mcpu=ev5 -Wa,-mev6 -c
core_cia.i
Falk I don't see any fault on gcc's side here. You could argue that
Falk the command line option for as
Joseph == Joseph S Myers [EMAIL PROTECTED] writes:
Joseph On Mon, 11 Jul 2005, Michael Cieslinski wrote:
I also could convert parts of the ggcinternals manual into wiki
pages. But only if there is a consensus about this being the way
to go.
Joseph I'm sure it's the wrong way to go. I
Kevin == Kevin Handy [EMAIL PROTECTED] writes:
Kevin Paul Koning wrote:
Joseph == Joseph S Myers [EMAIL PROTECTED] writes:
Joseph On Mon, 11 Jul 2005, Michael Cieslinski wrote:
I also could convert parts of the ggcinternals manual into wiki
pages. But only
Nicholas == Nicholas Nethercote [EMAIL PROTECTED] writes:
Nicholas This point about 33-bit machines is interesting because it
Nicholas raises an optimisation scenario that hasn't been mentioned
Nicholas so far.
Nicholas Consider doing 32-bit integer arithmetic on 64-bit machines
Nicholas
Steven == Steven Bosscher [EMAIL PROTECTED] writes:
Steven Indeed. Frankly this seems likely guess confuses me. It
Steven is already well known that using unsigned types for loop
Steven counters may greatly improve the code gcc can generate for
Steven loops. With wrap-around semantics,
Robert == Robert Dewar [EMAIL PROTECTED] writes:
Robert I am puzzled, why would *ANYONE* who knows C use int rather
Robert than unsigned if they want wrap around semantics?
Because most people don't follow the rule that always use unsigned
variables unless you know that it really needs to be
Gabriel == Gabriel Dos Reis [EMAIL PROTECTED] writes:
Robert Dewar [EMAIL PROTECTED] writes:
Gabriel Dos Reis wrote:
Robert Dewar [EMAIL PROTECTED] writes:
has the semantics that Gabriel Dos Reis wants is not an evaluable
predicate!
You completely missed the point, but I guess it is
Nathan == Nathan Sidwell [EMAIL PROTECTED] writes:
And all useful programs we write rely on undefined behaviour of
one sort or the other, starting with GCC. In the case of
Nathan They do? I thought they usually relied on implementation
Nathan defined, documented extensions or were part
Nathanael == Nathanael Nerode [EMAIL PROTECTED] writes:
Nathanael Paul Koning wrote:
Nathanael == Nathanael Nerode [EMAIL PROTECTED]
writes:
Nathanael * pdp11-*-* (generic only) Useless generic.
I believe this one generates DEC (as opposed to BSD) calling
conventions, so I'd rather
Nathanael == Nathanael Nerode [EMAIL PROTECTED] writes:
Nathanael * pdp11-*-* (generic only) Useless generic.
I believe this one generates DEC (as opposed to BSD) calling
conventions, so I'd rather keep it around. It also generates .s files
that can (modulo a few bugfixes I need to get in) be
Geoffrey == Geoffrey Keating [EMAIL PROTECTED] writes:
Geoffrey Paul Koning [EMAIL PROTECTED] writes:
After some off-line exchanges with Dave Korn, it seems to me that
part of the problem is that the documentation for
-funsafe-math-optimizations is so vague as to have no discernable
Allan == Allan Sandfeld Jensen [EMAIL PROTECTED] writes:
Allan Maybe the real goal like other have mentioned should be to
Allan divide the -ffast-math into multiple switches.
Yes, and document them so both users and implementers can tell what
they mean, which is not currently the case.
Scott == Scott Robert Ladd [EMAIL PROTECTED] writes:
Scott Paul Koning wrote:
Allan Maybe the real goal like other have mentioned should be to
Allan divide the -ffast-math into multiple switches.
Yes, and document them so both users and implementers can tell
what they mean, which
Scott == Scott Robert Ladd [EMAIL PROTECTED] writes:
Scott Richard Henderson wrote:
On Thu, May 26, 2005 at 10:34:14AM -0400, Scott Robert Ladd wrote:
static const double range = PI; // * 2.0; static const double
incr = PI / 100.0;
The trig insns fail with large numbers; an
Kevin == Kevin Handy [EMAIL PROTECTED] writes:
Kevin But, you are using a number in the range of 2^90, only have 64
Kevin bits for storing the floating point representation, and some
Kevin of that is needed for the exponent.
Fair enough, so with 64 bit floats you have no right to expect an
Scott == Scott Robert Ladd [EMAIL PROTECTED] writes:
Scott Dave Korn wrote:
It's difficult to tell from that quote, which lacks sufficient
context, but you *appear* at first glance to be conflating the
fundamental trignometric *functions* with the trignometric
*identities* that are
After some off-line exchanges with Dave Korn, it seems to me that part
of the problem is that the documentation for
-funsafe-math-optimizations is so vague as to have no discernable
meaning.
For example, does the wording of the documentation convey the
limitation that one should only invoke math
Uros == Uros Bizjak [EMAIL PROTECTED] writes:
Uros Hello!
Fair enough, so with 64 bit floats you have no right to expect an
accurate answer for sin(2^90). However, you DO have a right to
expect an answer in the range [-1,+1] rather than the 1.2e+27 that
Richard quoted. I see no words
Gabriel == Gabriel Dos Reis [EMAIL PROTECTED] writes:
Gabriel http://www.gnu.org/software/gcc/codingconventions.html
Gabriel Avoid the use of identifiers or idioms that would prevent
Gabriel code compiling with a C++ compiler. Identifiers such as new
Gabriel or class, that are reserved
Sam == Sam Lauber [EMAIL PROTECTED] writes:
The documentation for -fvisibility=hidden suggets that this
switch is useful for shared libraries, to make things smaller
and faster. It doesn't seem to be appropriate for object
libraries.
It's done *exactly* so that we catch this bug
Richard == Richard Henderson [EMAIL PROTECTED] writes:
Richard On Wed, May 18, 2005 at 11:32:51AM -0400, Paul Koning wrote:
What surprises me is that it's normally ok to mix static and
shared libs, but not here. And the message is utterly
uninformative about what is wrong or why
Richard == Richard Henderson [EMAIL PROTECTED] writes:
Richard On Wed, May 18, 2005 at 01:04:15PM -0400, Paul Koning wrote:
Fine, but are GCC *users* expected to search the GCC list
archives?
Richard If they want to know the answer to why, as opposed to
Richard being satisfied with don't
I'm upgrading to V4.0.0 and struggling with some code that's seriously
into templates. One puzzling error is this one:
keyed_obj.hh:159: error: no matching function for call to
'CxnIndex::CxnIndex(CxnIndex)'
Indeces.hh:150: note: candidates are: CxnIndex::CxnIndex(CxnIndex)
Indeces.hh:145:
Gabriel == Gabriel Dos Reis [EMAIL PROTECTED] writes:
Gabriel Joe is right. But I think the diagnostic is very very
Gabriel confusing and it is not obvious what was going from the type
Gabriel signature. Please fill a bugzilla PR and ask for diagnostic
Gabriel enhancement.
Thanks, that's
Robert == Robert Dewar [EMAIL PROTECTED] writes:
Robert Peter Barada wrote:
We're not talking about 5% speedup; if the linker starts
thrashing because of insufficient memory you pay far more than
that. And certainly anyone with an older computer who is
dissatified with its performance,
I ran into link errors complaining about references to hidden symbol
_Unwind_GetIP from a DSO.
It turns out unwind-dw2.c is compiled with -fvisibility=hidden for the
static library case (but not for the shared library case).
In my link, I was using the libgcc.a (for that particular platform I
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel On Fri, May 13, 2005 at 05:33:21PM -0400, Paul Koning wrote:
I ran into link errors complaining about references to hidden
symbol _Unwind_GetIP from a DSO.
It turns out unwind-dw2.c is compiled with -fvisibility=hidden
Geoffrey == Geoffrey Keating [EMAIL PROTECTED] writes:
Geoffrey Paul Koning [EMAIL PROTECTED] writes:
Still, never mind what the C spec appears to say, optimizing away
the cast cannot possibly what the user intended.
Geoffrey The user might have written a routine which takes a
Geoffrey
Florian == Florian Weimer [EMAIL PROTECTED] writes:
Florian Indeed. Explicitly pushing an exception frame pointer on
Florian the main stack is covered by the patent.
Oh, like VMS has done since V1.0, in 1978?
paul
Kai == Kai Henningsen [EMAIL PROTECTED] writes:
Kai As a QOI issue, it would be nice if such a situation caused a
Kai warning (ignoring volatile cast ... or something like that).
Kai It's rather dangerous to have the user believe that this worked
Kai as intended when it didn't.
Definitely.
James == James E Wilson James writes:
James Jonathan Bastien-Filiatrault wrote:
* We have defined BIT_PER_WORD to 16 and UNITS_PER_WORD to 1. On
this DSP, there are two 40-bits accumulators. How do we make GCC
take advantage of this and which machine mode do we use ?
James GCC has
Dale == Dale Johannesen [EMAIL PROTECTED] writes:
Dale On May 4, 2005, at 5:06 AM, Gabriel Dos Reis wrote:
Andrew Haley [EMAIL PROTECTED] writes:
| Nathan Sidwell writes: | Dale Johannesen wrote:
|
| And we don't have to document the behavior at all; it is not
documented |
James == James E Wilson James writes:
James On Wed, 2005-05-04 at 06:00, Paul Koning wrote:
I wonder if the work-in-progress PDP10 port
(http://pdp10.nocrew.org/gcc/) might help with this.
James Interesting, but a hobbyist port for a 36-bit machine that was
James end-of-lifed about 2
Daniel == Daniel Jacobowitz [EMAIL PROTECTED] writes:
Daniel On Wed, May 04, 2005 at 04:15:53PM -0400, Paul Koning wrote:
OUCH.
Some of the types in question are probably not used in the program
-- they are there for debugging. It's disturbing to see this sort
of incompatibility
Nathan == Nathan Sidwell [EMAIL PROTECTED] writes:
Nathan Dale Johannesen wrote:
However, as a QOI issue, I believe the compiler should treat the
reference as volatile if either the object or the lvalue is
volatile. That is obviously the user's intent.
Nathan I'm not disagreeing with
This test program:
struct bar;
template class T struct bar *foo (T *p)
{
return p-t;
}
produces an error in 4.0.0:
test.cc:3: error: ??bar?? is not a template type
Without the keyword struct it compiles fine. Earlier versions
(3.3.2, and I'm pretty sure 3.4.1 as well) don't complain.
Andrew == Andrew Pinski [EMAIL PROTECTED] writes:
However, I can always tell when a GCC build has hit the libjava
build -- that's when the *whole system* suddenly slows to a crawl.
Maybe it comes from doing some processing on 5000 foo.o files all
at once... :-(
Andrew But that is not
PhilipG == Philip George [EMAIL PROTECTED] writes:
What did you really mean?
PhilipG I need to install gcc into a disk image that will accompany
PhilipG a gui application i'm writing.
PhilipG ...the entire package (gui app + disk image with gcc) will be
PhilipG downloadable, so obviously
Robert == Robert Dewar [EMAIL PROTECTED] writes:
Robert Paul Koning wrote:
Robert == Robert Dewar [EMAIL PROTECTED] writes:
Robert Ken Raeburn wrote:
That's what I thought. So, unless the compiler (or language
spec) is going to become thread-aware, any data to be shared
across
Marcin == Marcin Dalecki [EMAIL PROTECTED] writes:
Marcin Templates are a no-go for a well known and well defined
Marcin subset for C++ for embedded programming known commonly as
Marcin well embedded C++.
I don't think that's a good argument. If people want to emasculate
the language,
Ralf == Ralf Corsepius [EMAIL PROTECTED] writes:
Ralf struct entrystruct * entry __attribute__ ((packed));
Ralf is interpreted as packed pointer to struct not as pointer to
Ralf packed struct, i.e. this construct is not meaningful.
Yes it's meaningful, it may not be what you intended.
It
Paul == Paul Schlie [EMAIL PROTECTED] writes:
Michael N. Moran wrote: I'm very much in favor of fine grained
synchronization primitives in the compiler, but not of changes to
volatile semantics.
Paul I wonder if it would be sufficient (if not preferable) to only
Paul extend (modify) the
E == E Weddington [EMAIL PROTECTED] writes:
E Paul Koning wrote:
It sure would be useful, though, if there were a construct that
does mean pointer to packed T. In particular, I've often needed
pointer to packed int and found no way to produce that. I ended
up creating a one-member
E == E Weddington [EMAIL PROTECTED] writes:
E Paul Koning wrote: According to the docs here:
E
http://gcc.gnu.org/onlinedocs/gcc-3.4.3/gcc/Type-Attributes.html#Type-Attributes
E what about doing something like this?:
E typedef int packed_int __attribute__ ((aligned (1)));
E
Dave == Dave Korn [EMAIL PROTECTED] writes:
Dave Doesn't the C language spec require the mode to be switchable
Dave at runtime?
Dave In any case, the ARM or Alpha isn't prevented from working in
Dave such a fashion just because the rounding mode is encoded in the
Dave instruction; it just
Marcin == Marcin Dalecki [EMAIL PROTECTED] writes:
Marcin On 2005-04-15, at 20:18, Mike Stump wrote:
On Thursday, April 14, 2005, at 08:48 PM, Marcin Dalecki wrote:
Templates are a no-go for a well known and well defined subset
for C++ for embedded programming known commonly as well
Michael == Michael N Moran [EMAIL PROTECTED] writes:
Michael Jason Merrill wrote:
One proposed change is to the semantics of volatile.
Michael Since IANALL, but I believe (as obviously you do) that
Michael changing the semantics of volatile should be under-taken
Michael with great care.
Andrew == Andrew Pinski [EMAIL PROTECTED] writes:
Andrew Yes it might be a silent miscompiling but there is an easy
Andrew work around, use a temporary variable, ...
I'm not sure how there can ever be an easy workaround to silent
miscompiles -- by definition you may not know there is a
tm == tm gccmail [EMAIL PROTECTED] writes:
tm On 25 Mar 2005, Ian Lance Taylor wrote:
Safe but very costly. It assumes that every processor has a cheap
way to save and restore the condition codes in user mode, which is
not necessarily the case. And it assumes that the save and
restore
401 - 495 of 495 matches
Mail list logo
