On 06/02/2011 03:25 PM, David Krauss wrote:
Optimally the re-opened context would be the preceding operator-> function
itself, to create the illusion of nested calls. However, the result of
build_new_op may be a target_expr or a call_expr. I'm not sure of the best way to
recover the function
On 6 Jun 2011, at 21:23, IainS wrote:
It doesn't...
.. if you want to be pedantic the following should cover all bases
on a given platform > 10.4:
make -k check-objc check-obj-c++ RUNTESTFLAGS="--target_board=unix\{-
m32,-m32/-fabi-version=1,-m64\} "
duh.. I should check my typing befor
> ... So, how do you test with -m32 ? ...
make -k check-obj-c++ RUNTESTFLAGS="--target_board=unix'{-m32,-m64}'"
On x86_64-apple-darwin10 (Mac OS X 10.6) -m64 is the default and
could be omitted after the comma, but the above works also on ppc
for which the default is -m32.
> The revamped patch i
This part has been run through testing.
I need approval for cp/cxx-pretty-print.c tho
2011-06-07 Bruce Korb
* gcc/cp/cxx-pretty-print.c (pp_cxx_decl_specifier_seq):
Do not set case label inside an "else" clause.
* fixincludes/fixlib.h (tCC): remove these #defines
* fixincludes/fixincl.
On Jun 6, 2011, at 12:22 PM, Nicola Pero wrote:
> This patch fixes PR obj-c++/48275. It's a routine parser ingenuity.
>
> OK to commit ?
Ok.
On Jun 6, 2011, at 1:32 PM, Dominique Dhumieres wrote:
>> The revamped patch in attach should fix them. :-)
>
> It does, thanks,
Ok, Iain chimed in that he's ok with it going in sooner, and since -m32 now
works, I think this work can go in now, thanks. Thanks for the testing help
Dominique!
This patch adds incomplete parsing support for the LOCK and UNLOCK
statement. Missing part 2 is the addition of the LOCK_TYPE of the
ISO_FORTRAN_ENV.
Build and tested on x86-64-linux.
OK for the trunk?
Tobias
b/gcc/fortran/dump-parse-tree.c | 27 +++
b/gcc/fortran/frontend-
Removed all of the pth code with the exception of pth_save_token_cache
and pth_load_token_cache and their respective closure.
The renaming of the remaining functions to pph will be done in a separate patch.
The patch was tested with a full bootstrap build and regression testing.
Note: There mig
On Mon, Jun 6, 2011 at 18:08, Gabriel Charette wrote:
> Removed all of the pth code with the exception of pth_save_token_cache
> and pth_load_token_cache and their respective closure.
>
> The renaming of the remaining functions to pph will be done in a separate
> patch.
>
> The patch was tested w
On 6 Jun 2011, at 22:37, Mike Stump wrote:
On Jun 6, 2011, at 1:32 PM, Dominique Dhumieres wrote:
The revamped patch in attach should fix them. :-)
It does, thanks,
Ok, Iain chimed in that he's ok with it going in sooner, and since -
m32 now works, I think this work can go in now, thanks.
Hi,
I checked in this patch to rename config/i386/t-linuxx32 to
config/i386/t-linux-x32.
H.J.
commit 60e43edbb2ff0a35c9a7d8c6b0dd99944ad0a408
Author: H.J. Lu
Date: Mon Jun 6 18:02:47 2011 -0700
Rename config/i386/t-linuxx32 to config/i386/t-linux-x32.
diff --git a/gcc/ChangeLog.x32 b/gcc
On Tue, May 31, 2011 at 7:00 AM, William J. Schmidt
wrote:
> This patch removes the now-redundant support for pow and powi builtins
> in the expand phase. My concerns about -O0 regressions were unfounded.
> There are code gen differences for the unlikely combination of -O0 and
> -ffast-math, but
Revised and retested patch attached.
OK to commit?
--Douglas Rupp
2011-06-06 Douglas B Rupp
* fixincludes/configure.ac (host_makefile_frag): Use mh-interix.
* fixincludes/configure: Regenerate
* fixincludes/Makefile.in (FIXINC_CPPFLAGS): New flag macro.
(@ho
In the testcase, fold_indirect_ref_1 won't fold *(T*)(s1+10) to an
ARRAY_REF because T != unsigned. Even if it were just a typedef to
unsigned, that isn't close enough, but in this case it's a typedef to
const unsigned.
I'm not sure what the type coherence rules are for ARRAY_REF. Is it
rea
On Mon, 6 Jun 2011 09:14:20 +0100
Jonathan Wakely wrote some comment about my
http://gcc.gnu.org/ml/gcc-patches/2011-06/msg00357.html patch:
> I found this hard to read, particularly "using if needed a front-end
> specific subdirectory."
>
> Maybe "is loaded from the plugin directory, or one
On 06/06/11 17:27, Richard Earnshaw wrote:
Eh? This is backwards. There is blx , but no bl . If the assembler
gets confused with 'bl r0' then it needs to be fixed urgently.
Are you requiring the assembler be fixed before this patch can be committed
(without the '+'?)
nathan
--
Nathan Sidwe
On Jun 6, 2011, Jan Hubicka wrote:
>> On May 30, 2011, Alexandre Oliva wrote:
>> > Index: gcc/ipa-inline-analysis.c
> Well, clauses is a typical zero terminated array, so I really do think
> the warning is bogus.
Looking into it, I'm not sure it is. Compiling with -O3 I get:
ipa-inline-anal
Hi!
While for the trunk I hope Michael will finalize a much better fix,
this patch provides a quick workaround for 4.6 branch.
In particular, I'd like to avoid reverting the
http://gcc.gnu.org/ml/gcc-patches/2011-01/msg01442.html
patch, because if GIMPLE passes don't do any significant code motio
101 - 118 of 118 matches
Mail list logo
