[Bug middle-end/102153] New: Better expansion of __builtin_*_overflow should be done
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102153 Bug ID: 102153 Summary: Better expansion of __builtin_*_overflow should be done Product: gcc Version: 12.0 Status: UNCONFIRMED Keywords: internal-improvement, missed-optimization Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- One thing I noticed is that __builtin_*_overflow is always expanded as: result = 0; if (overflow) result = 1; Which then later on get changed to result = overflow during ifcvt or jump threaded. Why not instead just use cstore instead.
[Bug target/99591] Improving __builtin_add_overflow performance on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99591 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > Looks fixed for GCC 11+. signed2_overflow(short, short): .LFB0: .cfi_startproc addw%si, %di seto%al ret signed1_overflow(signed char, signed char): .LFB1: .cfi_startproc addb%sil, %dil seto%al ret
[Bug target/99591] Improving __builtin_add_overflow performance on x86-64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99591 Andrew Pinski changed: What|Removed |Added Known to fail||10.3.0 Known to work||11.1.0 --- Comment #1 from Andrew Pinski --- Looks fixed for GCC 11+.
[Bug rtl-optimization/97856] Missed optimization: repeated call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97856 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug rtl-optimization/97856] Missed optimization: repeated call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97856 --- Comment #2 from Andrew Pinski --- (In reply to Richard Biener from comment #1) > Confirmed. basic-block reordering decides to duplicate the block: Yes there are a few other bugs where we like to duplicate the return block I have seen too.
[Bug tree-optimization/102152] [12 Regression] ICE: tree check: expected ssa_name, have integer_cst in cprop_operand, at tree-ssa-dom.c:1715
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102152
Andrew Pinski changed:
What|Removed |Added
CC||jeffreyalaw at gmail dot com
--- Comment #2 from Andrew Pinski ---
(gdb) p debug_gimple_stmt(op_p.loc.stmt)
if (0 != 0)
Optimizing statement if (next_mask_61 != { 0, ... })
Reducing vector comparison: if (next_mask_61 != { 0, ... })
To scalar equivalent: if (0 != 0)
So r12-3190 caused it.
[Bug tree-optimization/102152] [12 Regression] ICE: tree check: expected ssa_name, have integer_cst in cprop_operand, at tree-ssa-dom.c:1715
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102152 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-01 Target Milestone|--- |12.0 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/102124] [11/12 Regression] -ftree-loop-vectorize Causing Data To Lose Sign Bit on AARCH64 Platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102124 --- Comment #7 from Tomas Chang --- (In reply to Jakub Jelinek from comment #6) > Created attachment 51377 [details] > gcc12-pr102124.patch > > Untested fix. After applying this patch on GCC 11.2.1 code base, I re-built GCC on my AARCH64 box (spending 36 hours) and tested. This issue is gone. Thanks for fixing this bug so quickly!
[Bug tree-optimization/102152] New: [12 Regression] ICE: tree check: expected ssa_name, have integer_cst in cprop_operand, at tree-ssa-dom.c:1715
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102152
Bug ID: 102152
Summary: [12 Regression] ICE: tree check: expected ssa_name,
have integer_cst in cprop_operand, at
tree-ssa-dom.c:1715
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
Target: aarch64-linux-gnu
gcc-12.0.0-alpha20210829 snapshot (g:c3c669ac811429033c0151f910b38fc009e21ca8)
ICEs when compiling the following testcase w/ -march=armv8-a+sve -O1
-ftree-loop-vectorize -fno-tree-fre:
signed char i;
void
foo (void)
{
for (i = 0; i < 6; i += 5)
;
}
% aarch64-linux-gnu-gcc-12.0.0 -march=armv8-a+sve -O1 -ftree-loop-vectorize
-fno-tree-fre -c gye5eeyb.c
during GIMPLE pass: dom
gye5eeyb.c: In function 'foo':
gye5eeyb.c:4:1: internal compiler error: tree check: expected ssa_name, have
integer_cst in cprop_operand, at tree-ssa-dom.c:1715
4 | foo (void)
| ^~~
0x7e6522 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210829/work/gcc-12-20210829/gcc/tree.c:8688
0x7a5747 tree_check(tree_node*, char const*, int, char const*, tree_code)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210829/work/gcc-12-20210829/gcc/tree.h:3391
0x7a5747 cprop_operand
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210829/work/gcc-12-20210829/gcc/tree-ssa-dom.c:1715
0x7a5747 cprop_into_stmt
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210829/work/gcc-12-20210829/gcc/tree-ssa-dom.c:1792
0x7a5747 dom_opt_dom_walker::optimize_stmt(basic_block_def*,
gimple_stmt_iterator*, bool*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210829/work/gcc-12-20210829/gcc/tree-ssa-dom.c:2002
0x105aef8 dom_opt_dom_walker::before_dom_children(basic_block_def*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210829/work/gcc-12-20210829/gcc/tree-ssa-dom.c:1430
0x1a17487 dom_walker::walk(basic_block_def*)
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210829/work/gcc-12-20210829/gcc/domwalk.c:309
0x10584ec execute
/var/tmp/portage/cross-aarch64-linux-gnu/gcc-12.0.0_alpha20210829/work/gcc-12-20210829/gcc/tree-ssa-dom.c:764
[Bug rtl-optimization/79858] Explain to translators what %smode means
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79858 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-09-01 --- Comment #4 from Andrew Pinski --- Confirmed.
[Bug tree-optimization/79357] Doubling a single complex float gives inefficient code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79357
Andrew Pinski changed:
What|Removed |Added
Blocks||101926
--- Comment #4 from Andrew Pinski ---
(In reply to Marc Glisse from comment #3)
> Note that we do not generate better code for
> typedef float vec __attribute__((vector_size(8)));
> vec g(vec x){return 2*x;}
> (we don't consider larger vector modes when lowering/expanding vector
> operations, there is already a PR about that)
The testcase in comment #3 was fixed for GCC 11+.
The original testcase still has issues has SLP does not happen but then we are
to another problem.
See:
#define complex _Complex
typedef float vec __attribute__((vector_size(8)));
complex float f(complex float x) {
vec t = *(vec*)
t= (2*t);
return *(complex float*)
}
Note I think there is a dup for the above issue too.
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926
[Bug 101926] [meta-bug] struct/complex argument passing and return should be
improved
[Bug driver/49631] Driver --help should use common help code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49631 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2021-09-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Keywords||diagnostic, ||internal-improvement --- Comment #2 from Andrew Pinski --- Confirmed, display_help still exists with all of the printfs there.
[Bug tree-optimization/102151] Spurious warning by -Warray-bounds when allocating with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102151 --- Comment #2 from Andrew Pinski --- I think the malloc needs to be at least the sizeof which is why it is complaining.
[Bug c/102103] missing warning comparing array address to null
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102103 Martin Sebor changed: What|Removed |Added Keywords||patch --- Comment #2 from Martin Sebor --- Patch: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/578546.html
[Bug c/102151] Spurious warning by -Warray-bounds when allocating with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102151
Niibe Yutaka changed:
What|Removed |Added
CC||gniibe at fsij dot org
--- Comment #1 from Niibe Yutaka ---
struct arg_and_data_s
{
struct arg_and_data_s *next;
unsigned int len;
char arg[];
};
sizeof(struct arg_and_data_s) is 16 for x86_64.
offsetof (struct arg_and_data_s, arg) is 12.
[Bug c/102151] New: Spurious warning by -Warray-bounds when allocating with flexible array member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102151 Bug ID: 102151 Summary: Spurious warning by -Warray-bounds when allocating with flexible array member Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: gniibe at fsij dot org Target Milestone: --- Created attachment 51392 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51392=edit Test with smaller size and valid access to the structure with flexible array member When allocating memory with smaller size than sizeof(a_structure_with_flexible_member), for (valid) access to the structure, compiler emits spurious warning, in some optimization level.
[Bug middle-end/102133] [12 Regression] ICE in set_rtl building libgcc __muldc3 for 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133 --- Comment #12 from Hongtao.liu --- Fixed in GCC12.
[Bug middle-end/102133] [12 Regression] ICE in set_rtl building libgcc __muldc3 for 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133 --- Comment #11 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:508fa61b6319377e48cbee98da221aacd475fd10 commit r12-3276-g508fa61b6319377e48cbee98da221aacd475fd10 Author: liuhongt Date: Tue Aug 31 17:16:08 2021 +0800 Revert "Make sure we're playing with integral modes before call extract_integral_bit_field." This reverts commit 7218c2ec365ce95f5a1012a6eb425b0a36aec6bf. PR middle-end/102133
[Bug inline-asm/59615] "asm goto" output or at least clobbered operands
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59615 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|UNCONFIRMED |RESOLVED --- Comment #9 from Andrew Pinski --- Fixed in GCC 11 with r11-5002.
[Bug inline-asm/94522] Enhancement request: asm goto with outputs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94522 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|NEW |RESOLVED --- Comment #6 from Andrew Pinski --- Fixed in GCC 11 by r11-5002.
[Bug rtl-optimization/102150] New: Speculative execution of inline assembly causes divide error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102150 Bug ID: 102150 Summary: Speculative execution of inline assembly causes divide error Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: jeremy-gcc-bugzilla at sawicki dot us Target Milestone: --- Created attachment 51391 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51391=edit Reproducible test case The attached test case uses inline assembly to wrap the x86_64 DIV instruction. GCC speculatively executes the inline assembly on inputs that the source program does not, resulting in a divide error. The GCC documentation says that non-volatile inline assembly may be discarded or moved out of loops. It is not obvious whether speculative execution is also permitted. I asked on gcc-help and was asked to file a report. A related report points out that many projects currently wrap the DIV instruction without using volatile: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82677 Another related report considers the similar issue of whether pure/const functions must be non-trapping for inputs they don't actually receive: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93491 If it is determined that volatile is required, it would helpful to clarify in the documentation that speculative execution may occur without volatile: https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html#Volatile gcc version 11.2.0 (GCC) Target: x86_64-pc-linux-gnu Configured with: /home/jeremys/gcc-11.2.0/configure --prefix=/home/jeremys/gcc-11.2.0-install --disable-multilib Command line: g++ -O3 -o divasm divasm.cpp No compiler errors/warnings are produced When executed, a divide error occurs
[Bug bootstrap/89140] libiberty/pex-unix.c fails to compile in aarch64-to-x86_64 cross build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89140 --- Comment #1 from Andrew Pinski --- >the configure script for libiberty finds that getrusage is not available but >wait4 is. Both should be there.
[Bug bootstrap/62009] [5 Regression] Bootstrap failure in vec.h::splice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62009 Andrew Pinski changed: What|Removed |Added Keywords||build, ice-on-valid-code Summary|Bootstrap failure in|[5 Regression] Bootstrap |vec.h::splice |failure in vec.h::splice Resolution|--- |FIXED Status|NEW |RESOLVED Target Milestone|--- |5.0 --- Comment #4 from Andrew Pinski --- Fixed by r5-2542. The bug # is in the subject but it never got to bugzilla.
[Bug bootstrap/70242] GCC bootstrap failed on x86_64 using "--with-build-config=bootstrap-O3"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70242 --- Comment #3 from Andrew Pinski --- I was able to do this on the trunk last week and it did not fail.
[Bug bootstrap/52847] "case" shell quoting problem in top-level makefile
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52847 Andrew Pinski changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #4 from Andrew Pinski --- Fixed by r0-116582 which was 2 days after the last comment here (for GCC 4.8.0).
[Bug testsuite/51748] gcc.misc-tests/linkage.c fails on mips64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51748 --- Comment #2 from Andrew Pinski --- Created attachment 51390 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51390=edit Patch
[Bug c++/96286] Unhelpful errors after a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96286
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment #5 from Jason Merrill ---
(In reply to CVS Commits from comment #4)
> c++: limit instantiation with ill-formed class [PR96286]
This change and the one for PR92193 improve our limiting of recursive
instantiation leading to unhelpful errors, but they don't help with the vector
89164 testcase you pointed me at, because the static_assert is buried deep in
the call stack.
wa.ii: In instantiation of ‘constexpr bool std::__check_constructible() [with
_ValueType = X; _Tp = X&]’:
wa.ii:20407:119: required from ‘_ForwardIterator
std::uninitialized_copy(_InputIterator, _InputIterator, _ForwardIterator) [with
_InputIterator = X*; _ForwardIterator = X*]’
wa.ii:20560:37: required from ‘constexpr _ForwardIterator
std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator,
std::allocator<_Tp>&) [with _InputIterator = X*; _ForwardIterator = X*; _Tp =
X]’
wa.ii:22118:33: required from ‘constexpr void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = X*; _Tp = X; _Alloc =
std::allocator]’
wa.ii:21612:23: required from here
wa.ii:20342:56: error: static assertion failed: result type must be
constructible from input type
and then later we get
wa.ii: In instantiation of ‘constexpr void std::_Construct(_Tp*, _Args&& ...)
[with _Tp = X; _Args = {X&}]’:
wa.ii:20357:21: required from ‘constexpr _ForwardIterator
std::__do_uninit_copy(_InputIterator, _InputIterator, _ForwardIterator) [with
_InputIterator = X*; _ForwardIterator = X*]’
wa.ii:20558:30: required from ‘constexpr _ForwardIterator
std::__uninitialized_copy_a(_InputIterator, _InputIterator, _ForwardIterator,
std::allocator<_Tp>&) [with _InputIterator = X*; _ForwardIterator = X*; _Tp =
X]’
wa.ii:22118:33: required from ‘constexpr void std::vector<_Tp,
_Alloc>::_M_range_initialize(_ForwardIterator, _ForwardIterator,
std::forward_iterator_tag) [with _ForwardIterator = X*; _Tp = X; _Alloc =
std::allocator]’
wa.ii:21612:23: required from here
wa.ii:13010:21: error: no matching function for call to ‘construct_at(X*&, X&)’
but _Construct was queued for instantiation before we hit the static_assert; it
was prompted by an earlier line in __uninitialized_copy_a than the one that led
to the instantiation of __check_constructible.
I get better results if I add the static_assert to __uninitialized_copy_a, so
we hit it before queuing any further instantiations.
[Bug c++/36274] Please improve usage of template libs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36274 --- Comment #5 from Andrew Pinski --- I think C++ modules will fix this.
[Bug tree-optimization/102149] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102149 --- Comment #3 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #2) > Started with r12-3222-g89f33f44addbf9853bc3e6677db1fa941713cb6c > but got fixed with r12-3250-g67927342290c61d7e054430f1d7a7281f1f97fae > So I think we just want to add the testcase to the testsuite and close. That might mean -fno-vect-cost-model might be able to reproduce this still on the trunk I think.
[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876 Harald van Dijk changed: What|Removed |Added CC||harald at gigawatt dot nl --- Comment #12 from Harald van Dijk --- (In reply to Jonathan Wakely from comment #11) > No, probably not. Comment 2 doesn't work because -Wsystem-headers can't be > enabled and disabled using pragmas. It doesn't work like other warnings. However, the internal version of the #line directive, # [line number] [file name] [flags] could be used to mark a region of a system header as non-system header, which should achieve the same result, right? It might need a bit of cleanup to be maintainable, but this seems to work as a proof of concept: --- bits/unique_ptr.h +++ bits/unique_ptr.h @@ -82,7 +82,9 @@ "can't delete pointer to incomplete type"); static_assert(sizeof(_Tp)>0, "can't delete pointer to incomplete type"); +# 86 __FILE__ delete __ptr; +# 88 __FILE__ 3 } };
[Bug tree-optimization/102149] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102149 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Started with r12-3222-g89f33f44addbf9853bc3e6677db1fa941713cb6c but got fixed with r12-3250-g67927342290c61d7e054430f1d7a7281f1f97fae So I think we just want to add the testcase to the testsuite and close.
[Bug tree-optimization/102149] wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102149 --- Comment #1 from Qirun Zhang --- My bisection points to g:89f33f44addbf9853bc3e6677d
[Bug tree-optimization/102149] New: wrong code at -O3 on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102149
Bug ID: 102149
Summary: wrong code at -O3 on x86_64-linux-gnu
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: qrzhang at gatech dot edu
Target Milestone: ---
Seems to be a recent regression.
$ gcc-trunk -v
gcc version 12.0.0 20210831 (experimental) [master revision
5e57bacf6f3:a82c79a304b:de7a795c321e76826d123c92b99e73e144666b60] (GCC)
$ gcc-trunk abc.c ; ./a.out
1
$ gcc-trunk abc.c ; ./a.out
0
$ cat abc.c
int a[8];
int *b = [6];
char c;
int main() {
int d = 7;
for (; d >= 0; d--) {
*b = 1;
c = a[d] >> 3;
a[d] = c;
}
printf("%d\n", a[6]);
}
[Bug fortran/100950] ICE in output_constructor_regular_field, at varasm.c:5514
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100950 --- Comment #14 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:e4cb3bb9ac11b4126ffa718287dd509a4b10a658 commit r12-3273-ge4cb3bb9ac11b4126ffa718287dd509a4b10a658 Author: Harald Anlauf Date: Tue Aug 31 21:00:53 2021 +0200 Fortran - extend set of substring expressions handled in length simplification gcc/fortran/ChangeLog: PR fortran/100950 * simplify.c (substring_has_constant_len): Minimize checks for substring expressions being allowed. gcc/testsuite/ChangeLog: PR fortran/100950 * gfortran.dg/pr100950.f90: Extend coverage.
[Bug c++/55722] failed static_assert won't trigger a second time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55722 Jason Merrill changed: What|Removed |Added Status|NEW |RESOLVED CC||jason at gcc dot gnu.org Resolution|--- |INVALID --- Comment #4 from Jason Merrill --- The static_assert only fires once because we only instantiate a particular class or function once. When we instantiate __assert_callable, we trip the static_assert, but later uses get the result of the earlier instantiation. I don't think factoring out static_assert into a separate template is going to do what you want.
[Bug c++/55004] [meta-bug] constexpr issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55004 Bug 55004 depends on bug 92193, which changed state. Bug 92193 Summary: Poor diagnostics when a constexpr function call follows a failed static_assert https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92193 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/92193] Poor diagnostics when a constexpr function call follows a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92193 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Target Milestone|--- |12.0 Resolution|--- |FIXED --- Comment #4 from Jason Merrill --- Fixed for GCC 12.
[Bug fortran/56985] gcc/fortran/resolve.c:920: "'%s' in cannot appear in COMMON ..."
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56985 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-August/056457.html
[Bug c/102148] New: ppc64le: homogeneous float arguments are not passed correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102148
Bug ID: 102148
Summary: ppc64le: homogeneous float arguments are not passed
correctly
Product: gcc
Version: 8.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zlwang at ca dot ibm.com
Target Milestone: ---
example program:
typedef struct {
float a[2];
} sub;
typedef struct {float b; sub c; float d;} R;
extern R func(long,R,float,int);
R v = {0, {1,2}, 3};
double ma() {
R rv = func(77,v,88,99);
return rv.d;
}
Since R is a homogeneous float aggregate with less than 8 elements, func
argument passing should look like the following function:
func(long, float, float, float, float, float, int)
But they are not. At least for gcc8.4.1, the latter's long/int are passed in r3
and r9 respectively; while the former's long/int are passed in r3 and r7
respectively.
[Bug libstdc++/102015] [missed optimization] Small memory overhead in _Rb_tree_impl (fix would require ABI break)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102015 Jonathan Wakely changed: What|Removed |Added CC||redi at gcc dot gnu.org --- Comment #5 from Jonathan Wakely --- *** Bug 77402 has been marked as a duplicate of this bug. ***
[Bug libstdc++/77402] Use EBO for _Rb_tree_impl::_M_key_compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77402 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Jonathan Wakely --- Closing as a dup of a much newer bug, because that has more discussion. *** This bug has been marked as a duplicate of bug 102015 ***
[Bug libstdc++/102015] [missed optimization] Small memory overhead in _Rb_tree_impl (fix would require ABI break)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102015 --- Comment #4 from Jonathan Wakely --- In https://gcc.gnu.org/pipermail/libstdc++/2021-August/053108.html I proposed dropping C++98 support for the gnu-versioned-namespace, which would allow us to fix this by using [[__no_unique_address__]]. N.B. I reported this same issue as PR 77402 five years ago.
[Bug libstdc++/101739] Some function parameters in missing uglify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739 --- Comment #3 from Jonathan Wakely --- For consistency (and to avoid reports like this one) we might want to uglify them anyway. But it's not a correctness issue, just stylistic.
[Bug libstdc++/64399] g++ does not diagnose when upcasting owning pointer (e.g. unique_ptr) with non-virtual destructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64399 Jonathan Wakely changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2021-08-31 Ever confirmed|0 |1 --- Comment #8 from Jonathan Wakely --- See https://wg21.link/p2413 which proposes to make this conversion ill-formed.
[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58876 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=64399 --- Comment #11 from Jonathan Wakely --- (In reply to DB from comment #10) > Sorry to pester, but is this likely to get anywhere, any time soon? No, probably not. Comment 2 doesn't work because -Wsystem-headers can't be enabled and disabled using pragmas. It doesn't work like other warnings. I don't think this can be fixed in the library. > I presume the same goes for std::shared_ptr, too. No, because shared_ptr type-erases the deleter and so deletes the dynamic type even if the stored pointer is upcast to a different static type.
[Bug libstdc++/98421] std::span does not detect invalid range in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98421 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #2 from Jonathan Wakely --- Fixed on trunk.
[Bug libstdc++/98421] std::span does not detect invalid range in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98421 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ef7becc9c8a48804d3fd9dac032f7b33e561a612 commit r12-3272-gef7becc9c8a48804d3fd9dac032f7b33e561a612 Author: Jonathan Wakely Date: Tue Aug 31 17:34:51 2021 +0100 libstdc++: Add valid range checks to std::span constructors [PR98421] Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/98421 * include/std/span (span(Iter, size_type), span(Iter, Iter)): Add valid range checks. * testsuite/23_containers/span/cons_1_assert_neg.cc: New test. * testsuite/23_containers/span/cons_2_assert_neg.cc: New test.
[Bug middle-end/102126] Wrong optimization of FP multiplication and division by 1 and -1 with -ftrapping-math when an underflow is possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102126 --- Comment #8 from joseph at codesourcery dot com --- I think that documentation should be changed to say it's primarily about flags, not traps, with trapping being considered much more of a legacy feature rather than something it's normally a good idea to use (although the option should generally cover the case of traps as well, while still allowing variations in the nonzero number of times an exception is raised or the order in which different exceptions are raised).
[Bug target/102107] protocol register (r12) corrupted before a tail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #13 from Segher Boessenkool --- /* If we need to save CR, put it into r12 or r11. Choose r12 except when r12 will be needed by out-of-line gpr save. */ cr_save_regno = ((DEFAULT_ABI == ABI_AIX || DEFAULT_ABI == ABI_ELFv2) && !(strategy & (SAVE_INLINE_GPRS | SAVE_NOINLINE_GPRS_SAVES_LR)) ? 11 : 12);
[Bug gcov-profile/96092] Should --coverage respect -ffile-prefix-map?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96092 Andrew Psaltis changed: What|Removed |Added CC||apsaltis at vmware dot com --- Comment #5 from Andrew Psaltis --- Any word on this? WRT clang, it looks like this was committed early 2021[1], and has been released along with llvm 12.0.0 as -fprofile-prefix-map[2]. [1] https://github.com/llvm/llvm-project/commit/c3324450b204392169d4ec7172cb32f74c03e376 [2] https://releases.llvm.org/12.0.0/tools/clang/docs/ClangCommandLineReference.html#cmdoption-clang-fprofile-prefix-map
[Bug c++/12672] Evals template defaults args that it should not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12672 --- Comment #15 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:f1e7319956928712e8bf4893ebdfeeb6441099ee commit r12-3271-gf1e7319956928712e8bf4893ebdfeeb6441099ee Author: Patrick Palka Date: Tue Aug 31 13:31:10 2021 -0400 c++: check arity before deduction w/ explicit targs [PR12672] During overload resolution, when the arity of a function template clearly disagrees with the arity of the call, no specialization of the function template could yield a viable candidate. The deduction routine type_unification_real already notices this situation, but not before it substitutes explicit template arguments into the template, a step which could induce a hard error. Although it's necessary to perform this substitution first in order to check arity perfectly (since the substitution can e.g. expand a non-trailing parameter pack), in most cases we can determine ahead of time whether there's an arity disagreement without needing to perform deduction at all. To that end, this patch implements an (approximate) arity check in add_template_candidate_real that guards actual deduction. It's enabled only when there are explicit template arguments since that's when deduction can force otherwise avoidable template instantiations. (I experimented with enabling it unconditionally as an optimization, and observed some improvements to compile time of about 5% but also some slowdowns of about the same magnitude, so kept it conditional.) In passing, this adds a least_p parameter to arity_rejection for sake of consistent diagnostics with unify_arity. A couple of testcases needed to be adjusted so that deduction continues to occur as intended after this change. Except in unify6.C, where we were expecting foo to be ill-formed due to substitution forming a function type with an added 'const', but ISTM this is permitted by [dcl.fct]/7, so I changed the test accordingly. PR c++/12672 gcc/cp/ChangeLog: * call.c (rejection_reason::call_varargs_p): Rename this previously unused member to ... (rejection_reason::least_p): ... this. (arity_rejection): Add least_p parameter. (add_template_candidate_real): When there are explicit template arguments, check that the arity of the call agrees with the arity of the function before attempting deduction. (print_arity_information): Add least_p parameter. (print_z_candidate): Adjust call to print_arity_information. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/decltype29.C: Adjust. * g++.dg/template/error56.C: Adjust. * g++.old-deja/g++.pt/unify6.C: Adjust. * g++.dg/template/explicit-args7.C: New test.
[Bug fortran/102145] TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145 kargl at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement CC||kargl at gcc dot gnu.org Priority|P3 |P5 --- Comment #1 from kargl at gcc dot gnu.org --- Bummer. I do note that the gcc.info description describes -pedantic in terms of only ISO C/C++, but let's assume -pedantic should apply to ISO Fortran as well. From the gcc manual -Wpedantic' '-pedantic' Issue all the warnings demanded by strict ISO C and ISO C++; reject all programs that use forbidden extensions, ... >From Fortran 2018, 4.2 Conformance A processor conforms to this document if: ... (10) it contains the capability to detect and report the reason for rejecting a submitted program. Perhaps, gfortran is enforcing the "reject all programs that use forbidden extensions," portion. Improvements to the gfortran documentation are encouraged and welcomed from all users of gfortran that find it lacking.
[Bug libstdc++/101739] Some function parameters in missing uglify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739 --- Comment #2 from 康桓瑋 --- (In reply to Jonathan Wakely from comment #1) > These changes are not strictly necessary. > > "base" is a reserved name, because of move_iterator::base() etc. > > and "i" is a reserved name, because of operator""i() in . > > So users cannot define those as macros, and so it's safe for us to use them. Extremely reasonable.
[Bug target/102140] [12 Regression] ICE: in extract_constrain_insn, at recog.c:2670 (insn does not satisfy its constraints) with -Og -fipa-cp -fno-tree-ccp -fno-tree-ter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102140
Jakub Jelinek changed:
What|Removed |Added
CC||dje at gcc dot gnu.org,
||jakub at gcc dot gnu.org,
||segher at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Priority|P3 |P1
--- Comment #3 from Jakub Jelinek ---
Slightly adjusted testcase, so that there is no warning about too large
constant:
typedef int __attribute__((__vector_size__ (64))) U;
typedef __int128 __attribute__((__vector_size__ (64))) V;
int a, b;
static void
bar (char c, V v)
{
v *= c;
U u = a + (U) v;
(union { U b; }) { u };
b = 0;
}
void
foo (void)
{
bar (1, (V){((__int128) 9223372036854775808ULL) << 64});
}
Started with r12-139-g7d6bb80931b429631f63e0fd27bee95f32eb57a9 which was a
middle-end change, so I bet it just triggered a latent backend or LRA bug.
If I do:
typedef int V __attribute__((vector_size (16)));
typedef __int128 W __attribute__((vector_size (16)));
V
foo (void)
{
return (V) (W) { (unsigned __int128) 1 << 127 };
}
V
bar (void)
{
return (V) { 0, 0, 0, -__INT_MAX__ - 1 };
}
then the insns like:
(insn 9 5 10 2 (set (reg/i:V4SI 66 2)
(const_vector:V4SI [
(const_int 0 [0]) repeated x3
(const_int -2147483648 [0x8000])
])) "pr102140-3.c":8:1 1127 {vsx_movv4si_64bit}
(expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 0 [0]) repeated x3
(const_int -2147483648 [0x8000])
])
(nil)))
is split during split1. But on the above testcase we have
(insn 10 7 12 2 (set (reg:TI 118 [ _12 ])
(const_wide_int 0x8000)) "pr102140.c":9:5
1134 {vsx_movti_64bit}
(nil))
...
(insn 17 15 18 2 (set (reg:V4SI 120 [ _14 ])
(subreg:V4SI (reg:TI 118 [ _12 ]) 0)) 1127 {vsx_movv4si_64bit}
(expr_list:REG_DEAD (reg:TI 118 [ _12 ])
(expr_list:REG_EQUAL (const_vector:V4SI [
(const_int 0 [0]) repeated x3
(const_int -2147483648 [0x8000])
])
(nil
during split1 and only IRA forward propagates the constant into the insn.
So perhaps the operand predicate shouldn't allow such constants after split1?
split1 pass sets PROP_rtl_split_insns property which e.g. the i386 backend is
using to make sure not to match stuff after split1 if it was only supposed to
be valid before split1 (see ix86_pre_reload_split predicate).
[Bug libstdc++/101739] Some function parameters in missing uglify
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101739 --- Comment #1 from Jonathan Wakely --- These changes are not strictly necessary. "base" is a reserved name, because of move_iterator::base() etc. and "i" is a reserved name, because of operator""i() in . So users cannot define those as macros, and so it's safe for us to use them.
[Bug libstdc++/102074] include/bits/atomic_timed_wait.h:215: possible missing return ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102074 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:763eb1f19239ebb19c0f87590a4f02300c02c52b commit r12-3263-g763eb1f19239ebb19c0f87590a4f02300c02c52b Author: Jonathan Wakely Date: Tue Aug 31 16:50:17 2021 +0100 libstdc++: Add missing return for atomic timed wait [PR102074] This adds a missing return statement to the non-futex wait-until operation. Signed-off-by: Jonathan Wakely libstdc++-v3/ChangeLog: PR libstdc++/102074 * include/bits/atomic_timed_wait.h (__timed_waiter_pool) [!_GLIBCXX_HAVE_PLATFORM_TIMED_WAIT]: Add missing return.
[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125 --- Comment #6 from Richard Earnshaw --- (In reply to Richard Biener from comment #2) > One common source of missed optimizations is gimple_fold_builtin_memory_op > which has [...] Yes, this is the source of the problem. I wonder if this should be scaled by something like MOVE_RATIO to get a more acceptable limit, especially at higher optimization levels.
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #16 from Segher Boessenkool --- (In reply to wschmidt from comment #14) > I disagree with that. You should use __VSX__ && _ARCH_PWR9 to check for > P9 vector support, etc. The __POWERn_VECTOR__ things really are not > great and I wish they had never been added. +1 That we have corresponding TARGET_* macros internal to the backend is one thing. Also not great for the same reasons, but those can be useful shorthand maybe. But externally there should just be one authorative source of information, and ideally there will be no N other macros that confuse the user, or even confuse the user into thinking they are good to use.
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #15 from Segher Boessenkool --- (In reply to HaoChen Gui from comment #9) > For this example, let's suppose that we set mcpu=power8 and mno-vsx in the > command line. Thus, _ARCH_PWR8 should be defined as mcpu=power8. But if the > Power8-specific codes contain VSX codes, could the asm be executed? I think > we just use the macro _ARCH_PWR8 here to guard which instructions are > available. Yes, it can be executed just fine. The only thing the compiler -mno-vsx flag does is make the compiler not generate any code that uses the VSRs (or any VSX insns). Whether the program tries to use VSX resources by itself is up to it. The CPU certainly does not think it does not have those insns. The kernel will not think it does not, either. Things will just work, by default anyway.
[Bug libstdc++/98421] std::span does not detect invalid range in Debug Mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98421 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-08-31 Status|UNCONFIRMED |ASSIGNED
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #14 from wschmidt at linux dot ibm.com --- On 8/31/21 11:09 AM, bergner at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 > > --- Comment #13 from Peter Bergner --- > (In reply to Tulio Magno Quites Machado Filho from comment #12) >> There is a chance, that my previous comment is wrong with regards the >> generation of VSX instructions for Power8. >> >> I don't know what the second command means: >> >> $ gcc-11 -mcpu=power10 -dM -E - < /dev/null | grep -E 'VECTOR|VSX|ALTIVEC' >> #define __VSX__ 1 >> #define __ALTIVEC__ 1 >> #define __POWER9_VECTOR__ 1 >> #define __APPLE_ALTIVEC__ 1 >> #define __POWER8_VECTOR__ 1 >> $ gcc-11 -mcpu=power10 -mno-power8-vector -dM -E - < /dev/null | grep -E >> 'VECTOR|VSX|ALTIVEC' >> #define __VSX__ 1 >> #define __ALTIVEC__ 1 >> #define __APPLE_ALTIVEC__ 1 > __VSX__ doesn't mean all of VSX is enabled. IIRC, __VSX__ is the macro you > would use to see whether you have POWER7 VSX support. For POWER8's VSX > support, you'd use __POWER8_VECTOR__, etc. So in your last compile, you > disabled vector support from POWER8 onwards, but that leaves vector support > from POWER7 and earlier, ie, __VSX__ and __ALTIVEC__. If you had used > -mno-vsx, you'd still have __ALTIVEC__ and __APPLE_ALTIVEC__ defined. > Finally, > if you have used -mno-altivec, then you would have disabled all vector > support. > I disagree with that. You should use __VSX__ && _ARCH_PWR9 to check for P9 vector support, etc. The __POWERn_VECTOR__ things really are not great and I wish they had never been added.
[Bug libstdc++/98033] ABA problem in atomic wait
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98033 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2021-08-31 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Confirming this, although maybe we want to close it WONTFIX or WORKSFORME.
[Bug libstdc++/98978] Consider packing _M_Engaged in the tail padding of T in optional<>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98978 Jonathan Wakely changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed||2021-08-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug bootstrap/53504] configure script of platform TLS support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53504 --- Comment #2 from Jonathan Wakely --- Or maybe it's OK. The test is not trying to find out if threading works, only whether TLS works. If creating or joining the thread fails, there is probably a deeper issue. If creating and joining the thread works, then the important part does the right thing. (a_in_other_thread == a_in_main_thread) being false makes the program exit successfully, and we detect that TLS is supported. The likelihood of linking with -pthread succeeding but pthread_create or pthread_join failing is probably low, and so the check works in practice.
[Bug c++/92193] Poor diagnostics when a constexpr function call follows a failed static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92193 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:9aeadd8c319d5d940fa4dc91a393fc2959d27719 commit r12-3258-g9aeadd8c319d5d940fa4dc91a393fc2959d27719 Author: Jason Merrill Date: Mon Aug 30 18:42:05 2021 -0400 c++: Improve error recovery with constexpr [PR92193] The compiler tries to limit error cascades in limit_bad_template_recursion by avoiding triggering a new instantiation from one that has caused errors. We were exempting constexpr functions from this because they can be needed for constant evaluation, but as more and more functions get marked constexpr, this becomes an over-broad category. So as suggested on IRC, this patch only exempts functions that are needed for mandatory constant evaluation. As noted in the comment, this flag doesn't particularly need to use a bit in the FUNCTION_DECL, but there were still some free. PR c++/92193 gcc/cp/ChangeLog: * cp-tree.h (FNDECL_MANIFESTLY_CONST_EVALUATED): New. * constexpr.c (cxx_eval_call_expression): Set it. * pt.c (neglectable_inst_p): Check it. gcc/testsuite/ChangeLog: * g++.dg/diagnostic/static_assert4.C: New test.
[Bug libstdc++/97912] Get rid of location-invariant requirement in std::function small object optimisation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97912 Jonathan Wakely changed: What|Removed |Added Keywords||ABI Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2021-08-31
[Bug bootstrap/53504] configure script of platform TLS support.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53504 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-08-31 Status|UNCONFIRMED |NEW Component|libstdc++ |bootstrap Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- That comes from config/tls.m4 which does not belong to libstdc++., so component=bootstrap. The test was added for PR 28468. I agree the return values look wrong.
[Bug target/101865] _ARCH_PWR8 is not defined when using -mcpu=power8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101865 --- Comment #13 from Peter Bergner --- (In reply to Tulio Magno Quites Machado Filho from comment #12) > There is a chance, that my previous comment is wrong with regards the > generation of VSX instructions for Power8. > > I don't know what the second command means: > > $ gcc-11 -mcpu=power10 -dM -E - < /dev/null | grep -E 'VECTOR|VSX|ALTIVEC' > #define __VSX__ 1 > #define __ALTIVEC__ 1 > #define __POWER9_VECTOR__ 1 > #define __APPLE_ALTIVEC__ 1 > #define __POWER8_VECTOR__ 1 > $ gcc-11 -mcpu=power10 -mno-power8-vector -dM -E - < /dev/null | grep -E > 'VECTOR|VSX|ALTIVEC' > #define __VSX__ 1 > #define __ALTIVEC__ 1 > #define __APPLE_ALTIVEC__ 1 __VSX__ doesn't mean all of VSX is enabled. IIRC, __VSX__ is the macro you would use to see whether you have POWER7 VSX support. For POWER8's VSX support, you'd use __POWER8_VECTOR__, etc. So in your last compile, you disabled vector support from POWER8 onwards, but that leaves vector support from POWER7 and earlier, ie, __VSX__ and __ALTIVEC__. If you had used -mno-vsx, you'd still have __ALTIVEC__ and __APPLE_ALTIVEC__ defined. Finally, if you have used -mno-altivec, then you would have disabled all vector support.
[Bug rtl-optimization/102147] IRA dependent on 32-bit vs 64-bit register size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147 --- Comment #2 from David Edelsohn --- Created attachment 51389 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51389=edit Pre-processed subset of tree-vect-slp.c $ gcc -O2 -fno-exceptions produces different conflicts and register allocation choices if GCC (IRA) is built as 32 bit vs 64 bit compiler.
[Bug target/102107] protocol register (r12) corrupted before a tail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 Segher Boessenkool changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-08-31 Status|UNCONFIRMED |NEW --- Comment #12 from Segher Boessenkool --- So this actually happens during pro_and_epilogue already. Confirmed.
[Bug rtl-optimization/102147] IRA dependent on 32-bit vs 64-bit register size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147 David Edelsohn changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||bergner at gcc dot gnu.org, ||vmakarov at gcc dot gnu.org Last reconfirmed||2021-08-31 --- Comment #1 from David Edelsohn --- Confirmed. This was discovered when bootstrapping 64 bit GCC on AIX using 32 bit GCC. It seems that this should be reproduceable on any system and architecture by overriding the conflicts data structure encoding choice.
[Bug rtl-optimization/102147] New: IRA dependent on 32-bit vs 64-bit register size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102147 Bug ID: 102147 Summary: IRA dependent on 32-bit vs 64-bit register size Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: dje at gcc dot gnu.org Target Milestone: --- IRA heuristics chooses different data structure encodings based on the register size, and this produces different register allocation results. This was discovered by a GCC bootstrap comparison failure of tree-vect-slp.c when using a 32 bit compiler to bootstrap a 64 bit compiler. A difference occurs in ira-conflicts.c: build_object_conflicts(), for the same object with the same properties (i.e., min, max and px are the same), the function ira_conflict_vector_profitable_p() will return 1 by stage1-gcc and 0 by stage2-gcc. stage1-gcc: build_object_conflict obj140(a140) px=4 min=3 max=139 profitable_p=1 stage2-gcc: build_object_conflict obj140(a140) px=4 min=3 max=139 profitable_p=0 That's because the size of ira_object_t being a pointer is different in stage1-gcc (which is 32bit) and stage2-gcc (which is 64bit). My colleagues at ATOS and I aren't completely certain how this difference causes different conflict / allocation behavior because it seems that it should be an optimization. Should the data structure choice / algorithm choice depend on pointer size? Are the two algorithms supposed to generate the same results?
[Bug target/102146] New: [11 regression] several test cases fails after r11-8940
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102146 Bug ID: 102146 Summary: [11 regression] several test cases fails after r11-8940 Product: gcc Version: 11.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: seurer at gcc dot gnu.org Target Milestone: --- :d3d198940e5b527e76da7282cc2ce59045b4844, r11-8940 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lbz_cmpldi_cr0_QI_clobber_CCUNS_zero 2 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lha_cmpdi_cr0_HI_clobber_CC_sign 8 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lhz_cmpldi_cr0_HI_clobber_CCUNS_zero 2 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lwa_cmpdi_cr0_SI_EXTSI_CC_sign 3 FAIL: gcc.target/powerpc/fusion-p10-ldcmpi.c scan-assembler-times lwz_cmpldi_cr0_SI_EXTSI_CCUNS_zero 2 FAIL: gcc.target/powerpc/pr56605.c scan-rtl-dump-times combine "\\(compare:CC \\((?:and|zero_extend):DI \\(reg:[SD]I" 1 FAIL: gcc.target/powerpc/pr81348.c scan-assembler \\mlxsihzx\\M FAIL: gcc.target/powerpc/pr81348.c scan-assembler \\mvextsh2d\\M FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\mlwz\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\mplwz\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\mpstw\\M 2 FAIL: gcc.target/powerpc/prefix-no-update.c scan-assembler-times \\mstw\\M 2 These may just be tests that require adjusting the instruction counts to account for the changes introduced by this commit. commit 7d3d198940e5b527e76da7282cc2ce59045b4844 (HEAD, refs/bisect/bad) Author: Haochen Gui Date: Fri Jun 4 11:04:31 2021 +0800 rs6000: Expand PROMOTE_MODE marco in rs6000_promote_function_mode
[Bug libstdc++/31464] Extension request: publicly visible forward-declaration headers for and all STL containers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31464 Jonathan Wakely changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jonathan Wakely --- C++ Modules will (we hope) provide a better solution to this problem. Adding non-standard and non-portable headers will only make vendor lock-in more likely, as well as being a maintenance burden. It's three days since I fixed a bug in caused by inconsistent forward declarations that didn't match the real definitions. If we did it for the entire library, we'd make such mistakes more often. Given the position above, and that there has been no movement on this in 14 years, I don't think there is any benefit to keeping it open.
[Bug c++/102137] class template argument deduction with template template parameter allows explicit deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102137
Patrick Palka changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #2 from Patrick Palka ---
IMHO it might be good to track them separately since this one affects C++17
code but PR101883 affects only C++20 code (and the fix for the latter is
probably going to get backported).
Here's another accepts-invalid testcase, where the template template parm is
replaced by a dependent initializer:
template struct B { B(int){} }; explicit B(int) -> B;
template void f(T t) { B _ = t; }
void g() { f(0); }
[Bug fortran/102145] New: TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102145 Bug ID: 102145 Summary: TKR mismatches with -pedantic: -fallow-argument-mismatch does not degrade errors to warnings Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: ripero84 at gmail dot com Target Milestone: --- In the presence of -pedantic, -fallow-argument-mismatch fails to degrade the mismatch errors to warnings: $ cat pedt.f90 MODULE M IMPLICIT NONE EXTERNAL :: X CONTAINS SUBROUTINE S(A) COMPLEX :: A(*) CALL X(A) END SUBROUTINE T(A) REAL :: A(*) CALL X(A) END END $ gfortran pedt.f90 -c -o pedt.o -fallow-argument-mismatch # Expected warning pedt.f90:8:11: 8 | CALL X(A) | 1 .. 13 | CALL X(A) | 2 Warning: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/REAL(4)). $ gfortran pedt.f90 -c -o pedt.o -fallow-argument-mismatch -pedantic # Unexpected error pedt.f90:8:11: 8 | CALL X(A) | 1 .. 13 | CALL X(A) | 2 Error: Type mismatch between actual argument at (1) and actual argument at (2) (COMPLEX(4)/REAL(4)). This is: - undocumented; and - unexpected, since it effectively means that by adding -pedantic to a compilation line that already contains -fallow-argument-mismatch, mismatch warnings are upgraded to errors, despite -pedantic is only supposed to issue warnings. It seems that GCC developers have known for years that -pedantic may change warnings to errors in the absence of error-raising flags (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30929#c9), but it is still unclear to me whether this is undocumented or wrong behaviour. Note that there is evidence that -fallow-argument-mismatch is actually being processed: if the compiler finds multiple mismatches involving a given argument, it succeeds in only reporting one of them (as an error, not as the expected warning). I am seeking clarification about whether this is a bug (the combination of -pedantic -fallow-argument-mismatch flags should work differently / be forbidden), a documentation bug (in which case I would appreciate an explanation of the logic behind this, and an update to the documentation), or both, and I would be grateful for the fix(/es). I am aware that -fallow-argument-mismatch is a hack that should be avoided, but since users still need it, its behaviour and documentation should be at least consistent. Note that this issue has already been reported by some Fortran codes: https://github.com/cp2k/cp2k/issues/1019, https://gitlab.com/siesta-project/siesta/-/issues/130 . This seems to affect all versions of gfortran since GCC 10. It would be nice if any updates related to this were ported to the 10.x branch. Thank you for your help.
[Bug c++/102098] ICE when #include with -fmodules-ts -std=c++20 since r11-7530-g1e5cdb9f896fb220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098 --- Comment #5 from Devourer Station --- (In reply to Martin Liška from comment #1) > Please attach the source files.. I'm sorry that the attachment suddenly went missing. I reattached it.
[Bug c++/102098] ICE when #include with -fmodules-ts -std=c++20 since r11-7530-g1e5cdb9f896fb220
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102098 --- Comment #4 from Devourer Station --- Created attachment 51388 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51388=edit preprocessed source file (xz compressed) preprocessed source file (xz compressed)
[Bug c++/102137] class template argument deduction with template template parameter allows explicit deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102137 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ppalka at gcc dot gnu.org Last reconfirmed||2021-08-31 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- This is so close to PR 101883 that I wonder if it shouldn't be closed as a dup and the testcase added there. I'll confirm it and CC Patrick, so he can decide if he thinks it's a dup or a separate issue.
[Bug target/102143] ABI incompatibility with clang when passing 32bit vectors on 32bit i686
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102143 H.J. Lu changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-08-31 Status|UNCONFIRMED |NEW --- Comment #1 from H.J. Lu --- 16-bit and 32-bit vector pass and return are not specified in i386 psABI. 64-bit vector is specified, not really usable. Any suggestions?
[Bug tree-optimization/101145] niter analysis fails for until-wrap condition
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101145 --- Comment #10 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:eca730231d5493647bb1e508fb1f853ffee0e95a commit r12-3255-geca730231d5493647bb1e508fb1f853ffee0e95a Author: Jakub Jelinek Date: Tue Aug 31 15:26:14 2021 +0200 testsuite: Fix gcc.dg/vect/pr101145* tests [PR101145] I'm getting: FAIL: gcc.dg/vect/pr101145.c scan-tree-dump-times vect "vectorized 1 loops" 7 FAIL: gcc.dg/vect/pr101145_1.c scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr101145_2.c scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr101145_3.c scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr101145.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 7 FAIL: gcc.dg/vect/pr101145_1.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr101145_2.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 2 FAIL: gcc.dg/vect/pr101145_3.c -flto -ffat-lto-objects scan-tree-dump-times vect "vectorized 1 loops" 2 on i686-linux (or x86_64-linux with -m32/-mno-sse). The problem is that those tests use dg-options, which in */vect/ testsuite throws away all the carefully added default options to enable vectorization on each target (and which e.g. vect_int etc. effective targets rely on). The old way would be to name those tests gcc.dg/vect/O3-pr101145*, but we can also use dg-additional-options (which doesn't throw the default options, just appends to them) which is IMO better so that we don't have to rename the tests. 2021-08-31 Jakub Jelinek PR tree-optimization/101145 * gcc.dg/vect/pr101145.c: Use dg-additional-options with just -O3 instead of dg-options with -O3 -fdump-tree-vect-details. * gcc.dg/vect/pr101145_1.c: Likewise. * gcc.dg/vect/pr101145_2.c: Likewise. * gcc.dg/vect/pr101145_3.c: Likewise.
[Bug target/102135] (ARM Cortex-M3 and newer) changing operation order may reduce number of instructions needed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102135
--- Comment #1 from Richard Earnshaw ---
A small change to the testcase shows that this is highly dependent on the
constrained registers from the calling convention.
uint64_t foo64(int dummy, const uint8_t *rData1)
{
uint64_t buffer;
buffer = (((uint64_t)rData1[7]) << 56)|((uint64_t)(rData1[6]) <<
48)|((uint64_t)(rData1[5]) << 40)|(((uint64_t)rData1[4]) << 32)|
(((uint64_t)rData1[3]) <<
24)|(((uint64_t)rData1[2]) << 16)|((uint64_t)(rData1[1]) << 8)|rData1[0];
}
Register allocation does not re-order code in order to reduce the conflicts, so
this is not easy to fix.
This is also a problem that is more obvious in micro-testcases such as this
example, in real code it is more common for the register allocator to have more
freedom and to be able to avoid issues like this. If your programming style is
to write functions like this you'd likely get better code overall by marking
these very small functions as inline, so that they do not incur the call setup
and call/return overhead, which can be significant when you take into account
the number of registers that must be saved over a function call.
[Bug target/102107] protocol register (r12) corrupted before a tail call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102107 --- Comment #11 from Paul Clarke --- This does produce the issue for me: -- $ git checkout remotes/vendors/ibm/gcc-11-branch gcc-AT $ mkdir gcc-AT-build $ cd gcc-AT-build $ ../gcc-AT/configure --enable-languages=c,c++ --disable-libada --disable-libsanitizer --disable-libssp --disable-libgomp --disable-libvtv --disable-nls --prefix=/home/pc/gcc-AT-install $ make $ make install $ ~/gcc-AT-install/bin/gcc -S -O3 -mcpu=power10 -fverbose-asm r12test2.c $ grep --before-context=15 bctr r12test2.s mtctr 12 # func, func # r12test2.c:3030: } lwz 12,8(1) #, # r12test2.c:3013: ++*p_format; addi 9,9,1 # tmp251, *p_format_31(D), std 9,0(31) # *p_format_31(D), tmp251 # r12test2.c:3030: } ld 31,-8(1) #, mtcrf 8,12 #, .cfi_restore 72 .cfi_restore 31 .cfi_restore 30 .cfi_restore 28 .cfi_restore 27 # r12test2.c:3014: return (*func)(); bctr # func --
[Bug demangler/102132] [nm] Stack overflow in demangler_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102132 --- Comment #3 from Irfan Ariq --- Okay, I will move it to sourceware bugzilla. Thank you
[Bug demangler/102130] [c++filt] Stack overflow in demangle_path
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102130 --- Comment #2 from Irfan Ariq --- Okay I will move it to the sourceware bugzilla. Thank you.
[Bug bootstrap/100832] s390x-linux-gnu: wrong number of alternatives in the output template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100832 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #2 from Roger Sayle --- I believe this issue was fixed by Ilya's patch back in May. r12-1104-g22d834e32b509b22f68000b7f012d8e45d833ea8
[Bug target/102125] (ARM Cortex-M3 and newer) missed optimization. memcpy not needed operations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102125
--- Comment #5 from Richard Earnshaw ---
Testcase was not quite complete. Extending it to:
typedef unsigned long long uint64_t;
typedef unsigned long uint32_t;
typedef unsigned char uint8_t;
uint64_t bar64(const uint8_t *rData1)
{
uint64_t buffer;
__builtin_memcpy(, rData1, sizeof(buffer));
return buffer;
}
uint32_t bar32(const uint8_t *rData1)
{
uint32_t buffer;
__builtin_memcpy(, rData1, sizeof(buffer));
return buffer;
}
and then looking at the optimized tree output we see:
;; Function bar64 (bar64, funcdef_no=0, decl_uid=4196, cgraph_uid=1,
symbol_order=0)
uint64_t bar64 (const uint8_t * rData1)
{
uint64_t buffer;
uint64_t _4;
[local count: 1073741824]:
__builtin_memcpy (, rData1_2(D), 8);
_4 = buffer;
buffer ={v} {CLOBBER};
return _4;
}
;; Function bar32 (bar32, funcdef_no=1, decl_uid=4200, cgraph_uid=2,
symbol_order=1)
uint32_t bar32 (const uint8_t * rData1)
{
unsigned int _3;
[local count: 1073741824]:
_3 = MEM [(char * {ref-all})rData1_2(D)];
return _3;
}
So in the 32-bit case we've eliminated the memcpy at the tree level, but failed
to do that for 64-bit objects.
We probably need to add 64-bit support to the movmisalign pattern.
[Bug target/101723] arm: incorrect order of .fpu and .arch_extension directives leads to unsupported instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101723 --- Comment #15 from Richard Earnshaw --- (In reply to Christophe Lyon from comment #14) > I think you forgot to backport > r12-2790-ga22b3e022c2b45047a28d901042888eb77620499 to gcc-9 ? I don't think so. I think that patch collapsed away due to the way I ended up resolving a merge conflict in an earlier patch. Are you seeing any test errors due to this?
[Bug fortran/93524] [ISO C Binding][F2018] CFI_allocate – elem_size mishandled + sm wrongly set?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93524 Tobias Burnus changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Tobias Burnus --- (In reply to sandra from comment #7) > Now applied to GCC 11 too. The other two patches referenced in this issue > were put on mainline before GCC 11 branched and not on GCC 10 or any older > branch, so I think I'm done here and the issue can be closed. I concur → close as FIXED on GCC 12/mainline + GCC 11. Thanks! (Related PR 92189, but separate issue and not triggered by the testcase.)
[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92482
Tobias Burnus changed:
What|Removed |Added
Last reconfirmed||2021-08-31
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #6 from Tobias Burnus ---
With my bind-C array descriptor patch, all tests except of
strg_print_2("abc").
(To be submitted; I will include this testcase as
gfortran.dg/bind-c-char-descr.f90
with the failing test commented.)
The still FAILING testcase does *not* use BIND(C) - and only TYPE(*) with
assumed-rank:
That test passes this string to a gfortran array descriptor for type:
type(*), target, intent(in) :: this(..)
which is then
c_f_pointer(c_loc(this), strn)
to a Fortran pointer.
The call has:
scalar.4 = 97; // that's 'a' -> expected: "abc".
desc.3.dtype = {.elem_len=1, .rank=0, .type=1}; // not the elem_len=1;
should be len*kind
desc.3.data = (void *)
desc.3.span = (integer(kind=8)) desc.3.dtype.elem_len;
[Bug tree-optimization/102141] [12 Regression] ICE: with single element vector and the bswap pass at -O2 since r12-3072-gb320edc0c29c838b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102141 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 51387 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51387=edit gcc12-pr102141.patch Untested fix.
[Bug c++/101144] Coroutine compiler error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101144 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2021-08-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug tree-optimization/102131] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #4 from bin cheng ---
(In reply to Jiu Fu Guo from comment #3)
> The issue may come from 'iv0 cmp iv1' transform:
>
>if (c -->if (c>=b) in-loop
> -->if (b<=c) in-loop
>
> c: {4, +, 3}
> b: {1, +, 1}
>
> if ({1, +, 1} <= {4, +, 3})
> ==> if ({1,+,-2} <= {4,+,0}) here, error occur
> ==> if ({1,+,-2} < {5,+,0}) le-->lt
So this duplicates to PR100740? Thanks
[Bug tree-optimization/100089] [11/12 Regression] 30% performance regression for denbench/mp2decoddata2 with -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100089 Bug 100089 depends on bug 102142, which changed state. Bug 102142 Summary: [12 Regression] ICE Segmentation fault since r12-3222-g89f33f44addbf985 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102142 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/102142] [12 Regression] ICE Segmentation fault since r12-3222-g89f33f44addbf985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102142 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Richard Biener --- Fixed.
[Bug tree-optimization/102142] [12 Regression] ICE Segmentation fault since r12-3222-g89f33f44addbf985
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102142 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:67927342290c61d7e054430f1d7a7281f1f97fae commit r12-3250-g67927342290c61d7e054430f1d7a7281f1f97fae Author: Richard Biener Date: Tue Aug 31 11:04:51 2021 +0200 tree-optimization/102142 - fix typo in loop BB reduc cost adjustment This fixes a typo in the condition guarding the cleanup of the visited flag of costed scalar stmts. 2021-08-31 Richard Biener PR tree-optimization/102142 * tree-vect-slp.c (vect_bb_vectorization_profitable_p): Fix condition under which to unset the visited flag. * g++.dg/torture/pr102142.C: New testcase.
[Bug tree-optimization/102139] [11/12 Regression] -O3 miscompile due to slp-vectorize on strict align target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102139
Richard Biener changed:
What|Removed |Added
Target|riscv |riscv, x86_64-*-*
--- Comment #8 from Richard Biener ---
And for a condition:
typedef double aligned_double __attribute__((aligned(2*sizeof(double;
void __attribute__((noipa))
bar (int aligned, double *p)
{
if (aligned)
{
*(aligned_double *)p = 3.;
p[1] = 4.;
}
else
{
p[2] = 0.;
p[3] = 1.;
}
}
double x[8] __attribute__((aligned(2*sizeof (double;
int main()
{
bar (0, [1]);
return 0;
}
[Bug tree-optimization/102139] [11/12 Regression] -O3 miscompile due to slp-vectorize on strict align target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102139
--- Comment #7 from Richard Biener ---
Testcase triggering a segfault on x86_64 and showing the issue inside a single
BB with a function that doesn't return.
void __attribute__((noipa))
foo (int i)
{
if (i)
__builtin_exit (0);
}
typedef double aligned_double __attribute__((aligned(2*sizeof(double;
void __attribute__((noipa))
bar (double *p)
{
p[0] = 0.;
p[1] = 1.;
foo (1);
*(aligned_double *)p = 3.;
p[1] = 4.;
}
double x[4] __attribute__((aligned(2*sizeof (double;
int main()
{
bar ([1]);
return 0;
}
[Bug middle-end/102133] [12 Regression] ICE in set_rtl building libgcc __muldc3 for 32-bit SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102133 --- Comment #10 from Mikael Pettersson --- (In reply to Hongtao.liu from comment #2) > But failed to configure for target mcore, i didn't find any reference in > https://gcc.gnu.org/install/specific.html > > --target=mcore results in > *** Configuration mcore-unknown-none not supported It's mcore-elf or mcore-unknown-elf .
[Bug tree-optimization/102131] [12 Regression] wrong code at -O1 and above on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102131
--- Comment #3 from Jiu Fu Guo ---
The issue may come from 'iv0 cmp iv1' transform:
if (cif (c>=b) in-loop
-->if (b<=c) in-loop
c: {4, +, 3}
b: {1, +, 1}
if ({1, +, 1} <= {4, +, 3})
==> if ({1,+,-2} <= {4,+,0}) here, error occur
==> if ({1,+,-2} < {5,+,0}) le-->lt
