Citerar Warren D Smith :
Also, I'm somewhat amazed how it is argued to me that a 9-bit machine
the PDP-10 is
covered by C fine, but yet, C insists on having everything a multiple
of 8 bits with padding bits disallowed, and that too is fine, and both
these facts refute me.
Wrong.
The C languag
Quoting Ralf Corsepius :
On 12/13/2012 04:53 PM, Erik Trulsson wrote:
Quoting Ralf Corsepius :
On 12/12/2012 08:54 PM, Robert Dewar wrote:
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest
Quoting Ralf Corsepius :
On 12/12/2012 08:54 PM, Robert Dewar wrote:
On 12/12/2012 2:52 PM, Steven Bosscher wrote:
And as usual: If you use an almost 30 years old architecture, why
would you need the latest-and-greatest compiler technology?
Seriously...
Well the embedded folk often end up w
g does). In short,
> the user would just have to add this option, which should do all
> the magic for debugging.
No, absolutely not. Turning on debugging should not change what the
generated code looks like. Depending on the bug it is quite possible
for changes in optimization to hide the symptoms of the bug, thereby
making it more difficult to track down the bug.
--
Erik Trulsson
ertr1...@student.uu.se
t means a program using zero-length arrays does not conform to C90
(or C99 for that matter) so as far as the C standard is concerned GCC
may do whatever it wants if it encounters a zero-length array.
--
Erik Trulsson
ertr1...@student.uu.se
On Sun, Feb 21, 2010 at 11:35:11PM +, Dave Korn wrote:
> On 21/02/2010 22:42, Erik Trulsson wrote:
>
> > Yes, it does if the user is using binaries compiled by somebody else,
> > and that somebody else did not explicitly specify any CPU-flags.
> >
> > I beli
On Sun, Feb 21, 2010 at 10:59:05PM +0100, Steven Bosscher wrote:
> On Sun, Feb 21, 2010 at 10:07 PM, Erik Trulsson
> wrote:
> >> There is nothing which stops them from using -march=i386. It just may not
> >> be the default.
> >
> > That argument cuts b
On Sun, Feb 21, 2010 at 10:53:54PM +0100, Steven Bosscher wrote:
> On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson wrote:
> > One of the great advantages of much free/open software is the way it
> > will work just fine even on older hardware.
>
> Yes, but that doesn
On Sun, Feb 21, 2010 at 12:27:34PM -0800, H.J. Lu wrote:
> On Sun, Feb 21, 2010 at 12:22 PM, Erik Trulsson
> wrote:
> >>
> >> I agreed that gcc for x86 should choose a sensible default for 95% of
> >> current x86 processors in use. People with those old pro
gt; current x86 processors in use. People with those old processors can
> use older gcc or -march=.
>
> Default to SSE2 is a good first step.
I think you vastly underestimate the number of older x86 processors in
use.
--
Erik Trulsson
ertr1...@student.uu.se
LX series which do not seem
to support SSE at all (only MMX and 3dnow.)
However to answer the original question I believe that all x86
variants that are still actively developed for support at least the
full 80486 instruction set.
> I just wanted to
> make sure that there are no low-end third-
.
What probably would work is to use memcpy() to copy the contents
of an object of type float into another object of type uint32_t and
then use the value of that object. As long as uint32_t does not have
any trap representations that should be safe.
--
Erik Trulsson
ertr1...@student.uu.se
any prohibition against storing a value into an object using an
lvalue of a completely different type, but since you cannot read that
value back there is not much point in doing so.)
Note that most sorts of "type punning" (i.e. treating an object as if
it was of a different type than it actually is) is disallowed by the C
standard.
In particular accessing an array of chars as if it was an array of int is
not allowed any more than accessing an array of int as if it was an
array of float.
--
Erik Trulsson
ertr1...@student.uu.se
;
> But in the new compilers it's an integer type, not a character
> type--from the spec:
A character type is an integer type, so it is quite possible for
uint8_t to qualify both as a character type and as an integer type.
--
Erik Trulsson
ertr1...@student.uu.se
On Wed, Jan 06, 2010 at 07:29:21PM +, Joshua Haberman wrote:
> Erik Trulsson student.uu.se> writes:
> > > int i;
> > > unsigned int *pui = (unsigned int*)&i;
> > > unsigned int ui = *pui;
> >
> > (First I will assume that 'i'
On Wed, Jan 06, 2010 at 04:09:11AM +, Joshua Haberman wrote:
> Erik Trulsson student.uu.se> writes:
> > On Sun, Jan 03, 2010 at 05:46:48AM +, Joshua Haberman wrote:
> > > The aliasing policies that GCC implements seem to be more strict than
> > > what
while '*p2' is
an aggregate type not containing a member of the same type as '*b'.
Moreover accessing (*p1).x) or (*p1).y might also access '*a' (since the type
of '(*p1).x' is compatible with the type of '*a'), but an access to
'(*p1).z' will not access '*a'.
(The obvious situation where accessing *p1 would also access *a is if foo() is
called as follows:
struct S1 A;
foo(&A, &(A.x));
)
--
Erik Trulsson
ertr1...@student.uu.se
memcpy(&some_int, ..., ...) is illegal,
> because memcpy() will write to the int's storage with a pointer type
> other than int.
Your conclusion does not follow since the standard does not say what (if
any) pointer type memcpy() will use internally. It is not even necessary
that memcpy() is implemented in C.
--
Erik Trulsson
ertr1...@student.uu.se
ull pointer, while it is
implementation defined if 'p' is a null pointer or not.
It would be perfectly legal for a compiler to define that code to mean that
'p' is a pointer to address zero, while 'np' is a null pointer which
internally happens to have the same representation as an int with the value
0xdeadbeef.
(On such a system it would of course not be possible to place any real
object at the address 0xdeadbeef since a null pointer does not point to any
real object, but would seem unlikely to be a major problem.)
--
Erik Trulsson
ertr1...@student.uu.se
gether with closing open files and calling
functions registered through atexit(), etc.).
A program that crashed and thus did not call these cleanup routines caused
a memory leak.
--
Erik Trulsson
[EMAIL PROTECTED]
On Sun, Oct 28, 2007 at 06:06:17PM -, Dave Korn wrote:
> On 28 October 2007 17:39, Erik Trulsson wrote:
>
> > On Sun, Oct 28, 2007 at 01:10:00PM -0400, Robert Dewar wrote:
> >> Erik Trulsson wrote:
> >>
> >>> Unfortunately it seems that the POSIX s
On Sun, Oct 28, 2007 at 06:29:44PM +0100, Richard Guenther wrote:
> On 10/28/07, Erik Trulsson <[EMAIL PROTECTED]> wrote:
> > On Sun, Oct 28, 2007 at 03:03:46PM -, Dave Korn wrote:
> > > On 28 October 2007 13:32, Bart Van Assche wrote:
> > >
> > > &
On Sun, Oct 28, 2007 at 01:10:00PM -0400, Robert Dewar wrote:
> Erik Trulsson wrote:
>
>> Unfortunately it seems that the POSIX standard for threads say that as
>> long
>> as access to a shared variable is protected by a mutex there is no need to
>> use 'volat
ion of C/C++
> > and POSIX threads, we can't wait for the respective language
> > standardization committees to come up with a solution.
>
> You already have it, but you have declared it "unacceptable" and refused to
> use it without stating any clear reason.
; load
> adcl $0, %edx; maybe add 1
> movl%edx, acquires_count; store
> leave
> ret
>
What happens if you declare the variables as 'volatile' ?
(There is no guarantee that this will make things better, but it
is very likely.)
--
Erik Trulsson
[EMAIL PROTECTED]
permission to do optimizations that may change
> the end result. In our case when threads are involved the result may
> change, because there's no access to v in the abstract semantics, and
> thus no mutex is required from abstract POV.
>
>
> So, could someone explain me why this GCC optimization is valid, and,
> if so, where lies the boundary below which I may safely assume GCC
> won't try to store to objects that aren't stored to explicitly during
> particular execution path? Or maybe the named bug report is valid
> after all?
>
--
Erik Trulsson
[EMAIL PROTECTED]
On Sat, Jun 23, 2007 at 04:36:02PM -0400, Robert Dewar wrote:
> Erik Trulsson wrote:
>
> >Ken Thompson (one of the original creators of Unix) *did* put such a hack
> >into
> >their C compiler which would automatically add backdoor code when it
> >compiled the &
ogram. This was many years ago and AFAIK the hacked
Unix version was never released into the wild.
You can read more about this hack at
http://en.wikipedia.org/wiki/Thompson_hack or
http://www.acm.org/classics/sep95/
--
Erik Trulsson
[EMAIL PROTECTED]
On Tue, Jul 12, 2005 at 03:08:54PM -0700, Joe Buck wrote:
> On Tue, Jul 12, 2005 at 11:42:23PM +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). Otherwise the
&
ve the values 0 and 1 respectively.)
If the compiler is certain that the pointers do not point into the same
array or structure (as in my first example above) it is probably a good
idea to give a warning, but it should not warn for the legal cases (as in my
second example.)
--
Erik Trulsson
[EMAIL PROTECTED]
30 matches
Mail list logo
