Thank you Richard,
Made the required changes ,ok to commit ?
Thank you
~Umesh
On Thu, Nov 15, 2018 at 4:02 PM Richard Biener
wrote:
>
> On Thu, Nov 15, 2018 at 10:02 AM Umesh Kalappa
> wrote:
> >
> > Hi All,
> >
> > The attached patch (pr85667.patch) fixes the subjected issue .
> > we tested
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 similar for string literals. As internally we use
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 while operand_subword handles VOIDmode last argument
Committed.
(dg-additional-options wanted for lto.exp)
Richard.
2018-11-16 Richard Biener
PR testsuite/88053
* g++.dg/lto/pr54625-1_0.c: Add -w.
Index: gcc/testsuite/g++.dg/lto/pr54625-1_0.c
===
---
Hi!
On this testcase on aarch64-linux, we have a bb end like:
(insn 119 80 120 5 (set (reg:DI 110)
(high:DI (label_ref:DI 19))) -1
(insn_list:REG_LABEL_OPERAND 19 (nil)))
(insn 120 119 121 5 (set (reg:DI 109)
(lo_sum:DI (reg:DI 110)
(label_ref:DI 19))) -1
Hello,
The support for constructors/destructors on VxWorks evolves and the
current distinction between RTP vs kernel mode isn't precise enough
any more.
The attached patch, originally contributed by Jerome Lambourg for gcc-7,
introduces a TARGET_VXWORKS_HAVE_CTORS_DTORS internal macro which
On Fri, Nov 16, 2018 at 9:55 AM Jakub Jelinek wrote:
>
> Hi!
>
> On this testcase on aarch64-linux, we have a bb end like:
> (insn 119 80 120 5 (set (reg:DI 110)
> (high:DI (label_ref:DI 19))) -1
> (insn_list:REG_LABEL_OPERAND 19 (nil)))
> (insn 120 119 121 5 (set (reg:DI 109)
>
Hi!
The following two testcases, one is a regression from GCC 8 (introduced by
the constructor to STRING_CST optimization), the other seems to fail since
C++11 support has been introduced (but is accepted by clang++) fail,
because during parsing with processing_template_decl we end up with
Bootstrapped and regtested on s390x-redhat-linux.
Fixes rXsbg_mode_sXl test failures.
Combine used to give us
(set (reg:SI 65)
(ior:SI (lshiftrt:SI (reg:SI 3 %r3 [ bD.2238 ])
(const_int 2 [0x2]))
(reg:SI 2 %r2 [ aD.2237 ])))
but now we get
(set (reg:SI 65)
(ior:SI
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2018-11-16 Richard Biener
PR tree-optimization/88011
* tree-vrp.c (extract_range_from_binary_expr): Fix error in
replacing set_value_range_to_undefined and
set_value_range_to_varying with
Hi,
since the expansion of switches statement into decision trees was moved from
RTL to GIMPLE, the location information of the comparison statements has been
lost, i.e. GIMPLE generates comparison statements with UNKNOWN_LOCATION and
they are expanded as-is into RTL. Now this can be
On Fri, Nov 16, 2018 at 04:21:25PM +0530, Umesh Kalappa wrote:
> My bad ,
> attached the same now .
+2018-11-15 Lokesh Janghel
Two spaces before < instead of just one.
+
+ PR target/85667
Only a single space between PR and target.
+ * i386.c (function_value_ms_64): ms_abi insist
On Fri, Nov 16, 2018 at 4:12 AM Martin Sebor wrote:
>
> Ping: https://gcc.gnu.org/ml/gcc-patches/2018-08/msg01818.html
>
> Please let me know if there is something I need to change here
> to make the fix acceptable or if I should stop trying.
I have one more comment about
+ /* Defer warning
On Fri, Nov 16, 2018 at 9:07 AM Umesh Kalappa wrote:
>
> Thank you Richard,
>
> Made the required changes ,ok to commit ?
Can you attach the adjusted patch?
Thanks,
Richard.
> Thank you
> ~Umesh
> On Thu, Nov 15, 2018 at 4:02 PM Richard Biener
> wrote:
> >
> > On Thu, Nov 15, 2018 at 10:02 AM
Hi Mike,
Thanks for the changes.
On Thu, Nov 08, 2018 at 04:28:52PM -0500, Michael Meissner wrote:
> * config/rs6000/constraints.md (wF constraint): Update constraint
> documentation for power8 fusion only.
"so it is for ...", maybe? It is hard to understand your sentence.
> +
Hi all,
Tejas noticed that libstdc++.exp currently builds nlocale driver
(libstc++.exp:check_v3_target_namedlocale())
once for a test run. This is done irrespective of the number of variants in the
site.exp file.
For eg. if we have more than one variant for different target profiles i.e.
My bad ,
attached the same now .
~Umesh
On Fri, Nov 16, 2018 at 2:38 PM Richard Biener
wrote:
>
> On Fri, Nov 16, 2018 at 9:07 AM Umesh Kalappa
> wrote:
> >
> > Thank you Richard,
> >
> > Made the required changes ,ok to commit ?
>
> Can you attach the adjusted patch?
>
> Thanks,
> Richard.
>
On 16.11.18 11:15, Ilya Leoshkevich wrote:
> Bootstrapped and regtested on s390x-redhat-linux.
>
> Fixes rXsbg_mode_sXl test failures.
>
> Combine used to give us
>
> (set (reg:SI 65)
> (ior:SI (lshiftrt:SI (reg:SI 3 %r3 [ bD.2238 ])
> (const_int 2 [0x2]))
> (reg:SI 2
On 16/11/18 10:42 +, Renlin Li wrote:
Hi all,
Please remember that all patches for libstdc++ must be sent to the
libstdc++ list, as documented at https://gcc.gnu.org/lists.html
Just CCing me is not enough.
Tejas noticed that libstdc++.exp currently builds nlocale driver
On 11/15/18 9:54 PM, Jakub Jelinek wrote:
> On Thu, Nov 15, 2018 at 08:40:13PM +0100, Bernhard Reutner-Fischer wrote:
>> On 14 November 2018 12:35:27 CET, Jakub Jelinek wrote:
>>
--- a/gcc/config/gnu-user.h
+++ b/gcc/config/gnu-user.h
@@ -170,3 +170,6 @@ see the files COPYING3 and
Hello,
Have a nice day.
Do you company need a packaging boxes supplier in China?
We custom the packaging boxes for you products with custom logo.
Any of you reply will be appreciated.
Lookng forward to your reply
Best regards,
Slite
-
SLC IMPORT CO.LTD
Web:
The guideline I would give to determine if you're vulnerable... Do you
have speculation, including the ability to speculate past a memory
operation, branch prediction, memory caches and high resolution timer
(ie, like a cycle timer). If you've got those, then the processor is
likely vulnerable
On 11/16/18 7:08 AM, Indu Bhagat wrote:
>
> On 11/12/2018 01:48 AM, Martin Liška wrote:
>>> make check-gcc on x86_64 shows no new failures.
>>>
>>> (A related PR washttps://gcc.gnu.org/bugzilla/show_bug.cgi?id=86957 where
>>> we added diagnostics for the NO PROFILE case.)
>> Hi.
>>
>> Thanks
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 gcc-8 branch?
Thanks,
Martin
gcc/ChangeLog:
2018-11-16
On Fri, Nov 16, 2018 at 02:24:42PM +0100, Martin Liška wrote:
> + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES)
> +return MATCH_ERROR;
> +
> + int builtin_kind = 0;
> + if (gfc_match (" (notinbranch)") == MATCH_YES)
I think you need " ( notinbranch )" here.
> +
On Fri, Nov 16, 2018 at 11:45 AM Eric Botcazou wrote:
>
> Hi,
>
> since the expansion of switches statement into decision trees was moved from
> RTL to GIMPLE, the location information of the comparison statements has been
> lost, i.e. GIMPLE generates comparison statements with UNKNOWN_LOCATION
Hi Jeff,
On 10/11/18 00:04, Jeff Law wrote:
On 11/8/18 5:10 AM, Kyrill Tkachov wrote:
This patch fixes a flaw in the relationship between the way that
SCHED_PRESSURE_MODEL calculates the alap and depth vs how it uses
them in model_order_p. A comment in model_order_p says:
/* Combine the
On 11/16/18 3: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
Hi.
This is fix for the PR which we cooked with Honza.
He pre-approved that.
Survives regression tests and bootstrap on x86_64-linux-gnu.
I'm going to install it.
Martin
gcc/lto/ChangeLog:
2018-11-16 Martin Liska
PR lto/88004
* lto-symtab.c (lto_symtab_merge_symbols_1): Do
On Sat, Nov 10, 2018 at 11:36:28AM -0600, Kelvin Nilsen wrote:
> This new pass scans existing rtl expressions and replaces them with rtl
> expressions that favor selection of the D-form instructions in contexts for
> which the D-form instructions are preferred.
(Here would be a good place to
On Fri, Nov 16, 2018 at 07:06:51AM -0500, Nathan Sidwell wrote:
> On 11/16/18 3: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];
> >
On 11/16/2018 01:20 PM, Jonathan Wakely wrote:
On 16/11/18 10:42 +, Renlin Li wrote:
Hi all,
Please remember that all patches for libstdc++ must be sent to the
libstdc++ list, as documented at https://gcc.gnu.org/lists.html
Just CCing me is not enough.
Hi Jonathan,
I knew I missed
On 11/16/18 2:49 PM, Jakub Jelinek wrote:
> On Fri, Nov 16, 2018 at 02:24:42PM +0100, Martin Liška wrote:
>> + if (gfc_match (" (%n) attributes simd", builtin) != MATCH_YES)
>> +return MATCH_ERROR;
>> +
>> + int builtin_kind = 0;
>> + if (gfc_match (" (notinbranch)") == MATCH_YES)
>
> I
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
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
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.
*
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.
*
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
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
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
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
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
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
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.
*
This was a case of not marking the overloads of a lookup as immutable,
leading to an assert failure.
Applying to trunk.
nathan
--
Nathan Sidwell
2018-11-16 Nathan Sidwell
PR c++/87269
* parser.c (lookup_literal_operator): Mark overload for keeping
when inside template. Refactor.
*
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
> 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
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
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
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
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*
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
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.
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:
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
[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
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
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
[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).
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
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
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
>
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))
> > +
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
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
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
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
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.
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
[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
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
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
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:
> > > > >
Ping?
Best regards,
Thomas
On Sat, 10 Nov 2018 at 15:07, Thomas Preudhomme
wrote:
>
> Thanks Kyrill.
>
> Updated patch in attachment. Best regards,
>
> Thomas
> On Thu, 8 Nov 2018 at 15:53, Kyrill Tkachov
> wrote:
> >
> > Hi Thomas,
> >
> > On 08/11/18 09:52, Thomas Preudhomme wrote:
> > >
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
> 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:
>
> -
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
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,
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]
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
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:
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
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)
+++
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
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);
> +
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
> 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
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:
---
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
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
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
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 " ,
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
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
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
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
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,
1 - 100 of 135 matches
Mail list logo
