> On 21 Jan 2015, at 08:47, Joel Brobecker wrote:
>
> Thank you! :)
What is the rational for having --with-zlib but --with-libz-prefix
(ie zlib vs libz) ? Looks not very consistent.
Tristan.
>
> On Wed, Jan 07, 2015 at 06:45:48PM +0400, Joel Brobecker wrote:
>> Hello,
>>
>> This patch enha
Hi Mike,
Yes, I can quantify the cost. Is it very high.
Here is the patch that I used:
--- rtl/tsan_rtl.cc (revision 226644)
+++ rtl/tsan_rtl.cc (working copy)
@@ -709,7 +709,11 @@
ALWAYS_INLINE USED
void MemoryAccess(ThreadState *thr, uptr pc, uptr addr,
int kAccessSizeLog, bool kAccessI
Hi,
On Tue, 20 Jan 2015 17:47:29, Konstantin Serebryany wrote:
>>
>> We discussed two alternatives to sleep:
>>
>> 1. step function, optionally with sched_yield to make it somewhat less busy
>> waiting:
>> __attribute__((no_sanitize_thread))
>> void step (int i)
>> {
>> while (__atomic_load_n (&s
> What is the rational for having --with-zlib but --with-libz-prefix
> (ie zlib vs libz) ? Looks not very consistent.
I agree it's unfortunate, but it is unavoidable if I want to keep the
current option as it is (compatibility), and reuse AC_LIB_HAVE_LINKFLAGS
(which is a fairly complex function)
On Wed, Jan 21, 2015 at 12:23:34PM +0400, Dmitry Vyukov wrote:
> Hi Mike,
>
> Yes, I can quantify the cost. Is it very high.
>
> Here is the patch that I used:
>
> --- rtl/tsan_rtl.cc (revision 226644)
> +++ rtl/tsan_rtl.cc (working copy)
> @@ -709,7 +709,11 @@
> ALWAYS_INLINE USED
> void Memo
On Wed, Jan 21, 2015 at 11:34 AM, Jakub Jelinek wrote:
> On Wed, Jan 21, 2015 at 12:23:34PM +0400, Dmitry Vyukov wrote:
>> Hi Mike,
>>
>> Yes, I can quantify the cost. Is it very high.
>>
>> Here is the patch that I used:
>>
>> --- rtl/tsan_rtl.cc (revision 226644)
>> +++ rtl/tsan_rtl.cc (working
On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger
wrote:
>
> Hi,
>
> On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>>
>> [text-only]
>>
>> On Mon, Jan 19, 2015 at 7:42 AM, Mike Stump wrote:
>>> On Jan 19, 2015, at 12:43 AM, Dmitry Vyukov wrote:
I can't really make my mind on thi
__objc_get_forward_imp and get_imp were exported in libobjc since GCC 4.1, for
some reason these are not exported anymore in GCC 5 (both declared inline). So
either export these as before, or don't export them and bump the soname. The
latter seems to be unwanted, and at least gnustep-base is usin
Jeff Law writes:
> On 07/01/14 15:34, Daniel Gutson wrote:
>> On Tue, Jul 1, 2014 at 2:25 PM, Jeff Law wrote:
>>> On 03/19/14 08:06, Marcos Díaz wrote:
Well, finally I have the assignment, could you please review this patch?
>>>
>>> Thanks.
>>>
>>> My first thought was that if we've ma
On Wed, Jan 21, 2015 at 10:02:07AM +0100, Matthias Klose wrote:
> __objc_get_forward_imp and get_imp were exported in libobjc since GCC 4.1, for
> some reason these are not exported anymore in GCC 5 (both declared inline).
> So
> either export these as before, or don't export them and bump the so
On Wed, Jan 21, 2015 at 10:02:07AM +0100, Matthias Klose wrote:
> __objc_get_forward_imp and get_imp were exported in libobjc since GCC 4.1, for
> some reason these are not exported anymore in GCC 5 (both declared inline).
> So
> either export these as before, or don't export them and bump the so
> Perhaps 'd' should just go away completely. It was intended to
> distinguish between ports using the old scheduler description and
> ports using the DFA model.
Applied.
--
Eric BotcazouIndex: backends.html
===
RCS file: /cvs/gcc/w
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01008.html
I updated the testcase adding test for vfmsq_n_f64 intrinsic.
Test OK for both aarch64-linux-gnu and aarch64_be-linux-gnu-gcc.
OK for the trunk? Thanks.
Index: gcc/ChangeLog
=
Richard Biener writes:
> On Mon, Jan 12, 2015 at 10:36 AM, Hurugalawadi, Naveen
> wrote:
>> Hi Richard,
>>
>> Thanks for the quick review and comments.
>>
>> Please find attached the modified patch as per your suggestion.
>
> Ok.
Unfortunately, this patch causes an ICE on Solaris 10:
FAIL: g++
On 1/6/15 04:07, Jeff Law wrote:
> On 12/28/14 21:04, Chen Gang S wrote:
>> When failure occurs, random_seed may not be 0, so need reset it to 0
>> manually, or will let the next call init_random_seed() incorrect. The
>> related warning:
>>
>>g++ -c -DTARGET_NAME=\"parisc-gchen-linux\" -g -O2
Well, OK, it is actually not easier to write tests with step function
as compared to barrier.
On Wed, Jan 21, 2015 at 11:58 AM, Dmitry Vyukov wrote:
> On Tue, Jan 20, 2015 at 10:09 AM, Bernd Edlinger
> wrote:
>>
>> Hi,
>>
>> On Mon, 19 Jan 2015 18:49:21, Konstantin Serebryany wrote:
>>>
>>> [te
Hi,
On Wed, 21 Jan 2015 12:58:27, Dmitry Vyukov wrote:
>
>
> The step approach looks better to me at first sight.
>
> Busy waiting looks like a weak argument in this context. It's
> absolutely non performance-critical and a yield or usleep(10) will
> solve it more than sufficiently.
>
> I will ch
On Tue, Jan 20, 2015 at 8:57 PM, Jan Hubicka wrote:
> Hi,
> this patch relaxes inliner to allow limited cross-module inlining across units
> compiled with -O3 and -Os. This was tested with Firefox and it leads to binary
> of about the same size but noticeably faster in some of javascript benchmark
This adds four optimization patterns to match.pd, along with trivial
test cases. Compiles and works as expected, and 'make check' on x86_64
gives the same number of "unexpected failures" before and after (8
from gfortran.dg/guality/pr41558.f90, 1 from failing to compile
gcc.dg/plugin/ggcplug.c).
I
gcc.dg/20150120-1.c: New test
Rounding an integer to the next even integer is sometimes written x +=
x & 1. The equivalent x = (x+1)&~1 usually uses one less register, and
in practical cases only the new value of x will be used (making it
unlikely that the subexpression x&1 has any uses).
Signed-
gcc.dg/20150120-3.c: New test
This is simply the 'dual' of the previous pattern, added for
completeness.
Signed-off-by: Rasmus Villemoes
---
gcc/match.pd | 6 ++
gcc/testsuite/gcc.dg/20150120-3.c | 32
2 files changed, 38 insertions(+)
gcc.dg/20150120-2.c: New test
Clearing a certain subset of bits, for example to round down x to a
multiple of a power of 2, is sometimes written x & ~(x & y), where y
may or may not be a constant. It is shorter to use x & ~y,
particularly when y is a constant. gcc already does this when it is
spel
Generalizing the x+(x&1) pattern, one can round up x to a multiple of
a 2^k by adding the negative of x modulo 2^k. But it is fewer
instructions, and presumably requires fewer registers, to do the more
common (x+m)&~m where m=2^k-1.
Signed-off-by: Rasmus Villemoes
---
gcc/match.pd
Hi all,
just added myself to the MAINTAINERS file (Write after approval) as r219936.
I will do mostly gfortran development.
Regards,
Andre
--
Andre Vehreschild * Email: vehre ad gmx dot de
Index: ChangeLog
===
--- ChangeLog
On Wed, Jan 21, 2015 at 11:49:53AM +0100, Rasmus Villemoes wrote:
> gcc.dg/20150120-3.c: New test
>
> This is simply the 'dual' of the previous pattern, added for
> completeness.
If this is dual, I think you could make use of
(for op (bit_ior bit_and)
...
and do the simplification in one hunk.
Hi Jakub & Mike,
> test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
> internal-fn.c:243
> void step (int i)
It looks like your patches shot each other down..
How about this, maybe with a compile-time test of the step function in
c-c++common/tsan?
Thanks
Bernd.
David Edelsohn writes:
> Index: gcc/config/rs6000/rs6000.c
> ===
> --- gcc/config/rs6000/rs6000.c(revision 219747)
> +++ gcc/config/rs6000/rs6000.c(working copy)
> @@ -5072,6 +5072,28 @@ rs6000_file_start (void)
>
On Wed, Jan 21, 2015 at 12:17:51PM +0100, Bernd Edlinger wrote:
> > test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
> > internal-fn.c:243
> > void step (int i)
>
>
> It looks like your patches shot each other down..
>
> How about this, maybe with a compile-time test of the st
On 21/01/15 09:22, Yangfei (Felix) wrote:
This is a ping for: https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01008.html
I updated the testcase adding test for vfmsq_n_f64 intrinsic.
Test OK for both aarch64-linux-gnu and aarch64_be-linux-gnu-gcc.
OK for the trunk? Thanks.
Index: gcc/ChangeLog
=
On Wed, 21 Jan 2015 12:31:57, Jakub Jelinek wrote:
>
> On Wed, Jan 21, 2015 at 12:17:51PM +0100, Bernd Edlinger wrote:
>>> test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
>>> internal-fn.c:243
>>> void step (int i)
>>
>>
>> It looks like your patches shot each other down..
>>
>>
On 20/01/15 20:05 -0800, Tim Shen wrote:
On Tue, Jan 20, 2015 at 9:04 AM, Paolo Carlini wrote:
When we end up doing this to save run time, let's at least add in a comment
the PR #, like
// PR libstdc++/64680
before test02().
Certainly.
--
Regards,
Tim Shen
commit a150869847b7b02f57
On 19/01/15 18:01 -0800, Tim Shen wrote:
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits<>::lookup_collatename,
regex_traits<>::lookup_classname): Correctly narrow input chars.
* testsuite/28_regex/traits/wchar_t/user_defined.cc: New testcase.
OK for tr
Hi Thomas,
Thomas Koenig wrote:
> This patch takes the approach that any array bound which
> contains a dummy variable which is not INTENT(IN) may be
> changed by the user, and that we cannot be assured that
> it will not be changed.
How about sym->attr.flavor == FL_PARAMETER? I am not sure
whet
Just read it and thought the following may apply.
Jakub - are you fine with that?
Thanks,
Richard.
2015-01-21 Richard Biener
* gcc-5/criteria.html: Adjust and clarify bugs blocking the
release.
Index: gcc-5/criteria.html
=
On Wed, Jan 21, 2015 at 02:17:51PM +0100, Richard Biener wrote:
>
> Just read it and thought the following may apply.
>
> Jakub - are you fine with that?
LGTM.
> 2015-01-21 Richard Biener
>
> * gcc-5/criteria.html: Adjust and clarify bugs blocking the
> release.
Jakub
Refactored tests in clang to use barrier_init/wait:
http://llvm.org/viewvc/llvm-project?view=revision&revision=226659
There are still few sleep call, like when we need to wait for a thread
to exit (there is really no point to insert barrier_wait); or when we
need to wait for a thread to _block_ in
On Tue, Jan 20, 2015 at 2:01 PM, Jan Hubicka wrote:
>> On 2015.01.20 at 21:04 +0100, Jan Hubicka wrote:
>> > this patch fixes ICE in ipa_merge_profiles on speculative edges.
>> >
>> > Bootstrapped/regtested x86_64-linux, comitted. Also tested by Markus on
>> > Firefox build.
>>
>> This needs one a
Hi,
On 21 Jan 2015 17:57:10, Dmitry Vyukov wrote:
> Subject: Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
> To: bernd.edlin...@hotmail.de
> CC: konstantin.s.serebry...@gmail.com; mikest...@comcast.net;
> k...@google.com; ja...@redhat.com; richard.guent...@gmail.com;
> gcc-patches@gcc.
On Wed, Jan 21, 2015 at 5:38 PM, Bernd Edlinger
wrote:
> Hi,
>
> On 21 Jan 2015 17:57:10, Dmitry Vyukov wrote:
>> Subject: Re: [PING] [PATCH] Fix parameters of __tsan_vptr_update
>> To: bernd.edlin...@hotmail.de
>> CC: konstantin.s.serebry...@gmail.com; mikest...@comcast.net;
>> k...@google.com;
On 19 January 2015 at 17:54, Marcus Shawcroft
wrote:
> On 19 January 2015 at 15:43, Christophe Lyon
> wrote:
>> On 19 January 2015 at 14:29, Marcus Shawcroft
>> wrote:
>>> On 16 January 2015 at 17:52, Christophe Lyon
>>> wrote:
>>>
> OK provided, as per the previous couple, that we don;t
On 20/01/15 11:59 +, Jonathan Wakely wrote:
On 19/01/15 16:02 +, Jonathan Wakely wrote:
We declare atomic_init() but then never define it, I assume that's
just an accident.
Although the standard says this function is non-atomic, the simplest
fix at this stage is just to do an atomic sto
If we are combining insns like
I1: (... r90) REG_DEAD r90
I2: (set r90 ...)
I3: (...)
resulting in
I2: (set r90 ...)
I3: (...)
distribute_notes for that REG_DEAD r90 wil start searching (backwards)
for r90 starting from I3. Then it will find I2, and be
On 20/01/15 17:52 +, Jonathan Wakely wrote:
On 20/01/15 09:02 -0800, H.J. Lu wrote:
On Linux/ia-32, I got
output is:
/tmp/ccApSqaQ.o: In function `facet::facet()':^M
/export/gnu/import/git/gcc-test-x32/src-trunk/libstdc++-v3/testsuite/22_locale/ctype_byname/2.cc:29:
undefined reference to
`
As discussed in the PR, we're committing a layering violation here.
Removing that violation fixes the ICE, which is the most important
thing for the moment.
Reviewing objdump of the stage3 cc1plus, about 90% of the instances
of ccmp instruction are followed by a conditional branch, so combine
is u
> On Jan 21, 2015, at 1:02 AM, Matthias Klose wrote:
>
> __objc_get_forward_imp and get_imp were exported in libobjc since GCC 4.1, for
> some reason these are not exported anymore in GCC 5 (both declared inline).
> So
> either export these as before, or don't export them and bump the sonam
On Wed, Jan 21, 2015 at 08:41:46AM -0800, pins...@gmail.com wrote:
> > On Jan 21, 2015, at 1:02 AM, Matthias Klose wrote:
> >
> > __objc_get_forward_imp and get_imp were exported in libobjc since GCC 4.1,
> > for
> > some reason these are not exported anymore in GCC 5 (both declared inline).
>
Since HOST_WIDE_INT_PRINT_HEX includes "0x", we don't need to add another
"0x". OK to install?
H.J.
---
* class.c (dump_class_hierarchy_r): Remove 0x with
HOST_WIDE_INT_PRINT_HEX.
(dump_vtable): Likewise.
---
gcc/cp/class.c | 6 +++---
1 file changed, 3 insertions(+), 3
Jonathan Wakely writes:
>>I forgot that the mangled name for size_t depends on the target, so
>>the linker script needs [jm] instead of m. Patch coming soon ...
>
> This fixes the new FAILs on i686.
>
> Tested x86_64-linux and i686-linux, committed to trunk.
>
> I expect the new symbols are going
On 21/01/15 18:09 +0100, Rainer Orth wrote:
Indeed: before and after this change, Solaris bootstrap is broken. Now
I get
ld: fatal: libstdc++-symbols.ver-sun: 6153: symbol 'std::codecvt::do_unshift(__mbstate_t&, char*, char*, char*&) const': symbol
version conflict
_ZNKSt7codecvtIDic11__mbsta
On 01/20/2015 02:10 PM, Andrew Waterman wrote:
> 2015-01-09 Andrew Waterman
>
> * fop_n.c (libat_fetch_op): Align address to word boundary.
> (libat_op_fetch): Likewise.
Thanks. Applied to 4.8, 4.9, and mainline branches.
r~
Hi,
Is the following patch ok?
regards,
Alex
This patch fixes aarch64/atomic-op-consume.c test to expect safe assembly to be
generated when __ATOMIC_CONSUME semantics is requested.
2015-01-21 Alex Velenko alex.vele...@arm.com
gcc/testsuite/
gcc.target/aarch64/atomic-op-consume.c(scan-assemb
> Thanks. I had wrongly made eliminate_constant_term() static, reverted
> that change and it builds on
> all targets in config-list.mk.
> Committed as r219655 (hopefully nothing breaks!).
Any particular reason why store_bit_field, extract_bit_field, extract_low_bits
expand_mult and expand_mult_hi
Eric Botcazou writes:
>> Seems like the thread might have died down, so just wanted to ping it.
>> As Marcus says, this is holding up other patches so it'd be good to get
>> something in soon. Would it be OK to commit the original patch or should
>> we wait?
>
> Yes, go ahead, but add a FIXME or
Hi,
this patch fixed the no_sanitize_thread decl attribute again.
Boot-strapped and regression-tested on x86_64-linux-gnu.
OK for trunk?
Thanks
Bernd.
gcc/ChangeLog:
2015-01-21 Bernd Edlinger
* gimplify.c (gimplify_function_tree): Check the
On Wed, Jan 21, 2015 at 06:59:02PM +0100, Bernd Edlinger wrote:
> Hi,
>
> this patch fixed the no_sanitize_thread decl attribute again.
>
> Boot-strapped and regression-tested on x86_64-linux-gnu.
> OK for trunk?
Ok, thanks.
> gcc/ChangeLog:
> 2015-01-21 Bernd Edlinger
>
> * gimplify.
On Jan 21, 2015, at 3:17 AM, Bernd Edlinger wrote:
> Hi Jakub & Mike,
>
>> test.c:3:6: internal compiler error: in expand_TSAN_FUNC_EXIT, at
>> internal-fn.c:243
>> void step (int i)
>
> It looks like your patches shot each other down..
Ah, I’d use the phrase one-step forward. Yeah, looks not
On Jan 21, 2015, at 6:41 AM, Dmitry Vyukov wrote:
> But I am somewhat tired of editing hundreds of files for today. Why
> did I write so many tests, stupid!?
:-) We appreciate all your efforts and all your tests.
On Wed, Jan 21, 2015 at 05:39:12PM +, Alex Velenko wrote:
> Hi,
> Is the following patch ok?
> regards,
> Alex
Hi Alex,
Some comments on your submission inline below.
> This patch fixes aarch64/atomic-op-consume.c test to expect safe assembly to
> be
> generated when __ATOMIC_CONSUME semant
On Jan 21, 2015, at 1:54 AM, Chen Gang S wrote:
> On 1/6/15 04:07, Jeff Law wrote:
>>
>>>* toplev.c (init_local_tick): Process the failure when read
>>>fails for random_seed.
>> This is fine for the trunk. Please install.
> I am not familiar with the related working flow, who should
> i
On Tue, Jan 20, 2015 at 7:02 PM, Alan Modra wrote:
> On Tue, Jan 20, 2015 at 09:26:12AM -0500, David Edelsohn wrote:
>> On Tue, Jan 20, 2015 at 12:41 AM, Alan Modra wrote:
>> > On Mon, Jan 19, 2015 at 10:43:29PM -0500, David Edelsohn wrote:
>> >> On Fri, Jan 17, 2014 at 10:58 PM, Alan Modra wrot
On Mon, Jan 5, 2015 at 1:09 PM, Richard Biener wrote:
> On January 5, 2015 3:54:40 PM CET, Thomas Preud'homme
> wrote:
>>> From: Oleg Endo [mailto:oleg.e...@t-online.de]
>>> Sent: Tuesday, December 30, 2014 4:25 PM
>>>
>>> I've just tried disabling the 'rotlhi3' pattern and __builtin_bswap16
>>>
Hi Tobias,
> Thomas Koenig wrote:
>> This patch takes the approach that any array bound which
>> contains a dummy variable which is not INTENT(IN) may be
>> changed by the user, and that we cannot be assured that
>> it will not be changed.
>
> How about sym->attr.flavor == FL_PARAMETER? I am not
On Wed, Jan 21, 2015 at 6:22 AM, Andreas Schwab wrote:
> David Edelsohn writes:
>
>> Index: gcc/config/rs6000/rs6000.c
>> ===
>> --- gcc/config/rs6000/rs6000.c(revision 219747)
>> +++ gcc/config/rs6000/rs6000.c(workin
Hello,
(sorry for the broken thread, for some reason I haven't received any email
from gcc since about 10am, I'll investigate later)
+/* x & ~(x & y) -> x & ~y */
+(simplify
+ (bit_and:c @0 (bit_not (bit_and:c@2 @0 @1)))
+ (if (TREE_CODE (@2) != SSA_NAME || has_single_use (@2))
+ (bit_and @0
My patch for c++/57979 reduced the situations in which we fold a
variable to its constant initializer, leading to a bogus warning on this
testcase. The fix is to pull out the constant value in the warning code.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit b171d6f55d564243031b17fc1db1a
An instantiation of a constexpr template that does not satisfy the rules
for a constexpr function is still well-formed, just not constexpr.
Tested x86_64-pc-linux-gnu, applying to trunk.
commit f31ad5fe09e8d973926e32fa9617970e53b1ad19
Author: Jason Merrill
Date: Tue Jan 20 17:51:30 2015 -0500
On 12/29/2014 06:04 AM, Thomas Preud'homme wrote:
> Since 16bit byteswap can be done via an 8 bit rotation (and it is the
> canonical form),
> the check for an optab only serves to prevent the bswap optimization for
> targets that don't have a 16bit byteswap (but do have a rotation
> instruction)
Hi!
This picks my upstream fix for aarch64 compilation against glibc 2.21+
and a first step towards aarch64 sanitizer 42/47 bit address space support.
2015-01-21 Jakub Jelinek
PR sanitizer/64435
* sanitizer_common/sanitizer_platform_limits_posix.h: Cherry pick
upstream
On Wed, Oct 29, 2014 at 04:05:27PM +, Zamyatin, Igor wrote:
> >
> >
> > The question remains, are the decls all you need from the traversal (i.e.
> > what you need to act upon)? From my earlier skim of the original code that
> > wasn't that obvious.
> > You can have in decl_map at least also
Hi!
This patch fixes endless recursion, when we have e.g.
(eq (and (mem (mem)) (const_int 0)) (const_int 0))
and one of the MEMs is volatile (side_effects_p is true for it).
Due to the side effects, (and ... (const_int 0)) is not folded into 0,
and these two hunks then attempt to "simplify" it as
Hi!
I forgot to document this, is this ok for trunk or do you prefer some other
wording?
Slightly off-topic, what do you think about replacing *this ={v} {CLOBBER};
stmts in dtors of objects with virtual methods with storing of
NULL or some other value into the vtable pointer field, so that we wo
Hi!
As the testcase shows, with -fnon-call-exceptions RTL DSE can sometimes
remove possibly throwing stores and we then ICE because dead EH edges have
not been cleaned up.
This patch attempts to solve this similarly to how postreload-cse handles
it.
Bootstrapped/regtested on x86_64-linux and i68
On Wed, Jan 21, 2015 at 1:24 PM, Jakub Jelinek wrote:
> Hi!
>
> This picks my upstream fix for aarch64 compilation against glibc 2.21+
> and a first step towards aarch64 sanitizer 42/47 bit address space support.
Even though you are cherry-picking from upstream. The comments are incorrect.
It is
On 01/21/2015 01:36 PM, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2015-01-21 Jakub Jelinek
>
> PR rtl-optimization/62078
> * dse.c: Include cfgcleanup.h.
> (rest_of_handle_dse): For -fnon-call-exceptions, if DSE removed
>
On 01/21/2015 04:33 PM, Jakub Jelinek wrote:
+This option enables instrumentation of C++ member function calls, member
+accesses and some downcasts and upcasts, to verify the referenced object
Instead of "downcasts and upcasts" I'd write "conversions between
pointers to base and derived classe
On 01/21/2015 04:33 PM, Jakub Jelinek wrote:
Slightly off-topic, what do you think about replacing *this ={v} {CLOBBER};
stmts in dtors of objects with virtual methods with storing of
NULL or some other value into the vtable pointer field, so that we would
(sometimes) catch member accesses and me
For some reason, when converting sizeof("Main")-1 to int, we end up with
(unsigned)5UL + -1U, which fold fails to fold to 4U, but
initializer_constant_valid_p is happy to accept. I'm dealing with this
by always reprocessing expressions in the constexpr code.
Tested x86_64-pc-linux-gnu, applyi
On 01/21/2015 01:30 PM, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
>
> 2015-01-21 Jakub Jelinek
>
> PR debug/64511
> * simplify-rtx.c (simplify_relational_operation_1): Don't try to
> optimize (eq/ne (and (side_effects) (const_
Hi,
these two rather noticeable features are not mentioned.
Honza
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-5/changes.html,v
retrieving revision 1.69
diff -u -r1.69 changes.html
--- changes.html20 Jan 2015
On 01/21/2015 08:16 AM, Segher Boessenkool wrote:
> 2015-01-21 Segher Boessenkool
>
> gcc/
> PR rtl-optimization/64682
> * combine.c (distribute_notes): When moving a death note for
> a register that is set in the new I2, make sure to put it
> before that new I2.
>
> gc
On 20/01/2015 13:00, Jonathan Wakely wrote:
On 19/01/15 17:16 +, Jonathan Wakely wrote:
This is the last missing piece of the C++14 library, as proposed in
http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3657.htm
Tested x86_64-linux, *not* committed.
Now committed to trunk.
Is
Hi,
The patch is to address the bug here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64557
It is to call get_addr for VALUE before forming a mem_addr expr with
the VALUE and an offset. This is to avoid the problem that get_addr
can only handle VALUE but cannot handle an expr like: (VALUE +
offs
Don't install signal handlers in toplev.c if we're called from libgccjit,
only install them if we're called from main.c, thus avoiding
touching process-wide state from a shared library (see the PR for
details of how this is currently leading to SIGSEGV on errors in
"make check-jit").
Is this one s
This patch by Lynn Boger adds the base Go version to the start of the
runtime.Version string. Bootstrapped and ran Go testsuite on
x86_64-unknown-linux-gnu. Committed to mainline.
Ian
diff -r 00adc946a742 libgo/Makefile.am
--- a/libgo/Makefile.am Tue Jan 20 13:28:34 2015 -0800
+++ b/libgo/Makefi
Hi Jerry et al.,
Jerry DeLisle wrote:
I have added the following to libgfortran.h and used them (see patch)
/* Special unit numbers used to convey certain conditions. Numbers -3
thru -9 available. NEWUNIT values start at -10. */
#define GFC_INTERNAL_UNIT -1
#define GFC_INVALID_UNIT -2
On Wed, Jan 21, 2015 at 8:51 AM, Jakub Jelinek wrote:
> On Wed, Jan 21, 2015 at 08:41:46AM -0800, pins...@gmail.com wrote:
>> > On Jan 21, 2015, at 1:02 AM, Matthias Klose wrote:
>> >
>> > __objc_get_forward_imp and get_imp were exported in libobjc since GCC 4.1,
>> > for
>> > some reason these
On Tue, 2015-01-20 at 20:05 +0900, Kaz Kojima wrote:
> Oleg Endo wrote:
> > The updated treg_set_expr patch is attached, which should fix the GBR
> > issues. Tests here OK.
> > Kaz, could you please try again?
>
> New tests that FAIL:
>
> libgomp.fortran/udr14.f90 -O3 -g (internal compiler e
Hi everyone,
This is a follow-up to a change [1] in glibc. It fixes the issue [2] when
jal can not reach a target in different region.
It has been tested with DejaGnu for mips32/o32, mips64/n32 and mips64/n64.
Let me know what you think.
Regards,
Petar
[1]
https://sourceware.org/git/gitweb.cgi
On 21/01/15 23:30 +0100, François Dumont wrote:
On 20/01/2015 13:00, Jonathan Wakely wrote:
On 19/01/15 17:16 +, Jonathan Wakely wrote:
This is the last missing piece of the C++14 library, as proposed in
http://www.open-std.org/JTC1/sc22/wg21/docs/papers/2013/n3657.htm
Tested x86_64-linux,
On 21/01/15 23:30 +0100, François Dumont wrote:
+#if __cplusplus > 201103L
+ template
+ std::pair
+ equal_range(const _Kt& __x)
+ {
+ std::pair<_Base_iterator, _Base_iterator> __res =
+ _Base::equal_range(__x);
+ return std::make_pair(iterator(__re
On 01/21/2015 03:33 PM, Tobias Burnus wrote:
Hi Jerry et al.,
Jerry DeLisle wrote:
I have added the following to libgfortran.h and used them (see patch)
/* Special unit numbers used to convey certain conditions. Numbers -3
thru -9 available. NEWUNIT values start at -10. */
#define GFC_INT
The Go frontend incorrectly accepted ... with a call returning
multiple results, as in
f(g()...)
This is invalid and should not be accepted. This patch from Chris
Manghane fixes the problem. This is Go issue 9525. Bootstrapped and
ran Go testsuite on x86_64-unknown-linux-gnu. Committed to m
The gotools Makefile was written to install cgo using
--program-transform-name. That does not make sense, as cgo is an
internal program and the go tool will always look for the exact name
"cgo". This patch fixes the problem by always installing cgo as
"cgo". Bootstrapped and installed on x86_64-
> On 21/01/15 09:22, Yangfei (Felix) wrote:
> > This is a ping for:
> > https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01008.html
> > I updated the testcase adding test for vfmsq_n_f64 intrinsic.
> > Test OK for both aarch64-linux-gnu and aarch64_be-linux-gnu-gcc.
> > OK for the trunk? Thanks.
> >
On Wed, Jan 21, 2015 at 3:51 AM, Jonathan Wakely wrote:
> "Conform to ..."
>
>> standard interface.
>> * testsuite/28_regex/basic_regex/assign/char/cstring.cc: New
>> testcase.
>
>
> As it's a tiny change it's OK for trunk with that tweak to the changelog.
>
> (Any more non-regress
On Wed, Jan 21, 2015 at 4:12 AM, Jonathan Wakely wrote:
> Could this use "digit" instead of "alpha" so it shifts to "chfhs"
> instead of something with non-alphabetic characters?
Fixed and committed.
--
Regards,
Tim Shen
Hi DJ,
as discussed in the PR 50928, this patch fixes the generation of the m32c
target,
and seems to be at least a major step in the right direction.
Successfully built a bare-metal cross-compiler for m32c-elf using binutils-2.25.
OK for trunk and/or 4.9?
Thanks
Bernd.
On Wed, Jan 21, 2015 at 9:08 PM, Tim Shen wrote:
> Fixed and committed.
Submitted version.
--
Regards,
Tim Shen
commit 62662ecc7defacdd82f9a9c6e62a563b4a094726
Author: timshen
Date: Thu Jan 22 05:02:38 2015 +
PR libstdc++/64649
* include/bits/regex.tcc (regex_traits<>::
Am 22.01.2015 um 03:31 schrieb Jerry DeLisle:
Also, I miss the test case. I assume that you still include it, don't
you?
Yes test case will be included.
With those corrections OK?
Yes. Thanks for the patch!
Tobias
> -Original Message-
> From: Richard Henderson [mailto:r...@redhat.com]
> Sent: Thursday, January 22, 2015 5:24 AM
> To: Thomas Preud'homme; gcc-patches@gcc.gnu.org; 'Richard Biener'
> Subject: Re: [PATCH] Don't check for optab for 16bit bswap
>
> On 12/29/2014 06:04 AM, Thomas Preud'hom
1 - 100 of 101 matches
Mail list logo
