Re: [Patch] OpenMP: Add iterator support to Fortran's depend; add affinity clause
On Fri, May 28, 2021 at 12:59:20AM +0200, Tobias Burnus wrote:
> * gfortran.dg/gomp/depend-iterator-1.f90: New test.
> * gfortran.dg/gomp/depend-iterator-2.f90: New test.
Something I've missed during the review but it shows up during testing:
> diff --git a/gcc/testsuite/gfortran.dg/gomp/depend-iterator-1.f90
> b/gcc/testsuite/gfortran.dg/gomp/depend-iterator-1.f90
> new file mode 100644
> index 000..cad36aaf8b7
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/depend-iterator-1.f90
> @@ -0,0 +1,45 @@
> +! { dg-do run }
gcc/testsuite/*/gomp/ shouldn't have dg-do run tests, either
it is meant to be a runtime test and then it should be moved to
libgomp/testsuite/libgomp.fortran/ , or it should be changed to
dg-do compile.
> --- /dev/null
> +++ b/gcc/testsuite/gfortran.dg/gomp/depend-iterator-2.f90
> @@ -0,0 +1,44 @@
> +! { dg-do run }
And this one has dg-error in it, so this one must be dg-do compile.
> + !$omp task depend (iterator (j=i:i+1) , out : foo (j)) ! { dg-error
> "is not a variable" }
> +arr(i) = i
> + !!$omp end task
> +!$omp task depend(iterator(i=1:5), source ) ! { dg-error "ITERATOR may
> not be combined with SOURCE" }
> + !!$omp end task
> + !$omp task affinity (iterator(i=1:5): a) depend(iterator(i=1:5), sink : x)
> ! { dg-error "ITERATOR may not be combined with SINK" }
Jakub
[committed] openmp: Add shared to parallel for linear on parallel master taskloop simd [PR99928]
Hi!
I forgot to add default(none) and defaultmap(none) wherever possible on the
testcases to make sure none of the required clauses are added implicitly
(because
in that case it doesn't work with these none arguments of those default* clauses
or works differently with other default* settings.
And that revealed we didn't add shared on parallel for linear clause
on parallel master taskloop simd, so this patch fixes that too.
Bootstrapped/regtested on x86_64-linux, committed to trunk.
2021-05-29 Jakub Jelinek
PR middle-end/99928
* gimplify.c (gimplify_scan_omp_clauses): For taskloop simd
combined with parallel, make sure to add shared clause to
parallel for explicit linear clause.
* c-c++-common/gomp/pr99928-1.c: Add default(none) to constructs
combined with parallel, teams or taskloop and defaultmap(none)
to constructs combined with target.
* c-c++-common/gomp/pr99928-2.c: Likewise.
* c-c++-common/gomp/pr99928-3.c: Likewise.
* c-c++-common/gomp/pr99928-4.c: Likewise.
* c-c++-common/gomp/pr99928-5.c: Likewise.
* c-c++-common/gomp/pr99928-6.c: Likewise.
* c-c++-common/gomp/pr99928-7.c: Likewise.
* c-c++-common/gomp/pr99928-8.c: Likewise.
* c-c++-common/gomp/pr99928-9.c: Likewise.
* c-c++-common/gomp/pr99928-10.c: Likewise.
* c-c++-common/gomp/pr99928-13.c: Likewise.
* c-c++-common/gomp/pr99928-14.c: Likewise.
--- gcc/gimplify.c.jj 2021-05-28 11:03:19.620882465 +0200
+++ gcc/gimplify.c 2021-05-28 19:32:07.507156930 +0200
@@ -9014,6 +9014,7 @@ gimplify_scan_omp_clauses (tree *list_p,
lastprivate and perhaps firstprivate too on the
parallel. Similarly for #pragma omp for simd. */
struct gimplify_omp_ctx *octx = outer_ctx;
+ bool taskloop_seen = false;
decl = NULL_TREE;
do
{
@@ -9045,11 +9046,12 @@ gimplify_scan_omp_clauses (tree *list_p,
else if (octx
&& (octx->region_type & ORT_TASK) != 0
&& octx->combined_loop)
- ;
+ taskloop_seen = true;
else if (octx
&& octx->region_type == ORT_COMBINED_PARALLEL
- && ctx->region_type == ORT_WORKSHARE
- && octx == outer_ctx)
+ && ((ctx->region_type == ORT_WORKSHARE
+ && octx == outer_ctx)
+ || taskloop_seen))
flags = GOVD_SEEN | GOVD_SHARED;
else if (octx
&& ((octx->region_type & ORT_COMBINED_TEAMS)
--- gcc/testsuite/c-c++-common/gomp/pr99928-1.c.jj 2021-05-13
16:53:31.061368346 +0200
+++ gcc/testsuite/c-c++-common/gomp/pr99928-1.c 2021-05-28 19:41:20.326231536
+0200
@@ -12,14 +12,14 @@ foo (void)
/* { dg-final { scan-tree-dump "omp
distribute\[^\n\r]*firstprivate\\(f00\\)" "gimple" } } */
/* { dg-final { scan-tree-dump "omp parallel\[^\n\r]*firstprivate\\(f00\\)"
"gimple" } } *//* FIXME: This should be on for instead. */
/* { dg-final { scan-tree-dump-not "omp for\[^\n\r]*firstprivate\\(f00\\)"
"gimple" } } *//* FIXME. */
- #pragma omp distribute parallel for firstprivate (f00)
+ #pragma omp distribute parallel for firstprivate (f00) default(none)
for (int i = 0; i < 64; i++)
f00++;
/* { dg-final { scan-tree-dump "omp
distribute\[^\n\r]*firstprivate\\(f01\\)" "gimple" } } */
/* { dg-final { scan-tree-dump "omp parallel\[^\n\r]*firstprivate\\(f01\\)"
"gimple" } } *//* FIXME: This should be on for instead. */
/* { dg-final { scan-tree-dump-not "omp for\[^\n\r]*firstprivate\\(f01\\)"
"gimple" } } *//* FIXME. */
/* { dg-final { scan-tree-dump-not "omp simd\[^\n\r]*firstprivate\\(f01\\)"
"gimple" } } */
- #pragma omp distribute parallel for simd firstprivate (f01)
+ #pragma omp distribute parallel for simd firstprivate (f01) default(none)
for (int i = 0; i < 64; i++)
f01++;
/* { dg-final { scan-tree-dump "omp
distribute\[^\n\r]*firstprivate\\(f02\\)" "gimple" } } */
@@ -40,53 +40,53 @@ bar (void)
f03++;
/* { dg-final { scan-tree-dump-not "omp
master\[^\n\r]*firstprivate\\(f04\\)" "gimple" } } */
/* { dg-final { scan-tree-dump "omp taskloop\[^\n\r]*firstprivate\\(f04\\)"
"gimple" } } */
- #pragma omp master taskloop firstprivate (f04)
+ #pragma omp master taskloop firstprivate (f04) default(none)
for (int i = 0; i < 64; i++)
f04++;
/* { dg-final { scan-tree-dump-not "omp
master\[^\n\r]*firstprivate\\(f05\\)" "gimple" } } */
/* { dg-final { scan-tree-dump "omp taskloop\[^\n\r]*firstprivate\\(f05\\)"
"gimple" } } */
/* { dg-final { scan-tree-dump-not "omp simd\[^\n\r]*firstprivate\\(f05\\)"
"gimple" } } */
- #pragma omp master taskloop simd firstprivate (f05)
+ #pragma omp mast
[committed][PR bootstrap/100730] Fix warnings in H8 target files
Jan-Benedict's tester uses -enable-werror-always and thus will trip over
certain compilation issues that my tester would miss. This patches
addresses a few minor issues in the H8 backend flagged by Jan-Benedict's
tester.
In addition to verifying this fixes the failures Jan-Benedict reported,
I've also run this through my tester to ensure it didn't regress any tests.
Committed to the trunk,
Jeff
commit 32784a3de34e27ad136beeb27b2bfb24ecb0fb3b
Author: root
Date: Sat May 29 11:33:05 2021 -0400
[committed][PR bootstrap/100730] Fix warnings in H8 target files
gcc/
* config/h8300/h8300.c (h8300_emit_stack_adjustment): Drop unused
parameter. Call callers fixed.
(push): Likewise.
(output_plussi): Add FALLTHRU markers.
(h8300_shift_needs_scratch_p): Add gcc_unreachable marker.
diff --git a/gcc/config/h8300/h8300.c b/gcc/config/h8300/h8300.c
index 0ae8030cf62..ba2b9daf487 100644
--- a/gcc/config/h8300/h8300.c
+++ b/gcc/config/h8300/h8300.c
@@ -91,7 +91,7 @@ static int h8300_interrupt_function_p (tree);
static int h8300_saveall_function_p (tree);
static int h8300_monitor_function_p (tree);
static int h8300_os_task_function_p (tree);
-static void h8300_emit_stack_adjustment (int, HOST_WIDE_INT, bool);
+static void h8300_emit_stack_adjustment (int, HOST_WIDE_INT);
static HOST_WIDE_INT round_frame_size (HOST_WIDE_INT);
static unsigned int compute_saved_regs (void);
static const char *cond_string (enum rtx_code);
@@ -452,7 +452,7 @@ Fpa (rtx par)
SIZE to adjust the stack pointer. */
static void
-h8300_emit_stack_adjustment (int sign, HOST_WIDE_INT size, bool in_prologue)
+h8300_emit_stack_adjustment (int sign, HOST_WIDE_INT size)
{
/* If the frame size is 0, we don't have anything to do. */
if (size == 0)
@@ -511,7 +511,7 @@ compute_saved_regs (void)
/* Emit an insn to push register RN. */
static rtx
-push (int rn, bool in_prologue)
+push (int rn)
{
rtx reg = gen_rtx_REG (word_mode, rn);
rtx x;
@@ -571,7 +571,7 @@ h8300_push_pop (int regno, int nregs, bool pop_p, bool
return_p)
if (pop_p)
pop (regno);
else
- push (regno, false);
+ push (regno);
return;
}
@@ -755,7 +755,7 @@ h8300_expand_prologue (void)
if (frame_pointer_needed)
{
/* Push fp. */
- push (HARD_FRAME_POINTER_REGNUM, true);
+ push (HARD_FRAME_POINTER_REGNUM);
F (emit_move_insn (hard_frame_pointer_rtx, stack_pointer_rtx), 0);
}
@@ -787,7 +787,7 @@ h8300_expand_prologue (void)
}
/* Leave room for locals. */
- h8300_emit_stack_adjustment (-1, round_frame_size (get_frame_size ()), true);
+ h8300_emit_stack_adjustment (-1, round_frame_size (get_frame_size ()));
if (flag_stack_usage_info)
current_function_static_stack_size
@@ -828,7 +828,7 @@ h8300_expand_epilogue (void)
returned_p = false;
/* Deallocate locals. */
- h8300_emit_stack_adjustment (1, frame_size, false);
+ h8300_emit_stack_adjustment (1, frame_size);
/* Pop the saved registers in descending order. */
saved_regs = compute_saved_regs ();
@@ -2707,10 +2707,14 @@ output_plussi (rtx *operands, bool need_flags)
if (!need_flags)
return "adds\t%2,%S0";
+ /* FALLTHRU */
+
case 0xfffc:
if (!need_flags)
return "subs\t%G2,%S0";
+ /* FALLTHRU */
+
case 0x0001:
case 0x0002:
if (!need_flags)
@@ -2719,6 +2723,8 @@ output_plussi (rtx *operands, bool need_flags)
return "inc.w\t%2,%e0";
}
+ /* FALLTHRU */
+
case 0x:
case 0xfffe:
if (!need_flags)
@@ -2726,6 +2732,9 @@ output_plussi (rtx *operands, bool need_flags)
operands[2] = GEN_INT (intval >> 16);
return "dec.w\t%G2,%e0";
}
+
+ /* FALLTHRU */
+
}
/* See if we can finish with 4 bytes. */
@@ -2792,10 +2801,15 @@ compute_plussi_length (rtx *operands, bool need_flags)
if (!need_flags)
return 2;
+ /* FALLTHRU */
+
case 0x:
case 0xfffe:
if (!need_flags)
return 2;
+
+ /* FALLTHRU */
+
}
/* See if we can finish with 4 bytes. */
@@ -3999,6 +4013,7 @@ h8300_shift_needs_scratch_p (int count, machine_mode
mode, enum rtx_code type)
else if (type == ASHIFTRT)
return (ar == SHIFT_LOOP
|| (TARGET_H8300H && mode == SImode && count == 8));
+ gcc_unreachable ();
}
/* Output the assembler code for doing shifts. */
Re: [PATCH] correct VLA bound traversal (PR 100719)
On 5/26/2021 1:29 PM, Martin Sebor via Gcc-patches wrote: The -Wvla-parameter checking of the bounds of VLA parameters in function redeclarations has a few bugs: a) it scans the string that encodes the attribute access representation of the VLA bounds from the end, failing to consider that the string may be followed by another for a subsequent VLA, b) it fails to consider that the chain of VLA bounds is stored in the reverse order of arguments, and c) it tests the result of TREE_CHAIN rather than TREE_PURPOSE to determine if a VLA bound has been specified. This can cause false negatives. The attached change fixes these three problems. It was tested on x86_64-linux. Martin gcc-100719.diff PR c/100719 - missing -Wvla-parameter on a mismatch in second parameter gcc/ChangeLog: * attribs.c (init_attr_rdwr_indices): Use VLA bounds in the expected order. (attr_access::vla_bounds): Also handle VLA bounds. gcc/c-family/ChangeLog: * c-warn.c (warn_parm_array_mismatch): Check TREE_PURPOSE to test for element presence. gcc/testsuite/ChangeLog: * gcc.dg/Wvla-parameter-10.c: New test. * gcc.dg/Wvla-parameter-11.c: New test. OK jeff
Re: [PATCH] avoid -Wnonnull with lambda (PR 100684)
On 5/24/2021 4:12 AM, Martin Liška wrote: On 5/20/21 10:03 AM, Richard Biener wrote: Martin - was this intended? Can you fix it up please? (g:cb50701ec2c7) It was not intentional. Fixed in the attached patch (where I did a refactoring as well). Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin 0001-LTO-stream-properly-FUNCTION_DECL_DECL_TYPE.patch From fa91b695b595d2fa1a6245eafe26a83b7aeb0787 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Mon, 24 May 2021 11:18:21 +0200 Subject: [PATCH] LTO: stream properly FUNCTION_DECL_DECL_TYPE. gcc/lto/ChangeLog: * lto-common.c (compare_tree_sccs_1): Compare FUNCTION_DECL_DECL_TYPE. gcc/ChangeLog: * tree-streamer-in.c (unpack_ts_function_decl_value_fields): Unpack FUNCTION_DECL_DECL_TYPE. * tree-streamer-out.c (pack_ts_function_decl_value_fields): Stream FUNCTION_DECL_DECL_TYPE instead of DECL_IS_OPERATOR_NEW_P. * tree.h (set_function_decl_type): Use FUNCTION_DECL_DECL_TYPE macro. (DECL_IS_OPERATOR_NEW_P): Likewise. (DECL_IS_OPERATOR_DELETE_P): Likewise. (DECL_LAMBDA_FUNCTION_P): Likewise. OK jeff
Re: [PATCH 2/2] testsuite: Fix Wattributes test cases for s390 and add new test
On 5/3/2021 9:20 AM, Robin Dapp via Gcc-patches wrote: Following up, this patch removes the s390-specific check for the warning and adds a new test. Is it OK after the common-code changes are in? Regards Robin -- gcc/testsuite/ChangeLog: * c-c++-common/Wattributes.c: Remove s390-specific case and new test. * gcc.dg/Wattributes-6.c: Dito. OK Jeff
Re: [PATCH v2] MIPS: R6: load/store can process unaligned address
On 5/8/2021 4:12 AM, YunQiang Su wrote: MIPS release 6 requires the lw/ld/sw/sd can work with unaligned address, while it can be implemented by full hardware or trap&emulate. Since it is may be fully done by hardware, we add an option -m(no-)unaligned-access, the kernel may need it. gcc/ChangeLog: * config/mips/mips.h (ISA_HAS_UNALIGNED_ACCESS): (STRICT_ALIGNMENT): R6 can unaligned access. * config/mips/mips.md (movmisalign): Likewise. * config/mips/mips.opt: add -m(no-)unaligned-access * doc/invoke.texi: Likewise. gcc/testsuite/ChangeLog: * gcc.target/mips/mips.exp: add unaligned-access * gcc.target/mips/unaligned-2.c: New test. * gcc.target/mips/unaligned-3.c: New test. OK. Note that someone else will need to handle review of MIPS specific patches going forward. jeff
Re: [PATCH] diagnostics: Fix sporadic test failure
On 5/28/2021 6:38 AM, Bernd Edlinger wrote: Hi, it turns out to be reproducible this way: COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*" Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp ... FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c -fplugin=./diagnostic_plugin_test_tree_expression_range.so 1 blank line(s) in output FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c -fplugin=./diagnostic_plugin_test_tree_expression_range.so expected multiline pattern lines 550-551 not found: "__builtin_types_compatible_p \(long, int\) \+ f \(i\)\);.*\n ~\^~~\n" FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c -fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for excess errors) a lot more errors happen with COLUMNS=20. Tested on x86_64-pc-linux-gnu. Is it OK for trunk? Thanks Bernd. 2021-05-28 Bernd Edlinger * gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix caret_max_with. * gcc.dg/plugin/diagnostic_plugin_test_inlining.c (plugin_init): Likewise. * gcc.dg/plugin/diagnostic_plugin_test_paths.c (plugin_init): Likewise. * gcc.dg/plugin/diagnostic_plugin_test_string_literals.c (plugin_init): Likewise. * gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c (plugin_init): Likewise. So while you've got a patch here, you haven't indicated what the problem actually was. I'm guessing caret_max_width was uninitialized and thus we got random-ish values. Presumably those randomish-values are what caused tests to occasionally appear to truncate their output and fail? If that's the case, this is fine. If it's something deeper, please provide a bit of background to help in evaluating the patch. Thanks, jeff
Re: [PATCH] diagnostics: Fix sporadic test failure
On 5/29/21 9:31 PM, Jeff Law wrote:
>
>
> On 5/28/2021 6:38 AM, Bernd Edlinger wrote:
>> Hi,
>>
>> it turns out to be reproducible this way:
>>
>> COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*"
>>
>> Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
>> -fplugin=./diagnostic_plugin_test_tree_expression_range.so 1 blank
>> line(s) in output
>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
>> -fplugin=./diagnostic_plugin_test_tree_expression_range.so expected
>> multiline pattern lines 550-551 not found: "
>> __builtin_types_compatible_p \(long, int\) \+ f \(i\)\);.*\n
>> ~\^~~\n"
>> FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
>> -fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for
>> excess errors)
>>
>> a lot more errors happen with COLUMNS=20.
>>
>> Tested on x86_64-pc-linux-gnu.
>> Is it OK for trunk?
>>
>>
>> Thanks
>> Bernd.
>>
>>
>> 2021-05-28 Bernd Edlinger
>>
>> * gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix
>> caret_max_with.
>> * gcc.dg/plugin/diagnostic_plugin_test_inlining.c
>> (plugin_init): Likewise.
>> * gcc.dg/plugin/diagnostic_plugin_test_paths.c (plugin_init): Likewise.
>> * gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
>> (plugin_init): Likewise.
>> * gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c
>> (plugin_init): Likewise.
> So while you've got a patch here, you haven't indicated what the problem
> actually was. I'm guessing caret_max_width was uninitialized and thus we got
> random-ish values. Presumably those randomish-values are what caused tests
> to occasionally appear to truncate their output and fail?
>
> If that's the case, this is fine. If it's something deeper, please provide a
> bit of background to help in evaluating the patch.
>
Yes, the problem is just the function get_terminal_width in diagnostic.c, can
somehow learn the X-terminal's window dimensions where the make check is
started:
int
get_terminal_width (void)
{
const char * s = getenv ("COLUMNS");
if (s != NULL) {
int n = atoi (s);
if (n > 0)
return n;
}
#ifdef TIOCGWINSZ
struct winsize w;
w.ws_col = 0;
if (ioctl (0, TIOCGWINSZ, &w) == 0 && w.ws_col > 0)
return w.ws_col;
#endif
return INT_MAX;
}
and this is used to initialize context->caret_max_width in
diagnostic_set_caret_max_width,
and possibly also other places. This causes a small variation in the output that
is trips the test cases. It is just an extra newline in some cases, that I
have not
debugged why exactly this happens, but I assume this is intentional to make the
diagnostics spanning multiple lines better readable to a human.
Thanks,
Bernd.
> Thanks,
> jeff
>
Re: [PATCH] diagnostics: Fix sporadic test failure
On 5/29/2021 1:55 PM, Bernd Edlinger wrote:
On 5/29/21 9:31 PM, Jeff Law wrote:
On 5/28/2021 6:38 AM, Bernd Edlinger wrote:
Hi,
it turns out to be reproducible this way:
COLUMNS=80 make check-gcc-c RUNTESTFLAGS="plugin.exp=diagnostic*"
Running /home/ed/gnu/gcc-trunk/gcc/testsuite/gcc.dg/plugin/plugin.exp ...
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
-fplugin=./diagnostic_plugin_test_tree_expression_range.so 1 blank line(s)
in output
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
-fplugin=./diagnostic_plugin_test_tree_expression_range.so expected multiline pattern
lines 550-551 not found: " __builtin_types_compatible_p
\(long, int\) \+ f \(i\)\);.*\n
~\^~~\n"
FAIL: gcc.dg/plugin/diagnostic-test-expressions-1.c
-fplugin=./diagnostic_plugin_test_tree_expression_range.so (test for excess
errors)
a lot more errors happen with COLUMNS=20.
Tested on x86_64-pc-linux-gnu.
Is it OK for trunk?
Thanks
Bernd.
2021-05-28 Bernd Edlinger
* gcc.dg/plugin/diagnostic_plugin_show_trees.c (plugin_init): Fix
caret_max_with.
* gcc.dg/plugin/diagnostic_plugin_test_inlining.c
(plugin_init): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_paths.c (plugin_init): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_string_literals.c
(plugin_init): Likewise.
* gcc.dg/plugin/diagnostic_plugin_test_tree_expression_range.c
(plugin_init): Likewise.
So while you've got a patch here, you haven't indicated what the problem
actually was. I'm guessing caret_max_width was uninitialized and thus we got
random-ish values. Presumably those randomish-values are what caused tests to
occasionally appear to truncate their output and fail?
If that's the case, this is fine. If it's something deeper, please provide a
bit of background to help in evaluating the patch.
Yes, the problem is just the function get_terminal_width in diagnostic.c, can
somehow learn the X-terminal's window dimensions where the make check is
started:
int
get_terminal_width (void)
{
const char * s = getenv ("COLUMNS");
if (s != NULL) {
int n = atoi (s);
if (n > 0)
return n;
}
#ifdef TIOCGWINSZ
struct winsize w;
w.ws_col = 0;
if (ioctl (0, TIOCGWINSZ, &w) == 0 && w.ws_col > 0)
return w.ws_col;
#endif
return INT_MAX;
}
and this is used to initialize context->caret_max_width in
diagnostic_set_caret_max_width,
and possibly also other places. This causes a small variation in the output that
is trips the test cases. It is just an extra newline in some cases, that I
have not
debugged why exactly this happens, but I assume this is intentional to make the
diagnostics spanning multiple lines better readable to a human.
Thanks. So for the testsuite we certainly don't want to be doing that
:-) OK for the trunk, thanks for chasing it down -- I've been seeing
these failures, but haven't had the time to chase down a root cause.
Jeff
[committed] wwwdocs: mirrors.html: Move gwdg.de from ftp to https
I commit this change which moves from ftp to https. Eberhard, is there maybe a different/better URL to use, that does not feature "ftp" in the hostname? Gerald --- htdocs/mirrors.html | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/htdocs/mirrors.html b/htdocs/mirrors.html index 3e121e87..34da075a 100644 --- a/htdocs/mirrors.html +++ b/htdocs/mirrors.html @@ -21,7 +21,7 @@ mirrors. The following sites mirror the gcc.gnu.org download site France, Brittany: ftp://ftp.irisa.fr/pub/mirrors/gcc.gnu.org/gcc/";>ftp.irisa.fr, thanks to ftpma...@irisa.fr France, Versailles: ftp://ftp.uvsq.fr/pub/gcc/";>ftp.uvsq.fr, thanks to ftpma...@uvsq.fr Germany, Berlin: ftp://ftp.fu-berlin.de/unix/languages/gcc/";>ftp.fu-berlin.de, thanks to f...@fu-berlin.de -Germany: ftp://ftp.gwdg.de/pub/misc/gcc/";>ftp.gwdg.de, thanks to emoe...@gwdg.de +Germany: https://ftp.gwdg.de/pub/misc/gcc/";>ftp.gwdg.de, thanks to emoe...@gwdg.de Germany: https://ftp.mpi-inf.mpg.de/mirrors/gnu/mirror/gcc.gnu.org/pub/gcc/";>mpi-sb.mpg.de, thanks to ftpad...@mpi-sb.mpg.de Germany: http://gcc.cybermirror.org";>http://gcc.cybermirror.org, thanks to Sascha Schwarz (c...@cybermirror.org) Greece: http://ftp.ntua.gr/mirror/gnu/gcc/";>ntua.gr, thanks to ftp...@ntua.gr -- 2.31.1
Re: [PATCH] PR testsuite/100749 - gcc.dg/pch/valid-1.c fails after r12-949
On 5/29/2021 12:02 AM, Indu Bhagat via Gcc-patches wrote: Hi, This patch fixes the failing pch testcases as observed in PR testsuite/100749. Although the PR mentions powerpc64, the issue exists on other arches but appears to be latent. The issue causing the failure was that the underlying char[] df_set_names is a static var. Multiple calls to 'debug_set_names' with different write_symbols like the in c-family/c-pch.c must entail the use of xstrdup or such to retain a reliable copy of the debug format str containing the names. Bootstrapped, regression tested on x86_64, powepc64 (make check-gcc). Thanks, Indu PR testsuite/100749 - gcc.dg/pch/valid-1.c fails after r12-949 Fix failing pch testcases. Use xstrdup to retain a reliable copy of the debug format str containing the names (df_set_names is a static string var). 2021-05-28 Indu Bhagat gcc/c-family/ChangeLog: * c-pch.c (c_common_valid_pch): Use xstrdup for debug format set names. OK for the trunk. Thanks, Jeff
Re: [PATCH 0/11] warning control by group and location (PR 74765)
On 5/24/2021 4:02 PM, Martin Sebor via Gcc-patches wrote:
Having just one bit control whether an expression or statement should
be allowed to trigger warnings has been a source of bug reports about
false negatives for years. PR 74765 has a representative test case
that shows how by setting the bit to avoid -Wparentheses the C++ front
end also ends up preventing valid -Wuninitialized in the middle end,
but there are other such reports for C (e.g., PR 74762) as well as
the middle end.
This patch series solves the problem by associating an expression
(whether a tree node or a GIMPLE statement) with more than one such
bit through its location. Each new bit in the mapping corresponds
to a group of warnings (e.g., lexical, access, etc.), and each
location may be associated with a simple bitmap with one bit for
each group. The initial groups are mostly ad hoc and should be
refined over time. The rare expressions that have no location
continue to have just one bit[1].
The first patch introduces three new APIs without making use of them
in existing code:
bool get_no_warning (..., int option);
void set_no_warning (..., int option, ...);
void copy_no_warning (...);
Subsequent patches then replace invocations of the TREE_NO_WARNING()
macro and the gimple_no_warning_p() and gimple_set_no_warning()
functions throughout GCC with those and remove the legacy APIs to
keep them from being accidentally reintroduced along with the problem.
These are mostly mechanical changes, except that most of the new
invocations also specify the option whose disposition to query for
the expression or location, or which to enable or disable[2].
The last function, copy_no_warning(), copies the disposition from
one expression or location to another.
A couple of design choices might be helpful to explain:
First, introducing "warning groups" rather than controlling each
individual warning is motivated by a) the fact that the latter
would make avoiding redundant warnings for related problems
cumbersome (e.g., after issuing a -Warray-bounds we want to
suppress -Wstringop-overflow as well -Wstringop-overread for
the same access and vice versa), and b) simplicity and efficiency
of the implementation (mapping each option would require a more
complex data structure like a bitmap).
Second, using location_t to associate expressions/statements with
the warning groups also turns out to be more useful in practice
than a direct association between a tree or gimple*, and also
simplifies managing the data structure. Trees and gimple* come
and go across passes, and maintaining a mapping for them that
accounts for the possibility of them being garbage-collected
and the same addresses reused is less than straightforward.
Martin
[1] My expectation is to work toward providing locations for all
expressions/statements, even if it's the opening or closing brace
of the function they're used in.)
[2] A number of {get,set}_no_warning() calls introduced by the patch
don't provide an option argument and query or set just the one bit in
the expression/statement. Some of these may be correct as they are,
but others could be refined to also specify an option. I can do that
in a follow-up patch if someone helps me find the right option.
So definitely on board with the broad approach here. I think it's
largely compatible with what Jakub suggested a year or two ago in this
space as well.
I think you've got some API/naming suggestions, so let's get that
settled and the bits reposted.
Thanks,
jeff
