On 10/09/2011 08:18 AM, Ian Lance Taylor wrote:
+#undef NATIVE_HEADER_HEADER_COMPONENT
+#define NATIVE_SYSTEM_HEADER_COMPONENT MINGW
Typo (I think), otherwise okay.
Paolo
Ayal Zaks ayal.z...@gmail.com writes:
The issue of assigning stages to reg-moves is mostly relevant for
prolog and epilog generation, which requires and receives special
attention -- handled very nicely by ps_num_consecutive_stages! Note
that currently a simple boolean indicator for (the
On Mon, Oct 10, 2011 at 7:02 PM, Gary Funck g...@intrepid.com wrote:
Recently, a few UPC test programs failed to compile
due to mis-matches of parameters in a prototype and its
corresponding function definition. The mis-match was
based upon the apparent inequality of UPC layout qualifiers
This is bit of code cleanup and move macro code from avr.h to functions in
avr.c.
There's no change in functionality. Passed without regressions.
Ok?
Johann
* config/avr/avr-protos.h (avr_mode_code_base_reg_class): New
prototype.
(avr_regno_mode_code_ok_for_base_p):
Unfortunately, the report was correct in that clang is producing incorrect
code and
abusing the higher bits of the class-info field to store some other
information.
The clang folks are pretty responsive. I'd always give them a chance to
`fix' thier code, before putting hack-arounds in
This series of 5 patches generate LDRD/STRD instead of POP/PUSH in
epilogue/prologue for ARM and Thumb-2 mode of A15.
Patch [1/5] introduces new field in tune which can be used to indicate
whether LDRD/STRD are preferred over POP/PUSH by the specific core.
Patches [2-5/5] use this field to
In fact, the integer constant was needed because it appeared
in the blocking factor hash table, but not via a direct pointer.
Rather it was referenced by nature of the fact that
the blocking factor hash table referenced the integer constant
that is mapped in the integer constant hash table.
Hi!
This patch adds new field in tune_params to indicate if LDRD/STRD are
preferred over PUSH/POP in prologue/epilogue of specific core.
It also creates new tune for cortex-A15 and updates tunes for other
cores to set new field to default value.
Changelog entry for Patch to create tune for
Hi!
This patch generates LDRD instead of POP for Thumb2 epilogue in A15.
For optimize_size, original epilogue is generated for A15.
The work involves defining new functions, predicates and patterns.
As LDRD cannot be generated for PC, if PC is in register-list, LDRD is
generated for all other
Hi!
This patch generates STRD instead of PUSH in prologue for A15 ARM mode.
For optimize_size, original prologue is generated for A15.
The work involves defining new functions, predicates and patterns, along
with minor changes in existing code:
* STRD in ARM mode needs consecutive registers to
Hi!
This patch generates LDRD instead of POP in epilogue for A15 ARM mode.
For optimize_size, original epilogue is generated for A15.
The work involves defining new functions, predicates and patterns.
In this patch we keep on accumulating non-consecutive registers till
register-pair to be
On Oct 11, 2011, at 2:05 AM, Nicola Pero wrote:
Unfortunately, the report was correct in that clang is producing incorrect
code and
abusing the higher bits of the class-info field to store some other
information.
The clang folks are pretty responsive. I'd always give them a chance to
Hi
Uros, you was right both with fpmath and configflags. That is why it
was passing for me.
Attached patch which cures the problem.
testsuite/ChangeLog entry:
2011-10-11 Kirill Yukhin kirill.yuk...@intel.com
* gcc.target/i386/fma_double_1.c: Add -mfpmath=sse.
*
On Tue, Oct 11, 2011 at 12:12 PM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Uros, you was right both with fpmath and configflags. That is why it
was passing for me.
Attached patch which cures the problem.
testsuite/ChangeLog entry:
2011-10-11 Kirill Yukhin kirill.yuk...@intel.com
Thank you!
K
On Tue, Oct 11, 2011 at 2:19 PM, Uros Bizjak ubiz...@gmail.com wrote:
On Tue, Oct 11, 2011 at 12:12 PM, Kirill Yukhin kirill.yuk...@gmail.com
wrote:
Uros, you was right both with fpmath and configflags. That is why it
was passing for me.
Attached patch which cures the
I'm not completely following this yet, so please bear with me...
On 10/09/11 10:01, Richard Sandiford wrote:
Reload 0: GR_REGS, RELOAD_FOR_OUTPUT_ADDRESS (opnum = 0), can't combine,
secondary_reload_p
reload_reg_rtx: (reg:SI 5 $5)
Reload 1: reload_out (SI) = (reg:SI 32 $f0 [1655])
On Mon, Oct 10, 2011 at 3:21 PM, Artem Shinkarov
artyom.shinkar...@gmail.com wrote:
On Mon, Oct 10, 2011 at 12:02 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Oct 7, 2011 at 9:44 AM, Artem Shinkarov
artyom.shinkar...@gmail.com wrote:
On Fri, Oct 7, 2011 at 6:22 AM, Artem
On 10/11/2011 03:04 AM, Jason Merrill wrote:
On 10/10/2011 12:40 PM, Paolo Carlini wrote:
+ // The fraction 643/2136 approximates log10(2) to 7 significant
digits.
+ int max_digits10 = 2 + (is_decimal ? fmt-p : fmt-p * 643L / 2136);
Please cite N1822 in the comment and convert it to C
Hi,
in the 20090223-1.c gcc complains about functions possibly not being
inlined although they have the always_inline attribute on it. The
original failure could only be observed with these functions being
inlined. The attached patch forces GCC to suppress the warning.
Committed to mainline.
On Sat, 8 Oct 2011, William J. Schmidt wrote:
Greetings,
Here are the revised changes for the tree portions of the patch. I've
attempted to resolve all comments to date on those portions. Per
Steven's comment, I moved copy_ref_info into tree-ssa-address.c; let me
know if there's a better
Since we have the alias oracle we no longer optimize the testcase below
because I initially restricted the stmt walking to give up for PHIs
with more than 2 arguments because of compile-time complexity issues.
But it's easy to see that compile-time is not an issue when we
reduce PHI args pairwise
Hi,
On Mon, 10 Oct 2011, Kai Tietz wrote:
To ensure that we use simple_operand_p in all cases, beside for
branching AND/OR chains, in same way as before, I added to this function
an additional argument, by which the looking into comparisons can be
activated.
Better make it a separate
Hi,
for this largish testcase (reduced from a big one by Jakub) we ICE due
to error reporting routines re-entered. In 4_6-branch the situation is
worse, because for the original testcase we don't produce any useful
diagnostics at all before ICEing.
Thus the below, which seems pretty
http://codereview.appspot.com/5247044/diff/1/gcc/cp/pph-streamer.h
File gcc/cp/pph-streamer.h (right):
http://codereview.appspot.com/5247044/diff/1/gcc/cp/pph-streamer.h#newcode165
gcc/cp/pph-streamer.h:165: struct pph_stream {
165 struct pph_stream {
You need the typedef. Stage 1 is still
Hi,
tested x86_64-linux, committed.
Paolo.
2011-10-11 Emil Wojak e...@wojak.eu
PR c++/50661
* include/bits/stl_algobase.h (equal): Compare arrays of pointers
too with memcmp.
Index: include/bits/stl_algobase.h
It isn't a standoff, we can choose to just fix the issue and be compatible,
if we want.
I guess you're right and I'm probably using the wrong word - English is not my
first language. ;-)
But I meant that they could have made the same choice to be compatible (by
fixing the issue
in their
Sandeep == Sandeep Soni soni.sande...@gmail.com writes:
Sandeep The following patch is a basic attempt to build a symbol table that
Sandeep stores the names of all the declarations made in the input file.
I don't know anything about gimplefe, but unless you have complicated
needs, it is more
So updated version for patch. It creates new simple_operand_p_2
function instead of modifying simple_operand_p function.
ChangeLog
2011-10-11 Kai Tietz kti...@redhat.com
* fold-const.c (simple_operand_p_2): New function.
(fold_truthop): Rename to
(fold_truth_andor_1):
Hi,
on s390 we need a backchain in order to implement
__builtin_return_address for arguments other than 0.
Committed to mainline.
Bye,
-Andreas-
2011-10-11 Andreas Krebbel andreas.kreb...@de.ibm.com
* gcc.dg/pr49994-3.c: Add -mbackchain for s390 and s390x.
Index:
Hi Richard,
Thanks for the comments -- a few responses below.
On Tue, 2011-10-11 at 13:40 +0200, Richard Guenther wrote:
On Sat, 8 Oct 2011, William J. Schmidt wrote:
snip
+ c4 = uhwi_to_double_int (bitpos / BITS_PER_UNIT);
You don't verify that bitpos % BITS_PER_UNIT is zero
2011/10/4 Richard Henderson r...@redhat.com:
On 10/04/2011 08:42 AM, Joseph S. Myers wrote:
On Tue, 4 Oct 2011, Ilya Tocar wrote:
Hi everyone,
This patch fixes PR 50038 (redundant zero extensions) by modifying
implicit-zee pass
to also remove unneeded zero extensions from QImode to SImode.
Hi,
On Tue, 11 Oct 2011, Kai Tietz wrote:
Better make it a separate function the first tests your new
conditions, and then calls simple_operand_p.
Well, either I make it a new function and call it instead of
simple_operand_p,
That's what I meant, yes.
@@ -5149,13 +5176,6 @@
That looks pretty good, but do you really need to build up a separate
data structure to search? You seem to be searching it in the same order
that it's built up, so why not just walk the expansion chain directly
when searching?
Jason
2011/10/11 Michael Matz m...@suse.de:
Hi,
On Tue, 11 Oct 2011, Kai Tietz wrote:
Better make it a separate function the first tests your new
conditions, and then calls simple_operand_p.
Well, either I make it a new function and call it instead of
simple_operand_p,
That's what I meant,
On Tue, 2011-10-11 at 09:12 -0500, William J. Schmidt wrote:
The pattern matching is still very ad-hoc and doesn't consider
statements that feed the base address. There is conceptually
no difference between p-a[n] and *(p + n * 4).
That's true. Since we abandoned the general
On 10/10/2011 03:59 PM, Fabien Chêne wrote:
Sorry but I've failed to see why you called them callers of
lookup_field_1, could you elaborate ?
Hmm, I was assuming that the other functions would have gotten their
decls via lookup_field_1, but I suppose that isn't true for unqualified
lookup
Hi,
On Tue, 11 Oct 2011, Kai Tietz wrote:
So updated version for patch. It creates new simple_operand_p_2
function instead of modifying simple_operand_p function.
FWIW: I also can't think of a nice short name for that predicate function
:) One thing: move the test for TREE_SIDE_EFFECTS to
This patch fixes PR 50565, a failure to accept certain offsetof-type
expressions in static initializers introduced by my constant
expressions changes. (These expressions are permitted but not
required by ISO C to be accepted; the intent of my constant
expressions model is that they should be
On 10/10/2011 03:56 PM, Fabien Chêne wrote:
It tried to add the target declaration of a USING_DECL in the
method_vec of the class where the USING_DECL is declared. Thus, I
copied the target decl, adjusted its access, and then called
add_method with the target decl.
Copying the decl is unlikely
On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote:
Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
approved by Jason last December but I never got around to checking
it in. Paolo Carlini said in PR44473 that it was already approved
and doesn't need a new approval, so I
On Tue, Oct 11, 2011 at 3:12 AM, Kirill Yukhin kirill.yuk...@gmail.com wrote:
Hi
Uros, you was right both with fpmath and configflags. That is why it
was passing for me.
Attached patch which cures the problem.
testsuite/ChangeLog entry:
2011-10-11 Kirill Yukhin kirill.yuk...@intel.com
2011/10/11 Georg-Johann Lay a...@gjlay.de:
This is bit of code cleanup and move macro code from avr.h to functions in
avr.c.
There's no change in functionality. Passed without regressions.
Ok?
Johann
* config/avr/avr-protos.h (avr_mode_code_base_reg_class): New
prototype.
2011/10/11 Georg-Johann Lay a...@gjlay.de:
This is a small addendum to PR50447.
It's a change to addsi3 insn; the actual insn sequence printed is still the
same (except for adding +/-1 to l-reg) but the effect on cc0 is worked out so
that it can be used to cancel out comparisons like in long
On 10/10/2011 06:23 PM, Joseph S. Myers wrote:
On Mon, 10 Oct 2011, Janis Johnson wrote:
This patch skips several Power-specific tests if hard_float support
isn't available. OK for trunk?
It looks like these are testing for particular instructions using FPRs and
so powerpc_fprs is more
On 10/11/2011 11:34 AM, Peter Bergner wrote:
On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote:
Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
approved by Jason last December but I never got around to checking
it in. Paolo Carlini said in PR44473 that it was already
On Tue, Oct 11, 2011 at 11:52 AM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Oct 10, 2011 at 3:21 PM, Artem Shinkarov
artyom.shinkar...@gmail.com wrote:
On Mon, Oct 10, 2011 at 12:02 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Fri, Oct 7, 2011 at 9:44 AM, Artem
On 10/11/2011 12:55 PM, Jason Merrill wrote:
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
Does it work to only complain if !cp_parser_parsing_tentatively?
I suppose not, if you got no
On Tue, 11 Oct 2011, Janis Johnson wrote:
On 10/10/2011 06:23 PM, Joseph S. Myers wrote:
On Mon, 10 Oct 2011, Janis Johnson wrote:
This patch skips several Power-specific tests if hard_float support
isn't available. OK for trunk?
It looks like these are testing for particular
On 10/11/11 10:24:52, Richard Guenther wrote:
GF: 1. Is it valid to assume that pointer equality is sufficient
GF: to compare two integer constants for equality as long as they
GF: have identical type and value?
Yes, if both constants are live
The upc blocking factor hash table is declared
Hi,
I checked in this patch to remove the extra break.
H.J.
---
Index: config/i386/i386.c
===
--- config/i386/i386.c (revision 179810)
+++ config/i386/i386.c (working copy)
@@ -28096,7 +28096,6 @@ ix86_expand_special_args_builtin
On Tue, 2011-10-11 at 12:12 -0400, Jason Merrill wrote:
On 10/11/2011 11:34 AM, Peter Bergner wrote:
On Fri, 2011-09-30 at 10:37 -0700, Janis Johnson wrote:
Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
approved by Jason last December but I never got around to checking
The problem in both of these PRs is that G++ has assumed that we don't
ever need to actually perform non-dependent conversions in a template;
once we know that the conversion can be performed, we just generated a
NOP_EXPR to change the type of the expression. But this isn't good
enough for
This patch fixes an error where Annotalysis generates bogus warnings
when using lock and unlock functions that are attached to a base class.
The canonicalize routine did not work correctly in this case.
Bootstrapped and passed gcc regression testsuite on
x86_64-unknown-linux-gnu. Okay for
On 10/10/2011 01:19 PM, Janis Johnson wrote:
Tests gcc.target/powerpc/warn-[12].c fail for soft-float multilibs with
the unexpected warning -mvsx requires hardware floating point [enabled
by default]. This patch skips those tests for soft-float multilibs and
modifies the powerpc check for a
How about .gnu.switches.text.quote_paths?
Sounds good to me.
-cary
* gcc.target/sparc/sparc.exp: Add vis3 target test.
This doesn't work. The code always compiles:
(botcazou@ob) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.10 $
gcc/xgcc -Bgcc -c -o vis.o vis.c
(botcazou@ob) /nile.build/botcazou/gcc-head/sparc-sun-solaris2.10 $ objdump -d
vis.o
This patch teaches avr-gcc to skip 2-word instructions like STS and LDS.
It's just about looking into an 2-word insn and check if it's a 2-word
instruction or not.
Passes without regression. Ok to install?
Johann
PR target/49939
* config/avr/avr.md (*movqi): Rename to
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
Does it work to only complain if !cp_parser_parsing_tentatively?
Jason
On 10/11/2011 02:19 PM, Jason Merrill wrote:
For the 4.6 branch I'm only making the change for scalars.
Tested x86_64-pc-linux-gnu, applying to trunk.
Er, to 4.6.
For the 4.6 branch I'm only making the change for scalars.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit d8978a333ab71a4ad2c38446764c1b37092ea098
Author: Jason Merrill ja...@redhat.com
Date: Mon Oct 3 17:06:02 2011 -0400
PR c++/49855
PR c++/49896
* call.c
From: Eric Botcazou ebotca...@adacore.com
Date: Tue, 11 Oct 2011 20:10:34 +0200
* gcc.target/sparc/sparc.exp: Add vis3 target test.
This doesn't work. The code always compiles:
What does gcc -mcpu=niagara3 -mvis give to you for the following
source file:
long long
This ICE is still a regression in 4.6, so I'm checking in this patch to
fix it. Note that after this patch, the code generated for new T[1]{}
is still wrong, but that isn't a regression. The value-initialization
semantics are fixed in 4.7.
Tested x86_64-pc-linux-gnu.
commit
What does gcc -mcpu=niagara3 -mvis give to you for the following
source file:
long long
_vis3_fpadd64 (long long __X, long long __Y)
{
return __builtin_vis_fpadd64 (__X, __Y);
}
Nothing at all, with or without the options.
That's what the sparc.exp
On Oct 11, 2011, at 11:08 AM, Janis Johnson wrote:
On 10/10/2011 01:19 PM, Janis Johnson wrote:
Tests gcc.target/powerpc/warn-[12].c fail for soft-float multilibs with
the unexpected warning -mvsx requires hardware floating point [enabled
by default]. This patch skips those tests for
Currently, the consistency check done on pre-processor symbols is
triggering on symbols that are not really problematic (e.g., symbols
used for double-include guards).
The problem is that in the testsuite, we are refusing to process PPH
images that fail that test, which means we don't get to
On Tue, Oct 11, 2011 at 4:40 AM, Richard Guenther rguent...@suse.de wrote:
this function misses to transfer TREE_THIS_NOTRAP which is supposed
to be set on the base of old_ref or any contained ARRAY[_RANGE]_REF.
If you make the function generic please adjust it to at least do ...
...
Cool, Eric could you quickly test the following? This still leaves
the i386.exp case issue open, it stands to reason that something like
-Wall is needed for those tests too.
I think that we should go the i386 way. This works on i386 because the
builtins are always available (when you pass
I committed this patch to mainline to remove an incorrect ChangeLog
entry (the gofrontend directory lives elsewhere; gcc/go/ChangeLog only
applies to the files in gcc/go outside of gcc/go/gofrontend) and to fix
spacing in a Go frontend file.
Ian
Index: gofrontend/gogo-tree.cc
On Mon, Oct 10, 2011 at 3:37 PM, Delesley Hutchins deles...@google.com wrote:
--- gcc/tree-threadsafe-analyze.c (revision 179771)
+++ gcc/tree-threadsafe-analyze.c (working copy)
@@ -1830,14 +1830,27 @@ remove_lock_from_lockset (tree lockable, struct po
This feels like a bug in
This is a regression present on mainline and 4.6/4.5 branch. We generate wrong
code for the movcc patterns if the operands of the comparison have TFmode and
TARGET_HARD_QUAD is not set, because we fail to update the comparison code
after going through the comparison routine.
Tested on
Ok, it has been committed to both the FSF 4.6 and 4.5 branches now.
The ChangeLog entry is in the wrong file, it must be moved to cp/ChangeLog.
--
Eric Botcazou
I realized this one hasn't made it in, but is really nice. I made a
number of minor edits (typos, markup, simplifying headings,... among
others). What do you think -- should we include this?
Many users still won't have GCC 4.6 deployed yet, so I think it's
still worth it.
What do
On Tue, 2011-10-11 at 23:34 +0200, Eric Botcazou wrote:
Ok, it has been committed to both the FSF 4.6 and 4.5 branches now.
The ChangeLog entry is in the wrong file, it must be moved to cp/ChangeLog.
Oops, thanks for catching that! Fixed now.
Peter
I see, so we can test the code generation in the testsuite even if the
compiler was built against an assembler without support for the
instructions.
At least partially, yes.
But in such a case, I'm unsure if I understand why i386.exp needs
these tests at all. The presence of support for a
On Wed, 21 Sep 2011, Joey Ye wrote:
Committed in ARM/embedded-4_6-branch.
2011-09-21 Jiangning Liu jiangning@arm.com
Tune loop unrolling for cortex-m
* config/arm/arm-cores.def (cortex-m0): Change to new tune
cortex_v6m.
(cortex-m1): Likewise.
*
On Tue, Oct 11, 2011 at 10:32 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
The problem comes down to an expression with the difference of two
pointers being cast to int on a 64-bit system, resulting in
convert_to_integer moving the conversions inside the subtraction.
(These
On Fri, Sep 30, 2011 at 5:22 PM, Roman Zhuykov zhr...@ispras.ru wrote:
2011/7/21 zhr...@ispras.ru:
This patch should be applied only after pending patches by Revital.
Ping. New version is attached, it suits current trunk without
additional patches.
Thanks for the ping.
Also this related
On 6 October 2011 18:52, Dr. David Alan Gilbert
david.gilb...@linaro.org wrote:
Micahel K. Edwards points out in PR/48126 that the sync is in the
wrong place
relative to the branch target of the compare, since the load could
float
up beyond the ldrex.
PR
On 6 October 2011 18:54, Dr. David Alan Gilbert
david.gilb...@linaro.org wrote:
Add ARM 64bit sync helpers for use on older ARMs. Based on 32bit
versions but with check for sufficiently new kernel version.
gcc/
* config/arm/linux-atomic-64bit.c: New (based on
Any objections to this version of the patch ?
Fine with me though I think it's worthwhile to have such comments
without -dA but that's my personal impression. I don't care either
way.
cheers
Ramana
Cheers
Nick
gcc/ChangeLog
2011-10-05 Nick Clifton ni...@redhat.com
*
On 6 October 2011 18:52, Dr. David Alan Gilbert
david.gilb...@linaro.org wrote:
Micahel K. Edwards points out in PR/48126 that the sync is in the
wrong place
relative to the branch target of the compare, since the load could
float
up beyond the ldrex.
PR
On 6 October 2011 18:53, Dr. David Alan Gilbert
david.gilb...@linaro.org wrote:
Add support for ARM 64bit sync intrinsics.
gcc/
* arm.c (arm_output_ldrex): Support ldrexd.
(arm_output_strex): Support strexd.
(arm_output_it): New helper to output it in
On 6 October 2011 18:54, Dr. David Alan Gilbert
david.gilb...@linaro.org wrote:
Test support for ARM 64bit sync intrinsics.
gcc/testsuite/
* gcc.dg/di-longlong64-sync-1.c: New test.
* gcc.dg/di-sync-multithread.c: New test.
*
-Original Message-
From: Hans-Peter Nilsson [mailto:h...@bitrange.com]
Sent: Wednesday, October 12, 2011 06:57
To: Joey Ye
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [arm-embedded] Tune loop unrolling for cortex-m
On Wed, 21 Sep 2011, Joey Ye wrote:
Committed in
On Oct 6, 2011, at 10:54 AM, Dr. David Alan Gilbert wrote:
Test support for ARM 64bit sync intrinsics.
Ok. Watch for any fallout on non-arm systems. I'd always invite people who
think they know the best way to test volatile to chime in. There is the new
infrastructure to test multi core
Attached is the new patch. Bootstrapped on x86_64, no regressions.
gcc/ChangeLog.google-4_6:
2011-10-08 Dehao Chen de...@google.com
Add a flag (-frecord-gcc-switches-in-elf) to record compiler
command line options to .gnu.switches.text sections of
the object file.
*
ok.
David
On Tue, Oct 11, 2011 at 9:51 PM, Dehao Chen de...@google.com wrote:
Attached is the new patch. Bootstrapped on x86_64, no regressions.
gcc/ChangeLog.google-4_6:
2011-10-08 Dehao Chen de...@google.com
Add a flag (-frecord-gcc-switches-in-elf) to record compiler
On 10/11/2011 12:57 PM, Jason Merrill wrote:
On 10/11/2011 12:55 PM, Jason Merrill wrote:
On 10/09/2011 07:19 PM, Ed Smith-Rowland wrote:
Does cp_parser_identifier (parser) *not* consume the identifier token?
I'm pretty sure it does.
It does.
Does it work to only complain if
2011/10/11 Jason Merrill ja...@redhat.com:
On 10/10/2011 03:56 PM, Fabien Chêne wrote:
It tried to add the target declaration of a USING_DECL in the
method_vec of the class where the USING_DECL is declared. Thus, I
copied the target decl, adjusted its access, and then called
add_method with
89 matches
Mail list logo
