Tested on SPARC/Solaris, applied on the mainline and 4.7 branch.
2012-06-01 Eric Botcazou
PR ada/53517
* gnat.dg/lto14.adb: Skip on Solaris.
--
Eric Botcazou
Index: gnat.dg/lto14.adb
===
--- gnat.dg/lto14.adb (
On 05/29/2012 09:05 PM, Joseph S. Myers wrote:
> On Tue, 29 May 2012, Christian Bruel wrote:
>
>> So I tested the following semantics, with the ones that you pointed.
>
> Thanks for the testing. The patch is OK with the ChangeLog conflict
> markers removed (and the dates on log entries updated
Hi,
This patch adds 4 flags to enable user to type in a list of name
patterns. Compiler will match the function name with the given
patterns, and add "hot", "cold", "likely_hot", "likely_cold"
attributes to function declaration. The static branch prediction
checks if a basic block contains call to
> Hi,
>
> the first patch mainly introduces access methods to read parts of jump
> functions. I am no particular fan of these but the are now more
> widely spread than originally and above all checking asserts verifying
> that the correct part of the union is read should really be useful.
>
> I
> The issue is that fold_plusminus_mult re-writes the multiplication
> from unsigned to signed for the failing testcase, introducing
> undefined overflow.
fold_plusminus_mult or fold_binary? My understanding is that the problem is
fold_binary incorrectly stripping the outer signedness conversion
On Fri, 1 Jun 2012, Eric Botcazou wrote:
> > The issue is that fold_plusminus_mult re-writes the multiplication
> > from unsigned to signed for the failing testcase, introducing
> > undefined overflow.
>
> fold_plusminus_mult or fold_binary? My understanding is that the problem is
> fold_binary
Hi,
This patch replaces instances of sprintf with snprintf with sizeof(..) in
the AArch64 port.
It also fixes layout issues in the code it touches.
Thanks
Sofiane
-
ChangeLog
2012-06-01 Sofiane Naci
[AArch64] Replace sprintf with snprintf.
* config/aarch64/aarch
Hi,
This patch re-factors TLS dialect option selection in the AArch64 port to
use the generic support for enumerated option arguments.
Thanks
Sofiane
-
2012-06-01 Sofiane Naci
[AArch64] Use Enums for TLS option selection.
* config/aarch64/aarch64-opts.h (enum aarch64_tls
On 05/29/2012 06:00 PM, Florian Weimer wrote:
This patch flags operator new on variably modified types as an error.
If this is acceptable, this will simplify the implementation of the
C++11 requirement to throw std::bad_array_new_length instead of
allocating a memory region which is too short.
On Thu, May 31, 2012 at 6:48 PM, Steven Bosscher wrote:
> Hello,
>
> A smaller patch this time, but bigger impact: GIMPLE_H does not have
> to depend on TARGET_H. Only a few files need TARGET_H as well as
> GIMPLE_H, and most of them already included TARGET_H anyway. The ones
> that don't, are fix
On Thu, May 31, 2012 at 9:21 PM, Diego Novillo wrote:
> On 12-05-31 14:57 , Steven Bosscher wrote:
>>
>> Hello,
>>
>> Almost all files include output.h because it defines dump_file. IMHO
>> output.h should only be included in files that actually output
>> something to asm_out_file. Therefore wante
On Thu, 31 May 2012, Jason Merrill wrote:
> The comment mentions PCH in connection with deferred seting of
> DECL_ASSEMBLER_NAME; off the top of my head it occurs to me that that might be
> connected with anonymous unions, which need to have different linkage names in
> different translation units
Yet another new feature in 4.7, committed
Johann
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.7/changes.html,v
retrieving revision 1.108
diff -u -p -r1.108 changes.html
--- changes.html21 Apr 2012 00:00:20
On Fri, Jun 1, 2012 at 6:02 AM, Andrew Pinski
wrote:
> Hi,
> When I modified GCC to change the majority of bitfield accesses
> which were done via component ref to BIT_FIELD_REF, SRA messes up
> because when it does the replacement it still tries to use the
> BIT_FIELD_REF except it never places
For the record, Gaby approved this change (thanks, Gaby,) but his mail
didn't show up in the archives (gmail likes to send HTML mail, which
the GCC lists reject.)
On 1 June 2012 05:22, Gabriel Dos Reis wrote:
> Ok.
> So, what case do you see disabled where there is no sign conversion
> involved?
For the Ada testcase I attached, in fold_binary_loc we have:
(gdb) p debug_tree(op0)
unit size
align 64 symtab 0 alias set -1 canonical type 0x76fdd0a8 precision
64 min max >
readonly
On Fri, 1 Jun 2012, Eric Botcazou wrote:
> > So, what case do you see disabled where there is no sign conversion
> > involved?
>
> For the Ada testcase I attached, in fold_binary_loc we have:
>
> (gdb) p debug_tree(op0)
> type size
> unit size
> align 64 symtab 0
> Ah, I see. So the proper fix would be to use STRIP_NOP()ed op0/op1,
> something not readily available though.
Why not just add
TYPE_UNSIGNED (TREE_TYPE (op0)) == TYPE_UNSIGNED (TREE_TYPE (arg0))
&& TYPE_UNSIGNED (TREE_TYPE (op1)) == TYPE_UNSIGNED (TREE_TYPE (arg1))
with a small comment?
On Fri, 1 Jun 2012, Eric Botcazou wrote:
> > Ah, I see. So the proper fix would be to use STRIP_NOP()ed op0/op1,
> > something not readily available though.
>
> Why not just add
>
> TYPE_UNSIGNED (TREE_TYPE (op0)) == TYPE_UNSIGNED (TREE_TYPE (arg0))
> && TYPE_UNSIGNED (TREE_TYPE (op1)) == T
On 12/5/23 1:46 AM, Richard Henderson wrote:
> On 05/18/12 03:48, Chung-Lin Tang wrote:
>> @@ -2401,6 +2401,7 @@ scan_trace (dw_trace_info *trace)
>> {
>>/* Propagate across fallthru edges. */
>>dwarf2out_flush_queued_reg_saves ();
>> + def_cfa_1 (&this_cfa);
>>ma
> Well, it would rather be
>
> TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
> && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))
>
> but only in the !FLOAT_TYPE_P path.
That works in all cases I think, see existing cases in the folder.
> We could even compare
> TYPE_OVER
On Fri, 1 Jun 2012, Eric Botcazou wrote:
> > Well, it would rather be
> >
> > TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg0))
> > && TYPE_UNSIGNED (type) == TYPE_UNSIGNED (TREE_TYPE (arg1))
> >
> > but only in the !FLOAT_TYPE_P path.
>
> That works in all cases I think, see existing
I forgot to send this to the libstdc++ list the first time.
This patch evaluates _FORTIFY_SOURCE in a way similar to GNU libc.
If set, std::vector::operator[] throws if the index is out of bounds.
This is compliant with the standard because such usage triggers
undefined behavior. _FORTIFY_SOURCE
On Fri, Jun 1, 2012 at 2:02 AM, Martin Jambor wrote:
> Hi,
>
> this patch adds the capability to build aggregate jump functions.
> These consist of:
>
> 1) information what known compile time IPA-invariants are at various
> offsets of an aggregate passed to a callee either by reference
> (when
On Fri, Jun 01, 2012 at 01:00:46PM +0200, Florian Weimer wrote:
> I forgot to send this to the libstdc++ list the first time.
>
> This patch evaluates _FORTIFY_SOURCE in a way similar to GNU libc.
> If set, std::vector::operator[] throws if the index is out of bounds.
> This is compliant with the
This fixes an oversight.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2012-06-01 Richard Guenther
* tree-loop-distribution.c (stmt_has_scalar_dependences_outside_loop):
Handle PHIs.
(classify_partition): Likewise.
Index: gcc/tree-loop-distr
Hi
a bunch of minor comments, first:
1- What happens with make check-debug? I suppose the debug-mode checks
trigger before the check in normal code, and the testcase doesn't pass.
Maybe for this kind of work you need a // { dg-require-normal-mode "" }
2- Something sound weird with debug-mode wh
Hi,
On Fri, Jun 01, 2012 at 11:31:20AM +0200, Richard Guenther wrote:
> On Fri, Jun 1, 2012 at 6:02 AM, Andrew Pinski
> wrote:
> > Hi,
> > When I modified GCC to change the majority of bitfield accesses
> > which were done via component ref to BIT_FIELD_REF, SRA messes up
> > because when it doe
On 31 May 2012 19:18, Paul Brook wrote:
> > Testing:
> > * Crossbuild for target arm-none-eabi with cpu cortex-a9 neon softfp
> and
> > tested in three configuration: -marm (default), -mthumb, -mapcs-
> frame. No
> > regression on qemu.
> > * Crossbuild for target arm-none-eabi thumb2 with cpu cor
On 06/01/2012 11:00 AM, Florian Weimer wrote:
I'll try to warn about this case and make the transformation to the
proper operator new[] call.
Here's the version. I've added a warning for the ill-formed code.
The only remaining glitch is in g++.dg/cpp0x/regress/debug-debug7.C,
specifically (
Hi,
this is my last and best try ;) Seriously, compared to the last posted
version:
1- I added a rather large comment explaining what's going on wrt error
recovery.
2- Took the occasion to clean-up a bit the code about bool vs int for
flags (we had a mix).
3- Cleaned-up a bit the code itself (
On 06/01/2012 01:42 PM, Paolo Carlini wrote:
Hi
a bunch of minor comments, first:
1- What happens with make check-debug? I suppose the debug-mode checks
trigger before the check in normal code, and the testcase doesn't pass.
Maybe for this kind of work you need a // { dg-require-normal-mode "" }
As someone who wrote code that does such allocations, I'm surprised that this
is a GNU extension, and is rejected even by the C++11 standard. How is one
supposed to perform allocations of two-dimensional arrays when inner dimension
is given as function argument?
I'm relatively inexperienced, but
Hi,
On 06/01/2012 02:53 PM, Florian Weimer wrote:
I've seen the variable, but I don't understand how to use it. I would
like to add something about it to the testing documentation.
Just copy what *all* the other testcase in the library testsuite have,
just define it, with attribute unused. If
Oleg Endo wrote:
> The attached patch addresses PR 53512.
> Tested with
> make all-gcc
> make info dvi pdf
>
> Previous default behavior for SH4A:
> make check-gcc RUNTESTFLAGS="sh.exp=sh4a-sincosf*
> --target_board=sh-sim/-m4a-single/-ml"
>
> check-gcc RUNTESTFLAGS="sh.exp=sh4a-fsrra*
> --targ
On 06/01/2012 03:09 PM, Paolo Carlini wrote:
You are right, sorry, I went through your changes too quickly and
didn't realize that you are just using the existing _M_range_check.
Anyway, I confirm that probably we want something more consistent with
debug-mode, thus not throwing in this case. M
On 06/01/2012 02:09 PM, Paolo Carlini wrote:
>>> 4- Maybe I'm misremembering, sorry in case, but Isn't:
>>>
>>> #if defined _FORTIFY_SOURCE && _FORTIFY_SOURCE > 0
>>>
>>> the same as:
>>>
>>> #if _FORTIFY_SOURCE > 0
>>>
>>> ?
>>
>> I think you're right, but I'm just copying literally what GNU libc
In response to a comment from
http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01721.html, this patch removes
t-softfp-sfdf and t-softfp-excl from the aarch64 entries in libgcc/config.host.
Every setting in these files is overridden by t-softfp.
Addition to libgcc/ChangeLog:
2012-06-01 Jim MacA
On Fri, Jun 01, 2012 at 03:09:19PM +0200, Paolo Carlini wrote:
> On 06/01/2012 02:53 PM, Florian Weimer wrote:
> >I've seen the variable, but I don't understand how to use it. I
> >would like to add something about it to the testing documentation.
> Just copy what *all* the other testcase in the l
On 06/01/2012 03:22 PM, Pedro Alves wrote:
The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is
not defined.
Interesting, but does it happen in system headers too?
Paolo.
On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO if
this is presented as _FORTIFY_SOURCE check, it should call that and
not some other function.
I understand. I don't know much about -D_FORTIFY_SOURCE, honestly. I
hope the diagnosti
On Tue, May 29, 2012 at 12:01 PM, Igor Zamyatin wrote:
> Hi, Uros!
>
> Sorry, I didn't realize that patch was missed. I attached new version.
>
> Changelog:
>
> 2012-05-29 Yuri Rumyantsev
>
> * config/i386/i386.c (x86_sched_reorder): New function.
> Added new function x86_sched_reor
On Fri, Jun 01, 2012 at 03:39:12PM +0200, Paolo Carlini wrote:
> On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
> >The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
> >if this is presented as _FORTIFY_SOURCE check, it should call that
> >and not some other function.
> I understand. I
Hi,
On 06/01/2012 03:49 PM, Jakub Jelinek wrote:
On Fri, Jun 01, 2012 at 03:39:12PM +0200, Paolo Carlini wrote:
On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
if this is presented as _FORTIFY_SOURCE check, it should call that
and
On Fri, Jun 01, 2012 at 03:52:24PM +0200, Paolo Carlini wrote:
> On 06/01/2012 03:49 PM, Jakub Jelinek wrote:
> >On Fri, Jun 01, 2012 at 03:39:12PM +0200, Paolo Carlini wrote:
> >>On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
> >>>The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
>
On 06/01/2012 02:36 PM, Paolo Carlini wrote:
> On 06/01/2012 03:22 PM, Pedro Alves wrote:
>> The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is not
>> defined.
> Interesting, but does it happen in system headers too?
Good point. I just tried and it doesn't.
--
Pedro Alves
On Fri, Jun 01, 2012 at 03:11:51PM +0100, Pedro Alves wrote:
> On 06/01/2012 02:36 PM, Paolo Carlini wrote:
>
> > On 06/01/2012 03:22 PM, Pedro Alves wrote:
> >> The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is not
> >> defined.
> > Interesting, but does it happen in system
On 06/01/2012 04:04 PM, Jakub Jelinek wrote:
Well, you have the core file often (unless disabled), or could use
addr2line to decode the addresses. The point is that the fortification
checks must be very lightweight (so that people can enable them by
default for everything), and e.g. storing __L
On 06/01/2012 04:13 PM, Jakub Jelinek wrote:
On Fri, Jun 01, 2012 at 03:11:51PM +0100, Pedro Alves wrote:
On 06/01/2012 02:36 PM, Paolo Carlini wrote:
On 06/01/2012 03:22 PM, Pedro Alves wrote:
The shorter version triggers an -Wundef warning if _FORTIFY_SOURCE is not
defined.
Interesting, b
Register-pressure sensitive scheduling decreased greatly probability
of a long standing bug when 1st insn scheduling may result in reload
pass failure of finding a hard reg for a reload. Still the bug is present.
The following patch adds hard-reg splitting to LRA which should
finally solv
On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
if this is presented as _FORTIFY_SOURCE check, it should call that
and not some other function. You'd need to use
#if __USE_FORTIFY_LEVEL> 0
test instead (as __chk_fail is only provid
On 06/01/2012 05:00 PM, Florian Weimer wrote:
On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
if this is presented as _FORTIFY_SOURCE check, it should call that
and not some other function. You'd need to use
#if __USE_FORTIFY_LEVEL
On Fri, Jun 01, 2012 at 05:00:58PM +0200, Florian Weimer wrote:
> On 06/01/2012 03:34 PM, Jakub Jelinek wrote:
> >The standard -D_FORTIFY_SOURCE failure is __chk_fail (), so IMNSHO
> >if this is presented as _FORTIFY_SOURCE check, it should call that
> >and not some other function. You'd need to u
OK.
Jason
On 06/01/12 01:22, Tobias Burnus wrote:
gcc/gimple.h: In function 'block_in_transaction':
gcc/gimple.h:1596:20: warning: overflow in implicit constant conversion
[-Woverflow]
return bb->flags & BB_IN_TRANSACTION;
^
Is this still the case with the code currently in mainline:
return flag_tm &
On 06/01/2012 05:09 PM, Jakub Jelinek wrote:
__chk_fail it is, then. This means that the test case will be
specific to GNU libc platforms. How can I mark it as such?
{ target *-*-linux* } or so?
Wouldn't this match Bionic libc environments, too?
Note, __chk_fail () isn't prototyped in gli
On 06/01/2012 05:22 AM, Richard Guenther wrote:
On Thu, 31 May 2012, Jason Merrill wrote:
The comment mentions PCH in connection with deferred seting of
DECL_ASSEMBLER_NAME; off the top of my head it occurs to me that that might be
connected with anonymous unions, which need to have different l
On 06/01/2012 08:09 AM, Florian Weimer wrote:
The only remaining glitch is in g++.dg/cpp0x/regress/debug-debug7.C,
specifically (b is not a constant):
int (*x)[b] = new int[a][b];// { dg-error "not usable" }
The new warning I've added fires on this line, too. How can I check for
the pen
On 06/01/2012 05:37 PM, Jason Merrill wrote:
On 06/01/2012 08:09 AM, Florian Weimer wrote:
The only remaining glitch is in g++.dg/cpp0x/regress/debug-debug7.C,
specifically (b is not a constant):
int (*x)[b] = new int[a][b]; // { dg-error "not usable" }
The new warning I've added fires on this
Steven Bosscher writes:
> On Thu, May 31, 2012 at 11:15 PM, David Miller wrote:
>>
>> Removing output.h from reload1.c broke the sparc build because
>> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
>> reload1.c) references current_function_is_leaf.
>
> I was afraid of some fall-
On 06/01/12 10:11, Aldy Hernandez wrote:
On 06/01/12 01:22, Tobias Burnus wrote:
gcc/gimple.h: In function 'block_in_transaction':
gcc/gimple.h:1596:20: warning: overflow in implicit constant conversion
[-Woverflow]
return bb->flags & BB_IN_TRANSACTION;
^
Is this still the case with the code
On 06/01/2012 11:40 AM, Florian Weimer wrote:
I'm puzzled why build_new is even invoked after detecting that there is
a non-constant expression.
I'd accept a patch to change that.
Jason
This fixes a glitch introduced by me with rev 187581.
Committing as obvious.
2012-07-01 Olivier Hainque
* config/rs6000/vxworks.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Restore
the "do {" part of the do-while(0) loop.
vxoverride.diff
Description: Binary data
On Fri, Jun 1, 2012 at 1:26 AM, Dehao Chen wrote:
> Hi,
>
> This patch adds 4 flags to enable user to type in a list of name
> patterns. Compiler will match the function name with the given
> patterns, and add "hot", "cold", "likely_hot", "likely_cold"
> attributes to function declaration. The sta
Freescale would like to contribute these patches to gcc.
It enables gcc for the new Freescale 64 bit cores. It creates a pipeline
description, and set proper default flags for the e5500 and e6500 cores.
Some Altivec extensions for e6500 will be submitted as a separate process.
The patch was reg
Hi all,
In libgfortran/intrinsics/time_1.h:181, there is a typo that refers to
user_usecs (should be user_usec). This patch fixes it. I don't have
commit access, so someone please apply this for me. It should be obvious.
Robert Mason
diff --git a/libgfortran/intrinsics/time_1.h b/libgfor
> 2012-07-01 Olivier Hainque
>
> * config/rs6000/vxworks.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Restore
> the "do {" part of the do-while(0) loop.
This is needed on the 4.7 branch as well.
--
Eric Botcazou
> Sorry, I didn't realize that patch was missed. I attached new version.
>
> Changelog:
>
> 2012-05-29 Yuri Rumyantsev
>
>* config/i386/i386.c (x86_sched_reorder): New function.
>Added new function x86_sched_reorder.
Reading it, you get the impression that the new function is un
From: Rainer Orth
Date: Fri, 01 Jun 2012 18:01:45 +0200
> Steven Bosscher writes:
>
>> On Thu, May 31, 2012 at 11:15 PM, David Miller wrote:
>>>
>>> Removing output.h from reload1.c broke the sparc build because
>>> sparc's define of INITIAL_ELIMINATION_OFFSET (which is used in
>>> reload1.c)
The enclosed patch updates the earlier patch to address all of the feedback I
have gotten regarding generating pubnames. It fixes the offset problem in
the pubtypes table; switches DW_AT_pubtypes to a flag and so on.
It also adds and documents a new option "-g[no-]pubtypes" which allows users
to g
In 4.7, this is one bug: we are doing a push_to_top_level to instantiate
the lambda, and then not pushing back into the function scope that the
lambda belongs to. Fixed by following the lead of synthesize_method and
only doing push_function_context if we're dealing with a local class.
On the
Back when we added C++11 auto deduction, I thought we could shortcut the
normal deduction in some templates, when the type is adequately
describable (thus the late, unlamented function describable_type). Over
time various problems with this have arisen, of which this is the most
recent; as a r
Hi everyone,
These fixes are to allow building on vxWorks. Currently there are two
issues:
1. VxWorks does not have a variadic open - it must receive three
arguments. gcc/gcov.c however opens a file for reading and does not
pass in a mode argument, which causes an error on vxWorks. This
On 06/01/2012 02:40 PM, rbmj wrote:
Hi everyone,
These fixes are to allow building on vxWorks. Currently there are two
issues:
1. VxWorks does not have a variadic open - it must receive three
arguments. gcc/gcov.c however opens a file for reading and does not
pass in a mode argument, whi
ping?
On Thu, May 31, 2012 at 4:02 PM, Doug Kwan wrote:
> Hi Diego,
>
> This is a backport of this patch to fix an ICE on PowerPC64.
>
> http://gcc.gnu.org/ml/gcc-patches/2011-03/msg00829.html
>
> -Doug
>
>
> 2012-05-31 Doug Kwan
>
> Backport r171031 from upstream trunk i
On 06/01/2012 06:19 PM, Jason Merrill wrote:
On 06/01/2012 11:40 AM, Florian Weimer wrote:
I'm puzzled why build_new is even invoked after detecting that there is
a non-constant expression.
I'd accept a patch to change that.
I don't really now what I'm doing here. But I noticed that in
cp_
On 12-05-31 19:02 , Doug Kwan wrote:
2012-05-31 Doug Kwan
Backport r171031 from upstream trunk in gcc/.
2011-03-16 Alan Modra
PR target/45844
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address):
Don't create invalid off
This patch works around a subtlety in the way weak references to
symbols defined in archives are handled by the linker. This is an
issue because google binaries are using weak references to detect
whether the libgcov.a version contains the new __gcov_reset and
__gcov_dump interfaces. Since they are
When parsing a new-expression, we first try to parse a new-placement
before the type. In this case, the tokens don't make a valid
expression, but we were still trying to parse [n] as a
lambda-introducer. Fixed by bailing out of cp_parser_binary_expression
sooner if we encounter a parse error
Ok with better naming for the dummy function such as
'__gcov_dummy_ref1'. Another choice is to let __gcov_flush calls
__gcov_dump + __gcov_reset -- but the dump_completed state needs to be
saved and restored.
David
http://codereview.appspot.com/6276043/
This patch is for the google/gcc-4_6 branch.
Import pending patch from upstream to generate DW_AT_high_pc as a constant
offset relative to DW_AT_low_pc. When splitting DWARF info, generate new
format for location list entries using a start symbol and a length.
Together, these changes reduce the s
Renamed to __gcov_dummy_ref1 and __gcov_dummy_ref2. I'd prefer that
approach for now to keep the differences with trunk to a minimum.
Thanks,
Teresa
On Fri, Jun 1, 2012 at 2:18 PM, wrote:
> Ok with better naming for the dummy function such as
> '__gcov_dummy_ref1'. Another choice is to let __gc
ok.
thanks,
David
On Fri, Jun 1, 2012 at 2:26 PM, Teresa Johnson wrote:
> Renamed to __gcov_dummy_ref1 and __gcov_dummy_ref2. I'd prefer that
> approach for now to keep the differences with trunk to a minimum.
>
> Thanks,
> Teresa
>
> On Fri, Jun 1, 2012 at 2:18 PM, wrote:
>> Ok with better n
After finding yet another bug in the previous patch dealing with pretty-printing
decls for dwarf in canonical form, I have figured out a way to do it that is
less invasive and much cleaner.
This updated patch simply wraps the two entry points into the decl pretty-
printer called from cxx_dwarf_nam
On Fri, Jun 1, 2012 at 6:07 PM, Sterling Augustine
wrote:
> After finding yet another bug in the previous patch dealing with
> pretty-printing
> decls for dwarf in canonical form, I have figured out a way to do it that is
> less invasive and much cleaner.
>
> This updated patch simply wraps the t
This patch is for the google/gcc-4_6 branch.
[Revised to fix an latent bug exposed by changes to the numbering of the
slots in .debug_addr. The location list comparison code had an assertion
that two otherwise equal location expressions would have the same opcode
sizes, but that's not always true
Reviewers: davidxl, xur, bjanakiraman_google.com,
Message:
A trunk version of this patch is already under review. I'm creating this
CL in order to get this patch in before the branch date.
Please review this at http://codereview.appspot.com/6273045/
Affected files:
M gcc/ChangeLog.googl
The change in 4.7 to properly restrict visibility of a class based on
its template arguments exposed this bug: we were waiting until after the
base list is parsed to apply attributes, so if a class is used as a
template argument in its own base list, it has the wrong visibility in
that context.
On Jun 1, 2012, at 19:09 , Eric Botcazou wrote:
>> * config/rs6000/vxworks.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Restore
>> the "do {" part of the do-while(0) loop.
>
> This is needed on the 4.7 branch as well.
Hmm, I don't think so. The removal was part of the E500
related reorg, whic
89 matches
Mail list logo
