On Tue, Feb 4, 2020 at 6:44 PM Richard Sandiford
wrote:
>
> Richard Sandiford writes:
> > [...]
> >> I'm not sure given the issues you've introduced if I could actually
> >> fill out the matrix of answers without more underlying information.
> >> ie, when can we get symbols without source level d
On Tue, Feb 4, 2020 at 11:02 PM Martin Sebor wrote:
>
> On 2/4/20 2:31 PM, Jeff Law wrote:
> > On Tue, 2020-02-04 at 13:08 -0700, Martin Sebor wrote:
> >> On 2/4/20 12:15 PM, Richard Biener wrote:
> >>> On February 4, 2020 5:30:42 PM GMT+01:00, Jeff Law
> >>> wrote:
> On Tue, 2020-02-04 at
Hi,
This is an obvious patch fixing typo in maybe_promote_captured_temps,
previously, the vnum (== 0) is used for all captured temps...
Will commit later.
Thanks,
bin
gcc/cp
2020-02-05 Bin Cheng
* coroutines.cc (maybe_promote_captured_temps): Increase the index
number for tem
On 2/5/20 8:52 AM, Richard Biener wrote:
"Address space layout randomization (ASLR) can lead to not binary identical
PCH files. If you rely on stable PCH file contents disable ASLR when generating
PCH files."
?
I'm fine with that. Installed as
r10-6442-gf4239581925d6a9fba049f8f771e909a7a5e5c
bin.cheng wrote:
This is an obvious patch fixing typo in maybe_promote_captured_temps,
previously, the vnum (== 0) is used for all captured temps...
Will commit later.
Yeah, I made this exact change locally yesterday (but I didn’t commit it yet,
so go ahead if you have time).
Iain
Still pending: libgomp-Testsuite patch
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00207.html
This is the same fix – but for gcc/testsuite/.
To illustrate the problem again. Using remote testing
(here: modified target_compile, but DejaGNU's default_target_compile is
likewise),
and using chec
在 2020/2/5 下午2:14, JunMa 写道:
Hi
This patch builds co_await/yield_expr with unknown_type when we can not
know the promise type in processing_template_decl phase. it avoid to
confuse compiler when handing type deduction and conversion.
Bootstrap and test on X86_64, is it OK?
Regards
JunMa
Hi
so
On Fri, Jan 31, 2020 at 6:01 PM Ulrich Weigand wrote:
>
> Hello,
>
> we've noticed some inconsistencies in how the component flags of -ffast-math
> are handled, see the discussion on the GCC list starting here:
> https://gcc.gnu.org/ml/gcc/2020-01/msg00365.html
>
> This patch fixes those inconsist
On Tue, Feb 04, 2020 at 02:15:04PM +0100, Uros Bizjak wrote:
> On Tue, Feb 4, 2020 at 2:13 PM Jakub Jelinek wrote:
> >
> > On Tue, Feb 04, 2020 at 01:38:51PM +0100, Uros Bizjak wrote:
> > > As Richard advised, let's put this safety stuff back. Usually, in
> > > i386.md, these kind of splitters are
On Wed, Feb 05, 2020 at 10:58:04AM +0100, Jakub Jelinek wrote:
> Attached are 3 possible incremental patches for recog.c, all of them fix
> all the above regressions, but haven't fully bootstrapped/regtested any of
> them yet. My preference would be the last one, which for -O0 and x86
> disables s
Hi!
The testcases ICE because when processing the declare simd inbranch,
we don't create the i == 0 clone as it already exists, which means
clone_info->nargs is not adjusted, but we then rely on it being adjusted
when trying other clones.
Bootstrapped/regtested on x86_64-linux and i686-linux, com
Hi!
When briefly looking at PR93586, I've noticed a typo, fixed thusly,
committed to trunk as obvious.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index aec156eb773..a4005841f60 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,5 +1,8 @@
2020-02-05 Jakub Jelinek
+ * tree-ssa-alias.c
From: Andrew Pinski
Looks like the porting_to page was not linked to the changes
page for GCC 9. So uncomments it out.
Committed as obvious.
---
htdocs/gcc-9/changes.html | 2 --
1 file changed, 2 deletions(-)
diff --git a/htdocs/gcc-9/changes.html b/htdocs/gcc-9/changes.html
index c0e581fe..
Hi!
In C++ we weren't calling mark_exp_read on the __builtin_convertvector first
argument. I guess it could misbehave even with lambda implicit captures.
Fixed by calling decay_conversion on the argument, we use the argument as
rvalue so we want the standard lvalue to rvalue conversions, but as
On Wed, Feb 5, 2020 at 11:05 AM Jakub Jelinek wrote:
>
> On Tue, Feb 04, 2020 at 02:15:04PM +0100, Uros Bizjak wrote:
> > On Tue, Feb 4, 2020 at 2:13 PM Jakub Jelinek wrote:
> > >
> > > On Tue, Feb 04, 2020 at 01:38:51PM +0100, Uros Bizjak wrote:
> > > > As Richard advised, let's put this safety
On Wed, Feb 05, 2020 at 11:46:51AM +0100, Uros Bizjak wrote:
> I think we should just enable split4 also for -O0. This would also
> allow us to remove the "optimize > 0" check above and allow us to
> generate a bit more optimal code even with -O0 for
> TARGET_SSE_PARTIAL_REG_DEPENDENCY and TARGET_A
On Wed, Feb 5, 2020 at 12:03 PM Jakub Jelinek wrote:
>
> On Wed, Feb 05, 2020 at 11:46:51AM +0100, Uros Bizjak wrote:
> > I think we should just enable split4 also for -O0. This would also
> > allow us to remove the "optimize > 0" check above and allow us to
> > generate a bit more optimal code ev
On Wed, Feb 05, 2020 at 12:11:15PM +0100, Uros Bizjak wrote:
> > I think the primary question is, do we for -O0 need to enable split2 (as in,
> > will anything in pro_and_epilogue or jump2 passes benefit from the
> > splitting and worth running two -O0 post-RA split passes), then we could go
> > wi
Hi all,
On Wed, Feb 05, 2020 at 07:26:03AM +0100, Jakub Jelinek wrote:
> On Tue, Feb 04, 2020 at 06:04:09PM -0700, Jeff Law wrote:
> > --- a/gcc/cse.c
> > +++ b/gcc/cse.c
> > @@ -5572,6 +5572,16 @@ cse_insn (rtx_insn *insn)
> > sets[i].rtl = 0;
> > }
> >
> > + /* Similarly for no-
Hi!
On Wed, Feb 05, 2020 at 08:57:16AM +0100, Richard Biener wrote:
> On Tue, Feb 4, 2020 at 6:40 PM Segher Boessenkool
> wrote:
> > On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt wrote:
> > > My intent is to make adding new built-in functions as simple as adding
> > > a few lines to a co
在 2020/2/4 下午8:17, JunMa 写道:
Hi
When testing coroutines with lambda function, I find we copy each
captured
variable to frame. However, according to gimplify pass, for each
declaration
that is an alias for another expression(DECL_VALUE_EXPR), we can
substitute them directly.
Since lambda captu
On 2/5/20 6:30 AM, Segher Boessenkool wrote:
Hi!
On Wed, Feb 05, 2020 at 08:57:16AM +0100, Richard Biener wrote:
On Tue, Feb 4, 2020 at 6:40 PM Segher Boessenkool
wrote:
On Mon, Feb 03, 2020 at 08:26:01PM -0600, Bill Schmidt wrote:
My intent is to make adding new built-in functions as simp
This adds guards to genmatch generated code before accessing call
expression or stmt arguments that might be out of bounds when
the user provided bogus prototypes for what we consider builtins.
Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.
Richard.
2020-02-05 Richard Biener
We're now consistently building SLP operations with only
scalar defs from scalars which makes the testcase no longer
testing multiplication vectorization. The following smuggles
in a constant making the vector variant profitable for SLP build.
Tested on x86_64-linux, pushed.
2020-02-05 Richard
Jeff Law writes:
> Richard & Segher, if y'all could check my analysis here, it'd be
> appreciated.
>
> pr90275 is a P2 regression that is only triggering on ARM. David's
> testcase in c#1 is the best for this problem as it doesn't require
> magic flags like -fno-dce to trigger.
>
> The block in q
As PR93047 said, __builtin_apply/__builtin_return does not work well with
-frename-registers. This is caused by return register(e.g. r3) is used to
rename another register, before return register is stored to stack.
This patch fix this issue by emitting clobber for those egisters which
maybe chan
On 1/30/20 5:13 PM, Jan Hubicka wrote:
Martin, I welcome your opinion on the patch
Ok, recently we've made quite some experiments with Honza about
TOP N counters. Based on the numbers, it shows that tracking a negative
value per-counter value does not help much. So that I suggest to use
only on
The current -fpatchable-function-entry implementation is done almost
behind the backend back. Backend doesn't know if and where patchable
area will be generated during RTL passes.
TARGET_ASM_PRINT_PATCHABLE_FUNCTION_ENTRY is only used to print out
assembly codes for patchable area. This leads t
Currently patchable area is at the wrong place. It is placed immediately
after function label, before both .cfi_startproc and ENDBR. This patch
adds UNSPECV_PATCHABLE_AREA for pseudo patchable area instruction and
changes ENDBR insertion pass to also insert a dummy patchable area.
TARGET_ASM_PRIN
Currently patchable area is at the wrong place. It is placed immediately
after function label and before .cfi_startproc. A backend should be able
to add a pseudo patchable area instruction durectly into RTL. This patch
adds patch_area_size and patch_area_entry to cfun so that the patchable
area
Since patch_area_size and patch_area_entry have been added to cfun,
we can use them to directly insert the pseudo UNSPECV_PATCHABLE_AREA
instruction.
PR target/93492
* config/i386/i386-features.c
(rest_of_insert_endbr_and_patchable_area): Change
need_patchable_area
The analyzer recognizes __analyzer_dump_exploded_nodes as a "magic"
function for use in DejaGnu tests: at the end of the pass, it issues
a warning at each such call, dumping the count of exploded nodes seen at
the call, which can be checked in test cases via dg-warning directives,
along with the ID
Although the analyzer works on GIMPLE SSA and therefore in theory ought
to support all languages supported by GCC, the code currently only
supports the subset of GIMPLE SSA expressible via the C frontend.
For GCC 10 I want to explicitly restrict the scope of the analyzer to
C code, to keep the ini
Hi Modi,
Thanks for your patch!
> Adding support for extv and extzv on aarch64 as described in
> PR86901. I also changed
> extract_bit_field_using_extv to use gen_lowpart_if_possible instead of
> gen_lowpart directly. Using
> gen_lowpart directly will fail with an ICE in building libgcc when t
The G++ bug has been fixed for a couple of months so we can remove these
workarounds that define alias templates in terms of constrained class
templates. We can just apply constraints directly to alias templates as
specified in the C++20 working draft.
* include/bits/iterator_concepts.h (i
On Wed, Feb 05, 2020 at 09:59:19AM -0500, David Malcolm wrote:
> Although the analyzer works on GIMPLE SSA and therefore in theory ought
> to support all languages supported by GCC, the code currently only
> supports the subset of GIMPLE SSA expressible via the C frontend.
>
> For GCC 10 I want to
On Wed, Feb 05, 2020 at 04:18:49PM +0100, Jakub Jelinek wrote:
> C has ctors before main too, look for attribute constructor.
And you can have exceptions in C too, attribute cleanup for the C
"destructors" that are invoked when exception is thrown or pthread
cancellation is invoked.
Jakub
On 2/5/20 1:19 AM, Richard Biener wrote:
On Tue, Feb 4, 2020 at 11:02 PM Martin Sebor wrote:
On 2/4/20 2:31 PM, Jeff Law wrote:
On Tue, 2020-02-04 at 13:08 -0700, Martin Sebor wrote:
On 2/4/20 12:15 PM, Richard Biener wrote:
On February 4, 2020 5:30:42 PM GMT+01:00, Jeff Law wrote:
On Tue
Tobias Burnus writes:
> diff --git a/libgomp/testsuite/lib/libgomp.exp
> b/libgomp/testsuite/lib/libgomp.exp
> index 7e94527c7ca..cb7757b6a91 100644
> --- a/libgomp/testsuite/lib/libgomp.exp
> +++ b/libgomp/testsuite/lib/libgomp.exp
> @@ -346,11 +346,11 @@ proc check_effective_target_offload_targ
Tobias Burnus writes:
> Still pending: libgomp-Testsuite patch
> https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00207.html
>
> This is the same fix – but for gcc/testsuite/.
>
> To illustrate the problem again. Using remote testing
> (here: modified target_compile, but DejaGNU's default_target_com
Stam Markianos-Wright writes:
> On 2/4/20 12:02 PM, Richard Sandiford wrote:
>> Stam Markianos-Wright writes:
>>> On 1/31/20 1:45 PM, Richard Sandiford wrote:
Stam Markianos-Wright writes:
> On 1/30/20 10:01 AM, Richard Sandiford wrote:
>> Stam Markianos-Wright writes:
>>> On 1
"H.J. Lu" writes:
> Currently patchable area is at the wrong place.
Agreed :-)
> It is placed immediately
> after function label and before .cfi_startproc. A backend should be able
> to add a pseudo patchable area instruction durectly into RTL. This patch
> adds patch_area_size and patch_area_
Hi,
On Sat, Jan 25 2020, Feng Xue OS wrote:
> Made some changes.
>
> Feng
>
>
> From: Feng Xue OS
> Sent: Saturday, January 25, 2020 5:54 PM
> To: mjam...@suse.cz; Jan Hubicka; gcc-patches@gcc.gnu.org
> Subject: [PATCH] Generalized value pass-through for se
This patch removes a redundant "gfx900/gfx906" multilib that was added
by accident. We need those options independently, but not together.
Andrew
amdgcn: Remove redundant multilib
2020-02-05 Andrew Stubbs
gcc/
* config/gcn/t-gcn-hsa (MULTILIB_OPTIONS): Use / not space.
diff --git a/gcc/c
MS_ABI requires passing aggregates with only float/double in integer
registers. Checked gcc outputs against Clang and fixed:
FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54
-Wno-unused-variable -Wno-unused-parameter
-Wno-unused-but-set-variable -Wno-uninitialized -O0
-DABI_NU
On 2/5/20 5:44 AM, Jakub Jelinek wrote:
Hi!
In C++ we weren't calling mark_exp_read on the __builtin_convertvector first
argument. I guess it could misbehave even with lambda implicit captures.
Fixed by calling decay_conversion on the argument, we use the argument as
rvalue so we want the stan
On 2/4/20 4:20 AM, Jakub Jelinek wrote:
Hi!
My change
* typeck2.c (store_init_value): Don't call cp_fully_fold_init on
initializers of automatic non-constexpr variables in constexpr
functions.
- value = cp_fully_fold_init (value);
+ /* Don't fold initializers of automatic variables in constexp
Hi
Is it me or the patch isn't an attachment ? It is far more
convenient to provide something easy to extract and apply locally.
On 2/4/20 3:07 AM, Patrick Palka wrote:
This patch implements the C++20 ranges overloads for the algorithms in
[algorithms]. Most of the algorithms were reimpl
This patch is for PR 79193 and 88999, problems where libstdc++ is
mis-configuring itself when building for a bare-metal target because it
thinks it can link programs without pulling in the BSP that provides
low-level I/O support. (Specifically, this was observed on nios2-elf
with Newlib and GD
In the testcase, since there's no declaration of T, ref_view(T) declares a
non-static data member T of type ref_view, the same type as its enclosing
class. Then when we try to do C++20 aggregate class template argument
deduction we recursively try to adjust the braced-init-list to match the
templa
On Wed, Feb 05, 2020 at 09:53:27PM +0800, Jiufu Guo wrote:
> As PR93047 said, __builtin_apply/__builtin_return does not work well with
> -frename-registers. This is caused by return register(e.g. r3) is used to
> rename another register, before return register is stored to stack.
>
> This patch f
[resending with attachment now compressed]
On Wed, 5 Feb 2020, François Dumont wrote:
> Hi
>
> Is it me or the patch isn't an attachment ? It is far more convenient to
> provide something easy to extract and apply locally.
Good point, I've attached the patch as an attachment and I'll make s
On 2/4/20 6:05 PM, Martin Sebor wrote:
GCC diagnoses declarations of function aliases whose type doesn't
match that of the target (ditto for attribute weakref). It doesn't
yet diagnose such incompatbilities for variable aliases but that's
just an oversight that I will try to remember to correct
On Wed, Feb 5, 2020 at 9:00 AM Richard Sandiford
wrote:
>
> "H.J. Lu" writes:
> > Currently patchable area is at the wrong place.
>
> Agreed :-)
>
> > It is placed immediately
> > after function label and before .cfi_startproc. A backend should be able
> > to add a pseudo patchable area instruct
On Wed, Feb 5, 2020 at 6:59 PM H.J. Lu wrote:
>
> MS_ABI requires passing aggregates with only float/double in integer
> registers. Checked gcc outputs against Clang and fixed:
>
> FAIL: libffi.bhaible/test-callback.c -W -Wall -Wno-psabi -DDGTEST=54
> -Wno-unused-variable -Wno-unused-parameter
>
We should be able to assume that a template instantiation or other COMDAT
has non-zero address even if MAKE_DECL_ONE_ONLY for the target sets
DECL_WEAK and we haven't yet decided to emit a definition in this
translation unit.
Tested x86_64-pc-linux-gnu, OK for trunk?
PR c++/92003
Since reshape_init_array_1 can now reuse a single constructor for
an array of non-aggregate type, we might run into a scenario where
we reuse a constructor with TREE_SIDE_EFFECTS. This broke this test
because we have something like { { expr } } and we try to reshape it,
so we recurse on the inner
On Wed, Feb 5, 2020 at 4:18 PM Marek Polacek wrote:
> Since reshape_init_array_1 can now reuse a single constructor for
> an array of non-aggregate type, we might run into a scenario where
> we reuse a constructor with TREE_SIDE_EFFECTS. This broke this test
> because we have something like { {
When I submitted my recent patches, in updating one of the patches, I made a
thinko that resulted in a lot of failures on big endian systems (but not as
many on the little endian systems).
I have done bootstraps on both big endian and little endian systems. Can I
check in this patch?
On a big en
If we are going to use get_first_fn let's make sure we operate
on is_overloaded_fn, as the rest of the codebase does.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
PR c++/93597 - ICE with lambda in operator function.
* name-lookup.c (maybe_save_operator_binding): Check is_
Simplify post epilogue_completed splitters.
Now that we have post epilogue_completed split point for all
optimization levels, we can simplify post epilogue_completed splitters
considerably. If corresponding define_peephole2 pattern fails to
allocate a temporary register (or if peephole2 pass isn't
On 2/5/20 4:31 PM, Marek Polacek wrote:
If we are going to use get_first_fn let's make sure we operate
on is_overloaded_fn, as the rest of the codebase does.
Bootstrapped/regtested on x86_64-linux, ok for trunk?
PR c++/93597 - ICE with lambda in operator function.
* name-lookup.
On Sun, 5 Jan 2020, Gerald Pfeifer wrote:
> Happy to have you as a mirror, and if you'd like to submit a patch
> for https://gcc.gnu.org/mirrors.html that'd be great. Otherwise we
> can create one.
I applied this patch that I created on behalf of Sami.
Gerald
- Log -
On Wed, Feb 05, 2020 at 04:29:38PM -0500, Michael Meissner wrote:
> 2020-02-05 Michael Meissner
>
> PR target/93568
> * config/rs6000/rs6000.c (get_vector_offset): Fix
>
> --- /tmp/a8cqkr_rs6000.c 2020-02-05 14:55:36.255021903 -0600
> +++ gcc/config/rs6000/rs6000.c2020
On Wed, Feb 05, 2020 at 04:40:50PM -0500, Jason Merrill wrote:
> On 2/5/20 4:31 PM, Marek Polacek wrote:
> > If we are going to use get_first_fn let's make sure we operate
> > on is_overloaded_fn, as the rest of the codebase does.
> >
> > Bootstrapped/regtested on x86_64-linux, ok for trunk?
> >
On Wed, Feb 5, 2020 at 12:20 PM H.J. Lu wrote:
>
> On Wed, Feb 5, 2020 at 9:00 AM Richard Sandiford
> wrote:
> >
> > "H.J. Lu" writes:
> > > Currently patchable area is at the wrong place.
> >
> > Agreed :-)
> >
> > > It is placed immediately
> > > after function label and before .cfi_startproc.
On Wed, Feb 05, 2020 at 02:24:48PM -0800, H.J. Lu wrote:
> On Wed, Feb 5, 2020 at 12:20 PM H.J. Lu wrote:
> >
> > On Wed, Feb 5, 2020 at 9:00 AM Richard Sandiford
> > wrote:
> > >
> > > "H.J. Lu" writes:
> > > > Currently patchable area is at the wrong place.
> > >
> > > Agreed :-)
> > >
> > > >
On Wed, Feb 5, 2020 at 2:37 PM Marek Polacek wrote:
>
> On Wed, Feb 05, 2020 at 02:24:48PM -0800, H.J. Lu wrote:
> > On Wed, Feb 5, 2020 at 12:20 PM H.J. Lu wrote:
> > >
> > > On Wed, Feb 5, 2020 at 9:00 AM Richard Sandiford
> > > wrote:
> > > >
> > > > "H.J. Lu" writes:
> > > > > Currently pat
On Wed, Feb 5, 2020 at 2:51 PM H.J. Lu wrote:
>
> On Wed, Feb 5, 2020 at 2:37 PM Marek Polacek wrote:
> >
> > On Wed, Feb 05, 2020 at 02:24:48PM -0800, H.J. Lu wrote:
> > > On Wed, Feb 5, 2020 at 12:20 PM H.J. Lu wrote:
> > > >
> > > > On Wed, Feb 5, 2020 at 9:00 AM Richard Sandiford
> > > > wr
On Wed, 2020-02-05 at 16:18 +0100, Jakub Jelinek wrote:
> On Wed, Feb 05, 2020 at 09:59:19AM -0500, David Malcolm wrote:
> > Although the analyzer works on GIMPLE SSA and therefore in theory
> > ought
> > to support all languages supported by GCC, the code currently only
> > supports the subset of
> We should be able to assume that a template instantiation or other COMDAT
> has non-zero address even if MAKE_DECL_ONE_ONLY for the target sets
> DECL_WEAK and we haven't yet decided to emit a definition in this
> translation unit.
>
> Tested x86_64-pc-linux-gnu, OK for trunk?
>
> PR c++/
In unevaluated context, we only substitute a single PARM_DECL, not the
entire chain, but the handling of an empty pack expansion was missing that
check.
Tested x86_64-pc-linux-gnu, applying to trunk.
PR c++/93140
* pt.c (tsubst_decl) [PARM_DECL]: Check cp_unevaluated_operand in
On 2/3/20 11:44 AM, Jeff Law wrote:
On Fri, 2020-01-31 at 12:04 -0700, Martin Sebor wrote:
Attached is a reworked patch since the first one didn't go far
enough to solve the major problems. The new solution relies on
get_range_strlen_dynamic the same way as the sprintf optimization,
and does aw
On 2/4/20 7:35 AM, Richard Biener wrote:
...
Jakub/Richi, comments on this hunk?
+ tree ref = TREE_OPERAND (TREE_OPERAND (arg, 0), 0);
+ tree off = TREE_OPERAND (arg, 1);
+ if ((TREE_CODE (ref) == PARM_DECL || VAR_P (ref))
+ && (!DECL_EXTERNAL (ref)
+
I removed the trailing comma and (after a few false starts) managed
to push the change in commit
r10-6466-g297aa668293d55ffe100d810e92fbe592f262557.
I got the error below for my first few attempts. The message had
the expected format so I wasn't sure what the problem was until
I removed the "[
On 2/4/20 11:42 AM, Jakub Jelinek wrote:
> Hi!
>
> On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
>> I guess that Comment #9 patch form the PR should be trivially correct,
>> but althouhg it looks obvious, I don't want to propose the patch since
>> I have no means of testing it.
>
>
Segher Boessenkool writes:
> On Wed, Feb 05, 2020 at 09:53:27PM +0800, Jiufu Guo wrote:
>> As PR93047 said, __builtin_apply/__builtin_return does not work well with
>> -frename-registers. This is caused by return register(e.g. r3) is used to
>> rename another register, before return register is
On 2/5/20 5:04 PM, Marek Polacek wrote:
On Wed, Feb 05, 2020 at 04:40:50PM -0500, Jason Merrill wrote:
On 2/5/20 4:31 PM, Marek Polacek wrote:
If we are going to use get_first_fn let's make sure we operate
on is_overloaded_fn, as the rest of the codebase does.
Bootstrapped/regtested on x86_64-
On Thu, Feb 06, 2020 at 01:00:36AM +, JonY wrote:
> On 2/4/20 11:42 AM, Jakub Jelinek wrote:
> > Hi!
> >
> > On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> >> I guess that Comment #9 patch form the PR should be trivially correct,
> >> but althouhg it looks obvious, I don't want
The ARM Exception Handling ABI requires personality functions in
phase1 to initialize barrier_cache before returning
_URC_HANDLER_FOUND, and we don't.
Although our own ARM personality function does not use barrier_cache
at all, other languages' ARM personality functions, during phase2, are
allowed
Thread-local variables with DECL_COMMON trigger an internal compiler
error on targets that use emulated TLS without register_common, when
we attempt to expand a call to the NULL register_common, with
testcases as simple as gcc.dg/tls/emutls-2.c.
The documentation states that, on such targets, comm
81 matches
Mail list logo
