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
> "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-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 a
> "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 mea
> "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 o
> "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
>>
>>>>> "Kevin" == Kevin Handy <[EMAIL PROTECTED]> writes:
Kevin> Paul Koning wrote:
>>>>>>> "Joseph" == Joseph S Myers <[EMAIL PROTECTED]> writes:
>>>>>>>
>>>>>>>
>>
J
> "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 wron
> "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
> "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
> "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 poi
> "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 n
> "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
> "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
>>>>> "Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]> writes:
Nathanael> Paul Koning wrote:
>>>>>>> "Nathanael" == Nathanael Nerode <[EMAIL PROTECTED]>
>>>>>>> writes:
>>
Nathanael>
> "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 g
>>>>> "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
>
>>>>> "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 user
> "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 ca
> "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.
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
> "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
>> *identiti
> "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
> "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 w
> "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 r
>>>>> "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 t
>>>>> "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 messa
> "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 tha
> "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.
Tha
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: note
> "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
>>>>> "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.
>
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
don
>>>>> "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.
G
> "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
>>>>> "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 the
>>>>> "Daniel" == Daniel Jacobowitz <[EMAIL PROTECTED]> writes:
Daniel> On Wed, May 04, 2005 at 03:53:35PM -0400, Paul Koning wrote:
>> I'm doing some tests to see if 4.0.0 will improve our debug
>> experience, which is mixed indeed with c
I'm doing some tests to see if 4.0.0 will improve our debug
experience, which is mixed indeed with complex C++ code and 3.3.3.
So far it looks like things are MUCH worse. I built my application
and looked at it with GDB. Many of the structure names are missing.
I did some checking with readelf,
>>>>> "James" == James E Wilson 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 3
> "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
> "James" == James E Wilson 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
This test program:
struct bar;
template 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.
> "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 di
> "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>
>>>>> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> On Wednesday 27 April 2005 22:06, Paul Koning wrote:
>> Isn't a full bootstrap (all languages) part of the required test
>> procedure for changes? That's what the webs
> "Steven" == Steven Bosscher <[EMAIL PROTECTED]> writes:
Steven> On Wednesday 27 April 2005 17:45, Matt Thomas wrote:
>> If no one builds natively on older platforms, the recognition that
>> the new features maybe a problem for older platforms will never be
>> made.
Steven> Maybe the o
> "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,
>>>>> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
Robert> Paul Koning wrote:
>>>>>>> "Robert" == Robert Dewar <[EMAIL PROTECTED]> writes:
>>
Robert> Ken Raeburn wrote:
>> >> That's w
> "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
>> threads needs to be declared volatile, even if some other
>> mechanis
> "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 comm
>>>>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
Dave> ----Original Message
>> From: Paul Koning Sent: 15 April 2005 17:56
>>>>>>> "Dave" == Dave Korn <[EMAIL PROTECTED]> writes:
>>
Dave> Doesn&#x
> "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> instruct
>>>>> "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" == 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
>> "
> "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> ext
> "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
> "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 la
> "Jason" == Jason Merrill <[EMAIL PROTECTED]> writes:
Jason> On Thu, 14 Apr 2005 15:47:44 -0500, Robert Dewar
Jason> <[EMAIL PROTECTED]> wrote:
>> [Ada standard]
Jason> Yep, sounds a lot like C/C++: volatile reads and writes are
Jason> required to have sequential ordering relative to ea
> "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
> "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
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> Georg Bauhaus <[EMAIL PROTECTED]> writes:
>> | A busy-loop function is used to effect a delay, not too precise,
>> | but portably. Like
>> |
>> | #define COUNT 1000
>> |
>> | void f() { | /*volatile*/ /*register*/ int i;
>> |
>>
> "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 sav
301 - 363 of 363 matches
Mail list logo
