On Tue, Aug 6, 2013 at 9:29 AM, Teresa Johnson wrote:
> On Tue, Aug 6, 2013 at 9:01 AM, Martin Jambor wrote:
>> Hi,
>>
>> On Tue, Aug 06, 2013 at 07:14:42AM -0700, Teresa Johnson wrote:
>>> On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor wrote:
>>> > On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teres
Oleg Endo wrote:
> Speaking of GEN_FCN usage in rs6000.c. The recently added HTM builtin
> code has one interesting piece:
>
> static rtx
> htm_expand_builtin (tree exp, rtx target, bool * expandedp)
> {
> ...
> switch (nopnds)
> {
> case 0:
>pat = GEN_FCN (icode) (NULL_RTX);
>break;
>
On Tue, 2013-08-06 at 19:53 -0400, DJ Delorie wrote:
> Go for it. The static "212" is not required as long as the pass shows
> up in the right spot in the pass sequence.
Thanks. I checked, and both with and without the hardcoded 212, the
dumpfile for the pass for a foo.c is currently:
foo.c.246
Thanks; I've committed it to trunk as r201552.
On Tue, 2013-08-06 at 14:53 -0700, Mike Stump wrote:
> Ok.
>
> On Aug 6, 2013, at 3:43 AM, Dominique Dhumieres wrote:
> >> Hence plugins that create passes will need to be built with RTTI
> >> disabled in order to link against gcc, or they will fail
On Tue, 2013-08-06 at 12:49 -1000, Richard Henderson wrote:
> On 08/06/2013 11:23 AM, David Malcolm wrote:
> > gcc/
> > * coretypes.h (rtl_opt_pass): Add.
> > (gcc::context): Add.
> > * config/epiphany/epiphany.c (pass_mode_switch_use): New.
> > (
Simple oversight.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit e468033b49ddb6cadfd3c07d3ac0b81d80bc523a
Author: Jason Merrill
Date: Tue Aug 6 19:49:40 2013 -0400
PR c++/57825
* tree.c (strip_typedefs) [METHOD_TYPE]: Preserve ref-qualifier.
diff --git a/gcc/cp/tree.
On Tue, 30 Jul 2013, Richard Earnshaw wrote:
> Most arm target configs now require a 64-bit HW-int. Unfortunately a few of
> the older, less commonly used config targets do not. The code in arm.c now
> pretty much requires that a 64-bit HW-int is used, especially for
> vectorization to work.
>
Go for it. The static "212" is not required as long as the pass shows
up in the right spot in the pass sequence.
Peter,
Would you please help answer Oleg questions about case 0 in
htm_expand_builtin in rs6000.c?
Thanks, David
Speaking of GEN_FCN usage in rs6000.c. The recently added HTM builtin
code has one interesting piece:
static rtx
htm_expand_builtin (tree exp, rtx target, bool * expandedp)
{
...
sw
On 08/06/2013 11:20 AM, Oleg Endo wrote:
> PR other/12081
> config/rs6000/rs6000.c (gen_2arg_fn_t): Remove typedef.
> (rs6000_emit_swdiv, rs6000_emit_swrsqrt): Don't cast result of
> GEN_FCN to gen_2arg_fn_t.
Ok.
r~
On 08/06/2013 06:14 PM, Paolo Carlini wrote:
Ah I see, thanks. We reject this before and after the patch. Shall I add
this variant to the new testcase?
Sure.
Jason
On 08/06/2013 10:42 AM, Marek Polacek wrote:
Hm, actually, we can't easily fold the call to the sanitize function
away, I'm afraid, if we want to do it for the 'case '
case. When we hit the DIV_EXPR in 'case 0 * (1 / 0)',
the ubsan_instrument_division gets 1 as a first argument and 0 as
a second
On 08/06/2013 11:23 AM, David Malcolm wrote:
> gcc/
> * coretypes.h (rtl_opt_pass): Add.
> (gcc::context): Add.
> * config/epiphany/epiphany.c (pass_mode_switch_use): New.
> (epiphany_init): Port to new C++ pass API.
> (epiphany_optimize_mode_switching): Likewise.
Hi,
On 08/06/2013 11:19 PM, Jason Merrill wrote:
I mean something like
class Foo
{
int u, v, w;//, x;
typedef struct Bar { } Bar;
int Bar;
virtual void foo(void) {
struct Bar bar;
}
};
Ah I see, thanks. We reject this before and after the patch. Shall I add
this variant to the ne
On 08/06/2013 05:26 AM, Paolo Carlini wrote:
That's strange. I would expect that to mean that we don't properly
give an error for a Bar data member declared after the typedef.
You mean something like this?
class Foo
{
int u, v, w;//, x;
typedef struct Bar { } Bar;
Bar bar;
virtua
Ok.
On Aug 6, 2013, at 3:43 AM, Dominique Dhumieres wrote:
>> Hence plugins that create passes will need to be built with RTTI
>> disabled in order to link against gcc, or they will fail to load, with
>> an error like: ...
>
> The same holds for darwin, hence the following patch is needed:
>
>
On Tue, Aug 6, 2013 at 2:50 PM, Caroline Tice wrote:
> I have made all the requested changes. I am in the process of
> bootstrapping and running the regressions one last time. Assuming the
> bootstrapping & regression tests pass, is this ok to commit?
Sure.
Diego.
I have made all the requested changes. I am in the process of
bootstrapping and running the regressions one last time. Assuming the
bootstrapping & regression tests pass, is this ok to commit?
-- Caroline
cmt...@google.com
On Tue, Aug 6, 2013 at 2:45 PM, Diego Novillo wrote:
> On Tue, Aug 6,
On Mon, 2013-08-05 at 13:25 -1000, Richard Henderson wrote:
> On 08/05/2013 12:32 PM, Oleg Endo wrote:
> > Thanks, committed as rev 201513.
> > 4.8 also has the same problem. The patch applies on 4.8 branch without
> > problems and make all-gcc works.
> > OK for 4.8, too?
>
> Hum. I suppose so,
On Tue, Aug 6, 2013 at 2:39 PM, Benjamin De Kosnik wrote:
>
>> > +# Filter out unsupported systems.
>> > +case "${target}" in
>> > + x86_64-*-linux* | i?86-*-linux*)
>> > + VTV_SUPPORTED=yes
>> > + ;;
>> > + powerpc*-*-linux*)
>> > + ;;
>> > + sparc*-*-linux*)
>> > + ;;
>> > + arm*-*-linux*)
>
> > +# Filter out unsupported systems.
> > +case "${target}" in
> > + x86_64-*-linux* | i?86-*-linux*)
> > + VTV_SUPPORTED=yes
> > + ;;
> > + powerpc*-*-linux*)
> > + ;;
> > + sparc*-*-linux*)
> > + ;;
> > + arm*-*-linux*)
> > + ;;
>
> What about powerpc, sparc and arm? Why are they mentio
PR 58079 is about the do_SUBST assert:
/* Sanity check that we're replacing oldval with a CONST_INT
that is a valid sign-extension for the original mode. */
gcc_assert (INTVAL (newval)
== trunc_int_for_mode (INTVAL (newval), GET_MODE (oldval)));
triggering
On 08/05/2013 07:24 AM, Marek Polacek wrote:
On Sat, Aug 03, 2013 at 12:24:32PM -0400, Jason Merrill wrote:
Where are the SAVE_EXPRs coming from? It doesn't seem to me that x
needs to be wrapped in a SAVE_EXPR at all in this case. For cases
where the SAVE_EXPR is needed and not used in the tes
On Tue, 2013-08-06 at 10:34 -1000, Richard Henderson wrote:
> On 08/06/2013 06:06 AM, David Malcolm wrote:
> > Index: gcc/config/epiphany/epiphany.h
> > ===
> > --- gcc/config/epiphany/epiphany.h (revision 201526)
> > +++ gcc/config/e
On Tue, 2013-08-06 at 13:27 +0200, Jan-Benedict Glaw wrote:
> Hi!
>
> On Mon, 2013-08-05 22:09:45 -, olege...@gcc.gnu.org
> wrote:
> > Author: olegendo
> > Date: Mon Aug 5 22:09:45 2013
> > New Revision: 201513
> >
> > URL: http://gcc.gnu.org/viewcvs?rev=201513&root=gcc&view=rev
> > Log:
>
On 08/06/2013 04:33 AM, Yuri Rumyantsev wrote:
> -(define_expand "floatunssi2"
> +(define_expand "floatuns2"
>[(parallel
> [(set (match_operand:X87MODEF 0 "register_operand")
> (unsigned_float:X87MODEF
> - (match_operand:SI 1 "nonimmediate_operand")))
> + (match
On 08/06/2013 06:06 AM, David Malcolm wrote:
> Index: gcc/config/epiphany/epiphany.h
> ===
> --- gcc/config/epiphany/epiphany.h(revision 201526)
> +++ gcc/config/epiphany/epiphany.h(working copy)
> @@ -929,6 +929,9 @@
> };
>
On Tue, Aug 6, 2013 at 1:12 PM, Caroline Tice wrote:
> I was talking with Diego, and he suggested the possibility of putting
> the log files in the same directory that the gcc dump files go, i.e.
> the one specified by dump_base_name. Do you think that would be
> acceptable?
Sure.
Ian
> On Tue
Actually, I think that was dump_dir_name.
-- Caroline
On Tue, Aug 6, 2013 at 1:12 PM, Caroline Tice wrote:
> I was talking with Diego, and he suggested the possibility of putting
> the log files in the same directory that the gcc dump files go, i.e.
> the one specified by dump_base_name. Do you
I was talking with Diego, and he suggested the possibility of putting
the log files in the same directory that the gcc dump files go, i.e.
the one specified by dump_base_name. Do you think that would be
acceptable?
-- Caroline Tice
cmt...@google.com
On Tue, Aug 6, 2013 at 12:12 PM, Ian Lance Tay
BTW, you've a bug in your movqi pattern:
> diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
> index b4c9ac5..d8401b5 100644
> --- a/gcc/config/i386/i386.md
> +++ b/gcc/config/i386/i386.md
> @@ -2298,7 +2298,7 @@
> ;; partial register stall can be caused there. Then we use movzx.
>
I merged revision 201542 from the 4.8 branch to the gccgo branch.
Ian
On Tue, Aug 6, 2013 at 12:07 PM, Caroline Tice wrote:
>
>
>
> On Tue, Aug 6, 2013 at 12:02 PM, Ian Lance Taylor wrote:
>>
>> On Tue, Aug 6, 2013 at 11:43 AM, Caroline Tice wrote:
>> >
>> > On Tue, Aug 6, 2013 at 11:31 AM, Ian Lance Taylor
>> > wrote:
>> >
>> >>The output to the file doesn't hav
On Mon, 2013-08-05 at 17:03 -0400, David Malcolm wrote:
> On Mon, 2013-07-29 at 15:41 -0600, Jeff Law wrote:
> > On 07/26/2013 09:04 AM, David Malcolm wrote:
> > > This patch is the hand-written part of the conversion of passes from
> > > C structs to C++ classes. It does not work without the subs
On 08/06/2013 03:57 AM, Kirill Yukhin wrote:
> On 05 Aug 09:55, Richard Henderson wrote:
>> On 08/05/2013 08:07 AM, Kirill Yukhin wrote:
>>> Hello Richard, Vlad,
>>>
>>> On 31 Jul 06:26, Richard Henderson wrote:
On 07/31/2013 05:02 AM, Kirill Yukhin wrote:
>
> There's ICE (max. number
On Tue, Aug 6, 2013 at 11:43 AM, Caroline Tice wrote:
>
> On Tue, Aug 6, 2013 at 11:31 AM, Ian Lance Taylor wrote:
>
>>The output to the file doesn't have
>> any indication of what file is being compiled, so it will be ambiguous
>> when run in parallel.
>
> You are mistaken. It outputs one line
On Tue, 2013-08-06 at 19:11 +0100, Richard Sandiford wrote:
> David Malcolm writes:
> > commit 11d46884e8bd9802b0f528a16b3970b4076fe8a9
> > Author: David Malcolm
> > Date: Tue Aug 6 13:48:59 2013 -0400
> >
> > gcc/
> > * config/mips/mips.c (insert_pass_mips_machine_reorg2): Move
On Tue, Aug 6, 2013 at 10:35 AM, Caroline Tice wrote:
>
> choose_tmpdir(), from libiberty is not mentioned in any .h file, so cannot
> (at the moment) be used here. Is it OK for me to add choose_tmpdir to
> libiberty.h?
Well, maybe. But the approach looks a bit odd to me. Also very
underdocume
David Malcolm writes:
> commit 11d46884e8bd9802b0f528a16b3970b4076fe8a9
> Author: David Malcolm
> Date: Tue Aug 6 13:48:59 2013 -0400
>
> gcc/
> * config/mips/mips.c (insert_pass_mips_machine_reorg2): Move
> into...
> (mips_option_override): ...here, porting to new C++ API
yes -- if this is the place developers look at the most.
David
On Tue, Aug 6, 2013 at 10:18 AM, Sharad Singhai wrote:
> On Tue, Aug 6, 2013 at 10:10 AM, Martin Jambor wrote:
>> On Tue, Aug 06, 2013 at 09:22:02AM -0700, Sharad Singhai wrote:
>>> On Tue, Aug 6, 2013 at 8:57 AM, Xinliang David Li
On Tue, 2013-08-06 at 12:43 +0200, Dominique Dhumieres wrote:
> > Hence plugins that create passes will need to be built with RTTI
> > disabled in order to link against gcc, or they will fail to load, with
> > an error like: ...
>
> The same holds for darwin, hence the following patch is needed:
>
On Tue, 2013-08-06 at 08:16 -0700, Steve Ellcey wrote:
> On Mon, 2013-08-05 at 17:03 -0400, David Malcolm wrote:
>
> > Given all of the above testing I'm reasonably confident that this works.
> > However this is such a large change [1] that there's a non-zero chance
> > of at least one glitch - le
Hi,
nobody replied to this, presumably because nobody has any objections
but also nobody really cares, and the patch sits there in my queue.
OTOH, some time ago people on IRC told me to just commit it. It only
adds a testcase so I'll take the risk of being yelled at and go ahead.
I believe there
On Tue, 2013-08-06 at 14:12 +0200, Jan-Benedict Glaw wrote:
> On Tue, 2013-08-06 14:10:11 +0200, Jan-Benedict Glaw
> wrote:
> > And probably also for sparc{,64}-linux:
> >
> > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> > -fno-rtti -fasynchronous-unwind-tables -W -Wa
Hi,
Bernd Edlinger reported that my new testcase for PR 58041 generates
warnings about ABI on i686. The following fixes it so I am going to
commit it now to both trunk and the 4.8 branch so that as few people
as possible see new failures.
Sorry for the fuss and thanks Bernd for reporting and tes
On Tue, Aug 6, 2013 at 10:10 AM, Martin Jambor wrote:
> On Tue, Aug 06, 2013 at 09:22:02AM -0700, Sharad Singhai wrote:
>> On Tue, Aug 6, 2013 at 8:57 AM, Xinliang David Li wrote:
>> > On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor wrote:
>> >> Hi,
>> >>
>> >> On Mon, Aug 05, 2013 at 10:37:00PM -
On Tue, 2013-08-06 at 13:18 +0200, Jan-Benedict Glaw wrote:
> On Tue, 2013-08-06 13:12:57 +0200, Jan-Benedict Glaw
> wrote:
> > On Mon, 2013-08-05 20:16:05 -, dmalc...@gcc.gnu.org
> > wrote:
> > > New Revision: 201508
> > >
> > > URL: http://gcc.gnu.org/viewcvs?rev=201508&root=gcc&view=rev
On Tue, Aug 06, 2013 at 09:22:02AM -0700, Sharad Singhai wrote:
> On Tue, Aug 6, 2013 at 8:57 AM, Xinliang David Li wrote:
> > On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor wrote:
> >> Hi,
> >>
> >> On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teresa Johnson wrote:
> >>> This patch ports messages to
On 08/06/2013 06:49 AM, Aldy Hernandez wrote:
>> --- gcc/ipa-inline-analysis.c
>> +++ gcc/ipa-inline-analysis.c
>> @@ -1433,6 +1433,9 @@ initialize_inline_failed (struct cgraph_edge *e)
>> e->inline_failed = CIF_REDEFINED_EXTERN_INLINE;
>>else if (e->call_stmt_cannot_inline_p)
>> e->i
[Richard, small question for you below].
Not all your changes to Makefile.in have a changelog entry.
+c-family/cilk.o : c-family/cilk.c $(TREE_H) $(SYSTEM_H) $(CONFIG_H)
toplev.h \
+$(TREE_H) coretypes.h tree-iterator.h $(TREE_INLINE_H)
$(CGRAPH_H) \
+ $(DIAGNOSTIC_COR
Forgot the patch.
David
On Tue, Aug 6, 2013 at 9:42 AM, Xinliang David Li wrote:
> Corrected two small problems reported by the style checker (The
> warnings about the EnumValue for options in stringopt.opt are not
> valid).
>
> On Tue, Aug 6, 2013 at 1:46 AM, Michael Zolotukhin
> wrote:
>> Th
Corrected two small problems reported by the style checker (The
warnings about the EnumValue for options in stringopt.opt are not
valid).
On Tue, Aug 6, 2013 at 1:46 AM, Michael Zolotukhin
wrote:
> There are still some formatting issues (like 8 spaces instead of a
> tab, wrong indentation of do-
On Tue, Aug 6, 2013 at 2:20 AM, Uros Bizjak wrote:
>
> Patch [1] or [2] introduce following warning on alpha:
>
> /space/uros/gcc-build/gcc/testsuite/go2/../../gccgo
> -B/space/uros/gcc-build/gcc/testsuite/go2/../../
> /home/uros/gcc-svn/trunk/gcc/testsuite/go.test/test/cmplxdivide.go
> /home/uros
... today I did the following: commented out the error at issue
(decl.c:11828) and ran the testsuite. The attached js.txt is the list of
fails. Wanted to make sure that we have enough coverage.
I'm also attaching here the complete patch + testcase which passes boot
& test.
Thanks!
Paolo.
//
On Tue, Aug 6, 2013 at 9:01 AM, Martin Jambor wrote:
> Hi,
>
> On Tue, Aug 06, 2013 at 07:14:42AM -0700, Teresa Johnson wrote:
>> On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor wrote:
>> > On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teresa Johnson wrote:
>> >> This patch ports messages to the new du
On Tue, 2013-08-06 12:06:24 -0400, David Malcolm wrote:
> On Tue, 2013-08-06 at 13:12 +0200, Jan-Benedict Glaw wrote:
> > On Mon, 2013-08-05 20:16:05 -, dmalc...@gcc.gnu.org
> > wrote:
[Breakage on epiphany-elf]
> I'm kicking off a bootstrap of this (on x86_64) to further verify that
> the
On Tue, Aug 6, 2013 at 8:57 AM, Xinliang David Li wrote:
> On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor wrote:
>> Hi,
>>
>> On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teresa Johnson wrote:
>>> This patch ports messages to the new dump framework,
>>
>> It would be great this new framework was docu
On Tue, 2013-08-06 at 12:06 -0400, David Malcolm wrote:
> On Tue, 2013-08-06 at 13:12 +0200, Jan-Benedict Glaw wrote:
> > On Mon, 2013-08-05 20:16:05 -, dmalc...@gcc.gnu.org
> > wrote:
> > > New Revision: 201508
> > >
> > > URL: http://gcc.gnu.org/viewcvs?rev=201508&root=gcc&view=rev
> > > L
On Tue, Aug 6, 2013 at 2:42 AM, Jan Hubicka wrote:
>> >>> 2013-08-02 Xinliang David Li
>> >>>
>> >>> * config/i386/stringop.def: New file.
>> >>> * config/i386/stringop.opt: New file.
>> >>> * config/i386/i386-opts.h: Include stringopt.def.
>> >>> * config/i386/i
On Tue, 2013-08-06 at 13:12 +0200, Jan-Benedict Glaw wrote:
> On Mon, 2013-08-05 20:16:05 -, dmalc...@gcc.gnu.org
> wrote:
> > New Revision: 201508
> >
> > URL: http://gcc.gnu.org/viewcvs?rev=201508&root=gcc&view=rev
> > Log:
> > Automated conversion of passes to C++ classes
> >
> > gcc/
>
Hi,
On Tue, Aug 06, 2013 at 07:14:42AM -0700, Teresa Johnson wrote:
> On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor wrote:
> > On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teresa Johnson wrote:
> >> This patch ports messages to the new dump framework,
> >
> > It would be great this new framework was
On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor wrote:
> Hi,
>
> On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teresa Johnson wrote:
>> This patch ports messages to the new dump framework,
>
> It would be great this new framework was documented somewhere. I lost
> track of what was agreed it would be a
On Mon, 2013-08-05 at 17:03 -0400, David Malcolm wrote:
> Given all of the above testing I'm reasonably confident that this works.
> However this is such a large change [1] that there's a non-zero chance
> of at least one glitch - let me know if you see any breakages.
The mips*-*-* targets are no
Hi all,
attached is a cleanup patch which concerns the gfc_code structure and
gfc_get_code function (in st.c). It basically does two things:
1) It replaces the many occurrences of "XCNEW (gfc_code)" in class.c
by "gfc_get_code ()", which internally sets the locus and saves us
from doing it manual
Yuri Rumyantsev writes:
> * config/i386/i386.md (floatunssi2 expand): Add support
> for QI/HImode operand to produce more effecient code for
s/effecient/efficient/
Andreas.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"A
On Wed, Jul 31, 2013 at 02:52:39PM -0400, Jason Merrill wrote:
> >http://gcc.gnu.org/ml/gcc-patches/2013-07/msg01536.html
>
> Here, the C++ compiler is wrong to fold away the division by zero,
> but given that bug the folding ought to also eliminate the call to
> the sanitize function. Seems like
Hi All,
Here is simple fix which produces more optimal code unsigned
char(short) to float(double) with direct rtl-generation.
Bootstrapping and regression testing were successful for x86-64.
Is it OK for trunk?
ChangeLog:
2013-08-06 Yuri Rumyantsev
* config/i386/i386.md (floatunssi2 expand
On Tue, Aug 6, 2013 at 5:37 AM, Martin Jambor wrote:
> Hi,
>
> On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teresa Johnson wrote:
>> This patch ports messages to the new dump framework,
>
> It would be great this new framework was documented somewhere. I lost
> track of what was agreed it would be a
Hi,
this patch breaks out lto.c' code to read given function body into
cgraph_get_body. Instead of reading all bodies at once, we now read only
bodies that are needed on demand. This is how I planned to get whole program
compilation working back in 2004, so code is still mostly ready for it. :)
S
Thanks Andreas, it seems clear now that Bionic rand function is not
consistent with the standart.
--Alexander
2013/8/6 Andreas Schwab :
> Alexander Ivchenko writes:
>
>> Still, in C standart it is said that rand is defined in stdlib.h, and
>> we don't include it in that testcase.
>
> It also sa
Hi,
On Mon, Aug 05, 2013 at 10:37:00PM -0700, Teresa Johnson wrote:
> This patch ports messages to the new dump framework,
It would be great this new framework was documented somewhere. I lost
track of what was agreed it would be and from the uses in the
vectorizer I was never quite sure how to
On Tue, 2013-08-06 14:10:11 +0200, Jan-Benedict Glaw wrote:
> And probably also for sparc{,64}-linux:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions
> -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
> -Wwrite-strings -Wcast-qual -Wmissing-format-attribu
On Tue, 2013-08-06 13:18:16 +0200, Jan-Benedict Glaw wrote:
> On Tue, 2013-08-06 13:12:57 +0200, Jan-Benedict Glaw
> wrote:
> > On Mon, 2013-08-05 20:16:05 -, dmalc...@gcc.gnu.org
> > wrote:
> > > New Revision: 201508
> > >
> > > URL: http://gcc.gnu.org/viewcvs?rev=201508&root=gcc&view=re
Alexander Ivchenko writes:
> Still, in C standart it is said that rand is defined in stdlib.h, and
> we don't include it in that testcase.
It also says: "Provided that a library function can be declared without
reference to any type defined in a header, it is also permissible to
declare the func
The reason for undefined reference to rand is that it is defined as
"static __inline__" in Bionic stdlib.h:
static __inline__ int rand(void) {
return (int)lrand48();
}
So in fact, if you do "nm libc.so" for Bionic, you won't get the
rand.. which is probably not correct, because it doesn't hav
Hi!
On Mon, 2013-08-05 22:09:45 -, olege...@gcc.gnu.org
wrote:
> Author: olegendo
> Date: Mon Aug 5 22:09:45 2013
> New Revision: 201513
>
> URL: http://gcc.gnu.org/viewcvs?rev=201513&root=gcc&view=rev
> Log:
> PR other/12081
> * recog.h (rtx (*insn_gen_fn) (rtx, ...)): Replace
On Tue, 2013-08-06 13:12:57 +0200, Jan-Benedict Glaw wrote:
> On Mon, 2013-08-05 20:16:05 -, dmalc...@gcc.gnu.org
> wrote:
> > New Revision: 201508
> >
> > URL: http://gcc.gnu.org/viewcvs?rev=201508&root=gcc&view=rev
> > Log:
> > Automated conversion of passes to C++ classes
> >
> > gcc/
>
On Mon, 2013-08-05 20:16:05 -, dmalc...@gcc.gnu.org
wrote:
> New Revision: 201508
>
> URL: http://gcc.gnu.org/viewcvs?rev=201508&root=gcc&view=rev
> Log:
> Automated conversion of passes to C++ classes
>
> gcc/
>
> Patch autogenerated by refactor_passes.py from
> https://github
On Sun, 4 Aug 2013, Tom G. Christensen wrote:
> Latest results for gcc 4.8.x.
>
> -tgc
>
> Testresults for 4.8.1
> arm-unknown-linux-gnueabi
> hppa2.0w-hp-hpux11.11
> hppa64-hp-hpux11.11
> i386-pc-solaris2.9 (2)
> i686-pc-linux-gnu
> mips-unknown-linux-gnu
> mipsel-unknown-linux-gnu
> Hence plugins that create passes will need to be built with RTTI
> disabled in order to link against gcc, or they will fail to load, with
> an error like: ...
The same holds for darwin, hence the following patch is needed:
--- ../_clean/gcc/testsuite/lib/plugin-support.exp 2013-08-05
22:5
Hi Thomas,
> the rather self-explanatory patch implements the -Wzerotrip
> option. The positive form is not really useful, because
> the option is on by default (so the default behavior is
> not changed).
>
> The negative form of the option, -Wno-zerotrip, suppresses the
> warning. I have also a
On 08/06/2013 11:40 AM, Uros Bizjak wrote:
On Tue, Aug 6, 2013 at 11:33 AM, Paolo Carlini wrote:
Recent build failure on alpha-linux-gnu (r201522)
Uros, please revert it, thanks, we don't have the time to seriously look
into it now.
Francois, please be more careful with testing, it's the sec
> -Original Message-
> From: Andrew Pinski [mailto:pins...@gmail.com]
> Sent: Monday, August 05, 2013 4:40 PM
> To: Zhenqiang Chen
> Cc: GCC Patches
> Subject: Re: [PATCH] Reassociate X == CST1 || X == CST2 if popcount (CST2 -
> CST1) == 1 into ((X - CST1) & ~(CST2 - CST1)) == 0
>
> On Mo
> >>> 2013-08-02 Xinliang David Li
> >>>
> >>> * config/i386/stringop.def: New file.
> >>> * config/i386/stringop.opt: New file.
> >>> * config/i386/i386-opts.h: Include stringopt.def.
> >>> * config/i386/i386.opt: Include stringopt.opt.
> >>> * config/i38
On Tue, Aug 6, 2013 at 11:33 AM, Paolo Carlini wrote:
>> Recent build failure on alpha-linux-gnu (r201522)
>
> Uros, please revert it, thanks, we don't have the time to seriously look
> into it now.
>
> Francois, please be more careful with testing, it's the second time in a few
> days.
It looks
On 08/06/2013 11:30 AM, Uros Bizjak wrote:
Hello!
Recent build failure on alpha-linux-gnu (r201522)
Uros, please revert it, thanks, we don't have the time to seriously look
into it now.
Francois, please be more careful with testing, it's the second time in a
few days.
Paolo.
Hello!
Recent build failure on alpha-linux-gnu (r201522)
gmake[6]: Entering directory
`/space/homedirs/uros/gcc-build-xxx/alphaev68-unknown-linux-gnu/libstdc++-v3/src/c++11'
/bin/sh ../../libtool --tag CXX --tag disable-shared --mode=compile
/home/uros/gcc-build-xxx/./gcc/xgcc -shared-libgcc
-B
OK for embedded 4.8 branch
- Joey
> -Original Message-
> From: Terry Guo
> Sent: Tuesday, August 06, 2013 14:17
> To: Joey Ye
> Cc: gcc-patches@gcc.gnu.org
> Subject: [arm-embedded] Request to backport thumb1 far jump patch to
> embedded 4.8 branch
>
> Hello Joey,
>
> The thumb1 far jum
Hi,
On 08/06/2013 04:57 AM, Jason Merrill wrote:
On 08/05/2013 06:46 PM, Paolo Carlini wrote:
and after this comment, both pairs of qualify_lookup are called in that
order. Thus I started seriously suspecting that something may be wrong
in the if-else above, that is, that we really want somethi
On 06/08/13 10:04, Richard Earnshaw wrote:
> On 06/08/13 09:48, James Greenhalgh wrote:
>> *Ping*
>>
>> James
>>
>> On Thu, Aug 01, 2013 at 02:50:07PM +0100, Sofiane Naci wrote:
>>> Hi,
>>>
>>> This patch is part of the ongoing work to unify instruction classification
>>> between the ARM and AARCH6
On 06/08/13 09:48, James Greenhalgh wrote:
> *Ping*
>
> James
>
> On Thu, Aug 01, 2013 at 02:50:07PM +0100, Sofiane Naci wrote:
>> Hi,
>>
>> This patch is part of the ongoing work to unify instruction classification
>> between the ARM and AARCH64 backends.
>>
>> This patch fine tunes the ALU/shif
*Ping*
James
On Thu, Aug 01, 2013 at 02:50:07PM +0100, Sofiane Naci wrote:
> Hi,
>
> This patch is part of the ongoing work to unify instruction classification
> between the ARM and AARCH64 backends.
>
> This patch fine tunes the ALU/shift type attribute values in the ARM backend
> as detailed
There are still some formatting issues (like 8 spaces instead of a
tab, wrong indentation of do-loop and some other places) - to reveal
some of them you could use contrib/check_GNU_style.sh script.
But that was a nitpicking again:) Actually I wanted to ask whether
you're going to use this option fo
Ok then attached patch applied.
2013-08-06 François Dumont
* include/bits/hashtable_policy.h (_Hashtable_alloc): New.
(_ReuseOrAllocNode, _AllocNode): Adapt to use latter rather than
_Hashtable.
(_Before_begin<>): Remove.
* include/bits/hashtable.h (_Hashtable): Inherit fr
>> Sorry for the belated review.
>>
>> + bool ptr = sym->attr.pointer || sym->attr.allocatable
>> +|| (sym->ts.type == BT_CLASS
>> +&& CLASS_DATA (sym)->attr.class_pointer);
>>
>>
>> That looks quite imbalanced. Why do you not take care of
>> CLASS_DATA(sym)
Hi,
> Sorry for the belated review.
>
> + bool ptr = sym->attr.pointer || sym->attr.allocatable
> +|| (sym->ts.type == BT_CLASS
> +&& CLASS_DATA (sym)->attr.class_pointer);
>
>
> That looks quite imbalanced. Why do you not take care of
> CLASS_DATA(sym)->at
96 matches
Mail list logo