On Thu, 4 Oct 2018, David Malcolm wrote:
> On Thu, 2018-10-04 at 12:52 +0200, Richard Biener wrote:
> > On Fri, 28 Sep 2018, David Malcolm wrote:
>
> [...snip...]
>
> > >
> > > OK for trunk?
> >
> > OK. My question on 2/3 leaves Richard time to comment.
> >
> > Maybe you can tackle the issue
On Thu, Oct 04, 2018 at 05:36:58PM +, Joseph Myers wrote:
> On Thu, 4 Oct 2018, Stafford Horne wrote:
>
> > +or1k-*-linux*)
> > + tmake_file="$tmake_file or1k/t-or1k"
> > + tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl t-softfp"
> > + md_unwind_header=or1k/linux-unwind.h
> > + ;;
Add a configure knob for mingw32 and 64 toolchains to default passing
--large-address-aware to the linker, when creating 32-bit binaries.
-Wl,--disable-large-address-aware can still reverse its effects.
I've tested this with cross i686-pc-mingw32-gcc and
x86_64-w64-mingw64-gcc (is this the usual t
With
gcc -O2 -fPIC -flto -g -c -o a.o a.c
gcc -O2 -fPIC -flto -g -mavx -c -o b.o b.c
gcc -shared -O2 -fPIC -flto -g -o lib1.so a.o b.o
LTO correctly generates AVX for b.o and SSE for a.o. But the GCC driver
passes -msse2avx to assembler, which encodes SSE instructions as AVX
instructions. W
Hi!
So i just added archive handling to ease looking at more than just the
plain frontends, applied as r264856.
You can now use the exact files passed to the driver when linking e.g. cc1.
We link libcommon.a twice? Didn't look.
e.g.:
me@there:.../gcc$ /scratch/src/gcc-trunk/contrib/unused_functi
Ping. If I don't hear any objections I will consider this patch as
obvious since the only change is to add noinline attributes to the
tests.
Steve Ellcey
sell...@cavium.com
On Wed, 2018-09-26 at 09:21 -0700, Steve Ellcey wrote:
> A patch for PR tree-optimized/71625 caused regressions in the
> g
Andrew Stubbs writes:
> On 17/09/18 10:18, Richard Sandiford wrote:
>> The idea looks good to me FWIW, but you can't use curr_static_id for
>> the state, since that's a static description of the .md pattern rather
>> than data about this particular instance.
>
> I clearly misunderstood what that w
On 10/03/2018 10:09 AM, Peter Bergner wrote:
Here is another updated PATCH 2 that is the same as the previous version,
but includes the modification to the expected output of i386/pr49095.c
test case, as H.J. has confirmed the code gen changes we are seeing on
are a good thing.
This patch com
... and reorder insn patterns a bit.
2018-10-04 Uros Bizjak
* config/i386/i386.md (*fop__2_i387): Macroize insn
from *fop__2_i387 and *fop_xf_2_i387 using
X87MODEF mode iterator.
(*fop__3_i387): Macroize insn from
*fop__3_i387 and *fop_xf_3_i387 using
X87MODEF mode iter
On Thu, 4 Oct 2018, Jeff Law wrote:
> > I doubt you could prove that without LTO of the whole program because an
> > errno value set by a libm function call could always be checked in the
> > caller of whatever function is being compiled.
> Right, but if you have a series of calls like
>
>
>
On Thu, 4 Oct 2018, Jeff Law wrote:
> With the natural tensions around warning early vs warning late the
> warning analysis phase may choose to mark statements in various ways
> rather than issuing the warning at that time. ie, it might choose to
> mark the statement with the set of potential iss
On Oct 3, 2018, at 8:48 PM, Stafford Horne wrote:
>
> -mm-dd Stafford Horne
> Richard Henderson
>
> gcc/testsuite/ChangeLog:
>
> * gcc.c-torture/execute/20101011-1.c: Adjust for OpenRISC.
> * gcc.dg/20020312-2.c: Likewise.
> * gcc.dg/attr-alloc_size-11.c: Li
On 10/4/18 11:29 AM, Joseph Myers wrote:
> On Wed, 3 Oct 2018, Jeff Law wrote:
>
>> That led me to wonder if we could prove that for the majority of FP
>> intensive codes that even if the library set errno that nobody could
>> possibly be reading it, then we could in large part treat those builtin
On 9/13/18 4:01 AM, Andrew Stubbs wrote:
>
> The register that find_rename_reg is considering is SCC, which is one of
> the "special" registers. There is a short-cut in rename_chains for
> fixed registers, global registers, and frame pointers. It does not
> check HARD_REGNO_RENAME_OK.
I wonder i
On 9/3/18 8:48 AM, Vinay Kumar wrote:
> Hi Joseph,
>
>>> The documentation is of a new option, not of -Wreturn-type
> Done
>
>>> you should list the option as -Wno-prio-ctor-dtor when documenting
> Done
>
>>> You're not meant to have the literal text ", no ()" in the manual
> Sorry for the co
On Thu, 2018-10-04 at 12:52 +0200, Richard Biener wrote:
> On Fri, 28 Sep 2018, David Malcolm wrote:
[...snip...]
> >
> > OK for trunk?
>
> OK. My question on 2/3 leaves Richard time to comment.
>
> Maybe you can tackle the issue that -fopt-info-inline does
> nothing at the moment and see if
On 9/20/18 4:52 AM, Andrew Stubbs wrote:
> On 19/09/18 17:38, Andrew Stubbs wrote:
>> Here's an updated patch incorporating the RTL front-end changes. I had
>> to change from "repeated 2x" to "repeated x2" because the former is
>> not a valid C token, and apparently that's important.
>
> Here's a
On 10/3/18 11:58 AM, Martin Sebor wrote:
> The recent strnlen changes to detect reading past unterminated
> arrays introduced a couple of bugs:
>
> 1) ICE due to assuming that the strnlen argument necessarily
> refers to a known declaration under some conditions.
> 2) Failing to diagnose uses o
On Thu, 4 Oct 2018, Stafford Horne wrote:
> +or1k-*-linux*)
> + tmake_file="$tmake_file or1k/t-or1k"
> + tmake_file="$tmake_file t-softfp-sfdf t-softfp-excl t-softfp"
> + md_unwind_header=or1k/linux-unwind.h
> + ;;
> +or1k-*-*)
> + tmake_file="$tmake_file or1k/t-or1k"
> + t
On Wed, 3 Oct 2018, Jeff Law wrote:
> That led me to wonder if we could prove that for the majority of FP
> intensive codes that even if the library set errno that nobody could
> possibly be reading it, then we could in large part treat those builtin
> calls as -fno-math-errno (we'd mark them some
Richard Biener writes:
> On Fri, 28 Sep 2018, David Malcolm wrote:
>> This is v3 of the patch; previous versions were:
>> v2: https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00446.html
>> v1: https://gcc.gnu.org/ml/gcc-patches/2018-06/msg01462.html
>>
>> This patch introduces a class opt_proble
On October 4, 2018 6:35:57 PM GMT+02:00, David Malcolm
wrote:
>On Thu, 2018-10-04 at 12:45 +0200, Richard Biener wrote:
>> On Fri, 28 Sep 2018, David Malcolm wrote:
>>
>> > This patch introduces a verbosity level to dump messages:
>> > "user-facing" vs "internals".
>> >
>> > By default, message
On Thu, 2018-10-04 at 12:45 +0200, Richard Biener wrote:
> On Fri, 28 Sep 2018, David Malcolm wrote:
>
> > This patch introduces a verbosity level to dump messages:
> > "user-facing" vs "internals".
> >
> > By default, messages at the top-level dump scope are "user-facing",
> > whereas those that
Hi,
I'm working on some insn latency changes in the s390 backend and noticed
a regression in the SPEC2006 bzip2 test case that was due to some insns
being scheduled differently.
The sequence in short form before my change is
;; | insn | prio |
;; | 823 |1 | %r1=%r1+0x1
Hi!
On Thu, 20 Sep 2018 10:11:36 -0400, David Edelsohn wrote:
> I am pleased to announce that the GCC Steering Committee has
> appointed Thomas Schwinge as OpenACC Maintainer.
Thanks for your trust, after all these years. I'm happy to accept, and
will of course (continue to) work closely
On 10/04/2018 08:58 AM, Jeff Law wrote:
On 8/27/18 9:42 AM, Richard Biener wrote:
On Mon, Aug 27, 2018 at 5:32 PM Jeff Law wrote:
On 08/27/2018 02:29 AM, Richard Biener wrote:
On Sun, Aug 26, 2018 at 7:26 AM Jeff Law wrote:
On 08/24/2018 09:58 AM, Martin Sebor wrote:
The warning suppress
On 8/28/18 6:12 PM, Martin Sebor wrote:
>>> Sadly, dstbase is the PARM_DECL for d. That's where things are going
>>> "wrong". Not sure why you're getting the PARM_DECL in that case. I'd
>>> debug get_addr_base_and_unit_offset to understand what's going on.
>>> Essentially you're getting differen
On 8/27/18 9:42 AM, Richard Biener wrote:
> On Mon, Aug 27, 2018 at 5:32 PM Jeff Law wrote:
>>
>> On 08/27/2018 02:29 AM, Richard Biener wrote:
>>> On Sun, Aug 26, 2018 at 7:26 AM Jeff Law wrote:
On 08/24/2018 09:58 AM, Martin Sebor wrote:
> The warning suppression for -Wstringop-tr
> On 10/4/18 11:23 AM, Jan Hubicka wrote:
> >> Hi.
> >>
> >> That's new warnings that warns about ifunc having a function body.
> >> It provides following warning:
> >>
> >> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr87483.c: In function
> >> ‘g’:
> >> /home/marxin/Programming/gcc/gcc/tes
On 10/4/18 4:17 PM, Jeff Law wrote:
> On 10/4/18 7:56 AM, Martin Liška wrote:
>> Hi.
>>
>> When having a pair of target clones where foo calls bar, if the target
>> attribute are equal we can redirect the call and not use ifunc dispatcher.
>>
>> Patch survives regression tests on x86_64-linux-gnu.
On 10/04/2018 08:27 AM, Thomas Preudhomme wrote:
My bad, I used dg-cmp-results without verbosity which didn't show the
problem It starts to show it with -v -v, I'm not sure why. I'll have a
look right now and revert by the end of today if I cannot come up with
a fix. Does that sound ok?
Yes,
On 10/4/18 11:23 AM, Jan Hubicka wrote:
>> Hi.
>>
>> That's new warnings that warns about ifunc having a function body.
>> It provides following warning:
>>
>> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr87483.c: In function ‘g’:
>> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr87483.
On 10/4/18 11:29 AM, Kyrill Tkachov wrote:
> Hi Martin,
>
> On 18/07/18 16:49, Martin Liška wrote:
>> Hi.
>>
>> This patch improves aarch64 feature modifier hints.
>>
>> May I please ask ARM folks to test the patch?
>> Thanks,
>> Martin
>>
>
> I've bootstrapped and tested it on aarch64-none-linux
On 10/4/18 7:56 AM, Martin Liška wrote:
> Hi.
>
> When having a pair of target clones where foo calls bar, if the target
> attribute are equal we can redirect the call and not use ifunc dispatcher.
>
> Patch survives regression tests on x86_64-linux-gnu.
> Ready for trunk?
>
> Martin
>
> gcc/Ch
Successfully regrtested on x86_64-pc-linux-gnu.
OK for trunk?
gcc/testsuite/ChangeLog:
* lib/multiline.exp (proc dg-end-multiline-output): Check argument
count. If there's a 3rd argument, use dg-process-target on it,
bailing out, or recording expected failures as "maybe_x
-Wformat in the C++ FE doesn't work as well as it could:
(a) it doesn't report precise locations within the string literal, and
(b) it doesn't underline arguments for those arguments !CAN_HAVE_LOCATION_P,
despite having location wrapper nodes.
For example:
Wformat-ranges.C:32:10: warning: forma
On 10/4/18 2:58 AM, Richard Biener wrote:
> On Wed, 3 Oct 2018, Christophe Lyon wrote:
>
>> On Mon, 1 Oct 2018 at 11:36, Richard Biener wrote:
>>>
>>>
>>> The following typo-fix happens to fix a --param max-peel-branches limit
>>> caused missed peeling. The typo is present everywhere, the missed
Hi.
When having a pair of target clones where foo calls bar, if the target
attribute are equal we can redirect the call and not use ifunc dispatcher.
Patch survives regression tests on x86_64-linux-gnu.
Ready for trunk?
Martin
gcc/ChangeLog:
2018-10-04 Martin Liska
PR ipa/82625
On 04/10/18 14:25, Jeff Law wrote:
> On 10/4/18 6:37 AM, Richard Biener wrote:
>> On Thu, Oct 4, 2018 at 2:06 PM Joseph Myers wrote:
>>>
>>> On Thu, 4 Oct 2018, Richard Biener wrote:
>>>
The other issue is that we're treating -fno-math-errno as disabling
errno handling in general (not on
On 10/3/18 10:08 PM, Jeff Law wrote:
> Given the desire for reload to die and the difficulties testing this
> change on a reload target, I don't think mirroring this optimization in
> reload is necessary.
Right, it's good to have incentives to move away from reload to LRA.
Maybe we could add a few
On 10/4/18 6:37 AM, Richard Biener wrote:
> On Thu, Oct 4, 2018 at 2:06 PM Joseph Myers wrote:
>>
>> On Thu, 4 Oct 2018, Richard Biener wrote:
>>
>>> The other issue is that we're treating -fno-math-errno as disabling
>>> errno handling in general (not only for math functions). That would
>>
>> A
On Thu, 4 Oct 2018, Richard Biener wrote:
>
> The following fixes bogus differences in scalar iteration cost
> computed by the vectorizer when comparing 128 and 256 bit vectorizations.
> This was caused by the hook looking at the vector types mode even
> for kind == scalar_stmt and thus returning
On Thu, 4 Oct 2018, Richard Biener wrote:
> So it means that GCC may elide errno setting (by inlining a function for
> example) but otherwise assume nothing else?
Yes, on systems where libm functions do in fact set errno (but it can also
assume that only the actual errno variable is clobbered,
On Sun, 23 Sep 2018 10:48:52 +0200
Bernhard Reutner-Fischer wrote:
> On Sat, 22 Sep 2018 at 00:32, Julian Brown
> wrote:
>
> @@ -6218,13 +6221,20 @@ add_clause (gfc_symbol *sym, gfc_omp_map_op
> map_op) {
>gfc_omp_namelist *n;
>
> + if (!module_oacc_clauses)
> +module_oacc_clauses = g
Define _mm512_mask3_fmaddsub_round_pd with
__builtin_ia32_vfmaddsubpd512_mask, instead of
__builtin_ia32_vfmaddpd512_mask.
PR target/87517
* config/i386/avx512fintrin.h (_mm512_mask_fmaddsub_round_pd):
Defined with __builtin_ia32_vfmaddsubpd512_mask.
---
gcc/config/i386/av
On 9/18/18 10:00 AM, Martin Liška wrote:
> On 9/17/18 1:39 PM, Martin Liška wrote:
>> On 9/12/18 4:48 PM, Richard Biener wrote:
>>> On Wed, Sep 12, 2018 at 11:27 AM Martin Liška wrote:
On 9/11/18 5:08 PM, Alexander Monakov wrote:
> On Tue, 11 Sep 2018, Martin Liška wrote:
>> I've
On Thu, Oct 4, 2018 at 2:06 PM Joseph Myers wrote:
>
> On Thu, 4 Oct 2018, Richard Biener wrote:
>
> > The other issue is that we're treating -fno-math-errno as disabling
> > errno handling in general (not only for math functions). That would
>
> Also, is it treated as meaning the math functions
On Wed, 3 Oct 2018, Jeff Law wrote:
+/* Simplify cos(atan(x)) -> 1 / sqrt(x*x + 1). */
+ (for coss (COS)
+ atans (ATAN)
+ sqrts (SQRT)
+ (simplify
+ (coss (atans:s @0))
+ (rdiv {build_one_cst (type);}
+ (sqrts (plus (mult @0 @0) {build_one_cst (type);})
Don't we have th
On Tue, Oct 2, 2018 at 12:07 PM Eric Botcazou wrote:
>
> > so the fix is to simply not optimize here?
>
> Yes, we cannot turn a BIT_FIELD_REF with rev-storage into a VIEW_CONVERT_EXPR.
>
> > Are there correctness issues with the patterns we have for rev-storage? But
> > then some cases are let th
My bad, I used dg-cmp-results without verbosity which didn't show the
problem It starts to show it with -v -v, I'm not sure why. I'll have a
look right now and revert by the end of today if I cannot come up with
a fix. Does that sound ok?
Best regards,
Thomas
On Thu, 4 Oct 2018 at 12:31, H.J. Lu
On Thu, 4 Oct 2018, Richard Biener wrote:
>
> This tries to apply the same trick to sminmax reduction patterns
> as for the reduc_plus_scal ones, namely reduce %zmm -> %ymm -> %xmm
> first. On a microbenchmark this improves performance on Zen
> by ~30% for AVX2 and on Skylake-SP by ~10% for AVX5
On Thu, 4 Oct 2018, Richard Biener wrote:
> The other issue is that we're treating -fno-math-errno as disabling
> errno handling in general (not only for math functions). That would
Also, is it treated as meaning the math functions *do not set errno* (so a
load of errno (or of anything that mig
This tries to apply the same trick to sminmax reduction patterns
as for the reduc_plus_scal ones, namely reduce %zmm -> %ymm -> %xmm
first. On a microbenchmark this improves performance on Zen
by ~30% for AVX2 and on Skylake-SP by ~10% for AVX512 (for AVX2
there's no measurable difference).
I g
We've had string literal concatenation since we dropped K&R build
support. Let's use it to make things more readable.
Applying to trunk.
nathan
--
Nathan Sidwell
2018-10-04 Nathan Sidwell
* lang-specs.h: Use string contatenation, not line splicing.
Index: lang-specs.h
===
Hi Ian,
> Thanks for the note. This patch should fix the problem. Bootstrapped
> and ran Go tests on x86_64-pc-linux-gnu, both normally and pretending
> that the system had no memmem. Committed to mainline.
I've now verified the patch on i386-pc-solaris2.10: bootstrap restored.
Thanks.
On Wed, Oct 3, 2018 at 8:12 PM Vladimir Makarov wrote:
>
> On 10/03/2018 12:47 PM, Thomas Preudhomme wrote:
> > Best regards,
> >
> > Thomas
> >
> > never_reload_fixed_address_operand.patch
> >
> >
> > From 2831d8b886d92513c2d30d43a6a989d2bbd0ceee Mon Sep 17 00:00:00 2001
> > From: Thomas Preud'h
Hi Andreas,
> On Okt 01 2018, David Malcolm wrote:
>
>> Is there a link to the .log files somewhere so I can see the precise
>> messages in question? (e.g. are they all "loop versioned for
>> vectorization to enhance alignment"?).
>
> Yes, they are all the same message.
just for the record: I'm
On 04/10/18 07:37 +0200, François Dumont wrote:
Here is the cleanup version.
* include/bits/stl_tree.h
(_Rb_tree_iterator<>::operator==): Make inline friend.
(_Rb_tree_iterator<>::operator!=): Likewise.
(_Rb_tree_const_iterator<>::operator==): Likewise.
(_Rb_tree_const_iterat
On Fri, 14 Sep 2018 at 22:49, Jeff Law wrote:
>
> On 8/28/18 5:26 AM, Prathamesh Kulkarni wrote:
> > H
> > The attached patch extends malloc_candidate_p to handle multiple phis.
> > There's a lot of noise in the patch because I moved most of
> > malloc_candidate_p into
> > new function malloc_cand
On Fri, 28 Sep 2018, David Malcolm wrote:
> This patch introduces a verbosity level to dump messages:
> "user-facing" vs "internals".
>
> By default, messages at the top-level dump scope are "user-facing",
> whereas those that are in nested scopes are implicitly "internals",
> and are filtered ou
On Fri, 28 Sep 2018, David Malcolm wrote:
> Attempts to dump via -fopt-info from a plugin pass fail, due
> to the dfi->alt_state for such passes never being set.
>
> This is because the -fopt-info options were being set up per-pass
> during option-parsing (via gcc::dump_manager::opt_info_enable_p
Hi,
yesterday I didn't notice that we have a separate bug for a similar
issue affecting cp_parser_compound_requirement. Tested x86_64-linux.
Thanks, Paolo.
PS: while working on these issues, I noticed that somewhere else in the
concepts parsing bits we check the return value of cp_parser_req
The following fixes bogus differences in scalar iteration cost
computed by the vectorizer when comparing 128 and 256 bit vectorizations.
This was caused by the hook looking at the vector types mode even
for kind == scalar_stmt and thus returning vector operation costs
for things like add or negat
Hi Martin,
On 18/07/18 16:49, Martin Liška wrote:
Hi.
This patch improves aarch64 feature modifier hints.
May I please ask ARM folks to test the patch?
Thanks,
Martin
I've bootstrapped and tested it on aarch64-none-linux-gnu and I didn't see any
problems.
I like the functionality! It is de
> Hi.
>
> That's new warnings that warns about ifunc having a function body.
> It provides following warning:
>
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr87483.c: In function ‘g’:
> /home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr87483.c:5:35: warning:
> ‘alias’ attribute ignored
Hi.
That's new warnings that warns about ifunc having a function body.
It provides following warning:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr87483.c: In function ‘g’:
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/pr87483.c:5:35: warning:
‘alias’ attribute ignored because functio
On Wed, 3 Oct 2018, Christophe Lyon wrote:
> On Mon, 1 Oct 2018 at 11:36, Richard Biener wrote:
> >
> >
> > The following typo-fix happens to fix a --param max-peel-branches limit
> > caused missed peeling. The typo is present everywhere, the missed
> > peeling is a regression from GCC 7.
> >
>
On Thu, Oct 4, 2018 at 6:39 AM Jeff Law wrote:
>
> On 9/3/18 1:11 PM, Giuliano Augusto Faulin Belinassi wrote:
> > Fixed the issues pointed by the previous discussions. Closes PR86829.
> >
> > Adds substitution rules for sin(atan(x)) and cos(atan(x)), being
> > careful with overflow issues by cons
On Thu, Oct 4, 2018 at 1:10 AM Jeff Law wrote:
>
> On 9/4/18 9:27 AM, Wilco Dijkstra wrote:
> >
> > ping
> >
> >
> >
> >
> > From: Wilco Dijkstra
> > Sent: 18 June 2018 15:01
> > To: GCC Patches
> > Cc: nd; Joseph Myers
> > Subject: [PATCH v3] Change default to -fno-math-errno
> >
> >
> > GCC curr
On 10/3/18 6:56 PM, Jeff Law wrote:
> On 10/3/18 3:57 AM, Martin Liška wrote:
>> On 10/3/18 11:07 AM, Jan Hubicka wrote:
Hi.
There's one another ICE when calling fn_summary->get for a node
that's not present. Back-trace is:
(gdb) bt
#0 inline_to_all_callers (node
PING^4
On 9/19/18 8:02 PM, Martin Liška wrote:
> PING^3
>
> On 8/23/18 1:00 PM, Martin Liška wrote:
>> PING^2
>>
>> On 08/01/2018 03:56 PM, Martin Liška wrote:
>>> PING^1
>>>
>>> On 07/18/2018 05:49 PM, Martin Liška wrote:
Hi.
This patch improves aarch64 feature modifier hints.
>>>
On Tue, Oct 2, 2018 at 3:38 PM MCC CS wrote:
>
> Thanks a lot!
Well, thank you for the patch (and the patience...)!
Richard.
On Tue, Oct 2, 2018 at 4:18 PM Nathan Sidwell wrote:
>
> Ping?
I'm not sure this is the right kind of fix for sth that only triggers
with fat objects.
My suggestion is to watch the difference to the DIE tree(s) (including
the comdat ones) before early-LTO debug write-out (we already have
a dumpf
73 matches
Mail list logo
