On 03/15/2011 10:37 PM, Jeff Law wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
I noticed that VRP was missing many obvious jump threading
opportunities; investigation showed that it wasn't threading through
conditionals with pointer types, just those with integral types.
Fix is rather
On 03/16/2011 12:12 AM, Kenneth Zadeck wrote:
so how much time does this save?
I agree that this is a useful simplification, but it seems unlikely to
be that important in real code.
it seems like the 5000 store test would in general provide a better
safety valve.
I think having both is a good
Tom Tromey writes:
> I would like to ask that it be considered for 4.6.
>
> IIRC, if this patch does not go in 4.6, then we have to write some
> special and ugly GDB code to work around the debuginfo generated by 4.6.
> I would much prefer it if there was no need to write this code.
I see. I wa
Richard Guenther writes:
>> Ok for mainline if that passes, and perhaps also the 4.6 branch?
>
> I'm ok with this for mainline - Paolo, can you double-check the
> autofoo stuff? As for 4.6 I'd like to give it a day or two on
> trunk to allow people to report problems.
Paolo, do you have any com
On 03/16/2011 10:23 AM, Rainer Orth wrote:
> I'm ok with this for mainline - Paolo, can you double-check the
> autofoo stuff? As for 4.6 I'd like to give it a day or two on
> trunk to allow people to report problems.
Paolo, do you have any comments on the configure.ac part of the patch?
It
On Tue, 15 Mar 2011, Andrew Pinski wrote:
> On Tue, Mar 15, 2011 at 5:19 AM, Richard Guenther wrote:
> >
> > This avoids spilling SSE registers to memory just because we access
> > vector components in a C array way. The trick is to simply rewrite
> > those accesses to proper vector selects on t
Paolo Bonzini writes:
>> Paolo, do you have any comments on the configure.ac part of the patch?
>
> It's okay.
Thanks, installed on mainline then.
> I hope Binutils will never switch to 3.x, but that's not your fault.
True: although there are some precautions for binutils > 2, I doubt they
are
On Tue, Mar 15, 2011 at 8:41 PM, Jakub Jelinek wrote:
> Hi!
>
> The addition of STRIP_NOPS for EQ_EXPR/NE_EXPR revealed a bunch of cases
> which rely on arg0 and arg1 having the same type. Only the last hunk
> fixes the testcase, the rest is what I saw and it was possible the
> types wouldn't mat
On Tue, Mar 15, 2011 at 9:07 PM, Pat Haugen wrote:
> The following changes are already present on trunk as part of the fix for
> PR44364. Not having them on 4.5 caused problems with the subject fix when
> trying to spill FP regs with a stack > 32K.
>
> Bootstrap/regtest 4.5 branch on powerpc with
Jakub Jelinek writes:
> + {
> + int nargs = list_length (TYPE_ARG_TYPES (type));
> + link = CALL_INSN_FUNCTION_USAGE (insn);
../../gcc/var-tracking.c: In function 'prepare_call_arguments':
../../gcc/var-tracking.c:5623:12: error: unused variable 'nargs'
[-Werror=unus
On Wed, Mar 16, 2011 at 11:11:07AM +0100, Andreas Schwab wrote:
> Jakub Jelinek writes:
>
> > + {
> > + int nargs = list_length (TYPE_ARG_TYPES (type));
> > + link = CALL_INSN_FUNCTION_USAGE (insn);
>
> ../../gcc/var-tracking.c: In function 'prepare_call_arguments':
> ../..
On Mon, 14 Mar 2011, Benjamin Kosnik wrote:
I hacked up scripts/check_compile and ran the libstdc++ testsuite to
generate 4k+ .s files, and then analyzed the resulting assembly files
for vague linkage.
Here are the clear wins that are ABI-compatible, or in C++0x code. There
are other issues, li
On Wed, Mar 16, 2011 at 7:49 AM, Ira Rosen wrote:
> Hi,
>
> This patch adds a support of conditional store sinking for cases with
> multiple data references in then and else basic blocks. The
> correctness of the transformation is checked by verifying that there
> are no read-after-write and write
Richard Henderson schrieb:
> On 03/11/2011 05:43 AM, Georg-Johann Lay wrote:
>> I did not find a way to make this work together with -mcall-prologues.
>> Please let me know if you have suggestion on how call prologues can be
>> combine with tail calls.
>
> You need a new symbol in libgcc for this.
On Tue, Mar 15, 2011 at 10:37 PM, Jeff Law wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
>
> I noticed that VRP was missing many obvious jump threading
> opportunities; investigation showed that it wasn't threading through
> conditionals with pointer types, just those with integral
Thanks. I don't have write privileges. If no-one objects, can someone apply
the patch to trunk/appropriate branches?
2011-03-16 Stuart Henderson
PR target/47951
* config/bfin/bfin.md (loop_end): Update constraints to ensure inputs match
output.
-Original Message-
From: Bernd Schmi
This prepares things to share constant folding between passes
(CCP, FRE and VRP). It simplifies maybe_fold_reference making
sure to first canonicalize MEM_REFs and then call other folders.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-03-16 Richard Guent
On 16 March 2011 12:29, Richard Guenther wrote:
> On Wed, Mar 16, 2011 at 7:49 AM, Ira Rosen wrote:
>> Hi,
>>
>> This patch adds a support of conditional store sinking for cases with
>> multiple data references in then and else basic blocks. The
>> correctness of the transformation is checked by
Hi Guys,
I am checking in the attached patch to fix some regressions in the RX
port with regard to alignment and addressing modes. With this patch
applied I have 18 fewer failures in the GCC testsuite.
Cheers
Nick
gcc/ChangeLog
2011-03-16 Nick Clifton
* config/rx/rx.h (JUMP_
On Wed, Mar 16, 2011 at 09:46:20AM +0100, Paolo Bonzini wrote:
> On 03/16/2011 12:12 AM, Kenneth Zadeck wrote:
> >so how much time does this save?
> >
> >I agree that this is a useful simplification, but it seems unlikely to
> >be that important in real code.
> >it seems like the 5000 store test wo
On Wed, Mar 16, 2011 at 12:52 PM, Jakub Jelinek wrote:
> On Wed, Mar 16, 2011 at 09:46:20AM +0100, Paolo Bonzini wrote:
>> On 03/16/2011 12:12 AM, Kenneth Zadeck wrote:
>> >so how much time does this save?
>> >
>> >I agree that this is a useful simplification, but it seems unlikely to
>> >be that
On 03/16/2011 12:59 PM, Richard Guenther wrote:
On Wed, Mar 16, 2011 at 12:52 PM, Jakub Jelinek wrote:
On Wed, Mar 16, 2011 at 09:46:20AM +0100, Paolo Bonzini wrote:
On 03/16/2011 12:12 AM, Kenneth Zadeck wrote:
so how much time does this save?
I agree that this is a useful simplification, b
My fixing of store-sinking exposed an issue that relying on SSA
update to fixup virtual operands isn't a good idea if we incrementally
walk through all sinking candidates. Fixed by manually updating virtual
SSA form which is easy in this case.
Bootstrapped and tested on x86_64-unknown-linux-gnu,
H Jakub,
I think some of your DWARF patches caused:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48147
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48148
--
H.J.
On Wed, Mar 16, 2011 at 01:19:30PM +0100, Paolo Bonzini wrote:
> Jakub's behavior is expected, since the number of active local
> stores should be 1 with the earlier patch in that testcase.
> However, similar artificial testcases can probably be constructed
> that still trigger the ill behavior.
N
i think that i sympathize with richard's "do we really need another
parm?" whine. I would have just nailed it in without the parm. I
think that it is unreasonable to expect that a program with basic blocks
this big needs the full range of optimizations performed.
It is perfectly reasonable
On Wed, Mar 16, 2011 at 2:27 PM, Kenneth Zadeck
wrote:
> i think that i sympathize with richard's "do we really need another parm?"
> whine. I would have just nailed it in without the parm. I think that it
> is unreasonable to expect that a program with basic blocks this big needs
> the full ra
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/16/11 04:31, Richard Guenther wrote:
> On Tue, Mar 15, 2011 at 10:37 PM, Jeff Law wrote:
>
>
> I noticed that VRP was missing many obvious jump threading
> opportunities; investigation showed that it wasn't threading through
> conditionals wit
This makes sure we also rewrite complex variables into SSA form if
we extract components via pointer-to-elements.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-03-16 Richard Guenther
PR tree-optimization/26134
* tree-ssa.c (maybe_rewrit
-flto with using the linker-plugin has an implicit -fwhole-program
effect which brings foo local and allows IPA-SRA to remove the
constant parameter. The testcase does not want this and breaks
even without -flto if you make foo static.
Thus the following patch makes sure this doens't happen with
The assembler bug in Xcode 3.2.6/4.0 only impacts darwin10, so lto can
be renabled for darwin9 (for which it has been well tested on the regress
server). Re-enabling lto for *-apple-darwin9 on darwin allows us to
continue to monitor the status of darwin lto support while the containerized
lto cha
On Wed, 16 Mar 2011, Jack Howarth wrote:
> The assembler bug in Xcode 3.2.6/4.0 only impacts darwin10, so lto can
> be renabled for darwin9 (for which it has been well tested on the regress
> server). Re-enabling lto for *-apple-darwin9 on darwin allows us to
> continue to monitor the status of
Hi,
this patch adds slightly more simplification in try_combine(), under
-fexpensive-optimizations, by calling subst() to both i2 and i1.
Supplied is an ARM testcase where this resulted in one less redundant
ZERO_EXTEND insn under ARMv6 and above.
Bootstrapped and tested on i686 and x86_64, cross-
Hi All,
This problem optimize rule missing.
gen_lowpart got invalid operand.
I attached fix patch.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index ca9398c..9982644 100644
--- a/gcc/ChangeLog
+++ b/gcc/ChangeLog
@@ -1,3 +1,9 @@
+2011-03-16 Yoshinori Sato
+
+ PR/target 47998
+ * con
On Wed, Mar 16, 2011 at 03:50:20PM +0100, Richard Guenther wrote:
> On Wed, 16 Mar 2011, Jack Howarth wrote:
>
> > The assembler bug in Xcode 3.2.6/4.0 only impacts darwin10, so lto can
> > be renabled for darwin9 (for which it has been well tested on the regress
> > server). Re-enabling lto for
On 03/16/2011 03:32 AM, Georg-Johann Lay wrote:
> Richard Henderson schrieb:
>> On 03/11/2011 05:43 AM, Georg-Johann Lay wrote:
>>> I did not find a way to make this work together with -mcall-prologues.
>>> Please let me know if you have suggestion on how call prologues can be
>>> combine with tail
> Out of curiosity, did you update these manually, or did you run
> autoupdate on the files?
Thanks for the review. I updated manually, didn't know there was such a thing
as autoupdate!
FX
This fixes the easiest case in PR48149 by extending fold to handle
COMPLEX_EXPR , IMAGPART_EXPR >. We have to
be careful when the types do not match as fold-convert happily
re-constructs a COMPLEX_EXPR of this kind when folding a complex-expr
to a slightly different type.
Bootstrapped and teste
On Wed, Mar 16, 2011 at 4:34 AM, Richard Guenther wrote:
>
> This prepares things to share constant folding between passes
> (CCP, FRE and VRP). It simplifies maybe_fold_reference making
> sure to first canonicalize MEM_REFs and then call other folders.
>
> Bootstrapped and tested on x86_64-unkno
> Could that be related to the fact that I now keep getting linker
> errors about std::range_error::~range_error() being undefined?
> The .o file is looking for _ZNSt11range_errorD2Ev but libstdc++ has
> D0Ev and D1Ev.
Indeed. Fixed thusly.
tested x86/linux
-benjamin
2011-03-16 Benjamin Kosn
This patch is OK. I also think it's a bug that the constructors of the
anonymous struct have 't' in their names; they should also be anonymous
with DW_AT_linkage_name.
Jason
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/16/11 09:32, Yoshinori Sato wrote:
> Hi All,
>
> This problem optimize rule missing.
> gen_lowpart got invalid operand.
>
> I attached fix patch.
>
> diff --git a/gcc/ChangeLog b/gcc/ChangeLog
> index ca9398c..9982644 100644
> --- a/gcc/Change
In templates, we do overload resolution and then throw away most of it,
going back to the pre-conversion arguments. But when the call returns a
reference, we shouldn't elide the dereference and pretend it returns by
value, as that confuses lvalue_p.
Tested x86_64-pc-linux-gnu, applying to tru
With -fwhole-program (or -flto) f1 gets promoted to const and the
call to it is optimized away. The following avoids this by
making use of its return value.
Tested on x86_64-unknown-linux-gnu with and without -fwhole-program,
applied.
Richard.
2011-03-16 Richard Guenther
* gcc.dg/g
On 03/16/2011 08:01 AM, Chung-Lin Tang wrote:
> * combine.c (try_combine): Do simplification only call of
> subst() on i2 even when i1 is present. Update comments.
>
> testsuite/
> * gcc.target/arm/unsigned-extend-1.c: New testcase.
Ok.
r~
Hi,
expand_function_start failed to properly store frame pointer for
non-local goto when Pmode != ptr_mode. OK for trunk?
Thanks.
H.J.
---
diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
index 3405300..52ff01d 100644
--- a/gcc/ChangeLog.x32
+++ b/gcc/ChangeLog.x32
@@ -1,3 +1,9 @@
+2011-03-1
Conversion of default arguments is an implicit conversion, so it should
use LOOKUP_IMPLICIT.
A recent bug involved cp_parser_abort_tentative_parse failing to abort
because we had already committed to the tentative parse. So let's avoid
that in future.
Tested x86_64-pc-linux-gnu, applied to
On 03/16/2011 04:48 AM, Nick Clifton wrote:
> (peephole): Add peephole to combine zero- and sign- extending
> loads with arithmetic instructions.
Do you really need peepholes for this? I would have thought that
merely adding the instruction patterns for this would have been
enough to
On Wed, Mar 16, 2011 at 10:09:44AM -0700, H.J. Lu wrote:
> Hi,
>
> expand_function_start failed to properly store frame pointer for
> non-local goto when Pmode != ptr_mode. OK for trunk?
Wrong patch. Here is the correct mode. OK for trunk?
Thanks.
H.J.
---
diff --git a/gcc/ChangeLog.x32 b/
This patch fixes PR c/48116.
The bug is that -Wreturn-type does not follow the documentation. In
particular, it should warn for this code, but does not:
static void f() {}
static void g() { return f(); }
I think the bug is that c-typeck.c calls pedwarn with either 0 or
OPT_pedantic, but
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/16/11 04:31, Richard Guenther wrote:
> On Tue, Mar 15, 2011 at 10:37 PM, Jeff Law wrote:
>
>
> I noticed that VRP was missing many obvious jump threading
> opportunities; investigation showed that it wasn't threading through
> conditionals wit
On Wed, Mar 16, 2011 at 11:18:04AM -0600, Tom Tromey wrote:
> This patch fixes PR c/48116.
>
> The bug is that -Wreturn-type does not follow the documentation. In
> particular, it should warn for this code, but does not:
>
> static void f() {}
> static void g() { return f(); }
>
> I thi
Hi Richard,
Do you really need peepholes for this? I would have thought that
merely adding the instruction patterns for this would have been
enough to encourage combine to do its job merging these patterns...
I thought so too, but I found in my tests that combine was missing
plenty of cases
On 03/11/2011 06:14 AM, Chung-Lin Tang wrote:
> + /* Given (xor (and A B) C), using P^Q == ~PQ | ~QP (concat as AND),
> + we can transform (AB)^C into:
> + A(~CB) | ~AC | ~BC
> + Attempt a few simplifications when B and C are both constants. */
I do
On Mar 16, 2011, at 7:49 AM, Jack Howarth wrote:
> The assembler bug in Xcode 3.2.6/4.0 only impacts darwin10, so lto can
> be renabled for darwin9
> Okay for gcc trunk and 4.6.0?
Ok. I've now applied the patch to trunk and 4.6.x, thanks.
On Sun, Feb 27, 2011 at 5:45 AM, Uros Bizjak wrote:
> Hello!
>
> Attached [RFC] patch vectorizes calls to floor, ceil, trunc and rint
> (and their float variants) functions using roundps/roundpd SSE4.1
> instruction.
>
> 2011-02-27 Uros Bizjak
>
> * config/i386/i386.md (ROUND_FLOOR): New
On Wed, Mar 16, 2011 at 11:38 AM, H.J. Lu wrote:
> On Sun, Feb 27, 2011 at 5:45 AM, Uros Bizjak wrote:
>> Hello!
>>
>> Attached [RFC] patch vectorizes calls to floor, ceil, trunc and rint
>> (and their float variants) functions using roundps/roundpd SSE4.1
>> instruction.
>>
>> 2011-02-27 Uros B
Richard Henderson schrieb:
On 03/16/2011 03:32 AM, Georg-Johann Lay wrote:
Richard Henderson schrieb:
On 03/11/2011 05:43 AM, Georg-Johann Lay wrote:
I did not find a way to make this work together with -mcall-prologues.
Please let me know if you have suggestion on how call prologues can be
On Wed, Mar 16, 2011 at 4:48 AM, Nick Clifton wrote:
> Hi Guys,
>
> I am checking in the attached patch to fix some regressions in the RX
> port with regard to alignment and addressing modes. With this patch
> applied I have 18 fewer failures in the GCC testsuite.
> + (set_attr "length" "5
On Wed, Mar 16, 2011 at 7:56 PM, H.J. Lu wrote:
>>> Attached [RFC] patch vectorizes calls to floor, ceil, trunc and rint
>>> (and their float variants) functions using roundps/roundpd SSE4.1
>>> instruction.
>>>
>>> 2011-02-27 Uros Bizjak
>>>
>>> * config/i386/i386.md (ROUND_FLOOR): New
convert_for_initialization is sfinae-enabled, but it was calling
ocp_convert, which is not. This patch changes it to use the newer
perform_implicit_conversion_flags instead. To make that work, I needed
to add support for LOOKUP_PREFER_RVALUE to that code path.
Tested x86_64-pc-linux-gnu, app
Here the issue was that require_complete_type doesn't do anything in
templates, but convert_arg_to_ellipsis was assuming that it did. The
simple fix is to make sure we really do have a complete type.
Tested x86_64-pc-linux-gnu, applying to trunk. Also OK for 4.6? The
patch seems extremely s
Hello,
This PR is an enhancement request to emit a DW_TAG_ptr_to_member_type
DIE for pointer-to-member-function types.
The patch below does add a new language hook to support this and
adapts the existing code that emits DW_TAG_ptr_to_member_type for
ponter-to-data-member types to handle pointer-t
On Wed, Mar 16, 2011 at 03:54:45PM -0400, Jason Merrill wrote:
> Here the issue was that require_complete_type doesn't do anything in
> templates, but convert_arg_to_ellipsis was assuming that it did.
> The simple fix is to make sure we really do have a complete type.
>
> Tested x86_64-pc-linux-gn
Tom> This patch fixes PR c/48116.
Tom> The bug is that -Wreturn-type does not follow the documentation. In
Tom> particular, it should warn for this code, but does not:
Tom> static void f() {}
Tom> static void g() { return f(); }
Tom> I think the bug is that c-typeck.c calls pedwarn with either
Jakub was right that we were failing to add indices to the array
CONSTRUCTOR along this code path. It seems appropriate to add them
earlier, in reshape_init, like we do for classes, so this patch fixes
the bug that way.
Tested x86_64-pc-linux-gnu, applying to trunk. Also OK for 4.6.0? The
Jason Merrill writes:
> This patch is OK.
Thank you.
Would the RMs (in CC) object to this patch going into 4.6?
> I also think it's a bug that the constructors of the anonymous struct
> have 't' in their names; they should also be anonymous with
> DW_AT_linkage_name.
I think this makes sense.
One more: I noticed that we were calling require_complete_type within
template-specific code, but in a template require_complete_type just
returns immediately.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 453649bdbc1189503b34774d5a6cf2470a6bcd12
Author: Jason Merrill
Date: Wed Mar
The resolution of core issue 1148 clarifies that even though it isn't
safe to elide the copy from a function parameter to its return value, we
can change it to a move.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 3122c2fd2d08a4ac78c2954dda8330e59295e23f
Author: Jason Merrill
Date: We
On Mar 16, 2011, at 10:12 AM, Richard Henderson wrote:
> On 03/16/2011 04:48 AM, Nick Clifton wrote:
>> (peephole): Add peephole to combine zero- and sign- extending
>> loads with arithmetic instructions.
>
> Do you really need peepholes for this? I would have thought that
> merely addi
On Mar 16, 2011, at 12:05 PM, Andrew Pinski wrote:
>> + (set_attr "length" "5")] ;; Worst case sceanario. FIXME: If we defined
>> separate patterns
>> +);; rather than using iterators we could
>> specify exact sizes.
>
> You can set up the correct length even with
Hi,
>
> Also OK for 4.6.0? The risk is that swapping to
> perform_implicit_conversion_flags will have other differences of behavior,
> but the library regression seems pretty major, so I think it's worth the risk.
Thanks Jason. Indeed, I agree that the library issue is pretty serious. If you
Am 15.03.2011 23:42, schrieb Mikael Morin:
On second thought, maybe you're right; the speed-up / likeliness-to-break
ratio doesn't look so interesting after all, and selecting only
pure/implicitely pure functions for optimization would get rid of the weird
cases without (hopefully) being too res
Hello.
This patch removes obsolete LIBCALL_VALUE and FUNCTION_VALUE_REGNO_P macros
from AVR back end in the GCC and introduces equivalent TARGET_LIBCALL_VALUE
and TARGET_FUNCTION_VALUE_REGNO_P target hooks.
* config/avr/avr.h (RET_REGISTER, LIBCALL_VALUE,
FUNCTION_VALUE_REGNO_
Hello.
On 12/08/10 11:46, Anatoly Sokolov wrote:
Hi.
This patch converts loops of bitmap_set_bit/bitmap_clear_bit in to
bitmap_set_range/bitmap_clear_range functions call.
The patch has been bootstrapped on and regression tested on
x86_64-unknown-linux-gnu for c.
OK to install?
> If M$ mktemp when already 26 files exist with the same prefix at least
> properly fails, then it would be better to just retry with a changed prefix
> if it fails.
Done exactly that. Manually tested on i586-pc-mingw32, regtested on
x86_64-linux by editing config.h to fake the absence of mkstem
Anatoly Sokolov schrieb:
/* Returns register number for function return value.*/
-int
+static inline int
avr_ret_register (void)
{
return 24;
}
I always wondered why that works.
SI is returned in r22..r25 (not in r24..27)
DI is returnet in r18..r25 (not in r24..31)
So according to
Hello.
This patch removes obsolete OUTPUT_ADDR_CONST_EXTRA macro from V850 back
end in the GCC and introduces equivalent TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA
target hook.
Regression-tested on v850-unknown-elf.
OK to install?
* config/v850/v850.h (OUTPUT_ADDR_CONST_EXTRA): Remo
On Tue, Mar 15, 2011 at 4:19 AM, Jakub Jelinek wrote:
> Hi!
>
> Now that we are back in stage 1, I'd like move on with the
> entry_value/call_site debug info extensions.
>
> Here is the http://gcc.gnu.org/ml/gcc-patches/2010-12/msg01793.html
> patch updated to current trunk, bootstrapped/regtested
I committed a patch to upgrade to revision 94d654be2064 of the Go
library. That is the library sources as of about 2 weeks ago as I
delayed the commit for the 4.6 branch. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline.
The patch is too large to attach to th
Hi!
Bootstrap currently fails on mingw, because
targetm.calls.function_arg_advance has various asserts and doesn't
like being passed parameters that should have been passed by reference.
prepare_call_arguments code just tried to match up what types
arguments have and if there is no match, just giv
This patch to libgo changes the Go signal handling code to not try to
handle SIGPROF. This lets the usual -pg profiler work. Except that it
doesn't fully work with -fsplit-stack, but that is a separate issue.
Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline.
I
Hi!
As usually, Apple dwarf tools crash when seeing the new extensions
and I forgot to guard all their output with !dwarf_strict (if it is accepted
for DWARF 5 it will of course be changed into
dwarf_version >= 5 || !dwarf_strict).
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-lin
Hi,
The attached patch replace sreal math with mpfr math in predict.c and
host double math in mcf.c also with mpfr math.
Bootstrapped&tested (incl. ada) on x86_64-unknown-linux-gnu. OK for trunk?
Anyone a better suggestion for PRED_PRECISION?
Ciao!
Steven
* sreal.c: Remove file.
On Wed, Mar 16, 2011 at 03:38:25PM -0700, H.J. Lu wrote:
IMNSHO you really should reconsider using Pmode != ptr_mode for your port.
That said, the patch looks good to me, though I can't approve it.
> diff --git a/gcc/ChangeLog.x32 b/gcc/ChangeLog.x32
> index 764e3de..45db256 100644
> --- a/gcc/C
Hi!
Currently expand_debug_expr doesn't always guarantee canonical
MEM_EXPRs, if MEM_EXPR isn't canonical, sometimes aliasing code ICEs on it
(since recent Richard's change fortunately only if --enable-checking=yes).
The following patch canonicalizes those using fold and if canonicalization
isn't
On 3/16/2011 1:04 PM, Dodji Seketeli wrote:
> Would the RMs (in CC) object to this patch going into 4.6?
What would be the justification for that? The bar is pretty high on
putting a patch onto a release branch.
I don't see any evidence that this is a regression, and a bug that
affects debuggin
On Wed, Mar 16, 2011 at 4:28 PM, Jakub Jelinek wrote:
> On Wed, Mar 16, 2011 at 03:38:25PM -0700, H.J. Lu wrote:
>
> IMNSHO you really should reconsider using Pmode != ptr_mode for your port.
Someone can give it a try.
My main concern is the x32 process is running in 64bit mode. Its
stack opera
On 2011/3/17 03:21 AM, Richard Henderson wrote:
> On 03/11/2011 06:14 AM, Chung-Lin Tang wrote:
>> + /* Given (xor (and A B) C), using P^Q == ~PQ | ~QP (concat as AND),
>> + we can transform (AB)^C into:
>> + A(~CB) | ~AC | ~BC
>> + Attempt a few simpli
In this case, fold is turning one() >= 0 into (one(), true) because the
comparison is always true because one() returns unsigned, and we were
handling COMPOUND_EXPR like any other binary expression, expecting fold
to turn (1, 1) into 1. But it doesn't, and it makes sense to handle
COMPOUND_EXP
Here after we complained about the extern "C" we continued to try and
merge the two definitions even though for a simple redefinition we give
up. In this case it seems to make most sense to treat the two functions
as different since they have different signatures; they just clash
because both
The code for backwards-compatibility with ABI v1 didn't do too well with
the case of a literal class used as an array bound; it built up an
integral MINUS_EXPR with it directly, which doesn't make much sense.
But since 3.2 didn't support constexpr, we can just disable the v1
semantics when we a
In a normal constexpr function, we treat *this as a potential constant
expression. But in a constexpr constructor it isn't, since we're still
in the process of initializing the object.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 0f23f8a6fca94b1a00a51ea34643268e9ff840e9
Author: Jason
On Wed, Mar 16, 2011 at 9:32 PM, Jason Merrill wrote:
> In a normal constexpr function, we treat *this as a potential constant
> expression. But in a constexpr constructor it isn't, since we're still in
> the process of initializing the object.
Hi Jason,
I believe the patch is too strong, or am
On 03/16/2011 10:43 PM, Gabriel Dos Reis wrote:
The real problem is that the data member of the object is not initialized.
Fully constructed subobjects in constexpr constructor are still
be potential constant expressions.
For example, we should not reject
struct S {
int i;
On Wed, Mar 16, 2011 at 10:02 PM, Jason Merrill wrote:
> On 03/16/2011 10:43 PM, Gabriel Dos Reis wrote:
>>
>> The real problem is that the data member of the object is not initialized.
>> Fully constructed subobjects in constexpr constructor are still
>> be potential constant expressions.
>> For
On Wed, Mar 16, 2011 at 9:23 AM, Jason Merrill wrote:
> In templates, we do overload resolution and then throw away most of it,
> going back to the pre-conversion arguments. But when the call returns a
> reference, we shouldn't elide the dereference and pretend it returns by
> value, as that conf
Signed-off-by: Mike Frysinger
---
libdecnumber/.gitignore |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
create mode 100644 libdecnumber/.gitignore
diff --git a/libdecnumber/.gitignore b/libdecnumber/.gitignore
new file mode 100644
index 000..7e47161
--- /dev/null
+++ b/libdecnu
Needs some more work, here's a rough draft.
-benjaminIndex: htdocs/gcc-4.6/porting_to.html
===
RCS file: htdocs/gcc-4.6/porting_to.html
diff -N htdocs/gcc-4.6/porting_to.html
*** /dev/null 1 Jan 1970 00:00:00 -
--- htdocs/gcc-4.6
99 matches
Mail list logo
