[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek --- If you want to make something always_inline, define it in the header rather than having just a non-always_inline declaration in the header and definition in some TU. Because without LTO that means it will never be actually attempted to be inlined, and with LTO it can't be inlined until the IPA inlining which -O0 or -Og don't perform. Or, if the intention is that all calls to the function within its TU are inlined and not the other ones, split the function into two, one always_inline which is used from within the TU and another one which just calls it and is used from other TUs.
[Bug tree-optimization/112941] during GIMPLE pass: bitintlower ICE: in handle_operand_addr, at gimple-lower-bitint.cc:2126 (gimple-lower-bitint.cc:2134) at -O with _BitInt()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek --- Fixed.
[Bug target/113112] RISC-V: Dynamic LMUL feature stabilization for GCC-14 release
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113112
--- Comment #5 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:a43bd8255451227fc1cd3601b1f0265b21fafada
commit r14-6889-ga43bd8255451227fc1cd3601b1f0265b21fafada
Author: Juzhe-Zhong
Date: Tue Jan 2 11:37:43 2024 +0800
RISC-V: Make liveness be aware of rgroup number of LENS[dynamic LMUL]
This patch fixes the following situation:
vl4re16.v v12,0(a5)
...
vl4re16.v v16,0(a3)
vs4r.v v12,0(a5)
...
vl4re16.v v4,0(a0)
vs4r.v v16,0(a3)
...
vsetvli a3,zero,e16,m4,ta,ma
...
vmv.v.x v8,t6
vmsgeu.vv v2,v16,v8
vsub.vv v16,v16,v8
vs4r.v v16,0(a5)
...
vs4r.v v4,0(a0)
vmsgeu.vv v1,v4,v8
...
vsub.vv v4,v4,v8
sllia6,a4,2
vs4r.v v4,0(a5)
...
vsub.vv v4,v12,v8
vmsgeu.vv v3,v12,v8
vs4r.v v4,0(a5)
...
There are many spills which are 'vs4r.v'. The root cause is that we don't
count
vector REG liveness referencing the rgroup controls.
_29 = _25->iatom[0]; is transformed into the following vect statement with
4 different loop_len (loop_len_74, loop_len_75, loop_len_76, loop_len_77).
vect__29.11_78 = .MASK_LEN_LOAD (vectp_sb.9_72, 32B, { -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }, loop_len_74, 0);
vect__29.12_80 = .MASK_LEN_LOAD (vectp_sb.9_79, 32B, { -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }, loop_len_75, 0);
vect__29.13_82 = .MASK_LEN_LOAD (vectp_sb.9_81, 32B, { -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }, loop_len_76, 0);
vect__29.14_84 = .MASK_LEN_LOAD (vectp_sb.9_83, 32B, { -1, -1, -1, -1,
-1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1, -1 }, loop_len_77, 0);
which are the LENS number (LOOP_VINFO_LENS (loop_vinfo).length ()).
Count liveness according to LOOP_VINFO_LENS (loop_vinfo).length () to
compute liveness more accurately:
vsetivlizero,8,e16,m1,ta,ma
vmsgeu.vi v19,v14,8
vadd.vi v18,v14,-8
vmsgeu.vi v17,v1,8
vadd.vi v16,v1,-8
vlm.v v15,0(a5)
...
Tested no regression, ok for trunk ?
PR target/113112
gcc/ChangeLog:
* config/riscv/riscv-vector-costs.cc (compute_nregs_for_mode): Add
rgroup info.
(max_number_of_live_regs): Ditto.
(has_unexpected_spills_p): Ditto.
gcc/testsuite/ChangeLog:
* gcc.dg/vect/costmodel/riscv/rvv/pr113112-5.c: New test.
[Bug middle-end/113212] New: expand_expr_real_2 first argument can be constified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113212 Bug ID: 113212 Summary: expand_expr_real_2 first argument can be constified Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: internal-improvement Severity: normal Priority: P3 Component: middle-end Assignee: pinskia at gcc dot gnu.org Reporter: pinskia at gcc dot gnu.org Target Milestone: --- Filing this to remind myself to submit a patch for this when stage 1 opens up.
[Bug middle-end/113212] expand_expr_real_2 first argument can be constified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113212 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-03 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1
[Bug c++/113211] Trying to initialize the tripwire database ends up with a SEGV if a uid cannot be found
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113211 Sam James changed: What|Removed |Added CC||sjames at gcc dot gnu.org --- Comment #6 from Sam James --- (In reply to Andrew Pinski from comment #5) > Also I doubt this is a glibc issue either. Basically if you use getpwuid, > etc. in a static linked executable, it will use dlopen and TLS in a shared > library is not compatiable with a static linked executable. It even warns about that at link-time.
[Bug middle-end/113212] expand_expr_real_2 first argument can be constified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113212 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug libstdc++/113202] std::find does not work with the maximum range of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113202 --- Comment #6 from Carsten Schmidt --- > Why do you think this is a bug? 1. Considering the "possible implementation" of cppreference.com, pointer arithmetic, e.g. ptr-ptr, should not be an issue when searching for the sentinel. 2. Using ranges::find() does not show the observed behavior. 3. Other implementations of the libstdc++, e.g. MSVC, work properly.
[Bug libstdc++/113202] std::find does not work with the maximum range of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113202 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #7 from Andrew Pinski --- Note doing std::find(a, max) where max is outside of the array (or one element more than the array) is undefined code. Which means libstdc++ is working correctly. I suspect you should just use strlen if you want to find the null character in an unbounded array.
[Bug libstdc++/113202] std::find does not work with the maximum range of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113202 --- Comment #8 from Andrew Pinski --- The assumption is first and last are part of the same iterator which means in the case of pointers, it needs to be addresses inside the array or one element past the array. Everything else is undefined. It just happens to work for msvc's library does not mean it is defined code.
[Bug libstdc++/113202] std::find does not work with the maximum range of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113202 --- Comment #9 from Xi Ruoyao --- (In reply to Carsten Schmidt from comment #6) > > Why do you think this is a bug? > > 1. Considering the "possible implementation" of cppreference.com, pointer >arithmetic, e.g. ptr-ptr, should not be an issue when searching for the >sentinel. Quoting from https://en.cppreference.com/w/cpp/iterator: An iterator j is called reachable from an iterator i if and only if there is a finite sequence of applications of the expression ++i that makes i == j. If j is reachable from i, they refer to elements of the same sequence. A range is a pair of iterators that designate the beginning and end of the computation. A range [i, i) is an empty range; in general, a range [i, j) refers to the elements in the data structure starting with the element pointed to by i and up to but not including the element pointed to by j. Range [i, j) is valid if and only if j is reachable from i. Here there is no finite sequences of applications of the expression ++i that makes i == j because running ++i will invoke undefined behavior far before i == j. Thus this range is invalid. And: The result of the application of functions in the standard library to invalid ranges is undefined.
[Bug libstdc++/113202] std::find does not work with the maximum range of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113202 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #10 from Xi Ruoyao --- And "possible implementation" is just one of the infinite allowed implementations. libstdc++ can use a different implementation for speed/simplicity/whatever as long as it does not violate the standard.
[Bug libstdc++/113159] More robust std::sort for silly comparator functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113159 --- Comment #8 from Jonathan Wakely --- I haven't seen a proof that libstdc++'s std::sort can't be made more robust without losing performance. Maybe cheap range checks can be done conditionally when _GLIBCXX_ASSERTIONS is defined, or maybe they'll be cheap enough to do unconditionally. Some work is needed to see what's feasible, but there's no reason to just close the request as INVALID.
[Bug c++/113200] std::char_traits::move is not constexpr when the argument is a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2024-01-03 Component|libstdc++ |c++ Status|UNCONFIRMED |NEW Keywords|rejects-valid |diagnostic Ever confirmed|0 |1 --- Comment #5 from Jonathan Wakely --- Let's recategorize this as a front-end diagnostic issue. GCC's error is bad. That's mostly because of the ((char*)(&((S<5>*)this)->S<5>::data_)) noise, but it would also be good to explicitly state that comparisons with literals give unspecified results and so are not constant expressions.
[Bug libstdc++/113202] std::find does not work with the maximum range of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113202 --- Comment #11 from Jonathan Wakely --- s + OFFSET has undefined behaviour. With -O2 or -O3 GCC even tells you where the problem is: find_bug.cpp: In function 'int main(int, char**)': find_bug.cpp:39:61: warning: array subscript 1048576 is outside array bounds of 'const char [6]' [-Warray-bounds=] 39 | std::cout << "strlen = " << strlen_no_ranges(s, s + OFFSET) << ", no ranges, OFFSET = " << OFFSET << std::endl; | ^ find_bug.cpp:40:58: warning: array subscript 1048576 is outside array bounds of 'const char [6]' [-Warray-bounds=] 40 | std::cout << "strlen = " << strlen_ranges(s, s + OFFSET)<< ", ranges,OFFSET = " << OFFSET << std::endl; |
[Bug target/113116] [14 Regression] ~11-17% exec time regression of 436.cactusADM on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113116 Tamar Christina changed: What|Removed |Added CC||tnfchris at gcc dot gnu.org Last reconfirmed||2024-01-03 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from Tamar Christina --- (In reply to Filip Kastl from comment #0) > As seen on the graphs here > > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=578.100.0 > https://lnt.opensuse.org/db_default/v4/SPEC/graph?plot.0=586.100.0 > > between commits > g:8e0568d8ac9dbfc8 > g:5641787abeea0fdc > > there is a slowdown of 436.cactusADM SPEC2006 benchmark, 11% for Ofast > native LTO PGO and 17% for Ofast native LTO. Did you mean -Ofast native PGO? both linked runs are PGO. In any case, confirmed. Running bisect.
[Bug libstdc++/113202] std::find does not work with the maximum range of pointers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113202 --- Comment #12 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #11) > s + OFFSET has undefined behaviour. ... and iterating from s to has undefined behaviour too, as explained above. Nothing the program does is valid.
[Bug libgomp/113213] New: [OpenMP] Update omp_target_is_present / omp_target_is_accessible handling for NULL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113213 Bug ID: 113213 Summary: [OpenMP] Update omp_target_is_present / omp_target_is_accessible handling for NULL Product: gcc Version: 14.0 Status: UNCONFIRMED Keywords: openmp Severity: normal Priority: P3 Component: libgomp Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: jakub at gcc dot gnu.org Target Milestone: --- Update omp_target_is_present / omp_target_is_accessible handling for NULL * Including documentation The non-public issue https://github.com/OpenMP/spec/issues/3287 is about to clarify that the result is false. This has also implications for device == initial device.
[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200 Jonathan Wakely changed: What|Removed |Added Component|c++ |libstdc++ Keywords|diagnostic |rejects-valid --- Comment #6 from Jonathan Wakely --- Although we should fix the libstdc++ problem first, then re-assign (or maybe file a separate bug for the FE diagnostic).
[Bug bootstrap/112534] [14 regression] build failure after r14-5424-gdb50aea6259545 using gcc 4.8.5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112534 --- Comment #12 from Arsen Arsenović --- (In reply to seurer from comment #11) > Did it work? yes, I sent it on the ML: https://inbox.sourceware.org/gcc-patches/20231221193243.368541-1-ar...@aarsen.me/
[Bug target/113116] [14 Regression] ~11-17% exec time regression of 436.cactusADM on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113116 --- Comment #3 from Filip Kastl --- (In reply to Tamar Christina from comment #2) > Did you mean -Ofast native PGO? both linked runs are PGO. Yes I did. I meant PGO and wrote LTO. My bad :).
[Bug sanitizer/113214] New: false-positive -Wstringop-overflow warning with thread sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214
Bug ID: 113214
Summary: false-positive -Wstringop-overflow warning with thread
sanitizer
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: arnd at linaro dot org
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: ---
I came across another -Wstringop-overflow warning while building the kernel in
a newly added device driver, when the thread sanitizer is enabled. Reduced my
test case to
void _dev_warn(const void *dev, ...);
struct xe_uc {
int guc;
};
struct xe_gt {
struct xe_tile *tile;
struct pf_queue {
unsigned int data[128];
unsigned int tail;
} pf_queue[4];
struct xe_uc uc;
};
#define container_of(ptr, type, member) ({ \
void *__mptr = (void *)(ptr); \
((type *)(__mptr - __builtin_offsetof(type, member))); })
void xe_guc_pagefault_handler(struct xe_uc *uc, int asid, void *msg, int len)
{
struct xe_gt *gt = container_of(uc, struct xe_gt, uc);
void *xe = gt->tile;
struct pf_queue *pf_queue;
if (len != 4)
return;
pf_queue = >->pf_queue[asid % 4];
__builtin_memcpy(pf_queue->data + pf_queue->tail,
msg, len * sizeof(unsigned int));
_dev_warn(xe);
}
Original source code at
https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git/tree/drivers/gpu/drm/xe/xe_gt_pagefault.c?h=next-20240103#n322
Reproducer at https://godbolt.org/z/MMaz8rqcj
aarch64-linux-gcc-13.2 -Wall -O2 -fsanitize=thread -Werror=stringop-overflow
-Wall -c xe_gt_pagefault.c
xe_gt_pagefault.c: In function 'xe_guc_pagefault_handler':
xe_gt_pagefault.c:26:9: error: writing 16 bytes into a region of size 0
[-Werror=stringop-overflow=]
26 | __builtin_memcpy(pf_queue->data + pf_queue->tail,
| ^
27 | msg, len * sizeof(unsigned int));
|
xe_gt_pagefault.c:6:25: note: at offset 8 into destination object 'tile' of
size 8
6 | struct xe_tile *tile;
| ^~~~
cc1: some warnings being treated as errors
Currently I see this with gcc-13.x and gcc-14.0 but not gcc-12.
[Bug middle-end/113215] New: gimple FE can't handle static local variable with initializer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113215
Bug ID: 113215
Summary: gimple FE can't handle static local variable with
initializer
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: acoplan at gcc dot gnu.org
Target Milestone: ---
The following testcase is accepted:
int __GIMPLE (ssa)
f ()
{
static int x;
__BB(2):
return 1;
}
but adding an initializer to the static variable, it gets rejected:
$ cat > t.c
int __GIMPLE (ssa)
f ()
{
static int x = 1;
__BB(2):
return 1;
}
$ gcc/xgcc -B gcc -c -fgimple t.c
t.c: In function ‘f’:
t.c:4:18: error: expected ‘;’ before ‘=’ token
4 | static int x = 1;
| ^
t.c: At top level:
t.c:5:10: error: expected declaration specifiers or ‘...’ before numeric
constant
5 | __BB(2):
| ^
t.c:7:1: error: expected identifier or ‘(’ before ‘}’ token
7 | }
| ^
such IL can be generated by dumping optimized GIMPLE as seen e.g. with the
following testcase:
$ cat t2.c
int f() {
static int x = 1;
return x;
}
$ gcc/xgcc -B gcc -c t2.c -fdump-tree-optimized-gimple=-
int __GIMPLE (ssa)
f ()
{
static int x = 1;
int D_4434;
int _2;
__BB(2):
_2 = x;
goto __BB3;
__BB(3):
L0:
return _2;
}
[Bug libgomp/113216] New: [OpenMP] Improve omp_target_is_accessible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113216
Bug ID: 113216
Summary: [OpenMP] Improve omp_target_is_accessible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: openmp
Severity: normal
Priority: P3
Component: libgomp
Assignee: unassigned at gcc dot gnu.org
Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
Target Milestone: ---
For omp_target_is_accessible + unified address:
* it is not 100% correct to assume that any address is accessible on the host,
it might be a device-only address
(For handling NULL, see also PR 113213)
Likewise for the nonhost device:
* memory might be accessible even if only unified address
* * *
The host case is a bit trickier as no generic documentation seems to be
available albeit some ranges like 0x7F.. seem to denote device addresses +
a superset has to be formed.
* * *
For the device side, an API function might be available to check for it.
* *
In case of nvptx / CUDA, the following function seems to be suitable:
CUresult cuMemGetAccess ( unsigned long long* flags,
const CUmemLocation* location, CUdeviceptr ptr )
checking for flags == CU_MEM_ACCESS_FLAGS_PROT_READWRITE, if I understand it
correctly.
typedef enum CUmemAccess_flags_enum {
CU_MEM_ACCESS_FLAGS_PROT_NONE = 0x0, /**< Default, make the address range
not accessible */
CU_MEM_ACCESS_FLAGS_PROT_READ = 0x1, /**< Make the address range read
accessible */
CU_MEM_ACCESS_FLAGS_PROT_READWRITE = 0x3, /**< Make the address range
read-write accessible */
CU_MEM_ACCESS_FLAGS_PROT_MAX = 0x7FFF
} CUmemAccess_flags;
* *
In case of HSA/ROCm, I bet there is also some function.
For instance, hipPointerGetAttribute{,s} + hipDrvPointerGetAttributes permit to
query some pointer data.
[Bug target/113115] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115 Michal Jireš changed: What|Removed |Added CC||jeevitha at gcc dot gnu.org, ||mjires at suse dot cz --- Comment #1 from Michal Jireš --- Bisected to r14-3592-g9ea1248604d7b6.
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
Target Milestone|--- |13.2
--- Comment #14 from Jonathan Wakely ---
(In reply to andysem from comment #13)
> (In reply to Jonathan Wakely from comment #12)
> > (In reply to andysem from comment #11)
> > > > I'm not sure what you mean by "the compiler is free to generate code
> > > > that takes it into account." Takes what into account? What problem does
> > > > that freedom cause?
> > >
> > > I mean the compiler could move (some part of) dynamic_cast to precede the
> > > check for the standard facet. I.e. of something like this:
> > >
> > > template< typename _Facet >
> > > const _Facet* __try_use_facet(locale const& loc)
> > > {
> > > const size_t __i = _Facet::id._M_id();
> > > const locale::facet** __facets = __loc._M_impl->_M_facets;
> > > const _Facet* __dyn_facet = __dynamic_cast< const _Facet*
> > > >(__facets[__i]);
> > >
> > > // checks for every standard facet type
> > > if (__is_same(_Facet, ...))
> > > return static_cast(__facets[__i]);
> > >
> > > return __dyn_facet;
> > > }
> >
> > But why? Maybe I'm being slow but I still don't understand what problem is
> > being solved here.
> >
> > Also this would defeat the optimization that avoids the unnecessary overhead
> > of dynamic_cast for standard facets.
>
> I have seen gcc sometimes reorder code like this (i.e. move code from under
> a branch before it), presumably to improve ILP or prefetch data, I'm not
> sure. Yes, that defeats the branch, if it is used as an optimization, and I
> had to prevent this by adding compiler fences in those cases. Granted, in my
> case it happened with inlined code, but I imagine LTO makes it possible to
> perform similar code transformations with out-of-line code as well.
Building libstdc++ with LTO is unsupported (and doesn't happen when building
GCC, it requires making custom changes to the build process, which again is
unsupported). That's a non-issue.
> I'm not saying this is what actually happens. I'm just pointing out that
> even the code that is apparently unreachable may influence codegen and cause
> ODR issues.
I'm still not seeing an actual problem here, just speculation.
The compiler knows that `if (__is_same(T,T))` is true, and will not move
unreachable code before it unless that code has no side effects. And if it has
no side effects, there's no problem.
Since GCC 13.2 there is no change in semantics or observable side effects when
the explicit instantiations for std::use_facet (which are compiled with -frtti)
are used, or the function is inlined (which might be compiled with -fno-rtti).
For the gcc-11 and gcc-12 branches would could suppress the explicit
instantiation declarations for -fno-rtti, so that the extern template
definitions do not try to use dynamic_cast on a type that has no RTTI. But then
we'd need to backport (at least part of) the PR 103755 changes to use
static_cast for standard facets. Otherwise std::use_facet and std::has_facet
would always fail, even for the standard facets which are guaranteed to be
present. I don't think we want to do that on the stable branches, so I think
this is WONTFIX for GCC 13.1 and earlier, and FIXED for 13.2 and later.
[Bug libstdc++/113099] locale without RTTI uses dynamic_cast before gcc 13.2 or has ODR violation since gcc 13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113099 --- Comment #15 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #8) > (In reply to Peter Dimov from comment #7) > > You don't necessarily need dynamic_cast because facets are always installed > > and obtained by their exact type, not via a reference to base. > > Is that true? std::use_facet will return a reference to a facet with > X::id but it could actually be something derived from X. e.g. a user can > install their own facet derived from std::ctype, which overrides some > members. Code that does std::use_facet>(loc) will get the > user's facet, but via reference to base. And conversely, for std::use_facet the locale might contain a base class of Y, with the same id as Y::id, but there is no Y present. For example, given the OP's my_codecvt, the following code must throw std::bad_cast: std::locale loc; (void) std::use_facet(loc); There is no my_codecvt present. There is a facet with the same id, but its dynamic type is std::codecvt not my_codecvt. I don't see a way to avoid using dynamic_cast without an ABI change to the std::locale in libstdc++.
[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200
--- Comment #7 from Jonathan Wakely ---
Why does GCC accept this reduced version, which is invalid for the same reason
as the original?
#include
constexpr int N = 5;
struct S
{
char data_[ N ];
constexpr S( char const* p )
{
std::char_traits::move( data_, p, N );
}
};
constexpr S s( "test" );
Clang rejects it the same way.
[Bug c++/70248] constexpr initialization with unspecified equality expression accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248
Jonathan Wakely changed:
What|Removed |Added
Last reconfirmed|2020-10-15 00:00:00 |2024-1-3
--- Comment #11 from Jonathan Wakely ---
And another:
struct S
{
char data_[ 5 ];
constexpr S( char const* p ) : data_()
{
if (p == data_)
return;
for (int i = 0; i < 5; ++i)
data_[i] = p[i];
}
};
constexpr S s( "test" );
[Bug libstdc++/113200] std::char_traits::move is not constexpr when the argument is a string literal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113200 --- Comment #8 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #7) > Why does GCC accept this reduced version, which is invalid for the same > reason as the original? Looks like PR 70248
[Bug c++/70248] constexpr initialization with unspecified equality expression accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248 --- Comment #12 from Jonathan Wakely --- If the comparison happens in a template, GCC rejects it (see PR 113200).
[Bug c++/70248] constexpr initialization with unspecified equality expression accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70248
--- Comment #13 from Jonathan Wakely ---
Although this is accepted even though it's in a template, so it's more
complicated than just template vs non-template:
template
consteval void f( char const* p )
{
char buf[N]{};
if (p == buf) // unspecified
return;
for (int i = 0; i < 5; ++i)
buf[i] = p[i];
}
int main()
{
f("test");
}
[Bug tree-optimization/113120] during GIMPLE pass: bitintlower ICE: SIGSEGV with _BitInt() at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113120 Jakub Jelinek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 56983 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56983&action=edit gcc14-pr113120.patch Untested fix.
[Bug libgomp/113192] [11/12/13/14 Regression] ERROR: couldn't execute "../../../gcc/libgomp/testsuite/flock": no such file or directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113192 --- Comment #2 from dave.anglin at bell dot net --- On 2024-01-02 10:21 a.m., tschwinge at gcc dot gnu.org wrote: > Aha, sorry. Does it work if you changes: > > -AC_CHECK_PROG(FLOCK, perl, $srcdir/testsuite/flock) > +AC_CHECK_PROG(FLOCK, perl, $ac_abs_srcdir/testsuite/flock) No, we get: ERROR: couldn't execute "/testsuite/flock": no such file or directory I see top_srcdir is used in some files.
[Bug c++/106653] [C++23] P2582 - Class template argument deduction from inherited constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106653 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED CC||ppalka at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |14.0 Status|NEW |RESOLVED --- Comment #2 from Patrick Palka --- Implemented in r14-6551-g83088b331cde08 for GCC 14.
[Bug c++/98940] Implement C++23 language features
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98940 Bug 98940 depends on bug 106653, which changed state. Bug 106653 Summary: [C++23] P2582 - Class template argument deduction from inherited constructors https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106653 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/113217] New: [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113217
Bug ID: 113217
Summary: [14 Regression][aarch64] ICE in rtl_verify_bb_insns,
at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at suse dot cz
CC: acoplan at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Compiling reduced testcase g++.dg/vect/pr45470-b.cc results in ICE since
r14-6605-gc0911c6b357ba9.
$ cat pr45470-b.cc
struct _Vector_base {
int _M_end_of_storage;
};
struct vector : _Vector_base {
vector() : _Vector_base() {}
~vector();
};
struct LoadGraph {
LoadGraph();
vector colors;
vector data_block;
};
LoadGraph::LoadGraph() {}
$ aarch64-linux-gnu-g++ pr45470-b.cc -fnon-call-exceptions
-fvar-tracking-assignments-toggle -Ofast
pr45470-b.cc: In constructor ‘LoadGraph::LoadGraph()’:
pr45470-b.cc:13:25: error: in basic block 2:
13 | LoadGraph::LoadGraph() {}
| ^
pr45470-b.cc:13:25: error: flow control insn inside a basic block
(insn 7 6 8 2 (set (mem:V2x4QI (reg/f:DI 103 [ this ]) [0 +0 S8 A32])
(unspec:V2x4QI [
(const_int 0 [0]) repeated x2
] UNSPEC_STP)) "pr45470-b.cc":5:27 90 {*store_pair_4}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
during RTL pass: ldp_fusion
pr45470-b.cc:13:25: internal compiler error: in rtl_verify_bb_insns, at
cfgrtl.cc:2802
0x1b09b2e _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x148d06f rtl_verify_bb_insns
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2802
0x148d337 rtl_verify_flow_info_1
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:2889
0x148da96 rtl_verify_flow_info
/home/mjires/git/GCC/master/gcc/cfgrtl.cc:3134
0x147202e verify_flow_info()
/home/mjires/git/GCC/master/gcc/cfghooks.cc:283
0x1a37384 execute_function_todo
/home/mjires/git/GCC/master/gcc/passes.cc:2100
0x1a35faa do_per_function
/home/mjires/git/GCC/master/gcc/passes.cc:1687
0x1a37509 execute_todo
/home/mjires/git/GCC/master/gcc/passes.cc:2142
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.
$ aarch64-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-g++
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240103 (experimental) (GCC)
[Bug testsuite/113175] [11/12/13/14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 --- Comment #11 from GCC Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:af767e0b9e926fa1ef217087ce3b076be361965f commit r13-8189-gaf767e0b9e926fa1ef217087ce3b076be361965f Author: Patrick Palka Date: Tue Jan 2 21:31:20 2024 -0500 libstdc++: testsuite: Reduce max_size_type.cc exec time [PR113175] The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2 inadvertently increased the execution time of this test by over 5x due to making the two main loops actually run in the signed_p case instead of being dead code. To compensate, this patch cuts the relevant loops' range [-1000,1000] by 10x as proposed in the PR. This shouldn't significantly weaken the test since the same important edge cases are still checked in the smaller range and/or elsewhere. On my machine this reduces the test's execution time by roughly 10x (and 1.6x relative to before r14-205). PR testsuite/113175 libstdc++-v3/ChangeLog: * testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce 'limit' to 100 from 1000 and adjust 'log2_limit' accordingly. (test03): Likewise. (cherry picked from commit a138b99646a5551c53b860648521adb5bfe8c2fa)
[Bug tree-optimization/90693] Missing popcount simplifications
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90693 --- Comment #9 from Jakub Jelinek --- Created attachment 56984 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56984&action=edit gcc14-pr90693.patch Untested patch to do that.
[Bug testsuite/113175] [11/12/13/14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 --- Comment #12 from GCC Commits --- The releases/gcc-12 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1fb2b5c9a7fb212a5936cc702e49175ef988e5ad commit r12-10079-g1fb2b5c9a7fb212a5936cc702e49175ef988e5ad Author: Patrick Palka Date: Tue Jan 2 21:31:20 2024 -0500 libstdc++: testsuite: Reduce max_size_type.cc exec time [PR113175] The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2 inadvertently increased the execution time of this test by over 5x due to making the two main loops actually run in the signed_p case instead of being dead code. To compensate, this patch cuts the relevant loops' range [-1000,1000] by 10x as proposed in the PR. This shouldn't significantly weaken the test since the same important edge cases are still checked in the smaller range and/or elsewhere. On my machine this reduces the test's execution time by roughly 10x (and 1.6x relative to before r14-205). PR testsuite/113175 libstdc++-v3/ChangeLog: * testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce 'limit' to 100 from 1000 and adjust 'log2_limit' accordingly. (test03): Likewise. (cherry picked from commit a138b99646a5551c53b860648521adb5bfe8c2fa)
[Bug target/82420] ICE with -malign-int and -m68000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82420 --- Comment #4 from Mikael Pettersson --- Created attachment 56985 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56985&action=edit proposed fix
[Bug testsuite/113175] [11/12/13/14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 --- Comment #13 from GCC Commits --- The releases/gcc-11 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:2110667d43486174dda37a95f73d71941b394655 commit r11-11179-g2110667d43486174dda37a95f73d71941b394655 Author: Patrick Palka Date: Tue Jan 2 21:31:20 2024 -0500 libstdc++: testsuite: Reduce max_size_type.cc exec time [PR113175] The adjustment to max_size_type.cc in r14-205-g83470a5cd4c3d2 inadvertently increased the execution time of this test by over 5x due to making the two main loops actually run in the signed_p case instead of being dead code. To compensate, this patch cuts the relevant loops' range [-1000,1000] by 10x as proposed in the PR. This shouldn't significantly weaken the test since the same important edge cases are still checked in the smaller range and/or elsewhere. On my machine this reduces the test's execution time by roughly 10x (and 1.6x relative to before r14-205). PR testsuite/113175 libstdc++-v3/ChangeLog: * testsuite/std/ranges/iota/max_size_type.cc (test02): Reduce 'limit' to 100 from 1000 and adjust 'log2_limit' accordingly. (test03): Likewise. (cherry picked from commit a138b99646a5551c53b860648521adb5bfe8c2fa)
[Bug testsuite/113175] [11/12/13/14 Regression] testsuite/std/ranges/iota/max_size_type.cc 5x times slower
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113175 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Patrick Palka --- Fixed.
[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279 Mikael Pettersson changed: What|Removed |Added CC||mikpelinux at gmail dot com --- Comment #4 from Mikael Pettersson --- (In reply to Thorsten Otto from comment #3) > Created attachment 55837 [details] > Avoid segmentation fault when calling assign_temp with a NULL type pointer > > Attached is a potential patch to fix that. > > The above mentioned commit was made for gcc 4.3, and all compiler versions > after that are affected by it. This patch also fixes PR82420. That PR contains a tidied up patch with a test case and proper attribution to your original. Will you submit your patch or should I submit mine?
[Bug ipa/113203] __attribute__ ((always_inline)) fails with C99/LTO/-Og.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113203
--- Comment #4 from Stefan Krah ---
> Or, if the intention is that all calls to the function within its TU
> are inlined and not the other ones, split the function into two, one
> always_inline which is used from within the TU and another one which
> just calls it and is used from other TUs.
Yes, that's the intention. The real project has more than 100 functions in
mpdecimal.c. I'm using C99 inline to both automatically inline functions
specifically in that TU but generate regular functions for the other TUs
and libmpdec.so.
C99 saves the work of creating the wrappers manually.
Do note that this issue started with gcc-12, same as in:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
So it's a behavior change. I agree that the combination of "-flto -Og" is not
particularly important. But is it guaranteed that the above C99 scheme will
always work with -O{1,2,3}? Or are there other loopholes that might show up
in the future?
I guess that in order to be safe I'll remove always_inline and use your wrapper
suggestion some time in the future.
[Bug driver/113218] New: gcc -pg fails on contemporary FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113218 Bug ID: 113218 Summary: gcc -pg fails on contemporary FreeBSD Product: gcc Version: 12.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: emaste at freebsd dot org Target Milestone: --- FreeBSD retired _p profiled libraries in FreeBSD 14.0, so GCC specs need to be updated. Demonstrated below using the default FreeBSD devel/gcc port, but looking at gcc git I don't see any change. FreeBSD version: root@14:~ # uname -a FreeBSD 14 14.0-RELEASE FreeBSD 14.0-RELEASE #0 releng/14.0-n265380-f9716eee8ab4: Fri Nov 10 05:57:23 UTC 2023 r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 GCC: root@14:~ # gcc --version gcc (FreeBSD Ports Collection) 12.2.0 Copyright (C) 2022 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Failure: root@14:~ # gcc -pg hello.c /usr/local/bin/ld: cannot find -lc_p: No such file or directory Invocation, from gcc -v: collect2: error: ld returned 1 exit status /usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/collect2 -plugin /usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/liblto_plugin.so -plugin-opt=/usr/local/libexec/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/lto-wrapper -plugin-opt=-fresolution=/tmp//ccGg5YU1.res -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc_p -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s --eh-frame-hdr -m elf_x86_64_fbsd -V -dynamic-linker /libexec/ld-elf.so.1 /usr/lib/gcrt1.o /usr/lib/crti.o /usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/crtbegin.o -L/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0 -L/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/../../../../../x86_64-portbld-freebsd14.0/lib -L/usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/../../.. /tmp//cckdrIDm.o -lgcc --push-state --as-needed -lgcc_s --pop-state -lc_p -lgcc --push-state --as-needed -lgcc_s --pop-state /usr/local/lib/gcc12/gcc/x86_64-portbld-freebsd14.0/12.2.0/crtend.o /usr/lib/crtn.o
[Bug c++/113219] New: Overloaded ref-qualified conversion operator triggers bogus -Wconversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113219
Bug ID: 113219
Summary: Overloaded ref-qualified conversion operator triggers
bogus -Wconversion
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: m.cencora at gmail dot com
Target Milestone: ---
Following code when compiled on any gcc version (checked all available on
godbolt since gcc-7) triggers conversion warnings.
I consider it bogus because it tells user that it has chosen a better overload
(which is good thing, right?).
Clang doesn't print any related warning even with -Weverything
g++ -std=c++17 -Wconversion
template
struct wrapper
{
operator T() const&;
operator T&&() &&;
};
wrapper createInt();
int test()
{
return createInt();
}
Output is:
:13:21: warning: choosing 'wrapper::operator T&&() && [with T =
int]' over 'wrapper::operator T() const & [with T = int]' [-Wconversion]
13 | return createInt();
|~^~
:13:21: warning: for conversion from 'wrapper' to 'int'
[-Wconversion]
:13:21: note: because conversion sequence for the argument is better
[Bug target/113220] New: [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220
Bug ID: 113220
Summary: [aarch64] ICE Segmentation fault with
r14-6178-g8d29b7aca15133
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at suse dot cz
CC: richard.sandiford at arm dot com
Target Milestone: ---
Target: aarch64
Compiling reduced testcase gcc.target/aarch64/sme/zt0_state_5.c results in ICE
with r14-6178-g8d29b7aca15133.
$ cat zt0_state_5.c
#pragma GCC target "+sme2"
void inout_zt0() __arm_inout("zt0") {
int ptr;
ptr += 1;
}
$ aarch64-linux-gnu-gcc zt0_state_5.c -ftrapv -fstack-clash-protection
during RTL pass: mode_sw
zt0_state_5.c: In function ‘inout_zt0’:
zt0_state_5.c:5:1: internal compiler error: Segmentation fault
5 | }
| ^
0x1787d3a crash_signal
/home/mjires/git/GCC/master/gcc/toplev.cc:316
0x16f07c8 rtx_properties::try_to_add_pattern(rtx_def const*)
/home/mjires/git/GCC/master/gcc/rtlanal.cc:2246
0x16f0d4b rtx_properties::try_to_add_insn(rtx_insn const*, bool)
/home/mjires/git/GCC/master/gcc/rtlanal.cc:2356
0x1c83f7b growing_rtx_properties::add_insn(rtx_insn
const*, bool)::{lambda()#1}::operator()() const
/home/mjires/git/GCC/master/gcc/rtlanal.h:288
0x1c866a2 void
growing_rtx_properties::repeat::add_insn(rtx_insn
const*,
bool)::{lambda()#1}>(growing_rtx_properties::add_insn(rtx_insn
const*, bool)::{lambda()#1})
/home/mjires/git/GCC/master/gcc/rtlanal.h:246
0x1c83fda growing_rtx_properties::add_insn(rtx_insn
const*, bool)
/home/mjires/git/GCC/master/gcc/rtlanal.h:288
0x1c79afe aarch64_mode_emit
/home/mjires/git/GCC/master/gcc/config/aarch64/aarch64.cc:29400
0x2b318d1 optimize_mode_switching
/home/mjires/git/GCC/master/gcc/mode-switching.cc:1210
0x2b31b7a execute
/home/mjires/git/GCC/master/gcc/mode-switching.cc:1309
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.
$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240103 (experimental) (GCC)
[Bug target/113220] [aarch64] ICE Segmentation fault with r14-6178-g8d29b7aca15133
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113220 Richard Sandiford changed: What|Removed |Added CC|richard.sandiford at arm dot com |rsandifo at gcc dot gnu.org Last reconfirmed||2024-01-03 Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Richard Sandiford --- Mine
[Bug target/113217] [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113217 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 CC||pinskia at gcc dot gnu.org
[Bug target/113217] [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113217 Alex Coplan changed: What|Removed |Added Last reconfirmed||2024-01-03 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |acoplan at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Alex Coplan --- Confirmed, mine (but I'm looking at PR113070 first).
[Bug target/113217] [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113217
--- Comment #2 from Andrew Pinski ---
From:
```
(insn 7 2 8 2 (set (mem:SI (reg/f:DI 103 [ this ]) [1 MEM[(struct vector
*)this_4(D)].D.4476._M_end_of_storage+0 S4 A32])
(const_int 0 [0])) "/app/example.cpp":6:27 69 {*movsi_aarch64}
(nil))
(debug_insn 8 7 11 2 (debug_marker:BLK) "/app/example.cpp":6:3 -1
(nil))
(insn 11 8 42 2 (set (mem:SI (plus:DI (reg/f:DI 103 [ this ])
(const_int 4 [0x4])) [1 MEM[(struct vector *)this_4(D) +
4B].D.4476._M_end_of_storage+0 S4 A32])
(const_int 0 [0])) "/app/example.cpp":6:27 69 {*movsi_aarch64}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
```
To:
```
(insn 7 2 8 2 (set (mem:V2x4QI (reg/f:DI 103 [ this ]) [0 +0 S8 A32])
(unspec:V2x4QI [
(const_int 0 [0]) repeated x2
] UNSPEC_STP)) "/app/example.cpp":6:27 90 {*store_pair_4}
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil)))
(debug_insn 8 7 42 2 (debug_marker:BLK) "/app/example.cpp":6:3 -1
(nil))
(note 42 8 44 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
```
Most likely we should only handle stores instructions which cannot throw,
insn_nothrow_p .
[Bug target/113217] [14 Regression][aarch64] ICE in rtl_verify_bb_insns, at cfgrtl.cc:2796 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113217 --- Comment #3 from Andrew Pinski --- (In reply to Andrew Pinski from comment #2) > Most likely we should only handle stores instructions which cannot throw, > insn_nothrow_p . s/stores/stores and loads/ really.
[Bug middle-end/109849] suboptimal code for vector walking loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109849
--- Comment #34 from Martin Jambor ---
(In reply to Jan Hubicka from comment #32)
> > /tmp/build/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/stl_algobase.h:437:
> > warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
> > writing between 2 and 9223372036854775806 bytes into a region of size 0
> > overflows the destination [-Wstringop-overflow=]
>
> It warns on:
>
> template
> struct __copy_move<_IsMove, true, random_access_iterator_tag>
> {
> template
> _GLIBCXX20_CONSTEXPR
> static _Up*
> __copy_m(_Tp* __first, _Tp* __last, _Up* __result)
> {
> const ptrdiff_t _Num = __last - __first;
> if (__builtin_expect(_Num > 1, true))
> __builtin_memmove(__result, __first, sizeof(_Tp) * _Num);
> else if (_Num == 1)
> std::__copy_move<_IsMove, false, random_access_iterator_tag>::
> __assign_one(__result, __first);
> return __result + _Num;
> }
> };
>
> It is likely false positive on a code path that never happens in real
> code, but we now optimize it better.
>
We end up with:
[local count: 64736968]:
__builtin_memcpy (1B, v$_M_impl$D10203$_M_start_448, _354);
IIRC the statement variant is created by jump threading (specifically
thread2).
Moreover, if I understand the comment in compute_objsize_r about the
INTEGER_CST case correctly, small integers are considered potential
"result of erroneous null pointer addition/subtraction." So not
warning on a constant 1 destination does not seem to be desirable.
[Bug tree-optimization/113201] [14 Regression] internal compiler error: tree check: expected ssa_name, have integer_cst in replace_uses_by, at tree-cfg.cc:2058
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113201 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek --- Created attachment 56986 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56986&action=edit gcc14-pr113201.patch So, do we want just avoid trying to propagate constants to rslt uses if it is used in abnormal PHI like in this patch, or punt on doing final value replacement in that case altogether?
[Bug target/113221] New: [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113221
Bug ID: 113221
Summary: [14 Regression][aarch64]ICE in extract_insn, at
recog.cc:2812 since r14-6605-gc0911c6b357ba9
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mjires at suse dot cz
CC: acoplan at gcc dot gnu.org
Target Milestone: ---
Target: aarch64
Compiling reduced testcase gcc.dg/debug/pr43972.c results in ICE since
r14-6605-gc0911c6b357ba9.
$ cat pr43972.c
void bar();
void foo(int* b) {
for (;;)
*b++ = (long)bar;
}
$ aarch64-linux-gnu-gcc pr43972.c -O1 -fno-move-loop-invariants
-funroll-all-loops
pr43972.c: In function ‘foo’:
pr43972.c:5:1: error: unrecognizable insn:
5 | }
| ^
(insn 80 0 0 (set (reg:SI 130)
(subreg:SI (lo_sum:DI (reg/f:DI 105)
(symbol_ref:DI ("bar") [flags 0x41] )) 0)) -1
(nil))
during RTL pass: reload
pr43972.c:5:1: internal compiler error: in extract_insn, at recog.cc:2812
0x16e9be0 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:108
0x16e9c21 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/mjires/git/GCC/master/gcc/rtl-error.cc:116
0x169a764 extract_insn(rtx_insn*)
/home/mjires/git/GCC/master/gcc/recog.cc:2812
0x147d140 ira_remove_insn_scratches(rtx_insn*, bool, _IO_FILE*, rtx_def*
(*)(rtx_def*))
/home/mjires/git/GCC/master/gcc/ira.cc:5381
0x14d574a remove_insn_scratches
/home/mjires/git/GCC/master/gcc/lra.cc:2154
0x14d112b lra_emit_move(rtx_def*, rtx_def*)
/home/mjires/git/GCC/master/gcc/lra.cc:513
0x14eb151 curr_insn_transform
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:4669
0x14ed78c lra_constraints(bool)
/home/mjires/git/GCC/master/gcc/lra-constraints.cc:5414
0x14d6064 lra(_IO_FILE*, int)
/home/mjires/git/GCC/master/gcc/lra.cc:2442
0x147e4d3 do_reload
/home/mjires/git/GCC/master/gcc/ira.cc:5973
0x147e970 execute
/home/mjires/git/GCC/master/gcc/ira.cc:6161
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.
$ aarch64-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/home/mjires/built/master/libexec/gcc/aarch64-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-linux-gnu
Configured with: /home/mjires/git/GCC/master/configure
--prefix=/home/mjires/built/master --target=aarch64-linux-gnu
--disable-bootstrap --enable-languages=c,c++,fortran --disable-multilib
--disable-libsanitizer --enable-checking : (reconfigured)
/home/mjires/git/GCC/master/configure --prefix=/home/mjires/built/master
--target=aarch64-linux-gnu --disable-bootstrap --enable-languages=c,c++,fortran
--disable-multilib --disable-libsanitizer --enable-checking
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20240103 (experimental) (GCC)
[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113221 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0 CC||pinskia at gcc dot gnu.org
[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113221
--- Comment #1 from Andrew Pinski ---
Confirmed, but the IR from the ldp_fusion pass looks ok:
```
(insn 30 29 15 3 (set (reg/f:DI 110)
(lo_sum:DI (reg/f:DI 109)
(symbol_ref:DI ("_Z3barv") [flags 0x41] ))) "/app/example.cpp":5:10 discrim 1 -1
(expr_list:REG_DEAD (reg/f:DI 109)
(expr_list:REG_EQUAL (symbol_ref:DI ("_Z3barv") [flags 0x41]
)
(nil
(insn 15 30 32 3 (parallel [
(set (reg:DI 106)
(plus:DI (reg:DI 106)
(const_int 4 [0x4])))
(set (mem:SI (reg:DI 106) [0 S4 A8])
(subreg:SI (reg/f:DI 104) 0))
(set (mem:SI (plus:DI (reg:DI 106)
(const_int 4 [0x4])) [0 S4 A8])
(subreg:SI (reg/f:DI 110) 0))
]) "/app/example.cpp":5:10 discrim 1 102 {*storewb_post_pair_4}
(nil))
```
[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113221 Andrew Pinski changed: What|Removed |Added Last reconfirmed||2024-01-03 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW
[Bug target/113221] [14 Regression][aarch64]ICE in extract_insn, at recog.cc:2812 since r14-6605-gc0911c6b357ba9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113221
--- Comment #2 from Andrew Pinski ---
IRA decided to combine:
```
(insn 9 8 19 3 (set (reg/f:DI 104)
(lo_sum:DI (reg/f:DI 105)
(symbol_ref:DI ("bar") [flags 0x41] ))) "t.c":5:10 discrim 1 -1
(expr_list:REG_DEAD (reg/f:DI 105)
(expr_list:REG_EQUAL (symbol_ref:DI ("bar") [flags 0x41]
)
(nil
...
(insn 21 20 11 3 (set (reg/f:DI 110)
(lo_sum:DI (reg/f:DI 109)
(symbol_ref:DI ("bar") [flags 0x41] ))) "t.c":5:10 discrim 1 -1
(expr_list:REG_DEAD (reg/f:DI 109)
(expr_list:REG_EQUAL (symbol_ref:DI ("bar") [flags 0x41]
)
(nil
(insn 11 21 27 3 (parallel [
(set (reg:DI 106)
(plus:DI (reg:DI 106)
(const_int 4 [0x4])))
(set (mem:SI (reg:DI 106) [0 S4 A8])
(subreg:SI (reg/f:DI 104) 0))
(set (mem:SI (plus:DI (reg:DI 106)
(const_int 4 [0x4])) [0 S4 A8])
(subreg:SI (reg/f:DI 110) 0))
]) "t.c":5:10 discrim 1 102 {*storewb_post_pair_4}
(nil))
```
to:
```
(insn 11 20 27 3 (parallel [
(set (reg:DI 106)
(plus:DI (reg:DI 106)
(const_int 4 [0x4])))
(set (mem:SI (reg:DI 106) [0 S4 A8])
(subreg:SI (lo_sum:DI (reg/f:DI 105)
(symbol_ref:DI ("bar") [flags 0x41] )) 0))
(set (mem:SI (plus:DI (reg:DI 106)
(const_int 4 [0x4])) [0 S4 A8])
(subreg:SI (lo_sum:DI (reg/f:DI 109)
(symbol_ref:DI ("bar") [flags 0x41] )) 0))
]) "t.c":5:10 discrim 1 102 {*storewb_post_pair_4}
(expr_list:REG_DEAD (reg/f:DI 109)
(expr_list:REG_DEAD (reg/f:DI 105)
(nil
```
But I have no idea why though ...
[Bug analyzer/113222] New: ICE with -fanalyzer seen on Linux kernel kernel/sched/core.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113222
Bug ID: 113222
Summary: ICE with -fanalyzer seen on Linux kernel
kernel/sched/core.c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: dmalcolm at gcc dot gnu.org
Blocks: 106358
Target Milestone: ---
Given:
struct sched_class
{
int f;
};
extern struct sched_class __end_sched_classes[];
int
test ()
{
const struct sched_class* class = ((__end_sched_classes - 1));
return class->f;
}
trunk with -fanalyzer ICEs with:
/tmp/t.c: In function ‘test’:
/tmp/t.c:11:15: warning: buffer under-read [CWE-127] [-Wanalyzer-out-of-bounds]
11 | return class->f;
| ~^~~
‘test’: event 1
|
| 11 | return class->f;
| | ~^~~
| | |
| | (1) out-of-bounds read from byte -4 till byte -1 but
‘__end_sched_classes’ starts at byte 0
|
during IPA pass: analyzer
/tmp/t.c:11:15: internal compiler error: Segmentation fault
11 | return class->f;
| ~^~~
0x10708aa crash_signal
../../src/gcc/toplev.cc:316
0x2299a65 tree_check6(tree_node*, char const*, int, char const*, tree_code,
tree_code, tree_code, tree_code, tree_code, tree_code)
../../src/gcc/tree.h:3726
0x2299a65 ana::valid_region_spatial_item::add_boundaries(ana::boundaries&,
ana::logger*) const
../../src/gcc/analyzer/access-diagram.cc:1337
0x229e2e0 ana::access_diagram_impl::find_boundaries() const
../../src/gcc/analyzer/access-diagram.cc:2197
0x229e2e0 ana::access_diagram_impl::access_diagram_impl(ana::access_operation
const&, diagnostic_event_id_t, text_art::style_manager&, text_art::theme
const&, ana::logger*)
../../src/gcc/analyzer/access-diagram.cc:2064
0x229283b std::enable_if::value,
std::unique_ptr > >::type
make_unique(ana::access_operation const&, diagnostic_event_id_t&,
text_art::style_manager&, text_art::theme const&, ana::logger*&)
../../src/gcc/make-unique.h:41
0x229283b ana::access_diagram::access_diagram(ana::access_operation const&,
diagnostic_event_id_t, text_art::style_manager&, text_art::theme const&,
ana::logger*)
../../src/gcc/analyzer/access-diagram.cc:2666
0x212b331 ana::out_of_bounds::make_access_diagram(ana::access_operation const&,
text_art::style_manager&, text_art::theme const&, ana::logger*) const
../../src/gcc/analyzer/bounds-checking.cc:208
0x212b331 ana::out_of_bounds::maybe_show_diagram(ana::logger*) const
../../src/gcc/analyzer/bounds-checking.cc:187
0x212b803
ana::concrete_buffer_under_read::emit(ana::diagnostic_emission_context&)
../../src/gcc/analyzer/bounds-checking.cc:806
0x214ff37 ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic&)
../../src/gcc/analyzer/diagnostic-manager.cc:1617
0x2153ba6 ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
../../src/gcc/analyzer/diagnostic-manager.cc:1472
0x215053f ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
../../src/gcc/analyzer/diagnostic-manager.cc:1524
0x1479be4 ana::impl_run_checkers(ana::logger*)
../../src/gcc/analyzer/engine.cc:6226
0x147ab56 ana::run_checkers()
../../src/gcc/analyzer/engine.cc:6300
0x146be6c execute
../../src/gcc/analyzer/analyzer-pass.cc:87
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug tree-optimization/19347] Invariant load not moved out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347
Phosit changed:
What|Removed |Added
CC||phosit at autistici dot org
--- Comment #9 from Phosit ---
When there are few iterations (likely when it is unroled) there is no
alias-check:
void fill(int* data, int& value)
{
for(unsigned long i{0}; i != 4; ++i)
data[i] = value;
}
--- at -O2 results in:
fill(int*, int&):
movdxmm1, DWORD PTR [rsi]
pshufd xmm0, xmm1, 0xe0
movqQWORD PTR [rdi], xmm0
movdxmm0, DWORD PTR [rsi]
pshufd xmm0, xmm0, 0xe0
movqQWORD PTR [rdi+8], xmm0
ret
---
At -O3 the loop isn't removed and (thus) there is an alias-check.
[Bug tree-optimization/19347] Invariant load not moved out of loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19347 --- Comment #10 from Phosit --- The analysis in my previous comment is wrong. I don't know why there is no alias-check at -O2. Also the loop _is_ removed at -O3.
[Bug libfortran/113223] New: NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223
Bug ID: 113223
Summary: NAMELIST internal write missing leading blank
character
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: kargl at gcc dot gnu.org
Target Milestone: ---
Found at https://github.com/llvm/llvm-project/issues/76798
Program test_namelist_blank
Integer :: i,j
Character(300) ::s
Namelist /nml1/i,j
i = 99
j = 42
Write (s,NML=nml1)
Write (*,'("Internal ",A)') Merge('ok ','bug',s(1:1)==' ')
Write (*,NML=nml1)
End Program test_namelist_blank
F2018
13.11.4.3 Namelist output records
...
Except for new records created by explicit formatting within a defined
output procedure or by continuation of delimited character sequences,
each output record begins with a blank character.
Patch
diff --git a/libgfortran/io/write.c b/libgfortran/io/write.c
index f94e180ba33..a7cf5d9b233 100644
--- a/libgfortran/io/write.c
+++ b/libgfortran/io/write.c
@@ -2466,6 +2466,8 @@ namelist_write (st_parameter_dt *dtp)
dtp->u.p.nml_delim = '\0';
}
+ if (is_internal_unit (dtp))
+write_character (dtp, " ", 1, 1, NODELIM);
write_character (dtp, "&", 1, 1, NODELIM);
/* Write namelist name in upper case - f95 std. */
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 kargl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug analyzer/113222] ICE with -fanalyzer seen on Linux kernel kernel/sched/core.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113222 David Malcolm changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-03 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from David Malcolm --- I'm testing a fix
[Bug tree-optimization/113224] New: Warning "is used uninitialized" raised for an initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113224
Bug ID: 113224
Summary: Warning "is used uninitialized" raised for an
initialized variable
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gandalf at winds dot org
Target Milestone: ---
Target: x86_64-pc-linux-gnu
In an attempt to convert a float value bytewise to an integer, this function
returns the following unexpected GCC warnings at optimization level -O2 and -O3
on x86_64:
unsigned int myfunc() {
float _f=2.5;
unsigned int *_x=(unsigned int *)&_f;
return *_x;
}
gcc -O2 -Wall test12.c -c
test12.c: In function 'myfunc':
test12.c:4:10: warning: '_f' is used uninitialized
test12.c:2:9: note: '_f' declared here
It compiles correctly, at least. The warning goes away when
-fno-strict-aliasing is applied.
[Bug tree-optimization/113224] Warning "is used uninitialized" raised for an initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113224 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- This code is undefined for violating C/C++ aliasing rules. The warning is because of the undefinedness of the code.
[Bug tree-optimization/113224] Warning "is used uninitialized" raised for an initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113224 --- Comment #2 from Andrew Pinski --- >In an attempt to convert a float value bytewise to an integer, You should use memcpy instead (or an union which itself a GCC extension).
[Bug tree-optimization/113224] Warning "is used uninitialized" raised for an initialized variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113224 --- Comment #3 from gandalf at winds dot org --- Thank you for the suggestion. I'll try the union.
[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064 --- Comment #7 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:1c522c9eafa5b86b78cd7b3044e120762fb4c879 commit r14-6899-g1c522c9eafa5b86b78cd7b3044e120762fb4c879 Author: Patrick Palka Date: Wed Jan 3 15:43:28 2024 -0500 c++: bad direct reference binding via conv fn [PR113064] When computing a direct reference binding via a conversion function yields a bad conversion, reference_binding incorrectly commits to that conversion instead of trying a conversion via a temporary. This causes us to reject the first testcase because the bad direct conversion to B&& via the && conversion operator prevents us from considering the good conversion via the & conversion operator and a temporary. (Similar story for the second testcase.) This patch fixes this by making reference_binding not prematurely commit to such a bad direct conversion. We still fall back to it if using a temporary also fails (otherwise the diagnostic for cpp0x/explicit7.C regresses). PR c++/113064 gcc/cp/ChangeLog: * call.cc (reference_binding): Still try a conversion via a temporary if a direct conversion was bad. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/rv-conv4.C: New test. * g++.dg/cpp0x/rv-conv5.C: New test.
[Bug target/113225] New: bpf: attributekernel_helper function declarations create a BTF_FUNC_EXTERN.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113225
Bug ID: 113225
Summary: bpf: attributekernel_helper function declarations
create a BTF_FUNC_EXTERN.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: cupertino.miranda at oracle dot com
Target Milestone: ---
When using attribute kernel_helper such as the one in the example:
extern int foo (int arg) __attribute__((kernel_helper (666)));
int bar ()
{
return foo (20);
}
The following BTF entries are created:
[1] int 'int'(1U#B) size=4U#B offset=0UB#b bits=32UB#b SIGNED
[2] func_proto type=1
param '' type=1
[3] func_proto type=1
[4] func 'foo'(5U#B) type=2 linkage=0 (extern)
[5] func 'bar'(9U#B) type=3 linkage=1 (global)
BTF information is generated for the extern function declaration, imposing some
problem to tools such as bpftool that relies on BTF information to validate
completeness of the BTF information.
Since kernel helpers are not true functions the BTF information created,
although accurate with how the function is declared, it is not accurate with
its semantics.
Plan resolution is to skip btf output to any attributed kernel_helper function
declaration, since the BTF information in this case is not really required.
[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389 Sergey Fedorov changed: What|Removed |Added CC||vital.had at gmail dot com --- Comment #6 from Sergey Fedorov --- Has this ever been addressed? I am getting a similar-looking error with gcc-13.2.0 now: https://github.com/NGSolve/ngsolve/issues/68
[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389 --- Comment #7 from Andrew Pinski --- (In reply to Sergey Fedorov from comment #6) > I am getting a similar-looking error with gcc-13.2.0 now: > https://github.com/NGSolve/ngsolve/issues/68 Both clang and GCC reject the original testcase still So I doubt this is the same issue ...
[Bug c++/59389] [C++11] bogus error: call of overloaded ‘Foo()’ is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59389 --- Comment #8 from Andrew Pinski --- (In reply to Andrew Pinski from comment #7) > (In reply to Sergey Fedorov from comment #6) > > I am getting a similar-looking error with gcc-13.2.0 now: > > https://github.com/NGSolve/ngsolve/issues/68 > > Both clang and GCC reject the original testcase still > So I doubt this is the same issue ... Also the testcase in comment #2 works with GCC 13.2.0 while fails with GCC 13.1.0 ...
[Bug target/113218] gcc -pg fails on contemporary FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113218
--- Comment #1 from Andrew Pinski ---
Basically FBSD_LIB_SPEC in gcc/config/freebsd-spec.h should be modified to
`%{pg:` related parts. But only do that for FBSD_MAJOR >= 14 ...
[Bug target/113218] gcc -pg fails on contemporary FreeBSD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113218 Andrew Pinski changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-01-03 Status|UNCONFIRMED |NEW --- Comment #2 from Andrew Pinski --- .
[Bug target/113115] [14 Regression] ICE In extract_constrain_insn_cached recog.cc with ppc64le-linux-gnu crosscompiler from r14-3592-g9ea1248604d7b6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113115 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug sanitizer/113214] false-positive -Wstringop-overflow warning with thread sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113214 Andrew Pinski changed: What|Removed |Added Keywords||diagnostic Blocks||88443 --- Comment #1 from Andrew Pinski --- Note the GCC manual does say: ``` Note that sanitizers tend to increase the rate of false positive warnings, most notably those around -Wmaybe-uninitialized. We recommend against combining -Werror and [the use of] sanitizers. ``` So I suspect this should be closed as won't fix ... Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443 [Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 kargl at gcc dot gnu.org changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org --- Jerry can you take a look at this issue.
[Bug c++/113219] Overloaded ref-qualified conversion operator triggers bogus -Wconversion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113219 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Andrew Pinski --- This is documented this way too: https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gcc/Warning-Options.html#index-Wconversion ``` For C++, also warn for confusing overload resolution for user-defined conversions; and conversions that never use a type conversion operator: conversions to void, the same type, a base class or a reference to them. Warnings about conversions between signed and unsigned integers are disabled by default in C++ unless -Wsign-conversion is explicitly enabled. ``` Don't use -Wconversion if you don't wan this warning ... Note this warning was originally not part of -Wconversion but always on (in GCC 2.95.3) and then in GCC 3.4.0 was moved to part of -Wconversion; this was PR 10784 was about even.
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 --- Comment #2 from Jerry DeLisle --- (In reply to kargl from comment #1) > Jerry can you take a look at this issue. Will do. Minor tweak I hope.
[Bug target/111279] ICE: Segmentation fault with m68k,SJLJ and -malign-int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111279 --- Comment #5 from Thorsten Otto --- I don't mind. If your patch also contains a test case, just use that.
[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #8 from Patrick Palka ---
(In reply to m.cencora from comment #4)
> This also might be a just another symptom of the same root cause:
>
> struct bar
> {
> bar() = default;
>
> bar(const bar&);
> bar(bar&&);
>
> bar& operator=(const bar&);
> bar& operator=(bar&&);
> };
>
> struct foo
> {
> operator const bar& () const &;
>
> operator bar& () &;
>
> operator bar&&() &&;
> };
>
> void test()
> {
> bar a = foo{}; // ok
It seems this copy-init is valid according to
http://eel.is/c++draft/dcl.init#general-16.6.3 -- we first choose the best
conversion function according to the destination type bar (and independent of
bar's constructors) which in this case is operator bar&&() &&, and then perform
overload resolution of bar's constructors using the result of that conversion
function as the argument, which leads to bar(bar&&) unambiguously winning.
>
> a = foo{}; // not ok - ambiguous call, but why? &&-qualified looks like
> a better match
Whereas here, we perform the expected overload resolution of bar's constructor
set using the original argument, which gives two viable candidates
bar(const bar&) through operator const bar&() const&
bar(bar&&) through operator bar&&() &&
and user-defined conversion sequences that use different conversion functions
are incomparable, so the candidates are ambiguous.
>
> foo f;
> a = f; // ok
>
> a = static_cast(foo{}); // ok
> }
[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org Target Milestone|--- |14.0 Resolution|--- |FIXED --- Comment #9 from Patrick Palka --- The original testcase should be fixed for GCC 14 after r14-6899.
[Bug c++/113064] assignement from temporary sometimes invokes copy-assign instead of move-assign operator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113064 Patrick Palka changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=86521 --- Comment #10 from Patrick Palka --- N.B. the comment #4 testcase is similar to the one from PR86521, and I based the above analysis off of that PR..
[Bug target/113206] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206 --- Comment #4 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:4a0a8dc1b88408222b88e10278017189f6144602 commit r14-6902-g4a0a8dc1b88408222b88e10278017189f6144602 Author: Juzhe-Zhong Date: Thu Jan 4 06:38:43 2024 +0800 RISC-V: Fix bug of earliest fusion for infinite loop[VSETVL PASS] As PR113206 and PR113209, the bugs happens on the following situation: li a4,32 ... vsetvli zero,a4,e8,m8,ta,ma ... slliw a4,a3,24 sraiw a4,a4,24 bge a3,a1,.L8 sb a4,%lo(e)(a0) vsetvli zero,a4,e8,m8,ta,ma --> a4 is polluted value not the expected "32". ... .L7: j .L7 ---> infinite loop. The root cause is that infinite loop confuse earliest computation and let earliest fusion happens on unexpected place. Disable blocks that belong to infinite loop to fix this bug since applying ealiest LCM fusion on infinite loop seems quite complicated and we don't see any benefits. Note that disabling earliest fusion on infinite loops doesn't hurt the vsetvli performance, instead, it does improve codegen of some cases. Tested on both RV32 and RV64 no regression. PR target/113206 PR target/113209 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (invalid_opt_bb_p): New function. (pre_vsetvl::compute_lcm_local_properties): Disable earliest fusion on blocks belong to infinite loop. (pre_vsetvl::emit_vsetvl): Remove fake edges. * config/riscv/t-riscv: Add a new include file. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/avl_single-23.c: Adapt test. * gcc.target/riscv/rvv/vsetvl/vlmax_call-1.c: Robostify test. * gcc.target/riscv/rvv/vsetvl/vlmax_call-2.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_call-3.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_conflict-5.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-1.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-2.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-3.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-4.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-5.c: Ditto. * gcc.target/riscv/rvv/autovec/pr113206-1.c: New test. * gcc.target/riscv/rvv/autovec/pr113206-2.c: New test. * gcc.target/riscv/rvv/autovec/pr113209.c: New test.
[Bug target/113209] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113209 --- Comment #1 from GCC Commits --- The master branch has been updated by Pan Li : https://gcc.gnu.org/g:4a0a8dc1b88408222b88e10278017189f6144602 commit r14-6902-g4a0a8dc1b88408222b88e10278017189f6144602 Author: Juzhe-Zhong Date: Thu Jan 4 06:38:43 2024 +0800 RISC-V: Fix bug of earliest fusion for infinite loop[VSETVL PASS] As PR113206 and PR113209, the bugs happens on the following situation: li a4,32 ... vsetvli zero,a4,e8,m8,ta,ma ... slliw a4,a3,24 sraiw a4,a4,24 bge a3,a1,.L8 sb a4,%lo(e)(a0) vsetvli zero,a4,e8,m8,ta,ma --> a4 is polluted value not the expected "32". ... .L7: j .L7 ---> infinite loop. The root cause is that infinite loop confuse earliest computation and let earliest fusion happens on unexpected place. Disable blocks that belong to infinite loop to fix this bug since applying ealiest LCM fusion on infinite loop seems quite complicated and we don't see any benefits. Note that disabling earliest fusion on infinite loops doesn't hurt the vsetvli performance, instead, it does improve codegen of some cases. Tested on both RV32 and RV64 no regression. PR target/113206 PR target/113209 gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (invalid_opt_bb_p): New function. (pre_vsetvl::compute_lcm_local_properties): Disable earliest fusion on blocks belong to infinite loop. (pre_vsetvl::emit_vsetvl): Remove fake edges. * config/riscv/t-riscv: Add a new include file. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/vsetvl/avl_single-23.c: Adapt test. * gcc.target/riscv/rvv/vsetvl/vlmax_call-1.c: Robostify test. * gcc.target/riscv/rvv/vsetvl/vlmax_call-2.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_call-3.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_conflict-5.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-1.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-2.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-3.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-4.c: Ditto. * gcc.target/riscv/rvv/vsetvl/vlmax_single_vtype-5.c: Ditto. * gcc.target/riscv/rvv/autovec/pr113206-1.c: New test. * gcc.target/riscv/rvv/autovec/pr113206-2.c: New test. * gcc.target/riscv/rvv/autovec/pr113209.c: New test.
[Bug rtl-optimization/112525] fail to eliminate unused store
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525 Jiu Fu Guo changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jiu Fu Guo --- Fix committed.
[Bug middle-end/101926] [meta-bug] struct/complex/other argument passing and return should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926 Bug 101926 depends on bug 112525, which changed state. Bug 112525 Summary: fail to eliminate unused store https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112525 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/113206] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206 --- Comment #5 from JuzheZhong --- Both PR113206 and PR113209 are the same root cause and I have fixed both of them. Could you try the latest upstream GCC test SPEC 527/549 again to see whether it fixes the bugs in SPEC?
[Bug testsuite/113226] New: [14 Regression] testsuite/std/ranges/iota/max_size_type.cc fails for cris-elf after r14-6888-ga138b99646a555
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113226
Bug ID: 113226
Summary: [14 Regression]
testsuite/std/ranges/iota/max_size_type.cc fails for
cris-elf after r14-6888-ga138b99646a555
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: testsuite
Assignee: unassigned at gcc dot gnu.org
Reporter: hp at gcc dot gnu.org
Target Milestone: ---
After r14-6888-ga138b99646a555, I see, for cris-elf (32-bit target, no 128bit):
FAIL: std/ranges/iota/max_size_type.cc -std=gnu++20 execution test
FAIL: std/ranges/iota/max_size_type.cc -std=gnu++26 execution test
And in the .log:
spawn cris-elf-run ./max_size_type.exe^
Inconsistency found: 1 0 -100 -100^
/x/gcc/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc:246: void
test02() [with bool signed_p = true; bool shorten_p = false]: Assertion '0'
failed.
program stopped with signal 6 (Aborted).
FAIL: std/ranges/iota/max_size_type.cc -std=gnu++20 execution test
Changing all s/ok &=/VERIFY/ (plus adding one level of parentheses to one of
the lines) show:
/x/gcc/libstdc++-v3/testsuite/std/ranges/iota/max_size_type.cc:217: void
test02() [with bool signed_p = true; bool shorten_p = false]: Assertion 'i*j ==
shorten_type(max_type(i)*j)' failed.
program stopped with signal 6 (Aborted).
Further instrumentation, adding among other lines:
```
if (signed_p && ! shorten_p)
std::cerr << "j == " << int64_t(j) << std::endl;
if (!(i*j == shorten_type(max_type(i)*j)))
{
std::cerr << "i == " << int64_t(i) << ", j == " << j << ", i*j ==
" << int64_t(i*j) << ", max_type(i) == \
" << int64_t(max_type(i));
std::cerr << ", max_type(i)*j == " << int64_t(max_type(i)*j) <<
std::endl;
}
'''
shows that this is (see above for template parameters):
i == 1, j == -100, i*j == 4294967196, max_type(i) == 1, max_type(i)*j == -100
and that large number is as you might guess, (unsigned) -100.
Not sure if this is a bug in the testcase or elsewhere, but I'll start my
guessing with testsuite.
[Bug target/30271] -mstrict-align can add an store extra for struct argument passing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271 Jiu Fu Guo changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #15 from Jiu Fu Guo --- Fix was committed.
[Bug middle-end/101926] [meta-bug] struct/complex/other argument passing and return should be improved
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101926 Bug 101926 depends on bug 30271, which changed state. Bug 30271 Summary: -mstrict-align can add an store extra for struct argument passing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug other/16996] [meta-bug] code size improvements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16996 Bug 16996 depends on bug 30271, which changed state. Bug 30271 Summary: -mstrict-align can add an store extra for struct argument passing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug middle-end/29215] [4.3 Regression] extra store for memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29215 Bug 29215 depends on bug 30271, which changed state. Bug 30271 Summary: -mstrict-align can add an store extra for struct argument passing https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30271 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug target/113206] [14] RISC-V rv64gcv vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113206 Patrick O'Neill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Patrick O'Neill --- Confirmed fixed, thanks for the quick fix! I've kicked off a spec run.
[Bug target/113209] [14] RISC-V rv64gcv_zvl256b vector: Runtime mismatch with rv64gc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113209 Patrick O'Neill changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Patrick O'Neill --- Confirmed resolved.
[Bug target/113010] [RISCV] sign-extension lost in comparison with constant embedded in comma-op expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113010 --- Comment #2 from Patrick O'Neill --- Andrew I don't think this is a duplicate of pr112758 (or at least it wasn't resolved by the fix for pr112758). I still see the behavior on r14-6902-g4a0a8dc1b88. > /scratch/tc-testing/tc-jan-3-trunk/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc > -O2 -march=rv64gc red.c -o user-config.out > > QEMU_CPU=rv64,zbs=true timeout --verbose -k 0.1 1 > /scratch/tc-testing/tc-jan-3-trunk/build-rv64gcv/bin/qemu-riscv64 > user-config.out > echo $? > 1
[Bug rtl-optimization/104914] [MIPS] wrong comparison with scrabbled int value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104914
--- Comment #24 from GCC Commits ---
The master branch has been updated by YunQiang Su :
https://gcc.gnu.org/g:65d4b32dee2508f5bcdd999a132332cd46cf8a4d
commit r14-6905-g65d4b32dee2508f5bcdd999a132332cd46cf8a4d
Author: YunQiang Su
Date: Sat Dec 30 00:17:52 2023 +0800
MIPS: Add pattern insqisi_extended and inshisi_extended
This match pattern allows combination (zero_extract:DI 8, 24, QI)
with an sign-extend to 32bit INS instruction on TARGET_64BIT.
For SI mode, if the sign-bit is modified by bitops, we will need a
sign-extend operation. Since 32bit INS instruction can be sure that
result is sign-extended, and the QImode src register is safe for INS, too.
(insn 19 18 20 2 (set (zero_extract:DI (reg/v:DI 200 [ val ])
(const_int 8 [0x8])
(const_int 24 [0x18]))
(subreg:DI (reg:QI 205) 0)) "../xx.c":7:29 -1
(nil))
(insn 20 19 23 2 (set (reg/v:DI 200 [ val ])
(sign_extend:DI (subreg:SI (reg/v:DI 200 [ val ]) 0)))
"../xx.c":7:29 -1
(nil))
Combine try to merge them to:
(insn 20 19 23 2 (set (reg/v:DI 200 [ val ])
(sign_extend:DI (ior:SI (and:SI (subreg:SI (reg/v:DI 200 [ val ])
0)
(const_int 16777215 [0xff]))
(ashift:SI (subreg:SI (reg:QI 205 [ MEM[(const unsigned
char *)buf_8(D) + 3B] ]) 0)
(const_int 24 [0x18]) "../xx.c":7:29 18
{*insv_extended}
(expr_list:REG_DEAD (reg:QI 205 [ MEM[(const unsigned char *)buf_8(D)
+ 3B] ])
(nil)))
And do similarly for 16/16 pair:
(insn 13 12 14 2 (set (zero_extract:DI (reg/v:DI 198 [ val ])
(const_int 16 [0x10])
(const_int 16 [0x10]))
(subreg:DI (reg:HI 201 [ MEM[(const short unsigned int *)buf_6(D) +
2B] ]) 0)) "xx.c":5:30 286 {*insvdi}
(expr_list:REG_DEAD (reg:HI 201 [ MEM[(const short unsigned int
*)buf_6(D) + 2B] ])
(nil)))
(insn 14 13 17 2 (set (reg/v:DI 198 [ val ])
(sign_extend:DI (subreg:SI (reg/v:DI 198 [ val ]) 0))) "xx.c":5:30
241 {extendsidi2}
(nil))
>
(insn 14 13 17 2 (set (reg/v:DI 198 [ val ])
(sign_extend:DI (ior:SI (ashift:SI (subreg:SI (reg:HI 201 [
MEM[(const short unsigned int *)buf_6(D) + 2B] ]) 0)
(const_int 16 [0x10]))
(zero_extend:SI (subreg:HI (reg/v:DI 198 [ val ]) 0)
"xx.c":5:30 284 {*inshisi_extended}
(expr_list:REG_DEAD (reg:HI 201 [ MEM[(const short unsigned int
*)buf_6(D) + 2B] ])
(nil)))
Let's accept these patterns, and set the cost to 1 instruction.
gcc
PR rtl-optimization/104914
* config/mips/mips.md (insqisi_extended): New patterns.
(inshisi_extended): Ditto.
gcc/testsuite
* gcc.target/mips/pr104914.c: New test.
