Hello!
Attached patch fixes PR87928, where we ICE in ix86_compute_frame_layout in
gcc_assert (preferred_alignment >= STACK_BOUNDARY / BITS_PER_UNIT);
when __attribute__ ((sysv_abi) is used. When the testcase is compiled,
ix86_cfun_abi () returns SYSV_ABI due to function __attribute__
override,
On Tue, 6 Nov 2018 at 16:04, Richard Biener wrote:
>
> On Mon, Nov 5, 2018 at 3:11 PM Prathamesh Kulkarni
> wrote:
> >
> > On Mon, 5 Nov 2018 at 18:14, Richard Biener
> > wrote:
> > >
> > > On Mon, Nov 5, 2018 at 1:11 PM Prathamesh Kulkarni
> > > wrote:
> > > >
> > > > On Mon, 5 Nov 2018 at 15
On Mon, 5 Nov 2018 at 19:22, Ramana Radhakrishnan
wrote:
>
> On 26/10/2018 06:04, Prathamesh Kulkarni wrote:
> > Hi,
> > This is a rebased version of patch that adds a pattern to neon.md for
> > implementing division with multiplication by reciprocal using
> > vrecpe/vrecps with -funsafe-math-opti
On 11/07/2018 02:28 PM, Jeff Law wrote:
On 10/20/18 6:01 PM, Martin Sebor wrote:
The warning only triggers when the bound is less than or equal
to the length of the constant source string (i.e, when strncpy
truncates). So IIUC, your suggestion would defer folding only
such strncpy calls and
Hi!
On Thu, Nov 08, 2018 at 02:18:51PM -0600, Bill Schmidt wrote:
> We recently discovered that GCC is getting lucky with register allocation of
> some inline assembly code, despite invalid register constraints. In these
> two functions, a "wi" constraint (VSX valid for direct moves) was used for
Hi Fredrik,
Thank you for your submission. Your change looks very good to me, except
for a bunch of minor nits in your proposed ChangeLog entry.
> * gcc/config/mips/mips.c (mips_reorg_process_insns)
> (mips_option_override): Default to working around R5900
> errata only i
On 11/8/18 4:07 PM, Jeff Law wrote:
> On 11/7/18 7:17 PM, Peter Bergner wrote:
>> On 11/7/18 11:36 AM, Jeff Law wrote:
>>> OK with this change.
>>
>> Before I commit, how about I add the following test cases to test
>> both valid and invalid asm constraints? I think I have the reg
>> numbers for t
On 11/7/18 7:17 PM, Peter Bergner wrote:
> On 11/7/18 11:36 AM, Jeff Law wrote:
>> OK with this change.
>
> Before I commit, how about I add the following test cases to test
> both valid and invalid asm constraints? I think I have the reg
> numbers for the other architectures defined correctly.
This patch knocks off another old but trivial documentation bug, PR
36572. There are a couple more like this I'm going to squash too.
-Sandra
2018-11-08 Sandra Loosemore
PR other/36572
gcc/
* doc/invoke.texi (Optimize Options): Clarify default behavior
for -fno-sched-interblock and -fn
On 10/20/18 4:18 AM, Romain Geissler wrote:
> Hi,
>
> I would like to raise again the question of supporting -fuse-ld=ldd. A
> patch implementing it was already submitted in
> https://gcc.gnu.org/ml/gcc-patches/2016-06/msg01722.html by Davide
> Italiano. This patch still applies correctly to curre
On 11/8/18 4:00 AM, Alexandre Oliva wrote:
> When in_a resolves to a register set in the prev_clobber insn, we may
> use the SET_SRC for the compare instead. However, when in_b so
> resolves, we proceed to use the reg with its earlier value. When both
> resolve to the same register and prev_clobb
On 11/08/2018 04:52 AM, Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded variants that return a proper range. In the
future we should use actual ranges throughout, and not depend on range
extremes, as depending on this behavior
On Thu, 8 Nov 2018, Richard Biener wrote:
The patch is OK.
Thanks,
Richard.
Thanks. Can you please apply it as I don't have any commit rights ?
The patch can be found in
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01240.html
Here is a valid gcc/ChangeLog correctly formated where I am ref
This is version 2 of the patch to remove power9 fusion. Is it ok to check into
the trunk?
[gcc]
2018-11-08 Michael Meissner
* config/rs6000/constraints.md (wF constraint): Update constraint
documentation for power8 fusion only.
* config/rs6000/predicates.md (p9_fusion
On Thu, 8 Nov 2018 at 20:09, David Malcolm wrote:
>
> On Thu, 2018-11-08 at 19:38 +0100, Christophe Lyon wrote:
> [...snip...]
>
> > Hi,
> >
> > This patch breaks my builds:
> > /tmp/9837775_6.tmpdir/aci-gcc-fsf/sources/gcc-
> > fsf/gccsrc/gcc/doc//invoke.texi:14118:
> > @option expected braces.
>
On 11/8/18 1:48 PM, Jakub Jelinek wrote:
> On Thu, Nov 08, 2018 at 01:43:29PM -0700, Jeff Law wrote:
>> On 11/8/18 1:27 AM, Martin Liška wrote:
>>> libsanitizer/ChangeLog:
>>>
>>> 2018-11-08 Martin Liska
>>>
>>> PR sanitizer/87892
>>> * (all files): Revert upstream r318802.
>> Is it caus
On Thu, Nov 08, 2018 at 01:43:29PM -0700, Jeff Law wrote:
> On 11/8/18 1:27 AM, Martin Liška wrote:
> > libsanitizer/ChangeLog:
> >
> > 2018-11-08 Martin Liska
> >
> > PR sanitizer/87892
> > * (all files): Revert upstream r318802.
> Is it causing a build failure or somesuch? ie, why s
On Thu, Nov 08, 2018 at 09:39:12PM +0100, Rainer Orth wrote:
> I guess this is obvious?
>
> Rainer
>
> --
> -
> Rainer Orth, Center for Biotechnology, Bielefeld University
>
>
> 2018-11-08 Rainer Orth
>
>
On 11/8/18 1:27 AM, Martin Liška wrote:
> Hi.
>
> The GetNumberOfCPUs functionality is only used from Scudo allocator:
> https://llvm.org/docs/ScudoHardenedAllocator.html
>
> The hardening allocator is not used from GCC, thus I recommend to remove
> the function.
>
> Ready for trunk?
> Martin
>
Hi Jakub,
> The OpenMP 5.0 specification, https://www.openmp.org/specifications/ ,
> has been just released a few minutes ago and to celebrate that, I've merged
> gomp-5_0-branch into trunk after bootstrapping/regtesting it on x86_64-linux
> and
> i686-linux.
this patch series broke the Solaris
On Thu, Nov 08, 2018 at 03:44:44PM +, Sam Tebbs wrote:
> Does your patch fix the incorrect generation of "scvtf s1, s1"? I was
> looking at the issue as well and don't want to do any overlapping work.
I don't know. Well, there are no incorrect code issues I know of at all
now; but you mean th
Hi,
We recently discovered that GCC is getting lucky with register allocation of
some inline assembly code, despite invalid register constraints. In these
two functions, a "wi" constraint (VSX valid for direct moves) was used for a
temporary that, as written, is further constrained to be an FPR.
On Sun, Oct 7, 2018 at 12:36 AM Thomas Koenig wrote:
> Hi Janne,
>
> > The error handling functions can be called from a signal handler, so they
> > need to be async-signal-safe.
>
> I didn't know that. How can this happen?
>
Hmm, seems I was imagining things, I can't find anything like that in
Hi!
I've noticed this test fails intermittently.
The problem is that it wasn't correct, without the in_reduction
clause this patch adds (or e.g. without #pragma omp atomic) there
is a data race, multiple tasks can update concurrently the same variable.
Tested on x86_64-linux, previously it would
On 11/8/18 12:12 PM, Bill Seurer wrote:
> [PATCH, rs6000] Disable ASLR in sanitizer on powerpc64.
>
> Cherry pick powerpc64 sanitizer fix from upstream llvm.
>
> See https://reviews.llvm.org/rL346030 and
> https://reviews.llvm.org/D52900.
>
> Bootstrapped and tested on powerpc64le-unknown-linux-
Hi Jerry!
Hi all,
The attached patch adds code in read_sf_internal to handle early
termination of reads in the presence of comma's. This is to support
legacy codes which are not standard conforming as far as we can tell.
The additions are executed only if -std=legacy is given at compile tim
[PATCH, rs6000] Disable ASLR in sanitizer on powerpc64.
Cherry pick powerpc64 sanitizer fix from upstream llvm.
See https://reviews.llvm.org/rL346030 and
https://reviews.llvm.org/D52900.
Bootstrapped and tested on powerpc64le-unknown-linux-gnu and
powerpc64-unknown-linux-gnu with no regressions.
On Thu, 2018-11-08 at 19:38 +0100, Christophe Lyon wrote:
[...snip...]
> Hi,
>
> This patch breaks my builds:
> /tmp/9837775_6.tmpdir/aci-gcc-fsf/sources/gcc-
> fsf/gccsrc/gcc/doc//invoke.texi:14118:
> @option expected braces.
> /tmp/9837775_6.tmpdir/aci-gcc-fsf/sources/gcc-
> fsf/gccsrc/gcc/doc/
On 11/8/18 8:29 AM, Peter Bergner wrote:
> On 11/8/18 5:48 AM, Richard Biener wrote:
>> Esp. adding conflicts in a loop that says "See which defined values die
>> here."
>> is quite fishy.
>
> ..the original loop is dealing with some of the gory details you never read
> about in academic RA paper
This patch corrects a large number of test suite failures. I'm now down to
about 1100 failures out of over 60k total, from at least 4000 before.
Committed.
paul
ChangeLog:
2018-11-08 Paul Koning
* config/pdp11/constraints.md: Add "Z" series constraints for use
wi
Hi Mihail
On 08/11/18 10:02, Ramana Radhakrishnan wrote:
> On 07/11/2018 17:49, Mihail Ionescu wrote:
>> Hi All,
>>
>> This is a backport from trunk for GCC 8 and 7.
>>
>> SVN revision: r264595.
>>
>> Regression tested on arm-none-eabi.
>>
>>
>> gcc/ChangeLog
>>
>> 2018-11-02 Mihail Ionescu
>>
On Thu, 8 Nov 2018 at 12:33, Richard Biener wrote:
>
> On Wed, Nov 7, 2018 at 5:22 PM David Malcolm wrote:
> >
> > This patch ports various fprintf calls in the inlining code to using
> > the dump API, using the %C format code for printing cgraph_node *.
> > I focused on the dump messages that se
On Thu, Nov 8, 2018 at 7:03 PM Andi Kleen wrote:
>
> > OK for x86 part (that is only PATCH 1/3). It looks that this part can
> > go to mainline as an independent patch from other patches in serie.
>
> Thanks.
>
> Note even 2/3 has a small i386 specific part. Would be good if you
> could take a loo
On Thu, Nov 08, 2018 at 11:57:13PM +1030, Alan Modra wrote:
> On Wed, Nov 07, 2018 at 07:11:28PM -0600, Segher Boessenkool wrote:
> > On Wed, Nov 07, 2018 at 04:08:26PM +1030, Alan Modra wrote:
> > > There is really no need to define a TLSmode mode iterator that is
> > > identical (since !TARGET_64
> OK for x86 part (that is only PATCH 1/3). It looks that this part can
> go to mainline as an independent patch from other patches in serie.
Thanks.
Note even 2/3 has a small i386 specific part. Would be good if you
could take a look at that part.
-Andi
Define the thread-safe pool resource, using a shared_mutex to allow
multiple threads to concurrently allocate from thread-specific pools.
Define new weak symbols for the pthread_rwlock_t functions, to avoid
making libstdc++.so depend on libpthread.so
* config/abi/pre/gnu.ver: Add new sym
This is a patch 4 to support the Aarch64 SIMD ABI [1] in GCC.
It defines a new target hook targetm.check_part_clobbered that
takes a rtx_insn and checks to see if it is a call to a function
that may clobber partial registers. It returns true by default,
which results in the current behaviour, but
This is a patch 3 to support the Aarch64 SIMD ABI [1] in GCC.
It defines a new target hook targetm.remove_extra_call_preserved_regs
that takes a rtx_insn and will remove registers from the register
set passed in if we know that this call preserves those registers.
Aarch64 SIMD functions preserve s
On Thu, Nov 08, 2018 at 12:09:33PM -0500, Fritz Reese wrote:
> I find "expand" a more helpful name than "set_bitflag_1" since it
> describes what the macro does. However, I don't think it makes too
> much of a difference so I'll follow your preference (but I'll use
> SET_BITFLAG2 since then the def
This is a patch 2 to support the Aarch64 SIMD ABI [1] in GCC.
It defines the TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN,
TARGET_SIMD_CLONE_ADJUST, and TARGET_SIMD_CLONE_USABLE macros
so that GCC can generate SIMD clones on aarch64.
Steve Ellcey
sell...@cavium.com
2018-11-08 Steve Ellcey
On 11/8/18 10:19 AM, Renlin Li wrote:
>> Yes, this is the problem. We see from the dump, that r2040 does not
>> conflict with
>> hard reg r1:
>>
>> ;; a2040(r1597,l0) conflicts:
>> ;; total conflict hard regs:
>> ;; conflict hard regs:
> I think you should look for axxx(r2040, ..)?
>
>
This is a resubmission of patch 1 to support the Aarch64 SIMD ABI [1] in
GCC, it does not have any functional changes from the last submit.
The significant difference between the standard ARM ABI and the SIMD ABI
is that in the normal ABI a callee saves only the lower 64 bits of registers
V8-V15,
This is an updated set of patches for the SIMD ABI on aarch64. I have
updated all of them to apply to ToT. The first two have no functional
changes from the last submittal. The last two are a reworking of what
used to be a single patch. I split it up into two parts and reworked
it to address co
This patch adds support for defining an alias for a CPU name that can
then be used in conjunction with the -mcpu option in the same way that
the primary name can be used. Aliases do not lead to a short-cut of
the feature options; they are literally an alternative name for the
core CPU.
The new en
Hello!
> From: Andi Kleen
>
> Add builtins/intrinsics for PTWRITE. PTWRITE is a new instruction on Intel
> Gemini Lake/
> Goldmont Plus that allows to write values into the Processor Trace log. This
> allows
> very light weight instrumentation of programs.
>
> The intrinsics are compatible to i
Hi!
This is the gcc/testsuite/ part of the gomp-5_0-branch
merge to trunk I've just committed.
2018-11-08 Jakub Jelinek
* c-c++-common/gomp/atomic-17.c: New test.
* c-c++-common/gomp/atomic-18.c: New test.
* c-c++-common/gomp/atomic-19.c: New test.
* c-c++-comm
Hi!
The OpenMP 5.0 specification, https://www.openmp.org/specifications/ ,
has been just released a few minutes ago and to celebrate that, I've merged
gomp-5_0-branch into trunk after bootstrapping/regtesting it on x86_64-linux and
i686-linux.
Because the amount of changes in OpenMP 5.0 is much b
Andi Kleen writes:
Ping!
> From: Andi Kleen
>
> Add builtins/intrinsics for PTWRITE. PTWRITE is a new instruction on Intel
> Gemini Lake/
> Goldmont Plus that allows to write values into the Processor Trace log. This
> allows
> very light weight instrumentation of programs.
>
> The intrinsics
Andi Kleen writes:
Ping!
> From: Andi Kleen
>
> When instrumenting programs using __fentry__ it is often useful
> to instrument the function return too. Traditionally this
> has been done by patching the return address on the stack
> frame on entry. However this is fairly complicated (trace
> f
On Wed, Nov 7, 2018 at 5:32 PM Jakub Jelinek wrote:
>
> On Wed, Nov 07, 2018 at 05:05:13PM -0500, Fritz Reese wrote:
>
> --- a/gcc/fortran/options.c
> +++ b/gcc/fortran/options.c
> @@ -32,6 +32,20 @@ along with GCC; see the file COPYING3. If not see
>
> gfc_option_t gfc_option;
>
> +#define _exp
Hi all,
As a follow up patch described here:
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg02016.html
Mask/predicate type of data could be used as general data.
In sve ISA, we don't have operations which could directly extract element from a
predicate. The default code-gen for such use is in-e
Hi Richard,
On 11/08/2018 12:09 PM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:02 PM Renlin Li wrote:
Hi all,
When allow-store-data-races is enabled, ifcvt would prefer to generated
conditional select and unconditional store to convert certain if statement
into:
_ifc_1 = val
_ifc_2 = A
Patch 4 fixes the calculation of USHRT_MAX in some tests, to prevent integer
overflow for targets where sizeof(short) == sizeof(int). i.e.
-#define USHRT_MAX (SHRT_MAX * 2 + 1)
+#define USHRT_MAX (SHRT_MAX * 2U + 1)
>From 6a6580c486a7705798c5a2c9898f46e7a319976b Mon Sep 17 00:00:00 2001
From:
Patch 3 extends the regex in some tests which scan the assembler output for
"nop". On MSP430, the nop instruction is an uppercase "NOP".
>From 6ad3780262543c5237e939ac14ac6294a2adc77b Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 6 Nov 2018 12:59:58 +
Subject: [PATCH 3/4] [TEST
Patch 2 skips tests expecting NULL pointer checks to be deleted
with the -fdelete-null-pointer-checks flag, for targets which ignore this flag.
>From 55b405a4d2c694ffdbcbd6808e139d88cb2d2447 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Tue, 6 Nov 2018 12:59:33 +
Subject: [PATCH 2/4
Patch 1 adds a couple of new regexp strings to gcc-dg-prune to catch messages
emitted by GNU ld, when the size of an output section is too large for a memory
region, or the memory region overflows.
>From af810d86c47092e56590f5c13d0633c490f53c9d Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
D
I've committed some "obvious" changes to GCC tests that fix failures when
running the GCC testsuite for msp430-elf.
Patch 1 adds a couple of new regexp strings to gcc-dg-prune to catch messages
emitted by GNU ld, when the size of an output section is too large for a memory
region, or the memory r
On Thu, 8 Nov 2018, Kito Cheng wrote:
> Hi Joseph:
>
> I don't have commit right, could you help me to commit that, thanks :)
Done.
--
Joseph S. Myers
jos...@codesourcery.com
On 11/07/2018 02:36 AM, Martin Liška wrote:
On 11/5/18 7:00 PM, Martin Sebor wrote:
On 11/01/2018 07:45 AM, Martin Liška wrote:
On 11/1/18 1:15 PM, Jakub Jelinek wrote:
On Thu, Nov 01, 2018 at 01:09:16PM +0100, Martin Liška wrote:
-range 0.0 to 1.0, inclusive.
+range 0.0 to 1.0, inclusive. T
Hi Peter,
On 11/08/2018 03:21 PM, Peter Bergner wrote:
On 11/8/18 4:57 AM, Renlin Li wrote:
I think I found the problem!
As described in the PR, a hard register is used in
an pre/post modify expression. The hard register is live, but updated.
In this case, we should make it conflicting with al
On 11/8/18 9:39 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 2:32 PM Aldy Hernandez wrote:
[Richard, you're right. An overloaded debug() is better than
this->dump(). Anyone who thinks different is wrong. End of discussion.]
There's no reason to have multiple ways of dumping a value r
This is a regression present since the -faggressive-loop-optimizations option
was introduced, leading to wrong code in some cases for "while" loops with
convoluted control flow. It's caused by a bad interaction between three
different things: specific support we have in gigi for -fnon-call-exce
Hi Thomas,
On 08/11/18 09:52, Thomas Preudhomme wrote:
Ping?
Best regards,
Thomas
On Thu, 1 Nov 2018 at 16:03, Thomas Preudhomme
wrote:
Ping?
Best regards,
Thomas
On Fri, 26 Oct 2018 at 22:41, Thomas Preudhomme
wrote:
Hi,
Please find updated patch to fix PR85434: spilling of stack prot
On 11/08/2018 09:45 AM, Alexandre Oliva wrote:
> On Nov 7, 2018, JonY <10wa...@gmail.com> wrote:
>
>> On 11/07/2018 08:34 AM, Alexandre Oliva wrote:
>>> On Nov 1, 2018, JonY wrote:
>>>
Looks like it causes an error on 64bit:
/usr/libexec/gcc/x86_64-w64-mingw32/ld: unrecognized option
>
On Thu, 8 Nov 2018 at 15:11, Uros Bizjak wrote:
>
> On Thu, Nov 8, 2018 at 1:29 PM Christophe Lyon
> wrote:
> >
> > On Wed, 7 Nov 2018 at 16:50, Uros Bizjak wrote:
> > >
> > > 2018-11-07 Uros Bizjak
> > >
> > > * gcc.dg/pr87874.c: Compile only for int128 effective target.
> > >
> > > Test
On 11/8/18 9:55 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:50 PM Aldy Hernandez wrote:
On 11/8/18 9:43 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wro
On 11/8/18 10:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez wrote:
On 11/8/18 9:53 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wr
On 11/8/18 8:14 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 at 4:00 PM Aldy Hernandez wrote:
>>
>>
>>
>> On 11/8/18 9:56 AM, Richard Biener wrote:
>>> On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
On 11/8/18 9:49 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 a
On Thu, Nov 8, 2018 at 4:05 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:53 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:34 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
>
> I
On Tue, Oct 23, 2018 at 08:17:43AM -0500, Martin Liška wrote:
> Hello.
>
> As a follow up patch I would like to remove redundant string allocation
> on string which is not needed in my opinion.
>
> That bootstrap on aarch64-linux.
OK,
Thanks,
James
> From a21a626055442635057985323bb42ef29526e
On 11/8/18 4:57 AM, Renlin Li wrote:
> I think I found the problem!
>
> As described in the PR, a hard register is used in
> an pre/post modify expression. The hard register is live, but updated.
> In this case, we should make it conflicting with all pseudos live at
> that point. Does it make sen
We can have quite convoluted layouts in Ada when a representation clause is
given for a record type with variant part and this doesn't always play nice
with the DECL_BIT_FIELD_REPRESENTATIVE machinery. This patch arranges for
DECL_BIT_FIELD_TYPE to be cleared on the variant part in these cases.
On Thu, Nov 8, 2018 at 4:00 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:56 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:49 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
>
>
>
On 11/8/18 9:53 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
I believe I've seen this idiom more than once. I know for sure I've
used it in our ssa-range b
On 11/8/18 9:56 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
On 11/8/18 9:49 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wro
> 2018-11-07 Martin Liska
>
> * common.opt: Add -fipa-stack-alignment flag.
> * doc/invoke.texi: Document it.
> * final.c (rest_of_clean_state): Guard stack
> shrinking with flag.
OK
> gcc/ChangeLog:
>
> 2018-11-07 Martin Liska
>
> * cgraph.h (ipa_discover_re
Since expand_thunk no longer overrides the DECL_IGNORED_P setting on the thunk
from the front-end in every case, duplicate_thunk_for_node may create a new
thunk without DECL_IGNORED_P set and this doesn't play with inlining and early
debug info generation; fixed by forcing DECL_IGNORED_P as befo
On Thu, Nov 8, 2018 at 3:54 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:49 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:24 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
>
> T
On Thu, Nov 8, 2018 at 3:50 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:43 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
> >>
> >>
> >>
> >> On 11/8/18 9:21 AM, Richard Biener wrote:
> >>> On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
>
> A
On 11/8/18 9:49 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
This one's rather obvious and does not depend on any get_range_info API
change.
OK for trunk?
On Thu, Nov 8, 2018 at 3:40 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:34 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
> >>
> >> I believe I've seen this idiom more than once. I know for sure I've
> >> used it in our ssa-range branch :). I'll hunt for th
On 11/8/18 7:49 AM, Richard Biener wrote:
> On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
>>
>>
>>
>> On 11/8/18 9:24 AM, Richard Biener wrote:
>>> On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
This one's rather obvious and does not depend on any get_range_info API
ch
On Thu, Nov 8, 2018 at 3:34 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:31 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez wrote:
> >>
> >> Stupid boring changes.
> >>
> >> OK?
> >
> > Well, IMHO using m_min is making clear you are accessing a member
> > while using
On 11/8/18 9:43 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
All this nonsense:
- rtype = get_range_info (t, &min, &max);
- if (rtype == VR_RANGE
On Thu, Nov 8, 2018 at 3:31 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:24 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
> >>
> >> This one's rather obvious and does not depend on any get_range_info API
> >> change.
> >>
> >> OK for trunk?
> >
> > Hmm, no -
On 11/8/18 7:44 AM, Aldy Hernandez wrote:
>
>
> On 11/8/18 9:41 AM, Richard Biener wrote:
>> On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez wrote:
>>>
>>>
>>>
>>> On 11/8/18 8:59 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez
wrote:
>
> get/set_range_i
On 11/8/18 9:41 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez wrote:
On 11/8/18 8:59 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez wrote:
get/set_range_info() currently returns the extremes of a range. I have
implemented overloaded
On Thu, Nov 8, 2018 at 3:27 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 9:21 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
> >>
> >> All this nonsense:
> >>
> >> - rtype = get_range_info (t, &min, &max);
> >> - if (rtype == VR_RANGE)
> >> - {
>
On Thu, Nov 8, 2018 at 3:05 PM Aldy Hernandez wrote:
>
>
>
> On 11/8/18 8:59 AM, Richard Biener wrote:
> > On Thu, Nov 8, 2018 at 12:52 PM Aldy Hernandez wrote:
> >>
> >> get/set_range_info() currently returns the extremes of a range. I have
> >> implemented overloaded variants that return a pro
On 11/8/18 9:34 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
I believe I've seen this idiom more than once. I know for sure I've
used it in our ssa-range branch :). I'll hunt for the other uses and
adjust accordingly.
domain_p?! Isn't that the same as
On Thu, Nov 8, 2018 at 2:32 PM Aldy Hernandez wrote:
>
> [Richard, you're right. An overloaded debug() is better than
> this->dump(). Anyone who thinks different is wrong. End of discussion.]
>
> There's no reason to have multiple ways of dumping a value range. And
> I'm not even talking about
On Thu, Nov 8, 2018 at 1:52 PM Aldy Hernandez wrote:
>
> I believe I've seen this idiom more than once. I know for sure I've
> used it in our ssa-range branch :). I'll hunt for the other uses and
> adjust accordingly.
domain_p?! Isn't that the same as varying_p()? Also
+ if (m_kind == VR_RA
On 11/8/18 9:31 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez wrote:
Stupid boring changes.
OK?
Well, IMHO using m_min is making clear you are accessing a member
while using min () does not.
There is already prior art here. I believe I discussed this before a
On Thu, Nov 8, 2018 at 1:42 PM Aldy Hernandez wrote:
>
> Stupid boring changes.
>
> OK?
Well, IMHO using m_min is making clear you are accessing a member
while using min () does not.
So no, please do not make this kind of changes?
Richard.
On 11/8/18 9:24 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
This one's rather obvious and does not depend on any get_range_info API
change.
OK for trunk?
Hmm, no - that's broken. IIRC m_equiv are shared bitmaps if you
do tem = *old_vr so you modify it
On Thu, Nov 8, 2018 at 3:24 PM Richard Biener
wrote:
>
> On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
> >
> > This one's rather obvious and does not depend on any get_range_info API
> > change.
> >
> > OK for trunk?
>
> Hmm, no - that's broken. IIRC m_equiv are shared bitmaps if you
> do
On 11/8/18 5:48 AM, Richard Biener wrote:
> Err, that looks very much like a hack that manages to hide the issue.
It's true we do not want to hide the issue by adding unneeded conflicts,
since that can lead to unnecessary spills. However, ...
> Esp. adding conflicts in a loop that says "See whi
On 11/8/18 9:21 AM, Richard Biener wrote:
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
All this nonsense:
- rtype = get_range_info (t, &min, &max);
- if (rtype == VR_RANGE)
- {
- if (wi::lt_p (max, w, TYPE_SIGN (TREE_TYPE (t
- return true;
-
On Thu, Nov 8, 2018 at 1:17 PM Aldy Hernandez wrote:
>
> This one's rather obvious and does not depend on any get_range_info API
> change.
>
> OK for trunk?
Hmm, no - that's broken. IIRC m_equiv are shared bitmaps if you
do tem = *old_vr so you modify it in place with equiv_clear().
Thus, opera
On Thu, Nov 8, 2018 at 1:09 PM Aldy Hernandez wrote:
>
> All this nonsense:
>
> - rtype = get_range_info (t, &min, &max);
> - if (rtype == VR_RANGE)
> - {
> - if (wi::lt_p (max, w, TYPE_SIGN (TREE_TYPE (t
> - return true;
> - if (wi::lt_p (w, min, TYPE
1 - 100 of 154 matches
Mail list logo
