On Thu, Apr 16, 2015 at 11:11 PM, Jakub Jelinek wrote:
> Hi!
>
> As mentioned in the PR, on the following testcase we ICE, because for
> # DEBUG D#2 => b
> # DEBUG D#1 => a[D#2].t
> # DEBUG c => D#1
> during expansion we get the a[D#2].t added as MEM_EXPR of a MEM, and because
> we can't mem
On Fri, Apr 17, 2015 at 6:38 AM, wrote:
> From: Trevor Saunders
>
> Hi,
>
> Last stage 1 I introduced a second form of hash_table that stored elements of
> value_type in addition to the old form that stored elements of type value_type
> *. That lead to a fair bit of code dupplication in hash_ta
Hi all,
This patch adds an optional support for sanitizing user-defined
sections. Usually this is a bad idea because ASan changes relative
position of variables in section thus breaking user assumptions. But
this is a desired feature for kernel which (ab)uses sections for various
reasons (c
On 04/17/2015 10:33 AM, Yury Gribov wrote:
Hi all,
This patch adds an optional support for sanitizing user-defined
sections. Usually this is a bad idea because ASan changes relative
position of variables in section thus breaking user assumptions. But
this is a desired feature for kernel which
On Fri, Apr 17, 2015 at 10:37:50AM +0300, Yury Gribov wrote:
> commit 97c141d9be45b29fb7e281dc2b7cd904e93c2813
> Author: Yury Gribov
> Date: Mon Feb 2 14:33:17 2015 +0300
>
> 2015-04-17 Yury Gribov
>
> gcc/
> * asan.c (set_sanitized_sections): New function.
> (sectio
On Thu, Apr 16, 2015 at 06:47:26PM +0200, Georg-Johann Lay wrote:
> Am 04/16/2015 um 11:28 AM schrieb Senthil Kumar Selvaraj:
> >On Thu, Apr 16, 2015 at 11:02:05AM +0200, Georg-Johann Lay wrote:
> >>Am 04/16/2015 um 08:43 AM schrieb Senthil Kumar Selvaraj:
> >>>This patch fixes PR 65657.
> >>
> >>T
On Thu, Apr 16, 2015 at 6:28 PM, Mike Stump wrote:
> On Apr 14, 2015, at 8:07 AM, H.J. Lu wrote:
>>> I can confirm that the most current patch bootstraps on
>>> x86_64-apple-darwin14 and that all of the new tests show up as
>>> unsupported in the test suite.
>>> Jack
>>
>> I am re-postin
On Thu, Mar 19, 2015 at 10:24 AM, Ilya Tocar wrote:
> Hi,
>
> There were some discussion about "x" constraints being too conservative
> for some patterns in i386.md.
> Patch below fixes it. This is probably stage1 material.
>
> ChangeLog:
>
> gcc/
>
> 2015-03-19 Ilya Tocar
>
> * config/
On 15 Apr 14:07, Ilya Enkovich wrote:
> 2015-04-14 8:22 GMT+03:00 Jeff Law :
> > On 03/15/2015 02:30 PM, Richard Sandiford wrote:
> >>
> >> Ilya Enkovich writes:
> >>>
> >>> This patch allows propagation of loop invariants for i386 if propagated
> >>> value is a constant to be used in address oper
Hi!
I'd like to ping
PR target/65689 - P2 - http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00358.html
patch (perhaps with the code[?] == ' ' -> ISSPACE (code[?]) changes or
strstr, as discussed in the following thread).
At this point of course for trunk only, and perhaps after a while for 5.2.
For PR65549 the issue is that the force_decl_die DW_TAG_GNU_call_site
resolve_addr does can end up creating DIEs for types we won't emit
(it re-populates the limbo DIE list for the testcase). For the
particular testcase this happens because the context of the function
called (a lambda type) wasn'
Thanks for your quick feedback :)
2015-04-16 10:41 GMT+02:00 Marek Polacek :
> - Do you have a copyright assignment on file? (Not sure if it's needed for
> this particular patch.)
No I don't. Do you think I need one for this patch?
> - We'll need testcases. You should e.g. ensure that the wa
On Tue, 14 Apr 2015 15:15:02 +0100
Julian Brown wrote:
> On Wed, 8 Apr 2015 17:58:56 +0300
> Ilya Verbin wrote:
>
> > On Wed, Apr 08, 2015 at 15:31:42 +0100, Julian Brown wrote:
> > > This version is mostly the same as the last posted version but
> > > has a tweak in GOACC_parallel to account f
On 20-03-15 12:38, Tom de Vries wrote:
On 19-03-15 12:05, Tom de Vries wrote:
On 18-03-15 18:22, Tom de Vries wrote:
Hi,
this patch fixes PR65460.
The patch marks offloaded functions as parallelized, which means the parloops
pass no longer attempts to modify that function.
Updated patch to
On Fri, 17 Apr 2015, Richard Biener wrote:
>
> For PR65549 the issue is that the force_decl_die DW_TAG_GNU_call_site
> resolve_addr does can end up creating DIEs for types we won't emit
> (it re-populates the limbo DIE list for the testcase). For the
> particular testcase this happens because th
On Fri, Apr 17, 2015 at 1:05 AM, Uros Bizjak wrote:
> On Thu, Apr 16, 2015 at 6:28 PM, Mike Stump wrote:
>> On Apr 14, 2015, at 8:07 AM, H.J. Lu wrote:
I can confirm that the most current patch bootstraps on
x86_64-apple-darwin14 and that all of the new tests show up as
unsupporte
On Fri, Apr 17, 2015 at 12:32:03PM +0200, Richard Biener wrote:
> So Jakub says that using comp_unit_die () for the context of the stub
> DIE is wrong and he is of course right. The following adjusted patch
> uses the correct context, but only if we already have a DIE for it,
> otherwise we drop t
On Fri, Apr 17, 2015 at 12:36 PM, H.J. Lu wrote:
> I can confirm that the most current patch bootstraps on
> x86_64-apple-darwin14 and that all of the new tests show up as
> unsupported in the test suite.
> Jack
I am re-posting this patch. OK for trunk?
>>>
>>>
On Fri, Apr 17, 2015 at 1:04 PM, Uros Bizjak wrote:
> On Fri, Apr 17, 2015 at 12:36 PM, H.J. Lu wrote:
>
>> I can confirm that the most current patch bootstraps on
>> x86_64-apple-darwin14 and that all of the new tests show up as
>> unsupported in the test suite.
>> Jack
>> My point is that adding your patch while keeping the logic at the top
>> which claims to catch ALL vector operations makes for less readable
>> code.
>>
>> At the very least you'll need to update this comment:
>>
>> /* TODO: The cost infrastructure currently does not handle
>> vector oper
On 17/04/15 12:19, Kugan wrote:
Hi James,
Here is an attempt along this line. Is this what you have in mind?
Trying to keep functionality as before so that we can tune the
parameters later. Not fully tested yet.
Hi Kugan,
I'm not doing a full review here, just have a comment inline.
Thanks,
Hi,
This patch is to resolve missing IPA_REF_CHKP issues. When node has
instrumented version it usually has no body (either originally or was
tranfromed into instrumentation thunk). But in some cases we don't instrument
function and instrumentation clone becomes a thunk instead. In this case
2015-04-17 10:46 GMT+03:00 Senthil Kumar Selvaraj
:
>
> On Thu, Apr 16, 2015 at 06:47:26PM +0200, Georg-Johann Lay wrote:
> > Am 04/16/2015 um 11:28 AM schrieb Senthil Kumar Selvaraj:
> > >On Thu, Apr 16, 2015 at 11:02:05AM +0200, Georg-Johann Lay wrote:
> > >>Am 04/16/2015 um 08:43 AM schrieb Sent
On Fri, Apr 17, 2015 at 01:04:20PM +0200, Uros Bizjak wrote:
> On Fri, Apr 17, 2015 at 12:36 PM, H.J. Lu wrote:
>
> > I can confirm that the most current patch bootstraps on
> > x86_64-apple-darwin14 and that all of the new tests show up as
> > unsupported in the test suite.
> >
Hi,
This patch is to resolve missing IPA_REF_CHKP issues. When node has
instrumented version it usually has no body (either originally or was
tranfromed into instrumentation thunk). But in some cases we don't
instrument function and instrumentation clone becomes a thunk instead.
In this case we
On Fri, Apr 17, 2015 at 4:37 AM, Jakub Jelinek wrote:
> On Fri, Apr 17, 2015 at 01:04:20PM +0200, Uros Bizjak wrote:
>> On Fri, Apr 17, 2015 at 12:36 PM, H.J. Lu wrote:
>>
>> > I can confirm that the most current patch bootstraps on
>> > x86_64-apple-darwin14 and that all of the new tests
On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
> > creating yet another library for that.
> > So, IMHO beyond making the __cpu* entrypoints compat symbols only (@ instead
> > of @@ symbol versions) the right fix is s
On Thu, Apr 16, 2015 at 3:54 PM, Jason Merrill wrote:
> OK.
Thanks, committed as revision 222176.
>
> Jason
On Apr 17, 2015, at 1:05 AM, Uros Bizjak wrote:
> On Thu, Apr 16, 2015 at 6:28 PM, Mike Stump wrote:
>> On Apr 14, 2015, at 8:07 AM, H.J. Lu wrote:
I can confirm that the most current patch bootstraps on
x86_64-apple-darwin14 and that all of the new tests show up as
unsupported in
Note that Jakub requested a small change in the bugzilla commentary,
which I've implemented. I'm doing a regstrap now.
Bill
On Thu, 2015-04-16 at 16:46 -0500, Bill Schmidt wrote:
> Hi,
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65787 identifies an issue
> where the powerpc64le vector swap
On Fri, Apr 17, 2015 at 4:59 AM, Jakub Jelinek wrote:
> On Fri, Apr 17, 2015 at 04:48:48AM -0700, H.J. Lu wrote:
>> > I don't like it. Nonshared libgcc is libgcc.a, period. No sense in
>> > creating yet another library for that.
>> > So, IMHO beyond making the __cpu* entrypoints compat symbols o
Hi!
As discussed in the PR, during LTO bootstrap we have some hard to debug
issues where different gc checking values between stage1 and stage2 result
in different GC collections and occassionally we generate different code for
that. The stated workaround is --enable-stage1-checking=release,
I've
On Fri, Apr 17, 2015 at 05:36:30AM -0700, H.J. Lu wrote:
> This patch works for me. OK for trunk?
>
> gcc/testsuite/
>
> PR target/65612
> * g++.dg/ext/mv18.C: New test.
> * g++.dg/ext/mv19.C: Likewise.
> * g++.dg/ext/mv20.C: Likewise.
> * g++.dg/ext/mv21.C: Likewise.
> * g++.dg/ext/mv22.C: Like
Committed r222177 after testing on aarch64-none-linux-gnu and aarch64-none-elf.
gcc/ChangeLog:
config/aarch64/arm_neon.h (vdup_n_f32): Remove forward declaration
diff --git a/gcc/config/aarch64/arm_neon.h b/gcc/config/aarch64/arm_neon.h
index 71ef027..e9cc825 100644
--- a/gcc/config/aar
On Tue, Apr 14, 2015 at 05:43:26PM +0200, Thomas Schwinge wrote:
> On Tue, 14 Apr 2015 15:15:02 +0100, Julian Brown
> wrote:
> > On Wed, 8 Apr 2015 17:58:56 +0300
> > Ilya Verbin wrote:
> > > I see several regressions:
> > > FAIL: libgomp.oacc-c/../libgomp.oacc-c-c++-common/acc_on_device-1.c
> >
On Fri, 2015-04-17 at 07:27 -0500, Bill Schmidt wrote:
> Note that Jakub requested a small change in the bugzilla commentary,
> which I've implemented. I'm doing a regstrap now.
>
> Bill
>
Here's the revised and tested patch. OK for trunk and gcc-5-branch?
Thanks,
Bill
[gcc]
2015-04-16 Bi
...I went ahead and installed as
http://gcc.gnu.org/r222179
It will be backported to 5.2 as soon as 5.1 is open for patches again (assuming
RM won't approve this one for 5.1).
As far as I can tell, all works fine now, even with install-paths containing
spaces and LTO.
Johann
2015-04-17
OK.
Jason
OK.
Jason
> "Dave" == David Malcolm writes:
Dave> However within libcpp and gcc, in linemap's expanded_location and in
Dave> diagnostic messages, the "column" numbers are actually 1-based counts of
Dave> *characters*, so the "column" numbers emitted in diagnostics for the
Dave> start of the first token
On Fri, Apr 17, 2015 at 9:28 AM, Bill Schmidt
wrote:
> On Fri, 2015-04-17 at 07:27 -0500, Bill Schmidt wrote:
>> Note that Jakub requested a small change in the bugzilla commentary,
>> which I've implemented. I'm doing a regstrap now.
>>
>> Bill
>>
>
> Here's the revised and tested patch. OK for
2015-04-17 17:02 GMT+03:00 Georg-Johann Lay :
> ...I went ahead and installed as
>
> http://gcc.gnu.org/r222179
>
> It will be backported to 5.2 as soon as 5.1 is open for patches again
> (assuming RM won't approve this one for 5.1).
IMHO AVR port is not locked for patches.
It's not a primary targ
On Fri, Apr 17, 2015 at 08:28:02AM -0500, Bill Schmidt wrote:
> On Fri, 2015-04-17 at 07:27 -0500, Bill Schmidt wrote:
> > Note that Jakub requested a small change in the bugzilla commentary,
> > which I've implemented. I'm doing a regstrap now.
> >
> > Bill
> >
>
> Here's the revised and teste
On Fri, 2015-04-17 at 16:49 +0200, Jakub Jelinek wrote:
> On Fri, Apr 17, 2015 at 08:28:02AM -0500, Bill Schmidt wrote:
> > On Fri, 2015-04-17 at 07:27 -0500, Bill Schmidt wrote:
> > > Note that Jakub requested a small change in the bugzilla commentary,
> > > which I've implemented. I'm doing a re
Hi,
ping:
[gcc patch] libcc1: '@' GDB array operator
https://gcc.gnu.org/ml/gcc-patches/2015-03/msg01451.html
Message-ID: <20150327163646.ga16...@host1.jankratochvil.net>
Jan
Am 04/17/2015 um 04:43 PM schrieb Denis Chertykov:
2015-04-17 17:02 GMT+03:00 Georg-Johann Lay :
...I went ahead and installed as
http://gcc.gnu.org/r222179
It will be backported to 5.2 as soon as 5.1 is open for patches again
(assuming RM won't approve this one for 5.1).
IMHO AVR port is no
On 04/17/2015 01:59 AM, Jakub Jelinek wrote:
Hi!
I'd like to ping
PR target/65689 - P2 - http://gcc.gnu.org/ml/gcc-patches/2015-04/msg00358.html
patch (perhaps with the code[?] == ' ' -> ISSPACE (code[?]) changes or
strstr, as discussed in the following thread).
At this point of course for tru
Hi,
Comparing 64x1 vector types (defined by hand or from arm_neon.h) using GCC
vector extensions currently generates very poor assembly code, for example
"uint64x1_t foo (uint64x1_t a, uint64x1_t b) { return a >= b; }" generates (at -O3):
fmov x0, d0 // 22 movdi_aarch64/12 [length = 4]
fmov x
As per introduction, this allows vector_compare_rtx to work on DImode vectors.
Bootstrapped + check-gcc on x86-unknown-linux-gnu.
gcc/ChangeLog:
* optabs.c (vector_compare_rtx): Handle RTL operands having VOIDmode.
diff --git a/gcc/optabs.c b/gcc/optabs.c
index f8d584eeeb11a2c19d8c8d88
This just adds the necessary patterns used for comparisons of DImode vectors.
Used as part of arm_neon.h, in next/final patch.
Tested on aarch64-none-elf.
gcc/ChangeLog:
* config/aarch64/aarch64-simd.md (aarch64_vcond_internal,
vcond, vcondu,): Add DImode variant.
diff --git a/
This also makes the existing intrinsics tests apply to the new patterns.
Tested on aarch64-none-elf.
gcc/ChangeLog:
* config/aarch64/arm_neon.h (vceq_s64, vceq_u64, vceqz_s64, vceqz_u64,
vcge_s64, vcge_u64, vcgez_s64, vcgt_s64, vcgt_u64, vcgtz_s64, vcle_s64,
vcle_u64, vc
On 06/02/14 12:12, Jakub Jelinek wrote:
> Hi!
>
> I'd like to ping a few outstanding patches:
>
> - PR59575 P1 ARM dwarf2cfi ICEs fix
> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01997.html
>
Wasn't this already approved (with comment fix)?
https://gcc.gnu.org/ml/gcc-patches/2014-02/msg003
On 17/04/15 16:46, Richard Earnshaw wrote:
> On 06/02/14 12:12, Jakub Jelinek wrote:
>> Hi!
>>
>> I'd like to ping a few outstanding patches:
>>
>> - PR59575 P1 ARM dwarf2cfi ICEs fix
>> http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01997.html
>>
>
> Wasn't this already approved (with comment fix
From https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64134, testcase
#define vector __attribute__((vector_size(16)))
float a; float b;
vector float fb(void) { return (vector float){ 0,0,b,a};}
currently produces (correct, but suboptimal):
fb:
fmovs0, wzr
adrpx1, b
On 17/04/15 16:42, Tom Tromey wrote:
"Dave" == David Malcolm writes:
Dave> However within libcpp and gcc, in linemap's expanded_location and in
Dave> diagnostic messages, the "column" numbers are actually 1-based counts of
Dave> *characters*, so the "column" numbers emitted in diagnostics for
On 04/16/2015 12:57 PM, H.J. Lu wrote:
Uninitialized common symbol behavior in executables is target and linker
dependent. default_binds_local_p_3 is made public and updated to take an
argument to indicate if common symbol may be local. If common symbol
may be local, default_binds_local_p_3 wil
On 04/16/2015 02:38 PM, Andreas Tobler wrote:
Hi all,
the below is an attempt to warn a user when she/he builds a cross
compiler for *-*-freebsd* without giving a major version number.
Ok for trunk?
Thanks,
Andreas
2015-04-16 Andreas Tobler
* config.gcc: Exit with a comment when we do
On 04/16/2015 02:41 AM, Marek Polacek wrote:
On Thu, Apr 16, 2015 at 12:51:33AM +0200, Arnaud Bienner wrote:
Hi,
I've submitted a patch to bug 62182 [1], and I would like to have some
feedback about it (this is still WIP as noted in the bug).
As it is my first patch to gcc, I'm not sure what is
Hi,
On Fri, 2015-04-17 at 10:02 -0500, Bill Schmidt wrote:
> On Fri, 2015-04-17 at 16:49 +0200, Jakub Jelinek wrote:
> > You have actually mailed the original patch again, not the revised one.
>
> > That said, PARALLEL seems to be already handled by rtx_is_swappable_p,
> > so if it isn't handled
On Fri, Apr 17, 2015 at 11:32:44AM -0500, Bill Schmidt wrote:
> 2015-04-17 Bill Schmidt
>
> PR target/65787
> * config/rs6000/rs6000.c (rtx_is_swappable_p): Remove previous
> fix; ensure that a subsequent SH_NONE operand does not overwrite
> an existing *special value.
>
2015-04-17 18:32 GMT+03:00 Georg-Johann Lay :
> Am 04/17/2015 um 04:43 PM schrieb Denis Chertykov:
>>
>> 2015-04-17 17:02 GMT+03:00 Georg-Johann Lay :
>>>
>>> ...I went ahead and installed as
>>>
>>> http://gcc.gnu.org/r222179
>>>
>>> It will be backported to 5.2 as soon as 5.1 is open for patches
On 03/05/2015 09:50 AM, Yoshinori Sato wrote:
Add h8300-*-linux target for h8300 linux kernel and userland.
h8300-*-elf is some difference of standard elf.
h8300-*-linux is compatible of standard elf rules.
Thanks.
diff --git a/gcc/ChangeLog b/gcc/ChangeLog
index cfacea1..fc5101c 100644
--- a/
On April 17, 2015 2:37:08 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As discussed in the PR, during LTO bootstrap we have some hard to debug
>issues where different gc checking values between stage1 and stage2
>result
>in different GC collections and occassionally we generate different
>code for
>
On 04/16/2015 08:01 PM, Mikhail Maltsev wrote:
I would like to ping the following patch:
https://gcc.gnu.org/ml/gcc-patches/2014-12/msg01925.html
Review: https://gcc.gnu.org/ml/gcc-patches/2015-01/msg02672.html
I fixed minor issues mentioned in the review and updated the changelog
message. Rebas
On 03/19/2015 08:39 AM, Kyrill Tkachov wrote:
Hi all,
This patch fixes PR 65358. For details look at the excellent write-up
by Honggyu in bugzilla. The problem is that we're trying to pass a struct
partially on the stack and partially in regs during a tail-call
optimisation
but the struct we're
Yury Gribov writes:
> +
> +static bool
> +section_sanitized_p (const char *sec)
> +{
> + if (!sanitized_sections)
> +return false;
> + size_t len = strlen (sec);
> + const char *p = sanitized_sections;
> + while ((p = strstr (p, sec)))
> +{
> + if ((p == sanitized_sections || p[-1
On 04/17/2015 08:10 PM, Jeff Law wrote:
> Have you received confirmation from the FSF WRT your copyright
> assignment was accepted?
>
> jeff
>
Yes, it's ID is [gnu.org #972407]. Should I forward the PDF to you?
--
Regards,
Mikhail Maltsev
On Fri, Apr 17, 2015 at 06:39:59PM +0200, Jakub Jelinek wrote:
> The " && special_op != SH_NONE" test from the second if can go then,
> because it is never true. And I'd really think that you shouldn't change
> just the fmt[i] == 'E' handling, but also the fmt[i] == 'e' || fmt[i] == 'u'
> handling
Ping. Is this patch okay for trunk?
On 04/09/2015 03:16 PM, Martin Sebor wrote:
Attached is an updated patch that fixes the substr_6.f90
test that also prints a nul character to stdout. I don't
think there are any others.
Besides interfering with the debugging of the log corruption
I mentioned,
Hello!
This is just dead code for LRA-enabled target.
2015-04-17 Uros Bizjak
* config/i386/i386.h (LEGITIMIZE_RELOAD_ADDRESS): Remove.
* config/i386/i386.c (ix86_legitimize_reload_address): Ditto.
* config/i386/i386-protos.h (ix86_legitimize_reload_address): Ditto.
Bootstrapped,
On Thu, 2015-04-16 at 13:55 +0200, Richard Biener wrote:
> The following applies the patch produced earlier this year, applying
> TLC to array bound warnings and catching a few more cases.
>
> Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
>
> Richard.
>
> 2015-04-16 Richard Bien
Yep, thanks -- I just finished testing that, and it fixes the problem
with no regressions. Thanks for the help.
Is this ok to commit?
Thanks,
Bill
On Fri, 2015-04-17 at 19:46 +0200, Jakub Jelinek wrote:
> On Fri, Apr 17, 2015 at 06:39:59PM +0200, Jakub Jelinek wrote:
> > The " && special_op !=
On Tue, Apr 14, 2015 at 11:48 AM, Ian Lance Taylor wrote:
> This patch to the GCC 5 branch fixes PR 65755. This is a conservative
> patch for the branch. I will shortly apply a more complete, less
> conservative, patch to trunk. This patch simply adds the receiver
> type when producing the pkgp
Resending the previous message in a plain text format.
> Original Message
> Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION macro
> Date: Thursday, April 16, 2015 10:38 PM CEST
> From: "Moore, Catherine"
> To: "Maciej W. Rozycki" , Petar
> Jovanovic
> CC: 'Matthew Fo
On Fri, Apr 17, 2015 at 01:06:22PM -0500, Bill Schmidt wrote:
> Yep, thanks -- I just finished testing that, and it fixes the problem
> with no regressions. Thanks for the help.
>
> Is this ok to commit?
If David is ok with it, it is fine with me too. But, please commit to both
gcc-5-branch and
> -Original Message-
> From: Petar Jovanovic [mailto:petar.jovano...@rt-rk.com]
> Sent: Friday, April 17, 2015 2:23 PM
> To: Petar Jovanovic
> Cc: Maciej W. Rozycki; Matthew Fortune; gcc-patches@gcc.gnu.org; Moore,
> Catherine
> Subject: RE: [PATCH v2][MIPS] fix CRT_CALL_STATIC_FUNCTION m
On April 17, 2015 8:01:42 PM GMT+02:00, Steve Ellcey wrote:
>On Thu, 2015-04-16 at 13:55 +0200, Richard Biener wrote:
>> The following applies the patch produced earlier this year, applying
>> TLC to array bound warnings and catching a few more cases.
>>
>> Bootstrapped and tested on x86_64-unkno
On Fri, Apr 17, 2015 at 2:27 PM, Jakub Jelinek wrote:
> On Fri, Apr 17, 2015 at 01:06:22PM -0500, Bill Schmidt wrote:
>> Yep, thanks -- I just finished testing that, and it fixes the problem
>> with no regressions. Thanks for the help.
>>
>> Is this ok to commit?
>
> If David is ok with it, it is
On Fri, 17 Apr 2015, Richard Biener wrote:
The difference in behavior between bar and baz seems odd.
Yeah, I suppose VRP gets conservative in a way that's not helpful for
consistency of this warning. ~[0,0] and ~[-2,-2] likely meet as VARYING
and the warning code doesn't look at equivalence
DOM and jump threading both want to manipulate the SSA_NAME equivalency
tables. Right now DOM passes its table into the threader and the
threader manipulates the table directly (knowing its really just a
vector stack).
This results in duplicated code and a general lack of encapsulation.
This
On 04/17/2015 11:51 AM, mse...@redhat.com wrote:
Ping. Is this patch okay for trunk?
Yes, both are OK for the trunk.
Sorry for the delay, we're really just getting started working through
stuff that was queued up for stage1.
jeff
The libbacktrace library returns a PC that was (usually) decremented
to be part of the call instruction. The Go code that uses
runtime.Callers does not expect this, and Go code that adjusts the PC
value, such as libgo/go/runtime/pprof/pprof.go, can get fooled by it.
This leads to GCC PRs 64999 and
On Fri, 17 Apr 2015, Petar Jovanovic wrote:
> This issue will not trigger a linker error (I believe it treats the
> symbol referred by the relocation as a local symbol). This is a follow
> up to GLIBC BZ #17601, the problem is seen only at runtime. So, I think
> this brings back the need to run th
On 04/14/2015 02:11 AM, Kyrill Tkachov wrote:
Of course the effect on codegen of this patch depends a lot on the rtx
costs in the backend.
On aarch64 with -mcpu=cortex-a57 tuning I see the cost limit being
exceeded in more cases and the
expansion code choosing instead to do a move-immediate and
On Fri, 2015-04-17 at 21:08 +0200, Marc Glisse wrote:
> On Fri, 17 Apr 2015, Richard Biener wrote:
>
> >> The difference in behavior between bar and baz seems odd.
> >
> > Yeah, I suppose VRP gets conservative in a way that's not helpful for
> > consistency of this warning. ~[0,0] and ~[-2,-2] l
On 04/09/2015 11:31 PM, Adam Butcher wrote:
+ /* For generic lambdas, resolve default captured 'this' now. */
+ if (processing_template_decl
+ && is_dummy_object (instance)
+ && current_class_type
+ && CLASSTYPE_LA
On 04/17/2015 01:29 PM, Ian Lance Taylor wrote:
The libbacktrace library returns a PC that was (usually) decremented
to be part of the call instruction. The Go code that uses
runtime.Callers does not expect this, and Go code that adjusts the PC
value, such as libgo/go/runtime/pprof/pprof.go, can
On Fri, 2015-04-17 at 20:27 +0200, Jakub Jelinek wrote:
> On Fri, Apr 17, 2015 at 01:06:22PM -0500, Bill Schmidt wrote:
> > Yep, thanks -- I just finished testing that, and it fixes the problem
> > with no regressions. Thanks for the help.
> >
> > Is this ok to commit?
>
> If David is ok with it
As a follow-up, I got the same error with dl-close.c from glibc and
assumed it was the same type of code but when I looked at it and cut it
down I got this code and error. This seems more like a real GCC error
(in that it should not be warning). Note that I only get the error when
bad is declared
On 2015-04-17 20:58, Jason Merrill wrote:
On 04/09/2015 11:31 PM, Adam Butcher wrote:
+ /* For generic lambdas, resolve default captured 'this' now. */
This isn't quite right. We don't want to capture 'this' any time we
see a member function call, as overload resolution might c
On Apr 17, 2015, at 1:52 PM, Steve Ellcey wrote:
> struct link_namespaces *ns = &_dl_ns[nsid];
> (nsid != 0) ? (void) (0) : bad ("nsid != 0”);
Without disagreeing with the fact this looks like a bug, ideally, the two lines
above would be switched:
c++98:
If both the pointer operand and the
On Fri, Apr 17, 2015 at 1:03 PM, wrote:
> On 04/17/2015 01:29 PM, Ian Lance Taylor wrote:
>>
>> The libbacktrace library returns a PC that was (usually) decremented
>> to be part of the call instruction. The Go code that uses
>> runtime.Callers does not expect this, and Go code that adjusts the
GCC PR 65797 causes some of the runtime functions to be compiled with
no name in the debug info. This in turn causes the runtime/pprof test
to fail as reported in GCC PR 64683.
There are no good choices when a function has no name in the debug
info, but this patch assumes that if we see such a fu
On Fri, Apr 17, 2015 at 9:12 AM, Jeff Law wrote:
> On 04/16/2015 12:57 PM, H.J. Lu wrote:
>>
>> Uninitialized common symbol behavior in executables is target and linker
>> dependent. default_binds_local_p_3 is made public and updated to take an
>> argument to indicate if common symbol may be loca
On Fri, Apr 17, 2015 at 02:38:01PM -0700, H.J. Lu wrote:
>
Please add
PR target/65780
line to the ChangeLog entry. Ok for trunk and 5 branch with that change,
thanks.
> * config/i386/i386.c (ix86_binds_local_p): Define only if
> TARGET_MACHO and TARGET_DLLIMPORT_DECL_ATTRIBU
On Fri, 2015-03-20 at 17:50 +, Joseph Myers wrote:
> On Fri, 20 Mar 2015, David Malcolm wrote:
>
> > I believe that the presense of these markers in source code is almost
> > always a bug (are there any GCC frontends in which the markers are
> > parsable as something valid?)
>
> Well, obvious
PR 65798 says that in some cases runtime.Caller can return with ok ==
true when PC == 0. It's not clear to me quite how that can happen,
but it's easy to avoid with this patch. Bootstrapped and ran Go
testsuite on x86_64-unknown-linux-gnu. Committed to mainline and GCC
5 branch.
Ian
diff -r 400
On Fri, 17 Apr 2015, Steve Ellcey wrote:
As a follow-up, I got the same error with dl-close.c from glibc and
assumed it was the same type of code but when I looked at it and cut it
down I got this code and error. This seems more like a real GCC error
(in that it should not be warning). Note th
On Sat, 2015-04-18 at 00:15 +0200, Marc Glisse wrote:
> >
> > extern void bad (const char *__assertion) __attribute__ ((__noreturn__));
> > struct link_map { long int l_ns; };
> > extern struct link_namespaces
> > {
> >unsigned int _ns_nloaded;
> > } _dl_ns[1];
> > void _dl_close_worker (str
The attached patch works by adding the comment character to the set of
characters treated as separators. This works because a namelist comment
abstractly can be though of as equivalent to an end of line character. For
namelist the '!' character is already handled in the 'eat_separators' helper
100 matches
Mail list logo
