Re: rx: remove some asserts
Hi DJ, There is no need to assert these just to say not supported and gcc may rarely generate addresses from valid code which trigger these asserts. Ok? OK - please apply. Cheers Nick
Re: [V850] Hookize LIBCALL_VALUE
Hi Anatoliy, OK for trunk? 2015-07-26 Anatoly Sokolov ae...@post.ru * config/v850/v850.h (LIBCALL_VALUE): Remove macros. * config/v850/v850.md (RV_REGNUM): New constants. * config/v850/v850.c (v850_libcall_value): New functions. (v850_function_value_regno_p, v850_function_value): Use RV_REGNUM. (TARGET_LIBCALL_VALUE): Define. Approved - please apply. Cheers Nick
RFA: FT32: Fix building gcc.
Hi Guys, It seems that the FT32 port of GCC does not have a maintainer at the moment. Nevertheless I have a patch to fix a couple of build time problems compiling gcc for the FT32. Is this OK to apply ? Cheers Nick gcc/ChangeLog 2015-06-23 Nick Clifton ni...@redhat.com * config/ft32/ft32.c: Include emit-rtl.h for the definition of crtl. (ft32_print_operand): Cast the result of INTVAL in order to make sure that the correct value is printed. * config/ft32/ft32.h (STACK_GROWS_DOWNWARD): Define to an integer. Index: gcc/config/ft32/ft32.c === --- gcc/config/ft32/ft32.c (revision 224834) +++ gcc/config/ft32/ft32.c (working copy) @@ -59,8 +59,8 @@ #include basic-block.h #include df.h #include builtins.h +#include emit-rtl.h - #include stdint.h #define LOSE_AND_RETURN(msgid, x) \ @@ -199,7 +199,7 @@ return; case 'm': - fprintf (file, %d, -INTVAL(x)); + fprintf (file, %ld, (long) (- INTVAL(x))); return; case 'd': // a DW spec, from an integer alignment (for BLKmode insns) Index: gcc/config/ft32/ft32.h === --- gcc/config/ft32/ft32.h (revision 224834) +++ gcc/config/ft32/ft32.h (working copy) @@ -248,7 +248,7 @@ /* Define this macro if pushing a word onto the stack moves the stack pointer to a smaller address. */ -#define STACK_GROWS_DOWNWARD +#define STACK_GROWS_DOWNWARD 1 #define INITIAL_FRAME_POINTER_OFFSET(DEPTH) (DEPTH) = 0
Re: RFA: Fix isl-ast-gen-if-1.c test
Hi Jeff,
I'd tend to prefer to change the size of the array -- adding another
conditional in the loop may have unintended consequences that possibly
scramble things just enough to compromise the test.
Okey dokey, here is a revised version. Is this one OK ?
Cheers
Nick
gcc/ChangeLog
Index: 2015-06-22 Nick Clifton ni...@redhat.com
* gcc.dg/graphite/isl-ast-gen-if.c (main): Increase size of a
array to allow a[50] to be a valid location.
gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c
===
--- gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c(revision 224722)
+++ gcc/testsuite/gcc.dg/graphite/isl-ast-gen-if-1.c(working copy)
@@ -28,7 +28,7 @@
int
main (void)
{
- int a[50];
+ int a[51]; /* NB This size allows foo's first iteration to write to
a[50]. */
foo (a, 50);
int res = array_sum (a);
if (res != 49)
Re: RFA: RL78: Place zero-initialised data into the .bss section
Hi DJ, Ok but.. +case SECCAT_TBSS: + return default_select_section (decl, reloc, align); + +default: + gcc_unreachable (); Would it be better to just default: everything to default_select_section, instead of enumerating everything we know about today? Yes it would. :-} I have committed the patch with that change applied. Cheers Nick
Re: RFA: RL78: Save the frame pointer if it is used.
Hi DJ, OK to apply ? Ok, but... Thanks - committed. - if (regno == FRAME_POINTER_REGNUM frame_pointer_needed) + if (regno == FRAME_POINTER_REGNUM + (frame_pointer_needed || df_regs_ever_live_p (regno))) Do we want regs_ever_live or regs_ever_written_to ? I seem to recall changing a port... mep perhaps... to only save registers that are changed, not registers that are used but read-only. You are right, we would only need to save the FP if it is written to, but I could not find a regs_ever_written_to, or something similar. At least the current version of the patch will still work though, even if there is a needless save/restore of the FP. Cheers Nick
Re: RFA: Doc update: Describe new MSP430 feature
Hi Gerald, as maintainer of the port you do not need anyone else's approval. Thanks - have checked the (editted) patch in. That said, I am always happy to provide a second pair of eyes, so here are some comments: Thanks for those too. I have made the appropriate changes following your suggestions. Does this really apply to GCC 5, or GCC 6 and the (new) gcc-6/changes.html? GCC 6. I had forgotten to run cvs update -d in the wwwdocs directory and so only saw the gcc-5 directory. Doh. I have now applied the patch to the gcc-6/changes.html file. Cheers Nick
Re: Fix xstormy16 handling of HImode predicates
Hi Richard, gcc/ * config/stormy16/predicates.md (xs_hi_general_operand): Delete. (xs_hi_nonmemory_operand): Remove error. * config/stormy16/stormy16.md (movhi, movhi_internal): Use general_operand rather than xs_hi_general_operand. Approved - please apply. Cheers Nick
Re: [BUILDROBOT] RFA: RL78: Add support for G13 and G14 multiply and divide
Hi Jan-Benedict. ../../../gcc/gcc/config/rl78/rl78.c:390:14: error: enumeration value ‘MUL_RL78’ not handled in switch [-Werror=switch] switch (rl78_mul_type) ../../../gcc/gcc/config/rl78/rl78.c:4649:34: error: unused parameter ‘x’ [-Werror=unused-parameter] rl78_preferred_reload_class (rtx x, reg_class_t rclass) These are now fixed. Cheers Nick
RFA: Updated gcc-5 html documentation for new RX option
Hi Gerald, The attached patch updates the gcc html documentation to mention the new RX command line option that I checked in today. Is this patch OK to apply ? Cheers Nick Index: htdocs/gcc-5/changes.html === RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v retrieving revision 1.107 diff -u -3 -p -r1.107 changes.html --- htdocs/gcc-5/changes.html 13 Apr 2015 21:14:26 - 1.107 +++ htdocs/gcc-5/changes.html 15 Apr 2015 10:04:56 - @@ -800,6 +800,18 @@ here/a./p option became meaningless and can be discarded./li /ul +h3 id=rxRX/h3 + ul +liA new command line option code-mno-allow-string-insns/code can be +used to disable the generation of the codeSCMPU/code, codeSMOVU/code, +codeSMOVB/code, codeSMOVF/code, codeSUNTIL/code, codeSWHILE/code +and codeRMPA/code instructions. An erratum released by Renesas shows +that it is unsafe to use these instructions on addresses with the I/O space +of the processor. The new option can be used when the programmer is +concerned that the I/O space might be accessed. The default is still to +enable these instructions./li + /ul + h3 id=shSH/h3 ul liThe compiler will now pass the appropriate code--isa=/code option
Re: RFC: Avoid calling convert_to_mode with invalid rtl.
Hi Eric, Note that the very same code is in expand_assignment, so they probably should be kept in sync. Oops - I had missed that. The patch adds a second call to expand_expr(), giving the address mode as the suggested mode, and using a normal expansion, rather than EXPAND_SUM. This might work, but even if it does not the rtl in offset_rtx will be valid in a non-address context so that whatever convert_to_mode does will still remain valid. I don't think that we want to expand twice the same expression. What about calling force_operand on offset_rtx right before convert_to_mode? That works too, and is much better than my solution. What do you think of the attached patch ? Is it suitable for submission once the sources are out of stage 4 ? (No regressions with an x86_64-pc-linux-gnu toolchain and several fixes for an rl78-elf toolchain). Cheers Nick expr.c.patch.2 Description: Unix manual page
Re: RFA: RL78: Fix gcc testsuite failures
Hi Jan-Benedict, Seems you accidentally committed quite some more code you're currently working on in that very commit, which is now breaking Doh! Yes, sorry about that. I have now reverted the DIV attribute part of the patch. (I am hoping that this work will be ready for contributing soon, but it is not quite there yet). Cheers Nick
Re: [BUILDROBOT, PATCH] MSP430: Fix unused arg warning
Hi Jan-Benedict, 2014-12-17 Jan-Benedict Glaw jbg...@lug-owl.de * config/msp430/msp430.c (msp430_asm_output_addr_const_extra): Fix unused argument warning. Approved - please apply. Cheers Nick
Re: Ping: FR-V rtx iterator patches
Hi Richard, Ping for these FR-V patches: https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02645.html https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02646.html https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02647.html https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02648.html which convert callers of for_each_rtx to the new rtx iterators in rtl-iter.h. (These are the only uses of for_each_rtx left -- thanks for all the reviews to get this far.) Sorry for missing these. The patches are fine - please apply. Cheers Nick
Re: [PATCH] [BUILDROBOT] RX: Mark unused argument
Hi Jan-Benedict, 2014-11-03 Jan-Benedict Glaw jbg...@lug-owl.de * config/rx/rx.c (rx_handle_func_attribute): Mark unused argument. Approved - please apply. Cheers Nick
Re: [PATCH] msp430: inhibit automatic link of -lnosys in absence of -msim
Hi Peter, gcc/ChangeLog 2014-09-22 Peter A. Bigot p...@pabigot.com * config/msp430/msp430.h: Remove automatic -lnosys when -msim absent. Approved and applied. Cheers Nick
Re: [BUILDROBOT] [PATCH] rx-elf: error: logical not is only applied to the left hand side of comparison
Hi Jan-Benedict, 2014-09-04 Jan-Benedict Glaw jbg...@lug-owl.de * config/rx/rx.h (HARD_REGNO_MODE_OK): Add braces. Approved - please apply - thanks! Cheers Nick
Re: [BUILDROBOT] v850 fallout
Hi Guys,
Jan-Benedict Glaw wrote:
I've been away for holidays and other stuff, so this is a bit late,
but nevermind... The stringification of DECL_SECTION_NAME had some
fallout, see eg.
http://toolchain.lug-owl.de/buildbot/show_build_details.php?id=272454
/home/jbglaw/repos/gcc/gcc/config/v850/v850.c:2647: error: cannot convert
‘tree_node*’ to ‘const char*’ for argument ‘2’ to ‘void
set_decl_section_name(tree_node*, const char*)’
Fixed with this patch.
Cheers
Nick
gcc/ChangeLog
2014-06-25 Nick Clifton ni...@redhat.com
* config/v850/v850.c (GHS_default_section_names): Change to const
char * type.
(GHS_current_section_names): Likewise.
(v850_insert_attributes): Do not build strings, just assign the
names directly. Change the type of 'chosen_section' to const
char*.
* config/v850/v850-c.c (ghs_pragma_section): Assign the alias
directly to the array entry.
* config/v850/v850.h (GHS_default_section_names): Change to const
char * type.
(GHS_current_section_names): Likewise.
Index: gcc/config/v850/v850-c.c
===
--- gcc/config/v850/v850-c.c (revision 211967)
+++ gcc/config/v850/v850-c.c (working copy)
@@ -175,8 +175,7 @@
if (streq (alias, default))
GHS_current_section_names [kind] = NULL;
else
- GHS_current_section_names [kind] =
- build_string (strlen (alias) + 1, alias);
+ GHS_current_section_names [kind] = alias;
}
while (repeat);
Index: gcc/config/v850/v850.c
===
--- gcc/config/v850/v850.c (revision 211967)
+++ gcc/config/v850/v850.c (working copy)
@@ -54,8 +54,8 @@
static void v850_print_operand_address (FILE *, rtx);
/* Names of the various data areas used on the v850. */
-tree GHS_default_section_names [(int) COUNT_OF_GHS_SECTION_KINDS];
-tree GHS_current_section_names [(int) COUNT_OF_GHS_SECTION_KINDS];
+const char * GHS_default_section_names [(int) COUNT_OF_GHS_SECTION_KINDS];
+const char * GHS_current_section_names [(int) COUNT_OF_GHS_SECTION_KINDS];
/* Track the current data area set by the data area pragma (which
can be nested). Tested by check_default_data_area. */
@@ -2569,19 +2569,19 @@
if (GHS_default_section_names [(int) GHS_SECTION_KIND_SDATA] == NULL)
{
GHS_default_section_names [(int) GHS_SECTION_KIND_SDATA]
- = build_string (sizeof (.sdata)-1, .sdata);
+ = .sdata;
GHS_default_section_names [(int) GHS_SECTION_KIND_ROSDATA]
- = build_string (sizeof (.rosdata)-1, .rosdata);
+ = .rosdata;
GHS_default_section_names [(int) GHS_SECTION_KIND_TDATA]
- = build_string (sizeof (.tdata)-1, .tdata);
+ = .tdata;
GHS_default_section_names [(int) GHS_SECTION_KIND_ZDATA]
- = build_string (sizeof (.zdata)-1, .zdata);
+ = .zdata;
GHS_default_section_names [(int) GHS_SECTION_KIND_ROZDATA]
- = build_string (sizeof (.rozdata)-1, .rozdata);
+ = .rozdata;
}
if (current_function_decl == NULL_TREE
@@ -2592,7 +2592,7 @@
!DECL_SECTION_NAME (decl))
{
enum GHS_section_kind kind = GHS_SECTION_KIND_DEFAULT;
- tree chosen_section;
+ const char * chosen_section;
if (TREE_CODE (decl) == FUNCTION_DECL)
kind = GHS_SECTION_KIND_TEXT;
Index: gcc/config/v850/v850.h
===
--- gcc/config/v850/v850.h (revision 211967)
+++ gcc/config/v850/v850.h (working copy)
@@ -916,7 +916,7 @@
For the *normal* section kinds (like .data, .text, etc.) we do not
want to explicitly force the name of these sections, but would rather
let the linker (or at least the back end) choose the name of the
- section, UNLESS the user has force a specific name for these section
+ section, UNLESS the user has forced a specific name for these section
kinds. To accomplish this set the name in ghs_default_section_names
to null. */
@@ -952,8 +952,8 @@
extern data_area_stack_element * data_area_stack;
/* Names of the various data areas used on the v850. */
-extern tree GHS_default_section_names [(int) COUNT_OF_GHS_SECTION_KINDS];
-extern tree GHS_current_section_names [(int) COUNT_OF_GHS_SECTION_KINDS];
+extern const char * GHS_default_section_names [(int) COUNT_OF_GHS_SECTION_KINDS];
+extern const char * GHS_current_section_names [(int) COUNT_OF_GHS_SECTION_KINDS];
/* The assembler op to start the file. */
Re: RFA: Fix calculation of size of builtin setjmp buffer
Hi Eric, OK - here is your version of the patch, extended with a comment which I think is helpful for other people reading the code, and with the changes to builtins.c and md.texi removed, since the size of the buffer is not changing. Is this version OK to apply ? Cheers Nick gcc/ChangeLog 2014-05-16 Nick Clifton ni...@redhat.com * except.c (init_eh): Correct computation of the size of a builtin setjmp buffer for when pointers are bigger than words. Index: gcc/except.c === --- gcc/except.c(revision 210490) +++ gcc/except.c(working copy) @@ -286,9 +286,22 @@ tmp = size_int (FIRST_PSEUDO_REGISTER + 2 - 1); #endif #else - /* builtin_setjmp takes a pointer to 5 words. */ - tmp = size_int (5 * BITS_PER_WORD / POINTER_SIZE - 1); + /* Compute a minimally sized jump buffer. We need room to store at +least 3 pointers - stack pointer, frame pointer and return address. +Plus for some targets we need room for an extra pointer - in the +case of MIPS this is the global pointer. This makes a total of four +pointers, but to be safe we actually allocate room for 5. + +If pointers are smaller than words then we allocate enough room for +5 words, just in case the backend needs this much room. For more +discussion on this issue see: +http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00313.html. */ + if (POINTER_SIZE BITS_PER_WORD) + tmp = size_int (5 - 1); + else + tmp = size_int ((5 * BITS_PER_WORD / POINTER_SIZE) - 1); #endif tmp = build_index_type (tmp); tmp = build_array_type (ptr_type_node, tmp);
Re: RFA: Fix calculation of size of builtin setjmp buffer
Hi Eric, 2014-05-06 Nick Clifton ni...@redhat.com * except.c (init_eh): Fix computation of builtin setjmp buffer size. That's the same patch as https://gcc.gnu.org/ml/gcc-patches/2011-11/msg00272.html and is still incorrect. Ah - you are worried about the case where STACK_SAVEAREA_MODE() is smaller than Pmode, yes ? OK then, how about this revised version of the patch where the size computation is now: tmp = size_int (MAX (GET_MODE_SIZE (STACK_SAVEAREA_MODE (SAVE_NONLOCAL)) / GET_MODE_SIZE (Pmode), 1) + 2 /* Stack pointer and frame pointer. */ + 1 /* Slop for mips. */ - 1); OK to apply ? Cheers Nick except.c.patch.4 Description: Unix manual page
Re: RFA: Fix calculation of size of builtin setjmp buffer
Hi Mike, How about GET_MODE_SIZE (STACK_SAVEAREA_MODE (SAVE_NONLOCAL)) / GET_MODE_SIZE (Pmode) + 2 + /* slop for mips, see builtin_setjmp_setup */ 1 - 1. This retains the slop for mips, and fixes ports like ia64 and s390 (see STACK_SAVEAREA_MODE on those ports, it is larger one might expect)? OK - revised patch attached. I have added a comment before the computation to explain each of the numbers, and adjusted the comments in the other files to match the new size of the jump buffer. What do you think of this version ? Cheers Nick builtin-setjmp.patch.2 Description: Unix manual page
Re: RFA: Fix calculation of size of builtin setjmp buffer
Hi Jakub,
/* builtin_setjmp takes a pointer to 5 words. */
- tmp = size_int (5 * BITS_PER_WORD / POINTER_SIZE - 1);
+ tmp = size_int (5 * POINTER_SIZE / BITS_PER_WORD - 1);
That doesn't look correct to me. If the code wants to create 5 words long
array, but with pointer elements (instead of word sized elements), then
5 * BITS_PER_WORD is the desired size in bits of the buffer, POINTER_SIZE
is how many bits each void *array[...] element occupies and thus
5 * BITS_PER_WORD / POINTER_SIZE - 1 is the right last element, so I'd
say the previous expression is the right one. Perhaps you want to round up
rather than down, but certainly not swap the division operands.
Now, if the code actually expects 5 pointers, rather than 5 words, or
something else, then you'd at least need to also fix the comment.
The contents of the builtin setjmp buffer do not appear to be explicitly
documented anywhere. The nearest that I could come was this line in
the description of builtin_setjmp_setup in gcc/doc/md.texi:
Note that the buffer is five words long and that
the first three are normally used by the generic
mechanism.
But a comment in gcc/except.c:expand_builtin_setjmp_setup() says that
the first three entries in the buffer are for the frame pointer, the
address of the return label and the stack pointer. This appears to
suggest that it is 3 pointers that are stored in the buffer not 3 words.
Given that pointers can be bigger than words, and that if a pointer is 2
words long then even a 5 word buffer will be too small, I still feel
that my patch is correct. So here is a revised patch which updates the
comments in all of the places that I could find them, adds a description
of builtin_setjmp buffer to the documentation, and includes my original,
not quite so obvious fix.
OK to apply ?
Cheers
Nick
gcc/ChangeLog
2014-05-06 Nick Clifton ni...@redhat.com
* builtins.c: Update description of buffer used by builtin setjmp
and longjmp.
* doc/md.texi (builtin_setjmp_setup): Likewise.
* except.c (init_eh): Fix computation of builtin setjmp buffer
size.
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 210096)
+++ gcc/builtins.c (working copy)
@@ -977,10 +977,10 @@
emit_insn (gen_blockage ());
}
-/* __builtin_longjmp is passed a pointer to an array of five words (not
- all will be used on all machines). It operates similarly to the C
- library function of the same name, but is more efficient. Much of
- the code below is copied from the handling of non-local gotos. */
+/* __builtin_longjmp is passed a pointer to an array of five Pmode sized
+ entries (not all will be used on all machines). It operates similarly
+ to the C library function of the same name, but is more efficient. Much
+ of the code below is copied from the handling of non-local gotos. */
static void
expand_builtin_longjmp (rtx buf_addr, rtx value)
@@ -1204,10 +1204,10 @@
return const0_rtx;
}
-/* __builtin_update_setjmp_buf is passed a pointer to an array of five
words
- (not all will be used on all machines) that was passed to
__builtin_setjmp.
- It updates the stack pointer in that block to correspond to the current
- stack pointer. */
+/* __builtin_update_setjmp_buf is passed a pointer to an array of five
Pmode
+ sized entries (not all will be used on all machines) that was passed to
+ __builtin_setjmp. It updates the stack pointer in that block to
correspond
+ to the current stack pointer. */
static void
expand_builtin_update_setjmp_buf (rtx buf_addr)
@@ -6205,8 +6205,8 @@
gcc_unreachable ();
case BUILT_IN_SETJMP_SETUP:
- /* __builtin_setjmp_setup is passed a pointer to an array of five
words
- and the receiver label. */
+ /* __builtin_setjmp_setup is passed a pointer to an array of five
+Pmode sized entries and the receiver label. */
if (validate_arglist (exp, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
{
rtx buf_addr = expand_expr (CALL_EXPR_ARG (exp, 0), subtarget,
@@ -6239,9 +6239,9 @@
}
break;
- /* __builtin_longjmp is passed a pointer to an array of five words.
-It's similar to the C library longjmp function but works with
-__builtin_setjmp above. */
+ /* __builtin_longjmp is passed a pointer to an array of five Pmode
+sized entries. It's similar to the C library longjmp function
+but works with __builtin_setjmp above. */
case BUILT_IN_LONGJMP:
if (validate_arglist (exp, POINTER_TYPE, INTEGER_TYPE, VOID_TYPE))
{
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 210096)
+++ gcc/doc/md.texi (working copy)
@@ -6113,8 +6113,10 @@
as a pointer to a global table, must be restored. Though it is
preferred that the
Re: RFA: Fix calculation of size of builtin setjmp buffer
Hi Jakub,
But what will this do on targets where POINTER_SIZE is smaller than
BITS_PER_WORD? E.g. I think some options on s390 or ppc.
If you want it to be always 5 pointers, then you want
tmp = size_int (4);
and not something else, otherwise it really depends on how exactly it is
used, perhaps it can be 5 * MAX (BITS_PER_WORD / POINTER_SIZE, 1) - 1
or whatever else, but 5 * POINTER_SIZE / BITS_PER_WORD is definitely wrong.
Ah -I had not considered this.
OK - how about this revision ? It allocates a buffer big enough to hold
5 things, either pointers or words, whichever is bigger. The comments
are suitably adjusted as well.
Cheers
Nick
Index: gcc/except.c
===
--- gcc/except.c(revision 210096)
+++ gcc/except.c(working copy)
@@ -286,8 +286,9 @@
tmp = size_int (FIRST_PSEUDO_REGISTER + 2 - 1);
#endif
#else
- /* builtin_setjmp takes a pointer to 5 words. */
- tmp = size_int (5 * BITS_PER_WORD / POINTER_SIZE - 1);
+ /* builtin_setjmp uses a buffer big enough to hold
+5 pointers or 5 words, whichever is bigger. */
+ tmp = size_int ((5 * MAX (POINTER_SIZE, BITS_PER_WORD)) /
BITS_PER_WORD - 1);
#endif
tmp = build_index_type (tmp);
tmp = build_array_type (ptr_type_node, tmp);
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 210096)
+++ gcc/builtins.c (working copy)
@@ -977,10 +977,10 @@
emit_insn (gen_blockage ());
}
-/* __builtin_longjmp is passed a pointer to an array of five words (not
- all will be used on all machines). It operates similarly to the C
- library function of the same name, but is more efficient. Much of
- the code below is copied from the handling of non-local gotos. */
+/* __builtin_longjmp is passed a pointer to an array of five word/pointer
+ sized entries, not all will be used on all machines. It operates
similarly
+ to the C library function of the same name, but is more efficient. Much
+ of the code below is copied from the handling of non-local gotos. */
static void
expand_builtin_longjmp (rtx buf_addr, rtx value)
@@ -1204,10 +1204,10 @@
return const0_rtx;
}
-/* __builtin_update_setjmp_buf is passed a pointer to an array of five
words
- (not all will be used on all machines) that was passed to
__builtin_setjmp.
- It updates the stack pointer in that block to correspond to the current
- stack pointer. */
+/* __builtin_update_setjmp_buf is passed a pointer to an array of five
+ entries (not all will be used on all machines) that was passed to
+ __builtin_setjmp. It updates the stack pointer in that block to
+ correspond to the current stack pointer. */
static void
expand_builtin_update_setjmp_buf (rtx buf_addr)
@@ -6205,8 +6205,8 @@
gcc_unreachable ();
case BUILT_IN_SETJMP_SETUP:
- /* __builtin_setjmp_setup is passed a pointer to an array of five
words
- and the receiver label. */
+ /* __builtin_setjmp_setup is passed a pointer to an array of five
+entries and the receiver label. */
if (validate_arglist (exp, POINTER_TYPE, POINTER_TYPE, VOID_TYPE))
{
rtx buf_addr = expand_expr (CALL_EXPR_ARG (exp, 0), subtarget,
@@ -6239,9 +6239,9 @@
}
break;
- /* __builtin_longjmp is passed a pointer to an array of five words.
-It's similar to the C library longjmp function but works with
-__builtin_setjmp above. */
+ /* __builtin_longjmp is passed a pointer to an array of five
+entries. It's similar to the C library longjmp function
+but works with __builtin_setjmp above. */
case BUILT_IN_LONGJMP:
if (validate_arglist (exp, POINTER_TYPE, INTEGER_TYPE, VOID_TYPE))
{
Index: gcc/doc/md.texi
===
--- gcc/doc/md.texi (revision 210096)
+++ gcc/doc/md.texi (working copy)
@@ -6112,10 +6112,15 @@
A typical reason why you might need this pattern is if some value, such
as a pointer to a global table, must be restored. Though it is
preferred that the pointer value be recalculated if possible (given the
-address of a label for instance). The single argument is a pointer to
-the @code{jmp_buf}. Note that the buffer is five words long and that
-the first three are normally used by the generic mechanism.
+address of a label for instance).
+The single argument is a pointer to the @code{jmp_buf}. This buffer
+is big enough to hold five @code{word_mode} or @code{Pmode} sized
+entries, whichever is bigger. The generic machanism uses just the
+first three entries, (to hold the frame pointer, return address and
+stack pointer respectively), but target specific code can use all five
+of them.
+
@cindex @code{builtin_setjmp_receiver} instruction pattern
@item @samp{builtin_setjmp_receiver}
This pattern, if defined,
Re: RFA: x86 backend: Add default-manifest to Cygwin/MinGW links
Hi Kai, The default manifest file contains a resource section (.rsrc) holding information necessary for the binary to be run under Windows 8. It is placed last on the linker command line so that a user provided manifest, if there is one, will take precedence over the default manifest. Well, I am a bit concerned about the position of the manifest-object. What will actually happen, if user specifies an user-specific manifest-object. Will the default one, if present, be ignored, or will it be still linked? The default one, if present, will be ignored[1]. This is why I am using ENDFILE_SPEC to add the default manifest to the linker command line. This ensures that the default manifest is placed after any user specified object files on the linker command line. The resource merging code in the linker is specifically designed to drop any duplicate resources, only keeping the resource that appeared first on the command line. Cheers Nick [1] Strictly speaking the default manifest will not be ignored. It will be included in the link, and merged into the output .rsrc section. But the resource merging code in the linker will drop everything in the default manifest giving preference to the user supplied manifest instead.
Re: RFA: x86 backend: Add default-manifest to Cygwin/MinGW links
Hi Corinna, However, we know that the act of merging will currently result in broken resources in the executable. Wouldn't it be better to apply the above patch only after the resource merge fix? No. Well not in my opinion. :-) The reason is that this patch only makes a difference if the default manifest can be found in a library search path. If there is none present then nothing happens. So you can disable the (broken) merging of a default manifest file by simply not having it present. Which should be the case for all current installations. Plus - I am hoping to fix the resource merging problem soon. (Any day now, honest). So I would like to have the gcc patch in place for when that happens. Cheers Nick
