[Bug rtl-optimization/18446] We need to distinguish value extension and value truncation

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18446

--- Comment #3 from Andrew Pinski  ---
The gimple (tree) Level should be all well defined as we use abstract machine
to define it and there are no zero or sign extend dealing with upper bits that
are not part of the original program.

For the RTL level, it is slightly different but we don't do as much loop
optimizations there except for pull things out of the loop and some unrolling.

[Bug rtl-optimization/101076] RTL Combine pass won't generate sign_extnd RTX in some senario

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101076

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Ever confirmed|0   |1
   Last reconfirmed|2021-06-15 00:00:00 |2023-06-02
 Status|UNCONFIRMED |NEW

--- Comment #6 from Andrew Pinski  ---
I remember running into this issue with MIPS too.

There we got:

(set (reg:SI 197 [ aD.2145 ])
(ashiftrt:SI (truncate:SI (ashift:DI (reg:DI 199)
(const_int 16 [0x10])))
(const_int 16 [0x10])))

Or even worse:

(set (reg/i:DI 2 $2)
(sign_extend:DI (ashiftrt:SI (truncate:SI (ashift:DI (reg:DI 199)
(const_int 16 [0x10])))
(const_int 16 [0x10]

[Bug fortran/109358] Wrong formatting with T-descriptor during stream output

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358

--- Comment #7 from Steve Kargl  ---
On Fri, Jun 02, 2023 at 01:51:02AM +, jvdelisle at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358
> 
> Jerry DeLisle  changed:
> 
>What|Removed |Added
> 
>  Status|NEW |ASSIGNED
> 
> --- Comment #6 from Jerry DeLisle  ---
> I have been doing some additional checking and tried this. It is a variation
> which is not STREAM related:
> 
> program tabs
>   implicit none
>   integer :: fd
>   open(newunit=fd, file="test.txt", form="formatted")
>   write(fd, "(a)") "12345678901234567890123456789"
>   write(fd, "(i4, t25, t2, i4.4)") 1234, 0123
>   close(fd)
> end program tabs
> 
> With gfortran gcc 10.4.1 20230121 (GCC)
> 
> $ gfc10 -static -o tabs.x tabs.f90
> $ ./tabs.x 
> $ cat test.txt 
> 12345678901234567890123456789
> 12340123
> 
> It seems to me this should be:
> 
> 10123
> 
> Am I wrong?
> 

I think you're right.  t25 will position you 25 spaces
from the left tab limit and then you get repositioned
with t2 by 2 spaces from the left tab limit.

[Bug rtl-optimization/100080] missed optimization for dead code elimination at -O3 (vs. -O2)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100080

--- Comment #2 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> Confirmed.  At -O2 combine manages to drop the call to foo () (indirectly),
> at -O3 it does not.  There's not much difference on the GIMPLE level

For the gimple level it comes down to:
  _5 = (unsigned int) l_20(D);
  if (_5 > 1)
goto ; [50.00%]
  else
goto ; [50.00%]

What should we do there, l_20(D) is definitely uninitialized?
We even get a warning about it:

In function 'e',
inlined from 'main' at :17:5:
:9:20: warning: 'l' may be used uninitialized [-Wmaybe-uninitialized]
9 |   d = c >= (*j = b | *k) && b & (*i == 0);
  |  ~~^~~~
: In function 'main':
:16:9: note: 'l' was declared here
   16 | int l;
  | ^

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 66489, which changed state.

Bug 66489 Summary: combine fails to merge insns if some are reused later on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66489

   What|Removed |Added

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

[Bug rtl-optimization/66489] combine fails to merge insns if some are reused later on

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66489

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85160
 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |9.0

--- Comment #6 from Andrew Pinski  ---
Fixed in GCC 9 with 2->2 combing being done now (r9-2064-gc4c5ad1d6d1e1e1fe7a):

Trying 11 -> 12:
   11: r96:SI=-r115:SI
  REG_DEAD r115:SI
   12: r108:SI=r96:SI*r103:SI
Failed to match this instruction:
(parallel [
(set (reg:SI 108)
(mult:SI (neg:SI (reg:SI 115))
(reg/v:SI 103 [ cD.4384 ])))
(set (reg/v:SI 96 [ aD.4382 ])
(neg:SI (reg:SI 115)))
])
Failed to match this instruction:
(parallel [
(set (reg:SI 108)
(mult:SI (neg:SI (reg:SI 115))
(reg/v:SI 103 [ cD.4384 ])))
(set (reg/v:SI 96 [ aD.4382 ])
(neg:SI (reg:SI 115)))
])
Successfully matched this instruction:
(set (reg/v:SI 96 [ aD.4382 ])
(neg:SI (reg:SI 115)))
Successfully matched this instruction:
(set (reg:SI 108)
(mult:SI (neg:SI (reg:SI 115))
(reg/v:SI 103 [ cD.4384 ])))
allowing combination of insns 11 and 12
original costs 4 + 12 = 16
replacement costs 4 + 12 = 16
modifying insn i211: r96:SI=-r115:SI
deferring rescan insn with uid = 11.
modifying insn i312: r108:SI=-r115:SI*r103:SI
  REG_DEAD r115:SI
deferring rescan insn with uid = 12.

[Bug rtl-optimization/88403] The gcse and division/mod by 1000 prevents if-conversion

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88403

Andrew Pinski  changed:

   What|Removed |Added

 Target|mips, aarch64   |mips, aarch64 x86_64
Summary|[Mips,AArch64] The gcse and |The gcse and division/mod
   |division/mod by 1000|by 1000 prevents
   |prevents if-conversion  |if-conversion

--- Comment #2 from Andrew Pinski  ---
With my reduced testcase, x86_64 has the same issue too.

[Bug rtl-optimization/88403] [Mips,AArch64] The gcse and division/mod by 1000 prevents if-conversion

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88403

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-02
   Severity|normal  |enhancement
 Ever confirmed|0   |1
Summary|[Mips,AArch64] The gcse |[Mips,AArch64] The gcse and
   |prevents if-conversion  |division/mod by 1000
   ||prevents if-conversion
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.
GCSE is doing the right thing, just ifcvt can't handle this currently.

Here is a reduced testcase:
```
int f(int a, int b)
{
if (a % 1 > 1/2)
  a+= 1/2;
return a / 1;
}
```

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

[linkw at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108699

Kewen Lin  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Kewen Lin  ---
(In reply to Peter Bergner from comment #8)
> Can this be marked as FIXED or is there more to do?

Yeah, the issue should be fixed everywhere, thanks for reminding!

[Bug target/103498] Spec 2017 imagick_r is 2.62% slower on Power10 with pc-relative addressing compared to not using pc-relative addressing

[meissner at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103498

Michael Meissner  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Michael Meissner  ---
I just ran spec 2017 on a Power10 machine running RHEL 8, using the GCC 13.1
GCC and the Advance Toolchain 15.0 library.  In that run, I see no significant
(more than 1%) regressions if we use -mno-pcrel.  In fact, imagick_r was nearly
2% faster using PC-relative addressing.

[Bug target/108699] gcc.c-torture/execute/builtin-bitops-1.c fails on power 9 BE

[bergner at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108699

--- Comment #8 from Peter Bergner  ---
Can this be marked as FIXED or is there more to do?

[Bug rtl-optimization/102733] missing fs:0 store when followed by one to gs:0

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102733

--- Comment #6 from Andrew Pinski  ---
Created attachment 55238
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55238=edit
Patch which I will be testing

This adds a check for the address space in DSE.

Even tested:
```
void test_null_store_fs_gs (void)
{
  int __seg_fs *fs = (int __seg_fs *)0;
  *fs = 1; 

  int __seg_gs *gs = (int __seg_gs *)0;
  *gs = 2;  
  *fs = 3; 
}
```

And only 2/3 are emitted (in that order) which is the correct DSE even.

[Bug ipa/110057] Missed devirtualization opportunities

[yongxiangng at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057

--- Comment #6 from Ng YongXiang  ---
That is interesting. Thanks for the reply.

However, I'd argue that the 2 bugs mentioned are different from what I am
proposing. The 2 bugs linked access virtual functions via ptr (delete p;
val->f();) and are invoked by the user directly, and so I think it makes sense
for the compiler to access the vtable. 

However, the array issue I'm putting forth is caused by the destruction of the
array with automatic storage duration, and the destruction code is generated by
the compiler not by the user via some kind of ptr or reference.

Moreover, clang does it right and devirtualizes the destruction of the array
while gcc still doesn't.

https://godbolt.org/z/f33Gh5EGM

#include 
#include 

struct A
{
A()
{
std::cout << "A()" << std::endl;
}
virtual ~A() 
{
std::cout << "~A()" << std::endl;
}
};

struct B : public  A
{
B()
{
std::cout << "B()" << std::endl;
}
virtual ~B()
{
std::cout << "~B()" << std::endl;
}
};

int main()
{
A a[3];
a[0].~A();
:: new(std::addressof(a[0])) B();
}

[Bug c++/110084] [12/13/14 Regression] defaulted constexpr operator== causes crash

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110084

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |12.4
Summary|defaulted constexpr |[12/13/14 Regression]
   |operator== causes crash |defaulted constexpr
   ||operator== causes crash
   Last reconfirmed||2023-06-02

--- Comment #1 from Andrew Pinski  ---
Confirmed. I suspect r12-4202-g09d886e671f2230a caused the issue ...

[Bug rtl-optimization/102733] missing fs:0 store when followed by one to gs:0

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102733

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

--- Comment #5 from Andrew Pinski  ---
I think I have a fix.

[Bug c++/110084] New: defaulted constexpr operator== causes crash

[nikolasklauser at berlin dot de via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110084

Bug ID: 110084
   Summary: defaulted constexpr operator== causes crash
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nikolasklauser at berlin dot de
  Target Milestone: ---

template 
class BadTuple {
  constexpr bool operator==(const BadTuple&) const;
};
template
constexpr bool BadTuple::operator==(const BadTuple&) const = default;

BadTuple a;

causes GCC to crash.

https://godbolt.org/z/veG6hEeP3

[Bug target/103498] Spec 2017 imagick_r is 2.62% slower on Power10 with pc-relative addressing compared to not using pc-relative addressing

[bergner at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103498

--- Comment #3 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #2)
> Mike, do you still see this?

Ping again.  Is this still an issue?

[Bug rtl-optimization/52490] RTL DCE removes trapping const libcalls

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52490

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.5
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

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

[Bug rtl-optimization/52490] RTL DCE removes trapping const libcalls

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52490

--- Comment #3 from Andrew Pinski  ---
Fixed for GCC 7.5.0, GCC 8.3.0 and GCC 9+ by the patch which fixed PR 89188.

[Bug target/96762] ICE in extract_insn, at recog.c:2294 (error: unrecognizable insn)

[bergner at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96762

Peter Bergner  changed:

   What|Removed |Added

   Assignee|acsawdey at gcc dot gnu.org|unassigned at gcc dot 
gnu.org
 CC||bergner at gcc dot gnu.org

--- Comment #4 from Peter Bergner  ---
Aaron isn't working on GCC anymore, so unassigning him.

[Bug target/89188] ICE in pre_and_rev_post_order_compute, at cfganal.c:1055

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89188

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |7.5
  Known to work||7.5.0, 8.3.0, 9.1.0

[Bug rtl-optimization/52490] RTL DCE removes trapping const libcalls

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52490

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||6.4.0, 7.4.0, 8.1.0
  Known to work||7.5.0, 8.2.0

--- Comment #2 from Andrew Pinski  ---
You need also -fno-delete-dead-exceptions not to remove them in newer versions
for the gimple level.

[Bug rtl-optimization/52490] RTL DCE removes trapping const libcalls

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52490

--- Comment #1 from Andrew Pinski  ---
Starting in GCC 12, the addition is removed at the gimple level.

[Bug target/110083] [14 Regression] ICEs for testcase on fp-int-convert*timode after r14-1466-g3635e8c67e1

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110083

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
   Keywords||ice-on-valid-code

[Bug target/110083] New: [14 Regression] ICEs for testcase on fp-int-convert*timode after r14-1466-g3635e8c67e1

[haochen.jiang at intel dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110083

Bug ID: 110083
   Summary: [14 Regression] ICEs for testcase on
fp-int-convert*timode after r14-1466-g3635e8c67e1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haochen.jiang at intel dot com
  Target Milestone: ---

Currently we get testcase regressions following:

https://gcc.gnu.org/pipermail/gcc-regression/2023-June/077808.html

I checked my bisect script, at least for fp-int-convert-timode.c, it points to
commit r14-1466-g3635e8c67e1 when using -march=cascadelake.

Actually, it will cause ICEs when using -msse4 and higher ISA set.

I reproduce it by:

/export/users/haochenj/env/build_no_bootstrap_master/gcc/xgcc
-B/export/users/haochenj/env/build_no_bootstrap_master/gcc/
/export/users/haochenj/src/gcc/master/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode.c
-m64 -msse4 -fdiagnostics-plain-output -O2 -lm -o ./fp-int-convert-timode.exe

with backtrace:

during RTL pass: cse2
/export/users/haochenj/src/gcc/master/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode.c:
In function ‘main’:
/export/users/haochenj/src/gcc/master/gcc/testsuite/gcc.dg/torture/fp-int-convert-timode.c:22:1:
internal compiler error: in as_a, at machmode.h:381
0xcc405f scalar_mode as_a(machine_mode)
/export/users/haochenj/src/gcc/master/./gcc/machmode.h:381
0xf9eb33 wi::int_traits
>::get_precision(std::pair const&)
/export/users/haochenj/src/gcc/master/./gcc/rtl.h:2282
0xfb7fce unsigned int wi::get_precision
>(std::pair const&)
/export/users/haochenj/src/gcc/master/./gcc/wide-int.h:1795
0xfb21aa wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/export/users/haochenj/src/gcc/master/./gcc/wide-int.h:1029
0xfa7c7c generic_wide_int
>::generic_wide_int >(std::pair const&)
/export/users/haochenj/src/gcc/master/./gcc/wide-int.h:787
0x103f74b poly_int<1u, generic_wide_int >
>::poly_int >(std::pair const&)
/export/users/haochenj/src/gcc/master/./gcc/poly-int.h:670
0x103ef15 wi::to_poly_wide(rtx_def const*, machine_mode)
/export/users/haochenj/src/gcc/master/./gcc/rtl.h:2382
0x1558c20 neg_poly_int_rtx
/export/users/haochenj/src/gcc/master/./gcc/simplify-rtx.cc:57
0x156521c simplify_context::simplify_binary_operation_1(rtx_code, machine_mode,
rtx_def*, rtx_def*, rtx_def*, rtx_def*)
/export/users/haochenj/src/gcc/master/./gcc/simplify-rtx.cc:3171
0x1562b50 simplify_context::simplify_binary_operation(rtx_code, machine_mode,
rtx_def*, rtx_def*)
/export/users/haochenj/src/gcc/master/./gcc/simplify-rtx.cc:2641
0xfcbd31 simplify_binary_operation(rtx_code, machine_mode, rtx_def*, rtx_def*)
/export/users/haochenj/src/gcc/master/./gcc/rtl.h:3485
0x15730be simplify_const_relational_operation(rtx_code, machine_mode, rtx_def*,
rtx_def*)
/export/users/haochenj/src/gcc/master/./gcc/simplify-rtx.cc:6173
0x1571a01 simplify_context::simplify_relational_operation(rtx_code,
machine_mode, machine_mode, rtx_def*, rtx_def*)
/export/users/haochenj/src/gcc/master/./gcc/simplify-rtx.cc:5759
0xf0607d simplify_relational_operation(rtx_code, machine_mode, machine_mode,
rtx_def*, rtx_def*)
/export/users/haochenj/src/gcc/master/./gcc/rtl.h:3500
0x29418dd fold_rtx
/export/users/haochenj/src/gcc/master/./gcc/cse.cc:3487
0x2940e75 fold_rtx
/export/users/haochenj/src/gcc/master/./gcc/cse.cc:3227
0x29443e9 cse_insn
/export/users/haochenj/src/gcc/master/./gcc/cse.cc:4667
0x29498ce cse_extended_basic_block
/export/users/haochenj/src/gcc/master/./gcc/cse.cc:6566
0x2949ddd cse_main
/export/users/haochenj/src/gcc/master/./gcc/cse.cc:6711
0x294c0c6 rest_of_handle_cse2
/export/users/haochenj/src/gcc/master/./gcc/cse.cc:7609

[Bug rtl-optimization/91838] [8/9 Regression] incorrect use of shr and shrx to shift by 64, missed optimization of vector shift

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91838

--- Comment #16 from Andrew Pinski  ---
So the testcase g++.dg/opt/pr91838.C depends on the out come of the discussion
at:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620378.html

Which I think is saying this testcase is undefined really.

[Bug rtl-optimization/56451] [10/11/12/13/14 regression] Wrong code for gcc.c-torture/execute/941015-1.c on SH

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56451

--- Comment #19 from Andrew Pinski  ---
Maybe fixed via PR 83496 ?

[Bug fortran/109358] Wrong formatting with T-descriptor during stream output

[jvdelisle at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #6 from Jerry DeLisle  ---
I have been doing some additional checking and tried this. It is a variation
which is not STREAM related:

program tabs
  implicit none
  integer :: fd
  open(newunit=fd, file="test.txt", form="formatted")
  write(fd, "(a)") "12345678901234567890123456789"
  write(fd, "(i4, t25, t2, i4.4)") 1234, 0123
  close(fd)
end program tabs

With gfortran gcc 10.4.1 20230121 (GCC)

$ gfc10 -static -o tabs.x tabs.f90
$ ./tabs.x 
$ cat test.txt 
12345678901234567890123456789
12340123

It seems to me this should be:

10123

Am I wrong?

[Bug rtl-optimization/58517] ifcvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2013-10-05 00:00:00 |2023-6-1

--- Comment #10 from Andrew Pinski  ---
Note the wrong code can be still reproduced in GCC 13 too.

[Bug rtl-optimization/58517] ifcvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517

--- Comment #9 from Andrew Pinski  ---
The reason why r6-3654-g6b7e867187889 didn't fix this case is because it was
not looking into clobbers only the set side. 

Note the conditional in my patch should have been
if (reg_overlap_mentioned_p (DF_REF_REG (def), cond))

Maybe it should be bb_valid_for_noce_process_p instead, I am not 100% sure on
that.

[Bug rtl-optimization/58517] ifcvt (after combine) puts ccreg clobbering insn between ccset insn and ccreg use

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58517

--- Comment #8 from Andrew Pinski  ---
Created attachment 55237
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55237=edit
Patch which I think will fix this

This is option 1 of comment #3 though with an updated version.
I have not tested this at all but I think it will work.

[Bug target/104698] Inefficient code for DI to TI sign extend on power10

[bergner at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104698

--- Comment #5 from Peter Bergner  ---
Mike, are we doing backports of this?  ...or can we marked this as FIXED?

[Bug rtl-optimization/40987] ifcvt sometimes goes wrong for integer modes > 64bit

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40987

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |4.9.0

--- Comment #14 from Andrew Pinski  ---
Looks like this was fixed with r0-127324-ge15eb172b0dd (aka PR 59545).
Basically a signed integer overflow inside the compiler was causing the wrong
code happening.

[Bug rtl-optimization/40987] ifcvt sometimes goes wrong for integer modes > 64bit

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40987

--- Comment #13 from Andrew Pinski  ---
Here is a x86_64-linux-gnu testcase:
```
#include 

typedef __int128_t mytype;
#define value (((__int128_t)(((unsigned long long)__LONG_LONG_MAX__)+1)) |
(((__int128_t)0xull)<<64))

mytype func(long arg) __attribute__((noinline,noclone));
mytype func(long arg) {
   mytype val = 0;
   if (arg < 0) {
// __int128_t t = 0x8000ull |
(((__int128_t)0x)<<64);
  val = value;
   }
   return val;
}

int main() {
   mytype result = func(-1);
   if (result != value) {
  printf("failed.\n");
  return 1;
   } 
   printf("passed.\n");
   return 0;
}
```

It failed until GCC 4.9.0

[Bug middle-end/31542] Incorrect optization with nan values

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31542

--- Comment #4 from Andrew Pinski  ---
I can't reproduce this in any recent versions of GCC. Even in GCC 4.7.3 and GCC
4.6.4 it works and we get no assert.

[Bug middle-end/29253] expand_abs wrong default code for floating point

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29253

Andrew Pinski  changed:

   What|Removed |Added

  Attachment #55235|0   |1
is obsolete||

--- Comment #14 from Andrew Pinski  ---
Created attachment 55236
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55236=edit
Updated patch which I did some light testing on powerpc64-linux-gnu (with
-msoft-float)

I updated the patch because I noticed that we need to move the result of the
libcall to a temp register otherwise it might be removed.

I tested all of the testcases in this bug report with  -mlong-double-128
-msoft-float and we get the call to absl in the assembly output and they all
look correct.

[Bug middle-end/29253] expand_abs wrong default code for floating point

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=29253

--- Comment #13 from Andrew Pinski  ---
Created attachment 55235
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55235=edit
Slightly different patch

This is a slightly different patch but it basically does the same except it
uses emit_library_call_value instead of creating trees to the expanding.

[Bug libstdc++/109947] std::expected monadic operations do not support move-only error types yet

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109947

Jonathan Wakely  changed:

   What|Removed |Added

 Status|SUSPENDED   |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |13.2

--- Comment #8 from Jonathan Wakely  ---
The LWG issue has been moved to Tentatively Ready status by LWG, and should get
approved by the full committee in two weeks.

I've implemented the proposed resolution in GCC trunk as
r14-1471-gfe94f8b7e022b7 and will backport that to the gcc-13 branch too.

[Bug libstdc++/109758] std::abs(__float128) doesn't support NaN

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|14.0|13.2

--- Comment #16 from Jonathan Wakely  ---
Backported for 13.2 now

[Bug libstdc++/109758] std::abs(__float128) doesn't support NaN

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109758

--- Comment #15 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:099d469df67d8454aa393d036f4791912364bd4d

commit r13-7406-g099d469df67d8454aa393d036f4791912364bd4d
Author: Jonathan Wakely 
Date:   Wed May 10 12:20:58 2023 +0100

libstdc++: Fix std::abs(__float128) for -NaN and -0.0 [PR109758]

The current implementation of this non-standard overload of std::abs
incorrectly returns a negative value for negative NaNs and negative
zero, because x < 0 is false in both cases.

Use fabsl(long double) or fabsf128(_Float128) if those do the right
thing.  Otherwise, use __builtin_signbit(x) instead of x < 0 to detect
negative inputs. This assumes that __builtin_signbit handles __float128
correctly, but that seems to be true for all of GCC, clang and icc.

libstdc++-v3/ChangeLog:

PR libstdc++/109758
* include/bits/std_abs.h (abs(__float128)): Handle negative NaN
and negative zero correctly.
* testsuite/26_numerics/headers/cmath/109758.cc: New test.

(cherry picked from commit af595613acbd9863198ae69c7b1c9e856bca9e4f)

[Bug target/109972] RISC-V: Could use umodsi3/udivsi3/divsi3 libcalls for 32-bit division/remainder on RV64 without M extension

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109972

--- Comment #2 from Andrew Pinski  ---
(In reply to palmer from comment #1)
> Thanks.  Craig and I had talked about this offline, it looks like a real
> improvement to me.  We're not super worried about rv32 or code size, maybe
> Kito is?

I am care about RV32 code quality though the core I am working with has the M
extension so this case is not as important to me.

[Bug target/109972] RISC-V: Could use umodsi3/udivsi3/divsi3 libcalls for 32-bit division/remainder on RV64 without M extension

[palmer at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109972

palmer at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||palmer at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-01
   Severity|normal  |enhancement

--- Comment #1 from palmer at gcc dot gnu.org ---
Thanks.  Craig and I had talked about this offline, it looks like a real
improvement to me.  We're not super worried about rv32 or code size, maybe Kito
is?

[Bug fortran/88552] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88552

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |14.0

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed for gcc-14.  Closing.

Thanks for the report!

[Bug fortran/88552] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88552

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:ff8f45d20f9ea6acc99442ad29212d177f58e8fe

commit r14-1477-gff8f45d20f9ea6acc99442ad29212d177f58e8fe
Author: Harald Anlauf 
Date:   Thu Jun 1 23:04:30 2023 +0200

Fortran: force error on bad KIND specifier [PR88552]

gcc/fortran/ChangeLog:

PR fortran/88552
* decl.cc (gfc_match_kind_spec): Use error path on missing right
parenthesis.
(gfc_match_decl_type_spec): Use error return when an error occurred
during matching a KIND specifier.

gcc/testsuite/ChangeLog:

PR fortran/88552
* gfortran.dg/pr88552.f90: New test.

[Bug target/54089] [SH] Refactor shift patterns

[olegendo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089

--- Comment #53 from Oleg Endo  ---
(In reply to Segher Boessenkool from comment #52)
> 
> There is TARGET_LEGITIMATE_COMBINED_INSN though, which is a workaround for if
> you really do not want the instruction combiner to create particular
> instruction patterns (but it does nothing to prevent other parts of the
> compiler from doing the same!)

Thanks for pointing it out.  I knew I missed something recent ;)

[Bug fortran/100607] ICE with SELECT RANK

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607

--- Comment #8 from Steve Kargl  ---
On Thu, Jun 01, 2023 at 07:26:43PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607
> 
> --- Comment #7 from anlauf at gcc dot gnu.org ---
> (In reply to kargl from comment #6)
> > Created attachment 55191 [details]
> > patch that fixes bug
> > 
> > The patch, which was previously submitted, still applies and fixes the bug.
> 
> Sure.
> 
> Do you have an answer to your own remarks in comment#5?
> 

I've concluded that the bug was reported 2 years agos.
It was fixed by a tentative patch 2 years laters.

'case_value == -1' is for 'rank(*)'.

'case_value == -2' appears to be for non-'rank(*)' cases,
and those are handled in the preceding nested for-loop.

[Bug target/101544] [OpenMP][AMDGCN][nvptx] C++ offloading: unresolved _Znwm = "operator new(unsigned long)"

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101544

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords||openacc
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

[Bug fortran/100607] ICE with SELECT RANK

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100607

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #6)
> Created attachment 55191 [details]
> patch that fixes bug
> 
> The patch, which was previously submitted, still applies and fixes the bug.

Sure.

Do you have an answer to your own remarks in comment#5?

[Bug gcov-profile/110082] New: Coverage analysis vs. offloading compilation

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110082

Bug ID: 110082
   Summary: Coverage analysis vs. offloading compilation
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openacc, openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, jakub at gcc dot gnu.org,
marxin at gcc dot gnu.org, rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: amdgcn-amdhsa, nvptx-none

(Via a customer report) we've determined that offloading compilation fails in
combination with '-fprofile-arcs' (as implied by '--coverage', coverage
analysis):

: error: variable ‘__gcov0.main._omp_fn.0’ has been referenced in
offloaded code but hasn’t been marked to be included in the offloaded code
lto1: fatal error: errors during merging of translation units
compilation terminated.
nvptx mkoffload: fatal error:
build-gcc/gcc/x86_64-pc-linux-gnu-accel-nvptx-none-gcc returned 1 exit status
[...]

Per my quick look, during early host compilation, via
'gcc/tree-profile.cc:gimple_gen_edge_profiler', via 'pass_ipa_tree_profile', as
visible in '*.069i.profile', '__atomic_fetch_add_8 (&__gcov0.main._omp_fn.0[0],
1, 0);' etc. statements are added.  (Or, different statements in case that the
target cannot "utilize atomic update operations", or 'PROFILE_UPDATE_SINGLE' is
used.)

That's part of the IPA passes, so before offloading compilation split-off. 
(... as per the error, evidently).

As we've got no mechanism implemented currently to move any device-side
coverage data from the device execution back to the host, and integrate it with
the host-side coverage data, we propose to not do coverage analysis for
offloading compilation.

My idea is to abstract the "increment the edge execution count" operations into
some new GIMPLE/IFN code (?), and then later, once the offloading code has been
split off, lower it to the current form (host-side), or no-op (device-side). 
I'd appreciate a quick review if that approach makes sense?

---

We've seen and dealt with a few already, over the past decade, but still more
such similar issues certainly exist for other scenarios where GCC "early"
(before the offloading code split-off) does code transformations that device
compilation may choke on, and thus has to explicitly handle.  A full review of
GCC "early" transformations doesn't seem feasible, so we shall continue
addressing these incrementally, as encountered.

For another example (that I shall soon be working on), see
.

[Bug fortran/88552] ICE in gfc_typenode_for_spec, at fortran/trans-types.c:1120

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88552

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-June/059358.html

[Bug fortran/110076] ICE on mutually recursive derived types.

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110076

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-01
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  I believe I've seen another duplicate where running under gdb
shows that we enter an infinite loop in gfc_get_derived_type:

(gdb) l 2731,2753
2731  /* Go through the derived type components, building them as
2732 necessary. The reason for doing this now is that it is
2733 possible to recurse back to this derived type through a
2734 pointer component (PR24092). If this happens, the fields
2735 will be built and so we can return the type.  */
2736  for (c = derived->components; c; c = c->next)
2737{
2738  bool same_alloc_type = c->attr.allocatable
2739 && derived == c->ts.u.derived;
2740
2741  if (c->ts.type == BT_UNION && c->ts.u.derived->backend_decl ==
NULL)
2742c->ts.u.derived->backend_decl = gfc_get_union_type
(c->ts.u.derived);
2743
2744  if (c->ts.type != BT_DERIVED && c->ts.type != BT_CLASS)
2745continue;
2746
2747  if ((!c->attr.pointer && !c->attr.proc_pointer
2748  && !same_alloc_type)
2749  || c->ts.u.derived->backend_decl == NULL)
2750{
2751  int local_codim = c->attr.codimension ? c->as->corank:
codimen;
2752  c->ts.u.derived->backend_decl = gfc_get_derived_type
(c->ts.u.derived,
2753   
local_codim);

[Bug c++/110000] GCC should implement exclude_from_explicit_instantiation

[ldionne.2 at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=11

--- Comment #13 from Louis Dionne  ---
Nikolas already answered some, but just to expand on this:

> But on the topic of this enhancement request, I don't see why functions 
> should be excluded from explicit instantiation if they're already abi-tagged. 
> Do you want to be able to change these functions in ABI-incompatible ways 
> between major revisions of the library?

What we're trying to avoid here is that if a user has an explicit instantiation
*declaration*, we don't want their code to start depending on the fact that
some-implementation-detail-member-function exists in the class. So for example,
if we have:

  template 
  class vector {
  public:
iterator begin() { ... }
iterator end() { ... }

void __push_back_helper(T const&) { ... }
  };

If the user has something like this in their code:

  extern template class vector;

The compiler will then assume that the following methods are defined elsewhere
(presumably where the explicit instantiation actually happens):

iterator vector::begin();
iterator vector::end();
void vector::__push_back_helper(Foo const&);

Whether those methods are ABI-tagged or not doesn't matter, the compiler will
still emit code that contains external references to those methods. That's fine
if we're OK with committing to these methods in the long term, but if we want
to keep the flexibility of removing or changing these methods in arbitrary
ways, what we really want here is for the compiler not to assume that the
explicit instantiation includes these methods, and instead emit its own
linkonce_odr copy in the TU (which then gets deduplicated across TUs in case
the same function was defined elsewher too).

Does this make sense?

Regarding ABI tags, like Nikolas explained, the idea is that in most cases,
users actually have a single version of libc++ in their whole program, so all
the symbols from libc++ have the same ABI tag, and the linker will deduplicate
everything. In case a users happens to mix versions of libc++ in different TUs,
then the right thing will happen: functions with different ABI tags won't be
deduplicated as-if they were token-for-token equivalent and only the functions
that don't have an ABI tag will be deduplicated cause they're the same across
all TUs (but we do commit to stability for those symbols).

[Bug fortran/110081] Unhelpful error message: "(null):0: confused by earlier errors, bailing out"

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110081

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Duplicate of pr103259, which is fixed in 12.3 and newer.

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

[Bug fortran/103259] [11/12/13 Regression] ICE in resolve_common_vars, at fortran/resolve.c:956 since r11-3866-g4d2a56a0f7135469

[anlauf at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103259

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||andrew at fluidgravity dot 
co.uk

--- Comment #10 from anlauf at gcc dot gnu.org ---
*** Bug 110081 has been marked as a duplicate of this bug. ***

[Bug target/54089] [SH] Refactor shift patterns

[segher at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089

--- Comment #52 from Segher Boessenkool  ---
(In reply to Alexander Klepikov from comment #50)
> But maybe there is a way to exclude particular insn from combine pass? (I
> guess not).

In general, it is best to let combine just work on everything.  It will not
replace instructions if the replacement is more expensive, and it will only
ever create instruction sequences with the same semantics as what it started
with.

There is TARGET_LEGITIMATE_COMBINED_INSN though, which is a workaround for if
you really do not want the instruction combiner to create particular
instruction patterns (but it does nothing to prevent other parts of the
compiler from doing the same!)

[Bug debug/110073] [14 regression] btfout.cc format errors break bootstrap

[david.faust at oracle dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110073

--- Comment #1 from David Faust  ---
Created attachment 55234
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55234=edit
alternate proposed patch

Thank you for catching this, and for the fix!

With the proposed patch on linux x86_64 I see the following:

../../../gcc/gcc/btfout.cc: In function ‘void
btf_asm_func_type(ctf_container_ref, ctf_dtdef_ref, size_t)’:
../../../gcc/gcc/btfout.cc:952:31: warning: format ‘%u’ expects argument of
type ‘unsigned int’, but argument 4 has type ‘size_t’ {aka ‘long unsigned int’}
[-Wformat=]
  952 |"TYPE %u BTF_KIND_FUNC '%s'",
  |  ~^
  |   |
  |   unsigned int
  |  %lu
  953 |num_types_added + num_vars_added + 1 + i,
  |
  | |
  | size_t {aka
long unsigned int}

I believe %zu instead of %u should work.

Alternatively, a small refactor to the offending code makes it behave in line
with the other functions (to properly use a ctf_id_t, and then PRIu64 as in
your patch). But I haven't verified this on solaris/x86 yet.

[Bug libstdc++/77704] Data race on std::ctype

[dboles.src at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77704

Daniel Boles  changed:

   What|Removed |Added

 CC||dboles.src at gmail dot com

--- Comment #7 from Daniel Boles  ---
Yup, I too was just bitten by this, with libstdc++ 9.4.0-1ubuntu1~20.04.1

Luckily the Thread Sanitizer finally led me to the diagnosis, and many thanks
to Boris for posting his workaround, which I can confirm seems to fix it for me
too

[Bug testsuite/109951] [14 Regression] libgomp, testsuite: non-native multilib c++ tests fail on Darwin.

[tschwinge at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109951

Thomas Schwinge  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=91884
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tschwinge at gcc dot 
gnu.org

[Bug tree-optimization/110051] error: writing 1 byte into a region of size 0

[pkurash at cern dot ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110051

--- Comment #3 from Felix  ---
Yes, you're right, the warning is turned to error.

Without this option the compilation runs normally

[Bug libstdc++/110060] [14 Regression] Adding optimizer hints to std::vector causes a new -Wstringop-overread false positive

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #10 from Jonathan Wakely  ---
Fixed

[Bug middle-end/97048] [meta-bug] bogus/missing -Wstringop-overread warnings

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97048
Bug 97048 depends on bug 110060, which changed state.

Bug 110060 Summary: [14 Regression] Adding optimizer hints to std::vector 
causes a new -Wstringop-overread false positive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

[Bug libstdc++/110060] [14 Regression] Adding optimizer hints to std::vector causes a new -Wstringop-overread false positive

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110060

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:b7b255e77a271974479c34d1db3daafc04b920bc

commit r14-1470-gb7b255e77a271974479c34d1db3daafc04b920bc
Author: Jonathan Wakely 
Date:   Thu Jun 1 10:26:10 2023 +0100

libstdc++: Fix code size regressions in std::vector [PR110060]

My r14-1452-gfb409a15d9babc change to add optimization hints to
std::vector causes regressions because it makes std::vector::size() and
std::vector::capacity() too big to inline. That's the opposite of what
I wanted, so revert the changes to those functions.

To achieve the original aim of optimizing vec.assign(vec.size(), x) we
can add a local optimization hint to _M_fill_assign, so that it doesn't
affect all other uses of size() and capacity().

Additionally, add the same hint to the _M_assign_aux overload for
forward iterators and add that to the testcase.

It would be nice to similarly optimize:
  if (vec1.size() == vec2.size()) vec1 = vec2;
but adding hints to operator=(const vector&) doesn't help. Presumably
the relationships between the two sizes and two capacities are too
complex to track effectively.

libstdc++-v3/ChangeLog:

PR libstdc++/110060
* include/bits/stl_vector.h (_Vector_base::_M_invariant):
Remove.
(vector::size, vector::capacity): Remove calls to _M_invariant.
* include/bits/vector.tcc (vector::_M_fill_assign): Add
optimization hint to reallocating path.
(vector::_M_assign_aux(FwdIter, FwdIter, forward_iterator_tag)):
Likewise.
* testsuite/23_containers/vector/capacity/invariant.cc: Moved
to...
* testsuite/23_containers/vector/modifiers/assign/no_realloc.cc:
...here. Check assign(FwdIter, FwdIter) too.
* testsuite/23_containers/vector/types/1.cc: Revert addition
of -Wno-stringop-overread option.

[Bug fortran/102973] possible inconsistency in procptr_assignment handling when matching ASSOCIATE

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102973

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #2 from Paul Thomas  ---
Hi All,

Following comment #1 there does not seem to have been a testcase provided that
would require the fix nor has anybody shown that it does or does not wreck
havoc.

I am changing it to waiting.

Cheers

Paul

[Bug fortran/100094] Undefined pointers have incorrect rank when using optimization

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100094

Paul Thomas  changed:

   What|Removed |Added

 Status|NEW |WAITING
 Blocks|87477   |

--- Comment #4 from Paul Thomas  ---
Hi Jose,

This seems to me to have fixed itself.

I'll put the PR to "waiting" until you confirm (or not!).

I have also stopped it from blocking the associate meta-bug 87477.

Thanks

Paul


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
[Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[Bug target/80040] SSE4.1 ptest not always merged

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80040

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:3635e8c67e13e3da7e1e23a617dd9952218e93e0

commit r14-1466-g3635e8c67e13e3da7e1e23a617dd9952218e93e0
Author: Roger Sayle 
Date:   Thu Jun 1 15:10:09 2023 +0100

PR target/109973: CCZmode and CCCmode variants of [v]ptest on x86.

This is my proposed minimal fix for PR target/109973 (hopefully suitable
for backporting) that follows Jakub Jelinek's suggestion that we introduce
CCZmode and CCCmode variants of ptest and vptest, so that the i386
backend treats [v]ptest instructions similarly to testl instructions;
using different CCmodes to indicate which condition flags are desired,
and then relying on the RTL cmpelim pass to eliminate redundant tests.

This conveniently matches Intel's intrinsics, that provide different
functions for retrieving different flags, _mm_testz_si128 tests the
Z flag, _mm_testc_si128 tests the carry flag.  Currently we use the
same instruction (pattern) for both, and unfortunately the *ptest_and
optimization is only valid when the ptest/vptest instruction is used to
set/test the Z flag.

The downside, as predicted by Jakub, is that GCC's cmpelim pass is
currently COMPARE-centric and not able to merge the ptests from expressions
such as _mm256_testc_si256 (a, b) + _mm256_testz_si256 (a, b), which is a
known issue, PR target/80040.

2023-06-01  Roger Sayle  
Uros Bizjak  

gcc/ChangeLog
PR target/109973
* config/i386/i386-builtin.def (__builtin_ia32_ptestz128): Use new
CODE_for_sse4_1_ptestzv2di.
(__builtin_ia32_ptestc128): Use new CODE_for_sse4_1_ptestcv2di.
(__builtin_ia32_ptestz256): Use new CODE_for_avx_ptestzv4di.
(__builtin_ia32_ptestc256): Use new CODE_for_avx_ptestcv4di.
* config/i386/i386-expand.cc (ix86_expand_branch): Use CCZmode
when expanding UNSPEC_PTEST to compare against zero.
* config/i386/i386-features.cc (scalar_chain::convert_compare):
Likewise generate CCZmode UNSPEC_PTESTs when converting
comparisons.
(general_scalar_chain::convert_insn): Use CCZmode for COMPARE
result.
(timode_scalar_chain::convert_insn): Use CCZmode for COMPARE
result.
* config/i386/i386-protos.h (ix86_match_ptest_ccmode): Prototype.
* config/i386/i386.cc (ix86_match_ptest_ccmode): New predicate to
check for suitable matching modes for the UNSPEC_PTEST pattern.
* config/i386/sse.md (define_split): When splitting UNSPEC_MOVMSK
to UNSPEC_PTEST, preserve the FLAG_REG mode as CCZ.
(*_ptest): Add asterisk to hide define_insn.  Remove
":CC" mode of FLAGS_REG, instead use ix86_match_ptest_ccmode.
(_ptestz): New define_expand to specify CCZ.
(_ptestc): New define_expand to specify CCC.
(_ptest): A define_expand using CC to preserve the
current behavior.
(*ptest_and): Specify CCZ to only perform this optimization
when only the Z flag is required.

gcc/testsuite/ChangeLog
PR target/109973
* gcc.target/i386/pr109973-1.c: New test case.
* gcc.target/i386/pr109973-2.c: Likewise.

[Bug target/109973] [13/14 Regression] Wrong code for AVX2 since 13.1 by combining VPAND and VPTEST since r13-2006-ga56c1641e9d25e

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109973

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Roger Sayle :

https://gcc.gnu.org/g:3635e8c67e13e3da7e1e23a617dd9952218e93e0

commit r14-1466-g3635e8c67e13e3da7e1e23a617dd9952218e93e0
Author: Roger Sayle 
Date:   Thu Jun 1 15:10:09 2023 +0100

PR target/109973: CCZmode and CCCmode variants of [v]ptest on x86.

This is my proposed minimal fix for PR target/109973 (hopefully suitable
for backporting) that follows Jakub Jelinek's suggestion that we introduce
CCZmode and CCCmode variants of ptest and vptest, so that the i386
backend treats [v]ptest instructions similarly to testl instructions;
using different CCmodes to indicate which condition flags are desired,
and then relying on the RTL cmpelim pass to eliminate redundant tests.

This conveniently matches Intel's intrinsics, that provide different
functions for retrieving different flags, _mm_testz_si128 tests the
Z flag, _mm_testc_si128 tests the carry flag.  Currently we use the
same instruction (pattern) for both, and unfortunately the *ptest_and
optimization is only valid when the ptest/vptest instruction is used to
set/test the Z flag.

The downside, as predicted by Jakub, is that GCC's cmpelim pass is
currently COMPARE-centric and not able to merge the ptests from expressions
such as _mm256_testc_si256 (a, b) + _mm256_testz_si256 (a, b), which is a
known issue, PR target/80040.

2023-06-01  Roger Sayle  
Uros Bizjak  

gcc/ChangeLog
PR target/109973
* config/i386/i386-builtin.def (__builtin_ia32_ptestz128): Use new
CODE_for_sse4_1_ptestzv2di.
(__builtin_ia32_ptestc128): Use new CODE_for_sse4_1_ptestcv2di.
(__builtin_ia32_ptestz256): Use new CODE_for_avx_ptestzv4di.
(__builtin_ia32_ptestc256): Use new CODE_for_avx_ptestcv4di.
* config/i386/i386-expand.cc (ix86_expand_branch): Use CCZmode
when expanding UNSPEC_PTEST to compare against zero.
* config/i386/i386-features.cc (scalar_chain::convert_compare):
Likewise generate CCZmode UNSPEC_PTESTs when converting
comparisons.
(general_scalar_chain::convert_insn): Use CCZmode for COMPARE
result.
(timode_scalar_chain::convert_insn): Use CCZmode for COMPARE
result.
* config/i386/i386-protos.h (ix86_match_ptest_ccmode): Prototype.
* config/i386/i386.cc (ix86_match_ptest_ccmode): New predicate to
check for suitable matching modes for the UNSPEC_PTEST pattern.
* config/i386/sse.md (define_split): When splitting UNSPEC_MOVMSK
to UNSPEC_PTEST, preserve the FLAG_REG mode as CCZ.
(*_ptest): Add asterisk to hide define_insn.  Remove
":CC" mode of FLAGS_REG, instead use ix86_match_ptest_ccmode.
(_ptestz): New define_expand to specify CCZ.
(_ptestc): New define_expand to specify CCC.
(_ptest): A define_expand using CC to preserve the
current behavior.
(*ptest_and): Specify CCZ to only perform this optimization
when only the Z flag is required.

gcc/testsuite/ChangeLog
PR target/109973
* gcc.target/i386/pr109973-1.c: New test case.
* gcc.target/i386/pr109973-2.c: Likewise.

[Bug fortran/110081] New: Unhelpful error message: "(null):0: confused by earlier errors, bailing out"

[andrew at fluidgravity dot co.uk via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110081

Bug ID: 110081
   Summary: Unhelpful error message: "(null):0: confused by
earlier errors, bailing out"
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at fluidgravity dot co.uk
  Target Milestone: ---

The following code compiles with neither gfortran-11 nor gfortran-12, but does
compile with gfortran-10 and earlier. The error message just says "(null):0:
confused by earlier errors, bailing out" without giving any indication what the
problem is. (The actual problem seems to be the clash between the variable name
'p' in the common block and the module name 'p'.)

MODULE commons
   IMPLICIT NONE
   INTEGER :: p
   COMMON /c/ p
END
MODULE p
   IMPLICIT NONE
   SAVE
   CONTAINS
   SUBROUTINE sub
   USE commons
   END SUBROUTINE sub
END

$ gfortran-11 -c code.f90 

(null):0: confused by earlier errors, bailing out

[Bug tree-optimization/110080] [13/14 Regression] Missed Dead Code Elimination at -Os when using __builtin_unreachable since r13-6945-g429a7a88438

[theodort at inf dot ethz.ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110080

--- Comment #1 from Theodoros Theodoridis  ---
Oops, the first code snippet is wrong in the original post: 

void foo(void);
static unsigned char a = 131;
static int *b;
static int **c = 
static void d(int e, unsigned f) {
int *g;
if (!e){ // < if (!e) is correct
for (; a; ++a)
for (e = 0; 0;)
;
g = 
int **h = 
if (**h) {
foo();
}
}
*c = 
}
int main() { d(4 & a, a); }

this is also the correct assembly for gcc trunk/13.1/12.3 at -Os:

main:
movba(%rip), %al
testb   $4, %al
jne .L5
xorl%edx, %edx
.L2:
testb   %al, %al
je  .L12
incl%eax
movb$1, %dl
jmp .L2
.L12:
testb   %dl, %dl
je  .L5
movb$0, a(%rip)
.L5:
leaq-4(%rsp), %rax
movq%rax, b(%rip)
xorl%eax, %eax
ret
a:
.byte   -125


the code with the _builtin_unreachable and the rest are correct

[Bug tree-optimization/110080] New: [13/14 Regression] Missed Dead Code Elimination at -Os when using __builtin_unreachable since r13-6945-g429a7a88438

[theodort at inf dot ethz.ch via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110080

Bug ID: 110080
   Summary: [13/14 Regression] Missed Dead Code Elimination at -Os
when using __builtin_unreachable since
r13-6945-g429a7a88438
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

Given: 

void foo(void);
static unsigned char a = 131;
static int *b;
static int **c = 
static void d(int e, unsigned f) {
int *g;
if (e){
for (; a; ++a)
for (e = 0; 0;)
;
g = 
int **h = 
if (**h) {
foo();
}
}
*c = 
}
int main() { d(4 & a, a); }


gcc trunk/13.1/12.3 at -Os generate:

main:
testb   $4, a(%rip)
je  .L3
movb$0, a(%rip)
.L3:
leaq-4(%rsp), %rax
movq%rax, b(%rip)
xorl%eax, %eax
ret
a:
.byte   -125

If I include a __builtin_unreachable() to help the compiler:

void foo(void);
static unsigned char a = 131;
static int *b;
static int **c = 
static void d(int e, unsigned f) {
int *g;
if (f != 131) {
__builtin_unreachable(); // <- THIS
}
if (!e){
for (; a; ++a)
for (e = 0; 0;)
;
g = 
int **h = 
if (**h) {
foo();
}
}
*c = 
}
int main() { d(4 & a, a); }

gcc-12.3 at -Os generates better code:

main:
leaq-4(%rsp), %rax
movb$0, a(%rip)
movq%rax, b(%rip)
xorl%eax, %eax
ret
a:
.byte   -125

But gcc-13.1/trunk at -Os generate worse code:

main:
subq$24, %rsp
movba(%rip), %al
movl%eax, %edx
andl$4, %edx
movl%edx, 12(%rsp)
xorl%edx, %edx
.L2:
testb   %al, %al
je  .L8
incl%eax
movb$1, %dl
jmp .L2
.L8:
testb   %dl, %dl
je  .L4
movb$0, a(%rip)
jmp .L5
.L4:
cmpl$0, 12(%rsp)
je  .L5
callfoo
.L5:
leaq12(%rsp), %rax
movq%rax, b(%rip)
xorl%eax, %eax
addq$24, %rsp
ret
a:
.byte   -125

https://godbolt.org/z/zvqshjEj3


Started with r13-6945-g429a7a88438

[Bug fortran/87127] External function not recognised from within an associate block

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #12 from Paul Thomas  ---
I think that this one can be closed now.

Paul

[Bug fortran/87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[pault at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
Bug 87477 depends on bug 87127, which changed state.

Bug 87127 Summary: External function not recognised from within an associate 
block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87127

   What|Removed |Added

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

[Bug gcov-profile/110074] -fprofile-arcs profiles arcs generated by -fsanitize=bounds

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110074

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-06-01
 Ever confirmed|0   |1
Summary|code bloat with |-fprofile-arcs profiles
   |-fprofile-arcs +|arcs generated by
   |-fsanitize=bounds   |-fsanitize=bounds

--- Comment #2 from Andrew Pinski  ---
Simplified example:
```
int array[104];

int f(int t)
{
return array[t];
}
```

Compile this at -fprofile-arcs  -O2 -fsanitize=bounds and in .optimized we
have:
```
  PROF_edge_counter_5 = __gcov0._Z1fi[0];
  PROF_edge_counter_6 = PROF_edge_counter_5 + 1;
  __gcov0._Z1fi[0] = PROF_edge_counter_6;
  # DEBUG BEGIN_STMT
  _11 = (sizetype) t_1(D);
  if (_11 >= 104)
goto ; [0.05%]
  else
goto ; [99.95%]

   [local count: 536864]:
  _12 = (unsigned long) t_1(D);
  __builtin___ubsan_handle_out_of_bounds (&*.Lubsan_data0, _12);

   [local count: 1073741824]:
  PROF_edge_counter_7 = __gcov0._Z1fi[1];
  PROF_edge_counter_8 = PROF_edge_counter_7 + 1;
  __gcov0._Z1fi[1] = PROF_edge_counter_8;
  _4 = array[t_1(D)];
```

But we do really need to profile that arc?

[Bug gcov-profile/110072] __gcov_dump cannot generate gcda for so files opened with dlopen when gcc version is later than 5.1.0

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110072

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
GCC before 10.x is no longer being supported. That is we are not producing
another release of GCC before 10.x. So this is just a dup of bug 83879.

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

[Bug gcov-profile/83879] __gcov_dump doesn't work with dlopen-ed libraries

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879

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

[Bug gcov-profile/83879] __gcov_dump doesn't work with dlopen-ed libraries

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83879

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug ipa/110057] Missed devirtualization opportunities

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110057

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Ng YongXiang from comment #4)
> Would anyone be able to direct me to which portion of the code is
> responsible for this threshold between len 2 & 3 array? Is this the
> responsibility of the c++ frontend? or is it still related to the optimizer.

The front-end has nothing to do with the difference between 2 and 3. The
difference between 2 and 3 is unrolling of the loop in the optimizers. See bug
109770 and bug 80899 for other cases of inplacement new causing issues.

[Bug gcov-profile/110074] code bloat with -fprofile-arcs + -fsanitize=bounds

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110074

Andrew Pinski  changed:

   What|Removed |Added

  Component|sanitizer   |gcov-profile

--- Comment #1 from Andrew Pinski  ---
>Nick Desaulniers pointed out a recent change to LLVM that addresses a similar 
>problem by not trying to sanitize code that was generated by gcov

Well in the case of GCC, it is the order of sanitizer and profile-arcs is the
opposite of clang/LLVM's. That is the issue is we need not to generate
profile-arcs for code added by the sanitizer.

[Bug rtl-optimization/110079] [10/11/12/13/14 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110079

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-06-01
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug rtl-optimization/110079] [10/11/12/13/14 Regression] ICE with -freorder-blocks-and-partition and inline-asm goto

[pinskia at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110079

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||10.4.0, 12.2.0, 13.1.0,
   ||8.2.0, 9.5.0
   Target Milestone|--- |10.5
  Known to work||6.4.0, 7.3.0, 7.5.0
   Keywords||ice-on-valid-code
 Target||aarch64*-*-* riscv*-*-*
Summary|ICE with|[10/11/12/13/14 Regression]
   |-freorder-blocks-and-partit |ICE with
   |ion and inline-asm goto |-freorder-blocks-and-partit
   ||ion and inline-asm goto

[Bug rtl-optimization/110079] New: ICE with -freorder-blocks-and-partition

[yancheng.li at foxmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110079

Bug ID: 110079
   Summary: ICE with -freorder-blocks-and-partition
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yancheng.li at foxmail dot com
  Target Milestone: ---

When compiling the testacse attached with -S -O2 -freorder-blocks-and-partition
flags, I get the following error: 

// target：aarch64-linux-gnu
// configure：../gcc/configure --prefix=/home/lyc/2022/gcc-trunk/install
--enable-shared --enable-threads=posix --enable-checking=release
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-linker-hash-style=gnu --enable-languages=c --enable-plugin
--enable-initfini-array --disable-libgcj --without-isl --without-cloog
--enable-gnu-indirect-function --build=aarch64-linux-gnu
--with-stage1-ldflags=' -Wl,-z,relro,-z,now' --with-boot-ldflags='
-Wl,-z,relro,-z,now' --disable-bootstrap --with-multilib-list=lp64
// thread model：posix
// gcc version 14.0.0 20230531 (experimental) (GCC)
//
// during RTL pass: outof_cfglayout
// test.c: in function‘d’:
// test.c:12:1: internal compiler error：in fixup_reorder_chain，at
cfgrtl.cc:4029
//12 | }
//   | ^
// 0x824a97 fixup_reorder_chain
//  ../../gcc/gcc/cfgrtl.cc:4029
// 0x824a97 cfg_layout_finalize()
//  ../../gcc/gcc/cfgrtl.cc:4571
// 0x824d5f execute
//  ../../gcc/gcc/cfgrtl.cc:3753
// Please submit a full bug report, with preprocessed source.
// Please include the complete backtrace with any bug report.

// /home/lyc/2022/gcc-trunk/install/libexec/gcc/aarch64-linux-gnu/14.0.0/cc1
-quiet test.c -quiet -dumpbase test.c -dumpbase-ext .c -mlittle-endian
-mabi=lp64 -O2 -freorder-blocks-and-partition -freport-bug -o - -frandom-seed=0
-fdump-noaddr

# 0 "test.c"
# 0 ""
# 0 "<命令行>"
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "<命令行>" 2
# 1 "test.c"
int a;
__attribute__((__cold__)) int b(char *);
void d(void) {
e:
  for (; a;)
;
  b("");
  asm goto("" : : : : c);
  asm("");
c:
  goto e;
}

[Bug middle-end/110052] useless local variable not optimized away

[amonakov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110052

--- Comment #5 from Alexander Monakov  ---
There are other reasons why it's invalid. For instance, in a multi-threaded
program it could introduce a data race on assignment to foo->size inside of
'myrealloc' where the original program might have aborted without invoking UB.

Can you give more context about the problem you're trying to solve?

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16 on Intel Raptor Lake

[hubicka at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812

--- Comment #17 from Jan Hubicka  ---
I was also thinking of DCE. It looks like plausible idea.  It may leads to a
surprise where you sture same undefined variable to two places and later
compare them for equality, but that is undefined anyway.

[Bug target/54089] [SH] Refactor shift patterns

[olegendo at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089

--- Comment #51 from Oleg Endo  ---
(In reply to Alexander Klepikov from comment #50)
> 
> Ooh, my bad! You are absolutely right. A function is inlined and division is
> converted to 4 'shar's which at combine pass are catched by 'define_insn
> "ashrsi3_libcall_collapsed"' which is little unexpected to me. Of course, it
> is expanded at 'split' pass to lib call. 5 and less right shifts should not
> convert to a lib call, but that can be easily corrected.
> 
> But maybe there is a way to exclude particular insn from combine pass? (I
> guess not).
> 

I don't think there is a direct way to hide patterns from the combine pass,
although I could be wrong, since I haven't been tracking the combine pass
development closely for a while.

Perhaps you can look at how the left-shifts are done as a reference.


> Now concerning GCC testsuite. I ran it in such way:
> 
> make check RUNTESTFLAGS="CFLAGS='$CFLAGS -I/usr/local/sh-elf/include/'
> --target_board=sh-sim\{-m2e,-m4\}\{-ml,-mb\}"
> 
> There are lots of failed tests on non-patched GCC. Even if I narrow tests
> list to sh.exp, it still fails a lot of times. At last there's nothing in
> logs that produce ICE in RTL. I'm not sure I could find a crash due to the
> patch at all, even if it were there.

To test it, you first use a known good version of GCC without your patch, build
the whole toolchain from scratch and run it.  Then collect the test results.

Then apply your patch, and repeat the process.  Collect the test results again.

Then compare both test results.  If there are any new changes in the test
results your patch is hitting something.

Usually I'd run the testsuite as follows:

make -k check
RUNTESTFLAGS="--target_board=sh-sim\{-m2/-ml,-m2/-mb,-m2a/-mb,-m4/-ml,-m4/-mb,-m4a/-ml,-m4a/-mb}"

(running make with multiple jobs here is useful, and still it will take some
hours)

[Bug target/109954] x86-64's -m32 does not conform to documentation

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.5
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #16 from Jonathan Wakely  ---
Fixed on all active branches.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:bdd038cc1782b550b434a806ce995fc79f5d1f6b

commit r10-11432-gbdd038cc1782b550b434a806ce995fc79f5d1f6b
Author: Jonathan Wakely 
Date:   Thu Jun 1 11:30:10 2023 +0100

doc: Fix description of x86 -m32 option [PR109954]

This option does not imply -march=i386 so it's incorrect to say it
generates code that will run on "any i386 system".

gcc/ChangeLog:

PR target/109954
* doc/invoke.texi (x86 Options): Fix description of -m32 option.

(cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #14 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:8538e22f0004565bb95b10741bfd416961030f4c

commit r11-10838-g8538e22f0004565bb95b10741bfd416961030f4c
Author: Jonathan Wakely 
Date:   Thu Jun 1 11:30:10 2023 +0100

doc: Fix description of x86 -m32 option [PR109954]

This option does not imply -march=i386 so it's incorrect to say it
generates code that will run on "any i386 system".

gcc/ChangeLog:

PR target/109954
* doc/invoke.texi (x86 Options): Fix description of -m32 option.

(cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #13 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:4466c5ba6e2f1759a2ce461f15fc4e018872a22e

commit r12-9672-g4466c5ba6e2f1759a2ce461f15fc4e018872a22e
Author: Jonathan Wakely 
Date:   Thu Jun 1 11:30:10 2023 +0100

doc: Fix description of x86 -m32 option [PR109954]

This option does not imply -march=i386 so it's incorrect to say it
generates code that will run on "any i386 system".

gcc/ChangeLog:

PR target/109954
* doc/invoke.texi (x86 Options): Fix description of -m32 option.

(cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #12 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:3b95319b621d95055da182c5fbbccd0d82cb919e

commit r13-7398-g3b95319b621d95055da182c5fbbccd0d82cb919e
Author: Jonathan Wakely 
Date:   Thu Jun 1 11:30:10 2023 +0100

doc: Fix description of x86 -m32 option [PR109954]

This option does not imply -march=i386 so it's incorrect to say it
generates code that will run on "any i386 system".

gcc/ChangeLog:

PR target/109954
* doc/invoke.texi (x86 Options): Fix description of -m32 option.

(cherry picked from commit eeb92704967875411416b0b9508aa6f49e8192fd)

[Bug c++/110078] [13 regression] Excessive memory usage constructing std::variant from a high-index alternative.

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110078

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Making this a dup of PR 109678

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

[Bug c++/109678] [13/14 Regression] exponential time behavior on std::variant

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109678

Jonathan Wakely  changed:

   What|Removed |Added

 CC||toojays at toojays dot net

--- Comment #8 from Jonathan Wakely  ---
*** Bug 110078 has been marked as a duplicate of this bug. ***

[Bug c++/110078] [13 regression] Excessive memory usage constructing std::variant from a high-index alternative.

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110078

--- Comment #1 from Jonathan Wakely  ---
Already fixed by r14-409-g4b8d0d4d7fd245

[Bug c++/110078] New: [13 regression] Excessive memory usage constructing std::variant from a high-index alternative.

[toojays at toojays dot net via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110078

Bug ID: 110078
   Summary: [13 regression] Excessive memory usage constructing
std::variant from a high-index alternative.
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: toojays at toojays dot net
  Target Milestone: ---

Created attachment 55233
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55233=edit
Reproducer demonstrating excessive memory use constructing std::variant from a
high-index alternative.

The attached source contains a function which constructs a std::variant<29
alternatives> from the 29th alternative. Attempting to compile it with GCC 13.1
results in cc1plus consuming more than 20GiB of memory before being killed. GCC
12.2.0 is able to compile it promptly with no apparent problems.

$ g++-13 -v
Using built-in specs.
COLLECT_GCC=/opt/acacia/3rd-party/gcc-13.1.0-1/bin/g++
COLLECT_LTO_WRAPPER=/opt/acacia/3rd-party/gcc-13.1.0-1/libexec/gcc/x86_64-pc-linux-gnu/13.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /docker-20.04-build/extract/gcc-13.1.0/configure
--prefix=/opt/acacia/3rd-party/gcc-13.1.0-1
CPPFLAGS=-I/opt/acacia/3rd-party/gcc-13.1.0-1/include CFLAGS='-O2 -g
-fno-omit-frame-pointer' CXXFLAGS='-O2 -g -fno-omit-frame-pointer'
--enable-languages=c,c++,d --disable-multilib --with-system-zlib
--enable-checking=release --program-prefix= --program-suffix=
--with-gmp=/opt/acacia/3rd-party/gcc-13.1.0-1
--with-mpfr=/opt/acacia/3rd-party/gcc-13.1.0-1
--with-mpc=/opt/acacia/3rd-party/gcc-13.1.0-1
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.1.0 (GCC)

[Bug middle-end/110069] [Perf] -finstrument-functions causes program size to double

[amonakov at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110069

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
For such space-constrained environments I'd suggest using '-pg' instead. It
emits just one call to the _mcount function on entry without overhead. If you
need to hook the exit, you can replace the return address in your
implementation of _mcount (this function usually has a non-standard ABI, so
it's always necessary to implement it in assembly).

[Bug target/109812] GraphicsMagick resize is a lot slower in GCC 13.1 vs Clang 16 on Intel Raptor Lake

[jakub at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109812

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
Shouldn't we DCE something = x_N(D); stores when x is a VAR_DECL, at least
provided
something can't trap?  I mean, the previous content is one of the possible
uninitialized values.

[Bug target/54089] [SH] Refactor shift patterns

[klepikov.alex+bugs at gmail dot com via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54089

--- Comment #50 from Alexander Klepikov  
---
> > I've found that my patch catches integer division. In short, it appears to
> > work unpredictable. It looks like there's no easy way to catch right shift.
> 
> What do you mean it catches integer division? There could be several places
> during compilation, where the compiler will try to convert integer division
> to right shifts.  But it will not do so unless it's wrong.  The patterns you
> have added shouldn't match a division operation.

Ooh, my bad! You are absolutely right. A function is inlined and division is
converted to 4 'shar's which at combine pass are catched by 'define_insn
"ashrsi3_libcall_collapsed"' which is little unexpected to me. Of course, it is
expanded at 'split' pass to lib call. 5 and less right shifts should not
convert to a lib call, but that can be easily corrected.

But maybe there is a way to exclude particular insn from combine pass? (I guess
not).

Here are the files that confused me:

$ cat pr49880-3.c
/* Check that the option -mdiv=call-table works.  */
/* { dg-do link }  */
/* { dg-options "-mdiv=call-table" }  */

int
test00 (int a, int b)
{
  return a / b;
}

unsigned int
test01 (unsigned int a, unsigned b)
{
  return a / b;
}

int
main (int argc, char** argv)
{
  return test00 (argc, 123) + test01 (argc, 123);
}

Not-patched GCC

$ cat pr49880-3.s.clean
.file   "pr49880-3.c"
.text
.text
.align 1
.align 2
.global _test00
.type   _test00, @function
_test00:
mov.l   .L4,r0
sts.l   pr,@-r15
jsr @r0
nop
lds.l   @r15+,pr
rts
nop
.L5:
.align 2
.L4:
.long   ___sdivsi3
.size   _test00, .-_test00
.align 1
.align 2
.global _test01
.type   _test01, @function
_test01:
mov.l   .L8,r0
sts.l   pr,@-r15
jsr @r0
nop
lds.l   @r15+,pr
rts
nop
.L9:
.align 2
.L8:
.long   ___udivsi3
.size   _test01, .-_test01
.section.text.startup,"ax",@progbits
.align 1
.align 2
.global _main
.type   _main, @function
_main:
mov.l   .L11,r1
dmuls.l r1,r4
sts mach,r0
sharr0
sharr0
sharr0
sharr0
mov r4,r1
shllr1
subcr1,r1
sub r1,r0
mov.l   .L12,r1
dmulu.l r1,r4
sts mach,r1
sub r1,r4
shlrr4
add r4,r1
shlr2   r1
shlr2   r1
shlr2   r1
rts
add r1,r0
.L13:
.align 2
.L11:
.long   558694933
.L12:
.long   174592167
.size   _main, .-_main
.ident  "GCC: (GNU) 13.1.0"

Patched GCC

$ cat pr49880-3.s
.file   "pr49880-3.c"
.text
.text
.align 1
.align 2
.global _test00
.type   _test00, @function
_test00:
mov.l   .L4,r0
sts.l   pr,@-r15
jsr @r0
nop
lds.l   @r15+,pr
rts
nop
.L5:
.align 2
.L4:
.long   ___sdivsi3
.size   _test00, .-_test00
.align 1
.align 2
.global _test01
.type   _test01, @function
_test01:
mov.l   .L8,r0
sts.l   pr,@-r15
jsr @r0
nop
lds.l   @r15+,pr
rts
nop
.L9:
.align 2
.L8:
.long   ___udivsi3
.size   _test01, .-_test01
.section.text.startup,"ax",@progbits
.align 1
.align 2
.global _main
.type   _main, @function
_main:
mov.l   .L12,r2
mov r4,r1
sts.l   pr,@-r15
dmuls.l r2,r4
mov.l   .L13,r2
jsr @r2
sts mach,r4
mov r1,r2
shllr2
subcr2,r2
mov r4,r0
sub r2,r0
mov.l   .L14,r2
dmulu.l r2,r1
sts mach,r2
sub r2,r1
shlrr1
add r1,r2
shlr2   r2
shlr2   r2
shlr2   r2
add r2,r0
lds.l   @r15+,pr
rts
nop
.L15:
.align 2
.L12:
.long   558694933
.L13:
.long   ___ashiftrt_r4_4
.L14:
.long   174592167
.size   _main, .-_main
.ident  "GCC: (GNU) 13.1.0"



Now concerning GCC testsuite. I ran it in such way:

make check RUNTESTFLAGS="CFLAGS='$CFLAGS -I/usr/local/sh-elf/include/'
--target_board=sh-sim\{-m2e,-m4\}\{-ml,-mb\}"

There are lots of failed tests on non-patched GCC. Even if I narrow tests list
to sh.exp, it still fails a lot of times. At last there's nothing in logs that
produce ICE in RTL. I'm not sure I could find a crash due to the patch at all,
even if it were there.

And finally, 'parallel' appears to be unnecessary, thank you for pointing.

[Bug target/109954] x86-64's -m32 does not conform to documentation

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109954

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:eeb92704967875411416b0b9508aa6f49e8192fd

commit r14-1464-geeb92704967875411416b0b9508aa6f49e8192fd
Author: Jonathan Wakely 
Date:   Thu Jun 1 11:30:10 2023 +0100

doc: Fix description of x86 -m32 option [PR109954]

This option does not imply -march=i386 so it's incorrect to say it
generates code that will run on "any i386 system".

gcc/ChangeLog:

PR target/109954
* doc/invoke.texi (x86 Options): Fix description of -m32 option.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077

Jonathan Wakely  changed:

   What|Removed |Added

 Target|*-*-solaris2.11 |*-*-solaris2.11
   ||aarch4-unknown-linux-gnu

--- Comment #1 from Jonathan Wakely  ---
This affects aarch64 too:
https://gcc.gnu.org/pipermail/gcc-patches/2023-June/620335.html
And probably other targets where long double uses binary128 rep.

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2023-06-01
  Known to fail||14.0
   Keywords||ABI
 Status|UNCONFIRMED |ASSIGNED
   Priority|P3  |P1
 Ever confirmed|0   |1
  Known to work||13.1.1

[Bug libstdc++/110077] [14 regression] libstdc++-abi/abi_check FAILs on Solaris

[ro at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

[Bug libstdc++/110077] New: [14 regression] libstdc++-abi/abi_check FAILs on Solaris

[ro at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110077

Bug ID: 110077
   Summary: [14 regression] libstdc++-abi/abi_check FAILs on
Solaris
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
Target: *-*-solaris2.11

Between 20230530 (a899401404186843f38462c8fc9de733f19ce864) and 20230531
(070d651c6db37c3658be0a5274f44265045428e6),
libstdc++-abi/abi_check started to FAIL on Solaris (both sparc and x86, 32 and
64-bit):

+FAIL: libstdc++-abi/abi_check

The log file shows

1 incompatible symbols
0
_ZSt10from_charsPKcS0_RDF128_St12chars_format
std::from_chars(char const*, char const*, _Float128&, std::chars_format)
version status: incompatible
GLIBCXX_3.4.31
type: function
status: added