[Bug target/113871] psrlq is not used for PERM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113871 Uroš Bizjak changed: What|Removed |Added Attachment #57417|0 |1 is obsolete|| --- Comment #5 from Uroš Bizjak --- Created attachment 57419 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57419&action=edit Proposed v2 patch New version in testing, also handles 32-bit vectors.
[Bug fortran/113917] New: ice in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113917 Bug ID: 113917 Summary: ice in gfc_class_vptr_get Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Target Milestone: --- Created attachment 57420 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57420&action=edit F90 source code >From the flang test suite at https://github.com/llvm/llvm-project/tree/main/flang/test the file ./Lower/HLFIR/elemental-array-ops.f90 does this: test $ ~/gcc/results/bin/gfortran -c -w ./Lower/HLFIR/elemental-array-ops.f90 ./Lower/HLFIR/elemental-array-ops.f90:247:9: 247 | x = (y) | 1 internal compiler error: Segmentation fault 0xf58d89 crash_signal(int) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/toplev.cc:317 0x87ade1 gfc_class_vptr_get(tree_node*) /home/dcb38/gcc/working/gcc/../../trunk.20210101/gcc/fortran/trans-expr.cc:247 0x8944ea trans_class_vptr_len_assignment(stmtblock_t*, gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) with recent gfortran. The problem seems to exist since sometime before 2024016.
[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #16 from rguenther at suse dot de ---
On Tue, 13 Feb 2024, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
>
> --- Comment #15 from Jan Hubicka ---
> >
> > IVOPTs does the above but it does it (or should) as
> >
> > offset = (uintptr)&base2 - (uintptr)&base1;
> > val = *((T *)((uintptr)base1 + i + offset))
> >
> > which is OK for points-to as no POINTER_PLUS_EXPR is involved so the
> > resulting pointer points to both base1 and base2 (which isn't optimal
> > but correct).
> >
> > If we somehow get back a POINTER_PLUS that's where things go wrong.
> >
> > Doing the above in C code would be valid input so we have to treat
> > it correctly (OK, the standard only allows back-and-forth
> > pointer-to-integer casts w/o any adjustment, but of course we relax
> > this).
>
> OK. Modrefs tracks base pointer for accesses and tries to prove that
> they are function parameters. This should immitate ivopts:
> void
> __attribute__ ((noinline))
> set(int *a, unsigned long off)
> {
> *(int *)((unsigned long)a + off) = 1;
> }
> int
> test ()
> {
> int a;
> int b = 0;
> set (&a, (unsigned long)&b - (unsigned long)&a);
> return b;
> }
>
> Here set gets following gimple at modref2 time:
> __attribute__((noinline))
> void set (int * a, long unsigned int off)
> {
> long unsigned int a.0_1;
> long unsigned int _2;
> int * _3;
>
>[local count: 1073741824]:
> a.0_1 = (long unsigned int) a_4(D);
> _2 = a.0_1 + off_5(D);
> _3 = (int *) _2;
> *_3 = 1;
> return;
>
> }
>
> This is not pattern matched so modref does not think the access has a as
> a base:
>
> stores:
> Base 0: alias set 1
> Ref 0: alias set 1
> Every access
>
> While for:
>
> void
> __attribute__ ((noinline))
> set(int *a, unsigned long off)
> {
> *(a+off/sizeof(int))=1;
> }
>
> we produce:
>
> __attribute__((noinline))
> void set (int * a, long unsigned int off)
> {
> sizetype _1;
> int * _2;
>
>[local count: 1073741824]:
> _1 = off_3(D) & 18446744073709551612;
> _2 = a_4(D) + _1;
> *_2 = 1;
> return;
> }
>
> And this is understood:
>
> stores:
> Base 0: alias set 1
> Ref 0: alias set 1
> access: Parm 0
>
> If we consider it correct to optimize out the conversion from and to
> pointer type, then I suppose any addition of pointer and integer which
> we do not see means that we need to give up on tracking base completely.
>
> I guess PTA gets around by tracking points-to set also for non-pointer
> types and consequently it also gives up on any such addition.
>
> But what we really get from relaxing this?
> >
> > IVOPTs then in putting all of the stuff into 'offset' gets at
> > trying a TARGET_MEM_REF based on a NULL base but that's invalid.
> > We then resort to a LEA (ADDR_EXPR of TARGET_MEM_REF) to compute
> > the address which gets us into some phishy argument that it's
> > not valid to decompose ADDR_EXPR of TARGET_MEM_REF to
> > POINTER_PLUS of the TARGET_MEM_REF base and the offset. But
> > that's how it is (points-to treats (address of) TARGET_MEM_REF
> > as pointing to anything ...).
> >
> > > A quick fix would be to run IPA modref before ivopts, but I do not see
> > > how such
> > > transformation can work with rest of alias analysis (PTA etc)
> >
> > It does. Somewhere IPA modref interprets things wrongly, I didn't figure
> > out here though.
>
>
> I guess PTA gets around by tracking points-to set also for non-pointer
> types and consequently it also gives up on any such addition.
It does. But note it does _not_ for POINTER_PLUS where it treats
the offset operand as non-pointer.
> I think it is ipa-prop.c::unadjusted_ptr_and_unit_offset. It accepts
> pointer_plus expression, but does not look through POINTER_PLUS.
> We can restrict it further, but tracking base pointer is quite useful,
> so it would be nice to not give up completely.
It looks like that function might treat that
ADDR_EXPR >
as integer_zerop base. It does
if (TREE_CODE (op) == ADDR_EXPR)
{
poly_int64 extra_offset = 0;
tree base = get_addr_base_and_unit_offset (TREE_OPERAND (op, 0),
&offset);
if (!base)
{
base = get_base_address (TREE_OPERAND (op, 0));
if (TREE_CODE (base) != MEM_REF)
break;
offset_known = false;
}
else
{
if (TREE_CODE (base) != MEM_REF)
break;
with a variable offset we fall to the TREE_CODE (base) != MEM_REF
and will have offset_known == true. Not sure what it does with
the result though (it's not the address of a decl).
This function seems to oddly special-case != MEM_REF ... (maybe
it wants to hande DECL_P () as finishing?
Note get_addr_base_and_unit_offset will return NULL for
a TARGET_MEM_REF <&de
[Bug rtl-optimization/113617] [14 Regression] Symbol ... referenced in section `.data.rel.ro.local' of ...: defined in discarded section ... since r14-4944
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113617 --- Comment #16 from Jakub Jelinek --- It is waiting for review https://gcc.gnu.org/pipermail/gcc-patches/2024-January/644580.html
[Bug fortran/113917] ice in gfc_class_vptr_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113917 --- Comment #1 from David Binderman --- (In reply to David Binderman from comment #0) >The problem seems to exist since sometime before 2024016. That should be 20240116.
[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706 --- Comment #8 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:ab0c2c367a87b03f38a486a118b89335837619dc commit r14-8971-gab0c2c367a87b03f38a486a118b89335837619dc Author: Rainer Orth Date: Wed Feb 14 09:25:03 2024 +0100 testsuite: xfail c-c++-common/pr103798-2.c for C++ on Solaris [PR113706] c-c++-common/pr103798-2.c FAILs on Solaris when compiled as C++: FAIL: c-c++-common/pr103798-2.c -std=gnu++14 scan-assembler-not memchr FAIL: c-c++-common/pr103798-2.c -std=gnu++17 scan-assembler-not memchr FAIL: c-c++-common/pr103798-2.c -std=gnu++20 scan-assembler-not memchr FAIL: c-c++-common/pr103798-2.c -std=gnu++98 scan-assembler-not memchr As Jason analyzed, Solaris declares memchr for C++ as returning const void * as specified by the C++ standard, while gcc expects the return type to be void * like in C. So this patch xfails the test for C++ on Solaris. Tested on sparc-sun-solaris2.11 and x86_64-pc-linux-gnu. 2024-02-12 Rainer Orth gcc/testsuite: PR c++/113706 * c-c++-common/pr103798-2.c (scan-assembler-not): xfail for C++ on Solaris.
[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706 --- Comment #9 from Rainer Orth --- xfailed for GCC 14.0.1. Keep PR open for the underlying bug.
[Bug libstdc++/113841] Can't swap two std::hash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113841 --- Comment #9 from Viktor Ostashevskyi --- (In reply to Jonathan Wakely from comment #8) > Calling swap unqualified performs ADL, which has to find all the associated > namespaces and associated classes. To do that it has to complete all the > types involved, which means it tries to complete: > std::hash*> > std::pair > MyArrVec > MyVec > MyAllocator > > Trying to complete MyVec hits an error outside the immediate context, > because its default constructor cannot be instantiated, because > MyAllocator is not default constructible. > > That's why comment 5 fixes it. Thanks a lot for such a deep explanation. We applied patch from comment #5 to gcc-13 and now clang-17 can compile our application using libstdc++. Any plans to apply the patch to gcc-12/gcc-13/gcc-14/trunk?
[Bug middle-end/113694] Allow renaming stack smashing protector symbols
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113694 --- Comment #4 from Matheus Afonso Martins Moreira --- (In reply to Sam James from comment #3) > Note that this isn't something GCC offers for other things, e.g. PR97119. GCC does offer it for at least one thing that I'm aware of: -e entry --entry=entry Specify that the program entry point is entry. The argument is interpreted by the linker; the GNU linker accepts either a symbol name or an address. With this useful option, I was able to change the somewhat ugly "_start" symbol to a name of my choosing.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #25 from Jakub Jelinek --- So, to sum up what has been discussed on IRC, LTO streaming doesn't seem to stream SSA_NAME_INFO, only the final IPA phases of say IPA-VRP can set SSA_NAME_INFO. Thus, this bug is most likely solely about -fno-lto behavior of IPA-ICF. Supposedly there we can change the SSA_NAME_INFO upon final decision to merge two functions. I'd say it is in sem_function::merge above if (redirect_callers). And guard with !flag_wpa (or for flag_wpa assert all SSA_NAME_INFO is NULL). Except that by the time sem_function::merge is called, m_checker with its mapping between SSA_NAME_VERSION is unfortunately gone, so we'd need to preserve it somewhere.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 --- Comment #26 from Richard Biener --- (In reply to Jakub Jelinek from comment #25) > So, to sum up what has been discussed on IRC, LTO streaming doesn't seem to > stream SSA_NAME_INFO, only the final IPA phases of say IPA-VRP can set > SSA_NAME_INFO. > Thus, this bug is most likely solely about -fno-lto behavior of IPA-ICF. > > Supposedly there we can change the SSA_NAME_INFO upon final decision to > merge two functions. I'd say it is in sem_function::merge above if > (redirect_callers). > And guard with !flag_wpa (or for flag_wpa assert all SSA_NAME_INFO is NULL). > > Except that by the time sem_function::merge is called, m_checker with its > mapping between SSA_NAME_VERSION is unfortunately gone, so we'd need to > preserve it somewhere. Or go and throw away all ranges from the final merge target?
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-02-14 Status|UNCONFIRMED |NEW Keywords||needs-bisection Ever confirmed|0 |1 --- Comment #6 from Richard Biener --- tree PTA :1795.76 ( 91%) "nice". Possibly some of the PTA speedups done have regressed this case. Bisecting would be nice. It seems the preprocessed source "works" on x86_64 as well at least, for both trunk and GCC 11 (and I confirm 11 is fast). It might be that inlining heuristic changes make a difference here. PTA is known to have difficulties with functions with very many calls.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 Richard Biener changed: What|Removed |Added Target|sparcv9-sun-solaris2.11 |sparcv9-sun-solaris2.11, ||x86_64-*-* Target Milestone|--- |12.4 Priority|P3 |P2
[Bug debug/113918] New: Incomplete DWARF5 debug information for anonymous unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113918 Bug ID: 113918 Summary: Incomplete DWARF5 debug information for anonymous unions Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: tsqurt at outlook dot com Target Milestone: --- Created attachment 57421 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57421&action=edit example.c This is an academic finding and may not be a serious bug that urgently needs to be fixed. Fixing it may help improve the user's debugging experience. According to Programming languages — C, ISO/IEC9899:2017, Chapter 6, Section 7.2.1.13, the members of an anonymous structure or union are considered to be members of the containing structure or union. However, this feature does not seem to be reflected directly in the debug information. To check this problem, I use gcc-13.2.0 on Ubuntu 20.04.6 LTS, with the source code example.c attached. $gcc -o a.elf -std=c17 -gdwarf-5 --pedantic example.c $objdump -g a.elf ... <1><2e>: Abbrev Number: 2 (DW_TAG_union_type) <2f> DW_AT_byte_size : 4 <30> DW_AT_decl_file : 1 <31> DW_AT_decl_line : 4 <32> DW_AT_decl_column : 5 <33> DW_AT_sibling : <0x42> ... According to DWARF Debugging Information Format Version 5, Chapter 5, Section 7.1, this union type declared in ‘A’ should have a DW_AT_export_symbols attribute which indicates that member ‘x’ may be referenced as if ‘x’ is a member of ‘A’. To confirm that this issue is indeed a bug, I use GNU gdb (Ubuntu 9.2-0ubuntu1~20.04.1) 9.2, and start with shell command `gdb a.elf`. $(gdb) b main Breakpoint 1 at 0x40110a: file example.c, line 12. $(gdb) run Starting program: a.elf Breakpoint 1, main () at example.c:12 $(gdb) expr x.z=20 $(gdb) expr x.y=20 gdb command line:1:2: error: ‘’ has no member named ‘y’ Compilation failed. In comparison, member ‘z’ does not share this problem. This behavior is inconsistent with the C17 standard. I'm not sure if this problem should be down to DWARF5, gdb or gcc, but I think gcc should be capable to address this issue. Discussion: GCC has specified that the language is C17, so the debugger can deduce that ‘y’ is a member of ‘A’. But in DWARF5, debugging information is language-independent, so the debugger may not be responsible to make the above deduction based on the language C17. GCC should either generate a DW_AT_export_symbols attribute for the anonymous union or a descendant node for ‘A’. I do not know whether this is a bug or a feature. Please confirm this problem.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910
--- Comment #7 from Richard Biener ---
Note GCC 13 seems to dislike the preprocessed source (odd, 12 and trunk are
happy...)
In file included from /usr/gcc/11/include/c++/11.4.0/memory:76,
from
/vol/llvm/src/llvm-project/local/llvm/include/llvm/ADT/SmallVector.h:28,
from
/vol/llvm/src/llvm-project/local/llvm/include/llvm/ADT/SmallString.h:17,
from
/vol/llvm/src/llvm-project/local/llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.h:19,
from
/vol/llvm/src/llvm-project/local/llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp:19:
/usr/gcc/11/include/c++/11.4.0/bits/unique_ptr.h:486:8: error: expected
identifier before '__remove_cv'
/usr/gcc/11/include/c++/11.4.0/bits/unique_ptr.h:486:20: error: expected '('
before '=' token
/usr/gcc/11/include/c++/11.4.0/bits/unique_ptr.h:486:20: error: expected
type-specifier before '=' token
/usr/gcc/11/include/c++/11.4.0/bits/unique_ptr.h:486:20: error: expected
unqualified-id before '=' token
/usr/gcc/11/include/c++/11.4.0/bits/unique_ptr.h:492:55: error: wrong number of
template arguments (1, should be 2)
that's
using __remove_cv = typename remove_cv<_Up>::type;
template
using __is_derived_Tp
= __and_< is_base_of<_Tp, _Up>,
__not_, __remove_cv<_Up>>> >;
I think.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #27 from Jakub Jelinek ---
So:
--- gcc/ipa-icf.cc.jj 2024-02-10 11:25:09.645478952 +0100
+++ gcc/ipa-icf.cc 2024-02-14 10:44:27.906216458 +0100
@@ -1244,6 +1244,29 @@ sem_function::merge (sem_item *alias_ite
else
create_alias = true;
+ unsigned i;
+ tree name;
+ FOR_EACH_SSA_NAME (i, name, original->get_fun ())
+{
+ /* We need to either merge or reset SSA_NAME_*_INFO.
+For merging we don't preserve the mapping between
+original and alias SSA_NAMEs from successful equals
+calls. */
+ if (POINTER_TYPE_P (TREE_TYPE (name)))
+{
+ if (SSA_NAME_PTR_INFO (name))
+ {
+ gcc_assert (!flag_wpa);
+ SSA_NAME_PTR_INFO (name) = NULL;
+ }
+}
+ else if (SSA_NAME_RANGE_INFO (name))
+ {
+ gcc_assert (!flag_wpa);
+ SSA_NAME_RANGE_INFO (name) = NULL;
+ }
+}
+
if (redirect_callers)
{
int nredirected = redirect_all_callers (alias, local_original);
then? For the merging, I guess we'd need to move one of the 2 vec vectors
from m_checker to the sem_function instead of throwing it away in
sem_function::equals
if returning true.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 Richard Biener changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from Richard Biener --- early PTA for decodeToMCInst runs on 241782 variables, and we have 751952 constraints. A fun testcase ;) A little bit large to work with of course.
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 Richard Biener changed: What|Removed |Added Priority|P3 |P1
[Bug debug/113918] Incomplete DWARF5 debug information for anonymous unions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113918 Richard Biener changed: What|Removed |Added Last reconfirmed||2024-02-14 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Richard Biener --- Confirmed at least for the user side.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #9 from Richard Biener --- With only enabling early PTA via -fdisable-tree-alias -fdisable-tree-pre I got the compile finished in 18 minutes and tree PTA :1044.48 ( 98%) 1.53 ( 27%)1046.29 ( 97%) 4341k ( 0%)
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #28 from rguenther at suse dot de ---
On Wed, 14 Feb 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
>
> --- Comment #27 from Jakub Jelinek ---
> So:
> --- gcc/ipa-icf.cc.jj 2024-02-10 11:25:09.645478952 +0100
> +++ gcc/ipa-icf.cc 2024-02-14 10:44:27.906216458 +0100
> @@ -1244,6 +1244,29 @@ sem_function::merge (sem_item *alias_ite
>else
> create_alias = true;
>
> + unsigned i;
> + tree name;
> + FOR_EACH_SSA_NAME (i, name, original->get_fun ())
> +{
> + /* We need to either merge or reset SSA_NAME_*_INFO.
> +For merging we don't preserve the mapping between
> +original and alias SSA_NAMEs from successful equals
> +calls. */
> + if (POINTER_TYPE_P (TREE_TYPE (name)))
> +{
> + if (SSA_NAME_PTR_INFO (name))
> + {
> + gcc_assert (!flag_wpa);
> + SSA_NAME_PTR_INFO (name) = NULL;
> + }
> +}
> + else if (SSA_NAME_RANGE_INFO (name))
> + {
> + gcc_assert (!flag_wpa);
> + SSA_NAME_RANGE_INFO (name) = NULL;
> + }
> +}
> +
>if (redirect_callers)
> {
>int nredirected = redirect_all_callers (alias, local_original);
> then?
Yeah, though can't we do this in the caller and thus only once for the
target when we merge more than 2 nodes?
For the merging, I guess we'd need to move one of the 2 vec vectors
> from m_checker to the sem_function instead of throwing it away in
> sem_function::equals
> if returning true.
It might require quite some amount of memory though when N is big,
I'm not sure it's worth it?
[Bug target/113909] gcc.target/i386/pr113689-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909 --- Comment #2 from GCC Commits --- The master branch has been updated by Rainer Orth : https://gcc.gnu.org/g:d79aa77d9b2fe757b1bbda45defd4ac02b077a78 commit r14-8973-gd79aa77d9b2fe757b1bbda45defd4ac02b077a78 Author: Rainer Orth Date: Wed Feb 14 11:39:12 2024 +0100 testsuite: i386: Skip gcc.target/i386/pr113689-1.c etc. on Solaris [PR113909] gcc.target/i386/pr113689-[1-3].c FAIL on 64-bit Solaris/x86: FAIL: gcc.target/i386/pr113689-1.c (test for excess errors) UNRESOLVED: gcc.target/i386/pr113689-1.c compilation failed to produce executable FAIL: gcc.target/i386/pr113689-2.c (test for excess errors) UNRESOLVED: gcc.target/i386/pr113689-2.c compilation failed to produce executable FAIL: gcc.target/i386/pr113689-3.c (test for excess errors) UNRESOLVED: gcc.target/i386/pr113689-3.c compilation failed to produce executable with Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-1.c:43:1: sorry, unimplemented: no register available for profiling '-mcmodel=large' Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-2.c:26:1: sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported Excess errors: /vol/gcc/src/hg/master/local/gcc/testsuite/gcc.target/i386/pr113689-3.c:15:1: sorry, unimplemented: profiling '-mcmodel=large' with PIC is not supported This happens because i386/sol2.h doesn't define NO_PROFILE_COUNTERS. So this patch just skips the tests on Solaris. Tested on i386-pc-solaris2.11. 2024-02-13 Rainer Orth gcc/testsuite: PR target/113909 * gcc.target/i386/pr113689-1.c: Skip on Solaris. * gcc.target/i386/pr113689-2.c: Likewise. * gcc.target/i386/pr113689-3.c: Likewise.
[Bug target/113909] gcc.target/i386/pr113689-1.c etc. FAIL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113909 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Assignee|unassigned at gcc dot gnu.org |ro at gcc dot gnu.org Resolution|--- |FIXED URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Februar ||y/645546.html --- Comment #3 from Rainer Orth --- Mine. Fixed for GCC 14.0.1.
[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739 Rainer Orth changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2024-Februar ||y/645547.html --- Comment #9 from Rainer Orth --- Patch now posted for real.
[Bug target/113915] [14 regression] glibc's _dl_find_object_update_1 miscompiled for armv7a since r14-4365-g0731889c026bfe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113915 Wilco changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |wilco at gcc dot gnu.org --- Comment #11 from Wilco --- Yes the default for "conds" attribute is incorrect and at odds with the "predicable" attribute. The fix should work but will disable conditional execution on a few ARM-only patterns that just have "conds" attribute. Any shared patterns will be OK since they already need to set "predicable" for Thumb-2.
[Bug c++/99573] ICE in module: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in start_enum, at cp/decl.c:15663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99573 --- Comment #3 from GCC Commits --- The master branch has been updated by Nathaniel Shead : https://gcc.gnu.org/g:bbb30f12a7e5ce008f59ec26c9e4cc65ee79fe56 commit r14-8974-gbbb30f12a7e5ce008f59ec26c9e4cc65ee79fe56 Author: Nathaniel Shead Date: Mon Feb 12 12:40:15 2024 +1100 c++: Fix error recovery when redeclaring enum in different module [PR99573] This ensures that with modules enabled, redeclaring an enum in the wrong module or with the wrong underlying type no longer ICEs. The patch also rearranges the order of the checks a little because I think it's probably more important to note that you can't redeclare the enum all before complaining about mismatched underlying types etc. As a drive by this patch also adds some missing diagnostic groups, and rewords the module redeclaration error message to more closely match the wording used in other places this check is done. PR c++/99573 gcc/cp/ChangeLog: * decl.cc (start_enum): Reorder check for redeclaring in module. Add missing auto_diagnostic_groups. gcc/testsuite/ChangeLog: * g++.dg/modules/enum-12.C: New test. Signed-off-by: Nathaniel Shead Reviewed-by: Jason Merrill
[Bug c++/99573] ICE in module: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in start_enum, at cp/decl.c:15663
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99573 Nathaniel Shead changed: What|Removed |Added Keywords||error-recovery Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot gnu.org Target Milestone|--- |14.0 Status|NEW |RESOLVED Resolution|--- |FIXED CC||nshead at gcc dot gnu.org --- Comment #4 from Nathaniel Shead --- Fixed for GCC 14.
[Bug c++/103524] [meta-bug] modules issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524 Bug 103524 depends on bug 99573, which changed state. Bug 99573 Summary: ICE in module: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in start_enum, at cp/decl.c:15663 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99573 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #10 from Richard Biener --- Cutting the switch in decodeToMCInst after case 693: (roughly halving it by the number of source lines) gets us to tree PTA : 129.70 ( 92%) 0.51 ( 14%) 130.28 ( 90%) 2279k ( 0%) TOTAL : 140.28 3.68144.01 982M a profile shows Samples: 657K of event 'cycles:u', Event count (approx.): 873340708228 Overhead Samples Command Shared Object Symbol 88.08%578019 cc1plus cc1plus [.] bitmap_equal_p 4.76% 31340 cc1plus cc1plus [.] equiv_class_lookup_or_a 0.59% 4039 cc1plus cc1plus [.] bitmap_set_bit 0.24% 1611 cc1plus cc1plus [.] bitmap_copy the way we hash bitmaps is quite bad, we effectively hash set and a subset of unset bits. Adding a simple additional "hash", the number of set bits, improves this to Samples: 214K of event 'cycles:u', Event count (approx.): 283548833048 Overhead Samples Command Shared Object Symbol 69.73%148209 cc1plus cc1plus [.] bitmap_equal_p 6.29% 13499 cc1plus cc1plus [.] equiv_class_lookup_or_add of course we still have too many calls (or too large but almost equal bitmaps here). Still I have a handle on this.
[Bug c/66425] (void) cast doesn't suppress __attribute__((warn_unused_result))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66425 Christian Groessler changed: What|Removed |Added CC||groessler_christian at yahoo dot d ||e --- Comment #62 from Christian Groessler --- (In reply to Segher Boessenkool from comment #60) > So you want to not warn for some (just *some*) explicitly unused cases, and > do > warn for other explicitly unused cases, and all implicitly unused cases? > While > the author of the code explicitly asked for a warning message to be emitted > in > all such cases: "The 'warn_unused_result' attribute causes a warning to be > emitted if a caller of the function with this attribute does not use its > return > value." Yes! I'm write()ing to a pipe a small amount of data (< page size), and anyway don't know how to continue if the write() fails. It would be noticed at the other end. (void)write() doesn't suppress the warning. Annoying...
[Bug rtl-optimization/10837] noreturn attribute causes no sibling calling optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10837 --- Comment #18 from Lukas Grätz --- On another thought: I think something like -fignore-backtrace could be a reasonable optimization flag (enabled by default for -O4). By ignoring the backtrace we could do other optimizations on size and speed, like in this ticket and duplicates. There are use cases for that, see some of the duplicate tickets. For example in PR56165, they didn't want to support any debugging at all. And even if you want debugging, you might want to disregard backtraces and use a more sophisticated debugging device. This is independent from attribute musttail, with -fignore-backtrace we would leave GCC more freedom to do optimization.
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #11 from Richard Biener --- Created attachment 57422 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57422&action=edit patch I'm testing the attached which brings down compile-time to the levels of GCC 11 again (a bit faster even, 30s vs. 50s).
[Bug tree-optimization/113896] [12 Regression] Assigning array elements in the wrong order after floating point optimization since r12-8841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896 Richard Biener changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Known to work||12.3.1 --- Comment #8 from Richard Biener --- Fixed.
[Bug tree-optimization/113896] [12 Regression] Assigning array elements in the wrong order after floating point optimization since r12-8841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113896 --- Comment #7 from GCC Commits --- The releases/gcc-12 branch has been updated by Richard Biener : https://gcc.gnu.org/g:2f16c53558d01135f0f78cf78a2f722b774684d7 commit r12-10155-g2f16c53558d01135f0f78cf78a2f722b774684d7 Author: Richard Biener Date: Tue Feb 13 13:43:44 2024 +0100 tree-optimization/113896 - reduction of permuted external vector The following fixes eliding of the permutation of a BB reduction of an existing vector which breaks materialization of live lanes as we fail to permute the SLP_TREE_SCALAR_STMTS vector. PR tree-optimization/113896 * tree-vect-slp.cc (vect_optimize_slp): Permute SLP_TREE_SCALAR_STMTS when eliding a permuation in a VEC_PERM node we need to preserve because it wraps an extern vector. * g++.dg/torture/pr113896.C: New testcase.
[Bug target/111677] [12 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677
--- Comment #31 from GCC Commits ---
The releases/gcc-12 branch has been updated by Alex Coplan
:
https://gcc.gnu.org/g:fddce05d67f34174be0f306e1015d3868bbe7c31
commit r12-10156-gfddce05d67f34174be0f306e1015d3868bbe7c31
Author: Alex Coplan
Date: Tue Jan 30 09:39:59 2024 +
aarch64: Avoid out-of-range shrink-wrapped saves [PR111677]
The PR shows us ICEing due to an unrecognizable TFmode save emitted by
aarch64_process_components. The problem is that for T{I,F,D}mode we
conservatively require mems to be in range for x-register ldp/stp. That
is because (at least for TImode) it can be allocated to both GPRs and
FPRs, and in the GPR case that is an x-reg ldp/stp, and the FPR case is
a q-register load/store.
As Richard pointed out in the PR, aarch64_get_separate_components
already checks that the offsets are suitable for a single load, so we
just need to choose a mode in aarch64_reg_save_mode that gives the full
q-register range. In this patch, we choose V16QImode as an alternative
16-byte "bag-of-bits" mode that doesn't have the artificial range
restrictions imposed on T{I,F,D}mode.
Unlike for GCC 14 we need additional handling in the load/store pair
code as various cases are not expecting to see V16QImode (particularly
the writeback patterns, but also aarch64_gen_load_pair).
gcc/ChangeLog:
PR target/111677
* config/aarch64/aarch64.cc (aarch64_reg_save_mode): Use
V16QImode for the full 16-byte FPR saves in the vector PCS case.
(aarch64_gen_storewb_pair): Handle V16QImode.
(aarch64_gen_loadwb_pair): Likewise.
(aarch64_gen_load_pair): Likewise.
* config/aarch64/aarch64.md (loadwb_pair_):
Rename to ...
(loadwb_pair_): ... this, extending to
V16QImode.
(storewb_pair_): Rename to ...
(storewb_pair_): ... this, extending to
V16QImode.
* config/aarch64/iterators.md (TX_V16QI): New.
gcc/testsuite/ChangeLog:
PR target/111677
* gcc.target/aarch64/torture/pr111677.c: New test.
(cherry picked from commit 2bd8264a131ee1215d3bc6181722f9d30f5569c3)
[Bug target/111677] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111677 Alex Coplan changed: What|Removed |Added Summary|[12 Regression] darktable |darktable build on aarch64 |build on aarch64 fails with |fails with unrecognizable |unrecognizable insn due to |insn due to |-fstack-protector changes |-fstack-protector changes --- Comment #32 from Alex Coplan --- Fixed for GCC 12, keeping open for a final backport to GCC 11 (since the stack protector patches were also backported there, and the underlying issue is latent there).
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #46 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:5352ede92483b949e811cbdcdfaec5378f3e06d6 commit r14-8975-g5352ede92483b949e811cbdcdfaec5378f3e06d6 Author: Richard Biener Date: Fri Feb 9 08:15:44 2024 +0100 middle-end/113576 - zero padding of vector bools when expanding compares The following zeros paddings of vector bools when expanding compares and the mode used for the compare is an integer mode. In that case targets cannot distinguish between a 4 element and 8 element vector compare (both get to the QImode compare optab) so we have to do the job in the middle-end. PR middle-end/113576 * expr.cc (do_store_flag): For vector bool compares of vectors with padding zero that. * dojump.cc (do_compare_and_jump): Likewise.
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 Richard Biener changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #47 from Richard Biener --- This should now be fixed, but I think the issue might be latent on branches for GCN or for AVX512 via intrinsics (fully masked loops for AVX512 is also only available in GCC 14). Let's close this P1, we have to consider backporting when we manage to create a miscompiled testcase for older releases.
[Bug testsuite/113899] Vect module test failures while running on remote host due to default dg-do set to compile and additional-sources being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899 --- Comment #4 from GCC Commits --- The trunk branch has been updated by Andrew Pinski : https://gcc.gnu.org/g:948dbc5ee45f9ffd5f41fd6782704081cc7c8c27 commit r14-8978-g948dbc5ee45f9ffd5f41fd6782704081cc7c8c27 Author: Andrew Pinski Date: Tue Feb 13 13:39:16 2024 -0800 vect/testsuite: Fix vect-simd-clone-1[02].c when dg-do default is compile [PR113899] The vect testsuite will chose the dg-do default based on if it knows the running target does not support running with the vector extensions enabled (for easy of testing). The problem is when it is decided the default is compile instead of run, dg-additional-sources does not work. So the fix is to set dg-do on these two testcases to run explicitly. Tested on x86_64 with a hack to check_vect_support_and_set_flags to set the dg-default to compile. gcc/testsuite/ChangeLog: PR testsuite/113899 * gcc.dg/vect/vect-simd-clone-10.c: Add `dg-do run` * gcc.dg/vect/vect-simd-clone-12.c: Likewise. Signed-off-by: Andrew Pinski
[Bug testsuite/113899] Vect module test failures while running on remote host due to default dg-do set to compile and additional-sources being used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113899 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #5 from Andrew Pinski --- Fixed.
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #48 from Uroš Bizjak ---
The runtime testcase fails on non-AVX512F x86 targets due to:
/* { dg-do run } */
/* { dg-options "-O3" } */
/* { dg-additional-options "-march=skylake-avx512" { target { x86_64-*-*
i?86-*-* } } } */
but check_vect() only checks runtime support up to AVX2.
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #49 from Richard Biener ---
(In reply to Uroš Bizjak from comment #48)
> The runtime testcase fails on non-AVX512F x86 targets due to:
>
> /* { dg-do run } */
> /* { dg-options "-O3" } */
> /* { dg-additional-options "-march=skylake-avx512" { target { x86_64-*-*
> i?86-*-* } } } */
>
> but check_vect() only checks runtime support up to AVX2.
Hmm, can we fix that? We could change the above to { target avx512f_runtime }
but that really only checks for AVX512F, not say AVX512VL ...
I do remember using -mavx512vl wasn't enough to trigger the miscompile
nor did it trigger with -march=znver4 ... so I stuck to skylake-avx512 :/
[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739
--- Comment #10 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:a032c319cb9cf5348d71f008f311bcf95f3dac40
commit r14-8979-ga032c319cb9cf5348d71f008f311bcf95f3dac40
Author: Rainer Orth
Date: Wed Feb 14 14:52:54 2024 +0100
testsuite: gdc: Require ucn in gdc.test/runnable/mangle.d etc. [PR104739]
gdc.test/runnable/mangle.d and two other tests come out UNRESOLVED on
Solaris with the native assembler:
UNRESOLVED: gdc.test/runnable/mangle.d compilation failed to produce
executable
UNRESOLVED: gdc.test/runnable/mangle.d -shared-libphobos compilation failed
to produce executable
UNRESOLVED: gdc.test/runnable/testmodule.d compilation failed to produce
executable
UNRESOLVED: gdc.test/runnable/testmodule.d -shared-libphobos compilation
failed to produce executable
UNRESOLVED: gdc.test/runnable/ufcs.d compilation failed to produce
executable
UNRESOLVED: gdc.test/runnable/ufcs.d -shared-libphobos compilation failed
to produce executable
Assembler: mangle.d
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: "movzbl
test_ÑлÑÑийÑкие_пиÑÑмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: "movzbl
test_ÑлÑÑийÑкие_пиÑÑмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: "movzbl
test_ÑлÑÑийÑкие_пиÑÑмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
Near line: "movzbl
test_ÑлÑÑийÑкие_пиÑÑмена_9, %eax"
"/var/tmp//cci9q2Sc.s", line 115 : Syntax error
[...]
since /bin/as lacks UCN support.
Iain recently added UNICODE_NAMES: annotations to the affected tests and
those recently were imported into trunk.
This patch handles the DejaGnu side of things, adding
{ dg-require-effective-target ucn }
to those tests on the fly.
Tested on i386-pc-solaris2.11, sparc-sun-solaris2.11 (as and gas each),
and x86_64-pc-linux-gnu.
2024-02-03 Rainer Orth
gcc/testsuite:
PR d/104739
* lib/gdc-utils.exp (gdc-convert-test) : Require
ucn support.
[Bug d/104739] gdc.test/runnable/mangle.d etc. FAIL with Solaris as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104739 Rainer Orth changed: What|Removed |Added Assignee|ibuclaw at gdcproject dot org |ro at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Rainer Orth --- Mine. Fixed for GCC 14.0.1.
[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706 Jason Merrill changed: What|Removed |Added Status|NEW |ASSIGNED Target Milestone|14.0|15.0 Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #50 from Jakub Jelinek ---
(In reply to Richard Biener from comment #49)
> (In reply to Uroš Bizjak from comment #48)
> > The runtime testcase fails on non-AVX512F x86 targets due to:
> >
> > /* { dg-do run } */
> > /* { dg-options "-O3" } */
> > /* { dg-additional-options "-march=skylake-avx512" { target { x86_64-*-*
> > i?86-*-* } } } */
> >
> > but check_vect() only checks runtime support up to AVX2.
>
> Hmm, can we fix that? We could change the above to { target avx512f_runtime
> }
> but that really only checks for AVX512F, not say AVX512VL ...
>
> I do remember using -mavx512vl wasn't enough to trigger the miscompile
> nor did it trigger with -march=znver4 ... so I stuck to skylake-avx512 :/
It is certainly preferable to add -mavx512{bw,dq,vl} or whatever the testcase
actually needs and then one can
#define AVX512BW
#define AVX512DQ
#define AVX512VL
#include "avx512-check.h"
and get checks for all those.
[Bug c++/113706] c-c++-common/pr103798-2.c FAILs as C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113706 --- Comment #10 from Jason Merrill --- Created attachment 57423 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57423&action=edit patch for GCC 15 Here's a fix, but since this isn't a regression it can wait for stage 1.
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #51 from Jakub Jelinek ---
>From the -mavx* options I think -march=skylake-avx512 implies
-mavx512{f,cd,vl,bw,dq} but -mavx512f is implied by any of the latter 4.
[Bug analyzer/110090] -fanalyze sometimes assumes contradictory conditions to be valid at the same time during path exploration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110090 --- Comment #1 from David Malcolm --- Thanks for filing this bug report, and sorry for not responding before. Are you still able to reproduce this? If so, please can you use -save-temps to generated a preprocessed file (.i) that reproduces the issue, and attach it (and also post the precise command-line flags you're seeing it with). See https://gcc.gnu.org/bugs/#need Thanks!
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #52 from Uroš Bizjak --- Created attachment 57424 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57424&action=edit Proposed testsuite patch This patch fixes the failure for me (+ some other dg.exp/vect inconsistencies).
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #53 from Jakub Jelinek ---
Comment on attachment 57424
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57424
Proposed testsuite patch
As skylake-avx512 is -mavx512{f,cd,bw,dq,vl}, requiring just avx512f effective
target and testing it at runtime IMHO isn't enough.
For dg-do run testcases I really think we should avoid those -march= options,
because it means a lot of other stuff, BMI, LZCNT, ...
[Bug analyzer/111441] [14 Regression] ICE generating access diagram, in fold_binary_loc, at fold-const.cc:11580
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111441 David Malcolm changed: What|Removed |Added Summary|internal compiler error: in |[14 Regression] ICE |fold_binary_loc, at |generating access diagram, |fold-const.cc:11580 |in fold_binary_loc, at ||fold-const.cc:11580 Ever confirmed|0 |1 Last reconfirmed||2024-02-14 Status|UNCONFIRMED |NEW --- Comment #5 from David Malcolm --- Thanks for filing this. Still affects trunk, though I had to add a "void" to the return type of f to avoid :2:1: error: return type defaults to 'int' [-Wimplicit-int]: https://godbolt.org/z/WM8zbvrxf
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #12 from Richard Biener --- Note after the proper fix we still have (gdb) p pointer_equiv_class_table->m_searches $17 = 180497 (gdb) p pointer_equiv_class_table->m_collisions $18 = 4101085 (gdb) p pointer_equiv_class_table->m_n_elements $22 = 143701 (gdb) p pointer_equiv_class_table->m_size $23 = 262139 "perfecting" the hash helps (mixing each individual bit number) but then all the time is spent hashing ;) Samples: 177K of event 'cycles:u', Event count (approx.): 232966151280 Overhead Samples Command Shared Object Symbol 35.77% 65423 cc1plus cc1plus [.] bitmap_hash 9.64% 16589 cc1plus cc1plus [.] bitmap_set_bit I think the data structure used is simply far from optimal. Mixing each bitmap word has higher collision rates than the XOR (dropping the XOR of the first bit number). Mixing in ptr->indx as well gives OK collision rates but still 12.78% 16684 cc1plus cc1plus [.] bitmap_set_bit 12.56% 19318 cc1plus cc1plus [.] bitmap_hash XOR for the words ontop of mixing of ptr->indx gets little worse but still reasonable rates with 14.03% 16837 cc1plus cc1plus [.] bitmap_set_bit 6.33% 7694 cc1plus cc1plus [.] insert_updated_phi_node 4.74% 7500 cc1plus cc1plus [.] bitmap_hash
[Bug tree-optimization/113910] [12/13/14 regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 --- Comment #13 from GCC Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:ad7a365aaccecd23ea287c7faaab9c7bd50b944a commit r14-8980-gad7a365aaccecd23ea287c7faaab9c7bd50b944a Author: Richard Biener Date: Wed Feb 14 12:33:13 2024 +0100 tree-optimization/113910 - huge compile time during PTA For the testcase in PR113910 we spend a lot of time in PTA comparing bitmaps for looking up equivalence class members. This points to the very weak bitmap_hash function which effectively hashes set and a subset of not set bits. The major problem with it is that it simply truncates the BITMAP_WORD sized intermediate hash to hashval_t which is unsigned int, effectively not hashing half of the bits. This reduces the compile-time for the testcase from tens of minutes to 42 seconds and PTA time from 99% to 46%. PR tree-optimization/113910 * bitmap.cc (bitmap_hash): Mix the full element "hash" to the hashval_t hash.
[Bug c++/113919] New: Nested anonymous unions should be prohibited in ISO C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113919 Bug ID: 113919 Summary: Nested anonymous unions should be prohibited in ISO C++ Product: gcc Version: 13.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: tsqurt at outlook dot com Target Milestone: --- Created attachment 57425 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57425&action=edit example.cpp Anonymous unions shall not be declared within an anonymous union. But gcc never warns about this. Demo source code as a C++17 source file attached. Note: attached code is a valid C source code but not a valid C++ source code. GCC is expected to REJECT or WARN, but it compiles without any message. $gcc example.cpp -std=c++17 --pedantic -Wall -Wextra expect: warning: ISO C++ prohibits anonymous unions within anonymous unions[-Wpedantic] But gcc exited with code 0, leaving empty message. Reference: N4849, Working Draft, Standard for Programming Language C++, Chapter 11, Section 5.1 Anonymous unions. (Different versions of modern C++ specification mention this issue in their correspondent chapters.)
[Bug ada/113868] bogus error for delta aggregate as expression function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113868 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Last reconfirmed||2024-02-14 Ever confirmed|0 |1 Summary|error: expression function |bogus error for delta |must be enclosed in |aggregate as expression |parentheses.|function Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Confirmed. The syntax of expression functions is rather irregular and thus needs special casing, so I guess there is a loophole for delta aggregates.
[Bug c++/113919] Nested anonymous unions should be prohibited in ISO C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113919 Marek Polacek changed: What|Removed |Added Last reconfirmed||2024-02-14 Status|UNCONFIRMED |NEW Keywords||accepts-invalid Ever confirmed|0 |1 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- [class.union.anon]/1: Nested types, anonymous unions, and functions shall not be declared within an anonymous union.
[Bug ada/113877] gnatchop -c puts gnat.adc in the current working directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113877 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 CC||ebotcazou at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-14 --- Comment #1 from Eric Botcazou --- No clear if anybody else uses -c with gnatchop.
Re: [Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64
> > I guess PTA gets around by tracking points-to set also for non-pointer
> > types and consequently it also gives up on any such addition.
>
> It does. But note it does _not_ for POINTER_PLUS where it treats
> the offset operand as non-pointer.
>
> > I think it is ipa-prop.c::unadjusted_ptr_and_unit_offset. It accepts
> > pointer_plus expression, but does not look through POINTER_PLUS.
> > We can restrict it further, but tracking base pointer is quite useful,
> > so it would be nice to not give up completely.
>
> It looks like that function might treat that
>
> ADDR_EXPR >
>
> as integer_zerop base. It does
>
> if (TREE_CODE (op) == ADDR_EXPR)
> {
> poly_int64 extra_offset = 0;
> tree base = get_addr_base_and_unit_offset (TREE_OPERAND (op, 0),
> &offset);
> if (!base)
> {
> base = get_base_address (TREE_OPERAND (op, 0));
> if (TREE_CODE (base) != MEM_REF)
> break;
> offset_known = false;
> }
> else
> {
> if (TREE_CODE (base) != MEM_REF)
> break;
>
> with a variable offset we fall to the TREE_CODE (base) != MEM_REF
> and will have offset_known == true. Not sure what it does with
> the result though (it's not the address of a decl).
>
> This function seems to oddly special-case != MEM_REF ... (maybe
> it wants to hande DECL_P () as finishing?
Hmm the function was definitely not written with TARGET_MEM_REF in mind,
since it was originally used for IPA passes only.
We basically want to handle stuff like
&decl->foo
or
&(ptr->foo)
In the second case we want to continue the SSA walk to hopefully work
out the origin of PTR.
ipa-modref then looks if the base pointer is derived from function
parameter or points to local or readonly memory to produce its summary.
>
> Note get_addr_base_and_unit_offset will return NULL for
> a TARGET_MEM_REF <&decl, ..., offset> but TARGET_MEM_REF
> itself if the base isn't an ADDR_EXPR, irrespective of whether
> the offset within it is constant or not.
Hmm, interesting. I would expect it to interpret the emantics of TMR
and return base.
>
> Not sure if the above is a problem, but it seems the only caller
> will just call points_to_local_or_readonly_memory_p on the
> ADDR_EXPR where refs_local_or_readonly_memory_p via
> points_to_local_or_readonly_memory_p will eventually do
>
> /* See if memory location is clearly invalid. */
> if (integer_zerop (t))
> return flag_delete_null_pointer_checks;
>
> and that might be a problem. As said, we rely on
> ADDR_EXPR > to be an address computation
> that's not subject to strict interpretation to allow IVOPTs
> doing this kind of optimization w/o introducing some kind of
> INTEGER_LEA <...>. I know that's a bit awkward but we should
> make sure this is honored by IPA as well.
>
> I'd say
>
> diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
> index 74c9b4e1d1e..45a770cf940 100644
> --- a/gcc/ipa-fnsummary.cc
> +++ b/gcc/ipa-fnsummary.cc
> @@ -2642,7 +2642,8 @@ points_to_local_or_readonly_memory_p (tree t)
> return true;
>return !ptr_deref_may_alias_global_p (t, false);
> }
> - if (TREE_CODE (t) == ADDR_EXPR)
> + if (TREE_CODE (t) == ADDR_EXPR
> + && TREE_CODE (TREE_OPERAND (t, 0)) != TARGET_MEM_REF)
> return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
>return false;
> }
>
> might eventually work? Alternatively a bit less aggressive like
> the following.
>
> diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
> index 74c9b4e1d1e..7c79adf6440 100644
> --- a/gcc/ipa-fnsummary.cc
> +++ b/gcc/ipa-fnsummary.cc
> @@ -2642,7 +2642,9 @@ points_to_local_or_readonly_memory_p (tree t)
> return true;
>return !ptr_deref_may_alias_global_p (t, false);
> }
> - if (TREE_CODE (t) == ADDR_EXPR)
> + if (TREE_CODE (t) == ADDR_EXPR
> + && (TREE_CODE (TREE_OPERAND (t, 0)) != TARGET_MEM_REF
> + || TREE_CODE (TREE_OPERAND (TREE_OPERAND (t, 0), 0)) !=
> INTEGER_CST))
> return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
>return false;
> }
Yes, those both looks reasonable to me, perhaps less agressive would be
better.
>
> A "nicer" solution might be to add a informational operand
> to TARGET_MEM_REF, representing the base pointer to be used for
> alias/points-to purposes. But if that's not invariant it might
> keep some otherwise unnecessary definition stmts live.
Yep, I see that forcing extra IV to track original semantics would be
trouble here. I think that after iv-opts we should be done with more
fancy propagation across loops.
However, to avoid ipa-modref summary degradation, perhaps scheduling the
pass before ivopts would make sense...
Thanks,
Honza
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576 --- Comment #54 from Richard Biener --- Please also verify the bug reproduced with the altered set of options. What's the reason to have avx512-check.h in addition to tree-vect.h? At least for the vectorizer testsuite the latter is the canonical one, can we please merge AVX512 support therein?
[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #17 from Jan Hubicka ---
> > I guess PTA gets around by tracking points-to set also for non-pointer
> > types and consequently it also gives up on any such addition.
>
> It does. But note it does _not_ for POINTER_PLUS where it treats
> the offset operand as non-pointer.
>
> > I think it is ipa-prop.c::unadjusted_ptr_and_unit_offset. It accepts
> > pointer_plus expression, but does not look through POINTER_PLUS.
> > We can restrict it further, but tracking base pointer is quite useful,
> > so it would be nice to not give up completely.
>
> It looks like that function might treat that
>
> ADDR_EXPR >
>
> as integer_zerop base. It does
>
> if (TREE_CODE (op) == ADDR_EXPR)
> {
> poly_int64 extra_offset = 0;
> tree base = get_addr_base_and_unit_offset (TREE_OPERAND (op, 0),
> &offset);
> if (!base)
> {
> base = get_base_address (TREE_OPERAND (op, 0));
> if (TREE_CODE (base) != MEM_REF)
> break;
> offset_known = false;
> }
> else
> {
> if (TREE_CODE (base) != MEM_REF)
> break;
>
> with a variable offset we fall to the TREE_CODE (base) != MEM_REF
> and will have offset_known == true. Not sure what it does with
> the result though (it's not the address of a decl).
>
> This function seems to oddly special-case != MEM_REF ... (maybe
> it wants to hande DECL_P () as finishing?
Hmm the function was definitely not written with TARGET_MEM_REF in mind,
since it was originally used for IPA passes only.
We basically want to handle stuff like
&decl->foo
or
&(ptr->foo)
In the second case we want to continue the SSA walk to hopefully work
out the origin of PTR.
ipa-modref then looks if the base pointer is derived from function
parameter or points to local or readonly memory to produce its summary.
>
> Note get_addr_base_and_unit_offset will return NULL for
> a TARGET_MEM_REF <&decl, ..., offset> but TARGET_MEM_REF
> itself if the base isn't an ADDR_EXPR, irrespective of whether
> the offset within it is constant or not.
Hmm, interesting. I would expect it to interpret the emantics of TMR
and return base.
>
> Not sure if the above is a problem, but it seems the only caller
> will just call points_to_local_or_readonly_memory_p on the
> ADDR_EXPR where refs_local_or_readonly_memory_p via
> points_to_local_or_readonly_memory_p will eventually do
>
> /* See if memory location is clearly invalid. */
> if (integer_zerop (t))
> return flag_delete_null_pointer_checks;
>
> and that might be a problem. As said, we rely on
> ADDR_EXPR > to be an address computation
> that's not subject to strict interpretation to allow IVOPTs
> doing this kind of optimization w/o introducing some kind of
> INTEGER_LEA <...>. I know that's a bit awkward but we should
> make sure this is honored by IPA as well.
>
> I'd say
>
> diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
> index 74c9b4e1d1e..45a770cf940 100644
> --- a/gcc/ipa-fnsummary.cc
> +++ b/gcc/ipa-fnsummary.cc
> @@ -2642,7 +2642,8 @@ points_to_local_or_readonly_memory_p (tree t)
> return true;
>return !ptr_deref_may_alias_global_p (t, false);
> }
> - if (TREE_CODE (t) == ADDR_EXPR)
> + if (TREE_CODE (t) == ADDR_EXPR
> + && TREE_CODE (TREE_OPERAND (t, 0)) != TARGET_MEM_REF)
> return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
>return false;
> }
>
> might eventually work? Alternatively a bit less aggressive like
> the following.
>
> diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
> index 74c9b4e1d1e..7c79adf6440 100644
> --- a/gcc/ipa-fnsummary.cc
> +++ b/gcc/ipa-fnsummary.cc
> @@ -2642,7 +2642,9 @@ points_to_local_or_readonly_memory_p (tree t)
> return true;
>return !ptr_deref_may_alias_global_p (t, false);
> }
> - if (TREE_CODE (t) == ADDR_EXPR)
> + if (TREE_CODE (t) == ADDR_EXPR
> + && (TREE_CODE (TREE_OPERAND (t, 0)) != TARGET_MEM_REF
> + || TREE_CODE (TREE_OPERAND (TREE_OPERAND (t, 0), 0)) !=
> INTEGER_CST))
> return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
>return false;
> }
Yes, those both looks reasonable to me, perhaps less agressive would be
better.
>
> A "nicer" solution might be to add a informational operand
> to TARGET_MEM_REF, representing the base pointer to be used for
> alias/points-to purposes. But if that's not invariant it might
> keep some otherwise unnecessary definition stmts live.
Yep, I see that forcing extra IV to track original semantics would be
trouble here. I think that after iv-opts we should be done with more
fancy propagation across loops.
However, to avoid ipa-modref summary degradation, perhaps scheduling the
pass before ivopts would make sense...
Thanks,
Honza
[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
--- Comment #18 from rguenther at suse dot de ---
On Wed, 14 Feb 2024, hubicka at ucw dot cz wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787
>
> --- Comment #17 from Jan Hubicka ---
> > > I guess PTA gets around by tracking points-to set also for non-pointer
> > > types and consequently it also gives up on any such addition.
> >
> > It does. But note it does _not_ for POINTER_PLUS where it treats
> > the offset operand as non-pointer.
> >
> > > I think it is ipa-prop.c::unadjusted_ptr_and_unit_offset. It accepts
> > > pointer_plus expression, but does not look through POINTER_PLUS.
> > > We can restrict it further, but tracking base pointer is quite useful,
> > > so it would be nice to not give up completely.
> >
> > It looks like that function might treat that
> >
> > ADDR_EXPR >
> >
> > as integer_zerop base. It does
> >
> > if (TREE_CODE (op) == ADDR_EXPR)
> > {
> > poly_int64 extra_offset = 0;
> > tree base = get_addr_base_and_unit_offset (TREE_OPERAND (op, 0),
> > &offset);
> > if (!base)
> > {
> > base = get_base_address (TREE_OPERAND (op, 0));
> > if (TREE_CODE (base) != MEM_REF)
> > break;
> > offset_known = false;
> > }
> > else
> > {
> > if (TREE_CODE (base) != MEM_REF)
> > break;
> >
> > with a variable offset we fall to the TREE_CODE (base) != MEM_REF
> > and will have offset_known == true. Not sure what it does with
> > the result though (it's not the address of a decl).
> >
> > This function seems to oddly special-case != MEM_REF ... (maybe
> > it wants to hande DECL_P () as finishing?
>
> Hmm the function was definitely not written with TARGET_MEM_REF in mind,
> since it was originally used for IPA passes only.
> We basically want to handle stuff like
> &decl->foo
> or
> &(ptr->foo)
> In the second case we want to continue the SSA walk to hopefully work
> out the origin of PTR.
> ipa-modref then looks if the base pointer is derived from function
> parameter or points to local or readonly memory to produce its summary.
> >
> > Note get_addr_base_and_unit_offset will return NULL for
> > a TARGET_MEM_REF <&decl, ..., offset> but TARGET_MEM_REF
> > itself if the base isn't an ADDR_EXPR, irrespective of whether
> > the offset within it is constant or not.
>
> Hmm, interesting. I would expect it to interpret the emantics of TMR
> and return base.
> >
> > Not sure if the above is a problem, but it seems the only caller
> > will just call points_to_local_or_readonly_memory_p on the
> > ADDR_EXPR where refs_local_or_readonly_memory_p via
> > points_to_local_or_readonly_memory_p will eventually do
> >
> > /* See if memory location is clearly invalid. */
> > if (integer_zerop (t))
> > return flag_delete_null_pointer_checks;
> >
> > and that might be a problem. As said, we rely on
> > ADDR_EXPR > to be an address computation
> > that's not subject to strict interpretation to allow IVOPTs
> > doing this kind of optimization w/o introducing some kind of
> > INTEGER_LEA <...>. I know that's a bit awkward but we should
> > make sure this is honored by IPA as well.
> >
> > I'd say
> >
> > diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
> > index 74c9b4e1d1e..45a770cf940 100644
> > --- a/gcc/ipa-fnsummary.cc
> > +++ b/gcc/ipa-fnsummary.cc
> > @@ -2642,7 +2642,8 @@ points_to_local_or_readonly_memory_p (tree t)
> > return true;
> >return !ptr_deref_may_alias_global_p (t, false);
> > }
> > - if (TREE_CODE (t) == ADDR_EXPR)
> > + if (TREE_CODE (t) == ADDR_EXPR
> > + && TREE_CODE (TREE_OPERAND (t, 0)) != TARGET_MEM_REF)
> > return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
> >return false;
> > }
> >
> > might eventually work? Alternatively a bit less aggressive like
> > the following.
> >
> > diff --git a/gcc/ipa-fnsummary.cc b/gcc/ipa-fnsummary.cc
> > index 74c9b4e1d1e..7c79adf6440 100644
> > --- a/gcc/ipa-fnsummary.cc
> > +++ b/gcc/ipa-fnsummary.cc
> > @@ -2642,7 +2642,9 @@ points_to_local_or_readonly_memory_p (tree t)
> > return true;
> >return !ptr_deref_may_alias_global_p (t, false);
> > }
> > - if (TREE_CODE (t) == ADDR_EXPR)
> > + if (TREE_CODE (t) == ADDR_EXPR
> > + && (TREE_CODE (TREE_OPERAND (t, 0)) != TARGET_MEM_REF
> > + || TREE_CODE (TREE_OPERAND (TREE_OPERAND (t, 0), 0)) !=
> > INTEGER_CST))
> > return refs_local_or_readonly_memory_p (TREE_OPERAND (t, 0));
> >return false;
> > }
>
> Yes, those both looks reasonable to me, perhaps less agressive would be
> better.
Note I didn't check if it helps the testcase ..
> >
> > A "nicer" solution might be to add a informational operand
> > to TARGET_MEM_REF, representing the base pointer to be used for
> > alias/poin
[Bug tree-optimization/113910] [12/13 Regression] Factor 15 slowdown compiling AMDGPUDisassembler.cpp on SPARC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113910 Richard Biener changed: What|Removed |Added Summary|[12/13/14 regression] |[12/13 Regression] Factor |Factor 15 slowdown |15 slowdown compiling |compiling |AMDGPUDisassembler.cpp on |AMDGPUDisassembler.cpp on |SPARC |SPARC | Known to work||14.0 --- Comment #14 from Richard Biener --- The regression should be fixed, can you check we're now no longer slower on trunk? (either use a release checking build or use -fno-checking which should get you reasonably close)
[Bug tree-optimization/113787] [12/13/14 Regression] Wrong code at -O with ipa-modref on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113787 --- Comment #19 from Jan Hubicka --- > Note I didn't check if it helps the testcase .. I will check. > > > > > > > A "nicer" solution might be to add a informational operand > > > to TARGET_MEM_REF, representing the base pointer to be used for > > > alias/points-to purposes. But if that's not invariant it might > > > keep some otherwise unnecessary definition stmts live. > > > > Yep, I see that forcing extra IV to track original semantics would be > > trouble here. I think that after iv-opts we should be done with more > > fancy propagation across loops. > > > > However, to avoid ipa-modref summary degradation, perhaps scheduling the > > pass before ivopts would make sense... > > We also have that other bug where store-merging breaks the IPA summary > which gets prevailed in the late modref, so moving it around doesn't > solve all of the IL related issues ... I did not mean to paper around the fact that we produce wrong code with TARGET_MEM_REFs (we ought to fix that). If ivopts makes it difficult to track bases of memory accesses, we may get better summaries if we built them earlier. The purpose for late mod-ref is to analyze the function body as cleaned up as possible (so we do not get confused i.e. by dead memory accesses and other stuff we see before inlining) but we do not want to lower the representation too much, since that is generally lossy too. I will look at the store merging issue. Honza
[Bug c++/113332] [12/13/14 regression] checking ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 --- Comment #5 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9bc6b23d11697545e8a951ccd60691b1e58b98c2 commit r14-8981-g9bc6b23d11697545e8a951ccd60691b1e58b98c2 Author: Patrick Palka Date: Wed Feb 14 10:20:31 2024 -0500 c++: synthesized_method_walk context independence [PR113908] In the second testcase below, during ahead of time checking of the non-dependent new-expr we synthesize B's copy ctor, which we expect to get defined as deleted since A's copy ctor is inaccessible. But during access checking thereof, enforce_access incorrectly decides to defer it since we're in a template context according to current_template_parms (before r14-557 it checked processing_template_decl which got cleared from implicitly_declare_fn), which leads to the access check leaking out to the template context that triggered the synthesization, and B's copy ctor getting declared as non-deleted. This patch fixes this by using maybe_push_to_top_level to clear the context (including current_template_parms) before proceeding with the synthesization. We could do this from implicitly_declare_fn, but it's better to do it more generally from synthesized_method_walk for sake of its other callers. This turns out to fix PR113332 as well: there the lambda context triggering synthesization was causing maybe_dummy_object to misbehave, but now synthesization is sufficiently context-independent. PR c++/113908 PR c++/113332 gcc/cp/ChangeLog: * method.cc (synthesized_method_walk): Use maybe_push_to_top_level. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-nsdmi11.C: New test. * g++.dg/template/non-dependent31.C: New test. Reviewed-by: Jason Merrill
[Bug c++/113908] [14 Regression] bogus access error with new-expr of current non-template class with implicitly deleted copy ctor since r14-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113908 --- Comment #1 from GCC Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:9bc6b23d11697545e8a951ccd60691b1e58b98c2 commit r14-8981-g9bc6b23d11697545e8a951ccd60691b1e58b98c2 Author: Patrick Palka Date: Wed Feb 14 10:20:31 2024 -0500 c++: synthesized_method_walk context independence [PR113908] In the second testcase below, during ahead of time checking of the non-dependent new-expr we synthesize B's copy ctor, which we expect to get defined as deleted since A's copy ctor is inaccessible. But during access checking thereof, enforce_access incorrectly decides to defer it since we're in a template context according to current_template_parms (before r14-557 it checked processing_template_decl which got cleared from implicitly_declare_fn), which leads to the access check leaking out to the template context that triggered the synthesization, and B's copy ctor getting declared as non-deleted. This patch fixes this by using maybe_push_to_top_level to clear the context (including current_template_parms) before proceeding with the synthesization. We could do this from implicitly_declare_fn, but it's better to do it more generally from synthesized_method_walk for sake of its other callers. This turns out to fix PR113332 as well: there the lambda context triggering synthesization was causing maybe_dummy_object to misbehave, but now synthesization is sufficiently context-independent. PR c++/113908 PR c++/113332 gcc/cp/ChangeLog: * method.cc (synthesized_method_walk): Use maybe_push_to_top_level. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/lambda/lambda-nsdmi11.C: New test. * g++.dg/template/non-dependent31.C: New test. Reviewed-by: Jason Merrill
[Bug c++/113908] [14 Regression] bogus access error with new-expr of current non-template class with implicitly deleted copy ctor since r14-557
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113908 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Patrick Palka --- Fixed.
[Bug c++/113332] [12/13 regression] checking ICE when building fcitx-5.1.6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113332 Patrick Palka changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ppalka at gcc dot gnu.org
[Bug c++/113919] Nested anonymous unions should be prohibited in ISO C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113919 --- Comment #2 from Marek Polacek --- I suppose this should fix it but there are testsuite FAILs. --- a/gcc/cp/decl.cc +++ b/gcc/cp/decl.cc @@ -5522,6 +5522,12 @@ fixup_anonymous_aggr (tree t) } } } + /* [class.union.anon]/1: Nested types, anonymous unions, and functions +shall not be declared within an anonymous union. */ + else if (ANON_UNION_TYPE_P (TREE_TYPE (probe))) + pedwarn (DECL_SOURCE_LOCATION (probe), OPT_Wpedantic, +"anonymous unions cannot be declared within an anonymous " +"union"); } /* Splice all functions out of CLASSTYPE_MEMBER_VEC. */
[Bug tree-optimization/113576] [14 regression] 502.gcc_r hangs r14-8223-g1c1853a70f9422169190e65e568dcccbce02d95c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113576
--- Comment #55 from Uroš Bizjak ---
(In reply to Jakub Jelinek from comment #53)
> Comment on attachment 57424 [details]
> Proposed testsuite patch
>
> As skylake-avx512 is -mavx512{f,cd,bw,dq,vl}, requiring just avx512f
> effective target and testing it at runtime IMHO isn't enough.
> For dg-do run testcases I really think we should avoid those -march=
> options, because it means a lot of other stuff, BMI, LZCNT, ...
I think that addition of
+# if defined(__AVX512VL__)
+want_level = 7, want_b = bit_AVX512VL;
+# elif defined(__AVX512F__)
+want_level = 7, want_b = bit_AVX512F;
+# elif defined(__AVX2__)
to check_vect solves all current uses in gcc.dg/vect
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907 Jan Hubicka changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #29 from Jan Hubicka --- Safest fix is to make equals_p to reject merging functions with different value ranges assigned to corresponding SSA names. I would hope that, since early opts are still mostly local, that does not lead to very large degradation. This is lame of course. If we go for smarter merging, we need to also handle ipa-prop jump functions. In that case I think equals_p needs to check if value range sin SSA_NAMES and jump functions differs and if so, keep that noted so the merging code can do corresponding update. I will check how hard it is to implement this. (Equality handling is Martin Liska's code, but if I recall right, each equivalence class has a leader, and we can keep track if there are some differences WRT that leader, but I do not recall how subdivision of equivalence classes is handled).
[Bug ada/113893] finalization issue with anonymous access object of local type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||ebotcazou at gcc dot gnu.org Summary|Finalization exception |finalization issue with |issue with anonymous access |anonymous access object of |object. |local type Last reconfirmed||2024-02-14 Ever confirmed|0 |1 --- Comment #1 from Eric Botcazou --- The problem is that the finalization routine of Float_Sanitized.Container is local to Test01 but is invoked indirectly from "its enclosing library unit" when the dynamically allocated object is finalized, namely the enclosing procedure. So it's a plain dangling reference and its effects depend on the phase of the moon, for example the mere presence of Test02. The workaround is of course to follow the advice of the warning or else to move the instantiation of Float_Sanitized to the enclosing procedure.
[Bug ada/113893] finalization issue with anonymous access object of local type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893 Eric Botcazou changed: What|Removed |Added Status|NEW |SUSPENDED --- Comment #2 from Eric Botcazou --- No plan to fix this in the short term.
[Bug middle-end/113907] [14 regression] ICU miscompiled since on x86 since r14-5109-ga291237b628f41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113907
--- Comment #30 from Jakub Jelinek ---
Created attachment 57426
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57426&action=edit
gcc14-pr113907.patch
I've managed to come up with a small runtime testcase.
Now with a patch which does the resetting of SSA_NAME_{PTR,RANGE}_INFO for
!flag_wpa in ICF merged functions (in the hope that we regenerate it during
vrp1).
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #8 from GCC Commits --- The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:b79d3e6a9284703b70688122f7d4955e7c50804a commit r14-8983-gb79d3e6a9284703b70688122f7d4955e7c50804a Author: Jerry DeLisle Date: Tue Feb 13 14:32:21 2024 -0800 Fortran: Implement read_x for UTF-8 encoded files. PR fortran/99210 libgfortran/ChangeLog: * io/read.c (read_x): If UTF-8 encoding is enabled, use read_utf8 to move one character over in the read buffer. gcc/testsuite/ChangeLog: * gfortran.dg/pr99210.f90: New test.
[Bug c++/113919] Nested anonymous unions should be prohibited in ISO C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113919 --- Comment #3 from Marek Polacek --- clang++ has -Wnested-anon-types so I think we need that too.
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #4 from Jan Hubicka --- There is a cap in want_inline_self_recursive_call_p which gives up on inlining after reaching max recursive inlining depth of 8. Problem is that the tree here is too wide. After early inlining f0 contains 4 calls to f1 and
[Bug ada/113893] finalization issue with anonymous access object of local type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893 Eric Botcazou changed: What|Removed |Added Status|SUSPENDED |NEW --- Comment #3 from Eric Botcazou --- On second thoughts, some stopgap measure is probably in order.
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #5 from Jan Hubicka --- There is a cap in want_inline_self_recursive_call_p which gives up on inlining after reaching max recursive inlining depth of 8. Problem is that the tree here is too wide. After early inlining f0 contains 4 calls to f1 and 3 calls to f0. Similarly for f0, so we have something like (9+3*9)^8 as a cap on number of inlines that takes a while to converge. One may want to limit number of copies of function A within function B rather than depth, but that number can be large even for sane code. I am making patch to make inliner to ignore always_inline on all self-recrusive inline decisions.
[Bug c++/72751] anonymous union within an anonymous union accepted without diagnostic (i.e. add -Wnested-anon-types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72751 Marek Polacek changed: What|Removed |Added CC||tsqurt at outlook dot com --- Comment #3 from Marek Polacek --- *** Bug 113919 has been marked as a duplicate of this bug. ***
[Bug c++/113919] Nested anonymous unions should be prohibited in ISO C++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113919 Marek Polacek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #4 from Marek Polacek --- Ah, we have a dup. *** This bug has been marked as a duplicate of bug 72751 ***
[Bug c++/72751] anonymous union within an anonymous union accepted without diagnostic (i.e. add -Wnested-anon-types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72751
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
--- Comment #4 from Marek Polacek ---
Test from Bug 113919:
struct _ {
union
{
union {
int __;
};
};
};
int main(){return 0;}
[Bug c++/72751] anonymous union within an anonymous union accepted without diagnostic (i.e. add -Wnested-anon-types)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72751 --- Comment #5 from Marek Polacek --- We should also make sure that __extension__ suppresses the -Wnested-anon-types diagnostic.
[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability since r14-2967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 --- Comment #6 from GCC Commits --- The master branch has been updated by Jan Hubicka : https://gcc.gnu.org/g:8d51bfe0f97a27c749c36003867901338833340a commit r14-8985-g8d51bfe0f97a27c749c36003867901338833340a Author: Jan Hubicka Date: Wed Feb 14 17:37:34 2024 +0100 Fix ICE in loop splitting with -fno-guess-branch-probability PR tree-optimization/111054 gcc/ChangeLog: * tree-ssa-loop-split.cc (split_loop): Check for profile being present. gcc/testsuite/ChangeLog: * gcc.c-torture/compile/pr111054.c: New test.
[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability since r14-2967
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111054 Jan Hubicka changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from Jan Hubicka --- Fixed.
[Bug c++/113920] New: Make -std=gnu++20 default for GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113920 Bug ID: 113920 Summary: Make -std=gnu++20 default for GCC 15 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: mpolacek at gcc dot gnu.org Target Milestone: --- Once C++20 support in libstdc++ has been declared stable, we should probably switch the default from gnu++17 to gnu++20 in GCC 15. C++ modules will still be experimental though.
[Bug c++/113920] Make -std=gnu++20 default for GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113920 Marek Polacek changed: What|Removed |Added Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2024-02-14
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #7 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #1) > I assume that int8_t is char on Solaris, rather than signed char? This actually violates the C and C++ standards, which require that intN_t is a signed integer type, and C 6.2.5 says "There are five standard signed integer types, designated as signed char, short int, int, long int, and long long int." So char isn't allowed, it should be signed char. I don't know if it's possible to fix that on Solaris.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #8 from Jakub Jelinek --- (In reply to Jonathan Wakely from comment #7) > (In reply to Jonathan Wakely from comment #1) > > I assume that int8_t is char on Solaris, rather than signed char? > > This actually violates the C and C++ standards, which require that intN_t is > a signed integer type, and C 6.2.5 says "There are five standard signed > integer types, designated as signed char, short int, int, long int, and long > long int." So char isn't allowed, it should be signed char. > > I don't know if it's possible to fix that on Solaris. fixinc?
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #9 from Jonathan Wakely --- It's technically an ABI break, since void f(int8_t) would mangle differently. It probably wouldn't affect much in practice, but would still be a break.
[Bug libstdc++/113450] [14 Regression] std/format/functions/format.cc FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113450 --- Comment #10 from Jakub Jelinek --- Or convince Oracle to change it (again, an ABI break).
[Bug ipa/113291] [14 Regression] compilation never (?) finishes with recursive always_inline functions at -O and above since r14-2172
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113291 --- Comment #6 from Jan Hubicka --- Created attachment 57427 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57427&action=edit patch The patch makes compilation to finish in reasonable time. I ended up in need to dropping DISREGARD_INLINE_LIMITS in late inlining for functions with self recursive always inlines, since these grow large quick and even non-recursive inlining is too slow. We also end up with quite ugly diagnostics of form: tt.c:13:1: error: inlining failed in call to ‘always_inline’ ‘f1’: --param max-inline-insns-auto limit reached 13 | f1 (void) | ^~ tt.c:17:3: note: called from here 17 | f1 (); | ^ tt.c:6:1: error: inlining failed in call to ‘always_inline’ ‘f0’: --param max-inline-insns-auto limit reached 6 | f0 (void) | ^~ tt.c:16:3: note: called from here 16 | f0 (); | ^ tt.c:13:1: error: inlining failed in call to ‘always_inline’ ‘f1’: --param max-inline-insns-auto limit reached 13 | f1 (void) | ^~ tt.c:15:3: note: called from here 15 | f1 (); | ^ In function ‘f1’, inlined from ‘f0’ at tt.c:8:3, which is quite large so I can not add it to a testuiste. I will see if I can reduce this even more.
[Bug c/113921] New: Output register of an "asm volatile goto" is incorrectly clobbered/discarded
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113921
Bug ID: 113921
Summary: Output register of an "asm volatile goto" is
incorrectly clobbered/discarded
Product: gcc
Version: 11.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: seanjc at google dot com
CC: jakub at redhat dot com, ndesaulniers at google dot com,
torva...@linux-foundation.org, ubizjak at gmail dot com
Target Milestone: ---
Created attachment 57428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57428&action=edit
Intermediate output of the miscompiled file
gcc-11 appears to have a bug that results in gcc incorrectly clobbering the
output register of an "asm volatile goto".
The failing asm blob is a sequence of VMREADs in the Linux kernel, with the
outputs stored into a dynamically allocated structure whose lifecycle is far
beyond the scope of the code in question:
vmcs12->guest_pdptr0 = vmcs_read64(GUEST_PDPTR0);
vmcs12->guest_pdptr1 = vmcs_read64(GUEST_PDPTR1);
vmcs12->guest_pdptr2 = vmcs_read64(GUEST_PDPTR2);
vmcs12->guest_pdptr3 = vmcs_read64(GUEST_PDPTR3);
where vmcs_read64() eventually becomes:
asm volatile goto("1: vmread %[field], %[output]\n\t"
"jna %l[do_fail]\n\t"
_ASM_EXTABLE(1b, %l[do_exception])
: [output] "=r" (value)
: [field] "r" (field)
: "cc"
: do_fail, do_exception);
return value;
do_fail:
instrumentation_begin();
vmread_error(field);
instrumentation_end();
return 0;
do_exception:
kvm_spurious_fault();
return 0;
The first three PDPTR VMREADs generate correctly, but the fourth effectively
gets ignored, and '0' is written to vmcs12->guest_pdptr3.
3597: mov$0x280a,%r13d
359d: vmread %r13,%r13
35a1: jbe3724
35a7: mov%r13,0xd8(%rbx)
35ae: jmp396b
35b3: mov$0x280c,%r13d
35b9: vmread %r13,%r13
35bd: jbe3705
35c3: mov%r13,0xe0(%rbx)
35ca: jmp393a
35cf: mov$0x280e,%r13d
35d5: vmread %r13,%r13
35d9: jbe36e6
35df: mov%r13,0xe8(%rbx)
35e6: jmp3909
35eb: mov$0x2810,%eax
35f0: vmread %rax,%rax<= VMREAD to nowhere
35f3: jbe36ca
35f9: xor%r12d,%r12d <= zeroing of output
35fc: mov%r12,0xf0(%rbx) <= store to vmcs12->guest_pdptr3
Replacing "asm volatile goto" with the following macro
#define asm_goto(x...) \
do { asm volatile goto(x); asm (""); } while (0)
to force a second barrier generates functional code, although the attempt to
miscompile the sequence is still evident, as the output of the affected VMREAD
is unnecessarily bounced through an extra register:
35f8: mov$0x280a,%r13d
35fe: vmread %r13,%r13
3602: jbe36b2
3608: mov%r13,0xd8(%rbx)
360f: jmp3925
3614: mov$0x280c,%r13d
361a: vmread %r13,%r13
361e: jbe3693
3620: mov%r13,0xe0(%rbx)
3627: jmp38f4
362c: mov$0x280e,%r13d
3632: vmread %r13,%r13
3636: jbe367a
3638: mov%r13,0xe8(%rbx)
363f: jmp38c3
3644: mov$0x2810,%eax
3649: vmread %rax,%rax
364c: jbe3664
364e: mov%rax,%r12
3651: mov%r12,0xf0(%rbx)
The bug reproduces with two different 11.4.0 builds, on three different systems
(Intel i7-9850H, Intel i7-13700K, AMD EPYC 7B12), all running Debian-based
Linux.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/11/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:amdgcn-amdhsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-plugin --enable-default-pie --with-system-zlib
--enable-libphobos-checking=release --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-wer
[Bug rtl-optimization/103908] gcc miscompile asm goto for O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103908 Andrew Pinski changed: What|Removed |Added Known to fail|12.0|10.3.0, 11.2.0, 9.4.0 Known to work||10.4.0, 11.3.0, 9.5.0 Target Milestone|--- |9.5
[Bug libstdc++/113074] std::to_address should be SFINAE safe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113074 --- Comment #14 from Peter Kasting --- (In reply to Jonathan Wakely from comment #13) > As I said in comment 7, LWG considered this case and it was pointed out that > the problem described can only occur if a type defines iterator_concept = > contiguous_iterator; but then fails to actually provide the operations > needed for a contiguous iterator (i.e. either a pointer_traits > specialization with to_address or a sane operator->()). That's fair. But that only considers the functionality of to_address() inside this specific library use of it. If this tool is to be usable in other contexts (which I argue it should be, or it shouldn't have been exposed to end users), then said contexts may have nothing to do with iterators. And you are right, it's possible to reimplement concepts around "is this even legal to pass to to_address()", which is basically what we're doing to address this in Chromium. But that's pretty unfriendly to most usage; if you're in a context where you are reaching for to_address() to begin with, it's likely because you're templated and don't know that a simpler thing like `&*ptr` is valid. In such cases, having to_address() be SFINAE-friendly makes it far easier to fall back to other handling for "not a pointer". > A SFINAE-friendly std::to_address as implemented in libc++ means that such > an iterator will fail to satisfy std::contiguous_iterator and will silently > degrade to satosfying std::random_access_iterator only. It's not at all > clear to me that silently degrading such an iterator (which very explicitly > claims to be a contiguous iterator by defining iterator_concept to say so) > would be an improvement. I'd rather get an error telling me the thing I > thought was a contiguous iterator was not actually. That's fair, but isn't that implementable by simply making the definition of contiguous_iterator explicitly hard error in this case? That is, an SFINAE-friendly to_address() wouldn't prevent you from diagnosing this particular usage site as incorrect.
[Bug middle-end/113415] ICE: RTL check: -mstringop-strategy=byte_loop vs inline-asm goto with block copies
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113415 Andrew Pinski changed: What|Removed |Added Target Milestone|--- |14.0
[Bug tree-optimization/113567] ICE: SSA corruption: Unable to coalesce ssa_names 1 and 3 which are marked as MUST COALESCE. with _BitInt() and computed goto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113567 Jakub Jelinek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #4 from Jakub Jelinek --- Created attachment 57429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57429&action=edit gcc14-pr113567.patch Untested fix.
[Bug ada/113893] finalization issue with anonymous access object of local type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113893 Eric Botcazou changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug ada/113862] error: "others" choice not allowed here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113862 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2024-02-14 Status|UNCONFIRMED |NEW --- Comment #1 from Eric Botcazou --- Not clear if there is much value in creating a PR for such a pathological case if it happens to be legal.
