[Bug rtl-optimization/116053] [14/15 Regression] during RTL pass: cprop_hardreg ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -O1 -finstrument-functions -fno-forward

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116053

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #2 from Andrew Pinski  ---
Note I think a bisect here will just show where this latent bug shows up (GCC
13 register allocator gets it diffenent and uses the sp register as the
address).

I think after the call to df_analyze (that is in the loop) in
pass_cprop_hardreg::execute we need to call purge_all_dead_edges.

Or in df_analyze needs to call purge_dead_edge on the bb if it deletes an
instruction with a REG_EH_REGION note on it.

Note I do think we have a missed optimization at the gimple level. if the first
argument to memset/memcpy is an ADDR_EXPR, we change the assignment.

That is:
  x = *(__int128 *) __builtin_memset (, 0, 10);
Should be done as:
__builtin_memset (, 0, 10)
  x = *(__int128 *) 

And then this will be optimized away earlier.
Note this is a very much an artificial testcase and I highly doubt this will
show up normally because -fnon-call-exceptions is not used that much and even
less if fno-dead-exceptions.

[Bug rtl-optimization/116053] [14/15 Regression] during RTL pass: cprop_hardreg ICE: verify_flow_info failed: missing REG_EH_REGION note at the end of bb 2 with -O1 -finstrument-functions -fno-forward

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116053

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.


(insn 59 17 61 2 (set (reg:DI 1 dx [ _7+8 ])
(mem:DI (plus:DI (reg/f:DI 0 ax [108])
(const_int 8 [0x8])) [1 MEM[(__int128 *)_1]+8 S8 A64]))
"/app/example.cpp":5:7 discrim 1 88 {*movdi_internal}
 (expr_list:REG_UNUSED (reg:DI 1 dx [ _7+8 ])
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil
(note 61 59 60 3 [bb 3] NOTE_INSN_BASIC_BLOCK)
(insn 60 61 53 3 (set (reg:DI 0 ax [orig:100 _7 ] [100])
(mem:DI (reg/f:DI 0 ax [108]) [1 MEM[(__int128 *)_1]+0 S8 A128]))
"/app/example.cpp":5:7 discrim 1 88 {*movdi_internal}
 (expr_list:REG_UNUSED (reg:DI 0 ax [orig:100 _7 ] [100])
(expr_list:REG_EH_REGION (const_int 1 [0x1])
(nil



insn 59: replaced reg 0 with 7
rescanning insn with uid = 59.
ending the processing of deferred insns
df_analyze called
df_worklist_dataflow_doublequeue: n_basic_blocks 7 n_edges 7 count 7 (1)
deferring rescan insn with uid = 15.
deferring deletion of insn with uid = 59.

But then we don't update the basic blocks correctly ...

[Bug c/105612] [meta-bug] bogus/missing -Wtautological-compare

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105612
Bug 105612 depends on bug 116069, which changed state.

Bug 116069 Summary: tautological-compare warnings observed only with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116069

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c/80369] Warnings from preprocessor generated code not shown

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80369

Andrew Pinski  changed:

   What|Removed |Added

 CC||jbeulich at suse dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 116069 has been marked as a duplicate of this bug. ***

[Bug c/116069] tautological-compare warnings observed only with -save-temps

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116069

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #2 from Andrew Pinski  ---
Dup.

*** This bug has been marked as a duplicate of bug 80369 ***

[Bug c/116069] tautological-compare warnings observed only with -save-temps

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116069

--- Comment #1 from Andrew Pinski  ---
This happens IIRC tracking from macros is lost.

[Bug target/116076] [15 Regression] 4.5% slowdown of 433.milc on AMD Zen4

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116076

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||missed-optimization

[Bug target/116076] [15 Regression] 4.5% slowdown of 433.milc on AMD Zen4

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116076

--- Comment #1 from Andrew Pinski  ---
Might be:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=1e3aa9c9278db69d4bdb661a750a7268789188d6

[Bug c++/107211] [12/13/14/15 Regression] GCC compiles invalid use of non static member function in noexcept operator

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107211

--- Comment #7 from Andrew Pinski  ---
(In reply to Tymi from comment #6)
> And just as an addition, it always yields true. 
> For example here:
> ```cpp
> int awoo(void) noexcept(false);
> int awoo(int) noexcept(false);
> 
> int main(void)
> {
> std::cout << noexcept(awoo);
> }
> ```
> It still yields true (1). I suspect (I have not seen the source) the
> behaviour for this is already done, just the error is handled a different
> way than.. it should..

That is PR 78048 (and PR 86602).

[Bug tree-optimization/116079] [15 Regression] ice during GIMPLE pass lim

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116079

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
Confirmed, though it looks like it depends on an uninitialized array. I can't
reproduce the ICE otherwise.

Note this source looks like it was originally reduced by cvise, do you have the
original source where the ICE shows up? I want to see if it can be reproduce
without the uninitialized array.

[Bug tree-optimization/116079] [15 Regression] ice during GIMPLE pass lim

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116079

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
Summary|ice during GIMPLE pass lim  |[15 Regression] ice during
   ||GIMPLE pass lim

[Bug c++/116064] [15 Regression] SPEC 2017 523.xalancbmk_r failed to build

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116064

--- Comment #6 from Andrew Pinski  ---
By the way Xalan even upstream still has this bug.
https://github.com/apache/xalan-c/blob/c326619da4813acfc845c2830d904a4860f9afe1/src/xalanc/XMLSupport/XalanOtherEncodingWriter.hpp#L323

They do have a jira but there does not look like there is much work being done
on the project either.
(https://issues.apache.org/jira/issues/ ).

[Bug tree-optimization/116075] Inefficient SVE INSR codegen

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116075

--- Comment #2 from Andrew Pinski  ---
Short not using the vectorizer testcase:
```
#include 

svint8_t f(void)
{
  svint8_t tt;
  tt = svdup_s8 (0);
  tt = svinsr (tt, 0);
  return tt;
}
```

Note LLVM does not optimize the above to just `mov z31.b, #0` either but does
for the original auto-vectorized testcase.

[Bug target/116072] [15 Regression] 4.5% slowdown of 447.dealII on aarch64

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116072

--- Comment #2 from Andrew Pinski  ---
Also what glibc version is on the system? Since if it is std::find that is
causing the regression memchr was improved in the last year or so in glibc.

[Bug tree-optimization/87985] Compile-time and memory hog w/ -O1 -ftree-slp-vectorize

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87985

--- Comment #7 from Andrew Pinski  ---
This seems to regressed again on  the trunk for aarch64 (didn't check x86_64).

[Bug c++/109126] [DR2387] Linkage of const-qualified variable template

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109126

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-07-24

--- Comment #2 from Andrew Pinski  ---
.

[Bug c++/94404] [meta-bug] C++ core issues

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
Bug 94404 depends on bug 116077, which changed state.

Bug 116077 Summary: GCC hasn't implemented CWG DR 2387
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116077

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug c++/109126] [DR2387] Linkage of const-qualified variable template

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109126

Andrew Pinski  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #1 from Andrew Pinski  ---
*** Bug 116077 has been marked as a duplicate of this bug. ***

[Bug c++/116077] GCC hasn't implemented CWG DR 2387

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116077

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andrew Pinski  ---
Dup.

*** This bug has been marked as a duplicate of bug 109126 ***

[Bug target/116059] [14/15 Regression] Miscompile at -O2 since r14-6420-g85c5efcffed

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116059

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=115336

--- Comment #6 from Andrew Pinski  ---
(In reply to Robin Dapp from comment #3)
> Glad we went for rvv_ma_all_1s=true because otherwise this one would have
> gone unnoticed :)  The -fsigned-char -fno-strict-aliasing -fwrapv look
> unnecessary.  I see the problem without them as well, just the output is 255
> instead of 4294967295.
> 
> vect__3.14_56 = .MASK_LEN_LOAD (vectp_b.12_54, 8B, mask__15.11_52, _67, 0);
> // 1/0
> 
> The // 1/0 is unfortunately not true for RVV, it's rather 1/undefined which
> is where we go wrong.  So it looks pretty much like the missing else operand
> for the masked load again.  On my local "else operand" branch that merges
> with an empty vector the test succeeds.

Oh yes this issue. there was some recent discussion on the list saying the
semantics of MASK_LOAD is load and resulting of 0. Oh yes in reference to PR
115336.

https://inbox.sourceware.org/gcc-patches/7ea24dfc-34dd-4931-8614-6fd0ef869...@gmail.com/

[Bug target/116059] [14/15 Regression] Miscompile at -O2 since r14-6420-g85c5efcffed

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116059

--- Comment #5 from Andrew Pinski  ---
(In reply to Robin Dapp from comment #4)
> Strange, Andrew's comment didn't reach my inbox while both of Patrick's did.

Are you subscribed to gcc-bugs@ if not then you were added to the CC after my
comment was done :).

[Bug target/116072] [15 Regression] 4.5% slowdown of 447.dealII on aarch64

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116072

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #1 from Andrew Pinski  ---
I am suspecting it is the std::find changes (e.g r15-1857). I did hear that
libc++'s usage of memchr was slowering for SPEC 2006 on aarch64 before and
dealII is C++ code after all.

[Bug tree-optimization/116074] [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581)

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074

--- Comment #2 from Andrew Pinski  ---
opt_machine_mode
related_int_vector_mode (machine_mode vector_mode)
{
  gcc_assert (VECTOR_MODE_P (vector_mode));

So it is not passing a vector type here ...

[Bug tree-optimization/116074] [15 regression] ICE when building harfbuzz-9.0.0 on arm64 (related_int_vector_mode, at stor-layout.cc:581)

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116074

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||ice-on-valid-code
 Blocks||53947


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug c++/116052] [15 Regression] ICE in diagnostic_context::diagnostic_impl

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116052

--- Comment #4 from Andrew Pinski  ---
I am reducing but it is going slowly.

[Bug tree-optimization/116075] Inefficient SVE INSR codegen

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116075

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Component|target  |tree-optimization
   Last reconfirmed||2024-07-24
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Target|aarch64 |aarch64 riscv
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
>   _72 = .VEC_SHL_INSERT ({ 0, ... }, 0);

Confirmed.
This could be optimized at the gimple level to just `{0, ...}` I think.

And it shows up in RISCV too:
```
vsetvli a4,zero,e32,m1,ta,ma
vmv.v.i v2,0
csrra3,vlenb
li  a0,32768
srlia3,a3,2
addia0,a0,-768
lui a5,%hi(in)
vslide1up.vxv1,v2,zero
```

The internal function is a direct function to the optab vec_shl_insert:

```
@cindex @code{vec_shl_insert_@var{m}} instruction pattern
@item @samp{vec_shl_insert_@var{m}}
Shift the elements in vector input operand 1 left one element (i.e.@:
away from element 0) and fill the vacated element 0 with the scalar
in operand 2.  Store the result in vector output operand 0.  Operands
0 and 1 have mode @var{m} and operand 2 has the mode appropriate for
one element of @var{m}.
```

So if we have 0 for both then the result is also 0.

So this should fold it:
```
(simplify
 (INF_VEC_SHL_INSERT @1 uniform_vector_p@2)
 (if (operands_equal (@1, uniform_vector_p(@2))
  @2))

```

That is if we are inserting a value that is the same as the uniform vector we
can just simplify it to the uniform vector.

I will take care of this.

[Bug middle-end/115961] [15 Regression] wrong code on llvm-18.1.8 since r15-1936-g80e446e829d818 with bitfields less than the type mode precision

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #7 from Andrew Pinski  ---
Fixed. The fortran failures from my patches for PR 115086 are also fixed after
this.

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-24 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086
Bug 115086 depends on bug 115961, which changed state.

Bug 115961 Summary: [15 Regression] wrong code on llvm-18.1.8 since 
r15-1936-g80e446e829d818 with bitfields less than the type mode precision
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug middle-end/116065] [13/14/15 Regression] Function attribute optimize() might make ISA target attribute broken

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116065

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
  Component|target  |middle-end
   Last reconfirmed||2024-07-24

--- Comment #1 from Andrew Pinski  ---
Confirmed.

It also happens for aarch64 with:
```
#include 

int __attribute__((target ("+sve"), optimize(3)))
bar (void)
{
  svfloat32_t xseg;
  return svlen_f32(xseg);
}
```

Which makes me think this is not target specific. Same behavior at x86_64
testcase with the optimization levels too.

[Bug target/116065] [13/14/15 Regression] Function attribute optimize() might make ISA target attribute broken

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116065

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.4
 CC||pinskia at gcc dot gnu.org
   Keywords||needs-bisection,
   ||rejects-valid

[Bug target/116063] [PPC] Transparent union issue with signedness when optimizing

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116063

--- Comment #3 from Andrew Pinski  ---
(In reply to Hubert Tong from comment #2)
> If it is invalid, a diagnostic like this should appear:
> ```
> warning: union cannot be made transparent
> ```

Not always.
typedef union __attribute__((__transparent_union__)) U {
  unsigned int u;
  int x;
} U;

also fails the same way because signed int and unsigned int are passed
differently.

[Bug target/116063] [PPC] Transparent union issue with signedness when optimizing

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116063

--- Comment #1 from Andrew Pinski  ---
Hmm
(https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Common-Type-Attributes.html):
Second, the argument is passed to the function using the calling conventions of
the first member of the transparent union, not the calling conventions of the
union itself. All members of the union must have the same machine
representation; this is necessary for this argument passing to work properly.


I think this is invalid based on the documention.

[Bug c++/116064] [15 Regression] SPEC 2017 523.xalancbmk_r failed to build

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116064

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID
   See Also||https://github.com/llvm/llv
   ||m-project/issues/96859

--- Comment #1 from Andrew Pinski  ---
Same issue as clang bug report:
https://github.com/llvm/llvm-project/issues/96859

This is a bug in the sources.

[Bug middle-end/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058

--- Comment #8 from Andrew Pinski  ---
Created attachment 58745
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58745=edit
Try2

This fixes the disconnect between genorg and genemit inside genemit's removing
the explicit PARALLEL when generating the clobber lists. I think this should be
done even if it does not fix the boostrap since fixes the disconnect which has
been there since maybe r0-788-ge5f6a288fb94fa (1991) which changed how the
clobber list was generated.

[Bug middle-end/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Component|target  |middle-end
   Last reconfirmed||2024-07-24
 Ever confirmed|0   |1

--- Comment #6 from Andrew Pinski  ---
gen_insn (genemit.cc) does not add the implicit parallel until after it looks
at the clobber list. While genrecog.cc adds the implicit parallel
(add_implicit_parallel) before it starts to generate the recorg code.


Looks like this has been a bug for real long time (over 20 years) and this is
the first time it makes a difference.

So the fix should be inside gen_insn (genemit.cc) I think to look through a
parallel if that was the only thing in the list to look for the clobbers.

[Bug target/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058

--- Comment #5 from Andrew Pinski  ---
So from what I can tell is happening is
recog_level2 (in rtl-ssa/changes.cc)
calls recog:
  icode = ::recog (pat, rtl, _clobbers);


num_clobbers is greater than 0 and then we remove the clobbers inside the
PARALLEL:
  if (GET_CODE (pat) == PARALLEL)
{
  oldlen = XVECLEN (pat, 0);
  newvec = rtvec_alloc (num_clobbers + oldlen);
  for (int i = 0; i < oldlen; ++i)
RTVEC_ELT (newvec, i) = XVECEXP (pat, 0, i);
}


BUT add_clobbers does not handle the case where the clobbers was inside the
PARALLEL.

I am trying to understand why there is a difference understanding in
num_clobbers between recog and add_clobbers now.

[Bug rtl-optimization/116062] Exponentially slow compilation at -O3 with __attribute__((flatten))

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116062

Andrew Pinski  changed:

   What|Removed |Added

  Component|ipa |rtl-optimization

--- Comment #2 from Andrew Pinski  ---
 PRE:  17.11 ( 29%)   0.03 (  3%)  17.17 ( 28%)
 1752  (  0%)
 load CSE after reload  :  24.04 ( 40%)   0.00 (  0%)  24.12 ( 39%)
  182k (  0%)


This was --enable-checking=yes but with -fno-checking .

[Bug ipa/116062] Exponentially slow compilation at -O3 with __attribute__((flatten))

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116062

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||compile-time-hog
  Component|c++ |ipa

--- Comment #1 from Andrew Pinski  ---
I think this is expected because when you use flatten you explicitly say inline
everything.

[Bug target/116043] [15 regression] TLS relocation issue when building glibc with -O3 -mavx512bf16 by r15-1619

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116043

--- Comment #14 from Andrew Pinski  ---
(In reply to H.J. Lu from comment #13)
> This caused by r15-1619-g3b9b8d6cfdf593.

exposed by because that just changed the register allocation allocation really.

[Bug target/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058

--- Comment #3 from Andrew Pinski  ---
Created attachment 58744
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58744=edit
Patch which seems to fix the issue

This patch removes the parallel in the define_insn and seems to fix the issue.
The problem is we don't add back the clobbers that is inside the parallel. 

https://gcc.gnu.org/onlinedocs/gccint/Side-Effects.html#index-parallel

Does kinda of warn about this. But it is not obvious though.

[Bug rtl-optimization/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058

--- Comment #2 from Andrew Pinski  ---
trying to combine definition of r8 in:
```
 2004: r8:SI=r2:SI
into:
  725: {[r4:SI]=[r5:SI];use r8:SI;use 0;use r6:SI;clobber pr:SI;clobber
t:SI;clobber r4:SI;clobber r5:SI;clobber r6:SI;clobber r0:SI;clobber
r1:SI;clobber r2:SI;clobber r3:SI;}
register 4 is both clobbered and used as an input:
(parallel [
(set (mem:BLK (reg:SI 4 r4) [0  A8])
(mem:BLK (reg:SI 5 r5) [0  A8]))
(use (reg:SI 2 r2))
(use (const_int 0 [0]))
(use (reg:SI 6 r6))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 147 t))
(clobber (reg:SI 4 r4))
(clobber (reg:SI 5 r5))
(clobber (reg:SI 6 r6))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
(clobber (reg:SI 2 r2))
(clobber (reg:SI 3 r3))
])

```
The instruction before hand:
(insn 725 2004 726 68 (parallel [
(set (mem:BLK (reg:SI 4 r4) [0  A8])
(mem:BLK (reg:SI 5 r5) [0  A8]))
(use (reg:SI 8 r8))
(use (const_int 0 [0]))
(use (reg:SI 6 r6))
(clobber (reg:SI 146 pr))
(clobber (reg:SI 147 t))
(clobber (reg:SI 4 r4))
(clobber (reg:SI 5 r5))
(clobber (reg:SI 6 r6))
(clobber (reg:SI 0 r0))
(clobber (reg:SI 1 r1))
(clobber (reg:SI 2 r2))
(clobber (reg:SI 3 r3))
]) "t.ii":977:9 322 {block_lump_real_i4}
 (nil))


The pattern:
(define_insn "block_lump_real_i4"
  [(parallel [(set (mem:BLK (reg:SI R4_REG))
   (mem:BLK (reg:SI R5_REG)))
  (use (match_operand:SI 0 "arith_reg_operand" "r,r"))
  (use (match_operand 1 "" "Z,Ccl"))
  (use (reg:SI R6_REG))
  (clobber (reg:SI PR_REG))
  (clobber (reg:SI T_REG))
  (clobber (reg:SI R4_REG))
  (clobber (reg:SI R5_REG))
  (clobber (reg:SI R6_REG))
  (clobber (reg:SI R0_REG))
  (clobber (reg:SI R1_REG))
  (clobber (reg:SI R2_REG))
  (clobber (reg:SI R3_REG))])]

It is already using register 4 in the clobber and in the address before hand
...

[Bug rtl-optimization/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058

--- Comment #1 from Andrew Pinski  ---
from reading the code, this means add_clobbers was called on an unrecognized
insn.

[Bug rtl-optimization/116058] [15 Regression] sh4-linux-gnu fails to bootstrap, late combine issue

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116058

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||build, ice-on-valid-code
 CC||pinskia at gcc dot gnu.org

[Bug target/116059] [14/15 Regression] Miscompile at -O2 since r14-6420-g85c5efcffed

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116059

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |target
   Target Milestone|--- |14.2

--- Comment #1 from Andrew Pinski  ---
The gimple looks like:
```
;; Function main (main, funcdef_no=0, decl_uid=2758, cgraph_uid=1,
symbol_order=2) (executed once)

int main ()
{
  vector([4,4]) char vect_iftmp.18;
  vector([4,4]) char vect__33.17;
  vector([4,4]) char vect__32.16;
  vector([4,4]) char vect_iftmp.15;
  vector([4,4]) unsigned char vect__3.14;
  _Bool * vectp_b.13;
  vector([4,4]) unsigned char * vectp_b.12;
  vector([4,4])  mask__15.11;
  vector([4,4]) int vect__11.10;
  vector([4,4]) int vect_vec_iv_.9;
  char D.2780;
  char a_lsm.6;
  int d;
  char _4(D);
  int _5;
  int _45;
  vector([4,4]) int vect_cst__46;
  vector([4,4]) int _48;
  unsigned long _63;
  char _64;
  unsigned long ivtmp_65;
  unsigned long ivtmp_66;
  unsigned long _67;

   [local count: 63136016]:

   [local count: 252544065]:
  # vect_vec_iv_.9_47 = PHI <_48(3), { 0, 1, 2, ... }(2)>
  # vectp_b.12_54 = PHI 
  # ivtmp_65 = PHI 
  _67 = .SELECT_VL (ivtmp_65, POLY_INT_CST [4, 4]);
  _45 = (int) _67;
  vect_cst__46 = [vec_duplicate_expr] _45;
  _48 = vect_cst__46 + vect_vec_iv_.9_47;
  vect__11.10_50 = vect_vec_iv_.9_47 & { 1, ... }; // 0/1
  mask__15.11_52 = vect__11.10_50 != { 0, ... }; // 0/-1
  vect__3.14_56 = .MASK_LEN_LOAD (vectp_b.12_54, 8B, mask__15.11_52, _67, 0);
// 1/0
  vect_iftmp.15_57 = VIEW_CONVERT_EXPR(vect__3.14_56); // 1
  vect__32.16_58 = (vector([4,4]) char) vect__11.10_50;
  vect__33.17_60 = vect__32.16_58 ^ { 1, ... }; //0, 1
  vect_iftmp.18_61 = vect_iftmp.15_57 | vect__33.17_60; // 1
  vectp_b.12_55 = vectp_b.12_54 + _67;
  ivtmp_66 = ivtmp_65 - _67;
  if (ivtmp_66 != 0)
goto ; [75.00%]
  else
goto ; [25.00%]

   [local count: 63136016]:
  _63 = _67 + 18446744073709551615; //_67 - 1
  _64 = .VEC_EXTRACT (vect_iftmp.18_61, _63);
  a = _64;
  _5 = (int) _64;
  __builtin_printf ("%u\n", _5);
  return 0;

}
```

I don't see anything wrong here in the gimple here.

Someone from the riscv side will need to debug it from an instruction side
because the gimple looks fine and correct (still).

[Bug tree-optimization/116057] [12/13/14/15 Regression] SLP can introduces partialized unintialized vectors

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

Andrew Pinski  changed:

   What|Removed |Added

Summary|Miscompilation of nodejs|[12/13/14/15 Regression]
   |with -ftree-slp-vectorize   |SLP can introduces
   |on arm64 and probably   |partialized unintialized
   |others  |vectors
   Keywords||wrong-code
   Target Milestone|--- |12.5

[Bug tree-optimization/116057] Miscompilation of nodejs with -ftree-slp-vectorize on arm64 and probably others

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

Andrew Pinski  changed:

   What|Removed |Added

 Target|aarch64-unknown-linux-gnu   |aarch64-unknown-linux-gnu
   ||x86_64-linux-gnu
   Host|aarch64-unknown-linux-gnu   |
  Build|aarch64-unknown-linux-gnu   |

--- Comment #9 from Andrew Pinski  ---
So r12-397-gda9e6e63d1ae22 introduced ccp after the slp vectorizer.

Also it happens on x86_64 with -fno-vect-cost-model.

[Bug tree-optimization/116057] Miscompilation of nodejs with -ftree-slp-vectorize on arm64 and probably others

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

--- Comment #8 from Andrew Pinski  ---
The question comes is this defined or undefined?
I think it is still undefined.

Changing:
Maybe() : has_value_(false) {}

into:
Maybe() : has_value_(false), value_() {}

Makes this well defined.
And has no effect on if value_ had a constructor or not.

[Bug tree-optimization/116057] Miscompilation of nodejs with -ftree-slp-vectorize on arm64 and probably others

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

--- Comment #7 from Andrew Pinski  ---
Can you attach the full preprocessed source instead of just linking?

[Bug tree-optimization/116057] Miscompilation of nodejs with -ftree-slp-vectorize on arm64 and probably others

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-23
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

[Bug tree-optimization/116057] Miscompilation of nodejs with -ftree-slp-vectorize on arm64 and probably others

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

--- Comment #5 from Andrew Pinski  ---
Can you attach the original code that was failing since the reduced one is
questionable?

[Bug tree-optimization/116057] Miscompilation of nodejs with -ftree-slp-vectorize on arm64 and probably others

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

--- Comment #4 from Andrew Pinski  ---
So this code might have undefined behavior. At the very least it is
questionable.

[Bug tree-optimization/116057] Miscompilation of nodejs with -ftree-slp-vectorize on arm64 and probably others

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

--- Comment #3 from Andrew Pinski  ---
#define vect8 __attribute__((vector_size(8)))

vect8 int f(int a)
{
  int b;
  vect int t={1,1};
  if(a) return t;
  return (vect8 int){0, b};
}

[Bug tree-optimization/116057] Miscompilation of nodejs with -ftree-slp-vectorize on arm64 and probably others

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116057

--- Comment #2 from Andrew Pinski  ---
g:33c2b70dbabc02788caabcbc66b7baeafeb95bcf

That just changed the cost model.

Most likely could be reproduced with -fno-cost-model beforehand. 

Note there is an unitialized usage on one side of the if so that might be an
iasue.

[Bug preprocessor/108900] [libcpp] cpp gives wrong line number information with a file huge number of lines

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108900

Andrew Pinski  changed:

   What|Removed |Added

 CC||ovidiu.panait at windriver dot 
com

--- Comment #4 from Andrew Pinski  ---
*** Bug 116047 has been marked as a duplicate of this bug. ***

[Bug preprocessor/116047] C preprocessor bug

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116047

--- Comment #4 from Andrew Pinski  ---
Wrong one.

*** This bug has been marked as a duplicate of bug 108900 ***

[Bug preprocessor/84864] Issues with large line numbers >= 2^31

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84864

Andrew Pinski  changed:

   What|Removed |Added

 CC||ovidiu.panait at windriver dot 
com

--- Comment #10 from Andrew Pinski  ---
*** Bug 116047 has been marked as a duplicate of this bug. ***

[Bug preprocessor/116047] C preprocessor bug

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116047

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup.

*** This bug has been marked as a duplicate of bug 84864 ***

[Bug driver/116050] Passing invalid option to gcc with --version results in exit status of 0

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116050

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-23
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
  if (!maybe_print_and_exit ())
return 0;

Maybe that should be changed to get_exit_code() instead of 0.

[Bug ipa/106783] [12/13/14/15 Regression] ICE in ipa-modref.cc:analyze_function since r12-5247-ga34edf9a3e907de2

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106783

--- Comment #7 from Andrew Pinski  ---
(In reply to Jan Hubicka from comment #6)
> The problem is that n/=0 is undefined behavior (so we can optimize out call
> to function doing divide by zero), while __builtin_trap is observable and we
> do not optimize out code paths that may trip to it.
> 
> so isolate-paths is de-facto pesimizing code from this POV.  It is used
> __builtin_unreachable things would work.  I think some parts of compiler use
> __builtin_unreachable (such as loop unrolling) other __builtin_trap.  It
> would be nice to have consistent solution to this.

Also see the discussion at
https://gcc.gnu.org/pipermail/gcc/2024-June/244213.html .

[Bug ipa/116055] [14 regression] ICE from gcc.c-torture/unsorted/dump-noaddr.c after r14-10495-g9ddd5f88e60972

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116055

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=106783

--- Comment #1 from Andrew Pinski  ---
Looks very similar to PR 106783.

[Bug target/116054] RISCV: RV32: prologue/epilogue degradation

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116054

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58737|0   |1
is obsolete||

--- Comment #3 from Andrew Pinski  ---
Created attachment 58738
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58738=edit
reduced testcase

64bit looks ok and does the right thing for TImode (128bit).

[Bug target/116054] RISCV: RV32: prologue/epilogue degradation

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116054

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra

--- Comment #2 from Andrew Pinski  ---
Before RA:
```
(call_insn 16 15 44 3 (parallel [
(set (reg:DI 10 a0)
(call (mem:SI (symbol_ref:SI ("_Z18esp_timer_get_timev") [flags
0x41]  ) [0 esp_timer_get_time
S4 A32])
(const_int 0 [0])))
(use (unspec:SI [
(const_int 0 [0])
] UNSPEC_CALLEE_CC))
(clobber (reg:SI 1 ra))
]) "/app/example.cpp":18:33 355 {call_value_internal}
 (expr_list:REG_CALL_DECL (symbol_ref:SI ("_Z18esp_timer_get_timev") [flags
0x41]  )
(nil))
(nil))
(insn 44 16 45 3 (set (reg:SI 141)
(reg:SI 10 a0)) "/app/example.cpp":18:33 211 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 10 a0)
(nil)))
(insn 45 44 46 3 (set (reg:SI 142 [+4 ])
(reg:SI 11 a1 [+4 ])) "/app/example.cpp":18:33 211 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 11 a1 [+4 ])
(nil)))
(insn 46 45 47 3 (set (subreg:SI (reg:DI 136 [ _7 ]) 0)
(reg:SI 141)) "/app/example.cpp":18:33 211 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 141)
(nil)))
(insn 47 46 18 3 (set (subreg:SI (reg:DI 136 [ _7 ]) 4)
(reg:SI 142 [+4 ])) "/app/example.cpp":18:33 211 {*movsi_internal}
 (expr_list:REG_DEAD (reg:SI 142 [+4 ])
(nil)))
```


Afterwards:
```
(call_insn 16 15 46 3 (parallel [
(set (reg:DI 10 a0)
(call (mem:SI (symbol_ref:SI ("_Z18esp_timer_get_timev") [flags
0x41]  ) [0 esp_timer_get_time
S4 A32])
(const_int 0 [0])))
(use (unspec:SI [
(const_int 0 [0])
] UNSPEC_CALLEE_CC))
(clobber (reg:SI 1 ra))
]) "/app/example.cpp":18:33 431 {call_value_internal}
 (expr_list:REG_CALL_DECL (symbol_ref:SI ("_Z18esp_timer_get_timev") [flags
0x41]  )
(nil))
(nil))
(insn 46 16 47 3 (set (reg:SI 18 s2 [orig:136 _7 ] [136])
(reg:SI 10 a0 [141])) "/app/example.cpp":18:33 276 {*movsi_internal}
 (nil))
(insn 47 46 18 3 (set (reg:SI 19 s3 [ _7+4 ])
(reg:SI 11 a1 [orig:142+4 ] [142])) "/app/example.cpp":18:33 276
{*movsi_internal}
 (nil))
```

Note in GCC 13 and before there was a clobber of reg pseduo 136 between insn
between insn 45 and 46 (in the before RA) which seems to allow the RA to be
better in this case.

[Bug target/116054] RISCV: RV32: prologue/epilogue degradation

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116054

--- Comment #1 from Andrew Pinski  ---
Created attachment 58737
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58737=edit
testcase from godbolt

Please next time attach or put the testcase inline instead of just linking to
godbolt .

[Bug c++/116052] [15 Regression] ICE in diagnostic_context::diagnostic_impl

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116052

Andrew Pinski  changed:

   What|Removed |Added

URL|https://godbolt.org/z/rq67M |
   |nsrr|

--- Comment #3 from Andrew Pinski  ---
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:375:9:
  required from here
/opt/compiler-explorer/libs/stdexec/trunk/include/stdexec/__detail/__basic_sender.hpp:375:9:
internal compiler error: Segmentation fault
0x2733540 internal_error(char const*, ...)
   
/home/apinski/src/upstream-gcc-new/gcc/gcc/diagnostic-global-context.cc:491
0x13ad136 crash_signal
/home/apinski/src/upstream-gcc-new/gcc/gcc/toplev.cc:319
0xb7fd78 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
/home/apinski/src/upstream-gcc-new/gcc/gcc/tree.h:3777
0xb7fd78 write_prefix
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1344
0xb7fd78 write_prefix
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1293
0xb7fe56 write_prefix
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1354
0xb7fe56 write_prefix
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1293
0xb800a7 write_nested_name
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1279
0xb80757 write_type
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:2522
0xb7ecf5 write_template_arg
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:4107
0xb7f91b write_template_args
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:3228
0xb7ec47 write_template_arg
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:4139
0xb7f91b write_template_args
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:3228
0xb7fd34 write_prefix
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1342
0xb7fd34 write_prefix
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1293
0xb8395f write_template_prefix
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1443
0xb800ee write_nested_name
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1267
0xb80757 write_type
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:2522
0xb7f91b write_template_args
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:3228
0xb7fff3 write_nested_name
/home/apinski/src/upstream-gcc-new/gcc/gcc/cp/mangle.cc:1259
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/116052] [15 Regression] ICE in diagnostic_context::diagnostic_impl

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116052

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED

[Bug c++/116052] [15 Regression] ICE in diagnostic_context::diagnostic_impl

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116052

--- Comment #2 from Andrew Pinski  ---
Created attachment 58736
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58736=edit
preprocessed testcase from godbolt

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-23 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||115961

--- Comment #13 from Andrew Pinski  ---
Testcases that need changes to support BIT_ANDN and BIT_IORN (though I wonder
if one or 2 will depend on the fix for PR 115961 too):
+FAIL: gcc.dg/tree-ssa/bitops-1.c scan-tree-dump-times optimized "bit_and_expr"
9
+FAIL: gcc.dg/tree-ssa/bitops-1.c scan-tree-dump-times optimized "bit_ior_expr"
10
+FAIL: gcc.dg/tree-ssa/bitops-1.c scan-tree-dump-times optimized "bit_not_expr"
12
+FAIL: gcc.dg/tree-ssa/bitops-6.c scan-tree-dump-times optimized "bit_and_expr,
" 4
+FAIL: gcc.dg/tree-ssa/bitops-6.c scan-tree-dump-times optimized "bit_not_expr,
" 1
+FAIL: gcc.dg/tree-ssa/bitops-8.c scan-tree-dump-times optimized "bit_ior_expr,
" 1
+FAIL: gcc.dg/tree-ssa/bitops-8.c scan-tree-dump-times optimized "bit_not_expr,
" 1
+FAIL: gcc.dg/tree-ssa/cmpbit-4.c scan-tree-dump-times optimized "bit_and_expr,
" 6
+FAIL: gcc.dg/tree-ssa/cmpbit-4.c scan-tree-dump-times optimized "bit_not_expr,
" 2
+FAIL: gcc.dg/tree-ssa/pr110637-2.c scan-tree-dump-times optimized " & 1" 1
+FAIL: gcc.dg/tree-ssa/pr110637-2.c scan-tree-dump-times optimized "~a" 1
+FAIL: gcc.dg/tree-ssa/pr94880.c scan-tree-dump-times optimized " & [xy]_" 4
+FAIL: gcc.dg/tree-ssa/pr94880.c scan-tree-dump-times optimized "= ~[xy]_" 4
+FAIL: gcc.dg/tree-ssa/pr96671-1.c scan-tree-dump-times optimized " & " 6
+FAIL: gcc.dg/tree-ssa/pr96671-1.c scan-tree-dump-times optimized " ~" 6


Testcases which depend on the fix for PR 115961 (these all have logical(4)
types in it):
+FAIL: libgomp.fortran/lib1.f90   -Os  execution test
+FAIL: libgomp.fortran/lib2.f   -Os  execution test
+FAIL: libgomp.fortran/lib3.f   -Os  execution test
+FAIL: libgomp.fortran/reduction2.f90   -O2  execution test
+FAIL: libgomp.fortran/reduction2.f90   -O3 -fomit-frame-pointer -funroll-loops
-fpeel-loops -ftracer -finline-functions  execution test
+FAIL: libgomp.fortran/reduction2.f90   -O3 -g  execution test
+FAIL: libgomp.fortran/reduction2.f90   -Os  execution test


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115961
[Bug 115961] [15 Regression] wrong code on llvm-18.1.8 since
r15-1936-g80e446e829d818 with bitfields less than the type mode precision

[Bug target/116013] Missed optimization opportunity with andn involving consts

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116013

--- Comment #6 from Andrew Pinski  ---
Note I attached my patches to PR 115086 which fixes this for aarch64. All that
is needed after these patches get approved is either rename the current
patterns in the i386 backend to be andn3 and iorn3 and it will work
correctly. even for vector modes.

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #58726|0   |1
is obsolete||
  Attachment #58728|0   |1
is obsolete||

--- Comment #12 from Andrew Pinski  ---
Created attachment 58730
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58730=edit
New set of patches

I am going to test these tonight for aarch64 but will have to test tomorrow on
powerpc because I am waiting on the cfarm to update my ssh key.

[Bug target/116013] Missed optimization opportunity with andn involving consts

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116013

--- Comment #5 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #4)
> I have patches for part of this, though the optabs need to be renamed so the
> backend changes have to wait until I finish that. and I need to also match
> ~(a | CST) into `BIT_ANDC (~CST, a)` which I will add too.

Added that part of the patch to PR 115086. Once I change the optab name the x86
backend folks can implement the optabs and both of these will optimize now.

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086

--- Comment #11 from Andrew Pinski  ---
Created attachment 58728
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58728=edit
Patch that goes on top of the rest

This will fix the testcase in comment #10. It does fix the vector type one
(gcc/testsuite/gcc.target/aarch64/bic_simd-2.c) .

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086

--- Comment #10 from Andrew Pinski  ---
Another testcase:
```
unsigned test1(unsigned value)
{
  return ~(value | 0xf);
}
```

This one is reduced from PR 116013 .

[Bug target/116013] Missed optimization opportunity with andn involving consts

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116013

--- Comment #4 from Andrew Pinski  ---
I have patches for part of this, though the optabs need to be renamed so the
backend changes have to wait until I finish that. and I need to also match ~(a
| CST) into `BIT_ANDC (~CST, a)` which I will add too.

[Bug target/116013] Missed optimization opportunity with andn involving consts

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116013

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=111949
   Last reconfirmed||2024-07-23

--- Comment #3 from Andrew Pinski  ---
The combine issue is:
```
Failed to match this instruction:
(set (reg:DI 101 [ _3 ])
(and:DI (not:DI (reg:DI 104))
(const_int -9187201950435737472 [0x8080808080808080])))
Successfully matched this instruction:
(set (reg:DI 102 [ _1 ])
(not:DI (reg:DI 104)))
Failed to match this instruction:
(set (reg:DI 101 [ _3 ])
(and:DI (reg:DI 102 [ _1 ])
(const_int -9187201950435737472 [0x8080808080808080])))
```

which is very similar to PR 111949 and similar to PR 115086.

[Bug rtl-optimization/116037] [15 Regression] wrong code at -O2 with vector masking and add

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116037

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-07-23
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Andrew Pinski  ---
.

[Bug rtl-optimization/116039] [15 Regression] rv64gc miscompile at -O3 with -fno-strict-aliasing since r15-1901-g98914f9eba5

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116039

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-23
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
.

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086

--- Comment #9 from Andrew Pinski  ---
Created attachment 58726
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58726=edit
Current set of patches

This is the current set of patches but still need the optab name changes which
I will work on tomorrow.

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://github.com/llvm/llv
   ||m-project/issues/100045

--- Comment #8 from Andrew Pinski  ---
Note LLVM does do the same trick with orn which it does with bic so I filed
https://github.com/llvm/llvm-project/issues/100045 .

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #6)
> Note andc optab was added with r15-1890-gf379596e0ba99d .

Note the c here will need to be changed as there is a mode called csi (which is
the complex si mode which is used sometimes).

This means I am going to have to test powerpc too since it already has pattern
for andc and iorc.

[Bug target/116010] [15 regression] vectorization regressions on arm and aarch64 since r15-491-gc290e6a0b7a9de

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116010

--- Comment #5 from Andrew Pinski  ---
(In reply to Thiago Jung Bauermann from comment #3)
> Created attachment 58725 [details]
> mve-vabs.s generated by the test after commit c290e6a0b7a9.
> 
> (In reply to Andrew Pinski from comment #1)
> > So I think there are 2 different issues here.
> 
> If that is the case, then I can open a separate bugzilla so that there's one
> for each test failure.
>  
> > First gcc.target/arm/simd/mve-vabs.c now calls memcpy because of the
> > restrict instead of memmove. That should be a simple fix there.
> 
> In my setup I don't see memcpy being called. Instead of memmove, GCC is now
> generating the load and store instruction. E.g.:

Well that is an inlined version of memcpy. I was looking at what was done in
the tree dump to see the difference.

[Bug testsuite/116041] aarch64 fallout from removing vcond{,u,eq} patterns

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116041

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-07-22
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
>From aarch64-simd.md:
;; aarch64_simd_bsl may compile to any of bsl/bif/bit depending on register
;; allocation.
;; Operand 1 is the mask, operands 2 and 3 are the bitfields from which
;; to select.
;;
;; Thus our BSL is of the form:
;;   op0 = bsl (mask, op2, op3)
;; We can use any of:
;;
;;   if (op0 = mask)
;; bsl mask, op1, op2
;;   if (op0 = op1) (so 1-bits in mask choose bits from op2, else op0)
;; bit op0, op2, mask
;;   if (op0 = op2) (so 0-bits in mask choose bits from op1, else op0)
;; bif op0, op1, mask
;;
;; This pattern is expanded to by the aarch64_simd_bsl expander.
;; Some forms of straight-line code may generate the equivalent form
;; in *aarch64_simd_bsl_alt.


so it is the same but just with different operand ordering.

So I will handle this testcase change.

[Bug testsuite/116041] aarch64 fallout from removing vcond{,u,eq} patterns

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116041

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |testsuite
   Keywords|missed-optimization |

--- Comment #1 from Andrew Pinski  ---
Actually I am wrong; I accidently removed vcond_mask .

bar1:

body: .*\tcmge  v[0-9]+.4s, v[0-9]+.4s, v[0-9]+.4s
\tbsl   v[0-9]+.16b, v[0-9]+.16b, v[0-9]+.16b
\tand   v[0-9]+.16b, v[0-9]+.16b, v[0-9]+.16b
.*

vs:

cmgev29.4s, v29.4s, v0.4s
bit v30.16b, v28.16b, v29.16b
and v30.16b, v30.16b, v31.16b

bar2:
body: .*\tcmge  v[0-9]+.4s, v[0-9]+.4s, v[0-9]+.4s
\tbsl   v[0-9]+.16b, v[0-9]+.16b, v[0-9]+.16b
.*

vs:
cmgev30.4s, v30.4s, v0.4s
bit v31.16b, v29.16b, v30.16b


the difference is bit vs bsl.
So this is just a testcase failure.

[Bug tree-optimization/116041] New: aarch64 fallout from removing vcond{,u,eq} patterns

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116041

Bug ID: 116041
   Summary: aarch64 fallout from removing vcond{,u,eq} patterns
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: internal-improvement, missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
Blocks: 114189
  Target Milestone: ---

>From PR 114189:

aarch64 reports just
``
FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar1
FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar2
```

When I removed the vcond support from aarch64, these testcases fail.

The reduced testcase is:
```
void bar1 (int * restrict a, int * restrict b, int * restrict c,
  int * restrict d, int * restrict res, int n)
{
  for (int i = 0; i < (n & -4); i++)
res[i] = ((a[i] < b[i]) & c[i]) | ((a[i] >= b[i]) & d[i]);
}
```

This fails to vectorize even.

>From the dump:
t1.c:4:21: note:   vect_is_simple_use: operand _4 < _6, type of def: internal
t1.c:4:21: note:   vect_is_simple_use: vectype vector(4) 
t1.c:4:21: note:   vect_is_simple_use: operand 1, type of def: constant
t1.c:4:21: note:   vect_is_simple_use: operand 0, type of def: constant
t1.c:1:6: missed:   not vectorized: relevant stmt not supported: patt_72 = _7 ?
1 : 0;
t1.c:4:21: missed:  bad operation or unsupported loop bound.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189
[Bug 114189] Target implements obsolete vcond{,u,eq} expanders

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Richard Biener from comment #4)
> > aarch64 reports just
> > 
> > FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar1
> > FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar2
> 
> I think these 2 are now fixed after the fixes for PR 115659.
> There is also missing andc/iorc patterns. 
> Which I am testing a change for them. I am doing it as part of using
> andc/iorc for scalars change due to be able to use them for vectors too.

Actually I take that back, these are no longer vectorized. 
Let me file that as a seperate issue.

[Bug rtl-optimization/116039] [15] rv64gc miscompile at -O3 with -fno-strict-aliasing since r15-1901-g98914f9eba5

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116039

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |rtl-optimization
 CC||pinskia at gcc dot gnu.org
   Target Milestone|--- |15.0

[Bug libstdc++/116038] ambiguous overload in bind_front caused by deducing this

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116038

--- Comment #2 from Andrew Pinski  ---
>A smaller reproduction without including the stdlib is:


While the original is accepted by clang, this one is rejected by clang. I have
not looked into why though.

[Bug c++/116038] ambiguous overload in bind_front caused by deducing this

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116038

Andrew Pinski  changed:

   What|Removed |Added

Summary|[14/15 Regression]  |ambiguous overload in
   |ambiguous overload in   |bind_front caused by
   |bind_front caused by|deducing this
   |deducing this   |

--- Comment #1 from Andrew Pinski  ---
deducing this was not part of GCC 13 so this can't be a regression.

[Bug middle-end/100395] Bogus -Wstringop-overflow warning

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100395

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/116034] [12/13/14/15 Regression] wrong code with memcpy() from _Complex unsigned short at -fno-strict-aliasing -O1 and above

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116034

--- Comment #8 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #7)
> Created attachment 58723 [details]
> gcc15-pr116034.patch
> 
> Full untested patch.

This looks good to me. This is basically the same as the patch which I was
coming up with too.

[Bug tree-optimization/116034] [12/13/14/15 Regression] wrong code with memcpy() from _Complex unsigned short at -fno-strict-aliasing -O1 and above

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116034

--- Comment #4 from Andrew Pinski  ---
I think the issue is in maybe_rewrite_mem_ref_base :
  else if (TREE_CODE (TREE_TYPE (sym)) == COMPLEX_TYPE
   && useless_type_conversion_p (TREE_TYPE (*tp),
 TREE_TYPE (TREE_TYPE (sym
{
  *tp = build1 (integer_zerop (TREE_OPERAND (*tp, 1))
? REALPART_EXPR : IMAGPART_EXPR,
TREE_TYPE (*tp), sym);
}


It only checks for 0 and non-zero rather than 0 and size (of type) like it is
done in gimple-fold.cc and fold-const.cc.

Which means it has been latent since r0-107202-g64a3d6470e5eb7 and exposed by
something started to be optimized in GCC 7.

[Bug tree-optimization/116034] [12/13/14/15 Regression] wrong code with memcpy() from _Complex unsigned short at -fno-strict-aliasing -O1 and above

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116034

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-07-22
   Target Milestone|--- |12.5
Summary|wrong code with memcpy()|[12/13/14/15 Regression]
   |from _Complex unsigned  |wrong code with memcpy()
   |short at|from _Complex unsigned
   |-fno-strict-aliasing -O1|short at
   |and above   |-fno-strict-aliasing -O1
   ||and above

--- Comment #3 from Andrew Pinski  ---
Confirmed.

Looks like the code that folds MEM[(charD.10 * {ref-all}) + 1B] into
REAL/IMAG is going wrong and should not have folded it into that. I have not
looked into why though.

[Bug tree-optimization/116034] wrong code with memcpy() from _Complex unsigned short at -fno-strict-aliasing -O1 and above

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116034

--- Comment #2 from Andrew Pinski  ---
Folding statement: _1 =  + 1;
Queued stmt for removal.  Folds to:  <__complex__ short unsigned int>
[(void *) + 1B]
Folding statement: _3 = MEM  [(char * {ref-all})_1];
Folded into: _3 = MEM  [(char * {ref-all}) + 1B];

That is ok, but then we change it into:
  _3 = IMAGPART_EXPR ;

[Bug target/114189] Target implements obsolete vcond{,u,eq} expanders

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114189

--- Comment #11 from Andrew Pinski  ---
(In reply to Richard Biener from comment #4)
> aarch64 reports just
> 
> FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar1
> FAIL: gcc.target/aarch64/if-compare_2.c check-function-bodies bar2

I think these 2 are now fixed after the fixes for PR 115659.
There is also missing andc/iorc patterns. 
Which I am testing a change for them. I am doing it as part of using andc/iorc
for scalars change due to be able to use them for vectors too.

[Bug target/115086] bic is not used when the non-not part is a constant

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115086

--- Comment #6 from Andrew Pinski  ---
Note andc optab was added with r15-1890-gf379596e0ba99d .

[Bug sanitizer/115793] signed integer overflow check missing at optimization levels -O2, -O3, and -Os

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115793

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #7 from Andrew Pinski  ---
.

[Bug sanitizer/116031] signed integer overflow check at optimization level -O3

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116031

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
  int32_t s;
  int32_t *n = 
  uint32_t o = 1912123656;
  c(*n >> (*l + (int32_t)o >= 0));

First off s is uninitialized. So it being 0 is valid and 0 shifted by any value
is still 0 so the overflow add is optimized away.

[Bug ipa/115033] [12/13/14/15 Regression] Incorrect optimization of by-reference closure fields by fre1 pass since r12-5113-gd70ef65692fced

2024-07-22 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115033

--- Comment #19 from Andrew Pinski  ---
(In reply to Jan Hubicka from comment #18)
> modref_eaf_analysis::analyze_ssa_name misinterprets EAF flags.  If
> dereferenced
> parameter is passed (to map_iterator in the testcase) it can be returned
> indirectly which in turn makes it to escape into the next function call.
> 
> I am testing:
> 
> diff --git a/gcc/ipa-modref.cc b/gcc/ipa-modref.cc
> index a5adce8ea39..a4e3cc34b4d 100644
> --- a/gcc/ipa-modref.cc
> +++ b/gcc/ipa-modref.cc
> @@ -2571,8 +2571,7 @@ modref_eaf_analysis::analyze_ssa_name (tree name, bool
> deferred)
> int call_flags = deref_flags
> (gimple_call_arg_flags (call, i), ignore_stores);
> if (!ignore_retval && !(call_flags & EAF_UNUSED)
> -   && !(call_flags & EAF_NOT_RETURNED_DIRECTLY)
> -   && !(call_flags & EAF_NOT_RETURNED_INDIRECTLY))
> +   && !(call_flags & (EAF_NOT_RETURNED_DIRECTLY ||
> EAF_NOT_RETURNED_INDIRECTLY)))

`||` looks wrong, I suspect it should be `|`.

>   merge_call_lhs_flags (call, i, name, false, true);
> if (ecf_flags & (ECF_CONST | ECF_NOVOPS))
>   m_lattice[index].merge_direct_load ();

[Bug rtl-optimization/116027] Redundant backup and restore of register with -flive-range-shrinkage

2024-07-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116027

--- Comment #1 from Andrew Pinski  ---
-O2 -mpreferred-stack-boundary=3 -flive-range-shrinkage

[Bug target/116021] Ada build on Darwin: gen_il-main: Symbol not found: ___builtin_nested_func_ptr_created

2024-07-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116021

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Andrew Pinski  ---
This is a won't fix. Using an unreleased compiler before the ABI change to do a
bootstrap is not supported. There was a flag day in this case where it would
break. any before that date but after the day which added the option to use
heap based trampolines is not supported for bootstrap after that day. Only ones
without heap based trampolines and the ones with the supported ABI.

[Bug sanitizer/116026] Copying or moving a std::variant that can be a vector causes a maybe-uninitialized warning with -fsanitize=address -Og -finline-functions-called-once

2024-07-21 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116026

--- Comment #1 from Andrew Pinski  ---
Note the documentation warns about this case
https://gcc.gnu.org/onlinedocs/gcc-14.1.0/gcc/Instrumentation-Options.html#index-fsanitize_003daddress

Note that sanitizers tend to increase the rate of false positive warnings, most
notably those around -Wmaybe-uninitialized. We recommend against combining
-Werror and [the use of] sanitizers.

  1   2   3   4   5   6   7   8   9   10   >