[Bug c++/94676] New: constexpr destructors run too late for temporaries created inside __builtin_constant_p

[richard-gccbugzilla at metafoo dot co.uk]

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

Bug ID: 94676
   Summary: constexpr destructors run too late for temporaries
created inside __builtin_constant_p
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase:


struct A {
  int *p;
  constexpr ~A() { *p = 0; }
};
static_assert(!__builtin_constant_p((A{}, 123)));


I think this testcase should be accepted. The way I see it, there are two ways
one could approach this:

1) Run the destructor for the A temporary after evaluating
__builtin_constant_p's operand, notice the operand is non-constant, and
evaluate the __bcp call to 0.

2) Notice that the __bcp call's operand has a side-effect on the enclosing
evaluation (registering a non-trivial destructor for a temporary) and evaluate
the call to 0 due to that side-effect. [This is what Clang currently does.]

I was considering changing Clang's behavior from option 2 to option 1, but I
noticed that GCC actually appears to do a third thing:

3) Run the destructor at the end of the entire static-assert condition and
reject the program because the destructor (run outside of the protection of
__builtin_constant_p) has a side-effect.

I don't think there's an obvious correct answer here, but (3) doesn't seem
right to me.

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[b...@odd-e.com]

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

--- Comment #9 from Bas Vodde  ---

Hi Jonathan,

You are right, I was drawing much too many conclusions there. I should have
waited with that comment until I slept :) Sorry for that. And it has been a
while since I read the proposal, it has been years since we hit this problem in
clang.

Let me experiment a bit and see why gcc now behaves differently than clang, and
whether that can cause a non-optimized placement delete to called on a replace
operator new.

Otherwise, I still find it odd behavior but less harmful as I wrongly stated in
the previous comment.

[Bug fortran/69101] [F03] IEEE_SELECTED_REAL_KIND is not generic

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek  ---
But this one is accepted by icc/clang++ yet we ICE:

struct A {
  A();
  A(const A &);
};
struct B : A { };

A foo ();

int
main ()
{
  B b{foo()};
}

[Bug c++/91465] [9 Regression] unexpected expression of kind overload (ICE)

[mpolacek at gcc dot gnu.org]

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

Bug 94592 Summary: [10 Regression] ICE in non-type template parameter with 
constexpr constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94592

   What|Removed |Added

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

[Bug c++/94592] [10 Regression] ICE in non-type template parameter with constexpr constructor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #11 from Marek Polacek  ---
Fixed.

[Bug c++/94592] [10 Regression] ICE in non-type template parameter with constexpr constructor

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7836-gd419e176d74162af6513be0b3bc1031726543993
Author: Marek Polacek 
Date:   Fri Apr 17 15:47:15 2020 -0400

c++: Fix ICE with { } as template argument [PR94592]

As an extension (there should be a CWG about this though), we support
braced-init-list as a template argument, but convert_nontype_argument
had trouble digesting them.  We ICEd because of the double coercion we
perform for template arguments: convert_nontype_argument called from
finish_template_type got a { }, and since a class type was involved and
we were in a template, convert_like created an IMPLICIT_CONV_EXPR.  Then
the second conversion of the same argument crashed in constexpr.c
because the IMPLICIT_CONV_EXPR had gotten wrapped in a TARGET_EXPR.
Another issue was that an IMPLICIT_CONV_EXPR leaked to constexpr.c when
building an aggregate init.

We should have instantiated the IMPLICIT_CONV_EXPR in the first call to
convert_nontype_argument, but we didn't, because the call to
is_nondependent_constant_expression returned false because it checks
!BRACE_ENCLOSED_INITIALIZER_P.  Then non_dep was false even though the
expression didn't contain anything dependent and we didn't instantiate
it in convert_nontype_argument.  To fix this, check
BRACE_ENCLOSED_INITIALIZER_P in cxx_eval_outermost_constant_expr rather
than in is_nondependent_*.

PR c++/94592
* constexpr.c (cxx_eval_outermost_constant_expr): Return when T is
a BRACE_ENCLOSED_INITIALIZER_P.
(is_nondependent_constant_expression): Don't check
BRACE_ENCLOSED_INITIALIZER_P.
(is_nondependent_static_init_expression): Likewise.

* g++.dg/cpp2a/nontype-class34.C: New test.
* g++.dg/cpp2a/nontype-class35.C: New test.

[Bug libfortran/93871] COTAN is slow for complex types

[foreese at gcc dot gnu.org]

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

--- Comment #49 from Fritz Reese  ---
(In reply to ktkachov from comment #48)
> (In reply to CVS Commits from comment #45)
[...]
> 
> I think this broke the build for bare-metal (newlib) targets like
> aarch64-none-elf:
> 
> libgfortran/intrinsics/trigd_lib.inc:55:56: error: implicit declaration of
> function 'copysignl' [-Werror=implicit-function-declaration]
>55 | #define mpfr_copysign(rop, op1, op2, rnd) rop =
> SUFFIX(copysign)((op1), (op2))
>   |^~~~
> 
> I think newlib doesn't support long double functions well so likely doesn't
> have copysignl. Is there some way this use can be conditionalised on library
> support?

I believe I should use HAVE_* macros from libgfortran/config.h to check
availability of the required functions fmod[x], fabs[x], and copysign[x]. I
will check this out and patch a fix shortly, thanks for the report.

[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
This reduced test actually regressed with r241187:

struct A {
  A(A &);
};
struct B : A { };

A foo ();

int
main ()
{
  B{foo()};
}

$ ./cc1plus -quiet x.C -std=c++17
during RTL pass: expand
x.C: In function ‘int main()’:
x.C:11:3: internal compiler error: in assign_temp, at function.c:984
   11 |   B{foo()};
  |   ^~~~
0x105cdf1 assign_temp(tree_node*, int, int)
/home/mpolacek/src/gcc/gcc/function.c:984
0xdf123d expand_call(tree_node*, rtx_def*, int)
/home/mpolacek/src/gcc/gcc/calls.c:3825
0xfe98d5 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/home/mpolacek/src/gcc/gcc/expr.c:11135
0xfdc3d9 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/home/mpolacek/src/gcc/gcc/expr.c:8358
0xfbb233 expand_normal
/home/mpolacek/src/gcc/gcc/expr.h:288
0xfd7588 store_field
/home/mpolacek/src/gcc/gcc/expr.c:7102
0xfcf3c6 expand_assignment(tree_node*, tree_node*, bool)
/home/mpolacek/src/gcc/gcc/expr.c:5374
0xe12534 expand_call_stmt
/home/mpolacek/src/gcc/gcc/cfgexpand.c:2701
0xe15cab expand_gimple_stmt_1
/home/mpolacek/src/gcc/gcc/cfgexpand.c:3682
0xe1634a expand_gimple_stmt
/home/mpolacek/src/gcc/gcc/cfgexpand.c:3847
0xe1e4f9 expand_gimple_basic_block
/home/mpolacek/src/gcc/gcc/cfgexpand.c:5887
0xe2013b execute
/home/mpolacek/src/gcc/gcc/cfgexpand.c:6542
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/94382] conflicting function types should show more context

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from David Malcolm  ---
Beyond simply showing the entire prototype, some other ideas:

./fs/iomap/apply.c:13:1: error: conflicting types for ‘__iomap_apply’
   13 | __iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned
flags,
   14 |   struct iomap *iomap, struct iomap *srcmap,
  |   ---  
  |   ||
  |   param 5  param 6
   15 |   const struct iomap_ops *ops, iomap_actor_t actor)
  |   ---  ---
  |   ||
  |   param 7  param 8
In file included from ../fs/iomap/apply.c:9:
../include/linux/iomap.h:152:1: note: previous declaration of ‘__iomap_apply’
was here
  152 | __iomap_apply(struct inode *inode, loff_t pos, loff_t length, unsigned
flags,
  153 |   const struct iomap_ops *ops, iomap_actor_t actor,
  |   ---  ---
  ||   |
  |param 5 param 6
  154 |   struct iomap *iomap, struct iomap *srcmap);
  |   ---  
  ||   |
  |param 7 param 8
note: you've transposed params 5 and 7, and params 6 and 8

But it's probably simplest to just show the full prototype.

[Bug c++/94628] [8/9 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |invalid_nonstatic_memfn_p   |invalid_nonstatic_memfn_p
   |at cp/typeck.c:1979 since   |at cp/typeck.c:1979 since
   |r9-640-g1268ecc26fc1289b|r9-640-g1268ecc26fc1289b

--- Comment #14 from Patrick Palka  ---
Fixed for GCC 10 so far.

[Bug c++/43382] [C++0x] ICE with auto return type and variadic templates

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r10-7835-ga3a4f6be0c7ac1536c4d1def14217840b04dd488
Author: Patrick Palka 
Date:   Mon Apr 20 18:34:00 2020 -0400

c++: Recursive unification with packs and explicit targs [PR94628]

This PR seems to be similar to PR c++/43382, except that the recursive call
to
the variadic function with trailing return type in this testcase is
additionally
given some explicit template arguments.

In the first testcase below, when resolving the recursive call to 'select',
fn_type_unification first substitutes in the call's explicit template
arguments
before doing unification, and so during this substitution the template
argument
pack for Args is incomplete.

Since the pack is incomplete, the substitution of 'args...' in the trailing
return type decltype(f(args...)) is handled by the unsubstituted_packs case
of
tsubst_pack_expansion.  But the handling of this case happens _before_ we
reset
local_specializations, and so the substitution ends up reusing the old
binding
for 'args' from local_specializations rather than building a new one.

This patch fixes this issue by setting up local_specializations sooner in
tsubst_pack_expansion, before the handling of the unsubstituted_packs case.
It also adds a new policy to local_specialization_stack so that we could
use the
class here to conditionally replace local_specializations.

gcc/cp/ChangeLog:

PR c++/94628
* cp-tree.h (lss_policy::lss_nop): New enumerator.
* pt.c (local_specialization_stack::local_specialization_stack):
Handle
an lss_nop policy.
(local_specialization_stack::~local_specialization_stack):
Likewise.
(tsubst_pack_expansion): Use a local_specialization_stack instead
of
manually saving and restoring local_specializations.  Conditionally
replace local_specializations sooner, before the handling of the
unsubstituted_packs case.

gcc/testsuite/ChangeLog:

PR c++/94628
* g++.dg/cpp0x/variadic179.C: New test.
* g++.dg/cpp0x/variadic180.C: New test.

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[cvs-commit at gcc dot gnu.org]

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r10-7835-ga3a4f6be0c7ac1536c4d1def14217840b04dd488
Author: Patrick Palka 
Date:   Mon Apr 20 18:34:00 2020 -0400

c++: Recursive unification with packs and explicit targs [PR94628]

This PR seems to be similar to PR c++/43382, except that the recursive call
to
the variadic function with trailing return type in this testcase is
additionally
given some explicit template arguments.

In the first testcase below, when resolving the recursive call to 'select',
fn_type_unification first substitutes in the call's explicit template
arguments
before doing unification, and so during this substitution the template
argument
pack for Args is incomplete.

Since the pack is incomplete, the substitution of 'args...' in the trailing
return type decltype(f(args...)) is handled by the unsubstituted_packs case
of
tsubst_pack_expansion.  But the handling of this case happens _before_ we
reset
local_specializations, and so the substitution ends up reusing the old
binding
for 'args' from local_specializations rather than building a new one.

This patch fixes this issue by setting up local_specializations sooner in
tsubst_pack_expansion, before the handling of the unsubstituted_packs case.
It also adds a new policy to local_specialization_stack so that we could
use the
class here to conditionally replace local_specializations.

gcc/cp/ChangeLog:

PR c++/94628
* cp-tree.h (lss_policy::lss_nop): New enumerator.
* pt.c (local_specialization_stack::local_specialization_stack):
Handle
an lss_nop policy.
(local_specialization_stack::~local_specialization_stack):
Likewise.
(tsubst_pack_expansion): Use a local_specialization_stack instead
of
manually saving and restoring local_specializations.  Conditionally
replace local_specializations sooner, before the handling of the
unsubstituted_packs case.

gcc/testsuite/ChangeLog:

PR c++/94628
* g++.dg/cpp0x/variadic179.C: New test.
* g++.dg/cpp0x/variadic180.C: New test.

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

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The false positive is not due a shortcoming of the warning but rather due to
GCC not having a sufficiently sophisticated analysis of relationships of
pointers into the same objects.  The same warning (and probably a numbers as
well) can be reproduced with a simpler example.

$ cat pr94675.c && gcc -O2 -S -Wall -fdump-tree-vrp=/dev/stdout pr94675.c
unsigned char c, n;

int f (void)
{
  if (n <= 7) return 0;

  unsigned char *p = , *q = p + n;

  if (q - p <= 7)   // not eliminated
return 0;

  return p[7];  // spurious -Warray-bounds
}

;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=2)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 4 3 }
;; 3 succs { 4 }
;; 4 succs { 1 }

Value ranges after VRP:

n.0_1: unsigned char VARYING
_2: unsigned char VARYING
_3: int [0, 255]
_5: int [0, 255]


pr94675.c: In function ‘f’:
pr94675.c:12:11: warning: array subscript 7 is outside array bounds of
‘unsigned char[1]’ [-Warray-bounds]
   12 |   return p[7];
  |  ~^~~
pr94675.c:1:15: note: while referencing ‘c’
1 | unsigned char c, n;
  |   ^
f ()
{
  unsigned char n.0_1;
  unsigned char _2;
  int _3;
  int _5;

   [local count: 1073741824]:
  n.0_1 = n;
  if (n.0_1 <= 7)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 708669601]:
  _2 = MEM[(unsigned char *) + 7B];
  _5 = (int) _2;

   [local count: 1073741824]:
  # _3 = PHI <0(2), _5(3)>
  return _3;

}



;; Function f (f, funcdef_no=0, decl_uid=1932, cgraph_uid=1, symbol_order=2)

;; 1 loops found
;;
;; Loop 0
;;  header 0, latch 1
;;  depth 0, outer -1
;;  nodes: 0 1 2 3 4
;; 2 succs { 4 3 }
;; 3 succs { 4 }
;; 4 succs { 1 }

Value ranges after VRP:

n.0_1: unsigned char VARYING
_2: unsigned char VARYING
_3: int [0, 255]
_5: int [0, 255]


f ()
{
  unsigned char n.0_1;
  unsigned char _2;
  int _3;
  int _5;

   [local count: 1073741824]:
  n.0_1 = n;
  if (n.0_1 <= 7)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 708669601]:
  _2 = MEM[(unsigned char *) + 7B];
  _5 = (int) _2;

   [local count: 1073741824]:
  # _3 = PHI <_5(3), 0(2)>
  return _3;

}

[Bug target/91970] arm: 64bit int to double conversion does not respect rounding mode

[joseph at codesourcery dot com]

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

--- Comment #13 from joseph at codesourcery dot com  ---
bpabi-lib.h is the existing mechanism for renaming libgcc2.c functions and 
declaring them with __attribute__((pcs("aapcs"))).  (But when causing more 
such functions to be used, or such functions to be used when they weren't 
before, we'd need to make sure all the declarations therein are being 
applied properly in the new cases to give the functions the desired ABI.)

[Bug fortran/92993] [8/9 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |maybe_canonicalize_comparis |maybe_canonicalize_comparis
   |on_1, at fold-const.c:8845  |on_1, at fold-const.c:8845

--- Comment #6 from Thomas Koenig  ---
(In reply to anlauf from comment #4)
> The testcase in comment#0 compiles for me with today's master.
> Has this been fixed accidentally?  Maybe someone can bisect
> so that one can identify the commit that might be backported
> to fix the regression.

This probably was

https://gcc.gnu.org/g:2298af0800b292f028298c1eaec42fd3033c4b9b

the fix for PR94090.

I think this is something that could be backported.

[Bug c++/91241] [8/9/10 Regression] internal compiler error: symtab_node::verify failed

[mpolacek at gcc dot gnu.org]

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

--- Comment #8 from Marek Polacek  ---
Ping, can we get this fixed in GCC 10?

[Bug libstdc++/94674] std::ranges::basic_istream_view::iterator is missing std::iterator_traits entries

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
Your mistake is thinking that the iterators of views are like the iterators
you're used to.

They're not.

They have different properties (e.g. they might not be copyable, they might not
have operator->, they might not define iterator_category) and
std::iterator_traits is for use with the old kind of iterators, not the new
ones.

[Bug libstdc++/94674] std::ranges::basic_istream_view::iterator is missing std::iterator_traits entries

[redi at gcc dot gnu.org]

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

--- Comment #4 from Jonathan Wakely  ---
That iterator doesn't have a pointer type, because in the new Ranges world that
type is not useful. It is no longer required for iterators to have operator->
so what does the 'pointer' type even mean?

[Bug middle-end/94647] [10 Regression] bogus -Warray-bounds on strncpy into a larger member array from a smaller array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544173.html

[Bug middle-end/94635] [OpenMP][Offloading] mapping with alloc/delete followed by map(from/tofrom:) fails

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r10-7833-g3f5d94c192b81a3868f32f309dadd5571ef51cdf
Author: Thomas Schwinge 
Date:   Mon Apr 20 16:15:07 2020 +0200

Add 'dg-do run' to 'libgomp.fortran/target-enter-data-2.F90'

Fix-up for commit af557050fd011a03d21dc26b31959033061a0443 "[OpenMP] Fix
'omp
exit data' for Fortran arrays (PR 94635)".

libgomp/
PR middle-end/94635
* testsuite/libgomp.fortran/target-enter-data-2.F90: Add 'dg-do
run'.

[Bug ipa/93385] [10 Regression] wrong code with u128 modulo at -O2 -fno-dce -fno-ipa-cp -fno-tree-dce

[jamborm at gcc dot gnu.org]

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

--- Comment #30 from Martin Jambor  ---
Created attachment 48320
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48320=edit
Todays WIP patch

This is my todays (still very much) WIP patch.

- It marks statements which should not be copied before copying them
  and then skipping them.
- It does map SSA_NAMEs which should not survive to error_mark_node.
- Processing of calls is however still necessary, we cannot leave
  error_mark_nodes in the IL (until call redirection deals with it
  based on callee info).

But:

- It ICEs on gcc.dg/torture/pr48063.c.  I understand the problem,
  IPA-CP attempts to replace a floating-point parameter with an
  integer constant and fails but this fools the new DCE thingy into
  thinking some analysis declared the parameter unused even though it
  is used.  I'll have to make ipa_param_body_adjustments aware of
  tree_map.  (The original idea was to make it part of tree_map but
  for some reason I gave up on that.)

- There are three libgomp C++ ICEs that I know about which I have not
  even looked at.  I have not attempted any bootstrap yet.  I have not
  yet tested anything other than C/C++/Fortran.

- The new hash maps, or at least the one for statements, might be
  better placed in copy_body_data, the current place is just more
  convenient for the moment.  I do not care too much.

- Information currently stored in m_dead_ssas might be obtainable from
  decl_map in copy_body_data.

- I have not thought about debug statements yet and just ignored them
  for now.  I do want to handle them after other things work.

Any feedback welcome.

[Bug rtl-optimization/92430] [9 Regression] Compile-time hog w/ -Os -fno-if-conversion -fno-tree-dce -fno-tree-loop-optimize -fno-tree-vrp

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #10 from Jeffrey A. Law  ---
This was fixed in gcc-9 a few months back.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

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

--- Comment #20 from Iain Buclaw  ---
(In reply to David Binderman from comment #19)
> (In reply to ibuclaw from comment #17)
> > (In reply to David Binderman from comment #16)
> > > 
> > > I am struggling to understand what this output means:
> > > 
> > It's picking up the modules from a system location.  These most certainly
> > don't belong to the gdc compiler.  Which bad package maintainer is
> > installing compiler-specific modules in a common location? LDC?
> 
> I have package ldc-druntime-devel version 1.15.0 installed, 
> so that looks to be the source of the problem.

Yes, that would most certainly be the case.

I can apply the patch anyway, as it's good to not ICE.  However it won't
prevent the possibility of linker errors due to mismatches in ldc-druntime-dev
and libgphobos.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

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

--- Comment #19 from David Binderman  ---
(In reply to ibuclaw from comment #17)
> (In reply to David Binderman from comment #16)
> > 
> > I am struggling to understand what this output means:
> > 
> It's picking up the modules from a system location.  These most certainly
> don't belong to the gdc compiler.  Which bad package maintainer is
> installing compiler-specific modules in a common location? LDC?

I have package ldc-druntime-devel version 1.15.0 installed, 
so that looks to be the source of the problem.

[Bug fortran/92065] [8/9/10 Regression] internal compiler error: in expand_expr_real_1

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
The testcase in comment#0 does not ICE if in function fun2 the
second dummy argument is declared as TYPE instead of CLASS, i.e.

type (bar), intent(in) :: a(this%n) ! no ICE

instead of

class(bar), intent(in) :: a(this%n)

Maybe this rings a bell with someone.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

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

--- Comment #18 from Iain Buclaw  ---
(In reply to ibuclaw from comment #17)
> It's picking up the modules from a system location.  These most certainly
> don't belong to the gdc compiler.  Which bad package maintainer is
> installing compiler-specific modules in a common location? LDC?

A quick look at ldc on app.fedoraproject.org, and there's a reference to this
bug report.

https://bugzilla.redhat.com/show_bug.cgi?id=1781685

[Bug libstdc++/94674] std::ranges::basic_istream_view::iterator is missing std::iterator_traits entries

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

--- Comment #3 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
Thank you for pointing me to this.

I find this highly unexpected. There was made a change to `std::type_traits` in
C++20 that sets default values, but it does not apply to all iterators?

My use case was slightly different, I wanted to extract the `pointer` member
type and there is no equivalent like `std::ranges::range_pointer_t` for that.

This makes it particularly cumbersome to "forward" properties of an underlying
iterator which is used when wrapping it in a new iterator.

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

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-04-20
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |sandra at gcc dot 
gnu.org

--- Comment #2 from Thomas Schwinge  ---
I'm not very familiar with IPA optimizations, I'm not yet clear on what can be
done (optimized) with reasonable effort in GCC, and where/how, so will very
much appreciate your input, Jakub, Richard, others.

Sandra is going to look into this topic (who is not too familiar with OMP
handling).

As a first step, we shall not consider any offloading compilation specifics,
but just the usual host-side compilation.

Looking at the following simple example:

int main(void)
{
  int var;
#pragma acc parallel copyout(var)
#pragma omp target map(from:var)
  {
var = 1;
  }
  // 'var' never read.

  return 0;
}

For reference, with '-fno-openacc -fno-openmp -O1' (so, OMP deactiveated,
pragmas ignored), the 'var = 1' assignment disappears in the '030t.ccp1' dump
file, and 'var' itself disappears in the '047t.release_ssa' dump file.

With OMP enabled ('-fopenacc' shown in the following, but '-fopenmp' is very
similar), it's more difficult to optimize 'var': the OMP region (here: just the
'var = 1' assignment, plus any set-up and tear-down code) is moved (outlined)
into a separate function 'main._omp_fn.0', and the address of 'var' is taken,
stored in an internal data structure '.omp_data_arr.1', and is dereferenced in
'main._omp_fn.0' to access the original 'var'.  The outlined function
'main._omp_fn.0' is called via 'GOACC_parallel_keyed'.

One step is to add logic so that in this example, we can optimize 'copyout' to
'create'.  The 'copyout' clauses is encoded in '.omp_data_kinds.3[0]' as value
'514', where with the upper data alignment byte stripped off, '514 & 255 = 2',
which is 'GOMP_MAP_FROM'.  This shall -- at a suitable point in the pass
pipeline -- be optimized to 'GOMP_MAP_ALLOC'.

Another step is to add logic so that the "dead"ness of 'var' after the outlined
function 'main._omp_fn.0' called via 'GOACC_parallel_keyed' gets propagated
into 'main._omp_fn.0', so that the 'var = 1' assignment can be eliminated.

By the way, there already is some special IPA information handling for
'GOACC_parallel_keyed' ('BUILT_IN_GOACC_PARALLEL') in
'gcc/tree-ssa-structalias.c'.  This is, if I remember correctly, to evaluate
aliasing "transparently through" the outlined OMP function; see the PR46032
commit r231076 "Handle BUILT_IN_GOMP_PARALLEL in ipa-pta" and later commits,
for reference.  (And, there is a 'pass_oacc_ipa' to enable '-fipa-pta' for
OpenACC OMP functions.)

Working on eliminating 'var' completely from the internal '.omp_data_arr.1'
etc. data structures shall be a separate step, for later.  If that elimination
happens when we're already in offloading compilation pipeline, this is expected
to require more infrastructure to communicate that information back from the
offloading compiler(s) to the host compiler/runtime.


But first one step back -- I noticed that compiling the following:

#pragma acc routine
#pragma omp declare target
static void __attribute__((noinline)) f(int *var)
{
  *var = 1;
}
#pragma omp end declare target

int main(void)
{
  int var;
#pragma acc parallel copyout(var)
#pragma omp target map(from:var)
  {
f();
  }
  // 'var' never read.

  return 0;
}

... with '-fno-openacc -fno-openmp -O1' (so, OMP deactiveated, pragmas ignored)
also does *not* see any optimization of 'var'.  Is that something that needs to
be addressed first, before attempting the OMP case?

[Bug c++/94505] Logical operator inside fold-expression: strange warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Fixed in GCC 9.4 and 10.

[Bug c++/94505] Logical operator inside fold-expression: strange warning

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:83eeda5f004c3b9cbeccd3da1c3fe58b3015e55f

commit r9-8518-g83eeda5f004c3b9cbeccd3da1c3fe58b3015e55f
Author: Marek Polacek 
Date:   Mon Apr 20 15:43:49 2020 -0400

c++: Fix bogus -Wparentheses warning with fold-expression [PR94505]

We issue bogus -Wparentheses warnings (3 of them!) for this fold
expression:

  ((B && true) || ...)

Firstly, issuing a warning for a compiler-generated expression is wrong
and secondly, B && true must be wrapped in ( ) otherwise you'll get
error: binary expression in operand of fold-expression.

PR c++/94505 - bogus -Wparentheses warning with fold-expression.
* pt.c (fold_expression): Add warning_sentinel for -Wparentheses
before calling build_x_binary_op.

* g++.dg/cpp1z/fold11.C: New test.

[Bug tree-optimization/94675] New: [9 regression] -Warray-bounds false positive with -O2

[chantry.xavier at gmail dot com]

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

Bug ID: 94675
   Summary: [9 regression] -Warray-bounds false positive with -O2
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chantry.xavier at gmail dot com
  Target Milestone: ---

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

Tested with gcc 9.1 9.2 and 9.3 on godbolt.

Compiling with "-O2 -Warray-bounds" gives the following false positive :

---
: In function 'f':
:38:11: warning: array subscript 7 is outside array bounds of 'byte[1]'
{aka 'unsigned char[1]'} [-Warray-bounds]
   38 | ps->s += len;
  |   ^~
:46:6: note: while referencing 'c'

   46 | byte c;
  |  ^
Compiler returned: 0
---

Error also with -O3 but not with -O.

Note that the error goes after removing the assert.

[Bug c++/94590] Incorrectly accepts invalid C++11 braced initialisation of double from long double if sizeof(long double)==sizeof(double)

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #5 from Marek Polacek  ---
Patch approved for GCC 11:

[Bug libstdc++/94674] std::ranges::basic_istream_view::iterator is missing std::iterator_traits entries

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
The current disposition of the Library Working Group is to leave it that way,
because it doesn't meet the traditional iterator requirements, so it's expected
that iterator_traits is empty for it.

As you already know, you can use range_value_t to get the value
type instead, and range_difference_t for the difference type, and use the
concepts std::input_iterator, std::forward_iterator etc. to determine which
concepts it satisfies. Code written to work with ranges should rely on those
interfaces, not iterator_traits, which is for traditional iterator types.

[Bug fortran/92993] [8/9/10 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[anlauf at gcc dot gnu.org]

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #4)
> The testcase in comment#0 compiles for me with today's master.

Read: does not ICE; just gives an appropriate error message:

z1.f90:8:6:

8 |   function f(x)
  |  1
Error: Interface mismatch in global procedure 'f' at (1): POINTER attribute
mismatch in function result

[Bug fortran/92993] [8/9/10 Regression] ICE in maybe_canonicalize_comparison_1, at fold-const.c:8845

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #4 from anlauf at gcc dot gnu.org ---
The testcase in comment#0 compiles for me with today's master.
Has this been fixed accidentally?  Maybe someone can bisect
so that one can identify the commit that might be backported
to fix the regression.

[Bug c++/94505] Logical operator inside fold-expression: strange warning

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-7830-g5bdd4c5d3fc9c143e8edea3b10828e4b75d7a385
Author: Marek Polacek 
Date:   Sun Apr 19 12:12:01 2020 -0400

c++: Fix bogus -Wparentheses warning with fold-expression [PR94505]

We issue bogus -Wparentheses warnings (3 of them!) for this fold
expression:

  ((B && true) || ...)

Firstly, issuing a warning for a compiler-generated expression is wrong
and secondly, B && true must be wrapped in ( ) otherwise you'll get
error: binary expression in operand of fold-expression.

PR c++/94505 - bogus -Wparentheses warning with fold-expression.
* pt.c (fold_expression): Add warning_sentinel for -Wparentheses
before calling build_x_binary_op.

* g++.dg/cpp1z/fold11.C: New test.

[Bug libstdc++/94674] std::ranges::basic_istream_view::iterator is missing std::iterator_traits entries

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
This is a known defect in the C++20 draft:
https://cplusplus.github.io/LWG/issue3394

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gcc dot gnu.org]

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

ibuclaw at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ibuclaw at gcc dot gnu.org

--- Comment #17 from ibuclaw at gcc dot gnu.org ---
(In reply to David Binderman from comment #16)
> 
> I am struggling to understand what this output means:
> 
> binary   
> /home/dcb/gcc/results.20200420.d5/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/d21
> version   v2.076.1
> predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions
> GNU_StackGrowsDown GNU_InlineAsm D_LP64 assert D_ModuleInfo D_Exceptions
> D_TypeInfo all X86_64 D_HardFloat Posix linux CRuntime_Glibc CppRuntime_Gcc
> parse interpret3
> importall interpret3
> importobject  (/usr/include/d/object.d)
> importcore.internal.hash  (/usr/include/d/core/internal/hash.d)
> importcore.internal.traits(/usr/include/d/core/internal/traits.d)
> importcore.internal.convert   (/usr/include/d/core/internal/convert.d)
> semantic  interpret3
> importcore.stdc.string(/usr/include/d/core/stdc/string.d)


It's picking up the modules from a system location.  These most certainly don't
belong to the gdc compiler.  Which bad package maintainer is installing
compiler-specific modules in a common location? LDC?

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

 CC||frederik at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #20 from Thomas Schwinge  ---
(In reply to Leo Yuriev from comment #0)
> https://habr.com/en/company/pvs-studio/blog/497640/

I've asked Frederik to look into "Fragment N3, Assigning a variable to itself";
.

[Bug c++/94255] template specialization in different namespace causes crash

[mpolacek at gcc dot gnu.org]

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

--- Comment #6 from Marek Polacek  ---
Patch approved for GCC 11:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544081.html

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[marxin at gcc dot gnu.org]

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

--- Comment #12 from Martin Liška  ---
> How many times do you have to be told to test your patches?  Besides,
> Patrick is already working on this PR.

As Marek said, it's really unpleasant to send untested patches and so come up
with noise in bug reports.

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[mpolacek at gcc dot gnu.org]

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

--- Comment #11 from Marek Polacek  ---
(In reply to Nicholas Krause from comment #9)
> Created attachment 48318 [details]
> Possible Fix

No, it's not a fix, it just replaces an ICE with another ICE, as Martin already
pointed out:

94628-3.C:5:40: internal compiler error: tree check: expected
template_type_parm or template_template_parm or bound_template_template_parm,
have 
nontype_argument_pack in instantiation_dependent_r, at cp/pt.c:26950

and doesn't fix the rejects-valid testcase, either.

How many times do you have to be told to test your patches?  Besides, Patrick
is already working on this PR.

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[xerofoify at gmail dot com]

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

--- Comment #10 from Nicholas Krause  ---
(In reply to Martin Liška from comment #8)
> (In reply to Nicholas Krause from comment #7)
> > After adding this it seems to work for me, Patrick:
> >case TYPE_ARGUMENT_PACK:
> > if (value_dependent_expression_p(TREE_TYPE(*tp)))
> >  return *tp;
> > if (TEMPLATE_TYPE_PARAMETER_PACK(*tp))
> >  return *tp;
> > return NULL_TREE;
> > 
> > and gives me:
> > test.c: In function ‘std::common_type_t > (forward(f)(std::integral_constant(),
> > (forward)(args)...)), decltype
> > (forward(f)(int_constant(), (forward)(args)...))...>
> > select(int, F&&, Args&& ...)’:
> > test.c:14:12: warning: ‘if constexpr’ only available with ‘-std=c++17’ or
> > ‘-std=gnu++17’
> >14 | if constexpr(sizeof...(Is)>0)
> >   |^
> > test.c: In function ‘std::common_type_t > (forward(f)(std::integral_constant(),
> > (forward)(select::args)...)), decltype
> > (forward(f)(int_constant(),
> > (forward)(select::args)...))...> select(int, F&&,
> > Args&& ...) [with int I = 1; int ...Is = {}; F = t(int)::;
> > Args = {}]’:
> > test.c:17:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >17 | }
> >   | ^
> > 
> > with no segfault. I'm not sure if this is the correct part to add this test
> > for TYPE_ARGUMENT_PACK or if we would prefer it to be lower in the stack.
> 
> The suggested change is wrong:
> 
> /home/marxin/Programming/gcc2/objdir/./gcc/xgcc -shared-libgcc
> -B/home/marxin/Programming/gcc2/objdir/./gcc -nostdinc++
> -L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src
> -L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/src/.
> libs
> -L/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> libsupc++/.libs -B/usr/local/x86_64-pc-linux-gnu/bin/
> -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
> /usr/local/x86_64-pc-linux-gnu/include -isystem
> /usr/local/x86_64-pc-linux-gnu/sys-include-x c++-header -nostdinc++ -g
> -O2 -D_GNU_SOURCE 
> -I/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> include/x86_64-pc-linux-gnu
> -I/home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> include -I/home/marxin/Programming/gcc2/libstdc++-v3/libsupc++  -O2 -g
> -std=gnu++0x
> /home/marxin/Programming/gcc2/libstdc++-v3/include/precompiled/stdc++.h \
> -o x86_64-pc-linux-gnu/bits/stdc++.h.gch/O2ggnu++0x.gch
> In file included from
> /home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> include/cmath:42,
>  from
> /home/marxin/Programming/gcc2/libstdc++-v3/include/precompiled/stdc++.h:41:
> /home/marxin/Programming/gcc2/objdir/x86_64-pc-linux-gnu/libstdc++-v3/
> include/bits/cpp_type_traits.h:89:63: internal compiler error: tree check:
> expected template_type_parm or template_template_parm or
> bound_template_template_parm, have tree_list in instantiation_dependent_r,
> at cp/pt.c:26926
>89 |   enum { __value = bool(_Sp::__value) || bool(_Tp::__value) };
>   |   ^
> 0x8404c2 tree_check_failed(tree_node const*, char const*, int, char const*,
> ...)
>   ../../gcc/tree.c:9727
> 0x69234b tree_check3(tree_node*, char const*, int, char const*, tree_code,
> tree_code, tree_code)
>   ../../gcc/tree.h:3327
> 0x69234b instantiation_dependent_r
>   ../../gcc/cp/pt.c:26926
> 0x13749b3 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*,
> tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*))
>   ../../gcc/tree.c:11996
> 0xb10a88 cp_walk_subtrees(tree_node**, int*, tree_node* (*)(tree_node**,
> int*, void*), void*, hash_set default_hash_traits >*)
>   ../../gcc/cp/tree.c:5061
> 0x1374a47 walk_tree_1(tree_node**, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*,
> tree_node* (*)(tree_node**, int*, tree_node* (*)(tree_node**, int*, void*),
> void*, hash_set >*))
>   ../../gcc/tree.c:12019
> 0x1377c85 walk_tree_without_duplicates_1(tree_node**, tree_node*
> (*)(tree_node**, int*, void*), void*, tree_node* (*)(tree_node**, int*,
> tree_node* (*)(tree_node**, int*, void*), void*, hash_set default_hash_traits >*))
>   ../../gcc/tree.c:12352
> 0xa97c87 instantiation_dependent_uneval_expression_p(tree_node*)
>   ../../gcc/cp/pt.c:27033
> 0xa9e278 instantiation_dependent_expression_p(tree_node*)
>   ../../gcc/cp/pt.c:27043
> 0x973ba7 is_nondependent_constant_expression(tree_node*)
>   ../../gcc/cp/constexpr.c:8300
> 0x973fca fold_non_dependent_expr_template
>   ../../gcc/cp/constexpr.c:6970
> 0xa98147 build_non_dependent_expr(tree_node*)
>   ../../gcc/cp/pt.c:27531
> 0xb271ef build_x_binary_op(op_location_t const&, tree_code, tree_node*,
> tree_code, tree_node*, tree_code, tree_node**, int)
>   ../../gcc/cp/typeck.c:4245
> 

[Bug c++/94628] [8/9/10 Regression] ICE in invalid_nonstatic_memfn_p at cp/typeck.c:1979 since r9-640-g1268ecc26fc1289b

[xerofoify at gmail dot com]

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

--- Comment #9 from Nicholas Krause  ---
Created attachment 48318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48318=edit
Possible Fix

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

--- Comment #6 from Thomas Koenig  ---
Let's see if I can get this fixed.

[Bug c/94669] libcc1: 4 * minor performance problem

[dcb314 at hotmail dot com]

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

--- Comment #3 from David Binderman  ---
(In reply to Jan Kratochvil from comment #2)
> These fixes are very simple, maybe you can check it in as obvious?

Sorry no, I have no checkin permission.

> BTW the file was written by Alexandre Oliva, I wrote no single line there.

git blame seems to think you wrote it. Maybe it is in error.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

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

--- Comment #16 from David Binderman  ---
(In reply to Iain Buclaw from comment #15)
> Created attachment 48316 [details]
> adjust hardcoded index of Error.bypassException
> 
> Can you apply this and see if it goes away?

I applied your patch and the problem seems to go away.

> If this fixes it, then that answer is almost certainly is yes, you do have
> another (newer) D compiler installed.
> 
> You can also confirm by compiling the test with: gdc -v

I am struggling to understand what this output means:

binary   
/home/dcb/gcc/results.20200420.d5/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/d21
version   v2.076.1
predefs   GNU D_Version2 LittleEndian GNU_DWARF2_Exceptions GNU_StackGrowsDown
GNU_InlineAsm D_LP64 assert D_ModuleInfo D_Exceptions D_TypeInfo all X86_64
D_HardFloat Posix linux CRuntime_Glibc CppRuntime_Gcc
parse interpret3
importall interpret3
importobject(/usr/include/d/object.d)
importcore.internal.hash(/usr/include/d/core/internal/hash.d)
importcore.internal.traits  (/usr/include/d/core/internal/traits.d)
importcore.internal.convert (/usr/include/d/core/internal/convert.d)
semantic  interpret3
importcore.stdc.string  (/usr/include/d/core/stdc/string.d)
semantic2 interpret3
semantic3 interpret3
code  interpret3
function  interpret3.arrayRetTest
function  interpret3.ice3842
function  interpret3.arrayret2
function  interpret3.dotvar1
function  interpret3.dotvar2
function  interpret3.reffunc1
function  interpret3.reffunc2
function  interpret3.reffunc7
function  interpret3.reffunc3
function  interpret3.RefTestStruct.reffunc4
function  interpret3.RefTestStruct.reffunc6

but which gdc says I have no D compiler installed.

[Bug c/94669] libcc1: 4 * minor performance problem

[jan.kratochvil at redhat dot com]

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

Jan Kratochvil  changed:

   What|Removed |Added

 CC||aoliva at gcc dot gnu.org

--- Comment #2 from Jan Kratochvil  ---
These fixes are very simple, maybe you can check it in as obvious?

BTW the file was written by Alexandre Oliva, I wrote no single line there.

[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64

[jakub at gcc dot gnu.org]

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

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

Testsuite coverage.  This passes make -j32 -k check-c++-all
RUNTESTFLAGS=struct-layout-1.exp
on x86_64-linux, but it would be nice to know if it does FAIL on aarch64-linux
and/or arm*-linux-gnueabi.

[Bug target/94666] S/390: ICE on vectorized popcount

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

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

--- Comment #3 from Andreas Krebbel  ---
I've just committed this patch to mainline (and forgot to mention the PR in the
ChangeLog :(

gcc/ChangeLog:

2020-04-20  Andreas Krebbel  

* config/s390/vector.md ("popcountv8hi2_vx", "popcountv4si2_vx")
("popcountv2di2_vx"): Use simplify_gen_subreg.

gcc/testsuite/ChangeLog:

2020-04-20  Andreas Krebbel  

* g++.dg/pr94666.C: New test.

[Bug c++/85046] [8/9/10 Regression] cp/name-lookup.c:6175:53: runtime error: member access within null pointer of type 'struct cp_binding_level'

[nathan at gcc dot gnu.org]

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

--- Comment #8 from Nathan Sidwell  ---
the reduced testcases no longer crash the compiler.  The first emits a correct
error, the second succeeds.

The original testcase still crashes the compiler, after emitting a slew of
errors about ill-formed code.

[Bug target/94622] testsuite/gcc.dg/atomic/c11-atomic-exec-1.c fails on powerpc64le with -mpcrel

[acsawdey at gcc dot gnu.org]

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

--- Comment #2 from acsawdey at gcc dot gnu.org ---
Solution is going to be to always use plq if prefixed, which makes sense anyway
for little endian because it avoids the ugly doubleword swap.

[Bug c++/94674] New: std::ranges::basic_istream_view::iterator is missing std::iterator_traits entries

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 94674
   Summary: std::ranges::basic_istream_view::iterator is missing
std::iterator_traits entries
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

Hi gcc-team,

I'm not sure if I should have named the issue `std::iterator_traits is missing
default values for an iterator` (https://eel.is/c++draft/iterator.traits#3.2).

Maybe I misunderstood this, but I thought that I can query every iterator for
it's traits.

The following code does not work:

```c++
#include 
#include 
#include 

int main()
{
// std::string_view view; // does work
auto && view = std::ranges::basic_istream_view>{}; // does not work
// auto && view = std::ranges::take_view{}; // does work

using iterator_t = std::ranges::iterator_t;
using iter_value1_t = std::iter_value_t;
using iter_value2_t = typename
std::iterator_traits::value_type;

static_assert(std::same_as);
return 0;
}
```

with `g++-10 -std=c++2a`


https://godbolt.org/z/QAfdml

[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

--- Comment #1 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
After playing with this a bit more, I found out that clang actually behaves
differently:

```c++
#include 
#include 

template 
concept same_as = std::is_same_v;

template 
concept foo = requires(t v)
{
{v} -> same_as;
};

// all of them work with gcc and msvc
static_assert(foo); // fails with clang
static_assert(foo); // fails with clang
static_assert(foo); // fails with clang
static_assert(foo);
static_assert(foo);
```

https://godbolt.org/z/MGpfZF

I created an issue at https://bugs.llvm.org/show_bug.cgi?id=45622

[Bug libstdc++/92156] Cannot in-place construct std::any with std::any

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Jonathan Wakely  ---
Patch posted to
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544054.html

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

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

--- Comment #15 from Iain Buclaw  ---
Created attachment 48316
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48316=edit
adjust hardcoded index of Error.bypassException

Can you apply this and see if it goes away?

If this fixes it, then that answer is almost certainly is yes, you do have
another (newer) D compiler installed.

You can also confirm by compiling the test with: gdc -v

That will dump all front-end related information about the imports/semantic
passes (including where a module was found).

[Bug target/94613] S/390, powerpc: Wrong code generated for vec_sel builtin

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Andreas Krebbel :

https://gcc.gnu.org/g:2930bb321794c241d8df5591a5bf447bf89c6e82

commit r10-7827-g2930bb321794c241d8df5591a5bf447bf89c6e82
Author: Andreas Krebbel 
Date:   Mon Apr 20 19:36:33 2020 +0200

PR94613: Fix vec_sel builtin for IBM Z

The vsel instruction is a bit-wise select instruction.  Using an
IF_THEN_ELSE to express it in RTL is wrong and leads to wrong code being
generated in the combine pass.

With the patch the pattern is written using bit operations.  However,
I've just noticed that the manual still demands a fixed point mode for
AND/IOR and friends although several targets emit bit ops on floating
point vectors (including i386, Power, and s390). So I assume this is a
safe thing to do?!

gcc/ChangeLog:

2020-04-20  Andreas Krebbel  

PR target/94613
* config/s390/s390-builtin-types.def: Add 3 new function modes.
* config/s390/s390-builtins.def: Add mode dependent low-level
builtin and map the overloaded builtins to these.
* config/s390/vx-builtins.md ("vec_selV_HW"): Rename to ...
("vsel

PR target/94613
* gcc.target/s390/zvector/pr94613.c: New test.
* gcc.target/s390/zvector/vec_sel-1.c: New test.

[Bug middle-end/94647] [10 Regression] bogus -Warray-bounds on strncpy into a larger member array from a smaller array

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
I'm testing a patch.

-Warray-bounds (and all other similar warnigs) only considers valid accesses to
trailing arrays with zero or one element.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

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

--- Comment #14 from Iain Buclaw  ---
(In reply to David Binderman from comment #13)
> (In reply to Iain Buclaw from comment #12)
> > (In reply to David Binderman from comment #11)
> > > Checking flag "extra" is the one.
> > 
> > Without knowing too much about what that checking flag does.  That would be
> > highly odd if that were the case, as the dmd implementation sits "outside"
> > of gcc.
> > 
> > The only bridge that is connecting the two is d/d-system.h, which does some
> > necessary #define's to fix portability and use of gcc_assert.
> 
> A possible next step is for you to try a build with checking
> flag extra switched on and see what happens.
> 
> At least that would confirm or deny what I am seeing here.
> 
> I don't think bootstrap is required.

I can only deny what you are seeing.  It might be possible that the object.d
module being picked up by gdc is not the same version supplied by libphobos.

Do you have another D compiler installed?  Possibly one newer than 2.078?

More specifically, I'm thinking of https://github.com/dlang/dmd/pull/6689

But the related druntime change did not go in till 8 months (and two releases)
later.

[Bug c++/94673] New: [concepts] What is the return type of local parameters of requires expressions?

[gcc-bugs at marehr dot dialup.fu-berlin.de]

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

Bug ID: 94673
   Summary: [concepts] What is the return type of local parameters
of requires expressions?
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc-bugs at marehr dot dialup.fu-berlin.de
  Target Milestone: ---

What should I expect when I write the following concept:

```c++
#include 
#include 

template 
concept same_as = std::is_same_v;

template 
concept foo = requires(t v)
{
{v} -> same_as;
};

static_assert(foo); // gcc 9 / clang
static_assert(foo); // clang
static_assert(foo); // clang
```

https://godbolt.org/z/rRkCzE

* clang says that the type of the expression `v` is `t`.
* gcc 9 partially agreed on this for `foo`.
* gcc 10 rejects all of them
* msvc has the same opinion as gcc10, but also fails to provide an answer why.


gcc10 gives me an (improvable?) reason why the concept failed:

```
:13:15: note: constraints not satisfied
:8:9:   required by the constraints of 'template concept foo'
:8:15:   in requirements with 'int v'
:10:6: note: 'v' does not satisfy return-type-requirement
```

[Bug c++/94575] Bogus warning: Used variable is “not” used

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #3 from Marek Polacek  ---
Thanks for the updated testcase.  Confirmed.

[Bug c++/94575] Bogus warning: Used variable is “not” used

[bisqwit at iki dot fi]

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

--- Comment #2 from Joel Yliluoma  ---
Sorry, the error Marek Polacek mentions is due to a copypaste mistake on my
part. The correct code that demonstrates the problem is here. The difference is
the && instead of &.

#include 
template
static void Use(T&& plot)
{
plot(1);
}
int main()
{
static const int table[1] = {123456};
Use([&](auto x)
{
unsigned var = table[x];
unsigned ui = var;
std::printf("%u\n", ui);
});
}

[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a

[msebor at gcc dot gnu.org]

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

--- Comment #5 from Martin Sebor  ---
We want stores by user code to be diagnosed based on strict language rules
(e.g., accessing a member via a reference to another member).  To do that we
either have to teach the middle end to avoid taking shortcuts that make the IL
look like invalid user code, or be able to apply more permissive rules for
stores synthesized by it.

I assume the former is what you meant by "modify the  into
_REF[..., off]."  My comment was in support of that because, provided the
latter part actually meant "_REF[something, offsetoff (typeof (something),
field)], it could be added to and subtracted from to obtain pointers to any
other member of "something."  (In contrast,  + N is only valid
for N <= sizeof something.field (flexible arrays aside)).

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[dcb314 at hotmail dot com]

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

--- Comment #13 from David Binderman  ---
(In reply to Iain Buclaw from comment #12)
> (In reply to David Binderman from comment #11)
> > Checking flag "extra" is the one.
> 
> Without knowing too much about what that checking flag does.  That would be
> highly odd if that were the case, as the dmd implementation sits "outside"
> of gcc.
> 
> The only bridge that is connecting the two is d/d-system.h, which does some
> necessary #define's to fix portability and use of gcc_assert.

A possible next step is for you to try a build with checking
flag extra switched on and see what happens.

At least that would confirm or deny what I am seeing here.

I don't think bootstrap is required.

[Bug c++/94575] Bogus warning: Used variable is “not” used

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
I'm getting
94575.C: In function ‘int main()’:
94575.C:15:6: error: cannot bind non-const lvalue reference of type
‘main()::&’ to an rvalue of type ‘main()::’
   15 | });
  |  ^
94575.C:3:20: note:   initializing argument 1 of ‘void Use(T&) [with T =
main()::]’
3 | static void Use(T& plot)
  | ~~~^~~~
instead.  So, not confirmed yet.

[Bug c++/94560] ICE on recursive templated alias

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
This ICE is the same as the second test in bug 93085.

[Bug target/94650] Missed x86-64 peephole optimization: x >= large power of two

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
 Status|NEW |ASSIGNED

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

Using this patch, the following asm is created (-O2):

--cut here--
check:
xorl%eax, %eax
shrq$40, %rdi
setne   %al
ret

test0:
shrq$40, %rdi
jne .L5
ret
.L5:
xorl%edi, %edi
jmp g

test1:
movq%rdi, %rax
shrq$40, %rax
jne .L8
ret
.L8:
jmp g
--cut here--

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[tkoenig at gcc dot gnu.org]

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

--- Comment #5 from Thomas Koenig  ---
So, the problem seems to be that sym->attr.subref_array_pointer is
not set on the original test case.  It should be set by
p => get(r(:)) (or by an equivalent call get2(r)) because
we don't know what the particular subroutine may be doing.

[Bug d/94623] ice for ./gdc.test/compilable/interpret3.d

[ibuclaw at gdcproject dot org]

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

--- Comment #12 from Iain Buclaw  ---
(In reply to David Binderman from comment #11)
> (In reply to David Binderman from comment #10)
> > (In reply to David Binderman from comment #6)
> > > I'll reduce the checking flags down to "no" and see what happens.
> > 
> > It works fine. So it looks like one of the checking flags 
> > (df,extra,fold,rtl,yes) breaks it.
> > 
> > It will take a few hours, but I'll try to find out which one.
> 
> Checking flag "extra" is the one.

Without knowing too much about what that checking flag does.  That would be
highly odd if that were the case, as the dmd implementation sits "outside" of
gcc.

The only bridge that is connecting the two is d/d-system.h, which does some
necessary #define's to fix portability and use of gcc_assert.

[Bug c++/94549] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
I don't see how it makes a difference between whether it is a store created by
the vectorizer or some original user store.
What matters is what ADDR_EXPR picks up SCCVN for the base, and it will pick up
the first one which has the same value; if there are multiple fields starting
at the same address, it can pick any of them.

[Bug tree-optimization/94655] [10 Regression] Implicit assignment operator triggers stringop-overflow warning since r10-5451-gef29b12cfbb4979a

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Using the base object in the MEM_REF instead of the member when accessing
another member should certainly fix it.

Another option might be to somehow mark up these synthesized stores (e.g., by
setting some currently unused bit) to make it clear they were emitted for valid
source code.  I'd prefer the former option since that would preserve the
validity (in the C/C++ sense) of the source code.

[Bug fortran/94672] [10 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Note, just making (some or all) optional PARM_DECLs predetermined shared (or
firstprivate) by the langhook isn't correct, because
subroutine foo (array)
  real, optional :: array(:)
  !$omp parallel default(none) ! { dg-error "enclosing" }
  if (.not.present (array)) stop 1 ! { dg-error "not specified in enclosing" }
  !$omp end parallel
end subroutine
is now correctly rejected, but used to be accepts-invalid before this change.

[Bug fortran/94672] [10 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek  ---
>From quick look, seems the Fortran FE for the dummy optional argument uses
array.0, i.e. a local automatic array descriptor that is assigned if
if (array != 0B && (real(kind=4)[0:] * restrict) array->data != 0B)
something at the start of the function.
While most of the references to array are then replaced with accesses to
array.0,
the PRESENT check is done using the above condition.

So, I guess we should tweak the FE so that for the optional dummy arguments in
data sharing clauses it will add also firstprivate (array) or something similar
(if the original PARM_DECL is only used in PRESENT checks, then firstprivate is
all we need).

[Bug target/94668] [10 Regression] ICE generating float vec_inits since r10-808

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug target/94668] [10 Regression] ICE generating float vec_inits since r10-808

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r10-7819-g5da301cbd81c41b2e9629f55dd1b1889f7dae75e
Author: Richard Sandiford 
Date:   Mon Apr 20 15:43:32 2020 +0100

aarch64: Fix vector builds used by SVE vec_init [PR94668]

This testcase triggered an ICE in rtx_vector_builder::step because
we were trying to use a stepped representation for floating-point
constants.  The underlying problem was that the arguments to
rtx_vector_builder were the wrong way around, meaning that some
variations were likely to be incorrectly encoded for integers
(but probably as a silent failure).

Also, aarch64_sve_expand_vector_init_handle_trailing_constants
tries to extend the trailing constant elements to a full vector
by following the "natural" pattern of the original vector, which
should generally lead to nicer constants.  However, for the testcase,
we'd then end up picking a variable for some elements.  Fixed by
stubbing out all variable elements with zeros.

That fix involved testing valid_for_const_vector_p.  For consistency,
the patch uses the same test when finding trailing constants, instead
of the previous aarch64_legitimate_constant_p.

2020-04-20  Richard Sandiford  

gcc/
PR target/94668
* config/aarch64/aarch64.c (aarch64_sve_expand_vector_init): Fix
order of arguments to rtx_vector_builder.
(aarch64_sve_expand_vector_init_handle_trailing_constants):
Likewise.
When extending the trailing constants to a full vector, replace any
variables with zeros.

gcc/testsuite/
PR target/94668
* gcc.target/aarch64/sve/pr94668.c: New test.

[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component

[tkoenig at gcc dot gnu.org]

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

--- Comment #4 from Thomas Koenig  ---
Taking the slightly modified test case

program array_temps
  implicit none

  type :: tt
 integer :: u = 1
 integer :: v = 2
  end type tt

  type(tt), dimension(:), pointer :: r
  integer :: n
  integer, dimension(:), pointer :: p

  n = 10
  allocate(r(1:n))
  p => get(r)
  call foo(p, n)
  print *,sum(p)

  deallocate(r)

contains

   subroutine foo(a, n)
  integer, dimension(:), intent(in) :: a
  integer, intent(in) :: n
  print *, sum(a(1:n)), n
   end subroutine foo

   function get(x) result(q)
  type(tt), dimension(:), target, intent(in) :: x
  integer, dimension(:), pointer :: q
  q => x(:)%v
   end function get
end program array_temps

and looking at -fdump-tree-original shows something strange.

get looks good:

  {
integer(kind=8) D.3946;
integer(kind=8) D.3947;

D.3946 = ubound.0;
__result->span = 8;
__result->dtype = {.elem_len=4, .rank=1, .type=1};
D.3947 = stride.1;
__result->dim[0].lbound = 1;
__result->dim[0].ubound = D.3946;
__result->dim[0].stride = NON_LVALUE_EXPR ;
__result->data = (void *) &(*x.0)[0].v;
__result->offset = -NON_LVALUE_EXPR ;
  }

so the result for span is set.

The call to get and foo does not look to bad, either:

{
  struct array01_integer(kind=4) ptrtemp.15;
  struct array01_tt * D.4002;
  struct tt[0:] * ifm.16;
  integer(kind=8) D.4004;
  integer(kind=8) D.4005;

  ptrtemp.15.span = 4;
  D.4002 = 
  ifm.16 = (struct tt[0:] *) D.4002->data;
  D.4004 = (D.4002->dim[0].ubound - D.4002->dim[0].lbound) + 1;
  D.4005 = -NON_LVALUE_EXPR dim[0].stride>;
  get (, D.4002);
  p = ptrtemp.15;
}
foo (, );

But it seems that foo does not use the span at all.

OK, so what about the test case

program array_temps
  implicit none

  type :: tt
 integer :: u = 1
 integer :: v = 2
  end type tt

  type(tt), dimension(:), pointer :: r
  integer :: n
  integer, dimension(:), pointer :: p

  n = 10
  allocate(r(1:n))
  p => r%v
  call foo(p, n)
  print *,sum(p)

deallocate(r)

contains

   subroutine foo(a, n)
  integer, dimension(:), intent(in) :: a
  integer, intent(in) :: n
  print *, sum(a(1:n)), n
   end subroutine foo

end program array_temps

?

There, we actually convert the argument on call to foo:

   p = r;
p.data = (void *) &(*(struct tt[0:] *) r.data)[0].v;
p.span = r.span;
p.dim[0].ubound = p.dim[0].ubound + (1 - p.dim[0].lbound);
p.offset = p.offset - (1 - p.dim[0].lbound) * p.dim[0].stride;
p.dim[0].lbound = 1;
{
  integer(kind=4)[0:] * D.3975;
  integer(kind=8) D.3976;
  integer(kind=8) D.3977;
  integer(kind=8) D.3978;
  integer(kind=8) D.3979;
  struct array01_integer(kind=4) atmp.11;
  logical(kind=4) D.3987;
  integer(kind=8) D.3988;
  void * restrict D.3989;
  void * restrict D.3990;
  integer(kind=8) D.3991;
  integer(kind=4)[0:] * D.3995;
  integer(kind=8) D.3996;
  integer(kind=8) D.3997;
  integer(kind=8) D.3998;
  integer(kind=8) D.3999;

  D.3975 = (integer(kind=4)[0:] *) p.data;
  D.3976 = p.offset;
  D.3977 = p.dim[0].lbound;
  D.3978 = p.dim[0].ubound;
  D.3979 = D.3978 - D.3977;
typedef integer(kind=4) [0:];
  atmp.11.dtype = {.elem_len=4, .rank=1, .type=1};
  atmp.11.dim[0].stride = 1;
  atmp.11.dim[0].lbound = 0;
  atmp.11.dim[0].ubound = D.3979;
  D.3987 = D.3979 < 0;
  D.3988 = D.3979 + 1;
  atmp.11.span = 4;
  D.3989 = (void * restrict) __builtin_malloc (D.3987 ? 1 : MAX_EXPR
<(unsigned long) (D.3988 * 4), 1>);
  D.3990 = D.3989;
  atmp.11.data = D.3990;
  atmp.11.offset = 0;
  D.3991 = NON_LVALUE_EXPR ;
  {
integer(kind=8) S.12;
integer(kind=8) D.3993;

D.3993 = p.dim[0].stride;
S.12 = 0;
while (1)
  {
if (S.12 > D.3979) goto L.3;
(*(integer(kind=4)[0:] * restrict) atmp.11.data)[S.12] =
*((integer(kind=4) *) D.3975 + (sizetype) (((S.12 + D.3991) * D.3993 + D.3976)
* p.span));
S.12 = S.12 + 1;
  }
L.3:;
  }
  foo (, );
  __builtin_free ((void *) atmp.11.data);

This is not ideal from a performance perspective, but at least
it generated correct code.

So, it appears that somewhere, that conversion goes missing
(and it would also be enough just to convert the descriptor,
no real need to copy the data).

[Bug fortran/94672] [10 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Status|UNCONFIRMED |NEW
   Priority|P3  |P4
 Ever confirmed|0   |1
Summary|gfortran/OpenMP chokes on   |[10 Regression]
   |PRESENT(array) despite of   |gfortran/OpenMP chokes on
   |SHARED(array): Error:   |PRESENT(array) despite of
   |‘array’ not specified in|SHARED(array): Error:
   |enclosing ‘parallel’|‘array’ not specified in
   ||enclosing ‘parallel’
 CC||burnus at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org
   Last reconfirmed||2020-04-20

--- Comment #1 from Jakub Jelinek  ---
Started with r10-3735-gcb57504a550158913258e5be8ddb991376475efb

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Bas Vodde from comment #4)
> When an operator new gets optimized by the compiler, the framework can't
> keep track of the accounting information and the delete call will report
> that non-allocated memory was deleted.

Obviously memory that wasn't returned from your replacement operator new can't
be passed to your replacement operator delete. If calls to operator new are
combined into fewer calls, or elided completely, then the compiler is also
responsible for combining/eliding the corresponding calls to operator delete.

Read the proposal referenced in the Clang bug you linked to:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3433.html

I don't see any bug with current GCC 10.0.1 snapshots. If I provide a
replacement operator delete then it is only called once, with a pointer that
was returned by the single call to operator new.

[Bug libfortran/93871] COTAN is slow for complex types

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org

--- Comment #48 from ktkachov at gcc dot gnu.org ---
(In reply to CVS Commits from comment #45)
> The master branch has been updated by Fritz Reese :
> 
> https://gcc.gnu.org/g:57391ddaf39f7cb85825c32e83feb1435889da51
> 
> commit r10-7603-g57391ddaf39f7cb85825c32e83feb1435889da51
> Author: Fritz Reese 
> Date:   Tue Apr 7 11:59:36 2020 -0400
> 
> Fix PR fortran/93871 and re-implement degree-valued trigonometric
> intrinsics.
> 
> 2020-04-01  Fritz Reese  
> Steven G. Kargl  
> 
> gcc/fortran/ChangeLog
> 
> PR fortran/93871
> * gfortran.h (GFC_ISYM_ACOSD, GFC_ISYM_ASIND, GFC_ISYM_ATAN2D,
> GFC_ISYM_ATAND, GFC_ISYM_COSD, GFC_ISYM_COTAND, GFC_ISYM_SIND,
> GFC_ISYM_TAND): New.
> * intrinsic.c (add_functions): Remove check for flag_dec_math.
> Give degree trig functions simplification and name resolution
> functions (e.g, gfc_simplify_atrigd () and gfc_resolve_atrigd
> ()).
> (do_simplify): Remove special casing of degree trig functions.
> * intrinsic.h (gfc_simplify_acosd, gfc_simplify_asind,
> gfc_simplify_atand, gfc_simplify_cosd, gfc_simplify_cotand,
> gfc_simplify_sind, gfc_simplify_tand, gfc_resolve_trigd2): Add
> new
> prototypes.
> (gfc_simplify_atrigd, gfc_simplify_trigd, gfc_resolve_cotan,
> resolve_atrigd): Remove prototypes of deleted functions.
> * iresolve.c (is_trig_resolved, copy_replace_function_shallow,
> gfc_resolve_cotan, get_radians, get_degrees, resolve_trig_call,
> gfc_resolve_atrigd, gfc_resolve_atan2d): Delete functions.
> (gfc_resolve_trigd, gfc_resolve_trigd2): Resolve to library
> functions.
> * simplify.c (rad2deg, deg2rad, gfc_simplify_acosd,
> gfc_simplify_asind,
> gfc_simplify_atand, gfc_simplify_atan2d, gfc_simplify_cosd,
> gfc_simplify_sind, gfc_simplify_tand, gfc_simplify_cotand): New
> functions.
> (gfc_simplify_atan2): Fix error message.
> (simplify_trig_call, gfc_simplify_trigd, gfc_simplify_atrigd,
> radians_f): Delete functions.
> * trans-intrinsic.c: Add LIB_FUNCTION decls for sind, cosd, tand.
> (rad2deg, gfc_conv_intrinsic_atrigd, gfc_conv_intrinsic_cotan,
> gfc_conv_intrinsic_cotand, gfc_conv_intrinsic_atan2d): New
> functions.
> (gfc_conv_intrinsic_function): Handle ACOSD, ASIND, ATAND, COTAN,
> COTAND, ATAN2D.
> * trigd_fe.inc: New file. Included by simplify.c to implement
> simplify_sind, simplify_cosd, simplify_tand with code common to
> the
> libgfortran implementation.
> 
> gcc/testsuite/ChangeLog
> 
> PR fortran/93871
> * gfortran.dg/dec_math.f90: Extend coverage to real(10) and
> real(16).
> * gfortran.dg/dec_math_2.f90: New test.
> * gfortran.dg/dec_math_3.f90: Likewise.
> * gfortran.dg/dec_math_4.f90: Likewise.
> * gfortran.dg/dec_math_5.f90: Likewise.
> 
> libgfortran/ChangeLog
> 
> PR fortran/93871
> * Makefile.am, Makefile.in: New make rule for intrinsics/trigd.c.
> * gfortran.map: New routines for {sind, cosd, tand}X{r4, r8,
> r10, r16}.
> * intrinsics/trigd.c, intrinsics/trigd_lib.inc,
> intrinsics/trigd.inc:
> New files. Defines native degree-valued trig functions.

I think this broke the build for bare-metal (newlib) targets like
aarch64-none-elf:

libgfortran/intrinsics/trigd_lib.inc:55:56: error: implicit declaration of
function 'copysignl' [-Werror=implicit-function-declaration]
   55 | #define mpfr_copysign(rop, op1, op2, rnd) rop = SUFFIX(copysign)((op1),
(op2))
  |^~~~

I think newlib doesn't support long double functions well so likely doesn't
have copysignl. Is there some way this use can be conditionalised on library
support?

[Bug fortran/94672] New: gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’

[gcc at abeckmann dot de]

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

Bug ID: 94672
   Summary: gfortran/OpenMP chokes on PRESENT(array) despite of
SHARED(array): Error: ‘array’ not specified in
enclosing ‘parallel’
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gcc at abeckmann dot de
  Target Milestone: ---

Created attachment 48314
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48314=edit
failing testcase

This is a regression in gfortran-10 (reproduced in GNU Fortran (GCC) 10.0.1
20200420 (experimental) built from git master):

gfortran-master -Wall -fopenmp -c gf10bug.f90
gf10bug.f90:10:0:

   10 |IF (PRESENT(array)) THEN
  | 
Error: ‘array’ not specified in enclosing ‘parallel’
gf10bug.f90:10:0: Error: enclosing ‘parallel’

But 'array' *is* 'shared':
!$OMP PARALLEL DO DEFAULT(none) SHARED(array,n) PRIVATE(i)
DO i = 1,n
   IF (PRESENT(array)) THEN

That code is accepted by gfortran <= 9, Flang, Intel, PGI.

[Bug c++/94592] [10 Regression] ICE in non-type template parameter with constexpr constructor

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.3.0

--- Comment #9 from Richard Biener  ---
Indeed works with GCC 9.

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #14 from Nathan Sidwell  ---
Fixed:
* a6f400239d7 2020-04-20 | c++: tpl-tpl-parms are not canonicalizable types
[pr94454] (HEAD -> master, origin/master, origin/HEAD) [Nathan Sidwell]
* 7fcb93431ef 2020-04-20 | c++: Expr pack expansion equality [pr94454] [Nathan
Sidwell]
* aa576f2a860 2020-04-20 | c++: Template argument hashing [pr94454] [Nathan
Sidwell]

[Bug c++/94454] ICE 'canonical types differ for identical types'

[nathan at gcc dot gnu.org]

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

--- Comment #13 from Nathan Sidwell  ---
Created attachment 48313
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48313=edit
testing shim

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
(In reply to Richard Biener from comment #3)
> The question is whether the standard allows eliding of the side-effect
> setting newCalled to true.

It does.

That side effect happens inside a replaceable global allocation function. The
compiler is allowed to optimise away calls to replaceable global allocation
functions.

[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P1  |P2

--- Comment #3 from Richard Biener  ---
While it is a regression on the development "branch" it is a rejects-valid
(not implemented in GCC 9) -> ice-on-valid "regression" only as far as the
GCC 10 release is concerned.

So definitely not release critical.

[Bug ipa/94582] [10 Regression] ICE: verify_cgraph_node failed (error: invalid calls_comdat_local flag)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Assuming fixed.

[Bug c++/94549] [10 Regression] Inherited and constrained constructors are "ambiguous" even if they aren't

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.3.0

--- Comment #2 from Richard Biener  ---
Works with GCC 9.3 but only with additionally specifying -fconcepts

[Bug c++/94546] [10 Regression] unimplemented: unexpected AST of kind nontype_argument_pack

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.3.0

--- Comment #3 from Richard Biener  ---
Works with GCC 9.3 with -std=c++2a -fconcepts (w/o -fconcepts it warns)

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Well, the compiler shouldn't optimize away the allocation and not the
deallocation or vice versa, it needs to either optimize away allocation and all
corresponding deallocations, or none of that.
There were some bugs on the GCC side, but 20200225 snapshot is very old, you
should try something newer, last related fix is from 4 days ago.

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[b...@odd-e.com]

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

--- Comment #5 from Bas Vodde  ---

In the case we found this, it mostly uses the overload for accounting and thus
it doesn't cause a serious problem ('just' a test failure).

If you use the overloaded new/delete for providing your own memory management,
then this would potentially cause a serious problems.

[Bug ipa/94582] [10 Regression] ICE: verify_cgraph_node failed (error: invalid calls_comdat_local flag)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jan Hubicka :

https://gcc.gnu.org/g:48c82310947355665d628d4d1c8e736df9987574

commit r10-7814-g48c82310947355665d628d4d1c8e736df9987574
Author: Jan Hubicka 
Date:   Mon Apr 20 15:25:50 2020 +0200

Fix ICE on invalid calls_comdat_local flag [pr94582]

PR ipa/94582
* tree-inline.c (optimize_inline_calls): Recompute
calls_comdat_local
flag.

* g++.dg/torture/pr94582.C: New test.

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[b...@odd-e.com]

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

--- Comment #4 from Bas Vodde  ---

The newCalled to true in the example was the simplest way to show the behavior.

This bug came up in a open source project called CppuTest. This has the
functionality to detect memory leaks and does so by overloading the operator
new. For each operator new, it keeps accounting information.

When an operator new gets optimized by the compiler, the framework can't keep
track of the accounting information and the delete call will report that
non-allocated memory was deleted.

I assume this is an useful and perfectly legit way of overloading operator
new/delete.

This behavior was caught when running the automated test of the framework,
which failed in the debian build when updating to gcc10:
https://people.debian.org/~doko/logs/gcc10-20200225/cpputest_3.8-7_unstable_gcc10.log

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

[jakub at gcc dot gnu.org]

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

Bug 80051 Summary: gcc/dwarf2out.c: PVS-Studio: V501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051

   What|Removed |Added

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

[Bug other/80051] gcc/dwarf2out.c: PVS-Studio: V501

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Fixed with r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3

[Bug other/94629] 10 issues located by the PVS-studio static analyzer

[leo at yuriev dot ru]

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

--- Comment #19 from Leo Yuriev  ---
(In reply to CVS Commits from comment #4)
> The master branch has been updated by Richard Biener :
> 
> https://gcc.gnu.org/g:a64468a3034dd8e2d0794a5be84b8da544ffe2c3
> 
> commit r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3
> Author: Richard Biener 
> Date:   Fri Apr 17 09:19:32 2020 +0200
> 
> fix PVS studio reported bugs
> 
> 2020-04-17  Richard Biener  
[...]
> * dwarf2out.c (dw_val_equal_p): Fix pasto in
> dw_val_class_vms_delta comparison.
> * optabs.c (expand_binop_directly): Fix pasto in commutation
[...]

Seems the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051 should be closed
as fixed.

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The question is whether the standard allows eliding of the side-effect setting
newCalled to true.

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[b...@odd-e.com]

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

--- Comment #2 from Bas Vodde  ---

Oh wow, does this mean that it is the choice of the compiler to actually call
an overloaded operator new ?

That is interesting. Thanks.

I'd still consider it highly surprising behavior, at least it was for me...

[Bug c++/94671] Wrong behavior with operator new overloading when using O2 for optimization

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
No, this conforms to the standard. See [expr.new]

> An implementation is allowed to omit a call to a replaceable global allocation
> function (17.6.2.1, 17.6.2.2). When it does so, the storage is instead
> provided by the implementation or provided by extending the allocation
> of another new-expression.