git tag for gcc 7.4
I don't see a gcc-7_4_0-release tag in the git mirror. Is that intentional? Rasmus
Re: git tag for gcc 7.4
On Tue, 8 Jan 2019 at 13:16, Rasmus Villemoes wrote: > > I don't see a gcc-7_4_0-release tag in the git mirror. Is that intentional? Tags have to be manually added to the git mirror, they don't happen as part of the release process. I've added it now.
Re: git tag for gcc 7.4
On 08/01/2019 14.28, Jonathan Wakely wrote: > On Tue, 8 Jan 2019 at 13:16, Rasmus Villemoes wrote: >> >> I don't see a gcc-7_4_0-release tag in the git mirror. Is that intentional? > > Tags have to be manually added to the git mirror, they don't happen as > part of the release process. > > I've added it now. > Thanks :)
Re: Improve syntax error
Ping
Den lör 5 jan. 2019 kl 20:44 skrev Daniel Marjamäki
:
>
> Here is a new patch with fixed comments and indentation
>
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 972b629c092..294ff34fe55 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -171,6 +171,8 @@ struct GTY(()) c_parser {
>/* How many look-ahead tokens are available (0 - 4, or
> more if parsing from pre-lexed tokens). */
>unsigned int tokens_avail;
> + /* Nesting depth in expression (parentheses / squares). */
> + unsigned int nesting_depth;
>/* True if a syntax error is being recovered from; false otherwise.
> c_parser_error sets this flag. It should clear this flag when
> enough tokens have been consumed to recover from the error. */
> @@ -763,6 +765,22 @@ c_parser_next_tokens_start_declaration (c_parser *parser)
>return false;
> }
>
> +/* Nesting start token. */
> +
> +static bool c_parser_is_nesting_start (c_parser *parser)
> +{
> + return c_parser_next_token_is (parser, CPP_OPEN_PAREN) ||
> + c_parser_next_token_is (parser, CPP_OPEN_SQUARE);
> +}
> +
> +/* Nesting end token. */
> +
> +static bool c_parser_is_nesting_end (c_parser *parser)
> +{
> + return c_parser_next_token_is (parser, CPP_CLOSE_PAREN) ||
> + c_parser_next_token_is (parser, CPP_CLOSE_SQUARE);
> +}
> +
> /* Consume the next token from PARSER. */
>
> void
> @@ -772,6 +790,10 @@ c_parser_consume_token (c_parser *parser)
>gcc_assert (parser->tokens[0].type != CPP_EOF);
>gcc_assert (!parser->in_pragma || parser->tokens[0].type !=
> CPP_PRAGMA_EOL);
>gcc_assert (parser->error || parser->tokens[0].type != CPP_PRAGMA);
> + if (c_parser_is_nesting_start (parser))
> +parser->nesting_depth++;
> + else if (parser->nesting_depth > 0 && c_parser_is_nesting_end (parser))
> +parser->nesting_depth--;
>parser->last_token_location = parser->tokens[0].location;
>if (parser->tokens != &parser->tokens_buf[0])
> parser->tokens++;
> @@ -1673,6 +1695,20 @@ add_debug_begin_stmt (location_t loc)
>add_stmt (stmt);
> }
>
> +static bool c_parser_unmatched_p (c_parser *parser)
> +{
> + if (c_parser_is_nesting_end (parser))
> +return parser->nesting_depth == 0;
> + return false;
> +}
> +
> +static void complain_about_unmatched_token (c_parser *parser)
> +{
> + c_token *token = c_parser_peek_token (parser);
> + error_at (token->location, "unmatched %qs",
> +cpp_type2name (token->type, token->flags));
> +}
> +
> /* Parse a declaration or function definition (C90 6.5, 6.7.1, C99
> 6.7, 6.9.1, C11 6.7, 6.9.1). If FNDEF_OK is true, a function definition
> is accepted; otherwise (old-style parameter declarations) only other
> @@ -2228,7 +2264,10 @@ c_parser_declaration_or_fndef (c_parser
> *parser, bool fndef_ok,
> }
>else
> {
> - c_parser_error (parser, "expected %<,%> or %<;%>");
> + if (c_parser_unmatched_p (parser))
> +complain_about_unmatched_token (parser);
> + else
> +c_parser_error (parser, "expected %<,%> or %<;%>");
>c_parser_skip_to_end_of_block_or_statement (parser);
>return;
> }
> diff --git a/gcc/testsuite/gcc.dg/unmatched.c
> b/gcc/testsuite/gcc.dg/unmatched.c
> new file mode 100644
> index 000..bd458a01109
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/unmatched.c
> @@ -0,0 +1,19 @@
> +
> +/* { dg-do compile } */
> +
> +void f1() {
> + int a = 0)+3; /* { dg-error "unmatched" } */
> +}
> +
> +void f2() {
> + int b = (1]+3; /* { dg-error "expected" } */
> +}
> +
> +void f3() {
> + int b = 1]+3; /* { dg-error "unmatched" } */
> +}
> +
> +void f4() {
> + int c = (1))+3; /* { dg-error "unmatched" } */
> +}
> +
>
> Den lör 5 jan. 2019 kl 18:02 skrev Daniel Marjamäki
> :
> >
> > Thanks!
> >
> > I will take care of the indentation and fix the comment.
> >
> > > I think the indentation warnings should catch that?
> >
> > I get this:
> >
> > void f()
> > {
> > }
> > } // <- error: expected identifier or '(' before '}' token
> >
> > I ran with -Wall -Wextra -pedantic and did not see a indentation
> > warning. Am I missing some indentation warning? The error message I
> > get is a little misplaced. I think it's fine to warn about that } but
> > it could also say in the error message that the problem is probably
> > the previous }
> >
> > > Should this say something like "expected ) or , or ;"?
> >
> > No none of those suggestions will solve the error.
> >
> > Look at this code:
> >
> > int x = 3) + 0;
> >
> > Writing a ) or , or ; will not fix the syntax error. You have to
> > remove the ) or add a ( somewhere.
> >
> >
> >
> > Den lör 5 jan. 2019 kl 09:50 skrev Segher Boessenkool
> > :
> > >
> > > Hi Daniel,
> > >
> > > Some mostly boring comments:
> > >
> > > On Fri, Jan 04, 2019 at 09:25:10PM +0100, Daniel Marjamäki wrote:
> > > > The first reason is the hard problem, but maybe we can ignore this now
> > > > also:
> > > >
> > >
Re: Improve syntax error
On Tue, 8 Jan 2019, Daniel Marjamäki wrote: > Ping New features should be submitted in development stage 1; we're in regression-fixes-only mode at present so new features will not receive attention until probably April or May. When submitting a revised patch, please make sure each patch submission email is fully self-contained, with a full explanation of that version of the patch suitable for a git-style commit message (in addition to any description of changes relative to a previous patch version, which would not go in such a commit message). Rather than picking just one place there might be an unmatched close-parenthesis token, it would seem better to me to make the general logic printing errors for any unexpected token use different wording in the case where the unexpected token is an unmatched parenthesis (and make sure such wording is consistent between C and C++). I.e., it would be c_parser_error_richloc / C++ equivalents that would change. Note that c_parser_error_richloc has existing smarts to give a different diagnostic in the case of version control conflict markers in a source file, which is a strong indication it's the right place for other smarts relating to better diagnostics for particular unexpected tokens. Please note GNU Coding Standards formatting (for example, split lines before binary operators, not after them). -- Joseph S. Myers jos...@codesourcery.com
[RFC] moving assemble_start_function / assemble_end_function to output_mi_thunk
Hello, I'm implementing MI thunk generation for the xtensa target and I've got an issue that when my code generates a constant it is missing in the resulting assembly. This happens because a constant pool output happens inside the assemble_start_function, which is called before the thunk function body has a chance to be generated. The following patch moves assemble_start_function / assemble_end_function pair to the backend for all targets that define TARGET_ASM_OUTPUT_MI_THUNK to allow calling assemble_start_function after the function body is ready. Is it OK, or should I try to fix it differently? ---8<--- >From bad901880a3f9fc69726aa082e2b2c674bacca94 Mon Sep 17 00:00:00 2001 From: Max Filippov Date: Mon, 7 Jan 2019 18:22:12 -0800 Subject: [PATCH] gcc: move assemble_start_function / assemble_end_function to output_mi_thunk Let backends call assemble_start_function after they have generated thunk function body so that a constant pool could be output if it is required. gcc/ 2019-01-08 Max Filippov * cgraphunit.c (cgraph_node::expand_thunk): Remove assemble_start_function and assemble_end_function calls. * config/alpha/alpha.c (alpha_output_mi_thunk_osf): Call assemble_start_function and assemble_end_function. * config/arc/arc.c (arc_output_mi_thunk): Likewise. * config/arm/arm.c (arm_output_mi_thunk): Likewise. * config/bfin/bfin.c (bfin_output_mi_thunk): Likewise. * config/c6x/c6x.c (c6x_output_mi_thunk): Likewise. * config/cris/cris.c (cris_asm_output_mi_thunk): Likewise. * config/csky/csky.c (csky_output_mi_thunk): Likewise. * config/epiphany/epiphany.c (epiphany_output_mi_thunk): Likewise. * config/frv/frv.c (frv_asm_output_mi_thunk): Likewise. * config/i386/i386.c (x86_output_mi_thunk): Likewise. * config/ia64/ia64.c (ia64_output_mi_thunk): Likewise. * config/m68k/m68k.c (m68k_output_mi_thunk): Likewise. * config/microblaze/microblaze.c (microblaze_asm_output_mi_thunk): Likewise. * config/mips/mips.c (mips_output_mi_thunk): Likewise. * config/mmix/mmix.c (mmix_asm_output_mi_thunk): Likewise. * config/mn10300/mn10300.c (mn10300_asm_output_mi_thunk): Likewise. * config/nds32/nds32.c (nds32_asm_output_mi_thunk): Likewise. * config/nios2/nios2.c (nios2_asm_output_mi_thunk): Likewise. * config/or1k/or1k.c (or1k_output_mi_thunk): Likewise. * config/pa/pa.c (pa_asm_output_mi_thunk): Likewise. * config/riscv/riscv.c (riscv_output_mi_thunk): Likewise. * config/rs6000/rs6000.c (rs6000_output_mi_thunk): Likewise. * config/s390/s390.c (s390_output_mi_thunk): Likewise. * config/sh/sh.c (sh_output_mi_thunk): Likewise. * config/sparc/sparc.c (sparc_output_mi_thunk): Likewise. * config/spu/spu.c (spu_output_mi_thunk): Likewise. * config/stormy16/stormy16.c (xstormy16_asm_output_mi_thunk): Likewise. * config/tilegx/tilegx.c (tilegx_output_mi_thunk): Likewise. * config/tilepro/tilepro.c (tilepro_asm_output_mi_thunk): Likewise. * config/vax/vax.c (vax_output_mi_thunk): Likewise. --- gcc/cgraphunit.c | 4 gcc/config/alpha/alpha.c | 3 +++ gcc/config/arc/arc.c | 4 gcc/config/arm/arm.c | 4 gcc/config/bfin/bfin.c | 3 +++ gcc/config/c6x/c6x.c | 3 +++ gcc/config/cris/cris.c | 4 gcc/config/csky/csky.c | 3 +++ gcc/config/epiphany/epiphany.c | 3 +++ gcc/config/frv/frv.c | 4 gcc/config/i386/i386.c | 5 - gcc/config/ia64/ia64.c | 3 +++ gcc/config/m68k/m68k.c | 3 +++ gcc/config/microblaze/microblaze.c | 3 +++ gcc/config/mips/mips.c | 3 +++ gcc/config/mmix/mmix.c | 6 +- gcc/config/mn10300/mn10300.c | 3 +++ gcc/config/nds32/nds32.c | 3 +++ gcc/config/nios2/nios2.c | 3 +++ gcc/config/or1k/or1k.c | 5 - gcc/config/pa/pa.c | 3 +++ gcc/config/riscv/riscv.c | 3 +++ gcc/config/rs6000/rs6000.c | 3 +++ gcc/config/s390/s390.c | 3 +++ gcc/config/sh/sh.c | 3 +++ gcc/config/sparc/sparc.c | 3 +++ gcc/config/spu/spu.c | 3 +++ gcc/config/stormy16/stormy16.c | 3 +++ gcc/config/tilegx/tilegx.c | 3 +++ gcc/config/tilepro/tilepro.c | 3 +++ gcc/config/vax/vax.c | 4 31 files changed, 99 insertions(+), 7 deletions(-) diff --git a/gcc/cgraphunit.c b/gcc/cgraphunit.c index e6b1296abfb5..1c070ee95cd7 100644 --- a/gcc/cgraphunit.c +++ b/gcc/cgraphunit.c @@ -1786,7 +1786,6 @@ cgraph_node::expand_thunk (bool output_asm_thunks, bool force_gimple_thunk) && targetm.asm_out.can_output_mi_thunk (thunk_fndecl, fixed_offset, v
GNU MPFR 4.0.2 Release Candidate
The release of GNU MPFR 4.0.2 ("dinde aux marrons", patch level 2)
is imminent. Please help to make this release as good as possible
by downloading and testing this release candidate:
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.xz
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.bz2
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.gz
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.zip
The SHA1 digests:
c0b15940b703d55a05acdc61781962eb3d0bf857 mpfr-4.0.2-rc1.tar.bz2
fd4bc91650ad6cf549c9a036f036d62b26b47ac2 mpfr-4.0.2-rc1.tar.gz
535d06909eff58c8541250a222bd97a96aa5422c mpfr-4.0.2-rc1.tar.xz
3295000419ca52ebbbd17fdb889bbe7d3e7242bf mpfr-4.0.2-rc1.zip
The SHA256 digests:
60626832f47a51fe24dc366cadbf2157a085b62ac634526f0d03e5c987de59ae
mpfr-4.0.2-rc1.tar.bz2
58b561c76b30e9ef14961345d16e532bea89e08e3590b5394cd396b1c17a8ce7
mpfr-4.0.2-rc1.tar.gz
4fc4cee96878d2c947d488e8fc11b59877eb8d108c000634f39e6f3520ea04ea
mpfr-4.0.2-rc1.tar.xz
a3e4ec355db75c88a132e19d1bd3c3bcb72db23a0a21272a64fb8ac0da4e484f
mpfr-4.0.2-rc1.zip
The signatures:
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.xz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.bz2.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.tar.gz.asc
https://www.mpfr.org/mpfr-4.0.2/mpfr-4.0.2-rc1.zip.asc
Each tarball is signed by Vincent Lefèvre. This can be verified using
the DSA key ID 980C197698C3739D; this key can be retrieved with:
gpg --recv-keys 980C197698C3739D
or by downloading it from .
The key fingerprint is:
07F3 DBBE CC1A 3960 5078 094D 980C 1976 98C3 739D
The signatures can be verified with: gpg --verify
You should check that the key fingerprint matches.
Changes from version 4.0.1 to version 4.0.2:
- Corrected minimal GMP version in the INSTALL file and the MPFR manual.
- Improved MPFR manual. In particular, corrected/completed the
mpfr_get_str description in order to follow the historical behavior
and GMP's mpf_get_str function.
- Bug fixes (see ChangeLog file).
Please send success and failure reports with "./config.guess" output
to .
If no problems are found, GNU MPFR 4.0.2 should be released
around 2019-01-23.
Regards,
--
Vincent Lefèvre - Web:
