[Bug target/103463] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -Os -fno-tree-dominator-opts -fno-tree-vrp

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #1 from Hongtao.liu  ---
It should be fixed by
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585613.html

[Bug tree-optimization/103458] [12 Regression] ICE in verify_loop_structure, at cfgloop.c:1736 (error: loop with header 4 not in loop tree)

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
I will have a look.

[Bug target/103463] [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -Os -fno-tree-dominator-opts -fno-tree-vrp

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug ipa/103451] [12 Regression] crash at gcc/range-op.cc:1836 since r12-5531-g1b0acc4b800b589a

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||rguenth at gcc dot gnu.org

--- Comment #2 from Richard Biener  ---
So range-op.cc eventually wants to look at 'cfun' which of course is a non-go
in IPA context.

void
operator_div::wi_fold (irange , tree type,
   const wide_int _lb, const wide_int _ub,
   const wide_int _lb, const wide_int _ub) const
{
...
  // If flag_non_call_exceptions, we must not eliminate a division by zero.
  if (cfun->can_throw_non_call_exceptions)
{
  r.set_varying (type);
  return;

I'm not sure wi_fold should care about "eliminating a division", but surely
even for non-call EH the actual range of the result doesn't need to care.

So if sth goes wrong when eliding the above it needs to be fixed upthread
instead?

Otherwise a "quick" workaround for the ICE is to check !cfun || ... and
be conservative.  I see there's no state associated with range_fold_binary_expr
where the IPA context could pass down relevant can_throw_non_call_exceptions.

I also see

bool
fold_using_range::range_of_builtin_call (irange , gcall *call,
 fur_source )
...
  if (cfun->after_inlining)
{
  r.set_zero (type);

which might have similar problems (!cfun || ... looks quite reasonable there)

[Bug target/61713] ICE when building c++ code with atomic functions for thumb1 target

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||mans at mansr dot com

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

[Bug middle-end/56964] ICE with -fno-sync-libcalls when target lacks atomic operations

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Fixed in GCC 4.9.x and GCC 5+. by the patch which fixed PR 61713. It is an
exact dup really.

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

[Bug target/103463] New: [12 Regression] ICE: in ix86_attr_length_immediate_default, at config/i386/i386.c:16686 with -Os -fno-tree-dominator-opts -fno-tree-vrp

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 103463
   Summary: [12 Regression] ICE: in
ix86_attr_length_immediate_default, at
config/i386/i386.c:16686 with -Os
-fno-tree-dominator-opts -fno-tree-vrp
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 51892
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51892=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc -Os -fno-tree-dominator-opts -fno-tree-vrp testcase.c
during RTL pass: sched2
testcase.c: In function 'bar0':
testcase.c:10:1: internal compiler error: in
ix86_attr_length_immediate_default, at config/i386/i386.c:16686
   10 | }
  | ^
0x814081 ix86_attr_length_immediate_default(rtx_insn*, bool)
/repo/gcc-trunk/gcc/config/i386/i386.c:16686
0x1aeb948 insn_default_length(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.md:720
0x16dcd92 ix86_min_insn_size(rtx_insn*)
/repo/gcc-trunk/gcc/config/i386/i386.c:21516
0x1762631 core2i7_first_cycle_multipass_filter_ready_try
/repo/gcc-trunk/gcc/config/i386/x86-tune-sched-core.c:107
0x22e199f max_issue(ready_list*, int, void*, bool, int*)
/repo/gcc-trunk/gcc/haifa-sched.c:5952
0x22e47a7 max_issue(ready_list*, int, void*, bool, int*)
/repo/gcc-trunk/gcc/haifa-sched.c:6189
0x22e47a7 choose_ready
/repo/gcc-trunk/gcc/haifa-sched.c:6189
0x22f2532 schedule_block(basic_block_def**, void*)
/repo/gcc-trunk/gcc/haifa-sched.c:6806
0x12fb8cd schedule_region
/repo/gcc-trunk/gcc/sched-rgn.c:3179
0x12fb8cd schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.c:3518
0x12fbded schedule_insns()
/repo/gcc-trunk/gcc/sched-rgn.c:3504
0x12fbded rest_of_handle_sched2
/repo/gcc-trunk/gcc/sched-rgn.c:3742
0x12fbded execute
/repo/gcc-trunk/gcc/sched-rgn.c:3878
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r12-5569-20211128195959-g300dbea1269-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r12-5569-20211128195959-g300dbea1269-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.0.0 20211129 (experimental) (GCC)

[Bug c++/46476] Missing Warning about unreachable code after return [-Wunreachable-code-return]

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

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

Bug 103439 Summary: genemit emits dead code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103439

   What|Removed |Added

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

[Bug middle-end/103439] genemit emits dead code

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
OK, agreed.

[Bug rtl-optimization/60412] superfluous arithmetic generated for uneven tail handling

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||l_belev at yahoo dot com

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

[Bug tree-optimization/70274] optimization goes astray and adds completely redundant code

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Andrew Pinski  ---
Dup of bug 60412.

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

[Bug rtl-optimization/60412] superfluous arithmetic generated for uneven tail handling

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-29
   Keywords||missed-optimization

--- Comment #1 from Andrew Pinski  ---
Confirmed. this is sccp happening but it is not needed.

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

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

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

--- Comment #8 from Tamar Christina  ---
> 
> I wonder how the situation looks on AArch64?

The situation didn't improve, up until the end of stage-1 we were seeing a 6%
perf uplift from somewhere which seems to have gone away now (in a commit range
with a non IPA related patch).

The major problems is still the spills. Talking to Vlad I took at look at
improving the Chaitin-Briggs heuristics for spilling during the presence of
calls and how it tries to improve the allocation by moving spills along the
call gaph.

By improving on these heuristics I was able to reduce the number of spills and
saw improvements on both x86 and AArch64 which brought us back to the old
numbers.

However this same information is used by other areas such as register
preferences and so I had a regression in shrink wrapping.  There's also an
issue where x86 seems to assign negative values to register costs to indicate
they REALLY want this register.  This seems to work because the penalty applied
usually is large and it cancels out the negative cost.  But now the value stays
negative causing the register to not be used instead.

To fix these I need to keep track of the penalties and the costs separately but
did not get time to finish that work before the end of stage-1.

[Bug middle-end/46143] __attribute__((optimize)) emits wrong code

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug target/52555] [4.6/4.7/4.8 Regression] ICE unrecognizable insn with -ffast-math and __attribute__((optimize(xx)))

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug target/47315] ICE: in extract_insn, at recog.c:2109 (unrecognizable insn) with -mvzeroupper and __attribute__((target("avx")))

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug target/45478] __attribute__((__target__())) causes crashes at various places

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug target/45325] [4.9 Regression] target attribute doesn't work with -march=i586

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug c/41206] Segmentation fault from two "#pragma GCC optimize" lines

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug target/38018] gcc.dg/pr37106-1.c doesn't work

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug target/37394] [4.4 Regression] Segfault in ia64_variable_issue with -O -fschedule-insns2

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug middle-end/53776] pragma optimize does not support Os

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug middle-end/39840] Non-optimal (or wrong) implementation of SSE intrinsics

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug target/39787] ICE with #pragma GCC target

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

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

Bug 37565 Summary: __optimize__  attribute doesn't work correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37565

   What|Removed |Added

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

[Bug middle-end/37565] __optimize__ attribute doesn't work correctly

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
Fixed in GCC 4.9.0 by r0-125571-gc7f36d55a63c3

https://gcc.gnu.org/pipermail/gcc-patches/2013-October/371339.html

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

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

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

--- Comment #7 from luoxhu at gcc dot gnu.org ---
 1| Dump of assembler code for function foo:
 2|0x15e0 <+0>: rldicr. r3,r3,29,1
 3+>   0x15e4 <+4>: beq 0x15f0 
 4|0x15e8 <+8>: blr
 5|0x15ec <+12>:ori r2,r2,0
 6|0x15f0 <+16>:blr
 7|0x15f4 <+20>:.long 0x0
 8|0x15f8 <+24>:.long 0x0

(gdb) si
0x15e4 in foo ()
1: /x $r3 = 0xc000
2: /x $cr = 0x82000282

cr0 is negative if only rotldi3_mask_dot, but it was 0x42000282 on master code.


BTW, clang also generated instructions with two rorates:

foo(long):# @foo(long)
rldicl 3, 3, 31, 33
rldicl. 3, 3, 33, 29
beq 0, .LBB0_2
blr
.LBB0_2:
blr
.long   0
.quad   0

[Bug tree-optimization/49946] Thread jumps confuse loop unrolling

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Last reconfirmed||2021-11-29
  Component|middle-end  |tree-optimization
 Ever confirmed|0   |1
   Severity|normal  |enhancement
 Status|UNCONFIRMED |NEW

--- Comment #3 from Andrew Pinski  ---
Confirmed, though it looks like it was fixed on the trunk.
There has been a "few" jump threading patches which would have improved this
situation.

[Bug middle-end/87210] [RFE] introduce build time options to zero initialize automatic stack variables

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
  -ftrivial-auto-var-init=[uninitialized|pattern|zero] Add initializations to
automatic variables.

[Bug middle-end/96159] atomic creates incorrect code for possible misaligned struct

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

Summary|atomic creates incorrect|atomic creates incorrect
   |code for possible isaligned |code for possible
   |struct  |misaligned struct

--- Comment #10 from Martin Uecker  ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87237

[Bug tree-optimization/19676] Loop optimizer fails to reverse simple loop

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed a long time ago in GCC 4.6.0.

Everyone except for testloop2 was fixed in GCC 4.5.0 (which was PR 40886 and PR
31238 ). I have not looked into what fixed it in GCC 4.6 though.

[Bug tree-optimization/103462] GCC failed to reduce bit clear in loop.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Related to PR 101991 but not really the same. In this case the value that
matters is an induction variable while in the other case it was an invariant.

[Bug tree-optimization/103462] GCC failed to reduce bit clear in loop.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Severity|normal  |enhancement

[Bug tree-optimization/103462] GCC failed to reduce bit clear in loop.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
bit clear and induction variable could be simplified to `& CONSTANT`

[Bug tree-optimization/103462] GCC failed to reduce bit clear in loop.

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
Should it be done in vectorizer or ldist(just like memory op), or somewhere
else?

[Bug target/47769] [missed optimization] use of btr (bit test and reset)

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Hongtao.liu  ---

> 
> This is obviously horrible, but the right answer isn't btr in a loop, it's
> what clang does:
> 
> movabsq $7905747460161236406, %rax # imm = 0x6DB6DB6DB6DB6DB6 every
> third bit unset
> andq%rdi, %rax
> retq
> 

Open pr103462 for this.

[Bug tree-optimization/103462] New: vectorizer failed to reduce bit_clear in loop.

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 103462
   Summary: vectorizer failed to reduce bit_clear in loop.
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

the testcase is from pr47769

unsigned long cfunc_one(unsigned long tmp) {
for (unsigned long bit = 0; bit < 64; bit += 3) {
tmp &= ~(1UL << bit);
}
return tmp;
}

with -O3 -march=skylake -funroll-loops
gcc generates:
cfunc_one:
mov rax, rdi
xor edx, edx
.L2:
lea rcx, [rdx+3]
btr rax, rdx
lea rsi, [rdx+6]
btr rax, rcx
lea rdi, [rdx+9]
btr rax, rsi
btr rax, rdi
lea r8, [rdx+12]
lea r9, [rdx+15]
btr rax, r8
lea r10, [rdx+18]
btr rax, r9
lea r11, [rdx+21]
btr rax, r10
lea rcx, [rdx+24]
btr rax, r11
lea rsi, [rdx+27]
btr rax, rcx
lea rdi, [rdx+30]
btr rax, rsi
add rdx, 33
btr rax, rdi
cmp rdx, 66
jne .L2
ret

while clang generates:

cfunc_one(unsigned long):  # @cfunc_one(unsigned long)
movabs  rax, 7905747460161236406
and rax, rdi
ret

7905747460161236406 is bit clear for bit {0, 3, 6, 9, ..., 63}.

[Bug ipa/103461] [12 Regression] ICE in operator_div::wi_fold or in evaluate_conditions_for_known_args

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

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

--- Comment #2 from Andrew Pinski  ---
The first one is a dup of bug 103451.

[Bug ipa/103461] [12 Regression] ICE in operator_div::wi_fold or in evaluate_conditions_for_known_args

[asolokha at gmx dot com via Gcc-bugs]

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

Arseny Solokha  changed:

   What|Removed |Added

Summary|[12 Regression] ICE in  |[12 Regression] ICE in
   |operator_div::wi_fold   |operator_div::wi_fold or in
   ||evaluate_conditions_for_kno
   ||wn_args

--- Comment #1 from Arseny Solokha  ---
Another manifestation of the same issue:

unsigned char n;

void
foo (int a);

void
bar (void)
{
  foo (n + 1);
}

void
foo (int a)
{
  unsigned int x = 10;

  if (x * !a != 0)
bar ();
}

% gcc-12.0.0 -O2 --param early-inlining-insns=0 -c ljkqy0ae.c
during IPA pass: inline
ljkqy0ae.c:19:1: internal compiler error: in
evaluate_conditions_for_known_args, at ipa-fnsummary.c:516
   19 | }
  | ^
0x6d8bdb evaluate_conditions_for_known_args
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-fnsummary.c:516
0xc4732d do_estimate_edge_size(cgraph_edge*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline-analysis.c:330
0xc48aa7 estimate_edge_size
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.h:79
0xc48aa7 estimate_edge_growth
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.h:100
0xc48aa7 do_estimate_growth_1
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline-analysis.c:429
0xc48b2e cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/cgraph.h:3411
0xc48b2e estimate_growth(cgraph_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline-analysis.c:467
0x1ca09ef inline_small_functions
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.c:1980
0x1ca09ef ipa_inline
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.c:2743
0x1ca09ef execute
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.c:3142

[Bug ipa/103461] [12 Regression] ICE in operator_div::wi_fold

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug ipa/103461] New: [12 Regression] ICE in operator_div::wi_fold

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103461
   Summary: [12 Regression] ICE in operator_div::wi_fold
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

gcc-12.0.0-alpha20211128 snapshot (g:2899d49e3701a4df18a336a680a7095cc99a2229)
ICEs when compiling the following testcase w/ -O2:

int
baz (int c);

int
bar (int a, int b)
{
  return baz (a && (b / 0));
}

int
foo (int a, short int b)
{
  return bar (a, b);
}

% gcc-12.0.0 -O2 -w -c drnnxgu8.c
during IPA pass: inline
drnnxgu8.c:14:1: internal compiler error: Segmentation fault
   14 | }
  | ^
0xeaadef crash_signal
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/toplev.c:322
0x1d1e040 operator_div::wi_fold(irange&, tree_node*,
generic_wide_int const&, generic_wide_int
const&, generic_wide_int const&,
generic_wide_int const&) const
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/range-op.cc:1836
0x1d11cd7 range_operator::wi_fold_in_parts(irange&, tree_node*,
generic_wide_int const&, generic_wide_int
const&, generic_wide_int const&,
generic_wide_int const&) const
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/range-op.cc:192
0x1d12634 range_operator::fold_range(irange&, tree_node*, irange const&, irange
const&, tree_code) const
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/range-op.cc:214
0x116b949 range_fold_binary_expr(int_range<1u>*, tree_code, tree_node*,
int_range<1u> const*, int_range<1u> const*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/tree-vrp.c:1080
0xc2aad5 evaluate_conditions_for_known_args
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-fnsummary.c:511
0xc4732d do_estimate_edge_size(cgraph_edge*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline-analysis.c:330
0xc48aa7 estimate_edge_size
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.h:79
0xc48aa7 estimate_edge_growth
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.h:100
0xc48aa7 do_estimate_growth_1
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline-analysis.c:429
0xc48b2e cgraph_node::call_for_symbol_and_aliases(bool (*)(cgraph_node*,
void*), void*, bool)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/cgraph.h:3411
0xc48b2e estimate_growth(cgraph_node*)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline-analysis.c:467
0x1ca09ef inline_small_functions
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.c:1980
0x1ca09ef ipa_inline
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.c:2743
0x1ca09ef execute
   
/var/tmp/portage/sys-devel/gcc-12.0.0_p20211128/work/gcc-12-20211128/gcc/ipa-inline.c:3142

[Bug middle-end/60070] An option to disable all floating-pont

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

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

--- Comment #3 from Andrew Pinski  ---
For x86_64, the option was added with PR 70738.

I don't know if this would be an useful option that is general though. Each
target will implement it differently too.

[Bug target/61810] init-regs.c papers over issues elsewhere

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

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

--- Comment #6 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577192.html

[Bug tree-optimization/64992] More optimize opportunity

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
The missed optimization is:
int f(int c)
{
  unsigned t = c == 1;
  t <<= 1;
  return t == 0;
}

int f1(int c)
{
  unsigned t = c == 1;
  return ((int)t) <= 0;
}

That is (t << 1) == 0 should be convert into either:
(t & 0x7fff) or ((int)t) <= 0

Though the (semi more) general case is:
(for shift (lshift rshift)
 (for eqne (eq ne)
  (simplify
   (eqne (shift @0 INTEGER_CST@1) integer_zerop@2)
   (with
{
  mask = ...
}
(eqne (bit_and @0 { mask; }) @2)

And then the mask bit_and neeq to gtle

And then the rest will just work

[Bug target/102239] powerpc suboptimal boolean test of contiguous bits

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

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

--- Comment #6 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #5)
> (In reply to luoxhu from comment #4)
> > Simply adjust the sequence of dot instruction could produce expected code,
> > is this correct?
> 
> No it isn't.  Sorry.

Sorry I don't understand what is wrong...

> 
> > foo:
> > .LFB0:
> > .cfi_startproc
> > rldicr. 3,3,29,1
> > beq 0,.L2
> 
> This is fine, but only because it tests the EQ bit (not the LT or GT bits).
> So the generated RTL for this insn (the 2insn one) is not correct.

The generated RTL in pr102239.c.300r.split2 is:

(insn 32 8 33 2 (parallel [
(set (reg:CC 100 0 [123])
(compare:CC (and:DI (ashift:DI (reg:DI 3 3 [124])
(const_int 29 [0x1d]))
(const_int -4611686018427387904 [0xc000]))
(const_int 0 [0])))
(clobber (reg:DI 3 3 [125]))
]) "pr102239.c":4:6 238 {*rotldi3_mask_dot}
 (nil))
(insn 33 32 10 2 (set (reg:DI 3 3 [125])
(lshiftrt:DI (reg:DI 3 3 [125])
(const_int 29 [0x1d]))) "pr102239.c":4:6 278 {lshrdi3}
 (nil))
(jump_insn 10 33 11 2 (set (pc)
(if_then_else (eq (reg:CC 100 0 [123])
(const_int 0 [0]))
(label_ref 15)
(pc))) "pr102239.c":4:6 868 {*cbranch}
 (int_list:REG_BR_PROB 536870916 (nil))
 -> 15)


rotldi3_mask_dot is what you mentioned in c#1, it is a shifted result and not
matter for comparing to 0:

> *rotl3_mask_dot cannot do this either; the base and the dot2 of that
> cannot be done, they return a shifted result, but that doesn't matter for
> comparing it to 0.  So we should add a specialised version.

What specialized version to add?

[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #20 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #18)
> (In reply to Uroš Bizjak from comment #17)
> > (In reply to Hongtao.liu from comment #16)
> > 
> > > ix86_expand_vector_set is mainly used by vec_set_optab which exactly takes
> > > target as both input and output, it seems we can't create a new target for
> > > that.
> > 
> > OK, let's try to optimize it with gen_pinsr, as you proposed.
> > 
> > (It looks that the add-on patch from Comment #6 will generate VPBLEND in
> > this case, too.)
> 
> We should manually generate vinsertps from truncsfhf2, too. There is no
> point to call ix86_expand_vector_set if we already know the instruction. It
> will use vec_set_0 insn pattern, which has quite some
> alternatives.

For AVX2, your attached patch will optimize

vpxor   %xmm2, %xmm2, %xmm2
-   vpbroadcastw%xmm1, %xmm1
-   vpbroadcastw%xmm0, %xmm0
vpblendw$1, %xmm0, %xmm2, %xmm0
vpblendw$1, %xmm1, %xmm2, %xmm2
vcvtph2ps   %xmm2, %xmm2

Since upper bits of xmm1/xmm0 is not selected by vpblendw.

[Bug rtl-optimization/50677] volatile forces load into register

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug middle-end/60089] Complex arithmetic instructions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization

--- Comment #5 from Andrew Pinski  ---
The way we model these instructions these days is using vector modes.

[Bug middle-end/53875] calls to const functions are eliminated at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #5 from Andrew Pinski  ---
diff --git a/gcc/calls.c b/gcc/calls.c
index 27b59f26ad3..f23dde58671 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -2735,7 +2735,8 @@ expand_call (tree exp, rtx target, int ignore)
   && (!(flags & ECF_LOOPING_CONST_OR_PURE))
   && (flags & ECF_NOTHROW)
   && (ignore || target == const0_rtx
- || TYPE_MODE (rettype) == VOIDmode))
+ || TYPE_MODE (rettype) == VOIDmode)
+  && !optimize)
 {
   bool volatilep = false;
   tree arg;

[Bug middle-end/53875] calls to const functions are eliminated at -O0

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #3)
> The code which introduced this was
> g:8c6a82695b85f8ed74cdc67f2cf74c5a62d0d91d .

https://gcc.gnu.org/pipermail/gcc-patches/2003-May/104797.html

[Bug middle-end/53875] calls to const functions are eliminated at -O0

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||3.3.3
  Known to fail||3.4.0

--- Comment #3 from Andrew Pinski  ---
The code which introduced this was g:8c6a82695b85f8ed74cdc67f2cf74c5a62d0d91d .

[Bug target/102811] vcvtph2ps and vcvtps2ph should be used to convert _Float16 to SFmode with -mf16c

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #19 from Hongtao.liu  ---
(In reply to Uroš Bizjak from comment #17)
> (In reply to Hongtao.liu from comment #16)
> 
> > ix86_expand_vector_set is mainly used by vec_set_optab which exactly takes
> > target as both input and output, it seems we can't create a new target for
> > that.
> 
> OK, let's try to optimize it with gen_pinsr, as you proposed.
> 
> (It looks that the add-on patch from Comment #6 will generate VPBLEND in
> this case, too.)

I think your attached patch is a seperate optimization, the new added
alternatives which generates VPBLEND extend the pattern to accept sse register
for the inserted value, currently we only have "rm".

[Bug middle-end/59711] ICE in force_constant_size, at gimplify.c:619 with variably-modified return type

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |6.0
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70093
 Resolution|--- |FIXED
   Keywords||ice-on-valid-code
 Status|NEW |RESOLVED

--- Comment #9 from Andrew Pinski  ---
Fixed in GCC 6, by the patch which fixed PR 70093.

[Bug c++/103460] New: GCC rejected operator[](auto[]...) after P2128

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 103460
   Summary: GCC rejected operator[](auto[]...) after P2128
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This should be well-formed after P2128, please correct me if I am wrong.

struct S {
  void operator[](auto[]...);
};

https://godbolt.org/z/renf6nePj

[Bug fortran/50463] [4.6/4.7 Regression] -ftree-dse leeds to wrong code with gfortran

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||strasbur at chkw386 dot 
ch.pwr.wro
   ||c.pl

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

[Bug middle-end/58270] Wrong code while accessing trailing array elements in a global common structure

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=53086
 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #22 from Andrew Pinski  ---
Invalid as mentioned and a dup as mentioned.

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

[Bug middle-end/50808] Diagnostic output at expansion time should be moved earlier.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2011-10-20 00:00:00 |2021-11-28

--- Comment #4 from Andrew Pinski  ---
>* gcc.dg/noncompile/invalid_asm.c: Likewise.
>* gcc.dg/noncompile/920507-1.c: Likewise.

These still fail with non-fat LTO.
The rest I think should not pass with non-fat LTO.

[Bug ipa/46554] Less inlining leads to CSiBE regression

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |ipa
   Keywords||missed-optimization
 CC||marxin at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
Many things has changed since GCC 4.6 with respect to the inliner, has this
been fixed?

[Bug c++/97681] noinline attribute ignored on constexpr function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-debug
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=93008

--- Comment #8 from Andrew Pinski  ---
Plus newer versions of C++ are relaxing constexpr even more and GCC added
-fimplicit-constexpr which enables implicit constexpr for inline functions. 

Also constexpr have an implicit inline too, see PR 93008.

[Bug c++/93008] Need a way to make inlining heuristics ignore whether a function is inline

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/65503] g++ string array in struct crash

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
I suspect PR 92385 is a similar issue as here.

[Bug other/103021] Make the path to etags used in the build system configurable

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

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/585614.html

--- Comment #2 from Eric Gallager  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585614.html

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

[jiangning.liu at amperecomputing dot com via Gcc-bugs]

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

--- Comment #7 from Jiangning Liu  ---
Without reverting the commit g:1118a3ff9d3ad6a64bba25dc01e7703325e23d92, we
still see exchange2 performance issue for aarch64. BTW, we have been using
-fno-inline-functions-called-once to get the best performance number for
exchange2.

[Bug other/19089] Environment variable TMP may yield gcc: abort with internal error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Fixed. Sorry it took so long in fixing this issue.

[Bug other/19089] Environment variable TMP may yield gcc: abort with internal error

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

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:68332ab7ec58a89660db82569c5f4c2251d59741

commit r12-5568-g68332ab7ec58a89660db82569c5f4c2251d59741
Author: Andrew Pinski 
Date:   Sat Nov 27 18:16:50 2021 -0800

Fix PR 19089: Environment variable TMP may yield gcc: abort

Even though I cannot reproduce the ICE any more, this is still
a bug. We check already to see if we can access the directory
but never check to see if the path is actually a directory.

This adds the check and now we reject the file as not usable
as a tmp directory.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

libiberty/ChangeLog:

* make-temp-file.c (try_dir): Check to see if the dir
is actually a directory.

[Bug debug/24551] [meta-bug] -feliminate-unused-debug-types issues

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org,
   ||patrickdepinguin at gmail dot 
com

--- Comment #6 from Eric Gallager  ---
(In reply to Eric Gallager from comment #5)
> (In reply to Thomas De Schampheleire from comment #4)
> > Could it not be that #14167 is now fixed after fixing #86964 ?
> 
> is bug 86964 actually fixed? It's still open...

Never mind; NOW it's fixed...

[Bug c++/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

Eric Gallager  changed:

   What|Removed |Added

Summary|GCC should warn about 2^16  |GCC should warn about 2^16
   |and 2^32 and 2^64   |and 2^32 and 2^64
   ||[-Wxor-used-as-pow]

--- Comment #23 from Eric Gallager  ---
putting -Wxor-used-as-pow in the title since that's what clang went with

[Bug bootstrap/103459] New: Make configury regenerate cleanly with `autoreconf -Wall`

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

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

Bug ID: 103459
   Summary: Make configury regenerate cleanly with `autoreconf
-Wall`
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build
  Severity: enhancement
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: egallager at gcc dot gnu.org
  Target Milestone: ---

autoreconf comes with a -Wall flag (much like gcc's) that warns about
questionable and/or outdated autoconf/automake practices:
https://www.gnu.org/software/autoconf/manual/autoconf-2.69/html_node/autoreconf-Invocation.html
Currently when using this flag, it prints many warnings on gcc's various
configuration files; there are a lot of them, so I'm not going to paste them
here. It would be nice if we could silence these warnings so that we could use
that flag cleanly.

[Bug tree-optimization/103458] [12 Regression] ICE in verify_loop_structure, at cfgloop.c:1736 (error: loop with header 4 not in loop tree)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||needs-bisection
   Last reconfirmed||2021-11-29
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed. It looks like a latent bug though.

[Bug tree-optimization/103458] [12 Regression] ICE in verify_loop_structure, at cfgloop.c:1736 (error: loop with header 4 not in loop tree)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/103456] [12 Regression] gcc/gcc.c:9502:8: runtime error: load of address 0x0000009f5037 with insufficient space for an object of type 'const char' since r12-5548-g4a2007594cff78

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |blocker

[Bug tree-optimization/81174] bswap not recognized in |= statement

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86723

--- Comment #4 from Andrew Pinski  ---
This is fixed on the trunk.  I want to say the  r12-3072-gb320edc0c29c838b00
(PR86723) is what fixed this.

[Bug tree-optimization/103457] boolean operations on bit-fields are not merged

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #2 from Roland Illig  ---
Cool, thank you for taking this optimization.

Just to give you a bit of background: I discovered this while converting some
of the enum types in BSD Make to proper bitfields, which theoretically should
be possible without affecting the generated code.

https://github.com/NetBSD/src/blob/trunk/usr.bin/make/make.h

It was interesting to play around with this code on https://godbolt.org/,
seeing how differently the available compilers translate this simple code
fragment. That's where the Intel assembler syntax comes from. :)

[Bug c++/90782] internal compiler error: in dependent_type_p, at cp/pt.c:25409

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection

--- Comment #7 from Andrew Pinski  ---
This looks fixed on the trunk.

[Bug c++/103455] [9/10/11/12 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:27057

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

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

--- Comment #5 from Andrew Pinski  ---
Reduced:
template 
struct rp {
T* operator->() const;
operator T*() const;
template  explicit operator U*() const;
};
struct b {};
typedef void (b::*fptr)();
void foo(rp n, fptr h) {
(n->*h)();
}

[Bug sanitizer/100987] make distclean error "hwasan: No such file or directory"

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

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

Bug 62157 Summary: make distclean error when libsanitizer is configured not to 
build 'tsan'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62157

   What|Removed |Added

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

[Bug bootstrap/3415] make distclean (in gcc subdirectory) does not clean up all the way

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

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

Bug 62157 Summary: make distclean error when libsanitizer is configured not to 
build 'tsan'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62157

   What|Removed |Added

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

[Bug sanitizer/62157] make distclean error when libsanitizer is configured not to build 'tsan'

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
Fixed.

[Bug sanitizer/62157] make distclean error when libsanitizer is configured not to build 'tsan'

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

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

--- Comment #7 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

https://gcc.gnu.org/g:32377c101934477e3d27fec9c6a22f1c97ccf730

commit r12-5566-g32377c101934477e3d27fec9c6a22f1c97ccf730
Author: Andrew Pinski 
Date:   Sun Nov 28 01:14:59 2021 +

Fix PR 62157: disclean in libsanitizer not working

So what is happening is DIST_SUBDIRS contains the conditional
directories which is wrong, so we need to force DIST_SUBDIRS
to be the same as SUBDIRS as recommened by the automake manual.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.
Also now make distclean works inside libsanitizer directory.

libsanitizer/ChangeLog:

PR sanitizer/62157
* Makefile.am: Force DIST_SUBDIRS to be SUBDIRS.
* Makefile.in: Regenerate.
* asan/Makefile.in: Likewise.
* hwasan/Makefile.in: Likewise.
* interception/Makefile.in: Likewise.
* libbacktrace/Makefile.in: Likewise.
* lsan/Makefile.in: Likewise.
* sanitizer_common/Makefile.in: Likewise.
* tsan/Makefile.in: Likewise.
* ubsan/Makefile.in: Likewise.

[Bug tree-optimization/103457] boolean operations on bit-fields are not merged

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-28
   Severity|normal  |enhancement
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Andrew Pinski  ---
Mine for GCC 13. There is other bugs which are similar too.

[Bug target/103302] wrong code with -fharden-compares

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

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

--- Comment #5 from Alexandre Oliva  ---
Hello, Jim,

Thanks for the investigation, that's useful.  I guess the register allocator
shouldn't choose to coalesce registers when there's a clobber afterwards, or it
should drop the clobber, since otherwise it clobbers the coalesced set.

Anyway, I'm reworking the asm that prevents optimization because of bug 103149
and bug 103097, it might end up avoiding this unfortunate situation.  We'll
see...

[Bug tree-optimization/103458] New: [12 Regression] ICE in verify_loop_structure, at cfgloop.c:1736 (error: loop with header 4 not in loop tree)

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 103458
   Summary: [12 Regression] ICE in verify_loop_structure, at
cfgloop.c:1736 (error: loop with header 4 not in loop
tree)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-12.0.0-alpha20211121 snapshot (g:da17c304e22ba256eba0b03710aa329115163b08)
ICEs when compiling the following testcase w/ -O2:

__attribute__ ((returns_twice)) int
bar (void);

void
foo (int *p, int x)
{
  *p = 0;
  while (*p < 1)
{
  x = 0;
  while (x < 1)
bar ();

  x /= 0;
}

  foo (p, x);
}

% gcc-12.0.0 -O2 -w -c xiksrvsw.c
xiksrvsw.c: In function 'foo':
xiksrvsw.c:5:1: error: loop with header 4 not in loop tree
5 | foo (int *p, int x)
  | ^~~
during GIMPLE pass: cddce
xiksrvsw.c:5:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1736
0x6816e7 verify_loop_structure()
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/cfgloop.c:1736
0xdb8457 execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/passes.c:2058
0xdb8cbe execute_todo
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20211121/work/gcc-12-20211121/gcc/passes.c:2096

[Bug tree-optimization/103457] New: boolean operations on bit-fields are not merged

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 103457
   Summary: boolean operations on bit-fields are not merged
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

~~~c
#include 

typedef struct GNodeFlagsS {
bool remake:1;
bool childMade:1;
bool force:1;
bool doneWait:1;
bool doneOrder:1;
bool fromDepend:1;
bool doneAllsrc:1;
bool cycle:1;
bool doneCycle:1;
} GNodeFlags;

bool
GNodeFlags_IsNone(GNodeFlags flags)
{
return !flags.remake
   && !flags.childMade
   && !flags.force
   && !flags.doneWait
   && !flags.doneOrder
   && !flags.fromDepend
   && !flags.doneAllsrc
   && !flags.cycle
   && !flags.doneCycle;
}
~~~

On x86_64, GCC 11.2 generates:

~~~asm
GNodeFlags_IsNone(GNodeFlagsS):
mov eax, edi
and eax, 1
jne .L6
testdil, 2
jne .L1
mov eax, edi
shr ax, 2
and eax, 1
jne .L6
testdil, 8
jne .L1
mov eax, edi
shr ax, 4
and eax, 1
jne .L6
testdil, 32
jne .L1
mov eax, edi
shr ax, 6
and eax, 1
jne .L6
testdil, dil
js  .L1
shr di, 8
mov eax, edi
and eax, 1
xor eax, 1
ret
.L6:
xor eax, eax
.L1:
ret
~~~

ICC 2021.3.0 generates shorter code:

~~~asm
test  edi, 1#18.10
jne   ..B1.10   # Prob 50%  #18.10
test  edi, 2#19.13
jne   ..B1.10   # Prob 50%  #19.13
test  edi, 4#20.13
jne   ..B1.10   # Prob 50%  #20.13
(and so on)
~~~

Many other compilers fail to see the potential for optimizing this code as
well.

Clang is better, it generates:

~~~asm
GNodeFlags_IsNone(GNodeFlagsS): # @GNodeFlags_IsNone(GNodeFlagsS)
testedi, 511
seteal
ret
~~~

[Bug c++/103455] [9/10/11/12 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:27057

[stha09 at googlemail dot com via Gcc-bugs]

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

--- Comment #4 from Stephan Hartmann  ---
Last working compiler was gcc-8.1, gcc-8.2 and later produce an ICE.

[Bug rtl-optimization/98782] [11/12 Regression] Bad interaction between IPA frequences and IRA resulting in spills due to changes in BB frequencies

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

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

--- Comment #6 from Jan Hubicka  ---
I am sorry for getting back to this again late.  This stage1 we spent some time
with Martin improving the ipa-cp profile updating and looked again into the
realism of the profile. Also recently the codegen has improved somewhat due to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227 and due to modref
propagation.

I still believe for trunk GCC we should not have patch that intentionally makes
profile unrealistic just to make IRA work better by accident since it does not
seem to help anything real world except this somewhat odd benchmark. So I
wonder if we can make profile to work better for IRA without actually making it
unrealistic and tampering with ipa-cp cloning heuristics

I added code that compares guessed profile with feedback
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585599.html
and also fixed/improved code to dump stats about profile updates
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585578.html

This gives bit more handle on how realistic the profile is.  Answer is that not
very in general, but at least for basic blocks containing calls it is not bad
(we guess 0.9 while relity is 0.999).
I am not sure how much better we can do statically since this is such a special
case of backtracking.

Last week we also noticed that with -Ofast we inline the newly produced clones
together which makes IRA job a lot harder.  This is done by
-finline-functions-called-once and we tend to inline blocks of 2 or 3 clones
leading to 18 or 27 nested loops in each.  Simply disabling this optimization
gets another performance hit.

I filled in PR https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103454 and I think
we could teach the inliner to not inline functions called once in large loop
depths and restrict the large functions growths here since there are multiple
benchmarks that now degrade on this.

Worse yet, the heuristics for inlininig functions called once is not very smart
and it depends on the order of cgrpah_nodes in the linked list which is bit
random.

I wonder how the situation looks on AArch64?

[Bug c++/103455] [9/10/11/12 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:27057

[stha09 at googlemail dot com via Gcc-bugs]

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

--- Comment #3 from Stephan Hartmann  ---
Scratch comment 2, copied wrong one:

template 
struct raw_ptr {
T* operator->() const;
operator T*() const;
template 
explicit operator U*() const;
};

struct bar {};

struct foo {
typedef void (bar::*GenFunc)();
foo(GenFunc gen_func) {
(bar_->*gen_func)();
}
raw_ptr bar_;
};

It compiles with clang-12 and clang-13.

[Bug c++/103455] [9/10/11/12 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:27057

[stha09 at googlemail dot com via Gcc-bugs]

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

--- Comment #2 from Stephan Hartmann  ---
Handwritten reduced testcase:

template 
struct raw_ptr {
T* operator->() const;
template 
explicit operator U*() const;
};

struct bar {
   static void func(); 
};

struct foo {
typedef void (bar::*GenFunc)();
foo(GenFunc gen_func) {
(bar_->*gen_func)();
}
raw_ptr bar_;
};

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

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

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

Bug 103227 Summary: [12 Regression] 58% exchange2 regression with -Ofast 
-march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103227

   What|Removed |Added

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

[Bug ipa/103227] [12 Regression] 58% exchange2 regression with -Ofast -march=native on zen3 since r12-5223-gecdf414bd89e6ba251f6b3f494407139b4dbae0e

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

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

Jan Hubicka  changed:

   What|Removed |Added

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

--- Comment #15 from Jan Hubicka  ---
Fixed.

[Bug tree-optimization/101540] CONSTRUCTOR for vector(1) should just be VCE

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

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

Andrew Pinski  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2021-Novembe
   ||r/585597.html
   Keywords||patch

--- Comment #3 from Andrew Pinski  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585597.html

[Bug c++/103455] [9/10/11/12 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:27057

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||8.2.0
   Keywords||ice-on-invalid-code
   Target Milestone|--- |9.5
  Known to work|8.5.0   |

[Bug c++/103455] [9/10/11/12 Regression] internal compiler error: in dependent_type_p, at cp/pt.c:27057

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|internal compiler error: in |[9/10/11/12 Regression]
   |dependent_type_p, at|internal compiler error: in
   |cp/pt.c:27057   |dependent_type_p, at
   ||cp/pt.c:27057
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-11-28
 Ever confirmed|0   |1
  Known to fail||10.1.0, 11.1.0, 9.1.0
  Known to work||7.1.0, 8.1.0, 8.5.0

--- Comment #1 from Andrew Pinski  ---
I know this reduced testcase was invalid but the original code was valid. Is
there a way to reduce this again to see if it is valid (maybe by compiling with
GCC 8 or 7 or even clang too)?


Confirmed.

[Bug fortran/103261] ICE in gfc_check_reshape, at fortran/check.c:4742

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
These all appear to be fixed by the patch in:

https://gcc.gnu.org/pipermail/fortran/2021-November/057066.html

[Bug tree-optimization/103456] [12 Regression] gcc/gcc.c:9502:8: runtime error: load of address 0x0000009f5037 with insufficient space for an object of type 'const char' since r12-5548-g4a2007594cff78

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
   Last reconfirmed||2021-11-28
   Target Milestone|--- |12.0
 Ever confirmed|0   |1

[Bug tree-optimization/103456] New: [12 Regression] gcc/gcc.c:9502:8: runtime error: load of address 0x0000009f5037 with insufficient space for an object of type 'const char' since r12-5548-g4a2007594

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

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

Bug ID: 103456
   Summary: [12 Regression] gcc/gcc.c:9502:8: runtime error: load
of address 0x009f5037 with insufficient space for
an object of type 'const char' since
r12-5548-g4a2007594cff78fba6a29a0ec07fad31a7af19ff
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: siddhesh at redhat dot com
  Target Milestone: ---

GCC UBSAN bootstrap is broken since the revision:
../configure --with-build-config=bootstrap-ubsan --enable-languages=c,c++
--disable-multilib --enable-shared

/home/marxin/Programming/gcc/objdir/./gcc/xgcc
-B/home/marxin/Programming/gcc/objdir/./gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -B/usr/local/x86_64-pc-linux-gnu/lib/
-isystem /usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include   -fno-checking -g -O2 -O2  -g -O2
-DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
-Wno-error=format-diag -Wstrict-prototypes -Wmissing-prototypes
-Wno-error=format-diag -Wold-style-definition  -isystem ./include  -fpic
-mlong-double-80 -DUSE_ELF_SYMVER -fcf-protection -mshstk -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector  -fpic -mlong-double-80 -DUSE_ELF_SYMVER
-fcf-protection -mshstk -I. -I. -I../.././gcc -I../../../libgcc
-I../../../libgcc/. -I../../../libgcc/../gcc -I../../../libgcc/../include
-I../../../libgcc/config/libbid -DENABLE_DECIMAL_BID_FORMAT -DHAVE_CC_TLS 
-DUSE_TLS  -o _divdc3.o -MT _divdc3.o -MD -MP -MF _divdc3.dep -DL_divdc3 -c
../../../libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS
../../gcc/gcc.c:9494:11: runtime error: load of address 0x009f5034 with
insufficient space for an object of type 'const char'
0x009f5034: note: pointer points here
  6d 36 34 20 6d 36 34 3b  6d 33 32 20 6d 33 32 3b  00 00 00 00 00 00 00 00  21
00 00 00 00 00 00 00
  ^ 
#0 0x43f0ee in used_arg_t::operator()(char const*, int)
../../gcc/gcc.c:9494
#1 0x441ba9 in set_multilib_dir ../../gcc/gcc.c:9797
#2 0x441ba9 in driver::set_up_specs() const ../../gcc/gcc.c:8544
#3 0x412dc6 in driver::main(int, char**) ../../gcc/gcc.c:8126
#4 0x413987 in main ../../gcc/gcc-main.c:47
#5 0x77ce05bf in __libc_start_call_main (/lib64/libc.so.6+0x405bf)
#6 0x77ce067b in __libc_start_main_alias_2 (/lib64/libc.so.6+0x4067b)
#7 0x413b04 in _start
(/home/marxin/Programming/gcc/objdir/gcc/xgcc+0x413b04)

../../gcc/gcc.c:9494:11: runtime error: load of address 0x009f5034 with
insufficient space for an object of type 'const char'
0x009f5034: note: pointer points here
  6d 36 34 20 6d 36 34 3b  6d 33 32 20 6d 33 32 3b  00 00 00 00 00 00 00 00  21
00 00 00 00 00 00 00
  ^ 
#0 0x43f101 in used_arg_t::operator()(char const*, int)
../../gcc/gcc.c:9494
#1 0x441ba9 in set_multilib_dir ../../gcc/gcc.c:9797
#2 0x441ba9 in driver::set_up_specs() const ../../gcc/gcc.c:8544
#3 0x412dc6 in driver::main(int, char**) ../../gcc/gcc.c:8126
#4 0x413987 in main ../../gcc/gcc-main.c:47
#5 0x77ce05bf in __libc_start_call_main (/lib64/libc.so.6+0x405bf)
#6 0x77ce067b in __libc_start_main_alias_2 (/lib64/libc.so.6+0x4067b)
#7 0x413b04 in _start
(/home/marxin/Programming/gcc/objdir/gcc/xgcc+0x413b04)

[Bug target/63691] GCC 4.9.x fails to build GLIBC 2.20 on HPPA

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

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

John David Anglin  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #15 from John David Anglin  ---
Fixed.

[Bug c++/103455] New: internal compiler error: in dependent_type_p, at cp/pt.c:27057

[stha09 at googlemail dot com via Gcc-bugs]

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

Bug ID: 103455
   Summary: internal compiler error: in dependent_type_p, at
cp/pt.c:27057
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: stha09 at googlemail dot com
  Target Milestone: ---

Reduced testcase:

class raw_ptr {
  template  operator U *();
};
class GLES2Interface class ScopedGLuint {
  typedef void (GLES2Interface::*DeleteFunc)();
  ScopedGLuint(){gl_->*delete_func_} raw_ptr gl_;
  DeleteFunc delete_func_;
};

Original code is here:
https://chromium.googlesource.com/chromium/src/+/refs/heads/main/gpu/command_buffer/client/gl_helper.h#49

It seems GCC doesn't like the function pointer. There are some other locations
where the same happens in the Chromium codebase.

[Bug c++/102609] [C++23] P0847R7 - Deducing this

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-11-28

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

[Bug libstdc++/103448] unexpected tuple collapse

[janezz55 at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Janez Zemva  ---
The code worked for ((...), (...), ...), but not for ((...)), I did not
understand how a tuple not containing another tuple could possibly be
constructed. On the other hand, I already found a workaround and I already
asked a question on SO and it was the folks there who advised incorrectly, that
I should construct the top tuple using std::tuple() and not std::make_tuple().
The only place remaining to write anything in was therefore here.

[Bug tree-optimization/101540] CONSTRUCTOR for vector(1) should just be VCE

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I think I have a patch.

Basically adding this to simplify_vector_constructor should work for most
cases.

  if (nelts == 1 && CONSTRUCTOR_NELTS (op) == 1)
{
  tree op1 = CONSTRUCTOR_ELT (op, 0);
  if (useless_type_conversion_p (elem_type, TREE_TYPE (op1)))
{
  op1 = build1 (VIEW_CONVERT_EXPR, type, op1);
  gimple_assign_set_rhs_from_tree (gsi, op1);
  update_stmt (gsi_stmt (*gsi));
  return true;
}
}

[Bug middle-end/103454] New: -finline-functions-called-once is both compile-time and runtime loss at average for spec2006, spec2017 and tramp3d

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

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

Bug ID: 103454
   Summary: -finline-functions-called-once is both compile-time
and runtime loss at average for spec2006, spec2017 and
tramp3d
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Looking into exchange2 performance I run benchmarks with
-fno-inline-functions-called-once.  It seems we do have important regressions
here.

The following compares default flags (base) and run with additional
-fno-inline-functions-called-once
https://lnt.opensuse.org/db_default/v4/CPP/latest_runs_report?younger_in_days=14_in_days=0_changes=on_percentage_change=0.01=c53447034965e4191a8738f045a3c7d1552d5f59%2C67b183fac7b08067fdd3c09abd3efd2691083395_user_branches=on

https://lnt.opensuse.org/db_default/v4/SPEC/latest_runs_report?younger_in_days=14_in_days=0_changes=on_percentage_change=0.01=c53447034965e4191a8738f045a3c7d1552d5f59%2C67b183fac7b08067fdd3c09abd3efd2691083395_user_branches=on

Large differences are

default flags wins
 - fatigue2 with both -O2 and -Ofast inlining 40%

-fno-inline-functions-called-once wins:
 - tramp3d with -Ofast. 31%
 - exchange2 with -Ofast 11-21%
 - specfp2006 total build time 41% (mostly wrf that builds 71% faster)
 - specint2005 total about 1.5-3%
 - specfp2017 total 64% (again mostly wrf)
 - specint2017 total 2.5-3.5%

Once more tests are run I can make better summary.  It is couple releases since
I benchmarked -fno-inline-functions-called-once so I am not quite sure how long
we have the problem.

For exchange2 the problem is inlining different clones of digits2 into each
other. Each clone of digits2 has 9 nested loop and calls the other clone from
innermost one.  I guess we may want to have loop depth limit on inlining once
and also have its own specific large-functions-insns and growth (in particular,
I think the growth wants to be smaller, like say 10% instead of letting
function grow twice).

It also shows however that we have problems in middle-end both in scalability
and code quality on large CFGs which are probably quite important (and anoying)
to track down.