"XU SHENG" <[EMAIL PROTECTED]> writes:
> int priv_dat __attribute__ ((section(".note"))) = MAGIC;
>
...
>
> It's clear to me that only section marked attribute with the
> startup of ".note" can be compiled to section with type SHT_NOTE in ELF
> file. Then only problem is assembler in g
Hi Adam,
It's OK. Thanks.
Best Regards,
Edison
-Original Message-
From: Adam Nemet [mailto:[EMAIL PROTECTED]
Sent: 2008年5月22日 15:03
To: XU SHENG
Cc: gcc@gcc.gnu.org
Subject: Re: About the gcc Warning: setting incorrect section attributes for
.note
"XU SHENG" <[EMAIL PROTECTE
On Thu, May 22, 2008 at 1:04 AM, Tom Tromey <[EMAIL PROTECTED]> wrote:
> You may have seen this warning from the memory consumption tester:
>
> http://gcc.gnu.org/ml/gcc-regression/2008-05/msg00041.html
>
> ... related to the recent identifier GC patch.
>
> I looked into this a little. My theory i
On Thu, 2008-05-22 at 02:35 +0200, Gerald Pfeifer wrote:
> Fully agreed. For some reason many here tend to be very shy when it
> comes to that, so thanks for Richi for raising this in this case.
Here is a proposal.
Sincerely,
Laurent
*** index.html 22 May 2008 11:35:08 +0200 1.662
--- in
Hi,
I'm currently trying to implement the C++09 exception propagation
proposal (N2179). See the thread at
http://gcc.gnu.org/ml/libstdc++/2008-05/msg00079.html
in the libstdc++ list for details.
As I say in my first follow-up, I need a copy constructor for any type
with a consistent signature
> "Richard" == Richard Guenther <[EMAIL PROTECTED]> writes:
Richard> For big testcases I actually see a consistend reduction in
Richard> peak overall memory usage (the number if you would look at
Richard> 'top'). For small testcases I can see both ups and downs,
Richard> probably because of c
On Thu, May 22, 2008 at 11:44:34AM +0200, Laurent GUERBY wrote:
> + May 22, 2008
> + The GCC Compile Farm project has
> + made available to free softare developpers two bi-quad core servers
> + donated by http://www.amd.com/";>AMD with hosting donated
> + by http://www.inria.fr/saclay/";>INRIA Sacl
During the process of fixing setjmp for AVR target, I needed to define
targetm.builtin_setjmp_frame_value () to be used in
expand_builtin_setjmp_setup().
This sets the value of the Frame pointer stored in jump buffer.
I set this "value" to virtual_stack_vars_rtx+1 (==frame_pointer)
Receiver de
[EMAIL PROTECTED] wrote:
During the process of fixing setjmp for AVR target, I needed to define
targetm.builtin_setjmp_frame_value () to be used in
expand_builtin_setjmp_setup().
This sets the value of the Frame pointer stored in jump buffer.
I set this "value" to virtual_stack_vars_rtx+1 (==
I already have nonlocal_goto, and nonlocal_goto_receiver.
These expect saved frame pointer to be virtual_stack_vars_rtx+1.
For setjmp the value is determined by
targetm.builtin_setjmp_frame_value - which I defined and is correct.
But for goto the value is created by some other code - which a
Hi.
I've been unable to successfully bootstrap on my i386-pc-solaris2.10
system since this set of changes made it into the repository:
2008-05-20 Kai Tietz <[EMAIL PROTECTED]>
* config/i386/i386-protos.h (ix86_return_in_memory): Removed.
(ix86_i386elf_return_in_memory): Likewi
Art,
2008/5/22 Art Haas <[EMAIL PROTECTED]>:
> Hi.
>
> I've been unable to successfully bootstrap on my i386-pc-solaris2.10
> system since this set of changes made it into the repository:
>
> 2008-05-20 Kai Tietz <[EMAIL PROTECTED]>
>
>* config/i386/i386-protos.h (ix86_return_in_memory):
[EMAIL PROTECTED] writes:
> However, for a normal goto used inside a nested function, a
> different part of gcc creates the code to store frame pointer (not
> expand_builtin_setjmp_setup). I can't find this code.
I think you are looking for expand_builtin_nonlocal_goto in
builtins.c.
Ian
"Omar Torres" <[EMAIL PROTECTED]> writes:
> Richard Sandiford wrote:
>> Also, you need to beware of cases in which operands[1] overlaps
>> operands[0]. The splitter says:
>>
>> [(set (match_dup 2) (match_dup 4))
>> (set (match_dup 3) (match_dup 5))]
>>
>> and operands[2] is always the highpart:
Richard Sandiford <[EMAIL PROTECTED]> writes:
> "Omar Torres" <[EMAIL PROTECTED]> writes:
>> Richard Sandiford wrote:
>>> Also, you need to beware of cases in which operands[1] overlaps
>>> operands[0]. The splitter says:
>>>
>>> [(set (match_dup 2) (match_dup 4))
>>> (set (match_dup 3) (match_
Dear All,
I recently started working in a GCC backend, and as a result I expect
to be actively participating in the ML.
That said, I have questions on how to properly and efficiently do a
post. I want to remove the annoyances that at the end just unnecessary
waste everyone's time.
1- I notice
On Thu, 2008-05-22 at 09:39 -0700, Joe Buck wrote:
> On Thu, May 22, 2008 at 11:44:34AM +0200, Laurent GUERBY wrote:
> > + May 22, 2008
> > + The GCC Compile Farm project has
> > + made available to free softare developpers two bi-quad core servers
> > + donated by http://www.amd.com/";>AMD with ho
On Thu, 2008-05-22 at 19:41, Kai Tietz wrote:
> Ok, fixed on gcc trunk revision 135776.
The patch fixed the warning error, but the bootstrap is still broken:
{ ... snip ... }
cc1: warnings being treated as errors
/export/home/arth/gnu/gcc.git/gcc/config/i386/i386.c:4845: error:
'return_in_memory
I think my last email crossed your reply - so apolgies for restating:
expand_builtin_nonlocal_goto is fine. This perform stack restore,
extracts frame pointer value and does jump.
reciever is fine - this jump destination does restore of frame pointer.
The problem I have is with frame pointer
> But it looks like update_ld_motion_stores() and insert_store() also
> call gen_move_insn without adding clobbers if necessary. I suppose the
> insns produced there should also go through insn_invalid_p somewhere.
> I sent a hack for that to DJ, but I guess the proper place to fix this
> is insid
[EMAIL PROTECTED] writes:
> expand_builtin_nonlocal_goto is fine. This perform stack restore,
> extracts frame pointer value and does jump.
>
> reciever is fine - this jump destination does restore of frame pointer.
>
> The problem I have is with frame pointer value that is saved in by
> "setup" p
On Thu, 2008-05-22 at 21:12, Kai Tietz wrote:
> Art,
>
> 2008/5/22 Art Haas <[EMAIL PROTECTED]>:
> >
> > On Thu, 2008-05-22 at 19:41, Kai Tietz wrote:
> >> Ok, fixed on gcc trunk revision 135776.
> >
> > The patch fixed the warning error, but the bootstrap is still
> broken:
> >
> > { ... snip ...
Snapshot gcc-4.3-20080522 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.3-20080522/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.3 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Thanks Ian!
I found it in function.c (expand_function_start)
emit_move_insn (r_save, virtual_stack_vars_rtx);
Whereas it should be
emit_move_insn (r_save, targetm.builtin_setjmp_frame_value ());
to match same construction used for setjmp.
thanks for help!
Ian Lance Taylor wrote:
(yet another m32c-related problem)
Something in ivopts is converting this:
ap.1_5 = ap_38 + 2;
ap.2_6 = (struct tiny *) ap_38;
SR.8_15 = ap.2_6->c;
to this:
ap.1_5 = ap_38 + 2;
SR.8_15 = MEM[base: ap.1_5, offset: 65534];
Now, recall that for -mcpu=m32c size_t is 16 bits but pointers
2008/5/23 Art Haas <[EMAIL PROTECTED]>:
> On Thu, 2008-05-22 at 21:12, Kai Tietz wrote:
>> Art,
>>
>> 2008/5/22 Art Haas <[EMAIL PROTECTED]>:
>> >
>> > On Thu, 2008-05-22 at 19:41, Kai Tietz wrote:
>> >> Ok, fixed on gcc trunk revision 135776.
>> >
>> > The patch fixed the warning error, but the bo
26 matches
Mail list logo
