[Bug target/112816] [11/12/13/14 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- Created attachment 56767 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56767&action=edit gcc14-pr112816.patch Untested fix. Another issue is that the emitted code is terrible: pxor%xmm1, %xmm1 psrld $31, %xmm0 pcmpeqd %xmm1, %xmm0 pcmpeqd %xmm1, %xmm0 Why not just psrad $31, %xmm0 instead of all this?
[Bug target/112816] [11/12/13/14 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 --- Comment #4 from Jakub Jelinek --- I think we want to add some patterns for combine which would match (set (reg:V4SI 115) (eq:V4SI (lshiftrt:V4SI (subreg:V4SI (reg:V2DI 110) 0) (const_int 31 [0x1f])) (const_vector:V4SI [ (const_int 0 [0]) repeated x4 ]))) (and ditto for ashiftrt, in both cases with just match_operand:V4SI for the register_operand and obviously iterators over 16/32-byte integral vector modes) and turn that into ashiftrt by the same count.
[Bug target/112816] [11/12/13/14 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112816 Jakub Jelinek changed: What|Removed |Added Keywords|needs-bisection | --- Comment #5 from Jakub Jelinek --- BTW, with -O2 the ICE started with r12-4240, with -O3 with r10-2804-gbf05a3bbb58b355899ccabe861a06e85b7abe6e4 and guess it has been latent before that.
[Bug target/112743] RISC-V: building FAIL with -march=rv64(or rv32)gc_zve32f_zvfh_zfh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112743 --- Comment #6 from Li Pan --- Double confirmed the riscv-gnu-toolchain can be built successfully with the latest newlib.
[Bug c++/60994] gcc does not recognize hidden/shadowed enumeration as valid nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60994 --- Comment #19 from GCC Commits --- The master branch has been updated by Roger Sayle : https://gcc.gnu.org/g:193ef02a7f4f3e5349ad9cf8d3d4df466a99b677 commit r14-6075-g193ef02a7f4f3e5349ad9cf8d3d4df466a99b677 Author: Roger Sayle Date: Sat Dec 2 11:15:14 2023 + RISC-V: Improve style to work around PR 60994 in host compiler. This simple patch allows me to build a cross-compiler to riscv using older versions of RedHat's system compiler. The issue is PR c++/60994 where g++ doesn't like the same name (demand_flags) to be used by both a variable and a (enumeration) type, which is also undesirable from a (GNU) coding style perspective. One solution is to rename the type to demand_flags_t, but a less invasive change is to simply use another identifier for the problematic local variable, renaming demand_flags to dflags. 2023-12-02 Roger Sayle gcc/ChangeLog * config/riscv/riscv-vsetvl.cc (csetvl_info::parse_insn): Rename local variable from demand_flags to dflags, to avoid conflicting with (enumeration) type of the same name.
[Bug tree-optimization/112824] New: Stack spills and vector splitting with vector builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112824
Bug ID: 112824
Summary: Stack spills and vector splitting with vector builtins
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: elrodc at gmail dot com
Target Milestone: ---
I am not sure which component to place this under, but selected
tree-optimization as I suspect this is some sort of alias analysis failure
preventing the removal of stack allocations.
Godbolt link, reproduces on GCC trunk and 13.2:
https://godbolt.org/z/4TPx17Mbn
Clang has similar problems in my actual test case, but they don't show up in
this minimal example I made. Although Clang isn't perfect here either: it fails
to fuse fmadd + masked vmovapd, while GCC does succeed in fusing them.
For reference, code behind the godbolt link is:
#include
#include
#include
#include
template
using Vec [[gnu::vector_size(W * sizeof(T))]] = T;
// Omitted: 16 without AVX, 32 without AVX512F,
// or for forward compatibility some AVX10 may also mean 32-only
static constexpr ptrdiff_t VectorBytes = 64;
template
static constexpr ptrdiff_t VecWidth = 64 <= sizeof(T) ? 1 : 64/sizeof(T);
template struct Vector{
static constexpr ptrdiff_t L = N;
T data[L];
static constexpr auto size()->ptrdiff_t{return N;}
};
template struct Vector{
static constexpr ptrdiff_t W = N >= VecWidth ? VecWidth :
ptrdiff_t(std::bit_ceil(size_t(N)));
static constexpr ptrdiff_t L = (N/W) + ((N%W)!=0);
using V = Vec;
V data[L];
static constexpr auto size()->ptrdiff_t{return N;}
};
/// should be trivially copyable
/// codegen is worse when passing by value, even though it seems like it should
make
/// aliasing simpler to analyze?
template
[[gnu::always_inline]] constexpr auto operator+(Vector x, Vector y)
-> Vector {
Vector z;
for (ptrdiff_t n = 0; n < Vector::L; ++n) z.data[n] = x.data[n] +
y.data[n];
return z;
}
template
[[gnu::always_inline]] constexpr auto operator*(Vector x, Vector y)
-> Vector {
Vector z;
for (ptrdiff_t n = 0; n < Vector::L; ++n) z.data[n] = x.data[n] *
y.data[n];
return z;
}
template
[[gnu::always_inline]] constexpr auto operator+(T x, Vector y) ->
Vector {
Vector z;
for (ptrdiff_t n = 0; n < Vector::L; ++n) z.data[n] = x + y.data[n];
return z;
}
template
[[gnu::always_inline]] constexpr auto operator*(T x, Vector y) ->
Vector {
Vector z;
for (ptrdiff_t n = 0; n < Vector::L; ++n) z.data[n] = x * y.data[n];
return z;
}
template struct Dual {
T value;
Vector partials;
};
// Here we have a specialization for non-power-of-2 `N`
template
requires(std::floating_point && (std::popcount(size_t(N))>1))
struct Dual {
Vector data;
};
template
consteval auto firstoff(){
static_assert(std::same_as, "type not implemented");
if constexpr (W==2) return Vec<2,int64_t>{0,1} != 0;
else if constexpr (W == 4) return Vec<4,int64_t>{0,1,2,3} != 0;
else if constexpr (W == 8) return Vec<8,int64_t>{0,1,2,3,4,5,6,7} != 0;
else static_assert(false, "vector width not implemented");
}
template
[[gnu::always_inline]] constexpr auto operator+(Dual a,
Dual b)
-> Dual {
if constexpr (std::floating_point && (std::popcount(size_t(N))>1)){
Dual c;
for (ptrdiff_t l = 0; l < Vector::L; ++l)
c.data.data[l] = a.data.data[l] + b.data.data[l];
return c;
} else return {a.value + b.value, a.partials + b.partials};
}
template
[[gnu::always_inline]] constexpr auto operator*(Dual a,
Dual b)
-> Dual {
if constexpr (std::floating_point && (std::popcount(size_t(N))>1)){
using V = typename Vector::V;
V va = V{}+a.data.data[0][0], vb = V{}+b.data.data[0][0];
V x = va * b.data.data[0];
Dual c;
c.data.data[0] = firstoff::W,T>() ? x + vb*a.data.data[0] : x;
for (ptrdiff_t l = 1; l < Vector::L; ++l)
c.data.data[l] = va*b.data.data[l] + vb*a.data.data[l];
return c;
} else return {a.value * b.value, a.value * b.partials + b.value *
a.partials};
}
void prod(Dual,2> &c, const Dual,2> &a, const
Dual,2>&b){
c = a*b;
}
void prod(Dual,2> &c, const Dual,2> &a, const
Dual,2>&b){
c = a*b;
}
GCC 13.2 asm, when compiling with
-std=gnu++23 -march=skylake-avx512 -mprefer-vector-width=512 -O3
prod(Dual, 2l>&, Dual, 2l> const&,
Dual, 2l> const&):
pushrbp
mov eax, -2
kmovb k1, eax
mov rbp, rsp
and rsp, -64
sub rsp, 264
vmovdqa ymm4, YMMWORD PTR [rsi+128]
vmovapd zmm8, ZMMWORD PTR [rsi]
vmovapd zmm9, ZMMWORD PTR [rdx]
vmovdqa ymm6, YMMWORD PTR [rsi+64]
vmovdqa YMMWORD PTR [rsp+8], ymm4
vmovdqa ymm4, YMMWORD PTR [rdx+96]
vbroadcastsdzmm0, xmm8
[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 --- Comment #4 from Florian Weimer --- What I can I do here to help? What's an easy emutls target to build?
[Bug c++/112820] vtable not emitted correctly from module when compiling with -g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112820 Nathaniel Shead changed: What|Removed |Added CC||nathanieloshead at gmail dot com --- Comment #1 from Nathaniel Shead --- The issue seems to be that the same flag is used for DECL_EXTERN and TYPE_DECL_SUPPRESS_DEBUG, and the modules reading code is getting confused and thinking that TYPE_DECLs with the latter flag set means that they are actually DECL_EXTERN and thus preventing them from being emitted. The following hunk fixes this issue but it'd probably be better to clean up all handling of extern within the modules reading so that we don't lose the "suppress debug" flag entirely. diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc index 33fcf396875..add3fa4b945 100644 --- a/gcc/cp/module.cc +++ b/gcc/cp/module.cc @@ -5397,7 +5397,7 @@ trees_out::core_bools (tree t) DECL_NOT_REALLY_EXTERN -> base.not_really_extern == that was a lie, it is here */ - bool is_external = t->decl_common.decl_flag_1; + bool is_external = code != TYPE_DECL && t->decl_common.decl_flag_1; if (!is_external) /* decl_flag_1 is DECL_EXTERNAL. Things we emit here, might well be external from the POV of an importer. */
[Bug tree-optimization/112824] Stack spills and vector splitting with vector builtins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112824 --- Comment #1 from Chris Elrod --- Here I have added a godbolt example where I manually unroll the array, where GCC generates excellent code https://godbolt.org/z/sd4bhGW7e I'm not sure it is 100% optimal, but with an inner Dual size of `7`, on Skylake-X it is 38 uops for unrolled GCC with separate struct fields, vs 49 uops for Clang, vs 67 for GCC with arrays. uica expects <14 clock cycles for the manually unrolled vs >23 for the array version. My experience so far with expression templates has born this out: compilers seem to struggle with peeling away abstractions.
[Bug target/112743] RISC-V: building FAIL with -march=rv64(or rv32)gc_zve32f_zvfh_zfh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112743 JuzheZhong changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #7 from JuzheZhong --- Fixed
[Bug c++/112794] [contracts] modifying return value fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112794 Jason Merrill changed: What|Removed |Added Last reconfirmed||2023-12-02 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug c++/110734] Attributes cannot be applied to asm declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110734 --- Comment #20 from Julian Waters --- cppreference at least seems to indicate it retroactively applies to C++11 https://en.cppreference.com/w/cpp/language/asm
[Bug fortran/100651] [11/12/13/14 Regression] Bad handling of optional, allocatable character argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100651 --- Comment #16 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:27ce74fa23c93c1189c301993cd19ea766e6bdb5 commit r14-6081-g27ce74fa23c93c1189c301993cd19ea766e6bdb5 Author: Harald Anlauf Date: Fri Dec 1 22:44:30 2023 +0100 Fortran: deferred-length character optional dummy arguments [PR93762,PR100651] gcc/fortran/ChangeLog: PR fortran/93762 PR fortran/100651 * trans-array.cc (gfc_trans_deferred_array): Add presence check for optional deferred-length character dummy arguments. * trans-expr.cc (gfc_conv_missing_dummy): The character length for deferred-length dummy arguments is passed by reference, so that its value can be returned. Adjust handling for optional dummies. gcc/testsuite/ChangeLog: PR fortran/93762 PR fortran/100651 * gfortran.dg/optional_deferred_char_1.f90: New test.
[Bug fortran/93762] Truncation of deferred-length string when passing as optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93762 --- Comment #5 from GCC Commits --- The master branch has been updated by Harald Anlauf : https://gcc.gnu.org/g:27ce74fa23c93c1189c301993cd19ea766e6bdb5 commit r14-6081-g27ce74fa23c93c1189c301993cd19ea766e6bdb5 Author: Harald Anlauf Date: Fri Dec 1 22:44:30 2023 +0100 Fortran: deferred-length character optional dummy arguments [PR93762,PR100651] gcc/fortran/ChangeLog: PR fortran/93762 PR fortran/100651 * trans-array.cc (gfc_trans_deferred_array): Add presence check for optional deferred-length character dummy arguments. * trans-expr.cc (gfc_conv_missing_dummy): The character length for deferred-length dummy arguments is passed by reference, so that its value can be returned. Adjust handling for optional dummies. gcc/testsuite/ChangeLog: PR fortran/93762 PR fortran/100651 * gfortran.dg/optional_deferred_char_1.f90: New test.
[Bug fortran/112772] Some issues with OPTIONAL, ALLOCATABLE dummy arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112772 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Keywords||wrong-code Target Milestone|--- |14.0 Status|UNCONFIRMED |RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed testcase 1. Testcase 2 is dealt with by the fix for pr100651.
[Bug modula2/112825] New: Modula 2 builds target objects as part of all-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112825 Bug ID: 112825 Summary: Modula 2 builds target objects as part of all-gcc Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: modula2 Assignee: gaius at gcc dot gnu.org Reporter: rsandifo at gcc dot gnu.org Target Milestone: --- Normally, it's possible to do: ../src/configure --target=foo make -jN all-gcc without having a full build environment (binutils, sysroot, etc.) for target foo. This is useful for sanity checks and investigating bugs on other targets. It's also useful for config-list.mk. However, the Modula 2 build tries to build target objects as part of all-gcc. The specific route I see is: Considering target file 'm2.info'. File 'm2.info' does not exist. Considering target file 'doc/m2.info'. File 'doc/m2.info' does not exist. Considering target file '../../gcc/gcc/doc/gm2.texi'. File '../../gcc/gcc/doc/gm2.texi' was considered already. Considering target file 'm2/gm2-libs.texi'. File 'm2/gm2-libs.texi' does not exist. Considering target file 'gm2-libs.texi-check'. File 'gm2-libs.texi-check' does not exist. Considering target file 'm2/SYSTEM-pim.texi'. File 'm2/SYSTEM-pim.texi' does not exist. Considering target file 'SYSTEM-pim-texi-check'. File 'SYSTEM-pim-texi-check' does not exist. Considering target file '.../gcc/git/tmp/gcc/m2/gm2-libs/SYSTEM.def'. File '.../gcc/git/tmp/gcc/m2/gm2-libs/SYSTEM.def' does not exist. Pruning file 'gm2'. Pruning file 'xgcc'. Pruning file 'cc1gm2'. Finished prerequisites of target file '.../gcc/git/tmp/gcc/m2/gm2-libs/SYSTEM.def'. Must remake target '.../gcc/git/tmp/gcc/m2/gm2-libs/SYSTEM.def'.
[Bug c/112826] New: gcc rejects the valid code and reports undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112826
Bug ID: 112826
Summary: gcc rejects the valid code and reports undefined
reference
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: jwzeng at nuaa dot edu.cn
Target Milestone: ---
Hi, the following code seems valid. Gcc rejects it while clang accepts.
Compiler explorer: https://godbolt.org/z/sPK9sYqc6
```c
$ cat test.c
int* a();
static int b() { int *c = a();}
int main() {}
$
$ gcc test.c
/tmp/cchtt1Nc.o:test.c:function b: error: undefined reference to 'a'
collect2: error: ld returned 1 exit status
$
$ clang test.c
test.c:2:31: warning: non-void function does not return a value [-Wreturn-type]
2 | static int b() { int *c = a();}
| ^
1 warning generated.
$
$ gcc --version
gcc (GCC) 13.1.0
Copyright (C) 2023 Free Software Foundation, Inc.
$
$ clang --version
clang version 16.0.0
Target: x86_64-unknown-linux-gnu
Thread model: posix
```
[Bug c/112826] gcc rejects the valid code and reports undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112826 Arsen Arsenović changed: What|Removed |Added CC||arsen at gcc dot gnu.org --- Comment #1 from Arsen Arsenović --- I can't assert the validity of this code, but -O1 does elide the function as expected.
[Bug c/112826] gcc rejects the valid code and reports undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112826 Xi Ruoyao changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED CC||xry111 at gcc dot gnu.org --- Comment #2 from Xi Ruoyao --- N1570 6.9 p2: "If an identifier declared with external linkage is used in an expression (other than as part of the operand of a sizeof or _Alignof operator whose result is an integer constant), somewhere in the entire program there shall be exactly one external definition for the identifier" and annex J.2 explicitly lists "An identifier with external linkage is used, but in the program there does not exist exactly one external definition for the identifier" as undefined behavior. Note that you cannot interpret "used" as "really executed at runtime" because it's impossible to solve halting problem, so such an "interpretation" will render the entire standard nonsense.
[Bug middle-end/112822] [14 regression] ICE: invalid RHS for gimple memory store after r14-5831-gaae723d360ca26
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112822 Peter Bergner changed: What|Removed |Added Last reconfirmed||2023-12-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Peter Bergner --- (In reply to Andrew Pinski from comment #1) > >This is a huge C++ program that I have not cut down yet. > > I think it didn't attach because it was too big, maybe compress and attach > that. I have a creduce running to minimize it. Looks like it'll take a while to run. I'll attach it when it's done. I also note Bill's build was configured with --with-cpu=power10, so -O3 -mcpu=power10 are the options required to hit the ICE. Confirmed.
[Bug tree-optimization/112827] New: ICE on valid code at -O1 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112827
Bug ID: 112827
Summary: ICE on valid code at -O1 on x86_64-linux-gnu:
Segmentation fault
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: zhendong.su at inf dot ethz.ch
Target Milestone: ---
This appears to be a recent regression as it does not reproduce with 13.2.
Compiler Explorer: https://godbolt.org/z/4EhdjPE6o
[507] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231202 (experimental) (GCC)
[508] %
[508] % gcctk -O1 small.c
during GIMPLE pass: sccp
small.c: In function ‘main’:
small.c:2:5: internal compiler error: Segmentation fault
2 | int main() {
| ^~~~
0x105e273 crash_signal
../../gcc-trunk/gcc/toplev.cc:316
0x1149492 gimple_bb(gimple const*)
../../gcc-trunk/gcc/gimple.h:1908
0x1149492 instantiate_scev_name
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2263
0x1149492 instantiate_scev_r
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2637
0x1149dee instantiate_scev(edge_def*, loop*, tree_node*)
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2719
0x114bae9 instantiate_parameters(loop*, tree_node*)
../../gcc-trunk/gcc/tree-scalar-evolution.h:64
0x114bae9 simplify_peeled_chrec
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1344
0x11488a6 analyze_evolution_in_loop
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1455
0x11488a6 interpret_loop_phi
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1587
0x11488a6 analyze_scalar_evolution_1
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1975
0x114849a analyze_scalar_evolution_1
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1958
0x1148e24 analyze_scalar_evolution(loop*, tree_node*)
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2039
0x11483ee interpret_condition_phi
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1611
0x11483ee analyze_scalar_evolution_1
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1977
0x1148e24 analyze_scalar_evolution(loop*, tree_node*)
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2039
0x114abd2 interpret_rhs_expr
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1641
0x1148579 interpret_gimple_assign
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1919
0x1148579 analyze_scalar_evolution_1
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1970
0x1148e24 analyze_scalar_evolution(loop*, tree_node*)
../../gcc-trunk/gcc/tree-scalar-evolution.cc:2039
0x114abd2 interpret_rhs_expr
../../gcc-trunk/gcc/tree-scalar-evolution.cc:1641
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[509] %
[509] % cat small.c
int a, b, c, d, e;
int main() {
for (; c; c++) {
for (a = 0; a < 2; a++)
;
for (; b; b++) {
e = d;
d = a;
}
}
return 0;
}
[Bug tree-optimization/112827] [14 Regression] ICE on valid code at -O1 on x86_64-linux-gnu: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112827 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Target Milestone|--- |14.0 Summary|ICE on valid code at -O1 on |[14 Regression] ICE on |x86_64-linux-gnu: |valid code at -O1 on |Segmentation fault |x86_64-linux-gnu: ||Segmentation fault Last reconfirmed||2023-12-02 --- Comment #1 from Andrew Pinski --- Confirmed.
[Bug middle-end/112406] [14 Regression] Several SPECCPU 2017 benchmarks fail with on internal compiler error: in expand_insn, at optabs.cc:8305 after g:01c18f58d37865d5f3bbe93e666183b54ec608c7
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112406 --- Comment #24 from Andrew Pinski --- (In reply to GCC Commits from comment #22) > gcc/testsuite/ChangeLog: > > * gcc.target/aarch64/pr112406-2.c: New test. This testcase now fails after the recent changes to make some warnings defaulting to errors: /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:8:1: error: type defaults to 'int' in declaration of 'GetImageChannelMoments_image' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:8:31: error: type defaults to 'int' in declaration of 'GetImageChannelMoments_image_0' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:9:5: error: type defaults to 'int' in declaration of 'GetImageChannelMoments___trans_tmp_1' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:9:43: error: type defaults to 'int' in declaration of 'GetImageChannelMoments_M11_0' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:10:5: error: type defaults to 'int' in declaration of 'GetImageChannelMoments_pixel_3' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:10:37: error: type defaults to 'int' in declaration of 'GetImageChannelMoments_y' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:11:5: error: type defaults to 'int' in declaration of 'GetImageChannelMoments_p' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:18:1: error: return type defaults to 'int' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:22:1: error: return type defaults to 'int' [-Wimplicit-int] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c: In function 'GetImageChannelMoments': /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:36:42: error: implicit declaration of function 'atan' [-Wimplicit-function-declaration] /home/apinski/src/upstream-full-cross/gcc/gcc/testsuite/gcc.target/aarch64/pr112406.c:36:42: note: include '' or provide a declaration of 'atan'
[Bug other/112823] [11 only] -Wincompatible-pointer-types errors in libiberty/simple-object-mach-o.c (missing backport for gcc-11)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112823 Sam James changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Sam James --- https://inbox.sourceware.org/gcc-patches/87plzp5ac8@gentoo.org/T/#m8edd6947776f6d591121340d391f824d897605d0 It got merged w/o the PR #: commit 02cd761eb1198df50453b2e39653f48053609ffc (HEAD -> releases/gcc-11, origin/releases/gcc-11) Author: Iain Sandoe Date: Mon Aug 23 17:34:43 2021 +0100 libiberty, Darwin: Fix a build warning. r12-3005-g220c410162ebece4f missed a cast for the set_32 call. Fixed thus. Signed-off-by: Iain Sandoe libiberty/ChangeLog: * simple-object-mach-o.c (simple_object_mach_o_write_segment): Cast the first argument to set_32 as needed. (cherry picked from commit 38757aa88735ab2e511bc428e2407a5a5e9fa0be)
[Bug modula2/112825] Modula 2 builds target objects as part of all-gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112825 Gaius Mulley changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2023-12-02 Ever confirmed|0 |1 --- Comment #1 from Gaius Mulley --- Many thanks for the bug report - I'm looking into this.
[Bug c/112826] gcc rejects the valid code and reports undefined reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112826 Andrew Pinski changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=14105 --- Comment #3 from Andrew Pinski --- Note PR 14105 is the opposite request but both are invalid as both behavior with and without optimization is allowed by the C standard.
[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 Andrew Pinski changed: What|Removed |Added CC||pinskia at gcc dot gnu.org --- Comment #5 from Andrew Pinski --- (In reply to Florian Weimer from comment #4) > What I can I do here to help? What's an easy emutls target to build? --disable-tls is enough to get the warning while building libgcc on x86_64-linux-gnu: /home/apinski/src/upstream-gcc-match/gcc/libgcc/emutls.c:61:7: warning: conflicting types for built-in function ‘__emutls_get_address’; expected ‘void *(void *)’ [-Wbuiltin-declaration-mismatch] 61 | void *__emutls_get_address (struct __emutls_object *); | ^~~~ /home/apinski/src/upstream-gcc-match/gcc/libgcc/emutls.c:63:6: warning: conflicting types for built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned int, unsigned int, void *)’ [-Wbuiltin-declaration-mismatch] 63 | void __emutls_register_common (struct __emutls_object *, word, word, void *); | ^~~~ /home/apinski/src/upstream-gcc-match/gcc/libgcc/emutls.c:140:1: warning: conflicting types for built-in function ‘__emutls_get_address’; expected ‘void *(void *)’ [-Wbuiltin-declaration-mismatch] 140 | __emutls_get_address (struct __emutls_object *obj) | ^~~~ /home/apinski/src/upstream-gcc-match/gcc/libgcc/emutls.c:204:1: warning: conflicting types for built-in function ‘__emutls_register_common’; expected ‘void(void *, unsigned int, unsigned int, void *)’ [-Wbuiltin-declaration-mismatch] 204 | __emutls_register_common (struct __emutls_object *obj, | ^~~~ The build does not fail.
[Bug fortran/112828] New: Abort with malloc(): corrupted top size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112828 Bug ID: 112828 Summary: Abort with malloc(): corrupted top size Product: gcc Version: 13.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: townsend at astro dot wisc.edu Target Milestone: --- Created attachment 56768 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56768&action=edit MWE demonstrating problem When I compile the attached MWE with gfortran -o test test.f90 ...I get the following runtime error: malloc(): corrupted top size Program received signal SIGABRT: Process abort signal. Backtrace for this error: #0 0x7f13a2e7760f in ??? #1 0x7f13a2ec500c in ??? #2 0x7f13a2e77571 in raise #3 0x7f13a2e614b1 in abort #4 0x7f13a2e623b4 in ??? #5 0x7f13a2ece874 in ??? #6 0x7f13a2ed1fdf in ??? #7 0x7f13a2ed2b59 in __libc_malloc #8 0x40191a in MAIN__ #9 0x401c8c in main Aborted If I comment out the first allocate statement (the one with the STAT argument), then the program runs without problem (even though this statement isn't actually executed). There are a number of other things that make the bug go away; e.g., shrinking the length of the character variables in the main program to 20 or smaller. Setting the length to 21 still runs without error, but the second element of c_r ends up with some junk in it, viz: foo fooA cheers, Rich
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #6 from gnzlbg --- Thanks for all the quick feedback! > Also clang does not even document __builtin_ctzs anywhere ... This builtin is documented in the list of clang bultins. You can find it by using CTRL+F for the builtin, in that list, https://clang.llvm.org/docs/LanguageExtensions.html, which is the first link that Google reveals when searching for this exact builtin. Hope that helps. > ok, and? There is an HPC QCD app that was developed mostly using clang, and for which we can't apply source code modifications, that we'd like to compile which GCC as is, but currently doesn't due to this issue. Does that make sense? > You could just do: Thanks for the workaround! We were already using something similar as a temporary stopgap, but can't use that forever. Hope that makes sense! Thanks!
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #7 from Andrew Pinski --- (In reply to gnzlbg from comment #6) > Thanks for all the quick feedback! > > > Also clang does not even document __builtin_ctzs anywhere ... > > This builtin is documented in the list of clang bultins. You can find it by > using CTRL+F for the builtin, in that list, > https://clang.llvm.org/docs/LanguageExtensions.html, which is the first link > that Google reveals when searching for this exact builtin. Hope that helps. Look at that part where __builtin_ctzs is mentioned there. It just says it is valid inside a constexpr and nothing else about the builtin. >There is an HPC QCD app that was developed mostly using clang, and for which >we can't apply source code modifications, that we'd like to compile which GCC >as is, but currently doesn't due to this issue. Sounds like that HPC QCD app is broken. You should report it to the developers. Also since __builtin_ctzg is added, adding __builtin_ctzs really does not make any sense since it would just done as `#define __builtin_ctzs __builtin_ctzg((unsigned short)a)` in the source.
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #8 from gnzlbg --- Oh! Sorry! I see this was resolved as WONTFIX. Does that mean that GCC, in contrast with the LLVM community - which is always super helpful and friendly when it comes to trying to enable their toolchains to compile SW developed with GNU - intentionally does not want to enable the GNU toolchains to compile SW developed with clang? If that's the case, and this is community policy, and the person who closed this as WONTFIX speaks for the entirety of the GNU community, such that no patches to fix this will be accepted, then thank you for your time considering this issue and for your prompt response!
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #9 from gnzlbg --- > > Look at that part where __builtin_ctzs is mentioned there. > It just says it is valid inside a constexpr and nothing else about the > builtin. Yes, seems like a bug / pr should be opened in the llvm project to better document what the intrinsic does. I'll do that later. > Sounds like that HPC QCD app is broken. To you maybe. To me it seems like GCC is broken, hence why I opened the bug.
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #10 from Andrew Pinski --- (In reply to gnzlbg from comment #8) > Oh! Sorry! I see this was resolved as WONTFIX. > > Does that mean that GCC, in contrast with the LLVM community - which is > always super helpful and friendly when it comes to trying to enable their > toolchains to compile SW developed with GNU - intentionally does not want to > enable the GNU toolchains to compile SW developed with clang? Wait, there is a builtin that does exactly the same as what you need/wanted to do. Is there a need for another builtin? > > If that's the case, and this is community policy, and the person who closed > this as WONTFIX speaks for the entirety of the GNU community, such that no > patches to fix this will be accepted, then thank you for your time > considering this issue and for your prompt response! Since there is a new builtin included already to do the same thing as __builtin_ctzs but in a generic fashion (added to support _BitInt and the C23 bit functions), why add another builtin that is just there. Also reading the history on __builtin_ctzs for clang and even for GCC (it exists as an x86_64 target builtin with a specific option but undocumented because it was only to be used by the intrinics), you will see clang added it as a generic builtin and didn't document the behavior or anything. The history here seems clang added it to be compatiable with GCC's internal intrinsics implementation and exposed it for all targets but didn't document it. So the situtation we are at right now, add the builtin as a non-target specific builtin for GCC just to be compatiable with clang but we have no idea what the semantics of the builtin is because it is not documented.
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789 --- Comment #11 from Sam James --- (In reply to Andrew Pinski from comment #7) > Sounds like that HPC QCD app is broken. You should report it to the > developers. Also since __builtin_ctzg is added, adding __builtin_ctzs really > does not make any sense since it would just done as `#define __builtin_ctzs > __builtin_ctzg((unsigned short)a)` in the source. And you can achieve this in a bunch of ways without even directly modifying the source via the command line.
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789
--- Comment #12 from Andrew Pinski ---
(In reply to Sam James from comment #11)
> (In reply to Andrew Pinski from comment #7)
> > Sounds like that HPC QCD app is broken. You should report it to the
> > developers. Also since __builtin_ctzg is added, adding __builtin_ctzs really
> > does not make any sense since it would just done as `#define __builtin_ctzs
> > __builtin_ctzg((unsigned short)a)` in the source.
>
> And you can achieve this in a bunch of ways without even directly modifying
> the source via the command line.
One way is to do the add `-include ${PATH_TO_SRC}/clang_builtins_to_gcc.h` to
the command line and have something like:
```
#ifndef __CLANG_BUILTINS_TO_GCC_H__
#define __CLANG_BUILTINS_TO_GCC_H__
#if !__has_builtin(__builtin_ctzs)
static inline unsigned short __builtin_ctzs(unsigned short a)
{
#if __has_builtin(__builtin_ctzg)
return __builtin_ctzg(a);
#else
#error implement fallback
#endif
}
#endif
#endif
```
in clang_builtins_to_gcc.h .
[Bug target/112813] [14 Regression] RISCV ICE: vsetvl pass: in merge at config/riscv/riscv-vsetvl.cc:1968 on rv32gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112813 --- Comment #1 from JuzheZhong --- I think it's probably fixed on the trunk by my recent patch: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=923a67f17badcbe6e2b2e5d3570a265443258c8e If it has been fixed, plz verify it and send a patch with testcase directly. Thanks.
[Bug libgcc/109289] Conflicting types for built-in functions in libgcc/emutls.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109289 --- Comment #6 from Jan Dubiec --- (In reply to Florian Weimer from comment #3) > Jan, do you actually experience a build failure? The part you quoted only > shows warnings. Florian, it used to be just the warnings, but now (commit 1461b431) I am not even able to reach emutls.c: [...] rm -rf libcommon.a ar rc libcommon.a diagnostic-spec.o diagnostic.o diagnostic-color.o diagnostic-format-json.o diagnostic-format-sarif.o diagnostic-show-locus.o edit-context.o pretty-print.o intl.o json.o sbitmap.o vec.o input.o hash-table.o ggc-none.o memory-block.o selftest.o selftest-diagnostic.o sort.o text-art/box-drawing.o text-art/canvas.o text-art/ruler.o text-art/selftests.o text-art/style.o text-art/styled-string.o text-art/table.o text-art/theme.o text-art/widget.o ranlib libcommon.a make[2]: *** No rule to make target '../libiberty/pic/libiberty.a', needed by 'cc1-checksum.cc'. Stop. make[2]: Leaving directory '/d/works/xcomp/gcc-build/gcc' make[1]: *** [Makefile:4645: all-gcc] Error 2 make[1]: Leaving directory '/d/works/xcomp/gcc-build' make: *** [Makefile:1048: all] Error 2 Host: Windows/MSYS2, targets: ARM and H8
[Bug c++/112789] Missing clang __builtin_ctzs for short
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112789
Xi Ruoyao changed:
What|Removed |Added
CC||xry111 at gcc dot gnu.org
--- Comment #13 from Xi Ruoyao ---
(In reply to gnzlbg from comment #8)
> Oh! Sorry! I see this was resolved as WONTFIX.
>
> Does that mean that GCC, in contrast with the LLVM community - which is
> always super helpful and friendly when it comes to trying to enable their
> toolchains to compile SW developed with GNU - intentionally does not want to
> enable the GNU toolchains to compile SW developed with clang?
Because Clang developers actively claim to support GNU extensions, while GCC
never has such a policy to support other extensions. When an extension is
considered useful we port it, but in this case we already have __builtin_ctzg
as all others have mentioned.
And Clang developers also reject GNU extensions if they consider the extension
"wrong", despite they make such a "compatibility" claim.
In the future (when C23 is widely adopted) people should just use
stdc_trailing_zerosus instead of directly invoking __builtin_ctz{g,s} of
whatever compiler.
[Bug gcov-profile/112829] New: Dump PGO profiles to a memory buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112829 Bug ID: 112829 Summary: Dump PGO profiles to a memory buffer Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: gcov-profile Assignee: unassigned at gcc dot gnu.org Reporter: zamazan4ik at tut dot by CC: marxin at gcc dot gnu.org Target Milestone: --- According to the GCC documentation (https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html) the only option is to dump PGO profiles to a filesystem. I am looking for an option to dump PGO profiles into a memory buffer. LLVM infrastructure has such an ability - it's documented here: https://clang.llvm.org/docs/SourceBasedCodeCoverage.html#using-the-profiling-runtime-without-a-filesystem . If GCC has such an ability too - would be great if it would be described somewhere in the Instrumentation documentation (or in any other better place in your opinion). The use case for having this is simple - in some systems, a filesystem can be read-only (e.g. due to security concerns) or even not enough to handle the PGO profile. With the memory approach, we will be able to collect PGO profiles and then deliver and expose them via other interfaces like HTTP or MQTT. I guess some related information can be found here (https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libgcc/libgcov-profiler.c) but I am not sure.
