On May 16, 2014 4:47:11 AM CEST, Mike Stump wrote:
>This reorders the avx checks and gates on a target triplet check before
>compiling any code.
Can you explain why?
>Ok?
>
>diff --git a/gcc/testsuite/lib/target-supports.exp
>b/gcc/testsuite/lib/target-supports.exp
>index 40b5414..103a28a 100644
I have updated the trunk into the "fortran-dev" branch, which was quite
painful as I got a lot of conflicts when merging libgo (!). Committed as
Rev. 210480 (up to Rev. 208756) and Rev. 210490 (up to current trunk).
Tobias
The IBM XL team defined a set of HTM intrinsic functions that were supposed
to be API compatible across the XL and GCC compilers on both Power and S390.
PR61193 describes an issue where the functions that begin a transaction
are incompatible. The Power intrinsics return non-zero on success, while
On 05/15/2014 03:03 PM, Jonathan Wakely wrote:
Here's a finished patch to simplify
Tested x86_64-linux. Ed, any objection to this version?
This looks great, thanks!
Having done that should we actually stop using it as suggested in the
bug trail? ;-)
This reorders the avx checks and gates on a target triplet check before
compiling any code.
Ok?
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index 40b5414..103a28a 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-sup
> Index: gcc/auto-profile.c
> ===
> --- gcc/auto-profile.c(revision 0)
> +++ gcc/auto-profile.c(revision 0)
> @@ -0,0 +1,1584 @@
> +/* Calculate branch probabilities, and basic block execution counts.
Update the toplev
Hi, debugging runtime bugs due to devirtualization can be hard for
very large C++ programs with complicated class hierarchy. This patch
adds the support to report this high level transformation via
-fopt-info (not hidden inside dump file) and the ability the do binary
search with cutoff.
Ok for tr
Robert Suchanek writes:
> Are you working on the solution to fix the breakage? I'm about
> to look into this and wanted to find out how far we got with this.
You mean the "cleaner way" I suggested, or something else?
If you want to have a go then feel free. Otherwise I'll try to get
to it over t
On Thu, 15 May 2014, Jakub Jelinek wrote:
> But I think we can't use decimal_real_from_string, we'd need a variant
> of that function that would allow specification of the rounding mode
My point is that you can use "%.*RUe" or "%.*RDe" formats (for max and min
respectively), with an appropriate
On May 15, 2014, at 1:01 PM, Jeff Law wrote:
> For the memory optimizations, IIRC, the dependencies keep them from getting
> into the ready queue at the same time. Thus it's significantly harder to get
> them to issue consecutively when you've got an issue rate > 1.
> But if you've got an issu
Ping.
From: Robert Suchanek
Sent: 14 May 2014 14:24
To: Richard Sandiford; Matthew Fortune
Cc: Vladimir Makarov; gcc-patches@gcc.gnu.org; Kyrill Tkachov
Subject: RE: [RFC][PATCH][MIPS] Patch to enable LRA for MIPS backend
Hi Richard,
Are you working on the
> Hi,
>
> I'm planning to port the AutoFDO patch upstream. Attached is the
> prepared patch. You can also find the patch in
> http://codereview.appspot.com/99010043
>
> I've tested the patch with SPECCPU2006. For the CINT2006 benchmarks,
> the speedup comparison between O2, FDO and AutoFDO is as
On 15/05/14 22:20 +0200, François Dumont wrote:
Hi
Here is a proposal to fix PR 61143. As explained in the PR I
finally prefer to leave the container in a valid state that is to say
with a non zero number of bucket, that is to say 1, after a move. This
bucket is stored directly in the cont
> Hi, Honza,
>
> Please find the new patch in the attachment. This patch integrated
> your earlier suggestions. The noticeable changes are:
> (1) build specialized object for libgcov-driver.c and libgcov-merge.c
> and link into gcov-tool, rather including the source file.
> (2) split some gcov cou
Hi,
On 05/15/2014 10:20 PM, François Dumont wrote:
Hi
Here is a proposal to fix PR 61143. As explained in the PR I
finally prefer to leave the container in a valid state that is to say
with a non zero number of bucket, that is to say 1, after a move. This
bucket is stored directly in the
.. in case it would be useful to better analyze the issue and my
tentative fix, I ran the C++ and C++ runtime testsuite with an
appropriate gcc_assert, and the added DIRECT_LIST_INIT_P (init) case
matters only for the existing cpp1y/pr58708.C (besides the new
testcases, of course).
Also, in c
Hi
Here is a proposal to fix PR 61143. As explained in the PR I
finally prefer to leave the container in a valid state that is to say
with a non zero number of bucket, that is to say 1, after a move. This
bucket is stored directly in the container so not allocated to leave the
move operat
On 05/15/14 12:41, Mike Stump wrote:
On May 15, 2014, at 10:13 AM, Jeff Law wrote:
I've poked at the scheduler several times to do similar stuff, but
was never really satisfied with the results and never tried to
polish those prototypes into something worth submitting.
What was lacking? The
On Thu, May 15, 2014 at 09:10:55PM +0200, Jakub Jelinek wrote:
> I guess Toon meant that there is no easy way? to get rid of the color
> stuff in libsanitizer messages.
Yikes. I think there's no way yet; UBSAN_OPTIONS envvar, similar to
e.g. ASAN_OPTIONS, isn't supported yet it seems.
Mar
On 05/15/2014 09:10 PM, Jakub Jelinek wrote:
On Thu, May 15, 2014 at 08:37:07PM +0200, Marek Polacek wrote:
Sure, -fdiagnostics-color=auto "means to use color only when the
standard error is a terminal", or -fdiagnostics-color=never to turn it
off completely (testsuite uses the latter).
I g
On Thu, May 15, 2014 at 08:37:07PM +0200, Marek Polacek wrote:
> > And don't underestimate the *usefulness* of this - if you don't have the
> > resources to do a ubsan bootstrap, download mine from last night
> > (x86_64-linux-gnu): http://moene.org/~toon/gcc-tests.log.gz
> >
> > [ I hope there is
On Wed, May 14, 2014 at 05:37:25PM +, Joseph S. Myers wrote:
> > with s/max/min/;s/dconst1/dconstm1/; and, after the real_convert
> > do inexact = real_arithmetic (&newminval, MINUS_EXPR, &minval, &dconst1);
> > if !inexact just min = build_real (expr_type, newminval); and be done with
> > it (
Here's a finished patch to simplify
Tested x86_64-linux. Ed, any objection to this version?
commit 87d26af2fc07f0c45a0a6676161ae1db1d7541b7
Author: Jonathan Wakely
Date: Wed May 14 16:35:20 2014 +0100
2014-05-15 Ed Smith-Rowland <3dw...@verizon.net>
Jonathan Wakely
> Hi,
>
> the following patch deals with requested propagation in PR 53787 in
> the real benchmark (as opposed to the original simple testcase) by
> analyzing individual BBs in ipa-prop.c in dominator order.
>
> Currently we do the analysis in two loops, in the first the order is
> given by FOR_E
On May 15, 2014, at 10:13 AM, Jeff Law wrote:
> I've poked at the scheduler several times to do similar stuff, but was never
> really satisfied with the results and never tried to polish those prototypes
> into something worth submitting.
What was lacking? The cleanliness of the patch or the,
On Thu, May 15, 2014 at 08:32:36PM +0200, Toon Moene wrote:
> On 05/15/2014 05:08 PM, Marek Polacek wrote:
>
> >On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote:
> >>What's the overhead with bootstrap-ubsan ?
> >
> >I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cor
Optimize access to globals with -fpie, x86_64 only:
Currently, with -fPIE/-fpie, GCC accesses globals that are extern to the module
using the GOT. This is two instructions, one to get the address of the global
from the GOT and the other to get the value. If it turns out that the global
gets defi
On 05/15/2014 05:08 PM, Marek Polacek wrote:
On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote:
What's the overhead with bootstrap-ubsan ?
I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cores,
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (aka cfarm 20) and the results:
On Thu, May 15, 2014 at 12:26 AM, bin.cheng wrote:
> Hi,
> Targets like ARM and AARCH64 support double-word load store instructions,
> and these instructions are generally faster than the corresponding two
> load/stores. GCC currently uses peephole2 to merge paired load/store into
> one single in
On 05/15/14 10:51, Mike Stump wrote:
On May 15, 2014, at 12:26 AM, bin.cheng wrote:
Here comes up with a new GCC pass looking through each basic block
and merging paired load store even they are not adjacent to each
other.
So I have a target that has load and store multiple support that
suppo
On Thu, May 15, 2014 at 9:26 AM, bin.cheng wrote:
> Hi,
> Targets like ARM and AARCH64 support double-word load store instructions,
> and these instructions are generally faster than the corresponding two
> load/stores. GCC currently uses peephole2 to merge paired load/store into
> one single inst
On May 15, 2014, at 12:26 AM, bin.cheng wrote:
> Here comes up with a new GCC pass looking through each basic block and
> merging paired load store even they are not adjacent to each other.
So I have a target that has load and store multiple support that supports large
a number of registers (2-n
One of the two commits breaks sevral fortran tests in 32 bit mode,
see https://gcc.gnu.org/ml/gcc-regression/2014-05/msg00155.html
The ICE is
[Book15] f90/bug% gfc
/opt/gcc/work/gcc/testsuite/gfortran.dg/assumed_charlen_needed_1.f90 -m32 -O
/opt/gcc/work/gcc/testsuite/gfortran.dg/assumed_charlen
Oops, I missed:
gcc/ChangeLog:
2014-05-15 Alan Lawrence
* config/aarch64/aarch64-modes.def: Add V1DFmode.
* config/aarch64/aarch64.c (aarch64_vector_mode_supported_p):
Support V1DFmode.
gcc/testsuite/ChangeLog:
2014-05-15 Alan Lawrence
* gcc.dg/vect/vect-s
This fixes an ICE on AArch64 when compiling code with a vector of exactly one
double, and seems the most specific/accurate way of fixing that specific case.
I've included a test case of a range of other singleton vector types too
(compiles on aarch64-none-elf, x64_64, arm-none-eabi).
No regre
Sure, here is a revised patch (replacing a with __a). I've retested (the various
TBL dependencies have all been committed), no regressions on aarch64-none-elf or
aarch64_be-none-elf. May I propose gcc/ChangeLog:
2014-05-15 Alan Lawrence
* config/aarch64/aarch64-simd.md (aarch64_rev)
On Thu, May 15, 2014 at 05:16:00PM +0200, Jakub Jelinek wrote:
> On Thu, May 15, 2014 at 05:08:10PM +0200, Marek Polacek wrote:
> > On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote:
> > > What's the overhead with bootstrap-ubsan ?
> >
> > I timed normal bootstrap and bootstrap-
On Thu, May 15, 2014 at 05:08:10PM +0200, Marek Polacek wrote:
> On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote:
> > What's the overhead with bootstrap-ubsan ?
>
> I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cores,
> Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (aka c
On Thu, May 15, 2014 at 11:39:26AM +0100, Ramana Radhakrishnan wrote:
> What's the overhead with bootstrap-ubsan ?
I timed normal bootstrap and bootstrap-ubsan on x86_64, 24 cores,
Intel(R) Xeon(R) CPU X5670 @ 2.93GHz (aka cfarm 20) and the results:
--enable-languages=all
real35m10.419s
use
On 05/15/14 08:15, Eric Botcazou wrote:
Seems reasonable. Do you happen to have a testcase where you can see
the effects in one of the dumps?
That's not easy because NON_LVALUE_EXPRs are present only in .original and, at
least in Ada, essentially only in size expressions which are not visible
On Thu, May 15, 2014 at 4:45 PM, Martin Jambor wrote:
> Hi,
>
> PR 61085 revealed that I forgot to put a type_preserved check to an
> important spot, namely to update_indirect_edges_after_inlining, which
> leads to wrong devirtualization because the function does not ignore
> jump functions it sho
On May 15, 2014, at 12:55 AM, Eric Botcazou wrote:
> No, that's too complicated and risky, just do the following:
>
> /* builtin_setjmp takes a pointer to 5 words or pointers. */
> if (POINTER_SIZE > BITS_PER_WORD)
> tmp = size_int (4);
> else
> tmp = size_int (5 * BIT
Hi,
PR 61085 revealed that I forgot to put a type_preserved check to an
important spot, namely to update_indirect_edges_after_inlining, which
leads to wrong devirtualization because the function does not ignore
jump functions it should.
Fixed thusly, bootstrapped and tested on x86_64-linux on bot
On Thu, 15 May 2014, Martin Jambor wrote:
> Hi,
>
> my patch switching to more correct alias introduced an error into the
> call of build_ref_for_model also in sra_modify_expr (when avoiding
> VIEW_CONVERT_EXPR). We are no longer using access->base as the base
> for the memory expression being b
Hi,
my patch switching to more correct alias introduced an error into the
call of build_ref_for_model also in sra_modify_expr (when avoiding
VIEW_CONVERT_EXPR). We are no longer using access->base as the base
for the memory expression being built, but rather the original
expression from the sourc
> Seems reasonable. Do you happen to have a testcase where you can see
> the effects in one of the dumps?
That's not easy because NON_LVALUE_EXPRs are present only in .original and, at
least in Ada, essentially only in size expressions which are not visible in
the dump.
--
Eric Botcazou
Hi,
I'm trying to make progress on these two issues, which seem closely
related to me. Both only happen for NSDMIs in template classes, thus
when cp_parser_late_parse_one_default_arg sees processing_template_decl
!= 0 and doesn't call digest_init_flags directly, thus produces a
CONSTRUCTOR (v
On Thu, May 15, 2014 at 2:37 AM, Richard Sandiford
wrote:
> get_pool_constant can return general constants, not just SYMBOL_REFs,
> so the code does look wrong. In the particular case of CONST flagged up
> in the message, SYMBOL_REF_TLS_MODEL would read beyond the end of the rtx.
> I think you w
Janne Blomqvist wrote:
> libgfortran was happily assuming that STD{IN,OUT,ERR}_FILENO were open
> and no error checking was performed on the fstat() call
> Tested on x86_64-unknown-linux-gnu, Ok for trunk/4.9/4.8/4.7?
Looks good to me. Thanks!
Note that 4.8 has been frozen, cf.
https://gcc.gnu.o
On Thu, 15 May 2014, Marek Polacek wrote:
> On Thu, May 15, 2014 at 01:42:20PM +0100, Richard Sandiford wrote:
> > > It's not, I'm seeing many
> > > /home/marek/src/gcc/gcc/wide-int.h:1734:7: runtime error: shift
> > > exponent 64 is too large for 64-bit type 'long unsigned int'
> > > plus I thin
For some odd reason I didn't implement this earlier. This is one
major source of 2nd-stage opportunities that come up when running
two adjacent FRE passes.
Bootstrap and regtest ongoing on x86_64-unknown-linux-gnu.
Richard.
2014-05-15 Richard Biener
* tree-ssa-sccvn.c (visit_use):
Jakub Jelinek writes:
> On Thu, May 15, 2014 at 02:37:33PM +0200, Rainer Orth wrote:
>> > If OpenMP declare simd doesn't work on Solaris/x86 (due to the bogus hw cap
>> > stuff), then supposedly vect_simd_clones effective target should fail
>> > there.
>>
>> I don't think it's bogus: it guards
On Thu, May 15, 2014 at 01:42:20PM +0100, Richard Sandiford wrote:
> > It's not, I'm seeing many
> > /home/marek/src/gcc/gcc/wide-int.h:1734:7: runtime error: shift
> > exponent 64 is too large for 64-bit type 'long unsigned int'
> > plus I think I remember some other fails.
>
> Yeah, like Richar
On Thu, May 15, 2014 at 02:37:33PM +0200, Rainer Orth wrote:
> > If OpenMP declare simd doesn't work on Solaris/x86 (due to the bogus hw cap
> > stuff), then supposedly vect_simd_clones effective target should fail there.
>
> I don't think it's bogus: it guards against a similar kind of problems
>
Marek Polacek writes:
> On Thu, May 15, 2014 at 12:33:57PM +0200, Jakub Jelinek wrote:
>> On Thu, May 15, 2014 at 11:30:40AM +0100, Richard Sandiford wrote:
>> > Jakub Jelinek writes:
>> > > This patch adds two new options (compatible with clang) which allow
>> > > users to choose the behavior of
On 05/15/2014 06:34 AM, Manuel López-Ibáñez wrote:
This looks great. One minor nit: In this hunk, what is input_location
pointing at and why is that better than loc?
Oops, cut/paste error, thanks.
Also, are there other qualifiers of 'this' besides 'const'?
An object can also be 'volatile'.
Jakub Jelinek writes:
> On Tue, May 13, 2014 at 07:38:52PM +0200, Rainer Orth wrote:
>> Rainer Orth writes:
>>
>> > Jakub Jelinek writes:
>> >
>> >> 2014-04-18 Jakub Jelinek
>> >>
>> >> PR tree-optimization/60823
>> >> * omp-low.c (ipa_simd_modify_function_body): Go through
>> >> all
This adds a dispatch from fold_stmt (!inplace for now) to
match-and-simplify. Mainly to get more testing coverage.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-05-15 Richard Biener
* gimple-fold.c (fold_stmt_1): Dispatch to
gimple_match_and_si
We are missing specializations for wchar_t, char16_t and char32_t.
The preprocessor condition I've added at the top of is
to avoid needing to #include , which drops names in the
global namespace. GCC defines __UINT_LEAST16_TYPE__ and
__UINT_LEAST32_TYPE__ so we can use them, but other compilers
2014-05-15 15:27 GMT+04:00 Richard Biener :
> On Thu, May 15, 2014 at 1:07 PM, Ilya Enkovich wrote:
>> 2014-05-14 19:09 GMT+04:00 H.J. Lu :
>>> On Wed, May 14, 2014 at 1:18 AM, Ilya Enkovich
>>> wrote:
2014-05-13 23:21 GMT+04:00 Jeff Law :
> On 05/13/14 02:38, Ilya Enkovich wrote:
>
On Thu, May 15, 2014 at 5:27 AM, Richard Biener wrote:
>
> Status
> ==
>
> The 4.8 branch is now frozen as I am preparing a first release
> candidate for 4.8.3. All patches to the branch now require
> explicit approval from release managers.
Please hold off on GCC 4.8.3. powerpc-linux has a
On Thu, May 15, 2014 at 1:07 PM, Ilya Enkovich wrote:
> 2014-05-14 19:09 GMT+04:00 H.J. Lu :
>> On Wed, May 14, 2014 at 1:18 AM, Ilya Enkovich
>> wrote:
>>> 2014-05-13 23:21 GMT+04:00 Jeff Law :
On 05/13/14 02:38, Ilya Enkovich wrote:
>>>
>>> propagate constant bounds value and remo
Now with patch attached.
Also forgot to mention.
Tested arm-none-eabi.
Kyrill
On 15/05/14 12:25, Kyrill Tkachov wrote:
Hi all,
The scheduler algorithms are defined in sched-int.h as:
enum sched_pressure_algorithm
{
SCHED_PRESSURE_NONE,
SCHED_PRESSURE_WEIGHTED,
SCHED_PRESSURE_MODEL
Hi all,
The scheduler algorithms are defined in sched-int.h as:
enum sched_pressure_algorithm
{
SCHED_PRESSURE_NONE,
SCHED_PRESSURE_WEIGHTED,
SCHED_PRESSURE_MODEL
};
We should use the enum name SCHED_PRESSURE_MODEL rather than the direct integer
value (2).
This doesn't make any functiona
2014-05-14 19:09 GMT+04:00 H.J. Lu :
> On Wed, May 14, 2014 at 1:18 AM, Ilya Enkovich wrote:
>> 2014-05-13 23:21 GMT+04:00 Jeff Law :
>>> On 05/13/14 02:38, Ilya Enkovich wrote:
>>
>> propagate constant bounds value and remove checks in called function).
>
>
> So from a linking
On Thu, May 15, 2014 at 11:33 AM, Jakub Jelinek wrote:
> On Thu, May 15, 2014 at 11:30:40AM +0100, Richard Sandiford wrote:
>> Jakub Jelinek writes:
>> > This patch adds two new options (compatible with clang) which allow
>> > users to choose the behavior of undefined behavior sanitization.
>> >
On Thu, May 15, 2014 at 12:33:57PM +0200, Jakub Jelinek wrote:
> On Thu, May 15, 2014 at 11:30:40AM +0100, Richard Sandiford wrote:
> > Jakub Jelinek writes:
> > > This patch adds two new options (compatible with clang) which allow
> > > users to choose the behavior of undefined behavior sanitizat
On 15/05/14 07:36 +0200, Daniel Krügler wrote:
Looking at the definition of the new alias
__cv_tuple_size
you might want to apply LWG 2313
http://cplusplus.github.io/LWG/lwg-defects.html#2313
and simplify its definition even further.
I forgot about that. With that resolution the __cv_tuple_
On 14 May 2014 18:47, Jason Merrill wrote:
> When I was working on DR 1571, I noticed that our diagnostics weren't very
> helpful for reference bindings (BZ 20332/21631) so I set out to treat
> lvalue/rvalue mismatches and cv-qual loss as a bad conversion rather than no
> conversion. As I worked
On Thu, May 15, 2014 at 11:30:40AM +0100, Richard Sandiford wrote:
> Jakub Jelinek writes:
> > This patch adds two new options (compatible with clang) which allow
> > users to choose the behavior of undefined behavior sanitization.
> >
> > By default as before, all undefined behaviors (except for
Hi,
On 15 May 2014, at 09:26, "bin.cheng" wrote:
> Hi,
> Targets like ARM and AARCH64 support double-word load store instructions,
> and these instructions are generally faster than the corresponding two
> load/stores. GCC currently uses peephole2 to merge paired load/store into
> one single in
Jakub Jelinek writes:
> This patch adds two new options (compatible with clang) which allow
> users to choose the behavior of undefined behavior sanitization.
>
> By default as before, all undefined behaviors (except for
> __builtin_unreachable and missing return in C++) continue after reporting
>
Jason Merrill writes:
> (print_z_candidate): Say "candidate:" before each candidate.
* obj-c++.dg/exceptions-3.mm: Remove check for message no longer
emitted.
* obj-c++.dg/exceptions-5.mm: Likewise.
diff --git a/gcc/testsuite/obj-c++.dg/exceptions-3.mm
b/gcc/tests
Status
==
The 4.8 branch is now frozen as I am preparing a first release
candidate for 4.8.3. All patches to the branch now require
explicit approval from release managers.
Previous Report
===
https://gcc.gnu.org/ml/gcc/2014-05/msg00026.html
2014-05-14 19:09 GMT+04:00 H.J. Lu :
> On Wed, May 14, 2014 at 1:18 AM, Ilya Enkovich wrote:
>> 2014-05-13 23:21 GMT+04:00 Jeff Law :
>>> On 05/13/14 02:38, Ilya Enkovich wrote:
>>
>> propagate constant bounds value and remove checks in called function).
>
>
> So from a linking
Hi all,
Shifted arithmetic operations can never be encoded in 16-bits in and therefore
can not appear in Thumb2 IT blocks under ARMv8-A rules (and the -mrestrict-it
rules). This patch adjusts the relevant pattern for that purpose.
Tested and bootstrapped on arm-none-linux-gnueabihf and made s
On Thu, May 15, 2014 at 12:20:06PM +0400, Yury Gribov wrote:
> On 05/15/2014 12:05 PM, Konstantin Serebryany wrote:
> >No. We have to support too many build systems and hence do not want
> >any configure step.
> >All configuration has to be done in the sources.
>
> Yeah, I see your point. But fill
On Thu, May 15, 2014 at 12:07 PM, Andrew Pinski wrote:
> On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
> wrote:
>> H.J.,
>> Thanks for the patches. Please (re)send them to llvm-commits,
>> otherwise I can not accept them.
>
>
> I think this is bogus reasoning. You should be able to take
>
> I think this argument is bogus. Please do one build system and
> support it. Simple makefile and some scripts seems simple to support
> so you don't need anything extra.
Would be glad to. One (but not the only) prerequisite for that GCC
exports libsanitizer
as "svn external" and uses our cm
Wei Mi writes:
> Can I checkin this testcase fix?
I think this is for Uros to approve.
Rainer
--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
On 13 May 2014 20:56, Richard Earnshaw wrote:
> On 25/03/14 08:13, Zhenqiang Chen wrote:
>> Hi
>>
>> The patch enables shrink-wrap for apcs frame.
>>
>> Bootstrap and no make check regression in ARM, THUMB1 and THUMB2 modes.
>> No make check regression with "-g/-mapcs/-marm".
>> Build linux-3.14-r
On 05/15/2014 12:05 PM, Konstantin Serebryany wrote:
No. We have to support too many build systems and hence do not want
any configure step.
All configuration has to be done in the sources.
Yeah, I see your point. But filling code with magic constants isn't very
nice either.
We could make a
On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
wrote:
> H.J.,
> Thanks for the patches. Please (re)send them to llvm-commits,
> otherwise I can not accept them.
I think this is bogus reasoning. You should be able to take and post
them yourself. Those patches.
Thanks,
Andrew Pinski
>
H.J.,
Thanks for the patches. Please (re)send them to llvm-commits,
otherwise I can not accept them.
--kcc
On Wed, May 14, 2014 at 2:31 AM, H.J. Lu wrote:
> On Tue, May 13, 2014 at 2:02 AM, Konstantin Serebryany
> wrote:
>> New patch attached.
>> It is based on r208674 which enables LeakSanitiz
On 14 May 2014 22:30, Kyle McMartin wrote:
> The toolchain would like PT_GNU_STACK in our objects for all
> architectures to make it explicit whether we are requesting an
> executable stack or not.
>
> 2014-05-14 Kyle McMartin
>
> * config/aarch64/aarch64-linux.h (TARGET_ASM_FILE_END):
On Thu, May 15, 2014 at 1:05 AM, Konstantin Serebryany
wrote:
> On Thu, May 15, 2014 at 9:28 AM, Yury Gribov wrote:
>> On 05/14/2014 08:51 AM, Konstantin Serebryany wrote:
One theme I have been noticing in the libsanitizer code is that it has
all of the knowledge of glibc when it c
On Thu, May 15, 2014 at 9:28 AM, Yury Gribov wrote:
> On 05/14/2014 08:51 AM, Konstantin Serebryany wrote:
>>>
>>> One theme I have been noticing in the libsanitizer code is that it has
>>> all of the knowledge of glibc when it comes to syscalls but makes some
>>> bad assumptions dealing with some
On Thu, 15 May 2014, Jakub Jelinek wrote:
> Hi!
>
> fold_binary_loc for (X >> C1) & C2, if X is zero extended narrower
> value, decreases prec, but if the shift count is bigger
> than the narrower prec, we then attempt to zerobits <<= negative_value.
>
> In that case the result is necessarily ze
On Wed, May 14, 2014 at 12:56:54PM +0200, Rainer Orth wrote:
> Georg-Johann Lay writes:
>
> > Or what about simply that, which works for me:
> >
> >
> > Index: config/avr/avr.h
> > ===
> > --- config/avr/avr.h(revision 210276)
>
> Ah - you are worried about the case where STACK_SAVEAREA_MODE() is
> smaller than Pmode, yes ?
No, simply that the modified formula is plain wrong. The code does:
tmp = size_int (5 * BITS_PER_WORD / POINTER_SIZE - 1);
tmp = build_index_type (tmp);
tmp = build_array_type (ptr_type_node, t
Hi,
Targets like ARM and AARCH64 support double-word load store instructions,
and these instructions are generally faster than the corresponding two
load/stores. GCC currently uses peephole2 to merge paired load/store into
one single instruction which has a disadvantage. It can only handle simple
91 matches
Mail list logo
