Joseph S. Myers wrote:
The new Integrated Register Allocator is now in GCC trunk, and the old
allocator is scheduled for removal on or shortly after 25 September. All
GCC targets need updating for the new allocator; targets that have not
been updated when the old allocator is removed will no l
Joseph S. Myers wrote:
The new Integrated Register Allocator is now in GCC trunk, and the old
allocator is scheduled for removal on or shortly after 25 September. All
GCC targets need updating for the new allocator; targets that have not
been updated when the old allocator is removed will no l
The new Integrated Register Allocator is now in GCC trunk, and the old
allocator is scheduled for removal on or shortly after 25 September. All
GCC targets need updating for the new allocator; targets that have not
been updated when the old allocator is removed will no longer work and
will be
Snapshot gcc-4.2-20080827 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080827/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Status
==
The 4.3.2 release is now available from gcc.gnu.org and ftp.gnu.org
(except for a random subset of files that ftp.gnu.org appears to have
ignored for no reason evident to me). The announcement will be sent
to gcc-announce once some time has been allowed for mirrors to be
updated. T
Bonjour,
Oui je dis quel catastrophe! J'ai simplement doubler
mes ventes en quelques mois au lieu de les tripler!
Heureusement, que ce doublement de mes ventes s'est
stabilisé et a même tendance à encore augmenter!
Si vous êtes comme moi et que vous avez un site internet,
une newsletter, un bl
On Wed, Aug 27, 2008 at 12:36 PM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Wed, 27 Aug 2008, Brian Dessent wrote:
>
>> "H.J. Lu" wrote:
>>
>> > For Linux/x86, if gcc is configured for xxx-*-linux, the default arch
>> > should
>> > be xxx for both 32bit and 64bit, where xxx can be i[3456]86,
On Wed, Aug 27, 2008 at 11:47 AM, Jay <[EMAIL PROTECTED]> wrote:
>
>> "(volatile*)
>
> So this is using implied int then?
> Isn't that really considered to be avoided these days? Or perfectly ok in C?
> I know it is "legal", but I assume to be avoided as a matter of taste and C++
> compat.
> Or yo
On Wed, 27 Aug 2008, Brian Dessent wrote:
> "H.J. Lu" wrote:
>
> > For Linux/x86, if gcc is configured for xxx-*-linux, the default arch should
> > be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ...
> > x86-64. Is someone working on such a patch?
>
> IMHO making this Linu
On Wed, Aug 27, 2008 at 10:31:24PM +0530, Aaron P. D'Souza wrote:
> i have a C file that has been compiled for Thumb mode. in it, i am
> using ARM inline assembly code. apparently, GCC issues no error
> message but forcibly converts the ARM code into Thumb code.
It's just being disassembled wrong;
"H.J. Lu" wrote:
> For Linux/x86, if gcc is configured for xxx-*-linux, the default arch should
> be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ...
> x86-64. Is someone working on such a patch?
IMHO making this Linux specific just replaces one confusing and
arbitrary deci
> "(volatile*)
So this is using implied int then?
Isn't that really considered to be avoided these days? Or perfectly ok in C?
I know it is "legal", but I assume to be avoided as a matter of taste and C++
compat.
Or you can really omit the type I think not. Might be a nice extension
though
On Wed, Aug 27, 2008 at 11:02 AM, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Joseph S. Myers wrote:
>
>> Users of those systems should configure for i586-linux-gnu or
>> i486-linux-gnu not i686-linux-gnu. config.guess should select such a
>> target automatically in the case of a native build. (If
On Wed, Aug 27, 2008 at 05:55:19PM +, Joseph S. Myers wrote:
> On Wed, 27 Aug 2008, Joe Buck wrote:
>
> > Joseph again:
> > > > operations. (And I hold that i686-* should mean -march=i686 default not
> > > > -mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64,
> > > > subje
Joseph S. Myers wrote:
> Users of those systems should configure for i586-linux-gnu or
> i486-linux-gnu not i686-linux-gnu. config.guess should select such a
> target automatically in the case of a native build. (If you configure
> glibc for i686-linux-gnu, it will use assembly sources that r
Joseph S. Myers wrote:
The test will always compile, but sometimes the result will have
references to the __sync_* functions in the output. Then, for certain
targets where these functions are defined in a library, the result will
link. (The only targets where these are defined in a library ar
On Wed, 27 Aug 2008, Joe Buck wrote:
> Joseph again:
> > > operations. (And I hold that i686-* should mean -march=i686 default not
> > > -mcpu=i386 and similarly x86_64-* -m32 should default to -march=x86_64,
> > > subject to --with-arch etc. in both cases.)
>
> I'm not keen on moving the defaul
On Wed, 27 Aug 2008, Paolo Carlini wrote:
> Hi,
> > One significant case is where atomic operations are available with kernel
> > help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed
> > patch to do the same for ARM GNU/Linux; both use kernel help in those
> > implementations
On Wed, Aug 27, 2008 at 10:15 AM, Joseph S. Myers
> > glibc has certainly required -march=i486 or greater for some time to build
> > for IA32; it will fail to link for -march=i386 because of missing atomic
On Wed, Aug 27, 2008 at 10:26:32AM -0700, H.J. Lu wrote:
> Given that glibc requires -marc
Paolo Carlini:
Peter Dimov wrote:
The problem, from the point of view of a library such as
boost::shared_ptr, is that there is no way to distinguish between user A,
who just types g++ foo.cpp and expects to get a program that works well
on a typical machine, and user B, who types g++ -march=i386
Hi,
One significant case is where atomic operations are available with kernel
help. SH GNU/Linux provides __sync_* in libgcc and there is an unreviewed
patch to do the same for ARM GNU/Linux; both use kernel help in those
implementations, and more targets may do this in future. (It's been
pr
On Wed, Aug 27, 2008 at 10:15 AM, Joseph S. Myers
<[EMAIL PROTECTED]> wrote:
> On Fri, 22 Aug 2008, Richard Henderson wrote:
>
>> H.J. Lu wrote:
>> > Can we declare that Linux/ia32 generates i486 insn by default?
>>
>> We the gcc team? I'm not sure. For now I'll say no.
>>
>> We an individual lin
On Fri, 22 Aug 2008, Richard Henderson wrote:
> H.J. Lu wrote:
> > Can we declare that Linux/ia32 generates i486 insn by default?
>
> We the gcc team? I'm not sure. For now I'll say no.
>
> We an individual linux distributor? Certainly.
> In fact I would be surprised if i586 wasn't a
> decent
hello:
one small question regarding use of ARM inline assembly code in a
C file that has been compiled for Thumb mode.
is it possible to use ARM assembly code from within a C file that
has been compiled for Thumb and Thumb interworking?
how this is done is described on this page:
http://www.dev
Daniel Jacobowitz wrote on 27 August 2008 16:15:
> On Wed, Aug 27, 2008 at 02:45:25PM +0100, Dave Korn wrote:
>> Jay wrote on 27 August 2008 09:55:
>>
>>> Yeah that's probably ok.
>>> Volatile is enough to force the ordering?
>>
>> Absolutely; it's a defined part of the standard that all volat
On Wed, Aug 27, 2008 at 02:45:25PM +0100, Dave Korn wrote:
> Jay wrote on 27 August 2008 09:55:
>
> > Yeah that's probably ok.
> > Volatile is enough to force the ordering?
>
> Absolutely; it's a defined part of the standard that all volatile
> side-effects must complete in-order. GCC will not
Andrew Thomas Pinski wrote:
On Aug 27, 2008, at 0:27, Jay <[EMAIL PROTECTED]> wrote:
size = getpagesize(); \
mask = ~((long) size - 1);
Or even better store size after the store to mask.
That is:
int tmp = getpagesize();
*(volatile*)&mask = ~((long)tm
Jay wrote on 27 August 2008 09:55:
> Yeah that's probably ok.
> Volatile is enough to force the ordering?
Absolutely; it's a defined part of the standard that all volatile
side-effects must complete in-order. GCC will not move code past a volatile
operation.
> I still like just not caching ma
NightStrike wrote on 27 August 2008 02:17:
> On 8/26/08, David Daney wrote:
>> Paul Koning wrote:
>>> 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.
Peter Dimov wrote:
The problem, from the point of view of a library such as
boost::shared_ptr, is that there is no way to distinguish between user
A, who just types g++ foo.cpp and expects to get a program that works
well on a typical machine, and user B, who types g++ -march=i386
foo.cpp, wit
Jay <[EMAIL PROTECTED]> writes:
> configure CFLAGS='-V 3.4.4' doesn't work because:
>
>
> configure:3291: i686-pc-cygwin-gcc -o conftest.exe -V 3.4.4 -mno-cygwin -g
> co
> nftest.c >&5
> i686-pc-cygwin-gcc: '-V' must come at the start of the command line
> configure:3294: $? = 1
> configure:33
configure CFLAGS='-V 3.4.4' doesn't work because:
configure:3291: i686-pc-cygwin-gcc -o conftest.exe -V 3.4.4 -mno-cygwin -g co
nftest.c >&5
i686-pc-cygwin-gcc: '-V' must come at the start of the command line
configure:3294: $? = 1
configure:3312: error: cannot compute suffix of executables:
Yeah that's probably ok.
Volatile is enough to force the ordering?
I still like just not caching mask.
Is "volatile*" legal or just pseudo?
Some platforms cache neither.
Are some platforms getpagesize slow and others fast?
Or it's just "random evolution"?
If it's just "random", and nobody knows g
gcc 4.3.1 with small patches... (merged tree with binutils 2.18/gmp/mpfr, also
slightly patched)
build=i686-pc-cygwin
host=i686-pc-cygwin
target=i686-pc-mingw32
configure: /obj/gcc.1/i686-pc-cygwin/i686-pc-mingw32/i686-pc-mingw32/libstdc++-v
3/../libgomp/omp.h not found
checking for p
Sent from my iPhone
On Aug 27, 2008, at 0:27, Jay <[EMAIL PROTECTED]> wrote:
gcc 4.3.1
config/darwin.h:
#define
ENABLE_EXECUTE_STACK\
extern void __enable_execute_stack (void
*);\
void
gcc 4.3.1, with minor patches
build=host=i686-pc-cygwin
target=i686-pc-mingw32
sys-root setup how I believe is appropriatev
(well, er, um..maybe not, due to later problems, but I don't think that's the
problem here;
there indeed varying declarations of getpagesize)
=>
/obj/g
gcc 4.3.1
config/darwin.h:
#define ENABLE_EXECUTE_STACK\
extern void __enable_execute_stack (void *);\
void\
__enable_execute_s
37 matches
Mail list logo
