On 10/12/2013, at 1:07 am, Maxim Kuvyrkov wrote:
> My recent patches to cleanup support for Android/Bionic for *-linux-* targets
> broke mips64-linux and s390x-linux builds. Unfortunately, these targets fell
> out from the test coverage of these cleanups.
>
> The problems are in missing decla
> I'm strongly against the blacklist,
> that is not the way things are done in GCC,
> you have corresponding attribute to mark functions
> you don't want to instrument, people can macroize that with
> __typeof (symbol) symbol __attribute__((__no_sanitize_address__));
> But in any case, you mark it
On Tue, Dec 10, 2013 at 09:01:02PM +1300, Maxim Kuvyrkov wrote:
> Given that the one-line fix for s390x-linux is trivial (just add file with
> function prototypes to the list of headers), and that Richard approved
> mips*-linux part of the patch -- I'm going to commit the patch tomorrow
> unless I
On Tue, Dec 10, 2013 at 12:06:55PM +0400, Yury Gribov wrote:
> > I'm strongly against the blacklist,
> > that is not the way things are done in GCC,
> > you have corresponding attribute to mark functions
> > you don't want to instrument, people can macroize that with
> > __typeof (symbol) symbol __
As Richard requested, this patch removes INT_CST_LT in favour of
tree_int_cst_lt and renames INT_CST_LE in a similar way. I made
both of them inline since the idea is that wi::l[te]s_p should already
do the expensive stuff out-of-line. I also moved tree_int_cst_cmp in
the same way for consistency
On Tue, Dec 10, 2013 at 12:10 PM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 12:06:55PM +0400, Yury Gribov wrote:
>> > I'm strongly against the blacklist,
>> > that is not the way things are done in GCC,
>> > you have corresponding attribute to mark functions
>> > you don't want to instrument,
On 09/12/13 13:07, Maxim Kuvyrkov wrote:
> On 9/12/2013, at 8:21 am, Maxim Kuvyrkov wrote:
>
>> On 9/12/2013, at 3:24 am, Jan-Benedict Glaw wrote:
>>
>>> Hi Maxim!
>>>
>>> One of your recent libc<->android clean-up patches broke the
>>> mips64-linux target as a side-effect, see eg.
>>> http://to
Ping?
This is definitely a bug. The LIB1ASMFUNCS defined in t-bpabi should not be
overridden by t-arm.
OK for 4.8 and trunk
Thanks!
-Zhenqiang
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
> ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
> Sent: Monday,
Jakub wrote:
> You can still -include some header file from the command line and put the
> attributes in there or similar.
True although this probably won't work with C++ methods.
> The blacklist is really terribly ugly hack,
> which can't work reliably. What do you do for anonymous namespaces?
Hi,
On Mon, 9 Dec 2013 14:18:23, Richard Biener wrote:
>
> On Mon, Dec 9, 2013 at 1:39 PM, Bernd Edlinger
> wrote:
>> On Fri, 6 Dec 2013 11:51:15, Richard Biener wrote:
>>>
>>> On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
>>> wrote:
Hi,
On Thu, 5 Dec 2013 15:10:51, Richard Bie
On Mon, 9 Dec 2013, David Malcolm wrote:
> On Fri, 2013-12-06 at 21:27 +0100, Richard Biener wrote:
> > Oleg Endo wrote:
> > >On Fri, 2013-12-06 at 16:57 +0100, Steven Bosscher wrote:
> > >> On Fri, Dec 6, 2013 at 3:51 PM, David Malcolm wrote:
> > >> > * asan.c (transform_statements): Eli
> This all started with Stuart Hastings' original decloning patch way
> back in 2002:
> http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00354.html
> Bill Maddox tried to revive it in 2007:
> http://gcc.gnu.org/ml/gcc-patches/2007-11/msg01147.html
>
> I'm embarrassed that it has taken so long to g
Hello,
From http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59410#c1 issue:
> BTW, the tsan.exp tests don't seem to be as cheap as was claimed
during the patch
> submission, I'd prefer to at least throttle the > torture options
down to say -O0
> and -O2 rather than so many different variants when
On Tue, 10 Dec 2013, Richard Sandiford wrote:
> As Richard requested, this patch removes INT_CST_LT in favour of
> tree_int_cst_lt and renames INT_CST_LE in a similar way. I made
> both of them inline since the idea is that wi::l[te]s_p should already
> do the expensive stuff out-of-line. I also
>
> Agreed. I guess our main question is whether such mechanism is really needed
> by developers.
We use the blacklist:
- with asan init-order-checker to disable checking some specific
globals by their type name ("bening" true positive)
- with msan to suppress true benign reports from zlib's defla
On Tue, Dec 10, 2013 at 01:48:09PM +0400, Maxim Ostapenko wrote:
> 2013-12-10 Max Ostapenko
>
> * c-c++-common/tsan/thread_leak2.c: `dg-skip-if' removed.
> * gcc-dg/tsan/tsan.exp: Run only with '-O0' and '-O2' options.
> * g++-dg/tsan/tsan.exp: Run only with '-O0' and '-O2' op
> > * gimple-fold.c (can_refer_decl_in_current_unit_p): Check
> > references to comdat-local symbols.
Also i think this change needs more work. FROM_DECL is not the function you
are going to get the refernece, it is variable whose constructor the value was
take from.
I thi
On 6 December 2013 17:35, Tejas Belagod wrote:
> 2013-12-06 Tejas Belagod
>
> * config/aarch64/aarch64.h (TARGET_CRYPTO): New.
> (__ARM_FEATURE_CRYPTO): Define if TARGET_CRYPTO is true.
OK, but don;t apply until the rest of this patch series is approved.
/Marcus
On Tue, Dec 10, 2013 at 9:24 AM, Zhenqiang Chen wrote:
> Ping?
>
> This is definitely a bug. The LIB1ASMFUNCS defined in t-bpabi should not be
> overridden by t-arm.
>
> OK for 4.8 and trunk
This looks correct. Ok if no regressions for both 4.8 and trunk.
regards
Ramana
>
> Thanks!
> -Zhenqian
> What are the transformations that are enabled by making something not
> BLKmode?
>
> On the gimple level I cannot think of one..
On the RTL level, it's simple: anything BLKmode is forced to memory instead of
being loaded into registers.
> >This could work as well, although I'd restrict this t
On 6 December 2013 17:35, Tejas Belagod wrote:
> * config/arm/types.md (neon_mul_d_long, crypto_aes, crypto_sha1_xor,
> crypto_sha1_fast, crypto_sha1_slow, crypto_sha256_fast,
> crypto_sha256_slow): New.
Looks ok to me, but get an ack from Ramana.
Note that part of this
> > diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
> > index fbb63da..aa49bfe 100644
> > --- a/gcc/ipa-inline.c
> > +++ b/gcc/ipa-inline.c
> > @@ -230,6 +230,25 @@ report_inline_failed_reason (struct cgraph_edge *e)
> > }
> > }
> >
> > +/* True iff NODE calls another function which is loc
On 6 December 2013 17:36, Tejas Belagod wrote:
> * gcc.target/aarch64/aes.c: New.
Add _1 on the test case file name (see http://gcc.gnu.org/wiki/TestCaseWriting)
> diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
> index dc56170..9f35e09 100644
> --- a/gcc/con
On Tue, Dec 10, 2013 at 11:04:53AM +0100, Eric Botcazou wrote:
> > What are the transformations that are enabled by making something not
> > BLKmode?
> >
> > On the gimple level I cannot think of one..
>
> On the RTL level, it's simple: anything BLKmode is forced to memory instead
> of
> being
Same comments as previous patch:
On 6 December 2013 17:36, Tejas Belagod wrote:
> testsuite/
> * gcc.target/aarch64/sha1.c: New.
Add _1 on the test case file name (see http://gcc.gnu.org/wiki/TestCaseWriting)
> +static __inline uint32x4_t
> +vsha1cq_u32 (uint32x4_t hash_abcd, uint32_t
On 6 December 2013 17:36, Tejas Belagod wrote:
>
> Hi,
>
> The attached patch implements support for crypto sha256.
Same comments as previous crypto patch.
/Marcus
Done, r205853.
> What we support is out of bounds accesses for heap vars if the var's type
> has flexible array member or something we treat similarly and there is the
> possibility that there could be payload after the heap var that could be
> accessed from the flexible array members or similar arrays.
My ques
> :-) From a cleanup standpoint, I think the expansion code is ripe for
> someone to spend (condsiderable) time killing dead code. I suspect
> there's still significant gcc-1.91 (or even older) bits in there that
> have been dead for at least a decade.
The existing test was added for Ada a decad
Revision 205848 breaks bootstrap on x86_64-apple-darwin13: pr59445.
TIA
Dominique
On 3 December 2013 21:24, Andrew Pinski wrote:
>
> While compiling some programs, GCC and glibc (and newlib)'s definitions of
> size_t
> were not agreeing and causing format warnings to happen. The simple testcase
> for this is:
> #include
> #include
>
> int main(void)
> {
> ssize_t t = 0x1
Hi Kugan,
The latest patch looks good to me; I only have a couple of minor
comments inlined below. Please ask Marcus to review and approve it.
Thanks again for fixing this issue!
On 12/10/13 06:21, Kugan wrote:
[snip]
Updated it and tested with
1. binutils 2.23.2
a. bootstrapped with d
Hi!
Here is an updated version which doesn't warn about #include_next.
Ok for trunk?
2013-12-10 Jakub Jelinek
* sanitizer_common/Makefile.am (AM_CPPFLAGS): Add
-isystem $(top_srcdir)/include/system.
* sanitizer_common/Makefile.in: Regenerated.
* include/system/
On Fri, Dec 06, 2013 at 06:40:52AM -0800, Ian Lance Taylor wrote:
> There was a recent buggy patch to the demangler that added calls to
> malloc and realloc (2013-10-25 Gary Benson ).
> That patch must be fixed or reverted before the 4.9 release. The main
> code in the demangler must not call mall
> Hi,
>
>
> ChangeLog
>
> 2013-12-06 Kai Tietz
>
> PR target/56807
> * config/i386/i386.c (ix86_expand_prologue):
>
> Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu. Ok for apply?
So the code in question does spilling relative to stack pointer before function
call and relat
On Tue, Dec 10, 2013 at 12:48:20PM +0100, Jan Hubicka wrote:
> > Hi,
> >
> >
> > ChangeLog
> >
> > 2013-12-06 Kai Tietz
> >
> > PR target/56807
> > * config/i386/i386.c (ix86_expand_prologue):
> >
> > Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu. Ok for apply?
>
> So the
> On Tue, Dec 10, 2013 at 12:48:20PM +0100, Jan Hubicka wrote:
> > > Hi,
> > >
> > >
> > > ChangeLog
> > >
> > > 2013-12-06 Kai Tietz
> > >
> > > PR target/56807
> > > * config/i386/i386.c (ix86_expand_prologue):
> > >
> > > Tested for i686-w64-mingw32, x86_64-unknown-linux-gnu. Ok
On 09/12/13 23:18, Eric Botcazou wrote:
It's the pessimization introduced on the ARM (and other RISC targets) by the
distribution of truncations in simplify_truncation. Further information at:
http://gcc.gnu.org/ml/gcc/2013-12/msg00019.html
The change started as a simple address reassociatio
This is the 2nd piece. We can cache solution_set_expand when processing
complex constraints. This also fixes spurious bits leaking into
constraints that don't need the expansion as the delta was expanded
in-place previously (seen by the ipa-pta-14.c XFAIL).
Bootstrapped and tested on x86_64-unk
Hi!
At the end of this email you can find the patch that I'd like to apply to
gomp-4_0-branch for OpenACC structured blocks, after the following two
have been approved:
On Fri, 06 Dec 2013 19:33:35 +0100, I wrote:
> On Fri, 15 Nov 2013 14:44:45 -0700, Aldy Hernandez wrote:
> > --- a/gcc/omp-low.
Hi,
as far as I can see, this bug asks for the implementation of Core/1442,
thus don't do a special Koenig lookup including namespace std in
cp_parser_perform_range_for_lookup. Tested x86_64-linux.
Thanks,
Paolo.
/
/cp
2013-12-10 Paolo Carlini
Core DR 1442
Yes, I sent update to HJ's comment.
2013/12/6 Kai Tietz :
> Upps ... here is the missing Changlog
>
> ChangeLog
>
> 2013-12-06 Kai Tietz
>
> PR target/56807
> * config/i386/i386.c (ix86_expand_prologue): Address saved
> registers stack-relative, not via frame-pointer.
On Tue, Dec 10, 2013 at 2:44 AM, Yury Gribov wrote:
> Done, r205853.
I think it caused:
http://gcc.gnu.org/ml/gcc-regression/2013-12/msg00214.html
--
H.J.
On Tue, Dec 10, 2013 at 05:10:44AM -0800, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 2:44 AM, Yury Gribov wrote:
> > Done, r205853.
>
> I think it caused:
>
> http://gcc.gnu.org/ml/gcc-regression/2013-12/msg00214.html
Missing torture-finish before dg-finish? At least looking at other
*.exp files
HJ wrote:
>> Done, r205853.
> I think it caused:
> http://gcc.gnu.org/ml/gcc-regression/2013-12/msg00214.html
Right, I think we are missing torture-finish. Will send a fix after test.
-Y
Hi,
On 10 December 2013 01:52, Andrew Pinski wrote:
> On Mon, Dec 9, 2013 at 12:12 PM, Yufeng Zhang wrote:
>> To be more explicit and consistent, the name of the ILP32 loader shall have
>> 'ilp32' instead of '32'. The extension field shall be appended to
>> 'aarch64', separated by '_', and we
The movapd tests in the i386 testsuite fail if built with
-fstack-protector-strong or -fstack-protector-all, due to 8byte
alignment instead of 16, or 32byte alignment.
2013-12-10 Ryan Mansfield
PR testsuite/59442
* gcc.target/i386/sse2-movapd-1.c: Fix alignment attri
On Mon, Dec 9, 2013 at 8:49 PM, Oleg Endo wrote:
> On Thu, 2013-12-05 at 15:34 +0100, Oleg Endo wrote:
>> On Thu, 2013-12-05 at 14:56 +0100, Richard Biener wrote:
>> >
>> > grep for 'typedef struct.*{' in headers. The typedef name is usually
>> > the desired one and is used without 'struct'. So
On Mon, 9 Dec 2013, Marek Polacek wrote:
> Back in April 2011, Richard S. submitted the implementation of
> internal functions [1]. It originally had this hunk of code:
>
> if (code == SSA_NAME
> && (g = SSA_NAME_DEF_STMT (ssa_name))
> - && gimple_code (g) == GIMPLE
Hello,
On 09 Dec 14:08, H.J. Lu wrote:
> There are no regressions on Linux/x86-64 with -m32 and -m64.
> Can you check if it improves code quality on x886?
That is exactly what I was talking about. However I wasn't sure
that we can change already defined (and used throughout ports)
target hook.
An
On Tue, Dec 10, 2013 at 10:31 AM, Bernd Edlinger
wrote:
> Hi,
>
>
> On Mon, 9 Dec 2013 14:18:23, Richard Biener wrote:
>>
>> On Mon, Dec 9, 2013 at 1:39 PM, Bernd Edlinger
>> wrote:
>>> On Fri, 6 Dec 2013 11:51:15, Richard Biener wrote:
On Fri, Dec 6, 2013 at 11:15 AM, Bernd Edlinger
>>
On Tue, Dec 10, 2013 at 11:53 AM, Eric Botcazou wrote:
>> What we support is out of bounds accesses for heap vars if the var's type
>> has flexible array member or something we treat similarly and there is the
>> possibility that there could be payload after the heap var that could be
>> accessed
Jakub wrote:
> HJ wrote:
>>> Done, r205853.
>> I think it caused:
>>
>> http://gcc.gnu.org/ml/gcc-regression/2013-12/msg00214.html
>
> Missing torture-finish before dg-finish? At least looking at other
> *.exp files that do set-torture-options they all do that.
Full make-check is still running bu
On Tue, Dec 10, 2013 at 4:02 PM, Richard Biener
wrote:
> On Tue, Dec 10, 2013 at 11:53 AM, Eric Botcazou wrote:
>>> What we support is out of bounds accesses for heap vars if the var's type
>>> has flexible array member or something we treat similarly and there is the
>>> possibility that there c
Done in r205858.
---
From: Jakub Jelinek
Sent: Tuesday, December 10, 2013 7:37PM
To: Yury Gribov
Cc: H.J. Lu , Maxim Ostapenko
, GCC Patches
, Slava Garbuzov
Subject: Re: Fix tsan tests.
On 12/10/2013 07:37 PM, Jakub Jelinek wrote:
On Tue, Dec
On Tue, Dec 10, 2013 at 07:06:21PM +0400, Yury Gribov wrote:
> --- a/gcc/testsuite/g++.dg/tsan/tsan.exp
> +++ b/gcc/testsuite/g++.dg/tsan/tsan.exp
> @@ -42,5 +42,6 @@ gcc-dg-runtest [lsort [glob -nocomplain $srcdir/$subdir/*.c
> $srcdir/c-c++-common
> }
>
> # All done.
> +torture-finish
> tsa
On 09 Dec 14:08, H.J. Lu wrote:
>
> There are no regressions on Linux/x86-64 with -m32 and -m64.
> Can you check if it improves code quality on x886?
As second thought. If Tejas and Richard are right and it is simply incorrect
to check any offsets in this hook, may be we can end up with patch in
On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin wrote:
> On 09 Dec 14:08, H.J. Lu wrote:
>>
>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>> Can you check if it improves code quality on x886?
>
> As second thought. If Tejas and Richard are right and it is simply incorrect
> to che
On Dec 10, 2013, at 9:50 AM, Kirill Yukhin wrote:
> Hello,
> On 09 Dec 14:08, H.J. Lu wrote:
>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>> Can you check if it improves code quality on x886?
>
> That is exactly what I was talking about. However I wasn't sure
> that we can ch
On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin wrote:
> On 09 Dec 14:08, H.J. Lu wrote:
>>
>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>> Can you check if it improves code quality on x886?
>
> As second thought. If Tejas and Richard are right and it is simply incorrect
> to che
On 10 Dec 08:23, H.J. Lu wrote:
> What is wrong to pass the correct offset to
> CANNOT_CHANGE_MODE_CLASS? Backends are free to
> ignore it.
Yes, but as fas as understand this hook as a predicate
saying if it not-safe to change mode1 to mode2 for given
register class. I don't think that offsets sh
On 10 Dec 09:02, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
> wrote:
> > On 09 Dec 14:08, H.J. Lu wrote:
> > NOINLINE float
> > foo32x2_le (float32x2_t x)
> > {
> > +#ifdef __i386__
> > + __builtin_ia32_emms ();
> > +#endif
> >return bar (x[0]);
> > }
> You should ch
On Tue, Dec 10, 2013 at 9:09 AM, Kirill Yukhin wrote:
> On 10 Dec 09:02, H.J. Lu wrote:
>> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
>> wrote:
>> > On 09 Dec 14:08, H.J. Lu wrote:
>> > NOINLINE float
>> > foo32x2_le (float32x2_t x)
>> > {
>> > +#ifdef __i386__
>> > + __builtin_ia32_emms
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin wrote:
> On 10 Dec 08:23, H.J. Lu wrote:
>> What is wrong to pass the correct offset to
>> CANNOT_CHANGE_MODE_CLASS? Backends are free to
>> ignore it.
>
> Yes, but as fas as understand this hook as a predicate
> saying if it not-safe to change mode1
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin wrote:
On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
Yes, but as fas as understand this hook as a predicate
saying if it not-safe to change mo
On Mon, Dec 9, 2013 at 11:49 AM, Oleg Endo wrote:
> On Thu, 2013-12-05 at 15:34 +0100, Oleg Endo wrote:
>> On Thu, 2013-12-05 at 14:56 +0100, Richard Biener wrote:
>> >
>> > grep for 'typedef struct.*{' in headers. The typedef name is usually
>> > the desired one and is used without 'struct'. So
On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod wrote:
> H.J. Lu wrote:
>>
>> On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin
>> wrote:
>>>
>>> On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
On Tue, Dec 10, 2013 at 9:33 AM, H.J. Lu wrote:
> On Mon, Dec 9, 2013 at 11:49 AM, Oleg Endo wrote:
>> On Thu, 2013-12-05 at 15:34 +0100, Oleg Endo wrote:
>>> On Thu, 2013-12-05 at 14:56 +0100, Richard Biener wrote:
>>> >
>>> > grep for 'typedef struct.*{' in headers. The typedef name is usually
On Mon, Dec 09, 2013 at 08:49:59PM +0100, Oleg Endo wrote:
> Tested with make all-gcc.
You should be testing such changes by full bootstrap/regtest.
> gcc/ChangeLog:
> * gcc/cgraph.h (cgraph_node_set_iterator,
> varpool_node_set_iterator): Remove typedef.
> (cgraph_inline_faile
On Tue, Dec 10, 2013 at 9:44 AM, Jakub Jelinek wrote:
> On Mon, Dec 09, 2013 at 08:49:59PM +0100, Oleg Endo wrote:
>> Tested with make all-gcc.
>
> You should be testing such changes by full bootstrap/regtest.
I checked in r205866 to restore bootstrap.
>> gcc/ChangeLog:
>> * gcc/cgraph.h (
On Tue, 2013-12-10 at 09:49 -0800, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 9:44 AM, Jakub Jelinek wrote:
> > On Mon, Dec 09, 2013 at 08:49:59PM +0100, Oleg Endo wrote:
> >> Tested with make all-gcc.
> >
> > You should be testing such changes by full bootstrap/regtest.
>
> I checked in r205866 to
"H.J. Lu" writes:
> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
> wrote:
>> On 09 Dec 14:08, H.J. Lu wrote:
>>>
>>> There are no regressions on Linux/x86-64 with -m32 and -m64.
>>> Can you check if it improves code quality on x886?
>>
>> As second thought. If Tejas and Richard are right and i
But aren't both OpenMP and Cilk Plus simd clones marked as "omp
declare simd"? In which case you shouldn't have to do anything?
Are the Cilk Plus clones not being marked as "omp declare simd" in
the front-ends?
Didn't you mention in this thread
(http://gcc.gnu.org/ml/gcc-patches/2013-11/
Richard Biener writes:
> On Mon, 9 Dec 2013, Marek Polacek wrote:
>
>> Back in April 2011, Richard S. submitted the implementation of
>> internal functions [1]. It originally had this hunk of code:
>>
>>if (code == SSA_NAME
>>&& (g = SSA_NAME_DEF_STMT (ssa_name))
>> -
On Tue, 10 Dec 2013, Chung-Lin Tang wrote:
> Hi Joseph,
>
> Forgot to follow up on this patch. Here it is with a small update to
> check if 'p' got updated to a difference position. Does this now look okay?
OK.
--
Joseph S. Myers
jos...@codesourcery.com
Hello!
> 2013-12-10 Ryan Mansfield
>
> PR testsuite/59442
> * gcc.target/i386/sse2-movapd-1.c: Fix alignment attributes.
> * gcc.target/i386/sse2-movapd-2.c: Likewise.
> * gcc.target/i386/avx-vmovapd-256-1.c: Likewise.
> * gcc.target/i386/avx-vmovapd-256-2.c: Likewise.
OK for mainline and rele
On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
>> wrote:
>>> On 09 Dec 14:08, H.J. Lu wrote:
There are no regressions on Linux/x86-64 with -m32 and -m64.
Can you check if it improves code quality on
"H.J. Lu" writes:
> On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
> wrote:
>> "H.J. Lu" writes:
>>> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
>>> wrote:
On 09 Dec 14:08, H.J. Lu wrote:
>
> There are no regressions on Linux/x86-64 with -m32 and -m64.
> Can you check if
On Tue, Dec 10, 2013 at 10:26 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
>> wrote:
>>> "H.J. Lu" writes:
On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
wrote:
> On 09 Dec 14:08, H.J. Lu wrote:
>>
>> There are no
"H.J. Lu" writes:
> On Tue, Dec 10, 2013 at 10:26 AM, Richard Sandiford
> wrote:
>> "H.J. Lu" writes:
>>> On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
>>> wrote:
"H.J. Lu" writes:
> On Tue, Dec 10, 2013 at 8:05 AM, Kirill Yukhin
> wrote:
>> On 09 Dec 14:08, H.J. Lu wrot
On Tue, Dec 10, 2013 at 10:44 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Tue, Dec 10, 2013 at 10:26 AM, Richard Sandiford
>> wrote:
>>> "H.J. Lu" writes:
On Tue, Dec 10, 2013 at 9:57 AM, Richard Sandiford
wrote:
> "H.J. Lu" writes:
>> On Tue, Dec 10, 2013 at 8:05
Fixes missing DIR_SEPARATOR if --with-gxx-include-dir configured as
subdir of sysroot.
2013-12-10 Ryan Mansfield
PR preprocessor/56896
* incpath.c (add_standard_paths): Strip trailing sysroot
DIR_SEPARATOR
only if appended path begins with DIR_SEPARATOR.
Regards,
I agree with the staged checkin plan proposed. Teresa, can you help
with spliting out the libgcov.h/gcov-io.h change out (Rong is on a
trip..)
thanks,
David
On Fri, Dec 6, 2013 at 6:23 AM, Jan Hubicka wrote:
>> Hi, all
>>
>> This is the new patch for gcov-tool (previously profile-tool).
>>
>>
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod wrote:
H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin
wrote:
On 10 Dec 08:23, H.J. Lu wrote:
What is wrong to pass the correct offset to
CANNOT_CHANGE_MODE_CLASS? Backends are free to
ignore it.
Yes, but as fas a
On Tue, Dec 10, 2013 at 11:05 AM, Tejas Belagod wrote:
> H.J. Lu wrote:
>>
>> On Tue, Dec 10, 2013 at 9:26 AM, Tejas Belagod wrote:
>>>
>>> H.J. Lu wrote:
On Tue, Dec 10, 2013 at 9:04 AM, Kirill Yukhin
wrote:
>
> On 10 Dec 08:23, H.J. Lu wrote:
>>
>> What is wrong
On Dec 10, 2013, at 2:12 PM, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 11:05 AM, Tejas Belagod wrote:
>> ...
>> So, if (subreg:DI (match_operand:V4SF 1 "register_operand" "x,x") 0) is a
>> valid subreg, why not allow it in CANNOT_CHANGE_MODE_CLASS (like in Kirill's
>> patch http://gcc.gnu.org/ml
On Tue, Dec 10, 2013 at 11:01 AM, Xinliang David Li wrote:
> I agree with the staged checkin plan proposed. Teresa, can you help
> with spliting out the libgcov.h/gcov-io.h change out (Rong is on a
> trip..)
Sure, I will work on that part and send a patch once it is tested.
Teresa
>
> thanks,
On 12/10/13 00:01, bin.cheng wrote:
Emm, some kind of. See the cost of iv candidate set consists of several
parts, the representation cost in cost pair; the register pressure cost
falls in dependence on invariant expressions, etc.. Here iv_ca_has_deps
checks whether new cost pair depends on oth
[snip]
>> diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c
>> index b1b4eef..a53febc 100644
>> --- a/gcc/config/aarch64/aarch64.c
>> +++ b/gcc/config/aarch64/aarch64.c
>> @@ -5187,6 +5187,13 @@ aarch64_override_options (void)
>> aarch64_parse_tune ();
>> }
>>
On Dec 10, 2013, at 7:06 AM, Yury Gribov wrote:
> Jakub wrote:
> > HJ wrote:
> >>> Done, r205853.
> >> I think it caused:
> >>
> >> http://gcc.gnu.org/ml/gcc-regression/2013-12/msg00214.html
> >
> > Missing torture-finish before dg-finish? At least looking at other
> > *.exp files that do set-tort
On Mon, Dec 9, 2013 at 6:46 PM, bin.cheng wrote:
>
>>
> Hi,
> This is the new version patch computing the difference in tree affine then
> comparing against integer_zero_node.
> Bootstrap and test on current upstream. I will commit it if there is no
> other objection.
>
This caused:
http://gcc.
On 12/10/2013 10:44 AM, Richard Sandiford wrote:
> Sorry, I don't understand. I never said it was invalid. I said
> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
> a single register. On a little-endian target, the offset cannot be
> anything other than 0 in that case.
>
> So
Among the slower tests in the Go gcc testsuite are the rotate* tests.
This patch changes the GCC testsuite driver to test them in parallel
when using make -j. Tested by running the testsuite on
x86_64-unknown-linux-gnu and verifying that there were no differences.
Committed to mainline.
Ian
201
On 12/09/2013 02:46 AM, Gerald Pfeifer wrote:
> Hmm, it looks like this has not been approved/applied, but I also
> have not seen any NACK.
>
> This does address an annoying (and hard for novices to understand)
> roadblock for someone installing GCC manually. Can this go in?
The patch looks ok t
On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson wrote:
> On 12/10/2013 10:44 AM, Richard Sandiford wrote:
>> Sorry, I don't understand. I never said it was invalid. I said
>> (subreg:SF (reg:V4SF X) 1) was invalid if (reg:V4SF X) represents
>> a single register. On a little-endian target, t
On 12/10/2013 04:48 AM, Jan Hubicka wrote:
The case where I played with local comdats was the following.
I made cgraph_body_availability to get context argument (i.e. instead of saying
if something is available in current unit, it was saying if it is available
in current function/variable).
If t
Hi all,
here is a straightforward patch for a rather old PR, which deals with
argument checking. The patch at hand fixes one of the outstanding todo
items of the PR (see comment 17), namely extending the attribute
checking of dummy arguments. It adds checks for the four missing
attributes (asynchr
PR gcc/59422
This patch extends the supported targets for function multi versiong to also
include Haswell, Silvermont, and the most recent AMD models. It also
prioritizes AVX2 versions over AMD specific pre-AVX2 versions.
Hi Janus,
Janus Weil wrote:
here is a straightforward patch for a rather old PR, which deals with
argument checking. The patch at hand fixes one of the outstanding todo
items of the PR (see comment 17), namely extending the attribute
checking of dummy arguments. It adds checks for the four missi
2013/12/10 Tobias Burnus :
> Hi Janus,
>
>
> Janus Weil wrote:
>>
>> here is a straightforward patch for a rather old PR, which deals with
>> argument checking. The patch at hand fixes one of the outstanding todo
>> items of the PR (see comment 17), namely extending the attribute
>> checking of dum
1 - 100 of 123 matches
Mail list logo
