Re: Two suggestions for gcc C compiler to extend C language (by WD Smith)

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.

Re: Deprecate i386 for GCC 4.8?

Quoting Ralf Corsepius ralf.corsep...@googlemail.com: On 12/13/2012 04:53 PM, Erik Trulsson wrote: Quoting Ralf Corsepius ralf.corsep...@googlemail.com: 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

Re: Deprecate i386 for GCC 4.8?

Quoting Ralf Corsepius ralf.corsep...@googlemail.com: 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

Re: RFC: -Wall by default

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. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: Not conform to c90?

may do whatever it wants if it encounters a zero-length array. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: Change x86 default arch for 4.5?

the number of older x86 processors in use. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: Change x86 default arch for 4.5?

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 ertr1...@student.uu.se wrote: I agreed that gcc for x86 should choose a sensible default for 95% of current x86 processors in use. People with those old processors can use older gcc

Re: Change x86 default arch for 4.5?

On Sun, Feb 21, 2010 at 10:53:54PM +0100, Steven Bosscher wrote: On Sun, Feb 21, 2010 at 9:22 PM, Erik Trulsson ertr1...@student.uu.se 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't change

Re: Change x86 default arch for 4.5?

On Sun, Feb 21, 2010 at 10:59:05PM +0100, Steven Bosscher wrote: On Sun, Feb 21, 2010 at 10:07 PM, Erik Trulsson ertr1...@student.uu.se wrote: There is nothing which stops them from using -march=i386. It just may not be the default. That argument cuts both ways you know

Re: Change x86 default arch for 4.5?

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 believe that is the situation when installing

Re: Change x86 default arch for 4.5?

developed for support at least the full 80486 instruction set. I just wanted to make sure that there are no low-end third-party cores made recently (say, by Cyrix, VIA, or someone else) that lack atomics. I guess that the answer is no. -- Insert your favourite quote here. Erik Trulsson ertr1

Re: strict aliasing violation

of that object. As long as uint32_t does not have any trap representations that should be safe. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

possible for uint8_t to qualify both as a character type and as an integer type. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: Sorry to mention aliasing again, but is the standard IN6_ARE_ADDR_EQUAL really wrong?

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. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: GCC aliasing rules: more aggressive than C99?

On Wed, Jan 06, 2010 at 04:09:11AM +, Joshua Haberman wrote: Erik Trulsson ertr1013 at 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 is in the C99 standard. I am

Re: GCC aliasing rules: more aggressive than C99?

On Wed, Jan 06, 2010 at 07:29:21PM +, Joshua Haberman wrote: Erik Trulsson ertr1013 at student.uu.se writes: int i; unsigned int *pui = (unsigned int*)i; unsigned int ui = *pui; (First I will assume that 'i' will be assigned some value, to make sure it does not contain

Re: GCC aliasing rules: more aggressive than C99?

*p1 would also access *a is if foo() is called as follows: struct S1 A; foo(A, (A.x)); ) -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: GCC aliasing rules: more aggressive than C99?

type memcpy() will use internally. It is not even necessary that memcpy() is implemented in C. -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: Serious code generation/optimisation bug (I think)

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.) -- Insert your favourite quote here. Erik Trulsson ertr1...@student.uu.se

Re: Memory leaks in compiler

through atexit(), etc.). A program that crashed and thus did not call these cleanup routines caused a memory leak. -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED]

Re: Optimization of conditional access to globals: thread-unsafe?

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. cheers, DaveK -- Can't think of a witty .sigline today -- Insert your favourite quote here. Erik Trulsson

Re: Optimization of conditional access to globals: thread-unsafe?

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 'volatile'. How does it say this, in some

Re: Optimization of conditional access to globals: thread-unsafe?

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: Requiring that all thread-shared variables should

Re: Optimization of conditional access to globals: thread-unsafe?

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 standard for threads say that as long as access

Re: Optimization of conditional access to globals: thread-unsafe?

; 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.) -- Insert your favourite quote here. Erik

Re: Optimization of conditional access to globals: thread-unsafe?

to objects that aren't stored to explicitly during particular execution path? Or maybe the named bug report is valid after all? -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED]

Re: old intentional gcc bug?

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/ -- Insert your favourite quote here. Erik Trulsson [EMAIL PROTECTED]

Re: old intentional gcc bug?

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 'login' program. This was many years ago

Re: Pointers in comparison expressions

quote here. Erik Trulsson [EMAIL PROTECTED]

Re: Pointers in comparison expressions

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 behaviour is undefined