Re: About the gcc Warning: setting incorrect section attributes for .note
"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 gcc assumed ".note" section as
> "aw" (allocate/write) as default property, but actually, the .note
> section can be only marked with "a" (note section is readonly). If I
> modify the temporary .s export by gcc assembler by delete "w" property,
> the warning is disappeared.
Did you try making priv_dat const?
Adam
RE: About the gcc Warning: setting incorrect section attributes for .note
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 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 gcc assumed ".note" section as "aw"
> (allocate/write) as default property, but actually, the .note section
> can be only marked with "a" (note section is readonly). If I modify
> the temporary .s export by gcc assembler by delete "w" property, the
> warning is disappeared.
Did you try making priv_dat const?
Adam
Re: apparent memory increase
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 is that this is an artifact of > how the tester collects its data. In particular I suspect the tester > was not including the identifier data in its memory stats -- but now, > because identifiers are allocated via the GC, they are included. > > If this theory is in error, let me know and I will investigate some > more. In this case, it would be helpful to have the script that > generates the report. For big testcases I actually see a consistend reduction in peak overall memory usage (the number if you would look at 'top'). For small testcases I can see both ups and downs, probably because of changes in the number and points of GC collections (but I guess that is expected). Richard.
Re: GCC Compile Farm News: two new bi-quad core machines available
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 --- index.html 22 May 2008 11:41:36 +0200 *** *** 45,50 --- 45,56 + 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 Saclay. + May 19, 2008 GCC 4.2.4 has been released.
Injecting a function into code generation
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. In other words, I need a function like this:
template
void copy_constructor(T *dest, const T *src)
{
new (dest) T(*src);
}
Then I can generate the equivalent of
void (*copy)(void*, const void*) = reinterpret_castconst void*)>(
©_constructor);
to get a function that can copy-construct an arbitrary type (given that
I know the type, which I do).
The problem is that, since this stuff is done in the tree building in
except.c, I can't rely on any header having been included and defining
such a function.
How can I generate this function in code? I need one instantiation per
type that is thrown, and it would be nice to avoid defining the function
anew for every throw expression. I tried finding an existing case of
this in the source, but I can't think of any place where such a thing
would be done, except perhaps generation of an implicit special member.
But I can't find those.
Sebastian
Re: apparent memory increase
> "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 changes in the number and points of GC Richard> collections (but I guess that is expected). If you are looking with top, I suppose noise for smaller test cases could come from differences in the overhead imposed by the GC versus an obstack. Also the new scheme wastes some amount of memory per identifier -- on average, half the minimum allocation size. Tom
Re: GCC Compile Farm News: two new bi-quad core machines available
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 Saclay. "developers". Also, the FSF has rather restrictive linking rules, so I don't think the patch can include the link to AMD's site (the link to INRIA should be fine). Since we can't give AMD a link, we could at least list them first. Perhaps something like AMD has generously donated two bi-quad core machines with the latest Opteron 8354 "Barcelona B3" processor and 16GB of RAM to the GCC Compile Farm project for use by free software developers. Hosting is donated by http://www.inria.fr/saclay/";>INRIA Saclay.
Where is setup for "goto" in nested function created?
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 defined in target latter restores frame pointer using virtual_stack_vars_rtx = value - 1 This produce correct code as expected and avoids run-time add/sub of offsets. (setjmp works!) 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. The issue I have is that this "goto_setup" code does NOT use targetm.builtin_setjmp_frame_value - but seems to use value=virtual_stack_vars_rtx, which is incompatible with my target receiver. So where is the goto setup code created? And is there a bug here? regards Andy
Re: Where is setup for "goto" in nested function created?
[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 (==frame_pointer) Receiver defined in target latter restores frame pointer using virtual_stack_vars_rtx = value - 1 This produce correct code as expected and avoids run-time add/sub of offsets. (setjmp works!) 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. The issue I have is that this "goto_setup" code does NOT use targetm.builtin_setjmp_frame_value - but seems to use value=virtual_stack_vars_rtx, which is incompatible with my target receiver. So where is the goto setup code created? And is there a bug here? Perhaps you need to implement one or more of: save_stack_nonlocal, restore_stack_nonlocal, nonlocal_goto, and/or nonlocal_goto_receiver. David Daney
Re: Where is setup for "goto" in nested function created?
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 appears to be wrong but I can't find! -Original Message- From: David Daney <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: gcc@gcc.gnu.org Sent: Thu, 22 May 2008 1:16 pm Subject: Re: Where is setup for "goto" in nested function created? [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 (==frame_pointer) Receiver defined in target latter restores frame pointer using > virtual_stack_vars_rtx = value - 1 > This produce correct code as expected and avoids run-time add/sub of > offsets. (setjmp works!) > 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. > The issue I have is that this "goto_setup" code does NOT use > targetm.builtin_setjmp_frame_value - but seems to use > value=virtual_stack_vars_rtx, which is incompatible with my target > receiver. > So where is the goto setup code created? And is there a bug here? Perhaps you need to implement one or more of: save_stack_nonlocal, restore_stack_nonlocal, nonlocal_goto, and/or nonlocal_goto_receiver. David Daney
Bootstrap broken on i386-pc-solaris2.10
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): Likewise.
(ix86_i386interix_return_in_memory): Likewise.
* config/i386/i386-interix.h (TARGET_RETURN_IN_MEMORY): Removed.
(SUBTARGET_RETURN_IN_MEMORY): New.
* config/i386/i386elf.h: Likewise.
* config/i386/ptx4-i.h: Likewise.
* config/i386/sol2-10.h: Likewise.
* config/i386/sysv4.h: Likewise.
* config/i386/vx-common.h: Likewise.
* config/i386/i386.h (TARGET_RETURN_IN_MEMORY): Removed.
* config/i386/i386.c (ix86_return_in_memory): Made static and
make use of optional SUBTARGET_RETURN_IN_MEMORY macro.
(ix86_i386elf_return_in_memory): Removed.
(ix86_i386interix_return_in_memory): Removed.
(TARGET_RETURN_IN_MEMORY): Declared within i386.c only.
* target-def.h (TARGET_RETURN_IN_MEMORY): Remove protection
#ifdef.
Lots of warnings during the stage1 portion of the build, and once things
get into stage2 the '-Werror' flag kills the build:
{ ... snip build log ... }
/export/home/arth/gnu/gcc-0522/./prev-gcc/xgcc
-B/export/home/arth/gnu/gcc-0522/./prev-gcc/
-B/usr/local/i386-pc-solaris2.10/bin/ -c -O2 -march=pentium4 -DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wmissing-format-attribute -pedantic
-Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -DHAVE_CONFIG_H -DGENERATOR_FILE -I.
-Ibuild -I/export/home/arth/gnu/gcc.git/gcc
-I/export/home/arth/gnu/gcc.git/gcc/build
-I/export/home/arth/gnu/gcc.git/gcc/../include
-I/export/home/arth/gnu/gcc.git/gcc/../libcpp/include
-I/usr/local/include -I/usr/local/include
-I/export/home/arth/gnu/gcc.git/gcc/../libdecnumber
-I/export/home/arth/gnu/gcc.git/gcc/../libdecnumber/dpd
-I../libdecnumber -o build/gensupport.o
/export/home/arth/gnu/gcc.git/gcc/gensupport.c
In file included from ./tm.h:24,
from /export/home/arth/gnu/gcc.git/gcc/gensupport.c:24:
/export/home/arth/gnu/gcc.git/gcc/config/i386/sol2-10.h:113:1: error:
"SUBTARGET_RETURN_IN_MEMORY" redefined
In file included from ./tm.h:18,
from /export/home/arth/gnu/gcc.git/gcc/gensupport.c:24:
/export/home/arth/gnu/gcc.git/gcc/config/i386/sysv4.h:28:1: error: this
is the location of the previous definition
make[3]: *** [build/gensupport.o] Error 1
make[3]: *** Waiting for unfinished jobs
{ ... snip ...}
Art Haas
Re: Bootstrap broken on i386-pc-solaris2.10
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): Removed.
>(ix86_i386elf_return_in_memory): Likewise.
>(ix86_i386interix_return_in_memory): Likewise.
>* config/i386/i386-interix.h (TARGET_RETURN_IN_MEMORY): Removed.
>(SUBTARGET_RETURN_IN_MEMORY): New.
>* config/i386/i386elf.h: Likewise.
>* config/i386/ptx4-i.h: Likewise.
>* config/i386/sol2-10.h: Likewise.
>* config/i386/sysv4.h: Likewise.
>* config/i386/vx-common.h: Likewise.
>* config/i386/i386.h (TARGET_RETURN_IN_MEMORY): Removed.
>* config/i386/i386.c (ix86_return_in_memory): Made static and
>make use of optional SUBTARGET_RETURN_IN_MEMORY macro.
>(ix86_i386elf_return_in_memory): Removed.
>(ix86_i386interix_return_in_memory): Removed.
>(TARGET_RETURN_IN_MEMORY): Declared within i386.c only.
>* target-def.h (TARGET_RETURN_IN_MEMORY): Remove protection
> #ifdef.
>
> Lots of warnings during the stage1 portion of the build, and once things
> get into stage2 the '-Werror' flag kills the build:
>
> { ... snip build log ... }
> /export/home/arth/gnu/gcc-0522/./prev-gcc/xgcc
> -B/export/home/arth/gnu/gcc-0522/./prev-gcc/
> -B/usr/local/i386-pc-solaris2.10/bin/ -c -O2 -march=pentium4 -DIN_GCC
> -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
> -Wold-style-definition -Wmissing-format-attribute -pedantic
> -Wno-long-long -Wno-variadic-macros
> -Wno-overlength-strings -Werror -DHAVE_CONFIG_H -DGENERATOR_FILE -I.
> -Ibuild -I/export/home/arth/gnu/gcc.git/gcc
> -I/export/home/arth/gnu/gcc.git/gcc/build
> -I/export/home/arth/gnu/gcc.git/gcc/../include
> -I/export/home/arth/gnu/gcc.git/gcc/../libcpp/include
> -I/usr/local/include -I/usr/local/include
> -I/export/home/arth/gnu/gcc.git/gcc/../libdecnumber
> -I/export/home/arth/gnu/gcc.git/gcc/../libdecnumber/dpd
> -I../libdecnumber -o build/gensupport.o
> /export/home/arth/gnu/gcc.git/gcc/gensupport.c
> In file included from ./tm.h:24,
> from /export/home/arth/gnu/gcc.git/gcc/gensupport.c:24:
> /export/home/arth/gnu/gcc.git/gcc/config/i386/sol2-10.h:113:1: error:
> "SUBTARGET_RETURN_IN_MEMORY" redefined
> In file included from ./tm.h:18,
> from /export/home/arth/gnu/gcc.git/gcc/gensupport.c:24:
> /export/home/arth/gnu/gcc.git/gcc/config/i386/sysv4.h:28:1: error: this
> is the location of the previous definition
> make[3]: *** [build/gensupport.o] Error 1
> make[3]: *** Waiting for unfinished jobs
> { ... snip ...}
>
> Art Haas
>
I sent the following patch to patch-gcc for this.
Index: gcc/gcc/config/i386/sol2-10.h
===
--- gcc.orig/gcc/config/i386/sol2-10.h
+++ gcc/gcc/config/i386/sol2-10.h
@@ -110,5 +110,6 @@ along with GCC; see the file COPYING3.
#undef TARGET_ASM_NAMED_SECTION
#define TARGET_ASM_NAMED_SECTION i386_solaris_elf_named_section
+#undef SUBTARGET_RETURN_IN_MEMORY
#define SUBTARGET_RETURN_IN_MEMORY(TYPE, FNTYPE) \
ix86_sol10_return_in_memory (TYPE, FNTYPE)
Thanks for reporting,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
Re: Where is setup for "goto" in nested function created?
[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
Re: splitting const_int's
"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:
>>
>>operands[2] = gen_highpart(QImode, operands[0]);
>>
>> but consider the case in which operands[1] (and thus operands[4])
>> is a memory reference that uses the high part of operands[0] as
>> a base register. In that case, the base register will be modified
>> by the first split instruction and have the wrong value in the
>> second split instruction. See other ports for the canonical way
>> of handling this.
>>
>> Richard
>
> By looking at other ports, I learned that I can detect when this happens
> by using the reg_overlap_mentioned_p(). Here is one case:
> (insn 43 115 74 (set (reg:HI 7 %i0h)
> (mem/s/j:HI (plus:HI (reg/f:HI 7 %i0h [orig:39 source ] [39])
> (const_int 2 [0x2])) [0 .r+0 S2 A8])) 3
> {*movhi} (nil)
> (nil))
>
>I need to tell the compiler not to use as destination the same base
> register when doing index operations. Any suggestions on how do I that?
Hmm. If one destination register is the base and the other is the
index, you're probably best off adding them together and freeing up
a register that way. Hopefully it'll be a rare case.
Because you're doing this in a splitter, some of the later
rtl optimisers _might_ be able to get rid of the addition,
but I wouldn't bet on it.
Richard
Re: splitting const_int's
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_dup 5))]
>>>
>>> and operands[2] is always the highpart:
>>>
>>>operands[2] = gen_highpart(QImode, operands[0]);
>>>
>>> but consider the case in which operands[1] (and thus operands[4])
>>> is a memory reference that uses the high part of operands[0] as
>>> a base register. In that case, the base register will be modified
>>> by the first split instruction and have the wrong value in the
>>> second split instruction. See other ports for the canonical way
>>> of handling this.
>>>
>>> Richard
>>
>> By looking at other ports, I learned that I can detect when this happens
>> by using the reg_overlap_mentioned_p(). Here is one case:
>> (insn 43 115 74 (set (reg:HI 7 %i0h)
>> (mem/s/j:HI (plus:HI (reg/f:HI 7 %i0h [orig:39 source ] [39])
>> (const_int 2 [0x2])) [0 .r+0 S2 A8])) 3
>> {*movhi} (nil)
>> (nil))
>>
>>I need to tell the compiler not to use as destination the same base
>> register when doing index operations. Any suggestions on how do I that?
>
> Hmm. If one destination register is the base and the other is the
> index, you're probably best off adding them together and freeing up
> a register that way. Hopefully it'll be a rare case.
>
> Because you're doing this in a splitter, some of the later
> rtl optimisers _might_ be able to get rid of the addition,
> but I wouldn't bet on it.
Sorry, this was the same thing Paul suggested. Doesn't seem
as hacky to me as it did to him ;)
Richard
How to post to GCC lists?
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 noticed that when I reply to posts, the "References" are not preserved, which leads to messages in the same threat not to be linked together. I am using Thunderbird as my email client. When I go to View>Headers>All the References field looks accurate. Is there a trick to make this work? Should I use instead a different email client better suit for GCC ML? 2- Currently, (1) is the only thing I have run cross. I am sure there are other issues that those of you with more experience have already discovered and solve. Any other Dos/Don'ts or tips/tricks when posting to GCC ML? Thanks, -Omar
Re: GCC Compile Farm News: two new bi-quad core machines available
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 hosting donated > > + by http://www.inria.fr/saclay/";>INRIA Saclay. > > "developers". > > Also, the FSF has rather restrictive linking rules, so I don't think the > patch can include the link to AMD's site (the link to INRIA should be > fine). > > Since we can't give AMD a link, we could at least list them first. > Perhaps something like > > AMD has generously donated two bi-quad core machines with the > latest Opteron 8354 "Barcelona B3" processor and 16GB of RAM > to the GCC Compile Farm project > for use by free software developers. Hosting is donated > by http://www.inria.fr/saclay/";>INRIA Saclay. I have no objection to the change. Laurent
Re: Bootstrap broken on i386-pc-solaris2.10
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_32' defined but not used
/export/home/arth/gnu/gcc.git/gcc/config/i386/i386.c:4892: error:
'return_in_memory_ms_64' defined but not used
make[3]: *** [i386.o] Error 1
make[3]: *** Waiting for unfinished jobs
{ ... snip end of log ... }
Art Haas
Re: Where is setup for "goto" in nested function created?
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 value that is saved in by "setup" prior to all this For goto is does not use expand_builtin_setjmp_setup - (pathetically) I can't find what it is using. Andy -Original Message- From: Ian Lance Taylor <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: gcc@gcc.gnu.org Sent: Thu, 22 May 2008 2:26 pm Subject: Re: Where is setup for "goto" in nested function created? [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
Re: store_motion query
> 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 inside gcse.c itself. What about putting that logic inside gen_move_insn ?
Re: Where is setup for "goto" in nested function created?
[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" prior to all this > > For goto is does not use expand_builtin_setjmp_setup - (pathetically) > I can't find what it is using. I'm not really sure just what you are after (and I'm not sure that I would know the answer if I did). Most of the relevant code should be somewhere in tree-nested.c. Also look at expand_function_start, and in general any use of cfun->nonlocal_goto_save_area. Ian
Re: Bootstrap broken on i386-pc-solaris2.10
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 ... }
> > cc1: warnings being treated as errors
> > /export/home/arth/gnu/gcc.git/gcc/config/i386/i386.c:4845: error:
> > 'return_in_memory_32' defined but not used
> > /export/home/arth/gnu/gcc.git/gcc/config/i386/i386.c:4892: error:
> > 'return_in_memory_ms_64' defined but not used
> > make[3]: *** [i386.o] Error 1
> > make[3]: *** Waiting for unfinished jobs
> > { ... snip end of log ... }
>
> Could you please test the attached patch. I have no solaris2 box. If
> everything works for you please let me know.
The patch worked - I've successfully built the current GCC.
Thanks!
Art Haas
gcc-4.3-20080522 is now available
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/gcc-4_3-branch revision 135779 You'll find: gcc-4.3-20080522.tar.bz2 Complete GCC (includes all of below) gcc-core-4.3-20080522.tar.bz2 C front end and core compiler gcc-ada-4.3-20080522.tar.bz2 Ada front end and runtime gcc-fortran-4.3-20080522.tar.bz2 Fortran front end and runtime gcc-g++-4.3-20080522.tar.bz2 C++ front end and runtime gcc-java-4.3-20080522.tar.bz2 Java front end and runtime gcc-objc-4.3-20080522.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.3-20080522.tar.bz2The GCC testsuite Diffs from 4.3-20080515 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.3 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Where is setup for "goto" in nested function created?
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: [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" prior to all this For goto is does not use expand_builtin_setjmp_setup - (pathetically) I can't find what it is using. I'm not really sure just what you are after (and I'm not sure that I would know the answer if I did). Most of the relevant code should be somewhere in tree-nested.c. Also look at expand_function_start, and in general any use of cfun->nonlocal_goto_save_area. Ian
YAMP: ivopts vs sizetype
(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 are 24 bits. The above SHOULD have resulted in this: mov.b -2[a0], r0 which I would have converted to this: mov.b 16777214[a0], r0 but instead I get this (and lots of testsuite errors): mov.b 65536[a0], r0 So, there are two problems here: First, something in ivopts is using sizetype to manipulate pointers, which doesn't work. I've seen plenty of cases where sizetype is used where the original pointer type could have been used (or even HOST_WIDE_INT) but couldn't track down the specific case that's the culprit. Help? Second, this type of addressing is expensive on the m32c (displacements are always unsigned). It would have been far better to use ap_38 and not had a displacement (or had a small positive one). Is there a way to tell SSA (or gcc in general) that negative displacements are expensive?
Re: Bootstrap broken on i386-pc-solaris2.10
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 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_32' defined but not used
>> > /export/home/arth/gnu/gcc.git/gcc/config/i386/i386.c:4892: error:
>> > 'return_in_memory_ms_64' defined but not used
>> > make[3]: *** [i386.o] Error 1
>> > make[3]: *** Waiting for unfinished jobs
>> > { ... snip end of log ... }
>>
>> Could you please test the attached patch. I have no solaris2 box. If
>> everything works for you please let me know.
>
> The patch worked - I've successfully built the current GCC.
>
> Thanks!
>
> Art Haas
>
The patch is applyed on trunk.
Thanks,
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
