On Thu, Dec 5, 2013 at 8:46 AM, Kirill Yukhin wrote:
>> Oh, no. We don't want assembly in this century ;)
> Whoops, sorry. I was trying to do it with minimal changes.
>
> I've implemented approach you proposed.
>
> Batch in the bottom.
> Bootstrapped. New tests pass.
>
> Is it ok now?
>
> ChangeL
Hi,
Andreas Krebbel an I have ported the function hotpatching feature
from i386 (aka ms_hook_prologue attribute) to S/390. Andreas has
already internally approved the attached patch and will commit it
soon (for legal reasons he has to do that himself).
The attached patch introduces command line
On Thu, Dec 05, 2013 at 10:12:36AM +0400, max wrote:
> Hello,
>
> Here is a patch with initial ThreadSanitizer testsuite. It basically
> adds several tests from upstream LLVM testsuite.
> It works fine on x86_64 with patch from
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 applied.
>
> Ok t
On Thu, Dec 05, 2013 at 11:39:17AM +0400, Konstantin Serebryany wrote:
> On Wed, Dec 4, 2013 at 6:16 PM, Jakub Jelinek wrote:
> > On Wed, Dec 04, 2013 at 06:09:56PM +0400, Konstantin Serebryany wrote:
> >> This is a maintenance problem because we can not test if we broke
> >> something during deve
On Wed, 2013-12-04 20:19:29 -0700, Jeff Law wrote:
> This patch splits up the erroneous path optimization into two
> pieces. One which detects NULL dereferences and isolates those paths
> and a second which detects passing/returning a NULL pointer in cases
> where an attribute says a non-NULL valu
On Thu, Dec 05, 2013 at 11:51:12AM +0400, Konstantin Serebryany wrote:
> Committed upstream:
> http://llvm.org/viewvc/llvm-project?view=revision&revision=196480
LGTM, can we commit it after the merge you have already prepared, or do you
want to do another merge for it?
Alternatively, rather than
my 2c: running all upstream tsan tests (ninja check-tsan) takes 10
seconds on my (beefy) machine and requires rather little memory.
Of course, you need lots of *virtual* memory.
On Thu, Dec 5, 2013 at 12:07 PM, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 10:12:36AM +0400, max wrote:
>> Hello,
On Thu, Dec 5, 2013 at 12:18 PM, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 11:51:12AM +0400, Konstantin Serebryany wrote:
>> Committed upstream:
>> http://llvm.org/viewvc/llvm-project?view=revision&revision=196480
>
> LGTM, can we commit it after the merge you have already prepared, or do you
On Thu, Dec 05, 2013 at 12:30:21PM +0400, Konstantin Serebryany wrote:
> my 2c: running all upstream tsan tests (ninja check-tsan) takes 10
> seconds on my (beefy) machine and requires rather little memory.
> Of course, you need lots of *virtual* memory.
*virtual* memory is acceptable, not very ni
On Thu, Dec 05, 2013 at 10:42:35AM +0400, Yury Gribov wrote:
> This patch fixes http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369
> by disabling Linux-specific test on non-Linux platforms. Tested on
> x86_64-apple-darwin.
>
> Ok to commit?
Ok, thanks.
> 2013-12-05 Yury Gribov
>
> PR sa
Hi,
When building GCC on OSX with its native XCode/Clang tools, it outputs
quite some "struct X was previously declared as a class" or similar
warnings (-Wmismatched-tags is enabled by default).
The attached patch fixes this for class opt_pass and class
ipa_opt_pass_d by removing the redundant 's
On Wed, Dec 4, 2013 at 2:27 PM, Bill Schmidt
wrote:
> On Wed, 2013-12-04 at 07:13 -0600, Bill Schmidt wrote:
>> On Wed, 2013-12-04 at 11:30 +0100, Richard Biener wrote:
>> > On Wed, Dec 4, 2013 at 11:26 AM, Richard Biener
>> > wrote:
>> > > On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
>> > > wr
Hi,
When building GCC on OSX with its native XCode/Clang tools, it outputs
quite some "struct X was previously declared as a class" or similar
warnings (-Wmismatched-tags is enabled by default).
The attached patch fixes this for class varpool_node by removing the
redundant 'struct' tag which seem
On Wed, Dec 4, 2013 at 5:47 PM, H.J. Lu wrote:
> On Wed, Dec 4, 2013 at 8:41 AM, Ian Lance Taylor wrote:
>> On Wed, Dec 4, 2013 at 8:04 AM, FX wrote:
> Well, it regresses against 4.8, so it still is a P1 regression.
Does anyone care?
>>>
>>>
>>> Well, you’re one of the maintainers
Hi,
When building GCC on OSX with its native XCode/Clang tools, it outputs
quite some "struct X was previously declared as a class" or similar
warnings (-Wmismatched-tags is enabled by default).
The attached patch fixes a mismatch in struct vec_prefix when referring
to struct vec.
Tested with ma
> On Dec 5, 2013, at 12:48 AM, Oleg Endo wrote:
>
> Hi,
>
> When building GCC on OSX with its native XCode/Clang tools, it outputs
> quite some "struct X was previously declared as a class" or similar
> warnings (-Wmismatched-tags is enabled by default).
>
> The attached patch fixes this for
On Thu, Dec 5, 2013 at 9:18 AM, Jan-Benedict Glaw wrote:
> On Wed, 2013-12-04 20:19:29 -0700, Jeff Law wrote:
>> This patch splits up the erroneous path optimization into two
>> pieces. One which detects NULL dereferences and isolates those paths
>> and a second which detects passing/returning a
On Mon, Dec 02, 2013 at 03:52:09PM +0400, Konstantin Serebryany wrote:
> Expected ChangeLog entries:
> === libsanitizer/ChangeLog
>
> 2013-12-0X Kostya Serebryany
>
> * All source files: Merge from upstream r196090.
> * tsan/Makefile.am (tsan_files): Added new files.
>
This fixes PR59374, dependence analysis during BB SLP handles cases
that depend on the order of vectorized stmt generation in which case
it ignores WAR dependencies. But that of course only applies to
references that participate in the vectorization.
Bootstrapped and tested on x86_64-unknown-lin
> On Dec 5, 2013, at 1:00 AM, Oleg Endo wrote:
>
> Hi,
>
> When building GCC on OSX with its native XCode/Clang tools, it outputs
> quite some "struct X was previously declared as a class" or similar
> warnings (-Wmismatched-tags is enabled by default).
>
> The attached patch fixes a mismatch
On Thu, Dec 5, 2013 at 6:57 AM, Joseph S. Myers wrote:
> Index: c-family/c-common.c
> ===
> --- c-family/c-common.c (revision 205668)
> +++ c-family/c-common.c (working copy)
> @@ -4921,14 +4921,17 @@ c_common_get_alias_set (tree t)
This adjusts the testcase to not require float vector division,
maybe the cause the testcase fails on arm and ppc (just a guess).
Installed.
Richard.
2013-12-05 Richard Biener
PR tree-optimization/56787
* gcc.dg/vect/pr56787.c: Adjust to not require vector float
divi
On Thu, 2013-12-05 17:16:53 +0800, Bin.Cheng wrote:
> On Thu, Dec 5, 2013 at 6:57 AM, Joseph S. Myers
> wrote:
> > Index: c-family/c-common.c
> > ===
> > --- c-family/c-common.c (revision 205668)
> > +++ c-family/c-common.c (working
On Thu, 2013-12-05 at 01:11 -0800, pins...@gmail.com wrote:
>
> > On Dec 5, 2013, at 1:00 AM, Oleg Endo wrote:
> >
> > Hi,
> >
> > When building GCC on OSX with its native XCode/Clang tools, it outputs
> > quite some "struct X was previously declared as a class" or similar
> > warnings (-Wmisma
> On Dec 5, 2013, at 1:33 AM, Oleg Endo wrote:
>
>> On Thu, 2013-12-05 at 01:11 -0800, pins...@gmail.com wrote:
>>
>>> On Dec 5, 2013, at 1:00 AM, Oleg Endo wrote:
>>>
>>> Hi,
>>>
>>> When building GCC on OSX with its native XCode/Clang tools, it outputs
>>> quite some "struct X was previou
>> * Makefile.am (gcc_version): added gcc_version.
> Capital letter A here.
Thanks, fixed.
> Ok
Done in r205698.
-Y
Fixed in r205699.
Another libsanitizer merge from upstream, r196489
(Quick follow up after the r196090 merge)
Fixes (hopefully) .cfi and ppc32 support.
Tested on x86_64 Linux Ubuntu 12.04 box:
make -j 40 -C gcc check-g{cc,++}
RUNTESTFLAGS='--target_board=unix\{-m32,-m64\} asan.exp'
The ubsan testing fails, but th
Ping. The implementation has been commited.
On Thu, Nov 28, 2013 at 01:32:24PM +0100, Marek Polacek wrote:
> As promised, this patch on top of this patch by Tobias:
> http://gcc.gnu.org/ml/gcc-patches/2013-11/msg03082.html
> adds the documentation for -fsanitize=signed-integer-overflow.
>
> Ok t
On Thu, 2013-12-05 at 01:00 -0800, pins...@gmail.com wrote:
>
>
> No I don't think we want this at all. C++ is clear here. In fact we
> don't turn on werror for stage 1 for this exact reason. Rather it
> might be better to check if that flag to turn off the warning and use
> that. Also this w
On Thu, Dec 05, 2013 at 02:06:52PM +0400, Konstantin Serebryany wrote:
> Another libsanitizer merge from upstream, r196489
> (Quick follow up after the r196090 merge)
>
> Fixes (hopefully) .cfi and ppc32 support.
>
> Tested on x86_64 Linux Ubuntu 12.04 box:
> make -j 40 -C gcc check-g{cc,++}
> RU
This fixes the issue in linux/vt.h that appears in SUSE SLE11 kernel
headers which contain a pre-release variant that is broken and not
compatible with C++ (using the 'new' keyword).
The following fix simply replaces that (and only that) field with
'newev', the upstream choice.
fixinclude-tested
> Instead of mentioning the directory in the ChangeLog,
> mention the individual test files.
> ...
>* g++.dg/dg.exp: Prune tsan subdirectory.
Thanks, I fixed the ChangeLog file.
> how long does it take to run make check-gcc check-g++
RUNTESTFLAGS=tsan.exp ?
> How much memory does it need?
On 05 Dec 09:01, Uros Bizjak wrote:
> On Thu, Dec 5, 2013 at 8:46 AM, Kirill Yukhin wrote:
> > + emit_insn (gen_push (gen_rtx_REG (CCmode, FLAGS_REG)));
>
> The FLAGS_REG shuold be generated in an integer mode, appropriate for the
> push!
I suppose, `word_mode' is correct mode throughout the
On Thu, Dec 05, 2013 at 02:19:35PM +0400, Maxim Ostapenko wrote:
> > Instead of mentioning the directory in the ChangeLog,
> > mention the individual test files.
> > ...
> >* g++.dg/dg.exp: Prune tsan subdirectory.
>
> Thanks, I fixed the ChangeLog file.
>
> > how long does it take to run mak
On Thu, Dec 5, 2013 at 11:20 AM, Kirill Yukhin wrote:
>> > + emit_insn (gen_push (gen_rtx_REG (CCmode, FLAGS_REG)));
>>
>> The FLAGS_REG shuold be generated in an integer mode, appropriate for the
>> push!
> I suppose, `word_mode' is correct mode throughout these built-ins expanding.
>
>> >
Hi,
On Thu, Dec 05, 2013 at 02:06:52PM +0400, Konstantin Serebryany wrote:
> Another libsanitizer merge from upstream, r196489
> (Quick follow up after the r196090 merge)
That commit breaks the build with:
In file included from ../../../../libsanitizer/tsan/tsan_rtl_report.cc:18:0:
../../../../l
On Thu, Dec 05, 2013 at 02:51:44PM +0400, Maxim Ostapenko wrote:
> >2013-12-05 Max Ostapenko
> >2013-12-05 Max Ostapenko actually.
>
> Ok, I'm sorry, I'll fix it. Ok to commit?
Sure, that was the "Ok, thanks." in the previous mail.
Jakub
> 2013-12-05 Max Ostapenko < m.ostape...@partner.samsung.com >
> 2013-12-05 Max Ostapenko actually.
Ok, I'm sorry, I'll fix it. Ok to commit?
-Maxim
2013-12-05 Max Ostapenko
* c-c++-common/tsan/atomic_stack.c: New test.
* c-c++-common/tsan/fd_pipe_race.c: New test.
Hello,
This patch adds details about new AMD cores that got enabled in GCC-4.9.
OK for the wwwdocs?
Regards
Ganesh
cvs diff: Diffing .
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving rev
clang' build is broken for me the same way
Dmitry
2013/12/5 Tobias Burnus :
> Hi,
>
> On Thu, Dec 05, 2013 at 02:06:52PM +0400, Konstantin Serebryany wrote:
>> Another libsanitizer merge from upstream, r196489
>> (Quick follow up after the r196090 merge)
>
> That commit breaks the build with:
>
>
hi all,
*We found that COND_EXEC is better than IF_THEN_ELSE when used as expressing
condition move insns, because in sched, IF_THEN_ELSE insn has a dependence
on itself, and COND_EXEC has not.
* Besides, IF_THEN_ELSE is not good for SMS. some backend (frv) expands
condition move as IF_THEN_ELSE
On Thu, Dec 5, 2013 at 3:06 PM, Дмитрий Дьяченко wrote:
> clang' build is broken for me the same way
Should be fixed now (only configure/make build was affected and I
tested the cmake build before committing)
>
> Dmitry
>
> 2013/12/5 Tobias Burnus :
>> Hi,
>>
>> On Thu, Dec 05, 2013 at 02:06:52P
On Thu, Dec 5, 2013 at 11:12 AM, Oleg Endo wrote:
> On Thu, 2013-12-05 at 01:00 -0800, pins...@gmail.com wrote:
>>
>>
>> No I don't think we want this at all. C++ is clear here. In fact we
>> don't turn on werror for stage 1 for this exact reason. Rather it
>> might be better to check if that fla
"Joseph S. Myers" writes:
> @@ -4994,6 +4997,22 @@ c_sizeof_or_alignof_type (location_t loc,
> value = size_binop_loc (loc, CEIL_DIV_EXPR, TYPE_SIZE_UNIT (type),
> size_int (TYPE_PRECISION (char_type_node)
> / BITS_PER_UN
On Thu, 5 Dec 2013, Gopalasubramanian, Ganesh wrote:
> This patch adds details about new AMD cores that got enabled in GCC-4.9.
> OK for the wwwdocs?
Yes, thanks.
Gerald
When we're passing ADDR_EXPR of long long int argument in -m32 mode,
the ADDR_EXPR's VAR_DECL has to have its DECL_RTL set and
corresponding stack slot allocated, it seems. Otherwise we ICE
when expanding a function with such argument. This patch does that
and adds a testcase for it.
Bootstrappe
>> Ok to commit?
> Sure, that was the "Ok, thanks." in the previous mail.
Commited in r205704.
-Y
On Thu, Dec 05, 2013 at 12:26:25PM +0100, Marek Polacek wrote:
> --- gcc/ubsan.h.mp2013-12-05 11:25:18.979469651 +0100
> +++ gcc/ubsan.h 2013-12-05 11:25:28.958507098 +0100
> @@ -41,7 +41,7 @@ extern tree ubsan_instrument_unreachable
> extern tree ubsan_create_data (const char *, locatio
On Thu, 2013-12-05 at 12:21 +0100, Richard Biener wrote:
> On Thu, Dec 5, 2013 at 11:12 AM, Oleg Endo wrote:
> > On Thu, 2013-12-05 at 01:00 -0800, pins...@gmail.com wrote:
> >>
> >>
> >> No I don't think we want this at all. C++ is clear here. In fact we
> >> don't turn on werror for stage 1 for
On Thu, Dec 05, 2013 at 12:22:22PM +0100, Andreas Schwab wrote:
> "Joseph S. Myers" writes:
>
> > @@ -4994,6 +4997,22 @@ c_sizeof_or_alignof_type (location_t loc,
> > value = size_binop_loc (loc, CEIL_DIV_EXPR, TYPE_SIZE_UNIT (type),
> > size_int (TYPE_PRECISION (c
Ping.
On 19 Nov 12:33, Michael V. Zolotukhin wrote:
> Hi Jakub,
>
> Thanks for the remarks. Updated patch is attached, and my answers are below.
>
> > This will add into the table all "omp declare target" functions, but you
> > actually want there only the outlined #pragma omp target bodies.
>
Hi!
This patch improves a little bit the generic expansion of
UBSAN_CHECK_{ADD,SUB} by either making sure that if one of the
operands is CONST_INT, it is the second one (so that the first compare
+ conditional jump is folded) or by looking at value ranges if we can prove
one of the arguments is ei
On Thu, Dec 05, 2013 at 12:43:03PM +0100, Marek Polacek wrote:
> The following should fix it.
>
> 2013-12-05 Marek Polacek
>
> c-family/
> * c-common.c (c_sizeof_or_alignof_type): Move a declaration into
> [ADJUST_FIELD_ALIGN].
Ok, thanks.
Jakub
On Thu, Dec 05, 2013 at 12:51:09PM +0100, Jakub Jelinek wrote:
> For ubsan_expand_si_overflow_neg_check, I think tree-vrp.c change can be
> improved to handle also anti ranges, if the first argument of
> UBSAN_CHECK_SUB has value range [0, 0] and second argument anti-range
> ~[x, y] where x is mini
On 12/04/13 13:08, Bill Schmidt wrote:
On Wed, 2013-12-04 at 11:26 +0100, Richard Biener wrote:
On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
wrote:
On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
Yufeng Zhang wrote:
On 12/03/13 14:20, Richard Biener wrote:
On Tue, Dec 3, 2013 at
On 12/05/2013 10:45 AM, pins...@gmail.com wrote:
On Dec 5, 2013, at 1:33 AM, Oleg Endo wrote:
On Thu, 2013-12-05 at 01:11 -0800, pins...@gmail.com wrote:
On Dec 5, 2013, at 1:00 AM, Oleg Endo wrote:
Hi,
When building GCC on OSX with its native XCode/Clang tools, it outputs
quite some "
On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law wrote:
> On 12/03/13 22:08, Konstantin Serebryany wrote:
>>
>> We need
>> a) patches that we can review and apply to the llvm repository (w/o
>> breaking the modern systems, of course)
>> b) a buildbot that would run 24/7 catching regressions.
>>
>> If we r
On Thu, Dec 5, 2013 at 4:22 PM, Konstantin Serebryany
wrote:
> On Thu, Dec 5, 2013 at 1:05 AM, Jeff Law wrote:
>> On 12/03/13 22:08, Konstantin Serebryany wrote:
>>>
>>> We need
>>> a) patches that we can review and apply to the llvm repository (w/o
>>> breaking the modern systems, of course)
>>>
Hi Richard,
I had just an idea how to solve that recursion problem without completely
ignoring the
memory mode. I hope you are gonna like it.
This time I even added a comment :-)
Ok for trunk after boot-strap and regression-testing?
Bernd.
On Tue, 3 Dec 2013 12:23:11, Richard Biener wrote:
>
> The kernel and glibc check should be done at the toplevel.
> So what are the minimum kernel and glibc we want to
> support?
For us, the versions we want to support are those that have green
upstream buildbots and someone to keep them green.
It's hard or impossible to set a more precise combinati
On Thu, Dec 5, 2013 at 3:18 AM, Konstantin Serebryany
wrote:
> On Thu, Dec 5, 2013 at 3:06 PM, Дмитрий Дьяченко wrote:
>> clang' build is broken for me the same way
>
> Should be fixed now (only configure/make build was affected and I
> tested the cmake build before committing)
>
>>
>> Dmitry
>>
On Thu, Dec 5, 2013 at 4:47 AM, H.J. Lu wrote:
> On Thu, Dec 5, 2013 at 3:18 AM, Konstantin Serebryany
> wrote:
>> On Thu, Dec 5, 2013 at 3:06 PM, Дмитрий Дьяченко wrote:
>>> clang' build is broken for me the same way
>>
>> Should be fixed now (only configure/make build was affected and I
>> tes
On Thu, Dec 5, 2013 at 4:47 PM, H.J. Lu wrote:
> On Thu, Dec 5, 2013 at 3:18 AM, Konstantin Serebryany
> wrote:
>> On Thu, Dec 5, 2013 at 3:06 PM, Дмитрий Дьяченко wrote:
>>> clang' build is broken for me the same way
>>
>> Should be fixed now (only configure/make build was affected and I
>> tes
On Thu, Dec 05, 2013 at 04:54:23AM -0800, H.J. Lu wrote:
> I am testing this for the libm issue.
Preapproved with proper ChangeLog entry if it works.
> --- a/libsanitizer/configure.ac
> +++ b/libsanitizer/configure.ac
> @@ -87,7 +87,7 @@ AM_CONDITIONAL(LSAN_SUPPORTED, [test
> "x$LSAN_SUPPORTED" =
On Thu, Dec 5, 2013 at 4:59 AM, Konstantin Serebryany
wrote:
> On Thu, Dec 5, 2013 at 4:47 PM, H.J. Lu wrote:
>> On Thu, Dec 5, 2013 at 3:18 AM, Konstantin Serebryany
>> wrote:
>>> On Thu, Dec 5, 2013 at 3:06 PM, Дмитрий Дьяченко wrote:
clang' build is broken for me the same way
>>>
>>> Sh
On Wed, Dec 4, 2013 at 7:19 PM, Jeff Law wrote:
> As discussed late in this thread:
>
> http://gcc.gnu.org/ml/gcc/2013-11/msg00345.html
>
>
> This patch splits up the erroneous path optimization into two pieces. One
> which detects NULL dereferences and isolates those paths and a second which
> de
H.J. Lu wrote:
On Wed, Dec 4, 2013 at 9:29 AM, Jeff Law wrote:
On 12/04/13 09:14, H.J. Lu wrote:
+
+/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
aarch64*-*-* } } } */
Any particular reason why it doesn't work for x86?
I don't think so. I'm pretty sure Tejas is foc
On Thu, 2013-12-05 at 12:02 +, Yufeng Zhang wrote:
> On 12/04/13 13:08, Bill Schmidt wrote:
> > On Wed, 2013-12-04 at 11:26 +0100, Richard Biener wrote:
> >> On Tue, Dec 3, 2013 at 11:04 PM, Bill Schmidt
> >> wrote:
> >>> On Tue, 2013-12-03 at 21:35 +0100, Richard Biener wrote:
> Yufeng
On Thu, Dec 5, 2013 at 5:17 AM, Tejas Belagod wrote:
> H.J. Lu wrote:
>>
>> On Wed, Dec 4, 2013 at 9:29 AM, Jeff Law wrote:
>>>
>>> On 12/04/13 09:14, H.J. Lu wrote:
>>>
> +
> +/* { dg-final { scan-rtl-dump "deleting noop move" "combine" { target
> aarch64*-*-* } } } */
> Hello,
>there are dumps for Inkscape, it looks very well. There are few of
> functions that look like this (wpa cgraph):
>
> _ZL13resync_activeP19_EgeSelectOneActionii/2604322 (resync_active)
> @0x7f84af42cea0
> Type: function definition analyzed
> Visibility: prevailing_def_ironly
> R
> Can you, please, send me the -flto systemtaps for gimp and/or inkscape so we
> can decide
> on the patch? We should enable it earlier in stage3 rather than later.
I see, the PDF was included within the tar file. Was this with
-freorder-blocks-and-partition? If so, the patch is OK.
I still thi
Hello,
On 05 Dec 05:30, H.J. Lu wrote:
> Kirill, can you take a look why it doesn't work for x86?
Okay, I'll look at this.
--
Thanks, K
On Thu, Dec 5, 2013 at 12:41 PM, Oleg Endo wrote:
> On Thu, 2013-12-05 at 12:21 +0100, Richard Biener wrote:
>> On Thu, Dec 5, 2013 at 11:12 AM, Oleg Endo wrote:
>> > On Thu, 2013-12-05 at 01:00 -0800, pins...@gmail.com wrote:
>> >>
>> >>
>> >> No I don't think we want this at all. C++ is clear h
On 12/05/13 13:21, Bill Schmidt wrote:
On Thu, 2013-12-05 at 12:02 +, Yufeng Zhang wrote:
On 12/04/13 13:08, Bill Schmidt wrote:
On Wed, 2013-12-04 at 11:26 +0100, Richard Biener wrote:
[snip]
I'm not sure what you're suggesting that he use get_inner_reference on
at this point. At the p
On Thu, Dec 5, 2013 at 1:27 PM, Bernd Edlinger
wrote:
> Hi Richard,
>
> I had just an idea how to solve that recursion problem without completely
> ignoring the
> memory mode. I hope you are gonna like it.
>
> This time I even added a comment :-)
Ehm, ...
+ /* If MODE has no size i.e. BLKm
On Thu, 2013-12-05 at 14:56 +0100, Richard Biener wrote:
> > but they are used somewhere else. I could replace the uses of those
> > typedefs in a follow up patch, but for now I wanted to keep the changes
> > minimal.
>
> I didn't mean those cerating typedefs for the pointer type.
>
> >> and re
On Thu, Dec 5, 2013 at 4:59 AM, Konstantin Serebryany
wrote:
> On Thu, Dec 5, 2013 at 4:47 PM, H.J. Lu wrote:
>>
>> There are at least 2 fallouts:
>>
>> 1. -mx32 is broken.
>
> Please send a patch to the llvm-commits list
>
I am enclosing 2 patches here. You can test x32 on Ubuntu
13.04 or newe
On Thu, Dec 5, 2013 at 5:00 AM, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 04:54:23AM -0800, H.J. Lu wrote:
>> I am testing this for the libm issue.
>
> Preapproved with proper ChangeLog entry if it works.
>
>> --- a/libsanitizer/configure.ac
>> +++ b/libsanitizer/configure.ac
>> @@ -87,7 +87,
Hi!
Here is a patch that changes the splay tree implementation. Specifically,
generalizes the implementation so that it can be used by other functions
outside of its use by the functions within target.c.
Would appreciate review of the changes.
Thanks!
Generalize splay tree implementa
This finally fixes PR59058.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
Richard.
2013-12-05 Richard Biener
PR tree-optimization/59058
* tree-vectorizer.h (struct _loop_vec_info): Add num_itersm1
member.
(LOOP_VINFO_NITERSM1): New macro.
This is a fix of a wrong warning for a bas ISR name. The assumption was that
if DECL_ASSEMBLER_NAME is set, it would always starts with a *.
This is not the case for LTO compiler where the assembler name is the plain
name of the function (except an assembler name is set).
Thus, do a more res
On Thu, Dec 5, 2013 at 3:53 PM, Georg-Johann Lay wrote:
> This is a fix of a wrong warning for a bas ISR name. The assumption was
> that if DECL_ASSEMBLER_NAME is set, it would always starts with a *.
>
> This is not the case for LTO compiler where the assembler name is the plain
> name of the fu
On Thu, Dec 05, 2013 at 12:37:27PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 12:26:25PM +0100, Marek Polacek wrote:
> > --- gcc/ubsan.h.mp 2013-12-05 11:25:18.979469651 +0100
> > +++ gcc/ubsan.h 2013-12-05 11:25:28.958507098 +0100
> > @@ -41,7 +41,7 @@ extern tree ubsan_instrument_
Hi
On 3 December 2013 21:24, Andrew Pinski wrote:
> +(define_insn "trap"
> + [(trap_if (const_int 1) (const_int 8))]
> + ""
> + "brk #1000")
Please add a type attribute to the pattern. The type attributes are
now shared between arm and aarch64 backends.You should use the
type value intr
Am 12/05/2013 04:09 PM, schrieb Richard Biener:
On Thu, Dec 5, 2013 at 3:53 PM, Georg-Johann Lay wrote:
This is a fix of a wrong warning for a bas ISR name. The assumption was
that if DECL_ASSEMBLER_NAME is set, it would always starts with a *.
This is not the case for LTO compiler where the a
On 3 December 2013 21:24, Andrew Pinski wrote:
> * config/aarch64/t-aarch64 (MULTILIB_OPTIONS): Fix definition so
> that options are conflicting ones.
Looks fine to me, commit it.
/Marcus
On Thu, Dec 05, 2013 at 04:31:20PM +0100, Marek Polacek wrote:
> > > + }
> > > + t = build_fold_addr_expr (var);
> > > + return build2 (COMPOUND_EXPR, TREE_TYPE (t), tem, t);
> >
> > I would expect you want to use this too even if in_expand_p...
>
> Unfortunately, this won't be sufficient
I've applied this patch to include the new C extension __auto_type in the
4.9 release notes.
Index: changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-4.9/changes.html,v
retrieving revision 1.44
diff -u -r1.44 changes.html
--- ch
Jeff Law wrote:
On 12/04/13 09:06, Tejas Belagod wrote:
Richard Sandiford wrote:
Tejas Belagod writes:
Richard Sandiford wrote:
Tejas Belagod writes:
The problem is that one reg rtx can span several hard registers.
E.g. (reg:V4SI 32) might represent one 64-bit register (no. 32),
but it mig
Tejas Belagod wrote:
Hi,
Currently, CANNOT_CHANGE_MODE_CLASS is too restrictive wrt the mode-changes it
allows on FPREGs - it allows none at the moment. In fact, there are many mode
changes that are safe and can be allowed. For example, in a pattern like:
(subreg:SF (reg:V4SF v0) 0)
it
On 12/05/13 09:12, Tejas Belagod wrote:
Now that Kirill's looking at why this doesn't work for x86, could I
check this in without enabling vect-nop-move.c for targets (i?86-*-*
x86_64-*-*)? If not, I'm happy to wait.
Yea, that's fine with me.
jeff
On 4 Dec 2013, at 16:08, "Ian Bolton" wrote:
> Hi,
>
> Currently, on ARM, you have to either call abort() or raise(SIGTRAP)
> to achieve a handy crash.
>
> This patch allows you to instead call __builtin_trap() which is much
> more efficient at falling over because it becomes just a single
> in
PING!
-Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Saturday, November 30, 2013 11:38 PM
> To: 'al...@redhat.com'
> Cc: 'Jakub Jelinek'; 'gcc-patches@gcc.gnu.org'
> Subject: RE: [PING]: [GOMP4] [PATCH] SIMD-Enabled Functions (formerly
> Elemental functions) for C
>
PING!
-Balaji V. Iyer.
> -Original Message-
> From: Iyer, Balaji V
> Sent: Saturday, November 30, 2013 11:53 PM
> To: 'Jakub Jelinek'
> Cc: Aldy Hernandez (al...@redhat.com); 'Jeff Law'; 'gcc-
> patc...@gcc.gnu.org'
> Subject: RE: [GOMP4][PATCH] SIMD-enabled functions (formerly Elemental
On Thu, Dec 5, 2013 at 12:18 AM, Jan-Benedict Glaw wrote:
> On Wed, 2013-12-04 20:19:29 -0700, Jeff Law wrote:
>> This patch splits up the erroneous path optimization into two
>> pieces. One which detects NULL dereferences and isolates those paths
>> and a second which detects passing/returning a
This is the failure of gcc.dg/atomic/c11-atomic-exec-5.c on the SPARC, because
of the missing TARGET_ATOMIC_ASSIGN_EXPAND_FENV hook. The implementation is
heavily inspired from that of glibc; it seems to work fine on Solaris too,
except that the FE_* macros are different from the Linux ones, so
On 12/05/13 09:41, Ian Lance Taylor wrote:
On Thu, Dec 5, 2013 at 12:18 AM, Jan-Benedict Glaw wrote:
On Wed, 2013-12-04 20:19:29 -0700, Jeff Law wrote:
This patch splits up the erroneous path optimization into two
pieces. One which detects NULL dereferences and isolates those paths
and a seco
On Dec 4, 2013, at 10:12 PM, max wrote:
> Here is a patch with initial ThreadSanitizer testsuite. It basically adds
> several tests from upstream LLVM testsuite.
> It works fine on x86_64 with patch from
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59188 applied.
> Ok to commit
Ok.
> should
On Thu, Dec 05, 2013 at 04:44:29PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 05, 2013 at 04:31:20PM +0100, Marek Polacek wrote:
> > > > + }
> > > > + t = build_fold_addr_expr (var);
> > > > + return build2 (COMPOUND_EXPR, TREE_TYPE (t), tem, t);
> > >
> > > I would expect
1 - 100 of 154 matches
Mail list logo
