drop -aux{dir,base}, revamp -dump{dir,base} (was: Re: introduce -fcallgraph-info option)
On Dec 25, 2019, Alexandre Oliva wrote:
> 3. do not take the executable name into account when it shares the
> basename with an input file; combine executable basename with input name
> otherwise. this makes gcc -o foo[.exe] -g -gsplit-dwarf foo.c output
> foo.dwo rather than foo-foo.dwo, which is nice, but then dwo files
> compiled for use with foo won't all match foo-*.dwo; it seems more
> desirable that they all do
> 4. same as above, but only when there is only one input file, so that
> after adding bar.c to the command above, you'd get foo-foo.dwo and
> foo-bar.dwo
> Me, I'm leaning towards 5.
And yet I ended up implementing 4 after some more thinking, because the
point was to reduce gratuitous and unnecessary changes.
Here's my first cut at documenting all of the various complex
interactions between -o, -dumpbase, -dumpbase-ext, -dumpdir, and
save-temps=*
Is this too cryptic, to the point of requiring lots of examples to make
it understandable, or is this usable enough?
@@ -1561,6 +1563,89 @@ assembler file in @file{@var{source}.s}, a precompiled
header file in
@file{@var{source}.@var{suffix}.gch}, and all preprocessed C source on
standard output.
+
+@item -dumpbase @var{dumpbase}
+@opindex dumpbase
+This option sets the base name for auxiliary and dump output files. It
+does not affect the name of the main output file, implied or specified
+with @option{-o}. It may affect intermediate outputs, however:
+
+@smallexample
+gcc -save-temps -S foo.c&
+@end smallexample
+
+saves the (no longer) temporary preprocessed file in @file{foo.i}, and
+then compiles to the (implied) output file @file{foo.s}, whereas:
+
+@smallexample
+gcc -save-temps -dumpbase save-foo -c foo.c&
+@end smallexample
+
+preprocesses to in @file{save-foo.i}, compiles to @file{save-foo.s} (now
+an intermediate, thus auxiliary output), and then assembles to the
+(implied) output file @file{foo.o}.
+
+If absent, dump and aux files their names from the input file, or from
+the (non-linker) output file, if one is explicitly specified: dump
+output files (e.g. those requested by -fdump-* options) with the input
+name suffix, and aux output files (those requested by other non-dump
+options, e.g. @code{-save-temps}, @code{-gsplit-dwarf},
+@code{-fcallgraph-info}) without it.
+
+Similar suffix differentiation of dump and aux outputs can be attained
+for explicitly-given @option{-dumpbase basename.suf} by also specifying
+@option{-dumpbase-ext .suf}.
+
+If @var{dumpbase} is explicitly specified with any directory component,
+@option{-dumpdir} and other @var{dumppfx}-setting @option{-save-temps=*}
+options are ignored, and instead of appending to it, @var{dumpbase}
+fully overrides it.
+
+When @option{-dumpbase} is specified in a command that compiles multiple
+inputs, or that compiles and then links, it may be combined with
+@var{dumppfx}, as specified under @option{-dumpdir}, and each input file
+is then compiled using the combined @var{dumppfx}, and default values
+for @var{dumpbase} and @var{auxdropsuf} computed for each input file.
+
+
+@item -dumpbase-ext @var{auxdropsuf}
+@opindex dumpbase-ext
+When forming the name of an auxiliary (but not a dump) output file, drop
+trailing @var{auxdropsuf} from @var{dumpbase} before appending any
+suffixes. If not specified, this option defaults to the suffix of the
+input file, including the period.
+
+
+@item -dumpdir @var{dumppfx}
+@opindex dumpdir
+When forming the name of an auxiliary or dump output file, use
+@var{dumppfx} as a prefix. If it is to be used as a directory name, it
+must end with a directory separator.
+
+It defaults to the location of the output file; options
+@option{-save-temps=cwd} and @option{-save-temps=obj} override this
+default, just like an explicit @option{-dumpdir} option. In case
+multiple such options are given, the last one prevails.
+
+When compiling from multiple input files, if @option{-dumpbase} is
+specified, @var{dumpbase}, minus a @var{auxdropsuf} suffix, and a dash
+are appended to (or override, if containing any directory components) an
+explicit or defaulted @var{dumppfx}, so that each of the multiple
+compilations gets differently-named aux and dump outputs.
+
+When compiling and then linking from multiple input files, a defaulted
+or explicitly specified @var{dumppfx} also undergoes the @var{dumpbase}-
+transformation above. If neither @option{-dumpdir} nor
+@option{-dumpbase} are given, the linker output base name, minus the
+executable suffix, plus a dash is appended to the default @var{dumppfx}
+instead.
+
+When compiling and then linking from a single input file, the linker
+output base name will only be appended to the default @var{dumppfx} as
+above if it does not share the base name with the single input file
+name.
+
+
@item -v
@opindex v
Print (on standard error output) the commands executed to run the stages
--
Alexandre Oliva, freedom fighter he/him https://FSFLA.org/blogs/lxo
Free Software Evangelist
Re: [PATCH 09/13] OpenACC 2.6 deep copy: C and C++ front-end parts
On 12/18/19 1:03 AM, Julian Brown wrote: This patch has been broken out of the "OpenACC 2.6 manual deep copy support" patch, last posted here: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02376.html This part contains the C and C++ changes to parse attach and detach clauses and struct member accesses via "." or "->" on other data-movement clauses (copyin, copyout, etc.). Tested alongside other patches in this series with offloading to NVPTX. OK? The C++ changes look fine to me if they make sense to Jakub. Thanks, Julian ChangeLog gcc/c-family/ * c-common.h (c_omp_map_clause_name): Add prototype. * c-omp.c (c_omp_map_clause_name): New function. * c-pragma.h (pragma_omp_clause): Add PRAGMA_OACC_CLAUSE_ATTACH and PRAGMA_OACC_CLAUSE_DETACH. gcc/c/ * c-parser.c (c_parser_omp_clause_name): Add parsing of attach and detach clauses. (c_parser_omp_variable_list): Add ALLOW_DEREF optional parameter. Allow deref (->) in variable lists if true. (c_parser_omp_var_list_parens): Add ALLOW_DEREF optional parameter. Pass to c_parser_omp_variable_list. (c_parser_oacc_data_clause): Support attach and detach clauses. Update call to c_parser_omp_variable_list. (c_parser_oacc_all_clauses): Support attach and detach clauses. (OACC_DATA_CLAUSE_MASK, OACC_ENTER_DATA_CLAUSE_MASK, OACC_KERNELS_CLAUSE_MASK, OACC_PARALLEL_CLAUSE_MASK, OACC_SERIAL_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_ATTACH. (OACC_EXIT_DATA_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_DETACH. * c-typeck.c (handle_omp_array_sections_1): Reject subarrays for attach and detach. Support deref. (handle_omp_array_sections): Use GOMP_MAP_ATTACH_DETACH instead of GOMP_MAP_ALWAYS_POINTER for OpenACC. (c_oacc_check_attachments): New function. (c_finish_omp_clauses): Check attach/detach arguments for being pointers using above. Support deref. gcc/cp/ * parser.c (cp_parser_omp_clause_name): Support attach and detach clauses. (cp_parser_omp_var_list_no_open): Add ALLOW_DEREF optional parameter. Parse deref if true. (cp_parser_omp_var_list): Add ALLOW_DEREF optional parameter. Pass to cp_parser_omp_var_list_no_open. (cp_parser_oacc_data_clause): Support attach and detach clauses. Update call to cp_parser_omp_var_list_no_open. (cp_parser_oacc_all_clauses): Support attach and detach. (OACC_DATA_CLAUSE_MASK, OACC_ENTER_DATA_CLAUSE_MASK, OACC_KERNELS_CLAUSE_MASK, OACC_PARALLEL_CLAUSE_MASK, OACC_SERIAL_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_ATTACH. (OACC_EXIT_DATA_CLAUSE_MASK): Add PRAGMA_OACC_CLAUSE_DETACH. * semantics.c (handle_omp_array_sections_1): Reject subarrays for attach and detach. (handle_omp_array_sections): Use GOMP_MAP_ATTACH_DETACH instead of GOMP_MAP_ALWAYS_POINTER for OpenACC. (cp_oacc_check_attachments): New function. (finish_omp_clauses): Use above function. Allow structure fields and class members to appear in OpenACC data clauses. Support GOMP_MAP_ATTACH_DETACH. Support deref. gcc/testsuite/ * c-c++-common/goacc/deep-copy-arrayofstruct.c: New test. * c-c++-common/goacc/mdc-1.c: New test. * c-c++-common/goacc/mdc-2.c: New test. * gcc.dg/goacc/mdc.C: New test. --- gcc/c-family/c-common.h | 1 + gcc/c-family/c-omp.c | 33 +++ gcc/c-family/c-pragma.h | 2 + gcc/c/c-parser.c | 53 -- gcc/c/c-typeck.c | 76 +- gcc/cp/parser.c | 56 +-- gcc/cp/semantics.c| 98 --- .../goacc/deep-copy-arrayofstruct.c | 84 gcc/testsuite/c-c++-common/goacc/mdc-1.c | 55 +++ gcc/testsuite/c-c++-common/goacc/mdc-2.c | 62 gcc/testsuite/g++.dg/goacc/mdc.C | 68 + 11 files changed, 554 insertions(+), 34 deletions(-) create mode 100644 gcc/testsuite/c-c++-common/goacc/deep-copy-arrayofstruct.c create mode 100644 gcc/testsuite/c-c++-common/goacc/mdc-1.c create mode 100644 gcc/testsuite/c-c++-common/goacc/mdc-2.c create mode 100644 gcc/testsuite/g++.dg/goacc/mdc.C diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h index 2bcb54f66b9..2d89451b693 100644 --- a/gcc/c-family/c-common.h +++ b/gcc/c-family/c-common.h @@ -1205,6 +1205,7 @@ extern bool c_omp_predefined_variable (tree); extern enum omp_clause_default_kind c_omp_predetermined_sharing (tree); extern tree c_omp_check_context_selector (location_t, tree); extern void c_omp_mark_declare_variant (location_t, tree, tree); +extern const char *c_omp_map_clause_name (tre
Re: [RFC][C++ PATCH] Don't mangle attributes that have a space in their name
On 12/18/19 1:24 PM, Richard Sandiford wrote:
The SVE port needs to maintain a different type identity for
GNU vectors and "SVE vectors" even during LTO, since the types
use different ABIs. The easiest way of doing that seemed to be
to use type attributes. However, these type attributes shouldn't
be user-facing; they're just a convenient way of representing the
types internally in GCC.
There are already several internal-only attributes, such as "fn spec"
and "omp declare simd". They're distinguished from normal user-facing
attributes by having a space in their name, which means that it isn't
possible to write them directly in C or C++.
Taking the same approach mostly works well for SVE. The only snag
I've hit so far is that the new attribute needs to (and only exists to)
affect type identity. This means that it would normally get included
in mangled names, to distinguish it from types without the attribute.
However, the SVE ABI specifies a separate mangling for SVE vector types,
rather than using an attribute mangling + a normal vector mangling.
So we need some way of suppressing the attribute mangling for this case.
There are currently no other target-independent or target-specific
internal-only attributes that affect type identity, so this patch goes
for the simplest fix of skipping mangling for attributes whose names
contain a space. Other options I thought about were:
(1) Also make sure that targetm.mangled_type returns nonnull.
(2) Check directly for the target-specific name.
(3) Add a new target hook.
(4) Add new information to attribute_spec. This would be very invasive
at this stage, but maybe we should consider replacing all the boolean
fields with flags? That should make the tables slightly easier to
read and would make adding new flags much simpler in future.
What do you think? Do any of these sound OK, or is there a better
way of doing it?
Tested on aarch64-linux-gnu and x86_64-linux-gnu.
Thanks,
Richard
2019-12-18 Richard Sandiford
gcc/cp/
* mangle.c (write_CV_qualifiers_for_type): Don't mangle attributes
that contain a space.
This approach works for me. Though that condition is getting large
enough that I might break it out into a separate function.
Index: gcc/cp/mangle.c
===
--- gcc/cp/mangle.c 2019-11-29 13:04:13.654674379 +
+++ gcc/cp/mangle.c 2019-12-18 18:20:05.831412127 +
@@ -2377,6 +2377,11 @@ write_CV_qualifiers_for_type (const tree
tree name = get_attribute_name (a);
const attribute_spec *as = lookup_attribute_spec (name);
if (as && as->affects_type_identity
+ /* Skip internal-only attributes, which are distinguished from
+others by having a space. At present, all internal-only
+attributes that affect type identity are target-specific
+and are handled by targetm.mangle_type instead. */
+ && !strchr (IDENTIFIER_POINTER (name), ' ')
&& !is_attribute_p ("transaction_safe", name)
&& !is_attribute_p ("abi_tag", name))
vec.safe_push (a);
Bountysource campaign for gcc-rust?
Hello! The programming language Rust has become very popular over the past few years with many projects rewriting parts of their codebase in that language. While these rewrites often make the code perform faster and potentially safer, using Rust makes these projects less portable as Rust is limited to the architectures supported by LLVM which are less than the ones supported by GCC. For this reason, people have been asking for a Rust frontend for GCC similar to the one for Go. Now, there are actually two independent implementation of a Rust frontend for GCC [1, 2] being developed and I was wondering whether it would be desirable to help this development with a Bountysource campaign? I'm asking because I'm not sure whether GCC upstream would be okay having a Rust frontend in GCC at all and, if yes, it would be okay to have a Bountysource campaign for that project? I personally like the idea of a Rust frontend for GCC very much as I expect more software projects in the future to adopt Rust and I would like to be able to build and use these projects on architectures that LLVM doesn't support yet (and might not even in the future). Due to the popularity of Rust and the desire of the community for an independent implementation, I expect the Bountysource campaign to be rather successful. Thanks, Adrian > [1] https://github.com/redbrain/gccrs > [2] https://github.com/sapir/gcc-rust/tree/rust -- .''`. John Paul Adrian Glaubitz : :' : Debian Developer - glaub...@debian.org `. `' Freie Universitaet Berlin - glaub...@physik.fu-berlin.de `-GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
