Re: [gimplefe] Parsing __GIMPLE function body
On Mon, May 30, 2016 at 5:15 PM, Prasad Ghangal
wrote:
> Hi,
>
> As David suggested in his rtlfe patch,
> this patch recognizes __GIMPLE keyword and switches to
> c_parser_parse_gimple_body by providing -fgimple option.
>
>
> diff --git a/gcc/c-family/c-common.c b/gcc/c-family/c-common.c
> index 4568cf6..41a8f05 100644
> --- a/gcc/c-family/c-common.c
> +++ b/gcc/c-family/c-common.c
> @@ -511,6 +511,7 @@ const struct c_common_resword c_common_reswords[] =
>{ "__underlying_type", RID_UNDERLYING_TYPE, D_CXXONLY },
>{ "__volatile",RID_VOLATILE,0 },
>{ "__volatile__",RID_VOLATILE,0 },
> + { "__GIMPLE",RID_GIMPLE,0 },
I think we need a D_GIMPLE_ONLY flag which disables this reserved word
when -fgimple is not
in effect. That's something to put on a list of TODOs once everything
else works fine (it's not
high priority but a requirement to merge to trunk). For now you can
at least put D_CONLY there
(as -fgimple is a C only flag).
>{ "alignas",RID_ALIGNAS,D_CXXONLY | D_CXX11 | D_CXXWARN },
>{ "alignof",RID_ALIGNOF,D_CXXONLY | D_CXX11 | D_CXXWARN },
>{ "asm",RID_ASM,D_ASM },
> diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
> index 0295532..23a401d 100644
> --- a/gcc/c-family/c-common.h
> +++ b/gcc/c-family/c-common.h
> @@ -104,6 +104,9 @@ enum rid
>RID_DFLOAT32, RID_DFLOAT64, RID_DFLOAT128,
>RID_FRACT, RID_ACCUM, RID_AUTO_TYPE, RID_BUILTIN_CALL_WITH_STATIC_CHAIN,
>
> + /* "__GIMPLE", for the GIMPLE-parsing extension to the C frontend. */
> + RID_GIMPLE,
> +
>/* C11 */
>RID_ALIGNAS, RID_GENERIC,
>
> diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
> index 918df16..8ab56af 100644
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -200,6 +200,10 @@ F
> Driver C ObjC C++ ObjC++ Joined Separate MissingArgError(missing path
> after %qs)
> -F Add to the end of the main framework include path.
>
> +fgimple
> +C Var(flag_gimple) Init(0)
> +Enable parsing GIMPLE
> +
> H
> C ObjC C++ ObjC++
> Print the name of header files as they are used.
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 1cf4fb4..c5a4d3f 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -1396,6 +1396,7 @@ static bool c_parser_cilk_verify_simd (c_parser
> *, enum pragma_context);
> static tree c_parser_array_notation (location_t, c_parser *, tree, tree);
> static tree c_parser_cilk_clause_vectorlength (c_parser *, tree, bool);
> static void c_parser_cilk_grainsize (c_parser *, bool *);
> +static void c_parser_parse_gimple_body (c_parser *parser);
>
> /* Parse a translation unit (C90 6.7, C99 6.9).
>
> @@ -1638,6 +1639,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
> bool fndef_ok,
>tree all_prefix_attrs;
>bool diagnosed_no_specs = false;
>location_t here = c_parser_peek_token (parser)->location;
> + bool gimple_body_p = false;
>
>if (static_assert_ok
>&& c_parser_next_token_is_keyword (parser, RID_STATIC_ASSERT))
> @@ -1687,6 +1689,17 @@ c_parser_declaration_or_fndef (c_parser
> *parser, bool fndef_ok,
>c_parser_skip_to_end_of_block_or_statement (parser);
>return;
> }
> +
> + if (c_parser_next_token_is (parser, CPP_KEYWORD))
> +{
> + c_token *kw_token = c_parser_peek_token (parser);
> + if (kw_token->keyword == RID_GIMPLE)
> +{
> + gimple_body_p = true;
> + c_parser_consume_token (parser);
> +}
> +}
> +
>finish_declspecs (specs);
>bool auto_type_p = specs->typespec_word == cts_auto_type;
>if (c_parser_next_token_is (parser, CPP_SEMICOLON))
> @@ -2102,6 +2115,14 @@ c_parser_declaration_or_fndef (c_parser
> *parser, bool fndef_ok,
> oacc_routine_clauses, false, first, true);
>DECL_STRUCT_FUNCTION (current_function_decl)->function_start_locus
> = c_parser_peek_token (parser)->location;
> +
> + if (gimple_body_p && flag_gimple)
> +{
> + c_parser_parse_gimple_body (parser);
> + finish_function ();
> + return;
> +}
> +
>fnbody = c_parser_compound_statement (parser);
>if (flag_cilkplus && contains_array_notation_expr (fnbody))
> fnbody = expand_array_notation_exprs (fnbody);
> @@ -2123,7 +2144,7 @@ c_parser_declaration_or_fndef (c_parser *parser,
> bool fndef_ok,
>add_stmt (fnbody);
>finish_function ();
> }
> -
> +
>timevar_pop (tv);
>break;
> }
Always avoid stay changes like this.
> @@ -18055,4 +18076,23 @@ c_parser_array_notation (location_t loc,
> c_parser *parser, tree initial_index,
>return value_tree;
> }
>
> +/* Parse the body of a function declaration marked with "__GIMPLE". */
> +
> +void
> +c_parser_parse_gimple_body (c_parser *parser)
> +{
> + if (!c_parser_require (parser, CPP_OPEN_BRACE, "expected %<{%>"))
> +return;
> +
> + location_t loc1 = c_parser_peek_token (parser)->location;
> + inform (loc1, "start of GIMPLE");
> +
> + while (c_parser_ne
Re: GCC 5.4 Release Candidate available from gcc.gnu.org
Hi Richard, On 27/05/16 12:43, Richard Biener wrote: The first release candidate for GCC 5.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/5.4.0-RC-20160527 and shortly its mirrors. It has been generated from SVN revision 236809. I have sofar bootstrapped the release candidate on x86_64-suse-linux-gnu. Please test the release candidate and report any issues to bugzilla. If all goes well I'd like to release GCC 5.4 at the beginning of next week. Bootstrap and test on arm-none-linux-gnueabihf looks fine. Unfortunately, on aarch64-none-linux-gnu I noticed a regression compared to GCC 5.3: FAIL: gcc.target/aarch64/vbslq_u64_1.c scan-assembler-times bif\\tv 1 This is PR 68696 that has been triggered on that branch. The patch fixing that is at: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00826.html I have bootstrapped and tested it on aarch64-none-linux-gnu on top of the 5.4 RC and it fixes the regression. It applies cleanly to that branch. Is it okay to backport it to the branch? Thanks, Kyrill
Re: GCC 5.4 Release Candidate available from gcc.gnu.org
On Tue, 31 May 2016, Kyrill Tkachov wrote: > Hi Richard, > > On 27/05/16 12:43, Richard Biener wrote: > > The first release candidate for GCC 5.4 is available from > > > > ftp://gcc.gnu.org/pub/gcc/snapshots/5.4.0-RC-20160527 > > > > and shortly its mirrors. It has been generated from SVN revision 236809. > > > > I have sofar bootstrapped the release candidate on x86_64-suse-linux-gnu. > > > > Please test the release candidate and report any issues to bugzilla. > > > > If all goes well I'd like to release GCC 5.4 at the beginning of next > > week. > > > > Bootstrap and test on arm-none-linux-gnueabihf looks fine. > Unfortunately, on aarch64-none-linux-gnu I noticed a regression compared to > GCC 5.3: > FAIL: gcc.target/aarch64/vbslq_u64_1.c scan-assembler-times bif\\tv 1 > > This is PR 68696 that has been triggered on that branch. > The patch fixing that is at: > https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00826.html > > I have bootstrapped and tested it on aarch64-none-linux-gnu on top of the 5.4 > RC > and it fixes the regression. It applies cleanly to that branch. > > Is it okay to backport it to the branch? While it doesn't look like having the same cause (r231178) the patch looks safe to me to backport. Thus, ok. Thanks, Richard. > Thanks, > Kyrill > > -- Richard Biener SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nuernberg)
Re: GCC 5.4 Release Candidate available from gcc.gnu.org
On 31/05/16 12:17, Richard Biener wrote: On Tue, 31 May 2016, Kyrill Tkachov wrote: Hi Richard, On 27/05/16 12:43, Richard Biener wrote: The first release candidate for GCC 5.4 is available from ftp://gcc.gnu.org/pub/gcc/snapshots/5.4.0-RC-20160527 and shortly its mirrors. It has been generated from SVN revision 236809. I have sofar bootstrapped the release candidate on x86_64-suse-linux-gnu. Please test the release candidate and report any issues to bugzilla. If all goes well I'd like to release GCC 5.4 at the beginning of next week. Bootstrap and test on arm-none-linux-gnueabihf looks fine. Unfortunately, on aarch64-none-linux-gnu I noticed a regression compared to GCC 5.3: FAIL: gcc.target/aarch64/vbslq_u64_1.c scan-assembler-times bif\\tv 1 This is PR 68696 that has been triggered on that branch. The patch fixing that is at: https://gcc.gnu.org/ml/gcc-patches/2015-12/msg00826.html I have bootstrapped and tested it on aarch64-none-linux-gnu on top of the 5.4 RC and it fixes the regression. It applies cleanly to that branch. Is it okay to backport it to the branch? While it doesn't look like having the same cause (r231178) the patch looks safe to me to backport. Indeed, the bug is a missing pattern in the backend that ends up with us relying on xor+and sequences being emitted in a certain order after the tree passes, so it can be triggered by any of a number of tree-level changes. Thus, ok. Thanks, I'll commit it shortly. Kyrill Thanks, Richard. Thanks, Kyrill
Re: [patch,libgomp] Make libgomp Fortran modules multilib-aware
Richard, Jakub, or any global write maintainer: can I get a review on this one-word patch? -- The attached patch allows libgomp to install its Fortran modules in the correct multilib-aware directories, just like libgfortran does. Without it, multilib Fortran OpenMP code using the modules fails to compile because the modules are not found: $ gfortran -fopenmp a.f90 $ gfortran -fopenmp a.f90 -m32 a.f90:1:6: use omp_lib 1 Fatal Error: Can't open module file ‘omp_lib.mod’ for reading at (1): No such file or directory compilation terminated. Bootstrapped and tested on x86_64-apple-darwin15. OK to commit? FX 2016-05-03 Francois-Xavier Coudert PR libgomp/60670 * Makefile.am: Make fincludedir multilib-aware. * Makefile.in: Regenerate. Index: libgomp/Makefile.am === --- libgomp/Makefile.am (revision 235843) +++ libgomp/Makefile.am (working copy) @@ -10,7 +10,7 @@ config_path = @config_path@ search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) $(top_srcdir) \ $(top_srcdir)/../include -fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude +fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include vpath % $(strip $(search_path))
Re: [patch,libgomp] Make libgomp Fortran modules multilib-aware
On Tue, May 31, 2016 at 03:36:14PM +0200, FX wrote: > Richard, Jakub, or any global write maintainer: can I get a review on this > one-word patch? > > -- > > The attached patch allows libgomp to install its Fortran modules in the > correct multilib-aware directories, just like libgfortran does. > Without it, multilib Fortran OpenMP code using the modules fails to compile > because the modules are not found: > > $ gfortran -fopenmp a.f90 > $ gfortran -fopenmp a.f90 -m32 > a.f90:1:6: > > use omp_lib > 1 > Fatal Error: Can't open module file ‘omp_lib.mod’ for reading at (1): No such > file or directory > compilation terminated. Why? It should look for it first in 32/finclude, sure, but if not found, should fall back to finclude dir, where it is found. Does it differ between 32-bit and 64-bit compilation? > Bootstrapped and tested on x86_64-apple-darwin15. OK to commit? > 2016-05-03 Francois-Xavier Coudert > > PR libgomp/60670 > * Makefile.am: Make fincludedir multilib-aware. > * Makefile.in: Regenerate. > Index: libgomp/Makefile.am > === > --- libgomp/Makefile.am (revision 235843) > +++ libgomp/Makefile.am (working copy) > @@ -10,7 +10,7 @@ config_path = @config_path@ > search_path = $(addprefix $(top_srcdir)/config/, $(config_path)) > $(top_srcdir) \ > $(top_srcdir)/../include > > -fincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/finclude > +fincludedir = > $(libdir)/gcc/$(target_alias)/$(gcc_version)$(MULTISUBDIR)/finclude > libsubincludedir = $(libdir)/gcc/$(target_alias)/$(gcc_version)/include > > vpath % $(strip $(search_path)) Jakub
avr-gcc: incorrect first operand of a subreg? (PR71103)
Hi,
avr-gcc was crashing for below test case.
command line: avr-gcc -mmcu=atmega328p -O1 test.c
struct ResponseStruct{
unsigned char responseLength;
char *response;
};
static char response[5];
struct ResponseStruct something(){
struct ResponseStruct returnValue;
returnValue.responseLength = 5;
returnValue.response = response + 1;
return returnValue;
}
Output:
> test.c:12:1: error: unrecognizable insn:
> }
> ^
> (insn 6 5 7 2 (set (subreg:QI (reg:PSI 42 [ D.1499 ]) 1)
> (subreg:QI (const:HI (plus:HI (symbol_ref:HI ("response")
> [flags 0x2] )
> (const_int -1 [0x
> ]))) 0)) test.c:11 -1
> (nil))
> test.c:12:1: internal compiler error: in extract_insn, at
> recog.c:2287
> 0xd51195 _fatal_insn(char const*, rtx_def const*, char const*, int,
> char const*)
> /home/rudran/code/gcc/gcc/rtl-error.c:108
Source operand is a subreg which has const operand as first operand.
Subreg shall have pseudo, mem or hard registers as fist operand.
Ref: https://gcc.gnu.org/onlinedocs/gccint/Regs-and-Memory.html
For the reported case it has const expression. Isn't that incorrect?
validate_subreg doesn't seem to reject this case. How can we avoid such
case (avr target)?
Regards,
Pitchumani
Re: Please, take '-Wmisleading-indentation' out of -Wall
On Mon, May 30, 2016 at 3:15 PM, Patrick Palka wrote: > Though there are some inconsistencies regarding the inclusiveness of > -Wall seeing as neither -Woverlength-strings nor -Wempty-body are > enabled by -Wall even though they seemingly satisfy the criteria of > -Wall more readily than -Wmisleading-indentation does. We certainly don't want -Woverlength-strings in -Wall; that's a pedantic portability warning, not a warning about code that is probably incorrect. There's an open BZ about -Wempty-body, bug 52961. Jason
Re: [patch,libgomp] Make libgomp Fortran modules multilib-aware
> Why? It should look for it first in 32/finclude, sure, but if not found, > should fall back to finclude dir, where it is found. > Does it differ between 32-bit and 64-bit compilation? Module files are target- and ABI-dependent and can differ between multilibs. Thus gfortran only looks for intrinsic .mod files in the 32/finclude, and not the parent. This was the design choice made when we introduced them (the driver passes the one and only valid finclude directory to the compiler through the -fintrinsic-modules-path option.) So, the best practice is for libgomp to store its .mod files into the multilib-specific finclude directory, just like libgfortran does. FX
Re: (R5900) Implementing Vector Support
On 05/29/2016 12:59 AM, Woon yung Liu wrote: Hi Richard, I have solved the problems with the mulv8hi3 pattern; I needed to adjust the code within mips.c to allow the double-sized vector modes and to allow vector modes into the LO+HI accumulators. Yes, I should have mentioned that you would need to do that. What is the correct way to change the mode of registers? For example, I am doing this to change the mode for a register to V4SI within an expand: reg = gen_rtx_REG(V4SImode, REGNO (reg)); This is almost always incorrect, and certainly before reload. You need to use gen_lowpart. There are examples in the code fragments that I sent the other week. Finally, what is the difference between define_expand and define_insn_and_split? When should I ever use define_insn_and_split? You need to read the gcc internals documentation. They are all three different uses, though there is some overlap between define_insn and define_expand. Are define_insn_and_split patterns used to avoid pseudo registers? No. r~
