> I have built a static runtime library and i want the linker to access
> it automatically without having to pass it explicitly.
Wrong list, this one is for GCC development, not development with GCC.
Try [EMAIL PROTECTED] instead.
--
Eric Botcazou
Currently, the way the native CPU detection code in driver-i386.c
is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
the correct setting for this chip? There seems to be a lot of confusion
across the net as to w
Dear All,
Sorry to disturb uninterested people with following information
For information (and for future reference) my employing organisation CEA
http://www.cea.fr/ "Commissariat a l'Energie Atomique, a French state-owned
research entity with a scientific, technical, and industrial activity dul
Hello,
While working on our CLI port, I realized that we were missing, among
others, the block reordering pass. This is because we emit CLI code
before the RTL passes are reached.
Looking at the backend optimizations, it is clear that some modify the
CFG. But my understanding is that loop opt
On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> Currently, the way the native CPU detection code in driver-i386.c
> is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> Core 2 Duo*) processor will result in -m{arch,tune}=prescott. Is this
> the correct setting for this
Looking at the backend optimizations, it is clear that some modify the
CFG. But my understanding is that loop optimizations and unrolling are
also being moved to GIMPLE. I do not know about others.
Loop optimizations are performed on GIMPLE only because they are really
hard to perform on RTL
Hi,
I know little about CLI, but assuming that your backend is nonstandard
enought so it seems to make sense to replace the RTL bits I guess it
would make sense to make the bb-reorder run on GIMPLE level too, while
keeping bb-reorder on RTL level for common compilation path. This
is example of pas
BTW, I am surprised that it is not easy to know which organizations exactly
has signed such legal papers. It could happen (in big organizations) that
such an assignment has been signed, and a putative minor contributor to GCC
does not know about it yet.
There is a copyright list on gnu.org machi
On Fri, Dec 01, 2006 at 06:43:46AM -0800, H. J. Lu wrote:
> On Fri, Dec 01, 2006 at 03:36:59AM -0600, Ryan Hill wrote:
> > Currently, the way the native CPU detection code in driver-i386.c
> > is set up, using -m{arch,tune}=native with an Intel Core Duo (*not
> > Core 2 Duo*) processor will result
Personally, I think the list should be somewhere that *all* gcc
maintainers have access to (not all of us have gnu.org accounts).
I agree that in principle, GCC "code maintainers" would need to check it
after approving a patch of somebody who has no CVS access. But the FSF
does not care about
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows C++
compilation timed are through the roof.
Using quick (in theory) and trusty cpgram.ii, I get:
tree PTA :1135.48 (88%) usr 5.47 (55%) sys1168.23 (85
Hello!
At least on x86_64 and i686 SPEC score [1] and polyhedron [2] scores
dropped noticeably. For SPEC benchmarks, mgrid, galgel, ammp and
sixtrack tests are affected and for polygedron, ac (second regression
in the peak) and protein (?) regressed in that time frame.
[1] http://www.suse.de/~aj
On Fri, 2006-12-01 at 10:40 -0500, Andrew MacLeod wrote:
> My bootstrap/make check cycle took about 10 hours with yesterdays
> checkout (way longer than expected). A quick investigation shows C++
> compilation timed are through the roof.
>
> Using quick (in theory) and trusty cpgram.ii, I get:
>
Paolo Bonzini wrote:
The legislation in the US, however, is
probably very different: for example, the copyright assignment form
would have a separate signature, or a click-through if done via web,
where you accept that the FSF keeps the data on a computer in order to
process the assignment.
On Fri, 2006-12-01 at 10:56 -0500, Andrew MacLeod wrote:
> On Fri, 2006-12-01 at 10:40 -0500, Andrew MacLeod wrote:
> > My bootstrap/make check cycle took about 10 hours with yesterdays
> > checkout (way longer than expected). A quick investigation shows C++
> > compilation timed are through the r
On 12/1/06, Uros Bizjak <[EMAIL PROTECTED]> wrote:
Hello!
At least on x86_64 and i686 SPEC score [1] and polyhedron [2] scores
dropped noticeably. For SPEC benchmarks, mgrid, galgel, ammp and
sixtrack tests are affected and for polygedron, ac (second regression
in the peak) and protein (?) regre
* Alan Ong ([EMAIL PROTECTED]) [20061201 03:35]:
> Hello,
>I am trying to compile my code with hard-coded Japanese Kanji and
> full-width katakana string text but the compiler view some of the text
> as escape characters.
Please ask on [EMAIL PROTECTED] This list deals with the
On 12/1/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
On 12/1/06, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> Hello!
>
> At least on x86_64 and i686 SPEC score [1] and polyhedron [2] scores
> dropped noticeably. For SPEC benchmarks, mgrid, galgel, ammp and
> sixtrack tests are affected and for pol
Sure. Sorry for the huge log.
I will use your method for the merge commit message in the future.
Thanks a lot!
Regards,
Chao-ying
- Original Message -
From: "Jakub Jelinek" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Thursday, November 30, 2006 11:24 PM
Subject: Re: [Bug midd
FYI, I created an IA64 psABI discussion group:
http://groups-beta.google.com/group/ia64-abi
H.J.
This is the beta release of binutils 2.17.50.0.8 for Linux, which is
based on binutils 2006 1201 in CVS on sourceware.org plus various
changes. It is purely for Linux.
Starting from the 2.17.50.0.8 release, the default output section LMA
(load memory address) has changed for allocatable sections f
On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
My bootstrap/make check cycle took about 10 hours with yesterdays
checkout (way longer than expected). A quick investigation shows C++
compilation timed are through the roof.
10 hours?
Using quick (in theory) and trusty cpgram.ii, I get:
On Fri, Dec 01, 2006 at 04:35:32PM +0100, Paolo Bonzini wrote:
> There could be privacy problems too. I don't know the relevant
> legislation, but the [copyright assignment] list includes personal data
> (year of birth, citizenship, employer) and, in Italy, I would have to
> sign a form if I had ac
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > My bootstrap/make check cycle took about 10 hours with yesterdays
> > checkout (way longer than expected). A quick investigation shows C++
> > compilation timed are through the roof.
On Fri, 2006-12-01 at 11:45 -0500, Daniel Berlin wrote:
> On 12/1/06, Richard Guenther <[EMAIL PROTECTED]> wrote:
> > On 12/1/06, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> > > Hello!
> until we can deal with the register pressure (though i thought we had
> out-of-ssa changes to help with this now).
Hello,
In accordance with http://gcc.gnu.org/ml/gcc/2006-09/msg00454.html, I am
looking for a reviewer for patches that add tuning for AMD's new
AMDFAM10 architecture to gcc.
The changes are all confined to the i386 backend and are only turned on
with -march=amdfam10 and/or -mtune=amdfam10. The
On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > My bootstrap/make check cycle took about 10 hours with yesterdays
> > checkout (way longer than expected). A quick investigati
On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > My bootstrap/make check cycle took about 10 hours with yesterdays
> > checkout (way longer than expected). A quick investigati
On Fri, 2006-12-01 at 15:06 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > >
> > > > Using quick (in theory) and trusty cpgram.ii, I get:
> > > >
> > > > tree PTA :1135.48 (88%) usr
On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > > My bootstrap/make check cycle took about 10 hours with yest
On 01/12/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
On Fri, 2006-12-01 at 14:59 -0500, Daniel Berlin wrote:
> On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > On Fri, 2006-12-01 at 13:49 -0500, Daniel Berlin wrote:
> > > On 12/1/06, Andrew MacLeod <[EMAIL PROTECTED]> wrote:
> > > > My
There's a bunch of related issues, some kernel, some gcc,
thus the Cc from hell on that one.
First of all, in theory the timers in kernel are done that way:
* they have callback of type void (*)(unsigned long)
* they have data to be passed to it - of type unsigned long
Snapshot gcc-4.1-20061201 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20061201/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.1 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
I have noticed that the INSN_CODE for all patterns in the rtl dumps
.00.expand are -1 ... does this mean that the .md file was not used for the
initial RTL generation?
best regards
Andrija Radicevic
On 12/1/06, Andrija Radicevic <[EMAIL PROTECTED]> wrote:
Hi,
I have noticed that the INSN_CODE for all patterns in the rtl dumps
.00.expand are -1 ... does this mean that the .md file was not used for the
initial RTL generation?
It was used, but it is assumed that the initial RTL produced by
'
The message for the following error:
enum e { E3 = 1 / 0 };
is in C: error: enumerator value for 'E3' not integer constant
and in C++: error: enumerator value for 'E3' is not an integer constant
The code in C is error ("enumerator value for %qE is not an integer
constant", name);
and in C++ is
esident)k
nohup.20061127:7177.19user 1295.59system 45:34.88elapsed 309%CPU
(0avgtext+0avgdata 0maxresident)k
nohup.20061127:8173.81user 2752.39system 57:50.67elapsed 314%CPU
(0avgtext+0avgdata 0maxresident)k
nohup.20061201:6880.76user 1284.99system 41:35.44elapsed 327%CPU
(0avgtext+0avgdata 0m
I would like to multiply a 16-bit number by an 8-bit number and
produce a 24-bit result on the AVR. The AVR has a hardware 8-bit *
8-bit -> 16-bit multiplier.
If I multiply a 16-bit number by a 16-bit number, it produces a 16-bit
result, which isn't wide enough to hold the result.
If I cast one
Hi all,
I understand that all template functions in GCC should have vague
linkage and thus may be exported into numerous translation units where
they are used. I have been attempting to use a few different macros on
both an instanciated template functions FUNCTION_DECL node and a normal
functions
On Fri, 2006-12-01 at 17:21 +, Al Viro wrote:
> There's a bunch of related issues, some kernel, some gcc,
> thus the Cc from hell on that one.
I don't really see how this is a GCC question, rather I see this
as a C question which means this should have gone to either
[EMAIL PROTECTED] or
Andrew Pinski wrote:
On Fri, 2006-12-01 at 17:21 +, Al Viro wrote:
There's a bunch of related issues, some kernel, some gcc,
thus the Cc from hell on that one.
I don't really see how this is a GCC question, rather I see this
as a C question which means this should have gone
On 12/1/06, Al Viro <[EMAIL PROTECTED]> wrote:
There's a bunch of related issues, some kernel, some gcc,
thus the Cc from hell on that one.
First of all, in theory the timers in kernel are done that way:
* they have callback of type void (*)(unsigned long)
* they have dat
42 matches
Mail list logo
