Re: [PATCH] Fix PR 100944 - Array boundary misscalculation
On Sun, Jun 13, 2021 at 7:00 PM Giuliano Belinassi via Gcc-patches
wrote:
>
> This patch proposes a fix to PR 100944 by improving the array boundary
> computation when the flexible array has no clear constructor: if no
> constructor were found in the input code, we compute the size of the
> array as:
>
> offset(array begin) - offset(next element in RECORD_TYPE)
>
> If no next element is found in the RECORD, simply fall back to:
>
> offset(array begin) - offset(RECORD_TYPE ends)
>
> We avoid doing this calculation if the RECORD_TYPE is actually an
> UNION_TYPE, once things get very complicated in this case.
I'm looking at Wzero-length-array-bounds.c and wonder why the patch
makes a difference here.
struct X { int a[0]; int b, c; };
a is clearly not a flex-array?
The code in component_ref_size is truly weird. IMHO using
get_ref_base_and_unit_offset for computing the size of a flexarray
member is the wrong utility - instead a much better choice
(also for consistency) would be array_at_struct_end_p itself,
for example by giving it an optional HOST_WIDE_INT *size
argument.
Richard.
> gcc/ChangeLog:
> 2021-13-08 Giuliano Belinassi
>
> PR middle-end/100944
> * tree-dfa.c (get_ref_base_and_unit_offset): Add option to compute
> size
> of next field.
> * (get_ref_base_and_unit_offset_1): Same as above.
> * tree-dfa.h (get_ref_base_and_unit_offset): Same as above.
> (get_ref_base_and_unit_offset_1): Same as above.
> * tree.c (least_common_record_1): New.
> (least_common_record): New.
> (component_ref_size): Improve array size calculation.
>
> gcc/testsuite/ChangeLog:
> 2021-13-08 Giuliano Belinassi
>
> PR middle-end/100944
> * gcc.dg/Wzero-length-array-bounds.c: Update diagnostic.
> * gcc.dg/Warray-bounds-71.c: New test.
> ---
> gcc/testsuite/gcc.dg/Warray-bounds-71.c | 42 +++
> .../gcc.dg/Wzero-length-array-bounds.c| 18 +--
> gcc/tree-dfa.c| 31 -
> gcc/tree-dfa.h| 6 +-
> gcc/tree.c| 115 ++
> 5 files changed, 172 insertions(+), 40 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/Warray-bounds-71.c
>
> diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-71.c
> b/gcc/testsuite/gcc.dg/Warray-bounds-71.c
> new file mode 100644
> index 000..cc5b083bc77
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/Warray-bounds-71.c
> @@ -0,0 +1,42 @@
> +/* PR middle-end/100944 - missing -Warray-bounds accessing a flexible array
> + member of a nested struct
> + { dg-do compile }
> + { dg-options "-O2 -Wall" } */
> +
> +struct A0
> +{
> + int i, a[0];
> +};
> +
> +struct B0
> +{
> + struct A0 a;
> + long x;
> +} b0;
> +
> +void f0 (int i)
> +{
> + long t = b0.x;
> + b0.a.a[i] = 0;// { dg-warning "\\\[-Warray-bounds" }
> + if (t != b0.x)// folded to false
> +__builtin_abort ();
> +}
> +
> +struct Ax
> +{
> + int i, a[];
> +};
> +
> +struct Bx
> +{
> + struct Ax a;
> + long x;
> +} bx;
> +
> +void fx (int i)
> +{
> + long t = bx.x;
> + bx.a.a[i] = 0;// { dg-warning "\\\[-Warray-bounds" }
> + if (t != bx.x)// folded to false
> +__builtin_abort ();
> +}
> diff --git a/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
> b/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
> index 8e880d92dea..117b30ff294 100644
> --- a/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
> +++ b/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
> @@ -68,21 +68,21 @@ extern struct Y y;
>
> void access_to_member (int i)
> {
> - y.a[0].a[0] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> - y.a[0].a[1] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> - y.a[0].a[2] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> + y.a[0].a[0] = 0; // { dg-warning "\\\[-Warray-bounds" }
> + y.a[0].a[1] = 0; // { dg-warning "\\\[-Warray-bounds" }
> + y.a[0].a[2] = 0; // { dg-warning "\\\[-Warray-bounds" }
>sink (a);
>
> - y.a[1].a[0] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> - y.a[1].a[1] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> + y.a[1].a[0] = 0; // { dg-warning "\\\[-Warray-bounds" }
> + y.a[1].a[1] = 0; // { dg-warning "\\\[-Warray-bounds" }
>/* Similar to the array case above, accesses to a subsequent member
> of the "parent" struct seem like a more severe problem than those
> to the next member of the same struct. */
> - y.a[1].a[2] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> + y.a[1].a[2] = 0; // { dg-warning "\\\[-Warray-bounds" }
>sink (a);
>
> - y.b.a[0] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> - y.b.a[1] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> - y.b.a[2] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
> + y.b.a[0] = 0; // { dg-warning "\\\[-Warray-bounds" }
> + y.b.a[1] =
Re: [PATCH] teach compute_objsize about placement new (PR 100876)
On 14 June 2021 07:56:38 CEST, Bernhard Reutner-Fischer
wrote:
>On 14 June 2021 01:45:36 CEST, Jeff Law via Gcc-patches
> wrote:
>>
>>
>>On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote:
>>> The two forms of placement operator new defined in return
>their
>>> pointer argument and may not be displaced by user-defined functions.
>>> But because they are ordinary (not built-in) functions this property
>>> isn't reflected in their declarations alone, and there's no user-
>>> level attribute to annotate them with. When they are inlined
>>> the property is transparent in the IL but when they are not (without
>>> inlining such as -O0), calls to the operators appear in the IL and
>>> cause -Wmismatched-new-delete to try to match them with the
>functions
>>> called to deallocate memory. When the pointer to the memory was
>>> obtained from a function that matches the deallocator but not
>>> the placement new, the warning falsely triggers.
>>>
>>> The attached patch solves this by detecting calls to placement new
>>> and treating them the same as those to other pass-through calls
>(such
>>> as memset). In addition, it also teaches -Wfree-nonheap-object
>about
>>> placement delete, for a similar reason as above. Finally, it also
>>> adds a test for attribute fn spec indicating a function returns its
>>> argument. It's not necessary for the fix (I had initially though
>>> placement new might have the attribute) but it seems appropriate
>>> to check.
>>>
>>> Tested on x86_64-linux.
>>>
>>> Martin
>>>
>>> gcc-100876.diff
>>>
>>> PR c++/100876 - -Wmismatched-new-delete should understand placement
>>new when it's not inlined
>>>
>>> gcc/ChangeLog:
>>>
>>> PR c++/100876
>>> * builtins.c (gimple_call_return_array): Check for attribute fn
>>spec.
>>> Handle calls to placement new.
>>> (ndecl_dealloc_argno): Avoid placement delete.
>>>
>>> gcc/testsuite/ChangeLog:
>>>
>>> PR c++/100876
>>> * g++.dg/warn/Wmismatched-new-delete-4.C: New test.
>>> * g++.dg/warn/Wmismatched-new-delete-5.C: New test.
>>> * g++.dg/warn/Wstringop-overflow-7.C: New test.
>>> * g++.dg/warn/Wfree-nonheap-object-6.C: New test.
>>> * g++.dg/analyzer/placement-new.C: Prune out expected warning.
>>>
>>> diff --git a/gcc/builtins.c b/gcc/builtins.c
>>> index af1fe49bb48..fb0717a0248 100644
>>> --- a/gcc/builtins.c
>>> +++ b/gcc/builtins.c
>>> @@ -5159,11 +5159,43 @@ static tree
>>> gimple_call_return_array (gimple *stmt, offset_int offrng[2],
>>> range_query *rvals)
>>> {
>>> - if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)
>>> - || gimple_call_num_args (stmt) < 1)
Err, the if was removed, so right.
thanks,
>>> + {
>>> +/* Check for attribute fn spec to see if the function returns
>>one
>>> + of its arguments. */
>>> +attr_fnspec fnspec = gimple_call_fnspec (as_a (stmt));
>>> +unsigned int argno;
>>> +if (fnspec.returns_arg (&argno))
>>> + {
>>> + offrng[0] = offrng[1] = 0;
>>> + return gimple_call_arg (stmt, argno);
>>> + }
>>> + }
>>> +
>>> + if (gimple_call_num_args (stmt) < 1)
>>> return NULL_TREE;
>>Nit. You've got an unnecessary {} at the outer level of this hunk.
>
>if (unsigned int = 1 && fnspec.returns_arg (&argno))
>
>doesn't look too appealing though, I'd leave the curly braces, no?
>
>cheers,
>>
>>OK with the nit fixed.
>>
>>THanks,
>>Jeff
Re: [PATCH] teach compute_objsize about placement new (PR 100876)
On 14 June 2021 01:45:36 CEST, Jeff Law via Gcc-patches
wrote:
>
>
>On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote:
>> The two forms of placement operator new defined in return their
>> pointer argument and may not be displaced by user-defined functions.
>> But because they are ordinary (not built-in) functions this property
>> isn't reflected in their declarations alone, and there's no user-
>> level attribute to annotate them with. When they are inlined
>> the property is transparent in the IL but when they are not (without
>> inlining such as -O0), calls to the operators appear in the IL and
>> cause -Wmismatched-new-delete to try to match them with the functions
>> called to deallocate memory. When the pointer to the memory was
>> obtained from a function that matches the deallocator but not
>> the placement new, the warning falsely triggers.
>>
>> The attached patch solves this by detecting calls to placement new
>> and treating them the same as those to other pass-through calls (such
>> as memset). In addition, it also teaches -Wfree-nonheap-object about
>> placement delete, for a similar reason as above. Finally, it also
>> adds a test for attribute fn spec indicating a function returns its
>> argument. It's not necessary for the fix (I had initially though
>> placement new might have the attribute) but it seems appropriate
>> to check.
>>
>> Tested on x86_64-linux.
>>
>> Martin
>>
>> gcc-100876.diff
>>
>> PR c++/100876 - -Wmismatched-new-delete should understand placement
>new when it's not inlined
>>
>> gcc/ChangeLog:
>>
>> PR c++/100876
>> * builtins.c (gimple_call_return_array): Check for attribute fn
>spec.
>> Handle calls to placement new.
>> (ndecl_dealloc_argno): Avoid placement delete.
>>
>> gcc/testsuite/ChangeLog:
>>
>> PR c++/100876
>> * g++.dg/warn/Wmismatched-new-delete-4.C: New test.
>> * g++.dg/warn/Wmismatched-new-delete-5.C: New test.
>> * g++.dg/warn/Wstringop-overflow-7.C: New test.
>> * g++.dg/warn/Wfree-nonheap-object-6.C: New test.
>> * g++.dg/analyzer/placement-new.C: Prune out expected warning.
>>
>> diff --git a/gcc/builtins.c b/gcc/builtins.c
>> index af1fe49bb48..fb0717a0248 100644
>> --- a/gcc/builtins.c
>> +++ b/gcc/builtins.c
>> @@ -5159,11 +5159,43 @@ static tree
>> gimple_call_return_array (gimple *stmt, offset_int offrng[2],
>>range_query *rvals)
>> {
>> - if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)
>> - || gimple_call_num_args (stmt) < 1)
>> + {
>> +/* Check for attribute fn spec to see if the function returns
>one
>> + of its arguments. */
>> +attr_fnspec fnspec = gimple_call_fnspec (as_a (stmt));
>> +unsigned int argno;
>> +if (fnspec.returns_arg (&argno))
>> + {
>> +offrng[0] = offrng[1] = 0;
>> +return gimple_call_arg (stmt, argno);
>> + }
>> + }
>> +
>> + if (gimple_call_num_args (stmt) < 1)
>> return NULL_TREE;
>Nit. You've got an unnecessary {} at the outer level of this hunk.
if (unsigned int = 1 && fnspec.returns_arg (&argno))
doesn't look too appealing though, I'd leave the curly braces, no?
cheers,
>
>OK with the nit fixed.
>
>THanks,
>Jeff
Re: Ping: [PATCH 1/2] correct BB frequencies after loop changed
On 5/6/2021 8:36 PM, guojiufu via Gcc-patches wrote: Gentle ping. Original message: https://gcc.gnu.org/pipermail/gcc-patches/2020-October/555871.html I think you need a more aggressive ping :-) OK for the trunk. Sorry for the long delay. I kept hoping someone else would step in and look at it. jeff
Re: [PATCH] config: Backport "Rely less on internal symbols" (serial 68) to gettext.m4
On 5/23/2021 6:30 PM, Michael Forney wrote: GNU gettext introduced this change[0] in version 0.19.8 to fix gettext detection with musl libc, since it does not define these internal symbols. This allows gcc to build with musl gettext rather than falling back to the bundled version. [0] https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=b67399b4 2021-05-23 Michael Forney config/ChangeLog: * gettext.m4 (AM_GNU_GETTEXT): Skip checks for the internal symbols _nl_msg_cat_cntr, _nl_domain_bindings, and _nl_expand_alias, if __GNU_GETTEXT_SUPPORTED_REVISION is defined. Backport of gettext serial 68 patch. intl/ChangeLog: * configure: Regenerate. THanks. I've installed this on the trunk. Jeff
Re: [PATCH v2] Add a target calls hook: TARGET_PUSH_ARGUMENT
On 5/27/2021 2:18 PM, H.J. Lu via Gcc-patches wrote: 1. Replace PUSH_ARGS with a target calls hook, TARGET_PUSH_ARGUMENT, which takes an integer argument. When it returns true, push instructions will be used to pass outgoing arguments. If the argument is nonzero, it is the number of bytes to push and indicates the PUSH instruction usage is optional so that the backend can decide if PUSH instructions should be generated. Otherwise, the argument is zero. 2. Implement x86 target hook which returns false when the number of bytes to push is no less than 16 (8 for 32-bit targets) if vector load and store can be used. 3. Remove target PUSH_ARGS definitions which return 0 as it is the same as the default. 4. Define TARGET_PUSH_ARGUMENT of cr16 and m32c to always return true. gcc/ PR target/100704 * calls.c (expand_call): Replace PUSH_ARGS with targetm.calls.push_argument (0). (emit_library_call_value_1): Likewise. * defaults.h (PUSH_ARGS): Removed. (PUSH_ARGS_REVERSED): Replace PUSH_ARGS with targetm.calls.push_argument (0). * expr.c (block_move_libcall_safe_for_call_parm): Likewise. (emit_push_insn): Pass the number bytes to push to targetm.calls.push_argument and pass 0 if ARGS_ADDR is 0. * hooks.c (hook_bool_uint_true): New. * hooks.h (hook_bool_uint_true): Likewise. * rtlanal.c (nonzero_bits1): Replace PUSH_ARGS with targetm.calls.push_argument (0). * target.def (push_argument): Add a targetm.calls hook. * targhooks.c (default_push_argument): New. * targhooks.h (default_push_argument): Likewise. * config/bpf/bpf.h (PUSH_ARGS): Removed. * config/cr16/cr16.c (TARGET_PUSH_ARGUMENT): New. * config/cr16/cr16.h (PUSH_ARGS): Removed. * config/i386/i386.c (ix86_push_argument): (TARGET_PUSH_ARGUMENT): Likewise. * config/i386/i386.h (PUSH_ARGS): Removed. * config/m32c/m32c.c (TARGET_PUSH_ARGUMENT): New. * config/m32c/m32c.h (PUSH_ARGS): Removed. * config/nios2/nios2.h (PUSH_ARGS): Likewise. * config/pru/pru.h (PUSH_ARGS): Likewise. * doc/tm.texi.in: Remove PUSH_ARGS documentation. Add TARGET_PUSH_ARGUMENT hook. * doc/tm.texi: Regenerated. OK. jeff
[RFA] Minor improvement to compare elimination
I was reviewing the generated code in libgcc for the H8 to see if there
were any obvious redundant test/compares. Sure enough I found one in
the first file I looked at ;-)
So after IRA we have something like this:
(insn 43 112 44 4 (set (subreg:SI (reg:DI 40) 0)
(and:SI (subreg:SI (reg:DI 38) 0)
(subreg:SI (reg:DI 39) 0)))
"/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 246 {*logicalsi3}
(nil))
(insn 44 43 47 4 (set (subreg:SI (reg:DI 40) 4)
(and:SI (subreg:SI (reg:DI 38) 4)
(subreg:SI (reg:DI 39) 4)))
"/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 246 {*logicalsi3}
(expr_list:REG_DEAD (reg:DI 39)
(expr_list:REG_DEAD (reg:DI 38)
(nil
(jump_insn 47 44 83 4 (set (pc)
(if_then_else (ge (subreg:SI (reg:DI 40) 0)
(const_int 0 [0]))
(label_ref 55)
(pc))) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 281
{*branch}
(expr_list:REG_DEAD (reg:DI 40)
(int_list:REG_BR_PROB 1073204964 (nil)))
Which is just a DImode AND and a conditional branch based on the state
of the most significant bit. On the H8 we don't expose the condition
codes until split2. After splitting we have:
(insn 228 227 229 4 (parallel [
(set (reg:SI 0 r0)
(and:SI (reg:SI 0 r0)
(reg:SI 2 r2)))
(clobber (reg:CC 12 cc))
]) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 263 {*andsi3}
(nil))
(insn 229 228 230 4 (parallel [
(set (reg:SI 1 r1)
(mem/c:SI (plus:SI (reg/f:SI 7 sp)
(const_int 12 [0xc])) [1 %sfp+-12 S4 A32]))
(clobber (reg:CC 12 cc))
]) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 20
{*movsi_clobber_flags}
(nil))
(insn 230 229 231 4 (parallel [
(set (reg:SI 1 r1)
(and:SI (reg:SI 1 r1)
(reg:SI 3 r3 [orig:39+4 ] [39])))
(clobber (reg:CC 12 cc))
]) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 263 {*andsi3}
(nil))
(insn 231 230 232 4 (set (reg:CC 12 cc)
(compare:CC (reg:SI 0 r0)
(const_int 0 [0])))
"/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 131 {cmpsi}
(nil))
(jump_insn 232 231 83 4 (set (pc)
(if_then_else (ge (reg:CC 12 cc)
(const_int 0 [0]))
(label_ref 55)
(pc))) "/home/jlaw/test/gcc/libgcc/libgcc2.c":247:7 283
{*branch_1}
So far so good. An astute observer would probably note at this time
that insn 228 is a good candidate to eliminate the compare at insn 231,
except that insns 229 and 230 clobber the condition codes.
Things stay effectively like this through compare elimination which
fails to trigger because the condition codes are clobbered between insn
228 and insn 231.
*But* it turns out that insn 229 and insn 230 are both dead. They'll be
detected as such during peephole2, but that's too late to help compare
elimination (and in case you're wondering the DImode use in insn 47
keeps insn 44 from being deleted as dead before reload).
Naturally once peep2 has deleted the dead code it becomes obvious
there's a redundant test/compare.
The fix here is trivial -- just ask the DF machinery to do a fast DCE
from compare-elimination. That kills the two problematical insns and
then allows compare-elimination to detect that the compare is not
necessary. This shows up numerous times throughout libgcc and newlib.
Each time we're able to eliminate a compare like this we save 6 bytes of
instruction space and 3 cycles.
*** orig.s 2021-06-13 20:21:55.014435803 -0400
--- new.s 2021-06-13 20:21:34.329494744 -0400
*** ___absvdi2:
*** 43,50
not.l er2
mov.l @(8,er7),er0
and.l er2,er0
! cmp.l #0,er0
! bge .L2
sub.l er0,er0
mov.l er0,@(16,er7)
sub.l er1,er1
--- 43,49
not.l er2
mov.l @(8,er7),er0
and.l er2,er0
! bpl .L2
sub.l er0,er0
mov.l er0,@(16,er7)
sub.l er1,er1
I've bootstrapped and regression tested this on x86_64, though I doubt
it makes any difference there. BUt I'd bet it would help other targets
that don't expose double-word operations and have a condition code that
is clobbered by most instructions.
OK for the trunk?
Jeff
Minor improvement to compare elimination
gcc/
* compare-elim.c (try_eliminate_compare): Run DCE to clean things
before eliminating comparisons.
diff --git a/gcc/compare-elim.c b/gcc/compare-elim.c
index 85085cd6973..607eadc3d96 100644
--- a/gcc/compare-elim.c
+++ b/gcc/compare-elim.c
@@ -906,6 +906,7 @@ try_eliminate_compare (struct comparison *cmp)
static unsigned int
execute_compare_elim_after_reload (void)
{
+ df_set_flags (DF_LR_RUN_DCE);
df_analyze ();
gcc_checking_assert (!all_compares.exists ());
Re: [PATCH] teach compute_objsize about placement new (PR 100876)
On 6/2/2021 3:40 PM, Martin Sebor via Gcc-patches wrote:
The two forms of placement operator new defined in return their
pointer argument and may not be displaced by user-defined functions.
But because they are ordinary (not built-in) functions this property
isn't reflected in their declarations alone, and there's no user-
level attribute to annotate them with. When they are inlined
the property is transparent in the IL but when they are not (without
inlining such as -O0), calls to the operators appear in the IL and
cause -Wmismatched-new-delete to try to match them with the functions
called to deallocate memory. When the pointer to the memory was
obtained from a function that matches the deallocator but not
the placement new, the warning falsely triggers.
The attached patch solves this by detecting calls to placement new
and treating them the same as those to other pass-through calls (such
as memset). In addition, it also teaches -Wfree-nonheap-object about
placement delete, for a similar reason as above. Finally, it also
adds a test for attribute fn spec indicating a function returns its
argument. It's not necessary for the fix (I had initially though
placement new might have the attribute) but it seems appropriate
to check.
Tested on x86_64-linux.
Martin
gcc-100876.diff
PR c++/100876 - -Wmismatched-new-delete should understand placement new when
it's not inlined
gcc/ChangeLog:
PR c++/100876
* builtins.c (gimple_call_return_array): Check for attribute fn spec.
Handle calls to placement new.
(ndecl_dealloc_argno): Avoid placement delete.
gcc/testsuite/ChangeLog:
PR c++/100876
* g++.dg/warn/Wmismatched-new-delete-4.C: New test.
* g++.dg/warn/Wmismatched-new-delete-5.C: New test.
* g++.dg/warn/Wstringop-overflow-7.C: New test.
* g++.dg/warn/Wfree-nonheap-object-6.C: New test.
* g++.dg/analyzer/placement-new.C: Prune out expected warning.
diff --git a/gcc/builtins.c b/gcc/builtins.c
index af1fe49bb48..fb0717a0248 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -5159,11 +5159,43 @@ static tree
gimple_call_return_array (gimple *stmt, offset_int offrng[2],
range_query *rvals)
{
- if (!gimple_call_builtin_p (stmt, BUILT_IN_NORMAL)
- || gimple_call_num_args (stmt) < 1)
+ {
+/* Check for attribute fn spec to see if the function returns one
+ of its arguments. */
+attr_fnspec fnspec = gimple_call_fnspec (as_a (stmt));
+unsigned int argno;
+if (fnspec.returns_arg (&argno))
+ {
+ offrng[0] = offrng[1] = 0;
+ return gimple_call_arg (stmt, argno);
+ }
+ }
+
+ if (gimple_call_num_args (stmt) < 1)
return NULL_TREE;
Nit. You've got an unnecessary {} at the outer level of this hunk.
OK with the nit fixed.
THanks,
Jeff
Re: [r12-1405 Regression] FAIL: gcc.dg/c2x-attr-maybe_unused-1.c (test for warnings, line 31) on Linux/x86_64
Should be fixed now. On Sun, Jun 13, 2021, 5:36 PM Jeff Law wrote: > > > On 6/12/2021 3:41 PM, sunil.k.pandey via Gcc-patches wrote: > > On Linux/x86_64, > > > > c0f769fa3114ea852a26d93f0ee3f9595463de0b is the first bad commit > > commit c0f769fa3114ea852a26d93f0ee3f9595463de0b > > Author: Jason Merrill > > Date: Fri Jun 11 16:10:50 2021 -0400 > > > > c-family: don't warn for [[maybe_unused]] on data member > > > > caused > > > > FAIL: gcc.dg/c2x-attr-maybe_unused-1.c (test for warnings, line 23) > > FAIL: gcc.dg/c2x-attr-maybe_unused-1.c (test for warnings, line 31) > I've seen similar failures on some of the embedded targets as well. > > jeff > >
Re: [PATCH] PR libstdc++/98842: Fixed Constraints on operator<=>(optional, U)
Awesome, thanks! On Mon, Jun 7, 2021 at 11:30 AM Jonathan Wakely wrote: > On Fri, 4 Jun 2021 at 21:41, Jonathan Wakely wrote: > > > > On Thu, 3 Jun 2021 at 17:27, Seija K. via Libstdc++ < > libstd...@gcc.gnu.org> > > wrote: > > > > > The original operator was underconstrained. _Up needs to fulfill > > > compare_three_way_result, > > > as mentioned in this bug report > > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98842 > > > > > > > Thanks, I'll get the patch applied next week. > > The patch causes testsuite failures. > > I fixed it with the attached change instead, including a workaround > for an apparent C++20 defect. > > Pushed to trunk so far. >
Re: [PATCH] PR tree-optimization/96392 Optimize x+0.0 if x is an integer
On 6/11/2021 5:54 AM, Richard Biener via Gcc-patches wrote: On Thu, Jun 10, 2021 at 9:45 PM Roger Sayle wrote: The patch implements a missed optimization enhancement. Under usual IEEE rules, x+0.0 can't be simplified to x when x might potentially be an IEEE minus zero (-0.0). The current logic in the middle-end checks whether the type of x should honor signed zeros, but with this patch we introduce tree_expr_maybe_real_minus_zero_p that allows us to confirm that the value can't possibly be -0.0, for example, the result of a conversion from an integer type, or the result of fabs (or has a type that doesn't honor signed zero). Whilst modifying match.pd, I also converted some additional folding transformations from "testing the type" to "testing the value". The following patch has been tested on x86_64-pc-linux-gnu with a make bootstrap and make -k check with no new failures. Ok for mainline? OK. Maybe we can at some point record & propagate these FP value predicates on SSA names just similar to SSA_NAME_RANGE_INFO ... That's certainly been the hope. My vision was to have Ranger tackle tracking the special values in the FP space. But I think Aldy and Andrew are primarily focused on getting Ranger to the point where it subsumes [E]VRP at the moment. Jeff
Re: [r12-1405 Regression] FAIL: gcc.dg/c2x-attr-maybe_unused-1.c (test for warnings, line 31) on Linux/x86_64
On 6/12/2021 3:41 PM, sunil.k.pandey via Gcc-patches wrote: On Linux/x86_64, c0f769fa3114ea852a26d93f0ee3f9595463de0b is the first bad commit commit c0f769fa3114ea852a26d93f0ee3f9595463de0b Author: Jason Merrill Date: Fri Jun 11 16:10:50 2021 -0400 c-family: don't warn for [[maybe_unused]] on data member caused FAIL: gcc.dg/c2x-attr-maybe_unused-1.c (test for warnings, line 23) FAIL: gcc.dg/c2x-attr-maybe_unused-1.c (test for warnings, line 31) I've seen similar failures on some of the embedded targets as well. jeff
Re: [PATCH] arc: Add --with-fpu support for ARCv2 cpus
On 6/13/2021 4:06 AM, Bernhard Reutner-Fischer wrote: On Fri, 11 Jun 2021 14:25:24 +0300 Claudiu Zissulescu wrote: Hi Bernhard, Please find attached my latest patch, it includes (hopefully) all your feedback. Thank you for comments, concise and clean, i wouldn't know what to remove. LGTM. thanks for your patience! THen let's consider it approved at this point. Thanks for chiming in Bernhard and thanks for implementing the suggestions Claudiu! jeff
Re: [RFC/PATCH] updating global ranges and their effect on __builtin_unreachable code
On 6/13/2021 10:02 AM, Aldy Hernandez via Gcc-patches wrote: On Mon, Jun 7, 2021 at 4:32 PM Andrew MacLeod wrote: Aldy, I think this means we can use global information in the get_global query for ranger if "cfun->after_inlining" is true, otherwise do what we currently do. Tested on x86-64 Linux. OK for trunk? Aldy 0001-Pick-up-global-ranges-in-ranger-after-inlining.patch From 914810565183ad2cdac82ed5babd1f182346a728 Mon Sep 17 00:00:00 2001 From: Aldy Hernandez Date: Sun, 13 Jun 2021 16:20:33 +0200 Subject: [PATCH] Pick up global ranges in ranger after inlining. Ranger was not picking up global ranges because doing so could remove __builtin_unreachable calls too early to the detriment of LTO. However, we can safely remove these calls after inlining. This patch removes the restriction and allows ranger to pick up global ranges under these circumstances. Tested on x86-64 Linux. gcc/ChangeLog: * value-query.cc (gimple_range_global): Call get_range_global if called after inlining. OK jeff
[PATCH] i386: Improve variable permutation insn avoidance [PR101021]
Emit constant permutation insn directly from expand_vec_perm_shufb.
2021-06-13 Uroš Bizjak
gcc/
PR target/101021
* config/i386/i386-expand.c (expand_vec_perm_pshufb):
Emit constant permutation insn directly from here.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Pushed to master.
Uros.
diff --git a/gcc/config/i386/i386-expand.c b/gcc/config/i386/i386-expand.c
index 2fa3a18dc6a..6e33f6f8196 100644
--- a/gcc/config/i386/i386-expand.c
+++ b/gcc/config/i386/i386-expand.c
@@ -17593,13 +17593,16 @@ expand_vec_perm_pshufb (struct expand_vec_perm_d *d)
return false;
}
- /* Try to avoid variable permutation instruction. */
- if (canonicalize_vector_int_perm (d, &nd) && expand_vec_perm_1 (&nd))
-return false;
-
if (d->testing_p)
return true;
+ /* Try to avoid variable permutation instruction. */
+ if (canonicalize_vector_int_perm (d, &nd) && expand_vec_perm_1 (&nd))
+{
+ emit_move_insn (d->target, gen_lowpart (d->vmode, nd.target));
+ return true;
+}
+
if (vmode == V8SImode)
for (i = 0; i < 8; ++i)
rperm[i] = GEN_INT ((d->perm[i * nelt / 8] * 8 / nelt) & 7);
[Patch, fortran] PR fortran/100948 - [12 Regression] ICE in gfc_conv_expr_val, at fortran/trans-expr.c:9069
Hi all!
Proposed partial patch to:
Bug 100948 - [12 Regression] ICE in gfc_conv_expr_val, at
fortran/trans-expr.c:9069
Patch tested only on x86_64-pc-linux-gnu.
Reuse previously calculated full string length to set string section
default upper bound.
This patch only fixes the ICE the code produced is still wrong.
Thank you very much.
Best regards,
José Rui
Fortran: Fix ICE.
gcc/fortran/ChangeLog:
PR fortran/100948
* trans-expr.c (gfc_get_expr_charlen): reuse previously calculated
full string length to set string section default upper bound.
gcc/testsuite/ChangeLog:
PR fortran/100948
* gfortran.dg/PR100948.f90: New test.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index de406ad..1970cfc 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -2152,17 +2152,25 @@ gfc_get_expr_charlen (gfc_expr *e)
break;
case REF_SUBSTRING:
- gfc_init_se (&se, NULL);
- gfc_conv_expr_type (&se, r->u.ss.start, gfc_charlen_type_node);
- length = se.expr;
- gfc_conv_expr_type (&se, r->u.ss.end, gfc_charlen_type_node);
- length = fold_build2_loc (input_location, MINUS_EXPR,
-gfc_charlen_type_node,
-se.expr, length);
- length = fold_build2_loc (input_location, PLUS_EXPR,
-gfc_charlen_type_node, length,
-gfc_index_one_node);
- break;
+ {
+ tree start;
+
+ gfc_init_se (&se, NULL);
+ gcc_assert (r->u.ss.start);
+ gfc_conv_expr_type (&se, r->u.ss.start, gfc_charlen_type_node);
+ start = se.expr;
+ if (r->u.ss.end)
+ gfc_conv_expr_type (&se, r->u.ss.end, gfc_charlen_type_node);
+ else
+ se.expr = length;
+ length = fold_build2_loc (input_location, MINUS_EXPR,
+ gfc_charlen_type_node,
+ se.expr, start);
+ length = fold_build2_loc (input_location, PLUS_EXPR,
+ gfc_charlen_type_node, length,
+ gfc_index_one_node);
+ break;
+ }
default:
gcc_unreachable ();
diff --git a/gcc/testsuite/gfortran.dg/PR100948.f90 b/gcc/testsuite/gfortran.dg/PR100948.f90
new file mode 100644
index 000..c0e333f
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/PR100948.f90
@@ -0,0 +1,218 @@
+! { dg-do run }
+!
+! Tests fix for PR100948
+!
+! Based on contribution by JG. Steinmetz
+!
+
+program dct_p
+
+ implicit none
+
+ integer, parameter :: n = 2
+ integer, parameter :: m = 3
+
+ character(len=*), parameter :: u(*) = ["abc", "uvw"]
+
+ type :: dca_t
+character(:), allocatable :: c(:)
+ end type dca_t
+
+ type :: dcp_t
+character(:), pointer :: c(:)
+ end type dcp_t
+
+ character(len=m), target :: a(n)
+
+ a = u
+ if (size(a)/=n)stop 1
+ if (len(a)/=m) stop 2
+ if (any(a/=u)) stop 3
+ call dcs0(a)
+ if (size(a)/=n)stop 4
+ if (len(a)/=m) stop 5
+ if (any(a/=u)) stop 6
+ a = u
+ call dcs1(a)
+ if (size(a)/=n)stop 7
+ if (len(a)/=m) stop 8
+ if (any(a/=u)) stop 9
+ a = u
+ call dcs2(a)
+ if (size(a)/=n)stop 10
+ if (len(a)/=m) stop 11
+ if (any(a/=u)) stop 12
+ a = u
+ call dcs3(a)
+ if (size(a)/=n)stop 13
+ if (len(a)/=m) stop 14
+ if (any(a/=u)) stop 15
+ a = u
+ call dcs4(a)
+ if (size(a)/=n)stop 16
+ if (len(a)/=m) stop 17
+ if (any(a/=u)) stop 18
+ a = u
+ call dcs5(a)
+ if (size(a)/=n)stop 19
+ if (len(a)/=m) stop 20
+ if (any(a/=u)) stop 21
+ a = u
+ call dcs6(a)
+ if (size(a)/=n)stop 22
+ if (len(a)/=m) stop 23
+ if (any(a/=u)) stop 24
+ a = u
+ call dcs7(a)
+ if (size(a)/=n)stop 25
+ if (len(a)/=m) stop 26
+ if (any(a/=u)) stop 27
+ stop
+
+contains
+
+ subroutine dcs0(a)
+character(len=*), intent(in) :: a(:)
+
+if (size(a)/=n) stop 28
+if (len(a)/=m) stop 29
+if (any(a/=u)) stop 30
+associate (q => a(:)(:))
+ if (size(q)/=n)stop 31
+ if (len(q)/=m) stop 32
+ if (any(q/=u)) stop 33
+end associate
+return
+ end subroutine dcs0
+
+ subroutine dcs1(a)
+character(len=*), intent(in) :: a(:)
+
+character(len=len(a)) :: b(size(a))
+
+b = a(:)(:)
+if (size(b)/=n) stop 34
+if (len(b)/=m) stop 35
+if (any(b/=u)) stop 36
+associate (q => b(:)(:))
+ if (size(q)/=n)stop 37
+ if (len(q)/=m) stop 38
+ if (any(q/=u)) stop 39
+end associate
+return
+ end subroutine dcs1
+
+ subroutine dcs2(a)
+character(len=*), target, intent(in) :: a(:)
+
+character(:), pointer :: p(:)
+
+p => a
[PATCH] avr: Add atmega324pb MCU
Reference: https://www.microchip.com/wwwproducts/en/ATMEGA324PB
Signed-off-by: Matwey V. Kornilov
---
gcc/config/avr/avr-mcus.def | 1 +
gcc/doc/avr-mmcu.texi | 2 +-
2 files changed, 2 insertions(+), 1 deletion(-)
diff --git a/gcc/config/avr/avr-mcus.def b/gcc/config/avr/avr-mcus.def
index 37e4e9b317f..9b672e63548 100644
--- a/gcc/config/avr/avr-mcus.def
+++ b/gcc/config/avr/avr-mcus.def
@@ -207,6 +207,7 @@ AVR_MCU ("atmega323",ARCH_AVR5, AVR_ISA_NONE,
"__AVR_ATmega323__",
AVR_MCU ("atmega324a", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATmega324A__",
0x0100, 0x0, 0x8000, 0)
AVR_MCU ("atmega324p", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATmega324P__",
0x0100, 0x0, 0x8000, 0)
AVR_MCU ("atmega324pa", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATmega324PA__",
0x0100, 0x0, 0x8000, 0)
+AVR_MCU ("atmega324pb", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATmega324PB__",
0x0100, 0x0, 0x8000, 0)
AVR_MCU ("atmega325",ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATmega325__",
0x0100, 0x0, 0x8000, 0)
AVR_MCU ("atmega325a", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATmega325A__",
0x0100, 0x0, 0x8000, 0)
AVR_MCU ("atmega325p", ARCH_AVR5, AVR_ISA_NONE, "__AVR_ATmega325P__",
0x0100, 0x0, 0x8000, 0)
diff --git a/gcc/doc/avr-mmcu.texi b/gcc/doc/avr-mmcu.texi
index b02499859ae..da4a5b33659 100644
--- a/gcc/doc/avr-mmcu.texi
+++ b/gcc/doc/avr-mmcu.texi
@@ -38,7 +38,7 @@
@item avr5
``Enhanced'' devices with 16@tie{}KiB up to 64@tie{}KiB of program memory.
-@*@var{mcu}@tie{}= @code{atmega16}, @code{atmega16a}, @code{atmega16hva},
@code{atmega16hva2}, @code{atmega16hvb}, @code{atmega16hvbrevb},
@code{atmega16m1}, @code{atmega16u4}, @code{atmega161}, @code{atmega162},
@code{atmega163}, @code{atmega164a}, @code{atmega164p}, @code{atmega164pa},
@code{atmega165}, @code{atmega165a}, @code{atmega165p}, @code{atmega165pa},
@code{atmega168}, @code{atmega168a}, @code{atmega168p}, @code{atmega168pa},
@code{atmega168pb}, @code{atmega169}, @code{atmega169a}, @code{atmega169p},
@code{atmega169pa}, @code{atmega32}, @code{atmega32a}, @code{atmega32c1},
@code{atmega32hvb}, @code{atmega32hvbrevb}, @code{atmega32m1},
@code{atmega32u4}, @code{atmega32u6}, @code{atmega323}, @code{atmega324a},
@code{atmega324p}, @code{atmega324pa}, @code{atmega325}, @code{atmega325a},
@code{atmega325p}, @code{atmega325pa}, @code{atmega328}, @code{atmega328p},
@code{atmega328pb}, @code{atmega329}, @code{atmega329a}, @code{atmega329p},
@code{atmega329pa}, @code{atmega3250}, @code{atmega3250a}, @code{atmega3250p},
@code{atmega3250pa}, @code{atmega3290}, @code{atmega3290a}, @code{atmega3290p},
@code{atmega3290pa}, @code{atmega406}, @code{atmega64}, @code{atmega64a},
@code{atmega64c1}, @code{atmega64hve}, @code{atmega64hve2}, @code{atmega64m1},
@code{atmega64rfr2}, @code{atmega640}, @code{atmega644}, @code{atmega644a},
@code{atmega644p}, @code{atmega644pa}, @code{atmega644rfr2}, @code{atmega645},
@code{atmega645a}, @code{atmega645p}, @code{atmega649}, @code{atmega649a},
@code{atmega649p}, @code{atmega6450}, @code{atmega6450a}, @code{atmega6450p},
@code{atmega6490}, @code{atmega6490a}, @code{atmega6490p}, @code{ata5795},
@code{ata5790}, @code{ata5790n}, @code{ata5791}, @code{ata6613c},
@code{ata6614q}, @code{ata5782}, @code{ata5831}, @code{ata8210},
@code{ata8510}, @code{ata5702m322}, @code{at90pwm161}, @code{at90pwm216},
@code{at90pwm316}, @code{at90can32}, @code{at90can64}, @code{at90scr100},
@code{at90usb646}, @code{at90usb647}, @code{at94k}, @code{m3000}.
+@*@var{mcu}@tie{}= @code{atmega16}, @code{atmega16a}, @code{atmega16hva},
@code{atmega16hva2}, @code{atmega16hvb}, @code{atmega16hvbrevb},
@code{atmega16m1}, @code{atmega16u4}, @code{atmega161}, @code{atmega162},
@code{atmega163}, @code{atmega164a}, @code{atmega164p}, @code{atmega164pa},
@code{atmega165}, @code{atmega165a}, @code{atmega165p}, @code{atmega165pa},
@code{atmega168}, @code{atmega168a}, @code{atmega168p}, @code{atmega168pa},
@code{atmega168pb}, @code{atmega169}, @code{atmega169a}, @code{atmega169p},
@code{atmega169pa}, @code{atmega32}, @code{atmega32a}, @code{atmega32c1},
@code{atmega32hvb}, @code{atmega32hvbrevb}, @code{atmega32m1},
@code{atmega32u4}, @code{atmega32u6}, @code{atmega323}, @code{atmega324a},
@code{atmega324p}, @code{atmega324pa}, @code{atmega324pb}, @code{atmega325},
@code{atmega325a}, @code{atmega325p}, @code{atmega325pa}, @code{atmega328},
@code{atmega328p}, @code{atmega328pb}, @code{atmega329}, @code{atmega329a},
@code{atmega329p}, @code{atmega329pa}, @code{atmega3250}, @code{atmega3250a},
@code{atmega3250p}, @code{atmega3250pa}, @code{atmega3290}, @code{atmega3290a},
@code{atmega3290p}, @code{atmega3290pa}, @code{atmega406}, @code{atmega64},
@code{atmega64a}, @code{atmega64c1}, @code{atmega64hve}, @code{atmega64hve2},
@code{atmega64m1}, @code{atmega64rfr2}, @code{atmega640}, @code{atmega644},
@code{atmega644a}, @code{atmega644p}, @code{atmega644pa}, @code{atmega644rfr2},
@code{at
Re: [committed] wwwdocs: readings: Remove PRU-ICSS documentation reference
On Mon, May 31, 2021 at 12:20:21AM +0200, Gerald Pfeifer wrote: > TI's server has been telling us that "The PRU-ICSS wiki is in the > process of being migrated to software-dl.ti.com" for five months. > Time to pull the plug. > --- > htdocs/readings.html | 1 - > 1 file changed, 1 deletion(-) > > diff --git a/htdocs/readings.html b/htdocs/readings.html > index c4c0618a..33ed5822 100644 > --- a/htdocs/readings.html > +++ b/htdocs/readings.html > @@ -256,7 +256,6 @@ names. > > pru > Manufacturer: Texas Instruments > -href="https://processors.wiki.ti.com/index.php/PRU-ICSS";>Official PRU > Documentation > https://elinux.org/Category:PRU";>Community PRU > Documentation > > Hi, Could you please consider the following replacement? https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571766.html Regards, Dimitar
Re: [PATCH] c++: Don't complain about [[maybe_unused]] on non-static data members
On Fri, Jun 11, 2021 at 5:44 PM Jakub Jelinek wrote:
> On Fri, Jun 11, 2021 at 10:35:58PM +0200, Jakub Jelinek wrote:
> > > But I also agree that GCC shouldn't warn here.
> >
> > We could do that by using a wrapper around handle_unused_attribute
> > for the maybe_unused attribute, that way warn on unused attribute on
> > FIELD_DECLs, but not for maybe_unused (until we actually implement some
> > warning that uses it).
>
> Here it is in patch form.
> Ok for trunk if it passes bootstrap/regtest?
>
In r12-1405 I changed both warnings to be accepted on FIELD_DECL. I don't
think we need to warn about the GNU attribute, either; an attribute meaning
"don't warn about this being unused" is vacuously satisfied if we don't
warn about any unused fields, we might as well do the normal thing.
> 2021-06-11 Jakub Jelinek
>
> * tree.c (handle_maybe_unused_attribute): New function.
> (std_attribute_table): Use it as handler for maybe_unused
> attribute.
>
> * g++.dg/cpp1z/maybe_unused2.C: New test.
>
> --- gcc/cp/tree.c.jj2021-05-28 11:03:19.490884332 +0200
> +++ gcc/cp/tree.c 2021-06-11 23:41:36.503413441 +0200
> @@ -4872,6 +4872,23 @@ handle_likeliness_attribute (tree *node,
> return error_mark_node;
> }
>
> +/* The C++17 [[maybe_unused]] attribute maps to GNU unused attribute,
> + except that we don't want -Wattributes to warn for [[maybe_unused]]
> + on non-static data members. */
> +
> +static tree
> +handle_maybe_unused_attribute (tree *node, tree name, tree args,
> + int flags, bool *no_add_attrs)
> +{
> + if (TREE_CODE (*node) == FIELD_DECL)
> +{
> + *no_add_attrs = true;
> + return NULL_TREE;
> +}
> + else
> +return handle_unused_attribute (node, name, args, flags,
> no_add_attrs);
> +}
> +
> /* Table of valid C++ attributes. */
> const struct attribute_spec cxx_attribute_table[] =
> {
> @@ -4890,7 +4907,7 @@ const struct attribute_spec std_attribut
>/* { name, min_len, max_len, decl_req, type_req, fn_type_req,
> affects_type_identity, handler, exclude } */
>{ "maybe_unused", 0, 0, false, false, false, false,
> -handle_unused_attribute, NULL },
> +handle_maybe_unused_attribute, NULL },
>{ "nodiscard", 0, 1, false, false, false, false,
> handle_nodiscard_attribute, NULL },
>{ "no_unique_address", 0, 0, true, false, false, false,
> --- gcc/testsuite/g++.dg/cpp1z/maybe_unused2.C.jj 2021-06-11
> 23:40:51.742027943 +0200
> +++ gcc/testsuite/g++.dg/cpp1z/maybe_unused2.C 2021-06-11
> 23:40:47.642084225 +0200
> @@ -0,0 +1,7 @@
> +// { dg-do compile { target c++11 } }
> +// { dg-options "-Wunused -Wextra" }
> +
> +struct [[maybe_unused]] A {
> + [[maybe_unused]] static int i;
> + [[maybe_unused]] int a;
> +};
>
>
> Jakub
>
>
[PATCH] Fix PR 100944 - Array boundary misscalculation
This patch proposes a fix to PR 100944 by improving the array boundary
computation when the flexible array has no clear constructor: if no
constructor were found in the input code, we compute the size of the
array as:
offset(array begin) - offset(next element in RECORD_TYPE)
If no next element is found in the RECORD, simply fall back to:
offset(array begin) - offset(RECORD_TYPE ends)
We avoid doing this calculation if the RECORD_TYPE is actually an
UNION_TYPE, once things get very complicated in this case.
gcc/ChangeLog:
2021-13-08 Giuliano Belinassi
PR middle-end/100944
* tree-dfa.c (get_ref_base_and_unit_offset): Add option to compute size
of next field.
* (get_ref_base_and_unit_offset_1): Same as above.
* tree-dfa.h (get_ref_base_and_unit_offset): Same as above.
(get_ref_base_and_unit_offset_1): Same as above.
* tree.c (least_common_record_1): New.
(least_common_record): New.
(component_ref_size): Improve array size calculation.
gcc/testsuite/ChangeLog:
2021-13-08 Giuliano Belinassi
PR middle-end/100944
* gcc.dg/Wzero-length-array-bounds.c: Update diagnostic.
* gcc.dg/Warray-bounds-71.c: New test.
---
gcc/testsuite/gcc.dg/Warray-bounds-71.c | 42 +++
.../gcc.dg/Wzero-length-array-bounds.c| 18 +--
gcc/tree-dfa.c| 31 -
gcc/tree-dfa.h| 6 +-
gcc/tree.c| 115 ++
5 files changed, 172 insertions(+), 40 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/Warray-bounds-71.c
diff --git a/gcc/testsuite/gcc.dg/Warray-bounds-71.c
b/gcc/testsuite/gcc.dg/Warray-bounds-71.c
new file mode 100644
index 000..cc5b083bc77
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/Warray-bounds-71.c
@@ -0,0 +1,42 @@
+/* PR middle-end/100944 - missing -Warray-bounds accessing a flexible array
+ member of a nested struct
+ { dg-do compile }
+ { dg-options "-O2 -Wall" } */
+
+struct A0
+{
+ int i, a[0];
+};
+
+struct B0
+{
+ struct A0 a;
+ long x;
+} b0;
+
+void f0 (int i)
+{
+ long t = b0.x;
+ b0.a.a[i] = 0;// { dg-warning "\\\[-Warray-bounds" }
+ if (t != b0.x)// folded to false
+__builtin_abort ();
+}
+
+struct Ax
+{
+ int i, a[];
+};
+
+struct Bx
+{
+ struct Ax a;
+ long x;
+} bx;
+
+void fx (int i)
+{
+ long t = bx.x;
+ bx.a.a[i] = 0;// { dg-warning "\\\[-Warray-bounds" }
+ if (t != bx.x)// folded to false
+__builtin_abort ();
+}
diff --git a/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
b/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
index 8e880d92dea..117b30ff294 100644
--- a/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
+++ b/gcc/testsuite/gcc.dg/Wzero-length-array-bounds.c
@@ -68,21 +68,21 @@ extern struct Y y;
void access_to_member (int i)
{
- y.a[0].a[0] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
- y.a[0].a[1] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
- y.a[0].a[2] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
+ y.a[0].a[0] = 0; // { dg-warning "\\\[-Warray-bounds" }
+ y.a[0].a[1] = 0; // { dg-warning "\\\[-Warray-bounds" }
+ y.a[0].a[2] = 0; // { dg-warning "\\\[-Warray-bounds" }
sink (a);
- y.a[1].a[0] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
- y.a[1].a[1] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
+ y.a[1].a[0] = 0; // { dg-warning "\\\[-Warray-bounds" }
+ y.a[1].a[1] = 0; // { dg-warning "\\\[-Warray-bounds" }
/* Similar to the array case above, accesses to a subsequent member
of the "parent" struct seem like a more severe problem than those
to the next member of the same struct. */
- y.a[1].a[2] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
+ y.a[1].a[2] = 0; // { dg-warning "\\\[-Warray-bounds" }
sink (a);
- y.b.a[0] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
- y.b.a[1] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
- y.b.a[2] = 0; // { dg-warning "\\\[-Wzero-length-bounds" }
+ y.b.a[0] = 0; // { dg-warning "\\\[-Warray-bounds" }
+ y.b.a[1] = 0; // { dg-warning "\\\[-Warray-bounds" }
+ y.b.a[2] = 0; // { dg-warning "\\\[-Warray-bounds" }
y.b.a[3] = 0; // { dg-warning "\\\[-Warray-bounds" }
}
diff --git a/gcc/tree-dfa.c b/gcc/tree-dfa.c
index 1d20de0c400..dc3c15f11d5 100644
--- a/gcc/tree-dfa.c
+++ b/gcc/tree-dfa.c
@@ -772,9 +772,11 @@ get_ref_base_and_extent_hwi (tree exp, HOST_WIDE_INT
*poffset,
tree
get_addr_base_and_unit_offset_1 (tree exp, poly_int64_pod *poffset,
-tree (*valueize) (tree))
+tree (*valueize) (tree),
+bool of_next_component /* = false. */)
{
poly_int64 byte_offset = 0;
+ tree next_field = NULL_TREE;
/* Compute cumulative byte-offset for nested component-refs and array-
[PATCH, pushed] use range based for loops to iterate over vec<>
This changes users of FOR_EACH_VEC_ELT to use range based for loops, where the index variables are otherwise unused. As such the index variables are all deleted, producing shorter and simpler code. bootstrapped and regtested on x86_64-linux-gnu. Pushed as pre approved by Richi, in each case the index variables should have been deleted as part of the change. Signed-off-by: Trevor Saunders gcc/analyzer/ChangeLog: * call-string.cc (call_string::call_string): Use range based for to iterate over vec<>. (call_string::to_json): Likewise. (call_string::hash): Likewise. (call_string::calc_recursion_depth): Likewise. * checker-path.cc (checker_path::fixup_locations): Likewise. * constraint-manager.cc (equiv_class::equiv_class): Likewise. (equiv_class::to_json): Likewise. (equiv_class::hash): Likewise. (constraint_manager::to_json): Likewise. * engine.cc (impl_region_model_context::on_svalue_leak): Likewise. (on_liveness_change): Likewise. (impl_region_model_context::on_unknown_change): Likewise. * program-state.cc (sm_state_map::set_state): Likewise. * region-model.cc (test_canonicalization_4): Likewise. gcc/ChangeLog: * attribs.c (find_attribute_namespace): Iterate over vec<> with range based for. * auto-profile.c (afdo_find_equiv_class): Likewise. * gcc.c (do_specs_vec): Likewise. (do_spec_1): Likewise. (driver::set_up_specs): Likewise. * gimple-loop-jam.c (any_access_function_variant_p): Likewise. * gimple-ssa-store-merging.c (compatible_load_p): Likewise. (imm_store_chain_info::try_coalesce_bswap): Likewise. (imm_store_chain_info::coalesce_immediate_stores): Likewise. (get_location_for_stmts): Likewise. * graphite-poly.c (print_iteration_domains): Likewise. (free_poly_bb): Likewise. (remove_gbbs_in_scop): Likewise. (free_scop): Likewise. (dump_gbb_cases): Likewise. (dump_gbb_conditions): Likewise. (print_pdrs): Likewise. (print_scop): Likewise. * ifcvt.c (cond_move_process_if_block): Likewise. * lower-subreg.c (decompose_multiword_subregs): Likewise. * regcprop.c (pass_cprop_hardreg::execute): Likewise. * sanopt.c (sanitize_rewrite_addressable_params): Likewise. * sel-sched-dump.c (dump_insn_vector): Likewise. * store-motion.c (store_ops_ok): Likewise. (store_killed_in_insn): Likewise. * timevar.c (timer::named_items::print): Likewise. * tree-cfgcleanup.c (cleanup_control_flow_pre): Likewise. (cleanup_tree_cfg_noloop): Likewise. * tree-data-ref.c (dump_data_references): Likewise. (print_dir_vectors): Likewise. (print_dist_vectors): Likewise. (dump_data_dependence_relations): Likewise. (dump_dist_dir_vectors): Likewise. (dump_ddrs): Likewise. (create_runtime_alias_checks): Likewise. (free_subscripts): Likewise. (save_dist_v): Likewise. (save_dir_v): Likewise. (invariant_access_functions): Likewise. (same_access_functions): Likewise. (access_functions_are_affine_or_constant_p): Likewise. (find_data_references_in_stmt): Likewise. (graphite_find_data_references_in_stmt): Likewise. (free_dependence_relations): Likewise. (free_data_refs): Likewise. * tree-inline.c (copy_debug_stmts): Likewise. * tree-into-ssa.c (dump_currdefs): Likewise. (rewrite_update_phi_arguments): Likewise. * tree-ssa-propagate.c (clean_up_loop_closed_phi): Likewise. * tree-vect-data-refs.c (vect_analyze_possibly_independent_ddr): Likewise. (vect_slp_analyze_node_dependences): Likewise. (vect_slp_analyze_instance_dependence): Likewise. (vect_record_base_alignments): Likewise. (vect_get_peeling_costs_all_drs): Likewise. (vect_peeling_supportable): Likewise. * tree-vectorizer.c (vec_info::~vec_info): Likewise. (vec_info::free_stmt_vec_infos): Likewise. gcc/cp/ChangeLog: * constexpr.c (cxx_eval_call_expression): Iterate over vec<> with range based for. (cxx_eval_store_expression): Likewise. (cxx_eval_loop_expr): Likewise. * decl.c (wrapup_namespace_globals): Likewise. (cp_finish_decl): Likewise. (cxx_simulate_enum_decl): Likewise. * parser.c (cp_parser_postfix_expression): Likewise. --- gcc/analyzer/call-string.cc| 16 ++--- gcc/analyzer/checker-path.cc | 4 +- gcc/analyzer/constraint-manager.cc | 22 ++ gcc/analyzer/engine.cc | 12 +--- gcc/analyzer/program-state.cc | 4 +- gcc/analyzer/region-model.cc | 4 +- gcc/attribs.c | 13 ++-- gcc/auto-profile.c | 6 +- gcc/cp/constexpr.c
Re: [RFC/PATCH] updating global ranges and their effect on __builtin_unreachable code
On Mon, Jun 7, 2021 at 4:32 PM Andrew MacLeod wrote:
> Aldy, I think this means we can use global information in the get_global
> query for ranger if "cfun->after_inlining" is true, otherwise do what we
> currently do.
Tested on x86-64 Linux.
OK for trunk?
Aldy
From 914810565183ad2cdac82ed5babd1f182346a728 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez
Date: Sun, 13 Jun 2021 16:20:33 +0200
Subject: [PATCH] Pick up global ranges in ranger after inlining.
Ranger was not picking up global ranges because doing so could remove
__builtin_unreachable calls too early to the detriment of LTO. However,
we can safely remove these calls after inlining. This patch removes the
restriction and allows ranger to pick up global ranges under these
circumstances.
Tested on x86-64 Linux.
gcc/ChangeLog:
* value-query.cc (gimple_range_global): Call get_range_global
if called after inlining.
---
gcc/value-query.cc | 20 +---
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/gcc/value-query.cc b/gcc/value-query.cc
index 9047e271b5b..93609f3c7c4 100644
--- a/gcc/value-query.cc
+++ b/gcc/value-query.cc
@@ -397,14 +397,20 @@ get_range_global (irange &r, tree name)
r.set_varying (type);
}
-// ?? Like above, but only for default definitions of NAME. This is
-// so VRP passes using ranger do not start with known ranges,
-// otherwise we'd eliminate builtin_unreachables too early because of
-// inlining.
+// This is where the ranger picks up global info to seed initial
+// requests. It is a slightly restricted version of
+// get_range_global() above.
+//
+// The reason for the difference is that we can always pick the
+// default definition of an SSA with no adverse effects, but for other
+// SSAs, if we pick things up to early, we may prematurely eliminate
+// builtin_unreachables.
//
// Without this restriction, the test in g++.dg/tree-ssa/pr61034.C has
-// all of its unreachable calls removed too early. We should
-// investigate whether we should just adjust the test above.
+// all of its unreachable calls removed too early.
+//
+// See discussion here:
+// https://gcc.gnu.org/pipermail/gcc-patches/2021-June/571709.html
value_range
gimple_range_global (tree name)
@@ -412,7 +418,7 @@ gimple_range_global (tree name)
gcc_checking_assert (gimple_range_ssa_p (name));
tree type = TREE_TYPE (name);
- if (SSA_NAME_IS_DEFAULT_DEF (name))
+ if (SSA_NAME_IS_DEFAULT_DEF (name) || (cfun && cfun->after_inlining))
{
value_range vr;
get_range_global (vr, name);
--
2.31.1
Re: [Patch, fortran] PR fortran/101047/101048 Pointer explicit initialization
On 13/06/21 15:46, José Rui Faustino de Sousa wrote:
Hi All!
Proposed patch to:
And again I forgot to add the patch...
Sorry for the inconvenience.
Best regards,
José Rui
diff --git a/gcc/fortran/class.c b/gcc/fortran/class.c
index 93118ad..5670d18 100644
--- a/gcc/fortran/class.c
+++ b/gcc/fortran/class.c
@@ -443,7 +443,7 @@ gfc_is_class_container_ref (gfc_expr *e)
component to the corresponding type (or the declared type, given by ts). */
gfc_expr *
-gfc_class_initializer (gfc_typespec *ts, gfc_expr *init_expr)
+gfc_class_initializer (gfc_typespec *ts, gfc_expr *init_expr, bool pointer)
{
gfc_expr *init;
gfc_component *comp;
@@ -464,7 +464,10 @@ gfc_class_initializer (gfc_typespec *ts, gfc_expr *init_expr)
if (strcmp (comp->name, "_vptr") == 0 && vtab)
ctor->expr = gfc_lval_expr_from_sym (vtab);
else if (init_expr && init_expr->expr_type != EXPR_NULL)
- ctor->expr = gfc_copy_expr (init_expr);
+ ctor->expr = gfc_copy_expr (init_expr);
+ else if (strcmp (comp->name, "_data") == 0 && pointer)
+ ctor->expr = (init_expr && init_expr->expr_type == EXPR_NULL)
+ ? (gfc_get_null_expr (NULL)) : (NULL);
else
ctor->expr = gfc_get_null_expr (NULL);
gfc_constructor_append (&init->value.constructor, ctor);
diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index 956003e..32b2849 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4433,15 +4433,19 @@ bool
gfc_check_assign_symbol (gfc_symbol *sym, gfc_component *comp, gfc_expr *rvalue)
{
gfc_expr lvalue;
+ gfc_array_spec *as;
bool r;
- bool pointer, proc_pointer;
+ bool is_class, pointer, proc_pointer;
memset (&lvalue, '\0', sizeof (gfc_expr));
+ is_class = (sym->ts.type == BT_CLASS) && CLASS_DATA (sym);
+ as = is_class ? (CLASS_DATA (sym)->as) : (sym->as);
+
lvalue.expr_type = EXPR_VARIABLE;
lvalue.ts = sym->ts;
- if (sym->as)
-lvalue.rank = sym->as->rank;
+ if (as)
+lvalue.rank = as->rank;
lvalue.symtree = XCNEW (gfc_symtree);
lvalue.symtree->n.sym = sym;
lvalue.where = sym->declared_at;
@@ -4461,7 +4465,7 @@ gfc_check_assign_symbol (gfc_symbol *sym, gfc_component *comp, gfc_expr *rvalue)
}
else
{
- pointer = sym->ts.type == BT_CLASS && CLASS_DATA (sym)
+ pointer = is_class
? CLASS_DATA (sym)->attr.class_pointer : sym->attr.pointer;
proc_pointer = sym->attr.proc_pointer;
}
@@ -4883,32 +4887,21 @@ get_union_initializer (gfc_symbol *union_type, gfc_component **map_p)
}
static bool
-class_allocatable (gfc_component *comp)
-{
- return comp->ts.type == BT_CLASS && CLASS_DATA (comp)
-&& CLASS_DATA (comp)->attr.allocatable;
-}
-
-static bool
-class_pointer (gfc_component *comp)
-{
- return comp->ts.type == BT_CLASS && CLASS_DATA (comp)
-&& CLASS_DATA (comp)->attr.pointer;
-}
-
-static bool
comp_allocatable (gfc_component *comp)
{
- return comp->attr.allocatable || class_allocatable (comp);
+ if (comp->ts.type == BT_CLASS && CLASS_DATA (comp))
+return CLASS_DATA (comp)->attr.allocatable;
+ return comp->attr.allocatable;
}
static bool
comp_pointer (gfc_component *comp)
{
- return comp->attr.pointer
-|| comp->attr.proc_pointer
-|| comp->attr.class_pointer
-|| class_pointer (comp);
+ if (comp->attr.proc_pointer)
+return true;
+ if (comp->ts.type == BT_CLASS && CLASS_DATA (comp))
+return CLASS_DATA (comp)->attr.class_pointer;
+ return comp->attr.pointer;
}
/* Fetch or generate an initializer for the given component.
diff --git a/gcc/fortran/gfortran.h b/gcc/fortran/gfortran.h
index cbc95d3..52a76bc 100644
--- a/gcc/fortran/gfortran.h
+++ b/gcc/fortran/gfortran.h
@@ -3673,7 +3673,7 @@ void gfc_add_class_array_ref (gfc_expr *);
bool gfc_is_class_array_ref (gfc_expr *, bool *);
bool gfc_is_class_scalar_expr (gfc_expr *);
bool gfc_is_class_container_ref (gfc_expr *e);
-gfc_expr *gfc_class_initializer (gfc_typespec *, gfc_expr *);
+gfc_expr *gfc_class_initializer (gfc_typespec *, gfc_expr *, bool);
unsigned int gfc_hash_value (gfc_symbol *);
gfc_expr *gfc_get_len_component (gfc_expr *e, int);
bool gfc_build_class_symbol (gfc_typespec *, symbol_attribute *,
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index a6bcd2b..891f82a 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -406,20 +406,288 @@ gfc_conv_descriptor_ubound_set (stmtblock_t *block, tree desc,
gfc_add_modify (block, t, fold_convert (TREE_TYPE (t), value));
}
+
+/* Create a new dtype constructor. */
+
+static tree
+build_init_dtype (tree ctor, int rank)
+{
+ tree type;
+ tree field;
+ tree value;
+ tree init;
+ vec *vlst = NULL;
+
+ gcc_assert (TREE_CODE (ctor) == CONSTRUCTOR);
+ type = TREE_TYPE (ctor);
+
+ value = gfc_get_expr_from_ctor (ctor, 0);
+ if (value == NULL_TREE)
+value = integer_zero_node;
+ if (!TREE_CONSTANT (value) || TREE_SIDE_EFFECTS (value))
+value = (DECL_INITIAL (value))
+ ? (DECL_INITIAL (value)) : (integer_ze
[Patch, fortran] PR fortran/101047/101048 Pointer explicit initialization
Hi All! Proposed patch to: Bug 101047 - Pointer explicit initialization fails Bug 101048 - Class pointer explicit initialization refuses valid Patch tested only on x86_64-pc-linux-gnu. This patch deals with implementation of explicit initialization for pointer variables. It basically relies on using "gfc_conv_expr_descriptor" to build a pointer assignment and re-parsing it back into a descriptor constructor. It proceeds to implement the necessary differences between allocatable and pointer variables explicit initialization and to add, and correct, missing references to "CLASS_DATA" entities. Thank you very much. Best regards, José Rui Fortran: get pointer explicit initialization working. gcc/fortran/ChangeLog: PR fortran/10148 * class.c (gfc_class_initializer): only disassociate pointer if explicitly requested. PR fortran/10148 * expr.c (gfc_check_assign_symbol): get rank from CLASS_DATA if necessary. PR fortran/10147 * expr.c (class_allocatable): remove unnecessary auxiliary function. (class_pointer): remove unnecessary auxiliary function. (comp_allocatable): consolidate allocatable attribute checking. (comp_pointer): consolidate pointer attribute checking. * gfortran.h (gfc_class_initializer): change prototype to reflect the extra parameter. * trans-array.c: new group of functions to re-parse a "STATEMENT_LIST" back into a "CONSTRUCTOR". (build_init_dtype): Create a new dtype constructor. (build_init_desc_dtype): Find the old dtype constructor and create a new one. (append_init_dim): Append one of dim fields to vector. (build_init_dim): Create a dim constructor. (build_init_desc_dim): Create the dim array constructor. (append_desc_field): Append a field to the constructor vector. (build_init_descriptor): Create an array descriptor constructor. (gfc_build_init_descriptor_dtype): new function to build a descriptor containing only a dtype. (gfc_build_null_descriptor): update function to nullify and add the dtype. (gfc_build_init_descriptor): new function to build a full array descriptor constructor. (gfc_trans_static_array_pointer): updated to take in consideration the diferences between pointer and allocatable explicit initialization and the initialization of entities containing "CLASS_DATA". (gfc_conv_array_initializer): change function calls to reflect interface changes. * trans-array.h (gfc_trans_static_array_pointer): add return value. (gfc_build_null_descriptor): add parameter to prototype. (gfc_build_init_descriptor): new prototype. * trans-common.c (create_common): change function call to reflect interface changes. * trans-decl.c (gfc_create_string_length): set initial deferred character length to zero. (gfc_get_symbol_decl): change function call to reflect interface changes. (get_proc_pointer_decl): change function call to reflect interface changes. (gfc_trans_deferred_vars): change function call to reflect interface changes. (gfc_emit_parameter_debug_info): get rank from CLASS_DATA if necessary, change function call to reflect interface changes. * trans-expr.c (gfc_class_unlimited_poly): new auxiliary function to check if a tree representing a type is unlimited polymorphic. (gfc_conv_initializer): renamed gfc_conv_initializer_common. (gfc_conv_initializer_common): take in consideration differences between pointers and allocatables in initialization. (gfc_conv_sym_initializer): interface for initialization using gfc_symbol. (gfc_conv_comp_initializer): interface for initialization using gfc_component. (gfc_conv_expr_initializer): interface for initialization using gfc_expr. (gfc_trans_subcomponent_assign): change function call to reflect interface changes. (gfc_conv_union_initializer): change function call to reflect interface changes. (gfc_conv_structure): split in two divide between explicit initialization default initialization. (gfc_conv_structure_initializer): handles explicit initialization of every component field. (gfc_conv_expr): change function call to reflect interface changes. * trans-types.c (gfc_get_dtype_rank_type): if the "static_flag" is set elem_len to the initial value, from "DECL_INITIAL", or zero. * trans-types.h (gfc_get_dtype_rank_type): add parameter to prototype. * trans.c: new group of functions to extract a RHS from a "CONSTRUCTOR" or a "STATEMENT_LIST" or a "MODIFY_EXPR". (tree_ref_equal): simple tree equality check.
Re: [PATCH 0/3]: C N2653 char8_t implementation
On 6/11/21 1:27 PM, Joseph Myers wrote: On Fri, 11 Jun 2021, Tom Honermann via Gcc-patches wrote: The option is needed because it impacts core language backward compatibility (for both C and C++, the type of u8 string literals; for C++, the type of u8 character literals and the new char8_t fundamental type). Lots of new features in new standard versions can affect backward compatibility. We generally bundle all of those up into a single -std option rather than having an explosion of different language variants with different features enabled or disabled. I don't think this feature, for C, reaches the threshold that would justify having a separate option to control it, especially given that people can use -Wno-pointer-sign or pointer casts or their own local char8_t typedef as an intermediate step if they want code using u8"" strings to work for both old and new standard versions. Ok, I'm happy to defer to your experience. My perspective is likely biased by the C++20 changes being more disruptive for that language. I don't think u8"" strings are widely used in C library headers in a way where the choice of type matters. (Use of a feature in library headers is a key thing that can justify options such as -fgnu89-inline, because it means the choice of language version is no longer fully under control of a single project.) That aligns with my expectations. The only feature proposed for C2x that I think is likely to have significant compatibility implications in practice for a lot of code is making bool, true and false into keywords. I still don't think a separate option makes sense there. (If that feature is accepted for C2x, what would be useful is for people to do distribution rebuilds with -std=gnu2x as the default to find and fix code that breaks, in advance of the default actually changing in GCC. But the workaround for not-yet-fixed code would be -std=gnu11, not a separate option for that one feature.) Ok, that comparison is helpful. I think the whole patch series would best wait until after the proposal has been considered by a WG14 meeting, in addition to not increasing the number of language dialects supported. As an opt-in feature, this is useful to gain implementation and deployment experience for WG14. I think this feature is one of the cases where experience in C++ is sufficiently relevant for C (although there are certainly cases of other language features where the languages are sufficiently different that using C++ experience like that can be problematic). E.g. we didn't need -fdigit-separators for C before digit separators were added to C2x, and we don't need -fno-digit-separators now they are in C2x (the feature is just enabled or disabled based on the language version), although that's one of many features that do affect compatibility in corner cases. Got it, thanks again, that comparison is helpful. Per this and prior messages, I'll revise the gcc patch series as follows (I'll likewise revise the glibc changes, but will detail that in the corresponding glibc mailing list thread). 1. Remove the proposed use of -fchar8_t and -fno-char8_t for C code. 2. Remove the updated documentation for the -fchar8_t option since it won't be applicable to C code. 3. Remove the _CHAR8_T_SOURCE macro. 4. Enable the change of u8 string literal type based on -std=[gnu|c]2x (by setting flag_char8_t if flag_isoc2x is set). 5. Condition the declarations of atomic_char8_t and __GCC_ATOMIC_CHAR8_T_LOCK_FREE on _GNU_SOURCE or _ISOC2X_SOURCE. 6. Remove the char8 data member from cpp_options that I had added and forgot to remove. 7. Revise the tests and rename them for consistency with other C2x tests. If I've forgotten anything, please let me know. Thank you for the thorough review! Tom.
[committed] More improvements to H8 logicals for test/compare elimination
Another round of redundant test/compare elimination on the H8. This
improves our ability to use QImode logicals. Part of the problem we
needed to resolve here was that we support generating the b*
instructions which do not set condition codes as well as the usual and,
ior, xor.
The approach taken was to bring the b* form into the
define_insn_and_split and not split when the b* form can be used
(they're only used when twiddling a single bit). This seems to work
reasonably well based on the code I've looked at -- it's consistently
finding optimization opportunities resulting in notable decreases in the
size of newlib/libgcc.
This in turn allows us to have a nice generic qi pattern
which handles all the QImode logicals in the obvious and simple way.
This patch also adds support for the muls patterns generating condition
codes. I didn't find any real examples of this being used across
newlib/libgcc, but it's trivial to do. Note that mulu does not set
condition codes, so while it may look inconsistent, it matches the
hardware to the best of my knowledge.
Committing to the trunk (after a 21hr test cycle),
Jeff
commit 8a7d54b1e10b8f4fba1358260ed2e7056ed23cbd
Author: Jeff Law
Date: Sun Jun 13 11:09:38 2021 -0400
[committed] More improvements to H8 logicals for test/compare elimination
gcc/
* config/h8300/logical.md (qi3_1): New pattern.
(andqi3_1): Removed.
(qi3_1): Do not split for IOR/XOR a single bit.
(H8/SX bit logicals): Split out from other patterns.
* config/h8300/multiply.md (mulqihi3_const): Renamed from
mulqihi3_const_clobber_flags.
(mulqihi3, mulhisi3_const, mulhisi3): Similarly
diff --git a/gcc/config/h8300/logical.md b/gcc/config/h8300/logical.md
index fae3c7cd0c5..cb4c6384bdf 100644
--- a/gcc/config/h8300/logical.md
+++ b/gcc/config/h8300/logical.md
@@ -69,14 +69,6 @@
""
[(set_attr "length" "8,2")])
-(define_insn "*andqi3_1"
- [(set (match_operand:QI 0 "register_operand" "=r")
- (and:QI (match_operand:QI 1 "register_operand" "%0")
- (match_operand:QI 2 "h8300_src_operand" "rn")))
- (clobber (reg:CC CC_REG))]
- ""
- "and %X2,%X0"
- [(set_attr "length" "2")])
(define_insn_and_split "*andor3"
[(set (match_operand:QHSI 0 "register_operand" "=r")
@@ -179,27 +171,49 @@
(match_operand:QI 2 "h8300_src_operand" "Y2,rQi")))]
"TARGET_H8300SX || register_operand (operands[0], QImode)
|| single_one_operand (operands[2], QImode)"
- "#"
- "&& reload_completed"
+ { return == IOR ? "bset\\t%V2,%R0" : "bnot\\t%V2,%R0"; }
+ "&& reload_completed && !single_one_operand (operands[2], QImode)"
[(parallel [(set (match_dup 0) (ors:QI (match_dup 1) (match_dup 2)))
- (clobber (reg:CC CC_REG))])])
+ (clobber (reg:CC CC_REG))])]
+ ""
+ [(set_attr "length" "8")])
-(define_insn "qi3_1_clobber_flags"
- [(set (match_operand:QI 0 "bit_operand" "=U,rQ")
- (ors:QI (match_operand:QI 1 "bit_operand" "%0,0")
- (match_operand:QI 2 "h8300_src_operand" "Y2,rQi")))
+(define_insn "*qi3_1"
+ [(set (match_operand:QI 0 "bit_operand" "=rQ")
+ (ors:QI (match_operand:QI 1 "bit_operand" "%0")
+ (match_operand:QI 2 "h8300_src_operand" "rQi")))
(clobber (reg:CC CC_REG))]
- "TARGET_H8300SX || register_operand (operands[0], QImode)
- || single_one_operand (operands[2], QImode)"
- {
-if (which_alternative == 0)
- return == IOR ? "bset\\t%V2,%R0" : "bnot\\t%V2,%R0";
-else if (which_alternative == 1)
- return == IOR ? "or\\t%X2,%X0" : "xor\\t%X2,%X0";
-gcc_unreachable ();
+ "TARGET_H8300SX"
+ { return == IOR ? "or\\t%X2,%X0" : "xor\\t%X2,%X0"; }
+ [(set_attr "length" "*")
+ (set_attr "length_table" "logicb")])
+
+(define_insn "*qi3_1"
+ [(set (match_operand:QI 0 "register_operand" "=r")
+ (ors:QI (match_operand:QI 1 "register_operand" "%0")
+ (match_operand:QI 2 "h8300_src_operand" "ri")))
+ (clobber (reg:CC CC_REG))]
+ "TARGET_H8300SX"
+ { return == IOR ? "or\\t%X2,%X0" : "xor\\t%X2,%X0"; }
+ [(set_attr "length" "*")
+ (set_attr "length_table" "logicb")])
+
+(define_insn "*qi3_1"
+ [(set (match_operand:QI 0 "register_operand" "=r")
+ (logicals:QI (match_operand:QI 1 "register_operand" "%0")
+(match_operand:QI 2 "h8300_src_operand" "rn")))
+ (clobber (reg:CC CC_REG))]
+ ""
+ {
+if ( == IOR)
+ return "or\\t%X2,%X0";
+else if ( == XOR)
+ return "xor\\t%X2,%X0";
+else if ( == AND)
+ return "and\\t%X2,%X0";
+ gcc_unreachable ();
}
- [(set_attr "length" "8,*")
- (set_attr "length_table" "*,logicb")])
+ [(set_attr "length" "2")])
;; --
;; {AND,IOR,XOR}{HI3,SI3} PATTERNS
diff --git a/gcc/config/h8300/multiply.md b/gcc/config/h8300/multiply.md
index 1d56d4797a7..8b9328c1282 100644
--- a/gcc/confi
Re: [PATCH 1/3]: C N2653 char8_t: Language support
On 6/11/21 12:53 PM, Jakub Jelinek wrote:
On Fri, Jun 11, 2021 at 12:20:48PM -0400, Tom Honermann wrote:
I'm open to whatever signaling mechanism would be preferred. It took me a
while to settle on _CHAR8_T_SOURCE as the mechanism to propose as I didn't
find much for other precedents.
I agree that having _CHAR8_T_SOURCE be implied by the -fchar8_t option is
unusual with respect to other feature test macros. Is that what you find to
be weird and inconsistent?
Predefining __SIZEOF_CHAR8_T__ would be consistent with __SIZEOF_WCHAR_T__,
but kind of strange too since the size is always 1.
Perhaps a better approach would be to follow the __CHAR16_TYPE__ and
__CHAR32_TYPE__ precedent and define __CHAR8_TYPE__ to unsigned char. That
is likewise a bit strange since the type would always be unsigned char, but
it does provide a bit more symmetry. That could potentially have some use
as well; for C++, it could be defined as char8_t and thereby reflect the
difference between the two languages. Perhaps it could be useful in the
future as well if WG14 were to add distinct char8_t, char16_t, and char32_t
types as C++ did (I'm not offering any prediction regarding the likelihood
of that happening).
C++ already predefines
#define __CHAR8_TYPE__ unsigned char
#define __CHAR16_TYPE__ short unsigned int
#define __CHAR32_TYPE__ unsigned int
for -std={c,gnu}++2{0,a,3,b} or -fchar8_t (unless -fno-char8_t), so I agree
just making sure __CHAR8_TYPE__ is defined to unsigned char even for C
is best.
And you probably don't need to do anything in the C patch for it,
void
c_stddef_cpp_builtins(void)
{
builtin_define_with_value ("__SIZE_TYPE__", SIZE_TYPE, 0);
...
if (flag_char8_t)
builtin_define_with_value ("__CHAR8_TYPE__", CHAR8_TYPE, 0);
builtin_define_with_value ("__CHAR16_TYPE__", CHAR16_TYPE, 0);
builtin_define_with_value ("__CHAR32_TYPE__", CHAR32_TYPE, 0);
will do that.
Thank you; I had forgotten that I had already done that work. I
confirmed that the proposed changes result in __CHAR8_TYPE__ being
defined (the tests included with the patch already enforced it).
Tom.
Jakub
[PATCH] dwarf: Multi-register CFI address support.
Add support for architectures such as AMD GCN, in which the pointer size is
larger than the register size. This allows the CFI information to include
multi-register locations for the stack pointer, frame pointer, and return
address.
This patch was originally posted by Andrew Stubbs in
https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552873.html
It has now been re-worked according to the review comments. It does not use
DW_OP_piece or DW_OP_LLVM_piece_end. Instead it uses
DW_OP_bregx/DW_OP_shl/DW_OP_bregx/DW_OP_plus to build the CFA from multiple
consecutive registers. Here is how .debug_frame looks before and after this
patch:
$ cat factorial.c
int factorial(int n) {
if (n == 0) return 1;
return n * factorial (n - 1);
}
$ amdgcn-amdhsa-gcc -g factorial.c -O0 -c -o fac.o
$ llvm-dwarfdump -debug-frame fac.o
*** without this patch (edited for brevity)***
0014 CIE
DW_CFA_def_cfa: reg48 +0
DW_CFA_register: reg16 reg50
0018 002c FDE cie= pc=...01ac
DW_CFA_advance_loc4: 96
DW_CFA_offset: reg46 0
DW_CFA_offset: reg47 4
DW_CFA_offset: reg50 8
DW_CFA_offset: reg51 12
DW_CFA_offset: reg16 8
DW_CFA_advance_loc4: 4
DW_CFA_def_cfa_sf: reg46 -16
*** with this patch (edited for brevity)***
0024 CIE
DW_CFA_def_cfa_expression: DW_OP_bregx SGPR49+0, DW_OP_const1u 0x20,
DW_OP_shl, DW_OP_bregx SGPR48+0, DW_OP_plus
DW_CFA_expression: reg16 DW_OP_bregx SGPR51+0, DW_OP_const1u 0x20, DW_OP_shl,
DW_OP_bregx SGPR50+0, DW_OP_plus
0028 003c FDE cie= pc=...01ac
DW_CFA_advance_loc4: 96
DW_CFA_offset: reg46 0
DW_CFA_offset: reg47 4
DW_CFA_offset: reg50 8
DW_CFA_offset: reg51 12
DW_CFA_offset: reg16 8
DW_CFA_advance_loc4: 4
DW_CFA_def_cfa_expression: DW_OP_bregx SGPR47+0, DW_OP_const1u 0x20,
DW_OP_shl, DW_OP_bregx SGPR46+0, DW_OP_plus, DW_OP_lit16, DW_OP_minus
gcc/ChangeLog:
* dwarf2cfi.c (dw_stack_pointer_regnum): Change type to struct cfa_reg.
(dw_frame_pointer_regnum): Likewise.
(new_cfi_row): Use set_by_dwreg.
(get_cfa_from_loc_descr): Use set_by_dwreg. Support register spans.
handle DW_OP_bregx with DW_OP_breg{0-31}. Support DW_OP_lit*,
DW_OP_const*, DW_OP_minus, DW_OP_shl and DW_OP_plus.
(lookup_cfa_1): Use set_by_dwreg.
(def_cfa_0): Update for cfa_reg and support register spans.
(reg_save): Change sreg parameter to struct cfa_reg. Support register
spans.
(dwf_cfa_reg): New function.
(dwarf2out_flush_queued_reg_saves): Use dwf_cfa_reg instead of
dwf_regno.
(dwarf2out_frame_debug_def_cfa): Likewise.
(dwarf2out_frame_debug_adjust_cfa): Likewise.
(dwarf2out_frame_debug_cfa_offset): Likewise. Update reg_save usage.
(dwarf2out_frame_debug_cfa_register): Likewise.
(dwarf2out_frame_debug_expr): Likewise.
(create_pseudo_cfg): Use set_by_dwreg.
(initial_return_save): Use set_by_dwreg and dwf_cfa_reg,
(create_cie_data): Use dwf_cfa_reg.
(execute_dwarf2_frame): Use dwf_cfa_reg.
(dump_cfi_row): Use set_by_dwreg.
* dwarf2out.c (build_span_loc, build_breg_loc): New function.
(build_cfa_loc): Support register spans.
(build_cfa_aligned_loc): Update cfa_reg usage.
(convert_cfa_to_fb_loc_list): Use set_by_dwreg.
* dwarf2out.h (struct cfa_reg): New type.
(struct dw_cfa_location): Use struct cfa_reg.
(build_span_loc): New prototype.
* gengtype.c (main): Accept poly_uint16_pod type.
---
gcc/dwarf2cfi.c | 260
gcc/dwarf2out.c | 55 +-
gcc/dwarf2out.h | 37 ++-
gcc/gengtype.c | 1 +
4 files changed, 283 insertions(+), 70 deletions(-)
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index c27ac1960b0..5aacdcd094a 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2cfi.c
@@ -229,8 +229,8 @@ static vec queued_reg_saves;
static bool any_cfis_emitted;
/* Short-hand for commonly used register numbers. */
-static unsigned dw_stack_pointer_regnum;
-static unsigned dw_frame_pointer_regnum;
+static struct cfa_reg dw_stack_pointer_regnum;
+static struct cfa_reg dw_frame_pointer_regnum;
/* Hook used by __throw. */
@@ -430,7 +430,7 @@ new_cfi_row (void)
{
dw_cfi_row *row = ggc_cleared_alloc ();
- row->cfa.reg = INVALID_REGNUM;
+ row->cfa.reg.set_by_dwreg (INVALID_REGNUM);
return row;
}
@@ -538,7 +538,7 @@ get_cfa_from_loc_descr (dw_cfa_location *cfa, struct
dw_loc_descr_node *loc)
cfa->offset = 0;
cfa->base_offset = 0;
cfa->indirect = 0;
- cfa->reg = -1;
+ cfa->reg.set_by_dwreg (INVALID_REGNUM);
for (ptr = loc; ptr != NULL; ptr = ptr->dw_loc_next)
{
@@ -578,10 +578,10 @@ get_cfa_from_loc_descr (dw_cfa_location *cfa, struct
dw_loc_descr_node *loc)
case DW_OP_reg29:
case DW_OP_reg30:
case DW_OP_reg31:
- c
Re: [PATCH] x86: Replace ix86_red_zone_size with ix86_red_zone_used
On Fri, Jun 11, 2021 at 10:46 PM H.J. Lu wrote:
>
> Add red_zone_used to machine_function to track if red zone is used.
> When expanding function prologue, set red_zone_used to true if red
> zone is used.
>
> gcc/
>
> PR target/pr101023
> * config/i386/i386.c (ix86_expand_prologue): Set red_zone_used
> to true if red zone is used.
> (ix86_output_indirect_jmp): Replace ix86_red_zone_size with
> ix86_red_zone_used.
> * config/i386/i386.h (machine_function): Add red_zone_used.
> (ix86_red_zone_size): Removed.
> (ix86_red_zone_used): New.
> * config/i386/i386.md (peephole2 patterns): Replace
> ix86_red_zone_size with ix86_red_zone_used.
>
> gcc/testsuite/
>
> PR target/pr101023
> * g++.target/i386/pr101023a.C: New test.
> * g++.target/i386/pr101023b.C: Likewise.
LGTM.
Thanks,
Uros.
> ---
> gcc/config/i386/i386.c| 6 ++-
> gcc/config/i386/i386.h| 5 +-
> gcc/config/i386/i386.md | 8 +--
> gcc/testsuite/g++.target/i386/pr101023a.C | 62 +++
> gcc/testsuite/g++.target/i386/pr101023b.C | 5 ++
> 5 files changed, 80 insertions(+), 6 deletions(-)
> create mode 100644 gcc/testsuite/g++.target/i386/pr101023a.C
> create mode 100644 gcc/testsuite/g++.target/i386/pr101023b.C
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 05b8dc806cd..a61255857ff 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -8401,10 +8401,14 @@ ix86_expand_prologue (void)
>|| frame.stack_pointer_offset < CHECK_STACK_LIMIT))
> {
> ix86_emit_save_regs_using_mov (frame.reg_save_offset);
> + cfun->machine->red_zone_used = true;
> int_registers_saved = true;
> }
> }
>
> + if (frame.red_zone_size != 0)
> +cfun->machine->red_zone_used = true;
> +
>if (stack_realign_fp)
> {
>int align_bytes = crtl->stack_alignment_needed / BITS_PER_UNIT;
> @@ -15915,7 +15919,7 @@ ix86_output_indirect_jmp (rtx call_op)
> {
>/* We can't have red-zone since "call" in the indirect thunk
> pushes the return address onto stack, destroying red-zone. */
> - if (ix86_red_zone_size != 0)
> + if (ix86_red_zone_used)
> gcc_unreachable ();
>
>ix86_output_indirect_branch (call_op, "%0", true);
> diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
> index 919d0b2418a..182b3275991 100644
> --- a/gcc/config/i386/i386.h
> +++ b/gcc/config/i386/i386.h
> @@ -2663,6 +2663,9 @@ struct GTY(()) machine_function {
> invalid calls. */
>BOOL_BITFIELD silent_p : 1;
>
> + /* True if red zone is used. */
> + BOOL_BITFIELD red_zone_used : 1;
> +
>/* The largest alignment, in bytes, of stack slot actually used. */
>unsigned int max_used_stack_alignment;
>
> @@ -2693,7 +2696,7 @@ extern GTY(()) tree ms_va_list_type_node;
> #define ix86_current_function_calls_tls_descriptor \
>(ix86_tls_descriptor_calls_expanded_in_cfun && df_regs_ever_live_p
> (SP_REG))
> #define ix86_static_chain_on_stack (cfun->machine->static_chain_on_stack)
> -#define ix86_red_zone_size (cfun->machine->frame.red_zone_size)
> +#define ix86_red_zone_used (cfun->machine->red_zone_used)
>
> /* Control behavior of x86_file_start. */
> #define X86_FILE_START_VERSION_DIRECTIVE false
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index 7743c61ec86..6e4abf32e7c 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -20491,7 +20491,7 @@ (define_peephole2
> (clobber (mem:BLK (scratch)))])]
>"(TARGET_SINGLE_PUSH || optimize_insn_for_size_p ())
> && INTVAL (operands[0]) == -GET_MODE_SIZE (word_mode)
> - && ix86_red_zone_size == 0"
> + && !ix86_red_zone_used"
>[(clobber (match_dup 1))
> (parallel [(set (mem:W (pre_dec:P (reg:P SP_REG))) (match_dup 1))
> (clobber (mem:BLK (scratch)))])])
> @@ -20505,7 +20505,7 @@ (define_peephole2
> (clobber (mem:BLK (scratch)))])]
>"(TARGET_DOUBLE_PUSH || optimize_insn_for_size_p ())
> && INTVAL (operands[0]) == -2*GET_MODE_SIZE (word_mode)
> - && ix86_red_zone_size == 0"
> + && !ix86_red_zone_used"
>[(clobber (match_dup 1))
> (set (mem:W (pre_dec:P (reg:P SP_REG))) (match_dup 1))
> (parallel [(set (mem:W (pre_dec:P (reg:P SP_REG))) (match_dup 1))
> @@ -20520,7 +20520,7 @@ (define_peephole2
> (clobber (reg:CC FLAGS_REG))])]
>"(TARGET_SINGLE_PUSH || optimize_insn_for_size_p ())
> && INTVAL (operands[0]) == -GET_MODE_SIZE (word_mode)
> - && ix86_red_zone_size == 0"
> + && !ix86_red_zone_used"
>[(clobber (match_dup 1))
> (set (mem:W (pre_dec:P (reg:P SP_REG))) (match_dup 1))])
>
> @@ -20532,7 +20532,7 @@ (define_peephole2
> (clobber (reg:CC FLAGS_REG))])]
>"(TARGET_DOUBLE_PUSH || optimize_insn_for_size_p ())
> && INTVAL (o
Re: [committed] wwwdocs: gcc-11/changes.html: Editorial changes for RISC-V
On Sun, 13 Jun 2021 07:58:50 +0200 (CEST) Gerald Pfeifer wrote: > RISC-V has received a very nice section in the GCC 11 release notes > thanks to Kito. > > This are a couple of editorial changes, completing some sentence and > breaking longer sentences among others, and a bit of grammar. > > Pushed. > > Gerald > > --- > htdocs/gcc-11/changes.html | 33 ++--- > 1 file changed, 18 insertions(+), 15 deletions(-) > > diff --git a/htdocs/gcc-11/changes.html b/htdocs/gcc-11/changes.html > index 97606174..491b6b71 100644 > --- a/htdocs/gcc-11/changes.html > +++ b/htdocs/gcc-11/changes.html > @@ -953,33 +953,36 @@ You may also want to check out our > + Legacy architecture extension test macros like > + __riscv_atomic are deprecated, but will still be > + supported for at least 2 release cycles. I didn't look if we can annotate macros as deprecated to emit a warning on use nor if they are marked as such. > >Support IFUNC for riscv*-*-linux*. > + Add new option -misa-spec=* to control ISA spec version. > + This controls the default version of each extensions. > + It defaults to 2.2. Is "each extensions" in plural really correct gramatically? "default version of extensions" or "default version of each extension" And is "version of" correct WRT the code or does the code control the version "for extensions"? I.e. "to control the default ISA spec version for extensions" if that's what the option does? thanks,
Re: [PATCH] arc: Add --with-fpu support for ARCv2 cpus
On Fri, 11 Jun 2021 14:25:24 +0300 Claudiu Zissulescu wrote: > Hi Bernhard, > > Please find attached my latest patch, it includes (hopefully) all your > feedback. > > Thank you for comments, concise and clean, i wouldn't know what to remove. LGTM. thanks for your patience!
