[Bug libstdc++/104080] [12 Regression] newlib doesn't have endian.h causing build failure with 2800bc08e4ab r12-6646
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
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
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
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
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
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
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
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
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
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)
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
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
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=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
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
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
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
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
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
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
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
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
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=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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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<::recycle>; template class pmv; template using u1= pmv<::recycle>; template class ptr; template using u2= ptr<::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
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 ) access_ref pref, qref; if (!qry.get_ref (p, stmt, , 0) || !qry.get_ref (q, stmt, , 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
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
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<::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<::recycle>; | ^ clang accepts the code snippet
[Bug c++/103758] bogus warning: misspelled term 'decl' in format; use 'declaration' instead [-Wformat-diag]
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
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
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
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
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
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
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(*)
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
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=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
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
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
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
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]
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]
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
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]
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]
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]
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
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
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
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
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
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)
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
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
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
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
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)
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
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
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
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
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
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
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
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
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
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
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
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
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
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 = [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 = + _15;
[local count: 1063004409]:
# j_2 = PHI
# prephitmp_16 = PHI <_14(4), (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 <(2), q_7(7)>
_1 = (sizetype) j_24;
_15 = _1 * 4;
_14 = + _15;
[local count: 705197120]:
# j_2 = PHI
# prephitmp_16 = PHI <_14(3), (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 <(7)>
goto ; [100.00%]
[Bug fortran/102330] [12 Regression] ICE in expand_gimple_stmt_1, at cfgexpand.c:3932 since r12-980-g29a2f51806c
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
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
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
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
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
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
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
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
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
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
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
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
