Re: gcc/DATESTAMP not updated any longer
On 12/15/20 12:58 AM, Joseph Myers wrote: Maybe change the script to use /sourceware/snapshot-tmp/gcc (which has rather more space) instead of /tmp? Jakub can you please do it? Thanks, Martin
Results for 10.2.0 (GCC) testsuite on powerpc-ibm-aix6.1.9.0
g++-10 -v Using built-in specs. COLLECT_GCC=/opt/freeware/gcc-10.2.0/bin/g++-10 COLLECT_LTO_WRAPPER=/opt/freeware/gcc-10.2.0/libexec/gcc/powerpc-ibm-aix6.1. 9.0/10/lto-wrapper Target: powerpc-ibm-aix6.1.9.0 Configured with: ../configure --prefix=/opt/freeware/gcc-10.2.0 --with-as=/usr/bin/as --with-local-prefix=/opt/freeware/gcc-10.2.0 --with-ld=/usr/bin/ld --enable-languages=c,c++,go --enable-version-specific-runtime-libs --disable-nls --with-cloog=no --with-ppl=no --disable-libstdcxx-pch --enable-__cxa_atexit --disable-werror --with-gcc-major-version-only --program-suffix=-10 --disable-rpath --with-static-standard-libraries --enable-static --enable-threads=aix --enable-libstdcxx-threads : (reconfigured) ../configure --prefix=/opt/freeware/gcc-10.2.0 --with-as=/usr/bin/as --with-local-prefix=/opt/freeware/gcc-10.2.0 --with-ld=/usr/bin/ld --enable-languages=c,c++ --enable-version-specific-runtime-libs --disable-nls --with-cloog=no --with-ppl=no --disable-libstdcxx-pch --enable-__cxa_atexit --disable-werror --with-gcc-major-version-only --program-suffix=-10 --disable-rpath --with-static-standard-libraries --enable-static --enable-threads=aix --enable-libstdcxx-threads Thread model: aix Supported LTO compression algorithms: zlib gcc version 10.2.0 (GCC) Native configuration is powerpc-ibm-aix6.1.9.0 === g++ tests === Running target unix FAIL: g++.dg/compat/eh/new1 cp_compat_x_tst.o-cp_compat_y_tst.o execute XPASS: g++.dg/debug/pr56294.C -gxcoff (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff+ (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff+1 (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff+3 (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff1 (test for excess errors) XPASS: g++.dg/debug/pr56294.C -gxcoff3 (test for excess errors) XPASS: g++.dg/debug/pr56819.C -gxcoff (test for excess errors) XPASS: g++.dg/debug/pr56819.C -gxcoff+ (test for excess errors) XPASS: g++.dg/debug/pr56819.C -gxcoff+1 (test for excess errors) XPASS: g++.dg/debug/pr56819.C -gxcoff+3 (test for excess errors) XPASS: g++.dg/debug/pr56819.C -gxcoff1 (test for excess errors) XPASS: g++.dg/debug/pr56819.C -gxcoff3 (test for excess errors) FAIL: c-c++-common/builtin-has-attribute-4.c -std=gnu++14 (test for excess errors) FAIL: c-c++-common/builtin-has-attribute-4.c -std=gnu++17 (test for excess errors) FAIL: c-c++-common/builtin-has-attribute-4.c -std=gnu++2a (test for excess errors) FAIL: c-c++-common/builtin-has-attribute-4.c -std=gnu++98 (test for excess errors) XPASS: c-c++-common/ident-0b.c -std=gnu++14 scan-assembler-not GCC: XPASS: c-c++-common/ident-0b.c -std=gnu++17 scan-assembler-not GCC: XPASS: c-c++-common/ident-0b.c -std=gnu++2a scan-assembler-not GCC: XPASS: c-c++-common/ident-0b.c -std=gnu++98 scan-assembler-not GCC: FAIL: g++.dg/cpp2a/lambda-uneval5.C -std=c++2a scan-assembler-not globl.*_Z1f XPASS: g++.dg/eh/new1.C -std=c++98 execution test FAIL: g++.dg/ipa/pr83667.C -std=gnu++14 scan-ipa-dump inline "summary for void c::[^n]*THUNK0" FAIL: g++.dg/ipa/pr83667.C -std=gnu++17 scan-ipa-dump inline "summary for void c::[^n]*THUNK0" FAIL: g++.dg/ipa/pr83667.C -std=gnu++2a scan-ipa-dump inline "summary for void c::[^n]*THUNK0" FAIL: g++.dg/ipa/pr83667.C -std=gnu++98 scan-ipa-dump inline "summary for void c::[^n]*THUNK0" XPASS: g++.dg/opt/flifetime-dse2.C -std=gnu++14 execution test XPASS: g++.dg/opt/flifetime-dse2.C -std=gnu++17 execution test XPASS: g++.dg/opt/flifetime-dse2.C -std=gnu++2a execution test XPASS: g++.dg/opt/flifetime-dse2.C -std=gnu++98 execution test XPASS: g++.dg/opt/flifetime-dse4.C -std=gnu++14 execution test XPASS: g++.dg/opt/flifetime-dse4.C -std=gnu++17 execution test XPASS: g++.dg/opt/flifetime-dse4.C -std=gnu++2a execution test XPASS: g++.dg/opt/flifetime-dse4.C -std=gnu++98 execution test FAIL: g++.dg/other/anon5.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/other/anon5.C -std=gnu++14 undefined (test for warnings, line ) FAIL: g++.dg/other/anon5.C -std=gnu++17 (test for excess errors) FAIL: g++.dg/other/anon5.C -std=gnu++17 undefined (test for warnings, line ) FAIL: g++.dg/other/anon5.C -std=gnu++2a (test for excess errors) FAIL: g++.dg/other/anon5.C -std=gnu++2a undefined (test for warnings, line ) FAIL: g++.dg/other/anon5.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/other/anon5.C -std=gnu++98 undefined (test for warnings, line ) FAIL: g++.dg/pr78112-2.C (test for excess errors) UNRESOLVED: g++.dg/pr78112-2.C scan-assembler-times DW_AT_object_pointer 12 FAIL: g++.dg/pr84279.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/pr84279.C -std=gnu++17 (test for excess errors) FAIL: g++.dg/pr84279.C -std=gnu++2a (test for excess errors) FAIL: g++.dg/pr84279.C -std=gnu++98 (test for excess errors) FAIL: g++.dg/pr90981.C -std=gnu++14 (test for excess errors) FAIL: g++.dg/pr90981.C -std=gnu++17
why aarch64 doesn't support V4QI.
Hi, I have some problems in gcc development about aarch64. I saw it doesn't support V4QI machine mode in aarch64-modes.def, but it has V4QI in arm-modes.def. I want to know why it doesn't? I am looking forward your replies. Thanks for your help. Best regards, yancheng
Question about 'gcc/fold-const.c:fold_convert_loc' for 'real_cst' -> 'reference_type' of 'real_type'
Hi!
In a development branch based on devel/omp/gcc-10 branch (og10), which is
based on releases/gcc-10 branch, I'm running into the following issue.
But: the master branch code seems to look the same.
Given a specific scenario, we run into an ICE:
during GIMPLE pass: oaccdevlow
dump file: o.163t.oaccdevlow1
int_ion_mix_acc.f: In function ‘vtot_ion_mix_._omp_fn.0’:
int_ion_mix_acc.f:50: internal compiler error: in fold_convert_loc, at
fold-const.c:2436
50 | !$acc loop reduction(+:eva) independent
|
#0 internal_error (gmsgid=gmsgid@entry=0x17b6308 "in %s, at %s:%d") at
[...]/source-gcc/gcc/diagnostic.c:1706
#1 0x005f5c0b in fancy_abort (file=,
line=, function=) at
[...]/source-gcc/gcc/diagnostic.c:1778
#2 0x0080d65e in fold_convert_loc (loc=0, type=0x76841bd0,
arg=0x7685ede0) at [...]/source-gcc/gcc/fold-const.c:2435
#3 0x008cc8c5 in gimplify_modify_expr
(expr_p=expr_p@entry=0x7fffcc48, pre_p=pre_p@entry=0x7fffccb8,
post_p=post_p@entry=0x7fffca58, want_value=want_value@entry=false) at
[...]/source-gcc/gcc/gimplify.c:5741
#4 0x008f7c36 in gimplify_expr
(expr_p=expr_p@entry=0x7fffcc48, pre_p=pre_p@entry=0x7fffccb8,
post_p=0x7fffca58, post_p@entry=0x0,
gimple_test_f=gimple_test_f@entry=0x8cc0db ,
fallback=fallback@entry=0) at [...]/source-gcc/gcc/gimplify.c:13921
#5 0x008d1287 in gimplify_stmt
(stmt_p=stmt_p@entry=0x7fffcc48, seq_p=seq_p@entry=0x7fffccb8) at
[...]/source-gcc/gcc/gimplify.c:6849
#6 0x008baf79 in gimplify_and_add (t=t@entry=0x768dda78,
seq_p=seq_p@entry=0x7fffccb8) at [...]/source-gcc/gcc/gimplify.c:510
#7 0x008fdbb6 in gimplify_assign (dst=0x768b0048,
src=0x7685ede0, seq_p=0x7fffccb8) at
[...]/source-gcc/gcc/gimplify.c:15533
#8 0x00fc31c1 in nvptx_goacc_reduction_setup
(call=call@entry=0x76880d10, oa=oa@entry=0x7fffcd40) at
[...]/source-gcc/gcc/config/nvptx/nvptx.c:5791
#9 0x00fc3d4c in nvptx_goacc_reduction (call=0x76880d10) at
[...]/source-gcc/gcc/config/nvptx/nvptx.c:6002
#10 0x00a7c091 in execute_oacc_device_lower () at
[...]/source-gcc/gcc/omp-offload.c:2579
#11 0x00a7c9a0 in (anonymous
namespace)::pass_oacc_device_lower::execute (this=0x1c3ffb0) at
[...]/source-gcc/gcc/omp-offload.c:2862
[...]
(gdb) frame 2
#2 0x0080d65e in fold_convert_loc (loc=0, type=0x76841bd0,
arg=0x7685ede0) at [...]/source-gcc/gcc/fold-const.c:2435
2435 gcc_assert (TREE_CODE (orig) == VECTOR_TYPE
(gdb) print arg
$1 = (tree) 0x7685ede0
(gdb) call debug_tree(arg)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 7 canonical-type
0x767b3348 precision:64
pointer_to_this reference_to_this
>
constant 0.0>
(gdb) print type
$2 = (tree) 0x76841bd0
(gdb) call debug_tree(type)
unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 7 canonical-type
0x767b3348 precision:64
pointer_to_this reference_to_this
>
public unsigned DI size unit-size
align:64 warn_if_not_align:0 symtab:0 alias-set 6 structural-equality
pointer_to_this >
Per the 'fold_convert_loc' code (cited below), we see that for 'type' of
'case INTEGER_TYPE' etc. -- which 'type' of 'case REFERENCE_TYPE' does
"fall through" into -- we do not handle 'arg' of 'REAL_CST' like we do
for 'type' of 'case REAL_TYPE'.
Now, as this code has been like that "forever", I have difficulties to
imagine that this may be a bug. Is this wrong usage of
'fold_convert_loc'? (What does it mean to convert a 'real_cst' into a
'reference_type' of 'real_type'?) (... translating to: something is
going wrong elsewhere, in OpenACC 'reductions' handling?)
'gcc/fold-const.c':
2392 /* Convert expression ARG to type TYPE. Used by the middle-end for
2393simple conversions in preference to calling the front-end's
convert. */
2394
2395 tree
2396 fold_convert_loc (location_t loc, tree type, tree arg)
2397 {
2398 tree orig = TREE_TYPE (arg);
2399 tree tem;
2400
2401 if (type == orig)
2402 return arg;
2403
2404 if (TREE_CODE (arg) == ERROR_MARK
2405 || TREE_CODE (type) == ERROR_MARK
2406 || TREE_CODE (orig) == ERROR_MARK)
2407 return error_mark_node;
2408
2409 switch (TREE_CODE (type))
2410 {
2411 case POINTER_TYPE:
2412 case REFERENCE_TYPE:
2413 /* Handle conversions between pointers to different address
spaces. */
2414 if (POINTER_TYPE_P (orig)
2415 && (TYPE_ADDR_SPACE (TREE_TYPE (type))
2416 != TYPE_ADDR_SPACE (TREE_TYPE (orig
2417 return fold_build1_loc (loc, ADDR_SPACE_CONVERT_EXPR, type,
arg);
2418
Re: Question about 'gcc/fold-const.c:fold_convert_loc' for 'real_cst' -> 'reference_type' of 'real_type'
On Tue, Dec 15, 2020 at 05:02:24PM +0100, Thomas Schwinge wrote: > Per the 'fold_convert_loc' code (cited below), we see that for 'type' of > 'case INTEGER_TYPE' etc. -- which 'type' of 'case REFERENCE_TYPE' does > "fall through" into -- we do not handle 'arg' of 'REAL_CST' like we do > for 'type' of 'case REAL_TYPE'. > > Now, as this code has been like that "forever", I have difficulties to > imagine that this may be a bug. Is this wrong usage of > 'fold_convert_loc'? (What does it mean to convert a 'real_cst' into a > 'reference_type' of 'real_type'?) (... translating to: something is > going wrong elsewhere, in OpenACC 'reductions' handling?) This is definitely not a bug in fold_convert, but in whatever is calling it, converting something floating to a REFERENCE_TYPE doesn't make any sense. One usually wants to convert some pointer to reference or another reference to reference; and as one can't take address of real_cst, one probably somewhere should have forced the constant into a variable so that its address could be converted to the reference. Jakub
CC0 removal branch
Hi! I have updated my CC0 removal branch I started in 2019: refs/users/segher/heads/cc0 (yes I know this needs some patch series work; this branch rebases). I have tested it all on powerpc*, and sill test it with cross-compilers to all Linux targets later today. I already know one problem that will run into: the h8300 port still uses cc0! In peepholes, and also in h8300.c (cc0_rtx). All that is dead code I bet, but that still doesn't compile if CC0 is removed ;-) Another issue is md.texi: some of the examples are about patterns that no longer exist. Which isn't that bad, but some use CC0, so that is confusing, and also less useful than possible, because things like conditional branches are quite different in the MODE_CC world. Any suggestions what to replace those with is welcome https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/doc/md.texi;h=ec6ec180b91fcf9f481b6754c044483787fd923c;hb=HEAD#l212 https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/doc/md.texi;h=ec6ec180b91fcf9f481b6754c044483787fd923c;hb=HEAD#l11210 Any further testing of the branch is appreciated as well. Other than the aforementioned problems this is all ready for submission as soon as GCC 12 stage 1 opens. Segher p.s. The diffstat: gcc/caller-save.c| 13 +- gcc/cfgcleanup.c | 36 + gcc/cfgrtl.c | 33 +--- gcc/combine.c| 264 --- gcc/compare-elim.c | 4 +- gcc/conditions.h | 49 -- gcc/config/sparc/sparc.c | 1 - gcc/cprop.c | 21 +-- gcc/cse.c| 140 ++--- gcc/cselib.c | 2 - gcc/df-problems.c| 6 +- gcc/df-scan.c| 2 - gcc/doc/md.texi | 18 +-- gcc/doc/rtl.texi | 152 +++--- gcc/doc/tm.texi | 90 +-- gcc/doc/tm.texi.in | 88 +-- gcc/emit-rtl.c | 56 +-- gcc/final.c | 399 +-- gcc/fwprop.c | 2 +- gcc/gcse-common.c| 1 - gcc/gcse.c | 25 +-- gcc/genattrtab.c | 1 - gcc/genconfig.c | 19 --- gcc/genemit.c| 3 - gcc/genextract.c | 1 - gcc/gengenrtl.c | 1 - gcc/genrecog.c | 6 +- gcc/haifa-sched.c| 4 - gcc/ifcvt.c | 1 - gcc/ira-costs.c | 1 - gcc/ira.c| 15 +- gcc/jump.c | 53 +-- gcc/loop-invariant.c | 9 -- gcc/lra-constraints.c| 10 +- gcc/lra-eliminations.c | 1 - gcc/optabs.c | 7 - gcc/postreload-gcse.c| 1 - gcc/postreload.c | 4 - gcc/print-rtl.c | 1 - gcc/read-rtl-function.c | 1 - gcc/reg-notes.def| 10 -- gcc/reg-stack.c | 11 +- gcc/reginfo.c| 1 - gcc/regrename.c | 1 - gcc/reload.c | 48 +- gcc/reload1.c| 5 +- gcc/reorg.c | 146 ++--- gcc/resource.c | 17 +- gcc/rtl.c| 4 +- gcc/rtl.def | 9 +- gcc/rtl.h| 5 - gcc/rtlanal.c| 48 +- gcc/sched-deps.c | 15 -- gcc/sched-rgn.c | 6 +- gcc/shrink-wrap.c| 3 - gcc/simplify-rtx.c | 20 +-- gcc/system.h | 3 +- gcc/target.def | 2 +- gcc/valtrack.c | 3 +- gcc/var-tracking.c | 2 - 60 files changed, 154 insertions(+), 1746 deletions(-)
Re: CC0 removal branch
On 12/15/20 10:27 AM, Segher Boessenkool wrote: > Hi! > > I have updated my CC0 removal branch I started in 2019: > refs/users/segher/heads/cc0 > (yes I know this needs some patch series work; this branch rebases). > > I have tested it all on powerpc*, and sill test it with cross-compilers > to all Linux targets later today. I already know one problem that will > run into: the h8300 port still uses cc0! In peepholes, and also in > h8300.c (cc0_rtx). All that is dead code I bet, but that still doesn't > compile if CC0 is removed ;-) It's dead code. The peepholes a shouldn't be included by the main .md file. I've got a partial conversion of those here. Still lots of cleanup and improvements queued up. Don't let anything H8 related get in the way :-) If it breaks, I'll take care of it. jeff
