I found this suspicious looking line in cp/parser.c () while looking at
__thread and thread_local.
Look at the patterns of the if blocks above the line in question to verify.
Built and tested on x86_64-linux.
Ed
2012-11-11 Ed Smith-Rowland <3dw...@verizon.net>
* parser.c (cp_parser
I've checked in this patch to consistently use "bit-field" in
extend.texi instead of "bitfield" or "bit field". "Bit-field" is listed
in the GCC Coding Conventions as the preferred terminology, for
consistency with the C and C++ standards.
-Sandra
2012-11-10 Sandra Loosemore
gcc
I've checked in this patch to fix various problems with hyphenated
phrases in extend.texi. This exactly parallels similar copy edits I
made earlier this year to invoke.texi. To recap, in phrases like
"64-bit types", "64-bit" is a compound adjective phrase that immediately
precedes a noun and
As mentioned in http://gcc.gnu.org/wiki/Cxx11AbiCompatibility, C++11
changes the return type of complex::real and imag, leading to a binary
incompatibility between C++98 and C++11 code if the functions are used
without inlining. This patch adds an ABI tag to the C++11 variants so
that they hav
The demangler change was handling the tags in the wrong place; I'm
writing them out with unqualified names, so the demangler should expect
them in the same place.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 75eef303e5494f27a6d9bbef68aaf3200978a8f1
Author: Jason Merrill
Date: Sat No
This patch continues my series of copy-edits to the GCC user
documentation. Here I've fixed a number of problems in extend.texi with
confusion between "which" and "that", as I previously did for invoke.texi.
Committed as obvious since there are no changes to content, just grammar.
-Sandra
2
Hello,
This is another ICE in pre_and_rev_post_order_compute, called from
alias.c after register allocation.
The problem is that purge_all_dead_edges can make basic blocks
unreachable. Before my patch of r190602, alias.c handled unreachable
blocks (resulting in missed disambiguations). Now that a
On Sat, Nov 10, 2012 at 3:00 PM, Thomas Koenig wrote:
> I wrote:
>
>> after the dicsussion on c.l.f, it become clear that passing a DO loop
>> variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error.
>> The attached patch throws an error for both cases.
But should we really isse an
On Sat, Nov 10, 2012 at 10:38:55AM -0800, H.J. Lu wrote:
> On Sat, Nov 10, 2012 at 6:41 AM, Paolo Bonzini wrote:
> > Il 10/11/2012 07:44, H.J. Lu ha scritto:
> >> Hi,
> >>
> >> In
> >>
> >> (insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
> >> (mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A
This patch fixes a bug comparing struct field types in the reflect
package. Bootstrapped and ran Go testsuite on x86_64-unknown-linux-gnu.
Committed to mainline and 4.7 branch.
Ian
diff -r 8b1f2a35ded1 libgo/go/reflect/type.go
--- a/libgo/go/reflect/type.go Tue Nov 06 10:44:51 2012 -0800
+++ b/l
On Sat, Nov 10, 2012 at 3:43 AM, Uros Bizjak wrote:
> Hello!
>
> Attached patch disparages riF->o alternative of *movti_internal_rex64
> insn, as described by Vlad in comment #2 [1]
>
> The core of the problem however is, that gcc is unable to detect
> zero-extended address as offsetable. H.J. wil
Tobias Burnus wrote:
I spoke too early. With the updated patch, there is no ICE, but one
crashes for the following valid program with:
But with my original patch, it works.
To recap: My "if (gsi_end_p (i)) break;" (cf. [1]) fixes my original
issue (ICE for fail31.ii; [1]) and gives the correc
On Sat, Nov 10, 2012 at 6:41 AM, Paolo Bonzini wrote:
> Il 10/11/2012 07:44, H.J. Lu ha scritto:
>> Hi,
>>
>> In
>>
>> (insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
>> (mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
>> {*movti_internal_rex64}
>> (expr_list:REG_DEAD (r
On Sat, Nov 10, 2012 at 6:46 AM, Paolo Bonzini wrote:
> Il 10/11/2012 05:30, Andrew Pinski ha scritto:
>> Hi,
>> The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not
>> the final installed binary name. This patch fixes the problem by
>> changing if we got ld-new to just ld.
>> N
> Tested as described in the covering note. OK to install?
>
> Richard
>
>
> gcc/
> * expmed.c (narrow_bit_field_mem): New function.
> (store_bit_field_using_insv, store_bit_field_1, store_fixed_bit_field)
> (extract_bit_field_1): Use it.
This looks better now, thanks.
--
E
> Tested as described in the covering note. OK to install?
>
> Richard
>
>
> gcc/
> * expr.h (adjust_address_1): Add a size parameter.
> (adjust_address, adjust_address_nv, adjust_bitfield_address)
> (adjust_bitfield_address_nv): Adjust accordingly.
> (adjust_bitfield_ad
> Tested as described in the covering note. OK to install?
>
> Richard
>
> gcc/
> * combine.c (make_extraction): Handle TRUNCATEd INNERs.
OK, thanks.
--
Eric Botcazou
---
You've been invited by Claudiu Zissulescu to use Google Talk.
If you already have a Google account, login to Gmail and accept this chat
invitation:
http://mail.google.com/mail/b-6d05ada042-4af1bd6b15-UsxLYA8higFMiMVCCKbLIKrPP
In the patch I installed for PR rtl-optimization/54315:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg00745.html
the special code dealing with BLKmode in registers at the beginning of
store_field is disabled for CALL_EXPR:
/* If we are storing into an unaligned field of an aligned union that i
On Fri, 9 Nov 2012 22:51:45 +0530, Siddhesh wrote:
> I had reckoned that the behaviour could be reverted to what was before
> while I figure out a way to get the warning in place for both cases,
> i.e. with tree-vrp (where max_loop_iterations now causes the loop to
> be folded away in -O2) and this
Tobias Burnus wrote:
So untested:
Thanks for the patch! It fixed the problem half way: It fixes the
second issue I had (fail10.ii,
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00791.html ).
However, it didn't fix the original problem: As the call for strlen
directly returns, it never reach
Il 10/11/2012 05:30, Andrew Pinski ha scritto:
> Hi,
> The problem here is that set PLUGIN_LD_SUFFIX to ld-new which is not
> the final installed binary name. This patch fixes the problem by
> changing if we got ld-new to just ld.
> Note this issue has been around since 4.6 but not many people t
Il 10/11/2012 07:44, H.J. Lu ha scritto:
> Hi,
>
> In
>
> (insn 19 17 20 2 (set (reg:TI 85 [ *_15 ])
> (mem:TI (zero_extend:DI (reg:SI 82)) [0 *_15+0 S16 A32])) x.i:29 61
> {*movti_internal_rex64}
> (expr_list:REG_DEAD (reg:SI 82)
> (expr_list:REG_EQUIV (mem/c:TI (plus:DI (r
A few more testsuite fixes to address failures on AIX. The only
really interesting one is g++.dg/other/anon5.C where Undefined is
capitalized in the AIX error message.
Thanks, David
* c-c++-common/scal-to-vec2.c: Ignore non-standard ABI message.
* c-c++-common/vector-compare-1.c:
On 9 November 2012 22:09, Jason Merrill wrote:
> Now that G++ uses the value of __cplusplus specified by the standard, we
> don't need the other macro anymore.
>
> OK for trunk, or should I save it for the next stage 1?
>
> Jason
I'd been thinking about suggesting that change just the other day -
I wrote:
after the dicsussion on c.l.f, it become clear that passing a DO loop
variable to an INTENT(OUT) or INTENT(INOUT) dummy argument is an error.
The attached patch throws an error for both cases.
I chose to issue the errors as a front-end pass because we cannot check
for formal arguments
Jakub Jelinek wrote:
--- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100
+++ gcc/asan.c 2012-11-09 21:26:00.0 +0100
@@ -1362,6 +1362,8 @@ transform_statements (void)
instrument_assignment (&i);
else if (is_gimple_call (s))
maybe_instrument_call (
Hello!
Attached patch disparages riF->o alternative of *movti_internal_rex64
insn, as described by Vlad in comment #2 [1]
The core of the problem however is, that gcc is unable to detect
zero-extended address as offsetable. H.J. will propose a patch for
this [2].
2012-11-10 Vladimir Makarov
On Fri, Nov 09, 2012 at 09:36:53PM +0100, Tobias Burnus wrote:
> * I still have to do an all-language bootstrap and regtesting,
> though the latter is probably pointless as there is currently not a
> single -fasan test case.
> --- gcc/asan.c.orig 2012-11-09 21:26:26.0 +0100
> +++ gcc/asa
Ed Smith-Rowland <3dw...@verizon.net> ha scritto:
>Paolo?
... carte blanche to Jason! (but I have a little lexer tweak pending... ;)
Paolo
30 matches
Mail list logo
