- Feb 13, 2024
-
-
Richard Biener authored
The SLP permute optimization rewrite fixed this. PR tree-optimization/113896 * g++.dg/torture/pr113896.C: New testcase.
-
Richard Biener authored
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.
-
Rainer Orth authored
As it turned out, my patch to complete the libgm2 autoconf macros works on both Linux/sparc64 and Linux/x86_64, but breaks Solaris bootstrap: /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int m2iso_wraptime_gettimeofday(void*, timezone*)': /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:148:24: error: invalid conversion from 'void*' to 'timeval*' [-fpermissive] 148 | return gettimeofday (tv, tz); | ^~ | | | void* In file included from /usr/include/sys/select.h:27, from /usr/include/sys/types.h:665, from /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:35: /usr/include/sys/time.h:444:18: note: initializing argument 1 of 'int gettimeofday(timeval*, void*)' 444 | int gettimeofday(struct timeval *_RESTRICT_KYWD, void *_RESTRICT_KYWD); | ^ /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc: In function 'int m2iso_wraptime_settimeofday(void*, timezone*)': /vol/gcc/src/hg/master/local/libgm2/libm2iso/wraptime.cc:165:24: error: invalid conversion from 'void*' to 'timeval*' [-fpermissive] 165 | return settimeofday (tv, tz); | ^~ | | | void* /usr/include/sys/time.h:431:18: note: initializing argument 1 of 'int settimeofday(timeval*, void*)' 431 | int settimeofday(struct timeval *, void *); | ^~~~~~~~~~~~~~~~ This happens because on Linux only HAVE_[GS]ETTIMEOFDAY is defined, while Solaris has both that and HAVE_STRUCT_TIMEZONE, selecting different implementations. Fixed by casting tv to struct timeval *. I thought about changing the signatures instead to take a struct timeval * instead, but that seemed risky given that there's a HAVE_STRUCT_TIMEVAL, so would probably break other targets. Bootstrapped without regressions on i386-pc-solaris2.11, sparc-sun-solaris2.11, and x86_64-pc-linux-gnu. 2024-02-13 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> libgm2: * libm2iso/wraptime.cc [HAVE_STRUCT_TIMEZONE && HAVE_GETTIMEOFDAY] (EXPORT(gettimeofday)): Cast tv to struct timeval *. [HAVE_STRUCT_TIMEZONE && HAVE_SETTIMEOFDAY] (EXPORT(settimeofday)): Likewise.
-
Richard Biener authored
PR tree-optimization/113831 * tree-ssa-sccvn.cc (ao_ref_init_from_vn_reference): Fix typo in comment.
-
Richard Biener authored
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.
-
Tamar Christina authored
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.
-
Alex Coplan authored
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.
-
Richard Biener authored
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.
-
Jakub Jelinek authored
As I wrote earlier, I was seeing FAIL: gcc.dg/torture/bitint-24.c -O0 execution test FAIL: gcc.dg/torture/bitint-24.c -O2 execution test with the ia32 _BitInt enablement patch on i686-linux. I thought floatbitintxf.c was miscompiled with -O2 -march=i686 -mtune=generic, but it turned out to be UB in it. If a signed _BitInt to be converted to binary floating point has (after sign extension from possible partial limb to full limb) one or more most significant limbs equal to all ones and then in the limb below (the most significant non-~(UBILtype)0 limb) has the most significant limb cleared, like for 32-bit limbs 0x81582c05U, 0x0a8b01e4U, 0xc1b8b18fU, 0x2aac2a08U, -1U, -1U then bitint_reduce_prec can't reduce it to that 0x2aac2a08U limb, so msb is all ones and precision is negative (so it reduced precision from 161 to 192 bits down to 160 bits, in theory could go as low as 129 bits but that wouldn't change anything on the following behavior). But still iprec is negative, -160 here. For that case (i.e. where we are dealing with an negative input), the code was using 65 - __builtin_clzll (~msb) to compute how many relevant bits we have from the msb. Unfortunately that invokes UB for msb all ones. The right number of relevant bits in that case is 1 though (like for -2 it is 2 and -4 or -3 3 as already computed) - all we care about from that is that the most significant bit is set (i.e. the number is negative) and the bits below that should be supplied from the limbs below. So, the following patch fixes it by special casing it not to invoke UB. For msb 0 we already have a special case from before (but that is also different because msb 0 implies the whole number is 0 given the way bitint_reduce_prec works - even if we have limbs like ..., 0x80000000U, 0U the reduction can skip the most significant limb and msb then would be the one below it), so if iprec > 0, we already don't call __builtin_clzll on 0. 2024-02-13 Jakub Jelinek <jakub@redhat.com> * soft-fp/bitint.h (FP_FROM_BITINT): If iprec < 0 and msb is all ones, just set n to 1 instead of using __builtin_clzll (~msb).
-
Jakub Jelinek authored
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.
-
Steve Kargl authored
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.
-
David Malcolm authored
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>
-
GCC Administrator authored
-
- Feb 12, 2024
-
-
Jerry DeLisle authored
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.
-
Paul Keir authored
A call to `basic_string::clear()` in the std::string move assignment operator leads to a constexpr error from an access of inactive union member `_M_local_buf` in the added test (`test_move()`). Changing `__str._M_local_buf` to `__str._M_use_local_data()` in `operator=(basic_string&& __str)` fixes this. PR libstdc++/113294 libstdc++-v3/ChangeLog: * include/bits/basic_string.h (basic_string::operator=): Use _M_use_local_data() instead of _M_local_buf on the moved-from string. * testsuite/21_strings/basic_string/modifiers/constexpr.cc (test_move): New test. Signed-off-by:
Paul Keir <paul.keir@uws.ac.uk> Reviewed-by:
Patrick Palka <ppalka@redhat.com> Reviewed-by:
Jonathan Wakely <jwakely@redhat.com>
-
Marek Polacek authored
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.
-
Jakub Jelinek authored
lower-bitint: Fix handle_cast when used e.g. in comparisons of precisions 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.
-
Jakub Jelinek authored
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.
-
Jakub Jelinek authored
This patch depends on the libiberty/vprintf-support.c change. 2024-02-12 Jakub Jelinek <jakub@redhat.com> * gengtype.cc (adjust_field_rtx_def): Use HOST_SIZE_T_PRINT_UNSIGNED and cast to fmt_size_t instead of %lu and cast to unsigned long.
-
Jakub Jelinek authored
As I wrote earlier and we've discussed on IRC, with the ia32 _BitInt enablement patch this testcase FAILs on ia32, there is nothing vectorized in there, even with -mavx512{vl,bw,dq}, so no dbgcnt messages are emitted. The following patch instead prunes it. 2024-02-12 Jakub Jelinek <jakub@redhat.com> * gcc.dg/pr113693.c: Guard _BitInt(837) use with __BITINT_MAXWIDTH__ >= 837. Use dg-prune-output instead of dg-message for dbgcnt message.
-
Jakub Jelinek authored
When writing the HOST_SIZE_T_PRINT_UNSIGNED incremental patch, my first bootstrap failed on i686-linux. That is because I've also had @@ -1344,8 +1344,10 @@ adjust_field_rtx_def (type_p t, options_ } subfields = create_field (subfields, t, - xasprintf (".fld[%lu].%s", - (unsigned long) aindex, + xasprintf (".fld[" + HOST_SIZE_T_PRINT_UNSIGNED + "].%s", + (fmt_size_t) aindex, subname)); subfields->opt = nodot; if (t == note_union_tp) hunk in gengtype.cc. While sprintf obviously can print in this case %llu with fmt_size_t being unsigned long long (that is another bug I'll fix incrementally), seems libiberty_vprintf_buffer_size can't deal with that, it ignores h, hh, l, ll and L modifiers and unconditionally, estimates 30 chars as upper bounds for integers (that is fine) and then uses (void) va_arg (ap, int); to skip over the argument regardless if it was %d, %ld, %lld, %hd, %hhd etc. Now, on x86_64 that happens to work fine probably for all of those, on ia32 for everything but %lld, because it then skips just one half of the long long argument; now as there is %s after it, it will try to compute strlen not from the pointer argument corresponding to %s, but from the most significant half of the previous long long argument. So, the following patch attempts not to completely ignore the modifiers, but figure out from them whether to va_arg an int (used for h and hh as well), or long, or long long, or size_t, or ptrdiff_t - added support for z and t there, plus for Windows I64. And also %Lf etc. for long double. 2024-02-12 Jakub Jelinek <jakub@redhat.com> * vprintf-support.c (libiberty_vprintf_buffer_size): Handle properly l, ll, z, t or on _WIN32 I64 modifiers for diouxX and L modifier for fFgGeE.
-
Iain Buclaw authored
Each major release is not binary compatible with the previous. PR d/113667 libphobos/ChangeLog: * configure: Regenerate. * configure.ac (libtool_VERSION): Update to 5:0:0.
-
Iain Buclaw authored
The cause of the ICE was that TYPE_DECLs were only being generated for structs with members, not opaque structs. PR d/113125 gcc/d/ChangeLog: * types.cc (TypeVisitor::visit (TypeStruct *)): Generate TYPE_DECL and apply UDAs to opaque struct declarations. gcc/testsuite/ChangeLog: * gdc.dg/imports/pr113125.d: New test. * gdc.dg/pr113125.d: New test.
-
Iain Buclaw authored
D front-end changes: - Import latest fixes from dmd v2.107.0. D runtime changes: - Import latest fixes from druntime v2.107.0. Included in the merge are the fix for PR113772, and new testsuite directives to enable fixing PR104739. PR d/113772 gcc/d/ChangeLog: * dmd/MERGE: Merge upstream dmd 11240a9663. * d-builtins.cc (build_frontend_type): Update for new front-end interface. * types.cc (same_type_p): Likewise. libphobos/ChangeLog: * libdruntime/MERGE: Merge upstream druntime 11240a9663.
-
Iain Buclaw authored
When generating the argument, check the isCalleeDestroyingArgs hook, and force a TARGET_EXPR to be created if true, so that a reference to the live object isn't passed directly to the function that runs dtors. When instead dealing with caller running destructors, two temporaries were being generated, one explicit temporary generated by the D front-end, and another implicitly by the code generator. This has been reduced to one by setting DECL_VALUE_EXPR on the explicit temporary to bind it to the implicit slot created for the TARGET_EXPR, as that has the shorter lifetime of the two. PR d/113758 gcc/d/ChangeLog: * d-codegen.cc (d_build_call): Force a TARGET_EXPR when callee destorys its arguments. * decl.cc (DeclVisitor::visit (VarDeclaration *)): Set SET_DECL_VALUE_EXPR on the temporary variable to make it a placeholder for the TARGET_EXPR_SLOT. gcc/testsuite/ChangeLog: * gdc.dg/torture/pr113758.d: New test.
-
Christophe Lyon authored
BUILD_INFO is currently a byproduct of checking makeinfo presence/version. INSTALL_INFO used to be defined similarly, but was removed in 2000 (!) by commit 17db6582 (svn r38141). In order to save build time, our CI overrides MAKEINFO=echo, which works when invoking 'make all' but not for 'make install' in case some info files need an update. I noticed this while testing a patch posted on the gcc-patches list, leading to an error at 'make install' time after updating tm.texi (the build reported 'new text' in tm.texi and stopped). This is because 'install' depends on 'install-info', which depends on $(DESTDIR)$(infodir)/gccint.info (among others). As discussed, it is better to detect this problem during 'make all' rather than 'make install', and we still want to detect it even if makeinfo is not available. This patch makes configure set BUILD_INFO=no-info in case makeinfo is missing/too old, which effectively makes the build rules no-ops (x$(BUILD_INFO) != xinfo), and updates Makefile.in so that 'info' dependencies are still checked. 2024-02-10 Christophe Lyon <christophe.lyon@linaro.org> gcc/ * Makefile.in: Add no-info dependency. * configure.ac: Set BUILD_INFO=no-info if makeinfo is not available. * configure: Regenerate.
-
Iain Sandoe authored
The initial heap trampoline implementation was targeting 64b platforms. As the PR demonstrates this creates an issue where it is expected that the same symbols are exported for 32 and 64b. Rather than conditionalize the exports and code-gen on x86_64, this patch provides a basic implementation of the IA32 trampoline. This also avoids potential user confusion, when a 32b target has 64b multilibs, and vice versa; which is the case for Darwin. PR target/113855 gcc/ChangeLog: * config/i386/darwin.h (DARWIN_HEAP_T_LIB): Moved to be available to all sub-targets. * config/i386/darwin32-biarch.h (DARWIN_HEAP_T_LIB): Delete. * config/i386/darwin64-biarch.h (DARWIN_HEAP_T_LIB): Delete. libgcc/ChangeLog: * config.host: Add trampoline support to x?86-linux. * config/i386/heap-trampoline.c (trampoline_insns): Provide a variant for IA32. (union ix86_trampoline): Likewise. (__gcc_nested_func_ptr_created): Implement a basic trampoline for IA32.
-
Rainer Orth authored
Two libgomp tests XPASS on Solaris (any non-Linux target actually) since their introduction: XPASS: libgomp.c/alloc-pinned-1.c execution test XPASS: libgomp.c/alloc-pinned-2.c execution test The problem is that the test just prints OS unsupported and exits successfully, while the test is XFAILed: /* { dg-xfail-run-if "Pinning not implemented on this host" { ! *-*-linux-gnu } } */ Fixed by aborting immediately after the message above in the non-Linux case. Tested on i386-pc-solaris2.11 and i686-pc-linux-gnu. 2024-02-02 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> libgomp: PR testsuite/113448 * testsuite/libgomp.c/alloc-pinned-1.c [!__linux__] (CHECK_SIZE): Call abort. * testsuite/libgomp.c/alloc-pinned-2.c [!__linux__] (CHECK_SIZE): Likewise.
-
Richard Biener authored
When we use get_ref_base_and_extent during VN and that ends up using global ranges to restrict the range of a ref we have to take care of not using the same expression in the hashtable as for a ref that could not use that global range. The following attempts to ensure this by applying similar logic as get_ref_base_and_extent to copy_reference_ops_from_ref so they behave consistent. PR tree-optimization/113831 PR tree-optimization/108355 * tree-ssa-sccvn.cc (copy_reference_ops_from_ref): When we see variable array indices and get_ref_base_and_extent can resolve those to constants fix up the ops to constants as well. (ao_ref_init_from_vn_reference): Use 'off' member for ARRAY_REF and ARRAY_RANGE_REF instead of recomputing it. (valueize_refs_1): Also fixup 'off' of ARRAY_RANGE_REF. * gcc.dg/torture/pr113831.c: New testcase. * gcc.dg/tree-ssa/ssa-fre-104.c: Likewise.
-
Rainer Orth authored
As detailed in PR modula2/113888, the 32-bit libm2pim/target.c doesn't assemble in a Linux/sparc64 multilib build. However, the root cause is that the HAVE_EXP10* macros are never defined. While I was at it, I checked for other cases where the code uses HAVE_* macros that are missing from config.h.in. This patch adds the missing checks, changes the configure checks where the names don't match what's used in the code, or corrects the code to use the right names. So far tested on sparc64-unknown-linux-gnu by building libgm2 (32 and 64-bit) and running the gm2 tests. 2024-02-12 Rainer Orth <ro@CeBiTec.Uni-Bielefeld.DE> libgm2: PR modula2/113888 * configure.ac (GM2_CHECK_LIB): Rename gettimeofday guard to HAVE_GETTIMEOFDAY. (GM_CHECK_LIB): Check for settimeofday. (GM2_CHECK_LIB): Check for exp10, exp10f, exp10l in libm. (AC_CHECK_DECLS): Check for getenv. * configure, config.h.in: Regenerate. * libm2pim/dtoa.cc: Rename <strings.h>, <string.h> guards to HAVE_STRINGS_H, HAVE_STRING_H. * libm2pim/ldtoa.cc: Likewise.
-
Pan Li authored
When build with "-Werror=format-diag", there will be one misspelled term args as below. This patch would like fix it by taking the term arguments instead. ../../gcc/config/riscv/riscv-vector-builtins.cc: In function 'tree_node* riscv_vector::resolve_overloaded_builtin(location_t, unsigned int, tree, vec<tree_node*, va_gc>*)': ../../gcc/config/riscv/riscv-vector-builtins.cc:4633:65: error: misspelled term 'args' in format; use 'arguments' instead [-Werror=format-diag] 4633 | error_at (loc, "no matching function call to %qE with empty args", fndecl); gcc/ChangeLog: * config/riscv/riscv-vector-builtins.cc (resolve_overloaded_builtin): Replace args to arguments for misspelled term. gcc/testsuite/ChangeLog: * gcc.target/riscv/rvv/base/pr113766-1.c: Adjust the test cases. Signed-off-by:
Pan Li <pan2.li@intel.com>
-
Georg-Johann Lay authored
For devices that see a part for the flash memory in the RAM address space, bit-field NVMCTRL_CTRLB.FLMAP must match the value of symbol __flmap. This is achieved by dragging in startup code from lib<mcu>.a. The mechanism is the same like for libgcc's __do_copy_data and __do_clear_bss. The code is implemented in AVR-LibC #931 and can be dragged by referencing __do_flmap_init. In addition to setting FLMAP, that code also sets bit FLMAPLOCK provided symbol __flmap_lock has a non-zero value. This protects FLMAP from future changes. When the __do_flmap_init code is not wanted, the symbol can be satisfied by linking with -Wl,--defsym,__do_flmap_init=0 gcc/ PR target/112944 * config/avr/gen-avr-mmcu-specs.cc (print_mcu) [have_flmap]: <*link_rodata_in_ram>: Spec undefs symbol __do_flmap_init when not linked with -mrodata-in-ram.
-
Richard Biener authored
This makes sure to elide degenerate virtual PHIs when moving stores across early exits. PR tree-optimization/113863 * tree-vect-data-refs.cc (vect_analyze_early_break_dependences): Record crossed virtual PHIs. * tree-vect-loop.cc (move_early_exit_stmts): Elide crossed virtual PHIs. * gcc.dg/vect/pr113863.c: New testcase.
-
GCC Administrator authored
-
- Feb 11, 2024
-
-
John David Anglin authored
2024-02-11 John David Anglin <danglin@gcc.gnu.org> gcc/testsuite/ChangeLog: * gcc.c-torture/execute/ieee/cdivchkf.c: Use ilogb and __builtin_fmax instead of ilogbf and __builtin_fmaxf.
-
Francois-Xavier Coudert authored
On darwin, symbols are prefixed with underscore, and the order of operands is reversed. gcc/testsuite/ChangeLog: * gcc.target/i386/asm-raw-symbol.c: Adjust asm patterns.
-
John David Anglin authored
2024-02-11 John David Anglin <danglin@gcc.gnu.org> libgomp/ChangeLog: PR libgomp/113843 * configure.tgt (hppa*-*-linux*): Define config_path.
-
Torbjörn SVENSSON authored
The test case for PR97969 needs updates in order to comply with recent changes in GCC14. Without these changes, failures like this can be seen on arm-none-eabi: .../pr97969.c:6:9: error: type defaults to 'int' in declaration of 'a' [-Wimplicit-int] .../pr97969.c:34:1: error: return type defaults to 'int' [-Wimplicit-int] .../pr97969.c:40:3: error: implicit declaration of function 'ae' [-Wimplicit-function-declaration] .../pr97969.c:42:3: error: implicit declaration of function 'af' [-Wimplicit-function-declaration] .../pr97969.c:43:7: error: implicit declaration of function 'ag' [-Wimplicit-function-declaration] .../pr97969.c:46:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] .../pr97969.c:48:10: error: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion] .../pr97969.c:50:8: error: implicit declaration of function 'setjmp' [-Wimplicit-function-declaration] .../pr97969.c:51:5: error: implicit declaration of function 'ah' [-Wimplicit-function-declaration] .../pr97969.c:52:5: error: implicit declaration of function 'ai' [-Wimplicit-function-declaration] .../pr97969.c:54:5: error: implicit declaration of function 'aj' [-Wimplicit-function-declaration] Patch has been verified on Linux. gcc/testsuite/ChangeLog: * gcc.target/arm/pr97969.c: Update to comply with GCC14 changes. Signed-off-by:
Torbjörn SVENSSON <torbjorn.svensson@foss.st.com>
-
GCC Administrator authored
-
- Feb 10, 2024
-
-
Alexander Westbrooks authored
ChangeLog: * MAINTAINERS: Add myself to write after approval and DCO. Signed-off-by:
Alexander Westbrooks <alexanderw@gcc.gnu.org>
-