aboutsummaryrefslogtreecommitdiff
path: root/libcpp
AgeCommit message (Collapse)AuthorFilesLines
2023-06-20libcpp: Improve location for macro names [PR66290]Lewis Hyatt4-9/+20
When libcpp reports diagnostics whose locus is a macro name (such as for -Wunused-macros), it uses the location in the cpp_macro object that was stored by _cpp_new_macro. This is currently set to pfile->directive_line, which contains the line number only and no column information. This patch changes the stored location to the src_loc for the token defining the macro name, which includes the location and range information. libcpp/ChangeLog: PR c++/66290 * macro.cc (_cpp_create_definition): Add location argument. * internal.h (_cpp_create_definition): Adjust prototype. * directives.cc (do_define): Pass new location argument to _cpp_create_definition. (do_undef): Stop passing inferior location to cpp_warning_with_line; the default from cpp_warning is better. (cpp_pop_definition): Pass new location argument to _cpp_create_definition. * pch.cc (cpp_read_state): Likewise. gcc/testsuite/ChangeLog: PR c++/66290 * c-c++-common/cpp/macro-ranges.c: New test. * c-c++-common/cpp/line-2.c: Adapt to check for column information on macro-related libcpp warnings. * c-c++-common/cpp/line-3.c: Likewise. * c-c++-common/cpp/macro-arg-count-1.c: Likewise. * c-c++-common/cpp/pr58844-1.c: Likewise. * c-c++-common/cpp/pr58844-2.c: Likewise. * c-c++-common/cpp/warning-zero-location.c: Likewise. * c-c++-common/pragma-diag-14.c: Likewise. * c-c++-common/pragma-diag-15.c: Likewise. * g++.dg/modules/macro-2_d.C: Likewise. * g++.dg/modules/macro-4_d.C: Likewise. * g++.dg/modules/macro-4_e.C: Likewise. * g++.dg/spellcheck-macro-ordering.C: Likewise. * gcc.dg/builtin-redefine.c: Likewise. * gcc.dg/cpp/Wunused.c: Likewise. * gcc.dg/cpp/redef2.c: Likewise. * gcc.dg/cpp/redef3.c: Likewise. * gcc.dg/cpp/redef4.c: Likewise. * gcc.dg/cpp/ucnid-11-utf8.c: Likewise. * gcc.dg/cpp/ucnid-11.c: Likewise. * gcc.dg/cpp/undef2.c: Likewise. * gcc.dg/cpp/warn-redefined-2.c: Likewise. * gcc.dg/cpp/warn-redefined.c: Likewise. * gcc.dg/cpp/warn-unused-macros-2.c: Likewise. * gcc.dg/cpp/warn-unused-macros.c: Likewise.
2023-06-20Daily bump.GCC Administrator1-0/+6
2023-06-19libcpp: reject codepoints above 0x10FFFFBen Boeckel1-0/+7
Unicode does not support such values because they are unrepresentable in UTF-16. libcpp/ * charset.cc: Reject encodings of codepoints above 0x10FFFF. UTF-16 does not support such codepoints and therefore all Unicode rejects such values. Signed-off-by: Ben Boeckel <ben.boeckel@kitware.com>
2023-06-16Daily bump.GCC Administrator1-0/+15
2023-06-15configure: Implement --enable-host-pieMarek Polacek2-3/+38
[ This is my third attempt to add this configure option. The first version was approved but it came too late in the development cycle. The second version was also approved, but I had to revert it: <https://gcc.gnu.org/pipermail/gcc-patches/2022-November/607082.html>. I've fixed the problem (by moving $(PICFLAG) from INTERNAL_CFLAGS to ALL_COMPILERFLAGS). Another change is that since r13-4536 I no longer need to touch Makefile.def, so this patch is simplified. ] This patch implements the --enable-host-pie configure option which makes the compiler executables PIE. This can be used to enhance protection against ROP attacks, and can be viewed as part of a wider trend to harden binaries. It is similar to the option --enable-host-shared, except that --e-h-s won't add -shared to the linker flags whereas --e-h-p will add -pie. It is different from --enable-default-pie because that option just adds an implicit -fPIE/-pie when the compiler is invoked, but the compiler itself isn't PIE. Since r12-5768-gfe7c3ecf, PCH works well with PIE, so there are no PCH regressions. When building the compiler, the build process may use various in-tree libraries; these need to be built with -fPIE so that it's possible to use them when building a PIE. For instance, when --with-included-gettext is in effect, intl object files must be compiled with -fPIE. Similarly, when building in-tree gmp, isl, mpfr and mpc, they must be compiled with -fPIE. With this patch and --enable-host-pie used to configure gcc: $ file gcc/cc1{,plus,obj,gm2} gcc/f951 gcc/lto1 gcc/cpp gcc/go1 gcc/rust1 gcc/gnat1 gcc/cc1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=98e22cde129d304aa6f33e61b1c39e144aeb135e, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/cc1plus: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=859d1ea37e43dfe50c18fd4e3dd9a34bb1db8f77, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/cc1obj: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=1964f8ecee6163182bc26134e2ac1f324816e434, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/cc1gm2: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=a396672c7ff913d21855829202e7b02ecf42ff4c, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/f951: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=59c523db893186547ac75c7a71f48be0a461c06b, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/lto1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=084a7b77df7be2d63c2d4c655b5bbc3fcdb6038d, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/cpp: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=3503bf8390d219a10d6653b8560aa21158132168, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/go1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=988cc673af4fba5dcb482f4b34957b99050a68c5, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/rust1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=b6a5d3d514446c4dcdee0707f086ab9b274a8a3c, for GNU/Linux 3.2.0, with debug_info, not stripped gcc/gnat1: ELF 64-bit LSB pie executable, x86-64, version 1 (GNU/Linux), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, BuildID[sha1]=bb11ccdc2c366fe3fe0980476bcd8ca19b67f9dc, for GNU/Linux 3.2.0, with debug_info, not stripped I plan to add an option to link with -Wl,-z,now. Bootstrapped on x86_64-pc-linux-gnu with --with-included-gettext --enable-host-pie as well as without --enable-host-pie. Also tested on a Debian system where the system gcc was configured with --enable-default-pie. Co-Authored by: Iain Sandoe <iain@sandoe.co.uk> ChangeLog: * configure.ac (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate. c++tools/ChangeLog: * Makefile.in: Rename PIEFLAG to PICFLAG. Set LD_PICFLAG. Use it. Use pic/libiberty.a if PICFLAG is set. * configure.ac (--enable-default-pie): Set PICFLAG instead of PIEFLAG. (--enable-host-pie): New check. * configure: Regenerate. fixincludes/ChangeLog: * Makefile.in: Set and use PICFLAG and LD_PICFLAG. Use the "pic" build of libiberty if PICFLAG is set. * configure.ac: * configure: Regenerate. gcc/ChangeLog: * Makefile.in: Set LD_PICFLAG. Use it. Set enable_host_pie. Remove NO_PIE_CFLAGS and NO_PIE_FLAG. Pass LD_PICFLAG to ALL_LINKERFLAGS. Use the "pic" build of libiberty if --enable-host-pie. * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG and LD_PICFLAG after this check. * configure: Regenerate. * doc/install.texi: Document --enable-host-pie. gcc/ada/ChangeLog: * gcc-interface/Make-lang.in (ALL_ADAFLAGS): Remove NO_PIE_CFLAGS. Add PICFLAG. Use PICFLAG when building ada/b_gnat1.o and ada/b_gnatb.o. * gcc-interface/Makefile.in: Use pic/libiberty.a if PICFLAG is set. Remove NO_PIE_FLAG. gcc/m2/ChangeLog: * Make-lang.in: New var, GM2_PICFLAGS. Use it. gcc/d/ChangeLog: * Make-lang.in: Remove NO_PIE_CFLAGS. intl/ChangeLog: * Makefile.in: Use @PICFLAG@ in COMPILE as well. * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate. libcody/ChangeLog: * Makefile.in: Pass LD_PICFLAG to LDFLAGS. * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG and LD_PICFLAG after this check. * configure: Regenerate. libcpp/ChangeLog: * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate. libdecnumber/ChangeLog: * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate. libiberty/ChangeLog: * configure.ac: Also set shared when enable_host_pie. * configure: Regenerate. zlib/ChangeLog: * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate.
2023-06-15libcpp: Diagnose #include after failed __has_include [PR80753]Jakub Jelinek1-1/+14
As can be seen in the testcase, we don't diagnose #include/#include_next of a non-existent header if __has_include/__has_include_next is done for that header first. The problem is that we normally error the first time some header is not found, but in the _cpp_FFK_HAS_INCLUDE case obviously don't want to diagnose it, just expand it to 0. And libcpp caches both successful includes and unsuccessful ones. The following patch fixes that by remembering that we haven't diagnosed error when using __has_include* on it, and diagnosing it when using the cache entry in normal mode the first time. I think _cpp_FFK_NORMAL is the only mode in which we normally diagnose errors, for _cpp_FFK_PRE_INCLUDE that open_file_failed isn't reached and for _cpp_FFK_FAKE neither. 2023-06-15 Jakub Jelinek <jakub@redhat.com> PR preprocessor/80753 libcpp/ * files.cc (struct _cpp_file): Add deferred_error bitfield. (_cpp_find_file): When finding a file in cache with deferred_error set in _cpp_FFK_NORMAL mode, call open_file_failed and clear the flag. Set deferred_error in _cpp_FFK_HAS_INCLUDE mode if open_file_failed hasn't been called. gcc/testsuite/ * c-c++-common/missing-header-5.c: New test.
2023-05-10Daily bump.GCC Administrator1-0/+4
2023-05-09Update cpplib ru.poJoseph Myers1-43/+29
* ru.po: Update.
2023-05-01Daily bump.GCC Administrator1-0/+13
2023-04-30Revert "[PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__"Jeff Law1-1/+1
This reverts commit e7ce7c4905fd254760b1cd187752a03bc0c148ba.
2023-04-30[PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__Longjun Luo1-1/+1
From 0821df518b264e754d698d399f98be1a62945e32 Mon Sep 17 00:00:00 2001 From: Longjun Luo <luolongjuna@gmail.com> Date: Thu, 12 Jan 2023 23:59:54 +0800 Subject: [PATCH] libcpp: suppress builtin macro redefined warnings for __LINE__ As implied in gcc.gnu.org/legacy-ml/gcc-patches/2008-09/msg00076.html, gcc provides -Wno-builtin-macro-redefined to suppress warning when redefining builtin macro. However, at that time, there was no scenario for __LINE__ macro. But, when we try to build a live-patch, we compare sections by using -ffunction-sections. Some same functions are considered changed because of __LINE__ macro. At present, to detect such a changed caused by __LINE__ macro, we have to analyse code and maintain a function list. For example, in kpatch, check this commit github.com/dynup/kpatch/commit/0e1b95edeafa36edb7bcf11da6d1c00f76d7e03d. So, in this scenario, when we try to compared sections, it would be better to support suppress builtin macro redefined warnings for __LINE__ macro. libcpp: * init.cc (builtin_array): Do not always warn for a redefinition of __LINE__. gcc/testsuite * gcc.dg/builtin-redefine.c: Test for redefintion warnings for __LINE__. * gcc.dg/builtin-redefine-1.c: New test.
2023-03-26Daily bump.GCC Administrator1-0/+6
2023-03-24diagnostics: ensure that .sarif files are UTF-8 encoded [PR109098]David Malcolm2-0/+28
PR analyzer/109098 notes that the SARIF spec mandates that .sarif files are UTF-8 encoded, but -fdiagnostics-format=sarif-file naively assumes that the source files are UTF-8 encoded when quoting source artefacts in the .sarif output, which can lead to us writing out .sarif files with non-UTF-8 bytes in them (which break my reporting scripts). The root cause is that sarif_builder::maybe_make_artifact_content_object was using maybe_read_file to load the file content as bytes, and assuming they were UTF-8 encoded. This patch reworks both overloads of this function (one used for the whole file, the other for snippets of quoted lines) so that they go through input.cc's file cache, which attempts to decode the input files according to the input charset, and then encode as UTF-8. They also check that the result actually is UTF-8, for cases where the input charset is missing, or incorrectly specified, and omit the quoted source for such awkward cases. Doing so fixes all of the cases I've encountered. The patch adds a new: { dg-final { verify-sarif-file } } directive to all SARIF test cases in the test suite, which verifies that the output is UTF-8 encoded, and is valid JSON. In particular it verifies that when we complain about encoding problems, the .sarif report we emit is itself correctly encoded. gcc/ChangeLog: PR analyzer/109098 * diagnostic-format-sarif.cc (read_until_eof): Delete. (maybe_read_file): Delete. (sarif_builder::maybe_make_artifact_content_object): Use get_source_file_content rather than maybe_read_file. Reject it if it's not valid UTF-8. * input.cc (file_cache_slot::get_full_file_content): New. (get_source_file_content): New. (selftest::check_cpp_valid_utf8_p): New. (selftest::test_cpp_valid_utf8_p): New. (selftest::input_cc_tests): Call selftest::test_cpp_valid_utf8_p. * input.h (get_source_file_content): New prototype. gcc/testsuite/ChangeLog: PR analyzer/109098 * c-c++-common/diagnostic-format-sarif-file-1.c: Add verify-sarif-file directive. * c-c++-common/diagnostic-format-sarif-file-2.c: Likewise. * c-c++-common/diagnostic-format-sarif-file-3.c: Likewise. * c-c++-common/diagnostic-format-sarif-file-4.c: Likewise. * c-c++-common/diagnostic-format-sarif-file-Wbidi-chars.c: New test case, adapted from Wbidi-chars-1.c. * c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-1.c: New test case. * c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-2.c: New test case. * c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-3.c: New test case, adapted from cpp/Winvalid-utf8-1.c. * c-c++-common/diagnostic-format-sarif-file-valid-CP850.c: New test case, adapted from gcc.dg/diagnostic-input-charset-1.c. * gcc.dg/plugin/crash-test-ice-sarif.c: Add verify-sarif-file directive. * gcc.dg/plugin/crash-test-write-though-null-sarif.c: Likewise. * gcc.dg/plugin/diagnostic-test-paths-5.c: Likewise. * lib/scansarif.exp (verify-sarif-file): New procedure. * lib/verify-sarif-file.py: New support script. libcpp/ChangeLog: PR analyzer/109098 * charset.cc (cpp_valid_utf8_p): New function. * include/cpplib.h (cpp_valid_utf8_p): New prototype. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2023-03-17Daily bump.GCC Administrator1-0/+8
2023-03-16libcpp: Update Unicode copyright yearsJakub Jelinek4-4/+4
I've noticed I forgot to update copyright years when updating from Unicode 15.0.0 (and makeucnid.cc had it hopelessly obsolete). 2023-03-16 Jakub Jelinek <jakub@redhat.com> * makeucnid.cc (write_copyright): Update Unicode copyright years up to 2022. * makeuname2c.cc (write_copyright): Likewise. * ucnid.h: Regenerated. * uname2c.h: Regenerated.
2023-03-14Daily bump.GCC Administrator1-0/+10
2023-03-13libcpp: Fix ICE on directive inside _Pragma() operator [PR67046]Lewis Hyatt1-0/+5
get__Pragma_string() in directives.cc is responsible for lexing the parens and the string argument from a _Pragma("...") operator. This function does not handle the case when the closing paren is not on the same line as the string; in that case, libcpp will by default reuse the token buffer it previously used for the string, so that the string token returned by get__Pragma_string() may be corrupted, as shown in the testcase. Fix using the existing keep_tokens mechanism that temporarily disables the reuse of token buffers. libcpp/ChangeLog: PR preprocessor/67046 * directives.cc (_cpp_do__Pragma): Increment pfile->keep_tokens to ensure the returned string token is valid. gcc/testsuite/ChangeLog: PR preprocessor/67046 * c-c++-common/cpp/pr67046.c: New test.
2023-03-13libcpp: Update cpp_wcwidth() to Unicode 15Lewis Hyatt1-54/+56
Updates cpp_wcwidth() to Unicode 15, following the procedure in contrib/unicode/README mechanically without incident. contrib/ChangeLog: * unicode/DerivedCoreProperties.txt: Update to Unicode 15. * unicode/DerivedNormalizationProps.txt: Likewise. * unicode/EastAsianWidth.txt: Likwise. * unicode/PropList.txt: Likewise. * unicode/README: Likewise. * unicode/UnicodeData.txt: Likewise. libcpp/ChangeLog: * generated_cpp_wcwidth.h: Regenerated for Unicode 15.
2023-03-01Daily bump.GCC Administrator1-0/+4
2023-02-28Update cpplib sr.po, sv.poJoseph Myers2-83/+57
* sr.po, sv.po: Update.
2023-02-25Daily bump.GCC Administrator1-0/+6
2023-02-24Update .po filesJoseph Myers23-4305/+6832
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, 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.
2023-02-11Daily bump.GCC Administrator1-0/+4
2023-02-10Regenerate .pot filesJoseph Myers1-212/+329
gcc/po/ * gcc.pot: Regenerate. libcpp/po/ * cpplib.pot: Regenerate.
2023-01-17Daily bump.GCC Administrator1-0/+4
2023-01-16Add cpplib ka.poJoseph Myers1-0/+1110
* ka.po: New.
2023-01-16Update copyright years.Jakub Jelinek26-28/+28
2023-01-10Daily bump.GCC Administrator1-0/+4
2023-01-09Update cpplib eo.poJoseph Myers1-39/+28
* eo.po: Update.
2023-01-02Update Copyright year in ChangeLog filesJakub Jelinek1-1/+1
2022 -> 2023
2022-12-08Daily bump.GCC Administrator1-0/+6
2022-12-07preprocessor: Enable __VA_OPT__ for C2xJoseph Myers3-4/+10
C2x supports __VA_OPT__, so adjust libcpp not to pedwarn for uses of it (or of not passing any variable arguments to a variable-arguments macro) in standard C2x mode. I didn't try to duplicate existing tests for the details of the feature, just verified -pedantic-errors handling is as expected. And there's a reasonable argument (bug 98859) that __VA_OPT__ shouldn't be diagnosed in older standard modes at all (as opposed to not passing any variable arguments to a variable-arguments macro, for which older versions of the C standard require a diagnostic as a constraint violation); that argument applies to C as much as to C++, but I haven't made any changes in that regard. Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ * init.cc (lang_defaults): Enable va_opt for STDC2X. * lex.cc (maybe_va_opt_error): Adjust diagnostic message for C. * macro.cc (_cpp_arguments_ok): Update comment. gcc/testsuite/ * gcc.dg/cpp/c11-vararg-1.c, gcc.dg/cpp/c2x-va-opt-1.c: New tests.
2022-11-24Daily bump.GCC Administrator1-0/+15
2022-11-22Revert "configure: Implement --enable-host-pie"Marek Polacek2-38/+3
This reverts commit 251c72a68af3a8b0638705b73ef120ffdf0053eb.
2022-11-22configure: Implement --enable-host-pieMarek Polacek2-3/+38
This patch implements the --enable-host-pie configure option which makes the compiler executables PIE. This can be used to enhance protection against ROP attacks, and can be viewed as part of a wider trend to harden binaries. It is similar to the option --enable-host-shared, except that --e-h-s won't add -shared to the linker flags whereas --e-h-p will add -pie. It is different from --enable-default-pie because that option just adds an implicit -fPIE/-pie when the compiler is invoked, but the compiler itself isn't PIE. Since r12-5768-gfe7c3ecf, PCH works well with PIE, so there are no PCH regressions. When building the compiler, the build process may use various in-tree libraries; these need to be built with -fPIE so that it's possible to use them when building a PIE. For instance, when --with-included-gettext is in effect, intl object files must be compiled with -fPIE. Similarly, when building in-tree gmp, isl, mpfr and mpc, they must be compiled with -fPIE. I plan to add an option to link with -Wl,-z,now. ChangeLog: * Makefile.def: Pass $(PICFLAG) to AM_CFLAGS for gmp, mpfr, mpc, and isl. * Makefile.in: Regenerate. * Makefile.tpl: Set PICFLAG. * configure.ac (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate. c++tools/ChangeLog: * Makefile.in: Rename PIEFLAG to PICFLAG. Set LD_PICFLAG. Use it. Use pic/libiberty.a if PICFLAG is set. * configure.ac (--enable-default-pie): Set PICFLAG instead of PIEFLAG. (--enable-host-pie): New check. * configure: Regenerate. fixincludes/ChangeLog: * Makefile.in: Set and use PICFLAG and LD_PICFLAG. Use the "pic" build of libiberty if PICFLAG is set. * configure.ac: * configure: Regenerate. gcc/ChangeLog: * Makefile.in: Set LD_PICFLAG. Use it. Set enable_host_pie. Remove NO_PIE_CFLAGS and NO_PIE_FLAG. Pass LD_PICFLAG to ALL_LINKERFLAGS. Use the "pic" build of libiberty if --enable-host-pie. * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG and LD_PICFLAG after this check. * configure: Regenerate. * doc/install.texi: Document --enable-host-pie. gcc/d/ChangeLog: * Make-lang.in: Remove NO_PIE_CFLAGS. intl/ChangeLog: * Makefile.in: Use @PICFLAG@ in COMPILE as well. * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate. libcody/ChangeLog: * Makefile.in: Pass LD_PICFLAG to LDFLAGS. * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG and LD_PICFLAG after this check. * configure: Regenerate. libcpp/ChangeLog: * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate. libdecnumber/ChangeLog: * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate. libiberty/ChangeLog: * configure.ac: Also set shared when enable_host_pie. * configure: Regenerate. zlib/ChangeLog: * configure.ac (--enable-host-shared): Don't set PICFLAG here. (--enable-host-pie): New check. Set PICFLAG after this check. * configure: Regenerate.
2022-11-22Daily bump.GCC Administrator1-0/+13
2022-11-21libcpp: Fix paste error with unknown pragma after macro expansionLewis Hyatt1-5/+5
In directives.cc, do_pragma() contains logic to handle a case such as the new testcase pragma-omp-unknown.c, where an unknown pragma was the result of macro expansion (for pragma namespaces that permit expansion). This no longer works correctly as shown by the testcase, fixed by adding PREV_WHITE to the flags on the second token to prevent an unwanted paste. Also fixed the memory leak, since the temporary tokens are pushed on their own context, nothing prevents freeing of the buffer that holds them when the context is eventually popped. libcpp/ChangeLog: * directives.cc (do_pragma): Fix memory leak in token buffer. Fix unwanted paste between two tokens. gcc/testsuite/ChangeLog: * c-c++-common/gomp/pragma-omp-unknown.c: New test.
2022-11-21libcpp/remap: Only override if string matchedTorbjörn SVENSSON1-1/+1
For systems with HAVE_DOS_BASED_FILE_SYSTEM set, only override the pointer if the backslash pattern matches. Output without this patch: .../gcc/testsuite/gcc.dg/cpp/pr71681-2.c:5:10: fatal error: a/t2.h: No such file or directory With patch applied, no output and the test case succeeds. libcpp/ChangeLog * files.cc: Ensure pattern matches before use. Signed-off-by: Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
2022-11-21build: re-configure 2 filesMartin Liska1-0/+6
libcpp/ChangeLog: * config.in: Re-configure. libstdc++-v3/ChangeLog: * src/experimental/Makefile.in: Re-configure.
2022-11-21Daily bump.GCC Administrator1-0/+11
2022-11-19libcpp: Add missing config for --enable-valgrind-annotations [PR107691]Bernhard Reutner-Fischer2-0/+92
r7-912 copied (parts of) the valgrind annotation checks from gcc to libcpp. The above copies the missing pieces to libcpp to diagnose when libcpp is configured with --enable-valgrind-annotations but valgrind is not installed. libcpp/ChangeLog: PR preprocessor/107691 * configure.ac: Add valgrind header checks. * configure: Regenerate.
2022-11-18libcpp: Avoid remapping filenames within directivesRichard Purdie1-1/+1
Code such as: #include __FILE__ can interact poorly with the *-prefix-map options when cross compiling. In general you're after to remap filenames for use in target context but the local paths should be used to find include files at compile time. Ingoring filename remapping for directives allows avoiding such failures. Fix this to improve such usage and then document this against file-prefix-map (referenced by the other *-prefix-map options) to make the behaviour clear and defined. libcpp/ChangeLog: * macro.cc (_cpp_builtin_macro_text): Don't remap filenames within directives. gcc/ChangeLog: * doc/invoke.texi: Document prefix-maps don't affect directives.
2022-11-06Daily bump.GCC Administrator1-0/+16
2022-11-05c++: libcpp: Support raw strings with newlines in directives [PR55971]Lewis Hyatt1-9/+32
It's not currently possible to use a C++11 raw string containing a newline as part of the definition of a macro, or in any other preprocessing directive, such as: #define X R"(two lines)" #error R"(this error has two lines)" Add support for that by relaxing the conditions under which _cpp_get_fresh_line() refuses to get a new line. For the case of lexing a raw string, it's OK to do so as long as there is another line within the current buffer. The code in cpp_get_fresh_line() was refactored into a new function get_fresh_line_impl(), so that the new logic is applied only when processing a raw string and not any other times. libcpp/ChangeLog: PR preprocessor/55971 * lex.cc (get_fresh_line_impl): New function refactoring the code from... (_cpp_get_fresh_line): ...here. (lex_raw_string): Use the new version of get_fresh_line_impl() to support raw strings containing new lines when processing a directive. gcc/testsuite/ChangeLog: PR preprocessor/55971 * c-c++-common/raw-string-directive-1.c: New test. * c-c++-common/raw-string-directive-2.c: New test. gcc/c-family/ChangeLog: PR preprocessor/55971 * c-ppoutput.cc (adjust_for_newlines): Update comment.
2022-11-04libcpp: Update to Unicode 15Jakub Jelinek3-16992/+17201
The following pseudo-patch regenerates the libcpp tables with Unicode 15.0.0 which added 4489 new characters. As mentioned previously, this isn't just a matter of running the two libcpp/make*.cc programs on the new Unicode files, but one needs to manually update a table inside of makeuname2c.cc according to a table in Unicode text (which is partially reflected in the text files, but e.g. in Unicode 14.0.0 not 100% accurately, in 15.0.0 actually accurately). I've also added some randomly chosen subset of those 4489 new characters to a testcase. 2022-11-04 Jakub Jelinek <jakub@redhat.com> gcc/testsuite/ * c-c++-common/cpp/named-universal-char-escape-1.c: Add tests for some characters newly added in Unicode 15.0.0. libcpp/ * makeuname2c.cc (struct generated): Update from Unicode 15.0.0 table 4-8. * ucnid.h: Regenerated for Unicode 15.0.0. * uname2c.h: Likewise.
2022-10-20Daily bump.GCC Administrator1-0/+5
2022-10-19pch: Fix streaming of strings with embedded null bytesLewis Hyatt2-2/+9
When a GTY'ed struct is streamed to PCH, any plain char* pointers it contains (whether they live in GC-controlled memory or not) will be marked for PCH output by the routine gt_pch_note_object in ggc-common.cc. This routine special-cases plain char* strings, and in particular it uses strlen() to get their length. Thus it does not handle strings with embedded null bytes, but it is possible for something PCH cares about (such as a string literal token in a macro definition) to contain such embedded nulls. To fix that up, add a new GTY option "string_length" so that gt_pch_note_object can be informed the actual length it ought to use, and use it in the relevant libcpp structs (cpp_string and ht_identifier) accordingly. gcc/ChangeLog: * gengtype.cc (output_escaped_param): Add missing const. (get_string_option): Add missing check for option type. (walk_type): Support new "string_length" GTY option. (write_types_process_field): Likewise. * ggc-common.cc (gt_pch_note_object): Add optional length argument. * ggc.h (gt_pch_note_object): Adjust prototype for new argument. (gt_pch_n_S2): Declare... * stringpool.cc (gt_pch_n_S2): ...new function. * doc/gty.texi: Document new GTY((string_length)) option. libcpp/ChangeLog: * include/cpplib.h (struct cpp_string): Use new "string_length" GTY. * include/symtab.h (struct ht_identifier): Likewise. gcc/testsuite/ChangeLog: * g++.dg/pch/pch-string-nulls.C: New test. * g++.dg/pch/pch-string-nulls.Hs: New test.
2022-10-15Daily bump.GCC Administrator1-0/+17
2022-10-14preprocessor: C2x identifier rulesJoseph Myers4-33/+40
C2x has, like C++, adopted rules for identifiers based directly on an unversioned normative reference to Unicode. Make libcpp follow those rules for c2x / gnu2x standards (this involves bringing back a flag separate from the C++ one for whether to use these identifier rules, but this time enabled for all C++ language versions since that was the conclusion adopted for C++ identifier handling). There is one change here that affects C++. I believe the new normative requirement for NFC only applies to identifiers, not to the use of identifier-continue characters in pp-numbers, where there is no such requirement and so the diagnostic ought to be a warning not a pedwarn in pp-numbers, and that this is the case for both C and C++. Bootstrapped with no regressions for x86_64-pc-linux-gnu. libcpp/ * charset.cc (ucn_valid_in_identifier): Check xid_identifiers not cplusplus to determine whether to use CXX23 and NXX23 flags. * include/cpplib.h (struct cpp_options): Add xid_identifiers. * init.cc (struct lang_flags, lang_defaults): Add xid_identifiers. (cpp_set_lang): Set xid_identifiers. * lex.cc (warn_about_normalization): Add parameter identifier. Only pedwarn about non-NFC for identifiers, not pp-numbers. (_cpp_lex_direct): Update calls to warn_about_normalization. gcc/testsuite/ * gcc.dg/cpp/c2x-ucnid-1-utf8.c, gcc.dg/cpp/c2x-ucnid-1.c: New tests.
2022-10-14middle-end, c++, i386, libgcc: std::bfloat16_t and __bf16 arithmetic supportJakub Jelinek2-4/+20
Here is a complete patch to add std::bfloat16_t support on x86 (AArch64 and ARM left for later). Almost no BFmode optabs are added by the patch, so for binops/unops it extends to SFmode first and then truncates back to BFmode. For {HF,SF,DF,XF,TF}mode -> BFmode conversions libgcc has implementations of all those conversions so that we avoid double rounding, for BFmode -> {DF,XF,TF}mode conversions to avoid growing libgcc too much it emits BFmode -> SFmode conversion first and then converts to the even wider mode, neither step should be imprecise. For BFmode -> HFmode, it first emits a precise BFmode -> SFmode conversion and then SFmode -> HFmode, because neither format is subset or superset of the other, while SFmode is superset of both. expr.cc then contains a -ffast-math optimization of the BF -> SF and SF -> BF conversions if we don't optimize for space (and for the latter if -frounding-math isn't enabled either). For x86, perhaps truncsfbf2 optab could be defined for TARGET_AVX512BF16 but IMNSHO should FAIL if !flag_finite_math || flag_rounding_math || !flag_unsafe_math_optimizations, because I think the insn doesn't raise on sNaNs, hardcodes round to nearest and flushes denormals to zero. By default (unless x86 -fexcess-precision=16) we use float excess precision for BFmode, so truncate only on explicit casts and assignments. The patch introduces a single __bf16 builtin - __builtin_nansf16b, because (__bf16) __builtin_nansf ("") will drop the sNaN into qNaN, and uses f16b suffix instead of bf16 because there would be ambiguity on log vs. logb - __builtin_logbf16 could be either log with bf16 suffix or logb with f16 suffix. In other cases libstdc++ should mostly use __builtin_*f for std::bfloat16_t overloads (we have a problem with std::nextafter though but that one we have also for std::float16_t). 2022-10-14 Jakub Jelinek <jakub@redhat.com> gcc/ * tree-core.h (enum tree_index): Add TI_BFLOAT16_TYPE. * tree.h (bfloat16_type_node): Define. * tree.cc (excess_precision_type): Promote bfloat16_type_mode like float16_type_mode. (build_common_tree_nodes): Initialize bfloat16_type_node if BFmode is supported. * expmed.h (maybe_expand_shift): Declare. * expmed.cc (maybe_expand_shift): No longer static. * expr.cc (convert_mode_scalar): Don't ICE on BF -> HF or HF -> BF conversions. If there is no optab, handle BF -> {DF,XF,TF,HF} conversions as separate BF -> SF -> {DF,XF,TF,HF} conversions, add -ffast-math generic implementation for BF -> SF and SF -> BF conversions. * builtin-types.def (BT_BFLOAT16, BT_FN_BFLOAT16_CONST_STRING): New. * builtins.def (BUILT_IN_NANSF16B): New builtin. * fold-const-call.cc (fold_const_call): Handle CFN_BUILT_IN_NANSF16B. * config/i386/i386.cc (classify_argument): Handle E_BCmode. (ix86_libgcc_floating_mode_supported_p): Also return true for BFmode for -msse2. (ix86_mangle_type): Mangle BFmode as DF16b. (ix86_invalid_conversion, ix86_invalid_unary_op, ix86_invalid_binary_op): Remove. (TARGET_INVALID_CONVERSION, TARGET_INVALID_UNARY_OP, TARGET_INVALID_BINARY_OP): Don't redefine. * config/i386/i386-builtins.cc (ix86_bf16_type_node): Remove. (ix86_register_bf16_builtin_type): Use bfloat16_type_node rather than ix86_bf16_type_node, only create it if still NULL. * config/i386/i386-builtin-types.def (BFLOAT16): Likewise. * config/i386/i386.md (cbranchbf4, cstorebf4): New expanders. gcc/c-family/ * c-cppbuiltin.cc (c_cpp_builtins): If bfloat16_type_node, predefine __BFLT16_*__ macros and for C++23 also __STDCPP_BFLOAT16_T__. Predefine bfloat16_type_node related macros for -fbuilding-libgcc. * c-lex.cc (interpret_float): Handle CPP_N_BFLOAT16. gcc/c/ * c-typeck.cc (convert_arguments): Don't promote __bf16 to double. gcc/cp/ * cp-tree.h (extended_float_type_p): Return true for bfloat16_type_node. * typeck.cc (cp_compare_floating_point_conversion_ranks): Set extended{1,2} if mv{1,2} is bfloat16_type_node. Adjust comment. gcc/testsuite/ * lib/target-supports.exp (check_effective_target_bfloat16, check_effective_target_bfloat16_runtime, add_options_for_bfloat16): New. * gcc.dg/torture/bfloat16-basic.c: New test. * gcc.dg/torture/bfloat16-builtin.c: New test. * gcc.dg/torture/bfloat16-builtin-issignaling-1.c: New test. * gcc.dg/torture/bfloat16-complex.c: New test. * gcc.dg/torture/builtin-issignaling-1.c: Allow to be includable from bfloat16-builtin-issignaling-1.c. * gcc.dg/torture/floatn-basic.h: Allow to be includable from bfloat16-basic.c. * gcc.target/i386/vect-bfloat16-typecheck_2.c: Adjust expected diagnostics. * gcc.target/i386/sse2-bfloat16-scalar-typecheck.c: Likewise. * gcc.target/i386/vect-bfloat16-typecheck_1.c: Likewise. * g++.target/i386/bfloat_cpp_typecheck.C: Likewise. libcpp/ * include/cpplib.h (CPP_N_BFLOAT16): Define. * expr.cc (interpret_float_suffix): Handle bf16 and BF16 suffixes for C++. libgcc/ * config/i386/t-softfp (softfp_extensions): Add bfsf. (softfp_truncations): Add tfbf xfbf dfbf sfbf hfbf. (CFLAGS-extendbfsf2.c, CFLAGS-truncsfbf2.c, CFLAGS-truncdfbf2.c, CFLAGS-truncxfbf2.c, CFLAGS-trunctfbf2.c, CFLAGS-trunchfbf2.c): Add -msse2. * config/i386/libgcc-glibc.ver (GCC_13.0.0): Export __extendbfsf2 and __trunc{s,d,x,t,h}fbf2. * config/i386/sfp-machine.h (_FP_NANSIGN_B): Define. * config/i386/64/sfp-machine.h (_FP_NANFRAC_B): Define. * config/i386/32/sfp-machine.h (_FP_NANFRAC_B): Define. * soft-fp/brain.h: New file. * soft-fp/truncsfbf2.c: New file. * soft-fp/truncdfbf2.c: New file. * soft-fp/truncxfbf2.c: New file. * soft-fp/trunctfbf2.c: New file. * soft-fp/trunchfbf2.c: New file. * soft-fp/truncbfhf2.c: New file. * soft-fp/extendbfsf2.c: New file. libiberty/ * cp-demangle.h (D_BUILTIN_TYPE_COUNT): Increment. * cp-demangle.c (cplus_demangle_builtin_types): Add std::bfloat16_t entry. (cplus_demangle_type): Demangle DF16b. * testsuite/demangle-expected (_Z3xxxDF16b): New test.
generated by cgit v1.1 at 2025-01-01 01:54:59 +0000