I've merged GCC mainline revision 204559 to the gccgo branch.
Ian
This patch to the Go frontend fixes the type returned when a type
conversion has to make a function call. I have a test case that I will
commit to the master testsuite after the Go 1.2 release (the test case
is simply "return []byte(s)[0]"). Bootstrapped and ran Go testsuite on
x86_64-unknown-lin
Hi,
lp1243022.c will fail with options: -mfpu=neon -mfloat-abi=hard.
Logs show it does not generate auto-incremental instruction in pass
auto_inc_dec. In this case, the check of REG_INC note at subreg2 will
be invalid. So skip the check for target arm-neon.
All PASS with the following options:
Now is this patch OK for the trunk? Thank you!
thanks,
Cong
On Tue, Nov 5, 2013 at 9:58 AM, Cong Hou wrote:
> Thank you for your detailed explanation.
>
> Once GCC detects a reduction operation, it will automatically
> accumulate all elements in the vector after the loop. In the loop the
> re
Ping. OK for the trunk?
thanks,
Cong
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-effective-target vect_int } to make
> sure all loops ca
Ping
> -Original Message-
> From: Joey Ye [mailto:joey...@arm.com]
> Sent: Friday, November 01, 2013 1:00
> To: gcc-patches@gcc.gnu.org
> Subject: [patch] [arm] ARM Cortex-M3/M4 tuning
>
> Based on Julian's http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01006.html
> and
>
> * Merged with l
2013/11/7 Joseph S. Myers :
> 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 upda
On 7 November 2013 20:01, Uros Bizjak wrote:
> OTOH, looking a bit deeper, it looks that there is a problem in
> mode-switching infrastructure. If we have a BB without any mode
> requirements, but an insn that switched the mode via MODE_AFTER, we
> should not mark the block as transparent. Indeed
On Thu, Nov 7, 2013 at 2:25 PM, Uros Bizjak wrote:
>
> Recent Go mega-patch broke Alpha bootstrap. Following fixlet is needed:
>
> --cut here--
> Index: runtime/proc.c
> ===
> --- runtime/proc.c (revision 204522)
> +++ runtime/pr
Hello
On 06/11/13 15:32, Michael Matz wrote:
Hi,
On Tue, 5 Nov 2013, David Malcolm wrote:
Here's a followup patch which ensures that every gimple code has its own
subclass, by adding empty subclasses derived from the GSS_-based
subclasses as appropriate (I don't bother for gimple codes that a
Hello!
Recent Go mega-patch broke Alpha bootstrap. Following fixlet is needed:
--cut here--
Index: runtime/proc.c
===
--- runtime/proc.c (revision 204522)
+++ runtime/proc.c (working copy)
@@ -2098,7 +2098,7 @@
On Thu, 7 Nov 2013, Uros Bizjak wrote:
> However, this insn also raised FE_INEXACT flag (also on x86_64),
> probably not what you wanted. Your code that generates FE_UNDERFLOW
> will also raise FE_INEXACT. (and FE_DENORMAL).
If the compound assignment raised overflow or underflow, it will also ha
On Thu, Nov 7, 2013 at 9:55 PM, Uros Bizjak wrote:
>>> > I see code of the form (testing compilation rather than execution):
>>> >
>>> > flds4(%esp)
>>> > flds8(%esp)
>>> > fmulp %st, %st(1)
>>> > fstps 12(%esp)
>>> >
>>> > where the fstps should result
OK. It will be a couple of days.
On Thu, Nov 7, 2013 at 1:01 PM, Ian Lance Taylor wrote:
> In the meantime I've committed my version of the patch to the gccgo
> branch. It will be updated to whatever the final mainline version is
> the next time I merge from mainline to the gccgo branch.
>
> Ia
2013/11/7 Jeff Law :
> On 11/04/13 05:40, Richard Biener wrote:
>>>
>>>
>>> Effectively the bounds are passed "on the side".
>>
>>
>> Well, not exactly. I can see __bound_tmp.0_4 passed to access_and_store.
>
> I'm referring to how they're dealt with in FUNCTION_ARG and friends, ie, the
> low leve
Hi
Here is a patch to simplify a little safe iterator implementation.
Returning a sequence pointer from a safe iterator and a const sequence
pointer from a const safe iterator allows to avoid inconsistent usages
of iterator like comparing iterator with a const_iterator. This way
__get_dis
In the meantime I've committed my version of the patch to the gccgo
branch. It will be updated to whatever the final mainline version is
the next time I merge from mainline to the gccgo branch.
Ian
On Thu, Nov 7, 2013 at 10:16 AM, Ian Lance Taylor wrote:
> On Thu, Nov 7, 2013 at 8:48 AM, Bruce
On Thu, Nov 7, 2013 at 9:33 PM, Joseph S. Myers wrote:
>> > I see code of the form (testing compilation rather than execution):
>> >
>> > flds4(%esp)
>> > flds8(%esp)
>> > fmulp %st, %st(1)
>> > fstps 12(%esp)
>> >
>> > where the fstps should result in
Hi!
Here is a WIP. As the cloning doesn't yet produce multiple arguments
for one arg (say for SSE2 variant and simdlen(8) int should be passed
in two V4SImode arguments, while currently it is passed in one vector(8) int
BLKmode one) nor returned in multiple vectors (any thoughts how to represent
On Thu, 7 Nov 2013, Uros Bizjak wrote:
> > I see code of the form (testing compilation rather than execution):
> >
> > flds4(%esp)
> > flds8(%esp)
> > fmulp %st, %st(1)
> > fstps 12(%esp)
> >
> > where the fstps should result in the exception, and glibc
On Thu, Nov 7, 2013 at 3:14 PM, Aldy Hernandez wrote:
> SSA_NAME_DEF_STMT is set by default in gimple_build_assign(), by virtue of
> gimple_assign_set_lhs:
>
>> static inline void
>> gimple_assign_set_lhs (gimple gs, tree lhs)
>> {
>> GIMPLE_CHECK (gs, GIMPLE_ASSIGN);
>> gimple_set_op (gs, 0,
SSA_NAME_DEF_STMT is set by default in gimple_build_assign(), by virtue
of gimple_assign_set_lhs:
static inline void
gimple_assign_set_lhs (gimple gs, tree lhs)
{
GIMPLE_CHECK (gs, GIMPLE_ASSIGN);
gimple_set_op (gs, 0, lhs);
if (lhs && TREE_CODE (lhs) == SSA_NAME)
SSA_NAME_DEF_STMT (
.. nope, p2 isn't Ok, because we would return a different tree
depending on complain and . c_inhibit_evaluation_warnings. Thus either
something closer to p or something else.
Paolo.
2013/11/7 Jeff Law :
> On 10/31/13 03:15, Ilya Enkovich wrote:
>>
>> Hi,
>>
>> Here is a patch which adds support for bound constant to be used as
>> DECL_INITIAL for constant static bounds generated by compiler.
>>
>> Thanks,
>> Ilya
>> --
>>
>> gcc/
>>
>> 2013-10-23 Ilya Enkovich
>>
>>
... well, something like this seems better to me. Only lightly tested so
far, sorry.
Paolo.
///
Index: cvt.c
===
--- cvt.c (revision 204536)
+++ cvt.c (working copy)
@@ -621,24 +621,25 @@ cp_convert_
Hello!
Attached patch adds missing FP_EX_DENORM handling to x86 soft-fp
exception generator and improves support code a bit. The FP_EX_DENORM
handling will be needed by gfortran IEEE support.
2013-11-07 Uros Bizjak
* config/i386/sfp-exceptions.c (__sfp_handle_exceptions): Handle
FP_EX
On Nov 7, 2013, at 9:51 AM, Richard Sandiford
wrote:
> pdp11 and picochip-elf don't build on mainline due to:
>
> gcc/target-def.h:69:34: error: ‘default_stabs_asm_out_destructor’ was not
> declared in this scope
> # define TARGET_ASM_DESTRUCTOR default_stabs_asm_out_destructor
Fixed:
2
Just something I noticed while reviewing patches.
Installed onto the trunk as obvious.
Jeff
* varpool.c (ctor_for_folding): Fix typo in comment.
diff --git a/gcc/varpool.c b/gcc/varpool.c
index 4f1658e..1e4c823 100644
--- a/gcc/varpool.c
+++ b/gcc/varpool.c
@@ -304,7 +304,7 @@ ctor_for
Before r193504, if a method can not be overridden, LOOKUP_NONVIRTUAL
is set and the call is direct. The changes at r193504 (to fix PR
c++/11750) caused a regression to this behavior. This patch attempts
to fix that. Bootstraps and no test regressions on x86_64/linux. Is
this a correct fix and is t
Hi all, Jason,
in mainline, this commit:
http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=199232
appear to have caused a diagnostic regression for the following (from
c++/43906):
extern void z();
void f() { if ( z ) z(); }
that is, with -Waddress we warn twice, because in cp_conver
On 11/07/13 04:50, Ilya Enkovich wrote:
Hi,
Here is an updated patch version.
I think this needs to hold until we have a consensus on what the
parameter passing looks like for bounded pointers.
Jeff
On 10/31/13 03:15, Ilya Enkovich wrote:
Hi,
Here is a patch which adds support for bound constant to be used as
DECL_INITIAL for constant static bounds generated by compiler.
Thanks,
Ilya
--
gcc/
2013-10-23 Ilya Enkovich
* emit-rtl.c (immed_double_const): Support MODE_POINTER_BOU
Hi!
Thanks for the quick review of the patch series! Committed earlier
today, with the revisions as discussed.
On Wed, 6 Nov 2013 20:55:01 +0100, Jakub Jelinek wrote:
> On Wed, Nov 06, 2013 at 08:42:23PM +0100, tho...@codesourcery.com wrote:
> > +#define OACC_PARALLEL_CLAUSE_MASK
On Thu, 7 Nov 2013, Uros Bizjak wrote:
> [uros@localhost test]$ gcc -lm -g fpex.c
> [uros@localhost test]$ ./a.out
> Floating point exception (core dumped)
> [uros@localhost test]$ gcc -lm -g -m32 fpex.c
> [uros@localhost test]$ ./a.out
> [uros@localhost test]$
I see code of the form (testing com
On 11/04/13 05:40, Richard Biener wrote:
Effectively the bounds are passed "on the side".
Well, not exactly. I can see __bound_tmp.0_4 passed to access_and_store.
I'm referring to how they're dealt with in FUNCTION_ARG and friends, ie,
the low level aspects. Maybe that's why we're crossing
On Thu, Nov 7, 2013 at 7:26 PM, Joseph S. Myers wrote:
> On Thu, 7 Nov 2013, Uros Bizjak wrote:
>
>> Please note that following code form fenv.c won't generate overflow
>> exception on x87:
>>
>> if (excepts & FP_EX_OVERFLOW)
>> {
>> volatile float max = __FLT_MAX__;
>> r = max *
On Thu, 7 Nov 2013, Uros Bizjak wrote:
> Please note that following code form fenv.c won't generate overflow
> exception on x87:
>
> if (excepts & FP_EX_OVERFLOW)
> {
> volatile float max = __FLT_MAX__;
> r = max * max;
> }
r being volatile is intended to ensure that the re
On Thu, Nov 7, 2013 at 8:48 AM, Bruce Korb wrote:
>
> This time, I'm on my dev box and looked at the code.
> You remembered correctly that the first file name in the list
> of file names needs to not have wild card characters so that
> the testing scheme can create a file by that name. A director
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
> 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
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 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.
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
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
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
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
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,
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
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
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.
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
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
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
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/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
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
tmp
Description: Binary data
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.
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 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
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 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
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
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
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
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 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: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 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 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 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
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.
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
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,
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
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
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,
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 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 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 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
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 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
OK.
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/
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_
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
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, 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 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
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
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,
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
>> Should I fix the changelog with another commit?
> Yes, just fix up the ChangeLog and commit
Fixed.
-Y
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
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
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
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
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
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
1 - 100 of 138 matches
Mail list logo
