Hi!
The following patch fixes two bugs in the access_ref::inform_access function
(plus some formatting nits).
The first problem is that ref can be various things, e.g. *_DECL, or
SSA_NAME, or IDENTIFIER_NODE. And allocfn is non-NULL only if ref is
(at least originally) an SSA_NAME initialized to
On Linux/x86_64,
049bfd186fae9fb764a3ec04acb20d3eaacda7a3 is the first bad commit
commit 049bfd186fae9fb764a3ec04acb20d3eaacda7a3
Author: Tobias Burnus
Date: Tue Jan 19 11:57:34 2021 +0100
OpenMP/Fortran: Fixes for {use,is}_device_ptr
caused
FAIL: gfortran.dg/gomp/is_device_ptr-2.f90 -
Hi!
Similarly to how we handle erroneous operands to e.g. allocate clause,
this change just removes those clauses instead of accessing TYPE_MAIN_VARIANT
of its type, which doesn't work on error_mark_node. Also, just for good
measure, bails out if TYPE_NAME is NULL.
Bootstrapped/regtested on x86_
On 18.01.21 17:56, Tobias Burnus wrote:
While testing, it turned out that 'is_device_ptr(aa,bb,cc,dd) was
accepted
as only the first list item was checked – giving later an ICE in the ME.
... and as PR fortran/98757 showed, I forgot a 'git add' before committing
the associated testcase, given t
On Tue, Jan 19, 2021 at 10:54:08PM +0100, Jakub Jelinek via Gcc-patches wrote:
> So like this then if it passes bootstrap/regtest?
Successfully bootstrapped/regtested on x86_64-linux and i686-linux.
>
> 2021-01-19 Jakub Jelinek
>
> PR c++/98672
> * constexpr.c (check_for_return_co
On Wed, Jan 20, 2021 at 12:35 PM Hongtao Liu wrote:
>
> On Wed, Jan 20, 2021 at 12:10 AM Richard Sandiford
> wrote:
> >
> > Jakub Jelinek via Gcc-patches writes:
> > > On Tue, Jan 19, 2021 at 12:38:47PM +, Richard Sandiford via
> > > Gcc-patches wrote:
> > >> > actually only the lower 16bit
On Wed, Jan 20, 2021 at 12:10 AM Richard Sandiford
wrote:
>
> Jakub Jelinek via Gcc-patches writes:
> > On Tue, Jan 19, 2021 at 12:38:47PM +, Richard Sandiford via Gcc-patches
> > wrote:
> >> > actually only the lower 16bits are needed, the original insn is like
> >> >
> >> > .294.r.ira
> >>
Richard,
Can you please commit this patch for me? I don't have write access yet, I'm
still working on getting copyright assignment/disclaimer signed by my employer.
Thanks,
Eugene
-Original Message-
From: Richard Biener
Sent: Friday, January 15, 2021 3:55 AM
To: Eugene Rozenfeld
Cc:
PR debug/98751 reports an issue in which most of libgccjit's tests
fails in DWARF 5 handling with
`.Ldebug_loc2' is already defined"
asm errors.
The bogus label is being emitted at the 3rd in-process iteration, at:
31673 ASM_OUTPUT_LABEL (asm_out_file, loc_section_label);
which on the in
Similar to the problem reported for -Wstringop-overflow in pr98266
and already fixed, -Warray-bounds is also susceptible to false
positives in assignments and copies involving virtual inheritance.
Because the two warnings don't share code yet (hopefully in GCC 12)
the attached patch adds its own w
One of the advantages of LRA is that you can create new pseudos from it
just fine. The code in rs6000_emit_le_vsx_store was not aware of this.
This patch changes that, in the process fixing PR98549 (where it is
shown that we do call rs6000_emit_le_vsx_store during LRA, which we
used to assert can
On 1/10/21 7:28 PM, Paul Fee via Gcc-patches wrote:
[PATCH v2] c++: Add support for -std=c++2b
Thanks!
This patch was corrupted by word wrap, so it won't apply; if you can't
suppress word wrap in your mail client, please send the patch as an
attachment instead.
Also remember to use git gcc
On Tue, 19 Jan 2021, Nathan Sidwell wrote:
> Joseph,
> I was relying on this patch on the modules branch, but didn't realize the
> implications when merging and thought it was just a cleanup. I'm not sure why
> the driver wants to check here, rather than leave it to the compiler. Seems
> optimiz
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the German team of translators. The file is available at:
https://translationproject.org/latest/gcc/de.po
(This file, 'gcc-10.2.0.de.po', has jus
On Tue, Jan 19, 2021 at 03:47:47PM -0500, Jason Merrill via Gcc-patches wrote:
> On 1/13/21 6:39 PM, Marek Polacek wrote:
> > r11-6301 added some asserts in mangle.c, and now we trip over one of
> > them. In particular, it's the one asserting that we didn't get
> > IDENTIFIER_ANY_OP_P when manglin
Segher, Will:
The following patch set is adds the 128-bit integer operation support
and fixes a bug found in the existing support. This is the third
version of the patch set. The first five patches have minor updates
based on previous reviews. The last patch has a number of functional
changes t
Will, Segher:
This patch adds support for converting to/from 128-bit integers and
128-bit decimal floating point formats using the new P10 instructions
dcffixqq and dctfixqq. The new instructions are only used on P10 HW,
otherwise the conversions continue to use the existing SW routines.
The fi
Will, Segher:
This patch adds the 128-bit integer support for divide, modulo, shift,
compare of 128-bit integers instructions and builtin support.
version 3:
int_128bit-runnable.c: Removed ppc_native_128bit from
dg-require-effective-target. Was missed from
Will, Segher:
This patch adds support for converting to/from 128-bit integers and
128-bit decimal floating point formats.
Version 3:
No functional changes.
Tested on Power 8BE, Power9, Power10.
Version 2:
Updated ChangeLog comments. Fixed up comments in the test program.
Re-tested th
Will, Segher:
Patch 1, adds the 128-bit sign extension instruction support and
corresponding builtin support.
version 3:
doc/extend.texi: Fixed the "uThe" typo and added the colon at the
end of the line.
p9-sign_extend-runnable.c: Changed the dg-do run to *-*-linux
Will, Segher:
Patch 4 adds the vector 128-bit integer shift instruction support for
the V1TI type. This patch also renames and moves the VSX_TI iterator
from vsx.md to VEC_TI in vector.md. The uses of VEC_TI are also
updated.
This patch also renames and moves the VSX_TI iterator from vsx.md to
Will, Segher:
This patch fixes the order of the argument in the vec_rlmi and
vec_rlnm builtins. The patch also adds a new test cases to verify
the fix.
The patch has been tested on
powerpc64-linux instead (Power 8 BE)
powerpc64-linux instead (Power 9 LE)
powerpc64-linux instead (Powe
This Go frontend patch initializes variables with go:embed directives.
This completes the compiler work for go:embed. Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
eed40bca6f2eb3af0c811cf6ec9e123c5bf4907d
diff --git a/gcc/go/gofrontend/MERGE b/gcc/go/gofron
On Tue, Jan 19, 2021 at 04:01:49PM -0500, Jason Merrill wrote:
> Hmm, IF_STMT probably also needs to check the else clause, if the condition
> isn't a known constant.
You're right, I thought it was ok because it recurses with tf_none, but
if the then branch is potentially constant and only else re
On 1/15/21 11:37 AM, Patrick Palka wrote:
On Mon, 11 Jan 2021, Jason Merrill wrote:
On 1/7/21 4:06 PM, Patrick Palka wrote:
This is essentially a followup to r11-3714 -- we ICEing from another
"unguarded" call to build_concept_check, this time in do_auto_deduction,
due to the presence of templ
On 1/19/21 4:09 PM, Marek Polacek wrote:
On Tue, Jan 19, 2021 at 03:41:57PM -0500, Jason Merrill wrote:
On 1/13/21 1:38 PM, Marek Polacek wrote:
maybe_instantiate_noexcept doesn't expect to see error_mark_node, so
the new callsite I introduced in r11-6476 needs to be properly guarded.
I'd rat
On 1/19/21 3:47 PM, Marek Polacek wrote:
On Mon, Jan 18, 2021 at 05:18:46PM -0500, Jason Merrill wrote:
On 1/15/21 12:26 AM, Marek Polacek wrote:
My recent patch that introduced push_using_decl_bindings didn't
handle USING_DECL redeclaration, therefore things broke. This
patch amends that. No
On Tue, Jan 19, 2021 at 03:41:57PM -0500, Jason Merrill wrote:
> On 1/13/21 1:38 PM, Marek Polacek wrote:
> > maybe_instantiate_noexcept doesn't expect to see error_mark_node, so
> > the new callsite I introduced in r11-6476 needs to be properly guarded.
>
> I'd rather fix maybe_instantiate_noexce
On 1/19/21 11:29 AM, Patrick Palka wrote:
Here, during partial instantiation of the generic lambda, tsubst_copy on
the CLASS_PLACEHOLDER_TEMPLATE of the CTAD placeholder U{0} yields a
(level-lowered) TEMPLATE_TEMPLATE_PARM rather than the corresponding
TEMPLATE_DECL. This later confuses do_class
On 1/18/21 12:31 AM, Patrick Palka wrote:
When parsing the base-clause of a class declaration, we need to defer
access checking until the entire base-clause has been seen, so that
access can be properly checked relative to the scope of the class with
all its bases attached. This allows us to acc
On 1/18/21 12:31 AM, Patrick Palka wrote:
Here after resolving the address of a template-id inside decltype, we
end up instantiating the chosen specialization from the call to
mark_used in resolve_nondeduced_context, even though only its type is
needed.
Bootstrapped and regtested on x86_64-pc-li
On 1/15/21 11:26 AM, Jakub Jelinek wrote:
The following testcase is rejected even when it is valid.
The problem is that potential_constant_expression_1 doesn't have the
accurate *jump_target tracking cxx_eval_* has, and when the loop has
a condition that isn't guaranteed to be always true, the bo
On 1/13/21 6:39 PM, Marek Polacek wrote:
r11-6301 added some asserts in mangle.c, and now we trip over one of
them. In particular, it's the one asserting that we didn't get
IDENTIFIER_ANY_OP_P when mangling an expression with a dependent name.
As this testcase shows, it's possible to get that,
On Mon, Jan 18, 2021 at 05:18:46PM -0500, Jason Merrill wrote:
> On 1/15/21 12:26 AM, Marek Polacek wrote:
> > My recent patch that introduced push_using_decl_bindings didn't
> > handle USING_DECL redeclaration, therefore things broke. This
> > patch amends that. Note that I don't know if the oth
On 1/13/21 1:38 PM, Marek Polacek wrote:
maybe_instantiate_noexcept doesn't expect to see error_mark_node, so
the new callsite I introduced in r11-6476 needs to be properly guarded.
I'd rather fix maybe_instantiate_noexcept to deal with error_mark_node.
Bootstrapped/regtested on x86_64-pc-lin
On 1/13/21 12:05 PM, Patrick Palka wrote:
In the below testcase, the expression of the atomic constraint after
substitution is (int *) NON_LVALUE_EXPR <1> != 0B which is not a C++
constant expression, but its TREE_CONSTANT flag is set (from build2),
so satisfy_atom fails to notice that it's non-c
On 1/12/21 9:13 PM, Marek Polacek wrote:
Another ICE with delayed noexcept parsing, but a bit gnarlier.
A function definition marked with __attribute__((used)) ought to be
emitted even when it is not referenced in a TU. For a member function
template marked with __attribute__((used)) this means
On 1/12/21 9:13 PM, Marek Polacek wrote:
Since certain members of a class are a complete-class context
[class.mem.general]p7, we delay their parsing untile the whole class has
been parsed. For instance, NSDMIs and noexcept-specifiers. The order
in which we perform this delayed parsing matters;
On 1/12/21 5:26 PM, Patrick Palka wrote:
This patch removes a vestigial use of dk_no_check from
cp_parser_late_parsing_for_member, which ideally should have been
removed as part of the PR41437 patch that improved access checking
inside templates.
This allows us to correctly reject f1 and f2 be
Joseph,
I was relying on this patch on the modules branch, but didn't realize
the implications when merging and thought it was just a cleanup. I'm
not sure why the driver wants to check here, rather than leave it to the
compiler. Seems optimizing for failure? The only difference I can think
There's no need for this function to have an object, so make it
static and avoid UB.
gcc/cp/
* module.cc (trees_out::write_location): Make static.
--
Nathan Sidwell
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index 1fd0bcfe3eb..3b224b616c1 100644
--- i/gcc/cp/module.cc
+++
std::string tends to trigger a class of false positive out of bounds
access warnings for code GCC cannot prove is unreachable because of
missing aliasing constrains, and that ends up expanded inline into
user code. Simply inserting the contents of a constant char array
does that. In GCC 10 these
v1: https://gcc.gnu.org/pipermail/gcc-patches/2021-January/563800.html
v1 -> v2: Allow (mem) -> (subreg) propagation only for single uses.
Boostrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
and s390x-redhat-linux. Ok for master?
Suppose we have:
(set (reg/v:TF 63) (me
Jan Hubicka writes:
>> On Mon, 18 Jan 2021, Richard Sandiford wrote:
>>
>> > Jan Hubicka writes:
>> > >> >>
>> > >> >> Well, in tree-ssa code we do assume these to be either disjoint
>> > >> >> objects
>> > >> >> or equal (in decl_refs_may_alias_p that continues in case
>> > >> >> compare_base
On 1/19/21 10:46 AM, David Edelsohn wrote:
> Thanks for fixing this, Jeff.
No worries.
>
> I didn't realize that the testcase was testing the explicit source
> code line number hard coded the expected DWARF output.
Me neither. It took a few minutes to see what was going on. I kept
thinking so
On Mon, Jan 18, 2021 at 05:56:21PM +0100, Tobias Burnus wrote:
> gcc/testsuite/ChangeLog:
>
> PR fortran/98476
> * gfortran.dg/gomp/map-3.f90: Update expected scan-dump-tree.
> * gfortran.dg/gomp/is_device_ptr-1.f90: New test.
> * gfortran.dg/gomp/use_device_ptr-2.f90: New
Thanks for fixing this, Jeff.
I didn't realize that the testcase was testing the explicit source
code line number hard coded the expected DWARF output.
It would have been nice if the testcase included a comment about the
purpose and to alert people that the expected output needs to change
if line
Jonathan Wright writes:
> Hi,
>
> As subject, this patch rewrites integer mls Neon intrinsics to use
> a - b * c rather than inline assembly code, allowing for better
> scheduling and optimization.
>
> Regression tested and bootstrapped on aarch64-none-linux-gnu - no
> issues.
>
> If ok, please co
On Tue, 19 Jan 2021, Hans-Peter Nilsson wrote:
> On Tue, 19 Jan 2021, Richard Sandiford wrote:
>
> > Hans-Peter Nilsson writes:
> > > On Tue, 19 Jan 2021, Jakub Jelinek wrote:
> > >> I think "IRA target" is not the right term, all targets are IRA targets,
> > >> but only some are using LRA and oth
Hi all,
This patch relaxes the flags for the saturating arithmetic builtins to NONE,
allowing for more optimisation.
Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill
gcc/ChangeLog
* config/aarch64/aarch64-simd-builtins.def (sqshl, uqshl, sqrshl,
uqrs
On Fri, Jan 15, 2021 at 03:52:44PM -0600, Segher Boessenkool wrote:
> On Thu, Jan 14, 2021 at 12:09:36PM -0500, Michael Meissner wrote:
> > [PATCH] PowerPC: Add float128/Decimal conversions.
>
> Same question here.
In your last message, you said that it was unacceptable that the conversion
fails
On Fri, Jan 15, 2021 at 03:43:13PM -0600, Segher Boessenkool wrote:
> Hi!
>
> On Thu, Jan 14, 2021 at 11:59:19AM -0500, Michael Meissner wrote:
> > >From 78435dee177447080434cdc08fc76b1029c7f576 Mon Sep 17 00:00:00 2001
> > From: Michael Meissner
> > Date: Wed, 13 Jan 2021 21:47:03 -0500
> > Subj
Hi all,
this patch is for PR96372, the fail was introduced by [1] where the
failing check went from using target 'arm_thumb2' to
'arm_thumb2_ok_no_arm_v8_1_lob'. Unfortunately this is relying on
'arm_thumb2_ok' that has a different semantic compared to the original
'arm_thumb2'.
This patch is in
On Tue, 19 Jan 2021, Richard Sandiford wrote:
> Hans-Peter Nilsson writes:
> > On Tue, 19 Jan 2021, Jakub Jelinek wrote:
> >> I think "IRA target" is not the right term, all targets are IRA targets,
> >> but only some are using LRA and others use the old reload.
> >
> > But, IRA isn't used when..
Hi,
The attached patch fixes the issue mentioned in PR, by adding
arm_fp16_format to checked_options in optc-save-gen.awk.
Is this OK to commit in stage-4 if testing passes or should we hold it
till next stage-1 ?
Thanks,
Prathamesh
pr98636-2.diff
Description: Binary data
On Tue, 19 Jan 2021, Jeff Law wrote:
> On 1/19/21 5:36 AM, Hans-Peter Nilsson wrote:
> > I'll call the suggested testsuite target-supports predicate
> > "lra" (thanks Andreas S.; of course!), to be used negated here.
> Well we could do that.? But instead I propose we drop reload for gcc-12
> now th
Here, during partial instantiation of the generic lambda, tsubst_copy on
the CLASS_PLACEHOLDER_TEMPLATE of the CTAD placeholder U{0} yields a
(level-lowered) TEMPLATE_TEMPLATE_PARM rather than the corresponding
TEMPLATE_DECL. This later confuses do_class_deduction which expects
that the CLASS_PLAC
> On Mon, 18 Jan 2021, Richard Sandiford wrote:
>
> > Jan Hubicka writes:
> > >> >>
> > >> >> Well, in tree-ssa code we do assume these to be either disjoint
> > >> >> objects
> > >> >> or equal (in decl_refs_may_alias_p that continues in case
> > >> >> compare_base_decls is -1). I am not sure
Jakub Jelinek via Gcc-patches writes:
> On Tue, Jan 19, 2021 at 12:38:47PM +, Richard Sandiford via Gcc-patches
> wrote:
>> > actually only the lower 16bits are needed, the original insn is like
>> >
>> > .294.r.ira
>> > (insn 69 68 70 13 (set (reg:HI 96 [ _52 ])
>> > (subreg:HI (reg:
On Mon, 18 Jan 2021, Richard Sandiford wrote:
> Jan Hubicka writes:
> >> >>
> >> >> Well, in tree-ssa code we do assume these to be either disjoint objects
> >> >> or equal (in decl_refs_may_alias_p that continues in case
> >> >> compare_base_decls is -1). I am not sure if we win much by threat
On 1/19/21 5:36 AM, Hans-Peter Nilsson wrote:
>
> On Tue, 19 Jan 2021, Jakub Jelinek wrote:
>
>> On Mon, Jan 18, 2021 at 11:50:56PM -0500, Hans-Peter Nilsson wrote:
>>> On Mon, 18 Jan 2021, John David Anglin wrote:
The hppa target is a reload target and asm goto is not supported on reload
In aarch64_classify_symbol symbols are allowed large offsets on relocations.
This means the offset can use all of the +/-4GB offset, leaving no offset
available for the symbol itself. This results in relocation overflow and
link-time errors for simple expressions like &global_array + 0xff00.
The change to dwarf5 exposed multiple problems with
gcc.dg/debug/dwarf2/dwarf-float.c
AFAICT the test is supposed to check the dwarf2 records for float,
double and long double. In particular it checks the sizes of those
types and ensures they are 4, 8 and 16 bytes long respectively.
Of course w
Martin pointed out this is found with some warning modes.
I had two overloads of a function, but only one was needed. Let's keep
the constant one.
gcc/cp/
* modules.cc (identifier): Merge overloads.
--
Nathan Sidwell
diff --git i/gcc/cp/module.cc w/gcc/cp/module.cc
index 1fd0bc
On Tue, Jan 19, 2021 at 12:38:47PM +, Richard Sandiford via Gcc-patches
wrote:
> > actually only the lower 16bits are needed, the original insn is like
> >
> > .294.r.ira
> > (insn 69 68 70 13 (set (reg:HI 96 [ _52 ])
> > (subreg:HI (reg:DI 82 [ var_6.0_1 ]) 0)) "test.c":21:23 76
> > {
On Tue, Jan 19, 2021 at 2:13 PM Ilya Leoshkevich wrote:
>
> On Tue, 2021-01-19 at 09:41 +0100, Richard Biener wrote:
> > On Mon, Jan 18, 2021 at 11:04 PM Ilya Leoshkevich via Gcc-patches
> > wrote:
> > >
> > Suppose we have:
> > >
> > > (set (reg/v:TF 63) (mem/c:TF (reg/v:DI 62)))
> > > (
The following avoids ICEing on a indirect calls with a fnspec
in modref analysis.
Bootstrap & regtest running on x86_64-unknown-linux-gnu - OK?
Thanks,
Richard.
2021-01-19 Richard Biener
PR ipa/98330
* ipa-modref.c (analyze_stmt): Only record a summary for a
direct ca
Since SSA names do leak into global tree data structures like
TYPE_SIZE or in this case GFC_DECL_SAVED_DESCRIPTOR because of
frontend bugs we have to be careful to wipe references to the
CFG when we deconstruct SSA form because we now do ggc_free that.
Bootstrapped and tested on x86_64-unknown-lin
On Tue, 2021-01-19 at 09:41 +0100, Richard Biener wrote:
> On Mon, Jan 18, 2021 at 11:04 PM Ilya Leoshkevich via Gcc-patches
> wrote:
> >
> Suppose we have:
> >
> > (set (reg/v:TF 63) (mem/c:TF (reg/v:DI 62)))
> > (set (reg:FPRX2 66) (subreg:FPRX2 (reg/v:TF 63) 0))
> >
> > It is clearly
Hans-Peter Nilsson writes:
> On Tue, 19 Jan 2021, Jakub Jelinek wrote:
>
>> On Mon, Jan 18, 2021 at 11:50:56PM -0500, Hans-Peter Nilsson wrote:
>> > On Mon, 18 Jan 2021, John David Anglin wrote:
>> > > The hppa target is a reload target and asm goto is not supported on
>> > > reload targets.
>> >
On 1/19/21 12:37 PM, Martin Jambor wrote:
Right. From what I can tell at the moment, which is not much, the idea
was to be able to load it even from a non-standard path and specify that
path at configure time. If people think that is not useful and is
actually harmful, I guess it can go.
And
Hongtao Liu writes:
> On Mon, Jan 18, 2021 at 7:10 PM Richard Sandiford
> wrote:
>>
>> Hongtao Liu writes:
>> > On Mon, Jan 18, 2021 at 6:18 PM Richard Sandiford
>> > wrote:
>> >>
>> >> Hongtao Liu via Gcc-patches writes:
>> >> > Hi:
>> >> > If SRC had been assigned a mode narrower than the
On Tue, 19 Jan 2021, Jakub Jelinek wrote:
> On Mon, Jan 18, 2021 at 11:50:56PM -0500, Hans-Peter Nilsson wrote:
> > On Mon, 18 Jan 2021, John David Anglin wrote:
> > > The hppa target is a reload target and asm goto is not supported on
> > > reload targets.
> > > Skip failing tests on hppa.
>
This fixes input_location leaking with an invalid BLOCK from
expand_call_inline to tree_function_versioning via clone
materialization.
Bootstrapped and tested on x86_64-unknown-linux-gnu (with an
extra hunk calling verify_gimple from tree-function-versioning)
Pushed.
2021-01-19 Richard Biener
On Linux/x86_64,
3804e937b0e252a7e42632fe6d9f898f1851a49c is the first bad commit
commit 3804e937b0e252a7e42632fe6d9f898f1851a49c
Author: Mark Wielaard
Date: Tue Sep 29 15:52:44 2020 +0200
Default to DWARF5
caused
FAIL: libstdc++-prettyprinters/80276.cc whatis p4
FAIL: libstdc++-prettypr
Hi Thomas,
On Thu, Jan 14 2021, Thomas Schwinge wrote:
> Hi!
>
> I'm raising here an issue with HSA libgomp plugin code changes from a
> while ago. While HSA is now no longer relevant for GCC master branch,
> the same code has also been copied into the GCN libgomp plugin.
>
> This is commit b8d89
On 2021-01-19 10:52, Eric Botcazou wrote:
* config/sparch/rtemself.h (TARGET_OS_CPP_BUILTINS): Add built-in define
__FIX_LEON3FT_TN0018.
OK for whichever branch(es) you deem appropriate.
GCC-10, GCC-11 and master.
Thanks,
Daniel
On Mon, Jan 18, 2021 at 05:56:21PM +0100, Tobias Burnus wrote:
> OpenMP/Fortran: Fixes for {use,is}_device_ptr
>
> gcc/fortran/ChangeLog:
>
> PR fortran/98476
> * openmp.c (resolve_omp_clauses): Change use_device_ptr
> to use_device_addr for unless type(c_ptr); check all
>
> * config/sparch/rtemself.h (TARGET_OS_CPP_BUILTINS): Add built-in define
> __FIX_LEON3FT_TN0018.
OK for whichever branch(es) you deem appropriate.
--
Eric Botcazou
It's a long-standing GENERIC tree sharing issue.
Tested on x86_64-suse-linux, applied on the mainline, 10 and 9 branches.
2021-01-19 Eric Botcazou
PR ada/98740
* gcc-interface/trans.c (add_decl_expr): Always mark TYPE_ADA_SIZE.
--
Eric Botcazoudiff --git a/gcc/ada/gcc-inter
Enable a define FIX_LEON3FT_TN0018 for the LEON3FT targets affected
by the GRLIB-TN-0018 errata described here:
https://www.gaisler.com/notes
gcc/
* config/sparch/rtemself.h (TARGET_OS_CPP_BUILTINS): Add built-in define
__FIX_LEON3FT_TN0018.
---
gcc/config/sparc/rtemself.h | 2 ++
1 fi
On Mon, Jan 18, 2021 at 11:50:56PM -0500, Hans-Peter Nilsson wrote:
> On Mon, 18 Jan 2021, John David Anglin wrote:
> > The hppa target is a reload target and asm goto is not supported on reload
> > targets.
> > Skip failing tests on hppa.
>
> IIUC the preferred term is "IRA target" or maybe "non
On Tue, Jan 19, 2021 at 04:46:36PM +0800, Chung-Lin Tang wrote:
> > > + into the (above) structelem_refcount field of the _FIRST
> > > splay_tree_key,
> > > + the first key in the created sequence. All structure element
> > > siblings
> > > + share a single refcount in this mann
On Jan 18 2021, Hans-Peter Nilsson wrote:
> On Mon, 18 Jan 2021, John David Anglin wrote:
>> The hppa target is a reload target and asm goto is not supported on reload
>> targets.
>> Skip failing tests on hppa.
>
> IIUC the preferred term is "IRA target" or maybe "non-LRA
> target", as opposed to
On 2021/1/16 5:45 下午, Jakub Jelinek wrote:
+/* Unified reference count for structure element siblings, this is used
+ when REFCOUNT_STRUCTELEM_FIRST_P(k->refcount) == true, the first sibling
+ in a structure element sibling list item sequence. */
+uintptr_t structelem_refc
On Mon, Jan 18, 2021 at 11:04 PM Ilya Leoshkevich via Gcc-patches
wrote:
>
> Boostrapped and regtested on x86_64-redhat-linux, ppc64le-redhat-linux
> and s390x-redhat-linux. I realize it might be too late for a change
> like this, but it's desirable to have this in conjunction with the
> https://
On Mon, Jan 18, 2021 at 8:27 PM Martin Jambor wrote:
>
> Hi,
>
> IPA-SRA already contains a check to figure out that an otherwise dead
> parameter is actually required because of non-call exceptions, but it
> is not present at the equivalent spot where SRA figures out whether
> the return statemen
87 matches
Mail list logo
