Hi,
On 02/09/19 16:28, Paolo Carlini wrote:
Hi,
all should be more or less straightforward. I also propose to use an
additional range for that error message about constinit && constexpr
mentioned to Marek a few days ago. Tested x86_64-linux.
I'm gently piniging this very early because the f
On Fri, Sep 6, 2019 at 2:13 PM Wilco Dijkstra wrote:
>
> Hi,
>
> +(simplify
> + (convert
> +(rshift
> + (mult
>
> > is the outer convert really necessary? That is, if we change
> > the simplification result to
>
> Indeed that should be "convert?" to make it optional.
Rather drop it, a
Hi Ian,
> I've committed a patch to update libgo to the Go 1.13beta1 release.
> As is usual with these updates, the patch is too large to include
> here; I've included the diffs of the various GCC-specific configury
> and other files. Bootstrapped and ran Go testsuite on
> x86_64-pc-linux-gnu. C
On Fri, Sep 6, 2019 at 3:00 PM Ulrich Weigand wrote:
>
> Richard Biener wrote:
> > On Tue, Sep 3, 2019 at 3:09 PM Ulrich Weigand wrote:
> > > > If you read the C standards fine-print then yes. But people (or
> > > > even the C frontend!) hardly get that correct since for example
> > > > for
> >
On Fri, 6 Sep 2019 at 19:43, Christophe Lyon wrote:
>
> On Fri, 6 Sep 2019 at 11:09, Christophe Lyon
> wrote:
> >
> > On Fri, 6 Sep 2019 at 10:28, Kyrill Tkachov
> > wrote:
> > >
> > >
> > > On 9/6/19 9:01 AM, Christophe Lyon wrote:
> > > > On Fri, 19 Jul 2019 at 11:00, Kyrill Tkachov
> > > >
Made some changes.
Feng
---
diff --git a/gcc/ipa-cp.c b/gcc/ipa-cp.c
index 33d52fe5537..f218f1093b8 100644
--- a/gcc/ipa-cp.c
+++ b/gcc/ipa-cp.c
@@ -1244,23 +1244,23 @@ initialize_node_lattices (struct cgraph_node *node)
}
}
-/* Return the result of a (possibly arithmetic) pass through j
On Fri, Sep 6, 2019 at 5:45 PM Ilya Leoshkevich wrote:
>
> > Am 06.09.2019 um 13:07 schrieb Richard Biener :
> >
> > On Thu, Sep 5, 2019 at 1:10 PM Ilya Leoshkevich wrote:
> >>
> >> Right now gimplifier does not allow VEC_COND_EXPR's condition to trap
> >> and introduces a temporary if this could
On Wed, 4 Sep 2019 at 22:03, Christophe Lyon wrote:
>
> On Wed, 4 Sep 2019 at 16:16, Kyrill Tkachov
> wrote:
> >
> > Hi Christophe,
> >
> > On 5/15/19 1:39 PM, Christophe Lyon wrote:
> > > Support additional relocations: TLS_GD32_FDPIC, TLS_LDM32_FDPIC, and
> > > TLS_IE32_FDPIC.
> > >
> > > We d
On Thu, 5 Sep 2019 at 11:03, Kyrill Tkachov wrote:
>
> Hi Christophe,
>
> On 9/5/19 9:30 AM, Christophe Lyon wrote:
> > On Thu, 29 Aug 2019 at 17:32, Kyrill Tkachov
> > wrote:
> >> Hi Christophe,
> >>
> >> On 5/15/19 1:39 PM, Christophe Lyon wrote:
> >>> Without this, when we are unwinding across
* config.sub: Import upstream version 2019-06-30.
* config.guess: Import upstream version 2019-07-24.
Just installed this in svn trunk.
Hi!
This PR is a repetition of PR87853, just for avx2 instead of sse2.
See https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00195.html
for the previous patch.
This time there is just one intrinsic with the problem (note, the previous
patch didn't have to change _mm_cmpeq_epi8, as __v16qi vs. __v16qs
On 9/6/19 4:46 PM, Matthew Malcomson wrote:
Hello.
> We have taken the libsanitizer library from the same SVN revision as
> the other sanitizer libraries are taken from (SVN revision 345033 as
> mentioned in libsanitizer/MERGE).
Note that I updated the libsanitizer in the meantime to r368656. Th
On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> This is a port of the LLVM-svn commit number 359914, it allows
> compilation of the library without using interceptors.
As mentioned in the previous email, the cherry-pick will not be
needed any longer.
Martin
On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> This is taken from upstream LLVM (change made in LLVM svn commit
> 351730), but is not a direct cherry-pick of a commit since the commit
> does not apply cleanly.
As mentioned in the previous email, the cherry-pick will not be
needed any longer.
Marti
On 06/09/19 18:08 -0400, Ed Smith-Rowland via libstdc++ wrote:
As the title says.
was (correctly) delivered without comparison ops. so we chould
check off p1085.
Indeed, thanks!
This includes the status updates for constexpr lib diffs posted previously.
I also regenerated the html (result
On 05/09/19 15:45 -0400, Ed Smith-Rowland via libstdc++ wrote:
Here is a patch to the libstdc++ docs re constexpr additions. They
reflect the latest macro assignments AFAICT.
Constexpr interator reqs are implemented in 9.1, the rest for 10.1.
Ok?
Should I bother adding the Constexpr interator
The function integer_range_info makes sure that, if provided, the
initial value fills in the especified range. However, it is necessary
to convert the values to a numerical context before comparing, to make
sure awk is using arithmetical order and not lexicographical order.
This patch annotates tests that make use of a significant a mount of
stack space. Embedded and other restricted targets may have problems
compiling and running these tests. Note that the annotations are in
many cases not exact.
As this implements a solution proposed by Jeff Law
This patch adds a new dg_require_effective_target procedure to the
testsuite infrastructure: indirect_calls. This new function tells
whether a target supports calls to non-constant call targets.
This patch also annotates the tests in the gcc.c-torture testuite that
requi
Hi.
On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> Ensuring that the shadow stack is cleared on normal function exit will
> be done by adding instrumentation to the function epilogue through the
> compiler.
> longjmp and setjmp are some abnormal methods of exiting the function
> that can't be handl
On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> This flag can't be used at the same time as any of the other sanitizers.
> We add an equivalent flag to -static-libasan in -static-libhwasan to
> ensure static linking.
Hello.
You're introducing new option argument -fsanitize=hwaddress. However,
clang
On Mon, Sep 9, 2019 at 11:18 AM Jakub Jelinek wrote:
>
> Hi!
>
> This PR is a repetition of PR87853, just for avx2 instead of sse2.
> See https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00195.html
> for the previous patch.
>
> This time there is just one intrinsic with the problem (note, the previou
On 09/09/19 11:06, Martin Liška wrote:
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> This flag can't be used at the same time as any of the other sanitizers.
>> We add an equivalent flag to -static-libasan in -static-libhwasan to
>> ensure static linking.
>
> Hello.
>
> You're introducing new
On 9/9/19 12:17 PM, Matthew Malcomson wrote:
> On 09/09/19 11:06, Martin Liška wrote:
>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>>> This flag can't be used at the same time as any of the other sanitizers.
>>> We add an equivalent flag to -static-libasan in -static-libhwasan to
>>> ensure stati
I think the bits are in good enough shape they can go in now.
I just committed the port to svn trunk, in a single commit, yay!
Many thanks to you, richard, seguer and the other reviewers for the
great feedback and suggestions. What got committed is certainly WAY
better than what I subm
On 09/09/19 11:01, Martin Liška wrote:
> Hi.
>
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> Ensuring that the shadow stack is cleared on normal function exit will
>> be done by adding instrumentation to the function epilogue through the
>> compiler.
>> longjmp and setjmp are some abnormal meth
On 9/6/19 4:46 PM, Matthew Malcomson wrote:
> Hello,
>
> This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
> address sanitizer (HWASAN) in GCC. The document describing HWASAN can be
> found
> here http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.
He
On 9/9/19 12:29 PM, Matthew Malcomson wrote:
> On 09/09/19 11:01, Martin Liška wrote:
>> Hi.
>>
>> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>>> Ensuring that the shadow stack is cleared on normal function exit will
>>> be done by adding instrumentation to the function epilogue through the
>>> co
On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
>> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
>>> Ok, hopefully nobody is strongly against. I've just retested the
>>> patch and installed it as r275450.
>>
>> --- a/gcc/c-fam
On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> > On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
> >> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> >>> Ok, hopefully nobody is strongly against. I've just ret
And some further simplifications and improvements to the constructor
constraints for std::span.
This patch simplifies the constraints on the constructors from arrays by
removing the redundant checks that element_type and value_type are
convertible to element_type. The incorrect uses of _
On 08/09/19 16:44 +0300, Antony Polukhin wrote:
We've already beaten this topic to death, so let's put a final nail in
the coffin:
__to_chars_10_impl is quite fast. According to the IACA the main loop
takes only 6.0 cycles, the whole function with one iteration takes
10.0 cycles. Replacing the
Prathamesh Kulkarni writes:
> With patch, the only following FAIL remains for aarch64-sve.exp:
> FAIL: gcc.target/aarch64/sve/cond_unary_2.c -march=armv8.2-a+sve
> scan-assembler-times \\tmovprfx\\t 6
> which now contains 14.
> Should I adjust the test, assuming the change isn't a regression ?
We
bt-load.c has AFAIK been dead code since the removal of the SH5 port
in 2016. I have a patch series that would need to update the liveness
tracking in a nontrivial way, so it seemed better to remove the pass
rather than install an untested and probably bogus change.
Tested on aarch64-linux-gnu, x
On 9/9/19 1:08 PM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
>> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
>>> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> Ok, hopefull
I have a series of patches that (as a side effect) makes all rtl
passes use the information collected by -fipa-ra. This showed up a
latent bug in the liveness tracking in regrename.c, which doesn't take
CALL_INSN_FUNCTION_USAGE into account when processing clobbers.
This actually seems to be quit
On Mon, 9 Sep 2019 at 12:24, Martin Liška wrote:
>
> On 9/9/19 1:08 PM, Jakub Jelinek wrote:
> > On Mon, Sep 09, 2019 at 01:02:32PM +0200, Martin Liška wrote:
> >> On 9/6/19 4:56 PM, Jakub Jelinek wrote:
> >>> On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
> On Fri, Sep 06, 20
On Mon, Sep 09, 2019 at 01:24:53PM +0200, Martin Liška wrote:
> You are right. What about the suggested patch?
Can you please quickly (say with svn blame) double check whether the
descriptions weren't actually right but misleading (an option could
be deprecated in N and removed in N+1 or so, so se
On 9/9/19 1:39 PM, Jakub Jelinek wrote:
> On Mon, Sep 09, 2019 at 01:24:53PM +0200, Martin Liška wrote:
>> You are right. What about the suggested patch?
>
> Can you please quickly (say with svn blame) double check whether the
> descriptions weren't actually right but misleading (an option could
>
Currently when you compile with -g -flto and then link without
repeating -g you'll get a binary that has all early debug
but none of the late because the driver doesn't pass -g along
to the LTRANS stage.
This has always been the case and as with other options
"guessing" correctly is hard. The f
Hi.
I'm sending slightly updated version of the patch where we
need to properly select type in maybe_fold_comparisons_from_match_pd
function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
and so that we can't return a boolean_type_node.
Patch can bootstrap on x86_64-linux-gnu and s
Hi.
The patch is about transition of and_comparisons_1 matching
into match.pd.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 15045058d6caf84734ea949a297b6e31d9a8647c Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 6 Sep
Hi.
Next part if about transition of part of the OR patterns
into match.pd.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 0cc83b72025d243e9e6ebaa9a85c68c17f9cd09a Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 6 Sep 20
And finally the second part of OR patterns.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
Ready to be installed?
Thanks,
Martin
>From 621d25811179bce8a8ad58a88b742528e97917d6 Mon Sep 17 00:00:00 2001
From: Martin Liska
Date: Fri, 6 Sep 2019 12:59:36 +0200
Subject: [PATCH
PING^3
On 8/30/19 10:55 AM, Martin Liška wrote:
> PING^2
>
> On 8/26/19 2:34 PM, Martin Liška wrote:
>> PING^1
>>
>> On 8/13/19 1:51 PM, Martin Liška wrote:
>>> On 8/2/19 2:40 PM, David Malcolm wrote:
Something that occurred to me reading the updated patch: maybe it would
make things ea
PING^1
On 8/26/19 12:04 PM, Martin Liška wrote:
> Ok. I have a semi-working patch that has issues for inline clones.
> When we call cgraph_node::get_untransformed_body for an inline clone,
> then one needs to use clone_of->order to find proper LTO stream.
>
> What's more problematic is that such
On 09.09.19 14:02, Richard Biener wrote:
So this is really a very poor mans solution that also might
uncover issues with -g0 at compile-time vs. -g at link-time
if there are mixed -g0/g TUs in the LTO link.
Could this be documented, at least in the man page? e.g. invoke.texi. As a
bonus I wou
Hi.
I'm suggesting to rename Deprecated to IgnoreWarn as deprecated
means that an option is still working, but marked as obsolete.
We use the name for options that removed (no longer supported),
but still supported for backward compatibility.
Patch can bootstrap on x86_64-linux-gnu and survives r
On Mon, 9 Sep 2019, Martin Liška wrote:
> Hi.
>
> I'm sending slightly updated version of the patch where we
> need to properly select type in maybe_fold_comparisons_from_match_pd
> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
> and so that we can't return a boolean_type
On Mon, 9 Sep 2019, Martin Liška wrote:
I'm sending slightly updated version of the patch where we
need to properly select type in maybe_fold_comparisons_from_match_pd
function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
and so that we can't return a boolean_type_node.
+ tre
On 9/9/19 3:10 PM, Marc Glisse wrote:
> On Mon, 9 Sep 2019, Martin Liška wrote:
>
>> I'm sending slightly updated version of the patch where we
>> need to properly select type in maybe_fold_comparisons_from_match_pd
>> function for the created SSA_NAMEs. We can be called for a VECTOR_TYPE
>> and s
On Mon, 9 Sep 2019, Martin Liška wrote:
> On 9/9/19 3:10 PM, Marc Glisse wrote:
> > On Mon, 9 Sep 2019, Martin Liška wrote:
> >
> >> I'm sending slightly updated version of the patch where we
> >> need to properly select type in maybe_fold_comparisons_from_match_pd
> >> function for the created S
On 9/9/19 3:10 PM, Richard Biener wrote:
> On Mon, 9 Sep 2019, Martin Liška wrote:
>
>> Hi.
>>
>> I'm sending slightly updated version of the patch where we
>> need to properly select type in maybe_fold_comparisons_from_match_pd
>> function for the created SSA_NAMEs. We can be called for a VECTOR_
On 9/9/19 2:24 PM, Martin Liška wrote:
> Hi.
>
> The patch is about transition of and_comparisons_1 matching
> into match.pd.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
Updated version (as mentioned in part 1).
Ma
On Mon, 9 Sep 2019, Martin Liška wrote:
> On 9/9/19 3:10 PM, Richard Biener wrote:
> > On Mon, 9 Sep 2019, Martin Liška wrote:
> >
> >> Hi.
> >>
> >> I'm sending slightly updated version of the patch where we
> >> need to properly select type in maybe_fold_comparisons_from_match_pd
> >> function
On 9/9/19 3:42 PM, Richard Biener wrote:
> There is no newly created GIMPLE?
Hm, I thought from the beginning that maybe_fold_comparisons_from_match_pd
can come up with new temporary expressions that need to be inserted into
GIMPLE stream? But that's probably handled in ifcombine with:
On Mon, 9 Sep 2019, Matthias Klose wrote:
> On 09.09.19 14:02, Richard Biener wrote:
> > So this is really a very poor mans solution that also might
> > uncover issues with -g0 at compile-time vs. -g at link-time
> > if there are mixed -g0/g TUs in the LTO link.
>
> Could this be documented, at l
Currently character type names are given as CHARACTER(1) or CHARACTER(4)
for unicode. I find this misleading as I would expect the length to be
used instead of the kind.
I changed gfc_typename in misc.c to use the character length structure
in the gfc_typespec structure. This works fine for c
On Mon, 9 Sep 2019, Martin Liška wrote:
> On 9/9/19 3:42 PM, Richard Biener wrote:
> > There is no newly created GIMPLE?
>
> Hm, I thought from the beginning that maybe_fold_comparisons_from_match_pd
> can come up with new temporary expressions that need to be inserted into
> GIMPLE stream? But t
Hi Martin,
On Mon, Sep 09, 2019 at 03:04:20PM +0200, Martin Liška wrote:
> I'm suggesting to rename Deprecated to IgnoreWarn
That is an even worse name IMO.
Just call it Removed or Deleted or something like that? Something that
says what it _is_, not something that is an amalgamate of how we sh
On 09.09.19 15:51, Richard Biener wrote:
On Mon, 9 Sep 2019, Matthias Klose wrote:
On 09.09.19 14:02, Richard Biener wrote:
So this is really a very poor mans solution that also might
uncover issues with -g0 at compile-time vs. -g at link-time
if there are mixed -g0/g TUs in the LTO link.
Co
On Mon, Sep 09, 2019 at 08:56:17AM -0500, Segher Boessenkool wrote:
> Hi Martin,
>
> On Mon, Sep 09, 2019 at 03:04:20PM +0200, Martin Liška wrote:
> > I'm suggesting to rename Deprecated to IgnoreWarn
>
> That is an even worse name IMO.
>
> Just call it Removed or Deleted or something like that?
On Mon, Sep 09, 2019 at 04:04:01PM +0200, Jakub Jelinek wrote:
> On Mon, Sep 09, 2019 at 08:56:17AM -0500, Segher Boessenkool wrote:
> > Hi Martin,
> >
> > On Mon, Sep 09, 2019 at 03:04:20PM +0200, Martin Liška wrote:
> > > I'm suggesting to rename Deprecated to IgnoreWarn
> >
> > That is an even
On Mon, Sep 09, 2019 at 09:08:43AM -0500, Segher Boessenkool wrote:
> On Mon, Sep 09, 2019 at 04:04:01PM +0200, Jakub Jelinek wrote:
> > On Mon, Sep 09, 2019 at 08:56:17AM -0500, Segher Boessenkool wrote:
> > > Hi Martin,
> > >
> > > On Mon, Sep 09, 2019 at 03:04:20PM +0200, Martin Liška wrote:
>
Richard Biener wrote:
> On Fri, Sep 6, 2019 at 3:00 PM Ulrich Weigand wrote:
> > But as far as I can see, for *atomic* operations at least, we do make
> > that assumption. The x86 back-end for example just assumes that any
> > "int" or "long" object that is the target of an atomic operation is
>
On Thu, 5 Sep 2019 at 11:52, Arnaud Charlet wrote:
>
> > > Can someone please remind me in which repository I can find the GCC
> > > prerequisites doc sources?
> >
> > Answering my own question: found it under gcc/doc/install.texi
> >
> > Working on it...
>
> Just installed the following change on
> PING^1
>
> On 8/26/19 12:04 PM, Martin Liška wrote:
> > Ok. I have a semi-working patch that has issues for inline clones.
> > When we call cgraph_node::get_untransformed_body for an inline clone,
> > then one needs to use clone_of->order to find proper LTO stream.
This seems OK to me - when us
Andrea Corallo writes:
> Hi all,
> yesterday I've found an interesting bug in libgccjit.
> Seems we have an hard limitation of 200 characters for literal strings.
> Attempting to create longer strings lead to ICE during pass_expand
> while performing a sanity check in get_constant_size.
>
> Trac
> > Just installed the following change on trunk, thanks again for your
> > feedback!
> >
> > 2019-09-05 Arnaud Charlet
> >
> > * doc/install.texi: Update and clarify requirements to build GNAT.
> >
> Hi Arnaud,
>
> It seems there's a problem with this patch:
> /snapshots/gcc.git~maste
On Mon, 9 Sep 2019 at 17:18, Arnaud Charlet wrote:
>
> > > Just installed the following change on trunk, thanks again for your
> > > feedback!
> > >
> > > 2019-09-05 Arnaud Charlet
> > >
> > > * doc/install.texi: Update and clarify requirements to build GNAT.
> > >
> > Hi Arnaud,
> >
>
On 9/9/19 5:21 AM, Richard Sandiford wrote:
> bt-load.c has AFAIK been dead code since the removal of the SH5 port
> in 2016. I have a patch series that would need to update the liveness
> tracking in a nontrivial way, so it seemed better to remove the pass
> rather than install an untested and pr
Hello,
Since all patches of v5 have now been approved, I'm posting v6 to
share the actual patches I'm about to commit (some had minor changes
compared to v5).
Thanks to the reviewers,
Christophe
Changes between v5 and v6:
- rebased on top of recent gcc-10 master (September 9th, 2019)
- fixed li
From: Christophe Lyon
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.opt: Add -mfdpic option.
* doc/invoke.texi: Add documentation for -mfdpic.
Change-Id: I05b98d6ae87c2b3fc04dd7fba415c730accdf33e
diff --git a/gcc/config/arm/arm.opt b/gcc/co
From: Christophe Lyon
The new arm-uclinuxfdpiceabi target behaves pretty much like
arm-linux-gnueabi. In order to enable the same set of features, we
have to update several configure scripts that generally match targets
like *-*-linux*: in most places, we add *-uclinux* where there is
already *-l
From: Christophe Lyon
In FDPIC mode, we set -fPIE unless the user provides -fno-PIE, -fpie,
-fPIC or -fpic: indeed FDPIC code is PIC, but we want to generate code
for executables rather than shared libraries by default.
We also make sure to use the --fdpic assembler option, and select the
approp
From: Christophe Lyon
The FDPIC register is hard-coded to r9, as defined in the ABI.
We have to disable tailcall optimizations if we don't know if the
target function is in the same module. If not, we have to set r9 to
the value associated with the target module.
When generating a symbol addres
From: Christophe Lyon
In FDPIC, we need to make sure __do_global_dtors_aux and frame_dummy
are referenced by their address, not by pointers to the function
descriptors.
2019-XX-XX Christophe Lyon
Mickaël Guêné
libgcc/
* libgcc/crtstuff.c: Add support for FDPIC.
Chan
From: Christophe Lyon
The main difference with existing support is that function addresses
are function descriptor addresses instead. This means that all code
dealing with function pointers now has to cope with function
descriptors instead.
For the same reason, Linux kernel helpers can no longer
From: Christophe Lyon
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.h (PIC_REGISTER_MAY_NEED_SAVING): New helper.
* config/arm/arm.c (arm_compute_save_reg0_reg12_mask): Handle
FDPIC.
Change-Id: I0f3b2023ab2a2a0433dfe081dac6bbb194b7a76
From: Christophe Lyon
Use local binding rules to decide whether we can use GOTOFFFUNCDESC to
compute the function address.
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (arm_fdpic_local_funcdesc_p): New function.
(legitimize_pic_address): E
From: Christophe Lyon
In FDPIC mode, the trampoline generated to support pointers to nested
functions looks like:
.wordtrampoline address
.wordtrampoline GOT address
ldr r12, [pc, #8]
ldr r9, [pc, #8]
ldr
From: Christophe Lyon
Support additional relocations: TLS_GD32_FDPIC, TLS_LDM32_FDPIC, and
TLS_IE32_FDPIC.
We do not support the GNU2 TLS dialect.
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (tls_reloc): Add TLS_GD32_FDPIC,
TLS_LDM32_FDP
From: Christophe Lyon
2019-XX-XX Christophe Lyon
Mickaël Guêné
libgcc/
* unwind-arm-common.inc (ARM_SET_R7_RT_SIGRETURN)
(THUMB2_SET_R7_RT_SIGRETURN, FDPIC_LDR_R12_WITH_FUNCDESC)
(FDPIC_LDR_R9_WITH_GOT, FDPIC_LDR_PC_WITH_RESTORER)
(FDPIC_FUNCDE
From: Christophe Lyon
We call __aeabi_read_tp() to get the thread pointer. Since this is a
function call, we have to restore the FDPIC register afterwards.
2019-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (arm_load_tp): Add FDPIC support.
* co
From: Christophe Lyon
Without this, when we are unwinding across a signal frame we can jump
to an even address which leads to an exception.
This is needed in __gnu_persnality_sigframe_fdpic() when restoring the
PC from the signal frame since the PC saved by the kernel has the LSB
bit set to zero
From: Christophe Lyon
Several tests cannot work on ARM-FDPIC for various reasons: skip them,
or skip some directives.
gcc.dg/20020312-2.c: Skip since it forces -fno-pic.
gcc.target/arm/:
* Skip since r9 is clobbered by assembly code:
20051215-1.c
mmx-1.c
pr61948.c
pr77933-1.c
pr77933-
From: Christophe Lyon
In FDPIC mode, r9 is saved in addition to other registers, so update
the expected patterns accordingly.
2019-XX-XX Christophe Lyon
Mickaël Guêné
* gcc/testsuite/
* gcc.target/arm/interrupt-1.c: Add scan-assembler pattern for
arm*-*-uclin
From: Christophe Lyon
Some tests fail on arm*-*-uclinuxfdpiceabi because it generates PIC
code and they don't support it: skip them. They also fail on
arm*-linux* when forcing -fPIC.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* gcc.target/arm/eliminate.c: Accept only nonpic ta
From: Christophe Lyon
Add *-*-uclinux* to tests that work on this target.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* g++.dg/abi/forced.C: Add *-*-uclinux*.
* g++.dg/abi/guard2.C: Likewise.
* g++.dg/ext/cleanup-10.C: Likewise.
* g++.dg/ext/cleanup-11.C
From: Christophe Lyon
Some tests have the "nonpic" guard, but pass on
arm*-*-uclinuxfdpiceabi because it is in PIE mode by default. Rather
than adding this target to all these tests, add the "pie_enabled"
effective target.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* g++.dg/cp
From: Christophe Lyon
uclibc defines bswap_32, so use a different name in this test.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* gcc.target/arm/pr43698.c (bswap_32): Rename as my_bswap_32.
Change-Id: I2591bd911030814331cabf97ee5cf6cf8124b4f3
diff --git a/gcc/testsuite/gcc.t
I have a series of patches that allows several ABIs to be used
interoperably within the same translation unit. Part of that involves
removing our reliance on global register sets that describe "the ABI".
One of the difficulties is that we have several global sets that contain
related information.
From: Christophe Lyon
Since FDPIC currently supports arm and thumb-2 modes only, these tests
fail because they enforce an architecture version that doesn't match
these restrictions.
This patch introduces new values for the arm_arch effective-target
(v4t_thumb, v5t_thumb, v5te_thumb, v6_thumb, v6
From: Christophe Lyon
The recent stack_protect_combined_set_insn and
stack_protect_combined_test_insn force recomputing of GOT base, but
need to take into account that in FDPIC mode, the PIC register is
fixed by the ABI (r9).
2019-XX-XX Christophe Lyon
gcc/
* config/arm/arm.m
From: Christophe Lyon
Since FDPIC does not support -static, skip the related tests.
2019-XX-XX Christophe Lyon
gcc/testsuite/
* lib/target-supports.exp (check_effective_target_static): Disable
for ARM FDPIC target.
Change-Id: I119d0541e53f2f1e531540b20e7bc47d8338d89a
From: Christophe Lyon
The ldaddr macro in sjlj.S needs to be updated to support the FDPIC
model.
2019-XX-XX Christophe Lyon
libitm/
* config/arm/sjlj.S (ldaddr): Add FDPIC support.
Change-Id: Ieb2c6613363341d109c3500af0575b133b17407d
diff --git a/libitm/config/arm/sjlj.S b/
From: Christophe Lyon
2019-XX-XX Christophe Lyon
libstdc++-v3/
* acinclude.m4: Handle uclinux*.
* configure: Regenerate.
* configure.host: Handle uclinux*
Change-Id: Ia1b53693625e4153a090fcfc925a4d605bc98e59
diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-
We have two styles of HARD_REG_SET: a single integer based on
HOST_WIDEST_FAST_INT (used when FIRST_PSEUDO_REGISTER is small enough)
or an array of integers. One of the nice properties of this arrangement
is that:
void foo (const HARD_REG_SET);
is passed by value as an integer when the set is
On 09/09/19 11:47, Martin Liška wrote:
> On 9/6/19 4:46 PM, Matthew Malcomson wrote:
>> Hello,
>>
>> This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
>> address sanitizer (HWASAN) in GCC. The document describing HWASAN can be
>> found
>> here http://clang.llvm.org/docs/Ha
This patch replaces "COPY_HARD_REG_SET (x, y)" with "x = y".
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (COPY_HARD_REG_SET): Delete.
* caller-save.c (save_call_clobbered_regs): Use assignment instead
of COPY_HARD_REG_SET.
* config/epiphany/epiphany.c (e
1 - 100 of 173 matches
Mail list logo
