Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP
> The PA and SPARC back ends do not define DONT_USE_BUILTIN_SETJMP, so > they also do not have to define JMP_BUF_SIZE. So: > > * config/sparc/sparc.h (JMP_BUF_SIZE): Do not define. > * config/pa/pa.h (JMP_BUF_SIZE): Likewise. > > OK for trunk? OK for the SPARC, thanks. What about the Stormy16 and the picoChip? It seems like a cleanup is possible in this area for them as well. -- Eric Botcazou
[committed] update my email address.
as per $SUBJECT, Iain * MAINTAINERS (Write After Approval): Update my email address. Index: MAINTAINERS === --- MAINTAINERS (revision 188917) +++ MAINTAINERS (working copy) @@ -486,7 +486,7 @@ Ira Rosen i...@il.ibm.com Maciej W. Rozycki ma...@linux-mips.org Silvius Rusr...@google.com Matthew Sachs msa...@apple.com -Iain Sandoeia...@gcc.gnu.org +Iain Sandoei...@codesourcery.com Duncan Sands baldr...@gcc.gnu.org William Schmidtwschm...@linux.vnet.ibm.com Dodji Seketeli do...@gcc.gnu.org
[Patch Darwin/m32/ObjC] Fix m32 ObjC exceptions model breakage.
Hello H.J.
i686-Darwin, m32, ObjC is still broken from the patch to "Add
OPTION_MASK_ISA_X86_64 and support TARGET_BI_ARCH == 2"
As I pointed out in [1], in the case of the NeXT runtime, the ABI and
exceptions model depend on the multi-lib.
Currently, the exceptions model is set from C_COMMON_OVERRIDE_OPTIONS, which is
called before SUBTARGET_OVERRIDE_OPTIONS.
However, following your change, the User's multi-lib choice is no longer valid
when C_COMMON_OVERRIDE_OPTIONS is called, therefore I propose to move the tests
to SUBSUBTARGET_OVERRIDE_OPTIONS (darwin_override_options).
OK for trunk?
Iain
[1]
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00393.html
gcc:
* config/darwin.h (SUBTARGET_C_COMMON_OVERRIDE_OPTIONS): Move NeXT
runtime
exceptions model setting from here ...
* config/darwin.c (darwin_override_options): ... to here.
Index: gcc/config/darwin.c
===
--- gcc/config/darwin.c (revision 188918)
+++ gcc/config/darwin.c (working copy)
@@ -3007,6 +3007,18 @@ darwin_override_options (void)
flag_reorder_blocks = 1;
}
+/* FIXME: flag_objc_sjlj_exceptions is no longer needed since there is only
+ one valid choice of exception scheme for each runtime. */
+if (!global_options_set.x_flag_objc_sjlj_exceptions)
+ global_options.x_flag_objc_sjlj_exceptions =
+ flag_next_runtime && !TARGET_64BIT;
+
+/* FIXME: and this could be eliminated then too. */
+if (!global_options_set.x_flag_exceptions
+ && flag_objc_exceptions
+ && TARGET_64BIT)
+ flag_exceptions = 1;
+
if (flag_mkernel || flag_apple_kext)
{
/* -mkernel implies -fapple-kext for C++ */
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 188918)
+++ gcc/config/darwin.h (working copy)
@@ -140,9 +140,6 @@ extern GTY(()) int darwin_ms_struct;
} while (0)
#define SUBTARGET_C_COMMON_OVERRIDE_OPTIONS do {\
-if (!global_options_set.x_flag_objc_sjlj_exceptions) \
- global_options.x_flag_objc_sjlj_exceptions = \
- flag_next_runtime && !TARGET_64BIT; \
if (flag_mkernel || flag_apple_kext) \
{
\
if (flag_use_cxa_atexit == 2) \
[Patch, Darwin, x86] fix 53283
As described in the PR thread, Darwin was already using the TARGET_FOLD_BUILTIN
hook to process CFstrings.
The patch fixes the breakage by calling a SUBTARGET_FOLD_BUILTIN where defined
(following similar patterns for other items that require sub-target handling).
OK for trunk?
Iain
gcc:
PR target/53283
* config/i386/i386.c (ix86_fold_builtin): Call SUBTARGET_FOLD_BUILTIN
if defined.
* config/darwin.h: Rename TARGET_FOLD_BUILTIN to
SUBTARGET_FOLD_BUILTIN.
* config/rs6000/darwin.h: Map TARGET_FOLD_BUILTIN onto
SUBTARGET_FOLD_BUILTIN.
Index: gcc/config/i386/i386.c
===
--- gcc/config/i386/i386.c (revision 188918)
+++ gcc/config/i386/i386.c (working copy)
@@ -28030,6 +28030,10 @@ ix86_fold_builtin (tree fndecl, int n_args,
}
}
+#ifdef SUBTARGET_FOLD_BUILTIN
+ return SUBTARGET_FOLD_BUILTIN (fndecl, n_args, args, ignore);
+#endif
+
return NULL_TREE;
}
Index: gcc/config/rs6000/darwin.h
===
--- gcc/config/rs6000/darwin.h (revision 188918)
+++ gcc/config/rs6000/darwin.h (working copy)
@@ -422,3 +422,7 @@ do {
\
rs6000_builtin_decls[(unsigned) (RS6000_BUILTIN_CFSTRING)] \
= darwin_init_cfstring_builtins ((unsigned) (RS6000_BUILTIN_CFSTRING)); \
} while(0)
+
+/* So far, there is no rs6000_fold_builtin, if one is introduced, then
+ this will need to be modified similar to the x86 case. */
+#define TARGET_FOLD_BUILTIN SUBTARGET_FOLD_BUILTIN
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 188918)
+++ gcc/config/darwin.h (working copy)
@@ -912,7 +909,7 @@ void add_framework_path (char *);
#define TARGET_KEXTABI flag_apple_kext
/* We have target-specific builtins. */
-#define TARGET_FOLD_BUILTIN darwin_fold_builtin
+#define SUBTARGET_FOLD_BUILTIN darwin_fold_builtin
#define TARGET_N_FORMAT_TYPES 1
#define TARGET_FORMAT_TYPES darwin_additional_format_types
Re: [PATCH] Move Graphite to upstream cloog 0.17.0
On Fri, 22 Jun 2012, Richard Guenther wrote: > > This bumps the requirement to enable Graphite to using cloog 0.17.0 > which is the last release from upstream. The patch removes the > support for the legacy cloog versions, too. > > I am bootstrapping and testing this now with cloog 0.17.0 built > against the upstream ISL 0.10 version. > > If this ends up being approved I will put the cloog 0.17.0 tarball > in the infrastructure directory. > > Bootstrap and regtest pending on x86_64-unknown-linux-gnu. > > Ok for trunk (for the build parts)? The patch passed bootstrap and testing on x86_64-unknown-linux-gnu. Richard. > 2012-06-22 Richard Guenther > > Merge from graphite branch > 2011-07-21 Tobias Grosser > > * configure: Regenerated. > * config/cloog.m4: Remove support for CLooG-ppl and CLooG-parma, > both cloog.org and legacy versions. The only supported version will > be CLooG with the isl backend. > > 2011-07-21 Tobias Grosser > > * configure: Regenerated. > * configure.ac: Require cloog isl 0.17.0 > > 2011-07-21 Tobias Grosser > > * configure: Regenerated. > * config/cloog.m4: Do not define CLOOG_ORG > > gcc/ > * Makefile.in (graphite-clast-to-gimple.o, graphite-cloog-util.o): > Remove graphite-cloog-util.h. > * graphite-clast-to-gimple.c (gcc_type_for_iv_of_clast_loop, > build_iv_mapping, translate_clast_user, translate_clast, > free_scattering, initialize_cloog_names, build_cloog_prog, > create_params_index): Do not use old compatibility functions. > (clast_name_to_index, set_cloog_options): Remove code for legacy cloog. > * graphite-cloog-util.c (openscop_print_cloog_matrix): Do not use old > compatibility functions. > (new_Cloog_Scattering_from_ppl_Polyhedron): Remove code for legacy > cloog. > * graphite-cloog-util.h: Remove include of graphite-cloog-util.h. > * graphite.c (graphite.c): Do not call outdated cloog_initialize() and > cloog_finalize(). > * graphite-cloog-compat.h: Remove. > > 2011-08-09 Tobias Grosser > > gcc/ > * graphite-clast-to-gimple.c (new_clast_name_index): Store a copy > of the string, no just a reference. > (clast_name_index): Add a new field, that specifies if we need to free > the name. > (free_clast_name_index): If necessary, free the name string. > (clast_name_index_elt_info): Calculate the hash based on the string > content, not the memory location it is stored in. > (clast_name_to_level): Specify that we do not need to free the name. > (clast_name_to_index): Dito. > (clast_name_to_lb_ub): Dito. > (eq_clast_name_indexes): Compare the strings, not their base pointers. > (free_scattering): Removed. > (initialize_cloog_names): Renamed to add_names_to_union_domain(). > (add_names_to_union_domain): Changed to work on a union_domain, > instead of a CloogNames structure. > (build_cloog_prog): Removed. > (build_cloog_union_domain): New. > (generate_cloog_input): New. > (scop_to_clast): Use CloogInput instead of CloogProgram. > (print_generated_program): Adapt to new scop_to_clast() and do not > print the CloogProgram any more. > (create_params_index): Removed, functionality integrated in > add_names_to_union_domain(). > (gloog): Adapt to new scop_to_clast(). > * graphite-clast-to-gimple.h (scop_to_clast): Remove. > > 2012-01-11 Tobias Grosser > > * graphite-clast-to-gimple.c (clast_name_to_index, > clast_name_to_lb_ub, clast_name_to_gcc): Change types. > (clast_to_gcc_expression): Add clast_expr_name as a new > case. Do not assume a clast_expr_term points always to a > clast_expr_name. > (type_for_clast_term): Do not assume a clast_expr_term points always to > a clast_expr_name. > (type_for_clast_name): New. > (type_for_clast_expr): Add clast_expr_name as a new case. > > 2011-08-03 Sebastian Pop > > * graphite-cloog-util.c (new_Cloog_Domain_from_ppl_Polyhedron, > new_Cloog_Scattering_from_ppl_Polyhedron, > new_Cloog_Domain_from_ppl_Pointset_Powerset): Remove ATTRIBUTE_UNUSED. > > > Index: configure.ac > === > --- configure.ac (revision 17) > +++ configure.ac (working copy) > @@ -1623,7 +1623,7 @@ if test "x$with_cloog" != "xno"; then >dnl >dnl If we use CLooG-Legacy, the provided version information is >dnl ignored. > - CLOOG_CHECK_VERSION(0,16,1) > + CLOOG_CHECK_VERSION(0,17,0) > >dnl Only execute fail-action, if CLooG has been requested. >CLOOG_IF_FAILED([ > Index: config/cloog.m4 > === > --- config/cloog.m4 (revision 17) > +++ config/cloog.m4
Re: [PATCH] Move Graphite to upstream cloog 0.17.0
On 06/25/2012 09:59 AM, Richard Guenther wrote: On Fri, 22 Jun 2012, Richard Guenther wrote: This bumps the requirement to enable Graphite to using cloog 0.17.0 which is the last release from upstream. The patch removes the support for the legacy cloog versions, too. I am bootstrapping and testing this now with cloog 0.17.0 built against the upstream ISL 0.10 version. If this ends up being approved I will put the cloog 0.17.0 tarball in the infrastructure directory. Bootstrap and regtest pending on x86_64-unknown-linux-gnu. Ok for trunk (for the build parts)? The patch passed bootstrap and testing on x86_64-unknown-linux-gnu. I am in favor of pushing this in, but there is still a build system ack required. Richard, thanks for working on this! Tobi
Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP
On Mon, Jun 25, 2012 at 12:31 AM, DJ Delorie wrote: > >> The rl78 apparently doesn't know what it wants to do: >> >> /* NOTE: defined but zero means dwarf2 debugging, but sjlj EH. */ >> #define DWARF2_UNWIND_INFO 0 >> /*#define DONT_USE_BUILTIN_SETJMP 1*/ >> #undef DONT_USE_BUILTIN_SETJMP >> #define JMP_BUF_SIZE (8*3+8) >> >> But I'll leave that to an rl78 maintainer. > > RL78 has a return address size different than pointer size, so the > default GCC code won't work for EH. For similar reasons, GCC's > internal setjmp won't work either. Right. And rl78 does *not* define DONT_USE_BUILTIN_SETJMP. In other words, your port *does* use the internal setjmp code right now. If that doesn't work for EH, your port has a bug. Ciao! Steven
Re: [patch][doc] Add some missing libraries to sourcebuild.texi
On Sun, Jun 24, 2012 at 10:06 PM, Steven Bosscher wrote:
> Hello,
>
> Noticed while going through sourcebuild.texi to see what needs
> updating for the move of the C front end to its own subdirectory of
> gcc/.
>
> Ok for trunk?
Ok.
Thanks,
Richard.
> Ciao!
> Steven
>
> * doc/sourcebuild.texi: Add missing subdirectories.
>
> Index: doc/sourcebuild.texi
> ===
> --- doc/sourcebuild.texi (revision 188917)
> +++ doc/sourcebuild.texi (working copy)
> @@ -66,6 +66,10 @@ include it in @code{libc}.
> @item libada
> The Ada runtime library.
>
> +@item libatomic
> +The runtime support library for atomic operations (e.g. for @code{__sync}
> +and @code{__atomic}).
> +
> @item libcpp
> The C preprocessor library.
>
> @@ -94,6 +98,9 @@ generally useful data structures and algorithms.
> Introduction, libiberty, @sc{gnu} libiberty}, for more information
> about this library.
>
> +@item libitm
> +The runtime support library for transactional memory.
> +
> @item libjava
> The Java runtime library.
>
> @@ -104,6 +111,9 @@ dereferencing operations.
> @item libobjc
> The Objective-C and Objective-C++ runtime library.
>
> +@item libquadmath
> +The runtime support library for quad-precision math operations.
> +
> @item libssp
> The Stack protector runtime library.
Re: [patch][doc] Document JMP_BUF_SIZE
On Sun, Jun 24, 2012 at 11:56 PM, Steven Bosscher wrote:
> Hello,
>
> Documentation for this target macro is missing.
> This patch adds it. OK for trunk?
Ok.
Thanks,
Richard.
> Ciao!
> Steven
>
> * doc/tm.texi.in: Document JMP_BUF_SIZE.
> * doc/tm.texi: Regenerate.
>
>
>
> Index: doc/tm.texi.in
> ===
> --- doc/tm.texi.in (revision 188917)
> +++ doc/tm.texi.in (working copy)
> @@ -8856,6 +8856,14 @@ should use the @code{setjmp}/@code{longjmp} functi
> instead of the @code{__builtin_setjmp}/@code{__builtin_longjmp} machinery.
> @end defmac
>
> +@defmac JMP_BUF_SIZE
> +This macro has no effect unless @code{DONT_USE_BUILTIN_SETJMP} is also
> +defined. Define this macro if the default size of @code{jmp_buf} buffer
> +for the @code{setjmp}/@code{longjmp}-based exception handling mechanism
> +is not large enough, or if it is much too large.
> +The default size is @code{FIRST_PSEUDO_REGISTER * sizeof(void *)}.
> +@end defmac
> +
> @defmac DWARF_CIE_DATA_ALIGNMENT
> This macro need only be defined if the target might save registers in the
> function prologue at an offset to the stack pointer that is not aligned to
> Index: doc/tm.texi
> ===
> --- doc/tm.texi (revision 188917)
> +++ doc/tm.texi (working copy)
> @@ -8961,6 +8961,14 @@ should use the @code{setjmp}/@code{longjmp} functi
> instead of the @code{__builtin_setjmp}/@code{__builtin_longjmp} machinery.
> @end defmac
>
> +@defmac JMP_BUF_SIZE
> +This macro has no effect unless @code{DONT_USE_BUILTIN_SETJMP} is also
> +defined. Define this macro if the default size of @code{jmp_buf} buffer
> +for the @code{setjmp}/@code{longjmp}-based exception handling mechanism
> +is not large enough, or if it is much too large.
> +The default size is @code{FIRST_PSEUDO_REGISTER * sizeof(void *)}.
> +@end defmac
> +
> @defmac DWARF_CIE_DATA_ALIGNMENT
> This macro need only be defined if the target might save registers in the
> function prologue at an offset to the stack pointer that is not aligned to
Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP
On Mon, Jun 25, 2012 at 9:13 AM, Eric Botcazou wrote: >> The PA and SPARC back ends do not define DONT_USE_BUILTIN_SETJMP, so >> they also do not have to define JMP_BUF_SIZE. So: >> >> * config/sparc/sparc.h (JMP_BUF_SIZE): Do not define. >> * config/pa/pa.h (JMP_BUF_SIZE): Likewise. >> >> OK for trunk? > > OK for the SPARC, thanks. And thanks to you for the ack! :-) > What about the Stormy16 and the picoChip? It seems > like a cleanup is possible in this area for them as well. Right, I didn't look at the details of the uses of DONT_USE_BUILTIN_SETJMP and JMP_BUF_SIZE but it looks like the ones in picochip and stormy16 are redundant too: For picochip, this port defines DONT_USE_BUILTIN_SETJMP but in the .c file (and after all #includes), so it is never exported and not otherwise referenced in picochip.c, hence dead: config/picochip/picochip.c:#undef DONT_USE_BUILTIN_SETJMP config/picochip/picochip.c:#define DONT_USE_BUILTIN_SETJMP 1 stormy16 only undefines DONT_USE_BUILTIN_SETJMP (which is the default anyway) so these two lines are redundant: config/stormy16/stormy16.h:#undef DONT_USE_BUILTIN_SETJMP config/stormy16/stormy16.h:#define JMP_BUF_SIZE 8 I will remove those lines with the same commit. That leaves only rl78 and ia64: $ egrep "DONT_USE_BUILTIN_SETJMP|JMP_BUF_SIZE" config/* config/*/* config/ia64/freebsd.h:#define JMP_BUF_SIZE 76 config/ia64/hpux.h:#define JMP_BUF_SIZE (8 * 76) config/ia64/ia64.h:#define DONT_USE_BUILTIN_SETJMP config/ia64/linux.h:#define JMP_BUF_SIZE 76 config/ia64/vms.h:#define JMP_BUF_SIZE (8 * 76) config/rl78/rl78.h:/*#define DONT_USE_BUILTIN_SETJMP 1*/ config/rl78/rl78.h:#undef DONT_USE_BUILTIN_SETJMP config/rl78/rl78.h:#define JMP_BUF_SIZE (8*3+8) The ia64 ones have no useful comments. The 76 is a magic number and it seems strange to me that the size of JMP_BUF_SIZE depends on the OS (linux and freebsd have 76, hpux has 8*76, and vms copied the hpux example with the comment: "Maybe same as HPUX? Needs to be checked."). And anyway, these macros are only relevant for SJLJ exceptions - who uses that on ia64?? The rl78 one is, I think, a bug in the port. Ciao! Steven
Re: [Patch-v2] Adjustments for Windows x64 SEH
On Jun 22, 2012, at 5:04 PM, Richard Henderson wrote: > On 06/21/2012 12:48 AM, Tristan Gingold wrote: >> 2012-06-18 Tristan Gingold >> >> * config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ... >> (seh_cfa_adjust_cfa): ... that function. >> (seh_emit_stackalloc): Do not emit out of range values. >> * config/i386/i386.md: Delete unused UNSPEC_REG_SAVE, >> UNSPEC_DEF_CFA constants. >> * config/i386/i386.h (SEH_MAX_FRAME_SIZE): Define. >> * config/i386/i386.c (ix86_frame_pointer_required): Required >> for very large frames on SEH target. >> (ix86_compute_frame_layout): Save area is before frame pointer >> on SEH target. Handle very large frames. >> (ix86_expand_prologue): Likewise. > > Ok. I propose to backport it to the gcc 4.7 branch, as it fixes two issues: incorrect unwind info emitted and support of setjmp. Is it Ok ? Tristan.
Re: [Patch-v2] Adjustments for Windows x64 SEH
On Mon, 25 Jun 2012, Tristan Gingold wrote: > > On Jun 22, 2012, at 5:04 PM, Richard Henderson wrote: > > > On 06/21/2012 12:48 AM, Tristan Gingold wrote: > >> 2012-06-18 Tristan Gingold > >> > >>* config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ... > >>(seh_cfa_adjust_cfa): ... that function. > >>(seh_emit_stackalloc): Do not emit out of range values. > >>* config/i386/i386.md: Delete unused UNSPEC_REG_SAVE, > >>UNSPEC_DEF_CFA constants. > >>* config/i386/i386.h (SEH_MAX_FRAME_SIZE): Define. > >>* config/i386/i386.c (ix86_frame_pointer_required): Required > >>for very large frames on SEH target. > >>(ix86_compute_frame_layout): Save area is before frame pointer > >>on SEH target. Handle very large frames. > >>(ix86_expand_prologue): Likewise. > > > > Ok. > > I propose to backport it to the gcc 4.7 branch, as it fixes two issues: > incorrect unwind info emitted and support of setjmp. > Is it Ok ? Target maintainers call - but please give it some more time on trunk to allow regressions to be reported. Richard.
Re: [Patch] Adjustments for Windows x64 SEH
On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote: > Hello Tristan, > > patch works for me, too. Just one nit about the patch. > > 2012/6/18 Tristan Gingold : >> @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void) >> if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp) >> return true; >> >> + /* Win64 SEH, very large frames need a frame-pointer as maximum stack >> + allocation is 4GB (add a safety guard for saved registers). */ >> + if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE) >> +return true; > Where does this magic 4096 comes from? Is it intended to be the > page-size, or is it meant to be the maximum stack-frame consumed by > prologue? I would suggest to use here instead: > + if (TARGET_64BIT_MS_ABI && get_frame_size () > (SEH_MAX_FRAME_SIZE - 4096)) > +return true; > > Additional a testcase for big-stackframe would be interesting. You > won't need to make here a execution test, a assembler-scan would be > enough. I suppose this is checked by large-frame.c. But it requires lp64; what is the correct writing to enable this test only on 64bit mode ? Tristan.
Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP
On Jun 25, 2012, at 10:26 AM, Steven Bosscher wrote: > On Mon, Jun 25, 2012 at 9:13 AM, Eric Botcazou > wrote: >>> The PA and SPARC back ends do not define DONT_USE_BUILTIN_SETJMP, so >>> they also do not have to define JMP_BUF_SIZE. So: >>> >>> * config/sparc/sparc.h (JMP_BUF_SIZE): Do not define. >>> * config/pa/pa.h (JMP_BUF_SIZE): Likewise. >>> >>> OK for trunk? >> >> OK for the SPARC, thanks. > > And thanks to you for the ack! :-) > >> What about the Stormy16 and the picoChip? It seems >> like a cleanup is possible in this area for them as well. > > Right, I didn't look at the details of the uses of > DONT_USE_BUILTIN_SETJMP and JMP_BUF_SIZE but it looks like the ones in > picochip and stormy16 are redundant too: > > For picochip, this port defines DONT_USE_BUILTIN_SETJMP but in the .c > file (and after all #includes), so it is never exported and not > otherwise referenced in picochip.c, hence dead: > config/picochip/picochip.c:#undef DONT_USE_BUILTIN_SETJMP > config/picochip/picochip.c:#define DONT_USE_BUILTIN_SETJMP 1 > > stormy16 only undefines DONT_USE_BUILTIN_SETJMP (which is the default > anyway) so these two lines are redundant: > config/stormy16/stormy16.h:#undef DONT_USE_BUILTIN_SETJMP > config/stormy16/stormy16.h:#define JMP_BUF_SIZE 8 > > I will remove those lines with the same commit. > > That leaves only rl78 and ia64: > $ egrep "DONT_USE_BUILTIN_SETJMP|JMP_BUF_SIZE" config/* config/*/* > config/ia64/freebsd.h:#define JMP_BUF_SIZE 76 > config/ia64/hpux.h:#define JMP_BUF_SIZE (8 * 76) > config/ia64/ia64.h:#define DONT_USE_BUILTIN_SETJMP > config/ia64/linux.h:#define JMP_BUF_SIZE 76 > config/ia64/vms.h:#define JMP_BUF_SIZE (8 * 76) > config/rl78/rl78.h:/*#define DONT_USE_BUILTIN_SETJMP 1*/ > config/rl78/rl78.h:#undef DONT_USE_BUILTIN_SETJMP > config/rl78/rl78.h:#define JMP_BUF_SIZE (8*3+8) > > The ia64 ones have no useful comments. The 76 is a magic number and it > seems strange to me that the size of JMP_BUF_SIZE depends on the OS > (linux and freebsd have 76, hpux has 8*76, and vms copied the hpux > example with the comment: "Maybe same as HPUX? Needs to be > checked."). And anyway, these macros are only relevant for SJLJ > exceptions - who uses that on ia64?? FTR, until recently I think it was not possible to use SJLJ on ia64 due to a typo. On hpux, the definition of jmp_buf is: # define _JBLEN 320 typedef __float80 jmp_buf[_JBLEN/4]; which looks weird... Tristan.
Re: [Patch, Darwin, x86] fix 53283
On Jun 25, 2012, at 12:53 AM, Iain Sandoe wrote: > As described in the PR thread, Darwin was already using the > TARGET_FOLD_BUILTIN hook to process CFstrings. > > The patch fixes the breakage by calling a SUBTARGET_FOLD_BUILTIN where > defined (following similar patterns for other items that require sub-target > handling). > > OK for trunk? Ok.
Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP
> Right, I didn't look at the details of the uses of > DONT_USE_BUILTIN_SETJMP and JMP_BUF_SIZE but it looks like the ones in > picochip and stormy16 are redundant too: > > For picochip, this port defines DONT_USE_BUILTIN_SETJMP but in the .c > file (and after all #includes), so it is never exported and not > otherwise referenced in picochip.c, hence dead: > config/picochip/picochip.c:#undef DONT_USE_BUILTIN_SETJMP > config/picochip/picochip.c:#define DONT_USE_BUILTIN_SETJMP 1 > > stormy16 only undefines DONT_USE_BUILTIN_SETJMP (which is the default > anyway) so these two lines are redundant: > config/stormy16/stormy16.h:#undef DONT_USE_BUILTIN_SETJMP > config/stormy16/stormy16.h:#define JMP_BUF_SIZE 8 That's my understanding as well. > That leaves only rl78 and ia64: > $ egrep "DONT_USE_BUILTIN_SETJMP|JMP_BUF_SIZE" config/* config/*/* > config/ia64/freebsd.h:#define JMP_BUF_SIZE 76 > config/ia64/hpux.h:#define JMP_BUF_SIZE (8 * 76) > config/ia64/ia64.h:#define DONT_USE_BUILTIN_SETJMP > config/ia64/linux.h:#define JMP_BUF_SIZE 76 > config/ia64/vms.h:#define JMP_BUF_SIZE (8 * 76) > config/rl78/rl78.h:/*#define DONT_USE_BUILTIN_SETJMP 1*/ > config/rl78/rl78.h:#undef DONT_USE_BUILTIN_SETJMP > config/rl78/rl78.h:#define JMP_BUF_SIZE (8*3+8) > > The ia64 ones have no useful comments. The 76 is a magic number and it > seems strange to me that the size of JMP_BUF_SIZE depends on the OS > (linux and freebsd have 76, hpux has 8*76, and vms copied the hpux > example with the comment: "Maybe same as HPUX? Needs to be > checked."). And anyway, these macros are only relevant for SJLJ > exceptions - who uses that on ia64?? It looks like DONT_USE_BUILTIN_SETJMP was invented for the IA-64, probably because of the Register Stack Engine. But SPARC also has register windows, albeit less sophisticated, and can do without it. Morever, the Ada compiler uses __builtin_setjmp/__builtin_longjmp internally on the host (EH is used for error recovery) and is known to work fine on IA-64/Linux, HP-UX and VMS. In the end, it would appear that DONT_USE_BUILTIN_SETJMP was a quick trick to solve specific issues that could very likely have been solved otherwise. We should probably keep it for the sake of IA-64 and get rid of it for all other architectures, documenting that it isn't to be used in normal circumstances. -- Eric Botcazou
Re: [Patch Darwin/m32/ObjC] Fix m32 ObjC exceptions model breakage.
On Jun 25, 2012, at 12:52 AM, Iain Sandoe wrote: > OK for trunk? Ok. > * config/darwin.h (SUBTARGET_C_COMMON_OVERRIDE_OPTIONS): Move NeXT > runtime > exceptions model setting from here ... > * config/darwin.c (darwin_override_options): ... to here. Kinda nasty how delicate things are. :-(
GCC 4.5 branch is now frozen
The GCC 4.5 branch is now frozen for the final release off that branch and will then be officially closed. Thanks for your cooperation, Richard.
Re: [PING ARM Patches] PR53447: optimizations of 64bit ALU operation with constant
ping^2 thanks Carrot On Mon, Jun 18, 2012 at 6:17 PM, Carrot Wei wrote: > Hi > > Could ARM maintainers review following patches? > > http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00497.html > 64bit add/sub constants. > > http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01834.html > 64bit and with constants. > > http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01974.html > 64bit xor with constants. > > http://gcc.gnu.org/ml/gcc-patches/2012-06/msg00287.html > 64bit ior with constants. > > thanks > Carrot
Re: [PR debug/53682] avoid crash in cselib promote_debug_loc
On Jun 20, 2012, Alexandre Oliva wrote: > When promote_debug_loc was first introduced, it would never be called > with a NULL loc list. However, because of the strategy of temporarily > resetting loc lists before recursion introduced a few months ago in > alias.c, the earlier assumption no longer holds. > This patch adusts promote_debug_loc to deal with this case. > Ok to install? Unless there are objections in the next 24 hours, I'm going to install this in the 4.7 branch too. Regstrapped on x86_64-linux-gnu and i686-linux-gnu. > for gcc/ChangeLog > from Alexandre Oliva > PR debug/53682 > * cselib.c (promote_debug_loc): Don't crash on NULL argument. -- Alexandre Oliva, freedom fighterhttp://FSFLA.org/~lxoliva/ You must be the change you wish to see in the world. -- Gandhi Be Free! -- http://FSFLA.org/ FSF Latin America board member Free Software Evangelist Red Hat Brazil Compiler Engineer
Re: RFC: C++/OMP PATCH for c++/53565 (libgomp for-2.C failure)
On Thu, Jun 21, 2012 at 12:34:32AM -0700, Jason Merrill wrote: > All the tests in the libgomp and gcc testsuites pass with this > patch, but I'm not very confident about it because I don't fully > understand what the code is doing. In particular, I'm not sure what > the condition controlling the code in tsubst_omp_for_iterator that > looks at the clauses should be; init can never be a DECL_EXPR at > that point anymore. Don't remember exactly, but I'd guess I wanted to preserve as much as possible what the code was doing before for the non-class types. After RECUR init can't be DECL_EXPR, right? So if you do it unconditionally it doesn't need to be handled. > I'm also not sure whether moving the begin_omp_structured_block is > necessary, but it seemed like a good idea since we're handling the > DECL_EXPR earlier. Looking at the code now, I wonder whether begin_omp_structured_block shouldn't be moved later, not earlier, because the decl ctors should happen before the body of the worksharing region. But if it works as you wrote, I'm fine with it, I think the testsuite coverage should catch problematic cases. Jakub
Re: [PR debug/53682] avoid crash in cselib promote_debug_loc
On Mon, Jun 25, 2012 at 07:32:04AM -0300, Alexandre Oliva wrote: > Unless there are objections in the next 24 hours, I'm going to install > this in the 4.7 branch too. Regstrapped on x86_64-linux-gnu and > i686-linux-gnu. Just install it right away. Thanks. > > for gcc/ChangeLog > > from Alexandre Oliva > > > PR debug/53682 > > * cselib.c (promote_debug_loc): Don't crash on NULL argument. Jakub
Re: [Patch] Adjustments for Windows x64 SEH
2012/6/25 Tristan Gingold : > > On Jun 18, 2012, at 4:28 PM, Kai Tietz wrote: > >> Hello Tristan, >> >> patch works for me, too. Just one nit about the patch. >> >> 2012/6/18 Tristan Gingold : >>> @@ -8558,6 +8558,11 @@ ix86_frame_pointer_required (void) >>> if (TARGET_32BIT_MS_ABI && cfun->calls_setjmp) >>> return true; >>> >>> + /* Win64 SEH, very large frames need a frame-pointer as maximum stack >>> + allocation is 4GB (add a safety guard for saved registers). */ >>> + if (TARGET_64BIT_MS_ABI && get_frame_size () + 4096 > SEH_MAX_FRAME_SIZE) >>> + return true; >> Where does this magic 4096 comes from? Is it intended to be the >> page-size, or is it meant to be the maximum stack-frame consumed by >> prologue? I would suggest to use here instead: >> + if (TARGET_64BIT_MS_ABI && get_frame_size () > (SEH_MAX_FRAME_SIZE - >> 4096)) >> + return true; >> >> Additional a testcase for big-stackframe would be interesting. You >> won't need to make here a execution test, a assembler-scan would be >> enough. > > I suppose this is checked by large-frame.c. But it requires lp64; what is > the correct writing to enable this test only on 64bit mode ? > > Tristan. You can check for Windows 64-bit targets by 'llp64'. Check is in target-supports.exp Kai
[patch] Add a lexical block only when the callsite has source location info
During function inlining, a lexical block is added for each cloned
callee, and source info is attached to this block for addr2line to
derive the inline stack. However, some callsites do not have source
information attached to it. Adding a lexical block would be misleading
in this case. E.g. If a function is split, when the split callsite is
inlined back, the cloned callee should stay in the same lexical block
with its caller. This patch ensures that lexical blocks are only added
when the callsite has source location info in it.
Bootstrapped and passed gcc regression tests.
Is it ok for trunk?
Thanks,
Dehao
gcc/ChangeLog:
2012-06-25 Dehao Chen
* tree-profile.c: (expand_call_inline): Make a new lexical block only
when the call stmt has source location.
Index: gcc/tree-inline.c
===
--- gcc/tree-inline.c (revision 188926)
+++ gcc/tree-inline.c (working copy)
@@ -3950,10 +3950,17 @@
actual inline expansion of the body, and a label for the return
statements within the function to jump to. The type of the
statement expression is the return type of the function call. */
- id->block = make_node (BLOCK);
- BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
- BLOCK_SOURCE_LOCATION (id->block) = input_location;
- prepend_lexical_block (gimple_block (stmt), id->block);
+ if (gimple_has_location (stmt))
+{
+ id->block = make_node (BLOCK);
+ BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
+ BLOCK_SOURCE_LOCATION (id->block) = input_location;
+ prepend_lexical_block (gimple_block (stmt), id->block);
+}
+ else
+{
+ id->block = gimple_block (stmt);
+}
/* Local declarations will be replaced by their equivalents in this
map. */
Re: [patch] Add a lexical block only when the callsite has source location info
On Mon, Jun 25, 2012 at 1:43 PM, Dehao Chen wrote:
> During function inlining, a lexical block is added for each cloned
> callee, and source info is attached to this block for addr2line to
> derive the inline stack.
Well - the bug is then clearly
/* Set input_location here so we get the right instantiation context
if we call instantiate_decl from inlinable_function_p. */
saved_location = input_location;
if (gimple_has_location (stmt))
input_location = gimple_location (stmt)
which retails input_location instead of setting it to UNKNOWN_LOCATION.
Not adding a BLOCK will make debug information incorrect, no?
> However, some callsites do not have source
> information attached to it. Adding a lexical block would be misleading
> in this case. E.g. If a function is split, when the split callsite is
> inlined back, the cloned callee should stay in the same lexical block
> with its caller. This patch ensures that lexical blocks are only added
> when the callsite has source location info in it.
>
> Bootstrapped and passed gcc regression tests.
>
> Is it ok for trunk?
I'd rather see an unconditional set of input_location from gimple_location
of the statement.
Richard.
> Thanks,
> Dehao
>
> gcc/ChangeLog:
> 2012-06-25 Dehao Chen
>
> * tree-profile.c: (expand_call_inline): Make a new lexical block only
^
tree-inline.c
> when the call stmt has source location.
>
> Index: gcc/tree-inline.c
> ===
> --- gcc/tree-inline.c (revision 188926)
> +++ gcc/tree-inline.c (working copy)
> @@ -3950,10 +3950,17 @@
> actual inline expansion of the body, and a label for the return
> statements within the function to jump to. The type of the
> statement expression is the return type of the function call. */
> - id->block = make_node (BLOCK);
> - BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
> - BLOCK_SOURCE_LOCATION (id->block) = input_location;
> - prepend_lexical_block (gimple_block (stmt), id->block);
> + if (gimple_has_location (stmt))
> + {
> + id->block = make_node (BLOCK);
> + BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
> + BLOCK_SOURCE_LOCATION (id->block) = input_location;
Please use gimple_location (stmt) instead of input_location (yes, I realize
its set from that).
> + prepend_lexical_block (gimple_block (stmt), id->block);
> + }
> + else
> + {
> + id->block = gimple_block (stmt);
> + }
> /* Local declarations will be replaced by their equivalents in this
> map. */
[patch] [gcc/libgcc/ada/libstdc++] Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI
gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in various
other places as well. arm-linux-gnueabihf is used as a triplet by some
distributions.
Ok for the trunk?
Matthias
gcc/testsuite/
2012-06-25 Matthias Klose
* lib/target-supports.exp (check_profiling_available): Match
arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
gcc/ada/
2012-06-25 Matthias Klose
* gcc-interface/Makefile.in: Match arm*-*-linux-*eabi* for
ARM Linux/GNU EABI.
libgcc/
2012-06-25 Matthias Klose
* config.host: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
libstdc++-v3/
2012-06-25 Matthias Klose
* configure.host: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
* testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise.
* testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise.
libjava/
2012-06-25 Matthias Klose
* configure.ac: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
# DP: add support for arm-linux-*eabi* triplets; useful for armhf
--- a/src/libjava/configure.ac.orig
+++ b/src/libjava/configure.ac
@@ -924,7 +924,7 @@
# on Darwin -single_module speeds up loading of the dynamic libraries.
extra_ldflags_libjava=-Wl,-single_module
;;
-arm*linux*eabi)
+arm*-*-linux-*eabi*)
# Some of the ARM unwinder code is actually in libstdc++. We
# could in principle replicate it in libgcj, but it's better to
# have a dependency on libstdc++.
--- a/src/gcc/testsuite/lib/target-supports.exp.orig
+++ b/src/gcc/testsuite/lib/target-supports.exp
@@ -3235,7 +3235,7 @@
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
-|| [istarget arm*-*-linux-gnueabi]
+|| [istarget arm*-*-linux-*eabi*]
|| [istarget bfin*-*linux*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
@@ -3266,7 +3266,7 @@
|| [istarget i?86-*-*]
|| [istarget x86_64-*-*]
|| [istarget alpha*-*-*]
-|| [istarget arm*-*-linux-gnueabi]
+|| [istarget arm*-*-linux-*eabi*]
|| [istarget hppa*-*linux*]
|| [istarget s390*-*-*]
|| [istarget powerpc*-*-*]
--- a/src/gcc/ada/gcc-interface/Makefile.in.orig
+++ b/src/gcc/ada/gcc-interface/Makefile.in
@@ -1846,7 +1846,7 @@
LIBRARY_VERSION := $(LIB_VERSION)
endif
-ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word
4,$(targ,)
+ifeq ($(strip $(filter-out arm%-linux,$(arch)-$(osys)) $(if $(findstring
eabi,$(word 4,$(targ))),,$(word 4,$(targ,)
LIBGNAT_TARGET_PAIRS = \
a-intnam.ads
//
---
a/src/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc.orig
+++ b/src/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
@@ -1,5 +1,5 @@
// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums" }
-// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums
-Wl,--no-enum-size-warning" { target arm*-*-linux*eabi } }
+// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums
-Wl,--no-enum-size-warning" { target arm*-*-linux-*eabi* } }
// 2007-05-03 Benjamin Kosnik
//
--- a/src/libgcc/config.host
+++ b/src/libgcc/config.host
@@ -334,7 +334,7 @@
arm*-*-linux*) # ARM GNU/Linux with ELF
tmake_file="${tmake_file} arm/t-arm t-fixedpoint-gnu-prefix"
case ${host} in
- arm*-*-linux-*eabi)
+ arm*-*-linux-*eabi*)
tmake_file="${tmake_file} arm/t-elf arm/t-bpabi arm/t-linux-eabi
t-slibgcc-libgcc"
tm_file="$tm_file arm/bpabi-lib.h"
unwind_header=config/arm/unwind-arm.h
Re: [C++] Reject variably modified types in operator new
On 06/25/2012 05:25 AM, Jason Merrill wrote:
On 06/11/2012 12:11 PM, Florian Weimer wrote:
+ tree inner_nelts_cst = maybe_constant_value (inner_nelts);
+ if (!TREE_CONSTANT (inner_nelts_cst))
+ {
+ if (complain & tf_error)
+ error_at (EXPR_LOC_OR_HERE (inner_nelts),
+ "array size in operator new must be constant");
Please use cxx_constant_value to give a more specific error about what
is non-constant.
Thanks for your review.
I tried this, but for this example program,
/* 1 */ void f(int n, int m)
/* 2 */ {
/* 3 */ typedef char T[n];
/* 4 */ new T[m];
/* 5 */ }
GCC reports these errors:
/tmp/t.C: In function ‘void f(int, int)’:
/tmp/t.C:4:18: error: array size in operator new must be constant
/* 4 */ new T[m];
^
/tmp/t.C:4:18: error: ‘n’ is not a constant expression
The message should point to the typedef, but instead, it references the
line with operator new (which doesn't even contain the variable n).
For the non-VLA typedef case, it is an improvement. But I would like to
leave in both errors, as in the attached patch.
If you have suggestions how to improve cxx_constant_value error
reporting, I can look into that in a separate patch.
+ /* Warn if we performed the (T[N]) to T[N] transformation and N is
+ variable. */
+ if (outer_nelts_from_type
+ && !TREE_CONSTANT (maybe_constant_value (outer_nelts))
+ && (complain & tf_warning_or_error))
+ pedwarn(EXPR_LOC_OR_HERE (outer_nelts), OPT_Wvla,
+ "ISO C++ does not support variable-length array types");
Here, if we aren't complaining we should return error_mark_node; we
always need to act pedantic in SFINAE context.
The new version should do that.
I've added a new test case about error reporting in templates (where we
previously accepted ill-formed code such as new long[n][T::n] with n,
T::n both variables).
Bootstrapped and tested on x86_64-unknown-linux-gnu, with no new
regressions. OK for trunk?
--
Florian Weimer / Red Hat Product Security Team
2012-06-25 Florian Weimer
* init.c (build_new_1): Warn about (T[N]) for variable N, and
reject T[M][N].
* parser.c (cp_parser_direct_new_declarator): Accept non-constant
expressions. Handled now in build_new_1.
2012-06-25 Florian Weimer
* g++.dg/init/new35.C: New.
* g++.dg/init/new36.C: New.
* g++.dg/init/new37.C: New.
* g++.dg/ext/vla5.C: New warning.
* g++.dg/ext/vla8.C: New warning.
* g++.dg/cpp0x/regress/debug-debug7.C: Update diagnostics.
diff --git a/gcc/cp/init.c b/gcc/cp/init.c
index 419c13f..5a81643 100644
--- a/gcc/cp/init.c
+++ b/gcc/cp/init.c
@@ -2175,6 +2175,7 @@ build_new_1 (VEC(tree,gc) **placement, tree type, tree nelts,
tree pointer_type;
tree non_const_pointer_type;
tree outer_nelts = NULL_TREE;
+ bool outer_nelts_from_type = false;
tree alloc_call, alloc_expr;
/* The address returned by the call to "operator new". This node is
a VAR_DECL and is therefore reusable. */
@@ -2209,10 +2210,14 @@ build_new_1 (VEC(tree,gc) **placement, tree type, tree nelts,
}
else if (TREE_CODE (type) == ARRAY_TYPE)
{
+ /* Transforms new (T[N]) to new T[N]. The former is a GNU
+ extension for variable N. (This also covers new T where T is
+ a VLA typedef.) */
array_p = true;
nelts = array_type_nelts_top (type);
outer_nelts = nelts;
type = TREE_TYPE (type);
+ outer_nelts_from_type = true;
}
/* If our base type is an array, then make sure we know how many elements
@@ -2220,10 +2225,46 @@ build_new_1 (VEC(tree,gc) **placement, tree type, tree nelts,
for (elt_type = type;
TREE_CODE (elt_type) == ARRAY_TYPE;
elt_type = TREE_TYPE (elt_type))
-nelts = cp_build_binary_op (input_location,
-MULT_EXPR, nelts,
-array_type_nelts_top (elt_type),
-complain);
+{
+ tree inner_nelts = array_type_nelts_top (elt_type);
+ tree inner_nelts_cst = maybe_constant_value (inner_nelts);
+ if (!TREE_CONSTANT (inner_nelts_cst))
+ {
+ if (complain & tf_error)
+ {
+ error_at (EXPR_LOC_OR_HERE (inner_nelts),
+ "array size in operator new must be constant");
+ cxx_constant_value(inner_nelts);
+ }
+ nelts = error_mark_node;
+ }
+ if (nelts != error_mark_node)
+ nelts = cp_build_binary_op (input_location,
+MULT_EXPR, nelts,
+inner_nelts_cst,
+complain);
+}
+
+ if (variably_modified_type_p (elt_type, NULL_TREE) && (complain & tf_error))
+{
+ error ("variably modified type not allowed in operator new");
+ return error_mark_node;
+}
+
+ if (nelts == error_mark_node)
+return error_mark_node;
+
+ /* Warn if we performed the (T[N]) to T[N] transformation and N is
+ variable. */
+ if (outer_nelts_from_type
+ && !TREE_CONSTANT (maybe_constant_value (outer_nelts)))
+{
+ if (complain & tf_warning_or_error)
+ pedwarn(EXPR_LOC_OR_HERE (outer_nelts), OPT_Wvla,
+ "ISO C++ does not support variable-length array types");
+ else
+ return
Re: [patch] support for multiarch systems
Please find attached the patch updated for trunk 20120625, x86 only, tested on
x86-linux-gnu, KFreeBSD and the Hurd.
I left in the comment about the multiarch names, but I'm fine to change/discard
it. It was first required by Joseph Myers, then not found necessary by Paolo
Bonzini.
Ok for the trunk?
Matthias
2012-06-25 Matthias Klose
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
* config/i386/t-linux64: Likewise.
* config/i386/t-linux: Define MULTIARCH_DIRNAME.
* config/i386/t-gnu: Likewise.
Index: configure.ac
===
--- configure.ac(revision 188931)
+++ configure.ac(working copy)
@@ -623,6 +623,21 @@
[], [enable_multilib=yes])
AC_SUBST(enable_multilib)
+# Determine whether or not multiarch is enabled.
+AC_ARG_ENABLE(multiarch,
+[AS_HELP_STRING([--enable-multiarch],
+ [enable support for multiarch paths])],
+[case "${withval}" in
+yes|no|auto-detect) enable_multiarch=$withval;;
+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
+esac], [enable_multiarch=auto-detect])
+AC_MSG_CHECKING(for multiarch configuration)
+AC_SUBST(enable_multiarch)
+AC_MSG_RESULT($enable_multiarch)
+
+# needed for setting the multiarch name on ARM
+AC_SUBST(with_float)
+
# Enable __cxa_atexit for C++.
AC_ARG_ENABLE(__cxa_atexit,
[AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
Index: cppdefault.c
===
--- cppdefault.c(revision 188931)
+++ cppdefault.c(working copy)
@@ -63,6 +63,7 @@
#endif
#ifdef LOCAL_INCLUDE_DIR
/* /usr/local/include comes before the fixincluded header files. */
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
#endif
#ifdef PREFIX_INCLUDE_DIR
@@ -90,6 +91,7 @@
#endif
#ifdef NATIVE_SYSTEM_HEADER_DIR
/* /usr/include comes dead last. */
+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
#endif
{ 0, 0, 0, 0, 0, 0 }
Index: cppdefault.h
===
--- cppdefault.h(revision 188931)
+++ cppdefault.h(working copy)
@@ -43,9 +43,11 @@
C++. */
const char add_sysroot; /* FNAME should be prefixed by
cpp_SYSROOT. */
- const char multilib; /* FNAME should have the multilib path
- specified with -imultilib
- appended. */
+ const char multilib; /* FNAME should have appended
+ - the multilib path specified with -imultilib
+when 1 is passed,
+ - the multiarch path specified with
+-imultiarch, when 2 is passed. */
};
extern const struct default_include cpp_include_defaults[];
Index: Makefile.in
===
--- Makefile.in (revision 188931)
+++ Makefile.in (working copy)
@@ -350,6 +350,17 @@
enable_plugin = @enable_plugin@
+# Multiarch support
+enable_multiarch = @enable_multiarch@
+with_float = @with_float@
+ifeq ($(enable_multiarch),yes)
New Swedish PO file for 'gcc' (version 4.7.1)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Swedish team of translators. The file is available at: http://translationproject.org/latest/gcc/sv.po (This file, 'gcc-4.7.1.sv.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: http://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: http://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [patch] [gcc/libgcc/ada/libstdc++] Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI
On 25/06/12 13:08, Matthias Klose wrote:
> gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of
> arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in
> various
> other places as well. arm-linux-gnueabihf is used as a triplet by some
> distributions.
>
> Ok for the trunk?
>
now that all arm-linux ports are EABI conforming, why can't this just become
arm*-*-linux*
?
R.
> Matthias
>
> gcc/testsuite/
> 2012-06-25 Matthias Klose
>
> * lib/target-supports.exp (check_profiling_available): Match
> arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
>
> gcc/ada/
> 2012-06-25 Matthias Klose
>
> * gcc-interface/Makefile.in: Match arm*-*-linux-*eabi* for
> ARM Linux/GNU EABI.
>
> libgcc/
> 2012-06-25 Matthias Klose
>
> * config.host: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
>
> libstdc++-v3/
> 2012-06-25 Matthias Klose
>
> * configure.host: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
> * testsuite/20_util/make_signed/requirements/typedefs-2.cc: Likewise.
> * testsuite/20_util/make_unsigned/requirements/typedefs-2.cc: Likewise.
>
> libjava/
> 2012-06-25 Matthias Klose
>
> * configure.ac: Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI.
>
>
> armhf-triplet.diff
>
>
> # DP: add support for arm-linux-*eabi* triplets; useful for armhf
>
> --- a/src/libjava/configure.ac.orig
> +++ b/src/libjava/configure.ac
> @@ -924,7 +924,7 @@
> # on Darwin -single_module speeds up loading of the dynamic libraries.
> extra_ldflags_libjava=-Wl,-single_module
> ;;
> -arm*linux*eabi)
> +arm*-*-linux-*eabi*)
> # Some of the ARM unwinder code is actually in libstdc++. We
> # could in principle replicate it in libgcj, but it's better to
> # have a dependency on libstdc++.
> --- a/src/gcc/testsuite/lib/target-supports.exp.orig
> +++ b/src/gcc/testsuite/lib/target-supports.exp
> @@ -3235,7 +3235,7 @@
>|| [istarget i?86-*-*]
>|| [istarget x86_64-*-*]
>|| [istarget alpha*-*-*]
> - || [istarget arm*-*-linux-gnueabi]
> + || [istarget arm*-*-linux-*eabi*]
>|| [istarget bfin*-*linux*]
>|| [istarget hppa*-*linux*]
>|| [istarget s390*-*-*]
> @@ -3266,7 +3266,7 @@
>|| [istarget i?86-*-*]
>|| [istarget x86_64-*-*]
>|| [istarget alpha*-*-*]
> - || [istarget arm*-*-linux-gnueabi]
> + || [istarget arm*-*-linux-*eabi*]
>|| [istarget hppa*-*linux*]
>|| [istarget s390*-*-*]
>|| [istarget powerpc*-*-*]
> --- a/src/gcc/ada/gcc-interface/Makefile.in.orig
> +++ b/src/gcc/ada/gcc-interface/Makefile.in
> @@ -1846,7 +1846,7 @@
>LIBRARY_VERSION := $(LIB_VERSION)
> endif
>
> -ifeq ($(strip $(filter-out arm% linux-gnueabi,$(arch) $(osys)-$(word
> 4,$(targ,)
> +ifeq ($(strip $(filter-out arm%-linux,$(arch)-$(osys)) $(if $(findstring
> eabi,$(word 4,$(targ))),,$(word 4,$(targ,)
>LIBGNAT_TARGET_PAIRS = \
>a-intnam.adss-inmaop.adb --- a/src/libstdc++-v3/configure.host.orig
> +++ b/src/libstdc++-v3/configure.host
> @@ -322,7 +322,7 @@
> fi
> esac
> case "${host}" in
> - arm*-*-linux-*eabi)
> + arm*-*-linux-*eabi*)
>
> port_specific_symbol_files="\$(srcdir)/../config/os/gnu-linux/arm-eabi-extra.ver"
> ;;
> esac
> ---
> a/src/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc.orig
> +++
> b/src/libstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs-2.cc
> @@ -1,5 +1,5 @@
> // { dg-options "-std=gnu++0x -funsigned-char -fshort-enums" }
> -// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums
> -Wl,--no-enum-size-warning" { target arm*-*-linux*eabi } }
> +// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums
> -Wl,--no-enum-size-warning" { target arm*-*-linux-*eabi* } }
>
> // 2007-05-03 Benjamin Kosnik
> //
> ---
> a/src/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc.orig
> +++
> b/src/libstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs-2.cc
> @@ -1,5 +1,5 @@
> // { dg-options "-std=gnu++0x -funsigned-char -fshort-enums" }
> -// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums
> -Wl,--no-enum-size-warning" { target arm*-*-linux*eabi } }
> +// { dg-options "-std=gnu++0x -funsigned-char -fshort-enums
> -Wl,--no-enum-size-warning" { target arm*-*-linux-*eabi* } }
>
> // 2007-05-03 Benjamin Kosnik
> //
> --- a/src/libgcc/config.host
> +++ b/src/libgcc/config.host
> @@ -334,7 +334,7 @@
> arm*-*-linux*) # ARM GNU/Linux with ELF
> tmake_file="${tmake_file} arm/t-arm t-fixedpoint-gnu-prefix"
> case ${host} in
> - arm*-*-linux-*eabi)
> + arm*-*-linux-*eabi*)
> tmake_file="${tmake_file} arm/t-elf arm/t-bpabi arm/t-linux-eabi
> t-slibgcc-libgcc"
> tm_file="$tm_file arm/bpabi-lib.h"
>
Re: [patch] Add a lexical block only when the callsite has source location info
Hi, Richard,
Thanks for the prompt response.
On Mon, Jun 25, 2012 at 8:02 PM, Richard Guenther
wrote:
> On Mon, Jun 25, 2012 at 1:43 PM, Dehao Chen wrote:
>> During function inlining, a lexical block is added for each cloned
>> callee, and source info is attached to this block for addr2line to
>> derive the inline stack.
>
> Well - the bug is then clearly
>
> /* Set input_location here so we get the right instantiation context
> if we call instantiate_decl from inlinable_function_p. */
> saved_location = input_location;
> if (gimple_has_location (stmt))
> input_location = gimple_location (stmt)
>
> which retails input_location instead of setting it to UNKNOWN_LOCATION.
>
> Not adding a BLOCK will make debug information incorrect, no?
The only case I can think of that gimple_has_location is false for
call stmt is for function split.
If we have function foo, which is split into:
foo
foo.part1
And a callsite foo->foo.part1 is created in foo.
If the ipa-inline decided to inline this callsite, for an instruction
in foo.part1, it will have an inline stack of size 2. In the original
buggy code, the bottom of the inline stack will be random. Using your
proposed approach, the bottom of the inline stack would be
UNKNOW_LOCATION, but still has two levels. For function split, this
inline will not create any lexical block, but resumes the original
lexical block before the split. Thus my change simply not add a new
lexical block. Do you think this makes sense?
Thanks,
Dehao
>
>> However, some callsites do not have source
>> information attached to it. Adding a lexical block would be misleading
>> in this case. E.g. If a function is split, when the split callsite is
>> inlined back, the cloned callee should stay in the same lexical block
>> with its caller. This patch ensures that lexical blocks are only added
>> when the callsite has source location info in it.
>>
>> Bootstrapped and passed gcc regression tests.
>>
>> Is it ok for trunk?
>
> I'd rather see an unconditional set of input_location from gimple_location
> of the statement.
>
> Richard.
>
>> Thanks,
>> Dehao
>>
>> gcc/ChangeLog:
>> 2012-06-25 Dehao Chen
>>
>> * tree-profile.c: (expand_call_inline): Make a new lexical block only
>
> ^
> tree-inline.c
>
>> when the call stmt has source location.
>>
>> Index: gcc/tree-inline.c
>> ===
>> --- gcc/tree-inline.c (revision 188926)
>> +++ gcc/tree-inline.c (working copy)
>> @@ -3950,10 +3950,17 @@
>> actual inline expansion of the body, and a label for the return
>> statements within the function to jump to. The type of the
>> statement expression is the return type of the function call. */
>> - id->block = make_node (BLOCK);
>> - BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
>> - BLOCK_SOURCE_LOCATION (id->block) = input_location;
>> - prepend_lexical_block (gimple_block (stmt), id->block);
>> + if (gimple_has_location (stmt))
>> + {
>> + id->block = make_node (BLOCK);
>> + BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
>> + BLOCK_SOURCE_LOCATION (id->block) = input_location;
>
> Please use gimple_location (stmt) instead of input_location (yes, I realize
> its set from that).
>
>> + prepend_lexical_block (gimple_block (stmt), id->block);
>> + }
>> + else
>> + {
>> + id->block = gimple_block (stmt);
>> + }
>
>> /* Local declarations will be replaced by their equivalents in this
>> map. */
Re: [patch] support for multiarch systems
On Mon, 25 Jun 2012, Matthias Klose wrote: > Please find attached the patch updated for trunk 20120625, x86 only, tested on > x86-linux-gnu, KFreeBSD and the Hurd. This patch appears to include changes to config.gcc for other targets, not mentioned in your ChangeLog entries. Please resubmit without those changes, and submit them separately with their own rationale if needed. -- Joseph S. Myers jos...@codesourcery.com
Re: RFA: dead_debug_* ICE
On Sun, Jun 24, 2012 at 11:50:12AM +0100, Richard Sandiford wrote:
> --- gcc/df-problems.c 2012-06-23 13:28:55.576128246 +0100
> +++ gcc/df-problems.c 2012-06-24 11:25:36.851531368 +0100
> @@ -3209,7 +3210,8 @@ dead_debug_insert_temp (struct dead_debu
> the widest referenced mode. */
>while ((cur = *tailp))
> {
> - if (DF_REF_REGNO (cur->use) == uregno)
> + cur_reg = *DF_REF_REAL_LOC (cur->use);
> + if (REGNO (cur_reg) == uregno)
> {
> *usesp = cur;
> usesp = &cur->next;
> @@ -3217,21 +3219,13 @@ dead_debug_insert_temp (struct dead_debu
> cur->next = NULL;
> if (!reg
> || (GET_MODE_BITSIZE (GET_MODE (reg))
> - < GET_MODE_BITSIZE (GET_MODE (*DF_REF_REAL_LOC (cur->use)
> - reg = *DF_REF_REAL_LOC (cur->use);
> + < GET_MODE_BITSIZE (GET_MODE (cur_reg
> + reg = cur_reg;
> }
>else
> tailp = &(*tailp)->next;
> }
>
> - /* We may have dangling bits in debug->used for registers that were part
> - of a multi-register use, one component of which has been reset. */
> - if (reg == NULL)
> -{
> - gcc_checking_assert (!uses);
> - return 0;
> -}
> -
>gcc_checking_assert (uses);
>
>breg = reg;
Unfortunately this seems to break bootstrap on i686-linux.
Delta-reduced testcase is:
typedef _Complex float __attribute__ ((mode (TC))) __complex128;
extern __complex128 clogq (__complex128) __attribute__ ((__nothrow__));
__complex128
cacoshq (__complex128 x)
{
__complex128 res;
int rcls = __builtin_fpclassify (0, 1, 4, 3, 2, __real__ x);
int icls = __builtin_fpclassify (0, 1, 4, 3, 2, __imag__ x);
if (rcls <= 1 || icls <= 1)
{
__complex128 y;
res = clogq (y);
if (__real__ res < 0.0)
res = -res;
}
return res;
}
which ICEs at -O2 -g -fPIC -m32 in the above gcc_checking_assert (uses)
now.
Jakub
Re: [patch] Add a lexical block only when the callsite has source location info
On Mon, Jun 25, 2012 at 3:48 PM, Dehao Chen wrote:
> Hi, Richard,
>
> Thanks for the prompt response.
>
> On Mon, Jun 25, 2012 at 8:02 PM, Richard Guenther
> wrote:
>> On Mon, Jun 25, 2012 at 1:43 PM, Dehao Chen wrote:
>>> During function inlining, a lexical block is added for each cloned
>>> callee, and source info is attached to this block for addr2line to
>>> derive the inline stack.
>>
>> Well - the bug is then clearly
>>
>> /* Set input_location here so we get the right instantiation context
>> if we call instantiate_decl from inlinable_function_p. */
>> saved_location = input_location;
>> if (gimple_has_location (stmt))
>> input_location = gimple_location (stmt)
>>
>> which retails input_location instead of setting it to UNKNOWN_LOCATION.
>>
>> Not adding a BLOCK will make debug information incorrect, no?
>
> The only case I can think of that gimple_has_location is false for
> call stmt is for function split.
>
> If we have function foo, which is split into:
>
> foo
> foo.part1
>
> And a callsite foo->foo.part1 is created in foo.
>
> If the ipa-inline decided to inline this callsite, for an instruction
> in foo.part1, it will have an inline stack of size 2. In the original
> buggy code, the bottom of the inline stack will be random. Using your
> proposed approach, the bottom of the inline stack would be
> UNKNOW_LOCATION, but still has two levels. For function split, this
> inline will not create any lexical block, but resumes the original
> lexical block before the split. Thus my change simply not add a new
> lexical block. Do you think this makes sense?
I don't think it behaves sensibly for any other call without a location.
Basically you assume that this only happens for split functions but
I don't see why that should be true. Why would BLOCKs with
UNKOWN_LOCATION have any effect on addr2line anyways?
That seems to be something to check and fix.
Richard.
> Thanks,
> Dehao
>
>
>>
>>> However, some callsites do not have source
>>> information attached to it. Adding a lexical block would be misleading
>>> in this case. E.g. If a function is split, when the split callsite is
>>> inlined back, the cloned callee should stay in the same lexical block
>>> with its caller. This patch ensures that lexical blocks are only added
>>> when the callsite has source location info in it.
>>>
>>> Bootstrapped and passed gcc regression tests.
>>>
>>> Is it ok for trunk?
>>
>> I'd rather see an unconditional set of input_location from gimple_location
>> of the statement.
>>
>> Richard.
>>
>>> Thanks,
>>> Dehao
>>>
>>> gcc/ChangeLog:
>>> 2012-06-25 Dehao Chen
>>>
>>> * tree-profile.c: (expand_call_inline): Make a new lexical block only
>>
>> ^
>> tree-inline.c
>>
>>> when the call stmt has source location.
>>>
>>> Index: gcc/tree-inline.c
>>> ===
>>> --- gcc/tree-inline.c (revision 188926)
>>> +++ gcc/tree-inline.c (working copy)
>>> @@ -3950,10 +3950,17 @@
>>> actual inline expansion of the body, and a label for the return
>>> statements within the function to jump to. The type of the
>>> statement expression is the return type of the function call. */
>>> - id->block = make_node (BLOCK);
>>> - BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
>>> - BLOCK_SOURCE_LOCATION (id->block) = input_location;
>>> - prepend_lexical_block (gimple_block (stmt), id->block);
>>> + if (gimple_has_location (stmt))
>>> + {
>>> + id->block = make_node (BLOCK);
>>> + BLOCK_ABSTRACT_ORIGIN (id->block) = fn;
>>> + BLOCK_SOURCE_LOCATION (id->block) = input_location;
>>
>> Please use gimple_location (stmt) instead of input_location (yes, I realize
>> its set from that).
>>
>>> + prepend_lexical_block (gimple_block (stmt), id->block);
>>> + }
>>> + else
>>> + {
>>> + id->block = gimple_block (stmt);
>>> + }
>>
>>> /* Local declarations will be replaced by their equivalents in this
>>> map. */
Re: RFA: dead_debug_* ICE
Jakub Jelinek writes:
> Unfortunately this seems to break bootstrap on i686-linux.
> Delta-reduced testcase is:
> typedef _Complex float __attribute__ ((mode (TC))) __complex128;
> extern __complex128 clogq (__complex128) __attribute__ ((__nothrow__));
> __complex128
> cacoshq (__complex128 x)
> {
> __complex128 res;
> int rcls = __builtin_fpclassify (0, 1, 4, 3, 2, __real__ x);
> int icls = __builtin_fpclassify (0, 1, 4, 3, 2, __imag__ x);
> if (rcls <= 1 || icls <= 1)
> {
> __complex128 y;
> res = clogq (y);
> if (__real__ res < 0.0)
> res = -res;
> }
> return res;
> }
> which ICEs at -O2 -g -fPIC -m32 in the above gcc_checking_assert (uses)
> now.
Gah, sorry for the breakage. I don't have time to look at it right now,
so I've reverted the patch. I'll leave the proper fix to Alex.
Richard
Re: [Ping] Fix gcc/gcov.c and libgcc/libgcov.c to fix build on VxWorks
On 06/24/12 15:54, rbmj wrote: + c_fix_arg = "%0\n" + "#ifdef IN_GCC\n" + "#define mkdir(dir, mode) ((mode), (mkdir)(dir))\n" + "#endif\n"; + c_fix_arg = "extern[\t ]+STATUS[\t ]+mkdir[\t ]*" + "\\([\t ]*const[\t ]+char[\t ]*\\*[\t ]*" /* arg type */ + "(|[_[:alpha:]][_[:alnum:]]*)" /* arg name (optional) */ + "\\)[\t ]*;"; + + test_text = "extern STATUS mkdir (const char * _qwerty) ;"; How gross. Approved. :)
Re: [RFA/ARM] Add ACLE Predefined macro support
Further testing has found a couple of failures to build with a C++ compiler, and trunk has moved on a bit so the patch doesn't apply cleanly. An updated patch is attached. OK for trunk? Same ChangeLog as before. Thanks, Matt On 20/06/12 11:18, Matthew Gretton-Dann wrote: PING. On Mon, May 28, 2012 at 10:51:27AM +0100, Matthew Gretton-Dann wrote: All, This patch adds a variety of predefined macros to reveal the presence of various features of the ARM architecture. These are detailed in the ARM C Language Extensions specification, available here: http://infocenter.arm.com/help/topic/com.arm.doc.ihi0053-/index.html This patch then adds compiler predefines for: __ARM_SIZEOF_MINIMAL_ENUM which is defined as the size in bytes of the smallest enum. __ARM_ARCH which is defined as the major revision of the ARM instruction set which the target implements. __ARM_ARCH_ISA_THUMB which is defined as the major revision of the thumb instruction set which the target implements. __ARM_ARCH_PROFILE which is defined on ARMv7 targets, and ARMv6-M targets to be the character value of `A', `R' or `M', as defined by the target's architecture profile. __ARM_FEATURE_LDREX which is defined as a bit mask, composed of the widths of `ldrex' available on the target. These widths are: bit 0 - byte. bit 1 - 16-bit halfword. bit 2 - 32-bit word. bit 3 - 64-bit doubleword. __ARM_FEATURE_CLZ which is defined for targets which support the `clz' instruction. __ARM_FEATURE_SIMD32 which is defined when the ARMv6 integer SIMD instructions are available. __ARM_FEATURE_QBIT which is defined when the Q-Bit is present in the APSR. __ARM_FEATURE_SAT which is defined when the saturation instructions are available. __ARM_FP which is defined as a bit mask composed of the widths of floating-point types with hardware support on the target. These widths are: bit 1 - 16-bit half precision. bit 2 - 32-bit single precision. bit 3 - 64-bit double precision. __ARM_FP16_FORMAT_IEEE which is defined when the IEEE 754-2008 standard for 16-bit floating point representation is used. __ARM_FP16_FORMAT_ALTERNATIVE which is defined when the ARM alternative standard for 16-bit floating point representation is used. __ARM_FEATURE_FMA which is defined when the fused multiply-accumulate instructions are available for floating-point and/or Advanced SIMD values. __ARM_NEON_FP which is defined as a bit mask composed of the widths of floating point values supported by the NEON hardware. These widths are, as with __ARM_FP: bit 1 - 16-bit half precision. bit 2 - 32-bit single precision. bit 3 - 64-bit double precision. __ARM_WMMX which is defined where iwmmx operations are available on the target. As these macros may expand to something other than `1', we also update cpp.texi to reflect this fact. OK? Thanks, Matt gcc/ChangeLog: 2012-05-28 Matthew Gretton-Dann James Greenhalgh * config/arm/arm.h (TARGET_CPU_CPP_BUILTINS): Add new built-ins. (TARGET_FMA): New macro. (TARGET_ARM_QBIT, TARGET_ARM_SAT): Likewise. (TARGET_ARM_ARCH): Likewise. (TARGET_ARM_ARCH_ISA_THUMB): Likewise. (TARGET_V6M, TARGET_V7M): Likewise. (TARGET_ARM_ARCH_PROFILE): Likewise. (TARGET_ARM_FEATURE_LDREX): Likewise. (TARGET_ARM_FP, TARGET_NEON_FP): Likewise. (ARM_MIN_ENUM_SIZE): Likewise. * config/arm/arm.c (arm_file_start): Refactor appropriately. (base_architecture): New enumeration. (arm_base_arch): New global variable. (processors): Add field base_arch. (ARM_ARCH, ARM_CORE): Adjust accordingly. (arm_option_override): Add initialization of arm_base_arch. * doc/cpp.texi (system-specific predefined macros.): Change. gcc/testsuite/ChangeLog: 2012-05-28 Matthew Gretton-Dann James Greenhalgh * gcc.target/arm/ftest-support-arm.h New testcase. * gcc.target/arm/ftest-support-thumb.h Likewise. * gcc.target/arm/ftest-support.h Likewise. * gcc.target/arm/ftest-armv4-arm.c: Likewise. * gcc.target/arm/ftest-armv4t-arm.c: Likewise. * gcc.target/arm/ftest-armv4t-thumb.c: Likewise. * gcc.target/arm/ftest-armv5t-arm.c Likewise. * gcc.target/arm/ftest-armv5t-thumb.c Likewise. * gcc.target/arm/ftest-armv5te-arm.c: Likewise. * gcc.target/arm/ftest-armv5te-thumb.c: Likewise. * gcc.target/arm/ftest-armv6-arm.c Likewise. * gcc.target/arm/ftest-armv6-thumb.c Likewise. * gcc.target/arm/ftest-armv6k-arm.c Likewise. * gcc.target/arm/ftest-armv6k-thumb.c Likewise. * gcc.target/arm/ftest-armv6m-thumb.c: Likewise. * gcc.target/arm/ftest-armv6t2-arm.c: Likewise. * gcc.target/arm/ftest-armv6t2-thumb.c: Likewise. * gcc.target/arm/ftest-armv6z-arm.c: Likewise. * gcc.target/arm/ftest-armv6z-thumb.c: Likewise. * gcc.target/arm/ftest-armv7a-arm.c Likewise. * gcc.target/arm/ftest-armv7a-thumb.c Likewise.
[PATCH] Fix sse_loadlps constraints (PR target/53759)
Hi!
When the sse_loadlps and avx_loadlps patterns were merged together using
enabled attribute, apparently vmovlps alternative got a typo,
x <- x, x alternative is there already earlier, vmovlps should be
x <- m, 0 for noavx (that is right) and x <- m, x for avx.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk/4.7?
2012-06-25 Jakub Jelinek
PR target/53759
* config/i386/sse.md (sse_loadlps): Use x m x constraints instead
of x x x in the vmovlps load alternative.
* gcc.target/i386/pr53759.c: New test.
--- gcc/config/i386/sse.md.jj 2012-06-25 08:38:32.0 +0200
+++ gcc/config/i386/sse.md 2012-06-25 09:53:57.622335534 +0200
@@ -3943,7 +3943,7 @@ (define_expand "sse_loadlps_exp"
(define_insn "sse_loadlps"
[(set (match_operand:V4SF 0 "nonimmediate_operand" "=x,x,x,x,m")
(vec_concat:V4SF
- (match_operand:V2SF 2 "nonimmediate_operand" " 0,x,m,x,x")
+ (match_operand:V2SF 2 "nonimmediate_operand" " 0,x,m,m,x")
(vec_select:V2SF
(match_operand:V4SF 1 "nonimmediate_operand" " x,x,0,x,0")
(parallel [(const_int 2) (const_int 3)]]
--- gcc/testsuite/gcc.target/i386/pr53759.c.jj 2012-06-25 10:09:29.075376198
+0200
+++ gcc/testsuite/gcc.target/i386/pr53759.c 2012-06-25 10:09:19.0
+0200
@@ -0,0 +1,17 @@
+/* PR target/53759 */
+/* { dg-do compile } */
+/* { dg-options "-O2 -mavx" } */
+/* { dg-require-effective-target avx } */
+
+#include
+
+void
+foo (__m128 *x, __m64 *y)
+{
+ __m128 a = _mm_setzero_ps ();
+ __m128 b = _mm_loadl_pi (a, y);
+ *x = _mm_add_ps (b, b);
+}
+
+/* { dg-final { scan-assembler "vmovlps\[ \\t\]" } } */
+/* { dg-final { scan-assembler-not "vshufps\[ \\t\]" } } */
Jakub
[PATCH] Don't try to perform conditional_replacement on vectors (PR tree-optimization/53748)
Hi!
On vectors, even when they satisfy
integer_zerop/integer_onep/integer_all_onesp, the routine doesn't
handle vector types and it is questionable if it would be a good
optimization for them anyway. We don't handle complex there either,
so this patch limits it to integral/pointer types.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2012-06-25 Jakub Jelinek
PR tree-optimization/53748
* tree-ssa-phiopt.c (conditional_replacement): Only optimize
if arg0/arg1 have integral or pointer types.
* gcc.c-torture/compile/pr53748.c: New test.
--- gcc/tree-ssa-phiopt.c.jj2012-06-25 08:38:26.0 +0200
+++ gcc/tree-ssa-phiopt.c 2012-06-25 12:10:23.473357828 +0200
@@ -615,8 +615,12 @@ conditional_replacement (basic_block con
bool neg;
/* FIXME: Gimplification of complex type is too hard for now. */
- if (TREE_CODE (TREE_TYPE (arg0)) == COMPLEX_TYPE
- || TREE_CODE (TREE_TYPE (arg1)) == COMPLEX_TYPE)
+ /* We aren't prepared to handle vectors either (and it is a question
+ if it would be worthwhile anyway). */
+ if (!(INTEGRAL_TYPE_P (TREE_TYPE (arg0))
+ || POINTER_TYPE_P (TREE_TYPE (arg0)))
+ || !(INTEGRAL_TYPE_P (TREE_TYPE (arg1))
+ || POINTER_TYPE_P (TREE_TYPE (arg1
return false;
/* The PHI arguments have the constants 0 and 1, or 0 and -1, then
--- gcc/testsuite/gcc.c-torture/compile/pr53748.c.jj2012-06-25
11:54:15.959820372 +0200
+++ gcc/testsuite/gcc.c-torture/compile/pr53748.c 2012-06-25
11:43:35.0 +0200
@@ -0,0 +1,9 @@
+/* PR tree-optimization/53748 */
+
+typedef unsigned int V __attribute__ ((__vector_size__ (sizeof (int) * 4)));
+
+void
+foo (int x, V *y)
+{
+ *y = x ? ((V) { ~0U, ~0U, ~0U, ~0U }) : ((V) { 0, 0, 0, 0 });
+}
Jakub
Re: [PATCH] Fix sse_loadlps constraints (PR target/53759)
On 2012-06-25 07:42, Jakub Jelinek wrote: > PR target/53759 > * config/i386/sse.md (sse_loadlps): Use x m x constraints instead > of x x x in the vmovlps load alternative. > > * gcc.target/i386/pr53759.c: New test. Ok,. r~
Re: [C++] Reject variably modified types in operator new
On 06/25/2012 08:17 AM, Florian Weimer wrote: The message should point to the typedef, but instead, it references the line with operator new (which doesn't even contain the variable n). Yep, this is another example of how we don't track/use expression locations well enough. For the non-VLA typedef case, it is an improvement. But I would like to leave in both errors, as in the attached patch. OK. If you have suggestions how to improve cxx_constant_value error reporting, I can look into that in a separate patch. One way would be to pass around a location_t loc in the cxx_eval_* functions, starting with input_location, but then at the top of cxx_eval_constant_expression have if (EXPR_HAS_LOCATION (t)) loc = EXPR_LOCATION (t); and use error_at (loc in all error messages. And perhaps also change array_type_nelts_top to give the PLUS_EXPR (if any) the location of the array typedef (if any). Bootstrapped and tested on x86_64-unknown-linux-gnu, with no new regressions. OK for trunk? Yes. Jason
[RFA/ARM 0/3] Add support for fused multiply-accumulate to ARM backend
All, This sequence of three patches adds support to the ARM Backend for fused multiply-accumulate patterns on cores that support it. Patch 1 adds floating-point support. Patch 2 adds Advanced SIMD support in the auto-vectorizer. Patch 3 adds intrinsic support in arm_neon.h. These patches have been tested as a whole using QEmu targetting arm-none-eabi, and with an arm-linux-gnueabi bootstrap. They require the ACLE feature test macros patch currently under review here: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01592.html Thanks, Matt -- Matthew Gretton-Dann Principal Engineer, PD Software - Tools, ARM Ltd
[RFA/ARM 1/3] Add VFP support for VFMA and friends
All,
This patch adds support to the ARM backend for generating floating-point
fused multiply-accumulate.
OK?
gcc/ChangeLog:
2012-06-25 Matthew Gretton-Dann
* config/arm/iterators.md (SDF): New mode iterator.
(V_if_elem): Add support for SF and DF modes.
(V_reg): Likewise.
(F_w_constraint): New mode iterator attribute.
(F_r_constraint): Likewise.
(F_fma_type): Likewise.
(F_target): Likewise.
config/arm/vfp.md (fma4): New pattern.
(*fmsub4): Likewise.
(*fmnsub4): Likewise.
(*fmnadd4): Likewise.
Thanks,
Matt
--
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd
diff --git a/gcc/config/arm/iterators.md b/gcc/config/arm/iterators.md
index 795a5ee..3063f00 100644
--- a/gcc/config/arm/iterators.md
+++ b/gcc/config/arm/iterators.md
@@ -42,6 +42,9 @@
;; A list of the 32bit and 64bit integer modes
(define_mode_iterator SIDI [SI DI])
+;; A list of modes which the VFP unit can handle
+(define_mode_iterator SDF [SF DF])
+
;; Integer element sizes implemented by IWMMXT.
(define_mode_iterator VMMX [V2SI V4HI V8QI])
@@ -245,7 +248,8 @@
(V4HI "P") (V8HI "q")
(V2SI "P") (V4SI "q")
(V2SF "P") (V4SF "q")
- (DI "P") (V2DI "q")])
+ (DI "P") (V2DI "q")
+ (SF "") (DF"P")])
;; Wider modes with the same number of elements.
(define_mode_attr V_widen [(V8QI "V8HI") (V4HI "V4SI") (V2SI "V2DI")])
@@ -303,7 +307,8 @@
(V4HI "i16") (V8HI "i16")
(V2SI "i32") (V4SI "i32")
(DI "i64") (V2DI "i64")
- (V2SF "f32") (V4SF "f32")])
+ (V2SF "f32") (V4SF "f32")
+ (SF "f32") (DF "f64")])
;; Same, but for operations which work on signed values.
(define_mode_attr V_s_elem [(V8QI "s8") (V16QI "s8")
@@ -423,6 +428,12 @@
;; Mode attribute for vshll.
(define_mode_attr V_innermode [(V8QI "QI") (V4HI "HI") (V2SI "SI")])
+;; Mode attributes used for fused-multiply-accumulate VFP support
+(define_mode_attr F_w_constraint [(SF "=t") (DF "=w")])
+(define_mode_attr F_r_constraint [(SF "t") (DF "w")])
+(define_mode_attr F_fma_type [(SF "fmacs") (DF "fmacd")])
+(define_mode_attr F_target [(SF "") (DF "&& TARGET_VFP_DOUBLE")])
+
;;
;; Code attributes
;;
diff --git a/gcc/config/arm/vfp.md b/gcc/config/arm/vfp.md
index 2061414..2a50353 100644
--- a/gcc/config/arm/vfp.md
+++ b/gcc/config/arm/vfp.md
@@ -890,6 +890,54 @@
(set_attr "type" "fmacd")]
)
+;; Fused-multiply-accumulate
+
+(define_insn "fma4"
+ [(set (match_operand:SDF 0 "register_operand" "")
+(fma:SDF (match_operand:SDF 1 "register_operand" "")
+ (match_operand:SDF 2 "register_operand" "")
+ (match_operand:SDF 3 "register_operand" "0")))]
+ "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
+ "vfma%?.\\t%0, %1, %2"
+ [(set_attr "predicable" "yes")
+ (set_attr "type" "")]
+)
+
+(define_insn "*fmsub4"
+ [(set (match_operand:SDF 0 "register_operand" "")
+ (fma:SDF (neg:SDF (match_operand:SDF 1 "register_operand"
+ ""))
+ (match_operand:SDF 2 "register_operand" "")
+ (match_operand:SDF 3 "register_operand" "0")))]
+ "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
+ "vfms%?.\\t%0, %1, %2"
+ [(set_attr "predicable" "yes")
+ (set_attr "type" "")]
+)
+
+(define_insn "*fnmsub4"
+ [(set (match_operand:SDF 0 "register_operand" "")
+ (fma:SDF (match_operand:SDF 1 "register_operand" "")
+ (match_operand:SDF 2 "register_operand" "")
+ (neg:SDF (match_operand:SDF 3 "register_operand" "0"]
+ "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
+ "vfnms%?.\\t%0, %1, %2"
+ [(set_attr "predicable" "yes")
+ (set_attr "type" "")]
+)
+
+(define_insn "*fnmadd4"
+ [(set (match_operand:SDF 0 "register_operand" "")
+ (fma:SDF (neg:SDF (match_operand:SDF 1 "register_operand"
+ ""))
+ (match_operand:SDF 2 "register_operand" "")
+ (neg:SDF (match_operand:SDF 3 "register_operand" "0"]
+ "TARGET_32BIT && TARGET_HARD_FLOAT && TARGET_FMA "
+ "vfnma%?.\\t%0, %1, %2"
+ [(set_attr "predicable" "yes")
+ (set_attr "type" "")]
+)
+
;; Conversion routines
diff --git a/gcc/testsuite/gcc.target/arm/fma-sp.c b/gcc/testsuite/gcc.target/arm/fma-sp.c
new file mode 100644
index 000..457b55c
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/fma-sp.c
@@ -0,0 +1,13 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -mcpu=cortex-m4 -mfpu=fpv4-sp-d16 -mthumb" } */
+
+#include "fma.h"
+
+/* { dg-final { scan-assembler-not "vfma\.f64\td\[0-9\]" } } */
+/* { dg-final { scan-assembler-times "vfma\.f32\ts\[0-9\]" 1 } } */
+/* { dg-final { scan-assembler-not "vfms\.f64\td\[0-9\]" } } */
+/* { dg-final { scan-assembler-times "
[RFA/ARM 2/3] Add vectorizer support for VFMA
All,
This patch adds vectoriser support for VFMA to the ARM Neon backend.
Note that the VFP VFNMA and VFNMS instructions do not have Neon
equivalents.
OK?
gcc/ChangeLog:
2012-06-25 Matthew Gretton-Dann
* config/arm/neon.md (fma4): New pattern.
(*fmsub4): Likewise.
2012-06-25 Matthew Gretton-Dann
* gcc.target/arm/neon-vfma-1.c: New testcase.
* gcc.target/arm/neon-vfms-1.c: Likewise.
* lib/target-supports.exp (add_options_for_arm_neonv2): New
function.
(check_effective_target_arm_neonv2_ok_nocache): Likewise.
(check_effective_target_arm_neonv2_ok): Likewise.
(check_effective_target_arm_neonv2_hw): Likewise.
(check_effective_target_arm_neonv2): Likewise.
Thanks,
Matt
--
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd
diff --git a/gcc/config/arm/neon.md b/gcc/config/arm/neon.md
index 4568dea..4d12fb3 100644
--- a/gcc/config/arm/neon.md
+++ b/gcc/config/arm/neon.md
@@ -711,6 +711,33 @@
(const_string "neon_mla_qqq_32_qqd_32_scalar")]
)
+;; Fused multiply-accumulate
+(define_insn "fma4"
+ [(set (match_operand:VCVTF 0 "register_operand" "=w")
+(fma:VCVTF (match_operand:VCVTF 1 "register_operand" "w")
+ (match_operand:VCVTF 2 "register_operand" "w")
+ (match_operand:VCVTF 3 "register_operand" "0")))]
+ "TARGET_NEON && TARGET_FMA"
+ "vfma%?.\\t%0, %1, %2"
+ [(set (attr "neon_type")
+ (if_then_else (match_test "")
+ (const_string "neon_fp_vmla_ddd")
+ (const_string "neon_fp_vmla_qqq")))]
+)
+
+(define_insn "*fmsub4"
+ [(set (match_operand:VCVTF 0 "register_operand" "=w")
+(fma:VCVTF (neg:VCVTF (match_operand:VCVTF 1 "register_operand" "w"))
+ (match_operand:VCVTF 2 "register_operand" "w")
+ (match_operand:VCVTF 3 "register_operand" "0")))]
+ "TARGET_NEON && TARGET_FMA"
+ "vfms%?.\\t%0, %1, %2"
+ [(set (attr "neon_type")
+ (if_then_else (match_test "")
+ (const_string "neon_fp_vmla_ddd")
+ (const_string "neon_fp_vmla_qqq")))]
+)
+
(define_insn "ior3"
[(set (match_operand:VDQ 0 "s_register_operand" "=w,w")
(ior:VDQ (match_operand:VDQ 1 "s_register_operand" "w,0")
diff --git a/gcc/testsuite/gcc.target/arm/neon-vfma-1.c b/gcc/testsuite/gcc.target/arm/neon-vfma-1.c
new file mode 100644
index 000..a003a82
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/neon-vfma-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_neonv2_ok } */
+/* { dg-options "-O2 -ftree-vectorize -ffast-math" } */
+/* { dg-add-options arm_neonv2 } */
+/* { dg-final { scan-assembler "vfma\\.f32\[ \]+\[dDqQ]" } } */
+
+/* Verify that VFMA is used. */
+void f1(int n, float a, float x[], float y[]) {
+ int i;
+ for (i = 0; i < n; ++i)
+y[i] = a * x[i] + y[i];
+}
diff --git a/gcc/testsuite/gcc.target/arm/neon-vfms-1.c b/gcc/testsuite/gcc.target/arm/neon-vfms-1.c
new file mode 100644
index 000..8cefd8a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/arm/neon-vfms-1.c
@@ -0,0 +1,12 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target arm_neonv2_ok } */
+/* { dg-options "-O2 -ftree-vectorize -ffast-math" } */
+/* { dg-add-options arm_neonv2 } */
+/* { dg-final { scan-assembler "vfms\\.f32\[ \]+\[dDqQ]" } } */
+
+/* Verify that VFMS is used. */
+void f1(int n, float a, float x[], float y[]) {
+ int i;
+ for (i = 0; i < n; ++i)
+y[i] = a * -x[i] + y[i];
+}
diff --git a/gcc/testsuite/lib/target-supports.exp b/gcc/testsuite/lib/target-supports.exp
index bc5baa7..9fc8a5c 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2082,6 +2082,19 @@ proc add_options_for_arm_neon { flags } {
return "$flags $et_arm_neon_flags"
}
+# Add the options needed for NEON. We need either -mfloat-abi=softfp
+# or -mfloat-abi=hard, but if one is already specified by the
+# multilib, use it. Similarly, if a -mfpu option already enables
+# NEON, do not add -mfpu=neon.
+
+proc add_options_for_arm_neonv2 { flags } {
+if { ! [check_effective_target_arm_neonv2_ok] } {
+ return "$flags"
+}
+global et_arm_neonv2_flags
+return "$flags $et_arm_neonv2_flags"
+}
+
# Return 1 if this is an ARM target supporting -mfpu=neon
# -mfloat-abi=softfp or equivalent options. Some multilibs may be
# incompatible with these options. Also set et_arm_neon_flags to the
@@ -2110,6 +2123,38 @@ proc check_effective_target_arm_neon_ok { } {
check_effective_target_arm_neon_ok_nocache]
}
+# Return 1 if this is an ARM target supporting -mfpu=neon-vfpv4
+# -mfloat-abi=softfp or equivalent options. Some multilibs may be
+# incompatible with these options. Also set et_arm_neonv2_flags to the
+# best options to add.
+
+proc check_effective_target_arm_neonv2_ok_nocache { } {
+global et_arm_neonv2_flags
+set et_arm_neonv2_flags ""
+if { [check_effective_target_arm32] } {
+ foreach flags {"" "-mfloat-abi=softfp" "-mfpu=neon-vfpv4" "-mfpu=neon-v
[RFA/ARM 3/3] Add support for vfma* and vfms* Neon intrinsics
All,
This commit adds support for the vmfa* and vfms* Neon intrinsics.
This updates neon.ml, and the various generation tools which use it,
arm_neon.h, the testsuite and documentation.
The documentation has not been regenerated for a while and so the
changes are larger than expected.
OK?
gcc/ChangeLog:
2012-06-25 Matthew Gretton-Dann
* config/arm/arm.c (neon_builtin_data): Add vfma and vfms
builtins.
* config/arm/neon-docgen.ml (intrinsic_groups): Add
fused-multiply-* groups.
* config/neon-gen.ml (print_feature_test_start): New function.
(print_feature_test_end): Likewise.
(print_variant): Print feature test macros.
* config/arm/neon-testgen.ml (emit_prologue): Allow different
tests to require different effective targets.
(effective_target): New function.
(test_intrinsic): Specify correct effective targets.
* gcc/config/arm/neon.md (*fmsub4): Rename...
(fmsub4): ...to this.
(neon_vfma): New expand.
(neon_vfms): Likewise.
* config/neon.ml (opcode): Add Vfma and Vfms.
(features): Add Requires_feature.
(ops): Add VFMA and VFMS intrinsics.
* config/arm/arm_neon.h: Regenerate.
* doc/arm-neon-intrinsics.texi: Likewise.
gcc/testsuite/ChangeLog:
2012-06-25 Matthew Gretton-Dann
* gcc.target/arm/neon/vfmaQf32.c: New testcase.
* gcc.target/arm/neon/vfmaf32.c: Likewise.
* gcc.target/arm/neon/vfmsQf32.c: Likewise.
* gcc.target/arm/neon/vfmsf32.c: Likewise.
Thanks,
Matt
--
Matthew Gretton-Dann
Principal Engineer, PD Software - Tools, ARM Ltd
diff --git a/gcc/config/arm/arm.c b/gcc/config/arm/arm.c
index cba98f9..0b8b41e 100644
--- a/gcc/config/arm/arm.c
+++ b/gcc/config/arm/arm.c
@@ -18919,6 +18919,8 @@ static neon_builtin_datum neon_builtin_data[] =
VAR8 (BINOP, vmul, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
VAR8 (TERNOP, vmla, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
VAR3 (TERNOP, vmlal, v8qi, v4hi, v2si),
+ VAR2 (TERNOP, vfma, v2sf, v4sf),
+ VAR2 (TERNOP, vfms, v2sf, v4sf),
VAR8 (TERNOP, vmls, v8qi, v4hi, v2si, v2sf, v16qi, v8hi, v4si, v4sf),
VAR3 (TERNOP, vmlsl, v8qi, v4hi, v2si),
VAR4 (BINOP, vqdmulh, v4hi, v2si, v8hi, v4si),
diff --git a/gcc/config/arm/arm_neon.h b/gcc/config/arm/arm_neon.h
index 0567895..3afe3b0 100644
--- a/gcc/config/arm/arm_neon.h
+++ b/gcc/config/arm/arm_neon.h
@@ -1350,6 +1350,38 @@ vqdmlsl_s32 (int64x2_t __a, int32x2_t __b, int32x2_t __c)
return (int64x2_t)__builtin_neon_vqdmlslv2si (__a, __b, __c, 1);
}
+#ifdef __ARM_FEATURE_FMA
+__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
+vfma_f32 (float32x2_t __a, float32x2_t __b, float32x2_t __c)
+{
+ return (float32x2_t)__builtin_neon_vfmav2sf (__a, __b, __c, 3);
+}
+
+#endif
+#ifdef __ARM_FEATURE_FMA
+__extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
+vfmaq_f32 (float32x4_t __a, float32x4_t __b, float32x4_t __c)
+{
+ return (float32x4_t)__builtin_neon_vfmav4sf (__a, __b, __c, 3);
+}
+
+#endif
+#ifdef __ARM_FEATURE_FMA
+__extension__ static __inline float32x2_t __attribute__ ((__always_inline__))
+vfms_f32 (float32x2_t __a, float32x2_t __b, float32x2_t __c)
+{
+ return (float32x2_t)__builtin_neon_vfmsv2sf (__a, __b, __c, 3);
+}
+
+#endif
+#ifdef __ARM_FEATURE_FMA
+__extension__ static __inline float32x4_t __attribute__ ((__always_inline__))
+vfmsq_f32 (float32x4_t __a, float32x4_t __b, float32x4_t __c)
+{
+ return (float32x4_t)__builtin_neon_vfmsv4sf (__a, __b, __c, 3);
+}
+
+#endif
__extension__ static __inline int8x8_t __attribute__ ((__always_inline__))
vsub_s8 (int8x8_t __a, int8x8_t __b)
{
diff --git a/gcc/config/arm/neon-docgen.ml b/gcc/config/arm/neon-docgen.ml
index 23e37b4..043b1e0 100644
--- a/gcc/config/arm/neon-docgen.ml
+++ b/gcc/config/arm/neon-docgen.ml
@@ -103,6 +103,8 @@ let intrinsic_groups =
"Multiplication", single_opcode Vmul;
"Multiply-accumulate", single_opcode Vmla;
"Multiply-subtract", single_opcode Vmls;
+"Fused-multiply-accumulate", single_opcode Vfma;
+"Fused-multiply-subtract", single_opcode Vfms;
"Subtraction", single_opcode Vsub;
"Comparison (equal-to)", single_opcode Vceq;
"Comparison (greater-than-or-equal-to)", single_opcode Vcge;
diff --git a/gcc/config/arm/neon-gen.ml b/gcc/config/arm/neon-gen.ml
index 112c8be..0297597 100644
--- a/gcc/config/arm/neon-gen.ml
+++ b/gcc/config/arm/neon-gen.ml
@@ -239,6 +239,24 @@ let rec mode_suffix elttype shape =
and srcmode = mode_of_elt src shape in
string_of_mode dstmode ^ string_of_mode srcmode
+let print_feature_test_start features =
+ try
+match List.find (fun feature ->
+ match feature with Requires_feature _ -> true
+| _ -> false)
+ features with
+ Requires_feature feature ->
+Format.printf "#ifdef __ARM_FEA
Re: RFC: C++/OMP PATCH for c++/53565 (libgomp for-2.C failure)
On 06/25/2012 06:39 AM, Jakub Jelinek wrote: On Thu, Jun 21, 2012 at 12:34:32AM -0700, Jason Merrill wrote: All the tests in the libgomp and gcc testsuites pass with this patch, but I'm not very confident about it because I don't fully understand what the code is doing. In particular, I'm not sure what the condition controlling the code in tsubst_omp_for_iterator that looks at the clauses should be; init can never be a DECL_EXPR at that point anymore. Don't remember exactly, but I'd guess I wanted to preserve as much as possible what the code was doing before for the non-class types. After RECUR init can't be DECL_EXPR, right? So if you do it unconditionally it doesn't need to be handled. Right, I just wasn't sure what the point of the test was. Is it that if we're declaring the iteration variable in the for-init-statement, we don't need to worry about making it OMP private? I'm also not sure whether moving the begin_omp_structured_block is necessary, but it seemed like a good idea since we're handling the DECL_EXPR earlier. Looking at the code now, I wonder whether begin_omp_structured_block shouldn't be moved later, not earlier, because the decl ctors should happen before the body of the worksharing region. Should they? It seems that each of the private copies of the decl gets initialized separately, which I would expect to be part of the worksharing region. Jason
Re: RFC: C++/OMP PATCH for c++/53565 (libgomp for-2.C failure)
On Mon, Jun 25, 2012 at 11:04:42AM -0400, Jason Merrill wrote:
> Right, I just wasn't sure what the point of the test was. Is it
> that if we're declaring the iteration variable in the
> for-init-statement, we don't need to worry about making it OMP
> private?
It should be made private always. Even for
int
foo (void)
{
int j;
j = 6;
#pragma omp for private(j)
for (int i = 0; i < 6; i++)
j = i;
return j;
}
we declare it before #pragma omp for and make it private(i).
> >Looking at the code now, I wonder whether begin_omp_structured_block
> >shouldn't be moved later, not earlier, because the decl ctors should happen
> >before the body of the worksharing region.
>
> Should they? It seems that each of the private copies of the decl
> gets initialized separately, which I would expect to be part of the
> worksharing region.
Well, this is a worksharing region, so is already entered by all the
threads, thus the initialization is performed by all threads anyway, the
thing is just where the remapping of the var into the private var happens
(and that should be performed by the gimplifier).
Anyway, please go ahead with your patch.
Jakub
Re: [PATCH][configure] Make sure CFLAGS_FOR_TARGET And CXXFLAGS_FOR_TARGET contain -O2
Ping? This patch was tested successfully on cross GCC x86 -> arm-none-eabi, to make sure that target libs are built with "-O2 -g" as stated in a comment in configure. It fixes what looks like a cut & paste error. Without this patch, overriding CFLAGS not including -O2 leads to CFLAGS_FOR_TARGET lacking -O2, which results in target libs such as libstdc++ being compiled without -O2. OK? Christophe. On 16.04.2012 14:51, Christophe Lyon wrote: Ping? On 29.03.2012 13:48, Christophe Lyon wrote: Hello, According to a comment in configure/configure.ac: # We want to ensure that TARGET libraries (which we know are built with # gcc) are built with "-O2 -g", so include those options when setting # CFLAGS_FOR_TARGET and CXXFLAGS_FOR_TARGET. but the current code does not ensure this. I propose the patch below to fix this. 2012-03-29 Christophe Lyon * configure.ac (CFLAGS_FOR_TARGET, CXXFLAGS_FOR_TARGET): Make sure they contain -O2. * configure: Regenerate. Index: configure.ac === --- configure.ac(revision 2515) +++ configure.ac(working copy) @@ -2223,7 +2223,7 @@ if test "x$CFLAGS_FOR_TARGET" = x; then esac case " $CFLAGS " in *" -g "* | *" -g3 "*) ;; -*) CFLAGS_FOR_TARGET="-g $CFLAGS" ;; +*) CFLAGS_FOR_TARGET="-g $CFLAGS_FOR_TARGET" ;; esac fi AC_SUBST(CFLAGS_FOR_TARGET) @@ -2236,7 +2236,7 @@ if test "x$CXXFLAGS_FOR_TARGET" = x; the esac case " $CXXFLAGS " in *" -g "* | *" -g3 "*) ;; -*) CXXFLAGS_FOR_TARGET="-g $CXXFLAGS" ;; +*) CXXFLAGS_FOR_TARGET="-g $CXXFLAGS_FOR_TARGET" ;; esac fi AC_SUBST(CXXFLAGS_FOR_TARGET) Index: configure === --- configure(revision 2515) +++ configure(working copy) @@ -6739,7 +6739,7 @@ if test "x$CFLAGS_FOR_TARGET" = x; then esac case " $CFLAGS " in *" -g "* | *" -g3 "*) ;; -*) CFLAGS_FOR_TARGET="-g $CFLAGS" ;; +*) CFLAGS_FOR_TARGET="-g $CFLAGS_FOR_TARGET" ;; esac fi @@ -6752,7 +6751,7 @@ if test "x$CXXFLAGS_FOR_TARGET" = x; the esac case " $CXXFLAGS " in *" -g "* | *" -g3 "*) ;; -*) CXXFLAGS_FOR_TARGET="-g $CXXFLAGS" ;; +*) CXXFLAGS_FOR_TARGET="-g $CXXFLAGS_FOR_TARGET" ;; esac fi . .
Re: [PATCH][configure] Make sure CFLAGS_FOR_TARGET And CXXFLAGS_FOR_TARGET contain -O2
On Mon, 25 Jun 2012, Christophe Lyon wrote: > Ping? I advise CCing appropriate maintainers (in this case, build system maintainers) on pings. -- Joseph S. Myers jos...@codesourcery.com
C++ PATCH for c++/53202 (copy constructor not run in C++11)
The code that collects base initializers in a constructor declared
constexpr was checking potential_constant_expression and then discarding
an initializer for an empty base if true. But
potential_constant_expression only looks at whether a function is
declared constexpr, not whether the call actually turns out to be
constant; to determine that we need to keep the call around until we
actually try to expand it.
Tested x86_64-pc-linux-gnu, applied to 4.7 and trunk.
commit 2e6c5d723ff7407704f2cbd343383991b498fb5b
Author: jason
Date: Mon Jun 25 15:17:59 2012 +
PR c++/53202
* semantics.c (build_data_member_initialization): Always keep
initializer for empty base.
(cxx_eval_bare_aggregate): Discard it here.
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index ee41861..2d64a66 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5838,12 +5838,9 @@ build_data_member_initialization (tree t, VEC(constructor_elt,gc) **vec)
member = op;
else
{
- /* We don't put out anything for an empty base. */
+ /* This is an initializer for an empty base; keep it for now so
+ we can check it in cxx_eval_bare_aggregate. */
gcc_assert (is_empty_class (TREE_TYPE (TREE_TYPE (member;
- /* But if the initializer isn't constexpr, leave it in so we
- complain later. */
- if (potential_constant_expression (init))
- return true;
}
}
if (TREE_CODE (member) == ADDR_EXPR)
@@ -7064,6 +7061,12 @@ cxx_eval_bare_aggregate (const constexpr_call *call, tree t,
constructor_elt *inner = base_field_constructor_elt (n, ce->index);
inner->value = elt;
}
+ else if (TREE_CODE (ce->index) == NOP_EXPR)
+ {
+ /* This is an initializer for an empty base; now that we've
+ checked that it's constant, we can ignore it. */
+ gcc_assert (is_empty_class (TREE_TYPE (TREE_TYPE (ce->index;
+ }
else
CONSTRUCTOR_APPEND_ELT (n, ce->index, elt);
}
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-tuple.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-tuple.C
new file mode 100644
index 000..f59cd84
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-tuple.C
@@ -0,0 +1,106 @@
+// PR c++/53202
+// { dg-do run { target c++11 } }
+
+#include
+
+template
+ struct Bind_simple
+ {
+explicit
+Bind_simple(const Callable& callable)
+: _M_bound(callable)
+{ }
+
+Bind_simple(const Bind_simple&) = default;
+Bind_simple(Bind_simple&&) = default;
+
+auto operator()() -> decltype((*(Callable*)0)())
+{
+ return std::get<0>(_M_bound)();
+}
+
+ private:
+
+std::tuple _M_bound;
+ };
+
+template
+ Bind_simple
+ bind_simple(Callable& callable)
+ {
+return Bind_simple(callable);
+ }
+
+struct thread
+{
+ struct ImplBase { };
+
+ template
+struct Impl : ImplBase {
+ T t;
+ Impl(T&& t) : t(std::move(t)) { }
+};
+
+ template
+thread(T& t)
+{
+ auto p = make_routine(bind_simple(t));
+
+ p->t();
+
+ delete p;
+}
+
+ template
+Impl*
+make_routine(Callable&& f)
+{
+ return new Impl(std::forward(f));
+}
+};
+
+
+int c;
+class background_hello
+{
+public:
+background_hello()
+{
+ __builtin_printf("default ctor called, this=%p\n", this);
+ ++c;
+}
+
+background_hello(const background_hello &)
+{
+ __builtin_printf("copy ctor called\n");
+ ++c;
+}
+
+background_hello(background_hello &&)
+{
+ __builtin_printf("move ctor called\n");
+ ++c;
+}
+
+void operator ()() const
+{
+ __builtin_printf("void background_hello::operator()() called, this=%p\n", this);
+}
+
+~background_hello()
+{
+ __builtin_printf("destructor called, this=%p\n", this);
+ --c;
+}
+
+};
+
+int main()
+{
+ {
+background_hello bh;
+thread t(bh);
+ }
+ if (c != 0)
+__builtin_abort ();
+}
Fix PR tree-optimization/53729 (Re: [PATCH] Fix PR tree-optimization/53636)
Richard Guenther wrote:
> In this testcase the alignment of arr[i] should be irrelevant - it is
> not part of
> the stmts that are going to be vectorized. But of course this may be
> simply an odering issue in how we analyze data-references / statements
> in basic-block vectorization (thus we possibly did not yet declare the
> arr[i] = i statement as not taking part in the vectorization).
The following patch changes tree-vect-data-refs.c:vect_verify_datarefs_alignment
to only take into account statements marked as "relevant".
This should have no impact for loop-based vectorization, since the only caller
(vect_enhance_data_refs_alignment) already skips irrelevant statements.
[ As an aside, that routine should probably use STMT_VINFO_RELEVANT_P instead
of just checking STMT_VINFO_RELEVANT as a boolean. ]
However, for SLP this change in itself doesn't work, since vect_slp_analyze_bb_1
calls vect_verify_datarefs_alignment *before* statements have actually been
marked as relevant or irrelevant. Therefore, the patch also rearranges the
sequence in vect_slp_analyze_bb_1.
This in turn caused ICEs in vect_get_store_cost/vect_get_load_cost, since those
now can get called with statements with unsupported alignment. There is already
one caller (vect_get_data_access_cost) that checks for this case and simply
returns "infinite" cost instead of aborting. The patch moves this behaviour
into vect_get_store_cost/vect_get_load_cost themselves. (The particular cost
shouldn't matter since vectorization will still be rejected in the end, it's
just that the test now runs a bit later.)
Overall, I've tested the patch with no regresions on powerpc64-linux and
arm-linux-gnueabi. On PowerPC, it fixed the gcc.dg/vect/bb-slp-16.c test.
Mikael, would you mind verifying that it fixes the problem on sparc64?
OK for mainline?
Bye,
Ulrich
ChangeLog:
PR tree-optimization/53729
PR tree-optimization/53636
* tree-vect-slp.c (vect_slp_analyze_bb_1): Delay call to
vect_verify_datarefs_alignment until after statements have
been marked as relevant/irrelevant.
* tree-vect-data-refs.c (vect_verify_datarefs_alignment):
Skip irrelevant statements.
(vect_enhance_data_refs_alignment): Use STMT_VINFO_RELEVANT_P
instead of STMT_VINFO_RELEVANT.
(vect_get_data_access_cost): Do not check for supportable
alignment before calling vect_get_load_cost/vect_get_store_cost.
* tree-vect-stmts.c (vect_get_store_cost): Do not abort when
handling unsupported alignment.
(vect_get_load_cost): Likewise.
Index: gcc/tree-vect-data-refs.c
===
*** gcc/tree-vect-data-refs.c (revision 188850)
--- gcc/tree-vect-data-refs.c (working copy)
*** vect_verify_datarefs_alignment (loop_vec
*** 1094,1099
--- 1094,1102
gimple stmt = DR_STMT (dr);
stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
+ if (!STMT_VINFO_RELEVANT_P (stmt_info))
+ continue;
+
/* For interleaving, only the alignment of the first access matters.
Skip statements marked as not vectorizable. */
if ((STMT_VINFO_GROUPED_ACCESS (stmt_info)
*** vect_get_data_access_cost (struct data_r
*** 1213,1229
loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
int vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
int ncopies = vf / nunits;
- bool supportable_dr_alignment = vect_supportable_dr_alignment (dr, true);
! if (!supportable_dr_alignment)
! *inside_cost = VECT_MAX_COST;
else
! {
! if (DR_IS_READ (dr))
! vect_get_load_cost (dr, ncopies, true, inside_cost, outside_cost);
! else
! vect_get_store_cost (dr, ncopies, inside_cost);
! }
if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, "vect_get_data_access_cost: inside_cost = %d, "
--- 1216,1226
loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
int vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
int ncopies = vf / nunits;
! if (DR_IS_READ (dr))
! vect_get_load_cost (dr, ncopies, true, inside_cost, outside_cost);
else
! vect_get_store_cost (dr, ncopies, inside_cost);
if (vect_print_dump_info (REPORT_COST))
fprintf (vect_dump, "vect_get_data_access_cost: inside_cost = %d, "
*** vect_enhance_data_refs_alignment (loop_v
*** 1537,1543
stmt = DR_STMT (dr);
stmt_info = vinfo_for_stmt (stmt);
! if (!STMT_VINFO_RELEVANT (stmt_info))
continue;
/* For interleaving, only the alignment of the first access
--- 1534,1540
stmt = DR_STMT (dr);
stmt_info = vinfo_for_stmt (stmt);
! if (!STMT_VINFO_RELEVANT_P (stmt_info))
continue;
/* For interleaving, only the alignment of the first access
Index: gcc/tree-vect-stmts.c
Re: Add noexcept and constexpr to tr2/dynamic_bitset.
On 06/24/2012 07:18 AM, Jonathan Wakely wrote:
On 24 June 2012 12:18, Jonathan Wakely wrote:
On 24 June 2012 05:00, Ed Smith-Rowland wrote:
Subject says it.
This looks good, please CC gcc-patches with a changelog entry and
confirmation it was tested and it can go in. Thanks.
And don't forget to update the copyright year.
Built and tested on x86_64-linux-gnu.
2012-06-25 Edward Smith-Rowland <3dw...@verizon.net>
* include/tr2/dynamic_bitset (count, size, num_blocks, empty, max_size):
Add noexcept.
Index: include/tr2/dynamic_bitset
===
--- include/tr2/dynamic_bitset (revision 188848)
+++ include/tr2/dynamic_bitset (working copy)
@@ -1,6 +1,6 @@
// TR2 -*- C++ -*-
-// Copyright (C) 2009, 2010, 2011 Free Software Foundation, Inc.
+// Copyright (C) 2009, 2010, 2011, 2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -146,19 +146,19 @@
{ return this->_M_w.get_allocator(); }
static size_type
- _S_whichword(size_type __pos)
+ _S_whichword(size_type __pos) noexcept
{ return __pos / _S_bits_per_block; }
static size_type
- _S_whichbyte(size_type __pos)
+ _S_whichbyte(size_type __pos) noexcept
{ return (__pos % _S_bits_per_block) / __CHAR_BIT__; }
static size_type
- _S_whichbit(size_type __pos)
+ _S_whichbit(size_type __pos) noexcept
{ return __pos % _S_bits_per_block; }
static block_type
- _S_maskbit(size_type __pos)
+ _S_maskbit(size_type __pos) noexcept
{ return (static_cast(1)) << _S_whichbit(__pos); }
block_type&
@@ -333,7 +333,7 @@
}
size_type
- _M_size() const
+ _M_size() const noexcept
{ return this->_M_w.size(); }
unsigned long
@@ -1141,28 +1141,29 @@
/// Returns the number of bits which are set.
size_type
- count() const
+ count() const noexcept
{ return this->_M_do_count(); }
/// Returns the total number of bits.
size_type
- size() const
+ size() const noexcept
{ return this->_M_Nb; }
/// Returns the total number of blocks.
- size_type num_blocks() const
+ size_type
+ num_blocks() const noexcept
{ return this->_M_size(); }
/// Returns true if the dynamic_bitset is empty.
bool
- empty() const
+ empty() const noexcept
{ return (this->_M_Nb == 0); }
/// Returns the maximum size of a dynamic_bitset object having the same
/// type as *this.
/// The real answer is max() * bits_per_block but is likely to overflow.
- /*constexpr*/ size_type
- max_size() const
+ constexpr size_type
+ max_size() noexcept
{ return std::numeric_limits::max(); }
/**
Re: constexpr for tr2/bool_set.
On 06/24/2012 07:19 AM, Jonathan Wakely wrote:
This looks good too, again please CC gcc-patches with a changelog
entry and confirmation it was tested and it can go in. Thanks.
Built and tested on x86_64-linux-gnu.
2012-06-25 Edward Smith-Rowland <3dw...@verizon.net>
* include/tr2/bool_set (count, size, num_blocks, empty, max_size):
Add noexcept.
Index: include/tr2/bool_set
===
--- include/tr2/bool_set(revision 188848)
+++ include/tr2/bool_set(working copy)
@@ -1,6 +1,6 @@
// TR2 -*- C++ -*-
-// Copyright (C) 2009, 2011 Free Software Foundation, Inc.
+// Copyright (C) 2009, 2011, 2012 Free Software Foundation, Inc.
//
// This file is part of the GNU ISO C++ Library. This library is free
// software; you can redistribute it and/or modify it under the
@@ -56,10 +56,10 @@
public:
/// Default constructor.
-bool_set() : _M_b(_S_false) { }
+constexpr bool_set() : _M_b(_S_false) { }
/// Constructor from bool.
-bool_set(bool __t) : _M_b(_Bool_set_val(__t)) { }
+constexpr bool_set(bool __t) : _M_b(_Bool_set_val(__t)) { }
// I'm not sure about this.
bool contains(bool_set __b) const
Re: [RFA/ARM] Add ACLE Predefined macro support
On 25/06/12 15:39, Matthew Gretton-Dann wrote: > Further testing has found a couple of failures to build with a C++ compiler, > and trunk has moved on a bit so the patch doesn't apply cleanly. > > An updated patch is attached. > > OK for trunk? > > Same ChangeLog as before. > OK. R.
Re: [patch] support for multiarch systems
On 25.06.2012 15:56, Joseph S. Myers wrote:
> On Mon, 25 Jun 2012, Matthias Klose wrote:
>
>> Please find attached the patch updated for trunk 20120625, x86 only, tested
>> on
>> x86-linux-gnu, KFreeBSD and the Hurd.
>
> This patch appears to include changes to config.gcc for other targets, not
> mentioned in your ChangeLog entries. Please resubmit without those
> changes, and submit them separately with their own rationale if needed.
my mistake, removed these bits now again.
2012-06-25 Matthias Klose
* doc/invoke.texi: Document -print-multiarch.
* doc/install.texi: Document --enable-multiarch.
* doc/fragments.texi: Document MULTILIB_OSDIRNAMES, MULTIARCH_DIRNAME.
* configure.ac: Add --enable-multiarch option.
* configure.in: Regenerate.
* Makefile.in (s-mlib): Pass MULTIARCH_DIRNAME to genmultilib.
enable_multiarch, with_float: New macros.
if_multiarch: New macro, define in terms of enable_multiarch.
* genmultilib: Add new argument for the multiarch name.
* gcc.c (multiarch_dir): Define.
(for_each_path): Search for multiarch suffixes.
(driver_handle_option): Handle multiarch option.
(do_spec_1): Pass -imultiarch if defined.
(main): Print multiarch.
(set_multilib_dir): Separate multilib and multiarch names
from multilib_select.
(print_multilib_info): Ignore multiarch names in multilib_select.
* incpath.c (add_standard_paths): Search the multiarch include dirs.
* cppdeault.h (default_include): Document multiarch in multilib
member.
* cppdefault.c: [LOCAL_INCLUDE_DIR, STANDARD_INCLUDE_DIR] Add an
include directory for multiarch directories.
* common.opt: New options --print-multiarch and -imultilib.
* config.gcc: Add tmake fragments to tmake_file ( i386/t-kfreebsd
for i[34567]86-*-kfreebsd*-gnu and x86_64-*-kfreebsd*-gnu, i386/t-gnu
for i[34567]86-*-gnu*).
* config/i386/t-kfreebsd: Add multiarch names in
MULTILIB_OSDIRNAMES, define MULTIARCH_DIRNAME.
* config/i386/t-linux64: Likewise.
* config/i386/t-linux: Define MULTIARCH_DIRNAME.
* config/i386/t-gnu: Likewise.
Index: configure.ac
===
--- configure.ac(revision 188931)
+++ configure.ac(working copy)
@@ -623,6 +623,21 @@
[], [enable_multilib=yes])
AC_SUBST(enable_multilib)
+# Determine whether or not multiarch is enabled.
+AC_ARG_ENABLE(multiarch,
+[AS_HELP_STRING([--enable-multiarch],
+ [enable support for multiarch paths])],
+[case "${withval}" in
+yes|no|auto-detect) enable_multiarch=$withval;;
+*) AC_MSG_ERROR(bad value ${withval} given for --enable-multiarch option) ;;
+esac], [enable_multiarch=auto-detect])
+AC_MSG_CHECKING(for multiarch configuration)
+AC_SUBST(enable_multiarch)
+AC_MSG_RESULT($enable_multiarch)
+
+# needed for setting the multiarch name on ARM
+AC_SUBST(with_float)
+
# Enable __cxa_atexit for C++.
AC_ARG_ENABLE(__cxa_atexit,
[AS_HELP_STRING([--enable-__cxa_atexit], [enable __cxa_atexit for C++])],
Index: cppdefault.c
===
--- cppdefault.c(revision 188931)
+++ cppdefault.c(working copy)
@@ -63,6 +63,7 @@
#endif
#ifdef LOCAL_INCLUDE_DIR
/* /usr/local/include comes before the fixincluded header files. */
+{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 2 },
{ LOCAL_INCLUDE_DIR, 0, 0, 1, 1, 0 },
#endif
#ifdef PREFIX_INCLUDE_DIR
@@ -90,6 +91,7 @@
#endif
#ifdef NATIVE_SYSTEM_HEADER_DIR
/* /usr/include comes dead last. */
+{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 2 },
{ NATIVE_SYSTEM_HEADER_DIR, NATIVE_SYSTEM_HEADER_COMPONENT, 0, 0, 1, 0 },
#endif
{ 0, 0, 0, 0, 0, 0 }
Index: cppdefault.h
===
--- cppdefault.h(revision 188931)
+++ cppdefault.h(working copy)
@@ -43,9 +43,11 @@
C++. */
const char add_sysroot; /* FNAME should be prefixed by
cpp_SYSROOT. */
- const char multilib; /* FNAME should have the multilib path
- specified with -imultilib
- appended. */
+ const char multilib; /* FNAME should have appended
+ - the multilib path specified with -imultilib
+when 1 is passed,
+ - the multiarch path specified with
+-imultiarch, when 2 is passed. */
};
extern const struct default_include cpp_include_defaults[];
Index: Makefile.in
===
--- Makefile.in (revision 188931)
++
Re: [patch] [gcc/libgcc/ada/libstdc++] Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI
On 25.06.2012 15:22, Richard Earnshaw wrote: > On 25/06/12 13:08, Matthias Klose wrote: >> gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of >> arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in >> various >> other places as well. arm-linux-gnueabihf is used as a triplet by some >> distributions. >> >> Ok for the trunk? >> > > now that all arm-linux ports are EABI conforming, why can't this just become > > arm*-*-linux* > ? I assume it could. But I didn't check for other places where this would be needed.
Re: New option to turn off stack reuse for temporaries
Are there any more concerns about this patch? If not, I'd like to check it in. thanks, David On Fri, Jun 22, 2012 at 8:51 AM, Xinliang David Li wrote: > On Fri, Jun 22, 2012 at 2:39 AM, Richard Guenther > wrote: >> On Fri, Jun 22, 2012 at 11:29 AM, Jason Merrill wrote: >>> On 06/22/2012 01:30 AM, Richard Guenther wrote: > > What other issues? It enables more potential code motion, but on the > other hand, causes more conservative stack reuse. As far I can tell, > the handling of temporaries is added independently after the clobber > for scoped variables are introduced. This option can be used to > restore the older behavior (in handling temps). Well, it does not really restore the old behavior (if you mean before adding CLOBBERS, not before the single patch that might have used those for gimplifying WITH_CLEANUP_EXPR). You say it disables stack-slot sharing for those decls but it also does other things via side-effects of no longer emitting the CLOBBER. I say it's better to disable the stack-slot sharing. >>> >>> >>> The patch exactly restores the behavior of temporaries from before my change >>> to add CLOBBERs for temporaries. The primary effect of that change was to >>> provide stack-slot sharing, but if there are other effects they are probably >>> desirable as well, since the broken code depended on the old behavior. >> >> So you see it as workaround option, like -fno-strict-aliasing, rather than >> debugging aid? > > It can be used for both purposes -- if the violations are as pervasive > as strict-aliasing cases (which looks like so). > > thanks, > > David > >> >> Richard. >> >>> Jason
Re: libgo patch committed: Fix testsuite on PPC
Andreas Schwab writes:
> Ian Lance Taylor writes:
>
>> @@ -326,13 +336,18 @@
>> }
>>
>> {
>> +text="T"
>> +case "$GOARCH" in
>> +ppc*) text="D" ;;
>
> This is wrong for ppc.
>
> Andreas.
>
> diff --git a/libgo/testsuite/gotest b/libgo/testsuite/gotest
> index da1162e..208cbaf 100755
> --- a/libgo/testsuite/gotest
> +++ b/libgo/testsuite/gotest
> @@ -355,7 +355,7 @@ localname() {
> {
> text="T"
> case "$GOARCH" in
> - ppc*) text="D" ;;
> + ppc64) text="D" ;;
> esac
>
> symtogo='sed -e s/_test/XXXtest/ -e s/.*_\([^_]*\.\)/\1/ -e
> s/XXXtest/_test/'
Thanks. Committed to mainline and 4.7 branch.
Ian
Re: [wwwdocs] Update coding conventions for C++
[ Added doc maintainers in CC ]
While I'm not particularly interested in the details of the coding
conventions, I am interested in getting them in getting them installed
before we merge cxx-conversion to trunk.
Joseph, Gerald, do we have a process for accepting changes to coding
conventions?
It has been a week since the conventions were posted and I have seen
no comments on the patch.
Thanks. Diego.
On Mon, Jun 18, 2012 at 6:28 PM, Lawrence Crowl wrote:
> This patch updates the coding conventions to C++. The primary
> source file is codingconventions.html. The coding conventions now
> refer to a new file, codingrationale.html, providing the rationale
> for some of the C++ conventions. The two files in question are
> attached whole for your convenience.
>
> The "Portability" section has some changes. The "Miscellaneous
> Conventions" section moves later and become part of the "C and C++
> Language Conventions" section. The bulk of the change consists of
> additions to the "C and C++ Language Conventions" section and the
> addition of an entirely new "C++ Language Conventions" section.
> I added a table of contents.
>
> I have removed lines from the around the html tag, as they are
> causing my mail to be rejected. If you get this message twice, you
> now know why. :-)
>
> Please review.
>
>
> Index: codingconventions.html
> ===
> RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
> retrieving revision 1.66
> diff -u -u -r1.66 codingconventions.html
> --- codingconventions.html 19 Feb 2012 00:45:34 - 1.66
> +++ codingconventions.html 18 Jun 2012 22:04:49 -
> @@ -1,4 +1,8 @@
>
>
> GCC Coding Conventions
> @@ -15,8 +19,56 @@
> code to follow these conventions, it is best to send changes to follow
> the conventions separately from any other changes to the code.
>
> +
> +Documentation
> +ChangeLogs
> +Portability
> +Makefiles
> +Testsuite Conventions
> +Diagnostics Conventions
> +Spelling, terminology and markup
> +C and C++ Language Conventions
> +Compiler Options
> +Language Use
> + href="#Assertions">Assertions
> + href="#Character">Character Testing
> + href="#Error">Error Node Testing
> + href="#Generated">Parameters Affecting Generated Code
> + href="#C_Inlining">Inlining Functions
> +Formatting
> Conventions
> +Line
> Length
> + href="#C_Names">Names
> + href="#Expressions">Expressions
> + href="#Calls">Function Calls
> +C++ Language Conventions
> +Language Use
> + href="#Variable">Variable Definitions
> + href="#Struct_Use">Struct Definitions
> + href="#Class_Use">Class Definitions
> + href="#Constructors">Constructors and Destructors
> + href="#Conversions">Conversions
> + href="#Over_Func">Overloading Functions
> + href="#Over_Oper">Overloading Operators
> + href="#Default">Default Arguments
> + href="#Cxx_Inlining">Inlining Functions
> + href="#Template_Use">Templates
> + href="#Namespace_Use">Namespaces
> +RTTI
> and dynamic_cast
> + href="#Casts">Other Casts
> + href="#Exceptions">Exceptions
> + href="#Standard_Library">The Standard Library
> +Formatting
> Conventions
> + href="#Cxx_Names">Names
> + href="#Struct_Form">Struct Definitions
> + href="#Class_Form">Class Definitions
> + href="#Member_Form">Class Member Definitions
> + href="#Template_Form">Templates
> + href="#ExternC">Extern "C"
> + href="#Namespace_Form">Namespaces
> +
>
> -Documentation
> +
> +Documentation
>
> Documentation, both of user interfaces and of internals, must be
> maintained and kept up to date. In particular:
> @@ -43,7 +95,7 @@
>
>
>
> -ChangeLogs
> +ChangeLogs
>
> GCC requires ChangeLog entries for documentation changes; for the web
> pages (apart from java/ and libstdc++/) the CVS
> @@ -71,20 +123,61 @@
> java/58 is the actual number of the PR) at the top
> of the ChangeLog entry.
>
> -Portability
> +Portability
>
> There are strict requirements for portability of code in GCC to
> -older systems whose compilers do not implement all of the ISO C standard.
> -GCC requires at least an ANSI C89 or ISO C90 host compiler, and code
> -should avoid pre-standard style function definitions, unnecessary
> -function prototypes and use of the now deprecated @code{PARAMS} macro.
> +older systems whose compilers do not implement all of the
> +latest ISO C and C++ standards.
> +
> +
> +
> +The directories
> +gcc, libcpp and fixincludes
> +may use C++03.
> +They may also use the long long type
> +if the host C++ compiler supports it.
> +Furthermore,
> +these directories should also be compatible with C++11.
> +
> +
> +
> +The directories libiberty and libdecnumber must use C
> +and require at least an ANSI C89 or ISO C90 host compiler.
> +C code sho
Re: Fix partitioning of aliases
On Mon, Apr 9, 2012 at 12:18 PM, Jan Hubicka wrote: > Hi, > this patch fixes several different ICEs related to handling aliases in WHOPR > partitioning. It took me over week debug this, but when variable alias > is added to a boundary and its destination is not added, we get queue of > unforutnate events where the destinatoin gets analyzed and added at ltrans > time > resulting in interesting miscompilation seen at Mozilla with some vtables. > The problem is that constructor won't get streamed when the declaration is > not in varpool at partitioning time and thus once the variable is re-added > it has zero constructor. > Of course the problem manifests itself in various weird ways depending > on ordering of linker command maing it very difficult to reduce anything. > > While working on this I also noticed that PR 52634 is about related problem > where aliases are incorectly partitioned into multiple partitions. > The patch also fixes the varpool ICEs mentioned in the other two PRs. > I failed to produce testcase version of PR52722 testcase, since it does not > link now either, but it won't ICE. > > I will commit the patch and wait for some time, but I would like to backport > it to 4.7, since it solves quite nasty misoptimization problem. > At mainline after this patch i would like to follow with series of cleanups > and API changes I have in queue for symtab work. > > Honza > > PR lto/52722 > PR lto/51765 > PR lto/52634 > * lto-cgraph.c (compute_ltrans_boundary): When alias is in the > boundary, > add its target too. > * lto.c (add_references_to_partition): Add also aliased nodes. > (add_cgraph_node_to_partition, > add_varpool_node_to_partition): Work on nodes, not functions/variables; > when adding alias, add also the aliased object. > * gcc.dg/lto/pr52634_1.c: New testcase. > * gcc.dg/lto/pr52634_0.c: New testcase. Hi Jan, Can you backport it to 4.7? It also fixes: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53768 Thanks. -- H.J.
Re: [Patch, mips] Fix warning when using --with-synci
On Fri, 2012-06-22 at 10:24 +0100, Richard Sandiford wrote:
> If you use a different target name, the specs for that target can
> enforce whatever triplet-specific defaults you want. See the
> DRIVER_SELF_SPECS in vr.h for a particularly involved example.
> (Yours shouldn't need to be as bad!)
I think that using DRIVER_SELF_SPECS would still require me to figure
out exactly what architectures support -msynci and which don't in order
to pass the right thing. What I liked about -msynci-if-supported is
that it means there is only one check to determine if synci is
supported, the one in mips.h, and so I don't have to worry about two
different tests not being consistent.
> How are you expecting to use this configuration? Is the sysroot
> that backs it going to have C libraries for all combinations?
> I assume so, since otherwise you wouldn't be able to build
> more than libgcc.
Yes, I would build a C library for each combination.
> If so, we need to define what the OS library directories
> are for -EB vs -EL, -mhard-float vs. -msoft-float, etc.
> Are you planning to extend the IRIX lib/lib32/lib64 system,
> or use the Debian/Ubuntu multiarch?
>
> Richard
I was looking at lib/lib32/lib64. Here is the full t-mti file I was
trying to build with the latest sources:
MULTILIB_OPTIONS = EL/EB msoft-float mips32
MULTILIB_DIRNAMES = el eb soft-float mips32
MULTILIB_MATCHES := EL=mel EB=meb
EXTRA_MULTILIB_PARTS = crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o
and I also have a mti.h header file with:
#define MULTILIB_DEFAULTS { "EB" }
#define SYSROOT_SUFFIX_SPEC \
"%{mel|EL:/el}%{msoft-float:/soft-float}%{mips32:/mips32}"
Steve Ellcey
sell...@mips.com
Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP
Let me try again then... RL78 is confusing and it took a while to get it to work right. Please don't change it ;-)
C++ PATCH for c++/52988 (omitted calls with nullptr)
We were assuming that any expression of nullptr_t was equivalent to
nullptr, but that isn't valid if the expression has side-effects...
Tested x86_64-pc-linux-gnu, applying to 4.6, 4.7, trunk.
commit c716e8680864db1312338691de7d2618efec1c3f
Author: Jason Merrill
Date: Mon Jun 25 13:06:15 2012 -0400
PR c++/52988
* typeck.c (decay_conversion): Don't discard side-effects from
expressions of nullptr_t.
diff --git a/gcc/cp/typeck.c b/gcc/cp/typeck.c
index 945266b..971f386 100644
--- a/gcc/cp/typeck.c
+++ b/gcc/cp/typeck.c
@@ -1843,7 +1843,7 @@ decay_conversion (tree exp, tsubst_flags_t complain)
if (error_operand_p (exp))
return error_mark_node;
- if (NULLPTR_TYPE_P (type))
+ if (NULLPTR_TYPE_P (type) && !TREE_SIDE_EFFECTS (exp))
return nullptr_node;
/* build_c_cast puts on a NOP_EXPR to make the result not an lvalue.
diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr28.C b/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
new file mode 100644
index 000..05fbe57
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/nullptr28.C
@@ -0,0 +1,16 @@
+// { dg-do run { target c++11 } }
+
+typedef decltype(nullptr) nullptr_t;
+
+int i;
+nullptr_t n;
+const nullptr_t& f() { ++i; return n; }
+
+nullptr_t g() { return f(); }
+
+int main()
+{
+ g();
+ if (i != 1)
+__builtin_abort ();
+}
Re: [gimplefe] creating individual gimple_assign statements
On 12-06-23 14:42 , Sandeep Soni wrote: 2012-06-25 Sandeep Soni * parser.c (gimple_symtab_get): New. (gl_symtab_get_token): New. Gets the tree for the token. (gp_parse_expect_lhs): Tidy. Returns the tree node for lhs. (gp_parse_expect_rhs_op): Tidy. Returns the tree operand in rhs. (gp_parse_assign_stmt): Tidy. Creates the gimple assignment statement. OK. Thanks. Diego.
Re: ping x3 : latch mem to reg before multi-access in convert_move
On 2012-06-23 23:56, Olivier Hainque wrote: > Hello, > > ping # 3 for http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00298.html > > This is related to convert-move possibly emitting a sequence > with multiple accesses to one input, triggering multiple memory > accesses when that input happens to be a mem. Can you explain the sequence that results in multiple memory references? Because I can't see how it can... r~
Re: [Patch, mips] Fix warning when using --with-synci
Steve Ellcey writes:
> On Fri, 2012-06-22 at 10:24 +0100, Richard Sandiford wrote:
>
>> If you use a different target name, the specs for that target can
>> enforce whatever triplet-specific defaults you want. See the
>> DRIVER_SELF_SPECS in vr.h for a particularly involved example.
>> (Yours shouldn't need to be as bad!)
>
> I think that using DRIVER_SELF_SPECS would still require me to figure
> out exactly what architectures support -msynci and which don't in order
> to pass the right thing.
Not if you use MIPS_ISA_LEVEL_SPEC. I think you'd want that anyway,
in order to pick the right multilib. E.g. MIPS_ISA_LEVEL_SPEC is
the thing that would make -march=4kc pick the mips32 rather than
mips32r2 multilibs.
Since you have soft-float multilibs, you'd probably also want
MIPS_ARCH_FLOAT_SPEC.
Or to put it another way, MIPS_ISA_LEVEL_SPEC and MIPS_ARCH_FLOAT_SPEC
make the multilib options explicit on the command line. You can then
use that information to add whatever options you want to be the default
for a given multilib.
> What I liked about -msynci-if-supported is that it means there is only
> one check to determine if synci is supported, the one in mips.h, and
> so I don't have to worry about two different tests not being
> consistent.
It opens up a can of worms though. I think these --with-* options
should be consistent. If we say that --with-synci should be overridden
by anything that is incompatible with it, then the same should apply
to --with-abi, --with-arch, etc. (And the same should be true for
things like --with-mode on ARM.)
E.g. if you pass -mgp64 to a compiler that was configured with --with-arch,
then presumably we should ignore that --with-arch if it specifies a 32-bit
architecture, but continue to honour it if it specifies a 64-bit
architecture. (I realise we have --with-arch-32 and --with-arch-64, but
the principle holds regardless.) So say you have a target that is usually
mips64 by default, but that has 32-bit multilibs. If you configure with
--with-arch=mips32r2 --with-synci, then pass -mgp64, what should happen?
I assume we'd revert back to the default of mips64 and then (after your
change) silently drop the -msynci too. And that feels like too much
guesswork on our part. Maybe the user really wanted mips64r2.
That's just one example. The same thing would apply to --with-abi.
The relationships between these options are so complicated that
I think the user interface should be as simple as possible.
And IMO, that means that if the user explicitly configures with
--with-synci, then they should use -mno-synci if they want to
reverse that decision.
Packagers who want to provide both -msynci and -mno-synci multilibs
(with mips32 being one possible form of the latter) should IMO define
an appropriate configuration that doesn't rely on --with-synci.
>> If so, we need to define what the OS library directories
>> are for -EB vs -EL, -mhard-float vs. -msoft-float, etc.
>> Are you planning to extend the IRIX lib/lib32/lib64 system,
>> or use the Debian/Ubuntu multiarch?
>>
>> Richard
>
> I was looking at lib/lib32/lib64. Here is the full t-mti file I was
> trying to build with the latest sources:
>
> MULTILIB_OPTIONS = EL/EB msoft-float mips32
> MULTILIB_DIRNAMES = el eb soft-float mips32
> MULTILIB_MATCHES := EL=mel EB=meb
> EXTRA_MULTILIB_PARTS = crtbegin.o crtend.o crtbeginS.o crtendS.o crtbeginT.o
>
> and I also have a mti.h header file with:
>
> #define MULTILIB_DEFAULTS { "EB" }
> #define SYSROOT_SUFFIX_SPEC \
> "%{mel|EL:/el}%{msoft-float:/soft-float}%{mips32:/mips32}"
Ah, OK, I get it now. Thanks.
Richard
Re: [wwwdocs] Update coding conventions for C++
On Mon, 25 Jun 2012, Diego Novillo wrote: > [ Added doc maintainers in CC ] > > While I'm not particularly interested in the details of the coding > conventions, I am interested in getting them in getting them installed > before we merge cxx-conversion to trunk. > > Joseph, Gerald, do we have a process for accepting changes to coding > conventions? I suggest sending smaller (so easier to review) patches that are concrete and avoid speculation about possible future changes. > > +Compiler Options I don't like this repeated presentational markup; use appropriate logical markup instead. > > + > > +We will periodically pick a stable version of GCC, > > +and require that that version of GCC be able to build > > +all versions of GCC up to and including the next stable version. > > +E.g., we may decide that all newer versions of GCC > > +should be buildable with GCC 4.3.5. The current version required is more important than speculation about future changes. E.g., say that code must build with GCC 4.1 and later. > > +Assertions > > + > > +Code should use gcc_assert(EXPR) to check invariants. > > +Use gcc_unreachable() to mark places that should never be > > +reachable (such as an unreachable default case of a > > +switch). Do not use gcc_assert(0) for such purposes, as > > +gcc_unreachable gives the compiler more information. The > > +assertions are enabled unless explicitly configured off with > > +--enable-checking=none. Do not use abort. > > +User input should never be validated by either gcc_assert > > +or gcc_unreachable. If the checks are expensive or the > > +compiler can reasonably carry on after the error, they may be > > +conditioned on --enable-checking. I don't think any of this is new - perhaps you could separate rearrangement from the actual changes and C++ conventions? > > +Function Calls > > + > > + > > +All current GCC code uses a space between the function name > > +and the left parenthesis in a function call. > > +Essentially all C++ code omits that space, > > +which is more consistent with C++ syntax. > > +For the present we will retain the space. > > +It is possible that in the future we will switch the code with a flag day. > > + Avoid speculation. Avoid duplicating the GNU Coding Standards. Formatting can be assumed to follow the GNU Coding Standards except where they are meaningless for C++ or something explicitly overrides them. > > + > > +Think carefully about the size and performance impact > > +of virtual functions and virtual bases > > +before using them. > > + Explain in more detail what the size and performance impact is for people not familiar with the details of how C++ features are implemented. > > + > > +Indent protection labels by one space. > > + > > + > > + > > +Indent class members by two spaces. Do all the listed indentation rules correspond to what a will do by default when editing C++ code in GNU Emacs? If not, we have conflicting notions of GNU C++ indentation conventions. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.
On 06/21/2012 02:27 AM, Mike Stump wrote:
On Jun 20, 2012, at 12:36 PM, rbmj wrote:
My issue is that I'm uncomfortable with this, as it seems *too* easy.
I'd just be comfortable with a stake in the ground and press forward. I do
think this covers most all the cases.
With that in mind, then, here's a new patch over my original patch (i.e.
both are necessary). Let me know if this is what is needed or if I'm
still mistaken.
I also do not know how to run the test suite for the target system
(powerpc-wrs-vxworks). I would think some sort of powerpc simulator,
but I don't have a firmware image for VxWorks - just headers and
embedded hardware.
Modified:
*gcc/config.gcc: Set use_gcc_stdint to 'wrap' for
vxworks targets.
*fixincludes/inclhack.def (AAB_vxworks_stdint): add
#defines to make GCC aware of VxWorks stdint types
*fixincludes/fixincl.x: Regenerate
Robert Mason
>From 534222784011172403801a1617d67dba174c8441 Mon Sep 17 00:00:00 2001
From: rbmj
Date: Wed, 13 Jun 2012 11:24:01 -0400
Subject: [PATCH] Make GCC aware of VxWorks stdint types.
Modified:
*gcc/config.gcc: Set use_gcc_stdint to 'wrap' for
vxworks targets.
*fixincludes/inclhack.def (AAB_vxworks_stdint): add
#defines to make GCC aware of VxWorks stdint types
*fixincludes/fixincl.x: Regenerate
---
fixincludes/inclhack.def | 32
gcc/config.gcc |1 +
2 files changed, 33 insertions(+), 0 deletions(-)
diff --git a/fixincludes/inclhack.def b/fixincludes/inclhack.def
index 063158c..d122b6d 100644
--- a/fixincludes/inclhack.def
+++ b/fixincludes/inclhack.def
@@ -434,6 +434,38 @@ fix = {
typedef unsigned int uint_fast16_t;
typedef uint32_t uint_fast32_t;
typedef uint64_t uint_fast64_t;
+
+ #define SIG_ATOMIC_TYPE "int"
+
+ #define INT8_TYPE "signed char"
+ #define INT16_TYPE "signed short"
+ #define INT32_TYPE "signed int"
+ #define INT64_TYPE "signed long long"
+ #define UINT8_TYPE "unsigned char"
+ #define UINT16_TYPE "unsigned short"
+ #define UINT32_TYPE "unsigned int"
+ #define UINT64_TYPE "unsigned long long"
+
+ #define INT_LEAST8_TYPE "signed char"
+ #define INT_LEAST16_TYPE "signed short"
+ #define INT_LEAST32_TYPE "signed int"
+ #define INT_LEAST64_TYPE "signed long long"
+ #define UINT_LEAST8_TYPE "unsigned char"
+ #define UINT_LEAST16_TYPE "unsigned short"
+ #define UINT_LEAST32_TYPE "unsigned int"
+ #define UINT_LEAST64_TYPE "unsigned long long"
+
+ #define INT_FAST8_TYPE "signed char"
+ #define INT_FAST16_TYPE "signed int"
+ #define INT_FAST32_TYPE "signed int"
+ #define INT_FAST64_TYPE "signed long long"
+ #define UINT_FAST8_TYPE "unsigned char"
+ #define UINT_FAST16_TYPE "unsigned int"
+ #define UINT_FAST32_TYPE "unsigned int"
+ #define UINT_FAST64_TYPE "unsigned long long"
+
+ #define INTPTR_TYPE "long"
+ #define UINTPTR_TYPE "unsigned long"
#endif
_EndOfHeader_;
};
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 7ec184c..11369d3 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -771,6 +771,7 @@ case ${target} in
fi
;;
*-*-vxworks*)
+ use_gcc_stdint=wrap
tmake_file=t-vxworks
xm_defines=POSIX
extra_options="${extra_options} vxworks.opt"
--
1.7.5.4
Re: [PATCH, ARM] New CPU support for Marvell PJ4 cores
On 20 June 2012 03:53, Yi-Hsiu Hsu wrote: > marvell-pj4 is added to BE8_LINK_SPEC. > > Modified patch is attached. Missing a modified changelog entry. Ramana > > Thanks! > > B.R. > Yi-Hsiu, Hsu > > -Original Message- > From: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org] > Sent: Thursday, June 14, 2012 2:19 AM > To: Yi-Hsiu Hsu > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH, ARM] New CPU support for Marvell PJ4 cores > > On 29 May 2012 10:07, Yi-Hsiu Hsu wrote: >> Hi, >> >> This patch maintains Marvell PJ4 cores pipeline description. >> Run arm testsuite on arm-linux-gnueabi and no extra regressions are found. >> >> * config/arm/marvell-pj4.md: New marvell-pj4 pipeline description. >> * config/arm/arm.c (arm_issue_rate): Add marvell_pj4. >> * config/arm/arm-cores.def: Add core marvell-pj4. >> * config/arm/arm-tune.md: Regenerated. >> * config/arm/arm-tables.opt: Regenerated. >> * doc/invoke.texi: Added entry for marvell-pj4. > > This command line option should also be added to BE8_LINK_SPEC similar > to what's done for the other v7-a cores. > > Ok with that change. > > regards, > Ramana > > > >> >> >> Thanks! >> >> P.S. I create the patch from revision 187308, but this revision is unable to >> build successfully, then I apply this patch to revision 187623 and >> successfully build and pass the testsuite. >>
Re: [Patch-v2] Adjustments for Windows x64 SEH
2012/6/25 Richard Guenther : > On Mon, 25 Jun 2012, Tristan Gingold wrote: > >> >> On Jun 22, 2012, at 5:04 PM, Richard Henderson wrote: >> >> > On 06/21/2012 12:48 AM, Tristan Gingold wrote: >> >> 2012-06-18 Tristan Gingold >> >> >> >> * config/i386/winnt.c (i386_pe_seh_end_prologue): Move code to ... >> >> (seh_cfa_adjust_cfa): ... that function. >> >> (seh_emit_stackalloc): Do not emit out of range values. >> >> * config/i386/i386.md: Delete unused UNSPEC_REG_SAVE, >> >> UNSPEC_DEF_CFA constants. >> >> * config/i386/i386.h (SEH_MAX_FRAME_SIZE): Define. >> >> * config/i386/i386.c (ix86_frame_pointer_required): Required >> >> for very large frames on SEH target. >> >> (ix86_compute_frame_layout): Save area is before frame pointer >> >> on SEH target. Handle very large frames. >> >> (ix86_expand_prologue): Likewise. >> > >> > Ok. >> >> I propose to backport it to the gcc 4.7 branch, as it fixes two issues: >> incorrect unwind info emitted and support of setjmp. >> Is it Ok ? > > Target maintainers call - but please give it some more time on trunk to > allow regressions to be reported. > > Richard. Please give current version this week for testing. If no regressions about it are found a backport to 4.7 branch is ok for me. Thanks, Kai
Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.
On Jun 25, 2012, at 12:09 PM, rbmj wrote: > I also do not know how to run the test suite for the target system > (powerpc-wrs-vxworks). I would think some sort of powerpc simulator, but I > don't have a firmware image for VxWorks - just headers and embedded hardware. To test well, you need to be able to compile and run code. So, the question is, can you do that, or not? If you can, then you have what you need to test. If you cannot do that, then you cannot test well. If you can compile, then you can test the compile time tests, but you'll miss out on all runtime tests.
Re: [PATCH] ARM/NEON: vld1q_dup_s64 builtin
On 22 June 2012 18:58, Ramana Radhakrishnan wrote: > On 20 June 2012 14:37, Christophe Lyon wrote: >> On 06.06.2012 11:00, Ramana Radhakrishnan wrote: >>> >>> Ok with those changes. Ramana . >> >> >> Hi Ramana, >> >> How about this version? >> >> Christophe. >> > > OK - > > This should also go into the release branches as it fixes wrong code > with an intrinsic . I have now applied this to trunk for Christophe. Ramana > > Thanks, > Ramana
Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.
On 06/25/2012 04:02 PM, Mike Stump wrote: On Jun 25, 2012, at 12:09 PM, rbmj wrote: I also do not know how to run the test suite for the target system (powerpc-wrs-vxworks). I would think some sort of powerpc simulator, but I don't have a firmware image for VxWorks - just headers and embedded hardware. To test well, you need to be able to compile and run code. So, the question is, can you do that, or not? If you can, then you have what you need to test. If you cannot do that, then you cannot test well. If you can compile, then you can test the compile time tests, but you'll miss out on all runtime tests. Well, I know that I need to be able to compile and run code. I would guess (/hope) that the testsuite is automated though, but I can't use that if I need to use my own custom buildscripts in order to generate executables (can I?). Furthermore, I looked in those files (gcc/testsuite/gcc.dg/c99-stdint* - are these correct?) and I can't find any entry point. If it helps, I can compile/run code. I know that the original fixincludes patches I had compiled and ran code as well - I built my project and successfully ran it. The problem is I don't exactly know the method. Also, my classes have finished so I no longer have access to a target :-/ Robert Mason
Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP
> RL78 is confusing and it took a while to get it to work right. Please > don't change it ;-) But we can certainly remove stuff that doesn't do anything; in particular, these 3 lines /*#define DONT_USE_BUILTIN_SETJMP 1*/ #undef DONT_USE_BUILTIN_SETJMP #define JMP_BUF_SIZE (8*3+8) can be proved to be equivalent to the empty set. -- Eric Botcazou
[PATCH 0/4] Cleanup x86 vector multiplication
The end result is a bunch more macro-ized patterns in the md file,
and some missing patterns filled in. The widen_mult_even/odd hooks
elide the need for specific sdot_prod patterns while allowing the
same improved code sequence for other reductions.
I expect to be able to use the widen_mult_even/odd hooks elsewhere
as well, but that patch sequence is not yet complete.
Tested on x86-64-linux, {-msse2,-msse4}. Spot checked for -mavx2 and -mxop.
Committed.
r~
Richard Henderson (4):
i386: Cleanup and unify widening multiply patterns
i386: Use vpmacsdd for mulv4si3
i386: Add widen_multiply_even/odd builtins and hooks
i386: Delete sse sdot_prod; add sdot_prodv4si for xop
gcc/ChangeLog | 54 ++
gcc/config/i386/i386-builtin-types.def |5 +-
gcc/config/i386/i386-protos.h |4 +-
gcc/config/i386/i386.c | 308 +++-
gcc/config/i386/i386.md|1 +
gcc/config/i386/predicates.md |7 -
gcc/config/i386/sse.md | 282 +
7 files changed, 368 insertions(+), 293 deletions(-)
--
1.7.10.2
[PATCH 2/4] i386: Use vpmacsdd for mulv4si3
---
gcc/ChangeLog |4
gcc/config/i386/sse.md |6 ++
2 files changed, 10 insertions(+)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 12b8de8..b95eab5 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,9 @@
2012-06-25 Richard Henderson
+ * config/i386.sse.md (mul3): Use xop_pmacsdd.
+
+2012-06-25 Richard Henderson
+
* config/i386/i386.c (ix86_rtx_costs) [MULT]: Only apply XOP cost
to V16QImode.
(ix86_expand_vec_interleave): New.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 4c12581..93cd9d7 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -5564,6 +5564,12 @@
operands[2] = force_const_mem (mode, operands[2]);
ix86_fixup_binary_operands_no_copy (MULT, mode, operands);
}
+ else if (TARGET_XOP)
+{
+ rtx z = force_reg (mode, CONST0_RTX (mode));
+ emit_insn (gen_xop_pmacsdd (operands[0], operands[1], operands[2], z));
+ DONE;
+}
else
{
ix86_expand_sse2_mulv4si3 (operands[0], operands[1], operands[2]);
--
1.7.10.2
[PATCH 4/4] i386: Delete sse sdot_prod; add sdot_prodv4si for xop
Now that we support mult_even/odd hooks, the vectorizer can
generate the exact same code for plain sse dot_prod by itself,
as well as other reductions other than plus.
---
gcc/ChangeLog |6 +
gcc/config/i386/sse.md | 62 +++-
2 files changed, 14 insertions(+), 54 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index f63f523..4dc93af 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,11 @@
2012-06-25 Richard Henderson
+ * config/i386/sse.md (sse2_sse4_1): Remove code attr.
+ (dot_prodv4si, dot_prodv8si): Remove
+ (sdot_prodv4si): New; handle only XOP.
+
+2012-06-25 Richard Henderson
+
* config/i386/i386-builtin-types.def (V4UDI, V8USI): New.
(V2UDI_FUNC_V4USI_V4USI): New.
(V4UDI_FUNC_V8USI_V8USI): New.
diff --git a/gcc/config/i386/sse.md b/gcc/config/i386/sse.md
index 45d3a9c..4b51415 100644
--- a/gcc/config/i386/sse.md
+++ b/gcc/config/i386/sse.md
@@ -5737,64 +5737,18 @@
DONE;
})
-(define_code_attr sse2_sse4_1
- [(zero_extend "sse2") (sign_extend "sse4_1")])
-
-(define_expand "dot_prodv4si"
+;; Normally we use widen_mul_even/odd, but combine can't quite get it all
+;; back together when madd is available.
+(define_expand "sdot_prodv4si"
[(match_operand:V2DI 0 "register_operand")
- (any_extend:V2DI (match_operand:V4SI 1 "register_operand"))
+ (match_operand:V4SI 1 "register_operand")
(match_operand:V4SI 2 "register_operand")
(match_operand:V2DI 3 "register_operand")]
- " == ZERO_EXTEND ? TARGET_SSE2 : TARGET_SSE4_1"
-{
- rtx t1, t2, t3, t4;
-
- t1 = gen_reg_rtx (V2DImode);
- emit_insn (gen__mulv2siv2di3 (t1, operands[1], operands[2]));
- emit_insn (gen_addv2di3 (t1, t1, operands[3]));
-
- t2 = gen_reg_rtx (V4SImode);
- t3 = gen_reg_rtx (V4SImode);
- emit_insn (gen_sse2_lshrv1ti3 (gen_lowpart (V1TImode, t2),
-gen_lowpart (V1TImode, operands[1]),
-GEN_INT (32)));
- emit_insn (gen_sse2_lshrv1ti3 (gen_lowpart (V1TImode, t3),
-gen_lowpart (V1TImode, operands[2]),
-GEN_INT (32)));
-
- t4 = gen_reg_rtx (V2DImode);
- emit_insn (gen__mulv2siv2di3 (t4, t2, t3));
-
- emit_insn (gen_addv2di3 (operands[0], t1, t4));
- DONE;
-})
-
-(define_expand "dot_prodv8si"
- [(match_operand:V4DI 0 "register_operand")
- (any_extend:V4DI (match_operand:V8SI 1 "register_operand"))
- (match_operand:V8SI 2 "register_operand")
- (match_operand:V4DI 3 "register_operand")]
- "TARGET_AVX2"
+ "TARGET_XOP"
{
- rtx t1, t2, t3, t4;
-
- t1 = gen_reg_rtx (V4DImode);
- emit_insn (gen_avx2_mulv4siv4di3 (t1, operands[1], operands[2]));
- emit_insn (gen_addv4di3 (t1, t1, operands[3]));
-
- t2 = gen_reg_rtx (V8SImode);
- t3 = gen_reg_rtx (V8SImode);
- emit_insn (gen_avx2_lshrv2ti3 (gen_lowpart (V2TImode, t2),
-gen_lowpart (V2TImode, operands[1]),
-GEN_INT (32)));
- emit_insn (gen_avx2_lshrv2ti3 (gen_lowpart (V2TImode, t3),
-gen_lowpart (V2TImode, operands[2]),
-GEN_INT (32)));
-
- t4 = gen_reg_rtx (V4DImode);
- emit_insn (gen_avx2_mulv4siv4di3 (t4, t2, t3));
-
- emit_insn (gen_addv4di3 (operands[0], t1, t4));
+ rtx t = gen_reg_rtx (V2DImode);
+ emit_insn (gen_xop_pmacsdqh (t, operands[1], operands[2], operands[3]));
+ emit_insn (gen_xop_pmacsdql (operands[0], operands[1], operands[2], t));
DONE;
})
--
1.7.10.2
[PATCH 3/4] i386: Add widen_multiply_even/odd builtins and hooks
---
gcc/ChangeLog | 19 ++
gcc/config/i386/i386-builtin-types.def |5 +-
gcc/config/i386/i386.c | 103 +++-
gcc/config/i386/sse.md | 14 +
4 files changed, 137 insertions(+), 4 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index b95eab5..f63f523 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,24 @@
2012-06-25 Richard Henderson
+ * config/i386/i386-builtin-types.def (V4UDI, V8USI): New.
+ (V2UDI_FUNC_V4USI_V4USI): New.
+ (V4UDI_FUNC_V8USI_V8USI): New.
+ * config/i386/i386.c (ix86_expand_args_builtin): Handle them.
+ (IX86_BUILTIN_VEC_WIDEN_SMUL_ODD_V4SI): New.
+ (IX86_BUILTIN_VEC_WIDEN_SMUL_ODD_V8SI): New.
+ (IX86_BUILTIN_VEC_WIDEN_UMUL_ODD_V4SI): New.
+ (IX86_BUILTIN_VEC_WIDEN_UMUL_ODD_V8SI): New.
+ (IX86_BUILTIN_VEC_WIDEN_UMUL_EVEN_V4SI): New.
+ (IX86_BUILTIN_VEC_WIDEN_UMUL_EVEN_V8SI): New.
+ (bdesc_args): Add them.
+ (ix86_builtin_mul_widen_even, ix86_builtin_mul_widen_odd): New.
+ (TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_EVEN): New.
+ (TARGET_VECTORIZE_BUILTIN_MUL_WIDEN_ODD): New.
+ (ix86_expand_mul_widen_evenodd): Use xop_pmacsdqh.
+ * config/i386/sse.md (vec_widen_mult_odd_): New.
+
+2012-06-25 Richard Henderson
+
* config/i386.sse.md (mul3): Use xop_pmacsdd.
2012-06-25 Richard Henderson
diff --git a/gcc/config/i386/i386-builtin-types.def
b/gcc/config/i386/i386-builtin-types.def
index 401668a..398bf0a 100644
--- a/gcc/config/i386/i386-builtin-types.def
+++ b/gcc/config/i386/i386-builtin-types.def
@@ -97,7 +97,8 @@ DEF_VECTOR_TYPE (V4DI, DI)
DEF_VECTOR_TYPE (V8SI, SI)
DEF_VECTOR_TYPE (V16HI, HI)
DEF_VECTOR_TYPE (V32QI, QI)
-
+DEF_VECTOR_TYPE (V4UDI, UDI, V4DI)
+DEF_VECTOR_TYPE (V8USI, USI, V8SI)
DEF_POINTER_TYPE (PCCHAR, CHAR, CONST)
DEF_POINTER_TYPE (PCDOUBLE, DOUBLE, CONST)
@@ -283,6 +284,7 @@ DEF_FUNCTION_TYPE (V2DI, V2DI, SI)
DEF_FUNCTION_TYPE (V2DI, V2DI, V16QI)
DEF_FUNCTION_TYPE (V2DI, V2DI, V2DI)
DEF_FUNCTION_TYPE (V2DI, V4SI, V4SI)
+DEF_FUNCTION_TYPE (V2UDI, V4USI, V4USI)
DEF_FUNCTION_TYPE (V2DI, PCV2DI, V2DI)
DEF_FUNCTION_TYPE (V2SF, V2SF, V2SF)
DEF_FUNCTION_TYPE (V2SI, INT, INT)
@@ -349,6 +351,7 @@ DEF_FUNCTION_TYPE (V8SI, V8SI, SI)
DEF_FUNCTION_TYPE (V8SI, PCV8SI, V8SI)
DEF_FUNCTION_TYPE (V4DI, V4DI, V4DI)
DEF_FUNCTION_TYPE (V4DI, V8SI, V8SI)
+DEF_FUNCTION_TYPE (V4UDI, V8USI, V8USI)
DEF_FUNCTION_TYPE (V4DI, V4DI, V2DI)
DEF_FUNCTION_TYPE (V4DI, PCV4DI, V4DI)
DEF_FUNCTION_TYPE (V4DI, V4DI, INT)
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index a1b7628..c825033 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -25754,6 +25754,13 @@ enum ix86_builtins
IX86_BUILTIN_CPYSGNPS256,
IX86_BUILTIN_CPYSGNPD256,
+ IX86_BUILTIN_VEC_WIDEN_SMUL_ODD_V4SI,
+ IX86_BUILTIN_VEC_WIDEN_SMUL_ODD_V8SI,
+ IX86_BUILTIN_VEC_WIDEN_UMUL_ODD_V4SI,
+ IX86_BUILTIN_VEC_WIDEN_UMUL_ODD_V8SI,
+ IX86_BUILTIN_VEC_WIDEN_UMUL_EVEN_V4SI,
+ IX86_BUILTIN_VEC_WIDEN_UMUL_EVEN_V8SI,
+
/* FMA4 instructions. */
IX86_BUILTIN_VFMADDSS,
IX86_BUILTIN_VFMADDSD,
@@ -26612,6 +26619,8 @@ static const struct builtin_description bdesc_args[] =
{ OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_umulv1siv1di3,
"__builtin_ia32_pmuludq", IX86_BUILTIN_PMULUDQ, UNKNOWN, (int)
V1DI_FTYPE_V2SI_V2SI },
{ OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_umulv2siv2di3,
"__builtin_ia32_pmuludq128", IX86_BUILTIN_PMULUDQ128, UNKNOWN, (int)
V2DI_FTYPE_V4SI_V4SI },
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_umulv2siv2di3,
"__builtin_vw_umul_even_v4si", IX86_BUILTIN_VEC_WIDEN_UMUL_EVEN_V4SI, UNKNOWN,
(int) V2UDI_FTYPE_V4USI_V4USI },
+ { OPTION_MASK_ISA_SSE2, CODE_FOR_vec_widen_umult_odd_v4si,
"__builtin_ia32_vw_umul_odd_v4si", IX86_BUILTIN_VEC_WIDEN_UMUL_ODD_V4SI,
UNKNOWN, (int) V2UDI_FTYPE_V4USI_V4USI },
{ OPTION_MASK_ISA_SSE2, CODE_FOR_sse2_pmaddwd, "__builtin_ia32_pmaddwd128",
IX86_BUILTIN_PMADDWD128, UNKNOWN, (int) V4SI_FTYPE_V8HI_V8HI },
@@ -26738,6 +26747,7 @@ static const struct builtin_description bdesc_args[] =
{ OPTION_MASK_ISA_SSE4_1, CODE_FOR_uminv4si3, "__builtin_ia32_pminud128",
IX86_BUILTIN_PMINUD128, UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI },
{ OPTION_MASK_ISA_SSE4_1, CODE_FOR_uminv8hi3, "__builtin_ia32_pminuw128",
IX86_BUILTIN_PMINUW128, UNKNOWN, (int) V8HI_FTYPE_V8HI_V8HI },
{ OPTION_MASK_ISA_SSE4_1, CODE_FOR_sse4_1_mulv2siv2di3,
"__builtin_ia32_pmuldq128", IX86_BUILTIN_PMULDQ128, UNKNOWN, (int)
V2DI_FTYPE_V4SI_V4SI },
+ { OPTION_MASK_ISA_SSE4_1, CODE_FOR_vec_widen_smult_odd_v4si,
"__builtin_ia32_vw_smul_odd_v4si", IX86_BUILTIN_VEC_WIDEN_SMUL_ODD_V4SI,
UNKNOWN, (int) V2DI_FTYPE_V4SI_V4SI },
{ OPTION_MASK_ISA_SSE4_1, CODE_FOR_mulv4si3, "__builtin_ia32_pmulld128",
IX86_BUILTIN_PMULLD128, UNKNOWN, (int) V4SI_FTYPE_V4SI_V4SI },
/* SSE4.1 */
@@ -27004,12 +27014,15 @@ static const struct builtin_description bdesc_args[] =
{
[PATCH 1/4] i386: Cleanup and unify widening multiply patterns
Prepares for exposing builtin_mul_widen_even/odd hooks
for more efficient reduction. Adds QImode multiplication.
Shares code between mulv4si3 and the widening multiplies.
---
gcc/ChangeLog | 25 +
gcc/config/i386/i386-protos.h |4 +-
gcc/config/i386/i386.c| 211 -
gcc/config/i386/i386.md |1 +
gcc/config/i386/predicates.md |7 --
gcc/config/i386/sse.md| 206
6 files changed, 213 insertions(+), 241 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 59109d5..12b8de8 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,28 @@
+2012-06-25 Richard Henderson
+
+ * config/i386/i386.c (ix86_rtx_costs) [MULT]: Only apply XOP cost
+ to V16QImode.
+ (ix86_expand_vec_interleave): New.
+ (ix86_expand_mul_widen_evenodd): New.
+ (ix86_expand_mul_widen_hilo): New.
+ (ix86_expand_sse2_mulv4si3): Use ix86_expand_mul_widen_evenodd.
+ * config/i386/i386.md (u_bool) New code attr.
+ * config/i386/predicates.md
+ (nonimmediate_or_const_vector_operand): Remove.
+ * config/i386/sse.md (mul3): Don't use it; don't test
+ both AVX and SSE4_1.
+ (vec_widenmult_hi_): Remove.
+ (vec_widenmult_lo_): Remove.
+ (vec_widenmult_hi_v8si): Remove.
+ (vec_widenmult_lo_v8si): Remove.
+ (vec_widen_smult_hi_v4si): Remove.
+ (vec_widen_smult_lo_v4si): Remove.
+ (vec_widen_umult_hi_v4si): Remove.
+ (vec_widen_umult_lo_v4si): Remove.
+ (vec_widen_mult_hi_): New.
+ (vec_widen_mult_lo_): New.
+ * config/i386/i386-protos.h: Update.
+
2012-06-25 Matthew Gretton-Dann
James Greenhalgh
diff --git a/gcc/config/i386/i386-protos.h b/gcc/config/i386/i386-protos.h
index 88de8ed..c860e5a 100644
--- a/gcc/config/i386/i386-protos.h
+++ b/gcc/config/i386/i386-protos.h
@@ -1,6 +1,6 @@
/* Definitions of target machine for GCC for IA-32.
Copyright (C) 1988, 1992, 1994, 1995, 1996, 1996, 1997, 1998, 1999,
- 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011
+ 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
Free Software Foundation, Inc.
This file is part of GCC.
@@ -224,6 +224,8 @@ extern void ix86_expand_reduc (rtx (*)(rtx, rtx, rtx), rtx,
rtx);
extern void ix86_expand_vec_extract_even_odd (rtx, rtx, rtx, unsigned);
extern bool ix86_expand_pinsr (rtx *);
+extern void ix86_expand_mul_widen_evenodd (rtx, rtx, rtx, bool, bool);
+extern void ix86_expand_mul_widen_hilo (rtx, rtx, rtx, bool, bool);
extern void ix86_expand_sse2_mulv4si3 (rtx, rtx, rtx);
/* In i386-c.c */
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index 7e2352d..a1b7628 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -32101,7 +32101,7 @@ ix86_rtx_costs (rtx x, int code_i, int outer_code_i,
int opno, int *total,
/* V*QImode is emulated with 1-11 insns. */
if (mode == V16QImode || mode == V32QImode)
{
- int count;
+ int count = 11;
if (TARGET_XOP && mode == V16QImode)
{
/* For XOP we use vpshab, which requires a broadcast of the
@@ -32117,8 +32117,8 @@ ix86_rtx_costs (rtx x, int code_i, int outer_code_i,
int opno, int *total,
}
count = 3;
}
- else
- count = TARGET_SSSE3 ? 7 : 11;
+ else if (TARGET_SSSE3)
+ count = 7;
*total = cost->fabs * count;
}
else
@@ -32199,7 +32199,11 @@ ix86_rtx_costs (rtx x, int code_i, int outer_code_i,
int opno, int *total,
/* V*QImode is emulated with 7-13 insns. */
if (mode == V16QImode || mode == V32QImode)
{
- int extra = TARGET_XOP ? 5 : TARGET_SSSE3 ? 6 : 11;
+ int extra = 11;
+ if (TARGET_XOP && mode == V16QImode)
+ extra = 5;
+ else if (TARGET_SSSE3)
+ extra = 6;
*total = cost->fmul * 2 + cost->fabs * extra;
}
/* Without sse4.1, we don't have PMULLD; it's emulated with 7
@@ -38519,6 +38523,34 @@ ix86_expand_vec_extract_even_odd (rtx targ, rtx op0,
rtx op1, unsigned odd)
expand_vec_perm_even_odd_1 (&d, odd);
}
+static void
+ix86_expand_vec_interleave (rtx targ, rtx op0, rtx op1, bool high_p)
+{
+ struct expand_vec_perm_d d;
+ unsigned i, nelt, base;
+ bool ok;
+
+ d.target = targ;
+ d.op0 = op0;
+ d.op1 = op1;
+ d.vmode = GET_MODE (targ);
+ d.nelt = nelt = GET_MODE_NUNITS (d.vmode);
+ d.one_operand_p = false;
+ d.testing_p = false;
+
+ base = high_p ? nelt / 2 : 0;
+ for (i = 0; i < nelt / 2; ++i)
+{
+ d.perm[i * 2] = i + base;
+ d.perm[i * 2 + 1] = i + base + nelt;
+}
+
+ /* Note that for AVX this isn't one instruction. */
+ ok = ix
Re: RFA: dwarf2out vs. LP64-on-ELF32
Andrew Pinski writes: > On Sun, Jun 24, 2012 at 3:36 AM, Richard Sandiford > wrote: >> One of the more unfortunate things MIPS has inherited is an LP64 ABI >> that uses 32-bit rather than 64-bit ELF. I've no idea how many people >> use it these days (if anyone), but it happens to the ABI of the MIPS >> primary target, mipsisa64-elf. > > We (Cavium) use the EABI-64 ABI for our simple-exec (bare-metal) > target so there is an user base out there now. Thanks, that's good to know. I'm never entirely sure how things are being used, so this sort of information definitely helps. I also realised that it's no different from -msym32 -mabi=64, which is the standard way of building many 64-bit linux kernels, so my negative comments above were just plain wrong. Richard
Re: [Patch, mips] Fix warning when using --with-synci
On Mon, 2012-06-25 at 20:00 +0100, Richard Sandiford wrote: > Or to put it another way, MIPS_ISA_LEVEL_SPEC and MIPS_ARCH_FLOAT_SPEC > make the multilib options explicit on the command line. You can then > use that information to add whatever options you want to be the default > for a given multilib. OK, I didn't really understand this setup before, but I think I get it now and I see how I would use this to set -msynci. I guess I would want to create a new triple for a multilib linux mips target so I will work on that approach and see how it goes. Steve Ellcey sell...@mips.com
Re: [patch] Only define JMP_BUF_SIZE in backends that also define DONT_USE_BUILTIN_SETJMP
> But we can certainly remove stuff that doesn't do anything; in particular, > these 3 lines > > /*#define DONT_USE_BUILTIN_SETJMP 1*/ > #undef DONT_USE_BUILTIN_SETJMP > #define JMP_BUF_SIZE (8*3+8) > > can be proved to be equivalent to the empty set. If you say so, go for it ;-)
Re: [patch] [gcc/libgcc/ada/libstdc++] Match arm*-*-linux-*eabi* for ARM Linux/GNU EABI
On 25.06.2012 18:21, Matthias Klose wrote: > On 25.06.2012 15:22, Richard Earnshaw wrote: >> On 25/06/12 13:08, Matthias Klose wrote: >>> gcc/config.gcc now allows matching arm*-*-linux-*eabi* instead of >>> arm*-*-linux-*eabi for ARM Linux/GNU EABI. This changes the matching in >>> various >>> other places as well. arm-linux-gnueabihf is used as a triplet by some >>> distributions. >>> >>> Ok for the trunk? >>> >> >> now that all arm-linux ports are EABI conforming, why can't this just become >> >> arm*-*-linux* >> ? > > I assume it could. But I didn't check for other places where this would be > needed. $ grep -r 'arm[^_]*eabi' . |egrep -v 'ChangeLog|\.svn/'|wc -l 87 this seems to be a larger change, which should have been committed when the old abi targets were deprecated. I'd like to get the eabi* change in first. Matthias
Re: Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)
On Sat, Jun 23, 2012 at 3:55 AM, Dominique Dhumieres wrote:
>> As I don't have access to a Darwin machine to test a fix, would you
>> mind updating the test?
>
> The failures are gone with the obvious patch:
>
> diff -up ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c
> gcc/testsuite/gcc.dg/pubtypes-2.c
> --- ../_clean/gcc/testsuite/gcc.dg/pubtypes-2.c 2009-11-25 18:15:43.0
> +0100
> +++ gcc/testsuite/gcc.dg/pubtypes-2.c 2012-06-22 23:56:37.0 +0200
> @@ -2,7 +2,7 @@
> /* { dg-options "-O0 -gdwarf-2 -dA" } */
> /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } { "*" } { "" } } */
> /* { dg-final { scan-assembler "__debug_pubtypes" } } */
> -/* { dg-final { scan-assembler "long+\[ \t\]+0x6a+\[ \t\]+\[#;]+\[
> \t\]+Length of Public Type Names Info" } } */
> +/* { dg-final { scan-assembler "long+\[ \t\]+0x13b+\[ \t\]+\[#;]+\[
> \t\]+Length of Public Type Names Info" } } */
> /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
> \t\]+external name" } } */
> /* { dg-final { scan-assembler-not "unused_struct0\"+\[ \t\]+\[#;]+\[
> \t\]+external name" } } */
>
> diff -up ../_clean/gcc/testsuite/gcc.dg/pubtypes-3.c
> gcc/testsuite/gcc.dg/pubtypes-3.c
> --- ../_clean/gcc/testsuite/gcc.dg/pubtypes-3.c 2009-11-25 18:15:46.0
> +0100
> +++ gcc/testsuite/gcc.dg/pubtypes-3.c 2012-06-22 23:57:10.0 +0200
> @@ -2,7 +2,7 @@
> /* { dg-options "-O0 -gdwarf-2 -dA" } */
> /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } { "*" } { "" } } */
> /* { dg-final { scan-assembler "__debug_pubtypes" } } */
> -/* { dg-final { scan-assembler "long+\[ \t\]+0x6a+\[ \t\]+\[#;]+\[
> \t\]+Length of Public Type Names Info" } } */
> +/* { dg-final { scan-assembler "long+\[ \t\]+0x13b+\[ \t\]+\[#;]+\[
> \t\]+Length of Public Type Names Info" } } */
> /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
> \t\]+external name" } } */
> /* { dg-final { scan-assembler-not "unused_struct0\"+\[ \t\]+\[#;]+\[
> \t\]+external name" } } */
> /* { dg-final { scan-assembler-not "\"list_name_type0\"+\[ \t\]+\[#;]+\[
> \t\]+external name" } } */
> diff -up ../_clean/gcc/testsuite/gcc.dg/pubtypes-4.c
> gcc/testsuite/gcc.dg/pubtypes-4.c
> --- ../_clean/gcc/testsuite/gcc.dg/pubtypes-4.c 2009-11-25 18:15:39.0
> +0100
> +++ gcc/testsuite/gcc.dg/pubtypes-4.c 2012-06-22 23:57:38.0 +0200
> @@ -2,7 +2,7 @@
> /* { dg-options "-O0 -gdwarf-2 -dA" } */
> /* { dg-skip-if "Unmatchable assembly" { mmix-*-* } { "*" } { "" } } */
> /* { dg-final { scan-assembler "__debug_pubtypes" } } */
> -/* { dg-final { scan-assembler "long+\[ \t\]+0xa1+\[ \t\]+\[#;]+\[
> \t\]+Length of Public Type Names Info" } } */
> +/* { dg-final { scan-assembler "long+\[ \t\]+0x172+\[ \t\]+\[#;]+\[
> \t\]+Length of Public Type Names Info" } } */
> /* { dg-final { scan-assembler "used_struct0\"+\[ \t\]+\[#;]+\[
> \t\]+external name" } } */
> /* { dg-final { scan-assembler-not "unused_struct0\"+\[ \t\]+\[#;]+\[
> \t\]+external name" } } */
> /* { dg-final { scan-assembler "\"list_name_type0\"+\[ \t\]+\[#;]+\[
> \t\]+external name" } } */
>
> I don't have write access, so someone will have to do the commit.
I will commit this if someone can approve it.
Sterling
Re: [wwwdocs] Update coding conventions for C++
On 6/25/12, Joseph S. Myers wrote: > On Mon, 25 Jun 2012, Diego Novillo wrote: > > [ Added doc maintainers in CC ] > > > > While I'm not particularly interested in the details of the > > coding conventions, I am interested in getting them in getting > > them installed before we merge cxx-conversion to trunk. > > > > Joseph, Gerald, do we have a process for accepting changes to > > coding conventions? > > I suggest sending smaller (so easier to review) patches that are > concrete and avoid speculation about possible future changes. The speculative parts come from the wiki. Unless I had specific reason to remove them, I left them. > > > +Compiler Options > > I don't like this repeated presentational markup; use > appropriate logical markup instead. Done. > > > + > > > +We will periodically pick a stable version of GCC, > > > +and require that that version of GCC be able to build > > > +all versions of GCC up to and including the next stable version. > > > +E.g., we may decide that all newer versions of GCC > > > +should be buildable with GCC 4.3.5. > > The current version required is more important than speculation > about future changes. E.g., say that code must build with GCC > 4.1 and later. After some off-line discussion with Diego, I have removed some of text in this area. It now focuses on being portable, rather than on arbitrary version numbers. > > > +Assertions > > > + > > > +Code should use gcc_assert(EXPR) to check invariants. > > > +Use gcc_unreachable() to mark places that should never be > > > +reachable (such as an unreachable default case of a > > > +switch). Do not use gcc_assert(0) for such purposes, as > > > +gcc_unreachable gives the compiler more information. The > > > +assertions are enabled unless explicitly configured off with > > > +--enable-checking=none. Do not use abort. > > > +User input should never be validated by either gcc_assert > > > +or gcc_unreachable. If the checks are expensive or the > > > +compiler can reasonably carry on after the error, they may be > > > +conditioned on --enable-checking. > > I don't think any of this is new - perhaps you could separate > rearrangement from the actual changes and C++ conventions? The section titles are new, but the text itself is not. There did not seem to be a reasonable way to separate the rearrangment from the new context in which it was placed. > > > +Function Calls > > > + > > > + > > > +All current GCC code uses a space between the function name > > > +and the left parenthesis in a function call. > > > +Essentially all C++ code omits that space, > > > +which is more consistent with C++ syntax. > > > +For the present we will retain the space. > > > +It is possible that in the future we will switch the code with a flag > > > day. > > > + > > Avoid speculation. Avoid duplicating the GNU Coding Standards. > Formatting can be assumed to follow the GNU Coding Standards > except where they are meaningless for C++ or something explicitly > overrides them. That paragraph came from the wiki. I have removed it. > > > + > > > +Think carefully about the size and performance impact > > > +of virtual functions and virtual bases > > > +before using them. > > > + > > Explain in more detail what the size and performance impact is > for people not familiar with the details of how C++ features > are implemented. I have added a bit more in the rationale, reached through the link at the end of that section. > > > + > > > +Indent protection labels by one space. > > > + > > > + > > > + > > > +Indent class members by two spaces. > > Do all the listed indentation rules correspond to what a > will do by default when editing C++ code in GNU Emacs? If not, > we have conflicting notions of GNU C++ indentation conventions. I have no idea. I don't use emacs. The two-space rule for members comes from the wiki. The one-space rule for protection labels is common practice. If folks want something else, changes are fine with me. I have also made a few other edits requested offline by Benjamin Kosnik. -- Lawrence Crowl
Re: [wwwdocs] Update coding conventions for C++
On 6/25/12, Lawrence Crowl wrote: > On 6/25/12, Joseph S. Myers wrote: >> On Mon, 25 Jun 2012, Diego Novillo wrote: >> > [ Added doc maintainers in CC ] >> > >> > While I'm not particularly interested in the details of the >> > coding conventions, I am interested in getting them in getting >> > them installed before we merge cxx-conversion to trunk. >> > >> > Joseph, Gerald, do we have a process for accepting changes to >> > coding conventions? >> >> I suggest sending smaller (so easier to review) patches that are >> concrete and avoid speculation about possible future changes. > > The speculative parts come from the wiki. Unless I had specific > reason to remove them, I left them. > >> > > +Compiler Options> > > /> >> >> I don't like this repeated presentational markup; use >> appropriate logical markup instead. > > Done. > >> > > + >> > > +We will periodically pick a stable version of GCC, >> > > +and require that that version of GCC be able to build >> > > +all versions of GCC up to and including the next stable version. >> > > +E.g., we may decide that all newer versions of GCC >> > > +should be buildable with GCC 4.3.5. >> >> The current version required is more important than speculation >> about future changes. E.g., say that code must build with GCC >> 4.1 and later. > > After some off-line discussion with Diego, I have removed some of > text in this area. It now focuses on being portable, rather than > on arbitrary version numbers. > >> > > +Assertions >> > > + >> > > +Code should use gcc_assert(EXPR) to check >> > > invariants. >> > > +Use gcc_unreachable() to mark places that should never >> > > be >> > > +reachable (such as an unreachable default case of a >> > > +switch). Do not use gcc_assert(0) for such purposes, >> > > as >> > > +gcc_unreachable gives the compiler more information. >> > > The >> > > +assertions are enabled unless explicitly configured off with >> > > +--enable-checking=none. Do not use abort. >> > > +User input should never be validated by either >> > > gcc_assert >> > > +or gcc_unreachable. If the checks are expensive or the >> > > +compiler can reasonably carry on after the error, they may be >> > > +conditioned on --enable-checking. >> >> I don't think any of this is new - perhaps you could separate >> rearrangement from the actual changes and C++ conventions? > > The section titles are new, but the text itself is not. There did > not seem to be a reasonable way to separate the rearrangment from > the new context in which it was placed. > >> > > +Function Calls >> > > + >> > > + >> > > +All current GCC code uses a space between the function name >> > > +and the left parenthesis in a function call. >> > > +Essentially all C++ code omits that space, >> > > +which is more consistent with C++ syntax. >> > > +For the present we will retain the space. >> > > +It is possible that in the future we will switch the code with a flag >> > > day. >> > > + >> >> Avoid speculation. Avoid duplicating the GNU Coding Standards. >> Formatting can be assumed to follow the GNU Coding Standards >> except where they are meaningless for C++ or something explicitly >> overrides them. > > That paragraph came from the wiki. I have removed it. > >> > > + >> > > +Think carefully about the size and performance impact >> > > +of virtual functions and virtual bases >> > > +before using them. >> > > + >> >> Explain in more detail what the size and performance impact is >> for people not familiar with the details of how C++ features >> are implemented. > > I have added a bit more in the rationale, reached through the link > at the end of that section. > >> > > + >> > > +Indent protection labels by one space. >> > > + >> > > + >> > > + >> > > +Indent class members by two spaces. >> >> Do all the listed indentation rules correspond to what a >> will do by default when editing C++ code in GNU Emacs? If not, >> we have conflicting notions of GNU C++ indentation conventions. > > I have no idea. I don't use emacs. The two-space rule for members > comes from the wiki. The one-space rule for protection labels is > common practice. If folks want something else, changes are fine > with me. > > I have also made a few other edits requested offline by Benjamin > Kosnik. > > -- > Lawrence Crowl Sorry, I forgot to add the patch. Note that I have removed some html headers that cause gcc mail grief. Index: htdocs/codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.66 diff -u -u -r1.66 codingconventions.html --- htdocs/codingconventions.html 19 Feb 2012 00:45:34 - 1.66 +++ htdocs/codingconventions.html 25 Jun 2012 22:19:46 - @@ -15,8 +19,71 @@ code to follow these conventions, it is best to send changes to follow the conventions separately from any other changes to the code. + +Documentation +ChangeLogs +Portability +Makefiles +Testsuite Conventions
[v3] doxygen vs. pdflatex, kill COMPACT_LATEX
Here's a deceptively small patchlet that allows make doc-pdf-doxygen build the api PDF file when the prerequisites are met. (And the texmf.cnf file is edited to increase the underlying TeX subsystem's memory.) I'm currently using doxygen 1.8.1.1 and a variety of latex subsystems, depending on the machine I use to generate docs. Up to this point, fedora 17 would fail to complete generation of the pdf file. This fixes it, allowing the generation on both f16 and f17. Hopefully others. tested x86/linux, f16 tested x86/linux, f17 -benjamin2012-06-25 Benjamin Kosnik * doc/doxygen/user.cfg.in: Change COMPACT_LATEX to NO. diff --git a/libstdc++-v3/doc/doxygen/user.cfg.in b/libstdc++-v3/doc/doxygen/user.cfg.in index 3defd8d..b9fc4bf 100644 --- a/libstdc++-v3/doc/doxygen/user.cfg.in +++ b/libstdc++-v3/doc/doxygen/user.cfg.in @@ -1422,7 +1422,7 @@ MAKEINDEX_CMD_NAME = makeindex # LaTeX documents. This may be useful for small projects and may help to # save some trees in general. -COMPACT_LATEX = YES +COMPACT_LATEX = NO # The PAPER_TYPE tag can be used to set the paper type that is used # by the printer. Possible values are: a4, letter, legal and
Re: [PATCH 3/7] Add stdint.h wrapper for VxWorks.
On Jun 25, 2012, at 1:15 PM, rbmj wrote: > On 06/25/2012 04:02 PM, Mike Stump wrote: >> On Jun 25, 2012, at 12:09 PM, rbmj wrote: >>> I also do not know how to run the test suite for the target system >>> (powerpc-wrs-vxworks). I would think some sort of powerpc simulator, but I >>> don't have a firmware image for VxWorks - just headers and embedded >>> hardware. >> To test well, you need to be able to compile and run code. So, the question >> is, can you do that, or not? If you can, then you have what you need to >> test. If you cannot do that, then you cannot test well. If you can >> compile, then you can test the compile time tests, but you'll miss out on >> all runtime tests. >> > Well, I know that I need to be able to compile and run code. I would guess > (/hope) that the testsuite is automated though, It is. > but I can't use that if I need to use my own custom buildscripts in order to > generate executables (can I?). Yes, you can use it. > Furthermore, I looked in those files (gcc/testsuite/gcc.dg/c99-stdint* - are > these correct?) and I can't find any entry point. Lots of tests don't require main. A class that does require main are C runtime tests. > If it helps, I can compile/run code. I know that the original fixincludes > patches I had compiled and ran code as well - I built my project and > successfully ran it. The problem is I don't exactly know the method. Also, > my classes have finished so I no longer have access to a target :-/ Ah, if no access, then, no runtime testing. You can still do compile time testing, if you want. An easier task might be to ask someone that has a VxWorks testing setup to test for you, there might be someone on the list that has one.
[PATCH] Strength reduction
Here's a new version of the main strength reduction patch, addressing
previous comments. A couple of quick notes:
* I opened PR53773 and PR53774 for the cases where commutative
operations were encountered with a constant in rhs1. This version of
the patch still has the gcc_asserts in place to catch those cases, but
I'll plan to remove those once the patch is approved.
* You previously asked:
>>
>> +static slsr_cand_t
>> +base_cand_from_table (tree base_in)
>> +{
>> + slsr_cand mapping_key;
>> +
>> + gimple def = SSA_NAME_DEF_STMT (base_in);
>> + if (!def)
>> +return (slsr_cand_t) NULL;
>> +
>> + mapping_key.cand_stmt = def;
>> + return (slsr_cand_t) htab_find (stmt_cand_map, &mapping_key);
>>
>> isn't that reachable via the base-name -> chain mapping for base_in?
I had to review this a bit, but the answer is no. If you look at one of
the algebraic manipulations in create_mul_ssa_cand as an example,
base_in corresponds to Y. base_cand_from_table is looking for a
candidate that has Y for its LHS. The base-name -> chain mapping is
used to find all candidates that have B as the base_name.
* I added a detailed explanation of what's going on with legal_cast_p.
Hopefully this will be easier to understand now.
I've bootstrapped this on powerpc64-unknown-linux-gnu with three new
regressions (for which I opened the two bug reports). Ok for trunk
after removing the asserts?
Thanks,
Bill
gcc:
2012-06-25 Bill Schmidt
* tree-pass.h (pass_strength_reduction): New decl.
* tree-ssa-loop-ivopts.c (initialize_costs): Make non-static.
(finalize_costs): Likewise.
* timevar.def (TV_TREE_SLSR): New timevar.
* gimple-ssa-strength-reduction.c: New.
* tree-flow.h (initialize_costs): New decl.
(finalize_costs): Likewise.
* Makefile.in (tree-ssa-strength-reduction.o): New dependencies.
* passes.c (init_optimization_passes): Add pass_strength_reduction.
gcc/testsuite:
2012-06-25 Bill Schmidt
* gcc.dg/tree-ssa/slsr-1.c: New test.
* gcc.dg/tree-ssa/slsr-2.c: Likewise.
* gcc.dg/tree-ssa/slsr-3.c: Likewise.
* gcc.dg/tree-ssa/slsr-4.c: Likewise.
Index: gcc/tree-pass.h
===
--- gcc/tree-pass.h (revision 188890)
+++ gcc/tree-pass.h (working copy)
@@ -452,6 +452,7 @@ extern struct gimple_opt_pass pass_tm_memopt;
extern struct gimple_opt_pass pass_tm_edges;
extern struct gimple_opt_pass pass_split_functions;
extern struct gimple_opt_pass pass_feedback_split_functions;
+extern struct gimple_opt_pass pass_strength_reduction;
/* IPA Passes */
extern struct simple_ipa_opt_pass pass_ipa_lower_emutls;
Index: gcc/testsuite/gcc.dg/tree-ssa/slsr-1.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/slsr-1.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/slsr-1.c (revision 0)
@@ -0,0 +1,20 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-optimized" } */
+
+extern void foo (int);
+
+void
+f (int *p, unsigned int n)
+{
+ foo (*(p + n * 4));
+ foo (*(p + 32 + n * 4));
+ if (n > 3)
+foo (*(p + 16 + n * 4));
+ else
+foo (*(p + 48 + n * 4));
+}
+
+/* { dg-final { scan-tree-dump-times "\\+ 128" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\+ 64" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\+ 192" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/slsr-2.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/slsr-2.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/slsr-2.c (revision 0)
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-optimized" } */
+
+extern void foo (int);
+
+void
+f (int *p, int n)
+{
+ foo (*(p + n++ * 4));
+ foo (*(p + 32 + n++ * 4));
+ foo (*(p + 16 + n * 4));
+}
+
+/* { dg-final { scan-tree-dump-times "\\+ 144" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\+ 96" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } } */
Index: gcc/testsuite/gcc.dg/tree-ssa/slsr-3.c
===
--- gcc/testsuite/gcc.dg/tree-ssa/slsr-3.c (revision 0)
+++ gcc/testsuite/gcc.dg/tree-ssa/slsr-3.c (revision 0)
@@ -0,0 +1,22 @@
+/* { dg-do compile } */
+/* { dg-options "-O3 -fdump-tree-optimized" } */
+
+int
+foo (int a[], int b[], int i)
+{
+ a[i] = b[i] + 2;
+ i++;
+ a[i] = b[i] + 2;
+ i++;
+ a[i] = b[i] + 2;
+ i++;
+ a[i] = b[i] + 2;
+ i++;
+ return i;
+}
+
+/* { dg-final { scan-tree-dump-times "\\* 4" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\+ 4" 2 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\+ 8" 1 "optimized" } } */
+/* { dg-final { scan-tree-dump-times "\\+ 12" 1 "optimized" } } */
+/* { dg-final { cleanup-tree-dump "optimized" } }
Re: [wwwdocs] Update coding conventions for C++
Hey Lawrence, thanks for this work and for keeping the public up-to-date with this gcc-patches posting. This looks pretty good to me. The only remaining issue for me is the fuzzyness/handwaving around inlining. I think the only way to really enforce "what can be inlined" is not to have people use their best judgement, or what they think is a small function, or what they intend for the compiler to inline, but to have -Winline mandatory. And thus flag things that are written as inlined, but cannot then be inlined by the compiler. This area seems historically fraught, in terms of expectations. I'm not trying to poke at the hornets nest here. -benjamin
Re: Fix PR tree-optimization/53729 (Re: [PATCH] Fix PR tree-optimization/53636)
Ulrich Weigand writes:
> Richard Guenther wrote:
>
> > In this testcase the alignment of arr[i] should be irrelevant - it is
> > not part of
> > the stmts that are going to be vectorized. But of course this may be
> > simply an odering issue in how we analyze data-references / statements
> > in basic-block vectorization (thus we possibly did not yet declare the
> > arr[i] = i statement as not taking part in the vectorization).
>
> The following patch changes
> tree-vect-data-refs.c:vect_verify_datarefs_alignment
> to only take into account statements marked as "relevant".
>
> This should have no impact for loop-based vectorization, since the only
> caller
> (vect_enhance_data_refs_alignment) already skips irrelevant statements.
> [ As an aside, that routine should probably use STMT_VINFO_RELEVANT_P instead
> of just checking STMT_VINFO_RELEVANT as a boolean. ]
>
> However, for SLP this change in itself doesn't work, since
> vect_slp_analyze_bb_1
> calls vect_verify_datarefs_alignment *before* statements have actually been
> marked as relevant or irrelevant. Therefore, the patch also rearranges the
> sequence in vect_slp_analyze_bb_1.
>
> This in turn caused ICEs in vect_get_store_cost/vect_get_load_cost, since
> those
> now can get called with statements with unsupported alignment. There is
> already
> one caller (vect_get_data_access_cost) that checks for this case and simply
> returns "infinite" cost instead of aborting. The patch moves this behaviour
> into vect_get_store_cost/vect_get_load_cost themselves. (The particular cost
> shouldn't matter since vectorization will still be rejected in the end, it's
> just that the test now runs a bit later.)
>
> Overall, I've tested the patch with no regresions on powerpc64-linux and
> arm-linux-gnueabi. On PowerPC, it fixed the gcc.dg/vect/bb-slp-16.c test.
>
> Mikael, would you mind verifying that it fixes the problem on sparc64?
On sparc64-linux it fixed the bb-slp-16.c regression and didn't cause
any new ones.
/Mikael
>
> OK for mainline?
>
> Bye,
> Ulrich
>
>
> ChangeLog:
>
> PR tree-optimization/53729
> PR tree-optimization/53636
> * tree-vect-slp.c (vect_slp_analyze_bb_1): Delay call to
> vect_verify_datarefs_alignment until after statements have
> been marked as relevant/irrelevant.
> * tree-vect-data-refs.c (vect_verify_datarefs_alignment):
> Skip irrelevant statements.
> (vect_enhance_data_refs_alignment): Use STMT_VINFO_RELEVANT_P
> instead of STMT_VINFO_RELEVANT.
> (vect_get_data_access_cost): Do not check for supportable
> alignment before calling vect_get_load_cost/vect_get_store_cost.
> * tree-vect-stmts.c (vect_get_store_cost): Do not abort when
> handling unsupported alignment.
> (vect_get_load_cost): Likewise.
>
>
> Index: gcc/tree-vect-data-refs.c
> ===
> *** gcc/tree-vect-data-refs.c(revision 188850)
> --- gcc/tree-vect-data-refs.c(working copy)
> *** vect_verify_datarefs_alignment (loop_vec
> *** 1094,1099
> --- 1094,1102
> gimple stmt = DR_STMT (dr);
> stmt_vec_info stmt_info = vinfo_for_stmt (stmt);
>
> + if (!STMT_VINFO_RELEVANT_P (stmt_info))
> +continue;
> +
> /* For interleaving, only the alignment of the first access matters.
>Skip statements marked as not vectorizable. */
> if ((STMT_VINFO_GROUPED_ACCESS (stmt_info)
> *** vect_get_data_access_cost (struct data_r
> *** 1213,1229
> loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
> int vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
> int ncopies = vf / nunits;
> - bool supportable_dr_alignment = vect_supportable_dr_alignment (dr, true);
>
> ! if (!supportable_dr_alignment)
> ! *inside_cost = VECT_MAX_COST;
> else
> ! {
> ! if (DR_IS_READ (dr))
> ! vect_get_load_cost (dr, ncopies, true, inside_cost, outside_cost);
> ! else
> ! vect_get_store_cost (dr, ncopies, inside_cost);
> ! }
>
> if (vect_print_dump_info (REPORT_COST))
> fprintf (vect_dump, "vect_get_data_access_cost: inside_cost = %d, "
> --- 1216,1226
> loop_vec_info loop_vinfo = STMT_VINFO_LOOP_VINFO (stmt_info);
> int vf = LOOP_VINFO_VECT_FACTOR (loop_vinfo);
> int ncopies = vf / nunits;
>
> ! if (DR_IS_READ (dr))
> ! vect_get_load_cost (dr, ncopies, true, inside_cost, outside_cost);
> else
> ! vect_get_store_cost (dr, ncopies, inside_cost);
>
> if (vect_print_dump_info (REPORT_COST))
> fprintf (vect_dump, "vect_get_data_access_cost: inside_cost = %d, "
> *** vect_enhance_data_refs_alignment (loop_v
> *** 1537,1543
> stmt = DR_STMT (dr);
> stmt_info = vinfo_for_stmt (stmt);
>
>
Re: [wwwdocs] Update coding conventions for C++
On 6/25/12, Benjamin Kosnik wrote: > The only remaining issue for me is the fuzzyness/handwaving > around inlining. I think the only way to really enforce "what > can be inlined" is not to have people use their best judgement, > or what they think is a small function, or what they intend > for the compiler to inline, but to have -Winline mandatory. > And thus flag things that are written as inlined, but cannot then > be inlined by the compiler. > > This area seems historically fraught, in terms of expectations. > I'm not trying to poke at the hornets nest here. I see two problems with trying to use -Winline. First, the implication is that if the compiler does not complain with -Winline, then the inlining is fine. The compiler only warns when it cannot inline, not when that inlining is counter productive. That is, we want inlining when we win in either space or time, an -Winline does not tell us that. So, in a sense, the warning is too weak. Second, together -Winline and -Werror lead to a tempermental build. The documentation for -Winline says: Warn if a function can not be inlined and it was declared as inline. Even with this option, the compiler will not warn about failures to inline functions declared in system headers. The compiler uses a variety of heuristics to determine whether or not to inline a function. For example, the compiler takes into account the size of the function being inlined and the amount of inlining that has already been done in the current function. Therefore, seemingly insignificant changes in the source program can cause the warnings produced by -Winline to appear or disappear. IIUC, a small change to a function in a header file could cause a hundred other functions to suddenly start emitting the warning, causing the edit of files that would not normally be considered part of the patch. In the worst case, these functions would shift from header to source file, causing even more source churn. Even more disconcerting, the warning might not show up until later in the boot. If everyone keeps their inlines small and clean, maybe the second problem will not be so much of a problem. My concern is that writing it into the coding conventions shifts the practical consequences to places that are hard to anticipate and hard to deal with. For instance, suppose I inline foo() to meet performance goals, but in doing so bar() becomes to large to inline. Was bar() too performance critical to make non-inline? If so, how do I best refactor bar()? Will I need another maintainer to review the code because of that refactoring? With that concern stated, I will write into the conventions whatever concensus arises. Of course, I have no objection to an occasional inline cleanup. That is, build with -Werror and adjusting inlines that have, through the course of time, become larger than is useful. -- Lawrence Crowl
Re: [PATCH, gdc] - Merging gdc (GNU D Compiler) into gcc
On 19 June 2012 17:08, Steven Bosscher wrote: > Hello, > > I had a very quick look through the gdc_frontend patch. Below are a > couple of comments on it: > >> http://www.gdcproject.org/files/gdc_frontend.patch.gz >> >> [PATCH 1/4]: >> The D compiler frontend >> - gcc/d > > How did you test this? You include rtl.h/expr.h in d-builtins.c and > d-gcc-includes.h, which should both be in ALL_HOST_FRONTEND_OBJS and > fail to build because IN_GCC_FRONTEND is defined and GCC_RTL_H is > poisoned. See system.h: > > /* Front ends should never have to include middle-end headers. Enforce > this by poisoning the header double-include protection defines. */ > #ifdef IN_GCC_FRONTEND > #pragma GCC poison GCC_RTL_H GCC_EXCEPT_H GCC_EXPR_H > #endif > > Do you somehow bypass the normal build system? Or maybe you don't > include system.h? Either way, front ends should never have to include > RTL headers. > It seems that IN_GCC_FRONTEND was never defined throughout. I did not realise this. Have corrected it now in Make-lang.in and removed all code that depended on it. > BTW you also include output.h in those two files, and I am about two > patches away from adding output.h to the list of headers that no front > end should ever include (a front end should never have to write out > assembly). Can you please check what you need output.h for, and fix > this? > > > What are you calling targetm.asm_out.output_mi_thunk and > targetm.asm_out.generate_internal_label for? Thunks and aliases should > go through cgraphunit. > > (NB: This also means that this front end cannot work with LTO. IMHO we > shouldn't let in new front ends that don't work with LTO.) > > I tried switching, but unfortunately it broke the code generation of D thunks. D requires any class that inherits from an interface to output thunks for that interface regardless of how far back it is and whether it being external to the current module. However, the GCC backend as far as I can tell only outputs aliases when the function is output as well. So if there is no function to output no thunk will be generated. This leaves a handful of undefined references to thunks that were defined in the D frontend, but discarded by the backend. Whereas forcing the output using output_mi_thunk means the thunk is emitted and does not cause issues. So removing output.h will be a bit of a problem for me with no obvious way around it. > Many functions have no leading comment, and other GNU coding standard > requirements are not followed either. Those should IMHO be fixed also, > before this front end can be accepted. > > Most functions are of the same name but from different classes, eg: toElem, toIR, toCtype, toObjFile are a few of the main functions which cover the GCC code generation of all expressions and statements passed from the D frontend. > There is this comment: > +/* GCC does not support jumps from asm statements. > > This isn't really true anymore, as your patch also notes: > + -- > + %% Fix for GCC-4.5+ > + GCC now accepts a 5th operand, ASM_LABELS. > (...) > + For prior versions of gcc, this requires a backpatch. > > It seems to me that if this front end is contributed, handling of > prior version of gcc isn't necessary anymore - that code should just > be removed. > > > + > + case Op_de: > +#ifndef TARGET_80387 > +#define XFmode TFmode > +#endif > + mode = XFmode; // not TFmode > > What is this hack for? This is not the way to find the right mode for > this operation. > > +#ifdef TARGET_80387 > +#include "d-asm-i386.h" > +#else > +#define D_NO_INLINE_ASM_AT_ALL > +#endif > + > +/* Apple GCC extends ASM_EXPR to five operands; cannot use build4. */ > > Idem here. And Apple GCC is irrelevant too, if this front end lands on > FSF trunk. > > What is d/d-asm-i386.h for? It looks like i386 is a special case > throughout the front end. > After some discussion, I have remove the D Inline Asm implementation completely from GDC, along with the backend headers that it depended on, so this file is no more, along with the i386 special cases. > > In d-gcc-tree.h: > +// normally include config.h (hconfig.h, tconfig.h?), but that > +// includes things that cause problems, so... > + > +union tree_node; > +typedef union tree_node *tree; > > See coretypes.h. > Thanks for the tip! Have switched it over. -- Iain Buclaw *(p < e ? p++ : p) = (c & 0x0f) + '0';
Re: Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)
On Fri, Jun 22, 2012 at 9:46 PM, Jason Merrill wrote: > On 06/22/2012 02:15 PM, Cary Coutant wrote: >> >> But if the consensus turns out to be that enumerators should be in >> pubnames, wouldn't it also be fairly easy to change prune_unused_types >> so that it doesn't mark enumerators, and change output_pubnames to >> skip enumerators that have been pruned? > > > This makes sense to me. Enclosed is a patch that does it this way. It requires special-casing enumerators in two places. Personally, it seems cleaner to me just to put them in the pubtypes table, but I am happy to do it whichever way you want. Let me know, Sterling gcc/ChangeLog 2012-06-25 Sterling Augustine * dwarf2out.c (output_pubnames): Add check for DW_TAG_enumerator. (prune_unused_types): Add check for DW_TAG_enumerator. enum.patch Description: Binary data
RE: [PATCH, ARM] New CPU support for Marvell PJ4 cores
Updated changelog. * config/arm/marvell-pj4.md: New marvell-pj4 pipeline description. * config/arm/arm.c (arm_issue_rate): Add marvell_pj4. * config/arm/arm.md (tune_marvell): Add marvell_pj4. * config/arm/arm-cores.def: Add core marvell-pj4. * config/arm/arm-tune.md: Regenerated. * config/arm/arm-tables.opt: Regenerated. * config/arm/bpabi.h (BE8_LINK_SPEC): Add marvell_pj4. * doc/invoke.texi: Added entry for marvell-pj4. B.R. Yi-Hsiu, Hsu -Original Message- From: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org] Sent: Tuesday, June 26, 2012 3:36 AM To: Yi-Hsiu Hsu Cc: gcc-patches@gcc.gnu.org Subject: Re: [PATCH, ARM] New CPU support for Marvell PJ4 cores On 20 June 2012 03:53, Yi-Hsiu Hsu wrote: > marvell-pj4 is added to BE8_LINK_SPEC. > > Modified patch is attached. Missing a modified changelog entry. Ramana > > Thanks! > > B.R. > Yi-Hsiu, Hsu > > -Original Message- > From: Ramana Radhakrishnan [mailto:ramana.radhakrish...@linaro.org] > Sent: Thursday, June 14, 2012 2:19 AM > To: Yi-Hsiu Hsu > Cc: gcc-patches@gcc.gnu.org > Subject: Re: [PATCH, ARM] New CPU support for Marvell PJ4 cores > > On 29 May 2012 10:07, Yi-Hsiu Hsu wrote: >> Hi, >> >> This patch maintains Marvell PJ4 cores pipeline description. >> Run arm testsuite on arm-linux-gnueabi and no extra regressions are found. >> >> * config/arm/marvell-pj4.md: New marvell-pj4 pipeline description. >> * config/arm/arm.c (arm_issue_rate): Add marvell_pj4. >> * config/arm/arm-cores.def: Add core marvell-pj4. >> * config/arm/arm-tune.md: Regenerated. >> * config/arm/arm-tables.opt: Regenerated. >> * doc/invoke.texi: Added entry for marvell-pj4. > > This command line option should also be added to BE8_LINK_SPEC similar > to what's done for the other v7-a cores. > > Ok with that change. > > regards, > Ramana > > > >> >> >> Thanks! >> >> P.S. I create the patch from revision 187308, but this revision is unable to >> build successfully, then I apply this patch to revision 187623 and >> successfully build and pass the testsuite. >>
[testsuite] access name from dg-test via a proc instead of upvar
Lots of places in GCC's testsuite infrastructure get the test name with
current torture options, set up by DejaGnu's dg-test, by using upvar.
These accesses usually have a comment that this is ugly but there's
nothing else to do. I recently modified that test name for use by the
scan directives to add an extra space, not realizing that I was changing
the actual variable from dg-test, so tests that use a lot of scans are
getting one more space per scan message. Checking for options in the
name and adding a space also slowed things down quite a bit.
This patch limits the use of upvar for "name" in dg-test to a new proc
which saves its value for further uses in the same test, with an extra
space at the end if there are torture options.
Tested on i686-pc-linux-gnu for gcc and g++. OK for trunk?
Janis
2012-06-25 Janis Johnson
* lib/target-supports-dg.exp (testname-for-summary): New.
* lib/profopt.exp (profopt_execute): Define testname_with_flags.
* lib/gcc-dg.exp (cleanup-coverage-files, cleanup-repo-notes,
cleanup-stack-usage, cleanup-dump, cleanup-saved-temps, scan-module,
scan-module-absence, output-exists, output-exists-not: Use
testname-for-summary.
(dg-test): Clean up testname_with_flags.
* lib/scanasm.exp (scan-assembler, scan-assembler-not, scan-hidden,
scan-not-hidden, scan-file, scan-file-not, scan-stack-usage,
scan-stack-usage-not, scan-assembler-times, scan-assembler-dem,
scan-assembler-dem-not, object-size: Use testname-for-summary.
* lib/gcov.exp (run-gcov): Likewise.
* lib/scandump.exp (scan-dump, scan-dump-times, scan-dump-not,
scan-dump-dem, scan-dump-dem-note): Likewise.
Index: lib/target-supports-dg.exp
===
--- lib/target-supports-dg.exp (revision 188964)
+++ lib/target-supports-dg.exp (working copy)
@@ -31,6 +31,34 @@
return "$flags1 $flags2"
}
+# DejaGnu's dg-test defines a test name that includes torture options
+# which is used in most pass/fail messages. Grab a copy of it.
+
+proc testname-for-summary { } {
+global testname_with_flags
+
+# A variable called "name" is too generic, so identify dg-test by
+# the existence of dg-extra-tool-flags.
+if ![info exists testname_with_flags] {
+ set frames 2
+ while { ![info exists flags] } {
+ set frames [expr $frames + 1]
+ upvar $frames dg-extra-tool-flags flags
+ }
+
+ # We've got the stack level for dg-test; get the variable we want.
+ upvar $frames name name
+ set testname_with_flags $name
+
+ # If there are flags, add an extra space to improve readability of
+ # the test summary.
+ if { [llength $testname_with_flags] > 1 } {
+ set testname_with_flags "$testname_with_flags "
+ }
+}
+return "$testname_with_flags"
+}
+
# If this target does not support weak symbols, skip this test.
proc dg-require-weak { args } {
Index: lib/profopt.exp
===
--- lib/profopt.exp (revision 188964)
+++ lib/profopt.exp (working copy)
@@ -217,6 +217,7 @@
global tool profile_option feedback_option prof_ext perf_ext perf_delta
global generate_final_code use_final_code
global verbose
+global testname_with_flags
if ![info exists profile_option] {
error "No profile option specified for first compile."
@@ -240,6 +241,12 @@
set testcase "[file tail [file dirname $src]]/[file tail $src]"
}
+# Several procedures access the name of the test with torture flags,
+# normally defined in dg-test. Profile optimization tests don't
+# use dg-test, so define it here to make it accessible via
+# testname-for-summary.
+set testname_with_flags $testcase
+
set executable $tmpdir/[file tail [file rootname $src].x]
set basename [file tail $testcase]
set base [file rootname $basename]
@@ -272,6 +279,7 @@
set extra_flags [profopt-get-options $src]
if { [lindex ${dg-do-what} 1 ] == "N" } {
unsupported "$src"
+ unset testname_with_flags
verbose "$src not supported on this target, skipping it" 3
return
}
@@ -437,4 +445,5 @@
remote_file build delete $execname3
}
}
+unset testname_with_flags
}
Index: lib/gcc-dg.exp
===
--- lib/gcc-dg.exp (revision 188964)
+++ lib/gcc-dg.exp (working copy)
@@ -433,10 +433,7 @@
# Remove compiler-generated coverage files for the current test.
proc cleanup-coverage-files { } {
-# This assumes that we are two frames down from dg-test or some other proc
-# that stores the filename of the testcase in a local variable "name".
-# A cleaner solution would require a new DejaGnu release.
-upvar 2 name testcase
+set tes
Re: Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)
On Jun 25, 2012, at 3:15 PM, Sterling Augustine wrote: > On Sat, Jun 23, 2012 at 3:55 AM, Dominique Dhumieres > wrote: >>> As I don't have access to a Darwin machine to test a fix, would you >>> mind updating the test? >> >> The failures are gone with the obvious patch: > I will commit this if someone can approve it. Ok.
Re: [testsuite] access name from dg-test via a proc instead of upvar
On Jun 25, 2012, at 6:42 PM, Janis Johnson wrote: > Lots of places in GCC's testsuite infrastructure get the test name with > current torture options, set up by DejaGnu's dg-test, by using upvar. > These accesses usually have a comment that this is ugly but there's > nothing else to do. > OK for trunk? Ok.
Re: Updated to respond to various email comments from Jason, Diego and Cary (issue6197069)
OK. Jason
C++ PATCH for c++/53498 (infinite tsubst recursion with variadic template)
Here, the problem was that when we substitute into a parameter pack
PARM_DECL to get a dummy decl for use in a decltype context, we were
continuing to tsubst into its DECL_CHAIN as well, which causes problems
if a following parameter uses the previous parameter, as in this testcase.
In tsubst_copy we've dealt with this issue for non-pack parameters by
doing a copy_node before calling tsubst_decl, but it occurred to me that
we could check cp_unevaluated_context instead to avoid the extra allocation.
Tested x86_64-pc-linux-gnu, applying to trunk. Alternative patch that
just does the copy for packs as well tested and applying to 4.7.
commit 9b1909cf6cf54f405b83e312483d263d9c4b6f92
Author: Jason Merrill
Date: Mon Jun 25 17:02:48 2012 -0400
PR c++/53498
PR c++/53305
* pt.c (tsubst_decl) [PARM_DECL]: Don't recurse into DECL_CHAIN
if cp_unevaluated_operand is set.
(tsubst_copy) [PARM_DECL]: Don't copy before tsubsting.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index ad7134b..7e1c46f 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -10497,7 +10497,9 @@ tsubst_decl (tree t, tree args, tsubst_flags_t complain)
DECL_CHAIN (prev_r) = r;
}
- if (DECL_CHAIN (t))
+ /* If cp_unevaluated_operand is set, we're just looking for a
+ single dummy parameter, so don't keep going. */
+ if (DECL_CHAIN (t) && !cp_unevaluated_operand)
DECL_CHAIN (r) = tsubst (DECL_CHAIN (t), args,
complain, DECL_CHAIN (t));
@@ -12078,8 +12080,6 @@ tsubst_copy (tree t, tree args, tsubst_flags_t complain, tree in_decl)
if (r == NULL_TREE)
{
- tree c;
-
/* We get here for a use of 'this' in an NSDMI. */
if (DECL_NAME (t) == this_identifier
&& at_function_scope_p ()
@@ -12090,12 +12090,7 @@ tsubst_copy (tree t, tree args, tsubst_flags_t complain, tree in_decl)
declaration (such as in a late-specified return type). Just
make a dummy decl, since it's only used for its type. */
gcc_assert (cp_unevaluated_operand != 0);
- /* We copy T because want to tsubst the PARM_DECL only,
- not the following PARM_DECLs that are chained to T. */
- c = copy_node (t);
- r = tsubst_decl (c, args, complain);
- if (r == NULL_TREE)
- return error_mark_node;
+ r = tsubst_decl (t, args, complain);
/* Give it the template pattern as its context; its true context
hasn't been instantiated yet and this is good enough for
mangling. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype38.C b/gcc/testsuite/g++.dg/cpp0x/decltype38.C
new file mode 100644
index 000..97ebb33
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype38.C
@@ -0,0 +1,17 @@
+// PR c++/53498
+// { dg-do compile { target c++11 } }
+
+template
+struct B
+{
+ template
+ static
+ void b(const U& u, const Args&... args,
+ decltype(u.f(args...)) dummy)
+ {
+ }
+};
+
+int main() {
+ B b;
+}
diff --git a/gcc/testsuite/g++.dg/cpp0x/variadic132.C b/gcc/testsuite/g++.dg/cpp0x/variadic132.C
index f50c7a6..1b9c286 100644
--- a/gcc/testsuite/g++.dg/cpp0x/variadic132.C
+++ b/gcc/testsuite/g++.dg/cpp0x/variadic132.C
@@ -9,11 +9,11 @@ struct funct
int operator()(argTs...);
};
-template class test;
+template struct test;
template class tp,
class... arg1Ts, class... arg2Ts>
-class test, tp>
+struct test, tp>
{
template
auto test2(func fun, arg1Ts... arg1s, arg3Ts... arg3s)
@@ -23,5 +23,5 @@ class test, tp>
int main()
{
test, tuple> t2;
- t2.test2(funct(), 'a', 2); // { dg-error "no matching function" }
+ t2.test2(funct(), 'a', 2);
}
commit 1965f161a59d81a408cd2369e7a393fa17e95ede
Author: Jason Merrill
Date: Mon Jun 25 17:32:32 2012 -0400
PR c++/53498
PR c++/53305
* pt.c (tsubst_pack_expansion): Copy before dummy tsubst.
diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c
index 7f5682d..1b5ab9e 100644
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -9393,7 +9393,9 @@ tsubst_pack_expansion (tree t, tree args, tsubst_flags_t complain,
late-specified return type). Even if it exists, it might
have the wrong value for a recursive call. Just make a
dummy decl, since it's only used for its type. */
- arg_pack = tsubst_decl (parm_pack, args, complain);
+ /* Copy before tsubsting so that we don't recurse into any
+ later PARM_DECLs. */
+ arg_pack = tsubst_decl (copy_node (parm_pack), args, complain);
if (arg_pack && FUNCTION_PARAMETER_PACK_P (arg_pack))
/* Partial instantiation of the parm_pack, we can't build
up an argument pack yet. */
diff --git a/gcc/testsuite/g++.dg/cpp0x/decltype38.C b/gcc/testsuite/g++.dg/cpp0x/decltype38.C
new file mode 100644
index 000..97ebb33
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/decltype38.C
@@ -0,0 +1,17 @@
+// PR c++/53498
+// { dg-do compile { target c++11 } }
+
+template
+struct B
+{
+ template
+ static
+ void b(const U& u, const Args&... args,
+ decltype(u.f(args...)) dummy)
+ {
+ }
+};
+
+int main() {
+ B b;
+}
diff --git a/gcc/tes
