On Wed, 2006-06-07 at 01:36, Geoffrey Keating wrote:
> On 06/06/2006, at 5:25 PM, Andrew Pinski wrote:
>
> >> On 06/06/2006, at 5:20 PM, Andrew Pinski wrote:
> >>
> Right above, you said "We control the debug output machinery
> generating this, and can simply tell it to only deal in one
On Wed, 2006-06-07 at 06:22, Wolfgang Mües wrote:
> Rask,
>
> On Tuesday 06 June 2006 21:33, Rask Ingemann Lambertsen wrote:
> > > > + swp%?b\\t%1, %1, %0\;ldr%?b\\t%1, %0"
> > >
> > > You should get a price for cleverness here!
> >
> > Thanks! Indeed it looks good until you think of volatile va
On Mon, 5 Jun 2006, Martin Michlmayr wrote:
> * Gerald Pfeifer <[EMAIL PROTECTED]> [2006-06-05 22:51]:
>> GCC, the GNU Compiler Collection
> How about a dash here rather than a comma? Looks nicer imho:
> | GCC - the GNU Compiler Collection
The reason I avoid the dash is that, per the FSF guidel
"Richard Guenther" <[EMAIL PROTECTED]> wrote on 06/06/2006
16:58:27:
> On 6/6/06, Ayal Zaks <[EMAIL PROTECTED]> wrote:
> >
> > > This status report has been a long time coming, for which I
apologize.
> > >
> > > As fwprop is no longer on the table for 4.2, and as the vectorizer
> > > improvements
* Gerald Pfeifer <[EMAIL PROTECTED]> [2006-06-07 11:38]:
> I have a slight preference for keeping the status quo
OK.
--
Martin Michlmayr
http://www.cyrius.com/
hi,
I'm trying to understand the rtl genrated by gcc for mips processor.I
have read gcc internals by Richard Stallman but there are still some
confusions in the rtl language.
Following is a snippet of code which i'm trying to understand.
(insn 9 6 10 (nil) (set (reg:SI 182)
(mem/f:SI (sy
On 6/7/06, kernel coder <[EMAIL PROTECTED]> wrote:
hi,
I'm trying to understand the rtl genrated by gcc for mips processor.I
have read gcc internals by Richard Stallman
His name may be on it, but it's actually supposed to be maintained by
the gcc team.
I say "supposed" because apparently you c
> kernel coder writes:
kernel> In the above code following part is still unclear to me
kernel> [0 a+0 S4 A32]
The values in order represent:
Alias Set
Offset from a base expression, if part of a larger object
Size
Alignment
David
>
> In http://gcc.gnu.org/ml/gcc/2006-06/msg00185.html, your wrote:
>
> > So, two questions: any idea why 4.1.1 is no longer able to
> > automatically inline memcpys and why is the source operand for
> > movmemsi not know to be as widely aligned as it actually is?
>
> See PR middle-end/27226
>
Daniel, first of all, how would you prefer to communicate on general
GCC issues? Is it OK to send e-mail to you and to gcc mailing list, or
should I send such mails to gcc mailing list only?
Some of the GCC roots live on the heap memory, e.g. ident_table. These
are not found by Boehm's GC by defa
Laurynas Biveinis wrote:
> Daniel, first of all, how would you prefer to communicate on general
> GCC issues? Is it OK to send e-mail to you and to gcc mailing list, or
> should I send such mails to gcc mailing list only?
Copying me is fine for me.
>
> Some of the GCC roots live on the heap mem
Some of the GCC roots live on the heap memory, e.g. ident_table. These
are not found by Boehm's GC by default. I've started fixing such
places by registering these additional roots. But it got me thinking:
how do the old GCC garbage collectors know about those roots? I do not
see any root regist
The x86 psABI is very old and doesn't cover XMM registers. I'd like to
update x86 Linux calling convention for XMM register usage. I am not
sure if I should update stack alignment requirement.
The x86 psABI only requires 4 byte aligned stack. But the current gcc
assumes that the satck of a functio
On 07/giu/2006, at 18:22, H. J. Lu wrote:
The x86 psABI is very old and doesn't cover XMM registers. I'd like to
update x86 Linux calling convention for XMM register usage. I am not
sure if I should update stack alignment requirement.
Maybe you'll want to check how this is handled in Darwin/x
Hi,
There is a root list, generated by gengtype from parsing the files
looking for those GTY markers.
So, if you look at ggc_mark_roots, you can see the walker that is
walking the root table.
If you look in your *build* directory, and grep for ggc_root_tab, you
will see where the roots are.
> "Dan" == Daniel Berlin <[EMAIL PROTECTED]> writes:
Dan> You still need to be able to display the message for each number in all
Dan> the languages you want, so it's going to be stored somewhere, you
Dan> haven't solved the problem, just moved it completely to the consumer.
Usually I'm not a
On Wed, Jun 07, 2006 at 06:43:50PM +0200, Sandro Tolaini wrote:
>
> On 07/giu/2006, at 18:22, H. J. Lu wrote:
>
> >The x86 psABI is very old and doesn't cover XMM registers. I'd like to
> >update x86 Linux calling convention for XMM register usage. I am not
> >sure if I should update stack alignm
Andrew Pinski wrote:
On Jun 6, 2006, at 10:34 PM, Devang Patel wrote:
Andrew Pinski wrote:
On Jun 6, 2006, at 9:49 PM, Devang Patel wrote:
We can allocate space in numbering for vendor extensions.
What happens when you compile two sources with two different
compilers and they
use the sa
On Jun 7, 2006, at 10:10 AM, Devang Patel wrote:
Is it constructive (and appropriate? but hey I'm DWARF newbie
myself) to declare
DWARF standard limited and full of mistakes ?
No, I am saying that dwarf2 is supposed to be stable and adding stuff
is not likely
going to happen that often u
Laurynas Biveinis wrote:
> Hi,
>
>> There is a root list, generated by gengtype from parsing the files
>> looking for those GTY markers.
>>
>> So, if you look at ggc_mark_roots, you can see the walker that is
>> walking the root table.
>>
>> If you look in your *build* directory, and grep for ggc_
On Wed, Jun 07, 2006 at 06:57:45PM +0200, Laurynas Biveinis wrote:
> As far as I can understand, current GGC-ors do not simply register
> them as a additional roots - they walk them all the way down by the
> pointers and mark stuff as required during collection. Now, if I add
> the roots to Boehm's
Tom Tromey wrote:
Dan> It also has almost zero hope of working over multiple compiler versions,
Dan> being future proof in general, and not having other compiler vendors
Dan> fight over message number namespace.
The maintenance issue is a major one. This document definitely needs
to address thi
Tom Tromey wrote:
Devang> In the case of "dead code" we could use _msg. However, _cmd is
Devang> available to trigger some actions in tools that use this
Devang> information. If we let our imaginations run wild then for
Devang> example, lead developer towards __restrict documentation
Devang> (i.
Andrew Pinski wrote:
On Jun 7, 2006, at 10:10 AM, Devang Patel wrote:
Is it constructive (and appropriate? but hey I'm DWARF newbie myself)
to declare
DWARF standard limited and full of mistakes ?
No, I am saying that dwarf2 is supposed to be stable and adding stuff
is not likely
going to
Hi,
Yet another question: there are several root lists: gt_ggc_rtab,
gt_ggc_deletable_rtab, gt_pch_cache_rtab, gt_pch_scalar_rtb. Now what
is what? I see that gt_ggc_rtab is an "ordinary" list. The deletable
one seems to have things that can be always collected? The names of
the last two ones sug
Laurynas Biveinis wrote:
> Hi,
>
> Yet another question: there are several root lists: gt_ggc_rtab,
> gt_ggc_deletable_rtab, gt_pch_cache_rtab, gt_pch_scalar_rtb. Now what
> is what? I see that gt_ggc_rtab is an "ordinary" list. The deletable
> one seems to have things that can be always collected
> No, you said it has limitations and it is mistake to allow vendor
> extensions in DWARF.
My exact words were:
Not my fault and not really related because we are creating a new standard and
don't want to repeat this mistake, messages don't have this issue.
I was not trying to imply dwarf2 was mi
Andrew Pinski wrote:
No, you said it has limitations and it is mistake to allow vendor
extensions in DWARF.
My exact words were:
Not my fault and not really related because we are creating a new standard and
don't want to repeat this mistake, messages don't have this issue.
I was not tryin
On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
> And string does not answer localization issue, however for numbers at least
> there is one precedent to follow.
I think this discussion has gotten totally sidetracked. When I said
I was in favor of strings, I didn't mean messages tha
>
> And string does not answer localization issue, however for numbers at least
> there is one precedent to follow.
And strings have precedent for localization also, just look into how
GCC's error messages are done. Or even any of the Mac OS X programs
which does all localization based on string
Daniel Jacobowitz wrote:
On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
And string does not answer localization issue, however for numbers at least
there is one precedent to follow.
I think this discussion has gotten totally sidetracked.
I agree.
When I said
I was i
On 07/06/2006, at 11:33 AM, Daniel Jacobowitz wrote:
On Wed, Jun 07, 2006 at 11:29:44AM -0700, Devang Patel wrote:
And string does not answer localization issue, however for numbers
at least
there is one precedent to follow.
I think this discussion has gotten totally sidetracked. When I s
> "Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Devang> Since messages are represented using a number, how about using
Devang> one category bit to identify command message vs display message ?
Devang> Command message is a message where tools, reading opt diary,
Devang> take perform some
Tom Tromey wrote:
"Devang" == Devang Patel <[EMAIL PROTECTED]> writes:
Devang> Since messages are represented using a number, how about using
Devang> one category bit to identify command message vs display message ?
Devang> Command message is a message where tools, reading opt diar
> > I still don't see how gcc maintainers would know to make this
> > distinction. Perhaps I'm misunderstanding the distinction between
> > command and display.
>
> for (i=0; i<4; i++)
> {
> C[i] = A[i] + C[i+3];
> }
>
> Auto vectorizer emits three messages.
> 1) This loop is not vectorized beca
Hi,
I'm a Msc. student in the computer science department of the Technion, the
Israeli Institute of Technology.
My thesis is on compile time checking of dynamic SQL queries using C++
templates.
There is a __COUNTER__ macro, supported by Microsoft C++ compiler which can
help
me a lot in the thesis
[EMAIL PROTECTED] writes:
> I'm a Msc. student in the computer science department of the Technion, the
> Israeli Institute of Technology.
> My thesis is on compile time checking of dynamic SQL queries using C++
> templates.
> There is a __COUNTER__ macro, supported by Microsoft C++ compiler which
On 6/7/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Hi,
I'm a Msc. student in the computer science department of the Technion, the
Israeli Institute of Technology.
My thesis is on compile time checking of dynamic SQL queries using C++
templates.
There is a __COUNTER__ macro, supported by Mic
> There are 2 different, but related questions:
>
> 1. Should Linux require gcc generates 16byte aligned stack?
> 2. How should Linux support 4byte alignment code?
Independently of Linux, GCC could align the stack at 16 bytes and still be
compliant with the psABI. It could also wrap memalign as
HJ,
> We have several choices for stack alignment requirement
>
> 1. Leave it unchanged. Gcc can do
> a. Nothing. Let the program crash.
> b. Align stack to 16byte if XMM registers are used locally and
>aren't passed down as function arguments.
Why not so if the XMM regi
On Wed, Jun 07, 2006 at 04:08:14PM -0500, Menezes, Evandro wrote:
> HJ,
>
> > We have several choices for stack alignment requirement
> >
> > 1. Leave it unchanged. Gcc can do
> > a. Nothing. Let the program crash.
> > b. Align stack to 16byte if XMM registers are used locally and
> >
You might also check boost.org to see if they have this concept
already implemented. And if not, you could contribute it to them as
well.
On Jun 7, 2006, at 3:17 PM, [EMAIL PROTECTED] wrote:
Hi,
I'm a Msc. student in the computer science department of the
Technion, the
Israeli Institut
> > > We have several choices for stack alignment requirement
> > >
> > > 1. Leave it unchanged. Gcc can do
> > > a. Nothing. Let the program crash.
> > > b. Align stack to 16byte if XMM registers are used locally and
> > >aren't passed down as function arguments.
> >
> > Why not
On Wed, Jun 07, 2006 at 05:17:39PM -0500, Menezes, Evandro wrote:
> > > > We have several choices for stack alignment requirement
> > > >
> > > > 1. Leave it unchanged. Gcc can do
> > > > a. Nothing. Let the program crash.
> > > > b. Align stack to 16byte if XMM registers are used
> > > > > We have several choices for stack alignment requirement
> > > > >
> > > > > 1. Leave it unchanged. Gcc can do
> > > > > a. Nothing. Let the program crash.
> > > > > b. Align stack to 16byte if XMM registers are
> used locally and
> > > > >aren't passed down as fu
On 6/5/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
Our Co. have a new 32b embedded processor, and we have ported the gcc
backend for it(support c/c++), now we want add its backend code into gcc
packages. i read the "Contributing to GCC " pages that we must sign some
forms, can you kindly sen
Our Co. have a new 32 bit embedded processor, and we have ported the gcc
backend for it(support c/c++), now we want add its backend code into gcc
packages. i read the "Contributing to GCC " pages that we must sign some
forms, can you kindly send the forms to me?
Best Regards
Liqin
Hello!
Current mainline gcc can efficiently disable x87 instruction when
-mno-80387 switch is used. In this case, MMX registers can be used for
the autovectorisation even without emms or femms instructions to
switch back to x87 mode.
-mno-80387 introduces ABI change, so existing libraries are al
48 matches
Mail list logo
