)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-3.c (test1)
[__builtin_object_size]: Likewise.
* gcc.dg/builtin-object-size-4.c (test1)
[__builtin_object_size]: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
.../gcc.dg/builtin-dynamic-object
On 11/01/2022 15:13, Jakub Jelinek wrote:
On Tue, Jan 11, 2022 at 02:27:47PM +0530, Siddhesh Poyarekar wrote:
Handle GIMPLE_PHI and conditionals specially for dynamic objects,
returning PHI/conditional expressions instead of just a MIN/MAX
estimate.
This makes the returned object size variable
oid
computing offset for -1 size.
gcc/testsuite/ChangeLog:
PR tree-optimization/pr103961
* gcc.dg/pr103961.c: New test case.
Co-authored-by: Jakub Jelinek
Signed-off-by: Siddhesh Poyarekar
---
Tested with i686 build+test, x86_64 bootstrap build+test and ubsan
bootstrap.
gcc/testsu
On 11/01/2022 19:04, Jakub Jelinek wrote:
On Tue, Jan 11, 2022 at 06:40:44PM +0530, Siddhesh Poyarekar wrote:
Never try to compute size for offset when the object size is -1, which
is either unknown maximum or uninitialized minimum irrespective of the
osi->pass number.
gcc/Change
zero size for negative offsets.
* gcc.dg/builtin-object-size-4.c (test8): Likewise.
* gcc.dg/builtin-object-size-5.c (test7): Drop test for
__builtin_object_size.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- bootstrap build+test for x86_64
- build+test for i686
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 t
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 t
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 to
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
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
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 F
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 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
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 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
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?
>
> I'
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 writte
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 dele
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
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 moved on from Linaro, so I&#
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 doe
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 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 will
gan Vivenakandarajah
Siddhesh Poyarekar
gcc/
* gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type):
New member ADDR_QUERY_STR.
* gcc/config/aarch64/aarch64-tuning-flags.def
(SLOW_REGOFFSET_QUADWORD_STORE): New.
* gcc/config/aarch64/aarch6
Kugan Vivenakandarajah
Siddhesh Poyarekar
gcc/
* gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type):
New member ADDR_QUERY_STR.
* gcc/config/aarch64/aarch64-tuning-flags.def
(SLOW_REGOFFSET_QUADWORD_STORE): New.
* gcc/config/aarch64
From: Siddhesh Poyarekar
* 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 --git a/ChangeLog b/ChangeLog
index
eed by 0.22% in CPU2017,
with omnetpp_s (4.3%) and pop2_s (2.6%) being the biggest winners.
2018-xx-xx Jim Wilson
Kugan Vivenakandarajah
Siddhesh Poyarekar
gcc/
* gcc/config/aarch64/aarch64-protos.h (aarch64_addr_query_type):
New member
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
> aarch
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
>>&
oves fpspeed by 0.17% 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
Kugan Vivenakandarajah
Siddhesh Poyarekar
gcc/
* co
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 co
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 leas
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 IF_ST
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
>
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 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.
> (builtin_memref:
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 whe
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
Siddhe
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
> https://gcc.gnu.org/ml/gcc-testresults/2018-02/msg01514.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 becaus
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 void(*)(void
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.
>
> Unfortunately,
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/
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 thoug
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 successfully
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 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
From: Siddhesh Poyarekar
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
Jim Wilson
gcc/
* config/aarch64
Ping!
Siddhesh
On 27 October 2017 at 18:13, Siddhesh Poyarekar wrote:
> From: Siddhesh Poyarekar
>
> 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
&
On 3 November 2017 at 15:50, Richard Earnshaw
wrote:
>> 2017-10-27 Siddhesh Poyarekar
>> Jim Wilson
>>
>> gcc/
>> * config/aarch64/aarch64-cores.def (saphira): New.
>> * config/aarch64/aarch64-tune.md: Regenerated.
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 patch and you reviewe
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
di
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 qdf24xx
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 qdf24xx
Ping!
Siddhesh
On 4 November 2016 at 21:17, Siddhesh Poyarekar
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 structure and continues to have the a57
> pipe
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
di
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
* gcc.dg/Warray-bounds-3.c (bar): Keep array access within
bounds for
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
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
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 loop-unswit
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
* configure.ac: Disable libsanitizer if we're not building C++.
* configure: Regenerate.
diff --
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
>
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:
>
&g
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 war
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
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
> >
> > * configure.ac: Disable libsanitizer if we're not building C++.
> > * config
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
Cc'ing Carlos on this so that he's aware of it.
Siddhesh
Jakub Jelinek 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
> the cleanups
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
To: gcc-patches@gcc.gnu.org
Subject: Fw: [PATCH] Allow printing of
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 ne
this patch that
verifies that the double '|' bug I 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
* final.c [ASSEMBLER_DIALECT](do_assembler_dialects): New
functi
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:
2
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 alway
s...@gnu.org for more 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
in asm string literals
without operands since they do not undergo any 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
* final.c
Hi,
ping?
--
Siddhesh
Begin forwarded message:
Date: Tue, 27 Mar 2012 10:51:37 +0530
From: Siddhesh Poyarekar
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] Allow printing of escaped curly braces in assembler
directives with operands
Hi,
An assembler directive with an operand is filtered
On 2024-10-04 07:52, Jonathan Wakely wrote:
This doesn't really belong in our testsuite, because the sole purpose of
the new test is to find bugs in the Glibc wrappers (like the one linked
below). But maybe it's a kindness to do it in our testsuite, because we
already have this test in place, and
On 2024-09-27 06:31, Jakub Jelinek wrote:
On Fri, Sep 20, 2024 at 12:40:26PM -0400, Siddhesh Poyarekar wrote:
When wholesize != size, there is a reasonable opportunity for static
object sizes also to be computed using size_for_offset, so use that.
gcc/ChangeLog:
* tree-object-size.cc
On 2024-10-04 10:03, Siddhesh Poyarekar wrote:
diff --git a/libstdc++-v3/testsuite/17_intro/names.cc
b/libstdc++-v3/testsuite/17_intro/names.cc
index 6b9a3639aad..bbf45b93dee 100644
--- a/libstdc++-v3/testsuite/17_intro/names.cc
+++ b/libstdc++-v3/testsuite/17_intro/names.cc
@@ -377,4 +377,11
When wholesize != size, there is a reasonable opportunity for static
object sizes also to be computed using size_for_offset, so use that.
gcc/ChangeLog:
* tree-object-size.cc (plus_stmt_object_size): Call
SIZE_FOR_OFFSET for some negative offset cases.
* testsuite/gcc.dg/b
make-check did not introduce any new regressions
- i686 build and make-check did not introduce any new regressions
- Bootstrap build with bootstrap-ubsan config succeeded.
Thanks,
Sid
Siddhesh Poyarekar (4):
tree-object-size: use size_for_offset in more cases
tree-object-size: Fold PHI node
):
New functions.
(main): Call them.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 63
gcc/testsuite/gcc.dg/builtin-object-size-3.c | 63
gcc/tree-object-size.cc | 60
geLog:
PR middle-end/77608
* tree-object-size.cc (plus_stmt_object_size): Drop check for
constant offset.
* testsuite/gcc.dg/builtin-object-size-1.c (test14): New test.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/builtin-object-size-1.c
): Likewise.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 20 +++
gcc/testsuite/gcc.dg/builtin-object-size-3.c | 20 +++
gcc/tree-object-size.cc | 58
3 files changed, 86 insertions(+), 12 deletions(-)
diff
On 2024-09-20 21:42, Siddhesh Poyarekar wrote:
On 2024-09-20 20:20, Sam James wrote:
Siddhesh Poyarekar writes:
This series makes a few improvements to get static object size
estimates in
more cases, thus improving the success rate of the static
__builtin_object_size. This should fully fix
On 2024-09-20 20:20, Sam James wrote:
Siddhesh Poyarekar writes:
This series makes a few improvements to get static object size estimates in
more cases, thus improving the success rate of the static
__builtin_object_size. This should fully fix PR116556 and also covers a bulk
of use cases for
t-size-1.c (test12): New test.
(main): Call it.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gcc.dg/builtin-object-size-1.c | 21
gcc/tree-object-size.cc | 6 +++---
2 files changed, 24 insertions(+), 3 deletions(-)
diff --git a/gcc/t
e-3.c (test10): Adjust expected size.
Signed-off-by: Siddhesh Poyarekar
---
Testing:
- bootstrapped on x86_64
- tested on i686, no new regressions
- bootstrapp with config-ubsan in progress
.../g++.dg/ext/builtin-object-size2.C | 27 ++
gcc/testsuite/gcc.dg/builtin-object
Ping!
On 2024-12-19 08:16, Siddhesh Poyarekar wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
gcc/testsuite/ChangeLog:
PR testsuite/118127
* gfortr
s.exp
(check_effective_target_ppc_not_well_defined_denormals): New
procedure.
* gfortran.dg/default_format_2.f90: xfail for
ppc_not_well_defined_denormals.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
Signed-off-by: Siddhesh Poya
On 2025-01-29 07:34, Jakub Jelinek wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so don't
XFAIL some gfortran tests on ppc64le when configured with the IEEE128
long double ABI.
If long double is just IEEE754 double, then I think denormals
are equally well behaved, it is so
On 2025-01-29 08:24, Jakub Jelinek wrote:
On Wed, Jan 29, 2025 at 08:19:38AM -0500, Siddhesh Poyarekar wrote:
Denormal behaviour is well defined for IEEE128 long doubles, so
XFAIL some gfortran tests only for targets with the IBM128 long double
ABI.
gcc/testsuite/ChangeLog:
PR
ieee128_ok.
* gfortran.dg/default_format_denormal_2.f90: Likewise.
* gfortran.dg/large_real_kind_form_io_2.f90: Likewise.
Signed-off-by: Siddhesh Poyarekar
---
gcc/testsuite/gfortran.dg/default_format_2.f90 | 2 +-
gcc/testsuite/gfortran.dg/default_format_denormal_2.f90 |
301 - 400 of 421 matches
Mail list logo
