Hi!
On Thu, 12 Jun 2014 06:33:25 +0200, Jan Hubicka wrote:
> this lenghtly patch makes the legwork to put section names out of tree
> representation.
> Originally they were STRING_CST. I ended up implementing on-side reference
> counted
> string voclabulary that is done in bit baroque way to be
Ping?
Thanks!
-Zhenqiang
On 9 June 2014 17:08, Zhenqiang Chen wrote:
> Ping ^2?
>
> Thanks!
> -Zhenqiang
>
> On 28 May 2014 15:02, Zhenqiang Chen wrote:
>> Ping?
>>
>> Thanks!
>> -Zhenqiang
>>
>> On 22 May 2014 17:52, Zhenqiang Chen wrote:
>>> On 21 May 2014 20:43, Steven Bosscher wrote:
Hi Cesar!
Sorry for long delay, I was busy at the institute.
On 05.06.2014 07:58, Cesar Philippidis wrote:
I didn't see a whole lot different from your gfc_trans_oacc_loop and the
existing gfc_trans_omp_do, so I augmented the latter to handle the
openacc loop clause. It looks like the only imp
David,
thanks for the analysis!
> Without the ipa-inline-analysis.c change, g++ creates a static
> constructor with global visibility
>
> .globl
> ._GLOBAL__I_65535_0__home_dje_src_src_libstdc___v3_src_c__98_parallel_settings.cc_2984A295_0
>
> ._GLOBAL__I_65535_0__home_dje_src_src_libstd
Without the ipa-inline-analysis.c change, g++ creates a static
constructor with global visibility
.globl
._GLOBAL__I_65535_0__home_dje_src_src_libstdc___v3_src_c__98_parallel_settings.cc_2984A295_0
._GLOBAL__I_65535_0__home_dje_src_src_libstdc___v3_src_c__98_parallel_settings.cc_2984A295
Hi,
For some large constant, ports like ARM, need one more instructions to
operate it. e.g
#define MASK 0xfe00ff
void maskdata (int * data, int len)
{
int i = len;
for (; i > 0; i -= 2)
{
data[i] &= MASK;
data[i + 1] &= MASK;
}
}
Need two instructions for each AND opera
> Looks ok to me, but can you add a testcase please?
I have a testcase, but if -flto the testcase doesn't include *any*
definition of the test function, just all the LTO data. Is this
normal?
> Also check if 4.9 is affected.
It is... same fix works, though.
It looks like _Settings is miscompiled, or more specifically a
function descriptor has a bogus value
0x100bcbac <_ZN14__gnu_parallel9_SettingsC1Ev>: addir12,r2,-168
0x100bcbb0 <_ZN14__gnu_parallel9_SettingsC1Ev+4>:stw r2,20(r1)
0x100bcbb4 <_ZN14__gnu_parallel9_SettingsC1E
dw2_asm_output_vms_delta() calls dw2_asm_output_delta() in an abnormal
way, so need add a new function just like vprintf() for printf(), and
then the related call will be in normal way.
The related warning:
../../gcc/gcc/dwarf2asm.c: In function ‘void dw2_asm_output_vms_delta(int,
const char*,
On 06/16/2014 10:37 PM, Joseph S. Myers wrote:
> On Mon, 16 Jun 2014, Chen Gang wrote:
>
>> +static_output_delta (int size, const char *lab1, const char *lab2,
>
> static_ is not a helpful naming convention, since the fact that a function
> is static is nothing to do with what that function do
On Mon, Jun 16, 2014 at 5:44 PM, Jan Hubicka wrote:
> If you don't mind, I would like to commit back the rest of changes
> (reset_section)
> cleanups after testing on AIX + testing the aforementioned ARM testcase.
Please go ahead and commit the parts of the patch that do not cause problems.
Th
> On Mon, Jun 16, 2014 at 12:35 AM, Jan Hubicka wrote:
>
> > @@ -512,9 +516,9 @@ function_and_variable_visibility (bool w
> > next = next->same_comdat_group)
> > {
> > next->set_comdat_group (NULL);
> > - if (!next->alias)
> >
Here is one more patch concerning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61325
The following patch prevents complex address transformation just by
checking a change in address validity of subreg memory substitution.
The patch was bootstrapped and tested on x86-64.
Committed as rev. 2
On Jun 16, 2014, at 10:49 AM, Bernd Schmidt wrote:
>
> There are two reasons why I can't do this in the frontends - one, Joseph has
> already rejected a C frontend patch,
I’d like to think there is an acceptable way to get the right memory space on
things...
> and two, this needs to work with
> Honza,
>
> FYI, your bootstrap on gcc111 is hung in the exact same place as I
> have observed: all of the stage2 gen* programs spinning.
Yes (will kill it now), I was tracking down what change it is.
It is actually the inliner hunk that is independent of rest of changes
(and one that should be
Hi All!
The patch fixes ICE in array notation for the cases of incorrect arguments of
Cilk+ builtins and undeclared initial index.
Is it ok for trunk and 4.9?
Thanks,
Igor
diff --git a/gcc/c/ChangeLog b/gcc/c/ChangeLog
index 54d0de7..56e1b0b 100644
--- a/gcc/c/ChangeLog
+++ b/gcc/c/ChangeLog
@
On Mon, Jun 16, 2014 at 12:35 AM, Jan Hubicka wrote:
> @@ -512,9 +516,9 @@ function_and_variable_visibility (bool w
> next = next->same_comdat_group)
> {
> next->set_comdat_group (NULL);
> - if (!next->alias)
> -
Bootstrapped successfully on x64 with proposed patch.
The original commit indeed failed to bootstrap
(https://gcc.gnu.org/ml/gcc-testresults/2014-06/msg01419.html).
Ok to commit fix?
Ok (with proper ChangeLog entry).
r211713.
-Y
On Mon, Jun 16, 2014 at 10:21:39PM +0400, Yury Gribov wrote:
> On 06/16/2014 04:47 PM, Yury Gribov wrote:
> >On 06/16/2014 02:34 PM, Dominique Dhumieres wrote:
> >>>Done in r211699.
> >>
> >>This breaks bootstrap on x86_64-apple-darwin13:
> >
> >Hm, perhaps I didn't run full bootstrap after last ro
On 06/16/2014 04:47 PM, Yury Gribov wrote:
On 06/16/2014 02:34 PM, Dominique Dhumieres wrote:
Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
Hm, perhaps I didn't run full bootstrap after last round of review.
Does attached patch solve the problem for you? I've started boots
On 2014-06-16, 12:12 PM, Robert Suchanek wrote:
Pinging for approval.
This part of the patch will be needed for MIPS16. The second part to enable
LRA in MIPS has been already approved.
Sorry, Robert. I thought you are waiting for some Richard's comment
(actually he knows the code well and
On 06/16/2014 07:26 PM, Mike Stump wrote:
On Jun 16, 2014, at 3:56 AM, Bernd Schmidt
wrote:
For the ptx port, I've needed to write a new pass which ensures all
objects go into address spaces as required by the machine.
I have such a machine and I’ve always approached the problem from the
fron
On Jun 16, 2014, at 3:56 AM, Bernd Schmidt wrote:
> For the ptx port, I've needed to write a new pass which ensures all objects
> go into address spaces as required by the machine.
I have such a machine and I’ve always approached the problem from the front end
side. I ensure the right space up
Honza,
FYI, your bootstrap on gcc111 is hung in the exact same place as I
have observed: all of the stage2 gen* programs spinning.
- David
On Mon, Jun 16, 2014 at 11:08 AM, Jan Hubicka wrote:
>> Honza,
>>
>> Thanks for reverting the patch. I will check if this resolves the
>> current bootstrap
On 06/16/14 04:12, Kyrill Tkachov wrote:
Doh, you're right. I did consider it but for some reason thought we
might want to iterate over all of the bypasses anyway. Breaking out
seems good.
How about this?
Tested on arm and aarch64 and confirmed with valgrind that no out of
bounds accesses occu
On Mon, Jun 16, 2014 at 06:05:19PM +0200, Jan Hubicka wrote:
> > > This needs your decl_replaceable change to not be optimized to if (0),
> > > because of the explicit const modifier.
> >
> > The case I care about actually has "dummy" as const (with the intent
> > that it be allocated in a read-on
On 2014-06-16, 12:14 PM, Ramana Radhakrishnan wrote:
On Mon, Jun 16, 2014 at 5:11 PM, Vladimir Makarov wrote:
Any reason the check couldn't be like the earlier patch ?
i.e. else if (targetm.spill_class)
{
}
I've just preferred to put most conditions in one place. That is the
on
On 06/14/14 21:59, Janne Blomqvist wrote:
Ok.
(as an aside, has anyone ever heard of anyone actually using gfortran on hp-ux?)
Folks certainly used the much older g77 implementation on hpux. Since
the switch to gfortran? No clue. I'm kindof amazed anyone is trying to
work on hpux10.20. hpu
On Mon, Jun 16, 2014 at 4:08 PM, Jan Hubicka wrote:
>> Honza,
>>
>> Thanks for reverting the patch. I will check if this resolves the
>> current bootstrap problem.
>>
>> I was suggesting that you create a branch for all of the visibility
>> changes to make it easier to track the various original p
On Mon, Jun 16, 2014 at 5:11 PM, Vladimir Makarov wrote:
> On 2014-06-16, 11:05 AM, Ramana Radhakrishnan wrote:
>>
>> Hi,
>>
>> This handles NULL targetm.spill_class in assign_by_spills. This
>> showed up as a segfault during a build for arm-none-linux-gnueabi(hf).
>>
>> Fix pre-approved by r
Pinging for approval.
This part of the patch will be needed for MIPS16. The second part to enable
LRA in MIPS has been already approved.
> Hi Richard,
>
> >> Robert: you also had an LRA change, but is it still needed after this one?
> >> If so, could you repost it and explain the case it handle
On 2014-06-16, 11:05 AM, Ramana Radhakrishnan wrote:
Hi,
This handles NULL targetm.spill_class in assign_by_spills. This
showed up as a segfault during a build for arm-none-linux-gnueabi(hf).
Fix pre-approved by richi on IRC , verified that bootstrap continues
from where things broke furth
Richard,
Ping for these patches:
- [PATCH, ARM] Enable fuse-caller-save for ARM
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg8.html
- [PATCH, AARCH64] Enable fuse-caller-save for AARCH64
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg4.html
The patches enable the -fuse-caller-save opt
> On Mon, Jun 16, 2014 at 11:06:04AM +0200, Jan Hubicka wrote:
> > >
> > > Are the attached files acceptable?
> >
> > The testcase looks OK to me, but it already should be fixed on mainline
> > by patch https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01315.html that
> > prevents dummy to be marked
You can assign the same register to more than operand based on the Liveness. It
will be tricky if on the basis of Liveness available registers not found. In
that you need to spill one of the operands and use the registers assigned to
the next operand. This forms the basis of spilling one of the
On Mon, Jun 16, 2014 at 04:05:52PM +0100, Ramana Radhakrishnan wrote:
> This handles NULL targetm.spill_class in assign_by_spills. This showed
> up
> as a segfault during a build for arm-none-linux-gnueabi(hf).
>
> Fix pre-approved by richi on IRC , verified that bootstrap continues from
>
> Honza,
>
> Thanks for reverting the patch. I will check if this resolves the
> current bootstrap problem.
>
> I was suggesting that you create a branch for all of the visibility
> changes to make it easier to track the various original patches and
> later correction patches from you.
>
> I don
Hi,
This handles NULL targetm.spill_class in assign_by_spills. This showed
up as a segfault during a build for arm-none-linux-gnueabi(hf).
Fix pre-approved by richi on IRC , verified that bootstrap continues
from where things broke further on a tree (that reverts 211600 which is
the next br
On Mon, Jun 16, 2014 at 6:58 AM, Ian Lance Taylor wrote:
> On Mon, Jun 16, 2014 at 3:56 AM, Rainer Orth
> wrote:
>>
>> Works fine, thanks. Just before your patch arrived, I meant to test the
>> following, slightly more general patch. Perhaps it's an option to
>> handle other quirks like this?
>
On Sat, 2014-06-14 at 08:49 +0100, Richard Sandiford wrote:
> The patch below fixes the testcase. Please could you give it a spin
> and see whether there's any other fallout? I assume this would have
> shown up in a testsuite run if you'd been able to get that far.
>
> Thanks,
> Richard
The pa
I have bootstrapped r211707 with the full patch (among others!).
> It does not. So the above is IMHO very likely completely unrelated,
> perhaps Darwin specific, issue.
More likely related to the fact that I only resumed bootstrap after the change
tree t = NULL_TREE; and an update from r211700 t
On Mon, 16 Jun 2014, Chen Gang wrote:
> +static_output_delta (int size, const char *lab1, const char *lab2,
static_ is not a helpful naming convention, since the fact that a function
is static is nothing to do with what that function does. Try something
like dw2_asm_voutput_delta to indicate a
On Mon, Jun 16, 2014 at 3:56 AM, Rainer Orth
wrote:
>
> Works fine, thanks. Just before your patch arrived, I meant to test the
> following, slightly more general patch. Perhaps it's an option to
> handle other quirks like this?
This approach is fine with me, but the target macro should be
docu
On Mon, Jun 16, 2014 at 11:06:04AM +0200, Jan Hubicka wrote:
> >
> > Are the attached files acceptable?
>
> The testcase looks OK to me, but it already should be fixed on mainline
> by patch https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01315.html that
> prevents dummy to be marked as constant.
On Mon, 16 Jun 2014, Richard Biener wrote:
>
> The following fixes PR61482, avoiding to call set_value_range
> with [-INF(OVF), +INF(OVF)].
>
> Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Err, finger faster than eye. Here's the changelog.
Richard.
2014-06-16 Richard Biene
The following fixes PR61482, avoiding to call set_value_range
with [-INF(OVF), +INF(OVF)].
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
Index: gcc/tree-vrp.c
===
--- gcc/tree-vrp.c (revision 211698)
This adjusts substitute_and_fold similar to how the FRE/PRE propagation
stage works which means we properly cleanup after ourselves with
respect to DCE (if we are allowed to). The patch removes the
poor-mans DCE code (checking for has_zero_uses) as that doesn't
really belong here and as it doesn
There are two basic errors in the computation - the first is when
min_cost is never adjusted it remains at UINT_MAX (happens when
all PHI arguments are not defined in any loop). Second is if
the PHI argument is not defined in the same loop as the PHI - then
we accumulate the cost of already invar
Hello,
this patch adds basic support for libatomic for mingw targets using
win32 and for mingw targets using posix threading model.
The win32 implemenation might need for initialization of mutexes a
critical section. If issue occures we can still add that. For now
all testcases are passing for
On Mon, Jun 16, 2014 at 04:57:54PM +0400, Yury Gribov wrote:
> On 06/16/2014 04:52 PM, Dominique Dhumieres wrote:
> >I have done the change to tree t = NULL_TREE; then bootstrap fails with
> >
> >Bootstrap comparison failure!
> >gcc/plugin.o differs
> >gcc/toplev.o differs
>
> Interesting, I didn'
On 06/16/2014 04:52 PM, Dominique Dhumieres wrote:
I have done the change to tree t = NULL_TREE; then bootstrap fails with
Bootstrap comparison failure!
gcc/plugin.o differs
gcc/toplev.o differs
Interesting, I didn't know that asan.c runs during normal bootstrap.
-Y
Hi Maintainers,
This patch fixes the PR 60617 that occurs when we turn on reload pass
in thumb2 mode.
It occurs for the pattern "*ior_scc_scc" that gets generated for the 3
argument of the below function call.
JIT:emitStoreInt32(dst,regT0m, (op1 == dst || op2 == dst)));
(snip---)
(insn 634
I have done the change to tree t = NULL_TREE; then bootstrap fails with
Bootstrap comparison failure!
gcc/plugin.o differs
gcc/toplev.o differs
I'll try your full patch later (currently bootstrapping r211698).
Thanks,
Dominique
I'm about to backport the ZIP/UZP/TRN fix for ARM big-endian in r211369, that
patches arm_neon.h, before that we need to remove the OCAML code that
autogenerates arm_neon.h...ok?
--Alancommit 458ddd61009cef4f3bc0d02c6ea74a1da7a4b505
Author: ramana
Date: Thu May 8 14:35:40 2014 +
Bac
On 06/16/2014 02:34 PM, Dominique Dhumieres wrote:
Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
Hm, perhaps I didn't run full bootstrap after last round of review.
Does attached patch solve the problem for you? I've started bootstrap
but it'll take couple of hours to compl
On Mon, Jun 16, 2014 at 10:25:36AM +0100, Christophe Lyon wrote:
> Hi,
>
> This patches causes a failure to build GCC (since commit 211655), on
> all ARM and Aarch64 targets I track.
>
> I can see failures when building libgcc (_mulsc3.o, _muldc3.o,
> _divdc3.o), the error message being:
> 0xa07f
On Mon, Jun 16, 2014 at 1:45 PM, Bernd Schmidt wrote:
> On 06/16/2014 01:24 PM, Richard Biener wrote:
>>
>> On Mon, Jun 16, 2014 at 12:56 PM, Bernd Schmidt
>> wrote:
>>>
>>> For the ptx port, I've needed to write a new pass which ensures all
>>> objects
>>> go into address spaces as required by t
Wswitch-bool option was missing a 'Var' field, which means
-Wno-switch-bool didn't suppress the warning.
I'm committing the following as obvious.
2014-06-16 Marek Polacek
PR c/60439
* c.opt (Wswitch-bool): Add Var.
diff --git gcc/c-family/c.opt gcc/c-family/c.opt
index d2e047
On Mon, Jun 16, 2014 at 5:35 AM, Jan Hubicka wrote:
>> Honza,
>>
>> The cgraph patch in r211600 broke AIX bootstrap again. I cannot find
>> the corresponding patch in the GCC Patches mailing list, so I do not
>> see where this was discussed or approved.
>
> Sorry, I remember writting mail about t
On 06/16/2014 01:24 PM, Rainer Orth wrote:
This patch
2014-06-12 Jason Merrill
* toplev.c (process_options): Reject -fabi-version=1.
which was committed as part of the above, but not posted AFAICS,
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01054.html
introduced a testsuite f
Honza,
Thanks for reverting the patch. I will check if this resolves the
current bootstrap problem.
I was suggesting that you create a branch for all of the visibility
changes to make it easier to track the various original patches and
later correction patches from you.
I don't know if the gen*
A couple of small bugs involving pointers to member functions in
templates. In 61500, we were failing to handle MEMBER_REF in
lvalue_kind. In 61488, we were failing to handle unlowered PMF syntax
used as a template argument.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit ef46b757ccae7
On 06/16/2014 01:24 PM, Richard Biener wrote:
On Mon, Jun 16, 2014 at 12:56 PM, Bernd Schmidt wrote:
For the ptx port, I've needed to write a new pass which ensures all objects
go into address spaces as required by the machine. This uses the
regimplification code in gimplify-me.c, and that requ
Hi,
As discussed several times previously, support for NEON in ARM
big-endian mode is quite broken because of differing assumptions about
lane ordering made by the ARM EABI and the set of NEON intrinsics on
the one hand, and the vectorizer on the other.
Fixing this "properly" would involve quite
On Mon, Jun 16, 2014 at 12:57 PM, Bernd Schmidt wrote:
> There's code in regimplification that makes us use an extra temporary
> when we encounter a call returning a non-BLKmode structure. This seems
> somewhat inefficient and unnecessary, and when used from the
> lower-addr-spaces pass I'm workin
On Mon, Jun 16, 2014 at 12:57 PM, Bernd Schmidt wrote:
> This fixes an issue that showed up when regimplifying a call with a
> WITH_SIZE_EXPR for one of its arguments. At the moment we can end up trying
> to make a temporary and aborting because we don't know what size it ought to
> be. The probl
On Mon, Jun 16, 2014 at 12:56 PM, Bernd Schmidt wrote:
> For the ptx port, I've needed to write a new pass which ensures all objects
> go into address spaces as required by the machine. This uses the
> regimplification code in gimplify-me.c, and that requires some fixes and
> upgrades.
Can you ex
Jason Merrill writes:
> Now that -fabi-version defaults to 0, -Wabi isn't very useful. But for
> people interested in compatibility with earlier versions, this patch allows
> you to say -Wabi=2 to get any relevant warnings. This patch also adjusts
> the compatibility aliases to default to backw
On Mon, 16 Jun 2014, Steven Bosscher wrote:
> On Mon, Jun 16, 2014 at 12:36 AM, Hans-Peter Nilsson wrote:
> > On Sun, 15 Jun 2014, Steven Bosscher wrote:
> >> On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
> >> > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
> >> > merg
On Mon, Jun 16, 2014 at 12:39:07PM +0200, Marek Polacek wrote:
> Jason/Joseph, could you please look at the C++/C FE parts?
As mentioned on IRC, you need to differentiate between taking address
and not taking address.
struct S { int a; int b; } s[4], *t;
int *a, *b, *c;
void *d;
int e[4][4];
voi
There's code in regimplification that makes us use an extra temporary
when we encounter a call returning a non-BLKmode structure. This seems
somewhat inefficient and unnecessary, and when used from the
lower-addr-spaces pass I'm working on it leads to problems further
down that look like tree-ssa
This fixes an issue that showed up when regimplifying a call with a
WITH_SIZE_EXPR for one of its arguments. At the moment we can end up
trying to make a temporary and aborting because we don't know what size
it ought to be. The problem is that we call gimplify_expr with the
wrong predicate: g
For the ptx port, I've needed to write a new pass which ensures all
objects go into address spaces as required by the machine. This uses the
regimplification code in gimplify-me.c, and that requires some fixes and
upgrades.
Here's the first. When address spaces change, an ADDR_EXPR may have to
Ian Lance Taylor writes:
> This patch changes the gccgo driver to pass -t to the native linker on
> Solaris. This avoids warnings like
>
> ld: warning: symbol 'go$zerovalue' has differing sizes:
> (file hello.o value=0x8; file
> i386-pc-solaris2.11/libgo/.libs/libgo.so value=0x800);
>
The following is quite large patch for something rather simple as
bounds checking. The idea is to instrument ARRAY_REFs in such a way
that iff the array index is greater than the max value of the TYPE_DOMAIN
of the ARRAY_TYPE, call __ubsan builtin and report error.
My first attempts failed, howev
> Done in r211699.
This breaks bootstrap on x86_64-apple-darwin13:
/opt/gcc/build_w/./prev-gcc/xg++ -B/opt/gcc/build_w/./prev-gcc/
-B/opt/gcc/gcc4.10w/x86_64-apple-darwin13.2.0/bin/ -nostdinc++
-B/opt/gcc/build_w/prev-x86_64-apple-darwin13.2.0/libstdc++-v3/src/.libs
-B/opt/gcc/build_w/prev-x86
2014-06-13 19:40 GMT+04:00 Jeff Law :
> On 06/12/14 17:38, Ilya Enkovich wrote:
>>>
>>> It looks ok to me - did you test with all languages? In particular did
>>> you test Ada?
>>
>>
>> I configure compiler with no language disabling and then run bootstrap
>> and make check. Does it mean all langu
On 13/06/14 16:51, Jeff Law wrote:
On 06/13/14 03:56, Kyrill Tkachov wrote:
Hi all,
I noticed a memory corruption bug while adding some scheduler bypasses
in the arm backend.
genattrtab would segfault while processing the bypasses. Valgrind
confirmed this.
The problem is that when processing
Hello,
I am sorry for wrong reply address in previously sent thread. After working
for quite a long time, I would like to introduce new IPA pass. Goal of the pass
is to merge semantically equivalent functions and read-only variables.
If we prove that a function A is an equivalent to a functio
Hi,
this is a new collection of tests for IPA ICF pass.
Martin
Changelog:
2014-06-13 Martin Liska
Honza Hubicka
* gcc/testsuite/g++.dg/ipa/ipa-se-1.C: New test.
* gcc/testsuite/g++.dg/ipa/ipa-se-2.C: Likewise.
* gcc/testsuite/g++.dg/ipa/ipa-se-3.C: Li
Hi,
many tests rely on a precise number of scanned functions in a dump file. If
IPA ICF decides to merge some function and(or) read-only variables, counts do
not match.
Martin
Changelog:
2014-06-13 Martin Liska
Honza Hubicka
* c-c++-common/rotate-1.c: Text
*
Hi,
this small patch prepares remaining needed infrastructure for the new pass.
Changelog:
2014-06-13 Martin Liska
Honza Hubicka
* ipa-utils.h (polymorphic_type_binfo_p): Function marked external
instead of static.
* ipa-devirt.c (polymorphic_type_bin
On 14/6/16 5:55 PM, James Greenhalgh wrote:
> On Fri, Jun 13, 2014 at 05:46:45PM +0100, Vladimir Makarov wrote:
>> On 2014-06-11, 1:17 PM, Chung-Lin Tang wrote:
>>> Looking at this too, as an LRA exercise. I don't really think the
>>> pattern is wrong, rather LRA should just avoid creating the copy
Hi Honza,
On Mon, 2 Jun 2014 18:12:10, Jan Hubicka wrote:
>
>> Hi,
>>
>> On Mon, 2 Jun 2014 12:06:12, Richard Biener wrote:
>>>
>>> On Mon, Jun 2, 2014 at 11:00 AM, Bernd Edlinger
>>> wrote:
Hi,
the test case g++.old-deja/g++.mike/p4736b.C is mis-compiled with with all
optimiz
On Fri, Jun 13, 2014 at 05:46:45PM +0100, Vladimir Makarov wrote:
> On 2014-06-11, 1:17 PM, Chung-Lin Tang wrote:
> > Looking at this too, as an LRA exercise. I don't really think the
> > pattern is wrong, rather LRA should just avoid creating the copy in this
> > case; it's a result of operand con
Dear Paul,
Late thanks for the review, the patch has been committed to trunk at r211405.
> OK for trunk and, I would suggest 4.9.
I am now trying to do the back port to 4.9 and I got two failures:
FAIL: gfortran.dg/alloc_comp_basics_1.f90 -O* scan-tree-dump-times original
"builtin_free" 18
On Sat, 14 Jun 2014, Eric Botcazou wrote:
> > 2014-06-13 Richard Biener
> >
> > * tree-ssa-pre.c (eliminate_dom_walker::before_dom_children):
> > Rewrite to propagate the VN result into all uses where
> > possible and to remove stmts becoming dead because of that.
> > (eliminat
Hi,
On 16/06/14 10:42, Konstantin Serebryany wrote:
I've "fixed" this in upstream trunk:
http://llvm.org/viewvc/llvm-project?view=revision&revision=211008 This
will get into GCC with the next merge; or feel free to cherry pick.
Excellent thanks a lot.
Meanwhile, this still smells like a bug in
Hi,
This patches causes a failure to build GCC (since commit 211655), on
all ARM and Aarch64 targets I track.
I can see failures when building libgcc (_mulsc3.o, _muldc3.o,
_divdc3.o), the error message being:
0xa07f6f crash_signal
/tmp/214822_1.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/g
> On Fri, Jun 13, 2014 at 12:14 AM, Jan Hubicka wrote:
> > Hi,
> > while updating vect_can_force_dr_alignment_p for section API I noticed the
> > predicate is bit confused about when it can update the alignment.
> >
> > We need to check that decl_binds_to_current_def_p and in case we compile
> > a
I'd replaced the uid initialisation with an insn_info initialisation,
but it needed to be initialised at the point of insn_info test.
Tested against the testcase in the PR and applied as obvious.
Richard
gcc/
PR bootstrap/61516
* auto-inc-dec.c (merge_in_block): Fix location of
>
> Are the attached files acceptable?
The testcase looks OK to me, but it already should be fixed on mainline
by patch https://gcc.gnu.org/ml/gcc-patches/2014-05/msg01315.html that
prevents dummy to be marked as constant.
You can however modify the testcase to have
__attribute__ ((weak)) const
> > /* Variables declared 'const' without an initializer
> > have zero as the initializer if they may not be
> > overridden at link or run time. */
> > if (!DECL_INITIAL (real_decl)
> > && (DECL_EXTERNAL (decl) || decl_replaceable_p (decl)))
> > return error_mark_node;
> >
On 06/16/2014 12:23 PM, Jakub Jelinek wrote:
2014-06-11 Yury Gribov
New asan-instrumentation-with-call-threshold parameter.
Ok, thanks.
Done in r211699.
On Wed, Jun 11, 2014 at 2:28 PM, Paolo Carlini wrote:
> Hi,
>
> On 05/22/2014 09:02 PM, Jakub Jelinek wrote:
>>
>> In file included from
>> ../../../../trunk/libsanitizer/asan/asan_interceptors.cc:147:0:
>>
>> ../../../../trunk/libsanitizer/sanitizer_common/sanitizer_common_interceptors.inc:
>> In
On Mon, Jun 16, 2014 at 12:36 AM, Hans-Peter Nilsson wrote:
> On Sun, 15 Jun 2014, Steven Bosscher wrote:
>> On Sun, Jun 15, 2014 at 1:27 PM, Hans-Peter Nilsson wrote:
>> > /tmp/hpautotest-gcc0/gcc/gcc/auto-inc-dec.c: In function 'void
>> > merge_in_block(int, basic_block_def*)':
>> > /tmp/hpautote
On Mon, Jun 16, 2014 at 9:04 AM, Andreas Schwab wrote:
> Hans-Peter Nilsson writes:
>
>> On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
>>
>>> On Sun, 15 Jun 2014, Hans-Peter Nilsson wrote:
>>> > On Sun, 15 Jun 2014, Steven Bosscher wrote:
>>> > > Can you please try:
>>> > >
>>> > > [...]
>>> >
>
On Wed, Jun 11, 2014 at 04:53:32PM +0400, Yury Gribov wrote:
> On 06/11/2014 01:31 PM, Jakub Jelinek wrote:
> >The plan (we had already for 4.9, but didn't get to that yet) is in the end
> >not to lower the checks in asan pass that much, and lower it in sanopt
> >pass later on after performing some
On Fri, 13 Jun 2014, Richard Biener wrote:
>
> The following leverages the "extra" work done by FRE/PRE now
> (propagating copies and constants) and removes the copy-prop
> pass run during early optimizations (no passes after it expose
> copy propagation opportunities). It also moves the 3rd
> c
> On 06/10/2014 08:34 AM, Jan Hubicka wrote:
> >Hi,
> >ipa-reference is somewhat stupid and builds its data sets for all variables
> >including
> >addressable and public one just to prune them out after all bitmaps are
> >constructed.
> >This used to make sense when the profile generation happene
1 - 100 of 107 matches
Mail list logo
