mirror of
git://gcc.gnu.org/git/gcc.git
synced 2025-02-22 01:00:12 +08:00
f34422e06c
1353 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
GCC Administrator
|
4958fe2255 | Daily bump. | ||
Jason Merrill
|
7b8b96a327 |
libcpp: add .c++-header-unit target
The dependency output for header unit modules is based on the absolute pathname of the header file, but that's not something that a makefile can portably refer to. This patch adds a .c++-header-unit target based on the header name relative to an element of the include path. libcpp/ChangeLog: * internal.h (_cpp_get_file_dir): Declare. * files.cc (_cpp_get_file_dir): New fn. * mkdeps.cc (make_write): Use it. gcc/testsuite/ChangeLog: * g++.dg/modules/dep-4.H: New test. |
||
|
GCC Administrator
|
24da863403 | Daily bump. | ||
|
Jason Merrill
|
dbfbd3aa2c |
c-family: add -fsearch-include-path
The C++ modules code has a -fmodule-header (or -x c++-{user,system}-header)
option to specify looking up headers to compile to header units on the usual
include paths. I'd like to have the same functionality for full C++20
modules such as module std, which I proposed to live on the include path at
bits/std.cc. But this behavior doesn't seem necessarily connected to
modules, so I'm proposing a general C/C++ option to specify the behavior of
looking in the include path for the input files specified on the command
line.
Other ideas for the name of the option are very welcome.
The libcpp change is to allow -fsearch-include-path{,=user} to find files in
the current working directory, like -include. This can be handy for a quick
compile of both std.cc and a file that imports it, e.g.
g++ -std=c++20 -fmodules -fsearch-include-path bits/std.cc importer.cc
gcc/ChangeLog:
* doc/cppopts.texi: Document -fsearch-include-path.
* doc/invoke.texi: Mention it for modules.
gcc/c-family/ChangeLog:
* c.opt: Add -fsearch-include-path.
* c-opts.cc (c_common_post_options): Handle it.
gcc/cp/ChangeLog:
* module.cc (module_preprocess_options): Don't override it.
libcpp/ChangeLog:
* internal.h (search_path_head): Declare.
* files.cc (search_path_head): No longer static.
* init.cc (cpp_read_main_file): Use it.
|
||
|
GCC Administrator
|
349368aeba | Daily bump. | ||
Jakub Jelinek
|
1910ecf15b |
c: Add _Decimal64x support
The following patch adds _Decimal64x type support. Our dfp libraries (dpd & libbid) can only handle decimal32, decimal64 and decimal128 formats and I don't see that changing any time soon, so the following patch just hardcodes that _Decimal64x has the same mode as _Decimal128 (but is a distinct type). In the unlikely event some target would introduce something different that can be of course changed with target hooks but would be an ABI change. _Decimal128x is optional and we don't have a wider decimal type, so that type isn't added. 2024-11-15 Jakub Jelinek <jakub@redhat.com> gcc/ * tree-core.h (enum tree_index): Add TI_DFLOAT64X_TYPE. * tree.h (dfloat64x_type_node): Define. * tree.cc (build_common_tree_nodes): Initialize dfloat64x_type_node. * builtin-types.def (BT_DFLOAT64X): New DEF_PRIMITIVE_TYPE. (BT_FN_DFLOAT64X): New DEF_FUNCTION_TYPE_0. (BT_FN_DFLOAT64X_CONST_STRING, BT_FN_DFLOAT64X_DFLOAT64X): New DEF_FUNCTION_TYPE_1. * builtins.def (BUILT_IN_FABSD64X, BUILT_IN_INFD64X, BUILT_IN_NAND64X, BUILT_IN_NANSD64X): New builtins. * builtins.cc (expand_builtin): Handle BUILT_IN_FABSD64X. (fold_builtin_0): Handle BUILT_IN_INFD64X. (fold_builtin_1): Handle BUILT_IN_FABSD64X. * fold-const-call.cc (fold_const_call): Handle CFN_BUILT_IN_NAND64X and CFN_BUILT_IN_NANSD64X. * ginclude/float.h (DEC64X_MANT_DIG, DEC64X_MIN_EXP, DEC64X_MAX_EXP, DEC64X_MAX, DEC64X_EPSILON, DEC64X_MIN, DEC64X_TRUE_MIN, DEC64X_SNAN): Redefine. gcc/c-family/ * c-common.h (enum rid): Add RID_DFLOAT64X. * c-common.cc (c_global_trees): Fix comment typo. Add dfloat64x_type_node. (c_common_nodes_and_builtins): Handle RID_DFLOAT64X. * c-cppbuiltin.cc (c_cpp_builtins): Call builtin_define_decimal_float_constants also for dfloat64x_type_node if non-NULL. * c-lex.cc (interpret_float): Handle d64x suffixes. * c-pretty-print.cc (pp_c_floating_constant): Print d64x suffixes on dfloat64x_type_node typed constants. gcc/c/ * c-tree.h (enum c_typespec_keyword): Add cts_dfloat64x and adjust comment. * c-parser.cc (c_keyword_starts_typename, c_token_starts_declspecs, c_parser_declspecs, c_parser_gnu_attribute_any_word): Handle RID_DFLOAT64X. (c_parser_postfix_expression): Handle _Decimal64x arguments in __builtin_tgmath. (warn_for_abs): Handle BUILT_IN_FABSD64X. * c-decl.cc (declspecs_add_type): Handle cts_dfloat64x and RID_DFLOAT64X. (finish_declspecs): Handle cts_dfloat64x. * c-typeck.cc (c_common_type): Handle dfloat64x_type_node. gcc/testsuite/ * gcc.dg/dfp/c11-decimal64x-1.c: New test. * gcc.dg/dfp/c11-decimal64x-2.c: New test. * gcc.dg/dfp/c23-decimal64x-1.c: New test. * gcc.dg/dfp/c23-decimal64x-2.c: New test. * gcc.dg/dfp/c23-decimal64x-3.c: New test. * gcc.dg/dfp/c23-decimal64x-4.c: New test. libcpp/ * expr.cc (interpret_float_suffix): Handle d64x and D64x suffixes, adjust comment. |
||
|
GCC Administrator
|
5673fc0c7b | Daily bump. | ||
|
Jakub Jelinek
|
856809e582 |
c: Handle C23 floating constant {d,D}{32,64,128} suffixes like {df,dd,dl}
C23 roughly says that {d,D}{32,64,128} floating point constant suffixes
are alternate spellings of {df,dd,dl} suffixes in annex H.
So, the following patch allows that alternate spelling.
Or is it intentional it isn't enabled and we need to do everything in
there first before trying to define __STDC_IEC_60559_DFP__?
Like add support for _Decimal32x and _Decimal64x types (including
the d32x and d64x suffixes) etc.
2024-11-13 Jakub Jelinek <jakub@redhat.com>
libcpp/
* expr.cc (interpret_float_suffix): Handle d32 and D32 suffixes
for C like df, d64 and D64 like dd and d128 and D128 like
dl.
gcc/c-family/
* c-lex.cc (interpret_float): Subtract 3 or 4 from copylen
rather than 2 if last character of CPP_N_DFLOAT is a digit.
gcc/testsuite/
* gcc.dg/dfp/c11-constants-3.c: New test.
* gcc.dg/dfp/c11-constants-4.c: New test.
* gcc.dg/dfp/c23-constants-3.c: New test.
* gcc.dg/dfp/c23-constants-4.c: New test.
|
||
|
Jakub Jelinek
|
eb45d151fa |
c: Implement C2Y N3298 - Introduce complex literals [PR117029]
The following patch implements the C2Y N3298 paper Introduce complex literals by providing different (or no) diagnostics on imaginary constants (except for integer ones). For _DecimalN constants we don't support _Complex _DecimalN and error on any i/j suffixes mixed with DD/DL/DF, so nothing changed there. 2024-11-13 Jakub Jelinek <jakub@redhat.com> PR c/117029 libcpp/ * include/cpplib.h (struct cpp_options): Add imaginary_constants member. * init.cc (struct lang_flags): Add imaginary_constants bitfield. (lang_defaults): Add column for imaginary_constants. (cpp_set_lang): Copy over imaginary_constants. * expr.cc (cpp_classify_number): Diagnose CPP_N_IMAGINARY non-CPP_N_FLOATING constants differently for C. gcc/testsuite/ * gcc.dg/cpp/pr7263-3.c: Adjust expected diagnostic wording. * gcc.dg/c23-imaginary-constants-1.c: New test. * gcc.dg/c23-imaginary-constants-2.c: New test. * gcc.dg/c23-imaginary-constants-3.c: New test. * gcc.dg/c23-imaginary-constants-4.c: New test. * gcc.dg/c23-imaginary-constants-5.c: New test. * gcc.dg/c23-imaginary-constants-6.c: New test. * gcc.dg/c23-imaginary-constants-7.c: New test. * gcc.dg/c23-imaginary-constants-8.c: New test. * gcc.dg/c23-imaginary-constants-9.c: New test. * gcc.dg/c23-imaginary-constants-10.c: New test. * gcc.dg/c2y-imaginary-constants-1.c: New test. * gcc.dg/c2y-imaginary-constants-2.c: New test. * gcc.dg/c2y-imaginary-constants-3.c: New test. * gcc.dg/c2y-imaginary-constants-4.c: New test. * gcc.dg/c2y-imaginary-constants-5.c: New test. * gcc.dg/c2y-imaginary-constants-6.c: New test. * gcc.dg/c2y-imaginary-constants-7.c: New test. * gcc.dg/c2y-imaginary-constants-8.c: New test. * gcc.dg/c2y-imaginary-constants-9.c: New test. * gcc.dg/c2y-imaginary-constants-10.c: New test. * gcc.dg/c2y-imaginary-constants-11.c: New test. * gcc.dg/c2y-imaginary-constants-12.c: New test. |
||
|
GCC Administrator
|
441676b588 | Daily bump. | ||
|
Jakub Jelinek
|
1ae24f7e0b |
c++: Attempt to implement C++26 P3034R1 - Module Declarations Shouldn't be Macros [PR114461]
This is an attempt to implement the https://wg21.link/p3034r1 paper, but I'm afraid the wording in the paper is bad for multiple reasons. I think I understand the intent, that the module name and partition if any shouldn't come from macros so that they can be scanned for without preprocessing, but on the other side doesn't want to disable macro expansion in pp-module altogether, because e.g. the optional attribute in module-declaration would be nice to come from macros as which exact attribute is needed might need to be decided based on preprocessor checks. The paper added https://eel.is/c++draft/cpp.module#2 which uses partly the wording from https://eel.is/c++draft/cpp.module#1 The first issue I see is that using that "defined as an object-like macro" from there means IMHO something very different in those 2 paragraphs. As per https://eel.is/c++draft/cpp.pre#7.sentence-1 preprocessing tokens in preprocessing directives aren't subject to macro expansion unless otherwise stated, and so the export and module tokens aren't expanded and so the requirement that they aren't defined as an object-like macro makes perfect sense. The problem with the new paragraph is that https://eel.is/c++draft/cpp.module#3.sentence-1 says that the rest of the tokens are macro expanded and after macro expansion none of the tokens can be defined as an object-like macro, if they would be, they'd be expanded to that. So, I think either the wording needs to change such that not all preprocessing tokens after module are macro expanded, only those which are after the pp-module-name and if any pp-module-partition tokens, or all tokens after module are macro expanded but none of the tokens in pp-module-name and pp-module-partition if any must come from macro expansion. The patch below implements it as if the former would be specified (but see later), so essentially scans the preprocessing tokens after module without expansion, if the first one is an identifier, it disables expansion for it and then if followed by . or : expects another such identifier (again with disabled expansion), but stops after second : is seen. Second issue is that while the global-module-fragment start is fine, matches the syntax of the new paragraph where the pp-tokens[opt] aren't present, there is also private-module-fragment in the syntax where module is followed by : private ; and in that case the colon doesn't match the pp-module-name grammar and appears now to be invalid. I think the https://eel.is/c++draft/cpp.module#2 paragraph needs to change so that it allows also that pp-tokens of a pp-module may also be : pp-tokens[opt] (and in that case, I think the colon shouldn't come from a macro and private and/or ; can). Third issue is that there are too many pp-tokens in https://eel.is/c++draft/cpp.module , one is all the tokens between module keyword and the semicolon and one is the optional extra tokens after pp-module-partition (if any, if missing, after pp-module). Perhaps introducing some other non-terminal would help talking about it? So in "where the pp-tokens (if any) shall not begin with a ( preprocessing token" it isn't obvious which pp-tokens it is talking about (my assumption is the latter) and also whether ( can't appear there just before macro expansion or also after expansion. The patch expects only before expansion, so #define F (); export module foo F would be valid during preprocessing but obviously invalid during compilation, but #define foo(n) n; export module foo (3) would be invalid already during preprocessing. The last issue applies only if the first issue is resolved to allow expansion of tokens after : if first token, or after pp-module-partition if present or after pp-module-name if present. When non-preprocessing scanner sees export module foo.bar:baz.qux; it knows nothing can come from preprocessing macros and is ok, but if it sees export module foo.bar:baz qux then it can't know whether it will be export module foo.bar:baz; or export module foo.bar:baz [[]]; or export module foo.bar:baz.freddy.garply; because qux could be validly a macro, which expands to ; or [[]]; or .freddy.garply; etc. So, either the non-preprocessing scanner would need to note it as possible export of foo.bar:baz* module partitions and preprocess if it needs to know the details or just compile, or if that is not ok, the wording would need to rule out that the expansion of (the second) pp-tokens if any can't start with . or : (colon would be only problematic if it isn't present in the tokens before it already). So, if e.g. defining qux above to . whatever is invalid, then the scanner can rely it sees the whole module name and partition. The patch below implements what is above described as the first variant of the first issue resolution, i.e. disables expansion of as many tokens as could be in the valid module name and module partition syntax, but as soon as it e.g. sees two adjacent identifiers, the second one can be macro expanded. If it is macro expanded though, the expansion can't start with . or :, and if it expands to nothing, tokens after it (whether they come from macro expansion or not) can't start with . or :. So, effectively: #define SEMI ; export module SEMI used to be valid and isn't anymore, #define FOO bar export module FOO; isn't valid, #define COLON : export module COLON private; isn't valid, #define BAR baz export module foo.bar:baz.qux.BAR; isn't valid, #define BAZ .qux export module foo BAZ; isn't valid, #define FREDDY :garply export module foo FREDDY; isn't valid, while #define QUX [[]] export module foo QUX; or #define GARPLY private module : GARPLY; etc. is. 2024-11-01 Jakub Jelinek <jakub@redhat.com> PR c++/114461 libcpp/ * include/cpplib.h: Implement C++26 P3034R1 - Module Declarations Shouldn’t be Macros (or more precisely its expected intent). (NO_DOT_COLON): Define. * internal.h (struct cpp_reader): Add diagnose_dot_colon_from_macro_p member. * lex.cc (cpp_maybe_module_directive): For pp-module, if module keyword is followed by CPP_NAME, ensure all CPP_NAME tokens possibly matching module name and module partition syntax aren't expanded and aren't defined as object-like macros. Verify first token after that doesn't start with open paren. If the next token after module name/partition is CPP_NAME defined as macro, set NO_DOT_COLON flag on it. * macro.cc (cpp_get_token_1): Set pfile->diagnose_dot_colon_from_macro_p if token to be expanded has NO_DOT_COLON bit set in flags. Before returning, if pfile->diagnose_dot_colon_from_macro_p is true and not returning CPP_PADDING or CPP_COMMENT and not during macro expansion preparation, set pfile->diagnose_dot_colon_from_macro_p to false and diagnose if returning CPP_DOT or CPP_COLON. gcc/testsuite/ * g++.dg/modules/cpp-7.C: New test. * g++.dg/modules/cpp-8.C: New test. * g++.dg/modules/cpp-9.C: New test. * g++.dg/modules/cpp-10.C: New test. * g++.dg/modules/cpp-11.C: New test. * g++.dg/modules/cpp-12.C: New test. * g++.dg/modules/cpp-13.C: New test. * g++.dg/modules/cpp-14.C: New test. * g++.dg/modules/cpp-15.C: New test. * g++.dg/modules/cpp-16.C: New test. * g++.dg/modules/cpp-17.C: New test. * g++.dg/modules/cpp-18.C: New test. * g++.dg/modules/cpp-19.C: New test. * g++.dg/modules/cpp-20.C: New test. * g++.dg/modules/pmp-4.C: New test. * g++.dg/modules/pmp-5.C: New test. * g++.dg/modules/pmp-6.C: New test. * g++.dg/modules/token-6.C: New test. * g++.dg/modules/token-7.C: New test. * g++.dg/modules/token-8.C: New test. * g++.dg/modules/token-9.C: New test. * g++.dg/modules/token-10.C: New test. * g++.dg/modules/token-11.C: New test. * g++.dg/modules/token-12.C: New test. * g++.dg/modules/token-13.C: New test. * g++.dg/modules/token-14.C: New test. * g++.dg/modules/token-15.C: New test. * g++.dg/modules/token-16.C: New test. * g++.dg/modules/dir-only-3.C: Expect an error. * g++.dg/modules/dir-only-4.C: Expect an error. * g++.dg/modules/dir-only-5.C: New test. * g++.dg/modules/atom-preamble-2_a.C: In export module malcolm; replace malcolm with kevin. Don't define malcolm macro. * g++.dg/modules/atom-preamble-4.C: Expect an error. * g++.dg/modules/atom-preamble-5.C: New test. |
||
|
GCC Administrator
|
c232f92161 | Daily bump. | ||
|
Jakub Jelinek
|
45ab93d9af |
non-gcc: Remove trailing whitespace
I've tried to build stage3 with -Wleading-whitespace=blanks -Wtrailing-whitespace=blank -Wno-error=leading-whitespace=blanks -Wno-error=trailing-whitespace=blank added to STRICT_WARN and that expectably resulted in about 2744 unique trailing whitespace warnings and 124837 leading whitespace warnings when excluding *.md files (which obviously is in big part a generator issue). Others from that are generator related, I think those need to be solved later. The following patch just fixes up the easy case (trailing whitespace), which could be easily automated: for i in `find . -name \*.h -o -name \*.cc -o -name \*.c | xargs grep -l '[ ]$' | grep -v testsuite/`; do sed -i -e 's/[ ]*$//' $i; done I've excluded files which I knew are obviously generated or go FE. Is there anything else we'd want to avoid the changes? Due to patch size, I've split it between gcc/ part and rest (include/, libiberty/, libgcc/, libcpp/, libstdc++-v3/; this part). 2024-10-24 Jakub Jelinek <jakub@redhat.com> include/ * dyn-string.h: Remove trailing whitespace. * libiberty.h: Likewise. * xregex.h: Likewise. * splay-tree.h: Likewise. * partition.h: Likewise. * plugin-api.h: Likewise. * demangle.h: Likewise. * vtv-change-permission.h: Likewise. * fibheap.h: Likewise. * hsa_ext_image.h: Likewise. * hashtab.h: Likewise. * libcollector.h: Likewise. * sort.h: Likewise. * symcat.h: Likewise. * hsa_ext_amd.h: Likewise. libcpp/ * directives.cc: Remove trailing whitespace. * mkdeps.cc: Likewise. * line-map.cc: Likewise. * internal.h: Likewise. * files.cc: Likewise. * init.cc: Likewise. * makeucnid.cc: Likewise. * system.h: Likewise. * include/line-map.h: Likewise. * include/symtab.h: Likewise. * include/cpplib.h: Likewise. * expr.cc: Likewise. * charset.cc: Likewise. * macro.cc: Likewise. * errors.cc: Likewise. * lex.cc: Likewise. * traditional.cc: Likewise. libgcc/ * crtstuff.c: Remove trailing whitespace. * libgcov.h: Likewise. * config/alpha/crtfastmath.c: Likewise. * config/alpha/vms-gcc_shell_handler.c: Likewise. * config/alpha/vms-unwind.h: Likewise. * config/pa/linux-atomic.c: Likewise. * config/pa/linux-unwind.h: Likewise. * config/pa/quadlib.c: Likewise. * config/pa/fptr.c: Likewise. * config/s390/32/_fixsfdi.c: Likewise. * config/s390/32/_fixunssfdi.c: Likewise. * config/s390/32/_fixunsdfdi.c: Likewise. * config/c6x/pr-support.c: Likewise. * config/lm32/_udivsi3.c: Likewise. * config/lm32/libgcc_lm32.h: Likewise. * config/lm32/_udivmodsi4.c: Likewise. * config/lm32/_mulsi3.c: Likewise. * config/lm32/_modsi3.c: Likewise. * config/lm32/_umodsi3.c: Likewise. * config/lm32/_divsi3.c: Likewise. * config/darwin-crt3.c: Likewise. * config/msp430/mpy.c: Likewise. * config/ia64/tf-signs.c: Likewise. * config/ia64/fde-vms.c: Likewise. * config/ia64/unwind-ia64.c: Likewise. * config/ia64/vms-unwind.h: Likewise. * config/ia64/sfp-exceptions.c: Likewise. * config/ia64/quadlib.c: Likewise. * config/ia64/unwind-ia64.h: Likewise. * config/rl78/vregs.h: Likewise. * config/arm/bpabi.c: Likewise. * config/arm/unwind-arm.c: Likewise. * config/arm/pr-support.c: Likewise. * config/arm/linux-atomic.c: Likewise. * config/arm/bpabi-lib.h: Likewise. * config/frv/frvend.c: Likewise. * config/frv/cmovw.c: Likewise. * config/frv/frvbegin.c: Likewise. * config/frv/cmovd.c: Likewise. * config/frv/cmovh.c: Likewise. * config/aarch64/cpuinfo.c: Likewise. * config/i386/crtfastmath.c: Likewise. * config/i386/cygming-crtend.c: Likewise. * config/i386/32/tf-signs.c: Likewise. * config/i386/crtprec.c: Likewise. * config/i386/sfp-exceptions.c: Likewise. * config/i386/w32-unwind.h: Likewise. * config/m32r/initfini.c: Likewise. * config/sparc/crtfastmath.c: Likewise. * config/gcn/amdgcn_veclib.h: Likewise. * config/nios2/linux-atomic.c: Likewise. * config/nios2/linux-unwind.h: Likewise. * config/nios2/lib2-mul.c: Likewise. * config/nios2/lib2-nios2.h: Likewise. * config/xtensa/unwind-dw2-xtensa.c: Likewise. * config/rs6000/darwin-fallback.c: Likewise. * config/rs6000/ibm-ldouble.c: Likewise. * config/rs6000/sfp-machine.h: Likewise. * config/rs6000/darwin-asm.h: Likewise. * config/rs6000/darwin-crt2.c: Likewise. * config/rs6000/aix-unwind.h: Likewise. * config/rs6000/sfp-exceptions.c: Likewise. * config/gthr-vxworks.c: Likewise. * config/riscv/atomic.c: Likewise. * config/visium/memcpy.c: Likewise. * config/darwin-crt-tm.c: Likewise. * config/stormy16/lib2funcs.c: Likewise. * config/arc/ieee-754/divtab-arc-sf.c: Likewise. * config/arc/ieee-754/divtab-arc-df.c: Likewise. * config/arc/initfini.c: Likewise. * config/sol2/gmon.c: Likewise. * config/microblaze/divsi3_table.c: Likewise. * config/m68k/fpgnulib.c: Likewise. * libgcov-driver.c: Likewise. * unwind-dw2.c: Likewise. * fp-bit.c: Likewise. * dfp-bit.h: Likewise. * dfp-bit.c: Likewise. * libgcov-driver-system.c: Likewise. libgcc/config/libbid/ * _le_td.c: Remove trailing whitespace. * bid128_compare.c: Likewise. * bid_div_macros.h: Likewise. * bid64_to_bid128.c: Likewise. * bid64_to_uint32.c: Likewise. * bid128_to_uint64.c: Likewise. * bid64_div.c: Likewise. * bid128_round_integral.c: Likewise. * bid_binarydecimal.c: Likewise. * bid128_string.c: Likewise. * bid_flag_operations.c: Likewise. * bid128_to_int64.c: Likewise. * _mul_sd.c: Likewise. * bid64_mul.c: Likewise. * bid128_noncomp.c: Likewise. * _gt_dd.c: Likewise. * bid64_add.c: Likewise. * bid64_string.c: Likewise. * bid_from_int.c: Likewise. * bid128.c: Likewise. * _ge_dd.c: Likewise. * _ne_sd.c: Likewise. * _dd_to_td.c: Likewise. * _unord_sd.c: Likewise. * bid64_to_uint64.c: Likewise. * _gt_sd.c: Likewise. * _sd_to_td.c: Likewise. * _addsub_td.c: Likewise. * _ne_td.c: Likewise. * bid_dpd.c: Likewise. * bid128_add.c: Likewise. * bid128_next.c: Likewise. * _lt_sd.c: Likewise. * bid64_next.c: Likewise. * bid128_mul.c: Likewise. * _lt_dd.c: Likewise. * _ge_td.c: Likewise. * _unord_dd.c: Likewise. * bid64_sqrt.c: Likewise. * bid_sqrt_macros.h: Likewise. * bid64_fma.c: Likewise. * _sd_to_dd.c: Likewise. * bid_conf.h: Likewise. * bid64_noncomp.c: Likewise. * bid_gcc_intrinsics.h: Likewise. * _gt_td.c: Likewise. * _ge_sd.c: Likewise. * bid128_minmax.c: Likewise. * bid128_quantize.c: Likewise. * bid32_to_bid64.c: Likewise. * bid_round.c: Likewise. * _td_to_sd.c: Likewise. * bid_inline_add.h: Likewise. * bid128_fma.c: Likewise. * _eq_td.c: Likewise. * bid32_to_bid128.c: Likewise. * bid64_rem.c: Likewise. * bid128_2_str_tables.c: Likewise. * _mul_dd.c: Likewise. * _dd_to_sd.c: Likewise. * bid128_div.c: Likewise. * _lt_td.c: Likewise. * bid64_compare.c: Likewise. * bid64_to_int32.c: Likewise. * _unord_td.c: Likewise. * bid128_rem.c: Likewise. * bid_internal.h: Likewise. * bid64_to_int64.c: Likewise. * _eq_dd.c: Likewise. * _td_to_dd.c: Likewise. * bid128_to_int32.c: Likewise. * bid128_to_uint32.c: Likewise. * _ne_dd.c: Likewise. * bid64_quantize.c: Likewise. * _le_dd.c: Likewise. * bid64_round_integral.c: Likewise. * _le_sd.c: Likewise. * bid64_minmax.c: Likewise. libgcc/config/avr/libf7/ * f7-renames.h: Remove trailing whitespace. libstdc++-v3/ * include/debug/debug.h: Remove trailing whitespace. * include/parallel/base.h: Likewise. * include/parallel/types.h: Likewise. * include/parallel/settings.h: Likewise. * include/parallel/multiseq_selection.h: Likewise. * include/parallel/partition.h: Likewise. * include/parallel/random_number.h: Likewise. * include/parallel/find_selectors.h: Likewise. * include/parallel/partial_sum.h: Likewise. * include/parallel/list_partition.h: Likewise. * include/parallel/search.h: Likewise. * include/parallel/algorithmfwd.h: Likewise. * include/parallel/random_shuffle.h: Likewise. * include/parallel/multiway_mergesort.h: Likewise. * include/parallel/sort.h: Likewise. * include/parallel/algobase.h: Likewise. * include/parallel/numericfwd.h: Likewise. * include/parallel/multiway_merge.h: Likewise. * include/parallel/losertree.h: Likewise. * include/bits/basic_ios.h: Likewise. * include/bits/stringfwd.h: Likewise. * include/bits/ostream_insert.h: Likewise. * include/bits/stl_heap.h: Likewise. * include/bits/unordered_map.h: Likewise. * include/bits/hashtable_policy.h: Likewise. * include/bits/stl_iterator_base_funcs.h: Likewise. * include/bits/valarray_before.h: Likewise. * include/bits/regex.h: Likewise. * include/bits/postypes.h: Likewise. * include/bits/stl_iterator.h: Likewise. * include/bits/localefwd.h: Likewise. * include/bits/stl_algo.h: Likewise. * include/bits/ios_base.h: Likewise. * include/bits/stl_function.h: Likewise. * include/bits/basic_string.h: Likewise. * include/bits/hashtable.h: Likewise. * include/bits/valarray_after.h: Likewise. * include/bits/char_traits.h: Likewise. * include/bits/gslice.h: Likewise. * include/bits/locale_facets_nonio.h: Likewise. * include/bits/mask_array.h: Likewise. * include/bits/specfun.h: Likewise. * include/bits/random.h: Likewise. * include/bits/slice_array.h: Likewise. * include/bits/valarray_array.h: Likewise. * include/tr1/float.h: Likewise. * include/tr1/functional_hash.h: Likewise. * include/tr1/math.h: Likewise. * include/tr1/hashtable_policy.h: Likewise. * include/tr1/stdio.h: Likewise. * include/tr1/complex.h: Likewise. * include/tr1/stdbool.h: Likewise. * include/tr1/stdarg.h: Likewise. * include/tr1/inttypes.h: Likewise. * include/tr1/fenv.h: Likewise. * include/tr1/stdlib.h: Likewise. * include/tr1/wchar.h: Likewise. * include/tr1/tgmath.h: Likewise. * include/tr1/limits.h: Likewise. * include/tr1/wctype.h: Likewise. * include/tr1/stdint.h: Likewise. * include/tr1/ctype.h: Likewise. * include/tr1/random.h: Likewise. * include/tr1/shared_ptr.h: Likewise. * include/ext/mt_allocator.h: Likewise. * include/ext/sso_string_base.h: Likewise. * include/ext/debug_allocator.h: Likewise. * include/ext/vstring_fwd.h: Likewise. * include/ext/pointer.h: Likewise. * include/ext/pod_char_traits.h: Likewise. * include/ext/malloc_allocator.h: Likewise. * include/ext/vstring.h: Likewise. * include/ext/bitmap_allocator.h: Likewise. * include/ext/pool_allocator.h: Likewise. * include/ext/type_traits.h: Likewise. * include/ext/ropeimpl.h: Likewise. * include/ext/codecvt_specializations.h: Likewise. * include/ext/throw_allocator.h: Likewise. * include/ext/extptr_allocator.h: Likewise. * include/ext/atomicity.h: Likewise. * include/ext/concurrence.h: Likewise. * include/c_compatibility/wchar.h: Likewise. * include/c_compatibility/stdint.h: Likewise. * include/backward/hash_fun.h: Likewise. * include/backward/binders.h: Likewise. * include/backward/hashtable.h: Likewise. * include/backward/auto_ptr.h: Likewise. * libsupc++/eh_arm.cc: Likewise. * libsupc++/unwind-cxx.h: Likewise. * libsupc++/si_class_type_info.cc: Likewise. * libsupc++/vec.cc: Likewise. * libsupc++/class_type_info.cc: Likewise. * libsupc++/vmi_class_type_info.cc: Likewise. * libsupc++/guard_error.cc: Likewise. * libsupc++/bad_typeid.cc: Likewise. * libsupc++/eh_personality.cc: Likewise. * libsupc++/atexit_arm.cc: Likewise. * libsupc++/pmem_type_info.cc: Likewise. * libsupc++/vterminate.cc: Likewise. * libsupc++/eh_terminate.cc: Likewise. * libsupc++/bad_cast.cc: Likewise. * libsupc++/exception_ptr.h: Likewise. * libsupc++/eh_throw.cc: Likewise. * libsupc++/bad_alloc.cc: Likewise. * libsupc++/nested_exception.cc: Likewise. * libsupc++/pointer_type_info.cc: Likewise. * libsupc++/pbase_type_info.cc: Likewise. * libsupc++/bad_array_new.cc: Likewise. * libsupc++/pure.cc: Likewise. * libsupc++/eh_exception.cc: Likewise. * libsupc++/bad_array_length.cc: Likewise. * libsupc++/cxxabi.h: Likewise. * libsupc++/guard.cc: Likewise. * libsupc++/eh_catch.cc: Likewise. * libsupc++/cxxabi_forced.h: Likewise. * libsupc++/tinfo.h: Likewise. |
||
|
GCC Administrator
|
fa546b6641 | Daily bump. | ||
|
Jakub Jelinek
|
d4499a232a |
libcpp: Add -Wleading-whitespace= warning
The following patch on top of the r15-4346 patch adds -Wleading-whitespace= warning option. This warning doesn't care how much one actually indents which line in the source (that is something that can't be easily done in the preprocessor without doing syntactic analysis), but just simple checks on what kind of whitespace is used in the indentation. I think it is still useful to get warnings about such issues early, while git diagnoses some of it in patches (e.g. the tab after space case), getting the warnings earlier might help avoiding such issues sooner. There are projects which ban use of tabs and require just spaces, others which require indentation just with horizontal tabs, and finally projects which want indentation with tabs for multiples of tabstop size followed by spaces (fewer than tabstop size), like GCC. For all 3 kinds the warning diagnoses indentation with '\v' or '\f' characters (unless line contains just whitespace), and for the last one also cases where a space in the indentation is followed by horizontal tab or where there are N or more consecutive spaces in the indentation (for -ftabstop=N). BTW, for additional testing I've enabled the warnings (without -Werror for them) in stage3. There are many warnings (both trailing and leading whitespace), some of them something that can be easily fixed in the headers or source files, but others with whitespace issues in generated sources, so if we enable the warnings, either we'd need to adjust the generators or disable the warnings in (some of the) generated files. 2024-10-23 Jakub Jelinek <jakub@redhat.com> libcpp/ * include/cpplib.h (struct cpp_options): Add cpp_warn_leading_whitespace and cpp_tabstop members. (enum cpp_warning_reason): Add CPP_W_LEADING_WHITESPACE. * internal.h (struct _cpp_line_note): Document new line note kinds. * init.cc (cpp_create_reader): Set cpp_tabstop to 8. * lex.cc (find_leading_whitespace_issues): New function. (_cpp_clean_line): Use it. (_cpp_process_line_notes): Handle 'L', 'S' and 'T' line notes. (lex_raw_string): Clear type on 'L', 'S' and 'T' line notes inside of raw string literals. gcc/ * doc/invoke.texi (Wleading-whitespace=): Document. gcc/c-family/ * c.opt (Wleading-whitespace=): New option. * c-opts.cc (c_common_post_options): Set cpp_opts->cpp_tabstop to global_dc->m_tabstop. gcc/testsuite/ * c-c++-common/cpp/Wleading-whitespace-1.c: New test. * c-c++-common/cpp/Wleading-whitespace-2.c: New test. * c-c++-common/cpp/Wleading-whitespace-3.c: New test. * c-c++-common/cpp/Wleading-whitespace-4.c: New test. |
||
|
GCC Administrator
|
2553983e76 | Daily bump. | ||
Lewis Hyatt
|
65c5bbe1c9
|
diagnostics: libcpp: Improve locations for _Pragma lexing diagnostics [PR114423]
libcpp is not currently set up to be able to generate valid
locations for tokens lexed from a _Pragma string. Instead, after obtaining
the tokens, it sets their locations all to the location of the _Pragma
operator itself. This makes things like _Pragma("GCC diagnostic") work well
enough, but if any diagnostics are issued during lexing, prior to resetting
the token locations, those diagnostics get issued at the invalid
locations. Fix that up by adding a new field pfile->diagnostic_override_loc
that instructs libcpp to issue diagnostics at the alternate location.
libcpp/ChangeLog:
PR preprocessor/114423
* internal.h (struct cpp_reader): Add DIAGNOSTIC_OVERRIDE_LOC
field.
* directives.cc (destringize_and_run): Set the new field to the
location of the _Pragma operator.
* errors.cc (cpp_diagnostic_at): Support DIAGNOSTIC_OVERRIDE_LOC to
temporarily issue diagnostics at a different location.
(cpp_diagnostic_with_line): Likewise.
gcc/testsuite/ChangeLog:
PR preprocessor/114423
* c-c++-common/cpp/pragma-diagnostic-loc.c: New test.
* c-c++-common/cpp/diagnostic-pragma-1.c: Adjust expected output.
* g++.dg/pch/operator-1.C: Likewise.
|
||
|
GCC Administrator
|
de14559ef5 | Daily bump. | ||
|
Jakub Jelinek
|
e020116db0 |
c, libcpp: Partially implement C2Y N3353 paper [PR117028]
The following patch partially implements the N3353 paper.
In particular, it adds support for the delimited escape sequences
(\u{123}, \x{123}, \o{123}) which were added already for C++23,
all I had to do is split the delimited escape sequence guarding from
named universal character escape sequence guards
(\N{LATIN CAPITAL LETTER C WITH CARON}), which C++23 has but C2Y doesn't
and emit different diagnostics for C from C++ for the delimited escape
sequences.
And it adds support for the new style of octal literals, 0o137 or 0O1777.
I have so far added that just for C and not C++, because I have no idea
whether C++ will want to handle it similarly.
What the patch doesn't do is any kind of diagnostics for obsoletion of
\137 or 0137, as discussed in the PR, I think it is way too early for that.
Perhaps some non-default warning later on.
2024-10-17 Jakub Jelinek <jakub@redhat.com>
PR c/117028
libcpp/
* include/cpplib.h (struct cpp_options): Add named_uc_escape_seqs,
octal_constants and cpp_warn_c23_c2y_compat members.
(enum cpp_warning_reason): Add CPP_W_C23_C2Y_COMPAT enumerator.
* init.cc (struct lang_flags): Add named_uc_escape_seqs and
octal_constants bit-fields.
(lang_defaults): Add initializers for them into the table.
(cpp_set_lang): Initialize named_uc_escape_seqs and octal_constants.
(cpp_create_reader): Initialize cpp_warn_c23_c2y_compat to -1.
* charset.cc (_cpp_valid_ucn): Test
CPP_OPTION (pfile, named_uc_escape_seqs) rather than
CPP_OPTION (pfile, delimited_escape_seqs) in \N{} related tests.
Change wording of C cpp_pedwarning for \u{} and emit
-Wc23-c2y-compat warning for it too if needed. Formatting fixes.
(convert_hex): Change wording of C cpp_pedwarning for \u{} and emit
-Wc23-c2y-compat warning for it too if needed.
(convert_oct): Likewise.
* expr.cc (cpp_classify_number): Handle C2Y 0o or 0O prefixed
octal constants.
(cpp_interpret_integer): Likewise.
gcc/c-family/
* c.opt (Wc23-c2y-compat): Add CPP and CppReason parameters.
* c-opts.cc (set_std_c2y): Use CLK_STDC2Y or CLK_GNUC2Y rather
than CLK_STDC23 and CLK_GNUC23. Formatting fix.
* c-lex.cc (interpret_integer): Handle C2Y 0o or 0O prefixed
and wb/WB/uwb/UWB suffixed octal constants.
gcc/testsuite/
* gcc.dg/bitint-112.c: New test.
* gcc.dg/c23-digit-separators-1.c: Add _Static_assert for
valid binary constant with digit separator.
* gcc.dg/c23-octal-constants-1.c: New test.
* gcc.dg/c23-octal-constants-2.c: New test.
* gcc.dg/c2y-digit-separators-1.c: New test.
* gcc.dg/c2y-digit-separators-2.c: New test.
* gcc.dg/c2y-octal-constants-1.c: New test.
* gcc.dg/c2y-octal-constants-2.c: New test.
* gcc.dg/c2y-octal-constants-3.c: New test.
* gcc.dg/cpp/c23-delimited-escape-seq-1.c: New test.
* gcc.dg/cpp/c23-delimited-escape-seq-2.c: New test.
* gcc.dg/cpp/c2y-delimited-escape-seq-1.c: New test.
* gcc.dg/cpp/c2y-delimited-escape-seq-2.c: New test.
* gcc.dg/cpp/c2y-delimited-escape-seq-3.c: New test.
* gcc.dg/cpp/c2y-delimited-escape-seq-4.c: New test.
* gcc.dg/octal-constants-1.c: New test.
* gcc.dg/octal-constants-2.c: New test.
* gcc.dg/octal-constants-3.c: New test.
* gcc.dg/octal-constants-4.c: New test.
* gcc.dg/system-octal-constants-1.c: New test.
* gcc.dg/system-octal-constants-1.h: New file.
|
||
|
Jakub Jelinek
|
e48a65d3b3 |
Ternary operator formatting fixes
While working on PR117028 C2Y changes, I've noticed weird ternary
operator formatting (operand1 ? operand2: operand3).
The usual formatting is operand1 ? operand2 : operand3
where we have around 18000+ cases of that (counting only what fits
on one line) and
indent -nbad -bap -nbc -bbo -bl -bli2 -bls -ncdb -nce -cp1 -cs -di2 -ndj \
-nfc1 -nfca -hnl -i2 -ip5 -lp -pcs -psl -nsc -nsob
documented in
https://www.gnu.org/prep/standards/html_node/Formatting.html#Formatting
does the same.
Some code was even trying to save space as much as possible and used
operand1?operand2:operand3 or
operand1 ? operand2:operand3
Today I've grepped for such cases (the grep was '?.*[^ ]:' and I had to
skim through various false positives with that where the : matched e.g.
stuff inside of strings, or *.md pattern macros or :: scope) and the
following patch is a fix for what I found.
2024-10-16 Jakub Jelinek <jakub@redhat.com>
gcc/
* attribs.cc (lookup_scoped_attribute_spec): ?: operator formatting
fixes.
* basic-block.h (FOR_BB_INSNS_SAFE): Likewise.
* cfgcleanup.cc (outgoing_edges_match): Likewise.
* cgraph.cc (cgraph_node::dump): Likewise.
* config/arc/arc.cc (gen_acc1, gen_acc2): Likewise.
* config/arc/arc.h (CLASS_MAX_NREGS, CONSTANT_ADDRESS_P): Likewise.
* config/arm/arm.cc (arm_print_operand): Likewise.
* config/cris/cris.md (*b<rnzcond:code><mode>): Likewise.
* config/darwin.cc (darwin_asm_declare_object_name,
darwin_emit_common): Likewise.
* config/darwin-driver.cc (darwin_driver_init): Likewise.
* config/epiphany/epiphany.md (call, sibcall, call_value,
sibcall_value): Likewise.
* config/i386/i386.cc (gen_push2): Likewise.
* config/i386/i386.h (ix86_cur_cost): Likewise.
* config/i386/openbsdelf.h (FUNCTION_PROFILER): Likewise.
* config/loongarch/loongarch-c.cc (loongarch_cpu_cpp_builtins):
Likewise.
* config/loongarch/loongarch-cpu.cc (fill_native_cpu_config):
Likewise.
* config/riscv/riscv.cc (riscv_union_memmodels): Likewise.
* config/riscv/zc.md (*mva01s<X:mode>, *mvsa01<X:mode>): Likewise.
* config/rs6000/mmintrin.h (_mm_cmpeq_pi8, _mm_cmpgt_pi8,
_mm_cmpeq_pi16, _mm_cmpgt_pi16, _mm_cmpeq_pi32, _mm_cmpgt_pi32):
Likewise.
* config/v850/predicates.md (pattern_is_ok_for_prologue): Likewise.
* config/xtensa/constraints.md (d, C, W): Likewise.
* coverage.cc (coverage_begin_function, build_init_ctor,
build_gcov_exit_decl): Likewise.
* df-problems.cc (df_create_unused_note): Likewise.
* diagnostic.cc (diagnostic_set_caret_max_width): Likewise.
* diagnostic-path.cc (path_summary::path_summary): Likewise.
* expr.cc (expand_expr_divmod): Likewise.
* gcov.cc (format_gcov): Likewise.
* gcov-dump.cc (dump_gcov_file): Likewise.
* genmatch.cc (main): Likewise.
* incpath.cc (remove_duplicates, register_include_chains): Likewise.
* ipa-devirt.cc (dump_odr_type): Likewise.
* ipa-icf.cc (sem_item_optimizer::merge_classes): Likewise.
* ipa-inline.cc (inline_small_functions): Likewise.
* ipa-polymorphic-call.cc (ipa_polymorphic_call_context::dump):
Likewise.
* ipa-sra.cc (create_parameter_descriptors): Likewise.
* ipa-utils.cc (find_always_executed_bbs): Likewise.
* predict.cc (predict_loops): Likewise.
* selftest.cc (read_file): Likewise.
* sreal.h (SREAL_SIGN, SREAL_ABS): Likewise.
* tree-dump.cc (dequeue_and_dump): Likewise.
* tree-ssa-ccp.cc (bit_value_binop): Likewise.
gcc/c-family/
* c-opts.cc (c_common_init_options, c_common_handle_option,
c_common_finish, set_std_c89, set_std_c99, set_std_c11,
set_std_c17, set_std_c23, set_std_cxx98, set_std_cxx11,
set_std_cxx14, set_std_cxx17, set_std_cxx20, set_std_cxx23,
set_std_cxx26): ?: operator formatting fixes.
gcc/cp/
* search.cc (lookup_member): ?: operator formatting fixes.
* typeck.cc (cp_build_modify_expr): Likewise.
libcpp/
* expr.cc (interpret_float_suffix): ?: operator formatting fixes.
|
||
|
GCC Administrator
|
d9e02add88 | Daily bump. | ||
|
Jakub Jelinek
|
1844a4aa66 |
libcpp, c, middle-end: Optimize initializers using #embed in C
This patch actually optimizes #embed, so far in C.
For a simple testcase (for 494447200 bytes long cc1plus):
cat embed-11.c
unsigned char a[] = {
#embed "cc1plus"
};
time ./xgcc -B ./ -S -std=c23 -O2 embed-11.c
real 0m13.647s
user 0m7.157s
sys 0m2.597s
time ./xgcc -B ./ -c -std=c23 -O2 embed-11.c
real 0m28.649s
user 0m26.653s
sys 0m1.958s
and when configured against binutils with .base64 support
time ./xgcc -B ./ -S -std=c23 -O2 embed-11.c
real 0m4.283s
user 0m2.288s
sys 0m0.859s
time ./xgcc -B ./ -c -std=c23 -O2 embed-11.c
real 0m6.888s
user 0m5.876s
sys 0m1.002s
(all times with --enable-checking=yes,rtl,extra compiler).
Even just
./cc1plus -E -o embed-11.i embed-11.c
(which doesn't have this optimization yet and so preprocesses it as
1.3GB preprocessed file) needed almost 25GB of compile time RAM (but
preprocessed fine).
And compiling that embed-11.i with -std=c23 -O0 by unpatched gcc
I gave up after 400 seconds when it already ate 45GB of RAM and didn't
produce a single byte into embed-11.s yet.
The patch introduces a new CPP_EMBED token which contains raw memory image
virtually representing a sequence of int literals.
To simplify the parsing complexities, the preprocessor guarantees CPP_EMBED
is only emitted if there are 4+ (it actually does that for 64+ right now)
literals in the sequence and emits CPP_NUMBER CPP_COMMA CPP_EMBED CPP_COMMA
CPP_NUMBER tokens (with more CPP_EMBED separated by CPP_COMMA if it is
longer than 2GB, as STRING_CSTs in GCC and also the new RAW_DATA_CST etc.
are limited to INT_MAX elements). The main reason is that the preprocessor
doesn't really know in which context #embed directive appears, there could
be e.g.
{ 25 *
#embed "whatever"
* 2 - 15 }
or similar and dealing with this special case deep in the expression parsing
is undesirable.
With the CPP_NUMBERs around it, I believe in the C FE the only places which
need handling of the CPP_EMBED token are initializer parsing (that is the
only one which adds actual optimizations for it), comma expressions (I
believe nothing really cares whether it is 25,13,95 or
25,13,0,1,2,3,4,5,6,7,8,9,10,13,95 etc., so besides the 2 outer CPP_NUMBER
the parsing just adds one INTEGER_CST to the comma expression, I doubt users
want to be spammed with millions of -Wunused warnings per #embed),
whatever uses c_parser_expr_list (function calls, attribute arguments,
OpenMP sizes clause argument, OpenACC tile clause argument and whatever uses
c_parser_get_builtin_args (mainly for __builtin_shufflevector). Please correct
me if I'm wrong.
The patch introduces a RAW_DATA_CST tree code, which can then be used inside
of array CONSTRUCTOR elt values. In some sense RAW_DATA_CST is similar to
STRING_CST, but right now STRING_CST is used only if the whole array
initializer is that constant, while RAW_DATA_CST at index idx (should be
always INTEGER_CST index, another advantage of the CPP_NUMBER around is that
[30 ... 250] =
#embed "whatever"
really does what it would do with a integer sequence there) stands for
[idx] = RAW_DATA_POINTER (val)[0],
[idx+1] = RAW_DATA_POINTER (val)[1],
...
[idx+RAW_DATA_LENGTH (val)-1] = RAW_DATA_POINTER (val)[RAW_DATA_LENGTH (val)-1].
Another important thing is that unlike STRING_CST which has the data
embedded in it RAW_DATA_CST doesn't own the data, it has RAW_DATA_OWNER
which owns the data (that can be a STRING_CST, e.g. used for PCH or LTO
after reading LTO in) or another RAW_DATA_CST (with NULL RAW_DATA_OWNER,
standing for data owned by libcpp buffers). The advantage is that it can be
cheaply peeled off, or split into multiple smaller pieces, e.g. if one uses
designated initializer to store something into the middle of a 10GB #embed
array, in no case we need to actually copy data around for that.
Right now RAW_DATA_CST is only used in initializers of integral arrays where
the integer type has (host) CHAR_BIT precision, so usually char/signed
char/unsigned char (for C++ later maybe std::byte); in theory we could say
allocate 4 times as big buffer for conversions to int array and depending
on endianity and storage order reversal etc., but I'm not sure if that is
something that will be actually needed in the wild.
And an optimization inside of c-common.cc attempts to undo that CPP_NUMBER
CPP_EMBED CPP_NUMBER division in case one uses #embed the usual way and
doesn't use the boundary literals in weird ways and the values there match
the surrounding bytes in the owner buffer.
For LTO, in order to avoid copying perhaps gigabytes long data around,
the hacks in the streamer out/in cause the data owned by libcpp to be
streamed right into the stream and streamed back as a STRING_CST which
owns the data.
2024-10-16 Jakub Jelinek <jakub@redhat.com>
libcpp/
* include/cpplib.h (TTYPE_TABLE): Add CPP_EMBED token type.
* files.cc (finish_embed): For limit >= 64 and C preprocessing
instead of emitting CPP_NUMBER CPP_COMMA separated sequence for the
whole embed emit it just for the first and last byte and in between
emit a CPP_EMBED token or tokens if too large.
gcc/
* treestruct.def (TS_RAW_DATA_CST): New.
* tree.def (RAW_DATA_CST): New tree code.
* tree-core.h (struct tree_raw_data): New type.
(union tree_node): Add raw_data_cst member.
* tree.h (RAW_DATA_LENGTH, RAW_DATA_POINTER, RAW_DATA_OWNER): Define.
(gt_ggc_mx, gt_pch_nx): Declare overloads for tree_raw_data *.
* tree.cc (tree_node_structure_for_code): Handle RAW_DATA_CST.
(initialize_tree_contains_struct): Handle TS_RAW_DATA_CST.
(tree_code_size): Handle RAW_DATA_CST.
(initializer_zerop): Likewise.
(gt_ggc_mx, gt_pch_nx): Define overloads for tree_raw_data *.
* gimplify.cc (gimplify_init_ctor_eval): Handle RAW_DATA_CST.
* fold-const.cc (operand_compare::operand_equal_p): Handle
RAW_DATA_CST. Formatting fix.
(operand_compare::hash_operand): Handle RAW_DATA_CST.
(native_encode_initializer): Likewise.
(get_array_ctor_element_at_index): Likewise.
(fold): Likewise.
* gimple-fold.cc (fold_array_ctor_reference): Likewise. Formatting
fix.
* varasm.cc (const_hash_1): Handle RAW_DATA_CST.
(initializer_constant_valid_p_1): Likewise.
(array_size_for_constructor): Likewise.
(output_constructor_regular_field): Likewise.
* expr.cc (categorize_ctor_elements_1): Likewise.
(expand_expr_real_1) <case ARRAY_REF>: Punt for RAW_DATA_CST.
* tree-streamer.cc (streamer_check_handled_ts_structures): Mark
TS_RAW_DATA_CST as handled.
* tree-streamer-in.cc (streamer_alloc_tree): Handle RAW_DATA_CST.
(lto_input_ts_raw_data_cst_tree_pointers): New function.
(streamer_read_tree_body): Call it for RAW_DATA_CST.
* tree-streamer-out.cc (write_ts_raw_data_cst_tree_pointers): New
function.
(streamer_write_tree_body): Call it for RAW_DATA_CST.
(streamer_write_tree_header): Handle RAW_DATA_CST.
* lto-streamer-out.cc (DFS::DFS_write_tree_body): Handle RAW_DATA_CST.
* tree-pretty-print.cc (dump_generic_node): Likewise.
gcc/c-family/
* c-ppoutput.cc (token_streamer::stream): Add special code to spell
CPP_EMBED token.
* c-lex.cc (c_lex_with_flags): Handle CPP_EMBED. Formatting fix.
* c-common.cc (c_parse_error): Handle CPP_EMBED.
(braced_list_to_string): Optimize RAW_DATA_CST surrounded by
INTEGER_CSTs which match some bytes before or after RAW_DATA_CST in
its owner.
gcc/c/
* c-parser.cc (c_parser_braced_init): Handle CPP_EMBED.
(c_parser_get_builtin_args): Likewise.
(c_parser_expression): Likewise.
(c_parser_expr_list): Likewise.
* c-typeck.cc (digest_init): Handle RAW_DATA_CST. Formatting fix.
(init_node_successor): New function.
(add_pending_init): Handle RAW_DATA_CST.
(set_nonincremental_init): Formatting fix.
(output_init_element): Handle RAW_DATA_CST. Formatting fixes.
(maybe_split_raw_data): New function.
(process_init_element): Use maybe_split_raw_data. Handle
RAW_DATA_CST.
gcc/testsuite/
* c-c++-common/cpp/embed-20.c: New test.
* c-c++-common/cpp/embed-21.c: New test.
* c-c++-common/cpp/embed-28.c: New test.
* gcc.dg/cpp/embed-8.c: New test.
* gcc.dg/cpp/embed-9.c: New test.
* gcc.dg/cpp/embed-10.c: New test.
* gcc.dg/cpp/embed-11.c: New test.
* gcc.dg/cpp/embed-12.c: New test.
* gcc.dg/cpp/embed-13.c: New test.
* gcc.dg/cpp/embed-14.c: New test.
* gcc.dg/cpp/embed-15.c: New test.
* gcc.dg/cpp/embed-16.c: New test.
* gcc.dg/pch/embed-1.c: New test.
* gcc.dg/pch/embed-1.hs: New test.
* gcc.dg/lto/embed-1_0.c: New test.
* gcc.dg/lto/embed-1_1.c: New test.
|
||
|
Jakub Jelinek
|
ac615e1047 |
libcpp: Add -Wtrailing-blanks warning
Trailing blanks is something even git diff diagnoses; while it is a coding
style issue, if it is so common that git diff diagnoses it, I think it could
be useful to various projects to check that at compile time.
Dunno if it should be included in -Wextra, currently it isn't, and due to
tons of trailing whitespace in our sources, haven't enabled it for when
building gcc itself either.
Note, git diff also diagnoses indentation with tab following space, wonder
if we couldn't have trivial warning options where one would simply ask for
checking of indentation with no tabs, just spaces vs. indentation with
tabs followed by spaces (but never tab width or more spaces in the
indentation). I think that would be easy to do also on the libcpp side.
Checking how much something should be exactly indented requires syntax
analysis (at least some limited one) and can consider columns of first token
on line, but what the exact indentation blanks were is something only libcpp
knows.
On Thu, Sep 19, 2024 at 08:17:24AM +0200, Richard Biener wrote:
> Generally I like diagnosing this early. For the above I'd say -Wtrailing-whitespace=
> with a set of things to diagnose (and a sane default - just spaces and tabs - for
> -Wtrailiing-whitespace) would be nice. As for naming possibly follow the
> is{space,blank,cntrl} character classifications? If those are a good
> fit, that is.
The patch currently allows blank (' ' '\t') and space (' ' '\t' '\f' '\v'),
cntrl not yet added, not anything non-ASCII, but in theory could
be added later (though, non-ASCII would be just for inside of comments,
say non-breaking space etc. in the source is otherwise an error).
2024-10-15 Jakub Jelinek <jakub@redhat.com>
libcpp/
* include/cpplib.h (struct cpp_options): Add
cpp_warn_trailing_whitespace member.
(enum cpp_warning_reason): Add CPP_W_TRAILING_WHITESPACE.
* internal.h (struct _cpp_line_note): Document 'W' line note.
* lex.cc (_cpp_clean_line): Add 'W' line note for trailing whitespace
except for trailing whitespace after backslash. Formatting fix.
(_cpp_process_line_notes): Emit -Wtrailing-whitespace diagnostics.
Formatting fixes.
(lex_raw_string): Clear type on 'W' notes.
gcc/
* doc/invoke.texi (Wtrailing-whitespace): Document.
gcc/c-family/
* c.opt (Wtrailing-whitespace=): New option.
(Wtrailing-whitespace): New alias.
* c.opt.urls: Regenerate.
gcc/testsuite/
* c-c++-common/cpp/Wtrailing-whitespace-1.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-2.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-3.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-4.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-5.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-6.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-7.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-8.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-9.c: New test.
* c-c++-common/cpp/Wtrailing-whitespace-10.c: New test.
|
||
|
Jason Merrill
|
2c08ddd3fd |
libcpp: avoid extra spaces in module preprocessing
Within the compiler, module keywords "import", "module", and "export" that are recognized as part of module directives gain an extra trailing space to distinguish them from other non-keyword uses of those words in the code. But when dumping preprocessed output, printing those spaces creates a gratuitous inconsistency with non-modules preprocessing, as revealed by several of the g++.dg/modules/cpp* tests if modules are enabled by default in C++20 mode. libcpp/ChangeLog: * lex.cc (cpp_output_token): Omit terminal space from name. gcc/testsuite/ChangeLog: * g++.dg/modules/cpp-2_c.C: Expect only one space after import. * g++.dg/modules/cpp-5_c.C * g++.dg/modules/dep-2.C * g++.dg/modules/dir-only-2_b.C * g++.dg/modules/pr99050_b.C * g++.dg/modules/inc-xlate-1_b.H * g++.dg/modules/legacy-3_b.H * g++.dg/modules/legacy-3_c.H: Likewise. |
||
|
Lewis Hyatt
|
8c56d697b3
|
libcpp: Fix _Pragma("GCC system_header") [PR114436]
_Pragma("GCC system_header") currently takes effect only partially. It does
succeed in updating the line_map, so that checks like in_system_header_at()
return correctly, but it does not update pfile->buffer->sysp. One result is
that a subsequent #include does not set up the system header state properly
for the newly included file, as pointed out in the PR. Fix by propagating
the new system header state back to the buffer after processing the pragma.
libcpp/ChangeLog:
PR preprocessor/114436
* directives.cc (destringize_and_run): If the _Pragma changed the
buffer system header state (e.g. because it was "GCC
system_header"), propagate that change back to the actual buffer
too.
gcc/testsuite/ChangeLog:
PR preprocessor/114436
* c-c++-common/cpp/pragma-system-header-1.h: New test.
* c-c++-common/cpp/pragma-system-header-2.h: New test.
* c-c++-common/cpp/pragma-system-header.c: New test.
|
||
|
Lewis Hyatt
|
998eb2a126
|
libcpp: Support extended characters for #pragma {push,pop}_macro [PR109704]
The implementation of #pragma push_macro and #pragma pop_macro has to date
made use of an ad-hoc function, _cpp_lex_identifier(), which lexes an
identifier out of a string. When support was added for extended characters
in identifiers ($, UCNs, or UTF-8), that support was added only for the
"normal" way of lexing identifiers out of a cpp_buffer (_cpp_lex_direct) and
not for the ad-hoc way. Consequently, extended identifiers are not usable
with these pragmas.
The logic for lexing identifiers has become more complicated than it was
when _cpp_lex_identifier() was written -- it now handles things like \N{}
escapes in C++, for instance -- and it no longer seems practical to maintain
a redundant code path for lexing identifiers. Address the issue by changing
the implementation of #pragma {push,pop}_macro to lex identifiers in the
expected way, i.e. by pushing a cpp_buffer and lexing the identifier from
there.
The existing implementation has some quirks because of the ad-hoc parsing
logic. For example:
#pragma push_macro("X ")
...
#pragma pop_macro("X")
will not restore macro X (note the extra space in the first string). However:
#pragma push_macro("X ")
...
#pragma pop_macro("X ")
actually does sucessfully restore "X". This is because the key for looking
up the saved macro on the push stack is the original string passed, so the
string passed to pop_macro needs to match it exactly. It is not that easy to
reproduce this logic in the world of extended characters, given that for
example it should be valid to pass a UCN to push_macro, and the
corresponding UTF-8 to pop_macro. Given that this aspect of the existing
behavior seems unintentional and has no tests (and does not match other
implementations), I opted to make the new logic more straightforward. The
string passed needs to lex to one token, which must be a valid identifier,
or else no action is taken and no error is generated. Any diagnostics
encountered during lexing (e.g., due to a UTF-8 character not permitted to
appear in an identifier) are also suppressed.
It could be nice (for GCC 15) to also add a warning if a pop_macro does not
match a previous push_macro.
libcpp/ChangeLog:
PR preprocessor/109704
* include/cpplib.h (class cpp_auto_suppress_diagnostics): New class.
* errors.cc
(cpp_auto_suppress_diagnostics::cpp_auto_suppress_diagnostics): New
function.
(cpp_auto_suppress_diagnostics::~cpp_auto_suppress_diagnostics): New
function.
* charset.cc (noop_diagnostic_cb): Remove.
(cpp_interpret_string_ranges): Refactor diagnostic suppression logic
into new class cpp_auto_suppress_diagnostics.
(count_source_chars): Likewise.
* directives.cc (cpp_pop_definition): Add cpp_hashnode argument.
(lex_identifier_from_string): New static helper function.
(push_pop_macro_common): Refactor common logic from
do_pragma_push_macro and do_pragma_pop_macro; use
lex_identifier_from_string instead of _cpp_lex_identifier.
(do_pragma_push_macro): Reimplement using push_pop_macro_common.
(do_pragma_pop_macro): Likewise.
* internal.h (_cpp_lex_identifier): Remove.
* lex.cc (lex_identifier_intern): Remove.
(_cpp_lex_identifier): Remove.
gcc/testsuite/ChangeLog:
PR preprocessor/109704
* c-c++-common/cpp/pragma-push-pop-utf8.c: New test.
* g++.dg/pch/pushpop-2.C: New test.
* g++.dg/pch/pushpop-2.Hs: New test.
* gcc.dg/pch/pushpop-2.c: New test.
* gcc.dg/pch/pushpop-2.hs: New test.
|
||
|
GCC Administrator
|
f08af081a6 | Daily bump. | ||
|
Jakub Jelinek
|
c397a8c122 |
libcpp, genmatch: Use gcc_diag instead of printf for libcpp diagnostics
When working on #embed support, or -Wheader-guard or other recent libcpp
changes, I've been annoyed by the libcpp diagnostics being visually
different from normal gcc diagnostics, especially in the area of quoting
stuff in the diagnostic messages.
Normall GCC diagnostics is gcc_diag/gcc_tdiag, one can use
%</%>, %qs etc. in there, while libcpp diagnostics was marked as printf
and in libcpp we've been very creative with quoting stuff, either
no quotes at all, or "something" quoting, or 'something' quoting, or
`something' quoting (but in none of the cases it used colors consistently
with the rest of the compiler).
Now, libcpp diagnostics is always emitted using a callback,
pfile->cb.diagnostic. On the gcc/ side, this callback is initialized with
genmatch.cc: cb->diagnostic = diagnostic_cb;
c-family/c-opts.cc: cb->diagnostic = c_cpp_diagnostic;
fortran/cpp.cc: cb->diagnostic = cb_cpp_diagnostic;
where the latter two just use diagnostic_report_diagnostic, so actually
support all the gcc_diag stuff, only the genmatch.cc case didn't.
So, the following patch changes genmatch.cc to use pp_format* instead
of vfprintf so that it supports the gcc_diag formatting (pretty-print.o
unfortunately has various dependencies, so had to link genmatch with
libcommon.a libbacktrace.a and tweak Makefile.in so that there are no
circular dependencies) and marks the libcpp diagnostic routines as
gcc_diag rather than printf. That change resulted in hundreds of
-Wformat-diag new warnings (most of them useful and resulting IMHO in
better diagnostics), so the rest of the patch is changing the format
strings to make -Wformat-diag happy and adjusting the testsuite for
the differences in how is the diagnostic reformatted.
Dunno if some out of GCC tree projects use libcpp, that case would
make it harder because one couldn't use vfprintf in the diagnostic
callback anymore, but there is always David's libdiagnostic which could
be used for that purpose IMHO.
2024-10-12 Jakub Jelinek <jakub@redhat.com>
libcpp/
* include/cpplib.h (ATTRIBUTE_CPP_PPDIAG): Define.
(struct cpp_callbacks): Use ATTRIBUTE_CPP_PPDIAG instead of
ATTRIBUTE_FPTR_PRINTF on diagnostic callback.
(cpp_error, cpp_warning, cpp_pedwarning, cpp_warning_syshdr): Use
ATTRIBUTE_CPP_PPDIAG (3, 4) instead of ATTRIBUTE_PRINTF_3.
(cpp_warning_at, cpp_pedwarning_at): Use ATTRIBUTE_CPP_PPDIAG (4, 5)
instead of ATTRIBUTE_PRINTF_4.
(cpp_error_with_line, cpp_warning_with_line, cpp_pedwarning_with_line,
cpp_warning_with_line_syshdr): Use ATTRIBUTE_CPP_PPDIAG (5, 6)
instead of ATTRIBUTE_PRINTF_5.
(cpp_error_at): Use ATTRIBUTE_CPP_PPDIAG (4, 5) instead of
ATTRIBUTE_PRINTF_4.
* Makefile.in (po/$(PACKAGE).pot): Use --language=GCC-source rather
than --language=c.
* errors.cc (cpp_diagnostic_at, cpp_diagnostic,
cpp_diagnostic_with_line): Use ATTRIBUTE_CPP_PPDIAG instead of
-ATTRIBUTE_FPTR_PRINTF.
* charset.cc (cpp_host_to_exec_charset, _cpp_valid_ucn, convert_hex,
convert_oct, convert_escape): Fix up -Wformat-diag warnings.
(cpp_interpret_string_ranges, count_source_chars): Use
ATTRIBUTE_CPP_PPDIAG instead of ATTRIBUTE_FPTR_PRINTF.
(narrow_str_to_charconst): Fix up -Wformat-diag warnings.
* directives.cc (check_eol_1, directive_diagnostics, lex_macro_node,
do_undef, glue_header_name, parse_include, do_include_common,
do_include_next, _cpp_parse_embed_params, do_embed, read_flag,
do_line, do_linemarker, register_pragma_1, do_pragma_once,
do_pragma_push_macro, do_pragma_pop_macro, do_pragma_poison,
do_pragma_system_header, do_pragma_warning_or_error, _cpp_do__Pragma,
do_else, do_elif, do_endif, parse_answer, do_assert,
cpp_define_unused): Likewise.
* expr.cc (cpp_classify_number, parse_defined, eval_token,
_cpp_parse_expr, reduce, check_promotion): Likewise.
* files.cc (_cpp_find_file, finish_base64_embed,
_cpp_pop_file_buffer): Likewise.
* init.cc (sanity_checks): Likewise.
* lex.cc (_cpp_process_line_notes, maybe_warn_bidi_on_char,
_cpp_warn_invalid_utf8, _cpp_skip_block_comment,
warn_about_normalization, forms_identifier_p, maybe_va_opt_error,
identifier_diagnostics_on_lex, cpp_maybe_module_directive): Likewise.
* macro.cc (class vaopt_state, builtin_has_include_1,
builtin_has_include, builtin_has_embed, _cpp_warn_if_unused_macro,
_cpp_builtin_macro_text, builtin_macro, stringify_arg,
_cpp_arguments_ok, collect_args, enter_macro_context,
_cpp_save_parameter, parse_params, create_iso_definition,
_cpp_create_definition, check_trad_stringification): Likewise.
* pch.cc (cpp_valid_state): Likewise.
* traditional.cc (_cpp_scan_out_logical_line, recursive_macro):
Likewise.
gcc/
* Makefile.in (generated_files): Remove {gimple,generic}-match*.
(generated_match_files): New variable. Add a dependency of
$(filter-out $(OBJS-libcommon),$(ALL_HOST_OBJS)) files on those.
(build/genmatch$(build_exeext)): Depend on and link against
libcommon.a and $(LIBBACKTRACE).
* genmatch.cc: Include pretty-print.h and input.h.
(ggc_internal_cleared_alloc, ggc_free): Remove.
(fatal): New function.
(line_table): Remove.
(linemap_client_expand_location_to_spelling_point): Remove.
(diagnostic_cb): Use gcc_diag rather than printf format. Use
pp_format_verbatim on a temporary pretty_printer instead of
vfprintf.
(fatal_at, warning_at): Use gcc_diag rather than printf format.
(output_line_directive): Rename location_hash to loc_hash.
(parser::eat_ident, parser::parse_operation, parser::parse_expr,
parser::parse_pattern, parser::finish_match_operand): Fix up
-Wformat-diag warnings.
gcc/c-family/
* c-lex.cc (c_common_has_attribute,
c_common_lex_availability_macro): Fix up -Wformat-diag warnings.
gcc/testsuite/
* c-c++-common/cpp/counter-2.c: Adjust expected diagnostics for
libcpp diagnostic formatting changes.
* c-c++-common/cpp/embed-3.c: Likewise.
* c-c++-common/cpp/embed-4.c: Likewise.
* c-c++-common/cpp/embed-16.c: Likewise.
* c-c++-common/cpp/embed-18.c: Likewise.
* c-c++-common/cpp/eof-2.c: Likewise.
* c-c++-common/cpp/eof-3.c: Likewise.
* c-c++-common/cpp/fmax-include-depth.c: Likewise.
* c-c++-common/cpp/has-builtin.c: Likewise.
* c-c++-common/cpp/line-2.c: Likewise.
* c-c++-common/cpp/line-3.c: Likewise.
* c-c++-common/cpp/macro-arg-count-1.c: Likewise.
* c-c++-common/cpp/macro-arg-count-2.c: Likewise.
* c-c++-common/cpp/macro-ranges.c: Likewise.
* c-c++-common/cpp/named-universal-char-escape-4.c: Likewise.
* c-c++-common/cpp/named-universal-char-escape-5.c: Likewise.
* c-c++-common/cpp/pr88974.c: Likewise.
* c-c++-common/cpp/va-opt-error.c: Likewise.
* c-c++-common/cpp/va-opt-pedantic.c: Likewise.
* c-c++-common/cpp/Wheader-guard-2.c: Likewise.
* c-c++-common/cpp/Wheader-guard-3.c: Likewise.
* c-c++-common/cpp/Winvalid-utf8-1.c: Likewise.
* c-c++-common/cpp/Winvalid-utf8-2.c: Likewise.
* c-c++-common/cpp/Winvalid-utf8-3.c: Likewise.
* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-1.c:
Likewise.
* c-c++-common/diagnostic-format-sarif-file-bad-utf8-pr109098-3.c:
Likewise.
* c-c++-common/pr68833-3.c: Likewise.
* c-c++-common/raw-string-directive-1.c: Likewise.
* gcc.dg/analyzer/named-constants-Wunused-macros.c: Likewise.
* gcc.dg/binary-constants-4.c: Likewise.
* gcc.dg/builtin-redefine.c: Likewise.
* gcc.dg/cpp/19951025-1.c: Likewise.
* gcc.dg/cpp/c11-warning-1.c: Likewise.
* gcc.dg/cpp/c11-warning-2.c: Likewise.
* gcc.dg/cpp/c11-warning-3.c: Likewise.
* gcc.dg/cpp/c23-elifdef-2.c: Likewise.
* gcc.dg/cpp/c23-warning-2.c: Likewise.
* gcc.dg/cpp/embed-2.c: Likewise.
* gcc.dg/cpp/embed-3.c: Likewise.
* gcc.dg/cpp/embed-4.c: Likewise.
* gcc.dg/cpp/expr.c: Likewise.
* gcc.dg/cpp/gnu11-elifdef-2.c: Likewise.
* gcc.dg/cpp/gnu11-elifdef-3.c: Likewise.
* gcc.dg/cpp/gnu11-elifdef-4.c: Likewise.
* gcc.dg/cpp/gnu11-warning-1.c: Likewise.
* gcc.dg/cpp/gnu11-warning-2.c: Likewise.
* gcc.dg/cpp/gnu11-warning-3.c: Likewise.
* gcc.dg/cpp/gnu23-warning-2.c: Likewise.
* gcc.dg/cpp/include6.c: Likewise.
* gcc.dg/cpp/pr35322.c: Likewise.
* gcc.dg/cpp/tr-warn6.c: Likewise.
* gcc.dg/cpp/undef2.c: Likewise.
* gcc.dg/cpp/warn-comments.c: Likewise.
* gcc.dg/cpp/warn-comments-2.c: Likewise.
* gcc.dg/cpp/warn-comments-3.c: Likewise.
* gcc.dg/cpp/warn-cxx-compat.c: Likewise.
* gcc.dg/cpp/warn-cxx-compat-2.c: Likewise.
* gcc.dg/cpp/warn-deprecated.c: Likewise.
* gcc.dg/cpp/warn-deprecated-2.c: Likewise.
* gcc.dg/cpp/warn-long-long.c: Likewise.
* gcc.dg/cpp/warn-long-long-2.c: Likewise.
* gcc.dg/cpp/warn-normalized-1.c: Likewise.
* gcc.dg/cpp/warn-normalized-2.c: Likewise.
* gcc.dg/cpp/warn-normalized-3.c: Likewise.
* gcc.dg/cpp/warn-normalized-4-bytes.c: Likewise.
* gcc.dg/cpp/warn-normalized-4-unicode.c: Likewise.
* gcc.dg/cpp/warn-redefined.c: Likewise.
* gcc.dg/cpp/warn-redefined-2.c: Likewise.
* gcc.dg/cpp/warn-traditional.c: Likewise.
* gcc.dg/cpp/warn-traditional-2.c: Likewise.
* gcc.dg/cpp/warn-trigraphs-1.c: Likewise.
* gcc.dg/cpp/warn-trigraphs-2.c: Likewise.
* gcc.dg/cpp/warn-trigraphs-3.c: Likewise.
* gcc.dg/cpp/warn-trigraphs-4.c: Likewise.
* gcc.dg/cpp/warn-undef.c: Likewise.
* gcc.dg/cpp/warn-undef-2.c: Likewise.
* gcc.dg/cpp/warn-unused-macros.c: Likewise.
* gcc.dg/cpp/warn-unused-macros-2.c: Likewise.
* gcc.dg/pch/counter-2.c: Likewise.
* g++.dg/cpp0x/udlit-error1.C: Likewise.
* g++.dg/cpp23/named-universal-char-escape1.C: Likewise.
* g++.dg/cpp23/named-universal-char-escape2.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-1.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-2.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-3.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-4.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-5.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-6.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-7.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-8.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-9.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-10.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-11.C: Likewise.
* g++.dg/cpp23/Winvalid-utf8-12.C: Likewise.
* g++.dg/cpp/elifdef-3.C: Likewise.
* g++.dg/cpp/elifdef-5.C: Likewise.
* g++.dg/cpp/elifdef-6.C: Likewise.
* g++.dg/cpp/elifdef-7.C: Likewise.
* g++.dg/cpp/embed-1.C: Likewise.
* g++.dg/cpp/embed-2.C: Likewise.
* g++.dg/cpp/pedantic-errors.C: Likewise.
* g++.dg/cpp/warning-1.C: Likewise.
* g++.dg/cpp/warning-2.C: Likewise.
* g++.dg/ext/bitint1.C: Likewise.
* g++.dg/ext/bitint2.C: Likewise.
|
||
|
GCC Administrator
|
e9a213810a | Daily bump. | ||
|
Jason Merrill
|
d264b75eb2 |
libcpp: fix typo
libcpp/ChangeLog: * macro.cc (_cpp_pop_context): Fix typo. |
||
Ken Matsui
|
f709990333
|
libcpp: Use ' instead of %< and %> [PR117039]
PR bootstrap/117039 libcpp/ChangeLog: * directives.cc (do_pragma_once): Use ' instead of %< and %>. Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org> |
||
|
Ken Matsui
|
821d56100e
|
gcc, libcpp: Add warning switch for "#pragma once in main file" [PR89808]
This patch adds a warning switch for "#pragma once in main file". The warning option name is Wpragma-once-outside-header, which is the same as Clang provides. PR preprocessor/89808 gcc/c-family/ChangeLog: * c.opt (Wpragma_once_outside_header): Define new option. * c.opt.urls: Regenerate. gcc/ChangeLog: * doc/invoke.texi (Warning Options): Document -Wno-pragma-once-outside-header. libcpp/ChangeLog: * include/cpplib.h (cpp_warning_reason): Define CPP_W_PRAGMA_ONCE_OUTSIDE_HEADER. * directives.cc (do_pragma_once): Use CPP_W_PRAGMA_ONCE_OUTSIDE_HEADER. gcc/testsuite/ChangeLog: * g++.dg/warn/Wno-pragma-once-outside-header.C: New test. * g++.dg/warn/Wpragma-once-outside-header.C: New test. Signed-off-by: Ken Matsui <kmatsui@gcc.gnu.org> Reviewed-by: Marek Polacek <polacek@redhat.com> |
||
|
GCC Administrator
|
41179a3276 | Daily bump. | ||
|
Jakub Jelinek
|
d0e8f58b81 |
contrib, libcpp, libstdc++: Update to Unicode 16.0
It is autumn again and there is a new Unicode version 16.0. The following patch updates our Unicode stuff in contrib, libcpp and libstdc++ from that Unicode version. 2024-10-08 Jakub Jelinek <jakub@redhat.com> contrib/ * unicode/README: Update glibc git commit hash, replace Unicode 15 or 15.1 versions with 16. * unicode/gen_libstdcxx_unicode_data.py: Use 160000 instead of 150100 in _GLIBCXX_GET_UNICODE_DATA test. * unicode/from_glibc/utf8_gen.py: Updated from glibc 064c708c78cc2a6b5802dce73108fc0c1c6bfc80 commit. * unicode/DerivedCoreProperties.txt: Updated from Unicode 16.0. * unicode/emoji-data.txt: Likewise. * unicode/PropList.txt: Likewise. * unicode/GraphemeBreakProperty.txt: Likewise. * unicode/DerivedNormalizationProps.txt: Likewise. * unicode/NameAliases.txt: Likewise. * unicode/UnicodeData.txt: Likewise. * unicode/EastAsianWidth.txt: Likewise. gcc/testsuite/ * c-c++-common/cpp/named-universal-char-escape-1.c: Add tests for some Unicode 16.0 characters, both normal and generated. libcpp/ * makeucnid.cc (write_copyright): Update Unicode Copyright years. * makeuname2c.cc (generated_ranges): Adjust Unicode version from 15.1 to 16.0. Add EGYPTIAN HIEROGLYPH- generated range, adjust indexes in following entries. (write_copyright): Update Unicode Copyright years. * generated_cpp_wcwidth.h: Regenerated. * ucnid.h: Regenerated. * uname2c.h: Regenerated. libstdc++-v3/ * include/bits/unicode.h (std::__unicode::__v15_1_0): Rename inline namespace to ... (std::__unicode::__v16_0_0): ... this. (_GLIBCXX_GET_UNICODE_DATA): Change from 150100 to 160000. * include/bits/unicode-data.h: Regenerated. * testsuite/ext/unicode/properties.cc: Check for _Gcb_SpacingMark on U+11F03 rather than U+1D16D as the latter lost SpacingMark property in Unicode 16.0. |
||
|
GCC Administrator
|
14870c1f86 | Daily bump. | ||
|
Jakub Jelinek
|
e4c0595ec4 |
libcpp: Use constexpr for _cpp_trigraph_map initialization for C++14
The _cpp_trigraph_map initialization used to be done for C99+ using designated initializers, but can't be done that way for C++ because the designated initializer support in C++ as array designators are just an extension there and don't allow skipping anything nor going backwards. But, we can get the same effect using C++14 constexpr constructor. With the following patch we get rid of the runtime initialization and the array can be in .rodata. 2024-10-07 Jakub Jelinek <jakub@redhat.com> * internal.h (_cpp_trigraph_map_s): New type for C++14 or later. (_cpp_trigraph_map_d): New variable for C++14 or later. (_cpp_trigraph_map): Define to _cpp_trigraph_map_d.map for C++14 or later. * init.cc (init_trigraph_map): Define to nothing for C++14 or later. (TRIGRAPH_MAP, END, s): Define differently for C++14 or later. |
||
|
GCC Administrator
|
1d09117830 | Daily bump. | ||
|
Jakub Jelinek
|
5943a2fa1b |
libcpp: Implement clang -Wheader-guard warning [PR96842]
The following patch implements the clang -Wheader-guard warning, which warns if a valid multiple inclusion header guard's #ifndef/#if !defined directive is immediately (no other non-line directives nor other (non-comment) tokens in between) followed by #define directive for some different macro, which in get_suggestion rules is close enough to the actual header guard macro (i.e. likely misspelling), the #define is object-like with empty definition (I've followed what clang implements) and the macro isn't defined later on (at least not on the final #endif at the end of a header). In this case it emits a warning, so that #ifndef STDIO_H #define STDOI_H ... #endif or similar misspellings can be caught. clang enables this warning by default, but I've put it into -Wall instead as it still seems to be a style warning, nothing more severe; if a header doesn't survive multiple inclusion because of the misspelling, users will get different diagnostics. 2024-10-02 Jakub Jelinek <jakub@redhat.com> PR preprocessor/96842 libcpp/ * include/cpplib.h (struct cpp_options): Add warn_header_guard member. (enum cpp_warning_reason): Add CPP_W_HEADER_GUARD enumerator. * internal.h (struct cpp_reader): Add mi_def_cmacro, mi_loc and mi_def_loc members. (_cpp_defined_macro_p): Constify type pointed by argument type. Formatting fix. * init.cc (cpp_create_reader): Clear CPP_OPTION (pfile, warn_header_guard). * directives.cc (struct if_stack): Add def_loc and mi_def_cmacro members. (DIRECTIVE_TABLE): Add IF_COND flag to define. (do_define): Set ifs->mi_def_cmacro on a define immediately following #ifndef directive for the guard. Clear pfile->mi_valid. Formatting fix. (do_endif): Copy over pfile->mi_def_cmacro and pfile->mi_def_loc if ifs->mi_def_cmacro is set and pfile->mi_cmacro isn't a defined macro. (push_conditional): Clear mi_def_cmacro and mi_def_loc members. * files.cc (_cpp_pop_file_buffer): Emit -Wheader-guard diagnostics. gcc/ * doc/invoke.texi (Wheader-guard): Document. gcc/c-family/ * c.opt (Wheader-guard): New option. * c.opt.urls: Regenerated. * c-ppoutput.cc (init_pp_output): Initialize also cb->get_suggestion. gcc/testsuite/ * c-c++-common/cpp/Wheader-guard-1.c: New test. * c-c++-common/cpp/Wheader-guard-1-1.h: New test. * c-c++-common/cpp/Wheader-guard-1-2.h: New test. * c-c++-common/cpp/Wheader-guard-1-3.h: New test. * c-c++-common/cpp/Wheader-guard-1-4.h: New test. * c-c++-common/cpp/Wheader-guard-1-5.h: New test. * c-c++-common/cpp/Wheader-guard-1-6.h: New test. * c-c++-common/cpp/Wheader-guard-1-7.h: New test. * c-c++-common/cpp/Wheader-guard-1-8.h: New test. * c-c++-common/cpp/Wheader-guard-1-9.h: New test. * c-c++-common/cpp/Wheader-guard-1-10.h: New test. * c-c++-common/cpp/Wheader-guard-1-11.h: New test. * c-c++-common/cpp/Wheader-guard-1-12.h: New test. * c-c++-common/cpp/Wheader-guard-2.c: New test. * c-c++-common/cpp/Wheader-guard-2.h: New test. * c-c++-common/cpp/Wheader-guard-3.c: New test. * c-c++-common/cpp/Wheader-guard-3.h: New test. |
||
|
GCC Administrator
|
442db842f3 | Daily bump. | ||
Joseph Myers
|
3790ff7530 |
Update cpplib zh_CN.po
* zh_CN.po: Update. |
||
|
GCC Administrator
|
d53c5bca73 | Daily bump. | ||
|
Jakub Jelinek
|
4963eb7691 |
libcpp: Fix up UB in finish_embed
Jonathan reported on IRC that certain unnamed proprietary static analyzer
is unhappy about the new finish_embed function and it is actually right.
On a testcase like:
#embed __FILE__ limit (0) if_empty (0)
params->if_empty.count is 1, limit is 0, so count is 0 (we need just
a single token and one fits into pfile->directive_result). Because
count is 0, we don't allocate toks, so it stays NULL, and then in
1301 if (prefix->count)
1302 {
1303 *tok = *prefix->base_run.base;
1304 tok = toks;
1305 tokenrun *cur_run = &prefix->base_run;
1306 while (cur_run)
1307 {
1308 size_t cnt = (cur_run->next ? cur_run->limit
1309 : prefix->cur_token) - cur_run->base;
1310 cpp_token *t = cur_run->base;
1311 if (cur_run == &prefix->base_run)
1312 {
1313 t++;
1314 cnt--;
1315 }
1316 memcpy (tok, t, cnt * sizeof (cpp_token));
1317 tok += cnt;
1318 cur_run = cur_run->next;
1319 }
1320 }
the *tok = *prefix->base_run.base; assignment will copy the only
token. cur_run is still non-NULL, cnt will be initially 1 and
then decremented to 0, but we invoke UB because we do
memcpy (NULL, cur_run->base + 1, 0 * sizeof (cpp_token));
and then the loop stops because cur_run->next must be NULL.
As we don't really copy anything, toks can be anything non-NULL,
so the following patch fixes that by initializing toks also to
&pfile->directive_result (just something known to be non-NULL).
This should be harmless even for the
#embed __FILE__ limit (1)
case (no non-empty prefix/suffix) where toks isn't allocated
either, but in that case prefix->count will be 0 and in the
1321 for (size_t i = 0; i < limit; ++i)
1322 {
1323 tok->src_loc = params->loc;
1324 tok->type = CPP_NUMBER;
1325 tok->flags = NO_EXPAND;
1326 if (i == 0)
1327 tok->flags |= PREV_WHITE;
1328 tok->val.str.text = s;
1329 tok->val.str.len = sprintf ((char *) s, "%d", buffer[i]);
1330 s += tok->val.str.len + 1;
1331 if (tok == &pfile->directive_result)
1332 tok = toks;
1333 else
1334 tok++;
1335 if (i < limit - 1)
1336 {
1337 tok->src_loc = params->loc;
1338 tok->type = CPP_COMMA;
1339 tok->flags = NO_EXPAND;
1340 tok++;
1341 }
1342 }
loop limit will be 1, so tok is initially &pfile->directive_result,
that is stilled in, then tok = toks; (previously setting tok to NULL,
now to &pfile->directive_result again) and because 0 < 1 - 1 is
false, nothing further will happen and the loop will finish (and as
params->suffix.count will be 0, nothing further will use tok).
2024-09-13 Jakub Jelinek <jakub@redhat.com>
* files.cc (finish_embed): Initialize toks to tok rather
than NULL.
|
||
|
GCC Administrator
|
3d021a024b | Daily bump. | ||
|
Jakub Jelinek
|
ce0aecc7df |
libcpp, v2: Add support for gnu::base64 #embed parameter
This patch which adds another #embed extension, gnu::base64. As mentioned in the documentation, this extension is primarily intended for use by the preprocessor, so that for the larger (say 32+ or 64+ bytes long embeds it doesn't have to emit tens of thousands or millions of comma separated string literals which would be very expensive to parse again, but can emit #embed "." __gnu__::__base64__( \ "Tm9uIGVyYW0gbsOpc2NpdXMsIEJydXRlLCBjdW0sIHF1w6Ygc3VtbWlzIGluZ8OpbmlpcyBleHF1" \ "aXNpdMOhcXVlIGRvY3Ryw61uYSBwaGlsw7Nzb3BoaSBHcsOmY28gc2VybcOzbmUgdHJhY3RhdsOt" \ "c3NlbnQsIGVhIExhdMOtbmlzIGzDrXR0ZXJpcyBtYW5kYXLDqW11cywgZm9yZSB1dCBoaWMgbm9z" \ "dGVyIGxhYm9yIGluIHbDoXJpYXMgcmVwcmVoZW5zacOzbmVzIGluY8O6cnJlcmV0LiBuYW0gcXVp" \ "YsO6c2RhbSwgZXQgaWlzIHF1aWRlbSBub24gw6FkbW9kdW0gaW5kw7NjdGlzLCB0b3R1bSBob2Mg" \ "ZMOtc3BsaWNldCBwaGlsb3NvcGjDoXJpLiBxdWlkYW0gYXV0ZW0gbm9uIHRhbSBpZCByZXByZWjD" \ "qW5kdW50LCBzaSByZW3DrXNzaXVzIGFnw6F0dXIsIHNlZCB0YW50dW0gc3TDumRpdW0gdGFtcXVl" \ "IG11bHRhbSDDs3BlcmFtIHBvbsOpbmRhbSBpbiBlbyBub24gYXJiaXRyw6FudHVyLiBlcnVudCDD" \ "qXRpYW0sIGV0IGlpIHF1aWRlbSBlcnVkw610aSBHcsOmY2lzIGzDrXR0ZXJpcywgY29udGVtbsOp" \ "bnRlcyBMYXTDrW5hcywgcXVpIHNlIGRpY2FudCBpbiBHcsOmY2lzIGxlZ8OpbmRpcyDDs3BlcmFt" \ "IG1hbGxlIGNvbnPDum1lcmUuIHBvc3Ryw6ltbyDDoWxpcXVvcyBmdXTDunJvcyBzw7pzcGljb3Is" \ "IHF1aSBtZSBhZCDDoWxpYXMgbMOtdHRlcmFzIHZvY2VudCwgZ2VudXMgaG9jIHNjcmliw6luZGks" \ "IGV0c2kgc2l0IGVsw6lnYW5zLCBwZXJzw7Nuw6YgdGFtZW4gZXQgZGlnbml0w6F0aXMgZXNzZSBu" \ "ZWdlbnQu") with the meaning don't actually load some file, instead base64 decode (RFC4648 with A-Za-z0-9+/ chars and = padding, no newlines in between) the string and use that as data. This is chosen because it should be -pedantic-errors clean, fairly cheap to decode and then in optimizing compiler could be handled as similar binary blob to normal #embed, while the data isn't left somewhere on the disk, so distcc/ccache etc. can move the preprocessed source without issues. It makes no sense to support limit and gnu::offset parameters together with it IMHO, why would somebody waste providing full data and then threw some away? prefix/suffix/if_empty are normally supported though, but not intended to be used by the preprocessor. This patch adds just the extension side, not the actual emitting of this during -E or -E -fdirectives-only for now, that will be included in the upcoming patch. Compared to the earlier posted version of this extension, this patch allows the string concatenation in the parameter argument (but still doesn't allow escapes in the string, why would anyone use them when only A-Za-z0-9+/= are valid). The patch also adds support for parsing this even in -fpreprocessed compilation. 2024-09-12 Jakub Jelinek <jakub@redhat.com> libcpp/ * internal.h (struct cpp_embed_params): Add base64 member. (_cpp_free_embed_params_tokens): Declare. * directives.cc (DIRECTIVE_TABLE): Add IN_I flag to T_EMBED. (save_token_for_embed, _cpp_free_embed_params_tokens): New functions. (EMBED_PARAMS): Add gnu::base64 entry. (_cpp_parse_embed_params): Parse gnu::base64 parameter. If -fpreprocessed without -fdirectives-only, require #embed to have gnu::base64 parameter. Diagnose conflict between gnu::base64 and limit or gnu::offset parameters. (do_embed): Use _cpp_free_embed_params_tokens. * files.cc (finish_embed, base64_dec_fn): New functions. (base64_dec): New array. (B64D0, B64D1, B64D2, B64D3): Define. (finish_base64_embed): New function. (_cpp_stack_embed): Use finish_embed. Handle params->base64 using finish_base64_embed. * macro.cc (builtin_has_embed): Call _cpp_free_embed_params_tokens. gcc/ * doc/cpp.texi (Binary Resource Inclusion): Document gnu::base64 parameter. gcc/testsuite/ * c-c++-common/cpp/embed-17.c: New test. * c-c++-common/cpp/embed-18.c: New test. * c-c++-common/cpp/embed-19.c: New test. * c-c++-common/cpp/embed-27.c: New test. * gcc.dg/cpp/embed-6.c: New test. * gcc.dg/cpp/embed-7.c: New test. |
||
|
Jason Merrill
|
c5009eb887 |
libcpp: adjust pedwarn handling
Using cpp_pedwarning (CPP_W_PEDANTIC instead of if (CPP_PEDANTIC cpp_error
lets users suppress these diagnostics with
#pragma GCC diagnostic ignored "-Wpedantic".
This patch changes all instances of the cpp_error (CPP_DL_PEDWARN to
cpp_pedwarning. In cases where the extension appears in a later C++
revision, we now condition the warning on the relevant -Wc++??-extensions
flag instead of -Wpedantic; in such cases often the if (CPP_PEDANTIC) check
is retained to preserve the default non-warning behavior.
I didn't attempt to adjust the warning flags for the C compiler, since it
seems to follow a different system than C++.
The CPP_PEDANTIC check is also kept in _cpp_lex_direct to avoid an ICE in
the self-tests from cb.diagnostics not being initialized.
While working on testcases for these changes I noticed that the c-c++-common
tests are not run with -pedantic-errors by default like the gcc.dg and
g++.dg directories are. And if I specify -pedantic-errors with dg-options,
the default -std= changes from c++?? to gnu++??, which interferes with some
other pedwarns. So two of the tests are C++-only.
libcpp/ChangeLog:
* include/cpplib.h (enum cpp_warning_reason): Add
CPP_W_CXX{14,17,20,23}_EXTENSIONS.
* charset.cc (_cpp_valid_ucn, convert_hex, convert_oct)
(convert_escape, narrow_str_to_charconst): Use cpp_pedwarning
instead of cpp_error for pedwarns.
* directives.cc (directive_diagnostics, _cpp_handle_directive)
(do_line, do_elif): Likewise.
* expr.cc (cpp_classify_number, eval_token): Likewise.
* lex.cc (skip_whitespace, maybe_va_opt_error)
(_cpp_lex_direct): Likewise.
* macro.cc (_cpp_arguments_ok): Likewise.
(replace_args): Use -Wvariadic-macros for pedwarn about
empty macro arguments.
gcc/c-family/ChangeLog:
* c.opt: Add CppReason for Wc++{14,17,20,23}-extensions.
* c-pragma.cc (handle_pragma_diagnostic_impl): Don't check
OPT_Wc__23_extensions.
gcc/testsuite/ChangeLog:
* c-c++-common/pragma-diag-17.c: New test.
* g++.dg/cpp0x/va-opt1.C: New test.
* g++.dg/cpp23/named-universal-char-escape3.C: New test.
|
||
|
Jakub Jelinek
|
44058b8471 |
libcpp: Add support for gnu::offset #embed/__has_embed parameter
The following patch adds on top of the just posted #embed patch a first extension, gnu::offset which allows to seek in the data file (for seekable files, otherwise read and throw away). I think this is useful e.g. when some binary data start with some well known header which shouldn't be included in the data etc. 2024-09-12 Jakub Jelinek <jakub@redhat.com> libcpp/ * internal.h (struct cpp_embed_params): Add offset member. * directives.cc (EMBED_PARAMS): Add gnu::offset entry. (enum embed_param_kind): Add NUM_EMBED_STD_PARAMS. (_cpp_parse_embed_params): Use NUM_EMBED_STD_PARAMS rather than NUM_EMBED_PARAMS when parsing standard parameters. Parse gnu::offset parameter. * files.cc (struct _cpp_file): Add offset member. (_cpp_stack_embed): Handle params->offset. gcc/ * doc/cpp.texi (Binary Resource Inclusion): Document gnu::offset #embed parameter. gcc/testsuite/ * c-c++-common/cpp/embed-15.c: New test. * c-c++-common/cpp/embed-16.c: New test. * gcc.dg/cpp/embed-5.c: New test. |
||
|
Jakub Jelinek
|
eba6d2aa71 |
libcpp, c-family: Add (dumb) C23 N3017 #embed support [PR105863]
The following patch implements the C23 N3017 "#embed - a scannable,
tooling-friendly binary resource inclusion mechanism" paper.
The implementation is intentionally dumb, in that it doesn't significantly
speed up compilation of larger initializers and doesn't make it possible
to use huge #embeds (like several gigabytes large, that is compile time
and memory still infeasible).
There are 2 reasons for this. One is that I think like it is implemented
now in the patch is how we should use it for the smaller #embed sizes,
dunno with which boundary, whether 32 bytes or 64 or something like that,
certainly handling the single byte cases which is something that can appear
anywhere in the source where constant integer literal can appear is
desirable and I think for a few bytes it isn't worth it to come up with
something smarter and users would like to e.g. see it in -E readably as
well (perhaps the slow vs. fast boundary should be determined by command
line option). And the other one is to be able to more easily find
regressions in behavior caused by the optimizations, so we have something
to get back in git to compare against.
I'm definitely willing to work on the optimizations (likely introduce a new
CPP_* token type to refer to a range of libcpp owned memory (start + size)
and similarly some tree which can do the same, and can be at any time e.g.
split into 2 subparts + say INTEGER_CST in between if needed say for
const unsigned char d[] = {
#embed "2GB.dat" prefix (0, 0, ) suffix (, [0x40000000] = 42)
}; still without having to copy around huge amounts of data; STRING_CST
owns the memory it points to and can be only 2GB in size), but would
like to do that incrementally.
And would like to first include some extensions also not included in
this patch, like gnu::offset (off) parameter to allow to skip certain
constant amount of bytes at the start of the files, plus
gnu::base64 ("base64_encoded_data") parameter to add something which can
store more efficiently large amounts of the #embed data in preprocessed
source.
I've been cross-checking all the tests also against the LLVM implementation
https://github.com/llvm/llvm-project/pull/68620
which has been for a few hours even committed to LLVM trunk but reverted
afterwards. LLVM now has the support committed and I admit I haven't
rechecked whether the behavior on the below mentioned spots have been fixed
in it already or not yet.
The patch uses --embed-dir= option that clang plans to add above and doesn't
use other variants on the search directories yet, plus there are no
default directories at least for the time being where to search for embed
files. So, #embed "..." works if it is found in the same directory (or
relative to the current file's directory) and #embed "/..." or #embed </...>
work always, but relative #embed <...> doesn't unless at least one
--embed-dir= is specified. There is no reason to differentiate between
system and non-system directories, so we don't need -isystem like
counterpart, perhaps -iquote like counterpart could be useful in the future,
dunno what else. It has --embed-directory=dir and --embed-directory dir
as aliases.
There are some differences beyond clang ICEs, so I'd like to point them out
to make sure there is agreement on the choices in the patch. They are also
mentioned in the comments of the llvm pull request.
The most important is that the GCC patch (as well as the original thephd.dev
LLVM branch on godbolt) expands #embed (or acts as if it is expanded) into
a mere sequence of numbers like 123,2,35,26 rather then what clang
effectively treats as (unsigned char)123,(unsigned char)2,(unsigned
char)35,(unsigned char)26 but only does that when using integrated
preprocessor, not when using -save-temps where it acts as GCC.
JeanHeyd as the original author agrees that is how it is currently worded in
C23.
Another difference (not tested in the testsuite, not sure how to check for
effective target /dev/urandom nor am sure it is desirable to check that
during testsuite) is how to treat character devices, named pipes etc.
(block devices are errored on). The original paper uses /dev/urandom
in various examples and seems to assume that unlike regular files the
devices aren't really cached, so
#embed </dev/urandom> limit(1) prefix(int a = ) suffix(;)
#embed </dev/urandom> limit(1) prefix(int b = ) suffix(;)
usually results in a != b. That is what the godbolt thephd.dev branch
implements too and what this patch does as well, but clang actually seems
to just go from st.st_size == 0, ergo it must be zero-sized resource and
so just copies over if_empty if present. It is really questionable
what to do about the character devices/named pipes with __has_embed, for
regular files the patch doesn't read anything from them, relies on
st.st_size + limit for whether it is empty or non-empty. But I don't know
of a way to check if read on say a character device would read anything
or not (the </dev/null> limit (1) vs. </dev/zero> limit (1) cases), and
if we read something, that would be better cached for later because
#embed later if it reads again could read no further data even when it
first read something. So, the patch currently for __has_embed just
always returns 2 on the non-regular files, like the thephd.dev
branch does as well and like the clang pull request as well.
A question is also what to do for gnu::offset on the non-regular files
even for #embed, those aren't seekable and do we want to just read and throw
away the offset bytes each time we see it used?
clang also chokes on the
#if __has_embed (__FILE__ __limit__ (1) __prefix__ () suffix (1 / 0) \
__if_empty__ ((({{[0[0{0{0(0(0)1)1}1}]]}})))) != __STDC_EMBED_FOUND__
#error "__has_embed fail"
#endif
in embed-1.c, but thephd.dev branch accepts it and I don't see why
it shouldn't, (({{[0[0{0{0(0(0)1)1}1}]]}}))) is a balanced token
sequence and the file isn't empty, so it should just be parsed and
discarded.
clang also IMHO mishandles
const unsigned char w[] = {
#embed __FILE__ prefix([0] = 42, [15] =) limit(32)
};
but again only without -save-temps, seems like it
treats it as
[0] = 42, [15] = (99,111,110,115,116,32,117,110,115,105,103,110,101,100,
32,99,104,97,114,32,119,91,93,32,61,32,123,10,35,101,109,98)
rather than
[0] = 42, [15] = 99,111,110,115,116,32,117,110,115,105,103,110,101,100,
32,99,104,97,114,32,119,91,93,32,61,32,123,10,35,101,109,98
and warns on it for -Wunused-value and just compiles it as
[0] = 42, [15] = 98
And also
void foo (int, int, int, int);
void bar (void) { foo (
#embed __FILE__ limit (4) prefix (172 + ) suffix (+ 2)
); }
is treated as
172 + (118, 111, 105, 100) + 2
rather than
172 + 118, 111, 105, 100 + 2
which clang -save-temps or GCC treats it like, so results
in just one argument passed rather than 4.
if (!strstr ((const char *) magna_carta, "imprisonétur")) abort ();
in the testcase fails as well, but in that case calling it in gdb succeeds:
p ((char *(*)(char *, char *))__strstr_sse2) (magna_carta, "imprisonétur")
$2 = 0x555555558d3c <magna_carta+11564> "imprisonétur aut disseisiátur"...
so I guess they are just trying to constant evaluate strstr and do it
incorrectly.
They started with making the optimizations together in the initial patch
set, so they don't have the luxury to compare if it is just because of
the optimization they are trying to do or because that is how the
feature works for them. At least unless they use -save-temps for now.
There is also different behavior between clang and gcc on -M or other
dependency generating options. Seems clang includes the __has_embed
searched files in dependencies, while my patch doesn't. But so does
clang for __has_include and GCC doesn't. Emitting a hard dependency
on some header just because there was __has_include/__has_embed for it
seems wrong to me, because (at least when properly written) the source
likely doesn't mind if the file is missing, it will do something else,
so a hard error from make because of it doesn't seem right. Does
make have some weaker dependencies, such that if some file can be remade
it is but if it doesn't exist, it isn't fatal?
I wonder whether #embed <non-existent-file> really needs to be fatal
or whether we could simply after diagnosing it pretend the file exists
and is empty. For #include I think fatal errors make tons of sense,
but perhaps for #embed which is more localized we'd get better error
reporting if we didn't bail out immediately. Note, both GCC and clang
currently treat those as fatal errors.
clang also added -dE option which with -E instead of preprocessing
the #embed directives keeps them as is, but the preprocessed source
then isn't self-contained. That option looks more harmful than useful to
me.
Also, it isn't clear to me from C23 whether it is possible to have
__has_include/__has_c_attribute/__has_embed expressions inside of
the limit #embed/__has_embed argument.
6.10.3.2/2 says that defined should not appear there (and the patch
diagnoses it and testsuite tests), but for __has_include/__has_embed
etc. 6.10.1/11 says:
"The identifiers __has_include, __has_embed, and __has_c_attribute
shall not appear in any context not mentioned in this subclause."
If that subclause in that case means 6.10.1, then it presumably shouldn't
appear in #embed in 6.10.3, but __has_embed is in 6.10.1...
But 6.10.3.2/3 says that it should be parsed according to the 6.10.1
rules. Haven't included tests like
#if __has_embed (__FILE__ limit (__has_embed (__FILE__ limit (1))))
or
#embed __FILE__ limit (__has_include (__FILE__))
into the testsuite because of the doubts but I think the patch should
handle those right now.
The reason I've used Magna Carta text in some of the testcases is that
I hope it shouldn't be copyrighted after the centuries and I'd strongly
prefer not to have binary blobs in git after the xz backdoor lesson
and wanted something larger which doesn't change all the time.
Oh, BTW, I see in C23 draft 6.10.3.2 in Example 4
if (f_source == NULL);
return 1;
(note the spurious semicolon after closing paren), has that been fixed
already?
Like the thephd.dev and clang implementations, the patch always macro
expands the whole #embed and __has_embed directives except for the
embed keyword. That is most likely not what C23 says, my limited
understanding right now is that in #embed one needs to parse the whole
directive line with macro expansion disabled and check if it satisfies the
grammar, if not, the whole directive is macro expanded, if yes, only
the limit parameter argument is macro expanded and the prefix/suffix/if_empty
arguments are maybe macro expanded when actually used (and not at all if
unused). And I think __has_embed macro expansion has conflicting rules.
2024-09-12 Jakub Jelinek <jakub@redhat.com>
PR c/105863
libcpp/
* include/cpplib.h: Implement C23 N3017 #embed - a scannable,
tooling-friendly binary resource inclusion mechanism paper.
(struct cpp_options): Add embed member.
(enum cpp_builtin_type): Add BT_HAS_EMBED.
(cpp_set_include_chains): Add another cpp_dir * argument to
the declaration.
* internal.h (enum include_type): Add IT_EMBED.
(struct cpp_reader): Add embed_include member.
(struct cpp_embed_params_tokens): New type.
(struct cpp_embed_params): New type.
(_cpp_get_token_no_padding): Declare.
(enum _cpp_find_file_kind): Add _cpp_FFK_EMBED and _cpp_FFK_HAS_EMBED.
(_cpp_stack_embed): Declare.
(_cpp_parse_expr): Change return type to cpp_num_part instead of
bool, change second argument from bool to const char * and add third
argument.
(_cpp_parse_embed_params): Declare.
* directives.cc (DIRECTIVE_TABLE): Add embed entry.
(end_directive): Don't call skip_rest_of_line for T_EMBED directive.
(_cpp_handle_directive): Return 2 rather than 1 for T_EMBED in
directives-only mode.
(parse_include): Don't Call check_eol for T_EMBED directive.
(skip_balanced_token_seq): New function.
(EMBED_PARAMS): Define.
(enum embed_param_kind): New type.
(embed_params): New variable.
(_cpp_parse_embed_params): New function.
(do_embed): New function.
(do_if): Adjust _cpp_parse_expr caller.
(do_elif): Likewise.
* expr.cc (parse_defined): Diagnose defined in #embed or __has_embed
parameters.
(_cpp_parse_expr): Change return type to cpp_num_part instead of
bool, change second argument from bool to const char * and add third
argument. Adjust function comment. For #embed/__has_embed parameters
add an artificial CPP_OPEN_PAREN. Use the second argument DIR
directly instead of string literals conditional on IS_IF.
For #embed/__has_embed parameter, stop on reaching CPP_CLOSE_PAREN
matching the artificial one. Diagnose negative or too large embed
parameter operands.
(num_binary_op): Use #embed instead of #if for diagnostics if inside
#embed/__has_embed parameter.
(num_div_op): Likewise.
* files.cc (struct _cpp_file): Add limit member and embed bitfield.
(search_cache): Add IS_EMBED argument, formatting fix. Skip over
files with different file->embed from the argument.
(find_file_in_dir): Don't call pch_open_file if file->embed.
(_cpp_find_file): Handle _cpp_FFK_EMBED and _cpp_FFK_HAS_EMBED.
(read_file_guts): Formatting fix.
(has_unique_contents): Ignore file->embed files.
(search_path_head): Handle IT_EMBED type.
(_cpp_stack_embed): New function.
(_cpp_get_file_stat): Formatting fix.
(cpp_set_include_chains): Add embed argument, save it to
pfile->embed_include and compute lens for the chain.
* init.cc (struct lang_flags): Add embed member.
(lang_defaults): Add embed initializers.
(cpp_set_lang): Initialize CPP_OPTION (pfile, embed).
(builtin_array): Add __has_embed entry.
(cpp_init_builtins): Predefine __STDC_EMBED_NOT_FOUND__,
__STDC_EMBED_FOUND__ and __STDC_EMBED_EMPTY__.
* lex.cc (cpp_directive_only_process): Handle #embed.
* macro.cc (cpp_get_token_no_padding): Rename to ...
(_cpp_get_token_no_padding): ... this. No longer static.
(builtin_has_include_1): New function.
(builtin_has_include): Use it. Use _cpp_get_token_no_padding
instead of cpp_get_token_no_padding.
(builtin_has_embed): New function.
(_cpp_builtin_macro_text): Handle BT_HAS_EMBED.
gcc/
* doc/cppdiropts.texi (--embed-dir=): Document.
* doc/cpp.texi (Binary Resource Inclusion): New chapter.
(__has_embed): Document.
* doc/invoke.texi (Directory Options): Mention --embed-dir=.
* gcc.cc (cpp_unique_options): Add %{-embed*}.
* genmatch.cc (main): Adjust cpp_set_include_chains caller.
* incpath.h (enum incpath_kind): Add INC_EMBED.
* incpath.cc (merge_include_chains): Handle INC_EMBED.
(register_include_chains): Adjust cpp_set_include_chains caller.
gcc/c-family/
* c.opt (-embed-dir=): New option.
(-embed-directory): New alias.
(-embed-directory=): New alias.
* c-opts.cc (c_common_handle_option): Handle OPT__embed_dir_.
gcc/testsuite/
* c-c++-common/cpp/embed-1.c: New test.
* c-c++-common/cpp/embed-2.c: New test.
* c-c++-common/cpp/embed-3.c: New test.
* c-c++-common/cpp/embed-4.c: New test.
* c-c++-common/cpp/embed-5.c: New test.
* c-c++-common/cpp/embed-6.c: New test.
* c-c++-common/cpp/embed-7.c: New test.
* c-c++-common/cpp/embed-8.c: New test.
* c-c++-common/cpp/embed-9.c: New test.
* c-c++-common/cpp/embed-10.c: New test.
* c-c++-common/cpp/embed-11.c: New test.
* c-c++-common/cpp/embed-12.c: New test.
* c-c++-common/cpp/embed-13.c: New test.
* c-c++-common/cpp/embed-14.c: New test.
* c-c++-common/cpp/embed-25.c: New test.
* c-c++-common/cpp/embed-26.c: New test.
* c-c++-common/cpp/embed-dir/embed-1.inc: New test.
* c-c++-common/cpp/embed-dir/embed-3.c: New test.
* c-c++-common/cpp/embed-dir/embed-4.c: New test.
* c-c++-common/cpp/embed-dir/magna-carta.txt: New test.
* gcc.dg/cpp/embed-1.c: New test.
* gcc.dg/cpp/embed-2.c: New test.
* gcc.dg/cpp/embed-3.c: New test.
* gcc.dg/cpp/embed-4.c: New test.
* g++.dg/cpp/embed-1.C: New test.
* g++.dg/cpp/embed-2.C: New test.
* g++.dg/cpp/embed-3.C: New test.
|
||
|
GCC Administrator
|
ef84d2fea6 | Daily bump. | ||
Alexander Monakov
|
a8260ebeae |
libcpp: deduplicate definition of padding size
Tie together the two functions that ensure tail padding with search_line_ssse3 via CPP_BUFFER_PADDING macro. libcpp/ChangeLog: * internal.h (CPP_BUFFER_PADDING): New macro; use it ... * charset.cc (_cpp_convert_input): ...here, and ... * files.cc (read_file_guts): ...here, and ... * lex.cc (search_line_ssse3): here. |
||
|
GCC Administrator
|
3ff1b91e77 | Daily bump. |