> On Sun, 18 Nov 2012, Jan Hubicka wrote:
> > > > > this patch reduces max-peeled-insns and max-completely-peeled-insns
> > > > > from 400
> > > > > to 100. The reason why I am doing this is that I want to reduce code
> > > > > bloat
> > > > > caused by my cunroll work that enabled a lot more un
On Wed, Nov 7, 2012 at 2:11 PM, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55122
>
> The problem was in generation of reload pseudo for matching operands with
> uniq value which prevented to assign the same hard register for the reload
>
Hi,
this is a wrong code regression unfortunately caused by my fix for
c++/45385.
The story went (*) that in order to fix the latter missing warning we
decided to remove the kludge added in c++/35602 to avoid a bogus warning
*and* we also decided to early return from build_vec_init when maxi
On Thu, 22 Nov 2012, Kirill Yukhin wrote:
> Hi folks,
>
> This patch adds an utility for dumping MD-files after iterators and
> define_substs expanding. The new utility is named genmddump and is
> built along with other gen* programs.
>
> I also added new target to Makefile to invoke this utility.
Fixing two multiarch issues:
- the kfreebsd configuration gets the MULTILIB_OSDIRNAMES from the linux
definition, which now has x32 defined. Just filter out the x32 definition,
kfreebsd is plain 32/64 biarch.
- the configure.ac used $withval instead of $enableval. Explicit
--{en,dis}ab
On Fri, Nov 23, 2012 at 4:59 PM, H.J. Lu wrote:
> On Fri, Nov 23, 2012 at 3:38 PM, H.J. Lu wrote:
>> On Fri, Nov 23, 2012 at 3:21 PM, H.J. Lu wrote:
>>> On Fri, Nov 23, 2012 at 2:12 PM, Tobias Burnus wrote:
As suggested by Joseph, it uses fegetround instead of trying to get the
inform
On Fri, Nov 23, 2012 at 11:45 PM, Steven Bosscher wrote:
> Removing the note is easier but it may hurt optimization later on:
> CSE2 puts the note back in but this introduces a pass ordering
> dependency. Perhaps that's not a big problem, but I'm not sure...
Hmm, actually CSE2 fails to put the not
On Fri, Nov 23, 2012 at 3:38 PM, H.J. Lu wrote:
> On Fri, Nov 23, 2012 at 3:21 PM, H.J. Lu wrote:
>> On Fri, Nov 23, 2012 at 2:12 PM, Tobias Burnus wrote:
>>> As suggested by Joseph, it uses fegetround instead of trying to get the
>>> information elsewhere (which glibc does to avoid mixing libm
On Wed, Nov 21, 2012 at 6:40 PM, Greta Yorsh wrote:
> This patch adjusts the definition of TARGET_LDRD to false on Thumb1 targets,
> as suggested here:
> http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02048.html
>
> No regression on qemu for arm none-eabi with arch=armv5t/armv7-a
> mode=thumb/arm.
>
On Wed, Nov 14, 2012 at 1:52 PM, Kyrylo Tkachov wrote:
> Hi all,
>
> This patch adds the new tests for the vrint instructions in aarch32.
> It also adds an effective target check to see if we support an ARMv8 VFP and
> an add_options
> procedure for adding the required options to a testcase if we
> gcc/ChangeLog
>
> 2012-11-14 Kyrylo Tkachov
>
> * config/arm/arm.h (TARGET_FPU_ARMV8): New macro.
> * config/arm/arm.md (UNSPEC_VRINTZ, UNSPEC_VRINTP, UNSPEC_VRINTM,
> UNSPEC_VRINTR, UNSPEC_VRINTX, UNSPEC_VRINTA): New unspecs.
> (f_rints, f_rintd): New types.
On Wed, Nov 21, 2012 at 7:59 PM, Matthew Gretton-Dann
wrote:
> All,
>
> The attached patch fixes PR54974.
>
> In Thumb when calculating the PC value for a literal load the value used is
> the current PC rounded down to the nearest multiple of 4. The ARM backend
> currently does not take this into
On 23 Nov 2012, at 18:09, "Ian Bolton" wrote:
I had already committed my testcase for this for aarch64, but
it depends on this patch that doesn't yet exist in 4.7, so I
backported to our ARM/aarch64-4.7-branch.
Cheers,
Ian
This commit breaks the build, reverted.
/Marcus
On Fri, Nov 23, 2012 at 3:21 PM, H.J. Lu wrote:
> On Fri, Nov 23, 2012 at 2:12 PM, Tobias Burnus wrote:
>> As suggested by Joseph, it uses fegetround instead of trying to get the
>> information elsewhere (which glibc does to avoid mixing libm with libc).
>>
>> Build and tested on x86-64-gnu-linux
On Fri, Nov 23, 2012 at 2:12 PM, Tobias Burnus wrote:
> As suggested by Joseph, it uses fegetround instead of trying to get the
> information elsewhere (which glibc does to avoid mixing libm with libc).
>
> Build and tested on x86-64-gnu-linux. Committed as Rev. 193770.
>
> Tobias
This caused:
h
Ok if no regressions.
Ramana
On Wed, Oct 10, 2012 at 9:57 AM, Bin Cheng wrote:
> Ping^2
>
>> -Original Message-
>> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
> On
>> Behalf Of Bin Cheng
>> Sent: Monday, October 08, 2012 2:36 PM
>> To: gcc-patches@gcc.gnu.o
With this patch we define this_thread::yield() and
this_thread::sleep_for and this_thread::sleep_until unconditionally,
albeit with less functionality than when --enable-libstdcxx-time is
used.
This contains a #error so will fail to build on platforms that support
std::thread but don't provide ::s
/usr/lib/gcc/x86_64-pc-linux-gnu/
Reply-To: "H.J. Lu"
Hi,
I checked in this patch to fix PR sanitizer/55450.
H.J.
---
Index: ChangeLog
===
--- ChangeLog (revision 193766)
+++ ChangeLog (working copy)
@@ -1,12 +1,18 @@
+2012-11
On Fri, Nov 23, 2012 at 11:33:37AM -0800, H.J. Lu wrote:
> 2012-11-21 H.J. Lu
>
> PR bootstrap/55380
> * charset.c (_cpp_convert_input): Clear CPP_PAD_BUFFER_SIZE
> bytes if CLEAR_CPP_PAD_BUFFER isn't 0. Allocate extra
> CPP_PAD_BUFFER_SIZE bytes and clear it if CLEAR_C
On Fri, Nov 23, 2012 at 11:23 AM, Uros Bizjak wrote:
> On Fri, Nov 23, 2012 at 8:16 PM, H.J. Lu wrote:
>> On Fri, Nov 23, 2012 at 10:59 AM, Uros Bizjak wrote:
>>> Hello!
>>>
This patch allocates extra 16 bytes for -fsanitize=address so that
asan won't report read beyond memory buffer.
On Fri, Nov 23, 2012 at 8:16 PM, H.J. Lu wrote:
> On Fri, Nov 23, 2012 at 10:59 AM, Uros Bizjak wrote:
>> Hello!
>>
>>> This patch allocates extra 16 bytes for -fsanitize=address so that
>>> asan won't report read beyond memory buffer. It is used by
>>> bootstrap-asan. OK to install?
>>
>>/*
On Fri, Nov 23, 2012 at 10:59 AM, Uros Bizjak wrote:
> Hello!
>
>> This patch allocates extra 16 bytes for -fsanitize=address so that
>> asan won't report read beyond memory buffer. It is used by
>> bootstrap-asan. OK to install?
>
>/* Resize buffer if we allocated substantially too much, or
Hello!
> This patch allocates extra 16 bytes for -fsanitize=address so that
> asan won't report read beyond memory buffer. It is used by
> bootstrap-asan. OK to install?
/* Resize buffer if we allocated substantially too much, or if we
- haven't enough space for the \n-terminator. */
+
On Sun, 18 Nov 2012, Jan Hubicka wrote:
> > > > this patch reduces max-peeled-insns and max-completely-peeled-insns
> > > > from 400
> > > > to 100. The reason why I am doing this is that I want to reduce code
> > > > bloat
> > > > caused by my cunroll work that enabled a lot more unrolling then
On Fri, Nov 23, 2012 at 10:12 AM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 10:08:11AM -0800, H.J. Lu wrote:
>> > to also change the caller, read_file_guts, where it does
>> > buf = XNEWVEC (uchar, size + 1);
>> > and
>> > buf = XRESIZEVEC (uchar, buf, size + 1);
>>
>> I don't thi
On Fri, Nov 23, 2012 at 10:08:11AM -0800, H.J. Lu wrote:
> > to also change the caller, read_file_guts, where it does
> > buf = XNEWVEC (uchar, size + 1);
> > and
> > buf = XRESIZEVEC (uchar, buf, size + 1);
>
> I don't think it is necessary since there is no real data in
> those extra
On Fri, Nov 23, 2012 at 10:08 PM, H.J. Lu wrote:
> On Fri, Nov 23, 2012 at 9:38 AM, Jakub Jelinek wrote:
>> On Fri, Nov 23, 2012 at 09:23:37AM -0800, H.J. Lu wrote:
>>> This patch allocates extra 16 bytes for -fsanitize=address so that
>>> asan won't report read beyond memory buffer. It is used b
I had already committed my testcase for this for aarch64, but
it depends on this patch that doesn't yet exist in 4.7, so I
backported to our ARM/aarch64-4.7-branch.
Cheers,
Ian
From:
http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=f811051bf87b1de7804c19c8192
d0d099d157145
diff --git a/gcc/Cha
On Fri, Nov 23, 2012 at 9:38 AM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 09:23:37AM -0800, H.J. Lu wrote:
>> This patch allocates extra 16 bytes for -fsanitize=address so that
>> asan won't report read beyond memory buffer. It is used by
>> bootstrap-asan. OK to install?
>
> As valgrind wa
On Fri, Nov 23, 2012 at 09:23:37AM -0800, H.J. Lu wrote:
> This patch allocates extra 16 bytes for -fsanitize=address so that
> asan won't report read beyond memory buffer. It is used by
> bootstrap-asan. OK to install?
As valgrind warns about that too, I'd say we should do that unconditionally,
Hi,
This patch allocates extra 16 bytes for -fsanitize=address so that
asan won't report read beyond memory buffer. It is used by
bootstrap-asan. OK to install?
Thanks.
H.J.
---
2012-11-21 H.J. Lu
PR bootstrap/55380
* charset.c (_cpp_convert_input): Allocate extra 16 bytes
Looks great.
(I am not an expert in the build system either, but the changes look trivial).
Thanks!
--kcc
On Fri, Nov 23, 2012 at 8:29 PM, Alexander Potapenko wrote:
> The mach_override path looks good to me. I don't have enough knowledge
> of GCC buildsystem yet to review the rest.
>
> On Fri,
As suggested by Kostya.
Committed as Rev. 193764.
Tobias
Index: gcc/ChangeLog
===
--- gcc/ChangeLog (Revision 193763)
+++ gcc/ChangeLog (Arbeitskopie)
@@ -1,3 +1,8 @@
+2012-11-23 Tobias Burnus
+
+ * doc/invoke.texi (-fsanitize=ad
On Fri, Nov 23, 2012 at 8:39 AM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
>> > This patch attempts to instrument __atomic_* and __sync_* builtins.
>> > Unfortunately for none of the builtins there is 1:1 mapping to the tsan
>> > replacements, tsan uses
Dear Paul,
thanks for the updated patch. While reading your patch, I was wondering
whether the attached test case works or not.
Result: It does *not* print "Hello World" with neither gfortran nor
crayftn. If one changes in "m3" the declared type of "x" from "t" to
"t2", it shows "Hello World
On Fri, Nov 23, 2012 at 08:10:39PM +0400, Dmitry Vyukov wrote:
> > This patch attempts to instrument __atomic_* and __sync_* builtins.
> > Unfortunately for none of the builtins there is 1:1 mapping to the tsan
> > replacements, tsan uses weirdo memory model encoding (instead of values
> > from 0 t
The mach_override path looks good to me. I don't have enough knowledge
of GCC buildsystem yet to review the rest.
On Fri, Nov 23, 2012 at 8:17 PM, Jack Howarth wrote:
>The attached patch imports the missing mach_override/mach_override.h and
> mach_override/mach_override.c files from llvm.org'
On Fri, Nov 23, 2012 at 8:07 PM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 06:47:06PM +0400, Konstantin Serebryany wrote:
>> >> > Executing on host: addr2line -f -e
>> >> > /usr/local/google/kcc/gcc-build/gcc/testsuite/gcc/memcmp-1.exe
>> >> > 0x80488d1 0x8048560 (timeout = 300)
>> >> > spa
The attached patch imports the missing mach_override/mach_override.h and
mach_override/mach_override.c files from llvm.org's compiler-rt at
r168032 | glider | 2012-11-15 03:32:16 -0500 (Thu, 15 Nov 2012) | 3 lines
[ASan] Add the "lea $imm(%rip),%rax" instruction to mach_override.c
The need fo
... thus we could also do the below, for example. Actually I probably
like it a tad better ;)
Paolo.
Index: method.c
===
--- method.c(revision 193758)
+++ method.c(working copy)
@@ -1175,6 +1175,7 @@ synthe
On Fri, Nov 23, 2012 at 06:47:06PM +0400, Konstantin Serebryany wrote:
> >> > Executing on host: addr2line -f -e
> >> > /usr/local/google/kcc/gcc-build/gcc/testsuite/gcc/memcmp-1.exe
> >> > 0x80488d1 0x8048560 (timeout = 300)
> >> > spawn addr2line -f -e
> >> > /usr/local/google/kcc/gcc-build/gcc
Hi,
this adds a workaround (-mfix-ut699 switch) for the floating-point errata of
the LEON 3 processor UT699. It's almost entirely implemented in the SPARC
back-end, but there is a small change in expand_builtin_mathfn to make use of
sqrt_optab with a larger mode if it isn't available in the or
Hi,
when SSE memcpy/memset code was reverted last stage3 (because of alignment
handling bug), it went also with some unrelated changes, in particular
retunning of stringop descriptors for the new glibc implementation that finally
is sane for modern architectures. This patch partly restores the sec
This is the recent bootstrap failure on SPARC/Linux --with-cpu=ultrasparc in
release mode: cp/decl.c:copy_type_enum is miscompiled at -O2 after
http://gcc.gnu.org/ml/gcc-cvs/2012-11/msg00546.html
The patch has enabled the use of MEM_EXPR for bitfields. This was possible
thanks to earlier chan
http://gcc.gnu.org/ml/gcc-patches/2012-11/msg00984.html
Ping.
Thanks,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
ulrich.weig...@de.ibm.com
On 12-11-23 7:42 AM, Uros Bizjak wrote:
Hello!
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 193742.
2012-11-22 Vladimir Makarov
PR middle-end/55430
Hi,
On 11/23/2012 04:47 PM, Jason Merrill wrote:
On 11/23/2012 10:46 AM, Jason Merrill wrote:
On 11/22/2012 11:03 AM, Paolo Carlini wrote:
initialized to true too), but Markus (and me ;) proposes anyway to
initialize trivial_p to false, thus we should be fine (way below
trivial_p is used again
On 11/23/2012 10:46 AM, Jason Merrill wrote:
On 11/22/2012 11:03 AM, Paolo Carlini wrote:
initialized to true too), but Markus (and me ;) proposes anyway to
initialize trivial_p to false, thus we should be fine (way below
trivial_p is used again but only when deleted_p is false).
It certainly
On 11/22/2012 11:03 AM, Paolo Carlini wrote:
initialized to true too), but Markus (and me ;) proposes anyway to
initialize trivial_p to false, thus we should be fine (way below
trivial_p is used again but only when deleted_p is false).
It certainly can't hurt.
Jason
On 11/20/2012 03:31 PM, Jakub Jelinek wrote:
+case THROW_EXPR:
+ return block_may_fallthru (TREE_OPERAND (stmt, 0));
Shouldn't this just be false? OK with that change.
Jason
On 12-11-23 7:42 AM, Uros Bizjak wrote:
Hello!
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 193742.
2012-11-22 Vladimir Makarov
PR middle-end/55430
On 12-11-23 9:44 AM, Jakub Jelinek wrote:
Hi!
On Thu, Nov 22, 2012 at 08:29:36PM -0500, Vladimir Makarov wrote:
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430
The patch was successfully bootstrapped and tested on x86/x86-64.
Committed as rev. 193742.
20
Hi!
On Thu, Nov 22, 2012 at 08:29:36PM -0500, Vladimir Makarov wrote:
> The following patch fixes
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430
>
> The patch was successfully bootstrapped and tested on x86/x86-64.
>
> Committed as rev. 193742.
>
> 2012-11-22 Vladimir Makarov
>
On 11/23/2012 04:58 AM, Florian Weimer wrote:
Okay, this might work in the sense that it flags the relevant cases. I'm
still not convinced that this actually helps programmers that much
because it pretty much separates the two worlds. If this is the intend,
surely there are simpler approaches (s
On Fri, Nov 23, 2012 at 06:12:24PM +0400, Konstantin Serebryany wrote:
> Ok, the tests behave better on ubuntu 12.04.
> tested:
> rm -rf rm -rf */{*/,}libsanitizer && make -j20 && make -C gcc
> check-g{cc,++} RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
> asan.exp'
>
> The fresh asan library pro
> Sounds good. I am travelling the rest of the week so I'll get the revised
> patch ready by Mon. Thanks, Teresa
Hi,
I updated the patch, so we make progress on the heuristic retunning. There was
a segfault during profiledbootstrap trying to fetch DECL_STRUCT_FUNCTION of
calle of indirect call and
Hi!
This patch attempts to instrument __atomic_* and __sync_* builtins.
Unfortunately for none of the builtins there is 1:1 mapping to the tsan
replacements, tsan uses weirdo memory model encoding (instead of values
from 0 to 5 apparently 1 << 0 to 1 << 5, as if one could have more than
one memory
Hi,
I went ahead, updated the patch, tested wth profiledbootstrap on x86_64-linux
and commited. I really need to progress with heuristic re-tunning before we
get too far in stage3. In addition to caching result of find_working_set I had
to avoid ICE when we try to determine DECL_STRUCT_FUNCTION o
Hi!
var ={v} {CLOBBER};
stmts shouldn't be tsan instrumented, those aren't stores, just
markups that var's scope ends. Additionally this patch removes the
IMHO unneeded TODO_update_address_taken (discussed earlier already)
and fixes formatting of a few comments.
Ok for trunk?
2012-11-23 Jakub
Here are some more fixes for 16-bit int and similar.
Ok for trunk?
Johann
* gcc.dg/c1x-align-4.c: Skip avr.
* gcc.dg/54455.c: Require scheduling.
* gcc.dg/pr44024.c: Skip avr in final scan.
PR testsuite/52641
* gcc.c-torture/execute/20120919-1.x: New file
On Fri, Nov 23, 2012 at 5:30 PM, Tobias Burnus wrote:
> Konstantin Serebryany wrote:
>>>
>>> >I think the man page should be then updated.
>>
>> man page?
>
>
> I mean gcc/doc/invoke.texi, which is available as "man gcc" and also part of
> the GCC Manual (http://gcc.gnu.org/onlinedocs/). It curren
Konstantin Serebryany wrote:
>I think the man page should be then updated.
man page?
I mean gcc/doc/invoke.texi, which is available as "man gcc" and also
part of the GCC Manual (http://gcc.gnu.org/onlinedocs/). It currently
contains:
@item -fsanitize=address
Enable AddressSanitizer, a fast
On Fri, Nov 23, 2012 at 5:22 PM, Tobias Burnus wrote:
> Konstantin Serebryany wrote:
>>
>> Looks good.
>
>
> And now available at http://gcc.gnu.org/gcc-4.8/changes.html
Cool!
>
>
>>> Notes: I didn't mention Sparc, PowerPC, and Darwin
>>
>> Darwin works fine with clang, but not yet in gcc.
>
>
>
Konstantin Serebryany wrote:
Looks good.
And now available at http://gcc.gnu.org/gcc-4.8/changes.html
Notes: I didn't mention Sparc, PowerPC, and Darwin
Darwin works fine with clang, but not yet in gcc.
I know – and actually it is a bit unclear to me what's the review status
of Jack Howar
On Fri, Nov 23, 2012 at 4:47 PM, Jakub Jelinek wrote:
> On Fri, Nov 23, 2012 at 04:35:29PM +0400, Konstantin Serebryany wrote:
>> > Ok, provided it has been properly tested
>>
>> The upstream library is continuously tested on Linux, Mac, Windows and
>> Android
>> using the existing test suite (un
On Fri, Nov 23, 2012 at 04:35:29PM +0400, Konstantin Serebryany wrote:
> > Ok, provided it has been properly tested
>
> The upstream library is continuously tested on Linux, Mac, Windows and Android
> using the existing test suite (unfortunately, the build bots are
> private so far).
Yeah, but on
Hello!
>> The following patch fixes
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55430
>>
>> The patch was successfully bootstrapped and tested on x86/x86-64.
>>
>> Committed as rev. 193742.
>>
>> 2012-11-22 Vladimir Makarov
>>
>> PR middle-end/55430
>> * lra.c: Move
On Fri, Nov 23, 2012 at 3:15 PM, Jakub Jelinek wrote:
> Hi!
>
> Ok, provided it has been properly tested
The upstream library is continuously tested on Linux, Mac, Windows and Android
using the existing test suite (unfortunately, the build bots are
private so far).
> (given that we don't have
>
Looks good.
On Fri, Nov 23, 2012 at 3:27 PM, Tobias Burnus wrote:
> Konstantin Serebryany wrote:
>>
>> On Mon, Nov 19, 2012 at 10:44 PM, Tobias Burnus wrote:
>>>
>>> attached is a first draft for -faddress-sanitizer in the release notes.
>>
>> stack overflow is something different, I guess we wa
Konstantin Serebryany wrote:
On Mon, Nov 19, 2012 at 10:44 PM, Tobias Burnus wrote:
attached is a first draft for -faddress-sanitizer in the release notes.
stack overflow is something different, I guess we want to say "stack
buffer overflow". I typically write something like "heap-, stack-, an
Hi!
Ok, provided it has been properly tested (given that we don't have
almost any testsuite so far, that is at least
rm -rf */{*/,}libsanitizer;
make # -jN
in the build tree and
make -C gcc check-g{cc,++} RUNTESTFLAGS='--target_board=unix\{-m32,-m64\}
asan.exp'
).
On Fri, Nov 23, 2012 at 03:03:2
This is an internal error on a postcondition applying the 'Old attribute to a
parameter with discriminated record type. The problem is that S'Old ends up
being rewritten into a local constrained variable very late in the game by the
front-end and this yields a slightly skewed tree.
Fixed thusl
The layout of variant record types doesn't always guarantee the proper
alignment of aliased components if the record types are also packed.
Fixed thusly, tested on x86_64-suse-linux, applied on the mainline.
2012-11-23 Eric Botcazou
* gcc-interface/decl.c (components_need_strict_ali
Better attach the patch...
Georg-Johann Lay wrote:
> This patchlet fixes missing STAMP command line tool that is needed if gnat is
> build for target avr.
>
> The patch is untested and as proposed in
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243#c5
>
> Ok for trunk and 4.7?
>
> Johann
This patchlet fixes missing STAMP command line tool that is needed if gnat is
build for target avr.
The patch is untested and as proposed in
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55243#c5
Ok for trunk and 4.7?
Johann
PR ada/55243
* Makefile.in (TOOLS_FLAGS_TO_PASS_CROSS)
On 11/15/2012 02:51 AM, Jason Merrill wrote:
On 11/11/2012 11:58 PM, Jason Merrill wrote:
On 11/11/2012 08:01 AM, Florian Weimer wrote:
I'm not sure if this sufficiently far-reaching. It seems that this
doesn't allow me to implement a virtual function which takes a
std::string parameter in new
On Nov 22, 2012, at 9:48 AM, Kirill Yukhin wrote:
> This patch adds an utility for dumping MD-files after iterators and
> define_substs expanding.
> What do you guys think?
Cool. (That's not an official review. :-))
On Nov 22, 2012, at 8:54 AM, Georg-Johann Lay wrote:
> Some more skips for tests that will fail with 16-bit int etc.
>
> Ok for trunk?
Ok.
Hi Joseph,
Can you please help to review this patch and share your thoughts on this
feature? Thanks.
BR,
Terry
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Terry Guo
> Sent: Tuesday, November 13, 2012 12:47 PM
> To: jos
79 matches
Mail list logo
