OFFSET_TYPE is treated as an integral type for the purpose of conversion
in fold-const.c. However, the GIMPLE verifier disagrees, leading to
verification errors when a cast from boolean to offset type is gimplified.
Bootstrapped/regtested x86_64-pc-linux-gnu, ok for mainline?
Paolo
2012-05-16
Hi all,
First hunk is not needed indeed. Testing is ok. Thanks!!!
Here is the final patch:
diff --git a/gcc/configure.ac b/gcc/configure.ac
index 2c17736..43e760b 100644
--- a/gcc/configure.ac
+++ b/gcc/configure.ac
@@ -4566,6 +4566,11 @@ AC_CACHE_CHECK(__stack_chk_fail in target C library,
> Fixed thusly, tested on i586-suse-linux, applied as obvious on mainline,
> 4.6 and 4.5 branches.
>
>
> 2011-12-18 Eric Botcazou
>
> * configure: Regenerate.
> config/
> * acx.m4 (Test for GNAT): Update comment and add quotes in final test.
It turns out that gcc/configure needs to
David Miller writes:
> Ok for mainline and 4.7 branch?
OK for both, thanks.
> * jump.c (delete_related_insns): If we remove a CALL, make sure
> we delete it's NOTE_INSN_CALL_ARG_LOCATION note too.
On May 16, 2012, at 03:10 , David Edelsohn wrote:
> Okay.
revision 187581. Thanks!
On May 16, 2012, at 08:29 , Paolo Bonzini wrote:
> Ok.
Applied, Thanks Paolo :)
Opinion on http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00274.html ?
Thanks in advance,
Olivier
On Tue, May 15, 2012 at 7:19 PM, Lawrence Crowl wrote:
> The gcc source uses several constructs that GDB does not understand.
> This patch corrects some of them. It affects only compilers built
> with ENABLE_TREE_CHECKING, and hence release compilers are unaffected.
>
> In particular, I change th
On Wed, May 16, 2012 at 9:19 AM, Paolo Bonzini wrote:
> OFFSET_TYPE is treated as an integral type for the purpose of conversion
> in fold-const.c. However, the GIMPLE verifier disagrees, leading to
> verification errors when a cast from boolean to offset type is gimplified.
>
> Bootstrapped/regt
On Tue, 15 May 2012, William J. Schmidt wrote:
> Ping.
I don't like it too much - but pondering a bit over it I can't find
a nicer solution.
So, ok.
Thanks,
Richard.
> Thanks,
> Bill
>
> On Tue, 2012-05-08 at 22:04 -0500, William J. Schmidt wrote:
> > This fixes another statement-placement is
> *** /tmp/dL6Ouq_Makefile.tpl 2012-04-05 14:37:34.144103910 +0200
> --- Makefile.tpl 2012-04-04 22:03:53.822060326 +0200
> *** install.all: install-no-fixedincludes
> *** 906,916
> true ; \
> fi
>
> ! # install-no-fixedincludes is used because Cygnus
Dear Janne,
On 05/16/2012 08:45 AM, Janne Blomqvist wrote:
IMHO it would be cleaner if you instead somewhere in the beginning of unix.c did
#ifdef __VXWORKS__
/* open is not a variadic function on vxworks (or something...) */
#define open(path, flags) open(path, flags, 0666)
#endif
Untested, b
>
> extern const struct tune_params *current_tune;
> extern int vfp3_const_double_for_fract_bits (rtx);
> +
> +extern void arm_emit_coreregs_64bit_shift (enum rtx_code, rtx, rtx, rtx, rtx,
> +rtx);
> #endif /* RTX_CODE */
> #endif /* ! GCC_ARM_PROTOS_H *
On May 16, 2012, at 11:47 , Paolo Bonzini wrote:
>> install-no-fixedincludes: installdirs install-host-nogcc \
>> !install-target gcc-install-no-fixedincludes
...
> This is missing in the ChangeLog.
Indeed.
>> + install-no-fixedincludes: \
>> +stash-maybefixed-headers \
>> +stmp-in
Hi,
On 05/16/2012 06:02 AM, Jason Merrill wrote:
On 05/15/2012 07:56 PM, Paolo Carlini wrote:
But, speaking of incremental work: what if, post the build_min_nt_loc
chunk, we handle build_min_non_dep and build_min in a case by case way?
Thus we keep around the non-_loc variant and gradually repl
On Wed, May 16, 2012 at 1:03 PM, Tobias Burnus wrote:
> Dear Janne,
>
>
> On 05/16/2012 08:45 AM, Janne Blomqvist wrote:
>>
>> IMHO it would be cleaner if you instead somewhere in the beginning of
>> unix.c did
>>
>> #ifdef __VXWORKS__
>> /* open is not a variadic function on vxworks (or something
On 05/16/2012 12:54 PM, Paolo Carlini wrote:
I think I was wrong when I indicated that, and that EXPR_LOCATION is
better there, too. EXPR_LOC_OR_HERE is good for error messages, but
not for setting the location of a tree. Though it occurs to me that
we're likely to use the passed in location
On Wed, 2012-05-16 at 11:45 +0200, Richard Guenther wrote:
> On Tue, 15 May 2012, William J. Schmidt wrote:
>
> > Ping.
>
> I don't like it too much - but pondering a bit over it I can't find
> a nicer solution.
>
> So, ok.
>
> Thanks,
> Richard.
>
Agreed. I'm not fond of it either, and I fee
On Wed, 16 May 2012, William J. Schmidt wrote:
> On Wed, 2012-05-16 at 11:45 +0200, Richard Guenther wrote:
> > On Tue, 15 May 2012, William J. Schmidt wrote:
> >
> > > Ping.
> >
> > I don't like it too much - but pondering a bit over it I can't find
> > a nicer solution.
> >
> > So, ok.
> >
>
On 05/16/2012 07:26 AM, Janne Blomqvist wrote:
On Wed, May 16, 2012 at 1:03 PM, Tobias Burnus wrote:
On 05/16/2012 08:45 AM, Janne Blomqvist wrote:
IMHO it would be cleaner if you instead somewhere in the beginning of
unix.c did
#ifdef __VXWORKS__
/* open is not a variadic function on vxwork
Hi,
I am checking in this patch to regenerate configure files with the
updated libtoo.m4. libjava/libltdl and libgo aren't updated since they
have their own version of libtoo.m4. They should be updated separately.
H.J.
boehm-gc/
2012-05-16 H.J. Lu
* configure: Regenerated.
g
On Wed, 2012-05-16 at 14:05 +0200, Richard Guenther wrote:
> On Wed, 16 May 2012, William J. Schmidt wrote:
>
> > On Wed, 2012-05-16 at 11:45 +0200, Richard Guenther wrote:
> > > On Tue, 15 May 2012, William J. Schmidt wrote:
> > >
> > > > Ping.
> > >
> > > I don't like it too much - but ponderi
On 05/16/2012 01:25 PM, Paolo Carlini wrote:
Thus at this point in our location work I don't believe we can do much
(in terms of simple obvious changes) for UNKNOWN_LOCATIONs coming from
upstream, besides maybe using the LOC_OR_HERE trick for the immediate
error messages (but maybe isn't really
Hello,
since you touch the SPE area would you mind looking at this PR:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47856
--
Sebastian Huber, embedded brains GmbH
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
Phone : +49 89 18 90 80 79-6
Fax : +49 89 18 90 80 79-9
E-Mail : seba
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason for templating these functions? They all take trees as
parameter!?
True. I don't recall what Lawrence had in mind, but I remember that by
using templates here, you don't need to deal with the mess of
distinguishing tree from con
Hello All,
I am pinging the patch http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
below for trunk svn 187587
# patch
Index: gcc/toplev.c
===
--- gcc/toplev.c(
Committed to fix some fallout from testsuite.
http://gcc.gnu.org/viewcvs?view=revision&revision=187588
PR testsuite/52641
* gcc.dg/pr52549.c: Fix test for long != void*
* gcc.c-torture/execute/pr52979-1.x: New file.
* gcc.c-torture/execute/pr52979-2.x: New file.
On Mon, 7 May 2012, Aldy Hernandez wrote:
> Hi. Sorry for the delay. There were various tricky hiccups along the way to
> bootstrappability and regression cleanliness...
>
> On 04/26/12 04:51, Richard Guenther wrote:
> > On Wed, 25 Apr 2012, Aldy Hernandez wrote:
> >
> > > On 04/25/12 06:45, Ri
Hello Paolo,
This is a followup on the exchange we just had about
this patch, as part of another thread:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01093.html
Attached is a second version, adjusted to account for the
suggestions you made.
Looks good ?
Thanks for your feedback,
With Kind R
On Wed, May 16, 2012 at 2:43 PM, Diego Novillo wrote:
> On 12-05-16 05:41 , Richard Guenther wrote:
>
>> What's the reason for templating these functions? They all take trees as
>> parameter!?
>
>
> True. I don't recall what Lawrence had in mind, but I remember that by
> using templates here, yo
On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
wrote:
> Hello All,
>
> I am pinging the patch http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
> below for trunk svn 187587
> # patch
> Index: gcc/toplev.c
> ==
This fixes PR53364 - an oversight in the alias oracle when detecting
view-conversions on decls.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to
trunk and branch (possibly latent on the 4.6 branch).
Richard.
2012-05-16 Richard Guenther
PR tree-optimization/53364
On 12-05-16 09:00 , Richard Guenther wrote:
On Wed, May 16, 2012 at 2:43 PM, Diego Novillo wrote:
On 12-05-16 05:41 , Richard Guenther wrote:
What's the reason for templating these functions? They all take trees as
parameter!?
True. I don't recall what Lawrence had in mind, but I remembe
Il 16/05/2012 14:54, Olivier Hainque ha scritto:
> +
> + install-no-fixedincludes:
> + # Stash the current set of headers away, save stamps we're going to alter
> + # explicitly, and arrange for fixincludes not to run next time we trigger
> + # a headers rebuild.
> +
> + -rm -rf tmp-include
>
On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
> On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
> wrote:
> > Hello All,
> >
> > I am pinging the patch
> > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg00474.html
> > below for trunk svn 187587
--- gcc/toplev.c(rev
I noticed a write-only bitmap and some odd CFG hooks initializing code.
Removed as follows.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-05-16 Richard Guenther
* tree-vect-loop-manip.c (slpeel_update_phi_nodes_for_guard1):
Remove set-only bitm
On Wed, May 16, 2012 at 3:16 PM, Diego Novillo wrote:
> On 12-05-16 09:00 , Richard Guenther wrote:
>>
>> On Wed, May 16, 2012 at 2:43 PM, Diego Novillo
>> wrote:
>>>
>>> On 12-05-16 05:41 , Richard Guenther wrote:
>>>
What's the reason for templating these functions? They all take trees
>>
On Wed, May 16, 2012 at 3:18 PM, Basile Starynkevitch
wrote:
> On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
>> On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
>> wrote:
>> > Hello All,
>> >
>> > I am pinging the patch
>> > http://gcc.gnu.org/ml/gcc-patches/2012-02/msg0
Committed.
Richard.
2012-05-16 Richard Guenther
* tree-flow.h (get_virtual_var): Remove.
* tree-dfa.c (get_virtual_var): Likewise.
Index: gcc/tree-flow.h
===
--- gcc/tree-flow.h (revision 187591)
+++ gcc/tre
This tackles the remaining caller of mark_symbols_for_renaming, the
inliner. Incrementally as it's a mess ;)
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2012-05-16 Richard Guenther
* tree-inline.c (insert_init_stmt): Do not call
mark_symb
On Wed, May 16, 2012 at 03:29:12PM +0200, Richard Guenther wrote:
> On Wed, May 16, 2012 at 3:18 PM, Basile Starynkevitch
> wrote:
> > On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
> >> On Wed, May 16, 2012 at 2:46 PM, Basile Starynkevitch
> >> wrote:
> >> > Hello All,
> >> >
On Wed, May 16, 2012 at 3:38 PM, Basile Starynkevitch
wrote:
> On Wed, May 16, 2012 at 03:29:12PM +0200, Richard Guenther wrote:
>> On Wed, May 16, 2012 at 3:18 PM, Basile Starynkevitch
>> wrote:
>> > On Wed, May 16, 2012 at 03:02:39PM +0200, Richard Guenther wrote:
>> >> On Wed, May 16, 2012 at
On 12-05-16 09:27 , Richard Guenther wrote:
There's less typing if you use the template variant. Not sure why
you say there is less type safety with templates.
Because it accepts any type as tree argument?
Yes and no. It accepts any type that responds to tree
operations and has the same fi
On Wed, May 16, 2012 at 3:40 PM, Diego Novillo wrote:
> On 12-05-16 09:27 , Richard Guenther wrote:
>
>>> There's less typing if you use the template variant. Not sure why
>>> you say there is less type safety with templates.
>>
>>
>> Because it accepts any type as tree argument?
>
>
> Yes and no
On 11.05.2012 16:48, Ramana Radhakrishnan wrote:
I would change the iterator from VQX to VQ in the pattern above (you
can also simplify the setting of neon_type in that case as well as
change that to be a vec_duplicate as below and get rid of any
lingering definitions of UNSPEC_VLD1_DUP if they e
On 16 May 2012 15:40, Richard Guenther wrote:
>>
>> Without that patch displaying happen too late (and eats a lot of Emacs CPU)!!
>
> 1) Fix emacs (do not buffer stderr)
> 2) do not omit -quiet when running from inside emacs
Actually, I wonder how you (Richard) and other GCC hackers work with
and
On Wed, May 16, 2012 at 3:56 PM, Manuel López-Ibáñez
wrote:
> On 16 May 2012 15:40, Richard Guenther wrote:
>>>
>>> Without that patch displaying happen too late (and eats a lot of Emacs
>>> CPU)!!
>>
>> 1) Fix emacs (do not buffer stderr)
>> 2) do not omit -quiet when running from inside emacs
Hi,
Would anyone please have a look at:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00044.html
I know this is trivial boring stuff, but perhaps especially because of
this let's get rid of it ASAP? Thanks.
Maciej
This is it. Yay. Apart from return variable handling the inliner
is clean (even that we could clean up, but we're currently re-writing
virtual SSA form from the scratch anyway, so the benefit would be
minor). This patch saves us one update_stmt call per statement
(and update_stmt is not cheap!)
As of today, all Go link tests were failing like this:
Undefined first referenced
symbol in file
log_syslog.syslog_c
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/.
FAIL: go.go-torture/execute/array-1.go compilation,
On May 16, 2012, at 15:17 , Paolo Bonzini wrote:
> Please indent the comments with a tab and remove the empty lines.
Sure.
> Ok with that change.
Installed, thanks :)
If I may, we actually hit another install-no-fixedincludes issue
in more recent versions of gcc, after
http://gcc.gnu.or
On 05/16/2012 08:06 AM, rbmj wrote:
On 05/16/2012 07:26 AM, Janne Blomqvist wrote:
On Wed, May 16, 2012 at 1:03 PM, Tobias Burnus wrote:
On 05/16/2012 08:45 AM, Janne Blomqvist wrote:
IMHO it would be cleaner if you instead somewhere in the beginning of
unix.c did
#ifdef __VXWORKS__
/* open
Rainer Orth writes:
> As of today, all Go link tests were failing like this:
>
> Undefined first referenced
> symbol in file
> log_syslog.syslog_c
> /var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/.
> FAIL: go.go-torture/e
Il 16/05/2012 16:46, Olivier Hainque ha scritto:
>
> On May 16, 2012, at 15:17 , Paolo Bonzini wrote:
>> Please indent the comments with a tab and remove the empty lines.
>
> Sure.
>
>> Ok with that change.
>
> Installed, thanks :)
>
> If I may, we actually hit another install-no-fixedinclu
On Fri, 16 Mar 2012, Edmar wrote:
> I am pinging this post:
>
> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00430.html
I don't see any sign of anything further having happened with this patch
... you should ping approximately weekly until a patch is reviewed, and
probably also CC relevant mai
Hi,
currently build of Mozilla with -flto-partition=none fails at:
/tmp/ccQ0smdA.ltrans3.ltrans.o:ccQ0smdA.ltrans3.o:function
scriptableInvokeDefault(NPObject*, _NPVariant const*, unsigned int,
_NPVariant*) [clone .part.84.4761]: error: undefi
ned reference to 'construction vtable for
std::ostre
Joseph,
Thanks for the tip.
It is likely I need to re-generate the patch (and re-test)
as there had been a lot of activity in the trunk since the original post.
I will do this soon.
Regards,
Edmar
On 05/16/2012 11:10 AM, Joseph S. Myers wrote:
On Fri, 16 Mar 2012, Edmar wrote:
I am pingin
On May 16, 2012, at 17:03 , Paolo Bonzini wrote:
> Ok, thanks!
Great :-)
> All these are regressions, right?
Right.
> Please commit them to 4.7 branch too.
Will do. Thanks for your prompt and constructive feedback,
With Kind Regards,
Olivier
On 05/15/2012 02:16 PM, Patrick Marlier wrote:
Tested on i686.
Is the patch ok? Thanks.
BTW, Should we generate a warning or an error?
--
2012-05-15 Patrick Marlier
* trans-mem.c (diagnose_tm_1_op): Warn about assignment of transaction
unsafe function to safe function pointe
Il 16/05/2012 15:27, Richard Guenther ha scritto:
>> >
>> > Two bootstrapped compilers built exactly the same, except one was using the
>> > template version, the other using the straight inline functions with
>> > const_tree parameters and CONST_CAST_TREE in return values.
> That's of course not e
On 16 May 2012 16:02, Richard Guenther wrote:
> On Wed, May 16, 2012 at 3:56 PM, Manuel López-Ibáñez
> wrote:
>> On 16 May 2012 15:40, Richard Guenther wrote:
Without that patch displaying happen too late (and eats a lot of Emacs
CPU)!!
>>>
>>> 1) Fix emacs (do not buffer stderr)
On 05/16/2012 06:54 AM, Paolo Carlini wrote:
isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
default should be interpreted as input_location, no?
That would make sense to me; I don't know if it works that way now, though.
@@ -11968,7 +11968,8 @@ tsubst_qualified_id (tree
On 16/05/12 11:25, Ramana Radhakrishnan wrote:
Ok with those changes.
Hi Ramana,
Here's an update rebased and modified as requested.
Can you please confirm that the comments explain what you wanted to
know, and then I will commit it.
Thanks
Andrew
2012-05-16 Andrew Stubbs
gcc/
* con
On 05/15/2012 02:33 PM, Patrick Marlier wrote:
2012-05-15 Dave Boutcher
Patrick Marlier
* trans-mem.c (ipa_tm_transform_clone): Transform functions with
indirect calls.
2012-05-15 Patrick Marlier
* gcc.dg/tm/indirect-2.c: New test.
Ok for trunk an
On 16 May 2012 17:09, Andrew Stubbs wrote:
> On 16/05/12 11:25, Ramana Radhakrishnan wrote:
>>
>> Ok with those changes.
>
>
> Hi Ramana,
>
> Here's an update rebased and modified as requested.
>
> Can you please confirm that the comments explain what you wanted to know,
> and then I will commit i
On 16 May 2012 17:41, Jason Merrill wrote:
> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
>>
>> isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
>> default should be interpreted as input_location, no?
>
>
> That would make sense to me; I don't know if it works that way now, th
On Wed, May 16, 2012 at 11:56 AM, Manuel López-Ibáñez
wrote:
> On 16 May 2012 17:41, Jason Merrill wrote:
>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
>>>
>>> isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
>>> default should be interpreted as input_location, no?
>>
>>
>>
Hi
> On 16 May 2012 17:41, Jason Merrill wrote:
>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
>>>
>>> isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
>>> default should be interpreted as input_location, no?
>>
>>
>> That would make sense to me; I don't know if it works
Some cleanups in preparation for more EnabledBy goodness.
Bootstrapped and regression tested.
OK?
2012-05-16 Manuel López-Ibáñez
c-family/
* c.opt (--pedantic-errors,-pedantic-errors): Do not handle here.
* c-opts.c (c_common_handle_option): Do not handle explicitly
W
Hi!
Ping.
On Wed, 09 May 2012 10:01:55 +0800, I wrote:
> On Fri, 27 Apr 2012 10:29:06 +0200, Jakub Jelinek wrote:
> > On Fri, Apr 27, 2012 at 12:42:41PM +0800, Thomas Schwinge wrote:
> > > > > GET_MODE_BITSIZE (lmode)« (8 bits). (With the current sources, lmode
> > > > > is
> > > > > VOIDmode.
On 16 May 2012 19:06, Gabriel Dos Reis wrote:
> On Wed, May 16, 2012 at 11:56 AM, Manuel López-Ibáñez
> wrote:
>> On 16 May 2012 17:41, Jason Merrill wrote:
>>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
defau
Hi Jing, thanks!
The SUBTARGET_EXTRA_SPECS is defined in config/i386/gnu-user.h
In "linux.h", the original value of "SUBTARGET_EXTRA_SPECS" is
overwritten by LINUX_GRTE_EXTRA_SPECS, which is not right! Instead,
"SUBTARGET_EXTRA_SPECS" and "LINUX_GRTE_EXTRA_SPECS" must be
concatenated.
For every t
On 2012/05/16 01:02:26, shenhan wrote:
Hi Amhad and Jing, could you take a look at this CL at
http://codereview.appspot.com/6210060/
Thanks,
-Han
Shouldn't this have a corresponding ChangeLog entry and a
ChangeLog.google-gcc-4_6 entry?
http://codereview.appspot.com/6210060/
It turns out that there is a second target that doesn't define
ASM_OUTPUT_ADDR_DIFF_ELT: pdp11. I'll fix that.
The documentation is out of date as a consequence of this patch, because it
still says that ASM_OUTPUT_ADDR_DIFF_ELT is optional which is no longer the
case (or not unless you take so
Hi again,
> In any case, the general rule should be that input_location (or
> variants using that) should be only used in the parser (who actually
> knows what input_location is pointing at). Other functions should use
> a location coming from somewhere else (an argument or a tree).
> UNKNOWN_LOCA
On 16 May 2012 19:09, Paolo Carlini wrote:
> Hi
>
>> On 16 May 2012 17:41, Jason Merrill wrote:
>>> On 05/16/2012 06:54 AM, Paolo Carlini wrote:
isn't the diagnostic machinery able to cope with UNKNOWN_LOCATION? By
default should be interpreted as input_location, no?
>>>
>>>
>>> Th
On 2012/5/10 04:53 AM, Manuel López-Ibáñez wrote:
> 2012-05-09 Manuel López-Ibáñez
>
> PR 53063
> gcc/
> * doc/options.texi (EnabledBy): Document
> * opts.c: Include opts.h and options.h before tm.h.
> (finish_options): Do not handle some sub-options here...
> (com
Hi,
>
> I cannot answer because I don't know what are the defaults. What does
> build_min_nt use by default?
UNKNOWN_LOCATION. I think this answers most of your concerns.
> -expr = build_new_op (loc, code, LOOKUP_NORMAL, arg1, arg2, NULL_TREE,
> +expr = build_new_op (LOC_OR_HERE (loc), c
On 16 May 2012 19:47, Chung-Lin Tang wrote:
> On 2012/5/10 04:53 AM, Manuel López-Ibáñez wrote:
>> 2012-05-09 Manuel López-Ibáñez
>>
>> PR 53063
>> gcc/
>> * doc/options.texi (EnabledBy): Document
>> * opts.c: Include opts.h and options.h before tm.h.
>> (finish_options)
On 16 May 2012 19:53, Paolo Carlini wrote:
>> - expr = build_new_op (loc, code, LOOKUP_NORMAL, arg1, arg2, NULL_TREE,
>> + expr = build_new_op (LOC_OR_HERE (loc), code, LOOKUP_NORMAL,
>> + arg1, arg2, NULL_TREE,
>> overload, complain);
>>
>> This doesn't seem correct
> "Lawrence" == Lawrence Crowl writes:
Lawrence> The effect is that it now possible to get useful responses to gdb
Lawrence> command like
Lawrence> (gdb) print DECL_FUNCTION_CODE (decl)
Doesn't this mean that if you have checking enabled, and you use the
wrong macro on some tree, cc1 wil
On 05/16/2012 01:15 PM, Manuel López-Ibáñez wrote:
My proposal is to assert when checking is enabled (gcc_checking_assert
instead of gcc_assert) and degrade gracefully when not (use
input_location if given an UNKNOWN_LOCATION).
That makes sense if we want to require the front end to move to exp
Hi,
> On 16 May 2012 19:53, Paolo Carlini wrote:
>>> -expr = build_new_op (loc, code, LOOKUP_NORMAL, arg1, arg2, NULL_TREE,
>>> +expr = build_new_op (LOC_OR_HERE (loc), code, LOOKUP_NORMAL,
>>> + arg1, arg2, NULL_TREE,
>>> overload, complain);
>>>
>>> This doesn't
> "Manuel" == Manuel López-Ibáñez writes:
Manuel> Actually, I wonder how you (Richard) and other GCC hackers work with
Manuel> and debug GCC, because it is a real pain in the ass.
Manuel> * All the TREE_ macros don't work.
Manuel> * __extension__ prevents GDB from evaluating many things.
S
> "Manuel" == Manuel López-Ibáñez writes:
Manuel> It seems it will never work for statement expressions:
Manuel> http://article.gmane.org/gmane.comp.gcc.devel/107339
It could be done, but it is non-trivial for sure.
Manuel> I see how these small functions can quickly become annoying. Is it
On Wed, 16 May 2012, Manuel L?pez-Ib??ez wrote:
> Some cleanups in preparation for more EnabledBy goodness.
>
> Bootstrapped and regression tested.
>
> OK?
>
> 2012-05-16 Manuel L?pez-Ib??ez
>
> c-family/
> * c.opt (--pedantic-errors,-pedantic-errors): Do not handle here.
>
On Thu, 17 May 2012, Chung-Lin Tang wrote:
> 2012-05-17 Chung-Lin Tang
>
> * Makefile.in (options.c): Add options.h to included header
> files, before tm.h.
OK.
--
Joseph S. Myers
jos...@codesourcery.com
When COND_EXPR was changed from GIMPLE_SINGLE_RHS to
GIMPLE_TERNARY_RHS, get_maxval_strlen was not updated for that
changed. With a patch which has a late PHIOPT produce COND_EXPR, I
saw a couple of regressions (pr23484-chk.c and strncpy-chk.c).
This patch fixes get_maxval_strlen for that change
Ping.
Thanks,
Bill
On Thu, 2012-05-03 at 09:33 -0500, William J. Schmidt wrote:
> This patch was posted for comment back in February during stage 4. It
> addresses a performance issue noted in the EEMBC routelookup benchmark
> on a common idiom:
>
> if (...)
> x = y->left;
> else
>
Hi,
This is just like my previous patch to expand COND_EXPR using
conditional moves but this time using addcc instead.
I had to fix a bug in emit_conditional_add where it was swapping op2
and op3 which can never happen. Also the documentation for both
emit_conditional_add and add@var{mode}cc was
This patch adds new flags and defines such that the C++ decl pretty printer
prints both canonical dwarf names for decls without perturbing normal error
message output.
It addresses the issues with the earlier patches submitted as:
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00516.html
http://gcc
On Wed, May 16, 2012 at 12:34:18PM -0700, Andrew Pinski wrote:
> When COND_EXPR was changed from GIMPLE_SINGLE_RHS to
> GIMPLE_TERNARY_RHS, get_maxval_strlen was not updated for that
> changed. With a patch which has a late PHIOPT produce COND_EXPR, I
> saw a couple of regressions (pr23484-chk.c a
On 5/16/12, Richard Guenther wrote:
> On May 16, 2012 Diego Novillo wrote:
> > On 12-05-16 09:00 , Richard Guenther wrote:
> > > On May 16, 2012 Diego Novillo wrote:
> > > > On 12-05-16 05:41 , Richard Guenther wrote:
> > > > > What's the reason for templating these functions?
> > > > > They all
Hi
When moving stuff into libgcc, a line for m32r-rtems
got lost. This is PR53314.
Is this OK for the head and 4.7?
2012-05-16 Joel Sherrill
* config.host (m32r-*-rtems*): Include crtinit.o and crtfinit.o
as extra_parts.
diff --git a/libgcc/config.host b/libgcc/config.host
index 14
On 5/16/12, Tom Tromey wrote:
>> "Lawrence" == Lawrence Crowl writes:
>
> Lawrence> The effect is that it now possible to get useful responses
> Lawrence> to gdb command like
> Lawrence> (gdb) print DECL_FUNCTION_CODE (decl)
>
> Doesn't this mean that if you have checking enabled, and you
> Right, and that's why we want your change to split the nested function
> into abstract and concrete instances. But then it should be fine to
> attach the abstract instance to the abstract parent normally, I would
> think.
Indeed, this works, but I need to use function_possibly_abstracted_p inst
On May 16, 2012, at 1:27 PM,
wrote:
> It turns out that there is a second target that doesn't define
> ASM_OUTPUT_ADDR_DIFF_ELT: pdp11. I'll fix that.
>
> The documentation is out of date as a consequence of this patch, because it
> still says that ASM_OUTPUT_ADDR_DIFF_ELT is optional whic
On 2012/05/16 17:27:59, asharif1 wrote:
On 2012/05/16 01:02:26, shenhan wrote:
> Hi Amhad and Jing, could you take a look at this CL at
> http://codereview.appspot.com/6210060/
>
> Thanks,
> -Han
Shouldn't this have a corresponding ChangeLog entry and a
ChangeLog.google-gcc-4_6 entry?
Hi Ahm
I meant to CC the RTL optimization maintainers before ...
On 05/15/2012 02:39 PM, Meador Inge wrote:
> Hi All,
>
> As reported in PR rtl-optimization/53352 CSE currently trips up on a
> paradoxical subreg case. When compiling for ARM GNU/Linux with -O3
> the expanded RTL of interest looks like:
On 2012/05/16 22:11:08, shenhan wrote:
On 2012/05/16 17:27:59, asharif1 wrote:
> On 2012/05/16 01:02:26, shenhan wrote:
> > Hi Amhad and Jing, could you take a look at this CL at
> > http://codereview.appspot.com/6210060/
> >
> > Thanks,
> > -Han
>
> Shouldn't this have a corresponding ChangeLog
On Thu, May 17, 2012, Meador Inge wrote:
>> ;; This is *not* equal to zero because the upper
>> ;; two bytes are undefined.
>> (insn 14 13 15 2 (set (reg:SI 142)
>> (subreg:SI (reg:QI 141) 0))
>> (expr_list:REG_EQUAL (const_int 0 [0])
>> (nil)))
Hmm, this is what doc/rtl.texi
1 - 100 of 111 matches
Mail list logo
