Re: [PATCH][AArch64] Improve immediate expansion [PR106583]
Wilco Dijkstra writes:
> Improve immediate expansion of immediates which can be created from a
> bitmask immediate and 2 MOVKs. This reduces the number of 4-instruction
> immediates in SPECINT/FP by 10-15%.
>
> Passes regress, OK for commit?
>
> gcc/ChangeLog:
>
> PR target/106583
> * config/aarch64/aarch64.cc (aarch64_internal_mov_immediate)
> Add support for a bitmask immediate with 2 MOVKs.
>
> gcc/testsuite:
> PR target/106583
> * gcc.target/aarch64/pr106583.c: Add new test.
Nice.
Did you consider handling the case where the movks aren't for
consecutive bitranges? E.g. the patch handles:
0x12345678
and:
0x12345678
but it looks like it would be fairly easy to extend it to:
0x12345678
too.
Also, could you commonise:
val2 = val & ~mask;
if (val2 != val && aarch64_bitmask_imm (val2, mode))
break;
val2 = val | mask;
if (val2 != val && aarch64_bitmask_imm (val2, mode))
break;
val2 = val2 & ~mask;
val2 = val2 | (((val2 >> 32) | (val2 << 32)) & mask);
if (val2 != val && aarch64_bitmask_imm (val2, mode))
break;
? It's subtle enough that IMO it'd be better not to cut-&-paste it.
Thanks,
Richard
> ---
>
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index
> 926e81f028c82aac9a5fecc18f921f84399c24ae..1601d11710cb6132c80a77bb4fe2f8429519aa5a
> 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -5568,7 +5568,7 @@ aarch64_internal_mov_immediate (rtx dest, rtx imm, bool
> generate,
>one_match = ((~val & mask) == 0) + ((~val & (mask << 16)) == 0) +
> ((~val & (mask << 32)) == 0) + ((~val & (mask << 48)) == 0);
>
> - if (zero_match != 2 && one_match != 2)
> + if (zero_match < 2 && one_match < 2)
> {
>/* Try emitting a bitmask immediate with a movk replacing 16 bits.
> For a 64-bit bitmask try whether changing 16 bits to all ones or
> @@ -5600,6 +5600,43 @@ aarch64_internal_mov_immediate (rtx dest, rtx imm,
> bool generate,
> }
> }
>
> + /* Try a bitmask plus 2 movk to generate the immediate in 3 instructions.
> */
> + if (zero_match + one_match == 0)
> +{
> + mask = 0x;
> +
> + for (i = 0; i < 64; i += 16)
> + {
> + val2 = val & ~mask;
> + if (aarch64_bitmask_imm (val2, mode))
> + break;
> + val2 = val | mask;
> + if (aarch64_bitmask_imm (val2, mode))
> + break;
> + val2 = val2 & ~mask;
> + val2 = val2 | (((val2 >> 32) | (val2 << 32)) & mask);
> + if (aarch64_bitmask_imm (val2, mode))
> + break;
> +
> + mask = (mask << 16) | (mask >> 48);
> + }
> +
> + if (i != 64)
> + {
> + if (generate)
> + {
> + emit_insn (gen_rtx_SET (dest, GEN_INT (val2)));
> + emit_insn (gen_insv_immdi (dest, GEN_INT (i),
> +GEN_INT ((val >> i) & 0x)));
> + i = (i + 16) & 63;
> + emit_insn (gen_insv_immdi (dest, GEN_INT (i),
> +GEN_INT ((val >> i) & 0x)));
> + }
> +
> + return 3;
> + }
> +}
> +
>/* Generate 2-4 instructions, skipping 16 bits of all zeroes or ones which
> are emitted by the initial mov. If one_match > zero_match, skip set
> bits,
> otherwise skip zero bits. */
> diff --git a/gcc/testsuite/gcc.target/aarch64/pr106583.c
> b/gcc/testsuite/gcc.target/aarch64/pr106583.c
> new file mode 100644
> index
> ..f0a027a0950e506d4ddaacce5e151f57070948dc
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/aarch64/pr106583.c
> @@ -0,0 +1,30 @@
> +/* { dg-do assemble } */
> +/* { dg-options "-O2 --save-temps" } */
> +
> +long f1 (void)
> +{
> + return 0x7efefefefefefeff;
> +}
> +
> +long f2 (void)
> +{
> + return 0x12345678;
> +}
> +
> +long f3 (void)
> +{
> + return 0x12345678;
> +}
> +
> +long f4 (void)
> +{
> + return 0x12345678;
> +}
> +
> +long f5 (void)
> +{
> + return 0x12345678;
> +}
> +
> +/* { dg-final { scan-assembler-times {\tmovk\t} 10 } } */
> +/* { dg-final { scan-assembler-times {\tmov\t} 5 } } */
RE: [PATCH][AArch64] Implement ACLE Data Intrinsics
> -Original Message- > From: Andre Vieira (lists) > Sent: Tuesday, October 4, 2022 11:34 AM > To: Kyrylo Tkachov ; gcc-patches@gcc.gnu.org; > Richard Sandiford ; Richard Biener > > Subject: Re: [PATCH][AArch64] Implement ACLE Data Intrinsics > > Hi all, > > Can I backport this to gcc-11 branch? Also applies cleanly (with the > exception of the file extensions being different: 'aarch64-builtins.cc > vs aarch64-builtins.c'). > Ok by me if testing is clean. Thanks, Kyrill > Bootstrapped and regression tested on aarch64-linux-gnu. > > Kind regards, > Andre Vieira
Re: [PATCH] Fortran: error recovery for invalid types in array constructors [PR107000]
Hello
Le 04/10/2022 à 23:19, Harald Anlauf via Fortran a écrit :
Dear all,
we did not recover well from bad expressions in array constructors,
especially when there was a typespec and a unary '+' or '-', and
when the array constructor was used in an arithmetic expression.
The attached patch introduces an ARITH_INVALID_TYPE that is used
when we try to recover from these errors, and tries to handle
all unary and binary arithmetic expressions.
In the PR, you noted an inconsistency in the error message reported,
depending on the presence or lack of an operator.
I'm not sure you saw the suggestion to do the following in the last
message I posted:
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index e6e35ef3c42..ed93ddb2882 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1654,6 +1654,8 @@ eval_intrinsic (gfc_intrinsic_op op,
else
rc = reduce_binary (eval.f3, op1, op2, &result);
+ if (rc == ARITH_INVALID_TYPE)
+goto runtime;
/* Something went wrong. */
if (op == INTRINSIC_POWER && rc == ARITH_PROHIBIT)
In the testcase, it improves the situation slightly.
For example, from:
9 | x = (1.0, 2.0) * [complex :: +'1'] ! { dg-error "Invalid type" }
|1
Error: Invalid type in arithmetic operation at (1)
to:
9 | x = (1.0, 2.0) * [complex :: +'1'] ! { dg-error "Invalid type" }
| 1
Error: Operand of unary numeric operator ‘+’ at (1) is UNKNOWN
or from:
29 | print *, 2 * [real :: 0, 1+'1'] ! { dg-error "Invalid type" }
|1
Error: Invalid type in arithmetic operation at (1)
to:
29 | print *, 2 * [real :: 0, 1+'1'] ! { dg-error "Invalid type" }
| 1
Error: Operands of binary numeric operator ‘+’ at (1) are
INTEGER(4)/CHARACTER(1)
Unfortunately, it doesn't fix the bogus incommensurate arrays errors.
PING^1 [PATCH] testsuite: Windows reports errors with CreateProcess
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602541.html
Kind regards,
Torbjörn
On 2022-09-29 20:07, Torbjörn SVENSSON wrote:
When the mapper can't be executed, Windows report the error like:
.../bad-mapper-1.C: error: failed CreateProcess mapper 'this-will-not-work'
On Linux, the same error is reported this way:
.../bad-mapper-1.C: error: failed execvp mapper 'this-will-not-work'
This patch allows both output forms to be accepted.
Patch has been verified on Windows and Linux.
gcc/testsuite:
* g++.dg/modules/bad-mapper-1.C: Also accept CreateProcess.
Co-Authored-By: Yvan ROUX
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/g++.dg/modules/bad-mapper-1.C | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/g++.dg/modules/bad-mapper-1.C
b/gcc/testsuite/g++.dg/modules/bad-mapper-1.C
index 6d0ed4b5895..4b2312885d8 100644
--- a/gcc/testsuite/g++.dg/modules/bad-mapper-1.C
+++ b/gcc/testsuite/g++.dg/modules/bad-mapper-1.C
@@ -1,6 +1,6 @@
// { dg-additional-options "-fmodules-ts
-fmodule-mapper=|this-will-not-work" }
import unique1.bob;
-// { dg-error "-:failed exec.*mapper.* .*this-will-not-work" "" { target { ! {
*-*-darwin[89]* *-*-darwin10* } } } 0 }
+// { dg-error "-:failed (exec|CreateProcess).*mapper.* .*this-will-not-work"
"" { target { ! { *-*-darwin[89]* *-*-darwin10* } } } 0 }
// { dg-prune-output "fatal error:" }
// { dg-prune-output "failed to read" }
// { dg-prune-output "compilation terminated" }
PING^1 [PATCH] testsuite: Verify that module-mapper is available
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602111.html
Kind regards,
Torbjörn
On 2022-09-23 14:03, Torbjörn SVENSSON wrote:
For some test cases, it's required that the optional module mapper
"g++-mapper-server" is built. As the server is not required, the
test cases will fail if it can't be found.
gcc/testsuite/ChangeLog:
* lib/target-supports.exp (check_is_prog_name_available):
New.
* lib/target-supports-dg.exp
(dg-require-prog-name-available): New.
* g++.dg/modules/modules.exp: Verify avilability of module
mapper.
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/g++.dg/modules/modules.exp | 31
gcc/testsuite/lib/target-supports-dg.exp | 15
gcc/testsuite/lib/target-supports.exp| 15
3 files changed, 61 insertions(+)
diff --git a/gcc/testsuite/g++.dg/modules/modules.exp
b/gcc/testsuite/g++.dg/modules/modules.exp
index afb323d0efd..4784803742a 100644
--- a/gcc/testsuite/g++.dg/modules/modules.exp
+++ b/gcc/testsuite/g++.dg/modules/modules.exp
@@ -279,6 +279,29 @@ proc module-init { src } {
return $option_list
}
+# Return 1 if requirements are met
+proc module-check-requirements { tests } {
+foreach test $tests {
+ set tmp [dg-get-options $test]
+ foreach op $tmp {
+ switch [lindex $op 0] {
+ "dg-additional-options" {
+ # Example strings to match:
+ # -fmodules-ts -fmodule-mapper=|@g++-mapper-server\\ -t\\
[srcdir]/inc-xlate-1.map
+ # -fmodules-ts -fmodule-mapper=|@g++-mapper-server
+ if [regexp -- {(^| )-fmodule-mapper=\|@([^\\ ]*)} [lindex
$op 2] dummy dummy2 prog] {
+ verbose "Checking that mapper exist: $prog"
+ if { ![ check_is_prog_name_available $prog ] } {
+ return 0
+ }
+ }
+ }
+ }
+ }
+}
+return 1
+}
+
# cleanup any detritus from previous run
cleanup_module_files [find $DEFAULT_REPO *.gcm]
@@ -307,6 +330,14 @@ foreach src [lsort [find $srcdir/$subdir {*_a.[CHX}]] {
set tests [lsort [find [file dirname $src] \
[regsub {_a.[CHX]$} [file tail $src]
{_[a-z].[CHX]}]]]
+ if { ![module-check-requirements $tests] } {
+ set testcase [regsub {_a.[CH]} $src {}]
+ set testcase \
+ [string range $testcase [string length "$srcdir/"] end]
+ unsupported $testcase
+ continue
+ }
+
set std_list [module-init $src]
foreach std $std_list {
set mod_files {}
diff --git a/gcc/testsuite/lib/target-supports-dg.exp
b/gcc/testsuite/lib/target-supports-dg.exp
index aa2164bc789..6ce3b2b1a1b 100644
--- a/gcc/testsuite/lib/target-supports-dg.exp
+++ b/gcc/testsuite/lib/target-supports-dg.exp
@@ -683,3 +683,18 @@ proc dg-require-symver { args } {
set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
}
}
+
+# If this target does not provide prog named "$args", skip this test.
+
+proc dg-require-prog-name-available { args } {
+# The args are within another list; pull them out.
+set args [lindex $args 0]
+
+set prog [lindex $args 1]
+
+if { ![ check_is_prog_name_available $prog ] } {
+upvar dg-do-what dg-do-what
+set dg-do-what [list [lindex ${dg-do-what} 0] "N" "P"]
+}
+}
+
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 703aba412a6..c3b7a6c17b3 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -11928,3 +11928,18 @@ main:
.byte 0
} ""]
}
+
+# Return 1 if this target has prog named "$prog", 0 otherwise.
+
+proc check_is_prog_name_available { prog } {
+global tool
+
+set options [list "additional_flags=-print-prog-name=$prog"]
+set output [lindex [${tool}_target_compile "" "" "none" $options] 0]
+
+if { $output == $prog } {
+return 0
+}
+
+return 1
+}
PING^1 [PATCH] testsuite: /dev/null is not accessible on Windows
Hi,
Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602534.html
Kind regards,
Torbjörn
On 2022-09-29 19:38, Torbjörn SVENSSON wrote:
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe:
cannot find @/dev/null: No such file or directory
Patch has been verified on Windows and Linux.
gcc/testsuite:
* gcc.misc-tests/outputs.exp: Use "@nul" for Windows,
"@/dev/null" for other environments.
Co-Authored-By: Yvan ROUX
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.misc-tests/outputs.exp | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index ab919db1ccb..3fe7270fa63 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -78,6 +78,13 @@ if {[board_info $dest exists output_format]} {
append link_options " additional_flags=-Wl,-oformat,[board_info $dest
output_format]"
}
+
+set devnull "/dev/null"
+if { [info exists ::env(OS)] && [string match "Windows*" $::env(OS)] } {
+# Windows uses special file named "nul" as a substitute for /dev/null
+set devnull "nul"
+}
+
# Avoid possible influence from the make jobserver,
# otherwise ltrans0.ltrans_args files may be missing.
if [info exists env(MAKEFLAGS)] {
@@ -353,10 +360,10 @@ outest "$b-21 exe savetmp named2" $mult "-o $b.exe
-save-temps" {} {{--1.i --1.s
# Additional files are created when an @file is used
if !$skip_atsave {
-outest "$b-22 exe savetmp namedb-2" $sing "@/dev/null -o $b.exe -save-temps"
{} {{--0.i --0.s --0.o .args.0 !!$gld .ld1_args !0 .exe}}
-outest "$b-23 exe savetmp named2-2" $mult "@/dev/null -o $b.exe -save-temps"
{} {{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 !!$gld .ld1_args !0 .exe}}
-outest "$b-24 exe savetmp named2-3" $mult "@/dev/null -I dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 !!$gld .ld1_args
!0 .exe}}
-outest "$b-25 exe savetmp named2-4" $mult "@/dev/null -I dummy -L dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 .args.3 !!$gld
.ld1_args !0 .exe}}
+outest "$b-22 exe savetmp namedb-2" $sing "@$devnull -o $b.exe -save-temps" {}
{{--0.i --0.s --0.o .args.0 !!$gld .ld1_args !0 .exe}}
+outest "$b-23 exe savetmp named2-2" $mult "@$devnull -o $b.exe -save-temps" {}
{{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 !!$gld .ld1_args !0 .exe}}
+outest "$b-24 exe savetmp named2-3" $mult "@$devnull -I dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 !!$gld .ld1_args
!0 .exe}}
+outest "$b-25 exe savetmp named2-4" $mult "@$devnull -I dummy -L dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 .args.3 !!$gld
.ld1_args !0 .exe}}
}
# Setting the main output to a dir selects it as the default aux&dump
@@ -714,7 +721,7 @@ outest "$b-291 lto mult named-2" $mult "-o $b.exe -O2 -flto
-fno-use-linker-plug
outest "$b-292 lto sing nameddir-2" $sing "-o dir/$b.exe -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final
-fstack-usage" {dir/} {{--0.c.???i.icf --0.c.???r.final .wpa.???i.icf
.ltrans0.ltrans.???r.final .ltrans0.ltrans.su .exe} {}}
outest "$b-293 lto mult nameddir-2" $mult "-o dir/$b.exe -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final
-fstack-usage" {dir/} {{--1.c.???i.icf --1.c.???r.final --2.c.???i.icf --2.c.???r.final
.wpa.???i.icf .ltrans0.ltrans.???r.final .ltrans0.ltrans.su .exe} {}}
if !$skip_atsave {
-outest "$b-294 lto sing unnamed-3" $sing "@/dev/null -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final -fstack-usage
-save-temps $oaout" {} {{a--0.c.???i.icf a--0.c.???r.final a.wpa.???i.icf
a.ltrans0.ltrans.???r.final a.ltrans0.ltrans.su a--0.o a--0.s a--0.i a.ltrans0.o a.ltrans.out
a.ltrans0.ltrans.o a.ltrans0.ltrans_args a.args.0 a.ltrans0.ltrans.s a.wpa.args.0 a.lto_args
a.ld1_args a.ltrans_args a.ltrans0.ltrans.args.0 a.ld_args $aout}}
+outest "$b-294 lto sing unnamed-3" $sing "@$devnull -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final -fstack-usage
-save-temps $oaout" {} {{a--0.c.???i.icf a--0.c.???r.final a.wpa.???i.icf
a.ltrans0.ltrans.???r.final a.ltrans0.ltrans.su a--0.o a--0.s a--0.i a.ltrans0.o a.ltrans.out
a.ltrans0.ltrans.o a.ltrans0.ltrans_args a.args.0 a.ltrans0.ltrans.s a.wpa.args.0 a.lto_args
a.ld1_args a.ltrans_args a.ltrans0.ltrans.args.0 a.ld_args $aout}}
}
}
Re: [PATCH] Fortran: error recovery for invalid types in array constructors [PR107000]
Le 05/10/2022 à 10:51, Mikael Morin a écrit : Unfortunately, it doesn't fix the bogus incommensurate arrays errors. The following does. diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc index e6e35ef3c42..2c57c796270 100644 --- a/gcc/fortran/arith.cc +++ b/gcc/fortran/arith.cc @@ -1443,7 +1443,7 @@ reduce_binary_aa (arith (*eval) (gfc_expr *, gfc_expr *, gfc_expr **), gfc_replace_expr (c->expr, r); } - if (c || d) + if (rc == ARITH_OK && (c || d)) rc = ARITH_INCOMMENSURATE; if (rc != ARITH_OK) There is one last thing that I'm dissatisfied with. The handling of unknown types should be moved to reduce_binary, because the dispatching in reduce_binary doesn't handle EXPR_OP, so even if either or both operands are scalar, they are handled by the (array vs array) reduce_binary_aa function. That's confusing.
Re: [PATCH] testsuite: /dev/null is not accessible on Windows
On 9/29/22 17:38, Torbjörn SVENSSON via Gcc-patches wrote:
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe:
cannot find @/dev/null: No such file or directory
Patch has been verified on Windows and Linux.
gcc/testsuite:
* gcc.misc-tests/outputs.exp: Use "@nul" for Windows,
"@/dev/null" for other environments.
Co-Authored-By: Yvan ROUX
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.misc-tests/outputs.exp | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index ab919db1ccb..3fe7270fa63 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -78,6 +78,13 @@ if {[board_info $dest exists output_format]} {
append link_options " additional_flags=-Wl,-oformat,[board_info $dest
output_format]"
}
+
+set devnull "/dev/null"
+if { [info exists ::env(OS)] && [string match "Windows*" $::env(OS)] } {
+# Windows uses special file named "nul" as a substitute for /dev/null
+set devnull "nul"
+}
+
# Avoid possible influence from the make jobserver,
# otherwise ltrans0.ltrans_args files may be missing.
if [info exists env(MAKEFLAGS)] {
@@ -353,10 +360,10 @@ outest "$b-21 exe savetmp named2" $mult "-o $b.exe
-save-temps" {} {{--1.i --1.s
# Additional files are created when an @file is used
if !$skip_atsave {
-outest "$b-22 exe savetmp namedb-2" $sing "@/dev/null -o $b.exe -save-temps"
{} {{--0.i --0.s --0.o .args.0 !!$gld .ld1_args !0 .exe}}
-outest "$b-23 exe savetmp named2-2" $mult "@/dev/null -o $b.exe -save-temps"
{} {{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 !!$gld .ld1_args !0 .exe}}
-outest "$b-24 exe savetmp named2-3" $mult "@/dev/null -I dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 !!$gld .ld1_args
!0 .exe}}
-outest "$b-25 exe savetmp named2-4" $mult "@/dev/null -I dummy -L dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 .args.3 !!$gld
.ld1_args !0 .exe}}
+outest "$b-22 exe savetmp namedb-2" $sing "@$devnull -o $b.exe -save-temps" {}
{{--0.i --0.s --0.o .args.0 !!$gld .ld1_args !0 .exe}}
+outest "$b-23 exe savetmp named2-2" $mult "@$devnull -o $b.exe -save-temps" {}
{{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 !!$gld .ld1_args !0 .exe}}
+outest "$b-24 exe savetmp named2-3" $mult "@$devnull -I dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 !!$gld .ld1_args
!0 .exe}}
+outest "$b-25 exe savetmp named2-4" $mult "@$devnull -I dummy -L dummy -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0 -args.1 .args.2 .args.3 !!$gld
.ld1_args !0 .exe}}
}
# Setting the main output to a dir selects it as the default aux&dump
@@ -714,7 +721,7 @@ outest "$b-291 lto mult named-2" $mult "-o $b.exe -O2 -flto
-fno-use-linker-plug
outest "$b-292 lto sing nameddir-2" $sing "-o dir/$b.exe -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final
-fstack-usage" {dir/} {{--0.c.???i.icf --0.c.???r.final .wpa.???i.icf
.ltrans0.ltrans.???r.final .ltrans0.ltrans.su .exe} {}}
outest "$b-293 lto mult nameddir-2" $mult "-o dir/$b.exe -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final
-fstack-usage" {dir/} {{--1.c.???i.icf --1.c.???r.final --2.c.???i.icf --2.c.???r.final
.wpa.???i.icf .ltrans0.ltrans.???r.final .ltrans0.ltrans.su .exe} {}}
if !$skip_atsave {
-outest "$b-294 lto sing unnamed-3" $sing "@/dev/null -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final -fstack-usage
-save-temps $oaout" {} {{a--0.c.???i.icf a--0.c.???r.final a.wpa.???i.icf
a.ltrans0.ltrans.???r.final a.ltrans0.ltrans.su a--0.o a--0.s a--0.i a.ltrans0.o a.ltrans.out
a.ltrans0.ltrans.o a.ltrans0.ltrans_args a.args.0 a.ltrans0.ltrans.s a.wpa.args.0 a.lto_args
a.ld1_args a.ltrans_args a.ltrans0.ltrans.args.0 a.ld_args $aout}}
+outest "$b-294 lto sing unnamed-3" $sing "@$devnull -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized -fdump-rtl-final -fstack-usage
-save-temps $oaout" {} {{a--0.c.???i.icf a--0.c.???r.final a.wpa.???i.icf
a.ltrans0.ltrans.???r.final a.ltrans0.ltrans.su a--0.o a--0.s a--0.i a.ltrans0.o a.ltrans.out
a.ltrans0.ltrans.o a.ltrans0.ltrans_args a.args.0 a.ltrans0.ltrans.s a.wpa.args.0 a.lto_args
a.ld1_args a.ltrans_args a.ltrans0.ltrans.args.0 a.ld_args $aout}}
}
}
Thanks, looks good to me, will push to master soon.
Re: [PATCH] testsuite: /dev/null is not accessible on Windows
Hi,
On 2022-10-05 11:34, Jonathan Yong via Gcc-patches wrote:
On 9/29/22 17:38, Torbjörn SVENSSON via Gcc-patches wrote:
When running the DejaGNU testsuite on a toolchain built for native
Windows, the path /dev/null can't be used to open a stream to void.
On native Windows, the resource is instead named "nul".
The error would look like this:
c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe:
cannot find @/dev/null: No such file or directory
Patch has been verified on Windows and Linux.
gcc/testsuite:
* gcc.misc-tests/outputs.exp: Use "@nul" for Windows,
"@/dev/null" for other environments.
Co-Authored-By: Yvan ROUX
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.misc-tests/outputs.exp | 17 -
1 file changed, 12 insertions(+), 5 deletions(-)
diff --git a/gcc/testsuite/gcc.misc-tests/outputs.exp
b/gcc/testsuite/gcc.misc-tests/outputs.exp
index ab919db1ccb..3fe7270fa63 100644
--- a/gcc/testsuite/gcc.misc-tests/outputs.exp
+++ b/gcc/testsuite/gcc.misc-tests/outputs.exp
@@ -78,6 +78,13 @@ if {[board_info $dest exists output_format]} {
append link_options " additional_flags=-Wl,-oformat,[board_info
$dest output_format]"
}
+
+set devnull "/dev/null"
+if { [info exists ::env(OS)] && [string match "Windows*" $::env(OS)] } {
+ # Windows uses special file named "nul" as a substitute for
/dev/null
+ set devnull "nul"
+}
+
# Avoid possible influence from the make jobserver,
# otherwise ltrans0.ltrans_args files may be missing.
if [info exists env(MAKEFLAGS)] {
@@ -353,10 +360,10 @@ outest "$b-21 exe savetmp named2" $mult "-o
$b.exe -save-temps" {} {{--1.i --1.s
# Additional files are created when an @file is used
if !$skip_atsave {
-outest "$b-22 exe savetmp namedb-2" $sing "@/dev/null -o $b.exe
-save-temps" {} {{--0.i --0.s --0.o .args.0 !!$gld .ld1_args !0 .exe}}
-outest "$b-23 exe savetmp named2-2" $mult "@/dev/null -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 !!$gld
.ld1_args !0 .exe}}
-outest "$b-24 exe savetmp named2-3" $mult "@/dev/null -I dummy -o
$b.exe -save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0
-args.1 .args.2 !!$gld .ld1_args !0 .exe}}
-outest "$b-25 exe savetmp named2-4" $mult "@/dev/null -I dummy -L
dummy -o $b.exe -save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o
-args.0 -args.1 .args.2 .args.3 !!$gld .ld1_args !0 .exe}}
+outest "$b-22 exe savetmp namedb-2" $sing "@$devnull -o $b.exe
-save-temps" {} {{--0.i --0.s --0.o .args.0 !!$gld .ld1_args !0 .exe}}
+outest "$b-23 exe savetmp named2-2" $mult "@$devnull -o $b.exe
-save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o .args.0 !!$gld
.ld1_args !0 .exe}}
+outest "$b-24 exe savetmp named2-3" $mult "@$devnull -I dummy -o
$b.exe -save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o -args.0
-args.1 .args.2 !!$gld .ld1_args !0 .exe}}
+outest "$b-25 exe savetmp named2-4" $mult "@$devnull -I dummy -L
dummy -o $b.exe -save-temps" {} {{--1.i --1.s --1.o --2.i --2.s --2.o
-args.0 -args.1 .args.2 .args.3 !!$gld .ld1_args !0 .exe}}
}
# Setting the main output to a dir selects it as the default aux&dump
@@ -714,7 +721,7 @@ outest "$b-291 lto mult named-2" $mult "-o $b.exe
-O2 -flto -fno-use-linker-plug
outest "$b-292 lto sing nameddir-2" $sing "-o dir/$b.exe -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized
-fdump-rtl-final -fstack-usage" {dir/} {{--0.c.???i.icf
--0.c.???r.final .wpa.???i.icf .ltrans0.ltrans.???r.final
.ltrans0.ltrans.su .exe} {}}
outest "$b-293 lto mult nameddir-2" $mult "-o dir/$b.exe -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized
-fdump-rtl-final -fstack-usage" {dir/} {{--1.c.???i.icf
--1.c.???r.final --2.c.???i.icf --2.c.???r.final .wpa.???i.icf
.ltrans0.ltrans.???r.final .ltrans0.ltrans.su .exe} {}}
if !$skip_atsave {
-outest "$b-294 lto sing unnamed-3" $sing "@/dev/null -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized
-fdump-rtl-final -fstack-usage -save-temps $oaout" {}
{{a--0.c.???i.icf a--0.c.???r.final a.wpa.???i.icf
a.ltrans0.ltrans.???r.final a.ltrans0.ltrans.su a--0.o a--0.s a--0.i
a.ltrans0.o a.ltrans.out a.ltrans0.ltrans.o a.ltrans0.ltrans_args
a.args.0 a.ltrans0.ltrans.s a.wpa.args.0 a.lto_args a.ld1_args
a.ltrans_args a.ltrans0.ltrans.args.0 a.ld_args $aout}}
+outest "$b-294 lto sing unnamed-3" $sing "@$devnull -O2 -flto
-fno-use-linker-plugin -flto-partition=one -fdump-ipa-icf-optimized
-fdump-rtl-final -fstack-usage -save-temps $oaout" {}
{{a--0.c.???i.icf a--0.c.???r.final a.wpa.???i.icf
a.ltrans0.ltrans.???r.final a.ltrans0.ltrans.su a--0.o a--0.s a--0.i
a.ltrans0.o a.ltrans.out a.ltrans0.ltrans.o a.ltrans0.ltrans_args
a.args.0 a.ltrans0.ltrans.s a.wpa.args.0 a.lto_args a.ld1_args
a.ltrans_args a.ltrans0.ltrans.args.0 a.ld_args $aout}}
}
}
Thanks, looks good to me, will push to master soon.
Thanks for the review. I can p
Re: [PATCH] testsuite: /dev/null is not accessible on Windows
On 10/5/22 09:34, Jonathan Yong wrote: On 9/29/22 17:38, Torbjörn SVENSSON via Gcc-patches wrote: When running the DejaGNU testsuite on a toolchain built for native Windows, the path /dev/null can't be used to open a stream to void. On native Windows, the resource is instead named "nul". The error would look like this: c:/arm-11.3.rel1/bin/../lib/gcc/arm-none-eabi/11.3.1/../../../../arm-none-eabi/bin/ld.exe: cannot find @/dev/null: No such file or directory Patch has been verified on Windows and Linux. Thanks, looks good to me, will push to master soon. Pushed to master branch 5fe2e4f87e512407c5c560dfec2fe48ba099c807.
Re: PING^1 [PATCH] testsuite: Windows reports errors with CreateProcess
On 10/5/22 09:15, Torbjorn SVENSSON via Gcc-patches wrote: Hi, Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602541.html Kind regards, Torbjörn Looks good to me, pushed to master branch as fa8e3a055a082e38aeab2561a5016b01ebfd6ebd.
RE: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough jumps
Hi Torbjörn, > -Original Message- > From: Torbjorn SVENSSON > Sent: Wednesday, October 5, 2022 10:28 AM > To: Kyrylo Tkachov > Cc: Yvan Roux > Subject: Fwd: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough > jumps > > Hi Kyrill, > > I checked with Richard Sandiford if he could review this patch, but he > pointed to you. > Do you think that you can take a look it? This is ok. I don't think it changes any of the things we want to actually test for in these cases. Thanks, Kyrill > > Thank you! > > Kind regards, > Torbjörn > > > Forwarded Message > Subject: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough > jumps > Date: Wed, 28 Sep 2022 11:17:13 +0200 > From: Torbjorn SVENSSON > To: gcc-patches@gcc.gnu.org > CC: yvan.r...@foss.st.com, r...@cebitec.uni-bielefeld.de, > mikest...@comcast.net, kyrylo.tkac...@arm.com > > Hi, > > Ping: https://gcc.gnu.org/pipermail/gcc-patches/2022- > September/601829.html > > Kind regards, > Torbjörn > > On 2022-09-19 18:30, Torbjörn SVENSSON wrote: > > After moving the testglue in commit 9d503515cee, the jump to exit and > > abort is too far for the 'b' instruction on Cortex-M0. As most of the > > C code would generate a 'bl' instruction instead of a 'b' > > instruction, lets do the same for the inline assembler. > > > > The error seen without this patch: > > > > /tmp/cccCRiCl.o: in function `main': > > stack-protector-1.c:(.text+0x4e): relocation truncated to fit: > R_ARM_THM_JUMP11 against symbol `__wrap_exit' defined in .text section > in gcc_tg.o > > stack-protector-1.c:(.text+0x50): relocation truncated to fit: > R_ARM_THM_JUMP11 against symbol `__wrap_abort' defined in .text > section in gcc_tg.o > > collect2: error: ld returned 1 exit status > > > > gcc/testsuite/ChangeLog: > > > > * gcc/testsuite/gcc.target/arm/stack-protector-1.c: Use 'bl' > > instead of 'b' instruction. > > * gcc/testsuite/gcc.target/arm/stack-protector-3.c: Likewise. > > > > Co-Authored-By: Yvan ROUX > > Signed-off-by: Torbjörn SVENSSON > > --- > > gcc/testsuite/gcc.target/arm/stack-protector-1.c | 4 ++-- > > gcc/testsuite/gcc.target/arm/stack-protector-3.c | 2 +- > > 2 files changed, 3 insertions(+), 3 deletions(-) > > > > diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-1.c > b/gcc/testsuite/gcc.target/arm/stack-protector-1.c > > index 8d28b0a847c..3f0ffc9c3f3 100644 > > --- a/gcc/testsuite/gcc.target/arm/stack-protector-1.c > > +++ b/gcc/testsuite/gcc.target/arm/stack-protector-1.c > > @@ -56,8 +56,8 @@ asm ( > > " ldr r1, [sp, #4]\n" > > CHECK (r1) > > " mov r0, #0\n" > > -" b exit\n" > > +" bl exit\n" > > "1:\n" > > -" b abort\n" > > +" bl abort\n" > > " .size main, .-main" > > ); > > diff --git a/gcc/testsuite/gcc.target/arm/stack-protector-3.c > b/gcc/testsuite/gcc.target/arm/stack-protector-3.c > > index b8f77fa2309..2f710529b8f 100644 > > --- a/gcc/testsuite/gcc.target/arm/stack-protector-3.c > > +++ b/gcc/testsuite/gcc.target/arm/stack-protector-3.c > > @@ -26,7 +26,7 @@ asm ( > > " .type __stack_chk_fail, %function\n" > > "__stack_chk_fail:\n" > > " movsr0, #0\n" > > -" b exit\n" > > +" bl exit\n" > > " .size __stack_chk_fail, .-__stack_chk_fail" > > ); > >
[PATCH] c++, c, v3: Implement C++23 P1774R8 - Portable assumptions [PR106654]
On Tue, Oct 04, 2022 at 04:42:04PM -0400, Jason Merrill wrote:
> It could choose which function to call based on whether the constexpr_ctx
> parameter is null?
Done, though it needs to be in constexpr.cc then because struct
constexpr_ctx and cxx_eval_constant_expression is local to constexpr.cc.
> > * attribs.h (remove_attribute): Declare overload with additional
> > attr_ns argument.
> > (private_lookup_attribute): Declare overload with additional
> > attr_ns and attr_ns_len arguments.
> > (lookup_attribute): New overload with additional attr_ns argument.
> > * attribs.cc (remove_attribute): New overload with additional
> > attr_ns argument.
> > (private_lookup_attribute): New overload with additional
> > attr_ns and attr_ns_len arguments.
>
> I think go ahead and commit the attribs.{h,cc} changes separately.
Done last night.
> > @@ -8519,10 +8520,11 @@ cp_parser_parenthesized_expression_list
> > }
> > else
> > {
> > - expr
> > - = cp_parser_parenthesized_expression_list_elt (parser, cast_p,
> > -allow_expansion_p,
> > -non_constant_p);
> > + if (is_attribute_list == assume_attr)
> > + expr = cp_parser_conditional_expression (parser);
> > + else
> > + expr = cp_parser_parenthesized_expression_list_elt
> > + (parser, cast_p, allow_expansion_p, non_constant_p);
>
> This needs more parens to preserve this indentation.
I've changed the code some more and now the
cp_parser_parenthesized_expression_list_elt
call doesn't need reindentation and thus formatting uglification.
For some strange reason, the id_attr identifier case was setting
identifier variable and not pushing anything into the vector right away,
then at the very end it memmoved all the other elements one element to the
right and inserted the identifier there. That doesn't make any sense to me,
nothing is really looking at the expression_list vector until it is
returned, so I've just assigned the identifier to expr and handled it
like all other expressions.
> > + else
> > + {
>
> Maybe
>
> tree &arg = (*call_args)[0];
Good idea, changed.
Here is an updated, so far lightly tested, patch, ok if it passes
full bootstrap/regtest?
2022-10-05 Jakub Jelinek
PR c++/106654
gcc/
* internal-fn.def (ASSUME): New internal function.
* internal-fn.h (expand_ASSUME): Declare.
* internal-fn.cc (expand_ASSUME): Define.
* gimplify.cc (gimplify_call_expr): Gimplify IFN_ASSUME.
* fold-const.h (simple_condition_p): Declare.
* fold-const.cc (simple_operand_p_2): Rename to ...
(simple_condition_p): ... this. Remove forward declaration.
No longer static. Adjust function comment and fix a typo in it.
Adjust recursive call.
(simple_operand_p): Adjust function comment.
(fold_truth_andor): Adjust simple_operand_p_2 callers to call
simple_condition_p.
* doc/extend.texi: Document assume attribute. Move fallthrough
attribute example to its section.
gcc/c-family/
* c-attribs.cc (handle_assume_attribute): New function.
(c_common_attribute_table): Add entry for assume attribute.
* c-lex.cc (c_common_has_attribute): Handle
__have_cpp_attribute (assume).
gcc/c/
* c-parser.cc (handle_assume_attribute): New function.
(c_parser_declaration_or_fndef): Handle assume attribute.
(c_parser_attribute_arguments): Add assume_attr argument,
if true, parse first argument as conditional expression.
(c_parser_gnu_attribute, c_parser_std_attribute): Adjust
c_parser_attribute_arguments callers.
(c_parser_statement_after_labels) : Handle
assume attribute.
gcc/cp/
* cp-tree.h (process_stmt_assume_attribute): Implement C++23
P1774R8 - Portable assumptions. Declare.
(diagnose_failing_condition): Declare.
(find_failing_clause): Likewise.
* parser.cc (assume_attr): New enumerator.
(cp_parser_parenthesized_expression_list): Handle assume_attr.
Remove identifier variable, for id_attr push the identifier into
expression_list right away instead of inserting it before all the
others at the end.
(cp_parser_conditional_expression): New function.
(cp_parser_constant_expression): Use it.
(cp_parser_statement): Handle assume attribute.
(cp_parser_expression_statement): Likewise.
(cp_parser_gnu_attribute_list): Use assume_attr for assume
attribute.
(cp_parser_std_attribute): Likewise. Handle standard assume
attribute like gnu::assume.
* cp-gimplify.cc (process_stmt_assume_attribute): New function.
* constexpr.cc: Include fold-const.h.
(find_failing_clause_r, find_failing_clause): New f
Re: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough jumps
On 2022-10-05 11:51, Kyrylo Tkachov wrote: Hi Torbjörn, -Original Message- From: Torbjorn SVENSSON Sent: Wednesday, October 5, 2022 10:28 AM To: Kyrylo Tkachov Cc: Yvan Roux Subject: Fwd: PING^1 [PATCH] testsuite: 'b' instruction can't do long enough jumps Hi Kyrill, I checked with Richard Sandiford if he could review this patch, but he pointed to you. Do you think that you can take a look it? This is ok. I don't think it changes any of the things we want to actually test for in these cases. Thanks, Kyrill Thank you! Pushed to master branch 1a46a0a8b30405ea353a758971634dabeee89eaf. Kind regards, Torbjörn
Re: [COMMITTED] Convert nonzero mask in irange to wide_int.
On Tue, Oct 4, 2022 at 5:42 PM Andrew MacLeod wrote: > > > On 10/4/22 11:14, Aldy Hernandez wrote: > > On Tue, Oct 4, 2022 at 4:34 PM Richard Biener > > wrote: > >> > >> > >>> Am 04.10.2022 um 16:30 schrieb Aldy Hernandez : > >>> > >>> On Tue, Oct 4, 2022 at 3:27 PM Andrew MacLeod > >>> wrote: > > > On 10/4/22 08:13, Aldy Hernandez via Gcc-patches wrote: > >> On Tue, Oct 4, 2022, 13:28 Aldy Hernandez wrote: > >> On Tue, Oct 4, 2022 at 9:55 AM Richard Biener > >> wrote: > >>> Am 04.10.2022 um 09:36 schrieb Aldy Hernandez via Gcc-patches < > >> gcc-patches@gcc.gnu.org>: > The reason the nonzero mask was kept in a tree was basically > inertia, > as everything in irange is a tree. However, there's no need to keep > it in a tree, as the conversions to and from wide ints are very > annoying. That, plus special casing NULL masks to be -1 is prone > to error. > > I have not only rewritten all the uses to assume a wide int, but > have corrected a few places where we weren't propagating the masks, > or > rather pessimizing them to -1. This will become more important in > upcoming patches where we make better use of the masks. > > Performance testing shows a trivial improvement in VRP, as things > like > irange::contains_p() are tied to a tree. Ughh, can't wait for trees > in > iranges to go away. > >>> You want trailing wide int storage though. A wide_int is quite large. > >> Absolutely, this is only for short term storage. Any time we need > >> long term storage, say global ranges in SSA_NAME_RANGE_INFO, we go > >> through vrange_storage which will stream things in a more memory > >> efficient manner. For irange, vrange_storage will stream all the > >> sub-ranges, including the nonzero bitmask which is the first entry in > >> such storage, as trailing_wide_ints. > >> > >> See irange_storage_slot to see how it lives in GC memory. > >> > > That being said, the ranger's internal cache uses iranges, albeit with a > > squished down number of subranges (the minimum amount to represent the > > range). So each cache entry will now be bigger by the difference > > between > > one tree and one wide int. > > > > I wonder if we should change the cache to use vrange_storage. If not > > now, > > then when we convert all the subranges to wide ints. > > > > Of course, the memory pressure of the cache is not nearly as > > problematic as > > SSA_NAME_RANGE_INFO. The cache only stores names it cares about. > Rangers cache can be a memory bottleneck in pathological cases.. > Certainly not as bad as it use to be, but I'm sure it can still be > problematic.Its suppose to be a memory efficient representation > because of that. The cache can have an entry for any live ssa-name > (which means all of them at some point in the IL) multiplied by a factor > involving the number of dominator blocks and outgoing edges ranges are > calculated on. So while SSA_NAME_RANGE_INFO is a linear thing, the > cache lies somewhere between a logarithmic and exponential factor based > on the CFG size. > >>> Hmmm, perhaps the ultimate goal here should be to convert the cache to > >>> use vrange_storage, which uses trailing wide ints for all of the end > >>> points plus the masks (known_ones included for the next release). > >>> > if you are growing the common cases of 1 to 2 endpoints to more than > double in size (and most of the time not be needed), that would not be > very appealing :-P If we have any wide-ints, they would need to be a > memory efficient version. The Cache uses an irange_allocator, which is > suppose to provide a memory efficient objects.. hence why it trims the > number of ranges down to only what is needed. It seems like a trailing > wide-Int might be in order based on that.. > > Andrew > > > PS. which will be more problematic if you eventually introduce a > known_ones wide_int.I thought the mask tracking was/could be > something simple like HOST_WIDE_INT.. then you only tracks masks in > types up to the size of a HOST_WIDE_INT. then storage and masking is > all trivial without going thru a wide_int.Is that not so/possible? > >>> That's certainly easy and cheaper to do. The hard part was fixing all > >>> the places where we weren't keeping the masks up to date, and that's > >>> done (sans any bugs ;-)). > >>> > >>> Can we get consensus here on only tracking masks for type sizes less > >>> than HOST_WIDE_INT? I'd hate to do all the work only to realize we > >>> need to track 512 bit masks on a 32-bit host cross :-). > >> 64bits are not enough, 128 might be. But there’s trailing wide int > >>
[PATCH][pushed] testsuite: mark a test with xfail
Pushed as pre-approved by Jeff.
Martin
PR tree-optimization/106679
gcc/testsuite/ChangeLog:
* gcc.dg/tree-prof/cmpsf-1.c: Mark as a known limitation.
---
gcc/testsuite/gcc.dg/tree-prof/cmpsf-1.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/tree-prof/cmpsf-1.c
b/gcc/testsuite/gcc.dg/tree-prof/cmpsf-1.c
index 16adb92e1ca..696f459e605 100644
--- a/gcc/testsuite/gcc.dg/tree-prof/cmpsf-1.c
+++ b/gcc/testsuite/gcc.dg/tree-prof/cmpsf-1.c
@@ -181,4 +181,4 @@ main (void)
exit (0);
}
-/* { dg-final-use-not-autofdo { scan-tree-dump-not "Invalid sum" "dom2"} } */
+/* { dg-final-use-not-autofdo { scan-tree-dump-not "Invalid sum" "dom2" {
xfail *-*-* } } } */
--
2.37.3
Patch ping (Re: [PATCH] libgcc: Decrease size of _Unwind_FrameState and even more size of cleared area in uw_frame_state_for)
Hi! I'd like to ping this patch. Thanks. > 2022-09-19 Jakub Jelinek > > * unwind-dw2.h (REG_UNSAVED, REG_SAVED_OFFSET, REG_SAVED_REG, > REG_SAVED_EXP, REG_SAVED_VAL_OFFSET, REG_SAVED_VAL_EXP, > REG_UNDEFINED): New anonymous enum, moved from inside of > struct frame_state_reg_info. > (struct frame_state_reg_info): Remove reg[].how element and the > anonymous enum there. Add how element. > * unwind-dw2.c: Include stddef.h. > (uw_frame_state_for): Don't clear first > offsetof (_Unwind_FrameState, regs.how[0]) bytes of *fs. > (execute_cfa_program, __frame_state_for, uw_update_context_1, > uw_update_context): Use fs->regs.how[X] instead of fs->regs.reg[X].how > or fs.regs.how[X] instead of fs.regs.reg[X].how. > * config/sh/linux-unwind.h (sh_fallback_frame_state): Likewise. > * config/bfin/linux-unwind.h (bfin_fallback_frame_state): Likewise. > * config/pa/linux-unwind.h (pa32_fallback_frame_state): Likewise. > * config/pa/hpux-unwind.h (UPDATE_FS_FOR_SAR, UPDATE_FS_FOR_GR, > UPDATE_FS_FOR_FR, UPDATE_FS_FOR_PC, pa_fallback_frame_state): > Likewise. > * config/alpha/vms-unwind.h (alpha_vms_fallback_frame_state): > Likewise. > * config/alpha/linux-unwind.h (alpha_fallback_frame_state): Likewise. > * config/arc/linux-unwind.h (arc_fallback_frame_state, > arc_frob_update_context): Likewise. > * config/riscv/linux-unwind.h (riscv_fallback_frame_state): Likewise. > * config/nios2/linux-unwind.h (NIOS2_REG): Likewise. > * config/nds32/linux-unwind.h (NDS32_PUT_FS_REG): Likewise. > * config/s390/tpf-unwind.h (s390_fallback_frame_state): Likewise. > * config/s390/linux-unwind.h (s390_fallback_frame_state): Likewise. > * config/sparc/sol2-unwind.h (sparc64_frob_update_context, > MD_FALLBACK_FRAME_STATE_FOR): Likewise. > * config/sparc/linux-unwind.h (sparc64_fallback_frame_state, > sparc64_frob_update_context, sparc_fallback_frame_state): Likewise. > * config/i386/sol2-unwind.h (x86_64_fallback_frame_state, > x86_fallback_frame_state): Likewise. > * config/i386/w32-unwind.h (i386_w32_fallback_frame_state): Likewise. > * config/i386/linux-unwind.h (x86_64_fallback_frame_state, > x86_fallback_frame_state): Likewise. > * config/i386/freebsd-unwind.h (x86_64_freebsd_fallback_frame_state): > Likewise. > * config/i386/dragonfly-unwind.h > (x86_64_dragonfly_fallback_frame_state): Likewise. > * config/i386/gnu-unwind.h (x86_gnu_fallback_frame_state): Likewise. > * config/csky/linux-unwind.h (csky_fallback_frame_state): Likewise. > * config/aarch64/linux-unwind.h (aarch64_fallback_frame_state): > Likewise. > * config/aarch64/freebsd-unwind.h > (aarch64_freebsd_fallback_frame_state): Likewise. > * config/aarch64/aarch64-unwind.h (aarch64_frob_update_context): > Likewise. > * config/or1k/linux-unwind.h (or1k_fallback_frame_state): Likewise. > * config/mips/linux-unwind.h (mips_fallback_frame_state): Likewise. > * config/loongarch/linux-unwind.h (loongarch_fallback_frame_state): > Likewise. > * config/m68k/linux-unwind.h (m68k_fallback_frame_state): Likewise. > * config/xtensa/linux-unwind.h (xtensa_fallback_frame_state): > Likewise. > * config/rs6000/darwin-fallback.c (set_offset): Likewise. > * config/rs6000/aix-unwind.h (MD_FROB_UPDATE_CONTEXT): Likewise. > * config/rs6000/linux-unwind.h (ppc_fallback_frame_state): Likewise. > * config/rs6000/freebsd-unwind.h (frob_update_context): Likewise. Jakub
Re: [PATCH] Fortran: reject procedures and procedure pointers as output item [PR107074]
Hello Le 04/10/2022 à 21:27, Harald Anlauf via Fortran a écrit : Dear all, when looking at output item lists we didn't catch procedures and procedure pointers and ran into a gfc_internal_error(). Such items are not allowed by the Fortran standard, e.g. for procedure pointers there is C1233 (R1217) An expression that is an output-item shall not have a value that is a procedure pointer. Attached patch generates an error instead. Regtested on x86_64-pc-linux-gnu. OK for mainline? Please move the check to resolve_transfer in resolve.cc. Strangely, the patch doesn't seem to fix the problem on the testcase here. There is an outer parenthese expression preventing the condition you added from triggering. Can you double check? If we take the standard to the letter, only output items are forbidden, so a check is missing for writing context. I don't know how it can work for input items though, so maybe not worth it. In any case, the error shouldn't mention output items in reading context. Here is a variant of the testcase with procedure pointer components, that fails differently but can probably be caught as well. program p implicit none type :: t procedure(f), pointer, nopass :: b end type t type(t) :: a interface real function f() end function f end interface print *, merge (a%b, a%b, .true.) end
Re: [Patch] Fortran: Add OpenMP's assume(s) directives
Hi Jakub, On 04.10.22 14:58, Jakub Jelinek via Gcc-patches wrote: On Tue, Oct 04, 2022 at 02:26:13PM +0200, Tobias Burnus wrote: On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote: --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi OK? Ok, thanks. Committed as https://gcc.gnu.org/r13-3063-g8792047470073df0da4a5b91997d6058193d7676 Wouldn't this be better table driven (like c_omp_directives in c-family, though guess for Fortran you can just use spaces in the name, don't need 3 strings for the separate tokens)? Because I think absent/contains isn't the only spot where you need directive names, metadirective is another. Now added. I noted that I have different kinds/categories than you used in c-family/c-omp.c; and my impression that standalone vs. block vs delimited is a different category than informational/meta/... Maybe – I think there are already way to many string repetitions. One problem is that metadirectives permit combined/composite constructs while 'assume(s)' does not. I on purpose did not parse them, but probably in light of Metadirectives, I should. I will take a look. It is true that metadirective supports combined/composite constructs, and so do we in the C++ attribute case, still we IMHO can use the C/C++ table as is.and it doesn't need to include combined/composite constructs. The thing is that for the metadirective/C++ attribute case, all we need to know is to discover the directive category (declarative, stand-alone, construct, informational, ...) and for that it is enough to parse the first directive-name in combined/composite constructs. ... else if (popcount (old_n_absent) == 1) absent = ... sizeof() * (old_n_absent) * 2) Yeah. Or for 0 allocate say 8 and use (pow2p_hwi (old_n_absent) && old_n_absent >= 8) in the else if. I used now pow2p_hwi as popcount did not exist (and I didn't want to add an #include or use __builtin_popcount), not that either variant is clearer and it is neither performance critical nor is neither of "(x & -x) == x" and "popcount(x) == 1" slow. I don't understand the point of preallocation of gfc_omp_clauses here, ... That's now gone. As I have to check the duplication right after parsing – but before merging, I can no longer do it during resolution. Instead of keeping track of the directives separately, I now moved the checking to the directive parsing itself. It is not equivalent to that, because while we have the restriction that the same list item can't appear multiple times on the same directive, it can appear multiple times on multiple directives. I am not sure the handling of nested/repeated informational/declarative directives is very clear, but that's a separate issue. (Namely, OpenMP spec issue 3362.) Updated patch enclosed. And thanks for your comments! OK? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 Fortran: Add OpenMP's assume(s) directives libgomp/ChangeLog: * libgomp.texi (OpenMP 5.1 Impl. Status): Mark 'assume' as 'Y'. gcc/fortran/ChangeLog: * dump-parse-tree.cc (show_omp_assumes): New. (show_omp_clauses, show_namespace): Call it. (show_omp_node, show_code_node): Handle OpenMP ASSUME. * gfortran.h (enum gfc_statement): Add ST_OMP_ASSUME, ST_OMP_END_ASSUME, ST_OMP_ASSUMES and ST_NOTHING. (gfc_exec_op): Add EXEC_OMP_ASSUME. (gfc_omp_assumptions): New struct. (gfc_get_omp_assumptions): New XCNEW #define. (gfc_omp_clauses, gfc_namespace): Add assume member. (gfc_resolve_omp_assumptions): New prototype. * match.h (gfc_match_omp_assume, gfc_match_omp_assumes): New. * openmp.cc (omp_code_to_statement): Forward declare. (enum gfc_omp_directive_kind, struct gfc_omp_directive): New. (gfc_free_omp_clauses): Free assume member and its struct data. (enum omp_mask2): Add OMP_CLAUSE_ASSUMPTIONS. (gfc_omp_absent_contains_clause): New. (gfc_match_omp_clauses): Call it; optionally use passed omp_clauses argument. (omp_verify_merge_absent_contains, gfc_match_omp_assume, gfc_match_omp_assumes, gfc_resolve_omp_assumptions): New. (resolve_omp_clauses): Call the latter. (gfc_resolve_omp_directive, omp_code_to_statement): Handle EXEC_OMP_ASSUME. * parse.cc (decode_omp_directive): Parse OpenMP ASSUME(S). (next_statement, parse_executable, parse_omp_structured_block): Handle ST_OMP_ASSUME. (case_omp_decl): Add ST_OMP_ASSUMES. (gfc_ascii_statement): Handle Assumes, optional return string without '!$OMP '/'!$ACC ' prefix. * parse.h (gfc_ascii_statement): Add optional bool arg to prototype. * resolve.cc (gfc_resolve_blocks, gfc_resolve_code): Add EXEC_OMP_ASSUME. (gfc_resolve): Resolve ASSUMES directive. * symbol.cc (gfc_free_namespace): Free omp_assumes member. * st.cc (gfc_free_statement): Handle EXEC_OMP_ASSUME. * trans-openmp.cc (gfc_trans_omp_directive)
[PATCH][pushed] analyzer: remove unused variables
Fixes:
gcc/analyzer/call-summary.h:103:13: warning: private field 'm_called_fn' is not
used [-Wunused-private-field]
gcc/analyzer/engine.cc:1631:24: warning: unused parameter 'uncertainty'
[-Wunused-parameter]
gcc/analyzer/ChangeLog:
* call-summary.cc (call_summary_replay::call_summary_replay):
Remove unused variable and arguments.
* call-summary.h: Likewise.
* engine.cc (exploded_node::on_stmt): Likewise.
(exploded_node::replay_call_summaries): Likewise.
(exploded_node::replay_call_summary): Likewise.
* exploded-graph.h (class exploded_node): Likewise.
---
gcc/analyzer/call-summary.cc | 1 -
gcc/analyzer/call-summary.h | 1 -
gcc/analyzer/engine.cc| 5 +
gcc/analyzer/exploded-graph.h | 2 --
4 files changed, 1 insertion(+), 8 deletions(-)
diff --git a/gcc/analyzer/call-summary.cc b/gcc/analyzer/call-summary.cc
index 9d8716da96e..a8e881472ea 100644
--- a/gcc/analyzer/call-summary.cc
+++ b/gcc/analyzer/call-summary.cc
@@ -171,7 +171,6 @@ call_summary_replay::call_summary_replay (const
call_details &cd,
call_summary *summary,
const extrinsic_state &ext_state)
: m_cd (cd),
- m_called_fn (called_fn),
m_summary (summary),
m_ext_state (ext_state)
{
diff --git a/gcc/analyzer/call-summary.h b/gcc/analyzer/call-summary.h
index f4c5ff0b3aa..07cd3f53ce6 100644
--- a/gcc/analyzer/call-summary.h
+++ b/gcc/analyzer/call-summary.h
@@ -100,7 +100,6 @@ private:
const region *convert_region_from_summary_1 (const region *);
const call_details &m_cd;
- function *m_called_fn;
call_summary *m_summary;
const extrinsic_state &m_ext_state;
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index b4deee50f1f..735b5a3c061 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -1439,7 +1439,6 @@ exploded_node::on_stmt (exploded_graph &eg,
snode,
as_a (stmt),
state,
- uncertainty,
path_ctxt,
called_fn,
called_fn_data,
@@ -1598,7 +1597,6 @@ exploded_node::replay_call_summaries (exploded_graph &eg,
const supernode *snode,
const gcall *call_stmt,
program_state *state,
- uncertainty_t *uncertainty,
path_context *path_ctxt,
function *called_fn,
per_function_data *called_fn_data,
@@ -1612,7 +1610,7 @@ exploded_node::replay_call_summaries (exploded_graph &eg,
/* Each summary will call bifurcate on the PATH_CTXT. */
for (auto summary : called_fn_data->m_summaries)
-replay_call_summary (eg, snode, call_stmt, state, uncertainty,
+replay_call_summary (eg, snode, call_stmt, state,
path_ctxt, called_fn, summary, ctxt);
path_ctxt->terminate_path ();
@@ -1628,7 +1626,6 @@ exploded_node::replay_call_summary (exploded_graph &eg,
const supernode *snode,
const gcall *call_stmt,
program_state *old_state,
- uncertainty_t *uncertainty,
path_context *path_ctxt,
function *called_fn,
call_summary *summary,
diff --git a/gcc/analyzer/exploded-graph.h b/gcc/analyzer/exploded-graph.h
index ea4a890b9ce..11e46cab160 100644
--- a/gcc/analyzer/exploded-graph.h
+++ b/gcc/analyzer/exploded-graph.h
@@ -271,7 +271,6 @@ class exploded_node : public dnode
const supernode *snode,
const gcall *call_stmt,
program_state *state,
- uncertainty_t *uncertainty,
path_context *path_ctxt,
function *called_fn,
per_function_data *called_fn_data,
@@ -280,7 +279,6 @@ class exploded_node : public dnode
const supernode *snode,
const gcall *call_stmt,
program_state *state,
- uncertainty_t *uncertainty,
path_context *path_ctxt,
function *called_fn,
call_summary *summary,
--
2.37.3
[PATCH] IPA: support -flto + -flive-patching=inline-clone
There's no fundamental reason why -flive-patching=inline-clone can't
coexist with -flto. Yes, one can theoretically have many more clone
function that includes a live patch. It is pretty much the same
as in-module inlining.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
gcc/ChangeLog:
* opts.cc (finish_options): Print sorry message only
for -flive-patching=inline-only-static.
gcc/testsuite/ChangeLog:
* gcc.dg/live-patching-2.c: Update scanned pattern.
* gcc.dg/live-patching-5.c: New test.
---
gcc/opts.cc| 5 +++--
gcc/testsuite/gcc.dg/live-patching-2.c | 4 ++--
gcc/testsuite/gcc.dg/live-patching-5.c | 8
3 files changed, 13 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/live-patching-5.c
diff --git a/gcc/opts.cc b/gcc/opts.cc
index eb5db01de17..ae079fcd20e 100644
--- a/gcc/opts.cc
+++ b/gcc/opts.cc
@@ -1288,8 +1288,9 @@ finish_options (struct gcc_options *opts, struct
gcc_options *opts_set,
"%<-fsanitize=kernel-address%>");
/* Currently live patching is not support for LTO. */
- if (opts->x_flag_live_patching && opts->x_flag_lto)
-sorry ("live patching is not supported with LTO");
+ if (opts->x_flag_live_patching == LIVE_PATCHING_INLINE_ONLY_STATIC &&
opts->x_flag_lto)
+sorry ("live patching (with %qs) is not supported with LTO",
+ "inline-only-static");
/* Currently vtable verification is not supported for LTO */
if (opts->x_flag_vtable_verify && opts->x_flag_lto)
diff --git a/gcc/testsuite/gcc.dg/live-patching-2.c
b/gcc/testsuite/gcc.dg/live-patching-2.c
index 0dde4e9e0c0..1c4f9229b82 100644
--- a/gcc/testsuite/gcc.dg/live-patching-2.c
+++ b/gcc/testsuite/gcc.dg/live-patching-2.c
@@ -1,10 +1,10 @@
/* { dg-do compile } */
/* { dg-require-effective-target lto } */
-/* { dg-options "-O2 -flive-patching -flto" } */
+/* { dg-options "-O2 -flive-patching=inline-only-static -flto" } */
int main()
{
return 0;
}
-/* { dg-message "sorry, unimplemented: live patching is not supported with
LTO" "-flive-patching and -flto together" { target *-*-* } 0 } */
+/* { dg-message "sorry, unimplemented: live patching \\(with
'inline-only-static'\\) is not supported with LTO" "-flive-patching and -flto
together" { target *-*-* } 0 } */
diff --git a/gcc/testsuite/gcc.dg/live-patching-5.c
b/gcc/testsuite/gcc.dg/live-patching-5.c
new file mode 100644
index 000..098047a36cd
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/live-patching-5.c
@@ -0,0 +1,8 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target lto } */
+/* { dg-options "-O2 -flive-patching -flto" } */
+
+int main()
+{
+ return 0;
+}
--
2.37.3
[PATCH] c: support attribs starting with '_'
Support attributes starting with dash (like _noreturn, or __Noreturn). Note the only consumer of lookup_attribute_by_prefix comes from IPA ICF. Patch can bootstrap on x86_64-linux-gnu and survives regression tests. Ready to be installed? Thanks, Martin PR c/107156 gcc/ChangeLog: * attribs.h (lookup_attribute_by_prefix): Support attributes starting with dash (like _noreturn, or __Noreturn). --- gcc/attribs.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/gcc/attribs.h b/gcc/attribs.h index b2836560fc2..706d35e63d8 100644 --- a/gcc/attribs.h +++ b/gcc/attribs.h @@ -274,8 +274,6 @@ lookup_attribute_by_prefix (const char *attr_name, tree list) } const char *p = IDENTIFIER_POINTER (name); - gcc_checking_assert (attr_len == 0 || p[0] != '_'); - if (strncmp (attr_name, p, attr_len) == 0) break; -- 2.37.3
Re: [PATCH] c: support attribs starting with '_'
On Okt 05 2022, Martin Liška wrote: > * attribs.h (lookup_attribute_by_prefix): Support attributes > starting with dash (like _noreturn, or __Noreturn). s/dash/underscore/ -- Andreas Schwab, SUSE Labs, sch...@suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different."
[PATCH] c: support attribs starting with '_'
PR c/107156 gcc/ChangeLog: * attribs.h (lookup_attribute_by_prefix): Support attributes starting with underscore (like _noreturn, or __Noreturn). --- gcc/attribs.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/gcc/attribs.h b/gcc/attribs.h index b2836560fc2..706d35e63d8 100644 --- a/gcc/attribs.h +++ b/gcc/attribs.h @@ -274,8 +274,6 @@ lookup_attribute_by_prefix (const char *attr_name, tree list) } const char *p = IDENTIFIER_POINTER (name); - gcc_checking_assert (attr_len == 0 || p[0] != '_'); - if (strncmp (attr_name, p, attr_len) == 0) break; -- 2.37.3
Re: [PATCH] c: support attribs starting with '_'
On Wed, Oct 05, 2022 at 01:49:40PM +0200, Martin Liška wrote: > PR c/107156 > > gcc/ChangeLog: > > * attribs.h (lookup_attribute_by_prefix): Support attributes > starting with underscore (like _noreturn, or __Noreturn). There are no _noreturn or __Noreturn attributes, there is just _Noreturn. And, the assert is useful to catch that non-canonicalized attributes don't make it into the attribute lists. Now that we have the first attribute that starts with an underscore in canonicalized form (do we accept ___Noreturn__ attribute too, perhaps we shouldn't?), I'd say instead of removing the assert it should verify gcc_checking_assert (attr_len == 0 || p[0] != '_' || (ident_len > 1 && p[1] != '_')); ? > --- > gcc/attribs.h | 2 -- > 1 file changed, 2 deletions(-) > > diff --git a/gcc/attribs.h b/gcc/attribs.h > index b2836560fc2..706d35e63d8 100644 > --- a/gcc/attribs.h > +++ b/gcc/attribs.h > @@ -274,8 +274,6 @@ lookup_attribute_by_prefix (const char *attr_name, tree > list) > } > > const char *p = IDENTIFIER_POINTER (name); > - gcc_checking_assert (attr_len == 0 || p[0] != '_'); > - > if (strncmp (attr_name, p, attr_len) == 0) > break; > > -- > 2.37.3 Jakub
[PATCH 0/2] gcov: Split when edge locus differ from dest bb
Original discussion: https://gcc.gnu.org/pipermail/gcc/2022-October/239544.html Some tiny test additions as well as more accurate check for when to split edges for coverage. This patch preserves the edge splitting heuristic except using a slightly more precise comparison, but makes a huge difference for the condition profiling [1]. I compared the .gcov files for the gcc and g++ testsuites with and without this patch and found no differences, and bootstrapped on x86_64-linux. [1] https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598165.html Jørgen Kvalsvik (2): gcov: test switch/break line counts Split edge when edge locus and dest don't match gcc/profile.cc| 18 +- gcc/testsuite/g++.dg/gcov/gcov-1.C| 8 gcc/testsuite/gcc.misc-tests/gcov-4.c | 4 ++-- 3 files changed, 15 insertions(+), 15 deletions(-) -- 2.30.2
[PATCH 2/2] Split edge when edge locus and dest don't match
Edges with locus are candidates for splitting so that the edge with
locus is the only edge out of a basic block, except when the locuses
match. The test checks the last (non-debug) statement in a basic block,
but this causes an unnecessary split when the edge locus go to a block
which coincidentally has an unrelated label. Comparing the first
statement of the destination block is the same check but does not get
tripped up by labels.
An example with source/edge/dest locus when an edge is split:
1 int fn (int a, int b, int c) {
2int x = 0;
3if (a && b) {
4x = a;
5} else {
6 a_:
7x = (a - b);
8}
9
10return x;
11 }
block file line col stmt
src t.c 310 if (a_3(D) != 0)
edget.c 6 1
destt.c 6 1 a_:
src t.c 313 if (b_4(D) != 0)
edget.c 6 1
dst t.c 6 1 a_:
With label removed:
1 int fn (int a, int b, int c) {
2int x = 0;
3if (a && b) {
4x = a;
5} else {
6 // a_: <- label removed
7x = (a - b);
8}
9
10return x;
11
block file line col stmt
src t.c 310 if (a_3(D) != 0)
edge (null)0 0
destt.c 6 1 a_:
src t.c 313 if (b_4(D) != 0)
edge (null)0 0
dst t.c 6 1 a_:
and this is extract from gcov-4b.c which *should* split:
205 int
206 test_switch (int i, int j)
207 {
208int result = 0;
209
210switch (i)/* branch(80 25) */
211 /* branch(end) */
212 {
213case 1:
214 result = do_something (2);
215 break;
216case 2:
217 result = do_something (1024);
218 break;
219case 3:
220case 4:
221 if (j == 2) /* branch(67) */
222 /* branch(end) */
223return do_something (4);
224 result = do_something (8);
225 break;
226default:
227 result = do_something (32);
228 switch_m++;
229 break;
230 }
231return result;
231 }
block file line col stmt
src4b.c 21418 result_18 = do_something (2);
edge 4b.c 215 9
dst4b.c 23110 _22 = result_3;
src4b.c 21718 result_16 = do_something (1024);
edge 4b.c 218 9
dst4b.c 23110 _22 = result_3;
src4b.c 22418 result_12 = do_something (8);
edge 4b.c 225 9
dst4b.c 23110 _22 = result_3;
Note that the behaviour of comparison is preserved for the (switch) edge
splitting case. The former case now fails the check (even though
e->goto_locus is no longer a reserved location) because the dest matches
the e->locus.
gcc/ChangeLog:
* profile.cc (branch_prob): Compare edge locus to dest, not src.
---
gcc/profile.cc | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/gcc/profile.cc b/gcc/profile.cc
index 96121d60711..c13a79a84c2 100644
--- a/gcc/profile.cc
+++ b/gcc/profile.cc
@@ -1208,17 +1208,17 @@ branch_prob (bool thunk)
FOR_EACH_EDGE (e, ei, bb->succs)
{
gimple_stmt_iterator gsi;
- gimple *last = NULL;
+ gimple *dest = NULL;
/* It may happen that there are compiler generated statements
without a locus at all. Go through the basic block from the
last to the first statement looking for a locus. */
- for (gsi = gsi_last_nondebug_bb (bb);
+ for (gsi = gsi_start_nondebug_bb (bb);
!gsi_end_p (gsi);
- gsi_prev_nondebug (&gsi))
+ gsi_next_nondebug (&gsi))
{
- last = gsi_stmt (gsi);
- if (!RESERVED_LOCATION_P (gimple_location (last)))
+ dest = gsi_stmt (gsi);
+ if (!RESERVED_LOCATION_P (gimple_location (dest)))
break;
}
@@ -1227,14 +1227,14 @@ branch_prob (bool thunk)
Don't do that when the locuses match, so
if (blah) goto something;
is not computed twice. */
- if (last
- && gimple_has_location (last)
+ if (dest
+ && gimple_has_location (dest)
&& !RESERVED_LOCATION_P (e->goto_locus)
&& !single_succ_p (bb)
&& (LOCATION_FILE (e->goto_locus)
- != LOCATION_FILE (gimple_location (last))
+ != LOCATION_FILE (gimple_location (dest))
|| (LOCATION_LINE (e
[PATCH] c++: Improve handling of foreigner namespace attributes
Hi!
The following patch uses the new lookup_attribute overload and extra
tests to avoid emitting weird warnings on foreign namespace attributes
which we should just ignore (perhaps with a warning), but shouldn't
imply any meaning to them just because they have a name matching some
standard or gnu attribute name.
Lightly tested so far, ok for trunk if full bootstrap/regtest succeeds?
2022-10-05 Jakub Jelinek
gcc/c-family/
* c-common.cc (attribute_fallthrough_p): Lookup fallthrough attribute
only in gnu namespace or as standard attribute, treat fallthrough
attributes in other namespaces like any other unknown attribute.
gcc/cp/
* parser.cc (cp_parser_check_std_attribute): Only do checks if
attribute is a standard attribute or in gnu namespace and only
lookup other attributes in those namespaces.
* cp-gimplify.cc (lookup_hotness_attribute): Adjust function comment.
Only return true for standard attribute or gnu namespace attribute.
(remove_hotness_attribute): Only remove hotness attributes when
they are standard or in gnu namespace, implement it in a single
loop rather than former 4 now 8 remove_attribute calls.
gcc/testsuite/
* g++.dg/cpp1z/fallthrough2.C: New test.
* g++.dg/cpp2a/attr-likely7.C: New test.
--- gcc/c-family/c-common.cc.jj 2022-10-03 18:00:58.548661062 +0200
+++ gcc/c-family/c-common.cc2022-10-05 12:58:08.396043609 +0200
@@ -6007,12 +6007,15 @@ attribute_fallthrough_p (tree attr)
{
if (attr == error_mark_node)
return false;
- tree t = lookup_attribute ("fallthrough", attr);
+ tree t = lookup_attribute (NULL, "fallthrough", attr);
+ if (t == NULL_TREE)
+t = lookup_attribute ("gnu", "fallthrough", attr);
if (t == NULL_TREE)
return false;
/* It is no longer true that "this attribute shall appear at most once in
each attribute-list", but we still give a warning. */
- if (lookup_attribute ("fallthrough", TREE_CHAIN (t)))
+ if (lookup_attribute (NULL, "fallthrough", TREE_CHAIN (t))
+ || lookup_attribute ("gnu", "fallthrough", TREE_CHAIN (t)))
warning (OPT_Wattributes, "attribute % specified multiple "
"times");
/* No attribute-argument-clause shall be present. */
@@ -6023,9 +6026,11 @@ attribute_fallthrough_p (tree attr)
for (t = attr; t != NULL_TREE; t = TREE_CHAIN (t))
{
tree name = get_attribute_name (t);
- if (!is_attribute_p ("fallthrough", name))
+ tree ns = get_attribute_namespace (t);
+ if (!is_attribute_p ("fallthrough", name)
+ || (ns && !is_attribute_p ("gnu", ns)))
{
- if (!c_dialect_cxx () && get_attribute_namespace (t) == NULL_TREE)
+ if (!c_dialect_cxx () && ns == NULL_TREE)
/* The specifications of standard attributes in C mean
this is a constraint violation. */
pedwarn (input_location, OPT_Wattributes, "%qE attribute ignored",
--- gcc/cp/parser.cc.jj 2022-10-05 11:28:28.292141301 +0200
+++ gcc/cp/parser.cc2022-10-05 13:29:38.203433190 +0200
@@ -29265,7 +29265,10 @@ cp_parser_check_std_attribute (location_
if (attributes)
for (const auto &a : alist)
if (is_attribute_p (a, get_attribute_name (attribute))
- && lookup_attribute (a, attributes))
+ && (get_attribute_namespace (attribute) == NULL_TREE
+ || get_attribute_namespace (attribute) == gnu_identifier)
+ && (lookup_attribute (NULL, a, attributes)
+ || lookup_attribute ("gnu", a, attributes)))
{
if (!from_macro_expansion_at (loc))
warning_at (loc, OPT_Wattributes, "attribute %qs specified "
--- gcc/cp/cp-gimplify.cc.jj2022-10-05 11:19:19.160573401 +0200
+++ gcc/cp/cp-gimplify.cc 2022-10-05 12:53:08.367115180 +0200
@@ -3027,7 +3027,7 @@ cp_fold (tree x)
return x;
}
-/* Look up either "hot" or "cold" in attribute list LIST. */
+/* Look up "hot", "cold", "likely" or "unlikely" in attribute list LIST. */
tree
lookup_hotness_attribute (tree list)
@@ -3039,20 +3039,38 @@ lookup_hotness_attribute (tree list)
|| is_attribute_p ("cold", name)
|| is_attribute_p ("likely", name)
|| is_attribute_p ("unlikely", name))
- break;
+ {
+ tree ns = get_attribute_namespace (list);
+ if (ns == NULL_TREE || ns == gnu_identifier)
+ break;
+ }
}
return list;
}
-/* Remove both "hot" and "cold" attributes from LIST. */
+/* Remove "hot", "cold", "likely" and "unlikely" attributes from LIST. */
static tree
remove_hotness_attribute (tree list)
{
- list = remove_attribute ("hot", list);
- list = remove_attribute ("cold", list);
- list = remove_attribute ("likely", list);
- list = remove_attribute ("unlikely", list);
+ for (tree *p = &list; *p; )
+{
+ tree l = *p;
+ tree name = get_attribute_name (l);
+ if (is_attribute_p ("hot", name)
+ || is_attrib
[PATCH 1/2] gcov: test switch/break line counts
The coverage support will under some conditions decide to split edges to
accurately report coverage. By running the test suite with/without this
edge splitting a small diff shows up, addressed by this patch, which
should catch future regressions.
Removing the edge splitting:
diff --git a/gcc/profile.cc b/gcc/profile.cc
--- a/gcc/profile.cc
+++ b/gcc/profile.cc
@@ -1244,19 +1244,7 @@ branch_prob (bool thunk)
Don't do that when the locuses match, so
if (blah) goto something;
is not computed twice. */
- if (last
- && gimple_has_location (last)
- && !RESERVED_LOCATION_P (e->goto_locus)
- && !single_succ_p (bb)
- && (LOCATION_FILE (e->goto_locus)
- != LOCATION_FILE (gimple_location (last))
- || (LOCATION_LINE (e->goto_locus)
- != LOCATION_LINE (gimple_location (last)
- {
- basic_block new_bb = split_edge (e);
- edge ne = single_succ_edge (new_bb);
- ne->goto_locus = e->goto_locus;
- }
+
if ((e->flags & (EDGE_ABNORMAL | EDGE_ABNORMAL_CALL))
&& e->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
need_exit_edge = 1;
Assuming the .gcov files from make chec-gcc RUNTESTFLAGS=gcov.exp are
kept:
$ diff -r no-split-edge with-split-edge | grep -C 2 -E "^[<>]\s\s"
diff -r sans-split-edge/gcc/gcov-4.c.gcov with-split-edge/gcc/gcov-4.c.gcov
228c228
< -: 224:break;
---
> 1: 224:break;
231c231
< -: 227:break;
---
> #: 227:break;
237c237
< -: 233:break;
---
> 2: 233:break;
gcc/testsuite/ChangeLog:
* g++.dg/gcov/gcov-1.C: Add line count check.
* gcc.misc-tests/gcov-4.c: Likewise.
---
gcc/testsuite/g++.dg/gcov/gcov-1.C| 8
gcc/testsuite/gcc.misc-tests/gcov-4.c | 4 ++--
2 files changed, 6 insertions(+), 6 deletions(-)
diff --git a/gcc/testsuite/g++.dg/gcov/gcov-1.C
b/gcc/testsuite/g++.dg/gcov/gcov-1.C
index 9018b9a3a73..ee383b480a8 100644
--- a/gcc/testsuite/g++.dg/gcov/gcov-1.C
+++ b/gcc/testsuite/g++.dg/gcov/gcov-1.C
@@ -257,20 +257,20 @@ test_switch (int i, int j)
switch (i) /* count(5) */
/* branch(end) */
{
- case 1:
+ case 1: /* count(1) */
result = do_something (2); /* count(1) */
-break;
+break; /* count(1) */
case 2:
result = do_something (1024);
break;
- case 3:
+ case 3: /* count(3) */
case 4:
/* branch(67) */
if (j == 2)/* count(3) */
/* branch(end) */
return do_something (4); /* count(1) */
result = do_something (8); /* count(2) */
-break;
+break; /* count(2) */
default:
result = do_something (32); /* count(1) */
switch_m++; /* count(1) */
diff --git a/gcc/testsuite/gcc.misc-tests/gcov-4.c
b/gcc/testsuite/gcc.misc-tests/gcov-4.c
index 9d8ab1c1097..498d299b66b 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov-4.c
+++ b/gcc/testsuite/gcc.misc-tests/gcov-4.c
@@ -221,7 +221,7 @@ test_switch (int i, int j)
{
case 1:
result = do_something (2); /* count(1) */
-break;
+break; /* count(1) */
case 2:
result = do_something (1024);
break;
@@ -230,7 +230,7 @@ test_switch (int i, int j)
if (j == 2)/* count(3) */
return do_something (4); /* count(1) */
result = do_something (8); /* count(2) */
-break;
+break; /* count(2) */
default:
result = do_something (32); /* count(1) */
switch_m++; /* count(1) */
--
2.30.2
[COMMITTED] [PR tree-optimization/107052] range-ops: Pass nonzero masks through cast.
Track nonzero masks through a cast in range-ops.
We could also track through a truncating cast if the mask fits in the
outer type. I will do that as a follow-up patch because I already have
this patchset tested.
PR tree-optimization/107052
gcc/ChangeLog:
* range-op.cc (operator_cast::fold_range): Set nonzero mask.
---
gcc/range-op.cc | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 4f647abd91c..6fa27a8904e 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -2515,6 +2515,14 @@ operator_cast::fold_range (irange &r, tree type
ATTRIBUTE_UNUSED,
if (r.varying_p ())
return true;
}
+
+ // Pass nonzero mask through the cast.
+ if (!truncating_cast_p (inner, outer))
+{
+ wide_int nz = inner.get_nonzero_bits ();
+ nz = wide_int::from (nz, TYPE_PRECISION (type), TYPE_SIGN (inner.type
()));
+ r.set_nonzero_bits (nz);
+}
return true;
}
--
2.37.1
[COMMITTED] [PR tree-optimization/107052] range-ops: Pass nonzero masks through cast.
Track nonzero masks through a cast in range-ops.
We could also track through a truncating cast if the mask fits in the
outer type. I will do that as a follow-up patch because I already have
this patchset tested.
PR tree-optimization/107052
gcc/ChangeLog:
* range-op.cc (operator_cast::fold_range): Set nonzero mask.
---
gcc/range-op.cc | 8
1 file changed, 8 insertions(+)
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 4f647abd91c..6fa27a8904e 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -2515,6 +2515,14 @@ operator_cast::fold_range (irange &r, tree type
ATTRIBUTE_UNUSED,
if (r.varying_p ())
return true;
}
+
+ // Pass nonzero mask through the cast.
+ if (!truncating_cast_p (inner, outer))
+{
+ wide_int nz = inner.get_nonzero_bits ();
+ nz = wide_int::from (nz, TYPE_PRECISION (type), TYPE_SIGN (inner.type
()));
+ r.set_nonzero_bits (nz);
+}
return true;
}
--
2.37.1
[COMMITTED] [PR tree-optimization/107052] range-ops: Take into account nonzero mask in popcount.
PR tree-optimization/107052
gcc/ChangeLog:
* gimple-range-op.cc (cfn_popcount::fold_range): Take into account
nonzero bit mask.
---
gcc/gimple-range-op.cc | 15 ---
gcc/testsuite/gcc.dg/tree-ssa/pr107052.c | 13 +
2 files changed, 25 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/tree-ssa/pr107052.c
diff --git a/gcc/gimple-range-op.cc b/gcc/gimple-range-op.cc
index 5b71d1cce6d..42ebc7d6ce5 100644
--- a/gcc/gimple-range-op.cc
+++ b/gcc/gimple-range-op.cc
@@ -422,15 +422,24 @@ public:
virtual bool fold_range (irange &r, tree type, const irange &lh,
const irange &rh, relation_kind rel) const
{
+if (lh.undefined_p ())
+ return false;
+unsigned prec = TYPE_PRECISION (type);
+wide_int nz = lh.get_nonzero_bits ();
+wide_int pop = wi::shwi (wi::popcount (nz), prec);
// Calculating the popcount of a singleton is trivial.
if (lh.singleton_p ())
{
- wide_int nz = lh.get_nonzero_bits ();
- wide_int pop = wi::shwi (wi::popcount (nz), TYPE_PRECISION (type));
r.set (type, pop, pop);
return true;
}
-return cfn_ffs::fold_range (r, type, lh, rh, rel);
+if (cfn_ffs::fold_range (r, type, lh, rh, rel))
+ {
+ int_range<2> tmp (type, wi::zero (prec), pop);
+ r.intersect (tmp);
+ return true;
+ }
+return false;
}
} op_cfn_popcount;
diff --git a/gcc/testsuite/gcc.dg/tree-ssa/pr107052.c
b/gcc/testsuite/gcc.dg/tree-ssa/pr107052.c
new file mode 100644
index 000..88b5213160d
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tree-ssa/pr107052.c
@@ -0,0 +1,13 @@
+// { dg-do compile }
+// { dg-options "-O2 -fdump-tree-evrp" }
+
+void link_failure();
+void f(int a)
+{
+ a &= 0x300;
+ int b = __builtin_popcount(a);
+ if (b > 3)
+link_failure();
+}
+
+// { dg-final { scan-tree-dump-not "link_failure" "evrp" } }
--
2.37.1
Re: [PATCH 1/2] gcov: test switch/break line counts
On 10/5/22 14:04, Jørgen Kvalsvik via Gcc-patches wrote:
> The coverage support will under some conditions decide to split edges to
> accurately report coverage. By running the test suite with/without this
> edge splitting a small diff shows up, addressed by this patch, which
> should catch future regressions.
Thanks for the patch, it's OK (please apply it).
Martin
>
> Removing the edge splitting:
>
> diff --git a/gcc/profile.cc b/gcc/profile.cc
> --- a/gcc/profile.cc
> +++ b/gcc/profile.cc
> @@ -1244,19 +1244,7 @@ branch_prob (bool thunk)
> Don't do that when the locuses match, so
> if (blah) goto something;
> is not computed twice. */
> - if (last
> - && gimple_has_location (last)
> - && !RESERVED_LOCATION_P (e->goto_locus)
> - && !single_succ_p (bb)
> - && (LOCATION_FILE (e->goto_locus)
> - != LOCATION_FILE (gimple_location (last))
> - || (LOCATION_LINE (e->goto_locus)
> - != LOCATION_LINE (gimple_location (last)
> - {
> - basic_block new_bb = split_edge (e);
> - edge ne = single_succ_edge (new_bb);
> - ne->goto_locus = e->goto_locus;
> - }
> +
> if ((e->flags & (EDGE_ABNORMAL | EDGE_ABNORMAL_CALL))
> && e->dest != EXIT_BLOCK_PTR_FOR_FN (cfun))
> need_exit_edge = 1;
>
> Assuming the .gcov files from make chec-gcc RUNTESTFLAGS=gcov.exp are
> kept:
>
> $ diff -r no-split-edge with-split-edge | grep -C 2 -E "^[<>]\s\s"
> diff -r sans-split-edge/gcc/gcov-4.c.gcov with-split-edge/gcc/gcov-4.c.gcov
>228c228
>< -: 224:break;
>---
>> 1: 224:break;
>231c231
>< -: 227:break;
>---
>> #: 227:break;
>237c237
>< -: 233:break;
>---
>> 2: 233:break;
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/gcov/gcov-1.C: Add line count check.
> * gcc.misc-tests/gcov-4.c: Likewise.
> ---
> gcc/testsuite/g++.dg/gcov/gcov-1.C| 8
> gcc/testsuite/gcc.misc-tests/gcov-4.c | 4 ++--
> 2 files changed, 6 insertions(+), 6 deletions(-)
>
> diff --git a/gcc/testsuite/g++.dg/gcov/gcov-1.C
> b/gcc/testsuite/g++.dg/gcov/gcov-1.C
> index 9018b9a3a73..ee383b480a8 100644
> --- a/gcc/testsuite/g++.dg/gcov/gcov-1.C
> +++ b/gcc/testsuite/g++.dg/gcov/gcov-1.C
> @@ -257,20 +257,20 @@ test_switch (int i, int j)
>switch (i) /* count(5) */
> /* branch(end) */
> {
> - case 1:
> + case 1:/* count(1) */
> result = do_something (2); /* count(1) */
> -break;
> +break; /* count(1) */
>case 2:
> result = do_something (1024);
> break;
> - case 3:
> + case 3:/* count(3) */
>case 4:
> /* branch(67) */
> if (j == 2) /* count(3) */
> /* branch(end) */
>return do_something (4); /* count(1) */
> result = do_something (8); /* count(2) */
> -break;
> +break; /* count(2) */
>default:
> result = do_something (32); /* count(1) */
> switch_m++; /* count(1) */
> diff --git a/gcc/testsuite/gcc.misc-tests/gcov-4.c
> b/gcc/testsuite/gcc.misc-tests/gcov-4.c
> index 9d8ab1c1097..498d299b66b 100644
> --- a/gcc/testsuite/gcc.misc-tests/gcov-4.c
> +++ b/gcc/testsuite/gcc.misc-tests/gcov-4.c
> @@ -221,7 +221,7 @@ test_switch (int i, int j)
> {
>case 1:
> result = do_something (2); /* count(1) */
> -break;
> +break; /* count(1) */
>case 2:
> result = do_something (1024);
> break;
> @@ -230,7 +230,7 @@ test_switch (int i, int j)
> if (j == 2) /* count(3) */
>return do_something (4); /* count(1) */
> result = do_something (8); /* count(2) */
> -break;
> +break; /* count(2) */
>default:
> result = do_something (32); /* count(1) */
> switch_m++; /* count(1) */
Re: [Patch] Fortran: Add OpenMP's assume(s) directives
Minor update to just posted patch: the table did not revert all strings where a substring directive name existed, i.e. 'target' vs. 'target update', 'assume' vs. 'assumes'. Now fixed. Otherwise unchanged: Tobias On 05.10.22 13:19, Tobias Burnus wrote: Hi Jakub, On 04.10.22 14:58, Jakub Jelinek via Gcc-patches wrote: On Tue, Oct 04, 2022 at 02:26:13PM +0200, Tobias Burnus wrote: On Sun, Oct 02, 2022 at 07:47:18PM +0200, Tobias Burnus wrote: --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi OK? Ok, thanks. Committed as https://gcc.gnu.org/r13-3063-g8792047470073df0da4a5b91997d6058193d7676 Wouldn't this be better table driven (like c_omp_directives in c-family, though guess for Fortran you can just use spaces in the name, don't need 3 strings for the separate tokens)? Because I think absent/contains isn't the only spot where you need directive names, metadirective is another. Now added. I noted that I have different kinds/categories than you used in c-family/c-omp.c; and my impression that standalone vs. block vs delimited is a different category than informational/meta/... Maybe – I think there are already way to many string repetitions. One problem is that metadirectives permit combined/composite constructs while 'assume(s)' does not. I on purpose did not parse them, but probably in light of Metadirectives, I should. I will take a look. It is true that metadirective supports combined/composite constructs, and so do we in the C++ attribute case, still we IMHO can use the C/C++ table as is.and it doesn't need to include combined/composite constructs. The thing is that for the metadirective/C++ attribute case, all we need to know is to discover the directive category (declarative, stand-alone, construct, informational, ...) and for that it is enough to parse the first directive-name in combined/composite constructs. ... else if (popcount (old_n_absent) == 1) absent = ... sizeof() * (old_n_absent) * 2) Yeah. Or for 0 allocate say 8 and use (pow2p_hwi (old_n_absent) && old_n_absent >= 8) in the else if. I used now pow2p_hwi as popcount did not exist (and I didn't want to add an #include or use __builtin_popcount), not that either variant is clearer and it is neither performance critical nor is neither of "(x & -x) == x" and "popcount(x) == 1" slow. I don't understand the point of preallocation of gfc_omp_clauses here, ... That's now gone. As I have to check the duplication right after parsing – but before merging, I can no longer do it during resolution. Instead of keeping track of the directives separately, I now moved the checking to the directive parsing itself. It is not equivalent to that, because while we have the restriction that the same list item can't appear multiple times on the same directive, it can appear multiple times on multiple directives. I am not sure the handling of nested/repeated informational/declarative directives is very clear, but that's a separate issue. (Namely, OpenMP spec issue 3362.) Updated patch enclosed. And thanks for your comments! OK? Tobias - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955 Fortran: Add OpenMP's assume(s) directives libgomp/ChangeLog: * libgomp.texi (OpenMP 5.1 Impl. Status): Mark 'assume' as 'Y'. gcc/fortran/ChangeLog: * dump-parse-tree.cc (show_omp_assumes): New. (show_omp_clauses, show_namespace): Call it. (show_omp_node, show_code_node): Handle OpenMP ASSUME. * gfortran.h (enum gfc_statement): Add ST_OMP_ASSUME, ST_OMP_END_ASSUME, ST_OMP_ASSUMES and ST_NOTHING. (gfc_exec_op): Add EXEC_OMP_ASSUME. (gfc_omp_assumptions): New struct. (gfc_get_omp_assumptions): New XCNEW #define. (gfc_omp_clauses, gfc_namespace): Add assume member. (gfc_resolve_omp_assumptions): New prototype. * match.h (gfc_match_omp_assume, gfc_match_omp_assumes): New. * openmp.cc (omp_code_to_statement): Forward declare. (enum gfc_omp_directive_kind, struct gfc_omp_directive): New. (gfc_free_omp_clauses): Free assume member and its struct data. (enum omp_mask2): Add OMP_CLAUSE_ASSUMPTIONS. (gfc_omp_absent_contains_clause): New. (gfc_match_omp_clauses): Call it; optionally use passed omp_clauses argument. (omp_verify_merge_absent_contains, gfc_match_omp_assume, gfc_match_omp_assumes, gfc_resolve_omp_assumptions): New. (resolve_omp_clauses): Call the latter. (gfc_resolve_omp_directive, omp_code_to_statement): Handle EXEC_OMP_ASSUME. * parse.cc (decode_omp_directive): Parse OpenMP ASSUME(S). (next_statement, parse_executable, parse_omp_structured_block): Handle ST_OMP_ASSUME. (case_omp_decl): Add ST_OMP_ASSUMES. (gfc_ascii_statement): Handle Assumes, optional return string without '!$OMP '/'!$ACC ' prefix. * parse.h (gfc_ascii_statement): Add optional bool arg to prototype. * resolve.cc (gfc_re
[PATCH][AArch64] Improve bit tests [PR105773]
Since AArch64 sets all flags on logical operations, comparisons with zero
can be combined into an AND even if the condition is LE or GT.
Passes regress, OK for commit?
gcc:
PR target/105773
* config/aarch64/aarch64.cc (aarch64_select_cc_mode): Allow
GT/LE for merging compare with zero into AND.
(aarch64_get_condition_code_1): Support GT and LE in CC_NZmode.
gcc/testsuite:
PR target/105773
* gcc.target/aarch64/ands_2.c: Test for ANDS.
* gcc.target/aarch64/bics_2.c: Test for BICS.
* gcc.target/aarch64/tst_2.c: Test for TST.
* gcc.target/aarch64/tst_imm_split_1.c: Fix test.
---
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index
1601d11710cb6132c80a77bb4fe2f8429519aa5a..00876b08d8fbb1329a37a0ea73d3abf09d28b829
100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -11323,7 +11323,8 @@ aarch64_select_cc_mode (RTX_CODE code, rtx x, rtx y)
if ((mode_x == SImode || mode_x == DImode)
&& y == const0_rtx
- && (code == EQ || code == NE || code == LT || code == GE)
+ && (code == EQ || code == NE || code == LT || code == GE
+ || (code_x == AND && (code == GT || code == LE)))
&& (code_x == PLUS || code_x == MINUS || code_x == AND
|| code_x == NEG
|| (code_x == ZERO_EXTRACT && CONST_INT_P (XEXP (x, 1))
@@ -11471,6 +11472,8 @@ aarch64_get_condition_code_1 (machine_mode mode, enum
rtx_code comp_code)
case EQ: return AARCH64_EQ;
case GE: return AARCH64_PL;
case LT: return AARCH64_MI;
+ case GT: return AARCH64_GT;
+ case LE: return AARCH64_LE;
default: return -1;
}
break;
diff --git a/gcc/testsuite/gcc.target/aarch64/ands_2.c
b/gcc/testsuite/gcc.target/aarch64/ands_2.c
index
b061b1dfc59c1847cb799a1e49f8e5fc53bf2f14..c8763f234c5f7d19ef9c222756ab5e8a6eaae6fe
100644
--- a/gcc/testsuite/gcc.target/aarch64/ands_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/ands_2.c
@@ -8,8 +8,7 @@ ands_si_test1 (int a, int b, int c)
{
int d = a & b;
- /* { dg-final { scan-assembler-not "ands\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+" }
} */
- /* { dg-final { scan-assembler-times "and\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+"
2 } } */
+ /* { dg-final { scan-assembler "ands\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+" } } */
if (d <= 0)
return a + c;
else
@@ -21,12 +20,11 @@ ands_si_test2 (int a, int b, int c)
{
int d = a & 0x;
- /* { dg-final { scan-assembler-not "ands\tw\[0-9\]+, w\[0-9\]+, -1717986919"
} } */
- /* { dg-final { scan-assembler "and\tw\[0-9\]+, w\[0-9\]+, -1717986919" } }
*/
- if (d <= 0)
-return a + c;
- else
+ /* { dg-final { scan-assembler "ands\tw\[0-9\]+, w\[0-9\]+, -1717986919" } }
*/
+ if (d > 0)
return b + d + c;
+ else
+return a + c;
}
int
@@ -34,8 +32,7 @@ ands_si_test3 (int a, int b, int c)
{
int d = a & (b << 3);
- /* { dg-final { scan-assembler-not "ands\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+,
lsl 3" } } */
- /* { dg-final { scan-assembler "and\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+, lsl 3"
} } */
+ /* { dg-final { scan-assembler "ands\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+, lsl
3" } } */
if (d <= 0)
return a + c;
else
@@ -49,8 +46,7 @@ ands_di_test1 (s64 a, s64 b, s64 c)
{
s64 d = a & b;
- /* { dg-final { scan-assembler-not "ands\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+" }
} */
- /* { dg-final { scan-assembler-times "and\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+"
2 } } */
+ /* { dg-final { scan-assembler "ands\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+" } } */
if (d <= 0)
return a + c;
else
@@ -62,12 +58,11 @@ ands_di_test2 (s64 a, s64 b, s64 c)
{
s64 d = a & 0xll;
- /* { dg-final { scan-assembler-not "ands\tx\[0-9\]+, x\[0-9\]+,
-6148914691236517206" } } */
- /* { dg-final { scan-assembler "and\tx\[0-9\]+, x\[0-9\]+,
-6148914691236517206" } } */
- if (d <= 0)
-return a + c;
- else
+ /* { dg-final { scan-assembler "ands\tx\[0-9\]+, x\[0-9\]+,
-6148914691236517206" } } */
+ if (d > 0)
return b + d + c;
+ else
+return a + c;
}
s64
@@ -75,8 +70,7 @@ ands_di_test3 (s64 a, s64 b, s64 c)
{
s64 d = a & (b << 3);
- /* { dg-final { scan-assembler-not "ands\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+,
lsl 3" } } */
- /* { dg-final { scan-assembler "and\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+, lsl 3"
} } */
+ /* { dg-final { scan-assembler "ands\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+, lsl
3" } } */
if (d <= 0)
return a + c;
else
diff --git a/gcc/testsuite/gcc.target/aarch64/bics_2.c
b/gcc/testsuite/gcc.target/aarch64/bics_2.c
index
9ccae368c1276618bad691c78fb621a9c82794b7..c1f7e87a6121f7b067b7b37b149da64aa63ebd1a
100644
--- a/gcc/testsuite/gcc.target/aarch64/bics_2.c
+++ b/gcc/testsuite/gcc.target/aarch64/bics_2.c
@@ -8,8 +8,7 @@ bics_si_test1 (int a, int b, int c)
{
int d = a & ~b;
- /* { dg-final { scan-assembler-not "bics\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+" }
} */
- /* { dg-final { scan
Re: [PATCH] c++, c, v3: Implement C++23 P1774R8 - Portable assumptions [PR106654]
On 10/5/22 05:55, Jakub Jelinek wrote:
On Tue, Oct 04, 2022 at 04:42:04PM -0400, Jason Merrill wrote:
It could choose which function to call based on whether the constexpr_ctx
parameter is null?
Done, though it needs to be in constexpr.cc then because struct
constexpr_ctx and cxx_eval_constant_expression is local to constexpr.cc.
* attribs.h (remove_attribute): Declare overload with additional
attr_ns argument.
(private_lookup_attribute): Declare overload with additional
attr_ns and attr_ns_len arguments.
(lookup_attribute): New overload with additional attr_ns argument.
* attribs.cc (remove_attribute): New overload with additional
attr_ns argument.
(private_lookup_attribute): New overload with additional
attr_ns and attr_ns_len arguments.
I think go ahead and commit the attribs.{h,cc} changes separately.
Done last night.
@@ -8519,10 +8520,11 @@ cp_parser_parenthesized_expression_list
}
else
{
- expr
- = cp_parser_parenthesized_expression_list_elt (parser, cast_p,
-allow_expansion_p,
-non_constant_p);
+ if (is_attribute_list == assume_attr)
+ expr = cp_parser_conditional_expression (parser);
+ else
+ expr = cp_parser_parenthesized_expression_list_elt
+ (parser, cast_p, allow_expansion_p, non_constant_p);
This needs more parens to preserve this indentation.
I've changed the code some more and now the
cp_parser_parenthesized_expression_list_elt
call doesn't need reindentation and thus formatting uglification.
For some strange reason, the id_attr identifier case was setting
identifier variable and not pushing anything into the vector right away,
then at the very end it memmoved all the other elements one element to the
right and inserted the identifier there. That doesn't make any sense to me,
nothing is really looking at the expression_list vector until it is
returned, so I've just assigned the identifier to expr and handled it
like all other expressions.
+ else
+ {
Maybe
tree &arg = (*call_args)[0];
Good idea, changed.
Here is an updated, so far lightly tested, patch, ok if it passes
full bootstrap/regtest?
OK, thanks.
2022-10-05 Jakub Jelinek
PR c++/106654
gcc/
* internal-fn.def (ASSUME): New internal function.
* internal-fn.h (expand_ASSUME): Declare.
* internal-fn.cc (expand_ASSUME): Define.
* gimplify.cc (gimplify_call_expr): Gimplify IFN_ASSUME.
* fold-const.h (simple_condition_p): Declare.
* fold-const.cc (simple_operand_p_2): Rename to ...
(simple_condition_p): ... this. Remove forward declaration.
No longer static. Adjust function comment and fix a typo in it.
Adjust recursive call.
(simple_operand_p): Adjust function comment.
(fold_truth_andor): Adjust simple_operand_p_2 callers to call
simple_condition_p.
* doc/extend.texi: Document assume attribute. Move fallthrough
attribute example to its section.
gcc/c-family/
* c-attribs.cc (handle_assume_attribute): New function.
(c_common_attribute_table): Add entry for assume attribute.
* c-lex.cc (c_common_has_attribute): Handle
__have_cpp_attribute (assume).
gcc/c/
* c-parser.cc (handle_assume_attribute): New function.
(c_parser_declaration_or_fndef): Handle assume attribute.
(c_parser_attribute_arguments): Add assume_attr argument,
if true, parse first argument as conditional expression.
(c_parser_gnu_attribute, c_parser_std_attribute): Adjust
c_parser_attribute_arguments callers.
(c_parser_statement_after_labels) : Handle
assume attribute.
gcc/cp/
* cp-tree.h (process_stmt_assume_attribute): Implement C++23
P1774R8 - Portable assumptions. Declare.
(diagnose_failing_condition): Declare.
(find_failing_clause): Likewise.
* parser.cc (assume_attr): New enumerator.
(cp_parser_parenthesized_expression_list): Handle assume_attr.
Remove identifier variable, for id_attr push the identifier into
expression_list right away instead of inserting it before all the
others at the end.
(cp_parser_conditional_expression): New function.
(cp_parser_constant_expression): Use it.
(cp_parser_statement): Handle assume attribute.
(cp_parser_expression_statement): Likewise.
(cp_parser_gnu_attribute_list): Use assume_attr for assume
attribute.
(cp_parser_std_attribute): Likewise. Handle standard assume
attribute like gnu::assume.
* cp-gimplify.cc (process_stmt_assume_attribute): New function.
* constexpr.cc: Include fold-const.h.
(find_
[committed] libstdc++: Guard use of new built-in with __has_builtin
Tested x86_64-linux, pushed to trunk.
-- >8 --
Another case where I forgot that non-GCC compilers don't have this
built-in yet.
libstdc++-v3/ChangeLog:
* include/bits/invoke.h (__invoke_r): Check
__has_builtin(__reference_converts_from_temporary) before using
built-in.
---
libstdc++-v3/include/bits/invoke.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/libstdc++-v3/include/bits/invoke.h
b/libstdc++-v3/include/bits/invoke.h
index 8724a764f73..8fa8cf876d8 100644
--- a/libstdc++-v3/include/bits/invoke.h
+++ b/libstdc++-v3/include/bits/invoke.h
@@ -130,8 +130,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
{
using __result = __invoke_result<_Callable, _Args...>;
using __type = typename __result::type;
+#if __has_builtin(__reference_converts_from_temporary)
static_assert(!__reference_converts_from_temporary(_Res, __type),
"INVOKE must not create a dangling reference");
+#endif
using __tag = typename __result::__invoke_type;
return std::__invoke_impl<__type>(__tag{}, std::forward<_Callable>(__fn),
std::forward<_Args>(__args)...);
--
2.37.3
Re: [PATCH 2/2] Split edge when edge locus and dest don't match
On 10/5/22 14:04, Jørgen Kvalsvik via Gcc-patches wrote:
> Edges with locus are candidates for splitting so that the edge with
> locus is the only edge out of a basic block, except when the locuses
> match. The test checks the last (non-debug) statement in a basic block,
> but this causes an unnecessary split when the edge locus go to a block
> which coincidentally has an unrelated label. Comparing the first
> statement of the destination block is the same check but does not get
> tripped up by labels.
>
> An example with source/edge/dest locus when an edge is split:
>
> 1 int fn (int a, int b, int c) {
> 2int x = 0;
> 3if (a && b) {
> 4x = a;
> 5} else {
> 6 a_:
> 7x = (a - b);
> 8}
> 9
> 10return x;
> 11 }
>
> block file line col stmt
>
> src t.c 310 if (a_3(D) != 0)
> edget.c 6 1
> destt.c 6 1 a_:
>
> src t.c 313 if (b_4(D) != 0)
> edget.c 6 1
> dst t.c 6 1 a_:
>
> With label removed:
>
> 1 int fn (int a, int b, int c) {
> 2int x = 0;
> 3if (a && b) {
> 4x = a;
> 5} else {
> 6 // a_: <- label removed
> 7x = (a - b);
> 8}
> 9
> 10return x;
> 11
>
> block file line col stmt
>
> src t.c 310 if (a_3(D) != 0)
> edge (null)0 0
> destt.c 6 1 a_:
>
> src t.c 313 if (b_4(D) != 0)
> edge (null)0 0
> dst t.c 6 1 a_:
>
> and this is extract from gcov-4b.c which *should* split:
>
> 205 int
> 206 test_switch (int i, int j)
> 207 {
> 208int result = 0;
> 209
> 210switch (i)/* branch(80 25) */
> 211 /* branch(end) */
> 212 {
> 213case 1:
> 214 result = do_something (2);
> 215 break;
> 216case 2:
> 217 result = do_something (1024);
> 218 break;
> 219case 3:
> 220case 4:
> 221 if (j == 2) /* branch(67) */
> 222 /* branch(end) */
> 223return do_something (4);
> 224 result = do_something (8);
> 225 break;
> 226default:
> 227 result = do_something (32);
> 228 switch_m++;
> 229 break;
> 230 }
> 231return result;
> 231 }
>
> block file line col stmt
>
> src4b.c 21418 result_18 = do_something (2);
> edge 4b.c 215 9
> dst4b.c 23110 _22 = result_3;
>
> src4b.c 21718 result_16 = do_something (1024);
> edge 4b.c 218 9
> dst4b.c 23110 _22 = result_3;
>
> src4b.c 22418 result_12 = do_something (8);
> edge 4b.c 225 9
> dst4b.c 23110 _22 = result_3;
>
> Note that the behaviour of comparison is preserved for the (switch) edge
> splitting case. The former case now fails the check (even though
> e->goto_locus is no longer a reserved location) because the dest matches
> the e->locus.
It's fine, please install it.
I verified tramp3d coverage output is the same as before the patch.
Martin
>
> gcc/ChangeLog:
>
> * profile.cc (branch_prob): Compare edge locus to dest, not src.
> ---
> gcc/profile.cc | 18 +-
> 1 file changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/gcc/profile.cc b/gcc/profile.cc
> index 96121d60711..c13a79a84c2 100644
> --- a/gcc/profile.cc
> +++ b/gcc/profile.cc
> @@ -1208,17 +1208,17 @@ branch_prob (bool thunk)
> FOR_EACH_EDGE (e, ei, bb->succs)
> {
> gimple_stmt_iterator gsi;
> - gimple *last = NULL;
> + gimple *dest = NULL;
>
> /* It may happen that there are compiler generated statements
>without a locus at all. Go through the basic block from the
>last to the first statement looking for a locus. */
> - for (gsi = gsi_last_nondebug_bb (bb);
> + for (gsi = gsi_start_nondebug_bb (bb);
> !gsi_end_p (gsi);
> -gsi_prev_nondebug (&gsi))
> +gsi_next_nondebug (&gsi))
> {
> - last = gsi_stmt (gsi);
> - if (!RESERVED_LOCATION_P (gimple_location (last)))
> + dest = gsi_stmt (gsi);
> + if (!RESERVED_LOCATION_P (gimple_location (dest)))
> break;
> }
>
> @@ -1227,14 +1227,14 @@ branch_prob (bool thunk)
>Don't do that when the locuses match, so
>if (blah) goto something;
>is not computed twice. */
> - if (last
> - && gimple_has_
Re: [PATCH] c: support attribs starting with '_'
On 10/5/22 14:01, Jakub Jelinek wrote: > On Wed, Oct 05, 2022 at 01:49:40PM +0200, Martin Liška wrote: >> PR c/107156 >> >> gcc/ChangeLog: >> >> * attribs.h (lookup_attribute_by_prefix): Support attributes >> starting with underscore (like _noreturn, or __Noreturn). > > There are no _noreturn or __Noreturn attributes, there is just > _Noreturn. > And, the assert is useful to catch that non-canonicalized attributes > don't make it into the attribute lists. > Now that we have the first attribute that starts with an underscore > in canonicalized form (do we accept ___Noreturn__ attribute too, perhaps > we shouldn't?), I'd say instead of removing the assert it should verify > gcc_checking_assert (attr_len == 0 || p[0] != '_' >|| (ident_len > 1 && p[1] != '_')); Works for me, I'm going to install the following patch. Martin > ? >> --- >> gcc/attribs.h | 2 -- >> 1 file changed, 2 deletions(-) >> >> diff --git a/gcc/attribs.h b/gcc/attribs.h >> index b2836560fc2..706d35e63d8 100644 >> --- a/gcc/attribs.h >> +++ b/gcc/attribs.h >> @@ -274,8 +274,6 @@ lookup_attribute_by_prefix (const char *attr_name, tree >> list) >> } >> >>const char *p = IDENTIFIER_POINTER (name); >> - gcc_checking_assert (attr_len == 0 || p[0] != '_'); >> - >>if (strncmp (attr_name, p, attr_len) == 0) >> break; >> >> -- >> 2.37.3 > > Jakub > From b7eb1e7a0e887849470ec96c5f31422b2224c461 Mon Sep 17 00:00:00 2001 From: Martin Liska Date: Wed, 5 Oct 2022 12:34:30 +0200 Subject: [PATCH] c: support the attribute starting with '_' PR c/107156 gcc/ChangeLog: * attribs.h (lookup_attribute_by_prefix): Support the attribute starting with underscore (_Noreturn). --- gcc/attribs.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/attribs.h b/gcc/attribs.h index b2836560fc2..121b9ebbc39 100644 --- a/gcc/attribs.h +++ b/gcc/attribs.h @@ -274,8 +274,8 @@ lookup_attribute_by_prefix (const char *attr_name, tree list) } const char *p = IDENTIFIER_POINTER (name); - gcc_checking_assert (attr_len == 0 || p[0] != '_'); - + gcc_checking_assert (attr_len == 0 || p[0] != '_' + || (ident_len > 1 && p[1] != '_')); if (strncmp (attr_name, p, attr_len) == 0) break; -- 2.37.3
Re: [PATCH] c++ modules: lazy loading from within template [PR99377]
On Tue, 4 Oct 2022, Patrick Palka wrote:
> Here when lazily loading the binding for f at parse time from the
> template g, processing_template_decl is set and thus the call to
> note_vague_linkage_fn from module_state::read_cluster has no effect,
> and we never push f onto deferred_fns and end up never emitting its
> definition.
>
> ISTM the behavior of the lazy loading machinery shouldn't be sensitive
> to whether we're inside a template, and therefore we should probably be
> clearing processing_template_decl somewhere e.g in lazy_load_binding.
> This is sufficient to fix the testcase.
>
> But it also seems the processing_template_decl test in
> note_vague_linkage_fn, added by r8-7539-g977bc3ee11383e for PR84973, is
> perhaps too strong: if the intent is to avoid deferring output for
> uninstantiated templates, we should make sure that DECL in question is
> an uninstantiated template by checking e.g. value_dependent_expression_p.
> This too is sufficient to fix the testcase (since f isn't a template)
> and survives bootstrap and regtest.
>
> Does one or the other approach look like the correct fix for this PR?
>
> PR c++/99377
>
> gcc/cp/ChangeLog:
>
> * decl2.cc (note_vague_linkage_fn): Relax processing_template_decl
> test to value_dependent_expression_p.
> * module.cc (lazy_load_binding): Clear processing_template_decl.
>
> gcc/testsuite/ChangeLog:
>
> * g++.dg/modules/pr99377-2_a.C: New test.
> * g++.dg/modules/pr99377-2_b.C: New test.
> ---
> gcc/cp/decl2.cc| 2 +-
> gcc/cp/module.cc | 2 ++
> gcc/testsuite/g++.dg/modules/pr99377-2_a.C | 5 +
> gcc/testsuite/g++.dg/modules/pr99377-2_b.C | 6 ++
> 4 files changed, 14 insertions(+), 1 deletion(-)
> create mode 100644 gcc/testsuite/g++.dg/modules/pr99377-2_a.C
> create mode 100644 gcc/testsuite/g++.dg/modules/pr99377-2_b.C
>
> diff --git a/gcc/cp/decl2.cc b/gcc/cp/decl2.cc
> index 9f18466192f..5af4d17ee3b 100644
> --- a/gcc/cp/decl2.cc
> +++ b/gcc/cp/decl2.cc
> @@ -876,7 +876,7 @@ check_classfn (tree ctype, tree function, tree
> template_parms)
> void
> note_vague_linkage_fn (tree decl)
> {
> - if (processing_template_decl)
> + if (value_dependent_expression_p (decl))
> return;
>
>DECL_DEFER_OUTPUT (decl) = 1;
> diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
> index 500ac06563a..79cbb346ffa 100644
> --- a/gcc/cp/module.cc
> +++ b/gcc/cp/module.cc
> @@ -19074,6 +19074,8 @@ lazy_load_binding (unsigned mod, tree ns, tree id,
> binding_slot *mslot)
>
>timevar_start (TV_MODULE_IMPORT);
>
> + processing_template_decl_sentinel ptds;
> +
>/* Stop GC happening, even in outermost loads (because our caller
> could well be building up a lookup set). */
>function_depth++;
> diff --git a/gcc/testsuite/g++.dg/modules/pr99377-2_a.C
> b/gcc/testsuite/g++.dg/modules/pr99377-2_a.C
> new file mode 100644
> index 000..26e2bccbbbe
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/pr99377-2_a.C
> @@ -0,0 +1,5 @@
> +// PR c++/99377
> +// { dg-additional-options -fmodules-ts }
> +// { dg-module-cmi pr99377 }
> +export module pr99377;
> +export inline void f() { }
> diff --git a/gcc/testsuite/g++.dg/modules/pr99377-2_b.C
> b/gcc/testsuite/g++.dg/modules/pr99377-2_b.C
> new file mode 100644
> index 000..69571952c8a
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/modules/pr99377-2_b.C
> @@ -0,0 +1,6 @@
> +// PR c++/99377
> +// { dg-additional-options -fmodules-ts }
> +// { dg-do link }
> +import pr99377;
> +template void g() { f(); }
> +int main() { g(); }
This test can be simplified to:
import pr99377;
template void g() { f(); }
int main() { f(); }
which probably illustrates the bug better: we lazily load f at the
point of its first use, which in this case is in the (uninstantiated)
template g with processing_template_decl != 0. Thus during lazy loading
the call to note_vague_linkage_fn has no effect and we never emit the
definition of f.
[committed] libtdc++: Regenerate Makefile.in after freestanding header changes
I forgot to do this after applying Arsen's patches to my tree.
Tested x86_64-linux. Pushed to trunk.
-- >8 --
libstdc++-v3/ChangeLog:
* include/Makefile.in: Regenerate.
---
libstdc++-v3/include/Makefile.in | 101 +++
1 file changed, 49 insertions(+), 52 deletions(-)
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index 26d2f6a6d85..9d6075511f7 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -380,13 +380,6 @@ WARN_CXXFLAGS = \
# -I/-D flags to pass when compiling.
AM_CPPFLAGS = $(GLIBCXX_INCLUDES) $(CPPFLAGS)
-# Regarding *_freestanding:
-# For including files in freestanding, create a new _freestanding variable, and
-# split *_headers across an ``if GLIBCXX_HOSTED'', then update install-headers
-# to account for the new directory/set being added.
-# If such a variable exists, simply add to either *_headers or *_freestanding,
-# as appropriate.
-
# Standard C++ includes.
std_srcdir = ${glibcxx_srcdir}/include/std
std_builddir = .
@@ -395,20 +388,25 @@ std_freestanding = \
${std_srcdir}/array \
${std_srcdir}/atomic \
${std_srcdir}/bit \
+ ${std_srcdir}/bitset \
${std_srcdir}/concepts \
${std_srcdir}/coroutine \
+ ${std_srcdir}/expected \
${std_srcdir}/functional \
${std_srcdir}/iterator \
${std_srcdir}/limits \
${std_srcdir}/memory \
${std_srcdir}/numbers \
+ ${std_srcdir}/numeric \
${std_srcdir}/optional \
${std_srcdir}/ranges \
${std_srcdir}/ratio \
+ ${std_srcdir}/scoped_allocator \
${std_srcdir}/source_location \
${std_srcdir}/span \
${std_srcdir}/tuple \
${std_srcdir}/type_traits \
+ ${std_srcdir}/typeindex \
${std_srcdir}/utility \
${std_srcdir}/variant \
${std_srcdir}/version
@@ -418,7 +416,6 @@ std_freestanding = \
@GLIBCXX_HOSTED_TRUE@ ${std_freestanding} \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/any \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/barrier \
-@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/bitset \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/charconv \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/chrono \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/codecvt \
@@ -426,7 +423,6 @@ std_freestanding = \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/condition_variable \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/deque \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/execution \
-@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/expected \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/filesystem \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/forward_list \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/fstream \
@@ -442,12 +438,10 @@ std_freestanding = \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/map \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/memory_resource \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/mutex \
-@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/numeric \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/ostream \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/queue \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/random \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/regex \
-@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/scoped_allocator \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/semaphore \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/set \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/shared_mutex \
@@ -463,7 +457,6 @@ std_freestanding = \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/string_view \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/system_error \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/thread \
-@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/typeindex \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/unordered_map \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/unordered_set \
@GLIBCXX_HOSTED_TRUE@ ${std_srcdir}/valarray \
@@ -478,6 +471,7 @@ bits_freestanding = \
${bits_srcdir}/alloc_traits.h \
${bits_srcdir}/atomic_base.h \
${bits_srcdir}/c++0x_warning.h \
+ ${bits_srcdir}/boost_concept_check.h \
${bits_srcdir}/concept_check.h \
${bits_srcdir}/cpp_type_traits.h \
${bits_srcdir}/enable_special_members.h \
@@ -506,6 +500,7 @@ bits_freestanding = \
${bits_srcdir}/stl_iterator.h \
${bits_srcdir}/stl_iterator_base_funcs.h \
${bits_srcdir}/stl_iterator_base_types.h \
+ ${bits_srcdir}/stl_numeric.h \
${bits_srcdir}/stl_heap.h \
${bits_srcdir}/stl_pair.h \
${bits_srcdir}/stl_raw_storage_iter.h \
@@ -528,7 +523,6 @@ bits_freestanding = \
@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/basic_ios.tcc \
@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/basic_string.h \
@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/basic_string.tcc \
-@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/boost_concept_check.h \
@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/char_traits.h \
@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/charconv.h \
@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/chrono.h \
@@ -601,7 +595,6 @@ bits_freestanding = \
@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/stl_map.h \
@GLIBCXX_HOSTED_TRUE@ ${bits_srcdir}/stl_multimap.h \
@GLIBCXX_HOSTED_T
Re: [PATCH] c++: Define built-in for std::tuple_element [PR100157]
On Thu, 7 Jul 2022, Jonathan Wakely via Gcc-patches wrote:
> This adds a new built-in to replace the recursive class template
> instantiations done by traits such as std::tuple_element and
> std::variant_alternative. The purpose is to select the Nth type from a
> list of types, e.g. __builtin_type_pack_element(1, char, int, float) is
> int.
>
> For a pathological example tuple_element_t<1000, tuple<2000 types...>>
> the compilation time is reduced by more than 90% and the memory used by
> the compiler is reduced by 97%. In realistic examples the gains will be
> much smaller, but still relevant.
>
> Clang has a similar built-in, __type_pack_element, but that's a
> "magic template" built-in using <> syntax, which GCC doesn't support. So
> this provides an equivalent feature, but as a built-in function using
> parens instead of <>. I don't really like the name "type pack element"
> (it gives you an element from a pack of types) but the semi-consistency
> with Clang seems like a reasonable argument in favour of keeping the
> name. I'd be open to alternative names though, e.g. __builtin_nth_type
> or __builtin_type_at_index.
Rather than giving the trait a different name from __type_pack_element,
I wonder if we could just special case cp_parser_trait to expect <>
instead of parens for this trait?
Btw the frontend recently got a generic TRAIT_TYPE tree code, which gets
rid of much of the boilerplate of adding a new type-yielding built-in
trait, see e.g. cp-trait.def.
>
>
> The patch has some problems though ...
>
> FIXME 1: Marek pointed out that this this ICEs:
> template using type = __builtin_type_pack_element(sizeof(T),
> T...);
> type c;
>
> The sizeof(T) expression is invalid, because T is an unexpanded pack,
> but it's not rejected and instead crashes:
>
> ice.C: In substitution of 'template using type =
> __builtin_type_pack_element (sizeof (T), T ...) [with T = {int, char}]':
> ice.C:2:15: required from here
> ice.C:1:63: internal compiler error: in dependent_type_p, at cp/pt.cc:27490
> 1 | template using type =
> __builtin_type_pack_element(sizeof(T), T...);
> |
> ^
> 0xe13eea dependent_type_p(tree_node*)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:27490
> 0xeb1286 cxx_sizeof_or_alignof_type(unsigned int, tree_node*, tree_code,
> bool, bool)
> /home/jwakely/src/gcc/gcc/gcc/cp/typeck.cc:1912
> 0xdf4fcc tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
> bool)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:20582
> 0xdd9121 tsubst_tree_list(tree_node*, tree_node*, int, tree_node*)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:15587
> 0xddb583 tsubst(tree_node*, tree_node*, int, tree_node*)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:16056
> 0xddcc9d tsubst(tree_node*, tree_node*, int, tree_node*)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:16436
> 0xdd6d45 tsubst_decl
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:15038
> 0xdd952a tsubst(tree_node*, tree_node*, int, tree_node*)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:15668
> 0xdfb9a1 instantiate_template(tree_node*, tree_node*, int)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:21811
> 0xdfc1b6 instantiate_alias_template
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:21896
> 0xdd9796 tsubst(tree_node*, tree_node*, int, tree_node*)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:15696
> 0xdbaba5 lookup_template_class(tree_node*, tree_node*, tree_node*,
> tree_node*, int, int)
> /home/jwakely/src/gcc/gcc/gcc/cp/pt.cc:10131
> 0xe4bac0 finish_template_type(tree_node*, tree_node*, int)
> /home/jwakely/src/gcc/gcc/gcc/cp/semantics.cc:3727
> 0xd334c8 cp_parser_template_id
> /home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:18458
> 0xd429b0 cp_parser_class_name
> /home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:25923
> 0xd1ade9 cp_parser_qualifying_entity
> /home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:7193
> 0xd1a2c8 cp_parser_nested_name_specifier_opt
> /home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:6875
> 0xd4eefd cp_parser_template_introduction
> /home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:31668
> 0xd4f416 cp_parser_template_declaration_after_export
> /home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:31840
> 0xd2d60e cp_parser_declaration
> /home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:15083
>
>
> FIXME 2: I want to mangle __builtin_type_pack_element(N, T...) the same as
> typename std::_Nth_type::type but I don't know how. Instead of
> trying to fake the mangled string, it's probably better to build a decl
> for that nested type, right? Any suggestions where to find something
> similar I can learn from?
>
> The reason to mangle it that way is that it preserves the same symbol
> names as the library produced in GCC 12, and that it will still produce
> with non-GCC compilers (see the definitions of std::_Nth_type in the
> library parts of the patch). If we
Re: [PATCH] middle-end, c++, i386, libgcc: std::bfloat16_t and __bf16 arithmetic support
On Tue, Oct 04, 2022 at 05:50:50PM -0400, Jason Merrill wrote:
> > Another question is the suffixes of the builtins. For now I have added
> > bf16 suffix and enabled the builtins with !both_p, so one always needs to
> > use __builtin_* form for them. None of the GCC builtins end with b,
> > so this isn't ambiguous with __builtin_*f16, but some libm functions do end
> > with b, in particular ilogb, logb and f{??,??x}sub. ilogb and the subs
> > always have it, but is __builtin_logbf16 f16 suffixed logb or bf16 suffixed
> > log? Shall the builtins use f16b suffixes instead like the mangling does?
>
> Do we want bf16 builtins at all? The impression I've gotten is that users
> want computation to happen in SFmode and only later truncate back to BFmode.
As I wrote earlier, I think we need at least one, __builtin_nans variant
which would be used in libstdc++
std::numeric_limits::signaling_NaN() implementation.
I think
std::numeric_limits::infinity() can be implemented as
return (__bf16) __builtin_huge_valf ();
and similarly
std::numeric_limits::quiet_NaN() as
return (__bf16) __builtin_nanf ("");
but
return (__bf16) __builtin_nansf ("");
would loose the signaling NaN on the conversion and raise exception,
and as the method is constexpr,
union { unsigned short a; __bf16 b; } u = { 0x7f81 };
return u.b;
wouldn't work. I can certainly restrict the builtins to the single
one, but wonder whether the suffix for that builtin shouldn't be chosen
such that eventually we could add more builtins if we need to
and don't run into the log with bf16 suffix vs. logb with f16 suffix
ambiguity.
As you said, most of the libstdc++ overloads for std::bfloat16_t then
can use float builtins or library calls under the hood, but std::nextafter
is another case where I think we'll need to have something bfloat16_t
specific, because float ulp isn't bfloat16_t ulp, the latter is much larger.
Based on what Joseph wrote, I'll add bf16/BF16 suffix support for C too
in the next iteration (always with pedwarn in that case).
> > @@ -5716,7 +5716,13 @@ emit_store_flag_1 (rtx target, enum rtx_
> > {
> >machine_mode optab_mode = mclass == MODE_CC ? CCmode : compare_mode;
> >icode = optab_handler (cstore_optab, optab_mode);
> > - if (icode != CODE_FOR_nothing)
> > + if (icode != CODE_FOR_nothing
> > +/* Don't consider [BH]Fmode as usable wider mode, as neither is
> > + a subset or superset of the other. */
> > +&& (compare_mode == mode
> > +|| !SCALAR_FLOAT_MODE_P (compare_mode)
> > +|| maybe_ne (GET_MODE_PRECISION (compare_mode),
> > + GET_MODE_PRECISION (mode
>
> Why do you need to do this here (and in prepare_cmp_insn, and similarly in
> can_compare_p)? Shouldn't get_wider skip over modes that are not actually
> wider?
I'm afraid too many places rely on all modes of a certain class to be
visible when walking from "narrowest" to "widest" mode, say
FOR_EACH_MODE_IN_CLASS/FOR_EACH_MODE/FOR_EACH_MODE_UNTIL/FOR_EACH_WIDER_MODE
etc. wouldn't work at all if GET_MODE_WIDER_MODE (BFmode) == SFmode
&& GET_MODE_WIDER_MODE (HFmode) == SFmode.
Note, besides this GET_MODE_PRECISION (HFmode) == GET_MODE_PRECISION (BFmode)
case, another set of modes which have the same size are powerpc*
TFmode/IFmode/KFmode, but in that case it makes ugly hacks where it
artificially lowers the precision of 2 of them:
rs6000-modes.h:#define FLOAT_PRECISION_IFmode 128
rs6000-modes.h:#define FLOAT_PRECISION_TFmode 127
rs6000-modes.h:#define FLOAT_PRECISION_KFmode 126
(and the middle-end then has to work around that mess). Doing something
similar wouldn't help the BFmode vs. HFmode case though, one of them would
have wider precision and so e.g. C FE would then prefer it, but more
importantly, as they are unordered modes where most of the optabs aren't
implemented it is bad to pick optabs for the "wider" mode to handle the
"narrower" one. I think powerpc works because they define optabs for
all the 3 modes when those modes are usable.
Jakub
[COMMITTED] range-op: Keep nonzero mask up to date with truncating casts.
gcc/ChangeLog:
* range-op.cc (operator_cast::fold_range): Handle truncating casts
for nonzero masks.
---
gcc/range-op.cc | 18 +++---
1 file changed, 11 insertions(+), 7 deletions(-)
diff --git a/gcc/range-op.cc b/gcc/range-op.cc
index 6fa27a8904e..df0735cb42a 100644
--- a/gcc/range-op.cc
+++ b/gcc/range-op.cc
@@ -2516,13 +2516,17 @@ operator_cast::fold_range (irange &r, tree type
ATTRIBUTE_UNUSED,
return true;
}
- // Pass nonzero mask through the cast.
- if (!truncating_cast_p (inner, outer))
-{
- wide_int nz = inner.get_nonzero_bits ();
- nz = wide_int::from (nz, TYPE_PRECISION (type), TYPE_SIGN (inner.type
()));
- r.set_nonzero_bits (nz);
-}
+ // Update the nonzero mask. Truncating casts are problematic unless
+ // the conversion fits in the resulting outer type.
+ wide_int nz = inner.get_nonzero_bits ();
+ if (truncating_cast_p (inner, outer)
+ && wi::rshift (nz, wi::uhwi (TYPE_PRECISION (outer.type ()),
+ TYPE_PRECISION (inner.type ())),
+TYPE_SIGN (inner.type ())) != 0)
+return true;
+ nz = wide_int::from (nz, TYPE_PRECISION (type), TYPE_SIGN (inner.type ()));
+ r.set_nonzero_bits (nz);
+
return true;
}
--
2.37.1
Re: [PATCH] RISC-V: Introduce RVV header to enable builtin types
Committed, thanks :)
On Fri, Sep 30, 2022 at 2:59 PM wrote:
>
> From: Ju-Zhe Zhong
>
> gcc/ChangeLog:
>
> * config.gcc: Add riscv_vector.h.
> * config/riscv/riscv-builtins.cc: Add RVV builtin types support.
> * config/riscv/riscv-c.cc (riscv_pragma_intrinsic): New function.
> (riscv_register_pragmas): Ditto.
> * config/riscv/riscv-protos.h (riscv_register_pragmas): Ditto.
> (init_builtins): Move declaration from riscv-vector-builtins.h to
> riscv-protos.h.
> (mangle_builtin_type): Ditto.
> (verify_type_context): Ditto.
> (handle_pragma_vector): New function.
> * config/riscv/riscv-vector-builtins.cc (GTY): New variable.
> (register_vector_type): New function.
> (init_builtins): Add RVV builtin types support.
> (handle_pragma_vector): New function.
> * config/riscv/riscv-vector-builtins.h (GCC_RISCV_V_BUILTINS_H):
> Change name according to file name.
> (GCC_RISCV_VECTOR_BUILTINS_H): Ditto.
> (init_builtins): Remove declaration in riscv-vector-builtins.h.
> (mangle_builtin_type): Ditto.
> (verify_type_context): Ditto.
> * config/riscv/riscv.cc: Adjust for RVV builtin types support.
> * config/riscv/riscv.h (REGISTER_TARGET_PRAGMAS): New macro.
> * config/riscv/t-riscv: Remove redundant file including.
> * config/riscv/riscv_vector.h: New file.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/riscv/rvv/base/pragma-1.c: New test.
> * gcc.target/riscv/rvv/base/pragma-2.c: New test.
> * gcc.target/riscv/rvv/base/pragma-3.c: New test.
> * gcc.target/riscv/rvv/base/user-1.c: New test.
> * gcc.target/riscv/rvv/base/user-2.c: New test.
> * gcc.target/riscv/rvv/base/user-3.c: New test.
> * gcc.target/riscv/rvv/base/user-4.c: New test.
> * gcc.target/riscv/rvv/base/user-5.c: New test.
> * gcc.target/riscv/rvv/base/user-6.c: New test.
> * gcc.target/riscv/rvv/base/vread_csr.c: New test.
> * gcc.target/riscv/rvv/base/vwrite_csr.c: New test.
>
> ---
> gcc/config.gcc| 1 +
> gcc/config/riscv/riscv-builtins.cc| 2 +-
> gcc/config/riscv/riscv-c.cc | 41 +++
> gcc/config/riscv/riscv-protos.h | 11 ++
> gcc/config/riscv/riscv-vector-builtins.cc | 45
> gcc/config/riscv/riscv-vector-builtins.h | 13 +--
> gcc/config/riscv/riscv.cc | 7 +-
> gcc/config/riscv/riscv.h | 2 +
> gcc/config/riscv/riscv_vector.h | 100 ++
> gcc/config/riscv/t-riscv | 2 +-
> .../gcc.target/riscv/rvv/base/pragma-1.c | 4 +
> .../gcc.target/riscv/rvv/base/pragma-2.c | 4 +
> .../gcc.target/riscv/rvv/base/pragma-3.c | 4 +
> .../gcc.target/riscv/rvv/base/user-1.c| 65
> .../gcc.target/riscv/rvv/base/user-2.c| 65
> .../gcc.target/riscv/rvv/base/user-3.c| 65
> .../gcc.target/riscv/rvv/base/user-4.c| 65
> .../gcc.target/riscv/rvv/base/user-5.c| 65
> .../gcc.target/riscv/rvv/base/user-6.c| 65
> .../gcc.target/riscv/rvv/base/vread_csr.c | 26 +
> .../gcc.target/riscv/rvv/base/vwrite_csr.c| 26 +
> 21 files changed, 665 insertions(+), 13 deletions(-)
> create mode 100644 gcc/config/riscv/riscv_vector.h
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pragma-1.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pragma-2.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/pragma-3.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/user-1.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/user-2.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/user-3.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/user-4.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/user-5.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/user-6.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vread_csr.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/vwrite_csr.c
>
> diff --git a/gcc/config.gcc b/gcc/config.gcc
> index 7eb07870425..1dd408d1ade 100644
> --- a/gcc/config.gcc
> +++ b/gcc/config.gcc
> @@ -518,6 +518,7 @@ riscv*)
> extra_objs="riscv-builtins.o riscv-c.o riscv-sr.o
> riscv-shorten-memrefs.o riscv-selftests.o"
> extra_objs="${extra_objs} riscv-vector-builtins.o"
> d_target_objs="riscv-d.o"
> + extra_headers="riscv_vector.h"
> ;;
> rs6000*-*-*)
> extra_options="${extra_options} g.opt fused-madd.opt
> rs6000/rs6000-tables.opt"
> diff --git a/gcc/config/riscv/riscv-builtins.cc
> b/gcc/config/riscv/riscv-builtins.cc
> index a51037a8f7a..14865d70955 1
Re: [GCC13][Patch][V5][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array
> On Oct 4, 2022, at 1:37 PM, Joseph Myers wrote:
>
> On Tue, 4 Oct 2022, Qing Zhao via Gcc-patches wrote:
>
>> + { "strict_flex_array", 1, 1, false, false, false, false,
>> + handle_strict_flex_array_attribute, NULL },
>
> You're not requiring that the attribute be applied to a declaration here.
Okay, so, you mean I need to require the attribute to be applied to a
declaration as following:
{ "strict_flex_array", 1, 1, true, false, false, false,
handle_strict_flex_array_attribute, NULL },
?
Then when the attribute is attached to the type of the decl, the ICE will not
happen? (Yes, I tried, and the ICE was replaced with the following warning:
/home/opc/Install/lates/bin/gcc t.c
t.c:1:1: warning: ‘strict_flex_array’ attribute does not apply to types
[-Wattributes]
1 | int [[gnu::strict_flex_array(1)]] x;
| ^~~
Thanks, I will update the patch with this.
Let me know if you have more comments.
Qing
>
>> +static tree
>> +handle_strict_flex_array_attribute (tree *node, tree name,
>> +tree args, int ARG_UNUSED (flags),
>> +bool *no_add_attrs)
>> +{
>> + tree decl = *node;
>> + tree argval = TREE_VALUE (args);
>> +
>> + /* This attribute only applies to field decls of a structure. */
>> + if (TREE_CODE (decl) != FIELD_DECL)
>> +{
>> + error_at (DECL_SOURCE_LOCATION (decl),
>> +"%qE attribute may not be specified for %q+D", name, decl);
>
> But here you're using DECL_SOURCE_LOCATION on what might be a type, not a
> DECL. So if you have a test such as
>
> int [[gnu::strict_flex_array(1)]] x;
>
> that applies the attribute to a type, you get an ICE:
>
> t.c:1:1: internal compiler error: tree check: expected tree that contains
> 'decl minimal' structure, have 'integer_type' in
> handle_strict_flex_array_attribute, at c-family/c-attribs.cc:2526
>1 | int [[gnu::strict_flex_array(1)]] x;
> | ^~~
>
> --
> Joseph S. Myers
> jos...@codesourcery.com
[pushed] c++: lvalue_kind tweak
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
I was wondering how lvalue_kind handles VIEW_CONVERT_EXPR; in cases where
the type actually changes, it should have the same prvalue->xvalue effect as
ARRAY_REF, since we need to materialize a temporary to get an object we can
reinterpret as another type.
Currently this only fires on builtin-shufflevector-3.c, where we use
VIEW_CONVERT_EXPR to reinterpret a vector as an array.
REALPART_EXPR and IMAGPART_EXPR should also be treated like COMPONENT_REF.
PREINCREMENT_EXPR and PREDECREMENT_EXPR should only be applied to glvalues,
but if for some reason they were applied to a prvalue this would be correct.
TRY_CATCH_EXPR around a prvalue is also questionable, but this is the right
handling.
gcc/cp/ChangeLog:
* tree.cc (lvalue_kind) [VIEW_CONVERT_EXPR]: Change prvalue to
xvalue.
---
gcc/cp/tree.cc | 12 +++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/gcc/cp/tree.cc b/gcc/cp/tree.cc
index aa9c1b7d8f9..6d968a2af11 100644
--- a/gcc/cp/tree.cc
+++ b/gcc/cp/tree.cc
@@ -104,7 +104,17 @@ lvalue_kind (const_tree ref)
case REALPART_EXPR:
case IMAGPART_EXPR:
case VIEW_CONVERT_EXPR:
- return lvalue_kind (TREE_OPERAND (ref, 0));
+ op1_lvalue_kind = lvalue_kind (TREE_OPERAND (ref, 0));
+ /* As for ARRAY_REF and COMPONENT_REF, these codes turn a class prvalue
+into an xvalue: we need to materialize the temporary before we mess
+with it. Except VIEW_CONVERT_EXPR that doesn't actually change the
+type, as in location wrapper and REF_PARENTHESIZED_P. */
+ if (op1_lvalue_kind == clk_class
+ && !(TREE_CODE (ref) == VIEW_CONVERT_EXPR
+ && (same_type_ignoring_top_level_qualifiers_p
+ (TREE_TYPE (ref), TREE_TYPE (TREE_OPERAND (ref, 0))
+ return clk_rvalueref;
+ return op1_lvalue_kind;
case ARRAY_REF:
{
base-commit: 7d935cdd1a6772699ec0ab4f93711928ca4d30a1
--
2.31.1
Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone
Hi, Martin:
I have two questions on this:
1. What’s the motivation to enable -flive-patching with -flto? Is there any
application that will try -flive-patching with -flto now?
2. Why only enable -flive-patching=inline-clone with -flto?
thanks.
Qing
> On Oct 5, 2022, at 7:41 AM, Martin Liška wrote:
>
> There's no fundamental reason why -flive-patching=inline-clone can't
> coexist with -flto. Yes, one can theoretically have many more clone
> function that includes a live patch. It is pretty much the same
> as in-module inlining.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> * opts.cc (finish_options): Print sorry message only
> for -flive-patching=inline-only-static.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.dg/live-patching-2.c: Update scanned pattern.
> * gcc.dg/live-patching-5.c: New test.
> ---
> gcc/opts.cc| 5 +++--
> gcc/testsuite/gcc.dg/live-patching-2.c | 4 ++--
> gcc/testsuite/gcc.dg/live-patching-5.c | 8
> 3 files changed, 13 insertions(+), 4 deletions(-)
> create mode 100644 gcc/testsuite/gcc.dg/live-patching-5.c
>
> diff --git a/gcc/opts.cc b/gcc/opts.cc
> index eb5db01de17..ae079fcd20e 100644
> --- a/gcc/opts.cc
> +++ b/gcc/opts.cc
> @@ -1288,8 +1288,9 @@ finish_options (struct gcc_options *opts, struct
> gcc_options *opts_set,
> "%<-fsanitize=kernel-address%>");
>
> /* Currently live patching is not support for LTO. */
> - if (opts->x_flag_live_patching && opts->x_flag_lto)
> -sorry ("live patching is not supported with LTO");
> + if (opts->x_flag_live_patching == LIVE_PATCHING_INLINE_ONLY_STATIC &&
> opts->x_flag_lto)
> +sorry ("live patching (with %qs) is not supported with LTO",
> +"inline-only-static");
>
> /* Currently vtable verification is not supported for LTO */
> if (opts->x_flag_vtable_verify && opts->x_flag_lto)
> diff --git a/gcc/testsuite/gcc.dg/live-patching-2.c
> b/gcc/testsuite/gcc.dg/live-patching-2.c
> index 0dde4e9e0c0..1c4f9229b82 100644
> --- a/gcc/testsuite/gcc.dg/live-patching-2.c
> +++ b/gcc/testsuite/gcc.dg/live-patching-2.c
> @@ -1,10 +1,10 @@
> /* { dg-do compile } */
> /* { dg-require-effective-target lto } */
> -/* { dg-options "-O2 -flive-patching -flto" } */
> +/* { dg-options "-O2 -flive-patching=inline-only-static -flto" } */
>
> int main()
> {
> return 0;
> }
>
> -/* { dg-message "sorry, unimplemented: live patching is not supported with
> LTO" "-flive-patching and -flto together" { target *-*-* } 0 } */
> +/* { dg-message "sorry, unimplemented: live patching \\(with
> 'inline-only-static'\\) is not supported with LTO" "-flive-patching and -flto
> together" { target *-*-* } 0 } */
> diff --git a/gcc/testsuite/gcc.dg/live-patching-5.c
> b/gcc/testsuite/gcc.dg/live-patching-5.c
> new file mode 100644
> index 000..098047a36cd
> --- /dev/null
> +++ b/gcc/testsuite/gcc.dg/live-patching-5.c
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-require-effective-target lto } */
> +/* { dg-options "-O2 -flive-patching -flto" } */
> +
> +int main()
> +{
> + return 0;
> +}
> --
> 2.37.3
>
Re: [PATCH][GCC 12] arm: Fix constant immediates predicates and constraints for some MVE builtins
ping? On 9/12/22 10:13, Christophe Lyon via Gcc-patches wrote: Hi! On 9/9/22 11:33, Christophe Lyon wrote: This is a backport from trunk to gcc-12. Several MVE builtins incorrectly use the same predicate/constraint pair for several modes, which does not match the specification. This patch uses the appropriate iterator instead. 2022-09-06 Christophe Lyon gcc/ * config/arm/mve.md (mve_vqshluq_n_s): Use MVE_pred/MVE_constraint instead of mve_imm_7/Ra. (mve_vqshluq_m_n_s): Likewise. (mve_vqrshrnbq_n_): Use MVE_pred3/MVE_constraint3 instead of mve_imm_8/Rb. (mve_vqrshrunbq_n_s): Likewise. (mve_vqrshrntq_n_): Likewise. (mve_vqrshruntq_n_s): Likewise. (mve_vrshrnbq_n_): Likewise. (mve_vrshrntq_n_): Likewise. (mve_vqrshrnbq_m_n_): Likewise. (mve_vqrshrntq_m_n_): Likewise. (mve_vrshrnbq_m_n_): Likewise. (mve_vrshrntq_m_n_): Likewise. (mve_vqrshrunbq_m_n_s): Likewise. (mve_vsriq_n_): Likewise. (cheerry-picked from c3fb6658c7670e446f2fd00984404d971e416b3c) Is this backport OK for gcc-12? (with the "cheerry" typo above fixed) Thanks, Christophe --- gcc/config/arm/mve.md | 30 +++--- 1 file changed, 15 insertions(+), 15 deletions(-) diff --git a/gcc/config/arm/mve.md b/gcc/config/arm/mve.md index f16991c0a34..469e7e7f8dc 100644 --- a/gcc/config/arm/mve.md +++ b/gcc/config/arm/mve.md @@ -1617,7 +1617,7 @@ (define_insn "mve_vqshluq_n_s" [ (set (match_operand:MVE_2 0 "s_register_operand" "=w") (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "w") - (match_operand:SI 2 "mve_imm_7" "Ra")] + (match_operand:SI 2 "" "")] VQSHLUQ_N_S)) ] "TARGET_HAVE_MVE" @@ -2608,7 +2608,7 @@ (define_insn "mve_vqrshrnbq_n_" (set (match_operand: 0 "s_register_operand" "=w") (unspec: [(match_operand: 1 "s_register_operand" "0") (match_operand:MVE_5 2 "s_register_operand" "w") - (match_operand:SI 3 "mve_imm_8" "Rb")] + (match_operand:SI 3 "" "")] VQRSHRNBQ_N)) ] "TARGET_HAVE_MVE" @@ -2623,7 +2623,7 @@ (define_insn "mve_vqrshrunbq_n_s" (set (match_operand: 0 "s_register_operand" "=w") (unspec: [(match_operand: 1 "s_register_operand" "0") (match_operand:MVE_5 2 "s_register_operand" "w") - (match_operand:SI 3 "mve_imm_8" "Rb")] + (match_operand:SI 3 "" "")] VQRSHRUNBQ_N_S)) ] "TARGET_HAVE_MVE" @@ -3563,7 +3563,7 @@ (define_insn "mve_vsriq_n_" (set (match_operand:MVE_2 0 "s_register_operand" "=w") (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "0") (match_operand:MVE_2 2 "s_register_operand" "w") - (match_operand:SI 3 "mve_imm_selective_upto_8" "Rg")] + (match_operand:SI 3 "" "")] VSRIQ_N)) ] "TARGET_HAVE_MVE" @@ -4466,7 +4466,7 @@ (define_insn "mve_vqrshrntq_n_" (set (match_operand: 0 "s_register_operand" "=w") (unspec: [(match_operand: 1 "s_register_operand" "0") (match_operand:MVE_5 2 "s_register_operand" "w") - (match_operand:SI 3 "mve_imm_8" "Rb")] + (match_operand:SI 3 "" "")] VQRSHRNTQ_N)) ] "TARGET_HAVE_MVE" @@ -4482,7 +4482,7 @@ (define_insn "mve_vqrshruntq_n_s" (set (match_operand: 0 "s_register_operand" "=w") (unspec: [(match_operand: 1 "s_register_operand" "0") (match_operand:MVE_5 2 "s_register_operand" "w") - (match_operand:SI 3 "mve_imm_8" "Rb")] + (match_operand:SI 3 "" "")] VQRSHRUNTQ_N_S)) ] "TARGET_HAVE_MVE" @@ -4770,7 +4770,7 @@ (define_insn "mve_vrshrnbq_n_" (set (match_operand: 0 "s_register_operand" "=w") (unspec: [(match_operand: 1 "s_register_operand" "0") (match_operand:MVE_5 2 "s_register_operand" "w") - (match_operand:SI 3 "mve_imm_8" "Rb")] + (match_operand:SI 3 "" "")] VRSHRNBQ_N)) ] "TARGET_HAVE_MVE" @@ -4786,7 +4786,7 @@ (define_insn "mve_vrshrntq_n_" (set (match_operand: 0 "s_register_operand" "=w") (unspec: [(match_operand: 1 "s_register_operand" "0") (match_operand:MVE_5 2 "s_register_operand" "w") - (match_operand:SI 3 "mve_imm_8" "Rb")] + (match_operand:SI 3 "" "")] VRSHRNTQ_N)) ] "TARGET_HAVE_MVE" @@ -4980,7 +4980,7 @@ (define_insn "mve_vqshluq_m_n_s" (set (match_operand:MVE_2 0 "s_register_operand" "=w") (unspec:MVE_2 [(match_operand:MVE_2 1 "s_register_operand" "0") (match_operand:MVE_2 2 "s_register_operand" "w") - (match_operand:SI 3 "mve_imm_7" "Ra") + (match_operand:SI 3 "" "") (match_operand: 4 "vpr_register_operand" "Up")] VQSHLUQ_M_N_S)) ] @@ -5012,7 +5012,7 @@ (define_insn "mve_vsriq_m_n_" (set (match_operand:
[PATCH v2] testsuite: Sanitize fails for SP FPU on Arm
This patch stops reporting fails for Arm targets with single
precision floating point unit for types wider than 32 bits (the width
of float on arm-none-eabi).
As reported in PR102017, fenv is reported as supported in recent
versions of newlib. At the same time, for some Arm targets, the
implementation in libgcc does not support exceptions and thus, the
test fails with a call to abort().
gcc/testsuite/ChangeLog:
* lib/target-supports.exp
(check_effective_target_fenv_exceptions_double): New.
(check_effective_target_fenv_exceptions_long_double): New.
* gcc.dg/c2x-float-7.c: Split into 3 tests...
* gcc.dg/c2x-float-7a.c: Float part of c2x-float-7.c.
* gcc.dg/c2x-float-7b.c: Double part of c2x-float-7.c.
* gcc.dg/c2x-float-7c.c: Long double part of c2x-float-7.c.
* gcc.dg/pr95115.c: Switch to fenv_exceptions_double.
* gcc.dg/torture/float32x-nan-floath.c: Likewise.
* gcc.dg/torture/float32x-nan.c: Likewise.
* gcc.dg/torture/float64-nan-floath.c: Likewise.
* gcc.dg/torture/float64-nan.c: Likewise.
* gcc.dg/torture/inf-compare-1.c: Likewise.
* gcc.dg/torture/inf-compare-2.c: Likewise.
* gcc.dg/torture/inf-compare-3.c: Likewise.
* gcc.dg/torture/inf-compare-4.c: Likewise.
* gcc.dg/torture/inf-compare-5.c: Likewise.
* gcc.dg/torture/inf-compare-6.c: Likewise.
* gcc.dg/torture/inf-compare-7.c: Likewise.
* gcc.dg/torture/inf-compare-8.c: Likewise.
* gcc.dg/torture/inf-compare-1-float.c: New test.
* gcc.dg/torture/inf-compare-2-float.c: New test.
* gcc.dg/torture/inf-compare-3-float.c: New test.
* gcc.dg/torture/inf-compare-4-float.c: New test.
* gcc.dg/torture/inf-compare-5-float.c: New test.
* gcc.dg/torture/inf-compare-6-float.c: New test.
* gcc.dg/torture/inf-compare-7-float.c: New test.
* gcc.dg/torture/inf-compare-8-float.c: New test.
Co-Authored-By: Yvan ROUX
Signed-off-by: Torbjörn SVENSSON
---
gcc/testsuite/gcc.dg/c2x-float-7.c| 49
gcc/testsuite/gcc.dg/c2x-float-7a.c | 30
gcc/testsuite/gcc.dg/c2x-float-7b.c | 30
gcc/testsuite/gcc.dg/c2x-float-7c.c | 30
gcc/testsuite/gcc.dg/pr95115.c| 2 +-
.../gcc.dg/torture/float32x-nan-floath.c | 2 +-
gcc/testsuite/gcc.dg/torture/float32x-nan.c | 2 +-
.../gcc.dg/torture/float64-nan-floath.c | 2 +-
gcc/testsuite/gcc.dg/torture/float64-nan.c| 2 +-
.../gcc.dg/torture/inf-compare-1-float.c | 21 ++
gcc/testsuite/gcc.dg/torture/inf-compare-1.c | 2 +-
.../gcc.dg/torture/inf-compare-2-float.c | 21 ++
gcc/testsuite/gcc.dg/torture/inf-compare-2.c | 2 +-
.../gcc.dg/torture/inf-compare-3-float.c | 21 ++
gcc/testsuite/gcc.dg/torture/inf-compare-3.c | 2 +-
.../gcc.dg/torture/inf-compare-4-float.c | 21 ++
gcc/testsuite/gcc.dg/torture/inf-compare-4.c | 2 +-
.../gcc.dg/torture/inf-compare-5-float.c | 19 +
gcc/testsuite/gcc.dg/torture/inf-compare-5.c | 2 +-
.../gcc.dg/torture/inf-compare-6-float.c | 19 +
gcc/testsuite/gcc.dg/torture/inf-compare-6.c | 2 +-
.../gcc.dg/torture/inf-compare-7-float.c | 19 +
gcc/testsuite/gcc.dg/torture/inf-compare-7.c | 2 +-
.../gcc.dg/torture/inf-compare-8-float.c | 19 +
gcc/testsuite/gcc.dg/torture/inf-compare-8.c | 2 +-
gcc/testsuite/lib/target-supports.exp | 74 +++
26 files changed, 337 insertions(+), 62 deletions(-)
delete mode 100644 gcc/testsuite/gcc.dg/c2x-float-7.c
create mode 100644 gcc/testsuite/gcc.dg/c2x-float-7a.c
create mode 100644 gcc/testsuite/gcc.dg/c2x-float-7b.c
create mode 100644 gcc/testsuite/gcc.dg/c2x-float-7c.c
create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-1-float.c
create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-2-float.c
create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-3-float.c
create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-4-float.c
create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-5-float.c
create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-6-float.c
create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-7-float.c
create mode 100644 gcc/testsuite/gcc.dg/torture/inf-compare-8-float.c
diff --git a/gcc/testsuite/gcc.dg/c2x-float-7.c
b/gcc/testsuite/gcc.dg/c2x-float-7.c
deleted file mode 100644
index 0c90ff24165..000
--- a/gcc/testsuite/gcc.dg/c2x-float-7.c
+++ /dev/null
@@ -1,49 +0,0 @@
-/* Test SNAN macros. Runtime exceptions test, to verify NaN is
- signaling. */
-/* { dg-do run } */
-/* { dg-require-effective-target fenv_exceptions } */
-/* { dg-options "-std=c2x -pedantic-errors -fsignaling-nans" } */
-/* { dg-add-options ieee } */
-
-#include
-#include
-
-/* These should be defined if and only if signaling NaNs are supported
- for the given types.
[PATCH] Fix wrong code generated by unroll-and-jam pass
Hi,
as shown by the attached testcase, there is a loophole in the unroll-and-jam
pass that can quickly result in wrong code generation. The code reads:
if (!compute_data_dependences_for_loop (outer, true, &loop_nest,
&datarefs, &dependences))
{
if (dump_file && (dump_flags & TDF_DETAILS))
fprintf (dump_file, "Cannot analyze data dependencies\n");
free_data_refs (datarefs);
free_dependence_relations (dependences);
continue;
}
but compute_data_dependences_for_loop may return true even if the analysis is
reported as failing by compute_affine_dependence for some dependence pair:
(compute_affine_dependence
ref_a: data[_14], stmt_a: data[_14] = i_59;
ref_b: data[_14], stmt_b: data[_14] = i_59;
Data ref a:
#(Data Ref:
# bb: 12
# stmt: data[_14] = i_59;
# ref: data[_14];
# base_object: data;
# Access function 0: scev_not_known;
#)
Data ref b:
#(Data Ref:
# bb: 12
# stmt: data[_14] = i_59;
# ref: data[_14];
# base_object: data;
# Access function 0: scev_not_known;
#)
affine dependence test not usable: access function not affine or constant.
) -> dependence analysis failed
Note that this is a self-dependence pair and the code for them reads:
/* Nothing interesting for the self dependencies. */
if (dra == drb)
continue;
This means that the pass may reorder "complex" accesses to the same memory
location in successive iterations, which is OK for reads but not for writes.
Proposed fix attached, tested on x86-64/Linux, OK for all active branches?
2022-10-05 Eric Botcazou
* gimple-loop-jam.cc (tree_loop_unroll_and_jam): Bail out for a self
dependency that is a write-after-write if the access function is not
affine or constant.
2022-10-05 Eric Botcazou
* gcc.c-torture/execute/20221005-1.c: New test.
--
Eric Botcazoudiff --git a/gcc/gimple-loop-jam.cc b/gcc/gimple-loop-jam.cc
index a8a57d3d384..4f7a6e5bbae 100644
--- a/gcc/gimple-loop-jam.cc
+++ b/gcc/gimple-loop-jam.cc
@@ -545,11 +545,25 @@ tree_loop_unroll_and_jam (void)
/* If the refs are independend there's nothing to do. */
if (DDR_ARE_DEPENDENT (ddr) == chrec_known)
continue;
+
dra = DDR_A (ddr);
drb = DDR_B (ddr);
- /* Nothing interesting for the self dependencies. */
+
+ /* Nothing interesting for the self dependencies, except for WAW if
+ the access function is not affine or constant because we may end
+ up reordering writes to the same location. */
if (dra == drb)
- continue;
+ {
+ if (DR_IS_WRITE (dra)
+ && !DR_ACCESS_FNS (dra).is_empty ()
+ && DDR_ARE_DEPENDENT (ddr) == chrec_dont_know)
+ {
+ unroll_factor = 0;
+ break;
+ }
+ else
+ continue;
+ }
/* Now check the distance vector, for determining a sensible
outer unroll factor, and for validity of merging the inner
#include
int
main (int argc, char** argv)
{
const int len = argc == 2 ? atoi(argv[1]) : 4;
int count;
int data[64];
int M1[len][len];
int M2[len][len];
for (int i = 0; i < len; i++)
for (int j = 0 ; j < len ; j++)
M1[i][j] = M2[i][j] = i*len + j;
M2[1][0] = M2[0][1];
/* This writes successively 0 and 1 into data[M2[0][1]]. */
for (int i = 0; i < len - 1; i++)
for (int j = 0 ; j < len ; j++)
if (M1[i+1][j] > M1[i][j])
data[M2[i][j]] = i;
if (data [M2[0][1]] != 1)
abort ();
return 0;
}
Re: [PATCH][AArch64] Improve bit tests [PR105773]
Wilco Dijkstra writes:
> Since AArch64 sets all flags on logical operations, comparisons with zero
> can be combined into an AND even if the condition is LE or GT.
>
> Passes regress, OK for commit?
>
> gcc:
> PR target/105773
> * config/aarch64/aarch64.cc (aarch64_select_cc_mode): Allow
> GT/LE for merging compare with zero into AND.
> (aarch64_get_condition_code_1): Support GT and LE in CC_NZmode.
Realise this is awkward, but: CC_NZmode is for operations that set only
the N and Z flags to useful values. If we want to take advantage of V
being zero then I think we need a different mode.
We can't go all the way to CCmode because the carry flag has the opposite
value compared to subtraction. But we could have either:
* CC_INVC (inverted carry) that handles all comparisons, including the
redundant unsigned comparisons
* CC_NZV
Guess I've got a slight preference for CC_INVC, but either would be OK IMO.
Thanks,
Richard
>
> gcc/testsuite:
> PR target/105773
> * gcc.target/aarch64/ands_2.c: Test for ANDS.
> * gcc.target/aarch64/bics_2.c: Test for BICS.
> * gcc.target/aarch64/tst_2.c: Test for TST.
> * gcc.target/aarch64/tst_imm_split_1.c: Fix test.
>
> ---
>
> diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> index
> 1601d11710cb6132c80a77bb4fe2f8429519aa5a..00876b08d8fbb1329a37a0ea73d3abf09d28b829
> 100644
> --- a/gcc/config/aarch64/aarch64.cc
> +++ b/gcc/config/aarch64/aarch64.cc
> @@ -11323,7 +11323,8 @@ aarch64_select_cc_mode (RTX_CODE code, rtx x, rtx y)
>
>if ((mode_x == SImode || mode_x == DImode)
>&& y == const0_rtx
> - && (code == EQ || code == NE || code == LT || code == GE)
> + && (code == EQ || code == NE || code == LT || code == GE
> + || (code_x == AND && (code == GT || code == LE)))
>&& (code_x == PLUS || code_x == MINUS || code_x == AND
> || code_x == NEG
> || (code_x == ZERO_EXTRACT && CONST_INT_P (XEXP (x, 1))
> @@ -11471,6 +11472,8 @@ aarch64_get_condition_code_1 (machine_mode mode, enum
> rtx_code comp_code)
> case EQ: return AARCH64_EQ;
> case GE: return AARCH64_PL;
> case LT: return AARCH64_MI;
> + case GT: return AARCH64_GT;
> + case LE: return AARCH64_LE;
> default: return -1;
> }
>break;
> diff --git a/gcc/testsuite/gcc.target/aarch64/ands_2.c
> b/gcc/testsuite/gcc.target/aarch64/ands_2.c
> index
> b061b1dfc59c1847cb799a1e49f8e5fc53bf2f14..c8763f234c5f7d19ef9c222756ab5e8a6eaae6fe
> 100644
> --- a/gcc/testsuite/gcc.target/aarch64/ands_2.c
> +++ b/gcc/testsuite/gcc.target/aarch64/ands_2.c
> @@ -8,8 +8,7 @@ ands_si_test1 (int a, int b, int c)
> {
>int d = a & b;
>
> - /* { dg-final { scan-assembler-not "ands\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+"
> } } */
> - /* { dg-final { scan-assembler-times "and\tw\[0-9\]+, w\[0-9\]+,
> w\[0-9\]+" 2 } } */
> + /* { dg-final { scan-assembler "ands\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+" } }
> */
>if (d <= 0)
> return a + c;
>else
> @@ -21,12 +20,11 @@ ands_si_test2 (int a, int b, int c)
> {
>int d = a & 0x;
>
> - /* { dg-final { scan-assembler-not "ands\tw\[0-9\]+, w\[0-9\]+,
> -1717986919" } } */
> - /* { dg-final { scan-assembler "and\tw\[0-9\]+, w\[0-9\]+, -1717986919" }
> } */
> - if (d <= 0)
> -return a + c;
> - else
> + /* { dg-final { scan-assembler "ands\tw\[0-9\]+, w\[0-9\]+, -1717986919" }
> } */
> + if (d > 0)
> return b + d + c;
> + else
> +return a + c;
> }
>
> int
> @@ -34,8 +32,7 @@ ands_si_test3 (int a, int b, int c)
> {
>int d = a & (b << 3);
>
> - /* { dg-final { scan-assembler-not "ands\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+,
> lsl 3" } } */
> - /* { dg-final { scan-assembler "and\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+, lsl
> 3" } } */
> + /* { dg-final { scan-assembler "ands\tw\[0-9\]+, w\[0-9\]+, w\[0-9\]+, lsl
> 3" } } */
>if (d <= 0)
> return a + c;
>else
> @@ -49,8 +46,7 @@ ands_di_test1 (s64 a, s64 b, s64 c)
> {
>s64 d = a & b;
>
> - /* { dg-final { scan-assembler-not "ands\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+"
> } } */
> - /* { dg-final { scan-assembler-times "and\tx\[0-9\]+, x\[0-9\]+,
> x\[0-9\]+" 2 } } */
> + /* { dg-final { scan-assembler "ands\tx\[0-9\]+, x\[0-9\]+, x\[0-9\]+" } }
> */
>if (d <= 0)
> return a + c;
>else
> @@ -62,12 +58,11 @@ ands_di_test2 (s64 a, s64 b, s64 c)
> {
>s64 d = a & 0xll;
>
> - /* { dg-final { scan-assembler-not "ands\tx\[0-9\]+, x\[0-9\]+,
> -6148914691236517206" } } */
> - /* { dg-final { scan-assembler "and\tx\[0-9\]+, x\[0-9\]+,
> -6148914691236517206" } } */
> - if (d <= 0)
> -return a + c;
> - else
> + /* { dg-final { scan-assembler "ands\tx\[0-9\]+, x\[0-9\]+,
> -6148914691236517206" } } */
> + if (d > 0)
> return b + d + c;
> + else
> +return a + c;
> }
>
> s64
> @@ -75,8 +70,7 @@ ands_di_test3 (s64 a, s64 b, s64 c)
> {
>s64
Re: [Patch] Fortran: Add OpenMP's assume(s) directives
On Wed, Oct 05, 2022 at 02:29:56PM +0200, Tobias Burnus wrote:
> + gfc_error ("!OMP ASSUMES at %C must be in the specification part of a "
s/!OMP/!$OMP/
Otherwise LGTM.
Jakub
Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone
On 10/5/22 16:50, Qing Zhao wrote: > I have two questions on this: Hello. > > 1. What’s the motivation to enable -flive-patching with -flto? Is there any > application that will try -flive-patching with -flto now? We're planning supporting GCC LTO Linux kernel support, so that's one motivation. And the second one is a possible use in user-space livepatching. Note majority of modern distros default to -flto (openSUSE, Fedora, Debian, Ubuntu, ...). > > 2. Why only enable -flive-patching=inline-clone with -flto? Because the inline-only-static level (which you added/requested) would have to properly block inter-procedural inlining that happens in LTO (can_inline_edge_by_limits_p) and I'm not sure it would be properly blocked. So, feel free to extend my patch if you want? Martin > > thanks.
[committed] analyzer: fix ICEs seen with call summaries on PR 107060
This doesn't fix the various false positives seen with
-fanalyzer-call-summaries on PR 107060, but stops it crashing at -O2.
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3094-g6832c95c0e1a58.
gcc/analyzer/ChangeLog:
PR analyzer/107060
* call-summary.cc
(call_summary_replay::convert_svalue_from_summary_1): Handle NULL
results from convert_svalue_from_summary in SK_UNARY_OP and
SK_BIN_OP.
* engine.cc (impl_region_model_context::on_unknown_change): Bail
out on svalues that can't have associated state.
* region-model-impl-calls.cc
(region_model::impl_call_analyzer_get_unknown_ptr): New.
* region-model.cc (region_model::on_stmt_pre): Handle
"__analyzer_get_unknown_ptr".
* region-model.h
(region_model::impl_call_analyzer_get_unknown_ptr): New decl.
* store.cc (store::replay_call_summary_cluster): Avoid trying to
create binding clusters for base regions that shouldn't have them.
gcc/ChangeLog:
PR analyzer/107060
* doc/analyzer.texi (__analyzer_get_unknown_ptr): Document.
gcc/testsuite/ChangeLog:
PR analyzer/107060
* gcc.dg/analyzer/analyzer-decls.h (__analyzer_get_unknown_ptr):
New decl.
* gcc.dg/analyzer/call-summaries-2.c
(test_summarized_writes_param_to_ptr_unknown): New test.
Signed-off-by: David Malcolm
---
gcc/analyzer/call-summary.cc | 28 +--
gcc/analyzer/engine.cc| 2 ++
gcc/analyzer/region-model-impl-calls.cc | 10 +++
gcc/analyzer/region-model.cc | 6
gcc/analyzer/region-model.h | 1 +
gcc/analyzer/store.cc | 16 +++
gcc/doc/analyzer.texi | 4 +++
.../gcc.dg/analyzer/analyzer-decls.h | 3 ++
.../gcc.dg/analyzer/call-summaries-2.c| 7 +
9 files changed, 62 insertions(+), 15 deletions(-)
diff --git a/gcc/analyzer/call-summary.cc b/gcc/analyzer/call-summary.cc
index a8e881472ea..33916547e1e 100644
--- a/gcc/analyzer/call-summary.cc
+++ b/gcc/analyzer/call-summary.cc
@@ -298,23 +298,33 @@ call_summary_replay::convert_svalue_from_summary_1 (const
svalue *summary_sval)
{
const unaryop_svalue *unaryop_summary_sval
= as_a (summary_sval);
+ const svalue *summary_arg = unaryop_summary_sval->get_arg ();
+ const svalue *caller_arg = convert_svalue_from_summary (summary_arg);
+ if (!caller_arg)
+ return NULL;
region_model_manager *mgr = get_manager ();
- return mgr->get_or_create_unaryop
- (summary_sval->get_type (),
- unaryop_summary_sval->get_op (),
- convert_svalue_from_summary (unaryop_summary_sval->get_arg ()));
+ return mgr->get_or_create_unaryop (summary_sval->get_type (),
+ unaryop_summary_sval->get_op (),
+ caller_arg);
}
break;
case SK_BINOP:
{
const binop_svalue *binop_summary_sval
= as_a (summary_sval);
+ const svalue *summary_arg0 = binop_summary_sval->get_arg0 ();
+ const svalue *caller_arg0 = convert_svalue_from_summary (summary_arg0);
+ if (!caller_arg0)
+ return NULL;
+ const svalue *summary_arg1 = binop_summary_sval->get_arg1 ();
+ const svalue *caller_arg1 = convert_svalue_from_summary (summary_arg1);
+ if (!caller_arg1)
+ return NULL;
region_model_manager *mgr = get_manager ();
- return mgr->get_or_create_binop
- (summary_sval->get_type (),
- binop_summary_sval->get_op (),
- convert_svalue_from_summary (binop_summary_sval->get_arg0 ()),
- convert_svalue_from_summary (binop_summary_sval->get_arg1 ()));
+ return mgr->get_or_create_binop (summary_sval->get_type (),
+binop_summary_sval->get_op (),
+caller_arg0,
+caller_arg1);
}
break;
case SK_SUB:
diff --git a/gcc/analyzer/engine.cc b/gcc/analyzer/engine.cc
index 735b5a3c061..faef0bd15b0 100644
--- a/gcc/analyzer/engine.cc
+++ b/gcc/analyzer/engine.cc
@@ -172,6 +172,8 @@ void
impl_region_model_context::on_unknown_change (const svalue *sval,
bool is_mutable)
{
+ if (!sval->can_have_associated_state_p ())
+return;
for (sm_state_map *smap : m_new_state->m_checker_states)
smap->on_unknown_change (sval, is_mutable, m_ext_state);
}
diff --git a/gcc/analyzer/region-model-impl-calls.cc
b/gcc/analyzer/region-model-impl-calls.cc
index 71fb2770143..5cc590716b4 100644
--- a/gcc/analyzer/region-model-impl-calls.cc
+++ b/gcc/analyzer/region-model-impl-calls.cc
@@ -374,6 +374,16 @@ region_model::impl_call_analyzer_eval (const gcall
[committed] analyzer: simplify some includes
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu. Pushed to trunk as r13-3095-g2eff4fe383a59d. gcc/analyzer/ChangeLog: * analysis-plan.cc: Simplify includes. * analyzer-pass.cc: Likewise. * analyzer-selftests.cc: Likewise. * analyzer.cc: Likewise. * analyzer.h: Add includes of "json.h" and "tristate.h". * call-info.cc: Simplify includes. * call-string.cc: Likewise. * call-summary.cc: Likewise. * checker-path.cc: Likewise. * complexity.cc: Likewise. * constraint-manager.cc: Likewise. * diagnostic-manager.cc: Likewise. * engine.cc: Likewise. * feasible-graph.cc: Likewise. * known-function-manager.cc: Likewise. * pending-diagnostic.cc: Likewise. * program-point.cc: Likewise. * program-state.cc: Likewise. * region-model-asm.cc: Likewise. * region-model-impl-calls.cc: Likewise. * region-model-manager.cc: Likewise. * region-model-reachability.cc: Likewise. * region-model.cc: Likewise. * region-model.h: Include "selftest.h". * region.cc: Simplify includes. * sm-fd.cc: Likewise. * sm-file.cc: Likewise. * sm-malloc.cc: Likewise. * sm-pattern-test.cc: Likewise. * sm-sensitive.cc: Likewise. * sm-signal.cc: Likewise. * sm-taint.cc: Likewise. * sm.cc: Likewise. * state-purge.cc: Likewise. * store.cc: Likewise. * store.h: Likewise. * supergraph.cc: Likewise. * svalue.cc: Likewise. * svalue.h: Likewise. * trimmed-graph.cc: Likewise. * varargs.cc: Likewise. Signed-off-by: David Malcolm --- gcc/analyzer/analysis-plan.cc | 2 -- gcc/analyzer/analyzer-pass.cc | 1 - gcc/analyzer/analyzer-selftests.cc| 1 - gcc/analyzer/analyzer.cc | 1 - gcc/analyzer/analyzer.h | 2 ++ gcc/analyzer/call-info.cc | 7 --- gcc/analyzer/call-string.cc | 1 - gcc/analyzer/call-summary.cc | 1 - gcc/analyzer/checker-path.cc | 8 gcc/analyzer/complexity.cc| 4 gcc/analyzer/constraint-manager.cc| 3 --- gcc/analyzer/diagnostic-manager.cc| 7 --- gcc/analyzer/engine.cc| 6 -- gcc/analyzer/feasible-graph.cc| 7 --- gcc/analyzer/known-function-manager.cc| 1 - gcc/analyzer/pending-diagnostic.cc| 8 gcc/analyzer/program-point.cc | 4 gcc/analyzer/program-state.cc | 6 -- gcc/analyzer/region-model-asm.cc | 3 --- gcc/analyzer/region-model-impl-calls.cc | 7 --- gcc/analyzer/region-model-manager.cc | 7 --- gcc/analyzer/region-model-reachability.cc | 9 ++--- gcc/analyzer/region-model.cc | 4 gcc/analyzer/region-model.h | 1 + gcc/analyzer/region.cc| 4 gcc/analyzer/sm-fd.cc | 4 gcc/analyzer/sm-file.cc | 3 --- gcc/analyzer/sm-malloc.cc | 4 gcc/analyzer/sm-pattern-test.cc | 4 gcc/analyzer/sm-sensitive.cc | 3 --- gcc/analyzer/sm-signal.cc | 6 -- gcc/analyzer/sm-taint.cc | 4 gcc/analyzer/sm.cc| 2 -- gcc/analyzer/state-purge.cc | 10 +- gcc/analyzer/store.cc | 5 - gcc/analyzer/store.h | 2 -- gcc/analyzer/supergraph.cc| 1 - gcc/analyzer/svalue.cc| 10 ++ gcc/analyzer/svalue.h | 1 - gcc/analyzer/trimmed-graph.cc | 13 - gcc/analyzer/varargs.cc | 11 --- 41 files changed, 8 insertions(+), 180 deletions(-) diff --git a/gcc/analyzer/analysis-plan.cc b/gcc/analyzer/analysis-plan.cc index c488f372ea7..a4a42c5cd3d 100644 --- a/gcc/analyzer/analysis-plan.cc +++ b/gcc/analyzer/analysis-plan.cc @@ -27,7 +27,6 @@ along with GCC; see the file COPYING3. If not see #include "timevar.h" #include "ipa-utils.h" #include "function.h" -#include "json.h" #include "analyzer/analyzer.h" #include "diagnostic-core.h" #include "analyzer/analyzer-logging.h" @@ -35,7 +34,6 @@ along with GCC; see the file COPYING3. If not see #include "ordered-hash-map.h" #include "options.h" #include "cgraph.h" -#include "function.h" #include "cfg.h" #include "basic-block.h" #include "gimple.h" diff --git a/gcc/analyzer/analyzer-pass.cc b/gcc/analyzer/analyzer-pass.cc index f6cef58bc7c..fc7098ddccb 100644 --- a/gcc/analyzer/analyzer-pass.cc +++ b/gcc/analyzer/analyzer-pass.cc @@ -26,7 +26,6 @@ along with GCC; see the file COPYING3. If not see #include "diagnostic.h" #include "options.h" #include "tree.h" -#include "f
[committed] analyzer: add regression test for PR 107158
PR analyzer/107158 reports an ICE when using
-fanalyzer -fanalyzer-call-summaries
on a particular source file.
It turns out I just fixed this ICE in r13-3094-g6832c95c0e1a58.
This followup patch adds a somewhat reduced reproducer as a regression
test. Unfortunately, although the ICE is fixed, there are two false
positives from -Wanalyzer-malloc-leak on the test case, so I'm going to
use PR analyzer/107158 for tracking those false positives.
Tested on x86_64-pc-linux-gnu.
Pushed to trunk as r13-3096-gef878564140cbc.
gcc/testsuite/ChangeLog:
PR analyzer/107158
* gcc.dg/analyzer/call-summaries-pr107158.c: New test.
Signed-off-by: David Malcolm
---
.../gcc.dg/analyzer/call-summaries-pr107158.c | 83 +++
1 file changed, 83 insertions(+)
create mode 100644 gcc/testsuite/gcc.dg/analyzer/call-summaries-pr107158.c
diff --git a/gcc/testsuite/gcc.dg/analyzer/call-summaries-pr107158.c
b/gcc/testsuite/gcc.dg/analyzer/call-summaries-pr107158.c
new file mode 100644
index 000..54f442f0ad4
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/analyzer/call-summaries-pr107158.c
@@ -0,0 +1,83 @@
+/* { dg-additional-options "-fanalyzer-call-summaries" } */
+
+typedef __SIZE_TYPE__ size_t;
+enum { _ISspace = ((5) < 8 ? ((1 << (5)) << 8) : ((1 << (5)) >> 8)) };
+extern const unsigned short int **__ctype_b_loc(void)
+ __attribute__((__nothrow__, __leaf__, __const__));
+extern void *malloc(size_t __size)
+ __attribute__((__nothrow__, __leaf__, __malloc__, __alloc_size__(1)));
+extern char *strcpy(char *__restrict __dest, const char *__restrict __src)
+ __attribute__((__nothrow__, __leaf__, __nonnull__(1, 2)));
+extern size_t strlen(const char *__s)
+ __attribute__((__nothrow__, __leaf__, __pure__, __nonnull__(1)));
+
+struct mydata {
+ struct mydata *link;
+ char *name;
+ char *type;
+};
+
+static struct mydata *all_data;
+static int line_no;
+
+__attribute__((__noreturn__)) void failed(const char *message);
+
+static char *string_dup(const char *string) {
+ char *buf;
+
+ if ((buf = malloc(strlen(string) + 1)) == ((void *)0))
+failed("malloc() failed");
+
+ return strcpy(buf, string);
+}
+
+static void store_data(const char *name, const char *type) {
+ struct mydata *p, *q;
+
+ if ((p = (struct mydata *)malloc(sizeof(struct mydata))) == ((void *)0))
+failed("malloc() failed");
+
+ p->link = ((void *)0);
+ p->name = string_dup(name);
+ p->type = string_dup(type);
+
+ if ((q = all_data) == ((void *)0))
+all_data = p;
+ else {
+while (q->link != ((void *)0))
+ q = q->link;
+q->link = p;
+ }
+}
+
+static void parse_tbl(char *buffer) {
+ char *s = buffer;
+ char *t = s + strlen(s);
+
+ do {
+t--;
+if (((*__ctype_b_loc())[(int)(((int)*t))] & (unsigned short int)_ISspace))
+ *t = '\0';
+else
+ break;
+ } while (t > s);
+ while (((*__ctype_b_loc())[(int)(((int)*s))] & (unsigned short int)_ISspace))
+s++;
+ buffer = s;
+
+ line_no++;
+ if (*buffer != ';' && *buffer != '\0') {
+if (*buffer == '#') {
+ store_data(buffer, ""); /* { dg-bogus "leak" "PR analyzer/107158" {
xfail *-*-* } } */
+} else {
+
+ while (*s && !((*__ctype_b_loc())[(int)(((int)*s))] &
+ (unsigned short int)_ISspace))
+s++;
+ while (
+ ((*__ctype_b_loc())[(int)(((int)*s))] & (unsigned short
int)_ISspace))
+*s++ = '\0';
+ store_data(buffer, s); /* { dg-bogus "leak" "PR analyzer/107158" { xfail
*-*-* } } */
+}
+ }
+}
--
2.26.3
Re: [PATCH] IPA: support -flto + -flive-patching=inline-clone
> On Oct 5, 2022, at 1:36 PM, Martin Liška wrote: > > On 10/5/22 16:50, Qing Zhao wrote: >> I have two questions on this: > > Hello. > >> >> 1. What’s the motivation to enable -flive-patching with -flto? Is there any >> application that will try -flive-patching with -flto now? > > We're planning supporting GCC LTO Linux kernel support, so that's one > motivation. And the second one is a possible > use in user-space livepatching. Note majority of modern distros default to > -flto (openSUSE, Fedora, Debian, Ubuntu, ...). Okay, I see. That’s reasonable. > >> >> 2. Why only enable -flive-patching=inline-clone with -flto? > > Because the inline-only-static level (which you added/requested) would have > to properly > block inter-procedural inlining that happens in LTO > (can_inline_edge_by_limits_p) and > I'm not sure it would be properly blocked. So, feel free to extend my patch > if you want? -flive-patching=inline-only-static Only enable static functions inlining, all the inlining of external visible functions are blocked, So, LTO should be compatible with this naturally without any issue, I think. i.e, when "-flive-patching=inline-only-static -flto" present together, all the inter-procedural inlining should be automatically blocked by -flive-patching=inline-only-static already. Do I miss anything here? thanks. Qing > > Martin > >> >> thanks. >
[PATCH][pushed] contrib: run fetch before pushing Daily bump
As seen from recent days, the script fails when it pushes
a branch while another revision was pushed by a user.
Prevent that by doing fetch right before the pull.
The error message example:
cmdline: git push origin releases/gcc-11
stderr: 'fatal: unable to parse object: 4249a65c814287af667aa78789436d3fc618e80a
error: remote unpack failed: eof before pack header was fully read
I'm going to push the change and let's see if it mitigates the problem.
Martin
contrib/ChangeLog:
* gcc-changelog/git_update_version.py: Do fetch before a push.
---
contrib/gcc-changelog/git_update_version.py | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/contrib/gcc-changelog/git_update_version.py
b/contrib/gcc-changelog/git_update_version.py
index 05a9f7e402d..8462179b5ab 100755
--- a/contrib/gcc-changelog/git_update_version.py
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -127,6 +127,7 @@ def update_current_branch(ref_name):
repo.git.add(datestamp_path)
if not args.current:
repo.index.commit('Daily bump.')
+origin.fetch()
if args.push:
repo.git.push('origin', branch)
print('branch is pushed')
@@ -149,7 +150,7 @@ else:
print('=== Working on: %s ===' % branch, flush=True)
branch.checkout()
origin.pull(rebase=True)
-print('branch pulled and checked out')
+print('branch pulled and checked out', flush=True)
update_current_branch(name)
assert not repo.index.diff(None)
print('branch is done\n', flush=True)
--
2.37.3
[PATCH 0/3] rs6000: Get rid of wD
This series rewrites the code now using the wD constraint, because this constraint is a) unnecessary to have at all, and b) we want to use the constraint name for a more mnemonic purpose. As an extra benefit the new code is simpler than the original was. I'll commit this to trunk shortly. Segher Segher Boessenkool (3): rs6000: Remove "wD" from *vsx_extract__store rs6000: Rework vsx_extract_ rs6000: Remove the wD constraint gcc/config/rs6000/constraints.md | 6 --- gcc/config/rs6000/vsx.md | 85 +++- gcc/doc/md.texi | 3 -- 3 files changed, 40 insertions(+), 54 deletions(-) -- 1.8.3.1
[PATCH 2/3] rs6000: Rework vsx_extract_
Extracting the left and right halfs of a vector are entirely different
operations. Things are simpler if they are separate define_insns, and
it is easy to get rid of the "wD" constraint use then.
This also give the variant that is a no-op copy its own alternative, of
length 0 (and this, cost 0, making it more likely RA will choose it.
2022-10-05 Segher Boessenkool
* config/rs6000/vsx.md (vsx_extract_): Replace define_insn by a
define_expand. Split the contents to...
(*vsx_extract__0): ... this. Rewrite.
(*vsx_extract__01: ... and this. Rewrite.
---
gcc/config/rs6000/vsx.md | 80 ++--
1 file changed, 37 insertions(+), 43 deletions(-)
diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md
index 79a759b1ccf3..e0e34a78bca1 100644
--- a/gcc/config/rs6000/vsx.md
+++ b/gcc/config/rs6000/vsx.md
@@ -3388,59 +3388,53 @@ (define_expand "vsx_set_"
;; Optimize cases were we can do a simple or direct move.
;; Or see if we can avoid doing the move at all
-(define_insn "vsx_extract_"
- [(set (match_operand: 0 "gpc_reg_operand" "=wa, wa, wr, wr")
+(define_expand "vsx_extract_"
+ [(set (match_operand: 0 "gpc_reg_operand")
(vec_select:
-(match_operand:VSX_D 1 "gpc_reg_operand" "wa, wa, wa, wa")
+(match_operand:VSX_D 1 "gpc_reg_operand")
(parallel
- [(match_operand:QI 2 "const_0_to_1_operand" "wD, n, wD, n")])))]
+ [(match_operand:QI 2 "const_0_to_1_operand")])))]
"VECTOR_MEM_VSX_P (mode)"
+ "")
+
+(define_insn "*vsx_extract__0"
+ [(set (match_operand: 0 "gpc_reg_operand" "=wa,wa,wr")
+ (vec_select:
+(match_operand:VSX_D 1 "gpc_reg_operand" "0,wa,wa")
+(parallel
+ [(match_operand:QI 2 "const_0_to_1_operand" "n,n,n")])))]
+ "VECTOR_MEM_VSX_P (mode)
+ && INTVAL (operands[2]) == (BYTES_BIG_ENDIAN ? 0 : 1)"
{
- int element = INTVAL (operands[2]);
- int op0_regno = REGNO (operands[0]);
- int op1_regno = REGNO (operands[1]);
- int fldDM;
+ if (which_alternative == 0)
+return ASM_COMMENT_START " vec_extract to same register";
- gcc_assert (IN_RANGE (element, 0, 1));
- gcc_assert (VSX_REGNO_P (op1_regno));
+ if (which_alternative == 2)
+return "mfvsrd %0,%x1";
- if (element == VECTOR_ELEMENT_SCALAR_64BIT)
-{
- if (op0_regno == op1_regno)
- return ASM_COMMENT_START " vec_extract to same register";
+ return "xxlor %x0,%x1,%x1";
+}
+ [(set_attr "type" "*,veclogical,mfvsr")
+ (set_attr "isa" "*,*,p8v")
+ (set_attr "length" "0,*,*")])
- else if (INT_REGNO_P (op0_regno) && TARGET_DIRECT_MOVE
- && TARGET_POWERPC64)
- return "mfvsrd %0,%x1";
-
- else if (FP_REGNO_P (op0_regno) && FP_REGNO_P (op1_regno))
- return "fmr %0,%1";
-
- else if (VSX_REGNO_P (op0_regno))
- return "xxlor %x0,%x1,%x1";
-
- else
- gcc_unreachable ();
-}
-
- else if (element == VECTOR_ELEMENT_MFVSRLD_64BIT && INT_REGNO_P (op0_regno)
- && TARGET_P9_VECTOR && TARGET_POWERPC64 && TARGET_DIRECT_MOVE)
+(define_insn "*vsx_extract__1"
+ [(set (match_operand: 0 "gpc_reg_operand" "=wa,wr")
+ (vec_select:
+(match_operand:VSX_D 1 "gpc_reg_operand" "wa,wa")
+(parallel
+ [(match_operand:QI 2 "const_0_to_1_operand" "n,n")])))]
+ "VECTOR_MEM_VSX_P (mode)
+ && INTVAL (operands[2]) == (BYTES_BIG_ENDIAN ? 1 : 0)"
+{
+ if (which_alternative == 1)
return "mfvsrld %0,%x1";
- else if (VSX_REGNO_P (op0_regno))
-{
- fldDM = element << 1;
- if (!BYTES_BIG_ENDIAN)
- fldDM = 3 - fldDM;
- operands[3] = GEN_INT (fldDM);
- return "xxpermdi %x0,%x1,%x1,%3";
-}
-
- else
-gcc_unreachable ();
+ operands[3] = GEN_INT (BYTES_BIG_ENDIAN ? 2 : 3);
+ return "xxpermdi %x0,%x1,%x1,%3";
}
- [(set_attr "type" "veclogical,mfvsr,mfvsr,vecperm")
- (set_attr "isa" "*,*,p8v,p9v")])
+ [(set_attr "type" "mfvsr,vecperm")
+ (set_attr "isa" "*,p9v")])
;; Optimize extracting a single scalar element from memory.
(define_insn_and_split "*vsx_extract___load"
--
1.8.3.1
[PATCH 1/3] rs6000: Remove "wD" from *vsx_extract__store
We can use "n" instead of "wD" if we simply test the value of the integer constant directly. 2022-10-05 Segher Boessenkool * config/rs6000/vsx.md (*vsx_extract__store): Use "n" instead of "wD" constraint. --- gcc/config/rs6000/vsx.md | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/gcc/config/rs6000/vsx.md b/gcc/config/rs6000/vsx.md index e226a93bbe55..79a759b1ccf3 100644 --- a/gcc/config/rs6000/vsx.md +++ b/gcc/config/rs6000/vsx.md @@ -3466,8 +3466,9 @@ (define_insn "*vsx_extract__store" [(set (match_operand: 0 "memory_operand" "=m,Z,wY") (vec_select: (match_operand:VSX_D 1 "register_operand" "d,v,v") -(parallel [(match_operand:QI 2 "vsx_scalar_64bit" "wD,wD,wD")])))] - "VECTOR_MEM_VSX_P (mode)" +(parallel [(match_operand:QI 2 "vsx_scalar_64bit" "n,n,n")])))] + "VECTOR_MEM_VSX_P (mode) + && INTVAL (operands[2]) == (BYTES_BIG_ENDIAN ? 0 : 1)" "@ stfd%U0%X0 %1,%0 stxsdx %x1,%y0 -- 1.8.3.1
[PATCH 3/3] rs6000: Remove the wD constraint
2022-10-05 Segher Boessenkool
* config/rs6000/constraints.md (wD): Delete.
* doc/md.texi (Machine Constraints): Adjust.
---
gcc/config/rs6000/constraints.md | 6 --
gcc/doc/md.texi | 3 ---
2 files changed, 9 deletions(-)
diff --git a/gcc/config/rs6000/constraints.md b/gcc/config/rs6000/constraints.md
index 5a44a92142e5..54fef8d9996e 100644
--- a/gcc/config/rs6000/constraints.md
+++ b/gcc/config/rs6000/constraints.md
@@ -107,12 +107,6 @@ (define_constraint "wB"
(match_test "TARGET_P8_VECTOR")
(match_operand 0 "s5bit_cint_operand")))
-(define_constraint "wD"
- "@internal Int constant that is the element number of the 64-bit scalar
- in a vector."
- (and (match_code "const_int")
- (match_test "TARGET_VSX && (ival == VECTOR_ELEMENT_SCALAR_64BIT)")))
-
(define_constraint "wE"
"@internal Vector constant that can be loaded with the XXSPLTIB instruction."
(match_test "xxspltib_constant_nosplit (op, mode)"))
diff --git a/gcc/doc/md.texi b/gcc/doc/md.texi
index bb42ee1da36c..d0a71ecbb806 100644
--- a/gcc/doc/md.texi
+++ b/gcc/doc/md.texi
@@ -3267,9 +3267,6 @@ Like @code{b}, if @option{-mpowerpc64} is used;
otherwise, @code{NO_REGS}.
@item wB
Signed 5-bit constant integer that can be loaded into an Altivec register.
-@item wD
-Int constant that is the element number of the 64-bit scalar in a vector.
-
@item wE
Vector constant that can be loaded with the XXSPLTIB instruction.
--
1.8.3.1
[GCC13][Patch][V6][PATCH 0/2] Add a new option -fstrict-flex-arrays[=n] and attribute strict_flex_array(n) and use it in PR101836
This is the 6th version of the patch set. Compare to the 5th version, the major change is: (Address Joseph's comment on the attribute): 1. to require the attribute to be applied to a declaration; (c-family/c-attribs.cc) 2. update testing case to include such case; (testsuite/gcc.dg/strict-flex-array-1.c) Compare to the 4th version, the following are the major change:(Address Martin's comments). 1. change the name of the attribute from "strict_flex_arrays" to "strict_flex_array"; 2. update document to update all mentions of flexible array member with additional qualification "for the purposes of accessing the elements of such array". Compare to the 3rd version, the following are the major change: 1. delete all the warnings for the confliction between -std and -fstrict-flex-arrays per our discussion. 2. delete all the related testing cases for these warnings. 3. update all the wording changes, and documentation format changes recommanded by Joseph. I have bootstrapped and regression tested on both aarch64 and x86, no issues. The above changes are all in documentation and FEs. Since the Middle end change has been Okayed by Bichard in the V3 of the patch review. So, Joseph, could you please take a look at the FE and doc changes and let me know whether they are good to commit? thanks a lot. Qing Qing Zhao (2): Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array Use array_at_struct_end_p in __builtin_object_size [PR101836]
[GCC13][Patch][V6][PATCH 2/2] Use array_at_struct_end_p in __builtin_object_size [PR101836]
Use array_at_struct_end_p to determine whether the trailing array
of a structure is flexible array member in __builtin_object_size.
gcc/ChangeLog:
PR tree-optimization/101836
* tree-object-size.cc (addr_object_size): Use array_at_struct_end_p
to determine a flexible array member reference.
gcc/testsuite/ChangeLog:
PR tree-optimization/101836
* gcc.dg/pr101836.c: New test.
* gcc.dg/pr101836_1.c: New test.
* gcc.dg/pr101836_2.c: New test.
* gcc.dg/pr101836_3.c: New test.
* gcc.dg/pr101836_4.c: New test.
* gcc.dg/pr101836_5.c: New test.
* gcc.dg/strict-flex-array-2.c: New test.
* gcc.dg/strict-flex-array-3.c: New test.
---
gcc/testsuite/gcc.dg/pr101836.c| 60 ++
gcc/testsuite/gcc.dg/pr101836_1.c | 60 ++
gcc/testsuite/gcc.dg/pr101836_2.c | 60 ++
gcc/testsuite/gcc.dg/pr101836_3.c | 60 ++
gcc/testsuite/gcc.dg/pr101836_4.c | 60 ++
gcc/testsuite/gcc.dg/pr101836_5.c | 60 ++
gcc/testsuite/gcc.dg/strict-flex-array-2.c | 60 ++
gcc/testsuite/gcc.dg/strict-flex-array-3.c | 60 ++
gcc/tree-object-size.cc| 16 +++---
9 files changed, 487 insertions(+), 9 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr101836.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_1.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_2.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_3.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_4.c
create mode 100644 gcc/testsuite/gcc.dg/pr101836_5.c
create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-2.c
create mode 100644 gcc/testsuite/gcc.dg/strict-flex-array-3.c
diff --git a/gcc/testsuite/gcc.dg/pr101836.c b/gcc/testsuite/gcc.dg/pr101836.c
new file mode 100644
index 000..efad02cfe89
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101836.c
@@ -0,0 +1,60 @@
+/* -fstrict-flex-arrays is aliased with -ftrict-flex-arrays=3, which is the
+ strictest, only [] is treated as flexible array. */
+/* PR tree-optimization/101836 */
+/* { dg-do run } */
+/* { dg-options "-O2 -fstrict-flex-arrays" } */
+
+#include
+
+#define expect(p, _v) do { \
+size_t v = _v; \
+if (p == v) \
+printf("ok: %s == %zd\n", #p, p); \
+else \
+ { \
+ printf("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
+ __builtin_abort (); \
+ } \
+} while (0);
+
+struct trailing_array_1 {
+int a;
+int b;
+int c[4];
+};
+
+struct trailing_array_2 {
+int a;
+int b;
+int c[1];
+};
+
+struct trailing_array_3 {
+int a;
+int b;
+int c[0];
+};
+struct trailing_array_4 {
+int a;
+int b;
+int c[];
+};
+
+void __attribute__((__noinline__)) stuff(
+struct trailing_array_1 *normal,
+struct trailing_array_2 *trailing_1,
+struct trailing_array_3 *trailing_0,
+struct trailing_array_4 *trailing_flex)
+{
+expect(__builtin_object_size(normal->c, 1), 16);
+expect(__builtin_object_size(trailing_1->c, 1), 4);
+expect(__builtin_object_size(trailing_0->c, 1), 0);
+expect(__builtin_object_size(trailing_flex->c, 1), -1);
+}
+
+int main(int argc, char *argv[])
+{
+stuff((void *)argv[0], (void *)argv[0], (void *)argv[0], (void *)argv[0]);
+
+return 0;
+}
diff --git a/gcc/testsuite/gcc.dg/pr101836_1.c
b/gcc/testsuite/gcc.dg/pr101836_1.c
new file mode 100644
index 000..e2931ce1012
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr101836_1.c
@@ -0,0 +1,60 @@
+/* -fstrict-flex-arrays=3 is the strictest, only [] is treated as
+ flexible array. */
+/* PR tree-optimization/101836 */
+/* { dg-do run } */
+/* { dg-options "-O2 -fstrict-flex-arrays=3" } */
+
+#include
+
+#define expect(p, _v) do { \
+size_t v = _v; \
+if (p == v) \
+printf("ok: %s == %zd\n", #p, p); \
+else \
+ { \
+ printf("WAT: %s == %zd (expected %zd)\n", #p, p, v); \
+ __builtin_abort (); \
+ } \
+} while (0);
+
+struct trailing_array_1 {
+int a;
+int b;
+int c[4];
+};
+
+struct trailing_array_2 {
+int a;
+int b;
+int c[1];
+};
+
+struct trailing_array_3 {
+int a;
+int b;
+int c[0];
+};
+struct trailing_array_4 {
+int a;
+int b;
+int c[];
+};
+
+void __attribute__((__noinline__)) stuff(
+struct trailing_array_1 *normal,
+struct trailing_array_2 *trailing_1,
+struct trailing_array_3 *trailing_0,
+struct trailing_array_4 *trailing_flex)
+{
+expect(__builtin_object_size(normal->c, 1), 16);
+expect(__builtin_object_size(trailing_1->c, 1), 4);
+expect(__builtin_object_size(trailing_0->c, 1), 0);
+expect(__builtin_object_size(trailing_flex->c, 1), -1);
+}
+
+int main(int argc, char *argv[])
+{
+stuff((void *)argv[0], (void *)argv[0], (void *)argv[0], (void *)argv[0]);
+
+r
[GCC13][Patch][V6][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array
Add the following new option -fstrict-flex-arrays[=n] and a corresponding
attribute strict_flex_array to GCC:
'-fstrict-flex-arrays'
Control when to treat the trailing array of a structure as a flexible array
member for the purpose of accessing the elements of such an array.
The positive form is equivalent to '-fstrict-flex-arrays=3', which is the
strictest. A trailing array is treated as a flexible array member only
when
it declared as a flexible array member per C99 standard onwards.
The negative form is equivalent to '-fstrict-flex-arrays=0', which is the
least strict. All trailing arrays of structures are treated as flexible
array members.
'-fstrict-flex-arrays=LEVEL'
Control when to treat the trailing array of a structure as a flexible array
member for the purpose of accessing the elements of such an array. The
value
of LEVEL controls the level of strictness
The possible values of LEVEL are the same as for the
'strict_flex_array' attribute (*note Variable Attributes::).
You can control this behavior for a specific trailing array field
of a structure by using the variable attribute 'strict_flex_array'
attribute (*note Variable Attributes::).
'strict_flex_array (LEVEL)'
The 'strict_flex_array' attribute should be attached to the trailing
array field of a structure. It controls when to treat the trailing array
field of a structure as a flexible array member for the purposesof
accessing
the elements of such an array. LEVEL must be an integer betwen 0 to 3.
LEVEL=0 is the least strict level, all trailing arrays of
structures are treated as flexible array members. LEVEL=3 is the
strictest level, only when the trailing array is declared as a
flexible array member per C99 standard onwards ('[]'), it is
treated as a flexible array member.
There are two more levels in between 0 and 3, which are provided to
support older codes that use GCC zero-length array extension
('[0]') or one-element array as flexible array members('[1]'): When
LEVEL is 1, the trailing array is treated as a flexible array member
when it is declared as either '[]', '[0]', or '[1]'; When
LEVEL is 2, the trailing array is treated as a flexible array member
when it is declared as either '[]', or '[0]'.
This attribute can be used with or without the
'-fstrict-flex-arrays'. When both the attribute and the option
present at the same time, the level of the strictness for the
specific trailing array field is determined by the attribute.
gcc/c-family/ChangeLog:
* c-attribs.cc (handle_strict_flex_array_attribute): New function.
(c_common_attribute_table): New item for strict_flex_array.
* c.opt: (fstrict-flex-arrays): New option.
(fstrict-flex-arrays=): New option.
gcc/c/ChangeLog:
* c-decl.cc (flexible_array_member_type_p): New function.
(one_element_array_type_p): Likewise.
(zero_length_array_type_p): Likewise.
(add_flexible_array_elts_to_size): Call new utility
routine flexible_array_member_type_p.
(is_flexible_array_member_p): New function.
(finish_struct): Set the new DECL_NOT_FLEXARRAY flag.
gcc/cp/ChangeLog:
* module.cc (trees_out::core_bools): Stream out new bit
decl_not_flexarray.
(trees_in::core_bools): Stream in new bit decl_not_flexarray.
gcc/ChangeLog:
* doc/extend.texi: Document strict_flex_array attribute.
* doc/invoke.texi: Document -fstrict-flex-arrays[=n] option.
* print-tree.cc (print_node): Print new bit decl_not_flexarray.
* tree-core.h (struct tree_decl_common): New bit field
decl_not_flexarray.
* tree-streamer-in.cc (unpack_ts_decl_common_value_fields): Stream
in new bit decl_not_flexarray.
* tree-streamer-out.cc (pack_ts_decl_common_value_fields): Stream
out new bit decl_not_flexarray.
* tree.cc (array_at_struct_end_p): Update it with the new bit field
decl_not_flexarray.
* tree.h (DECL_NOT_FLEXARRAY): New flag.
gcc/testsuite/ChangeLog:
* g++.dg/strict-flex-array-1.C: New test.
* gcc.dg/strict-flex-array-1.c: New test.
---
gcc/c-family/c-attribs.cc | 47
gcc/c-family/c.opt | 7 ++
gcc/c/c-decl.cc| 130 +++--
gcc/cp/module.cc | 2 +
gcc/doc/extend.texi| 26 +
gcc/doc/invoke.texi| 28 -
gcc/print-tree.cc | 8 +-
gcc/testsuite/g++.dg/strict-flex-array-1.C | 31 +
gcc/testsuite/gcc.dg/strict-flex-array-1.c | 33 ++
gcc/tree-core.h| 5 +-
gcc/tree-streamer-in.cc| 1 +
gcc/tree-streamer-out.cc | 1 +
gcc/tree.cc
Re: [PATCH] middle-end, c++, i386, libgcc: std::bfloat16_t and __bf16 arithmetic support
On 10/5/22 09:47, Jakub Jelinek wrote:
On Tue, Oct 04, 2022 at 05:50:50PM -0400, Jason Merrill wrote:
Another question is the suffixes of the builtins. For now I have added
bf16 suffix and enabled the builtins with !both_p, so one always needs to
use __builtin_* form for them. None of the GCC builtins end with b,
so this isn't ambiguous with __builtin_*f16, but some libm functions do end
with b, in particular ilogb, logb and f{??,??x}sub. ilogb and the subs
always have it, but is __builtin_logbf16 f16 suffixed logb or bf16 suffixed
log? Shall the builtins use f16b suffixes instead like the mangling does?
Do we want bf16 builtins at all? The impression I've gotten is that users
want computation to happen in SFmode and only later truncate back to BFmode.
As I wrote earlier, I think we need at least one, __builtin_nans variant
which would be used in libstdc++
std::numeric_limits::signaling_NaN() implementation.
I think
std::numeric_limits::infinity() can be implemented as
return (__bf16) __builtin_huge_valf ();
and similarly
std::numeric_limits::quiet_NaN() as
return (__bf16) __builtin_nanf ("");
but
return (__bf16) __builtin_nansf ("");
would loose the signaling NaN on the conversion and raise exception,
and as the method is constexpr,
union { unsigned short a; __bf16 b; } u = { 0x7f81 };
return u.b;
wouldn't work. I can certainly restrict the builtins to the single
one, but wonder whether the suffix for that builtin shouldn't be chosen
such that eventually we could add more builtins if we need to
and don't run into the log with bf16 suffix vs. logb with f16 suffix
ambiguity.
As you said, most of the libstdc++ overloads for std::bfloat16_t then
can use float builtins or library calls under the hood, but std::nextafter
is another case where I think we'll need to have something bfloat16_t
specific, because float ulp isn't bfloat16_t ulp, the latter is much larger.
Makes sense.
Based on what Joseph wrote, I'll add bf16/BF16 suffix support for C too
in the next iteration (always with pedwarn in that case).
@@ -5716,7 +5716,13 @@ emit_store_flag_1 (rtx target, enum rtx_
{
machine_mode optab_mode = mclass == MODE_CC ? CCmode : compare_mode;
icode = optab_handler (cstore_optab, optab_mode);
- if (icode != CODE_FOR_nothing)
+ if (icode != CODE_FOR_nothing
+/* Don't consider [BH]Fmode as usable wider mode, as neither is
+ a subset or superset of the other. */
+&& (compare_mode == mode
+|| !SCALAR_FLOAT_MODE_P (compare_mode)
+|| maybe_ne (GET_MODE_PRECISION (compare_mode),
+ GET_MODE_PRECISION (mode
Why do you need to do this here (and in prepare_cmp_insn, and similarly in
can_compare_p)? Shouldn't get_wider skip over modes that are not actually
wider?
I'm afraid too many places rely on all modes of a certain class to be
visible when walking from "narrowest" to "widest" mode, say
FOR_EACH_MODE_IN_CLASS/FOR_EACH_MODE/FOR_EACH_MODE_UNTIL/FOR_EACH_WIDER_MODE
etc. wouldn't work at all if GET_MODE_WIDER_MODE (BFmode) == SFmode
&& GET_MODE_WIDER_MODE (HFmode) == SFmode.
Yes, it seems they need to change now that their assumptions have been
violated. I suppose FOR_EACH_MODE_IN_CLASS would need to change to not
use get_wider, and users of FOR_EACH_MODE/FOR_EACH_MODE_UNTIL need to
decide whether they want an iteration that uses get_wider (likely with a
new name) or not.
Note, besides this GET_MODE_PRECISION (HFmode) == GET_MODE_PRECISION (BFmode)
case, another set of modes which have the same size are powerpc*
TFmode/IFmode/KFmode, but in that case it makes ugly hacks where it
artificially lowers the precision of 2 of them:
rs6000-modes.h:#define FLOAT_PRECISION_IFmode 128
rs6000-modes.h:#define FLOAT_PRECISION_TFmode 127
rs6000-modes.h:#define FLOAT_PRECISION_KFmode 126
(and the middle-end then has to work around that mess). Doing something
similar wouldn't help the BFmode vs. HFmode case though, one of them would
have wider precision and so e.g. C FE would then prefer it, but more
importantly, as they are unordered modes where most of the optabs aren't
implemented it is bad to pick optabs for the "wider" mode to handle the
"narrower" one. I think powerpc works because they define optabs for
all the 3 modes when those modes are usable.
Jakub
Re: [PATCH][pushed] contrib: run fetch before pushing Daily bump
On 05.10.22 20:41, Martin Liška wrote:
+++ b/contrib/gcc-changelog/git_update_version.py
@@ -127,6 +127,7 @@ def update_current_branch(ref_name):
repo.git.add(datestamp_path)
if not args.current:
repo.index.commit('Daily bump.')
+origin.fetch()
if args.push:
repo.git.push('origin', branch)
print('branch is pushed')
Don't you need a 'rebase' in addition? Or alternately – putting 'fetch'
before 'commit' and then 'merge' would be alternately possible.
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Re: [PATCH v2] testsuite: Sanitize fails for SP FPU on Arm
On Wed, 5 Oct 2022, Torbjörn SVENSSON via Gcc-patches wrote: > -/* These should be defined if and only if signaling NaNs are supported > - for the given types. If the testsuite gains effective-target > - support for targets not supporting signaling NaNs, or not > - supporting them for all types, this test should be made > - appropriately conditional. */ > +/* This should be defined if and only if signaling NaNs is supported > + for the given type. */ You've lost the point from the previous comment that the test should be made (further) conditional if the testsuite gains effective-target support for targets not supporting signaling NaNs. This patch deals with targets where exceptions are only supported for some types, but the test remains unportable to systems without sNaN support, and so the comment about that unportability should remain. -- Joseph S. Myers jos...@codesourcery.com
Re: [GCC13][Patch][V6][PATCH 1/2] Add a new option -fstrict-flex-arrays[=n] and new attribute strict_flex_array
On Wed, 5 Oct 2022, Qing Zhao via Gcc-patches wrote: > + /* if not the last field, return false. */ Comments should start with an uppercase letter. > + /* if not an array field, return false. */ > + /* if there is a strict_flex_array attribute attached to the field, > + override the flag_strict_flex_arrays. */ > + /* get the value of the level first from the attribute. */ > + /* the attribute has higher priority than flag_struct_flex_array. */ > + /* default, all trailing arrays are flexiable array members. */ Likewise, and "flexible" not "flexiable". > + /* whether this field is the last field of the structure or union. > + for UNION, any field is the last field of it. */ Likewise. > +field of a structure as a flexible array member for the purposesof accessing Missing space, should be "purposes of". The C front-end and docs changes are OK with the fixes above. -- Joseph S. Myers jos...@codesourcery.com
Re: [PATCH, v2] Fortran: reject procedures and procedure pointers as IO element [PR107074]
Hi Mikael,
> Gesendet: Mittwoch, 05. Oktober 2022 um 12:34 Uhr
> Von: "Mikael Morin"
> Please move the check to resolve_transfer in resolve.cc.
I have done this, see attached updated patch.
Regtests cleanly on x86_64-pc-linux-gnu.
> Strangely, the patch doesn't seem to fix the problem on the testcase
> here. There is an outer parenthese expression preventing the condition
> you added from triggering. Can you double check?
You are right: I had a one-liner in my worktree from PR105371 that
fixes an issue with gfc_simplify_merge and that seems to help here.
It is now included.
> If we take the standard to the letter, only output items are forbidden,
> so a check is missing for writing context. I don't know how it can work
> for input items though, so maybe not worth it. In any case, the error
> shouldn't mention output items in reading context.
>
> Here is a variant of the testcase with procedure pointer components,
> that fails differently but can probably be caught as well.
>
> program p
>implicit none
>type :: t
> procedure(f), pointer, nopass :: b
>end type t
>type(t) :: a
>
>interface
> real function f()
> end function f
>end interface
>
>print *, merge (a%b, a%b, .true.)
> end
I hadn't thought about this, and found a solution that also fixes this
one. Great example! This is now an additional test.
OK for mainline?
And thanks for your comments!
Harald
From 70cba7da18023282546b9a5d80e976fc3744d732 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Wed, 5 Oct 2022 22:25:14 +0200
Subject: [PATCH] Fortran: reject procedures and procedure pointers as IO
element [PR107074]
gcc/fortran/ChangeLog:
PR fortran/107074
* resolve.cc (resolve_transfer): A procedure, type-bound procedure
or a procedure pointer cannot be an element of an IO list.
* simplify.cc (gfc_simplify_merge): Do not try to reset array lower
bound for scalars.
gcc/testsuite/ChangeLog:
PR fortran/107074
* gfortran.dg/pr107074.f90: New test.
* gfortran.dg/pr107074b.f90: New test.
---
gcc/fortran/resolve.cc | 31 +
gcc/fortran/simplify.cc | 3 ++-
gcc/testsuite/gfortran.dg/pr107074.f90 | 11 +
gcc/testsuite/gfortran.dg/pr107074b.f90 | 18 ++
4 files changed, 62 insertions(+), 1 deletion(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr107074.f90
create mode 100644 gcc/testsuite/gfortran.dg/pr107074b.f90
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index d133bc2d034..d9d101775f6 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -10137,6 +10137,37 @@ resolve_transfer (gfc_code *code)
"an assumed-size array", &code->loc);
return;
}
+
+ /* Check for procedures and procedure pointers. Fortran 2018 has:
+
+ C1233 (R1217) An expression that is an output-item shall not have a
+ value that is a procedure pointer.
+
+ There does not appear any reason to allow procedure pointers for
+ input, so we disallow them generally, and we reject procedures. */
+
+ if (exp->expr_type == EXPR_VARIABLE)
+{
+ /* Check for type-bound procedures. */
+ for (ref = exp->ref; ref; ref = ref->next)
+ if (ref->type == REF_COMPONENT
+ && ref->u.c.component->attr.flavor == FL_PROCEDURE)
+ break;
+
+ /* Procedure or procedure pointer? */
+ if (exp->ts.type == BT_PROCEDURE
+ || (ref && ref->u.c.component->attr.flavor == FL_PROCEDURE))
+ {
+ if (exp->symtree->n.sym->attr.proc_pointer
+ || (ref && ref->u.c.component->attr.proc_pointer))
+ gfc_error ("Data transfer element at %L cannot be a procedure "
+ "pointer", &code->loc);
+ else
+ gfc_error ("Data transfer element at %L cannot be a procedure",
+ &code->loc);
+ return;
+ }
+}
}
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 6ac92cf9db8..f0482d349af 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -4915,7 +4915,8 @@ gfc_simplify_merge (gfc_expr *tsource, gfc_expr *fsource, gfc_expr *mask)
{
result = gfc_copy_expr (mask->value.logical ? tsource : fsource);
/* Parenthesis is needed to get lower bounds of 1. */
- result = gfc_get_parentheses (result);
+ if (result->rank)
+ result = gfc_get_parentheses (result);
gfc_simplify_expr (result, 1);
return result;
}
diff --git a/gcc/testsuite/gfortran.dg/pr107074.f90 b/gcc/testsuite/gfortran.dg/pr107074.f90
new file mode 100644
index 000..1363c285912
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107074.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/107074 - ICE: Bad IO basetype (8)
+! Contributed by G.Steinmetz
+
+program p
+ implicit none
+ integer, external:: a
+ procedure(real), pointer :: b
+ print *, merge (a, a, .true.) ! { dg-error "procedure" }
+ print *, merge (b, b, .true.) ! { dg-error "procedure pointer" }
+end
diff --git a/gcc/testsuite/gfortran.dg/pr107074b.f90
[PATCH] c++: fixes for derived-to-base reference binding [PR107085]
This PR reports that
struct Base {};
struct Derived : Base {};
static_assert(__reference_constructs_from_temporary(Base const&, Derived));
doesn't pass, which it should: it's just like
const Base& b(Derived{});
where we bind 'b' to the Base subobject of a temporary object of type
Derived. The ck_base conversion didn't have ->need_temporary_p set because
we didn't need to create a temporary object just for the base, but the whole
object is a temporary so we're still binding to a temporary. Fixed by
the conv_is_prvalue hunk.
That broke a bunch of tests. I've distilled the issue into a simple test
in elision4.C. Essentially, we have
struct B { /* ... */ };
struct D : B { };
B b = D();
and we set force_elide in build_over_call, but we're unable to actually
elide the B::B(B&&) call, and crash on gcc_assert (!force_elide);.
says that copy
elision "can only apply when the object being initialized is known not to be
a potentially-overlapping subobject". So I suppose we shouldn't force_elide
the B::B(B&&) call. I don't belive the CWG 2327 code was added to handle
derived-to-base conversions, at that time conv_binds_ref_to_prvalue wasn't
checking ck_base at all.
Does that make sense? If so...
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/107085
gcc/cp/ChangeLog:
* call.cc (conv_is_prvalue): Return true if the base subobject is part
of a temporary object.
(build_over_call): Don't force_elide when it's a derived-to-base
conversion.
gcc/testsuite/ChangeLog:
* g++.dg/ext/reference_constructs_from_temporary1.C: Adjust expected
result.
* g++.dg/ext/reference_converts_from_temporary1.C: Likewise.
* g++.dg/cpp0x/elision4.C: New test.
---
gcc/cp/call.cc | 17 +++--
gcc/testsuite/g++.dg/cpp0x/elision4.C | 17 +
.../ext/reference_constructs_from_temporary1.C | 2 +-
.../ext/reference_converts_from_temporary1.C| 2 +-
4 files changed, 34 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/elision4.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index bd04a1d309a..15e969d6429 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -9186,7 +9186,11 @@ conv_is_prvalue (conversion *c)
{
if (c->kind == ck_rvalue)
return true;
- if (c->kind == ck_base && c->need_temporary_p)
+ if (c->kind == ck_base
+ /* We may not need a temporary object for the base itself, but if it
+is the base subobject of a temporary object, we're still dealing
+with a prvalue. */
+ && (c->need_temporary_p || conv_is_prvalue (next_conversion (c
return true;
if (c->kind == ck_user && !TYPE_REF_P (c->type))
return true;
@@ -9417,7 +9421,16 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
&& (DECL_COPY_CONSTRUCTOR_P (fn)
|| DECL_MOVE_CONSTRUCTOR_P (fn))
&& !unsafe_return_slot_p (first_arg)
- && conv_binds_ref_to_prvalue (convs[0]))
+ && conv_binds_ref_to_prvalue (convs[0])
+ /* Converting a class to another class that then binds to this
+copy/move constructor's argument is OK, but not when it's a
+derived-to-base conversion. */
+ && [convs] {
+ for (conversion *t = convs[0]; t; t = next_conversion (t))
+if (t->kind == ck_base)
+ return false;
+ return true;
+}())
{
force_elide = true;
goto not_really_used;
diff --git a/gcc/testsuite/g++.dg/cpp0x/elision4.C
b/gcc/testsuite/g++.dg/cpp0x/elision4.C
new file mode 100644
index 000..4833b50d48e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/elision4.C
@@ -0,0 +1,17 @@
+// PR c++/107085
+// { dg-do compile { target c++11 } }
+
+// Must be non-trivial to exhibit the ICE.
+struct X {
+ X();
+ X(X&&);
+};
+struct Z : X {};
+X x1 = Z();
+X x2 = X(Z());
+
+// ...but let's try the trivial path in build_over_call as well.
+struct B { };
+struct D : B { };
+B b1 = D();
+B b2 = B(D());
diff --git a/gcc/testsuite/g++.dg/ext/reference_constructs_from_temporary1.C
b/gcc/testsuite/g++.dg/ext/reference_constructs_from_temporary1.C
index 76de905a35d..5354b1dc4e6 100644
--- a/gcc/testsuite/g++.dg/ext/reference_constructs_from_temporary1.C
+++ b/gcc/testsuite/g++.dg/ext/reference_constructs_from_temporary1.C
@@ -201,7 +201,7 @@ SA(!__reference_constructs_from_temporary(const int&, H));
SA(!__reference_constructs_from_temporary(int&&, G2));
SA(!__reference_constructs_from_temporary(const int&, H2));
-SA(!__reference_constructs_from_temporary(const Base&, Der));
+SA(__reference_constructs_from_temporary(const Base&, Der));
// This fails because std::is_constructible_v> is false.
SA(!__reference_constructs_from_temporary(int&&, id));
diff --git a/gcc/testsuite/g++.dg/ext/reference_converts_from_temporary1.C
b/gcc/testsuit
Re: [PATCH, v2] Fortran: error recovery for invalid types in array constructors [PR107000]
Hi Mikael,
> Gesendet: Mittwoch, 05. Oktober 2022 um 11:23 Uhr
> Von: "Mikael Morin"
> An: "Harald Anlauf" , "fortran" ,
> "gcc-patches"
> Betreff: Re: [PATCH] Fortran: error recovery for invalid types in array
> constructors [PR107000]
> The following does.
>
>
> diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
> index e6e35ef3c42..2c57c796270 100644
> --- a/gcc/fortran/arith.cc
> +++ b/gcc/fortran/arith.cc
> @@ -1443,7 +1443,7 @@ reduce_binary_aa (arith (*eval) (gfc_expr *,
> gfc_expr *, gfc_expr **),
> gfc_replace_expr (c->expr, r);
> }
>
> - if (c || d)
> + if (rc == ARITH_OK && (c || d))
> rc = ARITH_INCOMMENSURATE;
>
> if (rc != ARITH_OK)
that's great! It fixes several rather weird cases. (There is at least
another PR on the incommensurate arrays, but we should not attempt to
fix everything today.)
> There is one last thing that I'm dissatisfied with.
> The handling of unknown types should be moved to reduce_binary, because
> the dispatching in reduce_binary doesn't handle EXPR_OP, so even if
> either or both operands are scalar, they are handled by the (array vs
> array) reduce_binary_aa function. That's confusing.
Do you have an example?
Anyway, please find attached an updated patch that incorporates your
two changes and regtests fine on x86_64-pc-linux-gnu.
Even if you disagree, I think this is really a significant step
forwards... (error-recovery wise).
OK for mainline?
Thanks,
Harald
From 1b40214b2b538ec176ff6c118770e6e1cc8796ae Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Tue, 4 Oct 2022 23:04:06 +0200
Subject: [PATCH] Fortran: error recovery for invalid types in array
constructors [PR107000]
gcc/fortran/ChangeLog:
PR fortran/107000
* arith.cc (gfc_arith_error): Define error message for
ARITH_INVALID_TYPE.
(reduce_unary): Catch arithmetic expressions with invalid type.
(reduce_binary_ac): Likewise.
(reduce_binary_ca): Likewise.
(reduce_binary_aa): Likewise.
(eval_intrinsic): Likewise.
(gfc_real2complex): Source expression must be of type REAL.
* gfortran.h (enum arith): Add ARITH_INVALID_TYPE.
gcc/testsuite/ChangeLog:
PR fortran/107000
* gfortran.dg/pr107000.f90: New test.
Co-authored-by: Mikael Morin
---
gcc/fortran/arith.cc | 23 +++-
gcc/fortran/gfortran.h | 2 +-
gcc/testsuite/gfortran.dg/pr107000.f90 | 50 ++
3 files changed, 73 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr107000.f90
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index d57059a375f..2c57c796270 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -118,6 +118,9 @@ gfc_arith_error (arith code)
case ARITH_WRONGCONCAT:
p = G_("Illegal type in character concatenation at %L");
break;
+case ARITH_INVALID_TYPE:
+ p = G_("Invalid type in arithmetic operation at %L");
+ break;
default:
gfc_internal_error ("gfc_arith_error(): Bad error code");
@@ -1261,6 +1264,9 @@ reduce_unary (arith (*eval) (gfc_expr *, gfc_expr **), gfc_expr *op,
gfc_expr *r;
arith rc;
+ if (op->expr_type == EXPR_OP && op->ts.type == BT_UNKNOWN)
+return ARITH_INVALID_TYPE;
+
if (op->expr_type == EXPR_CONSTANT)
return eval (op, result);
@@ -1302,6 +1308,9 @@ reduce_binary_ac (arith (*eval) (gfc_expr *, gfc_expr *, gfc_expr **),
gfc_expr *r;
arith rc = ARITH_OK;
+ if (op1->expr_type == EXPR_OP && op1->ts.type == BT_UNKNOWN)
+return ARITH_INVALID_TYPE;
+
head = gfc_constructor_copy (op1->value.constructor);
for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
{
@@ -1354,6 +1363,9 @@ reduce_binary_ca (arith (*eval) (gfc_expr *, gfc_expr *, gfc_expr **),
gfc_expr *r;
arith rc = ARITH_OK;
+ if (op2->expr_type == EXPR_OP && op2->ts.type == BT_UNKNOWN)
+return ARITH_INVALID_TYPE;
+
head = gfc_constructor_copy (op2->value.constructor);
for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
{
@@ -1414,6 +1426,10 @@ reduce_binary_aa (arith (*eval) (gfc_expr *, gfc_expr *, gfc_expr **),
if (!gfc_check_conformance (op1, op2, _("elemental binary operation")))
return ARITH_INCOMMENSURATE;
+ if ((op1->expr_type == EXPR_OP && op1->ts.type == BT_UNKNOWN)
+ || (op2->expr_type == EXPR_OP && op2->ts.type == BT_UNKNOWN))
+return ARITH_INVALID_TYPE;
+
head = gfc_constructor_copy (op1->value.constructor);
for (c = gfc_constructor_first (head),
d = gfc_constructor_first (op2->value.constructor);
@@ -1427,7 +1443,7 @@ reduce_binary_aa (arith (*eval) (gfc_expr *, gfc_expr *, gfc_expr **),
gfc_replace_expr (c->expr, r);
}
- if (c || d)
+ if (rc == ARITH_OK && (c || d))
rc = ARITH_INCOMMENSURATE;
if (rc != ARITH_OK)
@@ -1638,6 +1654,8 @@ eval_intrinsic (gfc_intrinsic_op op,
else
rc = reduce_binary (eval.f3, op1, op2, &result);
+ if (rc == ARITH_INVALID_TYPE)
+goto runtime;
/* Somet
Re: [PATCH] c++: fixes for derived-to-base reference binding [PR107085]
On 10/5/22 17:27, Marek Polacek wrote:
This PR reports that
struct Base {};
struct Derived : Base {};
static_assert(__reference_constructs_from_temporary(Base const&, Derived));
doesn't pass, which it should: it's just like
const Base& b(Derived{});
where we bind 'b' to the Base subobject of a temporary object of type
Derived. The ck_base conversion didn't have ->need_temporary_p set because
we didn't need to create a temporary object just for the base, but the whole
object is a temporary so we're still binding to a temporary. Fixed by
the conv_is_prvalue hunk.
That broke a bunch of tests. I've distilled the issue into a simple test
in elision4.C. Essentially, we have
struct B { /* ... */ };
struct D : B { };
B b = D();
and we set force_elide in build_over_call, but we're unable to actually
elide the B::B(B&&) call, and crash on gcc_assert (!force_elide);.
says that copy
elision "can only apply when the object being initialized is known not to be
a potentially-overlapping subobject". So I suppose we shouldn't force_elide
the B::B(B&&) call. I don't belive the CWG 2327 code was added to handle
derived-to-base conversions, at that time conv_binds_ref_to_prvalue wasn't
checking ck_base at all.
Does that make sense? If so...
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
PR c++/107085
gcc/cp/ChangeLog:
* call.cc (conv_is_prvalue): Return true if the base subobject is part
of a temporary object.
No, the base subobject of a prvalue is an xvalue.
I think the problem is that an expression being a prvalue is a subset of
binding a reference to a temporary, and we shouldn't try to express both
of those using the same function: you need a separate
conv_binds_ref_to_temporary.
(build_over_call): Don't force_elide when it's a derived-to-base
conversion.
gcc/testsuite/ChangeLog:
* g++.dg/ext/reference_constructs_from_temporary1.C: Adjust expected
result.
* g++.dg/ext/reference_converts_from_temporary1.C: Likewise.
* g++.dg/cpp0x/elision4.C: New test.
---
gcc/cp/call.cc | 17 +++--
gcc/testsuite/g++.dg/cpp0x/elision4.C | 17 +
.../ext/reference_constructs_from_temporary1.C | 2 +-
.../ext/reference_converts_from_temporary1.C| 2 +-
4 files changed, 34 insertions(+), 4 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/cpp0x/elision4.C
diff --git a/gcc/cp/call.cc b/gcc/cp/call.cc
index bd04a1d309a..15e969d6429 100644
--- a/gcc/cp/call.cc
+++ b/gcc/cp/call.cc
@@ -9186,7 +9186,11 @@ conv_is_prvalue (conversion *c)
{
if (c->kind == ck_rvalue)
return true;
- if (c->kind == ck_base && c->need_temporary_p)
+ if (c->kind == ck_base
+ /* We may not need a temporary object for the base itself, but if it
+is the base subobject of a temporary object, we're still dealing
+with a prvalue. */
+ && (c->need_temporary_p || conv_is_prvalue (next_conversion (c
return true;
if (c->kind == ck_user && !TYPE_REF_P (c->type))
return true;
@@ -9417,7 +9421,16 @@ build_over_call (struct z_candidate *cand, int flags,
tsubst_flags_t complain)
&& (DECL_COPY_CONSTRUCTOR_P (fn)
|| DECL_MOVE_CONSTRUCTOR_P (fn))
&& !unsafe_return_slot_p (first_arg)
- && conv_binds_ref_to_prvalue (convs[0]))
+ && conv_binds_ref_to_prvalue (convs[0])
+ /* Converting a class to another class that then binds to this
+copy/move constructor's argument is OK, but not when it's a
+derived-to-base conversion. */
+ && [convs] {
+ for (conversion *t = convs[0]; t; t = next_conversion (t))
+if (t->kind == ck_base)
+ return false;
+ return true;
+}())
{
force_elide = true;
goto not_really_used;
diff --git a/gcc/testsuite/g++.dg/cpp0x/elision4.C
b/gcc/testsuite/g++.dg/cpp0x/elision4.C
new file mode 100644
index 000..4833b50d48e
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp0x/elision4.C
@@ -0,0 +1,17 @@
+// PR c++/107085
+// { dg-do compile { target c++11 } }
+
+// Must be non-trivial to exhibit the ICE.
+struct X {
+ X();
+ X(X&&);
+};
+struct Z : X {};
+X x1 = Z();
+X x2 = X(Z());
+
+// ...but let's try the trivial path in build_over_call as well.
+struct B { };
+struct D : B { };
+B b1 = D();
+B b2 = B(D());
diff --git a/gcc/testsuite/g++.dg/ext/reference_constructs_from_temporary1.C
b/gcc/testsuite/g++.dg/ext/reference_constructs_from_temporary1.C
index 76de905a35d..5354b1dc4e6 100644
--- a/gcc/testsuite/g++.dg/ext/reference_constructs_from_temporary1.C
+++ b/gcc/testsuite/g++.dg/ext/reference_constructs_from_temporary1.C
@@ -201,7 +201,7 @@ SA(!__reference_constructs_from_temporary(const int&, H));
SA(!__reference_constructs_from_temporary(int&&, G2));
SA(!__reference_constructs_from_tempor
c: C2x typeof
[C++ maintainers / global reviewers, note that there is a C++
front-end change here needing review.]
C2x adds typeof as a standard feature. In general this follows
existing GNU C semantics very closely, but there are various ways in
which the implementation involves more than simply enabling the
keyword for C2x:
* As well as typeof, there is a typeof_unqual variant, which removes
all qualifiers and _Atomic from the resulting type (whereas typeof
preserves qualifiers and _Atomic on qualified or atomic (lvalue or
type name) operands).
* The typeof keyword is disabled by -fno-asm, so enabling it for C2x
needs to be implemented in a way that preserves the disabling by
-fno-asm for older standard versions (which having -fno-asm having
no effect on it in C2x mode). This is done via adding a new D_EXT11
mask (which is also where the C++ front-end change comes from, to
handle D_EXT11 appropriately there for -fno-asm and
-fno-gnu-keywords).
* GNU typeof treats the noreturn property of a function (as specified
in standard C with _Noreturn or [[noreturn]]) as being part of the
type of a pointer to function, but it is not part of the type in
standard terms. Thus a special case is needed in the typeof
implementation, just like in the _Generic implementation, to avoid
treating it as a type for standard typeof. It seems plausible this
is being used when copying the type of one object to another using
typeof, so the existing semantics are preserved for __typeof__, and
for typeof in pre-C2x modes, while typeof for C2x or later has the
standard semantics.
* It turns out that, even after Martin Uecker's changes in this area,
there were still cases where rvalues could wrongly have a qualified
or atomic type in GCC. This applied to ++ and -- increment and
decrement expressions, and also to calls to functions returning an
atomic type. (For the latter, the working draft doesn't actually
explicitly exclude the function call expression having an atomic
type, but given all the changes that have gone into C17 and C2x to
avoid rvalues ever having qualified types, and given that
lvalue-to-rvalue conversion removes both qualifiers and _Atomic, it
seems unlikely that this (or casts, where GCC already removes
_Atomic) is actually intended as a route to allow an
_Atomic-qualified rvalue; I've noted this to raise as an NB comment
on the CD ballot.)
Bootstrapped with no regressions for x86_64-pc-linux-gnu. OK to
commit (C++ front-end changes)?
gcc/
* doc/invoke.texi (-fno-asm): Update description of effects on
typeof keyword.
gcc/c-family/
* c-common.cc (c_common_reswords): Mark typeof as D_EXT11. Add
typeof_unqual.
* c-common.h (enum rid): Add RID_TYPEOF_UNQUAL.
(D_EXT11): New macro. Values of subsequent macros updated.
gcc/c/
* c-parser.cc (c_parse_init): Add D_EXT11 to mask if flag_no_asm
and not C2x.
(c_keyword_starts_typename, c_token_starts_declspecs)
(c_parser_declspecs, c_parser_objc_selector): Handle
RID_TYPEOF_UNQUAL.
(c_parser_typeof_specifier): Handle RID_TYPEOF_UNQUAL.
Distinguish typeof for C2x from __typeof__ for all standard
versions and typeof before C2x.
* c-typeck.cc (build_function_call_vec): Use unqualified version
of non-void return type.
(build_unary_op): Use unqualified type for increment and
decrement.
gcc/cp/
* lex.cc (init_reswords): Handle D_EXT11.
gcc/testsuite/
* gcc.dg/c11-typeof-1.c, gcc.dg/c2x-typeof-1.c,
gcc.dg/c2x-typeof-2.c, gcc.dg/c2x-typeof-3.c,
gcc.dg/gnu11-typeof-1.c, gcc.dg/gnu11-typeof-2.c,
gcc.dg/gnu2x-typeof-1.c: New tests.
diff --git a/gcc/c-family/c-common.cc b/gcc/c-family/c-common.cc
index 4f9878d2695..ffe17eaa9d9 100644
--- a/gcc/c-family/c-common.cc
+++ b/gcc/c-family/c-common.cc
@@ -494,7 +494,8 @@ const struct c_common_resword c_common_reswords[] =
{ "typedef", RID_TYPEDEF,0 },
{ "typename",RID_TYPENAME, D_CXXONLY | D_CXXWARN },
{ "typeid", RID_TYPEID, D_CXXONLY | D_CXXWARN },
- { "typeof", RID_TYPEOF, D_ASM | D_EXT },
+ { "typeof", RID_TYPEOF, D_EXT11 },
+ { "typeof_unqual", RID_TYPEOF_UNQUAL, D_CONLY | D_C2X },
{ "union", RID_UNION, 0 },
{ "unsigned",RID_UNSIGNED, 0 },
{ "using", RID_USING, D_CXXONLY | D_CXXWARN },
diff --git a/gcc/c-family/c-common.h b/gcc/c-family/c-common.h
index 5f470d94f4a..62ab4ba437b 100644
--- a/gcc/c-family/c-common.h
+++ b/gcc/c-family/c-common.h
@@ -104,7 +104,8 @@ enum rid
RID_SIZEOF,
/* C extensions */
- RID_ASM, RID_TYPEOF, RID_ALIGNOF, RID_ATTRIBUTE, RID_VA_ARG,
+ RID_ASM, RID_TYPEOF, RID_TYPEOF_UNQUAL, RID_ALIGNOF, RID_ATTRIBUTE,
+ RID_VA_ARG,
RID_EXTENSION, RID_IMAGPART, RID_REALPART, RID_LABEL, RID_CHOOSE_EXPR,
Re: [PATCH] RISC-V: Default to tuning for the thead-c906
-1 for this, default enable fast unaligned access could cause many
problems, and lots of RISC-V cores
don't support HW unaligned access (Rocket-base RISC-V core, most
SiFive core, and most Andes core IIRC),
change this to default means package from RISC-V linux distro might
contain unaligned access by default.
The default one should be the safest option, in case people really
want that, they could use --with-tune and
--with-arch to change that.
On Wed, Oct 5, 2022 at 1:57 PM Andrew Pinski via Gcc-patches
wrote:
>
> On Tue, Oct 4, 2022 at 8:55 PM Palmer Dabbelt wrote:
> >
> > The C906 is by far the most widely available RISC-V processor, so let's
> > default to tuning for it.
> >
> > gcc/ChangeLog
> >
> > * config/riscv/riscv.h (RISCV_TUNE_STRING_DEFAULT): Change to
> > thead-c906.
> > * doc/invoke.texi (RISC-V -mtune): Change the default to
> > thead-c906.
> >
> > ---
>
> I am ok with this as --with-tune and --with-arch works as ways of
> changing the default still.
>
> Thanks,
> Andrew
>
> >
> > This has come up a handful of times, most recently during the Cauldron.
> > It seems like a grey area to me: we're changing the behavior of some
> > command-line arguments (ie, everything that doesn't specify -mtune), but
> > we sort of change that anyway as the tuning parameters change between
> > releases.
> >
> > I'm not really seeing much of a precedent from the other ports. It
> > looks like aarch64 sort of changed the default in 02fdbd5beb0
> > ("[AArch64] [-mtune cleanup 2/5] Tune for Cortex-A53 by default.") but I
> > think at that point -mtune=generic and -mtune=cortex-a53 were equivalent
> > so I'm not sure that counts. I can't quite sort out if the default x86
> > tuning has ever changed, but the tuning parameters have changed. I
> > don't see any way around having the tuning parameters change as they're
> > pretty tightly coupled to the GCC internals, but changing to a different
> > tuning target is a bit bigger of a change.
> >
> > We also have a bit of a special case here: -mtune is in theory only a
> > performance issue, but this change will emit a lot more misaligned
> > accesses and we've seen those trigger bugs in the trap handlers before.
> > Those bugs are elsewhere so it's sort of not a GCC problem, but I'm sure
> > there's still users out there with broken firmware and this may cause
> > visible fallout. We can just tell those users their systems were always
> > broken, but that's never a fun way to do things.
> >
> > I figured the easiest way to talk about this would be to just send the
> > patch, but I definitely don't plan on committing it without some
> > discussion.
> > ---
> > gcc/config/riscv/riscv.h | 2 +-
> > gcc/doc/invoke.texi | 2 +-
> > 2 files changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> > index 363113c6511..1d9379fa5ee 100644
> > --- a/gcc/config/riscv/riscv.h
> > +++ b/gcc/config/riscv/riscv.h
> > @@ -40,7 +40,7 @@ along with GCC; see the file COPYING3. If not see
> > #endif
> >
> > #ifndef RISCV_TUNE_STRING_DEFAULT
> > -#define RISCV_TUNE_STRING_DEFAULT "rocket"
> > +#define RISCV_TUNE_STRING_DEFAULT "thead-c906"
> > #endif
> >
> > extern const char *riscv_expand_arch (int argc, const char **argv);
> > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > index e0c2c57c9b2..2a9ea3455f6 100644
> > --- a/gcc/doc/invoke.texi
> > +++ b/gcc/doc/invoke.texi
> > @@ -28529,7 +28529,7 @@ particular CPU name. Permissible values for this
> > option are: @samp{rocket},
> > @samp{thead-c906}, @samp{size}, and all valid options for @option{-mcpu=}.
> >
> > When @option{-mtune=} is not specified, use the setting from
> > @option{-mcpu},
> > -the default is @samp{rocket} if both are not specified.
> > +the default is @samp{thead-c906} if both are not specified.
> >
> > The @samp{size} choice is not intended for use by end-users. This is used
> > when @option{-Os} is specified. It overrides the instruction cost info
> > --
> > 2.34.1
> >
[PATCH] c++: remove optimize_specialization_lookup_p
Roughly speaking, optimize_specialization_lookup_p returns true
for a non-template member function of a class template, e.g.
template struct A { int f(); };
The idea behind the optimization in question seems to be that if we want
to look up the specialization A::f [with T=int], then we can just do
a name lookup for f in A and avoid having to maintain a spec_entry
for it in the decl_specializations table.
However, the benefit of this optimization seems questionable because in
order to do the name lookup we need to look up A [with T=int] in the
type_specializations table, which is just as expensive as looking up an
entry in decl_specializations. And according to my experiments using
stdc++.h, range-v3 and libstdc++ tests, the compiler is slightly (<1%)
_faster_ after disabling this optimization!
Additionally, this optimization means that an explicit specialization
won't get recorded in decl_specializations for such a template, which
is a rather arbitrary invariant violation, and apparently breaks the
below modules testcase.
So since this optimization doesn't seem to give a performance benefit,
complicates the explicit specialization story, and affects modules, this
patch proposes to remove it.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Patch generated with -w to suppress noisy whitespace changes.
gcc/cp/ChangeLog:
* pt.cc (optimize_specialization_lookup_p): Remove.
(retrieve_specialization): Assume the above returns false
and simplify accordingly.
(register_specialization): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/indirect-3_b.C: Expect that the entity
foo::TPL<0>::frob has is tagged as a specialization and
not just a declaration.
* g++.dg/modules/tpl-spec-8_a.H: New test.
* g++.dg/modules/tpl-spec-8_b.C: New test.
---
gcc/cp/pt.cc| 85 +
gcc/testsuite/g++.dg/modules/indirect-3_b.C | 2 +-
gcc/testsuite/g++.dg/modules/tpl-spec-8_a.H | 9 +++
gcc/testsuite/g++.dg/modules/tpl-spec-8_b.C | 8 ++
4 files changed, 22 insertions(+), 82 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/tpl-spec-8_a.H
create mode 100644 gcc/testsuite/g++.dg/modules/tpl-spec-8_b.C
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index bce2a777922..c079bbd4268 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -1170,39 +1170,6 @@ maybe_process_partial_specialization (tree type)
return type;
}
-/* Returns nonzero if we can optimize the retrieval of specializations
- for TMPL, a TEMPLATE_DECL. In particular, for such a template, we
- do not use DECL_TEMPLATE_SPECIALIZATIONS at all. */
-
-static inline bool
-optimize_specialization_lookup_p (tree tmpl)
-{
- return (DECL_FUNCTION_TEMPLATE_P (tmpl)
- && DECL_CLASS_SCOPE_P (tmpl)
- /* DECL_CLASS_SCOPE_P holds of T::f even if T is a template
-parameter. */
- && CLASS_TYPE_P (DECL_CONTEXT (tmpl))
- /* The optimized lookup depends on the fact that the
-template arguments for the member function template apply
-purely to the containing class, which is not true if the
-containing class is an explicit or partial
-specialization. */
- && !CLASSTYPE_TEMPLATE_SPECIALIZATION (DECL_CONTEXT (tmpl))
- && !DECL_MEMBER_TEMPLATE_P (tmpl)
- && !DECL_CONV_FN_P (tmpl)
- /* It is possible to have a template that is not a member
-template and is not a member of a template class:
-
-template
-struct S { friend A::f(); };
-
-Here, the friend function is a template, but the context does
-not have template information. The optimized lookup relies
-on having ARGS be the template arguments for both the class
-and the function template. */
- && !DECL_UNIQUE_FRIEND_P (DECL_TEMPLATE_RESULT (tmpl)));
-}
-
/* Make sure ARGS doesn't use any inappropriate typedefs; we should have
gone through coerce_template_parms by now. */
@@ -1276,43 +1243,12 @@ retrieve_specialization (tree tmpl, tree args,
hashval_t hash)
if (lambda_fn_in_template_p (tmpl))
return NULL_TREE;
- if (optimize_specialization_lookup_p (tmpl))
-{
- /* The template arguments actually apply to the containing
-class. Find the class specialization with those
-arguments. */
- tree class_template = CLASSTYPE_TI_TEMPLATE (DECL_CONTEXT (tmpl));
- tree class_specialization
- = retrieve_specialization (class_template, args, 0);
- if (!class_specialization)
- return NULL_TREE;
-
- /* Find the instance of TMPL. */
- tree fns = get_class_binding (class_specialization, DECL_NAME (tmpl));
- for (ovl_iterator iter (fns); iter; ++iter)
- {
- tree fn = *iter;
- if (tree ti = get_template_info (fn))
- if (TI_TEMPLATE (ti) == tmpl
-
Re: [PATCH] RISC-V: Default to tuning for the thead-c906
I agree with Kito; I don't support merging this patch. My reasoning is twofold:
- The default settings should be fairly neutral, avoiding codegen that
severely disadvantages some targets. Misaligned memory accesses are
certainly a problematic case in that respect. (And it's highly
asymmetric: the perf upside for implementations that do support this
feature is much lower than the perf downside for implementations that
don't.) I haven't reviewed the rest of the C906 tuning decisions, but
I'd raise the same concern if any of them are similarly non-neutral.
- Both the RISC-V ISA spec and the more recent RVA22 profile spec
explicitly caution about the perf impacts of such a tuning decision.
The RVA22 profile spec goes further to explicitly state that standard
software distributions should not do what this patch does.
https://github.com/riscv/riscv-profiles/commit/b09dc934e8cb8c1dfb7ddead8bdf509408e94609#diff-01b3848d5e44a205fafe2a7b93dbf353138763b76110bb833b71ac4afe5bR593-R595
Andrew
On Wed, Oct 5, 2022 at 6:59 PM Kito Cheng via Gcc-patches
wrote:
>
> -1 for this, default enable fast unaligned access could cause many
> problems, and lots of RISC-V cores
> don't support HW unaligned access (Rocket-base RISC-V core, most
> SiFive core, and most Andes core IIRC),
> change this to default means package from RISC-V linux distro might
> contain unaligned access by default.
>
> The default one should be the safest option, in case people really
> want that, they could use --with-tune and
> --with-arch to change that.
>
>
> On Wed, Oct 5, 2022 at 1:57 PM Andrew Pinski via Gcc-patches
> wrote:
> >
> > On Tue, Oct 4, 2022 at 8:55 PM Palmer Dabbelt wrote:
> > >
> > > The C906 is by far the most widely available RISC-V processor, so let's
> > > default to tuning for it.
> > >
> > > gcc/ChangeLog
> > >
> > > * config/riscv/riscv.h (RISCV_TUNE_STRING_DEFAULT): Change to
> > > thead-c906.
> > > * doc/invoke.texi (RISC-V -mtune): Change the default to
> > > thead-c906.
> > >
> > > ---
> >
> > I am ok with this as --with-tune and --with-arch works as ways of
> > changing the default still.
> >
> > Thanks,
> > Andrew
> >
> > >
> > > This has come up a handful of times, most recently during the Cauldron.
> > > It seems like a grey area to me: we're changing the behavior of some
> > > command-line arguments (ie, everything that doesn't specify -mtune), but
> > > we sort of change that anyway as the tuning parameters change between
> > > releases.
> > >
> > > I'm not really seeing much of a precedent from the other ports. It
> > > looks like aarch64 sort of changed the default in 02fdbd5beb0
> > > ("[AArch64] [-mtune cleanup 2/5] Tune for Cortex-A53 by default.") but I
> > > think at that point -mtune=generic and -mtune=cortex-a53 were equivalent
> > > so I'm not sure that counts. I can't quite sort out if the default x86
> > > tuning has ever changed, but the tuning parameters have changed. I
> > > don't see any way around having the tuning parameters change as they're
> > > pretty tightly coupled to the GCC internals, but changing to a different
> > > tuning target is a bit bigger of a change.
> > >
> > > We also have a bit of a special case here: -mtune is in theory only a
> > > performance issue, but this change will emit a lot more misaligned
> > > accesses and we've seen those trigger bugs in the trap handlers before.
> > > Those bugs are elsewhere so it's sort of not a GCC problem, but I'm sure
> > > there's still users out there with broken firmware and this may cause
> > > visible fallout. We can just tell those users their systems were always
> > > broken, but that's never a fun way to do things.
> > >
> > > I figured the easiest way to talk about this would be to just send the
> > > patch, but I definitely don't plan on committing it without some
> > > discussion.
> > > ---
> > > gcc/config/riscv/riscv.h | 2 +-
> > > gcc/doc/invoke.texi | 2 +-
> > > 2 files changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/gcc/config/riscv/riscv.h b/gcc/config/riscv/riscv.h
> > > index 363113c6511..1d9379fa5ee 100644
> > > --- a/gcc/config/riscv/riscv.h
> > > +++ b/gcc/config/riscv/riscv.h
> > > @@ -40,7 +40,7 @@ along with GCC; see the file COPYING3. If not see
> > > #endif
> > >
> > > #ifndef RISCV_TUNE_STRING_DEFAULT
> > > -#define RISCV_TUNE_STRING_DEFAULT "rocket"
> > > +#define RISCV_TUNE_STRING_DEFAULT "thead-c906"
> > > #endif
> > >
> > > extern const char *riscv_expand_arch (int argc, const char **argv);
> > > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> > > index e0c2c57c9b2..2a9ea3455f6 100644
> > > --- a/gcc/doc/invoke.texi
> > > +++ b/gcc/doc/invoke.texi
> > > @@ -28529,7 +28529,7 @@ particular CPU name. Permissible values for this
> > > option are: @samp{rocket},
> > > @samp{thead-c906}, @samp{size}, and all valid options for
> > > @option{-mcpu=}.
> > >
> > > When @option{-mtune=} is not specified, use the setting from
> > >
Re: [PATCH] cselib: Skip BImode while keeping track of subvalue relations [PR107088]
On 10/4/22 05:28, Stefan Schulze Frielinghaus via Gcc-patches wrote: For BImode get_narrowest_mode evaluates to QImode but BImode < QImode. Thus FOR_EACH_MODE_UNTIL never reaches BImode and iterates until OImode for which no wider mode exists so we end up with VOIDmode and fail. Fixed by adding a size guard so we effectively skip BImode. Bootstrap and regtest are currently running on x64. Assuming they pass ok for mainline? gcc/ChangeLog: PR rtl-optimization/107088 * cselib.cc (new_cselib_val): Skip BImode while keeping track of subvalue relations. OK. And FWIW, this fixes the various failures I saw in my tester due to the cselib patches. jeff
Re: [PATCH] c++: remove optimize_specialization_lookup_p
On 10/5/22 22:02, Patrick Palka wrote:
Roughly speaking, optimize_specialization_lookup_p returns true
for a non-template member function of a class template, e.g.
template struct A { int f(); };
The idea behind the optimization in question seems to be that if we want
to look up the specialization A::f [with T=int], then we can just do
a name lookup for f in A and avoid having to maintain a spec_entry
for it in the decl_specializations table.
However, the benefit of this optimization seems questionable because in
order to do the name lookup we need to look up A [with T=int] in the
type_specializations table, which is just as expensive as looking up an
entry in decl_specializations. And according to my experiments using
stdc++.h, range-v3 and libstdc++ tests, the compiler is slightly (<1%)
_faster_ after disabling this optimization!
Yeah, probably should have done this when we switched to hash tables.
Additionally, this optimization means that an explicit specialization
won't get recorded in decl_specializations for such a template, which
is a rather arbitrary invariant violation, and apparently breaks the
below modules testcase.
So since this optimization doesn't seem to give a performance benefit,
complicates the explicit specialization story, and affects modules, this
patch proposes to remove it.
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk? Patch generated with -w to suppress noisy whitespace changes.
OK.
gcc/cp/ChangeLog:
* pt.cc (optimize_specialization_lookup_p): Remove.
(retrieve_specialization): Assume the above returns false
and simplify accordingly.
(register_specialization): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/modules/indirect-3_b.C: Expect that the entity
foo::TPL<0>::frob has is tagged as a specialization and
not just a declaration.
* g++.dg/modules/tpl-spec-8_a.H: New test.
* g++.dg/modules/tpl-spec-8_b.C: New test.
---
gcc/cp/pt.cc| 85 +
gcc/testsuite/g++.dg/modules/indirect-3_b.C | 2 +-
gcc/testsuite/g++.dg/modules/tpl-spec-8_a.H | 9 +++
gcc/testsuite/g++.dg/modules/tpl-spec-8_b.C | 8 ++
4 files changed, 22 insertions(+), 82 deletions(-)
create mode 100644 gcc/testsuite/g++.dg/modules/tpl-spec-8_a.H
create mode 100644 gcc/testsuite/g++.dg/modules/tpl-spec-8_b.C
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index bce2a777922..c079bbd4268 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -1170,39 +1170,6 @@ maybe_process_partial_specialization (tree type)
return type;
}
-/* Returns nonzero if we can optimize the retrieval of specializations
- for TMPL, a TEMPLATE_DECL. In particular, for such a template, we
- do not use DECL_TEMPLATE_SPECIALIZATIONS at all. */
-
-static inline bool
-optimize_specialization_lookup_p (tree tmpl)
-{
- return (DECL_FUNCTION_TEMPLATE_P (tmpl)
- && DECL_CLASS_SCOPE_P (tmpl)
- /* DECL_CLASS_SCOPE_P holds of T::f even if T is a template
-parameter. */
- && CLASS_TYPE_P (DECL_CONTEXT (tmpl))
- /* The optimized lookup depends on the fact that the
-template arguments for the member function template apply
-purely to the containing class, which is not true if the
-containing class is an explicit or partial
-specialization. */
- && !CLASSTYPE_TEMPLATE_SPECIALIZATION (DECL_CONTEXT (tmpl))
- && !DECL_MEMBER_TEMPLATE_P (tmpl)
- && !DECL_CONV_FN_P (tmpl)
- /* It is possible to have a template that is not a member
-template and is not a member of a template class:
-
-template
-struct S { friend A::f(); };
-
-Here, the friend function is a template, but the context does
-not have template information. The optimized lookup relies
-on having ARGS be the template arguments for both the class
-and the function template. */
- && !DECL_UNIQUE_FRIEND_P (DECL_TEMPLATE_RESULT (tmpl)));
-}
-
/* Make sure ARGS doesn't use any inappropriate typedefs; we should have
gone through coerce_template_parms by now. */
@@ -1276,43 +1243,12 @@ retrieve_specialization (tree tmpl, tree args, hashval_t hash)
if (lambda_fn_in_template_p (tmpl))
return NULL_TREE;
- if (optimize_specialization_lookup_p (tmpl))
-{
- /* The template arguments actually apply to the containing
-class. Find the class specialization with those
-arguments. */
- tree class_template = CLASSTYPE_TI_TEMPLATE (DECL_CONTEXT (tmpl));
- tree class_specialization
- = retrieve_specialization (class_template, args, 0);
- if (!class_specialization)
- return NULL_TREE;
-
- /* Find the instance of TMPL. */
- tree fns = get_class_binding (class_specialization, DECL_NAME (tmpl));
- for (ovl_iterator iter (fns); iter; ++
[COMMITTED] Do not double print INF and NAN in frange pretty printer.
gcc/ChangeLog:
* value-range-pretty-print.cc (vrange_printer::print_real_value):
Avoid printing INF and NAN twice.
---
gcc/value-range-pretty-print.cc | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/gcc/value-range-pretty-print.cc b/gcc/value-range-pretty-print.cc
index 8cbe97b76fd..3a3b4b44cbd 100644
--- a/gcc/value-range-pretty-print.cc
+++ b/gcc/value-range-pretty-print.cc
@@ -123,7 +123,11 @@ vrange_printer::print_real_value (tree type, const
REAL_VALUE_TYPE &r) const
char s[100];
real_to_decimal_for_mode (s, &r, sizeof (s), 0, 1, TYPE_MODE (type));
pp_string (pp, s);
- if (!DECIMAL_FLOAT_TYPE_P (type))
+ if (!DECIMAL_FLOAT_TYPE_P (type)
+ // real_to_hexadecimal prints infinities and NAN as text. No
+ // need to print them twice.
+ && !real_isinf (&r)
+ && !real_isnan (&r))
{
real_to_hexadecimal (s, &r, sizeof (s), 0, 1);
pp_printf (pp, " (%s)", s);
--
2.37.1
[COMMITTED] Setting explicit NANs sets UNDEFINED for -ffinite-math-only.
We recently agreed that setting a range of NAN should instead set
UNDEFINED for -ffinite-math-only. This patch makes that change to
frange::set_nan() directly. Also, calling frange::update_nan() will now
be a nop for !HONOR_NANS.
Doing this in the setters simplifies everywhere we set NANs, as it keeps
us from introducing NANs by mistake.
gcc/ChangeLog:
* value-range.cc (frange::set): Call set_nan unconditionally.
(range_tests_nan): Adjust tests.
(range_tests_signed_zeros): Same.
(range_tests_floats): Same.
* value-range.h (frange::update_nan): Guard with HONOR_NANS.
(frange::set_nan): Set undefined if !HONOR_NANS.
---
gcc/value-range.cc | 59 ++---
gcc/value-range.h | 60 +-
2 files changed, 67 insertions(+), 52 deletions(-)
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index a307559b654..87239fafa77 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -304,13 +304,8 @@ frange::set (tree type,
if (real_isnan (&min) || real_isnan (&max))
{
gcc_checking_assert (real_identical (&min, &max));
- if (HONOR_NANS (type))
- {
- bool sign = real_isneg (&min);
- set_nan (type, sign);
- }
- else
- set_undefined ();
+ bool sign = real_isneg (&min);
+ set_nan (type, sign);
return;
}
@@ -3624,6 +3619,7 @@ range_tests_nan ()
{
frange r0, r1;
REAL_VALUE_TYPE q, r;
+ bool signbit;
// Equal ranges but with differing NAN bits are not equal.
if (HONOR_NANS (float_type_node))
@@ -3735,6 +3731,26 @@ range_tests_nan ()
r0.set_nan (float_type_node);
r0.clear_nan ();
ASSERT_TRUE (r0.undefined_p ());
+
+ // [10,20] NAN ^ [21,25] NAN = [NAN]
+ r0 = frange_float ("10", "20");
+ r0.update_nan ();
+ r1 = frange_float ("21", "25");
+ r1.update_nan ();
+ r0.intersect (r1);
+ ASSERT_TRUE (r0.known_isnan ());
+
+ // NAN U [5,6] should be [5,6] +-NAN.
+ r0.set_nan (float_type_node);
+ r1 = frange_float ("5", "6");
+ r1.clear_nan ();
+ r0.union_ (r1);
+ real_from_string (&q, "5");
+ real_from_string (&r, "6");
+ ASSERT_TRUE (real_identical (&q, &r0.lower_bound ()));
+ ASSERT_TRUE (real_identical (&r, &r0.upper_bound ()));
+ ASSERT_TRUE (!r0.signbit_p (signbit));
+ ASSERT_TRUE (r0.maybe_isnan ());
}
static void
@@ -3742,7 +3758,6 @@ range_tests_signed_zeros ()
{
tree zero = build_zero_cst (float_type_node);
tree neg_zero = fold_build1 (NEGATE_EXPR, float_type_node, zero);
- REAL_VALUE_TYPE q, r;
frange r0, r1;
bool signbit;
@@ -3788,18 +3803,6 @@ range_tests_signed_zeros ()
r0.intersect (r1);
ASSERT_TRUE (r0.zero_p ());
- // NAN U [5,6] should be [5,6] NAN.
- r0.set_nan (float_type_node);
- r1 = frange_float ("5", "6");
- r1.clear_nan ();
- r0.union_ (r1);
- real_from_string (&q, "5");
- real_from_string (&r, "6");
- ASSERT_TRUE (real_identical (&q, &r0.lower_bound ()));
- ASSERT_TRUE (real_identical (&r, &r0.upper_bound ()));
- ASSERT_TRUE (!r0.signbit_p (signbit));
- ASSERT_TRUE (r0.maybe_isnan ());
-
r0 = frange_float ("+0", "5");
r0.clear_nan ();
ASSERT_TRUE (r0.signbit_p (signbit) && !signbit);
@@ -3823,7 +3826,10 @@ range_tests_signed_zeros ()
r1 = frange_float ("0", "0");
r1.update_nan ();
r0.intersect (r1);
- ASSERT_TRUE (r0.known_isnan ());
+ if (HONOR_NANS (float_type_node))
+ASSERT_TRUE (r0.known_isnan ());
+ else
+ASSERT_TRUE (r0.undefined_p ());
r0.set_nonnegative (float_type_node);
ASSERT_TRUE (r0.signbit_p (signbit) && !signbit);
@@ -3863,7 +3869,8 @@ range_tests_floats ()
{
frange r0, r1;
- range_tests_nan ();
+ if (HONOR_NANS (float_type_node))
+range_tests_nan ();
range_tests_signbit ();
if (HONOR_SIGNED_ZEROS (float_type_node))
@@ -3936,14 +3943,6 @@ range_tests_floats ()
r0.intersect (r1);
ASSERT_EQ (r0, frange_float ("15", "20"));
- // [10,20] NAN ^ [21,25] NAN = [NAN]
- r0 = frange_float ("10", "20");
- r0.update_nan ();
- r1 = frange_float ("21", "25");
- r1.update_nan ();
- r0.intersect (r1);
- ASSERT_TRUE (r0.known_isnan ());
-
// [10,20] ^ [21,25] = []
r0 = frange_float ("10", "20");
r0.clear_nan ();
diff --git a/gcc/value-range.h b/gcc/value-range.h
index d1663620444..b06ca7477cd 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -,11 +,14 @@ inline void
frange::update_nan ()
{
gcc_checking_assert (!undefined_p ());
- m_pos_nan = true;
- m_neg_nan = true;
- normalize_kind ();
- if (flag_checking)
-verify_range ();
+ if (HONOR_NANS (m_type))
+{
+ m_pos_nan = true;
+ m_neg_nan = true;
+ normalize_kind ();
+ if (flag_checking)
+ verify_range ();
+}
}
// Like above, but set the sign of the NAN.
@@ -1124,11 +1127,14 @@ inline void
frange::update_nan (bool sign)
{
gcc_checking_assert (!undefined_p ());
- m_pos_nan = !sign;
- m_neg_nan = sign;
- normalize_ki
[COMMITTED] Do not check finite_operands_p twice in range-ops-float.
The uses of finite_operands_p removed are guarded by a call to
finite_operands_p already.
gcc/ChangeLog:
* range-op-float.cc (foperator_lt::fold_range): Remove extra check
to finite_operands_p.
(foperator_le::fold_range): Same.
(foperator_gt::fold_range): Same.
(foperator_ge::fold_range): Same.
---
gcc/range-op-float.cc | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 6e9d51d3b4b..68578aa6fe7 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -572,8 +572,7 @@ foperator_lt::fold_range (irange &r, tree type,
{
if (real_less (&op1.upper_bound (), &op2.lower_bound ()))
r = range_true (type);
- else if (finite_operands_p (op1, op2)
- && !real_less (&op1.lower_bound (), &op2.upper_bound ()))
+ else if (!real_less (&op1.lower_bound (), &op2.upper_bound ()))
r = range_false (type);
else
r = range_true_and_false (type);
@@ -688,8 +687,7 @@ foperator_le::fold_range (irange &r, tree type,
{
if (real_compare (LE_EXPR, &op1.upper_bound (), &op2.lower_bound ()))
r = range_true (type);
- else if (finite_operands_p (op1, op2)
- && !real_compare (LE_EXPR, &op1.lower_bound (), &op2.upper_bound
()))
+ else if (!real_compare (LE_EXPR, &op1.lower_bound (), &op2.upper_bound
()))
r = range_false (type);
else
r = range_true_and_false (type);
@@ -796,8 +794,7 @@ foperator_gt::fold_range (irange &r, tree type,
{
if (real_compare (GT_EXPR, &op1.lower_bound (), &op2.upper_bound ()))
r = range_true (type);
- else if (finite_operands_p (op1, op2)
- && !real_compare (GT_EXPR, &op1.upper_bound (), &op2.lower_bound
()))
+ else if (!real_compare (GT_EXPR, &op1.upper_bound (), &op2.lower_bound
()))
r = range_false (type);
else
r = range_true_and_false (type);
@@ -912,8 +909,7 @@ foperator_ge::fold_range (irange &r, tree type,
{
if (real_compare (GE_EXPR, &op1.lower_bound (), &op2.upper_bound ()))
r = range_true (type);
- else if (finite_operands_p (op1, op2)
- && !real_compare (GE_EXPR, &op1.upper_bound (), &op2.lower_bound
()))
+ else if (!real_compare (GE_EXPR, &op1.upper_bound (), &op2.lower_bound
()))
r = range_false (type);
else
r = range_true_and_false (type);
--
2.37.1
