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 o
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 h
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 j
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
(ins
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 creatin
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 (an
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
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 allow
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)
>
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
===
--- gcc/testsui
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.
> +/
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 metho
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.
/
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 problemat
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 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 a
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 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 %r2
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 simila
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
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 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
(libstc++.exp:che
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 C
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&EXPORT CO.LTD
Web:
h
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 t
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 for
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 M
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.
> +builtin_
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 say
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 so
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:
> > > Pi
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.
* g++
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 thi
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
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
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 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
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
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
++
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.
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
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, 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 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
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
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
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]
> 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.
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
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
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
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
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+
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
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
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
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 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 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 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
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/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
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 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
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
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 Stub
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
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
[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
[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).
[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.
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
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
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
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)
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
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
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
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
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
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
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
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
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, 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...
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 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
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 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 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/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 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))
> > +
1 - 100 of 135 matches
Mail list logo
