[Bug tree-optimization/106053] New: [13 Regression] wrong code with -O -fno-tree-fre

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 106053
   Summary: [13 Regression] wrong code with -O -fno-tree-fre
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc -O -fno-tree-fre testcase.c -Wno-psabi
$ ./a.out 
Aborted

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-1189-20220621080317-g7905a9ac267-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.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-r13-1189-20220621080317-g7905a9ac267-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20220621 (experimental) (GCC)

[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions

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

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

--- Comment #8 from luoxhu at gcc dot gnu.org ---
(In reply to rguent...@suse.de from comment #6)
> On Tue, 21 Jun 2022, jakub at gcc dot gnu.org wrote:
> 
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740
> > 
> > --- Comment #5 from Jakub Jelinek  ---
> > The problem with switch-conversion done multiple times is that when it is 
> > done
> > early, it can do worse job than when it is done late, e.g. we can have 
> > better
> > range information later which allows (unfortunately switch-conversion 
> > doesn't
> > use that yet, there is a PR about it) to ignore some never reachable values
> > etc.
> > So ideally we either need to be able to undo switch-conversion and redo it 
> > if
> > things have changed, or do it only late and for e.g. inlining costs perform 
> > it
> > only in analysis mode and record somewhere what kind of lowering would be 
> > done
> > and how much it would cost.
> > With multiple if-to-switch, don't we risk that we turn some ifs into switch,
> > then
> > switch-conversion lowers it back to ifs and then another if-to-switch 
> > matches
> > it again and again lowers it?
> 
> Yeah, I think ideally switch conversion would be done as part of switch
> lowering (plus maybe an extra if-to-switch).  The issue might be what
> I said - some passes don't like switches, but they probably need to be
> taught.  As of inline cost yes, doing likely-switch-converted analysis
> would probably work.

git diff
diff --git a/gcc/passes.def b/gcc/passes.def
index b257307e085..1376e7cb28d 100644
--- a/gcc/passes.def
+++ b/gcc/passes.def
@@ -243,8 +243,6 @@ along with GCC; see the file COPYING3.  If not see
 Clean them up.  Failure to do so well can lead to false
 positives from warnings for erroneous code.  */
   NEXT_PASS (pass_copy_prop);
   /* Identify paths that should never be executed in a conforming
 program and isolate those paths.  */
   NEXT_PASS (pass_isolate_erroneous_paths);
@@ -329,6 +327,7 @@ along with GCC; see the file COPYING3.  If not see
   POP_INSERT_PASSES ()
   NEXT_PASS (pass_simduid_cleanup);
   NEXT_PASS (pass_lower_vector_ssa);
+  NEXT_PASS (pass_if_to_switch);
   NEXT_PASS (pass_lower_switch);
   NEXT_PASS (pass_cse_reciprocals);
   NEXT_PASS (pass_reassoc, false /* early_p */);

Tried this to add the second if_to_switch before lower_switch, but switch
lowering doesn't work same as switch_conversion:

;; Function test2 (test2, funcdef_no=0, decl_uid=1982, cgraph_uid=1,
symbol_order=0)

beginning to process the following SWITCH statement ((null):0) : ---
switch (_2)  [INV], case 1:  [INV], case 2:  [INV],
case 3:  [INV], case 4:  [INV], case 5:  [INV], case 6:  [INV]>

;; GIMPLE switch case clusters: JT(values:6 comparisons:6 range:6 density:
100.00%):1-6
Removing basic block 11
;; basic block 11, loop depth 0
;;  pred:
switch (_2)  [INV], case 1:  [INV], case 2:  [INV],
case 3:  [INV], case 4:  [INV], case 5:  [INV], case 6:  [INV]>
;;  succ:   4
;;  5
;;  6
;;  7
;;  8
;;  9
;;  10



Updating SSA:
Registering new PHI nodes in block #0
Registering new PHI nodes in block #2
Updating SSA information for statement _1 = f_10(D)->len;
Registering new PHI nodes in block #3
Updating SSA information for statement _2 = f_10(D)->arr[3];
...
int test2 (struct fs * f)
{
  int _1;
  int _2;
  int _8;

   [local count: 1073741824]:
  _1 = f_10(D)->len;
  if (_1 > 3)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:
  _2 = f_10(D)->arr[3];
  switch (_2)  [0.00%], case 1:  [16.67%], case 2: 
[16.67%], case 3:  [16.67%], case 4:  [16.67%], case 5: 
[16.67%], case 6:  [16.67%]>

   [local count: 67108864]:
:
  goto ; [100.00%]

   [local count: 62914560]:
:
  goto ; [100.00%]

   [local count: 58982400]:
:
  goto ; [100.00%]

   [local count: 55296000]:
:
  goto ; [100.00%]

   [local count: 5184]:
:
  goto ; [100.00%]

   [local count: 4860]:
:

   [local count: 1073741824]: 
 # _8 = PHI <12(4), 27(5), 38(6), 18(7), 58(8), 68(9), 0(3), 0(2)>
:
  return _8;

}

ASM still contains indirect jump table like -fno-switch-conversion:

test2:
.LFB0:
.cfi_startproc
xorl%eax, %eax
cmpl$3, (%rdi)
jle .L1
cmpl$6, 16(%rdi)
ja  .L3
movl16(%rdi), %eax
jmp *.L5(,%rax,8)
.section.rodata
.align 8
.align 4
.L5:
.quad   .L3
.quad   .L11
.quad   .L9
.quad   .L8
.quad   .L7
.quad   .L6
.quad   .L4
.text
.p2align 4,,10
.p2align 3
.L11:
movl$12, %eax
.L1:
ret
.p2align 4,,10
.p2align 3
.L9:
movl$27, %eax
ret
.p2align 4,,10
.p2align 3
.L8:
movl$38, %eax
ret
.p2align 4,,10
.p2alig

[Bug c++/106052] ICE with -Wmismatched-tags with partially specialized friend struct of self type

[beardsley.matt.j at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Matt Beardsley  ---
Just wanted to clarify that the prev. comment only reproduces with an asserted
build.

However, I first observed this in a 300,000+ LOC preprocessed file with a
release gcc build. But I could not stably minimize those reproduction steps
much further below that size.

But I found I could much more consistently hit an ICE using an asserted build
instead, which seems to add up given it looks like it's an out of range access
(which is what the assert is guarding)

[Bug c++/106052] New: ICE with -Wmismatched-tags with partially specialized friend struct of self type

[beardsley.matt.j at gmail dot com via Gcc-bugs]

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

Bug ID: 106052
   Summary: ICE with -Wmismatched-tags with partially specialized
friend struct of self type
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beardsley.matt.j at gmail dot com
  Target Milestone: ---

The following uses gcc built from a fresh repo that I just cloned earlier today
(default build settings)

tmp.cpp:
template 
struct S {
template 
struct S2;

template 
struct S2 {};

friend struct S2, bool>;
};


No ICE with warning off:
$ g++ -c tmp.cpp -o /dev/null -Wno-mismatched-tags
(no output)

ICE with warning on:
$ g++ -c tmp.cpp -o /dev/null -Wmismatched-tags
tmp.cpp: In substitution of ‘template struct S::S2 [with Type = S]’:
tmp.cpp:10:2:   required from here
tmp.cpp:10:2: internal compiler error: tree check: accessed elt 2 of ‘tree_vec’
with 1 elts in tsubst, at cp/pt.cc:15831
   10 | };
  |  ^
0x8ae378 tree_vec_elt_check_failed(int, int, char const*, int, char const*)
../.././gcc/tree.cc:9016
0x9d5d11 tree_vec_elt_check(tree_node*, int, char const*, int, char const*)
../.././gcc/tree.h:3737
0xb71967 tsubst(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.cc:15831
0xb7ff0e tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.cc:13580
0xb80132 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
../.././gcc/cp/pt.cc:13562
0xb6eca7 get_partial_spec_bindings
../.././gcc/cp/pt.cc:25457
0xb6f15b most_specialized_partial_spec(tree_node*, int)
../.././gcc/cp/pt.cc:25703
0xaf2970 specialization_of
../.././gcc/cp/parser.cc:33627
0xaf2970 class_decl_loc_t::diag_mismatched_tags(tree_node*)
../.././gcc/cp/parser.cc:33811
0xaf8db8 class_decl_loc_t::diag_mismatched_tags()
../.././gcc/cp/parser.cc:33935
0xb3c292 c_parse_file()
../.././gcc/cp/parser.cc:48376
0xc721d1 c_common_parse_file()
../.././gcc/c-family/c-opts.cc:1235
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/105870] Asan cannot work correctly for RISC-V GCC

[cooper.joshua at linux dot alibaba.com via Gcc-bugs]

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

--- Comment #8 from JUN SHA  ---
I have fixed this bug and will commit the patch then.

[Bug c++/106051] New: -Wmismatched-tags gives false positive warning when "class C" is "using namespace"d into a namespace with another "class C" declaration

[beardsley.matt.j at gmail dot com via Gcc-bugs]

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

Bug ID: 106051
   Summary: -Wmismatched-tags gives false positive warning when
"class C" is "using namespace"d into a namespace with
another "class C" declaration
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: beardsley.matt.j at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/sx8aT3EKh



The following uses gcc built from a fresh repo that I just cloned earlier today
(default build settings)

tmp.cpp:
  namespace ns {
  class C {};
  }
  using namespace ns;
  class C;

No ambiguity with the warning off:
$ g++ -c tmp.cpp -o /dev/null -Wno-mismatched-tags
(no output)

Now it's ambiguous (also refers to it as "struct C" but it's really "class C")
$ g++ -c tmp.cpp -o /dev/null -Wmismatched-tags
tmp.cpp:5:7: error: reference to ‘C’ is ambiguous
5 | class C;
  |   ^
tmp.cpp:2:7: note: candidates are: ‘class ns::C’
2 | class C {};
  |   ^
tmp.cpp:5:7: note: ‘struct C’
5 | class C;
  |   ^


Not sure how noteworthy this is but if the last 2 lines are swapped the warning
goes away:

tmp.cpp:
  namespace ns {
  class C {};
  }
  class C;
  using namespace ns;

$ g++ -c tmp.cpp -o /dev/null -Wno-mismatched-tags
(no output)

$ g++ -c tmp.cpp -o /dev/null -Wmismatched-tags
(no output)

[Bug target/105991] [12/13 Regression] rldicl+sldi+add generated instead of rldimi

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

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

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

https://gcc.gnu.org/g:4306339798b6843937c628c5ece8c234b309b13d

commit r13-1191-g4306339798b6843937c628c5ece8c234b309b13d
Author: Roger Sayle 
Date:   Wed Jun 22 00:08:56 2022 +0100

PR target/105991: Recognize PLUS and XOR forms of rldimi in rs6000.md.

This patch addresses PR target/105991 where a change to prefer representing
shifts and adds at the tree-level as multiplications, causes problems for
the rldimi patterns in the powerpc backend.  The issue is that rs6000.md
models this pattern using IOR, and some variants that have the equivalent
PLUS or XOR in the RTL fail to match some *rotl4_insert patterns.
This is fixed in this patch by adding a define_insn_and_split to locally
canonicalize the PLUS and XOR forms to the backend's preferred IOR form.

An alternative fix might be for the RTL optimizers to define a canonical
form for these plus_xor_ior equivalent expressions, but the logical
choice might be plus (which may appear in an addressing mode), and such
a change may require a number of tweaks to update various backends
(i.e.  a more intrusive change than the one proposed here).

Many thanks for Marek Polacek for bootstrapping and regression testing
this change without problems.

2022-06-22  Roger Sayle  
Marek Polacek  
Segher Boessenkool  
Kewen Lin  

gcc/ChangeLog
PR target/105991
* config/rs6000/rs6000.md (rotl3_insert_3): Check that
exact_log2 doesn't return -1 (or zero).
(plus_xor): New code iterator.
(*rotl3_insert_3_): New define_insn_and_split.

gcc/testsuite/ChangeLog
PR target/105991
* gcc.target/powerpc/pr105991.c: New test case.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #0)
> % cat a.f90
> program bug
>implicit none
>integer i
>i = 42
>block
>   import none  ! <-- This is valid Fortran 2018

Note, there is a comma missing after import.  So this isn't valid.
One finds these things while implementing a patch.  The patch
includes a description of all constraints in F2018, but I did not
implement them all.  For example, this is invalid (assuming i and
j are available via host association)

interface
   subroutine foo
  import, only : i
  import
   end subroutine foo
end interface

as is

interface
   subroutine foo
  import, only : i
  import :: j
   end subroutine foo
end interface

To do this correctly, gfortran likely needs IMPORT_NONE, IMPORT_ONLY, and
IMPORT_ALL enumerators and then gfc_current_ns->has_import_set would be
set according to one of these instead of using just 0 and 1 for a namespace.

[Bug fortran/106035] F2018 allows an IMPORT statement within the BLOCK construct.

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

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

--- Comment #1 from kargl at gcc dot gnu.org ---
Created attachment 53187
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53187&action=edit
implementation of feature; no testcases

The attach patch has had some minimal testing while it was under development. 
For those test, the patch and gfortran appeared to do the right things.

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #53171|0   |1
is obsolete||

--- Comment #10 from H.J. Lu  ---
Created attachment 53186
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53186&action=edit
The v3 patch

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

--- Comment #6 from Steve Kargl  ---
On Tue, Jun 21, 2022 at 09:28:27PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105691
> 
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> Submitted version: https://gcc.gnu.org/pipermail/fortran/2022-June/057940.html
> 

Harald, looks like a straight forward translation of the 
library algorithm.  OK to commit.

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Submitted version: https://gcc.gnu.org/pipermail/fortran/2022-June/057940.html

[Bug c++/99963] [11 Regression] [concepts] template vs concept auto reports ambiguous overload

[tabloid.adroit at gmail dot com via Gcc-bugs]

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

tabloid.adroit at gmail dot com changed:

   What|Removed |Added

 CC||tabloid.adroit at gmail dot com

--- Comment #4 from tabloid.adroit at gmail dot com ---
(In reply to Patrick Palka from comment #1)
> Started with r11-1571.  Reduced testcase that replaces the abbreviated
> function templates with their corresponding non-abbreviated forms:
> 
> template  concept C1 = true;
> template  concept C2 = C1 && true;
> 
> template  int f(T, U);
> template  int f(U, T);
> 
> int x = f(0, 0); // error: ambiguous call
> 
> 
> If I understand the wording of P2113 correctly:
> 
>   If deduction against the other template succeeds for both transformed
> templates, constraints can be considered as follows:
>   - ... if the corresponding template-parameters of the
> template-parameter-lists are not equivalent ([temp.over.link]) or if the
> function parameters that positionally correspond between the two templates
> are not of the same type, neither template is more specialized than the other
> 
> then I think we're correct to reject the call as ambiguous because although
> the second overload is more constrained than the first, their function
> parameter lists aren't equivalent.

IMHO, `template  int f(U, T);` should win over `template  int f(T, U);`.

Based on interpreting the intent mentioned in
https://github.com/cplusplus/nbballot/issues/119 and the second example in
https://eel.is/c++draft/temp.fct#temp.func.order-example-6, the `corresponding`
(of the `corresponding template-parameters of ...`) relationship is based on
the mapping used during partial-ordering deduction. So the deduction between
`f(T, ..)` against `f(U, ..)` builds the  mapping, the deduction between
`f(.., U)` against `f(.., T)` builds the  mapping. The correspondence is
[T, U] against [U, T]. So `C1 T` is less constrained than `C2 U`, thus the
second `f` wins.

[Bug c++/98469] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6350

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug fortran/106050] ICE in reject_statement, at fortran/parse.cc:2879

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-21
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
With torched input, I might expect the symbol table to get sideways.  Before
asserting the reference count is zero, check if the count is negative and an
error message has already been emitted.

diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 7a80dfd063b..3aa2b9bd962 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3106,6 +3106,7 @@ gfc_free_symbol (gfc_symbol *&sym)
 void
 gfc_release_symbol (gfc_symbol *&sym)
 {
+
   if (sym == NULL)
 return;

@@ -3123,6 +3124,14 @@ gfc_release_symbol (gfc_symbol *&sym)
   if (sym->refs > 0)
 return;

+  if (sym->refs < 0)
+{
+  int ecnt;
+  gfc_get_errors (NULL, &ecnt);
+  if (ecnt > 0)
+   return;
+}
+
   gcc_assert (sym->refs == 0);
   gfc_free_symbol (sym);
 }

[Bug fortran/105691] Incorrect calculation of INDEX(str1,str2) at compile time

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #3)
> There is no need to special case the substring length of 1 case with my
> suggested patch.  Here's an update to eliminate the special case.

Frankly speaking, gfc_simplify_index is a mess.  The library code is a relief.
I'd take that as reference.

Thus taking.

[Bug c++/105824] Accepts invalid issue with implicit conversion of a scoped enumeration type

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

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

--- Comment #2 from Andrew Pinski  ---
Interesting MSVC accepts it too ...

[Bug c/105775] GCC uses an invalid assumption in numeric limits of char

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic

--- Comment #2 from Andrew Pinski  ---
I am trying to understand the issue here.
Are you saying the warning for "comparison is always true due to limited range
of data type" should not happen for the char type as it could either be signed
or unsigned?

[Bug fortran/106050] New: ICE in reject_statement, at fortran/parse.cc:2879

[gscfq--- via Gcc-bugs]

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

Bug ID: 106050
   Summary: ICE in reject_statement, at fortran/parse.cc:2879
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r8 :
(out of order statement)


$ cat z1.f90
program p
   stop
   type t(k)
  integer, kind :: k = 4
   end type
end

$ cat z2.f90
program p
   continue
   type t(k)
  integer, kind :: k = 4
   end type
end

$ cat z3.f90
program p
   a = 1
   type t(k)
  integer, kind :: k = 4
   end type
end

$ cat z4.f90
program p
   print *
   type t(k)
  integer, kind :: k = 4
   end type
end


$ gfortran-13-20220619 -c z1.f90
z1.f90:3:12:

3 |type t(k)
  |1
Error: Unexpected derived type declaration statement at (1)
f951: internal compiler error: Segmentation fault
0xe845df crash_signal
../../gcc/toplev.cc:322
0x70b53a delete_root
../../gcc/fortran/bbt.cc:150
0x70b6fe gfc_delete_bbt(void*, void*, int (*)(void*, void*))
../../gcc/fortran/bbt.cc:197
0x7deca8 gfc_delete_symtree(gfc_symtree**, char const*)
../../gcc/fortran/symbol.cc:2963
0x7e053d gfc_restore_last_undo_checkpoint()
../../gcc/fortran/symbol.cc:3708
0x7950f7 reject_statement
../../gcc/fortran/parse.cc:2879
0x79f8aa parse_progunit
../../gcc/fortran/parse.cc:6257
0x7a0ea1 gfc_parse_file()
../../gcc/fortran/parse.cc:6755
0x7ef83f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/106049] New: ICE in gfc_simplify_pack, at fortran/simplify.cc:6481

[gscfq--- via Gcc-bugs]

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

Bug ID: 106049
   Summary: ICE in gfc_simplify_pack, at fortran/simplify.cc:6481
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   type t
   end type
   type(t), parameter :: a = [t ::]
   type(t), parameter :: b(1,1) = a
   type(t) :: c(1) = pack(reshape(b, [1]), [.true.])
end


$ gfortran-13-20220619 -c z1.f90
f951: internal compiler error: Segmentation fault
0xcd90df crash_signal
../../gcc/toplev.cc:322
0x7929dd gfc_simplify_pack(gfc_expr*, gfc_expr*, gfc_expr*)
../../gcc/fortran/simplify.cc:6481
0x70f64a do_simplify
../../gcc/fortran/intrinsic.cc:4677
0x71a52a gfc_intrinsic_func_interface(gfc_expr*, int)
../../gcc/fortran/intrinsic.cc:5056
0x76f068 resolve_unknown_f
../../gcc/fortran/resolve.cc:2990
0x76f068 resolve_function
../../gcc/fortran/resolve.cc:3347
0x76f068 gfc_resolve_expr(gfc_expr*)
../../gcc/fortran/resolve.cc:7187
0x6ff504 gfc_reduce_init_expr(gfc_expr*)
../../gcc/fortran/expr.cc:3163
0x702490 gfc_match_init_expr(gfc_expr**)
../../gcc/fortran/expr.cc:3211
0x6ec7d4 variable_decl
../../gcc/fortran/decl.cc:3004
0x6ec7d4 gfc_match_data_decl()
../../gcc/fortran/decl.cc:6299
0x757583 match_word
../../gcc/fortran/parse.cc:67
0x757583 decode_statement
../../gcc/fortran/parse.cc:378
0x758fca next_free
../../gcc/fortran/parse.cc:1397
0x758fca next_statement
../../gcc/fortran/parse.cc:1629
0x75a55b parse_spec
../../gcc/fortran/parse.cc:4168
0x75d6fc parse_progunit
../../gcc/fortran/parse.cc:6210
0x75edc1 gfc_parse_file()
../../gcc/fortran/parse.cc:6755
0x7acb6f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/106048] New: [10/11/12/13 Regression] ICE in ubsan_encode_value, at ubsan.cc:143 / verify_gimple failed

[gscfq--- via Gcc-bugs]

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

Bug ID: 106048
   Summary: [10/11/12/13 Regression] ICE in ubsan_encode_value, at
ubsan.cc:143 / verify_gimple failed
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7, with and without -fsanitize=undefined :


$ cat z1.f90
program p
   integer :: real
   print *, real(2)
   associate (y => real+real)
  print *, y
   end associate
end


$ cat z2.f90
program p
   integer :: n
   print *, n(2)
   associate (y => n+n)
  print *, y
   end associate
end


$ gfortran-13-20220619 -c z1.f90
/tmp/cc97osCU.s: Assembler messages:
/tmp/cc97osCU.s:35: Error: junk `(intrinsic)_MOD_real' after expression


$ gfortran-13-20220619 -c z1.f90 -fsanitize=undefined
during RTL pass: expand
z1.f90:5:16:

5 |   print *, y
  |^
internal compiler error: in ubsan_encode_value, at ubsan.cc:143
0xcf9ca2 ubsan_encode_value(tree_node*, ubsan_encode_value_phase)
../../gcc/ubsan.cc:143
0xcfe316 ubsan_build_overflow_builtin(tree_code, unsigned int, tree_node*,
tree_node*, tree_node*, tree_node**)
../../gcc/ubsan.cc:1562
0xa72326 expand_mul_overflow
../../gcc/internal-fn.cc:2270
0xa749c6 expand_UBSAN_CHECK_MUL
../../gcc/internal-fn.cc:2516
0x8820e7 expand_call_stmt
../../gcc/cfgexpand.cc:2737
0x8820e7 expand_gimple_stmt_1
../../gcc/cfgexpand.cc:3869
0x8820e7 expand_gimple_stmt
../../gcc/cfgexpand.cc:4033
0x887297 expand_gimple_basic_block
../../gcc/cfgexpand.cc:6085
0x889d5e execute
../../gcc/cfgexpand.cc:6811

---

gcc configured with --enable-checking=yes :

$ gfortran-13-20220619 -c z1.f90
z1.f90:1:9:

1 | program p
  | ^
Error: type mismatch in binary expression
integer(kind=4)

integer(kind=4) (*) ()

integer(kind=4)

_1 = real * 2;
z1.f90:1:9: internal compiler error: 'verify_gimple' failed
0xed9e9d verify_gimple_in_seq(gimple*)
../../gcc/tree-cfg.cc:5217
0xb557b1 gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:16543
0xb55a55 gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:16659
0x964c47 cgraph_node::analyze()
../../gcc/cgraphunit.cc:676
0x967ef6 analyze_functions
../../gcc/cgraphunit.cc:1241
0x9690cd symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2501

[Bug fortran/106047] New: ICE in structure_alloc_comps, at fortran/trans-array.cc:9574

[gscfq--- via Gcc-bugs]

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

Bug ID: 106047
   Summary: ICE in structure_alloc_comps, at
fortran/trans-array.cc:9574
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   type t
  character(:), allocatable :: c
   end type
   type(t) :: x
   integer :: n = storage_size(x)
end


$ gfortran-13-20220619 -c z1.f90
z1.f90:5:15:

5 |type(t) :: x
  |   1
internal compiler error: Segmentation fault
0xcd90df crash_signal
../../gcc/toplev.cc:322
0x7c6620 structure_alloc_comps
../../gcc/fortran/trans-array.cc:9574
0x7c7348 gfc_nullify_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../gcc/fortran/trans-array.cc:10149
0x7c7348 gfc_trans_deferred_array(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-array.cc:11206
0x7dabac gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.cc:4994
0x7dd1a5 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7756
0x75f53e translate_all_program_units
../../gcc/fortran/parse.cc:6669
0x75f53e gfc_parse_file()
../../gcc/fortran/parse.cc:6956
0x7acb6f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/105807] ICE / error when defining a class containing polymorphic components

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

 CC||gs...@t-online.de

--- Comment #2 from G. Steinmetz  ---

Some simplified versions :


$ cat z1.f90
program p
type, abstract :: t
end type
type, abstract :: t2
integer :: n
class(t), allocatable :: v
end type
type, extends(t2) :: elem2d
end type
type, extends(t) :: vect3d
end type
type(vect3d) :: b
class(t2), allocatable :: e
e = elem2d(10,b)
end program


$ cat z2.f90
program p
type t
end type
type t2
integer :: n
class(t), allocatable :: v
end type
type, extends(t2) :: elem2d
end type
type, extends(t) :: vect3d
end type
type(vect3d) :: b
class(t2), allocatable :: e
e = elem2d(10,b)
end program


$ gfortran-13-20220619 -c z1.f90
z1.f90:14:20:

   14 | e = elem2d(10,b)
  |1
internal compiler error: in fold_convert_loc, at fold-const.cc:2593
0x9c67b3 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.cc:2593
0x7eb806 gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.cc:9004
0x7ec3bb gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.cc:9197
0x7ebec2 gfc_trans_subcomponent_assign
../../gcc/fortran/trans-expr.cc:9021
0x7ec3bb gfc_trans_structure_assign(tree_node*, gfc_expr*, bool, bool)
../../gcc/fortran/trans-expr.cc:9197
0x7e4970 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc/fortran/trans-expr.cc:9264
0x7e4cfc gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9432
0x7f5f91 gfc_trans_assignment_1
../../gcc/fortran/trans-expr.cc:11700
0x7b3b67 trans_code
../../gcc/fortran/trans.cc:1950
0x7dd0be gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7654
0x75f53e translate_all_program_units
../../gcc/fortran/parse.cc:6669
0x75f53e gfc_parse_file()
../../gcc/fortran/parse.cc:6956
0x7acb6f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug c++/80637] [concepts] incorrect ambiguous overload

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

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

--- Comment #2 from Andrew Pinski  ---
clang accepts this while MSVC rejects this for the same reason as GCC.

[Bug c++/80637] [concepts] incorrect ambiguous overload

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 53185
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53185&action=edit
Updated full testcase

[Bug c++/106046] GCC fails to disambiguate call to static member function when inside a class template

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

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

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

[Bug target/105960] [12/13 Regression] Crash in 32-bit mode

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:2474c8e09a93027cde39ecb6a53742142c8496ed

commit r12-8501-g2474c8e09a93027cde39ecb6a53742142c8496ed
Author: H.J. Lu 
Date:   Tue Jun 14 08:20:16 2022 -0700

i386: Disallow sibcall for calling ifunc functions with PIC register

Disallow siball when calling ifunc functions with PIC register so that
PIC register can be restored.

gcc/

PR target/105960
* config/i386/i386.cc (ix86_function_ok_for_sibcall): Return
false if PIC register is used when calling ifunc functions.

gcc/testsuite/

PR target/105960
* gcc.target/i386/pr105960.c: New test.

(cherry picked from commit fe9765c0b97e6b4ce2cd226631d329fc05ba2aa5)

[Bug tree-optimization/105651] [12/13 Regression] bogus "may overlap" memcpy warning with std::string

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection,
   ||needs-reduction
 Ever confirmed|0   |1
   Last reconfirmed||2022-06-21
 Status|UNCONFIRMED |NEW

--- Comment #7 from Andrew Pinski  ---
Slightly more reduced testcase (still has system headers):
#include 

std::string f()
{
   return "_" + std::string(" ");
}

[Bug tree-optimization/105651] [12/13 Regression] bogus "may overlap" memcpy warning with std::string

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|bogus "may overlap" memcpy  |[12/13 Regression] bogus
   |warning with std::string|"may overlap" memcpy
   ||warning with std::string
  Known to work||11.1.0
   Target Milestone|--- |12.2

[Bug tree-optimization/105651] bogus "may overlap" memcpy warning with std::string

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||cuzdav at gmail dot com

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

[Bug tree-optimization/106044] Spurious warning: -Wrestrict for adding std::strings (__builtin_memcpy)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 105651.

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

[Bug c++/106046] New: GCC fails to disambiguate call to static member function when inside a class template

[jlame646 at gmail dot com via Gcc-bugs]

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

Bug ID: 106046
   Summary: GCC fails to disambiguate call to static member
function when inside a class template
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jlame646 at gmail dot com
  Target Milestone: ---

The following example fails to compile with gcc 11.2 while it works with other
compilers like clang and msvc. This can be verified
here:https://godbolt.org/z/oK3xxTT14

The example is as follows:

```
#include 
#include 

template concept NodeFunctionType =
std::invocable, int>;
template concept ExtracterType = requires { typename
T::I_am_an_extracter; };

template
struct NodeMaker {
  template
  static constexpr auto create_node(Args&&... args) { return new
T(std::forward(args)...); }

  template requires (!ExtracterType)
  static constexpr auto create_node(DataMaker&& data_maker) { return
create_node(); } // line 13

  template requires (!NodeFunctionType)
  static constexpr auto create_node(DataMaker&& data_maker) { return
create_node(); } // line 16

  void do_something() {
const auto target = create_node(0);  //this does not work in gcc
  }
};

int main() {
  const auto target = NodeMaker<>::create_node(0); //but this works
}
```

I have placed comments in the above example so that it will be easier to see
where the problem is. As can be seen in the above example, the issue is with
the call `create_node(0)` from inside `do_something`. 

Moreover i noticed that we can resolve this issue by explicitly qualifying the
call with `NodeMaker<>::` as shown below:

```
void do_something() 
{
//--v--->added this qualification
const auto target = NodeMaker<>::create_node(0); //works now in gcc
  }
```
After explicitly qualification the program works. Demo:
https://godbolt.org/z/oMddPGj6x

Additionally, note that if we use `NodeMaker::` instead of `NodeMaker<>::`
then the issue will reappear. Demo: https://godbolt.org/z/xfK1nG9s5

```
void do_something() {
const auto target = NodeMaker::create_node(0);  //this does not work in
gcc
  }
```

[Bug libgomp/106045] Incorrect testcase in libgomp.c/target-31.c at -O0

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Thanks, fixed for 13 now.

[Bug libgomp/106045] Incorrect testcase in libgomp.c/target-31.c at -O0

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

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

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

https://gcc.gnu.org/g:85d613da341b76308edea48359a5dbc7061937c4

commit r13-1190-g85d613da341b76308edea48359a5dbc7061937c4
Author: Jakub Jelinek 
Date:   Tue Jun 21 17:51:08 2022 +0200

libgomp: Fix up target-31.c test [PR106045]

The i variable is used inside of the parallel in:
  #pragma omp simd safelen(32) private (v)
  for (i = 0; i < 64; i++)
{
  v = 3 * i;
  ll[i] = u1 + v * u2[0] + u2[1] + x + y[0] + y[1] + v + h[0] +
u3[i];
}
where i is predetermined linear (so while inside of the body
it is safe, private per SIMD lane var) the final value is written to
the shared variable, and in:
  for (i = 0; i < 64; i++)
if (ll[i] != u1 + 3 * i * u2[0] + u2[1] + x + y[0] + y[1] + 3 * i +
13 + 14 + i)
  #pragma omp atomic write
err = 1;
which is a normal loop and so it isn't in any way privatized there.
So we have a data race, fixed by adding private (i) clause to the
parallel.

2022-06-21  Jakub Jelinek  
Paul Iannetta  

PR libgomp/106045
* testsuite/libgomp.c/target-31.c: Add private (i) clause.

[Bug target/106038] x86_64 vectorization of ALU ops using xmm registers prematurely

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---

> backwards STV?

There's a pass in x86 backend called STV(scalar to vector, the pass convert
scalar instructions into vector mode when profitable), I guess "backwards STV"
means converting vector instruction back to scalar mode.

[Bug tree-optimization/105545] [12/13 Regression] Warning for string assignment with _GLIBCXX_ASSERTIONS since r12-3347-g8af8abfbbace49e6

[pdimov at gmail dot com via Gcc-bugs]

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

Peter Dimov  changed:

   What|Removed |Added

 CC||pdimov at gmail dot com

--- Comment #7 from Peter Dimov  ---
FWIW, I'm getting this warning in one of the Boost.Describe examples
(https://godbolt.org/z/WKMjeTdne) from innocent-looking code that concatenates
std::strings with op+.

[Bug target/106038] x86_64 vectorization of ALU ops using xmm registers prematurely

[goldstein.w.n at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Noah Goldstein  ---
(In reply to Richard Biener from comment #4)
> The vectorizer does not anticipate store-merging performing "vectorization"
> in GPRs and thus the scalar cost is off (it also doesn't anticipate the
> different
> ISA constraints wrt xmm vs gpr usage).
> 
> I wonder if we should try to follow what store-merging would do with respect
> to "vector types", thus prefer "general vectors" (but explicitely via integer
> types since we can't have vector types with both integer and vector modes)
> when possible (for bit operations and plain copies).
> 
> scanning over an SLP instance (group) and substituting integer types for
> SLP_TREE_VECTYPE might be possible.  Doing this nicely somewhere is going to
> be more interesting.  Far away vectorizable_* should compute a set of
> { vector-type, cost } pairs from the set of input operand vector-type[, cost]
> pair sets.  Not having "generic" vectors as vector types and relying on
> vector lowering to expand them would be an incremental support step for this
> I guess.
> 
> "backwards STV" could of course also work on the target side.

backwards STV?

[Bug libstdc++/97936] [11/12 Regression] 30_threads/latch/3.cc hangs

[sumbera at volny dot cz via Gcc-bugs]

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

Petr Sumbera  changed:

   What|Removed |Added

 CC||sumbera at volny dot cz

--- Comment #19 from Petr Sumbera  ---
I believe I still see the issue (these tests randomly fail like this):

=== libstdc++ tests ===

Running target unix
FAIL: 27_io/filesystem/iterators/error_reporting.cc (test for excess errors)
WARNING: program timed out.
FAIL: 29_atomics/atomic_float/wait_notify.cc execution test
WARNING: program timed out.
FAIL: 29_atomics/atomic_integral/wait_notify.cc execution test
WARNING: program timed out.
FAIL: 29_atomics/atomic_ref/wait_notify.cc execution test
WARNING: program timed out.
FAIL: 30_threads/latch/3.cc execution test
WARNING: program timed out.

==

This is Solaris with GCC 12.1.0 and 11.3.0.

[Bug go/106033] [13 Regression] libgo fails with error: reference to undefined name ‘_libgo_loff_t_type’ since r13-1159-g7f195a2270910a

[ian at airs dot com via Gcc-bugs]

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

Ian Lance Taylor  changed:

   What|Removed |Added

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

--- Comment #4 from Ian Lance Taylor  ---
Should be fixed now, sorry for the trouble.

[Bug go/106033] [13 Regression] libgo fails with error: reference to undefined name ‘_libgo_loff_t_type’ since r13-1159-g7f195a2270910a

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Ian Lance Taylor :

https://gcc.gnu.org/g:7905a9ac26707ed6ac49e40e35a9c8755c6574e3

commit r13-1189-g7905a9ac26707ed6ac49e40e35a9c8755c6574e3
Author: Ian Lance Taylor 
Date:   Sat Jun 18 18:19:28 2022 -0700

libgo: #include  when checking for loff_t

PR go/106033

Fixes golang/go#53469

Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/413214

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

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

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

--- Comment #5 from Marc Poulhiès  ---
Oh, nice, should have checked before commenting then ! Thanks !

[Bug tree-optimization/106044] Spurious warning: -Wrestrict for adding std::strings (__builtin_memcpy)

[cuzdav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Chris Uzdavinis  ---
Even marginally simpler:

#include 
auto f() {
return "_" + std::string(" ");
}


Originally I marked it as tree-optimization since it's only with -O3, but it
could be an issue in the standard library itself. I didn't consider that
initially.

[Bug target/106022] [12/13 Regression] Enable vectorizer generates extra load

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #9 from H.J. Lu  ---
(In reply to Richard Biener from comment #8)
> (In reply to H.J. Lu from comment #6)
> > Created attachment 53169 [details]
> > A patch
> > 
> > This patch multiplies the vector store cost by the number of scalar elements
> > in
> > a word to properly compare scalar store cost against vector store cost.
> 
> But that's not "properly" but "wrong" ...
> 
> Note we already cost the vector load from the constant pool so the vector
> side costing is correct.
> 
> What's eventually imprecise is the scalar cost where you could anticipate
> store merging, but adjusting the vector cost side is just wrong.

I tried to adjust the scalar cost.  When the scalar cost of storing a byte
is 6, dividing it by 8 (the number of scalar elements in a word) becomes 0.
Will it work?

[Bug gcov-profile/106036] Missing stdint.h include in libgcc/libgcov.h

[kacper.slominski72 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Kacper Słomiński  ---
Okay, this seems to have been a false alarm, sorry for that! Our C library was
missing the typedef for intptr_t in unistd.h, which POSIX does specify. After
adding that, libgcc compiled without problems. It appears that the typedefs in
gcc/gcov-io.h are either not compiled in at all, or are only compiled in when
stdint.h has been included before (I haven't looked into which of the two
happens exactly).

Feel free to close this as RESOLVED INVALID and disregard the patch I sent to
gcc-patches, and again, sorry for the false alarm.

[Bug libgomp/106045] New: Incorrect testcase in libgomp.c/target-31.c at -O0

[piannetta at kalrayinc dot com via Gcc-bugs]

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

Bug ID: 106045
   Summary: Incorrect testcase in libgomp.c/target-31.c at -O0
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: piannetta at kalrayinc dot com
CC: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53183
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53183&action=edit
patch which add the private clause on i

When investigating a test failure in the openmp testsuite, we found that the
test target-31.c exhibit a wrong behavior at -O0.

This is due to a missing private clause on the i variable.  At higher
optimization levels, the i variable is optimized out which makes the wrong
behavior disappear.

In attachment, a patch adding the missing private clause.

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

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

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

--- Comment #4 from Thomas Schwinge  ---
(In reply to Marc Poulhiès from comment #3)
> Fixed in github, but not yet in gcc's repository AFAIK.

It is, as of today, 10:33 UTC, when I did the 'git push'.  ;-).


(If there's more to do, then please re-open this PR, of course.)

[Bug c++/104872] Memory corruption in Coroutine with POD type

[benni.buch at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Benjamin Buch  ---
Bug is still present in GCC 12.1 and current trunk.

[Bug tree-optimization/106044] Spurious warning: -Wrestrict for adding std::strings (__builtin_memcpy)

[cuzdav at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Chris Uzdavinis  ---
only in c++20, too.

[Bug tree-optimization/106044] New: Spurious warning: -Wrestrict for adding std::strings (__builtin_memcpy)

[cuzdav at gmail dot com via Gcc-bugs]

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

Bug ID: 106044
   Summary: Spurious warning: -Wrestrict for adding std::strings
(__builtin_memcpy)
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cuzdav at gmail dot com
  Target Milestone: ---

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

At optimization O3, beginning in g++ 12.1 (and still present in trunk) with
-Wrestrict enabled I see the following warning:

warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807]
and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]

Here is the code:

///
#include 

std::string f(std::size_t n) {
return "_" + std::to_string(n);
}
///

On Compiler explorer: https://godbolt.org/z/KMWehnscM

Command line:

g++12 -O3 --std=c++20 -Wrestrict source.cpp

Output:
In file included from
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/string:40,
 from :1:
In static member function 'static constexpr std::char_traits::char_type*
std::char_traits::copy(char_type*, const char_type*, std::size_t)',
inlined from 'static constexpr void std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::_S_copy(_CharT*, const _CharT*, size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.h:423:21,
inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_replace(size_type, size_type, const _CharT*, size_type) [with
_CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.tcc:532:22,
inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::replace(size_type, size_type, const _CharT*, size_type) [with _CharT =
char; _Traits = std::char_traits; _Alloc = std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.h:2171:19,
inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>& std::__cxx11::basic_string<_CharT, _Traits, _Alloc>::insert(size_type,
const _CharT*) [with _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.h:1928:22,
inlined from 'constexpr std::__cxx11::basic_string<_CharT, _Traits,
_Allocator> std::operator+(const _CharT*, __cxx11::basic_string<_CharT,
_Traits, _Allocator>&&) [with _CharT = char; _Traits = char_traits;
_Alloc = allocator]' at
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/basic_string.h:3594:36,
inlined from 'std::string f(std::size_t)' at :4:34:
/opt/compiler-explorer/gcc-trunk-20220621/include/c++/13.0.0/bits/char_traits.h:434:56:
warning: 'void* __builtin_memcpy(void*, const void*, long unsigned int)'
accessing 9223372036854775810 or more bytes at offsets [2, 9223372036854775807]
and 1 may overlap up to 9223372036854775813 bytes at offset -3 [-Wrestrict]
  434 | return static_cast(__builtin_memcpy(__s1, __s2,
__n));
  |   
^
Compiler returned: 0

//

local machine g++ output (where I first encountered it)

[cuzdav@docker tmp]$ /opt/imc/gcc-12.1.0/bin/g++ -v 
Using built-in specs.
COLLECT_GCC=/opt/imc/gcc-12.1.0/bin/g++
COLLECT_LTO_WRAPPER=/opt/imc/gcc-12.1.0/libexec/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-12.1.0/configure --prefix=/opt/imc/gcc-12.1.0
--enable-languages=c,c++,fortran,lto --disable-multilib
--with-build-time-tools=/build/INSTALLDIR//opt/imc/gcc-12.1.0/bin
--enable-libstdcxx-time=rt
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.1.0 (GCC)

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

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

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

--- Comment #3 from Marc Poulhiès  ---
Fixed in github, but not yet in gcc's repository AFAIK.

[Bug rust/105913] gccrs doesn't compile on 32-bit targets

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #2 from Thomas Schwinge  ---
Assuming fixed via  "Fix
formatting error on 32-bits targets".

[Bug tree-optimization/94899] Failure to optimize out add before compare with INT_MIN

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

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

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

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

commit r13-1187-gab981aab92cbc71918fbaadcf6fa64bdb2b69be7
Author: Arjun Shankar 
Date:   Tue Jun 21 12:12:11 2022 +0200

match.pd: Remove "+ 0x8000" in int comparisons [PR94899]

Expressions of the form "X + CST < Y + CST" where:

* CST is an unsigned integer constant with only the MSB set, and
* X and Y's types have integer conversion ranks <= CST's

can be simplified to "(signed) X < (signed) Y".

This is because, assuming a 32-bit signed numbers,
(unsigned) INT_MIN + 0x8000 is 0, and
(unsigned) INT_MAX + 0x8000 is UINT_MAX.

i.e. the result increases monotonically with signed input.

This means:
((signed) X < (signed) Y) iff (X + 0x8000 < Y + 0x8000)

gcc/
PR tree-optimization/94899
* match.pd (X + C < Y + C -> (signed) X < (signed) Y, if C is
0x8000): New simplification.
gcc/testsuite/
* gcc.dg/pr94899.c: New test.

[Bug rtl-optimization/106032] [10/11/12/13 Regression] wrong code at -Os and above on x86_64-linux-gnu

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

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

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

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

commit r13-1186-ga0c30fe3b888f20215f3e040d21b62b603804ca9
Author: Jakub Jelinek 
Date:   Tue Jun 21 11:40:16 2022 +0200

ifcvt: Don't introduce trapping or faulting reads in noce_try_sign_mask
[PR106032]

noce_try_sign_mask as documented will optimize
  if (c < 0)
x = t;
  else
x = 0;
into x = (c >> bitsm1) & t;
The optimization is done if either t is unconditional
(e.g. for
  x = t;
  if (c >= 0)
x = 0;
) or if it is cheap.  We already check that t doesn't have side-effects,
but if t is conditional, we need to punt also if it may trap or fault,
as we make it unconditional.

I've briefly skimmed other noce_try* optimizations and didn't find one that
would suffer from the same problem.

2022-06-21  Jakub Jelinek  

PR rtl-optimization/106032
* ifcvt.cc (noce_try_sign_mask): Punt if !t_unconditional, and
t may_trap_or_fault_p, even if it is cheap.

* gcc.c-torture/execute/pr106032.c: New test.

[Bug middle-end/106030] [13 Regression] ice in emit_move_insn, at expr.cc:4026

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

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

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

https://gcc.gnu.org/g:2df1df945fac85d7b3d084001414a66a2709d8fe

commit r13-1185-g2df1df945fac85d7b3d084001414a66a2709d8fe
Author: Jakub Jelinek 
Date:   Tue Jun 21 11:38:59 2022 +0200

expand: Fix up expand_cond_expr_using_cmove [PR106030]

If expand_cond_expr_using_cmove can't find a cmove optab for a particular
mode, it tries to promote the mode and perform the cmove in the promoted
mode.

The testcase in the patch ICEs on arm because in that case we pass temp
which
has the promoted mode (SImode) as target to expand_operands where the
operands have the non-promoted mode (QImode).
Later on the function uses paradoxical subregs:
  if (GET_MODE (op1) != mode)
op1 = gen_lowpart (mode, op1);

  if (GET_MODE (op2) != mode)
op2 = gen_lowpart (mode, op2);
to change the operand modes.

The following patch fixes it by passing NULL_RTX as target if it has
promoted mode.

2022-06-21  Jakub Jelinek  

PR middle-end/106030
* expr.cc (expand_cond_expr_using_cmove): Pass NULL_RTX instead of
temp to expand_operands if mode has been promoted.

* gcc.c-torture/compile/pr106030.c: New test.

[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Xiong Hu Luo :

https://gcc.gnu.org/g:57424087e82db140c06d4ea73f9700d5291c5bc2

commit r13-1184-g57424087e82db140c06d4ea73f9700d5291c5bc2
Author: Xionghu Luo 
Date:   Thu Jun 9 15:46:30 2022 +0800

if-to-switch: Don't skip the first condition bb when find_conditions in
if-to-switch [PR105740]

The if condition is at last of first bb, so side effect statement in first
BB
doesn't matter, then the first if condition could also be folded to switch
table.

gcc/ChangeLog:

PR target/105740
* gimple-if-to-switch.cc (find_conditions): Don't skip the first
condition bb.

gcc/testsuite/ChangeLog:

PR target/105740
* gcc.dg/tree-ssa/if-to-switch-11.c: New test.

Signed-off-by: Xionghu Luo 

[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #6 from rguenther at suse dot de  ---
On Tue, 21 Jun 2022, jakub at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105740
> 
> --- Comment #5 from Jakub Jelinek  ---
> The problem with switch-conversion done multiple times is that when it is done
> early, it can do worse job than when it is done late, e.g. we can have better
> range information later which allows (unfortunately switch-conversion doesn't
> use that yet, there is a PR about it) to ignore some never reachable values
> etc.
> So ideally we either need to be able to undo switch-conversion and redo it if
> things have changed, or do it only late and for e.g. inlining costs perform it
> only in analysis mode and record somewhere what kind of lowering would be done
> and how much it would cost.
> With multiple if-to-switch, don't we risk that we turn some ifs into switch,
> then
> switch-conversion lowers it back to ifs and then another if-to-switch matches
> it again and again lowers it?

Yeah, I think ideally switch conversion would be done as part of switch
lowering (plus maybe an extra if-to-switch).  The issue might be what
I said - some passes don't like switches, but they probably need to be
taught.  As of inline cost yes, doing likely-switch-converted analysis
would probably work.

[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64

[jan.wassenberg at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Jan Wassenberg  ---
Sure, added GCC11 .ii. It does indeed still freeze GCC 12.

[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64

[jan.wassenberg at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Jan Wassenberg  ---
Created attachment 53181
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53181&action=edit
GCC11 zipped preprocessed source

[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions

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

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

--- Comment #5 from Jakub Jelinek  ---
The problem with switch-conversion done multiple times is that when it is done
early, it can do worse job than when it is done late, e.g. we can have better
range information later which allows (unfortunately switch-conversion doesn't
use that yet, there is a PR about it) to ignore some never reachable values
etc.
So ideally we either need to be able to undo switch-conversion and redo it if
things have changed, or do it only late and for e.g. inlining costs perform it
only in analysis mode and record somewhere what kind of lowering would be done
and how much it would cost.
With multiple if-to-switch, don't we risk that we turn some ifs into switch,
then
switch-conversion lowers it back to ifs and then another if-to-switch matches
it again and again lowers it?

[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64

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

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

--- Comment #5 from Martin Liška  ---
(In reply to Jan Wassenberg from comment #4)
> Thanks for having a look! BTW forgot to mention: version 11.0 does not have
> this issue.

Can you please share pre-processed source from GCC 11? And can you verify that
taking it and using it with GCC 12 is stuck?

[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions

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

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

--- Comment #4 from Richard Biener  ---
IIRC switch conversion was run early originally because it was supposed to
improve inlining heuristics.  One might view if-to-switch + switch-conversion
as canonicalization which would mean running it before things like jump
threading or loop opts (most don't like switches at least).  Then one might
view if-to-switch + switch-conversion as (target specific) code generation
optimization (for that we also have pass_lower_switch, so one thing would
be re-running if-to-switch before that again, supposed pass_lower_switch
also performs the transforms switch-conversion does).

I usually don't like running things again and again.

[Bug rtl-optimization/106041] [12/13 Regression] infinite loop in fast_dce at -O1 with aarch64

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

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

Richard Biener  changed:

   What|Removed |Added

Version|12.0|12.1.0
   Target Milestone|--- |12.2
Summary|infinite loop in fast_dce   |[12/13 Regression] infinite
   |at -O1 with aarch64 |loop in fast_dce at -O1
   ||with aarch64

[Bug c/106043] New: Power10: lacking vec_blendv builtins

[jens.seifert at de dot ibm.com via Gcc-bugs]

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

Bug ID: 106043
   Summary: Power10: lacking vec_blendv builtins
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

Missing builtins for vector instructions xxblendvb, xxblendvw, xxblendvd,
xxblendvd.


#include 

vector int blendv(vector int a, vector int b, vector int c)
{
return vec_blendv(a, b, c);
}

[Bug target/106038] x86_64 vectorization of ALU ops using xmm registers prematurely

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Last reconfirmed||2022-06-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||rguenth at gcc dot gnu.org
 Blocks||53947
 Target||x86_64-*-*

--- Comment #4 from Richard Biener  ---
The vectorizer does not anticipate store-merging performing "vectorization" in
GPRs and thus the scalar cost is off (it also doesn't anticipate the different
ISA constraints wrt xmm vs gpr usage).

I wonder if we should try to follow what store-merging would do with respect
to "vector types", thus prefer "general vectors" (but explicitely via integer
types since we can't have vector types with both integer and vector modes)
when possible (for bit operations and plain copies).

scanning over an SLP instance (group) and substituting integer types for
SLP_TREE_VECTYPE might be possible.  Doing this nicely somewhere is going to
be more interesting.  Far away vectorizable_* should compute a set of
{ vector-type, cost } pairs from the set of input operand vector-type[, cost]
pair sets.  Not having "generic" vectors as vector types and relying on
vector lowering to expand them would be an incremental support step for this
I guess.

"backwards STV" could of course also work on the target side.


Referenced Bugs:

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

[Bug c++/105864] storing nullptr_t to memory should not generate any instructions

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Ivan Sorokin from comment #5)
> I would suggest (In reply to Andrew Pinski from comment #4)
> >   nullptr_t t, t1 = nullptr;
> >   __builtin_memcpy(&a[0], &t, sizeof(t));
> 
> > So I suspect this should be marked as invalid.
> 
> The questions is how GCC defines memcpy'ing from nullptr_t.
> 
> Should it be required to read zero bytes? Or null pointer value? What about
> systems where the value of null pointer is not zero?
> 
> In any case I don't think memcpy'ing nullptr_t into a different type is
> particularly useful or used anywhere (I might be wrong). So I suggest
> defining nullptr_t as an empty type containing only padding bytes. In this
> case memcpy should just read the padding bytes.

But the padding bits needs to be zero then 

[Bug c++/105864] storing nullptr_t to memory should not generate any instructions

[vanyacpp at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Ivan Sorokin  ---
I would suggest (In reply to Andrew Pinski from comment #4)
>   nullptr_t t, t1 = nullptr;
>   __builtin_memcpy(&a[0], &t, sizeof(t));

> So I suspect this should be marked as invalid.

The questions is how GCC defines memcpy'ing from nullptr_t.

Should it be required to read zero bytes? Or null pointer value? What about
systems where the value of null pointer is not zero?

In any case I don't think memcpy'ing nullptr_t into a different type is
particularly useful or used anywhere (I might be wrong). So I suggest defining
nullptr_t as an empty type containing only padding bytes. In this case memcpy
should just read the padding bytes.

[Bug tree-optimization/105736] [12/13 Regression] ICE in force_gimple_operand_1, at gimplify-me.cc:79 since r13-222-g28896b38fabce818

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Siddhesh Poyarekar
:

https://gcc.gnu.org/g:70454c50b4592fe6876ecca13268264e395e058f

commit r13-1183-g70454c50b4592fe6876ecca13268264e395e058f
Author: Siddhesh Poyarekar 
Date:   Tue Jun 21 12:15:07 2022 +0530

tree-object-size: Don't let error_mark_node escape for ADDR_EXPR [PR105736]

The addr_expr computation does not check for error_mark_node before
returning the size expression.  This used to work in the constant case
because the conversion to uhwi would end up causing it to return
size_unknown, but that won't work for the dynamic case.

Modify the control flow to explicitly return size_unknown if the offset
computation returns an error_mark_node.

gcc/ChangeLog:

PR tree-optimization/105736
* tree-object-size.cc (addr_object_size): Return size_unknown
when object offset computation returns an error.

gcc/testsuite/ChangeLog:

PR tree-optimization/105736
* gcc.dg/builtin-dynamic-object-size-0.c (TV4): New struct.
(val3): New variable.
(test_pr105736): New test.
(main): Call it.

Signed-off-by: Siddhesh Poyarekar 

[Bug tree-optimization/105740] missed optimization switch transformation for conditions with duplicate conditions

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

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

Martin Liška  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to luoxhu from comment #2)
> Run if_to_switch and convert_switch again after copyprop2 could remove the
> redundant statement and expose opportunity for if-to-switch again, is this
> reasonable or just move if-to-switch/switch-conversion later run only once?  

Dunno. There was a discussion about the pass placement in the original thread.
Richi, Jakub: What do you think about it?

[Bug gcov-profile/106036] Missing stdint.h include in libgcc/libgcov.h

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2022-06-21
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Well, where exactly do you see an error? In the building of libgcc?

[Bug rtl-optimization/106041] infinite loop in fast_dce at -O1 with aarch64

[jan.wassenberg at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Jan Wassenberg  ---
Thanks for having a look! BTW forgot to mention: version 11.0 does not have
this issue.