summaryrefslogtreecommitdiff
path: root/libcpp
Commit message (Collapse)AuthorAgeFilesLines
* Daily bump.GCC Administrator2021-08-181-0/+17
|
* c++: Add C++20 #__VA_OPT__ supportJakub Jelinek2021-08-171-15/+73
| | | | | | | | | | | | | | | | | | | | | | | | | | | | The following patch implements C++20 # __VA_OPT__ (...) support. Testcases cover what I came up with myself and what LLVM has for #__VA_OPT__ in its testsuite and the string literals are identical between the two compilers on the va-opt-5.c testcase. 2021-08-17 Jakub Jelinek <jakub@redhat.com> libcpp/ * macro.c (vaopt_state): Add m_stringify member. (vaopt_state::vaopt_state): Initialize it. (vaopt_state::update): Overwrite it. (vaopt_state::stringify): New method. (stringify_arg): Replace arg argument with first, count arguments and add va_opt argument. Use first instead of arg->first and count instead of arg->count, for va_opt add paste_tokens handling. (paste_tokens): Fix up len calculation. Don't spell rhs twice, instead use %.*s to supply lhs and rhs spelling lengths. Don't call _cpp_backup_tokens here. (paste_all_tokens): Call it here instead. (replace_args): Adjust stringify_arg caller. For vaopt_state::END if stringify is true handle __VA_OPT__ stringification. (create_iso_definition): Handle # __VA_OPT__ similarly to # macro_arg. gcc/testsuite/ * c-c++-common/cpp/va-opt-5.c: New test. * c-c++-common/cpp/va-opt-6.c: New test.
* Daily bump.GCC Administrator2021-08-171-0/+4
|
* Update cpplib de.poJoseph Myers2021-08-161-33/+18
| | | | * de.po: Update.
* Daily bump.GCC Administrator2021-08-131-0/+6
|
* libcpp: Fix ICE with -Wtraditional preprocessing [PR101638]Jakub Jelinek2021-08-121-2/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following testcase ICEs in cpp_sys_macro_p, because cpp_sys_macro_p is called for a builtin macro which doesn't use node->value.macro union member but a different one and so dereferencing it ICEs. As the testcase is distilled from contemporary glibc headers, it means basically -Wtraditional now ICEs on almost everything. The fix can be either the patch below, return true for builtin macros, or we could instead return false for builtin macros, or the fix could be also (untested): --- libcpp/expr.c 2021-05-07 10:34:46.345122608 +0200 +++ libcpp/expr.c 2021-08-12 09:54:01.837556365 +0200 @@ -783,13 +783,13 @@ cpp_classify_number (cpp_reader *pfile, /* Traditional C only accepted the 'L' suffix. Suppress warning about 'LL' with -Wno-long-long. */ - if (CPP_WTRADITIONAL (pfile) && ! cpp_sys_macro_p (pfile)) + if (CPP_WTRADITIONAL (pfile)) { int u_or_i = (result & (CPP_N_UNSIGNED|CPP_N_IMAGINARY)); int large = (result & CPP_N_WIDTH) == CPP_N_LARGE && CPP_OPTION (pfile, cpp_warn_long_long); - if (u_or_i || large) + if ((u_or_i || large) && ! cpp_sys_macro_p (pfile)) cpp_warning_with_line (pfile, large ? CPP_W_LONG_LONG : CPP_W_TRADITIONAL, virtual_location, 0, "traditional C rejects the \"%.*s\" suffix", The builtin macros at least currently don't add any suffixes or numbers -Wtraditional would like to warn about. For floating point suffixes, -Wtraditional calls cpp_sys_macro_p only right away before emitting the warning, but in the above case the ICE is because cpp_sys_macro_p is called even if the number doesn't have any suffixes (that is I think always for builtin macros right now). 2021-08-12 Jakub Jelinek <jakub@redhat.com> PR preprocessor/101638 * macro.c (cpp_sys_macro_p): Return true instead of crashing on builtin macros. * gcc.dg/cpp/pr101638.c: New test.
* Daily bump.GCC Administrator2021-08-061-0/+11
|
* libcpp: Regenerate ucnid.h using Unicode 13.0.0 files [PR100977]Jakub Jelinek2021-08-051-11/+229
| | | | | | | | | | The following patch (incremental to the makeucnid.c fix) regenerates ucnid.h with https://www.unicode.org/Public/13.0.0/ucd/ files. 2021-08-05 Jakub Jelinek <jakub@redhat.com> PR c++/100977 * ucnid.h: Regenerated using Unicode 13.0.0 files.
* libcpp: Fix makeucnid bug with combining values [PR100977]Jakub Jelinek2021-08-052-346/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've noticed in ucnid.h two adjacent lines that had all flags and combine values identical and as such were supposed to be merged. This is due to a bug in makeucnid.c, which records last_flag, last_combine and really_safe of what has just been printed, but because of a typo mishandles it for last_combine, always compares against the combining_value[0] which is 0. This has two effects on the table, one is that often the table is unnecessarily large, as for non-zero .combine every character has its own record instead of adjacent characters with the same flags and combine being merged. This means larger tables. The other is that sometimes the last char that has combine set doesn't actually have it in the tables, because the code is printing entries only upon seeing the next character and if that character does have combining_value of 0 and flags are otherwise the same as previously printed, it will not print anything. The following patch fixes that, for clarity what exactly it affects I've regenerated with the same Unicode files as last time it has been regenerated. 2021-08-05 Jakub Jelinek <jakub@redhat.com> PR c++/100977 * makeucnid.c (write_table): Fix computation of last_combine. * ucnid.h: Regenerated using Unicode 6.3.0 files.
* Daily bump.GCC Administrator2021-07-271-0/+4
|
* Regenerate .pot files.Joseph Myers2021-07-261-180/+186
| | | | | | | | gcc/po/ * gcc.pot: Regenerate. libcpp/po/ * cpplib.pot: Regenerate.
* Daily bump.GCC Administrator2021-06-171-0/+7
|
* libcpp: location comparison within macro [PR100796]Jason Merrill2021-06-161-9/+11
| | | | | | | | | | | | | | | | | | | | | | The patch for 96391 changed linemap_compare_locations to give up on comparing locations from macro expansions if we don't have column information. But in this testcase, the BOILERPLATE macro is multiple lines long, so we do want to compare locations within the macro. So this patch moves the LINE_MAP_MAX_LOCATION_WITH_COLS check inside the block, to use it for failing gracefully. PR c++/100796 PR preprocessor/96391 libcpp/ChangeLog: * line-map.c (linemap_compare_locations): Only use comparison with LINE_MAP_MAX_LOCATION_WITH_COLS to avoid abort. gcc/testsuite/ChangeLog: * g++.dg/plugin/location-overflow-test-pr100796.c: New test. * g++.dg/plugin/plugin.exp: Run it.
* Daily bump.GCC Administrator2021-05-211-0/+14
|
* c: Add support for __FILE_NAME__ macro (PR c/42579)Christophe Lyon2021-05-203-4/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The toolchain provided by ST for stm32 has had support for __FILENAME__ for a while, but clang/llvm has recently implemented support for __FILE_NAME__, so it seems better to use the same macro name in GCC. It happens that the ST patch is similar to the one proposed in PR c/42579. Given these input files: :::::::::::::: mydir/myinc.h :::::::::::::: char* mystringh_file = __FILE__; char* mystringh_filename = __FILE_NAME__; char* mystringh_base_file = __BASE_FILE__; :::::::::::::: mydir/mysrc.c :::::::::::::: char* mystring_file = __FILE__; char* mystring_filename = __FILE_NAME__; char* mystring_base_file = __BASE_FILE__; we produce: $ gcc mydir/mysrc.c -I . -E char* mystringh_file = "./mydir/myinc.h"; char* mystringh_filename = "myinc.h"; char* mystringh_base_file = "mydir/mysrc.c"; char* mystring_file = "mydir/mysrc.c"; char* mystring_filename = "mysrc.c"; char* mystring_base_file = "mydir/mysrc.c"; 2021-05-20 Christophe Lyon <christophe.lyon@linaro.org> Torbjörn Svensson <torbjorn.svensson@st.com> PR c/42579 libcpp/ * include/cpplib.h (cpp_builtin_type): Add BT_FILE_NAME entry. * init.c (builtin_array): Likewise. * macro.c (_cpp_builtin_macro_text): Add support for BT_FILE_NAME. gcc/ * doc/cpp.texi (Common Predefined Macros): Document __FILE_NAME__. gcc/testsuite/ * c-c++-common/spellcheck-reserved.c: Add tests for __FILE_NAME__. * c-c++-common/cpp/file-name-1.c: New test.
* libcpp: Fix up -fdirectives-only handling of // comments on last line not ↵Jakub Jelinek2021-05-201-2/+3
| | | | | | | | | | | | | | | | | | terminated with newline [PR100646] As can be seen on the testcases, before the -fdirectives-only preprocessing rewrite the preprocessor would assume // comments are terminated by the end of file even when newline wasn't there, but now we error out. The following patch restores the previous behavior. 2021-05-20 Jakub Jelinek <jakub@redhat.com> PR preprocessor/100646 * lex.c (cpp_directive_only_process): Treat end of file as termination for !is_block comments. * gcc.dg/cpp/pr100646-1.c: New test. * gcc.dg/cpp/pr100646-2.c: New test.
* Daily bump.GCC Administrator2021-05-131-0/+7
|
* libcpp: Fix up -fdirectives-only preprocessing of includes not ending with ↵Jakub Jelinek2021-05-121-1/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | newline [PR100392] If a header doesn't end with a new-line, with -fdirectives-only we right now preprocess it as int i = 1;# 2 "pr100392.c" 2 i.e. the line directive isn't on the next line, which means we fail to parse it when compiling. GCC 10 and earlier libcpp/directives-only.c had for this: if (!pfile->state.skipping && cur != base) { /* If the file was not newline terminated, add rlimit, which is guaranteed to point to a newline, to the end of our range. */ if (cur[-1] != '\n') { cur++; CPP_INCREMENT_LINE (pfile, 0); lines++; } cb->print_lines (lines, base, cur - base); } and we have the assertion /* Files always end in a newline or carriage return. We rely on this for character peeking safety. */ gcc_assert (buffer->rlimit[0] == '\n' || buffer->rlimit[0] == '\r'); So, this patch just does readd the more less same thing, so that we emit a newline after the inline even when it wasn't there before. 2021-05-12 Jakub Jelinek <jakub@redhat.com> PR preprocessor/100392 * lex.c (cpp_directive_only_process): If buffer doesn't end with '\n', add buffer->rlimit[0] character to the printed range and CPP_INCREMENT_LINE and increment line_count. * gcc.dg/cpp/pr100392.c: New test. * gcc.dg/cpp/pr100392.h: New file.
* Daily bump.GCC Administrator2021-05-121-0/+24
|
* preprocessor: Support C2X #elifdef, #elifndefJoseph Myers2021-05-113-35/+88
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | C2X adds #elifdef and #elifndef preprocessor directives; these have also been proposed for C++. Implement these directives in libcpp accordingly. In this implementation, #elifdef and #elifndef are treated as non-directives for any language version other than c2x and gnu2x (if the feature is accepted for C++, it can trivially be enabled for relevant C++ versions). In strict conformance modes for prior language versions, this is required, as illustrated by the c11-elifdef-1.c test added. Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ * include/cpplib.h (struct cpp_options): Add elifdef. * init.c (struct lang_flags): Add elifdef. (lang_defaults): Update to include elifdef initializers. (cpp_set_lang): Set elifdef for pfile based on language. * directives.c (STDC2X, ELIFDEF): New macros. (EXTENSION): Increase value to 3. (DIRECTIVE_TABLE): Add #elifdef and #elifndef. (_cpp_handle_directive): Do not treat ELIFDEF directives as directives for language versions without the #elifdef feature. (do_elif): Handle #elifdef and #elifndef. (do_elifdef, do_elifndef): New functions. gcc/testsuite/ * gcc.dg/cpp/c11-elifdef-1.c, gcc.dg/cpp/c2x-elifdef-1.c, gcc.dg/cpp/c2x-elifdef-2.c: New tests.
* preprocessor: Fix cpp_avoid_paste for digit separatorsJoseph Myers2021-05-111-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The libcpp function cpp_avoid_paste is used to insert whitespace in preprocessed output where needed to avoid two consecutive preprocessing tokens, that logically (e.g. when stringized) do not have whitespace between them, from being incorrectly lexed as one when the preprocessed input is reread by a compiler. This fails to allow for digit separators, so meaning that invalid code, that has a CPP_NUMBER (from a macro expansion) followed by a character literal, can result in preprocessed output with a valid use of digit separators, so that required syntax errors do not occur when compiling with -save-temps. Fix this by handling that case in cpp_avoid_paste (as with other cases in cpp_avoid_paste, this doesn't try to check whether the language version in use supports digit separators; it's always OK to have unnecessary whitespace in preprocessed output). Note: there are other cases, with various kinds of wide character or string literal following a CPP_NUMBER, where spurious pasting of preprocessing tokens can occur but the sequence of tokens remains invalid both before and after that pasting. Maybe cpp_avoid_paste should also handle those cases (and similar cases after a CPP_NAME), to ensure the sequence of preprocessing tokens in preprocessed output is exactly right, whether or not it affects whether syntax errors occur. This patch only addresses the case with digit separators where invalid code can fail to be diagnosed without the space inserted. Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ * lex.c (cpp_avoid_paste): Do not allow pasting CPP_NUMBER with CPP_CHAR. gcc/testsuite/ * g++.dg/cpp1y/digit-sep-paste.C, gcc.dg/c2x-digit-separators-3.c: New tests.
* preprocessor: Enable digit separators for C2XJoseph Myers2021-05-111-2/+2
| | | | | | | | | | | | | | | | | | | | | | C2X adds digit separators, as in C++. Enable them accordingly in libcpp and c-lex.c. Some basic tests are added that digit separators behave as expected for C2X and are properly disabled for C11; further test coverage is included in the existing g++.dg/cpp1y/digit-sep*.C tests. Bootstrapped with no regressions for x86_64-pc-linux-gnu. gcc/c-family/ * c-lex.c (interpret_float): Handle digit separators for C2X. libcpp/ * init.c (lang_defaults): Enable digit separators for GNUC2X and STDC2X. gcc/testsuite/ * gcc.dg/c11-digit-separators-1.c, gcc.dg/c2x-digit-separators-1.c, gcc.dg/c2x-digit-separators-2.c: New tests.
* Daily bump.GCC Administrator2021-05-081-0/+5
|
* libcpp: Fix up pragma preprocessing [PR100450]Jakub Jelinek2021-05-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the r0-85991-ga25a8f3be322fe0f838947b679f73d6efc2a412c https://gcc.gnu.org/legacy-ml/gcc-patches/2008-02/msg01329.html changes, so that we handle macros inside of pragmas that should expand macros, during preprocessing we print those pragmas token by token, with CPP_PRAGMA printed as fputs ("#pragma ", print.outf); if (space) fprintf (print.outf, "%s %s", space, name); else fprintf (print.outf, "%s", name); where name is some identifier (so e.g. print #pragma omp parallel or #pragma omp for etc.). Because it ends in an identifier, we need to handle it like an identifier (i.e. CPP_NAME) for the decision whether a space needs to be emitted in between that #pragma whatever or #pragma whatever whatever and following token, otherwise the attached testcase is preprocessed as #pragma omp forreduction(+:red) rather than #pragma omp for reduction(+:red) The cpp_avoid_paste function is only called for this purpose. 2021-05-07 Jakub Jelinek <jakub@redhat.com> PR c/100450 * lex.c (cpp_avoid_paste): Handle token1 CPP_PRAGMA like CPP_NAME. * c-c++-common/gomp/pr100450.c: New test.
* Daily bump.GCC Administrator2021-05-071-0/+9
|
* preprocessor: Fix pp-number lexing of digit separators [PR83873, PR97604]Joseph Myers2021-05-062-7/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When the preprocessor lexes preprocessing numbers in lex_number, it accepts digit separators in more cases than actually permitted in pp-numbers by the standard syntax. One thing this accepts is adjacent digit separators; there is some code to reject those later, but as noted in bug 83873 it fails to cover the case of adjacent digit separators within a floating-point exponent. Accepting adjacent digit separators only results in a missing diagnostic, not in valid code being rejected or being accepted with incorrect semantics, because the correct lexing in such a case would have '' start the following preprocessing tokens, and no valid preprocessing token starts '' while ' isn't valid on its own as a preprocessing token either. So this patch fixes that case by moving the error for adjacent digit separators to lex_number (allowing a more specific diagnostic than if '' were excluded from the pp-number completely). Other cases inappropriately accepted involve digit separators before '.', 'e+', 'e-', 'p+' or 'p-' (or corresponding uppercase variants). In those cases, as shown by the test digit-sep-pp-number.C added, this can result in valid code being wrongly rejected as a result of too many characters being included in the pp-number. So this case is fixed by terminating the pp-number at the correct character according to the standard. That test also covers the case where a digit separator was followed by an identifier-nondigit that is not a nondigit (e.g. a UCN); that case was already handled correctly. Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ PR c++/83873 PR preprocessor/97604 * lex.c (lex_number): Reject adjacent digit separators here. Do not allow digit separators before '.' or an exponent with sign. * expr.c (cpp_classify_number): Do not check for adjacent digit separators here. gcc/testsuite/ PR c++/83873 PR preprocessor/97604 * g++.dg/cpp1y/digit-sep-neg-2.C, g++.dg/cpp1y/digit-sep-pp-number.C: New tests. * g++.dg/cpp1y/digit-sep-line-neg.C, g++.dg/cpp1y/digit-sep-neg.C: Adjust expected messages.
* Daily bump.GCC Administrator2021-05-041-0/+5
|
* GCC_CET_HOST_FLAGS: Check if host supports multi-byte NOPsH.J. Lu2021-05-031-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Check if host supports multi-byte NOPs before enabling CET on host. gcc/ PR bootstrap/99703 * configure: Regenerated. libbacktrace/ PR bootstrap/99703 * configure: Regenerated. libcc1/ PR bootstrap/99703 * configure: Regenerated. libcpp/ PR bootstrap/99703 * configure: Regenerated. libdecnumber/ PR bootstrap/99703 * configure: Regenerated. lto-plugin/ PR bootstrap/99703 * configure: Regenerated.
* Daily bump.GCC Administrator2021-04-301-0/+5
|
* preprocessor: Handle digit separators in #line [PR82359]Joseph Myers2021-04-291-0/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As reported in bug 82359, the preprocessor does not allow C++ digit separators in the line number in a #line directive, despite the standard syntax for that directive using digit-sequence which allows digit separators. There is some confusion in that bug about whether C++ is meant to allow digit separators there or not, but the last comment there suggests they are meant to be allowed, and the version of digit separators accepted for C2X at the March meeting explicitly mentions digit separators in the #line specification to avoid any ambiguity there. This patch thus adds code to handle digit separators in the line number in #line, as part of the preparation for enabling digit separators in C2X mode. The code changed does not contain any conditionals for whether digit separators are supported in the chosen language version, because that was handled earlier in pp-number lexing and if they aren't supported they won't appear in the string passed to that function. It does however make sure not to allow adjacent digit separators because those are only handled at a later stage of lexing at present. (Problems with how certain source character sequences involving digit separators that don't actually match the pp-number syntax get lexed as a pp-number and only diagnosed later, if at all, are bugs 83873 and 97604, to be addressed separately.) Making the change in this location will have the effect of allowing digit separators in the "# <line-number> <file> <flags>" form of directive as well as #line; I don't think that's a problem. Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ PR preprocessor/82359 * directives.c (strtolinenum): Handle digit separators. gcc/testsuite/ PR preprocessor/82359 * g++.dg/cpp1y/digit-sep-line.C, g++.dg/cpp1y/digit-sep-line-neg.C: New tests.
* Daily bump.GCC Administrator2021-04-201-0/+6
|
* preprocessor/100142 - revert unwanted change in last commitRichard Biener2021-04-191-1/+1
| | | | | | | | | | | | | | | This reverts a s/column_offset/column/ change in the fix for PR99446. 2021-04-19 Richard Biener <rguenther@suse.de> PR preprocessor/100142 libcpp/ * line-map.c (linemap_position_for_loc_and_offset): Revert unintended s/column_offset/column/ change. gcc/testsuite/ * gcc.dg/pr100142.c: New testcase. * g++.dg/diagnostic/pr72803.C: Revert last change.
* Daily bump.GCC Administrator2021-04-141-0/+12
|
* preprocessor: Fix column adjustment [PR 99446]Nathan Sidwell2021-04-131-10/+9
| | | | | | | | | | | | | | | | This ICE was because when adjusting a column offset we could advance into a linemap for a different file. We only checked the next line map was not for a line further advanced in any file, forgetting that it could be for an earlier line in a different file. The testcase needed adjusting as column 512 was unrepresentable, once that was taken into consideration. PR preprocessor/99446 libcpp/ * line-map.c (line-map.c): Do not advance to linemaps for different files. gcc/testsuite/ * g++.dg/diagnostic/pr72803.C: Adjust expected column.
* Fix thinko in libcpp preparation patch for modulesEric Botcazou2021-04-132-8/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The problem is that the new IS_MACRO_LOC macro: inline bool IS_MACRO_LOC (location_t loc) { return !IS_ORDINARY_LOC (loc) && !IS_ADHOC_LOC (loc); } is not fully correct since the position of the macro lines is not fixed: /* Returns the lowest location [of a token resulting from macro expansion] encoded in this line table. */ inline location_t LINEMAPS_MACRO_LOWEST_LOCATION (const line_maps *set) { return LINEMAPS_MACRO_USED (set) ? MAP_START_LOCATION (LINEMAPS_LAST_MACRO_MAP (set)) : MAX_LOCATION_T + 1; } In Ada, LINEMAPS_MACRO_USED is false so LINEMAPS_MACRO_LOWEST_LOCATION is MAX_LOCATION_T + 1, but IS_MACRO_LOC nevertheless returns true for anything in the range [LINE_MAP_MAX_LOCATION; MAX_LOCATION_T], thus yielding an ICE in linemap_macro_map_lookup for very large files. libcpp/ * include/line-map.h (IS_MACRO_LOC): Delete. * line-map.c (linemap_location_from_macro_expansion_p): Test LINEMAPS_MACRO_LOWEST_LOCATION of the linemap. gcc/cp/ * module.cc (ordinary_loc_of): Test LINEMAPS_MACRO_LOWEST_LOCATION of the linemap. (module_state::write_location): Likewise.
* Daily bump.GCC Administrator2021-03-301-0/+4
|
* Update cpplib sr.po.Joseph Myers2021-03-291-30/+14
| | | | * sr.po: Update.
* Daily bump.GCC Administrator2021-03-091-0/+4
|
* Update cpplib eo.po.Joseph Myers2021-03-081-32/+17
| | | | * eo.po: Update.
* Daily bump.GCC Administrator2021-03-031-0/+6
|
* diagnostics: fix ICE on fix-it hints on very long lines [PR99323]David Malcolm2021-03-021-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | PR c/99323 describes an ICE due to a failed assertion deep inside the fix-it printing machinery, where the fix-it hints on one line have not been properly sorted in layout's constructor. The underlying issue occurs when multiple fix-it hints affect a line wider that LINE_MAP_MAX_COLUMN_NUMBER, where the location_t values for characters after that threshold fall back to having column zero. It's not meaningful to try to handle fix-it hints without column information, so this patch rejects them as they are added to the rich_location, falling back to the "no fix-it hints on this diagnostic" case, fixing the crash. gcc/ChangeLog: PR c/99323 * diagnostic-show-locus.c (selftest::test_one_liner_many_fixits_2): Fix accidental usage of column 0. gcc/testsuite/ChangeLog: PR c/99323 * gcc.dg/pr99323-1.c: New test. * gcc.dg/pr99323-2.c: New test. libcpp/ChangeLog: PR c/99323 * line-map.c (rich_location::maybe_add_fixit): Reject fix-it hints at column 0.
* Daily bump.GCC Administrator2021-02-251-0/+12
|
* c++: Macro location fixes [PR 98718]Nathan Sidwell2021-02-242-18/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes some issues with macro maps. We were incorrectly calculating the number of macro expansions in a location span, and I had a workaround that partially covered that up. Further, while macro location spans are monotonic, that is not true of ordinary location spans. Thus we need to insert an indirection array when binary searching the latter. (We load ordinary locations before loading imports, but macro locations afterwards. We make sure an import location is de-macrofied, if needed.) PR c++/98718 gcc/cp/ * module.cc (ool): New indirection vector. (loc_spans::maybe_propagate): Location is not optional. (loc_spans::open): Likewise. Assert monotonically advancing. (module_for_ordinary_loc): Use ool indirection vector. (module_state::write_prepare_maps): Do not count empty macro expansions. Elide empty spans. (module_state::write_macro_maps): Skip empty expansions. (ool_cmp): New qsort comparator. (module_state::write): Create and destroy ool vector. (name_pending_imports): Fix dump push/pop. (preprocess_module): Likewise. Add more dumping. (preprocessed_module): Likewise. libcpp/ * include/line-map.h * line-map.c gcc/testsuite/ * g++.dg/modules/pr98718_a.C: New. * g++.dg/modules/pr98718_b.C: New.
* c++: modules & -fpreprocessed [PR 99072]Nathan Sidwell2021-02-241-0/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we read preprocessed source, we deal with a couple of special location lines at the start of the file. These provide information about the original filename of the source and the current directory, so we can process the source in the same manner. When updating that code, I had a somewhat philosophical question: Should the line table contain evidence of the filename the user provided to the compiler? I figured to leave it there, as it did no harm. But this defect shows an issue. It's in the line table and our (non optimizing) line table serializer emits that filename. Which means if one re-preprocesses the original source to a differently-named intermediate file, the resultant CMI is different. Boo. That's a difference that doesn't matter, except the CRC matching then fails. We should elide the filename, so that one can preprocess to mktemp intermediate filenames for whatever reason. This patch takes the approach of expunging it from the line table -- so the line table will end up with exactly the same form. That seems a better bet than trying to fix up mismatching line tables in CMI emission. PR c++/99072 libcpp/ * init.c (read_original_filename): Expunge all evidence of the original filename. gcc/testsuite/ * g++.dg/modules/pr99072.H: New.
* Daily bump.GCC Administrator2021-02-201-0/+6
|
* Update .po files.Joseph Myers2021-02-1921-4048/+4867
| | | | | | | | | | | | gcc/po/ * be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po, ja.po, nl.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po, zh_TW.po: Update. libcpp/po/ * be.po, ca.po, da.po, de.po, el.po, eo.po, es.po, fi.po, fr.po, id.po, ja.po, nl.po, pt_BR.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po, zh_TW.po: Update.
* Daily bump.GCC Administrator2021-02-191-0/+12
|
* c++: header-unit build capability [PR 99023]Nathan Sidwell2021-02-184-21/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This defect really required building header-units and include translation of pieces of the standard library. This adds smarts to the modules test harness to do that -- accept .X files as the source file, but provide '-x c++-system-header $HDR' in the options. The .X file will be considered by the driver to be a linker script and ignored (with a warning). Using this we can add 2 tests that end up building list_initializer and iostream, along with a test that iostream's build include-translates list_initializer's #include. That discovered a set of issues with the -flang-info-include-translate=HDR handling, also fixed and documented here. PR c++/99023 gcc/cp/ * module.cc (canonicalize_header_name): Use cpp_probe_header_unit. (maybe_translate_include): Fix note_includes comparison. (init_modules): Fix note_includes string termination. libcpp/ * include/cpplib.h (cpp_find_header_unit): Rename to ... (cpp_probe_header_unit): ... this. * internal.h (_cp_find_header_unit): Declare. * files.c (cpp_find_header_unit): Break apart to .. (test_header_unit): ... this, and ... (_cpp_find_header_unit): ... and, or and ... (cpp_probe_header_unit): ... this. * macro.c (cpp_get_token_1): Call _cpp_find_header_unit. gcc/ * doc/invoke.texi (flang-info-include-translate): Document header lookup behaviour. gcc/testsuite/ * g++.dg/modules/modules.exp: Bail on cross-testing. Add support for .X files. * g++.dg/modules/pr99023_a.X: New. * g++.dg/modules/pr99023_b.X: New.
* Daily bump.GCC Administrator2021-02-171-0/+4
|
* c++: directives-only preprocessing and include translation [PR 99050]Nathan Sidwell2021-02-161-3/+7
| | | | | | | | | | | | | We make sure files end in \n by placing one at the limit of the buffer (just past the end of what is read). We need to do the same for buffers generated via include-translation. Fortunately they have space. libcpp/ * files.c (_cpp_stack_file): Make buffers end in unread \n. gcc/testsuite/ * g++.dg/modules/pr99050_a.H: New. * g++.dg/modules/pr99050_b.C: New.
View Lorry Controller Status