On Thu, Nov 07, 2013 at 07:17:19AM +, Nathan Sidwell wrote:
> On 11/06/13 21:25, Dodji Seketeli wrote:
> >It appeared that gcov.c and input.c both have a static function named
> >read_line. I guess we ought to keep just one.
>
> As a general rule, that's good.
Generally yes, but IMHO not in
On Wed, Nov 06, 2013 at 08:42:15PM +0100, tho...@codesourcery.com wrote:
> From: Thomas Schwinge
>
> libgomp/
> * libgomp_g.h: Include for size_t.
I'm surprised why it is needed, because libgomp.h that includes it includes
stdlib.h that should provide size_t too. But, including thi
On Wed, Nov 06, 2013 at 08:42:16PM +0100, tho...@codesourcery.com wrote:
> From: Thomas Schwinge
>
> libgomp/
> * testsuite/lib/libgomp.exp (libgomp_init): Don't add -fopenmp to
> ALWAYS_CFLAGS.
> * testsuite/libgomp.c++/c++.exp (ALWAYS_CFLAGS): Add -fopenmp.
> * tes
On Wed, Nov 06, 2013 at 08:42:17PM +0100, tho...@codesourcery.com wrote:
> From: Thomas Schwinge
>
> gcc/c-family/
> * c.opt (fopenacc): New option.
> gcc/fortran/
> * lang.opt (fopenacc): New option.
> * invoke.texi (-fopenacc): Document it.
> * gfortran.h (gf
On Wed, Nov 06, 2013 at 08:42:18PM +0100, tho...@codesourcery.com wrote:
> --- gcc/config/arc/arc.h
> +++ gcc/config/arc/arc.h
> @@ -174,7 +174,7 @@ along with GCC; see the file COPYING3. If not see
> %(linker) %l " LINK_PIE_SPEC "%X %{o*} %{A} %{d} %{e*} %{m} %{N} %{n}
> %{r}\
> %{s} %
On Wed, Nov 06, 2013 at 08:42:19PM +0100, tho...@codesourcery.com wrote:
> From: Thomas Schwinge
>
> gcc/c-family/
> * c-cppbuiltin.c (c_cpp_builtins): Conditionally define _OPENACC.
> gcc/fortran/
> * cpp.c (cpp_define_builtins): Conditionally define _OPENACC.
> gcc
On Wed, Nov 06, 2013 at 08:42:21PM +0100, tho...@codesourcery.com wrote:
> From: Thomas Schwinge
>
> gcc/
> * gimplify.c (gimplify_body): Consider flag_openacc additionally
> to flag_openmp.
> * omp-low.c (execute_expand_omp, execute_lower_omp)
> (gate_diagnose_omp_b
On Wed, Nov 06, 2013 at 08:42:20PM +0100, tho...@codesourcery.com wrote:
> From: Thomas Schwinge
>
> gcc/
> * oacc-builtins.def: New file.
> * Makefile.in (BUILTINS_DEF): Add oacc-builtins.def.
> * builtins.def (DEF_GOACC_BUILTIN): New macro.
> Include "oacc-builtins
On Wed, Nov 06, 2013 at 08:42:22PM +0100, tho...@codesourcery.com wrote:
> From: Thomas Schwinge
>
> gcc/c-family/
> * c-pragma.c (oacc_pragmas): New array.
> (c_pp_lookup_pragma, init_pragma): Handle it.
> gcc/
> * doc/invoke.texi (-fopenacc): Update.
>
> gcc
On Wed, Nov 06, 2013 at 08:53:00PM +0100, Thomas Schwinge wrote:
> Forgot to pass the --patience switch to Git, so the diff algorithm
> decided to first patch the existing expand_omp_taskreg into
> expand_oacc_parallel, and then later re-add expand_omp_taskreg. Here's a
> more readable version of
On Wed, Nov 06, 2013 at 05:37:03PM -0700, Aldy Hernandez wrote:
> Hmmm, good point. I've moved update_stmt and company to the caller,
> and modified the caller to call regimplify_operands only for
> GIMPLE_RETURN which is the special case.
Can't you (later) handle that without regimplification to
On Wed, 6 Nov 2013, Richard Sandiford wrote:
> Richard Biener writes:
> > --- 599,615
> >
> > exp = TREE_OPERAND (exp, 0);
> > }
> >
> > + /* We need to deal with variable arrays ending structures. */
> > + if (seen_variable_array_ref
> > + && maxsize != -1
> >
On Wed, 6 Nov 2013, Jakub Jelinek wrote:
> On Tue, Nov 05, 2013 at 02:00:16PM -0800, Cong Hou wrote:
> > > I'm also curious -- did this code show up in a particular benchmark, if
> > > so,
> > > which one?
> >
> > I didn't find this problem from any benchmark, but from another
> > concern about
I very strongly disagree with this. The standard needs to be high than "does
it pass the test suite."
What we are introducing is a case where the program will behave one way with
optimization and another way without it. While, this is always true for timing
dependent code, it is pretty rare f
On Thu, 7 Nov 2013, Kenneth Zadeck wrote:
> I very strongly disagree with this. The standard needs to be high than "does
> it pass the test suite."
>
> What we are introducing is a case where the program will behave one way
> with optimization and another way without it. While, this is always
On Thu, Nov 07, 2013 at 09:48:46AM +0100, Richard Biener wrote:
> > --- gcc/tree-vrp.c.jj 2013-11-06 08:48:01.0 +0100
> > +++ gcc/tree-vrp.c 2013-11-06 09:32:19.205104029 +0100
> > @@ -92,6 +92,42 @@ static sbitmap *live;
> > static bool
> > live_on_edge (edge e, tree name)
> > {
On Thu, 7 Nov 2013, Jakub Jelinek wrote:
> On Thu, Nov 07, 2013 at 09:48:46AM +0100, Richard Biener wrote:
> > > --- gcc/tree-vrp.c.jj 2013-11-06 08:48:01.0 +0100
> > > +++ gcc/tree-vrp.c2013-11-06 09:32:19.205104029 +0100
> > > @@ -92,6 +92,42 @@ static sbitmap *live;
> > > s
I was a bit too hasty in committing this patch, thinking the review was
done. I have reverted it yesterday night.
Let's try again after a night of sleep.
Bernd Edlinger writes:
> I still do not see how this is supposed to work:
>
> If the previous invocation of get_line already had read some
>
Hi,
I've tested LRA on ARM in several configuration and it occurs that
only one regression is observed in Fortran for targets A15 and A9 in
hard and soft fp amd Thumb mode enabled by default (ARMv5 is clean).
The failing test case is gfortran.dg/realloc_on_assign_11.f90 in -O3
and the error seems
- warning_at (DECL_SOURCE_LOCATION (p),
- OPT_Wunused_but_set_variable,
- "variable %qD set but not used", p);
+ {
+if (!TREE_THIS_VOLATILE (p))
+ warning_at (DECL_SOURCE_LOCATION (p),
+OPT_Wunused_but_set_variable,
+"variable %qD set but not used", p);
+ }
I'd prefe
This patch just changes a QImode (const_int 255) to (const_int -1),
since the canonical form is to sign-extend. As things stand the pattern
trips a new assert added on the wide-int branch.
Tested by building rl78-elf before and after the patch and making sure
that there were no changes in assembl
2013/11/6 Ilya Enkovich :
> 2013/11/5 Jeff Law :
>> On 11/04/13 06:27, Richard Biener wrote:
>>>
>>> On Thu, Oct 31, 2013 at 10:02 AM, Ilya Enkovich
>>> wrote:
Hi,
Here is a patch which hadles the problem with optimization of
BUILT_IN_CHKP_ARG_BND calls. Pointer Bounds Ch
On Wed, Nov 6, 2013 at 9:56 PM, Andrew MacLeod wrote:
> On 11/06/2013 06:31 AM, Richard Biener wrote:
>>
>> On Wed, Nov 6, 2013 at 12:02 PM, Bernd Schmidt
>> wrote:
>>>
>>>
>>> Maybe we need to revisit it? As one of those who were not in favour of
>>> the C++ move, can I ask you guys to step back
On Wed, Nov 6, 2013 at 11:42 PM, Uros Bizjak wrote:
> On Thu, Nov 7, 2013 at 7:19 AM, H.J. Lu wrote:
>
>> We should use Pmode with stack_pointer_rtx. OK for trunk and 4.8
>> branch?
>
> OK everywhere.
>
I checked it into trunk and 4.8 branch. For 4.7, I only checked
in the i386.md change since
On Wed, Nov 6, 2013 at 11:06 PM, Eric Botcazou wrote:
>> Attached patch fixes PR 59021, where new vzeroupper instructions are
>> generated for -mavx after Vlad's useless insn removal patch.
>>
>> The problem was, that we depent on (useless) moves to AVX256 function
>> argument registers in front o
On Wed, Nov 6, 2013 at 6:10 PM, Diego Novillo wrote:
> On Wed, Nov 6, 2013 at 2:04 AM, Marc Glisse wrote:
>> On Tue, 5 Nov 2013, Diego Novillo wrote:
>>
>>> This is the first patch in a series of patches to cleanup tree.h to
>>> reduce the exposure it has all over the compiler.
>>>
>>> In this pa
On Wed, Nov 6, 2013 at 11:31 PM, Richard Sandiford
wrote:
> Ping.
Ok.
Thanks,
Richard.
> Richard Sandiford writes:
>> As discussed on gcc@, integer_onep is supposed to return false for
>> a nonzero 1-bit value if the type is signed.
>>
>> Tested on x86_64-linux-gnu and powerpc64-linux-gnu. OK
On Tue, Nov 05, 2013 at 11:26:46AM -0500, Andrew MacLeod wrote:
>
> I decided to name the new file gimple-expr.[ch] instead of
> gimple-decl This will eventually split into gimple-type.[ch],
> gimple-decl.[ch], and gimple-expr.[ch].
Since we are adding *new* C++ files, can't we please na
On Wed, Nov 6, 2013 at 6:06 PM, Richard Sandiford
wrote:
> Hi,
>
> "bin.cheng" writes:
>> Index: gcc/tree-ssa-loop-ivopts.c
>> ===
>> --- gcc/tree-ssa-loop-ivopts.c(revision 203267)
>> +++ gcc/tree-ssa-loop-ivopts.c(w
On Thu, Nov 07, 2013 at 10:32:10AM +0100, Richard Biener wrote:
> I'm looking for adjusting of live compute - either by adjusting the
> algorithm or by special casing the latches. Like for example
> with the following (untested, needs cleanup - the PHI processing
> can be factored out from find_as
On Thu, 7 Nov 2013, Jakub Jelinek wrote:
> On Thu, Nov 07, 2013 at 10:32:10AM +0100, Richard Biener wrote:
> > I'm looking for adjusting of live compute - either by adjusting the
> > algorithm or by special casing the latches. Like for example
> > with the following (untested, needs cleanup - the
As noticed by Richard.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-11-07 Richard Biener
* tree-dfa.c (get_ref_base_and_extent): Fix casting.
Index: gcc/tree-dfa.c
===
--- gcc/tree-dfa.c
This fixes CCP and DOM to not spread TREE_OVERFLOW eventually set
from fold. I've chosen to change the lattice updating which is
easiest.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-11-07 Richard Biener
* tree-ssa-ccp.c (canonicalize_float_value): Re
Hi,
Here is a patch to remove language hook used by Pointer Bounds Checker. To
disable checker on non C languages option is moved to c.opt.
Thanks,
Ilya
--
gcc/
2013-11-06 Ilya Enkovich
* common.opt (fcheck-pointer-bounds): Move to ...
* c-family/c.opt: ... here.
*
Hi all,
I've committed this patch as obvious. It adds a comment in
aarch64_legitimize_reload_address explaining that we need the RTL structure to
be preserved before push_reload and using plus_constant would fold that, causing
ICEs.
Thanks,
Kyrill
[gcc/]
2013-11-07 Kyrylo Tkachov
*
Hi,
Here is an updated patch version.
Thanks,
Ilya
--
diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 52d9ab0..9d7ae85 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3030,40 +3030,54 @@ gimple_check_call_args (gimple stmt, tree fndecl, bool
args_count_match)
{
for (i = 0, p = DECL_A
On Thu, Nov 7, 2013 at 12:46 PM, Ilya Enkovich wrote:
> Hi,
>
> Here is a patch to remove language hook used by Pointer Bounds Checker. To
> disable checker on non C languages option is moved to c.opt.
Ok.
Thanks,
Richard.
> Thanks,
> Ilya
> --
> gcc/
>
> 2013-11-06 Ilya Enkovich
>
>
Hi,
just some thoughts...
fgetc will definitely be much faster than fread 16K and fseek back to the end
of line position.
Note: fgetc is already buffered and not too slow on average, but only if you do
not
fseek around. In that case the buffered file-stream data is lost.
Well, reading 16K in
Preapproved by Jakub in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59029
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index 4991a3a..535b670 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,10 @@
+2013-11-07 Yury Gribov
+ Jakub Jelinek
+
+ PR sanitizer/59029
+ * gcc/asan.c (get_me
On Thu, Nov 07, 2013 at 04:32:56PM +0400, Yury Gribov wrote:
> + PR sanitizer/59029
> + * gcc/asan.c (get_mem_refs_of_builtin_call): Allow
> + integer literals as addresses in instrumented builtins.
> +
The prefix gcc/ hasn't been dropped as it should.
Marek
Hello,
I've looked into RTL after register allocation. Insn which
lead to assert is:
(insn 77 180 79 4 (set (reg/v:TF 44 loc12 [orig:359 T8 ] [359])
(mem:TF (post_modify:DI (reg/f:DI 14 r14 [435])
(plus:DI (reg/f:DI 14 r14 [435])
(reg:DI 45 loc13 [orig:34
Yup, Jakub already pointed this out. Should I fix the changelog with
another commit?
---
From: Marek Polacek
Sent: Thursday, November 07, 2013 4:38PM
To: Yury Gribov
Cc: gcc-patches@gcc.gnu.org, Jakub Jelinek ,
reich...@gcc.gnu.org, Viacheslav Garb
On Thu, Nov 07, 2013 at 01:25:00PM +0100, Bernd Edlinger wrote:
> just some thoughts...
>
>
> fgetc will definitely be much faster than fread 16K and fseek back to the end
> of line position.
>
> Note: fgetc is already buffered and not too slow on average, but only if you
> do not
> fseek arou
On Thu, Nov 07, 2013 at 04:48:10PM +0400, Yury Gribov wrote:
> Yup, Jakub already pointed this out. Should I fix the changelog with
> another commit?
Yes, just fix up the ChangeLog and commit, for ChangeLog changes
of course you don't add a new ChangeLog entry.
Jakub
>> Should I fix the changelog with another commit?
> Yes, just fix up the ChangeLog and commit
Fixed.
-Y
Hi,
On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote:
>
> On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger
> wrote:
>> Hi,
>>
>>> Eh ... even
>>>
>>> register struct { int i; int a[0]; } asm ("ebx");
>>>
>>> works. Also with int a[1] but not with a[2]. So just handling trailing
>>> arrays makes
oops - this time with attachments...
> Hi,
>
> On Fri, 25 Oct 2013 12:51:13, Richard Biener wrote:
>>
>> On Fri, Oct 25, 2013 at 12:02 PM, Bernd Edlinger
>> wrote:
>>> Hi,
>>>
Eh ... even
register struct { int i; int a[0]; } asm ("ebx");
works. Also with int a[1] but not
Hi,
at -O0 we ICE for this valid testcase in output_constant because
NULLPTR_TYPE is not handled. Should I dig further because we never want
nullptr to reach varasm? Because otherwise the patchlet works fine, I
checked that expand_expr can cope perfectly well with NULLPTR_TYPE as
TREE_TYPE of
On 11/07/2013 05:36 AM, Basile Starynkevitch wrote:
On Tue, Nov 05, 2013 at 11:26:46AM -0500, Andrew MacLeod wrote:
I decided to name the new file gimple-expr.[ch] instead of
gimple-decl This will eventually split into gimple-type.[ch],
gimple-decl.[ch], and gimple-expr.[ch].
Since we ar
On Thu, 7 Nov 2013, Mingjie Xing wrote:
> 2013/11/6 Richard Biener :
> > You miss a testcase.
> >
> > Also why should the warning be omitted for unused automatic
> > volatile variables? They cannot be used in any way.
> >
> > Richard.
>
> Thanks. I've updated the patch with a test case.
You do
On Thu, 7 Nov 2013, Richard Biener wrote:
> Well, I'm betting that you'll re-invent sth like 'tree' just don't
> call it 'tree' ;)
> You need to transparently refer to constants, SSA names and decls
> (at least) as GIMPLE statement operands. You probably will make
> a "gimple statement operand" b
On Thu, 7 Nov 2013, Ilya Enkovich wrote:
> Here is a new split. I still include rtl.h into tree-chkp.c for MEM_P
> usage. Is it OK?
I have no further comments on this patch.
--
Joseph S. Myers
jos...@codesourcery.com
Hi!
On Thu, 7 Nov 2013 09:15:45 +0100, Jakub Jelinek wrote:
> On Wed, Nov 06, 2013 at 08:42:18PM +0100, tho...@codesourcery.com wrote:
> > --- gcc/config/arc/arc.h
> > +++ gcc/config/arc/arc.h
> > @@ -174,7 +174,7 @@ along with GCC; see the file COPYING3. If not see
> > %(linker) %l " LINK_
I checked in this patch to remove redundant setting of
misaligned_prologue_used.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 204511)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-11-07 H.J. Lu
+
+ * config/
OK.
On 11/07/2013 01:58 AM, tsaund...@mozilla.com wrote:
> From: Trevor Saunders
>
> Hi,
>
> I admit its another c++ification, but the functions are useless, and if I'm
> changing the name of the called function its just easier to drop the class
> name
> bit all together.
>
> Trev
>
>[...]
> diff --g
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg. PARALLEL element value of 2 is the same in
+
On Wed, Nov 06, 2013 at 03:21:04PM -0700, Jeff Law wrote:
> >2013-11-06 Jakub Jelinek
> >
> > * tree-ssa-loop-niter.c: Include tree-ssanames.h.
> > (determine_value_range): Add loop argument. Use get_range_info to
> > improve range.
> > (bound_difference): Adjust caller.
> Cleve
On Thu, Nov 7, 2013 at 2:44 PM, Joseph S. Myers wrote:
> On Thu, 7 Nov 2013, Richard Biener wrote:
>
>> Well, I'm betting that you'll re-invent sth like 'tree' just don't
>> call it 'tree' ;)
>> You need to transparently refer to constants, SSA names and decls
>> (at least) as GIMPLE statement ope
On Thu, 7 Nov 2013 13:48:14, Jakub Jelinek wrote:
> On Thu, Nov 07, 2013 at 01:25:00PM +0100, Bernd Edlinger wrote:
>> just some thoughts...
>>
>>
>> fgetc will definitely be much faster than fread 16K and fseek back to the
>> end of line position.
>>
>> Note: fgetc is already buffered and not too
On Thu, Nov 07, 2013 at 02:58:31PM +0100, Thomas Schwinge wrote:
> On Thu, 7 Nov 2013 09:15:45 +0100, Jakub Jelinek wrote:
> > On Wed, Nov 06, 2013 at 08:42:18PM +0100, tho...@codesourcery.com wrote:
> > > --- gcc/config/arc/arc.h
> > > +++ gcc/config/arc/arc.h
> > > @@ -174,7 +174,7 @@ along with
On 11/07/2013 05:08 AM, Richard Biener wrote:
2 - I really believe gimple needs a type system different from front end
trees, that is my primary motivation. I'm tired of jumping through hoops to
do anything slightly different, and I got fed up with it. With a separate
type system for gimple,
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> Richard Sandiford wrote:
Tejas Belagod writes:
> Richard Sandiford wrote:
>> Tejas Belagod writes:
>>> + /* This is big-endian-safe because the elements are kept in target
>>> + memory order. So
Hi,
On Wed, 6 Nov 2013, David Malcolm wrote:
> > I don't like that. The empty classes are just useless, they imply a
> > structure that isn't really there, some of the separate gimple codes
> > are basically selectors of specific subtypes of a generic concept,
> > without additional data or m
On Wed, Nov 6, 2013 at 11:55 PM, Vladimir Simonov
wrote:
>> -Original Message-
>> From: Ian Lance Taylor [mailto:i...@google.com]
>> Sent: Wednesday, November 06, 2013 6:42 PM
>> To: Joey Ye
>> Cc: gcc-patches; d...@redhat.com; Vladimir Simonov
>> Subject: Re: [PATCH] [libiberty] MAX_PATH
Hi,
this patch fixed an LRA cycling due to secondary reload (Thumb mode).
Notice that this patch is a prerequisite to turn on LRA by default on
ARM. Bootstrapped on a9 and a15 without any regression in the
testsuite as LRA is off by default and with the regression reported in
the thread bellow wh
Here, forward propagation turned
_6 = a.1_5 & 1;
_7 = (_Bool) _6;
into
_7 = (_Bool) a.1_5;
but that's wrong: e.g. if a = 2 then (_Bool) _6 is 0, but (_Bool) a.1_5 is 1.
If a is an odd number, this is correct, but we don't know the value
of a, so I disabled this optimization for "x & 1" cases.
On 11/07/13 00:38, Jakub Jelinek wrote:
On Wed, Nov 06, 2013 at 05:37:03PM -0700, Aldy Hernandez wrote:
Hmmm, good point. I've moved update_stmt and company to the caller,
and modified the caller to call regimplify_operands only for
GIMPLE_RETURN which is the special case.
Can't you (later) h
On 11/6/13, 5:06 PM, Joseph S. Myers wrote:
> You should be testing aarch64*-*-* so as to match aarch64_be targets.
Thank you for catching that. Please commit this new patch if is OK. I
don't have SVN access.
Thanks,
Cesar
2013-11-06 Cesar Philippidis
gcc/testsuite/
* lib/ta
On Thu, Nov 07, 2013 at 08:17:13AM -0700, Aldy Hernandez wrote:
> But as discussed on IRC, I wonder whether we can do without the
> following in the attached patch:
>
> + tree repl = make_ssa_name (TREE_TYPE (retval), NULL);
> + stmt = gimple_build_assign (repl, ret
On Thu, Nov 07, 2013 at 04:15:11PM +0100, Marek Polacek wrote:
> Here, forward propagation turned
> _6 = a.1_5 & 1;
> _7 = (_Bool) _6;
> into
> _7 = (_Bool) a.1_5;
> but that's wrong: e.g. if a = 2 then (_Bool) _6 is 0, but (_Bool) a.1_5 is 1.
> If a is an odd number, this is correct, but we
On Thu, Nov 7, 2013 at 4:15 PM, Marek Polacek wrote:
> Here, forward propagation turned
> _6 = a.1_5 & 1;
> _7 = (_Bool) _6;
> into
> _7 = (_Bool) a.1_5;
> but that's wrong: e.g. if a = 2 then (_Bool) _6 is 0, but (_Bool) a.1_5 is 1.
?
(_Bool) 2
should truncate the value to zero.
Richard
On Thu, Nov 07, 2013 at 04:39:03PM +0100, Richard Biener wrote:
> On Thu, Nov 7, 2013 at 4:15 PM, Marek Polacek wrote:
> > Here, forward propagation turned
> > _6 = a.1_5 & 1;
> > _7 = (_Bool) _6;
> > into
> > _7 = (_Bool) a.1_5;
> > but that's wrong: e.g. if a = 2 then (_Bool) _6 is 0, but
From: Trevor Saunders
Hi,
This is the result of seeing what it would take to get rid of the has_gate and
has_execute flags on pass_data. It turns out not much, but I wanted
confirmation this part is ok before I go deal with all the places that
initialize the fields.
I bootstrapped this part o
Hi,
On Thu, Oct 31, 2013 at 10:04:45PM -0500, Aldy Hernandez wrote:
> Hello gentlemen. I'm CCing all of you, because each of you can
> provide valuable feedback to various parts of the compiler which I
> touch. I have sprinkled love notes with your names throughout the
> post :).
sorry it took
On Thu, Nov 07, 2013 at 04:39:03PM +0100, Richard Biener wrote:
> On Thu, Nov 7, 2013 at 4:15 PM, Marek Polacek wrote:
> > Here, forward propagation turned
> > _6 = a.1_5 & 1;
> > _7 = (_Bool) _6;
> > into
> > _7 = (_Bool) a.1_5;
> > but that's wrong: e.g. if a = 2 then (_Bool) _6 is 0, but
On Wed, Nov 6, 2013 at 12:21 AM, Joseph S. Myers
wrote:
> This patch, relative to trunk and based on work done on the C11-atomic
> branch, adds support for C11 _Atomic. It is intended to include all
> the required language support.
>
> It does not include the header; there's a version on the
> b
This patch cleans up various issues with the tests of atomics built-in
functions and libatomic functions, in preparation for adapting those
tests to add test coverage of stdatomic.h macros. The tests were
missing a return type for main (C11 doesn't allow implicit int return
types). Some tests wer
On Tue, Nov 05, 2013 at 11:21:56PM +, Joseph S. Myers wrote:
> 2013-11-05 Andrew MacLeod
> Joseph Myers
>
> * tree-core.h (enum cv_qualifier): Add TYPE_QUAL_ATOMIC.
> (enum tree_index): Add TI_ATOMICQI_TYPE, TI_ATOMICHI_TYPE,
> TI_ATOMICSI_TYPE, TI_ATOMICDI_TYP
On 11/07/13 06:11, Thomas Schwinge wrote:
Hi!
On Wed, 9 Oct 2013 18:32:11 +, "Iyer, Balaji V"
wrote:
* Makefile.def: Add libcilkrts to target_modules. Make libcilkrts
depend on libstdc++ and libgcc.
[...]
* Makefile.in: Added libcilkrts related fields
On 11/07/13 10:24, Diego Novillo wrote:
On Thu, Nov 7, 2013 at 5:29 AM, Richard Biener
wrote:
Moved to fold-const.c:
size_low_cst
Same as int_cst_value just with lack of any checking?
It may be. It's used by the POINTER_EXPR_PLUS handler. I will try to
replace it in a later patch.
tmp
Description: Binary data
On Thu, 7 Nov 2013, Rong Xu wrote:
> Thanks Joseph for these detailed comments/suggestions.
> The fixed patch is attached to this email.
> The only thing left out is the Texinfo manual. Do you mean this tool
> should have its it's own texi file in gcc/doc?
Its own texi file, probably included as
On 11/07/13 09:00, tsaund...@mozilla.com wrote:
From: Trevor Saunders
Hi,
This is the result of seeing what it would take to get rid of the has_gate and
has_execute flags on pass_data. It turns out not much, but I wanted
confirmation this part is ok before I go deal with all the places that
Get the new port building on wide-int. Seemed pretty obvious so I went
ahead and installed it.
Thanks,
Richard
Index: gcc/config/nds32/nds32.c
===
--- gcc/config/nds32/nds32.c2013-11-05 13:06:54.744239262 +
+++ gcc/config/n
On 11/06/13 15:29, Ian Lance Taylor wrote:
When fenv.h is not fixed, libquadmath does not build.
This patch works around the problem. Bootstrapped and tested on
x86_64-unknown-linux-gnu.
OK for mainline?
Hi Ian,
Yes, please.
This time, I'm on my dev box and looked at the code.
You remember
I wanted to make sure that each backend still builds with wide-int and that
there weren't any unexplained changes in assembly output. I arbitrarily
picked one target for each CPU:
aarch64-linux-gnueabi alpha-linux-gnu arc-elf arm-linux-gnueabi
avr-rtems bfin-elf c6x-elf cr16-elf cris-elf
So is this the right patch?
$ svn diff inclhack.def
Index: inclhack.def
===
--- inclhack.def(revision 204533)
+++ inclhack.def(working copy)
@@ -1738,7 +1738,7 @@
versions. */
fix = {
hackname = glibc_str
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
+ /* This is big-endian-safe because the elements are kept in target
+ memory order. So, for eg.
Hi,
On Wed, Nov 06, 2013 at 05:37:03PM -0700, Aldy Hernandez wrote:
> On 11/06/13 15:48, Jakub Jelinek wrote:
> >On Wed, Nov 06, 2013 at 03:24:40PM -0700, Aldy Hernandez wrote:
> >>I have checked the following patch with the attached testcases that
> >>were previously ICEing, and with a handful of
I doubt that this list is comprehensive.
When i many of these things a long time ago, I was not that interested
in bit for bit compatibly as long as was never introducing any
problems.in some cases it would have been hard to replicate some of
the end cases with the wide-int code.
On 11/0
On Thu, Nov 7, 2013 at 5:45 PM, Jakub Jelinek wrote:
> On Tue, Nov 05, 2013 at 11:21:56PM +, Joseph S. Myers wrote:
>> 2013-11-05 Andrew MacLeod
>> Joseph Myers
>>
>> * tree-core.h (enum cv_qualifier): Add TYPE_QUAL_ATOMIC.
>> (enum tree_index): Add TI_ATOMICQI_TYPE,
On Thu, Nov 7, 2013 at 8:23 AM, Andrew MacLeod wrote:
> On 11/07/2013 05:36 AM, Basile Starynkevitch wrote:
>>
>> On Tue, Nov 05, 2013 at 11:26:46AM -0500, Andrew MacLeod wrote:
>>>
>>> I decided to name the new file gimple-expr.[ch] instead of
>>> gimple-decl This will eventually split into
Kenneth Zadeck writes:
> I very strongly disagree with this. The standard needs to be high than
> "does it pass the test suite."
>
> What we are introducing is a case where the program will behave one way
> with optimization and another way without it. While, this is always
> true for timing dep
Hi, Thomas!
This is really great!
I've looked at your changes and in most of front-end parts it looks reasonable
to me. As you know, we're like-minded with you about how OpenACC's front-ends
should look like. So, I think it's good that you have working flow for your
implementation. Now we can s
On Nov 7, 2013, at 8:43 AM, Joseph S. Myers wrote:
> This patch cleans up various issues with the tests of atomics built-in
> functions and libatomic functions, in preparation for adapting those
> tests to add test coverage of stdatomic.h macros. The tests were
> missing a return type for main (C
On Nov 7, 2013, at 9:47 AM, Richard Sandiford
wrote:
> Get the new port building on wide-int. Seemed pretty obvious so I went
> ahead and installed it.
Looks good.
Kenneth Zadeck writes:
> I doubt that this list is comprehensive.
Hmm? It was supposed to be one target for each CPU, so if you think
I've missed one, please point it out. It certainly wasn't supposed
to be every target triple that gcc supports.
Even one target per CPU was useful, since quite
> On 11/07/13 09:32, Dodji Seketeli wrote:
>
>> From the above, what I can say is that input.o was already linked with
>> gcov. But I think it's minimal enough to only drag libcpp and the
>> diagnostic subsystem.
>
> I disagree. While input.o was available to gcov, I don't think it was being
> pull
On Thu, Nov 07, 2013 at 10:30:16AM -0700, Jeff Law wrote:
> On 11/07/13 09:00, tsaund...@mozilla.com wrote:
> >From: Trevor Saunders
> >
> >Hi,
> >
> > This is the result of seeing what it would take to get rid of the has_gate
> > and
> >has_execute flags on pass_data. It turns out not much, bu
1 - 100 of 138 matches
Mail list logo
