Il 21/05/2012 19:21, Andrew Jenner ha scritto:
> Hi Paolo,
>
> On 5/21/2012 10:12 AM, Paolo Bonzini wrote:
>> That's pretty heavy-weight. Perhaps you can try the usual algorithm of
>> looking at x->next and x->next->next?
>
> That would only detect cycles of length 1 and 2 though. While that wou
Manuel López-Ibáñez a écrit:
> This seems a chicken and egg dilemma. Current full-time contributors
> don't have interest or time for this kind of infrastructure work. And
> potential contributors who have interest in using (and perhaps
> improving) this infrastructure prefer to invest their effo
On 05/16/12 07:53, Richard Guenther wrote:
On Mon, 7 May 2012, Aldy Hernandez wrote:
[Sorry for the delay; I was on vacation.]
I am forgoing the load avoidance code altogether to simplify things.
Thanks.
+ /* Emit the load code into the latch, so that we are sure it will
+ be processe
Hi everyone,
This patch adds FPU support for powerpc on platforms that do not have
glibc. It is basically the same code as glibc has. The motivation for
this was that right now there is no fpu-target.h that works for
powerpc-*-vxworks.
Again, 90% of this code comes directly from glibc. Bu
This patch is for the google/gcc-4_6 branch.
Fission improvements and bug fixes. Adds new DW_OP_GNU_const_index to
handle TLS offsets in debug info. Adds -gpubnames/-gno-pubnames options
to explicitly request .debug_pubnames/pubtypes sections. Adds style
parameter to C/C++ pretty-printer so tha
Hi,
tested x86_64-linux, committed.
Paolo.
//
2012-05-21 Paolo Carlini
* testsuite/22_locale/num_put/put/char/9780-2.cc: Avoid -Wall warnings.
* testsuite/29_atomics/atomic/cons/49445.cc: Likewise.
* testsuite/29_atomics/atomic/operators/point
On 05/22/2012 12:53 AM, Jason Merrill wrote:
On 05/21/2012 04:18 PM, Paolo Carlini wrote:
-check_narrowing (type, init);
+check_narrowing (type, perform_implicit_conversion
+ (type, tinit, tf_none));
Any changes should go inside check_narrowing rather than outsi
On 05/21/2012 04:18 PM, Paolo Carlini wrote:
- check_narrowing (type, init);
+ check_narrowing (type, perform_implicit_conversion
+(type, tinit, tf_none));
Any changes should go inside check_narrowing rather than outside. I
think the
OK.
Jason
Hi,
I added to the library testsuite this testcase filed as part of
c++/53361, which works in mainline.
Thanks,
Paolo.
//
2012-05-21 Paolo Carlini
PR c++/53361
* testsuite/23_containers/array/cons/53361.cc: New.
Index: testsuite/23_containers/array/cons
Hello!
As shown in the PR, ivar-invalid-type-1 ICEs in constructor_name_p,
due to accessor on NULL "type" argument.
The one-liner patch fixes the ICE by adding a guard that checks that
current_class_type is non-NULL before calling constructor_name_p.
2012-05-21 Uros Bizjak
PR obj-c++
This is an ICE due to using single_set on a somewhat unconventional call
pattern. To fix it, I've borrowed code from dse.c which was mentioned in
the PR.
Bootstrapped & tested on x86_64-linux and committed.
Bernd
Index: gcc/ChangeLog
===
Hi!
In the testcase in the PR (not valid OpenMP, so not adding it to the
testsuite) predictive commoning optimizes a while (!x); loop with
volatile x into if (!x) for (;;);, because, while the stmt has volatile
ops, the COMPONENT_REF created by omp-low.c doesn't have TREE_THIS_VOLATILE
set on it (
> "Alexander" == Alexander Monakov writes:
Alexander> Hm, isn't GDB's 'set unwindonsignal on' enough to fix it?
Alexander> It's useful to have that in your .gdbinit anyway, because the
Alexander> same issue arises when calling debug_* functions in cc1 from
Alexander> the debugger.
Yeah, why
On May 18, 2012, at 7:48 PM, Lawrence Crowl wrote:
> On 5/17/12, Mike Stump wrote:
>> On May 17, 2012, at 2:41 PM, Lawrence Crowl wrote:
Reusing the compiler for this seems like the only way to go.
But, we did look at using g++ to parse C++ expressions from gdb,
and it was too slow
GDB PR 14065 has an executable which causes gdb to crash.
It crashes trying to demangle a certain symbol (see the included test
case). The standalone demangler doesn't crash here, but you can still
see the failure with valgrind.
I'm not sure this is the proper fix, but it seemed correct, and it
On 05/21/12 12:59, Patrick Marlier wrote:
> 2012-05-21 Patrick Marlier
>
> * eh_cpp.cc: Fix __cxa_end_catch declaration.
Ok.
r~
Hi,
this PR is about the missing -Wnarrowing warning for:
struct X
{
constexpr operator int() { return __INT_MAX__; }
};
signed char c { X{} };
The core issue seems pretty simple: check_narrowing, called by
check_initializer, cannot handle something as complex as a class type
with a type c
On Wed, May 16, 2012 at 1:03 PM, Sterling Augustine
wrote:
> This patch adds new flags and defines such that the C++ decl pretty printer
> prints both canonical dwarf names for decls without perturbing normal error
> message output.
>
> It addresses the issues with the earlier patches submitted as
Hi,
__cxa_end_catch declaration was wrong. No functional change just
correctness.
Ok for trunk?
Thanks.
2012-05-21 Patrick Marlier
* eh_cpp.cc: Fix __cxa_end_catch declaration.
--
Patrick Marlier
Index: eh_cpp.cc
===
Hello!
A cleanup to make ix86_output_operand more maintainable:
- merge condition code handling where appropriate
- change a couple of operands of put_condition_code to bool
- fix a couple of error reporting strings (COMPARISON_P does not check
for constant)
- move operand size checking cases tog
http://www.youtube.com/watch?feature=youtu.be&hl=ro&v=_Sl3Ox7RMnE
To unsubscribe please send email to unsubscr...@cc.psd-prahova.ro
> Regarding the implementation of popcntb, popcntd, and cmpb. Gcc has
> dedicated masks on target_flags for them, but due to shortage of bits,
> those masks controls more than the name implies.
The target flag bits control more than the name implies, but the bits
correspond to published ISA levels
This implements clzsi2 for m68k. It also fixes a bug in the Coldfire
expansion: ff1 (like bfffo) sets ccr from the source operand. Tested on
m68k-linux and installed on trunk.
Andreas.
* config/m68k/m68k.md (*clzsi2_cf): Renamed from clzsi2. Call
CC_STATUS_INIT.
(clzsi2
>> The entire motivation for this patch, including the proposed new
>> attributes is at:
>>
>> http://gcc.gnu.org/wiki/DebugFission
>>
>> In particular, the section titled, "Building a GDB Index".
>
> OK, I've read that section and I still don't understand why the consumer
> would need a pointer fr
Doug Evans writes:
> long long (+ unsigned long long) is ok by me.
> I could also rename the functions to read_uleb128_to_ull (unsigned
> long long) to allow for a day if/when someone wants
> read_uleb128_to_uint64. Ok?
Sounds good to me.
Thanks.
Ian
As discussed on the "RFC: questions on store data race" thread. This
patch increases the granularity of transactionness from the gimple
statement to the basic block containing it.
Pre-approved and committed.
Tested on x86-64 Linux.
Thanks.
* gimple.h (gimple_set_in_transaction): Remo
First: I have another rather simple patch, which still needs to be
reviewed: http://gcc.gnu.org/ml/fortran/2012-05/msg00086.html
* * *
When a realloc on assignment is done, gfortran first obtains the
descriptor by calling realloc_lhs_loop_for_fcn_call and then does the
actual function call u
Hi Paolo,
On Mon, 21 May 2012, Paolo Bonzini wrote:
Il 20/05/2012 20:50, Dimitrios Apostolou ha scritto:
Paolo: I couldn't find a single test-case where the mw_reg_pool was
heavily used so I reduced its size. You think it's OK for all archs?
Makes sense, we can see if something breaks. I'
On Mon, May 21, 2012 at 10:08 AM, Ian Lance Taylor wrote:
> d...@google.com (Doug Evans) writes:
>
>> 2012-05-17 Doug Evans
>>
>> * leb128.h: New file.
>
> I'm not entirely sure about the use of int64_t to hold the result. Do
> we want to let this interface support larger types some day?
get_def_for_expr_class and convert_tree_comp_to_rtx are only used if
HAVE_conditional_move. Tested on m68k-linux and ppc-linux, checked in.
Andreas.
* expr.c (get_def_for_expr_class): Define only if
HAVE_conditional_move.
(convert_tree_comp_to_rtx): Likewise.
diff --git
Hi Paolo,
On 5/21/2012 10:12 AM, Paolo Bonzini wrote:
That's pretty heavy-weight. Perhaps you can try the usual algorithm of
looking at x->next and x->next->next?
That would only detect cycles of length 1 and 2 though. While that would
cover all the testcases we currently know about, I wante
Il 20/05/2012 20:50, Dimitrios Apostolou ha scritto:
>
>
> Paolo: I couldn't find a single test-case where the mw_reg_pool was
> heavily used so I reduced its size. You think it's OK for all archs?
>
Makes sense, we can see if something breaks. I'll commit the patch
tomorrow after a re-review.
Il 21/05/2012 17:54, Andrew Jenner ha scritto:
> This patch is a followup to the patch Sandra Loosemore made to fix
> PR50380 (see (http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01402.html).
> That patch only detects fixed points, but Joseph Myers found a testcase
> which creates a cycle of length 2
Il 21/05/2012 02:57, Andrew Pinski ha scritto:
> The problem here is that when libgcc goes to try to figure out the
> size of double/long double, it includes some headers. But those
> headers does not exist when doing a "stage1" Linux cross compiler
> build.
>
> This fixes the problem having conf
d...@google.com (Doug Evans) writes:
> 2012-05-17 Doug Evans
>
> * leb128.h: New file.
I'm not entirely sure about the use of int64_t to hold the result. Do
we want to let this interface support larger types some day? E.g.,
should the result be long long?
I'll approve this patch, but
On Mon, 2012-05-21 at 14:17 +0200, Richard Guenther wrote:
> On Thu, May 3, 2012 at 4:33 PM, William J. Schmidt
> wrote:
> > This patch was posted for comment back in February during stage 4. It
> > addresses a performance issue noted in the EEMBC routelookup benchmark
> > on a common idiom:
> >
On Wed, Apr 11, 2012 at 7:35 AM, Bernd Schmidt wrote:
> On 12/23/2011 05:31 PM, Vladimir Makarov wrote:
>> On 12/21/2011 09:09 AM, Bernd Schmidt wrote:
>>> This patch was an experiment to see if we can get the same improvement
>>> with modifications to IRA, making it more tolerant to over-aggressi
On Mon, May 21, 2012 at 8:51 AM, Uros Bizjak wrote:
> On Mon, May 21, 2012 at 5:39 PM, Alexander Ivchenko
> wrote:
>
>> Changelog entry:
>>
>> 2012-05-21 Alexander Ivchenko
>>
>> PR target/53435
>> * config/i386/i386.c (ix86_expand_vec_perm): Use correct op.
>> (ix86_expa
Hi,
On Mon, 21 May 2012, Richard Guenther wrote:
> This removes the code that makes us walk DECL_INITIAL (recursively)
> on add_referenced_var - one source of compile-time hogs in the past
> and not strictly necessary.
For this to be a compile time hog, ...
>if (referenced_var_check_and_ins
This patch is a followup to the patch Sandra Loosemore made to fix
PR50380 (see (http://gcc.gnu.org/ml/gcc-patches/2011-12/msg01402.html).
That patch only detects fixed points, but Joseph Myers found a testcase
which creates a cycle of length 2, causing find_comparison_args to stall
even with t
On Mon, May 21, 2012 at 5:39 PM, Alexander Ivchenko wrote:
> Changelog entry:
>
> 2012-05-21 Alexander Ivchenko
>
> PR target/53435
> * config/i386/i386.c (ix86_expand_vec_perm): Use correct op.
> (ix86_expand_vec_perm): Use int mode instead of float.
> (expand_vec_
On Thu, 17 May 2012, Tom Tromey wrote:
> It would be nice if there were a way to make cc1 not crash due to user
> error in the debugger. I think this kind of crash will be especially
> crazy-making.
Hm, isn't GDB's 'set unwindonsignal on' enough to fix it? It's useful to
have that in your .gd
Hello!
It turned out that "rep; bsf" is not a 100% substitute for "tzcnt"
since the former sets ZF for zero input, while the later sets CF.
Attached patch fixes this oversight in ffs sequence.
2012-05-24 Uros Bizjak
PR target/53399
* config/i386/i386.md (ffs2): Generate CCCmod
Hi, could pls have a look to fix for
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53435
Changelog entry:
2012-05-21 Alexander Ivchenko
PR target/53435
* config/i386/i386.c (ix86_expand_vec_perm): Use correct op.
(ix86_expand_vec_perm): Use int mode instead of float.
On Mon, May 21, 2012 at 1:14 AM, Alan Modra wrote:
> Currently, powerpc-linux gcc -Os -mno-multiple uses out-of-line gpr
> save and restore functions when saving/restoring just one gpr. That's
> quite silly since the function call requires more instructions and is
> slower than an inline save/res
On Sun, May 20, 2012 at 10:48 PM, Alan Modra wrote:
> On Tue, May 08, 2012 at 08:02:39PM +0930, Alan Modra wrote:
>> I also make use of gen_frame_store and siblings that I invented for
>> generating the eh info, elsewhere in rs6000.c where doing so is
>> blindingly obvious. We could probably use
On Sun, May 20, 2012 at 9:57 PM, Alan Modra wrote:
> This removes rather a lot of forward declarations in rs6000.c, most of
> which existed to satisfy an early TARGET_INITIALIZER. Now that the
> TARGET_INITIALIZER has been moved to the end of rs6000.c, they become
> unnecessary and wrongly give t
> Hello list,
>
> I ported a patch from last year's GSOC to current trunk, removing
> deprecated hash tables and adding some new ones. I also backed out a
> change that reduced collisions by decreasing load factor because it had
> created controversy, so this patch should be easily applicable
What if the built-in macro appears in a macro defined in a system header
but used in user code? This would resolve the location all the way to
the user code, and warn. I think we only want to step out until we
reach a non-built-in macro, not all the way to the outermost expansion
point.
Jas
On 05/21/2012 09:53 AM, Dodji Seketeli wrote:
I have changed the gcc+.dg/warn/Wunused-local-typedefs.C test case to
make it use -Wunused instead of -Wunused-local-typedefs. I had to
adjust it to avoid the warnings due to the other -W* options triggered
by -Wunused there.
Hmm, I might have adde
This makes add_referenced_var take a struct function argument to
eventually avoid a push/pop_cfun around some of its callers (in
some further patch). It also avoids a redundant hashtable
lookup on var insertion.
Bootstrap & regtest running on x86_64-unknown-linux-gnu.
Richard.
2012-05-21 Rich
On 05/21/2012 10:07 AM, Dodji Seketeli wrote:
Jason Merrill writes:
When do we not want to set invocation_location if we're beginning to
expand a macro?
If M itself involves expanding another macro M', we are supposed to call
the (internal function) cpp_get_token_1 that does not set
set_invoc
OK.
Jason
On 17/05/12 14:23, Jim MacArthur wrote:
> On 02/05/12 14:55, Richard Sandiford wrote:
>> Richard Earnshaw writes:
>>> On 02/05/12 14:00, Richard Sandiford wrote:
Jim MacArthur writes:
> New Changelog text:
>
> 2012-05-02 Jim MacArthur
> * recog.c (reg_fits_class_p): Check bot
This patch fixes PR 53148, a regression where a conditional expression
between signed and unsigned, the evaluated half involving division by
zero but both halves having only integer constants as operands,
resulted in an ICE because C_MAYBE_CONST_EXPRs were wrongly nested
(they should never be neste
OK.
Jason
This removes the code that makes us walk DECL_INITIAL (recursively)
on add_referenced_var - one source of compile-time hogs in the past
and not strictly necessary. Fallout is fixed by guarding used flag
setting in unused-var-removal as all reads of that flag are already.
This is a first patch in
On Mon, 21 May 2012 02:30:58 +0200, Doug Evans wrote:
> Ping.
> On Thu, May 17, 2012 at 11:29 AM, Doug Evans wrote:
[...]
> > --- /dev/null 1 Jan 1970 00:00:00 -
> > +++ leb128.h 17 May 2012 18:23:29 -
[...]
> > +/* Get a definition for NULL. */
> > +#include
I think for NULL.
[
Tom Tromey writes:
>> "Dodji" == Dodji Seketeli writes:
>
> Dodji> To properly fix this, I think libcpp should keep the token of the
> Dodji> pasting operator '##', instead of representing it with flag on the LHS
> Dodji> operand's token. That way, it could use its location.
>
> Originally
One line patch to update Makefile.
2012-05-21 Dimitrios Apostolou
* gcc/Makefile.in: (toplev.o) toplev.o depends on cselib.h.
=== modified file 'gcc/Makefile.in'
--- gcc/Makefile.in 2012-05-04 20:04:47 +
+++ gcc/Makefile.in 2012-05-21 14:08:45 +
@@ -2751,7 +2751,7 @
On Mon, May 21, 2012 at 4:04 PM, Jakub Jelinek wrote:
> Hi!
>
> If there are exactly 2 complex loads and some other loads in SLP instance,
> we sometimes miscompile things because vect_supported_load_permutation_p
> skips important checks.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux a
On Mon, May 21, 2012 at 3:59 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE, because op_def_stmt isn't inside
> of the loop (phi is a degenerate phi referencing a phi result from before the
> loop) and stmts outside of the loop don't have uid set (or it can contain
> garbage).
Jason Merrill writes:
> On 05/15/2012 10:17 AM, Dodji Seketeli wrote:
>> It fixes the test case gcc.dg/cpp/paste12.c because that test case runs
>> with -ftrack-macro-expansion turned off. Otherwise, you are right that
>> the issue exists only when we aren't tracking virtual locations.
>
> I sti
On Mon, May 21, 2012 at 3:55 PM, Jakub Jelinek wrote:
> Hi!
>
> As the following testcases show, some places in fold_binary_loc
> (haven't checked other routines) can attempt to optimize even vector
> expressions, but in that case build_int_cst can't be used.
> Instead, for zeros build_zero_cst ca
PING 2:
This is a ping for the patch that add 'function_vector' attribute for
H8300 targets:
http://gcc.gnu.org/ml/gcc-patches/2012-04/msg00250.html
The patch has been updated to address Jeff's comments which can be referred
at: http://gcc.gnu.org/ml/gcc-patches/2012-03/msg01884.html
Please re
Hi!
If there are exactly 2 complex loads and some other loads in SLP instance,
we sometimes miscompile things because vect_supported_load_permutation_p
skips important checks.
Fixed thusly, bootstrapped/regtested on x86_64-linux and i686-linux, ok for
trunk/4.7?
2012-05-21 Jakub Jelinek
Hello list,
I ported a patch from last year's GSOC to current trunk, removing
deprecated hash tables and adding some new ones. I also backed out a
change that reduced collisions by decreasing load factor because it had
created controversy, so this patch should be easily applicable.
CC'd whoe
Hi!
On the following testcase we ICE, because op_def_stmt isn't inside
of the loop (phi is a degenerate phi referencing a phi result from before the
loop) and stmts outside of the loop don't have uid set (or it can contain
garbage).
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for tr
Hi!
As the following testcases show, some places in fold_binary_loc
(haven't checked other routines) can attempt to optimize even vector
expressions, but in that case build_int_cst can't be used.
Instead, for zeros build_zero_cst can be used, for the two places
which need to build 1 I'm just foldi
Hello,
The location for a built-in macro token is BUILTIN_LOCATION. When we
see that location value, we cannot know if that token was used in a
system header or not. And that can trigger some unwanted warnings on
e.g, the use of __LONG_LONG_MAX__ built-in macro in system headers
when we compile
Hello,
As the audit trail of this shows, -Wunused-local-typedefs is not
turned on by -Wunused after all. Sigh.
Now that we have the EnabledBy construct for the *.opt files, it's
more precise and concise to use that to make -Wunused-local-typedefs
be triggered by -Wunused.
I have changed the gcc
Hi,
this is a rather old diagnostic issue, already reported at least 3
times, recently too.
I tried various small variants of the same idea, and the below appears
to work well enough: it tells the user about all the missing open and
closed parentheses and overall the diagnostic is quite simi
Hi Eric,
there's a call to expand_decl in gcc-interface/utils.c, which is used only
for setting up some field of CONST_DECLs. I'm working on removing this
function, and removing that call from utils.c is seemingly working just
fine. It came in with :
2005-11-14 Thomas Quinot
O
On Thu, May 3, 2012 at 4:33 PM, William J. Schmidt
wrote:
> This patch was posted for comment back in February during stage 4. It
> addresses a performance issue noted in the EEMBC routelookup benchmark
> on a common idiom:
>
> if (...)
> x = y->left;
> else
> x = y->right;
>
> If the two
Ping for:
On May 15, 2012, at 11:10 AM, Tristan Gingold wrote:
> Hi,
>
> use of 'unsigned int' for i386.c:ix86_compute_frame_layout
> stack_alignment_needed results in truncation of frame offset in code such as:
>
> offset = (offset + stack_alignment_needed - 1) & -stack_alignment_needed
>
>
This fixes PR53408, we ICE when we encounter an unhandled situation
in induction handling for outer loop vectorization - the fix is to
properly reject this at analysis time rather than asserting and
ICEing, of course.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2012-
Ping for:
On May 15, 2012, at 10:52 AM, Tristan Gingold wrote:
> hi,
>
> looks like a typo...
>
> Ok for trunk ?
>
> Tristan.
>
> 2012-05-14 Tristan Gingold
>
> * common/config/ia64/ia64-common.c (ia64_except_unwind_info): Fix typo.
>
> diff --git a/gcc/common/config/ia64/ia64-comm
On Mon, May 21, 2012 at 12:18 PM, Richard Guenther
wrote:
> On Sun, May 20, 2012 at 9:10 PM, Diego Novillo wrote:
>> On 12-05-20 13:59 , Richard Henderson wrote:
>>>
>>> On 05/18/2012 04:48 PM, Diego Novillo wrote:
We can do this in trunk today using a variant of Lawrence's original
>>>
> > + 2012-05-17 Jan Hubicka
> > +
> > + * lto-symtab.c (lto_symtab_resolve_symbols): Preffer decl with
> > constructor
> > + over decl without.
> > + * cgraph.c (cgraph_remove_node): Clear also body of unanalyzed
> > nodes.
> > + * cgraph.h (varpool_can_remove_if_no_re
Seem to have missed this one.
Committed as obvious.
Richard.
2012-05-21 Richard Guenther
* gfortran.dg/pr46519-2.f90: Adjust to avoid memset transform.
Index: gcc/testsuite/gfortran.dg/pr46519-2.f90
===
--- gcc/testsui
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-05-21 Richard Guenther
* tree-loop-distribution.c (can_generate_builtin): Reject
volatile stmts.
* gcc.dg/torture/ldist-1.c: New testcase.
Index: gcc/tree-loop-distribution.c
===
On Sun, May 20, 2012 at 9:10 PM, Diego Novillo wrote:
> On 12-05-20 13:59 , Richard Henderson wrote:
>>
>> On 05/18/2012 04:48 PM, Diego Novillo wrote:
>>>
>>> We can do this in trunk today using a variant of Lawrence's original
>>> patch (http://gcc.gnu.org/ml/gcc-patches/2011-09/msg01649.html).
Hello,
This patch restores the --specs flags functionality.
There are 2 parts
1) Lazily check the flag validation until all command line spec files
are read. For this purpose, 'read_specs' records specs, to be analyzed
with 'file_spec_p'. Such flags have 'live_cond' = SWITCH_USER
2) --specs optio
On Sun, May 20, 2012 at 7:56 PM, Eric Botcazou wrote:
> Hi,
>
> since http://gcc.gnu.org/ml/gcc-patches/2011-05/msg00833.html, canonical type
> merging for arrays takes hours instead of minutes for big Ada applications.
> The problem is that iterative_hash_canonical_type doesn't hash TYPE_MIN_VALU
On Sun, May 20, 2012 at 7:24 PM, Nathan Sidwell wrote:
> In building a ppc cross compiler using a freshly built native compiler, I
> encountered an ICE in iterative_hash_expr compiling c-lex.c. I extracted
> the attached testcase, showing the problem is with statement expressions.
> Investigation
On Sun, May 20, 2012 at 1:40 AM, Andrew Pinski wrote:
> The problem here is that tree-if-conv.c produces COND_EXPR instead of
> the MAX/MIN EXPRs. When I added the expansion from COND_EXPR to
> conditional moves, I assumes that the expressions which should have
> been converted into MAX_EXPR/MIN_
On Sat, May 19, 2012 at 11:07 PM, John David Anglin
wrote:
> The attached change fixes a compilation error that occurs because
> JCR_SECTION_NAME is not defined on hppa*-hpux.
>
> Tested on hppa2.0w-hp-hpux11.11.
>
> Ok for trunk?
Ok.
Thanks,
Richard.
> Dave
> --
> J. David Anglin
On 05/21/2012 11:49 AM, Fabien Chêne wrote:
Doesn't the target selector c++11 set -pedantic as well ?
You may be right, I didn't check, sorry. Then just add that too,
wouldn't be the first time.
Paolo.
On Fri, May 18, 2012 at 11:13 PM, Robert Dewar wrote:
> On 5/18/2012 4:27 PM, Ulrich Weigand wrote:
>
>> I finally got some time to look into this in detail. The various special-
>> case transforms in associate_plusminus all transform a plus/minus
>> expression
>> tree into either a single operan
2012/5/21 Paolo Carlini :
> On 05/21/2012 01:45 AM, Michael Hope wrote:
>>
>> The testsuite for PR52796 uses the 'target c++11' selector which doesn't
>> exist in 4.6.
>> This patch backports the selector, clearing the 'ERROR:
>> g++.dg/cpp0x/variadic-value1.C:
>> syntax error in target selector "t
Hi,
a simple diagnostic issue: we aren't diagnosing functions returning
abstract class types as typenames.
In grokdeclarator we already have a place where we do such checks on the
return types, and I'm adding this one too, with the following details:
1- I'm not immediately returning with er
I tried applying your patch but ran into trouble with patch not liking
this . My suspicion is mailer munging white spaces in some form -
Could you send the patch as an attachment please rather than inline in
your mail ?
regards,
Ramana
Here it is, as an attachment. Note however that this patch
On 05/21/2012 01:45 AM, Michael Hope wrote:
The testsuite for PR52796 uses the 'target c++11' selector which
doesn't exist in 4.6.
This patch backports the selector, clearing the 'ERROR:
g++.dg/cpp0x/variadic-value1.C:
syntax error in target selector "target c++11" for " dg-do 2 run {
target c+
On Fri, 18 May 2012, Andi Kleen wrote:
> Richard Guenther writes:
>
> > In PR53346 we vectorize a simple memset loop very inefficiently.
> > But of course we should have detected this and transformed the
> > loop into a memset! Seems like we only do that if the original
> > loop does sth else t
95 matches
Mail list logo
