On 16 June 2014 08:20:09 Janne Blomqvist wrote:
On Sun, Jun 15, 2014 at 8:23 AM, Bernhard Reutner-Fischer
wrote:
>
>> >> On Tue, May 20, 2014 at 12:42 AM, Janne Blomqvist
>> >> wrote:
>> >>> On Thu, May 15, 2014 at 1:00 AM, Janne Blomqvist
>> >>> wrote:
>> Hi,
>>
>> a common m
On 15/06/14 15:37, Jason Merrill wrote:
On 06/15/2014 01:01 AM, Paolo Carlini wrote:
Committed... but, I don't think we are done yet, because it seems to me
that DR577 means that in C++11 mode we have to accept the typedef?!?
Hmm, apparently so. Might as well apply the DR to C++98 mode as well
On Mon, Jun 16, 2014 at 10:01 AM, Bernhard Reutner-Fischer
wrote:
> On 16 June 2014 08:20:09 Janne Blomqvist wrote:
>
>> On Sun, Jun 15, 2014 at 8:23 AM, Bernhard Reutner-Fischer
>> wrote:
>> >
>> >> >> On Tue, May 20, 2014 at 12:42 AM, Janne Blomqvist
>> >> >> wrote:
>> >> >>> On Thu, May 15,
On 06/13/14 19:17, Jakub Jelinek wrote:
On Thu, Jun 12, 2014 at 07:47:49PM +0200, Jakub Jelinek wrote:
Seems http://gcc.gnu.org/r197156 effectively reverted
the PR45078 fix for arm*-linux* (where unfortunately tm_file
is always overridden).
Was the removal of vxworks-dummy.h from that line inte
Richard Sandiford writes:
> Index: gcc/auto-inc-dec.c
> ===
> --- gcc/auto-inc-dec.c2014-06-14 20:08:31.421565177 +0100
> +++ gcc/auto-inc-dec.c2014-06-14 20:08:33.433584004 +0100
> @@ -969,7 +969,7 @@ find_inc (bool
On 16 June 2014 09:39, Janne Blomqvist wrote:
> On Mon, Jun 16, 2014 at 10:01 AM, Bernhard Reutner-Fischer
> wrote:
>> On 16 June 2014 08:20:09 Janne Blomqvist wrote:
>>
>>> On Sun, Jun 15, 2014 at 8:23 AM, Bernhard Reutner-Fischer
>>> wrote:
>>> >
>>> >> >> On Tue, May 20, 2014 at 12:42 AM, Ja
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:
>> > >
>> > > [...]
>> >
>> > Thanks. Looks pretty obvious. I was heading for the door with
> 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
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 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 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 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 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 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.
> > /* 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;
> >
>
> 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
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
> 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
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
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
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
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 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
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 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,
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
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 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
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
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
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
> 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
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
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);
>
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
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
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
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, 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
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: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
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 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
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
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*
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
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
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 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
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 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
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
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
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
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'
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
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
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
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)
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
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, 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, 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
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 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
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?
>
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
> 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
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
>
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 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
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 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
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 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
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 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 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 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 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
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 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
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 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 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 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
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 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)
> -
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
@
> 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
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
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 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)
> >
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 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
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*,
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
1 - 100 of 107 matches
Mail list logo
