- Jan 14, 2025
-
-
Anuj Mohite authored
This patch provided by Anuj Mohite as part of the GSoC project. It is modified slightly by Jerry DeLisle for minor formatting. The patch provides front-end parsing of the LOCALITY specs in DO_CONCURRENT and adds numerous test cases. gcc/fortran/ChangeLog: * dump-parse-tree.cc (show_code_node): Updated to use c->ext.concur.forall_iterator instead of c->ext.forall_iterator. * frontend-passes.cc (index_interchange): Updated to use c->ext.concur.forall_iterator instead of c->ext.forall_iterator. (gfc_code_walker): Likewise. * gfortran.h (enum locality_type): Added new enum for locality types in DO CONCURRENT constructs. * match.cc (match_simple_forall): Updated to use new_st.ext.concur.forall_iterator instead of new_st.ext.forall_iterator. (gfc_match_forall): Likewise. (gfc_match_do): Implemented support for matching DO CONCURRENT locality specifiers (LOCAL, LOCAL_INIT, SHARED, DEFAULT(NONE), and REDUCE). * parse.cc (parse_do_block): Updated to use new_st.ext.concur.forall_iterator instead of new_st.ext.forall_iterator. * resolve.cc (struct check_default_none_data): Added struct check_default_none_data. (do_concur_locality_specs_f2023): New function to check compliance with F2023's C1133 constraint for DO CONCURRENT. (check_default_none_expr): New function to check DEFAULT(NONE) compliance. (resolve_locality_spec): New function to resolve locality specs. (gfc_count_forall_iterators): Updated to use code->ext.concur.forall_iterator. (gfc_resolve_forall): Updated to use code->ext.concur.forall_iterator. * st.cc (gfc_free_statement): Updated to free locality specifications and use p->ext.concur.forall_iterator. * trans-stmt.cc (gfc_trans_forall_1): Updated to use code->ext.concur.forall_iterator. gcc/testsuite/ChangeLog: * gfortran.dg/do_concurrent_10.f90: New test. * gfortran.dg/do_concurrent_8_f2018.f90: New test. * gfortran.dg/do_concurrent_8_f2023.f90: New test. * gfortran.dg/do_concurrent_9.f90: New test. * gfortran.dg/do_concurrent_all_clauses.f90: New test. * gfortran.dg/do_concurrent_basic.f90: New test. * gfortran.dg/do_concurrent_constraints.f90: New test. * gfortran.dg/do_concurrent_local_init.f90: New test. * gfortran.dg/do_concurrent_locality_specs.f90: New test. * gfortran.dg/do_concurrent_multiple_reduce.f90: New test. * gfortran.dg/do_concurrent_nested.f90: New test. * gfortran.dg/do_concurrent_parser.f90: New test. * gfortran.dg/do_concurrent_reduce_max.f90: New test. * gfortran.dg/do_concurrent_reduce_sum.f90: New test. * gfortran.dg/do_concurrent_shared.f90: New test. Signed-off-by:
Anuj <anujmohite001@gmail.com>
-
David Malcolm authored
PR c/116871 notes that our diagnostics about incompatible function types could be improved. In particular, for the case of migrating to C23 I'm seeing a lot of build failures with signal handlers similar to this (simplified from alsa-tools-1.2.11, envy24control/profiles.c; see rhbz#2336278): typedef void (*__sighandler_t) (int); extern __sighandler_t signal (int __sig, __sighandler_t __handler) __attribute__ ((__nothrow__ , __leaf__)); void new_process(void) { void (*int_stat)(); int_stat = signal(2, ((__sighandler_t) 1)); signal(2, int_stat); } Before this patch, cc1 fails with this message: t.c: In function 'new_process': t.c:18:12: error: assignment to 'void (*)(void)' from incompatible pointer type '__sighandler_t' {aka 'void (*)(int)'} [-Wincompatible-pointer-types] 18 | int_stat = signal(2, ((__sighandler_t) 1)); | ^ t.c:20:13: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types] 20 | signal(2, int_stat); | ^~~~~~~~ | | | void (*)(void) t.c:11:57: note: expected '__sighandler_t' {aka 'void (*)(int)'} but argument is of type 'void (*)(void)' 11 | extern __sighandler_t signal (int __sig, __sighandler_t __handler) | ~~~~~~~~~~~~~~~^~~~~~~~~ With this patch, cc1 emits: t.c: In function 'new_process': t.c:18:12: error: assignment to 'void (*)(void)' from incompatible pointer type '__sighandler_t' {aka 'void (*)(int)'} [-Wincompatible-pointer-types] 18 | int_stat = signal(2, ((__sighandler_t) 1)); | ^ t.c:9:16: note: '__sighandler_t' declared here 9 | typedef void (*__sighandler_t) (int); | ^~~~~~~~~~~~~~ t.c:20:13: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types] 20 | signal(2, int_stat); | ^~~~~~~~ | | | void (*)(void) t.c:11:57: note: expected '__sighandler_t' {aka 'void (*)(int)'} but argument is of type 'void (*)(void)' 11 | extern __sighandler_t signal (int __sig, __sighandler_t __handler) | ~~~~~~~~~~~~~~~^~~~~~~~~ t.c:9:16: note: '__sighandler_t' declared here 9 | typedef void (*__sighandler_t) (int); | ^~~~~~~~~~~~~~ showing the location of the pertinent typedef ("__sighandler_t") Another example, simplfied from a52dec-0.7.4: src/a52dec.c (rhbz#2336013): typedef void (*__sighandler_t) (int); extern __sighandler_t signal (int __sig, __sighandler_t __handler) __attribute__ ((__nothrow__ , __leaf__)); /* Mismatching return type. */ static RETSIGTYPE signal_handler (int sig) { } static void print_fps (int final) { signal (42, signal_handler); } Before this patch, cc1 emits: t2.c: In function 'print_fps': t2.c:22:15: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types] 22 | signal (42, signal_handler); | ^~~~~~~~~~~~~~ | | | int (*)(int) t2.c:11:57: note: expected '__sighandler_t' {aka 'void (*)(int)'} but argument is of type 'int (*)(int)' 11 | extern __sighandler_t signal (int __sig, __sighandler_t __handler) | ~~~~~~~~~~~~~~~^~~~~~~~~ With this patch cc1 emits: t2.c: In function 'print_fps': t2.c:22:15: error: passing argument 2 of 'signal' from incompatible pointer type [-Wincompatible-pointer-types] 22 | signal (42, signal_handler); | ^~~~~~~~~~~~~~ | | | int (*)(int) t2.c:11:57: note: expected '__sighandler_t' {aka 'void (*)(int)'} but argument is of type 'int (*)(int)' 11 | extern __sighandler_t signal (int __sig, __sighandler_t __handler) | ~~~~~~~~~~~~~~~^~~~~~~~~ t2.c:16:19: note: 'signal_handler' declared here 16 | static RETSIGTYPE signal_handler (int sig) | ^~~~~~~~~~~~~~ t2.c:9:16: note: '__sighandler_t' declared here 9 | typedef void (*__sighandler_t) (int); | ^~~~~~~~~~~~~~ showing the location of the pertinent fndecl ("signal_handler"), and, as before, the pertinent typedef. The patch also updates the colorization in the messages to visually link and contrast the different types and typedefs. My hope is that this make it easier for users to decipher build failures seen with the new C23 default. Further improvements could be made to colorization in convert_for_assignment, and similar improvements to C++, but I'm punting those to GCC 16. gcc/c/ChangeLog: PR c/116871 * c-typeck.cc (pedwarn_permerror_init): Return bool for whether a warning was emitted. Only call print_spelling if we warned. (pedwarn_init): Return bool for whether a warning was emitted. (permerror_init): Likewise. (warning_init): Return bool for whether a warning was emitted. Only call print_spelling if we warned. (class pp_element_quoted_decl): New. (maybe_inform_typedef_location): New. (convert_for_assignment): For OPT_Wincompatible_pointer_types, move auto_diagnostic_group to cover all cases. Use %e and pp_element rather than %qT and tree to colorize the types. Capture whether a warning was emitted, and, if it was, show various notes: for a pointer to a function, show the function decl, for typedef types, and show the decls. gcc/testsuite/ChangeLog: PR c/116871 * gcc.dg/c23-mismatching-fn-ptr-a52dec.c: New test. * gcc.dg/c23-mismatching-fn-ptr-alsatools.c: New test. * gcc.dg/c23-mismatching-fn-ptr.c: New test. Signed-off-by:
David Malcolm <dmalcolm@redhat.com>
-
Andrew Pinski authored
With the addition of supporting operations on the SVE scalable vector types, the vec_duplicate tree will show up in expressions and the constexpr handling was not done for this tree code. This is a simple fix to treat VEC_DUPLICATE like any other unary operator and allows the constexpr-add-1.C testcase to work. Built and tested for aarch64-linux-gnu. PR c++/118445 gcc/cp/ChangeLog: * constexpr.cc (cxx_eval_constant_expression): Handle VEC_DUPLICATE like a "normal" unary operator. (potential_constant_expression_1): Likewise. gcc/testsuite/ChangeLog: * g++.target/aarch64/sve/constexpr-add-1.C: New test. Signed-off-by:
Andrew Pinski <quic_apinski@quicinc.com>
-
Robin Dapp authored
Hi, currently ssa-dse-1.C ICEs because expand_simple_binop returns NULL when building the scalar that is used to IOR two interleaving sequences. That's because we try to emit a shift in HImode. This patch shifts in Xmode and then lowpart-subregs the result to HImode. Regtested on rv64gcv_zvl512b. Regards Robin gcc/ChangeLog: * config/riscv/riscv-v.cc (expand_const_vector): Shift in Xmode.
-
Jiufu Guo authored
Previously, vsx_stxvd2x4_le_const_<mode> was introduced for 'split1' pass, so it is guarded by "can_create_pseudo_p ()". While it would be possible to match the pattern of this insn during/after RA, this insn could be updated to make it work for split pass after RA. And this insn would not be the best choice if the address has alignment like "&(-16)", so "!altivec_indexed_or_indirect_operand" is added to guard this insn. 2025-01-13 Jiufu Guo <guojiufu@linux.ibm.com> gcc/ PR target/116030 * config/rs6000/vsx.md (vsx_stxvd2x4_le_const_<mode>): Add clobber and guard with !altivec_indexed_or_indirect_operand. gcc/testsuite/ PR target/116030 * gcc.target/powerpc/pr116030.c: New test.
-
GCC Administrator authored
-
Robin Dapp authored
Hi, in PR117682 we build an interleaving pattern { 1, 201, 209, 25, 161, 105, 113, 185, 65, 9, 17, 89, 225, 169, 177, 249, 129, 73, 81, 153, 33, 233, 241, 57, 193, 137, 145, 217, 97, 41, 49, 121 }; with negative step expecting wraparound semantics due to -fwrapv. For building interleaved patterns we have an optimization that does e.g. {1, 209, ...} = { 1, 0, 209, 0, ...} and {201, 25, ...} >> 8 = { 0, 201, 0, 25, ...} and IORs those. The optimization only works if the lowpart bits are zero. When overflowing e.g. with a negative step we cannot guarantee this. This patch makes us fall back to the generic merge handling for negative steps. I'm not 100% certain we're good even for positive steps. If the step or the vector length is large enough we'd still overflow and have non-zero lower bits. I haven't seen this happen during my testing, though and the patch doesn't make things worse, so... Regtested on rv64gcv_zvl512b. Let's see what the CI says. Regards Robin PR target/117682 gcc/ChangeLog: * config/riscv/riscv-v.cc (expand_const_vector): Fall back to merging if either step is negative. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/autovec/pr117682.c: New test.
-
- Jan 13, 2025
-
-
Robin Dapp authored
Hi, the zbb-rol-ror and stack_save_restore tests use the -fno-lto option and scan the final assembly. For an invocation like -flto ... -fno-lto the output file we scan is still something like zbb-rol-ror-09.ltrans0.ltrans.s. Therefore skip the tests when "-flto" is present. This gets rid of a few UNRESOLVED tests. Regtested on rv64gcv_zvl512b. Going to push if the CI agrees. Regards Robin gcc/testsuite/ChangeLog: * gcc.target/riscv/stack_save_restore_1.c: Skip for -flto. * gcc.target/riscv/stack_save_restore_2.c: Ditto. * gcc.target/riscv/zbb-rol-ror-04.c: Ditto. * gcc.target/riscv/zbb-rol-ror-05.c: Ditto. * gcc.target/riscv/zbb-rol-ror-06.c: Ditto. * gcc.target/riscv/zbb-rol-ror-07.c: Ditto. * gcc.target/riscv/zbb-rol-ror-08.c: Ditto. * gcc.target/riscv/zbb-rol-ror-09.c: Ditto.
-
Gaius Mulley authored
This patch removes the physical address from the COPYING.FDL and replaces it with a URL. gcc/m2/ChangeLog: PR modula2/116557 * COPYING.FDL: Remove physical address and replace with a URL. Signed-off-by:
Gaius Mulley <gaiusmod2@gmail.com>
-
Thomas Koenig authored
gcc/fortran/ChangeLog: * dump-parse-tree.cc (show_attr): Fix typos for in_equivalence.
-
Xi Ruoyao authored
The test case long test (long x, long y) { return ((x | 0x1ff) << 3) + y; } is now compiled (-O2 -march=rv64g_zba) to li a4,4096 slliw a5,a0,3 addi a4,a4,-8 or a5,a5,a4 addw a0,a5,a1 ret Despite this check was originally intended to use zba better, now removing it actually enables the use of zba for this test case (thanks to late combine): ori a5,a0,511 sh3add a0,a5,a1 ret Obviously, bitmanip.md does not cover (any_or (ashift (reg) (imm123)) imm) at all, and even for and it just seems more natural splitting to (ashift (and (reg) (imm')) (imm123)) first, then let late combine to combine the outer ashift and the plus. I've not found any test case regressed by the removal. And "make check-gcc RUNTESTFLAGS=riscv.exp='zba-*.c'" also reports no failure. gcc/ChangeLog: PR target/115921 * config/riscv/riscv.md (<optab>_shift_reverse): Remove check for TARGET_ZBA. gcc/testsuite/ChangeLog: PR target/115921 * gcc.target/riscv/zba-shNadd-08.c: New test.
-
Iain Buclaw authored
Each major release is not binary compatible with the previous. PR d/117701 libphobos/ChangeLog: * configure: Regenerate. * configure.ac (libtool_VERSION): Update to 6:0:0.
-
Richard Sandiford authored
In g:06c4cf39 I mishandled signed comparisons of comparison results on STORE_FLAG_VALUE < 0 targets (despite specifically referencing STORE_FLAG_VALUE in the commit message). There, (lt TRUE FALSE) is true, although (ltu FALSE TRUE) still holds. Things get messy with vector modes, and since those weren't the focus of the original commit, it seemed better to punt on them for now. However, punting means that this optimisation no longer feels like a natural tail-call operation. The patch therefore converts "return simplify..." to the usual call-and-conditional-return pattern. gcc/ PR target/118418 * simplify-rtx.cc (simplify_context::simplify_relational_operation_1): Take STORE_FLAG_VALUE into account when handling signed comparisons of comparison results.
-
Xi Ruoyao authored
When zbs is not available, there's nothing special with single-bit immediates and we should perform reassociation as normal immediates. gcc/ChangeLog: PR target/115921 * config/riscv/riscv.md (<optab>_shift_reverse): Only check popcount_hwi if !TARGET_ZBS.
-
Jin Ma authored
When the vsetvl instructions of the two RVV instructions are merged using "use_max_sew", it is possible to update the sew of prev if prev.sew < next.sew, but keep the original ratio, which is obviously wrong. when the subsequent instructions are equal to the wrong ratio, it is possible to generate the wrong "vsetvli zero,zero" instruction, which will lead to unknown avl. gcc/ChangeLog: * config/riscv/riscv-vsetvl.cc (demand_system::use_max_sew): Also set the ratio for PREV. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/bug-10.c: New test.
-
Vineet Gupta authored
This seeming benign mistake caused a massive SPEC2017 Cactu regression (2.1 trillion insn to 2.5 trillion) wiping out all the gains from my recent sched1 improvement. Thankfully the issue was trivial to fix even if hard to isolate. On BPI3: Before bug ---------- | Performance counter stats for './cactusBSSN_r_base-1': | | 4,557,471.02 msec task-clock:u # 1.000 CPUs utilized | 1,245 context-switches:u # 0.273 /sec | 1 cpu-migrations:u # 0.000 /sec | 205,376 page-faults:u # 45.064 /sec | 7,291,944,801,307 cycles:u # 1.600 GHz | 2,134,835,735,951 instructions:u # 0.29 insn per cycle | 10,799,296,738 branches:u # 2.370 M/sec | 15,308,966 branch-misses:u # 0.14% of all branches | | 4557.710508078 seconds time elapsed Bug --- | Performance counter stats for './cactusBSSN_r_base-2': | | 4,801,813.79 msec task-clock:u # 1.000 CPUs utilized | 8,066 context-switches:u # 1.680 /sec | 1 cpu-migrations:u # 0.000 /sec | 203,836 page-faults:u # 42.450 /sec | 7,682,826,638,790 cycles:u # 1.600 GHz | 2,503,133,291,344 instructions:u # 0.33 insn per cycle ^^^^^^^^^^^^^^^^^ | 10,799,287,796 branches:u # 2.249 M/sec | 16,641,200 branch-misses:u # 0.15% of all branches | | 4802.616638386 seconds time elapsed | Fix --- | Performance counter stats for './cactusBSSN_r_base-3': | | 4,556,170.75 msec task-clock:u # 1.000 CPUs utilized | 1,739 context-switches:u # 0.382 /sec | 0 cpu-migrations:u # 0.000 /sec | 203,458 page-faults:u # 44.655 /sec | 7,289,854,613,923 cycles:u # 1.600 GHz | 2,134,854,070,916 instructions:u # 0.29 insn per cycle | 10,799,296,807 branches:u # 2.370 M/sec | 15,403,357 branch-misses:u # 0.14% of all branches | | 4556.445490123 seconds time elapsed Fixes: 46888571 ("RISC-V: Add cr and cf constraint") Signed-off-by:
Vineet Gupta <vineetg@rivosinc.com> gcc/ChangeLog: * config/riscv/riscv.cc (riscv_register_move_cost): Remove buggy check.
-
Paul-Antoine Arras authored
Add support to the Fortran parser for the OpenMP syntax that allows a comma after the directive name and between clauses of declare variant. The C and C++ parsers already support this syntax so only a new test is added. gcc/fortran/ChangeLog: * openmp.cc (gfc_match_omp_declare_variant): Match comma after directive name and between clauses. Emit more useful diagnostics. gcc/testsuite/ChangeLog: * gfortran.dg/gomp/declare-variant-2.f90: Remove error test for a comma after the directive name. Add tests for other invalid syntaxes (extra comma and invalid clause). * c-c++-common/gomp/adjust-args-5.c: New test. * gfortran.dg/gomp/adjust-args-11.f90: New test.
-
Jin Ma authored
Correct logic on 64-bit host: ... bseti a5,zero,38 bseti a5,a5,63 addi a5,a5,-1 and a4,a4,a5 ... Wrong logic on 32-bit host: ... li a5,64 bseti a5,a5,31 addi a5,a5,-1 and a4,a4,a5 ... gcc/ChangeLog: * config/riscv/riscv.cc (riscv_build_integer_1): Change 1UL/1ULL to HOST_WIDE_INT_1U. gcc/testsuite/ChangeLog: * gcc.target/riscv/zbs-bug.c: New test.
-
Paul-Antoine Arras authored
Without the target directive, the test would run on the host but still try to use device pointers, which causes a segfault. libgomp/ChangeLog: * testsuite/libgomp.fortran/dispatch-1.f90: Add missing target directive.
-
Gaius Mulley authored
P2SymBuild.mod.BuildSubrange does not use a virtual token and therefore any error message containing a subrange type produces poor location carots. This patch rewrites BuildSubrange and the buildError4 procedure in M2Check.mod (which is only called when there is a formal/actual parameter mismatch). buildError4 now issues a sub error for the formal and actual type declaration highlighing the type mismatch. gcc/m2/ChangeLog: PR modula2/118453 * gm2-compiler/M2Check.mod (buildError4): Call MetaError1 for the actual and formal parameter type. * gm2-compiler/P2Build.bnf (SubrangeType): Construct a virtual token containing the subrange type declaration. (PrefixedSubrangeType): Ditto. * gm2-compiler/P2SymBuild.def (BuildSubrange): Add tok parameter. * gm2-compiler/P2SymBuild.mod (BuildSubrange): Use tok parameter, rather than the token at the start of the subrange. gcc/testsuite/ChangeLog: PR modula2/118453 * gm2/pim/fail/badbecomes2.mod: New test. * gm2/pim/fail/badparamset1.mod: New test. * gm2/pim/fail/badparamset2.mod: New test. * gm2/pim/fail/badsyntaxset1.mod: New test. Signed-off-by:
Gaius Mulley <gaiusmod2@gmail.com>
-
Jeff Law authored
This resurrects a patch from a bit over 2 years ago that I never wrapped up. IIRC, I ended up up catching covid, then in the hospital for an unrelated issue and it just got dropped on the floor in the insanity. The basic idea here is to help postreload-cse eliminate more const/copies by recording a small set of conditional equivalences (as Richi said in 2022, "Ick"). It was originally to help eliminate an unnecessary constant load I saw in coremark, but as seen in BZ107455 the same issues show up in real code as well. Bootstrapped and regression tested on x86-64, also been through multiple spins in my tester. Changes since v2: - Simplified logic for blocks to examine - Remove redundant tests when filtering blocks to examine - Remove bogus check which only allowed reg->reg copies Changes since v1: Richard B and Richard S both had good comments last time around and their requests are reflected in this update: - Use rtx_equal_p rather than pointer equality - Restrict to register "destinations" - Restrict to integer modes - Adjust entry block handling My own wider scale testing resulted in a few more changes. - Robustify extracting the (set (pc) ... ), which then required ... - Handle if src/dst are clobbered by the conditional branch - Fix logic error causing too many equivalences to be recorded PR rtl-optimization/107455 gcc/ * postreload.cc (reload_cse_regs_1): Take advantage of conditional equivalences. gcc/testsuite * gcc.target/riscv/pr107455-1.c: New test. * gcc.target/riscv/pr107455-2.c: New test.
-
Alexandre Oliva authored
If a single-bit bitfield takes up the sign bit of a storage unit, comparing the corresponding bitfield between two objects loads the storage units, XORs them, converts the result to signed char, and compares it with zero: ((signed char)(a.<byte> ^ c.<byte>) >= 0). fold_truth_andor_for_ifcombine recognizes the compare with zero as a sign bit test, then it decomposes the XOR into an equality test. The problem is that, after this decomposition, that figures out the width of the accessed fields, we apply the sign bit mask to the left-hand operand of the compare, but we failed to also apply it to the right-hand operand when both were taken from the same XOR. This patch fixes that. for gcc/ChangeLog PR tree-optimization/118409 * gimple-fold.cc (fold_truth_andor_for_ifcombine): Apply the signbit mask to the right-hand XOR operand too. for gcc/testsuite/ChangeLog PR tree-optimization/118409 * gcc.dg/field-merge-20.c: New.
-
Jakub Jelinek authored
Something I've noticed during working on the crc wrong-code fix. My first version of the patch failed because of no longer matching some expected strings in the assembly, so I had to add TDF_DETAILS debugging into the -fdump-rtl-expand-details dump which the crc tests can use. For PR115910 Andrew has added similar note for the division/modulo case if it is positive and we can choose either unsigned or signed division. The problem is that unlike most other TDF_DETAILS diagnostics, this is not done before emitting the IL for the function, but during it. Other messages there are prefixed with ;;, both details on what it is doing and the GIMPLE IL for which it expands RTL, so the ;; Generating RTL for gimple basic block 4 ;; (code_label 13 12 14 2 (nil) [0 uses]) (note 14 13 0 NOTE_INSN_BASIC_BLOCK) positive division: unsigned cost: 30; signed cost: 28 ;; return _4; message in between just looks weird and IMHO should be ;; prefixed. 2025-01-13 Jakub Jelinek <jakub@redhat.com> PR target/115910 * expr.cc (expand_expr_divmod): Prefix the TDF_DETAILS note with ";; " and add a space before (needed tie breaker). Formatting fixes.
-
Martin Jambor authored
This commit makes the contrib/check-MAINTAINERS.py script happy about our MAINTAINERS file. I hope that it knows best how things ought to be and so am committing this as obvious. ChangeLog: 2025-01-13 Martin Jambor <mjambor@suse.cz> * MAINTAINERS: Fix the name order of the Write After Approval section.
-
Pascal Obry authored
gcc/ada/ChangeLog: * doc/gnat_ugn/platform_specific_information.rst: Update. * gnat_ugn.texi: Regenerate.
-
Javier Miranda authored
Partially revert the fix for sem_ch13.adb as it does not comply with RM 13.14(7.2/5). gcc/ada/ChangeLog: * sem_ch13.adb (Check_Aspect_At_End_Of_Declarations): Restore calls to Preanalyze_Spec_Expression that were replaced by calls to Preanalyze_And_Resolve. Add documentation. (Check_Aspect_At_Freeze_Point): Ditto.
-
Pascal Obry authored
gcc/ada/ChangeLog: * mdll.adb: For the created DLL to be relocatable we do not want to use the base file name when calling gnatdll. * gnatdll.adb: Removes option -d which is not working anymore. And when using a truly relocatable DLL the base-address has no real meaning. Also reword the usage string for -d as we do not want to specify relocatable as gnatdll can be used to create both relocatable and non relocatable DLL.
-
Piotr Trojanek authored
GNAT already emits a style warning when redundant parentheses appear inside logical and short-circuit operators. A similar warning will be soon emitted for unary operators as well. This patch removes the redundant parentheses to avoid build errors. gcc/ada/ChangeLog: * libgnat/a-strunb.ads: Remove redundant parentheses inside NOT operators.
-
Javier Miranda authored
Fix regression in the SPARK 2014 testsuite. gcc/ada/ChangeLog: * sem_util.adb (Build_Actual_Subtype_Of_Component): No action under preanalysis. * sem_ch5.adb (Set_Assignment_Type): If the right-hand side contains target names, expansion has been disabled to prevent expansion that might move target names out of the context of the assignment statement. Restore temporarily the current compilation mode so that the actual subtype can be built.
-
Piotr Trojanek authored
GNAT already emits a style warning when redundant parentheses appear inside logical and short-circuit operators. A similar warning is now emitted for unary operators as well. gcc/ada/ChangeLog: * par-ch4.adb (P_Factor): Warn when the operand of a unary operator doesn't require parentheses.
-
Piotr Trojanek authored
GNAT already emits a style warning when redundant parentheses appear inside logical and short-circuit operators. A similar warning will be soon emitted for unary operators as well. This patch removes the redundant parentheses to avoid future build errors. gcc/ada/ChangeLog: * libgnat/s-genbig.adb: Remove redundant parentheses in comments.
-
Piotr Trojanek authored
GNAT already emits a style warning when redundant parentheses appear inside logical and short-circuit operators. A similar warning will be soon emitted for unary operators as well. This patch removes the redundant parentheses to avoid future build errors. gcc/ada/ChangeLog: * checks.adb, exp_dist.adb, exp_imgv.adb, exp_util.adb, libgnarl/a-reatim.adb, libgnat/a-coinve.adb, libgnat/a-nbnbre.adb, libgnat/a-ngcoty.adb, libgnat/a-ngelfu.adb, libgnat/a-ngrear.adb, libgnat/a-strbou.ads, libgnat/a-strfix.ads, libgnat/a-strsea.adb, libgnat/a-strsea.ads, libgnat/a-strsup.ads, libgnat/a-strunb__shared.ads, libgnat/g-alleve.adb, libgnat/g-spitbo.adb, libgnat/s-aridou.adb, libgnat/s-arit32.adb, libgnat/s-dourea.ads, libgnat/s-genbig.adb, libgnat/s-imager.adb, libgnat/s-statxd.adb, libgnat/s-widthi.adb, sem_attr.adb, sem_ch10.adb, sem_ch3.adb, sem_ch6.adb, sem_ch7.adb, sem_dim.adb, sem_prag.adb, sem_res.adb, uintp.adb: Remove redundant parentheses inside NOT and ABS operators.
-
Piotr Trojanek authored
Use the same logic for warning about redundant parentheses in lower and upper bounds of a discrete range. This fixes a spurious warning that, if followed, would render the code illegal. gcc/ada/ChangeLog: * par-ch3.adb (P_Discrete_Range): Detect redundant parentheses in the lower bound like in the upper bound.
-
Gary Dismukes authored
The compiler was recursing endlessly when analyzing an aggregate of an array type whose component subtype has a static predicate and the component expressions are static, repeatedly transforming the aggregate first into a string literal and then back into an aggregate. This is fixed by suppressing the transformation to a string literal in the case where the component subtype has predicates. gcc/ada/ChangeLog: * sem_aggr.adb (Resolve_Aggregate): Add another condition to prevent rewriting an aggregate whose type is an array of characters, testing for the presence of predicates on the component type.
-
Piotr Trojanek authored
Code cleanup; semantics is unaffected. gcc/ada/ChangeLog: * exp_ch4.adb: (Expand_N_Not_In): Preserve Alternatives in expanded membership operator just like preserving Right_Opnd (though only one of these fields is present at a time). * par-ch4.adb (P_Membership_Test): Remove redundant setting of fields to their default values.
-
Piotr Trojanek authored
Fix a glitch in condition that effectively caused detection of redundant parentheses in upper range bounds to be dead code. gcc/ada/ChangeLog: * par-ch3.adb (P_Discrete_Range): Replace N_Subexpr, which was catching all subexpressions, with kinds that catch nodes that require parentheses to become "simple expressions".
-
Eric Botcazou authored
gcc/ada/ChangeLog: * libgnat/s-valrea.adb (Large_Powfive) [2 parameters]: Add a couple of additional comments.
-
Piotr Trojanek authored
According to Ada grammar, raise expression is an expression, but requires parens to be a simple_expression. We wrongly classified raise expressions as expressions, because we mishandled a global state variable in the parser. This patch causes some illegal code to be rejected. gcc/ada/ChangeLog: * par-ch4.adb (P_Relation): Prevent Expr_Form to be overwritten when parsing the raise expression itself. (P_Simple_Expression): Fix manipulation of Expr_Form.
-
Richard Biener authored
Here's another fix for a missing check that an IV value fits in a HIW. It's originally from Stefan. PR tree-optimization/117119 * tree-data-ref.cc (initialize_matrix_A): Check whether an INTEGER_CST fits in HWI, otherwise return chrec_dont_know. * gcc.dg/torture/pr117119.c: New testcase. Co-Authored-By:
Stefan Schulze Frielinghaus <stefansf@linux.ibm.com>
-
Thomas Schwinge authored
As of the recent commit 65286465 "Fortran: Fix location_t in gfc_get_extern_function_decl; [...]" change: The declaration created by gfc_get_extern_function_decl used input_location as DECL_SOURCE_LOCATION, which gave rather odd results with 'declared here' diagnostic. - It is much more useful to use the gfc_symbol's declated_at, which this commit now does. ..., we're no longer using the 'dg-bogus' location informations, as pointed out for one class of additional notes of 'gfortran.dg/goacc/routine-external-level-of-parallelism-2.f', once added in commit 03eb7791 "Add 'dg-note', 'dg-lto-note'". Therefore, un-XFAILed 'dg-note's rather than XFAILed 'dg-bogus'es. gcc/testsuite/ * gfortran.dg/goacc/routine-external-level-of-parallelism-2.f: Un-XFAIL 'dg-note's.
-