[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #4 from Andrew Pinski --- (In reply to wangwen from comment #3) > when the global pointer variety has an initialized value which is not NULL, > then the value should be an address, so the initialized value should be > recalculated when dynamically loaded. > > Now the problem is the array member and pointer member of struct data will > be place at same section, then the loader would not know how to calculate > the initialized value, because it has no idea the value is an address or is > normal data. > > it is a long story if you are interested in how the problem is brought up. > I pasted the link where we are trying to solve it. > https://github.com/azure-rtos/threadx/issues/230 Right, that means you are not processing the runtime relocations here correctly when doing a load of the module. The section .data.rel* just means it will have a runtime relocation which is in its own section. The runtime relocation section is created by the linker. Now if you are not doing a full link, in the object file there are still static relocations. (you can also get keep around relocations by the linker too via the -q/--emit-relocs option too). See https://sourceware.org/binutils/docs-2.40/ld.html there. But this is now outside of a GCC bug/question and really overlaps with the loader of threadx/azure-rtos and the linker.
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #3 from wangwen at microsoft dot com --- when the global pointer variety has an initialized value which is not NULL, then the value should be an address, so the initialized value should be recalculated when dynamically loaded. Now the problem is the array member and pointer member of struct data will be place at same section, then the loader would not know how to calculate the initialized value, because it has no idea the value is an address or is normal data. it is a long story if you are interested in how the problem is brought up. I pasted the link where we are trying to solve it. https://github.com/azure-rtos/threadx/issues/230
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #2 from Andrew Pinski --- as far as I understand, there will be a relocation section which is there for runtime relocations and they basically "instructions" on how the relocation should happen including the location of where the relocation will happen.
[Bug target/110709] how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709 --- Comment #1 from Andrew Pinski --- I don't understand your question since if we look at the output of GCC we get: .LC0: .ascii "const char *text\000" .section.data.rel.local,"aw" .align 2 .type user_test, %object .size user_test, 112 user_test: .ascii "struct member testChArray\000" .space 74 .word 10 .word .LC0 .word 27 Only text will have a relocation associated with it since that is the only one that needs it. Everything else has no need for a relocation since it is just data.
[Bug c/110709] New: how to handle the initialization of global struct data for position independent executable application.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110709
Bug ID: 110709
Summary: how to handle the initialization of global struct data
for position independent executable application.
Product: gcc
Version: 12.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: wangwen at microsoft dot com
Target Milestone: ---
our project is to dynamically load applications in azure-rtos. the application
is compiled with "-O0 -ffunction-sections -Wall -fno-plt -fpie
-msingle-pic-base -mno-pic-data-is-text-relative -fPIC"
when there are global variables defined in below ways, the initialized value of
struct members can't be loaded correctly.
"
typedef struct
{
char testChArray[100];
int test_A;
const char *text;
int test_B;
}GCC_TEST_t;
GCC_TEST_t user_test = {"struct member testChArray",10,"const char *text",27};
"
if the pointer member "text" is initialized when "user_test" is declared. the
"user_test" will be placed at section ".data.rel.local"; but other members like
"testChArray" would be initialized with relocated value which would be wrong,
So we wonder if PIC supports such struct data initialization that struct data
is composed with array and pointer and initialized when declared.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #17 from Oleg Endo --- (In reply to Rin Okuyama from comment #16) > The fix has been cherry-picked for NetBSD: > https://mail-index.netbsd.org/source-changes/2023/07/18/msg146078.html > > Let me thank you again, Oleg! Sure, you're welcome. Let me know if there's anything else. When you open an SH related PR here in GCC's bugzilla, please add me to the CC list, or else I might not see it timely.
[Bug target/101469] wrong code with "-O2 -fPIE" for SH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101469 --- Comment #16 from Rin Okuyama --- The fix has been cherry-picked for NetBSD: https://mail-index.netbsd.org/source-changes/2023/07/18/msg146078.html Let me thank you again, Oleg!
[Bug target/110438] generating all-ones zmm needs dep-breaking pxor before ternlog
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110438 --- Comment #6 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:c3f1768b21e9d994c4f090405e863feb06a54002 commit r14-2596-gc3f1768b21e9d994c4f090405e863feb06a54002 Author: liuhongt Date: Mon Jul 17 12:50:17 2023 +0800 Remove # from one_cmpl2 assemble output. optimize_insn_for_speed () in assemble output is not aligned with splitter condition, and it cause an ICE when building SPEC2017 blender_r. libpng/pngread.c: In function âpng_read_imageâ: libpng/pngread.c:786:1: internal compiler error: in final_scan_insn_1, at final.cc:2813 786 | } | ^ 0x73ac3d final_scan_insn_1 ../../gcc/final.cc:2813 0xb3420b final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*) ../../gcc/final.cc:2887 0xb344c4 final_1 ../../gcc/final.cc:1979 0xb34f64 rest_of_handle_final ../../gcc/final.cc:4240 0xb34f64 execute ../../gcc/final.cc:4318 gcc/ChangeLog: PR target/110438 * config/i386/sse.md (one_cmpl2): Remove # from assemble output.
[Bug target/110591] [i386] (Maybe) Missed optimisation: _cmpccxadd sets flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110591 --- Comment #5 from Hongtao.liu --- Fixed in GCC14.
[Bug target/110591] [i386] (Maybe) Missed optimisation: _cmpccxadd sets flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110591 --- Comment #4 from CVS Commits --- The master branch has been updated by hongtao Liu : https://gcc.gnu.org/g:06cc38c1c350b34cbd6dde23aefca32442c07a73 commit r14-2595-g06cc38c1c350b34cbd6dde23aefca32442c07a73 Author: liuhongt Date: Mon Jul 10 14:12:07 2023 +0800 Add peephole to eliminate redundant comparison after cmpccxadd. Similar like we did for cmpxchg, but extended to all ix86_comparison_int_operator since cmpccxadd set EFLAGS exactly same as CMP. When operand order in compare insn is same as that in cmpccxadd, compare insn can be eliminated directly. When operand order is swapped in compare insn, only optimize cmpccxadd + cmpl + jcc/setcc to cmpccxadd + jcc/setcc when FLAGS_REG is dead after jcc/setcc. gcc/ChangeLog: PR target/110591 * config/i386/sync.md (cmpccxadd_): Adjust the pattern to explicitly set FLAGS_REG like *cmp_1, also add extra 3 define_peephole2 after the pattern. gcc/testsuite/ChangeLog: * gcc.target/i386/pr110591.c: New test. * gcc.target/i386/pr110591-2.c: New test.
[Bug driver/110522] `-fdiagnostics-format=sarif-file`: file name conflicts / races
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110522 Roman Lebedev changed: What|Removed |Added CC||dmalcolm at redhat dot com, ||dseketel at redhat dot com, ||jwakely at redhat dot com --- Comment #2 from Roman Lebedev --- Would it please be possible to get an acknowledgement/rejection on this, please? It seems like a rather unexpected usability roadblock. Also, Dodji Seketeli's email from MAINTAINERS is unknown to bugzilla.
[Bug tree-optimization/110628] [14 regression] gcc.dg/tree-ssa/update-threading.c fails after r14-2383-g768f00e3e84123
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110628 --- Comment #4 from seurer at gcc dot gnu.org --- Created attachment 55563 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55563=edit All the intermediate files in a .tar.gz Here are all the files zipped up.
[Bug libstdc++/110708] std::format("{:%EEC %OOd}", std::chrono::system_clock::now()) should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110708 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2023-07-17 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED
[Bug libstdc++/110708] New: std::format("{:%EEC %OOd}", std::chrono::system_clock::now()) should be rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110708
Bug ID: 110708
Summary: std::format("{:%EEC %OOd}",
std::chrono::system_clock::now()) should be rejected
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
A chrono format string should only allow a single E or O modifier for each
flag.
[Bug middle-end/109557] __builtin_dynamic_object_size() does not work for simple testing case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109557
--- Comment #8 from qinzhao at gcc dot gnu.org ---
with the following slightly modified testing case, the same issue:
#include
#include
struct P {
int k;
int x[10];
} *p;
void store(int a, int b)
{
p = (struct P *)malloc (sizeof (struct P));
p->k = a;
p->x[b] = 0;
assert (__builtin_dynamic_object_size (p, 1) == sizeof (struct P));
return;
}
int main()
{
store(7, 7);
assert (__builtin_dynamic_object_size (p, 1) == sizeof (struct P));
free (p);
}
[opc@qinzhao-ol8u3-x86 109557]$ sh t
/home/opc/Install/latest/bin/gcc -O -fsanitize=bounds -fsanitize=object-size
-fstrict-flex-arrays=3 -fdump-tree-all t.c
a.out: t.c:20: main: Assertion `__builtin_dynamic_object_size (p, 1) == sizeof
(struct P)' failed.
t: line 19: 629958 Aborted (core dumped) ./a.out
[Bug driver/108022] [11/12/13 regression] -frecord-gcc-switches doesn't record preprocessor macros since r11-5739-g7caa49706316e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108022 --- Comment #6 from Sam James --- (In reply to Martin Liška from comment #5) > Yes, -ggdb3 seems to me like a reasonable solution. Note you can always > strip the debuginfo into a separate file. This doesn't really work for us, as building with (a lot of) debug info requires a lot more build-time resources (disk and RAM, mainly). We want to do these checks for everybody building things - keeping in mind we're a source-based distribution, and we don't make everyone build with debugging symbols. Building with -ggdb3 for everybody is not really an option. The existing behaviour has been pretty useful for us for many years, and we were hoping to extend it to CPPFLAGS too.
[Bug c++/110707] New: unused-but-set-variable in static lambda with deduced parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110707
Bug ID: 110707
Summary: unused-but-set-variable in static lambda with deduced
parameter
Product: gcc
Version: 13.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris0cotter at gmail dot com
Target Milestone: ---
With GCC-13.1 using `-std=c++20 -Wall`, the following code causes an
unused-but-set-variable warning for `f1` being unused.
https://godbolt.org/z/5vfEd7vr5
int foo() {
static auto f1 = [](int a) { return a;}; // warning: variable 'f1' set but
not used [-Wunused-but-set-variable]
static auto f2 = [](auto s) -> int { return f1(s); };
return f2(0);
}
The warning disappears if I replace `auto s` with `int s`, or if I remove the
return type from the second lambda ` -> int`.
[Bug c/110703] Incorrect "-Wfloat-conversion" diagnostic with _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110703 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-07-17 --- Comment #1 from Andrew Pinski --- It is basically the same as PR 68193 really.
[Bug ipa/110705] [11/12 Regression] ICE at -O2 and above: in gimplify_modify_expr, at gimplify.cc:6255 (on GCC-12.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110705 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE at -O2 and above: in|[11/12 Regression] ICE at |gimplify_modify_expr, at|-O2 and above: in |gimplify.cc:6255 (on|gimplify_modify_expr, at |GCC-12.x) |gimplify.cc:6255 (on ||GCC-12.x) Known to work||13.1.0, 9.5.0 Target Milestone|--- |11.5 Known to fail||10.1.0, 10.5.0, 11.3.0, ||11.4.0
[Bug fortran/95947] PACK intrinsic returns blank strings when an allocatable character array with allocatable length is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95947 --- Comment #7 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:95ddd2659849a904509067ec3a2770135149a722 commit r14-2586-g95ddd2659849a904509067ec3a2770135149a722 Author: Harald Anlauf Date: Sun Jul 16 22:17:27 2023 +0200 Fortran: intrinsics and deferred-length character arguments [PR95947,PR110658] gcc/fortran/ChangeLog: PR fortran/95947 PR fortran/110658 * trans-expr.cc (gfc_conv_procedure_call): For intrinsic procedures whose result characteristics depends on the first argument and which can be of type character, the character length will not be deferred. gcc/testsuite/ChangeLog: PR fortran/95947 PR fortran/110658 * gfortran.dg/deferred_character_37.f90: New test.
[Bug fortran/110658] MINVAL/MAXVAL and deferred-length character arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110658 --- Comment #3 from CVS Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:95ddd2659849a904509067ec3a2770135149a722 commit r14-2586-g95ddd2659849a904509067ec3a2770135149a722 Author: Harald Anlauf Date: Sun Jul 16 22:17:27 2023 +0200 Fortran: intrinsics and deferred-length character arguments [PR95947,PR110658] gcc/fortran/ChangeLog: PR fortran/95947 PR fortran/110658 * trans-expr.cc (gfc_conv_procedure_call): For intrinsic procedures whose result characteristics depends on the first argument and which can be of type character, the character length will not be deferred. gcc/testsuite/ChangeLog: PR fortran/95947 PR fortran/110658 * gfortran.dg/deferred_character_37.f90: New test.
[Bug middle-end/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110702 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Component|c |middle-end Keywords||needs-bisection Ever confirmed|0 |1 Last reconfirmed||2023-07-17 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug c/110702] [12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110702 Andrew Pinski changed: What|Removed |Added Summary|Wrong code at -O1 on|[12/13/14 Regression] Wrong |x86_64-linux-gnu|code at -O1 on |(regression since GCC-12.2) |x86_64-linux-gnu ||(regression since GCC-12.2) Keywords||wrong-code Known to work||11.4.0, 12.1.0 Known to fail||12.2.0, 12.3.0, 13.1.0 Target Milestone|--- |12.4
[Bug c/110699] [12/13/14 Regression] internal compiler error: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.cc:12754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110699 Andrew Pinski changed: What|Removed |Added Severity|normal |trivial
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Attachment #55561|0 |1 is obsolete|| --- Comment #83 from Jakub Jelinek --- Created attachment 55562 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55562=edit gcc14-bitint-wip.patch Now with support for passing large/huge _BitInt(N) INTEGER_CSTs as function arguments (although the RTL could be improved later), -fnon-call-exceptions support for large/huge _BitInt(N) loads/stores/divide/modulo and large/huge _BitInt(N) -> floating point conversions and support for uninited large/huge _BitInt SSA_NAMEs. Next will be ubsan and __builtin_*_overflow.
[Bug rtl-optimization/110701] [14 Regression] Wrong code at -O1/2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701 Andrew Pinski changed: What|Removed |Added See Also|https://gcc.gnu.org/bugzill | |a/show_bug.cgi?id=109040| --- Comment #4 from Andrew Pinski --- Maybe r14-2047-gd0e891406b16dc28905717de2
[Bug rtl-optimization/110701] [14 Regression] Wrong code at -O1/2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701
--- Comment #3 from Andrew Pinski ---
What GCC 13 did was
Trying 16 -> 17:
16: {r94:HI=r92:DI#0^0x3;clobber flags:CC;}
REG_DEAD r92:DI
REG_UNUSED flags:CC
17: r95:SI=sign_extend(r94:HI)
REG_DEAD r94:HI
Failed to match this instruction:
(set (reg:SI 95)
(ior:SI (and:SI (subreg:SI (reg:DI 92) 0)
(const_int 340 [0x154]))
(const_int 3 [0x3])))
[Bug rtl-optimization/110701] [14 Regression] Wrong code at -O1/2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701
Andrew Pinski changed:
What|Removed |Added
Keywords||wrong-code
Last reconfirmed||2023-07-17
Target Milestone|--- |14.0
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
--- Comment #2 from Andrew Pinski ---
Confirmed.
Trying 16 -> 17:
16: {r94:HI=r92:DI#0^0x3;clobber flags:CC;}
REG_DEAD r92:DI
REG_UNUSED flags:CC
17: r95:SI=sign_extend(r94:HI)
REG_DEAD r94:HI
Successfully matched this instruction:
(set (reg:SI 95)
(ior:SI (subreg:SI (reg:DI 92) 0)
(const_int 3 [0x3])))
allowing combination of insns 16 and 17
original costs 4 + 4 = 8
replacement cost 4
deferring deletion of insn with uid = 16.
modifying insn i317: {r95:SI=r92:DI#0|0x3;clobber flags:CC;}
REG_UNUSED flags:CC
REG_DEAD r92:DI
deferring rescan insn with uid = 17.
BUT r92 is defined by
(insn 12 11 13 2 (parallel [
(set (reg:DI 92)
(ashiftrt:DI (reg:DI 93 [ bD.2759 ])
(const_int 63 [0x3f])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":6:53 901 {ashrdi3_cvt}
(expr_list:REG_DEAD (reg:DI 93 [ bD.2759 ])
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_EQUAL (ashiftrt:DI (mem/c:DI (symbol_ref:DI ("b")
[flags 0x2] ) [1 bD.2759+0 S8 A64])
(const_int 63 [0x3f]))
(nil)
(insn 13 12 14 2 (set (subreg:HI (reg:DI 92) 0)
(not:HI (subreg:HI (reg:DI 92) 0))) "/app/example.cpp":6:53 816
{*one_cmplhi2_1}
(nil))
(insn 14 13 16 2 (parallel [
(set (subreg:HI (reg:DI 92) 0)
(and:HI (subreg:HI (reg:DI 92) 0)
(const_int 340 [0x154])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":6:53 596 {*andhi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
So that should be ok, well no because SI != HI here ... and
[Bug fortran/87142] Aliasing issue with overloaded assignment and allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142 Bug 87142 depends on bug 110618, which changed state. Bug 110618 Summary: Dependency between arguments when one is allocatable array whose dummy is intent(out) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Mikael Morin --- Fixed for 14.0.
[Bug c++/110706] New: [OpenMP] C++ class mapping fails to map reference-type members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110706
Bug ID: 110706
Summary: [OpenMP] C++ class mapping fails to map reference-type
members
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp, wrong-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
Target Milestone: ---
I probably get the syntax slightly wrong – and the example is stupid, but it
looks as if reference types do not get mapped but they should:
#pragma omp target enter data \
map(to:*this.0_1 [len: 16]) \
map(attach:this [bias: 0])
//
struct T {
int A[5];
};
static struct T y;
struct T2 {
struct T = y;
int x;
T2 () : x(5) { }
void foo() {
#pragma omp target enter data map(to:this[:1])
}
};
static struct T2 x;
int main() {
x.foo();
}
[Bug tree-optimization/110705] New: ICE at -O2 and above: in gimplify_modify_expr, at gimplify.cc:6255 (on GCC-12.x)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110705
Bug ID: 110705
Summary: ICE at -O2 and above: in gimplify_modify_expr, at
gimplify.cc:6255 (on GCC-12.x)
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: haoxintu at gmail dot com
Target Milestone: ---
Hi,
GCC-12.0 to GCC-12.3 versions fail to compile the following code.
$cat small.c
struct a {
long b;
};
union d {
struct a b;
int e;
}v;
long c;
int f;
static void g(union d h, long i) {
while (1)
switch (c)
case 4:
if (h.e)
c = 4;
}
void j(union d *h) {
if (f)
g(*h, h->b.b);
}
void k() { union d *h = j(h); }
$gcc-12 -w -O2 small.c
during IPA pass: inline
In function ‘j.part.0.isra’:
cc1: internal compiler error: in gimplify_modify_expr, at gimplify.cc:6255
0x664d30 gimplify_modify_expr
../../gcc/gimplify.cc:6255
0x97daf3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15098
0x982c3a gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7151
0x982c3a gimplify_and_add(tree_node*, gimple**)
../../gcc/gimplify.cc:496
0x982c3a internal_get_tmp_var
../../gcc/gimplify.cc:649
0x982ed1 get_initialized_tmp_var(tree_node*, gimple**, gimple**, bool)
../../gcc/gimplify.cc:681
0x982ed1 prepare_gimple_addressable
../../gcc/gimplify.cc:4580
0x983630 gimplify_addr_expr
../../gcc/gimplify.cc:6500
0x97dee8 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:15145
0x9952bf force_gimple_operand_1(tree_node*, gimple**, bool (*)(tree_node*),
tree_node*)
../../gcc/gimplify-me.cc:78
0x9953ff force_gimple_operand_gsi_1(gimple_stmt_iterator*, tree_node*, bool
(*)(tree_node*), tree_node*, bool, gsi_iterator_update)
../../gcc/gimplify-me.cc:115
0x9953ff force_gimple_operand_gsi(gimple_stmt_iterator*, tree_node*, bool,
tree_node*, bool, gsi_iterator_update)
../../gcc/gimplify-me.cc:141
0xa31bf9 ipa_param_adjustments::modify_call(cgraph_edge*, bool)
../../gcc/ipa-param-manipulation.cc:827
0x806a13 cgraph_edge::redirect_call_stmt_to_callee(cgraph_edge*)
../../gcc/cgraph.cc:1531
0x9f5ad4 inline_transform(cgraph_node*)
../../gcc/ipa-inline-transform.cc:783
0xb4248b execute_one_ipa_transform_pass
../../gcc/passes.cc:2330
0xb4248b execute_all_ipa_transforms(bool)
../../gcc/passes.cc:2393
0x80ce5f cgraph_node::expand()
../../gcc/cgraphunit.cc:1828
0x80ce5f cgraph_node::expand()
../../gcc/cgraphunit.cc:1788
0x80e39e expand_all_functions
../../gcc/cgraphunit.cc:1999
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug sanitizer/80578] -fsanitize=undefined report yields memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80578 Andrew Pinski changed: What|Removed |Added CC||marc.mutz at hotmail dot com --- Comment #4 from Andrew Pinski --- *** Bug 110704 has been marked as a duplicate of this bug. ***
[Bug sanitizer/110704] When ubsan reports an error, asan reports a leak in cp-demangle.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110704 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 80578 ***
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587 Roger Sayle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |roger at nextmovesoftware dot com --- Comment #11 from Roger Sayle --- My (upcoming) patch for PR88873 dramatically reduces the compile-time (with -O0) for this test case (by reducing the number of pseudos and reducing the number of reloads). But don't let that stop anyone from speeding up lra_final_code_change.
[Bug plugins/110610] [14 Regression] File insn-opinit.h not installed ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610 avieira at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from avieira at gcc dot gnu.org --- This should fix it. David please reopen if the problem still persists.
[Bug plugins/110610] [14 Regression] File insn-opinit.h not installed ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110610 --- Comment #10 from CVS Commits --- The master branch has been updated by Andre Simoes Dias Vieira : https://gcc.gnu.org/g:caabf0973a4e9a26421c94d540e3e20051e93e77 commit r14-2585-gcaabf0973a4e9a26421c94d540e3e20051e93e77 Author: Andre Vieira Date: Mon Jul 17 17:00:54 2023 +0100 Include insn-opinit.h in PLUGIN_H [PR110610] This patch fixes PR110610 by including insn-opinit.h in the INTERNAL_FN_H list, as insn-opinit.h is now required by internal-fn.h. This will lead to insn-opinit.h being installed in the plugin directory. gcc/ChangeLog: PR plugins/110610 * Makefile.in (INTERNAL_FN_H): Add insn-opinit.h.
[Bug sanitizer/110704] When ubsan reports an error, asan reports a leak in cp-demangle.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110704 --- Comment #1 from Marc Mutz --- GCC self-compiled, line numbers should be as at 275820c09e5: $ g++ --version g++ (GCC) 13.0.1 20230124 (experimental) $ (cd ~/C++/gcc; git log -1 --oneline) 275820c09e5 (HEAD, origin/trunk, origin/master, origin/HEAD) arm: Fix inclusion of arm-mlib.h header more than once (pr108505).
[Bug sanitizer/110704] New: When ubsan reports an error, asan reports a leak in cp-demangle.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110704 Bug ID: 110704 Summary: When ubsan reports an error, asan reports a leak in cp-demangle.c Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: marc.mutz at hotmail dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- When, in a combined asan+ubsan build, ubsan reports an error, then I consistently see a follow-up asan error. Example: 1: tests/auto/corelib/kernel/qobject/tst_qobject.cpp:8324:25: runtime error: downcast of address 0x7f3dd6cfe4e0 which does not point to an object of type 'Object' 1: 0x7f3dd6cfe4e0: note: object is of type 'QObject' 1: 00 00 00 00 80 3e d2 e1 3d 7f 00 00 c0 f5 e5 01 c0 60 00 00 00 00 20 00 00 00 00 00 00 00 00 00 1: ^~~ 1: vptr for 'QObject' 1: PASS : tst_QObject::declarativeData() 1: PASS : tst_QObject::asyncCallbackHelper() 1: PASS : tst_QObject::cleanupTestCase() 1: Totals: 114 passed, 0 failed, 0 skipped, 0 blacklisted, 3081ms 1: * Finished testing of tst_QObject * 1: 1: = 1: ==2734888==ERROR: LeakSanitizer: detected memory leaks 1: 1: Direct leak of 192 byte(s) in 8 object(s) allocated from: 1: #0 0x7f3de9bbd685 in __interceptor_realloc ../../../../gcc/libsanitizer/asan/asan_malloc_linux.cpp:85 1: #1 0x7f3ddc4be8fa in d_growable_string_resize x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4277 1: #2 0x7f3ddc4be8fa in d_growable_string_append_buffer x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4301 1: #3 0x7f3ddc4be8fa in d_growable_string_callback_adapter x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/cp-demangle.c:4318 1: 1: SUMMARY: AddressSanitizer: 192 byte(s) leaked in 8 allocation(s). I can reproduce this on GCC 11 and GCC 13.0.1. It always seems to be 8 objects and 192 bytes. I can't remember another instance with different numbers. Expected behaviour: ubsan does not introduce asan leaks.
[Bug middle-end/110697] [14 Regression] bootstrap failure on gcc/tree-ssa-loop-ivcanon.cc:1170 error: variable 'entry_count' set but not used [-Werror=unused-but-set-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110697 --- Comment #3 from Sergei Trofimovich --- I confirm this fixed the bootstrap for me. Thank you!
[Bug fortran/82205] parametrized derived types, problems with initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82205 Stijn Schildermans changed: What|Removed |Added CC||stijn.schildermans@kuleuven ||.be --- Comment #4 from Stijn Schildermans --- I just ran into the same issue. Gfortran 13.1.1 still does not accept the standard-conforming syntax. Has anyone been looking in to this? Posting this comment in the hopes to renew attention/interest.
[Bug c/110703] New: Incorrect "-Wfloat-conversion" diagnostic with _Generic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110703
Bug ID: 110703
Summary: Incorrect "-Wfloat-conversion" diagnostic with
_Generic
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jepler at unpythonic dot net
Target Milestone: ---
When compiled with `gcc -Wfloat-conversion -c boo.c` the following code results
in a `-Wfloat-conversion` diagnostic across a range of gcc versions including
gcc version 12.2.0 (Debian 12.2.0-14) and godbolt "trunk" as of today
(https://godbolt.org/z/3K7sTTv1x)
```
#include
#define tgsin(x) \
_Generic((x), \
double: sin((x)), \
float: sinf((x)) \
)
int f(double d) {
return tgsin(d) > 0;
}
```
The result is
```
$ gcc -Wfloat-conversion -c boo.c
boo.c: In function ‘f’:
boo.c:10:18: warning: conversion from ‘double’ to ‘float’ may change value
[-Wfloat-conversion]
10 | return tgsin(d) > 0;
| ^
boo.c:6:25: note: in definition of macro ‘tgsin’
6 | float: sinf(x) \
| ^
```
As far as I can tell, the diagnostic is spurious, because it applies to the
"float" case of _Generic, which is not the one that is actually chosen. That
is, inspecting the resulting object file `boo.o` there is a call to sin but not
to sinf.
This is prompted by https://github.com/v923z/micropython-ulab/pull/636 and
earlier
https://github.com/micropython/micropython/commit/f31f9a8b70db03cbcbcf39b493f959d0e284962a
-- it at first appeared to be related to -Os size optimization, but that's just
related to how glibc chooses to implement fpclassify, whether via _Generic or
not.
This may be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193
[Bug target/110696] RISC-V: -march doesn't imply correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110696 Kito Cheng changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-07-17 Status|UNCONFIRMED |NEW --- Comment #2 from Kito Cheng --- Fixed on upstream, but will wait one more week for backporting to GCC 13 branch
[Bug c/110699] [12/13/14 Regression] internal compiler error: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.cc:12754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110699 Marek Polacek changed: What|Removed |Added CC||sayle at gcc dot gnu.org --- Comment #1 from Marek Polacek --- Started with r12-3278: commit 823685221de986afb729910a6f2237f07a377f17 Author: Roger Sayle Date: Wed Sep 1 08:38:39 2021 +0100 C: PR c/79412: Poison decls with error_mark_node after type mismatch
[Bug c/110699] [12/13/14 Regression] internal compiler error: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.cc:12754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110699 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2023-07-17 Target Milestone|--- |12.4 Summary|internal compiler error:|[12/13/14 Regression] |tree check: expected|internal compiler error: |array_type, have error_mark |tree check: expected |in array_ref_low_bound, at |array_type, have error_mark |tree.cc:12754 |in array_ref_low_bound, at ||tree.cc:12754 Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org
[Bug c++/110524] [C++20] ICE with use of function template name with no prior declaration in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110524 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Patrick Palka --- Fixed for GCC 13.2, thanks for the bug report.
[Bug c++/110524] [C++20] ICE with use of function template name with no prior declaration in decltype
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110524 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:04e8808841c33d94529b144b15af5d11671dde1b commit r13-7570-g04e8808841c33d94529b144b15af5d11671dde1b Author: Patrick Palka Date: Sat Jul 15 09:47:36 2023 -0400 c++: mangling template-id of unknown template [PR110524] This fixes a crash when mangling an ADL-enabled call to a template-id naming an unknown template (as per P0846R0). PR c++/110524 gcc/cp/ChangeLog: * mangle.cc (write_expression): Handle TEMPLATE_ID_EXPR whose template is already an IDENTIFIER_NODE. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/fn-template26.C: New test. (cherry picked from commit 97ceaa110e1607ec8f4f1223200868e1642f3cc7)
[Bug c/110702] New: Wrong code at -O1 on x86_64-linux-gnu (regression since GCC-12.2)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110702
Bug ID: 110702
Summary: Wrong code at -O1 on x86_64-linux-gnu (regression
since GCC-12.2)
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
This looks like a regression since GCC-12.2.
Compiler explorer: https://godbolt.org/z/655af97j7
$ cat a.c
int printf(const char *, ...);
int a, b, c, d;
long e[9][7][4];
void f() {
for (; a >= 0; a--) {
b = 0;
for (; b <= 3; b++) {
c = 0;
for (; c <= 3; c++) {
int *g =
*g = e[0][0][b] | e[a][b][a];
}
}
}
}
int main() {
f();
printf("%d\n", a);
}
$
$ gcc-tk -O0 a.c && ./a.out
-1
$ gcc-tk -O1 a.c && ./a.out
0
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-322d17ae51ea0137167424e0018d7fa355948f9f/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-322d17ae51ea0137167424e0018d7fa355948f9f
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230711 (experimental) (GCC)
$
[Bug fortran/109699] With OpenACC reallocating a fortran pointer on a user type with allocatable fails.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109699 Patrick Bégou changed: What|Removed |Added Keywords||openacc --- Comment #1 from Patrick Bégou --- Just tested today as many new improvements have been added to gcc compilers. $ gfortran --version GNU Fortran (GCC) 14.0.0 20230717 (experimental) ... Nvidia HPC is nvhpc/23.5 The problem still occur.
[Bug rtl-optimization/110701] [14 Regression] Wrong code at -O1/2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701
Xi Ruoyao changed:
What|Removed |Added
Component|c |rtl-optimization
--- Comment #1 from Xi Ruoyao ---
Combine pass seems guilty. Before combine:
(insn 21 20 23 2 (parallel [
(set (subreg:HI (reg:DI 92) 0)
(and:HI (subreg:HI (reg:DI 92) 0)
(const_int 340 [0x154])))
(clobber (reg:CC 17 flags))
]) "/app/example.c":5:39 596 {*andhi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(insn 23 21 24 2 (parallel [
(set (reg:HI 94)
(xor:HI (subreg:HI (reg:DI 92) 0)
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) "/app/example.c":7:23 discrim 1 634 {*xorhi_1}
(expr_list:REG_DEAD (reg:DI 92)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil
(insn 24 23 25 2 (set (reg:SI 95)
(sign_extend:SI (reg:HI 94))) "/app/example.c":7:23 discrim 1 179
{extendhisi2}
(expr_list:REG_DEAD (reg:HI 94)
(nil)))
(insn 25 24 26 2 (set (mem:SI (reg/f:DI 85 [ c.3_6 ]) [3 *c.3_6+0 S4 A32])
(reg:SI 95)) "/app/example.c":7:23 discrim 1 91 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 95)
(expr_list:REG_DEAD (reg/f:DI 85 [ c.3_6 ])
(nil
This is perfectly legal. After combine:
(insn 21 20 23 2 (parallel [
(set (subreg:HI (reg:DI 92) 0)
(and:HI (subreg:HI (reg:DI 92) 0)
(const_int 340 [0x154])))
(clobber (reg:CC 17 flags))
]) "/app/example.c":5:39 596 {*andhi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(note 23 21 24 2 NOTE_INSN_DELETED)
(insn 24 23 25 2 (parallel [
(set (reg:SI 95)
(ior:SI (subreg:SI (reg:DI 92) 0)
(const_int 3 [0x3])))
(clobber (reg:CC 17 flags))
]) "/app/example.c":7:23 discrim 1 635 {*iorsi_1}
(expr_list:REG_UNUSED (reg:CC 17 flags)
(expr_list:REG_DEAD (reg:DI 92)
(nil
(insn 25 24 26 2 (set (mem:SI (reg/f:DI 85 [ c.3_6 ]) [3 *c.3_6+0 S4 A32])
(reg:SI 95)) "/app/example.c":7:23 discrim 1 91 {*movsi_internal}
(expr_list:REG_DEAD (reg:SI 95)
(expr_list:REG_DEAD (reg/f:DI 85 [ c.3_6 ])
(nil
The removal of sign_extend seems wrong.
[Bug middle-end/110697] [14 Regression] bootstrap failure on gcc/tree-ssa-loop-ivcanon.cc:1170 error: variable 'entry_count' set but not used [-Werror=unused-but-set-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110697 Tobias Burnus changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Tobias Burnus --- Should be FIXED by commit r14-2581-g3b9cd125cfca44d3ae18f409fb20b5c094829e41 "Restore bootstrap by removing unused variable in tree-ssa-loop-ivcanon.cc" Cf. https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624677.html
[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 --- Comment #4 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:e21e13e2525a042a0aabfbcb4ebf4f08609078c7 commit r14-2580-ge21e13e2525a042a0aabfbcb4ebf4f08609078c7 Author: Mikael Morin Date: Mon Jul 17 14:14:22 2023 +0200 fortran: Pass pre-calculated class container argument [pr110618] Pass already evaluated class container argument from gfc_conv_procedure_call down to gfc_add_finalizer_call through gfc_deallocate_scalar_with_status and gfc_deallocate_with_status, to avoid repeatedly evaluating the same data reference expressions in the generated code. PR fortran/110618 gcc/fortran/ChangeLog: * trans.h (gfc_deallocate_with_status): Add class container argument. (gfc_deallocate_scalar_with_status): Ditto. * trans.cc (gfc_deallocate_with_status): Add class container argument and pass it down to gfc_add_finalize_call. (gfc_deallocate_scalar_with_status): Same. * trans-array.cc (structure_alloc_comps): Update caller. * trans-stmt.cc (gfc_trans_deallocate): Ditto. * trans-expr.cc (gfc_conv_procedure_call): Ditto. Pass pre-evaluated class container argument if it's available. gcc/testsuite/ChangeLog: * gfortran.dg/intent_out_22.f90: New test.
[Bug fortran/110618] Dependency between arguments when one is allocatable array whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618 --- Comment #3 from CVS Commits --- The master branch has been updated by Mikael Morin : https://gcc.gnu.org/g:1a46400e5ac0f21eead74b10752f69ebc7a8be27 commit r14-2579-g1a46400e5ac0f21eead74b10752f69ebc7a8be27 Author: Mikael Morin Date: Mon Jul 17 14:14:18 2023 +0200 fortran: Use pre-evaluated class container if available [PR110618] Add the possibility to provide a pre-evaluated class container argument to gfc_add_finalizer to avoid repeatedly evaluating data reference expressions in the generated code. PR fortran/110618 gcc/fortran/ChangeLog: * trans.h (gfc_add_finalizer_call): Add class container argument. * trans.cc (gfc_add_finalizer_call): Ditto. Pass down new argument to get_final_proc_ref, get_elem_size, get_var_desc, and get_vptr. (get_elem_size): Add class container argument. Use provided class container if it's available. (get_var_descr): Same. (get_vptr): Same. (get_final_proc_ref): Same. Add boolean telling the class container argument is used. Set it. Don't try to use final_wrapper if class container argument was used.
[Bug c/97100] -Wformat checks all arms of _Generic leading to irrelevant type expectation warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97100 Konstantin Kharlamov changed: What|Removed |Added CC||Hi-Angel at yandex dot ru --- Comment #1 from Konstantin Kharlamov --- Still relevant. Just stumbled upon it in 13.1.1, was about to report a bug.
[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649 Martin Jambor changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #13 from Martin Jambor --- (In reply to Roger Sayle from comment #12) > Hi Jan, > I believe you also need to remove the >profile_count entry_count = profile_count::zero (); > from tree-ssa-loop-ivcanon.cc's try_peel_loop to avoid a > bootstrap issue with -Werror "variable entry_count set but unused". I'm bootstrapping that change right now.
[Bug bootstrap/110684] unknown spec function ‘dumps’ error, C compiler cannot create executables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110684 --- Comment #6 from AlexK --- I don't know, I copied it from somewhere I want to compile gcc on x86_64 Linux Mint
[Bug target/110696] RISC-V: -march doesn't imply correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110696 --- Comment #1 from CVS Commits --- The trunk branch has been updated by Lehua Ding : https://gcc.gnu.org/g:70742d08832eb7db4d90f52465966111a19ce3a5 commit r14-2564-g70742d08832eb7db4d90f52465966111a19ce3a5 Author: Lehua Ding Date: Mon Jul 17 12:27:12 2023 +0800 RISC-V: Ensure all implied extensions are included [PR110696] This patch fix target/PR110696, recursively add all implied extensions. PR target/110696 gcc/ChangeLog: * common/config/riscv/riscv-common.cc (riscv_subset_list::handle_implied_ext): recur add all implied extensions. (riscv_subset_list::check_implied_ext): Add new method. (riscv_subset_list::parse): Call checker check_implied_ext. * config/riscv/riscv-subset.h: Add new method. gcc/testsuite/ChangeLog: * gcc.target/riscv/attribute-20.c: New test. * gcc.target/riscv/pr110696.c: New test. Signed-off-by: Lehua Ding
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587 --- Comment #10 from Richard Biener --- I wonder what the following does anyway. We delete the noop move only when either the reg isn't used for return or it isn't in use in later insns between 'insn' and the next set of it. That seems to detect the hardreg = X; USE (hardreg); return sequence and wants to protect that despite X being the same as 'hardreg'. /* IRA can generate move insns involving pseudos. It is better remove them earlier to speed up compiler a bit. It is also better to do it here as they might not pass final RTL check in LRA, (e.g. insn moving a control register into itself). So remove an useless move insn unless next insn is USE marking the return reg (we should save this as some subsequent optimizations assume that such original insns are saved). */ if (NONJUMP_INSN_P (insn) && GET_CODE (pat) == SET && REG_P (SET_SRC (pat)) && REG_P (SET_DEST (pat)) && REGNO (SET_SRC (pat)) == REGNO (SET_DEST (pat)) && (! return_regno_p (REGNO (SET_SRC (pat))) || ! regno_in_use_p (insn, REGNO (SET_SRC (pat) what's odd is of course that return_regno_p returns true so much for this testcase. The return sequence to protect should be easily discoverable by walking from the function exit and thus could be marked instead of trying to match it to each insn like above. But I don't understand why we want to preserve this noop copy anyway ...
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587
Roger Sayle changed:
What|Removed |Added
CC||roger at nextmovesoftware dot
com
See Also||https://gcc.gnu.org/bugzill
||a/show_bug.cgi?id=88873
--- Comment #9 from Roger Sayle ---
I'll check whether turning off the insvti_{low,high}part transformations during
lra_in_progress helps compile-time. I believe everytime reload encounters a
TI<->SSE SUBREG, the spill/reload generates two or three additional
instructions. I'm thinking that perhaps this should ideally be an UNSPEC, that
we can split after reload. As shown in PR 88873, we'd like SSE->TI->SSE to
avoid going via memory [where currently this happens twice]. It looks like
"interval" in pr28071.c suffers from the same x86 ABI issues [i.e. is placed in
scalar TImode, where ideally we'd like V2DI].
[Bug fortran/107424] [13/14 Regression] ICE in gfc_trans_omp_do, at fortran/trans-openmp.cc:5397 - and wrong code - with non-rectangular loops
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107424 --- Comment #14 from Tobias Burnus --- (In reply to Tobias Burnus from comment #12) > Handle loop steps other than ±1. Fortran (here F2023) has under "11.1.7.4.3 The execution cycle" (for "DO"): "... consists of the following steps ..." "(1) The iteration count, if any, is tested. If it is zero, the loop terminates ... "(2) The block of the loop is executed.28 "(3) The iteration count, if any, is decremented by one. The DO variable, if any, is incremented by the value of the incrementation parameter m3." And Fortran states: "The execution of any numeric operation whose result is not defined by the arithmetic used by the processor is prohibited." (10.1.5.2.4 Evaluation of numeric intrinsic operations). * * * Thus (cf. email linked in comment 12), simply extending this to any constant step should be possible. (For the other cases, see email.)
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587 Richard Biener changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #8 from Richard Biener --- Btw, with GCC 13.1 this is already a LRA hog: LRA non-specific : 3.31 ( 73%) 0.01 ( 9%) 3.33 ( 72%) 3876k ( 3%) TOTAL : 4.53 0.11 4.65 126M GCC 8 and before were worse. On trunk: LRA non-specific : 6.22 ( 69%) 0.02 ( 20%) 6.22 ( 69%) 8922k ( 6%) LRA hard reg assignment: 1.00 ( 11%) 0.02 ( 20%) 1.02 ( 11%) 0 ( 0%) TOTAL : 8.97 0.10 9.08 149M the above is with just -O0. Profile: Samples: 37K of event 'cycles:u', Event count (approx.): 49984847870 Overhead Samples Command Shared Object Symbol 51.58% 19087 cc1 cc1 [.] lra_final_code_change 11.10% 4106 cc1 cc1 [.] next_nondebug_insn 7.61% 2879 cc1 cc1 [.] bitmap_set_bit 6.42% 2425 cc1 cc1 [.] find_hard_regno_for_1 2.28% 842 cc1 cc1 [.] bitmap_bit_p 0.99% 365 cc1 cc1 [.] lra_create_live_ranges_1 it possibly means we now spill more, at -O0 at least. We have a 10% regression in assembly line count between 13 and trunk. The main hog in lra_final_code_change is calls to regno_in_use_p and the loop within that. The BB in this function is _huge_ so the whole process quickly becomes quadratic. Maybe the whole thing should work backwards on a BB and this info collected on-the-fly as some "liveness" problem?
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587
Martin Jambor changed:
What|Removed |Added
CC||sayle at gcc dot gnu.org
--- Comment #7 from Martin Jambor ---
Oops sorry, indeed, the much bigger regression is because of:
commit 8911879415d6c2a7baad88235554a912887a1c5c
Author: Roger Sayle
Date: Fri Jul 14 18:10:05 2023 +0100
i386: Improved insv of DImode/DFmode {high,low}parts into TImode.
This is the next piece towards a fix for (the x86_64 ABI issues affecting)
PR 88873. This patch generalizes the recent tweak to ix86_expand_move
for setting the highpart of a TImode reg from a DImode source using
*insvti_highpart_1, to handle both DImode and DFmode sources, and also
use the recently added *insvti_lowpart_1 for setting the lowpart.
Although this is another intermediate step (not yet a fix), towards
enabling *insvti and *concat* patterns to be candidates for TImode STV
(by using V2DI/V2DF instructions), it already improves things a little.
[...]
[Bug target/110649] [14 Regression] 25% sphinx3 spec2006 regression on Ice Lake and zen between g:acaa441a98bebc52 (2023-07-06 11:36) and g:55900189ab517906 (2023-07-07 00:23)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110649 Roger Sayle changed: What|Removed |Added CC||roger at nextmovesoftware dot com --- Comment #12 from Roger Sayle --- Hi Jan, I believe you also need to remove the profile_count entry_count = profile_count::zero (); from tree-ssa-loop-ivcanon.cc's try_peel_loop to avoid a bootstrap issue with -Werror "variable entry_count set but unused".
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 --- Comment #10 from Sergei Trofimovich --- I confirm the change fixed build for me (it also needed unrelated workaround for https://gcc.gnu.org/PR110697). Thank you!
[Bug target/105522] [powerpc-darwin] ICE: in decode_addr_const, at varasm.c:3059
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105522
--- Comment #9 from Sergey Fedorov ---
Just to update, GCC 12.3.0 exhibits the same error:
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2-snowleopard/libsdl2-snowleopard/work/SDL2-2.0.22/src/hidapi/mac/hid.c:
In function 'create_usage_match':
/opt/local/var/macports/build/_opt_PPCSnowLeopardPorts_devel_libsdl2-snowleopard/libsdl2-snowleopard/work/SDL2-2.0.22/src/hidapi/mac/hid.c:407:21:
internal compiler error: in decode_addr_const, at varasm.cc:3083
407 | const void *keys[2] = { (void *)
CFSTR(kIOHIDDeviceUsagePageKey), (void *) CFSTR(kIOHIDDeviceUsageKey) };
| ^~~~
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See for instructions.
make: *** [build/SDL_hidapi.lo] Error 1
[Bug c/110701] New: Wrong code at -O1/2/3/s on x86_64-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110701
Bug ID: 110701
Summary: Wrong code at -O1/2/3/s on x86_64-linux-gnu
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: shaohua.li at inf dot ethz.ch
Target Milestone: ---
This looks like a recent regression. gcc at -O1 and above produce the wrong
code.
Compiler explorer: https://godbolt.org/z/6Wczv9dK6
$ cat a.c
int printf(const char *, ...);
int a;
long b;
int *c =
short(d)(short e, short f) { return e * f; }
int main() {
*c = d(340, b >= 0) ^ 3;
printf("%d\n", a);
}
$
$ gcc-tk -O0 a.c && ./a.out
343
$ gcc-tk -O1 a.c && ./a.out
-65193
$ gcc-tk -O2 a.c && ./a.out
-65193
$ gcc-tk -O3 a.c && ./a.out
-65193
$ gcc-tk -Os a.c && ./a.out
-65193
$
$ gcc-tk -v
Using built-in specs.
COLLECT_GCC=gcc-tk
COLLECT_LTO_WRAPPER=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-322d17ae51ea0137167424e0018d7fa355948f9f/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure --disable-multilib --disable-bootstrap
--enable-languages=c,c++
--prefix=/zdata/shaoli/compilers/ccbuilder-compilers/gcc-322d17ae51ea0137167424e0018d7fa355948f9f
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230711 (experimental) (GCC)
$
[Bug c/102989] Implement C2x's n2763 (_BitInt)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102989 Jakub Jelinek changed: What|Removed |Added Attachment #55545|0 |1 is obsolete|| --- Comment #82 from Jakub Jelinek --- Created attachment 55561 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55561=edit gcc14-bitint-wip.patch Remaining _BitInt to floating point conversions.
[Bug analyzer/110700] New: gcc -fanalyzer --analyzer-checker=taint encouters an error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110700
Bug ID: 110700
Summary: gcc -fanalyzer --analyzer-checker=taint encouters an
error
Product: gcc
Version: 13.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: geoffreydgr at icloud dot com
Target Milestone: ---
when i try to use taint checher to handle the following case, i encouter an
error.
```c
__attribute__ ((tainted_args))
double divide(double x, double y){
return x/y;
}
```
cmd:
gcc -fanalyzer --analyzer-checker=taint cwe-369.c -c
error messages:
"
// Target: x86_64-pc-linux-gnu
// Configured with: ../gcc/configure -prefix=/usr/local/gcc-13-9533
--enable-checking=release --enable-languages=c,c++ --disable-multilib
// Thread model: posix
// Supported LTO compression algorithms: zlib
// gcc version 13.1.1 20230717 (GCC)
//
// during IPA pass: analyzer
// CWE/cwe-369.c: In function 'divide':
// CWE/cwe-369.c:3:9: internal compiler error: in wide_int_to_tree_1, at
tree.cc:1755
// 3 | return x/y;
// |~^~
// 0x712cea wide_int_to_tree_1
// ../../gcc/gcc/tree.cc:1755
// 0xf4187b wide_int_to_tree(tree_node*, poly_int<1u,
generic_wide_int > > const&)
// ../../gcc/gcc/tree.cc:1867
// 0xf4187b build_int_cst(tree_node*, poly_int<1u, long>)
// ../../gcc/gcc/tree.cc:1507
// 0x1007587 ana::region_model_manager::get_or_create_int_cst(tree_node*,
poly_int<1u, long>)
// ../../gcc/gcc/analyzer/region-model-manager.cc:236
// 0x1028059 check_for_tainted_divisor
// ../../gcc/gcc/analyzer/sm-taint.cc:1355
// 0x1028059 on_stmt
// ../../gcc/gcc/analyzer/sm-taint.cc:1015
// 0xfd5dbf ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::uncertainty_t*,
ana::path_context*)
// ../../gcc/gcc/analyzer/engine.cc:1490
// 0xfd86bd ana::exploded_graph::process_node(ana::exploded_node*)
// ../../gcc/gcc/analyzer/engine.cc:4063
// 0xfd94fa ana::exploded_graph::process_worklist()
// ../../gcc/gcc/analyzer/engine.cc:3466
// 0xfdb7e7 ana::impl_run_checkers(ana::logger*)
// ../../gcc/gcc/analyzer/engine.cc:6125
// 0xfdc7c6 ana::run_checkers()
// ../../gcc/gcc/analyzer/engine.cc:6213
// 0xfccf68 execute
// ../../gcc/gcc/analyzer/analyzer-pass.cc:87
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.
// See <https://gcc.gnu.org/bugs/> for instructions.
// /usr/local/gcc-13-9533/libexec/gcc/x86_64-pc-linux-gnu/13.1.1/cc1 -quiet
-imultiarch x86_64-linux-gnu CWE/cwe-369.c -quiet -dumpbase cwe-369.c
-dumpbase-ext .c -mtune=generic -march=x86-64 -fanalyzer
-fanalyzer-checker=taint -freport-bug -o - -frandom-seed=0 -fdump-noaddr
"
[Bug middle-end/110586] [14 Regression] 10% fatigue2 regression on zen since r14-2369-g3a61ca1b925653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110586 --- Comment #3 from Martin Jambor --- (In reply to Jan Hubicka from comment #2) > Do we have other PRs reducing to this change? > I thought the recent sphinx regression was also becaus of this? But if I am wrong, there may be none.
[Bug tree-optimization/110204] [14 Regression] Suspicous warning when compiling ranges-v3 using GCC trunk (iteration 9223372036854775807 invokes undefined behavior)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110204
--- Comment #5 from Richard Biener ---
Yeah, the issue is that PRE figures out a new value here but we've already done
value-numbering so we can't alter the "old" solution here. So what we do
is add a '0' with value '_42' (instead of value '0'). This "second order"
value numbering leaves more opportunities on the plate. It was IMHO
cleaner to insert a
pretmp_163 = 0;
than substituting '0' everywhere but then leaving around the third order
optimizations in case we had _42 + 1 that would then simplify to sth = 1 ...
Previously we'd have inserted a degenerate PHI, now we get these kind of
copies. "Now" is for a long time so this isn't new for PRE at least.
We could "hack" this by doing
diff --git a/gcc/tree-ssa-sccvn.cc b/gcc/tree-ssa-sccvn.cc
index 11061a374a2..effb4f4de73 100644
--- a/gcc/tree-ssa-sccvn.cc
+++ b/gcc/tree-ssa-sccvn.cc
@@ -6615,6 +6615,13 @@ eliminate_dom_walker::eliminate_push_avail (basic_block,
tree op)
if (avail[SSA_NAME_VERSION (valnum)])
pushop = avail[SSA_NAME_VERSION (valnum)];
avail_stack.safe_push (pushop);
+ if (gassign *ass = dyn_cast (SSA_NAME_DEF_STMT (op)))
+ if (gimple_assign_rhs_class (ass) == GIMPLE_SINGLE_RHS)
+ {
+ tree rhs1 = gimple_assign_rhs1 (ass);
+ if (CONSTANT_CLASS_P (rhs1) || TREE_CODE (rhs1) == SSA_NAME)
+ op = rhs1;
+ }
avail[SSA_NAME_VERSION (valnum)] = op;
}
}
[Bug c++/110689] problem of initializer list and conversion operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110689 Jonathan Wakely changed: What|Removed |Added Keywords||rejects-valid Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-07-17
[Bug c++/110688] problem with templates typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110688
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
--- Comment #2 from Jonathan Wakely ---
We should be able to instantiate it like so:
template struct S01 {
struct P::template T<1> m;
};
struct X {
template struct T { };
};
S01 s;
Clang and EDG accept this.
GCC accepts it like this instead:
typename P::template T<1> m;
[Bug c/110699] New: internal compiler error: tree check: expected array_type, have error_mark in array_ref_low_bound, at tree.cc:12754
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110699
Bug ID: 110699
Summary: internal compiler error: tree check: expected
array_type, have error_mark in array_ref_low_bound, at
tree.cc:12754
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: 141242068 at smail dot nju.edu.cn
Target Milestone: ---
When compiling below program using gcc-14 with option `gcc-14 a.c`, gcc-14
crashes:
```
typedef __attribute__((__vector_size__(64))) int T;
void f(void) {
extern char a[64], b[64];
void *p = a;
T q = *(T *)[0];
}
void g() {
extern char b;
}
```
GCC's output is pasted below:
```
: In function 'g':
:10:15: error: conflicting types for 'b'; have 'char'
10 | extern char b;
| ^
:4:22: note: previous declaration of 'b' with type 'char[64]'
4 | extern char a[64], b[64];
| ^
: In function 'f':
:6:17: internal compiler error: tree check: expected array_type, have
error_mark in array_ref_low_bound, at tree.cc:12754
6 | T q = *(T *)[0];
|~^~~
0x215104e internal_error(char const*, ...)
???:0
0x896b1b tree_check_failed(tree_node const*, char const*, int, char const*,
...)
???:0
0xd6c895 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd6d557 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd6db1d gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd6cf6a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd7053a gimplify_stmt(tree_node**, gimple**)
???:0
0xd6d53e gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd7053a gimplify_stmt(tree_node**, gimple**)
???:0
0xd6e4ab gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd7053a gimplify_stmt(tree_node**, gimple**)
???:0
0xd6d914 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
???:0
0xd7053a gimplify_stmt(tree_node**, gimple**)
???:0
0xd719d3 gimplify_body(tree_node*, bool)
???:0
0xd71e2f gimplify_function_tree(tree_node*)
???:0
0xbaeba7 cgraph_node::analyze()
???:0
0xbb26f1 symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #6 from Richard Biener --- That doesn't seem to be the larger jump at Jul 16/17? Can we bisect that as well?
[Bug c++/110687] problem with class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110687 --- Comment #2 from Jonathan Wakely --- Fixed for 12.1 and 11.4 by: c++: template-id with current inst qualifier [PR102300] The patch for PR41723 properly changed one place to look into the current instantiation; now we need to fix this place as well. PR c++/102300 gcc/cp/ChangeLog: * parser.cc (cp_parser_template_name): Use dependent_scope_p. Probably a dup of PR 41723.
[Bug c++/110686] problem with explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110686
--- Comment #2 from Jonathan Wakely ---
(In reply to actri_lxlong3 from comment #0)
> Test template name resolution, such as:
>
> template struct N {
> template struct S23{
> typedef long X;
> void g(void) { try {} catch (typename ::N::S::S23::X) {} }
This code is nonsense, why are you reporting this?
> Error occurs when using typename and nested namespace templates.
> The C++ standard describes that the typename prefix should be used when a
> nested form such as ::N::S::S23::X represents a type rather than a
> member of the currently instantiated template.
Yes, but it also says that you need to say ::template S and ::template
S23 but that still won't help because P and S are not declared anywhere.
[Bug middle-end/110586] [14 Regression] 10% fatigue2 regression on zen since r14-2369-g3a61ca1b925653
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110586 Jan Hubicka changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-07-17 --- Comment #2 from Jan Hubicka --- Do we have other PRs reducing to this change? The patch makes cuntroll to scale down previously incoherent profiles when loop that does not loop is predicted to loop. Common source of these loops are vectorized epilogues which I fixed yesterday. With some luck this may fix fatigue.
[Bug rtl-optimization/110587] [14 regression] 96% pr28071.c compile time regression since r14-2337-g37a231cc7594d1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110587 --- Comment #5 from Martin Jambor --- (In reply to Hongtao.liu from comment #3) > I can't find pr28071.c in GCC testsuite, but find an attached source file in > the PR #c1, is that pr28071.c you means? Yes. (In reply to Hongtao.liu from comment #4) > (In reply to Jan Hubicka from comment #0) > > Seen here: > > https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=288.597.8 > > https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=468.597.8 > > https://lnt.opensuse.org/db_default/v4/CPP/graph?plot.0=172.597.8 > > Also is O0_g means compile flag is -O0 -g? That is what I used to bisect, although I *think* that -g is not necessary.
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 Kewen Lin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Kewen Lin --- Should be fixed on trunk.
[Bug tree-optimization/110652] [14 Regression] bootstrap failure on tree-vect-stmts.cc with --enable-checking=release: error: 'new_temp' may be used uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110652 --- Comment #8 from CVS Commits --- The master branch has been updated by Kewen Lin : https://gcc.gnu.org/g:081c623ca88dc53abe34b5f5661e79fcde800cef commit r14-2560-g081c623ca88dc53abe34b5f5661e79fcde800cef Author: Kewen Lin Date: Mon Jul 17 03:44:59 2023 -0500 vect: Initialize new_temp to avoid false positive warning [PR110652] As PR110652 and its duplicate PRs show, there could be one build error error: 'new_temp' may be used uninitialized for some build configurations. It's a false positive warning (or error at -Werror), but in order to make the build succeed, this patch is to initialize the reported variable 'new_temp' as NULL_TREE. PR tree-optimization/110652 gcc/ChangeLog: * tree-vect-stmts.cc (vectorizable_load): Initialize new_temp as NULL_TREE.
[Bug tree-optimization/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from Richard Biener --- Fixed.
[Bug middle-end/110673] [14 regression] ICE when buliding opus (internal compiler error: in gimple_phi_arg_def_from_edge, at gimple.h:4699)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110673 Bug 110673 depends on bug 110669, which changed state. Bug 110669 Summary: [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/110671] ICE on valid code at -O2 and -O3 on x86_64-linux-gnu: in gimple_phi_arg_def_from_edge, at gimple.h:4699
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110671 Bug 110671 depends on bug 110669, which changed state. Bug 110669 Summary: [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/109753] [13/14 Regression] pragma GCC target causes std::vector not to compile (always_inline on constructor)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109753
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #9 from Richard Biener ---
(In reply to Xi Ruoyao from comment #8)
> In local-fnsummary2:
>
> __attribute__((always_inline, target ("avx2")))
> void aa::aa (struct aa * const this)
> {
>[local count: 1073741824]:
> return;
>
> }
>
> this seems correct. But:
>
> void __static_initialization_and_destruction_0 ()
> {
>:
> aa::aa (&_M_impl);
> return;
>
> }
>
> Note that __static_initialization_and_destruction_0 is not attributed with
> avx2.
I think that's correct. Maybe we need multiple CTOR/DTOR functions
in such case.
[Bug target/29256] [11/12/13/14 regression] loop performance regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29256 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #76 from Richard Biener --- x86_64 has [local count: 536870800]: # ivtmp.13_3 = PHI vect__1.6_12 = MEM [(double *) + ivtmp.13_3 * 1]; MEM [(double *) + ivtmp.13_3 * 1] = vect__1.6_12; ivtmp.13_9 = ivtmp.13_3 + 16; if (ivtmp.13_9 != 1600) and .L2: movapd a(%rax), %xmm0 addq$16, %rax movaps %xmm0, c-16(%rax) cmpq$1600, %rax jne .L2 which I think is optimal. With -fPIC we get .L2: movapd (%rax,%rdx), %xmm0 addq$16, %rax movaps %xmm0, -16(%rax,%rcx) cmpq$1600, %rax jne .L2 let's close this.
[Bug tree-optimization/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 --- Comment #9 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:b8a1531371309698ad5cd4f000152ce74a52 commit r13-7569-gb8a1531371309698ad5cd4f000152ce74a52 Author: Richard Biener Date: Mon Jul 17 09:20:33 2023 +0200 tree-optimization/110669 - bogus matching of loop bitop The matching code lacked a check that we end up with a PHI node in the loop header. This caused us to match a random PHI argument now catched by the extra PHI_ARG_DEF_FROM_EDGE checking. PR tree-optimization/110669 * tree-scalar-evolution.cc (analyze_and_compute_bitop_with_inv_effect): Check we matched a header PHI. * gcc.dg/torture/pr110669.c: New testcase.
[Bug tree-optimization/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 --- Comment #8 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:3228e5c078ed2b505e4ad238b09c1817b38f9cfb commit r14-2559-g3228e5c078ed2b505e4ad238b09c1817b38f9cfb Author: Richard Biener Date: Mon Jul 17 09:20:33 2023 +0200 tree-optimization/110669 - bogus matching of loop bitop The matching code lacked a check that we end up with a PHI node in the loop header. This caused us to match a random PHI argument now catched by the extra PHI_ARG_DEF_FROM_EDGE checking. PR tree-optimization/110669 * tree-scalar-evolution.cc (analyze_and_compute_bitop_with_inv_effect): Check we matched a header PHI. * gcc.dg/torture/pr110669.c: New testcase.
[Bug middle-end/110697] [14 Regression] bootstrap failure on gcc/tree-ssa-loop-ivcanon.cc:1170 error: variable 'entry_count' set but not used [-Werror=unused-but-set-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110697 Richard Biener changed: What|Removed |Added Priority|P3 |P1 Keywords||build CC||hubicka at gcc dot gnu.org Target Milestone|--- |14.0
[Bug tree-optimization/110692] epilogues for loop which can be also vectorized with half size can be improved.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110692 Richard Biener changed: What|Removed |Added CC||rguenth at gcc dot gnu.org Keywords||missed-optimization Component|middle-end |tree-optimization Blocks||53947 --- Comment #1 from Richard Biener --- With the variable bound we have a[i_11] 1 times vector_load costs 12 in body _1 + 1 1 times scalar_to_vec costs 4 in prologue _1 + 1 1 times vector_stmt costs 4 in body _2 1 times vector_store costs 12 in body t.c:4:28: note: operating on full vectors for epilogue loop. t.c:4:28: note: cost model: epilogue peel iters set to vf/2 because loop iterations are unknown . a[i_11] 1 times scalar_load costs 12 in epilogue _1 + 1 1 times scalar_stmt costs 4 in epilogue _2 1 times scalar_store costs 12 in epilogue 1 times cond_branch_taken costs 16 in epilogue t.c:4:28: note: Cost model analysis: Vector inside of loop cost: 28 Vector prologue cost: 4 Vector epilogue cost: 44 Scalar iteration cost: 28 Scalar outside cost: 32 Vector outside cost: 48 prologue iterations: 0 epilogue iterations: 1 Calculated minimum iters for profitability: 1 t.c:4:28: note:Runtime profitability threshold = 2 t.c:4:28: note:Static estimate profitability threshold = 4 t.c:4:28: missed: not vectorized: estimated iteration count too small. with the static bound: a[i_10] 1 times vector_load costs 12 in body _1 + 1 1 times scalar_to_vec costs 4 in prologue _1 + 1 1 times vector_stmt costs 4 in body _2 1 times vector_store costs 12 in body t.c:4:28: note: operating on full vectors for epilogue loop. a[i_10] 1 times scalar_load costs 12 in epilogue _1 + 1 1 times scalar_stmt costs 4 in epilogue _2 1 times scalar_store costs 12 in epilogue t.c:4:28: note: Cost model analysis: Vector inside of loop cost: 28 Vector prologue cost: 4 Vector epilogue cost: 28 Scalar iteration cost: 28 Scalar outside cost: 0 Vector outside cost: 32 prologue iterations: 0 epilogue iterations: 1 Calculated minimum iters for profitability: 2 t.c:4:28: note:Runtime profitability threshold = 2 t.c:4:28: note:Static estimate profitability threshold = 2 so it's the branch of the epilog of the epilog that ups the cost, not sure whether in a reasonable way for this case. In the end I think if the count is unknown a fully peeled epilog with 2 iterations is a reasonable implementation. We could decide that costing the epilogue vectorization isn't worthwhile but note we are not implementing all 8 byte vector ops with the same efficiency as the 16 byte ones. Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 [Bug 53947] [meta-bug] vectorizer missed-optimizations
[Bug middle-end/110697] [14 Regression] bootstrap failure on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110697 Andrew Pinski changed: What|Removed |Added CC||juergen.reuter at desy dot de --- Comment #1 from Andrew Pinski --- *** Bug 110698 has been marked as a duplicate of this bug. ***
[Bug bootstrap/110698] Bootstrap fails with [-Werror=unused-but-set-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110698 Andrew Pinski changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- Dup. *** This bug has been marked as a duplicate of bug 110697 ***
[Bug bootstrap/110698] New: Bootstrap fails with [-Werror=unused-but-set-variable]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110698 Bug ID: 110698 Summary: Bootstrap fails with [-Werror=unused-but-set-variable] Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: juergen.reuter at desy dot de Target Milestone: --- This seems to be a very recent problem: last week (as of July 10) the bootstrap did still work with the gcc master, and now it is failing, cf. below. That should be pretty easy to find. #11 3096.5 /usr/src/gcc/gcc/expmed.cc: In function 'rtx_def* extract_bit_field_1(rtx, poly_uint64, poly_uint64, int, rtx, machine_mode, machine_mode, bool, bool, rtx_def**)': #11 3096.5 /usr/src/gcc/gcc/expmed.cc:1838:45: warning: '*(unsigned int*)((char*) + offsetof(scalar_int_mode, scalar_int_mode::m_mode))' may be used uninitialized [-Wmaybe-uninitialized] #11 3096.5 1838 | rtx sub = extract_bit_field_as_subreg (mode1, op0, imode, #11 3096.5 | ^~~ #11 3096.5 1839 | bitsize, bitnum); #11 3096.5 | #11 3096.5 /usr/src/gcc/gcc/expmed.cc:1798:19: note: '*(unsigned int*)((char*) + offsetof(scalar_int_mode, scalar_int_mode::m_mode))' was declared here #11 3096.5 1798 | scalar_int_mode imode; #11 3096.5 | ^ #11 3754.2 /usr/src/gcc/gcc/tree-ssa-loop-ivcanon.cc: In function 'bool try_peel_loop(loop*, edge, tree, bool, long int)': #11 3754.2 /usr/src/gcc/gcc/tree-ssa-loop-ivcanon.cc:1170:17: error: variable 'entry_count' set but not used [-Werror=unused-but-set-variable] #11 3754.2 1170 | profile_count entry_count = profile_count::zero (); #11 3754.2 | ^~~ #11 3758.5 cc1plus: all warnings being treated as errors
[Bug c++/110688] problem with templates typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110688 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2023-07-17 Known to fail||13.1.0 Version|4.8.1 |13.1.0 --- Comment #1 from Richard Biener --- Confirmed. Btw, please use a more recent compiler for your reports.
[Bug c++/110687] problem with class template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110687 Richard Biener changed: What|Removed |Added Known to work||11.4.0 Known to fail||10.5.0, 11.3.0 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Richard Biener --- GCC 11 accepts this and is the oldest still supported compiler. Likely a duplicate of an existing (fixed) bug.
[Bug c++/110686] problem with explicit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110686
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|--- |INVALID
--- Comment #1 from Richard Biener ---
clang provides the maybe more helpful:
> clang++ t.C -S
t.C:4:47: error: no type named 'S' in 'N'
void g(void) { try {} catch (typename ::N::S::S23::X) {} }
~^
[Bug c/110683] wrong code with '-O2 -fpack-struct'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110683 Richard Biener changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #6 from Richard Biener --- There's a set of options like -fpack-struct that result in a non 1:1 transform of the program which you probably should avoid using. In the manual they are documented to change the ABI.
[Bug tree-optimization/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 --- Comment #7 from Richard Biener --- Exactly the thing the patch was supposed to catch ... testing fix.
[Bug tree-optimization/110669] [14 regression] ICE in gcc.dg/torture/pr105132.c since r14-2515-gb77161e60bce7b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110669 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-07-17 --- Comment #6 from Richard Biener --- Mine.
[Bug fortran/110691] Segmentation fault on valid F2018 code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110691 --- Comment #1 from Jürgen Reuter --- Created attachment 55560 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55560=edit Shorter reproducer that gives bogus entries. This shorter reproducer gives (with gfortran 11.3) bogus output, and with gfortran 14.0 emty output. The expected output would be [] * Array of arrays [[h(0) h(1)]] [[h(0) h(1)] [h(-1) h(0)]]
[Bug middle-end/19987] [meta-bug] fold missing optimizations in general
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19987 Bug 19987 depends on bug 95923, which changed state. Bug 95923 Summary: Failure to optimize bool checks into and https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95923 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
