Copy code example for fetch and nand from "Legacy __sync Built-in
Functions for Atomic Memory Access" to "Built-in Functions for Memory
Model Aware Atomic Operations".
gcc/
* doc/extend.texi (Built-in Functions for Memory Model Aware
Atomic Operations): Document atomic fetch and n
On Fri, Jul 20, 2018 at 3:57 AM Richard Sandiford
wrote:
>
> We could vectorise:
>
> for (...)
>{
> a[0] = ...;
> a[1] = ...;
> a[2] = ...;
> a[3] = ...;
> a += stride;
>}
>
> (including the case when stride == 8) but not:
>
>
Hi,
Const int is handled differently at -O0 for -xc and -xc++, which can cause noise
in testsuite/libgomp.oacc-c-c++-common test-cases (which are both run for c and
c++) if const int is used for launch dimensions.
Fix this by using #defines instead.
Committed to trunk.
Thanks,
- Tom
[libgomp,
Hi,
When using a compiler build with:
...
+#define PTX_DEFAULT_VECTOR_LENGTH PTX_CTA_SIZE
+#define PTX_MAX_VECTOR_LENGTH PTX_CTA_SIZE
...
and running the libgomp testsuite, we run into an execution failure in
parallel-loop-1.c, due to a cuda launch failure:
...
nvptx_exec: kernel f6_none_none$_o
This patch by Cherry Zhang fixes the Go frontend to use the int type
for the len & cap arguments to a slice value. Bootstrapped and ran
Go testsuite on x86_64-pc-linux-gnu. Committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
> On Jan 8, 2019, at 11:53 AM, Jan Hubicka wrote:
>
>>>
>>> In general this parameter affects primarily -O3 builds, becuase -O2
>>> hardly hits the limit. From -O3 only programs with very large units are
>>> affected (-O2 units hits the limit only if you do have a lot of inline
>>> hints in th
I got confused and opened this PR thinking we've got another problem here.
Turns out things work as expected with the recent patch of mine. Well, at
least we have another testcase.
Bootstrapped/regtested on x86_64-linux, applying to trunk.
2019-01-08 Marek Polacek
PR c++/88744
On Mon, 2019-01-07 at 17:38 +, Richard Sandiford wrote:
>
> Yeah, this was the kind of thing I had in mind, thanks.
Here is an updated version of the patch. I bootstrapped and tested
on aarch64 and x86. I didn't test the other platforms where I changed
the arguments to hard_regno_call_part_
Hi Paul,
This is an updated version of the earlier patch. The main addition is
a second testcase that checks the errors emitted by the CFI API
functions.
I notice that the header file ISO_Fortran_binding.h is found twice
in the patch.
Is there any particular reason why you do not want to use
Test that StdUniquePtrPrinter correctly prints std::unique_ptr objects
using the old layout, prior to the PR libstdc++/77990 changes.
The printer test for a valueless std::variant started to fail because
the PR libstdc++/87431 fix meant it no longer became valueless. Change
the test to use a type
Hello world,
the attached patch fixes the PR by simpliy having gfc_simplify_spread
also do its job when there's an EXPR_STRUCTURE. The code to correctly
handle that case was already in place, it just was not run for that
case.
Regression-tested. OK for trunk?
Regards
Thomas
! { dg-do
When the contained value is not trivially copy (or move) constructible
the union's copy (or move) constructor will be deleted, and so the
_Optional_payload delegating constructors are invalid. G++ fails to
diagnose this because it incorrectly performs copy elision in the
delegating constructors. C
On 14-12-18 20:58, Tom de Vries wrote:
> 0016-nvptx-Add-vector_length-128-testcases.patch
> --- /dev/null
>
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/vred2d-128.c
>
Sorry, wrong list, meant to send to g...@gcc.gnu.org
--
Thanks.
-- Max
Hi!
The following patch attempts to fix one of the several issues with
the r266345 commit. assign_stack_local isn't called just during expansion,
but also during RA, at which point we can't just randomly emit insns in the
middle of nowhere hoping it will be emitted in some insn sequence.
This pa
Hello,
I'm implementing MI thunk generation for the xtensa target and I've got
an issue that when my code generates a constant it is missing in the
resulting assembly. This happens because a constant pool output happens
inside the assemble_start_function, which is called before the thunk
function
Hi!
As mentioned in the PR, if a VECTOR_CST is not VECTOR_CST_STEPPED_P,
it is sufficient to recurse just on all the encoded elt, because if
the vector has more elts than encoded, all the remaining ones are equal to
the last one.
But, if it is stepped, there is the possibility that while the penul
On Tue, Jan 08, 2019 at 03:45:54PM -0500, Jason Merrill wrote:
> On 1/8/19 10:42 AM, Marek Polacek wrote:
> > @@ -17020,6 +17020,18 @@ cp_parser_template_argument (cp_parser* parser)
> > argument = cp_parser_constant_expression (parser);
> > else
> > {
> > + /* In C++20, we can
Add a test case to check whether -masm-syntax-unified is indeed
emitting the inline assembler with .syntax unified.
gcc/testsuite/ChangeLog
* gcc.target/arm/pr88648-asm-syntax-unified.c: add test to
check if -masm-syntax-unified gets applied properly
---
.../gcc.target/a
On 08.01.2019 10:35, Kyrill Tkachov wrote:
> Hi Stefan,
>
> On 02/01/19 21:47, Stefan Agner wrote:
>> Add a test case to check whether -masm-syntax-unified is indeed
>> emitting the inline assembler with .syntax unified.
>
> Can you please provide a ChangeLog entry for this change.
>
>> ---
>>
On Tue, Jan 08, 2019 at 09:39:21PM +0100, Jakub Jelinek wrote:
> Hi!
>
> I've noticed this testcase FAILs, there are many reasons for that:
> 1) hardcoded use of -m32, which isn't really available on powerpc64le
> 2) -c in dg-options
> 3) use of target_clones attribute without ppc_cpu_supports_hw
On Tue, Jan 08, 2019 at 09:34:31PM +0100, Jakub Jelinek wrote:
> My recent changes to UNSPEC handling in dwarf2out.c apparently broke
> (non-release checking) regtest on powerpc*, a lot of
> note: non-delegitimized UNSPEC UNSPEC_FUSION_GPR (73) found in variable
> location
> messages are emitted w
Hi Steve,
Well, that was quick. Moving code around is problematic.
Thanks for checking. The patch is OK for trunk.
Regards
Thomas
[...]
2019-01-08 Marc Nieper-Wißkirchen
* docs/topics/compatibility.rst: Add LIBGCCJIT_ABI_11.
* docs/topics/expressions.rst (Global variables): Add
documentation of gcc_jit_lvalue_set_bool_thread_local.
* docs/_build/texinfo/libgccjit.texi: Regenerate.
On 12/31/18 4:23 PM, Joseph Myers wrote:
On Fri, 28 Dec 2018, Sandra Loosemore wrote:
Taken individually, all these changes probably qualify as obvious, but given
how extensive they are and how many files are touched, I thought it would be
good to get a sanity check on methodology before checki
On 12/28/18 2:45 PM, Alexandre Oliva wrote:
dwarf2out recognizes unspecified auto types by the identifier. C++
template class placeholders are unspecified auto types that take the
identifier of the class rather than those used by preexisting auto
types, so dwarf2out ICEs when it finds one of th
On 1/8/19 8:13 AM, Paolo Carlini wrote:
Hi,
a few additional easy to fix cases where we thought that a plain error
was good enough. Tested x86_64-linux.
Thanks, Paolo.
OK.
On 1/8/19 10:42 AM, Marek Polacek wrote:
On Mon, Jan 07, 2019 at 09:52:55PM -0500, Jason Merrill wrote:
On 1/7/19 6:56 PM, Marek Polacek wrote:
At the risk of seeming overly eager, I thought it would be reasonable to
go with the following: enabling braced-init-list as a template-argument.
As th
Hi!
I've noticed this testcase FAILs, there are many reasons for that:
1) hardcoded use of -m32, which isn't really available on powerpc64le
2) -c in dg-options
3) use of target_clones attribute without ppc_cpu_supports_hw effective
target
Also, there is no need to use both -mcpu=power7 -mcpu=e
Hi!
My recent changes to UNSPEC handling in dwarf2out.c apparently broke
(non-release checking) regtest on powerpc*, a lot of
note: non-delegitimized UNSPEC UNSPEC_FUSION_GPR (73) found in variable location
messages are emitted while compiling pretty much anything with -mcpu=power8
or later.
The
Am Di., 8. Jan. 2019 um 16:28 Uhr schrieb Steve Kargl
:
>
> On Tue, Jan 08, 2019 at 10:11:33AM +0100, Janus Weil wrote:
> >
> > the attached patch is close to obvious and fixes another small
> > ICE-on-invalid regression. Since there was a bit of discussion in the
> > PR, I am submitting it for app
Although they are already fixed, the first one because it didn't fail for me
and the second one thanks to Jakub's patch.
Tested on SPARC/Solaris 11, applied on the mainline.
2019-01-08 Eric Botcazou
PR bootstrap/88721
* config/sparc/sparc.c (function_arg_slotno): Set *PPREGN
> >
> > In general this parameter affects primarily -O3 builds, becuase -O2
> > hardly hits the limit. From -O3 only programs with very large units are
> > affected (-O2 units hits the limit only if you do have a lot of inline
> > hints in the code).
> don’t quite understand here, what’s the major
Hi Maciej!
On Mon, 3 Dec 2018 16:51:14 +, "Maciej W. Rozycki"
wrote:
> Add generic support for the OpenACC 2.6 `acc_get_property' and
> `acc_get_property_string' routines, as well as full handlers for the
> host and the NVPTX offload targets and a minimal handler for the HSA
> offload tar
On Tue, Jan 8, 2019 at 12:43 PM Jakub Jelinek wrote:
>
> On Tue, Jan 08, 2019 at 11:49:10AM +0100, Uros Bizjak wrote:
> > FLD from memory in SF and DFmode is considered a conversion, and
> > converts sNaN to NaN (and emits #IA exception). But sNaN handling is
> > already busted in the compiler as
On Tue, Jan 8, 2019 at 9:29 AM Uros Bizjak wrote:
>
> On Tue, Jan 8, 2019 at 5:17 PM H.J. Lu wrote:
> >
> > On Tue, Jan 8, 2019 at 6:54 AM Uros Bizjak wrote:
> > >
> > > On Tue, Jan 8, 2019 at 3:39 PM H.J. Lu wrote:
> > > >
> > > > On Mon, Jan 7, 2019 at 11:12 PM Uros Bizjak wrote:
> > > > >
>
On Tue, Jan 8, 2019 at 5:17 PM H.J. Lu wrote:
>
> On Tue, Jan 8, 2019 at 6:54 AM Uros Bizjak wrote:
> >
> > On Tue, Jan 8, 2019 at 3:39 PM H.J. Lu wrote:
> > >
> > > On Mon, Jan 7, 2019 at 11:12 PM Uros Bizjak wrote:
> > > >
> > > > On Mon, Jan 7, 2019 at 6:40 PM H.J. Lu wrote:
> > > > >
> > >
On Tue, 2019-01-08 at 14:31 +0100, Marc Nieper-Wißkirchen wrote:
> Dear David,
>
> thank you very much for your timely response and for talking a
> thorough
> look at my proposed patch.
>
> Am 07.01.19 um 21:34 schrieb David Malcolm:
>
> > Have you done the legal paperwork with the FSF for cont
> On Jan 8, 2019, at 5:46 AM, Jan Hubicka wrote:
>
>>> I plan to commit the patch tomorrow after re-testing everything after
>>> the bugfixes from today and yesterday. In addition to this have found
>>> that current inline-unit-growth is too small for LTO of large programs
>>> (especially Fire
Hi Alejandro,
+emit_move_insn (mask,
+ aarch64_simd_gen_const_vector_dup (mode,
+ HOST_WIDE_INT_M1U
+ << bits));
+
+emit_insn (gen_and3 (sign, arg2, mask));
Is there
Hi,
This patch adds support for copysign and xorsign builtins to SVE. With the new
expands, they can be vectorized using bitwise logical operations.
I tested this patch in an aarch64 machine bootstrapping the compiler and
running the checks.
Alejandro
gcc/Changelog:
2019-01-08 Alejandro Marti
On Tue, Jan 8, 2019 at 6:54 AM Uros Bizjak wrote:
>
> On Tue, Jan 8, 2019 at 3:39 PM H.J. Lu wrote:
> >
> > On Mon, Jan 7, 2019 at 11:12 PM Uros Bizjak wrote:
> > >
> > > On Mon, Jan 7, 2019 at 6:40 PM H.J. Lu wrote:
> > > >
> > > > There is no need to generate vzeroupper if caller uses upper b
On Mon, Jan 07, 2019 at 09:52:55PM -0500, Jason Merrill wrote:
> On 1/7/19 6:56 PM, Marek Polacek wrote:
> > At the risk of seeming overly eager, I thought it would be reasonable to
> > go with the following: enabling braced-init-list as a template-argument.
> > As the discussion on the reflector c
On Tue, Jan 08, 2019 at 10:11:33AM +0100, Janus Weil wrote:
>
> the attached patch is close to obvious and fixes another small
> ICE-on-invalid regression. Since there was a bit of discussion in the
> PR, I am submitting it for approval instead of just committing as
> obvious.
>
> Regtests cleanl
On 07/01/2019 22:50, Jeff Law wrote:
On 1/7/19 7:42 AM, Andre Vieira (lists) wrote:
Hi,
This patch fixes the way 'uses_hard_regs_p' handles paradoxical subregs.
The function is supposed to detect whether a register access of 'x'
overlaps with 'set'. For SUBREGs it should check whether any
On Tue, Jan 8, 2019 at 3:39 PM H.J. Lu wrote:
>
> On Mon, Jan 7, 2019 at 11:12 PM Uros Bizjak wrote:
> >
> > On Mon, Jan 7, 2019 at 6:40 PM H.J. Lu wrote:
> > >
> > > There is no need to generate vzeroupper if caller uses upper bits of
> > > AVX/AVX512 registers, We track caller's avx_u128_stat
On 1/8/19 2:57 PM, Martin Liška wrote:
> I'll re-run the bootstrap with the hunk.
Bootstraps®tests, thus I'm going to install it.
Martin
On Mon, Jan 7, 2019 at 11:12 PM Uros Bizjak wrote:
>
> On Mon, Jan 7, 2019 at 6:40 PM H.J. Lu wrote:
> >
> > There is no need to generate vzeroupper if caller uses upper bits of
> > AVX/AVX512 registers, We track caller's avx_u128_state and avoid
> > vzeroupper when caller's avx_u128_state is AV
On 1/8/19 3:14 PM, Jakub Jelinek wrote:
> On Tue, Jan 08, 2019 at 02:56:44PM +0100, Martin Liška wrote:
>> --- a/gcc/tree-switch-conversion.c
>> +++ b/gcc/tree-switch-conversion.c
>> @@ -100,6 +100,7 @@ switch_conversion::collect (gswitch *swtch)
>>max_case = gimple_switch_label (swtch, branch_
On Tue, Jan 08, 2019 at 02:56:44PM +0100, Martin Liška wrote:
> --- a/gcc/tree-switch-conversion.c
> +++ b/gcc/tree-switch-conversion.c
> @@ -100,6 +100,7 @@ switch_conversion::collect (gswitch *swtch)
>max_case = gimple_switch_label (swtch, branch_num - 1);
>
>m_range_min = CASE_LOW (min
On 2019/1/7 10:15 AM, Thomas Schwinge wrote:
Well, the "Properly handle wait clause with no arguments" changes still
need to be completed and go in first (to avoid introducing regressions),
and then I will have to see your whole set of changes that you intend to
commit: the bits you've incrementa
Hi Marc,
> >>> + (nop:type (op (convert:ty1 @1) (convert:ty2 @2)
> >>
> >> Please don't use 'nop' directly, use 'convert' instead. This line is very
> >> suspicious, both arguments of op should have the same type. Specifying the
> >> outertype should be unnecessary, it is always 'type'. An
On 1/8/19 2:50 PM, Jakub Jelinek wrote:
> On Tue, Jan 08, 2019 at 02:09:28PM +0100, Martin Liška wrote:
>> Changed that. I verified that tree-ssa.exp tests work fine. May I install
>> the hunk you suggested
>> without testing?
>
> I think better would be commit without that hunk and when you boot
On 1/8/19 2:08 PM, Jakub Jelinek wrote:
> On Tue, Jan 08, 2019 at 01:52:35PM +0100, Jakub Jelinek wrote:
>>> 2019-01-08 Martin Liska
>>>
>>> PR tree-optimization/88753
>>> * tree-switch-conversion.c (switch_conversion::build_one_array):
>>> Come up with local variable constructor. C
On Tue, Jan 08, 2019 at 02:09:28PM +0100, Martin Liška wrote:
> Changed that. I verified that tree-ssa.exp tests work fine. May I install the
> hunk you suggested
> without testing?
I think better would be commit without that hunk and when you bootstrap next
time, test that and commit (preapprove
On Tue, Jan 08, 2019 at 01:30:45PM +, Julian Brown wrote:
> commit 2ee3f8d09a7b2af6c9ba29cdd8e8587db1946c0b
> Author: Julian Brown
> Date: Wed Dec 19 05:01:58 2018 -0800
>
> Add testcase from PR71959
>
> libgomp/
>
> PR lto/71959
> * testsuite/libgomp.oacc-c+
On Tue, Jan 08, 2019 at 02:28:35PM +0100, Sebastian Huber wrote:
> libgomp/
>
> * config/rtems/bar.c: Include "../linux/bar.c" and delete copy
> and paste code.
> libgomp/config/rtems/bar.c | 183
> +
> 1 file changed, 2 insertions(+), 181
On Tue, Jan 08, 2019 at 02:28:34PM +0100, Sebastian Huber wrote:
> libgomp/
>
> * config/rtems/affinity-fmt.c: New file. Include affinity-fmt.c,
> undefining HAVE_GETPID and HAVE_GETHOSTNAME, and mapping fwrite to
> write.
Ok for trunk, thanks.
Jakub
Dear David,
thank you very much for your timely response and for talking a thorough
look at my proposed patch.
Am 07.01.19 um 21:34 schrieb David Malcolm:
Have you done the legal paperwork with the FSF for contributing to GCC?
See https://gcc.gnu.org/contribute.html#legal
Not yet; this i
On Sat, 22 Dec 2018 15:09:34 +
Iain Sandoe wrote:
> Hi Julian,
>
> > On 21 Dec 2018, at 16:47, Julian Brown
> > wrote:
>
> > On Fri, 21 Dec 2018 14:31:19 +0100
> > Jakub Jelinek wrote:
> >
> >> On Fri, Dec 21, 2018 at 01:23:03PM +, Julian Brown wrote:
> >>> 2018-xx-yy Nathan Si
libgomp/
* config/rtems/bar.c: Include "../linux/bar.c" and delete copy
and paste code.
---
libgomp/config/rtems/bar.c | 183 +
1 file changed, 2 insertions(+), 181 deletions(-)
diff --git a/libgomp/config/rtems/bar.c b/libgomp/config/r
libgomp/
* config/rtems/affinity-fmt.c: New file. Include affinity-fmt.c,
undefining HAVE_GETPID and HAVE_GETHOSTNAME, and mapping fwrite to
write.
---
libgomp/config/rtems/affinity-fmt.c | 49 +
1 file changed, 49 insertions(+)
create
Hi,
a few additional easy to fix cases where we thought that a plain error
was good enough. Tested x86_64-linux.
Thanks, Paolo.
/cp
2019-01-08 Paolo Carlini
* decl.c (grok_reference_init): Improve error location.
(grokdeclarator): Likewise, improve tw
On 1/8/19 1:52 PM, Jakub Jelinek wrote:
> On Tue, Jan 08, 2019 at 01:40:41PM +0100, Martin Liška wrote:
>> As seen in the PR, when doing switch convert linear transformation,
>> one needs to first convert to unsigned type for constructor values.
>>
>> Patch survives regression tests and bootstrap o
On Tue, Jan 08, 2019 at 01:52:35PM +0100, Jakub Jelinek wrote:
> > 2019-01-08 Martin Liska
> >
> > PR tree-optimization/88753
> > * tree-switch-conversion.c (switch_conversion::build_one_array):
> > Come up with local variable constructor. Convert first to
> > type of construct
The following fixes PR88739, VN figuring equivalences that later
lead to code insertions for code hoisting using a possibly overflowing
computation that wasn't done unconditionally before.
It is now possible to verify this with the new VN scheme. Still
a more complete fix is pending (there's a
On Tue, Jan 08, 2019 at 01:40:41PM +0100, Martin Liška wrote:
> As seen in the PR, when doing switch convert linear transformation,
> one needs to first convert to unsigned type for constructor values.
>
> Patch survives regression tests and bootstrap on x86_64-linux-gnu.
> Ready for trunk?
> Than
Hi.
As seen in the PR, when doing switch convert linear transformation,
one needs to first convert to unsigned type for constructor values.
Patch survives regression tests and bootstrap on x86_64-linux-gnu.
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2019-01-08 Martin Liska
PR t
Hi Wuyuan,
Thanks for pinging.
Some comments inline
On 08/01/19 11:23, wuyuan (E) wrote:
Hi , Maintainers
I submitted a tsv110 pipeline patch on the 20th of last month , Have
you reviewed the patch?look forward to your reply.
Best Regards,
Wuyuan
2019-1-8 wuyuan
Pleas
Hi Jonathan,
> On 06/01/19 17:59 +0100, Rainer Orth wrote:
>>Hi Jonathan,
>>
>>> The C++17 standard added some new members to std::basic_string, which
>>> were not previously instantiated in the library. This meant that the
>>> extern template declarations had to be disabled for C++17 mode. With
>
Bernd Edlinger writes:
> On 1/7/19 10:23 AM, Jakub Jelinek wrote:
>> On Sun, Dec 16, 2018 at 06:13:57PM +0200, Dimitar Dimitrov wrote:
>>> - /* Clobbering the STACK POINTER register is an error. */
>>> + /* Clobbered STACK POINTER register is not saved/restored by GCC,
>>> + which is often
Hi,
On 08/01/19 11:24, Christophe Lyon wrote:
On Mon, 7 Jan 2019 at 18:08, Paolo Carlini wrote:
Hi,
should be straightforward material. Tested x86_64-linux, as usual.
Thanks, Paolo.
/
Hi,
The new g++.dg/diagnostic/thread1.C passes on aarch64, but fails on arm:
FAIL: g
> > I plan to commit the patch tomorrow after re-testing everything after
> > the bugfixes from today and yesterday. In addition to this have found
> > that current inline-unit-growth is too small for LTO of large programs
> > (especially Firefox:) and there are important improvements when
> > inc
On Tue, Jan 08, 2019 at 11:49:10AM +0100, Uros Bizjak wrote:
> FLD from memory in SF and DFmode is considered a conversion, and
> converts sNaN to NaN (and emits #IA exception). But sNaN handling is
> already busted in the compiler as RA is free to spill the register in
> non-XFmode. IMO, the peeph
On 1/7/19 6:28 PM, James Greenhalgh wrote:
> On Fri, Dec 21, 2018 at 09:00:10AM -0600, Sam Tebbs wrote:
>> On 11/9/18 11:04 AM, Sam Tebbs wrote:
>
>
>
>> Attached is an improved patch with "hint" removed from the test scans,
>> pauth_hint_num_a and pauth_hint_num_b merged into pauth_hint_num a
Hi , Maintainers
I submitted a tsv110 pipeline patch on the 20th of last month , Have
you reviewed the patch?look forward to your reply.
On Tue, Jan 8, 2019 at 10:27 AM Jakub Jelinek wrote:
>
> On Tue, Jan 08, 2019 at 08:29:03AM +0100, Uros Bizjak wrote:
> > Is there a reason stack registers are excluded? Before stackreg pass,
> > these registers are just like other hard registers.
>
> I was just afraid of those, after stack pass r
Hi!
I've backported the following patches, bootstrapped/regtested on
x86_64-linux and i686-linux and committed to gcc-8-branch.
Jakub
2019-01-08 Jakub Jelinek
Backported from mainline
2018-11-13 Jakub Jelinek
PR tree-optimization/87898
* omp-simd-cl
On 1/7/19 6:11 PM, James Greenhalgh wrote:
> On Thu, Dec 20, 2018 at 10:38:42AM -0600, Sam Tebbs wrote:
>> On 11/22/18 4:54 PM, Sam Tebbs wrote:
>
>
>> Hi all,
>>
>> Attached is an updated patch with branch_protec_type renamed to
>> branch_protect_type, some unneeded ATTRIBUTE_USED removed and an
On Mon, 7 Jan 2019 at 18:08, Paolo Carlini wrote:
>
> Hi,
>
> should be straightforward material. Tested x86_64-linux, as usual.
>
> Thanks, Paolo.
>
> /
>
Hi,
The new g++.dg/diagnostic/thread1.C passes on aarch64, but fails on arm:
FAIL: g++.dg/diagnostic/thread1.C -std=c++
On Mon, 7 Jan 2019 at 15:14, Christophe Lyon wrote:
>
> On Mon, 7 Jan 2019 at 13:39, Jonathan Wakely wrote:
> >
> > On 07/01/19 09:48 +, Jonathan Wakely wrote:
> > >On 07/01/19 10:24 +0100, Christophe Lyon wrote:
> > >>Hi Jonathan
> > >>
> > >>On Sun, 6 Jan 2019 at 23:37, Jonathan Wakely wro
On 08/01/19 09:33, Kyrill Tkachov wrote:
Hi Stefan,
On 01/01/19 23:34, Stefan Agner wrote:
> This allows to use unified asm syntax when compiling for the
> ARM instruction. This matches documentation and seems what the
> initial patch was intended doing when the flag got added.
> ---
> gcc/co
Hi Stefan,
On 02/01/19 21:47, Stefan Agner wrote:
Add a test case to check whether -masm-syntax-unified is indeed
emitting the inline assembler with .syntax unified.
Can you please provide a ChangeLog entry for this change.
---
.../gcc.target/arm/pr88648-asm-syntax-unified.c| 14 +++
Hi Stefan,
On 01/01/19 23:34, Stefan Agner wrote:
This allows to use unified asm syntax when compiling for the
ARM instruction. This matches documentation and seems what the
initial patch was intended doing when the flag got added.
---
gcc/config/arm/arm.c | 3 ++-
1 file changed, 2 insertions(
On Tue, Jan 08, 2019 at 08:29:03AM +0100, Uros Bizjak wrote:
> Is there a reason stack registers are excluded? Before stackreg pass,
> these registers are just like other hard registers.
I was just afraid of those, after stack pass removing a store but not
load would result in the stack getting ou
Hi all,
the attached patch is close to obvious and fixes another small
ICE-on-invalid regression. Since there was a bit of discussion in the
PR, I am submitting it for approval instead of just committing as
obvious.
Regtests cleanly on x86_64-linux-gnu. Ok for trunk?
Cheers,
Janus
diff --git a/g
On Tue, Jan 8, 2019 at 10:18 AM Richard Biener wrote:
>
> This is about the Fortran FE creating global variable initializers
> with wrong type (integer type rather than pointer type) for
> ISOCBINDING_NULL_* initializers. The patch simplifies the logic
> in gfc_conv_initializer to directly creat
This is about the Fortran FE creating global variable initializers
with wrong type (integer type rather than pointer type) for
ISOCBINDING_NULL_* initializers. The patch simplifies the logic
in gfc_conv_initializer to directly create the expected GENERIC
rather than trying to use the scalarizer.
88 matches
Mail list logo
