On November 16, 2018 10:23:33 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>The documentation for this function says that it wants to go through
>all
>(integral) conversions (both promotions and demotions), as long as the
>whole sequence of conversions is functionally equivalent to
>(optionally)
>ca
On November 16, 2018 10:10:00 PM GMT+01:00, Jakub Jelinek
wrote:
>Hi!
>
>As mentioned in the PR, the PR78363 changes were done too early, as
>some of
>the BLOCKs are moved to the outlined function, it is undesirable to
>generate
>DW_TAG_lexical_block DIEs for them in a different function from whi
When I was working on some other doc fixes I noticed that there were a
few cases of lines overflowing the right margin in some of the option
summary lists. So when I was fixing that, I noticed some other
formatting inconsistencies, like only one space instead of two
separating options on the s
The mn103 adddi3_degenerate pattern looks something like this:
(define_insn_and_split "*adddi3_degenerate"
[(set (match_operand:SI 0 "register_operand" "=&r,&r")
(match_operand:SI 2 "nonmemory_operand" " 0, 0"))
(set (match_operand:SI 1 "register_operan
We used to preserve deferred access check along with resolved template
ids, but a tentative parsing firewall introduced additional layers of
deferred access checks, so that we don't preserve the checks we
want to any more.
This patch collapses the access check levels introduced by the
firewall wit
This patch is for PR23197, a complaint dating back to 2005 that the
documentation for the options enabled by -fprofile-generate and
-fprofile-use was bit-rotten. Well, it was even more bit-rotten by now.
:-P I updated the docs to reflect the current code in opts.c and
also fixed -fauto-prof
The fix for PR87854 outputs an error when a string literal is too large to
compile.
This patch adds dg-error directives to tests affected by the new error message.
Committed to trunk.
>From 6a00590f762be4267f5d8febb375c3192371de2f Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Sat, 17 N
On 11/16/18 3:53 PM, Ed Smith-Rowland wrote:
On 11/16/18 12:38 PM, Daniel Krügler wrote:
Am Fr., 16. Nov. 2018 um 18:13 Uhr schrieb Ed Smith-Rowland
<3dw...@verizon.net>:
Greetings,
This is late but I wanted to put it out there just to finish a thing.
It's fairly straightforward constexpr of
On 11/16/18 5:32 PM, Michele Pezzutti wrote:
Hi.
My Copyright assignment process is complete (done in Feb 2018).
Michele
On 16/11/2018 18:23, Ed Smith-Rowland wrote:
All,
This patch has been in my queue for a while.
I believe it is waiting on Copyright assignment for Michele. Is this
stil
PR tree-optimization/87025 reports an ICE within
-fsave-optimization-record's optrecord_json_writer.
The issue is that dump_context::begin_scope creates an optinfo
of kind OPTINFO_KIND_SCOPE, but fails to call
dump_context::end_any_optinfo, so the optinfo for the scope remains
pending.
The JSON w
As work towards fixing PR tree-optimization/87025, this patch
eliminates global state from optinfo-emit-json.cc in favor
of adding an optional m_json_writer field to dump_context,
replacing the m_forcibly_enable_optinfo flag.
This allows for writing selftests for the interaction of the
JSON-buildi
On Fri, Nov 16, 2018 at 04:26:18PM -0600, Peter Bergner wrote:
> On 11/16/18 11:06 AM, Segher Boessenkool wrote:
> > On Tue, Nov 13, 2018 at 11:29:20AM -0600, Peter Bergner wrote:
> >> I'll note I didn't change the vsx_mov_32bit pattern, since TImode
> >> isn't supported with -m32. However, if you
On Fri, Nov 16, 2018 at 01:33:58PM -0600, Peter Bergner wrote:
> On 11/16/18 11:06 AM, Segher Boessenkool wrote:
> > "W" is easy_vector_constant, which requires const_vector always; is that
> > okay here?
>
> Well, "wM" calls all_ones_constant which also requires const_vector, so
Does it?
(defin
To encourage and simplify the adoption of iterator classes in
GCC the attached patch turns the function_args_iterator struct
into an (almost) proper C++ iterator class that can be used
the same way as traditional forward iterators.
The patch also replaces all of the 26 uses of the legacy
FOREACH_
Yeah, thanks Jakubnathan-- Nathan Sidwell
Original message From: Jakub Jelinek Date:
11/16/18 15:50 (GMT-05:00) To: Nathan Sidwell , Jason Merrill
Cc: GCC Patches Subject: [PATCH[
Fix pr87269.C testcase On Fri, Nov 16, 2018 at 10:01:05AM -0500, Nathan Sidwell
wrote:> 2018-
Hi!
On Thu, Nov 15, 2018 at 12:44:36PM +, Wilco Dijkstra wrote:
> > On Wed, Nov 14, 2018 at 12:37:05PM +, Wilco Dijkstra wrote:
> >> +/* { dg-final { scan-assembler-not { dup } } } */
> >> +/* { dg-final { scan-assembler-not { fmov } } } */
> >
> > { dup } is the same as " dup " , tha
When binding an object to a template parameter of reference type, we
take the address of the object and dereference that address. The type
of the address may still carry (template) typedefs, but
verify_unstripped_args_1 rejects such typedefs other than in the top
level of template arguments.
We m
Hi.
My Copyright assignment process is complete (done in Feb 2018).
Michele
On 16/11/2018 18:23, Ed Smith-Rowland wrote:
All,
This patch has been in my queue for a while.
I believe it is waiting on Copyright assignment for Michele. Is this
still true?
Ed
When a member template is redeclared as a friend, we enter the context
of the member before looking it up, and then we check that the decls
are compatible. However, when the member template references template
types of the enclosing context, say an enclosing template class, the
compare fails becau
On 11/16/18 11:06 AM, Segher Boessenkool wrote:
> On Tue, Nov 13, 2018 at 11:29:20AM -0600, Peter Bergner wrote:
>> I'll note I didn't change the vsx_mov_32bit pattern, since TImode
>> isn't supported with -m32. However, if you want, I could remove the
>> redundant "*r" <- "jwM" alternative there
Hi!
On Thu, Nov 15, 2018 at 03:54:03PM +, Michael Matz wrote:
> On Wed, 14 Nov 2018, Alexander Monakov wrote:
> > On Wed, 14 Nov 2018, Segher Boessenkool wrote:
> > > Yeah, using local register vars to access global registers only works
> > > by accident. It does work currently though, and pe
On 11/16/18 1:18 PM, Marek Polacek wrote:
On Fri, Nov 16, 2018 at 12:23:42PM +0530, Umesh Kalappa wrote:
Thank you Marek,Appreciate your valuable feedback on the patch .
Attached the latest ,please do let us know your thoughts.
Thanks, this version looks good! Just some small nits:
--- gcc/
Hi Aaron,
On Wed, Nov 14, 2018 at 10:42:44AM -0600, Aaron Sawdey wrote:
> +static rtx
> +emit_vsx_zero_reg()
> +{
> + unsigned int i;
> + rtx zr[16];
> + for (i = 0; i < 16; i++)
> +zr[i] = GEN_INT (0);
> + rtvec zv = gen_rtvec_v (16, zr);
> + rtx zero_reg = gen_reg_rtx (V16QImode);
> +
On 11/16/18 1:15 PM, Peter Bergner wrote:
> This is currently bootstrapping and regtesting on x86_64-linux.
> Ok for mainline assuming the tests show no regressions?
>
> gcc/
> PR rtl-optimization/88033
> * ira-lives.c (non_conflicting_reg_copy_p): Skip copies from a register
> t
Hi!
I admit this is just a shot in the dark, but I don't see why
one couldn't adjust a type of EMPTY_CLASS_EXPR to EMPTY_CLASS_EXPR
with a different variant of the same type.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Or, should I drop that
&& TYPE_MAIN_VARIANT (type)
Hi!
The documentation for this function says that it wants to go through all
(integral) conversions (both promotions and demotions), as long as the
whole sequence of conversions is functionally equivalent to (optionally)
casting the returned value to a signed or unsigned type with the same
precisi
> On Thu, Nov 15, 2018 at 7:14 AM Jan Hubicka wrote:
> >
> > > > A warning seems appropriate. You think the front end is the right
> > > > place for that?
> > >
> > > Probably yes. Note that middle-end can optimize about dead branches and
> > > so that
> > > theoretically one can end up with a b
This patch is backported from druntime 2.083, primarily for beginning
to finish off AArch64 library support, but should apply to any targets
that use 128-bit IEEE long doubles. Bootstrapped and ran D2 testsuite
on x86_64-linux-gnu.
Commited to trunk as r266222.
--
Iain
---
diff --git a/libphobo
Hi!
As mentioned in the PR, the PR78363 changes were done too early, as some of
the BLOCKs are moved to the outlined function, it is undesirable to generate
DW_TAG_lexical_block DIEs for them in a different function from which they
actually end up in.
Those changes for parallel aren't necessary s
On 11/16/18 12:38 PM, Daniel Krügler wrote:
Am Fr., 16. Nov. 2018 um 18:13 Uhr schrieb Ed Smith-Rowland
<3dw...@verizon.net>:
Greetings,
This is late but I wanted to put it out there just to finish a thing.
It's fairly straightforward constexpr of operators and some simple
functions for std::c
On Fri, Nov 16, 2018 at 01:33:58PM -0600, Peter Bergner wrote:
> On 11/16/18 11:06 AM, Segher Boessenkool wrote:
> > Why does the "r" have a "*"? Should it have been just a "?"?
>
> Maybe Mike remembers why he added it? I'd guess it was probably to
> try and steer the vector modes away from GPRs
On Fri, Nov 16, 2018 at 10:01:05AM -0500, Nathan Sidwell wrote:
> 2018-11-16 Nathan Sidwell
>
> PR c++/87269
> * parser.c (lookup_literal_operator): Mark overload for keeping
> when inside template. Refactor.
>
> * g++.dg/lookup/pr87269.C: New.
This test fails on i686
On 11/16/18 11:06 AM, Segher Boessenkool wrote:
> Why does the "r" have a "*"? Should it have been just a "?"?
Maybe Mike remembers why he added it? I'd guess it was probably to
try and steer the vector modes away from GPRs. However, since that
alternative was also suppose to handle TImode, "*"
PR88033 shows a problem when handling simple copies from a register to itself:
(insn (set (reg:DI NNN) (reg:DI NNN)))
This was causing confusion in the code that performs liveness and conflict
updates and program point updates in lra-lives.c. Trying to handle these
types of copies would add so
On Thu, Nov 15, 2018 at 7:14 AM Jan Hubicka wrote:
>
> > > A warning seems appropriate. You think the front end is the right
> > > place for that?
> >
> > Probably yes. Note that middle-end can optimize about dead branches and so
> > that
> > theoretically one can end up with a branching where e
On Fri, Nov 16, 2018 at 11:25:15AM -0700, Martin Sebor wrote:
> On 11/16/2018 01:43 AM, Jakub Jelinek wrote:
> >
> > + /* This matters only for targets where ssizetype has smaller precision
> > + than 32 bits. */
> > + if (wi::lts_p (wi::to_wide (TYPE_MAX_VALUE (ssizetype)), length))
> > +
On 11/16/2018 01:43 AM, Jakub Jelinek wrote:
Hi!
Both C and C++ FE diagnose arrays larger than half of the address space:
/tmp/1.c:1:6: error: size of array ‘a’ is too large
char a[__SIZE_MAX__ / 2 + 1];
^
because one can't do pointer arithmetics on them. But we don't have
anything simil
On 16/11/18 18:19, Pat Haugen wrote:
On 11/8/18 6:10 AM, Kyrill Tkachov wrote:
> The attached patch avoids that by making the alap calculation only
> look at true dependencies. This shouldn't be too bad, since we use
> INSN_PRIORITY as the final tie-breaker than that does take
> anti-dependenc
On 11/8/18 6:10 AM, Kyrill Tkachov wrote:
> The attached patch avoids that by making the alap calculation only
> look at true dependencies. This shouldn't be too bad, since we use
> INSN_PRIORITY as the final tie-breaker than that does take
> anti-dependencies into account.
>
> This reduces the n
On Fri, Nov 16, 2018 at 12:23:42PM +0530, Umesh Kalappa wrote:
> Thank you Marek,Appreciate your valuable feedback on the patch .
>
> Attached the latest ,please do let us know your thoughts.
Thanks, this version looks good! Just some small nits:
--- gcc/cp/parser.c (revision 266026)
+++ gc
On Thu, Nov 15, 2018 at 4:48 PM David Malcolm wrote:
> On Tue, 2018-11-13 at 16:34 -0500, Jason Merrill wrote:
> > On Mon, Nov 12, 2018 at 4:32 PM Martin Sebor
> > wrote:
> > > On 11/11/2018 02:02 PM, David Malcolm wrote:
> > > > On Sun, 2018-11-11 at 11:01 -0700, Martin Sebor wrote:
> > > > > On
Hi all,
This is an alternative to
https://gcc.gnu.org/ml/gcc-patches/2018-11/msg00694.html
As richi suggested, this disables unrolling of loops vectorised with
variable-length SVE
in the vectoriser itself through the loop->unroll member.
It took me a few tries to get it right, as it needs to b
On Fri, 16 Nov 2018, Andrew Stubbs wrote:
> * config.sub: Recognize amdgcn*-*-amdhsa.
config.sub should be copied from upstream config.git (along with
config.guess at the same time), once the support has been added there; it
shouldn't be patched locally in GCC.
--
Joseph S. Myers
jos...
Am Fr., 16. Nov. 2018 um 18:13 Uhr schrieb Ed Smith-Rowland
<3dw...@verizon.net>:
>
> Greetings,
>
> This is late but I wanted to put it out there just to finish a thing.
>
> It's fairly straightforward constexpr of operators and some simple
> functions for std::complex.
>
> The only thing that jum
On Fri, 16 Nov 2018, Jakub Jelinek wrote:
> Hi!
>
> Both C and C++ FE diagnose arrays larger than half of the address space:
> /tmp/1.c:1:6: error: size of array ‘a’ is too large
> char a[__SIZE_MAX__ / 2 + 1];
> ^
> because one can't do pointer arithmetics on them. But we don't have
> an
On 11/16/18 10:21 AM, Kyrill Tkachov wrote:
>
It probably wouldn't be a bad idea to look at the default for
MAX_PENDING_LIST_LENGTH. Based on the current default value and the
comments in the code that value could well have been tuned 25 or more
years ago!
>>> Probably. I see
Just a reminder:
those are the two parts of this patch, which have been posted already
a while ago when we were still in stage 1:
https://gcc.gnu.org/ml/gcc-patches/2018-09/msg00805.html
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01237.html
Bernd.
On 10/20/18 11:16 AM, Bernd Edlinger wro
All,
This patch has been in my queue for a while.
I believe it is waiting on Copyright assignment for Michele. Is this
still true?
Ed
2018-11-16 Michele Pezzutti
Edward Smith-Rowland <3dw...@verizon.net>
PR libstdc++/83566 - cyl_bessel_j returns wrong result for x>1
Hi Jeff,
On 16/11/18 17:08, Jeff Law wrote:
On 11/16/18 5:35 AM, Kyrill Tkachov wrote:
But more importantly, it seems like blindly ignoring anti dependencies
is just a hack that happens to work. I wonder if we could somehow mark
the fake dependencies we add, and avoid bumping the ALAP when we
Greetings,
This is late but I wanted to put it out there just to finish a thing.
It's fairly straightforward constexpr of operators and some simple
functions for std::complex.
The only thing that jumped out was the norm function. We had this:
struct _Norm_helper
{
template
On 11/16/18 5:35 AM, Kyrill Tkachov wrote:
>
>> But more importantly, it seems like blindly ignoring anti dependencies
>> is just a hack that happens to work. I wonder if we could somehow mark
>> the fake dependencies we add, and avoid bumping the ALAP when we
>> encounter those fake dependencies
On Tue, Nov 13, 2018 at 11:29:20AM -0600, Peter Bergner wrote:
> PR87870 shows a problem loading simple constant values into TImode variables.
> This is a regression ever since VSX was added and we started using the
> vsx_mov_64bit pattern. We still get the correct code on trunk if we
> compile wi
Hi Martin,
Seems the change is not checked in yet?
Thanks,
Renlin
On 10/22/2018 01:22 PM, Martin Liška wrote:
On 10/22/18 12:09 PM, Jakub Jelinek wrote:
On Mon, Oct 22, 2018 at 12:04:23PM +0200, Martin Liška wrote:
I noticed that before the tests were run with all of
-std=(c|gnu)++(98|11|14)
Hi,
On Fri, 16 Nov 2018, Alexander Monakov wrote:
> > Not really, it ignores the fact that 'a' can change at any time, which
> > is what happens.
>
> Are you saying that local register variables, in your model, are
> essentially unfit for passing operands to inline asm on specific
> registers
Hello!
There are actually two problems discovered:
a) The insn condition of floatunsdidf2 is incorrect, it allows 32bit
AVX512F targets, but these are not necessarily
KEEP_VECTOR_ALIGNED_STACK targets.
b) movdi_to_sse is defined with extra parallel encapsulation.
Instructions in this form don't
This collection of miscellaneous patches configures the testsuite to run on AMD
GCN in a standalone (i.e. not offloading) configuration. It assumes you have
your Dejagnu set up to run binaries via the gcn-run tool.
2018-11-16 Andrew Stubbs
Kwok Cheung Yeung
Julian Br
[This patch was previously approved by Richard Sandiford (with added
documentation I've still not done), but objected to by Mike Stump. I
need to figure out who's right.]
There are a number of tests that fail because they assume that exceptions are
available, but GCN does not support them, yet.
[Already approved by Jeff Law. Included here for completeness.]
The GCN toolchain must use the LLVM assembler and linker because there's no
binutils port. The LLVM tools do not have the same diagnostic style as
binutils, so the "blank line(s) in output" tests are inappropriate (and very
noisy).
[Already approved by Jeff Law. Included here for completeness.]
The GCN/HSA loader ignores the load address and uses a random location, so we
build all GCN binaries as PIE, by default.
This patch makes the necessary testsuite adjustments to make this work
correctly.
2018-11-16 Andrew Stubbs
This patch contains the configuration adjustments needed to enable the GCN
back-end.
The new configure check for dlopen is required to allow building the new
gcn-run tool. This tool uses libdl to load the HSA runtime libraries, which
are required to run programs on the GPU. The tool is disabled
On Fri, 16 Nov 2018, Michael Matz wrote:
> > This follows both your model
>
> Not really, it ignores the fact that 'a' can change at any time, which is
> what happens.
Are you saying that local register variables, in your model, are essentially
unfit for passing operands to inline asm on specifi
[Already approved by Janne Blomqvist and Jeff Law. Included here for
completeness.]
This patch contains the GCN port of libgfortran. We use the minimal
configuration created for NVPTX. That's all that's required, besides the
target-independent bug fixes posted already.
2018-11-16 Andrew Stub
This patch contains the GCN port of libgcc.
Since the previous posting, I've removed gomp_print.c and reduction.c,
as well as addressing some other feedback.
2018-11-16 Andrew Stubbs
Kwok Cheung Yeung
Julian Brown
Tom de Vries
libgcc/
This patch is unchanged from that which was posted before. Discussion
fizzled out there and I was too busy with other patches to restart it
then. This issue needs to be resolved before libgfortran can be
compiled for GCN.
The IRA pass makes an assumption that any pseudos created after the pass
This is a reworked version of the remaining parts of the patch series I
posted on September 5th. As before, the series contains the
non-OpenACC/OpenMP portions of a port to AMD GCN3 and GCN5 GPU
processors. It's sufficient to build single-threaded programs, with
vectorization in the usual way. C
> On Nov 16, 2018, at 9:51 AM, Jan Hubicka wrote:
>
>> On 11/16/18 2:36 AM, Qing Zhao wrote:
>>> Hi,
>>>
>>> this is the new version of the patch.
>>>
>>> I have bootstrapped it on both aarch64 and x86, no regression.
>>>
>>> please take a look.
>>
>> Thanks for the updated version of the
On Fri, 16 Nov 2018 at 17:16, Matthew Malcomson
wrote:
>
> On 16/11/18 16:04, Jeff Law wrote:
> > On 11/15/18 12:06 PM, Martin Sebor wrote:
> >> On 11/15/2018 02:39 AM, Matthew Malcomson wrote:
> >>> If not we could add an
> >>> { dg-require-effective-target unwrapped }
> >>> directive in the
On 11/14/18 4:05 AM, Jozef Lawrynowicz wrote:
> Use of the patchable_function_entry attribute when the pointer mode is a
> partial int mode can cause a segfault.
> The handler for this attribute tries to write out the assembler directive
> for an integer with bytesize POINTER_SIZE_UNITS, so if this
My earlier patch for 87269 got me thinking and I realized that now we
don't order the non-hidden overload members, we can no longer get into
the situation of needing to mutate non-hidden overload members. We only
prepend. So all the lookup keeping & ovl marking machinery can go away.
It is u
On 11/16/18 9:16 AM, Matthew Malcomson wrote:
> On 16/11/18 16:04, Jeff Law wrote:
>> On 11/15/18 12:06 PM, Martin Sebor wrote:
>>> On 11/15/2018 02:39 AM, Matthew Malcomson wrote:
If not we could add an
{ dg-require-effective-target unwrapped }
directive in the testcases to sto
On 16/11/18 16:04, Jeff Law wrote:
> On 11/15/18 12:06 PM, Martin Sebor wrote:
>> On 11/15/2018 02:39 AM, Matthew Malcomson wrote:
>>> If not we could add an
>>> { dg-require-effective-target unwrapped }
>>> directive in the testcases to stop the failure complaints.
>> I'm not familiar with th
On Mon, Nov 12, 2018 at 11:54:58AM -0700, Jeff Law wrote:
> On 11/12/18 10:52 AM, Andrew Stubbs wrote:
> > If there are two instructions that both have an UNSPEC_VOLATILE, will
> > combine coalesce them into one in the combined pattern?
> I think you can put a different constant on each.
combine (
On 11/15/18 8:06 PM, Martin Sebor wrote:
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01473.html
> (Still looking for an approval.)
>
> On 11/09/2018 04:43 PM, Martin Sebor wrote:
>> On 11/09/2018 12:59 PM, Jeff Law wrote:
>>> On 10/31/18 10:27 AM, Martin Sebor wrote:
Ping: https://g
On 11/15/18 12:06 PM, Martin Sebor wrote:
> On 11/15/2018 02:39 AM, Matthew Malcomson wrote:
>> On 02/11/18 09:54, Christophe Lyon wrote:
>>> Hi,
>>>
>>> I've noticed failure on targets using newlib (aarch64-elf and arm-eabi):
>>> FAIL: gcc.c-torture/execute/printf-2.c
>>> FAIL: gcc.c-torture/execu
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, v6k_thumb, v6z_thumb) as
n
uclibc defines bswap_32, so use a different name in this test.
2018-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.target/arm/pr43698.c
b/g
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.
2018-XX-XX Christophe Lyon
gcc/testsuite/
* g++.dg/cpp0x/noexcept03.C: Add pi
Add *-*-uclinux* to tests that work on this target.
2018-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: Likewise.
* g+
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.
2018-XX-XX Christophe Lyon
gcc/testsuite/
* gcc.target/arm/eliminate.c: Accept only nonpic targets.
* g++.dg/
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-2.c
* Skip since the te
In FDPIC mode, r9 is saved in addition to other registers, so update
the expected patterns accordingly.
2018-XX-XX Christophe Lyon
Mickaël Guêné
* gcc/testsuite/
* gcc.target/arm/interrupt-1.c: Add scan-assembler pattern for
arm*-*-uclinuxfdpiceabi.
* g
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.
2018-XX-XX Christoph
We call __aeabi_read_tp() to get the thread pointer. Since this is a
function call, we have to restore the FDPIC register afterwards.
2018-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (arm_load_tp): Add FDPIC support.
* config/arm/arm.md (load_tp
2018-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_FUNCDESC_OFFSET, ARM_NEW_RT_SI
> On 11/16/18 2:36 AM, Qing Zhao wrote:
> > Hi,
> >
> > this is the new version of the patch.
> >
> > I have bootstrapped it on both aarch64 and x86, no regression.
> >
> > please take a look.
>
> Thanks for the updated version of the patch.
> I have last small nits I see:
>
> - gcc/common.op
Support additional relocations: TLS_GD32_FDPIC, TLS_LDM32_FDPIC, and
TLS_IE32_FDPIC.
We do not support the GNU2 TLS dialect.
2018-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (tls_reloc): Add TLS_GD32_FDPIC,
TLS_LDM32_FDPIC and TLS_IE32_FDPIC.
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 pc, [pc, #8]
Use local binding rules to decide whether we can use GOTOFFFUNCDESC to
compute the function address.
2018-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.c (arm_local_funcdesc_p): New function.
(legitimize_pic_address): Enforce binding rules on functi
2018-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: I0f3b2023ab2a2a0433dfe081dac6bbb194b7a76c
diff --git a/gcc/conf
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 be called by
dereferenc
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.
2018-XX-XX Christophe Lyon
Mickaël Guêné
* libgcc/crtstuff.c: Add support for FDPIC.
diff --git a/libgcc/crtstuff.c b/libgcc/crts
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 address, we have to take into
The new arm-uclinuxfdpiceabi target behaves pretty much like
arm-linux-gnueabi. In order the 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 *-linux*, or uclinux* when
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
appropriate linker emulation.
2018-XX-XX Christophe Lyon
Mickaël Guêné
gcc/
* config/arm/arm.opt: Add -mfdpic option.
* doc/invoke.texi: Add documentation for -mfdpic.
diff --git a/gcc/config/arm/arm.opt b/gcc/config/arm/arm.opt
index a1286a4..231c1cb 100644
--- a/gcc/config/arm/arm.opt
++
From: Christophe Lyon
Hello,
This patch series implements the GCC contribution of the FDPIC ABI for
ARM targets.
This ABI enables to run Linux on ARM MMU-less cores and supports
shared libraries to reduce the memory footprint.
Without MMU, text and data segments relative distances are differen
On 11/16/18 1:49 AM, Jakub Jelinek wrote:
> Hi!
>
> On Wed, Nov 14, 2018 at 09:35:30AM -0700, Jeff Law wrote:
>> +* optabs.c (expand_binop): Pass INT_MODE to operand_subword_force
>> +iff the operand is a constant.
>
> This broke gcc.target/i386/pr80173.c testcase. The problem is
> that
On 11/16/18 6:48 AM, Martin Liška wrote:
> Hi.
>
> As mentioned in the PR, we should guarantee that a function ends before
> it starts (from source line perspective).
>
> For gcc-8 branch, a work-around would be needed.
>
> Survives tests and bootstrap on x86_64-linux-gnu.
> Ready for trunk and
On 11/16/18 2:36 AM, Qing Zhao wrote:
> Hi,
>
> this is the new version of the patch.
>
> I have bootstrapped it on both aarch64 and x86, no regression.
>
> please take a look.
Thanks for the updated version of the patch.
I have last small nits I see:
- gcc/common.opt: when running --help=com
Hi,
On Thu, 15 Nov 2018, Alexander Monakov wrote:
> Reading the documentation certainly does not make that impression to me.
> In any case, can you elaborate a bit further please:
>
> 1. Regarding the comparison to 'volatile' qualifier. Suppose you have an
> automatic variable 'int v;' in a co
1 - 100 of 135 matches
Mail list logo
