On Wed, Dec 11, 2013 at 12:42 AM, Tobias Burnus wrote:
> The patch does the same for libgfortran as Uros did for libgcc/libatomic,
> cf. http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00878.html
>
> "This is also how glibc generates exceptions."
>
> Build and tested on x86-64-gnu-linux.
> OK ?
Ok,
Tobias Burnus wrote:
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
On 12/10/13 23:35, Bin.Cheng wrote:
I know little about GC, so when ggc_collect may be called (between two
passes)? If so, I have to call free_affine_expand_cache just after the
calling to tree_to_affine_combination_expand in SCEV because it's an
analyzer and as you pointed out, the analyzing re
So for this source, compiled for x86_64 with -O3:
typedef unsigned long int uint64_t;
typedef long int int64_t;
int summation_helper_1(int64_t* products, uint64_t count)
{
int s = 0;
uint64_t i;
for(i=0; i0) ? 1 : -1;
products[i] *= val;
if
On Wed, Dec 11, 2013 at 6:50 AM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 10:46:32AM +0800, bin.cheng wrote:
>> 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 t
On Wed, Dec 11, 2013 at 4:31 AM, H.J. Lu wrote:
> 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 th
On 12/10/13 16:22, Steven Bosscher wrote:
On Tue, Dec 10, 2013 at 7:30 AM, Jeff Law wrote:
Ping!
I'd prefer going with the first patch to merge_if_blocks (with a big
"???" or FIXME), to contain this problem to where it occurs.
Otherwise, before you know it, there are other places in the comp
On Tue, Dec 10, 2013 at 2:33 PM, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 2:25 PM, Tejas Belagod
> wrote:
>> On 10 December 2013 21:51, H.J. Lu wrote:
>>> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
On Tue, Dec 10, 2013 at 12:39 PM, Richard Henderson
wrote:
> On 12/10/2013
On Wed, Dec 11, 2013 at 6:50 AM, Jakub Jelinek wrote:
> On Tue, Dec 10, 2013 at 10:46:32AM +0800, bin.cheng wrote:
>> 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 t
Il 09/12/2013 12:08, Gerald Pfeifer ha scritto:
> On Mon, 9 Dec 2013, FX wrote:
>> > Look at this as a diagnostics bug: our current diagnostics for this
>> > pretty common situation sucks. It comes late in the compilation, and
>> > the message itself isn’t helpful.
> Totally seconded.
>
> Paolo,
Hello!
> 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.
Please add a ChangeLog entry and attach the complete patch
On Tue, Dec 10, 2013 at 3:19 PM, Uros Bizjak wrote:
> On Tue, Dec 10, 2013 at 11:23 PM, H.J. Lu wrote:
>> Hi,
>>
>> We have
>>
>> (define_insn "*movsf_internal"
>> [(set (match_operand:SF 0 "nonimmediate_operand"
>> "=Yf*f,m ,Yf*f,?r ,?m,v,v,v,m,?r,?Yi,!*y,!*y,!m,!r ,!*Ym")
>>
On Tue, Dec 10, 2013 at 7:30 AM, Jeff Law wrote:
>
>
> Ping!
I'd prefer going with the first patch to merge_if_blocks (with a big
"???" or FIXME), to contain this problem to where it occurs.
Otherwise, before you know it, there are other places in the compiler
that assume it's OK to merge blocks t
On Tue, Dec 10, 2013 at 11:23 PM, H.J. Lu wrote:
> Hi,
>
> We have
>
> (define_insn "*movsf_internal"
> [(set (match_operand:SF 0 "nonimmediate_operand"
> "=Yf*f,m ,Yf*f,?r ,?m,v,v,v,m,?r,?Yi,!*y,!*y,!m,!r ,!*Ym")
> (match_operand:SF 1 "general_operand"
> "Yf*fm,Yf*
> The patch does indeed fix unsigned-extend-1.c on arm and bootstraps
> succesfully on arm-none-linux-gnueabihf.
Thanks for the testing.
> Thanks for fixing this, that test failure has been spoiling my test runs for
> quite a while now :)
You're welcome. Now applied on mainline and 4.8 branch,
On Tue, Dec 10, 2013 at 10:46:32AM +0800, bin.cheng wrote:
> 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 breaks bootstrap on x86_
The patch does the same for libgfortran as Uros did for
libgcc/libatomic, cf.
http://gcc.gnu.org/ml/gcc-patches/2013-12/msg00878.html
"This is also how glibc generates exceptions."
Build and tested on x86-64-gnu-linux.
OK ?
Tobias
2013-12-10 Tobias Burnus
* config/fpu-387.h (sigill_hdlr,
Hi Jeff,
On Thu, 2013-12-05 21:14:23 -0700, Jeff Law wrote:
> On 12/05/13 21:10, Jan-Benedict Glaw wrote:
> > On Thu, 2013-12-05 20:49:06 -0700, Jeff Law wrote:
> > > I'd just change this one to be correct for the GNU style. If
> > > you wanted to follow-up with another patch to fix these
> > >
On Tue, Dec 10, 2013 at 2:25 PM, Tejas Belagod wrote:
> On 10 December 2013 21:51, H.J. Lu wrote:
>> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
>>> 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 understa
Pre-remark:
I had hoped that something like the following patch would work. However,
it will lead to a bunch of run-time segfaults in the test suite - but
the original dump seems to be fine and I also fail to spot the problem
when looking at the patch. Thus, instead of posting a working patch,
On 10 December 2013 21:51, H.J. Lu wrote:
> On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
>> 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 (re
Hi,
We have
(define_insn "*movsf_internal"
[(set (match_operand:SF 0 "nonimmediate_operand"
"=Yf*f,m ,Yf*f,?r ,?m,v,v,v,m,?r,?Yi,!*y,!*y,!m,!r ,!*Ym")
(match_operand:SF 1 "general_operand"
"Yf*fm,Yf*f,G ,rmF,rF,C,v,m,v,Yj,r ,*y ,m ,*y,*Yn,r"))]
alternative 13
On Tue, Dec 10, 2013 at 1:09 PM, H.J. Lu wrote:
> 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) represen
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
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
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 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
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
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/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
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/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
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 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
[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 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
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 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: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
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
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).
>>
>>
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,
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
"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: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 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 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
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, 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
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))
>> -
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/
"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
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
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 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: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 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 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
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 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
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 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 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 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 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
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 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
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 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
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
>>
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 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
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
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
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
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
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
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.
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.
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
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.
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
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
> 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 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
> 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 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!
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/
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
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
Revision 205848 breaks bootstrap on x86_64-apple-darwin13: pr59445.
TIA
Dominique
> :-) 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
> 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
Done, r205853.
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
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 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
1 - 100 of 123 matches
Mail list logo
