Re: About initialization of automatic variables
On Apr 18 2023, naoki ueda via Gcc-bugs wrote: > The attached code says "int a = 100;", but it should normally be > initialized with an "undefined value", but in the case of gcc-10, it is > initialized with "0". Isn't this a bug in gcc-10? 0 is just one instance of "undefined value". -- Andreas Schwab, sch...@linux-m68k.org GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 "And now for something completely different."
[Bug tree-optimization/109176] [11/12 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 --- Comment #18 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0a4cf0e92cbd5f18de3195fa2deb058f2f88e77e commit r12-9421-g0a4cf0e92cbd5f18de3195fa2deb058f2f88e77e Author: Jakub Jelinek Date: Thu Mar 23 10:02:25 2023 +0100 tree-vect-generic: Fix up expand_vector_condition [PR109176] The following testcase ICEs on aarch64-linux, because expand_vector_condition attempts to piecewise lower SVE d_3 = a_1(D) < b_2(D); _5 = VEC_COND_EXPR ; which isn't possible - nunits_for_known_piecewise_op ICEs but the rest of the code assumes constant number of elements too. expand_vector_condition attempts to find if a (rhs1) is a SSA_NAME for comparison and calls expand_vec_cond_expr_p (type, TREE_TYPE (a1), code) where a1 is one of the operands of the comparison and code is the comparison code. That one indeed isn't supported here, but what aarch64 SVE supports are the individual statements, comparison (expand_vec_cmp_expr_p) and expand_vec_cond_expr_p (type, TREE_TYPE (a), SSA_NAME), the latter because that function starts with if (VECTOR_BOOLEAN_TYPE_P (cmp_op_type) && get_vcond_mask_icode (TYPE_MODE (value_type), TYPE_MODE (cmp_op_type)) != CODE_FOR_nothing) return true; In an earlier version of the patch (in the PR), we did this if (VECTOR_BOOLEAN_TYPE_P (TREE_TYPE (a)) && expand_vec_cond_expr_p (type, TREE_TYPE (a), ERROR_MARK)) return true; before the code == SSA_NAME handling plus some further tweaks later. While that fixed the ICE, it broke quite a few tests on x86 and some on aarch64 too. The problem is that expand_vector_comparison doesn't lower comparisons which aren't supported and only feed VEC_COND_EXPR first operand and expand_vector_condition succeeds for those, so with the above mentioned change we'd verify the VEC_COND_EXPR is implementable using optab alone, but nothing would verify the tcc_comparison which relied on expand_vector_condition to verify. So, the following patch instead queries whether optabs can handle the comparison and VEC_COND_EXPR together (if a (rhs1) is a comparison; otherwise as before it checks only the VEC_COND_EXPR) and if that fails, also checks whether the two operations could be supported individually and only if even that fails does the piecewise lowering. 2023-03-23 Jakub Jelinek PR tree-optimization/109176 * tree-vect-generic.cc (expand_vector_condition): If a has vector boolean type and is a comparison, also check if both the comparison and VEC_COND_EXPR could be successfully expanded individually. * gcc.target/aarch64/sve/pr109176.c: New test. (cherry picked from commit 484c41c747d95f9cee15a33b75b32ae2e7eb45f3)
[Bug middle-end/106190] [10/11/12 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190
--- Comment #11 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:2d96422f4608c04d6a7c8444f14446c309416e24
commit r12-9424-g2d96422f4608c04d6a7c8444f14446c309416e24
Author: Jakub Jelinek
Date: Tue Mar 28 10:56:44 2023 +0200
sanopt: Return TODO_cleanup_cfg if any .{UB,HWA,A}SAN_* calls were lowered
[PR106190]
The following testcase ICEs, because without optimization eh lowering
decides not to duplicate finally block of try/finally and so we end up
with variable guarded cleanup. The sanopt pass creates a cfg that ought
to be cleaned up (some IFN_UBSAN_* functions are lowered in this case with
constant conditions in gcond and when not allowing recovery some bbs which
end with noreturn calls actually have successor edges), but the cfg cleanup
is actually (it is -O0) done only during the optimized pass. We notice
there that the d[1][a] = 0; statement which has an EH edge is unreachable
(because ubsan would always abort on the out of bounds d[1] access), remove
the EH landing pad and block, but because that block just sets a variable
and jumps to another one which tests that variable and that one is
reachable
from normal control flow, the __builtin_eh_pointer (1) later in there is
kept in the IL and we ICE during expansion of that statement because the
EH region has been removed.
The following patch fixes it by doing the cfg cleanup already during
sanopt pass if we create something that might need it, while the EH
landing pad is then removed already during sanopt pass, there is ehcleanup
later and we don't ICE anymore.
2023-03-28 Jakub Jelinek
PR middle-end/106190
* sanopt.cc (pass_sanopt::execute): Return TODO_cleanup_cfg if any
of the IFN_{UB,HWA,A}SAN_* internal fns are lowered.
* gcc.dg/asan/pr106190.c: New test.
(cherry picked from commit 39a43dc336561e0eba0de477b16c7355f19d84ee)
[Bug c++/109319] [12 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109319 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:6a5c0588ac00f6f55ae7ed2bb791e7e119a01c43 commit r12-9425-g6a5c0588ac00f6f55ae7ed2bb791e7e119a01c43 Author: Jakub Jelinek Date: Thu Mar 30 23:08:25 2023 +0200 c++: Fix up ICE in build_min_non_dep_op_overload [PR109319] The following testcase ICEs, because grok_array_decl during processing_template_decl handling of a non-dependent subscript emits a -Wcomma-subscript pedwarn, we decide to pass to the single index argument the index expressions as if it was wrapped with () around it, but then when preparing it for later instantiation we don't actually take that into account and ICE on a mismatch of number of index arguments (the overload expects a single index, testcase has two index expressions in this case). For non-dependent subscript which are builtin subscripts we also emit the same pedwarn and don't ICE, but emit the same pedwarn again whenever we instantiate it, which is also IMHO undesirable, it is enough to warn once during parsing the template. The following patch fixes it by turning even the original index expressions (those which didn't go through make_args_non_dependent) into a single index using comma expression(s). 2023-03-30 Jakub Jelinek PR c++/109319 * decl2.cc (grok_array_decl): After emitting a pedwarn for -Wcomma-subscript, if processing_template_decl set orig_index_exp to compound expr from orig_index_exp_list. * g++.dg/cpp23/subscript14.C: New test. (cherry picked from commit c016887c91a79d67b6a3c7e19b9219f5ab1e2a4d)
[Bug c++/109164] wrong code with thread_local reference, loops and -ftree-pre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109164 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:c534a9e56cf16fd996c78f443b6c91f403d794ed commit r12-9420-gc534a9e56cf16fd996c78f443b6c91f403d794ed Author: Jakub Jelinek Date: Mon Mar 20 20:29:47 2023 +0100 c++: Drop TREE_READONLY on vars (possibly) initialized by tls wrapper [PR109164] The following two testcases are miscompiled, because we keep TREE_READONLY on the vars even when they are (possibly) dynamically initialized by a TLS wrapper function. Normally cp_finish_decl drops TREE_READONLY from vars which need dynamic initialization, but for TLS we do this kind of initialization upon every access to those variables. Keeping them TREE_READONLY means e.g. PRE can hoist loads from those before loops which contain the TLS wrapper calls, so we can access the TLS variables before they are initialized. 2023-03-20 Jakub Jelinek PR c++/109164 * cp-tree.h (var_needs_tls_wrapper): Declare. * decl2.cc (var_needs_tls_wrapper): No longer static. * decl.cc (cp_finish_decl): Clear TREE_READONLY on TLS variables for which a TLS wrapper will be needed. * g++.dg/tls/thread_local13.C: New test. * g++.dg/tls/thread_local13-aux.cc: New file. * g++.dg/tls/thread_local14.C: New test. * g++.dg/tls/thread_local14-aux.cc: New file. (cherry picked from commit 0a846340b99675d57fc2f2923a0412134eed09d3)
[Bug tree-optimization/109410] [13 Regression] ICE: verify_flow_info failed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109410 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:0e55b8e091a7263364cb08fd2c9172babb554ab1 commit r12-9428-g0e55b8e091a7263364cb08fd2c9172babb554ab1 Author: Jakub Jelinek Date: Wed Apr 12 16:55:15 2023 +0200 reassoc: Fix up another ICE with returns_twice call [PR109410] The following testcase ICEs in reassoc, unlike the last case I've fixed there here SSA_NAME_USED_IN_ABNORMAL_PHI is not the case anywhere. build_and_add_sum places new statements after the later appearing definition of an operand but if both operands are default defs or constants, we place statement at the start of the function. If the very first statement of a function is a call to returns_twice function, this doesn't work though, because that call has to be the first thing in its basic block, so the following patch splits the entry successor edge such that the new statements are added into a different block from the returns_twice call. I think we should in stage1 reconsider such placements, I think it unnecessarily enlarges the lifetime of the new lhs if its operand(s) are used more than once in the function. Unless something sinks those again. Would be nice to place it closer to the actual uses (or where they will be placed). 2023-04-12 Jakub Jelinek PR tree-optimization/109410 * tree-ssa-reassoc.cc (build_and_add_sum): Split edge from entry block if first statement of the function is a call to returns_twice function. * gcc.dg/pr109410.c: New test. (cherry picked from commit 51856718a82ce60f067910d9037ca255645b37eb)
[Bug ipa/105685] [10/11/12 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2407495178fa20382944cdbb875e940ad109f9fb commit r12-9422-g2407495178fa20382944cdbb875e940ad109f9fb Author: Jakub Jelinek Date: Sun Mar 26 20:15:05 2023 +0200 predict: Don't emit -Wsuggest-attribute=cold warning for functions which already have that attribute [PR105685] In the following testcase, we predict baz to have cold entry regardless of the user supplied attribute (as it call unconditionally a cold function), but still issue a -Wsuggest-attribute=cold warning despite it having that attribute already. The following patch avoids that. 2023-03-26 Jakub Jelinek PR ipa/105685 * predict.cc (compute_function_frequency): Don't call warn_function_cold if function already has cold attribute. * c-c++-common/cold-2.c: New test. (cherry picked from commit 7eca91d4781bb3df941f25c30b971dac66ba1b3d)
[Bug target/109276] [11/12 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276 --- Comment #20 from CVS Commits --- The releases/gcc-12 branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:429a5143d17bd83d4662cd6c7a2c30d065c8f65b commit r12-9423-g429a5143d17bd83d4662cd6c7a2c30d065c8f65b Author: Jakub Jelinek Date: Tue Mar 28 10:43:08 2023 +0200 i386: Require just 32-bit alignment for SLOT_FLOATxFDI_387 -m32 -mpreferred-stack-boundary=2 DImode temporaries [PR109276] The following testcase ICEs since r11-2259 because assign_386_stack_local -> assign_stack_local -> ix86_local_alignment now uses 64-bit alignment for DImode temporaries rather than 32-bit as before. Most of the spots in the backend which ask for DImode temporaries are during expansion and those apparently are handled fine with -m32 -mpreferred-stack-boundary=2, we dynamically realign the stack in that case (most of the spots actually don't need that alignment but at least one does), then 2 spots are in STV which I assume also work correctly. But during splitting we can create a DImode slot which doesn't need to be 64-bit alignment (it is nicer for performance though), when we apparently aren't able to detect it for dynamic stack realignment purposes. The following patch just makes the slot 32-bit aligned in that rare case. 2023-03-28 Jakub Jelinek PR target/109276 * config/i386/i386.cc (assign_386_stack_local): For DImode with SLOT_FLOATxFDI_387 and -m32 -mpreferred-stack-boundary=2 pass align 32 rather than 0 to assign_stack_local. * gcc.target/i386/pr109276.c: New test. (cherry picked from commit 4b5ef857f5faf09f274c0a95c67faaa80d198124)
[Bug other/109306] The strstr implementation in libiberty might have undefined behavior (out of bounds mem access)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109306
--- Comment #9 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jakub Jelinek
:
https://gcc.gnu.org/g:1c7d418661e385d7428842088b93016e2be43ce4
commit r12-9426-g1c7d418661e385d7428842088b93016e2be43ce4
Author: Jakub Jelinek
Date: Sun Apr 2 20:05:31 2023 +0200
libiberty: Make strstr.c in libiberty ANSI compliant
On Fri, Nov 13, 2020 at 11:53:43AM -0700, Jeff Law via Gcc-patches wrote:
>
> On 5/1/20 6:06 PM, Seija Kijin via Gcc-patches wrote:
> > The original code in libiberty says "FIXME" and then says it has not
been
> > validated to be ANSI compliant. However, this patch changes the
function to
> > match implementations that ARE compliant, and such code is in the
public
> > domain.
> >
> > I ran the test results, and there are no test failures.
>
> Thanks. This seems to be the standard "simple" strstr implementation.
> There's significantly faster implementations available, but I doubt it's
> worth the effort as the version in this file only gets used if there is
> no system strstr.c.
Except that PR109306 says the new version is non-compliant and
is certainly slower than what we used to have. The only problem I see
on the old version (sure, it is not very fast version) is that for
strstr ("abcd", "") it returned "abcd"+4 rather than "abcd" because
strchr in that case changed p to point to the last character and then
strncmp returned 0.
The question reported in PR109306 is whether memcmp is required not to
access characters beyond the first difference or not.
For all of memcmp/strcmp/strncmp, C17 says:
"The sign of a nonzero value returned by the comparison functions memcmp,
strcmp, and strncmp
is determined by the sign of the difference between the values of the first
pair of characters (both
interpreted as unsigned char) that differ in the objects being compared."
but then in memcmp description says:
"The memcmp function compares the first n characters of the object pointed
to by s1 to the first n
characters of the object pointed to by s2."
rather than something similar to strncmp wording:
"The strncmp function compares not more than n characters (characters that
follow a null character
are not compared) from the array pointed to by s1 to the array pointed to
by
s2."
So, while for strncmp it seems clearly well defined when there is zero
terminator before reaching the n, for memcmp it is unclear if say
int
memcmp (const void *s1, const void *s2, size_t n)
{
int ret = 0;
size_t i;
const unsigned char *p1 = (const unsigned char *) s1;
const unsigned char *p2 = (const unsigned char *) s2;
for (i = n; i; i--)
if (p1[i - 1] != p2[i - 1])
ret = p1[i - 1] < p2[i - 1] ? -1 : 1;
return ret;
}
wouldn't be valid implementation (one which always compares all characters
and just returns non-zero from the first one that differs).
So, shouldn't we just revert and handle the len == 0 case correctly?
I think almost nothing really uses it, but still, the old version
at least worked nicer with a fast strchr.
Could as well strncmp (p + 1, s2 + 1, len - 1) if that is preferred
because strchr already compared the first character.
2023-04-02 Jakub Jelinek
PR other/109306
* strstr.c: Revert the 2020-11-13 changes.
(strstr): Return s1 if len is 0.
(cherry picked from commit 1719fa40c4ee4def60a2ce2f27e17f8168cf28ba)
[Bug c++/109319] [12 Regression] ICE in build_min_non_dep_op_overload, at cp/tree.cc:3793 since r12-5510
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109319 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed also for 12.3.
[Bug target/109276] [11 Regression] ICE: in assign_stack_local_1, at function.cc:429 with -mpreferred-stack-boundary=2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109276 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] ICE: in |[11 Regression] ICE: in |assign_stack_local_1, at|assign_stack_local_1, at |function.cc:429 with|function.cc:429 with |-mpreferred-stack-boundary= |-mpreferred-stack-boundary= |2 |2 --- Comment #21 from Jakub Jelinek --- Fixed also for 12.3.
[Bug ipa/105685] [10/11 Regression] Bogus `-Wsuggest-attribute=cold` on function already marked as `__attribute__((cold))`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105685 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] Bogus |[10/11 Regression] Bogus |`-Wsuggest-attribute=cold` |`-Wsuggest-attribute=cold` |on function already marked |on function already marked |as `__attribute__((cold))` |as `__attribute__((cold))` --- Comment #8 from Jakub Jelinek --- Fixed also for 12.3.
[Bug middle-end/106190] [10/11 Regression] ICE in expand_builtin_eh_common with -fnon-call-exceptions -fsanitize=address,undefined -fno-sanitize-recover=all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106190 Jakub Jelinek changed: What|Removed |Added Summary|[10/11/12 Regression] ICE |[10/11 Regression] ICE in |in expand_builtin_eh_common |expand_builtin_eh_common |with -fnon-call-exceptions |with -fnon-call-exceptions |-fsanitize=address,undefine |-fsanitize=address,undefine |d -fno-sanitize-recover=all |d -fno-sanitize-recover=all --- Comment #12 from Jakub Jelinek --- Fixed also for 12.3.
[Bug tree-optimization/109176] [11 Regression] internal compiler error: in to_constant, at poly-int.h:504
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109176 Jakub Jelinek changed: What|Removed |Added Summary|[11/12 Regression] internal |[11 Regression] internal |compiler error: in |compiler error: in |to_constant, at |to_constant, at |poly-int.h:504 |poly-int.h:504 --- Comment #19 from Jakub Jelinek --- Fixed also for 12.3.
[Bug testsuite/106879] [13/14 regression] new test case gcc.dg/vect/bb-slp-layout-19.c fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106879 Jiu Fu Guo changed: What|Removed |Added CC||guojiufu at gcc dot gnu.org --- Comment #5 from Jiu Fu Guo --- Like PR65484 and PR87306. On P7, option -mno-allow-movmisalign is added during testing, which prevents slp happen on the code.
[Bug libgcc/109540] New: Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
Bug ID: 109540
Summary: Y2038: GCC gthr-posix.h weakref symbol invoking
function has impact on time values
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libgcc
Assignee: unassigned at gcc dot gnu.org
Reporter: punitb20 at gmail dot com
Target Milestone: ---
All
if we fallowed https://sourceware.org/glibc/wiki/Y2038ProofnessDesign for Y2038
fix(where all timer related variable moved to 64 bit instead of 32 bit ),
pthread_cond_timedwait function from gthr_posix.h is calling different function
in pthrea_cond_wait.c of glibc(due to weakref of symbol
pthread_cond_timedwait()) which impacting the time value.
>From pthread.h
extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict
__abstime) __asm__ ("" "__pthread_cond_timedwait64")
>From gthread_posix.h:
static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait
__attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__
(pthread_cond_timedwait)));
__gthrw_(pthread_cond_timedwait) --> ___pthread_cond_timedwait invoking in
glibc instead of __pthread_cond_timedwait64 which is impacting time value as
__pthread_cond_timedwait is converting value from 32 bit to 64 bit.
normal pthread_cond_timedwait is invoking __pthread_cond_timedwait64 properly
and its working fine.
From: pthread_cond_wait.c
#if __TIMESIZE == 64
strong_alias (___pthread_cond_timedwait64, ___pthread_cond_timedwait)
#else
strong_alias (___pthread_cond_timedwait64, __pthread_cond_timedwait64)
libc_hidden_def (__pthread_cond_timedwait64)
int
___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t *mutex,
const struct timespec *abstime)
{
struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
return __pthread_cond_timedwait64 (cond, mutex, &ts64);
}
#endif /* __TIMESIZE == 64 */
versioned_symbol (libc, ___pthread_cond_timedwait,
pthread_cond_timedwait, GLIBC_2_3_2);
libc_hidden_ver (___pthread_cond_timedwait, __pthread_cond_timedwait)
#ifndef SHARED
strong_alias (___pthread_cond_timedwait, __pthread_cond_timedwait)
#endif
if add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h issue is resolved
but that is not correct way as it disable weakref for all symbol, please let me
know what is correct way to fix this, this i observed with gcc-9.3.0 gcc and
glibc 2.34
Regards
Puneet
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #1 from Puneet B --- Here issue is weakref symbol in gcc not using the __asm_ function pointed by pthread.h instead its calling directly ___pthread_cond_timedwait which is exposed by version_symbol in pthread_cond_wait.c of glibc
[Bug c++/109532] -fshort-enums does not pick smallest underlying type for scoped enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109532 --- Comment #6 from Jonathan Wakely --- (In reply to Wilhelm M from comment #5) > So in general a scoped-enum inside a class (nested type) maybe always a bad > idea, because it prevents optimization. I don't know how you have drawn that conclusion or how it's related to this bug report. > And when specifying the underlying > type, the -fstrict-enums can't be applied because all values of the > underlying type are possible. Correct, with a fixed underlying type -fstrict-enums and -fshort-enums have no effect.
Re: About initialization of automatic variables
Ok, thanks! 2023年4月18日(火) 16:06 Andreas Schwab : > On Apr 18 2023, naoki ueda via Gcc-bugs wrote: > > > The attached code says "int a = 100;", but it should normally be > > initialized with an "undefined value", but in the case of gcc-10, it is > > initialized with "0". Isn't this a bug in gcc-10? > > 0 is just one instance of "undefined value". > > -- > Andreas Schwab, sch...@linux-m68k.org > GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1 > "And now for something completely different." >
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #1 from Martin Liška --- Created attachment 54877 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54877&action=edit Reduced test-case Takes 1.77s after the mentioned revision and 0.15s before it.
Re: About initialization of automatic variables
The gcc-bugs@gcc.gnu.org list is for automated email from our Bugzilla database, please don't use it to report bugs or to ask questions about how GCC works. For questions about using GCC send email to gcc-h...@gcc.gnu.org and to report bugs please use bugzilla: https://gcc.gnu.org/bugs/ Thanks!
[Bug libgomp/107041] [13/14 Regression] C '-Wenum-int-mismatch' diagnostic for OpenACC 'acc_on_device'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107041 Jakub Jelinek changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-04-18 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek --- Created attachment 54879 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54879&action=edit gcc14-pr107041.patch Untested fix.
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Richard Biener --- I will have a look.
[Bug target/109541] New: ICE in extract_constrain_insn on sparc64-unknown-linux-gnu when building rhash-1.4.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541
Bug ID: 109541
Summary: ICE in extract_constrain_insn on
sparc64-unknown-linux-gnu when building rhash-1.4.3
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: sjames at gcc dot gnu.org
Target Milestone: ---
Host: sparc64-unknown-linux-gnu
Target: sparc64-unknown-linux-gnu
Build: sparc64-unknown-linux-gnu
Created attachment 54880
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54880&action=edit
a-sha512.i
Hit this when building rhash-1.4.3
```
$ sparc64-unknown-linux-gnu-gcc -DUSE_OPENSSL -DNDEBUG -pipe
-ffunction-sections -fdata-sections -fomit-frame-pointer -Wall -W
-Wstrict-prototypes -Wnested-externs -Winline -Wpointer-arith
-Wbad-function-cast -Wmissing-prototypes -Wmissing-declarations
-Wdeclaration-after-statement -O2 -mcpu=niagara4 -pipe -fpic
-DRHASH_XVERSION=0x01040200 librhash/sha512.c
librhash/sha512.c: In function ‘rhash_sha512_process_block’:
librhash/sha512.c:179:1: error: insn does not satisfy its constraints:
179 | }
| ^
(insn 5 2048 675 2 (set (reg/f:DI 72 %f40 [2613])
(mem/u/c:DI (plus:DI (reg:DI 3 %g3 [109])
(symbol_ref:DI ("rhash_k512") [flags 0x2] )) [0 S8 A64])) "librhash/sha512.c":158:17 125
{*movdi_insn_sp64}
(expr_list:REG_EQUIV (symbol_ref:DI ("rhash_k512") [flags 0x2] )
(nil)))
during RTL pass: reload
librhash/sha512.c:179:1: internal compiler error: in extract_constrain_insn, at
recog.cc:2692
0x18521f7 internal_error(char const*, ...)
???:0
0x2cbd17 fancy_abort(char const*, int, char const*)
???:0
0x2b2b27 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
???:0
0x2b2bdf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
???:0
0xa3b7b7 extract_constrain_insn(rtx_insn*)
???:0
0x8c3687 lra(_IO_FILE*)
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See
[Bug target/109541] ICE in extract_constrain_insn on sparc64-unknown-linux-gnu when building rhash-1.4.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109541 --- Comment #1 from Sam James --- Maybe a dupe of PR108703? Need to rebuild with debugging symbols as well now.
[Bug tree-optimization/109240] Missed fneg/fsub optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109240 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:2349e69125335d4c8c5e43cf3643844519d154c3 commit r14-22-g2349e69125335d4c8c5e43cf3643844519d154c3 Author: Jakub Jelinek Date: Tue Apr 18 11:01:47 2023 +0200 match.pd: Improve fneg/fadd optimization [PR109240] match.pd has mostly for AArch64 an optimization in which it optimizes certain forms of __builtin_shuffle of x + y and x - y vectors into fneg using twice as wide element type so that every other sign is changed, followed by fadd. The following patch extends that optimization, so that it can handle other forms as well, using the same fneg but fsub instead of fadd. As the plus is commutative and minus is not and I want to handle vec_perm with plus minus and minus plus order preferrably in one pattern, I had to do the matching operand checks by hand. 2023-04-18 Jakub Jelinek PR tree-optimization/109240 * match.pd (fneg/fadd): Rewrite such that it handles both plus as first vec_perm operand and minus as second using fneg/fadd and minus as first vec_perm operand and plus as second using fneg/fsub. * gcc.target/aarch64/simd/addsub_2.c: New test. * gcc.target/aarch64/sve/addsub_2.c: New test.
[Bug tree-optimization/109240] Missed fneg/fsub optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109240 Jakub Jelinek changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #4 from Jakub Jelinek --- Implemented for GCC 14.
[Bug tree-optimization/98856] [11/12/13/14 Regression] botan AES-128/XTS is slower by ~17% since r11-6649-g285fa338b06b804e72997c4d876ecf08a9c083af
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98856 Richard Biener changed: What|Removed |Added Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #44 from Richard Biener --- The original description is for znver1 which we stopped benchmarking. https://lnt.opensuse.org/db_default/v4/CPP/graph?highlight_run=39959&plot.0=171.721.1 is for znver2 still showing the regression and the following for znver3 which doesn't date back to the rev that regressed https://lnt.opensuse.org/db_default/v4/CPP/graph?highlight_run=39969&plot.721=283.721.1 So the issue is still there but I am no longer actively working on it.
Re: About initialization of automatic variables
Ok, I see. 2023年4月18日(火) 17:27 Jonathan Wakely : > The gcc-bugs@gcc.gnu.org list is for automated email from our Bugzilla > database, please don't use it to report bugs or to ask questions about > how GCC works. > > For questions about using GCC send email to gcc-h...@gcc.gnu.org and > to report bugs please use bugzilla: https://gcc.gnu.org/bugs/ > > Thanks! > > >
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #3 from Richard Biener --- The issue is almost certainly the cost of pointers_related_p Samples: 3M of event 'cycles', Event count (approx.): 3573086788171 Children Self Samples Command Shared Object Symbol - 93.15% 0.80% 25898 cc1plus cc1plus [.] (anonymous namespace)::pointers_related_p # - 92.35% (anonymous namespace)::pointers_related_p # - 92.30% (anonymous namespace)::pointers_related_p # - 92.21% (anonymous namespace)::pointers_related_p # - 92.12% (anonymous namespace)::pointers_related_p # - 92.02% (anonymous namespace)::pointers_related_p # - 91.93% (anonymous namespace)::pointers_related_p # - 91.84% (anonymous namespace)::pointers_related_p # - 91.75% (anonymous namespace)::pointers_related_p # - 91.66% (anonymous namespace)::pointers_related_p # - 91.57% (anonymous namespace)::pointers_related_p # - 91.48% (anonymous namespace)::pointers_related_p # - 91.39% (anonymous namespace)::pointers_related_p # - 87.34% (anonymous namespace)::pointers_related_p# - 62.30% (anonymous namespace)::pointers_related_p # - 44.52% pointer_query::get_ref # - 44.51% compute_objsize # + 15.03% access_ref::size_remaining # + 14.49% wide_int_to_tree # + 4.91% generic_wide_int >::operat# + 4.57% operator<
[Bug fortran/108961] Segfault when associating to pointer from C_F_POINTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108961 Paul Thomas changed: What|Removed |Added Blocks|87477 | Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org --- Comment #3 from Paul Thomas --- Since this has nothing to do with the associate construct, I have removed the blocking of PR87477. That said, I am onto it :-) I cannot see anything untoward with the produced code at the moment and, since there is the dependence on whether or not the subroutine is in a module, I can only surmise that there is some subtle difference in memory usage. Paul Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477 [Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement
[Bug c++/109518] invalid constexpr code is accepted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109518 Jonathan Wakely changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2023-04-18 Status|UNCONFIRMED |NEW
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #4 from Richard Biener --- So what we try to do is, when check_pointer_uses follows the use chain of 'ptr' through say ptr2 = ptr + 4; then it wants to visit ptr2 uses as well. For PHIs we get to ptr2 = PHI <..., ptr, ...>; and we want to consider uses of ptr2 only if all other PHI arguments are "related" to 'ptr'. To prove that we perform complicated gymnastics, in particular the only real check done is if (!ptr_derefs_may_alias_p (p, q)) return false; and that's of course incredibly weak. To disprove relatedness the pointers_related_p recurses, but only when either of both pointers are defined by a PHI. It uses pointer-query to skip chains of pointer adjustments up to such definition. So we basically do forward relatedness in check_pointer_uses and then backward relatedness in pointers_related_p. I think we should eschew that completely and only try to handle "forward" PHIs by the iteration in check_pointer_uses itself.
[Bug libstdc++/109517] Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517 Jonathan Wakely changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=108617 --- Comment #1 from Jonathan Wakely --- I think this is a front end bug, not a library bug.
[Bug libstdc++/109517] Failure to compile constexpr std::copy with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109517 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jonathan Wakely --- Ah yes, this is a dup of bug 106212 which is caused by bug 85944 *** This bug has been marked as a duplicate of bug 85944 ***
[Bug c++/85944] Address of temporary bound to a function parameter at global scope not considered constexpr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85944 Jonathan Wakely changed: What|Removed |Added CC||terra at gnome dot org --- Comment #9 from Jonathan Wakely --- *** Bug 109517 has been marked as a duplicate of this bug. ***
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #2 from Jonathan Wakely --- N.B. GCC 9 is no longer supported, so any changes will not help that version.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #3 from Puneet B --- It can be reproduceable in gcc master branch or latest release..dont look at it as GCC particular version bug.
[Bug c/109542] New: bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 Bug ID: 109542 Summary: bad detection of null dereferance cause ud2a in valid inline function code Product: gcc Version: 11.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: amos.maimon at sap dot com Target Milestone: --- Created attachment 54881 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54881&action=edit snip code that reproduce the issue that decribe above There is a bug in the detection of null dereferance - and user code change to UD2A. This happened when the function picked to be inline. How to reproduce: 1. download the attached code snip. 2. compile with the following params: gcc -Wall -Werror -Wno-packed-not-aligned -Wno-address-of-packed-member -Wno-multichar -Wno-unused -fno-strict-aliasing -fno-optimize-sibling-calls -mno-sse -fno-omit-frame-pointer -g -finline-limit=6000 -mcmodel=large -ffreestanding -mno-red-zone -O2 test.c 3. with objdump you can see that the line : *(p + 0xe) = 0xfc; compile to : 1044: c6 04 25 fe ff 0f 00movb $0x0,0xe 104b: 00 104c: 0f 0b ud2 While if instead p you will use local parameter (define SIMPLE_WRITE and recompile) it will keep user code as expected: 1044: c6 04 25 fe ff 0f 00movb $0xfc,0xe 104b: fc Note that the problam will not occur if -fno-delete-null-pointer-checks will be added to the compilation parameters.
[Bug tree-optimization/109543] New: Avoid using BLKmode for unions with a non-BLKmode member when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543
Bug ID: 109543
Summary: Avoid using BLKmode for unions with a non-BLKmode
member when possible
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: avieira at gcc dot gnu.org
Target Milestone: ---
Hi,
So with the following C-code:
$ cat t.c
#include
#ifdef GOOD
typedef float64x2x2_t TYPE;
#else
typedef union
{
float64x2x2_t v;
double d[4];
} TYPE;
#endif
void foo (TYPE *a, TYPE *b, TYPE *c, unsigned n)
{
TYPE X = a[0];
TYPE Y = b[0];
TYPE Z = c[0];
for (unsigned i = 0; i < n; ++n)
{
TYPE temp = X;
X = Y;
Y = Z;
Z = temp;
}
a[0] = X;
b[0] = Y;
c[0] = Z;
}
If compiled for aarch64 with -DGOOD the compiler will use vector register moves
in the loop, whereas without -DGOOD it will use the stack with memmoves.
The reason for this is because when picking the mode to address a UNION with
gcc will always choose BLKmode as soon as any member of a UNION is BLKmode. In
such cases I think it would be safe to go with not-BLKmode of members that have
the same size as the entire UNION?
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #4 from Jonathan Wakely --- Yes, I know. I'm just pointing out that you're reporting a bug against an unsupported version.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540
--- Comment #5 from Jonathan Wakely ---
The description is a bit confusing, but the issue is that we define:
typedef struct timespec __gthread_time_t;
and then use that in several functions like this:
static inline int
__gthread_cond_timedwait (__gthread_cond_t *__cond, __gthread_mutex_t *__mutex,
const __gthread_time_t *__abs_timeout)
{
return __gthrw_(pthread_cond_timedwait) (__cond, __mutex, __abs_timeout);
}
If libc uses a 64-bit time_t in struct timespec then we need to use
__pthread_cond_timedwait64 instead of pthread_cond_timedwait, because the
latter expects a struct containing a 32-bit time_t instead of a 64-bit one.
The weak alias referenced by __gthrw_ is defined like so:
static __typeof(pthread_cond_timedwait) __gthrw_pthread_cond_timedwait
__attribute__ ((__weakref__("pthread_cond_timedwait"), __copy__
(pthread_cond_timedwait)));
Where the _TIME_BITS=64 declaration of pthread_cond_timedwait is:
extern int pthread_cond_timedwait (pthread_cond_t *__restrict __cond,
pthread_mutex_t *__restrict __mutex, const struct timespec *__restrict
__abstime) __asm__ ("" "__pthread_cond_timedwait64")
The reported issue is that weakref("pthread_cond_timedwait") binds to a symbol
of that name, rather than to __pthread_cond_timedwait64, so we end up passing a
64-bit timespec to the 32-bit pthread_cond_timedwait.
However, that's not what I observe when I test it.
If I compile with 32-bit time_t for i686 using GCC 12 and
glibc-2.36-9.fc37.i686 then a call to __gthread_cond_timedwait will resolve to
glibc's pthread_cond_timedwait which expects a 32-bit timespec:
(gdb)
13__gthread_cond_timedwait(&cond, &mutex, &ts);
(gdb) step
__gthread_cond_timedwait (__cond=0x804c060 , __mutex=0x804c090 ,
__abs_timeout=0xc7e8)
at /usr/include/c++/12/x86_64-redhat-linux/32/bits/gthr-default.h:872
872 return __gthrw_(pthread_cond_timedwait) (__cond, __mutex,
__abs_timeout);
(gdb)
___pthread_cond_timedwait (cond=0x804c060 , mutex=0x804c090 ,
abstime=0xc7e8) at pthread_cond_wait.c:655
655 {
(gdb) l
650 libc_hidden_def (__pthread_cond_timedwait64)
651
652 int
653 ___pthread_cond_timedwait (pthread_cond_t *cond, pthread_mutex_t
*mutex,
654 const struct timespec *abstime)
655 {
656 struct __timespec64 ts64 = valid_timespec_to_timespec64 (*abstime);
657
658 return __pthread_cond_timedwait64 (cond, mutex, &ts64);
659 }
If I recompile the same code with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 then
the call to __gthread_cond_timedwait resolves to glibc's
__pthread_cond_timedwait64:
(gdb)
13__gthread_cond_timedwait(&cond, &mutex, &ts);
(gdb) step
__gthread_cond_timedwait (__cond=0x804c060 , __mutex=0x804c090 ,
__abs_timeout=0xc7e0)
at /usr/include/c++/12/x86_64-redhat-linux/32/bits/gthr-default.h:872
872 return __gthrw_(pthread_cond_timedwait) (__cond, __mutex,
__abs_timeout);
(gdb)
___pthread_cond_timedwait64 (cond=0x804c060 , mutex=0x804c090 ,
abstime=0xc7e0) at pthread_cond_wait.c:632
632 {
(gdb) l
627
628 /* See __pthread_cond_wait_common. */
629 int
630 ___pthread_cond_timedwait64 (pthread_cond_t *cond, pthread_mutex_t
*mutex,
631 const struct __timespec64 *abstime)
632 {
633 /* Check parameter validity. This should also tell the compiler that
634 it can assume that abstime is not NULL. */
635 if (! valid_nanoseconds (abstime->tv_nsec))
636 return EINVAL;
So it seems to work fine. Do you actually observe a bug, or are you just
speculating from reading the wiki page and headers?
[Bug libstdc++/109536] Failure to compile constexpr std::vector with -D_GLIBCXX_DEBUG
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109536 --- Comment #3 from Jonathan Wakely --- Right - using std::vector in constant expressions isn't supported by debug mode. Somebody needs to work on that.
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 Xi Ruoyao changed: What|Removed |Added CC||xry111 at gcc dot gnu.org --- Comment #1 from Xi Ruoyao --- Performing arithmetic on NULL pointer is an undefined behavior. The standard says you can only perform arithmetic on a pointer if it's a pointer to an array element (an object not in any array will be considered as the only element in an array with length 1), but NULL is not such a pointer.
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 --- Comment #2 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4ec4ceafcc04ec7bafb1857cf6d491030440a765 commit r14-27-g4ec4ceafcc04ec7bafb1857cf6d491030440a765 Author: Patrick Palka Date: Tue Apr 18 07:21:07 2023 -0400 libstdc++: Fix typo in views::as_const's operator() [PR109525] PR libstdc++/109525 libstdc++-v3/ChangeLog: * include/std/ranges (views::_AsConst::operator()): Add missing const to constant_range test. * testsuite/std/ranges/adaptors/as_const/1.cc (test02): Improve formatting. Adjust expected type of v2. (test03): New test.
[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827 --- Comment #1 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:cb5c71d16d0fb47638498365f5c857ce7c673eaf commit r14-29-gcb5c71d16d0fb47638498365f5c857ce7c673eaf Author: Patrick Palka Date: Tue Apr 18 07:21:13 2023 -0400 libstdc++: Implement range_adaptor_closure from P2387R3 [PR108827] PR libstdc++/108827 libstdc++-v3/ChangeLog: * include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value for C++23. * include/std/ranges (range_adaptor_closure): Define for C++23. * include/std/version (__cpp_lib_ranges): Bump value for C++23. * testsuite/std/ranges/version_c++23.cc: Bump expected value of __cpp_lib_ranges. * testsuite/std/ranges/range_adaptor_closure.cc: New test.
[Bug tree-optimization/109543] Avoid using BLKmode for unions with a non-BLKmode member when possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109543 Richard Biener changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2023-04-18 CC||jamborm at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Richard Biener --- A safe mode would have to be an integer mode supporting bitwise copying. Usually SRA is responsible for selecting "register-like" types for aggregates but it might in this case stay away because of the union. But it really looks like a classy example SRA should handle (for example by splitting TYPE into four DImode integers - it wouldn't currently chose vectors but of course it eventually could). Can you adjust the testcase to use GCC generic vectors?
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 --- Comment #3 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4dc8c0b62d91d239b88cc81bbb8f4fbde317fde6 commit r13-7212-g4dc8c0b62d91d239b88cc81bbb8f4fbde317fde6 Author: Patrick Palka Date: Tue Apr 18 07:21:07 2023 -0400 libstdc++: Fix typo in views::as_const's operator() [PR109525] PR libstdc++/109525 libstdc++-v3/ChangeLog: * include/std/ranges (views::_AsConst::operator()): Add missing const to constant_range test. * testsuite/std/ranges/adaptors/as_const/1.cc (test02): Improve formatting. Adjust expected type of v2. (test03): New test. (cherry picked from commit 4ec4ceafcc04ec7bafb1857cf6d491030440a765)
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 Richard Biener changed: What|Removed |Added Target||x86_64-*-* i?86-*-* Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Richard Biener --- This works exactly as intended. In C when you offset a pointer you may not venture outside of a valid object and at NULL there isn't a valid object unless -fno-delete-null-pointer-checks.
[Bug libstdc++/108827] [C++23] Implement P2387R3, Pipe support for user-defined range adaptors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108827 --- Comment #2 from CVS Commits --- The releases/gcc-13 branch has been updated by Patrick Palka : https://gcc.gnu.org/g:769c324424500a3d20de7417f62a4e7bce345775 commit r13-7214-g769c324424500a3d20de7417f62a4e7bce345775 Author: Patrick Palka Date: Tue Apr 18 07:21:13 2023 -0400 libstdc++: Implement range_adaptor_closure from P2387R3 [PR108827] PR libstdc++/108827 libstdc++-v3/ChangeLog: * include/bits/ranges_cmp.h (__cpp_lib_ranges): Bump value for C++23. * include/std/ranges (range_adaptor_closure): Define for C++23. * include/std/version (__cpp_lib_ranges): Bump value for C++23. * testsuite/std/ranges/version_c++23.cc: Bump expected value of __cpp_lib_ranges. * testsuite/std/ranges/range_adaptor_closure.cc: New test. (cherry picked from commit cb5c71d16d0fb47638498365f5c857ce7c673eaf)
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 --- Comment #3 from Amos Maimon --- 1. the same will occur if you will do : p[0xe] = 0xfc; 2. how do you explin the fact that if the null set in the function (SIMPLE_WRITE case) gcc compile it without ud2a
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 --- Comment #4 from Xi Ruoyao --- (In reply to Amos Maimon from comment #3) > 1. the same will occur if you will do : > p[0xe] = 0xfc; Yes, it's undefined behavior too as C defines a[b] as *(a+b). > 2. how do you explin the fact that if the null set in the function > (SIMPLE_WRITE case) gcc compile it without ud2a It's an undefined behavior, the compiler can do anything.
[Bug c/109542] bad detection of null dereferance cause ud2a in valid inline function code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109542 --- Comment #5 from Jonathan Wakely --- You can either perform the arithmetic using intptr_t or uintptr_t, or use -fdelete-null-pointer-checks (as the documentation for that option explains). Also I would expect a volatile char* to be used for such accesses.
[Bug libstdc++/109525] typo in views::as_const::operator()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109525 Patrick Palka changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.0 --- Comment #4 from Patrick Palka --- Fixed for GCC 13, thanks!
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #6 from CVS Commits --- The releases/gcc-13 branch has been updated by Richard Biener : https://gcc.gnu.org/g:68aea7801848f978f8b5461807dfd3b7a504da1e commit r13-7215-g68aea7801848f978f8b5461807dfd3b7a504da1e Author: Richard Biener Date: Tue Apr 18 11:49:48 2023 +0200 tree-optimization/109539 - restrict PHI handling in access diagnostics Access diagnostics visits the SSA def-use chains to diagnose things like dangling pointer uses. When that runs into PHIs it tries to prove all incoming pointers of which one is the currently visited use are related to decide whether to keep looking for the PHI def uses. That turns out to be overly optimistic and thus costly. The following scraps the existing handling for simply requiring that we eventually visit all incoming pointers of the PHI during the def-use chain analysis and only then process uses of the PHI def. Note this handles backedges of natural loops optimistically, diagnosing the first iteration. There's gcc.dg/Wuse-after-free-2.c containing a testcase requiring this. PR tree-optimization/109539 * gimple-ssa-warn-access.cc (pass_waccess::check_pointer_uses): Re-implement pointer relatedness for PHIs. (cherry picked from commit fdbaab2dc886f78a1e755120faa17e77c862)
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Richard Biener --- Fixed.
[Bug tree-optimization/109539] [13/14 Regression] Compile-time hog in gimple-ssa-warn-access.cc since r13-6706-gadb70c2d1060b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109539 --- Comment #5 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:fdbaab2dc886f78a1e755120faa17e77c862 commit r14-30-gfdbaab2dc886f78a1e755120faa17e77c862 Author: Richard Biener Date: Tue Apr 18 11:49:48 2023 +0200 tree-optimization/109539 - restrict PHI handling in access diagnostics Access diagnostics visits the SSA def-use chains to diagnose things like dangling pointer uses. When that runs into PHIs it tries to prove all incoming pointers of which one is the currently visited use are related to decide whether to keep looking for the PHI def uses. That turns out to be overly optimistic and thus costly. The following scraps the existing handling for simply requiring that we eventually visit all incoming pointers of the PHI during the def-use chain analysis and only then process uses of the PHI def. Note this handles backedges of natural loops optimistically, diagnosing the first iteration. There's gcc.dg/Wuse-after-free-2.c containing a testcase requiring this. PR tree-optimization/109539 * gimple-ssa-warn-access.cc (pass_waccess::check_pointer_uses): Re-implement pointer relatedness for PHIs.
[Bug libgcc/109540] Y2038: GCC gthr-posix.h weakref symbol invoking function has impact on time values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109540 --- Comment #6 from Puneet B --- its not after refer the wiki, its observed on target where its clear that even after compiling application with -D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64 its still calling ___pthread_cond_timedwait More over if i call pthread_cond_timedwait directly its calling __pthread_cond_timedwait64 directly as i already mentioned in this thread. And issue is resolved if i add #defing GTHREAD_USE_WEAK 0 in libgcc/gthr-posix.h it clears that weakref symbol is not working properly during linker stage. both __gthrw_(pthread_cond_timedwait) and pthread_cond_timedwait are expected to invoke same API. let me know if you need any more inputs
[Bug c++/105351] [concepts] Constraint checking does correctly match static member attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105351 Patrick Palka changed: What|Removed |Added Target Milestone|--- |13.0 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from Patrick Palka --- Fixed for GCC 13, probably not suitable for backporting. Thanks for the bug report.
[Bug libstdc++/108976] codecvt for Unicode allows surrogate code points
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108976 --- Comment #7 from Dimitrij Mijoski --- I put a second version of the patch https://gcc.gnu.org/pipermail/libstdc++/2023-March/055667.html about a month ago.
[Bug target/105325] power10: Error: operand out of range
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105325 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org Target Milestone|--- |13.0
[Bug target/109544] New: implicit declaration of function '__riscv_vsseg4e8_v_i8mf8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109544 Bug ID: 109544 Summary: implicit declaration of function '__riscv_vsseg4e8_v_i8mf8' Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: malat at debian dot org Target Milestone: --- Seems like some intrinsics are missing: $ wget https://raw.githubusercontent.com/riscv-non-isa/rvv-intrinsic-doc/70b1a6ba0959505793bc8d2c3ccea0e2b5402e80/auto-generated/api-testing/vsseg4e8.c Gives: % clang-16 -v -march=rv64gcv1p0 -c vsseg4e8.c Debian clang version 16.0.0 (1~exp5) Target: riscv64-unknown-linux-gnu Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib/gcc/riscv64-linux-gnu/12 Found candidate GCC installation: /usr/bin/../lib/gcc/riscv64-linux-gnu/13 Selected GCC installation: /usr/bin/../lib/gcc/riscv64-linux-gnu/13 (in-process) "/usr/lib/llvm-16/bin/clang" -cc1 -triple riscv64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name vsseg4e8.c -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -target-cpu generic-rv64 -target-feature +m -target-feature +a -target-feature +f -target-feature +d -target-feature +c -target-feature +v -target-feature +zve32f -target-feature +zve32x -target-feature +zve64d -target-feature +zve64f -target-feature +zve64x -target-feature +zvl128b -target-feature +zvl32b -target-feature +zvl64b -target-feature -e -target-feature -h -target-feature -zihintpause -target-feature -zfhmin -target-feature -zfh -target-feature -zfinx -target-feature -zdinx -target-feature -zhinxmin -target-feature -zhinx -target-feature -zba -target-feature -zbb -target-feature -zbc -target-feature -zbs -target-feature -zbkb -target-feature -zbkc -target-feature -zbkx -target-feature -zknd -target-feature -zkne -target-feature -zknh -target-feature -zksed -target-feature -zksh -target-feature -zkr -target-feature -zkn -target-feature -zks -target-feature -zkt -target-feature -zk -target-feature -zmmul -target-feature -zvl256b -target-feature -zvl512b -target-feature -zvl1024b -target-feature -zvl2048b -target-feature -zvl4096b -target-feature -zvl8192b -target-feature -zvl16384b -target-feature -zvl32768b -target-feature -zvl65536b -target-feature -zicbom -target-feature -zicboz -target-feature -zicbop -target-feature -svnapot -target-feature -svpbmt -target-feature -svinval -target-feature -xventanacondops -target-feature -xtheadvdot -target-feature -experimental-zihintntl -target-feature -experimental-zca -target-feature -experimental-zcd -target-feature -experimental-zcf -target-feature -experimental-zvfh -target-feature -experimental-zawrs -target-feature -experimental-ztso -target-feature +relax -target-feature -save-restore -target-abi lp64d -msmall-data-limit 8 -mllvm -treat-scalable-fixed-error-as-warning -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/malat/highway/bin -resource-dir /usr/lib/llvm-16/lib/clang/16 -internal-isystem /usr/lib/llvm-16/lib/clang/16/include -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib/gcc/riscv64-linux-gnu/13/../../../../riscv64-linux-gnu/include -internal-externc-isystem /usr/include/riscv64-linux-gnu -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdebug-compilation-dir=/home/malat/highway/bin -ferror-limit 19 -fno-signed-char -fgnuc-version=4.2.1 -fcolor-diagnostics -faddrsig -o vsseg4e8.o -x c vsseg4e8.c clang -cc1 version 16.0.0 based upon LLVM 16.0.0 default target riscv64-unknown-linux-gnu ignoring nonexistent directory "/usr/bin/../lib/gcc/riscv64-linux-gnu/13/../../../../riscv64-linux-gnu/include" ignoring nonexistent directory "/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/llvm-16/lib/clang/16/include /usr/local/include /usr/include/riscv64-linux-gnu /usr/include End of search list. while: % gcc-13 -v -march=rv64gcv1p0 -c vsseg4e8.c Using built-in specs. COLLECT_GCC=gcc-13 Target: riscv64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 13-20230411-1' --with-bugurl=file:///usr/share/doc/gcc-13/README.Bugs --enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust --prefix=/usr --with-gcc-major-version-only --program-suffix=-13 --program-prefix=riscv64-linux-gnu- --enable-shared --enable-linker-build-id --libexecdir=/usr/libexec --without-included-gettext --enable-threads=posix --libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm --disable-libquadmath --disable-libquadmath-support --enable-plugin --enable-default-pie --wi
[Bug middle-end/109545] New: first_stmt has strange semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109545 Bug ID: 109545 Summary: first_stmt has strange semantics Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: rguenth at gcc dot gnu.org Target Milestone: --- tree-cfg.cc:first_stmt skips debug stmts but not labels which is quite odd and can lead to compare-debug issues. Users are ./tree-cfgcleanup.cc: stmt = first_stmt (dest); ./tree-cfgcleanup.cc: label = first_stmt (dest); ./omp-expand.cc: && first_stmt (store_bb) == store ./tree-vect-slp.cc: if (gcall *first = safe_dyn_cast (first_stmt (bb))) ./gimple-loop-versioning.cc: gimple *stmt = first_stmt (loop->header); ./cp/cp-gimplify.cc:return first_stmt (p->stmt); ./cp/cp-gimplify.cc: return first_stmt (BIND_EXPR_BODY (stmt)); ./cp/cp-gimplify.cc: tree ft = first_stmt (then_); ./cp/cp-gimplify.cc: tree fe = first_stmt (else_); ./tree-cfg.h:extern gimple *first_stmt (basic_block); ./tree-cfg.cc: then_stmt = first_stmt (then_bb); ./tree-cfg.cc: else_stmt = first_stmt (else_bb);
[Bug target/109544] implicit declaration of function '__riscv_vsseg4e8_v_i8mf8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109544 --- Comment #1 from JuzheZhong --- We don't support segment yet since segment load/store api will be changed. For example: The old api: __riscv_vsseg4e8_v_i8mf8(base, vint8mf8_t v0, vint8mf8_t v1, vint8mf8_t v2, vint8mf8_t v3, vl); will be changed into: __riscv_vsseg4e8_v_i8mf8(base, vint8mf8x4_t v0, vl); The latest segment load/store are not merged yet: https://github.com/riscv-non-isa/rvv-intrinsic-doc/pull/198 but will be soon merged. GCC will not implement old api, instead we are implementing latest api recently and they are expected in GCC 14.
[Bug target/109544] implicit declaration of function '__riscv_vsseg4e8_v_i8mf8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109544 Mathieu Malaterre changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Mathieu Malaterre --- ok then. Closing as resolved/invalid then !
[Bug middle-end/108786] bitmap_first_set_bit misses a bitmap_clear_first_bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108786 --- Comment #2 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:f548ece7abc0a0c81dd049e9f8b480ff2c38e18b commit r14-41-gf548ece7abc0a0c81dd049e9f8b480ff2c38e18b Author: Richard Biener Date: Tue Feb 14 16:36:03 2023 +0100 middle-end/108786 - add bitmap_clear_first_set_bit This adds bitmap_clear_first_set_bit and uses it where previously bitmap_clear_bit followed bitmap_first_set_bit. The advantage is speeding up the search and avoiding to clobber ->current. PR middle-end/108786 * bitmap.h (bitmap_clear_first_set_bit): New. * bitmap.cc (bitmap_first_set_bit_worker): Rename from bitmap_first_set_bit and add optional clearing of the bit. (bitmap_first_set_bit): Wrap bitmap_first_set_bit_worker. (bitmap_clear_first_set_bit): Likewise. * df-core.cc (df_worklist_dataflow_doublequeue): Use bitmap_clear_first_set_bit. * graphite-scop-detection.cc (scop_detection::merge_sese): Likewise. * sanopt.cc (sanitize_asan_mark_unpoison): Likewise. (sanitize_asan_mark_poison): Likewise. * tree-cfgcleanup.cc (cleanup_tree_cfg_noloop): Likewise. * tree-into-ssa.cc (rewrite_blocks): Likewise. * tree-ssa-dce.cc (simple_dce_from_worklist): Likewise. * tree-ssa-sccvn.cc (do_rpo_vn_1): Likewise.
[Bug tree-optimization/58359] __builtin_unreachable prevents vectorization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359 Andrew Pinski changed: What|Removed |Added Known to work||12.1.0 Keywords||needs-bisection --- Comment #14 from Andrew Pinski --- Note the original testcase is fixed in GCC 12.1.0. The one in comment #2 is not but I think it is a seperate issue ...
[Bug middle-end/108786] bitmap_first_set_bit misses a bitmap_clear_first_bit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108786 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Richard Biener --- Fixed for GCC 14+
[Bug tree-optimization/109546] New: [13 Regression] Missed Dead Code Elimination when using __builtin_unreachable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109546
Bug ID: 109546
Summary: [13 Regression] Missed Dead Code Elimination when
using __builtin_unreachable
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: theodort at inf dot ethz.ch
Target Milestone: ---
cat input.c
void foo(void);
static int a, c;
static int *b = &a;
static int **d = &b;
void __assert_fail() __attribute__((__noreturn__));
int main() {
int *e = *d;
if (e == &a || e == &c);
else {
__assert_fail();
}
if (e == &a || e == &c);
else
foo();
}
both gcc 12 and trunk at -O3 generate the following code:
main:
movqb(%rip), %rax
cmpq$c, %rax
je .L2
cmpq$a, %rax
jne .L7
.L2:
xorl%eax, %eax
ret
.L7:
pushq %rax
xorl%eax, %eax
call__assert_fail
b:
.quad a
the call to foo is eliminated but the call to __assert_fail is missed, even
though
both if statement conditions are identical.
If add a __builtin_unreachable before the call to __assert_fail the opposite
happens:
void foo(void);
static int a, c;
static int *b = &a;
static int **d = &b;
void assert_fail() __attribute__((__noreturn__));
int main() {
int *e = *d;
if (e == &a || e == &c);
else {
__builtin_unreachable();
assert_fail();
}
if (e == &a || e == &c);
else
foo();
}
gcc-trunk -O3 generates:
main:
movqb(%rip), %rax
cmpq$c, %rax
je .L4
cmpq$a, %rax
je .L4
pushq %rax
callfoo
xorl%eax, %eax
popq%rdx
ret
.L4:
xorl%eax, %eax
ret
b:
.quad a
the call to __assert_fail is now properly eliminated but now the call to foo is
missed.
This is a regression as gcc-12 generates:
main:
xorl%eax, %eax
ret
[Bug target/107674] [11/12/13 Regressions] arm: MVE codegen regressions on VCTP and vector LDR/STR instructions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674 Stam Markianos-Wright changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #5 from Stam Markianos-Wright --- Thanks Richard! I believe this is now fixed. This is likely not applicable for backporting as Andre's changes included some mid-end additions and it's only a missed-optimization regression -- hence closing this ticket.
[Bug middle-end/109545] first_stmt has strange semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109545 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Why? DEBUG_STMTs should never appear before labels.
[Bug fortran/93338] [10/11/12/13/14 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338 --- Comment #12 from Paul Thomas --- This is fixed on current 10- through 13-branches. I don't quite know why it hasn't been closed. Paul
[Bug middle-end/109545] first_stmt has strange semantics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109545 --- Comment #2 from Richard Biener --- Yep, but it will for label: # DEBUG ... _1 = xyz; return 'label'. It surely depends on what the users intend (and we have only very few). Likely the tree-vect-slp.cc case (I've only added recently ...) is wrong in this regard since. It wants first non-label non-debug.
[Bug fortran/93338] [10/11/12/13/14 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:282
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93338 --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #12) > This is fixed on current 10- through 13-branches. > > I don't quite know why it hasn't been closed. It still fails for me at -O1 and higher for 10-branch and 11-branch: % gfc-11 pr93338.f90 -O1 during IPA pass: inline pr93338.f90:10:3: 10 | end | ^ internal compiler error: in make_ssa_name_fn, at tree-ssanames.c:290 0xe0f0d5 make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int) ../../gcc-11/gcc/tree-ssanames.c:287 0xc8dc8e make_ssa_name ../../gcc-11/gcc/tree-ssanames.h:115 0xc8dc8e remap_ssa_name ../../gcc-11/gcc/tree-inline.c:262 0xc90897 copy_tree_body_r(tree_node**, int*, void*) ../../gcc-11/gcc/tree-inline.c:1256 0xeb4505 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc-11/gcc/tree.c:12091 0xeb4b4e walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc-11/gcc/tree.c:12439 0xc8cdec remap_type_1 ../../gcc-11/gcc/tree-inline.c:622 0xc8d0c8 remap_type(tree_node*, copy_body_data*) ../../gcc-11/gcc/tree-inline.c:740 0xc8cc87 remap_type_1 ../../gcc-11/gcc/tree-inline.c:452 0xc8d0c8 remap_type(tree_node*, copy_body_data*) ../../gcc-11/gcc/tree-inline.c:740 0xc8dc7b remap_ssa_name ../../gcc-11/gcc/tree-inline.c:262 0xc9117f remap_gimple_op_r ../../gcc-11/gcc/tree-inline.c:1058 0xeb4505 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*, tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*), void*, hash_set >*)) ../../gcc-11/gcc/tree.c:12091 0x9a5f9d walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*), walk_stmt_info*) ../../gcc-11/gcc/gimple-walk.c:221 0xc8f2ff remap_gimple_stmt ../../gcc-11/gcc/tree-inline.c:1952 0xc916ed copy_bb ../../gcc-11/gcc/tree-inline.c:2022 0xc9319a copy_cfg_body ../../gcc-11/gcc/tree-inline.c:3054 0xc9319a copy_body ../../gcc-11/gcc/tree-inline.c:3309 0xc96164 expand_call_inline ../../gcc-11/gcc/tree-inline.c:5129 0xc977c9 gimple_expand_calls_inline ../../gcc-11/gcc/tree-inline.c:5319 Please submit a full bug report, with preprocessed source if appropriate. So adjust known-to-work/-fail?
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #15 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:b7c54e3f48086c29179f7765a35c381de5109a0a commit r14-43-gb7c54e3f48086c29179f7765a35c381de5109a0a Author: Jonathan Wakely Date: Tue Apr 18 14:37:38 2023 +0100 libstdc++: Export global iostreams with GLIBCXX_3.4.31 symver [PR108969] Since GCC 13 the global iostream objects are only initialized once in libstdc++, and not by a std::ios::Init object in every translation unit that includes . To avoid using uninitialized streams defined in an older libstdc++.so, translation units using the global iostreams should depend on the GLIBCXX_3.4.31 symver. Define std::cin as std::__io::cin and then export it as std::cin@@GLIBCXX_3.4.31 so that references to std::cin bind to the new symver. Also export it as @GLIBCXX_3.4 for backwards compatibility libstdc++-v3/ChangeLog: PR libstdc++/108969 * src/Makefile.am: Move globals_io.cc to here. * src/Makefile.in: Regenerate. * src/c++98/Makefile.am: Remove globals_io.cc from here. * src/c++98/Makefile.in: Regenerate. * src/c++98/globals_io.cc [_GLIBCXX_SYMVER_GNU] (cin): Adjust symbol name and then export with GLIBCXX_3.4.31 symver. (cout, cerr, clog, wcin, wcout, wcerr, wclog): Likewise. * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Regenerate. * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/pre/gnu.ver: Add iostream objects to new symver.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #16 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:762be0646bf96761ce68a9e06ab60c453e0963d0 commit r13-7217-g762be0646bf96761ce68a9e06ab60c453e0963d0 Author: Jonathan Wakely Date: Tue Apr 18 14:37:38 2023 +0100 libstdc++: Export global iostreams with GLIBCXX_3.4.31 symver [PR108969] Since GCC 13 the global iostream objects are only initialized once in libstdc++, and not by a std::ios::Init object in every translation unit that includes . To avoid using uninitialized streams defined in an older libstdc++.so, translation units using the global iostreams should depend on the GLIBCXX_3.4.31 symver. Define std::cin as std::__io::cin and then export it as std::cin@@GLIBCXX_3.4.31 so that references to std::cin bind to the new symver. Also export it as @GLIBCXX_3.4 for backwards compatibility libstdc++-v3/ChangeLog: PR libstdc++/108969 * src/Makefile.am: Move globals_io.cc to here. * src/Makefile.in: Regenerate. * src/c++98/Makefile.am: Remove globals_io.cc from here. * src/c++98/Makefile.in: Regenerate. * src/c++98/globals_io.cc [_GLIBCXX_SYMVER_GNU] (cin): Adjust symbol name and then export with GLIBCXX_3.4.31 symver. (cout, cerr, clog, wcin, wcout, wcerr, wclog): Likewise. * config/abi/post/aarch64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/i486-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/m68k-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/riscv64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/32/baseline_symbols.txt: Regenerate. * config/abi/post/s390x-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/post/x86_64-linux-gnu/baseline_symbols.txt: Regenerate. * config/abi/pre/gnu.ver: Add iostream objects to new symver.
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 Jonathan Wakely changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #17 from Jonathan Wakely --- Fixed for 13.1
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #19 from CVS Commits --- The releases/gcc-13 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:ed933888e680384e1e7af361b20dd484ad424f7d commit r13-7218-ged933888e680384e1e7af361b20dd484ad424f7d Author: Jonathan Wakely Date: Tue Apr 18 17:22:40 2023 +0100 libstdc++: Fix preprocessor condition in linker script [PR108969] The linker script is preprocessed with $(top_builddir)/config.h not the include/$target/bits/c++config.h version, which means that configure macros do not have the _GLIBCXX_ prefix yet. The _GLIBCXX_SYMVER_GNU and _GLIBCXX_SHARED checks are redundant, because the gnu.ver file is only used for _GLIBCXX_SYMVER_GNU and the linker script is only used for the shared library. Remove those. libstdc++-v3/ChangeLog: PR libstdc++/108969 * config/abi/pre/gnu.ver: Fix preprocessor condition. (cherry picked from commit 6067ae4557a3a7e5b08359e78a29b8a9d5dfedce)
[Bug libstdc++/108969] [13/14 Regression] Initializing iostreams in the library needs a GLIBCXX_3.4.31 versioned symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108969 --- Comment #18 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:6067ae4557a3a7e5b08359e78a29b8a9d5dfedce commit r14-46-g6067ae4557a3a7e5b08359e78a29b8a9d5dfedce Author: Jonathan Wakely Date: Tue Apr 18 17:22:40 2023 +0100 libstdc++: Fix preprocessor condition in linker script [PR108969] The linker script is preprocessed with $(top_builddir)/config.h not the include/$target/bits/c++config.h version, which means that configure macros do not have the _GLIBCXX_ prefix yet. The _GLIBCXX_SYMVER_GNU and _GLIBCXX_SHARED checks are redundant, because the gnu.ver file is only used for _GLIBCXX_SYMVER_GNU and the linker script is only used for the shared library. Remove those. libstdc++-v3/ChangeLog: PR libstdc++/108969 * config/abi/pre/gnu.ver: Fix preprocessor condition.
[Bug fortran/82064] [10/11/12/13/14 Regression] [OOP] multiple incompatible definitions of extended derived type via module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82064 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from Paul Thomas --- This seems to have been fixed in the dim and distant past but not closed. GNU Fortran (GCC) 8.3.1 20191027 through the current mainline all produce the two "OK"s and, yes, I did use the separate files. Closing. Paul
[Bug target/94908] Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908
--- Comment #11 from CVS Commits ---
The master branch has been updated by Uros Bizjak :
https://gcc.gnu.org/g:95b99e47f4f2df2d0c5680f45e3ec0a3170218ad
commit r14-47-g95b99e47f4f2df2d0c5680f45e3ec0a3170218ad
Author: Uros Bizjak
Date: Tue Apr 18 17:50:37 2023 +0200
i386: Improve permutations with INSERTPS instruction [PR94908]
INSERTPS can select any element from src and insert into any place
of the dest. For SSE4.1 targets, compiler can generate e.g.
insertps $64, %xmm0, %xmm1
to insert element 1 from %xmm1 to element 0 of %xmm0.
gcc/ChangeLog:
PR target/94908
* config/i386/i386-builtin.def (__builtin_ia32_insertps128):
Use CODE_FOR_sse4_1_insertps_v4sf.
* config/i386/i386-expand.cc (expand_vec_perm_insertps): New.
(expand_vec_perm_1): Call expand_vec_per_insertps.
* config/i386/i386.md ("unspec"): Declare UNSPEC_INSERTPS here.
* config/i386/mmx.md (mmxscalarmode): New mode attribute.
(@sse4_1_insertps_): New insn pattern.
* config/i386/sse.md (@sse4_1_insertps_): Macroize insn
pattern from sse4_1_insertps using VI4F_128 mode iterator.
gcc/testsuite/ChangeLog:
PR target/94908
* gcc.target/i386/pr94908.c: New test.
* gcc.target/i386/sse4_1-insertps-5.c: New test.
* gcc.target/i386/vperm-v4sf-2-sse4.c: New test.
[Bug target/94908] Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908 --- Comment #12 from Uroš Bizjak --- Implemented also for x86.
[Bug c++/108099] [12 Regression] ICE with type alias with `signed __int128_t`
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108099 --- Comment #20 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:32955c1c2246aa336d3fd2423c32546c39a6ca30 commit r12-9429-g32955c1c2246aa336d3fd2423c32546c39a6ca30 Author: Jason Merrill Date: Thu Mar 9 17:35:24 2023 -0500 c++: signed __int128_t [PR108099] The code for handling signed + typedef was breaking on __int128_t, because it isn't a proper typedef: it doesn't have DECL_ORIGINAL_TYPE. PR c++/108099 gcc/cp/ChangeLog: * decl.cc (grokdeclarator): Handle non-typedef typedef_decl. gcc/testsuite/ChangeLog: * g++.dg/ext/int128-7.C: New test.
[Bug debug/107154] [12 Regression] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 --- Comment #5 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2088358b658c44f69d37af0d7deec321f557741d commit r12-9430-g2088358b658c44f69d37af0d7deec321f557741d Author: Jason Merrill Date: Tue Oct 4 17:06:04 2022 -0400 c++: fix debug info for array temporary [PR107154] In the testcase the elaboration of the array init that happens at genericize time was getting the location info for the end of the function; fixed by doing the expansion at the location of the original expression. PR c++/107154 gcc/cp/ChangeLog: * cp-gimplify.cc (cp_genericize_init_expr): Use iloc_sentinel. (cp_genericize_target_expr): Likewise. gcc/testsuite/ChangeLog: * g++.dg/debug/dwarf2/lineno-array1.C: New test.
[Bug c++/108468] [11/12 Regression] ICE in most_specialized_partial_spec/builtin_guide_p in C++20 mode
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108468 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:b210f028ee9dd55bfd9f60ccfc2c015f73dbe930 commit r12-9433-gb210f028ee9dd55bfd9f60ccfc2c015f73dbe930 Author: Jason Merrill Date: Tue Mar 14 16:32:31 2023 -0400 c++: variable tmpl partial specialization [PR108468] Generally we expect TPARMS_PRIMARY_TEMPLATE to be set, but sometimes it isn't for partial instantiations. This ought to be improved, but it's trivial to work around it in this case. PR c++/108468 gcc/cp/ChangeLog: * pt.cc (unify_pack_expansion): Check that TPARMS_PRIMARY_TEMPLATE is non-null. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ78.C: New test.
[Bug c++/98056] coroutines: ICE tree check: expected record_type or union_type or qual_union_type, have array_type since r11-2183-g0f66b8486cea8668
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056 --- Comment #23 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1da2d99c632a90e5af55c8f8db1c11af587bb0a0 commit r12-9434-g1da2d99c632a90e5af55c8f8db1c11af587bb0a0 Author: Jason Merrill Date: Wed Mar 15 16:33:37 2023 -0400 c++: co_await and initializer_list [PR103871] When flatten_await_stmt processes the backing array for an initializer_list, we call cp_build_modify_expr to initialize the promoted variable from the TARGET_EXPR; that needs to be accepted. PR c++/103871 PR c++/98056 gcc/cp/ChangeLog: * typeck.cc (cp_build_modify_expr): Allow array initialization of DECL_ARTIFICIAL variable. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-initlist1.C: New test.
[Bug c++/108566] [11/12 Regression] ICE: tree check: expected tree that contains 'decl with visibility' structure, have 'field_decl' in write_unqualified_name with anonymous struct inside an anonymous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108566 --- Comment #8 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:f483dc1367294d02581e2d98c5f84be4dd67f26b commit r12-9431-gf483dc1367294d02581e2d98c5f84be4dd67f26b Author: Jason Merrill Date: Thu Mar 9 23:33:43 2023 -0500 c++: class NTTP and nested anon union [PR108566] We were failing to come up with the name for the anonymous union. It seems like unfortunate redundancy, but the ABI does say that the name of an anonymous union is its first named member. PR c++/108566 gcc/cp/ChangeLog: * mangle.cc (anon_aggr_naming_decl): New. (write_unqualified_name): Use it. gcc/testsuite/ChangeLog: * g++.dg/abi/anon6.C: New test.
[Bug c++/107310] [12 Regression] "warning: control reaches end of non-void function" with a throw under a trivially-true conditional since r12-5638-ga3e75c1491cd2d50
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107310 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:0f6d443f0d0dd8a6bab99ab1957df3cd82541b27 commit r12-9432-g0f6d443f0d0dd8a6bab99ab1957df3cd82541b27 Author: Jason Merrill Date: Tue Mar 14 12:20:51 2023 -0400 c++: -Wreturn-type with if (true) throw [PR107310] I removed this folding in GCC 12 because it was interfering with an experiment of richi's, but that never went in and the change causes regressions, so let's put it back. This reverts commit r12-5638-ga3e75c1491cd2d. PR c++/107310 gcc/cp/ChangeLog: * cp-gimplify.cc (genericize_if_stmt): Restore folding of constant conditions. gcc/testsuite/ChangeLog: * c-c++-common/Wimplicit-fallthrough-39.c: Adjust warning. * g++.dg/warn/Wreturn-6.C: New test.
[Bug c++/103871] [11/12 Regression] coroutines: co_await causes build error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103871 --- Comment #20 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:1da2d99c632a90e5af55c8f8db1c11af587bb0a0 commit r12-9434-g1da2d99c632a90e5af55c8f8db1c11af587bb0a0 Author: Jason Merrill Date: Wed Mar 15 16:33:37 2023 -0400 c++: co_await and initializer_list [PR103871] When flatten_await_stmt processes the backing array for an initializer_list, we call cp_build_modify_expr to initialize the promoted variable from the TARGET_EXPR; that needs to be accepted. PR c++/103871 PR c++/98056 gcc/cp/ChangeLog: * typeck.cc (cp_build_modify_expr): Allow array initialization of DECL_ARTIFICIAL variable. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-initlist1.C: New test.
[Bug c++/101869] [10/11/12 Regression] &enumclass::enumvalue is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101869 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:2f9bb63c5e82512ba9e53f4d5e67949c100d8830 commit r12-9436-g2f9bb63c5e82512ba9e53f4d5e67949c100d8830 Author: Jason Merrill Date: Thu Mar 16 13:11:32 2023 -0400 c++: &enum::enumerator [PR101869] We don't want to call build_offset_ref with an enum. PR c++/101869 gcc/cp/ChangeLog: * semantics.cc (finish_qualified_id_expr): Don't try to build a pointer-to-member if the scope is an enumeration. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/enum43.C: New test.
[Bug c++/108975] [10/11/12 Regression] ICE on constexpr variable used as nontype template since r9-5473-ge32fc4499f863f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108975 --- Comment #14 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:55ab4606ab1084a55d53184c5cf4543740a7f65d commit r12-9440-g55ab4606ab1084a55d53184c5cf4543740a7f65d Author: Jason Merrill Date: Fri Mar 17 17:26:40 2023 -0400 c++: constant, array, lambda, template [PR108975] When a lambda refers to a constant local variable in the enclosing scope, we tentatively capture it, but if we end up pulling out its constant value, we go back at the end of the lambda and prune any unneeded captures. Here while parsing the template we decided that the dim capture was unneeded, because we folded it away, but then we brought back the use in the template trees that try to preserve the source representation with added type info. So then when we tried to instantiate that use, we couldn't find what it was trying to use, and crashed. Fixed by not trying to prune when parsing a template; we'll prune at instantiation time. PR c++/108975 gcc/cp/ChangeLog: * lambda.cc (prune_lambda_captures): Don't bother in a template. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-const11.C: New test.
[Bug c++/105809] [10/11/12 Regression] __PRETTY_FUNCTION__ in constexpr in function vs NSDMI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105809 --- Comment #7 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:dbd8af5d8f4568ed5683ae8aa15ccb330bbf74c0 commit r12-9438-gdbd8af5d8f4568ed5683ae8aa15ccb330bbf74c0 Author: Jason Merrill Date: Thu Mar 16 15:35:15 2023 -0400 c++: __func__ and local class DMI [PR105809] As in 108242, we need to instantiate in the context of the enclosing function, not after it's gone. PR c++/105809 gcc/cp/ChangeLog: * init.cc (get_nsdmi): Split out... (maybe_instantiate_nsdmi_init): ...this function. * cp-tree.h: Declare it. * pt.cc (tsubst_expr): Use it. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-__func__3.C: New test.
[Bug c++/105406] [11/12 Regression] coroutines: since 11.3 co_await attempts to copy a move-only value when await_transform(T &) exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105406 --- Comment #4 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:6fd32842404ac1a3cd98189f61d93c5bc9c8680c commit r12-9435-g6fd32842404ac1a3cd98189f61d93c5bc9c8680c Author: Jason Merrill Date: Wed Mar 15 17:02:15 2023 -0400 c++: co_await and move-only type [PR105406] Here we were building a temporary MoveOnlyAwaitable to hold the result of evaluating 'o', but since 'o' is an lvalue we should build a reference instead. PR c++/105406 gcc/cp/ChangeLog: * coroutines.cc (build_co_await): Handle lvalue 'o'. gcc/testsuite/ChangeLog: * g++.dg/coroutines/co-await-moveonly1.C: New test.
[Bug c++/108242] [10/11/12 Regression] '__FUNCTION__' was not declared when used inside a generic (templated) lambda declared inside a template function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108242 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:890d711a2477119a34cf435f6159b6253b124374 commit r12-9437-g890d711a2477119a34cf435f6159b6253b124374 Author: Jason Merrill Date: Thu Mar 16 15:11:25 2023 -0400 c++: generic lambda, local class, __func__ [PR108242] Here we are trying to do name lookup in a deferred instantiation of t() and failing to find __func__. tsubst_expr already tries to instantiate members of local classes, but was failing with the partial instantiation of generic lambdas. PR c++/108242 gcc/cp/ChangeLog: * pt.cc (tsubst_expr) [TAG_DEFN]: Handle partial instantiation. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/lambda-generic-func2.C: New test.
[Bug c++/109357] [12 Regression] internal compiler error in cp/constexpr.cc:1685
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109357 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #3 from Jason Merrill --- Fixed for 12.3/13.
[Bug c++/69410] [10/11/12 Regression] friend declarations in local classes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69410 --- Comment #13 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:615c48b317397c2dc3d6769954d5c399ea882f7a commit r12-9439-g615c48b317397c2dc3d6769954d5c399ea882f7a Author: Jason Merrill Date: Fri Mar 17 09:43:48 2023 -0400 c++: namespace-scoped friend in local class [PR69410] do_friend was only considering class-qualified identifiers for the qualified-id case, but we also need to skip local scope when there's an explicit namespace scope. PR c++/69410 gcc/cp/ChangeLog: * friend.cc (do_friend): Handle namespace as scope argument. * decl.cc (grokdeclarator): Pass down in_namespace. gcc/testsuite/ChangeLog: * g++.dg/lookup/friend24.C: New test.
[Bug debug/107154] [12 Regression] GDB jumping to end of block when stepping over construction of local variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107154 Jason Merrill changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from Jason Merrill --- Fixed for 12.3/13.
[Bug c++/106890] [10/11/12 Regression] virtual inheritance triggers compiler error when instatiating derived class with in-class initialization since r8-2709-g12659e10c7820071
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106890 --- Comment #3 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:94569d91bd4c604da755b4aae84256e7fe21196a commit r12-9441-g94569d91bd4c604da755b4aae84256e7fe21196a Author: Jason Merrill Date: Sat Mar 18 08:27:26 2023 -0400 c++: DMI in template with virtual base [PR106890] When parsing a default member init we just build a CONVERT_EXPR for converting to a virtual base, and then expand that into the more complex form when we actually use the DMI in a constructor. But that wasn't working for the template case where we are considering the conversion at the point that the constructor needs the DMI instantiation, so it seemed like we were in a constructor already. And then when the other constructor tries to reuse the instantiation, it sees uses of the first constructor's parameters, and dies. So ensure that we get the CONVERT_EXPR in this case, too. PR c++/106890 gcc/cp/ChangeLog: * init.cc (maybe_instantiate_nsdmi_init): Don't leave current_function_decl set to a constructor. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template25.C: New test.
[Bug c++/105481] [10/11/12 Regression] ICE: unexpected expression of kind template_parm_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105481 --- Comment #9 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:ab7c0a44ca9e913af654ae82963565d61d8bb39f commit r12-9443-gab7c0a44ca9e913af654ae82963565d61d8bb39f Author: Jason Merrill Date: Thu Mar 23 18:20:52 2023 -0400 c++: default template arg, partial ordering [PR105481] The default argument code in type_unification_real was assuming that all targs we've deduced by that point are non-dependent, but that's not the case for partial ordering. PR c++/105481 gcc/cp/ChangeLog: * pt.cc (type_unification_real): Adjust for partial ordering. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/fntmpdefarg-partial1.C: New test.
[Bug c++/105996] [10/11/12 Regression] reinterpret_cast in constexpr failure creating a pair with a function pointer of class parent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105996 --- Comment #6 from CVS Commits --- The releases/gcc-12 branch has been updated by Jason Merrill : https://gcc.gnu.org/g:12d7fb7e5810cc5e394d3cbea43d1b19ea7f9348 commit r12-9442-g12d7fb7e5810cc5e394d3cbea43d1b19ea7f9348 Author: Jason Merrill Date: Thu Mar 23 16:50:09 2023 -0400 c++: constexpr PMF conversion [PR105996] Here, we were calling build_reinterpret_cast regardless of whether there was actually a cast, and that now sets REINTERPRET_CAST_P. But that optimization seems dodgy anyway, as it involves NOP_EXPR from one RECORD_TYPE to another and we try to reserve NOP_EXPR for fundamental types. And the generated code seems the same, so let's drop it. And also strip location wrappers. PR c++/105996 gcc/cp/ChangeLog: * typeck.cc (build_ptrmemfunc): Drop 0-offset optimization and location wrappers. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/constexpr-pmf3.C: New test.
