This libgo patch changes the go tool to look for a tool build ID
before hashing the entire file It also fixes the key used to store
the ID. This is a significant speedup in go tool run time.
Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu. Committed
to mainline.
Ian
Index: gcc/go/gofro
This patch to the Go frontend permits inlining constant expressions
and expression statements. This relatively minor change increases the
number of inlinable functions/methods in the standard library from 983
to 2179. In particular it permits inlining math/bits/RotateLeftNN.
This restores the spe
On 9/9/19 7:03 PM, Marek Polacek wrote:
On Mon, Sep 09, 2019 at 04:59:57PM -0400, Jason Merrill wrote:
Maybe check this in one place, after splice_late_return_type?
That works! So like this?
Bootstrapped/regtested on x86_64-linux, ok for trunk?
OK, thanks.
Jason
+Peter Collingbourne +Evgeniy Stepanov (the main developers of HWASAN
in LLVM, FYI)
Please note that Peter has recently implemented support for globals in
LLVM's HWASAN.
--kcc
On Mon, Sep 9, 2019 at 8:55 AM Matthew Malcomson
wrote:
>
> On 09/09/19 11:47, Martin Liška wrote:
> > On 9/6/19 4:46 P
On Mon, Sep 09, 2019 at 04:59:57PM -0400, Jason Merrill wrote:
> Maybe check this in one place, after splice_late_return_type?
That works! So like this?
Bootstrapped/regtested on x86_64-linux, ok for trunk?
2019-09-09 Marek Polacek
PR c++/84374 - diagnose invalid uses of decltype(au
On Sat, Sep 7, 2019 at 5:03 AM Andreas Schwab wrote:
>
> This has dropped support for riscv64:
Thanks, and sorry. The gccgo-local changes were lost when the files
moved. I restored them as follows. Bootstrapped and ran Go testsuite
on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gc
On Mon, Sep 09, 2019 at 03:56:52PM -0500, Segher Boessenkool wrote:
> On Mon, Sep 09, 2019 at 04:32:39PM -0400, Michael Meissner wrote:
> > On Fri, Sep 06, 2019 at 07:09:45AM -0500, Segher Boessenkool wrote:
> > > On Wed, Sep 04, 2019 at 01:26:27PM -0400, Michael Meissner wrote:
> > >
> > > [snip]
On Mon, 9 Sep 2019, Tejas Joshi wrote:
> Hello.
> I am using real_isfinite to check for overflow conditions. How should
> I check for underflow? I have tried different ways but they
> contradicted other cases to pass.
I think the right check for underflow is: *before* calling
exact_real_truncate
On Mon, 9 Sep 2019, Jakub Jelinek wrote:
> > "IgnoreWarn" reads as "ignore the warning".
> >
> > If we want it named as two things, can we just make it two things?
> > "Ignore WarnDeleted" or something. Which also says what it is warning
> > about.
>
> Or WarnRemoved. Both work for me, but ult
On 9/2/19 9:28 AM, 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.
Thanks, Paolo.
/
OK.
Jaso
../../../libgo/go/golang.org/x/sys/cpu/cpu.go:17:30: error: reference to
undefined name ‘cacheLineSize’
17 | type CacheLinePad struct{ _ [cacheLineSize]byte }
| ^
../../../libgo/go/golang.org/x/sys/cpu/cpu_linux.go:56:2: error: reference to
undefined name ‘do
On 9/8/19 11:47 AM, Marek Polacek wrote:
[dcl.type.auto.deduct]/5 "If the placeholder-type-specifier is of the
form type-constraintopt decltype(auto), T shall be the placeholder alone."
So, only plain decltype(auto) is allowed. But we aren't diagnosing it in
function declarations, because do_au
On Mon, Sep 09, 2019 at 04:32:39PM -0400, Michael Meissner wrote:
> On Fri, Sep 06, 2019 at 07:09:45AM -0500, Segher Boessenkool wrote:
> > On Wed, Sep 04, 2019 at 01:26:27PM -0400, Michael Meissner wrote:
> >
> > [snip]
> >
> > > So to keep other passes from 'improving' things, I opted to do the
On 9/7/19 3:37 PM, Marek Polacek wrote:
* parser.c (CP_PARSER_FLAGS_NO_DELAY_NOEXCEPT): New parser flag.
Is it feasible to reverse this, and specifically delay parsing of
noexcept-specifications on member function declarations? When else
would we want it?
Jason
On Mon, 9 Sep 2019 at 22:06, Prathamesh Kulkarni
wrote:
>
> On Mon, 9 Sep 2019 at 16:45, Richard Sandiford
> wrote:
> >
> > 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
>
On Fri, Sep 06, 2019 at 07:09:45AM -0500, Segher Boessenkool wrote:
> On Wed, Sep 04, 2019 at 01:26:27PM -0400, Michael Meissner wrote:
>
> [snip]
>
> > So to keep other passes from 'improving' things, I opted to do the pass as
> > the
> > last pass before final.
>
> If the problem is that you
On Fri, Sep 06, 2019 at 07:50:51AM -0500, Segher Boessenkool wrote:
> On Thu, Sep 05, 2019 at 08:18:02PM -0400, Michael Meissner wrote:
> > On Thu, Aug 29, 2019 at 04:32:07PM -0500, Segher Boessenkool wrote:
> > > This is not just for reload anymore, so please don't name it that.
> > > Renaming
>
On 8/26/19 3:00 AM, Richard Biener wrote:
> On Fri, Aug 23, 2019 at 9:19 PM Jeff Law wrote:
>>
>> On 8/22/19 4:46 AM, Richard Biener wrote:
> Also you seem to use this info to constrain optimization when you
> might remember that types of addresses do not carry such information...
> Th
On Sat, Sep 7, 2019 at 8:20 AM Andreas Schwab wrote:
>
> On Sep 07 2019, Bernd Edlinger wrote:
>
> > Hi Ian,
> >
> >> gotools:
> >>
> >> 2019-09-06 Ian Lance Taylor
> >>
> >> * Makefile.am (check-carchive-test): Just run "go test", not "go
> >> test carchive_test.go".
> >> * Makefile.in: Regen
On 21/08/19 23:36 -0400, Ed Smith-Rowland via libstdc++ wrote:
On 8/20/19 6:14 PM, Jonathan Wakely wrote:
On 16/08/19 22:39 -0400, Ed Smith-Rowland via libstdc++ wrote:
The latest draft and I guess the above paper changed the macro
names for the C++20 constexpr lib featues.
__cpp_lib_constexp
In the Go frontend, for the main package, we add an implicit import of
the runtime package, to ensure that it is initialized. That import
used the predeclared location, which caused various tests, notably
Named_type::is_builtin, to treat these imported names as builtin.
Start using a real location
We forgot to ever traverse types of constant expressions in the Go
frontend. This rarely makes a difference--evidently, since nobody
noticed--but it does matter when we inline constant expressions: we
need to ensure that the type is visible to the importing code. This
patch fixes the omissions.
On Thu, 22 Aug 2019 at 00:05, Prathamesh Kulkarni
wrote:
>
> On Mon, 19 Aug 2019 at 22:14, James Greenhalgh
> wrote:
> >
> > On Thu, Aug 15, 2019 at 02:11:25PM +0100, Prathamesh Kulkarni wrote:
> > > On Thu, 8 Aug 2019 at 11:22, Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Thu, 1 Aug 201
Hi all.
Please take a look at v2 (attached).
I changed patch according to review comments. The same testing was performed
again.
Thanks,
Dmitrij
On Thu, Sep 05, 2019 at 06:34:49PM +0300, Dmitrij Pochepko wrote:
> This patch adds matching for Hamming weight (popcount) implementation. The
> foll
On 9/9/19 8:53 PM, Jeff Law wrote:
On 9/6/19 7:36 AM, Martin Liška wrote:
Hi.
I've been working on transition of cond expressions to match.pd.
With my changes I noticed there's one wrong pattern that leads to:
Transforming _6 > _7 & _6 < _7 into 0
...
/home/marxin/Programming/gcc/gcc/testsuite
Hi,
thank you for looking into it.
On Fri, Sep 06, 2019 at 12:13:34PM +, 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 "co
On 9/6/19 4:58 AM, Graham Markall wrote:
> This patch is an RFC to invite comments as to whether the approach
> to solving the problem is a suitable one for upstream GCC, or whether
> there are alternative approaches that would be recommended.
>
> Motivation
> --
>
> We have observed that
Hi,
thank you for looking into it.
On Fri, Sep 06, 2019 at 12:23:40PM +0200, Richard Biener wrote:
> On Thu, Sep 5, 2019 at 5:35 PM Dmitrij Pochepko
> wrote:
> >
> > This patch adds matching for Hamming weight (popcount) implementation. The
> > following sources:
> >
> > int
> > foo64 (unsigned
On 9/6/19 7:36 AM, Martin Liška wrote:
> Hi.
>
> I've been working on transition of cond expressions to match.pd.
> With my changes I noticed there's one wrong pattern that leads to:
>
> Transforming _6 > _7 & _6 < _7 into 0
> ...
> /home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/vector-c
On 09/09/19 13:04 -0400, Ed Smith-Rowland wrote:
On 9/9/19 5:38 AM, Jonathan Wakely wrote:
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 st
On 9/6/19 12:02 AM, Bernd Edlinger wrote:
> Hi,
>
>
> as discussed already I propose this little refactoring as a follow-up
> which is not supposed to be doing any change to the code generation.
>
> I tried to get the description of ALT_RTL right, since it changed
> quite a lot recently what thi
On 9/4/19 12:16 PM, Rafael Tsuha wrote:
> Hi, Jeff
>
> Em seg, 29 de abr de 2019 às 18:22, Jeff Law escreveu:
>>
>> On 1/22/19 12:31 PM, Rafael Tsuha wrote:
>>> This patch simplifies the expression sinh (x) / cosh (x) to tanh (x).
>>> This rule is mathematically valid.
>>>
>>> There's a slight di
Hi
This patch improves stl_algobase.h
copy/copy_backward/fill/fill_n/equal implementations. The improvements are:
- activation of algo specialization for __gnu_debug::_Safe_iterator (w/o
_GLIBCXX_DEBUG mode)
- activation of algo specialization for _Deque_iterator even if mixed
with ano
On September 9, 2019 4:17:20 PM GMT+02:00, Ulrich Weigand
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
Jeff Law writes:
> On 9/9/19 9:53 AM, Richard Sandiford wrote:
>> 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:
>>
>>
Jeff Law writes:
> On 9/9/19 5:33 AM, Richard Sandiford wrote:
>> 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_
On 9/6/19 5:26 PM, Martin Sebor wrote:
> Just a heads up that I tested the patch with Glibc and the kernel.
> It exposes some of the same "abuses" of (near) zero-length arrays
> as the most recent improvement in this area. In glibc, it
> complains about code in fileops.c, iofwide.c, libc-tls.c, an
On 9/9/19 5:33 AM, Richard Sandiford wrote:
> 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
I never got around to updating these testcases after the combine hardreg
changes (and more). This patch does not fix all failures, just the simple
ones that are obvious improvements. The rest need more work.
Committing to trunk.
Segher
2019-09-09 Segher Boessenkool
gcc/testsuite/
On 9/9/19 10:37 AM, Richard Sandiford wrote:
> [Follows on from https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00571.html]
>
> We currently maintain global REG_SET versions of fixed_reg_set
> and regs_invalidated_by_call. With bitmap_view, we can instead
> operate directly on the underlying HARD_R
On 9/9/19 10:32 AM, Richard Sandiford wrote:
> This patch adds a bitmap_view class that creates a read-only,
> on-stack bitmap representation of an array-like object X. The main
> use case is to allow HARD_REG_SETs to be used in REG_SET (i.e. bitmap)
> operations.
>
> For now it only handles cons
On 9/9/19 10:02 AM, Richard Sandiford wrote:
> This patch makes ior_hard_reg_conflicts take a const_hard_reg_set
> rather than a pointer, so that it can be passed a temporary object
> in later patches.
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * ira-int.h (ior_hard_reg_conflicts): T
On 9/9/19 10:02 AM, Richard Sandiford wrote:
> Use "x == y" instead of "hard_reg_set_equal_p (x, y)".
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (HARD_REG_SET::operator==): New function.
> (HARD_REG_SET::operator!=): Likewise.
> (hard_reg_set_equal_p): De
On 9/9/19 10:01 AM, Richard Sandiford wrote:
> Use "x |= ~y" instead of "IOR_COMPL_HARD_REG_SET (x, y)", or just
> "x | ~y" if the result is a temporary.
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (IOR_COMPL_HARD_REG_SET): Delete.
> * config/aarch64/cortex-a57-
On 9/9/19 10:01 AM, Richard Sandiford wrote:
> Use "x &= ~y" instead of "AND_COMPL_HARD_REG_SET (x, y)", or just
> "x & ~y" if the result is a temporary. This means that we're splitting
> it into two operations, but the compiler should be able to combine them
> for reasonable values of FIRST_PSEUD
On 9/9/19 10:00 AM, Richard Sandiford wrote:
> Use "x |= y" instead of "IOR_HARD_REG_SET (x, y)" (or just "x | y"
> if the result is a temporary).
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (HARD_REG_SET::operator|): New function.
> (HARD_REG_SET::operator|=):
On 9/9/19 9:59 AM, Richard Sandiford wrote:
> Use "x &= y" instead of "AND_HARD_REG_SET (x, y)" (or just "x & y"
> if the result is a temporary).
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (HARD_REG_SET::operator&): New function.
> (HARD_REG_SET::operator&): Li
On 9/9/19 9:59 AM, Richard Sandiford wrote:
> "COMPL_HARD_REG_SET (x, y)" becomes "x = ~y".
>
>
> 2019-09-09 Richard Sandiford
>
> gcc/
> * hard-reg-set.h (HARD_REG_SET::operator~): New function.
> (COMPL_HARD_REG_SET): Delete.
> * config/c6x/c6x.c (c6x_call_saved_register_u
On 9/9/19 9:58 AM, Richard Sandiford wrote:
> 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 CO
On 9/9/19 9:53 AM, Richard Sandiford wrote:
> 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_
On 9/9/19 5:41 AM, Jonathan Wakely wrote:
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?
Sho
ping
Cleanup 64-bit multiplies. Combine the expanders using iterators.
Merge the signed/unsigned multiplies as well as the pre-Armv6 and Armv6
variants. Split DImode operands early into parallel sets inside the
MULL/MLAL instructions - this improves register allocation and avoids
subreg
ping
Cleanup the various highpart multiply patterns using iterators.
As a result the signed and unsigned variants and the pre-Armv6
multiply operand constraints are all handled in a single pattern
and simple expander.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wil
ping
Cleanup the 32-bit multiply patterns. Merge the pre-Armv6 with the Armv6
patterns, remove useless alternatives and order the accumulator operands
to prefer MLA Ra, Rb, Rc, Ra whenever feasible.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wilco Dijkstra
ping
Remove various MULS/MLAS patterns which are enabled when optimizing for
size. However the codesize gain from these patterns is so minimal that
there is no point in keeping them.
Bootstrap OK on armhf, regress passes.
ChangeLog:
2019-09-03 Wilco Dijkstra
* config/a
ping
In aarch64_classify_symbol symbols are allowed full-range 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
fo
ping
We currently use default mid-end expanders for logical DImode operations.
These split operations without first splitting off complex immediates or
memory operands. The resulting expansions are non-optimal and allow for
fewer LDRD/STRD opportunities. So add back explicit expanders wh
ping
Currently the Arm backend selects the alternative sched pressure algorithm.
The issue is that this doesn't take register pressure into account, and so
it causes significant additional spilling on Arm where there are only 14
allocatable registers. SPEC2006 shows si
Setting HONOR_REG_ALLOC_ORDER improves codesize with -Os, however it generates
slower and larger code with -O2 and higher. So only set it when optimizing for
size. On Cortex-A57 this improves SPECINT2006 by 0.15% and SPECFP2006 by 0.25%
while reducing codesize.
Bootstrap OK, OK for commit?
Chan
On 9/9/19 5:38 AM, Jonathan Wakely wrote:
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
previ
Currently arm_legitimize_address doesn't handle Thumb-2 at all, resulting in
inefficient code. Since Thumb-2 supports similar address offsets use the Arm
legitimization code for Thumb-2 to get significant codesize and performance
gains. SPECINT2006 shows 0.4% gain on Cortex-A57, while SPECFP impr
On Mon, 9 Sep 2019 at 16:45, Richard Sandiford
wrote:
>
> 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.
> > S
[Follows on from https://gcc.gnu.org/ml/gcc-patches/2019-09/msg00571.html]
We currently maintain global REG_SET versions of fixed_reg_set
and regs_invalidated_by_call. With bitmap_view, we can instead
operate directly on the underlying HARD_REG_SETs, avoiding the
need to keep the two pieces of da
This patch adds a bitmap_view class that creates a read-only,
on-stack bitmap representation of an array-like object X. The main
use case is to allow HARD_REG_SETs to be used in REG_SET (i.e. bitmap)
operations.
For now it only handles constant-sized arrays, but I've tried to
define the types in
This patch switches both gcn-plugin and gcn-run to use "coarse-grained"
memory for device-resident data. I've just learned that the "kernargs"
region that we have been using is in fact host-resident.
This means that hsa_memory_copy is no longer optional, and somewhat
complicates the memory set
Hello.
I am using real_isfinite to check for overflow conditions. How should
I check for underflow? I have tried different ways but they
contradicted other cases to pass.
static bool
fold_const_narrow_binary (real_value *result, const real_value *arg0,
int icode, const real_value *ar
This patch makes ior_hard_reg_conflicts take a const_hard_reg_set
rather than a pointer, so that it can be passed a temporary object
in later patches.
2019-09-09 Richard Sandiford
gcc/
* ira-int.h (ior_hard_reg_conflicts): Take a const_hard_reg_set
instead of a HARD_REG_SET *.
Use "x == y" instead of "hard_reg_set_equal_p (x, y)".
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (HARD_REG_SET::operator==): New function.
(HARD_REG_SET::operator!=): Likewise.
(hard_reg_set_equal_p): Delete.
* cfgcleanup.c (old_insns_match_p): Use ==
Use "x |= ~y" instead of "IOR_COMPL_HARD_REG_SET (x, y)", or just
"x | ~y" if the result is a temporary.
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (IOR_COMPL_HARD_REG_SET): Delete.
* config/aarch64/cortex-a57-fma-steering.c (rename_single_chain):
Use "|~" inst
Use "x &= ~y" instead of "AND_COMPL_HARD_REG_SET (x, y)", or just
"x & ~y" if the result is a temporary. This means that we're splitting
it into two operations, but the compiler should be able to combine them
for reasonable values of FIRST_PSEUDO_REGISTER.
2019-09-09 Richard Sandiford
gcc/
Use "x |= y" instead of "IOR_HARD_REG_SET (x, y)" (or just "x | y"
if the result is a temporary).
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (HARD_REG_SET::operator|): New function.
(HARD_REG_SET::operator|=): Likewise.
(IOR_HARD_REG_SET): Delete.
* con
Use "x &= y" instead of "AND_HARD_REG_SET (x, y)" (or just "x & y"
if the result is a temporary).
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (HARD_REG_SET::operator&): New function.
(HARD_REG_SET::operator&): Likewise.
(AND_HARD_REG_SET): Delete.
* call
"COMPL_HARD_REG_SET (x, y)" becomes "x = ~y".
2019-09-09 Richard Sandiford
gcc/
* hard-reg-set.h (HARD_REG_SET::operator~): New function.
(COMPL_HARD_REG_SET): Delete.
* config/c6x/c6x.c (c6x_call_saved_register_used): Use ~ instead
of COMPL_HARD_REG_SET.
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
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
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
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++-
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
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 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 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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 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 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 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
1 - 100 of 173 matches
Mail list logo
