aboutsummaryrefslogtreecommitdiff
path: root/libcpp
AgeCommit message (Collapse)AuthorFilesLines
14 hourslibcpp: Use pedwarn instead of warning for CWG2578 diagnostics [PR120778]Jakub Jelinek1-1/+4
This is another case which changed from compile time undefined behavior to ill-formed, diagnostic required. Now, we warn on this, so pedantically that is good enough, maybe all we need is a testcase, but the following patch changes it to a pedwarn for C++26. 2025-08-04 Jakub Jelinek <jakub@redhat.com> PR preprocessor/120778 * macro.cc (stringify_arg): For C++26 emit a pedarn instead of warning for \ at the end of stringification. * g++.dg/DRs/dr2578.C: New test.
26 hoursDaily bump.GCC Administrator1-0/+7
34 hourslibcpp: Fix up cpp_maybe_module_directive [PR120845]Jakub Jelinek1-16/+14
My changes for "Module Declarations Shouldn’t be Macros" paper broke the following testcase. The backup handling intentionally tries to drop CPP_PRAGMA_EOL token if things go wrong, which is desirable for the case where we haven't committed to the module preprocessing directive (i.e. changed the first token to the magic one). In that case there is no preprocessing directive start and so CPP_PRAGMA_EOL would be wrong. If there is a premature new-line after we've changed the first token though, we shouldn't drop CPP_PRAGMA_EOL, because otherwise we ICE in the FE. While clang++ and MSVC accept the testcase, in my reading it is incorrect at least in the C++23 and newer wordings and I think the changes have been a DR, https://eel.is/c++draft/cpp.module has no exception for new-lines and https://eel.is/c++draft/cpp.pre#1.sentence-2 says that new-line (unless deleted during phase 2 when after backslash) ends the preprocessing directive. The patch arranges for eol being set only in the not_module case. 2025-08-03 Jakub Jelinek <jakub@redhat.com> PR c++/120845 libcpp/ * lex.cc (cpp_maybe_module_directive): Move eol variable declaration to the start of the function, initialize to false and only set it to peek->type == CPP_PRAGMA_EOL in the not_module case. Formatting fix. gcc/testsuite/ * g++.dg/modules/cpp-21.C: New test.
5 daysDaily bump.GCC Administrator2-0/+14
5 daysUpdate cpplib sr.poJoseph Myers1-528/+357
* sr.po: Update.
6 dayslibcpp: Fix up comma diagnostics in preprocessor for C++ [PR120778]Jakub Jelinek2-3/+18
The P2843R3 Preprocessing is never undefined paper contains comments that various compilers handle comma operators in preprocessor expressions incorrectly and I think they are right. In both C and C++ the grammar uses constant-expression non-terminal for #if/#elif and in both C and C++ that NT is conditional-expression, so #if 1, 2 is IMHO clearly wrong in both languages. C89 then says for constant-expression "Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except when they are contained within the operand of a sizeof operator." Because all the remaining identifiers in the #if/#elif expression are replaced with 0 I think assignments, increment, decrement and function-call aren't that big deal because (0 = 1) or ++4 etc. are all invalid, but for comma expressions I think it matters. In r0-56429 PR456 Joseph has added !CPP_OPTION (pfile, c99) to handle that correctly. Then C99 changed that to: "Constant expressions shall not contain assignment, increment, decrement, function-call, or comma operators, except when they are contained within a subexpression that is not evaluated." That made for C99+ #if 1 || (1, 2) etc. valid but #if (1, 2) is still invalid, ditto #if 1 ? 1, 2 : 3 In C++ I can't find anything like that though, and as can be seen on say int a[(1, 2)]; int b[1 ? 1, 2 : 3]; being accepted by C++ and rejected by C while int c[1, 2]; int d[1 ? 2 : 3, 4]; being rejected in both C and C++, so I think for C++ it is indeed just the grammar that prevents #if 1, 2. When it is the second operand of ?: or inside of () the grammar just uses expression and that allows comma operator. So, the following patch uses different decisions for C++ when to diagnose comma operator in preprocessor expressions, for C++ tracks if it is inside of () (obviously () around #embed clauses don't count unless one uses limit ((1, 2)) etc.) or inside of the second ?: operand and allows comma operator there and disallows elsewhere. BTW, I wonder if anything in the standard disallows <=> in the preprocessor expressions. Say #if (0 <=> 1) < 0 etc. #include <compare> constexpr int a = (0 <=> 1) < 0; is valid (but not valid without #include <compare>) and the expressions don't use any identifiers. 2025-07-30 Jakub Jelinek <jakub@redhat.com> PR c++/120778 * internal.h (struct lexer_state): Add comma_ok member. * expr.cc (_cpp_parse_expr): Initialize it to 0, increment on CPP_OPEN_PAREN and CPP_QUERY, decrement on CPP_CLOSE_PAREN and CPP_COLON. (num_binary_op): For C++ pedwarn on comma operator if pfile->state.comma_ok is 0 instead of !c99 or skip_eval. * g++.dg/cpp/if-comma-1.C: New test.
10 daysDaily bump.GCC Administrator1-0/+20
10 daysdiagnostics: move diagnostic.c to diagnostics/context.ccDavid Malcolm1-1/+1
No functional change intended. gcc/ChangeLog: * Makefile.in (OBJS-libcommon): Replace diagnostic.o with diagnostics/context.o. gcc/c-family/ChangeLog: * c-common.cc (c_family_tests): Add include of "diagnostics/diagnostics-selftests.h". Replace c_diagnostic_cc_tests with diagnostics::selftest::context_cc_tests. * c-common.h: Drop c_diagnostic_cc_tests decl. gcc/ChangeLog: * diagnostic.h (num_digits): Move to... (diagnostics::num_digits): ...here. (get_cwe_url): Move to... (diagnostics::get_cwe_url): ...here. (maybe_line_and_column): Move to... (diagnostics::maybe_line_and_column): ...here. * diagnostic.cc: Move to... * diagnostics/context.cc: ...here. * diagnostics/diagnostics-selftests.cc (run_diagnostics_selftests): Add comment about context_cc_tests. * diagnostics/diagnostics-selftests.h: Add context_cc_tests decl. * diagnostics/sarif-sink.cc: Update for file rename. * diagnostics/source-printing.cc: Update for num_digits moving to diagnostics::num_digits. * errors.cc: Update for file rename. * input.cc: Update for num_digits moving to diagnostics::num_digits. libcpp/ChangeLog: * charset.cc: Update comment for file rename. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
10 daysdiagnostics: convert diagnostic_t to enum class diagnostics::kindDavid Malcolm1-2/+2
No functional change intended. gcc/ChangeLog: * Makefile.in: Replace diagnostic.def with diagnostics/kinds.def. * config/aarch64/aarch64.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * config/i386/i386-options.cc: Likewise. * config/s390/s390.cc: Likewise. * diagnostic-core.h: Replace typedef diagnostic_t with enum class diagnostics::kind in diagnostics/kinds.h and include it. * diagnostic-global-context.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * diagnostic.cc: Likewise. * diagnostic.h: Likewise. * diagnostics/buffering.cc: Likewise. * diagnostics/buffering.h: Likewise. * diagnostics/context.h: Likewise. * diagnostics/diagnostic-info.h: Likewise. * diagnostics/html-sink.cc: Likewise. * diagnostic.def: Move to... * diagnostics/kinds.def: ...here and update for diagnostic_t becoming enum class diagnostics::kind. * diagnostics/kinds.h: New file, based on material in diagnostic-core.h. * diagnostics/lazy-paths.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * diagnostics/option-classifier.cc: Likewise. * diagnostics/option-classifier.h: Likewise. * diagnostics/output-spec.h: Likewise. * diagnostics/paths-output.cc: Likewise. * diagnostics/sarif-sink.cc: Likewise. * diagnostics/selftest-context.cc: Likewise. * diagnostics/selftest-context.h: Likewise. * diagnostics/sink.h: Likewise. * diagnostics/source-printing.cc: Likewise. * diagnostics/text-sink.cc: Likewise. * diagnostics/text-sink.h: Likewise. * gcc.cc: Likewise. * libgdiagnostics.cc: Likewise. * lto-wrapper.cc: Likewise. * opts-common.cc: Likewise. * opts-diagnostic.h: Likewise. * opts.cc: Likewise. * rtl-error.cc: Likewise. * substring-locations.cc: Likewise. * toplev.cc: Likewise. gcc/ada/ChangeLog: * gcc-interface/trans.cc: Update for diagnostic_t becoming enum class diagnostics::kind. gcc/analyzer/ChangeLog: * pending-diagnostic.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * program-point.cc: Likewise. gcc/c-family/ChangeLog: * c-common.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * c-format.cc: Likewise. * c-lex.cc: Likewise. * c-opts.cc: Likewise. * c-pragma.cc: Likewise. * c-warn.cc: Likewise. gcc/c/ChangeLog: * c-errors.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * c-parser.cc: Likewise. * c-typeck.cc: Likewise. gcc/cobol/ChangeLog: * util.cc: Update for diagnostic_t becoming enum class diagnostics::kind. gcc/cp/ChangeLog: * call.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * constexpr.cc: Likewise. * cp-tree.h: Likewise. * decl.cc: Likewise. * error.cc: Likewise. * init.cc: Likewise. * method.cc: Likewise. * module.cc: Likewise. * parser.cc: Likewise. * pt.cc: Likewise. * semantics.cc: Likewise. * typeck.cc: Likewise. * typeck2.cc: Likewise. gcc/d/ChangeLog: * d-diagnostic.cc: Update for diagnostic_t becoming enum class diagnostics::kind. gcc/fortran/ChangeLog: * cpp.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * error.cc: Likewise. * options.cc: Likewise. gcc/jit/ChangeLog: * dummy-frontend.cc: Update for diagnostic_t becoming enum class diagnostics::kind. gcc/m2/ChangeLog: * gm2-gcc/m2linemap.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * gm2-gcc/rtegraph.cc: Likewise. gcc/rust/ChangeLog: * backend/rust-tree.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * backend/rust-tree.h: Likewise. * resolve/rust-ast-resolve-expr.cc: Likewise. * resolve/rust-ice-finalizer.cc: Likewise. * resolve/rust-ice-finalizer.h: Likewise. * resolve/rust-late-name-resolver-2.0.cc: Likewise. gcc/testsuite/ChangeLog: * gcc.dg/plugin/diagnostic_plugin_test_show_locus.cc: Update for diagnostic_t becoming enum class diagnostics::kind. * gcc.dg/plugin/expensive_selftests_plugin.cc: Likewise. * gcc.dg/plugin/location_overflow_plugin.cc: Likewise. * lib/gcc-dg.exp: Likewise. libcpp/ChangeLog: * internal.h: Update comment for diagnostic_t becoming enum class diagnostics::kind. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
10 daysdiagnostics: introduce diagnostics/source-printing.ccDavid Malcolm2-3/+5
Move diagnostic-show-locus.cc to diagnostics/source-printing.cc Move diagnostic-label-effects.h to diagnostics/source-printing-effects.h Move selftest-diagnostic-show-locus.h to diagnostics/selftest-source-printing.h No functional change intended. gcc/ChangeLog: * Makefile.in (OBJS): Replace diagnostic-show-locus.o with diagnostics/source-printing.o. * diagnostic.h (class diagnostic_source_effect_info): Replace with... (class diagnotics::source_effect_info): ...this. * diagnostics/paths-output.cc: Likewise. Update for move of "diagnostic-label-effects.h" to "diagnostics/source-printing-effects.h". * diagnostics/sarif-sink.cc: Update for move of "selftest-diagnostic-show-locus.h" to "diagnostics/selftest-source-printing.h". * selftest-diagnostic-show-locus.h: Move to... * diagnostics/selftest-source-printing.h: ...here. * diagnostic-label-effects.h: Move to... * diagnostics/source-printing-effects.h: ...here, updating for above changes. * diagnostic-show-locus.cc: Move to... * diagnostics/source-printing.cc: ...here. * gcc-rich-location.h: Likewise. * selftest-run-tests.cc: Likewise. * selftest.h: Likewise. gcc/testsuite/ChangeLog: * g++.dg/plugin/show-template-tree-color-labels.C: Update for moves to "source-printing". * gcc.dg/plugin/diagnostic-test-show-locus.py: Likewise. libcpp/ChangeLog: * include/cpplib.h: Update for moves to "source-printing". * include/rich-location.h (class label_effects): Move to... (class diagnostics::label_effects): ...here. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
10 daysdiagnostics: introduce namespace diagnostics::pathsDavid Malcolm1-4/+4
Move more diagnostic-specific code from gcc/ to gcc/diagnostics/ No functional change intended. contrib/ChangeLog: * filter-clang-warnings.py: Update for move of diagnostic-path-output.cc to diagnostics/paths-output.cc. gcc/ChangeLog: * Makefile.in (OBJS): Replace lazy-diagnostic-path.o with diagnostics/lazy-paths.o. (OBJS-libcommon): Replace diagnostic-path.o with diagnostics/paths.o, diagnostic-path-output.o with diagnostics/paths-output.o, and selftest-diagnostic-path.o with diagnostics/selftest-paths.o. (EXTRA_BACKEND_OBJS): Replace lazy-diagnostic-path.o with diagnostics/lazy-paths.o. * diagnostic-format-html.cc: Update #include for "diagnostic-path.h" moving to "diagnostics/paths.h", diagnostic_thread_id_t to diagnostics::paths::thread_id_t, diagnostic_event_id_t to diagnostics::paths::event_id_t, diagnostic_path to diagnostics::paths::path, and diagnostic_thread to diagnostics::paths::thread, and diagnostic_event to diagnostics::paths::event. * diagnostic-format-html.h: Likewise. * diagnostic-format-sarif.cc: Likewise. Update PROPERTY_PREFIX for threadFlowLocations from "gcc/diagnostic_event/" to "gcc/diagnostics/paths/event/". * diagnostic-format-text.cc: Likewise. * diagnostic-format-text.h: Likewise. * diagnostic.cc: Likewise. * diagnostic.h: Likewise. * diagnostic-event-id.h: Move to... * diagnostics/event-id.h: ...here, updating header guard. (diagnostics:paths:event_id_t): New typedef. (diagnostic_thread_id_t): Replace with... (diagnostics:paths:thread_id_t): New typedef. * lazy-diagnostic-path.cc: Move to... * diagnostics/lazy-paths.cc: ...here. Update for above changes, lazy_diagnostic_path becomes diagnostics::paths::lazy_path. (lazy_diagnostic_path_cc_tests): Rename to... (diagnostics_lazy_paths_cc_tests): ...this. * lazy-diagnostic-path.h: Move to... * diagnostics/lazy-paths.h: ...here, updating header guard. Update for above changes. * diagnostic-path-output.cc: Move to... * diagnostics/paths-output.cc: ...here. Update for above changes. (diagnostic_path_output_cc_tests): Rename to... (diagnostics_paths_output_cc_tests): ...this. * diagnostic-path.cc: Move to... * diagnostics/paths.cc: ...here. Update for above changes. * diagnostic-path.h: Move to... * diagnostics/paths.h: ...here, updating header guard. Update #include for moving "diagnostic-event-id.h" to "diagnostics/event-id.h". (class diagnostic_event): Convert to... (class diagnostics::paths::event): ...this. (class diagnostic_thread): Convert to... (class diagnostics::paths::thread): ...this. (class diagnostic_path): Convert to... (class diagnostics::paths::path): ...this. * diagnostic-show-locus.cc: Update for above changes. * doc/analyzer.texi: Likewise. * selftest-diagnostic-path.cc: Move to... * diagnostics/selftest-paths.cc: ...here. Update for above changes, and for "selftest-diagnostic-path.h" moving to "diagnostics/selftest-paths.h". * selftest-diagnostic-path.h: Move to... * diagnostics/selftest-paths.h: ...here, updating header guard. Update for above changes. * libgdiagnostics.cc: Update for above changes. * libsarifreplay.cc: Update property prefix for threadFlowLocations from "gcc/diagnostic_event/" to "gcc/diagnostics/paths/event/". * pretty-print-format-impl.h: Update for above changes. * pretty-print.cc: Likewise. * selftest-run-tests.cc (selftest::run_tests): Update for renaming of lazy_diagnostic_path_cc_tests to diagnostics_lazy_paths_cc_tests, and of diagnostic_path_output_cc_tests to diagnostics_paths_output_cc_tests. * selftest.h (lazy_diagnostic_path_cc_tests): Replace decl with... (diagnostics_lazy_paths_cc_tests): ...this. (diagnostic_path_output_cc_tests): Replace decl with... (diagnostics_paths_output_cc_tests): ...this. * simple-diagnostic-path.cc: Clarify that this relates to "tree" and thus shouldn't be in "diagnostics". Update for above changes. * simple-diagnostic-path.h: Likewise. gcc/analyzer/ChangeLog: * access-diagram.cc: Update for changes to diagnostic paths: "diagnostic-path.h" moving to "diagnostics/paths.h", "diagnostic-event-id.h" moving to "diagnostics/event-id.h", diagnostic_event_id_t to diagnostics::paths::event_id_t, diagnostic_path to diagnostics::paths::path, and diagnostic_event to diagnostics::paths::event. * access-diagram.h: Likewise. * analyzer.cc: Likewise. * bounds-checking.cc: Likewise. * call-info.cc: Likewise. * checker-event.cc: Likewise. * checker-event.h: Likewise. * checker-path.cc: Likewise. * checker-path.h: Likewise. * common.h: Likewise. * diagnostic-manager.cc: Likewise. * pending-diagnostic.cc: Likewise. * pending-diagnostic.h: Likewise. * program-point.cc: Likewise. * program-state.cc: Likewise. * region-model.cc: Likewise. * sm-fd.cc: Likewise. * sm-file.cc: Likewise. * sm-malloc.cc: Likewise. * sm-pattern-test.cc: Likewise. * sm-sensitive.cc: Likewise. * sm-signal.cc: Likewise. * sm-taint.cc: Likewise. * varargs.cc: Likewise. gcc/testsuite/ChangeLog: * gcc.dg/plugin/analyzer_gil_plugin.cc: Update #include for "diagnostic-path.h" moving to "diagnostics/paths.h", diagnostic_thread_id_t to diagnostics::paths::thread_id_t, diagnostic_event_id_t to diagnostics::paths::event_id_t, diagnostic_path to diagnostics::paths::path, and diagnostic_thread to diagnostics::paths::thread, and diagnostic_event to diagnostics::paths::event. * gcc.dg/plugin/diagnostic_plugin_test_paths.cc: Likewise. * lib/sarif.py (get_state_graph): Update property prefix for threadFlowLocations from "gcc/diagnostic_event/" to "gcc/diagnostics/paths/event/". * gcc.dg/sarif-output/include-chain-2.h: Update comment. libcpp/ChangeLog: * include/rich-location.h: Replace diagnostic_path with diagnostics::paths::path. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2025-06-18Daily bump.GCC Administrator1-0/+5
2025-06-17c++: modules and #pragma diagnosticJason Merrill2-0/+15
To respect the #pragma diagnostic lines in libstdc++ headers when compiling with module std, we need to represent them in the module. I think it's reasonable to give serializers direct access to the underlying data, as here with get_classification_history. This is a different approach from how Jakub made PCH streaming members of diagnostic_option_classifier, but it seems to me that modules handling belongs in module.cc. libcpp/ChangeLog: * line-map.cc (linemap_location_from_module_p): Add. * include/line-map.h: Declare it. gcc/ChangeLog: * diagnostic.h (diagnostic_option_classifier): Friend diagnostic_context. (diagnostic_context::get_classification_history): New. gcc/cp/ChangeLog: * module.cc (module_state::write_diagnostic_classification): New. (module_state::write_begin): Call it. (module_state::read_diagnostic_classification): New. (module_state::read_initial): Call it. (dk_string, dump_dc_change): New. gcc/testsuite/ChangeLog: * g++.dg/modules/warn-spec-3_a.C: New test. * g++.dg/modules/warn-spec-3_b.C: New test. * g++.dg/modules/warn-spec-3_c.C: New test.
2025-06-11Daily bump.GCC Administrator1-0/+9
2025-06-10diagnostics: make experimental-html sink prettier [PR116792]David Malcolm2-2/+35
This patch to the "experimental-html" diagnostic sink: * adds use of the PatternFly 3 CSS library (via an optional link in the generated html to a copy in a CDN) * uses PatternFly's "alert" pattern to show severities for diagnostics, properly nesting "note" diagnostics for diagnostic groups. Example: before: https://dmalcolm.fedorapeople.org/gcc/2025-06-10/before/diagnostic-ranges.c.html after: https://dmalcolm.fedorapeople.org/gcc/2025-06-10/after/diagnostic-ranges.c.html * adds initial support for logical locations and physical locations * adds initial support for multi-level nested diagnostics such as those for C++ concepts diagnostics. Ideally this would show a clickable disclosure widget to expand/collapse a level, but for now it uses nested <ul> elements with <li> for the child diagnostics. Example: before: https://dmalcolm.fedorapeople.org/gcc/2025-06-10/before/nested-diagnostics-1.C.html after: https://dmalcolm.fedorapeople.org/gcc/2025-06-10/after/nested-diagnostics-1.C.html gcc/ChangeLog: PR other/116792 * diagnostic-format-html.cc: Include "diagnostic-path.h" and "diagnostic-client-data-hooks.h". (html_builder::m_logical_loc_mgr): New field. (html_builder::m_cur_nesting_levels): New field. (html_builder::m_last_logical_location): New field. (html_builder::m_last_location): New field. (html_builder::m_last_expanded_location): New field. (HTML_STYLE): Add "white-space: pre;" to .source and .annotation. Add "gcc-quoted-text" CSS class. (html_builder::html_builder): Initialize the new fields. If CSS is enabled, add CDN links to PatternFly 3 stylesheets. (html_builder::add_stylesheet): New. (html_builder::on_report_diagnostic): Add "alert" param to make_element_for_diagnostic, setting it by default, but unsetting it for nested diagnostics below the top level. Use add_at_nesting_level for nested diagnostics. (add_nesting_level_attr): New. (html_builder::add_at_nesting_level): New. (get_pf_class_for_alert_div): New. (get_pf_class_for_alert_icon): New. (get_label_for_logical_location_kind): New. (add_labelled_value): New. (html_builder::make_element_for_diagnostic): Add leading comment. Add "alert" param. Drop class="gcc-diagnostic" from <div> tag, instead adding the class for a PatternFly 3 alert if "alert" is true, and adding a <span> with an alert icon, both according to the diagnostic severity. Add a severity prefix to the message for alerts. Add any metadata/option text as suffixes to the message. Show any logical location. Show any physical location. Don't show the locus if the last location is unchanged within the diagnostic_group. Wrap any execution path element in a <div id="execution-path"> and add a label to it. Wrap any generated patch in a <div id="suggested-fix"> and add a label to it. (selftest::test_simple_log): Update expected HTML. gcc/testsuite/ChangeLog: PR other/116792 * gcc.dg/html-output/missing-semicolon.py: Update for changes to diagnostic elements. * gcc.dg/format/diagnostic-ranges-html.py: Likewise. * gcc.dg/plugin/diagnostic-test-metadata-html.py: Likewise. Drop out-of-date comment. * gcc.dg/plugin/diagnostic-test-paths-2.py: Likewise. * gcc.dg/plugin/diagnostic-test-paths-4.py: Likewise. Drop out-of-date comment. * gcc.dg/plugin/diagnostic-test-show-locus.py: Likewise. * lib/htmltest.py (get_diag_by_index): Update to use search by id. (get_message_within_diag): Update to use search by class. libcpp/ChangeLog: PR other/116792 * include/line-map.h (typedef expanded_location): Convert to... (struct expanded_location): ...this. (operator==): New decl, for expanded_location. (operator!=): Likewise. * line-map.cc (operator==): New decl, for expanded_location. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2025-05-17Daily bump.GCC Administrator1-0/+4
2025-05-16Update cpplib es.poJoseph Myers1-30/+30
* es.po: Update.
2025-05-16Daily bump.GCC Administrator1-0/+4
2025-05-15Update cpplib zh_CN.poJoseph Myers1-31/+30
* zh_CN.po: Update.
2025-05-15Daily bump.GCC Administrator1-0/+4
2025-05-14Update cpplib es.poJoseph Myers1-4/+4
* es.po: Update.
2025-05-13Daily bump.GCC Administrator1-0/+4
2025-05-12Update cpplib es.poJoseph Myers1-519/+348
* es.po: Update.
2025-05-08Daily bump.GCC Administrator1-0/+13
2025-05-07libcpp: Further fixes for incorrect line numbers in large files [PR120061]Jakub Jelinek2-16/+40
The backport of the PR108900 fix to 14 branch broke building chromium because static_assert (__LINE__ == expected_line_number, ""); now triggers as the __LINE__ values are off by one. This isn't the case on the trunk and 15 branch because we've switched to 64-bit location_t and so one actually needs far longer header files to trigger it. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c11 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c12 contain (large) testcases in patch form which show on the 14 branch that the first one used to fail before the PR108900 backport and now works correctly, while the second one attempts to match the chromium behavior and it used to pass before the PR108900 backport and now it FAILs. The two testcases show rare problematic cases, because do_include_common -> parse_include -> check_eol -> check_eol_1 -> cpp_get_token_1 -> _cpp_lex_token -> _cpp_lex_direct -> linemap_line_start triggers there /* Allocate the new line_map. However, if the current map only has a single line we can sometimes just increase its column_bits instead. */ if (line_delta < 0 || last_line != ORDINARY_MAP_STARTING_LINE_NUMBER (map) || SOURCE_COLUMN (map, highest) >= (1U << (column_bits - range_bits)) || ( /* We can't reuse the map if the line offset is sufficiently large to cause overflow when computing location_t values. */ (to_line - ORDINARY_MAP_STARTING_LINE_NUMBER (map)) >= (((uint64_t) 1) << (CHAR_BIT * sizeof (linenum_type) - column_bits))) || range_bits < map->m_range_bits) map = linemap_check_ordinary (const_cast <line_map *> (linemap_add (set, LC_RENAME, ORDINARY_MAP_IN_SYSTEM_HEADER_P (map), ORDINARY_MAP_FILE_NAME (map), to_line))); and so creates a new ordinary map on the line right after the (problematic) #include line. Now, in the spot that r14-11679-g8a884140c2bcb7 patched, pfile->line_table->highest_location in all 3 tests (also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120061#c13 ) is before the decrement the start of the line after the #include line and so the decrement is really desirable in that case to put highest_location somewhere on the line where the #include actually is. But at the same time it is also undesirable, because if we do decrement it, then linemap_add LC_ENTER called from _cpp_do_file_change will then /* Generate a start_location above the current highest_location. If possible, make the low range bits be zero. */ location_t start_location = set->highest_location + 1; unsigned range_bits = 0; if (start_location < LINE_MAP_MAX_LOCATION_WITH_COLS) range_bits = set->default_range_bits; start_location += (1 << range_bits) - 1; start_location &= ~((1 << range_bits) - 1); linemap_assert (!LINEMAPS_ORDINARY_USED (set) || (start_location >= MAP_START_LOCATION (LINEMAPS_LAST_ORDINARY_MAP (set)))); and we can end up with the new LC_ENTER ordinary map having the same start_location as the preceding LC_RENAME one. Next thing that happens is computation of included_from: if (reason == LC_ENTER) { if (set->depth == 0) map->included_from = 0; else /* The location of the end of the just-closed map. */ map->included_from = (((map[0].start_location - 1 - map[-1].start_location) & ~((1 << map[-1].m_column_and_range_bits) - 1)) + map[-1].start_location); The normal case (e.g. with the testcase included at the start of this comment) is that map[-1] starts somewhere earlier and so map->included_from computation above nicely computes location_t which expands to the start of the #include line. With r14-11679 reverted, for #c11 as well as #c12 map[0].start_location == map[-1].start_location above, and so it is ((location_t) -1 & ~((1 << map[-1].m_column_and_range_bits) - 1))) + map[-1].start_location, which happens to be start of the #include line. For #c11 map[0].start_location is 0x500003a0 and map[-1] has m_column_and_range_bits 7 and map[-2] has m_column_and_range_bits 12 and map[0].included_from is set to 0x50000320. For #c12 map[0].start_location is 0x606c0402 and map[-2].start_location is 0x606c0400 and m_column_and_range_bits is 0 for all 3 maps. map[0].included_from is set to 0x606c0401. The last important part is again in linemap_add when doing LC_LEAVE: /* (MAP - 1) points to the map we are leaving. The map from which (MAP - 1) got included should be the map that comes right before MAP in the same file. */ from = linemap_included_from_linemap (set, map - 1); /* A TO_FILE of NULL is special - we use the natural values. */ if (to_file == NULL) { to_file = ORDINARY_MAP_FILE_NAME (from); to_line = SOURCE_LINE (from, from[1].start_location); sysp = ORDINARY_MAP_IN_SYSTEM_HEADER_P (from); } Here it wants to compute the right to_line which ought to be the line after the #include directive. On the #c11 testcase that doesn't work correctly though, because map[-1].included_from is 0x50000320, from[0] for that is LC_ENTER with start_location 0x4080 and m_column_and_range_bits 12 but note that we've earlier computed map[-1].start_location + (-1 & 0xffffff80) and so only decreased by 7 bits, so to_line is still on the line with #include and not after it. In the #c12 that doesn't happen, all the ordinary maps involved there had 0 m_column_and_range_bits and so this computes correct line. Below is a fix for the trunk including testcases using the location_overflow_plugin hack to simulate the bugs without needing huge files (in the 14 case it is just 330KB and almost 10MB, but in the 15 case it would need to be far bigger). The pre- r15-9018 trunk has FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*6[^\n\r]*== 6 and current trunk FAIL: gcc.dg/plugin/location-overflow-test-pr116047.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*6[^\n\r]*== 6 FAIL: gcc.dg/plugin/location-overflow-test-pr120061.c -fplugin=./location_overflow_plugin.so scan-file static_assert[^\n\r]*5[^\n\r]*== 5 and with the patch everything PASSes. I'll post afterwards a 14 version of the patch. The patch reverts the r15-9018 change, because it is incorrect, we really need to decrement it even when crossing ordinary map boundaries, so that the location is not on the line after the #include line but somewhere on the #include line. It also patches two spots in linemap_add mentioned above to make sure we get correct locations both in the included_from location_t when doing LC_ENTER (second line-map.cc hunk) and when doing LC_LEAVE to compute the right to_line (first line-map.cc hunk), both in presence of an added LC_RENAME with the same start_location as the following LC_ENTER (i.e. the problematic cases). The LC_ENTER hunk is mostly to ensure included_form location_t is at the start of the #include line (column 0), without it we can decrease include_from not enough and end up at some random column in the middle of the line, because it is masking away map[-1].m_column_and_range_bits bits even when in the end the resulting include_from location_t will be found in map[-2] map with perhaps different m_column_and_range_bits. That alone doesn't fix the bug though. The more important is the LC_LEAVE hunk and the problem there is caused by linemap_line_start not actually doing r = set->highest_line + (line_delta << map->m_column_and_range_bits); when adding a new map (the LC_RENAME one because we need to switch to different number of directly encoded ranges, or columns, etc.). So, in the original PR108900 case that to_line = SOURCE_LINE (from, from[1].start_location); doesn't do the right thing, from there is the last < 0x50000000 map with m_column_and_range_bits 12, from[1] is the first one above it and map[-1].included_from is the correct location of column 0 on the #include line, but as the new LC_RENAME map has been created without actually increasing highest_location to be on the new line (we've just set to_line of the new LC_RENAME map to the correct line), to_line = SOURCE_LINE (from, from[1].start_location); stays on the same source line. I've tried to just replace that with to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; i.e. just find out the #include line from map[-1].included_from and add 1 to it, unfortunately that breaks the c-c++-common/cpp/line-4.c test where we expect to stay on the same 0 line for LC_LEAVE from <command line> and gcc.dg/cpp/trad/Wunused.c, gcc.dg/cpp/trad/builtins.c and c-c++-common/analyzer/named-constants-via-macros-traditional.c tests all with -traditional-cpp preprocessing where to_line is also off-by-one from the expected one. So, this patch instead conditionalizes it, uses the to_line = SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; way only if from[1] is a LC_RENAME map (rather than the usual LC_ENTER one), that should limit it to the problematic cases of when parse_include peeked after EOL and had to create LC_RENAME map with the same start_location as the LC_ENTER after it. Some further justification for the LC_ENTER hunk, using the https://gcc.gnu.org/pipermail/gcc-patches/2025-May/682774.html testcase (old is 14 before r14-11679, vanilla current 14 and new with the 14 patch) I get $ /usr/src/gcc-14/obj/gcc/cc1.old -quiet -std=c23 pr116047.c -nostdinc In file included from pr116047-1.h:327677:21, from pr116047.c:4: pr116047-2.h:1:1: error: unknown type name ‘a’ 1 | a b c; | ^ pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ 1 | a b c; | ^ pr116047-1.h:327677:1: error: static assertion failed: "" 327677 | #include "pr116047-2.h" | ^~~~~~~~~~~~~ $ /usr/src/gcc-14/obj/gcc/cc1.vanilla -quiet -std=c23 pr116047.c -nostdinc In file included from pr116047-1.h:327678, from pr116047.c:4: pr116047-2.h:1:1: error: unknown type name ‘a’ 1 | a b c; | ^ pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ 1 | a b c; | ^ $ /usr/src/gcc-14/obj/gcc/cc1.new -quiet -std=c23 pr116047.c -nostdinc In file included from pr116047-1.h:327677, from pr116047.c:4: pr116047-2.h:1:1: error: unknown type name ‘a’ 1 | a b c; | ^ pr116047-2.h:1:5: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘c’ 1 | a b c; | ^ pr116047-1.h has on lines 327677+327678: #include "pr116047-2.h" static_assert (__LINE__ == 327678, ""); so the static_assert failure is something that was dealt mainly in the LC_LEAVE hunk and files.cc reversion, but please have a look at the In file included from lines. 14.2 emits correct line (#include "pr116047-2.h" is indeed on line 327677) but some random column in there (which is not normally printed for smaller headers; 21 is the . before extension in the filename). Current trunk emits incorrect line (327678 instead of 327677, clearly it didn't decrement). And the patched compiler emits the right line with no column, as would be printed if I remove e.g. 300000 newlines from the file. 2025-05-07 Jakub Jelinek <jakub@redhat.com> PR preprocessor/108900 PR preprocessor/116047 PR preprocessor/120061 * files.cc (_cpp_stack_file): Revert 2025-03-28 change. * line-map.cc (linemap_add): Use SOURCE_LINE (from, linemap_included_from (map - 1)) + 1; instead of SOURCE_LINE (from, from[1].start_location); to compute to_line for LC_LEAVE. For LC_ENTER included_from computation, look at map[-2] or even lower if map[-1] has the same start_location as map[0]. * gcc.dg/plugin/plugin.exp: Add location-overflow-test-pr116047.c and location-overflow-test-pr120061.c. * gcc.dg/plugin/location_overflow_plugin.cc (plugin_init): Don't error on unknown values, instead just break. Handle 0x4fHHHHHH arguments differently. * gcc.dg/plugin/location-overflow-test-pr116047.c: New test. * gcc.dg/plugin/location-overflow-test-pr116047-1.h: New test. * gcc.dg/plugin/location-overflow-test-pr116047-2.h: New test. * gcc.dg/plugin/location-overflow-test-pr120061.c: New test. * gcc.dg/plugin/location-overflow-test-pr120061-1.h: New test. * gcc.dg/plugin/location-overflow-test-pr120061-2.h: New test.
2025-04-29Daily bump.GCC Administrator1-0/+6
2025-04-27c-family: Improve location for -Wunknown-pragmas in a _Pragma [PR118838]Lewis Hyatt2-0/+12
The warning for -Wunknown-pragmas is issued at the location provided by libcpp to the def_pragma() callback. This location is cpp_reader::directive_line, which is a location for the start of the line only; it is also not a valid location in case the unknown pragma was lexed from a _Pragma string. These factors make it impossible to suppress -Wunknown-pragmas via _Pragma("GCC diagnostic...") directives on the same source line, as in the PR and the test case. Address that by issuing the warning at a better location returned by cpp_get_diagnostic_override_loc(). libcpp already maintains this location to handle _Pragma-related diagnostics internally; it was needed also to make a publicly accessible version of it. gcc/c-family/ChangeLog: PR c/118838 * c-lex.cc (cb_def_pragma): Call cpp_get_diagnostic_override_loc() to get a valid location at which to issue -Wunknown-pragmas, in case it was triggered from a _Pragma. libcpp/ChangeLog: PR c/118838 * errors.cc (cpp_get_diagnostic_override_loc): New function. * include/cpplib.h (cpp_get_diagnostic_override_loc): Declare. gcc/testsuite/ChangeLog: PR c/118838 * c-c++-common/cpp/pragma-diagnostic-loc-2.c: New test. * g++.dg/gomp/macro-4.C: Adjust expected output. * gcc.dg/gomp/macro-4.c: Likewise. * gcc.dg/cpp/Wunknown-pragmas-1.c: Likewise.
2025-04-25Daily bump.GCC Administrator1-0/+6
2025-04-24c: Allow $@` in GNU23/GNU2Y raw string delimiters [PR110343]Jakub Jelinek1-2/+3
Aaron mentioned in the PR that late in C23 N3124 was adopted and $@` are now part of basic character set. The paper has been implemented in GCC from what I can see, but we should allow for GNU23/2Y $@` in raw string delimiters as well, like they are allowed for C++26, because the delimiters can contain anything from basic character set but space, ()\, tab, form-feed, newline and backspace. 2025-04-24 Jakub Jelinek <jakub@redhat.com> PR c++/110343 * lex.cc (lex_raw_string): For C allow $@` in raw string delimiters if CPP_OPTION (pfile, low_ucns) i.e. for C23 and later. * gcc.dg/raw-string-1.c: New test.
2025-04-10Daily bump.GCC Administrator1-0/+6
2025-04-09libcpp: Fix error recovery after use of __VA_ARGS__ as macro argument [PR118674]Jakub Jelinek1-3/+4
The following testcase ICEs after emitting one pedwarn (about using __VA_ARGS__ in a place where it shouldn't be used) and one error. The error is emitted by _cpp_save_parameter where it sees the node has been used already earlier. But unlike the other _cpp_save_parameter caller which does goto out; if it returns false, this call with explicit __VA_ARGS__ doesn't and if it increments number of parameters etc. after the error, we then try to unsave it twice. The following patch fixes it by doing the goto out in that case too, the macro will then not be considered as variable arguments macro, but for error recovery I think that is fine. The other option would be before the other _cpp_save_parameter caller check if the node is pfile->spec_nodes.n__VA_ARGS__ and in that case also error and goto out, but that seems more expensive than this for the common case that the macro definition is correct. 2025-04-09 Jakub Jelinek <jakub@redhat.com> PR preprocessor/118674 * macro.cc (parse_params) <case CPP_ELLIPSIS>: If _cpp_save_parameter failed for __VA_ARGS__, goto out. * gcc.dg/cpp/pr118674.c: New test.
2025-04-05Daily bump.GCC Administrator1-0/+10
2025-04-04c++, libcpp: Allow some left shifts in the preprocessor [PR119391]Jakub Jelinek1-5/+23
The libcpp left shift handling implements (partially) the C99-C23 wording where shifts are UB if shift count is negative, or too large, or shifting left a negative value or shifting left non-negative value results in something not representable in the result type (in the preprocessor case that is intmax_t). libcpp actually implements left shift by negative count as right shifts by negation of the count and similarly right shifts by negative count as left shifts by negation (not ok), sets overflow for too large shift count (ok), doesn't check for negative values on left shift (not ok) and checks correctly for the non-representable ones otherwise (ok). Now, C++11 to C++17 has different behavior, whereas in C99-C23 1 << 63 in preprocessor is invalid, in C++11-17 it is valid, but 3 << 63 is not. The wording is that left shift of negative value is UB (like in C) and signed non-negative left shift is UB if the result isn't representable in corresponding unsigned type (so uintmax_t for libcpp). And then C++20 and newer says all left shifts are well defined with the exception of bad shift counts. In -fsanitize=undefined we handle these by /* For signed x << y, in C99 and later, the following: (unsigned) x >> (uprecm1 - y) if non-zero, is undefined. */ and /* For signed x << y, in C++11 to C++17, the following: x < 0 || ((unsigned) x >> (uprecm1 - y)) if > 1, is undefined. */ Now, we are late in GCC 15 development, so I think making the preprocessor more strict than it is now is undesirable, so will defer setting overflow flag for the shifts by negative count, or shifts by negative value left. The following patch just makes some previously incorrectly rejected or warned cases valid for C++11-17 and even more for C++20 and later. 2025-04-04 Jakub Jelinek <jakub@redhat.com> PR preprocessor/119391 * expr.cc (num_lshift): Add pfile argument. Don't set num.overflow for !num.unsignedp in C++20 or later unless n >= precision. For C++11 to C++17 set it if orig >> (precision - 1 - n) as logical shift results in value > 1. (num_binary_op): Pass pfile to num_lshift. (num_div_op): Likewise. * g++.dg/cpp/pr119391.C: New test.
2025-03-29Daily bump.GCC Administrator1-0/+6
2025-03-28libcpp: Fix incorrect line numbers in large files [PR108900]Jeremy Bettis1-0/+9
This patch addresses an issue in the C preprocessor where incorrect line number information is generated when processing files with a large number of lines. The problem arises from improper handling of location intervals in the line map, particularly when locations exceed LINE_MAP_MAX_LOCATION_WITH_PACKED_RANGES. By ensuring that the highest location is not decremented if it would move to a different ordinary map, this fix resolves the line number discrepancies observed in certain test cases. This change improves the accuracy of line number reporting, benefiting users relying on precise code coverage and debugging information. libcpp/ChangeLog: PR preprocessor/108900 * files.cc (_cpp_stack_file): Do not decrement highest_location across distinct maps. Signed-off-by: Jeremy Bettis <jbettis@google.com> Signed-off-by: Yash Shinde <Yash.Shinde@windriver.com>
2025-03-28Daily bump.GCC Administrator1-0/+5
2025-03-27libcpp: Add missing configure check for setlocale.Roland McGrath3-3/+6
libcpp/ * configure.ac: Check for setlocale. * configure, config.in: Regenerated.
2025-03-21Daily bump.GCC Administrator1-0/+4
2025-03-20Update cpplib de.poJoseph Myers1-11/+7
* de.po: Update.
2025-03-19Daily bump.GCC Administrator1-0/+4
2025-03-18Update cpplib fr.po, sv.poJoseph Myers2-20/+14
* fr.po, sv.po: Update.
2025-03-18Daily bump.GCC Administrator1-0/+6
2025-03-17Update .po filesJoseph Myers23-1022/+1295
gcc/po/ * be.po, da.po, de.po, el.po, es.po, fi.po, fr.po, hr.po, id.po, ja.po, ka.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, ka.po, nl.po, pt_BR.po, ro.po, ru.po, sr.po, sv.po, tr.po, uk.po, vi.po, zh_CN.po, zh_TW.po: Update.
2025-03-15Daily bump.GCC Administrator1-0/+4
2025-03-14Regenerate .pot filesJoseph Myers1-52/+61
gcc/po/ * gcc.pot: Regenerate. libcpp/po/ * cpplib.pot: Regenerate.
2025-03-13Daily bump.GCC Administrator1-0/+6
2025-03-12preprocessor: Fix up diagnostic typo in convert_oct [PR119202]Jakub Jelinek1-1/+1
In r15-4286 I've introduced a typo, part of the change was - cpp_error (pfile, CPP_DL_ERROR, "'\\o' not followed by '{'"); + cpp_error (pfile, CPP_DL_ERROR, "%<\\o%> not followed by %<}%>"); which turned { into }. This patch fixes it back. 2025-03-12 Jakub Jelinek <jakub@redhat.com> PR preprocessor/119202 * charset.cc (convert_oct): Fix up typo in diagnostics about \o not followed by {.
2025-03-11Daily bump.GCC Administrator1-0/+4
2025-03-10Update cpplib de.poJoseph Myers1-512/+344
* de.po: Update.
2025-03-04Daily bump.GCC Administrator1-0/+6