[Bug target/93182] [avr] Add -nodevicespecs option.

[gjl at gcc dot gnu.org]

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

Georg-Johann Lay  changed:

   What|Removed |Added

 Target||avr
   Priority|P3  |P5

[Bug target/93182] New: [avr] Add -nodevicespecs option.

[gjl at gcc dot gnu.org]

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

Bug ID: 93182
   Summary: [avr] Add -nodevicespecs option.
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Currently, self-specs include device-specs/specs- no matter what, i.e.
that specs file will always override specs from -specs=. The new option omits
device-specs so that no specs from the user are overridden. 

In addition, bypassing device-specs allows specifying a custom device specs
file without to set -B. 7

[Bug c++/93048] ICE in verify_gimple

[pilarlatiesa at gmail dot com]

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

--- Comment #5 from Pilar Latiesa  ---
(In reply to Arseny Solokha from comment #3)
> It is likely a duplicate of PR93033.

It is certainly related. The fix for that PR made that all of the provided
testcases compile with yesterday spapshot (20200106).

However, this code still exhibits the problem:

#include 

template
struct TTensor
{
  TTensor DatArr[d];
};

template
struct TTensor
{
  double Dat;
};

template
struct TCoefs
{
  double aP;
  std::valarray aF;
  TTensor b;
};


template
class TExpr
{
public:
  TCoefs
  CalcCoefs() const;
};

template
TCoefs
TExpr::CalcCoefs() const
{
  double aP = 0.0;
  std::valarray aF;
  TTensor b = {};

  return {aP, aF, b};
}

int main()
{
  TExpr<2, 2> foo;

  auto bar = foo.CalcCoefs();

  return 0;
}

[Bug fortran/93162] [10 Regression] gcc/fortran/trans-openmp.c:2469:50: runtime error: load of value 145992800, which is not a valid value for type 'ar_type' since r279628

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Should be fixed now.

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[jakub at gcc dot gnu.org]

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

Bug 93162 Summary: [10 Regression] gcc/fortran/trans-openmp.c:2469:50: runtime 
error: load of value 145992800, which is not a valid value for type 'ar_type' 
since r279628
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93162

   What|Removed |Added

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

[Bug tree-optimization/92819] [10 Regression] Worse code generated on avx2 due to simplify_vector_constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Blocks||92822

--- Comment #9 from Richard Biener  ---
Similar issue in PR92822 for arm


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92822
[Bug 92822] [10 Regression] vfma_laneq_f32 and vmul_laneq_f32 are broken on
aarch64 after r278938

[Bug fortran/93162] [10 Regression] gcc/fortran/trans-openmp.c:2469:50: runtime error: load of value 145992800, which is not a valid value for type 'ar_type' since r279628

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  7 07:14:41 2020
New Revision: 279944

URL: https://gcc.gnu.org/viewcvs?rev=279944&root=gcc&view=rev
Log:
PR fortran/93162
* trans-openmp.c (gfc_trans_omp_clauses): Check for REF_ARRAY type
before testing u.ar.type == AR_FULL.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-openmp.c

[Bug c++/91369] Implement P0784R7: constexpr new

[jakub at gcc dot gnu.org]

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

--- Comment #29 from Jakub Jelinek  ---
Author: jakub
Date: Tue Jan  7 07:13:50 2020
New Revision: 279943

URL: https://gcc.gnu.org/viewcvs?rev=279943&root=gcc&view=rev
Log:
PR c++/91369
* constexpr.c (struct constexpr_global_ctx): Add heap_alloc_count
member, initialize it to zero in ctor.
(cxx_eval_call_expression): Bump heap_dealloc_count when deleting
a heap object.  Don't cache calls to functions which allocate some
heap objects and don't deallocate them or deallocate some heap
objects they didn't allocate.

* g++.dg/cpp1y/constexpr-new.C: Expect an error explaining why
static_assert failed for C++2a.
* g++.dg/cpp2a/constexpr-new9.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/constexpr-new9.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/constexpr.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/cpp1y/constexpr-new.C

[Bug c/93181] New: -Wuninitialized fails to warn about uninitialized value; -Wmaybe-uninitialized should also warn.

[intvnut at gmail dot com]

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

Bug ID: 93181
   Summary: -Wuninitialized fails to warn about uninitialized
value; -Wmaybe-uninitialized should also warn.
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: intvnut at gmail dot com
  Target Milestone: ---

GCC 4.1.2 previously warned about p being used uninitialized in code such as
the following:

#include 

void ub_express(int);
void test(void);

struct foo {
int count;
};

extern struct foo a, b;
struct foo a, b;

void ub_express(int x) {
struct foo *p;
if (x == 1) {
p = &a;
}
if (x == 2) {
p = &b;
}
p->count++;
}

void test(void) {
for (int i = 0; i < 3; ++i) {
ub_express(i);
}
}

https://godbolt.org/z/xd8vsL

:21: warning: 'p' is used uninitialized in this function

With every later version of GCC I tried at Godbolt's compiler explorer up
through 9.2.0 and trunk (and the few I tried locally on my workstation), it no
longer warns.

Furthermore, 4.1.2 only warns if I retain the function 'test', as that
definitely includes a code path where 'p' is used uninitialized.  

It seems like GCC should warn about ub_express() even if 'test' isn't present
according to the description for -Wmaybe-uninitialized.  It's a similar code
pattern to the one that appears in the documentation to -Wmaybe-uninitialized:

{
  int x;
  switch (y)
{
case 1: x = 1;
  break;
case 2: x = 4;
  break;
case 3: x = 5;
}
  foo (x);
}

I've tagged this as 9.1.0 and "C" as this oversight is present in that version,
but I see similar behavior across many GCC versions and in both the C and C++
compilers.

[Bug c++/47877] -fvisibility-inlines-hidden does not hide member template functions

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/82380] [concepts] Error when using requires constraint with attributes

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

--- Comment #9 from Jason Merrill  ---
Fixed by patch for PR 92739.

[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[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 82380, which changed state.

Bug 82380 Summary: [concepts] Error when using requires constraint with 
attributes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82380

   What|Removed |Added

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

[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts

[jason at gcc dot gnu.org]

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

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Tue Jan  7 01:07:59 2020
New Revision: 279936

URL: https://gcc.gnu.org/viewcvs?rev=279936&root=gcc&view=rev
Log:
PR c++/92552 - ICE with inherited constrained default ctor.

We set TYPE_HAS_USER_CONSTRUCTOR on the template type in lookup_using_decl,
but we didn't copy it to the instantiation.  Setting it in
one_inherited_ctor is too late, as that gets called after we decide whether
to set CLASSTYPE_LAZY_DEFAULT_CTOR.  This change affects other testcases as
well; the changes are fixes for the other inherited constructor tests as
well.

* pt.c (instantiate_class_template_1): Copy
TYPE_HAS_USER_CONSTRUCTOR.
* class.c (one_inherited_ctor): Don't set it here.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor7.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/class.c
trunk/gcc/cp/pt.c
trunk/gcc/testsuite/g++.dg/concepts/inherit-ctor3.C
trunk/gcc/testsuite/g++.dg/cpp2a/concepts-inherit-ctor2.C
trunk/gcc/testsuite/g++.dg/template/crash7.C
trunk/gcc/testsuite/g++.old-deja/g++.pt/error2.C

[Bug c++/92739] [10 Regression] Requires clause followed by an attribute no longer compiles

[jason at gcc dot gnu.org]

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

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Tue Jan  7 01:02:06 2020
New Revision: 279935

URL: https://gcc.gnu.org/viewcvs?rev=279935&root=gcc&view=rev
Log:
PR c++/92739 - parsing requires clause with attributes.

gcc/cp/
* parser.c (cp_parser_constraint_requires_parens): Exclude
attributes as postfix expressions.

gcc/testsuite/
* g++.dg/concepts-pr92739.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/cpp2a/concepts-attrib1.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/parser.c

[Bug c/93180] const function pointers placed in a custom section are causing that custom section to become writable

[pskocik at gmail dot com]

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

--- Comment #3 from pskocik at gmail dot com ---
Thanks for explaining. Yes, -fPIC does cause the section to become writable on
clang.

I'm currently toying with using a custom section to gather const
function-pointers, but this -fPIC stuff is causing these const-pointers to be
effectively writable via __start_mysection/__stop_mysection, which is weird.

I thought the const data would get relocated all once at load time and then
become readonly, but it is staying writable with -fPIC.

Anyway, apologies for the false alarm.

Best regards,
Petr Skocik

[Bug c/93180] const function pointers placed in a custom section are causing that custom section to become writable

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
as I mentioned function pointer has nothing to do with it, you can see the
behavior with:
__attribute((__section__("mysection"))) int const cx = -42;
typedef const int *iptr;

__attribute((__section__("mysection")))  const iptr cxptr= & cx;
 CUT 
With -fPIE/-fPIC (which means the relocation needs to be done at runtime and
such), get:
.sectionmysection,"aw",@progbits

With -fno-PIE/-fno-PIC:
.sectionmysection,"a",@progbits

[Bug c/93180] const function pointers placed in a custom section are causing that custom section to become writable

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
It is not about function pointer but rather a pointer in general.  This section
needs runtime relocations (because you are compiling as PIE) so it needs to be
writable.

Your gcc is defaulting to generating PIE programs while your clang is NOT.
You will get the same behavior if you generate the same kind of programs for
both.  Either -fno-PIE for GCC or add -fPIE for clang.

[Bug c/93180] New: const function pointers placed in a custom section are causing that custom section to become writable

[pskocik at gmail dot com]

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

Bug ID: 93180
   Summary: const function pointers placed in a custom section are
causing that custom section to become writable
   Product: gcc
   Version: 7.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

__attribute((__section__("mysection"))) int const cx = -42;

(or with multiple const data variables in the `mysection` section) results in
assembly output containing

.sectionmysection,"a",@progbits

Adding a const function pointer as in

#include 
__attribute((__section__("mysection"))) int (* const p)(char const*) = &puts;

causes the section to be mapped to a writable segment

.sectionmysection,"aw",@progbits

Since the pointer is const, I think the section ought to remain read-only (on
clang it does).

[Bug c++/92552] [10 Regression] internal compiler error: in lazily_declare_fn, at cp/method.c:3045 with -fconcepts

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug libstdc++/91263] unordered_map and unordered_set operator== double key comparison causes exponential behavior

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
No, a==b is equivalent to std::equal(a.begin(), a.end(), b.begin(), b.end())
which doesn't have access to the container's equality predicate.

[Bug libstdc++/91263] unordered_map and unordered_set operator== double key comparison causes exponential behavior

[fdumont at gcc dot gnu.org]

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

François Dumont  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-06
 CC||fdumont at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |fdumont at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from François Dumont  ---
I confirm. I even wonder if there is not a Standard conformity issue here as
keys are supported to be compared using the container provided predicate, the
key type do not necessarily have a == operator.

[Bug c++/60304] Including disables -Wconversion-null in C++ 98 mode

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #25 from Jason Merrill  ---
(In reply to Jonathan Wakely from comment #24)
> I'm still not convinced keeping the "GNU extension" (or historical baggage,
> depending on your point of view) in C++98 for hypothetical compatibility is
> useful.

stdbool.h was not part of C++98, so it even existing in C++98 mode is an
extension.  IMO we should never define the macros for C++.

[Bug middle-end/93076] [10 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cddce

[law at redhat dot com]

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

--- Comment #3 from Jeffrey A. Law  ---
Created attachment 47599
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47599&action=edit
Testcase

[Bug middle-end/93076] [10 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cddce

[law at redhat dot com]

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

--- Comment #4 from Jeffrey A. Law  ---
My bisection points to:

commit ca09820d964b68e165153c6770b4403dece92004
Author: jason 
Date:   Thu Dec 19 14:06:45 2019 +

PR c++/66139 - EH cleanups for partially constructed aggregates.

There were several overlapping PRs about failure to clean up fully
constructed subobjects when an exception is thrown during aggregate
initialization of a temporary.  I fixed this for non-temporaries in the
context of 57510, but that fix didn't handle temporaries.  So this patch
does split_nonconstant_init at gimplification time, which is much smaller
than alternatives I tried.

PR c++/57510
* cp-gimplify.c (cp_gimplify_init_expr): Use
split_nonconstant_init.
* typeck2.c (split_nonconstant_init): Handle non-variable dest.
(split_nonconstant_init_1): Clear TREE_SIDE_EFFECTS.
* tree.c (is_local_temp): New.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@279576
138bc75d-0d04-0410-961f-82ee72b054a4

Just in case we're chasing multiple issues, I'm attaching the testcase from
pybind11.  Compile on x86_64 with -O2.

[Bug tree-optimization/93179] New: [10 Regression] ICE (segfault) in loop_depth on x86_64-linux-gnu

[doko at debian dot org]

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

Bug ID: 93179
   Summary: [10 Regression] ICE (segfault) in loop_depth on
x86_64-linux-gnu
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk r279880, building icu 63.2 on x86_64-linux-gnu (no other
archs), compiler defaulting to hardening defaults. fails with -O1, works with
-O0.

The example isn't completely reduced, however further creduce attempts are
timing out after 300 seconds.

$ cat dtfmttst.ii
class UnicodeString {
public:
  enum EInvariant {};
  UnicodeString(char );
  ~UnicodeString();

private:
public:
};
class DateFormat : UnicodeString {
public:
  enum EStyle {
kNone};
};
UnicodeString CharsToUnicodeString(const char *);
class DateFormatTest {
  void TestNonGregoFmtParse();

public:
private:
private:
};
typedef struct {
  int era;
  int year;
  int month;
  int day;
  int hour;
  int minute;
  UnicodeString formattedDate;
} CalAndFmtTestItem;
typedef struct {
  const char *locale;
  DateFormat::EStyle style;
  UnicodeString pattern;
  const CalAndFmtTestItem *caftItems;
} TestNonGregoItem;
void DateFormatTest::TestNonGregoFmtParse() {
  CalAndFmtTestItem cafti_zh_chinese_custU[] {78, 31, 0, 1, 12, 0, 0};
  TestNonGregoItem items[] {"zh@calendar=chinese", DateFormat::kNone,
CharsToUnicodeString("rU\\u5E74MMMd"),
cafti_zh_chinese_custU};
  TestNonGregoItem *itemPtr;
  for (itemPtr = items; itemPtr->locale != __null; itemPtr++)
;
}

$ g++ -c -std=c++11 -Wall -Wextra -Wpedantic -O1 dtfmttst.ii 
during GIMPLE pass: profile_estimate
dtfmttst.ii: In member function 'void DateFormatTest::TestNonGregoFmtParse()':
dtfmttst.ii:46:1: internal compiler error: Segmentation fault
   46 | }
  | ^
0xbfef43 crash_signal
../../src/gcc/toplev.c:328
0x81d8e6 loop_depth
../../src/gcc/cfgloop.h:529
0x81d8e6 flow_loop_nested_p(loop const*, loop const*)
../../src/gcc/cfgloop.c:66
0x81d8e6 flow_bb_inside_loop_p(loop const*, basic_block_def const*)
../../src/gcc/cfgloop.c:859
0x81d8e6 flow_bb_inside_loop_p(loop const*, basic_block_def const*)
../../src/gcc/cfgloop.c:850
0xd13f34 chain_of_csts_start
../../src/gcc/tree-ssa-loop-niter.c:2883
0xd15764 get_base_for
../../src/gcc/tree-ssa-loop-niter.c:2932
0xd15764 loop_niter_by_eval(loop*, edge_def*)
../../src/gcc/tree-ssa-loop-niter.c:3055
0xb5daed predict_loops
../../src/gcc/predict.c:1988
0xb5eeae tree_estimate_probability(bool)
../../src/gcc/predict.c:3096
0xb5f073 execute
../../src/gcc/predict.c:4034
0xb5f073 execute
../../src/gcc/predict.c:4017
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug target/93178] New: PPC: inefficient 64-bit constant generation if msb is off in low 16 bit

[jens.seifert at de dot ibm.com]

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

Bug ID: 93178
   Summary: PPC: inefficient 64-bit constant generation if msb is
off in low 16 bit
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

Input:
unsigned long long hi16msbon_low16msboff()
{
   return 0x87654321ULL; // expected: li 3,0x4321 ; oris 3,0x8765
}

Command line:
gcc -O2 -maix64 -save-temps const.C

Output:
._Z21hi16msbon_low16msboffv:
LFB..1:
lis 3,0x8765
ori 3,3,0x4321
rldicl 3,3,0,32
blr

[Bug target/93177] New: PPC: Missing many useful platform intrinsics

[memmerto at ca dot ibm.com]

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

Bug ID: 93177
   Summary: PPC: Missing many useful platform intrinsics
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: memmerto at ca dot ibm.com
  Target Milestone: ---

File gcc/config/rs6000/ppu_intrinsics.h defines a lot of useful intrisics for
PPC, but this heading on this file indicates that it is specific to the "Cell
BEA", which is a PPC derivative.

The #define guards at the top of the file suggest that the file was intended
for both ppu (cell) and ppc/ppc64 (PowerPC/POWER) configurations.

It would be very useful if this file could be installed on all powerpc targets,
or perhaps cloned to ppc_intrinsics.h and have that installed on powerpc.

[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

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

--- Comment #15 from David Binderman  ---
Reduced C++ code seems to be:

struct a {
  char b;
};
class c {
public:
  c(c const &);
  ~c();
};
struct d {
  enum e {};
};
struct f {
  c g;
  a h;
  c i;
  d::e j;
};
class k {
  f l;
  k(c const &, a const &, c, d::e);
};
k::k(c const &g, a const &h, c i, d::e j) : l{g, h, i, j} {}

Flag -march=native not required now.

[Bug middle-end/93076] [10 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cddce

[dcb314 at hotmail dot com]

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

Bug 93033 Summary: [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033

   What|Removed |Added

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

[Bug c++/93163] internal compiler error: verify_gimple failed

[dcb314 at hotmail dot com]

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

Bug 93033 Summary: [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033

   What|Removed |Added

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

[Bug c++/93077] [10 Regression] internal compiler error: in hash_operand during GIMPLE pass: fre

[dcb314 at hotmail dot com]

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

Bug 93033 Summary: [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033

   What|Removed |Added

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

[Bug target/93176] New: PPC: inefficient 64-bit constant consecutive ones

[jens.seifert at de dot ibm.com]

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

Bug ID: 93176
   Summary: PPC: inefficient 64-bit constant consecutive ones
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

All 64-bit constants containing a sequence of ones can be constructed with 2
instructions (li/lis + rldicl). gcc creates up to 5 instructions.

Input:
unsigned long long onesLI()
{
   return 0x0000ULL; // expected: li 3,0xFF00 ; rldicl 3,3,0,8
}

unsigned long long onesLIS()
{
   return 0x0000ULL; // expected: lis 3,0xFF00 ; rldicl 3,3,0,8
}

unsigned long long onesHI()
{
   return 0x0000ULL; // expected: lis 3,0x ; rldicl 3,3,8,8
}

Command line:
gcc -O2 -maix64 -save-temps const.C

Output:
._Z6onesLIv:
LFB..2:
lis 3,0xff
ori 3,3,0x
sldi 3,3,32
oris 3,3,0x
ori 3,3,0xff00
blr


._Z7onesLISv:
LFB..3:
lis 3,0xff
ori 3,3,0x
sldi 3,3,32
oris 3,3,0xff00
blr

._Z6onesHIv:
LFB..4:
lis 3,0xff
ori 3,3,0xff00
sldi 3,3,32
blr

[Bug tree-optimization/93156] abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa

[bruno at clisp dot org]

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

--- Comment #10 from Bruno Haible  ---
(In reply to Jakub Jelinek from comment #9)
> So the only thing we should take from the above for the compiler is optimize
> in ccp that x*x has the second least significant bit clear.

If a compiler understands this, I'll change the function as follows:
=
/* Return NULL.  */
static void *
null_ptr (void)
{
  unsigned int x = rand ();
  unsigned long long y = (unsigned long long) x * (unsigned long long) x;
  /* The following statement is equivalent to if (false),
 since a square is always congruent to 0 or 1 mod 3.  */
  if ((y % 3) == 2) {
brick_the_hard_disk ();
return (void *) -1;
  } else
return (void *) 0;
}
=

Now, if you change GCC to handle that, by exploiting Gauss' quadratic
reciprocity law https://en.wikipedia.org/wiki/Quadratic_reciprocity ,
then I'll make y a polynomial of degree 3 and use some theorem about
Frobenius automorphisms ;-)

[Bug c++/93154] can't constrain captured functions to be invocable w/ lambda arg - func/lambda template args mixed up?

[db0451 at gmail dot com]

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

--- Comment #3 from DB  ---
still occurs with the new g++-10 (Debian 10-20200104-1) 10.0.0 20200104
(experimental) [trunk revision 279880]

[Bug c++/93152] derived_from on lambda arg causes ICE / uses wrong base, for some orders of template args on containing function

[db0451 at gmail dot com]

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

--- Comment #6 from DB  ---
still occurs with the new g++-10 (Debian 10-20200104-1) 10.0.0 20200104
(experimental) [trunk revision 279880]

[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes

[dcb314 at hotmail dot com]

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

--- Comment #14 from David Binderman  ---
Created attachment 47598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47598&action=edit
gzipped C++ source code

The attached C++ source code seems to be still broken.

-march=native (aka bdver2) seems to be required.

[Bug fortran/93175] New: ICE involving nested parameterized derived types

[townsend at astro dot wisc.edu]

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

Bug ID: 93175
   Summary: ICE involving nested parameterized derived types
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: townsend at astro dot wisc.edu
  Target Milestone: ---

I get an ICE when compiling this example code (involving a PDT inside a PDT):


module pdt_test_m

  type :: matrix (k,n)
 integer, kind :: k
 integer, len  :: n
 real(k)   :: a(n,n)
  end type matrix

  type :: problem(n)
 integer, len   :: n
 type(matrix(kind(0.D0),n)) :: m
  end type problem

end module pdt_test_m

program pdt_test

  use pdt_test_m

  implicit none

  type(problem(2)) :: p

  p%m%a = 1.

  print *, p%n
  print *, p%m%n
  print *, p%m%a

end program pdt_test


The error is as follows (on Linux):

pdt-test.f90:30:0:

   30 | end program pdt_test
  | 
internal compiler error: Segmentation fault
0xad494f crash_signal
/root/sdk2/build/gcc/gcc/toplev.c:326
0x59e47f insert_parameter_exprs
/root/sdk2/build/gcc/gcc/fortran/decl.c:3491
0x59e47f insert_parameter_exprs
/root/sdk2/build/gcc/gcc/fortran/decl.c:3477
0x5bcced gfc_traverse_expr(gfc_expr*, gfc_symbol*, bool (*)(gfc_expr*,
gfc_symbol*, int*), int)
/root/sdk2/build/gcc/gcc/fortran/expr.c:5144
0x670ffa structure_alloc_comps
/root/sdk2/build/gcc/gcc/fortran/trans-array.c:9353
0x674a80 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
gfc_actual_arglist*)
/root/sdk2/build/gcc/gcc/fortran/trans-array.c:9630
0x670924 structure_alloc_comps
/root/sdk2/build/gcc/gcc/fortran/trans-array.c:9428
0x674a80 gfc_allocate_pdt_comp(gfc_symbol*, tree_node*, int,
gfc_actual_arglist*)
/root/sdk2/build/gcc/gcc/fortran/trans-array.c:9630
0x6833e3 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
/root/sdk2/build/gcc/gcc/fortran/trans-decl.c:4599
0x6859f9 gfc_generate_function_code(gfc_namespace*)
/root/sdk2/build/gcc/gcc/fortran/trans-decl.c:6851
0x6102e6 translate_all_program_units
/root/sdk2/build/gcc/gcc/fortran/parse.c:6134
0x6102e6 gfc_parse_file()
/root/sdk2/build/gcc/gcc/fortran/parse.c:6367
0x65aa5f gfc_be_parse_file
/root/sdk2/build/gcc/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

(On OSX I also get a segfault, but the nice backtrace info is missing. Is there
a build flag for gcc to fix the lack of backtrace?)

cheers,

Rich

[Bug tree-optimization/43361] missing uninitialized warning without optimization (-O0) (PHI in always_executed basic block)

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
  Component|c++ |tree-optimization

--- Comment #13 from Jason Merrill  ---
Not a C++ issue; removing the use of iostreams from the testcase and compiling
as C has the same result.

[Bug tree-optimization/80635] [8/9/10 regression] std::optional and bogus -Wmaybe-uninitialized warning

[jason at gcc dot gnu.org]

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

--- Comment #38 from Jason Merrill  ---
(In reply to Jason Merrill from comment #37)
>(because the warning is correct for the over-reduced optional):

This is better:

template
struct optional
{
  optional () : m_dummy (), live (false) {}
  void emplace () { new (&m_item) T (); live = true; }
  ~optional () { if (live) m_item.~T (); }

  union
  {
int m_dummy;
T m_item;
  };
  bool live;
};

[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

[ndesaulniers at google dot com]

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

Nick Desaulniers  changed:

   What|Removed |Added

 CC||ndesaulniers at google dot com

--- Comment #2 from Nick Desaulniers  ---
https://reviews.llvm.org/D72215 is the discussion on the interaction between
the two in LLVM, FWIW.

[Bug target/93174] New: [10 Regression] ICE building glibc __sha512_process_block for i686

[jsm28 at gcc dot gnu.org]

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

Bug ID: 93174
   Summary: [10 Regression] ICE building glibc
__sha512_process_block for i686
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jsm28 at gcc dot gnu.org
  Target Milestone: ---
Target: i686-*

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

The following ICE appears building glibc for i686-gnu with GCC trunk (tested
with r279905). For some reason it doesn't appear building i686-pc-linux-gnu
glibc (in my bot's testing) although I can reproduce the same ICE building the
preprocessed source with an x86_64-linux-gnu compiler with -m32. Compile with
-O2, and -m32 if using a 86-bit compiler. Based on my bot's results, this is a
recent regression on trunk (but I haven't tested using fixed testcase sources
and variable compiler).

In file included from sha512.c:238:
./sha512-block.c: In function '__sha512_process_block':
./sha512-block.c:105:1: error: unrecognizable insn:
(insn 735 734 49 2 (parallel [
(set (reg:CCC 17 flags)
(compare:CCC (zero_extend:DI (plus:SI (plus:SI (ltu:SI (reg:CC
17 flags)
(const_int 0 [0]))
(mem/j:SI (plus:SI (reg:SI 5 di [277])
(const_int 68 [0x44])) [12
ctx_90(D)->D.4378.total+4 S4 A32]))
(reg:SI 1 dx [ lolen+4 ])))
(plus:DI (zero_extend:DI (reg:SI 1 dx [ lolen+4 ]))
(ltu:DI (reg:CC 17 flags)
(const_int 0 [0])
(set (mem/j:SI (plus:SI (reg:SI 5 di [277])
(const_int 68 [0x44])) [12 ctx_90(D)->D.4378.total+4 S4
A32])
(plus:SI (plus:SI (ltu:SI (reg:CC 17 flags)
(const_int 0 [0]))
(mem/j:SI (plus:SI (reg:SI 5 di [277])
(const_int 68 [0x44])) [12
ctx_90(D)->D.4378.total+4 S4 A32]))
(reg:SI 1 dx [ lolen+4 ])))
]) "./sha512-block.c":26:36 -1
 (nil))
during RTL pass: split2
./sha512-block.c:105:1: internal compiler error: in extract_insn, at
recog.c:2294
0x5a6f14 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/scratch/jmyers/glibc/many10/src/gcc/gcc/rtl-error.c:108
0x5a6f30 _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/scratch/jmyers/glibc/many10/src/gcc/gcc/rtl-error.c:116
0xc3a4a3 extract_insn(rtx_insn*)
/scratch/jmyers/glibc/many10/src/gcc/gcc/recog.c:2294
0xc3a511 extract_insn_cached(rtx_insn*)
/scratch/jmyers/glibc/many10/src/gcc/gcc/recog.c:2183
0x93c699 cleanup_subreg_operands(rtx_insn*)
/scratch/jmyers/glibc/many10/src/gcc/gcc/final.c:3312
0xc3881f split_insn
/scratch/jmyers/glibc/many10/src/gcc/gcc/recog.c:2920
0xc3c93e split_all_insns()
/scratch/jmyers/glibc/many10/src/gcc/gcc/recog.c:2988
0xc3ca78 rest_of_handle_split_before_sched2
/scratch/jmyers/glibc/many10/src/gcc/gcc/recog.c:4015
0xc3ca78 execute
/scratch/jmyers/glibc/many10/src/gcc/gcc/recog.c:4054
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/80635] [8/9/10 regression] 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

  Component|c++ |tree-optimization
  Known to work||5.5.0
Summary|std::optional and bogus |[8/9/10 regression]
   |-Wmaybe-uninitialized   |std::optional and bogus
   |warning |-Wmaybe-uninitialized
   ||warning
  Known to fail||10.0, 6.5.0, 7.3.1, 8.3.1,
   ||9.2.1

--- Comment #37 from Jason Merrill  ---
Regression from GCC 5, because with the GCC 6 -flifetime-dse changes we
properly recognize the initial state of the object as uninitialized; with
-fno-lifetime-dse we think it starts out zero-initialized.

The problem is that we have two parallel variables that aren't being treated as
parallel.  From the .optimized dump of the comment 0 test using std::optional
(because the warning is correct for the over-reduced optional):

   [count: 0]:
  # maybe_a$m_51 = PHI  // _M_value
  # maybe_a$4_54 = PHI <0(2), 1(5)> // _M_engaged
...
  _12 = VIEW_CONVERT_EXPR(maybe_a$4_54);
  if (_12 != 0)
goto ; [0.00%]
  else
goto ; [0.00%]

   [count: 0]:
  set (maybe_a$m_51);

Here maybe_a$m_51 is uninitialized iff maybe_a$4_54 is 0, and in that case we
don't use the uninitialized value.  The PHIs are completely parallel.  I'm a
bit surprised the optimizer doesn't already handle this sort of situation,
where a conditional jump determines which PHI argument we have, and therefore
should be able to select the corresponding argument from parallel PHIs in the
target block.  So bb 10 should be

  set (_29);

and we shouldn't get the warning.

[Bug tree-optimization/93134] [graphite] ICE: Segmentation fault in ISL

[asolokha at gmx dot com]

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

Arseny Solokha  changed:

   What|Removed |Added

 CC||asolokha at gmx dot com

--- Comment #3 from Arseny Solokha  ---
(In reply to Martin Liška from comment #1)
> Confirmed with current trunk and isl-0.22. Apparently, isl-0.20 is fine.

Please at least add PR90004 to the See Also section.

[Bug target/93005] Redundant NEON loads/stores from stack are not eliminated

[joel at airwebreathe dot org.uk]

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

--- Comment #7 from Joel Holdsworth  ---
> Did you test it with big-endian?

Good question. It seems to do the right thing in both cases:
https://godbolt.org/z/7rDzAm

[Bug target/93005] Redundant NEON loads/stores from stack are not eliminated

[rearnsha at gcc dot gnu.org]

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

--- Comment #6 from Richard Earnshaw  ---
(In reply to Joel Holdsworth from comment #5)
> I found that if I make modified versions of the intrinsics in arm_neon.h
> that are designed more along the lines of the x86_64 SSE intrinsics defined
> with a simple pointer dereference, then gcc does the right thing [1].
> 
> 
> #include 
> 
> __extension__ extern __inline void
> __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
> vst1q_s32_fixed (int32_t * __a, int32x4_t __b)
> {
>   *(int32x4_t*)__a = __b;
> }
> 
> __extension__ extern __inline int32x4_t
> __attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
> vld1q_s32_fixed (const int32_t * __a)
> {
>   return *(const int32x4_t*)__a;
> }
> 
> int32x4_t foo(int32x4_t a)
> {
> int32_t temp[4];
> vst1q_s32_fixed(temp, a);
> return vld1q_s32_fixed(temp);
> }
> 
> 
> 
> ...compiles to:
> 
> foo(long __vector(4)):
> bx  lr
> 
> 
> Is there any reason not to simply redefine vst1q_s32, vld1q_s32 and friends
> to stop using builtins?
> 

Did you test it with big-endian?

[Bug target/93005] Redundant NEON loads/stores from stack are not eliminated

[joel at airwebreathe dot org.uk]

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

--- Comment #5 from Joel Holdsworth  ---
I found that if I make modified versions of the intrinsics in arm_neon.h that
are designed more along the lines of the x86_64 SSE intrinsics defined with a
simple pointer dereference, then gcc does the right thing [1].


#include 

__extension__ extern __inline void
__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
vst1q_s32_fixed (int32_t * __a, int32x4_t __b)
{
  *(int32x4_t*)__a = __b;
}

__extension__ extern __inline int32x4_t
__attribute__  ((__always_inline__, __gnu_inline__, __artificial__))
vld1q_s32_fixed (const int32_t * __a)
{
  return *(const int32x4_t*)__a;
}

int32x4_t foo(int32x4_t a)
{
int32_t temp[4];
vst1q_s32_fixed(temp, a);
return vld1q_s32_fixed(temp);
}



...compiles to:

foo(long __vector(4)):
bx  lr


Is there any reason not to simply redefine vst1q_s32, vld1q_s32 and friends to
stop using builtins?


[1]https://godbolt.org/#g:!((g:!((g:!((h:codeEditor,i:(fontScale:14,j:2,lang:c%2B%2B,selection:(endColumn:2,endLineNumber:22,positionColumn:1,positionLineNumber:1,selectionStartColumn:2,selectionStartLineNumber:22,startColumn:1,startLineNumber:1),source:'%23include+%3Carm_neon.h%3E%0A%0A__extension__+extern+__inline+void%0A__attribute__++((__always_inline__,+__gnu_inline__,+__artificial__))%0Avst1q_s32_fixed+(int32_t+*+__a,+int32x4_t+__b)%0A%7B%0A++*(int32x4_t*)__a+%3D+__b%3B%0A%7D%0A%0A__extension__+extern+__inline+int32x4_t%0A__attribute__++((__always_inline__,+__gnu_inline__,+__artificial__))%0Avld1q_s32_fixed+(const+int32_t+*+__a)%0A%7B%0A++return+*(const+int32x4_t*)__a%3B%0A%7D%0A%0Aint32x4_t+foo(int32x4_t+a)%0A%7B%0Aint32_t+temp%5B4%5D%3B%0Avst1q_s32_fixed(temp,+a)%3B%0Areturn+vld1q_s32_fixed(temp)%3B%0A%7D'),l:'5',n:'0',o:'C%2B%2B+source+%232',t:'0')),header:(),k:49.54010711093072,l:'4',m:50,n:'0',o:'',s:0,t:'0'),(g:!((h:compiler,i:(compiler:arm831,filters:(b:'0',binary:'1',commentOnly:'0',demangle:'0',directives:'0',execute:'1',intel:'0',libraryCode:'1',trim:'1'),fontScale:14,j:2,lang:c%2B%2B,libs:!(),options:'-O2+-march%3Darmv7-a+-mtune%3Dcortex-a8+-mfpu%3Dneon+-mfloat-abi%3Dhard',selection:(endColumn:1,endLineNumber:1,positionColumn:1,positionLineNumber:1,selectionStartColumn:1,selectionStartLineNumber:1,startColumn:1,startLineNumber:1),source:2),l:'5',n:'0',o:'ARM+gcc+8.3.1+(none)+(Editor+%232,+Compiler+%232)+C%2B%2B',t:'0')),header:(),l:'4',m:50,n:'0',o:'',s:0,t:'0')),k:100,l:'3',n:'0',o:'',t:'0')),version:4

[Bug c++/29843] [meta-bug] C++98 standard conformance issues

[jason at gcc dot gnu.org]

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

Bug 12333 Summary: [DR 272] Explicit call to MyClass::~MyClass() not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12333

   What|Removed |Added

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

[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|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |10.0

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

[Bug c++/23287] [4.2 regression] Explicitly invoking destructor of template class in a template and is dependent

[jason at gcc dot gnu.org]

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

Bug 12333 Summary: [DR 272] Explicit call to MyClass::~MyClass() not allowed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12333

   What|Removed |Added

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

[Bug c++/93077] [10 Regression] internal compiler error: in hash_operand during GIMPLE pass: fre

[jason at gcc dot gnu.org]

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

Bug 93033 Summary: [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033

   What|Removed |Added

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

[Bug middle-end/93076] [10 Regression] internal compiler error: Segmentation fault during GIMPLE pass: cddce

[jason at gcc dot gnu.org]

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

Bug 93033 Summary: [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033

   What|Removed |Added

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

[Bug c++/93163] internal compiler error: verify_gimple failed

[jason at gcc dot gnu.org]

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

Bug 93033 Summary: [10 Regression] error: incorrect sharing of tree nodes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93033

   What|Removed |Added

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

[Bug c++/93033] [10 Regression] error: incorrect sharing of tree nodes

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/93106] [c++2a] Deleted move constructor is not selected when returning an automatic variable

[jason at gcc dot gnu.org]

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

--- Comment #3 from Jason Merrill  ---
Confirmed.  check_return_expr can't use convert_for_initialization to test
whether to treat the returned lvalue as an rvalue.

[Bug c++/93106] [c++2a] Deleted move constructor is not selected when returning an automatic variable

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-06
 CC||jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug target/93129] PPC memset not using vector instruction on >= Power8

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-06
 CC||acsawdey at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |acsawdey at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/93130] PPC simple memset not inlined

[acsawdey at gcc dot gnu.org]

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

acsawdey at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-01-06
 CC||acsawdey at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |acsawdey at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug target/70928] Load simple float constants via VSX operations on PowerPC

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 CC||jens.seifert at de dot ibm.com

--- Comment #3 from Bill Schmidt  ---
*** Bug 93128 has been marked as a duplicate of this bug. ***

[Bug target/93128] PPC small floating point constants can be constructed using vector operations

[wschmidt at gcc dot gnu.org]

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

Bill Schmidt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||wschmidt at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #2 from Bill Schmidt  ---
This is a duplicate of PR70928.

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

[Bug c++/93173] New: "error: incorrect sharing of tree nodes" and "internal compiler error: verify_gimple failed"

[sbergman at redhat dot com]

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

Bug ID: 93173
   Summary: "error: incorrect sharing of tree nodes" and "internal
compiler error: verify_gimple failed"
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

I think this only started recently on GCC trunk, I observe it at least with a
build based on today's 62a72308e1c5479bb3a9e8cacd45d49db219aaec "New bitfield
testcases":

> $ cat test.cc
> template struct S1 {
>   S1(S1 &);
>   ~S1();
> };
> struct S2 {
>   S1 x;
>   int y;
>   int z;
> };
> void f(S1 x, int y, int z) { new S2{x, y, z}; }

> $ g++ -c test.cc
> test.cc: In function ‘void f(S1, int, int)’:
> test.cc:10:6: error: incorrect sharing of tree nodes
>10 | void f(S1 x, int y, int z) { new S2{x, y, z}; }
>   |  ^
> MEM[(struct S2 *)D.2374]
> MEM[(struct S2 *)D.2374].z = z;
> during GIMPLE pass: cfg
> test.cc:10:6: internal compiler error: verify_gimple failed
> 0xfda96a verify_gimple_in_cfg(function*, bool)
>   ../../src/gcc/tree-cfg.c:5445
> 0xec1caf execute_function_todo
>   ../../src/gcc/passes.c:1983
> 0xec2aec do_per_function
>   ../../src/gcc/passes.c:1638
> 0xec2aec execute_todo
>   ../../src/gcc/passes.c:2037
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

(I assume this is a different issue than open issue 93033, given my build
includes b5cabe5e4b2778223d7a910ac3a5bbd61bff007c "PR c++/93033 - incorrect
tree node sharing with array init.")

[Bug fortran/93162] [10 Regression] gcc/fortran/trans-openmp.c:2469:50: runtime error: load of value 145992800, which is not a valid value for type 'ar_type' since r279628

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.
When the code has been added, components weren't allowed in map clause or the
OpenACC clauses, so it didn't check for REF_ARRAY.

[Bug testsuite/92991] [10 regression] g++.dg/ubsan/vptr-4.C fails starting with r279473

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||nathan at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Nathan Sidwell  ---
Fixed by r279902.  Sorry, didn't know this PR had been filed.

[Bug c++/91369] Implement P0784R7: constexpr new

[lutztonineubert at gmail dot com]

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

--- Comment #28 from Toni Neubert  ---
Thank you very much again for your fast help. Your patch works for this test
case.

I have another test case which fails. (Maybe more..., I am sorry).

//main.cpp: in ‘constexpr’ expansion of ‘test3()’
//main.cpp: in ‘constexpr’ expansion of ‘(& b)->bar::~bar()’
//main.cpp: in ‘constexpr’ expansion of ‘(&((bar*)this)->bar::f)->foo::~foo()’
//main.cpp  error: deallocation of already deallocated storage
struct foo {
constexpr foo(int* i) : ptr{i} {}

constexpr ~foo() {
delete ptr;
}

int* ptr;
};

struct bar {
foo f{new int};
};

constexpr auto test3() {
bar b;
return true;
}

static_assert(test3());

[Bug target/93005] Redundant NEON loads/stores from stack are not eliminated

[joel at airwebreathe dot org.uk]

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

--- Comment #4 from Joel Holdsworth  ---
Results for clang and MSVC are similar:

clang trunk:

foo(__simd128_int32_t):
push{r11, lr}
mov r11, sp
sub sp, sp, #24
bfc sp, #0, #4
mov r0, sp
vst1.32 {d0, d1}, [r0]
vld1.64 {d0, d1}, [r0:128]
mov sp, r11
pop {r11, pc}


...but even though these other compilers don't do any better on ARM, I still
think my original point stands.

[Bug c++/93138] [10 regression] elaborated type specifier visibility check problem

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Fixed.

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

[nathan at gcc dot gnu.org]

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

--- Comment #8 from Nathan Sidwell  ---
Author: nathan
Date: Mon Jan  6 15:22:54 2020
New Revision: 279903

URL: https://gcc.gnu.org/viewcvs?rev=279903&root=gcc&view=rev
Log:
PR c++/79592

* g++.dg/ubsan/vptr-4.C: Add expected error.

Modified:
branches/c++-modules/gcc/testsuite/g++.dg/ubsan/vptr-4.C

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

[nathan at gcc dot gnu.org]

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

--- Comment #7 from Nathan Sidwell  ---
Author: nathan
Date: Mon Jan  6 15:22:02 2020
New Revision: 279902

URL: https://gcc.gnu.org/viewcvs?rev=279902&root=gcc&view=rev
Log:
PR c++/79592 adjust testcase

https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00127.html
* g++.dg/ubsan/vptr-4.C: Add expected error.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ubsan/vptr-4.C

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug rtl-optimization/93170] [10 Regression] wrong code due to use of a call-clobbered register

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-06
 CC||marxin at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
  Known to work||9.2.0
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r276318.

[Bug target/93172] New: with AVX512 masked mov assigning zero can use {z}

[kretz at kde dot org]

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

Bug ID: 93172
   Summary: with AVX512 masked mov assigning zero can use {z}
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---
Target: x86_64-*-*, i?86-*-*

Testcase (cf. https://godbolt.org/z/DMQf9-):

#include 

// missed optimization:
__m512 f(__m512 x, __mmask16 k) {
return _mm512_mask_mov_ps(x, _knot_mask16(k), __m512());
}

// f should be translated like this:
__m512 g(__m512 x, __mmask16 k) {
return _mm512_maskz_mov_ps(k, x);
}

GCC translates f to:

  vxorps xmm1, xmm1, xmm1
  kmovw k1, edi
  vmovaps zmm0{k1}, zmm1

. It could use:

  kmovd k0, edi
  knotw k1, k0
  vmovaps zmm0 {k1} {z}, zmm0

like g does. I.e. whenever a constant zero is assigned under a negated
write-mask, the {z} variant of vmovaps should be used.

Clang even uses {z} for `_mm512_mask_mov_ps(x, k, __m512())` (i.e. without
negation of the mask), which is unclear whether that's actually a
pessimization: https://godbolt.org/z/Nn4qXz

[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398

[pinskia at gcc dot gnu.org]

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

--- Comment #61 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #60) 
> NOTICE how bfi1_1 uses one rlwimi while bfi1 has rlwinm followed by or but
> could just used rlwimi .  This is a generic problem of combine wanting to
> use nonzerobits but that sometimes can remove "important" information.

Actually it is worse because I had it backwards (due to me lowering bit-field
accesses on the tree level and producing BIT_INSERT_EXPR which just happen to
produce better code for bfi1 but worse code for bfi1_1), without my lowering
bfi1 uses three instructions to do the insert.
Also I filed PR 93171 (for a powerpc64 case) to show what is going on and
without the side comments.  The code from PR 93171 came from an inner kernel of
the network forwarding code on Octeon (MIPS) processor.

[Bug rtl-optimization/93171] New: rldimi is sometimes not produced because combine gets in the way

[pinskia at gcc dot gnu.org]

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

Bug ID: 93171
   Summary: rldimi is sometimes not produced because combine gets
in the way
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc64-linux-gnu

Take:
typedef unsigned long long uint64_t;
typedef uint64_t cvmx_pow_tag_type_t;
typedef uint64_t cvmx_pow_tag_op_t;
typedef union
{
uint64_t u64;
struct
{

uint64_t no_sched : 1;
uint64_t unused : 2;
uint64_t index :13;
cvmx_pow_tag_op_t op : 4;
uint64_t unused2 : 2;
uint64_t qos : 3;
uint64_t grp : 4;
cvmx_pow_tag_type_t type : 3;
uint64_t tag :32;
} s_cn38xx;
struct {

uint64_t no_sched : 1;
cvmx_pow_tag_op_t op : 4;
uint64_t unused1 : 16;
uint64_t grp : 6;
uint64_t unused3 : 3;
cvmx_pow_tag_type_t type : 2;
uint64_t tag :32;
} s_cn68xx_other;

} cvmx_pow_tag_req_t;

int c;

#define CVMX_POW_TAG_OP_SWTAG 0

void f(uint64_t *a, int tag, int tag_type)
{
  cvmx_pow_tag_req_t tag_req;
  tag_req.u64 = 0;
  if (c)
{
  tag_req.s_cn68xx_other.op = 0;
  tag_req.s_cn68xx_other.tag = tag;
  asm("":"+r"(tag_req.u64));
  tag_req.s_cn68xx_other.type = tag_type;
}
  else
{
  tag_req.s_cn38xx.op = 0;
  tag_req.s_cn38xx.tag = tag;
//  asm("":"+r"(tag_req.u64));
  tag_req.s_cn38xx.type = tag_type;
}

  *a = tag_req.u64;
}
--- CUT ---
On the path which contains the asm, we get:
rldimi 4,5,32,30

While on the other path, we get:
rldic 5,5,32,29
or 4,4,5

NOTE the asm is just there to force combine not to happen :).

[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398

[pinskia at gcc dot gnu.org]

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

--- Comment #60 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #59)
> You either do a define_split (splitting the above ior thing into the two
> insns you want, during combine itself), or you do a define_insn_and_split,
> allowing this whole thing as a single rtl insn (perhaps only before split1,
> or whatever works best).

That won't work for the above folding as you need to know the non-zero bits of
r93 match up with the constant to the "and" (-256).
Also this really should be a generic as I originally saw this issue on MIPS :).

Here is a testcase which you will see the same issue as insv_1.c on
powerpc64-linux-gnu (for little-endian just swap around the fields of the
struct):
typedef struct bitfield
{
  unsigned short eight1: 8;
  unsigned short eight: 8;
} bitfield;

bitfield
bfi1 (bitfield a, unsigned *b)
{
  a.eight = *b;
  return a;
}

bitfield
bfi1_1 (bitfield a, unsigned b)
{
  a.eight = b;
  return a;
}

NOTICE how bfi1_1 uses one rlwimi while bfi1 has rlwinm followed by or but
could just used rlwimi .  This is a generic problem of combine wanting to use
nonzerobits but that sometimes can remove "important" information.

[Bug rtl-optimization/93165] avoidable 2x penalty on unpredicted overwrite

[ncm at cantrip dot org]

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

--- Comment #5 from ncm at cantrip dot org ---
(In reply to Alexander Monakov from comment #3)
> The compiler has no way of knowing ahead of time that you will be evaluating
> the result on random data; for mostly-sorted arrays branching is arguably
> preferable.
> 
> __builtin_expect_with_probability is a poor proxy for unpredictability: a
> condition that is true every other time leads to a branch that is both very
> predictable and has probability 0.5.

If putting it in made my code slower, I would take it back out. The only value
it has is if it changes something. If it doesn't improve matters, I need to try
something else. For it to do nothing helps nobody.

> I think what you really need is a way to express branchless selection in the
> source code when you know you need it but the compiler cannot see that on
> its own. Other algorithms like constant-time checks for security-sensitive
> applications probably also need such computational primitive.
> 
> So perhaps an unpopular opinion, but I'd say a
> __builtin_branchless_select(c, a, b) (guaranteed to live throughout
> optimization pipeline as a non-branchy COND_EXPR) is badly missing.

We can quibble over whether the name of the intrinsic means anything with a
value of 0.5, but no other meaning would be useful.

But in general I would rather write portable code to get the semantics I need.
I don't have a preference between the AND/OR notation and the indexing version,
except that the former seems like a more generally useful optimization. Best
would be both.

[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398

[segher at gcc dot gnu.org]

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

--- Comment #59 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #58)
> (In reply to Jeffrey A. Law from comment #39)
> > Failed to match this instruction:
> > (set (reg/i:DI 0 x0)
> > (ior:DI (and:DI (reg:DI 95)
> > (const_int -256 [0xff00]))
> > (reg:DI 93)))

> I have been thinking about how to fix this for the last 6 years :).  It
> would be useful if we could produce the following two instructions:
> zero_extract(r95:DI,0x8,0)=r93
> x0=r95
> 
> But I have not figured out how to produce that.

You either do a define_split (splitting the above ior thing into the two
insns you want, during combine itself), or you do a define_insn_and_split,
allowing this whole thing as a single rtl insn (perhaps only before split1,
or whatever works best).

[Bug rtl-optimization/93170] New: [10 Regression] wrong code due to use of a call-clobbered register

[zsojka at seznam dot cz]

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

Bug ID: 93170
   Summary: [10 Regression] wrong code due to use of a
call-clobbered register
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

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

Output:
$ x86_64-pc-linux-gnu-gcc -O2 -frename-registers -fno-tree-forwprop
-fno-tree-fre -fira-algorithm=priority -mstringop-strategy=loop
--param=hot-bb-frequency-fraction=0 testcase.c -Wno-psabi
$ ./a.out 
Aborted

In the assembly output:
...
# testcase.c:17:   d = __builtin_popcountll (-((v64u8) i)[0]);
movsx   rdi, esi# tmp233, tmp232
mov QWORD PTR [rsp+32], r10 # %sfp, _70
mov QWORD PTR [rsp+40], r11 # %sfp, _70
mov QWORD PTR [rsp+16], rbx # %sfp, _67
call__popcountdi2   #
...
# testcase.c:16:   j >>= ((v64u128) h <= j);
shrdr12, rsi, cl# tmp254,, tmp253
xor ebx, ebx#
# testcase.c:18:   return a + g + j;
mov QWORD PTR [rsp+128], rax#, tmp251
# testcase.c:16:   j >>= ((v64u128) h <= j);
shr rsi, cl #, tmp253
...

The __popcountdi2 call clobbers rsi, and the caller uses the clobbered value.

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

[Bug libstdc++/93161] Remove extra operator== for comparison categories in not in standard

[wezrule at hotmail dot com]

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

--- Comment #4 from Wesley Shillingford  ---
Great, thanks for the confirmation

[Bug rtl-optimization/87763] [9/10 Regression] aarch64 target testcases fail after r265398

[pinskia at gcc dot gnu.org]

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

--- Comment #58 from Andrew Pinski  ---
(In reply to Jeffrey A. Law from comment #39)
> We've actually got an RMW insn when combine starts.  But...
> Trying 17, 7 -> 13:
>17: r92:DI=r95:DI
>   REG_DEAD r95:DI
> 7: zero_extract(r92:DI,0x8,0)=r93:DI
>   REG_DEAD r93:DI
>13: x0:DI=r92:DI
>   REG_DEAD r92:DI
> Failed to match this instruction:
> (set (reg/i:DI 0 x0)
> (ior:DI (and:DI (reg:DI 95)
> (const_int -256 [0xff00]))
> (reg:DI 93)))
> 
> We've torn the damn thing apart via expand_field_assignment.  Worse yet,
> that naturally splits and results in:

I have been thinking about how to fix this for the last 6 years :).  It would
be useful if we could produce the following two instructions:
zero_extract(r95:DI,0x8,0)=r93
x0=r95

But I have not figured out how to produce that.

[Bug libstdc++/93161] Remove extra operator== for comparison categories in not in standard

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Once a proposal is approved for inclusion in the working draft any further
changes are made to the content in the draft, not the proposal. The original
proposal is of historical interest only, what matters is the content of the
working draft.

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
> Yes, that makes sense. We should do it both during merging and during
> instrumentation. If we choose a drop level equal to 10^2 or 10^3 we should
> not probably introduce a divergence.

Instrumentation is resolved fine.

[Bug tree-optimization/92924] [10 regression] reproducible indirect call profile merging causes 80% slowdown in Firefox pref-reftest-singletons id-getter microbenchmarks

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
> 
> So the histogram of destinations is indeed greatly dominated by one
> estination but there are very many others (not all are listed since I
> started dropping them).
> 
> One way to make reproducible merging better is to drop destinations with
> small trip counts before merging, but I am not sure it would help everywhere.

Yes, that makes sense. We should do it both during merging and during
instrumentation. If we choose a drop level equal to 10^2 or 10^3 we should not
probably introduce a divergence.

One solution could be to interpret a profile when it's read and make a decision
about validity and invalidity.

[Bug libstdc++/93161] Remove extra operator== for comparison categories in not in standard

[wezrule at hotmail dot com]

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

--- Comment #2 from Wesley Shillingford  ---
Thanks for the swift reply.

(In reply to Jonathan Wakely from comment #1)
> That paper is more than two years old. The current working draft does
> specify the equality operators, e.g. [cmp.strongord]

I didn't realise those papers are not revised if there are changes, noted for
the future thanks.

> > http://wg21.link/P1946
> That paper was approved two months ago and is part of the current working
> draft.

You are correct, I've now the mailings list, which lists it as approved.
Perhaps I misinterpreted Bo Persson's comment.

> I don't see a libstdc++ bug here.

Yep seems so, I will inform MSVC if this is not fixed next preview (P1946 does
not currently appear on their conformance list yet), many thanks!

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
The relevant rule is http://eel.is/c++draft/dcl.constexpr#7 but that whole
subclause is new since C++03 :-)

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > (In reply to Andrew Pinski from comment #1)
> > > I want to say b::c::c is not a valid constexpr constructor.  Because
> > > b::c's field h's constructor is not constexr.  If that is the case, 
> > > then
> > > should be accepts invalid code.
> 
> It's a template. If the constructor doesn't meet the requirements of a
> constexpr constructor, then the constexpr specifier is just ignored. So it's
> not invalid.

Oh, ok.  I should really get familiar with all of the newer C++ features; I
have not learned enough about anything past C++03 :).

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I want to say b::c::c is not a valid constexpr constructor.  Because
> > b::c's field h's constructor is not constexr.  If that is the case, then
> > should be accepts invalid code.

It's a template. If the constructor doesn't meet the requirements of a
constexpr constructor, then the constexpr specifier is just ignored. So it's
not invalid.

> Or maybe I don't understand constexpr that well :).  e::e() is definitely
> not a valid constexpr though :).

Which is OK because it's not marked constexpr.

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I want to say b::c::c is not a valid constexpr constructor.  Because
> b::c's field h's constructor is not constexr.  If that is the case, then
> should be accepts invalid code.

Or maybe I don't understand constexpr that well :).  e::e() is definitely not a
valid constexpr though :).

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I want to say b::c::c is not a valid constexpr constructor.  Because
b::c's field h's constructor is not constexr.  If that is the case, then
should be accepts invalid code.

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |10.0

[Bug c++/93169] [10 regression] Variable incorrectly put into readonly section.

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-06
 CC||polacek at redhat dot com
 Ever confirmed|0   |1

[Bug c++/93169] New: [10 regression] Variable incorrectly put into readonly section.

[hubicka at gcc dot gnu.org]

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

Bug ID: 93169
   Summary: [10 regression] Variable incorrectly put into readonly
section.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

This is testcase by Mark Williams who also bisected it
template  class b {
  struct c {
a h;
constexpr c() {}
~c() {}
  } d;
};
struct e {
  int g;
  e() { g = 2; }
};
main() { static const b f; }

$ /aux/hubicka/trunk-install/bin/g++ -O2 t.C
t.C:12:1: warning: ISO C++ forbids declaration of ‘main’ with no type
[-Wreturn-type]
   12 | main() { static const b f; }
  | ^~~~
$ ./a.out
Segmentation fault
$ /aux/hubicka/9-install/bin/g++ -O2 t.C
At.C:12:6: warning: ISO C++ forbids declaration of ‘main’ with no type
[-Wreturn-type]
   12 | main() { static const b f; }
  |  ^
$ ./a.out

It is caused by 
commit 88bbd5a94e06eb42a5ed84a3ff6da498bea229e9 (HEAD, refs/bisect/bad)
Author: mpolacek 
AuthorDate: Mon Aug 19 13:59:13 2019 +
Commit: mpolacek 
CommitDate: Mon Aug 19 13:59:13 2019 +

PR c++/91264 - detect modifying const objects in constexpr.
* constexpr.c (modifying_const_object_error): New function.
(cxx_eval_call_expression): Set TREE_READONLY on a CONSTRUCTOR of
a const-qualified object after it's been fully constructed.
(modifying_const_object_p): New function.
(cxx_eval_store_expression): Detect modifying a const object
during constant expression evaluation.
(cxx_eval_increment_expression): Use a better location when
building
up the store.
(cxx_eval_constant_expression) : Mark a constant
object's constructor TREE_READONLY.

and goes away after reverting the cxx_eval_call_expression hunk.

[Bug ipa/83411] function multiversioning should clone the entire sub-callgraph

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Yury Gribov from comment #5)
> (In reply to Martin Liška from comment #4)
> > So finding
> > a point like your 'loop' and using flatten attribute can guarantee the
> > call-chain is fully optimized. Would be interesting to come up with more
> > examples from real applications.
> 
> As this is not immediately obvious and/or googleable, perhaps we could add a
> note to docs for pragma target and target/target_clones attributes?

Sure, I've just sent a patch:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00107.html

[Bug libstdc++/93161] Remove extra operator== for comparison categories in not in standard

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
(In reply to Wesley Shillingford from comment #0)
> However the last line fails to compile with MSVC. After checking the
> standards library support document operator==(strong_ordering,
> strong_ordering) is not mentioned:
> http://wg21.link/p0768

That paper is more than two years old. The current working draft does specify
the equality operators, e.g. [cmp.strongord]

  friend constexpr
  bool operator==(strong_ordering v, strong_ordering w) noexcept = default;

> Even worse is that value types are not even standardised for comparison
> operators! (thanks Bo Persson):
> http://wg21.link/P1946

That paper was approved two months ago and is part of the current working
draft.

I don't see a libstdc++ bug here.

[Bug rtl-optimization/93165] avoidable 2x penalty on unpredicted overwrite

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Alexander Monakov from comment #3)
> So perhaps an unpopular opinion, but I'd say a
> __builtin_branchless_select(c, a, b) (guaranteed to live throughout
> optimization pipeline as a non-branchy COND_EXPR) is badly missing.

I am going to say otherwise.  Many of the time conditional move is faster than
using a branch; even if the branch is predictable (there are a few exceptions)
on most non-Intel/AMD targets.  This is because the conditional move is just
one cycle and only a "predictable" branch is one cyle too.

It is even worse when doing things like:
if (a && b)
where on aarch64, this can be done using only one cmp followed by one ccmp.
NOTE on PowerPC, you could use in theory crand/cror (though this is not done
currently and I don't know if they are profitable in any recent design).

Plus aarch64 has conditional add and a few other things which improve the idea
of a conditional move.

[Bug tree-optimization/92860] [8/9/10 regression] Global flags affected by -O settings are clobbered by optimize attribute

[marxin at gcc dot gnu.org]

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

--- Comment #9 from Martin Liška  ---
Author: marxin
Date: Mon Jan  6 09:13:15 2020
New Revision: 279895

URL: https://gcc.gnu.org/viewcvs?rev=279895&root=gcc&view=rev
Log:
Mark param_max_combine_insns with Optimization keyword.

PR tree-optimization/92860
* params.opt: Mark param_max_combine_insns with Optimization
keyword. 


Modified:
trunk/gcc/ChangeLog
trunk/gcc/params.opt

[Bug tree-optimization/93156] abused nonnull attribute evokes new segfault in gcc 10 since Nov 4 commit, 0fb958ab8aa

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #9 from Jakub Jelinek  ---
(In reply to Bruno Haible from comment #8)
> (In reply to Andrew Pinski from comment #6)
> > a?-1:0 is transformed into -1 before we figure out that a is always true; an
> > ordering difference.
> 
> Fortunately the GCC optimization affects only the return value of
> null_ptr(). It does not cause side effects to occur that shouldn't occur.
> 
> Test case:
> =
> extern char *canonicalize_file_name (const char *__name)
>   __attribute__ ((__nonnull__ (1)));
> extern int rand (void);
> extern void brick_the_hard_disk (void);
> 
> /* Return NULL.  */
> static void *
> null_ptr (void)
> {
>   unsigned int x = rand ();
>   unsigned int y = x * x;
>   /* The following statement is equivalent to if (false),
>  since a square is always congruent to 0 or 1 mod 4.  */
>   if (y & 2) {
> brick_the_hard_disk ();
> return (void *) -1;
>   } else
> return (void *) 0;
> }
> 
> int
> main (void)
> {
>   return !!canonicalize_file_name (null_ptr ());
> }

An optimizing compiler optimizes the assumption that UB doesn't occur, because
when it occurs, anything can happen.  The above testcase has an unconditional
UB when passing NULL to function argument that requires NULL is not passed to
it
and thus the compiler when seeing that a value outside the range [(void *)1,
(void *) -2] (i.e. either NULL or (void *) -1) is passed to it and the
requirement for nonnull is that it is not NULL figures out that the range must
be [(void *) -1, (void *) -1] and replaces it with the constant all ones
pointer.
If say y & 4 was used instead of y & 2, the UB would be only conditional, and
in any case, the compiler can't call brick_the_hard_disk before reaching the
UB, but once invoking UB, it can call anything, format the disk in other ways
and perform anything else.
So the only thing we should take from the above for the compiler is optimize in
ccp that x*x has the second least significant bit clear.  Will handle that
today.

[Bug rtl-optimization/93165] avoidable 2x penalty on unpredicted overwrite

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
The compiler has no way of knowing ahead of time that you will be evaluating
the result on random data; for mostly-sorted arrays branching is arguably
preferable.

__builtin_expect_with_probability is a poor proxy for unpredictability: a
condition that is true every other time leads to a branch that is both very
predictable and has probability 0.5.

I think what you really need is a way to express branchless selection in the
source code when you know you need it but the compiler cannot see that on its
own. Other algorithms like constant-time checks for security-sensitive
applications probably also need such computational primitive.

So perhaps an unpopular opinion, but I'd say a __builtin_branchless_select(c,
a, b) (guaranteed to live throughout optimization pipeline as a non-branchy
COND_EXPR) is badly missing.

[Bug other/93168] Error messages are full of control code garbage

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
 CC||dmalcolm at gcc dot gnu.org,
   ||pinskia at gcc dot gnu.org
  Component|middle-end  |other

--- Comment #2 from Andrew Pinski  ---
Currently -fdiagnostics-urls is enabled to auto but it seems like for some
terminals, it detects the wrong thing.

Which terminal are you using, and what version?


See https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01409.html also.  Though
--with-diagnostics-urls has not gone in yet.

[Bug middle-end/93168] Error messages are full of control code garbage

[segher at gcc dot gnu.org]

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

--- Comment #1 from Segher Boessenkool  ---
The actual control stuff is eaten by bugzilla, but it makes just as little
sense like this.  There is an escape before the ] I think, but it messes up
the display (in different and interesting ways depending on terminal), so
not completely sure.

[Bug middle-end/93168] New: Error messages are full of control code garbage

[segher at gcc dot gnu.org]

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

Bug ID: 93168
   Summary: Error messages are full of control code garbage
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: segher at gcc dot gnu.org
  Target Milestone: ---

For example,

nestfunc-1.c: In function 'f':
nestfunc-1.c:22:1: warning: control reaches end of non-void function
[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wreturn-type-Wreturn-type]8;;]

(and it doesn't show the warning option, either, any more).

This stuff should not be enabled by default.