[Bug c++/94924] Default equality operator for C-array compares addresses, not data

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-05-06
 Status|UNCONFIRMED |NEW

[Bug libstdc++/94960] extern template prevents inlining of standard library objects

[erich.keane at intel dot com]

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

Erich Keane  changed:

   What|Removed |Added

 CC||erich.keane at intel dot com

--- Comment #3 from Erich Keane  ---
(In reply to Jonathan Wakely from comment #2)
> Please provide complete testcases, not just URLs, as required by
> https://gcc.gnu.org/bugs
> 
> #include 
> 
> int main()
> {
> std::string(size_t(0), 0);
> }
> 
> 
> I still think it's wrong for GCC to treat the 'inline' specifier as an
> inlining hint. The compiler should be a better judge of inlining decisions
> than the developer.
> 
> (In reply to Andrew Pinski from comment #1)
> > g:1a289fa36294627c252492e4c18d7877a7c80dc1 changed that.
> 
> Well that commit just meant that the explicit instantiations are declared
> for C++17 as well, where previously they were only declared for < C++17. It
> didn't add the explicit instantiations.

Hi Jon!
I helped the submitter in #llvm debug this a little, so I perhaps have a better
understanding of his issue:

As you know, "extern template" is a hint to the compiler that we don't need to
emit the template as a way to save on compile time.

Both GCC and clang will NOT instantiate these templates in O0 mode.  However,
in O1+ modes, both will actually still instantiate the templates in the
frontend, BUT only for 'inline' functions.  Basically, we're using 'inline' as
a heuristic that there is benefit in sending these functions to the optimizer
(basically, sacrificing the compile time gained by 'extern template' in
exchange for a better inlining experience).

In the submitter's case, the std::string constructor calls "_M_construct".  The
constructor is inlined, but _M_construct is not, since it never gets to the
optimizer.

libc++ uses an __init function to do the same thing as _M_construct, however IT
is marked inline, and thus doesn't have the problem.

I believe the submitter wants to have you mark more of the functions in
extern-templated classes 'inline' so that it matches the heuristic better.

I don't think that there is a good way to change the compiler itself without
making 'extern template' absolutely meaningless.

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[joseph at codesourcery dot com]

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

--- Comment #44 from joseph at codesourcery dot com  ---
This commit also introduces bug 94963 which breaks the glibc build (and is 
*not* fixed by the commit that fixed bug 94949).

[Bug tree-optimization/94963] New: [11 Regression] Spurious uninitialized warning for static variable building glibc

[jsm28 at gcc dot gnu.org]

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

Bug ID: 94963
   Summary: [11 Regression] Spurious uninitialized warning for
static variable building glibc
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---

r11-39-gf9e1ea10e657af9fb02fafecf1a600740fd34409 ("tree-optimization/39612 -
avoid issueing loads in SM when possible") introduces a spurious warning
building the following code (reduced from glibc) with -O2 -Wall (for
aarch64-linux-gnu at least, probably for other targets.  The warning is
obviously bogus because it relates to a field of a static variable, which is
always initialized.

uninit.c: In function 'f':
uninit.c:30:6: warning: 'var_field_lsm.8' may be used uninitialized in this
function [-Wmaybe-uninitialized]
   30 |   if (var.field != 0)
  |  ^


Reduced testcase:

typedef struct
{
  int p1;
  int p2;
  int p3;
} P;
struct S
{
  int field;
};
extern int v2;
extern void foo (struct S *map);
static struct S var;
const P *pv;
int ps;
void
f (void)
{
  if (pv != 0)
for (const P *ph = pv; ph < [ps]; ++ph)
  switch (ph->p1)
{
case 1:
  v2 = ph->p2;
  break;
case 2:
  var.field = ph->p3;
  break;
}
  if (var.field != 0)
foo ();
}

[Bug tree-optimization/94962] New: Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

[n...@self-evident.org]

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

Bug ID: 94962
   Summary: Suboptimal AVX2 code for
_mm256_zextsi128_si256(_mm_set1_epi8(-1))
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: n...@self-evident.org
  Target Milestone: ---

Background: https://stackoverflow.com/q/61601902/

GCC emits an unnecessary "vmovdqa xmm0,xmm0" for the following code:

 __m256i mask()
{
return _mm256_zextsi128_si256(_mm_set1_epi8(-1));
}

Live example on godbolt: https://gcc.godbolt.org/z/PbsQDR

I have found no way to avoid this except by resorting to inline asm.

[Bug c++/90212] [8/9/10/11 Regression] by-ref capture of constexpr class object rejected

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:04b89192ace3a766a17374d5bef8fb19d9be2d7c

commit r11-122-g04b89192ace3a766a17374d5bef8fb19d9be2d7c
Author: Jason Merrill 
Date:   Tue May 5 17:39:19 2020 -0400

c++: constexpr and lambda capture [PR90212]

This is the same issue as PR86429, just in potential_constant_expression_1
rather than cxx_eval_constant_expression.  As in that case, when we're
trying to evaluate a constant expression within a lambda, we don't have a
constant closure object to refer to, but we can try to refer directly to
the
captured variable.

gcc/cp/ChangeLog
2020-05-05  Jason Merrill  

PR c++/90212
* constexpr.c (potential_constant_expression_1): In a lambda
function, consider a captured variable directly.

[Bug libstdc++/94960] extern template prevents inlining of standard library objects

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-05-05
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #2 from Jonathan Wakely  ---
Please provide complete testcases, not just URLs, as required by
https://gcc.gnu.org/bugs

#include 

int main()
{
std::string(size_t(0), 0);
}


I still think it's wrong for GCC to treat the 'inline' specifier as an inlining
hint. The compiler should be a better judge of inlining decisions than the
developer.

(In reply to Andrew Pinski from comment #1)
> g:1a289fa36294627c252492e4c18d7877a7c80dc1 changed that.

Well that commit just meant that the explicit instantiations are declared for
C++17 as well, where previously they were only declared for < C++17. It didn't
add the explicit instantiations.

[Bug libstdc++/94960] extern template prevents inlining of standard library objects

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
g:1a289fa36294627c252492e4c18d7877a7c80dc1 changed that.

[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef

[mpolacek at gcc dot gnu.org]

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

--- Comment #18 from Marek Polacek  ---
Actually it might be better to make it out to a function and use that in both
places, otherwise I'm either duplicating code or it's just too ugly.

[Bug testsuite/84324] objc/execute/exceptions/matcher-1.m:27:10: warning: return with a value, in function returning void

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #2 from H.J. Lu  ---
Fixed for GCC 11.

[Bug testsuite/84324] objc/execute/exceptions/matcher-1.m:27:10: warning: return with a value, in function returning void

[cvs-commit at gcc dot gnu.org]

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-121-gd0aed8d5ba77e0756f3c9ebcd65eba1bfb11f24b
Author: H.J. Lu 
Date:   Tue May 5 13:35:36 2020 -0700

matcher-1.m: Change return type to int

my_exception_matcher must return int.  Otherwise, this test fails.

PR testsuite/84324
* objc/execute/exceptions/matcher-1.m (my_exception_matcher):
Change return type to int.

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on master for GCC 11.  Thanks for the report!

[Bug fortran/93366] ICE: Invalid expression in gfc_element_size

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:5a26ea7e0f8b9a00a2eb0a5e8f70efa04056f167

commit r11-120-g5a26ea7e0f8b9a00a2eb0a5e8f70efa04056f167
Author: Harald Anlauf 
Date:   Tue May 5 22:16:50 2020 +0200

PR fortran/93366 - ICE on invalid, reject invalid use of NULL() as argument

gcc/fortran/ChangeLog:

2020-05-05  Steve Kargl  
Harald Anlauf  

PR fortran/93366
* check.c (gfc_check_associated, invalid_null_arg): Factorize
check for presence of invalid NULL() argument.
(gfc_check_kind, gfc_check_merge, gfc_check_shape)
(gfc_check_sizeof, gfc_check_spread, gfc_check_transfer): Use this
check for presence of invalid NULL() arguments.

gcc/testsuite/ChangeLog:

2020-05-05  Harald Anlauf  

PR fortran/93366
* gfortran.dg/pr93366.f90: New test.

[Bug bootstrap/94961] New: [11 regression] internal compiler error: in df_refs_verify, at df-scan.c:4002

[dimhen at gmail dot com]

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

Bug ID: 94961
   Summary: [11 regression] internal compiler error: in
df_refs_verify, at df-scan.c:4002
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

r11-46 PASS
r11-117 FAIL

configure --enable-checking=yes,df --enable-languages=c,c++,lto
--disable-multilib

make
...
/home/dimhen/build/gcc_current/./prev-gcc/xg++
-B/home/dimhen/build/gcc_current/./prev-gcc/
-B/usr/local/x86_64-pc-linux-gnu/bin/ -nostdinc++
-B/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-B/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu
 -I/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/include
 -I/home/dimhen/src/gcc_current/libstdc++-v3/libsupc++
-L/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/dimhen/build/gcc_current/prev-x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g -O2 -fno-checking -gtoggle -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings -Werror -fno-common  -DHAVE_CONFIG_H -I. -I.
-I/home/dimhen/src/gcc_current/gcc -I/home/dimhen/src/gcc_current/gcc/.
-I/home/dimhen/src/gcc_current/gcc/../include
-I/home/dimhen/src/gcc_current/gcc/../libcpp/include
-I/home/dimhen/build/gcc_current/./gmp -I/home/dimhen/src/gcc_current/gmp
-I/home/dimhen/build/gcc_current/./mpfr/src
-I/home/dimhen/src/gcc_current/mpfr/src -I/home/dimhen/src/gcc_current/mpc/src 
-I/home/dimhen/src/gcc_current/gcc/../libdecnumber
-I/home/dimhen/src/gcc_current/gcc/../libdecnumber/bid -I../libdecnumber
-I/home/dimhen/src/gcc_current/gcc/../libbacktrace
-I/home/dimhen/build/gcc_current/./isl/include
-I/home/dimhen/src/gcc_current/isl/include  -o tree-ssa-loop-ivopts.o -MT
tree-ssa-loop-ivopts.o -MMD -MP -MF ./.deps/tree-ssa-loop-ivopts.TPo
/home/dimhen/src/gcc_current/gcc/tree-ssa-loop-ivopts.c
during RTL pass: jump2
/home/dimhen/src/gcc_current/gcc/tree-ssa-ccp.c: In function 'void
bit_value_unop(tree_code, signop, int, widest_int*, widest_int*, signop, int,
const widest_int&, const widest_int&)':
/home/dimhen/src/gcc_current/gcc/tree-ssa-ccp.c:1338:1: internal compiler
error: in df_refs_verify, at df-scan.c:4002
 1338 | }
  | ^
0xf1eb1d df_refs_verify
/home/dimhen/src/gcc_current/gcc/df-scan.c:4002
0xf1ed50 df_insn_refs_verify
/home/dimhen/src/gcc_current/gcc/df-scan.c:4072
0xf1eec4 df_bb_verify
/home/dimhen/src/gcc_current/gcc/df-scan.c:4101
0xf1f46e df_scan_verify()
/home/dimhen/src/gcc_current/gcc/df-scan.c:4222
0xf07083 df_verify()
/home/dimhen/src/gcc_current/gcc/df-core.c:1818
0xf0593f df_analyze_1
/home/dimhen/src/gcc_current/gcc/df-core.c:1214
0xf05d02 df_analyze()
/home/dimhen/src/gcc_current/gcc/df-core.c:1290
0x23a9d46 try_optimize_cfg
/home/dimhen/src/gcc_current/gcc/cfgcleanup.c:2994
0x23aa1cf cleanup_cfg(int)
/home/dimhen/src/gcc_current/gcc/cfgcleanup.c:3174
0x23aa506 execute
/home/dimhen/src/gcc_current/gcc/cfgcleanup.c:3354
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [Makefile:1117: tree-ssa-ccp.o] Error 1

[Bug libstdc++/94960] New: extern template prevents inlining of standard library objects

[krzysio.kurek at wp dot pl]

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

Bug ID: 94960
   Summary: extern template prevents inlining of standard library
objects
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krzysio.kurek at wp dot pl
  Target Milestone: ---

Consider this example
void foo()
{
  std::string(1, 0);
}
(https://godbolt.org/z/AlkBBJ)
This function creates a string using the `basic_string(size_t, CharT)`
constructor and then discards it. This particular constructor uses _M_construct
internally, which is declared as an out of line member function. Because of
this, and because the function isn't marked as `inline`, when the compiler
reaches the `extern template class basic_string;`, it foregoes trying to
find the definition for _M_construct, instead generating a call to it, causing
foo() to fully instantiate a string object and then delete it, since the
compiler can't find _M_construct within its own translation unit.

This problem applies to every member function of any class which has an extern
template, is defined out of line and is not marked as `inline`.

[Bug tree-optimization/94913] Failure to optimize not+cmp into overflow check

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||jakub at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-05-05

--- Comment #3 from Uroš Bizjak  ---
(In reply to Gabriel Ravier from comment #1)
> The same thing happens for this code :
> 
> bool f(unsigned x, unsigned y)
> {
> return (x - y - 1) >= x;
> }

This transformation is the job for tree combiner.

[Bug tree-optimization/94913] Failure to optimize not+cmp into overflow check

[ubizjak at gmail dot com]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 48458
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48458=edit
Prototype patch

Prototype patch for missed optimization, described in Comment #0.

Following testcase:

--cut here--
int
foo (unsigned int x, unsigned int y)
{
  return ~x < y;
}

void f1 (void);
void f2 (void);

void
bar (unsigned int x, unsigned int y)
{
  if (~x < y)
f1 ();
  else
f2 ();
}
--cut here--

compiles (-O2) to:

foo:
xorl%eax, %eax
addl%esi, %edi
setc%al
ret

bar:
addl%esi, %edi
jnc .L4
jmp f1
.L4:
jmp f2

[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef

[mpolacek at gcc dot gnu.org]

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

--- Comment #17 from Marek Polacek  ---
Ah, omp_declare_variant_finalize_one.  I think I'll do something similar, but
not the same: if we see a CALL_EXPR whose CALL_EXPR_FN is a BASELINK, we know
it's not the std::is_constant_evaluated call we're looking for.  Thanks.

[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #16 from Jakub Jelinek  ---
I remember dealing with this elsewhere (in declare variant support).
I had to do:
-  variant = cp_get_callee_fndecl_nofold (variant); 
+  variant = cp_get_callee (variant);   
+  if (variant) 
+{  
+  if (TREE_CODE (variant) == FUNCTION_DECL)
+   ;   
+  else if (TREE_TYPE (variant) && INDIRECT_TYPE_P (TREE_TYPE (variant)))   
+   variant = cp_get_fndecl_from_callee (variant, false);   
+  else 
+   variant = NULL_TREE;
+}  
because cp_get_callee_fndecl_nofold would ICE (I think exactly like this one))
when feeded during processing_template_decl with something it doesn't expect to
see.

[Bug c++/94937] [10/11 Regression] ICE with if constexpr (in cp_get_fndecl_from_callee, at cp/cvt.c:1000) since r10-2835-g14da3939da3adcef

[mpolacek at gcc dot gnu.org]

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

--- Comment #15 from Marek Polacek  ---
Reduced:

struct B {
  static constexpr bool foo() { return false; }
};

template
struct C {
  static void bar ()
  {
if constexpr (B::foo()) ;
  }
};

[Bug tree-optimization/18487] Warnings for pure and const functions that are not actually pure or const

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #20 from Martin Sebor  ---
Working on a solution.

[Bug middle-end/4210] should not warn in dead code

[nisse at lysator dot liu.se]

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

--- Comment #37 from Niels Möller  ---
(In reply to Manuel López-Ibáñez from comment #35)
> There is no such place. Dead code is identified in the middle-end and by
> then, there is no parse tree, only GIMPLE and SSA:
> https://gcc.gnu.org/onlinedocs/gccint/Passes.html#Passes

So if emission of the warning is postponed to after the Tree SSA passes
(https://gcc.gnu.org/onlinedocs/gccint/Tree-SSA-passes.html#Tree-SSA-passes).
Could perhaps be inserted just after (or as part of) pass_remove_useless_stmts?

> > 3. Alternatively, [...] construct a special tree object representing an
> > expression with invalid/undefined behavior, and any meta data needed to emit
> > a warning or error to describe it? Then emission of the warning could be
> > postponed to later, say, close to the conversion to SSA form?
> 
> That is still too early, since the dead code elimination happens after SSA.

Then that special value needs to be passed through the conversions to gimple
and SSA. I imagine it could be treated much like a compile time constant, but
with an annotation saying it's invalid, and why, to be displayed in case the
compiler thinks it needs to generate any code to evaluate it. (And if we go
that route, we should probably do the same for most or all warnings on invalid
operands detected by the frontend).

[Bug middle-end/4210] should not warn in dead code

[nisse at lysator dot liu.se]

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

--- Comment #36 from Niels Möller  ---
(In reply to Martin Sebor from comment #34)
> 
> The front ends can eliminate simple subexpressions (as in '0 ? x >> 32 : x
> >> 1') but they don't do the same for statements.  Moving the warning from
> the front end to some later pass would avoid diagnosing code in those cases
> (it would also avoid duplicating the same code between different front
> ends).  The earliest is probably gimplify.c.  That would avoid warning on
> statements rendered dead as a result of constant expressions (as defined by
> the language) but not [...]

Thanks. So moving the warning to the gimplify pass would be an improvement over
the current situation. Maybe I can try it out, it sounds reasonably simple.

[Bug tree-optimization/94956] Unable to remove impossible ffs() test for zero

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Another option would be to fold FFS (x) for x known non-zero into CTZ (x) + 1
in match.pd.

[Bug fortran/94943] [10 Regression] A module does not export allocatable attribute of herein arrays.

[artu72 at gmail dot com]

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

--- Comment #2 from Andrea Mastellone  ---
(In reply to kargl from comment #1)
> There is very little we can do without a minimum example that shows the
> problem.  What you have attached cannot be compiled by anyone as
> deallocate_vars.f90 contains a dozen or so USE statements and you haven't
> provided those modules.  In addition, we don't do mpif90.  What happens if
> you remove all of the unnecessary compiler options you use and use actually
> use gfortran.

Ok, i will try to reduce the code to minimal part that can reproduce the
problem without using mpif90. I'll send you something asap.

[Bug middle-end/4210] should not warn in dead code

[manu at gcc dot gnu.org]

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

--- Comment #35 from Manuel López-Ibáñez  ---
(In reply to Niels Möller from comment #32)
> 1. There's similar code in c_fully_fold_internal, in gcc/c/c-fold.c, close
> to line 400. But that code does *not* emit any warning for the example
> above, which surprised me a bit. Maybe that's only for the case that both
> operands to the shift operator are constants?

In general, front-ends should avoid emitting warnings while folding
(simplifying) expressions. I think there is an open bug about this but I cannot
find it now.

Of course, if the code is doing the same, it should be factored out into a
common function. A good first patch to submit:
https://gcc.gnu.org/wiki/GettingStarted#Basics:_Contributing_to_GCC_in_10_easy_steps

> 2. More importantly, if the warning is deleted from build_binary_op, we need
> to add a check for this case, and an appropriate warning, somewhere later in
> the compilation process. It has to be done after dead code is identified,
> i.e., in a phase processing only non-dead code. And preferably as early as
> possibly, when we're still working close to the parse-tree representation.
> Is there such a place? Some other functions traversing the tree are
> c_gimplify_expr (gcc/c-family/c-gimplify.c) and verify_tree
> (gcc/c-family/c-common.c), are any of those called after elimination of dead
> code?

There is no such place. Dead code is identified in the middle-end and by then,
there is no parse tree, only GIMPLE and SSA:
https://gcc.gnu.org/onlinedocs/gccint/Passes.html#Passes

Of course, you could add some kind of unreachable code pass to the FE, but that
would require a lot of work from your side. Clang has something similar that
you could use as an inspiration: 

https://github.com/llvm/llvm-project/blob/2946cd701067404b99c39fb29dc9c74bd7193eb3/clang/include/clang/Analysis/Analyses/ReachableCode.h

> 3. Alternatively, if there's no place after dead code elimination where the
> parse tree is still easily available, a different alternative could be to
> leave the check for invalid shift counts in c-typeck.c, but instead of
> emitting a warning, construct a special tree object representing an
> expression with invalid/undefined behavior, and any meta data needed to emit
> a warning or error to describe it? Then emission of the warning could be
> postponed to later, say, close to the conversion to SSA form?

That is still too early, since the dead code elimination happens after SSA.

[Bug tree-optimization/94956] Unable to remove impossible ffs() test for zero

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
VRP knows that the argument must be non-zero:
  # RANGE ~[0, 0]
  x.0_1 = (int) x_3(D);
  # RANGE [1, 32] NONZERO 63
  _2 = __builtin_ffs (x.0_1);
  # RANGE [0, 31] NONZERO 31
  _4 = _2 + -1;
  return _4;
in *.optimized dump, but the comparison and conditional move is emitted by the
ffssi2 i386.md expander.  Unfortunately, from what that expander sees there is
no way to find out the argument is non-zero.
So, I wonder if for these optabs where whether the argument must be nonzero
might matter (anything but ffs?  I mean, clz, ctz have undefined values for
zero) we shouldn't add further optab, like ffsnonzero, where the code which
still can query VRP info of the argument could be used and use the other optab
in expand_direct_optab_fn.

[Bug target/94959] Wrong code gen for MVE intrinsics vldrbq_s32 which fails with assembler `Error: lo register required`

[sripar01 at gcc dot gnu.org]

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

SRINATH PARVATHANENI  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |sripar01 at gcc dot 
gnu.org
 Target||arm
   Last reconfirmed||2020-05-05
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug target/94959] New: Wrong code gen for MVE intrinsics vldrbq_s32 which fails with assembler `Error: lo register required`

[sripar01 at gcc dot gnu.org]

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

Bug ID: 94959
   Summary: Wrong code gen for MVE intrinsics vldrbq_s32 which
fails with assembler `Error: lo register required`
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sripar01 at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48457
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48457=edit
test case

$ arm-none-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-none-eabi-gcc
COLLECT_LTO_WRAPPER=/media/sripar01/2tb_work/Release/build-arm-none-eabi/install/libexec/gcc/arm-none-eabi/10.0.1/lto-wrapper
Target: arm-none-eabi
Configured with: /media/sripar01/2tb_work/Release/src/gcc/configure
--target=arm-none-eabi
--prefix=/media/sripar01/2tb_work/Release/build-arm-none-eabi/install//
--with-gmp=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-mpfr=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-mpc=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--with-isl=/media/sripar01/2tb_work/Release/build-arm-none-eabi/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=yes --enable-languages=c,c++,fortran --with-newlib
--with-multilib-list=rmprofile --with-pkgversion=unknown
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200427 (experimental) (unknown)

$arm-none-eabi-gcc new.c -c -Ofast -march=armv8.1-m.main+mve -mfloat-abi=hard

new.c: In function 'foo':
new.c:12351:27: warning: passing argument 1 of '__arm_vldrbq_s32' makes pointer
from integer without a cast [-Wint-conversion]
12351 | b += __arm_vldrbq_s32(c1);
  |   ^~
  |   |
  |   char
new.c:8600:34: note: expected 'const int8_t *' {aka 'const signed char *'} but
argument is of type 'char'
 8600 | __arm_vldrbq_s32 (int8_t const * __base)
  |   ~~~^~
/tmp/cc3Q97vs.s: Assembler messages:
/tmp/cc3Q97vs.s:47: Error: lo register required -- `vldrb.s32 q2,[ip]'


`vldrb.s32 q2,[ip]' --> For vldrbq_s32 MVE intrinsic, only low registers are
allowed as second argument and but current compiler is generating wrong code,
which is failing with assembler as shown above.

The test case added is not a properly written one (char variable c passed to
vldrbq_s32 where as expected is const int8_t *) but this is done to reproduce
the above failure.

[Bug fortran/94943] [10 Regression] A module does not export allocatable attribute of herein arrays.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
There is very little we can do without a minimum example that shows the
problem.  What you have attached cannot be compiled by anyone as
deallocate_vars.f90 contains a dozen or so USE statements and you haven't
provided those modules.  In addition, we don't do mpif90.  What happens if you
remove all of the unnecessary compiler options you use and use actually use
gfortran.

[Bug fortran/94958] gcc/fortran/trans-array.c:9797: possible typo ?

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||fanfarillo.gcc at gmail dot com
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89863

--- Comment #1 from David Binderman  ---
Adding original author from git blame and the static analyser bug report.

[Bug fortran/94958] New: gcc/fortran/trans-array.c:9797: possible typo ?

[dcb314 at hotmail dot com]

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

Bug ID: 94958
   Summary: gcc/fortran/trans-array.c:9797: possible typo ?
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

gcc/fortran/trans-array.c:9797:15: style: Variable 'args.errmsg' is reassigned
a value before the old one has been used. [redundantAssignment]

Source code is

  args.errmsg = errmsg;
  args.errmsg = errmsg_len;

Maybe better code

  args.errmsg = errmsg;
  args.errmsg_len = errmsg_len;

[Bug c++/94957] Compilation slowww for simple code with -O1/2/3 and -g in GCC 8 and 9

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org,
   ||mpolacek at gcc dot gnu.org
Version|unknown |9.0

--- Comment #1 from Jakub Jelinek  ---
Seems var-tracking, we end up with -O2 -g with main containing just debug
stmts,
  # DEBUG BEGIN_STMT
  # DEBUG thisD.212422 => NULL
  # DEBUG thisD.212423 => NULL
  # DEBUG thisD.212424 => NULL
...
  # DEBUG thisD.242421 => NULL
  # DEBUG thisD.212421 => NULL
  return 0;
for those 3 this pointers of the ctor, and var-tracking is quite slow on
that indeed.
Though, code-generation-wise, I think that for these larger arrays we shouldn't
emit
  _1 = >array[0];
  MyObject::MyObject (_1);
  _2 = >array[1];
  MyObject::MyObject (_2);
  _3 = >array[2];
  MyObject::MyObject (_3);
...
  _29997 = >array[29996];
  MyObject::MyObject (_29997);
  _29998 = >array[29997];
  MyObject::MyObject (_29998);
  _2 = >array[29998];
  MyObject::MyObject (_2);
  _3 = >array[2];
  MyObject::MyObject (_3);
but instead just a loop over the array elts initializing them, because e.g. if
everything doesn't get inlined, it will be much shorter.

[Bug c++/94955] [10/11 Regression] ICE in to_wide

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |10.2
Summary|[10 regression] ICE in  |[10/11 Regression] ICE in
   |to_wide |to_wide

--- Comment #3 from Marek Polacek  ---
Started with r10-6527-gaaa26bf496a646778ac861aed124d960b5bf549f.  I can take a
look.

I've set the target to 10.2, but someone might disagree.

[Bug c++/94951] [8/9/10/11 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 48456
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48456=edit
gcc11-pr94951.patch

Untested fix.  It seems just wrong to call the c-family strict_aliasing_warning
for dependent types, we shouldn't query alias sets of dependent types and do
any decisions based on what that gives.

[Bug libstdc++/94936] pmr::synchronized_pool_resource crashes without -pthread

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

--- Comment #2 from Jonathan Wakely  ---
Fixed on master only for now, but backports will come soon.

[Bug libstdc++/94906] memory corruption in std::pmr::monotonic_buffer_resource

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |9.4

--- Comment #3 from Jonathan Wakely  ---
Thanks for the report and identifying the source of the bug.

Fixed on master only for now, but backports will come soon.

[Bug c++/94955] [10 regression] ICE in to_wide

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|WAITING |NEW

[Bug c++/94955] [10 regression] ICE in to_wide

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Created attachment 48455
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48455=edit
testcase

[Bug c++/94955] [10 regression] ICE in to_wide

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Last reconfirmed||2020-05-05
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

[Bug middle-end/4210] should not warn in dead code

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

Summary|should not warning with |should not warn in dead
   |dead code   |code
 CC||msebor at gcc dot gnu.org

--- Comment #34 from Martin Sebor  ---
(In reply to Niels Möller from comment #32)

The front ends can eliminate simple subexpressions (as in '0 ? x >> 32 : x >>
1') but they don't do the same for statements.  Moving the warning from the
front end to some later pass would avoid diagnosing code in those cases (it
would also avoid duplicating the same code between different front ends).  The
earliest is probably gimplify.c.  That would avoid warning on statements
rendered dead as a result of constant expressions (as defined by the language)
but not those whose constant value GCC later propagates from prior assignments,
such as in

  const int zero = 0;

  unsigned 
  shift_dead (unsigned x)
  {
if (zero)
  return x >> 32;
else
  return x >> 1;
  }

The later the warning is moved the more statements will be eliminated as dead,
but the more other transformations will also be applied that might eliminate
the warning where it might be desirable, or perhaps even introduce it where it
wouldn't be issued otherwise.

[Bug c++/94957] New: Compilation slowww for simple code with -O1/2/3 and -g in GCC 8 and 9

[hehaochen at hotmail dot com]

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

Bug ID: 94957
   Summary: Compilation slowww for simple code with -O1/2/3 and -g
in GCC 8 and 9
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hehaochen at hotmail dot com
  Target Milestone: ---

code:

-

class MyObject
{
public:
MyObject() {}
};

class MyClassSlow
{
MyObject array[3] {}; 
};


int main()
{
MyClassSlow slow;
}

-


run : 
   g++ -Ox -g -std=c++11 test.cpp
in
  gcc-7 gcc-8 gcc-9 with -O1/2/3 -g


#
##
##   Hangs "forever"
##   gcc version 9.2.0 (GCC)
##
#

  -O3

real0m1.299s
user0m0.910s
sys 0m0.197s

  -O3 -g

Forever... (kill after 15min)


#
##
##   Hangs "forever"
##   gcc version 8.2.0 (GCC)
##
#

  -O3

real0m1.434s
user0m1.062s
sys 0m0.229s

  -O2 -g

Forever... (kill after 15min)

#
##
## Acceptable but still slow in
##   gcc version 7.4.0 (GCC)
##
#


  -O0 -g 

real0m 3.892s
user0m 3.404s
sys 0m 0.482s


  -O1 -g

real1m 6.103s
user1m 5.718s
sys 0m 0.302s


  -O2 -g

real1m 23.666s
user1m 23.310s
sys 0m 0.280s


  -O3

real0m 1.451s
user0m 1.229s
sys 0m 0.221s

  -O3 -g

real1m 19.463s
user1m 19.037s
sys 0m 0.349s


Execution times (seconds)
 phase opt and generate  :  84.89 (99%) usr   1.88 (90%) sys  86.89 (99%) wall 
139631 kB (65%) ggc
 trivially dead code :  82.12 (96%) usr   0.00 ( 0%) sys  82.26 (94%) wall 
 0 kB ( 0%) ggc



#
##
## OK in clang
##
#

clang version 9.0.0-svn366056

root@c5c7aa8003d9:/downloads# time  clang++-9 -O3 -g test.cpp

  real0m 0.176s
  user0m 0.103s
  sys 0m 0.073s

root@c5c7aa8003d9:/downloads# time  clang++-9 -O3 test.cpp

  real0m 0.165s
  user0m 0.102s
  sys 0m 0.063s

[Bug tree-optimization/94956] Unable to remove impossible ffs() test for zero

[steinar+gcc at gunderson dot no]

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

--- Comment #1 from Steinar H. Gunderson  ---
Sorry, truncated the assembler. GCC's is:

atum17:~> objdump --disassemble test.o  

test.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   0f bc ffbsf%edi,%edi
   3:   b8 ff ff ff ff  mov$0x,%eax
   8:   0f 45 c7cmovne %edi,%eax
   b:   c3  retq   
atum17:~>

[Bug tree-optimization/94956] New: Unable to remove impossible ffs() test for zero

[steinar+gcc at gunderson dot no]

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

Bug ID: 94956
   Summary: Unable to remove impossible ffs() test for zero
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: steinar+gcc at gunderson dot no
  Target Milestone: ---

Hi,

Given GCC 10 x86-64, and this code:

#include 
#include 

int foo(uint32_t x) {
if (x == 0) __builtin_unreachable();
return ffs(x) - 1;
}

I get this assembler:

atum17:~> gcc-10 -O2 -c test.c 
atum17:~> objdump --disassemble test.o

The cmovne test is rather expensive for me due to high instruction latency,and
I can never have zero in my situation. (It costs ~10% in a much larger graph
algorithm.) I'm unable to get GCC to understand that it doesn't need it, save
for using an explicit asm statement.

By contrast, Clang 10 gets this right:

atum17:~> clang-10 -O2 -c test.c
atum17:~> objdump --disassemble test.o

test.o: file format elf64-x86-64


Disassembly of section .text:

 :
   0:   0f bc c7bsf%edi,%eax
   3:   c3  retq   

Is it possible to get access to the raw instruction by some clever means? :-)

[Bug c++/94955] [10 regression] ICE in to_wide

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Can you provide the .ii file too?

[Bug c++/94955] New: ICE in to_wide

[hubicka at gcc dot gnu.org]

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

Bug ID: 94955
   Summary: ICE in to_wide
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48454
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48454=edit
proposed patch

This was reported to me by Mark Williams (who also did the testcase and
proposed patch)

% g++ -std=gnu++17 bug.ii -S -o bug.s
bug.ii: In function �void d()�:
bug.ii:6:32: internal compiler error: in sign_mask, at wide-int.h:855
6 | void d() { short e = e >> b::c(); }
  |^
0xa56be2 generic_wide_int >::sign_mask()
const
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/wide-int.h:855
0xa56be2 bool wi::neg_p >
>(generic_wide_int > const&, signop)
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/wide-int.h:1836
0xa56be2 tree_int_cst_sgn(tree_node const*)
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/tree.c:7386
0x1065e85 cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/typeck.c:5613
0xfa9629 build_new_op_1
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/call.c:6501
0xfa931d build_new_op(op_location_t const&, tree_code, int, tree_node*,
tree_node*, tree_node*, tree_node**, int)
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/call.c:6547
0x106267f build_x_binary_op(op_location_t const&, tree_code, tree_node*,
tree_code, tree_node*, tree_code, tree_node**, int)
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/typeck.c:4248
0x10162f0 cp_parser_binary_expression
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:9684
0x10157a4 cp_parser_assignment_expression
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:9824
0x1015380 cp_parser_constant_expression
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:10118
0x1015380 cp_parser_initializer_clause
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:23148
0x1015380 cp_parser_initializer
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:23086
0x1008ab0 cp_parser_init_declarator
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:20780
0x1006144 cp_parser_simple_declaration
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:13689
0x101df42 cp_parser_declaration_statement
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:13121
0x101a67c cp_parser_statement
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:11434
0x101a38a cp_parser_statement_seq_opt
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:11800
0x101a38a cp_parser_compound_statement
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:11750
0x101a0f9 cp_parser_function_body
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:22992
0x101a0f9 cp_parser_ctor_initializer_opt_and_function_body
/home/engshare/third-party2/gcc/9.x/src/gcc-10.x/gcc/cp/parser.c:23043

The problem was that it had previously used fold_for_warn to find an
INTEGER_CST, and assumed the cp_fold_rvalue would too. But fold_for_warn
handles some edge cases that cp_fold_rvalue does not, and in this case we end
up with a NOP_EXPR instead of the INTEGER_CST

[Bug tree-optimization/94921] Failure to optimize nots with sub into single add

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 48453
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48453=edit
gcc11-pr94921.patch

Untested fix.

[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre

[segher at gcc dot gnu.org]

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

--- Comment #19 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #18)
> Created attachment 48451 [details]
> gcc11-pr94873.patch
> 
> Untested patch then.

This one-liner is pre-approved.  Thank you!

[Bug c++/94807] Inconsistency in lambda instantiation

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed 733195e367d, adjusted instantiation to set the name.

[Bug target/94954] Wrong code generation for vec_pack_to_short_fp32 builtin for Power

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
   Keywords||wrong-code
 CC||segher at gcc dot gnu.org
 Ever confirmed|0   |1
 Target||powerpc*-*-*
   Last reconfirmed||2020-05-05
 Status|UNCONFIRMED |NEW

--- Comment #1 from Bill Schmidt  ---
Confirmed.

[Bug target/94954] New: Wrong code generation for vec_pack_to_short_fp32 builtin for Power

[wschmidt at gcc dot gnu.org]

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

Bug ID: 94954
   Summary: Wrong code generation for vec_pack_to_short_fp32
builtin for Power
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wschmidt at gcc dot gnu.org
  Target Milestone: ---

This builtin was mis-implemented.  It is supposed to pack 32-bit floating-point
values into 16-bit floating-point form.  Instead, the values are converted to
unsigned 16-bit integer form.  This should be fixed in all supported releases.

[Bug rtl-optimization/94516] [10 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11 Regression] gnutls   |[10 Regression] gnutls test
   |test ./psk-file fails since |./psk-file fails since
   |r10-7515-g2c0fa3ecf70d199af |r10-7515-g2c0fa3ecf70d199af
   |18785702e9e0548fd3ab793 |18785702e9e0548fd3ab793

--- Comment #16 from Jakub Jelinek  ---
Should be fixed on the trunk now, unsure about backporting yet, time will tell.

[Bug c++/94953] New: A lot of false maybe-uninitialized warnings with O3

[olaf.krzikalla at dlr dot de]

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

Bug ID: 94953
   Summary: A lot of false maybe-uninitialized warnings with O3
   Product: gcc
   Version: 9.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: olaf.krzikalla at dlr dot de
  Target Milestone: ---

See https://godbolt.org/z/nh2gJ9

The warnings only appear with -O3. They only appear for 7<=Blocksize<=16.
They disappear, if you comment out line 32, which is unrelated to
oldDestinationCache.
I'd like to know what is going on here.

[Bug rtl-optimization/94516] [10/11 Regression] gnutls test ./psk-file fails since r10-7515-g2c0fa3ecf70d199af18785702e9e0548fd3ab793

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-87-gd44f14ccef831d90feb57fab56bc3389d543ffdd
Author: Jakub Jelinek 
Date:   Tue May 5 16:34:51 2020 +0200

csa, postreload: Improve csa after recent cselib changes [PR94516]

This patch addresses a missed optimization caused by the cselib changes.
Already in the past postreload could replace sp = sp + const_int with
sp = regxy if regxy already has the right value, but with the cselib
changes it happens several times more often.  It can result in smaller
code, so it seems undesirable to prevent such optimizations, but
unfortunately it can get into the way of stack adjustment coalescing,
where e.g. if we used to have sp = sp + 32; sp = sp - 8;, previously
we'd turn that into sp = sp + 24;, but now postreload optimizes
into sp = r12; sp = sp - 8; and csa gives up.

The patch just adds a REG_EQUAL note when changing sp = sp + const into
sp = reg, where we remember it was actually a stack adjustment by certain
constant, and the combine-stack-adj changes than make use of those
REG_EQUAL
notes, together with LR tracking (csa did enable the note problem, just
didn't simulate each insn) so that we can add the needed clobbers etc.
(taken from the other stack adjustment insn).

2020-05-05  Jakub Jelinek  

PR rtl-optimization/94516
* postreload.c (reload_cse_simplify): When replacing sp = sp +
const
with sp = reg, add REG_EQUAL note with sp + const.
* combine-stack-adj.c (try_apply_stack_adjustment): Change return
type from int to bool.  Add LIVE and OTHER_INSN arguments.  Undo
postreload sp = sp + const to sp = reg optimization if needed and
possible.
(combine_stack_adjustments_for_block): Add LIVE argument.  Handle
reg = sp insn with sp + const REG_EQUAL note.  Adjust
try_apply_stack_adjustment caller, call
df_simulate_initialize_forwards and df_simulate_one_insn_forwards.
(combine_stack_adjustments): Allocate and free LIVE bitmap,
adjust combine_stack_adjustments_for_block caller.

[Bug c++/94799] [8/9/10 Regression] Calling a member template function fails

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression] Calling
   |Calling a member template   |a member template function
   |function fails  |fails

--- Comment #8 from Marek Polacek  ---
Fixed on trunk so far.  I plan to backport it to 10.2, maybe 9 too.

[Bug c++/94799] [8/9/10/11 Regression] Calling a member template function fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

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

commit r11-86-gef3479afc5ab415f00a53fc6f6a990df7f6a0747
Author: Marek Polacek 
Date:   Tue Apr 28 22:30:44 2020 -0400

c++: Member template function lookup failure [PR94799]

Whew, this took a while.  We fail to parse "p->template A::a()"
(where p is of type A *) because since r249752 we treat the RHS of the
->
as dependent and avoid a lookup in the enclosing context: since that rev
cp_parser_template_name checks parser->context->object_type too, which
here is unknown_type_node, signalling a type-dependent object:

 7756   if (dependent_p)
 7757 /* Tell cp_parser_lookup_name that there was an object, even
though it's
 7758type-dependent.  */
 7759 parser->context->object_type = unknown_type_node;

with which cp_parser_template_name returns identifier 'A',
cp_parser_class_name
then creates a TEMPLATE_ID_EXPR A, but then

23735   decl = make_typename_type (scope, decl, tag_type, tf_error);

in cp_parser_class_name fails because scope is NULL.  Then we return
error_mark_node and parse errors ensue.

I've tried various approaches, e.g. keeping TEMPLATE_ID_EXPR around
instead of calling make_typename_type, which didn't work, whereupon I
realized that since we don't want to perform name lookup if we've seen
the template keyword and the scope is dependent, we can adjust
parser->context->object_type and use the type of the object expression
as the scope, even if it's type-dependent.  This should be in line with
[basic.lookup.classref]p4.  If the postfix expression doesn't have a type,
use typeof to carry its type.  This typeof will be processed in
tsubst/TYPENAME_TYPE.

PR c++/94799
* parser.c (cp_parser_postfix_dot_deref_expression): If we have
a type-dependent object of class type, stash it to
parser->context->object_type.  If the postfix expression doesn't
have
a type, use typeof.
(cp_parser_class_name): Consider object scope too.
(cp_parser_lookup_name): Remove code dealing with the case when
object_type is unknown_type_node.

* g++.dg/lookup/this1.C: Adjust dg-error.
* g++.dg/template/lookup12.C: New test.
* g++.dg/template/lookup13.C: New test.
* g++.dg/template/lookup14.C: New test.
* g++.dg/template/lookup15.C: New test.

[Bug c++/90749] [8/9/10/11 Regression] ICE in enclosing_instantiation_of, at cp/pt.c:13462

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Fixed on trunk by r11-17-g82d5decef38b5562d97c49a70ca2636a08769dbc

[Bug gcov-profile/93623] No need to dump gcdas when forking

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:811b7636cb8c10f1a550a76242b5666c7ae36da2

commit r11-85-g811b7636cb8c10f1a550a76242b5666c7ae36da2
Author: Martin Liska 
Date:   Tue May 5 16:15:47 2020 +0200

Remove __gcov_flush.

PR gcov-profile/93623
* tree-cfg.c (stmt_can_terminate_bb_p): Update comment to reflect
reality.
PR gcov-profile/93623
* Makefile.in: Remove __gcov_flush.
* gcov.h (__gcov_flush): Remove.
* libgcov-interface.c (__gcov_flush): Remove.
(init_mx): Use renamed mutex.
(__gcov_lock): Likewise.
(__gcov_unlock): Likewise.
(__gcov_fork): Likewise.
(__gcov_flush): Remove.

[Bug gcov-profile/93623] No need to dump gcdas when forking

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-84-gc0532db47d092430f8e8f497b2dc53343527bb13
Author: Martin Liska 
Date:   Tue May 5 16:15:46 2020 +0200

Use __gcov_dump and __gcov_reset in execv and fork context.

PR gcov-profile/93623
* libgcov-interface.c (__gcov_fork): Do not flush
and reset only in child process.
(__gcov_execl): Dump counters only and reset them
only if exec* fails.
(__gcov_execlp): Likewise.
(__gcov_execle): Likewise.
(__gcov_execv): Likewise.
(__gcov_execvp): Likewise.
(__gcov_execve): Likewise.

[Bug gcov-profile/93623] No need to dump gcdas when forking

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-83-gd39f7dc8d558ca31a661b02d08ff090ce65e6652
Author: Martin Liska 
Date:   Tue May 5 16:15:45 2020 +0200

Do locking for __gcov_dump and __gcov_reset as well.

PR gcov-profile/93623
* Makefile.in: Add _gcov_lock_unlock to LIBGCOV_INTERFACE.
* libgcov-interface.c (ALIAS_void_fn): Remove.
(__gcov_lock): New.
(__gcov_unlock): New.
(__gcov_flush): Use __gcov_lock and __gcov_unlock.
(__gcov_reset): Likewise.
(__gcov_dump): Likewise.
* libgcov.h (__gcov_lock): New declaration.
(__gcov_unlock): Likewise.

[Bug gcov-profile/93623] No need to dump gcdas when forking

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Liška  ---
Fixed on master.

[Bug tree-optimization/90591] Avoid unnecessary data transfer out of OMP construct

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus  ---
Somewhat related: In terms of OpenMP (to be refined in the spec), the following
applies (in order to work both with shared + nonshared memory):

  int x = 5;
  #pragma omp target map(from:x)
x = 7;
  printf("%f\n", x);

This code is invalid – which means that the compiler could use this for
optimization and it probably should warn that "x" is used uninitialized.

[Bug driver/94330] No warning if jobserver not available

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
Fixed on master.

[Bug driver/94330] No warning if jobserver not available

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:0f62caf58b5d11f375f789385d6d49891ebd9a94

commit r11-81-g0f62caf58b5d11f375f789385d6d49891ebd9a94
Author: Martin Liska 
Date:   Tue May 5 16:11:33 2020 +0200

Provide warning for missing jobserver.

PR driver/94330
* lto-wrapper.c (run_gcc): When using -flto=jobserver,
report warning when the jobserver is not detected.

[Bug gcov-profile/94636] gcov should and could output overall coverage. This is just a 2 code lines change.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on master.

[Bug gcov-profile/94636] gcov should and could output overall coverage. This is just a 2 code lines change.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-79-gab37baa60ef287c0f5ba9eaa067aa3192b9fb37e
Author: Martin Liska 
Date:   Fri Apr 17 17:19:12 2020 +0200

gcov: print total_lines summary for all files.

gcc/ChangeLog:

2020-04-17  Martin Liska  

PR gcov-profile/94636
* gcov.c (main): Print total lines summary at the end.
(generate_results): Expect file_name always being non-null.
Print newline after intermediate file is printed in order to align
with
what we do for normal files.

[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses

[marxin at gcc dot gnu.org]

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

Bug 92472 Summary: enhancement: 5 * constify some parameters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92472

   What|Removed |Added

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

[Bug other/89860] liboffloadmic/runtime/offload_target.cpp:332]: (style) Array index 'i' is used before limits check.

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
Fixed on master.

[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses

[marxin at gcc dot gnu.org]

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

Bug 89860 Summary: liboffloadmic/runtime/offload_target.cpp:332]: (style) Array 
index 'i' is used before limits check.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89860

   What|Removed |Added

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

[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations

[amonakov at gcc dot gnu.org]

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

--- Comment #4 from Alexander Monakov  ---
> Why is it missing the static keyword then? (Or alternatively, why isn't it in 
> an anonymous namespace?)

Huh? Without the warning developers may simply forget to put the 'static'
keyword. With the warning they would be reminded when bootstrapping the patch.


> Ah, I like the namespace thing for target hooks (possibly langhooks as well).

Sure, it's nice to have sensible namespace rules for future additions, but
hopefully that's not a reason/excuse to never re-enable the warning.

[Bug c/92472] enhancement: 5 * constify some parameters

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
 CC||marxin at gcc dot gnu.org

--- Comment #5 from Martin Liška  ---
I hope all pieces are fixed now.

[Bug other/89863] [meta-bug] Issues in gcc that other static analyzers (cppcheck, clang-static-analyzer, PVS-studio) find that gcc misses

[marxin at gcc dot gnu.org]

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

Bug 92565 Summary: trunk/libgcc/config/libbid/bid_internal.h: 2 * useless 
assignments ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92565

   What|Removed |Added

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

[Bug libgcc/92565] trunk/libgcc/config/libbid/bid_internal.h: 2 * useless assignments ?

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Fixed on master.

[Bug c/92472] enhancement: 5 * constify some parameters

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:03f9754665b889e0988d0392db1eb35e91b97693

commit r11-76-g03f9754665b889e0988d0392db1eb35e91b97693
Author: Martin Liska 
Date:   Tue Feb 4 14:55:25 2020 +0100

Use const for template argument.

libstdc++-v3/ChangeLog:

2020-02-04  Martin Liska  

PR c/92472
* include/parallel/multiway_merge.h:
Use const for _Compare template argument.

[Bug other/89860] liboffloadmic/runtime/offload_target.cpp:332]: (style) Array index 'i' is used before limits check.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:98f7381d17a1ad47773b70a5de7d94a164357916

commit r11-75-g98f7381d17a1ad47773b70a5de7d94a164357916
Author: Martin Liska 
Date:   Tue Feb 4 14:57:59 2020 +0100

Put index check before use.

liboffloadmic/ChangeLog:

2020-02-04  Martin Liska  

PR other/89860
* runtime/offload_target.cpp: Put index check
before its use.

[Bug c/92472] enhancement: 5 * constify some parameters

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

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

commit r11-74-gd73d45f19180a474b1bd3af3c9cdf52da3bafc78
Author: Martin Liska 
Date:   Tue Feb 4 14:55:14 2020 +0100

Use const for some function arguments.

gcc/ChangeLog:

2020-02-04  Martin Liska  

PR c/92472
* alloc-pool.h: Use const for some arguments.
* bitmap.h: Likewise.
* mem-stats.h: Likewise.
* sese.h (get_entry_bb): Likewise.
(get_exit_bb): Likewise.

[Bug libgcc/92565] trunk/libgcc/config/libbid/bid_internal.h: 2 * useless assignments ?

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:8b33430b53b2a884f177f1d9b40ed840e07240c5

commit r11-73-g8b33430b53b2a884f177f1d9b40ed840e07240c5
Author: Martin Liska 
Date:   Tue Feb 4 14:54:51 2020 +0100

Remove 2 dead variables in bid_internal.h.

libgcc/config/libbid/ChangeLog:

2020-02-04  Martin Liska  

PR libgcc/92565
* bid_internal.h (handle_UF_128_rem): Remove unused variable.
(handle_UF_128): Likewise.

[Bug c++/94951] [8/9/10/11 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/94951] [8/9/10/11 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
And the array isn't needed either:
struct A { int a; };
template 
struct B : public A
{
  static B foo () { B t; t.a = 4; return t; }
};

[Bug c++/94951] [8/9/10/11 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Slightly simplified testcase:
struct A { unsigned a[32]; };
template 
struct B : public A
{
  static B foo () { B t; t.a[0] = 4; return t; }
};

[Bug c++/94951] [8/9/10/11 Regression] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |8.5
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
Summary|dereferencing type-punned   |[8/9/10/11 Regression]
   |pointer will break  |dereferencing type-punned
   |strict-aliasing rules when  |pointer will break
   |using super class for a |strict-aliasing rules when
   |template type   |using super class for a
   ||template type

--- Comment #2 from Jakub Jelinek  ---
Started with r7-755-g23cb72663051cd3f5a8952d4aa2186d50243b7d0

[Bug tree-optimization/92177] [10 Regression] gcc.dg/vect/bb-slp-22.c FAILs

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.0
Summary|[10/11 regression]  |[10 Regression]
   |gcc.dg/vect/bb-slp-22.c |gcc.dg/vect/bb-slp-22.c
   |FAILs   |FAILs
  Known to work||11.0

--- Comment #10 from Richard Biener  ---
Fixed on trunk (hopefully).

[Bug tree-optimization/92177] [10/11 regression] gcc.dg/vect/bb-slp-22.c FAILs

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-71-g3fbf43b9bc060e2904abe64e870868b9a4bfce13
Author: Richard Biener 
Date:   Tue May 5 15:38:24 2020 +0200

testsuite/92177 - adjust expected patterns for gcc.dg/vect/bb-slp-22.c

We now always vectorize two BBs, adjust the selector to also scan
for integer multiplication vectorization explicitely.

2020-05-05  Richard Biener  

PR testsuite/92177
* gcc.dg/vect/bb-slp-22.c: Adjust.

[Bug target/94743] IRQ handler doesn't save scratch VFP registers

[clyon at gcc dot gnu.org]

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

--- Comment #16 from Christophe Lyon  ---
Another potential issue just came to my mind: what if the IRQ handler is
compiled with -mfloat-abi=soft but calls a function compiled with
-mfloat-abi=softfp? We have no way to guess that the FP registers can be
clobbered when compiling the handler.

[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Alexander Monakov from comment #0)
> > Transition to C++ did not change -Wmissing-prototypes to
> > -Wmissing-declarations, so over time several violations crept in. In
> > particular this penalizes optimization during non-LTO bootstrap (the
> > compiler has to assume the function might be used in another TU, even though
> > in reality all uses are in current file and it simply misses the 'static'
> > keyword).
> 
> Why is it missing the static keyword then? (Or alternatively, why isn't it
> in an anonymous namespace?)
> 
> 
> (In reply to Alexander Monakov from comment #1)
> > Another reason to have -Wmissing-declarations is that otherwise mismatches
> > of unused functions are not caught until it's too late (mismatching
> > definition is assumed to be an overload of the function declared in the
> > header file).
> 
> A more robust way to avoid that problem is to declare the function in a
> namespace, and define it using a qualified name:
> 
> // declaration
> namespace targ
> {
>   void foo(void*);
> }
> 
> // definition
> void targ::foo(class vec_info*);  // ERROR
> 
> Because no foo with that signature was declared in namespace targ it's an
> error, not just a warning.
> 
> Should the coding convention be adjusted to avoid this problem?

Ah, I like the namespace thing for target hooks (possibly langhooks as well).

[Bug bootstrap/91972] Bootstrap should use -Wmissing-declarations

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Alexander Monakov from comment #0)
> Transition to C++ did not change -Wmissing-prototypes to
> -Wmissing-declarations, so over time several violations crept in. In
> particular this penalizes optimization during non-LTO bootstrap (the
> compiler has to assume the function might be used in another TU, even though
> in reality all uses are in current file and it simply misses the 'static'
> keyword).

Why is it missing the static keyword then? (Or alternatively, why isn't it in
an anonymous namespace?)


(In reply to Alexander Monakov from comment #1)
> Another reason to have -Wmissing-declarations is that otherwise mismatches
> of unused functions are not caught until it's too late (mismatching
> definition is assumed to be an overload of the function declared in the
> header file).

A more robust way to avoid that problem is to declare the function in a
namespace, and define it using a qualified name:

// declaration
namespace targ
{
  void foo(void*);
}

// definition
void targ::foo(class vec_info*);  // ERROR

Because no foo with that signature was declared in namespace targ it's an
error, not just a warning.

Should the coding convention be adjusted to avoid this problem?

[Bug tree-optimization/92177] [10/11 regression] gcc.dg/vect/bb-slp-22.c FAILs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #8 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #7 from Richard Biener  ---
[...]
> which means we are actually vectorizing a multiplication.  Like with
> the following.  Rainer - can you test this?
[...]
Works for me: tested on sparc-sun-solaris2.11 (32 and 64-bit) and (to
verify that I didn't mess up the mangled patch) on i386-pc-solaris2.11.

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[tnfchris at gcc dot gnu.org]

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

--- Comment #43 from Tamar Christina  ---
Oh, that was quick, thanks! I was looking at the log for another commit against
this PR so missed it :)

[Bug ipa/94947] [8/9/10 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression]
   |-fipa-pta + pthread_once|-fipa-pta + pthread_once
   |crash since |crash since
   |r6-5684-g47e5754e17e9ac3b   |r6-5684-g47e5754e17e9ac3b
  Known to work||11.0
  Known to fail|11.0|10.0

--- Comment #6 from Richard Biener  ---
Fixed on trunk sofar.

[Bug ipa/94947] [8/9/10/11 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-70-gf9b5db750bc7fbba69fee93564907f7da1bca35f
Author: Richard Biener 
Date:   Tue May 5 13:09:50 2020 +0200

ipa/94947 - fix test for externally visible variables for IPA PTA

This fixes lack of an escape point of externally declared variables.

2020-05-05  Richard Biener  

PR ipa/94947
* tree-ssa-structalias.c (ipa_pta_execute): Use
varpool_node::externally_visible_p ().
(refered_from_nonlocal_var): Likewise.

* gcc.dg/torture/pr94947-1.c: New testcase.
* gcc.dg/torture/pr94947-2.c: Likewise.

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[rguenther at suse dot de]

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

--- Comment #42 from rguenther at suse dot de  ---
On Tue, 5 May 2020, tnfchris at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39612
> 
> Tamar Christina  changed:
> 
>What|Removed |Added
> 
>  CC||tnfchris at gcc dot gnu.org
> 
> --- Comment #41 from Tamar Christina  ---
> Hi Richi,
> 
> This patch f9e1ea10e657 seems to be causing miscompares in the GCC benchmark 
> in
> SPEC2017.
> 
> I haven't tried to produce a reproducer yet but could if that's needed.

PR94949 (already fixed)

[Bug tree-optimization/39612] [8/9 Regression] LIM inserts loads from uninitialized local memory

[tnfchris at gcc dot gnu.org]

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tnfchris at gcc dot gnu.org

--- Comment #41 from Tamar Christina  ---
Hi Richi,

This patch f9e1ea10e657 seems to be causing miscompares in the GCC benchmark in
SPEC2017.

I haven't tried to produce a reproducer yet but could if that's needed.

[Bug c++/94951] dereferencing type-punned pointer will break strict-aliasing rules when using super class for a template type

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Keywords||diagnostic
   Last reconfirmed||2020-05-05

--- Comment #1 from Richard Biener  ---
We're warning via

#0  warning_at (location=426247, opt=664, 
gmsgid=0x2a36f08 "dereferencing type-punned pointer will break
strict-aliasing rules") at ../../src/trunk/gcc/diagnostic.c:1442
#1  0x00e324c9 in strict_aliasing_warning (loc=426247, 
type=, expr=)
at ../../src/trunk/gcc/c-family/c-warn.c:729
#2  0x00d45def in cp_build_indirect_ref_1 (loc=426535, 
ptr=, errorstring=RO_NULL, complain=3, 
do_fold=true) at ../../src/trunk/gcc/cp/typeck.c:3364
#3  0x00d46191 in cp_build_fold_indirect_ref (
pointer=) at ../../src/trunk/gcc/cp/typeck.c:3444
#4  0x009ecb7a in build_base_path (code=PLUS_EXPR, 
expr=, binfo=, 
nonnull=1, complain=3) at ../../src/trunk/gcc/cp/class.c:513
#5  0x00d4309f in build_class_member_access_expr (object=..., 
member=, 
access_path=, preserve_reference=false, 
complain=3) at ../../src/trunk/gcc/cp/typeck.c:2603
#6  0x00d45377 in finish_class_member_access_expr (object=..., 
name=, template_p=false, 
complain=3) at ../../src/trunk/gcc/cp/typeck.c:3209

[Bug tree-optimization/94921] Failure to optimize nots with sub into single add

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug middle-end/94940] [10/11 Regression] spurious -Warray-bounds for a zero length array member of union since r10-4300-g49fb45c81f4ac068

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
I think array_at_struct_end_p conservatively returns true for p->a[i] though.
Indeed all calls to the function return the correct value.  So is it somebody
invented a "more clever" variant of said check?  Or do we simply fail to call
it?  Ok, more clever it is:

bool
vrp_prop::check_array_ref (location_t location, tree ref,
   bool ignore_off_by_one)
{
...
  if (!up_bound
  || TREE_CODE (up_bound) != INTEGER_CST
  || (warn_array_bounds < 2
  && array_at_struct_end_p (ref)))
{
...
  const bool compref = TREE_CODE (arg) == COMPONENT_REF;
  if (compref)
{
  /* Try to determine the size of the trailing array from
 its initializer (if it has one).  */
  if (tree refsize = component_ref_size (arg, _zero_len))
if (TREE_CODE (refsize) == INTEGER_CST)
  maxbound = refsize;

and refsize == 0 here.  Parsing an initializer for a union is tricky but
this one clearly gets the wrong answer from that.

[Bug ipa/94947] [8/9/10/11 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug ipa/94947] [8/9/10/11 Regression] -fipa-pta + pthread_once crash since r6-5684-g47e5754e17e9ac3b

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
(In reply to Richard Biener from comment #3)
> In fact this situation doesn't seem to be handled at all - global variables
> are still an afterthought in IPA-PTA it seems.  Needs more work than a
> simple fix.

Hum, actually it's a simple bug and the following fixes it.

diff --git a/gcc/tree-ssa-structalias.c b/gcc/tree-ssa-structalias.c
index 416a26c996c..16a2b53c2b7 100644
--- a/gcc/tree-ssa-structalias.c
+++ b/gcc/tree-ssa-structalias.c
@@ -8187,8 +8187,8 @@ ipa_pta_execute (void)

   /* For the purpose of IPA PTA unit-local globals are not
  escape points.  */
-  bool nonlocal_p = (var->used_from_other_partition
-|| var->externally_visible
+  bool nonlocal_p = (var->externally_visible_p ()
+|| var->used_from_other_partition
 || var->force_output);
   var->call_for_symbol_and_aliases (refered_from_nonlocal_var,
_p, true);

[Bug target/94950] [8/9/10/11 regression] ICE in gcc.dg/pr94780.c on riscv64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 regression] ICE in  |[8/9/10/11 regression] ICE
   |gcc.dg/pr94780.c on riscv64 |in gcc.dg/pr94780.c on
   ||riscv64
   Target Milestone|--- |8.5

[Bug target/94950] [8/9/10 regression] ICE in gcc.dg/pr94780.c on riscv64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested obvious fix, but I have no way to actually test this myself except for
the testcase (which got fixed).

[Bug tree-optimization/94949] [11 Regression] Wrong code for couple of SPEC benchmarks since r11-39-gf9e1ea10e657af9f

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Biener  ---
Fixed.