[Bug c++/79592] incomplete diagnostic "is not usable as a constexpr function because:"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 10.

[Bug c++/66139] destructor not called for members of partially constructed anonymous struct/array

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/5458] address of overloaded template function as argument for template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
  Known to fail|4.2.0   |

--- Comment #18 from Jason Merrill  ---
The compiler is following the standard.  C++11 and up say,

When P is a function type, pointer to function type, or pointer to member
function type:
— If the argument is an overload set containing one or more function templates,
the parameter is treated as a non-deduced context.
— If the argument is an overload set (not containing function templates), trial
argument deduction is attempted using each of the members of the set. If
deduction succeeds for only one of the overload set members, that member is
used as the argument value for the deduction. If deduction succeeds for more
than one member of the overload set the parameter is treated as a non-deduced
context.

So indeed, adding a function template to the overload set means no deduction is
done, according to the first bullet.

[Bug other/16996] [meta-bug] code size improvements

[jason at gcc dot gnu.org]

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

Bug 3187 Summary: gcc lays down two copies of constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187

   What|Removed |Added

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

[Bug c++/3187] gcc lays down two copies of constructors

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #43 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #41)
> what we could do (perhaps as an option) is
> to emit another function, which would take an argument what kind of ctor
> resp. dtor it is, and
> behave differently depending on that argument, then have both kinds of ctor
> resp. dtor to tail call (or if not possible, just call) the other function.
> I guess it could have ABI consequences though (in which comdat section to
> place it).

This was implemented for bug 41090; -fdeclone-ctor-dtor defaults to on with
-Os, off otherwise.  So, fixed in 4.9.

[Bug c++/41090] [4.7/4.8/4.9 Regression] Using static label reference in c++ class constructor produces wrong code

[jason at gcc dot gnu.org]

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

Bug 3187 Summary: gcc lays down two copies of constructors
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3187

   What|Removed |Added

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

[Bug tree-optimization/92980] [miss optimization]redundant load missed by fre.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-18
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
I think the problem is we are folding the right side of the array (with the
conversion to size_t) too early.
That is:
src1[j-1]

Is being folded too early to have (j-1)*4

Fixing this up in match.pd is wrong.

This gets us the best code without any patch to match.pd:
int foo(unsigned int *__restrict src1, int i, int k, int n)
{
  int j = k + n;
  int sum = src1[j];
  int jj = j-1;
  sum += src1[jj];
  if (i <= k)
{
  j+=2;
int ii = j-3;
  sum += src1[ii];
}
  return sum + j;
}

See how j-1 and j-3 are not folded early and that fixes the issue.

[Bug ipa/92981] New: [10 Regression] ICE in get_partitioning_class, at symtab.c:1966

[asolokha at gmx dot com]

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

Bug ID: 92981
   Summary: [10 Regression] ICE in get_partitioning_class, at
symtab.c:1966
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

g++-10.0.0-alpha20191215 snapshot (r279405) ICEs when compiling the following
testcase w/ -flto:

static union {
  int yz;
};

struct ra {
  static int 
};

int ::dy = static_cast (yz);

bool
bm ()
{
  return ra::dy == yz;
}

% g++-10.0.0-alpha20191215 -flto -c eum4ktwa.cc
during IPA pass: fnsummary
eum4ktwa.cc:15:1: internal compiler error: in get_partitioning_class, at
symtab.c:1966
   15 | }
  | ^
0x69c5ac symtab_node::get_partitioning_class()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/symtab.c:1966
0xddfd55 lto_output_varpool_node
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/lto-cgraph.c:619
0xddfd55 output_symtab()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/lto-cgraph.c:981
0xded3c9 lto_output()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/lto-streamer-out.c:2547
0xe75d02 write_lto
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/passes.c:2612
0xe75d02 ipa_write_summaries_1
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/passes.c:2676
0xe75d02 ipa_write_summaries()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/passes.c:2731
0xb23ea2 ipa_passes
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/cgraphunit.c:2652
0xb23ea2 symbol_table::compile()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/cgraphunit.c:2739
0xb25a7b symbol_table::compile()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/cgraphunit.c:2719
0xb25a7b symbol_table::finalize_compilation_unit()
   
/var/tmp/portage/sys-devel/gcc-10.0.0_alpha20191215/work/gcc-10-20191215/gcc/cgraphunit.c:2986

[Bug tree-optimization/92980] [miss optimization]redundant load missed by fre.

[crazylht at gmail dot com]

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

--- Comment #1 from Hongtao.liu  ---
test.c.033.fre1
foo (unsigned int * restrict src1, int i, int k, int n)
{
  int sum;
  int j;
  long unsigned int _1;
  long unsigned int _2;
  unsigned int * _3;
  unsigned int _4;
  sizetype _7;
  unsigned int * _8;
  unsigned int _9;
  unsigned int _11;
  long unsigned int _12;
  long unsigned int _13;
  sizetype _14;
  unsigned int * _15;
  unsigned int _16;
  unsigned int _18;
  int _31;

   :
  j_23 = k_21(D) + n_22(D);
  _1 = (long unsigned int) j_23;
  _2 = _1 * 4;
  _3 = src1_24(D) + _2;
  _4 = *_3;
  sum_26 = (int) _4;
  _7 = _2 + 18446744073709551612;
  _8 = src1_24(D) + _7;
  _9 = *_8;
  _11 = _4 + _9;
  sum_27 = (int) _11;
  if (k_21(D) >= i_28(D))
goto ; [INV]
  else
goto ; [INV]

   :
  j_29 = j_23 + 2;
  _12 = (long unsigned int) j_29;
  _13 = _12 * 4;
  _14 = _13 + 18446744073709551604; --- it shoule be simplified to _7
  _15 = src1_24(D) + _14;
  _16 = *_15;
  _18 = _11 + _16;
  sum_30 = (int) _18;

   :
  # j_19 = PHI 
  # sum_20 = PHI 
  _31 = j_19 + sum_20;
  return _31;
}

[Bug tree-optimization/92980] New: [miss optimization]redundant load missed by fre.

[crazylht at gmail dot com]

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

Bug ID: 92980
   Summary: [miss optimization]redundant load missed by fre.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

cat test.c

int foo(unsigned int *__restrict src1, int i, int k, int n)
{
  int j = k + n;
  int sum = src1[j];
  sum += src1[j-1];
  if (i <= k)
{
  j+=2;
  sum += src1[j-3];
}
  return sum + j;
}


x86_64_gcctrunk -Ofast test.c -S
got 

foo:
.LFB0:
.cfi_startproc
addl%edx, %ecx
movl%esi, %r8d
movslq  %ecx, %rsi
movl(%rdi,%rsi,4), %eax
addl-4(%rdi,%rsi,4), %eax
cmpl%r8d, %edx
jl  .L3
addl$2, %ecx
movslq  %ecx, %rdx
addl-12(%rdi,%rdx,4), %eax    redudant load, it's actual a[j-1]
which is loaded before.
.L3:
addl%ecx, %eax
ret
.cfi_endproc
.LFE0:
.size   foo, .-foo
.ident  "GCC: (GNU) 10.0.0 20191117 (experimental)"
.section.note.GNU-stack,"",@progbits

it could be better like

foo:
.LFB0:
.cfi_startproc
addl%edx, %ecx
movl%esi, %r9d
movslq  %ecx, %rsi
movl-4(%rdi,%rsi,4), %r8d
movl(%rdi,%rsi,4), %eax
addl%r8d, %eax
cmpl%r9d, %edx
jl  .L3
addl$2, %ecx
addl%r8d, %eax > reuse earlir load result.
.L3:
addl%ecx, %eax
ret
.cfi_endproc

[Bug c++/61339] add mismatch between struct and class [-Wmismatched-tags] to non-bugs

[msebor at gcc dot gnu.org]

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

--- Comment #16 from Martin Sebor  ---
Author: msebor
Date: Tue Dec 17 23:53:07 2019
New Revision: 279480

URL: https://gcc.gnu.org/viewcvs?rev=279480=gcc=rev
Log:
PR c++/61339 - add warning for mismatch between struct and class

gcc/c-family/ChangeLog:

PR c++/61339
* c.opt (-Wmismatched-tags, -Wredundant-tags): New options.

gcc/cp/ChangeLog:

PR c++/61339
* parser.c (cp_parser_maybe_warn_enum_key): New function.
(class_decl_loc_t): New class.
(cp_parser_elaborated_type_specifier): Call
cp_parser_maybe_warn_enum_key.
(cp_parser_class_head): Call cp_parser_check_class_key.
(cp_parser_check_class_key): Add arguments.  Call
class_decl_loc_t::add.
(c_parse_file): Call class_decl_loc_t::diag_mismatched_tags.

gcc/testsuite/ChangeLog:

PR c++/61339
* g++.dg/warn/Wmismatched-tags.C: New test.
* g++.dg/warn/Wredundant-tags.C: New test.
* g++.dg/pch/Wmismatched-tags.C: New test.
* g++.dg/pch/Wmismatched-tags.Hs: New test header.

gcc/ChangeLog:

PR c++/61339
* doc/invoke.texi (-Wmismatched-tags, -Wredundant-tags): Document
new C++ options.


Added:
trunk/gcc/testsuite/g++.dg/pch/Wmismatched-tags.C
trunk/gcc/testsuite/g++.dg/pch/Wmismatched-tags.Hs
trunk/gcc/testsuite/g++.dg/warn/Wmismatched-tags.C
trunk/gcc/testsuite/g++.dg/warn/Wredundant-tags.C
Modified:
trunk/gcc/ChangeLog
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c.opt
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c
trunk/gcc/doc/invoke.texi
trunk/gcc/testsuite/ChangeLog

[Bug c++/61339] add mismatch between struct and class [-Wmismatched-tags]

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0
Summary|add mismatch between struct |add mismatch between struct
   |and class   |and class
   |[-Wmismatched-tags] to  |[-Wmismatched-tags]
   |non-bugs|

--- Comment #17 from Martin Sebor  ---
Patch committed in r279480.

[Bug fortran/92977] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3526

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||openmp
   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-17
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed when compiling with optimization.

Actually, you can compile with optimization, but need to disable
front-end optimization (-fno-frontend-optimize).

[Bug fortran/92976] [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-12-17
Summary|[8/9/10 Regression] ICE in  |[8/9/10 Regression][OOP]
   |trans_associate_var, at |ICE in trans_associate_var,
   |fortran/trans-stmt.c:1963   |at
   ||fortran/trans-stmt.c:1963
 Ever confirmed|0   |1
  Known to fail||10.0, 7.4.1, 8.3.1, 9.2.1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[msebor at gcc dot gnu.org]

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

--- Comment #16 from Martin Sebor  ---
The warning doesn't affect code generation.  It's issued independent of it. 
We'll have to agree to disagree about the validity of the test case in comment
#0, but I do agree that at least some of your test cases unfortunately are
valid in C (although I don't think they're also valid in C++ where only the
union member that was last written to can be read).  I'll look into this when
I'm back from PTO in January.

[Bug c++/79592] incomplete diagnostic "is not usable as a constexpr function because:"

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Dec 17 21:46:40 2019
New Revision: 279473

URL: https://gcc.gnu.org/viewcvs?rev=279473=gcc=rev
Log:
PR c++/79592 - missing explanation of invalid constexpr.

We changed months back to use the pre-generic form for constexpr evaluation,
but explain_invalid_constexpr_fn was still using DECL_SAVED_TREE.  This
mostly works, but misses some issues due to folding.  So with this patch we
save the pre-generic form of constexpr functions even when we know they
can't produce a constant result.

* constexpr.c (register_constexpr_fundef): Do store the body of a
template instantiation that is not potentially constant.
(explain_invalid_constexpr_fn): Look it up.
(cxx_eval_call_expression): Check fundef->result.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c

[Bug c++/92576] Definition of variable template without initializer is treated as declaration

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Dec 17 21:46:11 2019
New Revision: 279472

URL: https://gcc.gnu.org/viewcvs?rev=279472=gcc=rev
Log:
PR c++/92576 - redeclaration of variable template.

The variable templates patch way back when forgot to add handling here.  The
simplest answer seems to be recursing to the underlying declaration.

* decl.c (redeclaration_error_message): Recurse for variable
templates.

Added:
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ65.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl.c
trunk/gcc/testsuite/g++.dg/cpp1y/var-templ32.C

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[manu at gcc dot gnu.org]

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

--- Comment #35 from Manuel López-Ibáñez  ---
In any case, looking at the uninit dump with -fdump-tree-all-all-lineno it
appears that GCC knows the block where the warning is triggered is never
executed:

;;   basic block 13, loop depth 0, count 0 (precise), probably never executed
;;prev block 12, next block 14, flags: (NEW, REACHABLE, VISITED)
;;pred:   12 [never]  count:0 (precise) (EH,EXECUTABLE)
;;   starting at line -1
: [LP 2]
  # DEBUG c1$16$iD.2602 => c1$16$i_9
  # DEBUG c1D.2601 => 1
  # DEBUG thisD.2599 => 
  [./example.cpp:20:23] # DEBUG D#2ptD.0 => [./example.cpp:20:23]
&[./example.cpp:20:18] [./example.cpp:20:18] c1D.2412.D.2424.tD.2426
  [./example.cpp:20:23] # DEBUG thisD.2600 => D#2ptD.0
  [./example.cpp:9:11] # DEBUG BEGIN_STMT
  [./example.cpp:9:13] # .MEM_27 = VDEF <.MEM_15>
  xD.2332 = c1$16$i_9;
  [./example.cpp:9:18] goto ; [0.00%]
;;succ:   15 [never]  count:0 (precise) (FALLTHRU,EXECUTABLE)

I remember seeing other bugs where the block info could be used to avoid
warning.

[Bug tree-optimization/92949] bswap/store merging does not handle BIT_INSERT_EXPR/BIT_FIELD_REF

[pinskia at gcc dot gnu.org]

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

--- Comment #7 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #5)
> Note bswap pass is very fragile.  In fact if we increase the limit by 1,
> things dont work any more.  There needs to be a better way of handling this.

PR 92979 is for that issue.  I was able to find a testcase without the
bit-field lowering.

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[manu at gcc dot gnu.org]

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

--- Comment #34 from Manuel López-Ibáñez  ---
(In reply to Martin Sebor from comment #15)
> I think the following smaller test case independent of libstdc++ captures
> the same issue as the bigger test case in comment #4.  Again, declaring f()
> noexcept avoids the warning (but it's not a solution in general).  Zero
> initializing A::i first and then setting it to the result of f() also avoids
> the warning and seems like more viable solution/workaround until GCC gets
> smarter about exceptions.


In this example, if you add a useless pointer to t, then GCC doesn't warn:

template 
struct C {
  C (): b(), t()  { }
  ~C () { if (b) t.~T (); }

  void f () {
b = true;
new () T ();
pt = 
  }
private:
  bool b;
  T * pt;
public:
  union {
T t;
char x[sizeof (T)];
  };
 };

[Bug c++/59655] incorrect diagnostic on templatized function with lambda parameter

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 17 21:40:14 2019
New Revision: 279470

URL: https://gcc.gnu.org/viewcvs?rev=279470=gcc=rev
Log:
PR c++/59655
* pt.c (push_tinst_level_loc): If limit_bad_template_recursion,
set TREE_NO_WARNING on tldcl.
* decl2.c (no_linkage_error): Treat templates with TREE_NO_WARNING
as defined during error recovery.

* g++.dg/cpp0x/diag3.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp0x/diag3.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/decl2.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/12333] [DR 272] Explicit call to MyClass::~MyClass() not allowed

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning

[msebor at gcc dot gnu.org]

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

--- Comment #14 from Martin Sebor  ---
(In reply to Tobias Burnus from comment #12)

The warnings have been enabled by default since _FORTIFY_SOURCE (and Builtin
Size Checking) was introduced.  Given their severity I don't think we want
consider changing the default setting.  Splitting up the warning into two
wouldn't be a good solution, or even a good workaround, because there's no
obvious difference between the source code that is prone to the false positives
and code that isn't (as far as users can tell, the code looks the same).

LTO is a problem in the sense that it enables a C-only warning for FORTRAN
code.  But a similar problem also affects C if the warning is disabled via
#pragma GCC diagnostic (see below).  Incidentally, the converse problem (false
negatives) affects -Warray-bounds: out-of-bounds indices aren't diagnosed even
when explicitly requested (to see that, replace char with int below).

We need to come up with a solution to avoid diagnosing code that's synthesized
by GCC itself (without introducing false negatives), and we need to get the
warning suppression working reliably.  With and without LTO.  I'm planning to
look into the #pragma problem in January but I'm not sure coming up with a
solution for the the other problem is feasible in GCC 10.

$ cat a.c && gcc -O2 -flto -c -o a1.o a.c && gcc -DMAIN -O2 -flto -c -o a2.o
a.c && gcc -O2 -flto a1.o a2.o -o a.out
#pragma GCC diagnostic ignored "-Wstringop-overflow"

typedef char T;

#if MAIN

T i;

void f (T*);

int main (void)
{
  f ();
  return i;
}

#else

void f (T *p)
{
  p[3] = 0;
}

#endif
In function ‘f’,
inlined from ‘main’ at a.c:13:3:
a.c:21:8: warning: writing 1 byte into a region of size 0
[-Wstringop-overflow=]
   21 |   p[3] = 0;
  |^
a.c: In function ‘main’:
a.c:7:3: note: at offset 3 to object ‘i’ with size 1 declared here
7 | T i;
  |   ^

[Bug tree-optimization/92949] bswap/store merging does not handle BIT_INSERT_EXPR/BIT_FIELD_REF

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||92979

--- Comment #6 from Andrew Pinski  ---
PR 92979 shows the problem I am running into with respect to the bswap pass not
handling loads or otherwise correctly.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92979
[Bug 92979] bswap not finding a bswap with a memory load at the beginging of
the instruction stream

[Bug tree-optimization/92979] New: bswap not finding a bswap with a memory load at the beginging of the instruction stream

[pinskia at gcc dot gnu.org]

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

Bug ID: 92979
   Summary: bswap not finding a bswap with a memory load at the
beginging of the instruction stream
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-linux-gnu

Take these two functions:
unsigned g(unsigned *a)
{
  unsigned M0 = *a & 0xff;
  unsigned M1 = (*a>>8) & 0xff;
  unsigned M2 = (*a>>16) & 0xff;
  unsigned M3 = (*a>>24) & 0xff;
  unsigned t = 0;
  t |= M0;
  t <<= 8;
  t |= M1;
  t <<= 8;
  t |= M2;
  t <<= 8;
  t |= M3;
  return t;
}
unsigned g1(unsigned a)
{
  unsigned M0 = a & 0xff;
  unsigned M1 = (a>>8) & 0xff;
  unsigned M2 = (a>>16) & 0xff;
  unsigned M3 = (a>>24) & 0xff;
  unsigned t = 0;
  t |= M0;
  t <<= 8;
  t |= M1;
  t <<= 8;
  t |= M2;
  t <<= 8;
  t |= M3;
  return t;
}
- CUT ---

Only g1 is detected as bswap while g is not.  The problem is the way bswap is
too "agressive" in looking through the instruction stream to find loads.

I found this while implementing lowering of bit-fields.

[Bug c++/92236] [concepts] Explain non-satisfaction in static_assert

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #8 from Jason Merrill  ---
Fixed for GCC 10.

[Bug c++/67491] [meta-bug] concepts issues

[jason at gcc dot gnu.org]

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

Bug 92236 Summary: [concepts] Explain non-satisfaction in static_assert
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92236

   What|Removed |Added

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

[Bug c++/79592] incomplete diagnostic "is not usable as a constexpr function because:"

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning

[msebor at gcc dot gnu.org]

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

--- Comment #13 from Martin Sebor  ---
(In reply to Jakub Jelinek from comment #9)

Thanks for the nice test case!  The assumptions the warning makes aren't
accidental: it tries to detect bugs that would otherwise go undetected, and it
relies on the fact that the IL, although ambiguous (as in: matching both valid
code injected by GCC itself, as well as accidental bugs introduced by careless
programmers), corresponds to the source code more often than not.  It's a
trade-off between false negatives and false positives, with the balance
shifting each time a new transformation is added that breaks the assumption. 
The only way to do better is to make the IL reflect the distinction between the
two classes of uses).

The GIMPLE in the test case in comment #10 that causes the warning is this:

  p_2(D)->l = l_3(D);
  vectp.5_21 = _2(D)->t.a;
  MEM  [(char *)vectp.5_21] = { 2, 3, 4, 5, 6, 7, 8, 9 };

and the warning sees that vectp.5_21 is just a pointer to p->t.a.  If, for
example, the IL instead looked like this:

  p_2(D)->l = l_3(D);
  MEM[(Vec8 *)p_2(D) + 8B] = { 2, 3, 4, 5, 6, 7, 8, 9 };
  vectp.10_14 = _2(D)->t.i;

the warning (as it is today) wouldn't trigger (Vec8 is a typedef for
__attribute__ ((vector_size (8))) char) because it doesn't know how to convert
offsets into structs into members (but that's just a limitation that I hope to
remove).  But even this IL is still ambiguous because it corresponds to this
assignment:

  *((Vec8*)>t.a) = (Vec8){ 2, 3, 4, 5, 6, 7, 8, 9 };

Here the overflow is intended to be detected but won't be.  Worse, a trivial
change to the code like so results in the former IL, bringing the warning back:

  *((__attribute__ ((vector_size (8))) char*)>t.a) = (__attribute__
((vector_size (8))) char){ 2, 3, 4, 5, 6, 7, 8, 9 };

To avoid this problem we just need to "encode" the cast in the MEM_REF
destination argument (or maybe the type of the offset) used by optimizers in a
way that doesn't correspond to a valid source code construct.  Or, more
generally, just use some unused bit in the MEM_REF representation to
distinguish the two cases.  I'm not an expert on GIMPLE so I don't have a good
sense of what would work or work best, but if the idea is sound I'll try to
look into it for GCC 11.

[Bug c++/68012] g++ incorrectly accepts forward declaration of constexpr variable template

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
This seems like an ill-formed, no diagnostic required situation because no
valid specialization can be generated; if you try to instantiate the template,
G++ complains then.  I agree that giving a diagnostic would be better, but the
conformance issue is that G++ allows you to redefine it (PR 92576).

[Bug target/92841] Optimize -fstack-protector-strong code generation a bit

[jakub at gcc dot gnu.org]

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

--- Comment #11 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 17 20:40:01 2019
New Revision: 279468

URL: https://gcc.gnu.org/viewcvs?rev=279468=gcc=rev
Log:
PR target/92841
* config/i386/i386.md (@stack_protect_set_1_,
@stack_protect_test_1_): Use output_asm_insn.
(*stack_protect_set_2_, *stack_protect_set_3): New define_insns
and corresponding define_peephole2s.

* gcc.target/i386/pr92841.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/pr92841.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.md
trunk/gcc/testsuite/ChangeLog

[Bug c++/92576] Definition of variable template without initializer is treated as declaration

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/84255] accepts redefinition of template variable

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/92560] ICE using decltype(x < y) when that operator uses operator<=>

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/57082] brace initialization requires public destructor

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||10.0, 9.2.1
  Known to fail|10.0|

--- Comment #8 from Jason Merrill  ---
Fixed for 9.3/10.  Does anyone think it's important to fix this in 8.4?

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[jason at gcc dot gnu.org]

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

--- Comment #33 from Jason Merrill  ---
(In reply to Pedro Alves from comment #32)
> Usually maybe-uninit warnings point to false positives involving scalars,
> and initializing them is practically free.  But here the size of T may be
> significant, which could lead to e.g., calling memset in loops.

Using optional with a large T sounds like a strange choice to me, since it
means you have to allocate the space even if you don't have a value.

[Bug rtl-optimization/90040] [meta-bug] modulo-scheduler and partitioning issues

[zhroma at gcc dot gnu.org]

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

Roman Zhuykov  changed:

   What|Removed |Added

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

--- Comment #1 from Roman Zhuykov  ---
I want to ping this meta-bug and kindly ask Jakub/Honza to look at it.  I've
just rechecked that ICE described in bug 85426 comment 4 presents on current
trunk.  While PR89116 example "unfortunately" shows no ICE at the moment.

Issue is still the same - we ask cfg_layout_redirect_edge_and_branch_force to
redirect a crossing jump.

With my local (still WIP) modulo-sched features, SMS pass can be used on x86,
where -freorder-blocks-and-partition is enabled by default.  So, this assertion
failure becomes much more annoying, even bootstrap failed on it in some
specific conditions.

[Bug libstdc++/92978] New: std::gcd mishandles mixed-signedness

[rs2740 at gmail dot com]

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

Bug ID: 92978
   Summary: std::gcd mishandles mixed-signedness
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rs2740 at gmail dot com
  Target Milestone: ---

From https://stackoverflow.com/q/59379703/2756719; the current gcd
implementation is essentially

  template
constexpr common_type_t<_Mn, _Nn>
__gcd(_Mn __m, _Nn __n)
{
  return __m == 0 ? __detail::__abs_integral(__n)
: __n == 0 ? __detail::__abs_integral(__m)
: __detail::__gcd(__n, __m % __n);
}

__m % __n generally does the wrong thing if one of the operands is negative and
signed and the other operand is unsigned. E.g., -120 % 10u is 6u, rather than
zero.

[Bug rtl-optimization/92591] ICE in optimize_sc, at modulo-sched.c:1063

[zhroma at gcc dot gnu.org]

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

--- Comment #9 from Roman Zhuykov  ---
Started discussion in mailing list:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01223.html

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #32 from Pedro Alves  ---
Right, the potentially-sensitive aspect is what I mean to stress here.  Usually
maybe-uninit warnings point to false positives involving scalars, and
initializing them is practically free.  But here the size of T may be
significant, which could lead to e.g., calling memset in loops.

[Bug c++/92774] ICE with defaulted three-way comparison function

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #2 from Jason Merrill  ---
Fixed.

[Bug c++/91165] [10 Regression] error: location references block not in block tree

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #9 from Jason Merrill  ---
Fixed.

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[jason at gcc dot gnu.org]

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

--- Comment #31 from Jason Merrill  ---
(In reply to Pedro Alves from comment #30)
> I assume so, but do we really want to zero-initialize the buffer?  T might
> be large, and I'd think that pessimization to quiet a warning isn't the
> right way to go?

The usual way to quiet a maybe-uninit warning is to add redundant
initialization; this doesn't seem that different, apart from it being in a
library that could potentially be used in performance-sensitive code.

[Bug fortran/92977] New: ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3526

[gs...@t-online.de]

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

Bug ID: 92977
   Summary: ICE in gfc_trans_omp_atomic, at
fortran/trans-openmp.c:3526
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

In addition to pr92899, down to at least gcc-5 :


$ cat z1.f90
program p
   integer :: n = 1
   integer :: a
!$omp atomic write
   a = f(n) - f(n)
contains
   integer function f(x)
  integer, intent(in) :: x
  f = x
   end
end


$ gfortran-10-20191215 -c z1.f90 -O2 -fopenmp
z1.f90:4:0:

4 | !$omp atomic write
  |
internal compiler error: in gfc_trans_omp_atomic, at
fortran/trans-openmp.c:3526
0x78bcf5 gfc_trans_omp_atomic
../../gcc/fortran/trans-openmp.c:3526
0x79b71f gfc_trans_omp_directive(gfc_code*)
../../gcc/fortran/trans-openmp.c:5510
0x70b1d7 trans_code
../../gcc/fortran/trans.c:2139
0x7424cd gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6bc426 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6bc426 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x70742f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/92976] New: [8/9/10 Regression] ICE in trans_associate_var, at fortran/trans-stmt.c:1963

[gs...@t-online.de]

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

Bug ID: 92976
   Summary: [8/9/10 Regression] ICE in trans_associate_var, at
fortran/trans-stmt.c:1963
   Product: gcc
   Version: 10.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 gfortran-6 :


$ cat z1.f90
program p
   type t
   end type
contains
   subroutine s(x)
  class(t) :: x(2)
  select type (x)
  type is (t)
  end select
   end
end


$ cat z2.f90
program p
   type t
   end type
contains
   subroutine s(x)
  class(*) :: x(2)
  select type (x)
  type is (t)
  end select
   end
end


$ gfortran-5 -c z1.f90
$
$ gfortran-10-20191215 -c z1.f90
z1.f90:1:0:

1 | program p
  |
internal compiler error: in trans_associate_var, at fortran/trans-stmt.c:1963
0x744404 trans_associate_var
../../gcc/fortran/trans-stmt.c:1963
0x74a221 gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2283
0x6d6d37 trans_code
../../gcc/fortran/trans.c:1960
0x74b6be gfc_trans_select_type_cases
../../gcc/fortran/trans-stmt.c:2913
0x74b6be gfc_trans_select_type(gfc_code*)
../../gcc/fortran/trans-stmt.c:3622
0x6d6dc7 trans_code
../../gcc/fortran/trans.c:1980
0x74a1af gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.c:2276
0x6d6d37 trans_code
../../gcc/fortran/trans.c:1960
0x700124 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6801
0x6fff24 gfc_generate_contained_functions
../../gcc/fortran/trans-decl.c:5796
0x6fff24 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6733
0x6891b6 translate_all_program_units
../../gcc/fortran/parse.c:6302
0x6891b6 gfc_parse_file()
../../gcc/fortran/parse.c:6541
0x6d365f gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/92975] ICE in convert_nonlocal_reference_op, in tree-nested.c:1065

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from G. Steinmetz  ---

Without such a block :


$ cat z2.f90
program p
   procedure(s), pointer :: g
   g => s
   call g
   call s
contains
   subroutine s
  print *, 's'
   end
end


$ cat z4.f90
program p
   procedure(s), pointer :: g
   g => s
   print *, g()
   print *, s()
contains
   function s() result(n)
  n = 1
   end
end


$ gfortran-10-20191215 z2.f90 && ./a.out
 s
 s

$ gfortran-10-20191215 z4.f90 && ./a.out
   1
   1

[Bug fortran/92975] New: ICE in convert_nonlocal_reference_op, in tree-nested.c:1065

[gs...@t-online.de]

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

Bug ID: 92975
   Summary: ICE in convert_nonlocal_reference_op, in
tree-nested.c:1065
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

In addition to pr92781, some examples with a procedure pointer 
embedded in a block. ICEs down to at least gfortran-5 :


$ cat z1.f90
program p
   block
  procedure(s), pointer :: g
  g => s
  call g
  call s
   end block
contains
   subroutine s
  print *, 's'
   end
end


$ cat z3.f90
program p
   block
  procedure(s), pointer :: g
  g => s
  print *, g()
  print *, s()
   end block
contains
   function s() result(n)
  n = 1
   end
end


$ gfortran-10-20191215 -c z1.f90
z1.f90:1:0:

1 | program p
  |
internal compiler error: Segmentation fault
0xb8147f crash_signal
../../gcc/toplev.c:328
0xc0cce3 convert_nonlocal_reference_op
../../gcc/tree-nested.c:1065
0xde2d35 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*,
tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
void*, hash_set >*))
../../gcc/tree.c:11954
0x91e3dd walk_gimple_op(gimple*, tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:221
0x91e5f8 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:596
0x91e7a0 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0x91e681 walk_gimple_stmt(gimple_stmt_iterator*, tree_node*
(*)(gimple_stmt_iterator*, bool*, walk_stmt_info*), tree_node* (*)(tree_node**,
int*, void*), walk_stmt_info*)
../../gcc/gimple-walk.c:605
0x91e7a0 walk_gimple_seq_mod(gimple**, tree_node* (*)(gimple_stmt_iterator*,
bool*, walk_stmt_info*), tree_node* (*)(tree_node**, int*, void*),
walk_stmt_info*)
../../gcc/gimple-walk.c:51
0xc09a48 walk_body
../../gcc/tree-nested.c:713
0xc0a248 walk_function
../../gcc/tree-nested.c:724
0xc0a248 walk_all_functions
../../gcc/tree-nested.c:789
0xc0defd lower_nested_functions(tree_node*)
../../gcc/tree-nested.c:3528
0x7d47f4 cgraph_node::analyze()
../../gcc/cgraphunit.c:675
0x7d7457 analyze_functions
../../gcc/cgraphunit.c:1212
0x7d7db2 symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2958

[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types

[gs...@t-online.de]

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

--- Comment #6 from G. Steinmetz  ---

Compiles these slightly modified cases :


$ cat z2.f90  # no allocatable a
program p
   type t
  integer :: a
   end type
   type t2
  type(t) :: b
   end type
   type t3
  type(t2) :: c
   end type
contains
   function g(x)
  class(t2) :: x
  type(t) :: g(2)
   end
   function f(x)
  class(t3) :: x
  type(t) :: f(2)
  f = g(x%c)
   end
end


$ cat z3.f90  # scalar functions g, f
program p
   type t
  integer, allocatable :: a
   end type
   type t2
  type(t) :: b
   end type
   type t3
  type(t2) :: c
   end type
contains
   function g(x)
  class(t2) :: x
  type(t) :: g
   end
   function f(x)
  class(t3) :: x
  type(t) :: f
  f = g(x%c)
   end
end

[Bug fortran/92586] ICE in gimplify_expr, at gimplify.c:13479 with nested allocatable derived types

[gs...@t-online.de]

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

G. Steinmetz  changed:

   What|Removed |Added

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

--- Comment #5 from G. Steinmetz  ---

A simplification might be :


$ cat z1.f90
program p
   type t
  integer, allocatable :: a
   end type
   type t2
  type(t) :: b
   end type
   type t3
  type(t2) :: c
   end type
contains
   function g(x)
  class(t2) :: x
  type(t) :: g(2)
   end
   function f(x)
  class(t3) :: x
  type(t) :: f(2)
  f = g(x%c)
   end
end


$ gfortran-10-20191215 -c z1.f90
gimplification failed:
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f89646ad7e0 fields 
pointer_to_this  chain >
unsigned DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f89646adc78
pointer_to_this >

arg:0 
addressable used ignored BLK z1.f90:19:0 size  unit-size 
align:64 warn_if_not_align:0 context 
chain 
used ignored DI z1.f90:19:0 size 
unit-size 
align:64 warn_if_not_align:0 context  chain >>
z1.f90:19:0 start: z1.f90:19:0 finish: z1.f90:19:0>
z1.f90:19:0:

   19 |   f = g(x%c)
  |
internal compiler error: gimplification failed
0xa14dd1 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:14379
0xa1ba3c gimplify_compound_lval
../../gcc/gimplify.c:3052
0xa125f5 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13320
0xa27b18 gimplify_modify_expr
../../gcc/gimplify.c:5769
0xa1489a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13368
0xa17b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6810
0xa139a3 gimplify_statement_list
../../gcc/gimplify.c:1857
0xa139a3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13812
0xa17b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6810
0xa1cee8 gimplify_cond_expr
../../gcc/gimplify.c:4228
0xa13d80 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13325
0xa17b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6810
0xa139a3 gimplify_statement_list
../../gcc/gimplify.c:1857
0xa139a3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13812
0xa17b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6810
0xa18c83 gimplify_bind_expr
../../gcc/gimplify.c:1420
0xa13bd2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13569
0xa17b18 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.c:6810
0xa139a3 gimplify_statement_list
../../gcc/gimplify.c:1857
0xa139a3 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.c:13812

[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning

[burnus at gcc dot gnu.org]

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

--- Comment #12 from Tobias Burnus  ---
(In reply to Martin Sebor from comment #11)
> Because like all flow-based warnings, -Wstringop-overflow has a non-zero rate
> of false positives

I think false positive is okay fine, but the question is whether the option
should then be enabled by default. – That's independent whether it is C, C++ or
Fortran. I think someone who use several -W… options is fine with false
positives, but those who use only default options should not see bogus results.

Or split this in two parts – one for those parts before the problematic GIMPLE
optimizations – enabled by default (at least for C/C++). And another option for
warnings after GIMPLE "messed up" which the user has to specify explicitly
(might also be implied by -Wextra or maybe even -Wall).

> LTO builds are known to have issues with interpreting command line options,

My feeling is that this more a problem of GIMPLE doing optimization that about
LTO and command-line options. — At least comment 11 and PR 92765 look like C
code to me.

> If this warning is useful even in FORTRAN despite the non-zero false
> positive rate […] the option can be made generic

I think it has some use – a bit more limited as it is not as easy as in C to
run into such string bugs, but it can detect some issues also in Fortran code.
– As in C but due to the limited benefit even more so: it as a whole – or at
least those parts after the GIMPLE optimization – should only be enabled by a
-W flag (might well be implied, e.g., by -Wextra).

[Bug fortran/92956] [10 Regression] 'libgomp.fortran/examples-4/async_target-2.f90' fails with offloading due to bogus -Wstringop-overflow warning

[msebor at gcc dot gnu.org]

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

--- Comment #11 from Martin Sebor  ---
Here's some history.  When -Wstringop-overflow was introduced it only detected
overflow in calls to C functions like strcpy or memcpy that aren't normally
seen in FORTRAN programs.  It provided a means of controlling warnings issued
by _FORTIFY_SOURCE for overflowing calls to string functions like strcpy.  But
_FORTIFY_SOURCE misses many buffer overflows and so the warning was enhanced to
detect some of those.  Because like all flow-based warnings,
-Wstringop-overflow has a non-zero rate of false positives, it was meant to be
enabled only for the languages where such calls were normally made directly.

It was only recently that the warning has also started detecting overflow by
assignments.  That was done partly because GCC itself transforms calls to
library functions like strcpy or memcpy to direct assignments via MEM_REF,
which previously prevented buffer overflows by those assignments from being
detected.

LTO builds are known to have issues with interpreting command line options,
including warnings (e.g., merging options used to compile different translation
units when functions defined in those units are inlined into one another).  I
don't know all the details here but I do know it's a topic of ongoing
discussion.  One solution/workaround I've heard suggested is specifying the
expected options when linking.

Does passing -Wno-stringop-overflow when linking (with LTO) suppress the
warnings?

If this warning is useful even in FORTRAN despite the non-zero false positive
rate, or maybe because of it with LTO, the option can be made generic so the
false positives can be suppressed using #pragma GCC diagnostic or on the
command line when compiling.  (I should mention that even #pragma GCC
diagnostic doesn't work completely reliably with optimization, and I have no
idea how or if it works with LTO.  It's something I'm yet to look into.)

[Bug c++/92974] New: diagnostic missing source information

[barry.revzin at gmail dot com]

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

Bug ID: 92974
   Summary: diagnostic missing source information
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Here's the best reduction I was able to come up with thanks to creduce:

# 1 "" 3
typedef unsigned char a;
typedef unsigned b;
enum {
  c
};
class d { 
public:
  template  int f(e const &, a const *, b); 
};
template  d::f(e const &, a const *, b) { b g(c ?: g); }
int h;
unsigned char i;
long j;
class k { 
  l() { m.f(h, , j); }
  d m;
};


If you compile that snipped with -Wall -Wextra, you get:

: In instantiation of ‘int d::f(const e&, const a*, b) [with e = int; a =
unsigned char; b = unsigned int]’:
:15:21:   required from here
cc1plus: warning: enumeral and non-enumeral type in conditional expression
[-Wextra]

The warning comes from cc1plus and has no source information attached to it.
The comparison is on line 11, but the source printed is line 15 - which is the
declaration of "class k".

The kind of diagnostic I'd expect is (from a different reduction):

reduction.cpp:4:21: warning: enumeral and non-enumeral type in conditional
expression [-Wextra]
4 | void b() { long c(a ?: c); }
  |   ~~^~~~

That is, actually pointing me to _where_ the comparison happens.

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[palves at redhat dot com]

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

--- Comment #30 from Pedro Alves  ---
I assume so, but do we really want to zero-initialize the buffer?  T might be
large, and I'd think that pessimization to quiet a warning isn't the right way
to go?

[Bug c++/80635] std::optional and bogus -Wmaybe-uninitialized warning

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #29 from Jason Merrill  ---
(In reply to Pedro Alves from comment #0)
>union
>{
>  int m_dummy;
>  T m_item;

Here, changing m_dummy to be unsigned char[sizeof(T)] (or std::byte instead of
unsigned char), so that the buffer starts fully zero-initialized, avoids the
warning.  Similarly, in msebor's comment #15 testcase, having the C constructor
initialize x instead of t avoids the warning.  For some reason, this isn't
working for me with actual std::optional.

[Bug middle-end/92824] Wrong optimization: representation of long doubles not copied even with memcpy

[ch3root at openwall dot com]

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

--- Comment #4 from Alexander Cherepanov  ---
(In reply to Richard Biener from comment #3)
> shows we're constant folding this to
> 
>   __builtin_printf ("%lf\n",
> 3.36210314311209350626267781732175260259807934484647124011e-4932);

Unfortunately, in this form, it's not clear whether normalization already
happened or not (unlike with clang which prints such numbers as hex).

OTOH I would not expect problems with only one variable after pr71522 was
fixed.

> now.  When we put #pragma GCC unroll 16 before your testcases loop we
> get the following (unrolling and constant folding happens after the
> "bad" transform)
> 
> main ()
> {
>[local count: 82570746]:
>   printf ("%02x ", 128);
>   printf ("%02x ", 128);
>   printf ("%02x ", 0);
>   printf ("%02x ", 0);
>   printf ("%02x ", 128);
>   printf ("%02x ", 0);
>   printf ("%02x ", 0);
>   printf ("%02x ", 0);
>   printf ("%02x ", 0);
>   printf ("%02x ", 0);
>   printf ("%02x ", 0);
>   printf ("%02x ", 0);
>   __builtin_putchar (10);
>   return 0;

After inserting `#pragma GCC unroll 16` in my testcase I get something else:

main ()
{
   [local count: 63136024]:
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 1);
  printf ("%02x ", 128);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  printf ("%02x ", 0);
  __builtin_putchar (10);
  return 0;

}

Please note 16 values being printed instead of 12, "1" printed in exponent and
zeroes in padding (exactly as in the description of this pr). I'm testing on
x86-64.

[Bug c++/92968] C style struct initialization fail to compile in g++ when initializing array fields

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Because it is valid C (C99 and later), but invalid C++.  While C++20 supports
designated initializers, it only supports them with e.g. { .a = { 5, 0 } }.
See http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0329r4.pdf for
details which even highlights the C vs. C++ differences with rationale.

[Bug c++/92973] [10 Regression] Silently accepting defaulted comparison operators in C++11 .. 17

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47517
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47517=edit
gcc10-pr92973.patch

Untested fix.

[Bug c++/92973] [10 Regression] Silently accepting defaulted comparison operators in C++11 .. 17

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-17
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/92973] New: [10 Regression] Silently accepting defaulted comparison operators in C++11 .. 17

[jakub at gcc dot gnu.org]

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

Bug ID: 92973
   Summary: [10 Regression] Silently accepting defaulted
comparison operators in C++11 .. 17
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

struct S { bool operator==(const S&) const = default; int s; };
static_assert(S{} == S{});

is silently accepted in -std=c++11 .. -std=c++17 modes, even when it should be
valid only in -std=c++2a.

[Bug c++/92966] Segfault on defaulted operator== with wrong return type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-17
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47516
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47516=edit
gcc10-pr92966.patch

Untested fix.

[Bug c++/92965] "note: 'x' is not public" emitted even when no error is emitted

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-17
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 47515
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47515=edit
gcc10-pr92965.patch

Untested fix.

[Bug tree-optimization/92772] wrong code vectorizing masked max

[ams at gcc dot gnu.org]

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

Andrew Stubbs  changed:

   What|Removed |Added

   Priority|P3  |P5
   Severity|critical|minor

--- Comment #7 from Andrew Stubbs  ---
Thank you for the help, Richard and Richard.

I'm electing not to fix this bug, but instead have worked around it for amdgcn
by implementing the fold_extract_last pattern.

There's two main reasons for this:

1. I'm not confident I can see how to fix it properly, so it's going to take me
a long time to get it right.

2. The code that it generates is horrible (and the fix will only make it
worse), so I would want to implement fold_extract_last anyway. This would leave
this code unused by amdgcn, and the time spent fixing it wasted effort.

I've therefore downgraded the priority and severity on this bug, and committed
a pointer into the code to assist anybody tripping over the same issue in
future.

https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01191.html

The bug still exists, but is now no longer reproducible on amdgcn.

[Bug tree-optimization/92486] Wrong optimization: padding in structs is not copied even with memcpy

[jamborm at gcc dot gnu.org]

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

--- Comment #17 from Martin Jambor  ---
If we really decide to fix this in SRA, i can be done (after the previous
patches in the series are in) with something like
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01185.html

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[jakub at gcc dot gnu.org]

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

--- Comment #15 from Jakub Jelinek  ---
As for __builtin_*_eq, we could have some analysis that looks at accesses from
the same base, and e.g. if there is struct S { char name[16]; int whatever; }
and
we see strcmp (p->name, ...) and p->whatever stored or loaded before that or
after that with no possibility to exit/abort etc. in between, we could still
optimize into *_eq.  Doesn't tree-if-conv.c have similar analysis (ifc_dr
etc.)?
Maybe it would need to know minimal page size and only trigger if the
read/write of a field after it isn't too far away as a guarantee that in a
valid program if the first byte of p->name doesn't trap, then others won't
either.

[Bug tree-optimization/92706] SRA confuses FRE

[jamborm at gcc dot gnu.org]

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

--- Comment #4 from Martin Jambor  ---
I have proposed the following patches to address this on trunk.  The
testcase from comment #3 can be fixed with
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01183.html

The original testcase however needs also propagation from LHSs to RHSs
posted in https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01184.html

Both patches require a small fix posted in
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01182.html

[Bug ipa/92971] Suspicious code in cgraph_edge_brings_all_agg_vals_for_node(), ipa-cp.c

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-17
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Jambor  ---
I'll remove it with https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01186.html

[Bug tree-optimization/92765] [10 Regression] Wrong code caused by folding of -Wstring-compare since r276773

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
(In reply to Martin Sebor from comment #12)
> The __builtin_strcmp(ptr->header.magic, "x") call in comment #0 is undefined
> because the two-element array ptr->header.magic is not a nul-terminated
> string.  The warning was designed to point that out.

If so, the warning needs to be done early.  And it shouldn't affect code
generation.

See e.g. tree-ssa-sccvn.c:
/* Probibit value-numbering zero offset components
   of addresses the same before the pass folding
   __builtin_object_size had a chance to run
   (checking cfun->after_inlining does the
   trick here).  */
if (TREE_CODE (orig) != ADDR_EXPR
|| maybe_ne (off, 0)
|| cfun->after_inlining)
  off.to_shwi ();
I'm surprised non-zero offs can be handled this way even before objsz1 pass,
before that we really should consider the same only if the offset is the same
and FIELD_DECLs type has the same size, but we could have some cfun flag or
property set by objsz1 pass.  That said, after that what COMPONENT_REFs are
used in ADDR_EXPR needs to be ignored.

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[jakub at gcc dot gnu.org]

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

--- Comment #10 from Jakub Jelinek  ---
Make that:
struct T { char a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p; };
struct S { long l; struct T t; };

void
foo (long l, struct S *p)
{
  p->l = l;
  p->t.a = 2;
  p->t.b = 3;
  p->t.c = 4;
  p->t.d = 5;
  p->t.e = 6;
  p->t.f = 7;
  p->t.g = 8;
  p->t.h = 9;
  p->t.i = 10;
  p->t.j = 11;
  p->t.k = 12;
  p->t.l = 13;
  p->t.m = 14;
  p->t.n = 15;
  p->t.o = 16;
  p->t.p = 17;
}
and at -O3 slp2 doing:
+  vect_cst__21 = { 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17 };
   p_2(D)->l = l_3(D);
-  p_2(D)->t.a = 2;
-  p_2(D)->t.b = 3;
-  p_2(D)->t.c = 4;
-  p_2(D)->t.d = 5;
-  p_2(D)->t.e = 6;
-  p_2(D)->t.f = 7;
-  p_2(D)->t.g = 8;
-  p_2(D)->t.h = 9;
-  p_2(D)->t.i = 10;
-  p_2(D)->t.j = 11;
-  p_2(D)->t.k = 12;
-  p_2(D)->t.l = 13;
-  p_2(D)->t.m = 14;
-  p_2(D)->t.n = 15;
-  p_2(D)->t.o = 16;
-  p_2(D)->t.p = 17;
+  vectp.4_22 = _2(D)->t.a;
+  MEM  [(char *)vectp.4_22] = vect_cst__21;

pr92956.c: In function ‘foo’:
pr92956.c:8:10: warning: writing 16 bytes into a region of size 1
[-Wstringop-overflow=]
8 |   p->t.a = 2;
  |   ~~~^~~
pr92956.c:1:17: note: at offset 0 to object ‘a’ with size 1 declared here
1 | struct T { char a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p; };
  | ^

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek  ---
To reproduce, one can use e.g.
./gfortran -B ./ -fopenmp -O3 -flto -flto-partition=1to1 -fno-use-linker-plugin
async_target-2.f90 -fdump-tree-strlen -r -nostdlib -I
../x86_64-pc-linux-gnu/libgomp/ -B ../x86_64-pc-linux-gnu/libgomp/ -B
../x86_64-pc-linux-gnu/libgomp/.libs/ -v -save-temps
(if the test is copied into the gcc/ subdirectory of build dir).
The
  vectp.52_27 = [(struct array01_real(kind=4) *)_7 clique 1 base
0].dtype.rank;
  MEM  [(signed char *)vectp.52_27 clique 1 base 0] = {
1, 3 };
the warning warns about has been created by SLP vectorization of
  MEM[(struct array01_real(kind=4) *)_7 clique 1 base 0].dtype.rank = 1;
  MEM[(struct array01_real(kind=4) *)_7 clique 1 base 0].dtype.type = 3;
It can be reproduced e.g. with -O3 on x86_64-linux:
struct T { char a, b, c, d, e, f, g, h, i, j, k, l, m, n, o, p; };
struct S { long l; struct T t; };

void
foo (long l, struct S *p)
{
  p->l = l;
  p->t.a = 2;
  p->t.b = 3;
  p->t.c = 4;
  p->t.d = 5;
  p->t.e = 6;
  p->t.f = 7;
  p->t.g = 8;
  p->t.h = 9;
  p->t.i = 10;
  p->t.j = 11;
  p->t.k = 12;
  p->t.l = 13;
  p->t.m = 14;
  p->t.n = 15;
  p->t.o = 16;
}

Here slp2 pass changes:
+  vect_cst__20 = { 2, 3, 4, 5, 6, 7, 8, 9 };
   p_2(D)->l = l_3(D);
-  p_2(D)->t.a = 2;
-  p_2(D)->t.b = 3;
-  p_2(D)->t.c = 4;
-  p_2(D)->t.d = 5;
-  p_2(D)->t.e = 6;
-  p_2(D)->t.f = 7;
-  p_2(D)->t.g = 8;
-  p_2(D)->t.h = 9;
+  vectp.4_21 = _2(D)->t.a;
+  MEM  [(char *)vectp.4_21] = vect_cst__20;
This is valid GIMPLE IL, but like in PR92765, the warning code makes
assumptions that aren't valid in GIMPLE, after early opts where GCC for
__builtin_object_size (, [13]) purposes disables some optimization to ensure
the access paths are meaningful, later passes don't preserve it and for
ADDR_EXPR all that matters is the value,
i.e. what offset from the base needs to be added, what COMPONENT_REFs are there
or aren't doesn't mean anything.

[Bug ipa/92971] Suspicious code in cgraph_edge_brings_all_agg_vals_for_node(), ipa-cp.c

[jamborm at gcc dot gnu.org]

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

--- Comment #2 from Martin Jambor  ---
(In reply to fxue from comment #0)
> The variable "values" is defined as static, which makes a questionable side
> effect. History calls will impact result of current call!
> 
>   for (i = 0; i < count; i++)
> {
>   static vec values = vNULL;
>   class ipcp_param_lattices *plats;

Ugh, fortunately it is always assigned before the first use but it definitely
should not be a static variable, that is some sort of pasto.  I'll prepare an
obvious patch.  Thanks for spotting it.

[Bug ipa/92971] Suspicious code in cgraph_edge_brings_all_agg_vals_for_node(), ipa-cp.c

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This has been added in r193700, CCing author.

[Bug lto/92972] gcc/lto-wrapper.c:443: identical branches ?

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Created attachment 47514
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47514=edit
gcc10-pr92972.patch

Untested patch.

[Bug lto/92972] gcc/lto-wrapper.c:443: identical branches ?

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-12-17
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
It is suspicious and redundant, but correct, -fno-PIE and -fno-pie does the
same thing.  I think we should just use unconditional = "-fno-pie" in that
case.

[Bug lto/92972] New: gcc/lto-wrapper.c:443: identical branches ?

[dcb314 at hotmail dot com]

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

Bug ID: 92972
   Summary: gcc/lto-wrapper.c:443: identical branches ?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Some suspicious coding in lto-wrapper.c:

trunk/gcc/lto-wrapper.c:443:60: warning: this condition has identical branches
[-Wduplicated-branches]

svn blame says:

263988hubicka (*decoded_options)[j].canonical_option[0] = big ?
"-fno-pie" : "-fno-pie";

[Bug ipa/92971] New: Suspicious code in cgraph_edge_brings_all_agg_vals_for_node(), ipa-cp.c

[fxue at gcc dot gnu.org]

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

Bug ID: 92971
   Summary: Suspicious code in
cgraph_edge_brings_all_agg_vals_for_node(), ipa-cp.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The variable "values" is defined as static, which makes a questionable side
effect. History calls will impact result of current call!

  for (i = 0; i < count; i++)
{
  static vec values = vNULL;
  class ipcp_param_lattices *plats;

[Bug libgomp/92970] OpenACC 2.5: 'acc_delete' etc. on non-present data is a no-op

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
Created attachment 47513
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47513=edit
'libgomp.oacc-c-c++-common/pr92970-1.c'

I'm attaching a simple C/C++ test case.

Tobias, will you please provide similar Fortran test cases, that exercises all
the different code paths that we have in
'libgomp/oacc-mem.c:GOACC_enter_exit_data', related to 'find_pointer' handling?

[Bug libgomp/92970] New: OpenACC 2.5: 'acc_delete' etc. on non-present data is a no-op

[tschwinge at gcc dot gnu.org]

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

Bug ID: 92970
   Summary: OpenACC 2.5: 'acc_delete' etc. on non-present data is
a no-op
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org,
jules at gcc dot gnu.org
  Target Milestone: ---

OpenACC 2.5 states that 'acc_delete' etc. on non-present data is a no-op.

Note that this (silently!) changed in OpenACC 2.6 ff.: "a runtime error is
issued".  I filed  "OpenACC
2.5 vs. 2.6 ff. difference in 'acc_delete' etc. for non-present data".

GCC trunk should currently be implementing the OpenACC 2.5 semantics, but we
fail (at least for some variants).  I know of course how to easily fix this,
but will wait to first get the intended OpenACC semantics clarified.

[Bug tree-optimization/92949] bswap/store merging does not handle BIT_INSERT_EXPR/BIT_FIELD_REF

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
Note bswap pass is very fragile.  In fact if we increase the limit by 1, things
dont work any more.  There needs to be a better way of handling this.

Oh when I was adding bit insert to it, it falls over due to the above problem
too, though it is a little more complex.
If I start with zero, I can get it to work.  Though I have not added that one
yet.

I will be looking into what we could do for store merging to see if it could be
improved.

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus  ---
(In reply to Tobias Burnus from comment #7)
> testsuite/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing
> 2 bytes into a region of size 1 [-Wstringop-overflow=]
>34 | allocate (v1(N), v2(N))
> lto1: note: at offset 0 to object ‘rank’ with size 1 declared here

First, I want to note that there is no string (STRING_TYPE) around but only
numeric data types.

My feeling is that the following goes wrong, in -fdump-tree-omplower(-lineno),
one has:
  D.4378 = .omp_data_i->v1;
  D.4378->dtype.rank = 1;
  D.4379 = .omp_data_i->v1;
  D.4379->dtype.type = 3;
which later becomes (-fdump-dtree-strlen):
   vectp.205_27 = & *_7.dtype.rank
   MEM  [(signed char *)vectp.205_27] = { 1, 3 };

See libgfortran/libgfortran.h for how the struct is organized; namely:
  signed char rank;
  signed char type;

[Bug target/92962] Documentation: x86 Options - znver2 missing RDPID and WBNOINVD

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 17 09:23:59 2019
New Revision: 279455

URL: https://gcc.gnu.org/viewcvs?rev=279455=gcc=rev
Log:
PR target/92962
* common/config/i386/i386-common.c (processor_alias_table): Formatting
fixes.
* doc/invoke.texi (bdver3, bdver4, znver1): Add missing closing paren.
(znver2): Likewise.  Add RDPID and WBNOINVD, remove spurious comma
before CLWB.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/common/config/i386/i386-common.c
trunk/gcc/doc/invoke.texi

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus  ---
Created attachment 47512
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47512=edit
-fdump-tree-strlen for both host run (async_target-2.f90.180t.strlen1, 1639
lines) and LTO nvptx run (async_target-2.o.180t.strlen1, 563 l.)

(In reply to Thomas Schwinge from comment #6)
> but I'll note that -- as we've seen in PR92952 -- it's actually useful in
> other scenarios
I think it can be useful in corner cases for Fortran for code written such that
FE compiler cannot check it at compile time. With explicitly writing bounds, it
can also be useful for a single TU, e.g.
subroutine str(n)
  integer :: n
  character(len=n) :: str  ! n = not known without call-argument propagation
  str(n:n+2) = 'abc' ! writes 2 bytes out of bounds

Thus, you should consider to enable it for all languages - or at least Fortran
in addition.


> This problem persists, thus:

I can confirm that the issue has been fixed for gfortran.dg/lto/pr87689_*,
but not for libgomp.fortran/examples-4/async_target-2.f90


Using the same options as for async_target-2.f90, it also fails without actual
offloading:

gfortran-trunk -fopenmp -O3 -flto -flto-partition=1to1 -fno-use-linker-plugin
testsuite/libgomp.fortran/examples-4/async_target-2.f90 -fdump-tree-strlen


testsuite/libgomp.fortran/examples-4/async_target-2.f90: In function
‘vec_mult_._omp_fn.2’:
testsuite/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2
bytes into a region of size 1 [-Wstringop-overflow=]
   34 | allocate (v1(N), v2(N))
  | 
lto1: note: at offset 0 to object ‘rank’ with size 1 declared here
testsuite/libgomp.fortran/examples-4/async_target-2.f90:34: warning: writing 2
bytes into a region of size 1 [-Wstringop-overflow=]
lto1: note: at offset 0 to object ‘rank’ with size 1 declared here

 * * *

With offloading, it fails for:

10.0.0/accel/nvptx-none/lto1 -fdump-tree-strlen -quiet -dumpbase
async_target-2.o -m64 -mgomp -auxbase async_target-2 -O3 -version -fno-openacc
-fno-pie -foffload-abi=lp64 -fopenmp @/tmp/ccarNfXs -o async_target-2.s

 * * *

I have now attached both -fdump-tree-strlen

[Bug c++/92969] New: Segmentation fault compiling partial specialization of auto-deduced member function pointers

[joe.antoon at gmail dot com]

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

Bug ID: 92969
   Summary: Segmentation fault compiling partial specialization of
auto-deduced member function pointers
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: joe.antoon at gmail dot com
  Target Milestone: ---

Created attachment 47511
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47511=edit
preprocessed source

The following code, which auto-deduces and partially specializes a parameter
pack of member function pointers, causes a segmentation fault during
compilation:

CODE:
template 
struct Foo;

template <
typename Class,
typename... ReturnType, 
ReturnType (Class::*...Methods)()>
struct Foo {
constexpr void operator ()() { }
};

struct Bar {
  int baz() { return 42; }
};

void tryOut() {
  Foo<::baz>{}();
}

EXPECTED RESULT: compiles on clang v9 without errors
ACTUAL RESULT:
during RTL pass: expand
: In function 'void tryOut()':
:17:19: internal compiler error: Segmentation fault
   17 |   Foo<::baz>{}();
  |   ^~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Encountered on g++-9 Ubuntu 18.04 WSL.
COMMAND: g++ test.cpp -std=c++17
SYSTEM TYPE: x86_64-linux-gnu
VERSION: gcc version 9.2.1 20191102 (Ubuntu 9.2.1-17ubuntu1~18.04.1)
CONFIGURATION: Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.2.1-17ubuntu1~18.04.1' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-offload-targets=nvptx-none,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu

Also reproduces on Compiler Explorer:
COMMAND: g++ test.cpp -std=c++17
SYSTEM TYPE: x86_64-linux-gnu
VERSION: gcc version 9.2.0 (Compiler-Explorer-Build) 
CONFIGURATION: Configured with: ../gcc-9.2.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran,ada,d
--enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto
--enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build

https://godbolt.org/z/PJZdPL

[Bug target/92950] Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

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

--- Comment #3 from Andreas Krebbel  ---
Author: krebbel
Date: Tue Dec 17 08:41:54 2019
New Revision: 279454

URL: https://gcc.gnu.org/viewcvs?rev=279454=gcc=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi

The backend emits 16 bit memory loads for single element character
vector.  As a result the character will not be right justified in the
GPR.

gcc/ChangeLog:

2019-12-17  Andreas Krebbel  

Backport from mainline
2019-12-16  Andreas Krebbel  

PR target/92950
* config/s390/vector.md ("mov" for V_8): Replace lh, lhy,
and lhrl with llc.

gcc/testsuite/ChangeLog:

2019-12-17  Andreas Krebbel  

Backport from mainline
2019-12-16  Andreas Krebbel  

PR target/92950
* gcc.target/s390/vector/pr92950.c: New test.


Added:
branches/gcc-8-branch/gcc/testsuite/gcc.target/s390/vector/pr92950.c
Modified:
branches/gcc-8-branch/gcc/ChangeLog
branches/gcc-8-branch/gcc/config/s390/vector.md
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug target/92950] Wrong load instructions emitted for movv1qi

[krebbel at gcc dot gnu.org]

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

--- Comment #2 from Andreas Krebbel  ---
Author: krebbel
Date: Tue Dec 17 08:37:26 2019
New Revision: 279453

URL: https://gcc.gnu.org/viewcvs?rev=279453=gcc=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi

The backend emits 16 bit memory loads for single element character
vector.  As a result the character will not be right justified in the
GPR.

gcc/ChangeLog:

2019-12-17  Andreas Krebbel  

Backport from mainline
2019-12-16  Andreas Krebbel  

PR target/92950
* config/s390/vector.md ("mov" for V_8): Replace lh, lhy,
and lhrl with llc.

gcc/testsuite/ChangeLog:

2019-12-17  Andreas Krebbel  

Backport from mainline
2019-12-16  Andreas Krebbel  

PR target/92950
* gcc.target/s390/vector/pr92950.c: New test.


Added:
branches/gcc-9-branch/gcc/testsuite/gcc.target/s390/vector/pr92950.c
Modified:
branches/gcc-9-branch/gcc/ChangeLog
branches/gcc-9-branch/gcc/config/s390/vector.md
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug fortran/92956] 'libgomp.fortran/examples-4/async_target-2.f90' offloading compilation regression

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2019-12-17
 Resolution|DUPLICATE   |---
 Ever confirmed|0   |1

--- Comment #6 from Thomas Schwinge  ---
(In reply to Martin Sebor from comment #2)
> -Wstringop-overflow is a C-family only option that shouldn't be enabled for
> Fortran.  It took some effort to make it work that way (see pr80545 for the
> background) and there's no test for it so either the logic put in there
> still isn't correct or something has regressed.

I don't have time right now to read up the history/rationale behind that
(enabling a generic? middle-end warning only for certain source languages), but
I'll note that -- as we've seen in PR92952 -- it's actually useful in other
scenarios, too?  (And if only to make the analysis' code more robust.)


(In reply to Martin Sebor from comment #5)
> Thanks!  Yes, the code made the incorrect assumption that array indices were
> zero-based.  I just committed r279445 with a fix so I'm going to assume it
> takes care of these warnings as well as will resolve this as a duplicate.

This problem persists, thus:

> *** This bug has been marked as a duplicate of bug 92952 ***

Re-opened.