Re: Re: [PATCH] Testsuite: Add btf-dataset option for RISC-V.
-原始邮件-
发件人: "Palmer Dabbelt"
发送时间: 2021-12-31 00:59:08 (星期五)
收件人: jeffreya...@gmail.com
抄送: gcc-patches@gcc.gnu.org, jia...@iscas.ac.cn, gcc-patches@gcc.gnu.org,
indu.bha...@oracle.com, kito.ch...@sifive.com, yul...@nj.iscas.ac.cn,
si...@isrc.iscas.ac.cn, shi...@iscas.ac.cn
主题: Re: [PATCH] Testsuite: Add btf-dataset option for RISC-V.
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into
right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type Format) is the metadata format which encodes the
debug info related to BPF program/map, more details on:
https://www.kernel.org/doc/html/latest/bpf/index.html#bpf-type-format-btf
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Add riscv target
support.
Is the goal here to get the variable "d" out of the small data section
and into the standard data section? It's not clear from your
description .
Neither an ACK nor a NAK at this point. I need to understand
better
what you're trying to accomplish.
Thanks for your mentions, the testcase said it expect 3 DATASEC records: one
for each of .data, .rodata and .bss.
If we only use /* { dg-options "-O0 -gbtf -dA" } */ as default compile option
on riscv target like:
```
$ riscv64-unknown-elf-gcc -S -O0 -gbtf -dA btf-datasec-1.c
```
the variable in section will be throw into .sdata, .sbss, .srodata and don't
fit the check require, and I add the additional option '-msmall-data-limit' to
fix it, to get a correct .section part, we need to limit the
'-msmall-data-limit' less than the smallest variable 'int a' size define as 4
byte, then it will be send into section .bss.
```
$ riscv64-unknown-elf-gcc -S -O0 -gbtf -dA btf-datasec-1.c -o btf-datasec-1.s
.Ltext0:
.cfi_sections .debug_frame
.file 0 "/root/test" "btf-datasec-1.c"
.globl a
.section.sbss,"aw",@nobits
.align 2
.type a, @object
.size a, 4
$ riscv64-unknown-elf-gcc -S -O0 -gbtf -dA -msmall-data-limit=2 btf-datasec-1.c
-o btf-datasec-2.s
.Ltext0:
.cfi_sections .debug_frame
.file 0 "/root/test" "btf-datasec-1.c"
.globl a
.bss
.align 2
.type a, @object
.size a, 4
```
It is seem on other variable, and when all section set right, all check in the
testcase can pass on riscv.
```
$ diff btf-datasec-1.s btf-datasec-2.s
.bss
144c163
.section.srodata,"a"
---
.section.rodata
151c170
.section.sdata,"aw"
---
.data
158c177
.section.srodata
---
.section.rodata
```
IIUC that's what this is doing, though the commit message isn't clear at
all. That saind, it might be better to do something like
Sorry for the unclear commit, I explained the idea in this mail, should I
resend the patch?
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index dbb236bbda1..c0ad77d40aa 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -22,9 +22,9 @@
/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7
} } */
/* Check that strings for each DATASEC have been added to the BTF
string table. */
-/* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
int a;
long long b;
as whether specific symbols end up in .data or .sdata is really just an
optimization and either should be sufficiently correct.
Yes, I think you are quite right, this is a question that the symbol goes
different section after optimization.
IIRC some targets have other flavors of these, PPC's .sdata2 comes to
mind. Not sure if we'd need that to drop their -msdata=none flag.
I'm not familiar with other target, maybe there are some error parts with my
understanding, Thanks at all!
Re: [PATCH] Set __FLT_EVAL_METHOD__/__FLT_EVAL_METHOD_TS_18661_3__ to FLT_EVAL_METHOD_PROMOTE_TO_FLOAT when FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16.
On Mon, 27 Dec 2021, liuhongt via Gcc-patches wrote: > Since FLT_EVAL_METHOD only accepts negative value, 0, 1 or 2. > > gcc/c-family/ChangeLog: > > PR c/100854 > * c-common.c (excess_precision_mode_join): Return > FLT_EVAL_METHOD_PROMOTE_TO_FLOAT when both x and y are > FLT_EVAL_METHOD_PROMOTE_TO_FLOAT16. This patch is incorrect. The function excess_precision_mode_join correctly implements the semantics defined in the comment above the function, resulting in the correct value of FLT_EVAL_METHOD being defined in (taking proper account of whether C23 values for FLT_EVAL_METHOD are permitted or not, including the -fpermitted-flt-eval-methods= option). -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH] Register --sysroot in the driver switches table
> On 28 Dec 2021, at 17:38, Jeff Law wrote: >> gcc/ >> * gcc.c (driver_handle_option): do_save --sysroot. > OK. Thanks for the prompt review Jeff! I have another simple one coming :)
[PATCH 3/3] c++: expr-cast - C-style cast conformance [PR77465]
gcc/testsuite/ChangeLog: * g++.dg/conversion/explicit2.C: New test. * g++.dg/conversion/explicit3.C: New test. 0003-Add-tests-verifying-conformance-to-explicit.patch Description: Binary data
[PATCH 2/3] c++: expr-cast - C-style cast conformance [PR77465]
gcc/cp/ChangeLog: * call.c (reference_binding): gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-union.C: * g++.dg/warn/Wstrict-aliasing-5.C: * g++.old-deja/g++.jason/rvalue3.C: * g++.dg/conversion/explicit1.C: New test. 0002-Add-const-qualification-to-static_cast-stage-of-C-st.patch Description: Binary data
[PATCH 1/3] c++: expr-cast - C-style cast conformance [PR77465]
PR c++/77465 - [DR909] rejected C-style cast involving casting away constness from result of conversion operator PR c++/77465 gcc/cp/ChangeLog: * call.c (tourney): (joust): (build_user_type_conversion_1): (reference_binding): (implicit_conversion_1): (build_user_type_conversion): (perform_overload_resolution): (build_op_call): (build_conditional_expr): (build_new_op): (build_op_subscript): (convert_like_internal): (build_over_call): (build_new_method_call): * cp-tree.h (build_user_type_conversion): gcc/testsuite/ChangeLog: * g++.old-deja/g++.brendan/misc17.C: * g++.old-deja/g++.mike/p2855.C: * g++.dg/conversion/cwg909.C: New test. 0001-Apply-C-style-cast-rules-for-user-defined-conversion.patch Description: Binary data
[PATCH 0/3] c++: expr-cast - C-style cast conformance [PR77465]
This patch series improves conformance to the C++ standard for C-style casts (explicit cast notation, [expr.cast]) in two scenarios. First, as discussed in CWG 909 [1], a C-style cast may invoke a user-defined conversion (as a static_cast) followed by a const_cast; currently this is erroneously rejected, tracked in PR77465 [2]. Second, a C-style cast to non-const reference to arithmetic type can and thus should be interpreted as a static_cast reference binding to temporary followed by a const_cast; currently it is interpreted as a reinterpret_cast (possibly followed by const_cast). To the best of my knowledge this has not been reported as a defect; credit to Turtlefight on Stack Overflow [3] for analyzing the situation, drawing my attention to the above issues, and convincing me that my interpretation was correct. Note that C-style cast to /const/ arithmetic reference will already introduce a temporary; this patch only changes the behavior where the reference is to non-const. Clearly there is the potential for miscompilation of existing code that assumes an incorrect interpretation (reinterpret_cast); a number of existing test cases are amended in this patch series. In consideration of this, I have checked bootstrap (on x86_64) with no new errors, and add a warning (to Wconversion) where a C-style cast to arithmetic reference introduces a temporary in a situation where the user may expect a reinterpret_cast (type-punning); this affects both the const (existing) and non-const case. Note that this change will not affect C code compiled as C++, since that code cannot contain user-defined conversions or references. In this patch series, * 1/3 - allow C-style cast to invoke user-defined conversion followed by const_cast, resolving PR77465; adds a test case and fixes existing test cases which expect this to be rejected * 2/3 - allow C-style cast to non-const reference to arithmetic type to invoke static_cast reference binding to temporary followed by const_cast; adds a test case and fixes existing test cases which expect reinterpret_cast semantics * 3/3 - add comprehensive test suite covering expr.cast scenarios, positive and negative. 1. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#909 2. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77465 3. https://stackoverflow.com/a/70400230/567292
Re: [PATCH] convert (xor (and (xor A B) C) A) to (ior (and A ~C) (and B C)) [PR90323]
Hi!
On Tue, Dec 28, 2021 at 07:27:06PM -0600, Xionghu Luo wrote:
> Bootstrapped and regtested on powerpc64le-linux-gnu {P10,P9}
> powerpc64-linux-gnu {P8, P7} and X86. OK for master?
>
> gcc/ChangeLog:
>
> PR 90323
> * simplify-rtx.c (simplify_context::simplify_binary_operation_1): Relax
> C from constant to constant or reg.
So, this doesn't even do the right thing for PowerPC, for scalar
operations that is: we only have rl[wd]imi for this, and nothing that
uses a register for the mask instead. Not that it will hurt much at all
(if anything) in practice, but :-)
OTOH for vectors we have vsel/xxsel, which always uses a register for
the mask.
On yet another hand, the formulation with two XORs is just obfuscation,
for RTL. RTL very much does not have the rule that fewer ops is better.
So, ideally we will never get this nonsense in RTL at all. Probably the
simplest / best way to get there is to not have it in Gimple either, and
instead just use some "select" operation there, which can be optimised
much better anyway?
And yeah that will be GCC 13 stuff :-(
Segher
Re: [PATCH] aix: handle 64bit inodes for include directories
On 12/30/2021 9:43 AM, David Edelsohn wrote: Hi, Jeff Is the revised patch from Clement okay? I *think* so. I don't think it's likely to affect any other system as a host, build or target. I'm not entirely sure it's right for canadian crosses to/from involving aix, but that seems like a bit of a corner case these days that we could iterate on if it's not 100% correct. I'll ACK for the trunk. Jeff
Ping^3: [PATCH, rs6000 V2] rotate and mask constants [PR94393]
Ping. On 11/22/21 1:38 PM, Pat Haugen via Gcc-patches wrote: > Updated version of the patch. Changes made from original are updated > commentary to hopefully aid readability, no functional changes. > > > Implement more two insn constants. rotate_and_mask_constant covers > 64-bit constants that can be formed by rotating a 16-bit signed > constant, rotating a 16-bit signed constant masked on left or right > (rldicl and rldicr), rotating a 16-bit signed constant masked by > rldic, and unusual "lis; rldicl" and "lis; rldicr" patterns. All the > values possible for DImode rs6000_is_valid_and_mask are covered. > > Bootstrapped and regression tested on powerpc64(32/64) and powerpc64le. > Ok for master? > > -Pat > > > 2021-11-22 Alan Modra > Pat Haugen > > PR 94393 > gcc/ > * config/rs6000/rs6000.c (rotate_di, is_rotate_positive_constant, > is_rotate_negative_constant, rotate_and_mask_constant): New functions. > (num_insns_constant_multi, rs6000_emit_set_long_const): Use it here. > * config/rs6000/rs6000.md (*movdi_internal64+1 splitter): Delete. > gcc/testsuite/ > * gcc.target/powerpc/rot_cst.h, > * gcc.target/powerpc/rot_cst1.c, > * gcc.target/powerpc/rot_cst2.c: New tests. >
Re: [PATCH] convert (xor (and (xor A B) C) A) to (ior (and A ~C) (and B C)) [PR90323]
On Thu, Dec 30, 2021 at 09:22:51AM -0700, Jeff Law wrote: > On 12/28/2021 6:27 PM, Xionghu Luo via Gcc-patches wrote: > > PR 90323 > > * simplify-rtx.c (simplify_context::simplify_binary_operation_1): > > Relax > > C from constant to constant or reg. > > > >gcc/testsuite/ChangeLog: > > > > * gcc.target/powerpc/pr90323.c: New test. > If C is not a constant and the target does not have and-complement > instructions, then this is likely worse than the original. If you want > to do this transformation, then you probably need to be checking target > costs. It even then is still not worse on any modern superscalar machine! Segher
Re: [PATCH] Testsuite: Add btf-dataset option for RISC-V.
On Thu, 30 Dec 2021 08:28:34 PST (-0800), gcc-patches@gcc.gnu.org wrote:
On 12/29/2021 8:02 PM, jiawei wrote:
Add -msmall-data-limit option to put global and static data into right
section and generate 'btt_info' on RISC-V target.
BTF (BPF Type Format) is the metadata format which encodes the debug info
related to BPF program/map, more details on:
https://www.kernel.org/doc/html/latest/bpf/index.html#bpf-type-format-btf
gcc/testsuite/ChangeLog:
* gcc.dg/debug/btf/btf-datasec-1.c: Add riscv target support.
Is the goal here to get the variable "d" out of the small data section
and into the standard data section? It's not clear from your description .
Neither an ACK nor a NAK at this point. I need to understand better
what you're trying to accomplish.
IIUC that's what this is doing, though the commit message isn't clear at
all. That saind, it might be better to do something like
diff --git a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
index dbb236bbda1..c0ad77d40aa 100644
--- a/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
+++ b/gcc/testsuite/gcc.dg/debug/btf/btf-datasec-1.c
@@ -22,9 +22,9 @@
/* { dg-final { scan-assembler-times "0\[\t \]+\[^\n\]*bts_offset" 7 } } */
/* Check that strings for each DATASEC have been added to the BTF string table. */
-/* { dg-final { scan-assembler-times "ascii \".data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
-/* { dg-final { scan-assembler-times "ascii \".bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?data.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?rodata.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
+/* { dg-final { scan-assembler-times "ascii \".[s]?bss.0\"\[\t
\]+\[^\n\]*btf_aux_string" 1 } } */
int a;
long long b;
as whether specific symbols end up in .data or .sdata is really just an
optimization and either should be sufficiently correct.
IIRC some targets have other flavors of these, PPC's .sdata2 comes to
mind. Not sure if we'd need that to drop their -msdata=none flag.
Re: [PATCH] aix: handle 64bit inodes for include directories
Hi, Jeff Is the revised patch from Clement okay? Thanks, David On Tue, Aug 24, 2021 at 3:59 AM CHIGOT, CLEMENT wrote: > > >>> So my worry here is this is really a host property -- ie, this is > >>> behavior of where GCC runs, not the target for which GCC is generating > >>> code. > >>> > >>> That implies that the change in aix.h is wrong. aix.h is for the > >>> target, not the host -- you don't want to define something like > >>> HOST_STAT_FOR_64BIT_INODES there. > >>> > >>> You'd want to be triggering this behavior via a host fragment, x-aix, or > >>> better yet via an autoconf test. > >> Indeed, would this version be better ? I'm not sure about the configure > >> test. > >> But as we are retrieving the size of dev_t and ino_t just above, I'm > >> assuming > >> that the one being used in stat directly. At least, that's the case on > >> AIX, and > >> this test is only made for AIX. > > It's a clear improvement. It's still checking for the aix target though: > > > > +# Select the right stat being able to handle 64bit inodes, if needed. > > +if test "$enable_largefile" != no; then > > + case "$target" in > > +*-*-aix*) > > + if test "$ac_cv_sizeof_ino_t" == "4" -a "$ac_cv_sizeof_dev_t" == > > 4; then > > + > > +$as_echo "#define HOST_STAT_FOR_64BIT_INODES stat64x" >>confdefs.h > > + > > + fi;; > > + esac > > +fi > > > > Again, we're dealing with a host property. You might be able to just > > change $target above to $host. Hmm, that makes me wonder about canadian > > crosses where host != build.We may need to do this for both the aix > > host and aix build. > > Yes, my bad, I've updated the case. I don't know if there is a usual way > to check both $build and $host. I've tried to avoid code duplication so > tell me if it's okay or if you'd rather have a case for $build and one > for $host. > > Thanks, > Clément
Re: [PATCH] libiberty: support digits in cpp mangled clone names
On 12/16/2021 3:40 AM, lsix--- via Gcc-patches wrote: From: Lancelot SIX Currently libiberty fails to demangle the name of cloned functions if the clone-type-identifier contains numbers. This can be observed with the following example: $ cat > ex.cc
Re: [PATCH] regrename: Fix -fcompare-debug issue in find_rename_reg [PR103756]
On 12/29/2021 3:19 AM, Jakub Jelinek wrote: Hi! The r12-5978 change caused a -fcompare-debug issue, because without -g a chain might start with a noop move, but with -g there could be one or more DEBUG_INSNs in the chain before the noop move and so regrename could make different decisions between -g and -g0. Note, I must say I don't really understand the original change much, if we want to make sure the noop moves are removed, couldn't regrename during building of those du chains simply remove the noop moves instead? Anyway, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2021-12-28 Jakub Jelinek PR rtl-optimization/103756 * regrename.c (find_rename_reg): Test noop_move_p on the first non-debug insn in the chain rather than on the first insn. * g++.dg/opt/pr103756.C: New test. Sadly I wasn't ever able to trigger a nop-move in this code to investigate how the nop-move more thoroughly. IIRC Jojo indicated it occurred with some local changes he was playing with. The patch is fine, of course. jeff
Re: [PATCH] convert (xor (and (xor A B) C) A) to (ior (and A ~C) (and B C)) [PR90323]
On 12/30/2021 9:27 AM, Jakub Jelinek wrote:
On Thu, Dec 30, 2021 at 09:22:51AM -0700, Jeff Law via Gcc-patches wrote:
On 12/28/2021 6:27 PM, Xionghu Luo via Gcc-patches wrote:
Bootstrapped and regtested on powerpc64le-linux-gnu {P10,P9}
powerpc64-linux-gnu {P8, P7} and X86. OK for master?
gcc/ChangeLog:
PR 90323
* simplify-rtx.c (simplify_context::simplify_binary_operation_1): Relax
C from constant to constant or reg.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr90323.c: New test.
If C is not a constant and the target does not have and-complement
instructions, then this is likely worse than the original. If you want to
do this transformation, then you probably need to be checking target costs.
I'm not sure we can check costs because what simplify_* is fed especially
during combine might be far from what is a valid instruction and checking
costs on something that isn't valid could lead to bogus results.
Perhaps check if the andnot optab exist for the mode, except we don't have
such an optab...
Should we just defer this to the next stage1? That would give plenty of
time to wire up an optab and test it on the appropriate targets.
jeff
Re: [PATCH] Testsuite: Add btf-dataset option for RISC-V.
On 12/29/2021 8:02 PM, jiawei wrote: Add -msmall-data-limit option to put global and static data into right section and generate 'btt_info' on RISC-V target. BTF (BPF Type Format) is the metadata format which encodes the debug info related to BPF program/map, more details on: https://www.kernel.org/doc/html/latest/bpf/index.html#bpf-type-format-btf gcc/testsuite/ChangeLog: * gcc.dg/debug/btf/btf-datasec-1.c: Add riscv target support. Is the goal here to get the variable "d" out of the small data section and into the standard data section? It's not clear from your description . Neither an ACK nor a NAK at this point. I need to understand better what you're trying to accomplish. jeff
Re: [PATCH] convert (xor (and (xor A B) C) A) to (ior (and A ~C) (and B C)) [PR90323]
On Thu, Dec 30, 2021 at 09:22:51AM -0700, Jeff Law via Gcc-patches wrote:
> On 12/28/2021 6:27 PM, Xionghu Luo via Gcc-patches wrote:
> > Bootstrapped and regtested on powerpc64le-linux-gnu {P10,P9}
> > powerpc64-linux-gnu {P8, P7} and X86. OK for master?
> >
> > gcc/ChangeLog:
> >
> > PR 90323
> > * simplify-rtx.c (simplify_context::simplify_binary_operation_1): Relax
> > C from constant to constant or reg.
> >
> > gcc/testsuite/ChangeLog:
> >
> > * gcc.target/powerpc/pr90323.c: New test.
> If C is not a constant and the target does not have and-complement
> instructions, then this is likely worse than the original. If you want to
> do this transformation, then you probably need to be checking target costs.
I'm not sure we can check costs because what simplify_* is fed especially
during combine might be far from what is a valid instruction and checking
costs on something that isn't valid could lead to bogus results.
Perhaps check if the andnot optab exist for the mode, except we don't have
such an optab...
Jakub
Re: [PATCH] libcpp: Fix up ##__VA_OPT__ handling [PR89971]
On 12/30/2021 2:24 AM, Jakub Jelinek via Gcc-patches wrote: Hi! In the following testcase we incorrectly error about pasting / token with padding token (which is a result of __VA_OPT__); instead we should like e.g. for ##arg where arg is empty macro argument clear PASTE_LEFT flag of the previous token if __VA_OPT__ doesn't add any real tokens (which can happen either because the macro doesn't have any tokens passed to ... (i.e. __VA_ARGS__ expands to empty) or when __VA_OPT__ doesn't have any tokens in between ()s). Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2021-12-30 Jakub Jelinek PR preprocessor/89971 libcpp/ * macro.c (replace_args): For ##__VA_OPT__, if __VA_OPT__ expands to no tokens at all, drop PASTE_LEFT flag from the previous token. gcc/testsuite/ * c-c++-common/cpp/va-opt-9.c: New test. OK jeff
Re: [PATCH] convert (xor (and (xor A B) C) A) to (ior (and A ~C) (and B C)) [PR90323]
On 12/28/2021 6:27 PM, Xionghu Luo via Gcc-patches wrote:
Bootstrapped and regtested on powerpc64le-linux-gnu {P10,P9}
powerpc64-linux-gnu {P8, P7} and X86. OK for master?
gcc/ChangeLog:
PR 90323
* simplify-rtx.c (simplify_context::simplify_binary_operation_1): Relax
C from constant to constant or reg.
gcc/testsuite/ChangeLog:
* gcc.target/powerpc/pr90323.c: New test.
If C is not a constant and the target does not have and-complement
instructions, then this is likely worse than the original. If you want
to do this transformation, then you probably need to be checking target
costs.
Jeff
[RFC PATCH] i386: Introduce V2QImode vectorized arithmetic [PR103861]
This patch adds basic V2QImode infrastructure and V2QImode arithmetic
operations (plus, minus and neg). The patched compiler can emit SSE
vectorized QImode operations (e.g. PADDB) with partial QImode vector,
and also synthesized double HI/LO QImode operations with integer registers.
The testcase:
typedef char __v2qi __attribute__ ((__vector_size__ (2)));
__v2qi plus (__v2qi a, __v2qi b) { return a + b; };
compiles with -O2 to:
movl%edi, %edx
movl%esi, %eax
addb%sil, %dl
addb%ah, %dh
movl%edx, %eax
ret
which is much better than what the unpatched compiler produces:
movl%edi, %eax
movl%esi, %edx
xorl%ecx, %ecx
movb%dil, %cl
movsbl %dh, %edx
movsbl %ah, %eax
addl%edx, %eax
addb%sil, %cl
movb%al, %ch
movl%ecx, %eax
ret
The V2QImode vectorization does not require vector registers, so it can
be enabled by default also for 32-bit targets without SSE.
The patch also enables vectorized V2QImode sign/zero extends.
The reason for RFC are several warning failures in
Wstringop-overflow-*.[Cc] as a result of an unwanted vectorization. I
tried to sprinkle vect_slp_v2qi_store_align xfails around, but
unfortunately without success, since I have no idea about the details
of these tests.
I didn't want to introduce testsuite FAILs, so help with these failing
tests is greatly appreciated.
Anyway, the above example shows the potential of V2QImode
vectorization. There are additional similar optimizations possible
(e.g. shifts with GPRs) in addition to SSE instructions on partial
V2QI vectors.
Patch is bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
2021-12-30 Uroš Bizjak
gcc/ChangeLog:
PR target/103861
* config/i386/i386.h (VALID_SSE2_REG_MOODE): Add V2QImode.
(VALID_INT_MODE_P): Ditto.
* config/i386/i386.c (ix86_secondary_reload): Handle
V2QImode reloads from SSE register to memory.
(vector_mode_supported_p): Always return true for V2QImode.
* config/i386/i386.md (*subqi_ext_2): New insn pattern.
(*negqi_ext_2): Ditto.
* config/i386/mmx.md (movv2qi): New expander.
(movmisalignv2qi): Ditto.
(*movv2qi_internal): New insn pattern.
(*pushv2qi2): Ditto.
(negv2qi2 and splitters): Ditto.
(v2qi3 and splitters): Ditto.
gcc/testsuite/ChangeLog:
PR target/103861
* gcc.target/i386/pr103861.c: New test.
* gcc.target/i386/pr92658-avx512vl.c:
Remove vpmovqb scan-assembler xfail.
* gcc.target/i386/pr92658-sse4.c:
Remove pmovzxbq scan-assembler xfail.
* gcc.target/i386/pr92658-sse4-2.c:
Remove pmovsxbq scan-assembler xfail.
* gcc.target/i386/warn-vect-op-2.c: Adjust warnings.
diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
index ec155826310..4e02b26b44f 100644
--- a/gcc/config/i386/i386.c
+++ b/gcc/config/i386/i386.c
@@ -19306,7 +19306,7 @@ ix86_secondary_reload (bool in_p, rtx x, reg_class_t
rclass,
}
/* Require movement to gpr, and then store to memory. */
- if ((mode == HFmode || mode == HImode)
+ if ((mode == HFmode || mode == HImode || mode == V2QImode)
&& !TARGET_SSE4_1
&& SSE_CLASS_P (rclass)
&& !in_p && MEM_P (x))
@@ -22082,6 +22082,8 @@ ix86_vector_mode_supported_p (machine_mode mode)
if ((TARGET_3DNOW || TARGET_MMX_WITH_SSE)
&& VALID_MMX_REG_MODE_3DNOW (mode))
return true;
+ if (mode == V2QImode)
+return true;
return false;
}
diff --git a/gcc/config/i386/i386.h b/gcc/config/i386/i386.h
index 398f7513752..3adb1cb22c6 100644
--- a/gcc/config/i386/i386.h
+++ b/gcc/config/i386/i386.h
@@ -1039,7 +1039,8 @@ extern const char *host_detect_local_cpu (int argc, const
char **argv);
((MODE) == V16QImode || (MODE) == V8HImode || (MODE) == V2DFmode \
|| (MODE) == V8HFmode || (MODE) == V4HFmode || (MODE) == V2HFmode \
|| (MODE) == V4QImode || (MODE) == V2HImode || (MODE) == V1SImode \
- || (MODE) == V2DImode || (MODE) == DFmode || (MODE) == HFmode)
+ || (MODE) == V2DImode || (MODE) == V2QImode || (MODE) == DFmode \
+ || (MODE) == HFmode)
#define VALID_SSE_REG_MODE(MODE) \
((MODE) == V1TImode || (MODE) == TImode \
@@ -1072,7 +1073,7 @@ extern const char *host_detect_local_cpu (int argc, const
char **argv);
|| (MODE) == SDmode || (MODE) == DDmode \
|| (MODE) == HFmode || (MODE) == HCmode \
|| (MODE) == V2HImode || (MODE) == V2HFmode \
- || (MODE) == V1SImode || (MODE) == V4QImode \
+ || (MODE) == V1SImode || (MODE) == V4QImode || (MODE) == V2QImode \
|| (TARGET_64BIT\
&& ((MODE) == TImode || (MODE) == CTImode \
|| (MODE) == TFmode || (MODE) ==
Re: [PATCH] fixed testcase fail gcc.dg/analyzer/pr103526.c leak
On 12/29/2021 7:21 PM, shi...@iscas.ac.cn wrote: From: LiaoShihua following 'false' branch in line 20, 'tmp.word_state' leaks in line 26. So free 'tmp.word_state' before return 'rval'. gcc/testsuite\ChangeLog: * gcc.dg/analyzer/pr103526.c: Umm, isn't the whole point of the test to verify that the analyzer properly detects the non-free'd pointer as escaping via the return value? Jeff
Re: [PATCH] emit-rtl: Fix a -fcompare-debug issue due to var-tracking [PR103808]
On 12/29/2021 3:35 AM, Jakub Jelinek wrote:
Hi!
We get a -fcompare-debug FAIL on the following testcase. The problem is
that during cprop we get when a TImode pseudo holding x is being
constructed:
(debug_insn 111 59 103 7 (var_location:TI D#2 (clobber (const_int 0 [0]))) -1
(nil))
(insn 103 111 110 7 (clobber (reg/v:TI 89 [ x ])) "pr103808.c":8:9 -1
(nil))
(debug_insn 110 103 104 7 (var_location:TI D#2 (subreg:TI (reg:DI 111 [ x ])
0)) -1
(nil))
(insn 104 110 109 7 (set (subreg:DI (reg/v:TI 89 [ x ]) 0)
(reg:DI 111 [ x ])) "pr103808.c":8:9 80 {*movdi_internal}
(expr_list:REG_DEAD (reg:DI 111 [ x ])
(nil)))
Now, during RA that paradoxical subreg in a debug insn obviously can't
affect where pseudo 111 is allocated and RA puts it into the bp register,
so we have:
(debug_insn 110 111 109 4 (var_location:TI D#2 (reg:TI 6 bp [orig:111 x ]
[111])) -1
(nil))
Now, during var-tracking when we for:
(debug_insn 25 23 26 3 (var_location:TI x (concatn/v:TI [
(reg:DI 6 bp [orig:111 x ] [111])
(subreg:DI (debug_expr:TI D#2) 8)
])) "pr103808.c":8:9 -1
(nil))
try to simplify the highpart subreg of bp, gen_rtx_REG_offset is called in:
if (HARD_REGISTER_NUM_P (final_regno))
{
rtx x = gen_rtx_REG_offset (op, outermode, final_regno,
subreg_memory_offset (outermode,
innermode, byte));
and that unfortunately sets REG_ATTRS on stack_pointer_rtx, because
gen_rtx_REG_offset uses gen_rtx_REG which for Pmode STACK_POINTER_REGNUM
returns stack_pointer_rtx rather than newly created register.
The clobbering of REG_ATTRS on the shared stack_pointer_rtx then shows up
in the dumps as (reg/f:DI 7 sp [ x+8 ]) instead of (reg/f:DI 7 sp)
that shows up without var-tracking.
Clobbering of REG_ATTRS on the shared *_pointer_rtx looks just wrong.
So, IMHO either simplify_gen_subreg -> gen_rtx_REG_offset should call
gen_raw_REG to make sure we get a new non-shared REG we can set REG_ATTRS
on, or we should make sure that we don't overwrite the REG_ATTRS on the
shared REGs (but then simplify_gen_subreg shouldn't try to overwrite
ORIGINAL_REGNO on those either).
For non-DEBUG_INSNs, I'd hope this never happens, the RA shouldn't allocate
multi-word regs overlapping with stack pointer, hard frame pointer etc.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-12-28 Jakub Jelinek
PR debug/103808
* emit-rtl.c (gen_rtx_REG_offset): Use gen_raw_REG instead of
gen_rtx_REG.
* gcc.dg/pr103808.c: New test.
A comment on why we use gen_raw_REG seems appropriate. OK with that change.
jeff
Re: [PATCH] c-family: Use BULTINS_LOCATION for predefined macros changed upon optimize or target pragmas [PR103012]
On 12/29/2021 3:01 AM, Jakub Jelinek via Gcc-patches wrote: Hi! The following testcases ICE when an optimize or target pragma is followed by a long line (4096+ chars). This is because on such long lines we can't use columns anymore, but the cpp_define calls performed by c_cpp_builtins_optimize_pragma or from the backend hooks for target pragma are done on temporary buffers and expect to get columns from whatever line they appear on (which happens to be the long line after optimize/target pragma), and we run into: #0 fancy_abort (file=0x3abec67 "../../libcpp/line-map.c", line=502, function=0x3abecfc "linemap_add") at ../../gcc/diagnostic.c:1986 #1 0x02e7c335 in linemap_add (set=0x77fca000, reason=LC_RENAME, sysp=0, to_file=0x41287a0 "pr103012.i", to_line=3) at ../../libcpp/line-map.c:502 #2 0x02e7cc24 in linemap_line_start (set=0x77fca000, to_line=3, max_column_hint=128) at ../../libcpp/line-map.c:827 #3 0x02e7ce2b in linemap_position_for_column (set=0x77fca000, to_column=1) at ../../libcpp/line-map.c:898 #4 0x02e771f9 in _cpp_lex_direct (pfile=0x40c3b60) at ../../libcpp/lex.c:3592 #5 0x02e76c3e in _cpp_lex_token (pfile=0x40c3b60) at ../../libcpp/lex.c:3394 #6 0x02e610ef in lex_macro_node (pfile=0x40c3b60, is_def_or_undef=true) at ../../libcpp/directives.c:601 #7 0x02e61226 in do_define (pfile=0x40c3b60) at ../../libcpp/directives.c:639 #8 0x02e610b2 in run_directive (pfile=0x40c3b60, dir_no=0, buf=0x7fffd430 "__OPTIMIZE__ 1\n", count=14) at ../../libcpp/directives.c:589 #9 0x02e650c1 in cpp_define (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2513 #10 0x02e65100 in cpp_define_unused (pfile=0x40c3b60, str=0x2f784d1 "__OPTIMIZE__") at ../../libcpp/directives.c:2522 #11 0x00f50685 in c_cpp_builtins_optimize_pragma (pfile=0x40c3b60, prev_tree=, cur_tree=) at ../../gcc/c-family/c-cppbuiltin.c:600 assertion that LC_RENAME doesn't happen first. I think the right fix is emit those predefined macros upon optimize/target pragmas with BUILTINS_LOCATION, like we already do for those macros at the start of the TU, they don't appear in columns of the next line after it. Another possibility would be to force them at the location of the pragma. Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? 2021-12-28 Jakub Jelinek PR c++/103012 gcc/ * config/i386/i386-c.c (ix86_pragma_target_parse): Perform cpp_define/cpp_undef calls with forced token locations BUILTINS_LOCATION. * config/arm/arm-c.c (arm_pragma_target_parse): Likewise. * config/aarch64/aarch64-c.c (aarch64_pragma_target_parse): Likewise. * config/s390/s390-c.c (s390_pragma_target_parse): Likewise. gcc/c-family/ * c-cppbuiltin.c (c_cpp_builtins_optimize_pragma): Perform cpp_define_unused/cpp_undef calls with forced token locations BUILTINS_LOCATION. gcc/testsuite/ PR c++/103012 * g++.dg/cpp/pr103012.C: New test. * g++.target/i386/pr103012.C: New test. OK jeff
Re: [PATCH] shrink-wrapping: Fix up prologue block discovery [PR103860]
On 12/30/2021 3:08 AM, Segher Boessenkool wrote: Hi! On Thu, Dec 30, 2021 at 10:43:32AM +0100, Jakub Jelinek wrote: The following testcase is miscompiled, because a prologue which contains subq $8, %rsp instruction is emitted at the start of a basic block which contains conditional jump that depends on flags register set in an earlier basic block, the prologue instruction then clobbers those flags. Normally this case is checked by can_get_prologue predicate, but this is done only at the start of the loop. If we update pro later in the loop (because some bb shouldn't be duplicated) and then don't push anything further into vec and the vec is already empty (this can happen when the new pro is already in bb_with bitmask and either has no successors (that is the case in the testcase where that bb ends with a trap) or all the successors are already in bb_with, then the loop doesn't iterate further and can_get_prologue will not be checked. The following simple patch makes sure we call can_get_prologue even after the last former iteration when vec is already empty and only break from the loop afterwards (and only if the updating of pro done because of !can_get_prologue didn't push anything into vec again). Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? That looks good, and very simple, thanks! git blame says I wrote 69.9% of shrink-wrap.c, but I am not maintainer of it, so I cannot approve your patch -- but it is fine afaics. Well, we should probably fix the maintainer status of shrink-wrap.c. In the mean time, based on Segher's review, this is fine for the trunk. jeff
Re: [PATCH] shrink-wrapping: Fix up prologue block discovery [PR103860]
Hi! On Thu, Dec 30, 2021 at 10:43:32AM +0100, Jakub Jelinek wrote: > The following testcase is miscompiled, because a prologue which > contains subq $8, %rsp instruction is emitted at the start of > a basic block which contains conditional jump that depends on > flags register set in an earlier basic block, the prologue instruction > then clobbers those flags. > Normally this case is checked by can_get_prologue predicate, but this > is done only at the start of the loop. If we update pro later in the > loop (because some bb shouldn't be duplicated) and then don't push > anything further into vec and the vec is already empty (this can happen > when the new pro is already in bb_with bitmask and either has no successors > (that is the case in the testcase where that bb ends with a trap) or > all the successors are already in bb_with, then the loop doesn't iterate > further and can_get_prologue will not be checked. > > The following simple patch makes sure we call can_get_prologue even after > the last former iteration when vec is already empty and only break from > the loop afterwards (and only if the updating of pro done because of > !can_get_prologue didn't push anything into vec again). > > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk? That looks good, and very simple, thanks! git blame says I wrote 69.9% of shrink-wrap.c, but I am not maintainer of it, so I cannot approve your patch -- but it is fine afaics. Segher > 2021-12-30 Jakub Jelinek > > PR rtl-optimization/103860 > * shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue is > called on pro even if nothing further is pushed into vec. > > * gcc.dg/pr103860.c: New test.
[PATCH] shrink-wrapping: Fix up prologue block discovery [PR103860]
Hi!
The following testcase is miscompiled, because a prologue which
contains subq $8, %rsp instruction is emitted at the start of
a basic block which contains conditional jump that depends on
flags register set in an earlier basic block, the prologue instruction
then clobbers those flags.
Normally this case is checked by can_get_prologue predicate, but this
is done only at the start of the loop. If we update pro later in the
loop (because some bb shouldn't be duplicated) and then don't push
anything further into vec and the vec is already empty (this can happen
when the new pro is already in bb_with bitmask and either has no successors
(that is the case in the testcase where that bb ends with a trap) or
all the successors are already in bb_with, then the loop doesn't iterate
further and can_get_prologue will not be checked.
The following simple patch makes sure we call can_get_prologue even after
the last former iteration when vec is already empty and only break from
the loop afterwards (and only if the updating of pro done because of
!can_get_prologue didn't push anything into vec again).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-12-30 Jakub Jelinek
PR rtl-optimization/103860
* shrink-wrap.c (try_shrink_wrapping): Make sure can_get_prologue is
called on pro even if nothing further is pushed into vec.
* gcc.dg/pr103860.c: New test.
--- gcc/shrink-wrap.c.jj2021-06-07 09:24:57.731689612 +0200
+++ gcc/shrink-wrap.c 2021-12-29 19:16:28.114148496 +0100
@@ -781,7 +781,7 @@ try_shrink_wrapping (edge *entry_edge, r
unsigned max_grow_size = get_uncond_jump_length ();
max_grow_size *= param_max_grow_copy_bb_insns;
- while (!vec.is_empty () && pro != entry)
+ while (pro != entry)
{
while (pro != entry && !can_get_prologue (pro, prologue_clobbered))
{
@@ -791,6 +791,9 @@ try_shrink_wrapping (edge *entry_edge, r
vec.quick_push (pro);
}
+ if (vec.is_empty ())
+ break;
+
basic_block bb = vec.pop ();
if (!can_dup_for_shrink_wrapping (bb, pro, max_grow_size))
while (!dominated_by_p (CDI_DOMINATORS, bb, pro))
--- gcc/testsuite/gcc.dg/pr103860.c.jj 2021-12-29 19:19:23.047696170 +0100
+++ gcc/testsuite/gcc.dg/pr103860.c 2021-12-29 19:19:08.360902059 +0100
@@ -0,0 +1,31 @@
+/* PR rtl-optimization/103860 */
+/* { dg-do run } */
+/* { dg-options "-O3" } */
+/* { dg-additional-options "-fPIC" { target fpic } } */
+
+static int d, *e;
+int f;
+
+__attribute__((noinline)) signed char
+foo (signed char b, signed char c)
+{
+ return b + c;
+}
+
+int
+main ()
+{
+ signed char l;
+ for (l = -1; l; l = foo (l, 1))
+{
+ while (d < 0)
+ ;
+ if (d > 0)
+ {
+ f = 0;
+ *e = 0;
+ }
+}
+ d = 0;
+ return 0;
+}
Jakub
[PATCH] objc: Fix handling of break stmt inside of switch inside of ObjC foreach [PR103639]
Hi!
The r11-3302-g3696a50beeb73f changes broke the following ObjC testcase.
in_statement is either 0 (not in a looping statement), various IN_* flags
for various kinds of looping statements (or OpenMP structured blocks) or
those flags ored with IN_SWITCH_STMT when a switch appears inside of those
contexts. This is because break binds to switch in that last case, but
continue binds to the looping construct in that case.
The c_finish_bc_stmt function performs diagnostics on incorrect
break/continue uses and then checks if in_statement & IN_OBJC_FOREACH
and in that case jumps to the label provided by the caller, otherwise
emits a BREAK_STMT or CONTINUE_STMT. This is incorrect if we have
ObjC foreach with switch nested in it and break inside of that,
in_statement in that case is IN_OBJC_FOREACH | IN_SWITCH_STMT and
is_break is true. We want to handle it like other breaks inside of
switch, i.e. emit a BREAK_STMT.
The following patch fixes that.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2021-12-30 Jakub Jelinek
PR objc/103639
* c-typeck.c (c_finish_bc_stmt): For break inside of switch inside of
ObjC foreach, emit normal BREAK_STMT rather than goto to label.
2021-12-30 Iain Sandoe
PR objc/103639
* objc.dg/pr103639.m: New test.
--- gcc/c/c-typeck.c.jj 2021-12-09 15:37:27.657304583 +0100
+++ gcc/c/c-typeck.c2021-12-29 16:27:56.693351501 +0100
@@ -11257,7 +11257,8 @@ c_finish_bc_stmt (location_t loc, tree l
if (skip)
return NULL_TREE;
- else if (in_statement & IN_OBJC_FOREACH)
+ else if ((in_statement & IN_OBJC_FOREACH)
+ && !(is_break && (in_statement & IN_SWITCH_STMT)))
{
/* The foreach expander produces low-level code using gotos instead
of a structured loop construct. */
--- gcc/testsuite/objc.dg/pr103639.m.jj 2021-11-07 16:02:58.901842074 +0100
+++ gcc/testsuite/objc.dg/pr103639.m2021-12-29 21:42:08.253107653 +0100
@@ -0,0 +1,101 @@
+/* PR objc/103639 */
+/* { dg-do run } */
+/* { dg-skip-if "No NeXT fast enum. pre-Darwin9" { *-*-darwin[5-8]* } {
"-fnext-runtime" } { "" } } */
+/* { dg-xfail-run-if "Needs OBJC2 ABI" { *-*-darwin* && { lp64 && { ! objc2 }
} } { "-fnext-runtime" } { "" } } */
+/* { dg-additional-sources
"../objc-obj-c++-shared/nsconstantstring-class-impl.m" } */
+/* { dg-additional-options "-mno-constant-cfstrings" { target *-*-darwin* } }
*/
+/* { dg-additional-options "-Wno-objc-root-class" } */
+
+#import "../objc-obj-c++-shared/TestsuiteObject.m"
+#ifndef __NEXT_RUNTIME__
+#include
+#else
+#include "../objc-obj-c++-shared/nsconstantstring-class.h"
+#endif
+
+extern int printf (const char *, ...);
+#include
+
+/* A mini-array implementation that can be used to test fast
+enumeration. You create the array with some objects; you can
+mutate the array, and you can fast-enumerate it.
+ */
+@interface MyArray : TestsuiteObject
+{
+ unsigned int length;
+ id *objects;
+ unsigned long mutated;
+}
+- (id) initWithLength: (unsigned int)l objects: (id *)o;
+- (void) mutate;
+- (unsigned long)countByEnumeratingWithState: (struct
__objcFastEnumerationState *)state
+ objects:(id *)stackbuf
+ count:(unsigned long)len;
+@end
+
+@implementation MyArray : TestsuiteObject
+- (id) initWithLength: (unsigned int)l
+ objects: (id *)o
+{
+ length = l;
+ objects = o;
+ mutated = 0;
+ return self;
+}
+- (void) mutate
+{
+ mutated = 1;
+}
+- (unsigned long)countByEnumeratingWithState: (struct
__objcFastEnumerationState*)state
+objects: (id*)stackbuf
+ count: (unsigned long)len
+{
+ unsigned long i, batch_size;
+
+ /* We keep how many objects we served in the state->state counter. So the
next batch
+ will contain up to length - state->state objects. */
+ batch_size = length - state->state;
+
+ /* Make obvious adjustments. */
+ if (batch_size < 0)
+batch_size = 0;
+
+ if (batch_size > len)
+batch_size = len;
+
+ /* Copy the objects. */
+ for (i = 0; i < batch_size; i++)
+stackbuf[i] = objects[i];
+
+ state->state += batch_size;
+ state->itemsPtr = stackbuf;
+ state->mutationsPtr =
+
+ return batch_size;
+}
+@end
+
+int check = 0;
+
+int
+main()
+{
+ id *objects = malloc (sizeof (id) * 2);
+ objects[0] = @"a";
+ objects[1] = @"b";
+
+ MyArray *array = [[MyArray alloc] initWithLength: 2 objects: objects];
+
+ int someVar = 0;
+ for (id object in array) {
+switch (someVar) {
+ case 0:
+ break;
+}
+++check;
+ }
+
+ if (check != 2)
+abort ();
+ return 0;
+}
Jakub
[PATCH] libcpp: Fix up ##__VA_OPT__ handling [PR89971]
Hi!
In the following testcase we incorrectly error about pasting / token
with padding token (which is a result of __VA_OPT__); instead we should
like e.g. for ##arg where arg is empty macro argument clear PASTE_LEFT
flag of the previous token if __VA_OPT__ doesn't add any real tokens
(which can happen either because the macro doesn't have any tokens
passed to ... (i.e. __VA_ARGS__ expands to empty) or when __VA_OPT__
doesn't have any tokens in between ()s).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok
for trunk?
2021-12-30 Jakub Jelinek
PR preprocessor/89971
libcpp/
* macro.c (replace_args): For ##__VA_OPT__, if __VA_OPT__ expands
to no tokens at all, drop PASTE_LEFT flag from the previous token.
gcc/testsuite/
* c-c++-common/cpp/va-opt-9.c: New test.
--- libcpp/macro.c.jj 2021-12-01 10:07:46.774663941 +0100
+++ libcpp/macro.c 2021-12-29 15:22:09.393455799 +0100
@@ -2094,8 +2094,14 @@ replace_args (cpp_reader *pfile, cpp_has
tokens_buff_add_token (buff, virt_locs,
t, t->src_loc, t->src_loc,
NULL, 0);
+ continue;
}
- else if (src->flags & PASTE_LEFT)
+ if (start && paste_flag == start && (*start)->flags & PASTE_LEFT)
+ /* If __VA_OPT__ expands to nothing (either because __VA_ARGS__
+ is empty or because it is __VA_OPT__() ), drop PASTE_LEFT
+ flag from previous token. */
+ copy_paste_flag (pfile, start, >avoid_paste);
+ if (src->flags & PASTE_LEFT)
{
/* Don't avoid paste after all. */
while (paste_flag && paste_flag != start
--- gcc/testsuite/c-c++-common/cpp/va-opt-9.c.jj2021-12-29
15:30:48.231203467 +0100
+++ gcc/testsuite/c-c++-common/cpp/va-opt-9.c 2021-12-29 15:40:12.676317163
+0100
@@ -0,0 +1,20 @@
+/* PR preprocessor/89971 */
+/* { dg-do compile } */
+/* { dg-options "-std=gnu99" { target c } } */
+/* { dg-options "-std=c++20" { target c++ } } */
+
+int a, c;
+#define m1(...) a /##__VA_OPT__(b) c
+#define m2(...) a /##__VA_OPT__() c
+#define m3(...) a##__VA_OPT__()##b = 1
+#define m4(...) a##__VA_OPT__(b c d)##e = 2
+
+int
+foo (void)
+{
+ int d = m1();
+ int e = m2(1);
+ int m3(1 2 3);
+ int m4();
+ return d + e + ab + ae;
+}
Jakub
SV: SV: [commited] jit: Support for global rvalue initialization and constructors
Oh ye no it is probably terrible missuse trying to write into the constructor.
=)
Maybe I should look into barring that entrypoint for constructors. Kinda
overlooked
that rvalue arrays could be used as lvalues.
/Petter
Från: Antoni Boucher
Skickat: den 30 december 2021 02:40
Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org; gcc-patches@gcc.gnu.org
Ämne: Re: SV: [commited] jit: Support for global rvalue initialization and
constructors
Oh, sorry, I meant when you have an array not in a local variable, and
you try to assign to an index of this array.
Something like:
gcc_jit_rvalue *ctor = gcc_jit_context_new_array_constructor
(ctxt,0,int50arr_type,6,values);
gcc_jit_block_add_assignment (block, 0,
gcc_jit_context_new_array_access(NULL, ctor,
gcc_jit_context_zero(int_type)), some_value);
Le jeudi 30 décembre 2021 à 01:16 +, Petter Tomner a écrit :
> Could you be more specific? I tried the equivalent of:
>
> /* int [50] foobar = {1,2,3,4};
> int [50] foo() { int arr[50];
> arr = (int [50]){-1,-2,-3,-4,-5,-6};
> arr = foobar;
> arr = (int [50]){1,2,3,4,5,6};
> arr[6] = 1234;
> return arr;}
>
> N.B: Not a typo, returning an array.
> */
>
> in test-local-init-rvalue.c with a global and local "arr" and it ran
> fine. (See attachment).
>
> Regards, Petter
>
>
> Från: Antoni Boucher
> Skickat: den 29 december 2021 23:45
> Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> gcc-patches@gcc.gnu.org
> Ämne: Re: [commited] jit: Support for global rvalue initialization
> and constructors
>
> I realized that trying to do an assignment to an array created by the
> new array constructor API will result in a "gimplification failed"
> error:
>
> libgccjit.so: error: gimplification failed
> 0x7fa3a441e5d3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15964
> 0x7fa3a442b1ab gimplify_modify_expr
> ../../../gcc/gcc/gimplify.c:5975
> 0x7fa3a441ac4c gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:14951
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a441bca3 gimplify_statement_list
> ../../../gcc/gcc/gimplify.c:2014
> 0x7fa3a441bca3 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15396
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a441f000 gimplify_bind_expr
> ../../../gcc/gcc/gimplify.c:1427
> 0x7fa3a441adc6 gimplify_expr(tree_node**, gimple**, gimple**, bool
> (*)(tree_node*), int)
> ../../../gcc/gcc/gimplify.c:15152
> 0x7fa3a441e63c gimplify_stmt(tree_node**, gimple**)
> ../../../gcc/gcc/gimplify.c:7026
> 0x7fa3a4420671 gimplify_body(tree_node*, bool)
> ../../../gcc/gcc/gimplify.c:16197
> 0x7fa3a4420b3c gimplify_function_tree(tree_node*)
> ../../../gcc/gcc/gimplify.c:16351
> 0x7fa3a419fe5e gcc::jit::playback::function::postprocess()
> ../../../gcc/gcc/jit/jit-playback.c:1909
> 0x7fa3a41a13dc gcc::jit::playback::context::replay()
> ../../../gcc/gcc/jit/jit-playback.c:3250
>
>
> Should an assignment to such a value be supported?
>
> Le mercredi 15 décembre 2021 à 19:19 +, Petter Tomner a écrit :
> > Oh ye I accidentally dropped that in the merge thank you.
> >
> > I believe there is an implicit "global:" in the top of each version
> > scope, so it shouldn't
> > matter other than looking a bit deviant.
> >
> > Regards,
> > Petter
> >
> > Från: Antoni Boucher
> > Skickat: den 15 december 2021 15:19
> > Till: Petter Tomner; David Malcolm; j...@gcc.gnu.org;
> > gcc-patches@gcc.gnu.org
> > Ämne: Re: [commited] jit: Support for global rvalue initialization
> > and constructors
> >
> > Hi Petter.
> > I believe you have forgotten the line `global:` in the file
> > `gcc/jit/libgccjit.map`.
> > I'm not sure what this line does, but it is there for all other
> > ABI.
> > David: What do you think?
> > Regards.
> >
> > Le mardi 14 décembre 2021 à 17:22 +, Petter Tomner via Jit a
> > écrit :
> > > Hi!
> > >
> > > I have pushed the patch for rvalue initialization and ctors for
> > > libgccjit, for ABI 19.
> > >
> > > Please see attached patch.
> > >
> > > Regards,
> > > Petter
> > >
> >
> >
>
>
