Hi!
With the new tsan tests, I've noticed that libbacktrace symbolization
doesn't work when the binary is a PIE.
The problem is that in that case we obviously can't use base_address
of 0, the PIE typically will not have 0 bias, that is actually the sole
point of PIEs that their base address is ran
On 11/26/13 03:52, Bin.Cheng wrote:
On Tue, Nov 26, 2013 at 6:06 AM, Jeff Law wrote:
On 11/25/13 02:11, Bin.Cheng wrote:
Slightly tune to make iv cand choosing algorithm more accurate:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg01574.html
It would help if you had some sample codes where
Jeff Law wrote:
> It looks like Jakub took care of it.
True.
On 12/03/13 03:08, Yury Gribov wrote:
> The situation hasn't changed in the last four days.
Thanks. Do you think you can check the patch in question?
It looks like Jakub took care of it.
jeff
On 12/04/13 01:16, Bernd Edlinger wrote:
Looking for some more time your patch may be indeed the easiest
without big re-factoring.
Richard (or Bernd), can you comment on why? Something seems "off" here.
Why do we need to handle inner references here specially? If feels
like we're caterin
builtin-unreachable-6.c when compiled for armv7l has a conditional where
the fall-thru block has no successors (due to __builtin_unreachable) and
is immediately followed by the jump-to block. In this situation there
will be a BARRIER after the fall-thru block (remember, it has no
successors)
tem = (char) 255 + (char) 1;
>>
>> tem is always of type 'char' in GIMPLE (even if later promoted
>> via PROMOTE_MODE) the value-range is a 'char' value-range and thus
>> never will exceed [CHAR_MIN, CHAR_MAX]. The only way you can
>> use that directly is if you can rely on undefined behav
On 12/05/13 21:10, Jan-Benedict Glaw wrote:
On Thu, 2013-12-05 20:49:06 -0700, Jeff Law wrote:
On 12/05/13 14:33, Jan-Benedict Glaw wrote:
On Thu, 2013-12-05 14:22:46 -0700, Jeff Law wrote:
On 12/05/13 14:17, Jan-Benedict Glaw wrote:
[...]
I'd just change this one to be correct for the GN
On 12/04/13 00:49, Bernd Edlinger wrote:
Regarding the consistency of bitregion_start/end ,
they should either both be zero, or
bitregion_start <= bitpos && bitpos+bitsize-1 <= bitregion_end
Presumably to satisfy the consecutive bitfields are a single memory
location stuff from C++11. Thus t
On Thu, 2013-12-05 20:49:06 -0700, Jeff Law wrote:
> On 12/05/13 14:33, Jan-Benedict Glaw wrote:
> > On Thu, 2013-12-05 14:22:46 -0700, Jeff Law wrote:
> > > On 12/05/13 14:17, Jan-Benedict Glaw wrote:
[...]
> I'd just change this one to be correct for the GNU style. If you
> wanted to follow-u
On 12/05/13 02:50, Marek Polacek wrote:
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 -fsaniti
On 12/05/13 14:33, Jan-Benedict Glaw wrote:
On Thu, 2013-12-05 14:22:46 -0700, Jeff Law wrote:
On 12/05/13 14:17, Jan-Benedict Glaw wrote:
diff --git a/gcc/config/score/score.h b/gcc/config/score/score.h
index 5ab7875..e3bb7f0 100644
--- a/gcc/config/score/score.h
+++ b/gcc/config/score/score.
On 30-03-13 18:11, Tom de Vries wrote:
Paolo,
This patch series adds analysis of register usage of functions for usage by IRA.
The original post is here
( http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01234.html ).
This patch uses the information of which registers are clobbered by a call
in IRA
On 30-03-13 18:11, Tom de Vries wrote:
Richard,
This patch series adds analysis of register usage of functions for usage by IRA.
The original post is here
( http://gcc.gnu.org/ml/gcc-patches/2013-01/msg01234.html ).
This patch implements the target hook TARGET_FN_OTHER_HARD_REG_USAGE for ARM.
T
Hi Richard
You mentioned that Micha has a patch pending that enables of zero-step
stores. What is the status of this patch? I could not find it through
searching "Micha".
Thank you!
Cong
On Wed, Oct 16, 2013 at 2:02 AM, Richard Biener wrote:
> On Tue, 15 Oct 2013, Cong Hou wrote:
>
>> Thank
On 14-03-13 10:34, Tom de Vries wrote:
I thought about implementing your optimization for LRA by myself. But it
>is ok if you decide to work on it. At least, I am not going to start
>this work for a month.
>>I'm also currently looking at how to use the analysis in LRA.
>>AFAIU, in lra-constrain
On 27-04-13 12:01, Richard Sandiford wrote:
Tom de Vries writes:
+/* { dg-do run } */
+/* { dg-options "-fuse-caller-save -save-temps" } */
+/* { dg-skip-if "" { *-*-* } { "*" } { "-Os" } } */
+/* Testing -fuse-caller-save optimization option. */
+
+static int __attribute__((noinline))
+bar (
A rather simple fix for an ICE on invalid bug (low-priority 4.8/4.9
regression).
Bootstrapped and regtested without new failure on x86-64-gnu-linux.
OK for the trunk and 4.8?
Tobias
2013-06-12 Tobias Burnus
PR c++/58567
* pt.c (tsubst_omp_for_iterator): Early return for error_mark_node.
> On Thu, 21 Nov 2013, Jan Hubicka wrote:
>
> > >
> > > Why do you need an additional -fparallelism? Wouldn't
> > > -fwpa=... be a better match, matching -flto=...? As we already
> > > pass down a -fwpa option to WPA this would make things easier, no?
> >
> > My plan was to possibly use same o
On Fri, Dec 06, 2013 at 12:19:04AM +0100, Paolo Carlini wrote:
> 2013-12-05 Paolo Carlini
>
> * g++.dg/warn/pr15774-1.C: Adjust expected message.
Thanks.
Jakub
Hi,
On 12/05/2013 11:41 PM, Jakub Jelinek wrote:
On Tue, Dec 03, 2013 at 11:49:03AM +0100, Paolo Carlini wrote:
2013-12-03 Paolo Carlini
* decl.c (duplicate_decls): Replace pairs of errors and permerrors
with error + inform (permerror + inform, respectively).
This broke
g++
> Generically, each iteration of the compare-and-exchange loop should be as
> if the previous iterations hadn't happened, so restoring all the previous
> FP state is right in that sense.
I see.
> With regard to the implementation, the insn patterns for the SPARC
> builtins should specify that the
If a non-type template parameter of a member class template depends on
template parameters from the enclosing class template, we need to use
the partially instantiated version of the member template in deduction.
Tested x86_64-pc-linux-gnu, applying to trunk and 4.8.
commit d77a6d36bd910be2e1b8
On Tue, Dec 03, 2013 at 11:49:03AM +0100, Paolo Carlini wrote:
> 2013-12-03 Paolo Carlini
>
> * decl.c (duplicate_decls): Replace pairs of errors and permerrors
> with error + inform (permerror + inform, respectively).
This broke
g++.dg/warn/pr15774-1.C
test:
/usr/src/gcc/gcc/tests
On Wed, Dec 04, 2013 at 08:14:43AM -0800, H.J. Lu wrote:
> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.dg/vect/vect-nop-move.c
> > @@ -0,0 +1,64 @@
> > +/* { dg-do run } */
> > +/* { dg-require-effective-target vect_float } */
> > +/* { dg-options "-O3 -fdump-rtl-combine-details" } */
Please chang
On Thu, 5 Dec 2013, Eric Botcazou wrote:
> > Note that you could probably just reload the tmp1_var value rather than
> > needing to store the fsr value again to clear exceptions from it, unless
> > there's an architecture-specific reason the tmp1_var value might no longer
> > be the right value to
Tobias Burnus writes:
> Rainer Orth wrote:
>> Unfortunately, this breaks Solaris/SPARC bootstrap:
>>
>> /vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/erfc_scaled.c:64:22:
>> error: 'M_2_SQRTPIl' undeclared (first use in this function)
>> # define _M_2_SQRTPI M_2_SQRTPIl
>>
>> It seems M_2
Rainer Orth wrote:
Unfortunately, this breaks Solaris/SPARC bootstrap:
/vol/gcc/src/hg/trunk/local/libgfortran/intrinsics/erfc_scaled.c:64:22: error:
'M_2_SQRTPIl' undeclared (first use in this function)
# define _M_2_SQRTPI M_2_SQRTPIl
It seems M_2_SQRTPI[lq] are GNU extensions, thus missin
On Thu, 2013-12-05 14:22:46 -0700, Jeff Law wrote:
> On 12/05/13 14:17, Jan-Benedict Glaw wrote:
> >diff --git a/gcc/config/score/score.h b/gcc/config/score/score.h
> >index 5ab7875..e3bb7f0 100644
> >--- a/gcc/config/score/score.h
> >+++ b/gcc/config/score/score.h
> >@@ -757,11 +757,12 @@ typedef
> Hello,
>thank you for the trick in ipa-split.c. It really helped! I
Good!, this patch is pre-approved after testing.
> prepared 2 tests for Inkscape, first was just with my function
> reordering pass. And for the second, I enable also
> -freorder-blocks-and-partition (note: files ending with
Uros Bizjak writes:
> Currently, gfortran.dg/erf_3.F90 FAILs on targets with 128bit
> (quadruple) long double, since high-precision erfc_scaled_r16 gets
> defined only for __float128 quadruple precision.
>
> Attached patch defines this function also for 128bit long double targets.
>
> [BTW: The p
> -Original Message-
> From: Jason Merrill [mailto:ja...@redhat.com]
> Sent: Thursday, December 5, 2013 4:00 PM
> To: Iyer, Balaji V; gcc-patches@gcc.gnu.org
> Cc: Jeff Law
> Subject: Re: _Cilk_spawn and _Cilk_sync for C++
>
> On 12/04/2013 02:45 PM, Jason Merrill wrote:
> + e
On 12/05/13 14:17, Jan-Benedict Glaw wrote:
Hi!
This patch silences warnings (unused static functions, ambiguous
`else') for the score target.
2013-12-05 Jan-Benedict Glaw
* config/score/score.c (score_force_temporary): Delete function.
(score_split_symbol): Ditto.
*
Hi!
This patch silences warnings (unused static functions, ambiguous
`else') for the score target.
2013-12-05 Jan-Benedict Glaw
* config/score/score.c (score_force_temporary): Delete function.
(score_split_symbol): Ditto.
* config/score/score.h (ASM_OUTPUT_ADDR_DIFF_EL
On Thu, Dec 5, 2013 at 1:02 PM, Patrick Marlier
wrote:
> Hi,
>
>
> On 12/05/2013 07:22 PM, H.J. Lu wrote:
>>
>> We'd like to add a new -mtune=ia option for x86 to optimize for both
>> Haswell and Silvermont. Currently, -mtune=ia is aliased to -mtune=slm.
>> We will improve it further for Haswell
Hi,
On 12/05/2013 07:22 PM, H.J. Lu wrote:
We'd like to add a new -mtune=ia option for x86 to optimize for both
Haswell and Silvermont. Currently, -mtune=ia is aliased to -mtune=slm.
We will improve it further for Haswell and Silvermont. Later, we will
update it to future Intel processors.
A
> Note that you could probably just reload the tmp1_var value rather than
> needing to store the fsr value again to clear exceptions from it, unless
> there's an architecture-specific reason the tmp1_var value might no longer
> be the right value to load to clear exceptions. (This is what x86 does
On 12/04/2013 02:45 PM, Jason Merrill wrote:
+ error_at (input_location, "_Cilk_sync cannot be used without
enabling"
+ "Cilk Plus");
+ cp_lexer_consume_token (parser->lexer);
+ if (parser->in_statement & IN_CILK_SPAWN)
+ parser->in_statement = parser->in_sta
On 12/05/13 02:50, Marek Polacek wrote:
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 -fsaniti
On Thu, Dec 5, 2013 at 12:38 PM, Uros Bizjak wrote:
> On Thu, Dec 5, 2013 at 7:22 PM, H.J. Lu wrote:
>
>> We'd like to add a new -mtune=ia option for x86 to optimize for both
>> Haswell and Silvermont. Currently, -mtune=ia is aliased to -mtune=slm.
>> We will improve it further for Haswell and S
On 12/05/13 03:18, Richard Biener wrote:
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
'newe
On Thu, Dec 5, 2013 at 7:22 PM, H.J. Lu wrote:
> We'd like to add a new -mtune=ia option for x86 to optimize for both
> Haswell and Silvermont. Currently, -mtune=ia is aliased to -mtune=slm.
> We will improve it further for Haswell and Silvermont. Later, we will
> update it to future Intel proc
On 11/30/13 20:38, Iyer, Balaji V wrote:
Hello Aldy,
Some of the middle end changes I made in the previous patch was not
flying for the C++. Here is a fixed patch where the middle-end changes will
work for both C and C++.
With this email, I am attaching the patch for C along wit
Hi!
This is a second attempt at libsanitizer symbolization using
libbacktrace. The compiler-rt maintained bit have been
already added by the recent merge from compiler-rt, so this
patch is mostly configury/Makefile stuff. Rather than using
libbacktrace.la built in libbacktrace directory directly
This patch rejects literal operators with defaulted arguments with an extra
note to that effect. Not a big deal but it responds to a "malformed program"
statement in the draft.
Builds and tests clean on x86_64-linux. OK?
Ed
CL_udlit_nodefault
Description: Binary data
patch_udlit_nodefa
The following patch fixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59317
The patch was bootstrapped on x86-64.
Committed as rev. 205718.
2013-12-05 Vladimir Makarov
PR rtl-optimization/59317
* lra-constraints.c (in_class_p): Don't ignore insn with constant
as a sou
Hello,
thank you for the trick in ipa-split.c. It really helped! I
prepared 2 tests for Inkscape, first was just with my function
reordering pass. And for the second, I enable also
-freorder-blocks-and-partition (note: files ending with _blocks.xxx in
attached tar).
Touched pages:
just reorder
On Thu, Dec 5, 2013 at 9:03 AM, Jeff Law wrote:
>
> Q. Now that we're in stage3, presumably GO imports onto the trunk are
> stopping? If so would it make sense to enable GO by default?
The Go library will no longer be updated except for bug fixes. If
there is a Go 1.2.1 release, and if it is re
Hi,
We'd like to add a new -mtune=ia option for x86 to optimize for both
Haswell and Silvermont. Currently, -mtune=ia is aliased to -mtune=slm.
We will improve it further for Haswell and Silvermont. Later, we will
update it to future Intel processors. OK for trunk?
Thanks.
H.J.
---
2013-12-0
Looks good to me.
On Thu, Dec 5, 2013 at 2:18 AM, Richard Biener wrote:
>
> 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 repla
On Thu, Dec 05, 2013 at 06:22:02PM +0100, Jakub Jelinek wrote:
> As a follow-up, please see if all the dg-skip-if -flto
> ubsan markings can be removed now.
Unfortunately, not yet. With -flto, we fail with
cclAoIBG.o:(.text+0x14): undefined reference to `.Lubsan_data0.2616'^M
collect2: error: ld
The following patch fixes two GCC testsuite failures for LRA. The patch
makes swap through registers instead of memory for the test cases when
LRA is used.
There are differences in reload and LRA constraint matching algorithm
which results in different alternative choices when the original pa
On Thu, 5 Dec 2013, Eric Botcazou wrote:
> + /* We generate the equivalent of feclearexcept (FE_ALL_EXCEPT):
> +
> + unsigned int tmp2_var;
> + __builtin_store_fsr (&tmp2_var);
> +
> + tmp2_var &= ~accrued_exception_mask;
> +
> + __builtin_load_fsr (&tmp2_var); */
Note t
On Thu, Dec 05, 2013 at 06:14:03PM +0100, Marek Polacek wrote:
> 2013-12-05 Marek Polacek
>
> PR sanitizer/59333
> PR sanitizer/59397
> * ubsan.c: Include rtl.h and expr.h.
> (ubsan_encode_value): Add new parameter. If expanding, assign
> a stack slot for DECL_RTL
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
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 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
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 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
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
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
>
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
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
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
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
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
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
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
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 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
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
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
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.
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
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,
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, 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 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 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 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
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
> 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,
>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
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*-*-* } } } */
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
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 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
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 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: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 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
>>
> 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
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:
>
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)
>>>
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 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 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 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
1 - 100 of 154 matches
Mail list logo
