Ping!
On Tue, Nov 27, 2012 at 03:32:46PM +0530, Siddhesh Poyarekar wrote:
Ping!
Siddhesh
On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote:
Hi,
Ping!
Siddhesh
On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:
Hi,
Here's an updated version
Cc'ing Carlos on this so that he's aware of it.
Siddhesh
Jakub Jelinek ja...@redhat.com wrote:
On Sat, Jan 19, 2013 at 12:22:23PM -0500, Jason Merrill wrote:
Siddhesh has a patch to implement the thread atexit functionality in
glibc in order to integrate better with the dynamic loader and run
On Fri, 20 Jul 2012 22:24:57 -0400 (EDT), Hans-Peter wrote:
Sounds like a good idea, but I think you shouldn't limit that to
{} but rather introduce \ to escape and cause any next
character to be emitted as-is, in particular |.
I had dropped the change to escape | thinking it wasn't needed --
mentioned above is fixed.
Regards,
Siddhesh
[1] http://gcc.gnu.org/ml/gcc-patches/2012-07/msg00840.html
gcc/ChangeLog:
2012-07-25 Siddhesh Poyarekar siddh...@redhat.com
* final.c [ASSEMBLER_DIALECT](do_assembler_dialects): New
function to implement assembler dialects
On Wed, 25 Jul 2012 08:31:14 -0700, Richard wrote:
* gcc.dg/asm-dialect-1.c: New test case.
... except this should go in gcc.target/i386/ without the { target }
qualifier.
Thanks, here's the updated version.
Regards,
Siddhesh
gcc/ChangeLog:
2012-07-25 Siddhesh Poyarekar siddh
Hi,
Resending. I did not get any responses the last two times and I too
forgot about it. Can someone please review this?
Thanks,
Siddhesh
Begin forwarded message:
Date: Tue, 3 Apr 2012 18:46:53 +0530
From: Siddhesh Poyarekar siddh...@redhat.com
To: gcc-patches@gcc.gnu.org
Subject: Fw: [PATCH
Hi,
When the location for throw() exception specification is not the same
as the function it is written against, it leads gcov to give incorrect
results. See bug 50055 for details of the the same. The following
patch makes sure that the exception specification block (nothrow or
otherwise) is
information.
I think Siddhesh should be covered by the Red Hat assignment (it would help
if the patch has been mailed from a redhat.com address to notice that).
Thanks! I will keep that in mind for future submissions.
--
Siddhesh Poyarekar
http://siddhesh.in
transformation.
The patch does not introduce any regressions. I have tested this with
x86_64 and i686 and it works well with both of them.
Regards,
Siddhesh
gcc/ChangeLog:
2012-03-27 Siddhesh Poyarekar siddh...@redhat.com
* final.c (output_asm_insn, asm_fprintf): Print curly braces
Hi,
ping?
--
Siddhesh
Begin forwarded message:
Date: Tue, 27 Mar 2012 10:51:37 +0530
From: Siddhesh Poyarekar siddh...@redhat.com
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Allow printing of escaped curly braces in assembler
directives with operands
Hi,
An assembler directive
to think that the test case is
incorrect. I am not sure what the test case verifies since the array
accesses are obviously beyond bounds.
Regards,
Siddhesh
testsuite/ChangeLog:
2012-11-09 Siddhesh Poyarekar siddh...@redhat.com
* gcc.dg/Warray-bounds-3.c (bar): Keep array access within
in the testsuite that I haven't figured out yet.
I have tested the patch on x86_64 for C language and the testsuite
reports no regressions. In fact, it seems to have fixed a previous
failure in gcc.dg/vect/slp-perm-9.c.
Regards,
Siddhesh
ChangeLog:
2012-11-09 Siddhesh Poyarekar siddh...@redhat.com
On Fri, 9 Nov 2012 17:34:26 +0100, Jan wrote:
I don't mind saying that GCC should define cases that the language
standards leave undefined. But that does not seem to be what this
patch does. I don't see why this is a good idea. It seems to
produce a program that is unpredictable in a
On Fri, 09 Nov 2012 11:57:44 -0700, Jeff wrote:
The off-by-one aspects of 31227 ought to be corrected.
Ok for the trunk,
I don't have write access (not sure if I qualify for it yet with just a
couple of trivial patches so far) so I need someone to commit for me.
Thanks,
Siddhesh
On Fri, 9 Nov 2012 22:51:45 +0530, Siddhesh wrote:
I had reckoned that the behaviour could be reverted to what was before
while I figure out a way to get the warning in place for both cases,
i.e. with tree-vrp (where max_loop_iterations now causes the loop to
be folded away in -O2) and this
Hi,
Here's an updated version of the patch which warns the user if the
removing of redundant exits results in an infinite loop. I have added
an additional flag in struct loop called external_exits to record if
an exit edge is moved outside the loop body. This currently happens in
the
Hi,
Current HEAD fails build when --enable-languages=c, i.e. C++ is not
being built. Attached patch fixes this.
Regards,
Siddhesh
ChangeLog:
2012-11-15 Siddhesh Poyarekar siddh...@redhat.com
* configure.ac: Disable libsanitizer if we're not building C++.
* configure
Hi,
Ping!
Siddhesh
On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:
Hi,
Here's an updated version of the patch which warns the user if the
removing of redundant exits results in an infinite loop. I have added
an additional flag in struct loop called external_exits to record if
an
Hi,
Ping!
Siddhesh
On Thu, 15 Nov 2012 19:52:21 +0530, Siddhesh wrote:
Hi,
Current HEAD fails build when --enable-languages=c, i.e. C++ is not
being built. Attached patch fixes this.
Regards,
Siddhesh
ChangeLog:
2012-11-15 Siddhesh Poyarekar siddh...@redhat.com
Ping!
Siddhesh
On Wed, Nov 21, 2012 at 12:42:13PM +0530, Siddhesh Poyarekar wrote:
Hi,
Ping!
Siddhesh
On Thu, 15 Nov 2012 19:05:38 +0530, Siddhesh wrote:
Hi,
Here's an updated version of the patch which warns the user if the
removing of redundant exits results
Ping!
Siddhesh
On Wed, Nov 21, 2012 at 12:43:10PM +0530, Siddhesh Poyarekar wrote:
Hi,
Ping!
Siddhesh
On Thu, 15 Nov 2012 19:52:21 +0530, Siddhesh wrote:
Hi,
Current HEAD fails build when --enable-languages=c, i.e. C++ is not
being built. Attached patch fixes
On Tue, Nov 27, 2012 at 11:05:47AM +0100, Jakub Jelinek wrote:
On Thu, Nov 15, 2012 at 07:52:21PM +0530, Siddhesh Poyarekar wrote:
2012-11-15 Siddhesh Poyarekar siddh...@redhat.com
* configure.ac: Disable libsanitizer if we're not building C++.
* configure: Regenerate.
Ok
Ping!
Siddhesh
On 4 November 2016 at 21:17, Siddhesh Poyarekar
<siddhesh.poyare...@linaro.org> wrote:
> This adds an mcpu option for the upcoming Qualcomm Falkor core. This
> is identical to the qdf24xx part that was added earlier and hence
> retains the same tuning structur
Hi,
This patch documents the newly added flag in gcc 7 for the upcoming
Qualcomm Falkor processor core.
Siddhesh
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.24
This adds an mcpu option for the upcoming Qualcomm Falkor core. This
is identical to the qdf24xx part that was added earlier and hence
retains the same tuning structure and continues to have the a57
pipeline for now. The part number has also been changed and this
patch fixes this for both
On 3 November 2016 at 23:08, Andrew Pinski wrote:
> This patch no longer applies after the recent changes (starting around
> a month ago) to aarch64-cores.def. Please updat the patch for the
> recent changes
Sorry about that, I'll post an updated patch shortly.
Siddhesh
This adds an mcpu option for the upcoming Qualcomm Falkor core. This
is identical to the qdf24xx part that was added earlier and hence
retains the same tuning structure and continues to have the a57
pipeline for now. The part number has also been changed and this
patch fixes this for both
On 5 January 2017 at 05:00, Gerald Pfeifer wrote:
> In case you are wondering, Siddhesh, Richard was referring
> to https://gcc.gnu.org/gcc-7/changes.html and at
> https://gcc.gnu.org/about.html you'll find some documentation
> on how to go about updating that.
I did post a
Hi,
This patch documents the newly added flag in gcc 7 for the upcoming
Qualcomm Falkor processor core.
Siddhesh
Index: htdocs/gcc-7/changes.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/gcc-7/changes.html,v
retrieving revision 1.33
On Friday 24 November 2017 05:36 PM, Siddhesh Poyarekar wrote:
> freq_max < 1, i.e. highest frequency among bbs in the function being
> higher than real_bb_freq_max means that the bb ends up with a profile
> count larger than real_bb_freq_max and then can go all the way up to
freq_max < 1, i.e. highest frequency among bbs in the function being
higher than real_bb_freq_max means that the bb ends up with a profile
count larger than real_bb_freq_max and then can go all the way up to
and beyond profile_count::max_count.
Bootstrapped on aarch64, testsuite in progress.
On 3 November 2017 at 15:50, Richard Earnshaw
<richard.earns...@foss.arm.com> wrote:
>> 2017-10-27 Siddhesh Poyarekar <siddhesh.poyare...@linaro.org>
>> Jim Wilson <jim.wil...@linaro.org>
>>
>> gcc/
>> *
Ping!
Siddhesh
On 27 October 2017 at 18:13, Siddhesh Poyarekar <siddh...@gotplt.org> wrote:
> From: Siddhesh Poyarekar <siddhesh.poyare...@linaro.org>
>
> This patch adds an mcpu option for the Qualcomm saphira server part.
> Tested on aarch64 and did not find any re
r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
which this comment about X30 not being marked as call-clobbered is no
longer accurate.
Siddhesh
* config/aarch64/aarch64.h: Remove obsolete comment.
---
gcc/config/aarch64/aarch64.h | 9 -
1 file changed, 9
On 06/05/2018 10:02 PM, Kyrill Tkachov wrote:
Adding some folks who know more about other CPUs as well.
Are you okay with enabling these instructions in AArch64?
If you could give this a spin on some benchmarks you
care about on your platforms it would be really useful data.
Sameera had
On 29 May 2018 at 21:17, James Greenhalgh wrote:
> On Tue, May 29, 2018 at 05:01:42AM -0500, Sameera Deshpande wrote:
>> Hi!
>>
>> Please find attached the patch to add support of ARMv8.4 in saphira
>> for Qualcomm server part. Tested on aarch64, without any regressions.
>>
>> Ok for trunk?
>
>
On 07/02/2018 03:29 PM, Kyrill Tkachov wrote:
Nice! What were the regressions though? Would be nice to adjust the tests
to make them more robust so that we have as clean a testsuite as possible.
Sure, they're gcc.dg/guality/pr36728-2.c and gcc.target/aarch64/extend.c.
The addressing mode
-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aarch64/t-aarch64 (falkor-tag-collision-avoidance.o):
Likewise.
* config/aarch64/aarch64
On 06/19/2018 09:11 PM, James Greenhalgh wrote:
On Mon, Jun 18, 2018 at 08:43:04AM -0500, Siddhesh Poyarekar wrote:
r217431 changed X30 as caller-saved in CALL_USE_REGISTERS because of
which this comment about X30 not being marked as call-clobbered is no
longer accurate.
Is the second
From: Siddhesh Poyarekar <siddhesh.poyare...@linaro.org>
This patch adds an mcpu option for the Qualcomm saphira server part.
Tested on aarch64 and did not find any regressions resulting from this
patch.
Siddhesh
2017-10-27 Siddhesh Poyarekar <siddhesh.poyare...@l
On Wednesday 17 January 2018 08:31 PM, Wilco Dijkstra wrote:
> Why is that a bad thing? With the patch as is, the testcase generates:
>
> .L4:
> ldr q0, [x2, x3]
> add x5, x1, x3
> add x3, x3, 16
> cmp x3, x4
> str q0, [x5]
> bne .L4
>
On Wednesday 17 January 2018 07:07 PM, Wilco Dijkstra wrote:
> (finished version this time, somehow Outlook loves to send emails early...)
>
> Hi,
>
> In general I think the best way to achieve this would be to use the
> existing cost models which are there for exactly this purpose. If
> this
On Wednesday 17 January 2018 11:13 PM, Wilco Dijkstra wrote:
> Are you saying the same issue exists for all stores with writeback? If so then
> your patch would need to address that too.
Yes, I'll be posting a separate patch for that because the condition set
is slightly different for it. It
ro.org>
Kugan Vivenakandarajah <kugan.vivekanandara...@linaro.org>
Siddhesh Poyarekar <siddh...@sourceware.org>
gcc/
* gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type):
New member ADDR_QUERY_STR.
* gcc/config/aarch64/aar
From: Siddhesh Poyarekar <siddh...@sourceware.org>
* MAINTAINERS (write after approval): Add myself.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@256836
138bc75d-0d04-0410-961f-82ee72b054a4
---
ChangeLog | 4
MAINTAINERS | 1 +
2 files changed, 5 insertions(+)
diff
org>
Kugan Vivenakandarajah <kugan.vivekanandara...@linaro.org>
Siddhesh Poyarekar <siddh...@sourceware.org>
gcc/
* gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type):
New member ADDR_QUERY_STR.
* gcc/config/aarch64/aarch6
On Wednesday 24 January 2018 06:29 PM, Siddhesh Poyarekar wrote:
>>> + /* Avoid register indexing for 128-bit stores when the
>>> + AARCH64_EXTRA_TUNE_SLOW_REGOFFSET_QUADWORD_STORE option is set. */
>>> + if (!optimize_size
>>&
% and intspeed by 0.62% in CPU2017,
with xalancbmk_s (3.84%) wrf_s (1.46%) and mcf_s (1.62%) being the
biggest winners. There were no regressions beyond 0.4%.
2018-xx-xx Jim Wilson <jim.wil...@linaro.org>
Kugan Vivenakandarajah <kugan.vivekanandara...@linaro.org>
On Thursday 15 February 2018 07:50 PM, Wilco Dijkstra wrote:
> So it seems to me using existing cost mechanisms is always preferable, even
> if you
> currently can't differentiate between loads and stores.
Luis is working on address cost adjustments among other things, so I
guess the path of
Ping!
On Friday 09 February 2018 01:02 PM, Siddhesh Poyarekar wrote:
> Hi,
>
> Here's v3 of the patch to disable register offset addressing mode for
> stores of 128-bit values on Falkor because they're very costly.
> Following Kyrill's suggestion, I compared the codegen for
On Tuesday 20 February 2018 03:14 PM, Jakub Jelinek wrote:
> On Mon, Feb 19, 2018 at 09:59:00PM +0530, Siddhesh Poyarekar wrote:
>> The C++ frontend generates a break that results in the fallthrough
>> warning misfiring in nested switch blocks where cases in the inner
>>
On Monday 19 February 2018 09:59 PM, Siddhesh Poyarekar wrote:
> The C++ frontend generates a break that results in the fallthrough
> warning misfiring in nested switch blocks where cases in the inner
> switch block return, rendering the break pointless. The fallthrough
&g
The C++ frontend generates a break that results in the fallthrough
warning misfiring in nested switch blocks where cases in the inner
switch block return, rendering the break pointless. The fallthrough
detection in finish_break_stmt does not work either because the
condition is encoded as an
On Friday 02 February 2018 05:15 AM, Martin Sebor wrote:
> PR middle-end/84095 - false-positive -Wrestrict warnings for memcpy within
> array
>
> gcc/ChangeLog:
>
> PR middle-end/84095
> * gimple-ssa-warn-restrict.c (builtin_memref::extend_offset_range): New.
>
Libraries like gtk/glib[1] and python[2] use functions with common
argument subsets to register callbacks. The working idea behind it is
to have a flag in the structure (or some other pre-determined method)
that specifies how the callback is cast and called.
Fix this by not throwing a warning
On Friday 23 February 2018 09:20 PM, David Malcolm wrote:
> Do we have a PR open for this yet?
>
> I believe this is an example of where this bit (for the Python case):
> https://github.com/imageworks/OpenColorIO/pull/518
There is now:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84531
On Friday 23 February 2018 09:22 PM, Martin Sebor wrote:
> I see no failures in this test in any of the recently reported
> results on any targets except those below:
>
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01530.html
>
On Saturday 24 February 2018 12:01 AM, Richard Biener wrote:
> I don't see how the function cast is valid.
>
> I've argued for void (*) () to/from void (*) (int), etc. In the past and that
> was shot down similarly. This looks like exactly the same thing.
That should not throw a warning
On Saturday 24 February 2018 01:32 AM, Martin Sebor wrote:
> Casting the address of a function that takes one or more arguments
> to one that takes fewer is unsafe because when the pointer is used
> to call the function the extra arguments have indeterminate values.
> (This is also why
On Saturday 24 February 2018 03:28 AM, Martin Sebor wrote:
> In my mind that would be a perfectly reasonable approach.
> A variation on it might be to leave a new warning disabled
> in the first release, then include it in -Wextra the next
> release, and finally put it in -Wall.
>
>
Ping!
Siddhesh
On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.
The falkor hardware prefetching system uses a combination of the
source, destination and offset
On 08/02/2018 04:19 PM, Kyrill Tkachov wrote:
Hi Siddhesh,
On 02/08/18 11:23, Siddhesh Poyarekar wrote:
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any noticeable
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any noticeable difference in
performance (there's a very small bump of 1.7% in x264 but that's
about it) in my tests but is
On 08/03/2018 12:02 AM, James Greenhalgh wrote:
On Thu, Aug 02, 2018 at 11:58:37AM -0500, Siddhesh Poyarekar wrote:
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any
There was a typo in the pipeline description where DUP was assigned to
the vector pipes for quad mode ops when it really only uses the VTOG
pipes. Fixing this does not show any noticeable difference in
performance (there's a very small bump of 1.7% in x264 but that's
about it) in my tests but is
Hello,
Ping!
On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.
The falkor hardware prefetching system uses a combination of the
source, destination and offset to decide
On 08/07/2018 10:30 PM, James Greenhalgh wrote:
To help set expectations here. I'm currently only able to dedicate a couple
of hours of time to review each week. Tamar's Stack Clash has been taking
a big chunk of that time recently as we push it to a final state for trunk.
This pass is... large
On 08/01/2018 04:24 AM, James Greenhalgh wrote:
OK if this is what is best for your subtarget.
I have pushed this on behalf of Luis since he is on holiday.
Thanks,
Siddhesh
On 08/01/2018 04:23 AM, James Greenhalgh wrote:
On Wed, Jul 25, 2018 at 01:10:34PM -0500, Luis Machado wrote:
The adjusted vector costs give Falkor a reasonable boost in performance for FP
benchmarks (both CPU2017 and CPU2006) and doesn't change INT benchmarks that
much. About 0.7% for CPU2017
Hello,
Ping!
Siddhesh
On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.
The falkor hardware prefetching system uses a combination of the
source, destination and offset
Ping!
On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.
The falkor hardware prefetching system uses a combination of the
source, destination and offset to decide which
Ping!
On 07/24/2018 12:37 PM, Siddhesh Poyarekar wrote:
Hi,
This is a rewrite of the tag collision avoidance patch that Kugan had
written as a machine reorg pass back in February.
The falkor hardware prefetching system uses a combination of the
source, destination and offset to decide which
On 07/13/2018 06:32 PM, Kyrill Tkachov wrote:
This looks good to me modulo a couple of minor comments inline.
You'll still need an approval from a maintainer.
Thanks, I'll send a fixed up version on Monday.
+ for (ause= DF_REG_USE_CHAIN (regno); ause; ause = DF_REF_NEXT_REG
(ause))
+ {
that falkor does not support sve
Changes from v1:
- Fixed up issues pointed out by Kyrill
- Avoid renaming R0/V0 since they could be return values
- Fixed minor formatting issues.
2018-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision
R0/V0 since they could be return values
- Fixed minor formatting issues.
2018-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aarch64/t-aarch64
On 07/16/2018 09:59 PM, Kyrill Tkachov wrote:
I think this looks ok now. You'll still need a maintainer to approve it
though.
Thank you for the review Kyrill, but also apologies for wasting your
time on it. I just found that the patch breaks a test so I'm currently
reviewing it to see
On Thursday 30 August 2018 01:28 PM, Siddhesh Poyarekar wrote:
On Wednesday 29 August 2018 10:05 PM, James Greenhalgh wrote:
Sorry that this took me so long to get to. > > The code is
outstanding quality, a textbook example of writing an
> analysis/optimization pass using m
On Wednesday 29 August 2018 10:05 PM, James Greenhalgh wrote:
Sorry that this took me so long to get to. > > The code is outstanding quality, a textbook example of writing an
> analysis/optimization pass using modern GCC frameworks and data >
structures! If you ever find the opportunity, I bet
- Avoid renaming R0/V0 since they could be return values
- Fixed minor formatting issues.
2018-07-02 Siddhesh Poyarekar
Kugan Vivekanandarajah
* config/aarch64/falkor-tag-collision-avoidance.c: New file.
* config.gcc (extra_objs): Build it.
* config/aarch64
From: Siddhesh Poyarekar <siddh...@sourceware.org>
Hi,
Jim Wilson posted a patch for this in September[1] and it appears
following discussions that the patch was an acceptable fix for falkor.
Kugan followed up[2] with a test case since that was requested during
initial review. Jim has
% in CPU2017,
with omnetpp_s (4.3%) and pop2_s (2.6%) being the biggest winners.
2018-xx-xx Jim Wilson <jim.wil...@linaro.org>
Kugan Vivenakandarajah <kugan.vivekanandara...@linaro.org>
Siddhesh Poyarekar <siddh...@sourceware.org>
gcc/
* gcc/conf
On Wednesday 24 January 2018 05:50 PM, Kyrill Tkachov wrote:
> I would tend towards making the costs usage more intelligent and
> differentiating
> between loads and stores but I agree that is definitely GCC 9 material.
> Whether this approach is an acceptable stopgap for GCC 8 is up to the
>
Avoid issuing a bogus warning when the source of strncpy is bound by a
constant and is known to be less than the size of the destination.
Testsuite run is underway (not complete yet, but no new errors so far)
and a bootstrap is also underway, I'll report status once they're both
done.
gcc/
Avoid issuing a bogus warning when the source of strncpy is bound by a
constant known to be less than the minimum size of the destination.
Changes from v1:
- Use range-info instead of the MIN_EXPR hack
- Get the minimum size of dst and check for NULL_TREE return
The patch bootstraps
On Monday 12 March 2018 03:26 PM, Richard Biener wrote:
> Please use tree_int_cst_lt (rhs1, dstsize) instead.
>
>> + {
>> + gimple_set_no_warning (stmt, true);
>
> Why this? There's only a single bit -- where do we warn from if you
> don't do this here?
I incorrectly
On Wednesday 14 March 2018 08:40 PM, Richard Biener wrote:
> Instead of building a tree from max you should use
>
> if (wi::to_widest (max) < wi::to_widest (wi::to_wide (dstsize)))
> return;
>
> given compute_objsize is somewhat confused about the type it returns
> a widest_int compare
On 8/25/21 5:44 PM, Matthias Klose wrote:
On 7/28/21 1:44 PM, David Malcolm via Gcc-patches wrote:
On Wed, 2021-07-28 at 10:34 +0530, Siddhesh Poyarekar wrote:
Recognize __builtin_free as being equivalent to free when passed into
__attribute__((malloc ())), similar to how it is treated when
On 10/13/21 00:36, Martin Sebor wrote:
On 10/12/21 12:33 PM, Siddhesh Poyarekar wrote:
The warning is falsely triggered for THREAD_SELF in glibc when
accessing TCB through the segment register.
Thanks for looking into it! The Glibc warning is being tracked
in PR 102630. The root cause
Recognize the __builtin_dynamic_object_size builtin, but simply
replace it with -1 or 0 for now.
gcc/ChangeLog:
* builtins.c (expand_builtin, fold_builtin_2): Add
BUILT_IN_DYN_OBJECT_SIZE.
(fold_builtin_dyn_object_size): New function.
(valid_object_size_args): New
crosses a threshold. I'll take this up once we
have more data on the nature of the bottlenecks.
Siddhesh Poyarekar (8):
__builtin_dynamic_object_size: Recognize builtin name
tree-dynamic-object-size: New pass
tree-dynamic-object-size: Handle GIMPLE_PHI
tree-dynamic-object-size: Support
.
* gcc.dg/builtin-object-size-16.c: Likewise.
* gcc.dg/builtin-object-size-17.c: Likewise.
* gcc.dg/builtin-object-size-2.c: Likewise.
* gcc.dg/builtin-object-size-3.c: Likewise.
* gcc.dg/builtin-object-size-4.c: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
.../g
, gimplify_size_exprs): Adjust.
(parm_object_size): New function.
(collect_object_sizes_for): Handle GIMPLE_NOP.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-dynamic-object-size-0.c (test_parmsz): New
test.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
.
(addr_dyn_object_size): Call it. Support subobject size
computation.
gcc/testsuite/ChangeLog:
* gcc.dg/builtin-dynamic-object-size-0.c
(test_dynarray_struct_subobj): New test.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 34
-off-by: Siddhesh Poyarekar
---
gcc/Makefile.in | 19 +-
gcc/builtins.c| 8 +
gcc/doc/extend.texi | 11 +
gcc/passes.def| 3 +
.../gcc.dg/builtin-dynamic-object-size-0.c
ct_wholesizes and
object_wholesize_exprs.
gcc/testsuite/ChangeLog
* gcc.dg/builtin-dynamic-object-size-0.c (dynarray_struct):
New struct.
(test_dynarray_struct, test_substring,
test_substring_ptrplus): New tests.
(main): Call them.
Signed-off-by: Siddh
, test_builtin_malloc_condphi2,
test_builtin_malloc_condphi3, test_builtin_calloc_condphi,
test_deploop): New tests.
(main): Call them.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object-size-0.c| 92 +++
gcc/tree-dynamic-object-size.c| 258
,
test_passthrough_nonssa): New tests.
(main): Call them.
Signed-off-by: Siddhesh Poyarekar
---
gcc/builtins.c| 2 +-
.../gcc.dg/builtin-dynamic-object-size-0.c| 37 +++
gcc/tree-dynamic-object-size.c| 255 +-
3
On 10/13/21 13:50, Richard Biener wrote:
On Tue, Oct 12, 2021 at 8:34 PM Siddhesh Poyarekar wrote:
The warning is falsely triggered for THREAD_SELF in glibc when
accessing TCB through the segment register.
I think this is a more generic bug - the warning is also bogus if the
general address
On 10/8/21 03:44, Siddhesh Poyarekar wrote:
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index 133b82eef38..082d167cd65 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -12777,6 +12777,17 @@ assert (__builtin_object_size (q, 1) == sizeof
(var.b));
@end smallexample
On 10/8/21 03:44, Siddhesh Poyarekar wrote:
(from about 4% to 70% in bash), but that could well be due to the _chk
I should also clarify that this is for memcpy. For all fortifiable
functions, the coverage percentage went from 30.81% to 84.5% for bash.
Below is the full table. Please note
1 - 100 of 377 matches
Mail list logo