aboutsummaryrefslogtreecommitdiff
path: root/gcc
AgeCommit message (Collapse)AuthorFilesLines
2023-07-07Update ChangeLog and version files for releasereleases/gcc-10.5.0releases/gcc-10Richard Biener17-1/+65
2023-07-07Daily bump.GCC Administrator1-1/+1
2023-07-06Daily bump.GCC Administrator1-1/+1
2023-07-05Daily bump.GCC Administrator1-1/+1
2023-07-04Daily bump.GCC Administrator1-1/+1
2023-07-03Daily bump.GCC Administrator1-1/+1
2023-07-02Daily bump.GCC Administrator3-1/+18
2023-07-01d: Fix ICE in setValue, at d/dmd/dinterpret.c:7013Iain Buclaw2-1/+63
Backports ICE fix from upstream. When casting null to integer or real, instead of painting the type on the NullExp, we emplace an IntegerExp/RealExp with the value zero. Same as when casting from NullExp to bool. Reviewed-on: https://github.com/dlang/dmd/pull/13172 PR d/110511 gcc/d/ChangeLog: * dmd/dinterpret.c (Interpreter::visit (CastExp *)): Handle casting null to int or float. gcc/testsuite/ChangeLog: * gdc.test/compilable/test21794.d: New test. (cherry picked from commit 066385c918485d4cef5c243d3b0691193df382de)
2023-07-01Daily bump.GCC Administrator3-1/+40
2023-06-30c++: bogus warning with value init of const pmf [PR92752]Patrick Palka2-1/+20
Here we're emitting a -Wignored-qualifiers warning for an intermediate compiler-generated cast of nullptr to 'method-type* const' as part of value initialization of a const pmf. This patch suppresses the warning by instead casting to the corresponding unqualified type. PR c++/92752 gcc/cp/ChangeLog: * typeck.c (build_ptrmemfunc): Cast a nullptr constant to the unqualified pointer type not the qualified one. gcc/testsuite/ChangeLog: * g++.dg/warn/Wignored-qualifiers2.C: New test. Co-authored-by: Jason Merrill <jason@redhat.com> (cherry picked from commit e971990cbda091b4caf5e1a5bded5121068934e4)
2023-06-30c++: Fix reference NTTP binding to noexcept fn [PR97420]Patrick Palka3-26/+23
Here, in C++17 mode, convert_nontype_argument_function is rejecting binding a non-noexcept function reference template parameter to a noexcept function (encoded as the template argument '*(int (&) (int)) &f'). The first roadblock to making this work is that the argument is wrapped an an implicit INDIRECT_REF, so we need to unwrap it before calling strip_fnptr_conv. The second roadblock is that the NOP_EXPR cast converts from a function pointer type to a reference type while simultaneously removing the noexcept qualification, and fnptr_conv_p doesn't consider this cast to be a function pointer conversion. This patch fixes this by making fnptr_conv_p treat REFERENCE_TYPEs and POINTER_TYPEs interchangeably. Finally, in passing, this patch also simplifies noexcept_conv_p by removing a bunch of redundant checks already performed by its only caller fnptr_conv_p. PR c++/97420 gcc/cp/ChangeLog: * cvt.c (noexcept_conv_p): Remove redundant checks and simplify. (fnptr_conv_p): Don't call non_reference. Use INDIRECT_TYPE_P instead of TYPE_PTR_P. * pt.c (convert_nontype_argument_function): Look through implicit INDIRECT_REFs before calling strip_fnptr_conv. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/noexcept68.C: New test. (cherry picked from commit b4329e3dd6fb7c78948fcf9d2f5b9d873deec284)
2023-06-30Daily bump.GCC Administrator2-1/+9
2023-06-28go: Update usage of TARGET_AIX to TARGET_AIX_OSPaul E. Murphy2-6/+6
TARGET_AIX is defined to a non-zero value on linux and maybe other powerpc64le targets. This leads to unexpected behavior such as dropping the .go_export section when linking a shared library on linux/powerpc64le. Instead, use TARGET_AIX_OS to toggle AIX specific behavior. Fixes golang/go#60798. 2023-06-22 Paul E. Murphy <murphyp@linux.ibm.com> gcc/go/ * go-backend.c [TARGET_AIX]: Rename and update usage to TARGET_AIX_OS. * go-lang.c: Likewise. (cherry picked from commit b76cd1ec361712e1ac9ca5e0246da24ea2b78916)
2023-06-29Daily bump.GCC Administrator3-1/+16
2023-06-28Make option mvzeroupper independent of optimization level.liuhongt3-7/+19
pass_insert_vzeroupper is under condition TARGET_AVX && TARGET_VZEROUPPER && flag_expensive_optimizations && !optimize_size But the document of mvzeroupper doesn't mention the insertion required -O2 and above, it may confuse users when they explicitly use -Os -mvzeroupper. ------------ mvzeroupper Target Mask(VZEROUPPER) Save Generate vzeroupper instruction before a transfer of control flow out of the function. ------------ The patch moves flag_expensive_optimizations && !optimize_size to ix86_option_override_internal. It makes -mvzeroupper independent of optimization level, but still keeps the behavior of architecture tuning(emit_vzeroupper) unchanged. gcc/ChangeLog: * config/i386/i386-features.c (pass_insert_vzeroupper:gate): Move flag_expensive_optimizations && !optimize_size to .. * config/i386/i386-options.c (ix86_option_override_internal): .. this, it makes -mvzeroupper independent of optimization level, but still keeps the behavior of architecture tuning(emit_vzeroupper) unchanged. (rest_of_handle_insert_vzeroupper): Remove flag_expensive_optimizations && !optimize_size. gcc/testsuite/ChangeLog: * gcc.target/i386/avx-vzeroupper-29.c: New testcase.
2023-06-28Daily bump.GCC Administrator1-1/+1
2023-06-27Daily bump.GCC Administrator3-1/+19
2023-06-26d: Suboptimal codegen for __builtin_expect(cond, false)Iain Buclaw2-12/+41
Since PR96435, both boolean objects and expressions have been evaluated in the following way. (*(ubyte*)&obj_or_expr) & 1 It has been noted that sometimes this can cause the back-end to optimize in non-obvious ways - in particular with __builtin_expect. This @safe feature is now restricted to just when reading the value of a bool field that comes from a union. PR d/110359 gcc/d/ChangeLog: * d-convert.cc (convert_for_rvalue): Only apply the @safe boolean conversion to boolean fields of a union. (convert_for_condition): Call convert_for_rvalue in the default case. gcc/testsuite/ChangeLog: * gdc.dg/pr110359.d: New test. (cherry picked from commit ab98db1e8c1b997414539f41b7fb814019497d8d)
2023-06-26Daily bump.GCC Administrator1-1/+1
2023-06-25Daily bump.GCC Administrator1-1/+1
2023-06-24Daily bump.GCC Administrator1-1/+1
2023-06-23Daily bump.GCC Administrator1-1/+1
2023-06-22Daily bump.GCC Administrator1-1/+1
2023-06-21Daily bump.GCC Administrator3-1/+20
2023-06-20rs6000: Guard __builtin_{un,}pack_vector_int128 with vsx [PR109932]Kewen Lin3-2/+44
As PR109932 shows, builtins __builtin_{un,}pack_vector_int128 should be guarded under vsx rather than power7, as their corresponding bif patterns have the conditions TARGET_VSX and VECTOR_MEM_ALTIVEC_OR_VSX_P (V1TImode). This patch is to ensure __builtin_{un,}pack_vector_int128 only available under vsx. PR target/109932 gcc/ChangeLog: * config/rs6000/rs6000-builtin.def (BU_VSX_MISC_2): New macro. ({un,}pack_vector_int128): Use BU_VSX_MISC_2 instead of BU_P7_MISC_2. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr109932-1.c: New test. * gcc.target/powerpc/pr109932-2.c: New test. (cherry picked from commit db291447877aae67979ce3655fcc6fc877f57c6a)
2023-06-20Daily bump.GCC Administrator3-1/+18
2023-06-19rs6000: Don't use TFmode for 128 bits fp constant in toc [PR110011]Kewen Lin2-1/+43
As PR110011 shows, when encoding 128 bits fp constant into toc, we adopts REAL_VALUE_TO_TARGET_LONG_DOUBLE which is to find the first float mode with LONG_DOUBLE_TYPE_SIZE bits of precision, it would be TFmode here. But the 128 bits fp constant can be with mode IFmode or KFmode, which doesn't necessarily have the same underlying float format as the one of TFmode, like this PR exposes, with option -mabi=ibmlongdouble TFmode has ibm_extended_format while KFmode has ieee_quad_format, mixing up the formats (the encoding/decoding ways) would cause unexpected results. This patch is to make it use constant's own mode instead of TFmode for real_to_target call. PR target/110011 gcc/ChangeLog: * config/rs6000/rs6000.c (output_toc): Use the mode of the 128-bit floating constant itself for real_to_target call. gcc/testsuite/ChangeLog: * gcc.target/powerpc/pr110011.c: New test. (cherry picked from commit 388809f2afde874180da0669c669e241037eeba0)
2023-06-19Daily bump.GCC Administrator1-1/+1
2023-06-18Daily bump.GCC Administrator1-1/+1
2023-06-17Daily bump.GCC Administrator1-1/+1
2023-06-16Daily bump.GCC Administrator1-1/+1
2023-06-15Daily bump.GCC Administrator1-1/+1
2023-06-14Daily bump.GCC Administrator1-1/+1
2023-06-13Daily bump.GCC Administrator1-1/+1
2023-06-12Daily bump.GCC Administrator1-1/+1
2023-06-11Daily bump.GCC Administrator1-1/+1
2023-06-10Daily bump.GCC Administrator4-1/+32
2023-06-09Darwin, PPC: Fix struct layout with pragma pack [PR110044].Iain Sandoe5-1/+108
This bug was essentially that darwin_rs6000_special_round_type_align() was ignoring externally-imposed capping of field alignment. Signed-off-by: Iain Sandoe <iain@sandoe.co.uk> PR target/110044 gcc/ChangeLog: * config/rs6000/rs6000.c (darwin_rs6000_special_round_type_align): Make sure that we do not have a cap on field alignment before altering the struct layout based on the type alignment of the first entry. gcc/testsuite/ChangeLog: * gcc.target/powerpc/darwin-abi-13-0.c: New test. * gcc.target/powerpc/darwin-abi-13-1.c: New test. * gcc.target/powerpc/darwin-abi-13-2.c: New test. * gcc.target/powerpc/darwin-structs-0.h: New test. (cherry picked from commit 84d080a29a780973bef47171ba708ae2f7b4ee47)
2023-06-09fortran: Fix ICE on pr96024.f90 on big-endian hosts [PR96024]Jakub Jelinek1-1/+2
The pr96024.f90 testcase ICEs on big-endian hosts. The problem is that length->val.integer is accessed after checking length->expr_type == EXPR_CONSTANT, but it is a CHARACTER constant which uses length->val.character union member instead and on big-endian we end up reading constant 0x100000000 rather than some small number on little-endian and if target doesn't have enough memory for 4 times that (i.e. 16GB allocation), it ICEs. 2023-06-09 Jakub Jelinek <jakub@redhat.com> PR fortran/96024 * primary.c (gfc_convert_to_structure_constructor): Only do constant string ctor length verification and truncation/padding if constant length has INTEGER type. (cherry picked from commit 4cf6e322adc19f927859e0a5edfa93cec4b8c844)
2023-06-09Daily bump.GCC Administrator1-1/+1
2023-06-08Daily bump.GCC Administrator1-1/+1
2023-06-07Daily bump.GCC Administrator1-1/+1
2023-06-06Daily bump.GCC Administrator1-1/+1
2023-06-05Daily bump.GCC Administrator1-1/+1
2023-06-04Daily bump.GCC Administrator1-1/+1
2023-06-03Daily bump.GCC Administrator1-1/+1
2023-06-02Daily bump.GCC Administrator2-1/+9
2023-06-01doc: Fix description of x86 -m32 option [PR109954]Jonathan Wakely1-1/+1
This option does not imply -march=i386 so it's incorrect to say it generates code that will run on "any i386 system". gcc/ChangeLog: PR target/109954 * doc/invoke.texi (x86 Options): Fix description of -m32 option. (cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)
2023-06-01Daily bump.GCC Administrator1-1/+1
2023-05-31Daily bump.GCC Administrator1-1/+1