[Bug target/109228] warning: implicit declaration of function '__riscv_vlenb'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109228 --- Comment #3 from JuzheZhong --- Fixed by the following patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-March/614397.html Let's wait for review and merged. Thanks.
[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242
--- Comment #2 from Peter Kasting ---
(In reply to TC from comment #1)
> The missing remove_cv_t is real, but this example is invalid. As the linked
> cppreference page notes, you cannot pass a PMD to transform.
Ah, true! How about this then: https://godbolt.org/z/TaccPEsY1
#include
struct S {
int& i() const;
};
void foo() {
std::optional().transform(::i);
}
[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242 TC changed: What|Removed |Added CC||rs2740 at gmail dot com --- Comment #1 from TC --- The missing remove_cv_t is real, but this example is invalid. As the linked cppreference page notes, you cannot pass a PMD to transform.
[Bug target/85048] [missed optimization] vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #9 from Hongtao.liu ---
With the patch, we can generate optimized code expect for those 16 {u,}qq
cases, since the ABI doesn't support 1024-bit vector.
1 file changed, 16 insertions(+), 2 deletions(-)
gcc/config/i386/sse.md | 18 --
modified gcc/config/i386/sse.md
@@ -8014,8 +8014,9 @@ (define_expand "fixuns_trunc2"
(match_operand:VF1 1 "register_operand")]
"TARGET_SSE2"
{
- if (mode == V16SFmode)
-emit_insn (gen_ufix_truncv16sfv16si2 (operands[0],
+ /* AVX512 support vcvttps2udq for all 128/256/512-bit vectors. */
+ if (mode == V16SFmode || TARGET_AVX512VL)
+emit_insn (gen_ufix_trunc2 (operands[0],
operands[1]));
else
{
@@ -8413,6 +8414,12 @@ (define_insn "*floatv2div2sf2_mask_1"
(set_attr "prefix" "evex")
(set_attr "mode" "V4SF")])
+(define_expand "floatuns2"
+ [(set (match_operand:VF2_512_256VL 0 "register_operand")
+ (unsigned_float:VF2_512_256VL
+ (match_operand: 1 "nonimmediate_operand")))]
+ "TARGET_AVX512F")
+
(define_insn "ufloat2"
[(set (match_operand:VF2_512_256VL 0 "register_operand" "=v")
(unsigned_float:VF2_512_256VL
@@ -8694,6 +8701,13 @@ (define_insn "fix_truncv4dfv4si2"
(set_attr "prefix" "maybe_evex")
(set_attr "mode" "OI")])
+
+/* The standard pattern name is fixuns_truncmn2. */
+(define_expand "fixuns_truncv4dfv4si2"
+ [(set (match_operand:V4SI 0 "register_operand")
+ (unsigned_fix:V4SI (match_operand:V4DF 1 "nonimmediate_operand")))]
+ "TARGET_AVX512VL && TARGET_AVX512F")
+
(define_insn "ufix_truncv4dfv4si2"
[(set (match_operand:V4SI 0 "register_operand" "=v")
(unsigned_fix:V4SI (match_operand:V4DF 1 "nonimmediate_operand"
"vm")))]
[Bug modula2/107630] runtime libs should be self-contained
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107630 --- Comment #4 from CVS Commits --- The master branch has been updated by Gaius Mulley : https://gcc.gnu.org/g:573dbd5175dbf16a3b4551ec55800febf0d1b617 commit r13-6795-g573dbd5175dbf16a3b4551ec55800febf0d1b617 Author: Gaius Mulley Date: Wed Mar 22 01:45:58 2023 + PR modula2/107630 Remove M2LINK and remove some cross linking Remove M2LINK.def. Pass the user forced module initialization string as a parameter to M2RTS.ConstructModules. This patch allows -fm2-whole-program to link successfully using dynamic libraries. gcc/m2/ChangeLog: PR modula2/107630 * Make-lang.in (m2/stage2/cc1gm2$(exeext)): Remove m2/gm2-libs-boot/M2LINK.o. (m2/stage1/cc1gm2$(exeext)): Ditto. (GM2-LIBS-BOOT-DEFS): Remove M2LINK.def. (GM2-LIBS-DEFS): Ditto. (m2/mc-boot/$(SRC_PREFIX)%.o): Replace CXX_FLAGS with CXXFLAGS. (m2/mc-boot-ch/$(SRC_PREFIX)%.o): Ditto. (m2/mc-boot/main.o): Ditto. (mcflex.o): Add $(CFLAGS). (m2/gm2-libs-boot/M2LINK.o): Remove rule. * gm2-compiler/M2GCCDeclare.def (DeclareM2linkGlobals): Remove. * gm2-compiler/M2GCCDeclare.mod: (M2LinkEntry): Remove. (M2LinkIndex): Remove. (DoVariableDeclaration): Remove initial and call to AddEntryM2Link. (AddEntryM2Link): Remove. (GetEntryM2Link): Remove. (DeclareM2linkGlobals): Remove. (DetectM2LinkInitial): Remove. (InitM2LinkModule): Remove. * gm2-compiler/M2GenGCC.mod (CodeFinallyEnd): Remove call to DeclareM2linkGlobals. * gm2-compiler/M2Quads.mod (BuildM2InitFunction): Add extra parameter containing runtime module override to ConstructModules. * gm2-compiler/M2Scaffold.mod: Update comment describing ConstructModules. * gm2-gcc/m2decl.cc (m2decl_DeclareM2linkForcedModuleInitOrder): Remove. * gm2-libs-iso/M2RTS.def (ConstructModules): Add overrideliborder parameter. * gm2-libs-iso/M2RTS.mod: Add overrideliborder parameter. * gm2-libs/M2Dependent.def (ConstructModules): Add overrideliborder parameter. * gm2-libs/M2Dependent.mod (ConstructModules): Add overrideliborder parameter. * gm2-libs/M2RTS.def (ConstructModules): Add overrideliborder parameter. * gm2-libs/M2RTS.mod (ConstructModules): Add overrideliborder parameter. * gm2-libs/M2LINK.def: Removed. libgm2/ChangeLog: * libm2pim/Makefile.am (M2DEFS): Remove M2LINK.def. * libm2pim/Makefile.in: Rebuild. Signed-off-by: Gaius Mulley
[Bug target/85048] [missed optimization] vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #8 from Hongtao.liu ---
(In reply to Hongtao.liu from comment #7)
> Yes, Looks like the pattern name is misdefined.
> it shoud be fixuns_trunc, but we have ufix_trunc.
No, we have the right name but generate extra instructions for uns.
8012(define_expand "fixuns_trunc2"
8013 [(match_operand: 0 "register_operand")
8014 (match_operand:VF1 1 "register_operand")]
8015 "TARGET_SSE2"
8016{
8017 if (mode == V16SFmode)
8018emit_insn (gen_ufix_truncv16sfv16si2 (operands[0],
8019 operands[1]));
8020 else
8021{
8022 rtx tmp[3];
8023 tmp[0] = ix86_expand_adjust_ufix_to_sfix_si (operands[1], [2]);
8024 tmp[1] = gen_reg_rtx (mode);
8025 emit_insn (gen_fix_trunc2 (tmp[1],
tmp[0]));
8026 emit_insn (gen_xor3 (operands[0], tmp[1],
tmp[2]));
8027}
8028 DONE;
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 kargl at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2023-03-22 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Priority|P3 |P4 --- Comment #8 from kargl at gcc dot gnu.org --- Confirmed.
[Bug target/85048] [missed optimization] vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048 Hongtao.liu changed: What|Removed |Added CC||crazylht at gmail dot com --- Comment #7 from Hongtao.liu --- Yes, Looks like the pattern name is misdefined. it shoud be fixuns_trunc, but we have ufix_trunc.
[Bug c++/109243] New: Side cast of pointer-to-member with UB is incorrectly accepted in constant evaluation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109243
Bug ID: 109243
Summary: Side cast of pointer-to-member with UB is incorrectly
accepted in constant evaluation
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: de34 at live dot cn
Target Milestone: ---
The following code snippet is incorrectly accepted by gcc (perhaps in all
versions supporting constexpr) (Godbolt link: https://godbolt.org/z/GqodcGWPe):
```
struct B1 {
char i;
};
struct B2 {
char j;
};
struct D : B1, B2 {};
constexpr auto mp = static_cast(static_cast(::i));
```
According to [expr.static.cast]/13, such static_cast (performing side cast) has
undefined behavior, and should not be accepted as a constant (sub)expression.
(Unfortunately, there're well-defined manners to create a non-null
pointer-to-member with offset -1, see
https://github.com/itanium-cxx-abi/cxx-abi/pull/163).
[Bug c++/109181] requires expression type requirement rejects valid type when it is a nested member template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109181
--- Comment #5 from waffl3x ---
(In reply to Patrick Palka from comment #3)
> A workaround is to just remove the unneeded 'template' after the :: in this
> case. Or is there an example where the template keyword is needed that we
> incorrectly reject?
In my original use case, A in `inline constexpr bool go = requires{typename
A::template B;};` would have been dependent, I included the template
keyword because of that but it should have occurred to me that the example I
presented doesn't need it, I'm not sure what the standard requires for this
sort of thing though.
When I reduce I just remove everything that isn't required to get the result
I'm looking for, I should have realized that changing the semantics of the
example might create confusion and in the future I think I will also include a
reduced version that comes closer to the problem I actually encountered, I
imagine that it will be helpful even if it's not actually the most reduced
version.
I'll try to create an example that reflects my use case better as soon as I
can.
[Bug target/98596] registers not reused on RISC-V
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98596 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement CC||pinskia at gcc dot gnu.org
[Bug target/96297] Redundant zero extension after inlining the function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96297
Andrew Pinski changed:
What|Removed |Added
Severity|normal |enhancement
--- Comment #1 from Andrew Pinski ---
It has nothing to do with inlining either.
Here is a testcase to show that:
int f(unsigned char c) {
return ((c >= '0') & (c <= '9')) ? 0xa : 0;
}
[Bug libstdc++/109242] C++2b std::optional::transform omits required std::remove_cv_t from return optional type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2023-03-21 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug libstdc++/109242] New: C++2b std::optional::transform omits required std::remove_cv_t from return optional type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109242
Bug ID: 109242
Summary: C++2b std::optional::transform omits required
std::remove_cv_t from return optional type
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: pkasting at google dot com
Target Milestone: ---
The implementation of C++2b's std::optional::transform() on HEAD omits a call
to std::remove_cv_t when determining the value type of the returned optional.
As a result valid code such as the following example is rejected:
https://godbolt.org/z/hG5hnz59e
#include
struct S {
int i;
};
void foo() {
std::optional().transform(::i);
}
Per https://en.cppreference.com/w/cpp/utility/optional/transform, the returned
type should always be computed via std::remove_cv_t<> on the invoke_result, but
per
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/std/optional;hb=HEAD,
_Up consistently omits this.
[Bug bootstrap/92709] Cross Compilation failed for Latest GCC riscv64-linux-gnu on Linux/WSL2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92709 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #4 from Andrew Pinski --- No feedback in over 2 years and other folks have done build of this cross compiler since then.
[Bug target/109236] [avr] Invalid code of signed 16-bit compare optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109236 gandalf at winds dot org changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from gandalf at winds dot org --- Thank you, I hadn't thought of that at all. That was precisely my problem and I developed a work-around. Not a bug.
[Bug fortran/104572] ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104572 --- Comment #3 from Steve Kargl --- On Tue, Mar 21, 2023 at 09:02:14PM +, anlauf at gcc dot gnu.org wrote: > --- Comment #2 from anlauf at gcc dot gnu.org --- > (In reply to kargl from comment #1) > > Self explanatory. > > > > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc > > Yes. Either this or: I'm fine with gfortran emitting either error message. As we've both put eyes on the bug, go ahead and use your error message and commit.
[Bug fortran/104572] ICE in gfc_resolve_finalizers, at fortran/resolve.cc:13646
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104572
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Self explanatory.
>
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
Yes. Either this or:
@@ -13986,6 +13995,13 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool
*finalizable)
}
arg = dummy_args->sym;
+ if (!arg)
+ {
+ gfc_error ("Argument of FINAL procedure at %L must be of type %qs",
+>proc_sym->declared_at, derived->name);
+ goto error;
+ }
+
if (arg->as && arg->as->type == AS_ASSUMED_RANK
&& ((list != derived->f2k_derived->finalizers) || list->next))
{
[Bug c++/109241] [13 Regression] ICE Segmentation fault since for ccache package r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241
--- Comment #1 from Andrew Pinski ---
Reduced almost all the way:
```
void g() {
[](auto) {
[]() {
({
struct __attribute__FMT_COMPILE_STRING {};
});
};
}(1);
}
```
[Bug c++/109241] [13 Regression] ICE Segmentation fault since for ccache package r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241 Martin Liška changed: What|Removed |Added Last reconfirmed||2023-03-21 Ever confirmed|0 |1 Priority|P3 |P1 Status|UNCONFIRMED |NEW Target Milestone|--- |13.0
[Bug c++/109241] New: [13 Regression] ICE Segmentation fault since for ccache package r13-6722-gb323f52ccf966800
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109241
Bug ID: 109241
Summary: [13 Regression] ICE Segmentation fault since for
ccache package r13-6722-gb323f52ccf966800
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: marxin at gcc dot gnu.org
CC: jason at redhat dot com
Target Milestone: ---
Reduced from ccache package:
$ cat LocalStorage.ii
template struct integral_constant {
static constexpr int value = __v;
};
template using __enable_if_t = _Tp;
template using __void_t = void;
template _Tp __declval(long);
template auto declval() -> decltype(__declval<_Tp>(0));
template struct __result_of_success;
template struct __result_of_impl;
template
__result_of_success()(declval<_Args>...))> _S_test;
template
struct __result_of_impl {
typedef decltype(_S_test<_Functor, _ArgTypes...>) type;
};
template
struct __invoke_result : __result_of_impl::value,
integral_constant::value,
_Functor, _ArgTypes...> {};
template struct __is_invocable_impl;
template
struct __is_invocable_impl<_Result, _Ret, __void_t>
: integral_constant {};
template class function;
template
using _Requires = __enable_if_t<_Cond::value, _Tp>;
template
struct function<_Res(_ArgTypes...)> {
template >
struct _Callable : __is_invocable_impl<_Res2, _Res> {};
template >>
function(_Functor) {}
};
void for_each_cache_subdir(function)>) {
for_each_cache_subdir([](auto, auto) {
[](auto) {
({
struct __attribute__FMT_COMPILE_STRING {};
});
};
});
}
$ g++ LocalStorage.ii -c
LocalStorage.ii: In instantiation of ‘for_each_cache_subdir(function)>):: [with auto:1 = char (*)(); auto:2 =
function (*)()]’:
LocalStorage.ii:11:44: required from ‘struct __result_of_impl)>)::, char, function >’
LocalStorage.ii:31:10: recursively required by substitution of
‘template struct __is_invocable_impl<_Result, _Ret,
__void_t > [with _Result =
__invoke_result)>)::, char, function >; _Ret =
void]’
LocalStorage.ii:31:10: required from ‘struct function)>::_Callable)>)::,
for_each_cache_subdir(function)>)::, __invoke_result)>)::, char, function > >’
LocalStorage.ii:26:7: required by substitution of ‘template using _Requires = __enable_if_t<_Cond::value, _Tp> [with _Cond =
function)>::_Callable)>)::,
for_each_cache_subdir(function)>)::, __invoke_result)>)::, char, function > >; _Tp =
void]’
LocalStorage.ii:32:32: required by substitution of ‘template function)>::function(_Functor) [with _Functor
= for_each_cache_subdir(function)>)::; = ]’
LocalStorage.ii:36:24: required from here
LocalStorage.ii:38:7: internal compiler error: Segmentation fault
38 | ({
| ^
0x11978cf crash_signal
/home/marxin/Programming/gcc/gcc/toplev.cc:314
0x778b1edf ???
/usr/src/debug/glibc-2.37/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0xb19347 tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/marxin/Programming/gcc/gcc/tree.h:3539
0xb19347 find_parameter_packs_r
/home/marxin/Programming/gcc/gcc/cp/pt.cc:4073
0x14873cd walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.cc:11327
0x1487a40 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
/home/marxin/Programming/gcc/gcc/tree.cc:11442
0xb1b105 check_for_bare_parameter_packs(tree_node*, unsigned int)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:4283
0xb7b5a5 finish_expr_stmt(tree_node*)
/home/marxin/Programming/gcc/gcc/cp/semantics.cc:904
0xb3c3d2 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:18856
0xb3bbb4 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:19204
0xb66e68 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:18810
0xb66e68 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:20203
0xb2f796 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:21715
0xb3977f tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:19872
0xb3ae47 tsubst_expr(tree_node*, tree_node*, int, tree_node*)
/home/marxin/Programming/gcc/gcc/cp/pt.cc:18852
0xb3a201 tsubst_expr(tree_node*, tree_node*, int,
[Bug debug/109237] csmith: another timeout with -g -O3 this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 Andrew Pinski changed: What|Removed |Added Component|middle-end |debug --- Comment #4 from Andrew Pinski --- To give an insight into how much the verifiers give: CFG verifier : 61.10 ( 11%) 3.97 ( 13%) 65.09 ( 11%) 0 ( 0%) ... tree SSA verifier : 39.90 ( 7%) 0.02 ( 0%) 39.93 ( 7%) 0 ( 0%) tree STMT verifier : 141.76 ( 26%) 0.00 ( 0%) 141.95 ( 25%) 0 ( 0%) ... verify RTL sharing : 82.20 ( 15%) 0.00 ( 0%) 82.25 ( 14%) 0 ( 0%) Which is almost due to the number of debug statements (RTL and gimple level). The only way to reduce the cost here is reduce the number of debug statements ...
[Bug middle-end/109237] csmith: another timeout with -g -O3 this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 --- Comment #3 from Andrew Pinski --- cfg cleanup: 10.35 ( 5%) 0.00 ( 0%) 10.36 ( 4%) 7072 ( 0%) trivially dead code: 29.89 ( 14%) 0.00 ( 0%) 29.89 ( 13%) 352 ( 0%) tree CFG cleanup : 10.41 ( 5%) 0.00 ( 0%) 10.44 ( 4%) 90k ( 0%) ... tree operand scan : 11.85 ( 6%) 8.90 ( 32%) 20.93 ( 9%) 4074k ( 0%) ... backwards jump threading : 12.18 ( 6%) 7.53 ( 27%) 19.66 ( 8%) 2549M ( 37%) ... expand : 9.37 ( 4%) 0.35 ( 1%) 9.72 ( 4%) 2177M ( 31%) ... scheduling 2 : 19.13 ( 9%) 3.44 ( 13%) 22.57 ( 10%) 746M ( 11%) ... variable tracking : 6.84 ( 3%) 0.00 ( 0%) 6.84 ( 3%) 27M ( 0%) >From what I can tell it is just there are a lot (much more) more debug statements causing the influence here ... And the slow down is not just in one location either. Note the above is the trunk with --enable-checking=yes but with -fno-checking added to not take into account the gimple verifications which also slow it down even further.
[Bug target/85048] [missed optimization] vector conversions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85048
--- Comment #6 from Matthias Kretz (Vir) ---
Most of the conversions are optimized perfectly now. Only the following
conversions are still missing for AVX-512:
https://godbolt.org/z/9afWbYod6
#include
template
using V [[gnu::vector_size(Size)]] = T;
template V cvt4(V x) {
return V{To(x[0]), To(x[1]), To(x[2]), To(x[3])};
}
template V cvt8(V x) {
return V{
To(x[0]), To(x[1]), To(x[2]), To(x[3]),
To(x[4]), To(x[5]), To(x[6]), To(x[7])
};
}
template V cvt16(V x) {
return V{
To(x[0]), To(x[1]), To(x[2]), To(x[3]),
To(x[4]), To(x[5]), To(x[6]), To(x[7]),
To(x[8]), To(x[9]), To(x[10]), To(x[11]),
To(x[12]), To(x[13]), To(x[14]), To(x[15])
};
}
#define _(name, from, to, size) \
auto name(V x) { return cvt##size(x); }
// integral -> double
_(vcvtudq2pd, uint32_t, double, 4)
_(vcvtudq2pd, uint32_t, double, 8)
// integral -> float
_(vcvtqq2ps , int64_t, float, 16)
_(vcvtuqq2ps, uint64_t, float, 16)
// float -> integral
_(vcvttps2qq, float, int64_t, 16)
_( cvttps2udq, float, uint32_t, 4)
_(vcvttps2udq, float, uint32_t, 8)
_(vcvttps2uqq, float, uint64_t, 16)
// double -> integral
_(vcvttpd2udq, double, uint32_t, 4)
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
--- Comment #7 from Steve Kargl ---
On Tue, Mar 21, 2023 at 12:27:58PM -0700, Steve Kargl wrote:
>
> So, there is a chunk of code in decl.cc(4682-4689 or so),
>
> if (implicit_flag == 1)
> {
> if (matched_type && gfc_match_char (')') != MATCH_YES)
> return MATCH_ERROR;
>
> return MATCH_YES;
> }
>
> causing the problem. The implicit_flag == 1 conditional was
> added in 2004 (revision e5ddaa24beae) to check for 'IMPLICIT
> CHARACTER'. The code block was updated in revision 0fb56814562a
> when 'TYPE(intrinsic-type-spec)' was added to gfortran.
>
> I have no idea how this was suppose to work.
Well, I figured that out. The code allows
'implicit real (a-z)'
to be parsed and compiled. The downside is that it
blocks OP's code. A simplied code
program testit
! implicit real(a-z) ! Works
! implicit real(4) (a-z) ! Works
implicit type(real(4)) (a-z) ! Whoops.
type(real(4)) :: quad
if (kind(quad) /= 4) stop 1
end program testit
So, 'type(intrinsic-type-spec)' seems to be broken
when placed in 'implicit type(intrinsic-type-spec)'.
[Bug middle-end/109237] csmith: another timeout with -g -O3 this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 --- Comment #2 from Andrew Pinski --- Note it seems worse with checking enabled as it is verification that takes a long time.
[Bug fortran/97592] [10/11/12/13 Regression] Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/97592] [10/11/12/13 Regression] Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||7.5.0, 8.5.0 Keywords||wrong-code Summary|Incorrectly set pointer |[10/11/12/13 Regression] |remapping with array|Incorrectly set pointer |pointer argument to |remapping with array |CONTIGUOUS dummy|pointer argument to ||CONTIGUOUS dummy Target Milestone|--- |10.5 Known to fail||10.4.0, 11.3.0, 12.2.0, ||13.0, 9.5.0 --- Comment #4 from anlauf at gcc dot gnu.org --- Adding known-to-work, known-to-fail versions.
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
--- Comment #6 from Steve Kargl ---
On Tue, Mar 21, 2023 at 02:57:49PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223
>
> --- Comment #5 from kargl at gcc dot gnu.org ---
> (In reply to urbanjost from comment #4)
> > User-defined types work and as I read the ISO standard are supported, and
> > TYPE(REAL) works; it is only when a parameter is added that it fails;
> > nvfortran fails for user-defined type declared below it but it works with
> > one defined via a USE from a module; while gfortran allows the type to be
> > defined after the use,
> > but I consider that a nvfortran bug myself.
>
> Ah, yeah, you're right. I failed to follow the EBNF in R864.
> It seems that gfortran is getting tripped up with the character
> following the basic type name, ie., the kind selector part.
>
So, there is a chunk of code in decl.cc(4682-4689 or so),
if (implicit_flag == 1)
{
if (matched_type && gfc_match_char (')') != MATCH_YES)
return MATCH_ERROR;
return MATCH_YES;
}
causing the problem. The implicit_flag == 1 conditional was
added in 2004 (revision e5ddaa24beae) to check for 'IMPLICIT
CHARACTER'. The code block was updated in revision 0fb56814562a
when 'TYPE(intrinsic-type-spec)' was added to gfortran.
I have no idea how this was suppose to work.
[Bug tree-optimization/109240] New: Missed fneg/fsub optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109240
Bug ID: 109240
Summary: Missed fneg/fsub optimization
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: avieira at gcc dot gnu.org, burnus at gcc dot gnu.org,
jakub at gcc dot gnu.org, marxin at gcc dot gnu.org,
tnfchris at gcc dot gnu.org
Depends on: 109230
Target Milestone: ---
Host: aarch64-linux-gnu
Target: aarch64-linux-gnu
+++ This bug was initially created as a clone of Bug #109230 +++
On aarch64 we optimize at -O2 only half of the following routines:
typedef float V __attribute__((vector_size (4 * sizeof (float;
typedef int VI __attribute__((vector_size (4 * sizeof (float;
__attribute__((noipa)) V
foo (V x, V y)
{
V a = x - y;
V b = y + x;
return __builtin_shuffle (b, a, (VI) { 0, 5, 2, 7 });
}
__attribute__((noipa)) V
bar (V x, V y)
{
V a = x - y;
V b = y + x;
return __builtin_shuffle (a, b, (VI) { 4, 1, 6, 3 });
}
__attribute__((noipa)) V
baz (V x, V y)
{
V a = x - y;
V b = y + x;
return __builtin_shuffle (b, a, (VI) { 4, 1, 6, 3 });
}
__attribute__((noipa)) V
qux (V x, V y)
{
V a = x - y;
V b = y + x;
return __builtin_shuffle (a, b, (VI) { 0, 5, 2, 7 });
}
__attribute__((noipa)) V
boo (V x, V y)
{
V a = x + y;
V b = y - x;
return __builtin_shuffle (b, a, (VI) { 0, 5, 2, 7 });
}
__attribute__((noipa)) V
corge (V x, V y)
{
V a = x + y;
V b = y - x;
return __builtin_shuffle (a, b, (VI) { 4, 1, 6, 3 });
}
__attribute__((noipa)) V
fred (V x, V y)
{
V a = x + y;
V b = y - x;
return __builtin_shuffle (b, a, (VI) { 4, 1, 6, 3 });
}
__attribute__((noipa)) V
garply (V x, V y)
{
V a = x + y;
V b = y - x;
return __builtin_shuffle (a, b, (VI) { 0, 5, 2, 7 });
}
starting with r13-4024-gb2bb611d90d01f64a24 (plus r13-4122-g1bc7efa948f751
bugfix).
The other half could be handled similarly, just with fneg+fsub rather than
fneg+fadd.
Unfortunately, match.pd canonicalizes those, we still have 0, 5, 2, 7
permutations for all of them, but the two operations swapped. Unfortunately
match.pd doesn't allow :c
on vec_perm, and if we use (for op (plus minus)
otherop (minus plus)
then we couldn't add :c to the plus one. So, copy and paste the whole large
simplification, swap (plus:c @0 @1) and (minus @0 @1) and replace (plus at the
end with (minus? Or handle the commutativity manually?
(for op (plus minus)
otherop (minus plus)
(simplify
(vec_perm (op @0 @1) (otherop @2 @3) VECTOR_CST@4)
and use operand_equal_p manually to allow all forms we want?
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
[Bug 109230] [13 Regression] Maybe wrong code for opus package on aarch64 since
r13-4122-g1bc7efa948f751
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #17 from Jakub Jelinek --- Created attachment 54725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54725=edit gcc13-pr109230.patch Full untested patch.
[Bug analyzer/109239] New: -Wanalyzer-deref-before-check seen on Linux kernel due to inlining with -fno-delete-null-pointer-checks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109239
Bug ID: 109239
Summary: -Wanalyzer-deref-before-check seen on Linux kernel due
to inlining with -fno-delete-null-pointer-checks
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Target Milestone: ---
Created attachment 54724
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54724=edit
Reproducer
I'm seeing various -Wanalyzer-deref-before-check false positives on the Linux
kernel; hopefully the attached is a representative reproducer for all of them.
When compiled with:
-fanalyzer -fno-delete-null-pointer-checks -O2
trunk falsely complains:
In function 'bus_get',
inlined from 'bus_remove_file' at :122:7,
inlined from 'remove_probe_files' at :139:3,
inlined from 'bus_unregister' at :150:3:
:105:6: warning: check of 'bus' for NULL after already dereferencing it
[-Wanalyzer-deref-before-check]
105 | if (bus) {
| ^
'bus_unregister': events 1-2
|
| 147 | if (bus->dev_root)
| | ~~~^~
| | |
| | (1) pointer 'bus' is dereferenced here
|..
| 150 | remove_probe_files(bus);
| | ~
| | |
| | (2) inlined call to 'remove_probe_files' from 'bus_unregister'
|
+--> 'remove_probe_files': event 3
|
| 139 | bus_remove_file(bus, _attr_drivers_autoprobe);
| | ^
| | |
| | (3) inlined call to 'bus_remove_file' from
'remove_probe_files'
|
+--> 'bus_remove_file': event 4
|
| 122 | if (bus_get(bus)) {
| | ^
| | |
| | (4) inlined call to 'bus_get' from
'bus_remove_file'
|
+--> 'bus_get': event 5
|
| 105 | if (bus) {
| | ^
| | |
| | (5) pointer 'bus' is checked for NULL
here but it was already dereferenced at (1)
|
Compiler returned: 0
Trunk: https://godbolt.org/z/ErKf6fz86
[Bug c++/108795] [10/11/12/13 Regression] ICE in prep_operand, at cp/call.cc:6325 since r7-2549-gf3365c1201908df5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108795 Jason Merrill changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109238 --- Comment #1 from Andrew Pinski --- c = realloc (p, -1); ... ; if (c != ((void *)0) ) support_exit_failure_impl (1, "tst-realloc.c", 120, "realloc (p, -1) succeeded."); c = p; ... p = realloc (p, 0);
[Bug target/109236] [avr] Invalid code of signed 16-bit compare optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109236 Dimitar Dimitrov changed: What|Removed |Added CC||dimitar at gcc dot gnu.org --- Comment #1 from Dimitar Dimitrov --- Pass the -Wstrict-overflow=4 option to GCC and see that compiler assumes no integer overlow will happen: test.c:3:12: warning: assuming signed overflow does not occur when simplifying 'X - Y <= 0' to 'X <= Y' [-Wstrict-overflow] 3 | return (x-y <= 0); Consider using "__builtin_sub_overflow" for a strictly defined behaviour when integer overflow happens.
[Bug fortran/99036] [11/12/13 Regression] ICE in gfc_current_interface_head, at fortran/interface.c:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99036 --- Comment #11 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:dd282b16bfd3c6e218dffb7798a375365b10ae22 commit r13-6790-gdd282b16bfd3c6e218dffb7798a375365b10ae22 Author: Harald Anlauf Date: Tue Mar 21 19:58:31 2023 +0100 Fortran: reject MODULE PROCEDURE outside generic module interface [PR99036] gcc/fortran/ChangeLog: PR fortran/99036 * decl.cc (gfc_match_modproc): Reject MODULE PROCEDURE if not in a generic module interface. gcc/testsuite/ChangeLog: PR fortran/99036 * gfortran.dg/pr99036.f90: New test.
[Bug tree-optimization/109238] [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109238 Martin Liška changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-03-21 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=109170 Target Milestone|--- |13.0 Ever confirmed|0 |1
[Bug tree-optimization/109238] New: [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109238 Bug ID: 109238 Summary: [13 Regression] tst-realloc.i:42:19: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] in glibc tests Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: rguenth at gcc dot gnu.org Target Milestone: --- Created attachment 54723 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54723=edit Unreduced test-case It's the same issue as PR109170 this time in glibc's test-suite: [ 1569s] gcc tst-realloc.c -c -std=gnu11 -fgnu89-inline -O2 -Wall -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -g -Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math -fstack-protector-strong -fno-common -Wstrict-prototypes -Wold-style-definition -fmath-errno-fPIE -fcf-protection -I../include -I/home/abuild/rpmbuild/BUILD/glibc-2.37.9000.180.g9e2ff880f3/cc-base/malloc -I/home/abuild/rpmbuild/BUILD/glibc-2.37.9000.180.g9e2ff880f3/cc-base -I../sysdeps/unix/sysv/linux/x86_64/64 -I../sysdeps/unix/sysv/linux/x86_64 -I../sysdeps/unix/sysv/linux/x86/include -I../sysdeps/unix/sysv/linux/x86 -I../sysdeps/x86/nptl -I../sysdeps/unix/sysv/linux/wordsize-64 -I../sysdeps/x86_64/nptl -I../sysdeps/unix/sysv/linux/include -I../sysdeps/unix/sysv/linux -I../sysdeps/nptl -I../sysdeps/pthread -I../sysdeps/gnu -I../sysdeps/unix/inet -I../sysdeps/unix/sysv -I../sysdeps/unix/x86_64 -I../sysdeps/unix -I../sysdeps/posix -I../sysdeps/x86_64/64 -I../sysdeps/x86_64/fpu/multiarch -I../sysdeps/x86_64/fpu -I../sysdeps/x86/fpu -I../sysdeps/x86_64/multiarch -I../sysdeps/x86_64 -I../sysdeps/x86/include -I../sysdeps/x86 -I../sysdeps/ieee754/float128 -I../sysdeps/ieee754/ldbl-96/include -I../sysdeps/ieee754/ldbl-96 -I../sysdeps/ieee754/dbl-64 -I../sysdeps/ieee754/flt-32 -I../sysdeps/wordsize-64 -I../sysdeps/ieee754 -I../sysdeps/generic -I.. -I../libio -I. -D_LIBC_REENTRANT -include /home/abuild/rpmbuild/BUILD/glibc-2.37.9000.180.g9e2ff880f3/cc-base/libc-modules.h -DMODULE_NAME=testsuite -include ../include/libc-symbols.h -DPIC -DTOP_NAMESPACE=glibc -DTEST_NO_MALLOPT -o /home/abuild/rpmbuild/BUILD/glibc-2.37.9000.180.g9e2ff880f3/cc-base/malloc/tst-realloc.o -MD -MP -MF /home/abuild/rpmbuild/BUILD/glibc-2.37.9000.180.g9e2ff880f3/cc-base/malloc/tst-realloc.o.dt -MT /home/abuild/rpmbuild/BUILD/glibc-2.37.9000.180.g9e2ff880f3/cc-base/malloc/tst-realloc.o [ 1569s] In function 'do_test', [ 1569s] inlined from 'legacy_test_function' at ../test-skeleton.c:55:10: [ 1569s] tst-realloc.c:135:7: error: pointer 'p' may be used after 'realloc' [-Werror=use-after-free] [ 1569s] 135 | p = realloc (p, 0); [ 1569s] | ^~ [ 1569s] tst-realloc.c:117:7: note: call to 'realloc' here [ 1569s] 117 | c = realloc (p, -1); [ 1569s] | ^~~ [ 1569s] tst-realloc.c:127:12: error: pointer 'p' may be used after 'realloc' [-Werror=use-after-free] [ 1569s] 127 | if (c[i] != 0xff) [ 1569s] |^ [ 1569s] tst-realloc.c:117:7: note: call to 'realloc' here [ 1569s] 117 | c = realloc (p, -1); $ gcc tst-realloc.i -c -O2 -Wall -Werror In function ‘do_test’, inlined from ‘legacy_test_function’ at ../test-skeleton.c:55:10: tst-realloc.c:135:7: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] tst-realloc.c:117:7: note: call to ‘realloc’ here tst-realloc.c:127:12: error: pointer ‘p’ may be used after ‘realloc’ [-Werror=use-after-free] tst-realloc.c:117:7: note: call to ‘realloc’ here cc1: all warnings being treated as errors
[Bug preprocessor/109183] [regression?] since GCC 11.1, -MM -MMD generates "a-" prefixed dependency files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109183 Yann Droneaud changed: What|Removed |Added CC||yann at droneaud dot fr --- Comment #2 from Yann Droneaud --- gcc -MM -MMD seems to behave like gcc -dumpbase a -MM -MMD test.c or gcc -dumpdir a- -MM -MMD test.c
[Bug modula2/109125] [13 regression] SIGBUS in m2pim_ldtoa_ldtoa
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109125 Gaius Mulley changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Gaius Mulley --- Thanks for the bug reports - closing as all resolved.
[Bug middle-end/109237] csmith: another timeout with -g -O3 this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 David Binderman changed: What|Removed |Added Keywords||needs-bisection, ||needs-reduction --- Comment #1 from David Binderman --- It looks as if this bug has existed for more than a year or so: $ (ulimit -t 300; time ~/gcc/results.20220403/bin/gcc -c -w -g -O3 bug901.c) gcc: fatal error: Killed signal terminated program cc1 compilation terminated. real5m3.060s user4m56.316s sys 0m4.150s $
[Bug c/109237] New: csmith: another timeout with -g -O3 this time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109237 Bug ID: 109237 Summary: csmith: another timeout with -g -O3 this time Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 54722 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54722=edit C source code The attached C code, when compiled by -O3, seems to take a reasonable time: $ time ~/gcc/results/bin/gcc -c -w -O3 bug901.c real0m0.619s user0m0.597s sys 0m0.012s But adding -g seems to cause trouble: $ (ulimit -t 120; time ~/gcc/results/bin/gcc -c -w -g -O3 bug901.c) gcc: fatal error: Killed signal terminated program cc1 compilation terminated. real2m1.255s user1m58.650s sys 0m1.593s $ ~/gcc/results/bin/gcc -v 2>&1 | fgrep exp gcc version 13.0.1 20230321 (experimental) (0963cb5fde158cce) So the version I used seems to include today's patch from Andrew Macleod for timing reduction.
[Bug c++/109177] Call to C++ function marked unavailable gets diagnosed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109177
--- Comment #4 from Alex Coplan ---
(In reply to Patrick Palka from comment #3)
> FWIW one way to test against duplicate errors currently is something like:
>
> void f() __attribute__((unavailable)); // { dg-bogus "is unavailable.*is
> unavailable" }
> // { dg-error "is unavailable" "" { target *-*-* } .-1 }
Thanks, that's helpful. I suppose it would be nice if DejaGnu could be modified
(or perhaps configured) so that errors are only matched at most once, but that
seems unlikely to happen and it would be awkward to coordinate across projects.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #16 from Jakub Jelinek --- --- gcc/match.pd.jj 2023-02-18 12:38:30.967022708 +0100 +++ gcc/match.pd2023-03-21 17:24:54.964665797 +0100 @@ -8096,6 +8096,7 @@ and, scalar_mode inner_mode = GET_MODE_INNER (vec_mode); } (if (sel.series_p (0, 2, 0, 2) + && sel.series_p (1, 2, nelts + 1, 2) && GET_MODE_2XWIDER_MODE (inner_mode).exists (_elt_mode) && multiple_p (GET_MODE_NUNITS (vec_mode), 2, _nunits) && related_vector_mode (vec_mode, wide_elt_mode, seems to indeed fix this.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2023-03-21 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #15 from Jakub Jelinek --- I'll handle this.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #7 from Jakub Jelinek --- > No luck reproducing this using a cross. Ok, so I'll continue with the reghunt. > So, could you please attach -fdump-tree-optimized -da dumps from both runs? Sure. Even compressed with xz, the tarballs are too large for bugzilla, so I've placed them at https://www.cebitec.uni-bielefeld.de/~ro/files/ti.s2.tar.xz https://www.cebitec.uni-bielefeld.de/~ro/files/ti.s3.tar.xz > Also, check if you are using the same d21 binary, another possibility might be > miscompiled d21. Both the dumps and the objects/assembler output were created with the same d21 binary, just the -fno-checking/-fchecking=1 difference.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #14 from Jakub Jelinek ---
I think series_p clearly documents that:
/* Return true if index OUT_BASE + I * OUT_STEP selects input
element IN_BASE + I * IN_STEP. For example, the call to test
whether a permute reverses a vector of N elements would be:
series_p (0, 1, N - 1, -1)
which would return true for { N - 1, N - 2, N - 3, ... }.
The calls to test for an interleaving of elements starting
at N1 and N2 would be:
series_p (0, 2, N1, 1) && series_p (1, 2, N2, 1).
which would return true for { N1, N2, N1 + 1, N2 + 1, ... }. */
bool
vec_perm_indices::series_p (unsigned int out_base, unsigned int out_step,
element_type in_base, element_type in_step) const
So, if you want to catch permutation { 0, nelts, 2, nelts + 2, 4, nelts + 4,
... }
then I think you need sel.series_p (0, 2, 0, 2) && sel.series_p (1, 2, nelts +
1, 2).
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #13 from Martin Liška ---
Jakub, you are too fast! Anyway, nice test-case. So far I was able to come to
something semi-reduced:
typedef struct {
float r;
float i;
} kiss_fft_cpx;
kiss_fft_cpx *kf_bfly2_Fout, *opus_fft_impl_Fout2;
int opus_fft_impl_tw;
void
opus_fft_impl() {
float t_0 = (0 + opus_fft_impl_Fout2[1].i) * opus_fft_impl_tw;
float t_1 = (opus_fft_impl_Fout2[1].i - opus_fft_impl_Fout2[1].r) *
opus_fft_impl_tw;
opus_fft_impl_Fout2[1].r = kf_bfly2_Fout[1].r - t_0;
opus_fft_impl_Fout2[1].i = kf_bfly2_Fout[1].i - t_1;
kf_bfly2_Fout[1].r += t_0;
kf_bfly2_Fout[1].i += t_1;
}
[Bug c++/109177] Call to C++ function marked unavailable gets diagnosed twice
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109177
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #3 from Patrick Palka ---
FWIW one way to test against duplicate errors currently is something like:
void f() __attribute__((unavailable)); // { dg-bogus "is unavailable.*is
unavailable" }
// { dg-error "is unavailable" "" { target *-*-* } .-1 }
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #12 from Jakub Jelinek ---
Full self-contained testcase, PASSes with -O0, FAILs on aarch64-linux with -O2:
#if __SIZEOF_FLOAT__ == __SIZEOF_INT__
typedef float V __attribute__((vector_size (4 * sizeof (float;
typedef int VI __attribute__((vector_size (4 * sizeof (float;
__attribute__((noipa)) V
foo (V x, V y)
{
V a = x - y;
V b = y + x;
return __builtin_shuffle (b, a, (VI) { 0, 5, 2, 3 });
}
int
main ()
{
V a = (V) { 1.0f, 2.0f, 3.0f, 4.0f };
V b = (V) { 8.0f, 9.0f, 10.0f, 11.0f };
V c = foo (a, b);
if (c[0] != 9.0f || c[1] != -7.0f || c[2] != 13.0f || c[3] != 15.0f)
__builtin_abort ();
}
#else
int
main ()
{
}
#endif
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #11 from Tamar Christina --- Neither of those vec_perms are valid targets for this optimization. It looks like sel.series_p is not doing what I expected. It's matching even elements and ignoring the odd ones.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #10 from Jakub Jelinek ---
So are we talking about
typedef float V __attribute__((vector_size (16)));
typedef int VI __attribute__((vector_size (16)));
V
foo (V x, V y)
{
V a = x - y;
V b = y + x;
return __builtin_shuffle (b, a, (VI) { 0, 5, 2, 3 });
}
then?
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #9 from avieira at gcc dot gnu.org --- Hmm I was seeing the change in opus_ifft but that does look like different codegen :/ I might not be looking at the right thing. That transformation looks definitely wrong though as the selection selects 3 values from the first vector (which is the result of the plus), and the fneg would negate 2 values right?
[Bug analyzer/109225] -Wanalyzer-null-dereference false negative with *c = 404
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109225 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- Using -O0 basically prevents any analysis regarding a loop. I'm not sure if "-O0 -fanalyzer" really makes any sense. The test cases works with -O2.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #8 from Martin Liška ---
Where I see the following change in optimized dump:
float _423;
float _424;
float _425;
+ vector(4) float _442;
+ vector(2) double _443;
void * _742;
unsigned int _743;
const struct kiss_fft_state * _744;
@@ -383,6 +385,7 @@
long unsigned int _914;
unsigned long _919;
void * _927;
+ vector(2) double _930;
struct kiss_fft_cpx * _935;
sizetype _936;
unsigned long _941;
@@ -530,13 +533,14 @@
_89 = _88 * 7.07106769084930419921875e-1;
_866 = {_76, _75, _86, _89};
_868 = {_74, _78, _86, _89};
- vect__93.89_859 = vect__56.86_870 - _866;
vect__93.89_858 = vect_t_r_54.81_878 - _867;
vect__93.89_857 = vect__56.87_869 - _868;
vect__60.88_864 = _865 + vect__56.85_871;
- vect__60.88_863 = _866 + vect__56.86_870;
vect__60.88_861 = _868 + vect__56.87_869;
- _855 = VEC_PERM_EXPR ;
+ _930 = VIEW_CONVERT_EXPR(_866);
+ _443 = -_930;
+ _442 = VIEW_CONVERT_EXPR(_443);
+ _855 = _442 + vect__56.86_870;
_853 = VEC_PERM_EXPR ;
MEM [(float *)Fout_512] = vect__60.88_864;
MEM [(float *)Fout_512 + 16B] = _855;
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #7 from Martin Liška --- I've just isolated that to celt/kiss_fft.c, can you confirm the change comes from the file?
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #7 from Jakub Jelinek --- No luck reproducing this using a cross. So, could you please attach -fdump-tree-optimized -da dumps from both runs? Also, check if you are using the same d21 binary, another possibility might be miscompiled d21.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230
--- Comment #6 from avieira at gcc dot gnu.org ---
Thanks!
My initial investigation has lead me to think the change is being caused at
vrp2, which is the only time the pattern gets triggered with -O2, the tree
before the pass (at the place where the transformation happens):
vect__83.466_787 = VEC_PERM_EXPR ;
vect__87.467_786 = vect__81.462_791 * vect__83.466_787;
vect__91.469_784 = vect__84.458_794 - vect__87.467_786;
vect__88.468_785 = vect__84.458_794 + vect__87.467_786;
_783 = VEC_PERM_EXPR ;
...
vect__96.470_782 = vect__95.450_800 - _783;
after the pass:
vect__83.466_787 = VEC_PERM_EXPR ;
vect__87.467_786 = vect__83.466_787 * vect__81.462_791;
vect__91.469_784 = vect__84.458_794 - vect__87.467_786;
vect__88.468_785 = vect__87.467_786 + vect__84.458_794;
_756 = VIEW_CONVERT_EXPR(vect__87.467_786);
_755 = -_756;
_739 = VIEW_CONVERT_EXPR(_755);
_783 = _739 + vect__84.458_794;
...
vect__96.470_782 = vect__95.450_800 - _783;
So before we had:
_783 = the first element of vect_88 and the second element of vect__91
these are respectively
vect__88 = vect__84 + vect__87
vect__91 = vect__84 - vect__87
so _783 = {vect__84[0] + vect__87[0], vect__84[1] - vect__87[1]}
after the pass
_783 = _739 + vect__84
This is where I don't know if I'm reading the optimization correctly, but it
says all 'even' lanes are negated, does that mean we end up with:
_739 = { -vect__87[0] , vect__87[1]}
if so then that's why we have a wrong result as you want to negate lane 1 not
0. Otherwise if lane 1 is the one that gets negated then it should be OK as
you'd get:
so _783 = { vect__87[0] + vect__84[0], -vect__87[1] + vect__84[1] }
Now obviously that's assuming -a + b == b - a (not sure if that's true with
floating point errors etc)
[Bug c++/85973] [[nodiscard]] on class shall emit a warning for unused anonymous variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2023-03-21
Ever confirmed|0 |1
Summary|[[nodiscard]] shall emit a |[[nodiscard]] on class
|warning for unused |shall emit a warning for
|anonymous variable |unused anonymous variable
Status|UNCONFIRMED |NEW
--- Comment #3 from Andrew Pinski ---
Reduced testcase:
```
struct [[nodiscard]] scope_exit {
scope_exit(int);
};
int main()
{
scope_exit{0};
}
```
Note if we move the attribute to the constructor, then GCC will error out.
[Bug c++/85973] [[nodiscard]] shall emit a warning for unused anonymous variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973 Andrew Pinski changed: What|Removed |Added CC||t...@bang-olufsen.dk --- Comment #2 from Andrew Pinski --- *** Bug 109235 has been marked as a duplicate of this bug. ***
[Bug c++/109235] nodiscard attribute on class not copied to the constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #5 from Andrew Pinski --- Dup of bug 85973. *** This bug has been marked as a duplicate of bug 85973 ***
[Bug c++/85973] [[nodiscard]] shall emit a warning for unused anonymous variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85973 Andrew Pinski changed: What|Removed |Added CC||johelegp at gmail dot com --- Comment #1 from Andrew Pinski --- *** Bug 95454 has been marked as a duplicate of this bug. ***
[Bug c++/95454] type-level nodiscard not applied to constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95454 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #4 from Andrew Pinski --- Dup of bug 85973. *** This bug has been marked as a duplicate of bug 85973 ***
[Bug c++/109235] nodiscard attribute on class not copied to the constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 --- Comment #4 from Andrew Pinski --- (In reply to Andrew Pinski from comment #3) > If we move the nodiscard to the constructor, GCC errors out correctly. That is true even on the original testcase.
[Bug c++/109235] nodiscard attribute on class not copied to the constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 Andrew Pinski changed: What|Removed |Added Summary|nodiscard attribute ignored |nodiscard attribute on |on temporary created|class not copied to the ||constructors --- Comment #3 from Andrew Pinski --- If we move the nodiscard to the constructor, GCC errors out correctly.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 --- Comment #5 from Martin Liška --- Steps to reproduce: $ wget https://archive.mozilla.org/pub/opus/opus-1.3.1.tar.gz $ tar xvzf opus-1.3.1.tar.gz $ cd opus-1.3.1/ $ ./configure $ make -j32 && make -j32 check So it fails even with default options that are: -g -O2 -fvisibility=hidden -D_FORTIFY_SOURCE=2 -W -Wall -Wextra -Wcast-align -Wnested-externs -Wshadow -Wstrict-prototypes
[Bug c++/109235] nodiscard attribute ignored on temporary created
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235
Andrew Pinski changed:
What|Removed |Added
Keywords||diagnostic
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Last reconfirmed||2023-03-21
Summary|nodiscard attribute ignored |nodiscard attribute ignored
|with deduction guide|on temporary created
--- Comment #2 from Andrew Pinski ---
This has nothing to do with deduction guides either.
Reduced testcase:
```
struct [[nodiscard]] scope_exit {
scope_exit(int);
};
int main()
{
scope_exit{0};
}
```
[Bug c++/109235] nodiscard attribute ignored with deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 --- Comment #1 from Andrew Pinski --- Created attachment 54721 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54721=edit Full testcase with -std=c++20 Please attach the testcase next time or put it inline and not just a link to godbolt .
[Bug c/109236] New: [avr] Invalid code of signed 16-bit compare optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109236
Bug ID: 109236
Summary: [avr] Invalid code of signed 16-bit compare
optimization
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gandalf at winds dot org
Target Milestone: ---
I'm seeing incorrect code when -O1 or higher is used on AVR (atmega1284p). The
compiler generates code that compares "x" to "y", instead of performing the
subtraction and comparing against 0. This subtraction matters since "x" and "y"
are signed 16-bit variables, and the math in the expression "x-y <= 0" stays as
16-bit in AVR (as opposed to being promoted to 32-bit ints in e.g. x86).
gcc -v:
Using built-in specs.
Reading specs from /usr/local/avr/lib/gcc/avr/12.2.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/local/avr/libexec/gcc/avr/12.2.0/lto-wrapper
Target: avr
Configured with: ../configure --target=avr --prefix=/usr/local/avr
--disable-nls --enable-languages=c --disable-bootstrap --disable-libssp
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 12.2.0 (GCC)
Sample code:
_Bool compare(short x, short y)
{
return (x-y <= 0);
}
Compiled using: gcc -O1 -mmcu=atmega1284p -c -o test.o test.c
ASM result:
:
0: 9c 01 movwr18, r24
2: 81 e0 ldi r24, 0x01 ; 1
4: 62 17 cp r22, r18< X compared directly to Y;
no subtraction
6: 73 07 cpc r23, r19
8: 04 f4 brge.+0 ; 0xa
a: 80 e0 ldi r24, 0x00 ; 0
000c <.L2>:
c: 08 95 ret
I instead expect to see a subtraction between r22:23 and r18:19, then a compare
against r1 (zero).
The following testcase causes an incorrect computation:
compare(-30737, 24799) returns 1 on AVR; expected 0. (-30737 - (24799)) as
signed 16-bit = 1, which is not <= 0.
For the record, changing the function to "return ((short)(x-y) <= 0)" produces
the same incorrect code.
Compiling the function without optimization correctly returns 0.
It's possible other signed variable sizes besides 16-bit have the same problem,
but I did not test this.
[Bug c++/109235] New: nodiscard attribute ignored with deduction guide
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109235 Bug ID: 109235 Summary: nodiscard attribute ignored with deduction guide Product: gcc Version: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: t...@bang-olufsen.dk Target Milestone: --- I have tried implementing std::experimental::scope_exit and since this is a RAII object, I marked it with [[nodiscard]] to ensure all instances are assigned to a variable. It appears, however, that GCC ignores the nodiscard attribute when a deduction guide is present. See this Godbolt link for an example: https://godbolt.org/z/v9e8dqW1o Notice how Clang correctly flags the problem.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #6 from Rainer Orth --- Created attachment 54720 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54720=edit sparc-sun-solaris2.11 auto-host.h
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #5 from Jakub Jelinek --- (In reply to r...@cebitec.uni-bielefeld.de from comment #4) > It might be that this is hard to reproduce in a cross: as I mentioned, > the failure only happens with gas natively and I'm uncertain if the > configure tests distinguishing those two all work properly in a cross. Could you then also attach auto-host.h ?
[Bug c++/106890] [10/11/12/13 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106890 --- Comment #2 from CVS Commits --- The trunk branch has been updated by Jason Merrill : https://gcc.gnu.org/g:041a164ec9b467f9ac2f15980f83f17e3f8ea150 commit r13-6788-g041a164ec9b467f9ac2f15980f83f17e3f8ea150 Author: Jason Merrill Date: Sat Mar 18 08:27:26 2023 -0400 c++: DMI in template with virtual base [PR106890] When parsing a default member init we just build a CONVERT_EXPR for converting to a virtual base, and then expand that into the more complex form when we actually use the DMI in a constructor. But that wasn't working for the template case where we are considering the conversion at the point that the constructor needs the DMI instantiation, so it seemed like we were in a constructor already. And then when the other constructor tries to reuse the instantiation, it sees uses of the first constructor's parameters, and dies. So ensure that we get the CONVERT_EXPR in this case, too. PR c++/106890 gcc/cp/ChangeLog: * init.cc (maybe_instantiate_nsdmi_init): Don't leave current_function_decl set to a constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template25.C: New test.
[Bug fortran/109223] parameters for a type on IMPLICIT do not work. For example: IMPLICIT TYPE(REAL(KIND=REAL128)) fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109223 --- Comment #5 from kargl at gcc dot gnu.org --- (In reply to urbanjost from comment #4) > User-defined types work and as I read the ISO standard are supported, and > TYPE(REAL) works; it is only when a parameter is added that it fails; > nvfortran fails for user-defined type declared below it but it works with > one defined via a USE from a module; while gfortran allows the type to be > defined after the use, > but I consider that a nvfortran bug myself. Ah, yeah, you're right. I failed to follow the EBNF in R864. It seems that gfortran is getting tripped up with the character following the basic type name, ie., the kind selector part.
[Bug target/109137] [12/13 regression] Compiling ffmpeg with -m32 on x86_64-pc-linux-gnu hangs on libavcodec/h264_cabac.c since r12-9086-g489c81db7d4f75
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109137 --- Comment #15 from Vladimir Makarov --- I've reproduced hanging up but for the particular commit. I also reproduced internal compiler error on the current master. I'll try to fix the both problems on this week.
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus --- (In reply to avieira from comment #3) > Hi Martin, what options do you build these tests with? Clicking on the link for the glm package (and then "download logfile") shows for instance the following (I have not checked whether a certain fine is compiled differently): /usr/bin/c++ -I/home/abuild/rpmbuild/BUILD/glm-0.9.9.8 -mbranch-protection=standard -O2 -Wall -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=3 -fstack-protector-strong -funwind-tables -fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -flto=auto -g -fPIC -fno-strict-aliasing -O2 -g -DNDEBUG -O2 -Wno-long-long -MD
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 avieira at gcc dot gnu.org changed: What|Removed |Added CC||avieira at gcc dot gnu.org --- Comment #3 from avieira at gcc dot gnu.org --- Hi Martin, what options do you build these tests with?
[Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232 --- Comment #2 from Andrew Pinski --- clang does not emit the function but does emit the warning ...
[Bug driver/109234] gcc refuses compilation with implausible error when using -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109234 --- Comment #2 from Jakub Jelinek --- Are you sure this isn't some Ubuntu customization? Can't reproduce with 12.2.1 20230320 nor 12.1.1 20220507 (Red Hat 12.1.1-1).
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #4 from ro at CeBiTec dot Uni-Bielefeld.DE --- "jakub at gcc dot gnu.org" writes: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 > > --- Comment #3 from Jakub Jelinek --- > Can you find out the gdc and d21 invocation lines for those 2 cases? sure (with -v -save-temps added): * stage 2, -fno-checking: /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/gdc -B/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -fno-checking -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -nostdinc -I /vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -c /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -v -save-temps -fPIC -fversion=Shared -o rt/util/.libs/typeinfo.o /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/d21 /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -mcpu=v9 -g -O2 -Wall -version -fno-checking -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /var/gcc/regression/master/11.4-gcc-gas/build/gcc/../lib/gcc/sparc-sun-solaris2.11/13.0.1/ -isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include -isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include-fixed -nostdinc -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -I /vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -v -o rt/util/.libs/typeinfo.s * stage 3, -fchecking=1 /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/gdc -B/var/gcc/regression/master/11.4-gcc-gas/build/./gcc/ -B/vol/gcc/sparc-sun-solaris2.11/bin/ -B/vol/gcc/sparc-sun-solaris2.11/lib/ -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -fchecking=1 -fversion=Shared -Wall -frelease -ffunction-sections -fdata-sections -O2 -g -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -nostdinc -I /vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -c /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -fPIC -fversion=Shared -o rt/util/typeinfo.o -v -save-temps /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/d21 /vol/gcc/src/hg/master/local/libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/ -dumpbase typeinfo.d -dumpbase-ext .d -mcpu=v9 -g -O2 -Wall -version -fchecking=1 -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /var/gcc/regression/master/11.4-gcc-gas/build/gcc/../lib/gcc/sparc-sun-solaris2.11/13.0.1/ -isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include -isystem /var/gcc/regression/master/11.4-gcc-gas/build/./gcc/include-fixed -nostdinc -isystem /vol/gcc/sparc-sun-solaris2.11/include -isystem /vol/gcc/sparc-sun-solaris2.11/sys-include -I /vol/gcc/src/hg/master/local/libphobos/libdruntime -I . -v -o rt/util/typeinfo. > I've tried to test it using a cross-compiler: It might be that this is hard to reproduce in a cross: as I mentioned, the failure only happens with gas natively and I'm uncertain if the configure tests distinguishing those two all work properly in a cross. FWIW, I'm currently running a reghunt to identify the culprit. However, a single step takes 1h25...
[Bug driver/109234] gcc refuses compilation with implausible error when using -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109234 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2023-03-21 Ever confirmed|0 |1 --- Comment #1 from Andrew Pinski --- Works on the trunk. This looks to be a bug in Ubuntu's compiler so you should report it to them really since that is where you got the binary.
[Bug c/109234] New: gcc refuses compilation with implausible error when using -fprofile-arcs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109234 Bug ID: 109234 Summary: gcc refuses compilation with implausible error when using -fprofile-arcs Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: konstantin.priesnitz at de dot bosch.com Target Milestone: --- Command: touch empty.c gcc -save-temps=obj -fprofile-arcs -pthread -c empty.c Result: cc1: error: unknown profile update method ‘prefer-atomic-fasynchronous-unwind-tables’ cc1: note: valid arguments to ‘-fprofile-update=’ are: atomic prefer-atomic single Expected: Running without error. gcc version: $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/12/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 12.2.0-3ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-12/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr --with-gcc-major-version-only --program-suffix=-12 --program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib --enable-libphobos-checking=release --with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch --disable-werror --enable-cet --with-arch-32=i686 --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic --enable-offload-targets=nvptx-none=/build/gcc-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-nvptx/usr,amdgcn-amdhsa=/build/gcc-12-U8K4Qv/gcc-12-12.2.0/debian/tmp-gcn/usr --enable-offload-defaulted --without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix Supported LTO compression algorithms: zlib zstd gcc version 12.2.0 (Ubuntu 12.2.0-3ubuntu1)
[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192 --- Comment #11 from Richard Biener --- (In reply to Richard Biener from comment #6) > On a fast machine compile eventually finishes and a time-report looks like > > dominator optimization : 156.84 ( 52%) 0.00 ( 0%) 156.86 ( > 52%) 112k ( 1%) > backwards jump threading : 145.15 ( 48%) 0.00 ( 0%) 145.15 ( > 48%)70k ( 0%) > TOTAL : 302.15 0.02302.19 > 16M With the fix in it's now dominator optimization : 0.01 ( 4%) 0.00 ( 0%) 0.00 ( 0%) 112k ( 1%) backwards jump threading : 0.00 ( 0%) 0.00 ( 0%) 0.04 ( 13%) 70k ( 0%) Thanks a lot (for reporting and for fixing)
[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192 Andrew Macleod changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from Andrew Macleod --- fixed.
[Bug tree-optimization/109192] [13 Regression] timeout with -O3 since r13-5579
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109192 --- Comment #9 from CVS Commits --- The master branch has been updated by Andrew Macleod : https://gcc.gnu.org/g:0963cb5fde158cce986523a90fa9edc51c881f31 commit r13-6787-g0963cb5fde158cce986523a90fa9edc51c881f31 Author: Andrew MacLeod Date: Mon Mar 20 16:11:12 2023 -0400 Terminate GORI calculations if a relation is not relevant. We currently allow VARYING lhs GORI calculations to continue if there is a relation present in the hope it will eventually better refine a result. This adds a check that the relation is relevant to the outgoing range calculation first. If it is not relevant, stop calculating. PR tree-optimization/109192 * gimple-range-gori.cc (gori_compute::compute_operand_range): Terminate gori calculations if a relation is not relevant. * value-relation.h (value_relation::set_relation): Allow equality between op1 and op2 if they are the same.
[Bug c/109233] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233
--- Comment #2 from Uroš Bizjak ---
As can be seen from the preprocessed file, tp->irq_max is set to:
tp->irq_max = 1;
or
tp->irq_max = (4 + 1);
and the compilation warns in tg3_init_one at:
for (i = 0; i < tp->irq_max; i++) {
struct tg3_napi *tnapi = >napi[i];
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #3 from Jakub Jelinek --- Can you find out the gdc and d21 invocation lines for those 2 cases? I've tried to test it using a cross-compiler: /usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -g -O2 -Wall -version -fchecking=1 -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem /home/jakub/src/gcc/obj62/./gcc/include -isystem /home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime -I . -v -o /tmp/typeinfo.s1 /usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -g -O2 -Wall -version -fno-checking -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem /home/jakub/src/gcc/obj62/./gcc/include -isystem /home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime -I . -v -o /tmp/typeinfo.s2 /usr/src/gcc/objs4/gcc/d21 ../../../../libphobos/libdruntime/rt/util/typeinfo.d -quiet -dumpdir rt/util/.libs/ -dumpbase typeinfo.d -dumpbase-ext .d -O2 -Wall -version -fno-checking -fversion=Shared -frelease -ffunction-sections -fdata-sections -fpreview=dip1000 -fpreview=fieldwise -fpreview=dtorfields -fPIC -fversion=Shared -iprefix /home/jakub/src/gcc/obj62/gcc/../lib/gcc/x86_64-pc-linux-gnu/13.0.1/ -isystem /home/jakub/src/gcc/obj62/./gcc/include -isystem /home/jakub/src/gcc/obj62/./gcc/include-fixed -nostdinc -isystem /usr/local/x86_64-pc-linux-gnu/include -isystem /usr/local/x86_64-pc-linux-gnu/sys-include -I ../../../../libphobos/libdruntime -I . -v -o /tmp/typeinfo.s3 but don't see assembly differences in any of that. objs4/gcc/d21 is ../configure --target sparc-sun-solaris2.12 (but I'm playing with stuff in x86_64-linux libdruntime tree because I have no idea what all d21 needs...).
[Bug c/109233] warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 --- Comment #1 from Uroš Bizjak --- Created attachment 54719 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54719=edit Preprocessed file -O2 -Warray-bounds: In function ‘tg3_init_one’, inlined from ‘tg3_init_one’ at drivers/net/ethernet/broadcom/tg3.c:17542:12: drivers/net/ethernet/broadcom/tg3.c:17787:37: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds=] In file included from drivers/net/ethernet/broadcom/tg3.c:72: drivers/net/ethernet/broadcom/tg3.h: In function ‘tg3_init_one’: drivers/net/ethernet/broadcom/tg3.h:3203:18: note: while referencing ‘napi’ In function ‘tg3_init_one’, inlined from ‘tg3_init_one’ at drivers/net/ethernet/broadcom/tg3.c:17542:12: drivers/net/ethernet/broadcom/tg3.c:17787:37: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Warray-bounds=] drivers/net/ethernet/broadcom/tg3.h: In function ‘tg3_init_one’: drivers/net/ethernet/broadcom/tg3.h:3203:18: note: while referencing ‘napi’
[Bug c/109233] New: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109233 Bug ID: 109233 Summary: warning: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: ubizjak at gmail dot com Target Milestone: --- There is another bogus array bounds warning when compiling linux in: drivers/net/ethernet/broadcom/tg3.c: In function ‘tg3_init_one’: drivers/net/ethernet/broadcom/tg3.c:17787:51: error: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Werror=array-bounds=] 17787 | struct tg3_napi *tnapi = >napi[i]; | ^~~ In file included from drivers/net/ethernet/broadcom/tg3.c:72: drivers/net/ethernet/broadcom/tg3.h:3203:41: note: while referencing ‘napi’ 3203 | struct tg3_napi napi[TG3_IRQ_MAX_VECS]; | ^~~~ drivers/net/ethernet/broadcom/tg3.c:17787:51: error: array subscript 5 is above array bounds of ‘struct tg3_napi[5]’ [-Werror=array-bounds=] 17787 | struct tg3_napi *tnapi = >napi[i]; | ^~~ drivers/net/ethernet/broadcom/tg3.h:3203:41: note: while referencing ‘napi’ 3203 | struct tg3_napi napi[TG3_IRQ_MAX_VECS]; | ^~~~ cc1: all warnings being treated as errors
[Bug tree-optimization/109213] [13 Regression] -Os generates significantly more code since r13-723
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109213 Richard Biener changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #6 from Richard Biener --- t.c:26:5: missed: not inlinable: main/7 -> m/6, --param large-stack-frame-growth limit reached and after the DSE: IPA function summary for main/7 inlinable global time: 38.636364 self size: 11 global size: 11 min size: 8 self stack: 0 global stack:0 IPA function summary for m/6 inlinable global time: 86.705545 self size: 22 global size: 22 min size: 19 self stack: 264 global stack:264 vs. IPA function summary for main/7 inlinable global time: 42.636364 self size: 14 global size: 14 min size: 11 self stack: 40 global stack:40 without the DSE. And we apply the limit in a quite complicated way in caller_growth_limits, changing mains stack size to 1 or 4 doesn't help, so it isn't a totally arbitrary special-casing of zero caller stack size. I'm leaning towards a WONTFIX or reclassify as non-regression. The bug is definitely not that we now do more DSE, the pre-existing bug might be that we take the absolute size of the caller stack into account.
[Bug c++/109232] Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232 Richard Biener changed: What|Removed |Added Keywords||link-failure --- Comment #1 from Richard Biener --- maybe it's implementation defined or unspecified whether instantiation happens?
[Bug tree-optimization/109230] [13 Regression] Maybe wrong code for opus package on aarch64 since r13-4122-g1bc7efa948f751
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109230 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.0
[Bug c++/109232] New: Using deduced return type in an unevaluated context leads to codegen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109232
Bug ID: 109232
Summary: Using deduced return type in an unevaluated context
leads to codegen
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rs2740 at gmail dot com
Target Milestone: ---
auto begin(auto&& r) {
return r.begin();
}
namespace {
struct R {
int* begin();
};
}
static_assert(__is_same(decltype(begin(R())), int*));
int main() {}
Even though ::begin is only used in an unevaluated context, GCC at -O0
generates code for begin, leading to a warning and a failure to link
(https://gcc.godbolt.org/z/cdajoP7f3):
:10:14: warning: 'int* {anonymous}::R::begin()' used but never defined
10 | int* begin();
| ^
/opt/compiler-explorer/gcc-trunk-20230320/bin/../lib/gcc/x86_64-linux-gnu/13.0.1/../../../../x86_64-linux-gnu/bin/ld:
/tmp/cc7gqEhh.o: in function `auto begin<(anonymous namespace)::R&>((anonymous
namespace)::R&)':
:2: undefined reference to `(anonymous namespace)::R::begin()'
collect2: error: ld returned 1 exit status
Execution build compiler returned: 1
[Bug tree-optimization/109219] [12/13 Regression] csmith: ice in vect_slp_analyze_node_operations_1, at tree-vect-slp.cc:5954 since r13-1106-g8c2733e16ec1c0cd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109219 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:26adc870e3675591050f37edab46850b97a3c122 commit r13-6786-g26adc870e3675591050f37edab46850b97a3c122 Author: Richard Biener Date: Tue Mar 21 12:49:36 2023 +0100 tree-optimization/109219 - avoid looking at STMT_SLP_TYPE The following avoids looking at STMT_SLP_TYPE apart from the only place needing it - transform and analysis of non-SLP loop stmts. In particular it doesn't have a reliable meaning on SLP representatives which are also passed as stmt_vinfo to vectorizable_* routines. The proper way to check in those is to look for the slp_node argument instead. PR tree-optimization/109219 * tree-vect-loop.cc (vectorizable_reduction): Check slp_node, not STMT_SLP_TYPE. * tree-vect-stmts.cc (vectorizable_condition): Likewise. * tree-vect-slp.cc (vect_slp_analyze_node_operations_1): Remove assertion on STMT_SLP_TYPE. * gcc.dg/torture/pr109219.c: New testcase.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE --- > --- Comment #1 from Jakub Jelinek --- > Is that with -g vs. non--g? > Could be NEXT_INSN vs. next_nondebug_insn in combine_reload_insn. No, it's just -fno-checking in stage 2 vs -fchecking=1 in stage 3, no other changes.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Is that with -g vs. non--g? Could be NEXT_INSN vs. next_nondebug_insn in combine_reload_insn.
[Bug testsuite/108898] [13 Regression] Test introduced by r13-6278-g3da77f217c8b2089ecba3eb201e727c3fcdcd19d failed on i386
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108898
--- Comment #7 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:49a8bce43cdc1d1b48efa5eeb2a4097cfca1dc22
commit r13-6785-g49a8bce43cdc1d1b48efa5eeb2a4097cfca1dc22
Author: Jakub Jelinek
Date: Tue Mar 21 13:42:51 2023 +0100
testsuite: Remove obsolete comments [PR108898]
On Tue, Mar 21, 2023 at 12:35:19PM +, Andrew Stubbs wrote:
> > /* Ensure the the in-branch simd clones are used on targets that
support them.
> > Some targets use another call for the epilogue loops. */
> > -/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone}
2 "vect" { target { ! aarch64*-*-* } } } } */
> > -/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone}
3 "vect" { target aarch64*-*-* } } } */
> > +/* { dg-final { scan-tree-dump-times {[\n\r] [^\n]* = foo\.simdclone}
2 "vect" } } */
>
> I suppose those comments are now obsolete.
Oops, fixed thusly.
2023-03-21 Jakub Jelinek
PR testsuite/108898
* gcc.dg/vect/vect-simd-clone-16.c: Remove parts of comment
mentioning
epilogue loops.
* gcc.dg/vect/vect-simd-clone-17.c: Likewise.
* gcc.dg/vect/vect-simd-clone-18.c: Likewise.
[Bug d/109231] [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 Rainer Orth changed: What|Removed |Added Target Milestone|--- |13.0
[Bug d/109231] New: [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109231 Bug ID: 109231 Summary: [13 regression] Comparison failure in libphobos/libdruntime/rt/util/typeinfo.o Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: ro at gcc dot gnu.org Target Milestone: --- Host: sparc-sun-solaris2.11 Target: sparc-sun-solaris2.11 Build: sparc-sun-solaris2.11 Between 20230317 (2bb71424636fba7944b36b1689e9df22a53f1a3f) and 20230320 (fbd50e867e6a782c7b56c9727bf7e1e74dae4b94), Solaris/SPARC bootstrap broke with a comparison failure: Comparing stages 2 and 3 Bootstrap comparison failure! sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/.libs/typeinfo.o differs sparc-sun-solaris2.11/libphobos/libdruntime/rt/util/typeinfo.o differs make[2]: *** [Makefile:32772: compare] Error 1 For some reason, this only happens when using gas, not with the native as. elfcmp shows *** section: [244].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTfTfZQBb7compareMxFIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T20TypeInfoArrayGenericTfTfZQBb7compareMxFIPvIQdZi() < 0x40:+0x40: 83 aa 4a a8 fcmpes%fcc1, %f9, %f8 > 0x40:+0x40: 81 aa 4a a8 fcmpes%fcc0, %f9, %f8 *** section: [245].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTdTdZQBb7compareMxFIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T20TypeInfoArrayGenericTdTdZQBb7compareMxFIPvIQdZi() < 0x34:+0x34: 81 aa 0a 48 fcmpd %fcc0, %d8, %d8 > 0x34:+0x34: 83 aa 0a 48 fcmpd %fcc1, %d8, %d8 *** section: [246].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility17__c_complex_floatTQBjZQCk7compareMxFIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility17__c_complex_floatTQBjZQCk7compareMxFIPvIQdZi() < 0x3c:+0x3c: 87 aa 0a 28 fcmps %fcc3, %f8, %f8 > 0x3c:+0x3c: 81 aa 0a 28 fcmps %fcc0, %f8, %f8 *** section: [247].text._D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility18__c_complex_doubleTQBkZQCl7compareMxFIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T20TypeInfoArrayGenericTEQBsQBs7utility18__c_complex_doubleTQBkZQCl7compareMxFIPvIQdZi() < 0x3c:+0x3c: 83 aa 0a 48 fcmpd %fcc1, %d8, %d8 > 0x3c:+0x3c: 85 aa 0a 48 fcmpd %fcc2, %d8, %d8 *** section: [248].text._D2rt4util8typeinfo__T15TypeInfoGenericTfTfZQw7compareMxFNaNbNeIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T15TypeInfoGenericTfTfZQw7compareMxFNaNbNeIPvIQdZi() < 0x8:+0x8: 87 aa 0a 28 fcmps %fcc3, %f8, %f8 > 0x8:+0x8: 81 aa 0a 28 fcmps %fcc0, %f8, %f8 *** section: [249].text._D2rt4util8typeinfo__T15TypeInfoGenericTdTdZQw7compareMxFNaNbNeIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T15TypeInfoGenericTdTdZQw7compareMxFNaNbNeIPvIQdZi() < 0x8:+0x8: 85 aa 0a 48 fcmpd %fcc2, %d8, %d8 > 0x8:+0x8: 87 aa 0a 48 fcmpd %fcc3, %d8, %d8 *** section: [250].text._D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility17__c_complex_floatTQBjZQCf7compareMxFNaNbNeIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility17__c_complex_floatTQBjZQCf7compareMxFNaNbNeIPvIQdZi() < 0x8:+0x8: 83 aa 0a 28 fcmps %fcc1, %f8, %f8 > 0x8:+0x8: 85 aa 0a 28 fcmps %fcc2, %f8, %f8 *** section: [251].text._D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility18__c_complex_doubleTQBkZQCg7compareMxFNaNbNeIPvIQdZi: data information differs --- : _D2rt4util8typeinfo__T15TypeInfoGenericTEQBnQBn7utility18__c_complex_doubleTQBkZQCg7compareMxFNaNbNeIPvIQdZi() < 0x8:+0x8: 87 aa 0a 48 fcmpd %fcc3, %d8, %d8 > 0x8:+0x8: 81 aa 0a 48 fcmpd %fcc0, %d8, %d8 *** section: [284].text._D4core8internal5array8equality__T8__equalsTxE2rt4util7utility17__c_complex_floatTxQBmZQCbFNaNbNiNfMAxQCfMQgZb: data information differs --- : _D4core8internal5array8equality__T8__equalsTxE2rt4util7utility17__c_complex_floatTxQBmZQCbFNaNbNiNfMAxQCfMQgZb() < 0x44:+0x44: 85 aa 4a 28 fcmps %fcc2, %f9, %f8 > 0x44:+0x44: 87 aa 4a 28 fcmps %fcc3, %f9, %f8 *** section: [287].text._D4core8internal5array8equality__T8__equalsTxE2rt4util7utility18__c_complex_doubleTxQBnZQCcFNaNbNiNfMAxQCgMQgZb: data information differs --- : _D4core8internal5array8equality__T8__equalsTxE2rt4util7utility18__c_complex_doubleTxQBnZQCcFNaNbNiNfMAxQCgMQgZb() < 0x44:+0x44: 81 aa 8a 48 fcmpd %fcc0, %d10, %d8 > 0x44:+0x44: 83 aa 8a 48 fcmpd %fcc1, %d10, %d8 *** section: [295].text._D4core8internal4hash__T13coalesceFloatTfZQsFNaNbNiNfxfZf: data information differs --- : _D4core8internal4hash__T13coalesceFloatTfZQsFNaNbNiNfxfZf() <
[Bug tree-optimization/109184] [10/11/12/13 Regression] csmith: 2017 bug with -floop-interchange
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109184
--- Comment #13 from Richard Biener ---
Testcase with just the essential stuff.
static int g_1731[7] = { 42, 0, 0, 0, 0, 0, 42 };
void __attribute__((noipa)) foo ()
{
int l_1930[5] = { 0, };
for (int i = 0; i < 15; ++i)
for (int j = 4; (j >= 1); j -= 1)
#pragma GCC unroll 0
for (int k = 0; (k <= 4); k += 1)
g_1731[(j + 1)] = --l_1930[k];
}
int main()
{
foo ();
if (g_1731[0] != 42
|| g_1731[1] != 0 || g_1731[2] != -60 || g_1731[3] != -59
|| g_1731[4] != -58 || g_1731[5] != -57
|| g_1731[6] != 42)
__builtin_abort ();
return 0;
}
The innermost loop body then is
[local count: 894749066]:
# k_26 = PHI
# ivtmp_23 = PHI
_1 = l_1930[k_26];
_2 = _1 + -1;
l_1930[k_26] = _2;
g_1731[_6] = _2;
k_17 = k_26 + 1;
ivtmp_21 = ivtmp_23 - 1;
if (ivtmp_21 != 0)
one should note that for data dependence analysis we'd usually need to
treat scalars (in this case SSA names) as arrays of the size of the
whole nest iteration domain and the dependences would be between
statements, not reads/writes. So the above is
_1 = l_1930[k_26];
_2[i] = _1 + -1;
l_1930[k_26] = _2[i];
g_1731[_6] = _2[i];
then and when we interchange the loop we suddenly need two different
_2[] elements and when eliminating _2[] there's a dependence between
the l_1930 store and the implied load from a different iteration.
Note that when l_1930[k] wouldn't be stored to g_1731[j+1] the
interchange would be of course valid and we do not want to break
that case.
