[Bug c++/91415] Invalid warning for C++17 sequencing of shift operator E1<

2020-12-03 Thread nico at josuttis dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91415

Nicolai Josuttis  changed:

   What|Removed |Added

 CC||nico at josuttis dot de

--- Comment #11 from Nicolai Josuttis  ---
 int j = i++ << i++;
is still not handled correctly in 9.3, 10.1, and 11.0.

[Bug tree-optimization/98133] [11 Regression] ICE in vectorizable_conversion, at tree-vect-stmts.c:4690

2020-12-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98133

Richard Biener  changed:

   What|Removed |Added

Summary|ICE in  |[11 Regression] ICE in
   |vectorizable_conversion, at |vectorizable_conversion, at
   |tree-vect-stmts.c:4690  |tree-vect-stmts.c:4690
   Priority|P3  |P1
   Target Milestone|--- |11.0

[Bug tree-optimization/98133] ICE in vectorizable_conversion, at tree-vect-stmts.c:4690

2020-12-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98133

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
 CC||joel.hutton at arm dot com
   Assignee|rguenth at gcc dot gnu.org |unassigned at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
#5  0x019c9eeb in vectorizable_conversion (vinfo=0x3985f80, 
stmt_info=0x39c0f70, gsi=0x0, vec_stmt=0x0, slp_node=0x0, 
cost_vec=0x7fffc4f8) at ../../src/trunk/gcc/tree-vect-stmts.c:4686
4686ncopies = vect_get_num_copies (loop_vinfo, vectype_in);
(gdb) p debug_generic_expr (vectype_in)
vector(8) short int
$1 = void
(gdb) p loop_vinfo->vectorization_factor 
$2 = {> = {coeffs = {4, 0}}, }

that can't work.

(gdb) p debug_gimple_stmt (stmt_info->stmt)
patt_10 = (a_15(D)) <<< ??? >>> (-30574);

the TREE_CODE of this is WIDEN_PLUS_EXPR (we seem to miss an entry for
tree_code_name and pretty-printing for this ... so much for using new
tree-codes).

vectorizable_conversion has

  code = gimple_assign_rhs_code (stmt);
  if (!CONVERT_EXPR_CODE_P (code)
  && code != FIX_TRUNC_EXPR
  && code != FLOAT_EXPR
  && code != WIDEN_PLUS_EXPR
  && code != WIDEN_MINUS_EXPR
  && code != WIDEN_MULT_EXPR
  && code != WIDEN_LSHIFT_EXPR)
return false;

so it's supposed to handle this case.  I think the special-case is that
the whole stmt is invariant and thus not participating in determining
the vectorization factor (all ops are invariant).  So we're running into

  /* If op0 is an external or constant def, infer the vector type
 from the scalar type.  */
  if (!vectype_in)
vectype_in = get_vectype_for_scalar_type (vinfo, rhs_type, slp_node);

now we should always be able to use vectype_out for determining ncopies,
we just have to correctly interpret it for WIDEN/NARROW or adjust it.

Leaving to arm folks to resolve.

[Bug target/98124] Z: Load and test LTDBR instruction gets not used for comparison against 0.0

2020-12-03 Thread krebbel at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124

--- Comment #2 from Andreas Krebbel  ---
(In reply to Andreas Krebbel from comment #1)
> LTDBR turns SNaNs into QNaNs and that's not supposed to happen in your
> testcase. We emit LTDBR only with -fno-trapping-math

... or if the result of LTDBR isn't used.

[Bug target/98124] Z: Load and test LTDBR instruction gets not used for comparison against 0.0

2020-12-03 Thread krebbel at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124

Andreas Krebbel  changed:

   What|Removed |Added

 CC||krebbel at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Andreas Krebbel  ---
LTDBR turns SNaNs into QNaNs and that's not supposed to happen in your
testcase. We emit LTDBR only with -fno-trapping-math

[Bug tree-optimization/98133] ICE in vectorizable_conversion, at tree-vect-stmts.c:4690

2020-12-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98133

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
I will have a look.

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

2020-12-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130

--- Comment #2 from Richard Biener  ---
Confirmed.  The issue is that placement new is _not_ __attribute__((malloc)),
it makes PTA consider the object not escaping and then we have DSE do

;; Function append (_ZL6appendPi, funcdef_no=1, decl_uid=2355, cgraph_uid=2,
symbol_order=3)

  Deleted dead store: MEM[(int * *)_4] = value_5(D);

__attribute__((always_inline))
void append (int * value)
{
  void * _2;
  void * _4;

   :
  _2 = p;
  _4 = operator new (8, _2);
  return;

}

[Bug testsuite/98125] [11 Regression] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

2020-12-03 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

Richard Biener  changed:

   What|Removed |Added

Summary|New test case   |[11 Regression] New test
   |g++.dg/pr93195a.C in|case g++.dg/pr93195a.C in
   |r11-5656 has excess errors  |r11-5656 has excess errors
   Target Milestone|--- |11.0

--- Comment #6 from Richard Biener  ---
dg-skip-if I suppose

[Bug c++/80780] Front-end support needed for experimental::source_location

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80780

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

https://gcc.gnu.org/g:9715663f7db7ac57121c9a60dd0078787e274f66

commit r11-5736-g9715663f7db7ac57121c9a60dd0078787e274f66
Author: Jakub Jelinek 
Date:   Fri Dec 4 08:08:39 2020 +0100

c++: Change __builtin_source_location to use __PRETTY_FUNCTION__ instead of
__FUNCTION__ [PR80780]

On Tue, Dec 01, 2020 at 01:03:52PM +, Jonathan Wakely via Gcc-patches
wrote:
> I mentioned in PR 80780 that a __builtin__PRETTY_FUNCTION would have
> been nice, because __FUNCTION__ isn't very useful for C++, because of
> overloading and namespace/class scopes. There are an unlimited number
> of functions that have __FUNCTION__ == "s", e.g. "ns::s(int)" and
> "ns::s()" and "another_scope::s::s(T...)" etc.
>
> Since __builtin_source_location() can do whatever it wants (without
> needing to add __builtin__PRETTY_FUNCTION) it might be nice to use the
> __PRETTY_FUNCTION__ string. JeanHeyd's tests would still need changes,
> because the name would be "s::s(void*)" not "s::s" but that still
> seems better for users.

When I've added template tests for the previous patch, I have noticed that
the current __builtin_source_location behavior is not really __FUNCTION__,
just close, because e.g. in function template __FUNCTION__ is still
"bar" but __builtin_source_location gave "bar<0>".

Anyway, this patch implements above request to follow __PRETTY_FUNCTION__
(on top of the earlier posted patch).

2020-12-04  Jakub Jelinek  

PR c++/80780
* cp-gimplify.c (fold_builtin_source_location): Use 2 instead of 0
as last argument to cxx_printable_name.

* g++.dg/cpp2a/srcloc1.C (quux): Use __PRETTY_FUNCTION__ instead of
function.
* g++.dg/cpp2a/srcloc2.C (quux): Likewise.
* g++.dg/cpp2a/srcloc15.C (S::S): Likewise.
(bar): Likewise.  Adjust expected column.
* g++.dg/cpp2a/srcloc17.C (S::S): Likewise.
(bar): Likewise.  Adjust expected column.

* testsuite/18_support/source_location/1.cc (main): Adjust for
__builtin_source_location using __PRETTY_FUNCTION__-like names
instead
__FUNCTION__-like.
* testsuite/18_support/source_location/consteval.cc (main):
Likewise.

[Bug gcov-profile/97461] [11 Regression] allocate_gcov_kvp() deadlocks in firefox LTO+PGO build (overridden malloc() recursion)

2020-12-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461

--- Comment #24 from Martin Liška  ---
@Honza: PING

[Bug tree-optimization/98123] if-to-switch tests fail on arm

2020-12-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #3 from Martin Liška  ---
Should be really fixed, please reopen if not.

[Bug c/98132] ‘target_mem_ref’ not supported by expression internal error

2020-12-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98132

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-12-04

--- Comment #1 from Martin Liška  ---
Can't reproduce that. Moreover, GCC 6.4.0 is out of support, can you please
test the lastest GCC release (10.x)?

[Bug c++/98130] [11 regression] placement new fails on webkit-gtk-2.28.4 since r11-4745-g58c9de46541ade79

2020-12-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Summary|[11 regression] placement   |[11 regression] placement
   |new fails on|new fails on
   |webkit-gtk-2.28.4   |webkit-gtk-2.28.4 since
   ||r11-4745-g58c9de46541ade79
   Target Milestone|--- |11.0
 CC||hubicka at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
   Last reconfirmed||2020-12-04

--- Comment #1 from Martin Liška  ---
Started with r11-4745-g58c9de46541ade79, -fno-strict-aliasing is not needed.

[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

2020-12-03 Thread amodra at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

Alan Modra  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #5 from Alan Modra  ---
The default implementation of -fpatchable-function-entry is broken and useless
on powerpc64 ELFv1 and ELFv2.  For ELFv1 we get

.section".opd","aw"
.align 3
_Z3foov:
.quad   .L._Z3foov,.TOC.@tocbase,0
.previous
.type   _Z3foov, @function
.L._Z3foov:
.section__patchable_function_entries,"awo",@progbits,_Z3foov
.align 3
.8byte  .LPFE1
.section.text._Z3foov,"axG",@progbits,_Z3foov,comdat
.LPFE1:
nop

So the "o" flag symbol is one in the .opd section, rather than what would be
correct here, .L._Z3foov.

The implementation is even more useless for ELFv2, with the nop appearing in
the global entry code (so providing patch space for only some calls of the
function),
which results in assembler complaints about ".localentry expression is not a
power of 2".

I don't think there is anything wrong with the new testcase, just a lack of
xfail powerpc64*-*-*.

[Bug tree-optimization/98133] New: ICE in vectorizable_conversion, at tree-vect-stmts.c:4690

2020-12-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98133

Bug ID: 98133
   Summary: ICE in vectorizable_conversion, at
tree-vect-stmts.c:4690
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org, rsandifo at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: aarch64-linux-gnu

The following fails:

$ g++ /home/marxin/Programming/gcc/gcc/testsuite/g++.dg/vect/pr96022.cc -Ofast
--param=max-completely-peeled-insns=0 -fno-tree-loop-im -fno-tree-pre -c
during GIMPLE pass: vect
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/vect/pr96022.cc: In function
‘void test(short int, bool, int)’:
/home/marxin/Programming/gcc/gcc/testsuite/g++.dg/vect/pr96022.cc:6:6: internal
compiler error: in vectorizable_conversion, at tree-vect-stmts.c:4690
6 | void test(short a, bool, int p8) {
  |  ^~~~
0x6a2afb vectorizable_conversion
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-stmts.c:4690
0xf08773 vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-stmts.c:10694
0xf23c08 vect_analyze_loop_operations
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-loop.c:1758
0xf23c08 vect_analyze_loop_2
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-loop.c:2478
0xf23c08 vect_analyze_loop(loop*, vec_info_shared*)
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vect-loop.c:2925
0xf48321 try_vectorize_loop_1
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.c:995
0xf48d19 vectorize_loops()
   
/home/marxin/BIG/buildbot/buildworker/marxinbox-gcc-trunk-aarch64/build/gcc/tree-vectorizer.c:1229
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/92729] [avr] Convert the backend to MODE_CC so it can be kept in future releases

2020-12-03 Thread abebeos at lazaridis dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92729

--- Comment #35 from abebeos at lazaridis dot com ---
(In reply to abebeos from comment #11)
> (In reply to John Paul Adrian Glaubitz from comment #10)
> [...]
> > The main problem is apparently that the target hasn't been properly worked
> > on for a long time.
> [...]
> 
> Yes, this seems to result in this barrier:
> 
> => missing stable development environment for the work on the avr backend
> itself (build/test/simulate).
> 
> So this issue here splits into 3 major steps:
> 
> A) create a stable dev environment fro work on the avr backend
[...]

See https://github.com/abebeos/avr-gnu, should work as described.

My tests show:

=> pipcet's aborted non-cc0 backend results in 4 issues.
=> saaadhu's "shelved" non-cc0 backend results in 0 issues.

Tests should be easily reproducible.

We can "talk business" now, i don't need to focus anymore.

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

H.J. Lu  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-Decembe
   ||r/561075.html

--- Comment #10 from H.J. Lu  ---
A patch set is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2020-December/561075.html

[Bug c/98132] New: ‘target_mem_ref’ not supported by expression internal error

2020-12-03 Thread thutt at vmware dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98132

Bug ID: 98132
   Summary: ‘target_mem_ref’ not supported by expression internal
error
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thutt at vmware dot com
  Target Milestone: ---

#if 0
The program below, compiled with:

   x86_64-vmk-linux-gnu-gcc (GCC) 6.4.0
   Copyright (C) 2017 Free Software Foundation, Inc.
   This is free software; see the source for copying conditions.  There is NO
   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

fails with the following internal gcc error and an incorrect warning:

  #‘target_mem_ref’ not supported by expression#’./main.c: In function ‘main’:
  ./main.c:15:12: warning:  is used uninitialized in this function
[-Wuninitialized]
  return (*(uint16*)&ote.field[i] >> i) & 0x1ff;
  ^~~
  ./main.c:19:1: note: ‘ote’ was declared here
   f1(t0_t ote)
   ^~

The compiler used was built in-house.

The command line is:

  CC=

  ${CC}   \
  -nostdinc   \
  -O2 \
  -Wuninitialized \
  -o ./main.o \
  -c ./main.c

#endif


typedef unsigned char uint8;
typedef unsigned short int uint16;

typedef struct t0_t {
   uint8 field[5];
} t0_t;

extern t0_t ote;

static unsigned
f0(t0_t ote, unsigned i)
{
   return (*(uint16*)&ote.field[i] >> i) & 0x1ff;
}

static unsigned
f1(t0_t ote)
{
   int i;
   for (i = 0; i < 4; i++) {
  unsigned j = f0(ote, i);
  if (j == 1) {
 return 1;
  }
   }
   return 0;
}

int
main(int argc, char **argv)
{
   return f1(ote);
}

[Bug tree-optimization/98131] new test case g++.dg/cpp2a/concepts-nodiscard1.C in r11-5719 has excess errors

2020-12-03 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98131

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #1 from Jason Merrill  ---
Added XFAIL for now.

[Bug c++/57111] Generalize -Wfree-nonheap-object to delete

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57111

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #13 from Martin Sebor  ---
(In reply to Jonathan Wakely from comment #12)
> (In reply to Martin Sebor from comment #11)
> > It detects the bug in the test case in comment #0 but only with optimization
> > (to see through inlined calls) and with -Wsystem-headers.
> 
> This seems like a warning that should not be suppressed in system headers.
> 
> Diagnostic pragmas could be added to system headers to suppress false
> positives.

I agree.  I thought it was due to an omission on my part but after checking I
see that the code does jump through all the necessary hoops to trigger even in
system headers, so it's a bug that it doesn't.Let me see what's going on.

[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts

2020-12-03 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed in r11-5733 (with the wrong PR in the comment).

[Bug c++/98019] Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted

2020-12-03 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019

Jason Merrill  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Resolution|FIXED   |---
   Last reconfirmed||2020-12-03

--- Comment #4 from Jason Merrill  ---
Oops, not actually fixed yet, it was only working for me because of another WIP
patch in my tree.

[Bug middle-end/87736] New attributes to mark custom alloc/free function pair

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736
Bug 87736 depends on bug 87731, which changed state.

Bug 87731 Summary: Detection of mismatched alloc/free pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731

   What|Removed |Added

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

[Bug middle-end/87731] Detection of mismatched alloc/free pairs

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Implemented for GCC 11 in r11-5732.

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 87731, which changed state.

Bug 87731 Summary: Detection of mismatched alloc/free pairs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87731

   What|Removed |Added

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

[Bug middle-end/87736] New attributes to mark custom alloc/free function pair

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87736

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Implemented GCC 11 in r11-5732.

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 94527, which changed state.

Bug 94527 Summary: RFE: Add an __attribute__ that marks a function as freeing 
an object
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527

   What|Removed |Added

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

[Bug middle-end/94527] RFE: Add an __attribute__ that marks a function as freeing an object

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #14 from Martin Sebor  ---
Done for GCC 11.

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87403
Bug 87403 depends on bug 90629, which changed state.

Bug 90629 Summary: Support for -Wmismatched-new-delete
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629

   What|Removed |Added

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

[Bug c++/90629] Support for -Wmismatched-new-delete

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Sebor  ---
Done for GCC 11.

[Bug middle-end/94527] RFE: Add an __attribute__ that marks a function as freeing an object

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94527

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-5732-gdce6c58db87ebf7f4477bd3126228e73e497
Author: Martin Sebor 
Date:   Thu Dec 3 15:41:25 2020 -0700

Add support for detecting mismatched allocation/deallocation calls.

PR c++/90629 - Support for -Wmismatched-new-delete
PR middle-end/94527 - Add an __attribute__ that marks a function as freeing
an object

gcc/ChangeLog:

PR c++/90629
PR middle-end/94527
* builtins.c (access_ref::access_ref): Initialize new member.
(compute_objsize): Use access_ref::deref.  Handle simple pointer
assignment.
(expand_builtin): Remove handling of the free built-in.
(call_dealloc_argno): Same.
(find_assignment_location): New function.
(fndecl_alloc_p): Same.
(gimple_call_alloc_p): Same.
(call_dealloc_p): Same.
(matching_alloc_calls_p): Same.
(warn_dealloc_offset): Same.
(maybe_emit_free_warning): Same.
* builtins.h (struct access_ref): Declare new member.
(maybe_emit_free_warning): Make extern.  Make use of access_ref.
Handle -Wmismatched-new-delete.
* calls.c (initialize_argument_information): Call
maybe_emit_free_warning.
* doc/extend.texi (attribute malloc): Update.
* doc/invoke.texi (-Wfree-nonheap-object): Expand documentation.
(-Wmismatched-new-delete): Document new option.
(-Wmismatched-dealloc): Document new option.

gcc/c-family/ChangeLog:

PR c++/90629
PR middle-end/94527
* c-attribs.c (handle_dealloc_attribute): New function.
(handle_malloc_attribute): Handle argument forms of attribute.
* c.opt (-Wmismatched-dealloc): New option.
(-Wmismatched-new-delete): New option.

gcc/testsuite/ChangeLog:

PR c++/90629
PR middle-end/94527
* g++.dg/asan/asan_test.cc: Fix a bug.
* g++.dg/warn/delete-array-1.C: Add expected warning.
* g++.old-deja/g++.other/delete2.C: Add expected warning.
* g++.dg/warn/Wfree-nonheap-object-2.C: New test.
* g++.dg/warn/Wfree-nonheap-object.C: New test.
* g++.dg/warn/Wmismatched-new-delete.C: New test.
* g++.dg/warn/Wmismatched-dealloc-2.C: New test.
* g++.dg/warn/Wmismatched-dealloc.C: New test.
* gcc.dg/Wmismatched-dealloc.c: New test.
* gcc.dg/analyzer/malloc-1.c: Prune out expected warning.
* gcc.dg/attr-malloc.c: New test.
* gcc.dg/free-1.c: Adjust text of expected warning.
* gcc.dg/free-2.c: Same.
* gcc.dg/torture/pr71816.c: Prune out expected warning.
* gcc.dg/tree-ssa/pr19831-2.c: Add an expected warning.
* gcc.dg/Wfree-nonheap-object-2.c: New test.
* gcc.dg/Wfree-nonheap-object-3.c: New test.
* gcc.dg/Wfree-nonheap-object.c: New test.

libstdc++-v3/ChangeLog:

* testsuite/ext/vstring/modifiers/clear/56166.cc: Suppress a false
positive warning.

[Bug c++/90629] Support for -Wmismatched-new-delete

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90629

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r11-5732-gdce6c58db87ebf7f4477bd3126228e73e497
Author: Martin Sebor 
Date:   Thu Dec 3 15:41:25 2020 -0700

Add support for detecting mismatched allocation/deallocation calls.

PR c++/90629 - Support for -Wmismatched-new-delete
PR middle-end/94527 - Add an __attribute__ that marks a function as freeing
an object

gcc/ChangeLog:

PR c++/90629
PR middle-end/94527
* builtins.c (access_ref::access_ref): Initialize new member.
(compute_objsize): Use access_ref::deref.  Handle simple pointer
assignment.
(expand_builtin): Remove handling of the free built-in.
(call_dealloc_argno): Same.
(find_assignment_location): New function.
(fndecl_alloc_p): Same.
(gimple_call_alloc_p): Same.
(call_dealloc_p): Same.
(matching_alloc_calls_p): Same.
(warn_dealloc_offset): Same.
(maybe_emit_free_warning): Same.
* builtins.h (struct access_ref): Declare new member.
(maybe_emit_free_warning): Make extern.  Make use of access_ref.
Handle -Wmismatched-new-delete.
* calls.c (initialize_argument_information): Call
maybe_emit_free_warning.
* doc/extend.texi (attribute malloc): Update.
* doc/invoke.texi (-Wfree-nonheap-object): Expand documentation.
(-Wmismatched-new-delete): Document new option.
(-Wmismatched-dealloc): Document new option.

gcc/c-family/ChangeLog:

PR c++/90629
PR middle-end/94527
* c-attribs.c (handle_dealloc_attribute): New function.
(handle_malloc_attribute): Handle argument forms of attribute.
* c.opt (-Wmismatched-dealloc): New option.
(-Wmismatched-new-delete): New option.

gcc/testsuite/ChangeLog:

PR c++/90629
PR middle-end/94527
* g++.dg/asan/asan_test.cc: Fix a bug.
* g++.dg/warn/delete-array-1.C: Add expected warning.
* g++.old-deja/g++.other/delete2.C: Add expected warning.
* g++.dg/warn/Wfree-nonheap-object-2.C: New test.
* g++.dg/warn/Wfree-nonheap-object.C: New test.
* g++.dg/warn/Wmismatched-new-delete.C: New test.
* g++.dg/warn/Wmismatched-dealloc-2.C: New test.
* g++.dg/warn/Wmismatched-dealloc.C: New test.
* gcc.dg/Wmismatched-dealloc.c: New test.
* gcc.dg/analyzer/malloc-1.c: Prune out expected warning.
* gcc.dg/attr-malloc.c: New test.
* gcc.dg/free-1.c: Adjust text of expected warning.
* gcc.dg/free-2.c: Same.
* gcc.dg/torture/pr71816.c: Prune out expected warning.
* gcc.dg/tree-ssa/pr19831-2.c: Add an expected warning.
* gcc.dg/Wfree-nonheap-object-2.c: New test.
* gcc.dg/Wfree-nonheap-object-3.c: New test.
* gcc.dg/Wfree-nonheap-object.c: New test.

libstdc++-v3/ChangeLog:

* testsuite/ext/vstring/modifiers/clear/56166.cc: Suppress a false
positive warning.

[Bug tree-optimization/96344] 3rdd case of gnat.dg/opt86a.adb fails because of VRP

2020-12-03 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344

--- Comment #5 from Eric Botcazou  ---
> A fresh build of trunk on x86_64 shows the following Ada failures:
> 
> !  FAIL: gnat.dg/opt86a.adb (1: +1)
> !  FAIL: gnat.dg/opt86b.adb (1: +1)
> !  FAIL: gnat.dg/opt86c.adb (1: +1)
> 
> The logs show this:
> 
> $ grep "FAIL: gnat.dg/opt86" gcc/testsuite/gnat/gnat.log
> FAIL: gnat.dg/opt86a.adb scan-tree-dump-times optimized ">>" 4
> FAIL: gnat.dg/opt86b.adb scan-tree-dump-not optimized "> 29"
> FAIL: gnat.dg/opt86c.adb scan-tree-dump-not optimized "> 26"

Introduced on 12/01, probably by:

2020-12-01  Martin Liska  

PR tree-optimization/14799
PR ipa/88702
* Makefile.in: Add gimple-if-to-switch.o.
* dbgcnt.def (DEBUG_COUNTER): Add new debug counter.
* passes.def: Include new pass_if_to_switch pass.
* timevar.def (TV_TREE_IF_TO_SWITCH): New timevar.
* tree-pass.h (make_pass_if_to_switch): New.
* tree-ssa-reassoc.c (struct operand_entry): Move to the header.
(dump_range_entry): Move to header file.
(debug_range_entry): Likewise.
(no_side_effect_bb): Make it global.
* tree-switch-conversion.h (simple_cluster::simple_cluster):
Add inline for couple of functions in order to prevent error
about multiple defined symbols.
* gimple-if-to-switch.cc: New file.
* tree-ssa-reassoc.h: New file.

[Bug tree-optimization/96344] 3rdd case of gnat.dg/opt86a.adb fails because of VRP

2020-12-03 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96344

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
Also seen on x86_64-linux.  I was about to open a bug with this:

A fresh build of trunk on x86_64 shows the following Ada failures:

!  FAIL: gnat.dg/opt86a.adb (1: +1)
!  FAIL: gnat.dg/opt86b.adb (1: +1)
!  FAIL: gnat.dg/opt86c.adb (1: +1)

The logs show this:

$ grep "FAIL: gnat.dg/opt86" gcc/testsuite/gnat/gnat.log
FAIL: gnat.dg/opt86a.adb scan-tree-dump-times optimized ">>" 4
FAIL: gnat.dg/opt86b.adb scan-tree-dump-not optimized "> 29"
FAIL: gnat.dg/opt86c.adb scan-tree-dump-not optimized "> 26"

[Bug c++/98126] -Wsequence-point is non-linear for certain cases

2020-12-03 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98126

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #1 from Marek Polacek  ---
I have a (simple, stupid) patch.

[Bug tree-optimization/98131] New: new test case g++.dg/cpp2a/concepts-nodiscard1.C in r11-5719 has excess errors

2020-12-03 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98131

Bug ID: 98131
   Summary: new test case g++.dg/cpp2a/concepts-nodiscard1.C in
r11-5719 has excess errors
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:5ea36d20c352a3ca436aa764404f6210b090866b, r11-5719

make  -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/cpp2a/concepts-nodiscard1.C"
FAIL: g++.dg/cpp2a/concepts-nodiscard1.C  -std=c++2a (test for excess errors)
# of unexpected failures1
# of unsupported tests  3

Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C 
  -fdiagnostics-plain-output  -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 
-std=c++2a  -pedantic-errors -Wno-long-long  -S -o concepts-nodiscard1.s   
(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++2a -pedantic-errors -Wno-long-long -S -o concepts-nodiscard1.s
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C:8:10:
warning: ignoring return value of 'int foo()', declared with attribute
'nodiscard' [-Wunused-result]
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C:6:19:
note: declared here
Executing on host:
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
exceptions_enabled107545.cc-fdiagnostics-plain-output  -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0 
-S -o exceptions_enabled107545.s(timeout = 300)
spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
exceptions_enabled107545.cc -fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-S -o exceptions_enabled107545.s
FAIL: g++.dg/cpp2a/concepts-nodiscard1.C  -std=c++2a (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/cpp2a/concepts-nodiscard1.C:8:10:
warning: ignoring return value of 'int foo()', declared with attribute
'nodiscard' [-Wunused-result]

testcase /home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/dg.exp completed in
0 seconds

=== g++ Summary ===

# of unexpected failures1
# of unsupported tests  3

[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts

2020-12-03 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/98130] New: [11 regression] placement new fails on webkit-gtk-2.28.4

2020-12-03 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98130

Bug ID: 98130
   Summary: [11 regression] placement new fails on
webkit-gtk-2.28.4
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

Initial problem is observed on liferea crash at startup against
webkit-gtk-2.28.4 built with gcc-11.

If I reduced original source correctly here is minimized version of the crash:

//$ cat a.cc
/*

  $ g++-10.2.0 -O1 -fno-strict-aliasing a.cc -o a-10 && ./a-10
  &a=0x7ffc83475894
  $ g++-11.0.0 -O1 -fno-strict-aliasing a.cc -o a-11 && ./a-11
  Illegal instruction (core dumped) ./a-11

*/

#if 0
#  include 
#else
inline void* operator new(unsigned long, void* __p) { return __p; }
#endif

#include 

typedef int* T;

static T storage;
static T* p = &storage;

// '__attribute__((__always_inline__))' seems to be the trigger
static inline __attribute__((__always_inline__)) void append(T value)
{
new (p) T(value);
}

int main() {
int a;
append(&a);

if (!*p)
__builtin_trap();
fprintf(stderr, "&a=%p\n", *p);
}

[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

H.J. Lu  changed:

   What|Removed |Added

 CC||amodra at gmail dot com

--- Comment #4 from H.J. Lu  ---
(In reply to seurer from comment #0)
> g:694d4a6d0c466d0fbc97920a9c6641a7b349ca35, r11-5656
> 
> make  -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/pr93195a.C"
> FAIL: g++.dg/pr93195a.C  -std=gnu++98 (test for excess errors)
> FAIL: g++.dg/pr93195a.C  -std=gnu++14 (test for excess errors)
> FAIL: g++.dg/pr93195a.C  -std=gnu++17 (test for excess errors)
> FAIL: g++.dg/pr93195a.C  -std=gnu++2a (test for excess errors)
> # of unexpected failures  4
> 
> The errors are all this:
> 
> collect2: error: ld returned 1 exit status
> compiler exited with status 1
> FAIL: g++.dg/pr93195a.C  -std=gnu++14 (test for excess errors)
> Excess errors:
> `.text._Z3foov' referenced in section `__patchable_function_entries' of
> /tmp/ccwJ1d6k.o: defined in discarded section `.text._Z3foov[_Z3foov]' of
> /tmp/ccwJ1d6k.o

This is a PowerPC specific issue.  I don't know how
__patchable_function_entries
works on PowerPC.

[Bug libfortran/98129] New: Failure on reading big chunk of /dev/urandom

2020-12-03 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129

Bug ID: 98129
   Summary: Failure on reading big chunk of /dev/urandom
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

The following program

program main
  implicit none
  integer, parameter :: n = 10**7
  integer :: u,v
  integer, dimension(:), allocatable :: a
  open (newunit=u,file="/dev/urandom",form="unformatted",access="stream")
  open (newunit=v,file="/dev/null",form="unformatted",access="stream")
  allocate (a(n))
  read (u) a
  write (v) a
end program main

fails on Linux with

At line 9 of file read.f90
Fortran runtime error: End of file

Error termination. Backtrace:
#0  0x7fa9c7be372f in read_block_direct
at ../../../trunk/libgfortran/io/transfer.c:664
#1  0x7fa9c7be372f in unformatted_read
at ../../../trunk/libgfortran/io/transfer.c:1127
#2  0x400bf3 in ???
#3  0x400c9c in ???
#4  0x7fa9c6e64349 in __libc_start_main
at ../csu/libc-start.c:308
#5  0x400909 in ???
at ../sysdeps/x86_64/start.S:120
#6  0x in ???

[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts

2020-12-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
(In reply to H.J. Lu from comment #1)
> It is likely caused by r11-5695.

Yes, it's since this revision. I see that same issue.

[Bug rtl-optimization/97459] __uint128_t remainder for division by 3

2020-12-03 Thread tkoenig at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97459

--- Comment #26 from Thomas Koenig  ---
Yep, it's implemented and works great.

For a simple "sum of digits" program in base ten, it's an acceleration
by more than a factor of two.

Thanks!

[Bug libgcc/97543] powerpc64le: libgcc has unexpected long double in .gnu_attribute

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Michael Meissner :

https://gcc.gnu.org/g:9f1a6501994a2d18ec4fe2a6664637f48021b210

commit r11-5728-g9f1a6501994a2d18ec4fe2a6664637f48021b210
Author: Michael Meissner 
Date:   Thu Dec 3 14:50:26 2020 -0500

PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issues

If you use a compiler with long double defaulting to 64-bit instead of
128-bit
with IBM extended double, you get linker warnings about mis-matches in the
gnu
attributes for long double (PR libgcc/97543).  Even if the compiler is
configured to have long double be 64 bit as the default with the
configuration
option '--without-long-double-128' you get the warnings.

You also get the same issues if you use a compiler with long double
defaulting
to IEEE 128-bit instead of IBM extended double (PR libgcc/97643).

The issue is the way libgcc.a/libgcc.so is built.  Right now when building
libgcc under Linux, the long double size is set to 128-bits when building
libgcc.  However, the gnu attributes are set, leading to the warnings.

One feature of the current GNU attribute implementation is if you have a
shared
library (such as libgcc_s.so), the GNU attributes for the shared library is
an
inclusive OR of all of the objects within the library.  This means if any
object file that uses the -mlong-double-128 option and uses long double,
the GNU
attributes for the library will indicate that it uses 128-bit IBM long
doubles.  If you have a static library, you will get the warning only if
you
actually reference an object file  with the attribute set.

This patch does two things:

1)  All of the object files that support IBM 128-bit long doubles
explicitly set the ABI to IBM extended double.

2)  I turned off GNU attributes for building the shared library or for
building the IBM 128-bit long double support.

libgcc/
2020-12-03  Michael Meissner  

PR libgcc/97543
PR libgcc/97643
* config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
(IBM128_SHARED_OBJS): New make variable.
(IBM128_OBJS): New make variable.  Set all objects to use the
explicit IBM format, and disable gnu attributes.
(IBM128_CFLAGS): New make variable.
(gcc_s_compile): Add -mno-gnu-attribute to all shared library
modules.

[Bug c++/97643] Accepts invalid qualification conversion involving array of unknown bound [P0388]

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97643

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Michael Meissner :

https://gcc.gnu.org/g:9f1a6501994a2d18ec4fe2a6664637f48021b210

commit r11-5728-g9f1a6501994a2d18ec4fe2a6664637f48021b210
Author: Michael Meissner 
Date:   Thu Dec 3 14:50:26 2020 -0500

PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issues

If you use a compiler with long double defaulting to 64-bit instead of
128-bit
with IBM extended double, you get linker warnings about mis-matches in the
gnu
attributes for long double (PR libgcc/97543).  Even if the compiler is
configured to have long double be 64 bit as the default with the
configuration
option '--without-long-double-128' you get the warnings.

You also get the same issues if you use a compiler with long double
defaulting
to IEEE 128-bit instead of IBM extended double (PR libgcc/97643).

The issue is the way libgcc.a/libgcc.so is built.  Right now when building
libgcc under Linux, the long double size is set to 128-bits when building
libgcc.  However, the gnu attributes are set, leading to the warnings.

One feature of the current GNU attribute implementation is if you have a
shared
library (such as libgcc_s.so), the GNU attributes for the shared library is
an
inclusive OR of all of the objects within the library.  This means if any
object file that uses the -mlong-double-128 option and uses long double,
the GNU
attributes for the library will indicate that it uses 128-bit IBM long
doubles.  If you have a static library, you will get the warning only if
you
actually reference an object file  with the attribute set.

This patch does two things:

1)  All of the object files that support IBM 128-bit long doubles
explicitly set the ABI to IBM extended double.

2)  I turned off GNU attributes for building the shared library or for
building the IBM 128-bit long double support.

libgcc/
2020-12-03  Michael Meissner  

PR libgcc/97543
PR libgcc/97643
* config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
(IBM128_SHARED_OBJS): New make variable.
(IBM128_OBJS): New make variable.  Set all objects to use the
explicit IBM format, and disable gnu attributes.
(IBM128_CFLAGS): New make variable.
(gcc_s_compile): Add -mno-gnu-attribute to all shared library
modules.

[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts

2020-12-03 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
--- gcc/cp/parser.c.jj  2020-12-03 20:41:57.194174600 +0100
+++ gcc/cp/parser.c 2020-12-03 20:46:28.626125729 +0100
@@ -30589,7 +30589,7 @@ cp_parser_late_parsing_default_args (cp_
   tree copy;
   unsigned ix;

-  tree parmdecl = parms[i];
+  tree parmdecl = (*parms)[i];
   pushdecl (parmdecl);

   if (!default_arg)
@@ -30618,8 +30618,8 @@ cp_parser_late_parsing_default_args (cp_
   parm = NULL_TREE;
   for (int i = parms->length () - 1; i >= 0; --i)
 {
-  DECL_CHAIN (parms[i]) = parm;
-  parm = parms[i];
+  DECL_CHAIN ((*parms)[i]) = parm;
+  parm = (*parms)[i];
 }

   pop_defarg_context ();

seems to work for me.
So does:
--- gcc/cp/cp-tree.h.jj 2020-12-02 22:55:36.328252325 +0100
+++ gcc/cp/cp-tree.h2020-12-03 20:49:11.746293467 +0100
@@ -963,6 +963,7 @@ public:

   /* Breaks pointer/value consistency for convenience.  */
   tree& operator[] (unsigned i) const { return (*v)[i]; }
+  tree& operator[] (int i) const { return (*v)[i]; }

   ~releasing_vec() { release_tree_vector (v); }
 private:

[Bug libstdc++/88322] Implement C++20 library features.

2020-12-03 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 88812, which changed state.

Bug 88812 Summary: Implement C++20 LWG 2499/P0487R1 - Fixing 
operator>>(basic_istream&, CharT*)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88812

   What|Removed |Added

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

[Bug libstdc++/88812] Implement C++20 LWG 2499/P0487R1 - Fixing operator>>(basic_istream&, CharT*)

2020-12-03 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88812

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
This was fixed in r11-2581 17abcc773415848dce593016512636cda3de20d5

[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342

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

https://gcc.gnu.org/g:30b606bb9b9314010a446ea4bed3481632008f75

commit r11-5727-g30b606bb9b9314010a446ea4bed3481632008f75
Author: Harald Anlauf 
Date:   Thu Dec 3 20:33:22 2020 +0100

PR fortran/95342 - ICE in gfc_match_subroutine, at fortran/decl.c:7913

Add checks for NULL pointers before dereferencing them.

gcc/fortran/ChangeLog:

PR fortran/95342
* decl.c (gfc_match_function_decl): Avoid NULL pointer dereference.
(gfc_match_subroutine): Likewise.

gcc/testsuite/ChangeLog:

PR fortran/95342
* gfortran.dg/pr95342.f90: New test.

[Bug bootstrap/98128] [11 Regression] Bootstrap failed on 32-bit hosts

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-03
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from H.J. Lu  ---
It is likely caused by r11-5695.

[Bug bootstrap/98128] New: [11 Regression] Bootstrap failed on 32-bit hosts

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98128

Bug ID: 98128
   Summary: [11 Regression] Bootstrap failed on 32-bit hosts
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: jakub at redhat dot com, jason at redhat dot com
  Target Milestone: ---

On Linux/x86, r11-5702 failed to bootstrap:

../../src-master/gcc/cp/parser.c: In function ??void
cp_parser_late_parsing_default_args(cp_parser*, tree)??:
../../src-master/gcc/cp/parser.c:30592:28: error: ambiguous overload for
??operator[]?? (operand types are ??releasing_vec?? and ??int??)
30592 |   tree parmdecl = parms[i];
  |^
../../src-master/gcc/cp/parser.c:30592:28: note: candidate:
??operator[](releasing_vec::vec_t* {aka vec*}, int)??
(built-in)
In file included from ../../src-master/gcc/cp/parser.c:25:
../../src-master/gcc/cp/cp-tree.h:965:9: note: candidate: ??tree_node*&
releasing_vec::operator[](unsigned int) const??
  965 |   tree& operator[] (unsigned i) const { return (*v)[i]; }
  | ^~~~
In file included from ../../src-master/gcc/c-family/c-common.h:26,
 from ../../src-master/gcc/cp/cp-tree.h:40,
 from ../../src-master/gcc/cp/parser.c:25:
../../src-master/gcc/cp/parser.c:30621:24: error: ambiguous overload for
??operator[]?? (operand types are ??releasing_vec?? and ??int??)
30621 |   DECL_CHAIN (parms[i]) = parm;
  |^
../../src-master/gcc/tree.h:286:26: note: in definition of macro
??CONTAINS_STRUCT_CHECK??
  286 | (contains_struct_check ((T), (STRUCT), __FILE__, __LINE__,
__FUNCTION__))
  |  ^
../../src-master/gcc/tree.h:2424:27: note: in expansion of macro ??TREE_CHAIN??
 2424 | #define DECL_CHAIN(NODE) (TREE_CHAIN (DECL_MINIMAL_CHECK (NODE)))
  |   ^~
../../src-master/gcc/tree.h:431:33: note: in expansion of macro
??CONTAINS_STRUCT_CHECK??
  431 | #define DECL_MINIMAL_CHECK(T)   CONTAINS_STRUCT_CHECK (T,
TS_DECL_MINIMAL)
  | ^
../../src-master/gcc/tree.h:2424:39: note: in expansion of macro
??DECL_MINIMAL_CHECK??
 2424 | #define DECL_CHAIN(NODE) (TREE_CHAIN (DECL_MINIMAL_CHECK (NODE)))
  |   ^~
../../src-master/gcc/cp/parser.c:30621:7: note: in expansion of macro
??DECL_CHAIN??
30621 |   DECL_CHAIN (parms[i]) = parm;
  |   ^~
../../src-master/gcc/cp/parser.c:30621:24: note: candidate:
??operator[](releasing_vec::vec_t* {aka vec*}, int)??
(built-in)
30621 |   DECL_CHAIN (parms[i]) = parm;
  |^
../../src-master/gcc/tree.h:286:26: note: in definition of macro
??CONTAINS_STRUCT_CHECK??

r11-5693 is OK.

[Bug libstdc++/88322] Implement C++20 library features.

2020-12-03 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
Bug 88322 depends on bug 93121, which changed state.

Bug 93121 Summary: std::bit_cast missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121

   What|Removed |Added

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

[Bug libstdc++/93121] std::bit_cast missing

2020-12-03 Thread redi at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #11 from Jonathan Wakely  ---
Added for GCC 11.

[Bug c++/96960] [C++20] ICE in tsubst_copy_and_build, at cp/pt.c:20531 from lambda in return-type-requirement

2020-12-03 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96960

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
Summary|ICE in  |[C++20] ICE in
   |tsubst_copy_and_build, at   |tsubst_copy_and_build, at
   |cp/pt.c:20531 from lambda   |cp/pt.c:20531 from lambda
   |in return-type-requirement  |in return-type-requirement

--- Comment #2 from Jason Merrill  ---
This has to do with type_deducible_p's use of tf_partial.  That function is
left over from the days before P1084; we still kind of treat return type
requirements as deduction rather than simply checking the constraint.  Though
other places where we do need to do deduction work properly:

C0 auto x = 42;

int f(C0 auto x);
int y = f(42);

[Bug libstdc++/93121] std::bit_cast missing

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:9e433b3461ab64b38350817392a77efb67bb78b4

commit r11-5722-g9e433b3461ab64b38350817392a77efb67bb78b4
Author: Jonathan Wakely 
Date:   Thu Dec 3 19:17:13 2020 +

libstdc++: Add std::bit_cast for C++20 [PR 93121]

Thanks to Jakub's addition of the built-in, we can add this to the
library now. The compiler tests for the built-in are quite extensive,
including verifying the constraints, so this only adds minimal tests to
the library testsuite.

This doesn't add a new _GLIBCXX_HAVE_BUILTIN_BIT_CAST because using
__has_builtin(__builtin_bit_cast) works for GCC and versions of Clang
that provide the built-in.

libstdc++-v3/ChangeLog:

PR libstdc++/93121
* include/std/bit (__cpp_lib_bit_cast, bit_cast): Define.
* include/std/version (__cpp_lib_bit_cast): Define.
* testsuite/26_numerics/bit/bit.cast/bit_cast.cc: New test.
* testsuite/26_numerics/bit/bit.cast/version.cc: New test.

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

--- Comment #9 from H.J. Lu  ---
Created attachment 49675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49675&action=edit
A patch

[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

2020-12-03 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086

Uroš Bizjak  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Assignee|jakub at gcc dot gnu.org   |ubizjak at gmail dot com

--- Comment #8 from Uroš Bizjak  ---
Fixed for gcc-9.4, gcc-10.3 and gcc-11.0.

[Bug c++/98019] Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted

2020-12-03 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 11.

[Bug c++/98019] Concepts: compound requirement expression from 'requires' expression is considered discarded-value expression for [[nodiscard]], false positive warning emitted

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98019

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

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

commit r11-5719-g5ea36d20c352a3ca436aa764404f6210b090866b
Author: Jason Merrill 
Date:   Thu Dec 3 13:55:51 2020 -0500

c++: Add testcase for PR98019

This has already been fixed on trunk, but I don't see a testcase for it.

gcc/testsuite/ChangeLog:

PR c++/98019
* g++.dg/cpp2a/concepts-nodiscard1.C: New test.

[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

2020-12-03 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086

--- Comment #7 from Uroš Bizjak  ---
https://gcc.gnu.org/g:521c839fad4e4a30cdadda254fb3f07706285033

commit r9-9096-g521c839fad4e4a30cdadda254fb3f07706285033
Author: Uros Bizjak 
Date:   Thu Dec 3 19:08:23 2020 +0100

i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode
and nothing else.  The patch rewrites zero-extension part to use
convert_to_mode to handle TImode and hypothetically even wider modes.

2020-12-03  Uroš Bizjak  
Jakub Jelinek  

gcc/
PR target/98086
* config/i386/i386.c (ix86_md_asm_adjustmd): Rewrite
zero-extension part to use convert_to_mode.

gcc/testsuite/
PR target/98086
* gcc.target/i386/pr98086.c: New test.

[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

2020-12-03 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086

--- Comment #6 from Uroš Bizjak  ---
https://gcc.gnu.org/g:4fa2ab664324eca33bd67981698c453820f70b86

commit r10-9116-g4fa2ab664324eca33bd67981698c453820f70b86
Author: Uros Bizjak 
Date:   Thu Dec 3 17:49:42 2020 +0100

i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode
and nothing else.  The patch rewrites zero-extension part to use
convert_to_mode to handle TImode and hypothetically even wider modes.

2020-12-03  Uroš Bizjak  
Jakub Jelinek  

gcc/
PR target/98086
* config/i386/i386.c (ix86_md_asm_adjustmd): Rewrite
zero-extension part to use convert_to_mode.

gcc/testsuite/
PR target/98086
* gcc.target/i386/pr98086.c: New test.

(cherry picked from commit 756f55e62f73eb32787497eb9e564d4b21a6e637)

[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

2020-12-03 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086

--- Comment #5 from Uroš Bizjak  ---
https://gcc.gnu.org/g:756f55e62f73eb32787497eb9e564d4b21a6e637

commit r11-5713-g756f55e62f73eb32787497eb9e564d4b21a6e637
Author: Uros Bizjak 
Date:   Thu Dec 3 17:49:42 2020 +0100

i386: Fix up ix86_md_asm_adjust for TImode [PR98086]

ix86_md_asm_adjust assumes that dest_mode can be only [QHSD]Imode
and nothing else.  The patch rewrites zero-extension part to use
convert_to_mode to handle TImode and hypothetically even wider modes.

2020-12-03  Uroš Bizjak  
Jakub Jelinek  

gcc/
PR target/98086
* config/i386/i386.c (ix86_md_asm_adjustmd): Rewrite
zero-extension part to use convert_to_mode.

gcc/testsuite/
PR target/98086
* gcc.target/i386/pr98086.c: New test.

[Bug ada/97504] [11 Regression] Ada bootstrap error after r11-4029

2020-12-03 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504

Eric Botcazou  changed:

   What|Removed |Added

 CC||sch...@linux-m68k.org

--- Comment #39 from Eric Botcazou  ---
*** Bug 98127 has been marked as a duplicate of this bug. ***

[Bug ada/98127] [11 regression] libada lacks objects needed for 128-bit types

2020-12-03 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98127

Eric Botcazou  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Eric Botcazou  ---
.

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

[Bug c++/97059] C++20: compound requirement uses inconsistent return type (adds ref)

2020-12-03 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97059

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Resolution|--- |INVALID
 Status|UNCONFIRMED |RESOLVED

--- Comment #3 from Jason Merrill  ---
(In reply to Dimitri Gorokhovik from comment #0)
> template 
> concept S = requires (T t)
> {
>   { t.n } -> std::same_as  #if NOBUG
> &
> #endif
> >;
>   requires std::is_same_v ;
> };
> 
> Compilation succeeds when NOBUG is defined, i.e., the compound requirement
> '{ t.n } ->' produces the return type as 'const std::size_t &' instead of
> 'const std::size_t'. Which is inconsistent elsewhere (see the source code
> above).

For the second 'requires' to be equivalent to the return-type-requirement, you
need another set of parentheses around "t.n".

7.5.7.3: "The immediately-declared constraint (13.2) of the type-constraint for
decltype((E)) shall be satisfied."

It's the extra parentheses that result in the reference type rather than
non-reference.  GCC is correct here.

[Bug ada/98127] New: [11 regression] libada lacks objects needed for 128-bit types

2020-12-03 Thread schwab--- via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98127

Bug ID: 98127
   Summary: [11 regression] libada lacks objects needed for
128-bit types
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
CC: ebotcazou at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc*-*-*

=== acats configuration ===
target gcc is /daten/gcc/gcc-20201201/Build/gcc/xgcc
-B/daten/gcc/gcc-20201201/Build/gcc/
Reading specs from /daten/gcc/gcc-20201201/Build/gcc/specs
COLLECT_GCC=/daten/gcc/gcc-20201201/Build/gcc/xgcc
COLLECT_LTO_WRAPPER=/daten/gcc/gcc-20201201/Build/gcc/lto-wrapper Target:
powerpc64-suse-linux Configured with: ../configure --prefix=/usr
--build=powerpc64-suse-linux --enable-shared --with-system-zlib CFLAGS='-O2 -g'
CXXFLAGS='-O2 -g' --enable-checking=release --with-cpu-64=power4
--enable-secureplt --with-long-double-128 Thread model: posix Supported LTO
compression algorithms: zlib gcc version 11.0.0 20201201 (experimental) [HEAD
revision 69157fe75823] (GCC)
host=powerpc64-suse-linux
target=powerpc64-suse-linux
gnatmake is /daten/gcc/gcc-20201201/Build/gcc/gnatmake

GNATLS 11.0.0 20201201 (experimental) [HEAD revision 69157fe75823]
Copyright (C) 1997-2020, Free Software Foundation, Inc.

Source Search Path:
   
   /daten/gcc/gcc-20201201/Build/gcc/ada/rts
   /usr/lib64/gcc/powerpc64-suse-linux/11.0.0/adainclude


Object Search Path:
   
   /daten/gcc/gcc-20201201/Build/gcc/ada/rts
   /usr/lib64/gcc/powerpc64-suse-linux/11.0.0/adalib


Project Search Path:
   
   /usr/powerpc64-suse-linux/lib/gnat
   /usr/powerpc64-suse-linux/share/gpr
   /usr/share/gpr
   /usr/lib/gnat


=== acats support ===
Generating support files.../daten/gcc/gcc-20201201/Build/gcc/gnatmake
--GNATBIND=/daten/gcc/gcc-20201201/Build/gcc/gnatbind
--GNATLINK=/daten/gcc/gcc-20201201/Build/gcc/gnatlink
--GCC=/daten/gcc/gcc-20201201/Build/gcc/xgcc
-B/daten/gcc/gcc-20201201/Build/gcc/ -gnatws -O2
/daten/gcc/gcc-20201201/gcc/testsuite/ada/acats/support/impbit.adb -largs
--GCC=/daten/gcc/gcc-20201201/Build/gcc/xgcc
-B/daten/gcc/gcc-20201201/Build/gcc/
/daten/gcc/gcc-20201201/Build/gcc/xgcc -c
-I/daten/gcc/gcc-20201201/gcc/testsuite/ada/acats/support/
-B/daten/gcc/gcc-20201201/Build/gcc/ -gnatws -O2 -I-
/daten/gcc/gcc-20201201/gcc/testsuite/ada/acats/support/impbit.adb
/daten/gcc/gcc-20201201/Build/gcc/gnatbind -x impbit.ali
error: "s-imgllli.ali" not found, "s-imgllli.ads" must be compiled
gnatmake: *** bind failed.
 Failed to compile impbit

[Bug target/98086] [9/10/11 Regression] ICE in extract_insn, at recog.c:2315

2020-12-03 Thread ubizjak at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98086

Uroš Bizjak  changed:

   What|Removed |Added

  Attachment #49661|0   |1
is obsolete||

--- Comment #4 from Uroš Bizjak  ---
Created attachment 49674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49674&action=edit
Proposed v2 patch

[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

--- Comment #3 from H.J. Lu  ---
(In reply to seurer from comment #2)
> #define HAVE_GAS_SECTION_LINK_ORDER 1

Please show the command line options passed to ld, pass --dependency-file=FILE
to ld to list all linker input files and upload all linker input files so that
I can investigate with a cross linker.

[Bug c++/98122] [10/11 Regression] Accessing union member through pointer-to-member is not a constant expression

2020-12-03 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/98122] [10/11 Regression] Accessing union member through pointer-to-member is not a constant expression

2020-12-03 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98122

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-03
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Keywords||rejects-valid
Summary|[regression] Accessing  |[10/11 Regression]
   |union member through|Accessing union member
   |pointer-to-member is not a  |through pointer-to-member
   |constant expression |is not a constant
   ||expression
   Target Milestone|--- |10.3

--- Comment #1 from Marek Polacek  ---
Started with r276563.

[Bug target/98112] Add -fdirect-access-external-data & drop HAVE_LD_PIE_COPYRELOC

2020-12-03 Thread i at maskray dot me via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98112

--- Comment #2 from Fangrui Song  ---
Note: -fdirect-access-external-data is architecture-independent. For example,
currently Clang on aarch64 can perform the following optimization:

// clang -target aarch64 -fPIE -O3
  adrpx8, :got:var
  ldr x8, [x8, :got_lo12:var]
  ldr w0, [x8]
  ret
// clang -target aarch64 -fPIE -O3 -mpie-copy-relocations
  adrpx8, var
  ldr w0, [x8, :lo12:var]
  ret

A better name for -mpie-copy-relocations is -fno-direct-access-external-data:

  1. the option can affect -fno-pic and -fpic
  2. for -no-pie and -pie links, there is not necessary a copy relocation
  (-fpic can use this option as well, but keep in mind that DSOs do not support
copy relocations. So if such code is used for -shared links and the data turns
out to be undefined, the linker will reject the object file)

---

The second thing about the feature request is that x86-64 should default to
-fno-direct-access-external-data for -fpie to address the protected symbol
issues.
(-fno-direct-access-external-data for -fpie is the behavior on most
architectures.)

  (1): PC32 referencing a protected function is unnecessarily rejected in a
-shared link (this also affects aarch64)
  // gcc -fpic -fuse-ld=bfd -shared -fvisibility=protected b.c => relocation
R_X86_64_PC32 against protected symbol `f' can not be used when making a shared
object
  // aarch64-linux-gnu-gcc -fpic -fuse-ld=bfd -shared -fvisibility=protected
b.c => relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol `f' which may bind
externally can not be used when making a shared object; recompile with -fPIC
  // gold is good

  void f() {}
  void *g() { return &f; }

This can be fixed by making GNU ld more permissive.

  (2) protected data access can use slightly more efficient PC32. Currently it
uses the slightly pessimized REX_GOTPCRELX.
  int a __attribute__((visibility("protected")));
  int f() { return a; }

[Bug c++/98126] New: -Wsequence-point is non-linear for certain cases

2020-12-03 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98126

Bug ID: 98126
   Summary: -Wsequence-point is non-linear for certain cases
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

This script generates C++ programs that show that -Wsequence-point exhibits
non-linear behavior:

#!/bin/bash
n=$1

printf "struct T { bool operator==(const T &ot) const; };
struct C {
  bool operator==(const C &ot) const {
return\n"
for i in $(seq $n); do printf "  t$i == ot.t$i &&\n"; done
printf "  true; 
  }
"
for i in $(seq $n); do printf "  T t$i;\n"; done
printf "};\n"

$ ./gen.sh 100 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 0.60
$ ./gen.sh 200 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 4.50
$ ./gen.sh 300 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 14.62
$ ./gen.sh 400 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 34.46
$ ./gen.sh 500 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 67.27
$ ./gen.sh 600 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 117.33
$ ./gen.sh 700 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 179.78
$ ./gen.sh 800 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
real 278.54

Note that
$ ./gen.sh 800 > gen.cc && time -p ./cc1plus -quiet -fsyntax-only -Wall gen.cc
-Wno-sequence-point
real 0.14

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread jozefl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

--- Comment #8 from Jozef Lawrynowicz  ---
(In reply to Jozef Lawrynowicz from comment #7)
> (In reply to Florian Weimer from comment #6)
> > (In reply to Jozef Lawrynowicz from comment #4)
> > > GAS merges the "R" flag state in .section declarations, silently, and with
> > > logical OR, and GCC should do the same. So if you have:
> > > 
> > > int __attribute__((section(".data.foo"))) foo1 = 1;
> > > int __attribute__((used,section(".data.foo"))) foo2 = 2;
> > > 
> > > .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> > > "used" attribute to the second declaration of section(".data.foo") should
> > > not cause any warning/error messages to be emitted either. So option 3 
> > > from
> > > above.
> > > 
> > > Just need to do something similar to what is already done for 
> > > SECTION_NOTYPE
> > > in varasm.c:get_section.
> > 
> > I don't now the details, but I think foo1 should not implicitly be marked as
> > “used”. The difference matters for static functions, for example. GCC should
> > still drop them if they are not referenced, even if they are located in a
> > retained section.  So free_slotinfo in comment 5.
> 
> With the suggested approach, GCC would still drop foo1 if it is not used,
> since it is only the section being marked with SECTION_RETAIN, and this only
> affects whether the "R" flag is output in the .section directive for the
> decl.
> 
> GCC will only keep an unreferenced decl if it has DECL_PRESERVE_P and we
> haven't changed that with the "used" applies SHF_GNU_RETAIN functionality.
> 
> If foo1 somehow makes it into the assembler code, it will be kept, even if
> it is not used, since we lose the ability to remove individual decls once
> they are put in sections.

Sorry, in my foo1/foo2 example they are not static so will not be dropped by
GCC.

For the free_slotinfo example, it would be dropped by GCC if unused, even
though another function with the same section was marked "used" and has
SECTION_RETAIN.

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread jozefl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

--- Comment #7 from Jozef Lawrynowicz  ---
(In reply to Florian Weimer from comment #6)
> (In reply to Jozef Lawrynowicz from comment #4)
> > GAS merges the "R" flag state in .section declarations, silently, and with
> > logical OR, and GCC should do the same. So if you have:
> > 
> > int __attribute__((section(".data.foo"))) foo1 = 1;
> > int __attribute__((used,section(".data.foo"))) foo2 = 2;
> > 
> > .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> > "used" attribute to the second declaration of section(".data.foo") should
> > not cause any warning/error messages to be emitted either. So option 3 from
> > above.
> > 
> > Just need to do something similar to what is already done for SECTION_NOTYPE
> > in varasm.c:get_section.
> 
> I don't now the details, but I think foo1 should not implicitly be marked as
> “used”. The difference matters for static functions, for example. GCC should
> still drop them if they are not referenced, even if they are located in a
> retained section.  So free_slotinfo in comment 5.

With the suggested approach, GCC would still drop foo1 if it is not used, since
it is only the section being marked with SECTION_RETAIN, and this only affects
whether the "R" flag is output in the .section directive for the decl.

GCC will only keep an unreferenced decl if it has DECL_PRESERVE_P and we
haven't changed that with the "used" applies SHF_GNU_RETAIN functionality.

If foo1 somehow makes it into the assembler code, it will be kept, even if it
is not used, since we lose the ability to remove individual decls once they are
put in sections.

[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

2020-12-03 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

--- Comment #2 from seurer at gcc dot gnu.org ---
#define HAVE_GAS_SECTION_LINK_ORDER 1

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread fw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

--- Comment #6 from Florian Weimer  ---
(In reply to Jozef Lawrynowicz from comment #4)
> GAS merges the "R" flag state in .section declarations, silently, and with
> logical OR, and GCC should do the same. So if you have:
> 
> int __attribute__((section(".data.foo"))) foo1 = 1;
> int __attribute__((used,section(".data.foo"))) foo2 = 2;
> 
> .data.foo should have SECTION_RETAIN set within GCC. The addition of the
> "used" attribute to the second declaration of section(".data.foo") should
> not cause any warning/error messages to be emitted either. So option 3 from
> above.
> 
> Just need to do something similar to what is already done for SECTION_NOTYPE
> in varasm.c:get_section.

I don't now the details, but I think foo1 should not implicitly be marked as
“used”. The difference matters for static functions, for example. GCC should
still drop them if they are not referenced, even if they are located in a
retained section.  So free_slotinfo in comment 5.

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

--- Comment #5 from H.J. Lu  ---
[hjl@gnu-cfl-2 tmp]$ cat x.c
struct dtv_slotinfo_list
{
  struct dtv_slotinfo_list *next;
};

extern struct dtv_slotinfo_list *list;

static int __attribute__ ((section ("__libc_freeres_fn")))
free_slotinfo (struct dtv_slotinfo_list **elemp)
{
  if (!free_slotinfo (&(*elemp)->next))
return 0;
  return 1;
}

__attribute__ ((used, section ("__libc_freeres_fn")))
static void free_mem (void)
{
  free_slotinfo (&list);
}
[hjl@gnu-cfl-2 tmp]$ /usr/gcc-11.0.0-x32/bin/gcc -S -O2 x.c -fPIC
x.c: In function ‘free_mem’:
x.c:17:13: error: ‘free_mem’ causes a section type conflict with
‘free_slotinfo.isra’
   17 | static void free_mem (void)
  | ^~~~
x.c:9:1: note: ‘free_slotinfo.isra’ was declared here
9 | free_slotinfo (struct dtv_slotinfo_list **elemp)
  | ^
[hjl@gnu-cfl-2 tmp]$

[Bug c++/98115] [11 Regression] error: partial specialization ‘class Stringify’ is not more specialized than [-fpermissive] since r11-5663-g329ae1d7751346ba

2020-12-03 Thread nathan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98115

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed 7254a78cf4c

[Bug c++/98116] [11 Regression] ICE in strip_typedefs, at cp/tree.c:1744 since r11-5663-g329ae1d7751346ba

2020-12-03 Thread nathan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98116

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #2 from Nathan Sidwell  ---
Fixed 7254a78cf4c

[Bug c++/98115] [11 Regression] error: partial specialization ‘class Stringify’ is not more specialized than [-fpermissive] since r11-5663-g329ae1d7751346ba

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98115

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:7254a78cf4c419a9b9361289d8c535130cf1dfd0

commit r11-5712-g7254a78cf4c419a9b9361289d8c535130cf1dfd0
Author: Nathan Sidwell 
Date:   Thu Dec 3 08:40:43 2020 -0800

c++: Testcases [PR 98115]

These two testcases provide coverage for 98115, which doesn't trigger on
all hosts.

PR c++/98115
PR c++/98116
gcc/testsuite/
* g++.dg/template/pr98115.C: New.
* g++.dg/template/pr98116.C: New.

[Bug c++/98116] [11 Regression] ICE in strip_typedefs, at cp/tree.c:1744 since r11-5663-g329ae1d7751346ba

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98116

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:7254a78cf4c419a9b9361289d8c535130cf1dfd0

commit r11-5712-g7254a78cf4c419a9b9361289d8c535130cf1dfd0
Author: Nathan Sidwell 
Date:   Thu Dec 3 08:40:43 2020 -0800

c++: Testcases [PR 98115]

These two testcases provide coverage for 98115, which doesn't trigger on
all hosts.

PR c++/98115
PR c++/98116
gcc/testsuite/
* g++.dg/template/pr98115.C: New.
* g++.dg/template/pr98116.C: New.

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread jozefl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

--- Comment #4 from Jozef Lawrynowicz  ---
(In reply to H.J. Lu from comment #2)
> The issue here is that what should happen when definitions marked with used
> attribute and unmarked definitions are put in the same section. It has
> nothing
> to do with .retain.

This bug report doesn't mention that. It looks to me that Florian was looking
to discuss the conceptual issue of whether the "used" attribute should apply
SHF_GNU_RETAIN.

I assume you're referring to the glibc bug 27002 with though.

(In reply to H.J. Lu from comment #3)
> If we cant to use SHF_GNU_RETAIN on used attribute, compiler can do
> 
> 1. Issue an error.
> 2. issue a warning and mark the unmarked definition as used.
> 3. Silently mark the unmarked definition as used.

GAS merges the "R" flag state in .section declarations, silently, and with
logical OR, and GCC should do the same. So if you have:

int __attribute__((section(".data.foo"))) foo1 = 1;
int __attribute__((used,section(".data.foo"))) foo2 = 2;

.data.foo should have SECTION_RETAIN set within GCC. The addition of the "used"
attribute to the second declaration of section(".data.foo") should not cause
any warning/error messages to be emitted either. So option 3 from above.

Just need to do something similar to what is already done for SECTION_NOTYPE in
varasm.c:get_section.

[Bug c++/96299] Defaulted operator <=> implicitly deleted when a member has operator < and operator == and return type is specified

2020-12-03 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96299

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Looking at this now.

[Bug testsuite/98125] New test case g++.dg/pr93195a.C in r11-5656 has excess errors

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #1 from H.J. Lu  ---
Please show

$ grep HAVE_GAS_SECTION_LINK_ORDER auto-host.h

[Bug testsuite/98125] New: New test case g++.dg/pr93195a.C in r11-5656 has excess errors

2020-12-03 Thread seurer at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98125

Bug ID: 98125
   Summary: New test case g++.dg/pr93195a.C in r11-5656 has excess
errors
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:694d4a6d0c466d0fbc97920a9c6641a7b349ca35, r11-5656

make  -k check-gcc RUNTESTFLAGS="dg.exp=g++.dg/pr93195a.C"
FAIL: g++.dg/pr93195a.C  -std=gnu++98 (test for excess errors)
FAIL: g++.dg/pr93195a.C  -std=gnu++14 (test for excess errors)
FAIL: g++.dg/pr93195a.C  -std=gnu++17 (test for excess errors)
FAIL: g++.dg/pr93195a.C  -std=gnu++2a (test for excess errors)
# of unexpected failures4

The errors are all this:

collect2: error: ld returned 1 exit status
compiler exited with status 1
FAIL: g++.dg/pr93195a.C  -std=gnu++14 (test for excess errors)
Excess errors:
`.text._Z3foov' referenced in section `__patchable_function_entries' of
/tmp/ccwJ1d6k.o: defined in discarded section `.text._Z3foov[_Z3foov]' of
/tmp/ccwJ1d6k.o

[Bug tree-optimization/98107] [11 regression] ICE at hash-table.c:137 starting with r11-5663

2020-12-03 Thread nathan at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98107

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed 62fb1b9e0da

[Bug tree-optimization/98107] [11 regression] ICE at hash-table.c:137 starting with r11-5663

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98107

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:62fb1b9e0da44a15b0434def20724f989d61e27b

commit r11-5708-g62fb1b9e0da44a15b0434def20724f989d61e27b
Author: Nathan Sidwell 
Date:   Thu Dec 3 07:42:09 2020 -0800

c++: Fix array type dependency [PR 98107]

I'd missed some paths through build_cplus_array_type, plus, some
arrays come via the C-type builder.  This propagates dependency in
more places and asserts that in the cases where TYPE_DEPENDENT_P_VALID
is unset, the type is non-dependent.

PR c++/98107
gcc/cp/
* tree.c (build_cplus_array_type): Mark dependency of new variant.
(cp_build_qualified_type_real, strip_typedefs): Assert
TYPE_DEPENDENT_P_VALID, or not a dependent type.

[Bug target/98124] New: Z: Load and test LTDBR instruction gets not used for comparison against 0.0

2020-12-03 Thread jens.seifert at de dot ibm.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124

Bug ID: 98124
   Summary: Z: Load and test LTDBR instruction gets not used for
comparison against 0.0
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jens.seifert at de dot ibm.com
  Target Milestone: ---

#include 
double sign(double in)
{
   return in == 0.0 ? 0.0 : copysign(1.0, in);
}

Command line:
gcc m64 -O2 -save-temps copysign.C

Output:
_Z4signd:
.LFB234:
.cfi_startproc
larl%r5,.L8
lzdr%f2
cdbr%f0,%f2
je  .L6
ld  %f2,.L9-.L8(%r5)
cpsdr   %f0,%f0,%f2
br  %r14

Use of LTDBR expected instead of  lzdr%f2 + cdbr%f0,%f2

[Bug tree-optimization/98123] if-to-switch tests fail on arm

2020-12-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #2 from Martin Liška  ---
Should be fixed on master, can you please re-check it?

[Bug tree-optimization/98123] if-to-switch tests fail on arm

2020-12-03 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Last reconfirmed||2020-12-03

--- Comment #1 from Martin Liška  ---
All right, I'm gonna test it with a cross compiler.

[Bug other/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

H.J. Lu  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-03
  Component|target  |other
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW

--- Comment #3 from H.J. Lu  ---
(In reply to H.J. Lu from comment #2)
> The issue here is that what should happen when definitions marked with used
> attribute and unmarked definitions are put in the same section. It has
> nothing
> to do with .retain.

If we cant to use SHF_GNU_RETAIN on used attribute, compiler can do

1. Issue an error.
2. issue a warning and mark the unmarked definition as used.
3. Silently mark the unmarked definition as used.

[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554

2020-12-03 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #5 from Eric Botcazou  ---
.

[Bug middle-end/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371

2020-12-03 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #9 from Eric Botcazou  ---
.

[Bug middle-end/98099] ICE in gen_lowpart_common, at emit-rtl.c:1554

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98099

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

https://gcc.gnu.org/g:277ff3406d533990e98cf1c2075b9dc9db6fa48a

commit r11-5706-g277ff3406d533990e98cf1c2075b9dc9db6fa48a
Author: Eric Botcazou 
Date:   Thu Dec 3 15:54:14 2020 +0100

Fix PR middle-end/98099

this replaces the ICE by a sorry message for the use of reverse scalar
storage order with 128-bit decimal floating-point type on 32-bit targets.

gcc/ChangeLog:
PR middle-end/98099
* expmed.c (flip_storage_order): In the case of a non-integer mode,
sorry out if the integer mode to be used instead is not supported.

gcc/testsuite/ChangeLog:
* gcc.dg/pr98099.c: New test.

[Bug middle-end/98082] [11 Regression] ICE in set_rtl, at cfgexpand.c:178 since r11-3257-g225a08220e444371

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98082

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r11-5705-g5d103763b9bc6a998dd4a453861663b229d7a24a
Author: Eric Botcazou 
Date:   Thu Dec 3 15:52:15 2020 +0100

Fix PR middle-end/98082

this fixes an ICE introduced by the fix for PR middle-end/97078 where
use_register_for_decl was changed to return true at -O0 for a parameter
of a thunk.  It turns out that we need to do the same for a result in
this case.

gcc/ChangeLog:
PR middle-end/98082
* function.c (use_register_for_decl): Also return true for a result
if cfun->tail_call_marked is true.

gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/pr98082.C: New test.

[Bug middle-end/97078] [11 Regression] ICE in set_rtl building glibc tests with -ffloat-store

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97078

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Eric Botcazou :

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

commit r11-5705-g5d103763b9bc6a998dd4a453861663b229d7a24a
Author: Eric Botcazou 
Date:   Thu Dec 3 15:52:15 2020 +0100

Fix PR middle-end/98082

this fixes an ICE introduced by the fix for PR middle-end/97078 where
use_register_for_decl was changed to return true at -O0 for a parameter
of a thunk.  It turns out that we need to do the same for a result in
this case.

gcc/ChangeLog:
PR middle-end/98082
* function.c (use_register_for_decl): Also return true for a result
if cfun->tail_call_marked is true.

gcc/testsuite/ChangeLog:
* g++.dg/cpp2a/pr98082.C: New test.

[Bug target/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

--- Comment #2 from H.J. Lu  ---
The issue here is that what should happen when definitions marked with used
attribute and unmarked definitions are put in the same section. It has nothing
to do with .retain.

[Bug libstdc++/93121] std::bit_cast missing

2020-12-03 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93121

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

https://gcc.gnu.org/g:896048cf43d5eb21ab7c16553bb9d13b0f890b81

commit r11-5704-g896048cf43d5eb21ab7c16553bb9d13b0f890b81
Author: Jakub Jelinek 
Date:   Thu Dec 3 15:46:54 2020 +0100

c++: Add __builtin_bit_cast to implement std::bit_cast [PR93121]

The following patch adds __builtin_bit_cast builtin, similarly to
clang or MSVC which implement std::bit_cast using such an builtin too.
It checks the various std::bit_cast requirements, when not constexpr
evaluated acts pretty much like VIEW_CONVERT_EXPR of the source argument
to the destination type and the hardest part is obviously the constexpr
evaluation.
I've left out PDP11 handling of those, couldn't figure out how exactly are
bitfields laid out there

2020-12-03  Jakub Jelinek  

PR libstdc++/93121
* fold-const.h (native_encode_initializer): Add mask argument
defaulted to nullptr.
(find_bitfield_repr_type): Declare.
(native_interpret_aggregate): Declare.
* fold-const.c (find_bitfield_repr_type): New function.
(native_encode_initializer): Add mask argument and support for
filling it.  Handle also some bitfields without integral
DECL_BIT_FIELD_REPRESENTATIVE.
(native_interpret_aggregate): New function.
* gimple-fold.h (clear_type_padding_in_mask): Declare.
* gimple-fold.c (struct clear_padding_struct): Add clear_in_mask
member.
(clear_padding_flush): Handle buf->clear_in_mask.
(clear_padding_union): Copy clear_in_mask.  Don't error if
buf->clear_in_mask is set.
(clear_padding_type): Don't error if buf->clear_in_mask is set.
(clear_type_padding_in_mask): New function.
(gimple_fold_builtin_clear_padding): Set buf.clear_in_mask to
false.
* doc/extend.texi (__builtin_bit_cast): Document.

* c-common.h (enum rid): Add RID_BUILTIN_BIT_CAST.
* c-common.c (c_common_reswords): Add __builtin_bit_cast.

* cp-tree.h (cp_build_bit_cast): Declare.
* cp-tree.def (BIT_CAST_EXPR): New tree code.
* cp-objcp-common.c (names_builtin_p): Handle RID_BUILTIN_BIT_CAST.
(cp_common_init_ts): Handle BIT_CAST_EXPR.
* cxx-pretty-print.c (cxx_pretty_printer::postfix_expression):
Likewise.
* parser.c (cp_parser_postfix_expression): Handle
RID_BUILTIN_BIT_CAST.
* semantics.c (cp_build_bit_cast): New function.
* tree.c (cp_tree_equal): Handle BIT_CAST_EXPR.
(cp_walk_subtrees): Likewise.
* pt.c (tsubst_copy): Likewise.
* constexpr.c (check_bit_cast_type, cxx_eval_bit_cast): New
functions.
(cxx_eval_constant_expression): Handle BIT_CAST_EXPR.
(potential_constant_expression_1): Likewise.
* cp-gimplify.c (cp_genericize_r): Likewise.

* g++.dg/cpp2a/bit-cast1.C: New test.
* g++.dg/cpp2a/bit-cast2.C: New test.
* g++.dg/cpp2a/bit-cast3.C: New test.
* g++.dg/cpp2a/bit-cast4.C: New test.
* g++.dg/cpp2a/bit-cast5.C: New test.

[Bug target/98121] __attribute__ ((used)) should not imply SHF_RETAIN_SECTION

2020-12-03 Thread jozefl at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98121

jozefl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jozefl at gcc dot gnu.org

--- Comment #1 from jozefl at gcc dot gnu.org ---
The feedback after I originally submitted a patch that implements a "retain"
attribute to apply SHF_GNU_RETIAN, was that "used" should instead apply
SHF_GNU_RETAIN:

https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557097.html

The discussions went on about other aspects of the implementation in other
threads, but there were no objections to the idea of "used" applying
SHF_GNU_RETAIN.

I think the logic is sound that a declaration marked with the "used" attribute
should not be removed by the compiler, or garbage collected by the linker.
Basically, if you mark a declaration as "used", it should be retained in the
final program, even if it was not referenced.

The issue lies in the fact that the "used" attribute has been around for so
long, that the change in behavior has the potential to affect existing
applications that make use of it.

However, the new behavior is only enabled when using the latest GCC and latest
Binutils. Some change in behavior can be expected when using the latest
versions of the tools. This new behavior should really be documented in the
release notes though.

I didn't want to have "used" change section attributes in assembler directives,
the original plan was to use a separate assembler ".retain" directive to apply
SHF_GNU_RETAIN. This would mean we could leave .section assembler directives
for a particular "used" declaration untouched, and just emit a ".retain
" directive. The assembler therefore handles the application of
the SHF_GNU_RETAIN flag to a particular section, instead of forcing the
compiler to have to make these additional considerations about section
attributes.

I even did a patch for that, but there was staunch objection from H.J. on this,
on multiple occasions, I realized we weren't going to get anywhere:

https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557931.html
https://gcc.gnu.org/pipermail/gcc-patches/2020-November/558400.html
https://sourceware.org/pipermail/binutils/2020-November/114077.html

I would be more than happy to add the .retain attribute to Binutils, but we
would need a Binutils global maintainer to approve that, and no one gave the OK
for my original ".retain " patch the first time round. I could
then change the GCC implementation to use the ".retain" directive, which would
ensure that section attributes in assembler code output by GCC are not
contaminated with the "R" flag when the "used" attribute is applied.

Thanks,
Jozef

[Bug tree-optimization/98123] New: if-to-switch tests fail on arm

2020-12-03 Thread clyon at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98123

Bug ID: 98123
   Summary: if-to-switch tests fail on arm
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

The recently introduced if-to-switch-* tests fail on arm:

gcc.dg/tree-ssa/if-to-switch-2.c scan-tree-dump iftoswitch "Condition chain
with 3 BBs transformed into a switch statement."
gcc.dg/tree-ssa/if-to-switch-3.c scan-tree-dump iftoswitch "Condition chain
with 3 BBs transformed into a switch statement."
gcc.dg/tree-ssa/if-to-switch-4.c scan-tree-dump-not iftoswitch "Condition
chain"
gcc.dg/tree-ssa/if-to-switch-5.c scan-tree-dump iftoswitch "Condition chain
with 5 BBs transformed into a switch statement."
gcc.dg/tree-ssa/if-to-switch-6.c scan-tree-dump-not iftoswitch "Condition
chain"
gcc.dg/tree-ssa/if-to-switch-8.c scan-tree-dump-not iftoswitch "Condition
chain"

When GCC is configured with:
--target arm-none-linux-gnueabihf
--with-mode thumb
--with-cpu cortex-a5
--with-fpu vfpv3-d16-fp16

Configuring for cortex-a9 instead of cortex-a5 shows less failures, only:
gcc.dg/tree-ssa/if-to-switch-4.c scan-tree-dump-not iftoswitch "Condition
chain"
gcc.dg/tree-ssa/if-to-switch-6.c scan-tree-dump-not iftoswitch "Condition
chain"
gcc.dg/tree-ssa/if-to-switch-8.c scan-tree-dump-not iftoswitch "Condition
chain"

[Bug tree-optimization/98113] [11 Regression] popcnt is not vectorized on s390 since f5e18dd9c7da

2020-12-03 Thread iii at linux dot ibm.com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98113

--- Comment #6 from Ilya Leoshkevich  ---
With the patch, vxe/popcount-1.c works on s390 again:

vpopctf:
.LFB2:
.cfi_startproc
vpopctf %v24,%v24
br  %r14

Thanks!

  1   2   >