| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
The PR88587 fix changes DECL_MODE of vars with vector type during inlining/cloning
when the vars are copied, so that their DECL_MODE matches their TYPE_MODE in
the new function. Unfortunately, the following testcase still ICEs, the var
isn't really used in the new function and so it isn't copied, but becomes
just a nonlocalized var. So we can't adjust its DECL_MODE because it
appears in multiple functions and needs different modes in between them.
The following patch changes the DEBUG_INSN creation to use TYPE_MODE instead
of DECL_MODE for vars with vector types.
2020-12-04 Jakub Jelinek <jakub@redhat.com>
PR target/98100
* cfgexpand.c (expand_gimple_basic_block): For vars with
vector type, use TYPE_MODE rather than DECL_MODE.
* gcc.target/i386/pr98100.c: New test.
(cherry picked from commit 4c18faa4dd4dffdb76bc879b7555574ce3f4da01)
|
|
As discussed in https://sourceware.org/bugzilla/show_bug.cgi?id=26987 ,
for very large bounds (which don't fit into HOST_WIDE_INT) GCC emits invalid
DWARF.
In DWARF2, DW_AT_{lower,upper}_bound were constant reference class.
In DWARF3 they are block constant reference and the
Static and Dynamic Properties of Types
chapter says:
"For a block, the value is interpreted as a DWARF expression; evaluation of the expression
yields the value of the attribute."
In DWARF4/5 they are constant exprloc reference class.
Now, for add_AT_wide we use DW_FORM_data16 (valid in constant class)
when -gdwarf-5, but otherwise just use DW_FORM_block1, which is not constant
class, but block.
For DWARF3 this means emitting clearly invalid DWARF, because the
DW_FORM_block1 should contain a DWARF expression, not random bytes
containing the constant directly.
For DWARF2/DWARF4/5 it could be considered a GNU extension, but a very badly
designed one when it means something different in DWARF3.
The following patch uses add_AT_wide only if we know we'll be using
DW_FORM_data16, and otherwise wastes 2 extra bytes and emits in there
DW_OP_implicit_value <size> before the constant.
2020-12-03 Jakub Jelinek <jakub@redhat.com>
* dwarf2out.c (add_scalar_info): Only use add_AT_wide for 128-bit
constants and only in dwarf-5 or later, where DW_FORM_data16 is
available. Otherwise use DW_FORM_block*/DW_FORM_exprloc with
DW_OP_implicit_value to describe the constant.
(cherry picked from commit a08add4b115800281669d24e445342bd782de0cb)
|
|
On the following testcase with -fpic -mcmodel=large -fno-plt we emit
call puts@GOTPCREL(%rip)
but that is not really appropriate for CM_LARGE_PIC, the .text can be larger
than 2GB in that case and the .got slot further away from %rip than what can
fit into the signed 32-bit immediate.
The following patch computes the address of the .got slot the way it is
computed for that model for function pointer loads, and calls that.
2020-12-01 Jakub Jelinek <jakub@redhat.com>
PR target/98063
* config/i386/i386.c (ix86_expand_call): Handle non-plt
CM_LARGE_PIC calls.
* gcc.target/i386/pr98063.c: New test.
(cherry picked from commit ebc8606a9408623e2fa2a02a5526b882ffd0e7a8)
|
|
c_parser_binary_expression was using build2 to create a temporary holder
for binary expression that c_parser_atomic and c_finish_omp_atomic can then
handle. The latter performs then all the needed checking.
Unfortunately, build2 performs some checking too, e.g. PLUS_EXPR vs.
POINTER_PLUS_EXPR or matching types of the arguments, nothing we can guarantee
at the parsing time. So we need something like C++ build_min_nt*. This
patch implements that inline.
2020-11-24 Jakub Jelinek <jakub@redhat.com>
PR c/97958
* c-parser.c (c_parser_binary_expression): For omp atomic binary
expressions, use make_node instead of build2 to avoid checking build2
performs.
* c-c++-common/gomp/pr97958.c: New test.
(cherry picked from commit 1cd47144fd250f37206c8e2a0cc7d51c25ad368c)
|
|
Aldy's PR71855 fix avoided emitting multiple redundant
DW_TAG_unspecified_parameters sub-DIEs of a single DIE by restricting
it to early dwarf only. That unfortunately means if we need to emit
another DIE for the function (whether it is for LTO, or e.g. because of
IPA cloning), we don't emit DW_TAG_unspecified_parameters, it remains
solely in the DW_AT_abstract_origin's referenced DIE.
But DWARF consumers don't really use DW_TAG_unspecified_parameters
from there, like we duplicate DW_TAG_formal_parameter sub-DIEs even in the
clones because either they have some more specific location, or e.g.
a function clone could have fewer or different argument types etc.,
they need to assume that originally stdarg function isn't later stdarg etc.
Unfortunately, while for DW_TAG_formal_parameter sub-DIEs, we can use the
hash tabs to look the PARM_DECLs if we already have the DIEs, for
DW_TAG_unspecified_parameters we don't have an easy way to look it up.
The following patch handles it by trying to figure out if we are creating a
fresh new DIE (in that case we add DW_TAG_unspecified_parameters if it is
stdarg), or if gen_subprogram_die is called again on an pre-existing DIE
to fill in some further details (then it will not touch it).
Except for lto, subr_die != old_die would be good enough, but unfortunately
for LTO the new DIE that will refer to early dwarf created DIE is created
on the fly during lookup_decl_die. So the patch tracks if the DIE has
no children before any children are added to it.
2020-11-14 Jakub Jelinek <jakub@redhat.com>
PR debug/97599
* dwarf2out.c (gen_subprogram_die): Call
gen_unspecified_parameters_die even if not early dwarf, but only
if subr_die is a newly created DIE.
(cherry picked from commit 812258b07c1a80e8dc79a0beb3ec0e17be62f5e5)
|
|
While these function declarations have NULL decl_specifiers->type,
they have still type specifiers specified from which the default int
in the return type is added, so we shouldn't try to parse those as
deduction guides.
2020-11-03 Jakub Jelinek <jakub@redhat.com>
PR c++/97663
* parser.c (cp_parser_init_declarator): Don't try to parse
C++17 deduction guides if there are any type specifiers even when
type is NULL.
* g++.dg/cpp1z/class-deduction75.C: New test.
(cherry picked from commit cd41e4a1864c10c7f9141284e82e5cc0a3007806)
|
|
> >> wide_int new_lb = wi::set_bit (r.lower_bound (0), 127)
> >>
> >> and creates the value:
> >>
> >> p new_lb
> >> {<wide_int_storage> = {val = {-65535, -1, 0}, len = 2, precision = 128},
> >> static is_sign_extended = true}
> >
> > This is non-canonical and so invalid, if the low HWI has the MSB set
> > and the high HWI is -1, it should have been just
> > val = {-65535}, len = 1, precision = 128}
> >
> > I guess the bug is that wi::set_bit_large doesn't call canonize.
>
> Yeah, looks like a micro-optimisation gone wrong.
2020-10-28 Jakub Jelinek <jakub@redhat.com>
* wide-int.cc (wi::set_bit_large): Call canonize unless setting
msb bit and clearing bits above it.
(cherry picked from commit e41011e5edcd9606573d3450d98512450dddca77)
|
|
The following testcases are miscompiled (the first one since my improvements
to rotate discovery on GIMPLE, the other one for many years) because
combiner optimizes nested ROTATEs with narrowing SUBREG in between (i.e.
the outer rotate is performed in shorter precision than the inner one) to
just one ROTATE of the rotated constant. While that (under certain
conditions) can work for shifts, it can't work for rotates where we can only
do that with rotates of the same precision.
2020-10-13 Jakub Jelinek <jakub@redhat.com>
PR rtl-optimization/97386
* combine.c (simplify_shift_const_1): Don't optimize nested ROTATEs if
they have different modes.
* gcc.c-torture/execute/pr97386-1.c: New test.
* gcc.c-torture/execute/pr97386-2.c: New test.
(cherry picked from commit 1a98b22b0468214ae8463d075dacaeea1d46df15)
|
|
The following testcase FAILs, because we don't mark the child OpenMP function
as cfun->calls_alloca when it does call alloca. When optimizing, during DCE we
reset those flags and recompute them again, but with -O0 DCE is not performed.
Fixed by calling notice_special_calls when moving insns to the child function.
cfun->calls_alloca is normally set during gimplification and most of the
alloca calls omp-low.c does go through the gimplifier, but one spot didn't
and built the gcall directly, so that one needs to set calls_alloca too.
2020-10-08 Jakub Jelinek <jakub@redhat.com>
PR sanitizer/97294
* tree-cfg.c (move_block_to_fn): Call notice_special_calls on
call stmts being moved into dest_cfun.
* omp-low.c (lower_rec_input_clauses): Set cfun->calls_alloca when
adding __builtin_alloca_with_align call without gimplification.
* gcc.dg/asan/pr97294.c: New test.
(cherry picked from commit a30fcfb3b848e4b895cb47378b4a250184af3afe)
|
|
libcpp has two specialized altivec implementations of search_line_fast,
one for power8+ and the other one otherwise.
Both use __attribute__((altivec(vector))) and the GCC builtins rather than
altivec.h and the APIs from there, which is fine, but should be restricted
to when libcpp is built with GCC, so that it can be relied on.
The second elif is
and thus e.g. when built with clang it isn't picked, but the first one was
just guarded with
and so according to the bugreporter clang fails miserably on that.
The following patch fixes that by adding the same GCC_VERSION requirement
as the second version. I don't know where the 4.5 in there comes from and
the exact version doesn't matter that much, as long as it is above 4.2 that
clang pretends to be and smaller or equal to 4.8 as the oldest gcc we
support as bootstrap compiler ATM.
Furthermore, the patch fixes the comment, the version it is talking about is
not pre-GCC 5, but actually the GCC 5+ one.
2020-09-26 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/97163
* lex.c (search_line_fast): Only use _ARCH_PWR8 Altivec version
for GCC >= 4.5.
(cherry picked from commit cd547f0ddcd3a54e5b73bcda5ac0f0c46808db8b)
|
|
|
|
This fixes a division by zero in the selection-sampling std::__sample
overload when the input range is empty (and hence __unsampled_sz is 0).
libstdc++-v3/ChangeLog:
* include/bits/stl_algo.h (__sample): Exit early when the
input range is empty.
* testsuite/25_algorithms/sample/3.cc: New test.
(cherry picked from commit 813ad9c4dd5a779f12ad2abf710c6e75a3117ef0)
|
|
cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since r8-7957. In the
testcase below, this causes the second static_assert to fail on targets
where alignof(double) != __alignof__(double) because the specialization
table (which uses cp_tree_equal as its equality predicate) conflates the
two dependent specializations integral_constant<__alignof__(T)> and
integral_constant<alignof(T)>.
This patch makes cp_tree_equal distinguish between these two operators
by inspecting the ALIGNOF_EXPR_STD_P flag.
gcc/cp/ChangeLog:
PR c++/88115
PR libstdc++/97273
* tree.c (cp_tree_equal) <case ALIGNOF_EXPR>: Return false if
ALIGNOF_EXPR_STD_P differ.
gcc/testsuite/ChangeLog:
PR c++/88115
PR libstdc++/97273
* g++.dg/template/alignof3.C: New test.
(cherry picked from commit 592fe221735bdaa375b1834dd49ce125d0b600d8)
|
|
With -Werror=return-type we run into compile fails complaining about
missing return stmts.
2021-04-21 Richard Biener <rguenther@suse.de>
PR testsuite/100176
* g++.dg/compat/struct-layout-1_generate.c: Add missing return.
* gcc.dg/compat/struct-layout-1_generate.c: Likewise.
(cherry picked from commit d8f953819e8f72e646f22c7803d79bd2b56d1e30)
|
|
|
|
|
|
The name __deref is defined as a macro by Windows headers.
This renames the __deref() helper function to __ref. It doesn't actually
dereference an iterator. it just has the same type as the iterator's
reference type.
libstdc++-v3/ChangeLog:
PR libstdc++/97362
* doc/html/manual/source_code_style.html: Regenerate.
* doc/xml/manual/appendix_contributing.xml: Add __deref to
BADNAMES.
* include/debug/functions.h (_Irreflexive_checker::__deref):
Rename to __ref.
(cherry picked from commit 2137aa92412da363d52ef699987441be28b239d0)
|
|
libstdc++-v3/ChangeLog:
PR libstdc++/97570
* libsupc++/new_opa.cc: Declare size_t in global namespace.
Remove unused header.
(cherry picked from commit 93e9a7bcd5434a24c945de33cd7fa01a25f68418)
|
|
Currently the <experimental/random>, <experimental/source_location> and
<experimental/utility> headers can be included in C++98 and C++11 modes,
but gives errors. With this change they can be included, but define
nothing.
libstdc++-v3/ChangeLog:
PR libstdc++/98319
* include/experimental/memory_resource: Add system_header pragma
and only define contents for C++14 and later.
* include/experimental/random: Only define contents for C++14
and later.
* include/experimental/source_location: Likewise.
* include/experimental/utility: Likewise.
* testsuite/experimental/feat-lib-fund.cc: Include all LFTS
headers that are present. Allow test to run for all modes.
(cherry picked from commit ab9bd93271061f436c10e35e261ecb73e2108ccc)
|
|
libstdc++-v3/ChangeLog:
PR libstdc++/99058
* doc/xml/manual/status_cxx2011.xml: Document when support
became stable.
* doc/xml/manual/status_cxx2014.xml: Likewise.
* doc/xml/manual/status_cxx2017.xml: Likewise.
* doc/html/manual/status.html: Regenerate.
(cherry picked from commit ce43c906049b828c0472d8499b52ac6233c869d0)
|
|
Since GCC 8, the -freorder-blocks-and-partition pass can split a function
into hot and cold parts, thus generating 2 FDEs for a single function in
DWARF for exception purposes and doing an equivalent trick for Windows SEH.
Now the Windows system unwinder does not support arbitrarily large frames
and there is even a hard limit on the encoding of the CFI, which changes
the stack allocation strategy when it is topped and which must be reflected
everywhere.
gcc/
* config/i386/winnt.c (i386_pe_seh_cold_init): Properly deal with
frames larger than the SEH maximum frame size.
gcc/testsuite/
* gnat.dg/opt92.adb: New test.
|
|
|
|
|
|
|
|
|
|
|
|
contrib/ChangeLog:
* gcc-changelog/git_commit.py: Sync with master.
* gcc-changelog/git_email.py: Likewise.
* gcc-changelog/git_update_version.py: Likewise.
* gcc-changelog/setup.cfg: Likewise.
* gcc-changelog/test_email.py: Likewise.
* gcc-changelog/test_patches.txt: Likewise.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The simplification of the transposition of a constant array shall properly
initialize and set the shape of the result.
gcc/fortran/ChangeLog:
PR fortran/99840
* simplify.c (gfc_simplify_transpose): Properly initialize
resulting shape.
gcc/testsuite/ChangeLog:
PR fortran/99840
* gfortran.dg/transpose_5.f90: New test.
(cherry picked from commit d7cef070bf43bfb3f3d77bac42eadea06c4b0281)
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
'libhsa-runtime64.so'
For unknown reasons, this had gotten added for the libgomp HSA plugin in commit
b8d89b03db5f212919e4571671ebb4f5f8b1e19d (r242749) "Remove build dependence on
HSA run-time", and later propagated into the GCN plugin.
libgomp/
* plugin/plugin-hsa.c (init_enviroment_variables): Don't prepend
the 'HSA_RUNTIME_LIB' path to 'libhsa-runtime64.so'.
* plugin/configfrag.ac (HSA_RUNTIME_LIB): Clean up.
* config.h.in: Regenerate.
* configure: Likewise.
(cherry picked from commit 7c1e856bedb4ae190c420ec2d2ca5e08730cf21d)
|
|
|
