Re: [PATCH][GCC][arm] Add CLI and multilib support for Armv8.1-M Mainline MVE extensions
On Fri, Jan 17, 2020 at 07:58:46PM +0100, Jakub Jelinek wrote:
> One is I wonder if it has been bootstrapped, because at least in a cross
> from x86_64-linux to armv7hl-linux-gnueabi I'm seeing:
> ../../gcc/config/arm/arm.c: In function ‘void
> cmse_nonsecure_call_inline_register_clear()’:
> ../../gcc/config/arm/arm.c:18469:18: warning: unused variable ‘next’
> [-Wunused-variable]
> rtx_insn *next, *last, *pop_insn, *after = insn;
> ^~~~
> warning, which I believe in bootstrap would result in
> -Werror=unused-variable error.
Bootstrap found yet another unused variable:
../../gcc/config/arm/vfp.md:1651:17: warning: unused variable 'regname'
[-Wunused-variable]
Fixed thusly, committed as obvious to trunk.
2020-01-18 Jakub Jelinek
* config/arm/vfp.md (*clear_vfp_multiple): Remove unused variable.
--- gcc/config/arm/vfp.md
+++ gcc/config/arm/vfp.md
@@ -1648,7 +1648,6 @@ (define_insn "*clear_vfp_multiple"
{
int num_regs = XVECLEN (operands[0], 0);
char pattern[30];
-const char *regname;
rtx reg;
strcpy (pattern, \"vscclrm%?\\t{%|\");
Jakub
[wwwdocs,C++] Update notes on C++17 and C++2a support.
Streamline these two sections, remove references to svn.html, note the latter has landed by now. Pushed. Jonathan, Marek, Jason, it might be good if you could go through the page and see whether there are similar simplifications/updates. Thanks, Gerald --- htdocs/projects/cxx-status.html | 8 ++-- 1 file changed, 2 insertions(+), 6 deletions(-) diff --git a/htdocs/projects/cxx-status.html b/htdocs/projects/cxx-status.html index dd3702dc..8d9dbce6 100644 --- a/htdocs/projects/cxx-status.html +++ b/htdocs/projects/cxx-status.html @@ -36,9 +36,7 @@ GCC has experimental support for the next revision of the C++ standard, which is expected to be published in 2020. - C++2a features are available as part of "mainline" GCC -in the trunk of GCC's repository -and will be available in GCC 8 and later. To enable C++2a + C++2a features are available since GCC 8. To enable C++2a support, add the command-line parameter -std=c++2a to your g++ command line. Or, to enable GNU extensions in addition to C++2a features, @@ -462,9 +460,7 @@ https://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2017";>the library documentation. - C++17 features are available as part of "mainline" GCC -in the trunk of GCC's repository -and in GCC 5 and later. To enable C++17 + C++17 features are available since GCC 5. To enable C++17 support, add the command-line parameter -std=c++17 to your g++ command line. Or, to enable GNU extensions in addition to C++17 features, -- 2.24.1
[wwwdocs] Generalize instructions and remove notes on repository mirroring via rsync.
Remove all references how to perform local checkouts, to SVN, and mirroring the repository. Instead generalize descriptions since with the move to Git syncing the repository with rsync and then checking out locally became mostly pointless. Pushed. Gerald --- htdocs/rsync.html | 45 - 1 file changed, 12 insertions(+), 33 deletions(-) diff --git a/htdocs/rsync.html b/htdocs/rsync.html index 29e804ac..18700f58 100644 --- a/htdocs/rsync.html +++ b/htdocs/rsync.html @@ -4,7 +4,7 @@ - + GCC: Anonymous read-only rsync access https://gcc.gnu.org/gcc.css"; /> @@ -12,47 +12,26 @@ GCC: Anonymous read-only rsync access -We are offering our SVN repository and various other data like our FTP -site through anonymous https://rsync.samba.org";>rsync. +We are offering aspects like our mailing list archives, downloads, +etc. through anonymous https://rsync.samba.org";>rsync. +A list of available rsync targets is available via: -That way you can make local copies of the GCC SVN repository to ease -the burden on the GCC main site, and browse the source locally. - -Getting a local copy of GCC repository using rsync - -The GCC repository is available at rsync://gcc.gnu.org/gcc-svn. -As of January 2011 it consumes about 23GB of disk space which takes a -substantial time to transfer. -Subsequent synchronizations will be much faster, as rsync uses a smart -algorithm to only transfer differences. - -Here is how you get a copy of the repository: -rsync --archive --delete --compress rsync://gcc.gnu.org/gcc-svn /usr/local/gcc-local-repo +rsync rsync://gcc.gnu.org/ -The same command can be run periodically to synchronize your copy of -the repository. -Other rsync options that you might want to use include ---verbose and --progress to provide feedback, -including during the initial phase that is otherwise silent. +To obtain a copy of one of the modules: -To get a list of available rsync targets, run: -rsync rsync://gcc.gnu.org/ +rsync --archive --delete --compress rsync://gcc.gnu.org/MODULE /my/local/directory +The same command can be run periodically to synchronize your local +copy. -Using the local repository - -Refer to SVN instructions to check out your -local copy of the repository. Note that the rsync command above will -mirror the repository at its root directory, so the URL you will need -to use to check out from your local repository will look something -like file:///usr/local/gcc-local-repo/ instead of -svn://gcc.gnu.org/svn/gcc/ (i.e., without the trailing -/svn/gcc directory names that would be included for -gcc.gnu.org access). +Other rsync options that you might want to use include +--verbose and --progress to provide feedback, +including during the initial phase that is otherwise silent. -- 2.24.1
Re: [PATCH] Fix noreorder symbol partitioning reversion.
> On Thu, 2020-01-16 at 20:43 +0100, Martin Liška wrote: > > Hi. > > > > The patch is fixes a regression in libgcrypt package where > > we incorrectly forget to stream out a definition of a no-reorder symbol. > > It's caused by LTO balanced map reversion, where we do not revert > > also best_noreorder_pos. > > > > It's pre-approved patch by Honza and I'm going to install it. > > Patch can bootstrap on x86_64-linux-gnu and survives regression tests. > > > > Thanks, > > Martin > > > > > > gcc/lto/ChangeLog: > > > > 2020-01-16 Martin Liska > > > > * lto-partition.c (lto_balanced_map): Remember > > best_noreorder_pos and then restore to it > > when we revert. > Thank you! That addressed several niggling failures. Yep, it is quite intereesting the bug survived multiple releases since the initial Andi's kernel work. On the other hand it reproduces only if you mix in -O0 modules or use explicit -fno-toplevel-reorder. So if you see it in packages it is worth to investigate if build flags are not broken. -O0 -flto is not the most powerful optimization to do. Honza > > jeff > > >
[wwwdocs] Condense and trim three aspects of our snapshot instructions.
This includes folding in a reference to our lists overview as a link into some other text, removing a long obsolete reference to age-old versions of the patch command, and skippking details that are covered by the gcc_update script. Pushed. Gerald --- htdocs/snapshots.html | 11 +++ 1 file changed, 3 insertions(+), 8 deletions(-) diff --git a/htdocs/snapshots.html b/htdocs/snapshots.html index 80d61e27..6567a857 100644 --- a/htdocs/snapshots.html +++ b/htdocs/snapshots.html @@ -21,20 +21,15 @@ progress. Any given snapshot may generate incorrect code or even fail to build. If you plan on downloading and using snapshots, we highly recommend you -subscribe to the GCC mailing lists. See -mailing lists on the main GCC page for instructions on how to subscribe. +subscribe to the GCC mailing lists. When using the diff files to update from older snapshots to newer snapshots, make sure to use "-E" and "-p" arguments to patch so that empty files are -deleted and full pathnames are provided to patch. If your version of -patch does not support "-E", you'll need to get a newer version. Also note -that you may need autoconf, autoheader and various other programs if you use -diff files to update from one snapshot to the next. +deleted and full pathnames are provided to patch. contrib/gcc_update can be used to apply diffs between successive snapshot versions and preserve relations between generated -files so that autoconf et al aren't needed. This is documented in -comments in contrib/gcc_update. +files so that autoconf et al aren't needed. The program sha512sum — which is included with the https://www.gnu.org/software/coreutils/";>GNU Coreutils -- 2.24.1
Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function
On 1/17/20 11:20 PM, Thomas Koenig wrote:
function_reference_1.f90:9:8:
9 | print *, foo(1)%a ! { dg-error "Syntax error" }
| 1
Error: Syntax error in expression at (1)
The error message is not helpful at all. I was recently struggling to
understand why/where some code was failing with syntax error – and it
took me a while to find it. And with this message, I had also to find
out what did go wrong.
How about: ("Unexpected junk after %s at %L",
expr->n.symtree->sym->name, &expr->where)? – or "Unexpected junk in
reference to %s at %L"?
Or deviating from your current error messages: ""Inconsistent use of %s
at %L"
(Side note: I think we have the general problem that expr->where does
not start after the white space, which can be slightly confusing.)
Cheers,
Tobias
[wwwdocs] Have the projects list refer to Git instead of SVN for branches.
Pushed. Gerald --- htdocs/projects/index.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/projects/index.html b/htdocs/projects/index.html index 2c6472cc..26f667bd 100644 --- a/htdocs/projects/index.html +++ b/htdocs/projects/index.html @@ -23,7 +23,7 @@ help develop GCC: Projects for the GCC web pages. Projects for improving the GCC documentation. -There are several development +There are several development branches with projects that you may be able to help out with. Investigate and fix some of the known optimizer inadequacies. -- 2.24.1
Re: analyzer branch renamed to "devel/analyzer"
On Wed, 15 Jan 2020, David Malcolm wrote: > The new git server doesn't seem to like such branch names [1], so I'm > now using "devel/analyzer" Do you plan to also document this in git.html (per the message below you quoted ;-)? > remote: *** Shared development branches should be named devel/*, and > should be documented in https://gcc.gnu.org/git.html . Gerald
Re: [Patch, Fortran + wwwdocs] PR93253 – Document BOZ changes, make it friendlier in legacy code
On Wed, 15 Jan 2020, Tobias Burnus wrote: > Regarding the patch, I enclosed a revised version. I have applied the following markup fix on top. Not a bug (in HTML 5, it would have been in XHTML), though surely not what you intended... Gerald - Log - commit aa1665da66b064f53e5c99a09894003b53779baa Author: Gerald Pfeifer Date: Sat Jan 18 13:01:10 2020 +0100 Close a list item instead of opening an empty one. diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html index 76a4ed9c..66440102 100644 --- a/htdocs/gcc-10/changes.html +++ b/htdocs/gcc-10/changes.html @@ -276,7 +276,7 @@ a work-in-progress. Some of these extensions are permitted with the -fallow-invalid-boz, where the error is degraded to a warning and the code is compiled as with older gfortran. - + At any optimization level except-Os, gfortran now uses inline packing for arguments instead of calling a library
[PATCH] i386: Fix up -fdollars-in-identifiers with identifiers starting with $ in -masm=att (PR target/91298)
Hi!
In AT&T syntax leading $ is special, so if we have identifiers that start
with dollar, we usually fail to assemble it (or assemble incorrectly).
As mentioned in the PR, what works is wrapping the identifiers inside of
parens, like:
movl$($a), %eax
leaq($a)(,%rdi,4), %rax
movl($a)(%rip), %eax
movl($a)+16(%rip), %eax
.globl $a
.type $a, @object
.size $a, 72
$a:
.string "$a"
.quad ($a)
(this is x86_64 -fno-pic -O2). In some places ($a) is not accepted,
like as .globl operand, in .type, .size, so the patch overrides
ASM_OUTPUT_SYMBOL_REF rather than e.g. ASM_OUTPUT_LABELREF.
I didn't want to duplicate what assemble_name is doing (following
transparent aliases), so split assemble_name into two parts; just
mere looking at the first character of a name before calling assemble_name
wouldn't be good enough, a transparent alias could lead from a name
not starting with $ to one starting with it and vice versa.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2020-01-18 Jakub Jelinek
PR target/91298
* output.h (assemble_name_resolve): Declare.
* varasm.c (assemble_name_resolve): New function.
(assemble_name): Use it.
* config/i386/i386.h (ASM_OUTPUT_SYMBOL_REF): Define.
* gcc.target/i386/pr91298-1.c: New test.
* gcc.target/i386/pr91298-2.c: New test.
--- gcc/output.h.jj 2020-01-12 11:54:36.692409199 +0100
+++ gcc/output.h2020-01-17 09:51:27.606873017 +0100
@@ -237,6 +237,12 @@ extern void assemble_label (FILE *, cons
addition of an underscore). */
extern void assemble_name_raw (FILE *, const char *);
+/* Return NAME that should actually be emitted, looking through
+ transparent aliases. If NAME refers to an entity that is also
+ represented as a tree (like a function or variable), mark the entity
+ as referenced. */
+extern const char *assemble_name_resolve (const char *);
+
/* Like assemble_name_raw, but should be used when NAME might refer to
an entity that is also represented as a tree (like a function or
variable). If NAME does refer to such an entity, that entity will
--- gcc/varasm.c.jj 2020-01-12 11:54:38.533381424 +0100
+++ gcc/varasm.c2020-01-17 09:53:14.430239885 +0100
@@ -2589,20 +2589,16 @@ assemble_name_raw (FILE *file, const cha
ASM_OUTPUT_LABELREF (file, name);
}
-/* Like assemble_name_raw, but should be used when NAME might refer to
- an entity that is also represented as a tree (like a function or
- variable). If NAME does refer to such an entity, that entity will
- be marked as referenced. */
-
-void
-assemble_name (FILE *file, const char *name)
+/* Return NAME that should actually be emitted, looking through
+ transparent aliases. If NAME refers to an entity that is also
+ represented as a tree (like a function or variable), mark the entity
+ as referenced. */
+const char *
+assemble_name_resolve (const char *name)
{
- const char *real_name;
- tree id;
+ const char *real_name = targetm.strip_name_encoding (name);
+ tree id = maybe_get_identifier (real_name);
- real_name = targetm.strip_name_encoding (name);
-
- id = maybe_get_identifier (real_name);
if (id)
{
tree id_orig = id;
@@ -2614,7 +2610,18 @@ assemble_name (FILE *file, const char *n
gcc_assert (! TREE_CHAIN (id));
}
- assemble_name_raw (file, name);
+ return name;
+}
+
+/* Like assemble_name_raw, but should be used when NAME might refer to
+ an entity that is also represented as a tree (like a function or
+ variable). If NAME does refer to such an entity, that entity will
+ be marked as referenced. */
+
+void
+assemble_name (FILE *file, const char *name)
+{
+ assemble_name_raw (file, assemble_name_resolve (name));
}
/* Allocate SIZE bytes writable static space with a gensym name
--- gcc/config/i386/i386.h.jj 2020-01-17 09:22:47.524148012 +0100
+++ gcc/config/i386/i386.h 2020-01-17 10:21:10.822480641 +0100
@@ -2258,6 +2258,31 @@ extern int const svr4_dbx_register_map[F
#define ASM_OUTPUT_FUNCTION_LABEL(FILE, NAME, DECL) \
ix86_asm_output_function_label ((FILE), (NAME), (DECL))
+/* A C statement (sans semicolon) to output a reference to SYMBOL_REF SYM.
+ If not defined, assemble_name will be used to output the name of the
+ symbol. This macro may be used to modify the way a symbol is referenced
+ depending on information encoded by TARGET_ENCODE_SECTION_INFO. */
+
+#ifndef ASM_OUTPUT_SYMBOL_REF
+#define ASM_OUTPUT_SYMBOL_REF(FILE, SYM) \
+ do { \
+const char *name \
+ = assemble_name_resolve (XSTR (x, 0)); \
+/* In -masm=att wrap identifiers that start with $ \
+ into parens. */\
+if (name[0] == '$' \
+ && user_label_prefix[0
[PATCH] testsuite: effective_target_march_option: support checking for -march=*
testsuite:
* lib/target-supports.exp (effective_target_march_option): New.
I see no (other) way to, depending on the absence of an option,
add an option for a specific target. Specifically, I don't see
how to do this with dg-skip-if and its friends.
For gcc.dg/torture/pr26515.c and cris-elf, you get an error for
supplying multiple (different) -march=... options (and that
error is desirable), like testing cris-elf with
RUNTESTFLAGS=--target_board=cris-sim/arch=v8, where otherwise
-march=v10 and -march=v8 will both be given, and the test would
fail.
See example last.
Ok to commit the below?
---
gcc/testsuite/lib/target-supports.exp | 4
1 file changed, 4 insertions(+)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 629b454..565cb62 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -2463,6 +2463,10 @@ proc check_effective_target_ti_c64xp { } {
}]
}
+# Check if a -march=... option is given, as part of (earlier) options.
+proc check_effective_target_march_option { } {
+return [check-flags [list "" { *-*-* } { "-march=*" } { "" } ]]
+}
proc check_alpha_max_hw_available { } {
return [check_runtime alpha_max_hw_available {
--
2.11.0
Example usage (one of several similar, which will be committed
together with the above, if approved):
diff --git a/gcc/testsuite/gcc.dg/torture/pr26515.c
b/gcc/testsuite/gcc.dg/torture/pr26515.c
index a051e2e..ff765ba 100644
--- a/gcc/testsuite/gcc.dg/torture/pr26515.c
+++ b/gcc/testsuite/gcc.dg/torture/pr26515.c
@@ -1,4 +1,4 @@
-/* { dg-options "-march=v10" { target cris*-*-* } } */
+/* { dg-options "-march=v10" { target { cris*-*-* && { ! march_option } } } }
*/
struct i
{
long long i_size;
brgds, H-P
Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function
Am 18.01.20 um 12:44 schrieb Tobias Burnus:
function_reference_1.f90:9:8:
9 | print *, foo(1)%a ! { dg-error "Syntax error" }
| 1
Error: Syntax error in expression at (1)
The error message is not helpful at all.
Well, yes. It is no better than what we currently have for the slightly
different test case
type t
integer :: a
end type t
type(t) :: foo
external foo
print *, foo(1)%a
end
which is
a.f90:6:16:
6 | print *, foo(1)%a
|1
Error: Syntax error in PRINT statement at (1)
(but at least that points to the right place).
I can see if I can also replace this with something more useful
(have to find the place where this is issued first, though).
Regards
Thomas
[committed] Reword a comment in varpool_node::ctor_useable_for_folding_p.
2019-01-18 Gerald Pfeifer * varpool.c (ctor_useable_for_folding_p): Fix grammar. --- gcc/ChangeLog | 4 gcc/varpool.c | 7 --- 2 files changed, 8 insertions(+), 3 deletions(-) diff --git a/gcc/varpool.c b/gcc/varpool.c index e5d632e0eb5..458cdf1bf37 100644 --- a/gcc/varpool.c +++ b/gcc/varpool.c @@ -352,9 +352,10 @@ varpool_node::ctor_useable_for_folding_p (void) return DECL_INITIAL (real_node->decl) != NULL; } - /* Alias of readonly variable is also readonly, since the variable is stored - in readonly memory. We also accept readonly aliases of non-readonly - locations assuming that user knows what he is asking for. */ + /* An alias of a read-only variable is also read-only, since the variable + is stored in read-only memory. We also accept read-only aliases of + non-read-only locations assuming that the user knows what he is asking + for. */ if (!TREE_READONLY (decl) && !TREE_READONLY (real_node->decl)) return false; -- 2.24.1
[C++ coroutines] Initial implementation pushed to master.
Hi, Thanks to: * the reviewers, the code was definitely improved by your reviews. * those folks who tested the branch and/or compiler explorer instance and reported problems with reproducers. * WG21 colleagues, especially Lewis and Gor for valuable input and discussions on the design. = TL;DR: * This is not enabled by default (even for -std=c++2a), it needs -fcoroutines. * Like all the C++20 support, it is experimental, perhaps more experimental than some other pieces because wording is still being amended. * The FE/ME tests are run for ALL targets; in principle this should be target- agnostic, if we see fails then that is probably interesting input for the ABI panel. * I regstrapped on 64b LE and BE platforms and a 32b LE host with no observed issues or regressions. * it’s just slightly too big to send uncompressed so attached as a bz2. * commit is r10-6063-g49789fd08 thanks again to all those who helped, Iain == The full covering note: This is the squashed version of the first 6 patches that were split to facilitate review. The changes to libiberty (7th patch) to support demangling the co_await operator stand alone and are applied separately. The patch series is an initial implementation of a coroutine feature, expected to be standardised in C++20. Standardisation status (and potential impact on this implementation) The facility was accepted into the working draft for C++20 by WG21 in February 2019. During following WG21 meetings, design and national body comments have been reviewed, with no significant change resulting. The current GCC implementation is against n4835 [1]. At this stage, the remaining potential for change comes from: * Areas of national body comments that were not resolved in the version we have worked to: (a) handling of the situation where aligned allocation is available. (b) handling of the situation where a user wants coroutines, but does not want exceptions (e.g. a GPU). * Agreed changes that have not yet been worded in a draft standard that we have worked to. It is not expected that the resolution to these can produce any major change at this phase of the standardisation process. Such changes should be limited to the coroutine-specific code. ABI --- The various compiler developers 'vendors' have discussed a minimal ABI to allow one implementation to call coroutines compiled by another. This amounts to: 1. The layout of a public portion of the coroutine frame. Coroutines need to preserve state across suspension points, the storage for this is called a "coroutine frame". The ABI mandates that pointers into the coroutine frame point to an area begining with two function pointers (to the resume and destroy functions described below); these are immediately followed by the "promise object" described in the standard. This is sufficient that the builtins can take a coroutine frame pointer and determine the address of the promise (or call the resume/destroy functions). 2. A number of compiler builtins that the standard library might use. These are implemented by this patch series. 3. This introduces a new operator 'co_await' the mangling for which is also agreed between vendors (and has an issue filed for that against the upstream c++abi). Demangling for this is added to libiberty in a separate patch. The ABI has currently no target-specific content (a given psABI might elect to mandate alignment, but the common ABI does not do this). Standard Library impact --- The current implementations require addition of only a single header to the standard library (no change to the runtime). This header is part of the patch. GCC Implementation outline -- The standard's design for coroutines does not decorate the definition of a coroutine in any way, so that a function is only known to be a coroutine when one of the keywords (co_await, co_yield, co_return) is encountered. This means that we cannot special-case such functions from the outset, but must process them differently when they are finalised - which we do from "finish_function ()". At a high level, this design of coroutine produces four pieces from the original user's function: 1. A coroutine state frame (taking the logical place of the activation record for a regular function). One item stored in that state is the index of the current suspend point. 2. A "ramp" function This is what the user calls to construct the coroutine frame and start the coroutine execution. This will return some object representing the coroutine's eventual return value (or means to continue it when it it suspended). 3. A "resume" function. This is what gets called when a the coroutine is resumed when suspended. 4. A "destroy" function. This is what gets called when the coroutine state should be destroyed
Re: [PATCH] Fix ICE caused by swallowing a token in c_parser_consume_token
On Fri, Jan 17, 2020 at 03:11:40PM +0100, Jakub Jelinek wrote:
> On Fri, Jan 17, 2020 at 09:07:01AM -0500, Jason Merrill wrote:
> > On 12/30/19 3:51 PM, Kerem Kat wrote:
> > > +/* { dg-message "expected" "expected" { target *-*-* } .3 } */
> >
> > Dejagnu doesn't like this:
> >
> > ERROR: c-c++-common/pr92833-4.c -std=c++98: expected integer but got ".3"
> > for " dg-message 4 "expected" "expected" { target *-*-* } .3 "
>
> Yeah, it can handle .-3 if you want 3 lines before the one with dg-message,
> or .+3 if you want 3 lines after it, or . for current line (then you can
> leave that and target out), or exact line number, or some symbolic name if
> earlier marked.
Fixed thusly, committed as obvious to trunk.
2020-01-18 Jakub Jelinek
PR c/92833
* c-c++-common/pr92833-4.c: Fix dg-message syntax.
--- gcc/testsuite/c-c++-common/pr92833-4.c.jj 2020-01-17 09:31:28.672194093
+0100
+++ gcc/testsuite/c-c++-common/pr92833-4.c 2020-01-18 13:51:33.718394204
+0100
@@ -1,7 +1,7 @@
/* Six marker characters at EOF, causes conflict marker detector to peek 4
tokens. */
-/* { dg-message "expected" "expected" { target *-*-* } .3 } */
+/* { dg-message "expected" "expected" { target *-*-* } .+1 } */
>>
>>
>>
\ No newline at end of file
Jakub
Re: [C++ coroutines] Initial implementation pushed to master.
On Sat, Jan 18, 2020 at 12:53:48PM +, Iain Sandoe wrote: Thanks. Shouldn't this be mentioned in https://gcc.gnu.org/projects/cxx-status.html ? > * This is not enabled by default (even for -std=c++2a), it needs -fcoroutines. And, if this is the planned case even for GCC 10 release, I think the -fcoroutines option needs to be mentioned there too. Jakub
Re: [C++ coroutines] Initial implementation pushed to master.
Hi Jakub, Jakub Jelinek wrote: On Sat, Jan 18, 2020 at 12:53:48PM +, Iain Sandoe wrote: Thanks. Shouldn't this be mentioned in https://gcc.gnu.org/projects/cxx-status.html ? * This is not enabled by default (even for -std=c++2a), it needs -fcoroutines. And, if this is the planned case even for GCC 10 release, I think the -fcoroutines option needs to be mentioned there too. Yes, (and I also need to update the wiki), just didn’t want to delay the commit any more. I will get onto those (on Monday probably). Iain
Re: [PATCH] i386: Fix up -fdollars-in-identifiers with identifiers starting with $ in -masm=att (PR target/91298)
On Sat, Jan 18, 2020 at 1:30 PM Jakub Jelinek wrote:
>
> Hi!
>
> In AT&T syntax leading $ is special, so if we have identifiers that start
> with dollar, we usually fail to assemble it (or assemble incorrectly).
> As mentioned in the PR, what works is wrapping the identifiers inside of
> parens, like:
> movl$($a), %eax
> leaq($a)(,%rdi,4), %rax
> movl($a)(%rip), %eax
> movl($a)+16(%rip), %eax
> .globl $a
> .type $a, @object
> .size $a, 72
> $a:
> .string "$a"
> .quad ($a)
> (this is x86_64 -fno-pic -O2). In some places ($a) is not accepted,
> like as .globl operand, in .type, .size, so the patch overrides
> ASM_OUTPUT_SYMBOL_REF rather than e.g. ASM_OUTPUT_LABELREF.
> I didn't want to duplicate what assemble_name is doing (following
> transparent aliases), so split assemble_name into two parts; just
> mere looking at the first character of a name before calling assemble_name
> wouldn't be good enough, a transparent alias could lead from a name
> not starting with $ to one starting with it and vice versa.
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2020-01-18 Jakub Jelinek
>
> PR target/91298
> * output.h (assemble_name_resolve): Declare.
> * varasm.c (assemble_name_resolve): New function.
> (assemble_name): Use it.
> * config/i386/i386.h (ASM_OUTPUT_SYMBOL_REF): Define.
>
> * gcc.target/i386/pr91298-1.c: New test.
> * gcc.target/i386/pr91298-2.c: New test.
x86 part is OK, with a nit below.
Thanks,
Uros.
> --- gcc/output.h.jj 2020-01-12 11:54:36.692409199 +0100
> +++ gcc/output.h2020-01-17 09:51:27.606873017 +0100
> @@ -237,6 +237,12 @@ extern void assemble_label (FILE *, cons
> addition of an underscore). */
> extern void assemble_name_raw (FILE *, const char *);
>
> +/* Return NAME that should actually be emitted, looking through
> + transparent aliases. If NAME refers to an entity that is also
> + represented as a tree (like a function or variable), mark the entity
> + as referenced. */
> +extern const char *assemble_name_resolve (const char *);
> +
> /* Like assemble_name_raw, but should be used when NAME might refer to
> an entity that is also represented as a tree (like a function or
> variable). If NAME does refer to such an entity, that entity will
> --- gcc/varasm.c.jj 2020-01-12 11:54:38.533381424 +0100
> +++ gcc/varasm.c2020-01-17 09:53:14.430239885 +0100
> @@ -2589,20 +2589,16 @@ assemble_name_raw (FILE *file, const cha
> ASM_OUTPUT_LABELREF (file, name);
> }
>
> -/* Like assemble_name_raw, but should be used when NAME might refer to
> - an entity that is also represented as a tree (like a function or
> - variable). If NAME does refer to such an entity, that entity will
> - be marked as referenced. */
> -
> -void
> -assemble_name (FILE *file, const char *name)
> +/* Return NAME that should actually be emitted, looking through
> + transparent aliases. If NAME refers to an entity that is also
> + represented as a tree (like a function or variable), mark the entity
> + as referenced. */
> +const char *
> +assemble_name_resolve (const char *name)
> {
> - const char *real_name;
> - tree id;
> + const char *real_name = targetm.strip_name_encoding (name);
> + tree id = maybe_get_identifier (real_name);
>
> - real_name = targetm.strip_name_encoding (name);
> -
> - id = maybe_get_identifier (real_name);
>if (id)
> {
>tree id_orig = id;
> @@ -2614,7 +2610,18 @@ assemble_name (FILE *file, const char *n
>gcc_assert (! TREE_CHAIN (id));
> }
>
> - assemble_name_raw (file, name);
> + return name;
> +}
> +
> +/* Like assemble_name_raw, but should be used when NAME might refer to
> + an entity that is also represented as a tree (like a function or
> + variable). If NAME does refer to such an entity, that entity will
> + be marked as referenced. */
> +
> +void
> +assemble_name (FILE *file, const char *name)
> +{
> + assemble_name_raw (file, assemble_name_resolve (name));
> }
>
> /* Allocate SIZE bytes writable static space with a gensym name
> --- gcc/config/i386/i386.h.jj 2020-01-17 09:22:47.524148012 +0100
> +++ gcc/config/i386/i386.h 2020-01-17 10:21:10.822480641 +0100
> @@ -2258,6 +2258,31 @@ extern int const svr4_dbx_register_map[F
> #define ASM_OUTPUT_FUNCTION_LABEL(FILE, NAME, DECL) \
>ix86_asm_output_function_label ((FILE), (NAME), (DECL))
>
> +/* A C statement (sans semicolon) to output a reference to SYMBOL_REF SYM.
> + If not defined, assemble_name will be used to output the name of the
> + symbol. This macro may be used to modify the way a symbol is referenced
> + depending on information encoded by TARGET_ENCODE_SECTION_INFO. */
> +
> +#ifndef ASM_OUTPUT_SYMBOL_REF
> +#define ASM_OUTPUT_SYMBOL_REF(FILE, SYM) \
> + do { \
> +
[COMMITTED] config.gcc : Add crisv32-*-* and cris-*-linux*
I'm sorry to say that there's no incentive to maintain
crisv32-*-* and cris-*-linux* configurations beyond nostalgia,
(and I'm out of that for the moment). Support in the Linux
kernel for either applicable CRIS variant (CRIS v10 and CRIS
v32) is gone since 2018. Their related part of the cc0
transition workload would be noticable. Note that cris-elf
remains, but crisv32-elf and the CRIS v32 multilib will be
removed, at least for now.
I'm not completely happy about the message (the next-next line
after the context) "*** unless a maintainer comes forward"
because it'd have to be at an infinitesimal maintenance cost to
the cris-elf support. Still, I'm not bothered enough to add
another case construct or means for "planned obsolescence".
Since we're very late at the gcc-10 cycle, maybe best to commit
the cc0 transition for CRIS to "gcc-11" instead, and leave these
targets enabled-but-obsoleted in gcc-10. I believe that's the
formally more correct way to go, even if pragmatically no-one
cares. I think I'll put that work on a branch for now.
---
gcc/ChangeLog | 4
gcc/config.gcc | 2 ++
2 files changed, 6 insertions(+)
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 423899d3988..b4c45a45087 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,7 @@
+2020-01-17 Hans-Peter Nilsson
+
+ * config.gcc : Add crisv32-*-* and cris-*-linux*
+
2020-01-17 Richard Sandiford
* gimplify.c (gimplify_return_expr): Use poly_int_tree_p rather
diff --git a/gcc/config.gcc b/gcc/config.gcc
index 5a2f1730477..5532a7be6ac 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -248,6 +248,8 @@ md_file=
# Obsolete configurations.
case ${target} in
tile*-*-*\
+ | crisv32-*-* \
+ | cris-*-linux* \
)
if test "x$enable_obsolete" != xyes; then
echo "*** Configuration ${target} is obsolete." >&2
--
2.11.0
brgds, H-P
Re: [PATCH] contrib/download_prerequisites: Use http instead of ftp
On Tue, 12 Nov 2019, Janne Blomqvist wrote: > Convert the download_prerequisites script to use http instead of > ftp. This works better with firewalls, proxies, and so on. It's also > faster, a quick test on my system before patch: Plus common web browsers are starting to deprecate and actually remove support for the FTP protocol. Thank you for making this change, and I've made some associated changes to our web pages, too, this week. If you see any further ones, let's proceed. > Question: Should we in fact use https? I haven't used it since > download_prerequisites checks that the sha512/md5 matches the > ones in the GCC tree, but maybe there are reasons? I don't see a strong case for https over http in this context, but would not be opposed either. Gerald
[committed][GCC][PATCH][AArch64] Fix unused variable warning breaking bootstrap.
Hi All,
This marks the parameter &fi as unused so it doesn't
cause a boostrap failure.
Bootstrapped aarch64-none-linux-gnu.
committed under the obvious rule.
Thanks,
Tamar
gcc/ChangeLog:
2020-01-18 Tamar Christina
* config/aarch64/aarch64-sve-builtins-base.cc (memory_vector_mode):
Mark parameter unused.
--
diff --git a/gcc/config/aarch64/aarch64-sve-builtins-base.cc b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
index 868a6afaf2e77a77df8a97e2c874d52f5c0b7029..b48932f6a4fd265e1f5d0bd62d222c163857b63e 100644
--- a/gcc/config/aarch64/aarch64-sve-builtins-base.cc
+++ b/gcc/config/aarch64/aarch64-sve-builtins-base.cc
@@ -1206,7 +1206,7 @@ class svld1ro_impl : public load_replicate
{
public:
machine_mode
- memory_vector_mode (const function_instance &fi) const OVERRIDE
+ memory_vector_mode (const function_instance &fi ATTRIBUTE_UNUSED) const OVERRIDE
{
return OImode;
}
Re: Analyzer committed to master (was Re: Analyzer status)
Hi David, >> I'm seeing quite a number of failures on Solaris (both sparc and >> x86), >> but also some on 32-bit Linux/x86: >> >> Running target unix/-m32 >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 610) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 611) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 615) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 616) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 657) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 658) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 662) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 663) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 705) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 706) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 710) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 711) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 753) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 754) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 758) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for warnings, line 759) >> +FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors) > > Thanks, and sorry about this; I've filed this for myself as: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93281 > and have been investigating. > >> I'll file PRs for the Solaris ones once I get to it. I've now filed PR analyzer/93316 for the rest; most of the errors there also occur on at least one non-Solaris target. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
[COMMITTED] libgcc: cris: config/cris/arit.c (DS): Apply attribute __fallthrough__.
libgcc:
* config/cris/arit.c (DS): Apply attribute __fallthrough__.
Without this, there are, for each compilation of arit.c, 30ish
occurrences of "this statement may fall through
[-Wimplicit-fallthrough=]", for lines that look like
case 32: DS; case 31: DS; case 30: DS; case 29: DS;
Noticed while working on the cc0 transition. Looks like I don't
inspect the logs often.
Adding -Werror to libgcc build-options should perhaps be
considered?
---
libgcc/config/cris/arit.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/libgcc/config/cris/arit.c b/libgcc/config/cris/arit.c
index ba1c1e7..3369559 100644
--- a/libgcc/config/cris/arit.c
+++ b/libgcc/config/cris/arit.c
@@ -128,7 +128,8 @@ do_31div (unsigned long a, unsigned long b)
i.e. "a - (b - 1) == (a - b) + 1". */
b--;
-#define DS __asm__ ("dstep %2,%0" : "=r" (a) : "0" (a), "r" (b))
+#define DS __asm__ ("dstep %2,%0" : "=r" (a) : "0" (a), "r" (b)); \
+ __attribute__ ((__fallthrough__))
switch (quot_digits)
{
--
2.11.0
brgds, H-P
New Chinese (traditional) PO file for 'gcc' (version 9.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Chinese (traditional) team of translators. The file is available at: https://translationproject.org/latest/gcc/zh_TW.po (This file, 'gcc-9.1.0.zh_TW.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
New Chinese (traditional) PO file for 'gcc' (version 9.1.0)
Hello, gentle maintainer. This is a message from the Translation Project robot. A revised PO file for textual domain 'gcc' has been submitted by the Chinese (traditional) team of translators. The file is available at: https://translationproject.org/latest/gcc/zh_TW.po (This file, 'gcc-9.1.0.zh_TW.po', has just now been sent to you in a separate email.) All other PO files for your package are available in: https://translationproject.org/latest/gcc/ Please consider including all of these in your next release, whether official or a pretest. Whenever you have a new distribution with a new version number ready, containing a newer POT file, please send the URL of that distribution tarball to the address below. The tarball may be just a pretest or a snapshot, it does not even have to compile. It is just used by the translators when they need some extra translation context. The following HTML page has been updated: https://translationproject.org/domain/gcc.html If any question arises, please contact the translation coordinator. Thank you for all your work, The Translation Project robot, in the name of your translation coordinator.
Re: [PATCH] ipa-profile.c: reset call_sums state within ipa-profile.c (PR ipa/93315)
> > > On Mon, 2020-01-13 at 11:23 +0800, luoxhu wrote: > > > On 2020/1/10 19:08, Jan Hubicka wrote: > > > > OK. You will need to do the obvious updates for Martin's patch > > > > which turned some member functions into static functions. > > > > > > > > Honza > > > > > > Thanks a lot! Rebased & updated, will commit below patch shortly > > > when git push is ready. > > > > > > > > > v8: > > > 1. Rebase to master with Martin's static function (r280043) comments > > > merge. > > > Boostrap/testsuite/SPEC2017 tested pass on Power8-LE. > > > 2. TODO: > > > 2.1. C++ devirt for multiple speculative call targets. > > > 2.2. ipa-icf ipa_merge_profiles refine with COMDAT inline > > > testcase. > > > > [...] > > > > > diff --git a/gcc/ipa-profile.c b/gcc/ipa-profile.c > > > > [...] > > > > > +static ipa_profile_call_summaries *call_sums = NULL; > > > > [...] > > > > > static void > > > ipa_profile_generate_summary (void) > > > @@ -169,7 +261,10 @@ ipa_profile_generate_summary (void) > > >basic_block bb; > > > > > >hash_table hashtable (10); > > > - > > > + > > > + gcc_checking_assert (!call_sums); > > > + call_sums = new ipa_profile_call_summaries (symtab); > > > + > > > > [...] > > > > Unfortunately, this assertion is failing for most of the testcases in > > jit.dg, reducing the number of PASS results in jit.sum from 10473 down > > to 3254 in my builds. > > > > > > Counter-intuitively, "jit" is not in --enable-languages=all (as it also > > needs --enable-host-shared at configure time, which slows down the > > built compiler code). > > > > > > The jit code expects to be able to invoke the compiler code more than > > once within the same process, purging all state. > > > > It looks like this "call_sums" state needs deleting and resetting to > > NULL after the compiler has run (or else we'll likely get an ICE due to > > using old symtab/call summaries in subsequent in-process runs of the > > compiler). > > > > Is there a natural place to do that within the IPA hooks? > > > > > > Alternatively the following patch seems to fix things (not yet fully > > tested though); hopefully it seems sane. > > Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu; fixes > the issue with jit.sum. > > OK for master? > > gcc/ChangeLog: > PR ipa/93315 > * ipa-profile.c (ipa_profile_c_finalize): New function. > * toplev.c (toplev::finalize): Call it. > * toplev.h (ipa_profile_c_finalize): New decl. Other similar summaries are freed at the end of execute method. I think that we probably want to do the same for consistency as well. Advantage is that this releases memory prior late compilation/streaming. I think for all these summaries we have leak for -flto compilation where we do not call execute methods and thus we do not free the summaries. Is this problem for jit? Honza
Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function
Hello world,
I found an ommission in primary.c which prevented issuing a
more specific error instead of "syntax error" for the case
when a function was declared in an EXTERNAL statement,
and I have now gone for the "Unexpected junk after foo"
variant.
Regression-tested. OK for trunk?
Regards
Thomas
2020-01-18 Thomas König
PR fortran/44960
* primary.c (gfc_match_rvalue): Break after setting MATCH_ERROR.
* resolve.c (resolve_function): Issue error when a
function call contains a reference.
2020-01-18 Thomas König
PR fortran/44960
* gfortran.dg/function_reference_1.f90: New test.
diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c
index 07b8ac08ba2..bd50827bb15 100644
--- a/gcc/fortran/primary.c
+++ b/gcc/fortran/primary.c
@@ -3661,6 +3661,7 @@ gfc_match_rvalue (gfc_expr **result)
gfc_error ("The leftmost part-ref in a data-ref cannot be a "
"function reference at %C");
m = MATCH_ERROR;
+ break;
}
m = MATCH_YES;
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 6f2a4c4d65a..697afadb378 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -3129,6 +3129,13 @@ resolve_function (gfc_expr *expr)
|| sym->intmod_sym_id == GFC_ISYM_CAF_SEND))
return true;
+ if (expr->ref)
+{
+ gfc_error ("Unexpected junk after %qs at %L", expr->symtree->n.sym->name,
+ &expr->where);
+ return false;
+}
+
if (sym && sym->attr.intrinsic
&& !gfc_resolve_intrinsic (sym, &expr->where))
return false;
diff --git a/gcc/testsuite/gfortran.dg/function_reference_1.f90 b/gcc/testsuite/gfortran.dg/function_reference_1.f90
new file mode 100644
index 000..be634c9dd4b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/function_reference_1.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR 44960 - this was erroneusly accepted.
+! Original test case by Daniel Franke.
+
+type t
+ integer :: a
+end type t
+type(t) :: foo
+print *, foo(1)%a ! { dg-error "Unexpected junk" }
+end
+
diff --git a/gcc/testsuite/gfortran.dg/function_reference_2.f90 b/gcc/testsuite/gfortran.dg/function_reference_2.f90
new file mode 100644
index 000..375c58bb6d2
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/function_reference_2.f90
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! PR 44960 - improve the error message
+program main
+ type t
+ integer :: a
+end type t
+type(t) :: foo
+external foo
+i = foo(1)%1 ! { dg-error "leftmost part-ref in a data-ref cannot be a function reference" }
+end
! { dg-do compile }
! PR 44960 - improve the error message
program main
type t
integer :: a
end type t
type(t) :: foo
external foo
i = foo(1)%1 ! { dg-error "leftmost part-ref in a data-ref cannot be a function reference" }
end
! { dg-do compile }
! PR 44960 - this was erroneusly accepted.
! Original test case by Daniel Franke.
type t
integer :: a
end type t
type(t) :: foo
print *, foo(1)%a ! { dg-error "Unexpected junk" }
end
[PATCH] c++: Fix coroutines.cc build for nvptx-none target
Hi! When building offloading cross-compiler from x86_64-linux to nvptx-none, the build fails with: ../../gcc/cp/coroutines.cc: In function 'tree_node* get_fn_local_identifier(tree, const char*)': ../../gcc/cp/coroutines.cc:2255:12: error: expected ';' before 'char' 2255 | sep = "$" |^ |; .. 2262 | char *an; | I'll commit the following fix as obvious if it builds successfully. 2020-01-18 Jakub Jelinek * coroutines.cc (get_fn_local_identifier): Fix NO_DOT_IN_LABEL but non-NO_DOLLAR_IN_LABEL case build. --- gcc/cp/coroutines.cc.jj 2020-01-18 13:47:09.318360691 +0100 +++ gcc/cp/coroutines.cc2020-01-18 19:05:48.349119608 +0100 @@ -2252,7 +2252,7 @@ get_fn_local_identifier (tree orig, cons sep = "."; #else #ifndef NO_DOLLAR_IN_LABEL - sep = "$" + sep = "$"; #else sep = "_"; pfx = "__"; Jakub
Re: [patch, fortran] Fix PR 44960, accepts invalid reference on function
Hello Thomas, looks good to me. Nice catch the missing "break". Tobias PS: I think it does not exercise a differ code path, but instead of derived types, using a character string works as well. The following is accepted with the unmodified trunk: character(len=4):: str print *, str(1)(1:4) end On 1/18/20 7:04 PM, Thomas Koenig wrote: Hello world, I found an ommission in primary.c which prevented issuing a more specific error instead of "syntax error" for the case when a function was declared in an EXTERNAL statement, and I have now gone for the "Unexpected junk after foo" variant. Regression-tested. OK for trunk? Regards Thomas 2020-01-18 Thomas König PR fortran/44960 * primary.c (gfc_match_rvalue): Break after setting MATCH_ERROR. * resolve.c (resolve_function): Issue error when a function call contains a reference. 2020-01-18 Thomas König PR fortran/44960 * gfortran.dg/function_reference_1.f90: New test.
Re: [PATCH] RFC: testsuite: add minimium version to dg-require-dot (PR analyzer/93293)
On Jan 17, 2020, at 2:07 PM, David Malcolm wrote: > > I ran into difficulties with the Graphviz format changing from under > me during an upgrade, where the new version of "dot" would reject .dot > files generated by the analyzer. > > Thoughts? [ consider this a peanut gallery comment ] Another thought would be to bump the version required and just not worry about it. The people that have, like and use dot, are likely small, so I'd like to think they can update it. I don't have/use dot, so, I'm happy to defer to others that have, use, and play with dot.
Re: [PATCH] analyzer: ensure that all DejaGnu tests have unique names
On Jan 17, 2020, at 1:30 PM, David Malcolm wrote: > > Jeff noticed various name collisions of test names in the analyzer > testsuite, due to me using empty comment strings when using line > offsets in test directives. > > This patch adds non-empty comment strings to such DejaGnu directives > throughout the analyzer testsuite. > > OK for master? Ok.
Re: [PATCH] testsuite: effective_target_march_option: support checking for -march=*
> On Jan 18, 2020, at 4:35 AM, Hans-Peter Nilsson wrote: > > testsuite: > * lib/target-supports.exp (effective_target_march_option): New. > > I see no (other) way to, depending on the absence of an option, > add an option for a specific target. Specifically, I don't see > how to do this with dg-skip-if and its friends. > > For gcc.dg/torture/pr26515.c and cris-elf, you get an error for > supplying multiple (different) -march=... options (and that > error is desirable), like testing cris-elf with > RUNTESTFLAGS=--target_board=cris-sim/arch=v8, where otherwise > -march=v10 and -march=v8 will both be given, and the test would > fail. > > Ok to commit the below? Ok. [ If the arm folks want to chime in with any great ideas... ]
