On 2/11/22 07:35, Richard Sandiford wrote:
Dan Li writes:
On 2/11/22 01:53, Richard Sandiford wrote:
Dan Li writes:
On 2/10/22 01:55, Richard Sandiford wrote:
void f();
int g(int x) {
if (x == 0) {
__asm__ ("":::"x19", "x20");
return 1;
}
f();
On Fri, 25 Feb 2022, Qing Zhao wrote:
> Hi, Jakub and Richard:
>
> This is the 3rd version of the patch, the major change compared to the
> previous version are:
>
> 1. Add warning_enabled_at guard before “suppress_warning”
> 2. Add location to the call to __builtin_clear_padding for auto init.
Hi,
This patch intends to sync with llvm change in
https://reviews.llvm.org/D120307 to add enumeration and truncate
imm to unsigned char, so users could use ~ on immediates.
Bootstraped/regtested on x86_64-pc-linux-gnu{-m32,}.
Ok for master?
gcc/ChangeLog:
* config/i386/avx512fintrin.h
On Fri, 25 Feb 2022, Jiufu Guo wrote:
> Richard Biener writes:
>
> > On Thu, 24 Feb 2022, Jiufu Guo wrote:
> >
> >> Jiufu Guo via Gcc-patches writes:
> >>
> >> > Segher Boessenkool writes:
> >> >
> >> >> On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Biener wrote:
> >> >>> I'm assuming we'
On Fri, Feb 25, 2022 at 08:11:40AM +0100, Richard Biener via Gcc-patches wrote:
> On Thu, 24 Feb 2022, Qing Zhao wrote:
>
> > I briefly checked all the usages of suppress_warning within the current
> > gcc,
> > and see that most of them are not guarded by any condition.
> >
> > So, the current
On Fri, 25 Feb 2022, Jakub Jelinek wrote:
> On Fri, Feb 25, 2022 at 08:11:40AM +0100, Richard Biener via Gcc-patches
> wrote:
> > On Thu, 24 Feb 2022, Qing Zhao wrote:
> >
> > > I briefly checked all the usages of suppress_warning within the current
> > > gcc,
> > > and see that most of them a
On Fri, Feb 25, 2022 at 10:13:33AM +0100, Richard Biener via Gcc-patches wrote:
> I meant
>
> /* Set the no_warning flag of STMT to NO_WARNING. */
>
> static inline void
> gimple_set_no_warning (gimple *stmt, bool no_warning)
> {
> stmt->no_warning = (unsigned) no_warning;
> }
>
> on the arti
Hi!
We don't support BIT_{AND,IOR,XOR,NOT}_EXPR on complex types,
&/|/^ are just rejected for them, and ~ is parsed as CONJ_EXPR.
So, we should avoid simplifications which turn valid complex type
expressions into something that will ICE during expansion.
Bootstrapped/regtested on x86_64-linux and
On Fri, 25 Feb 2022, Jakub Jelinek wrote:
> On Fri, Feb 25, 2022 at 10:13:33AM +0100, Richard Biener via Gcc-patches
> wrote:
> > I meant
> >
> > /* Set the no_warning flag of STMT to NO_WARNING. */
> >
> > static inline void
> > gimple_set_no_warning (gimple *stmt, bool no_warning)
> > {
> >
On Fri, 25 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> We don't support BIT_{AND,IOR,XOR,NOT}_EXPR on complex types,
> &/|/^ are just rejected for them, and ~ is parsed as CONJ_EXPR.
> So, we should avoid simplifications which turn valid complex type
> expressions into something that will ICE during
Hi!
As mentioned in the PR, the following testcase is miscompiled for similar
reasons as the already fixed PR78791 - we use SLOT_TEMP slots in various
places during expansion and during expansion we can guarantee that the
lifetime of those temporary slot doesn't overlap. But the following
splitte
Hi!
The following testcase is miscompiled on ia32 at -O2, because
when expand_SPACESHIP is called, we have pending stack adjustment
from the foo call right before it.
Now, ix86_expand_fp_spaceship uses emit_jump_insn several times
but then emit_jump also several times. While emit_jump_insn doesn'
On Fri, 25 Feb 2022, Jakub Jelinek wrote:
> Hi!
>
> The following testcase is miscompiled on ia32 at -O2, because
> when expand_SPACESHIP is called, we have pending stack adjustment
> from the foo call right before it.
> Now, ix86_expand_fp_spaceship uses emit_jump_insn several times
> but then e
Hi!
This fixes a spelling mistake I found while looking at warning-control
implementation.
Committed as obvious.
2022-02-25 Jakub Jelinek
* warning-control.cc (get_nowarn_spec): Comment spelling fix.
--- gcc/warning-control.cc.jj 2022-01-17 18:05:04.861306618 +0100
+++ gcc/warning
On Fri, Feb 25, 2022 at 10:31:50AM +0100, Richard Biener wrote:
> I think it's used as fallback for UNKNOWN_LOCATION, but if we "invent"
> a creative location for the artificial stmt it will of course
> affect other stmts/expressions using that location.
>
> > I think it will work.
>
> Yes, I thi
On Fri, 25 Feb 2022, Jakub Jelinek wrote:
> On Fri, Feb 25, 2022 at 10:31:50AM +0100, Richard Biener wrote:
> > I think it's used as fallback for UNKNOWN_LOCATION, but if we "invent"
> > a creative location for the artificial stmt it will of course
> > affect other stmts/expressions using that loc
On Fri, Feb 25, 2022 at 11:12:13AM +0100, Richard Biener wrote:
> On Fri, 25 Feb 2022, Jakub Jelinek wrote:
>
> > On Fri, Feb 25, 2022 at 10:31:50AM +0100, Richard Biener wrote:
> > > I think it's used as fallback for UNKNOWN_LOCATION, but if we "invent"
> > > a creative location for the artificia
On Fri, Feb 25, 2022 at 10:33 AM Jakub Jelinek wrote:
>
> Hi!
>
> As mentioned in the PR, the following testcase is miscompiled for similar
> reasons as the already fixed PR78791 - we use SLOT_TEMP slots in various
> places during expansion and during expansion we can guarantee that the
> lifetime
This fixes a long-standing issue in PRE where we track valueized
expressions in our expression sets that we use for PHI translation,
code insertion but also feed into match-and-simplify via
vn_nary_simplify. But that's not what is expected from vn_nary_simplify
or match-and-simplify which assume w
Hi,
the IF_THEN_ELSE detection currently prevents us from properly costing
register-register moves which causes the lower-subreg pass to assume
that a VR-VR move is as expensive as two GPR-GPR moves.
This patch adds handling for SETs containing REGs as well as MEMs and is
inspired by the aarch64
On Fri, 25 Feb 2022, Richard Biener wrote:
> This fixes a long-standing issue in PRE where we track valueized
> expressions in our expression sets that we use for PHI translation,
> code insertion but also feed into match-and-simplify via
> vn_nary_simplify. But that's not what is expected from v
On Thu, 24 Feb 2022, Qing Zhao wrote:
>
>
> > On Feb 24, 2022, at 4:16 AM, Richard Biener wrote:
> >
> > On Sat, 19 Feb 2022, Qing Zhao wrote:
> >
> >> Hi,
> >>
> >> This is the 2nd patch for fixing pr102276.
> >>
> >> Adding -Wtrivial-auto-var-init and update documentation.
> >>
> >> Addi
If the movcc comparison is not valid it triggers an assert in the
current implementation. This behavior is not needed as we can FAIL
the movcc expand pattern.
gcc/
* config/arc/arc.cc (gen_compare_reg): Return NULL_RTX if the
comparison is not valid.
* config/arc/arc.md (m
> If the movcc comparison is not valid it triggers an assert in the
> current implementation. This behavior is not needed as we can FAIL
> the movcc expand pattern.
In case of a MODE_CC comparison you can also just return it as described
here https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104154
o
Richard Biener writes:
> On Fri, 25 Feb 2022, Jiufu Guo wrote:
>
>> Richard Biener writes:
>>
>> > On Thu, 24 Feb 2022, Jiufu Guo wrote:
>> >
>> >> Jiufu Guo via Gcc-patches writes:
>> >>
>> >> > Segher Boessenkool writes:
>> >> >
>> >> >> On Wed, Feb 23, 2022 at 02:02:59PM +0100, Richard Bi
On Fri, 25 Feb 2022, Jiufu Guo wrote:
> Richard Biener writes:
>
> > On Fri, 25 Feb 2022, Jiufu Guo wrote:
> >
> >> Richard Biener writes:
> >>
> >> > On Thu, 24 Feb 2022, Jiufu Guo wrote:
> >> >
> >> >> Jiufu Guo via Gcc-patches writes:
> >> >>
> >> >> > Segher Boessenkool writes:
> >> >>
Installed as obvious.
Martin
PR testsuite/104687
gcc/testsuite/ChangeLog:
* gcc.dg/lto/20090717_0.c: Fix asan error.
---
gcc/testsuite/gcc.dg/lto/20090717_0.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/testsuite/gcc.dg/lto/20090717_0.c
b/gcc/tests
The following replaces
/* Skip bits that are zero. */
for (; (word & 1) == 0; word >>= 1)
bit_num++;
idioms in ira-int.h in the attempt to speedup update_conflict_hard_regno_costs
which we're bound on in PR104686. The trick is to use ctz_hwi here
which should pay off even
> On Feb 25, 2022, at 2:38 AM, Richard Biener wrote:
>
> On Fri, 25 Feb 2022, Qing Zhao wrote:
>
>> Hi, Jakub and Richard:
>>
>> This is the 3rd version of the patch, the major change compared to the
>> previous version are:
>>
>> 1. Add warning_enabled_at guard before “suppress_warning”
>>
> On Feb 25, 2022, at 6:43 AM, Richard Biener wrote:
>
> On Thu, 24 Feb 2022, Qing Zhao wrote:
>
>>
>>
>>> On Feb 24, 2022, at 4:16 AM, Richard Biener wrote:
>>>
>>> On Sat, 19 Feb 2022, Qing Zhao wrote:
>>>
Hi,
This is the 2nd patch for fixing pr102276.
Adding
On 2022-02-25 09:14, Richard Biener wrote:
The following replaces
/* Skip bits that are zero. */
for (; (word & 1) == 0; word >>= 1)
bit_num++;
idioms in ira-int.h in the attempt to speedup update_conflict_hard_regno_costs
which we're bound on in PR104686. The tric
On 2/25/22 12:38, Robin Dapp wrote:
> Hi,
>
> the IF_THEN_ELSE detection currently prevents us from properly costing
> register-register moves which causes the lower-subreg pass to assume
> that a VR-VR move is as expensive as two GPR-GPR moves.
>
> This patch adds handling for SETs containing RE
On Wed, Feb 23, 2022 at 07:45:20PM -0300, Alexandre Oliva via Gcc-patches wrote:
> PR middle-end/104540
> * g++.dg/PR104540.C: New.
Both -mforce-drap and -mstackrealign options are x86 specific.
Tested on x86_64-linux, i686-linux and powerpc64le-linux, committed to
trunk.
2022-02-25
Hi!
Mark mentioned in the PR further 2 simplifications that also ICE
with complex types.
For these, eventually (but IMO GCC 13 materials) we could support it
for vector types if it would be uniform vector constants.
Currently integer_pow2p is true only for INTEGER_CSTs and COMPLEX_CSTs
and we can'
Hi!
The following testcase ICEs, because for some strange reason it decides to use
movmisaligntf during expansion where the destination is MEM and source is
CONST_DOUBLE. For normal mov expanders the rs6000 backend uses
rs6000_emit_move to ensure that if one operand is a MEM, the other is a REG
a
> Am 25.02.2022 um 18:58 schrieb Jakub Jelinek via Gcc-patches
> :
>
> Hi!
>
> Mark mentioned in the PR further 2 simplifications that also ICE
> with complex types.
> For these, eventually (but IMO GCC 13 materials) we could support it
> for vector types if it would be uniform vector consta
Hi,
After more study of all the discussion so far and the corresponding code for
suppress_warning, I think the following suggestion
Should be the best approach right now for this issue:
> SET_EXPR_LOCATION (tmp_dst, UNKNOWN_LOCATION);
> suppress_warning (tmp_dst, OPT_Wuninitialized)
When processing a template, the enumerators we build don't have a type
yet. But is_late_template_attribute is not prepared to see a _DECL
without a type, so we crash on
enum tree_code code = TREE_CODE (type);
(I found that we don't give the "is deprecated" warning for the enumerator
'f' in the
[ Most likely a GCC 13 patch, but I'm posting it now so that I don't lose it. ]
When looking into the other PR I noticed that we fail to give a warning
for a deprecated enumerator when the enum is in a class template. This
only happens when the attribute doesn't have an argument. The reason is
t
Hi,
This is the 4th version based on the discussion so far.
The major change is:
> SET_EXPR_LOCATION (tmp_dst, UNKNOWN_LOCATION);
> suppress_warning (tmp_dst, OPT_Wuninitialized);
> with a comment explaing why we do that.
The patch has been bootstrapped and regress tested on both x86 an
40 matches
Mail list logo
