From: Hans-Peter Nilsson h...@axis.com
Date: Fri, 1 Jun 2012 07:58:13 +0200
- the gUSA atomic method in config/sh/sh.md is really cute, go
see it.
Doh, I mean config/sh/sync.md.
brgds, H-P
Aldy Hernandez wrote:
PR tree-optimization/52558
* cfg.c (alloc_aux_for_edge): Fix comment.
(alloc_aux_for_edge): Remove static.
* basic-block.h (alloc_aux_for_edge): Protoize.
* tree-ssa-loop-im.c (execute_sm_if_changed): New.
Tested on SPARC/Solaris, applied on the mainline and 4.7 branch.
2012-06-01 Eric Botcazou ebotca...@adacore.com
PR ada/53517
* gnat.dg/lto14.adb: Skip on Solaris.
--
Eric Botcazou
Index: gnat.dg/lto14.adb
===
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 a
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 have
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 sofiane.n...@arm.com
[AArch64] Replace sprintf with snprintf.
*
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 sofiane.n...@arm.com
[AArch64] Use Enums for TLS option selection.
*
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 stevenb@gmail.com 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
On Thu, May 31, 2012 at 9:21 PM, Diego Novillo dnovi...@google.com 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.
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
andrew.pin...@caviumnetworks.com 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
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)
nop_expr 0x7700c5a0
type integer_type 0x76fdd0a8 bitsizetype public unsigned sizetype DI
size integer_cst
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)
nop_expr 0x7700c5a0
type integer_type 0x76fdd0a8 bitsizetype public
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)) ==
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);
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
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 cases in the
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.
On Fri, Jun 1, 2012 at 2:02 AM, Martin Jambor mjam...@suse.cz 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
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 rguent...@suse.de
* tree-loop-distribution.c (stmt_has_scalar_dependences_outside_loop):
Handle PHIs.
(classify_partition): Likewise.
Index:
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
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
andrew.pin...@caviumnetworks.com 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
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 cortex-m3. No
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 oleg.e...@t-online.de 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*
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.
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 is doing.
I can change it to
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
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
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
On Tue, May 29, 2012 at 12:01 PM, Igor Zamyatin izamya...@gmail.com wrote:
Hi, Uros!
Sorry, I didn't realize that patch was missed. I attached new version.
Changelog:
2012-05-29 Yuri Rumyantsev yuri.s.rumyant...@intel.com
* config/i386/i386.c (x86_sched_reorder): New function.
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 don't
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
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
if this is
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 headers
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
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,
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
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
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 use
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
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
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
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 stevenb@gmail.com writes:
On Thu, May 31, 2012 at 11:15 PM, David Miller da...@davemloft.net 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
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 hain...@adacore.com
* config/rs6000/vxworks.h (SUBSUBTARGET_OVERRIDE_OPTIONS): Restore
the do { part of the do-while(0) loop.
vxoverride.diff
Description: Binary data
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
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
2012-07-01 Olivier Hainque hain...@adacore.com
* 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 yuri.s.rumyant...@intel.com
* config/i386/i386.c (x86_sched_reorder): New function.
Added new function x86_sched_reorder.
Reading it, you get the impression that
From: Rainer Orth r...@cebitec.uni-bielefeld.de
Date: Fri, 01 Jun 2012 18:01:45 +0200
Steven Bosscher stevenb@gmail.com writes:
On Thu, May 31, 2012 at 11:15 PM, David Miller da...@davemloft.net wrote:
Removing output.h from reload1.c broke the sparc build because
sparc's define of
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
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
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,
ping?
On Thu, May 31, 2012 at 4:02 PM, Doug Kwan dougk...@google.com 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 dougk...@google.com
Backport
On 12-05-31 19:02 , Doug Kwan wrote:
2012-05-31 Doug Kwandougk...@google.com
Backport r171031 from upstream trunk in gcc/.
2011-03-16 Alan Modraamo...@gmail.com
PR target/45844
* config/rs6000/rs6000.c (rs6000_legitimize_reload_address):
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
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
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, davi...@google.com wrote:
Ok with better naming for the dummy function such as
'__gcov_dummy_ref1'. Another
ok.
thanks,
David
On Fri, Jun 1, 2012 at 2:26 PM, Teresa Johnson tejohn...@google.com 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,
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
On Fri, Jun 1, 2012 at 6:07 PM, Sterling Augustine
saugust...@google.com 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
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
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
86 matches
Mail list logo
