[Bug tree-optimization/37810] Bad store sinking job

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

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

--- Comment #7 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> The original testcase (from an IRC discussion) reduced to a C testcase is:
> 
> struct A {
>   int n;
>   int m;
> };
> 
> void g();
> 
> void test (struct A* iter)
> {
>   struct A end = { 0, 0 };
>   while (iter->n != end.n)
> {
>   iter->n = iter->n + 1;
>   if (iter->n == iter->m)
> g();
> }
> }
> 
> where there is an optimization possibility to sink the store to iter->n to
> before the call and apply load-store motion to iter->n for the remaining
> loop.

So to clarify the desired code would look like

void test (struct A* iter)
{
  struct A end = { 0, 0 };
  int tem = iter->n;
  while (tem != end.n)
{
  tem = tem + 1;
  if (tem == iter->m)
{
  iter->n = tem;
  g();
  tem = iter->n;
}
}
  iter->n = tem;
}

PRE does half of the job, but then sinking would need to duplicate the store
on the loop exit, something it currently cannot do (the logic is to duplicate
to two places less frequently executed).

[Bug c++/84893] Rejects a valid code with variadic function template taking a function pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #2)
> EDG accepts it but Clang doesn't:
> 
> 84893.cc:7:5: error: no matching function for call to 'f'
> f(g);
> ^~~
> 84893.cc:2:6: note: candidate template ignored: failed template argument
> deduction
> void f(void(*)(T..., int)) { }
>  ^
> 1 error generated.

clang started to accept it in clang 7.

Confirmed.

[Bug c++/56190] GCC fails deducing a "void(*)(int, float, double)" to a "void(*)(T..., float, double)" with T={int}

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-27
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug c++/84893] Rejects a valid code with variadic function template taking a function pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Dup of bug 56190.

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

[Bug c++/56190] GCC fails deducing a "void(*)(int, float, double)" to a "void(*)(T..., float, double)" with T={int}

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||v.reshetnikov at gmail dot com

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

[Bug c++/66670] "template argument deduction/substitution failed" with function pointers and multiple parameter packs

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||56190

--- Comment #4 from Andrew Pinski  ---
I suspect PR 56190 is very much the same bug.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56190
[Bug 56190] GCC fails deducing a "void(*)(int, float, double)" to a
"void(*)(T..., float, double)" with T={int}

[Bug c++/97999] pass address of instance of function template to another instance of the same function template with placeholder return type

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
This is a dup of bug 64194 which is fixed for GCC 10.3.

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

[Bug c++/64194] [C++14] for function template with auto return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||spartan_117 at juno dot com

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

[Bug c++/84857] A valid call to a template function in a variadic template struct is rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed|2018-03-14 00:00:00 |2021-7-27
   Keywords||ice-on-invalid-code

--- Comment #2 from Andrew Pinski  ---
Note if you do (instead of the last line):
int t = S::f<0>();

On the trunk we produce an ICE:
:9:26: internal compiler error: tree check: accessed elt 1 of
'tree_vec' with 0 elts in tsubst_pack_expansion, at cp/pt.c:13047
9 | int t = S::f<0>();
  | ~^~

[Bug debug/101633] New: [debug] DW_TAG_subrange_type missing DW_AT_upper_bound

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

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

Bug ID: 101633
   Summary: [debug] DW_TAG_subrange_type missing DW_AT_upper_bound
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Filing FTR. ]

Consider gdb test-case p.adb / pck.adb / pck.ads (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite/gdb.ada/array_of_variant
).

When compiling like this:
...
$ gcc -S -fgnat-encodings=minimal -g p.adb -dA
...
we have with gcc 7.5.0:
...
.uleb128 0x16   # (DIE (0x156) DW_TAG_array_type)
.long   .LASF14 # DW_AT_name: "p__array_t"
.long   0x145   # DW_AT_type
.long   0x169   # DW_AT_sibling
.uleb128 0x17   # (DIE (0x163) DW_TAG_subrange_type)
.long   0x13e   # DW_AT_type
.byte   0   # end of children of DIE 0x156
...
and the gdb test-case fails like this:
...
(gdb) print objects^M
$1 = ((tag => object, values => ()), (tag => unused))^M
(gdb) FAIL: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
...

In constrast, with gcc 8.5.0, we have:
...
.uleb128 0x15   # (DIE (0x13b) DW_TAG_array_type)
.long   .LASF14 # DW_AT_name: "p__array_t"
.long   0x12a   # DW_AT_type
.long   0x153   # DW_AT_sibling
.uleb128 0x16   # (DIE (0x148) DW_TAG_subrange_type)
.long   0x123   # DW_AT_type
.uleb128 0x4# DW_AT_upper_bound
.byte   0x91# DW_OP_fbreg
.sleb128 -72
.byte   0x6 # DW_OP_deref
.byte   0   # end of children of DIE 0x13b
...
and the failing test passes like this:
...
(gdb) print objects^M
$1 = ((tag => object, values => (2, 2, 2, 2, 2)), (tag => unused))^M
(gdb) PASS: gdb.ada/array_of_variant.exp: scenario=minimal: print entire array
...

[Bug c++/91099] constexpr vs -frounding-math

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

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

Marc Glisse  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Marc Glisse  ---
Interestingly, Jakub's patch has the same issue my patch here had: "defeated by
constexpr-caching if we change flag_rounding_math in the middle of a
translation unit".

constexpr double f(){return 1./3.;}
#if BUG
__attribute__((optimize("no-rounding-math")))
double g(){
  double d=f();
  return d;
}
#endif
__attribute__((optimize("rounding-math")))
double h(){
  double d=f();
  return d;
}

The presence of g changes the code we generate for h. At least we don't seem to
reuse the cache from a different value of manifestly_const_eval, so maybe
changing rounding_math is just not supported and this goes in the list of
issues with attribute optimize.

[Bug target/39821] 120% slowdown with vectorizer

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

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

--- Comment #6 from Richard Biener  ---
0x398f310 _2 * _4 1 times scalar_stmt costs 12 in body
...
0x392b3f0 _1 w* _3 2 times vec_promote_demote costs 8 in body
...
t4.c:4:12: note:  Cost model analysis:
  Vector inside of loop cost: 40
  Vector prologue cost: 4
  Vector epilogue cost: 108
  Scalar iteration cost: 40
  Scalar outside cost: 32
  Vector outside cost: 112
  prologue iterations: 0
  epilogue iterations: 2
  Calculated minimum iters for profitability: 3

so clearly the widening multiplication is not costed correctly.  With SSE 4.2
we can do better:

.L4:
movdqu  (%rcx,%rax), %xmm0
movdqu  (%rsi,%rax), %xmm1
addq$16, %rax
movdqa  %xmm0, %xmm3
movdqa  %xmm1, %xmm4
punpckldq   %xmm0, %xmm3
punpckldq   %xmm1, %xmm4
punpckhdq   %xmm0, %xmm0
pmuldq  %xmm4, %xmm3
punpckhdq   %xmm1, %xmm1
pmuldq  %xmm1, %xmm0
paddq   %xmm3, %xmm2
paddq   %xmm0, %xmm2
cmpq%rdi, %rax
jne .L4

but even there the costing is imprecise.  The vectorizer is unhelpful in
categorizing the widen mult as vec_promote_demote which then fails to
run into

case MULT_EXPR:
case WIDEN_MULT_EXPR:
case MULT_HIGHPART_EXPR:
  stmt_cost = ix86_multiplication_cost (ix86_cost, mode);
  break;

fixing that yields

0x392b3f0 _1 w* _3 2 times vector_stmt costs 136 in body

for both SSE2 and SSE4.2 and AVX2 so that's over-estimating cost then via

  /* V*DImode is emulated with 5-8 insns.  */
  else if (mode == V2DImode || mode == V4DImode)
{
  if (TARGET_XOP && mode == V2DImode)
return ix86_vec_cost (mode, cost->mulss * 2 + cost->sse_op * 3);
  else
return ix86_vec_cost (mode, cost->mulss * 3 + cost->sse_op * 5);
}

with cost->mulss == 16.  I suppose it is somehow failing to realize it's
doing a widening multiply.

[Bug c++/53506] Variadic templates in combination with function pointer problem

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||66670
   Keywords||rejects-valid
   Last reconfirmed|2017-08-20 00:00:00 |2021-7-27

--- Comment #3 from Andrew Pinski  ---
Note I do think the code is valid , some of this is recorded as PR 66670.

Looks like clang cannot deduce return type still.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66670
[Bug 66670] "template argument deduction/substitution failed" with function
pointers and multiple parameter packs

[Bug debug/101633] [debug] DW_TAG_subrange_type missing DW_AT_upper_bound

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

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #1 from Tom de Vries  ---
Fixed by:
...
commit 51f01fc387a2fb580108ccb27f945ee4bd1cfd34 (refs/bisect/bad)
Author: Richard Biener 
Date:   Tue May 16 11:00:59 2017 +

dwarf2out.c (loc_list_from_tree_1): Do not create DW_OP_GNU_variable_value
for DECL_IGNORED_P decls.

2017-05-16  Richard Biener  

* dwarf2out.c (loc_list_from_tree_1): Do not create
DW_OP_GNU_variable_value for DECL_IGNORED_P decls.

From-SVN: r248094

...
which was submitted here (
https://gcc.gnu.org/pipermail/gcc-patches/2017-May/474571.html ).

Fixed since release 8.1.0.

[Bug debug/101633] [debug] DW_TAG_subrange_type missing DW_AT_upper_bound

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

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

--- Comment #2 from Tom de Vries  ---
https://gcc.gnu.org/pipermail/gcc-patches/2017-May/474657.html :
...
>> 2017-05-15  Richard Biener  
>>
>>   * dwarf2out.c (loc_list_from_tree_1): Do not create
>>   DW_OP_GNU_variable_value for DECL_IGNORED_P decls.
>
> Can you verify it e.g. in a bootstrapped cc1plus doesn't change the debug info
> (except for dwarf2out.o itself)?
> It looks reasonable and it would surprise me if did, just want to be sure.

Done.  Note it only happened for Ada.
...

Heh, indeed it did.

[Bug middle-end/80053] Label with address taken should prevent duplication of containing basic block

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

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

--- Comment #15 from Alexander Monakov  ---
(In reply to Richard Biener from comment #14)
> I think the original asm goto case clearly remains and this is a difficult
> to handle case since the label address only appears as regular input and the
> goto target is statically represented in the CFG.  The testcase is
> miscompiled at -O2 already.
> 
> I think asm goto is prone to such miscompilation in general if combined with
> label addresses as inputs.  I don't think it was supposed to be used in this
> way so we might want to simply amend documentation to make such uses
> undefined ...  in fact one might read
> 
> "The
> @var{GotoLabels} section in an @code{asm goto} statement contains
> a comma-separated
> list of all C labels to which the assembler code may jump."
> 
> that jumps must jump to one of the labels literally (in the way documented
> later).

I don't see a contradiction? 'lp' holds the address of 'l'; label 'l' is listed
in the asm. It doesn't jump to anywhere but 'l'.

[Bug c++/77939] Valid program rejected due to access control

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Fixed for GCC 7, most likely by r7-5353.

[Bug c++/54235] Templates compile but don't link

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Fixed in GCC 8.0.

[Bug c++/101634] New: Vectorize optimisations trigger floating point exception

[gcc at wdqb dot uk via Gcc-bugs]

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

Bug ID: 101634
   Summary: Vectorize optimisations trigger floating point
exception
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at wdqb dot uk
  Target Milestone: ---

Created attachment 51208
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51208&action=edit
Code that reproduces the issue

I am using g++ 11.1.1 on OpenSUSE Tumbleweed 20210713.

When compiled with `g++ -O3 example.cpp` the code snippet triggers a floating
point exception and the program exits through the `signalHandler` function. I
believe this behaviour to be incorrect.

When compiled with `g++ -O3 -fno-tree-slp-vectorize example.cpp` (or any lower
level of optimisation) the exception is not triggered and the program exits
normally.

When compiled with any older version of `g++` with `O3` the exception is not
triggered and the program exits normally.

The program can also be modified to read it's input values from a file (see
commented section). This is shown to prove that the optimisation is not
dependent on the values being available at compile time. Indeed, this is a
snippet of a larger program in which the values are read in from a file.

[Bug c++/44254] Template pointer and reference arguments not always recognized as referencing to the same variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-checking,
   ||ice-on-valid-code

--- Comment #3 from Andrew Pinski  ---
With checking turned on we get:
:8:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
8 | }
  | ^

_ZN1AIXadL_Z1aEEEC1Ev/7 (A::A() [with int* p = (& a)]) @0x7f32dd186770
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: public weak comdat comdat_group:_ZN1AIXadL_Z1aEEEC5Ev one_only
  Same comdat group as: _ZN1AIXadL_Z1aEEEC2Ev/6
  previous sharing asm name: 4
  References: _ZN1AIXadL_Z1aEEEC2Ev/6 (alias) 
  Referring: 
  Function flags:
  Called by: main/1 
  Calls: 
_ZN1AIXadL_Z1aEEEC1Ev/4 (A::A() [with int* p = (& a)]) @0x7f32dd186440
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: public weak comdat comdat_group:_ZN1AIXadL_Z1aEEEC5Ev one_only
  Same comdat group as: _ZN1AIXadL_Z1aEEEC2Ev/3
  next sharing asm name: 7
  References: _ZN1AIXadL_Z1aEEEC2Ev/3 (alias) 
  Referring: 
  Function flags:
  Called by: main/1 
  Calls: 
:8:1: internal compiler error: symtab_node::verify failed
0x1d80e09 internal_error(char const*, ...)
???:0
0xbbe032 symtab_node::verify_symtab_nodes()
???:0
0xbda1df symbol_table::finalize_compilation_unit()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
ASM generation compiler returned: 1
:8:1: error: Two symbols with same comdat_group are not linked by the
same_comdat_group list.
8 | }
  | ^
_ZN1AIXadL_Z1aEEEC1Ev/7 (A::A() [with int* p = (& a)]) @0x7fd7568fe770
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: public weak comdat comdat_group:_ZN1AIXadL_Z1aEEEC5Ev one_only
  Same comdat group as: _ZN1AIXadL_Z1aEEEC2Ev/6
  previous sharing asm name: 4
  References: _ZN1AIXadL_Z1aEEEC2Ev/6 (alias) 
  Referring: 
  Function flags:
  Called by: main/1 
  Calls: 
_ZN1AIXadL_Z1aEEEC1Ev/4 (A::A() [with int* p = (& a)]) @0x7fd7568fe440
  Type: function definition analyzed alias cpp_implicit_alias
  Visibility: public weak comdat comdat_group:_ZN1AIXadL_Z1aEEEC5Ev one_only
  Same comdat group as: _ZN1AIXadL_Z1aEEEC2Ev/3
  next sharing asm name: 7
  References: _ZN1AIXadL_Z1aEEEC2Ev/3 (alias) 
  Referring: 
  Function flags:
  Called by: main/1 
  Calls:

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r12-2522-ga21bd3cebd6f54af70a37c18b8fbeae933fb6515
Author: Jakub Jelinek 
Date:   Tue Jul 27 09:59:37 2021 +0200

gimple-fold: Fix up __builtin_clear_padding on classes with virtual
inheritence [PR101586]

For the following testcase, B is 16-byte type, containing 8-byte
virtual pointer and 1-byte A member, and C contains two FIELD_DECLs,
one with B type and size of just 8-byte and then a field with type
A and 1-byte size.
The __builtin_clear_padding code was upset about the B typed FIELD_DECL
containing FIELD_DECLs beyond the field size and triggered
assertion failure.
This patch makes it ignore all FIELD_DECLs that are (fully) beyond the sz
passed from the caller (except for the flexible array member
diagnostics that is kept).

2021-07-27  Jakub Jelinek  

PR middle-end/101586
* gimple-fold.c (clear_padding_type): Ignore FIELD_DECLs with byte
positions above or equal to sz except for diagnostics of flexible
array members.

* g++.dg/torture/builtin-clear-padding-4.C: New test.

[Bug c++/100279] [ICE in trunk] ICE caused by negative double NTTP. Error: Two symbols with same comdat_group are not linked by the same_comdat_group list.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #5 from Andrew Pinski  ---
This is the same as PR 98216.

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

[Bug c++/98216] [C++20] template mangling for double template argument is wrong

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bobmiller at nvidia dot com

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

[Bug middle-end/101586] ICE:in clear_padding_type, at gimple-fold.c:4783 with call to __builtin_clear_padding for C++

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

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

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk.
Can be backported to 11.3, though it isn't much useful there as libstdc++ still
doesn't use the builtin.

[Bug c++/55581] [C++11] Too-eager instantiation with decltype

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

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

--- Comment #3 from Andrew Pinski  ---
so these days clang explodes on this testcase.

[Bug c++/57520] alias template substitution/deduction failure

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

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

--- Comment #4 from Andrew Pinski  ---
On the trunk with C++14 (and C++11), gcc errors out where clang used to error
out only.  With C++17 (and C++20), though GCC accepts the code.

[Bug fortran/101635] New: FAIL: gfortran.dg/PR93963.f90 – alias-handling issue with BIND(C)'s _gfortran_cfi_desc_to_gfc_desc

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

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

Bug ID: 101635
   Summary: FAIL: gfortran.dg/PR93963.f90 – alias-handling issue
with BIND(C)'s _gfortran_cfi_desc_to_gfc_desc
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jrfsousa at gcc dot gnu.org, sandra at gcc dot gnu.org
  Target Milestone: ---

This is kind of a regression as the testcase is new with the
commit r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c
for PR 93308, PR 93963, PR 94327, PR 94331, and PR 97046.

The testcase  gfortran.dg/PR93963.f90  has the following;
the → lines are from the -fdump-tree-original:

  integer(kind=c_int), pointer :: intp(:)
  nullify(intp)
  irnk = rank_p(intp)   ! this is BIND(C) with an assumed-rank argument

and the dump

   intp.dtype = {.elem_len=4, .rank=1, .type=1};
   intp.data = 0B;

and for the rank_p call:
  void * cfi.6;

  if ((integer(kind=4)[0:] *) intp.data == 0B)
{
  intp.dtype = {.elem_len=4, .rank=1, .type=1};
}
  _gfortran_gfc_desc_to_cfi_desc (&cfi.6, &intp);
  irnk = rank_p (cfi.6);
  __builtin_free (cfi.6);


With -m32  + optimizations, there seems to be an alias analysis issue which
causes that in rank_p, the argument's rank is <0 or >15 – such that rank_p
returns -1000. Unsurprisingly,
  -1000 != 1
and, hence, the program runs into:
  if (irnk /= rnk)stop 1

 * * *

Solution:  I think the proper fix is to remove both 
_gfortran_gfc_desc_to_cfi_desc  and  _gfortran_cfi_desc_to_gfc_desc from
libgfortran/runtime/ISO_Fortran_binding.c and create inline code in the
compiler itself, i.e. in gcc/fortran/trans-expr.c's
gfc_conv_gfc_desc_to_cfi_desc and in gcc/fortran/trans-decl.c's
convert_CFI_desc.

The code in libgfortran is rather simple - and in the compiler itself,
knowledge about the type can be used, avoiding both type alias issues and
generating proper code – it also improves the performance.

[Bug c++/63254] elfos.h missing space between literal and identifier.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
   Keywords||build
   Target Milestone|--- |6.0
 Resolution|--- |FIXED

--- Comment #3 from Andrew Pinski  ---
Been fixed since r6-581.

[Bug c++/62295] Variable Length Arrays can't be passed to functions in c++

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 51352.

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

[Bug c++/51352] g++ can't pass variable-length array as a function argument

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||cdkrot at yandex dot ru

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

[Bug target/39821] 120% slowdown with vectorizer

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-2524-gc8ce54c6e67295b70052d1b9f9a2f7ce9e2f8f0d
Author: Richard Biener 
Date:   Tue Jul 27 09:24:57 2021 +0200

tree-optimization/39821 - fix cost classification for widening arith

This adjusts the vectorizer to cost vector_stmt for widening
arithmetic instead of vec_promote_demote in the line of telling
the target that stmt_info->stmt is the meaningful piece we cost.

2021-07-27  Richard Biener  

PR tree-optimization/39821
* tree-vect-stmts.c (vect_model_promotion_demotion_cost): Use
vector_stmt for widening arithmetic.
(vectorizable_conversion): Adjust.

[Bug target/39821] 120% slowdown with vectorizer

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

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

--- Comment #8 from Richard Biener  ---
I've pushed the change that makes us run into ix86_multiplication_cost but as
said that doesn't differentiate highpart or widening multiply yet and thus
we're now missing optimizations because of too conservative costing.

[Bug c++/72780] public `using` directive exposes protected base-class constructor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 66475.

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

[Bug c++/66475] Access checking in templates circumvented with 'using' (C++11)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kyle.strand at beckman dot com

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

[Bug tree-optimization/101573] uninitialized warning could not appear correclty in -O0 optimisation level

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Biener :

https://gcc.gnu.org/g:66030d68a7edfc9504a50469598e0707b8f787ce

commit r12-2525-g66030d68a7edfc9504a50469598e0707b8f787ce
Author: Richard Biener 
Date:   Thu Jul 22 12:26:16 2021 +0200

tree-optimization/101573 - improve uninit warning at -O0

We can improve uninit warnings from the early pass by looking
at PHI arguments on fallthru edges that are uninitialized and
have uses that are before a possible loop exit.  This catches
some cases earlier that we'd only warn in a more confusing
way after early inlining as seen by testcase adjustments.

It introduces

FAIL: gcc.dg/uninit-23.c (test for excess errors)

where we additionally warn

gcc.dg/uninit-23.c:21:13: warning: 't4' is used uninitialized
[-Wuninitialized]

which I think is OK even if it's not obvious that the new
warning is an improvement when you look at the obvious source.

Somehow for all cases I never get the `'foo' was declared here`
notes, I didn't dig why that happens but it's odd.

2021-07-22  Richard Biener  

PR tree-optimization/101573
* tree-ssa-uninit.c (warn_uninit_phi_uses): New function
looking at uninitialized PHI arg defs in some constrained cases.
(warn_uninitialized_vars): Call it.
(execute_early_warn_uninitialized): Calculate dominators.

* gcc.dg/uninit-pr101573.c: New testcase.
* gcc.dg/uninit-15-O0.c: Adjust.
* gcc.dg/uninit-15.c: Likewise.
* gcc.dg/uninit-23.c: Likewise.
* c-c++-common/uninit-17.c: Likewise.

[Bug tree-optimization/101573] uninitialized warning could not appear correclty in -O0 optimisation level

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

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||12.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed for GCC 12.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 101573 Summary: uninitialized warning could not appear correclty in -O0 
optimisation level
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101573

   What|Removed |Added

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

[Bug middle-end/78103] Failure to optimize with __builtin_clzl

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

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

Jakub Jelinek  changed:

   What|Removed |Added

  Attachment #51204|0   |1
is obsolete||

--- Comment #16 from Jakub Jelinek  ---
Created attachment 51209
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51209&action=edit
gcc12-pr78103.patch

Updated patch.  This one fixes the reuse of a pseudo you've mentioned above,
and fixes gcc.target/i386/pr101175.c regression the patch reintroduced by
adding !TARGET_LZCNT conditions to the two new define_insns.

Nothing changes for combine though, I think it really would be nice if it could
either change newly added pseudos from combine_split_insns by i2dest if
possible, or better handle new pseudos from both combine_split_insns and when
for find_split_point i2dest can't be resued with creating LOG_LINKS.

I guess I can work around this by using define_insn_and_split instead of a
combiner splitter, but combine splitters are cleaner...

[Bug tree-optimization/101636] New: [11/12 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr')

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 101636
   Summary: [11/12 Regression] ICE: verify_gimple failed (error:
conversion of register to a different size in
'view_convert_expr')
   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: ---
Target: x86_64-pc-linux-gnu

gcc-12.0.0-alpha20210725 snapshot (g:b454c40956947938c9e274d75cef8a43171f3efa)
ICEs when compiling the following testcase, reduced from
gcc/testsuite/gcc.dg/vect/slp-cond-5.c, w/ -mavx512f -O1 -ftree-vectorize:

inline int
foo (int y, int a)
{
  return (y && a) ? a : 0;
}

void
bar (int *__restrict a, int *__restrict d, int *__restrict e, int i)
{
  while (i < 1)
{
  e[8] = e[7] = e[6] = e[5] = e[4] = e[3] = e[2] = e[1] = e[0]
= foo (d[8], a[8]);
  e[9] = foo (d[9], a[9]);
  e[10] = foo (d[0], a[0]);
  e[11] = foo (d[1], a[1]);
  e[12] = foo (d[12], a[12]);
  e[13] = foo (d[13], a[13]);
  e[14] = foo (d[4], a[4]);
  e[15] = foo (d[15], a[15]);

  a += 16;
  e += 1;
  i += 1;
}
}

% x86_64-pc-linux-gnu-gcc-12.0.0 -mavx512f -O1 -ftree-vectorize -c uo7arifc.c
uo7arifc.c: In function 'bar':
uo7arifc.c:8:1: error: conversion of register to a different size in
'view_convert_expr'
8 | bar (int *__restrict a, int *__restrict d, int *__restrict e, int i)
  | ^~~
VIEW_CONVERT_EXPR>(vect_patt_173.38_215);

_151 = VIEW_CONVERT_EXPR>(vect_patt_173.38_215);
during GIMPLE pass: slp
uo7arifc.c:8:1: internal compiler error: verify_gimple failed
0xe8a12a verify_gimple_in_cfg(function*, bool)
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210725/work/gcc-12-20210725/gcc/tree-cfg.c:5536
0xd5934f execute_function_todo
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210725/work/gcc-12-20210725/gcc/passes.c:2042
0xd59d5b execute_todo
   
/var/tmp/portage/sys-devel/gcc-12.0.0_alpha20210725/work/gcc-12-20210725/gcc/passes.c:2096

[Bug c++/97458] C++ parsing fails when calling specialized template method inside lambda

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
An easier work around is:
[p](){ p->template fn(); }; 

Confirmed.

[Bug c++/81781] constexpr pointer comparsion error

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug c++/89074] valid pointer equality constexpr comparison rejected

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||bobk-off at yandex dot ru

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

[Bug c++/55004] [meta-bug] constexpr issues

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

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

Bug 81781 Summary: constexpr pointer comparsion error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81781

   What|Removed |Added

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

[Bug c++/91907] ['17] Constexpr of member function pointer as template parameter results in inconsistent diagnostics

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

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

--- Comment #2 from Andrew Pinski  ---
Seems fixed on the trunk.  But I could not figure out which patch fixed it so a
bisect would be useful.

[Bug tree-optimization/101637] New: #pragma omp for simd defeats VECT_COMPARE_COSTS optimisations

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

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

Bug ID: 101637
   Summary: #pragma omp for simd defeats VECT_COMPARE_COSTS
optimisations
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64*-*-*

Compiling this with -O3 -march=armv8.2-a+sve:

void
foo (__INT64_TYPE__ *a, __INT32_TYPE__ *b, __INT16_TYPE__ *c)
{
//#pragma omp for simd
  for (int i = 0; i < 100; ++i)
a[i] = b[i] + c[i];
}

gives:

.L2:
ld1wz1.s, p0/z, [x1, x3, lsl 2]
ld1sh   z0.s, p0/z, [x2, x3, lsl 1]
punpklo p1.h, p0.b
add z0.s, z0.s, z1.s
punpkhi p0.h, p0.b
sunpklo z1.d, z0.s
sunpkhi z0.d, z0.s
st1dz1.d, p1, [x0, x3, lsl 3]
st1dz0.d, p0, [x5, x3, lsl 3]
add x3, x3, x6
whilelo p0.s, w3, w4
b.any   .L2

whereas uncommenting the pragma gives the considerably uglier:

.L2:
ld1hz0.h, p0/z, [x2, x3, lsl 1]
punpklo p1.h, p0.b
punpkhi p0.h, p0.b
ld1wz2.s, p1/z, [x1, x3, lsl 2]
ld1wz3.s, p0/z, [x7, x3, lsl 2]
punpklo p2.h, p1.b
punpkhi p1.h, p1.b
sunpklo z1.s, z0.h
sunpkhi z0.s, z0.h
add z1.s, z1.s, z2.s
add z0.s, z0.s, z3.s
sunpklo z2.d, z1.s
sunpklo z3.d, z0.s
sunpkhi z1.d, z1.s
sunpkhi z0.d, z0.s
st1dz1.d, p1, [x0, #1, mul vl]
punpklo p1.h, p0.b
punpkhi p0.h, p0.b
st1dz3.d, p1, [x0, #2, mul vl]
st1dz0.d, p0, [x0, #3, mul vl]
st1dz2.d, p2, [x0]
add x3, x3, x6
add x0, x0, x5
whilelo p0.h, w3, w4
b.any   .L2

For VECT_COMPARE_COSTS targets, we should probably still consider all
possibilities and pick the “best” vector implementation (ignoring the
comparison with scalar code).

[Bug c++/70331] missing error dereferencing a dangling pointer in constexpr function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-27
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug target/101579] Suboptimal codegen for __builtin_shufflevector

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-27
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
The original GIMPLE looks like

  g.0_1 = g;
  g.1_2 = g;
  v = VEC_PERM_EXPR ;
  v = ~v;
  g.2_3 = g;
  w = v + g.2_3;
  D.2465.a = w;
  _4 = D.2465.b;
  D.2466.a = w;
  D.2467 = BIT_FIELD_REF ;
  _5 = {D.2467, D.2467, D.2467, D.2467, D.2467, D.2467, D.2467, D.2467};
  u = _4 + _5;
  D.2468 = u;
  return D.2468;

but then veclower ends up open-coding the VEC_PERM_EXPR because the constant
permute is not supported by the target.  The same seems to be true for the
upper/lower half selection for some reason.

Note veclower doesn't have any code trying to implement a not supported
VEC_PERM_EXPR as a combination of supported ones.

[Bug tree-optimization/101580] [12 Regression] ICE Segmentation fault since r12-2429-g62acc72a957b5614

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Priority|P3  |P1
   Keywords||ice-on-valid-code

[Bug fortran/92482] BIND(C) with array-descriptor mishandled for type character

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

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

--- Comment #5 from Tobias Burnus  ---
Crossref:
See also PR 100906 "Bind(c): failure handling character with len/=1"
and PR 100906 comment 4 regarding a status (what needs to be done).

[Bug fortran/100906] Bind(c): failure handling character with len/=1

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

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

--- Comment #5 from Tobias Burnus  ---
Cross ref:
See also PR 92482 "BIND(C) with array-descriptor mishandled for type character"

[Bug preprocessor/101638] New: ICE with -Wtraditional

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

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

Bug ID: 101638
   Summary: ICE with -Wtraditional
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

With recent glibc head includes

> cat t.c
#include 
#include 

ICEs preprocessing the above with -Wtraditional

> gcc t.c -c -Wtraditional
In file included from /usr/include/features.h:488,
 from /usr/include/bits/libc-header-start.h:33,
 from /usr/include/stdlib.h:25,
 from t.c:2:
/usr/include/sys/cdefs.h:1: internal compiler error: Segmentation fault
1 | /* Copyright (C) 1992-2021 Free Software Foundation, Inc.
  | 
0xdef92b internal_error(char const*, ...)
???:0
0xddd540 cpp_sys_macro_p(cpp_reader*)
???:0
0xf0f026 _cpp_parse_expr
???:0
0xf0e452 _cpp_handle_directive
???:0
0xf09324 _cpp_lex_token
???:0
0xf21485 c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
???:0
0x1417068 c_parse_file()
???:0
0x1414d1b c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/101590] (len & - N) <= len is not optimized to 1

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

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

--- Comment #1 from Richard Biener  ---
it doesn't even have to be -N, any unsigned & N <= unsigned

[Bug libgomp/93030] [OpenACC] libgomp.oacc-c-c++-common/deep-copy-10.c FAILS on AMDGCN – invalid 'async' usage?

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Thomas Schwinge  ---
See  for the
latest discussion on this one.

[Bug target/101579] Suboptimal codegen for __builtin_shufflevector

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
As
typedef unsigned char V __attribute__((vector_size (32)));

V
foo (V x)
{
  return __builtin_shufflevector (x, x, 0, 1, 2, 0, 5, 1, 0, 1, 3, 2, 3, 0, 4,
3, 1, 2,
2, 0, 4, 2, 3, 1, 1, 2, 3, 4, 1, 1, 0,
0, 5, 2);
}

V
bar (V x)
{
  return __builtin_shufflevector (x, x, 0, 3, 3, 3, 3, 4, 5, 0, 1, 5, 2, 1, 0,
1, 1, 2,
3, 2, 0, 5, 4, 5, 1, 0, 1, 4, 4, 3, 4,
5, 2, 0);
}
with -O2 -mavx2 is handled, I'd say this is veclower task to determine that the
particular permutation could be cheaply implemented with two permutations of
half-sized vectors and ask the backend if it supports those.
Of course there can be other permutations that can't be implemented that way
easily and might e.g. need more half-sized permutations...

[Bug tree-optimization/101591] (a|b) ==/!= a -> (b & ~a) ==/!= 0 on gimple

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

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

--- Comment #4 from Richard Biener  ---
Not sure if it is cheaper - it's one more operation on GIMPLE so (a|b) == a
looks more canonical?

[Bug c/101607] ICE on compilable code: in assign_stack_temp_for_type, at function.c:798

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid

--- Comment #1 from Richard Biener  ---
This is another case of a too large aggregate type that we should instead
reject.

[Bug tree-optimization/101612] _Complex float multiply expansion does not allow for a tail call to __mulsc3

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

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

--- Comment #1 from Richard Biener  ---
Hmm, looks like missed PRE of the COMPLEX_EXPR to me.

simplifying {complex_expr,_18,_19} translated 4 -> 3 to {complex_expr,_16,_17}
to _15

Starting insert iteration 1
Skipping partial redundancy for expression {complex_expr,_18,_19} (0003), no
redundancy on to be optimized for speed edge

indeed there's no redundancy on the speed edge and we'd end up splitting the
edge for the insertion on the speed edge.

[Bug tree-optimization/101615] [12 Regression] wrong code at -O3 on x86_64-linux-gnu since r12-1872

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |12.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-27

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

[Bug rtl-optimization/101617] a ? -1 : 1 -> (-(type)a) | 1

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

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

--- Comment #8 from Richard Biener  ---
We generally want less stmts on GIMPLE, (-(type)a) | 1 is more than
a ? -1 : 1 which means it should be a RTL expansion time optimization.

[Bug tree-optimization/101639] New: vectorization with bool reduction

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

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

Bug ID: 101639
   Summary: vectorization with bool reduction
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org
  Target Milestone: ---
Target: x86_64-*-*

bool f(char* p, long n)
{
  bool r = true;
  for(long i = 0; i < n; ++i)
r &= (p[i] != 0);
  return r;
}

is not vectorized, while if I simply declare r as char instead of bool, it is
(not quite optimal since it fails to pull &1 out of the loop, but that's a
separate issue).

[Bug tree-optimization/101621] gcc cannot optimize int8_t vector assign with subscription to shuffle

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-07-27
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #4 from Richard Biener  ---
It's done with -O3 since the vectorizer handles this.  There's a pattern
matching phase in forwprop which also handles some cases but it does not handle
this specific case (and it's a bit messy already).  forwprop eventually sees

v16b gcc_cannot_shuffle_with_cast (v2si64 x)
{
  v16b b0;
  char _1;
  char _2;
  char _3;
  char _4;

   [local count: 1073741824]:
  _1 = BIT_FIELD_REF ;
  _2 = BIT_FIELD_REF ;
  _3 = BIT_FIELD_REF ;
  _4 = BIT_FIELD_REF ; 
  b0_6 = {_1, _1, _1, _1, _2, _2, _2, _2, _3, _3, _3, _3, _4, _4, _4, _4};
  return b0_6;

and early forwprop

   :
  _1 = VIEW_CONVERT_EXPR(x_18(D));
  _2 = BIT_FIELD_REF <_1, 8, 0>;
  _3 = BIT_FIELD_REF <_1, 8, 0>;
...
  b0_20 = {_2, _3, _4, _5, _6, _7, _8, _9, _10, _11, _12, _13, _14, _15, _16,
_17};

[Bug fortran/101624] [9/10/11/12 Regression] ICE: tree check: expected tree that contains 'decl with RTL' structure, have 'const_decl' in maybe_optimize_ubsan_ptr_ifn, at sanopt.c:495

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |9.5

[Bug ipa/101625] [11/12 Regression] ICE in modref_tree::merge with LTO and -m32

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org
   Target Milestone|--- |11.2
  Component|lto |ipa
Summary|ICE in  |[11/12 Regression] ICE in
   |modref_tree::merge |modref_tree::merge
   |with LTO and -m32   |with LTO and -m32
   Priority|P3  |P2
   Keywords||ice-on-valid-code, lto

[Bug preprocessor/101628] Preprocessor errors on extended characters in #if 0 code block

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
thus dup

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

[Bug preprocessor/62661] digit separator warning in if'ed out code

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||david.post at ohyonghao dot com

--- Comment #4 from Richard Biener  ---
*** Bug 101628 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/101637] #pragma omp for simd defeats VECT_COMPARE_COSTS optimisations

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Depends on whether simdlen clause is specified or not.  If it is, we should go
if possible with what user asked for (the chosen vectorization factor). 
Otherwise sure, pick the vectorization with smallest cost, but still prefer to
vectorize over not vectorizing, because user asked for vectorization.

[Bug c++/101631] gcc permits object reference to object outside of its lifetime during constant evaluation

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|1   |0
 Status|WAITING |UNCONFIRMED
   Keywords||accepts-invalid

[Bug tree-optimization/101637] #pragma omp for simd defeats VECT_COMPARE_COSTS optimisations

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org
   Last reconfirmed||2021-07-27
 Status|UNCONFIRMED |NEW

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed, though it also needs -fopenmp to trigger for me

[Bug tree-optimization/101634] Vectorize optimisations trigger floating point exception

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I believe the issue has been fixed already and is a duplicate of PR100778. 
There's an updated GCC 11 package pending in
https://build.opensuse.org/project/show/openSUSE:Factory:Staging:A which you
could verify against (or in devel:gcc which should even be published).

A locally built g++ from the GCC 11 branch doesn't reproduce the issue for me.

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

[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||gcc at wdqb dot uk

--- Comment #17 from Richard Biener  ---
*** Bug 101634 has been marked as a duplicate of this bug. ***

[Bug d/101640] New: d: Wrong evaluation order of binary expressions

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 101640
   Summary: d: Wrong evaluation order of binary expressions
   Product: gcc
   Version: 9.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Because of the use of fold_build2, the evaluation order is ignored in the
following example.
---
int fun(ref int);

int test(int i)
{
return i + fun(i);
}

[Bug tree-optimization/101639] vectorization with bool reduction

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

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||53947
   Last reconfirmed||2021-07-27
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
vectorizable_reduction fails the

6692  scalar_dest = gimple_assign_lhs (stmt);
6693  scalar_type = TREE_TYPE (scalar_dest);
6694  if (!POINTER_TYPE_P (scalar_type) && !INTEGRAL_TYPE_P (scalar_type)
6695  && !SCALAR_FLOAT_TYPE_P (scalar_type))
6696return false;
6697
6698  /* Do not try to vectorize bit-precision reductions.  */
6699  if (!type_has_mode_precision_p (scalar_type))
6700return false;

check.  I guess we could relax that for BIT_*_EXPR reductions.  But then
we run into

t5.c:4:21: note:   vect_is_simple_use: vectype vector(16) unsigned char
t5.c:4:21: missed:   mixed mask and nonmask vector types
t5.c:1:6: missed:   not vectorized: relevant stmt not supported: _7 = _4 &
r_14;
t5.c:4:21: missed:  bad operation or unsupported loop bound.

I guess that's mainly a fault of missed bool pattern handling of the
reduction - we fail to make p[i] != 0 available as non-boolean vector.


Referenced Bugs:

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

[Bug tree-optimization/101636] [11/12 Regression] ICE: verify_gimple failed (error: conversion of register to a different size in 'view_convert_expr')

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-07-27
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |11.2
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Richard Biener  ---
Confirmed.

vect_patt_173.38_215 = VEC_COND_EXPR vectorizing SLP node starting from: patt_173 = patt_172 ?
-1 : 0;
t.c:8:1: note: vect_is_simple_use: operand () _75, type of
def: internal
t.c:8:1: note: add new stmt: vect_patt_173.38_215 = VEC_COND_EXPR
;
t.c:8:1: note: vectorizing stmts using SLP.

I will eventually have a look.

[Bug tree-optimization/101641] New: Bogus redundant store removal

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

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

Bug ID: 101641
   Summary: Bogus redundant store removal
   Product: gcc
   Version: 11.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

union u {
  long x;
  long long y;
};

__attribute__((noinline,noclone))
long test(long *px, long long *py, union u *pu)
{
  *px = 0;
  *py = 1;

  long xy = pu->y;
  pu->x = xy;

  return *px;
}

int main ()
{
  union u u;
  if (test (&u.x, &u.y, &u) != 1)
__builtin_abort ();
  return 0;
}

is miscompiled at -O2+ as FRE removes the seemingly redundant store to
pu->x but that's needed to make the read via *px pick up the value stored
via *py = 1 rather than (correctly) disambiguating against that and
running into *px = 0.

[Bug tree-optimization/101641] Bogus redundant store removal

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-07-27
 Status|UNCONFIRMED |ASSIGNED
   Keywords||wrong-code

--- Comment #1 from Richard Biener  ---
We're already going great lengths trying to preserve stores that change the
dynamic type in a way relevant for downstream users (which we actually do not
see).  In particular we've settled to

  alias_set_type set = ao_ref_alias_set (&lhs_ref);
  alias_set_type base_set = ao_ref_base_alias_set (&lhs_ref);
  if ((vnresult->set != set
   && ! alias_set_subset_of (set, vnresult->set))
  || (vnresult->base_set != base_set
  && ! alias_set_subset_of (base_set, vnresult->base_set)))
resultsame = false;

but this case is so degenerate that all the alias sets and base alias sets
of both pu->y (vnresult) and pu->x (lhs_ref) are 2 since we use the alias
set of the union type for all accesses that have the union in their path.

The only remaining chance we have here is to look at the actual types
and reject punning attempts.  We are really missing a way to preserve
the TBAA effect of a store but not the store itself.

[Bug c/101642] New: ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 101642
   Summary: ice in decompose, at wide-int.h:984
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 51210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51210&action=edit
C source code

The attached C code does this with recent gcc:

$ ../results/bin/gcc -c -O2 bug740.c 
during GIMPLE pass: fre
netflow_v1.c: In function ‘Process_v1’:
netflow_v1.c:507:1: internal compiler error: in decompose, at wide-int.h:984
0x139979c wi::int_traits >::decompose(long*, 
unsigned int, generic_wide_int const&)
../../trunk.git/gcc/wide-int.h:984
0x139979c wide_int_ref_storage::wide_int_ref_storage >(generic_wide_int const&, unsigned int)
../../trunk.git/gcc/wide-int.h:1034
0x139979c generic_wide_int
>::generic_wide_int
 >(generic_wide_int
const&,
 unsigned int)
../../trunk.git/gcc/wide-int.h:790

I will have my usual go at reducing the code and trying to spot a
range of git hashes where the problem first occurs.

[Bug c/101642] ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
Problem first seems to occur sometime between git hash ead235f60139edc6,
dated 20210724 and git hash fcc7c6369f7fbf29, dated today.

[Bug c/101642] ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Reduced code seems to be

short __bswap_16___bsx, Process_v1___trans_tmp_1;
int Process_v1_common_record;
char Process_v1_s2;
void Process_v1(void) {
  Process_v1___trans_tmp_1 = __builtin_bswap16(__bswap_16___bsx);
  if (Process_v1___trans_tmp_1)
Process_v1_s2 = Process_v1_common_record;
}

[Bug c/101642] ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
In a git bisect, trying cf5f544227f16b63

[Bug middle-end/78103] Failure to optimize with __builtin_clzl

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

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

--- Comment #17 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #16)
> Created attachment 51209 [details]
> gcc12-pr78103.patch
> 
> Updated patch.  This one fixes the reuse of a pseudo you've mentioned above,
> and fixes gcc.target/i386/pr101175.c regression the patch reintroduced by
> adding !TARGET_LZCNT conditions to the two new define_insns.

Great :-)

> Nothing changes for combine though, I think it really would be nice if it
> could either change newly added pseudos from combine_split_insns by i2dest
> if possible,

Is that ever safe to do?

> or better handle new pseudos from both combine_split_insns and
> when
> for find_split_point i2dest can't be resued with creating LOG_LINKS.

You cannot safely attempt to combine the two insns split to again, neither
alone nor in combination with other insns.  Since pretty much by definition
that new reg will be set in the new i2 and used in (only) in the new i3,
no combination with that new reg is valid ever?

> I guess I can work around this by using define_insn_and_split instead of a
> combiner splitter, but combine splitters are cleaner...

Sometimes it helps to pretend you have an instruction you do not.  Both pure
splitters and define_insn_and_split have their place :-)

[Bug middle-end/78103] Failure to optimize with __builtin_clzl

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

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

--- Comment #18 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #17)
> > Nothing changes for combine though, I think it really would be nice if it
> > could either change newly added pseudos from combine_split_insns by i2dest
> > if possible,
> 
> Is that ever safe to do?

Except for debug insns if the mode is the same and i2dest doesn't appear in
i2set nor i3set nor anything in between, why not?
As for debug insns, as I said earlier, the current code is reusing i2dest for
the splitting found by find_split_point.

> > or better handle new pseudos from both combine_split_insns and
> > when
> > for find_split_point i2dest can't be resued with creating LOG_LINKS.
> 
> You cannot safely attempt to combine the two insns split to again, neither
> alone nor in combination with other insns.  Since pretty much by definition
> that new reg will be set in the new i2 and used in (only) in the new i3,
> no combination with that new reg is valid ever?

Sure, combining those 2 insns can't be sucessful, otherwise it would have
matched earlier.  But they can be combined with other insns, say the first of
those 2 split insns being i0 and second i1 combined into some other i3 and i2,
or perhaps just split insns i1 and i2 combined into some other i3.

[Bug c/101642] ice in decompose, at wide-int.h:984

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
(In reply to David Binderman from comment #3)
> In a git bisect, trying cf5f544227f16b63

Seems bad, so trying 1ab2270036dc0f2a.

[Bug c/101642] ice in decompose, at wide-int.h:984

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

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

--- Comment #5 from Jakub Jelinek  ---
Started with r12-2516-gcf5f544227f16b63e224529190329eb0edca791c

[Bug middle-end/101642] [12 Regression] ice in decompose, at wide-int.h:984

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

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

Richard Biener  changed:

   What|Removed |Added

Summary|ice in decompose, at|[12 Regression] ice in
   |wide-int.h:984  |decompose, at
   ||wide-int.h:984
   Target Milestone|--- |12.0
 CC||sayle at gcc dot gnu.org
  Component|c   |middle-end

[Bug middle-end/101642] [12 Regression] ice in decompose, at wide-int.h:984

[zsojka at seznam dot cz via Gcc-bugs]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #6 from Zdenek Sojka  ---
Even simpler testcase failing at -O1:
$ cat testcase.c
int x;

void
foo (void)
{
  __builtin_bswap16 (x) ? : x;
}
$ x86_64-pc-linux-gnu-gcc -O testcase.c 
during GIMPLE pass: fre
testcase.c: In function 'foo':
testcase.c:7:1: internal compiler error: in decompose, at wide-int.h:984
7 | }
  | ^
0x7f7b80 wi::int_traits >
>::decompose(long*, unsigned int, generic_wide_int > const&)
...

[Bug fortran/101635] FAIL: gfortran.dg/PR93963.f90 – alias-handling issue with BIND(C)'s _gfortran_cfi_desc_to_gfc_desc

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

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

Paul Thomas  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-07-27
 Ever confirmed|0   |1
 CC||pault at gcc dot gnu.org

--- Comment #1 from Paul Thomas  ---

> Solution:  I think the proper fix is to remove both 
> _gfortran_gfc_desc_to_cfi_desc  and  _gfortran_cfi_desc_to_gfc_desc from
> libgfortran/runtime/ISO_Fortran_binding.c and create inline code in the
> compiler itself, i.e. in gcc/fortran/trans-expr.c's
> gfc_conv_gfc_desc_to_cfi_desc and in gcc/fortran/trans-decl.c's
> convert_CFI_desc.
> 
> The code in libgfortran is rather simple - and in the compiler itself,
> knowledge about the type can be used, avoiding both type alias issues and
> generating proper code – it also improves the performance.

I agree completely. The library code was used as a temporary measure since it
is easily tested outside the compiler. I think that the time has indeed come to
convert it to inline code.

I am still out of commission for gfortran work and so I won't take it yet.

Paul

[Bug tree-optimization/72443] VRP derives poor range for "y = (int)x + C;" when x has an anti-range

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com
 Resolution|--- |FIXED
 Status|NEW |RESOLVED

--- Comment #4 from Andrew Macleod  ---
Ranger VRP passes produce:

Non-varying global ranges:
=:
y_7  : int [-2147483647, 5][12, +INF]


So.. fixed I guess.

[Bug middle-end/78103] Failure to optimize with __builtin_clzl

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #19 from Jakub Jelinek  ---
Created attachment 51211
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51211&action=edit
gcc12-pr78103.patch

Updated untested patch that uses define_insn_and_split in 2 cases instead of
the combine splitters so that it can work around the lack of LOG_LINKS.
The patch doesn't do anything with -mlzcnt, even when bsr or bsr + lea would be
shorter than mov + lzcnt + sub, but I'm afraid we can't do anything about that,
we've lost information whether it is UB on zero or not with -mlzcnt and for
zero input all this is quite unsafe.

[Bug middle-end/101642] [12 Regression] ice in decompose, at wide-int.h:984

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
I think better testcase would be
int x;

unsigned short
foo (void)
{
  return __builtin_bswap16 (x) ? : x;
}
because otherwise you're asking for it to be DCEd.

The problem is that for __builtin_bswap16 like for many other builtins with 8
or 16-bit argument(s) the operand is promoted to int.
So, many of the match.pd rules just don't trigger for it at all, like:
 (simplify
  (bswap (bswap @0))
  @0)
 (simplify
  (bswap (bit_not (bswap @0)))
  (bit_not @0))
 (for bitop (bit_xor bit_ior bit_and)
  (simplify
   (bswap (bitop:c (bswap @0) @1))
   (bitop @0 (bswap @1
because there are casts it doesn't take into account for bswap16, others are
just incorrect, like:
 (for cmp (eq ne)
  (simplify
   (cmp (bswap @0) (bswap @1))
   (cmp @0 @1))
- it needs to convert @0 and @1 to the type of one of the bswaps, otherwise it
could be comparing even the upper bits, and others are both incorrect and cause
ICE, like
  (simplify
(cmp (bswap @0) INTEGER_CST@1)
   (cmp @0 (bswap @1
Let me deal with just those now and the rest that just don't match can be dealt
with later on.

[Bug preprocessor/57824] Raw string literals not handled correctly in macro arguments or deferred pragmas

[moritz.baumann at sap dot com via Gcc-bugs]

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

Moritz Baumann  changed:

   What|Removed |Added

 CC||moritz.baumann at sap dot com

--- Comment #4 from Moritz Baumann  ---
Raw string literals are still not handled correctly in macros in some cases:

#define myMacro(string) u##string

int square(int num) {
auto string = myMacro(R"EOF(



)EOF");
// intentional syntax error
return num * num
}

(https://godbolt.org/z/qYfax5E8x)

The line number in the compiler error message refers to a line that doesn't
even exist. It seems like line breaks in the raw string literal are counted
twice.

[Bug debug/101643] New: [debug, ada] packed array not described as packed

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

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

Bug ID: 101643
   Summary: [debug, ada] packed array not described as packed
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

[ Filing FTR. ]

Consider gdb test-case foo_ra24_010.adb / pck.adb / pck.ads (
https://sourceware.org/git/?p=binutils-gdb.git;a=tree;f=gdb/testsuite/gdb.ada/big_packed_array
).

With gcc-8.5.0 we have:
...
$ gnatmake-8 -f foo_ra24_010.adb -fgnat-encodings=minimal -g
$ gdb -q -batch ./foo_ra24_010 -ex start -ex n -ex n -ex 'p bad'
Temporary breakpoint 1 at 0x402ce6: file foo_ra24_010.adb, line 19.

Temporary breakpoint 1, foo_ra24_010 () at foo_ra24_010.adb:19
19 Good : PA := (others => False);
20 Bad : Bad_Packed_Table := (others => False);
22 Do_Nothing (Good'Address);  -- STOP
$1 = (0 => 0 )
...
while with gcc-9.3.1 we have:
...
$ gnatmake-9 -f foo_ra24_010.adb -fgnat-encodings=minimal -g
+ gdb -q -batch ./foo_ra24_010 -ex start -ex n -ex n -ex 'p bad'
Temporary breakpoint 1 at 0x402d24: file foo_ra24_010.adb, line 19.

Temporary breakpoint 1, foo_ra24_010 () at foo_ra24_010.adb:19
19 Good : PA := (others => False);
20 Bad : Bad_Packed_Table := (others => False);
22 Do_Nothing (Good'Address);  -- STOP
$1 = (false )
...

The difference in gdb behaviour is caused by the dwarf information.

With gcc-8.5.0 we have:
...
 <2><2074>: Abbrev Number: 10 (DW_TAG_variable)
<2075>   DW_AT_name: bad
<207c>   DW_AT_type: <0x2028>
 <1><2028>: Abbrev Number: 5 (DW_TAG_array_type)
<2029>   DW_AT_name: pck__t
<202d>   DW_AT_bit_stride  : 8
<202e>   DW_AT_type: <0x2003>
<2032>   DW_AT_alignment   : 1
<2033>   DW_AT_sibling : <0x203f>
 <2><2037>: Abbrev Number: 7 (DW_TAG_subrange_type)
<2038>   DW_AT_type: <0x200a>
<203c>   DW_AT_lower_bound : 0
<203d>   DW_AT_upper_bound : 24
 <2><203e>: Abbrev Number: 0
 <1><2003>: Abbrev Number: 4 (DW_TAG_base_type)
<2004>   DW_AT_byte_size   : 1
<2005>   DW_AT_encoding: 7  (unsigned)
<2006>   DW_AT_name: system__unsigned_types__packed_byte
 <1><200a>: Abbrev Number: 4 (DW_TAG_base_type)
<200b>   DW_AT_byte_size   : 4
<200c>   DW_AT_encoding: 5  (signed)
<200d>   DW_AT_name: integer
...

With gcc-9.3.1 we have for foo_ra24_010.adb:
...
 <2><20a1>: Abbrev Number: 11 (DW_TAG_variable)
<20a2>   DW_AT_name: bad
<20a9>   DW_AT_type: <0x205f>
 <1><205f>: Abbrev Number: 7 (DW_TAG_typedef)
<2060>   DW_AT_name: pck__bad_packed_table
<2067>   DW_AT_type: <0x2048>
<206b>   DW_AT_alignment   : 1
 <1><2048>: Abbrev Number: 5 (DW_TAG_array_type)
<2049>   DW_AT_name: pck__t___XP1
<204d>   DW_AT_bit_stride  : 8
<204e>   DW_AT_type: <0x2016>
<2052>   DW_AT_alignment   : 1
 <2><2057>: Abbrev Number: 8 (DW_TAG_subrange_type)
<2058>   DW_AT_type: <0x201d>
<205c>   DW_AT_lower_bound : 0
<205d>   DW_AT_upper_bound : 24
 <2><205e>: Abbrev Number: 0
 <1><2016>: Abbrev Number: 4 (DW_TAG_base_type)
<2017>   DW_AT_byte_size   : 1
<2018>   DW_AT_encoding: 7  (unsigned)
<2019>   DW_AT_name: system__unsigned_types__packed_byte
 <1><201d>: Abbrev Number: 4 (DW_TAG_base_type)
<201e>   DW_AT_byte_size   : 4
<201f>   DW_AT_encoding: 5  (signed)
<2020>   DW_AT_name: integer
...
and with pck__t___XP1 listed once more for pck.adb as:
...
 <1><1ab5>: Abbrev Number: 5 (DW_TAG_array_type)
<1ab6>   DW_AT_name: pck__t___XP1
<1aba>   DW_AT_bit_stride  : 1
<1abb>   DW_AT_type: <0x1aa0>
<1abf>   DW_AT_alignment   : 1
 <2><1ac4>: Abbrev Number: 6 (DW_TAG_subrange_type)
<1ac5>   DW_AT_type: <0x15f9>
<1ac9>   DW_AT_lower_bound : 0
<1aca>   DW_AT_upper_bound : 195
 <2><1acb>: Abbrev Number: 0
 <1><1aa0>: Abbrev Number: 4 (DW_TAG_base_type)
<1aa1>   DW_AT_byte_size   : 1
<1aa2>   DW_AT_encoding: 2  (boolean)
<1aa3>   DW_AT_name: boolean
 <1><15f9>: Abbrev Number: 2 (DW_TAG_enumeration_type)
<15fa>   DW_AT_name: pck__enum_idx
<15fe>   DW_AT_encoding: 7  (unsigned)
<15ff>   DW_AT_byte_size   : 1
...

ISTM that in the gcc-8.5.0 case, gdb does the best it can do with the info
provided, and that is this a gcc bug.

[Bug middle-end/101642] [12 Regression] ice in decompose, at wide-int.h:984

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #8 from Zdenek Sojka  ---
(In reply to Jakub Jelinek from comment #7)
> I think better testcase would be
> int x;
> 
> unsigned short
> foo (void)
> {
>   return __builtin_bswap16 (x) ? : x;
> }
> because otherwise you're asking for it to be DCEd.
> 

Indeed, but when I tried this, it didn't ICE any more. (but I didn't explore
this any further)

[Bug debug/101643] [debug, ada] packed array not described as packed

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

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

Tom de Vries  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Keywords||wrong-debug
 Status|UNCONFIRMED |RESOLVED
   Target Milestone|--- |9.0
Version|7.5.0   |8.5.0

--- Comment #1 from Tom de Vries  ---
Fixed by:
...
commit 21afc4facd1ac4f62f7bd8ca0a3997fdb8ed1230
Author: Eric Botcazou 
AuthorDate: Thu May 31 10:46:02 2018 +
Commit: Pierre-Marie de Rodat 
CommitDate: Thu May 31 10:46:02 2018 +

[Ada] Fix strange behavior of Object_Size for packed array subtype

2018-05-31  Eric Botcazou  

gcc/ada/

* gcc-interface/decl.c (gnat_to_gnu_entity) : Do not
deal with the ___XP suffix for packed array types here...
: ...or here when processing the implementation
type
but when processing the original type instead.  Do not reuse the
DECL
of the implementation type for the original type.  Tidy up.

From-SVN: r260999
...

I was not able to find a submission of this patch.

[Bug middle-end/101642] [12 Regression] ice in decompose, at wide-int.h:984

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

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

--- Comment #9 from Jakub Jelinek  ---
With unsigned short return it ICEs, with int return it doesn't.

[Bug gcov-profile/101644] New: [GCOV] Label after "return" has wrong coverage.

[njuwy at smail dot nju.edu.cn via Gcc-bugs]

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

Bug ID: 101644
   Summary: [GCOV] Label after "return" has wrong coverage.
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: njuwy at smail dot nju.edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../configure -enable-checking=release -enable-languages=c,c++
-disable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.0 (GCC) 

$ cat test.c
#include
#include
int main() {
l1:
  return &&l1 - &&l2;
l2:
  printf("Executed\n");
}

$ gcc -O0 --coverage test.c;./a.out;gcov test;cat test.c.gcov
File 'test.c'
Lines executed:100.00% of 4
Creating 'test.c.gcov'

-:0:Source:test.c
-:0:Graph:test.gcno
-:0:Data:test.gcda
-:0:Runs:1
-:1:#include
-:2:#include
1:3:int main() {
1:4:l1:
1:5:  return &&l1 - &&l2;
1:6:l2:
-:7:  printf("Executed\n");
-:8:}

Line 6 was wrongly marked as executed.

[Bug tree-optimization/101634] Vectorize optimisations trigger floating point exception

[gcc at wdqb dot uk via Gcc-bugs]

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

William Bainbridge  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |FIXED

--- Comment #2 from William Bainbridge  ---
Thank you for looking into it. I have verified that gcc-11.2-RC-20210721 fixes
the issue.

[Bug middle-end/101642] [12 Regression] ice in decompose, at wide-int.h:984

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2021-07-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #10 from Jakub Jelinek  ---
Created attachment 51212
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51212&action=edit
gcc12-pr101642.patch

Untested fix.

[Bug c++/101631] gcc permits object reference to object outside of its lifetime during constant evaluation

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to fsb4000 from comment #2)
> I'm confused with "What we do not want: Bugs in releases or snapshots of GCC
> not issued by the GNU Project. Report them to whoever provided you with the
> release".

10.3.0 is an official release. 10.3.1 or some heavily patched GCC would not be.

[Bug tree-optimization/101626] [12 Regression] ICE in verify_sra_access_forest, at tree-sra.c:2376

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

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

Martin Jambor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-07-27
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Jambor  ---
Confirmed.  I will have a look (although probably unfortunately only later in
August).

[Bug middle-end/101642] [12 Regression] ice in decompose, at wide-int.h:984

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #11 from Roger Sayle  ---
Hi Jakub,
Sorry for the inconvenience.
I've just come up with a near-identical fix.  I think it's safe to strip the
(symmetric) bswaps in the first transformation, but I'm now paranoid enough to
explicitly convert both operands of the cmp to the same comparison type in the
second transformation.
-   (cmp (bswap @0) INTEGER_CST@1)
-   (cmp @0 (bswap @1
+   (cmp (bswap@0 @1) INTEGER_CST@2)
+   (with { tree t = TREE_TYPE(@0); }
+(cmp (convert:t @1) (convert:t (bswap @2))