[Bug libstdc++/104080] [12 Regression] newlib doesn't have endian.h causing build failure with 2800bc08e4ab r12-6646

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1
   Target Milestone|--- |12.0

[Bug c++/104079] [10/11/12 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1192

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/104074] [12 Regression] [c++17] Maybe rejected code: is not a valid type for a template non-type parameter since r12-6022-gbb2a7f80a98de3fe

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P1

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug c++/98824] [C++-20] function template non-type-class-arg deduction fails with a reason that looks bogus

2022-01-17 Thread bernie at codewiz dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98824

--- Comment #4 from Bernie Innocenti  ---
Are there any known workarounds?

[Bug c++/98824] [C++-20] function template non-type-class-arg deduction fails with a reason that looks bogus

2022-01-17 Thread bernie at codewiz dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98824

Bernie Innocenti  changed:

   What|Removed |Added

 CC||bernie at codewiz dot org

--- Comment #3 from Bernie Innocenti  ---
Assuming this is the same bug, it's still present in g++ 12 as well as trunk:
https://godbolt.org/z/6r3bc3j15

[Bug c++/104074] [12 Regression] [c++17] Maybe rejected code: is not a valid type for a template non-type parameter since r12-6022-gbb2a7f80a98de3fe

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=51577

--- Comment #4 from Andrew Pinski  ---
(In reply to Martin Liška from comment #0)
> The following test-case is isolated from libreoffice:

Note QT/chromium has the same code even as it comes from skia.

[Bug modula2/104065] [12 Regression] trunk 20220117 fails to build modula2

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104065

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build

--- Comment #1 from Andrew Pinski  ---
I get the feeling this is compiling with the C front-end rather than the C++
front-end like it should be 

[Bug tree-optimization/103721] [12 regression] wrong code generated for loop with conditional since r12-4790-g4b3a325f07acebf4

2022-01-17 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103721

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #4 from Jeffrey A. Law  ---
But what doesn't make any sense here is the folding in this block:

 [local count: 1073741824]:
# searchVolume_5 = PHI 
# currentVolume_6 = PHI 
_2 = searchVolume_5 != currentVolume_6;
_3 = searchVolume_5 != 0;
_4 = _2 & _3;
if (_4 != 0)
  goto ; [89.00%]
else
  goto ; [11.00%]


In fold_using_range::range_of_range_op we have:

(gdb) p debug_tree (op1)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7780e5e8 precision:32 min  max

pointer_to_this >
visited var 
def_stmt searchVolume_5 = PHI 
version:5>
$113 = void
(gdb) p debug_tree (op2)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set 1 canonical-type
0x7780e5e8 precision:32 min  max

pointer_to_this >
visited var 
def_stmt currentVolume_6 = PHI 
version:6>
$114 = void
(gdb) p rel
$115 = EQ_EXPR

If I'm reading the code correctly I think that means that the ranger has
determined that _5 and _6 are equal.  But I don't see how it can possibly make
that determination with this CFG:

int f (int world)
{
  int currentVolume;
  int searchVolume;
  int ipos.0_1;
  _Bool _2;
  _Bool _3;
  _Bool _4;

;;   basic block 2, loop depth 0
;;pred:   ENTRY
  goto ; [100.00%]
;;succ:   9

;;   basic block 3, loop depth 1
;;pred:   9
  ipos.0_1 = ipos;
  if (ipos.0_1 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]
;;succ:   8
;;4

;;   basic block 4, loop depth 1
;;pred:   3
;;succ:   8

;;   basic block 8, loop depth 1
;;pred:   4
;;3
  # searchVolume_11 = PHI <1(4), 0(3)>
  # currentVolume_8 = PHI 
;;succ:   9

;;   basic block 9, loop depth 1
;;pred:   8
;;2
  # searchVolume_5 = PHI 
  # currentVolume_6 = PHI 
  _2 = searchVolume_5 != currentVolume_6;
  _3 = searchVolume_5 != 0;
  _4 = _2 & _3;
  if (_4 != 0)
goto ; [89.00%]
  else
goto ; [11.00%]
;;succ:   3
;;7

;;   basic block 7, loop depth 0
;;pred:   9
  return currentVolume_6;
;;succ:   EXIT

}

This feels like it's got to be a problem in the equivalence handling -- it's
largely outside the threader.

My recollection of equivalences in loops is that they're exceedingly hard to
get correct once you follow the backedge -- particularly since you have to
invalidate some equivalences once you traverse that backedge.  Finding the set
that needed to be invalidated was expensive and the book keeping turned out to
be too hard to do reliably so I ripped it all out.

How does equivalence handling in the Ranger world work once you traverse the
backedge of a loop?

[Bug target/103973] x86: 4-way comparison of floats/doubles with spaceship operator possibly suboptimal

2022-01-17 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103973

--- Comment #11 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r12-6655-g5e26bf17220926d308d0e3bb82bae6e592d2e485
Author: liuhongt 
Date:   Tue Jan 18 10:45:10 2022 +0800

Adjust testcase for --target_board='unix{-m64\ -march=cascadelake}'

Change scan-assembler from "\tucomisd" to "\t\[v\]?ucomisd".

gcc/testsuite/ChangeLog:

PR target/103973
* g++.target/i386/pr103973-1.C: Change scan-assembler from
"\tucomisd" to "\t\[v\]?ucomisd".
* g++.target/i386/pr103973-11.C: Ditto.
* g++.target/i386/pr103973-13.C: Ditto.
* g++.target/i386/pr103973-15.C: Ditto.
* g++.target/i386/pr103973-3.C: Ditto.
* g++.target/i386/pr103973-5.C: Ditto.
* g++.target/i386/pr103973-7.C: Ditto.
* g++.target/i386/pr103973-9.C: Ditto.
* gcc.target/i386/pr103973-1.c: Ditto.
* gcc.target/i386/pr103973-11.c: Ditto.
* gcc.target/i386/pr103973-13.c: Ditto.
* gcc.target/i386/pr103973-15.c: Ditto.
* gcc.target/i386/pr103973-3.c: Ditto.
* gcc.target/i386/pr103973-5.c: Ditto.
* gcc.target/i386/pr103973-7.c: Ditto.
* gcc.target/i386/pr103973-9.c: Ditto.

[Bug target/104015] [12 regression] gcc.dg/vect/slp-perm-9.c fails on power 9 (only)

2022-01-17 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104015

--- Comment #11 from Kewen Lin  ---
(In reply to rsand...@gcc.gnu.org from comment #10)
> Checking the number of tries might be useful, but if so, I think
> it should be done by a test that was written for that specific
> purpose.  The tst can then be updated if the original way of checking
> the number of tries no longer worked for some reason.  The test
> would likely be target-specific (since, for example, the expectations
> are different for Power 9 and Power 10).
> 
> But this test was added to test how the SLP permute code handled
> groups of 3 elements.  IMO that's the only thing that it should test.
> Even the existing target selectors are so complicated as to be almost
> incomprehensible. :-)

Good point and idea! I just posted one patch
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588658.html following
this nice suggestion.

[Bug libstdc++/104080] [12 Regression] newlib doesn't have endian.h causing build failure with 2800bc08e4ab r12-6646

2022-01-17 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW

[Bug libstdc++/104080] [12 Regression] newlib doesn't have endian.h causing build failure with 2800bc08e4ab r12-6646

2022-01-17 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080

--- Comment #2 from Hans-Peter Nilsson  ---
Created attachment 52215
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52215&action=edit
patch for endian.h issue

This patch is not sufficient: after this, I get:
libtool: compile:  /X-obj/./gcc/xgcc -shared-libgcc -B/X-obj/./gcc -nostdinc++
-L/X-obj/cris-elf/libstdc++-v3/src -L/X-obj/cris-elf/libstdc++-v3/src/.libs
-L/X-obj/cris-elf/libstdc++-v3/libsupc++/.libs -nostdinc
-B/X-obj/cris-elf/newlib/ -isystem /X-obj/cris-elf/newlib/targ-include -isystem
/X-gccsrc/newlib/libc/include -B/X-obj/cris-elf/libgloss/cris
-L/X-obj/cris-elf/libgloss/libnosys -L/X-gccsrc/libgloss/cris
-B/mnt/storage0/hp/tmpdir/break22017-1/pre/cris-elf/bin/
-B/mnt/storage0/hp/tmpdir/break22017-1/pre/cris-elf/lib/ -isystem
/mnt/storage0/hp/tmpdir/break22017-1/pre/cris-elf/include -isystem
/mnt/storage0/hp/tmpdir/break22017-1/pre/cris-elf/sys-include
-I/X-gccsrc/libstdc++-v3/../libgcc
-I/X-obj/cris-elf/libstdc++-v3/include/cris-elf
-I/X-obj/cris-elf/libstdc++-v3/include -I/X-gccsrc/libstdc++-v3/libsupc++
-std=gnu++17 -nostdinc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -g
-O2 -c /X-gccsrc/libstdc++-v3/src/c++17/floating_from_chars.cc -o
floating_from_chars.o
In file included from
/X-gccsrc/libstdc++-v3/src/c++17/floating_from_chars.cc:65:
/X-gccsrc/libstdc++-v3/src/c++17/fast_float/fast_float.h: In function 'void
{anonymous}::fast_float::round(adjusted_mantissa&, callback)':
/X-gccsrc/libstdc++-v3/src/c++17/fast_float/fast_float.h:2469:20: error: no
matching function for call to 'min(int32_t&, int)'
 2469 | cb(am, std::min(shift, 64));
  |^~~
In file included from /X-obj/cris-elf/libstdc++-v3/include/string:50,
 from
/X-gccsrc/libstdc++-v3/src/c++17/floating_from_chars.cc:35:
/X-obj/cris-elf/libstdc++-v3/include/bits/stl_algobase.h:230:5: note:
candidate: 'template constexpr const _Tp& std::min(const _Tp&, const
_Tp&)'
  230 | min(const _Tp& __a, const _Tp& __b)
  | ^~~
/X-obj/cris-elf/libstdc++-v3/include/bits/stl_algobase.h:230:5: note:  
template argument deduction/substitution failed:
/X-gccsrc/libstdc++-v3/src/c++17/fast_float/fast_float.h:2469:20: note:  
deduced conflicting types for parameter 'const _Tp' ('long int' and 'int')
 2469 | cb(am, std::min(shift, 64));
  |^~~
/X-obj/cris-elf/libstdc++-v3/include/bits/stl_algobase.h:278:5: note:
candidate: 'template constexpr const _Tp&
std::min(const _Tp&, const _Tp&, _Compare)'
  278 | min(const _Tp& __a, const _Tp& __b, _Compare __comp)
  | ^~~
/X-obj/cris-elf/libstdc++-v3/include/bits/stl_algobase.h:278:5: note:  
template argument deduction/substitution failed:
/X-gccsrc/libstdc++-v3/src/c++17/fast_float/fast_float.h:2469:20: note:  
deduced conflicting types for parameter 'const _Tp' ('long int' and 'int')
 2469 | cb(am, std::min(shift, 64));
  |^~~
make[5]: *** [Makefile:585: floating_from_chars.lo] Error 1
make[5]: Leaving directory '/X-obj/cris-elf/libstdc++-v3/src/c++17'

This is likely the usual size_t mismatch.  Unassigning myself.

[Bug libstdc++/104080] [12 Regression] newlib doesn't have endian.h causing build failure with 2800bc08e4ab r12-6646

2022-01-17 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080

Hans-Peter Nilsson  changed:

   What|Removed |Added

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

--- Comment #1 from Hans-Peter Nilsson  ---
I'm testing an obvious patch.

[Bug libstdc++/104080] [12 Regression] newlib doesn't have endian.h causing build failure with 2800bc08e4ab r12-6646

2022-01-17 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug libstdc++/104080] New: [12 Regression] newlib doesn't have endian.h causing build failure with 2800bc08e4ab r12-6646

2022-01-17 Thread hp at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104080

Bug ID: 104080
   Summary: [12 Regression] newlib doesn't have endian.h causing
build failure with 2800bc08e4ab r12-6646
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
  Target Milestone: ---
Target: cris-elf

With a commit in the range a81f6092350c..490e23032baa, most likely 2800bc08e4ab
a.k.a. r12-6646, newlib targets such as cris-elf has started failing at build
time of libstdc++ thus:

make[5]: Entering directory '/X-obj/cris-elf/libstdc++-v3/src/c++17'
/bin/sh ../../libtool --tag CXX --tag disable-shared   --mode=compile
/X-obj/./gcc/xgcc -shared-libgcc -B/X-obj/./gcc -nostdinc++
-L/X-obj/cris-elf/libstdc++-v3/src -L/X-obj/cris-elf/libstdc++-v3/src/.libs
-L/X-obj/cris-elf/libstdc++-v3/libsupc++/.libs -nostdinc
-B/X-obj/cris-elf/newlib/ -isystem /X-obj/cris-elf/newlib/targ-include -isystem
/X-gccsrc/newlib/libc/include -B/X-obj/cris-elf/libgloss/cris
-L/X-obj/cris-elf/libgloss/libnosys -L/X-gccsrc/libgloss/cris
-B/X/pre/cris-elf/bin/ -B/X/pre/cris-elf/lib/ -isystem /X/pre/cris-elf/include
-isystem /X/pre/cris-elf/sys-include-I/X-gccsrc/libstdc++-v3/../libgcc
-I/X-obj/cris-elf/libstdc++-v3/include/cris-elf
-I/X-obj/cris-elf/libstdc++-v3/include -I/X-gccsrc/libstdc++-v3/libsupc++  
-std=gnu++17 -nostdinc++   -fno-implicit-templates  -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi=2  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=floating_from_chars.lo 
-fimplicit-templates -g -O2  -c -o floating_from_chars.lo
/X-gccsrc/libstdc++-v3/src/c++17/floating_from_chars.cc
libtool: compile:  /X-obj/./gcc/xgcc -shared-libgcc -B/X-obj/./gcc -nostdinc++
-L/X-obj/cris-elf/libstdc++-v3/src -L/X-obj/cris-elf/libstdc++-v3/src/.libs
-L/X-obj/cris-elf/libstdc++-v3/libsupc++/.libs -nostdinc
-B/X-obj/cris-elf/newlib/ -isystem /X-obj/cris-elf/newlib/targ-include -isystem
/X-gccsrc/newlib/libc/include -B/X-obj/cris-elf/libgloss/cris
-L/X-obj/cris-elf/libgloss/libnosys -L/X-gccsrc/libgloss/cris
-B/X/pre/cris-elf/bin/ -B/X/pre/cris-elf/lib/ -isystem /X/pre/cris-elf/include
-isystem /X/pre/cris-elf/sys-include -I/X-gccsrc/libstdc++-v3/../libgcc
-I/X-obj/cris-elf/libstdc++-v3/include/cris-elf
-I/X-obj/cris-elf/libstdc++-v3/include -I/X-gccsrc/libstdc++-v3/libsupc++
-std=gnu++17 -nostdinc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=floating_from_chars.lo -fimplicit-templates -g
-O2 -c /X-gccsrc/libstdc++-v3/src/c++17/floating_from_chars.cc -o
floating_from_chars.o
In file included from
/X-gccsrc/libstdc++-v3/src/c++17/floating_from_chars.cc:65:
/X-gccsrc/libstdc++-v3/src/c++17/fast_float/fast_float.h:139:10: fatal error:
endian.h: No such file or directory
  139 | #include 
  |  ^~
compilation terminated.
make[5]: *** [Makefile:585: floating_from_chars.lo] Error 1
make[5]: Leaving directory '/X-obj/cris-elf/libstdc++-v3/src/c++17'

Newlib doesn't have endian.h, but it does have machine/endian.h.
An obvious patch is being tested.

[Bug c++/104079] [10/11/12 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1192

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=52869

--- Comment #4 from Andrew Pinski  ---
I suspect the patch which fixed PR 52869 caused this.

[Bug c++/104079] [10/11/12 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1192

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=96242

--- Comment #3 from Andrew Pinski  ---
A little more reduced:
template 
struct AT
{
static void cn() noexcept(b);
void SNFP( void *n ) noexcept(noexcept(cn()));
};

[Bug target/103702] [12 Regression] ICE in update_target_cost_per_stmt, at config/rs6000/rs6000.c:5457

2022-01-17 Thread linkw at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103702

--- Comment #4 from Kewen Lin  ---
Patch was posted with the link
https://gcc.gnu.org/pipermail/gcc-patches/2021-December/587309.html, still
pending on review.

[Bug c++/104079] [10/11/12 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1192

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079

--- Comment #2 from Andrew Pinski  ---
A little more reduced:
template 
struct AT
{
static void cn() noexcept(noexcept(DT::CN()));
void SNFP( void *n ) noexcept(noexcept(cn()));
};

[Bug c++/104079] [10/11/12 Regression] internal compiler error: in nothrow_spec_p, at cp/except.c:1192

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code,
   ||needs-bisection
   Last reconfirmed||2022-01-18
 Ever confirmed|0   |1
  Known to fail||10.1.0
  Known to work||9.1.0, 9.4.0
 Status|UNCONFIRMED |NEW
   Target Milestone|--- |10.4
Summary|internal compiler error: in |[10/11/12 Regression]
   |nothrow_spec_p, at  |internal compiler error: in
   |cp/except.c:1192|nothrow_spec_p, at
   ||cp/except.c:1192

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug c++/104079] New: internal compiler error: in nothrow_spec_p, at cp/except.c:1192

2022-01-17 Thread turningtides at outlook dot de via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104079

Bug ID: 104079
   Summary: internal compiler error: in nothrow_spec_p, at
cp/except.c:1192
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: turningtides at outlook dot de
  Target Milestone: ---

Created attachment 52214
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52214&action=edit
gcc -c main.cpp main.o

main.cpp:6:46: internal compiler error: in nothrow_spec_p, at cp/except.c:1192
6 | void SNFP( void *n ) noexcept(noexcept(cn( n, n )))
  |~~^~~~
0x5fcb2b nothrow_spec_p(tree_node const*)
../../src/gcc/cp/except.c:1192
0x5fcb2b nothrow_spec_p(tree_node const*)
../../src/gcc/cp/except.c:1184
0x108ec56 set_flags_from_callee(tree_node*)
../../src/gcc/cp/call.c:334
0x108b529 build_call_a(tree_node*, int, tree_node**)
../../src/gcc/cp/call.c:371
0x108ad76 build_cxx_call(tree_node*, int, tree_node**, int, tree_node*)
../../src/gcc/cp/call.c:10057
0x1073257 build_over_call
../../src/gcc/cp/call.c:9561
0x1134b3c build_new_method_call_1
../../src/gcc/cp/call.c:10814
0x1134696 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
../../src/gcc/cp/call.c:10890
0x106298f finish_call_expr(tree_node*, vec**,
bool, bool, int)
../../src/gcc/cp/semantics.c:2751
0x10da2d2 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:20485
0x10db12c tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../src/gcc/cp/pt.c:20012
0x1014712 instantiate_non_dependent_expr_internal(tree_node*, int)
../../src/gcc/cp/pt.c:6342
0x1014712 instantiate_non_dependent_expr_sfinae(tree_node*, int)
../../src/gcc/cp/pt.c:6370
0x1014712 instantiate_non_dependent_expr_sfinae(tree_node*, int)
../../src/gcc/cp/pt.c:6354
0x1014712 build_noexcept_spec(tree_node*, int)
../../src/gcc/cp/except.c:1240
0xfb9ee9 cp_parser_late_noexcept_specifier
../../src/gcc/cp/parser.c:26836
0xfb9ee9 cp_parser_class_specifier_1
../../src/gcc/cp/parser.c:25148
0xfa344c cp_parser_class_specifier
../../src/gcc/cp/parser.c:25235
0xfa344c cp_parser_type_specifier
../../src/gcc/cp/parser.c:18478
0xfa052c cp_parser_decl_specifier_seq
../../src/gcc/cp/parser.c:15089
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/103124] PPC: "mr" instruction is unnecessary when extending DI to V1TI

2022-01-17 Thread guihaoc at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103124

HaoChen Gui  changed:

   What|Removed |Added

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

--- Comment #7 from HaoChen Gui  ---
fixed by r12-6620

[Bug middle-end/103483] [12 regression] context-sensitive ranges change triggers stringop-overread

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483

--- Comment #17 from Martin Sebor  ---
Jaosn: this is how all middle-end warnings have always behaved.  They trigger
on invalid statements present in the IL.  A statement is considered invalid
when any of its operands is out of bounds or in some other way not valid for it
(e.g., null in -Wnonnull, or not pointing to the first byte allocated on the
heap in -Wfree-nonheap-pointer, or not matching an allocation call in
-Wmismatched-dealloc).  Warnings don't differentiate between constant operands
or those in some range.  We have been making more extensive use of ranges since
get_range_info() was introduced, but prior to that, -Warray-bounds made use of
ranges as well (thanks to VRP).  Even in warnings that don't use ranges,
constant operands need not be literals: they can be reduced to constants from
ranges by various transformations (jump threading is just one of them).  For
more background please see my two-part article from 2019: Understanding GCC
Warnings:

  https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings
 
https://developers.redhat.com/blog/2019/03/13/understanding-gcc-warnings-part-2

It's easy to derive examples from the one in comment #12 or comment #15 showing
other similar warnings: replacing the memcpy() call with an array subscript
triggers a -Warray-bounds; snprintf() triggers -Wformat-truncation; malloc()
triggers -Walloc-size-larger-than; etc.  See below.  (I also showed an example
with -Wnonnull in comment #13.  It's issued on the same basis.)

It might seem like the common denominator in all these instances is ranges, but
they're a red herring.  The same effect can be demonstrated without them.  The
root cause behind them all is that (again) warnings are designed to trigger for
apparently reachable invalid IL.  See pr54202 for an example from 2012 with
-Wfree-nonheap-object.  The warning is simply based on what the pointer points
to, irrespective of the conditions under which the invalid statement is
evaluated.

If you consider any of the warnings above false positives you must consider as
such all of them.  It makes no sense to do something about just a subset of
them and not the rest.  And to avoid them altogether you have to disable (or at
least seriously cripple) all those we've ever added into the middle end.  You
could, for example, only warn in statements that are reached unconditionally
from function entry.  Removing them them all from -Wall and making them opt-in
would reduce the number of complaints but only as a result of the number of
users explicitly enabling the warnings, without actually improving anything
(besides, by being included in -Wall most already are opt-in).  In any event,
any of these alternatives would compromise the security improvements we have
invested so much in over the years.  The best solution, in my view, is to show
users the conditionals under which the invalid statements can be reached.  I
hoped to be able to do that by extending Ranger
(https://gcc.gnu.org/pipermail/gcc/2021-December/237922.html) but it could also
be done by rolling a range propagation engine just for warnings (like for the
static analyzer).

char *sink;
__attribute__ ((noipa))
int mystrlen (const char *p)
{
  return __builtin_strlen (p);
}

inline void copy(const char *p)
{
  int L = mystrlen (p);
  if (L < 5)
/* Small string magic. */;
  else
   *sink = p[L];
}
void f()
{ 
  copy ("12");
} 

In function ‘copy’,
inlined from ‘f’ at a.c:18:3:
a.c:14:13: warning: array subscript [5, 2147483647] is outside array bounds of
‘char[3]’ [-Warray-bounds]
   14 |*sink = p[L];
  |~^~~

char *sink;
__attribute__ ((noipa))
int mystrlen (const char *p)
{
  return __builtin_strlen (p);
}

inline void copy(const char *p)
{
  int L = mystrlen (p);
  if (L < 5)
/* Small string magic. */;
  else
__builtin_snprintf (sink, 5, "%*s", L, p);
}
void f()
{ 
  copy ("12");
} 

a.c: In function ‘f’:
a.c:14:38: warning: ‘__builtin_snprintf’ output truncated before the last
format character [-Wformat-truncation=]
   14 | __builtin_snprintf (sink, 5, "%*s", L, p);
  |  ^
In function ‘copy’,
inlined from ‘f’ at a.c:18:3:
a.c:14:5: note: ‘__builtin_snprintf’ output between 6 and 2147483648 bytes into
a destination of size 5
   14 | __builtin_snprintf (sink, 5, "%*s", L, p);
  | ^


$ gcc -O2 -S -Walloc-size-larger-than=4 a.c
har *sink;
__attribute__ ((noipa))
int mystrlen (const char *p)
{
  return __builtin_strlen (p);
}

inline void copy(const char *p)
{
  int L = mystrlen (p);
  if (L < 5)
/* Small string magic. */;
  else
sink = __builtin_malloc (L);
}
void f()
{ 
  copy ("12");
} 

In function ‘copy’,
inlined from ‘f’ at a.c:18:3:
a.c:14:12: warning: argument 1 range [5, 2147483647] exceeds maximum object
size 4 [-Walloc-size-larger-than=]
   14 | sink = __builtin_malloc (L);
  |

[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

2022-01-17 Thread hubicka at kam dot mff.cuni.cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558

--- Comment #13 from hubicka at kam dot mff.cuni.cz ---
> Result pure looping 0
> Function found to be pure: foo/4
This is good - we are supposed to find it to be pure and walk all
aliases and update noninterposable ones
> Declaration updated to be pure: foo/4
I have to take look why this happens though.

[Bug middle-end/103483] [12 regression] context-sensitive ranges change triggers stringop-overread

2022-01-17 Thread amacleod at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483

--- Comment #16 from Andrew Macleod  ---
The only thing I can think of is it is *guaranteed* to be out of range, then
assume that is because those other values were handled elsewhere and don't
report it?  

L_3 int [5, +INF]
 [local count: 354334800]:
_4 = (long unsigned int) L_3;
sink.0_5 = sink;
__builtin_memcpy (sink.0_5, "12", _4);

_4 : long unsigned int [5, 2147483647]

That is different than if _4 was varying or [1, 2147483647].

of course, then you wont catch the cases where its guaranteed that we are going
to copy too many bytes.  But then, you don't get those if you just turn it off
either.

[Bug middle-end/103483] [12 regression] context-sensitive ranges change triggers stringop-overread

2022-01-17 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103483

Jason Merrill  changed:

   What|Removed |Added

 CC||jeffreyalaw at gmail dot com
Summary|context-sensitive ranges|[12 regression]
   |change triggers |context-sensitive ranges
   |stringop-overread   |change triggers
   ||stringop-overread

--- Comment #15 from Jason Merrill  ---
Jeff, I remember running into similar issues in the past with jump-threading
creating nonsensical blocks which we would then give other warnings about, and
I think you fixed at least one of those.  Do you have any input that could help
guide us to a resolution of this problem?

Note that the original testcase no longer warns on trunk because 
disables the warning entirely.

To simplify my example a bit (compile with -O -Wall)

char *sink;
int mystrlen (const char *p);
inline void copy(const char *p)
{
  int L = mystrlen (p);
  if (L < 5)
/* Small string magic. */;
  else
__builtin_memcpy (sink, p, L);
}
void f()
{
  copy ("12"); // bogus warning 
}

I see that this actually warns as far back as GCC 8; I guess this is an older
problem that has only gotten more problematic with improvements in value range
propagation.

I don't see any plausible way for the user to guard this perfectly reasonable
code against this warning, other than disabling it.

Again, at the point of the memcpy we don't know anything about the probability
of different values of L.  With or without the if condition, if we try to
memcpy 5 bytes out of "12" we get undefined behavior; that doesn't become more
likely because we want to handle small L differently.  It creates a branch that
is all undefined behavior, but that doesn't make the branch reachable.

[Bug fortran/82968] gfortran.dg/ieee/ieee_6.f90 fails at -O0

2022-01-17 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82968

--- Comment #6 from Eric Botcazou  ---
I get this compilation error:

In file included from /home/ebotcazou/src/libgfortran/runtime/fpu.c:29:
./fpu-target.h:36:24: error: invalid application of 'sizeof' to incomplete type
'struct fenv'
   36 | _Static_assert (sizeof(struct fenv) <= 8 * GFC_FPE_STATE_INT_KIND,
  |^~
./fpu-target.h:36:17: error: expression in static assertion is not an integer
   36 | _Static_assert (sizeof(struct fenv) <= 8 * GFC_FPE_STATE_INT_KIND,
  | ^~
make[2]: *** [Makefile:3071: fpu.lo] Error 1
make[2]: Leaving directory
'/home/ebotcazou/build/sparc64-linux-gnu/libgfortran'
make[1]: *** [Makefile:1692: all] Error 2
make[1]: Leaving directory
'/home/ebotcazou/build/sparc64-linux-gnu/libgfortran'
make: *** [Makefile:23173: all-target-libgfortran] Error 2

[Bug c++/104074] [12 Regression] [c++17] Maybe rejected code: is not a valid type for a template non-type parameter since r12-6022-gbb2a7f80a98de3fe

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074

Andrew Pinski  changed:

   What|Removed |Added

 CC||linux at carewolf dot com

--- Comment #3 from Andrew Pinski  ---
*** Bug 104078 has been marked as a duplicate of this bug. ***

[Bug c++/104078] Some type determination weirdness

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104078

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
THis was just reported as PR 104074.

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

[Bug c++/104025] [12 Regression] '-fcompare-debug' failure with enabled warnings since r12-6563-gb8ffa71e4271ae56

2022-01-17 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025

--- Comment #6 from Jason Merrill  ---
(In reply to Jakub Jelinek from comment #5)
> Created attachment 52213 [details]
> gcc12-pr104025.patch
> 
> Untested fix.  I think the old input_location is the right one.

I think the bug is that cp_lexer_rollback_tokens isn't properly updating
input_location.

[Bug c++/104078] New: Some type determination weirdness

2022-01-17 Thread linux at carewolf dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104078

Bug ID: 104078
   Summary: Some type determination weirdness
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linux at carewolf dot com
  Target Milestone: ---

In an attempt to compile Qt and specifically Qt WebEngine with latest gcc 12
from git today, I git the follow weird error, from Skia inside Chromium inside
QtWebengine:

./../../../../../qtwebengine/src/3rdparty/chromium/third_party/skia/src/gpu/GrRefCnt.h:173:73:
error: ‘‘dependent_operator_type’ not supported by dump_type’ is
not a valid type for a template non-type parameter
  173 | gr_sp;
  |
^
../../../../../../qtwebengine/src/3rdparty/chromium/third_party/skia/src/gpu/GrRefCnt.h:173:73:
error: ‘‘dependent_operator_type’ not supported by dump_type’ is
not a valid type for a template non-type parameter

The error triggers in C++17 mode only, and the file compiles fine in C++20 mode
(and in c++17 mode on older gccs, and clang and msvc, etc).

[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558

--- Comment #12 from Andrew Pinski  ---
(In reply to Rich Felker from comment #11)
> Are you sure? If pure/const discovery is no longer applied to weak
> definitions, it shouldn't be able to propagate to a non-inlined caller. Of
> course the fix may be incomplete or not working, which I guess we could tell
> from whether it happened prior to or after comment 5. :)

There still looks like there is a bug as shown by taking the original testcase
in comment #0 and using -O2 -fno-inline, you will get:

reclaim_gaps:
ret
...
foo:
ret

Which is still wrong as reclaim should not be considered as pure.

>From *.pure-const:

Starting cycle
  Visiting donate_dummy/0 state:const looping 0
Result const looping 0
Function found not to call free: donate_dummy/0
Starting cycle
  Visiting reclaim/2 state:pure looping 0
Call to __malloc_donate/1 const
Result pure looping 0
Function found to be pure: reclaim/2
Declaration updated to be pure: reclaim/2
Starting cycle
  Visiting reclaim_gaps/3 state:pure looping 0
Call to reclaim/2 state:pure looping:0
Call to reclaim/2 state:pure looping:0
Result pure looping 0
Function found to be pure: reclaim_gaps/3
Declaration updated to be pure: reclaim_gaps/3
Starting cycle
  Visiting foo/4 state:const looping 0
Call to reclaim_gaps/3 state:pure looping:0
Result pure looping 0
Function found to be pure: foo/4
Declaration updated to be pure: foo/4

reclaim, reclaim_gaps and foo are all found as pure. without -fno-inline, we
get some early inlining which causes the difference there.

[Bug middle-end/104077] bogus/missing -Wdangling-pointer

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-17
  Alias||Wdangling-pointer
 Status|UNCONFIRMED |NEW
 Depends on||104076
   Keywords||diagnostic, meta-bug
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076
[Bug 104076] bogus -Wdangling-pointer on a conditional

[Bug middle-end/104077] New: bogus/missing -Wdangling-pointer

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104077

Bug ID: 104077
   Summary: bogus/missing -Wdangling-pointer
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This meta-bug tracks false positives and negatives in the middle-end
-Wdangling-pointer, new in GCC 12.

[Bug middle-end/104076] bogus -Wdangling-pointer on a conditional

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-01-17
   Keywords||diagnostic

[Bug middle-end/104076] New: bogus -Wdangling-pointer on a conditional

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104076

Bug ID: 104076
   Summary: bogus -Wdangling-pointer on a conditional
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

As reported in
https://gcc.gnu.org/pipermail/gcc-patches/2022-January/588620.html, the new
-Wdangling-pointer issues a false positive for the following test case:

$ cat t.C && g++ -S -Wall t.C
#include 

struct S1
{
  S1 (int);
  ~S1 ();
};

struct S2 { S2 (std::initializer_list); };

S2 f1();

S2 f2(bool b)
{
  return b ? f1() : S2{0};
}

t.C: In function ‘S2 f2(bool)’:
t.C:16:1: warning: dangling pointer to an unnamed temporary may be used
[-Wdangling-pointer=]
   16 | }
  | ^
t.C:15:25: note: unnamed temporary defined here
   15 |   return b ? f1() : S2{0};
  | ^
t.C:16:1: warning: dangling pointer to an unnamed temporary may be used
[-Wdangling-pointer=]
   16 | }
  | ^
t.C:15:25: note: unnamed temporary defined here
   15 |   return b ? f1() : S2{0};
  | ^

[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

2022-01-17 Thread bugdal at aerifal dot cx via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558

--- Comment #11 from Rich Felker  ---
Are you sure? If pure/const discovery is no longer applied to weak definitions,
it shouldn't be able to propagate to a non-inlined caller. Of course the fix
may be incomplete or not working, which I guess we could tell from whether it
happened prior to or after comment 5. :)

[Bug fortran/103692] [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062

2022-01-17 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103692

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2022-January/057420.html

[Bug middle-end/104075] bogus/missing -Wuse-after-free

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-01-17
 Depends on||104069
   Keywords||diagnostic, meta-bug
 Ever confirmed|0   |1


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069
[Bug 104069] -Werror=use-after-free false positive on elfutils-0.186

[Bug middle-end/104075] New: bogus/missing -Wuse-after-free

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104075

Bug ID: 104075
   Summary: bogus/missing -Wuse-after-free
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This meta-bug tracks false positives and negatives in the middle-end
-Wuse-after-free, new in GCC 12 (unrelated to -Wanalyzer-use-after-free).

[Bug c++/104074] [12 Regression] [c++17] Maybe rejected code: is not a valid type for a template non-type parameter since r12-6022-gbb2a7f80a98de3fe

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074

--- Comment #2 from Andrew Pinski  ---
The following are accepted:
struct f;

template  class pfm;
template  using u0 = pfm<&T::recycle>;
template  class pmv;
template  using u1= pmv<&T::recycle>;
template  class ptr;
template  using u2= ptr<&T::recycle>;

So I don't see why auto would be special not accepting this here.

[Bug tree-optimization/104069] -Werror=use-after-free false positive on elfutils-0.186

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069

--- Comment #4 from Martin Sebor  ---
Actually, this is already supposed to be handled but the code is not effective
due to a typo.  This fixes it:

diff --git a/gcc/gimple-ssa-warn-access.cc b/gcc/gimple-ssa-warn-access.cc
index f639807a78a..f9508a1d211 100644
--- a/gcc/gimple-ssa-warn-access.cc
+++ b/gcc/gimple-ssa-warn-access.cc
@@ -4082,7 +4082,9 @@ pointers_related_p (gimple *stmt, tree p, tree q,
pointer_query &qry)
   access_ref pref, qref;
   if (!qry.get_ref (p, stmt, &pref, 0)
   || !qry.get_ref (q, stmt, &qref, 0))
-return true;
+/* GET_REF() only rarely fails.  When it does, it's likely because
+   it involves a self-referential PHI.  Return a conservative result.  */
+return false;

   return pref.ref == qref.ref;
 }

[Bug c++/104074] [12 Regression] [c++17] Maybe rejected code: is not a valid type for a template non-type parameter since r12-6022-gbb2a7f80a98de3fe

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Last reconfirmed||2022-01-17
 Status|UNCONFIRMED |NEW
Summary|[12 Regression] Maybe   |[12 Regression] [c++17]
   |rejected code: is not a |Maybe rejected code: is not
   |valid type for a template   |a valid type for a template
   |non-type parameter since|non-type parameter since
   |r12-6022-gbb2a7f80a98de3fe  |r12-6022-gbb2a7f80a98de3fe
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
I think it is valid too. GCC does accept it for -std=c++20 but not for
-std=c++17 .

[Bug c++/104074] New: [12 Regression] Maybe rejected code: is not a valid type for a template non-type parameter since r12-6022-gbb2a7f80a98de3fe

2022-01-17 Thread marxin at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104074

Bug ID: 104074
   Summary: [12 Regression] Maybe rejected code: is not a valid
type for a template non-type parameter since
r12-6022-gbb2a7f80a98de3fe
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: ppalka at gcc dot gnu.org
  Target Milestone: ---

The following test-case is isolated from libreoffice:

$ cat x.ii
template  class gr_sp;
template  using gr_rp = gr_sp<&T::recycle>;

$ g++ x.ii -c
x.ii:2:54: error: ‘‘dependent_operator_type’ not supported by dump_type’ is not a valid type for a template non-type parameter
2 | template  using gr_rp = gr_sp<&T::recycle>;
  |  ^

clang accepts the code snippet

[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]

2022-01-17 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758

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

https://gcc.gnu.org/g:2c4b5bd4440292eca51de1f09ccce0d139ab981e

commit r11-9474-g2c4b5bd4440292eca51de1f09ccce0d139ab981e
Author: Marek Polacek 
Date:   Mon Jan 17 16:26:01 2022 -0500

c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]

I'm tired of seeing

cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]

every time I compile cp/parser.c, which happens...a lot.  I'd like my
compilation to be free of warnings, otherwise I'm going to miss some
important ones.

"decl-specifiers" is a C++ grammar term; it is not actual code, so
should not be wrapped with %< %>.  I hope we can accept it as an exception
in check_tokens.

It was surrounded by %< %> in cp_parser_decl_specifier_seq, so fix that.

In passing, fix a misspelling in missspellings.

PR c++/103758

gcc/c-family/ChangeLog:

* c-format.c (check_tokens): Accept "decl-specifier*".

gcc/cp/ChangeLog:

* parser.c (cp_parser_decl_specifier_seq): Replace
%
with %qD.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-condition.C: Adjust dg-error.

(cherry picked from commit bb936163e28fdbe1a751c55d5e5975e036322a3d)

[Bug target/104045] [AArch64] combine related to insn fmaxnm

2022-01-17 Thread joseph at codesourcery dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104045

--- Comment #5 from joseph at codesourcery dot com  ---
Folding the fmax operation should be valid in the absence of 
-fsignaling-nans (fmax (a, +Inf) should return +Inf without raising any 
exceptions, for any x not a signaling NaN).  However, replacing the 
division with the constant +Inf is only valid with -fno-trapping-math 
(though it would be OK by default to use the fact that the result is +Inf 
in optimizing the fmax call, as long as the division itself doesn't get 
removed so the divide-by-zero exception is preserved).

[Bug jit/104073] New: Add option to hide stderr logging in libgccjit

2022-01-17 Thread bouanto at zoho dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104073

Bug ID: 104073
   Summary: Add option to hide stderr logging in libgccjit
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
One issue I have for my work on adding support for 128-bit integers is that the
way libgccjit works does not allow knowing before compiling whether those
integers are supported on the target platform.

As such, one workaround I have to know if they are supported is to create this
type and compile using the JIT.
If there is an error, I know the type is not supported.

The problem is that this will show the error on stderr, which is problematic in
rustc_codegen_gcc as rust expects no output there in some cases.

Unless you have a better idea for checking if this type is supported, I could
use my workaround if we add an option to hide stderr logging in libgccjit.

I have an upcomming patch for this.

[Bug jit/104072] New: Register variables in libgccjit

2022-01-17 Thread bouanto at zoho dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104072

Bug ID: 104072
   Summary: Register variables in libgccjit
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
I'm opening this issue to track my upcoming patch adding support for register
variables in libgccjit.

[Bug jit/104071] New: Add support for bitcast

2022-01-17 Thread bouanto at zoho dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104071

Bug ID: 104071
   Summary: Add support for bitcast
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
I'm opening this issue to track my upcoming patch to add support for bitcasts
in libgccjit.

[Bug fortran/103692] [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062

2022-01-17 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103692

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #4 from anlauf at gcc dot gnu.org ---
We need to handle zero-sized constructors.

Tentative patch:

diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 472304326e8..f1d92e00c98 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -1883,6 +1883,9 @@ gfc_expand_constructor (gfc_expr *e, bool fatal)
   gfc_expr *f;
   bool rc;

+  if (gfc_is_size_zero_array (e))
+return true;
+
   /* If we can successfully get an array element at the max array size then
  the array is too big to expand, so we just return.  */
   f = gfc_get_array_element (e, flag_max_array_constructor);

[Bug c++/104007] [12 Regression] new (std::nothrow) S[n] always calls ~S since r12-6328-gbeaee0a871b6485d

2022-01-17 Thread jason at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104007

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/103942] [9 Regression] invalid memory reference with allocatable string and class(*)

2022-01-17 Thread anlauf at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103942

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

Summary|[10 Regression] invalid |[9 Regression] invalid
   |memory reference with   |memory reference with
   |allocatable string and  |allocatable string and
   |class(*)|class(*)
  Known to fail||9.4.1

--- Comment #5 from anlauf at gcc dot gnu.org ---
After the backport this should have been marked as 9-regression.  Doing so now.

[Bug c++/104025] [12 Regression] '-fcompare-debug' failure with enabled warnings since r12-6563-gb8ffa71e4271ae56

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 52213
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52213&action=edit
gcc12-pr104025.patch

Untested fix.  I think the old input_location is the right one.

[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

2022-01-17 Thread amonakov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558

--- Comment #10 from Alexander Monakov  ---
As comment #5 mentioned, it is still broken, you just need -fno-inline in
addition to -O2 for the original testcase. Andrew's remark is quite useful for
situations like this, you know :)

[Bug tree-optimization/104069] -Werror=use-after-free false positive on elfutils-0.186

2022-01-17 Thread msebor at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2022-01-17
 Ever confirmed|0   |1

--- Comment #3 from Martin Sebor  ---
The warning triggers at -O0 and above for an IL that looks like this (at -O1):

   [local count: 59126544]:
  # sb_4 = PHI <0B(4), sb_3(5)>
  b_15 = realloc (sb_4, 1);
  if (b_15 != 0B)
goto ; [99.96%]
  else
goto ; [0.04%]

   [local count: 59102893]:

   [local count: 59126544]:
  # sb_5 = PHI 
  return sb_5; <<< -Wuse-after-free 

}

All it does is check to see if the use of sb_5 in the return statement is
dominated by the realloc call without considering the data flow (i.e., that
sb_5 is equal to sb_4 when b_15 is null).

The handling of the dominance is too simplistic.  Let me look into make it more
intelligent.

[Bug libgcc/27576] The .eh_frame section in crtend.o has wrong aligment

2022-01-17 Thread hjl.tools at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27576

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-17

[Bug c++/104025] [12 Regression] '-fcompare-debug' failure with enabled warnings since r12-6563-gb8ffa71e4271ae56

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104025

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Yeah, the reason that -fcompare-debug fails isn't that -g vs. -g0 would emit
different line number, but that -fcompare-debug uses -w for one of the
compilations so that warnings aren't emitted multiple times and so one
compilation is with -Wmissing-template-keyword and one without.

[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]

2022-01-17 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758

--- Comment #16 from Marek Polacek  ---
Yeah, I'm testing a patch which does just that.

[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758

--- Comment #15 from Jakub Jelinek  ---
Just replace startswith (x, y) with strncmp (x, y, strlen (y)) == 0 for 11 and
earlier.

[Bug middle-end/104067] [12 Regression] wrong code compiling QEMU since r12-4790-g4b3a325f07acebf4

2022-01-17 Thread law at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067

--- Comment #5 from Jeffrey A. Law  ---
I briefly looked at the other BZ last week, but didn't make much headway.  The
first thing that stood out was why are we threading around the loop.  I thought
that was disabled.  Anyway, Aldy and/or I will take both of these in the coming
days.

[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]

2022-01-17 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758

--- Comment #14 from Marek Polacek  ---
Oops, that broke the build:

.../c-family/c-format.c:3229:22: error: ‘startswith’ was not declared in this
scope
 3229 |   && startswith (format_chars, "decl-specifier"))

I've reverted the patch.

[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]

2022-01-17 Thread mpolacek at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #13 from Marek Polacek  ---
Now fixed in GCC 11 too.

[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]

2022-01-17 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103758

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

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

commit r11-9472-ga59360efef52468ad4648304f7ba56037f130a9a
Author: Marek Polacek 
Date:   Fri Dec 17 14:34:12 2021 -0500

c-family: Have -Wformat-diag accept "decl-specifier" [PR103758]

I'm tired of seeing

cp/parser.c:15923:55: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]
cp/parser.c:15925:57: warning: misspelled term 'decl' in format; use
'declaration' instead [-Wformat-diag]

every time I compile cp/parser.c, which happens...a lot.  I'd like my
compilation to be free of warnings, otherwise I'm going to miss some
important ones.

"decl-specifiers" is a C++ grammar term; it is not actual code, so
should not be wrapped with %< %>.  I hope we can accept it as an exception
in check_tokens.

It was surrounded by %< %> in cp_parser_decl_specifier_seq, so fix that.

In passing, fix a misspelling in missspellings.

PR c++/103758

gcc/c-family/ChangeLog:

* c-format.c (check_tokens): Accept "decl-specifier*".

gcc/cp/ChangeLog:

* parser.c (cp_parser_decl_specifier_seq): Replace
%
with %qD.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-condition.C: Adjust dg-error.

(cherry picked from commit bb936163e28fdbe1a751c55d5e5975e036322a3d)

[Bug bootstrap/102831] [12 regression] Spurious -Wparentheses etc. warnings

2022-01-17 Thread tschwinge at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102831

Thomas Schwinge  changed:

   What|Removed |Added

 Status|NEW |WAITING
 CC||rguenth at gcc dot gnu.org

--- Comment #9 from Thomas Schwinge  ---
Please check if this happens to be resolved with Richard's recent PR101292
commit r12-6640-g1374d4b963a6ac2e0ec1645c09e5162e68b009d6 "middle-end/101292 -
invalid memory access with warning control".

[Bug middle-end/101292] [12 Regression] recent valgrind error in warning-control.cc since r12-1804-g65870e75616ee4359d1c13b99be794e6a577bc65

2022-01-17 Thread tschwinge at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101292

Thomas Schwinge  changed:

   What|Removed |Added

 CC||tschwinge at gcc dot gnu.org

--- Comment #9 from Thomas Schwinge  ---
(In reply to CVS Commits from comment #7)
> The warning control falls into the C++ trap of using a reference
> to old hashtable contents for a put operation which can end up
> re-allocating that before reading from the old freed referenced to
> source.  Fixed by introducing a temporary.

What the heck...  I'd so much looked into this code and even refactored it in
context of my earlier commit r12-3498-g6c79057fae6bbb36c4a4fd61c5b7107a16b71b17
"Don't maintain a warning spec for 'UNKNOWN_LOCATION'/'BUILTINS_LOCATION'
[PR101574]" -- but I had not noticed that pre-existing problem.  Thanks,
Richard!


In the general case, this is probably too complex to get a reliable diagnostic
for (say, GCC Analyzer)?

[Bug middle-end/104067] [12 Regression] wrong code compiling QEMU since r12-4790-g4b3a325f07acebf4

2022-01-17 Thread amacleod at redhat dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067

--- Comment #4 from Andrew Macleod  ---
(In reply to Martin Liška from comment #2)
> Likely dup of PR103721.

I think so too. It looks eerily familiar.   Aldy will be back this week and
will have a look.

[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |
 CC||pinskia at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
Figures. I might take a look tomorrow.

[Bug rtl-optimization/104059] [12 Regression] cprop_hardreg propgates hard registers for mov instructions between different REG_CLASS without considering cost

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104059

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Just testing for number of vmovd insns on the testcase (2 in r12-1 and 3 in
current trunk) bisects to r12-5358-g32221357007666124409ec3ee0d3a1cf263ebc9e

[Bug c++/80351] Inconsistent warning for constexpr auto constant when using initializer list (-Wunused-variable)

2022-01-17 Thread pokechu022+gccbugzilla at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80351

Pokechu22  changed:

   What|Removed |Added

 CC||pokechu022+gccbugzilla@gmai
   ||l.com

--- Comment #3 from Pokechu22  ---
Still an issue in GCC 11.2.

Here are some additional examples: https://godbolt.org/z/hvEs6bb95
https://godbolt.org/z/674seG3bn https://godbolt.org/z/6esEs1fsr
https://godbolt.org/z/s8eqsnzP9 https://godbolt.org/z/1TjnP6GeG
https://godbolt.org/z/czefeKWsf

The use of an enum class isn't needed; the issue also happens with int.

In GCC 7.1+, marking warn as [[maybe_unused]] removes the warning (it doesn't
get shifted to no_warn); GCC 6.4- give an additional warning that
"'maybe_unused' attribute directive ignored" (it may not have been implemented
then).

Explicitly using std::initializer_list instead of auto resolves the issue.
 In GCC 9.2+, only warn needs to be changed to have an explicit type (no_warn
can remain as auto without a warning being generated), but in GCC 9.1-, the
first use of auto will generate the warning (meaning no_warn will generate a
warning unless it too is changed).

If different types are used, then one warning is generated for each type (e.g.
{1, 2} and {1u, 2u} each generate one warning).

The behavior of only one warning being generated started in GCC 4.8.1+;
multiple warnings were generated in 4.7.4-.

[Bug c++/103991] [12 Regression] Bogus -Wreturn-type with constexpr if and local var with destructor

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103991

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug d/104070] New: libphobos: alias gc.os.MAP_ANON conflicts with alia s gc.os.MAP_ANON on kfreebsd-gnu

2022-01-17 Thread doko at debian dot org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104070

Bug ID: 104070
   Summary: libphobos: alias gc.os.MAP_ANON conflicts with alia s
gc.os.MAP_ANON on kfreebsd-gnu
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with the gcc-11 branch and the trunk:

looking at libphobos/configure.tgt, libphobos is supposed to build on
kfreebsd-gnu. However the build fails with

../../../../src/libphobos/libdruntime/gc/os.d:47:37: error: alias
gc.os.MAP_ANON conflicts with alia
s gc.os.MAP_ANON at ../../../../src/libphobos/libdruntime/gc/os.d:43:30
   47 | version (CRuntime_Glibc) import core.sys.linux.sys.mman : MAP_ANON;
  | ^
../../../../src/libphobos/libdruntime/gc/os.d:47:37: error: module
core.sys.linux.sys.mman import 'M
AP_ANON' not found
   47 | version (CRuntime_Glibc) import core.sys.linux.sys.mman : MAP_ANON;
  | ^
make[6]: *** [Makefile:2338: gc/os.lo] Error 1

[Bug rtl-optimization/104054] [9/10/11/12 Regression] '-fcompare-debug' failure (length) w/ -Os -funroll-loops since r8-3946-gfe94440235cfaa57

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104054

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
The toplevel comment in the pass says:
  DEBUG_INSNs are treated specially, in particular registers occurring inside
  them are treated as requiring ALL_REGS as a class.

[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

2022-01-17 Thread bugdal at aerifal dot cx via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558

--- Comment #9 from Rich Felker  ---
Can you provide a link to the commit that might have fixed it? I imagine it's
simple enough to backport, in which case I'd like to do so.

[Bug middle-end/103163] [12 Regression] stack_limit_rtx is created too early causing nregs field on REG to be zero (gcc.target/nios2/nios2-stack-check-1.c and gcc.target/powerpc/stack-limit.c)

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163

--- Comment #5 from Andrew Pinski  ---
(In reply to Richard Biener from comment #4)
> Not sure how it became a regression in GCC 12, but it sure looks worth
> fixing.

I reported how the ice became a regression in comment #1. It used to not ice
before r12-1702 as the assert was added in that revision.

[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03

2022-01-17 Thread hubicka at kam dot mff.cuni.cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662

--- Comment #9 from hubicka at kam dot mff.cuni.cz ---
> I'm inclined to make this P1 even though it is gfortran only.  As a last 
> resort
> it should work to make the receiver side a ref-all pointer.
Yes, I also think this is important bug (like all TBAA related wrong
codes).  Getting alias set 0 to the receiver is probably doable even
with my Fortran frontend knowledge, but I would like to understand why
the types are not matching which I don't.

[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd

2022-01-17 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031

--- Comment #13 from Sergei Trofimovich  ---
The change also fixed original nix-2.4 test failure. Thank you!

[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

2022-01-17 Thread hubicka at kam dot mff.cuni.cz via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558

--- Comment #8 from hubicka at kam dot mff.cuni.cz ---
> > Do weak aliases fall under some implicit ODR here?
> 
> The whole definition of "weak" is that it entitles you to make a definition
> that will be exempt from ODR, where a non-weak definition, if any, replaces 
> it.

I fixed recently bug in pure-const discovery which made us to add
attributes to weaks while it should not, so perhaps this bug is gone.
For non-inline functions we should handle those as interposable.
Concerning warning, I we make difference between may and must warnings.
I think this is still useful do be diagnosed for user to consider
(perhaps there is a reason why all overwritters has to be weak), so I
think we should porduce may form of warning.

I will take a look.

[Bug tree-optimization/104069] -Werror=use-after-free false positive on elfutils-0.186

2022-01-17 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069

--- Comment #2 from Sergei Trofimovich  ---
Similar code triggers the same warning (and error due to -Werror) on current
linux.git:

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tools/lib/subcmd/subcmd-util.h?id=0c947b893d69231a9add855939da7c66237ab44f#n50

static inline void *xrealloc(void *ptr, size_t size)
{
void *ret = realloc(ptr, size);
if (!ret && !size)
ret = realloc(ptr, 1);
if (!ret) {
ret = realloc(ptr, size);
if (!ret && !size)
ret = realloc(ptr, 1);
if (!ret)
die("Out of memory, realloc failed");
}
return ret;
}

  CC  tools/objtool/help.o
In file included from help.c:12:
In function 'xrealloc',
inlined from 'add_cmdname' at help.c:24:2:
subcmd-util.h:56:23: error: pointer may be used after 'realloc'
[-Werror=use-after-free]
   56 | ret = realloc(ptr, size);
  |   ^~
subcmd-util.h:52:21: note: call to 'realloc' here
   52 | void *ret = realloc(ptr, size);
  | ^~
subcmd-util.h:58:31: error: pointer may be used after 'realloc'
[-Werror=use-after-free]
   58 | ret = realloc(ptr, 1);
  |   ^~~
subcmd-util.h:52:21: note: call to 'realloc' here
   52 | void *ret = realloc(ptr, size);
  | ^~

[Bug tree-optimization/104069] -Werror=use-after-free false positive on elfutils-0.186

2022-01-17 Thread pinskia at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |tree-optimization

--- Comment #1 from Andrew Pinski  ---
The warning defiantly looks wrong. Realloc fails so it's argument is still
valid.

[Bug c/104069] New: -Werror=use-after-free false positive on elfutils-0.186

2022-01-17 Thread slyfox at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104069

Bug ID: 104069
   Summary: -Werror=use-after-free false positive on
elfutils-0.186
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
CC: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Originally observed on elfutils-0.186 (which builds with -Werror by default).

Here is my attempt to extract simplified example:


typedef long unsigned int size_t;

extern void *realloc(void *__ptr, size_t __size)
__attribute__((__nothrow__, __leaf__))
__attribute__((__warn_unused_result__)) __attribute__((__alloc_size__(2)));

void * __libdw_unzstd(size_t todo) {
  void * sb = 0;

  for(;;) {
// ran ony once
if (!sb) {
  char * b = realloc(sb, todo);
  if (!b)
break;

  sb = b;
}

todo -= 1;
if (todo == 0)
  break;
  }

  // shrink buffer: leave only one byte for simplicity
  char * b = realloc(sb, 1);
  if (b) {
  sb = b;
  } else {
  // realloc failed mysteriously, leave 'sb' untouched.
  }

  return sb;
}

$ gcc-12.0.0 -O2 -std=gnu99 -Wall -Werror -c zstd.c.c
zstd.c.c: In function ‘__libdw_unzstd’:
zstd.c.c:35:10: error: pointer ‘sb’ may be used after ‘realloc’
[-Werror=use-after-free]
   35 |   return sb;
  |  ^~
zstd.c.c:28:14: note: call to ‘realloc’ here
   28 |   char * b = realloc(sb, 1);
  |  ^~
cc1: all warnings being treated as errors

I think it's a proper false positive. Original code is not as contrived (but I
think it's still correct):
https://sourceware.org/git/?p=elfutils.git;a=blob;f=libdwfl/gzip.c;h=ba8ecfba6c316b261ee38bb288ab163664ade9e5;hb=983e86fd89e8bf02f2d27ba5dce5bf078af4ceda#l180

$ gcc-12.0.0 -v
Using built-in specs.
COLLECT_GCC=/<>/gcc-12.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<>/gcc-12.0.0/libexec/gcc/x86_64-unknown-linux-gnu/12.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with:
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20220116 (experimental) (GCC)

[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed now.

[Bug c++/104031] [12 regression] Global nested constructors generate invalid code since r12-6329-g4f6bc28fc7dd86bd

2022-01-17 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104031

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

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

commit r12-6643-gaeca44768d54b089243004d1ef00d34dfa9f6530
Author: Jakub Jelinek 
Date:   Mon Jan 17 18:10:34 2022 +0100

c++: Fix cp_genericize_target_expr for TARGET_EXPRs created for global
initialization [PR104031]

The following patch is miscompiled, cp_genericize_target_expr expects
that for the constant part split_nonconstant_init will emit an INIT_EXPR
that will initialize it, but that doesn't happen and instead we get
DECL_INITIAL on the TARGET_EXPR_SLOT that isn't initialized anywhere
in the IL.

The problem is that the TARGET_EXPR has been created while
current_function_decl was NULL, it is inside a global var initializer.
That means the build_local_temp created VAR_DECL has NULL DECL_CONTEXT.
Later on when genericizing the ssdf (current_function_decl is already
non-NULL), the new cp_genericize_target_expr is called and during
split_nonconstant_init it checks is_local_temp, but that due to the NULL
DECL_CONTEXT returns false.  DECL_CONTEXT is set only later on during
gimplification.

The following patch fixes it by setting DECL_CONTEXT also inside of
cp_genericize_target_expr, which fixes the testcase.  But if there are
better spots to do that, please let me know...

2022-01-17  Jakub Jelinek  

PR c++/104031
* cp-gimplify.c (cp_genericize_target_expr): Set DECL_CONTEXT of
TARGET_EXPR_SLOT to current_function_decl if it was NULL.

* g++.dg/cpp1y/pr104031.C: New test.

[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676

--- Comment #22 from Jakub Jelinek  ---
If we consider such an inline asm invalid, we could error on it, ICE is not the
right thing.  But what exactly should we error on?  Alternative containing
multiple register classes for multi-word operands is still something used quite
commonly in real-world, the problem is when the RA assigns it a reg spanning
across those.  Or do most backends restrict multi-word regs to start at a reg
number divisible by the number of words they need?

[Bug target/103676] [10/11/12 Regression] internal compiler error: in extract_constrain_insn, at recog.c:2671

2022-01-17 Thread vmakarov at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103676

--- Comment #21 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #19)
> r10-3981-gf6ff841bc8dd87ce364deb217dc6d1ec5dc31de8 still doesn't ICE,
> r10-3984-g22060d0e575e7754eb1355763d22bbe37c3caa13 already ICEs.
> 
> I guess there is a disagreement between LRA and recog on how exactly they
> treat register constraints.
> "=lh" for TARGET_THUMB means LO_REGS or HI_REGS classes for the output, bet
> LRA sees that LO_REGS or HI_REGS is together GENERAL_REGS and picks a
> GENERAL_REGS
> (reg:DI 7 r7 [orig:119 tmp ] [119]).  But that one has one half in LO_REGS
> and another half in HI_REGS and so extract_constrain_insn ->
> constrain_operands
> doesn't consider it as matching.

Interesting case.  To find required (reload) register class, LRA (as also the
old reload pass) makes some union of register classes in one alternative which
contains all or part of the registers of the classes (in this case it is
general reg class).  The problem can be solved w/o fixing LRA (and reload pass)
by using

 asm volatile(
  "ldrd %Q[r], %R[r], %[p]\n"
  : [r]"=l,h"(tmp)
  : [p]"m,m"(*p64)
  : "memory"
 );

The problem can be solved in LRA by more complex representation of required reg
classes (still reload should have also such fix).  I guess it will complicate
LRA and reload code a lot.

We could also use more clear description of semantics of constraints currently
used by LRA/reload.  In this case we still need to output more meaningful error
for LRA/reload instead of just internal compiler error.

[Bug target/103973] x86: 4-way comparison of floats/doubles with spaceship operator possibly suboptimal

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103973

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

2022-01-17 Thread bugdal at aerifal dot cx via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95558

--- Comment #7 from Rich Felker  ---
> Do weak aliases fall under some implicit ODR here?

The whole definition of "weak" is that it entitles you to make a definition
that will be exempt from ODR, where a non-weak definition, if any, replaces it.

[Bug middle-end/104067] [12 Regression] wrong code compiling QEMU since r12-4790-g4b3a325f07acebf4

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067

Jakub Jelinek  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
extern void abort ();
struct S { int x; } a[10];
struct S *b;

int
main ()
{
  int i, j = 0;
  struct S *q = a;

  for (i = 100; --i > 0; )
{
  struct S *p;
  j++;
  if (j >= 10)
j = 0;
  p = &a[j];

  if (p == q)
abort ();
  __atomic_thread_fence (__ATOMIC_SEQ_CST);
  q = p;
}
  return 0;
}

This goes wrong in threadfull2, strlen1 looks correct to me:
   [local count: 10737416]:

   [local count: 1063004409]:
  # j_17 = PHI 
  # q_18 = PHI 
  # ivtmp_4 = PHI 
  j_8 = j_17 + 1;
  if (j_8 == 10)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 701582906]:
  _1 = (sizetype) j_8;
  _15 = _1 * 4;
  _14 = &a + _15;

   [local count: 1063004409]:
  # j_2 = PHI 
  # prephitmp_16 = PHI <_14(4), &a(3)>
  if (prephitmp_16 == q_18)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  abort ();

   [local count: 1063004409]:
  __atomic_thread_fence (5);
  ivtmp_3 = ivtmp_4 - 1;
  if (ivtmp_3 != 0)
goto ; [99.00%]
  else
goto ; [1.00%]

   [local count: 1052374367]:
  goto ; [100.00%]

   [local count: 10737416]:
  return 0;

but threadfull2 turns that into something that weirdly starts with:
   [local count: 10737416]:
  j_8 = 1;
  if (j_8 == 10)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 701582906]:
  # ivtmp_22 = PHI <99(2), ivtmp_12(7)>
  # j_24 = PHI 
  # q_25 = PHI <&a(2), q_7(7)>
  _1 = (sizetype) j_24;
  _15 = _1 * 4;
  _14 = &a + _15;

   [local count: 705197120]:
  # j_2 = PHI 
  # prephitmp_16 = PHI <_14(3), &a(2)>
  # ivtmp_23 = PHI 
  # q_26 = PHI 
  if (prephitmp_16 == q_26)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  abort ();

and for j == 10 turns it into unconditional abort:
  j_20 = j_21 + 1;
  if (j_20 == 10)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 357807289]:
  # j_5 = PHI <0(7)>
  # prephitmp_9 = PHI <&a(7)>
  goto ; [100.00%]

[Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c

2022-01-17 Thread tschwinge at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102330

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug fortran/104048] ICE with recursively defined derived type

2022-01-17 Thread pault at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104048

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
(In reply to Martin Liška from comment #4)
> Started with r7-4096-gbf9f15ee55f5b291, it was rejected before the revision
> with:

The fix is (This chunk is lifted from a much bigger patch):

diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2e15a7e874c..3f786e91a2f 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -11419,6 +11562,8 @@ trans_class_assignment (stmtblock_t *block, gfc_expr
*lhs, gfc_expr *rhs,
old_vptr = build_int_cst (TREE_TYPE (vptr), 0);

   size = gfc_vptr_size_get (vptr);
+  lse->expr = TREE_CODE (lse->expr) == INDIRECT_REF ?
+ TREE_OPERAND (lse->expr, 0) : lse->expr;
   class_han = GFC_CLASS_TYPE_P (TREE_TYPE (lse->expr))
  ? gfc_class_data_get (lse->expr) : lse->expr;


with it this runs correctly:


MODULE moa_view_types

IMPLICIT NONE

TYPE moa_basic_view
integer, allocatable :: shp(:)
END TYPE moa_basic_view

TYPE :: moa_view_type
TYPE(moa_basic_view) :: left_array
TYPE(moa_basic_view) :: right_array
TYPE(moa_view_type), ALLOCATABLE :: left_view
TYPE(moa_view_type), ALLOCATABLE :: right_view
END TYPE moa_view_type

CONTAINS

FUNCTION catenate_view_view( view1, view2 ) result(new_view)
CLASS(moa_view_type), TARGET, INTENT(IN) :: view1
CLASS(moa_view_type), TARGET, INTENT(IN) :: view2
CLASS(moa_view_type),  ALLOCATABLE:: new_view

ALLOCATE( new_view )

new_view%left_view  = view1 ! Used to cause an ICE
new_view%right_view = view2 !  -ditto-
END FUNCTION catenate_view_view

END MODULE moa_view_types

use moa_view_types
class(moa_view_type), allocatable :: view1, view2, new_view
allocate (view1, view2)
view1%left_array%shp = [1 , 2]
view2%right_array%shp = [3 , 4]
new_view = catenate_view_view( view1, view2 )
select type (new_view)
  type is (moa_view_type)
if (any (new_view%left_view%left_array%shp .ne. [1,2])) stop 1
if (any (new_view%right_view%right_array%shp .ne. [3,4])) stop 2
end select
end


Paul

[Bug middle-end/104067] [12 Regression] wrong code compiling QEMU since r12-4790-g4b3a325f07acebf4

2022-01-17 Thread jakub at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104067

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |12.0

[Bug c++/51405] [9/10/11/12 Regression] Passing method result to constructor treated as function declaration

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51405

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/53932] [9/10/11/12 Regression] C++ reference variable to member of anonymous union in global is error

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53932

Richard Biener  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
with

> ./cc1plus -quiet t.ii -flto
during IPA pass: modref
t.ii:3:24: internal compiler error: in get_partitioning_class, at symtab.c:2095
3 | int main() { return r; }
  |^
0x438 symtab_node::get_partitioning_class()
/home/rguenther/src/gcc3/gcc/symtab.c:2095
0x159f81c lto_output_varpool_node
/home/rguenther/src/gcc3/gcc/lto-cgraph.c:622
0x15a079e output_symtab()
/home/rguenther/src/gcc3/gcc/lto-cgraph.c:989
0x15bd1bd lto_output()
/home/rguenther/src/gcc3/gcc/lto-streamer-out.c:2813
0x16a3a79 write_lto
/home/rguenther/src/gcc3/gcc/passes.c:2761
(gdb) p node->debug()
i/3 (i) @0x766c1100
  Type: variable
  Body removed by symtab_remove_unreachable_nodes
  Visibility: semantic_interposition artificial
  References: 
  Referring: r/1 (addr) 
  Availability: not_available
  Varpool flags:
$2 = void

so we somehow remove the variable because either the DECL_INITIAL walks do not
work or because the C++ FE screws up in setting things up.

[Bug c++/54319] [9/10/11/12 Regression] empty class causes error while non-empty does not

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54319

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug target/55428] [9/10/11/12 Regression] -mms-bitfields hides -mno-align-double option

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55428

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/65211] [9/10/11/12 Regression] Type alignment lost inside templated function

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65211

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c/65673] [9/10/11/12 Regression] Compound literal with initializer for zero-sized array drops other initializers

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65673

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/66892] [9/10/11/12 Regression] [DR355] Fix of core language defect 355 has status c++11 but is not implemented yet

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66892

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.1.0
   Priority|P3  |P2

[Bug preprocessor/67046] [9/10/11/12 Regression] Segmentation fault when a preprocessor directive follows the argument to _Pragma

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67046

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2

[Bug c++/67048] [9/10/11/12 Regression] GCC rejects well-formed program using empty anonymous enum specifier in a variable declaration

2022-01-17 Thread rguenth at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67048

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Priority|P3  |P2
Version|unknown |11.1.0

  1   2   3   >