On Mon, 7 Feb 2022, Joseph Myers wrote:
> On Fri, 4 Feb 2022, Richard Biener via Gcc-patches wrote:
>
> > This adds explicit variable birth CLOBBERs in an attempt to fix
> > PR90348 and duplicates. The birth / death CLOBBER pairs are
> > used to compute liveness and conflicts for stack variable
The following improves early uninit diagnostics by computing edge
reachability using our value-numbering framework in its cheapest
mode and ignoring unreachable blocks when looking
for uninitialized uses. To not ICE with -fdump-tree-all the
early uninit pass needs a dumpfile since VN tries to
The polarity of do/do not was reversed for this option when compored to
the rest of them. This seems to have been copied from PowerPC, when the
polarity of the arguments in the docs was reversed (presumably to match
the default), but appears to have never made sense on RISC-V.
gcc/ChangeLog
The previous wording makes it sound like "do not emit" is a
clarification of "emit", which is not accurate. This cleans up the
wording to match (most) of the other arguments.
gcc/ChangeLog
* doc/invoke.texi (RISC-V -memit-attribute): Re-word the do/do
not language.
Hi!
On 2/7/22 5:05 PM, Segher Boessenkool wrote:
> Hi!
>
> On Mon, Feb 07, 2022 at 04:20:24PM -0600, Bill Schmidt wrote:
>> I observed recently that a couple of Power10 instructions and built-in
>> functions
>> were somehow not implemented. This patch adds one of them (vmsumcud).
>> Although
On 2/7/22 09:29, Andrew MacLeod wrote:
I have a proposal for PR 104288.
ALL patches (in sequence) bootstrap on their own and each cause no
regressions.
I've been continuing to work with this towards the GCC13 solution for
statement side effects. And There is another possibility we could
RISC-V has no support for subword atomic operations; code currently
generates libatomic library calls.
This patch changes the default behavior to inline subword atomic calls
(using the same logic as the existing library call).
Behavior can be specified using the -minline-atomics and
On Fri, 4 Feb 2022, Richard Biener via Gcc-patches wrote:
> This adds explicit variable birth CLOBBERs in an attempt to fix
> PR90348 and duplicates. The birth / death CLOBBER pairs are
> used to compute liveness and conflicts for stack variable
> coalescing where the lack of an explicit birth
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r12-7087-g0c04ac0e15830b.
gcc/analyzer/ChangeLog:
PR analyzer/104417
* sm-taint.cc (tainted_allocation_size::tainted_allocation_size):
Remove overzealous assertion.
PR analyzer/103872 reports a failure of gcc.dg/analyzer/pr103526.c on
riscv64-unknown-elf-gcc. The issue is that I wrote the test on x86_64
where a memcpy in the test is optimized to a write to a read/write pair,
whereas due to alignment differences the analyzer can see it as a
memcpy call,
Hi!
On Mon, Feb 07, 2022 at 04:20:24PM -0600, Bill Schmidt wrote:
> I observed recently that a couple of Power10 instructions and built-in
> functions
> were somehow not implemented. This patch adds one of them (vmsumcud).
> Although
> this isn't normally stage-4 material, this is really
Hi!
I observed recently that a couple of Power10 instructions and built-in functions
were somehow not implemented. This patch adds one of them (vmsumcud). Although
this isn't normally stage-4 material, this is really simple and carries no
discernible risk, so I hope it can be considered.
On 2/7/22 10:58, Palmer Dabbelt wrote:
On Mon, 07 Feb 2022 09:41:10 PST (-0800), Vineet Gupta wrote:
On 2/7/22 01:28, Philipp Tomsich wrote:
Vineet,
On Mon, 7 Feb 2022 at 07:06, Vineet Gupta wrote:
This is at par with other major arches such as aarch64, i386, s390 ...
No testsuite
Hi Paul,
thanks for attacking this.
I haven't looked at the actual patch, only tried to check the new
testcases with other compilers.
Am 03.02.22 um 18:14 schrieb Paul Richard Thomas via Fortran:
I have tried to interpret F2018 7.5.6.2 and 7.5.6.3 as well as possible.
This is not always
On Mon, 7 Feb 2022 at 21:01, Jonathan Wakely wrote:
>
>
> On Mon, 7 Feb 2022 at 20:12, Dimitar Dimitrov wrote:
>
>> On PRU target with newlib, we have the following combination in config.h:
>> /* #undef HAVE_DIRENT_H */
>> #define HAVE_FCNTL_H 1
>> #define HAVE_UNLINKAT 1
>>
>> In newlib,
On Mon, 7 Feb 2022 at 20:12, Dimitar Dimitrov wrote:
> On PRU target with newlib, we have the following combination in config.h:
> /* #undef HAVE_DIRENT_H */
> #define HAVE_FCNTL_H 1
> #define HAVE_UNLINKAT 1
>
> In newlib, targets which do not define dirent.h, get a build error when
>
On 2/7/22 09:57, Patrick Palka wrote:
Here constant evaluation of the atomic constraint use_func_v with T=int
sensibly yields an INTEGER_CST of type const bool, but the assert in
satisfaction_value expects unqualified bool. Let's just relax the
assert to accept cv-qualified bool more generally.
On 2/7/22 09:57, Patrick Palka wrote:
The fail-fast predicate uses_deducible_template_parms used by
unify_one_argument is neglecting to look inside the noexcept-spec of a
function type, and this causes deduction to fail for the below testcase
since the noexcept-spec is the only part of the type
On 2/7/22 12:34, Patrick Palka wrote:
On Thu, 3 Feb 2022, Jason Merrill wrote:
On 2/3/22 15:55, Patrick Palka wrote:
On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote:
On 2/3/22 12:04, Patrick Palka wrote:
On Wed, 2 Feb 2022, Jason Merrill wrote:
On 2/2/22 12:09, Patrick Palka wrote:
On PRU target with newlib, we have the following combination in config.h:
/* #undef HAVE_DIRENT_H */
#define HAVE_FCNTL_H 1
#define HAVE_UNLINKAT 1
In newlib, targets which do not define dirent.h, get a build error when
including :
On Sat, 05 Feb 2022 00:14:26 PST (-0800), gcc-patches@gcc.gnu.org wrote:
Thanks, LGTM :)
On Sat, Feb 5, 2022 at 7:56 AM Maciej W. Rozycki wrote:
We have recently updated the default for the `-misa-spec=' option, yet
we still have not documented it nor its `--with-isa-spec=' counterpart
in
On Mon, 07 Feb 2022 09:41:10 PST (-0800), Vineet Gupta wrote:
On 2/7/22 01:28, Philipp Tomsich wrote:
Vineet,
On Mon, 7 Feb 2022 at 07:06, Vineet Gupta wrote:
This is at par with other major arches such as aarch64, i386, s390 ...
No testsuite regressions: same numbers w/ w/o
Putting that
On 2/7/22 01:28, Philipp Tomsich wrote:
Vineet,
On Mon, 7 Feb 2022 at 07:06, Vineet Gupta wrote:
This is at par with other major arches such as aarch64, i386, s390 ...
No testsuite regressions: same numbers w/ w/o
Putting that check seems a good idea, but I haven't seen any cases
related
On Thu, 3 Feb 2022, Jason Merrill wrote:
> On 2/3/22 15:55, Patrick Palka wrote:
> > On Thu, Feb 3, 2022 at 3:20 PM Jason Merrill wrote:
> > >
> > > On 2/3/22 12:04, Patrick Palka wrote:
> > > > On Wed, 2 Feb 2022, Jason Merrill wrote:
> > > >
> > > > > On 2/2/22 12:09, Patrick Palka wrote:
>
Hi Maciej:
Thanks for doing this, OK to trunk.
On Tue, Feb 1, 2022 at 7:04 AM Maciej W. Rozycki wrote:
>
> Use `gcc-dg-runtest' test driver rather than `dg-runtest' to run the
> RISC-V testsuite as several targets already do. Adjust test options
> across individual test cases accordingly where
Ping.
thanks.
Qing
> On Jan 28, 2022, at 12:03 PM, Qing Zhao via Gcc-patches
> wrote:
>
> Hi,
>
> PR 100775 ( ICE: in df_exit_block_bitmap_verify, at df-scan.c:4164 with
> -mthumb -fzero-call-used-regs=used)
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100775
>
> Although the ICE only
Hi Segher,
Thanks for all the reviews for this series! I'd like to gently ping the last
two patches.
BR,
Bill
On 1/28/22 11:50 AM, Bill Schmidt via Gcc-patches wrote:
> As the subject states. Fixing this is accomplished by moving the built-ins
> to the correct stanzas, [altivec] and [vsx].
>
On Mon, Feb 7, 2022 at 8:20 AM Jakub Jelinek wrote:
>
> On Fri, Feb 04, 2022 at 12:00:57PM -0500, David Edelsohn via Gcc-patches
> wrote:
> > > The following testcase FAILs when configured with
> > > --with-long-double-format=ieee . Only happens in the -std=c* modes, not
> > > the
> > > GNU
The fail-fast predicate uses_deducible_template_parms used by
unify_one_argument is neglecting to look inside the noexcept-spec of a
function type, and this causes deduction to fail for the below testcase
since the noexcept-spec is the only part of the type which contains a
deducible template
Here constant evaluation of the atomic constraint use_func_v with T=int
sensibly yields an INTEGER_CST of type const bool, but the assert in
satisfaction_value expects unqualified bool. Let's just relax the
assert to accept cv-qualified bool more generally.
Bootstrapped and regtested on
The patches resolves the issue for GCC11 in a much simpler way.
By default, ranger and EVRP are running in hybrid mode. This means if
ranger misses something, evrp will pick up the slack. This enables us to
change the 2 places which check for non-null to ignore potentially
incorrect
This changes the non-null interface to provide more granularity and
facilitate more precise queries.
Previously, we could only ask if NAME was nonnull anywhere in the block,
and it applied to the entire block. now we can ask:
bool always_nonnull_p (tree name, basic_block bb); // all uses
This patch adds the ability to register side effects within a block to
ranger. This is currently only for tracking non-null values.
the rvrp_folder performs a DOM walk and then attempts to simplify and
the fold each stmt during the walk. This patch adds a call to
register_side_effects() to
This patch changes the non-null tracking in ranger to use 2 bits in order
to distinguish between blocks which contain uses of NAME in:
1) non-null generating statements, (1 bit)
2) statements which are not non-null generating (the other bit),
THis is the new bit.
3) and the existence of
I have a proposal for PR 104288.
This PR highlights the shortcomings of assuming that when the non-null
property is seen within a block, that it applies to the entire block.
This is a 3 patch set, but is less dramatic than it sounds. I just
wanted to split it into small bits for safety and
On Fri, Feb 04, 2022 at 12:00:57PM -0500, David Edelsohn via Gcc-patches wrote:
> > The following testcase FAILs when configured with
> > --with-long-double-format=ieee . Only happens in the -std=c* modes, not the
> > GNU modes; while the glibc headers have __asm redirects of
> > vsnprintf and
On Mon, Feb 07, 2022 at 05:31:58PM +0530, Siddhesh Poyarekar wrote:
> Use __builtin_dynamic_object_size to get object sizes for ubsan.
>
> gcc/ChangeLog:
>
> middle-end/70090
> * ubsan.cc (ubsan_expand_objsize_ifn): Allow non-constant SIZE.
> (instrument_object_size): Get
Use __builtin_dynamic_object_size to get object sizes for ubsan.
gcc/ChangeLog:
middle-end/70090
* ubsan.cc (ubsan_expand_objsize_ifn): Allow non-constant SIZE.
(instrument_object_size): Get dynamic object size expression.
gcc/testsuite/ChangeLog:
On 2/7/22 09:11, Jakub Jelinek wrote:
...
> 1) formatting, = should be at the start of next line rather than end of the
>line
> 2) all_masks, always_inline_safe_masks and caller_required_masks aren't
>ever modified, perhaps make them const?
> 3) I wonder if there is any advantage to have
This makes sure we always have a _Complex compare split to a
different stmt for the compare operand in a COND_EXPR on GIMPLE.
Complex lowering doesn't handle this and the change is something
we want for all kind of compares at some point.
Bootstrapped and tested on x86_64-unknown-linux-gnu,
Hi Segher,
Thanks for the comments!
on 2022/2/7 下午3:53, Segher Boessenkool wrote:
> Hi!
>
> On Wed, Jan 05, 2022 at 03:34:41PM +0800, Kewen.Lin wrote:
>> This patch is to fix the inconsistent behaviors for non-LTO mode
>> and LTO mode. As Martin pointed out, currently the function
>>
Vineet,
On Mon, 7 Feb 2022 at 07:06, Vineet Gupta wrote:
>
> This is at par with other major arches such as aarch64, i386, s390 ...
>
> No testsuite regressions: same numbers w/ w/o
Putting that check seems a good idea, but I haven't seen any cases
related to this get through anyway.
Do you
There is the following code in aarch64_layout_frame:
else if (crtl->outgoing_args_size.is_constant (_outgoing_args_size)
&& frame.saved_regs_size.is_constant (_saved_regs_size)
&& const_outgoing_args_size + const_saved_regs_size < 512
&& (!saves_below_hard_fp_p ||
On Mon, Feb 07, 2022 at 01:54:00PM +0800, Kewen.Lin wrote:
> on 2022/1/28 上午1:17, Segher Boessenkool wrote:
> > On Thu, Jan 27, 2022 at 07:21:33PM +0800, Kewen.Lin wrote:
> >>PR target/103627
> >>* config/rs6000/rs6000.cc (rs6000_option_override_internal): Disable
> >>MMA if
On Mon, Feb 07, 2022 at 08:09:47AM +0100, Andreas Krebbel via Gcc-patches wrote:
> MASK_MVCLE is set for -Os but not for other optimization levels. In
> general it should not make much sense to inline across calls where the
> flag is different but we have to allow it for always_inline.
>
> The
45 matches
Mail list logo
