On Mon, Oct 17, 2011 at 8:23 AM, Razya Ladelsky wrote:
> This patch fixes the failures described in
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49960
> It also fixes bzips when run with autopar enabled.
>
> In both cases the self dependences are not handled correctly.
> In the first case, a non
On Oct 14, 2011, at 4:02 PM, Tom Tromey wrote:
>> "Tristan" == Tristan Gingold writes:
>
> Tristan> I am not against this patch, my only concern is that there are many
> Tristan> many dwarf consumers and I have no idea how they will react to this
> Tristan> change.
>
> I tend to think that
On 28 September 2011 09:48, Joey Ye wrote:
> 2011-09-28 Joey Ye
>
> * gcc.target/arm/pr42575.c: Remove architecture option.
OK.
FTR - Joey had checked that it ran ok with an optional march=armv5te
in RUNTESTFLAGS .
Ramana
Jason Merrill writes:
> On 10/13/2011 01:12 PM, Dodji Seketeli wrote:
>> + while (true)
>> +{
>> + if (!linemap_macro_expansion_map_p (map0)
>> + || !linemap_macro_expansion_map_p (map1)
>> + || map0 == map1)
>> + break;
>
> I'd put the test in the condition, but i
Hi,
With Jakub's patch for bool types the 3 loops in gcc.dg/vect/vect-21.c
are now vectorizable on targets that support vector conditions.
Tested on powerpc64-suse-linux.
Committed.
Ira
testsuite/ChangeLog:
* gcc.dg/vect/vect-21.c: Expect the loops to get vectorized on
targets that suppo
> (I don't have svn write access so I'll need someone else to commit it if
> it's approved.)
I can apply it for you. But ... do you have a copyright assignment in place
for contributions to GCC ? The patch looks small and trivial enough that
I think I can apply it without a signed copyright assi
FWIW, I still believe that tweaking the documentation to match the long
standing reality, would be a small improvement. I'm not going to further
insist, anyway.
Paolo.
This set of patches to track locations of tokens access macro
expansion was reviewed and accepted at
http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01346.html.
I have bootstrapped and tested it on x86_64-unknown-linux-gnu against
trunk and I am checking it in now.
Thanks.
In this third instalment the diagnostic machinery -- when faced with
the virtual location of a token resulting from macro expansion -- uses
the new linemap APIs to unwind the stack of macro expansions that led
to that token and emits a [hopefully] more useful message than what we
have today.
diagn
This patch adds -fdebug-cpp option. When used with -E this dumps the
relevant macro map before every single token. This clutters the output
a lot but has proved to be invaluable in tracking some bugs during the
development of the virtual location support.
gcc/ChangeLog
2011-10-15 Tom Tromey
This patch basically arranges for the allocation size of line_map
buffers to be as close as possible to a power of two. This
*significantly* decreases peak memory consumption as (macro) maps are
numerous and stay live during all the compilation.
The patch adds a new ggc_round_alloc_size interface
This patch adds statistics about line maps' memory consumption and
macro expansion to the output of -fmem-report. It has been useful in
trying to reduce the memory consumption of the macro maps support.
gcc/ChangeLog
2011-10-15 Tom Tromey
Dodji Seketeli
* input.c (ONE_K
On 10/16/2011 09:38 PM, Steve Kargl wrote:
The attach patch fixes the construction of a format string
from a user-defined operator or from a string with a kind
type prefix.
OK. Thanks for the patch.
Tobias
2011-10-16 Steven G. Kargl
* io.c (match_dt_format): Match a user-defined op
On 10/15/11 16:21, Eric Botcazou wrote:
> so the correct fix is very likely something like:
>
> Index: cfgrtl.c
> ===
> --- cfgrtl.c(revision 179844)
> +++ cfgrtl.c(working copy)
> @@ -1024,13 +1024,20 @@ patch_jump_insn (rtx
On 10/15/2011 11:21 PM, Steve Kargl wrote:
OK for trunk?
2011-10-15 Steven G. Kargl
* gfortran.dg/ishft_3.f90: Update test.
I am not so happy with complete test replacements. How about adding it
as new test case?
2011-10-15 Steven G. Kargl
* check.c (less_than_bitsize
On Mon, Oct 17, 2011 at 11:42 AM, Paolo Carlini
wrote:
> FWIW, I still believe that tweaking the documentation to match the long
> standing reality, would be a small improvement. I'm not going to further
> insist, anyway.
The original patch is ok.
Thanks,
Richard.
> Paolo.
>
On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini wrote:
> FWIW, I still believe that tweaking the documentation to match the long
> standing reality, would be a small improvement. I'm not going to further
> insist, anyway.
It isn't improvement.
The improvement would be to restore the documented def
On Mon, Oct 17, 2011 at 5:25 AM, Richard Guenther
wrote:
> On Mon, Oct 17, 2011 at 11:42 AM, Paolo Carlini
> wrote:
>> FWIW, I still believe that tweaking the documentation to match the long
>> standing reality, would be a small improvement. I'm not going to further
>> insist, anyway.
>
> The ori
On Mon, Oct 17, 2011 at 12:26 PM, Gabriel Dos Reis
wrote:
> On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini
> wrote:
>> FWIW, I still believe that tweaking the documentation to match the long
>> standing reality, would be a small improvement. I'm not going to further
>> insist, anyway.
>
> It isn
On Mon, Oct 17, 2011 at 5:28 AM, Richard Guenther
wrote:
> On Mon, Oct 17, 2011 at 12:26 PM, Gabriel Dos Reis
> wrote:
>> On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini
>> wrote:
>>> FWIW, I still believe that tweaking the documentation to match the long
>>> standing reality, would be a small i
On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz wrote:
> Hello,
>
> So I committed the gimplify patch separate. And here is the remaining
> fold-const patch.
> The important tests here are in gcc.dg/tree-ssa/builtin-expect[1-4].c, which
> cover the one special-case for branching. Also tree-ssa/2004020
> Of course you can commit to 4.6.
Ok. Btw, my patch had a small regression (PR50752), which was very
quickly reported by Joost. I have just committed the obvious fix as
r180079.
> Be quick, though; 4.6.2 was due for release now-ish -
I know. I'll try to do it today.
Cheers,
Janus
> On Sun,
On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini wrote:
FWIW, I still believe that tweaking the documentation to match the long
standing reality, would be a small improvement. I'm not going to further
insist, anyway.
It isn't improvement.
The impro
On Mon, Oct 17, 2011 at 11:57 AM, Dodji Seketeli wrote:
> In this third instalment the diagnostic machinery -- when faced with
> the virtual location of a token resulting from macro expansion -- uses
> the new linemap APIs to unwind the stack of macro expansions that led
> to that token and emits
On Sat, Oct 15, 2011 at 11:27 PM, Andrew Stubbs wrote:
> This patch fixes a bug in which the widening multiply-and-accumulate
> optimization failed to take the intermediate types into account.
>
> The effect of this is that the compiler would do what the programmer
> expected to happen, rather tha
On 10/15/11 16:21, Eric Botcazou wrote:
>> PR middle-end/50496
>> * cfgrtl.c (try_redirect_by_replacing_jump): Treat EXIT_BLOCK_PTR case
>> separately before call to redirect_jump(). Add assertion.
>> (patch_jump_insn): Same.
>
> This will definitely disable redirections to the
On Sun, Oct 16, 2011 at 12:05 PM, Tom de Vries wrote:
> On 10/14/2011 12:00 PM, Richard Guenther wrote:
>> On Fri, Oct 14, 2011 at 1:12 AM, Tom de Vries wrote:
>>> On 10/12/2011 02:19 PM, Richard Guenther wrote:
On Wed, Oct 12, 2011 at 8:35 AM, Tom de Vries
wrote:
> Richard,
>
On Mon, 17 Oct 2011, Paolo Carlini wrote:
> On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
> > On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini
> > wrote:
> > > FWIW, I still believe that tweaking the documentation to match the long
> > > standing reality, would be a small improvement. I'm not goin
On Mon, Oct 17, 2011 at 5:53 AM, Richard Guenther wrote:
> On Mon, 17 Oct 2011, Paolo Carlini wrote:
>
>> On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
>> > On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini
>> > wrote:
>> > > FWIW, I still believe that tweaking the documentation to match the long
>
2011/10/17 Richard Guenther :
> On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz wrote:
>> Hello,
>>
>> So I committed the gimplify patch separate. And here is the remaining
>> fold-const patch.
>> The important tests here are in gcc.dg/tree-ssa/builtin-expect[1-4].c, which
>> cover the one special-cas
On 10/10/2011 02:23 PM, Paul Brook wrote:
>> Index: libjava/exception.cc
>> ===
>> --- libjava/exception.cc (revision 179739)
>> +++ libjava/exception.cc (working copy)
>> @@ -135,6 +135,7 @@
>> {
>>_Unwind_Ptr Start;
>>
Ping.
Could please someone check if my approach is OK and it is worth to
continue work on patch for PR50038?
Thanks
Ilya
2011/10/11 Ilya Enkovich :
> 2011/10/4 Richard Henderson :
>> On 10/04/2011 08:42 AM, Joseph S. Myers wrote:
>>> On Tue, 4 Oct 2011, Ilya Tocar wrote:
>>>
Hi everyone,
>>
On Mon, 17 Oct 2011, Gabriel Dos Reis wrote:
> On Mon, Oct 17, 2011 at 5:53 AM, Richard Guenther wrote:
> > On Mon, 17 Oct 2011, Paolo Carlini wrote:
> >
> >> On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
> >> > On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini
> >> > wrote:
> >> > > FWIW, I still
On Mon, Oct 17, 2011 at 5:38 AM, Paolo Carlini wrote:
> On 10/17/2011 12:26 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 17, 2011 at 4:42 AM, Paolo Carlini
>> wrote:
>>>
>>> FWIW, I still believe that tweaking the documentation to match the long
>>> standing reality, would be a small improvement
On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
Thus clearly the documentation is wrong ;)
;-)
Not necessarily. Paolo does not say why that line was added.
I don't remember adding that line to change the default.
Indeed, as far as I can see, you added that line while *preserving* the
existing
On Mon, Oct 17, 2011 at 6:08 AM, Richard Guenther wrote:
> The initial patch, split between rev. 31343 and 31999 indeed added
Thanks for helping tracking history.
> + /* Enable automatic line wrapping by default */
> + set_message_length (72);
>
> to C++ lang_decode_option. Later it got appe
On Mon, Oct 17, 2011 at 6:09 AM, Paolo Carlini wrote:
> On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
>>>
>>> Thus clearly the documentation is wrong ;)
>>
>> ;-)
>> Not necessarily. Paolo does not say why that line was added.
>> I don't remember adding that line to change the default.
>
> Inde
On 10/17/2011 01:08 PM, Richard Guenther wrote:
The initial patch, split between rev. 31343 and 31999 indeed added
+ /* Enable automatic line wrapping by default */
+ set_message_length (72);
to C++ lang_decode_option. Later it got appearantly lost somehow,
probably during some of the Great
On Mon, Oct 17, 2011 at 12:59 PM, Kai Tietz wrote:
> 2011/10/17 Richard Guenther :
>> On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz wrote:
>>> Hello,
>>>
>>> So I committed the gimplify patch separate. And here is the remaining
>>> fold-const patch.
>>> The important tests here are in gcc.dg/tree-s
On 10/17/2011 01:16 PM, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 6:09 AM, Paolo Carlini wrote:
On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
Thus clearly the documentation is wrong ;)
;-)
Not necessarily. Paolo does not say why that line was added.
I don't remember adding that line
On Mon, Oct 17, 2011 at 6:14 AM, Paolo Carlini wrote:
> On 10/17/2011 01:08 PM, Richard Guenther wrote:
>>
>> The initial patch, split between rev. 31343 and 31999 indeed added
>>
>> + /* Enable automatic line wrapping by default */
>> + set_message_length (72);
>>
>> to C++ lang_decode_option.
On 10/17/2011 01:24 PM, Gabriel Dos Reis wrote:
Again this argument is making a sort of revisionism. The 72 default
was added to g++, and other front-ends (in reality at the time, only C
could be affected) decided not to. Over the years, we have moved to
share more and more codes with other fro
On Mon, 17 Oct 2011, Gabriel Dos Reis wrote:
> On Mon, Oct 17, 2011 at 6:08 AM, Richard Guenther wrote:
>
> > The initial patch, split between rev. 31343 and 31999 indeed added
>
> Thanks for helping tracking history.
>
> > + /* Enable automatic line wrapping by default */
> > + set_message_
On Mon, Oct 17, 2011 at 6:19 AM, Paolo Carlini wrote:
> On 10/17/2011 01:16 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 17, 2011 at 6:09 AM, Paolo Carlini
>> wrote:
>>>
>>> On 10/17/2011 12:56 PM, Gabriel Dos Reis wrote:
>
> Thus clearly the documentation is wrong ;)
;-)
2011/10/17 Richard Guenther :
> On Mon, Oct 17, 2011 at 12:59 PM, Kai Tietz wrote:
>> 2011/10/17 Richard Guenther :
>>> On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz wrote:
Hello,
So I committed the gimplify patch separate. And here is the remaining
fold-const patch.
The im
On Mon, Oct 17, 2011 at 6:29 AM, Richard Guenther wrote:
> On Mon, 17 Oct 2011, Gabriel Dos Reis wrote:
>
>> On Mon, Oct 17, 2011 at 6:08 AM, Richard Guenther wrote:
>>
>> > The initial patch, split between rev. 31343 and 31999 indeed added
>>
>> Thanks for helping tracking history.
>>
>> > + /*
On Mon, Oct 17, 2011 at 1:31 PM, Kai Tietz wrote:
> 2011/10/17 Richard Guenther :
>> On Mon, Oct 17, 2011 at 12:59 PM, Kai Tietz wrote:
>>> 2011/10/17 Richard Guenther :
On Fri, Oct 14, 2011 at 9:43 PM, Kai Tietz wrote:
> Hello,
>
> So I committed the gimplify patch separate. A
On Mon, Oct 17, 2011 at 6:26 AM, Paolo Carlini wrote:
> I would **strongly** oppose any change to 72 not strongly
> motivated at least by a comparison with other high quality front-ends
I love it when you make arguments like this. It makes me smile, and
I like smiling when I just get off bed :-)
On 10/17/2011 01:44 PM, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 6:26 AM, Paolo Carlini wrote:
I would **strongly** oppose any change to 72 not strongly
motivated at least by a comparison with other high quality front-ends
I love it when you make arguments like this. It makes me smile,
Richard Guenther writes:
> This broke bootstrap on x86_64-linux.
>
> /space/rguenther/src/svn/trunk/libcpp/line-map.c: In function
> 'source_location linemap_macro_map_loc_to_exp_point(const line_map*,
> source_location)':
> /space/rguenther/src/svn/trunk/libcpp/line-map.c:628:12: error:
> variab
On Mon, Oct 17, 2011 at 6:48 AM, Paolo Carlini wrote:
> On 10/17/2011 01:44 PM, Gabriel Dos Reis wrote:
>>
>> On Mon, Oct 17, 2011 at 6:26 AM, Paolo Carlini
>> wrote:
>>>
>>> I would **strongly** oppose any change to 72 not strongly
>>> motivated at least by a comparison with other high quality f
On Tue, Oct 11, 2011 at 04:19:52PM -0300, Alexandre Oliva wrote:
> Here's what I've got so far. Regstrapped on x86_64-linux-gnu and
> i686-linux-gnu. Ok to install?
I see
+FAIL: gcc.c-torture/compile/pr19080.c -O3 -g (internal compiler error)
+FAIL: gcc.c-torture/compile/pr19080.c -O3 -g (te
This changes alignment computation of a MEM during expansion
from MAX (TYPE_ALIGN (TREE_TYPE (exp)), get_object_alignment (exp))
to something weaker (with possibly less alignment) when we
were able to compute an explicit misaligned value (thus,
get_object_alignment_1 (exp, &misalign) would return
This fixes PR50729, so much for not implementing it by using
value-ranges ... opens up the door for more bugs ;)
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-10-17 Richard Guenther
PR tree-optimization/50729
* tree-vrp.c (extract_range
Ok, I see. This might be profitable to do that. So fold_truth_op
hunk looks like this
@@ -5149,13 +5176,6 @@ fold_truthop (location_t loc, enum tree_
build2 (BIT_IOR_EXPR, TREE_TYPE (ll_arg),
ll_arg, rl_arg),
On Sun, Oct 16, 2011 at 22:09, Lawrence Crowl wrote:
> Factor the vector and chain output routines to remove boolean control
> parameters. The functions pph_out_tree_vec_1 and pph_out_chain_1 split
> their conditional parts of their implementation into their use cases,
> calling each other as need
Thanks!
K
On Sat, Oct 15, 2011 at 3:08 PM, Uros Bizjak wrote:
> On Sat, Oct 15, 2011 at 10:32 AM, Uros Bizjak wrote:
>
--- /dev/null
+++ b/gcc/testsuite/gcc.target/i386/fma_double_1.c
@@ -0,0 +1,19 @@
+/* { dg-do compile } */
+/* { dg-prune-output ".*warning: 'sseregpar
This patch adds a call to _commit() on _WIN32 for the FLUSH subroutine
and the FLUSH statement. It removes the _commit from gfortran's buf_flush.
Background:
* gfortran internally buffers the I/O, but it calls the nonbuffering
open/write/read functions (and not, e.g., fopen/fwrite/fread). On
U
On 14/10/11 14:31, Bernd Schmidt wrote:
> On 07/13/11 16:03, Richard Earnshaw wrote:
>>> * config/arm/arm.c (store_multiple_sequence): Avoid cases where
>>> the base reg is stored iff compiling for Thumb1.
>>>
>>> * gcc.target/arm/pr49641.c: New test.
>
> Ping. Richard, you replied to
On Mon, Oct 17, 2011 at 2:22 PM, Kai Tietz wrote:
> Ok, I see. This might be profitable to do that. So fold_truth_op
> hunk looks like this
>
> @@ -5149,13 +5176,6 @@ fold_truthop (location_t loc, enum tree_
> build2 (BIT_IOR_EXPR, TREE_TYPE (ll_arg),
>
On Fri, Oct 14, 2011 at 20:27, Gabriel Charette wrote:
> Yes, I understand that.
>
> But when the second 2.pph is skipped when reading foo.pph, the reading
> of its line_table is also skipped (as foo.pph doesn't contain the
> line_table information for 2.h, 2.pph does and adds it when its
> includ
> "Tristan" == Tristan Gingold writes:
Tom> Another way to look at it is that there have been many changes to GCC's
Tom> DWARF output in the last few years. Surely these have broken these
Tom> DWARF consumers more than this change possibly could.
Tristan> Yes, but there is -gstrict-dwarf to
On 20/09/11 11:51, Andrew Stubbs wrote:
> On 09/09/11 12:55, Richard Earnshaw wrote:
>> The part number field is meaningless outside of the context of a a
>> specific vendor -- only taken as a pair can they refer to a specific
>> part. So why is the vendor field hard-coded rather than factored int
Hi,
here submitter requests a more accurate error message for X.Y where X is
a pointer to class type. Thus the below, tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
//
/cp
2011-10-17 Paolo Carlini
PR c++/44524
* typeck.c (build_class_member_a
Sure,
Is simplier and also handles (A T[-IF] (B T-IF C) -> (A T B) T-IF C
case, which can happen by framing in conditions.
@@ -8380,13 +8400,65 @@ fold_truth_andor (location_t loc, enum t
lhs is another similar operation, try to merge its rhs with our
rhs. Then try to merge our lhs a
On Mon, Oct 17, 2011 at 8:32 AM, Paolo Carlini wrote:
> Hi,
>
> here submitter requests a more accurate error message for X.Y where X is a
> pointer to class type. Thus the below, tested x86_64-linux.
>
> Ok for mainline?
s/is of pointer type/has pointer type/g
>
> Thanks,
> Paolo.
>
>
Finally here is what I am checking in, which passes bootstrap with
--disable-checking --enable-languages=all,ada -- modulo this other bug
that breaks bootstrap as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50709.
It's been OKed off-line by Tom Tromey.
commit c1cd2be336ceec75cf40ac5f32cc4f72
On 10/17/2011 03:39 PM, Gabriel Dos Reis wrote:
On Mon, Oct 17, 2011 at 8:32 AM, Paolo Carlini wrote:
Hi,
here submitter requests a more accurate error message for X.Y where X is a
pointer to class type. Thus the below, tested x86_64-linux.
Ok for mainline?
s/is of pointer type/has pointer t
> I checked the attached patch, test results at
> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg01377.html
>
> which are the same as with my suggested patch.
>
> Ok for the trunk?
I probably don't have authority to approve this, but looks OK to me.
Paul
> gcc/
> * reload1.c (reload_regs_reach_end_p): Replace with...
> (reload_reg_rtx_reaches_end_p): ...this function.
> (new_spill_reg_store): Update commentary.
> (emit_input_reload_insns): Don't clear new_spill_reg_store here.
> (emit_output_reload_insns): Check reload
Roman Zhuykov writes:
> [PATCH 4/9] Move the SMS pass earlier
> http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01811.html
I don't think this is a good idea. To get good results, SMS really
needs to run as close to the register allocator as possible, otherwise
later passes might disrupt the schedul
>> I checked the attached patch, test results at
>> http://gcc.gnu.org/ml/gcc-testresults/2011-10/msg01377.html
>>
>> which are the same as with my suggested patch.
>>
>> Ok for the trunk?
>
> I probably don't have authority to approve this, but looks OK to me.
The libobjc bits are Ok for trunk.
Thanks for inputs, Jakub!
I am attaching updated patch.
Updated testsuite/ChangeLog entry:
2011-10-17 Kirill Yukhin
* gcc.target/i386/avx2-vpop-check.h: New header.
* gcc.target/i386/avx2-vpaddd-3.c: New test.
* gcc.target/i386/avx2-vpaddw-3.c: Ditto.
* gcc.tar
On Fri, 14 Oct 2011, Richard Guenther wrote:
>
> This follows up Michas testcase where we fail to handle the
> conservatively propagated restrict tags properly. The following
> patch simplifies handling of restrict in the oracle and thus
> only excludes NONLOCAL (as designed), but not ESCAPED fr
This is more code clean-up for insn attributes.
It removes "mcu_have_movw", "mcu_mega" and defines "enabled" and "isa"
attributes instead.
The "isa" attribute which triggers "enabled" is a replacement for AVR_HAVE_MOVW
assembler dialect. We don't actually support assembler dialects but different
On Mon, Oct 17, 2011 at 06:27:04PM +0400, Kirill Yukhin wrote:
> Thanks for inputs, Jakub!
>
> I am attaching updated patch.
>
> Updated testsuite/ChangeLog entry:
> 2011-10-17 Kirill Yukhin
>
> * gcc.target/i386/avx2-vpop-check.h: New header.
> * gcc.target/i386/avx2-vpaddd-3
>There is no real post morten debugging on AVR as there is nothing like core
>dump.
But if there is any kind of debugging at all, you might use the debugger to put
a breakpoint in abort(), and if so, having that invoked via jmp means you don't
know who called it. So you'd want a way to suppres
On Mon, Oct 17, 2011 at 3:36 PM, Kai Tietz wrote:
> Sure,
>
> Is simplier and also handles (A T[-IF] (B T-IF C) -> (A T B) T-IF C
> case, which can happen by framing in conditions.
>
> @@ -8380,13 +8400,65 @@ fold_truth_andor (location_t loc, enum t
> lhs is another similar operation, try to
I'm checking this in as obvious.
Sergio pointed out, via this patch, that gcc/configure didn't properly
emit whether sys/std.h was discovered.
Tested by re-running configure and examining the output.
Tom
2011-10-17 Sergio Durigan Junior
* configure.ac: Display `yes' if the SystemTap
paul_kon...@dell.com schrieb:
>> There is no real post morten debugging on AVR as there is nothing like
>> core dump.
>
> But if there is any kind of debugging at all, you might use the debugger to
> put a breakpoint in abort(), and if so, having that invoked via jmp means
> you don't know who cal
Thanks, guys, could anybody please commit that?
K
On Mon, Oct 17, 2011 at 6:33 PM, Jakub Jelinek wrote:
> On Mon, Oct 17, 2011 at 06:27:04PM +0400, Kirill Yukhin wrote:
>> Thanks for inputs, Jakub!
>>
>> I am attaching updated patch.
>>
>> Updated testsuite/ChangeLog entry:
>> 2011-10-17 Kirill
As described in the PR, after Benjamin's patch
2011-10-10 Benjamin Kosnik
PR libstdc++/49818
* config/abi/pre/gnu.ver (CXXABI_1.3.6): Add symbols.
__cxa_get_exception_ptr is now present in both CXXABI_1.3.1 and
CXXABI_1.3.6, which breaks Solaris bootstrap with Sun ld:
ld: fat
On 10/17/2011 05:00 PM, Rainer Orth wrote:
As described in the PR, after Benjamin's patch
2011-10-10 Benjamin Kosnik
PR libstdc++/49818
* config/abi/pre/gnu.ver (CXXABI_1.3.6): Add symbols.
__cxa_get_exception_ptr is now present in both CXXABI_1.3.1 and
CXXABI_1.3.6, which b
On 10/16/2011 01:45 PM, Uros Bizjak wrote:
> libgcc/ChangeLog:
>
> 2011-10-16 Uros Bizjak
> Eric Botcazou
>
> PR target/50737
> * config/alpha/linux-unwind.h (alpha_fallback_frame_state): Set
> fs->signal_frame to 1.
>
> libjava/ChangeLog:
>
> 2011-10-16 Uros B
On Mon, Oct 17, 2011 at 15:49, Tobias Burnus wrote:
> This patch adds a call to _commit() on _WIN32 for the FLUSH subroutine and
> the FLUSH statement. It removes the _commit from gfortran's buf_flush.
Like I argued in this message
http://gcc.gnu.org/ml/fortran/2011-10/msg00094.html ,
I think t
Hi Janne,
On 10/17/2011 05:30 PM, Janne Blomqvist wrote:
On Mon, Oct 17, 2011 at 15:49, Tobias Burnus wrote:
This patch adds a call to _commit() on _WIN32 for the FLUSH subroutine and
the FLUSH statement. It removes the _commit from gfortran's buf_flush.
Like I argued in this message
http://
>> Be quick, though; 4.6.2 was due for release now-ish -
>
> I know. I'll try to do it today.
Alrighty. Just committed the patch to the 4.6 branch as r180099.
Seems we're down to three open Fortran front-end regressions for the
upcoming 4.6.2 release:
* http://gcc.gnu.org/bugzilla/show_bug.cgi
Hi Julian,
There are a couple of minor formatting nits.
>+static int
>+arm_movmemqi_unaligned (rtx *operands)
>+ /* Inlined memcpy using ldr/str/ldrh/strh can be quite big: try to limit
>+ size of code if optimizing for size. We'll use ldm/stm if
>src_aligned
>+ or ds
2011/10/17 Georg-Johann Lay :
> This is more code clean-up for insn attributes.
>
> It removes "mcu_have_movw", "mcu_mega" and defines "enabled" and "isa"
> attributes instead.
>
> The "isa" attribute which triggers "enabled" is a replacement for
> AVR_HAVE_MOVW
> assembler dialect. We don't actu
On Mon, Oct 17, 2011 at 12:22:03PM +0200, Tobias Burnus wrote:
> On 10/15/2011 11:21 PM, Steve Kargl wrote:
> >OK for trunk?
> >
> >2011-10-15 Steven G. Kargl
> >
> > * gfortran.dg/ishft_3.f90: Update test.
>
> I am not so happy with complete test replacements. How about adding it
> as new
On Mon, Oct 17, 2011 at 6:41 AM, Dodji Seketeli wrote:
> Finally here is what I am checking in, which passes bootstrap with
> --disable-checking --enable-languages=all,ada -- modulo this other bug
> that breaks bootstrap as well
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50709.
>
> It's been OK
I plan to check in the following patch as obvious after it passed
testing.
cygwin has a MADV_DONTNEED, but does not use mmap. The ifdefs for
madvise assumed this wouldn't happen and it broke the cygwin build.
Just don't set USING_MADVISE when USING_MMAP is not set. Thanks
to Kai Titz for testin
On 10/17/2011 07:48 AM, Paolo Carlini wrote:
And please help
re-assessing the situation wrt the other front-ends *today* not in the
stone age.
EDG always wraps diagnostics at ~80 columns.
clang wraps diagnostics at $COLUMNS when stderr is going to a terminal,
and doesn't wrap otherwise.
The
Hi,
exactly like the recently fixed c++/17212. Tested x86_64-linux.
Ok for mainline?
Thanks,
Paolo.
/
/gcc
2011-10-17 Paolo Carlini
PR c++/50757
* c-family/c.opt ([Wnonnull]): Add C++ and Objective-C++.
* doc/invoke.texi: Update.
/testsuite
On 10/17/2011 07:31 PM, Jason Merrill wrote:
clang wraps diagnostics at $COLUMNS when stderr is going to a
terminal, and doesn't wrap otherwise.
The clang behavior seems like the right way to go.
Thanks Jason. I'll see how to implement this.
Paolo.
OK.
Jason
OK.
Jason
On 10/16/2011 05:01 PM, Fabien Chêne wrote:
[...]
Does the attached testcase checked what you mention ?
... with the testcase attached.
Yes, that's what I had in mind.
Jason
> Yes. However, in the case that caused the PR, this was attempted with
> reload_completed == 0, so we cannot generate return patterns anyway and
> must fail.
OK, but we clean up the CFG after reload is completed (e.g. just before
emitting the prologue) so in this case we can generate return patt
On 10/17/11 19:43, Eric Botcazou wrote:
>> Yes. However, in the case that caused the PR, this was attempted with
>> reload_completed == 0, so we cannot generate return patterns anyway and
>> must fail.
>
> OK, but we clean up the CFG after reload is completed (e.g. just before
> emitting the prol
1 - 100 of 131 matches
Mail list logo
