Am 11.11.2013 19:18, schrieb Cary Coutant:
But for "USE mod_name, only: nml", one is supposed to generate a
DW_TAG_imported_declaration.
And there I am stuck. For normal variables, the DW_TAG_imported_declaration
refers to a DW_TAG_variable die. Analogously, for a namelist one would have
to refe
Hello,
On 07 Nov 15:42, Kirill Yukhin wrote:
> Could you pls take a look?
Ping?
--
Thanks, K
> Hmm, at -O0 we should be able to coalesce all SSA names of a
> DECL. So in theory the following should work:
Yes, the attached patch introduces no regressions in the testsuite. How
robust is that though? Do we need some checking for it?
* cfgexpand.c (expand_used_vars): Allocate sp
This is OK, thanks for catching the pasto!
Only...
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index 430d562..b8cb871 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
> @@ -3974,10 +3974,10 @@ ix86_option_override_internal (bool main_args_p,
>if (fla
Hello,
I would like to propose the activation by default of -Wreturn-type.
The main objective would to provide a warning for such code:
int foo() {
return;
}
For now, it is only enabled when we have -Wall:
$ gcc -c foo.c
$ gcc -Wall -c foo.c
foo.c: In function ‘foo’:
foo.c:2:2: warning:
On Tue, Nov 12, 2013 at 11:05:45AM +0100, Jan Hubicka wrote:
> > @@ -16576,7 +16576,7 @@ ix86_avx256_split_vector_move_misalign (rtx
> > op0, rtx op1)
> >
> >if (MEM_P (op1))
> > {
> > - if (TARGET_AVX256_SPLIT_UNALIGNED_LOAD)
> > + if (!TARGET_AVX2 && TARGET_AVX256_SPLIT_UNALIG
Richard, Jakub,
You are right regarding the cost model if we talk about vectorizer alone.
But the #pragma omp simd goes beyond the vectorizer - it introduces
parallel context in a place user defines, similar to #pragma omp parallel.
Are we applying any cost model for omp parallel region?
You can
On Tue, Nov 12, 2013 at 01:16:14AM +0100, Marc Glisse wrote:
> On Mon, 11 Nov 2013, Ondřej Bílka wrote:
>
> >On Sun, Nov 10, 2013 at 04:27:00PM +0100, Marc Glisse wrote:
> >>Hello,
> >>
> >>I am posting this patch to get some feedback on the approach. The
> >>goal is to replace malloc+free with a
On 12/11/13 06:59, Joey Ye wrote:
> For RTOS who need to relocate executable, PC relative and GOTOFF cannot be
> used as the offset between any sections won't be fixed. Only GOT can be
> used, just as VxWorks RTP does.
>
> This patch introduces a new option enable user to choose between fixed
> of
On Tue, Nov 12, 2013 at 02:48:46PM +0400, Sergey Ostanevich wrote:
> You are right regarding the cost model if we talk about vectorizer alone.
> But the #pragma omp simd goes beyond the vectorizer - it introduces
> parallel context in a place user defines, similar to #pragma omp parallel.
> Are we
The patch is at:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg00308.html
and an Ada testcase at:
http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00910.html
Thanks in advance.
--
Eric Botcazou
This patch quashes a -Wmaybe-uninitialized warning that showed up
when running bootstrap with asan/ubsan. Supposedly in that case
we aren't able to preinitialize label with the first element of the
label_pairs vector.
Regtested/bootstrapped on x86_64-linux, ok for trunk?
2013-11-12 Marek Polace
Hello,
Patch in the bottom extends some hooks toward AVX-512 support.
This patch decrease icount for Spec2006 FP suite (ref set):
Optset was: -static -m64 -fstrict-aliasing -fno-prefetch-loop-arrays
-Ofast -funroll-loops -flto -march=core-avx2 -mtune=core-avx2
Lower is better.
Test\ArchI
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
I am trying to get something to actually work and be accepted in
gcc. That may mean being conservative.
That also may mean that you will cover only cases where it is not needed.
A malloc will have a small per-thread cache for small requests that does
n
yes, ICC ignores cost analysis and follows user request on introduction of
simd parallelism in the loop.they follow the omp parallel semantics.
On Tue, Nov 12, 2013 at 3:05 PM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 02:48:46PM +0400, Sergey Ostanevich wrote:
>> You are right regarding the
On Tue, Nov 12, 2013 at 04:45:17PM +0400, Sergey Ostanevich wrote:
> yes, ICC ignores cost analysis and follows user request on introduction of
> simd parallelism in the loop.they follow the omp parallel semantics.
What about #pragma ivdep? I.e. if we decided to follow ICC here, should
we ignore
On 11-11-13 14:17, Richard Biener wrote:
On Mon, 11 Nov 2013, Tom de Vries wrote:
On 11/11/13 10:50, Richard Biener wrote:
On Sat, 9 Nov 2013, Tom de Vries wrote:
Bootstrapped and regtested on x86_64.
OK for trunk?
Comments inline
diff --git a/gcc/tree-ssa-tail-merge.c b/gcc/tree-ssa-tai
On Tue, Nov 12, 2013 at 8:52 AM, Uros Bizjak wrote:
> On Mon, Nov 11, 2013 at 8:52 PM, Ian Lance Taylor wrote:
>> On Fri, Nov 8, 2013 at 1:10 AM, Uros Bizjak wrote:
>>>
>>> panic: runtime error: invalid memory address or nil pointer dereference
>>> [signal 0xb code=0x1 addr=0x1c]
>
>>> FAIL: run
On Tue, Nov 12, 2013 at 2:26 AM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 11:05:45AM +0100, Jan Hubicka wrote:
>> > @@ -16576,7 +16576,7 @@ ix86_avx256_split_vector_move_misalign (rtx
>> > op0, rtx op1)
>> >
>> >if (MEM_P (op1))
>> > {
>> > - if (TARGET_AVX256_SPLIT_UNALIGNED_L
Hi,
in this very old issue we reject:
void f(int,int);
void f(int,int,int);
void g ()
{
(&f)(1,2,3);
}
with "address of overloaded function with no contextual type information".
It seems to me that handling the ADDR_EXPR close to the beginning of
finish_call_expr goes a long way toward f
ivdep just substitutes all cross-iteration data analysis,
nothing related to cost model. ICC does not cancel its
cost model in case of #pragma ivdep
as for the safelen - OMP standart treats it as a limitation
for the vector length. this means if no safelen is present
an arbitrary vector length can
Hi!
Could a global maintainer or build machinery maintainer please review the
two unreviewed patches posted in this series?
On Mon, 4 Nov 2013 10:13:39 -0800, Cary Coutant wrote:
> >> Ping. To sum it up, with these patches applied, there are no changes for
> >> a "regular" build (not using the
I checked in this patch to turn on SEE unaligned load and store for
Haswell. OK for 4.8?
Thanks.
H.J.
---
2013-11-12 H.J. Lu
PR target/59088
* config/i386/x86-tune.def (X86_TUNE_SSE_UNALIGNED_LOAD_OPTIMAL):
Set for m_HASWELL.
(X86_TUNE_SSE_UNALIGNED_STORE_OPTIM
Hi,
On Mon, Nov 11, 2013 at 10:15:24AM -0700, Aldy Hernandez wrote:
> On 11/07/13 10:58, Martin Jambor wrote:
>
> >Sorry for the delay. I'd just like to re-iterate one comment from my
> >previous email which is that I do not think tree-sra.c should export
> >any function to the outside world apa
On Thu, Nov 07, 2013 at 06:24:55PM -0800, Cong Hou wrote:
> Ping. OK for the trunk?
> On Fri, Nov 1, 2013 at 10:47 AM, Cong Hou wrote:
> > It seems that on some platforms the loops in
> > testsuite/gcc.dg/vect/pr58508.c may be unable to be vectorized. This
> > small patch added { dg-require-effect
On Tue, Nov 12, 2013 at 05:46:14PM +0400, Sergey Ostanevich wrote:
> ivdep just substitutes all cross-iteration data analysis,
> nothing related to cost model. ICC does not cancel its
> cost model in case of #pragma ivdep
>
> as for the safelen - OMP standart treats it as a limitation
> for the ve
On Tue, Nov 12, 2013 at 2:55 PM, H.J. Lu wrote:
> I checked in this patch to turn on SEE unaligned load and store for
> Haswell. OK for 4.8?
>
> Thanks.
>
> H.J.
> ---
> 2013-11-12 H.J. Lu
>
> PR target/59088
> * config/i386/x86-tune.def (X86_TUNE_SSE_UNALIGNED_LOAD_OPTIMAL):
>
On 11/12/13 2:03 PM, Tom de Vries wrote:
> On 11-11-13 14:17, Richard Biener wrote:
>> On Mon, 11 Nov 2013, Tom de Vries wrote:
>>
>>> On 11/11/13 10:50, Richard Biener wrote:
On Sat, 9 Nov 2013, Tom de Vries wrote:
> Bootstrapped and regtested on x86_64.
>
> OK for trunk?
>>>
On 11/12/13 3:16 PM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 05:46:14PM +0400, Sergey Ostanevich wrote:
>> ivdep just substitutes all cross-iteration data analysis,
>> nothing related to cost model. ICC does not cancel its
>> cost model in case of #pragma ivdep
>>
>> as for the safelen - OMP
Ian Lance Taylor writes:
> On Fri, Nov 8, 2013 at 4:01 AM, Rainer Orth
> wrote:
>> The recent Go patch (couldn't find the submission on gcc-patches) broke
>> Solaris bootstrap: on Solaris 10/x86 I get
>>
>> /vol/gcc/src/hg/trunk/local/libgo/go/net/tcpsockopt_unix.go:26:103: error:
>> reference
On Fri, Nov 8, 2013 at 8:20 AM, Teresa Johnson wrote:
> On Fri, Nov 8, 2013 at 8:14 AM, Steven Bosscher wrote:
>> On Fri, Nov 8, 2013 at 4:45 PM, Teresa Johnson wrote:
>>> On Tue, May 14, 2013 at 3:47 PM, Steven Bosscher wrote:
>>> I'd like to revisit this old patch from Sri to generate a label f
On Tue, Nov 12, 2013 at 01:41:24PM +0100, Marc Glisse wrote:
> On Tue, 12 Nov 2013, Ondřej Bílka wrote:
>
> >>I am trying to get something to actually work and be accepted in
> >>gcc. That may mean being conservative.
> >
> >That also may mean that you will cover only cases where it is not needed.
On Tue, Nov 12, 2013 at 12:55:17AM +0100, Marc Glisse wrote:
> On Mon, 11 Nov 2013, Richard Biener wrote:
>
> >On Sun, Nov 10, 2013 at 4:27 PM, Marc Glisse wrote:
> >>Hello,
> >>
> >>I am posting this patch to get some feedback on the approach. The goal is to
> >>replace malloc+free with a stack
On Tue, Nov 12, 2013 at 03:35:13PM +0100, Richard Biener wrote:
> > Anyway, in that case I think the originally posted patch is wrong,
> > if we want to treat force_vect as disregard all the cost model and
> > force vectorization (well, the name of the field already kind of suggest
> > that), then
Ian Lance Taylor writes:
> On Tue, Nov 12, 2013 at 6:43 AM, Rainer Orth
> wrote:
>>
>> works on Solaris 11, but not on Solaris 9 and 10 which lack
>> TCP_KEEPALIVE_THRESHOLD.
>
> Do they have any facility for changing the keepalive timers?
There's TCP_KEEPALIVE which is already used in tcpsocko
On Tue, 12 Nov 2013, Iyer, Balaji V wrote:
>> Are you linking with -nostdlib or something similar? IIRC those
>> routines are provided by libc on *bsd*. On other systems you may need
>> to link in libdl via -ldl.
> Yes, I am. In my system SUSE, I need to explicitly link it.
>> I'm sure there's
On Tue, Nov 12, 2013 at 6:43 AM, Rainer Orth
wrote:
>
> works on Solaris 11, but not on Solaris 9 and 10 which lack
> TCP_KEEPALIVE_THRESHOLD.
Do they have any facility for changing the keepalive timers?
Ian
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
Anyway you need a better analysis to determine if user called realloc on
converted pointer.
Note that I am checking if the argument of free is the same as the return
value of malloc by looking at the SSA_NAME, not the C variable. If the
user called re
On 11/12/2013 05:26 AM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 11:05:45AM +0100, Jan Hubicka wrote:
>>> @@ -16576,7 +16576,7 @@ ix86_avx256_split_vector_move_misalign (rtx
>>> op0, rtx op1)
>>>
>>>if (MEM_P (op1))
>>> {
>>> - if (TARGET_AVX256_SPLIT_UNALIGNED_LOAD)
>>> +
Hello,
Below is the updated patch amended to take your previous comments in
account.
In add_file_to_cache_tab the evicted cache array entry is the one that
was less used.
Incidentally I also fixed some thinkos and issued that I have seen in
the previous patch.
Bootstrapped on x86_64-unknown-lin
On Tue, Nov 12, 2013 at 10:39:28AM -0500, Vladimir Makarov wrote:
> >> Shall we also disable argument accumulation for cores? It seems we won't
> >> solve the IRA issues, right?
> > You mean LRA issues here, right? If you are starting to use
> > no-accumulate-outgoing-args much more often than in
Please add a comment citing 13.3.1.1. OK with that change.
Jason
On Tue, Nov 12, 2013 at 3:49 PM, Teresa Johnson wrote:
>> Is there a format for compiler-defined labels that would not be able
>> to clash with other user-generated labels?
>
> My understanding is that the "." in the generated name ensures that it
> will not clash with user-generated labels which c
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
On Tue, Nov 12, 2013 at 01:41:24PM +0100, Marc Glisse wrote:
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
I am trying to get something to actually work and be accepted in
gcc. That may mean being conservative.
That also may mean that you will cover only
Richi,
i am having a little trouble putting this back the way that you want.
The issue is rem.
what is supposed to happen for INT_MIN % -1?
I would assume because i am failing the last case of
gcc.dg/c90-const-expr-8.c that INT_MIN %-1 should not overflow even if
INT_MIN / -1 does. howev
On 11/12/13 06:56, Martin Jambor wrote:
+
+/* Given an expression, return an adjustment entry specifying the
+ transformation to be done on EXPR. If no suitable adjustment entry
+ was found, returns NULL.
+
+ If IGNORE_DEFAULT_DEF is set, consider SSA_NAMEs which are not a
+ default def
On Tue, 12 Nov 2013, Kenneth Zadeck wrote:
> Richi,
>
> i am having a little trouble putting this back the way that you want. The
> issue is rem.
> what is supposed to happen for INT_MIN % -1?
>
> I would assume because i am failing the last case of gcc.dg/c90-const-expr-8.c
> that INT_MIN %-1
On Tue, Nov 12, 2013 at 7:16 AM, Gerald Pfeifer wrote:
> On Tue, 12 Nov 2013, Iyer, Balaji V wrote:
>>> Are you linking with -nostdlib or something similar? IIRC those
>>> routines are provided by libc on *bsd*. On other systems you may need
>>> to link in libdl via -ldl.
>> Yes, I am. In my sys
On 28/06/13 12:41, Christophe Lyon wrote:
> Hi,
> Following the discussion on
> http://gcc.gnu.org/ml/gcc/2013-05/msg00208.html
> here is a patch to change the frame direction.
>
> Passed 'make check' with no regression on aarch64-none-linux-gnu and
> with a few UNSUPPORTED -> PASS on aarch64-none
On Wed, 2013-11-06 at 17:32 +, Marcus Shawcroft wrote:
> Exactly, hard wiring the newlib interface into the configury of other
> libraries is questionable, but the patch applied to libgfortran goes
> beyond hard wiring details of the interface, it hard wires incorrect
> details of the interfac
On 11/10/13 20:11, Jeff Law wrote:
OK. It sounds like there's a pretty general consensus that we ought ot
go ahead and leave in a load/store of a NULL pointer. I'll go ahead and
run with that. I'll probably just emit SSA_NAME = *0, unless someone
thinks we ought ot distinguish between loads an
On 11/12/2013 11:27 AM, Joseph S. Myers wrote:
On Tue, 12 Nov 2013, Kenneth Zadeck wrote:
Richi,
i am having a little trouble putting this back the way that you want. The
issue is rem.
what is supposed to happen for INT_MIN % -1?
I would assume because i am failing the last case of gcc.dg/c
+/* Operation to be performed for the parameter in ipa_parm_adjustment
+ below. */
+enum ipa_parm_op {
+ IPA_PARM_OP_NONE,
+
+ /* This describes a brand new parameter.
+
+ For new parameters, base_index must be >= the number of
+ DECL_ARGUMENTS in the function. That is, new argumen
On Tue, Nov 12, 2013 at 05:01:31PM +0100, Marc Glisse wrote:
> On Tue, 12 Nov 2013, Ondřej Bílka wrote:
>
> >On Tue, Nov 12, 2013 at 01:41:24PM +0100, Marc Glisse wrote:
> >>On Tue, 12 Nov 2013, Ondřej Bílka wrote:
> >>
> I am trying to get something to actually work and be accepted in
> g
On Tue, 12 Nov 2013, Jeff Law wrote:
Here's a patch which arranges to leave a null pointer dereferece in the IL.
For a memory load through a null pointer, we just leave the statement as-is
since the LHS is going to be a throw-away SSA_NAME. For a store through a
null pointer, we try to simpli
On Tue, Nov 12, 2013 at 7:54 AM, Steven Bosscher wrote:
> On Tue, Nov 12, 2013 at 3:49 PM, Teresa Johnson wrote:
>>> Is there a format for compiler-defined labels that would not be able
>>> to clash with other user-generated labels?
>>
>> My understanding is that the "." in the generated name ensu
> This patch quashes a -Wmaybe-uninitialized warning that showed up
> when running bootstrap with asan/ubsan. Supposedly in that case
> we aren't able to preinitialize label with the first element of the
> label_pairs vector.
>
> Regtested/bootstrapped on x86_64-linux, ok for trunk?
>
> 2013-11-
> in Ada 2012 it is allowed to omit components of aggregates (the equivalent
> of initializers/constructors); in this case, the contents of the
> corresponding fields in the record become undefined. Now the gimplifier
> implements the C semantics of clearing the missing components, so this
> patch
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
Seems to be missing some bits.
A example, its purpose is to show a idea not to be complete.
I agree, but when too many bits are missing or wrong I fail to get the
idea :-(
How will you find small constant allocations with this in place?
I won't.
It has been a week since the libsanitizer patches were checked in, which broke
the PowerPC64 Linux system along with others (PR 59009 for powerpc). Please
revert these patches while you are working on proper fixes for all of the hosts
and targets.
Quoting from the GCC development plan:
Patch Rev
This patch adds support for the C11 keyword _Thread_local.
Semantically it's essentially the same as __thread, except that it
doesn't have the GNU C ordering restriction on __thread appearing
before extern or static.
Bootstrapped with no regressions on x86_64-unknown-linux-gnu. Applied
to mainlin
[plain text]
So far I was not able to reproduce the compilation failure -- and I am
asking someone from the PowerPC side to help.
Please apply any minimal #ifdef patch to
sanitizer_platform_limits_linux.cc to make it compile, while keeping
x86_64 tests pass.
If we revert the patch now, I will not
or, alternatively, we can disable libsanitizer on PowerPC if the
PowerPC community does not care enough about it being healthy.
On Tue, Nov 12, 2013 at 9:41 AM, Kostya Serebryany wrote:
> [plain text]
> So far I was not able to reproduce the compilation failure -- and I am
> asking someone from t
On 11/12/13 10:14, Marc Glisse wrote:
On Tue, 12 Nov 2013, Jeff Law wrote:
Here's a patch which arranges to leave a null pointer dereferece in
the IL. For a memory load through a null pointer, we just leave the
statement as-is since the LHS is going to be a throw-away SSA_NAME.
For a store thro
Hi Jakub
Thank you for pointing it out. The updated patch is pasted below. I
will pay attention to it in the future.
thanks,
Cong
diff --git a/gcc/testsuite/ChangeLog b/gcc/testsuite/ChangeLog
index 3d9916d..32a6ff7 100644
--- a/gcc/testsuite/ChangeLog
+++ b/gcc/testsuite/ChangeLog
@@ -1,3 +
On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote:
> or, alternatively, we can disable libsanitizer on PowerPC if the
> PowerPC community does not care enough about it being healthy.
I think there should be a global --enable-libsanitizer or whatever option that
would allow people t
On Tue, Nov 12, 2013 at 10:04:15AM -0800, Cong Hou wrote:
> Thank you for pointing it out. The updated patch is pasted below. I
> will pay attention to it in the future.
Ok, thanks.
Note, you can use dg-additional-options if needed in g*.dg/vect/, just not
dg-options.
> --- a/gcc/testsuite/Change
On Tue, Nov 12, 2013 at 10:04 AM, Michael Meissner
wrote:
> On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote:
>> or, alternatively, we can disable libsanitizer on PowerPC if the
>> PowerPC community does not care enough about it being healthy.
>
> I think there should be a global
On Tue, 12 Nov 2013, Jeff Law wrote:
On 11/12/13 10:14, Marc Glisse wrote:
You didn't like Jakub's comment about __builtin_unreachable?
No, it's certainly not appropriate for this optimization. The problem with
using builtin_unreachable is if you do reach that point, you fall into an
unrelat
On 11/12/13 05:41, Marc Glisse wrote:
On Tue, 12 Nov 2013, Ondřej Bílka wrote:
I am trying to get something to actually work and be accepted in
gcc. That may mean being conservative.
That also may mean that you will cover only cases where it is not needed.
A malloc will have a small per-thre
Got it!
thanks,
Cong
On Tue, Nov 12, 2013 at 10:05 AM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 10:04:15AM -0800, Cong Hou wrote:
>> Thank you for pointing it out. The updated patch is pasted below. I
>> will pay attention to it in the future.
>
> Ok, thanks.
> Note, you can use dg-addit
>>> Is there a format for compiler-defined labels that would not be able
>>> to clash with other user-generated labels?
>>
>> My understanding is that the "." in the generated name ensures that it
>> will not clash with user-generated labels which cannot contain ".". So
>> this should not be an iss
A question about the newly added global variable function_counter.
Does it have to be a global? Can I make it a file static, within macro
L_gcov_time_profiler? I don't find a use other than in
__gcov_time_profiler().
thanks,
-Rong
On Mon, Nov 11, 2013 at 9:52 AM, Martin Liška wrote:
> On 11 N
>> Isn't this something that should be expressed in DWARF with
>> DW_AT_ranges? See DWARF4, section 2.17,
>>
>> Does GCC generate such ranges?
>
> GCC does generate these ranges. However, according to Cary many tools
> do not rely on dwarf info for locating the corresponding function
> name, they j
The reason patch was in its original state is because we want
to notify user that his assumption of profitability may be wrong.
This is not a part of any spec and as far as I know ICC does not
notify user about the case. Still it can be a good hint for those
users who tries to get as much as possib
> One cannot simply also import, e.g., "i" as the code might have:
>
> subroutine example()
> use mod, only: my_nml
> integer :: i! < Locally defined variable
> read(uid, my_nml)
> ...
> end subroutine example
>
> In that case "i" is the local variable. As written, one can creat
On Mon, Nov 11, 2013 at 11:30 PM, Uros Bizjak wrote:
> There was something wrong with Bernd's address, retrying.
>
>>> Currently on trunk the option -mpreferred-stack-boundary does not work
>>> together with #pragma GCC target("sse") or __attribute__((target("sse"))).
>>>
>>> There is already a te
Thanks. I'll have this change included in my libgcov.c re-re-factoring patch.
-Rong
On Tue, Nov 12, 2013 at 10:18 AM, Martin Liška wrote:
> Hi Rong,
> you are right, that's the only usage and so that you can declare it
> static.
>
> Thank you,
> Martin
>
> On Nov 12, 2013 7:10 PM, "Rong Xu" w
On Tue, Nov 12, 2013 at 10:07:32AM -0800, Kostya Serebryany wrote:
> On Tue, Nov 12, 2013 at 10:04 AM, Michael Meissner
> wrote:
> > On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote:
> >> or, alternatively, we can disable libsanitizer on PowerPC if the
> >> PowerPC community does
On Tue, Nov 12, 2013 at 07:08:22PM +0100, Marc Glisse wrote:
> On Tue, 12 Nov 2013, Jeff Law wrote:
>
> >On 11/12/13 10:14, Marc Glisse wrote:
> >>You didn't like Jakub's comment about __builtin_unreachable?
> >No, it's certainly not appropriate for this optimization. The
> >problem with using bu
On Mon, Nov 11, 2013 at 4:45 PM, Michael Meissner
wrote:
> This patch fixes PR 59054, which is a bug I introduced in early October, when
> I
> added initial patches for allowing DFmode values in the traditional Altivec
> registers on ISA 2.06, and SFmode values on ISA 2.07. This patch eliminates
On 11/12/13 10:14, Marc Glisse wrote:
I assume the second LHS should be RHS. Don't you want to mark it somehow
so the next DCE doesn't remove it?
Sigh, yes DCE is removing the load.
That can be fixed by just marking the MEM_REF as volatile and updating
the statement. It's a pretty trivial ch
> On Tue, Nov 12, 2013 at 10:39:28AM -0500, Vladimir Makarov wrote:
> > >> Shall we also disable argument accumulation for cores? It seems we won't
> > >> solve the IRA issues, right?
> > > You mean LRA issues here, right? If you are starting to use
> > > no-accumulate-outgoing-args much more ofte
> If we revert the patch now, I will not be able to work on it again in
> nearest months, which means 4.9 will not get updated asan.
> How bad that is -- I don't know.
When you contribute patches, you should allocate enough time with your
employer to address any fall out. This problem likely affe
On Tue, Nov 12, 2013 at 10:07:32AM -0800, Kostya Serebryany wrote:
> On Tue, Nov 12, 2013 at 10:04 AM, Michael Meissner
> wrote:
> > On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote:
> >> or, alternatively, we can disable libsanitizer on PowerPC if the
> >> PowerPC community does
On Tue, Nov 12, 2013 at 10:57 AM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 10:07:32AM -0800, Kostya Serebryany wrote:
>> On Tue, Nov 12, 2013 at 10:04 AM, Michael Meissner
>> wrote:
>> > On Tue, Nov 12, 2013 at 09:43:38AM -0800, Kostya Serebryany wrote:
>> >> or, alternatively, we can disab
On Mon, Nov 11, 2013 at 9:17 AM, Teresa Johnson wrote:
> On Mon, Nov 11, 2013 at 9:13 AM, Jan Hubicka wrote:
>>> On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote:
>>> >> I have a warning like that already in drop_profile(). Is that
>>> >
>>> > I think it should be warning (or silent) for COMDA
On 11/11/13 21:41, Iyer, Balaji V wrote:
-Original Message-
From: David Edelsohn [mailto:dje@gmail.com]
Sent: Monday, November 11, 2013 11:36 AM
To: Iyer, Balaji V
Cc: GCC Patches; Joseph S. Myers
Subject: Re: PING Cilk Plus failures on non-LTO targets
On Mon, Nov 4, 2013 at 11:06
On 11/11/13 14:03, Andrew MacLeod wrote:
So on to the anomaly that causes the issue. force_gimple_operand* is
extensively used by the middle end, but not by the front end at all. The
front ends do not use the statement iterators, but 2 of the
force_gimple_operand() routines work with gsi's, and
Hello!
This was uncovered by x86 lto-profiledbootstrap. The patch allows
lto-profiledbootstrap to proceed further.
2013-11-12 Uros Bizjak
* cp-demangle.c (d_copy_templates): Cast result of malloc
to (struct d_print_template *).
(d_print_comp): Cast result of realloc to (struct d_s
On Tue, Nov 12, 2013 at 10:59:12AM -0800, Kostya Serebryany wrote:
> This is all dead code in gcc repo. This is why I am asking for any
> quick #ifdef.
> in clang repo this code is used by MemorySanitizer (and will be used
> by asan/tsan later).
I can't find how it is used in msan/ in the llvm rep
On Tue, Nov 12, 2013 at 11:30 AM, Jakub Jelinek wrote:
> On Tue, Nov 12, 2013 at 10:59:12AM -0800, Kostya Serebryany wrote:
>> This is all dead code in gcc repo. This is why I am asking for any
>> quick #ifdef.
>> in clang repo this code is used by MemorySanitizer (and will be used
>> by asan/tsan
On 11/12/2013 02:23 PM, Jeff Law wrote:
On 11/11/13 14:03, Andrew MacLeod wrote:
So on to the anomaly that causes the issue. force_gimple_operand* is
extensively used by the middle end, but not by the front end at all. The
front ends do not use the statement iterators, but 2 of the
force_gimple
On Tue, Nov 12, 2013 at 11:34:48AM -0800, Kostya Serebryany wrote:
> > Anyway, the following #ifdefs out tons of dead code and still builds just
>
> Thanks, that should work.
> I am really sorry I couldn't do it myself before -- just got back from travel.
So do you have some suggestion for #ifdef
On Tue, Nov 12, 2013 at 11:08 AM, Teresa Johnson wrote:
> On Mon, Nov 11, 2013 at 9:17 AM, Teresa Johnson wrote:
>> On Mon, Nov 11, 2013 at 9:13 AM, Jan Hubicka wrote:
On Mon, Nov 11, 2013 at 8:22 AM, Jan Hubicka wrote:
>> I have a warning like that already in drop_profile(). Is that
On Tue, Nov 12, 2013 at 11:34:48AM -0800, Kostya Serebryany wrote:
> On Tue, Nov 12, 2013 at 11:30 AM, Jakub Jelinek wrote:
> > On Tue, Nov 12, 2013 at 10:59:12AM -0800, Kostya Serebryany wrote:
> >> This is all dead code in gcc repo. This is why I am asking for any
> >> quick #ifdef.
> >> in clan
On Tue, Nov 12, 2013 at 11:24 AM, Uros Bizjak wrote:
>
> This was uncovered by x86 lto-profiledbootstrap. The patch allows
> lto-profiledbootstrap to proceed further.
>
> 2013-11-12 Uros Bizjak
>
> * cp-demangle.c (d_copy_templates): Cast result of malloc
> to (struct d_print_template *
Hey Ian,
My latest set of changes (which I just checked in as revision204717)
to restructuring the gimple include files breaks go. It requires a
minor change to the go front end in order for it to compile...
patch attached:
Andrew
2013-11-12 Andrew MacLeod
* go/gofrontend/expressi
Alignments are stored in a byte, large alignments don't actually work nicely.
This caps the alignment to 128, as most ports would define BIGGEST_ALIGNMENT to
be smaller than this. The competing change would to be to make it a short,
but, I'd be happy to punt that until such time as someone act
On Tue, Nov 12, 2013 at 01:11:04PM -0800, Mike Stump wrote:
> Alignments are stored in a byte, large alignments don't actually work nicely.
> This caps the alignment to 128, as most ports would define BIGGEST_ALIGNMENT
> to be smaller than this. The competing change would to be to make it a
>
1 - 100 of 152 matches
Mail list logo
