[Bug target/109414] RISC-V: unnecessary sext.w in rv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109414 --- Comment #4 from Sinan --- (In reply to Andrew Pinski from comment #1) > Actually this more related to WORD_REGISTER_OPERATIONS . > > (insn 7 4 8 2 (set (reg:SI 77) > (plus:SI (subreg/s/u:SI (reg/v:DI 74 [ x ]) 0) > (const_int 1 [0x1]))) "/app/example.cpp":3:12 -1 > (nil)) > > GCC then thinks that is an add on all 64bit which is not true ... Hi Andrew, thanks for the info. I don't see anything things we could do for WORD_REGISTER_OPERATIONS. Maybe we still need to handle these insn case by case in the backend?
[Bug target/109415] No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 --- Comment #1 from Andrew Pinski --- I don't see why there should be a define here? The command line will be different between the two so you could just stick a -DXYZ somewhere or handle it in a header file.
[Bug preprocessor/109415] New: No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109415 Bug ID: 109415 Summary: No predefined macros to differentiate between ARM Cortex-M33 and Cortex-M55 Product: gcc Version: 11.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: Vedant.VijayYevale at infineon dot com Target Milestone: --- there is no reliable way to differentiate between CM33 and CM55. For both CM33 and CM55 __ARM_ARCH_8M_MAIN__ is defined. there should be updated compiler predefined macro for CM55.
[Bug target/109414] RISC-V: unnecessary sext.w in rv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109414 --- Comment #3 from Andrew Pinski --- (In reply to Sinan from comment #2) > commit 23d9f62c50d935462ecda5516746037a474c25cd looks like a solution for > this. r13-4150-g23d9f62c50d935
[Bug target/109414] RISC-V: unnecessary sext.w in rv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109414 --- Comment #2 from Sinan --- commit 23d9f62c50d935462ecda5516746037a474c25cd looks like a solution for this. like adding a new pattern for `not` ``` (define_insn "*one_cmpl_subreg" [(set (match_operand:DI 0 "register_operand" "=r") (not:DI (sign_extend:DI (match_operand:SI 1 "register_operand" " r"] "TARGET_64BIT && !partial_subreg_p (operands[1])" "not\t%0,%1" [(set_attr "type" "logical") (set_attr "mode" "SI")]) ``` but somehow it does not work for xor/or/and ...
[Bug target/109414] RISC-V: unnecessary sext.w in rv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109414 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement --- Comment #1 from Andrew Pinski --- Actually this more related to WORD_REGISTER_OPERATIONS . (insn 7 4 8 2 (set (reg:SI 77) (plus:SI (subreg/s/u:SI (reg/v:DI 74 [ x ]) 0) (const_int 1 [0x1]))) "/app/example.cpp":3:12 -1 (nil)) GCC then thinks that is an add on all 64bit which is not true ...
[Bug target/109414] New: RISC-V: unnecessary sext.w in rv64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109414
Bug ID: 109414
Summary: RISC-V: unnecessary sext.w in rv64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sinan.lin at linux dot alibaba.com
Target Milestone: ---
I recently encountered several suboptimal cases with unnecessary sext.w in
not/and/xor/or in rv64i.
e.g.
```
int xor_2 (int x, int n) {
return (x + 1) ^ n;
}
int not_2 (int x, int n) {
return ~(x + n);
}
```
gcc:
```
xor_2:
addiw a0,a0,1
xor a0,a1,a0
sext.w a0,a0
ret
not_2:
addwa0,a0,a1
not a0,a0
sext.w a0,a0
ret
```
clang:
```
xor_2:
addwa0, a0, a1
xor a0, a0, a1
ret
not_2:
addwa0, a0, a1
not a0, a0
ret
```
This case looks a bit similar to
https://gcc.gnu.org/bugzilla//show_bug.cgi?id=106585 , where the X iterator is
used in insn pattern.
[Bug target/109399] RISC-V: RVV VSETVL PASS backward demand fusiton bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109399 --- Comment #1 from CVS Commits --- The master branch has been updated by Jeff Law : https://gcc.gnu.org/g:fdc5abbdcfb65d415af6c40230f8f07872e51e49 commit r13-7008-gfdc5abbdcfb65d415af6c40230f8f07872e51e49 Author: Juzhe-Zhong Date: Tue Apr 4 19:20:47 2023 -0600 [PATCH] RISC-V: Fix PR109399 VSETVL PASS bug PR 109399 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (pass_vsetvl::compute_local_backward_infos): Update user vsetvl in local demand fusion. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/pr109399.c: New test.
[Bug target/109137] [12 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 #24 from Sam James --- As a heavy consumer of the branch for our distribution, I'd say it was a (nice) surprise, but then I wasn't expecting it to end up exposing a latent bug (or making it worse). At the end of the day, not much harm done in this case, as we noticed it pretty quickly. glibc also tends to backport tuning improvements (often more invasive than this) which is also sometimes a bit controversial.
[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410 --- Comment #2 from Andrew Pinski --- The broken IR has been there since at least 4.9.0: : _1 = x_4(D) > 41; baz (x_4(D), y_5(D)); goto ; : ABNORMAL_DISPATCHER (0); : _8 = y_5(D) != 0; _9 = x_4(D) == 42; _11 = x_4(D) > 42; _12 = _1 | _8; _13 = (int) _12; 4.7.x didn't have the ABNORMAL_DISPATCHER part of the IR either.
[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410 Andrew Pinski changed: What|Removed |Added Keywords||ice-checking --- Comment #1 from Andrew Pinski --- Most likely r13-1754-g7a158a5776f5ca which introduced the checking in the first place.
[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410 Andrew Pinski changed: What|Removed |Added Component|c |tree-optimization Target Milestone|--- |13.0
[Bug c/109409] [13 Regression] ICE in check_format_arg, at c-family/c-format.cc:1777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109409 --- Comment #2 from Andrew Pinski --- /* Variable length arrays can't be initialized. */ gcc_assert (TREE_CODE (array_size) == INTEGER_CST);
[Bug c++/109356] Enhancement idea to provide clearer missing brace line number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109356
--- Comment #3 from Jonny Grant ---
A different example where GCC does a good job of indicating the line number of
a missing comma problem.
https://godbolt.org/z/asGhE3W17
:6:5: error: expected '}' before '{' token
6 | {"G", "H"},
| ^
:2:1: note: to match this '{'
2 | {
| ^
:6:5: error: expected ',' or ';' before '{' token
6 | {"G", "H"},
| ^
[Bug c++/109404] tree check: expected identifier_node, have template_id_expr in dump_decl, at cp/error.cc:1301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109404 --- Comment #2 from Andrew Pinski --- The error that is being trying to print is: :8:27: error: 'constexpr' static data member 'is_iter< >' must have an initializer
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #39 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #38)
> struct foo {
>int n;
>char (*buf)[.n];
> };
>
> void store(struct foo* p, int a, int b) { (*p->buf)[a] = b; }
>
> int main()
> {
> struct foo p = { 7, &(char[7]){ 0 } };
> store(, 7, 1);
> }
>
> With UBSan, this should give this error:
> ex.c:8:52: runtime error: index 7 out of bounds for type 'char [*]'
yes, this worked. and with -fdump-tree-gimple, I can see the IR representation
for this test case. thanks.
> In the parser for '.n' I create a component ref with a placeholder
> expression inside it. But then later when creating a component
> ref for p->buf I replace all placeholder expressions in the
> *type* of p->buf with *p. So the type of p->buf has a
> .n as size expression somewwere and this
> becomes p.n.
the above explanation is very clean. thanks.
but the thing that confused me is: is the *type* of p->buf Pointer or Array?
>From the source code, it's a pointer, right? if so, why embed the array size to
it?
> Yes, potentially. But a FAM has special semantics and the
> code for this detects this based on the missing size (I think).
Yes, that's true. currently, we determine a FAM as the following (c-decl.cc):
/* Determine whether TYPE is a ISO C99 flexible array memeber type "[]". */
static bool
flexible_array_member_type_p (const_tree type)
{
if (TREE_CODE (type) == ARRAY_TYPE
&& TYPE_SIZE (type) == NULL_TREE
&& TYPE_DOMAIN (type) != NULL_TREE
&& TYPE_MAX_VALUE (TYPE_DOMAIN (type)) == NULL_TREE)
return true;
return false;
}
So, if we want to change the syntax of FAM to include size info, and embedded
this size info to the TYPE, then we need to adjust all the places in FE or in
Middle end that depend on the current FAM IR. Yes, potentially much bigger
changes.
therefore, directly extending the FAM syntax to include the size info might
involve bigger change than attribute approach.
We can implement attribute first, and then later do the syntax extension.
that might be safer.
> I tried the other thing first, because it seemed simpler and
> could potentially serve as a basis for the FAM case. But I am
> not so sure anymore, because of the issue mentioned below.
Okay, I see now.
> For the FAM case we should probably attach the attribute
> to the member and read it directly in the object size pass,
> similar how this is now done for the access attributes for
> parameters.
Yes, implementation of attribute should be simpler and safer.
I will try to come up with a patch on this attribute.
>
> I also thought that passing the information via the type
> would be better, but I am not sure how to do this at the
> moment.
Yes, passing the Size info through the type will be better, we can implement
this syntax extension later if the attribute works very well, and we can
promote it to a real language standard at that time.
[Bug target/109040] [13 Regression] wrong code with v16hi compare & mask on riscv64 at -O2 since r13-4907-g2e886eef7f2b5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040
--- Comment #7 from Eric Botcazou ---
WORD_REGISTER_OPERATIONS means that subword register operations in RTL are
actually performed on the whole word register by the machine, e.g.. for
(insn 47 35 39 2 (set (reg:HI 175)
(subreg:HI (reg:SI 166) 0)) "pr109040.c":9:11 179 {*movhi_internal}
(expr_list:REG_DEAD (reg:SI 166)
(nil)))
you can infer the MSB of (reg:SI 175) instead of them being undefined. But I
don't think that it prevents any particular instruction form.
[Bug ipa/109408] [13 Regression] ICE in decide_about_value, at ipa-cp.cc:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109408 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108605 --- Comment #1 from Andrew Pinski --- Most likely introduced by r13-5818-g00a49047b504b27a .
[Bug ipa/109408] [13 Regression] ICE in decide_about_value, at ipa-cp.cc:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109408 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |13.0
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 Damian changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #7 from Damian --- Hello Jakup, build tested and it works. Many thanks Damian
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 --- Comment #6 from Damian --- Hello Jakub, many thanks for you help :-) Damian
[Bug target/109402] v850: non-v850e version of __muldi3() in /libgcc/config/v850/lib1funcs.S operates sp in reversed direction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109402 --- Comment #1 from Andrew Pinski --- r0-44780-g8376061dbecc aka https://inbox.sourceware.org/gcc-patches/m3wuqam1t4@north-pole.nickc.cambridge.redhat.com/ It has been broken for almost 21 years even.
[Bug target/109406] Missing use of aarch64 SVE2 unpredicated integer multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109406 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2023-04-04 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug fortran/109413] New: [OpenMP] ICE for 'OMP ERROR at(compilation)' when using a named constant/parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109413 Bug ID: 109413 Summary: [OpenMP] ICE for 'OMP ERROR at(compilation)' when using a named constant/parameter Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: ice-on-valid-code, openmp Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org Target Milestone: --- The following gives an ICE in gfc_enforce_clean_symbol_state. character(*), parameter :: pt = "hkgj" !$omp error at(compilation) message(pt) end The current wording implies that this is valid. TODO: Check what C/C++ do for non-literals. Note: OpenMP Spec Issue 3558 might change what is permitted. * * * Possibly, the printing needs to me moved from directly after parsing to later: It sounds as if code placed in non-executable context (→ declaration part), metadirectives needs to be honored – which may imply a delayed printing after evaluating the static context selector? For executable context, the 'at' clause has the following, but not when used in declarative/non-executable context: "If _action-time_ is **compilation** and the directive appears in an executable context that is not reachable at runtime, the action may or may not be performed."
[Bug c/109412] [13 Regression] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412 --- Comment #2 from joseph at codesourcery dot com --- May be related to bug 107682.
[Bug fortran/104349] ICE in (tree_to_uhwi) gfc_conv_array_initializer, at fortran/trans-array.cc:6337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104349 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.0 Status|ASSIGNED|RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed in gcc-13. Closing. Thanks for the report!
[Bug fortran/104349] ICE in (tree_to_uhwi) gfc_conv_array_initializer, at fortran/trans-array.cc:6337
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104349 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:c57a93f647511cf7a3005f1197a1da03b5e3a1b0 commit r13-7003-gc57a93f647511cf7a3005f1197a1da03b5e3a1b0 Author: Harald Anlauf Date: Mon Apr 3 21:34:01 2023 +0200 Fortran: reject module variable as character length in PARAMETER [PR104349] gcc/fortran/ChangeLog: PR fortran/104349 * expr.cc (check_restricted): Adjust check for valid variables in restricted expressions: make no exception for module variables. gcc/testsuite/ChangeLog: PR fortran/104349 * gfortran.dg/der_charlen_1.f90: Adjust dg-patterns. * gfortran.dg/pr104349.f90: New test.
[Bug c/109412] [13 Regression] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-04-04 Target Milestone|--- |13.0 CC||jsm28 at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Priority|P3 |P2 --- Comment #1 from Marek Polacek --- Started with r13-2205-g14cfa01755a66a: commit 14cfa01755a66afbae2539f8b5796c960ddcecc6 Author: Joseph Myers Date: Thu Aug 25 21:02:57 2022 + c: Support C2x empty initializer braces
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #38 from Martin Uecker ---
Am Dienstag, dem 04.04.2023 um 15:07 + schrieb qinzhao at gcc dot gnu.org:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
>
> --- Comment #37 from qinzhao at gcc dot gnu.org ---
> (In reply to Martin Uecker from comment #36)
>
> >
> > I considered pointers to arrays:
> >
> > struct P {
> > int n;
> > char (*buf)[.n];
> > };
> >
>
> Okay.
> Then for the field "buf", it has a pointer type, the size of this field is a
> compile-time constant. where in the IR do you put the ".n" (the size of the
> array this pointer points to). That's the place I am trying to understand from
> your patch or from the IR dump of a working small testing case.
Try this:
struct foo {
int n;
char (*buf)[.n];
};
void store(struct foo* p, int a, int b) { (*p->buf)[a] = b; }
int main()
{
struct foo p = { 7, &(char[7]){ 0 } };
store(, 7, 1);
}
With UBSan, this should give this error:
ex.c:8:52: runtime error: index 7 out of bounds for type 'char [*]'
In the parser for '.n' I create a component ref with a placeholder
expression inside it. But then later when creating a component
ref for p->buf I replace all placeholder expressions in the
*type* of p->buf with *p. So the type of p->buf has a
.n as size expression somewwere and this
becomes p.n.
So the middle-end never sees the placeholder, but only the size
expression with the p.n in it. According to the comment
in tree.def I thought the later (replacement) part happens
automatically in the middle end, but this does not seem to be
the case in this scenario, so I implemented it in the FE.
> > the FAM case needs more work and I guess there are
> > still many other problems with the patch.
> >
> For the FAM case, since the field itself is an ARRAY type, then the ".n" can
> be
> naturally put to the SIZE of the type of the field.
Yes, potentially. But a FAM has special semantics and the
code for this detects this based on the missing size (I think).
> Another thing I'd like to point out, for the original intention of this PR,
> FAM
> case is more important than the pointer to array case, I think. So, should we
> focus on FAM first?
I tried the other thing first, because it seemed simpler and
could potentially serve as a basis for the FAM case. But I am
not so sure anymore, because of the issue mentioned below.
> >
> > The comments in
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
> >
> > imply that the size information does not survive long enough
> need to study this a little bit more.
>
> > But the size expression is evaluated each time when the member is
> > accessed.
> How to represent this in IR?
This is done in the FE by putting the size in save_expr which
and building the C_MAYBE_CONST_EXPR.
>
> > Maybe the size expressions should be limited to very simple
> expressions without side effects.
> agreed. but I think we might want to focus on FAM first.
For the FAM case we should probably attach the attribute
to the member and read it directly in the object size pass,
similar how this is now done for the access attributes for
parameters.
I also thought that passing the information via the type
would be better, but I am not sure how to do this at the
moment.
In any case, I am also just learning about a lot of things
in the middle end, so if others with more experience
have advice, you should better listen to them.
Martin
>
[Bug c/109409] [13 Regression] ICE in check_format_arg, at c-family/c-format.cc:1777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109409 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P2 Target Milestone|--- |13.0 CC||jsm28 at gcc dot gnu.org, ||mpolacek at gcc dot gnu.org Last reconfirmed||2023-04-04 Status|UNCONFIRMED |NEW --- Comment #1 from Marek Polacek --- Started with r13-2205-g14cfa01755a66a: commit 14cfa01755a66afbae2539f8b5796c960ddcecc6 Author: Joseph Myers Date: Thu Aug 25 21:02:57 2022 + c: Support C2x empty initializer braces
[Bug debug/109411] missing debug information with statement frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109411 Marek Polacek changed: What|Removed |Added CC||aoliva at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r255569 -- Alex, any comments? I'm not sure it is a genuine gcc bug but saying "No line 9 in file "test.h"" seems confusing at least. Possibly related to bug 92468.
[Bug c/109412] New: [13 Regression] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109412
Bug ID: 109412
Summary: [13 Regression] ICE in fold_convert_loc, at
fold-const.cc:2627
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220821 and 20220828 :
(derived from c-c++-common/ubsan/bounds-21.c)
$ cat z1.c
int i;
int foo (void) { return ++i; }
int
main ()
{
char a() = {};
a[foo ()] = a[foo()] | 'a';
if (i != 2)
__builtin_abort ();
a[foo()] |= 'a';
if (i != 3)
__builtin_abort ();
}
$ gcc-13-20230402 -c z1.c
z1.c: In function 'main':
z1.c:6:3: error: function 'a' is initialized like a variable
6 | char a() = {};
| ^~~~
z1.c:6:3: internal compiler error: in fold_convert_loc, at fold-const.cc:2627
0xa76ede fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.cc:2627
0x7741de pop_init_level(unsigned int, int, obstack*, unsigned int)
../../gcc/c/c-typeck.cc:9382
0x7a7f8e c_parser_braced_init
../../gcc/c/c-parser.cc:5775
0x7a9651 c_parser_initializer
../../gcc/c/c-parser.cc:5675
0x7c3ec8 c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2564
0x7c293b c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:6208
0x7c2d83 c_parser_compound_statement
../../gcc/c/c-parser.cc:6105
0x7c4d7f c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2841
0x7cf0af c_parser_external_declaration
../../gcc/c/c-parser.cc:1925
0x7cf9ed c_parser_translation_unit
../../gcc/c/c-parser.cc:1779
0x7cf9ed c_parse_file()
../../gcc/c/c-parser.cc:24632
0x84a4e1 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1248
[Bug debug/109411] New: missing debug information with statement frontiers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109411
Bug ID: 109411
Summary: missing debug information with statement frontiers
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
Target Milestone: ---
$ cat main.cc
#include "test.h"
void invokeInline (Message & msg, int param)
{
someInlineFunction (msg, param);
}
int main ()
{
Message msg;
invokeInline (msg, 42);
}
$ cat test.h
struct Message {
int member{35};
};
template
void someInlineFunction (T & msg, int value)
{
msg.member += value;
}
$ g++ -Og -g main.cc
$ gdb --nh --batch -ex 'break test.h:9' -ex run ./a.out
No line 9 in file "test.h".
[...]
but:
$ g++ -Og -g main.cc -gno-statement-frontiers
$ gdb --nh --batch -ex 'break test.h:9' -ex run ./a.out
Breakpoint 1 at 0x40113b: file /home/mpolacek/x/trunk/gcc/r/test.h, line 9.
[...]
[Bug c/109410] New: [13 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410
Bug ID: 109410
Summary: [13 Regression] ICE: verify_flow_info failed
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220717 and 20220724, at -O1+ :
(testcase derived from pr108783.c)
(gcc configured with --enable-checking=yes)
$ cat z1.c
__attribute__((returns_twice)) int baz (int, int);
int
bar (int x)
{
return x;
}
int
foo (int x, int y)
{
int a;
a = bar (x);
baz (x, y);
return y && a && a;
}
int
qux (int x, int y)
{
int a;
a = bar (x);
baz (x, y);
return y && a != 42 && a >= 42;
}
int
corge (int x, int y)
{
int a;
baz (x, y);
a = bar (x);
return y || a == 42 || a > 42;
}
$ gcc-13-20230402 -c z1.c -O2
z1.c: In function 'corge':
z1.c:24:1: error: returns_twice call is not first in basic block 2
24 | corge (int x, int y)
| ^
baz (x_7(D), y_8(D));
during GIMPLE pass: reassoc
z1.c:24:1: internal compiler error: verify_flow_info failed
0x8eeb6f verify_flow_info()
../../gcc/cfghooks.cc:285
0xd58ce6 execute_function_todo
../../gcc/passes.cc:2110
0xd59742 execute_todo
../../gcc/passes.cc:2152
[Bug c/109409] New: [13 Regression] ICE in check_format_arg, at c-family/c-format.cc:1777
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109409
Bug ID: 109409
Summary: [13 Regression] ICE in check_format_arg, at
c-family/c-format.cc:1777
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20220821 and 20220828, with -Wall :
$ cat z1.c
int g ();
void f (char *a)
{
const char c[g()] = "1";
__builtin_sprintf (a, c);
}
$ gcc-13-20230402 -c z1.c -Wall
z1.c: In function 'f':
z1.c:4:23: error: variable-sized object may not be initialized except with an
empty initializer
4 | const char c[g()] = "1";
| ^~~
z1.c:5:3: internal compiler error: in check_format_arg, at
c-family/c-format.cc:1777
5 | __builtin_sprintf (a, c);
| ^
0x83216a check_format_arg
../../gcc/c-family/c-format.cc:1777
0x82d680 check_format_info
../../gcc/c-family/c-format.cc:1543
0x82d680 check_function_format(tree_node const*, tree_node*, int, tree_node**,
vec*)
../../gcc/c-family/c-format.cc:1198
0x81a3e5 check_function_arguments(unsigned int, tree_node const*, tree_node
const*, int, tree_node**, vec*)
../../gcc/c-family/c-common.cc:6093
0x775e4d build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*, tree_node*)
../../gcc/c/c-typeck.cc:3309
0x7a6d01 c_parser_postfix_expression_after_primary
../../gcc/c/c-parser.cc:11239
0x79461d c_parser_postfix_expression
../../gcc/c/c-parser.cc:10846
0x7a17ba c_parser_unary_expression
../../gcc/c/c-parser.cc:8831
0x7a2b1f c_parser_cast_expression
../../gcc/c/c-parser.cc:8672
0x7a2e1b c_parser_binary_expression
../../gcc/c/c-parser.cc:8440
0x7a44eb c_parser_conditional_expression
../../gcc/c/c-parser.cc:8138
0x7a4d74 c_parser_expr_no_commas
../../gcc/c/c-parser.cc:8052
0x7a5022 c_parser_expression
../../gcc/c/c-parser.cc:11379
0x7a57db c_parser_expression_conv
../../gcc/c/c-parser.cc:11419
0x7c01f3 c_parser_statement_after_labels
../../gcc/c/c-parser.cc:6781
0x7c24db c_parser_compound_statement_nostart
../../gcc/c/c-parser.cc:6296
0x7c2d83 c_parser_compound_statement
../../gcc/c/c-parser.cc:6105
0x7c4d7f c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2841
0x7cf0af c_parser_external_declaration
../../gcc/c/c-parser.cc:1925
0x7cf9ed c_parser_translation_unit
../../gcc/c/c-parser.cc:1779
[Bug c/109408] New: [13 Regression] ICE in decide_about_value, at ipa-cp.cc:6154
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109408
Bug ID: 109408
Summary: [13 Regression] ICE in decide_about_value, at
ipa-cp.cc:6154
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: gs...@t-online.de
Target Milestone: ---
Started between 20230205 and 20230212, at -O3+ :
(testcase derived from pr108605.c)
(gcc configured with --enable-checking=yes)
$ cat z1.c
struct S {
int a, b, c;
int d[__INT_MAX__], e;
};
void
foo (struct S *s)
{
if (s->b && s->c != 0)
__builtin_abort ();
}
void
bar (void)
{
struct S s[2];
s[0].a = 0;
s[0].e = 0;
foo (s);
}
$ gcc-13-20230402 -c z1.c -O3
during IPA pass: cp
z1.c:18:1: internal compiler error: in decide_about_value, at ipa-cp.cc:6154
18 | }
| ^
0x1d5590f decide_about_value
../../gcc/ipa-cp.cc:6153
0x1d55be9 decide_whether_version_node
../../gcc/ipa-cp.cc:6248
0x1d5926b ipcp_decision_stage
../../gcc/ipa-cp.cc:6430
0x1d5926b ipcp_driver
../../gcc/ipa-cp.cc:6618
[Bug tree-optimization/109407] instruction cmpxchgl run error when using with g++ -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- The inline-asm is incorrect as the EAX/RAX register gets clobbered by cmpxchgl So you need something like (which works now): int tmp; __asm__ __volatile__( "lock;" "cmpxchgl %[NEW_VALUE], %[DST];" "sete %[RET];" : [RET] "=q"(dwRtnV),[DST] "+m"(dwOriV) , "=a"(tmp) // newly added :[NEW_VALUE] "r"(dwDstV), "a"(dwExpV) : "memory", "cc" );
[Bug c++/109396] Winit-self doesn't warn when std::move()-d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109396 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-04-04 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Confirmed. I would've thought that -Wself-move caught that but no. Likely mine for GCC 14.
[Bug tree-optimization/109407] New: instruction cmpxchgl run error when using with g++ -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109407
Bug ID: 109407
Summary: instruction cmpxchgl run error when using with g++ -O
Product: gcc
Version: 9.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: johgjc at yeah dot net
Target Milestone: ---
Created attachment 54810
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54810=edit
a simple test code
the following code,
when using g++ test.cpp, the a.out is a endless loop as expected.
when using g++ -O2 test.cpp, the a.out returns and prints dwOriV=8
#include
#include
int main(){
volatile int dwOriV = 32;
int8_t dwRtnV = 0;
int dwExpV = 16;
int dwDstV = 8;
while(true){
__asm__ __volatile__(
"lock;"
"cmpxchgl %[NEW_VALUE], %[DST];"
"sete %[RET];"
: [RET] "=q"(dwRtnV),[DST] "+m"(dwOriV)
:[NEW_VALUE] "r"(dwDstV), "a"(dwExpV)
: "memory", "cc"
);
if(dwRtnV) {break;}
}
printf("%d",dwOriV);
return 0;
}
my gcc version:
gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108896
--- Comment #37 from qinzhao at gcc dot gnu.org ---
(In reply to Martin Uecker from comment #36)
>
> I considered pointers to arrays:
>
> struct P {
> int n;
> char (*buf)[.n];
> };
>
Okay.
Then for the field "buf", it has a pointer type, the size of this field is a
compile-time constant. where in the IR do you put the ".n" (the size of the
array this pointer points to). That's the place I am trying to understand from
your patch or from the IR dump of a working small testing case.
> the FAM case needs more work and I guess there are
> still many other problems with the patch.
>
For the FAM case, since the field itself is an ARRAY type, then the ".n" can be
naturally put to the SIZE of the type of the field.
Another thing I'd like to point out, for the original intention of this PR, FAM
case is more important than the pointer to array case, I think. So, should we
focus on FAM first?
>
> The comments in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104970
>
> imply that the size information does not survive long enough
need to study this a little bit more.
> But the size expression is evaluated each time when the member is
> accessed.
How to represent this in IR?
> Maybe the size expressions should be limited to very simple
expressions without side effects.
agreed. but I think we might want to focus on FAM first.
[Bug target/109040] [13 Regression] wrong code with v16hi compare & mask on riscv64 at -O2 since r13-4907-g2e886eef7f2b5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040 --- Comment #6 from Jakub Jelinek --- Created attachment 54809 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54809=edit gcc13-pr109040.patch The following patch seems to fix it at least when eyeballing the testcase in a cross-compiler, it achieves exactly what we want, & 0x84c to perform the zero extension. But I have no way to actually test this on riscv.
[Bug target/109406] Missing use of aarch64 SVE2 unpredicated integer multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109406 ktkachov at gcc dot gnu.org changed: What|Removed |Added Severity|normal |enhancement
[Bug target/109406] New: Missing use of aarch64 SVE2 unpredicated integer multiply
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109406
Bug ID: 109406
Summary: Missing use of aarch64 SVE2 unpredicated integer
multiply
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
For the testcase
#define N 1024
long long res[N];
long long in1[N];
long long in2[N];
void
mult (void)
{
for (int i = 0; i < N; i++)
res[i] = in1[i] * in2[i];
}
With -O3 -march=armv8.5-a+sve2 we generate the loop:
ptrue p1.b, all
whilelo p0.d, wzr, w2
.L2:
ld1dz0.d, p0/z, [x4, x0, lsl 3]
ld1dz1.d, p0/z, [x3, x0, lsl 3]
mul z0.d, p1/m, z0.d, z1.d
st1dz0.d, p0, [x1, x0, lsl 3]
incdx0
whilelo p0.d, w0, w2
b.any .L2
ret
SVE2 supports the MUL (vectors, unpredicated) instruction that would allow us
to eliminate the use of p1. Clang manages to do this (though it has other
inefficiencies) in https://godbolt.org/z/7xj6xEchx
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Jakub Jelinek --- Fixed.
[Bug tree-optimization/109386] [13 Regression] Frange value relation related miscompilation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109386 --- Comment #4 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:ce243c9eefc2728cb8743ebbcb84c3e08236f06a commit r13-7002-gce243c9eefc2728cb8743ebbcb84c3e08236f06a Author: Jakub Jelinek Date: Tue Apr 4 16:13:06 2023 +0200 range-op-float: Fix reverse ops of comparisons [PR109386] I've missed one of my recent range-op-float.cc changes (likely the r13-6967 one) caused FAIL: libphobos.phobos/std/math/algebraic.d execution test FAIL: libphobos.phobos_shared/std/math/algebraic.d execution test regressions, distilled into a C testcase below. In the testcase, we have !(u >= v) condition where both u and v are results of fabs*, which guards t1 = u u<= __FLT_MAX__; and t2 = v u<= __FLT_MAX__; comparisons. From false u >= v where u and v have [0.0, +Inf] NAN ranges we (incorrectly deduce that one of them is [nextafterf (0.0, 1.0), +Inf] NAN and the other is [0.0, nextafterf (+Inf, 0.0)] NAN and from that deduce that one of the comparisons is always true, because UNLE_EXPR with the maximum representable number are false only if the value is +Inf and our ranges tell that is not possible. The bug is that the u >= v comparison determines a sensible range only when it is true - we then know neither operand can be NAN and it behaves correctly. But when the comparison is false, our current code gives sensible answers only if the other op can't be NAN. If it can be NAN, whenever it is NAN, the comparison is always false regardless of the other value, so the other value needs to be VARYING. Now, foperator_unordered_lt::op1_range etc. had code to deal with that for op?.known_nan (), but as the testcase shows, it is enough if it may be a NAN at runtime to make it VARYING. So, the following patch replaces for all those BRS_FALSE cases of the normal non-equality comparisons if (opOTHER.known_isnan ()) r.set_varying (type); to do it also if maybe_isnan (). For the unordered or ... comparisons, it is similar for BRS_TRUE. Those comparisons are true whenever either operand is NAN, or if neither is NAN, the corresponding normal comparison. So, if those comparisons are true and other operand might be a NAN, we can't tell (VARYING), if it is false, currently handling is correct. 2023-04-04 Jakub Jelinek PR tree-optimization/109386 * range-op-float.cc (foperator_lt::op1_range, foperator_lt::op2_range, foperator_le::op1_range, foperator_le::op2_range, foperator_gt::op1_range, foperator_gt::op2_range, foperator_ge::op1_range, foperator_ge::op2_range): Make r varying for BRS_FALSE case even if the other op is maybe_isnan, not just known_isnan. (foperator_unordered_lt::op1_range, foperator_unordered_lt::op2_range, foperator_unordered_le::op1_range, foperator_unordered_le::op2_range, foperator_unordered_gt::op1_range, foperator_unordered_gt::op2_range, foperator_unordered_ge::op1_range, foperator_unordered_ge::op2_range): Make r varying for BRS_TRUE case even if the other op is maybe_isnan, not just known_isnan. * gcc.c-torture/execute/ieee/pr109386.c: New test.
[Bug target/109040] [13 Regression] wrong code with v16hi compare & mask on riscv64 at -O2 since r13-4907-g2e886eef7f2b5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040
--- Comment #5 from Jakub Jelinek ---
The insn with HImode subreg comes from RTL DSE, before DSE we have:
(insn 36 35 39 2 (set (mem/c:SI (plus:SI (reg/f:SI 65 frame)
(const_int -64 [0xffc0])) [2 S4 A128])
(reg:SI 166)) "pr109040.c":9:11 178 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 166)
(nil)))
(insn 39 36 40 2 (set (reg:SI 171)
(zero_extend:SI (mem/c:HI (plus:SI (reg/f:SI 65 frame)
(const_int -64 [0xffc0])) [0 S2 A128])))
"pr109040.c":9:11 111 {*zero_extendhisi2}
(nil))
and DSE makes:
(insn 47 35 39 2 (set (reg:HI 175)
(subreg:HI (reg:SI 166) 0)) "pr109040.c":9:11 179 {*movhi_internal}
(expr_list:REG_DEAD (reg:SI 166)
(nil)))
(insn 39 47 40 2 (set (reg:SI 171)
(zero_extend:SI (reg:HI 175))) "pr109040.c":9:11 111
{*zero_extendhisi2}
(expr_list:REG_DEAD (reg:HI 175)
(nil)))
out of it. Does it for WORD_REGISTER_OPERATIONS need to create a single
instruction?
[Bug target/109040] [13 Regression] wrong code with v16hi compare & mask on riscv64 at -O2 since r13-4907-g2e886eef7f2b5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040
Jakub Jelinek changed:
What|Removed |Added
CC||ebotcazou at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
That said, I've tried to reproduce this using -O1 -fno-tree-forwprop
unsigned int a;
unsigned short b;
__attribute__((noipa))
unsigned int
foo (void)
{
unsigned int c = a & 0x8084c;
unsigned short d = c;
return d + b;
}
but while the RTL is quite similar in that case, this one works.
The problem with the #c0 testcase is during combine.
We have before combine:
(insn 32 23 34 2 (set (reg:SI 167 [ m ])
(mem/c:SI (reg/v/f:SI 147) [1 m+0 S4 A128])) "pr109040.c":9:30 180
{*movsi_internal}
(expr_list:REG_DEAD (reg/v/f:SI 147)
(nil)))
(insn 34 32 35 2 (set (reg:SI 168)
(const_int 526412 [0x8084c])) "pr109040.c":9:30 176 {*mvconst_internal}
(nil))
(insn 35 34 47 2 (set (reg:SI 166)
(and:SI (reg:SI 167 [ m ])
(reg:SI 168))) "pr109040.c":9:30 95 {andsi3}
(expr_list:REG_DEAD (reg:SI 168)
(expr_list:REG_DEAD (reg:SI 167 [ m ])
(expr_list:REG_EQUAL (and:SI (reg:SI 167 [ m ])
(const_int 526412 [0x8084c]))
(nil)
(insn 47 35 39 2 (set (reg:HI 175)
(subreg:HI (reg:SI 166) 0)) "pr109040.c":9:11 181 {*movhi_internal}
(expr_list:REG_DEAD (reg:SI 166)
(nil)))
(insn 39 47 40 2 (set (reg:SI 171)
(zero_extend:SI (reg:HI 175))) "pr109040.c":9:11 111
{*zero_extendhisi2}
(expr_list:REG_DEAD (reg:HI 175)
(nil)))
(insn 40 39 43 2 (set (reg:SI 172)
(leu:SI (reg:SI 171)
(const_int 5 [0x5]))) "pr109040.c":9:11 291 {*sleu_sisi}
(expr_list:REG_DEAD (reg:SI 171)
(nil)))
Now, the zero extension from HImode to SImode of m & 0x8084c would be best
combined as
m & 0x84c, but 0x84c doesn't fit into signed 12-bit immediate for ANDI
instruction.
On the above shorter testcase the major difference before combine is that the
zero_extend
is combined with the subreg, so
(insn 10 9 11 2 (set (reg:SI 148 [ c ])
(zero_extend:SI (subreg:HI (reg:SI 144 [ c ]) 0))) "pr109040-2.c":10:12
111 {*zero_extendhisi2}
(expr_list:REG_DEAD (reg:SI 144 [ c ])
(nil)))
in there. On the short testcase, the first successful combine is trying to
combine the *mvconst_internal, and and zero_extend:
Failed to match this instruction:
(set (reg:SI 148 [ c ])
(and:SI (reg:SI 145 [ a ])
(const_int 2124 [0x84c])))
Successfully matched this instruction:
(set (reg:SI 144 [ c ])
(const_int 2124 [0x84c]))
Successfully matched this instruction:
(set (reg:SI 148 [ c ])
(and:SI (reg:SI 145 [ a ])
(reg:SI 144 [ c ])))
and everything is fine.
On the #c0 testcase, the first successful combine from the above ones is trying
to combine the and and insn 47 (subreg) into:
Successfully matched this instruction:
(set (subreg:SI (reg:HI 175) 0)
(and:SI (reg:SI 167 [ m ])
(reg:SI 168)))
Now, not really sure if that's valid given that riscv is
WORD_REGISTER_OPERATIONS 1 target.
But maybe even the insn 47 before combine is wrong for such a target.
As pseudo 168 is 0x8084c, the upper half contains one randomish bit.
And later this new insn is combined with the leu into
Successfully matched this instruction:
(set (reg:SI 172)
(leu:SI (subreg:SI (reg:HI 175) 0)
(const_int 5 [0x5])))
which is definitely wrong, because the zero extension disappeared.
[Bug c++/109405] Should class final decoration result in larger unique_ptr with deleter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109405 --- Comment #2 from Richard Hazlewood --- Ah, ok. Thanks for quick response.
[Bug c++/109405] Should class final decoration result in larger unique_ptr with deleter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109405 Jonathan Wakely changed: What|Removed |Added Keywords||ABI --- Comment #1 from Jonathan Wakely --- This is expected. The unique_ptr implementation uses tuple which is similarly dependent on whether the tuple elements are final or not. Originally, that was because we used inheritance in tuple, in order to take advantage of the empty-base class optimization. Obviously we can't use inheritance for final types. These days we do not use inheritance, we use the [[no_unique_address]] attribute so that empty tuple elements take no space. But to avoid an ABI incompatibility with previous versions of GCC, the attribute is only used for non-final types. There's no way to fix this without breaking the library's ABI.
[Bug c++/109405] New: Should class final decoration result in larger unique_ptr with deleter ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109405
Bug ID: 109405
Summary: Should class final decoration result in larger
unique_ptr with deleter ?
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gcc at hazlewoods dot net
Target Milestone: ---
Whilst making an attempt to ensure some `std::unique_ptr<>` types had size
`sizeof(intptr_t)`, I was using empty `struct` deleters.
I habitually tapped `final` on a struct, and was surprised to see my
`static_assert`s fire.
Maybe this is a consequence of the push for devirtualization optimization, but
hopefully this can be confirmed.
```
#include
#include
int main()
{
struct S { void operator()() {} };
struct SF final { void operator()() {} };
std::cout << "S : " << sizeof(S) << std::endl;
std::cout << "SF: " << sizeof(SF) << std::endl;
using SP = std::unique_ptr;
using SFP = std::unique_ptr;
std::cout << "SP : " << sizeof(SP) << std::endl;
std::cout << "SFP: " << sizeof(SFP) << std::endl;
}
```
https://godbolt.org/z/Gfz4W5sP1
[Bug c++/109404] tree check: expected identifier_node, have template_id_expr in dump_decl, at cp/error.cc:1301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109404 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Last reconfirmed||2023-04-04 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug sanitizer/109107] [10/11/12/13 Regression] UBsan since GCC-8 misses an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109107 Marek Polacek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Marek Polacek --- Fixed for GCC 13.
[Bug sanitizer/109107] [10/11/12/13 Regression] UBsan since GCC-8 misses an integer-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109107 --- Comment #4 from CVS Commits --- The trunk branch has been updated by Marek Polacek : https://gcc.gnu.org/g:c1aca26b707471ce8051bd03b3fb2217bcdf2df0 commit r13-7001-gc1aca26b707471ce8051bd03b3fb2217bcdf2df0 Author: Marek Polacek Date: Mon Mar 13 18:50:25 2023 -0400 sanitizer: missing signed integer overflow errors [PR109107] Here we're failing to detect a signed overflow with -O because match.pd, since r8-1516, transforms c = (a + 1) - (int) (short int) b; into c = (int) ((unsigned int) a + 4294946117); wrongly eliding the overflow. This kind of problems is usually avoided by using TYPE_OVERFLOW_SANITIZED in the appropriate place. The first match.pd hunk in the patch fixes it. I've constructed a testcase for each of the surrounding cases as well. Then I noticed that fold_binary_loc/associate has the same problem, so I've added a TYPE_OVERFLOW_SANITIZED there as well (it may be too coarse, sorry). Then I found yet another problem, but instead of fixing it now I've opened 109134. I could probably go on and find a dozen more. PR sanitizer/109107 gcc/ChangeLog: * fold-const.cc (fold_binary_loc): Use TYPE_OVERFLOW_SANITIZED when associating. * match.pd: Use TYPE_OVERFLOW_SANITIZED. gcc/testsuite/ChangeLog: * c-c++-common/ubsan/pr109107-1.c: New test. * c-c++-common/ubsan/pr109107-2.c: New test. * c-c++-common/ubsan/pr109107-3.c: New test. * c-c++-common/ubsan/pr109107-4.c: New test.
[Bug target/109040] [13 Regression] wrong code with v16hi compare & mask on riscv64 at -O2 since r13-4907-g2e886eef7f2b5a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109040 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 54808 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54808=edit gcc13-riscv-mvconst.patch I think it is weird to have multiple mov like patterns. I've tried to get rid of this by adding a new predicate for *movsi_internal/*movdi_64bit, which after expansion and until end of split1 accepts the splittable constants and turn the current *mvconst_internal into a pure splitter. This doesn't fix the PR though, but I think it would be a good idea anyway.
[Bug tree-optimization/109392] [12/13 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177 since r12-117-gb972e036f40c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392 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 54807 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54807=edit gcc13-pr109392.patch Untested fix.
[Bug libstdc++/109400] Missing 'advance' optimizations for std::istreambuf_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109400
--- Comment #3 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> Additionally, std::ranges::advance is not specialized for
> std::istreambuf_iterator so just increments character by character. The
> ranges::advance(i, n) form should use std::advance. The ranges::advance(i,
> sentinel) form will already be optimal when the sentinel is the same type as
> the iterator, but will be slow when using default_sentinel_t.
Oops, assignable_from&, default_sentinel_t> is
satisfied, via the non-explicit istreambuf_iterator(default_sentinel_t)
constructor, so it already works efficiently with default_sentinel.
> The
> ranges::advance(i, n, sentinel) form could be done efficiently, and has the
> advantage that it's not undefined if EOF is reached before advancing n times.
This could still be improved though.
Something like this:
--- a/libstdc++-v3/include/bits/ranges_base.h
+++ b/libstdc++-v3/include/bits/ranges_base.h
@@ -42,6 +42,17 @@
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
+
+template class char_traits;
+template class istreambuf_iterator;
+template
+ static constexpr bool __is_istreambuf_iter = false;
+
+template
+ static constexpr bool
+ __is_istreambuf_iter>>
+= std::__is_char<_CharT>::__value;
+
namespace ranges
{
template
@@ -737,6 +748,8 @@ namespace ranges
while (++__n);
}
}
+ else if constexpr (__is_istreambuf_iter<_It>)
+ std::advance(__it, __n);
else
{
// cannot decrement a non-bidirectional iterator
@@ -791,6 +804,11 @@ namespace ranges
return __n;
else if (__n > 0)
{
+ if constexpr (__is_istreambuf_iter<_It>)
+ {
+ // TODO need access to __it._M_sbuf
+ }
+
iter_difference_t<_It> __m = 0;
do
{
But it seems to me that it would be helpful if ranges::advance was a
customization point, so that program-defined iterators could provide an
optimized implementation too.
[Bug c++/109404] New: tree check: expected identifier_node, have template_id_expr in dump_decl, at cp/error.cc:1301
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109404
Bug ID: 109404
Summary: tree check: expected identifier_node, have
template_id_expr in dump_decl, at cp/error.cc:1301
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
template struct iterator { };
struct fn
{
template
static constexpr bool is_iter = false;
template
static constexpr bool is_iter = true;
};
There's a missing '>' before '= true' but any build with checking enabled gives
an ICE:
ice.cc:8:27: error: parse error in template argument list
8 | static constexpr bool is_iter = true;
| ^~
'
tree check: expected identifier_node, have template_id_expr in dump_decl, at
cp/error.cc:1301
0x8974ca tree_check_failed(tree_node const*, char const*, int, char const*,
...)
/home/jwakely/src/gcc/gcc/gcc/tree.cc:8909
0x6fb65d tree_check(tree_node*, char const*, int, char const*, tree_code)
/home/jwakely/src/gcc/gcc/gcc/tree.h:3530
0x6fb65d dump_decl
/home/jwakely/src/gcc/gcc/gcc/cp/error.cc:1301
0xa4adb7 decl_to_string
/home/jwakely/src/gcc/gcc/gcc/cp/error.cc:3307
0xa4adb7 cp_printer
/home/jwakely/src/gcc/gcc/gcc/cp/error.cc:4481
0x220250f pp_format(pretty_printer*, text_info*)
/home/jwakely/src/gcc/gcc/gcc/pretty-print.cc:1475
0x21e11c5 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*)
/home/jwakely/src/gcc/gcc/gcc/diagnostic.cc:1579
0x21e18f4 diagnostic_impl
/home/jwakely/src/gcc/gcc/gcc/diagnostic.cc:1743
0x21e223a error_at(unsigned int, char const*, ...)
/home/jwakely/src/gcc/gcc/gcc/diagnostic.cc:2066
0xa1cca4 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
/home/jwakely/src/gcc/gcc/gcc/cp/decl.cc:14413
0xa3a14e grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
/home/jwakely/src/gcc/gcc/gcc/cp/decl2.cc:990
0xb22389 cp_parser_init_declarator
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:23025
0xb2a2be cp_parser_single_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:32512
0xb2a4e4 cp_parser_template_declaration_after_parameters
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:32065
0xb2ad70 cp_parser_explicit_template_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:32338
0xaf6bf5 cp_parser_member_specification_opt
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:27149
0xaf6bf5 cp_parser_class_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:26161
0xaf6bf5 cp_parser_type_specifier
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:19491
0xaf8606 cp_parser_decl_specifier_seq
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:16044
0xaf9634 cp_parser_simple_declaration
/home/jwakely/src/gcc/gcc/gcc/cp/parser.cc:15263
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/109393] Very trivial address calculation does not fold
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109393 --- Comment #2 from manolis.tsamis at vrull dot eu --- (In reply to Andrew Pinski from comment #1) > Note sometimes -fwrapv will optimize things because it can assume that > overflow is defined as wrapping and this is one case that is true. Yes it > sounds counter intuitive but it is true. Even re-association happens more > with -fwrapv :). Yes it is truly counter intuitive :) Yet, leaving this wrapv behaviour aside, isn't this something that should be always optimized regardless of wrap/overflow flags?
[Bug ipa/109403] New: Alignment of common blocks not reported correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109403 Bug ID: 109403 Summary: Alignment of common blocks not reported correctly Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: jahns at dkrz dot de CC: marxin at gcc dot gnu.org Target Milestone: --- When compiling a source file with -flto, the alignment of common blocks seems to not be reported from gcc-nm: $ cat >align-test.f90 <
[Bug target/109402] New: v850: non-v850e version of __muldi3() in /libgcc/config/v850/lib1funcs.S operates sp in reversed direction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109402 Bug ID: 109402 Summary: v850: non-v850e version of __muldi3() in /libgcc/config/v850/lib1funcs.S operates sp in reversed direction Product: gcc Version: 11.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: t-hosh...@pony-e.jp Target Milestone: --- I have no idea to show a reproduce way in shortly. Because a problem happens with inter-procedure such as interrupt service routines which use storage in stack. Where I talk about is: in a commit 8b1204d7, /libgcc/config/v850/lib1funcs.S L2214, L2259. There are stack-pointer operations. I think these operations: shrink before, glowth after --- may reversed way. There is one more consideration; this version of __muldi3() does not use local storage in stack. So the problem will be resolved simply to remove sp-operations. In my environment, the next patch works well. --- >From 1258506e0192fb0b9e5ce9e99fe88752ba7a5644 Tue, 4 Apr 2023 20:31:48 +0900 From: Hoshino Tetsuma Date: Tue, 4 Apr 2023 19:25:03 +0900 Subject: [PATCH] remove improper stack-pointer operation diff --git a/libgcc/config/v850/lib1funcs.S b/libgcc/config/v850/lib1funcs.S index 00dd61d..99e79bf 100644 --- a/libgcc/config/v850/lib1funcs.S +++ b/libgcc/config/v850/lib1funcs.S @@ -2211,7 +2211,6 @@ ___muldi3: #ifdef __v850__ jarl __save_r26_r31, r10 -addi 16, sp, sp mov r6, r28 shr 15, r28 movea lo(32767), r0, r14 @@ -2256,7 +2255,6 @@ mulh r12, r6 mov r28, r17 mulh r10, r17 -add -16, sp mov r28, r12 mulh r8, r12 add r17, r18
[Bug tree-optimization/109401] Optimise max (a, b) + min (a, b) into a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109401 --- Comment #5 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #4) > (In reply to Andrew Pinski from comment #2) > > Something like this: > > (for op (somebinarops) > > (simplify > > (op:c (min:c @0 @1) (max:c @0 @1)) > > (if (!FLOAT_TYPE_P(type)) > > Why? Commutative ops don't care which operand is first and which is second > even when honoring NaNs or signed zeros. It is not the commutative ops that is the issue but rather the definition of min/max is the issue. From what I remember those two are not well defined. Oh min/max should be added to the list of communative ops too; though there might be already patterns for those.
[Bug tree-optimization/109401] Optimise max (a, b) + min (a, b) into a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109401 --- Comment #4 from Jakub Jelinek --- (In reply to Andrew Pinski from comment #2) > Something like this: > (for op (somebinarops) > (simplify > (op:c (min:c @0 @1) (max:c @0 @1)) > (if (!FLOAT_TYPE_P(type)) Why? Commutative ops don't care which operand is first and which is second even when honoring NaNs or signed zeros.
[Bug tree-optimization/109401] Optimise max (a, b) + min (a, b) into a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109401 --- Comment #3 from Andrew Pinski --- (In reply to Jakub Jelinek from comment #1) > Guess it applies to other commutative expressions, like &, | or ^. yes and == and != too.
[Bug tree-optimization/109401] Optimise max (a, b) + min (a, b) into a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109401 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement Last reconfirmed||2023-04-04 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski --- Something like this: (for op (somebinarops) (simplify (op:c (min:c @0 @1) (max:c @0 @1)) (if (!FLOAT_TYPE_P(type)) (op @0 @1 Replacing somebinarops with all commutative binary expressions code. Note !FLOAT_TYPE_P might be changed to !HONOR_NANS && !HONOR_SIGNED_ZEROS instead but I am not 100% sure that is the correct thing there. Confirmed.
[Bug libstdc++/14493] std::bad_alloc::what() does not explain what happened
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=14493 --- Comment #30 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:688d126b69215db29774c249b052e52d765782b3 commit r13-6999-g688d126b69215db29774c249b052e52d765782b3 Author: Jonathan Wakely Date: Tue Apr 4 12:04:14 2023 +0100 libstdc++: Fix outdated docs about demangling exception messages The string returned by std::bad_exception::what() hasn't been a mangled name since PR libstdc++/14493 was fixed for GCC 4.2.0, so remove the docs showing how to demangle it. libstdc++-v3/ChangeLog: * doc/xml/manual/extensions.xml: Remove std::bad_exception from example program. * doc/html/manual/ext_demangling.html: Regenerate.
[Bug tree-optimization/109401] Optimise max (a, b) + min (a, b) into a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109401 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Guess it applies to other commutative expressions, like &, | or ^.
[Bug tree-optimization/109401] New: Optimise max (a, b) + min (a, b) into a + b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109401
Bug ID: 109401
Summary: Optimise max (a, b) + min (a, b) into a + b
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ktkachov at gcc dot gnu.org
Target Milestone: ---
The testcase
#include
#include
uint32_t
foo (uint32_t a, uint32_t b)
{
return std::max (a, b) + std::min (a, b);
}
uint32_t
foom (uint32_t a, uint32_t b)
{
return std::max (a, b) * std::min (a, b);
}
could optimise foo into a + b and foom into a * b.
Should be a matter of some match.pd patterns?
[Bug libstdc++/109400] Missing 'advance' optimizations for std::istreambuf_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109400
--- Comment #2 from Jonathan Wakely ---
For ranges::advance we could do something like this, but it feels like there
should be a better way to customize ranges::advance for your own iterators:
--- a/libstdc++-v3/include/bits/ranges_base.h
+++ b/libstdc++-v3/include/bits/ranges_base.h
@@ -712,6 +712,12 @@ namespace ranges
struct __advance_fn final
{
+template
+ constexpr bool __is_istreambuf_iter = false;
+template
+ constexpr bool __is_istreambuf_iter>
+ = __gnu_cxx::__is_char<_CharT>::__value;
+
template
constexpr void
operator()(_It& __it, iter_difference_t<_It> __n) const
@@ -737,6 +743,8 @@ namespace ranges
while (++__n);
}
}
+ else if constexpr (__is_istreambuf_iter<_It>)
+ std::advance(__it, __n);
else
{
// cannot decrement a non-bidirectional iterator
@@ -754,6 +762,9 @@ namespace ranges
__it = std::move(__bound);
else if constexpr (sized_sentinel_for<_Sent, _It>)
(*this)(__it, __bound - __it);
+ else if constexpr (__is_istreambuf_iter<_It>
+&& is_same_v<_Sent, default_sentinel_t>)
+ __it = _It();
else
{
while (__it != __bound)
@@ -791,6 +802,11 @@ namespace ranges
return __n;
else if (__n > 0)
{
+ if constexpr (__is_istreambuf_iter<_It>)
+ {
+ // TODO need access to __it._M_sbuf
+ }
+
iter_difference_t<_It> __m = 0;
do
{
[Bug libstdc++/109400] Missing 'advance' optimizations for std::istreambuf_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109400
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed||2023-04-04
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely ---
This fixes std::next
--- a/libstdc++-v3/include/bits/streambuf_iterator.h
+++ b/libstdc++-v3/include/bits/streambuf_iterator.h
@@ -541,6 +541,18 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
__i = istreambuf_iterator<_CharT>(__sb);
}
+#if __cplusplus > 201103L
+ template
+_GLIBCXX_NODISCARD [[__gnu__::__always_inline__]] inline
+__enable_if_t<__is_char<_CharT>::__value, istreambuf_iterator<_CharT>>
+next(istreambuf_iterator<_CharT> __x,
+typename char_traits<_CharT>::off_type __n = 1)
+{
+ std::advance(__x, __n);
+ return __x;
+}
+#endif
+
/// @} group iterators
_GLIBCXX_END_NAMESPACE_VERSION
[Bug target/107674] [11/12/13 Regressions] arm: MVE codegen regressions on VCTP and vector LDR/STR instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674 --- Comment #3 from Stam Markianos-Wright --- Thank you, Andre for fixing the Part 1 in this ticket :) The part 2 we've found to be a regression since r13-416-g485a0ae0982abe and is also the reason why the mve_*_memory_nodes tests are currently failing.
[Bug libstdc++/109400] New: Missing 'advance' optimizations for std::istreambuf_iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109400 Bug ID: 109400 Summary: Missing 'advance' optimizations for std::istreambuf_iterator Product: gcc Version: 13.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: enhancement Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: redi at gcc dot gnu.org Target Milestone: --- We have a custom overload of std::advance for std::istreambuf_iterator which operates directly on the streambuf's get area, instead of incrementing character by character. But it doesn't get used when calling std::next, because that calls std::advance without ADL, and the custom overload hasn't been declared yet. We either need to declare istreambuf_iterator and its std::advance, or add a custom overload of std::next. Additionally, std::ranges::advance is not specialized for std::istreambuf_iterator so just increments character by character. The ranges::advance(i, n) form should use std::advance. The ranges::advance(i, sentinel) form will already be optimal when the sentinel is the same type as the iterator, but will be slow when using default_sentinel_t. The ranges::advance(i, n, sentinel) form could be done efficiently, and has the advantage that it's not undefined if EOF is reached before advancing n times.
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Jakub Jelinek --- Should be fixed now.
[Bug target/109384] [13 Regression] unquoted keyword 'float' in format [-Werror=format-diag]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109384
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:840354060e23ff28d325af2b8422233ce14f40f8
commit r13-6997-g840354060e23ff28d325af2b8422233ce14f40f8
Author: Jakub Jelinek
Date: Tue Apr 4 11:20:28 2023 +0200
riscv: Fix bootstrap [PR109384]
The following patch unbreaks riscv bootstrap, where it previously failed
on -Werror=format-diag warning promoted to error.
Ok for trunk?
Or shall it say e.g.
"%<-march=%s%>: % extension conflicts with %"
?
Or say if the current condition is true, do
const char *ext = "zfinx";
if (subset_list->lookup ("zdinx"))
ext = "zdinx";
else if (subset_list->lookup ("zhinx"))
ext = "zhinx";
else if (subset_list->lookup ("zhinxmin"))
ext = "zhinxmin";
and
"%<-march=%s%>: %qs extension conflicts with %", arch, ext
? Or do similar check for which extension to print against it,
const char *ext = "zfinx";
const char *ext2 = "f";
if (subset_list->lookup ("zdinx"))
{
ext = "zdinx";
if (subset_list->lookup ("d"))
ext2 = "d";
}
else if (subset_list->lookup ("zhinx"))
{
ext = "zhinx";
if (subset_list->lookup ("zfh"))
ext2 = "zfh";
}
else if (subset_list->lookup ("zhinxmin"))
{
ext = "zhinxmin";
if (subset_list->lookup ("zfhmin"))
ext2 = "zfhmin";
}
"%<-march=%s%>: %qs extension conflicts with %qs", arch, ext, ext2
?
2023-04-04 Jakub Jelinek
PR target/109384
* common/config/riscv/riscv-common.cc (riscv_subset_list::parse):
Reword diagnostics about zfinx conflict with f, formatting fixes.
* gcc.target/riscv/arch-19.c: Expect a different message about
zfinx
vs. f conflict.
[Bug c/109399] New: RISC-V: RVV VSETVL PASS backward demand fusiton bug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109399
Bug ID: 109399
Summary: RISC-V: RVV VSETVL PASS backward demand fusiton bug
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: juzhe.zhong at rivai dot ai
Target Milestone: ---
Consider this following case:
#include "riscv_vector.h"
void foo(void *in1, void *in2, void *in3, void *out, size_t n) {
size_t vl = __riscv_vsetvlmax_e32m1();
vint32m1_t a = __riscv_vle32_v_i32m1(in1, vl);
vint32m1_t b = __riscv_vle32_v_i32m1_tu(a, in2, vl);
vint32m1_t c = __riscv_vle32_v_i32m1_tu(b, in3, vl);
__riscv_vse32_v_i32m1(out, c, vl);
}
Current codegen:
foo:
vsetvli a5,zero,e32,m1,ta,mu
vle32.v v1,0(a0)
vle32.v v1,0(a1)
vle32.v v1,0(a2)
vse32.v v1,0(a3)
ret
It's obvious that "ta,mu" is incorrect. Instead, we should emit vsetvl
with "tu,m[au]" ,mask policy can be either mu or ma. But tail policy must be
"tu".
The reason we have this issue is that we didn't update && change user vsetvl
instruction during local backward demand fusion (Phase 1).
Will post a bug fix patch soon.
[Bug tree-optimization/109392] [12/13 Regression] ICE in tree_vec_extract, at tree-vect-generic.cc:177 since r12-117-gb972e036f40c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109392 Martin Liška changed: What|Removed |Added CC||marxin at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Summary|[12/13 Regression] ICE in |[12/13 Regression] ICE in |tree_vec_extract, at|tree_vec_extract, at |tree-vect-generic.cc:177|tree-vect-generic.cc:177 ||since r12-117-gb972e036f40c --- Comment #3 from Martin Liška --- (In reply to Andrew Pinski from comment #1) > Confirmed. > > Most likely caused by r12-117-gb972e036f40c . Yes, started with this revision.
[Bug c/109398] New: libiberty/sha1.c:234:11: warning: defining a type within 'offsetof' is a Clang extension [-Wgnu-offsetof-extensions]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109398 Bug ID: 109398 Summary: libiberty/sha1.c:234:11: warning: defining a type within 'offsetof' is a Clang extension [-Wgnu-offsetof-extensions] Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: marxin at gcc dot gnu.org CC: ian at airs dot com Target Milestone: --- I noticed the following Clang warning that is based on: https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
[Bug tree-optimization/109304] [13 Regression] ICE in get_vrange, at value-range-storage.cc:87 when building Python 3.12.0_alpha6 since r13-6849-ged626f18b189920a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304 Martin Liška changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Martin Liška --- Fixed.
[Bug tree-optimization/109304] [13 Regression] ICE in get_vrange, at value-range-storage.cc:87 when building Python 3.12.0_alpha6 since r13-6849-ged626f18b189920a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109304 --- Comment #7 from CVS Commits --- The master branch has been updated by Martin Liska : https://gcc.gnu.org/g:d0b961b802dd7d9d555ff4515835a479329326e9 commit r13-6995-gd0b961b802dd7d9d555ff4515835a479329326e9 Author: Richard Biener Date: Tue Mar 28 08:06:12 2023 + tree-optimization/109304 - properly handle instrumented aliases When adjusting calls to reflect instrumentation we failed to handle calls to aliases since they appear to have no body. Instead resort to symtab node availability. The patch also avoids touching internal function calls in a more obvious way (builtins might have a body available). profiledbootstrap & regtest running on x86_64-unknown-linux-gnu. Honza - does this look OK? PR tree-optimization/109304 * tree-profile.cc (tree_profiling): Use symtab node availability to decide whether to skip adjusting calls. Do not adjust calls to internal functions. * gcc.dg/pr109304.c: New testcase.
