> Am 05.04.2024 um 21:59 schrieb Jørgen Kvalsvik :
>
> Hi,
>
> I propose these fixes for the current issues with the condition
> coverage.
>
> Rainer, I propose to simply delete the test with __sigsetjmp. I don't
> think it actually detects anything reasonable any more, I kept it around
> to
Hi Jerry, hello world,
Jerry D wrote:
On 4/5/24 10:47 AM, Jerry D wrote:
On 4/4/24 2:41 PM, Tobias Burnus wrote:
I think for the current testcases, I like the patch – the question
is only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
[...]
But for 'comma': [...]
On 3/27/24 4:55 AM, Philipp Tomsich wrote:
Jeff,
just a heads-up that that trunk (i.e., the soon-to-be GCC14) still
generates the suboptimal sequence:
https://godbolt.org/z/K9YYEPsvY
Realistically it's too late to get this into gcc-14.
Jeff
On 4/5/24 10:47 AM, Jerry D wrote:
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For 'point' – 0.3 is read and ios = 0 (as expected)
But
This is a cleanup patch in preparation to fixing the real bug in PR101865.
TARGET_DIRECT_MOVE is redundant with TARGET_P8_VECTOR, so alias it to that.
Also replace all usages of OPTION_MASK_DIRECT_MOVE with OPTION_MASK_P8_VECTOR
and delete the now dead mask.
This passed bootstrap and retesting on
On Fri, Apr 05, 2024 at 03:46:30PM -0600, Jeff Law wrote:
>
>
> On 4/5/24 3:27 PM, Segher Boessenkool wrote:
> > Hi!
> >
> > On Wed, Apr 03, 2024 at 01:07:41PM +0200, Richard Biener wrote:
> > > The following avoids re-walking and re-combining the instructions
> > > between i2 and i3 when the pa
On 4/5/24 3:27 PM, Segher Boessenkool wrote:
Hi!
On Wed, Apr 03, 2024 at 01:07:41PM +0200, Richard Biener wrote:
The following avoids re-walking and re-combining the instructions
between i2 and i3 when the pattern of i2 doesn't change.
Bootstrap and regtest running ontop of a reversal of
r1
Hi!
On Wed, Apr 03, 2024 at 01:07:41PM +0200, Richard Biener wrote:
> The following avoids re-walking and re-combining the instructions
> between i2 and i3 when the pattern of i2 doesn't change.
>
> Bootstrap and regtest running ontop of a reversal of
> r14-9692-g839bc42772ba7a.
Please include
The __sigsetjmp test was added as a regression test, which an early
iteration of the MC/DC support caused an internal compiler error,
triggered by a code path which did not make it through to the final
revision. Since this test really only worked on linux and does not
serve a purpose any more it c
When a function is tree-inlined, copy the condition -> expression mapping
from the inlined function into the caller, shifted so uids are not mixed
Tree inlining was always problematic under condition coverage - either
through a nullptr dereference (like in the test case), or through
quietly mixing
Hi,
I propose these fixes for the current issues with the condition
coverage.
Rainer, I propose to simply delete the test with __sigsetjmp. I don't
think it actually detects anything reasonable any more, I kept it around
to prevent a regression. Since then I have built a lot of programs (with
opt
> + /* When there's a call that might not return the last iteration
> + is possibly partial. This matches what we check in invariant
> + motion.
> + ??? For the call argument evaluation it would be still OK. */
> + if (!may_have_exited
> + && is_g
Successfully bootstrapped & regrtested on x86_64-pc-linux-gnu.
Pushed to trunk as r14-9817-g4b02dd48f531ea.
gcc/analyzer/ChangeLog:
PR analyzer/114588
* access-diagram.cc (access_diagram_impl::access_diagram_impl):
Replace hardcoded colors for valid_style and invalid_style
On Fri, Apr 05, 2024 at 09:40:48AM +0200, Jakub Jelinek wrote:
> Hi!
>
> When looking at maybe_warn_for_constant_evaluated for the trivial
> infinite loops patch, I've noticed that it can emit weird diagnostics
> for if constexpr in templates, first warn that std::is_constant_evaluted()
> always e
On Fri, Apr 05, 2024 at 08:28:08PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 05, 2024 at 02:22:18PM -0400, Marek Polacek wrote:
> > Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
> >
> > -- >8 --
> > -Whardened warns when -fhardened couldn't enable a hardening option
> > because that
On Fri, Apr 05, 2024 at 02:22:18PM -0400, Marek Polacek wrote:
> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
>
> -- >8 --
> -Whardened warns when -fhardened couldn't enable a hardening option
> because that option was disabled on the command line, e.g.:
>
> $ ./cc1plus -quiet g.C
Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk?
-- >8 --
-Whardened warns when -fhardened couldn't enable a hardening option
because that option was disabled on the command line, e.g.:
$ ./cc1plus -quiet g.C -fhardened -O2 -fstack-protector
cc1plus: warning: '-fstack-protector-strong
On Fri, Apr 5, 2024 at 5:28 AM Manolis Tsamis wrote:
>
> If we consider code like:
>
> if (bar1 == x)
> return foo();
> if (bar2 != y)
> return foo();
> return 0;
>
> We would like the ifcombine pass to convert this to:
>
> if (bar1 == x || bar2 != y)
> return foo
tested on aarch64-apple-darwin21, pushed to trunk, thanks.
Iain
--- 8< ---
When we have '-O3 -g' we emit a bunch of LB{B,E} local labels which
were not currently being discarded, leading to some test fails.
Fixed by adding this case to the ignored labels.
gcc/testsuite/ChangeLog:
* lib
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For 'point' – 0.3 is read and ios = 0 (as expected)
But for 'comma':
* GCC 12 reads nothing
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
Fixed by r12-2975.
PR c++/91079
DR 1881
gcc/testsuite/ChangeLog:
* g++.dg/ext/is_std_layout5.C: New test.
---
gcc/testsuite/g++.dg/ext/is_std_layout5.C | 13 +
1 file changed, 13 insertions(+)
create m
I spotted this whitespace error during the review of
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/648846.html.
Pushing as obvious after testing on aarch64-linux-gnu.
Thanks,
Alex
gcc/ChangeLog:
* config/aarch64/aarch64-ldp-fusion.cc (struct alias_walker):
Fix double spac
On 05/04/2024 13:53, Ajit Agarwal wrote:
> Hello Alex/Richard:
>
> All review comments are incorporated.
Thanks, I was kind-of expecting you to also send the renaming patch as a
preparatory patch as we discussed.
Sorry for another meta comment, but: I think the reason that the Linaro
CI isn't ru
On 05/04/2024 16:05, H.J. Lu wrote:
On Fri, Apr 5, 2024 at 6:52 AM Richard Biener wrote:
Am 05.04.2024 um 15:46 schrieb H.J. Lu :
On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
There's no default bitmap obstack during global CTORs, so allocate the
bitmap locally.
Bootstrap and r
Don't use implicit shift count in double-precision shifts in AT&T syntax
since they aren't in Intel SDM. Keep the 's' modifier for backward
compatibility with inline asm statements.
PR target/114590
* config/i386/i386.md (x86_64_shld): Use explicit shift count in
AT&T synt
The new support for gcov modified condition/decision coverage
introduced two new flags for gcc, -Wcoverage-too-many-conditions and
-fcondition-coverage. But didn't regenerate the gcc/common.opt.urls.
Fixes: 08a52331803f ("Add condition coverage (MC/DC)")
gcc/ChangeLog:
* common.opt.urls:
On 4/4/24 6:41 AM, Richard Biener wrote:
The following speeds up stack variable conflict detection by recognizing
that the all-to-all conflict recording is only necessary for CFG merges
as it's the unioning of the live variable sets that doesn't come with
explicit mentions we record conflicts
On 05/04/2024 16:05, H.J. Lu wrote:
On Fri, Apr 5, 2024 at 6:52 AM Richard Biener wrote:
Am 05.04.2024 um 15:46 schrieb H.J. Lu :
On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
There's no default bitmap obstack during global CTORs, so allocate the
bitmap locally.
Bootstrap and r
On Fri, Apr 5, 2024 at 6:52 AM Richard Biener wrote:
>
>
>
> > Am 05.04.2024 um 15:46 schrieb H.J. Lu :
> >
> > On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
> >>
> >> There's no default bitmap obstack during global CTORs, so allocate the
> >> bitmap locally.
> >>
> >> Bootstrap and regte
On Thu, Apr 4, 2024 at 5:54 AM Jørgen Kvalsvik wrote:
>
> On 04/04/2024 14:10, Jan Hubicka wrote:
> >> gcc/ChangeLog:
> >>
> >> * builtins.cc (expand_builtin_fork_or_exec): Check
> >>condition_coverage_flag.
> >> * collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
> >>
> Am 05.04.2024 um 15:46 schrieb H.J. Lu :
>
> On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
>>
>> There's no default bitmap obstack during global CTORs, so allocate the
>> bitmap locally.
>>
>> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>>
>> Richard.
>>
>>
aarch64-sve.md had a pattern that combined:
cmpeq pb.T, pa/z, zc.T, #0
mov zd.T, pb/z, #1
into:
cnotzd.T, pa/m, zc.T
But this is only valid if pa.T is a ptrue. In other cases, the
original would set inactive elements of zd.T to 0, whereas the
combined form wou
On Fri, Apr 5, 2024 at 1:21 AM Richard Biener wrote:
>
> There's no default bitmap obstack during global CTORs, so allocate the
> bitmap locally.
>
> Bootstrap and regtest running on x86_64-unknown-linux-gnu.
>
> Richard.
>
> PR middle-end/114599
> * symtab.cc (ifunc_ref_map): Do n
On Fri, 5 Apr 2024, Richard Biener wrote:
> The following makes sure to only compute upper bounds for the number
> of iterations of loops from undefined behavior invoked by stmts when
> those are executed in each loop iteration, in particular also in the
> last one. The latter cannot be guarantee
On 05/04/2024 15:00, Rainer Orth wrote:
Hi Jørgen,
On 04/04/2024 14:10, Jan Hubicka wrote:
gcc/ChangeLog:
* builtins.cc (expand_builtin_fork_or_exec): Check
condition_coverage_flag.
* collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
* common.opt: A
On Fri, Apr 5, 2024 at 3:43 PM Richard Biener
wrote:
>
> On Fri, Apr 5, 2024 at 2:28 PM Manolis Tsamis wrote:
> >
> > If we consider code like:
> >
> > if (bar1 == x)
> > return foo();
> > if (bar2 != y)
> > return foo();
> > return 0;
> >
> > We would like the ifcombine p
The following makes sure to only compute upper bounds for the number
of iterations of loops from undefined behavior invoked by stmts when
those are executed in each loop iteration, in particular also in the
last one. The latter cannot be guaranteed if there's possible
infinite loops or calls with
The following adds another get_loop_body variant, one to get blocks
in RPO.
Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.
* cfgloop.h (get_loop_body_in_rpo): Declare.
* cfgloop.cc (get_loop_body_in_rpo): Compute loop body in RPO.
---
gcc/cfgloop.cc | 68 +
The following passes down whether a stmt is always executed from
infer_loop_bounds_from_undefined to infer_loop_bounds_from_array.
The parameters were already documented. The patch doesn't remove
possibly redundant checks from idx_infer_loop_bounds yet.
Boostrapped on x86_64-unknown-linux-gnu, te
Tested x86_64-pc-linux-gnu, applying to trunk.
-- >8 --
The #undef was added in r0-90320-g100d537d7a7b5c but it never did
anything.
gcc/c-family/ChangeLog:
* c-warn.cc (warn_about_parentheses): Remove an #undef.
---
gcc/c-family/c-warn.cc | 1 -
1 file changed, 1 deletion(-)
diff --git
Hi Jørgen,
> On 04/04/2024 14:10, Jan Hubicka wrote:
>>> gcc/ChangeLog:
>>>
>>> * builtins.cc (expand_builtin_fork_or_exec): Check
>>> condition_coverage_flag.
>>> * collect2.cc (main): Add -fno-condition-coverage to OBSTACK.
>>> * common.opt: Add new options -fcondition-coverage
> Hi,
>
> interactions of IPA-CP and IPA-SRA on the same data is a rather big
> source of issues, I'm afraid. PR 113964 is a situation where IPA-CP
> propagates an unsigned short in a union parameter into a function
> which itself calls a different function which has a same union
> parameter and
Hi,
interactions of IPA-CP and IPA-SRA on the same data is a rather big
source of issues, I'm afraid. PR 113964 is a situation where IPA-CP
propagates an unsigned short in a union parameter into a function
which itself calls a different function which has a same union
parameter and both these uni
On Fri, Apr 5, 2024 at 2:28 PM Manolis Tsamis wrote:
>
> If we consider code like:
>
> if (bar1 == x)
> return foo();
> if (bar2 != y)
> return foo();
> return 0;
>
> We would like the ifcombine pass to convert this to:
>
> if (bar1 == x || bar2 != y)
> return foo
If we consider code like:
if (bar1 == x)
return foo();
if (bar2 != y)
return foo();
return 0;
We would like the ifcombine pass to convert this to:
if (bar1 == x || bar2 != y)
return foo();
return 0;
The ifcombine pass can handle this transformation but it i
Hi!
On 2024-04-03T14:06:45+0200, Tobias Burnus wrote:
> Nvptx's mkoffload.cc contains 14 'fatal_error' calls and one 'warning_at'
> call,
> which stands out more clearly (color, bold) when enabling
>diagnostic_color_init
> which this patch does. — Additionally, the call gcc_init_libintl perm
Hello,
On Tue, Apr 2, 2024 at 8:26 PM Richard Sandiford
wrote:
> I don't know if you're waiting on me, but just in case: this and patch 3
> still LGTM if Thomas is OK with them.
Thanks. Thomas asked me to resubmit with Changelog entries added (but
hasn't pointed out anything else), so this is wa
On Fri, 5 Apr 2024, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled, because in the vectorized
> epilogue the vectorizer assumes it can use aligned loads/stores
> (if the base decl gets alignment increased), but it actually doesn't
> increase that.
> This is because r10-4203-
Christophe Lyon writes:
> m2 has a m2.dvi build rule, but lacks the m2.install-dvi one.
>
> 2024-04-04 Christophe Lyon
>
> gcc/m2/
> * Make-lang.in (m2.install-dvi): New rule.
> ---
> gcc/m2/Make-lang.in | 12
> 1 file changed, 12 insertions(+)
>
> diff --git a/gcc/m2
Hi!
On Tue, Mar 26, 2024 at 11:55:41AM +, Wilco Dijkstra wrote:
> * acinclude.m4: Remove ARCH_AARCH64_HAVE_LSE128.
> * configure: Regenerated.
Seems configure hasn't been regenerated properly after the last
acinclude.m4 change as e.g. noticed by the autoregen CI.
I've committ
Hi!
The following testcase is miscompiled, because in the vectorized
epilogue the vectorizer assumes it can use aligned loads/stores
(if the base decl gets alignment increased), but it actually doesn't
increase that.
This is because r10-4203-g97c1460367 added the hunk following
patch removes. The
On Fri, 5 Apr 2024, Jakub Jelinek wrote:
> On Fri, Feb 23, 2024 at 12:18:00PM +0100, Jørgen Kvalsvik wrote:
> > This is a mostly straight port from the gcov-19.c tests from the C test
> > suite. The only notable differences from C to D are that D flips the
> > true/false outcomes for loop headers,
Hello Alex:
On 03/04/24 8:51 pm, Alex Coplan wrote:
> On 23/02/2024 16:41, Ajit Agarwal wrote:
>> Hello Richard/Alex/Segher:
>
> Hi Ajit,
>
> Sorry for the delay and thanks for working on this.
>
> Generally this looks like the right sort of approach (IMO) but I've left
> some comments below.
>
On Fri, Feb 23, 2024 at 12:18:00PM +0100, Jørgen Kvalsvik wrote:
> This is a mostly straight port from the gcov-19.c tests from the C test
> suite. The only notable differences from C to D are that D flips the
> true/false outcomes for loop headers, and the D front end ties loop and
> ternary condi
Hello Alex/Richard:
All review comments are incorporated.
Common infrastructure of load store pair fusion is divided into target
independent and target dependent changed code.
Target independent code is the Generic code with pure virtual function
to interface betwwen target independent and depen
There's no default bitmap obstack during global CTORs, so allocate the
bitmap locally.
Bootstrap and regtest running on x86_64-unknown-linux-gnu.
Richard.
PR middle-end/114599
* symtab.cc (ifunc_ref_map): Do not use auto_bitmap.
(is_caller_ifunc_resolver): Optimize bitmap
Hi!
Here is a new version of the PR114462 P2809R3 patch.
As clarified on core, for trivially empty iteration statements
(where the condition isn't empty or INTEGER_CST, because those
loops can't contain std::is_constant_evaluated() in the condition
and the middle-end handles them right even with -
Hi!
When looking at maybe_warn_for_constant_evaluated for the trivial
infinite loops patch, I've noticed that it can emit weird diagnostics
for if constexpr in templates, first warn that std::is_constant_evaluted()
always evaluates to false (because the function template is not constexpr)
and then
Hi!
While ctors/dtors don't return anything (undeclared void or this pointer
on arm) and copy assignment operators normally return a reference to *this,
it isn't invalid to return uselessly some class object which might need
destructing, but the OpenMP clause handling code wasn't expecting that.
On Thu, 4 Apr 2024, Tamar Christina wrote:
> Hi All,
>
> The report shows that we end up in a situation where the code has been peeled
> for gaps and we have an early break.
>
> The code for peeling for gaps assume that a scalar loop needs to perform at
> least one iteration. However this doesn
On 5 April 2024 03:03:05 CEST, "H.J. Lu" wrote:
>On Thu, Apr 4, 2024 at 5:34 PM wrote:
>>
>> On 3 April 2024 15:49:13 CEST, "H.J. Lu" wrote:
>
>> + /* Skip if it has been visited. */
>> + unsigned int uid = e->caller->get_uid ();
>> + if (bitmap_bit_p (ifunc_ref_map, uid))
>> +
61 matches
Mail list logo
