aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2024-02-14i386: psrlq is not used for PERM<a,{0},1,2,3,4> [PR113871]Uros Bizjak9-14/+222
Introduce vec_shl_<mode> and vec_shr_<mode> expanders to improve '*a = __builtin_shufflevector(*a, (vect64){0}, 1, 2, 3, 4);' and '*a = __builtin_shufflevector((vect64){0}, *a, 3, 4, 5, 6);' shuffles. The generated code improves from: movzwl 6(%rdi), %eax movzwl 4(%rdi), %edx salq $16, %rax orq %rdx, %rax movzwl 2(%rdi), %edx salq $16, %rax orq %rdx, %rax movq %rax, (%rdi) to: movq (%rdi), %xmm0 psrlq $16, %xmm0 movq %xmm0, (%rdi) and to: movq (%rdi), %xmm0 psllq $16, %xmm0 movq %xmm0, (%rdi) in the second case. The patch handles 32-bit vectors as well and improves generated code from: movd (%rdi), %xmm0 pxor %xmm1, %xmm1 punpcklwd %xmm1, %xmm0 pshuflw $230, %xmm0, %xmm0 movd %xmm0, (%rdi) to: movd (%rdi), %xmm0 psrld $16, %xmm0 movd %xmm0, (%rdi) and to: movd (%rdi), %xmm0 pslld $16, %xmm0 movd %xmm0, (%rdi) PR target/113871 gcc/ChangeLog: * config/i386/mmx.md (V248FI): New mode iterator. (V24FI_32): DItto. (vec_shl_<V248FI:mode>): New expander. (vec_shl_<V24FI_32:mode>): Ditto. (vec_shr_<V248FI:mode>): Ditto. (vec_shr_<V24FI_32:mode>): Ditto. * config/i386/sse.md (vec_shl_<V_128:mode>): Simplify expander. (vec_shr_<V248FI:mode>): Ditto. gcc/testsuite/ChangeLog: * gcc.target/i386/pr113871-1a.c: New test. * gcc.target/i386/pr113871-1b.c: New test. * gcc.target/i386/pr113871-2a.c: New test. * gcc.target/i386/pr113871-2b.c: New test. * gcc.target/i386/pr113871-3a.c: New test. * gcc.target/i386/pr113871-3b.c: New test. * gcc.target/i386/pr113871-4a.c: New test.
2024-02-15c++: Defer emitting inline variables [PR113708]Nathaniel Shead6-2/+25
Inline variables are vague-linkage, and may or may not need to be emitted in any TU that they are part of, similarly to e.g. template instantiations. Currently 'import_export_decl' assumes that inline variables have already been emitted when it comes to end-of-TU processing, and so crashes when importing non-trivially-initialised variables from a module, as they have not yet been finalised. This patch fixes this by ensuring that inline variables are always deferred till end-of-TU processing, unifying the behaviour for module and non-module code. PR c++/113708 gcc/cp/ChangeLog: * decl.cc (make_rtl_for_nonlocal_decl): Defer inline variables. * decl2.cc (import_export_decl): Support inline variables. gcc/testsuite/ChangeLog: * g++.dg/debug/dwarf2/inline-var-1.C: Reference 'a' to ensure it is emitted. * g++.dg/debug/dwarf2/inline-var-3.C: Likewise. * g++.dg/modules/init-7_a.H: New test. * g++.dg/modules/init-7_b.C: New test. Signed-off-by: Nathaniel Shead <nathanieloshead@gmail.com>
2024-02-14aarch64/testsuite: Remove dg-excess-errors from c-c++-common/gomp/pr63328.c ↵Andrew Pinski2-3/+0
and gcc.dg/gomp/pr87895-2.c [PR113861] These now pass after r14-6416-gf5fc001a84a7db so let's remove the dg-excess-errors from them. Committed as obvious after a test for aarch64-linux-gnu. gcc/testsuite/ChangeLog: PR testsuite/113861 * c-c++-common/gomp/pr63328.c: Remove dg-excess-errors. * gcc.dg/gomp/pr87895-2.c: Likewise. Signed-off-by: Andrew Pinski <quic_apinski@quicinc.com>
2024-02-14Fix ICE in loop splitting with -fno-guess-branch-probabilityJan Hubicka2-1/+13
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.
2024-02-14middle-end: inspect all exits for additional annotations for loop.Tamar Christina2-6/+42
Attaching a pragma to a loop which has a complex condition often gets the pragma dropped. e.g. #pragma GCC novector while (i < N && parse_tables_n--) before lowering this is represented as: if (ANNOTATE_EXPR <i <= 305 && parse_tables_n-- != 0, no-vector>) ... But after lowering the condition is broken appart and attached to the final component of the expression: if (parse_tables_n.2_2 != 0) goto <D.4456>; else goto <D.4453>; <D.4456>: iftmp.1D.4452 = 1; goto <D.4454>; <D.4453>: iftmp.1D.4452 = 0; <D.4454>: D.4451 = .ANNOTATE (iftmp.1D.4452, 2, 0); if (D.4451 != 0) goto <D.4442>; else goto <D.4440>; <D.4440>: and it's never heard from again because during replace_loop_annotate we only inspect the loop header and latch for annotations. Since annotations were supposed to apply to the loop as a whole this fixes it by checking the loop exit src blocks for annotations instead. gcc/ChangeLog: * tree-cfg.cc (replace_loop_annotate): Inspect loop edges for annotations. gcc/testsuite/ChangeLog: * gcc.dg/vect/vect-novect_gcond.c: New test.
2024-02-14Fortran: Implement read_x for UTF-8 encoded files.Jerry DeLisle1-0/+29
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.
2024-02-14coreutils-sum-pr108666.c: fix spurious LLP64 warningsJonathan Yong1-1/+1
Fixes the following warnings on x86_64-w64-mingw32: coreutils-sum-pr108666.c:17:1: warning: conflicting types for built-in function ‘memcpy’; expected ‘void *(void *, const void *, long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 17 | memcpy(void* __restrict __dest, const void* __restrict __src, size_t __n) | ^~~~~~ coreutils-sum-pr108666.c:25:1: warning: conflicting types for built-in function ‘malloc’; expected ‘void *(long long unsigned int)’ [-Wbuiltin-declaration-mismatch] 25 | malloc(size_t __size) __attribute__((__nothrow__, __leaf__)) | ^~~~~~ gcc/testsuite: * c-c++-common/analyzer/coreutils-sum-pr108666.c: Use __SIZE_TYPE__ instead of long unsigned int for size_t definition. Signed-off-by: Jonathan Yong <10walls@gmail.com>
2024-02-14c++: synthesized_method_walk context independence [PR113908]Patrick Palka3-0/+40
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 <jason@redhat.com>
2024-02-14tree-optimization/113910 - huge compile time during PTARichard Biener1-1/+1
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.
2024-02-14testsuite: gdc: Require ucn in gdc.test/runnable/mangle.d etc. [PR104739]Rainer Orth1-0/+5
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 <ro@CeBiTec.Uni-Bielefeld.DE> gcc/testsuite: PR d/104739 * lib/gdc-utils.exp (gdc-convert-test) <UNICODE_NAMES>: Require ucn support.
2024-02-14vect/testsuite: Fix vect-simd-clone-1[02].c when dg-do default is compile ↵Andrew Pinski2-0/+4
[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 <quic_apinski@quicinc.com>
2024-02-14testsuite: Add %[zt][diox] tests to gcc.dg/format/Jakub Jelinek2-2/+19
On Mon, Feb 12, 2024 at 04:10:33PM +0000, Joseph Myers wrote: > Please also add some tests of format checking for these modifiers in > gcc.dg/format/gcc_*.c. The following patch does that. Haven't added tests for bad type (but I think we don't have them in c99-printf* either) for these because it is hard to figure out what type from {,unsigned }{int,long,long long} size_t/ptrdiff_t certainly is not, guess one could do that with preprocessor conditionals, e.g. comparing __PTRDIFF_MAX__ with __INT_MAX__, __LONG_MAX__ and __LONG_LONG_MAX__ and pick up the one which is different; but we'd need to find out corresponding effective targets for the expected diagnostics. 2024-02-14 Jakub Jelinek <jakub@redhat.com> * gcc.dg/format/gcc_diag-1.c (foo): Add tests for z and t modifiers. * gcc.dg/format/gcc_gfc-1.c (foo): Add tests for ll, z and t modifiers.
2024-02-14pretty-print: Fix up ptrdiff handling for %tu, %to, %txJakub Jelinek2-8/+20
This is IMHO more of a theoretical case, I believe my current code doesn't handle %tu or %to or %tx correctly if ptrdiff_t is not one of int, long int or long long int. For size_t and %zd or %zi I'm using va_arg (whatever, ssize_t) and hope that ssize_t is the signed type corresponding to size_t which C99 talks about. For ptrdiff_t there is no type for unsigned type corresponding to ptrdiff_t and I'm not aware of a portable way on the host to get such a type (the fmt tests use hacks like #define signed /* Type might or might not have explicit 'signed'. */ typedef unsigned __PTRDIFF_TYPE__ unsigned_ptrdiff_t; #undef signed but that only works with compilers which predefine __PTRDIFF_TYPE__), std::make_unsigned<ptrdiff_t> I believe only works reliably if ptrdiff_t is one of char, signed char, short, int, long or long long, but won't work e.g. for __int20__ or whatever other weird ptrdiff_t the host might have. The following patch assumes host is two's complement (I think we rely on it pretty much everywhere anyway) and prints unsigned type corresponding to ptrdiff_t as unsigned long long printing of ptrdiff_t value masked with 2ULL * PTRDIFF_MAX + 1. So the only actual limitation is that it doesn't support ptrdiff_t wider than long long int. 2024-02-14 Jakub Jelinek <jakub@redhat.com> * pretty-print.cc (PTRDIFF_MAX): Define if not yet defined. (pp_integer_with_precision): For unsigned ptrdiff_t printing with u, o or x print ptrdiff_t argument converted to unsigned long long and masked with 2ULL * PTRDIFF_MAX + 1. * error.cc (error_print): For u printing of ptrdiff_t, print ptrdiff_t argument converted to unsigned long long and masked with 2ULL * PTRDIFF_MAX + 1.
2024-02-14middle-end/113576 - zero padding of vector bools when expanding comparesRichard Biener2-0/+33
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.
2024-02-14c++: Fix error recovery when redeclaring enum in different module [PR99573]Nathaniel Shead2-14/+31
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 <nathanieloshead@gmail.com> Reviewed-by: Jason Merrill <jason@redhat.com>
2024-02-14testsuite: i386: Skip gcc.target/i386/pr113689-1.c etc. on Solaris [PR113909]Rainer Orth3-0/+3
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 <ro@CeBiTec.Uni-Bielefeld.DE> 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.
2024-02-14testsuite: gfortran: Remove obsolete references to Solaris 9Rainer Orth5-5/+5
Some gfortran tests still contain references to long-obsolete Solaris 9. This patch removes them. Tested on i386-pc-solaris2.11. 2024-02-13 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> gcc/testsuite: * gfortran.dg/fmt_en.f90 (dg-output): Don't xfail on ?86-*-solaris2.9*. * gfortran.dg/fmt_en_rd.f90: Likewise. * gfortran.dg/fmt_en_rn.f90: Likewise. * gfortran.dg/fmt_en_ru.f90: Likewise. * gfortran.dg/fmt_en_rz.f90: Likewise.
2024-02-14testsuite: xfail c-c++-common/pr103798-2.c for C++ on Solaris [PR113706]Rainer Orth1-1/+2
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 <string.h> 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 <ro@CeBiTec.Uni-Bielefeld.DE> gcc/testsuite: PR c++/113706 * c-c++-common/pr103798-2.c (scan-assembler-not): xfail for C++ on Solaris.
2024-02-14install: Update gettext linkGerald Pfeifer1-2/+2
gcc: * doc/install.texi (Prerequisites): Update gettext link.
2024-02-14Daily bump.GCC Administrator7-1/+250
2024-02-13c++: adjust the extra ; warning [PR113760]Marek Polacek6-5/+24
A minimal fix to quash an extra ; warning. I have a more complete patch for GCC 15. DR 1693 PR c++/113760 gcc/cp/ChangeLog: * parser.cc (cp_parser_member_declaration): Only pedwarn about an extra semicolon in C++98. gcc/testsuite/ChangeLog: * g++.dg/semicolon-fixits.C: Run in C++98 only. * g++.dg/warn/pedantic2.C: Adjust dg-warning. * g++.old-deja/g++.jason/parse11.C: Adjust dg-error. * g++.dg/DRs/dr1693-1.C: New test. * g++.dg/DRs/dr1693-2.C: New test.
2024-02-13x86-64: Use push2/pop2 only if the incoming stack is 16-byte alignedH.J. Lu2-0/+16
Since push2/pop2 requires 16-byte stack alignment, don't use them if the incoming stack isn't 16-byte aligned. gcc/ PR target/113876 * config/i386/i386.cc (ix86_pro_and_epilogue_can_use_push2pop2): Return false if the incoming stack isn't 16-byte aligned. gcc/testsuite/ PR target/113876 * gcc.target/i386/pr113876.c: New test.
2024-02-13OpenMP: Reject non-const 'condition' trait in FortranTobias Burnus17-44/+119
OpenMP 5.0 only permits constant expressions for the 'condition' trait in context selectors; this is relaxed in 5.2 but not implemented. In order to avoid wrong code, it is now rejected. Additionally, in Fortran, 'condition' should not accept an integer expression, which is now ensured. Additionally, as 'device_num' should be a conforming device number, there is now a check on the value. PR middle-end/113904 gcc/c/ChangeLog: * c-parser.cc (c_parser_omp_context_selector): Handle splitting of OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR. gcc/cp/ChangeLog: * parser.cc (cp_parser_omp_context_selector): Handle splitting of OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR. gcc/fortran/ChangeLog: * trans-openmp.cc (gfc_trans_omp_declare_variant): Handle splitting of OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR. * openmp.cc (gfc_match_omp_context_selector): Likewise; rejects non-const device_num/condition; improve diagnostic. gcc/ChangeLog: * omp-general.cc (struct omp_ts_info): Update for splitting of OMP_TRAIT_PROPERTY_EXPR into OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR. * omp-selectors.h (enum omp_tp_type): Replace OMP_TRAIT_PROPERTY_EXPR by OMP_TRAIT_PROPERTY_{DEV_NUM,BOOL}_EXPR. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/declare-variant-1.f90: Change 'condition' trait's argument from integer to a logical expression. * gfortran.dg/gomp/declare-variant-11.f90: Likewise. * gfortran.dg/gomp/declare-variant-12.f90: Likewise. * gfortran.dg/gomp/declare-variant-13.f90: Likewise. * gfortran.dg/gomp/declare-variant-2.f90: Likewise. * gfortran.dg/gomp/declare-variant-2a.f90: Likewise. * gfortran.dg/gomp/declare-variant-3.f90: Likewise. * gfortran.dg/gomp/declare-variant-4.f90: Likewise. * gfortran.dg/gomp/declare-variant-6.f90: Likewise. * gfortran.dg/gomp/declare-variant-8.f90: Likewise. * gfortran.dg/gomp/declare-variant-20.f90: New test.
2024-02-13c++/modules: use optimized crc32 from zlibPatrick Palka2-6/+4
The current implementation of bytes::calc_crc computes the checksum one byte at a time which turns out to be quite slow, accounting for 15% of streaming in time for a modular Hello World. We have a crc32_unsigned version that processes 4 bytes at a time which we could use here, but since we bundle zlib we might as well use its highly optimized crc routines that can process up to 32 bytes at a time. So this patch makes us use zlib's crc32 in this hot code path. This reduces stream in time for a modular Hello World by around 15% for me with a release compiler. gcc/cp/ChangeLog: * Make-lang.in (CFLAGS-cp/module.o): Add $(ZLIBINC). * module.cc: Include <zlib.h>. (bytes::calc_crc): Use crc32 from zlib. (bytes_out::set_crc): Use crc32_combine from zlib. Reviewed-by: Jason Merill <jason@redhat.com>
2024-02-13c++/modules: ICEs with modular fmtlibPatrick Palka4-2/+31
Building modular fmtlib triggered two small modules bugs in C++23 and C++26 mode respectively (due to libstdc++ header differences). The first is that a TEMPLATE_DECL having DECL_LANG_SPECIFIC doesn't necessarily imply that its DECL_TEMPLATE_RESULT has DECL_LANG_SPECIFIC. So in add_specializations we need to use STRIP_TEMPLATE consistently; this is a follow-up to r12-7187-gdb84f382ae3dc2. The second is that get_originating_module_decl was ICEing on class-scope enumerators injected via using-enum. I suppose we should handle them like a class-scope entity rather than a non-using-enum enumerator. gcc/cp/ChangeLog: * module.cc (depset::hash::add_specializations): Use STRIP_TEMPLATE consistently. (get_originating_module_decl): Handle class-scope CONST_DECL. gcc/testsuite/ChangeLog: * g++.dg/modules/friend-6_a.C: New test. * g++.dg/modules/using-enum-3_a.C: New test. * g++.dg/modules/using-enum-3_b.C: New test. Reviewed-by: Jason Merill <jason@redhat.com>
2024-02-13c++/modules: reduce lazy loading recursionPatrick Palka2-3/+18
It turns out that with modules we can call mangle_decl recursively which is bad because the global mangling state isn't recursion aware. The recursion happens from write_closure_type_name, which calls lambda_function, which performs name lookup, which can trigger lazy loading, which can call maybe_clone_body for a newly loaded cdtor, which can inspect DECL_ASSEMBLER_NAME, which enters mangling. This was observed when using fmtlib as a module with trunk and it leads to a bogus "mangling conflicts with a previous mangle error" followed by an ICE from cdtor_comdat_group due to a mangling mismatch. This patch fixes this by sidestepping lazy loading when performing the op() lookup in lambda_function, so that we don't accidentally end up entering mangling recursively. This should be safe since the lazy load should still get triggered by some other name lookup. In passing it was noticed that lazy loading can get excessively recursive ultimately due to the name lookups performed from check_local_shadow, which may trigger lazy loading, which cause us to instantiate/clone things, which end up calling check_local_shadow. This patch mitigates this by implementating an optimization suggested by Jason: > I think we shouldn't bother with check_local_shadow in a clone or > instantiation, only when actually parsing. This reduces the maximum depth of lazy loading recursion for a simple modular Hello World from ~115 to ~12. gcc/cp/ChangeLog: * lambda.cc (lambda_function): Call get_class_binding_direct instead of lookup_member to sidestep lazy loading. * name-lookup.cc (check_local_shadow): Punt if we're in a function context that's not actual parsing. Reviewed-by: Jason Merill <jason@redhat.com>
2024-02-13Fortran: fix passing of optional dummies to bind(c) procedures [PR113866]Harald Anlauf2-2/+109
PR fortran/113866 gcc/fortran/ChangeLog: * trans-expr.cc (gfc_conv_procedure_call): When passing an optional dummy argument to an optional dummy argument of a bind(c) procedure and the dummy argument is passed via a CFI descriptor, no special presence check and passing of a default NULL pointer is needed. gcc/testsuite/ChangeLog: * gfortran.dg/bind_c_optional-2.f90: New test.
2024-02-13c++: variable partial spec redeclaration [PR113612]Jason Merrill2-3/+14
If register_specialization finds a previous declaration and throws the new one away, we shouldn't still add the new one to DECL_TEMPLATE_SPECIALIZATIONS. PR c++/113612 gcc/cp/ChangeLog: * pt.cc (process_partial_specialization): Return early on redeclaration. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/var-templ85.C: New test.
2024-02-13Re: [PATCH] RISC-V: Fix macro fusion for auipc+add, when identifying ↵Monk Chiang2-1/+5
UNSPEC_AUIPC. [PR113742] gcc/ChangeLog: PR target/113742 * config/riscv/riscv.cc (riscv_macro_fusion_pair_p): Fix recognizes UNSPEC_AUIPC for RISCV_FUSE_LUI_ADDI. gcc/testsuite/ChangeLog: * gcc.target/riscv/pr113742.c: New test.
2024-02-13Fix lookup of TuplePattern sub-pattern typesOwen Avery2-6/+10
gcc/rust/ChangeLog: * backend/rust-compile-pattern.cc (CompilePatternLet::visit): Lookup type of sub-pattern, not tuple pattern itself. gcc/testsuite/ChangeLog: * rust/compile/issue-2847-b.rs: New test. Signed-off-by: Owen Avery <powerboat9.gamer@gmail.com>
2024-02-13c++: SFINAE-unfriendly error on throwing pointer [PR112436]Marek Polacek2-31/+44
On the heels of r14-8903, this patch adds further complain parameters so that we don't emit "invalid use of incomplete type" from inside a concept. PR c++/112436 gcc/cp/ChangeLog: * except.cc (expand_start_catch_block): Pass tf_warning_or_error to is_admissible_throw_operand_or_catch_parameter. (build_throw): Pass complain to is_admissible_throw_operand_or_catch_parameter. (complete_ptr_ref_or_void_ptr_p): Add a tsubst_flags_t parameter. Use it. Return bool. Call complete_type_or_maybe_complain instead of complete_type_or_else. (is_admissible_throw_operand_or_catch_parameter): Add a tsubst_flags_t parameter. Use it. Guard error calls. gcc/testsuite/ChangeLog: * g++.dg/cpp2a/concepts-pr112436.C: New test.
2024-02-13gccrs: add powi intrinsicsMarc Poulhiès3-5/+39
gcc/rust/ChangeLog: * backend/rust-builtins.cc (BuiltinsContext::register_rust_mappings): Add powi and reformat. * backend/rust-builtins.h: Add missing copyright header. gcc/testsuite/ChangeLog: * rust/compile/torture/intrinsics-math.rs: Adjust pow test, add test for powi. Signed-off-by: Marc Poulhiès <dkm@kataplop.net>
2024-02-13tree-optimization/113896 - testcase for fixed PRRichard Biener1-0/+35
The SLP permute optimization rewrite fixed this. PR tree-optimization/113896 * g++.dg/torture/pr113896.C: New testcase.
2024-02-13tree-optimization/113895 - copy_reference_ops_from_ref vs. bitfieldsRichard Biener2-3/+39
The recent enhancement to discover constant array indices by range info used by get_ref_base_and_extent doesn't work when the outermost component reference is to a bitfield because we track the running offset in the reference ops as bytes. The following does as ao_ref_init_from_vn_reference and recovers that manually, tracking the offset for the purpose of discovering the constant array index in bits instead. PR tree-optimization/113895 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Track offset to discover constant array indices in bits, handle COMPONENT_REF to bitfields. * gcc.dg/torture/pr113895-1.c: New testcase.
2024-02-13Fix comment typo in ao_ref_init_from_vn_referenceRichard Biener1-1/+1
PR tree-optimization/113831 * tree-ssa-sccvn.cc (ao_ref_init_from_vn_reference): Fix typo in comment.
2024-02-13tree-optimization/113902 - fix VUSE update in move_early_exit_stmtsRichard Biener2-5/+22
The following adjusts move_early_exit_stmts to track the last seen VUSE instead of getting it from the last store which could be a PHI where gimple_vuse doesn't work. PR tree-optimization/113902 * tree-vect-loop.cc (move_early_exit_stmts): Track last_seen_vuse for VUSE updating. * gcc.dg/vect/pr113902.c: New testcase.
2024-02-13gccrs: Add testcase for #[rustc_const_stable]Arthur Cohen1-0/+2
To ensure we don't introduce regressions back to issue #2314 gcc/testsuite/ChangeLog: * rust/compile/rustc_const_stable.rs: New test.
2024-02-13expand: Fix formatting for "macro not found" errorArthur Cohen1-3/+3
gcc/rust/ChangeLog: * expand/rust-macro-expand.h (struct MacroExpander): Nitpick: fix formatting of emitted error.
2024-02-13Fix rebinding importsOwen Avery3-93/+116
gcc/rust/ChangeLog: * resolve/rust-ast-resolve-item.cc (flatten_glob): Use Import class. (flatten_rebind): Likewise. (flatten_list): Likewise. (flatten): Likewise. (flatten_use_dec_to_paths): Likewise. (flatten_use_dec_to_imports): Likewise. (ResolveItem::visit): Likewise. (Import::add_prefix): New. (rust_flatten_nested_glob): Adjust test. (rust_flatten_glob): Likewise. (rust_flatten_rebind_none): Likewise. (rust_flatten_rebind): Likewise. (rust_flatten_rebind_nested): Likewise. (rust_flatten_list): Likewise. * resolve/rust-ast-resolve-item.h (class Import): New. gcc/testsuite/ChangeLog: * rust/compile/use_2.rs: New test. Signed-off-by: Owen Avery <powerboat9.gamer@gmail.com>
2024-02-13middle-end: update vector loop upper bounds when early break vect [PR113734]Tamar Christina2-1/+39
When doing early break vectorization we should treat the final iteration as possibly being partial. This so that when we calculate the vector loop upper bounds we take into account that final iteration could have done some work. The attached testcase shows that if we don't then cunroll may unroll the loop an if the upper bound is wrong we lose a vector iteration. This is similar to how we adjust the scalar loop bounds for the PEELED case. gcc/ChangeLog: PR tree-optimization/113734 * tree-vect-loop.cc (vect_transform_loop): Treat the final iteration of an early break loop as partial. gcc/testsuite/ChangeLog: PR tree-optimization/113734 * gcc.dg/vect/vect-early-break_117-pr113734.c: New test.
2024-02-13c++: Don't advertise cxx_constexpr_string_builtins [PR113658]Alex Coplan2-1/+14
When __has_feature was introduced for GCC 14, I included the feature cxx_constexpr_string_builtins, since of the relevant string builtins that GCC implements, it seems to support constexpr evaluation of those builtins. However, as the PR shows, GCC doesn't implement the full list of builtins in the clang documentation. After enumerating the builtins, the clang docs [1] say: > Support for constant expression evaluation for the above builtins can > be detected with __has_feature(cxx_constexpr_string_builtins). and a strict reading of this would suggest we can't really support constexpr evaluation of a builtin if we don't implement the builtin in the first place. So the conservatively correct thing to do seems to be to stop advertising the feature altogether to avoid failing to build code which assumes the presence of this feature implies the presence of all the builtins listed in the clang documentation. [1] : https://clang.llvm.org/docs/LanguageExtensions.html#string-builtins gcc/cp/ChangeLog: PR c++/113658 * cp-objcp-common.cc (cp_feature_table): Remove entry for cxx_constexpr_string_builtins. gcc/testsuite/ChangeLog: PR c++/113658 * g++.dg/ext/has-feature2.C: New test.
2024-02-13tree-optimization/113898 - ICE with sanity checking for VN ref adjustmentRichard Biener2-0/+17
The following fixes a missing add to the accumulated offset when adjusting an ARRAY_REF op for value-ranges applied to by get_ref_base_and_extent. PR tree-optimization/113898 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): Add missing accumulated off adjustment. * gcc.dg/torture/pr113898.c: New testcase.
2024-02-13hwint: Fix up preprocessor conditions for GCC_PRISZ/fmt_size_tJakub Jelinek1-2/+2
Using unsigned long long int for fmt_size_t and "ll" for GCC_PRISZ as broke the gengtype on i686-linux before the libiberty fix is certainly unexpected. size_t is there unsigned int, so expected fmt_size_t is unsigned int (or some other 32-bit type). The problem was that I was comparing SIZE_MAX against signed maxima, but SIZE_MAX is unsigned maximum. 2024-02-13 Jakub Jelinek <jakub@redhat.com> * hwint.h (GCC_PRISZ, fmt_size_t): Fix preprocessor conditions, instead of comparing SIZE_MAX against INT_MAX and LONG_MAX compare it against UINT_MAX and ULONG_MAX.
2024-02-12Fortran: Set the length of an allocatable characterSteve Kargl2-0/+12
PR fortran/113883 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_deferred_array): Set length to zero, avoiding extraneous diagnostics. gcc/testsuite/ChangeLog: * gfortran.dg/allocatable_length.f90: New test.
2024-02-12diagnostics: unbreak 'make gcc.pot'David Malcolm3-19/+19
As noted by Joseph, I broke "make gcc.pot" in r14-6057-g12b67d1e13b3cf by adding an overloaded format API with the format string in a different position, leading to this failure: emit_diagnostic_valist used incompatibly as both --keyword=emit_diagnostic_valist:4 --flag=emit_diagnostic_valist:4:gcc-internal-format and --keyword=emit_diagnostic_valist:5 --flag=emit_diagnostic_valist:5:gcc-internal-format Fix by replacing the overloaded function with one with a different name. See also r10-6297-g6c8e584430bc5d for previous fixes for this involving the same function, or r5-6946-g40fecdd62f7d29 and r5-6959-gdb30e21cbff7b9 for older fixes for similar issues. gcc/analyzer/ChangeLog: * pending-diagnostic.cc (diagnostic_emission_context::warn): Update for renaming of emit_diagnostic_valist overload to emit_diagnostic_valist_meta. (diagnostic_emission_context::inform): Likewise. gcc/ChangeLog: * diagnostic-core.h (emit_diagnostic_valist): Rename overload to... (emit_diagnostic_valist_meta): ...this. * diagnostic.cc (emit_diagnostic_valist): Likewise, to... (emit_diagnostic_valist_meta): ...this. Signed-off-by: David Malcolm <dmalcolm@redhat.com>
2024-02-13Daily bump.GCC Administrator5-1/+147
2024-02-12libgfortran: Adjust bytes_left and pos for access="STREAM".Jerry DeLisle1-0/+14
During tab edits, the pos (position) and bytes_used Variables were not being set correctly for stream I/O. Since stream I/O does not have 'real' records, the format buffer active length must be used instead of the record length variable. PR libgfortran/109358 libgfortran/ChangeLog: * io/transfer.c (formatted_transfer_scalar_write): Adjust bytes_used and pos variable for stream access. gcc/testsuite/ChangeLog: * gfortran.dg/pr109358.f90: New test.
2024-02-12c++: ICE with reinterpret_cast and switch [PR113545]Marek Polacek2-3/+11
Jason, this is the patch you proposed for PR113545. It looks very safe so I'm posting it here so that it's not forgotten. PR c++/113545 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_switch_expr): If the condition doesn't reduce to an INTEGER_CST, consider it non-constant. gcc/testsuite/ChangeLog: * g++.dg/cpp1y/constexpr-reinterpret3.C: Remove dg-ice.
2024-02-12lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions ↵Jakub Jelinek2-4/+33
multiple of limb_prec [PR113849] handle_cast handles the simple way all narrowing large/huge bitint to large/huge bitint conversions and also such widening conversions if we can assume that the most significant limb is processed using constant index and both lhs and rhs have same number of limbs. But, the condition whether we can rely on the most significant limb being processed using constant index is incorrect. For m_upwards_2limb it was correct (m_upwards_2limb then is the number of limbs handled by the loop, so if lhs_type has larger precision than that, it is handled with constant index), similarly if m_var_msb is set (on left shifts), it is never handled with constant idx. But in other cases, like right shifts or non-equality comparisons, or bitquery operations which operate from most significant to least significant limb, all those can handle even the most significant limb in a loop when lhs_type has precision which is a multiple of limb_prec. So, the following patch punts on the optimization in that case and goes for the conditionals in the loop for that case. 2024-02-12 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/113849 * gimple-lower-bitint.cc (bitint_large_huge::handle_cast): Don't use fast path for widening casts where !m_upwards_2limb and lhs_type has precision which is a multiple of limb_prec. * gcc.dg/torture/bitint-58.c: New test.
2024-02-12attribs: Don't canonicalize lookup_scoped_attribute_spec argument [PR113674]Jakub Jelinek2-10/+13
The C and C++ FEs when parsing attributes already canonicalize them (i.e. if they start with __ and end with __ substrings, we remove those). lookup_attribute already verifies in gcc_assert that the first character of name is not an underscore, and even lookup_scoped_attribute_spec doesn't attempt to canonicalize the namespace it is passed. But for some historic reason it was canonicalizing the name argument, which misbehaves when an attribute starts with ____ and ends with ____. I believe it is just wrong to try to canonicalize lookup_scope_attribute_spec name attribute, it should have been canonicalized already, in other spots where it is called it is already canonicalized before. 2024-02-12 Jakub Jelinek <jakub@redhat.com> PR c++/113674 * attribs.cc (extract_attribute_substring): Remove. (lookup_scoped_attribute_spec): Don't call it. * c-c++-common/Wattributes-3.c: New test.
generated by cgit v1.1 at 2025-09-24 07:06:05 +0000