[Bug rtl-optimization/94864] Failure to combine vunpckhpd+movsd into single vunpckhpd

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-04-30
  Component|target  |rtl-optimization
 CC||rguenth at gcc dot gnu.org,
   ||segher at gcc dot gnu.org,
   ||uros at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #2 from Richard Biener  ---
We're feeding combine with

(insn 7 4 9 2 (set (reg:DF 87)
(vec_select:DF (reg:V2DF 90)
(parallel [
(const_int 1 [0x1])
]))) "y.c":6:26 3195 {sse2_storehpd}
 (expr_list:REG_DEAD (reg:V2DF 90)
(nil)))
(insn 9 7 14 2 (set (reg:V2DF 88 [ result ])
(vec_merge:V2DF (vec_duplicate:V2DF (reg:DF 87))
(reg:V2DF 89)
(const_int 1 [0x1]))) "y.c":6:21 2918 {vec_setv2df_0}
 (expr_list:REG_DEAD (reg:V2DF 89)
(expr_list:REG_DEAD (reg:DF 87)
(nil

which makes

(set (reg:V2DF 88 [ result ])
(vec_merge:V2DF (vec_duplicate:V2DF (vec_select:DF (reg:V2DF 90)
(parallel [
(const_int 1 [0x1])
])))
(reg:V2DF 89)
(const_int 1 [0x1])))

out of this which does not match anything because x86 chooses to use
vec_merge in some and vec_select/vec_concat in other patterns:

(define_insn "*vec_interleave_highv2df"
  [(set (match_operand:V2DF 0 "nonimmediate_operand" "=x,v,v,x,v,m")
(vec_select:V2DF
  (vec_concat:V4DF
(match_operand:V2DF 1 "nonimmediate_operand" " 0,v,o,o,o,v")
(match_operand:V2DF 2 "nonimmediate_operand" " x,v,1,0,v,0"))
  (parallel [(const_int 1)
 (const_int 3)])))]
  "TARGET_SSE2 && ix86_vec_interleave_v2df_operator_ok (operands, 1)"
  "@
   unpckhpd\t{%2, %0|%0, %2}

not sure if combine should try to exchange vec_merge for vec_select/vec_concat
or if this is simply the backends fault (or GCCs for even having two ways
to express the same thing...)

[Bug c++/94844] Simple nonsensical program accepted by g++ (rejected by clang++)

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #1)
> This is intentional. You get a diagnostic with -pedantic or -pedantic-errors
> 
> 94844.cc: In function ‘int main()’:
> 94844.cc:9:8: warning: ‘long’ specified with ‘Foo’ {aka ‘long unsigned int’}
> [-Wpedantic]
> 9 |   func(-1);
>   |^~~~
> 

One which is even better than clang produces even.

[Bug target/94865] Failure to combine unpckhpd+unpcklpd into blendps

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2020-04-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Similar as PR94864.  I'll note that x86 might fare better if on GIMPLE instead
of

  _1 = BIT_FIELD_REF ;
  result_4 = BIT_INSERT_EXPR ;
  return result_4;

we had a VEC_PERM but IIRC for two-element vectors this regressed some cases.
Note for this case the IL looks like above from the start so pattern-matching
a insert of an element from another vector to a permute might be a possibility
as well.

[Bug c++/80516] No error for bad type-specifier-seq in template parameter

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Jonathan Wakely from comment #3)
> The warning has changed slightly since GCC 9:
> 
> 80516.cc:6:3: warning: ‘signed’ specified with ‘u’ {aka ‘unsigned int’}
> [-Wpedantic]
> 6 | S s;
>   |   ^~
That was because of PR 84701.

[Bug target/94866] Failure to optimize pinsrq of 0 with index 1 into movq

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 Depends on||94864

--- Comment #1 from Richard Biener  ---
We're expanding from

  _3 = BIT_INSERT_EXPR ;
  return _3;

which ends up using

(insn 8 7 9 (set (reg:V2DI 85)
(vec_merge:V2DI (vec_duplicate:V2DI (reg:DI 86))
(reg:V2DI 85)
(const_int 2 [0x2]))) "y.c":6:28 -1

so likely the vec_merge "issue" again.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94864
[Bug 94864] Failure to combine vunpckhpd+movsd into single vunpckhpd

[Bug c++/80516] No error for bad type-specifier-seq in template parameter

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski  ---
This extension has been in G++ since G++ was checked into a repo.

[Bug c++/94867] [9 Regression] New (since gcc 8) false positive with -Wnull-dereference in very simple code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-30
  Known to fail||9.1.0, 9.3.0
   Target Milestone|--- |9.4
Summary|New (since gcc 8) false |[9 Regression] New (since
   |positive with   |gcc 8) false positive with
   |-Wnull-dereference in very  |-Wnull-dereference in very
   |simple code |simple code
 Status|UNCONFIRMED |NEW
  Known to work||10.0, 8.4.0
 Ever confirmed|0   |1
   Keywords||needs-bisection

--- Comment #1 from Richard Biener  ---
Confirmed, only warns with GCC 9 for me.

[Bug tree-optimization/94442] [10 regression] Redundant loads/stores emitted at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #3 from Richard Biener  ---
So I wonder why

  a$vect_s8$0_4 = MEM[(const struct __m256i &)output_5(D) + 32].vect_s8[0];  

necessarily emits two RTL insns.  It's likely because get_inner_reference
will not see through MEM[output_5(D) + 32] but records an extra offset
from the component-ref which we fail to fold into the MEM generated by
expansion of the MEM base.

[Bug c++/94529] [8/9/10 Regression] Wrong error message for template member function specialization

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Version|unknown |9.3.0
   Target Milestone|--- |8.5

[Bug lto/94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
Similar:
* PR71536 – *ICE* with *unused* static variable in declare-target function

Richard wrote in
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544905.html
> IIRC there was a bugreport similar to this where offload
> variables were computed "early" instead of at the point
> of streaming.
>
> It's obvious that the offload "part" use is not reflected in
> the non-offloat "part" IL (like via a function call parameter
> or so), so I assume this is a local static in a function
> we simply compile twice (but did not actually clone),
> once for each offloat target and once for the host.  So it's
> likely the above issue.

[Bug target/94538] [9/10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

Summary|[10 Regression] ICE: in |[9/10 Regression] ICE: in
   |extract_constrain_insn_cach |extract_constrain_insn_cach
   |ed, at recog.c:2223 (insn   |ed, at recog.c:2223 (insn
   |does not satisfy its|does not satisfy its
   |constraints) with   |constraints) with
   |-mcpu=cortex-m23|-mcpu=cortex-m23
   |-mslow-flash-data   |-mslow-flash-data
   Target Milestone|--- |9.4

--- Comment #17 from Richard Biener  ---
Can somebody check whether 9.3.0 is affected and fill out known-to-work
appropriately?

[Bug lto/94848] [Offloading][LTO] error due to only partially eliminated var / -ftree-pre causes link errors | libgomp.fortran/use_device_ptr-optional-3.f90 failures

[burnus at gcc dot gnu.org]

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

--- Comment #2 from Tobias Burnus  ---
Also possibly related (static local device variable) are the fixed PRs,
which might give a hint how to solve it (although, those look more like a band
aid):

* PR85063 – local variable for switch statement; solution:
  "Mark CSWTCH.x variable with attribute omp declare target for
   offloading functions."

* PR84592
  → see previous PR above
  → PR 90779 - comment 10 has: "Add "omp declare target" attributes
to static block scope variables inside of target region or target
functions."

[Bug debug/94868] New: GCC compile error(GCC-4.6.3)

[zhaojing2 at longcheer dot com]

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

Bug ID: 94868
   Summary: GCC compile error(GCC-4.6.3)
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhaojing2 at longcheer dot com
  Target Milestone: ---

Created attachment 48414
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48414&action=edit
compile log

CONFIGURE:
./configure --prefix=/opt/gcc-4.6.3/gcc_install
--with-gmp=/opt/gcc-4.6.3/gmp-4.3.2/gmp_install
--with-mpfr=/opt/gcc-4.6.3/mpfr-2.4.2/mpfr_install
--with-mpc=/opt/gcc-4.6.3/mpc-0.8.1/mpc_install --enable-checking=release
--program-suffix=gcc-4.6.2 --enable-languages=c,c++ --disable-bootstrap
--enable-shared --disable-multilib

ERROR:
../.././libgcc/../gcc/libgcc2.c: In function ‘__multi3’:
../.././libgcc/../gcc/libgcc2.c:558:1: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_muldi3.o] Error 1
make[2]: *** Waiting for unfinished jobs
../.././libgcc/../gcc/libgcc2.c: In function ‘__cmpti2’:
../.././libgcc/../gcc/libgcc2.c:1156:1: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_cmpdi2.o] Error 1
../.././libgcc/../gcc/libgcc2.c: In function ‘__ucmpti2’:
../.././libgcc/../gcc/libgcc2.c:1175:1: internal compiler error: Segmentation
fault
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[2]: *** [_ucmpdi2.o] Error 1
../.././libgcc/../gcc/libgcc2.c: In function ‘__absvti2’:
../.././libgcc/../gcc/libgcc2.c:272:1: internal compiler error: Segmentation
fault
Please submit a full bug report,

[Bug target/94863] Failure to use blendps over mov when possible

[gabravier at gmail dot com]

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

--- Comment #3 from Gabriel Ravier  ---
For binary size, the `movsd` takes 4 bytes and the `blendps` takes 6 bytes

The port allocations for the instructions are as such (same formatting as for
the throughputs) : 

Wolfdale: p5, p015
Nehalem: p5, p5
Westmere: p5, p5
Sandy Bridge: p05, p5
Ivy Bridge: p05, p5
Haswell: p015, p5
Broadwell: p015, p5
Skylake: p015, p5
Skylake-X: p015, p5
Kaby Lake: p015, p5
Coffee Lake: p015, p5
Cannon Lake: p015, p015
Ice Lake: p015, p015
Zen+: fp01, fp0123
Zen 2: fp013, fp0123

Something like "p015" meaning that the instruction can be executed on port 0, 1
or 5. Also, all architectures have both instructions take a single uop.

The latency of `blendps` and `movsd` are 1 on every single architecture I could
test

Final note : The numbers are specifically for the `blendps xmm, xmm, imm8` and
the `movsd xmm, xmm` forms of those instructions

[Bug fortran/93581] [9 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
(In reply to Tobias Burnus from comment #7)
> Patch was submitted at
>   https://gcc.gnu.org/pipermail/fortran/2020-March/054050.html
> 
> And committed as r10-7081-g9de42a8e995451cb13dceb3970ae23ff88240bff
> [As far as I could see, it was not yet backported to GCC 9.]
> 
> 
> commit 9de42a8e995451cb13dceb3970ae23ff88240bff
> Author: Paul Thomas 
> Date:   Sun Mar 8 18:52:35 2020 +
> 
> Patch and ChangeLogs for PR93581
> 
> +2020-03-08  Paul Thomas  
> +
> +   PR fortran/93581
> +   * resolve.c (gfc_resolve_ref): Modify array refs to be elements
> +   if the ref chain ends in INQUIRY_LEN.
> +   * trans-array.c (gfc_get_dataptr_offset): Provide the offsets
> +   for INQUIRY_RE and INQUIRY_IM.
> +
> +2020-03-08  Paul Thomas  
> +
> +   PR fortran/93581
> +   * gfortran.dg/inquiry_type_ref_6.f90 : New test.
> +

Hi Tobias,

If you could backport it for me, I would be really grateful. I completely
screwed up my 9-branch, due to my continuing git incompetence, and have not had
time to rescue it.

Cheers

Paul

[Bug ipa/94856] [10 Regression] ICE: Segmentation fault (in clone_of_p); or ICE: verify_cgraph_node failed (error: edge points to wrong declaration) since r10-4944-g1e83bd7003e03160

[marxin at gcc dot gnu.org]

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

--- Comment #4 from Martin Liška  ---
Reduced test-case:

class a {
public:
  virtual ~a() {}
};
class b {
public:
  virtual void c();
};
class C : a, public b {};
class d : C {
  ~d();
  void c();
};
d::~d() { ((b *)this)->c(); }
void d::c() {}

[Bug tree-optimization/94836] Failure to optimize condition based on known value of static variable

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
OK, so it's not that easy to do.  Consider

int f(int x)
{
static int s;

if (!s)
s = x;

return s;
}

which we cannot optimize in this way.  VN would need to work in a way
assigning the value 0 to 's' optimistically and if it eventually
arrives at s = x it would need to invalidate that optimistic assumption
and iterate.  That is it would need to see the function as

int f(int x)
{
static int s;
 # s = PHI <0, s'>

if (!s)
s = x;

return s;
 s' = s;
 goto start;
}

with the goto of course not explicit.  I suppose rather than integrating
the feature into their value-numbering scheme compilers implement special
purpose optimization (IIRC this pattern appears in SPEC).

[Bug tree-optimization/94836] Failure to optimize condition based on known value of static variable

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c++/94869] New: Template argument deduction/substitution failure with Howard Hinnant's calendar library

[lcarreon at bigpond dot net.au]

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

Bug ID: 94869
   Summary: Template argument deduction/substitution failure with
Howard Hinnant's calendar library
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lcarreon at bigpond dot net.au
  Target Milestone: ---

The following bit of code used to compile ok with g++ 9.2.1.

#include 

int main()
{
std::istringstream str{"2020-04-30 17:30:00.000"}; 
std::chrono::local_time loc_time;
str >> date::parse("%Y-%m-%d %H:%M:%S", loc_time);
return 0;
}

(NOTE: date.h is Howard Hinnant's sample implementation of the calendar library
included in C++20.)

However, when I compile with g++ 10.0.1 using this command line:

g++ -c -g -m64 -O3 -Wall -Werror -I/usr/local/include -std=c++2a dt.cpp

The compile fails with the following messages (excerpt only/incomplete):

dt.cpp:7:50: error: no matching function for call to ‘parse(const char [18],
std::chrono::local_time >
>&)’
7 |  str >> date::parse("%Y-%m-%d %H:%M:%S", loc_time);
  |  ^
In file included from dt.cpp:1:
/usr/local/include/date.h:7827:1: note: candidate: ‘template decltype
((date::from_stream(declval&>(),
format.c_str(), tp), date::parse_manip{format,
tp})) date::parse(const std::__cxx11::basic_string&,
Parsable&)’
 7827 | parse(const std::basic_string& format, Parsable&
tp)
  | ^
/usr/local/include/date.h:7827:1: note:   template argument
deduction/substitution failed:
dt.cpp:7:50: note:   mismatched types ‘const std::__cxx11::basic_string’ and ‘const char [18]’
7 |  str >> date::parse("%Y-%m-%d %H:%M:%S", loc_time);
  |  ^
In file included from dt.cpp:1:
/usr/local/include/date.h:7838:1: note: candidate: ‘template decltype
((date::from_stream(declval&>(),
format.c_str(), tp, (& abbrev)), date::parse_manip{format, tp, (& abbrev)})) date::parse(const
std::__cxx11::basic_string&, Parsable&,
std::__cxx11::basic_string&)’
 7838 | parse(const std::basic_string& format, Parsable&
tp,
  | ^
/usr/local/include/date.h:7838:1: note:   template argument
deduction/substitution failed:
dt.cpp:7:50: note:   mismatched types ‘const std::__cxx11::basic_string’ and ‘const char [18]’
7 |  str >> date::parse("%Y-%m-%d %H:%M:%S", loc_time);

FYI, I will also notify Howard Hinnant of this issue because he might have a
clue as to the cause of the problem.

[Bug debug/94868] GCC compile error(GCC-4.6.3)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Richard Biener  ---
GCC 4.6.3 is no longer supported, I suggest you try building gmp/mpfr/mpc
in-tree by invoking ./contrib/download_prerequesites prior to build
rather than using (possibly bogus) libs in /opt.  Since you seem to
compile a very old code-base also make sure your host compiler is not
too new (since you are using --disable-bootstrap it will do -O2 optimization).

[Bug target/94870] New: Failure to use movhlps instead of seperated mov+unpckhpd

[gabravier at gmail dot com]

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

Bug ID: 94870
   Summary: Failure to use movhlps instead of seperated
mov+unpckhpd
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef double v2df __attribute__((vector_size(16)));

v2df _mm_sqrt_sd(v2df a, v2df b)
{
v2df c = __builtin_ia32_sqrtpd((v2df){b[0], b[1]});
return (v2df){c[1], a[1]};
}

With -O3, LLVM outputs :

_mm_sqrt_sd(double __vector(2), double __vector(2)):
  sqrtpd xmm1, xmm1
  movhlps xmm0, xmm1 # xmm0 = xmm1[1],xmm0[1]
  ret

GCC outputs :

_mm_sqrt_sd(double __vector(2), double __vector(2)):
  movapd xmm2, xmm0
  sqrtpd xmm0, xmm1
  unpckhpd xmm0, xmm2
  ret

unpckhpd and movhlps seem to have equivalent performance, so using movhlps to
elide the extra movapd seems like it would make sense

[Bug target/57002] ARM back end has extra entries in attribute interrupt array.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Christophe Lyon :

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

commit r10-8063-g03afbf335776916724b0608c256495c04a369d2b
Author: Christophe Lyon 
Date:   Wed Apr 29 09:55:45 2020 +

arm: Remove duplicate entries in isr_attribute_args [PR target/57002]

Remove two duplicate entries in isr_attribute_args ("abort" and
"ABORT").

2020-04-30  Christophe Lyon  

PR target/57002
gcc/
* config/arm/arm.c (isr_attribute_args): Remove duplicate entries.

[Bug target/57002] ARM back end has extra entries in attribute interrupt array.

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

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

--- Comment #5 from Christophe Lyon  ---
Fixed on trunk.

[Bug ipa/94856] [10 Regression] ICE: Segmentation fault (in clone_of_p); or ICE: verify_cgraph_node failed (error: edge points to wrong declaration) since r10-4944-g1e83bd7003e03160

[marxin at gcc dot gnu.org]

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

--- Comment #5 from Martin Liška  ---
So the GNU TM is involved only very slightly as it prevents one inlining
candidate:

Without -fgnu-tm:

Enqueueing calls in d::~d()/9.
   Estimating body: c.constprop/34
   Known to be false: not inlined
   size:0 time:0.00 nonspec time:2.00
   Estimating body: c.constprop/34
   Known to be false: not inlined
   size:0 time:0.00 nonspec time:2.00
  enqueuing call d::~d()/9 -> c.constprop/34, badness -inf

With -fgnu-tm:
pr47218.ii:14:25: missed:   not inlinable: d::~d()/9 -> c.constprop/34,

reason is this:
ipa-inline.c:364:

  /* TM pure functions should not be inlined into non-TM_pure
 functions.  */
  else if (is_tm_pure (callee->decl) && !is_tm_pure (caller->decl))
{
  e->inline_failed = CIF_UNSPECIFIED;
  inlinable = false;
}

The following patch can cause the ICE without -fgnu-tm:

diff --git a/gcc/ipa-inline.c b/gcc/ipa-inline.c
index f71443feff7..cb968059a28 100644
--- a/gcc/ipa-inline.c
+++ b/gcc/ipa-inline.c
@@ -361,7 +361,8 @@ can_inline_edge_p (struct cgraph_edge *e, bool report,
 }
   /* TM pure functions should not be inlined into non-TM_pure
  functions.  */
-  else if (is_tm_pure (callee->decl) && !is_tm_pure (caller->decl))
+  else if (strcmp (callee->name(), "c.constprop") == 0
+  && strcmp (caller->name(), "d::~d()") == 0)
 {
   e->inline_failed = CIF_UNSPECIFIED;
   inlinable = false;

@Martin, Honza: Can you please take a look?
I tend to mark it as P1.

[Bug ipa/94856] [10 Regression] ICE: Segmentation fault (in clone_of_p); or ICE: verify_cgraph_node failed (error: edge points to wrong declaration) since r10-4944-g1e83bd7003e03160

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
With the patch, minimal options are:
g++ pr47218.ii -fno-tree-dse --param uninlined-function-insns=0 --param
early-inlining-insns=3 -O2 -c

[Bug testsuite/94763] UNRESOLVED scan assembler tests on arm-none-eabi

[clyon at gcc dot gnu.org]

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

--- Comment #3 from Christophe Lyon  ---
(In reply to vvinayag from comment #2)

> Sorry for the late reply. 
> The tests appear to pass when I invoke them locally. They only failed as
> part of our buildbot run tests. It could be a glitch in our test system. But
> I was wondering whether there were any recent changes in the testsuites.

If you still have the .log file, you could check why the tests are UNRESOLVED,
there's probably an error message nearby.

[Bug libstdc++/94869] [10 Regression] Template argument deduction/substitution failure with Howard Hinnant's calendar library

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||rejects-valid
   Last reconfirmed||2020-04-30
   Target Milestone|--- |10.0
Summary|Template argument   |[10 Regression] Template
   |deduction/substitution  |argument
   |failure with Howard |deduction/substitution
   |Hinnant's calendar library  |failure with Howard
   ||Hinnant's calendar library
  Component|c++ |libstdc++
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Can you provide a complete testcase?  I'm sure date.h does not include
any STL bits.  That is, please provide preprocessed source.

[Bug testsuite/94725] Tests with proprietary license notices

[pault at gcc dot gnu.org]

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

--- Comment #4 from Paul Thomas  ---
https://gcc.gnu.org/g:31e6f8293362979aea53b5cae3fa6ab0b6981694

commit r10-8064-g31e6f8293362979aea53b5cae3fa6ab0b6981694
Author: Paul Thomas 
Date:   Thu Apr 30 09:56:01 2020 +0100

PR94725 - deleting gfortran.dg/dtio_5.f90 and pdt_5.f03

Replacement tests are on their way but are taking a bit longer to prepare than
expected.

Paul

[Bug target/94871] New: Failure to convert cmpeqpd+pxor with -1 into cmpneqpd

[gabravier at gmail dot com]

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

Bug ID: 94871
   Summary: Failure to convert cmpeqpd+pxor with -1 into cmpneqpd
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

typedef double v2df __attribute__((vector_size(16)));
typedef int64_t v2di __attribute__((vector_size(16)));
typedef int8_t v16qi __attribute__((vector_size(16)));

inline v2di set1_epi8(int8_t a)
{
return (v2di)(v16qi){a, a, a, a, a, a, a, a, a, a, a, a, a, a, a, a};
}

v2di cmpneq_pd(v2df a, v2df b)
{
return ((v2di)__builtin_ia32_cmpeqpd(a, b) ^ set1_epi8(0xFF));
}

With -O3, LLVM outputs : 

cmpneq_pd(double __vector(2), double __vector(2)):
  cmpneqpd xmm0, xmm1
  ret

GCC outputs :

cmpneq_pd(double __vector(2), double __vector(2)):
  cmpeqpd xmm0, xmm1
  pcmpeqd xmm1, xmm1
  pxor xmm0, xmm1
  ret

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

[rguenth at gcc dot gnu.org]

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

--- Comment #37 from Richard Biener  ---
Eww.  Fixing the missed optimization causes tons of maybe-uninit warnings.
That was probably to be expected since we're introducing undefs on the loop
entry edge and conditional uses.  We eventually should mark the conditional
stores on the exits with no-warning...

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

[stefansf at linux dot ibm.com]

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

Bug 94769 Summary: Possible use of uninitialized variable num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769

   What|Removed |Added

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

[Bug fortran/94769] Possible use of uninitialized variable num

[stefansf at linux dot ibm.com]

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

Stefan Schulze Frielinghaus  changed:

   What|Removed |Added

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

--- Comment #10 from Stefan Schulze Frielinghaus  ---
Closing since fixed by 27594524d8a

[Bug target/94538] [9/10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

  Known to work||9.2.0

--- Comment #18 from Christophe Lyon  ---
I've just checked that the testcase passes with 9.2.0

[Bug d/90719] libphobos.phobos_shared/std/file.d FAILs on 32-bit Solaris

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:05b6520ed29a9e2b5480ecab4e71d999c7d04f29

commit r10-8066-g05b6520ed29a9e2b5480ecab4e71d999c7d04f29
Author: Iain Buclaw 
Date:   Thu Apr 30 11:03:33 2020 +0200

d: Merge upstream dmd 934df6f8c, druntime 7bdd83d7

Corrects a previous change made to the SPARC stdc bindings, and
backports PPC-related fixes.  The library and language testsuite now
passes fully on powerpc64le-linux-gnu.

Fixes: PR d/90719
Fixes: PR d/94825

Reviewed-on: https://github.com/dlang/dmd/pull/11079
 https://github.com/dlang/druntime/pull/3078
 https://github.com/dlang/druntime/pull/3083

libphobos/ChangeLog:

PR d/94825
* libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Remove
config/powerpc/switchcontext.S
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/powerpc/callwithstack.S: Remove.
* libdruntime/config/powerpc/switchcontext.S: Fix symbol name of
fiber_switchContext.
* libdruntime/core/thread.d: Disable fiber migration tests on PPC.
* testsuite/libphobos.thread/fiber_guard_page.d: Set guardPageSize
same as stackSize.

[Bug d/94825] libphobos test case failures on powerpc64

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:05b6520ed29a9e2b5480ecab4e71d999c7d04f29

commit r10-8066-g05b6520ed29a9e2b5480ecab4e71d999c7d04f29
Author: Iain Buclaw 
Date:   Thu Apr 30 11:03:33 2020 +0200

d: Merge upstream dmd 934df6f8c, druntime 7bdd83d7

Corrects a previous change made to the SPARC stdc bindings, and
backports PPC-related fixes.  The library and language testsuite now
passes fully on powerpc64le-linux-gnu.

Fixes: PR d/90719
Fixes: PR d/94825

Reviewed-on: https://github.com/dlang/dmd/pull/11079
 https://github.com/dlang/druntime/pull/3078
 https://github.com/dlang/druntime/pull/3083

libphobos/ChangeLog:

PR d/94825
* libdruntime/Makefile.am (DRUNTIME_SOURCES_CONFIGURED): Remove
config/powerpc/switchcontext.S
* libdruntime/Makefile.in: Regenerate.
* libdruntime/config/powerpc/callwithstack.S: Remove.
* libdruntime/config/powerpc/switchcontext.S: Fix symbol name of
fiber_switchContext.
* libdruntime/core/thread.d: Disable fiber migration tests on PPC.
* testsuite/libphobos.thread/fiber_guard_page.d: Set guardPageSize
same as stackSize.

[Bug ipa/94856] [10 Regression] ICE: Segmentation fault (in clone_of_p); or ICE: verify_cgraph_node failed (error: edge points to wrong declaration) since r10-4944-g1e83bd7003e03160

[jamborm at gcc dot gnu.org]

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

--- Comment #7 from Martin Jambor  ---
The "edge points to wrong decl" case is a verifier error.  We have a
method which (in the course of IPA-CP) loses its this pointer because
it is unused and the pass then does not clone all the this adjusting
thunks and just makes the calls go straight to the new clone - and
then the verifier complains that the edge does not seem to point to a
clone of what it used to.  This looked weird because the verifier
actually has logic detecting this case but it turns out that it is
confused by inliner body-saving mechanism which invents a new decl for
the base function.

Inlining body-saving mechanism should correctly set former_clone_of
and then we can detect this case too.  Then we pass this particular
round of verification but the subsequent one fails because we have
inlined the function into its former thunk - which subsequently does
not have any callees, but the verifier still access them and segfaults
just like in the original -fopenacc case.  That is why the following
(yet untested) patch most likely fixes that case too:

diff --git a/gcc/cgraph.c b/gcc/cgraph.c
index 72d7cb54301..2a9813df2d9 100644
--- a/gcc/cgraph.c
+++ b/gcc/cgraph.c
@@ -3104,15 +3104,17 @@ clone_of_p (cgraph_node *node, cgraph_node *node2)
return false;
   /* In case of instrumented expanded thunks, which can have multiple
calls
 in them, we do not know how to continue and just have to be
-optimistic.  */
-  if (node->callees->next_callee)
+optimistic.  The same applies if all calls have already been inlined
+into the thunk.  */
+  if (!node->callees || node->callees->next_callee)
return true;
   node = node->callees->callee->ultimate_alias_target ();

   if (!node2->clone.param_adjustments
  || node2->clone.param_adjustments->first_param_intact_p ())
return false;
-  if (node2->former_clone_of == node->decl)
+  if (node2->former_clone_of == node->decl
+ || node2->former_clone_of == node->former_clone_of)
return true;

   cgraph_node *n2 = node2;
diff --git a/gcc/ipa-inline-transform.c b/gcc/ipa-inline-transform.c
index be60bbccb5c..e9e21cc0296 100644
--- a/gcc/ipa-inline-transform.c
+++ b/gcc/ipa-inline-transform.c
@@ -607,6 +607,8 @@ save_inline_function_body (struct cgraph_node *node)
}
 }
   *ipa_saved_clone_sources->get_create (first_clone) = prev_body_holder;
+  first_clone->former_clone_of
+= node->former_clone_of ? node->former_clone_of : node->decl;
   first_clone->clone_of = NULL;

   /* Now node in question has no clones.  */

[Bug c/94842] [8/9/10 Regression] internal compiler error: in gimplify_label_expr, at gimplify.c:2573

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Indeed:
_Atomic float x = 5;

void
bar (float y[(int) (x += 2)])
{
}
is accepted while
_Atomic float x = 5;

void
foo (void)
{
  void bar (float y[(int) (x += 2)]) {}
}
ICEs.  The problem is that create_artificial_label called from
build_atomic_assign from the nested function parameter declaration parsing sets
LABEL_DECL to current_function_decl

[Bug debug/94868] GCC compile error(GCC-4.6.3)

[zhaojing2 at longcheer dot com]

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

--- Comment #2 from Zhao Jing  ---
Dear Richard Biener:

I have already installed gmp/mpfr/mpc before install gcc.

zhaojing2@ubuntu:/opt/gcc-4.6.3$ ls gmp-4.3.2/gmp_install/
include  lib  share
zhaojing2@ubuntu:/opt/gcc-4.6.3$ ls mpfr-2.4.2/mpfr_install/
include  lib  share
zhaojing2@ubuntu:/opt/gcc-4.6.3$ ls mpc-0.8.1/mpc_install/
include  lib  share

I suggest you try building gmp/mpfr/mpc in-tree by invoking
./contrib/download_prerequesites prior to build rather than using (possibly
bogus) libs in /opt.
==> What's the next step atfer invoking ./contrib/download_prerequesites?
Could you please describe more details? How can I install the gcc step by
step?
How should I make the configure?

Thanks.

[Bug c/94842] [8/9/10 Regression] internal compiler error: in gimplify_label_expr, at gimplify.c:2573

[jakub at gcc dot gnu.org]

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

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 48415
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48415&action=edit
gcc10-pr94842.patch

Untested fix.

[Bug target/94871] Failure to convert cmpeqpd+pxor with -1 into cmpneqpd

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Target||x86_64-*-* i?86-*-*
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-30

--- Comment #1 from Richard Biener  ---
Requires some x86 specific builtin folding or open-coding it.

[Bug tree-optimization/94872] New: Failure to optimize shuffle from u32 array into u64 array properly

[gabravier at gmail dot com]

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

Bug ID: 94872
   Summary: Failure to optimize shuffle from u32 array into u64
array properly
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

union u64Elems
{
uint64_t as_u64;
int32_t as_i32[2];
};

uint64_t f(u64Elems m1, u64Elems m2)
{
u64Elems res;
res.as_i32[0] = m1.as_i32[1];
res.as_i32[1] = m2.as_i32[1];

return res.as_u64;
}

With -O3, LLVM outputs :

f(u64Elems, u64Elems): # @f(u64Elems, u64Elems)
  shr rdi, 32
  movabs rax, -4294967296
  and rax, rsi
  or rax, rdi
  ret

GCC outputs :

f(u64Elems, u64Elems):
  sar rdi, 32
  sar rsi, 32
  movd xmm0, edi
  movd xmm1, esi
  punpckldq xmm0, xmm1
  movq rax, xmm0
  ret

With -mno-sse, it's even worse :

f(u64Elems, u64Elems):
  sar rdi, 32
  sar rsi, 32
  mov QWORD PTR [rsp-8], 0
  mov DWORD PTR [rsp-8], edi
  mov rax, QWORD PTR [rsp-8]
  mov QWORD PTR [rsp-16], rax
  mov DWORD PTR [rsp-12], esi
  mov rax, QWORD PTR [rsp-16]
  ret

Looking at the final tree representation :

f (union u64Elems m1, union u64Elems m2)
{
  int _1;
  int _2;
  long unsigned int _4;
  vector(2) int _8;

   [local count: 1073741824]:
  # DEBUG BEGIN_STMT
  # DEBUG BEGIN_STMT
  _1 = m1.as_i32[1];
  # DEBUG BEGIN_STMT
  _2 = m2.as_i32[1];
  _8 = {_1, _2};
  # DEBUG BEGIN_STMT
  _4 = VIEW_CONVERT_EXPR(_8);
  return _4;

}

It looks to me like the conversion to vector(2) is the culprit here, it's not
getting optimized properly

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

[zsojka at seznam dot cz]

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

Bug ID: 94873
   Summary: [8/9/10 Regression] wrong code with -O
-fno-merge-constants -fno-split-wide-types
-fno-tree-fre
   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: aarch64-unknown-linux-gnu

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

Output:
$ aarch64-unknown-linux-gnu-gcc -O -fno-merge-constants -fno-split-wide-types
-fno-tree-fre testcase.c -static
$ ./a.out 
`�+%��@�

The generated code passes wrong data as the "format" argument; I wasn't able to
reproduce this without using __builtin_printf() quickly.

...
and w1, w1, 255 //, MEM[(volatile unsigned char *)&x]
adrpx0, .LANCHOR0   // tmp98,
add x0, x0, :lo12:.LANCHOR0 //, tmp98,
bl  printf  //
...
.set.LANCHOR0,. + 0
.LC0:
.xword  -846514461162629792
.xword  0
.LC1:
.string "%02x"
...

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r10-8064-20200430095601-g31e6f829336-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/10.0.1/lto-wrapper
Target: aarch64-unknown-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
--with-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r10-8064-20200430095601-g31e6f829336-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.0.1 20200430 (experimental) (GCC)

[Bug middle-end/94874] New: [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified in enclosing ‘target’'

[tschwinge at gcc dot gnu.org]

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

Bug ID: 94874
   Summary: [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for
'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified
in enclosing ‘target’'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48417
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48417&action=edit
'gcc/testsuite/c-c++-common/gomp/pr.c'

[...]/pr.c:24:37: error: ‘array_li.0’ not specified in enclosing ‘target’
   24 | array_so_openmp_target = sizeof array;
  |  ~~~^

I suppose for all such compiler-generated ('DECL_ARTIFICIAL') objects, we
shouldn't generate 'default(none)'/'defaultmap(none)' diagnostics, but instead
make them available on the offloading device in the "best possible" way.  (...,
which probably defaults to 'firstprivate' given that these are typically
small-size objects?)  (Regarding the latter, see also
'gcc/gimplify.c:omp_shared_to_firstprivate_optimizable_decl_p', which applies
similar rationale regarding "large decls".)

Also, for conceptual simplicity, I suppose any such compiler-generated
('DECL_ARTIFICIAL') objects should in some way be marked up with 'firstprivate'
clauses "explicitly by the compiler" when they are created, instead of having
'omp_default_clause' etc. do that.  (I have not studied that in detail.)  My
inclination would be to put an 'gcc_assert (!DECL_ARTIFICIAL(decl))' there? 
But maybe that's too hard.  Also need to sort out how that relates to
'lang_hooks.decls.omp_predetermined_sharing' etc.


Back to the diagnostic here, for '-x c++' we get, worse:

[...]/pr.c:24:28: error: ‘’ not specified in enclosing ‘target’
   24 | array_so_openmp_target = sizeof array;
  | ~~~^~

(Notice the empty '‘’'.)  Per GDB:

Breakpoint 1, omp_notice_variable (ctx=0x2d2fc10,
decl=decl@entry=0x77feee10, in_code=in_code@entry=true) at
[...]/source-gcc/gcc/gimplify.c:7487
7487  error ("%qE not specified in enclosing
%",
(gdb) print d
$1 = (tree) 0x77feee10
(gdb) call debug_tree(d)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x767c3150 precision:64 min  max >
used ignored DI [...]/pr.c:8:23 size 
unit-size 
align:64 warn_if_not_align:0 context >
(gdb) print d.decl_minimal.name
$2 = (tree) 0x0

Doing something like 'gcc/fortran/trans-openmp.c:gfc_omp_report_decl' doesn't
easily help here, because:

(gdb) print d.decl_common.artificial_flag
$3 = 1
(gdb) print d.decl_common.lang_specific
$4 = (lang_decl *) 0x0

[Bug middle-end/94874] [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified in enclosing ‘target’'

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Schwinge  ---
Tobias, will you please familiarize yourself with this topic.

[Bug middle-end/94874] [OpenMP] Unhelpful 'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not specified in enclosing ‘target’'

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
This is something that is handled by
lang_hooks.decls.omp_predetermined_sharing
some FEs need to treat all DECL_ARTIFICIAL decls that way, others perhaps a
subset of them.

[Bug debug/94875] New: -fdebug-types-section drops DW_AT_object_pointer

[vries at gcc dot gnu.org]

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

Bug ID: 94875
   Summary: -fdebug-types-section drops DW_AT_object_pointer
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider the test-case consisting of gdb.cp/derivation.cc and
gdb.cp/derivation2.cc (
https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/testsuite/gdb.cp/derivation.cc;hb=HEAD
and
https://sourceware.org/git/?p=binutils-gdb.git;a=blob_plain;f=gdb/testsuite/gdb.cp/derivation2.cc;hb=HEAD
).

Without -fdebug-types-section:
...
$ g++ derivation.cc derivation2.cc -g
...
we have:
...
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_name: derivation.cc
 <1><161>: Abbrev Number: 11 (DW_TAG_class_type)
<162>   DW_AT_name: A
<164>   DW_AT_byte_size   : 8
<165>   DW_AT_decl_file   : 1
<166>   DW_AT_decl_line   : 33
<167>   DW_AT_sibling : <0x1df>
 <2><16b>: Abbrev Number: 12 (DW_TAG_typedef)
<16c>   DW_AT_name: value_type
<170>   DW_AT_decl_file   : 1
<171>   DW_AT_decl_line   : 35
<172>   DW_AT_type: <0x14a>
<176>   DW_AT_accessibility: 1  (public)
 <2><1a6>: Abbrev Number: 15 (DW_TAG_subprogram)
<1a7>   DW_AT_external: 1
<1a7>   DW_AT_name: afoo
<1ab>   DW_AT_decl_file   : 1
<1ac>   DW_AT_decl_line   : 44
<1ad>   DW_AT_linkage_name: _ZN1A4afooEv
<1b1>   DW_AT_type: <0x16b>
<1b5>   DW_AT_accessibility: 1  (public)
<1b6>   DW_AT_declaration : 1
<1b6>   DW_AT_object_pointer: <0x1be>
<1ba>   DW_AT_sibling : <0x1c4>
 <3><1be>: Abbrev Number: 7 (DW_TAG_formal_parameter)
<1bf>   DW_AT_type: <0x1df>
<1c3>   DW_AT_artificial  : 1
 <1>: Abbrev Number: 48 (DW_TAG_subprogram)
   DW_AT_specification: <0x1a6>
   DW_AT_decl_line   : 198
   DW_AT_object_pointer: <0xd39>
   DW_AT_low_pc  : 0x400640
   DW_AT_high_pc : 0xf
   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
   DW_AT_object_pointer: <0xd39>
   DW_AT_GNU_all_call_sites: 1
   DW_AT_sibling : <0xd46>
 <2>: Abbrev Number: 47 (DW_TAG_formal_parameter)
   DW_AT_name:  this
   DW_AT_type: <0x1e5>
   DW_AT_artificial  : 1
   DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24)
...

OTOH with -fdebug-types-section:
...
$ g++ derivation.cc derivation2.cc -g -fdebug-types-section
...
we have:
...
.debug_info:
 <0>: Abbrev Number: 41 (DW_TAG_compile_unit)
   DW_AT_name: derivation.cc
 <1><13e>: Abbrev Number: 45 (DW_TAG_class_type)
<13f>   DW_AT_name: A
<141>   DW_AT_signature   : <0xccc>
<145>   DW_AT_declaration : 1
<145>   DW_AT_sibling : <0x174>
 <2><153>: Abbrev Number: 47 (DW_TAG_subprogram)
<154>   DW_AT_external: 1
<154>   DW_AT_name: afoo
<158>   DW_AT_decl_file   : 1
<159>   DW_AT_decl_line   : 44
<15a>   DW_AT_linkage_name: _ZN1A4afooEv
<15e>   DW_AT_type: <0xcdb>
<162>   DW_AT_accessibility: 1  (public)
<163>   DW_AT_declaration : 1
 <1><8fd>: Abbrev Number: 68 (DW_TAG_subprogram)
<8fe>   DW_AT_specification: <0x153>
<902>   DW_AT_decl_line   : 198
<903>   DW_AT_object_pointer: <0x921>
<907>   DW_AT_low_pc  : 0x400640
<90f>   DW_AT_high_pc : 0xf
<917>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<919>   DW_AT_object_pointer: <0x921>
<91d>   DW_AT_GNU_all_call_sites: 1
<91d>   DW_AT_sibling : <0x92e>
 <2><921>: Abbrev Number: 67 (DW_TAG_formal_parameter)
<922>   DW_AT_name: (indirect string, offset: 0x63c): this
<926>   DW_AT_type: <0x17a>
<92a>   DW_AT_artificial  : 1
<92a>   DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24)
 <1>: Abbrev Number: 27 (DW_TAG_class_type)
   DW_AT_name: A
   DW_AT_signature   : signature: 0xbb06cf12bfa5e351
   DW_AT_declaration : 1
   DW_AT_sibling : <0xce8>
 <2>: Abbrev Number: 28 (DW_TAG_typedef)
   DW_AT_name: (indirect string, offset: 0x515): value_type
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 35
   DW_AT_type: <0xce8>
   DW_AT_accessibility: 1  (public)

.debug_types:
  Compilation Unit @ offset 0x94b:
   Signature: 0xbb06cf12bfa5e351
   Type Offset:   0x25 (0x94b + 0x25 == 0x970)
 <0><962>: Abbrev Number: 1 (DW_TAG_type_unit)
 <1><970>: Abbrev Number: 25 (DW_TAG_class_type)
<971>   DW_AT_name: A
<973>   DW_AT_byte_size   : 8
<974>   DW_AT_decl_file   : 1
<975>   DW_AT_decl_line   : 33
<976>   DW_AT_sibling : <0x9ee>
 <2><97a>: Abbrev Number: 28 (DW_TAG_typedef)
<97b>   DW_AT_name: (indirect string,

[Bug middle-end/94876] New: [OpenACC] Unhelpful mapping for 'DECL_ARTIFICIAL' inside OpenACC 'kernels' regions

[tschwinge at gcc dot gnu.org]

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

Bug ID: 94876
   Summary: [OpenACC] Unhelpful mapping for 'DECL_ARTIFICIAL'
inside OpenACC 'kernels' regions
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48418
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48418&action=edit
'gcc/testsuite/c-c++-common/goacc/pr.c'

This is somewhat conceptually related to PR94874 "[OpenMP] Unhelpful
'defaultmap(none)' diagnostic for 'DECL_ARTIFICIAL': 'error: ‘array_li.0’ not
specified in enclosing ‘target’'".

For OpenACC, we seem to be (totally/only?) relying on
'gcc/gimplify.c:oacc_default_clause' for determining how 'DECL_ARTIFICIAL'
objects are transported to the device.  In particular, for OpenACC 'kernels'
constructs, they inherit the behavior that "Scalars default to 'copy'" --
instead of the (supposedly) expected 'firstprivate'.  Even if not causing any
harm (now), that's definitely unfortunate/non-optimal.

See the 'gcc/testsuite/c-c++-common/goacc/pr.c' I'm attaching.


As mentioned in PR94874:

| I suppose for all such compiler-generated ('DECL_ARTIFICIAL') objects, we
shouldn't generate 'default(none)' diagnostics [we don't for OpenACC], but
instead make them available on the offloading device in the "best possible"
way.  (..., which probably defaults to 'firstprivate' given that these are
typically small-size objects?)  (Regarding the latter, see also
'gcc/gimplify.c:omp_shared_to_firstprivate_optimizable_decl_p', which applies
similar rationale regarding "large decls".)
|
| Also, for conceptual simplicity, I suppose any such compiler-generated
('DECL_ARTIFICIAL') objects should in some way be marked up with 'firstprivate'
clauses "explicitly by the compiler" when they are created, instead of having
['oacc_default_clause'] etc. do that.  (I have not studied that in detail.)  My
inclination would be to put an 'gcc_assert (!DECL_ARTIFICIAL(decl))' there? 
But maybe that's too hard.  Also need to sort out how that relates to
'lang_hooks.decls.omp_predetermined_sharing' etc.

[Bug middle-end/94876] [OpenACC] Unhelpful mapping for 'DECL_ARTIFICIAL' inside OpenACC 'kernels' regions

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #1 from Thomas Schwinge  ---
Tobias, will you please familiarize yourself with this topic.

[Bug middle-end/94876] [OpenACC] Unhelpful mapping for 'DECL_ARTIFICIAL' inside OpenACC 'kernels' regions

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
Created attachment 48419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48419&action=edit
'0001-WIP-Refuse-OMP-OpenACC-DECL_ARTIFICIAL-in-oacc_defau.patch'

Indeed, using the attached
'0001-WIP-Refuse-OMP-OpenACC-DECL_ARTIFICIAL-in-oacc_defau.patch', we get the
following regressions, which indicate cases where
'gcc/gimplify.c:oacc_default_clause' currently has to figure out how to deal
with 'DECL_ARTIFICIAL' objects:

  - 'c-c++-common/goacc/firstprivate-mappings-1.c'
  - 'g++.dg/goacc/firstprivate-mappings-1.C'
  - 'gfortran.dg/goacc/default_none.f95'
  - 'gfortran.dg/goacc/modules.f95'
  - 'gfortran.dg/goacc/nested-function-1.f90'
  - 'gfortran.dg/goacc/pr77371-1.f90'

[Bug fortran/94358] [OMP] Privatize internal array variables introduced by the Fortran FE

[tschwinge at gcc dot gnu.org]

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

--- Comment #2 from Thomas Schwinge  ---
(In reply to Thomas Schwinge from comment #0)
> The original test case, 'gcc/testsuite/gfortran.dg/goacc/default_none.f95',
> had already gotten committed (unmodified) to trunk in r229832 (commit
> ef014f95d542ae7b18cb4150cbb1f1ef68160f7b, 2015-11-06) -- so presumably
> didn't exhibit the original 'default(none)' problem any more.
> 
> That's presumably due to
>  "open acc default
> data attribute", where per the "fortran FE" comment, the new
> 'DECL_ARTIFICIAL' handling might indeed be the reason why we're no longer
> seeing the original 'default(none)' correctness issue.

So the first thing (please, separately from other changes/patches mentioned
here), is to make sure that these (supposedly) 'DECL_ARTIFICIAL' objects
generated by the Fortran front end do play well regarding PR94876 "[OpenACC]
Unhelpful mapping for 'DECL_ARTIFICIAL' inside OpenACC 'kernels' regions".

Assuming that the Fortran front end does generate 'DECL_ARTIFICIAL' objects
which instead of 'firstprivate' clauses will then get 'copy' clauses generated
for OpenACC 'kernels' constructs, and the Fortran front end supposedly
generates code to initialize these 'DECL_ARTIFICIAL' objects inside the
offloaded region, we'd then have race-conditions, with all device threads
writing into the same global memory concurrently?


Tobias, as a first step, can you please provide an exemplary Fortran test case
that shows some cases of what code the Fortran front end generates to calculare
array lower and upper bounds etc., for a multi-level OpenACC gang, worker,
vector loop?

[Bug debug/94875] -fdebug-types-section drops DW_AT_object_pointer

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
Minimal example:
...
$ cat derivation.cc
class A {
public:
  A() {}
  int afoo() { return 1; }
};

A a_instance;

int
main (void)
{
return 0;
}
...

compiled as:
...
$ g++ derivation.cc -g -fdebug-types-section
...

DW_AT_object_pointer is missing here in .debug_info:
...
 <2><109>: Abbrev Number: 11 (DW_TAG_subprogram)
<10a>   DW_AT_external: 1
<10a>   DW_AT_name: (indirect string, offset: 0x20c): afoo
<10e>   DW_AT_decl_file   : 1
<10f>   DW_AT_decl_line   : 4
<110>   DW_AT_linkage_name: (indirect string, offset: 0x285): _ZN1A4afooEv
<114>   DW_AT_type: <0x125>
<118>   DW_AT_accessibility: 1  (public)
<119>   DW_AT_declaration : 1
...
but not here in .debug_types:
...
 <2><47>: Abbrev Number: 5 (DW_TAG_subprogram)
<48>   DW_AT_external: 1
<48>   DW_AT_name: (indirect string, offset: 0x20c): afoo
<4c>   DW_AT_decl_file   : 1
<4d>   DW_AT_decl_line   : 4
<4e>   DW_AT_linkage_name: (indirect string, offset: 0x285): _ZN1A4afooEv
<52>   DW_AT_type: <0x68>
<56>   DW_AT_accessibility: 1   (public)
<57>   DW_AT_declaration : 1
<57>   DW_AT_object_pointer: <0x5b>
...

[Bug debug/94847] -fdebug-types-section drops const in type

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Minimal test-case:
...
$ cat constvars.c
int
main (void)
{
  const char laconic = 'A';
  volatile char vox = 'X';
  const volatile char victor = 'Y';

  return 0;
}
...

Compiled like this:
...
$ gcc -g constvars.c -fdebug-types-section
...

gives the wrong type for 'victor':
...
$ gdb -batch a.out -ex start -ex "ptype victor"
Temporary breakpoint 1 at 0x40049b: file constvars.c, line 4.

Temporary breakpoint 1, main () at constvars.c:4
4 const char laconic = 'A';
type = volatile char
...

[Bug tree-optimization/94877] New: Failure to simplify ~(x + 1) to -2 - x

[gabravier at gmail dot com]

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

Bug ID: 94877
   Summary: Failure to simplify ~(x + 1) to -2 - x
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int x)
{
return ~(x + 1);
}

With -O3, LLVM outputs this : 

f(int): # @f(int)
  mov eax, -2
  sub eax, edi
  ret

GCC outputs this :

f(int):
  lea eax, [rdi+1]
  not eax
  ret

`~x - 1` is already simplified to `-2 - x`, so optimizing this looks like it
would make sense too.

[Bug target/94748] aarch64: many unnecessary bti j emitted

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Szabolcs Nagy :

https://gcc.gnu.org/g:6ac83d350604c3e934d5e8a455ba7ec1c1c0240b

commit r10-8069-g6ac83d350604c3e934d5e8a455ba7ec1c1c0240b
Author: Szabolcs Nagy 
Date:   Fri Apr 24 17:36:02 2020 +0100

aarch64: don't emit bti j after NOTE_INSN_DELETED_LABEL [PR94748]

It was previously discussed that indirect branches cannot go to
NOTE_INSN_DELETED_LABEL so inserting a landing pad is unnecessary.
See https://gcc.gnu.org/pipermail/gcc-patches/2019-May/522625.html

Before the patch a bti j was inserted after the label in

  __attribute__((target("branch-protection=bti")))
  int foo (void)
  {
  label:
return 0;
  }

This is not necessary and weakens the security protection.

gcc/ChangeLog:

PR target/94748
* config/aarch64/aarch64-bti-insert.c (rest_of_insert_bti): Remove
the check for NOTE_INSN_DELETED_LABEL.

gcc/testsuite/ChangeLog:

PR target/94748
* gcc.target/aarch64/pr94748.c: New test.

[Bug tree-optimization/94878] New: Failure to optimize div with bls/or pattern

[gabravier at gmail dot com]

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

Bug ID: 94878
   Summary: Failure to optimize div with bls/or pattern
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

unsigned y(unsigned x)
{
unsigned s = x & -x;
return s | (x % s);
}

With -O3, LLVM outputs : 

y(unsigned int):
  blsi ecx, edi
  lea eax, [rcx - 1]
  and eax, edi
  or eax, ecx
  ret

GCC outputs :

y(unsigned int):
  mov eax, edi
  xor edx, edx
  blsi ecx, edi
  div ecx
  mov eax, edx
  or eax, ecx
  ret

If a single change to this function is applied, changing it to this :

unsigned y(unsigned x)
{
unsigned s = x & -x;
return x | (x % s);
}

It's equivalent to `return x`, and LLVM recognises this : 

y(unsigned int):
  mov eax, edi
  ret

While GCC does not :

y(unsigned int):
  mov eax, edi
  xor edx, edx
  blsi ecx, edi
  div ecx
  mov eax, edx
  or eax, edi
  ret

[Bug tree-optimization/94878] Failure to optimize div with bls/or pattern

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
Also, the assembly outputs are for when compiling with with `-mbmi` but that
should not affect the bug itself

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

[rguenth at gcc dot gnu.org]

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

--- Comment #38 from Richard Biener  ---
Created attachment 48420
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48420&action=edit
patch

Tested on x86_64-unknown-linux-gnu, queued for GCC 11.  Note it does not
(and cannot) fix the case for where we have a conditionally executed load
only - we still emit an unconditional load in the preheader then.

[Bug c++/94879] coroutines: ICE building folly in captures_temporary, at cp/coroutines.cc:2707

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-30
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org

[Bug c++/94879] New: coroutines: ICE building folly in captures_temporary, at cp/coroutines.cc:2707

[iains at gcc dot gnu.org]

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

Bug ID: 94879
   Summary: coroutines: ICE building folly in captures_temporary,
at cp/coroutines.cc:2707
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48421&action=edit
fix under test

The following code should compile, but fails with

Excess errors:
/src-local/cxx-coroutines/gcc/testsuite/g++.dg/coroutines/folly-1.C:48:39:
internal compiler error: in captures_temporary, at cp/coroutines.cc:2707
libbacktrace could not find executable to open


The problem is that we are not properly accounting for proxy variable cases.



namespace std {
template  a b(a &&);
template  struct d { c e; };
template  struct coroutine_traits : f {};
template  struct coroutine_handle;
template <> struct coroutine_handle<> {};
template  struct coroutine_handle : coroutine_handle<> {};
struct g {};
} // namespace std

class h {};
class i {
  i(i &&);
};

namespace ac {
template  class ad {
public:
  bool await_ready();
  void await_resume();
  void await_suspend(std::coroutine_handle<>);
  i ae;
};
} // namespace ac

template  ac::ad operator co_await(ab);
class j {
  class l {};

public:
  std::g initial_suspend();
  l final_suspend();
};
class m : public j {
public:
  void get_return_object();
  void unhandled_exception();
};
class n {
public:
  using promise_type = m;
};
std::d k;
void a() {
  auto am = k;
  [&]() -> n { co_await std::b(am.e); };
}

[Bug tree-optimization/57359] store motion causes wrong code for union access at -O3

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Attachment #48381|0   |1
is obsolete||

--- Comment #31 from Richard Biener  ---
Created attachment 48422
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48422&action=edit
more complex approac

So this is a feature-wise finished patch for the more complex approach (some
possible improvements are still marked as ???).  I'm throwing this on SPEC
now and appreciate correctness testing.  It patches ontop of the PR39612 patch
which is ready for early GCC 11.

[Bug target/94538] [9/10 Regression] ICE: in extract_constrain_insn_cached, at recog.c:2223 (insn does not satisfy its constraints) with -mcpu=cortex-m23 -mslow-flash-data

[wilco at gcc dot gnu.org]

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

--- Comment #19 from Wilco  ---
Yes I have a GCC9.3 build now, this fails too.

[Bug tree-optimization/94880] New: Failure to recognize andn pattern

[gabravier at gmail dot com]

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

Bug ID: 94880
   Summary: Failure to recognize andn pattern
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int x, int y)
{
return (x | y) - y;
}

This can be optimized to a single andn : 

f(int, int): # @f(int, int)
  andn eax, esi, edi
  ret

(LLVM output with -O3 -mbmi)

GCC currently outputs this : 

f(int, int):
  or edi, esi
  mov eax, edi
  sub eax, esi
  ret

[Bug tree-optimization/94882] New: Failure to optimize and+or+sub into xor+not

[gabravier at gmail dot com]

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

Bug ID: 94882
   Summary: Failure to optimize and+or+sub into xor+not
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

int f(int x, int y)
{
return (x & y) - (x | y) - 1;
}

This can be optimized to `~(x ^ y)`. LLVM does this transformation, but GCC
does not.

[Bug sanitizer/94881] New: incorrect Wstringop-overflow warning with thread sanitizer

[arnd at linaro dot org]

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

Bug ID: 94881
   Summary: incorrect Wstringop-overflow warning with thread
sanitizer
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arnd at linaro dot org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

A gcc-10 snapshot from earlier this month (dated 2020-04-13) produced a
-Wstringop-overflow warning that made no sense when building the Linux kernel.
I reduced it to a small test case

https://godbolt.org/z/NyjxvH

struct a {
  char b[50];
};
struct c {
  short action;
  struct a d;
};
struct f {
  short command;
  struct c e;
};
void i(struct f *f, int *g, unsigned h) {
  struct c *j = &f->e;
  j->action = 0;
  __builtin_memcpy(&j->d.b[h], g, 16);
}

$ x86_64-linux-gcc -O2 -Wall -fsanitize=thread test.c -c
test.c:In function 'i':
test.c:15:3: warning: writing 16 bytes into a region of size 0
[-Wstringop-overflow=]
   15 |   __builtin_memcpy(&j->d.b[h], g, 16);
  |   ^~~
test.c:5:9: note: at offset 0 to object 'action' with size 2 declared here
5 |   short action;
  | ^~

[Bug c++/94775] [8/9/10 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:6318fe77395fc0dd59419bc4d69cd06ac0158e54

commit r10-8071-g6318fe77395fc0dd59419bc4d69cd06ac0158e54
Author: Marek Polacek 
Date:   Wed Apr 29 15:36:35 2020 -0400

tree: Don't reuse types if TYPE_USER_ALIGN differ [PR94775]

Here we trip on the TYPE_USER_ALIGN (t) assert in strip_typedefs: it
gets "const d[0]" with TYPE_USER_ALIGN=0 but the result built by
build_cplus_array_type is "const char[0]" with TYPE_USER_ALIGN=1.

When we strip_typedefs the element of the array "const d", we see it's
a typedef_variant_p, so we look at its DECL_ORIGINAL_TYPE, which is
char, but we need to add the const qualifier, so we call
cp_build_qualified_type -> build_qualified_type
where get_qualified_type checks to see if we already have such a type
by walking the variants list, which in this case is:

  char -> c -> const char -> const char -> d -> const d

Because check_base_type only checks TYPE_ALIGN and not TYPE_USER_ALIGN,
we choose the first const char, which has TYPE_USER_ALIGN set.  If the
element type of an array has TYPE_USER_ALIGN, the array type gets it too.

So we can make check_base_type stricter.  I was afraid that it might make
us reuse types less often, but measuring showed that we build the same
amount of types with and without the patch, while bootstrapping.

PR c++/94775
* tree.c (check_base_type): Return true only if TYPE_USER_ALIGN
match.
(check_aligned_type): Check if TYPE_USER_ALIGN match.

* g++.dg/warn/Warray-bounds-10.C: New test.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Started with r8-7309-g74a9301d6128c0c7a4a8570545b9db40505c93f2

[Bug sanitizer/94881] [10 Regression] incorrect Wstringop-overflow warning with thread sanitizer since r10-5451-gef29b12cfbb4979a

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-30
  Known to fail||10.0
  Known to work||9.3.0
Summary|incorrect   |[10 Regression] incorrect
   |Wstringop-overflow warning  |Wstringop-overflow warning
   |with thread sanitizer   |with thread sanitizer since
   ||r10-5451-gef29b12cfbb4979a
 Status|UNCONFIRMED |NEW

--- Comment #1 from Martin Liška  ---
Confirmed, started with r10-5451-gef29b12cfbb4979a.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-30
   Target Milestone|--- |8.5

--- Comment #2 from Jakub Jelinek  ---
Testcase without printf:
__attribute__((noipa)) void
foo (const char *p, int q)
{
  if (p[0] != '%' || p[1] != '0' || p[2] != '2' || p[3] != 'x' || p[4] != '\0'
|| (unsigned char) q != 0x95)
__builtin_abort ();
}

int
main ()
{
  char x = ((union { __int128 a; char b[16]; }){ .a =
0xF4409395252B9560}).b[1];
  for (unsigned i = 0; i < sizeof (x); i++)
foo ("%02x", i[(volatile unsigned char *) &x]);
  return 0;
}

The difference (before that commit and with that) is:
--- pr94873.s1  2020-04-30 14:31:25.834578823 +0200
+++ pr94873.s2  2020-04-30 14:32:46.452456073 +0200
@@ -19,8 +19,11 @@ main:
ret
.size   main, .-main
.section.rodata
-   .align  3
+   .align  4
.set.LANCHOR0,. + 0
+.LC0:
+   .xword  -846514461162629792
+   .xword  0
 .LC1:
.string "%02x"
.ident  "GCC: (GNU) 8.0.1 20180315 (experimental)"
i.e. the unused constant somehow made it into the .rodata section.

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

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P2
 CC||ktkachov at gcc dot gnu.org,
   ||vladimir.mezentsev at oracle 
dot c
   ||om

[Bug tree-optimization/94872] Failure to optimize shuffle from u32 array into u64 array properly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  ABI details not being exposed and GCC committing to a stack slot
for m1 is one of the reasons we fail to optimize this properly.

[Bug c++/94883] New: coroutines: ICE building folly in verify_gimple_stmt, at tree-cfg.c:4959

[iains at gcc dot gnu.org]

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

Bug ID: 94883
   Summary: coroutines: ICE building folly in verify_gimple_stmt,
at tree-cfg.c:4959
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48423
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48423&action=edit
fix under test

The following should compile but produces:

folly-2.C:59:1: internal compiler error: in verify_gimple_stmt, at
tree-cfg.c:4959

The problem here is that target cleanup expressions have been added to the
initialisers for the awaitable (and returns of non-trivial values from
await_suspend() calls.  This is because the expansion of the co_await into its
control flow is not apparent to the machinery adding the target cleanup
expressions.  The solution being tested is simply to recreate target
expressions as the co_awaits are lowered.  Teaching the machinery to handle
walking co_await expressions in different ways at different points (outside the
coroutine transformation) seems overly complex.

===

namespace std {
template  struct coroutine_traits : a {};
template  struct coroutine_handle;
template <> struct coroutine_handle<> {};
template  struct coroutine_handle : coroutine_handle<> {};
struct b {
  bool await_ready();
  void await_suspend(coroutine_handle<>);
  void await_resume();
};
} // namespace std

template  auto ab(int ac, d ad) -> decltype(ad.e(ac));
int f;
class h {
  class j {
  public:
bool await_ready();
void await_suspend(std::coroutine_handle<>);
void await_resume();
  };

public:
  void get_return_object();
  std::b initial_suspend();
  j final_suspend();
  void unhandled_exception();
  template  
auto await_transform (g c) { return ab(f, c); }
};
template  class k {
public:
  using promise_type = h;
  using i = std::coroutine_handle<>;
  class l {
  public:
~l();
operator bool();
  };
  class m {
  public:
bool await_ready();
i await_suspend(std::coroutine_handle<>);
l await_resume();
  };
  class n {
  public:
m e(int);
  };
  n ah();
};

template 
k 
my_coro (k am, ai) {
  if (auto an = co_await am.ah())
;
}

void foo () {
  k a;
  my_coro (a, [] {});
}

[Bug c++/94883] coroutines: ICE building folly in verify_gimple_stmt, at tree-cfg.c:4959

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Last reconfirmed||2020-04-30
 Ever confirmed|0   |1
   Keywords||ice-on-valid-code
   Target Milestone|--- |10.0

[Bug c++/94775] [8/9 Regression] ICE in strip_typedefs, at cp/tree.c:1734 since r8-4668-g8a5ee94a082b3d48

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |strip_typedefs, at  |strip_typedefs, at
   |cp/tree.c:1734 since|cp/tree.c:1734 since
   |r8-4668-g8a5ee94a082b3d48   |r8-4668-g8a5ee94a082b3d48

--- Comment #11 from Marek Polacek  ---
Fixed on trunk so far.

[Bug tree-optimization/94877] Failure to simplify ~(x + 1) to -2 - x

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-30
   Keywords||easyhack
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

[Bug tree-optimization/94878] Failure to optimize div with bls/or pattern

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-04-30
 Target||x86_64-*-* i?86-*-*

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

[Bug tree-optimization/94880] Failure to recognize andn pattern

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  Would be canonicalization only on GIMPLE (which has no andn).

[Bug tree-optimization/94882] Failure to optimize and+or+sub into xor+not

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-30
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

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

[Bug tree-optimization/94884] New: Failure to recognize that result of or is always superior to operands

[gabravier at gmail dot com]

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

Bug ID: 94884
   Summary: Failure to recognize that result of or is always
superior to operands
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

bool decide() __attribute((const));

inline unsigned getXOrY(unsigned x, unsigned y)
{
return decide() ? y : x;
}

bool f(unsigned x, unsigned y)
{
return (x | y) >= getXOrY(x, y);
}

`f` can be optimized to `return true`. This transformation is done by LLVM, not
by GCC.

[Bug tree-optimization/94884] Failure to recognize that result of or is always superior to operands

[gabravier at gmail dot com]

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

--- Comment #1 from Gabriel Ravier  ---
`f` can also be translated to `return true;` when it's this :

bool f(unsigned x, unsigned y)
{
return (x & y) <= getXOrY(x, y);
}

[Bug tree-optimization/94884] Failure to recognize that result of or is always superior to operands

[gabravier at gmail dot com]

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

--- Comment #2 from Gabriel Ravier  ---
Also when it is this :

bool f(unsigned x, unsigned y)
{
return x <= (x | ~y);
}

[Bug tree-optimization/94884] Failure to recognize that result of or is always superior to operands

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/94885] New: Functional cast from int to empty class incorrectly accepted with -std=c++2a

[ppalka at gcc dot gnu.org]

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

Bug ID: 94885
   Summary: Functional cast from int to empty class incorrectly
accepted with -std=c++2a
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

The following testcase

template 
void foo();

struct base {};
struct derived : base {};

void
bar()
{
  foo();
}

is rejected by GCC 9 (with both -std=c++17 and -std=c++2a) and rejected by GCC
10 with -std=c++17, but it's accepted by GCC 10 with -std=c++2a.

[Bug c++/94885] Functional cast from int to empty class type with empty base incorrectly accepted with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Accepted since my r10-6519-gac6eaa55a5199196ea0a25763114ce05333a14d3

[Bug middle-end/88780] [8/9/10 Regression] bogus -Wstringop-truncation for copying as many bytes from a string as its length

[jiapei at longervision dot com]

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

Pei JIA  changed:

   What|Removed |Added

 CC||jiapei at longervision dot com

--- Comment #4 from Pei JIA  ---
gcc 9.3 in Ubuntu 20.04, this bug comes back

[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948

[chantry.xavier at gmail dot com]

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

--- Comment #18 from Xavier  ---
The lib has been recently opensourced so I can share it :
https://github.com/Intersec/lib-common/blob/master/src/core/str-stream.h

We have 100-200 usages of p_end/s_end/b_end so even if it's possible to patch
them all, I am not a big fan of this solution.

[Bug c++/94885] Functional cast from int to empty class type with empty base incorrectly accepted with -std=c++2a

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Started with r10-6519-gac6eaa55a5199196ea0a25763114ce05333a14d3

[Bug c++/94886] New: coroutines: ICE building folly, in transform_local_var_uses, at cp/coroutines.cc:1908

[iains at gcc dot gnu.org]

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

Bug ID: 94886
   Summary: coroutines: ICE building folly, in
transform_local_var_uses, at cp/coroutines.cc:1908
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iains at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48424
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48424&action=edit
fix under test

the code below should build but produces an ICE

this is because the range-based for generates three artificial variables that
need to be allocated to the coroutine frame but, when walking the BIND_EXR that
contains these, the DECL_INITIAL for one of them refers to an entry appearing
later, which means that the frame entry hasn't been allocated when that INITIAL
is walked.

The solution is to defer walking the DECL_INITIAL/SIZE etc. until all the
BIND_EXPR vars have been processed.

coro1
my_coro ()
{
  const std::array expectedValues = {{0, 3, 1, 4, 2}};

  for (int expectedValue : expectedValues) {
co_yield expectedValue;
  }
}

[Bug c++/94886] coroutines: ICE building folly, in transform_local_var_uses, at cp/coroutines.cc:1908

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
   Assignee|unassigned at gcc dot gnu.org  |iains at gcc dot gnu.org
   Last reconfirmed||2020-04-30
   Target Milestone|--- |10.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug debug/94887] New: -fdebug-types-section drops DW_TAG_formal_parameter and DW_TAG_template_type_param

[vries at gcc dot gnu.org]

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

Bug ID: 94887
   Summary: -fdebug-types-section drops DW_TAG_formal_parameter
and DW_TAG_template_type_param
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider this test-case, minimized from gdb testsuite test-case py-methods.cc:
...
$ cat py-xmethods.cc
template 
class G
{
public:
  template 
  T mul(const T1 t1) { return t1 * 5; }
};

int
main(void)
{
  G g;
  return g.mul (1.0);
}
...

Without -fdebug-types-section, we have:
...
$ g++ py-xmethods.cc -g
$ gdb -batch a.out -ex start  -ex "ptype g"  
Temporary breakpoint 1 at 0x4004cf: file py-xmethods.cc, line 13.

Temporary breakpoint 1, main () at py-xmethods.cc:13
13return g.mul (1.0);
type = class G [with T = int] {
  public:
T mul(double);
}
...

But with -fdebug-types-section, we have:
...
$ g++ py-xmethods.cc -g -fdebug-types-section
$ gdb -batch a.out -ex start  -ex "ptype g"
Temporary breakpoint 1 at 0x4004cf: file py-xmethods.cc, line 13.

Temporary breakpoint 1, main () at py-xmethods.cc:13
13return g.mul (1.0);
type = class G [with T = int] {

}
...

Or with the tentative gdb patch from here (
https://sourceware.org/bugzilla/show_bug.cgi?id=25898#c3 ), we have:
...
$ gdb -batch a.out -ex start  -ex "ptype g"
Temporary breakpoint 1 at 0x4004cf: file py-xmethods.cc, line 13.

Temporary breakpoint 1, main () at py-xmethods.cc:13
13return g.mul (1.0);
type = class G [with T = int] {
  public:
T mul(void);
}
...
Note the 'void' instead of 'double'.

Without -fdebug-types-section, we have:
...
 <1>: Abbrev Number: 2 (DW_TAG_class_type)
   DW_AT_name: (indirect string, offset: 0x225): G
   DW_AT_byte_size   : 1
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 2
   DW_AT_sibling : <0x12f>
 <2>: Abbrev Number: 3 (DW_TAG_subprogram)
   DW_AT_external: 1
   DW_AT_name: mul
<101>   DW_AT_decl_file   : 1
<102>   DW_AT_decl_line   : 6
<103>   DW_AT_linkage_name: _ZN1GIiE3mulIdEEiT_
<107>   DW_AT_type: <0x12f>
<10b>   DW_AT_accessibility: 1  (public)
<10c>   DW_AT_declaration : 1
<10c>   DW_AT_object_pointer: <0x11c>
<110>   DW_AT_sibling : <0x127>
 <3><114>: Abbrev Number: 4 (DW_TAG_template_type_param)
<115>   DW_AT_name: T1
<118>   DW_AT_type: <0x136>
 <3><11c>: Abbrev Number: 5 (DW_TAG_formal_parameter)
<11d>   DW_AT_type: <0x142>
<121>   DW_AT_artificial  : 1
 <3><121>: Abbrev Number: 6 (DW_TAG_formal_parameter)
<122>   DW_AT_type: <0x136>
 <1><14d>: Abbrev Number: 11 (DW_TAG_subprogram)
<14e>   DW_AT_specification: <0xfc>
<152>   DW_AT_object_pointer: <0x178>
<156>   DW_AT_low_pc  : 0x4004ee
<15e>   DW_AT_high_pc : 0x24
<166>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<168>   DW_AT_object_pointer: <0x178>
<16c>   DW_AT_GNU_all_call_sites: 1
<16c>   DW_AT_sibling : <0x192>
 <2><170>: Abbrev Number: 4 (DW_TAG_template_type_param)
<171>   DW_AT_name: T1
<174>   DW_AT_type: <0x136>
 <2><178>: Abbrev Number: 12 (DW_TAG_formal_parameter)
<179>   DW_AT_name: this
<17d>   DW_AT_type: <0x148>
<181>   DW_AT_artificial  : 1
<181>   DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24)
 <2><184>: Abbrev Number: 13 (DW_TAG_formal_parameter)
<185>   DW_AT_name: t1
<188>   DW_AT_decl_file   : 1
<189>   DW_AT_decl_line   : 6
<18a>   DW_AT_type: <0x13d>
<18e>   DW_AT_location: 2 byte block: 91 60 (DW_OP_fbreg: -32)
...

But with -fdebug-types-section, we have:
...
 <1><10e>: Abbrev Number: 9 (DW_TAG_subprogram)
<10f>   DW_AT_specification: <0x18e>
<113>   DW_AT_object_pointer: <0x139>
<117>   DW_AT_low_pc  : 0x4004ee
<11f>   DW_AT_high_pc : 0x24
<127>   DW_AT_frame_base  : 1 byte block: 9c(DW_OP_call_frame_cfa)
<129>   DW_AT_object_pointer: <0x139>
<12d>   DW_AT_GNU_all_call_sites: 1
<12d>   DW_AT_sibling : <0x153>
 <2><131>: Abbrev Number: 3 (DW_TAG_template_type_param)
<132>   DW_AT_name: T1
<135>   DW_AT_type: <0xf7>
 <2><139>: Abbrev Number: 10 (DW_TAG_formal_parameter)
<13a>   DW_AT_name: this
<13e>   DW_AT_type: <0x109>
<142>   DW_AT_artificial  : 1
<142>   DW_AT_location: 2 byte block: 91 68 (DW_OP_fbreg: -24)
 <2><145>: Abbrev Number: 11 (DW_TAG_formal_parameter)
<146>   DW_AT_name: t1
<149>   DW_AT_decl_file   : 1
<14a>   DW_AT_decl_line   : 6
<14b>   DW_AT_type: <0xfe>
<14f>   DW_AT_location: 2 byte block: 91 60 (DW_OP_fbr

[Bug libstdc++/89510] [9/10 Regression] new_allocator::construct needs to be constrained

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2020-04-30
Summary|new_allocator::construct|[9/10 Regression]
   |needs to be constrained |new_allocator::construct
   ||needs to be constrained
  Known to work||8.4.1
   Keywords||rejects-valid
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
  Known to fail||10.0, 9.3.1
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |9.4

--- Comment #1 from Jonathan Wakely  ---
This is actually a regression that breaks valid code:

#include 

template using void_t = void;

template
struct has_construct
: std::false_type
{ };

template
struct has_construct().construct(std::declval()))>>
: std::true_type
{ };

struct X { X(int); };

constexpr bool b = has_construct, X>::value;


In file included from
/home/jwakely/gcc/9/include/c++/9.2.1/x86_64-pc-linux-gnu/bits/c++allocator.h:33,
 from
/home/jwakely/gcc/9/include/c++/9.2.1/bits/allocator.h:46,
 from /home/jwakely/gcc/9/include/c++/9.2.1/memory:63,
 from alloc.cc:1:
/home/jwakely/gcc/9/include/c++/9.2.1/ext/new_allocator.h: In instantiation of
'void __gnu_cxx::new_allocator<_Tp>::construct(_Up*, _Args&& ...) [with _Up =
X; _Args = {}; _Tp = X]':
alloc.cc:17:55:   recursively required by substitution of 'template struct has_construct().construct(declval()))> > [with T = std::allocator; U =
X]'
alloc.cc:17:55:   required from here
/home/jwakely/gcc/9/include/c++/9.2.1/ext/new_allocator.h:145:20: error: no
matching function for call to 'X::X()'
  145 |  noexcept(noexcept(::new((void *)__p)
  |^~
  146 |_Up(std::forward<_Args>(__args)...)))
  |~~~
alloc.cc:15:12: note: candidate: 'X::X(int)'
   15 | struct X { X(int); };
  |^
alloc.cc:15:12: note:   candidate expects 1 argument, 0 provided
alloc.cc:15:8: note: candidate: 'constexpr X::X(const X&)'
   15 | struct X { X(int); };
  |^
alloc.cc:15:8: note:   candidate expects 1 argument, 0 provided
alloc.cc:15:8: note: candidate: 'constexpr X::X(X&&)'
alloc.cc:15:8: note:   candidate expects 1 argument, 0 provided

[Bug c++/94888] New: segment fault

[chunqiu1234 at foxmail dot com]

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

Bug ID: 94888
   Summary: segment fault
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chunqiu1234 at foxmail dot com
  Target Milestone: ---

There is some problems with my project use g++ in linuxOS. So I extract the
main.cpp  from my project. And when I run the program compiled with g++ , it
always reports segment fault. the same program I compiled with Microsoft VC++
works well. So I want to know whether there is a bug with g++? 


my g++ version:

z@sd:~$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/5/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
5.4.0-6ubuntu1~16.04.12' --with-bugurl=file:///usr/share/doc/gcc-5/README.Bugs
--enable-languages=c,ada,c++,java,go,d,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-5 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-5-amd64/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-5-amd64
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-5-amd64
--with-arch-directory=amd64 --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.12)


SOURCE CODE
main.cpp:


//RemoveRef
template
struct RemoveRef
{ typedef _Tp   type; };

template
struct RemoveRef<_Tp&>
{ typedef _Tp   type; };

template
struct RemoveRef<_Tp&&>
{ typedef _Tp   type; };


//RValue
template
typename RemoveRef<_Tp>::type&& RValueRef(_Tp&& __t)
{ return static_cast::type&&>(__t); }


//Forward
template
_Tp&&
Forward(typename RemoveRef<_Tp>::type& __t)
{ return static_cast<_Tp&&>(__t); }


template
_Tp&&
Forward(typename RemoveRef<_Tp>::type&& __t)
{ return static_cast<_Tp&&>(__t); }



//RemoveConst
template 
struct RemoveConst{
typedef  T  type;
};

template 
struct RemoveConst{
typedef  T&  type;
};

template 
struct RemoveConst{
typedef  T* type;
};


template 
struct RemoveConst{
typedef  T  type;
};

template
typename RemoveConst<_Tp>::type NonConst(_Tp&& __t)
{ return (typename RemoveConst<_Tp>::type)(__t); }

template
typename RemoveConst<_Tp>::type* NonConst(_Tp* __t)
{ return (typename RemoveConst<_Tp>::type*)(__t); }






template 
class IFunction{
public:
virtual Ret call(Arg... args) = 0;
virtual ~IFunction() {};
};


template 
class FunctionImpl
: public IFunction {
public:
virtual Ret call(Arg... args) {
return t(args...);
}

template 
FunctionImpl(Ty&& t_) : t(Forward(t_)) {}

private:
T t;
};



template 
class FunctionBridger{
public:
template 
FunctionBridger(T&& func_) :
func(new FunctionImpl::type, Ret, Arg
...>(Forward(func_) ) )
{
}

FunctionBridger(FunctionBridger&& o){
func = o.func, o.func = 0;
}
~FunctionBridger() {func ? (delete  func, 1) : 0;}

Ret operator ()(Arg... args) {
return  func->call(args...);
}

private:
IFunction *func;
};


template 
struct FunctionType{

};


template 
struct FunctionType{
typedef  FunctionBridger type;
};





template 
class Function
: public FunctionType::type{
public:
template 
Function( Ty&& func) : FunctionType::type(Forward(func)) { }

~Function() {};

private:
template 
void operator = (Ty&& func);
};



static int f(char a){
return  a+1;
}


struct F{
int operator ()(char a){
return a+2;
}
int operator ()(char a) const{
return a+3;
}
};



int main(int argc, char *argv[])
{
Function func = &f;
char ret = func('a');//'b'

F f1;
Function func1 =  f1;
ret = func1('a'); //c

const F f2;
Function func2 =  f2;
ret = func2('a'); //'d'
return 0;
}

[Bug c++/94888] segment fault

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
GCC 5 has been unsupported for several yeas, please try a current release.

[Bug c++/94888] segment fault

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
AddressSanitizer:DEADLYSIGNAL
=
==198476==ERROR: AddressSanitizer: stack-overflow on address 0x7ffc0eba4ff8 (pc
0x7f4eab1169b4 bp 0x7f4eab20ef80 sp 0x7ffc0eba5000 T0)
#0 0x7f4eab1169b4 in __asan::Allocator::ComputeRZLog(unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_allocator.cpp:361
#1 0x7f4eab1169b4 in __asan::Allocator::Allocate(unsigned long, unsigned
long, __sanitizer::BufferedStackTrace*, __asan::AllocType, bool)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_allocator.cpp:439
#2 0x7f4eab113a78 in __asan::asan_memalign(unsigned long, unsigned long,
__sanitizer::BufferedStackTrace*, __asan::AllocType)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_allocator.cpp:951
#3 0x7f4eab197760 in operator new(unsigned long)
/home/jwakely/src/gcc/gcc/libsanitizer/asan/asan_new_delete.cpp:99
#4 0x40191d in FunctionBridger::FunctionBridger >(Function&&) /tmp/94888.cc:104
#5 0x4016cb in Function::Function
>(Function&&) /tmp/94888.cc:143
#6 0x401c28 in FunctionImpl, int,
char>::FunctionImpl >(Function&&)
/tmp/94888.cc:90
#7 0x40192b in FunctionBridger::FunctionBridger >(Function&&) /tmp/94888.cc:104
#8 0x4016cb in Function::Function
>(Function&&) /tmp/94888.cc:143
#9 0x401c28 in FunctionImpl, int,
char>::FunctionImpl >(Function&&)
/tmp/94888.cc:90
#10 0x40192b in FunctionBridger::FunctionBridger >(Function&&) /tmp/94888.cc:104
#11 0x4016cb in Function::Function
>(Function&&) /tmp/94888.cc:143
#12 0x401c28 in FunctionImpl, int,
char>::FunctionImpl >(Function&&)
/tmp/94888.cc:90
#13 0x40192b in FunctionBridger::FunctionBridger >(Function&&) /tmp/94888.cc:104

[Bug libstdc++/94869] [10 Regression] Template argument deduction/substitution failure with Howard Hinnant's calendar library

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It includes tons of std::lib headers:

#include 
#include 
#include 
#include 
#include 
#if !(__cplusplus >= 201402)
#  include 
#endif
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#include 
#if HAS_STRING_VIEW
# include 
#endif
#include 
#include 

[Bug c++/94827] [10 Regression] crash on requires clause in tparam list since r10-4424

[nathan at gcc dot gnu.org]

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

--- Comment #3 from Nathan Sidwell  ---
Created attachment 48425
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48425&action=edit
try instantiating the fn

This one ices with the initial patch.

[Bug c++/94885] Functional cast from int to empty class type with empty base incorrectly accepted with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/94885] [10 Regression] Functional cast from int to empty class type with empty base incorrectly accepted with -std=c++2a

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
Summary|Functional cast from int to |[10 Regression] Functional
   |empty class type with empty |cast from int to empty
   |base incorrectly accepted   |class type with empty base
   |with -std=c++2a |incorrectly accepted with
   ||-std=c++2a

[Bug c/94889] New: Negate function not getting optimised to negate call

[satanichiya at waifu dot club]

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

Bug ID: 94889
   Summary: Negate function not getting optimised to negate call
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: satanichiya at waifu dot club
  Target Milestone: ---

int func(int x)
{
for(int i=0;i

[Bug libstdc++/94890] New: std::tuple({0}) fails to compile with -std=c++2a

[ppalka at gcc dot gnu.org]

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

Bug ID: 94890
   Summary: std::tuple({0}) fails to compile with
-std=c++2a
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ppalka at gcc dot gnu.org
  Target Milestone: ---

$ cat testcase.C
#include 

struct c { int i; };

std::tuple x({0});

$ g++-10 -std=c++17 testcase.C
$ g++-10 -std=c++2a testcase.C
testcase.C:5:20: error: converting to ‘std::tuple’ from initializer list
would use explicit constructor ‘constexpr
std::tuple<_Elements>::tuple(_UElements&& ...) [with _UElements = {int}; bool
_Valid = true; typename
std::enable_if::_TCC<_Valid>::__is_explicitly_constructible<_UElements
...>(), bool>::type  = false; _Elements = {c}]’
5 | std::tuple x({0});
  |^


PR94885 may be related, but its testcase wasn't reduced from this testcase.

[Bug ipa/94856] [10 Regression] ICE: Segmentation fault (in clone_of_p); or ICE: verify_cgraph_node failed (error: edge points to wrong declaration) since r10-4944-g1e83bd7003e03160

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
I proposed the patch on the mailing list:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544943.html