[Bug target/111634] RISC-V vector: ICE RTL check: expected code 'reg', have 'lo_sum' in rhs_regno, at rtl.h:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111634
--- Comment #2 from CVS Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:a809a556dc0792a34fca7b754ff96ea3ea7d1e7f
commit r14-4443-ga809a556dc0792a34fca7b754ff96ea3ea7d1e7f
Author: Pan Li
Date: Sat Oct 7 12:39:14 2023 +0800
RISC-V: Bugfix for legitimize address PR/111634
Given we have RTL as below.
(plus:DI (mult:DI (reg:DI 138 [ g.4_6 ])
(const_int 8 [0x8]))
(lo_sum:DI (reg:DI 167)
(symbol_ref:DI ("f") [flags 0x86] )
))
When handling (plus (plus (mult (a) (mem_shadd_constant)) (fp)) (C)) case,
the fp will be the lo_sum operand as above. We have assumption that the fp
is reg but actually not here. It will have ICE when building with option
--enable-checking=rtl.
This patch would like to fix it by adding the REG_P to ensure the operand
is a register. The test case gcc/testsuite/gcc.dg/pr109417.c covered this
fix when build with --enable-checking=rtl.
PR target/111634
gcc/ChangeLog:
* config/riscv/riscv.cc (riscv_legitimize_address): Ensure
object is a REG before extracting its' REGNO.
Signed-off-by: Pan Li
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643 --- Comment #14 from Lukas Grätz --- (In reply to Andrew Pinski from comment #13) > (In reply to Andrew Pinski from comment #12) > > Gcc does have tail call optimization which should allow the instrumentation > > with less overhead. Though tail call optimization happens at -O2 and above > > only (by default). > > The only improvement to this would be fall through alias which allows the > removal of the jump to the other function. A direct non-conditional jump is > usually predictable so the overhead should be small still. Thanks! I thought that there was still some stack involved also causing some overhead for every function call (in comparison to a pure non-conditional jump). When I have time next week, I will try to look into that in detail.
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643 --- Comment #13 from Andrew Pinski --- (In reply to Andrew Pinski from comment #12) > Gcc does have tail call optimization which should allow the instrumentation > with less overhead. Though tail call optimization happens at -O2 and above > only (by default). The only improvement to this would be fall through alias which allows the removal of the jump to the other function. A direct non-conditional jump is usually predictable so the overhead should be small still.
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643 --- Comment #12 from Andrew Pinski --- Gcc does have tail call optimization which should allow the instrumentation with less overhead. Though tail call optimization happens at -O2 and above only (by default).
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #11 from Lukas Grätz ---
(In reply to Alexander Monakov from comment #10)
> (In reply to Lukas Grätz from comment #9)
> > I also wondered whether
> >
> > int bar_alias (void) { return bar_original(); }
> >
> > could be a portable alternative to attribute alias. Except that current GCC
> > does not translate it that way.
>
> That's because function addresses are significant and so
>
> _alias == _original
>
> must evaluate to false, but would be true for aliases.
>
> In theory compilers could do better by introducing fall-through aliases:
> https://gcc.gnu.org/wiki/
> cauldron2019talks?action=AttachFile=view=fallthrough-aliases.pdf
Thanks a lot! I haven't thought about function addresses. Is there hope that
fall-through aliases get into gcc? Then my perhaps my instrumentation
fall-through would also be possible to implement.
[Bug fortran/110957] -ffpe-trap and -ffpe-summary options issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110957
--- Comment #2 from anlauf at gcc dot gnu.org ---
Created attachment 56071
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56071=edit
Patch to fix mixed up parsing of fpe options
The attached patch fixes the mixup and adds the possibility to specify
-ffpe-trap=none to clear previously enabled exceptions on the command line.
Will submit this to the list.
Regarding the treatment of -f(no-)trapping-math, I played around a little
bit, and I am unsure what to do.
In gfortran, the option -ffpe-trap only sets the FPU mask in the main and
does nothing else. Which I think is the major (sole?) purpose.
On the other hand, -f(no-)trapping-math has implications that affect
e.g. reassociation. Adding to gfc_post_options() something like
if (gfc_option.fpe != 0 && !flag_trapping_math)
{
gfc_warning_now (0, "Option %<-ffpe-trap=%> enforces "
"%<-ftrapping-math%> for Fortran");
flag_trapping_math = 1;
}
will generate different warnings for -O3 -ffast-math, -Ofast, and might
create more confusion than help users.
I tend to think that this part should not be implemented (now), unless
we better understand the implications of what a change of the defaults
in gcc means to gfortran.
[Bug target/109279] RISC-V: complex constants synthesized should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279 --- Comment #19 from Vineet Gupta --- FWIW with today's change, splitter is now hidden from IRA, but we are still getting the extraneous mv. 2023-10-06 c1bc7513b1d7 RISC-V: const: hide mvconst splitter from IRA
[Bug target/109279] RISC-V: complex constants synthesized should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109279
--- Comment #18 from Vineet Gupta ---
(In reply to Vineet Gupta from comment #17)
> (In reply to Vineet Gupta from comment #16)
> > > Which is what this produces:
> > > ```
> > > long long f(void)
> > > {
> > > unsigned t = 16843009;
> > > long long t1 = t;
> > > long long t2 = ((unsigned long long )t) << 32;
> > > asm("":"+r"(t1));
> > > return t1 | t2;
> > > }
> > > ```
> > li a0,16842752
> > addia0,a0,257
> > li a5,16842752
> > sllia0,a0,32
> > addia5,a5,257
> > or a0,a5,a0
> > ret
>
> This is again IRA inflicted pain (similar to [PR110748]).
> IRA seems to be undoing split1 since we have 2 insn sequences to synthesize
> the constant pieces. This explains why the problem got exacerbated with
> commit 0530254413f8 ("riscv: relax splitter restrictions for creating
> pseudos") since now different regs are used to create parts of const, vs 1
> reg being repeatedly used for assembling a const (fooling IRA's equivalent
> replacement logic).
After commit
2023-08-18 a047513c9222 RISC-V: Enable pressure-aware scheduling by
default.
the test above has improved.
li a5,16842752
addia5,a5,257
mv a0,a5
sllia5,a5,32
or a0,a0,a5
ret
[Bug bootstrap/111663] profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663 Sergei Trofimovich changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |slyfox at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Sergei Trofimovich --- Fixed in master branch.
[Bug bootstrap/111663] profiledbootstrap fails on master: gcc/genmodes.cc:2152:1: error: ‘gcc/build/genmodes.gcda’ profile count data file not found [-Werror=missing-profile]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111663 --- Comment #2 from CVS Commits --- The master branch has been updated by Sergei Trofimovich : https://gcc.gnu.org/g:2551e10038a70901f30b2168e6e3af4536748f3c commit r14-4439-g2551e10038a70901f30b2168e6e3af4536748f3c Author: Sergei Trofimovich Date: Mon Oct 2 12:08:17 2023 +0100 Makefile.tpl: disable -Werror for feedback stage [PR111663] Without the change profiled bootstrap fails for various warnings on master branch as: $ ../gcc/configure $ make profiledbootstrap ... gcc/genmodes.cc: In function âint main(int, char**)â: gcc/genmodes.cc:2152:1: error: âgcc/build/genmodes.gcdaâ profile count data file not found [-Werror=missing-profile] ... gcc/gengtype-parse.cc: In function âvoid parse_error(const char*, ...)â: gcc/gengtype-parse.cc:142:21: error: â%sâ directive argument is null [-Werror=format-overflow=] The change removes -Werror just like autofeedback does today. / PR bootstrap/111663 * Makefile.tpl (STAGEfeedback_CONFIGURE_FLAGS): Disable -Werror. * Makefile.in: Regenerate.
[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111694 --- Comment #4 from Andrew Macleod --- (In reply to Richard Biener from comment #3) > Looks like some frange / relation mistake then. l_3(D) [frange] double [-Inf, +Inf] Equivalence set : [l_3(D), r_4(D)] : _1 = __builtin_signbit (l_3(D)); if (_1 != 0) goto ; [INV] else goto ; [INV] 3->6 (T) _1 : [irange] int [-INF, -1][1, +INF] 3->6 (T) l_3(D) : [frange] double [-Inf, -0.0 (-0x0.0p+0)] 3->4 (F) _1 : [irange] int [0, 0] 3->4 (F) l_3(D) : [frange] double [0.0 (0x0.0p+0), +Inf] : _2 = __builtin_signbit (r_4(D)); Yeah, we know l_3 and r_4 are equivalent, and we also know that on the edge 3->4 l_3 has the range double [0.0 (0x0.0p+0), +Inf] When we miss is that with an equivalence, we also have to put -0.0 back into the range. We currently don't so we think we can fold the second signbit call. If I fix that, we then see r_4(D) [frange] double [-0.0 (-0x0.0p+0), +Inf] which prevents the folding. I need to audit to see if there are other places where we may have to "adjust" equivalence range, or how best to deal with this in the general case.
[Bug c++/111717] syntax error When CTAD encounters complex alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717 Andrew Pinski changed: What|Removed |Added Keywords||c++-lambda --- Comment #2 from Andrew Pinski --- This looks like another one of the lamdba inside a decltype for a type alias issues.
[Bug debug/111716] call site parameter not matching with formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
--- Comment #4 from Andrew Pinski ---
Short testcase:
```
struct f
{
int a[10];
int b[10];
int c;
int d[10];
int e[10];
};
void g(int a[10], int b[10], int e, int i[10], int j[10]);
void h(void *a1)
{
struct f *a = (struct f*)a1;
g(a->a, a->b, a->c, a->d, a->e);
}
```
[Bug debug/111716] call site parameter not matching with formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716 --- Comment #3 from King Lok Chung --- (In reply to Andrew Pinski from comment #1) > (In reply to King Lok Chung from comment #0) > > I also find that the type of the parameter is not propagated correctly. For > > example, an array type is propagated as a pointer type. Should I open > > another bug report for this? > > array types decay to pointers for parameters ... I know they are the same most of the time; however, knowing the variable is an array will be more beneficial than just knowing it as a standard pointer, as an array implies the data will be within a bounded area, while a pointer type will not be able to make such an implication.
[Bug debug/111716] call site parameter not matching with formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716
Andrew Pinski changed:
What|Removed |Added
Target|riscv64-linux-gnu |riscv64-linux-gnu
||x86_64-linux-gnu
||aarch64-linux-gnu
--- Comment #2 from Andrew Pinski ---
So it looks like the first argument is passed through with no change and that
is not recorded ...
It happens on x86_64, aarch64 too.
The testcase I was using was the preprocessed source from bug 111680 and add to
the following to the end:
```
void run_benchmark( void *vargs ) {
struct bench_args_t *args = (struct bench_args_t *)vargs;
bfs(args->nodes, args->edges, args->starting_node, args->level,
args->level_counts);
}
```
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Comment #10 from Alexander Monakov ---
(In reply to Lukas Grätz from comment #9)
> I also wondered whether
>
> int bar_alias (void) { return bar_original(); }
>
> could be a portable alternative to attribute alias. Except that current GCC
> does not translate it that way.
That's because function addresses are significant and so
_alias == _original
must evaluate to false, but would be true for aliases.
In theory compilers could do better by introducing fall-through aliases:
https://gcc.gnu.org/wiki/cauldron2019talks?action=AttachFile=view=fallthrough-aliases.pdf
[Bug c++/111717] syntax error When CTAD encounters complex alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717
--- Comment #1 from 康桓瑋 ---
#include
namespace std {
constexpr size_t dynamic_extent = -1;
template
class extents { };
template
using dextents = decltype([](index_sequence) {
return extents{};
}(make_index_sequence{}));
// this works well
static_assert(std::is_same_v<
dextents,
extents>
);
template
class mdspan {
template
explicit mdspan(Ptr ptr, Integrals... exts);
};
template
explicit mdspan(ElementType*, Integrals...)
->mdspan>;
}
https://godbolt.org/z/E45dcb4G8
[Bug c++/111717] New: syntax error When CTAD encounters complex alias template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111717 Bug ID: 111717 Summary: syntax error When CTAD encounters complex alias template Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: hewillk at gmail dot com Target Milestone: ---
[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111643
--- Comment #9 from Lukas Grätz ---
Thanks for everything, it seemed to be a misunderstanding from my side anyway
and the documentation fix should help others.
I am sorry for being silent, I was sick for a few days. As for my original
problem, I am thinking of opening a new report, because I realized there could
be another solution without flatten. To explain a bit more, we have
bar_original() and bar_new(), the latter should behave identical to the former
except one additional statement, the "instrumentation". Since the
instrumentation can be done in two assembler instructions only, the overhead of
bar_new() calling bar_original() is not negligible.
int bar_original (int x) { /* CODE */ }
unsigned int trace_buffer[512];
uint8_t trace_pos;
#define FUNCTION_NUMBER_bar 0x686
int bar_new (int x) {
trace_buffer[trace_pos++] = 0x686; // instrumentation
return bar_original(x);
}
My idea: Do not touch the stack inside bar_new() and replace the call in
bar_new() with a jump or better a fall-through to bar_original(). This is
possible, because both functions have the same signature. It could save around
4 instructions and some stack memory. I have a lot of such functions after my
instrumentation step.
I also wondered whether
int bar_alias (void) { return bar_original(); }
could be a portable alternative to attribute alias. Except that current GCC
does not translate it that way.
[Bug debug/111716] call site parameter not matching with formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716 --- Comment #1 from Andrew Pinski --- (In reply to King Lok Chung from comment #0) > I also find that the type of the parameter is not propagated correctly. For > example, an array type is propagated as a pointer type. Should I open > another bug report for this? array types decay to pointers for parameters ...
[Bug tree-optimization/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code --- Comment #4 from Andrew Pinski --- (In reply to Carlos Galvez from comment #3) > Thanks for the quick response! Unfortunately we are stuck on GCC 9 for > reasons so I'll try to shuffle the code around a bit to make it work :) Using -fno-ivopts is another options since that is where the bad code is introduced.
[Bug debug/111716] New: call site parameter not matching with formal parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111716 Bug ID: 111716 Summary: call site parameter not matching with formal parameter Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: king.chung at manchester dot ac.uk Target Milestone: --- Created attachment 56070 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56070=edit The C source code to produce the error The call site information in the caller does not match the parameter of the callee. Caller call site DWARF: <2>: Abbrev Number: 17 (DW_TAG_call_site) DW_AT_call_return_pc: 0x10a10 DW_AT_call_tail_call: 1 DW_AT_call_origin : <0xa73> <3><1000>: Abbrev Number: 1 (DW_TAG_call_site_parameter) <1001> DW_AT_location: 1 byte block: 5a (DW_OP_reg10 (a0)) <1003> DW_AT_call_value : 3 byte block: a3 1 5a (DW_OP_entry_value: (DW_OP_reg10 (a0))) <3><1007>: Abbrev Number: 1 (DW_TAG_call_site_parameter) <1008> DW_AT_location: 1 byte block: 5b (DW_OP_reg11 (a1)) <100a> DW_AT_call_value : 6 byte block: a3 1 5a 23 80 20 (DW_OP_entry_value: (DW_OP_reg10 (a0)); DW_OP_plus_uconst: 4096) <3><1011>: Abbrev Number: 1 (DW_TAG_call_site_parameter) <1012> DW_AT_location: 1 byte block: 5d (DW_OP_reg13 (a3)) <1014> DW_AT_call_value : 7 byte block: a3 1 5a 23 88 a0 2 (DW_OP_entry_value: (DW_OP_reg10 (a0)); DW_OP_plus_uconst: 36872) <3><101c>: Abbrev Number: 1 (DW_TAG_call_site_parameter) <101d> DW_AT_location: 1 byte block: 5e (DW_OP_reg14 (a4)) <101f> DW_AT_call_value : 7 byte block: a3 1 5a 23 88 a2 2 (DW_OP_entry_value: (DW_OP_reg10 (a0)); DW_OP_plus_uconst: 37128) <3><1027>: Abbrev Number: 0 <2><1028>: Abbrev Number: 0 Callee parameter: <1>: Abbrev Number: 30 (DW_TAG_subprogram) DW_AT_external: 1 DW_AT_name: bfs DW_AT_decl_file : 6 DW_AT_decl_line : 53 DW_AT_decl_column : 6 DW_AT_prototyped : 1 DW_AT_declaration : 1 DW_AT_sibling : <0xa99> <2>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_type: <0xa99> <2>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_type: <0xa9e> <2>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_type: <0x88e> <2>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_type: <0xaa3> <2>: Abbrev Number: 3 (DW_TAG_formal_parameter) DW_AT_type: <0xaa8> <2>: Abbrev Number: 0 This is using the same binary as Bug111680. I used the following command to compile the code `riscv64-unknown-linux-gnu-gcc -static -O3 -Wall -Wno-unused-label -march=rv64imafd -g -fno-reorder-blocks -o bfs bfs.c local_support.c support.c harness.c` I also find that the type of the parameter is not propagated correctly. For example, an array type is propagated as a pointer type. Should I open another bug report for this?
[Bug tree-optimization/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 --- Comment #3 from Carlos Galvez --- Thanks for the quick response! Unfortunately we are stuck on GCC 9 for reasons so I'll try to shuffle the code around a bit to make it work :)
[Bug ipa/111672] Inappropriate function splitting during pass_split_functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111672 --- Comment #13 from Hanke Zhang --- (In reply to Andrew Pinski from comment #12) > (In reply to Hanke Zhang from comment #11) > > But I have never seen this '_FORTIFY_SOURCE' before. So I'm a confused as > > well. And when I try gcc@11.4 built in the default ubuntu 22.04, it's the > > same. So I don't know how to describe now. Thanks for your help anyway. > > Well Ubuntu's compiler defaults to defining _FORTIFY_SOURCE while the > upstream GCC does not. Ubuntu's compiler also defaults to building PIE > applications too. Thanks a lot. The _FORTIFY_SOURCE maybe the problem then.
[Bug c/110368] Incorrect "is used uninitialized" warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110368 --- Comment #7 from Sam James --- That said, I suppose we should do better here with -Wstrict-aliasing. No level detects it.
[Bug c++/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 --- Comment #2 from Andrew Pinski --- >From IV-OPTs dup: inv_expr 3: (-() _13 - () ) - -1 inv_expr 4: -() _13 - () That is totally bogus (that was even in GCC 8)
[Bug tree-optimization/111715] Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2023-10-06 Status|UNCONFIRMED |ASSIGNED --- Comment #2 from Richard Biener --- Created attachment 56069 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56069=edit more aggressive TBAA, prototype patch This is a prototype patch to get_alias_set to recognize a proper tail of the access path on the object we have punned to. I'm not sure it will work out this way. For better understanding a smaller testcase is required.
[Bug tree-optimization/111715] Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715 --- Comment #1 from Richard Biener --- Created attachment 56068 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56068=edit preprocessed source
[Bug tree-optimization/111715] New: Missed optimization in FRE because of weak TBAA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111715 Bug ID: 111715 Summary: Missed optimization in FRE because of weak TBAA Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- Jakub reports a spurious diagnostic with tree-affine.cc with the wide-int patches: > ./cc1plus -quiet -O2 -Wall -fno-exceptions /tmp/t.ii In file included from ../../gcc/coretypes.h:465, from ../../gcc/tree-affine.cc:22: In member function 'void widest_int_storage::set_len(unsigned int, bool) [with int N = 576]', inlined from 'void wi::copy(T1&, const T2&) [with T1 = widest_int_storage<576>; T2 = generic_wide_int >]' at ../../gcc/wide-int.h:2407:13, inlined from 'widest_int_storage& widest_int_storage::operator=(const T&) [with T = int; int N = 576]' at ../../gcc/wide-int.h:1805:12, inlined from 'generic_wide_int& generic_wide_int::operator=(const T&) [with T = int; storage = widest_int_storage<576>]' at ../../gcc/wide-int.h:1018:23, inlined from 'void aff_combination_remove_elt(aff_tree*, unsigned int)' at ../../gcc/tree-affine.cc:596:34: ../../gcc/wide-int.h:1856:14: warning: 'void* memcpy(void*, const void*, size_t)' offset [0, 7] is out of the bounds [0, 0] [-Warray-bounds=] ../../gcc/wide-int.h:1857:12: warning: 'void free(void*)' called on a pointer to an unallocated object '1' [-Wfree-nonheap-object] In member function 'void widest_int_storage::set_len(unsigned int, bool) [with int N = 576]', inlined from 'void wi::copy(T1&, const T2&) [with T1 = widest_int_storage<576>; T2 = generic_wide_int >]' at ../../gcc/wide-int.h:2407:13, inlined from 'widest_int_storage& widest_int_storage::operator=(const T&) [with T = int; int N = 576]' at ../../gcc/wide-int.h:1805:12, inlined from 'generic_wide_int& generic_wide_int::operator=(const T&) [with T = int; storage = widest_int_storage<576>]' at ../../gcc/wide-int.h:1018:23, inlined from 'void aff_combination_convert(aff_tree*, tree)' at ../../gcc/tree-affine.cc:256:34: ../../gcc/wide-int.h:1856:14: warning: 'void* memcpy(void*, const void*, size_t)' offset [0, 7] is out of the bounds [0, 0] [-Warray-bounds=] ../../gcc/wide-int.h:1857:12: warning: 'void free(void*)' called on a pointer to an unallocated object '1' [-Wfree-nonheap-object] that's caused by failing to CSE in MEM [(struct widest_int_storage *)comb_13(D)].elts[_6].coef.D.132464.len = 1; _49 = (sizetype) _6; _50 = _49 * 88; _101 = _50 + 104; _74 = comb_13(D) + _101; *_74 = 1; _80 = MEM [(struct widest_int_storage *)comb_13(D)].elts[_6].coef.D.132464.len; where the view-convert pun in the MEM_REF makes it get the alias set of wide-int storage which conflicts with the *_74 store of a 'long'. We fail to pick up the store to an 'int' (the len) and possible disambiguation with TBAA. That's somewhat by design since we are faced with a lot of address-taking and dereferencing of pointers as part of C++ abstraction. But the "tail" is still a valid access.
[Bug c++/111714] Strange behavior when casting std::size_t to bool, UB or compiler bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 --- Comment #1 from Richard Biener --- looks like a bug in GCC 9.x, note that's EOL and thus will receive no fixes. You can try to bisect where it was fixed since GCC 10.1 seems to work. There might be a duplicate fixed bugreport for this.
[Bug driver/111700] ICE: SIGSEGV in needs_read_p (input.cc:598) with -fdiagnostics-format=sarif-file or -fdiagnostics-format=sarif-stderr on pre-processed input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111700 David Malcolm changed: What|Removed |Added Last reconfirmed||2023-10-06 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- Thanks for filing this bug. Confirmed with trunk and gcc 13: trunk: https://godbolt.org/z/7cb1Ed83r 13.2: https://godbolt.org/z/GzYfMnbss I'm working on a fix.
[Bug c++/111714] New: Strange behavior when casting std::size_t to bool, UB or compiler bug?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111714 Bug ID: 111714 Summary: Strange behavior when casting std::size_t to bool, UB or compiler bug? Product: gcc Version: 9.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: carlosgalvezp at gmail dot com Target Milestone: --- Created attachment 56067 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56067=edit Test case Hi! We are bumping from GCC 7.5 to 9.4 and one of our tests fail. The test works on GCC 10 and above, as well as Clang trunk. Sanitizers (GCC and Clang) and Valgrind don't report anything. I have managed to create a minimal example here: https://godbolt.org/z/3q7c4qYzE (attached to the bug as a file as well). There's also comments about changes to the code that can make the test pass. This smells a lot like UB, but I can't figure out what is wrong with the code. Otherwise it could well be a compiler bug. Is there anything obvious you can see that could explain the behavior? Thanks!
[Bug c++/104255] parsing function signature fails when it uses a function parameter outside of an unevaluated context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104255 Patrick Palka changed: What|Removed |Added CC||hewillk at gmail dot com --- Comment #6 from Patrick Palka --- *** Bug 111712 has been marked as a duplicate of this bug. ***
[Bug c++/111712] Syntax error when passing function parameter as NTTP in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111712 Patrick Palka changed: What|Removed |Added CC||ppalka at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Patrick Palka --- this seems to be a dup of PR104255, using a trailing requires instead of a trailing return type *** This bug has been marked as a duplicate of bug 104255 ***
[Bug c/111708] Calling external global function instead of local static function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708 --- Comment #5 from Kirill Frolov --- C standard states,that: 6.2.2 Linkages of identifiers 7) If, within a translation unit, the same identifier appears with both internal and external linkage, the behavior is undefined. So, I think only ICC has adequate behaviour. Other compilers miss at least warning message.
[Bug c/111708] Calling external global function instead of local static function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708 --- Comment #4 from Kirill Frolov --- With updated source ICC still gives an error. MSVC works from my point of view correcly, same as Clang. Lets see to a C-standard (https://files.lhmouse.com/standards/ISO%20C%20N2176.pdf), section 6.2.2 states that: | 4) For an identifier declared with the storage-class specifier extern | in a scope in which a prior declaration of that identifier is visible [31] | if the prior declaration specifies internal or external linkage, | the linkage of the identifier at the later declaration is the same as | the linkage specified at the prior declaration. If no prior declaration | _is_ _visible_, or if the prior declaration specifies no linkage, then the | identifier has external linkage. | [31] As specified in 6.2.1, the later declaration might hide the | prior declaration. Lets see section 6.2.1: | 4) ... Within the inner scope, the identifier designates the entity | declared in the inner scope; the entity declared in the outer scope | is hidden (and _not_ _visible_) within the inner scope. As a result, I must conclude that GCC generates code right, but Clang, MSVC and ICC works incorrectly. But this happens with "-Os" options. With "-O0" option GCC generates _wrong_ _code_, as it avoids calling of _external_ function (https://godbolt.org/z/6GbPdc9vT): main: pushrbp mov rbp, rsp sub rsp, 16 mov DWORD PTR [rbp-4], edi mov QWORD PTR [rbp-16], rsi mov eax, DWORD PTR [rbp-4] mov edi, eax callf leave ret f: pushrbp mov rbp, rsp sub rsp, 32 mov DWORD PTR [rbp-20], edi mov eax, DWORD PTR [rbp-20] mov DWORD PTR [rbp-4], eax cmp DWORD PTR [rbp-4], 0 jg .L4 mov eax, 0 jmp .L5 .L4: mov eax, DWORD PTR [rbp-4] sub eax, 1 mov edi, eax callf .L5: leave ret In any case, GCC generated different code with -O0 and -Os, and such behaviour is definitely a bug.
[Bug c/111708] Calling external global function instead of local static function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111708
--- Comment #3 from Kirill Frolov ---
Looks like example demonstrates undefined behaviour. This article
(https://wiki.sei.cmu.edu/confluence/display/c/DCL36-C.+Do+not+declare+an+identifier+with+conflicting+linkage+classifications)
contains table, which shows that I can use "extern" keyword in second
declaration to refer symbol with internal linkage. So I fixed the
source:
static int f(int);
int main(int argc, const char *argv[])
{
(void)argv;
return f(argc);
}
static int f(int f)
{
int x = f;
{
extern int f(int);
if (x < 1)
return 0;
else
return f(x - 1);
}
}
The problem still persist. See an example: https://godbolt.org/z/reGbM67Kj
GCC still references external function "f", but I expect that internal function
must be referenced instead.
[Bug libstdc++/111685] Segfault while sorting on array element address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111685 --- Comment #12 from Fedor Chelnokov --- Related discussion: https://stackoverflow.com/q/77224270/7325599
[Bug libstdc++/111713] libstdc++ accepts invalid regular expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=29 --- Comment #2 from Andrew Pinski --- Dup of bug 29?
[Bug tree-optimization/109088] GCC does not always vectorize conditional reduction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109088 --- Comment #14 from Richard Biener --- Sorry for the delay - but this looks exactly like Robins transform to COND_ADD, no? But sure, the current code doesn't handle a reduction path through multiple stmts but when if-conversion would convert the final add to a COND_ADD then it should be a matter of teaching tree-vect-loop.cc:check_reduction_path about conditional operations?
[Bug libstdc++/111713] libstdc++ accepts invalid regular expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713 --- Comment #1 from 康桓瑋 --- The "+*" part is not valid.
[Bug libstdc++/111713] New: libstdc++ accepts regular expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111713
Bug ID: 111713
Summary: libstdc++ accepts regular expression
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: hewillk at gmail dot com
Target Milestone: ---
#include
#include
#include
int main() {
std::regex invalid_re("AAA\\s*(\\w+*)"); // should throw
std::smatch match;
std::string str("AAA BBB");
assert(std::regex_match(str, match, invalid_re));
std::cout << match[1] << "\n"; // libstdc++ prints BBB
}
https://godbolt.org/z/1zrv1Wf71
[Bug c++/111712] Syntax error when passing function parameter as NTTP in requires-clause
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111712
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed||2023-10-06
Status|UNCONFIRMED |NEW
--- Comment #1 from Andrew Pinski ---
Reduced testcase:
```
template
struct s
{
constexpr static bool t = B;
constexpr bool operator()() { return t; }
};
template
void f(s b)
requires requires { typename s; };
int main() {
f(s{});
}
```
Note MSVC accepts the above ...
[Bug middle-end/111260] [14 Regression] arm: ice in maybe_legitimize_operand, at optabs.cc:8054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #8 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #7)
> Better reduced testcase:
> ```
> long f(int a)
> {
> int b = 822920;
> int t = a == b;
> return t * (long)b;
> }
> ```
Here is one that ICEs on both arm and aarch64:
```
int f1(long long a)
{
int b = 822920;
int t = a == b;
return t * (int)b;
}
```
[Bug middle-end/111260] [14 Regression] arm: ice in maybe_legitimize_operand, at optabs.cc:8054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260
--- Comment #7 from Andrew Pinski ---
Better reduced testcase:
```
long f(int a)
{
int b = 822920;
int t = a == b;
return t * (long)b;
}
```
[Bug middle-end/111260] [14 Regression] arm: ice in maybe_legitimize_operand, at optabs.cc:8054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260 --- Comment #6 from Andrew Pinski --- *** Bug 111711 has been marked as a duplicate of this bug. ***
[Bug middle-end/111711] [14 Regression] ICE: in maybe_legitimize_operand, at optabs.cc:8046 at -O1 with division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #3 from Andrew Pinski --- So I looked further into this and it was actually a dup when I said it was not. Anyways just marking it as a dup of bug 111260 in the end. *** This bug has been marked as a duplicate of bug 111260 ***
[Bug middle-end/111260] [14 Regression] arm: ice in maybe_legitimize_operand, at optabs.cc:8054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260 Andrew Pinski changed: What|Removed |Added Target|arm-linux-gnueabihf |arm-*-* aarch64-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-06 Ever confirmed|0 |1 See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=111711 --- Comment #5 from Andrew Pinski --- (In reply to Zdenek Sojka from comment #4) > (In reply to Andrew Pinski from comment #3) > > (In reply to Zdenek Sojka from comment #2) > > ... > > > > ... > > > > That is 100% a different bug and should be filed separately. > > Than you for checking, I've created PR111711 for that Actually it looks like I might be wrong in the end. For the reduced testcase in comment #1 we have: int __trans_tmp_5; long long int g_263.0_1; int func_16_l_1358.1_2; _Bool _4; [local count: 1073741824]: g_263.0_1 = g_263; _4 = g_263.0_1 == 357942; __trans_tmp_5_6 = _4 ? 357942 : 357941; In this case, 357942 are 2 different modes (SImode and DImode). Still causes by r14-2667-gceae1400cf24f329393e96dd9720 .
[Bug middle-end/111260] [14 Regression] arm: ice in maybe_legitimize_operand, at optabs.cc:8054
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111260 Andrew Pinski changed: What|Removed |Added Component|target |middle-end Summary|arm: ice in |[14 Regression] arm: ice in |maybe_legitimize_operand, |maybe_legitimize_operand, |at optabs.cc:8054 |at optabs.cc:8054 Keywords|needs-bisection | Target Milestone|--- |14.0
[Bug middle-end/111711] [14 Regression] ICE: in maybe_legitimize_operand, at optabs.cc:8046 at -O1 with division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711 --- Comment #2 from Andrew Pinski --- (In reply to Andrew Pinski from comment #1) > It was introduced by r14-2667-gceae1400cf24f329393e96dd9720 . > > We have: > long int x; > int _3; > _Bool _5; > _3 = 0 / 0; > _5 = _3 == 822920; > x_7 = _5 ? 822920 : 0; > > If I disable the added checks on dealing with rtx_equal_p, the ICE goes away. I mean if I disable the added code trying to reuse the constants, the ICE goes away. > The problem is the mode for the result does not match the mode for the > comparison (DImode for the result of the conditional and SImode for the > comparison).
[Bug middle-end/111711] [14 Regression] ICE: in maybe_legitimize_operand, at optabs.cc:8046 at -O1 with division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Keywords|needs-bisection | Last reconfirmed||2023-10-06 Status|UNCONFIRMED |NEW --- Comment #1 from Andrew Pinski --- It was introduced by r14-2667-gceae1400cf24f329393e96dd9720 . We have: long int x; int _3; _Bool _5; _3 = 0 / 0; _5 = _3 == 822920; x_7 = _5 ? 822920 : 0; If I disable the added checks on dealing with rtx_equal_p, the ICE goes away. The problem is the mode for the result does not match the mode for the comparison (DImode for the result of the conditional and SImode for the comparison).
[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111699 Andrew Pinski changed: What|Removed |Added Target Milestone|14.0|13.3 Known to work|13.2.1 |10.4.0, 14.0 Known to fail|14.0| --- Comment #7 from Andrew Pinski --- Will be backporting it in a few days to the other open branches as this is a latent bug.
[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111699 --- Comment #6 from CVS Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:e77428a9a336f57e3efe3eff95f2b491d7e9be14 commit r14-4432-ge77428a9a336f57e3efe3eff95f2b491d7e9be14 Author: Andrew Pinski Date: Thu Oct 5 12:21:19 2023 -0700 MATCH: Fix infinite loop between `vec_cond(vec_cond(a,b,0), c, d)` and `a & b` Match has a pattern which converts `vec_cond(vec_cond(a,b,0), c, d)` into `vec_cond(a & b, c, d)` but since in this case a is a comparison fold will change `a & b` back into `vec_cond(a,b,0)` which causes an infinite loop. The best way to fix this is to enable the patterns for vec_cond(*,vec_cond,*) only for GIMPLE so we don't get an infinite loop for fold any more. Note this is a latent bug since these patterns were added in r11-2577-g229752afe3156a and was exposed by r14-3350-g47b833a9abe1 where now able to remove a VIEW_CONVERT_EXPR. OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions. PR middle-end/111699 gcc/ChangeLog: * match.pd ((c ? a : b) op d, (c ? a : b) op (c ? d : e), (v ? w : 0) ? a : b, c1 ? c2 ? a : b : b): Enable only for GIMPLE. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr111699-1.c: New test.
[Bug target/111677] arm64 build fails unrecognizable insn [REGRESSION]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 --- Comment #2 from Gianfranco --- Thanks, Debian syncs the branch fixes from time to time, last time was up to * Update to git 20230913 from the gcc-13 branch. Indeed, I requested to sync again sources. thanks!
[Bug rtl-optimization/111711] [14 Regression] ICE: in maybe_legitimize_operand, at optabs.cc:8046 at -O1 with division by zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111711 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||needs-bisection
[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111709 Richard Biener changed: What|Removed |Added Target Milestone|--- |13.3 --- Comment #9 from Richard Biener --- Does it work on trunk?
[Bug rtl-optimization/111702] [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111702 Richard Biener changed: What|Removed |Added Target Milestone|--- |14.0 Keywords||needs-bisection
[Bug middle-end/111701] [11/12/13/14 Regression] wrong code for __builtin_signbit(x*x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111701 Richard Biener changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-10-06 Priority|P3 |P2 Target Milestone|--- |11.5 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed.
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 Mathieu Malaterre changed: What|Removed |Added Attachment #56065|0 |1 is obsolete|| --- Comment #15 from Mathieu Malaterre --- Created attachment 56066 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56066=edit widen_mul_test.cc
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 --- Comment #14 from Mathieu Malaterre --- (In reply to Xi Ruoyao from comment #12) > (In reply to Mathieu Malaterre from comment #10) > > I could not reduce to a single *.cc file. The function needs to be in an alt > > file 'foo.cc'. > > Can you try copying the functions provided in foo.cc into the test case but > and noipa attribute for them? Updated, thanks for the pointer. See comment #13. Here is what I see on my side (Debian/sid/armhf): $ g++-13 -std=c++11 -o works -O2 -fno-tree-vectorize -g -Wfatal-errors -Werror -Wall -Wextra -Wconversion -Wpedantic -DNDEBUG -fno-exceptions -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee widen_mul_test.cc -> success $ valgrind --leak-check=yes --error-exitcode=1 ./works -> success (no leak) $ clang++-16 -std=c++11 -Wfatal-errors -Werror -Wall -Wextra -Wconversion -Wno-unknown-attributes -O2 -DNDEBUG -fno-exceptions -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -o works0 widen_mul_test.cc -> success Now simply remove `-fno-tree-vectorize`: $ g++ -std=c++11 -o fails -O2 -g -Wfatal-errors -DNDEBUG -fno-exceptions -march=armv7-a -mfpu=neon-vfpv4 -mfloat-abi=hard -mfp16-format=ieee widen_mul_test.cc -> failure (abort)
[Bug target/111231] armhf: Miscompilation with -O2/-fno-exceptions level (-fno-tree-vectorize is working)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231 Mathieu Malaterre changed: What|Removed |Added Attachment #55816|0 |1 is obsolete|| Attachment #55990|0 |1 is obsolete|| Attachment #55991|0 |1 is obsolete|| --- Comment #13 from Mathieu Malaterre --- Created attachment 56065 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56065=edit widen_mul_test.cc
