On 12/04/2014 01:07 AM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs, because base_checks vector contains
stale statements, and can_remove_asan_check relies on them not to be
there anymore (assumes that all statements in the vector dominate
the current statement, if that is not true, the
Jeff Law wrote:
> >+@item max-fsm-thread-path-insns
> >+Maximum number of instructions to copy when duplicating blocks on a
> >+finite state automaton jump thread path. The default is 100.
> >+
> >+@item max-fsm-thread-length
> >+Maximum number of basic blocks on a finite state automaton jump thre
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Jeff Law
> Sent: Tuesday, December 02, 2014 6:11 AM
> To: Zhenqiang Chen
> Cc: Steven Bosscher; gcc-patches@gcc.gnu.org; Jakub Jelinek
> Subject: Re: [PATCH] Fix PR 61225
>
>
The attached patch removes some remaining mentions of cloog and ppl in our docs.
Tested with “make info html pdf”. OK for trunk?
FX
PS: with this, the remaining mentions of cloog or ppl are comments in
config/isl.m4, graphite.c and graphite-blocking.c. They should probably go away
too, but th
Hi Jason,
ping for https://gcc.gnu.org/ml/gcc-patches/2014-11/msg02975.html,
a proposal to address comments you made on a patch I had sent
earlier on.
> The attached patches combined bootstrap and regtest fine on x86_64-linux.
> We also have nominal test results with our 4.9 based series of comp
10-days ping
This restores bootstrap on a secondary target, target maintainer is OK with it.
I think I need build maintainers approval, so please review.
> when the freshly built g++ is used, we need to pass the appropriate -B
> options. As I understand it, the appropriate place for that is in
Sebastian Pop wrote:
> a fail I have not seen in the past:
>
> FAIL: gcc.c-torture/compile/pr27571.c -Os (internal compiler error)
>
> I am still investigating why this fails: as far as I can see for now this is
> because in copying the FSM path we create an internal loop that is then
> discov
On 02/12/14 22:58, Ramana Radhakrishnan wrote:
On Tue, Nov 11, 2014 at 11:55 AM, Kyrill Tkachov wrote:
Hi all,
This is the arm implementation of the macro fusion hook.
It tries to fuse movw+movt operations together. It also tries to take lo_sum
RTXs into account since those generate movt inst
Hi Eric,
Sorry for the delay, for some reasons despite being a recipient the mail
didn't hit my inbox but only my gcc-patches box.
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Eric Botcazou
>
> > 2014-11-14 Thomas Preud'homme
> >
> > * r
Ping?
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> Sent: Friday, November 28, 2014 3:02 PM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH, contrib] Reduce check_GNU_style noise
>
> Currently check_G
On 03/12/14 20:34 -0800, Tim Shen wrote:
Committed. Does it need to be backported to 4.9? When do we usually do
the backporting?
It depends. If the patch is a bit risky sometimes we'll leave it on
the trunk for a while before backporting in case any problems arise.
I think this change is safe
On Thu, 4 Dec 2014, Thomas Preud'homme wrote:
> Ping?
Ok.
Thanks,
Richard.
> > -Original Message-
> > From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> > ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
> > Sent: Friday, November 28, 2014 3:02 PM
> > To: gcc-patches@gcc.gnu.o
On Wed, 3 Dec 2014, Jakub Jelinek wrote:
> Hi!
>
> As discussed in the PR, ideally this should be done in the middle-end,
> but no fix materialized for it during the last 18 months and is unlikely
> to happen for GCC 5 either, so this patch just restores what the FEs used
> to produce. Bootstrap
Hi all,
The second scan-assembler test for clz\tv\[0-9\]+\.2s FAILs on this test
due to vector costs on A57.
The vectorisation happens for cortex-a53 and thunderx.
I think this test was supposed to test the capability of vectorising clz
rather than the tuning decision of whether to (though I i
On Thu, Dec 4, 2014 at 12:28 AM, Jan Hubicka wrote:
> Hi,
> this patch fixes fold-const folding if EQ/NE_EXPR of ADDR_EXPRS WRT aliases
> and
> weaks. Similarly as my earlier nonzero_address_p patch, it moves the logic
> whether two symbls can resolve to same location to symtab.
>
> The existing
Hi,
As discussed in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00473.html
This patch enables v64qi permutations.
I've checked vshuf* tests from dg-torture.exp,
with avx512* options on sde and generated permutations are correct.
OK for trunk?
---
gcc/config/i386/i386.c | 85 +
On Thu, Dec 4, 2014 at 8:59 AM, Benda Xu wrote:
> Hello,
>
> libc could be installed in a directory prefix. This patch provides
> a way to specify such a prefix for gcc at configuration time.
>
> I have only tested the patch with glibc on amd64, x86 and arm.
> It is logically straightforward. Ple
On Thu, Dec 4, 2014 at 10:02 AM, FX wrote:
> The attached patch removes some remaining mentions of cloog and ppl in our
> docs.
> Tested with “make info html pdf”. OK for trunk?
Ok.
Thanks,
Richard.
> FX
>
>
>
> PS: with this, the remaining mentions of cloog or ppl are comments in
> config/is
Hi Manuel,
thanks for rightfully nagging - I shouldn't do late at night reviews. Regarding:
Manuel López-Ibáñez wrote:
> It is still not clear to me if line_len is the length of the line read
> or not, is it? If not, is there any way to actually get the length of
> the line?
Looking at the code
On 27 November 2014 at 11:27, Renlin Li wrote:
> gcc/ChangeLog:
>
> 2014-11-27 Renlin Li
>
> * config/aarch64/aarch64.c (aarch64_parse_cpu): Don't define
> selected_tune.
> (aarch64_override_options): Use selected_cpu's tuning.
>
OK and this is also broken in 4.9, could you prepare a
Richard Biener writes:
> On Thu, Dec 4, 2014 at 8:59 AM, Benda Xu wrote:
> > Hello,
> >
> > libc could be installed in a directory prefix. This patch provides a
> > way to specify such a prefix for gcc at configuration time.
> >
> > I have only tested the patch with glibc on amd64, x86 and arm.
On Wed, Dec 3, 2014 at 4:24 PM, Tobias Burnus
wrote:
> Dear all,
>
> the attached patches permit an in-tree build of GCC 4.9 using
> CLooG with ISL-0.14 backend and ISL-0.14 - as wished by Richard.
>
> The CLooG patches have been extracted from the CLooG git repository
> and have been included as
For PR62173, the ideal solution is to resolve the problem on tree level ivopt
pass.
While, apart from the tree level issue, PR 62173 also exposed another two RTL
level issues.
one of them is looks like we could improve RTL level loop invariant hoisting by
re-shuffle insns.
for Seb's testcase
Sebastian Pop wrote:
> Sebastian Pop wrote:
> > a fail I have not seen in the past:
> >
> > FAIL: gcc.c-torture/compile/pr27571.c -Os (internal compiler error)
> >
> > I am still investigating why this fails: as far as I can see for now this is
> > because in copying the FSM path we create an
Currently even when I prototype
double exp10 (double);
this function is not available to optimizers for code generation if
they just check for builtin_decl_implicit (BUILT_IN_EXP10).
Curiously though the function is identified as BUILT_IN_EXP10 when
used though, thus the middle-end assumes it ha
Jeff Law wrote:
> I'm a bit worried about compile-time impacts of the all the
> recursion
I will also restrict the recursion to the loop in which we look for the FSM
thread, like this:
diff --git a/gcc/tree-ssa-threadedge.c b/gcc/tree-ssa-threadedge.c
index a6fb361..9a153bb 100644
--- a/gcc/tree-
On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang wrote:
> For PR62173, the ideal solution is to resolve the problem on tree level
> ivopt pass.
>
> While, apart from the tree level issue, PR 62173 also exposed another two
> RTL level issues.
> one of them is looks like we could improve RTL level loop i
On Thu, Dec 4, 2014 at 12:07 PM, Richard Biener
wrote:
> On Thu, Dec 4, 2014 at 12:00 PM, Jiong Wang wrote:
>> For PR62173, the ideal solution is to resolve the problem on tree level
>> ivopt pass.
>>
>> While, apart from the tree level issue, PR 62173 also exposed another two
>> RTL level issues
On Thu, 4 Dec 2014, Richard Biener wrote:
>
> Currently even when I prototype
>
> double exp10 (double);
>
> this function is not available to optimizers for code generation if
> they just check for builtin_decl_implicit (BUILT_IN_EXP10).
> Curiously though the function is identified as BUILT_I
On Wed, Dec 3, 2014 at 4:24 PM, Tobias Burnus
wrote:
> Dear all,
>
> the attached patches permit an in-tree build of GCC 4.9 using
> CLooG with ISL-0.14 backend and ISL-0.14 - as wished by Richard.
>
> The CLooG patches have been extracted from the CLooG git repository
> and have been included as
On Thu, Dec 4, 2014 at 1:49 AM, Ilya Tocar wrote:
> Hi,
>
> As discussed in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00473.html
> This patch enables v64qi permutations.
> I've checked vshuf* tests from dg-torture.exp,
> with avx512* options on sde and generated permutations are correct.
>
>
On Thu, Dec 04, 2014 at 03:54:25AM -0800, H.J. Lu wrote:
> On Thu, Dec 4, 2014 at 1:49 AM, Ilya Tocar wrote:
> > Hi,
> >
> > As discussed in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00473.html
> > This patch enables v64qi permutations.
> > I've checked vshuf* tests from dg-torture.exp,
> > w
On Thu, Dec 4, 2014 at 3:57 AM, Jakub Jelinek wrote:
> On Thu, Dec 04, 2014 at 03:54:25AM -0800, H.J. Lu wrote:
>> On Thu, Dec 4, 2014 at 1:49 AM, Ilya Tocar wrote:
>> > Hi,
>> >
>> > As discussed in https://gcc.gnu.org/ml/gcc-patches/2014-10/msg00473.html
>> > This patch enables v64qi permutatio
On Thu, Dec 04, 2014 at 04:00:27AM -0800, H.J. Lu wrote:
> >> Can you add a few testcases?
> >
> > Isn't it already covered by gcc.dg/torture/vshuf* ?
> >
>
> I didn't see them fail on my machines today.
Those are executable testcases, those better should not fail.
The patch just improved code ge
On 11/27/2014 05:14 PM, Marat Zakirov wrote:
On 11/19/2014 06:01 PM, Marat Zakirov wrote:
Hi all!
Here is the patch which forces ASan to ignore alignment of memory
access. It increases ASan overhead but it's still useful because some
programs like linux kernel often cheat with alignment whi
Hi Matthew, Richard,
Matthew Fortune writes:
> Richard Biener writes:
>> On Thu, Dec 4, 2014 at 8:59 AM, Benda Xu wrote:
>> > Hello,
>> >
>> > libc could be installed in a directory prefix. This patch provides a
>> > way to specify such a prefix for gcc at configuration time.
>> >
>> > I have
Ping.
On 19 Nov 16:34, Ilya Tocar wrote:
> As omp target and offloading support is committed to trunk,
> I think it's reasonable to add some new warnings.
>
> On 06 Nov 15:27, Ilya Tocar wrote:
> > Ping.
> > On 30 Oct 18:31, Ilya Tocar wrote:
> > > Ping.
> > > On 20 Oct 19:26, Ilya Tocar wrote:
>
This is the last patch, moving stpcpy folding. There are still
string function foldings left but those are exclusively GENERIC
now with no chance of advertedly recursing from GIMPLE folding
via GENERIC folding back to GIMPLE folding. I'll deal with those
during next stage1.
Bootstrapped on x86_
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-12-04 Richard Biener
* gimple-fold.c (replace_stmt_with_simplification): Properly
fail when maybe_push_res_to_seq fails.
Index: gcc/gimple-fold.c
=
On Tue, Dec 2, 2014 at 4:28 PM, Yuri Rumyantsev wrote:
> Thanks Richard for your quick reply!
>
> 1. I agree that we can combine predicate_extended_ and
> predicate_arbitrary_ to one function as you proposed.
> 2. What is your opinion about using more simple decision about
> insertion point - if b
On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu wrote:
>> It would probably help reviewers if you pointed to actual path
>> submission [1], which unfortunately contains the explanation in the
>> patch itself [2], which further explains that this functionality is
>> currently only support
On Thu, Dec 4, 2014 at 1:04 PM, Jakub Jelinek wrote:
> On Thu, Dec 04, 2014 at 04:00:27AM -0800, H.J. Lu wrote:
>> >> Can you add a few testcases?
>> >
>> > Isn't it already covered by gcc.dg/torture/vshuf* ?
>> >
>>
>> I didn't see them fail on my machines today.
>
> Those are executable testcase
+address-sanitizer
Please don't hurry with it.
Do you have any numbers on how frequent are unaligned accesses in
kernel? Is it worth addressing at this cost?
size_in_bytes = -1 instrumentation is too slow to be the default in kernel.
If we want to pursue this, I propose a different scheme.
Hand
Hi,
this accepts-invalid is about an invalid loop of the form:
for (int i = 5: arr)
thus it starts with an initialized declaration, which would be legal in
a normal for loop, but then the colon means that it can only be an
invalid range-based for loop. Ideally, it would be nice to say som
On Thu, Dec 4, 2014 at 1:45 PM, Uros Bizjak wrote:
> On Thu, Dec 4, 2014 at 1:04 PM, Jakub Jelinek wrote:
>> On Thu, Dec 04, 2014 at 04:00:27AM -0800, H.J. Lu wrote:
>>> >> Can you add a few testcases?
>>> >
>>> > Isn't it already covered by gcc.dg/torture/vshuf* ?
>>> >
>>>
>>> I didn't see them
... oops, sent the wrong patch. See the below instead.
Paolo.
///
Index: cp/parser.c
===
--- cp/parser.c (revision 218348)
+++ cp/parser.c (working copy)
@@ -10841,6 +10841,7 @@ cp_parser_for_init_statement (cp_parse
On Thu, Dec 4, 2014 at 4:04 AM, Jakub Jelinek wrote:
> On Thu, Dec 04, 2014 at 04:00:27AM -0800, H.J. Lu wrote:
>> >> Can you add a few testcases?
>> >
>> > Isn't it already covered by gcc.dg/torture/vshuf* ?
>> >
>>
>> I didn't see them fail on my machines today.
>
> Those are executable testcase
On Thu, Dec 04, 2014 at 12:30:39PM +0100, Richard Biener wrote:
> > OK for the 4.9 branch?
> I think for a system 0.14 ISL build which I just checked you need to
> adjust the ISL version check as well.
Confirmed. Using additionally the following patch survives bootstrapping
here with
--with-isl=
Nothing sets any more CLOOGLIBS and CLOOGINC - thus, we can
also remove it.
The patch survived bootstrapping. OK?
Tobias
diff --git a/gcc/Makefile.in b/gcc/Makefile.in
index 43405a0..98cff75 100644
--- a/gcc/Makefile.in
+++ b/gcc/Makefile.in
@@ -1006,7 +1006,7 @@ BUILD_LIBDEPS= $(BUILD_LIBIBER
Richard,
I did simple change by saving gsi iterator for each bb that has
critical edges by adding additional field to bb_predicate_s:
typedef struct bb_predicate_s {
/* The condition under which this basic block is executed. */
tree predicate;
/* PREDICATE is gimplified, and the sequence
FX writes:
> 10-days ping
> This restores bootstrap on a secondary target, target maintainer is OK with
> it. I think I need build maintainers approval, so please review.
While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
now bootstraps, but 32-bit (i386-apple-darwin14.0.0)
On Thu, Dec 4, 2014 at 2:04 PM, Tobias Burnus
wrote:
> Nothing sets any more CLOOGLIBS and CLOOGINC - thus, we can
> also remove it.
>
> The patch survived bootstrapping. OK?
Ok.
Thanks,
Richard.
> Tobias
>
>
> diff --git a/gcc/Makefile.in b/gcc/Makefile.in
> index 43405a0..98cff75 100644
> --
On Thu, Dec 4, 2014 at 2:01 PM, Tobias Burnus
wrote:
> On Thu, Dec 04, 2014 at 12:30:39PM +0100, Richard Biener wrote:
>> > OK for the 4.9 branch?
>> I think for a system 0.14 ISL build which I just checked you need to
>> adjust the ISL version check as well.
>
> Confirmed. Using additionally the
> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
> now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not:
Is it due to my patch, or pre-existing bootstrap failure?
How do you configure this 32-bit compiler? target/build/host/CFLAGS/CXXFLAGS/etc
FX
On Thu, Dec 4, 2014 at 2:15 PM, Yuri Rumyantsev wrote:
> Richard,
>
> I did simple change by saving gsi iterator for each bb that has
> critical edges by adding additional field to bb_predicate_s:
>
> typedef struct bb_predicate_s {
>
> /* The condition under which this basic block is executed.
Hi Rainer,
On 4 Dec 2014, at 13:32, Rainer Orth wrote:
> FX writes:
>
>> 10-days ping
>> This restores bootstrap on a secondary target, target maintainer is OK with
>> it. I think I need build maintainers approval, so please review.
>
> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-appl
FX writes:
>> While in my testing, 64-bit Mac OS X 10.10.1 (x86_64-apple-darwin14.0.0)
>> now bootstraps, but 32-bit (i386-apple-darwin14.0.0) does not:
>
> Is it due to my patch, or pre-existing bootstrap failure?
I can't tell: before your patch, 32-bit bootstrap was broken due to PR
bootstrap/
On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
size_in_bytes = -1 instrumentation is too slow to be the default in kernel.
If we want to pursue this, I propose a different scheme.
Handle 8+ byte accesses as 1/2/4 accesses. No changes to 1/2/4 access handling.
Currently when we allocate, say, 17-by
On Thu, Dec 4, 2014 at 2:47 PM, Richard Biener
wrote:
> On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
>> Hi Rainer,
>>
>> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>>
>>> FX writes:
>>>
10-days ping
This restores bootstrap on a secondary target, target maintainer is OK with
On Thu, Dec 4, 2014 at 2:48 PM, Richard Biener
wrote:
> On Thu, Dec 4, 2014 at 2:47 PM, Richard Biener
> wrote:
>> On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
>>> Hi Rainer,
>>>
>>> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>>>
FX writes:
> 10-days ping
> This restore
> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC
> _won't_ override -mdynamic-no-pic, so that's not a simple way out]
> This means that the PIC library is being built with non-pic relocs.
config/mh-darwin says tha
On Thu, Dec 4, 2014 at 2:52 PM, FX wrote:
>> The default BOOT_CFLAGS are: -O2 -g -mdynamic-no-pic
>> the libiberty pic build appends: -fno-common (and not even -fPIC) [NB -fPIC
>> _won't_ override -mdynamic-no-pic, so that's not a simple way out]
>> This means that the PIC library is being built
On 04 Dec 13:51, Uros Bizjak wrote:
> On Thu, Dec 4, 2014 at 1:45 PM, Uros Bizjak wrote:
> > On Thu, Dec 4, 2014 at 1:04 PM, Jakub Jelinek wrote:
> >> On Thu, Dec 04, 2014 at 04:00:27AM -0800, H.J. Lu wrote:
> >>> >> Can you add a few testcases?
> >>> >
> >>> > Isn't it already covered by gcc.dg/
On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov wrote:
> On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
>>
>> size_in_bytes = -1 instrumentation is too slow to be the default in
>> kernel.
>>
>> If we want to pursue this, I propose a different scheme.
>> Handle 8+ byte accesses as 1/2/4 accesses. No cha
OK.
Jason
On 02 Dec 12:21, Uros Bizjak wrote:
> On Tue, Dec 2, 2014 at 12:08 PM, Ilya Enkovich wrote:
>
> >> > Having stage1 close to end, may we make some decision regarding this
> >> > patch? Having a couple of working variants, may we choose and use one
> >> > of them?
> >>
> >> I propose to wait for Vl
On Thu, Dec 4, 2014 at 2:43 PM, Iain Sandoe wrote:
> Hi Rainer,
>
> On 4 Dec 2014, at 13:32, Rainer Orth wrote:
>
>> FX writes:
>>
>>> 10-days ping
>>> This restores bootstrap on a secondary target, target maintainer is OK with
>>> it. I think I need build maintainers approval, so please review.
On 04/12/14 11:39 +, Jonathan Wakely wrote:
On 03/12/14 23:32 +0100, François Dumont wrote:
On 03/12/2014 16:59, Jonathan Wakely wrote:
François (or anyone else), do you see any problem with this change?
It makes the code shorter and I think is much easier to read, it also
reduces the memo
On 12/04/2014 05:04 PM, Dmitry Vyukov wrote:
On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov wrote:
On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
size_in_bytes = -1 instrumentation is too slow to be the default in
kernel.
If we want to pursue this, I propose a different scheme.
Handle 8+ byte acc
On Thu, Dec 4, 2014 at 2:53 PM, Ilya Tocar wrote:
>> >>> >> Can you add a few testcases?
>> >>> >
>> >>> > Isn't it already covered by gcc.dg/torture/vshuf* ?
>> >>> >
>> >>>
>> >>> I didn't see them fail on my machines today.
>> >>
>> >> Those are executable testcases, those better should not fa
On 04/12/14 14:11 +, Jonathan Wakely wrote:
Although this touches almost every line of the hashtable.h and
hastable_policy.h files, it's mostly mechanical. The main purpose is
to replace every use of X* with a typedef like X_pointer, which comes
from the allocator. In the common case it's jus
Sebastian Pop wrote:
> Jeff Law wrote:
> > I'm a bit worried about compile-time impacts of the all the
> > recursion
>
> I will also restrict the recursion to the loop in which we look for the FSM
> thread.
The attached patch includes this change. It passed bootstrap and regression
test on x86_6
Committed.
Richard.
2014-12-04 Richard Biener
* doc/match-and-simplify.texi: Update for recent changes.
Index: doc/match-and-simplify.texi
===
--- doc/match-and-simplify.texi (revision 218352)
+++ doc/match-and-simplify
Hi,
This patch adds a check for stpcpy function into
gcc.target/i386/chkp-strlen-2.c test.
make check RUNTESTFLAGS="i386.exp=chkp-strlen-2.c" is OK. OK for trunk?
Thanks,
Ilya
--
2014-12-04 Ilya Enkovich
PR target/64056
* lib/target-supports.exp (check_effective_target_stpc
Hi Ilya,
> This patch adds a check for stpcpy function into
> gcc.target/i386/chkp-strlen-2.c test.
>
> make check RUNTESTFLAGS="i386.exp=chkp-strlen-2.c" is OK. OK for trunk?
>
> Thanks,
> Ilya
> --
> 2014-12-04 Ilya Enkovich
>
> PR target/64056
> * lib/target-supports.exp (check
Hi,
The issue is that lookup_destructor calls
adjust_result_of_qualified_name_lookup
with an NULL_TREE decl (returned by lookup_member). So error-message
is missing.
As already discussed in bug-tracker:
ChangeLog
2014-12-04 Kai Tietz
PR c++/64100
* typeck.c (lookup_destructor): Ha
On Thu, 4 Dec 2014, Richard Biener wrote:
> Currently even when I prototype
>
> double exp10 (double);
>
> this function is not available to optimizers for code generation if
> they just check for builtin_decl_implicit (BUILT_IN_EXP10).
> Curiously though the function is identified as BUILT_IN_E
Hi,
this patch fixes an ICE happening on invalid code for < c++11. It is
reasoned by
accessing blindly identifier without checking that it is a declaration.
ChangeLog
2014-12-04 Kai Tietz
PR c++/64127
* parser.c (cp_parser_diagnose_invalid_type_name): Check
id for being a declar
On Thu, 4 Dec 2014, Joseph Myers wrote:
> On Thu, 4 Dec 2014, Richard Biener wrote:
>
> > Currently even when I prototype
> >
> > double exp10 (double);
> >
> > this function is not available to optimizers for code generation if
> > they just check for builtin_decl_implicit (BUILT_IN_EXP10).
>
On 04 Dec 15:58, Rainer Orth wrote:
> Hi Ilya,
>
>
> > This patch adds a check for stpcpy function into
> > gcc.target/i386/chkp-strlen-2.c test.
> >
> > make check RUNTESTFLAGS="i386.exp=chkp-strlen-2.c" is OK. OK for trunk?
> >
> > Thanks,
> > Ilya
> > --
> > 2014-12-04 Ilya Enkovich
> >
>
> Can you try adding it as
>
> T_CFLAGS += -mdynamic-no-pic
>
> in gcc/config/t-tarwin instead?
Nope, doing so fails to link libgcc_s.dylib:
/Users/fx/devel/gcc/i/./gcc/xgcc -B/Users/fx/devel/gcc/i/./gcc/
-B/Users/fx/devel/gcc/i2/i386-apple-darwin14.0.0/bin/
-B/Users/fx/devel/gcc/i2/i386-appl
On Thu, 4 Dec 2014, Richard Biener wrote:
> So what does this all mean in practice for optimization passes?
I don't know what it means in terms of how to fix the various existing
problems - it's simply how I think a fixed compiler should behave.
> When b) does not apply then the given stpcpy sp
Hi,
this patch adds INDIRECT_REF support to cxx_eval_store_expression handling.
There is a different variant suggested by Marek, which adds additional
operand-0 to ref, which looks to me wrong.
ChangeLog gcc/cp
2014-12-04 Kai Tietz
PR c++/64106
* constexpr.c (cxx_eval_store_expressio
On Thu, 4 Dec 2014, Joseph Myers wrote:
> On Thu, 4 Dec 2014, Richard Biener wrote:
>
> > So what does this all mean in practice for optimization passes?
>
> I don't know what it means in terms of how to fix the various existing
> problems - it's simply how I think a fixed compiler should behav
On 4 Dec 2014, at 15:24, FX wrote:
>> Can you try adding it as
>>
>> T_CFLAGS += -mdynamic-no-pic
>>
>> in gcc/config/t-tarwin instead?
>
-mdynamic-no-pic should be used to build *host* executable stuff for m32 darwin.
It is not suitable for building shared libraries (hence the problem with
On Thu, 4 Dec 2014, Richard Biener wrote:
> OTOH this also means the user cannot provide a conforming
> implementation on his own and get that used by GCC without editing
> system headers or including a header with -isystem or similar
> tricks.
Well - you could have a pragma / attribute for that
The PR shows a case in which fold introduces undefined behavior in a
valid program, because what it does here is
-(long int) (ul + ULONG_MAX) - 1 ->
~(long int) (ul + ULONG_MAX) ->
-(long int) ul
But the latter transformation is wrong if ul is unsigned long and equals
LONG_MAX + 1UL, because that i
On Thu, Dec 04, 2014 at 04:00:34PM +0100, Kai Tietz wrote:
> Hi,
>
> The issue is that lookup_destructor calls
> adjust_result_of_qualified_name_lookup
> with an NULL_TREE decl (returned by lookup_member). So error-message
> is missing.
>
> As already discussed in bug-tracker:
>
> ChangeLog
>
On Thu, Dec 04, 2014 at 04:12:02PM +0100, Kai Tietz wrote:
> Hi,
>
> this patch fixes an ICE happening on invalid code for < c++11. It is
> reasoned by
> accessing blindly identifier without checking that it is a declaration.
>
> ChangeLog
>
> 2014-12-04 Kai Tietz
>
> PR c++/64127
>
2014-12-04 16:46 GMT+01:00 Marek Polacek :
> On Thu, Dec 04, 2014 at 04:00:34PM +0100, Kai Tietz wrote:
>> Hi,
>>
>> The issue is that lookup_destructor calls
>> adjust_result_of_qualified_name_lookup
>> with an NULL_TREE decl (returned by lookup_member). So error-message
>> is missing.
>>
>> As
On 12/1/2014 11:57 AM, Jeff Law wrote:
Prior to reload (ie, in DSE1) there's a bit of magic in that we do not
set frame_read on call insns. That may in fact be wrong and possibly
the source of the problem.
/* This field is only used for the processing of const functions.
These functions
2014-12-04 16:47 GMT+01:00 Marek Polacek :
> On Thu, Dec 04, 2014 at 04:12:02PM +0100, Kai Tietz wrote:
>> Hi,
>>
>> this patch fixes an ICE happening on invalid code for < c++11. It is
>> reasoned by
>> accessing blindly identifier without checking that it is a declaration.
>>
>> ChangeLog
>>
>>
> 2014-11-19 Sandra Loosemore
>
> gcc/
> * simplify-rtx.c (simplify_relational_operation_1): Handle
> simplification identities for BICS patterns.
>
> gcc/testsuite/
> * gcc.target/aarch64/bics_4.c: New.
OK for mainline, but there are trailing spaces in the patch
On Thu, Dec 04, 2014 at 04:59:21PM +0100, Kai Tietz wrote:
> Same as said before. Issue is a invalid-code bug with ICE, and
> error-messages are pretty meaningless. It would be helpful to have in
> testsuite just the opportunity to test for no ICE.
You can add just // { dg-error "" } on all line
On December 4, 2014 4:45:25 PM CET, Marek Polacek wrote:
>The PR shows a case in which fold introduces undefined behavior in a
>valid program, because what it does here is
>-(long int) (ul + ULONG_MAX) - 1 ->
>~(long int) (ul + ULONG_MAX) ->
>-(long int) ul
>But the latter transformation is wrong
On Thu, Dec 4, 2014 at 4:44 AM, Uros Bizjak wrote:
> On Wed, Dec 3, 2014 at 10:35 PM, H.J. Lu wrote:
>
>>> It would probably help reviewers if you pointed to actual path
>>> submission [1], which unfortunately contains the explanation in the
>>> patch itself [2], which further explain
On Thu, Dec 4, 2014 at 5:16 PM, Yury Gribov wrote:
> On 12/04/2014 05:04 PM, Dmitry Vyukov wrote:
>>
>> On Thu, Dec 4, 2014 at 4:48 PM, Yury Gribov wrote:
>>>
>>> On 12/04/2014 03:47 PM, Dmitry Vyukov wrote:
size_in_bytes = -1 instrumentation is too slow to be the default in
k
On Thu, Dec 4, 2014 at 8:06 PM, 'Dmitry Vyukov' via address-sanitizer
wrote:
> You answered your own question about user space :)
Yeah, I hoped someone would rush to overpersuade me...
-Y
>
> I think you want get_addr_base_and_unit_offset here. But I really wonder
I copied what I found in tree-ssa-alias. The differenc eis that
get_addr_base_and_unit_offset won't give a range for variable sized accesses
right?
> what cases this code catches that the code in fold_comparison you t
>
> I did not really like it either (although I must say that in general I
> really dislike the need to call expand_thunk but telling it to not
Yeah, I am thinking about simply teaching inliner to handle them. Given the
issues
with extra copies for values passed by reference it may be better so
1 - 100 of 147 matches
Mail list logo
