Clearly my test was inadequate...we need to handle DECLTYPE_TYPE as well
as actual enums and classes.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit 9c1e6f92b1b4bd4d30f4d04818900e05c59382bc
Author: Jason Merrill
Date: Sat Jul 23 14:21:48 2011 -0400
PR c++/49823
* parser.c (c
Commited.
On 07/24/2011 06:22 PM, David Edelsohn wrote:
> This patch set causes a bootstrap failure on AIX:
>
> In file included from /farm/dje/src/src/libgcc/../gcc/unwind-dw2.c:1590:0:
> /farm/dje/src/src/libgcc/../gcc/unwind.inc: In function
> '_Unwind_RaiseException':
> /farm/dje/src/src/libgcc/../gcc/u
The ARM failure was due to constant pools being considered
unreachable code. Ideally, we'd do something to mark these
constant pools as data, not code, but again that's something
for another day.
A full arm-eabi test run is still underway, but at least the
libgcc build failure is fixed.
r~
With the last two fixes, the only remaining i686 regression
from Thursday is 1 fortran testcase, whose number I have
misplaced. This highlights an accidental change I made while
moving code around between functions, and an assertion I
added trying to see if we'd Done The Right Thing already.
Th
This fixes the examples given in the PR building libgcc
for Sparc and CRIS. A full bootstrap on sparc64-linux
is underway, but it'll take some time to complete. In
the meantime it's well past the stage1 failure.
Just a silly oversight in processing sequences, after
having copied the code from pr
On 07/24/2011 08:09 PM, H.J. Lu wrote:
On Sun, Jul 24, 2011 at 7:03 PM, H.J. Lu wrote:
On Mon, Jul 11, 2011 at 10:45 AM, Sandra Loosemore
wrote:
2011-06-17 Sandra Loosemore
gcc/
* configure.ac (demangler_in_ld): Default to yes.
* configure: Regenerated.
* collect2.c (main
As a follow-up, by inspection, args_size should be zeroed across
edges for which we explicitly undo args_size, like EH. But we
do the same thing for non-local gotos and computed gotos.
I couldn't see any difference in the test results with this
patch, and frankly I'm surprised about that. But,
Tested on i686-linux. I'm not sure how I missed this with {,-m32}
testing on x86_64.
r~
PR debug/49825
* dwarf2cfi.c (cfi_row_equal_p): Don't compare args_size.
diff --git a/gcc/dwarf2cfi.c b/gcc/dwarf2cfi.c
index 3ff4c61..f715e07 100644
--- a/gcc/dwarf2cfi.c
+++ b/gcc/dwarf2
On Sun, Jul 24, 2011 at 7:03 PM, H.J. Lu wrote:
> On Mon, Jul 11, 2011 at 10:45 AM, Sandra Loosemore
> wrote:
>> Ping?
>>
>> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html
>>
>>> We had a bug report from a customer that the linker was ignoring the
>>> --demangle and --no-demangle options
On Mon, Jul 11, 2011 at 10:45 AM, Sandra Loosemore
wrote:
> Ping?
>
> http://gcc.gnu.org/ml/gcc-patches/2011-06/msg01368.html
>
>> We had a bug report from a customer that the linker was ignoring the
>> --demangle and --no-demangle options when generating map files.
>> Moreover, it was failing in
On Sun, Jul 24, 2011 at 2:34 PM, Uros Bizjak wrote:
> On Sat, Jul 23, 2011 at 3:57 PM, H.J. Lu wrote:
>
This patch adds x32 LEA insn support. The main issue is
gen_lowpart (Pmode, operands[1]);
doesn't work on symbol. This patch avoids it.
Also we shouldn't ge
This patch set causes a bootstrap failure on AIX:
In file included from /farm/dje/src/src/libgcc/../gcc/unwind-dw2.c:1590:0:
/farm/dje/src/src/libgcc/../gcc/unwind.inc: In function
'_Unwind_RaiseException':
/farm/dje/src/src/libgcc/../gcc/unwind.inc:136:1: internal compiler
error: in maybe_record_
Hi,
There are two issues, first the inliner does not copy a volatile
when creating a new tree in one case. The second issue is that
IPA-SRA does not check if we are deferencing a pointer variable via a
volatile type.
OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Thanks,
On Tue, 28 Jun 2011, Joseph S. Myers wrote:
> (In checking for such files -
> there aren't that many - I also noticed that the target macro
> DELAY_SLOTS_FOR_EPILOGUE is used and documented but not defined by any
> target, so the code relating to that macro is ripe for removal and
> poisoning of th
On Sat, Jul 23, 2011 at 3:57 PM, H.J. Lu wrote:
>>> This patch adds x32 LEA insn support. The main issue is
>>>
>>> gen_lowpart (Pmode, operands[1]);
>>>
>>> doesn't work on symbol. This patch avoids it.
>>>
>>> Also we shouldn't generate 32bit store with x32 PIC source.
>>>
>>> Any comments?
On Mon, 25 Jul 2011, Anatoly Sokolov wrote:
> Hi.
>
> This patch removes obsolete PRINT_OPERAND, PRINT_OPERAND_ADDRESS and
> PRINT_OPERAND_PUNCT_VALID_P macros from MMIX back end in the GCC and
> introduces equivalent TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS and
> TARGET_PRINT_OPERAND_P
Hi.
This patch removes obsolete PRINT_OPERAND, PRINT_OPERAND_ADDRESS and
PRINT_OPERAND_PUNCT_VALID_P macros from M32C back end in the GCC and
introduces equivalent TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS and
TARGET_PRINT_OPERAND_PUNCT_VALID_P target hooks.
Regression tested on m3
Hi.
This patch removes obsolete PRINT_OPERAND, PRINT_OPERAND_ADDRESS and
PRINT_OPERAND_PUNCT_VALID_P macros from MMIX back end in the GCC and
introduces equivalent TARGET_PRINT_OPERAND, TARGET_PRINT_OPERAND_ADDRESS and
TARGET_PRINT_OPERAND_PUNCT_VALID_P target hooks.
Regression tested on mm
* ping *
http://gcc.gnu.org/ml/fortran/2011-07/msg00246.html
Tobias Burnus:
Tobias Burnus wrote:
This patch adds a "token" element as last element in the descriptor
such that is can be easily ignored when passing a descriptor to a
noncoarray descriptor dummy.
Handling coarray descriptors di
On Sun, Jul 24, 2011 at 05:59, Richard Guenther
wrote:
> For two IVs with the same precision, one signed and one unsigned you choose
> signedness of the canonical IV based on the random order of PHIs - that
> doesn't
> look correct.
>
> I think what you should do here is use an unsigned type if a
... Francois, your patch, as applied had nasty typos, which probably
broke the build (or we lacking tons of testcases ;) I committed the below.
Paolo.
PS: I think the fix could be suited also for the branch, maybe after a
couple of weeks of testing...
///
2011-07-24 Paolo Ca
On 07/24/2011 09:24 PM, François Dumont wrote:
For info, I will submit a proposal for DR 41975 tomorrow or the day
after.
Oh, excellent, and good idea saying it in advance.
Paolo.
On 07/24/2011 01:31 AM, Paolo Carlini wrote:
On 07/23/2011 10:31 PM, François Dumont wrote:
Hi
While working on DR 41975 I realized a small issue in current
rehash implementation that sometimes lead to load_factor being
greater than max_load_factor. Here is a patch to fix that:
Ok, good.
Hi,
we sometimes get messages like this in Ada:
prime-mc2-other.adb: In function 'PRIME.MC2.OTHER.DO_SOMETHING':
prime-mc2.adb:2:4: warning: inlining failed in call
to 'PRIME.MC2.GET_INPUT_VALUE.PART': non-call exception handling mismatch
[-Winline]
prime-mc2-other.adb:3:4: warning: called from
Hi Steven,
On Sun, 24 Jul 2011, Steven Bosscher wrote:
Can you please create your patches with the -p option, so that it's
easier to see what function you are changing? Also, even for an RFC
patch a ChangeLog is more than just nice to have ;-)
Do you mean an entry in Changelog file in root dir
On Sun, Jul 24, 2011 at 6:08 PM, Dimitrios Apostolou wrote:
> Hello all,
>
> attached is my attempt to replace bitmaps, that we are *sure* they will
> never map any pseudo regs, with HARD_REG_SETs. Jakub, I have moved the check
> you suggested, for never surpassing FIRST_PSEUDO_REGS, into hard-reg
On Sun, Jul 24, 2011 at 2:02 PM, Ira Rosen wrote:
> On 21 July 2011 15:19, Ira Rosen wrote:
>> On 20 July 2011 21:35, Ulrich Weigand wrote:
>>>
>>> The return value of foo with vectorization is 1249 instead
>>> of 1999 for some reason.
>>
>> I reproduced the failure. It occurs without Richard's
The Ada language has got Out and In/Out parameters for subprograms and gigi
builds a special structure return type to pass them back. The attached patch
improves the latter mechanism by promoting the mode of this structure return
type if it is passed in registers.
Tested on i586-suse-linux, ap
"Ulrich Weigand" wrote on 22/07/2011 05:05:57 PM:
> Hi Ira,
>
> gcc.dg/vect/vect-70.c fails sporadically on spu-elf, because the local
> variable "tmp1" exceeds local store size (it is over 1MB in size), and
> thus the stack wraps around.
>
> Dorit had originally fixed this by reducing the size
When gigi builds an indexed component reference with a variable index, it marks
the array object as addressable. This was probably necessary back in the RTL
days but this is very likely obsolete by now.
Tested on i586-suse-linux, applied on the mainline.
2011-07-24 Eric Botcazou
*
Tested on i586-suse-linux, applied on the mainline.
2011-07-24 Eric Botcazou
* gcc-interface/gigi.h (build_function_stub): Remove.
(build_return_expr): Likewise.
(convert_vms_descriptor): Declare.
* gcc-interface/utils.c (convert_vms_descriptor): Make global.
On 21 July 2011 15:19, Ira Rosen wrote:
> On 20 July 2011 21:35, Ulrich Weigand wrote:
>>
>> The return value of foo with vectorization is 1249 instead
>> of 1999 for some reason.
>
> I reproduced the failure. It occurs without Richard's
> (http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01022.html)
On Sun, Jul 24, 2011 at 9:25 AM, Sebastian Pop wrote:
> 2011-07-23 Sebastian Pop
>
> * tree-data-ref.c (max_stmt_executions_tree): Do not call
> lang_hooks.types.type_for_size.
> ---
> gcc/ChangeLog | 5 +
> gcc/tree-data-ref.c | 5 -
> 2 files changed, 9 inse
On Sun, Jul 24, 2011 at 9:25 AM, Sebastian Pop wrote:
> 2011-07-23 Sebastian Pop
>
> PR middle-end/47653
> * graphite-scop-detection.c (graphite_can_represent_loop): Discard
> loops using wrapping semantics.
>
> * gcc.dg/graphite/run-id-pr47653.c: New.
> * gcc
On Sun, Jul 24, 2011 at 9:25 AM, Sebastian Pop wrote:
> 2011-07-23 Sebastian Pop
>
> * tree-ssa-loop-manip.c (canonicalize_loop_ivs): Build an unsigned
> iv only when the largest type is unsigned. Do not call
> lang_hooks.types.type_for_size.
>
> * testsuite/libgomp
On Sat, Jul 23, 2011 at 6:29 PM, DJ Delorie wrote:
>
>> Yeah, the testcase is invalid - that we lost the volatile was a bug, but
>> you really have to fix the kernel.
>
> Sadly, that's not a helpful suggestion. How else should the kernel
> force a word-sized read? I thought volatile was the way
On Sat, Jul 23, 2011 at 4:38 PM, Sebastian Pop wrote:
> On Sat, Jul 23, 2011 at 09:35, Sebastian Pop wrote:
>> With this patch we avoid instantiating ADDR_EXPR: it makes no sense
>> to translate b[i] into b[{0, +, 1}_1].
>>
>
> This should have been &b[i] and &b[{0, +, 1}_1].
>
> Ok for trunk?
O
Hello Roman,
> This patch should be applied only after pending patches by Revital. This
patch
> significantly enhances the existing implementation of the SMS. Patch
adds
> support of scheduling loops without doloop pattern. The loop should meet
the
> following requirements.
Thanks for the patch
Hi,
The first patch of this set:
Fix PR47653: do not handle loops using wrapping semantics in graphite
follows the recommendation from Tobias:
> As a first step to make Graphite correct, I would just bail out if
> overflows can occur.
Not handling induction variables of unsigned types has some
2011-07-23 Sebastian Pop
* tree-data-ref.c (max_stmt_executions_tree): Do not call
lang_hooks.types.type_for_size.
---
gcc/ChangeLog |5 +
gcc/tree-data-ref.c |5 -
2 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/gcc/ChangeLog b/gcc/ChangeLo
2011-07-23 Sebastian Pop
PR middle-end/47653
* graphite-scop-detection.c (graphite_can_represent_loop): Discard
loops using wrapping semantics.
* gcc.dg/graphite/run-id-pr47653.c: New.
* gcc.dg/graphite/interchange-3.c: Do not use unsigned types for
Hi Roman,
> While building a data dependency graph for loop a ddg edge for some pair
> of instructions with inter-loop dependency should be created only if
> there is no edge for intra-loop dependency between these instructions.
> Creating both of edges leads sometimes to the fact that function
I
2011-07-23 Sebastian Pop
* tree-ssa-loop-manip.c (canonicalize_loop_ivs): Build an unsigned
iv only when the largest type is unsigned. Do not call
lang_hooks.types.type_for_size.
* testsuite/libgomp.graphite/force-parallel-1.c: Un-xfail.
* testsuite/lib
Hi Bernd,
I tried building a tic6x-elf toolchain today from the FSF mainline
sources, but "make all-gcc" fails with:
make[1]: *** No rule to make target
`/work/sources/gcc/current/gcc/common/config/c6x/c6x-common.c', needed by
`c6x-common.o'. Stop.
Could you fix this please ?
Cheers
45 matches
Mail list logo
