This patch removes the %e error for AIX, since it seems there has been
no attempt to keep ASM_CPU_SPEC cpu support up to date for AIX, and
adds missing entries to ASM_CPU_SPEC in rs6000.h. Removing the %e
isn't ideal, but leaving it in and hitting a compiler error for -mcpu
cases where the AIX
On Thu, Oct 04, 2018 at 02:04:13PM +0100, Julian Brown wrote:
> gcc/
> * omp-low.c (scan_sharing_clauses): Update handling of OpenACC declare
> create, declare copyin and declare deviceptr to have local lifetimes.
> (convert_to_firstprivate_int): Handle pointer types.
>
On Fri, Dec 7, 2018 at 1:24 AM Iain Sandoe wrote:
>
> Hi
>
> This got stuck in my stack of patches for LTO debug support, and I forgot to
> ping it…
>
> > On 22 Aug 2018, at 14:20, Richard Biener wrote:
> >
> > On Wed, Aug 22, 2018 at 2:56 PM Iain Sandoe wrote:
> >>
> >>
> >>> On 20 Aug 2018,
On 2018/12/7 07:32 PM, Thomas Schwinge wrote:
> Hi Chung-Lin!
>
> On Tue, 25 Sep 2018 21:10:47 +0800, Chung-Lin Tang
> wrote:
>> These are the OpenACC specific changes, mostly the re-implementation of
>> async-related acc_* runtime
>> library API functions to use the new backend plugin
Hi Qing,
>> On Nov 28, 2018, at 9:52 AM, Jan Hubicka wrote:
>>
>>>
>>> 2018-11-20 qing zhao
>>>
>>> * cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
>>> * common.opt: Add -flive-patching flag.
>>> * doc/invoke.texi: Document -flive-patching.
>>> * flag-types.h (enum
When trying to rebuild libphobos with -g3 -O0 for better debugging, I
noticed that GDCFLAGS weren't passed down as expected. It turned out
that they are missing from AM_MAKEFLAGS. After I fixed this, the only
file still compiled with -g -O2 was libdruntime/core/threadasm.S, so I
added CCASFLAGS,
On 06/12/2018 15:36, Jeff Law wrote:
>
> As outlined in the PR, the aarch64 has a non-default value for
> CASE_VALUES_THRESHOLD which changes decisions in switch lowering. Those
> changes in switch lowering can expose additional jump threads later in
> the pipeline which cause heartburn for a
On Thu, Dec 06, 2018 at 10:40:41PM +, Julian Brown wrote:
> + && (TREE_CODE (inner_type) == REAL_TYPE
> + || (!omp_is_reference (var)
> + && INTEGRAL_TYPE_P (inner_type))
> + || TREE_CODE (inner_type) == INTEGER_TYPE)
Not sure I
On Fri, 7 Dec 2018, Richard Biener wrote:
>
> The following fixes PR63184 by using tree-affine to resolve pointer
> comparisons. Instead of trying to stick this into a match.pd pattern
> the following does this in the more constrained forwprop environment.
>
> I've only implemented the cases
Hello,
will it help, if Bugzilla is reprogrammed to send automatically weekly
reminders on all patches, that are not integrated yet?
Will lt help, if I hire myself to integrate the patch, or shall I
rather hire somebody to send reminders?
If something can be done after sending a reminder, then
On Thu, Dec 6, 2018 at 10:22 PM Jason Merrill wrote:
>
> On Thu, Dec 6, 2018 at 11:14 AM Jason Merrill wrote:
> >
> > Looks good to me. Independently, do you see a reason not to disable the
> > old demangler entirely?
>
> Like so. Does anyone object to this? These mangling schemes haven't
>
Vladimir Makarov writes:
> Here is another solution for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88282
>
> less hackish than original one.
>
> The patch was bootstrapped and tested on x86/x86-64/ppc64/aarch64.
>
> Committed as rev. 266862.
Nice! Thanks for doing this.
On Fri, Nov 30, 2018 at 03:41:09AM -0800, Julian Brown wrote:
> gcc/c-family/
> * c-pragma.h (pragma_omp_clause): Add PRAGMA_OACC_CLAUSE_ATTACH,
> PRAGMA_OACC_CLAUSE_DETACH.
...
> @@ -11804,9 +11808,12 @@ c_parser_omp_variable_list (c_parser *parser,
> case
Hi Jason,
>> Looks good to me. Independently, do you see a reason not to disable the
>> old demangler entirely?
>
> Like so. Does anyone object to this? These mangling schemes haven't
> been relevant in decades.
I am not really familiar with this old scheme, so please excuse my ignorance
in
On Fri, Dec 07, 2018 at 10:27:17AM +, Nick Clifton wrote:
> >> Looks good to me. Independently, do you see a reason not to disable the
> >> old demangler entirely?
> >
> > Like so. Does anyone object to this? These mangling schemes haven't
> > been relevant in decades.
>
> I am not really
On Fri, Dec 7, 2018 at 2:07 AM Rainer Orth
wrote:
>
> > This libgo patch by Cherry Zhang adds support for precise stack
> > scanning to the Go runtime. This uses per-function stack maps stored
> > in the exception tables in the language-specific data area. The
> > compiler needs to generate
Hi,
these should be more or less straightforward (now that
DECL_SOURCE_LOCATION often extracts a proper location ;). In the case of
warn_if_not_aligned I also removed the redundant width check (it's never
null, double checked by running the instrumented testsuite too) and I
also removed the
Hi Chung-Lin!
On Tue, 25 Sep 2018 21:10:47 +0800, Chung-Lin Tang
wrote:
> These are the OpenACC specific changes, mostly the re-implementation of
> async-related acc_* runtime
> library API functions to use the new backend plugin interfaces, in a
> non-target specific way.
(The patch was
On 19/11/2018 09:57, Thomas Preudhomme wrote:
> Softfloat single precision and double precision floating-point
> multiplication routines in libgcc share some code with the
> floating-point division of their corresponding precision. As the code
> is structured now, this leads to *all* division code
On Thu, Nov 29, 2018 at 10:56:46AM -0600, Sudakshina Das wrote:
> Hi
>
> On 02/11/18 18:37, Sudakshina Das wrote:
> > Hi
> >
> > This patch is part of a series that enables ARMv8.5-A in GCC and
> > adds Branch Target Identification Mechanism.
> >
Hi,
the patch below adds alias analysis (AA) walk limiting to all
walk_alias_vdefs calls invoked as IPA-CP and ipa-fnsummary summary
generation. Eventually the two should be unified into just one phase
but that is something for stage1. This patch gives them both
independent budgets, both
On Fri, Dec 07, 2018 at 04:19:22PM +, Wilco Dijkstra wrote:
> Jakub Jelinek wrote:
> > On Fri, Dec 07, 2018 at 02:52:48PM +, Wilco Dijkstra wrote:
> >> - struct __attribute__((aligned (32))) S { int a[4]; } s;
> >>
Hi Chung-Lin!
On Tue, 25 Sep 2018 21:11:42 +0800, Chung-Lin Tang
wrote:
> These are the testsuite/libgomp.oacc-c-c++-common/* changes.
> diff --git a/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-71.c
> b/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-71.c
> index c85e824..6afe2a0 100644
>
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88349
The patch is simple and therefore I checked it only on x86-64.
Committed as rev. 226894.
Index: ChangeLog
===
--- ChangeLog (revision 266893)
+++
Adding gdb-patches, since demangling affects gdb.
Ref: https://gcc.gnu.org/ml/gcc-patches/2018-12/msg00407.html
On 12/07/2018 10:40 AM, Jakub Jelinek wrote:
> On Fri, Dec 07, 2018 at 10:27:17AM +, Nick Clifton wrote:
Looks good to me. Independently, do you see a reason not to disable
"Kyrill Tkachov" writes:
> @@ -10834,6 +10836,34 @@ aarch64_parse_tune_string (const char *tune_string,
>"tune=");
> }
>
> +/* Parse the sve_width tuning moverride string in TUNE_STRING.
> + Accept the valid SVE vector widths allowed by
> +
A recent patch inadvertently added the use of "vector" to mmintrin.h
when all such uses should be "__vector".
Committed as obvious/trivial.
[gcc]
2018-12-07 Paul A. Clarke
PR target/88408
* config/rs6000/mmintrin.h (_mm_packs_pu16): Correctly use "__vector".
Index:
So as discussed in BZ87813, the evrp range analyzer currently reflects
any globally valid ranges it finds into the global range information we
attach to SSA_NAMEs.
That is usually a good thing, except when the analyzer is called from a
warning pass. Enabling/disabling of warnings should not
Improve the fix for PR64242. Various optimizations can change a memory
reference
into a frame access. Given there are multiple virtual frame pointers which may
be replaced by multiple hard frame pointers, there are no checks for writes to
the
various frame pointers. So updates to a frame
On Thu, Dec 6, 2018 at 10:04 AM Ian Lance Taylor via gcc-patches
wrote:
>
> On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote:
> >
> > Is the patch OK with you ?
>
This caused:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88409
--
H.J.
Hi,
Jakub Jelinek wrote:
> On Fri, Dec 07, 2018 at 02:52:48PM +, Wilco Dijkstra wrote:
>> - struct __attribute__((aligned (32))) S { int a[4]; } s;
>>
>> - bar ();
On Fri, Dec 7, 2018 at 8:17 AM H.J. Lu wrote:
>
> On Thu, Dec 6, 2018 at 10:04 AM Ian Lance Taylor via gcc-patches
> wrote:
> >
> > On Thu, Dec 6, 2018 at 3:12 AM Nick Clifton wrote:
> > >
> > > Is the patch OK with you ?
> >
>
> This caused:
>
>
thanks a lot for fixing this issue.
Qing
> On Dec 7, 2018, at 7:07 AM, Rainer Orth wrote:
>
> Hi Qing,
>
>>> On Nov 28, 2018, at 9:52 AM, Jan Hubicka wrote:
>>>
2018-11-20 qing zhao
* cif-code.def (EXTERN_LIVE_ONLY_STATIC): New CIF code.
* common.opt: Add
On 12/7/18 3:55 AM, Richard Biener wrote:
> On Fri, 7 Dec 2018, Richard Biener wrote:
>
>>
>> The following fixes PR63184 by using tree-affine to resolve pointer
>> comparisons. Instead of trying to stick this into a match.pd pattern
>> the following does this in the more constrained forwprop
"Kyrill Tkachov" writes:
> diff --git a/gcc/config/aarch64/aarch64-protos.h
> b/gcc/config/aarch64/aarch64-protos.h
> index
> 1fe1a50d52aeb3719cf30c4a2af41abb8dd7233d..fa3c247f0773e1d4101b6209b6b7ba6cd50f82eb
> 100644
> --- a/gcc/config/aarch64/aarch64-protos.h
> +++
> Hi Honza,
> I have committed the typo fix as revision 266885.
> Also I followed your suggestion (IIUC) by calling
> profile_count::adjust_for_ipa_scaling for zero den in function
> update_profiling_info. It works and does make more sense than
> changing the global zero check logic.
> Patch
On 07/12/18 16:32, Richard Sandiford wrote:
"Kyrill Tkachov" writes:
@@ -10834,6 +10836,34 @@ aarch64_parse_tune_string (const char *tune_string,
"tune=");
}
+/* Parse the sve_width tuning moverride string in TUNE_STRING.
+ Accept the valid SVE
On 12/7/18 6:46 AM, Richard Earnshaw (lists) wrote:
> On 06/12/2018 15:36, Jeff Law wrote:
>>
>> As outlined in the PR, the aarch64 has a non-default value for
>> CASE_VALUES_THRESHOLD which changes decisions in switch lowering. Those
>> changes in switch lowering can expose additional jump
Sorry about the breakage. Thanks for the patch.
On Fri, Dec 7, 2018 at 9:23 AM Ian Lance Taylor wrote:
> On Fri, Dec 7, 2018 at 2:07 AM Rainer Orth
> wrote:
> >
> > > This libgo patch by Cherry Zhang adds support for precise stack
> > > scanning to the Go runtime. This uses per-function
As I suggested in the BZ, this patch rejects constants with just the
high bit set for the recently added "bfxil" pattern. As a result we'll
return to using "bit" for the test in the BZ.
I'm not versed enough in aarch64 performance tuning to know if "bit" is
actually a better choice than
On 12/7/18 10:31 AM, Richard Earnshaw (lists) wrote:
> On 07/12/2018 15:52, Jeff Law wrote:
>> As I suggested in the BZ, this patch rejects constants with just the
>> high bit set for the recently added "bfxil" pattern. As a result we'll
>> return to using "bit" for the test in the BZ.
>>
>> I'm
On Tue, Dec 4, 2018 at 12:58 PM Florian Weimer wrote:
>
> * Wilco Dijkstra:
>
> >> For userland, I would like to eventually copy the OpenBSD approach for
> >> architectures which have some form of PC-relative addressing: we can
> >> have multiple random canaries in (RELRO) .rodata in sufficiently
When using the unpredicated immediate forms of MUL, LSL, LSR and ASR,
the rtl patterns would still have the predicate operand we created for
the other forms. This patch splits the patterns after reload in order
to get rid of the predicate, like we already do for WHILE.
Tested on
On 12/7/18 5:39 AM, Paolo Carlini wrote:
Hi,
these should be more or less straightforward (now that
DECL_SOURCE_LOCATION often extracts a proper location ;). In the case of
warn_if_not_aligned I also removed the redundant width check (it's never
null, double checked by running the
Hi Chung-Lin!
On Tue, 25 Sep 2018 21:11:42 +0800, Chung-Lin Tang
wrote:
> These are the testsuite/libgomp.oacc-c-c++-common/* changes.
Please commit the following three hunks to trunk: the code as present
doesn't declare its async/wait dependencies correctly. To record the
review effort,
Hi,
Jakub Jelinek wrote:
On Fri, Dec 07, 2018 at 04:19:22PM +, Wilco Dijkstra wrote:
>> The test case doesn't need an aligned object to fail, so why did you add it?
>
> It needed it on i686, because otherwise it happened to see the value it
> wanted in the caller's stack frame.
Right, so I
Sorry for the slow review.
Steve Ellcey writes:
> @@ -1470,6 +1479,45 @@ aarch64_hard_regno_mode_ok (unsigned regno,
> machine_mode mode)
>return false;
> }
>
> +/* Return true if this is a definition of a vectorized simd function. */
> +
> +static bool
> +aarch64_simd_decl_p (tree
On 12/6/18 6:26 PM, Jakub Jelinek wrote:
On Wed, Dec 05, 2018 at 09:50:56PM +0100, Jakub Jelinek wrote:
On Wed, Dec 05, 2018 at 03:49:26PM -0500, Jason Merrill wrote:
On 11/28/18 3:42 AM, Jakub Jelinek wrote:
Whenever we need to clone a cdtor (either because the target doesn't support
aliases
Hi all,
On top of the previous patch that implements TARGET_ESTIMATED_POLY_VALUE
and adds an sve_width tuning field to the CPU structs, this patch implements
an -moverride knob to adjust this sve_width field to allow for experimentation.
Again, reminder that this only has an effect when
Hi all,
The hook TARGET_ESTIMATED_POLY_VALUE allows a target to give an estimate for a
poly_int run-time value.
It is used exclusively in tuning decisions, things like estimated loop
iterations, probabilities etc.
It is not relied on for correctness.
If we know the SVE width implemented in
On Fri, Dec 07, 2018 at 02:52:48PM +, Wilco Dijkstra wrote:
> - struct __attribute__((aligned (32))) S { int a[4]; } s;
>
> - bar ();
>
Hi Chung-Lin!
On Tue, 25 Sep 2018 21:11:42 +0800, Chung-Lin Tang
wrote:
> These are the testsuite/libgomp.oacc-c-c++-common/* changes.
> --- a/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-79.c
> +++ b/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-79.c
> @@ -114,6 +114,7 @@ main (int argc,
Hi Guys,
Looks good to me. Independently, do you see a reason not to disable the
old demangler entirely?
>> * How likely is it that there are old toolchain in use out there that
>> still
>> use the v2 mangling ?
> GCC 3.0 and up used the new (Itanium C++ ABI) mangling, 2.95
On 12/4/18 4:53 PM, Segher Boessenkool wrote:
> Okay, so you make -mabi={ibm,ieee}longdouble be valid options only if
> there is -mlong-double-128. Could you add that to the documentation then
> please?
Done.
>> Is this ok for mainline once bootstrap and regtesting come back clean?
>
> Okay
Hi,
>> Ultimately, the best solution here will probably depend on which we
>> think is more likely, copysign or the example I give above.
> I'd tend to suspect we'd see more pure integer bit twiddling than the
> copysign stuff.
All we need to do is to clearly separate the integer and FP/SIMD
On 12/7/18 11:48 AM, Wilco Dijkstra wrote:
> Hi,
>
>>> Ultimately, the best solution here will probably depend on which we
>>> think is more likely, copysign or the example I give above.
>> I'd tend to suspect we'd see more pure integer bit twiddling than the
>> copysign stuff.
>
> All we need
On Tue, 2018-12-04 at 18:31 -0500, Jason Merrill wrote:
> On 12/3/18 5:10 PM, Jeff Law wrote:
> > On 11/19/18 9:51 AM, David Malcolm wrote:
[...]
> > Well, you probably know my biggest worry with this -- the
> > unwrappign
> > wack-a-mole problem. It looks like additional memory usage is
> >
On Fri, 7 Dec 2018 at 14:30, Rainer Orth wrote:
>
> When trying to rebuild libphobos with -g3 -O0 for better debugging, I
> noticed that GDCFLAGS weren't passed down as expected. It turned out
> that they are missing from AM_MAKEFLAGS. After I fixed this, the only
> file still compiled with -g
On Nov 12, 2018, Alexandre Oliva wrote:
> I'm having second thoughts on specifying external files with a
> full pathname, though, as it might lead to accidental GPL violations.
Here's a patch that takes the multilib list file from gcc/config/arm.
Any objections, further requests or advice,
On Sun, 2 Dec 2018 at 18:23, Gerald Pfeifer wrote:
>
> Hi Iain,
>
> On Mon, 12 Nov 2018, Iain Buclaw wrote:
> > As suggested, this adds an announcement of the D front end addition
> > to the news items on the GCC home page, and from what I can tell, the
> > relevant pages where the language
On Fri, 7 Dec 2018, Iain Buclaw wrote:
> After pushing, it was noticed that there was a small misspelling that
> went unnoticed. I've committed the correction as I don't think
> there'll be any objection to the change.
Indeed. Obvious changes and ones within your domain (so release
notes for
Hi Torbjorn,
Just some formatting nitpicking:
On Tue, Nov 27, 2018 at 07:45:59PM +, Torbjorn SVENSSON wrote:
> diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
> index 38e27a50a1e..e61ddc3260b 100644
> --- a/gcc/doc/invoke.texi
> +++ b/gcc/doc/invoke.texi
> @@ -6456,7 +6456,7 @@ Warn
Hi,
ICE in PR 88214 happens because a type-mismatch in K C code makes
IPA-CP analysis call ao_ref_init_from_ptr_and_size on an integer
SSA_NAME, this function in turn constructs a temporary MEM_REF based on
that integer SSA_NAME and then later on call_may_clobber_ref_p_1 treats
the MEM_REF base
When using the unpredicated all-register forms of FADD, FSUB and FMUL,
the rtl patterns would still have the predicate operand we created for
the other forms. This patch splits the patterns after reload in order
to get rid of the predicate, like we already do for WHILE.
Tested on
On 12/7/18 6:36 AM, Richard Biener wrote:
On Thu, Dec 6, 2018 at 10:22 PM Jason Merrill wrote:
On Thu, Dec 6, 2018 at 11:14 AM Jason Merrill wrote:
Looks good to me. Independently, do you see a reason not to disable the
old demangler entirely?
Like so. Does anyone object to this?
Hi,
debugging a problem with an older GCC (4.6). I've seen RTXs using
ZERO_EXTRACT LHS operands on MEMs as in:
(insn 7 6 0 (set (zero_extract:DI (mem/s/c:QI (plus:DI (reg/f:DI 39
virtual-stack-vars)
(const_int -5 [0xfffb])) [0+0 S1 A8])
(const_int 24
On 07/12/2018 15:52, Jeff Law wrote:
> As I suggested in the BZ, this patch rejects constants with just the
> high bit set for the recently added "bfxil" pattern. As a result we'll
> return to using "bit" for the test in the BZ.
>
> I'm not versed enough in aarch64 performance tuning to know if
> "Pedro" == Pedro Alves writes:
Pedro> I would say that it's very, very unlikely, and not worth it of the
Pedro> maintenance burden.
Agreed, and especially true for the more unusual demanglings like Lucid
or EDG.
On the gdb side perhaps we can get rid of "demangle-style" now. It
probably
On Tue, Dec 4, 2018 at 4:40 PM Bin.Cheng wrote:
>
> On Thu, Nov 29, 2018 at 12:20 AM Jan Hubicka wrote:
> >
> > > On Tue, Nov 20, 2018 at 6:55 PM bin.cheng
> > > wrote:
> > > >
> > > > Sender:Jan Hubicka
> > > > Sent at:2018 Nov 5 (Mon) 22:21
> > > > To:Richard Biener
> > > > Cc:bin.cheng ;
The following fixes PR63184 by using tree-affine to resolve pointer
comparisons. Instead of trying to stick this into a match.pd pattern
the following does this in the more constrained forwprop environment.
I've only implemented the cases where the comparison resolves to a
compile-time value,
Hi Ian,
> This libgo patch by Cherry Zhang adds support for precise stack
> scanning to the Go runtime. This uses per-function stack maps stored
> in the exception tables in the language-specific data area. The
> compiler needs to generate these stack maps; currently this is only
> done by a
On Thu, 6 Dec 2018, Martin Sebor wrote:
> On 12/6/18 2:26 PM, Jakub Jelinek wrote:
> > On Thu, Dec 06, 2018 at 01:21:58PM -0700, Martin Sebor wrote:
> > > Bug 88372 - alloc_size attribute is ignored on function pointers
> > > points out that even though the alloc_size attribute is accepted
> > >
On Thu, 6 Dec 2018, Martin Sebor wrote:
> On 12/5/18 7:58 AM, Richard Biener wrote:
> > On Wed, 5 Dec 2018, Jeff Law wrote:
> >
> > > On 12/4/18 6:16 AM, Richard Biener wrote:
> > > >
> > > > This tries to make bugs like that in PR88317 harder to create by
> > > > introducing a bitmap_release
73 matches
Mail list logo
