Hi!
The tail recursion optimization hasn't been adjusted for POINTER_PLUS_EXPR
introduction, so we can try to produce PLUS_EXPR with 2 pointer operands or
not optimize testcases we could with preexisting POINTER_PLUS_EXPR.
The following patch attempts to fix that. The last two hunks teach it
to
Hi!
On the following testcase we generate
.section.lbss,"aw",@progbits
which causes assembler warning, it is supposed to be
.section.lbss,"aw",@nobits
instead. The following patch fixes that. I went through all of
default_section_type_flags and looked for which sections the defau
Ping^2
Thanks.
bin
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On Behalf Of bin.cheng
Sent: Thursday, August 08, 2013 4:51 PM
To: gcc-patches@gcc.gnu.org
Cc: Richard Earnshaw
Subject: [PING][PATCH ARM]Extend thumb1_reorg to save more compa
Jakub Jelinek wrote:
>Hi!
>
>The tail recursion optimization hasn't been adjusted for
>POINTER_PLUS_EXPR
>introduction, so we can try to produce PLUS_EXPR with 2 pointer
>operands or
>not optimize testcases we could with preexisting POINTER_PLUS_EXPR.
>
>The following patch attempts to fix that.
Hi Joseph,
Your patch itself makes sense on general principles, but the concept of an
AVR Linux target doesn't - this is an 8-bit processor Really, the bug
you've found is that there's an avr-*-* case that is too general, matching
nonsensical targets such as AVR Linux rather than just avr-*-
Hello,
On 22 Aug 12:06, Richard Henderson wrote:
> Ok.
I've updated ChangeLog (thanks, HJ!) and
checked in to main trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-08/msg00545.html
--
Thanks, K
Inspired by this mail: http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html
Thanks!
--
Tim Shen
regex-locale.patch
Description: Binary data
> It was also on the mailing list too. If I'd had the reference to 57940,
> I wouldn't have approved the patch given your comment from July 20.
Understood. I missed the message on the list and remembered only the PR.
--
Eric Botcazou
On Fri, Aug 23, 2013 at 9:08 AM, Jakub Jelinek wrote:
> On the following testcase we generate
> .section.lbss,"aw",@progbits
> which causes assembler warning, it is supposed to be
> .section.lbss,"aw",@nobits
> instead. The following patch fixes that. I went through all of
> def
On 08/21/2013 04:30 PM, Jan Hubicka wrote:
Index: ipa.c
===
--- ipa.c (revision 201890)
+++ ipa.c (working copy)
@@ -1397,7 +1397,7 @@ ipa_profile_read_summary (void)
static unsigned int
ipa_profile (void)
{
- stru
On 23 August 2013 10:15, Tim Shen wrote:
> These two patches are not logically relative, but the next patch is
> based on this one.
>
> This patch of the regex scanner(or lexer) supports all styles
> specified by N3376. It shall build an abstract layer of regex token
> sequence, so that, ideally,
On 23 August 2013 10:17, Tim Shen wrote:
> Inspired by this mail: http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html
This is OK too, thanks for the quick fix to the locale issue!
On Thu, Aug 22, 2013 at 06:09:40PM -0700, Ian Lance Taylor wrote:
> On Thu, Aug 22, 2013 at 5:35 PM, Alan Modra wrote:
> > On Fri, Aug 16, 2013 at 06:18:05PM +0930, Alan Modra wrote:
> >> I'd like to apply the following patch to the gcc repository (well,
> >> excluding the libgo part which I'm hop
Hi,
On 08/23/2013 11:17 AM, Tim Shen wrote:
2013-08-23 Tim Shen
* include/bits/regex.h: Fix callers.
* include/bits/regex_compiler.h: Store _Traits reference.
* include/bits/regex_executor.h: Add _Traits member for _DFSExecutor.
* include/bits/regex_exe
This patchlet is an easy low hanging fruit in the pile of local patches
I have. It turns old style emulation of inline functions into real inline
functions.
Tested on x86_64-suse-linux. Applied to mainline.
-- Gaby
2013-08-23 Gabriel Dos Reis
* pretty-print.h (pp_newline_and_flus
This patch fixes bootstrap comparison when doing bootstrap
with -fsanitize=undefined enabled. We need to hash the UID of the
type and also I had to switch two statements; we need to get
TYPE_MAIN_VARIANT of the type first...
Hence, no more bootstrap comparison failures. Woohoo!
Tested x86_64-lin
On Fri, Aug 23, 2013 at 02:37:56PM +0200, Marek Polacek wrote:
> This patch fixes bootstrap comparison when doing bootstrap
> with -fsanitize=undefined enabled. We need to hash the UID of the
> type and also I had to switch two statements; we need to get
> TYPE_MAIN_VARIANT of the type first...
>
Hi,
On Fri, Aug 02, 2013 at 09:48:43PM -0400, David Malcolm wrote:
> GDB 7.0 onwards supports hooks written in Python to improve the
> quality-of-life within the debugger. The best known are the
> pretty-printing hooks [1], which we already use within libstdc++ for
> printing better representatio
On Fri, Aug 23, 2013 at 02:44:49PM +0200, Jakub Jelinek wrote:
> Why not just return TYPE_UID (data->type); ?
Wasn't aware it's enough.
> Anyway, once you change the hash table uses into pointer_map, this will
> all go away.
Right.
Marek
Hi,
besides the issue discussed a bit some time ago, we have got in Bugzilla
a number of other issues, all essentially dups of each other (modulo
irrelevant details, AFAICS)
c++/51488
c++/53618
c++/58059
c++/56163 (this is two bugs, the second one is dup of c++/55843)
In thes
Hi,
Please find the patch to add assembler option "-mcu" for generating assembler
error messages when target not supporting hardware FPU were seeing FPU code,
namely RX100 and RX200.
KPIT has recently submitted a patch to add warnings of RX variants that do not
have hardware FPU support,
http://w
Hi Steve and Kaz,
Sorry about that. Kaz has a fix shown in rtl-optimization/58220:
--- ORIG/trunk/gcc/final.c 2013-08-22 09:43:35.0 +0900
+++ trunk/gcc/final.c 2013-08-22 14:36:51.0 +0900
@@ -1650,7 +1650,7 @@ reemit_insn_block_notes (void)
rtx insn, note;
insn = get_insns
On 08/22/2013 12:05 PM, Paolo Carlini wrote:
Sorry if I'm saying something rather vague: I suppose you mean
BINFO_FLAG_6? Because it's the last one.
No, that's a language-specific flag.
Jason
On 08/22/2013 11:22 AM, Jan Hubicka wrote:
This option did not occured to me and of course I would be bit fearing of C++ FE
not having binfos ready all the time it wants to touch the type. But probably
you know if that can happen ;)
Classes (including struct and union) always have binfos.
Jas
> On 08/22/2013 11:22 AM, Jan Hubicka wrote:
> >This option did not occured to me and of course I would be bit fearing of
> >C++ FE
> >not having binfos ready all the time it wants to touch the type. But
> >probably
> >you know if that can happen ;)
>
> Classes (including struct and union) alwa
On 08/23/2013 03:47 PM, Jason Merrill wrote:
On 08/22/2013 12:05 PM, Paolo Carlini wrote:
Sorry if I'm saying something rather vague: I suppose you mean
BINFO_FLAG_6? Because it's the last one.
No, that's a language-specific flag.
Ah great. Thanks!
Paolo.
On Fri, Aug 23, 2013 at 6:29 PM, Paolo Carlini wrote:
> Thanks a lot indeed. But: "Fix callers" of *what*?!? And from *where*? To be
> really honest this kind of ChangeLog entry doesn't make much sense. Please
> get used to list the specific functions you are changing. It's important.
I see.
Act
On Fri, Aug 23, 2013 at 5:40 PM, Jonathan Wakely wrote:
> I would rearrange the ChangeLog, to put
>
> * include/bits/regex_executor.tcc: Don't use reference for submatch.
>
> after regex_scanner.tcc, so that the files the _Scanner is moved from
> come immediately before the files it is mov
Hello,
This is new patch version.
Optimization does not use BIT_FIELD_REF any more, instead it generates new
COMPONENT_REF and FIELD_DECL.
Existing Bit field representative is associated with newly created field
declaration.
During analysis phase optimization uses bit field representatives when
On 08/23/2013 09:57 AM, Jan Hubicka wrote:
Ok, I will prepare variant using public_flag of BINFO that seeems unused.
I.e. having BINFO_FINAL_P and C++ specific macro
CLASSTYPE_FINAL(t) as BINFO_FINAL_P (TYPE_BINFO (t)).
Sounds good.
Jason
> Hi,
> I went through some statistics on firefox build (it is a source combining
> many coding styles).
> I was basically curious where we do devirtualization. The result is:
>
> Before inline (i.e. important devirtualization)
> 624 ssa-pre devirt 0
> this is interaprocedural deviru
On 08/23/2013 03:59 PM, Tim Shen wrote:
On Fri, Aug 23, 2013 at 6:29 PM, Paolo Carlini wrote:
Thanks a lot indeed. But: "Fix callers" of *what*?!? And from *where*? To be
really honest this kind of ChangeLog entry doesn't make much sense. Please
get used to list the specific functions you are c
> On 08/23/2013 09:57 AM, Jan Hubicka wrote:
> >Ok, I will prepare variant using public_flag of BINFO that seeems unused.
> >I.e. having BINFO_FINAL_P and C++ specific macro
> >CLASSTYPE_FINAL(t) as BINFO_FINAL_P (TYPE_BINFO (t)).
>
> Sounds good.
Hi,
this is patch I am testing. Does it look OK?
The following patch was just committed as r201941 (pre-approved by
Jakub) to fix PR rtl-optimization/58220 and PR regression/58221.
Bootstrapped and tested on x86_64-unknown-linux-gnu. also confirmed
that I could reproduce the problem in PR rtl-optimization/58220 and
that the patch fixes it. Thanks
On Fri, Aug 23, 2013 at 6:34 AM, Teresa Johnson wrote:
> Hi Steve and Kaz,
>
> Sorry about that. Kaz has a fix shown in rtl-optimization/58220:
>
> --- ORIG/trunk/gcc/final.c 2013-08-22 09:43:35.0 +0900
> +++ trunk/gcc/final.c 2013-08-22 14:36:51.0 +0900
> @@ -1650,7 +1650,7 @@ ree
> Hi,
> this is patch I am testing. Does it look OK?
> Index: cp/pt.c
> ===
> --- cp/pt.c (revision 201910)
> +++ cp/pt.c (working copy)
> @@ -8730,7 +8730,8 @@ instantiate_class_template_1 (tree type)
>/* Adjust visibilit
On Fri, Aug 23, 2013 at 10:26 PM, Paolo Carlini
wrote:
> Great. But please but the names of the functions you are changing between
> round brackets. You have tons of examples everywhere.
...like this?
--
Tim Shen
changelog
Description: Binary data
On 23 August 2013 15:53, Tim Shen wrote:
> On Fri, Aug 23, 2013 at 10:26 PM, Paolo Carlini
> wrote:
>> Great. But please but the names of the functions you are changing between
>> round brackets. You have tons of examples everywhere.
>
> ...like this?
Yes, that makes it clear what part of the fil
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap with Richard B.'s comments.
I also expect many of them
On 08/23/2013 04:53 PM, Tim Shen wrote:
On Fri, Aug 23, 2013 at 10:26 PM, Paolo Carlini
wrote:
Great. But please but the names of the functions you are changing between
round brackets. You have tons of examples everywhere.
...like this?
The assign change is fine. But I would also put between r
Hi,
On Mon, Aug 19, 2013 at 11:10:31AM +0200, Jan Hubicka wrote:
> Hi,
> here is variant of patch that drops the field walking from
> gimple_extract_devirt_binfo_from_cst completely. As pointed out
> by Jason, it is pointless since all structures have BINFO in C++
> and thus get_binfo_at_offset wi
Hi Jakub and/or Joseph,
the reporter of this bug seems to be very anxious to have it fixed in
the repository. While Richi is away, do you think you could have a
look? It is very small.
Thanks a lot,
Martin
On Fri, Aug 02, 2013 at 01:45:31PM +0200, Martin Jambor wrote:
> Hi,
>
> while comput
Hi,
this patch makes cgraphunit.c to do very simple devirtualization when method
being called is from anonymous namespace class and none of its derivations
overwrite the method. I do it in cgraph build only because later we need
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01007.html first so the
On Thu, Aug 22, 2013 at 7:15 PM, Alan Modra wrote:
> Without another tmake file it really is exactly the same as before.
>
> old, after applying "make" string gunk
> MULTILIB_OPTIONS = m64/m32
> MULTILIB_OSDIRNAMES = ../lib64 ../lib
>
> new
> MULTILIB_OPTIONS = m64/m32
> MULTILIB_OSDIRNAMES = m64
On Fri, Aug 23, 2013 at 05:11:22PM +0200, Martin Jambor wrote:
> Hi Jakub and/or Joseph,
>
> the reporter of this bug seems to be very anxious to have it fixed in
> the repository. While Richi is away, do you think you could have a
> look? It is very small.
Isn't this ABI incompatible change (a
Jan,
This has broken all builds because method_type_class() is defined.
Graham
On Fri, Aug 23, 2013 at 11:03 PM, Paolo Carlini
wrote:
> The assign change is fine. But I would also put between round brackets
> (class _Compiler<>) for the _M_traits change and use something like
> (_DFSExecutor<>::_DFSExecutor): Adjust. for the last change (remember that
> constructors are spec
> Jan,
>
> This has broken all builds because method_type_class() is defined.
Oops, sorry for that. I happened to make partial diff only.
This patch adds the missing bit.
Honza
Index: ChangeLog
===
--- ChangeLog (revision 201943
On 23 August 2013 16:48, Tim Shen wrote:
> By the way, do we seariously need to keep ChangeLog in files? Is it
> more like a tradition than a solution? After all, we have SVN or Git
> now. I remember a mail metioned this but cannot find it >.<
It's not a tradition, they are required, see
http://ww
On Fri, 2013-08-23 at 07:38 -0700, Teresa Johnson wrote:
> > It should be committed soon, by Kaz or myself once testing finishes.
> > Please let me know if that doesn't fix your failures.
>
> Fix committed as r201941. Let me know if you still have issues.
>
> Teresa
This patch fixes the problem
2013/8/22 Mikael Morin :
> Le 22/08/2013 17:41, Janus Weil a écrit :
>> Hi all,
>>
>> here is a wrong-code fix for type-bound assignments, which makes sure
>> that these are resolved to polymorphic procedure calls. This was not
>> always the case, because we used the wrong ordering when checking fo
Am Fri, 23 Aug 2013 17:17:41 +0800
schrieb Tim Shen :
> Inspired by this mail:
> http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html
>
> Thanks!
>
>
Hi Tim,
I applied the patch + compiled everything - it's working now! Thanks!
But... I found a problem with .imbue():
int main()
{
s
On Sun, 4 Aug 2013, Gerald Pfeifer wrote:
On Sat, 13 Jul 2013, Marc Glisse wrote:
2013-07-14 Marc Glisse
gcc/cp/
* call.c (build_conditional_expr_1): Handle the case with 1 vector
and 2 scalars. Call save_expr before building a vector.
* typeck.c (cp_build_binary_op)
so... can I get an official "ok to commit with you and Nick as maintainers"
then?
On 08/23/2013 11:02 AM, Richard Sandiford wrote:
Hi Kenny,
This is the first time I've looked at the implementation of wide-int.h
(rather than just looking at the rtl changes, which as you know I like
in general), so FWIW here are some comments on wide-int.h. I expect
a lot of them overlap with
On Tue, 20 Aug 2013, Cong Hou wrote:
> When a sin() (cos(), log(), etc.) function is called on a value of
> float type and the returned double value is converted to another value
> of float type, GCC converts this function call into a float version
> (sinf()) in the optimization mode. This avoids
This patch has not been reviewed for more than three months:
http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00113.html
This patch from Chris Manghane fixes a bug in the type reflection
information for a struct with an anonymous field of a builtin type.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
Ian
diff -r ea33e34cb12d go/types.cc
--- a/go/types.cc Thu Aug
On Wed, 21 Aug 2013, Zhenqiang Chen wrote:
> SHORT_CIRCUIT expression will be converted to CCMP expressions
> at the end of front-end.
That doesn't sound like the right place to me. We want the same code to
be generated whether users write && and || directly or write corresponding
sequences of
> That doesn't sound like the right place to me. We want the same code to
> be generated whether users write && and || directly or write corresponding
> sequences of if conditions. In general we want to move away from
> optimizing complicated expressions in fold-const, towards having GIMPLE
>
On Thu, 22 Aug 2013, Alan Modra wrote:
> For multiarch, powerpc64le-linux now will use powerpc64le-linux-gnu.
> Given a typical big-endian native toolchain with os dirs /lib and
> /lib64, we'll use /lible and /lib64le if supporting little-endian as
> well. If you happen to use /lib and /lib32, th
On Thu, 22 Aug 2013, Selvaraj, Senthil_Kumar wrote:
> 2013-08-23 Senthil Kumar Selvaraj
> * c-typeck.c (output_pending_init_elements): Handle overflow of
> constructor_unfilled_index.
This patch needs to add include a testcase to the testsuite that fails
before and passes after th
On Fri, 23 Aug 2013, Alan Modra wrote:
> I'd like to import upstream libtool into gcc to support powerpc64le,
Has the sysroot semantics issue been resolved in upstream libtool, or do
you mean "import with 3334f7ed5851ef1e96b052f2984c4acdbf39e20c reverted"?
--
Joseph S. Myers
jos...@codesourcer
On Fri, 23 Aug 2013, nick clifton wrote:
> Hi Joseph,
> > Your patch itself makes sense on general principles, but the concept of an
> > AVR Linux target doesn't - this is an 8-bit processor Really, the bug
> > you've found is that there's an avr-*-* case that is too general, matching
> > non
On Fri, 23 Aug 2013, Zoran Jovanovic wrote:
> New test case involving unions is added.
Tests for unions should include *execution* tests that the relevant bits
have the right values after the sequence of assignments.
--
Joseph S. Myers
jos...@codesourcery.com
On Thu, 8 Aug 2013, Joseph S. Myers wrote:
On Fri, 26 Jul 2013, Marc Glisse wrote:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57324
(that is using llvm's sanitizer)
and for a first patch (unreviewed):
http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01466.html
(started at http://gcc.gnu.org/ml/
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
>> /* Negate THIS. */
>> inline wide_int_ro
>> wide_int_ro::operator - () const
>> {
>> wide_int_ro r;
>> r = wide_int_ro (0) - *this;
>> return r;
>> }
>>
>> /* Negate THIS. */
>> inline wide_int_ro
>> wide_int_ro::neg () const
>> {
>>
The primary function of this patch is to formally make the class
pretty_printer polymorphic (in the OO sense.) It has always been
conceptually polymorphic -- we just didn't have linguistic support to
say so in C. As a secondary change, the patch makes a systematic use of
pp_buffer -- making it e
On Aug 22, 2013, at 7:16 PM, Gabriel Dos Reis
wrote:
>>> My reasoning (for C++98, but the same is true for C++11) is based
>>> on 3.8/1:
>>> […]
>>> The lifetime of an object of type T ends when:
>>> -- if T is a class type with a non-trivial destructor (12.4),
>>> the destructor call st
2013/8/20 Tom Tromey :
> This converts Go.
>
> It renames gospec.o to go/gospec.o, for uniformity and so we can
> remove an explicit rule.
>
> It defines go_OBJS, to conform to the documented Make-lang.in
> conventions, and to ensure that Go objects are given the correct
> order-only dependencies o
Hi,
On 08/23/2013 05:12 PM, Jan Hubicka wrote:
+/* { dg-final { scan-tree-dump-nop "A::foo" 0 "ssa"} } */
This should be scan-tree-dump-not right?
Paolo.
On Fri, Aug 23, 2013 at 7:32 PM, Mike Stump wrote:
> On Aug 22, 2013, at 7:16 PM, Gabriel Dos Reis
> wrote:
>> But even so, in light of this, I don't think you original assertion is
>> definitive.
>
> Nothing is ever definitive. Now, if you want to say I quoted something
> wrong, or that I a
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
>> #define addr_max_bitsize (64)
>> #define addr_max_precision \
>
> These should either be lower-case C++ constants or upper-case macros.
Fixed:
diff --git a/gcc/wide-int.h b/gcc/wide-int.h
index 9ccdf7c..b40962c 100644
--- a/gcc/wide-int.
On Aug 23, 2013, at 8:02 AM, Richard Sandiford
wrote:
>> * When a constant that has an integer type is converted to a
>>wide-int it comes in with precision 0. For these constants the
>>top bit does accurately reflect the sign of that constant; this
>>is an exception to the normal ru
On Aug 23, 2013, at 5:53 PM, Gabriel Dos Reis
wrote:
> If you quoted the standard to back up your assertions, I would have been
> able to "feel free to point this out" :-)
>
> The thing is I am still trying to figure out what (1) what you would have
> liked;
I've directly stated it, not sure h
On Fri, Aug 23, 2013 at 10:34 PM, Mike Stump wrote:
> On Aug 23, 2013, at 5:53 PM, Gabriel Dos Reis
> wrote:
>> If you quoted the standard to back up your assertions, I would have been
>> able to "feel free to point this out" :-)
>>
>> The thing is I am still trying to figure out what (1) what y
I was looking at a performance issue with some jump threading
improvements when I had to dig through the PRE dumps.
PRE notes when it finds fully redundant expressions, but fails to
actually include fully redundant expression in a textual form in the
debugging dump.
ie, before my patch PRE
On 08/23/2013 01:52 PM, DJ Delorie wrote:
so... can I get an official "ok to commit with you and Nick as maintainers"
then?
Just need to clear it with the steering committee, which for this sort
of thing has been pretty trivial. Basically it has to pass the
technical review (which y'all have
On Sat, Aug 24, 2013 at 1:51 AM, Stefan Schweter wrote:
> Am Fri, 23 Aug 2013 17:17:41 +0800
> schrieb Tim Shen :
>
>> Inspired by this mail:
>> http://gcc.gnu.org/ml/libstdc++/2013-08/msg00131.html
>>
>> Thanks!
>>
>>
>
> Hi Tim,
>
> I applied the patch + compiled everything - it's working now! T
On 08/23/2013 10:51 AM, Jan Hubicka wrote:
Sadly we ICE here because BINFO of type is not built yet.
I tried to move the code after xref_binfos and it does seem to lead to errors
while building libstdc++ PCH. Any idea what to do here?
If it's causing trouble, let's just put the flag on the typ
80 matches
Mail list logo
