On Fri, 6 Sep 2019, Martin Liška wrote:
I've been working on transition of cond expressions to match.pd.
With my changes I noticed there's one wrong pattern that leads to:
Transforming _6 > _7 & _6 < _7 into 0
...
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/vector-compare-3.c:20:1:
Hi,
this fixes PR 91684, where an only 4-byte aligned memory is used with movdi,
which is formally invalid for strict alignment, but okay for prefer_ldrd_strd
targets.
Boot-strapped and reg-tested on arm-linux-gnueabihf.
Patch was approved via BZ.
Applied to trunk.
Thanks
Bernd.
2019-09-06 Be
On Fri, Sep 6, 2019 at 5:14 PM Segher Boessenkool
wrote:
>
> On Fri, Sep 06, 2019 at 04:42:58PM -0700, Nick Desaulniers via gcc-patches
> wrote:
> > Just to prove my point about version checks being brittle, it looks
> > like Rasmus' version check isn't even right. GCC supported `asm
> > inline`
On Fri, Sep 06, 2019 at 04:42:58PM -0700, Nick Desaulniers via gcc-patches
wrote:
> On Fri, Sep 6, 2019 at 3:56 PM Segher Boessenkool
> wrote:
> Oh, I misunderstood. I see your point. Define the symbol as a number
> for what level of output flags you support (ie. the __cplusplus
> macro).
That
Thanks to Andreas Schwab for the pointer on how to fix this properly.
This re-enables -msave-restore for shared libraries, and uses the
t-slibgcc-libgcc file to get the save-restore routines included directly
in shared libraries so that we don't need to indirect through the PLT
to reach them, which
On Fri, Sep 6, 2019 at 3:56 PM Segher Boessenkool
wrote:
>
> On Fri, Sep 06, 2019 at 03:35:02PM -0700, Nick Desaulniers wrote:
> > On Fri, Sep 6, 2019 at 3:03 PM Segher Boessenkool
> > wrote:
> > > And if instead you tested whether the actual feature you need works as
> > > you need it to, it wou
On Sat, Aug 31, 2019 at 1:08 AM Andreas Schwab wrote:
> I think the problem is that riscv needs to use t-slibgcc-libgcc so that
> libgcc_s.so is a linker script.
Yes, thanks, that fixes the problem and works well. I've got a patch
using this solution now.
Jim
Just a heads up that I tested the patch with Glibc and the kernel.
It exposes some of the same "abuses" of (near) zero-length arrays
as the most recent improvement in this area. In glibc, it
complains about code in fileops.c, iofwide.c, libc-tls.c, and
rtld.c. The ones I looked at all look like
On Fri, Sep 06, 2019 at 03:35:02PM -0700, Nick Desaulniers wrote:
> On Fri, Sep 6, 2019 at 3:03 PM Segher Boessenkool
> wrote:
> > And if instead you tested whether the actual feature you need works as
> > you need it to, it would even work fine if there was a bug we fixed that
> > breaks things f
On Fri, Sep 6, 2019 at 3:03 PM Segher Boessenkool
wrote:
>
> On Fri, Sep 06, 2019 at 11:14:08AM -0700, Nick Desaulniers wrote:
> > Here's the case that I think is perfect:
> > https://developers.redhat.com/blog/2016/02/25/new-asm-flags-feature-for-x86-in-gcc-6/
> >
> > Specifically the feature tes
On Fri, Sep 06, 2019 at 11:14:08AM -0700, Nick Desaulniers wrote:
> Here's the case that I think is perfect:
> https://developers.redhat.com/blog/2016/02/25/new-asm-flags-feature-for-x86-in-gcc-6/
>
> Specifically the feature test preprocessor define __GCC_ASM_FLAG_OUTPUTS__.
>
> See exactly how
This isn't used since 2018. (It's a remnant of paired single support).
Committing to trunk.
Segher
2019-09-06 Segher Boessenkool
* config/rs6000/rs6000.md (unspec): Delete UNSPEC_MV_CR_OV.
---
gcc/config/rs6000/rs6000.md | 1 -
1 file changed, 1 deletion(-)
diff --git a/gcc/con
This isn't used since 2012. (It's a remnant of RIOS support).
Committing to trunk.
Segher
2019-09-06 Segher Boessenkool
* config/rs6000/rs6000.c (rs6000_rtx_costs) : Delete.
* config/rs6000/rs6000.md (unspec): Delete UNSPEC_FRSP.
---
gcc/config/rs6000/rs6000.c | 12
On Thu, Sep 5, 2019 at 10:53 AM Uros Bizjak wrote:
>
> On Thu, Sep 5, 2019 at 7:47 AM Hongtao Liu wrote:
> >
> > Change cost from 2->6 got
> > -
> > 531.deepsjeng_r 9.64%
> > 548.exchange_r 10.24%
> > 557.xc_r 7.99%
> > 508.namd_r 1.08%
> > 527.cam4_r 6
Recent enhancements to -Wstringop-overflow improved the warning
to the point that it detects a superset of the problems -Warray-
bounds is intended detect in character accesses. Because both
warnings detect overlapping sets of problems, and because the IL
they work with tends to change in subtle
It's tiresome to have to look in insn-emit.c to see where some split
came from, so let's print that info to the dump file as well. But
don't print the full path, just the basename, for greater readability.
Testing on powerpc64-linux {-m32,-m64}. Is this okay for trunk if that
succeeds?
Segher
I've committed a patch to update libgo to the Go 1.13beta1 release.
As is usual with these updates, the patch is too large to include
here; I've included the diffs of the various GCC-specific configury
and other files. Bootstrapped and ran Go testsuite on
x86_64-pc-linux-gnu. Committed to mainlin
On Fri, Sep 6, 2019 at 9:39 AM Jakub Jelinek wrote:
>
> On Fri, Sep 06, 2019 at 11:30:28AM -0500, Segher Boessenkool wrote:
> > On Fri, Sep 06, 2019 at 05:13:54PM +0200, Miguel Ojeda wrote:
> > > On Fri, Sep 6, 2019 at 2:23 PM Segher Boessenkool
> > > wrote:
> > > > I can't find anything with "fe
On Fri, 6 Sep 2019 at 11:09, Christophe Lyon wrote:
>
> On Fri, 6 Sep 2019 at 10:28, Kyrill Tkachov
> wrote:
> >
> >
> > On 9/6/19 9:01 AM, Christophe Lyon wrote:
> > > On Fri, 19 Jul 2019 at 11:00, Kyrill Tkachov
> > > wrote:
> > >>
> > >> On 5/15/19 1:39 PM, Christophe Lyon wrote:
> > >>> Sin
I've just backported these from mainline. They add the Vega 20 gfx906
architecture and multilib.
Andrew
Document -march=gfx906 option.
2019-06-07 Andrew Stubbs
gcc/
* doc/invoke.texi (AMD GCN Options): Add gfx906.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 3103f86ce98..
On Fri, Sep 6, 2019 at 6:30 PM Segher Boessenkool
wrote:
>
> (Which isn't the C++ standard yet, okay).
At this stage, it pretty much is. It is basically bug fixing at this point.
> No, that is not what it does. A user defines such a macro, and that
> makes the library change behaviour.
That is
On Fri, Sep 06, 2019 at 11:30:28AM -0500, Segher Boessenkool wrote:
> On Fri, Sep 06, 2019 at 05:13:54PM +0200, Miguel Ojeda wrote:
> > On Fri, Sep 6, 2019 at 2:23 PM Segher Boessenkool
> > wrote:
> > > I can't find anything with "feature" and "macros" in the C++ standard,
> > > it's "predefined m
Current IPA only supports a simple kind of CP on by-ref argument, that is
directly defined with a constant value before callsite. This patch is meant
to extend CP to handle a more generalized form on by-ref argument
definition, which is similar to what have done on by-value argument. It will
cover
On Fri, Sep 06, 2019 at 05:13:54PM +0200, Miguel Ojeda wrote:
> On Fri, Sep 6, 2019 at 2:23 PM Segher Boessenkool
> wrote:
> > I can't find anything with "feature" and "macros" in the C++ standard,
> > it's "predefined macros" there I guess? In C, it is also "predefined
> > macros" in general, an
On 9/6/19 4:56 PM, Jakub Jelinek wrote:
On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
Ok, hopefully nobody is strongly against. I've just retested the
patch and installed it as r275450.
--- a/gcc/c-family/c.opt
+++
This patch uses a more appropriate local variable in the call to
localize_reductions in gimplify_omp_for, for better self-documentation.
Tested with offloading to AMD GCN. I will apply to the
openacc-gcc-9-branch shortly.
Julian
ChangeLog
gcc/
* gimplify.c (gimplify_omp_for): Us
This patch adds profiling support to the AMD GCN libgomp plugin, modeled
after the equivalent support in the NVPTX plugin. This gives a positive
test delta in AMD GCN offload testing.
I will apply to the openacc-gcc-9-branch shortly.
Julian
2019-09-06 Julian Brown
libgomp/
*
This patch adds some missing functions to the AMD GCN-specific target.c
file. This fixes several link errors in the testsuite.
Tested with offloading to AMD GCN. I will apply to the
openacc-gcc-9-branch shortly.
Julian
ChangeLog
libgomp/
* config/gcn/target.c (omp_pause_resource
> Am 06.09.2019 um 13:07 schrieb Richard Biener :
>
> On Thu, Sep 5, 2019 at 1:10 PM Ilya Leoshkevich wrote:
>>
>> Right now gimplifier does not allow VEC_COND_EXPR's condition to trap
>> and introduces a temporary if this could happen, for example, generating
>>
>> _5 = _4 > { 2.0e+0, 2.0e+0,
On Fri, Sep 6, 2019 at 7:21 AM Nathan Sidwell wrote:
> I expect to begin merging proper later this year
Yay!
Jason
On Fri, Sep 6, 2019 at 2:23 PM Segher Boessenkool
wrote:
>
> I can't find anything with "feature" and "macros" in the C++ standard,
> it's "predefined macros" there I guess? In C, it is also "predefined
> macros" in general, and there is "conditional feature macros".
They are introduced in C++20
On Fri, Sep 06, 2019 at 10:48:53AM -0400, Marek Polacek wrote:
> On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> > Ok, hopefully nobody is strongly against. I've just retested the
> > patch and installed it as r275450.
>
> --- a/gcc/c-family/c.opt
> +++ b/gcc/c-family/c.opt
> @@ -1
On 9/6/19 8:49 AM, Florian Weimer wrote:
> * Jeff Law:
>
>> On 9/6/19 2:57 AM, Florian Weimer wrote:
>>> Without this change, libstdc++ is built without futex symbols if GCC
>>> rejects implicit function declarations in default mode.
>>>
>>> Thanks,
>>> Florian
>>>
>>> config/ChangeLog:
>>>
>>> 20
* Jeff Law:
> On 9/6/19 2:57 AM, Florian Weimer wrote:
>> Without this change, libstdc++ is built without futex symbols if GCC
>> rejects implicit function declarations in default mode.
>>
>> Thanks,
>> Florian
>>
>> config/ChangeLog:
>>
>> 2019-09-06 Florian Weimer
>>
>> * futex.m4 (G
On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> Ok, hopefully nobody is strongly against. I've just retested the
> patch and installed it as r275450.
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
Used in Fix-
When exiting a function we need to ensure the shadow stack for this
function has no remaining colour. Without clearing the shadow stack
area for this function pointer checks to later function calls could
check untagged areas (such as parameters passed on the stack) against
a shadow stack area with
This patch in the series is just for demonstration, here we add stubs
where MTE would be implemented.
At the moment all implementations are dummies of some sort, the assembly
generated uses `mov` instead of `irg`, `add` instead of `addg`, and
`sub` instead of `subg`. This should mean the binaries
On entry to each function we colour the relevant shadow stack region for
each stack variable the colour to match the tag added to each pointer
for that variable.
We currently only use the library option for this, in the future inline
options will be added and configured in the same way as ASAN.
T
This patch makes sure that every pointer to a stack variable includes a
tag of some sort on it.
The way tagging works is:
1) For every new stack frame, a random tag is generated.
2) A base register is formed from the stack pointer value and this
random tag.
3) References to stack variab
This builds the library in the way designed for userspace rather than
for kernel space. This means intercepting allocation routines so they
now tag memory at the same time, and intercepting setjmp/longjmp so that
it clears tags on the stack when called.
libsanitizer/ChangeLog:
2019-09-06 Matthe
Here we use exactly the same mechanism as ASAN_MARK to poison/unpoison
variables on entry/exit of a block.
In order to simply use the exact same machinery we're using the same
internal functions until the SANOPT pass. This means that all handling
of ASAN_MARK is the same.
This has the negative th
Handle all builtin functions that we know use memory accesses.
This commit uses the machinery added for ASAN to identify builtin
functions that access memory.
The main differences between the approaches for HWASAN and ASAN are:
1) libhwasan intercepts much less builtin functions.
2) Alloca needs t
This is an analogous option to --bootstrap-asan to configure. It allows
bootstrapping GCC using HWASAN.
For the same reasons as for ASAN we have to avoid using the HWASAN
sanitizer when compiling libiberty and the lto-plugin.
Also add a function to query whether -fsanitize=hwaddress has been
pas
This adds the `hwasan` pass that puts HWASAN_CHECK internal functions
around memory accesses to check that tags in the pointer being used
match the tag stored in shadow memory for the memory region being used.
These internal functions are expanded into actual checks in the sanopt
pass that happens
When colouring shadow memory, we need to ensure that each tag granule
is only used by one variable at a time.
This is done by ensuring that ecah coloured variable is aligned to the
tag granule representation size and also ensure that the end of each
variable as an alignment boundary between the en
This patch does tries to tie libhwasan into the GCC build system in the
same way that the other sanitizer runtime libraries are handled.
libsanitizer/ChangeLog:
2019-09-06 Matthew Malcomson
* Makefile.am: Build libhwasan.
* Makefile.in: Build libhwasan.
* asan/Makefi
When using hwasan to tag parameters on the stack, we need to ensure that
the shadow stack is cleared upon exit of a function.
If this is not done, then accesses to an untagged memory region (e.g.
parameters passed on the stack) can end up being checked against a
shadow region that was coloured for
This flag can't be used at the same time as any of the other sanitizers.
We add an equivalent flag to -static-libasan in -static-libhwasan to
ensure static linking.
gcc/ChangeLog:
2019-09-06 Matthew Malcomson
* common.opt (static-libhwasan): New cli option.
* config/gnu-user.h
This makes the error reporting for loadN and storeN much better.
In this first draft these are the only functions I will be using and
hence this fix is very useful.
This is taken from upstream LLVM (change made in LLVM svn commit
351730), but is not a direct cherry-pick of a commit since the commi
On 9/6/19 2:57 AM, Florian Weimer wrote:
> Without this change, libstdc++ is built without futex symbols if GCC
> rejects implicit function declarations in default mode.
>
> Thanks,
> Florian
>
> config/ChangeLog:
>
> 2019-09-06 Florian Weimer
>
> * futex.m4 (GCC_LINUX_FUTEX): Include
This is a port of the LLVM-svn commit number 359914, it allows
compilation of the library without using interceptors.
This has been useful for testing.
libsanitizer/ChangeLog:
2019-09-06 Matthew Malcomson
* hwasan/hwasan_linux.cc: Allow compilation without
interceptors.
##
Hello,
This patch series is a WORK-IN-PROGRESS towards porting the LLVM hardware
address sanitizer (HWASAN) in GCC. The document describing HWASAN can be found
here http://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html.
The current patch series is far from complete, but I'm post
Introduce libsanitizer to GCC tree
Takes the libhwasan library from LLVM and puts it into our source tree
excluding the build system files.
Tieing the source files into our build system is done in a later commit.
We have taken the libsanitizer library from the same SVN revision as
the other sani
I've backported this patch from mainline.
Andrew
Tweak error message for mapped parameters.
2019-07-05 Andrew Stubbs
gcc/fortran/
* openmp.c (resolve_omp_clauses): Add custom error messages for
parameters in map clauses.
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 1c7b
On 9/6/19 12:53 PM, Richard Biener wrote:
> On Fri, 6 Sep 2019, Richard Biener wrote:
>
>> On Thu, 5 Sep 2019, Barnaby Wilks wrote:
>>
>>> Hello,
>>>
>>> This patch changes a match.pd expression so that binary math expressions
>>> will not be done in the precision of it's widest type if
>>> -funsa
Hi.
I've been working on transition of cond expressions to match.pd.
With my changes I noticed there's one wrong pattern that leads to:
Transforming _6 > _7 & _6 < _7 into 0
...
/home/marxin/Programming/gcc/gcc/testsuite/c-c++-common/vector-compare-3.c:20:1:
error: the first argument of a ‘vec_c
Richard Biener wrote:
> On Tue, Sep 3, 2019 at 3:09 PM Ulrich Weigand wrote:
> > > If you read the C standards fine-print then yes. But people (or
> > > even the C frontend!) hardly get that correct since for example
> > > for
> > >
> > > struct __attribute__((packed)) { int i; } s;
> > >
> > > v
Ilya Leoshkevich writes:
> @@ -329,6 +332,34 @@ expand_vec_cmp_expr_p (tree value_type, tree mask_type,
> enum tree_code code)
>return false;
> }
>
> +/* Return TRUE iff vcond_optab/vcondu_optab support the given tree
> + comparison. */
Nit: better to use "true" rather than "TRUE" in m
* include/bits/range_access.h (ssize): Define for C++20.
* testsuite/24_iterators/range_access_cpp20.cc: New test.
* doc/xml/manual/status_cxx2020.xml: Update P1227R2 status.
* doc/html/*: Regenerate.
Tested x86_64-linux, committed to trunk.
commit 606b6138a44f1f
On Thu, Sep 05, 2019 at 08:18:02PM -0400, Michael Meissner wrote:
> On Thu, Aug 29, 2019 at 04:32:07PM -0500, Segher Boessenkool wrote:
> > This is not just for reload anymore, so please don't name it that. Renaming
> > things isn't hard, this isn't a public API or anything :-)
>
> This hasn't ju
[CCs trimmed]
On 9/6/19 2:58 AM, Martin Liška wrote:
Ok, hopefully nobody is strongly against. I've just retested the
patch and installed it as r275450.
Martin missed a couple of spots. Installing this. 1 bit freed!
nathan
--
Nathan Sidwell
2019-09-06 Nathan Sidwell
PR c++/91125
*
Ilya Leoshkevich writes:
> One of the next patches in series needs to frequently pass short-lived
> fake rtxes to the back-end in order to test its capabilities. In order
> to reduce the load on GC, it is beneficial to allocate these rtxes on
> stack.
>
> Provide the macro counterparts of gen_* f
Hi Jim,
On Thu, Sep 05, 2019 at 04:40:56PM -0700, Jim Wilson wrote:
> On Thu, Sep 5, 2019 at 3:03 PM Segher Boessenkool
> wrote:
> > My big question is why do other targets not have this problem? Or what
> > is it they do differently?
>
> RISC-V doesn't have convenient sign/zero extend instruct
Current IPA only supports a simple kind of CP on by-ref argument, that is
directly defined with a constant value before callsite. This patch is meant to
extend CP to handle a more generalized form on by-ref argument definition,
which is similar to what have done on by-value argument. It will cov
On Thu, 5 Sep 2019 16:01:19 +0100
Julian Brown wrote:
> On Thu, 5 Sep 2019 21:52:00 +0800
> Chung-Lin Tang wrote:
>
> > On 2019/9/5 9:45 AM, Julian Brown wrote:
> > > Much of omp-sese.c originates from code written for NVPTX by
> > > Nathan Sidwell (adapted to work on gimple instead of RTL) -
On Thu, Sep 05, 2019 at 05:52:44PM +0200, Miguel Ojeda wrote:
> On Thu, Sep 5, 2019 at 3:45 PM Segher Boessenkool
> wrote:
> >
> > [ That's not what a feature test macro is; a feature test macro allows the
> > user to select some optional behaviour. Things like _GNU_SOURCE. ]
>
> Yes and no.
This patch fixes a tree-checking failure with the recently-applied patch
on the openacc-gcc-9-branch to localize reductions.
Tested with offloading to NVPTX. I will apply shortly.
Julian
ChangeLog
gcc/
* gimplify.c (gimplify_omp_workshare): Use OMP_CLAUSES, OMP_BODY
inst
This patch fixes a build failure for NVPTX on the
openacc-gcc-9-branch. The algorithm to calculate single-entry,
single-exit (SESE) regions has been moved to generic code so it can
(so far, potentially) be shared with other targets. Some name clashes
have been fixed and other minor cleanups have be
Hi,
+(simplify
+ (convert
+(rshift
+ (mult
> is the outer convert really necessary? That is, if we change
> the simplification result to
Indeed that should be "convert?" to make it optional.
> Is the Hamming weight popcount
> faster than the libgcc table-based approach? I wonder if
On 9/5/19 5:55 PM, Richard Earnshaw (lists) wrote:
> On 03/09/2019 21:45, Bernd Edlinger wrote:
>> Hi,
>>
>> due to the introduction of unaligned_loaddi and unaligned_storedi,
>> two test cases show some regression as PR 91614 points out.
>>
>> I would like to change the test expectations if these
On Wed, Sep 04, 2019 at 01:26:27PM -0400, Michael Meissner wrote:
[snip]
> So to keep other passes from 'improving' things, I opted to do the pass as the
> last pass before final.
If the problem is that you do not properly analyse dependencies between
insns, well, fix that?
If this really needs
On Fri, 6 Sep 2019, Richard Biener wrote:
> On Thu, 5 Sep 2019, Barnaby Wilks wrote:
>
> > Hello,
> >
> > This patch changes a match.pd expression so that binary math expressions
> > will not be done in the precision of it's widest type if
> > -funsafe-math-optimizations is enabled.
> >
> > Th
>
> * tree-ssa-alias.c (nonoverlapping_component_refs_since_match_p):
> Rename to ...
> (nonoverlapping_refs_since_match_p): ... this; handle also
> ARRAY_REFs.
> (alias_stats): Update stats.
> (dump_alias_stats): Likewise.
> (cheap_array_ref_low_bound): N
On 9/6/19 12:47 PM, Richard Earnshaw (lists) wrote:
> On 06/09/2019 11:28, Bernd Edlinger wrote:
>> Hi!
>>
>> It was pointed out in the PR that the test case fails on big endian
>> targets.
>>
>> This is probably obvious, since the test case scans the assembler
>> output for vld1.32, vst1.32, vldr
This patch
1) deletes DECL_CONSTRUCTION_VTABLE_P. It is checked in exactly one
place, but that place is unreachable. When we set D_C_V_P, we also set
the visibility to internal. When we check it, we've already bailed out
if the visibility was set.
2) Move DECL_NON_TRIVIALLY_INITIALIZED_P
On Thu, Sep 5, 2019 at 1:10 PM Ilya Leoshkevich wrote:
>
> One of the next patches in series needs to frequently pass short-lived
> fake rtxes to the back-end in order to test its capabilities. In order
> to reduce the load on GC, it is beneficial to allocate these rtxes on
> stack.
>
> Provide t
On Thu, Sep 5, 2019 at 1:10 PM Ilya Leoshkevich wrote:
>
> Right now gimplifier does not allow VEC_COND_EXPR's condition to trap
> and introduces a temporary if this could happen, for example, generating
>
> _5 = _4 > { 2.0e+0, 2.0e+0, 2.0e+0, 2.0e+0 };
> _6 = VEC_COND_EXPR <_5, { -1, -1, -1,
This patch is an RFC to invite comments as to whether the approach
to solving the problem is a suitable one for upstream GCC, or whether
there are alternative approaches that would be recommended.
Motivation
--
We have observed that in some cases the estimation of callee growth for
inlini
On Fri, Sep 6, 2019 at 10:11 AM Andreas Krebbel wrote:
>
> Hi,
>
> since this caused a critical performance regression in the OpenJ9 byte code
> interpreter after
> migrating from GCC 4.8 to GCC 7 I would like to backport this patch also to
> GCC 8 and 9 branch.
>
> Ok - after bootstrap and regr
On 06/09/2019 11:28, Bernd Edlinger wrote:
Hi!
It was pointed out in the PR that the test case fails on big endian
targets.
This is probably obvious, since the test case scans the assembler
output for vld1.32, vst1.32, vldr and vstr, but these are never
generated for -mbig-endian.
So added dg-
On Tue, Sep 3, 2019 at 3:09 PM Ulrich Weigand wrote:
>
> Richard Biener wrote:
> > On Tue, Sep 3, 2019 at 1:56 PM Ulrich Weigand wrote:
> > > combined with the fact that get_object_alignment_2 actually itself
> > > uses type alignment if we have an actual memory object:
> > > /* When EXP is
Hi Ilya,
On Thu, Sep 05, 2019 at 01:10:14PM +0200, Ilya Leoshkevich wrote:
> z13 supports only non-signaling vector comparisons. This means we
> cannot vectorize LT, LE, GT, GE and LTGT when compiling for z13. Notify
> middle-end about this using more restrictive operator predicate in
> vcond.
Hi!
It was pointed out in the PR that the test case fails on big endian
targets.
This is probably obvious, since the test case scans the assembler
output for vld1.32, vst1.32, vldr and vstr, but these are never
generated for -mbig-endian.
So added dg-require-effective-target arm_little_endian.
On Thu, Sep 5, 2019 at 6:13 PM Caroline Tice via gcc-patches
wrote:
>
> Yesterday I submitted a patch that disallows using vtable verfication
> with LTO (they don't work
> properly together), but I missed fixing the flags for one testcase.
> This patch fixes that omission.
>
> Testing: Tescase pas
On Thu, 5 Sep 2019, Barnaby Wilks wrote:
> Hello,
>
> This patch changes a match.pd expression so that binary math expressions
> will not be done in the precision of it's widest type if
> -funsafe-math-optimizations is enabled.
>
> This patch has been extracted from
> https://gcc.gnu.org/ml/gcc
On Thu, Sep 05, 2019 at 05:38:18PM -0500, Segher Boessenkool wrote:
> On Thu, Sep 05, 2019 at 04:48:28PM -0400, Michael Meissner wrote:
> > > I wouldn't use "ep" for *non*-pcrel. The new constraints/predicates don't
> > > need to do everything in a C block. Looks good otherwise.
> >
> > Any part
On Thu, Sep 5, 2019 at 5:35 PM Dmitrij Pochepko
wrote:
>
> This patch adds matching for Hamming weight (popcount) implementation. The
> following sources:
>
> int
> foo64 (unsigned long long a)
> {
> unsigned long long b = a;
> b -= ((b>>1) & 0xULL);
> b = ((b>>2) & 0x
On 24.07.2019. 20:57, Jeff Law wrote:
> On 7/17/19 2:29 AM, Dragan Mladjenovic wrote:
>>
>>
>> On 09.07.2019. 23:21, Jeff Law wrote:
>>> On 7/9/19 2:06 PM, Dragan Mladjenovic wrote:
This patch prevents merging of CALL instructions that that have different
REG_CALL_DECL notes attached to t
On Fri, Sep 06, 2019 at 10:57:06AM +0200, Florian Weimer wrote:
> Without this change, libstdc++ is built without futex symbols if GCC
> rejects implicit function declarations in default mode.
>
> Thanks,
> Florian
>
> config/ChangeLog:
>
> 2019-09-06 Florian Weimer
>
> * futex.m4 (GCC
On 06/09/2019 11:15, Bernd Edlinger wrote:
On 9/4/19 2:53 PM, Richard Earnshaw (lists) wrote:
Index: gcc/testsuite/gcc.target/arm/unaligned-argument-2.c
===
--- gcc/testsuite/gcc.target/arm/unaligned-argument-2.c (Revision 0)
+++
On 9/4/19 2:53 PM, Richard Earnshaw (lists) wrote:
> Index: gcc/testsuite/gcc.target/arm/unaligned-argument-2.c
> ===
> --- gcc/testsuite/gcc.target/arm/unaligned-argument-2.c (Revision 0)
> +++ gcc/testsuite/gcc.target/arm/unaligne
On 9/5/19 3:17 PM, Richard Biener wrote:
> On Tue, 16 Jul 2019, Li Jia He wrote:
>
>> Hi,
>>
>> I made some changes based on the recommendations. Would you like to
>> help me to see it again ? Sorry, it took so long time to provide the
>> patch.
>>
>> Note: 1. I keep the code for and_compa
On 9/5/19 3:01 PM, Richard Biener wrote:
> On Tue, 16 Jul 2019, Li Jia He wrote:
>
>> Hi,
>>
>> I made some changes based on the recommendations. Would you like to
>> help me to see it again ? Sorry, it took so long time to provide the
>> patch.
>>
>> Note: 1. I keep the code for and_compa
On 06/09/19 10:57 +0200, Florian Weimer wrote:
Without this change, libstdc++ is built without futex symbols if GCC
rejects implicit function declarations in default mode.
Thanks,
Florian
config/ChangeLog:
2019-09-06 Florian Weimer
* futex.m4 (GCC_LINUX_FUTEX): Include for the sys
The cmp_and and cmp_ior patterns were missing a couple of short-it
variants for thumb2, where the comparisons are all using registers some
of which were HI_REGS.
* config/arm/arm.md (cmp_and): Add short-it variant for thumb2 with
high regs.
(cmp_ior): Likewise.
Committe
Hi.
This is one obvious documentation update, where we have tuples
that use ',' as the element separator. And we separate these tuples
with ',' as well.
Martin
gcc/ChangeLog:
2019-08-30 Martin Liska
* doc/match-and-simplify.texi: Separate tuples with ;.
---
gcc/doc/match-and-simpli
On Fri, 6 Sep 2019 at 10:28, Kyrill Tkachov wrote:
>
>
> On 9/6/19 9:01 AM, Christophe Lyon wrote:
> > On Fri, 19 Jul 2019 at 11:00, Kyrill Tkachov
> > wrote:
> >>
> >> On 5/15/19 1:39 PM, Christophe Lyon wrote:
> >>> Since FDPIC currently supports arm and thumb-2 modes only, these tests
> >>> fa
Without this change, libstdc++ is built without futex symbols if GCC
rejects implicit function declarations in default mode.
Thanks,
Florian
config/ChangeLog:
2019-09-06 Florian Weimer
* futex.m4 (GCC_LINUX_FUTEX): Include for the syscall
function.
libgomp/ChangeLog, libitm
On 06/09/2019 08:42, Bernhard Reutner-Fischer wrote:
On 5 September 2019 18:07:25 CEST, Andrew Stubbs wrote:
I just committed the attached patch to the openacc-gcc-9-branch.
+ /* Store that requires input registers are not overwritten by
+following instruction. */
+
On Fri, 6 Sep 2019, Jakub Jelinek wrote:
> Hi!
>
> On Thu, Sep 05, 2019 at 08:40:35PM +0200, Bernhard Reutner-Fischer wrote:
> > >@@ -2771,6 +2771,11 @@ load_register_parameters (struct arg_dat
> > > poly_int64 size = 0;
> > > HOST_WIDE_INT const_size = 0;
> > > rtx_insn *before_arg =
1 - 100 of 107 matches
Mail list logo
