Hi.
IPA pure const should always construct ipa_reduced_postorder with
possibility to cross AVAIL_INTERPOSABLE boundary. The pass itself
can then properly stop propagation on these symbols.
The patch is pre-approved by Honza.
Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
@Honza: PING^2
On 2/4/19 9:09 AM, Martin Liška wrote:
> @Honza: PING^1
>
> Martin
>
> On 1/24/19 9:10 AM, Martin Liška wrote:
>> On 1/23/19 7:28 PM, Segher Boessenkool wrote:
>>> Hi Martin,
>>>
>>> On Wed, Jan 23, 2019 at 10:29:40AM +0100, Martin Liška wrote:
diff --git a/gcc/cfgrtl.c b/gcc
Updated version of the patch where I added a test-case.
I'm going to install this version.
Martin
>From ffe0985846a8827fce4e47f090804e664059b650 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 8 Feb 2019 13:04:11 +0100
Subject: [PATCH] Construct ipa_reduced_postorder always for overwritable (PR
Hi Uros,
> On Fri, Feb 8, 2019 at 1:24 PM Uros Bizjak wrote:
>
>> Attached patch fixes --enable-frame-pointer handling, and this way
>> makes a couple of defines in config/i386/sol2.h obsolete.
>
> It turned out that --enable-frame-pointer does not work for multilibs
> at all. So, instead of pret
On Wed, Jan 23, 2019 at 09:35:03AM +, co...@sdf.org wrote:
> > Is this necessary? I'd prefer to not set this field if it can be
> > avoided. The same goes for the others, I intend to remove them at
> > soonest convenience once the problematic parts of the front-end logic
> > has been abstract
> Hi.
>
> IPA pure const should always construct ipa_reduced_postorder with
> possibility to cross AVAIL_INTERPOSABLE boundary. The pass itself
> can then properly stop propagation on these symbols.
>
> The patch is pre-approved by Honza.
> Patch can bootstrap on x86_64-linux-gnu and survives reg
> To fix the r267812 incorrectness we need to use the *stored*
> size, i.e. that which will be stored into using register-sized
> writes. It's seems like the bug is just a typo, so the fix is
> as simple as follows. Note the usage of "diff -U 10" to show
> that size_stored is used in the "then"-a
> Date: Mon, 11 Feb 2019 07:38:14 +0100
> From: Richard Biener
> >+ HOST_WIDE_INT min_parm_align
> >+= STRICT_ALIGNMENT ? BITS_PER_WORD : PREFERRED_STACK_BOUNDARY;
>
> Shouldn't it be MIN (...) of BOTH?
That *does* seem logical... Take 2 as follows, in testing as
before.
Ok to commi
> @Honza: PING^2
>
> On 2/4/19 9:09 AM, Martin Liška wrote:
> > @Honza: PING^1
> >
> > Martin
> >
> > On 1/24/19 9:10 AM, Martin Liška wrote:
> >> On 1/23/19 7:28 PM, Segher Boessenkool wrote:
> >>> Hi Martin,
> >>>
> >>> On Wed, Jan 23, 2019 at 10:29:40AM +0100, Martin Liška wrote:
> diff
> You make an arbitrary distinction between certain CPUs and duplicate
> patterns based on that.
Sure, somewhat arbitrary, but that's a proof of concept and IMO better than
treating every processor the same way. The alternative would be to complicate
further the existing patterns by means of th
On Mon, Feb 11, 2019 at 10:00:03AM +0100, Hans-Peter Nilsson wrote:
> > Date: Mon, 11 Feb 2019 07:38:14 +0100
> > From: Richard Biener
>
> > >+ HOST_WIDE_INT min_parm_align
> > >+ = STRICT_ALIGNMENT ? BITS_PER_WORD : PREFERRED_STACK_BOUNDARY;
> >
> > Shouldn't it be MIN (...) of BOTH?
>
Hi Stefan,
On 09/02/19 16:25, Stefan Agner wrote:
Hi Kyrill,
On 10.01.2019 12:38, Kyrill Tkachov wrote:
Hi Stefan,
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
Hi,
asan_expand_mark_ifn does manual store merging but doesn't take into account
the alignment, so this can break on strict-alignment platforms.
Tested on SPARC/Solaris 11, where this fixes this regression:
FAIL: gcc.dg/asan/use-after-scope-5.c -O0 output pattern test
FAIL: gcc.dg/asan/use-a
On Mon, Feb 11, 2019 at 11:03:41AM +0100, Eric Botcazou wrote:
> asan_expand_mark_ifn does manual store merging but doesn't take into account
> the alignment, so this can break on strict-alignment platforms.
>
> Tested on SPARC/Solaris 11, where this fixes this regression:
>
> FAIL: gcc.dg/asan/
Hi Jakub,
On 08/02/19 11:40, Jakub Jelinek wrote:
On Fri, Feb 08, 2019 at 11:29:10AM +, Matthew Malcomson wrote:
> I'm pretty sure there's no difference between the iwmmxt target and
> others so believe your simpler fix of just using 'q' is a good idea.
> (there's no difference in gas and n
> Date: Mon, 11 Feb 2019 10:22:12 +0100
> From: Jakub Jelinek
> Is PREFERRED_STACK_BOUNDARY what we want here? Shouldn't that be
> STACK_BOUNDARY, or PARM_BOUNDARY? Though, PARM_BOUNDARY on cris is 32...
Hm.
I wish there was a better distinction both in the code and in
peoples minds between b
On Mon, Feb 11, 2019 at 10:32:23AM +, Kyrill Tkachov wrote:
> I think this is ok.
Ok, committed the simpler version.
> The "q" constraint was introduced after the iwmmxt.md patterns were written
> and it seems
> that they were just never updated to use it.
> It's hard for anyone to get a hol
On Sun, 2019-02-10 at 22:08 -0800, Ian Lance Taylor wrote:
> On Sun, Feb 10, 2019 at 3:41 AM Svante Signell
> wrote:
> > On Sat, 2019-02-09 at 23:57 +0100, Svante Signell wrote:
> > > On Sat, 2019-02-09 at 14:40 -0800, Ian Lance Taylor wrote:
> > > > On Fri, Feb 8, 2019 at 3:07 PM Matthias Klose
> So, wouldn't it be better to check for STRICT_ALIGNMENT
> get_pointer_alignment (base_addr) and do this only if that alignment
> (shifted right by ASAN_SHADOW_SHIFT) is not sufficient and e.g. if we would
> know that the shadow is at least 2 byte aligned but not 4 byte aligned, use
> size = 2 ins
On 08/02/2019 16:10, David Edelsohn wrote:
I am pleased to announce that the GCC Steering Committee has
appointed Andrew Stubbs and Julian Brown as AMD GCN maintainers.
Many thanks to David and the Steering Committee!
I've committed the attached.
Andrew
Add AMD GCN maintainers
2019-0
On Mon, Feb 11, 2019 at 12:31:43PM +0100, Eric Botcazou wrote:
> > So, wouldn't it be better to check for STRICT_ALIGNMENT
> > get_pointer_alignment (base_addr) and do this only if that alignment
> > (shifted right by ASAN_SHADOW_SHIFT) is not sufficient and e.g. if we would
> > know that the shado
On 10/02/19 11:46 +0800, 李苏旺 wrote:
hi Marc,
I am very glad to receive you reply, in fact , I have neither " C++
standard these are specified" nor "feature test macro" , I saw negation,
conjunction and disjunction have added in type_traits , and similar , after
I reference to
https://whatis.t
Hi!
On Mon, Feb 11, 2019 at 11:08:12AM +1030, Alan Modra wrote:
> On Fri, Feb 08, 2019 at 04:53:44PM -0600, Segher Boessenkool wrote:
> > > @@ -37981,7 +37982,7 @@ rs6000_call_sysv (rtx value, rtx func_desc, rtx
> > > tlsarg, rtx cookie)
> > >func = rs6000_longcall_ref (func_desc, tlsarg)
Bootstrapped and regtested on s390x-redhat-linux.
After r265371 (S/390: Make "b" constraint match literal pool references),
satisfies_constraint_b () started accepting memory references, whose
addresses do not pass legitimate_address_p (). Specifically, literal
pool accesses past the end of the e
I noticed that HAVE_INITFINI_ARRAY_SUPPORT wasn't properly detected on
Solaris 11.4 and up in 64-bit-default configurations when using gas
(2.32) and Solaris ld.
Closer inspection revealed the following: both Solaris as and gas <=
2.28 emit
Section Header[7]: sh_name: .init_array.01005
sh_ad
On Sun, Feb 10, 2019 at 11:25 PM Uros Bizjak wrote:
>
> On Mon, Feb 11, 2019 at 2:04 AM H.J. Lu wrote:
> >
> > On Sun, Feb 10, 2019 at 1:49 PM Uros Bizjak wrote:
> > >
> > > On Sun, Feb 10, 2019 at 10:45 PM Uros Bizjak wrote:
> > >
> > > > > > > + [(const_int 0)]
> > > > > > > +{
> > > > > > >
> No. 64-bit aligned offsets too. If you know 64-bit alignment of base_addr,
> you can use size 2 stores (though not size 4 stores) on the
> !STRICT_ALIGNMENT targets. And that is something still pretty common.
But we're talking about STRICT_ALIGNMENT targets here: an array of 2 doubles
at add
On Sun, Feb 10, 2019 at 08:42:42PM -0600, Bill Schmidt wrote:
> On 2/10/19 4:05 PM, Segher Boessenkool wrote:
> > On Sun, Feb 10, 2019 at 10:10:02AM -0600, Bill Schmidt wrote:
> >> I've added executable tests for both shift-right algebraic and shift-right
> >> logical.
> >> Both fail prior to appl
Hello Segher,
the current procdure is:
-- write at https://gcc.gnu.org/bugzilla/
-- read an answer, that the update shall be posted to gcc-patches
-- subscribe to gcc-patches, post the change and wait for an answer.
This waiting is not for free. There are a lot of emails, for the person might
Ilya Leoshkevich wrote:
> After r265371 (S/390: Make "b" constraint match literal pool references),
> satisfies_constraint_b () started accepting memory references, whose
> addresses do not pass legitimate_address_p (). Specifically, literal
> pool accesses past the end of the entry they are base
On Mon, Feb 11, 2019 at 1:26 PM H.J. Lu wrote:
>
> On Sun, Feb 10, 2019 at 11:25 PM Uros Bizjak wrote:
> >
> > On Mon, Feb 11, 2019 at 2:04 AM H.J. Lu wrote:
> > >
> > > On Sun, Feb 10, 2019 at 1:49 PM Uros Bizjak wrote:
> > > >
> > > > On Sun, Feb 10, 2019 at 10:45 PM Uros Bizjak wrote:
> > >
Instead of a single test that only checks whether can be
included in Parallel Mode, add tests for each of C++11/C++14/C++17 that
check whether is compatible with _GLIBCXX_PARALLEL.
This increases the coverage to (almost) all headers.
If is not available then the tests will trivially pass, beca
On Mon, Feb 11, 2019 at 01:31:24PM +0100, Eric Botcazou wrote:
> > No. 64-bit aligned offsets too. If you know 64-bit alignment of base_addr,
> > you can use size 2 stores (though not size 4 stores) on the
> > !STRICT_ALIGNMENT targets. And that is something still pretty common.
>
> But we're t
On Sat, Feb 09, 2019 at 02:39:30PM +0100, Jakub Jelinek wrote:
> On Sat, Feb 09, 2019 at 01:22:30PM +0100, Jakub Jelinek wrote:
> > On Sat, Feb 09, 2019 at 04:11:43AM -0800, H.J. Lu wrote:
> > > I believe all usages of
> > >
> > > (ior (match_operand 0 "ext_sse_reg_operand")
> > > (match_ope
All these patches from HJL have no testcases. Are they even sutable for gcc 9
at this stage
Original message
From: Uros Bizjak
Date: 11/02/2019 12:51 (GMT+00:00)
To: "H.J. Lu"
Cc: GCC Patches
Subject: Re: [PATCH 12/43] i386: Emulate MMX vec_dupv2si with SSE
On Mon, Fe
In Mon, Feb 11, 2019 at 4:51 AM Uros Bizjak wrote:
>
> On Mon, Feb 11, 2019 at 1:26 PM H.J. Lu wrote:
> >
> > On Sun, Feb 10, 2019 at 11:25 PM Uros Bizjak wrote:
> > >
> > > On Mon, Feb 11, 2019 at 2:04 AM H.J. Lu wrote:
> > > >
> > > > On Sun, Feb 10, 2019 at 1:49 PM Uros Bizjak wrote:
> > >
On Mon, Feb 11, 2019 at 5:11 AM graham stott
wrote:
>
> All these patches from HJL have no testcases. Are they even sutable for gcc 9
> at this stage
All my changes are covered by
https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00632.html
> Original message
> From: Uros Bizjak
On Mon, Feb 11, 2019 at 2:10 PM H.J. Lu wrote:
>
> On Sat, Feb 09, 2019 at 02:39:30PM +0100, Jakub Jelinek wrote:
> > On Sat, Feb 09, 2019 at 01:22:30PM +0100, Jakub Jelinek wrote:
> > > On Sat, Feb 09, 2019 at 04:11:43AM -0800, H.J. Lu wrote:
> > > > I believe all usages of
> > > >
> > > > (ior (
On Mon, Feb 11, 2019 at 10:07:44AM +0100, Eric Botcazou wrote:
> > You make an arbitrary distinction between certain CPUs and duplicate
> > patterns based on that.
>
> Sure, somewhat arbitrary, but that's a proof of concept and IMO better than
> treating every processor the same way. The alterna
On 2/11/19 6:43 AM, Segher Boessenkool wrote:
> On Sun, Feb 10, 2019 at 08:42:42PM -0600, Bill Schmidt wrote:
>> On 2/10/19 4:05 PM, Segher Boessenkool wrote:
>>> On Sun, Feb 10, 2019 at 10:10:02AM -0600, Bill Schmidt wrote:
I've added executable tests for both shift-right algebraic and shift-
On Mon, Feb 11, 2019 at 5:15 AM Uros Bizjak wrote:
>
> On Mon, Feb 11, 2019 at 2:10 PM H.J. Lu wrote:
> >
> > On Sat, Feb 09, 2019 at 02:39:30PM +0100, Jakub Jelinek wrote:
> > > On Sat, Feb 09, 2019 at 01:22:30PM +0100, Jakub Jelinek wrote:
> > > > On Sat, Feb 09, 2019 at 04:11:43AM -0800, H.J.
Hi,
On Mon, Feb 11 2019, Jan Hubicka wrote:
>> Hi.
>>
>> IPA pure const should always construct ipa_reduced_postorder with
>> possibility to cross AVAIL_INTERPOSABLE boundary. The pass itself
>> can then properly stop propagation on these symbols.
>>
>> The patch is pre-approved by Honza.
>> Pat
Hi!
We had a problem report for code attempting to implement a vector right-shift
for a
vector long long (V2DImode) type. The programmer noted that we don't have a
vector
splat-immediate for this mode, but cleverly realized he could use a vector char
splat-immediate since only the lower 6 bits
On Mon, Feb 11, 2019 at 02:15:18PM +0100, Uros Bizjak wrote:
> > Here is the updated patch to remove ext_sse_reg_operand check with a
> > testcase.
> >
> > OK for trunk?
>
> No. As said, please correctly set mode to XImode in mode attribute
> calculation.
The instructions in question are
vmovdqu
> Hi,
>
> On Mon, Feb 11 2019, Jan Hubicka wrote:
> >> Hi.
> >>
> >> IPA pure const should always construct ipa_reduced_postorder with
> >> possibility to cross AVAIL_INTERPOSABLE boundary. The pass itself
> >> can then properly stop propagation on these symbols.
> >>
> >> The patch is pre-appro
On Mon, Feb 11, 2019 at 2:29 PM H.J. Lu wrote:
> > No. As said, please correctly set mode to XImode in mode attribute
> > calculation.
>
> There is
>
> switch (get_attr_type (insn))
> {
> case TYPE_SSELOG1:
> return standard_sse_constant_opcode (insn, operands);
>
> standard_sse_c
On Mon, Feb 11, 2019 at 12:44:31PM +, Дилян Палаузов wrote:
> -- at https://www.gnu.org/software/gcc/contribute.html is written “If you do
> not receive a response to a patch that you
> have submitted within two weeks or so, it may be a good idea to chase it by
> sending a follow-up email to
On Mon, Feb 11, 2019 at 07:17:16AM -0600, Bill Schmidt wrote:
> At -O0 (if I hand-inline everything myself to avoid errors), we scalarize
> the modulo/masking operation into a rldicl for each doubleword. I really
> don't see any reason to change the code.
So what does this look like at expand (at
Hello Segher,
my question was how do you propose to proceed, so that a
no-reminders-for-patches-are-necessary-state is reached.
There is no relation with having infinite time or dealing with high-cost
low-profit patches.
Previously I raised the quesion, whether automating the process for sendi
Hi Wilco,
Thanks for your feedback.
> On 8 Feb 2019, at 22:35, Wilco Dijkstra wrote:
>
> Hi Olivier,
>
>> Sorry, I had -mapcs-frame in mind.
>
> That's identical to -mapcs, and equally deprecated. It was superceded 2
> decades
> ago. -mpcs-frame bugs have been reported multiple times, includ
On Mon, Feb 11, 2019 at 5:51 AM Uros Bizjak wrote:
>
> On Mon, Feb 11, 2019 at 2:29 PM H.J. Lu wrote:
>
> > > No. As said, please correctly set mode to XImode in mode attribute
> > > calculation.
> >
> > There is
> >
> > switch (get_attr_type (insn))
> > {
> > case TYPE_SSELOG1:
> >
On 10/02/19 09:42, Christophe Lyon wrote:
>
> Both this simple patch or the previous fix all the ICEs I reported, thanks.
>
> Of course, the scan-assembler failures remain to be fixed.
>
In the testcase I failed to account for targets that don't support arm
mode or
targets that do not support
On 2/11/19 8:11 AM, Segher Boessenkool wrote:
> On Mon, Feb 11, 2019 at 07:17:16AM -0600, Bill Schmidt wrote:
>> At -O0 (if I hand-inline everything myself to avoid errors), we scalarize
>> the modulo/masking operation into a rldicl for each doubleword. I really
>> don't see any reason to change t
Hi All,
On AArch64 aarch64_classify_address has a case for when it's non-strict
that will allow it to accept any byte offset from a reg when validating
an address in a given addressing mode.
This because reload would later make the address valid. SVE however requires
the address always be valid,
Hi all,
After the register allocator changes of r268705 we need to update a few tests
with new output.
In all cases the compiler is now generating the expected code, since the tests
are all float16 testcases using a hard-floar abi, we expect that actual fp16
instructions are used rather than usin
> -Original Message-
> From: James Greenhalgh
> Sent: 06 February 2019 17:42
> To: Alejandro Martinez Vicente
> Cc: GCC Patches ; nd ; Richard
> Sandiford ; Richard Biener
>
> Subject: Re: [Aarch64][SVE] Vectorise sum-of-absolute-differences
>
> On Mon, Feb 04, 2019 at 07:34:05AM -0600,
On Mon, Feb 11, 2019 at 3:32 PM H.J. Lu wrote:
>
> On Mon, Feb 11, 2019 at 5:51 AM Uros Bizjak wrote:
> >
> > On Mon, Feb 11, 2019 at 2:29 PM H.J. Lu wrote:
> >
> > > > No. As said, please correctly set mode to XImode in mode attribute
> > > > calculation.
> > >
> > > There is
> > >
> > > swit
Hi Bill,
On Mon, Feb 11, 2019 at 07:36:11AM -0600, Bill Schmidt wrote:
> 2019-02-11 Bill Schmidt
>
> * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Shift-right
> and shift-left vector built-ins need to include a TRUNC_MOD_EXPR
> for correct semantics.
>
> [gcc/testsu
In Mon, Feb 11, 2019 at 7:56 AM Uros Bizjak wrote:
>
> On Mon, Feb 11, 2019 at 3:32 PM H.J. Lu wrote:
> >
> > On Mon, Feb 11, 2019 at 5:51 AM Uros Bizjak wrote:
> > >
> > > On Mon, Feb 11, 2019 at 2:29 PM H.J. Lu wrote:
> > >
> > > > > No. As said, please correctly set mode to XImode in mode at
On 11/02/19 15:17, Tamar Christina wrote:
Hi all,
After the register allocator changes of r268705 we need to update a few tests
with new output.
In all cases the compiler is now generating the expected code, since the tests
are all float16 testcases using a hard-floar abi, we expect that actu
On 2/11/19 10:01 AM, Segher Boessenkool wrote:
> Hi Bill,
>
> On Mon, Feb 11, 2019 at 07:36:11AM -0600, Bill Schmidt wrote:
>> 2019-02-11 Bill Schmidt
>>
>> * config/rs6000/rs6000.c (rs6000_gimple_fold_builtin): Shift-right
>> and shift-left vector built-ins need to include a TRUNC_MO
On Mon, Feb 11, 2019 at 04:56:45PM +0100, Uros Bizjak wrote:
> > Let's first define what MODE_XI means in standard_sse_constant_opcode
> > as well as in all these mov patterns for with and without AVX512VL.
> > Without
> > a clear definition, we can't get out of this mess.
>
> INT_MODE (OI, 32)
On Mon, Feb 11, 2019 at 02:16:27PM +, Дилян Палаузов wrote:
> Hello Segher,
>
> my question was how do you propose to proceed, so that a
> no-reminders-for-patches-are-necessary-state is reached.
>
> There is no relation with having infinite time or dealing with high-cost
> low-profit patch
I noticed the comments in the test don't correspond to what it's
designed to exercise: namely that the call to hot_function() is
inlined and the call to cold_function() is not, rather than
the other way around.
Attached is a patch that adjusts the comments. Honza, please let
me know if this look
> I noticed the comments in the test don't correspond to what it's
> designed to exercise: namely that the call to hot_function() is
> inlined and the call to cold_function() is not, rather than
> the other way around.
>
> Attached is a patch that adjusts the comments. Honza, please let
> me know
Hi Wilco,
> On 8 Feb 2019, at 22:35, Wilco Dijkstra wrote:
> So I think we need to push much harder on getting rid of obsolete stuff and
> avoid people encountering these nasty issues.
Numbers I just received indicate that we can legitimately head
in this direction for VxWorks as well (move tow
Hello Ramana,
> Olivier, while you are here could you also document the choices made by
> the vxworks port in terms of the ABI and how it differs from EABI ? It
> would certainly help with patch review.
Thanks for your feedback as well.
Yes, I'll add a comment and macro defs to the VxWorks
heade
The GCC optimizer can generate symbols with non-zero offset from simple
if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
with offsets fail if it changes bit zero and the relocation forces bit zero
to true. The fix is to disable offsets on function pointer symbols.
ARM
Bootstrapped and regtested on s390x-redhat-linux.
The previous attempt to fix PR89233 [1] went into wrong direction of
dealing with symptoms rather than the root cause. Since the approach
here is completely different, I'm not sending it as v2.
The following insn:
(insn (set (reg:DI %r2)
My patch for 86943 on the branch removed this code, which led to a location
change on one of the diagnostics in constexpr-lambda8.C. Removing this bit
wasn't the point of the patch, so let's put it back.
Applying to 8 branch.
* pt.c (tsubst_copy_and_build): Do still clear expr location
On Sun, Feb 10, 2019 at 3:16 AM Uros Bizjak wrote:
>
> On 2/10/19, H.J. Lu wrote:
> > Emulate MMX pshufw with SSE. Only SSE register source operand is allowed.
> >
> > PR target/89021
> > * config/i386/mmx.md (mmx_pshufw_1): Add SSE emulation.
> > (*vec_dupv4hi): Likewise.
> >
On Mon, 11 Feb 2019, Wilco Dijkstra wrote:
> The GCC optimizer can generate symbols with non-zero offset from simple
> if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
> with offsets fail if it changes bit zero and the relocation forces bit zero
> to true. The fix is to
Fix test errors on targets which do not support pthreads.
Committed as obvious.
ChangeLog:
2019-02-11 Wilco Dijkstra
PR tree-optimization/86637
* gcc.c-torture/compile/pr86637-2.c: Test pthread and graphite target.
---
diff --git a/gcc/testsuite/gcc.c-torture/compile/pr86637-2
Tamar Christina writes:
> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
> index
> 5df5a8b78439e69705e62845a4d1f86166a01894..59f03e688e58c1aab37629555c7b3f19e5075935
> 100644
> --- a/gcc/config/aarch64/aarch64.c
> +++ b/gcc/config/aarch64/aarch64.c
> @@ -3414,6 +3414,14
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-02/msg00224.html
(This patch also handles bug 88835.)
On 2/4/19 8:58 PM, Martin Sebor wrote:
The attached patch relaxes -Wformat-overflow=2 to avoid warning about
individual directives that might (but need not) exceed the 4095 byte
limit, and about
On Mon, Feb 11, 2019 at 3:10 AM Svante Signell wrote:
>
> On Sun, 2019-02-10 at 22:08 -0800, Ian Lance Taylor wrote:
> > On Sun, Feb 10, 2019 at 3:41 AM Svante Signell
> > wrote:
> > > On Sat, 2019-02-09 at 23:57 +0100, Svante Signell wrote:
> > > > On Sat, 2019-02-09 at 14:40 -0800, Ian Lance Ta
Svante Signell, le lun. 11 févr. 2019 12:10:21 +0100, a ecrit:
> WCONTINUED is not defined, I assume that WIFCONTINUED is not supported.
>
> From waitpid(2):
> WCONTINUED (since Linux 2.6.10)
>also return if a stopped child has been resumed by delivery of SIGCONT.
>
> @Samuel: more info?
git
On 2/7/19 6:02 PM, Marek Polacek wrote:
Since r268321 we can call digest_init even in a template, when the compound
literal isn't instantiation-dependent.
Right. And since digest_init modifies the CONSTRUCTOR in place, that
means the template trees are digested rather than the original parse
On Thu, 2019-02-07 at 18:13 +, Wilco Dijkstra wrote:
> External Email
>
> Hi Steve,
>
> > > After special cases you could do something like t = mask2 +
> > > (HWI_1U << shift);
> > > return t == (t & -t) to check for a valid bfi.
> >
> > I am not sure I follow this logic and my attempts to u
On Sun, Feb 10, 2019 at 2:48 AM Uros Bizjak wrote:
>
> On 2/10/19, H.J. Lu wrote:
> > Emulate MMX sse_cvtps2pi/sse_cvttps2pi with SSE.
> >
> > PR target/89021
> > * config/i386/mmx.md (sse_cvtps2pi): Add SSE emulation.
> > (sse_cvttps2pi): Likewise.
>
> It looks to me that this
This is a repost of a patch for PR 88383 updated to also fix the just
reported PR 89288 (the original patch only partially handles this case).
The review of the first patch was derailed by questions about the design
of the built-in so the fix for the ICE was never approved. I think
the ICEs shoul
On Fri, Feb 08, 2019 at 05:37:00PM -0500, Jason Merrill wrote:
> On 2/8/19 12:21 PM, Marek Polacek wrote:
> > r256999 removed early bailout for pointer-to-member-function types, so we
> > now try to tsubst each element of a pointer-to-member-function CONSTRUCTOR.
> >
> > That's fine but the proble
This I don't like.
Obvious, but ok?
2019-02-11 Marek Polacek
* typeck2.c (digest_init_r): Remove commented code.
--- gcc/cp/typeck2.c
+++ gcc/cp/typeck2.c
@@ -1099,7 +1099,6 @@ digest_init_r (tree type, tree init, int nested, int
flags,
tree typ1 = TYPE_MAIN_VARIANT (TREE_T
On Mon, Feb 11, 2019 at 12:20:42PM -0700, Martin Sebor wrote:
> This is a repost of a patch for PR 88383 updated to also fix the just
> reported PR 89288 (the original patch only partially handles this case).
> The review of the first patch was derailed by questions about the design
> of the built-
On Mon, Feb 11, 2019 at 7:09 PM H.J. Lu wrote:
>
> On Sun, Feb 10, 2019 at 3:16 AM Uros Bizjak wrote:
> >
> > On 2/10/19, H.J. Lu wrote:
> > > Emulate MMX pshufw with SSE. Only SSE register source operand is allowed.
> > >
> > > PR target/89021
> > > * config/i386/mmx.md (mmx_pshufw
Hi Alexander,
> Just to be sure the issue is analyzed properly: if it's certain that this
> usage
> is not allowed, shouldn't the linker produce a diagnostic instead of silently
> concealing the issue?
The ABI doesn't require this but yes a linker could report a warning if the
addend of a functi
OK.
On 2/11/19 2:27 PM, Marek Polacek wrote:
This I don't like.
Obvious, but ok?
2019-02-11 Marek Polacek
* typeck2.c (digest_init_r): Remove commented code.
--- gcc/cp/typeck2.c
+++ gcc/cp/typeck2.c
@@ -1099,7 +1099,6 @@ digest_init_r (tree type, tree init, int nested, int
flags
On Mon, Feb 11, 2019 at 8:08 PM H.J. Lu wrote:
>
> On Sun, Feb 10, 2019 at 2:48 AM Uros Bizjak wrote:
> >
> > On 2/10/19, H.J. Lu wrote:
> > > Emulate MMX sse_cvtps2pi/sse_cvttps2pi with SSE.
> > >
> > > PR target/89021
> > > * config/i386/mmx.md (sse_cvtps2pi): Add SSE emulation.
>
On 2/11/19 2:21 PM, Marek Polacek wrote:
On Fri, Feb 08, 2019 at 05:37:00PM -0500, Jason Merrill wrote:
On 2/8/19 12:21 PM, Marek Polacek wrote:
r256999 removed early bailout for pointer-to-member-function types, so we
now try to tsubst each element of a pointer-to-member-function CONSTRUCTOR.
On 2/8/19 6:18 PM, Jakub Jelinek wrote:
Hi!
Non-type template arguments are constant-expression in the grammar and thus
manifestly constant-evaluated.
For e.g. class templates, convert_nontype_argument is called with
tf_warning_or_error and so while we called in the below spots
maybe_constant_va
On Mon, Feb 11, 2019 at 12:20:42PM -0700, Martin Sebor wrote:
> --- gcc/c-family/c-attribs.c (revision 268774)
> +++ gcc/c-family/c-attribs.c (working copy)
> @@ -4032,8 +4032,12 @@ validate_attribute (location_t atloc, tree oper, t
>
>if (TYPE_P (oper))
> tmpdecl = build_decl (atloc,
On Mon, 11 Feb 2019, Wilco Dijkstra wrote:
> > With Gold linker this is handled correctly. So it looks to me like a
> > bug in BFD linker, where it ignores any addend (not just +1/-1) when
> > resolving a relocation against a Thumb function.
>
> If the Gold linker doesn't fail that means Gold has
On 2/11/19 1:23 PM, Jakub Jelinek wrote:
On Mon, Feb 11, 2019 at 12:20:42PM -0700, Martin Sebor wrote:
--- gcc/c-family/c-attribs.c(revision 268774)
+++ gcc/c-family/c-attribs.c(working copy)
@@ -4032,8 +4032,12 @@ validate_attribute (location_t atloc, tree oper, t
if (TYPE_P (ope
On Mon, Feb 11, 2019 at 5:35 PM Wilco Dijkstra wrote:
>
> The GCC optimizer can generate symbols with non-zero offset from simple
> if-statements. Bit zero is used for the Arm/Thumb state bit, so relocations
> with offsets fail if it changes bit zero and the relocation forces bit zero
> to true.
On Mon, Feb 11, 2019 at 4:48 PM Olivier Hainque wrote:
>
> Hi Wilco,
>
> > On 8 Feb 2019, at 22:35, Wilco Dijkstra wrote:
>
> > So I think we need to push much harder on getting rid of obsolete stuff and
> > avoid people encountering these nasty issues.
>
> Numbers I just received indicate that w
On Mon, 2019-02-11 at 10:27 -0800, Ian Lance Taylor wrote:
> On Mon, Feb 11, 2019 at 3:10 AM Svante Signell
> wrote:
> > On Sun, 2019-02-10 at 22:08 -0800, Ian Lance Taylor wrote:
> > > On Sun, Feb 10, 2019 at 3:41 AM Svante Signell
> > > wrote:
> > > > On Sat, 2019-02-09 at 23:57 +0100, Svante S
The attached patch moves the check for this F2018 obsolescent feature
to a better place where the warning is only emitted when the COMMON is
declared. No warning should be emitted when such a legacy module is
simply used.
Regtested on x86_64-pc-linux-gnu.
OK for trunk?
Thanks,
Harald
2019-02-1
On x86-64, since __m64 is returned and passed in XMM registers, we can
emulate MMX intrinsics with SSE instructions. To support it, we added
#define TARGET_MMX_WITH_SSE \
(TARGET_64BIT && TARGET_SSE2)
#define TARGET_MMX_WITH_SSE_P(x) \
(TARGET_64BIT_P (x) && TARGET_SSE2_P (x))
;; Define ins
Emulate MMX packsswb/packssdw/packuswb with SSE packsswb/packssdw/packuswb
plus moving bits 64:95 to bits 32:63 in SSE register. Only SSE register
source operand is allowed.
2019-02-08 H.J. Lu
Uros Bizjak
PR target/89021
* config/i386/i386-protos.h (ix86_move_vec
In 64-bit mode, SSE2 can be used to emulate MMX instructions without
3DNOW. We can use SSE2 to support MMX register modes.
PR target/89021
* config/i386/i386.c (ix86_set_reg_reg_cost): Also support
VALID_MMX_WITH_SSE_REG_MODE.
(ix86_vector_mode_supported_p): Likewi
1 - 100 of 146 matches
Mail list logo
