[Bug modula2/115804] ICE during gimplification with new isfinite optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115804 --- Comment #5 from Stefan Schulze Frielinghaus --- I did a quick test and with diff --git a/gcc/m2/gm2-gcc/m2builtins.cc b/gcc/m2/gm2-gcc/m2builtins.cc index cfb4751e15a..4263a4e297f 100644 --- a/gcc/m2/gm2-gcc/m2builtins.cc +++ b/gcc/m2/gm2-gcc/m2builtins.cc @@ -1031,7 +1031,8 @@ DoBuiltinIsfinite (location_t location, tree value) tree functype = TREE_TYPE (gm2_isfinite_node); tree funcptr = build1 (ADDR_EXPR, build_pointer_type (functype), gm2_isfinite_node); - tree call = m2treelib_DoCall1 (location, ptr_type_node, funcptr, value); + tree rettype = TREE_TYPE (functype); + tree call = m2treelib_DoCall1 (location, rettype, funcptr, value); return call; } it seems to work just fine. Skimming over the code other builtins as e.g. DoBuiltinIsnan need to be changed, too.
[Bug target/115816] New: ICE: in emit_move_insn, at expr.cc:4611 with target("sse4.1,arch=core2") attribute and -mavx512f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115816
Bug ID: 115816
Summary: ICE: in emit_move_insn, at expr.cc:4611 with
target("sse4.1,arch=core2") attribute and -mavx512f
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: iamanonymous.cs at gmail dot com
Target Milestone: ---
***
OS and Platform:
$ uname -a:
Linux 65dac7c84719 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC
2023 x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
Using built-in specs.
COLLECT_GCC=/home/software/gcc-trunk-3aa004f/bin/gcc
COLLECT_LTO_WRAPPER=/home/software/gcc-trunk-3aa004f/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++ --prefix=/home/software/gcc-trunk-3aa004f
--enable-coverage
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20240630 (experimental) (GCC)
***
Program:
$ cat mutant.c
register __attribute__((__vector_size__(16 * sizeof(float float a,
b asm("zmm6"), c;
__attribute__((target("sse4.1,arch=core2"))) void d() {
for (int e;;)
c[e] = a[e] < b[e];
}
***
Command Lines:
$ gcc -mavx512f mutant.c
mutant.c:2:5: warning: call-clobbered register used for global register
variable
2 | b asm("zmm6"), c;
| ^
mutant.c:1:69: error: register name not specified for 'a'
1 | register __attribute__((__vector_size__(16 * sizeof(float float a,
| ^
mutant.c:2:20: error: register name not specified for 'c'
2 | b asm("zmm6"), c;
|^
during RTL pass: expand
mutant.c: In function 'd':
mutant.c:5:20: internal compiler error: in emit_move_insn, at expr.cc:4611
5 | c[e] = a[e] < b[e];
| ~^~~
0x5071bcf diagnostic_context::report_diagnostic(diagnostic_info*)
???:0
0x50724a1 diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
???:0
0x50924c7 internal_error(char const*, ...)
???:0
0x50729e4 fancy_abort(char const*, int, char const*)
???:0
0x147c27f emit_move_insn(rtx_def*, rtx_def*)
???:0
0x14b3d1b expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
???:0
0x149e86c expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
???:0
0x148b3db store_expr(tree_node*, rtx_def*, int, bool, bool)
???:0
0x14885d9 expand_assignment(tree_node*, tree_node*, bool)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug c/115817] New: [AVR] Suboptimal code for zeroing SRAM byte from ISR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115817
Bug ID: 115817
Summary: [AVR] Suboptimal code for zeroing SRAM byte from ISR
Product: gcc
Version: 14.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dimich.dmb at gmail dot com
Target Milestone: ---
There are two almost identical ISRs, the difference is only an immediate value
to be stored in SRAM.
```
static volatile unsigned char flag;
__attribute__ ((__signal__,__used__, __externally_visible__))
void __vector_set_one(void)
{
flag = 1;
}
__attribute__ ((__signal__,__used__, __externally_visible__))
void __vector_set_zero(void)
{
flag = 0;
}
```
(The real code is reduced to this MRE to avoid ISR macro from avr-libc header)
First function compiles to the following code:
000c <__vector_set_zero>:
c: 1f 92 pushr1
e: 1f b6 in r1, 0x3f; 63
10: 1f 92 pushr1
12: 11 24 eor r1, r1
14: 10 92 00 00 sts 0x, r1 ; 0x80 <__SREG__+0x7fffc1>
18: 1f 90 pop r1
1a: 1f be out 0x3f, r1; 63
1c: 1f 90 pop r1
1e: 18 95 reti
which looks overcomplicated comparing to the first one:
<__vector_set_one>:
0: 8f 93 pushr24
2: 81 e0 ldi r24, 0x01 ; 1
4: 80 93 00 00 sts 0x, r24 ; 0x80 <__SREG__+0x7fffc1>
8: 8f 91 pop r24
a: 18 95 reti
For other non-zero values the code is the same as for `__vector_set_one` except
the value itself.
The same difference is observed in final ELF binary, regardless of whether
compiled and linked with or without `-flto`.
Preprocessed file:
```
# 0 "example.c"
# 0 ""
# 0 ""
# 1 "example.c"
static volatile unsigned char flag;
__attribute__ ((__signal__,__used__, __externally_visible__))
void __vector_set_one(void)
{
flag = 1;
}
__attribute__ ((__signal__,__used__, __externally_visible__))
void __vector_set_zero(void)
{
flag = 0;
}
```
GCC version and build flags:
$ avr-gcc -v
Using built-in specs.
Reading specs from /usr/lib/gcc/avr/14.1.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/14.1.0/lto-wrapper
Target: avr
Configured with: /build/avr-gcc/src/gcc-14.1.0/configure
--disable-install-libiberty --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-linker-build-id --disable-nls
--disable-werror --disable-__cxa_atexit --enable-checking=release
--enable-clocale=gnu --enable-gnu-unique-object --enable-gold
--enable-languages=c,c++ --enable-ld=default --enable-lto --enable-plugin
--enable-shared --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-as=/usr/bin/avr-as --with-gnu-as --with-gnu-ld --with-ld=/usr/bin/avr-ld
--with-plugin-ld=ld.gold --with-system-zlib --with-isl
--enable-gnu-indirect-function
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 14.1.0 (GCC)
System: Arch Linux, x86_64 GNU/Linux
Compilation:
$ avr-gcc -Wall -pedantic -Os -mmcu=attiny13a --save-temps -c -o example.o
example.c
Expected code:
__vector_set_zero:
pushr24
ldi r24, 0x00
sts flag, r24
pop r24
reti
[Bug libstdc++/115799] ranges::find's optimized branching for memchr is not quite right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 --- Comment #5 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:762ee55d369a3257997092ef7853cf9dd4d5cc4f commit r15-1879-g762ee55d369a3257997092ef7853cf9dd4d5cc4f Author: Jonathan Wakely Date: Fri Jul 5 18:58:00 2024 +0100 libstdc++: Fix memchr path in std::ranges::find for non-common range [PR115799] The memchr optimization introduced in r15-1857 needs to advance the start iterator instead of returning the sentinel. libstdc++-v3/ChangeLog: PR libstdc++/115799 * include/bits/ranges_util.h (__find_fn): Return iterator instead of sentinel. * testsuite/25_algorithms/find/constrained.cc: Check non-common contiguous sized range of char.
[Bug libstdc++/115799] ranges::find's optimized branching for memchr is not quite right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 --- Comment #6 from GCC Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ce34fcc572a0dceebcffef76e98064546feebb38 commit r15-1880-gce34fcc572a0dceebcffef76e98064546feebb38 Author: Jonathan Wakely Date: Sat Jul 6 21:34:29 2024 +0100 libstdc++: Fix std::find for non-contiguous iterators [PR115799] The r15-1857 change didn't correctly restrict the new optimization to contiguous iterators. libstdc++-v3/ChangeLog: PR libstdc++/115799 * include/bits/stl_algo.h (find): Use 'if constexpr' so that memchr optimization is a discarded statement for non-contiguous iterators. * testsuite/25_algorithms/find/bytes.cc: Check with input iterators.
[Bug libstdc++/115807] C++23 P0943R6 does't qualify std::atomic in #define _Atomic properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115807 Jonathan Wakely changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/115799] ranges::find's optimized branching for memchr is not quite right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jonathan Wakely --- Fixed now, thanks for the reports.
[Bug target/115763] RISC-V: Use wrong SEW for vfmv.v.f when -march only has zvfhmin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115763 --- Comment #8 from Monk Chiang --- Li Pan, I tested it without any errors, I think this issue has been fixed
[Bug libstdc++/115799] ranges::find's optimized branching for memchr is not quite right
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115799 --- Comment #8 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #7) > Fixed now, thanks for the reports. Thanks for the quick fix. There may be another potential issue that I don't know if it is worth mentioning. When the difference_type of the contiguous_iterator is an integer-class type such as ranges::__detail::__max_diff_type, we may also need to perform an explicit conversion in the call of __builtin_memchr as the latter only accepts size_t.
[Bug fortran/108889] [12/13/14/15 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108889 --- Comment #7 from kargls at comcast dot net --- (In reply to Paul Thomas from comment #6) > Created attachment 58586 [details] > Fix for this PR > > This does the job but it is still a bit clunky. > > Having recently used the location field of locus to determine decl order, I > rather think that it can be similarly used to determine, when an entity has > been assigned to in the current scope. I have a backlog of regressions to > attend to first. I will come back to this one very soon. > > Paul Does this also fix PR 106089? There's a patch in comment #3 of that PR that addresses a similar issue.
[Bug c++/115810] Strange warning messages
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115810 --- Comment #11 from linuxnyasha at tutanota dot com --- If I just compile manually in docker, it works the same way.(In reply to Andrew Pinski from comment #10) > Can you provide the exact version of gcc you are using? The trunk works > correctly. g++-14 from Ubuntu 24.04 repositories
[Bug modula2/115804] ICE during gimplification with new isfinite optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115804 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-07-07 Ever confirmed|0 |1 --- Comment #6 from Andrew Pinski --- It looks like that was copied from DoBuiltinAlloca/DoBuiltinMemCopy where ptr_type_node is ok/correct. In summary the functions that need to be fixed (replacing the return type that was ptr_type_node with the return type of the function): DoBuiltinIsfinite DoBuiltinIsnan m2builtins_BuiltInHugeVal m2builtins_BuiltInHugeValShort m2builtins_BuiltInHugeValLong Confirmed.
[Bug fortran/115700] [11/12/13/14 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 --- Comment #7 from GCC Commits --- The releases/gcc-14 branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:36ca07f0a95c00cc985fc06e46df4028e6f2b77e commit r14-10387-g36ca07f0a95c00cc985fc06e46df4028e6f2b77e Author: Harald Anlauf Date: Tue Jul 2 21:26:05 2024 +0200 Fortran: fix associate with assumed-length character array [PR115700] gcc/fortran/ChangeLog: PR fortran/115700 * trans-stmt.cc (trans_associate_var): When the associate target is an array-valued character variable, the length is known at entry of the associate block. Move setting of string length of the selector to the initialization part of the block. gcc/testsuite/ChangeLog: PR fortran/115700 * gfortran.dg/associate_69.f90: New test. (cherry picked from commit 7b7f203472d07a05d959a29638c7c95d98bf0c1c)
[Bug fortran/115700] [11/12/13 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[11/12/13/14 regression]|[11/12/13 regression] Bogus |Bogus warning for associate |warning for associate with |with assumed-length |assumed-length character |character array |array --- Comment #8 from anlauf at gcc dot gnu.org --- Original issue fixed on mainline for gcc-15, and on 14-branch so far. Backporting further seems to depend on backporting at least the changes to trans-stmt.cc from r14-1629. I'd rather not do this. Leaving open to track the issues mentioned in comment#5.
[Bug modula2/115804] ICE during gimplification with new isfinite optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115804 Gaius Mulley changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #7 from Gaius Mulley --- Many thanks both for diagnosing the bug, I'll make the changes to the five functions in error.
[Bug c++/115806] [11/12/13/14/15 Regression] No error for member enum redefinition in class template (even after instantiation)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115806 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |11.5
[Bug c++/115818] New: Infinite recursive in noexcept operator is not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115818
Bug ID: 115818
Summary: Infinite recursive in noexcept operator is not
detected
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: fchelnokov at gmail dot com
Target Milestone: ---
This program
```
struct C {
void f() noexcept(noexcept(f())) {}
};
```
is rejected by both Clang and MSVC, because noexcept of f() is defined with
infinite recursion. But GCC accepts the program, which looks wrong.
Online demo: https://gcc.godbolt.org/z/abTc7sG4v
Original discussion: https://stackoverflow.com/q/74015227/7325599
[Bug c++/115818] Infinite recursion in noexcept operator is not detected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115818 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 107256 ***
[Bug c++/107256] Contradictory circular noexcept-specifier is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107256 --- Comment #2 from Andrew Pinski --- *** Bug 115818 has been marked as a duplicate of this bug. ***
[Bug c++/107256] [11/12/13/14/15 Regression] Contradictory circular noexcept-specifier is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107256 Andrew Pinski changed: What|Removed |Added Known to fail||10.1.0 Summary|Contradictory circular |[11/12/13/14/15 Regression] |noexcept-specifier is |Contradictory circular |accepted|noexcept-specifier is ||accepted Known to work||9.5.0 Target Milestone|--- |11.5
[Bug modula2/115804] ICE during gimplification with new isfinite optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115804 Gaius Mulley changed: What|Removed |Added Attachment #58596|0 |1 is obsolete|| --- Comment #8 from Gaius Mulley --- Created attachment 58604 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58604&action=edit Proposed fix Based on the previous patch and all the diagnosis above here is a proposed patch. The bootstrap test is currently underway. I'll apply the patch (if it passes). Patch summary five function calls use the correct return type and a GTY added to the static struct builtin_function_entry.
[Bug modula2/115804] ICE during gimplification with new isfinite optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115804 --- Comment #9 from GCC Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:4594d555aa551a9998fc921363c5f6ea50630d5c commit r15-1886-g4594d555aa551a9998fc921363c5f6ea50630d5c Author: Gaius Mulley Date: Sun Jul 7 22:42:51 2024 +0100 PR modula2/115804 ICE during gimplification with new isfinite optab The calls to five m2 builtins have the incorrect return type. This was detected when adding isfinitedf2 optab to the s390 backend which results in ICEs during gimplification in the gm2 testsuite. gcc/m2/ChangeLog: PR modula2/115804 * gm2-gcc/m2builtins.cc (builtin_function_entry): Add GTY. (DoBuiltinMemCopy): Add rettype and use rettype in the call. (DoBuiltinAlloca): Ditto. (DoBuiltinIsfinite): Ditto. (DoBuiltinIsnan): Ditto. (m2builtins_BuiltInHugeVal): Ditto. (m2builtins_BuiltInHugeValShort): Ditto. (m2builtins_BuiltInHugeValLong): Ditto. Co-Authored-By: Stefan Schulze Frielinghaus Co-Authored-By: Andrew Pinski Signed-off-by: Gaius Mulley
[Bug modula2/115804] ICE during gimplification with new isfinite optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115804 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Gaius Mulley --- Closing now that the patch has been applied - thanks for the report and bug diagnosis.
[Bug target/115795] RISC-V: vsetvl step causes wrong codegen after fusing info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115795 JuzheZhong changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #1 from JuzheZhong --- No. It is not vsetvl bug. For vle32.v and vse32.v which only demands ratio of SEW/LMUL, that is, all vsetvli with ratio = 4 (32/8) are all ok for them in the case you shows. right vtype: e8m2, e16m4, e32m8. Currently we default pick e8m2 instead of e16m4 and e32m8 when they are both ok for demand ratio.
[Bug rtl-optimization/115104] [15 Regression] RISC-V: GCC-14 can combine vsext+vadd -> vwadd but Trunk GCC (GCC 15) Failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115104 JuzheZhong changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from JuzheZhong --- Fixed
[Bug c/115819] New: RISC-V: Failed to hoist vrsub.vx to the header of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819
Bug ID: 115819
Summary: RISC-V: Failed to hoist vrsub.vx to the header of the
loop
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
https://godbolt.org/z/K119cG14h
void foo (int *__restrict A, int n) {
for (int i = n; i > 0; --i) {
A[i] += 1;
}
}
vsetvli a4,zero,e32,m1,ta,ma
add a5,a5,a3
vid.v v2
add a5,a0,a5
subwt3,a1,t1
li a2,0
.L4:
vl1re32.v v3,0(a5)
vrsub.vxv5,v2,a6 -> should be hoisted
addwa2,a2,t1
vrgather.vv v1,v3,v5
vadd.vi v1,v1,1
vrgather.vv v3,v1,v5
vs1r.v v3,0(a5)
[Bug target/115819] RISC-V: Failed to hoist vrsub.vx to the header of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819 Andrew Pinski changed: What|Removed |Added Keywords||missed-optimization Target||Riscv Component|c |target --- Comment #1 from Andrew Pinski --- This might be a cost issue.
[Bug tree-optimization/115819] RISC-V: Failed to hoist vrsub.vx to the header of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2024-07-07
Blocks||53947
Severity|normal |enhancement
Ever confirmed|0 |1
Target|Riscv |Riscv aarch64
Status|UNCONFIRMED |NEW
Component|target |tree-optimization
--- Comment #2 from Andrew Pinski ---
vect__4.9_41 = VEC_PERM_EXPR ;
vect__5.10_43 = vect__4.9_41 + { 1, ... };
vect__5.13_50 = VEC_PERM_EXPR ;
Well the vrgather here should not be needed in the first place.
We have:
vrgather.vv v1,v3,v5
vadd.vi v1,v1,1
vrgather.vv v3,v1,v5
For aarch64 we get:
rev z31.s, z31.s // 32 [c=4 l=4] aarch64_sve_revvnx4si
add z31.s, z31.s, #1 // 33 [c=12 l=4] addvnx4si3/0
rev z31.s, z31.s // 34 [c=4 l=4] aarch64_sve_revvnx4si
But the 2 revs are not neded, just like the 2 vrgather.vv are not needed.
For aarch64 (without SVE) we get just as bad (maybe worse) code generation:
tbl v29.16b, {v30.16b - v31.16b}, v27.16b // 36 [c=4 l=4]
aarch64_qtbl2v16qi
add v29.4s, v29.4s, v26.4s// 38 [c=8 l=4] addv4si3
mov v28.16b, v29.16b // 116 [c=4 l=4]
*aarch64_simd_movv16qi/3
tbl v25.16b, {v28.16b - v29.16b}, v27.16b // 43 [c=4 l=4]
aarch64_qtbl2v16qi
The TBL are not needed.
I thought I saw this before too ...
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug tree-optimization/115819] RISC-V: Failed to hoist vrsub.vx to the header of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Andrew Pinski --- PR 61338 . *** This bug has been marked as a duplicate of bug 61338 ***
[Bug tree-optimization/61338] too many permutation in a vectorized "reverse loop"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338 Andrew Pinski changed: What|Removed |Added CC||juzhe.zhong at rivai dot ai --- Comment #5 from Andrew Pinski --- *** Bug 115819 has been marked as a duplicate of this bug. ***
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 115819, which changed state. Bug 115819 Summary: RISC-V: Failed to hoist vrsub.vx to the header of the loop https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug tree-optimization/61338] too many permutation in a vectorized "reverse loop"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61338
--- Comment #6 from Andrew Pinski ---
Just the simple:
```
void foo (int *__restrict A, int n) {
for (int i = n; i > 0; --i) {
A[i] += 1;
}
}
```
Produces the double PERM here.
>From PR 115819 .
[Bug tree-optimization/115819] RISC-V: Failed to hoist vrsub.vx to the header of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819 --- Comment #4 from JuzheZhong --- (In reply to Andrew Pinski from comment #1) > This might be a cost issue. No. I don't it's cost issue. It's because we suppress the hoist by incorrect POLY INT handling codes. I have a patch to fix it: https://gcc.gnu.org/pipermail/gcc-patches/2024-February/644706.html But it seems to produce ICEs...
[Bug target/115763] RISC-V: Use wrong SEW for vfmv.v.f when -march only has zvfhmin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115763 --- Comment #9 from Li Pan --- (In reply to Monk Chiang from comment #8) > Li Pan, I tested it without any errors, I think this issue has been fixed Thank you! Looks this bug is still in UNCONFIRMED status, will close it once confirmed.
[Bug tree-optimization/115819] RISC-V: Failed to hoist vrsub.vx to the header of the loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819 Andrew Pinski changed: What|Removed |Added Resolution|DUPLICATE |--- Status|RESOLVED|NEW --- Comment #5 from Andrew Pinski --- Let's reopen this for the moving of the invariant out of the loop. Though this code could be improved further because of PR 61338; there might be a better testcase out there for the invariant case; though I can't find it right now.
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 115819, which changed state. Bug 115819 Summary: RISC-V: Failed to hoist vrsub.vx to the header of the loop https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115819 What|Removed |Added Status|RESOLVED|NEW Resolution|DUPLICATE |---
[Bug target/115688] [15 regression] ICE on simple test case from r15-703-gb390b011569635
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115688 --- Comment #9 from GCC Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:f90ca62566c1d20da585d95ced99f6a1903fc2cc commit r15-1889-gf90ca62566c1d20da585d95ced99f6a1903fc2cc Author: Kewen Lin Date: Sun Jul 7 22:38:34 2024 -0500 rs6000: Consider explicit VSX when masking off ALTIVEC [PR115688] PR115688 exposes an inconsistent state in which we have VSX enabled but ALTIVEC disabled. There is one hunk: if (main_target_opt && !main_target_opt->x_rs6000_altivec_abi) rs6000_isa_flags &= ~((OPTION_MASK_VSX | OPTION_MASK_ALTIVEC) & ~rs6000_isa_flags_explicit); which disables both VSX and ALTIVEC together only considering them explicitly set or not. For the given case, VSX is explicitly specified, altivec is implicitly enabled as it's part of set ISA_2_6_MASKS_SERVER. When falling into the above hunk, vsx is kept as it's explicitly enabled but altivec gets masked off, it's unexpected. This patch is to consider explicit VSX when masking off ALTIVEC, not mask off it if TARGET_VSX and it's explicitly set. PR target/115688 gcc/ChangeLog: * config/rs6000/rs6000.cc (rs6000_option_override_internal): Consider explicit VSX when masking off ALTIVEC. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr115688.c: New test.
[Bug c++/115820] New: Qualified anonymous union is not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115820
Bug ID: 115820
Summary: Qualified anonymous union is not diagnosed
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: luigighiron at gmail dot com
Target Milestone: ---
The following code is not diagnosed in GCC:
struct foo{
const union{
const int i;
};
};
This is not a valid anonymous union because the declaration does not follow the
form "union { member-specification } ;" as the C++ standard specifies. This
also generates an error with Clang, though not with MSVC which has the same
bug. Volatile qualification has the same issue as const qualification as
present in the example.
[Bug c++/115820] Qualified anonymous union is not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115820 --- Comment #1 from Halalaluyafail3 --- The Clang error only occurs with -pedantic-errors to make it clear, GCC does not diagnose the error even with -pedantic-errors.
[Bug c++/115820] Qualified anonymous union is not diagnosed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115820 Andrew Pinski changed: What|Removed |Added Known to fail||3.4.6 Last reconfirmed||2024-07-08 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Confirmed. Not a regression. Looks like it has always been accepted without a pedwarn. Note C11 allows for qualifications on anonymous unions/structs.
[Bug tree-optimization/115659] powerpc fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659 --- Comment #13 from GCC Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:6425dae07aa4be58abade03455c2d9744f73d4e1 commit r15-1891-g6425dae07aa4be58abade03455c2d9744f73d4e1 Author: Kewen Lin Date: Mon Jul 8 00:15:00 2024 -0500 rs6000: Replace orc with iorc [PR115659] Since iorc optab is introduced, this patch is to update the expander names and all the related uses like bif expanders, gen functions accordingly. PR tree-optimization/115659 gcc/ChangeLog: * config/rs6000/rs6000-builtins.def: Update some bif expanders by replacing orc3 with iorc3. * config/rs6000/rs6000-string.cc (expand_cmp_vec_sequence): Update gen function by replacing orc3 with iorc3. * config/rs6000/rs6000.md (orc3): Rename to ... (iorc3): ... this.
[Bug tree-optimization/115659] powerpc fallout from removing vcond{,u,eq} patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115659
--- Comment #12 from GCC Commits ---
The master branch has been updated by Kewen Lin :
https://gcc.gnu.org/g:f379596e0ba99df249d6e8b3f2e66edfcea916fe
commit r15-1890-gf379596e0ba99df249d6e8b3f2e66edfcea916fe
Author: Kewen Lin
Date: Mon Jul 8 00:14:59 2024 -0500
isel: Fold more in gimple_expand_vec_cond_expr with andc and iorc
[PR115659]
As PR115659 shows, assuming c = x CMP y, there are some
folding chances for patterns r = c ? 0/z : z/-1:
- for r = c ? 0 : z, it can be folded into r = ~c & z.
- for r = c ? z : -1, it can be folded into r = ~c | z.
But BIT_AND/BIT_IOR applied on one BIT_NOT operand is a
compound operation, it's arguable to consider it beats
vector selection. So this patch is to introduce new
optabs andc, iorc and its corresponding internal functions
BIT_{ANDC,IORC}, and if targets defines such optabs for
vector modes, it means targets support these hardware
insns and should be not worse than vector selection.
PR tree-optimization/115659
gcc/ChangeLog:
* doc/md.texi: Document andcm3 and iorcm3.
* gimple-isel.cc (gimple_expand_vec_cond_expr): Add more foldings
for
patterns x CMP y ? 0 : z and x CMP y ? z : -1.
* internal-fn.def (BIT_ANDC): New internal function.
(BIT_IORC): Likewise.
* optabs.def (andc, iorc): New optab.
[Bug c/115821] New: -Wc++-compat should warn about anonymous struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115821
Bug ID: 115821
Summary: -Wc++-compat should warn about anonymous struct
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: diagnostic, documentation
Severity: enhancement
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Target Milestone: ---
The documentation for -Wc++-compat says:
Warn about ISO C constructs that are outside of the common subset of ISO C and
ISO C++, e.g. request for implicit conversion from void * to a pointer to
non-void type.
Which makes me think that it should warn about anonymous structs (which is
valid for ISO C but not for ISO C++).
Either we should refine the documentation for -Wc++-compat to talk about GNU
extensions in both (well it is part of C11) or warn in this case.
testcase:
```
struct foo{
struct{
const int i;
};
};
```
I don't have a preference on which way this should be fixed though.
Note we might want to warn on qualifiers on anonymous unions in a similar
fashion (see PR 115820) unless we change the documentation to talk about GNU
extensions here.
[Bug fortran/108889] [12/13/14/15 Regression] (Re)Allocate in assignment shows used uninitialized memory warning with -Wall if LHS is unallocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108889 --- Comment #8 from Paul Thomas --- (In reply to kargls from comment #7) > (In reply to Paul Thomas from comment #6) > > Created attachment 58586 [details] > > Fix for this PR > > > > This does the job but it is still a bit clunky. > > > > Having recently used the location field of locus to determine decl order, I > > rather think that it can be similarly used to determine, when an entity has > > been assigned to in the current scope. I have a backlog of regressions to > > attend to first. I will come back to this one very soon. > > > > Paul > > Does this also fix PR 106089? There's a patch in comment #3 of that > PR that addresses a similar issue. Hi Steve, Yes, that's one and the same issue. One neat feature that will emerge from adding an 'assigned_at' field to gfc_symbol is that the fortran front end can issue a "used uninitialized" warning if -Wuninitialized is not set. For example: integer :: i, j i = 1 i = j print *, i end nagfor issues by default: Warning: test.f90, line 5: Symbol J referenced but never set Cheers Paul
[Bug c/115822] New: -Wmisleading-indentation should warn for inconsistent use of tabs vs spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115822 Bug ID: 115822 Summary: -Wmisleading-indentation should warn for inconsistent use of tabs vs spaces Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: brunopitrus at hotmail dot com Target Milestone: --- …rather than assuming a tab is a certain number of spaces. This example looks misleading depending on your editor settings: https://godbolt.org/z/x97Y68Wc4 The preferred semantics would be Python style (mixing of tabs and spaces is allowed iff the prefix is the same) but that would probably require adding a stack machine to the relevant code.
[Bug c/115822] -Wmisleading-indentation should warn for inconsistent use of tabs vs spaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115822 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- This is not going to work as gnu coding style is a mix of spaces and tabs always. From https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Warning-Options.html#index-Wmisleading-indentation ``` In the case of mixed tabs and spaces, the warning uses the -ftabstop= option to determine if the statements line up (defaulting to 8). ``` So we could add a new option for that style but I really doubt we will. It will definitely not be the default due to gnu coding style that is used inside gcc itself.
[Bug fortran/84006] [11/12/13/14 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 --- Comment #18 from GCC Commits --- The releases/gcc-14 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c36acfea1aea17ff8df8994657c8bf9e3ccde6ca commit r14-10390-gc36acfea1aea17ff8df8994657c8bf9e3ccde6ca Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test. (cherry picked from commit b9294757f82aae8de6d98c122cd4e3b98f685217)
[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 --- Comment #8 from GCC Commits --- The releases/gcc-14 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c36acfea1aea17ff8df8994657c8bf9e3ccde6ca commit r14-10390-gc36acfea1aea17ff8df8994657c8bf9e3ccde6ca Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test. (cherry picked from commit b9294757f82aae8de6d98c122cd4e3b98f685217)
[Bug fortran/100027] ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 --- Comment #6 from GCC Commits --- The releases/gcc-14 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:c36acfea1aea17ff8df8994657c8bf9e3ccde6ca commit r14-10390-gc36acfea1aea17ff8df8994657c8bf9e3ccde6ca Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test. (cherry picked from commit b9294757f82aae8de6d98c122cd4e3b98f685217)
[Bug fortran/100027] ICE on storage_size with polymorphic argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100027 --- Comment #7 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b1429ddd7f20a5c88b65d8de38d64c98c4820782 commit r13-8897-gb1429ddd7f20a5c88b65d8de38d64c98c4820782 Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test. (cherry picked from commit b9294757f82aae8de6d98c122cd4e3b98f685217)
[Bug fortran/84006] [11/12/13/14 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 --- Comment #19 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b1429ddd7f20a5c88b65d8de38d64c98c4820782 commit r13-8897-gb1429ddd7f20a5c88b65d8de38d64c98c4820782 Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test. (cherry picked from commit b9294757f82aae8de6d98c122cd4e3b98f685217)
[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98534 --- Comment #9 from GCC Commits --- The releases/gcc-13 branch has been updated by Paul Thomas : https://gcc.gnu.org/g:b1429ddd7f20a5c88b65d8de38d64c98c4820782 commit r13-8897-gb1429ddd7f20a5c88b65d8de38d64c98c4820782 Author: Paul Thomas Date: Sun May 12 06:59:45 2024 +0100 Fortran: Unlimited polymorphic intrinsic function arguments [PR84006] 2024-05-12 Paul Thomas gcc/fortran PR fortran/84006 PR fortran/100027 PR fortran/98534 * iresolve.cc (gfc_resolve_transfer): Emit a TODO error for unlimited polymorphic mold. * trans-expr.cc (gfc_resize_class_size_with_len): Use the fold even if a block is not available in which to fix the result. (trans_class_assignment): Enable correct assignment of character expressions to unlimited polymorphic variables using lhs _len field and rse string_length. * trans-intrinsic.cc (gfc_conv_intrinsic_storage_size): Extract the class expression so that the unlimited polymorphic class expression can be used in gfc_resize_class_size_with_len to obtain the storage size for character payloads. Guard the use of GFC_DECL_SAVED_DESCRIPTOR by testing for DECL_LANG_SPECIFIC to prevent the ICE. Also, invert the order to use the class expression extracted from the argument. (gfc_conv_intrinsic_transfer): In same way as 'storage_size', use the _len field to obtaining the correct length for arg 1. Add a branch for the element size in bytes of class expressions with provision to make use of the unlimited polymorphic _len field. Again, the class references are explicitly identified. 'mold_expr' was already declared. Use it instead of 'arg'. Do not fix 'dest_word_len' for deferred character sources because reallocation on assign makes use of it before it is assigned. gcc/testsuite/ PR fortran/84006 PR fortran/100027 * gfortran.dg/storage_size_7.f90: New test. PR fortran/98534 * gfortran.dg/transfer_class_4.f90: New test. (cherry picked from commit b9294757f82aae8de6d98c122cd4e3b98f685217)
[Bug target/115713] rs6000: Miss warning for incompatible no-altivec and vsx in target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115713
--- Comment #6 from Kewen Lin ---
(In reply to Richard Biener from comment #5)
> The docs are at least imprecise. Surely command-line -maltivec with
> target ("no-vsx") shouldn't revert to whatever is default with the target
> opts.
Thanks for confirming, I'll update the affected test case.
[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 --- Comment #10 from Paul Thomas --- Created attachment 58605 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58605&action=edit "Fix" for this PR This "fix" turns out to have restricted utility because of other changes in 14-branch and mainline. I will close the PR without committing the patch. Sorry it didn't work out. Paul
[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 Paul Thomas changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #11 from Paul Thomas --- This "fix" turns out to have restricted utility because of other changes in 14-branch and mainline. I will close the PR without committing the patch. Sorry it didn't work out. Paul
[Bug fortran/84006] [11/12 Regression] ICE in storage_size() with CLASS entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Summary|[11/12/13/14 Regression]|[11/12 Regression] ICE in |ICE in storage_size() with |storage_size() with CLASS |CLASS entity|entity --- Comment #20 from Paul Thomas --- Fixed on 13-branch to mainline. Closing as fixed Cheers Paul
[Bug fortran/92006] storage_size() returns incorrect value on unlimited polymorphic variable (CLASS(*)) when passed a CHARACTER variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92006 Bug 92006 depends on bug 84006, which changed state. Bug 84006 Summary: [11/12 Regression] ICE in storage_size() with CLASS entity https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84006 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug modula2/115823] New: Wrong expansion of isnormal optab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115823 Bug ID: 115823 Summary: Wrong expansion of isnormal optab Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: stefansf at gcc dot gnu.org Target Milestone: --- Implementing isnormal optab for s390 results in FAIL: gm2/builtins/run/pass/testisnormal.mod compilation, -O FAIL: gm2/builtins/run/pass/testisnormal.mod compilation, -O -g FAIL: gm2/builtins/run/pass/testisnormal.mod compilation, -O3 -fomit-frame-pointer FAIL: gm2/builtins/run/pass/testisnormal.mod compilation, -O3 -fomit-frame-pointer -finline-functions FAIL: gm2/builtins/run/pass/testisnormal.mod compilation, -Os FAIL: gm2/builtins/run/pass/testisnormal.mod compilation, -g UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution, -O (link failed) UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution, -O -g (link failed) UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution, -O3 -fomit-frame-pointer (link failed) UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution, -O3 -fomit-frame-pointer -finline-functions (link failed) UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution, -Os (link failed) UNRESOLVED: gm2/builtins/run/pass/testisnormal.mod execution, -g (link failed) All tests output /usr/bin/ld: /tmp/ccFZtxN6.o: in function `test': testisnormal.mod:(.text+0x2d4): undefined reference to `__builtin_isnormal' collect2: error: ld returned 1 exit status In math.h we have # define isnormal(x) __builtin_isnormal (x) which means for C code in expand_builtin if (!optimize && !called_as_built_in (fndecl) && fcode != BUILT_IN_FORK && fcode != BUILT_IN_EXECL && fcode != BUILT_IN_EXECV && fcode != BUILT_IN_EXECLP && fcode != BUILT_IN_EXECLE && fcode != BUILT_IN_EXECVP && fcode != BUILT_IN_EXECVE && fcode != BUILT_IN_CLEAR_CACHE && !ALLOCA_FUNCTION_CODE_P (fcode) && fcode != BUILT_IN_FREE && (fcode != BUILT_IN_MEMSET || !(flag_inline_stringops & ILSOP_MEMSET)) && (fcode != BUILT_IN_MEMCPY || !(flag_inline_stringops & ILSOP_MEMCPY)) && (fcode != BUILT_IN_MEMMOVE || !(flag_inline_stringops & ILSOP_MEMMOVE)) && (fcode != BUILT_IN_MEMCMP || !(flag_inline_stringops & ILSOP_MEMCMP))) return expand_call (exp, target, ignore); `called_as_built_in (fndecl)` is always true whereas for gm2 it evaluates to false due to the call side being isnormal (1.0e+0) However, in rtx_for_function_call the symbol reference funexp = XEXP (DECL_RTL (fndecl), 0); is actually __builtin_isnormal which leads to a linker error. Out of curiosity, the test output indicates that this error also happens e.g. for -O3. However, looking into the logs, those tests where never executed with -O3. Kinda surprised me.
