Steve Kargl writes:
>> The ChangeLog entry says that if --enable-build-poststage1-with-cxx is
>> set, C++ becomes a boot language. That is what you are seeing. I guess
>> what the ChangeLog entry does not say is that
>> --enable-build-poststage1-with-cxx is set by default.
>>
>
> What are the
On Fri, Aug 05, 2011 at 06:51:12PM -0700, Ian Lance Taylor wrote:
> Thomas Koenig writes:
>
> > I just noticed that C++ now appears to be built by default, even when
> > only the C and fortran are specified. The configure line
> >
> >
> > ../trunk/configure --prefix=$HOME --enable-languages=c,f
Thomas Koenig writes:
> I just noticed that C++ now appears to be built by default, even when
> only the C and fortran are specified. The configure line
>
>
> ../trunk/configure --prefix=$HOME --enable-languages=c,fortran
> --with-mpc=/usr/local --with-mpfr=/usr/local
>
> leads to the message
>
Please replace or augment the
alphaev68-dec-osf5.1a Test results: 4.4.6,
in
http://gcc.gnu.org/gcc-4.4/buildstat.html
from
http://gcc.gnu.org/ml/gcc-testresults/2011-05/msg00074.html
to
http://gcc.gnu.org/ml/gcc-testresults/2011-08/msg00586.html
The reason is explained at the top of the summary:
On Sat, Aug 06, 2011 at 12:52:02AM +0200, Thomas Koenig wrote:
> Hello world,
>
> I just noticed that C++ now appears to be built by default, even when
> only the C and fortran are specified. The configure line
>
>
> ../trunk/configure --prefix=$HOME --enable-languages=c,fortran
> --with-mpc
Hello world,
I just noticed that C++ now appears to be built by default, even when
only the C and fortran are specified. The configure line
../trunk/configure --prefix=$HOME --enable-languages=c,fortran
--with-mpc=/usr/local --with-mpfr=/usr/local
leads to the message
checking for versi
Snapshot gcc-4.6-20110805 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.6-20110805/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
> >
> > In a way I like the current scheme since it is simple and extending it
> > should IMO have some good reason. We could refine -Os behaviour without
> > changing current predicates to optimize for speed in
> > a) functions declared as "hot" by user and BBs in them that are not proved
> > cold
This is the beta release of binutils 2.21.53.0.2 for Linux, which is
based on binutils 2011 0804 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
>
> In a way I like the current scheme since it is simple and extending it
> should IMO have some good reason. We could refine -Os behaviour without
> changing current predicates to optimize for speed in
> a) functions declared as "hot" by user and BBs in them that are not proved
> cold.
> b) based
Nope, I don't use those :-)
DJ Delorie wrote:
> Was this reproducible for m32c also? I can test it if so...
The patch simply passes the destination address space through
to MODE_CODE_BASE_REG_CLASS and REGNO_MODE_CODE_OK_FOR_BASE_P,
to allow targets to make register allocation decisions based
on address space.
As long as
Was this reproducible for m32c also? I can test it if so...
Am Fri 05 Aug 2011 07:49:49 PM CEST schrieb Xinliang David Li
:
On Fri, Aug 5, 2011 at 12:32 AM, Richard Guenther
wrote:
On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
Did you try using FDO with -Os? FDO should make hot code parts
optimized similar to -O3 but leave other pieces optimi
Hello!
Attached patch introduces generation of addr32 prefixed addresses,
mainly intended to merge ZERO_EXTRACTed LEA calculations into address.
After fixing various inconsistencies with "o" constraints, the patch
works surprisingly well (in its current form fixes all reported
problems in the PR
On Fri, Aug 5, 2011 at 12:32 AM, Richard Guenther
wrote:
> On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
Did you try using FDO with -Os? FDO should make hot code parts
optimized similar to -O3 but leave other pieces optimized for size.
Using FDO with -O3 gives you the opposit
On Fri, Aug 5, 2011 at 7:40 AM, Jan Hubicka wrote:
> Am Fri 05 Aug 2011 09:32:05 AM CEST schrieb Richard Guenther
> :
>
>> On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
>
> Did you try using FDO with -Os? FDO should make hot code parts
> optimized similar to -O3 but leave other
gcc-python-plugin [1] now provides a gcc-with-cpychecker harness that
runs gcc with an additional pass that checks CPython API calls
(internally, it's using the gcc python plugin to run a python script
that does the work).
I tried rebuilding the plugin using
make CC=../other-build/gcc-with-cpych
Am Fri 05 Aug 2011 09:32:05 AM CEST schrieb Richard Guenther
:
On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
Did you try using FDO with -Os? FDO should make hot code parts
optimized similar to -O3 but leave other pieces optimized for size.
Using FDO with -O3 gives you the opposite, col
Michael Matz wrote:
> On Fri, 5 Aug 2011, Ulrich Weigand wrote:
> > Instead, if you just have a address and you don't know ahead of time
> > whether it refers to Flash or RAM space, you ought to hold that number
> > in an "int" (or "short" or whatever integer type is most appropriate),
> > and then
Hi,
On Fri, 5 Aug 2011, Ulrich Weigand wrote:
> > However, there are situations like the following where you like to take
> > the decision at runtime:
> >
> > char cast_3 (char in_pgm, void * p)
> > {
> > return in_pgm ? (*((char __pgm *) p)) : (*((char *) p));
> > }
>
> That's really an a
Georg-Johann Lay wrote:
> AVR hardware has basically three address spaces:
[snip]
OK, thanks for the information!
> Of course, RAM and Flash are no subsets of each other when regarded as
> physical memory, but they are subsets when regarded as numbers. This
> lead to my mistake to define RAM and
Ulrich Weigand schrieb:
Georg-Johann Lay wrote:
Ulrich Weigand wrote:
I'd be happy to bring this up to date if you're willing to work with
me to get this tested on a target that needs this support ...
Just attached a patch to bugzilla because an AVR user wanted to play
with the AS support a
Georg-Johann Lay wrote:
> Ulrich Weigand wrote:
> > I'd be happy to bring this up to date if you're willing to work with
> > me to get this tested on a target that needs this support ...
>
> Just attached a patch to bugzilla because an AVR user wanted to play
> with the AS support and asked me to
Georg-Johann Lay wrote:
> Ulrich Weigand wrote:
> > This is pretty much working as expected. "pallo" is a string literal
> > which (always) resides in the default address space. According to the
> > named address space specification (TR 18037) there are no string literals
> > in non-default addre
On Thu, Aug 4, 2011 at 8:42 PM, Jan Hubicka wrote:
>>> Did you try using FDO with -Os? FDO should make hot code parts
>>> optimized similar to -O3 but leave other pieces optimized for size.
>>> Using FDO with -O3 gives you the opposite, cold portions optimized
>>> for size while the rest is optim
26 matches
Mail list logo
