FX wrote:
This patch fixes PR 52559 (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52559),
which was due to my earlier patch for displaying error loci in lines containing
wide characters (http://gcc.gnu.org/ml/fortran/2012-03/msg00015.html).
In preexisting code, a tab is displayed as a single sp
> It could be the case that an alternate, legitimate representation of the
> same expression is used elsewhere, and at the point that goes into
> cselib, the previously debug-only entry should become a regular entry in
> the cselib table.
>
> Is this what you observe?
Sure, that's what I've been s
Hi,
This is an updated version of the QImode displacement addressing patch
from the PR that applies to rev 185405. Tested on sh-sim with no new
failures.
The issue as a whole requires some more work and I'd like to split it in
smaller incremental changes and separate patches.
Cheers,
Oleg
Cha
> currently sizetype precision (cf store-layout.c:initialize_sizetypes) is
> the same as size_t. This is an issue on VMS, where size_t is 'unsigned
> int', but we'd like to have a 64 bit sizetype for Ada. My understanding is
> that ISO-C doesn't require size_t precision to match the one of void *.
> The middle-end of course would not care much what you use for sizetype.
> But be warned - if the mode for sizetype is different of ptr_mode things
> are going to be interesting for you (yes, ptr_mode, not Pmode).
That worked well up to GCC 4.6 though, at least in Ada. Of course using the
same
On Mar 19, 2012, at 9:46 AM, Eric Botcazou wrote:
>> The middle-end of course would not care much what you use for sizetype.
>> But be warned - if the mode for sizetype is different of ptr_mode things
>> are going to be interesting for you (yes, ptr_mode, not Pmode).
>
> That worked well up to G
Oleg Endo wrote:
> This is an updated version of the QImode displacement addressing patch
> from the PR that applies to rev 185405. Tested on sh-sim with no new
> failures.
>
> The issue as a whole requires some more work and I'd like to split it in
> smaller incremental changes and separate pat
> I am lost here. Which targets (with ptr_mode size != Pmode size !=
> sizetype size) are you referring to ?
Targets for which sizetype mode isn't necessarily equal to ptr_mode like VMS.
Up to GCC 4.6, sizetype was Pmode in Ada, but ptr_mode in C.
--
Eric Botcazou
On Mon, 19 Mar 2012, Eric Botcazou wrote:
> > I am lost here. Which targets (with ptr_mode size != Pmode size !=
> > sizetype size) are you referring to ?
>
> Targets for which sizetype mode isn't necessarily equal to ptr_mode like VMS.
> Up to GCC 4.6, sizetype was Pmode in Ada, but ptr_mode in
On Mar 19, 2012, at 10:41 AM, Eric Botcazou wrote:
>> I am lost here. Which targets (with ptr_mode size != Pmode size !=
>> sizetype size) are you referring to ?
>
> Targets for which sizetype mode isn't necessarily equal to ptr_mode like VMS.
VMS was (in gcc < 4.8) configured with POINTER_SIZ
> It does make sense to give the target control over the mode used for
> sizetype. Of course a global change of the default (for example to
> use Pmode as Ada did) will require testing each affected target,
> so I think it makes sense to keep the default as-is.
No disagreement here.
> Btw, we st
> But it's only ever computed for RECORD_TYPEs where DECL_QUALIFIER is
> unused.
OK, that could work indeed.
> For now giving up seems to be easiest (just give up when
> DECL_FIELD_OFFSET is not equal for all of the bitfield members).
> That will at most get you the miscompiles for the PRs back,
On Mon, 19 Mar 2012, Eric Botcazou wrote:
> > It does make sense to give the target control over the mode used for
> > sizetype. Of course a global change of the default (for example to
> > use Pmode as Ada did) will require testing each affected target,
> > so I think it makes sense to keep the
http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00641.html
Georg-Johann Lay wrote:
> The problem with the PR is that lower-subreg.c happily splits multi-byte moves
> from address spaces without knowing anything about the additional costs this
> is
> causing.
>
> The TARGET_MODE_DEPENDENT_ADDRESS_P
> No, about the disagreement of the precision of ptrdiff_t and that
> of sizetype. See c-common.c:pointer_int_sum:
>
> /* Convert the integer argument to a type the same size as sizetype
> so the multiply won't overflow spuriously. */
> if (TYPE_PRECISION (TREE_TYPE (intop)) != TYPE_PREC
On Mon, 19 Mar 2012, Eric Botcazou wrote:
> > No, about the disagreement of the precision of ptrdiff_t and that
> > of sizetype. See c-common.c:pointer_int_sum:
> >
> > /* Convert the integer argument to a type the same size as sizetype
> > so the multiply won't overflow spuriously. */
>
2012/3/19 Georg-Johann Lay :
> http://gcc.gnu.org/ml/gcc-patches/2012-03/msg00641.html
>
> Georg-Johann Lay wrote:
>> The problem with the PR is that lower-subreg.c happily splits multi-byte
>> moves
>> from address spaces without knowing anything about the additional costs this
>> is
>> causing.
On Mar 16, 2012, at 12:38 PM, Richard Guenther wrote:
[…]
> Well, this setup is not well supported by the middle-end (and indeed m32c
> has existing issues with that). So in your case decoupling sizetype from
> size_t sounds like the more appropriate solution.
>
>>> Btw, while we are transition
Hi,
around line 380, we have in tree.def:
/* References to storage. */
/* The ordering of the following codes is optimized for the classification
in handled_component_p. Keep them in a consecutive group. */
The hitch is that VIEW_CONVERT_EXPR is far apart from the others, so the patch
pu
On Mon, Mar 19, 2012 at 1:21 PM, Eric Botcazou wrote:
> Hi,
>
> around line 380, we have in tree.def:
>
> /* References to storage. */
>
> /* The ordering of the following codes is optimized for the classification
> in handled_component_p. Keep them in a consecutive group. */
>
> The hitch is
On 03/16/2012 06:16 PM, Jonathan Wakely wrote:
2012/3/16 Paweł Sikora:
Should the addition be \$$ to escape it for the shell as well as for make?
(I know it works, but that might not be true for all shells.)
i don't think that $, could be expaneded by any shell.
I'm not worried about it not ex
On Mon, Mar 19, 2012 at 1:02 PM, Tristan Gingold wrote:
>
> On Mar 16, 2012, at 12:38 PM, Richard Guenther wrote:
> […]
>
>> Well, this setup is not well supported by the middle-end (and indeed m32c
>> has existing issues with that). So in your case decoupling sizetype from
>> size_t sounds like
Hello!
This patch uses Pmode consistently for some remaining cases.
No functional change.
2012-03-19 Uros Bizjak
* config/i386/i386.c (ix86_expand_prologue) : Use Pmode
mode consistently. Use ix86_gen_add3. Assert that Pmode == DImode.
(ix86_expand_split_stack_prolo
On Mon, 19 Mar 2012, Eric Botcazou wrote:
> > But it's only ever computed for RECORD_TYPEs where DECL_QUALIFIER is
> > unused.
>
> OK, that could work indeed.
>
> > For now giving up seems to be easiest (just give up when
> > DECL_FIELD_OFFSET is not equal for all of the bitfield members).
> > T
On 03/18/2012 11:32 AM, Paolo Carlini wrote:
+ if ((TREE_CODE (type) == REFERENCE_TYPE
+ && lvalue_p (expr)
+ && same_type_p (TREE_TYPE (expr), TREE_TYPE (type)))
+ || same_type_p (TREE_TYPE (expr), type))
+ warning (OPT_Wuseless_cast, "useless cast to type %qT",
On 03/19/2012 02:17 PM, Jason Merrill wrote:
On 03/18/2012 11:32 AM, Paolo Carlini wrote:
+ if ((TREE_CODE (type) == REFERENCE_TYPE
+ && lvalue_p (expr)
+ && same_type_p (TREE_TYPE (expr), TREE_TYPE (type)))
+ || same_type_p (TREE_TYPE (expr), type))
+warning (OPT_Wuseless_cast,
Ping.
On 08/03/12 15:48, Andrew Stubbs wrote:
On 17/02/12 15:30, Andrew Stubbs wrote:
I've got a full test run going again.
OK for 4.8, again?
The test run revealed some bugs handling MINUS.
This update has been tested and passes a bootstrap and test with no
regressions. Indeed, it has actu
On 16/03/12 01:41, Michael Hope wrote:
> Hi there.
>
> This patch backports my PCH on ARM EABI fix[1] for pch/PR45979 to the 4.6
> branch. This
> fixes PCH support on ARM and tidies up the random pch testsuite failures that
> are seen
> between runs.
>
> OK for 4.6?
>
OK.
R.
> -- Michael
>
On 08/03/12 15:48, Andrew Stubbs wrote:
> On 17/02/12 15:30, Andrew Stubbs wrote:
>> I've got a full test run going again.
>>
>> OK for 4.8, again?
>
> The test run revealed some bugs handling MINUS.
>
> This update has been tested and passes a bootstrap and test with no
> regressions. Indeed, i
OK.
Jason
> Ok. I think volatilep should be always set as well.
Thanks. No strong opinion, but at least one caller (fold_truthop through
decode_field_reference) calls the function 4 times in a row and only checks
volatilep at the end to disable the transformation.
--
Eric Botcazou
We have the unfortunate situation that expand may leave us with
unreachable blocks that are required by proper rtl_eh functioning
(unreachable landing-pads, that is). This is bad for any verification
pass the pass manager may want to call that requires dominators to
be computed (I'm thinking of v
On Mar 19, 2012, at 1:36 PM, Richard Guenther wrote:
> On Mon, Mar 19, 2012 at 1:02 PM, Tristan Gingold wrote:
>>
>> On Mar 16, 2012, at 12:38 PM, Richard Guenther wrote:
>> […]
>>
>>> Well, this setup is not well supported by the middle-end (and indeed m32c
>>> has existing issues with that).
On Sun, Mar 18, 2012 at 1:55 PM, Uros Bizjak wrote:
> On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>
>>> I am testing this patch. OK for trunk if it passes all tests?
>>
>> No, force_reg will generate a pseudo, so this conversion is valid only
>> for !can_create_pseudo ().
>>
>> At least
On Mon, Mar 19, 2012 at 8:51 AM, H.J. Lu wrote:
> On Sun, Mar 18, 2012 at 1:55 PM, Uros Bizjak wrote:
>> On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>>
I am testing this patch. OK for trunk if it passes all tests?
>>>
>>> No, force_reg will generate a pseudo, so this conversion is
>
> We have the unfortunate situation that expand may leave us with
> unreachable blocks that are required by proper rtl_eh functioning
> (unreachable landing-pads, that is). This is bad for any verification
> pass the pass manager may want to call that requires dominators to
> be computed (I'm t
On Mon, 19 Mar 2012, Jan Hubicka wrote:
> >
> > We have the unfortunate situation that expand may leave us with
> > unreachable blocks that are required by proper rtl_eh functioning
> > (unreachable landing-pads, that is). This is bad for any verification
> > pass the pass manager may want to ca
On Sun, Mar 18, 2012 at 3:17 PM, Gerald Pfeifer wrote:
> On Wed, 14 Mar 2012, H.J. Lu wrote:
>>> Apart from the above, at least invoke.texi does not define what an x32
>>> environment is. Shouldn't that done somewhere (before this terminology
>>> is used)?
>> I am not sure where to put it. In an
On Mon, Mar 19, 2012 at 4:41 PM, Richard Guenther wrote:
> Comments?
What does rtl_eh do for no-SJLJ exceptions?
Have you tested with SJLJ exceptions? (Can/should we move that code to GIMPLE?)
Ciao!
Steven
Hello,
now that the apply_distributive_law change is in, I'd like to pick up
Richard's original patch, see discussion here:
http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00852.html
The version below integrates all requests for changes that were raised.
It's been part of Linaro GCC releases in this
On Mon, 19 Mar 2012, Steven Bosscher wrote:
> On Mon, Mar 19, 2012 at 4:41 PM, Richard Guenther wrote:
> > Comments?
>
> What does rtl_eh do for no-SJLJ exceptions?
Quoting from except.c
'Then, via finish_eh_generation, we generate the real landing pads
to which the runtime will actually tr
On Thu, Mar 15, 2012 at 12:02 PM, Tom Tromey wrote:
>> "DJ" == DJ Delorie writes:
>
> Tom> Finally, there is already stuff in libiberty not related to
> Tom> portability. E.g., hashtab or the demangler.
>
> DJ> Yeah, I know, hence my "Should I give up that premise?"
>
> Yeah.
>
> I am not su
On 16/03/12 13:29, EXTERNAL Waechtler Peter (Fa. TCP, CM-AI/PJ-CF31) wrote:
The CodeSourcery toolchain contains a "fix" like the following,
please consider for adding it.
Here's the full original patch with ChangeLog.
I don't know why Dan never submitted this one. Perhaps it's not suitable
fo
> But given the pushback for even one new library, I think we're
> unnecessarily slowing ourselves down.
I'm not opposed to libiberty becoming the kitchen sink, if that's what
people want. If it does go that route, my reason for being a
libiberty maintainer no longer applies, and others who are
On Mon, Mar 19, 2012 at 8:54 AM, H.J. Lu wrote:
> On Mon, Mar 19, 2012 at 8:51 AM, H.J. Lu wrote:
>> On Sun, Mar 18, 2012 at 1:55 PM, Uros Bizjak wrote:
>>> On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>>>
> I am testing this patch. OK for trunk if it passes all tests?
No,
This patch adds code to detect a particular form of expansion produced by the
build-in-place machinery for the allocation of a private limited indefinite
type where the full view lacks discriminants. The allocator appears as a
qualified expression containing a build-in-place call. The patch prevent
For an object of a class-wide interface type, the object declaration is
rewritten as a renaming with a new entity, and debug info was not being
generated for the renaming, preventing printing of the object's value
in gdb. The entity of the renaming is now marked as needing debug info.
Tested on x8
It may be useful to have trivial postconditions of "True" or "False" on some
subprograms. The first is essentially a confirming postcondition, while the
second indicates that a procedure will not return (if postconditions are
checked). Do not emit warnings on such postconditions. Similarly for Ensu
Il 19/03/2012 17:07, Ulrich Weigand ha scritto:
> Hello,
>
> now that the apply_distributive_law change is in, I'd like to pick up
> Richard's original patch, see discussion here:
> http://gcc.gnu.org/ml/gcc-patches/2011-09/msg00852.html
>
> The version below integrates all requests for changes t
On Mon, Mar 19, 2012 at 9:19 AM, H.J. Lu wrote:
> On Mon, Mar 19, 2012 at 8:54 AM, H.J. Lu wrote:
>> On Mon, Mar 19, 2012 at 8:51 AM, H.J. Lu wrote:
>>> On Sun, Mar 18, 2012 at 1:55 PM, Uros Bizjak wrote:
On Sun, Mar 18, 2012 at 5:01 PM, Uros Bizjak wrote:
>> I am testing this pa
On Mon, Mar 19, 2012 at 5:34 PM, H.J. Lu wrote:
>>> Combine failed:
>>>
>>> (set (reg:QI 63 [ c ])
>>> (mem/c:QI (plus:DI (zero_extend:DI (unspec:SI [
>>> (const_int 0 [0])
>>> ] UNSPEC_TP))
>>> (mem/u/c:DI (const:DI (unspec:DI [
>>>
On Mon, Mar 19, 2012 at 12:12 PM, Andrew Stubbs wrote:
> On 16/03/12 13:29, EXTERNAL Waechtler Peter (Fa. TCP, CM-AI/PJ-CF31) wrote:
>>
>> The CodeSourcery toolchain contains a "fix" like the following,
>> please consider for adding it.
>
>
> Here's the full original patch with ChangeLog.
>
> I do
This patch ensures that gnatmake no longer crashes when there are -m
switches after -cargs and after -margs on the command line.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-03-19 Vincent Celier
* make.adb (Scan_Make_Arg): Make sure all significant -m switches
on the
This patch gives better error recovery and message for a ** b ** c
1. package ParenExp is
2.a : Integer := 2 ** 3 ** 4;
|
>>> parenthesization required for **
3. end;
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-03-19 Robert Dewa
This is the initial checkin to establish the framework for this new
attribute which will check subcomponents of composite objects. No
test yet, since the implementation is not there yet!
Tested on x86_64-pc-linux-gnu, committed on trunk
2012-03-19 Robert Dewar
* exp_attr.adb, sem_attr
This patch causes the scanner to recognize preprocessor directives
in the case where the preprocessor is in active, and give better
messages, as shown by this example compiled with -gnatld7 -gnatj60.
1. package Preproc is
2. #if JUNK then
|
>>> preprocessor directive igno
This framework was implemented years ago, but never documented,
and no optimizer was ever implemented, so best just to remove it
at this stage. If anyone ever wants to implement a high level
optimizer, the least of the effort will be putting this back.
Note that the critical point (which is that re
This patch provides a debug switch -gnatd.N that has the effect of
enlarging entities in the compiler by one node. The addition node
is not used, but this can be used to evaluate the impact of adding
a node. No test, since no external effect.
Tested on x86_64-pc-linux-gnu, committed on trunk
2012
Hi,
On Mon, 19 Mar 2012, Steven Bosscher wrote:
> On Mon, Mar 19, 2012 at 4:41 PM, Richard Guenther wrote:
> > Comments?
>
> What does rtl_eh do for no-SJLJ exceptions?
Emitting the landing pad code (copy-out from EH_RETURN_DATA_REGNO, or
target specific code) and redirecting edges to that on
On Mon, Mar 19, 2012 at 9:37 AM, Uros Bizjak wrote:
> On Mon, Mar 19, 2012 at 5:34 PM, H.J. Lu wrote:
>
Combine failed:
(set (reg:QI 63 [ c ])
(mem/c:QI (plus:DI (zero_extend:DI (unspec:SI [
(const_int 0 [0])
] UNSPEC_TP))
On Mon, Mar 19, 2012 at 5:19 PM, H.J. Lu wrote:
> movl %fs:0, %eax
> movq c@gottpoff(%rip), %rdx
> movzbl (%rax,%rdx), %edx
> movb %dl, y(%rip)
> movq w@gottpoff(%rip), %rdx
> movzwl (%rax,%rdx), %eax
> movw %ax, i(%rip)
> r
On Mon, Mar 19, 2012 at 5:47 PM, H.J. Lu wrote:
> For x32, thread pointer is an unsigned 32bit value.
>
> movl %fs:0, %eax
>
> is the correct instruction to load thread pointer into EAX and RAX.
So, where is ZERO_EXTEND RTX then?
Uros.
On Mon, Mar 19, 2012 at 9:49 AM, Uros Bizjak wrote:
> On Mon, Mar 19, 2012 at 5:47 PM, H.J. Lu wrote:
>
>> For x32, thread pointer is an unsigned 32bit value.
>>
>> movl %fs:0, %eax
>>
>> is the correct instruction to load thread pointer into EAX and RAX.
>
> So, where is ZERO_EXTEND RTX then?
>
> On Mon, 19 Mar 2012, Steven Bosscher wrote:
>
> > On Mon, Mar 19, 2012 at 4:41 PM, Richard Guenther wrote:
> > > Comments?
> >
> > What does rtl_eh do for no-SJLJ exceptions?
>
> Quoting from except.c
>
> 'Then, via finish_eh_generation, we generate the real landing pads
>to which the ru
On Mon, Mar 19, 2012 at 5:55 PM, H.J. Lu wrote:
>>> For x32, thread pointer is an unsigned 32bit value.
>>>
>>> movl %fs:0, %eax
>>>
>>> is the correct instruction to load thread pointer into EAX and RAX.
>>
>> So, where is ZERO_EXTEND RTX then?
>>
>
> Thread pointer (TP) is an opaque value to G
> On Mon, Mar 19, 2012 at 12:12 PM, Andrew Stubbs
> wrote:
> > On 16/03/12 13:29, EXTERNAL Waechtler Peter (Fa. TCP,
> CM-AI/PJ-CF31) wrote:
> >>
> >> The CodeSourcery toolchain contains a "fix" like the following,
> >> please consider for adding it.
> >
> >
> > Here's the full original patch with
> "DJ" == DJ Delorie writes:
DJ> The only drawback to adding toplevel libraries is coordinating changes
DJ> among the toplevel configury.
And adding crud to Makefiles all over.
Pick a name for the new library and I will implement this.
Tom
On Mar 9, 2012, at 10:46 AM, Georg-Johann Lay wrote:
> The problem with the PR is that lower-subreg.c happily splits multi-byte moves
> from address spaces without knowing anything about the additional costs this
> is
> causing.
Nasty, arm hit this sort of problem recently as well, and I've hit t
On Mon, Mar 19, 2012 at 6:01 PM, Uros Bizjak wrote:
For x32, thread pointer is an unsigned 32bit value.
movl %fs:0, %eax
is the correct instruction to load thread pointer into EAX and RAX.
>>>
>>> So, where is ZERO_EXTEND RTX then?
>>>
>>
>> Thread pointer (TP) is an opaq
> while I have your attention: what is an virtual unwind frame? ;)
No such thing exists.
Throwing an exception is a muti-stage process. It requires unwinding the
stack frame twice, taking different actions in the process. "Forced"
unwinding and backtracing add extra complications. The _US_*
Bernhard Reutner-Fischer writes:
> On Thu, Mar 15, 2012 at 08:35:47PM +0100, Jakub Jelinek wrote:
>>On Thu, Mar 15, 2012 at 05:56:32PM +0100, Bernhard Reutner-Fischer wrote:
>>> On Thu, Mar 15, 2012 at 04:57:12PM +0100, Richard Guenther wrote:
>>> >On Thu, Mar 15, 2012 at 1:39 PM, Bernhard Reutne
On 03/19/2012 03:59 PM, Jason Merrill wrote:
OK.
Thanks. I committed the patch. I'm going to add, as obvious, the
following few additional tests, which my previous iteration got wrong.
Paolo.
//
2012-03-19 Paolo Carlini
* g++.dg/warn/Wuseless-cast.C: Extend.
Ind
On Mon, Mar 19, 2012 at 10:29 AM, Uros Bizjak wrote:
> On Mon, Mar 19, 2012 at 6:01 PM, Uros Bizjak wrote:
> For x32, thread pointer is an unsigned 32bit value.
>
> movl %fs:0, %eax
>
> is the correct instruction to load thread pointer into EAX and RAX.
So, where is
The following patch discourages usage of BP, R12, and R13 as it results
in larger addresses on x86/x86-64.
Committed as rev. 185533.
2012-03-19 Vladimir Makarov
* config/i386/i386.c (ix86_register_bank): Add special treatment
for BP, R12, and R13.
Index: config/i386/i386.c
On Mon, Mar 19, 2012 at 6:50 PM, H.J. Lu wrote:
>>> Please test my proposed patch. If it works OK, I will commit it to SVN.
>>
>> The onyl acceptable way is to generate ZERO_EXTEND in place, so:
>>
>> --cut here--
>> static rtx
>> get_thread_pointer (enum machine_mode tp_mode, bool to_reg)
>> {
>
Add support to re-play actions on types as well as symbols.
When declaring class types, the parser calls finish_struct_methods to perform
things like sorting the method vector for the class. This needs
to be done at reading time, because the sorting is done based on
the pointer values of the entr
This patch renames pph_symtab, pph_symtab_entry and pph_symtab_action into
pph_replay* to better reflects the semantics of this table.
No functional changes, just a rename.
2012-03-19 Diego Novillo
* pph-streamer.h (struct pph_replay_entry): Rename from
pph_symtab_entry.
this removes the pb_ds fails exposed by this patch.
-benjamin2012-03-19 Benjamin Kosnik
* include/ext/pb_ds/detail/pat_trie_/
constructors_destructor_fn_imps.hpp: Increment after recursion.
* include/ext/pb_ds/detail/pat_trie_/pat_trie_base.hpp: Convert
node_type markup fr
This breaks constructors on pretty much every elf+newlib target,
because newlib and gcc both use HAVE_INITFINI_ARRAY (and have for many
years) but the tests don't match. GCC puts ctors in .ctors but libgcc
is built without support for them (newlib's generated config headers
define HAVE_INITFINI_A
Hello!
This patch just substitutes "copy_to_mode_reg (Pmode, ...)" with
copy_addr_to_reg function where appropriate.
2012-03-19 Uros Bizjak
* builtins.c (expand_builtin_cexpi): Use copy_addr_to_reg instead of
copy_to_mode_reg (Pmode, ...).
(expand_builtin_frame_address
On Mon, Mar 19, 2012 at 1:34 PM, DJ Delorie wrote:
>
> This breaks constructors on pretty much every elf+newlib target,
> because newlib and gcc both use HAVE_INITFINI_ARRAY (and have for many
> years) but the tests don't match. GCC puts ctors in .ctors but libgcc
> is built without support for t
Sweet! Thanks! We hadn't merged that bit into our tree yet...
On 19.03.2012 18:32, Paul Brook wrote:
while I have your attention: what is an virtual unwind frame? ;)
No such thing exists.
Throwing an exception is a muti-stage process. It requires unwinding the
stack frame twice, taking different actions in the process. "Forced"
unwinding and backtracing
On Fri, 16 Mar 2012 11:10:48 +0100
Richard Guenther wrote:
> On Fri, Mar 16, 2012 at 1:29 AM, Jonathan Wakely
> wrote:
> > On 15 March 2012 15:40, Richard Guenther wrote:
> >> On Thu, Mar 15, 2012 at 4:22 PM, Kai Tietz
> >> wrote:
> >>> Richard,
> >>>
> >>> ping. I think now could be a good ti
Mike Stump writes:
>> If we're going to remove the assert, we need to define stuff like
>> that.
>
> Orthogonal. The rest of the compiler defines what happens, it either
> is inconsistent, in which case it is by fiat, undefined, or it is
> consistent, in which case that consistency defines it. T
Hello!
No functional change.
2012-03-19 Uros Bizjak
* config/i386/i386.md (allocate_stack): Simplify.
Tested on x86_64-pc-linux-gnu, committed to mainline SVN.
Uros.
Index: i386/i386.md
===
--- i386/i386.md(revi
On Mon, Mar 19, 2012 at 9:09 AM, Doug Evans wrote:
> On Thu, Mar 15, 2012 at 12:02 PM, Tom Tromey wrote:
>>> "DJ" == DJ Delorie writes:
>>
>> Tom> Finally, there is already stuff in libiberty not related to
>> Tom> portability. E.g., hashtab or the demangler.
>>
>> DJ> Yeah, I know, hence m
On Mar 19, 2012, at 2:44 PM, Richard Sandiford wrote:
> Mike Stump writes:
>>> If we're going to remove the assert, we need to define stuff like
>>> that.
>>
>> Orthogonal. The rest of the compiler defines what happens, it either
>> is inconsistent, in which case it is by fiat, undefined, or it
On Mar 19, 2012, at 3:00 PM, Oleg Endo wrote:
> The attached patch adapts SH machine description to the braced string
> notation.
Nice. My only comment would be, I think that { should start indented. I know
quite a few ports start in column 0, but... I think they are all wrong.
(define_insn
Oleg Endo wrote:
> The attached patch adapts SH machine description to the braced string
> notation. This eliminates the need to have escaped strings-in-strings
> and hopefully makes the whole thing a bit easier to read.
>
> Tested by 'make all-gcc' and cross-compiling newlib.
>
> OK?
OK.
Reg
Hello Everyone,
This patch is for the Cilkplus and Cilkplus-4_7-branch affecting mainly the C
compiler. it will fix a crash when a default vector length or processor name is
not given.
Thanks,
Balaji V. Iyer.
diff --git a/gcc/ChangeLog.cilk b/gcc/ChangeLog.cilk
index b2d90e0..35f052f 100644
-
This is for the google/gcc-4_6 branch only.
This revised patch fixes several problems with -gfission:
- Bad index for range list in the compile unit DIE.
- DW_AT_ranges attribute for compile unit in the wrong file.
- Incorrect size for skeleton type unit DIEs.
- Wrote location expression using
92 matches
Mail list logo
