[Bug tree-optimization/94889] Negate function not getting optimised to bitwise not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94889 --- Comment #5 from Andreas Schwab --- Note that 1<<31 is undefined.
[Bug libstdc++/94869] [10 Regression] Template argument deduction/substitution failure with Howard Hinnant's calendar library
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94869 --- Comment #9 from Jonathan Wakely --- OK thanks for confirming that. N.B. this is why you're supposed to provide preprocessed source. The code you showed to demonstrate the bug did *not* demonstrate it, because you were actually using something different (a modified version of , or some extra code not shown in your example). Opening namespace std to add your own declarations to it (such as using-declarations of ::date::local_time) is forbidden, resulting in undefined behaviour. The result you got here is a good example of why. Instead of trying to add things to namespace std, you should do something like: #include #if __cpp_lib_chrono >= 201803L namespace time = std::chrono; #else #include namespace time = date; #endif // use time::duration, time::local_time etc.
[Bug c++/92894] "declared using local type 'test01()::X', is used but never defined" during concept satisfaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894 --- Comment #5 from Jonathan Wakely --- Drat, I think you're right. So once again, deduced return types cause problems. But this also suggests to me that the design of std::projected is a problem, because anywhere it might get used has to be very careful and avoid using idiomatic C++.
[Bug tree-optimization/94899] Failure to optimize out add before compare with INT_MIN
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94899 rsandifo at gcc dot gnu.org changed: What|Removed |Added Keywords||easyhack Status|RESOLVED|NEW Last reconfirmed||2020-05-01 CC||rsandifo at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #4 from rsandifo at gcc dot gnu.org --- Reopening because... (In reply to Andrew Pinski from comment #2) > This is invalid as 0x8000 is unsigned (C90/C++03) or long (C99/C++11) in > type. > Which means then overflow is not undefined but rather wrapping. It's unsigned int for C99/C++11 too (see the different handling of decimal-literals and other integer-literals in [lex.icon.type]). This means that the result of the addition is also unsigned, For the specific value of 0x8000, the transformation is monotonic, so the optimisation is valid and well-defined.
[Bug libstdc++/92894] "declared using local type 'test01()::X', is used but never defined" during concept satisfaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |10.0 Component|c++ |libstdc++ Status|NEW |ASSIGNED --- Comment #6 from Jonathan Wakely --- Mine then.
[Bug libstdc++/94900] New: filesystem recursive_directory_iterator incorrectly skips entries in case directories can not be read
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94900
Bug ID: 94900
Summary: filesystem recursive_directory_iterator incorrectly
skips entries in case directories can not be read
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: tonvandenheuvel at gmail dot com
Target Milestone: ---
Suppose we have a subdirectory `x` with two other subdirectories `a` and `b`,
both unreadable for the current user:
$ mkdir -p x/a x/b && chmod 000 x/a x/b
Then, the following program will only print one of the two directories:
#include
#include
namespace sfs = std::filesystem;
int main(int argc, char** argv)
{
std::error_code ec;
for (sfs::recursive_directory_iterator it{"x"}; it !=
sfs::recursive_directory_iterator();
it.increment(ec))
{
std::cout << *it << '\n';
}
return 0;
}
On my system, it outputs:
"x/b"
Using a `directory_iterator` instead does print both directories, as expected.
[Bug libstdc++/94900] filesystem recursive_directory_iterator incorrectly skips entries in case directories have no read/execute permissions set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94900 --- Comment #1 from Ton van den Heuvel --- I found that specifying `std::filesystem::directory_options::skip_permission_denied` does list all entries for `recursive_directory_iterator`. I no longer think this is a bug; the directory iterator stops iteration once it tries to access an unreadable directory. Sorry for the noise.
[Bug libstdc++/94900] filesystem recursive_directory_iterator incorrectly skips entries in case directories have no read/execute permissions set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94900 Ton van den Heuvel changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #2 from Ton van den Heuvel --- I found that specifying `std::filesystem::directory_options::skip_permission_denied` does list all entries for `recursive_directory_iterator`. I no longer think this is a bug; the recursive directory iterator stops iteration once it tries to access a directory it does not have permissions for. The regular directory_iterator does not try to go down the unreadable directories, resulting in iteration to continue.
[Bug libstdc++/94901] New: [10 Regression] uses BADNAME _T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94901
Bug ID: 94901
Summary: [10 Regression] uses BADNAME _T
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
GCC 10 adds:
template
constexpr true_type __is_complete_or_unbounded(__type_identity<_T>)
{ return {}; }
But _T is a documented BADNAME and needs to be replaced with _Tp.
This was reported on IRC, I don't have a full reproducer, but it's clearly a
bug.
[Bug libstdc++/94901] [10 Regression] uses BADNAME _T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94901 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |10.0
[Bug libstdc++/94901] [10 Regression] uses BADNAME _T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94901 Jonathan Wakely changed: What|Removed |Added Known to fail||10.0, 11.0 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Known to work||9.3.1 Last reconfirmed||2020-05-01
[Bug libstdc++/94900] filesystem recursive_directory_iterator incorrectly skips entries in case directories have no read/execute permissions set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94900 Andreas Schwab changed: What|Removed |Added Resolution|WONTFIX |INVALID
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #40 from Thomas Koenig --- Yes, that test case works. Thanks a lot for putting in all the effort! Because we need -fsanitize=address to reliably detect this bug, I have proposed https://gcc.gnu.org/pipermail/gcc-patches/2020-May/544975.html which introduces such a gfortran.dg/asan directory where this can be tested.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #41 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:cb2c76c8b156c6d8541ddb3aa894568a2de3b02b commit r9-8557-gcb2c76c8b156c6d8541ddb3aa894568a2de3b02b Author: Thomas Koenig Date: Fri May 1 14:45:56 2020 +0200 Revert patch for PR fortran/93956. 2020-04-27 Thomas Koenig PR fortran/93956 PR fortran/94788 * expr.c (gfc_check_pointer_assign): Revert patch for PR 93956. * interface.c: Likewise.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 --- Comment #17 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:cb2c76c8b156c6d8541ddb3aa894568a2de3b02b commit r9-8557-gcb2c76c8b156c6d8541ddb3aa894568a2de3b02b Author: Thomas Koenig Date: Fri May 1 14:45:56 2020 +0200 Revert patch for PR fortran/93956. 2020-04-27 Thomas Koenig PR fortran/93956 PR fortran/94788 * expr.c (gfc_check_pointer_assign): Revert patch for PR 93956. * interface.c: Likewise.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 --- Comment #18 from CVS Commits --- The releases/gcc-8 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:b92bb10248a8f99cecf71a54c56bd4d8c75a322f commit r8-10228-gb92bb10248a8f99cecf71a54c56bd4d8c75a322f Author: Thomas Koenig Date: Fri May 1 14:45:56 2020 +0200 Revert patch for PR fortran/93956. 2020-04-27 Thomas Koenig PR fortran/93956 PR fortran/94788 * expr.c (gfc_check_pointer_assign): Revert patch for PR 93956. * interface.c: Likewise.
[Bug fortran/94788] [8/9 Regression] Severe regression leading to double free in tcache
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94788 --- Comment #42 from CVS Commits --- The releases/gcc-8 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:b92bb10248a8f99cecf71a54c56bd4d8c75a322f commit r8-10228-gb92bb10248a8f99cecf71a54c56bd4d8c75a322f Author: Thomas Koenig Date: Fri May 1 14:45:56 2020 +0200 Revert patch for PR fortran/93956. 2020-04-27 Thomas Koenig PR fortran/93956 PR fortran/94788 * expr.c (gfc_check_pointer_assign): Revert patch for PR 93956. * interface.c: Likewise.
[Bug libstdc++/94901] [10 Regression] uses BADNAME _T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94901 --- Comment #1 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:070b4df8a06539b661c134d436ea4207099fdcf0 commit r11-9-g070b4df8a06539b661c134d436ea4207099fdcf0 Author: Jonathan Wakely Date: Fri May 1 13:13:39 2020 +0100 libstdc++: Replace reserved identifier _T with _Tp (PR 94901) The libstdc++ manual documents that _T can not be used, because it's a macro in system headers on some targets. PR libstdc++/94901 * include/std/type_traits (__is_complete_or_unbounded): Replace BADNAME _T with _Tp. * testsuite/17_intro/badnames.cc: New test.
[Bug c/94902] New: [10 Regression] internal compiler error: output_operand: invalid use of register 'frame'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94902
Bug ID: 94902
Summary: [10 Regression] internal compiler error:
output_operand: invalid use of register 'frame'
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
void foo ( void ) {
register int x asm ( "19" ) ;
x -- ;
}
$ gcc-10 --version
gcc (GCC) 10.0.1 20200419 (experimental)
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-10 reduced.c
reduced.c: In function ‘foo’:
reduced.c:5:1: error: frame cannot be used in ‘asm’ here
5 | }
| ^
during RTL pass: final
reduced.c:5:1: internal compiler error: output_operand: invalid use of register
'frame'
0xa58bb6 output_operand_lossage(char const*, ...)
../../gcc-10-20200419/gcc/final.c:3609
0xa58ee1 output_operand(rtx_def*, int)
../../gcc-10-20200419/gcc/final.c:4051
0xa59a3d output_asm_insn(char const*, rtx_def**)
../../gcc-10-20200419/gcc/final.c:3963
0xa5d3e7 final_scan_insn_1
../../gcc-10-20200419/gcc/final.c:3106
0xa5d6ab final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc-10-20200419/gcc/final.c:3152
0xa5d7b6 final_1
../../gcc-10-20200419/gcc/final.c:2020
0xa5e374 rest_of_handle_final
../../gcc-10-20200419/gcc/final.c:4658
0xa5e374 execute
../../gcc-10-20200419/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/92894] "declared using local type 'test01()::X', is used but never defined" during concept satisfaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894 --- Comment #7 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:a5f2fb1ff1742685a91dfdf78da871fd4d3292e5 commit r11-10-ga5f2fb1ff1742685a91dfdf78da871fd4d3292e5 Author: Jonathan Wakely Date: Fri May 1 14:27:25 2020 +0100 libstdc++: Replace deduced return type in ranges::iter_move (PR 92894) The deduced return type causes the instantiation of the function body, which can then require the instantiation of std::projected::operator* which is intentionally not defined. This patch uses a helper trait to define the return type, so that the function body doesn't need to be instantiated. That helper trait can then also be used in other places that currently check the return type of ranges::iter_move (iter_rvalue_reference_t and indirectly_readable). 2020-05-01 Jonathan Wakely Patrick Palka PR libstdc++/92894 * include/bits/iterator_concepts.h (ranges::__cust_imove::_IMove): Add trait to determine return type and an alias for it. (ranges::__cust_imove::_IMove::operator()): Use __result instead of deduced return type. (iter_rvalue_reference_t): Use _IMove::__type instead of checking the result of ranges::iter_move. (__detail::__indirectly_readable_impl): Use iter_rvalue_reference_t instead of checking the result of ranges::iter_move. * testsuite/24_iterators/customization_points/92894.cc: New test. * testsuite/24_iterators/indirect_callable/92894.cc: New test.
[Bug c/94903] New: internal compiler error: in assign_temp, at function.c:982
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94903
Bug ID: 94903
Summary: internal compiler error: in assign_temp, at
function.c:982
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: anbu1024.me at gmail dot com
Target Milestone: ---
$ cat reduced.c
extern struct S var ;
void foo ( )
{
asm volatile ( "" : "=r" ( var ) ) ;
}
$ gcc-9 --version
gcc (GCC) 9.3.1 20200425
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-9 reduced.c
during RTL pass: expand
reduced.c: In function ‘foo’:
reduced.c:6:2: internal compiler error: in assign_temp, at function.c:982
6 | asm volatile ( "" : "=r" ( var ) ) ;
| ^~~
0x5b5f1e assign_temp(tree_node*, int, int)
../../gcc-9-20200425/gcc/function.c:982
0x6e81e1 expand_asm_stmt
../../gcc-9-20200425/gcc/cfgexpand.c:3196
0x6ebc95 expand_gimple_stmt_1
../../gcc-9-20200425/gcc/cfgexpand.c:3688
0x6ebc95 expand_gimple_stmt
../../gcc-9-20200425/gcc/cfgexpand.c:3850
0x6f0b9f expand_gimple_basic_block
../../gcc-9-20200425/gcc/cfgexpand.c:5890
0x6f2f2e execute
../../gcc-9-20200425/gcc/cfgexpand.c:6513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug libstdc++/94901] [10 Regression] uses BADNAME _T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94901 --- Comment #2 from CVS Commits --- The master branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:187c854cc6284f546c151d6b6d4574d061e00d71 commit r11-11-g187c854cc6284f546c151d6b6d4574d061e00d71 Author: Jonathan Wakely Date: Fri May 1 14:49:48 2020 +0100 libstdc++: Add more tests for _E10, _E11 etc. (PR 94901) PR libstdc++/94901 * testsuite/17_intro/badnames.cc: Test values between _E9 and _E24 too.
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #35 from Lewis Hyatt --- (In reply to Lewis Hyatt from comment #34) > (In reply to Eric Gallager from comment #33) > > This is a big enough feature that it should probably get an entry in > > gcc-10/changes.html > > I emailed a suggested patch to that effect here: > https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01667.html. I can commit if it > looks OK. Thanks! With GCC 10 release imminent, would anyone be able to confirm it's OK to push this to changes.html please? Thanks so much. https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544343.html
[Bug c++/94890] std::tuple({0}) fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890
Ville Voutilainen changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |ville.voutilainen at
gmail dot com
CC||ville.voutilainen at gmail dot
com
Last reconfirmed||2020-05-01
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
--- Comment #5 from Ville Voutilainen ---
What happens with std::tuple x({0}) is that the _UElements&&... constructor
is not a direct candidate, so we fall back to trying a copy constructor. That's
a match, and then it tries to convert the argument. Since c is constructible
from int, but not convertible from int, the match is the explicit constructor,
and calling that fails because initializing the argument is copy-init.
The fix that we can apply in tuple is to make __is_implicitly_constructible
look at either is_convertible or is_aggregate, and then negate properly
in __is_explicitly_constructible.
In other words, mine. :)
[Bug libstdc++/94901] [10 Regression] uses BADNAME _T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94901 --- Comment #3 from CVS Commits --- The releases/gcc-10 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:bcf1d3883236c30147201cd712e6edbdc4fbc3ab commit r10-8083-gbcf1d3883236c30147201cd712e6edbdc4fbc3ab Author: Jonathan Wakely Date: Fri May 1 14:32:24 2020 +0100 libstdc++: Replace reserved identifier _T with _Tp (PR 94901) The libstdc++ manual documents that _T can not be used, because it's a macro in system headers on some targets. Backport from mainline 2020-05-01 Jonathan Wakely PR libstdc++/94901 * include/std/type_traits (__is_complete_or_unbounded): Replace BADNAME _T with _Tp. * testsuite/17_intro/badnames.cc: New test.
[Bug c++/94890] std::tuple({0}) fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890 --- Comment #6 from Marek Polacek --- Thanks Ville. What I should have said... (In reply to Marek Polacek from comment #4) > My current theory is that it is not a bug. ...in the compiler proper. It'd be nice if the original test compiled.
[Bug libstdc++/94901] [10 Regression] uses BADNAME _T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94901 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 10.1
[Bug c++/94890] std::tuple({0}) fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890 --- Comment #7 from Ville Voutilainen --- ..and as expected, std::optional is broken the same way.
[Bug c++/94890] std::tuple({0}) fails to compile with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94890 --- Comment #8 from Ville Voutilainen --- (In reply to Marek Polacek from comment #6) > Thanks Ville. What I should have said... > > (In reply to Marek Polacek from comment #4) > > My current theory is that it is not a bug. > > ...in the compiler proper. It'd be nice if the original test compiled. No worries. This needs two library fixes and an LWG issue, I'll take care of it.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
Jakub Jelinek changed:
What|Removed |Added
CC||law at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #4 from Jakub Jelinek ---
I think this boils down whether it is valid to have REG_EQUAL note on a REG_INC
insn or not.
The documentation says:
"This note is only valid on an insn that sets only one register"
but REG_INC insns actually set two registers, the result and
increment/decrement some other register.
The combiner has code to count the autoincs before/after transformation and
punts if they disagree, but because of the REG_EQUAL note the:
1498 /* Temporarily replace the set's source with the
1499 contents of the REG_EQUAL note. The insn will
1500 be deleted or recognized by try_combine. */
...
code just replaces the
(insn 7 29 8 2 (set (reg:TI 95 [ D.3590 ])
(mem/u/c:TI (post_inc:DI (reg/f:DI 106)) [0 S16 A128]))
"pr94873.c":11:48 58 {*movti_aarch64}
(expr_list:REG_INC (reg/f:DI 106)
(expr_list:REG_EQUAL (const_wide_int 0x0f4409395252b9560)
(nil
insn so that it is
(insn 7 29 8 2 (set (reg:TI 95 [ D.3590 ])
(const_wide_int 0x0f4409395252b9560)) "pr94873.c":11:48 58
{*movti_aarch64}
(expr_list:REG_INC (reg/f:DI 106)
(expr_list:REG_EQUAL (const_wide_int 0x0f4409395252b9560)
(nil
and when counting auto_inc on that, we don't find anything, so happily drop the
auto-inc side-effect.
So, if REG_EQUAL is invalid on REG_INC insns, the auto-inc pass should throw
away those notes from insns which it optimizes, if it is not invalid, combiner
needs to ignore REG_EQUAL notes on REG_INC insns or something similar (or count
the auto-inc effects on the original vs. replacement and if they disagree,
punt).
[Bug tree-optimization/92177] [10 regression] gcc.dg/vect/bb-slp-22.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177 Rainer Orth changed: What|Removed |Added Attachment #47085|0 |1 is obsolete|| --- Comment #4 from Rainer Orth --- Created attachment 48429 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48429&action=edit 32-bit sparc-sun-solaris2.11 bb-slp-22.c.171.slp2 I just noticed that the test still FAILs, both 32 and 64-bit, and apparently never stopped.
[Bug tree-optimization/92177] [10 regression] gcc.dg/vect/bb-slp-22.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92177 Rainer Orth changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Rainer Orth --- Not yet fixed.
[Bug testsuite/94853] [10/11 regression] excess errors in gfortran.dg/analyzer/pr93993.f90 since r10-8012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94853 Rainer Orth changed: What|Removed |Added CC||ro at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Build|powerpc64*-linux-gnu| Last reconfirmed||2020-05-01 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu, ||i686-pc-linux-gnu, ||x86_64-pc-linux-gnu, ||*-*-solaris2.11 Host|powerpc64*-linux-gnu| --- Comment #2 from Rainer Orth --- I'm seeing it on all of Solaris (SPARC and x86) and Linux/x86_64. May be universal.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 Jeffrey A. Law changed: What|Removed |Added CC||law at redhat dot com --- Comment #5 from Jeffrey A. Law --- I can't see how a REG_EQUAL note on an insn with multiple outputs can possibly work -- we wouldn't know what output the REG_EQUAL note refers to. And we have to consider an embedded side effect as having an output. Or to think of it another way, any embedded side effect can be implemented with a parallel at which point it's painfully obvious the insn has multiple outputs and a REG_EQUAL note would be inappropriate.
[Bug fortran/83118] [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #32 from Rainer Orth --- *** Bug 94388 has been marked as a duplicate of this bug. ***
[Bug fortran/94388] FAIL: gfortran.dg/unlimited_polymorphic_30.f03 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94388 Rainer Orth changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ro at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #1 from Rainer Orth --- Happens on several different targets, cf. PR fortran/83118. *** This bug has been marked as a duplicate of bug 83118 ***
[Bug fortran/83118] [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83118 --- Comment #33 from Rainer Orth --- What's going to happen with the fix? It works for me on sparc-sun-solaris2.11 and obviously several other targets. This has been open for months now with a known fix, and it seems we're going to release GCC 10.1 with this bug.
[Bug c++/94904] New: [DR 1696] Temporary lifetime and non-static data member initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94904
Bug ID: 94904
Summary: [DR 1696] Temporary lifetime and non-static data
member initializers
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1696 should reject
the following three examples in all modes.
[dcl.init.aggr] If a reference member is initialized from its
brace-or-equal-initializer and a potentially-evaluated subexpression thereof is
an aggregate initialization that would use that brace-or-equal-initializer, the
program is ill-formed.
struct A;
extern A a;
struct A {
const A& a1 { A{a,a} }; // OK
const A& a2 { A{} }; // error
};
A a{a,a}; // OK
[class.base.init] A temporary expression bound to a reference member in a
mem-initializer is ill-formed.
struct A {
A() : v(42) { } // error
const int& v;
};
[class.base.init] A temporary expression bound to a reference member from a
brace-or-equal-initializer is ill-formed.
struct A {
A() = default; // OK
A(int v) : v(v) { } // OK
const int& v = 42; // OK
};
A a1; // error: ill-formed binding of temporary to
reference
A a2(1); // OK, unfortunately
It might be possible also fix PR 63181 at the same time.
[Bug libstdc++/92894] "declared using local type 'test01()::X', is used but never defined" during concept satisfaction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92894 --- Comment #8 from Jonathan Wakely --- Fixed on master (GCC 11) so far. Clang's error is a bit more explicit about the problem: error: function 'std::projected::operator*' is used but not defined in this translation unit, and cannot be defined in any other translation unit because its type does not have linkage For a type with external linkage the ranges::iter_move::operator() function still gets instantiated, but the compiler doesn't reject it immediately because it's possible that projected::operator* is defined in another translation unit. Since the function isn't actually called (just instantiated to find its return type) there's no reference to it in the final object, and so it doesn't matter that projected::operator* isn't defined anywhere. The program is still ill-formed, but no diagnostic is required and it "works". For a type with internal linkage (like a local class) the compiler stops immediately, diagnosing the ill-formed call to projected::operator*. So without this fix it's not possible to use most std::ranges:: algos with local classes.
[Bug c++/94904] [DR 1696] Temporary lifetime and non-static data member initializers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94904 Marek Polacek changed: What|Removed |Added Last reconfirmed||2020-05-01 Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/94905] New: Bogus warning -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905
Bug ID: 94905
Summary: Bogus warning -Werror=maybe-uninitialized
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: bug-apl at gnu dot org
Target Milestone: ---
Hi,
as of g++ 9.3.0 when building GNU APL, g++ emits bogus warnings of type
-Werror=maybe-uninitialized.
Apparently the compiler issues these warnings simply because it is lacking
enough context to really figure out what is happening (e.g. if the supposedly
missing initialization is happening in a different function).
An example is:
https://svn.savannah.gnu.org/viewvc/apl/trunk/src/Shape.hh?view=markup
Shape.hh:133:18: error: ‘shape_Z.Shape::rho[axis]’ may be used
uninitialized in this function [-Werror=maybe-uninitialized]
if (rho[r]) { volume /= rho[r]; rho[r] = sh; volume *=
rho[r]; }
~^
The line 133 is preceded by an assertion that verifies that rho[r] is
initialized. Apparently the compiler assumes that the initialization
of rho[r] on the right of = happens after the test of rho[r] on the left
of =. It completely ignores, however, the fact that rho[r] was simply
updated and was initialized already before the function (set_shape_item)
was called.
May I kindly request to move this kind of warnings away from -Wall to
-Wextra ?
According to "man g++":
-Wall
This enables all the warnings about constructions that some users
consider questionable, and that are easy to avoid (or modify to
prevent the warning), even in conjunction with macros. This also
In the example above there is no "easy to avoid" way to fix the warning.
Kind regards,
Jürgen Sauermann
Maintainer of GNU APL
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Target|sparc-sun-solaris2.11 |sparc-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2020-05-01 --- Comment #1 from Eric Botcazou --- I have them both on Linux and Solaris.
[Bug c++/94896] [10/11 regression] ICE: canonical types differ for identical types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94896 Eric Botcazou changed: What|Removed |Added CC||polacek at redhat dot com --- Comment #2 from Eric Botcazou --- This comes from: 2020-04-30 Marek Polacek PR c++/94775 * tree.c (check_base_type): Return true only if TYPE_USER_ALIGN match. (check_aligned_type): Check if TYPE_USER_ALIGN match. which is a rather risky change so close to a release if you ask me.
[Bug c++/91133] [8/9/10/11 Regression] Wrong "partial specialization is not more specialized than" error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91133
--- Comment #4 from Jason Merrill ---
This is really a question of partial ordering; determining whether the partial
specialization is more specialized than the primary class template is
equivalent to this testcase:
template struct Id { typedef T type; };
template struct A {};
templatevoid f(A); // #1
template::type X> void f(A); // #2
int main()
{
f(A()); // is #2 more specialized?
}
This was rejected as ambiguous by GCC going back at least to 4.1. It is also
rejected by EDG/icc. It is accepted by clang and msvc, like the original
testcase.
The issue is with the partial ordering deduction of #1 from #2: we deduce int
for U from the second argument, and Id::type for U from the third argument,
and those don't agree, so deduction for the third argument fails in both
directions, and the functions are ambiguous.
This is related to open core issues 455 and 1337.
I don't know what rationale clang/msvc are using to conclude that #2 is more
specialized.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 rsandifo at gcc dot gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #6 from rsandifo at gcc dot gnu.org --- (In reply to Jeffrey A. Law from comment #5) > I can't see how a REG_EQUAL note on an insn with multiple outputs can > possibly work -- we wouldn't know what output the REG_EQUAL note refers to. > And we have to consider an embedded side effect as having an output. > > Or to think of it another way, any embedded side effect can be implemented > with a parallel at which point it's painfully obvious the insn has multiple > outputs and a REG_EQUAL note would be inappropriate. Yeah, I can see that argument, but to play devil's advocate: I think the requirement for having a single REG SET_DEST makes sense because the REG_EQUAL note would be genuinely ambiguous if there were multiple REG SET_DESTs. But in the case of a REG_INC insn with a single REG SET_DEST, there's no ambiguity about which register is meant. I guess there's also the problem that stack pushes don't need a REG_INC note, so anything we do can't just be keyed off REG_INC. The only sure way to check whether a register is set as a side-effect is to look at the complete pattern (like dse.c:check_for_inc_dec). So I think there's the argument that optimisers have to be wary of this in the same way that they need to be wary of folding: (set (reg X) (and (mem (pre_inc (reg Y))) (reg Z))) into (set (reg X) (const_int 0)) when Z can be proven to be zero.
[Bug libstdc++/94906] New: memory corruption in std::pmr::memory_buffer_resource
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94906
Bug ID: 94906
Summary: memory corruption in std::pmr::memory_buffer_resource
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: arnaud02 at users dot sourceforge.net
Target Milestone: ---
>cat pmr1.cpp
#include
#include
#include
int main() {
const std::size_t max_size = 75'000'000;
std::pmr::monotonic_buffer_resource res;
std::pmr::unordered_map> counter{&res};
for (size_t i = 0; i < max_size; ++i) counter[i];
}
>g++ -Wall -std=c++17 -O2 -g pmr1.cpp && ./a.out
*** Error in `./a.out': free(): invalid pointer: 0x2b06379d000f ***
=== Backtrace: =
/lib64/libc.so.6(+0x81299)[0x2b03c8a6f299]
opt/gcc/gcc-930-rh7/lib64/libstdc++.so.6(_ZNSt3pmr25monotonic_buffer_resource18_M_release_buffersEv+0x48)[0x2b03c825fe78]
opt/gcc/gcc-930-rh7/lib64/libstdc++.so.6(_ZNSt3pmr25monotonic_buffer_resourceD2Ev+0x1e)[0x2b03c825febe]
./a.out[0x400d51]
/lib64/libc.so.6(__libc_start_main+0xf5)[0x2b03c8a10555]
./a.out[0x400eb4]
In monotonic_buffer_resource::_Chunk::release, "__size" is not calculated
properly when _Chunk::_M_size is 32 or more. Here is a candidate patch:
--- gcc-9.3.0/libstdc++-v3/src/c++17/memory_resource.cc 2020-03-12
11:07:24.0 +
+++ gcc-9.3.0/libstdc++-v3/src/c++17/memory_resource.cc.new 2020-05-01
18:31:24.367672036 +0100
@@ -228,7 +228,7 @@
if (__ch->_M_canary != (__ch->_M_size | __ch->_M_align))
return; // buffer overflow detected!
- size_t __size = (1u << __ch->_M_size);
+ size_t __size = (1lu << __ch->_M_size);
size_t __align = (1u << __ch->_M_align);
void* __start = (char*)(__ch + 1) - __size;
__r->deallocate(__start, __size, __align);
[Bug c/89161] Bogus -Wformat-overflow warning with value range known
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89161 Martin Sebor changed: What|Removed |Added Known to fail|9.0 |10.0, 9.2.0 Last reconfirmed|2019-02-02 00:00:00 |2020-5-1 --- Comment #2 from Martin Sebor --- Reconfirming with GCC 10 with slightly different output: pr89161.c:7: sprintf: objsize = 3, fmtstr = ".%1u" Directive 1 at offset 0: ".", length = 1 Result: 1, 1, 1, 1 (1, 1, 1, 1) Directive 2 at offset 1: "%1u" pr89161.c: In function ‘main’: pr89161.c:7:24: warning: ‘%1u’ directive writing between 1 and 6 bytes into a region of size 2 [-Wformat-overflow=] 7 | sprintf(buf, ".%1u", (10 * a[0]) / a[1]); |^~~ pr89161.c:7:22: note: directive argument in the range [0, 327675] 7 | sprintf(buf, ".%1u", (10 * a[0]) / a[1]); | ^~ Result: 1, 6, 6, 6 (2, 7, 7, 7) Directive 3 at offset 4: "", length = 1 pr89161.c:7:9: note: ‘sprintf’ output between 3 and 8 bytes into a destination of size 3 7 | sprintf(buf, ".%1u", (10 * a[0]) / a[1]); | ^~~~
[Bug c++/93822] [8/9/10/11 Regression] ICE in make_ssa_name_fn, at tree-ssanames.c:279 since r7-536-g381cdae49785fc4b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93822 --- Comment #3 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:bcbf334afe091ad7d0f5ffe164299f8730cf41d1 commit r11-15-gbcbf334afe091ad7d0f5ffe164299f8730cf41d1 Author: Jason Merrill Date: Fri May 1 13:53:32 2020 -0400 c++: generic lambda and -fsanitize=vla-bound [PR93822] Within the generic lambda the VLA capture proxy VAR_DECL has DECL_VALUE_EXPR which is a NOP_EXPR to the VLA type of the proxy. The problem here was that when instantiating we were tsubsting that type twice, once for the type of the DECL and once for the type of the NOP_EXPR, and getting two different (though equivalent) types. Then gimplify_type_sizes fixed up the type of the DECL, but that didn't affect the type of the NOP_EXPR, leading to sadness. Fixed by directly reusing the type from the DECL. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/93822 * pt.c (tsubst_decl): Make sure DECL_VALUE_EXPR continues to have the same type as the variable.
[Bug target/90479] gcc-arm-none-eabi-8-2018-q4-major [c99 plus -pg not working]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90479 --- Comment #2 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:82d5decef38b5562d97c49a70ca2636a08769dbc commit r11-17-g82d5decef38b5562d97c49a70ca2636a08769dbc Author: Jason Merrill Date: Fri May 1 13:53:32 2020 -0400 c++: Local class DMI using local static [PR90479] For default member initializers in templates it's important to push into the right context during get_nsdmi. But for a local class that's not possible, and trying leaves the function context we need to be in, so don't try. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/90479 * init.c (get_nsdmi): Don't push_to_top_level for a local class.
[Bug c/90036] [8/9/10/11 Regression] false positive: directive argument is null [-Werror=format-overflow=]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90036 --- Comment #10 from Martin Sebor --- The warning for the test in comment #3 has disappeared in GCC 10 (it's still there in GCC 9). There are no printf calls with null arguments in the strlen dump. GCC 10 still issues a warning for the test in comment #8. The predicate analysis might be something to look into for GCC 11.
[Bug c++/91529] [8/9/10/11 Regression] -fmerge-all-constants leads to corrupt output without inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91529 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:a2f32550a085984fbaaec962bf7723514ac71dff commit r11-16-ga2f32550a085984fbaaec962bf7723514ac71dff Author: Jason Merrill Date: Fri May 1 13:53:32 2020 -0400 c++: -fmerge-all-constants vs. destructors [PR91529] cp_finish_decl avoids setting TREE_READONLY on TREE_STATIC variables that have non-constant construction or destruction, but -fmerge-all-constants was converting an automatic variable to static while leaving TREE_READONLY set. Fixed by clearing the flag in cp_finish_decl in the presence of -fmerge-all-constants. gcc/cp/ChangeLog 2020-05-01 Jason Merrill PR c++/91529 * decl.c (cp_finish_decl): Also clear TREE_READONLY if -fmerge-all-constants.
[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 Bug 85741 depends on bug 87719, which changed state. Bug 87719 Summary: missing warning on printf %s and unterminated array https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87719 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/87719] missing warning on printf %s and unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87719
Martin Sebor changed:
What|Removed |Added
Known to fail|9.0 |8.3.0
Known to work||10.0, 9.2.0
Resolution|--- |FIXED
Status|UNCONFIRMED |RESOLVED
Target Milestone|--- |9.3
Assignee|unassigned at gcc dot gnu.org |msebor at gcc dot
gnu.org
--- Comment #1 from Martin Sebor ---
GCC 9 and 10 issue the expected warning, likely as a result of r264822:
pr87719.c: In function ‘f’:
pr87719.c:5:26: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-overflow=]
5 | __builtin_sprintf (d, "%s", a); // warning, good
| ^~ ~
pr87719.c:1:12: note: referenced argument declared here
1 | const char a[] = { 'a', 'b' };
|^
pr87719.c: In function ‘g’:
pr87719.c:10:22: warning: ‘%s’ directive argument is not a nul-terminated
string [-Wformat-overflow=]
10 | __builtin_printf ("%s", a); // missing warning
| ^~ ~
pr87719.c:1:12: note: referenced argument declared here
1 | const char a[] = { 'a', 'b' };
|^
[Bug tree-optimization/87034] [9/10/11 Regression] missing -Wformat-overflow on a sprintf %s with a wide string
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87034 Martin Sebor changed: What|Removed |Added Last reconfirmed|2018-08-22 00:00:00 |2020-5-1 Known to fail||10.0, 11.0, 9.2.0 --- Comment #10 from Martin Sebor --- Reconfirming with GCC 10.1.
[Bug c++/94907] New: ICE: Segmentation fault (in check_return_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907
Bug ID: 94907
Summary: ICE: Segmentation fault (in check_return_expr)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: asolokha at gmx dot com
Target Milestone: ---
gcc-10.1.0-RC20200430 ICEs when compiling the following testcase, extracted
from test/CXX/class/class.compare/class.compare.default/p4.cpp from the clang
10.0.0 test suite, w/ -std=c++2a:
namespace std {
struct strong_ordering {
};
}
struct E;
struct D {
virtual std::strong_ordering operator<=>(const struct E&) const = 0;
};
struct E : D {
std::strong_ordering operator<=>(const E&) const override = default;
};
% g++-10.1.0 -std=c++2a -c wwmk0dwc.cpp
wwmk0dwc.cpp: In member function 'virtual constexpr std::strong_ordering
E::operator<=>(const E&) const':
wwmk0dwc.cpp:12:24: internal compiler error: Segmentation fault
12 | std::strong_ordering operator<=>(const E&) const override = default;
|^~~~
0xfed34f crash_signal
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/toplev.c:328
0xa8008a check_return_expr(tree_node*, bool*)
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/typeck.c:9924
0xa32b5f finish_return_stmt(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/semantics.c:956
0x964803 build_comparison_op
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/method.c:1445
0x9652d9 synthesize_method(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/method.c:1550
0x892e02 check_bases_and_members
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/class.c:6002
0x89725b finish_struct_1(tree_node*)
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/class.c:7216
0x898ca4 finish_struct(tree_node*, tree_node*)
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/class.c:7520
0x99abb3 cp_parser_class_specifier_1
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/parser.c:23881
0x99cc5b cp_parser_class_specifier
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/parser.c:24180
0x99cc5b cp_parser_type_specifier
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/parser.c:17711
0x99dd65 cp_parser_decl_specifier_seq
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/parser.c:14359
0x99e804 cp_parser_simple_declaration
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/parser.c:13613
0x9c8ff2 cp_parser_declaration
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/parser.c:13433
0x9c978f cp_parser_translation_unit
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/parser.c:4734
0x9c978f c_parse_file()
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/cp/parser.c:43975
0xae268b c_common_parse_file()
/var/tmp/portage/sys-devel/gcc-10.1.0_rc20200430/work/gcc-10.1.0-RC-20200430/gcc/c-family/c-opts.c:1190
[Bug libstdc++/94906] memory corruption in std::pmr::memory_buffer_resource
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94906 Jonathan Wakely changed: What|Removed |Added Last reconfirmed||2020-05-01 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Keywords||wrong-code Ever confirmed|0 |1
[Bug c++/94907] ICE: Segmentation fault (in check_return_expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-05-01 CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek --- We ICE here 9926 /* Remember that this function did return a value. */ 9927 current_function_returns_value = 1; because cfun is null.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #7 from Segher Boessenkool --- REG_EQ* is documented as only being allowed on insns that set only one register. If you want to change that, you'll have to check *all* code that consumes this, see if they rely on that fact or not, and if so, change that.
[Bug libstdc++/94906] memory corruption in std::pmr::memory_buffer_resource
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94906 --- Comment #1 from Andrew Pinski --- Better would be: size_t __size = (((size_t)1) << __ch->_M_size); As long could be 32bits (windows)
[Bug c/67224] UTF-8 support for identifier names in GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 --- Comment #36 from Manuel López-Ibáñez --- If the patch is in, it should be ok. Or ask in gcc-patches for someone to commit on your behalf. Gerald is very helpful. Just make sure the subject of the email is very clear. On Fri, 1 May 2020, 16:12 lhyatt at gmail dot com, wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67224 > > --- Comment #35 from Lewis Hyatt --- > (In reply to Lewis Hyatt from comment #34) > > (In reply to Eric Gallager from comment #33) > > > This is a big enough feature that it should probably get an entry in > > > gcc-10/changes.html > > > > I emailed a suggested patch to that effect here: > > https://gcc.gnu.org/ml/gcc-patches/2020-01/msg01667.html. I can commit > if it > > looks OK. Thanks! > > With GCC 10 release imminent, would anyone be able to confirm it's OK to > push > this to changes.html please? Thanks so much. > https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544343.html > > -- > You are receiving this mail because: > You are on the CC list for the bug.
[Bug rtl-optimization/94873] [8/9/10/11 Regression] wrong code with -O -fno-merge-constants -fno-split-wide-types -fno-tree-fre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873 --- Comment #8 from rsandifo at gcc dot gnu.org --- (In reply to Segher Boessenkool from comment #7) > REG_EQ* is documented as only being allowed on insns that set only one > register. If you want to change that, you'll have to check *all* code > that consumes this, see if they rely on that fact or not, and if so, > change that. But the point is that the word "set" is ambiguous. Does it mean set by a SET or set by any means? I think it can be read both ways. After all, a CLOBBER is a form of set too, but that's clearly meant to be excluded. Either way will need auditing. If we say that this kind of REG_EQUAL is wrong, we'd in theory need to audit everything that adds REG_EQUAL notes to make sure it has an appropriate check, or doesn't need one. I'm also not sure if we really are concerned about multiple registers in this particular case, or whether it's more the case that we don't want REG_EQUAL notes on insns with side effects.
[Bug tree-optimization/92893] [10 Regression] Unhelpful -Wstringop-overflow warning for a trailing one-element array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92893
--- Comment #9 from Stephan Bergmann ---
(In reply to Martin Sebor from comment #2)
> Defining Str like so works for the test case:
>
> struct Str {
> template Str(Cat c)
> {
> struct Flex { char c, a[]; } *p = (Flex*)get();
> c.add(p->a);
> }
> };
So I had created "Silence bogus
-Wstringop-overflow with GCC trunk towards GCC 10" back in last December, and
it sufficed to suppress all those warnings when compiling LibreOffice with
then-trunk GCC, with optimizations enabled. However, meanwhile GCC has changed
again so that at least one place in the LibreOffice code now produces two
-Werror=stringop-overflow= in one such
struct Hack { char c; char a[]; };
workaround. (While in general the workarounds appear to still be effective in
suppressing other such warnings.) Bisecting, I found that first
> commit ef29b12cfbb4979a89b3cbadbf485a77c8fd8fce
> Author: Martin Sebor
> Date: Sat Dec 14 00:52:46 2019 +
>
> PR middle-end/91582 - missing heap overflow detection for strcpy
caused a new "writing 1 byte into a region of size 0" at
> In file included from /home/user/libreoffice/include/rtl/string.hxx:41,
> from /home/user/libreoffice/include/rtl/ustring.hxx:37,
> from
> /home/user/libreoffice/include/unotest/filters-test.hxx:14,
> from
> /home/user/libreoffice/unotest/source/cpp/filters-test.cxx:14:
> In member function ‘char* rtl::OStringConcat::addData(char*) const
> [with T1 = rtl::OStringLiteral; T2 = const char [2]]’,
> inlined from ‘char* rtl::OStringConcat::addData(char*) const
> [with T1 = rtl::OStringConcat; T2 =
> rtl::OString]’ at /home/user/libreoffice/include/rtl/stringconcat.hxx:256:114,
> inlined from ‘rtl::OString::OString(rtl::OStringConcat&&) [with
> T1 = rtl::OStringConcat; T2 =
> rtl::OString]’ at /home/user/libreoffice/include/rtl/string.hxx:281:34,
> inlined from ‘void test::FiltersTest::recursiveScan(test::filterStatus,
> const rtl::OUString&, const rtl::OUString&, const rtl::OUString&,
> SfxFilterFlags, SotClipboardFormatId, unsigned int, bool)’ at
> /home/user/libreoffice/unotest/source/cpp/filters-test.cxx:111:67:
> /home/user/libreoffice/include/rtl/stringconcat.hxx:77:11: error: writing 1
> byte into a region of size 0 [-Werror=stringop-overflow=]
>77 | memcpy( buffer, data, length );
> | ~~^~~~
> In file included from /home/user/libreoffice/include/rtl/ustring.hxx:37,
> from
> /home/user/libreoffice/include/unotest/filters-test.hxx:14,
> from
> /home/user/libreoffice/unotest/source/cpp/filters-test.cxx:14:
> /home/user/libreoffice/include/rtl/string.hxx: In member function ‘void
> test::FiltersTest::recursiveScan(test::filterStatus, const rtl::OUString&,
> const rtl::OUString&, const rtl::OUString&, SfxFilterFlags,
> SotClipboardFormatId, unsigned int, bool)’:
> /home/user/libreoffice/include/rtl/string.hxx:280:32: note: at offset 0 to
> object ‘rtl::OString::OString(rtl::OStringConcat&&) [with T1 =
> rtl::OStringConcat; T2 =
> rtl::OString]::Hack::c’ with size 1 declared here
> 280 | struct Hack { char c; char a[]; };
> |^
and later
> commit a9a437ffc4269650e34af92c4fb095b7ed98f94a
> Author: Jakub Jelinek
> Date: Tue Mar 17 13:36:41 2020 +0100
>
> tree-ssa-strlen: Fix up count_nonzero_bytes* [PR94015]
started to even cause an additional "writing 4 bytes into a region of size 1"
> In file included from /home/user/libreoffice/include/rtl/string.hxx:41,
> from /home/user/libreoffice/include/rtl/ustring.hxx:37,
> from
> /home/user/libreoffice/include/unotest/filters-test.hxx:14,
> from
> /home/user/libreoffice/unotest/source/cpp/filters-test.cxx:14:
> In function ‘char* rtl::addDataHelper(char*, const char*, std::size_t)’,
> inlined from ‘static char*
> rtl::ToStringHelper::addData(char*, const
> rtl::OStringLiteral&)’ at
> /home/user/libreoffice/include/rtl/string.hxx:1907:91,
> inlined from ‘char* rtl::OStringConcat::addData(char*) const
> [with T1 = rtl::OStringLiteral; T2 = const char [2]]’ at
> /home/user/libreoffice/include/rtl/stringconcat.hxx:222:103,
> inlined from ‘char* rtl::OStringConcat::addData(char*) const
> [with T1 = rtl::OStringConcat; T2 =
> rtl::OString]’ at /home/user/libreoffice/include/rtl/stringconcat.hxx:256:114,
> inlined from ‘rtl::OString::OString(rtl::OStringConcat&&) [with
> T1 = rtl::OStringConcat; T2 =
> rtl::OString]’ at /home/user/libreoffice/include/rtl/string.hxx:281:34,
> inlined from ‘void test::FiltersTest::recursiveScan(test::filterStatus,
> const rtl::OUString&, const rtl::OUString&, const rtl::OUString&,
> SfxFilterFlags, SotClipboardFormatId, unsigned int, bool)’ at
> /home/user/libreoffice/unotest/source/cpp/fi
[Bug middle-end/86851] missing -Wformat-overflow on %s with a constant string plus variable offset
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86851 Martin Sebor changed: What|Removed |Added Component|tree-optimization |middle-end Known to fail||10.0, 8.3.0, 9.2.0 Last reconfirmed||2020-05-01 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Martin Sebor --- No progress in GCC 10.
[Bug tree-optimization/85175] [8/9/10/11 regression] false-positive -Wformat-overflow= warning with gcc-8 -Os
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85175 Martin Sebor changed: What|Removed |Added Last reconfirmed|2018-04-03 00:00:00 |2020-5-1 Known to fail||10.0, 8.3.0, 9.2.0 --- Comment #12 from Martin Sebor --- Reconfirming with GCC 10.
[Bug tree-optimization/83733] -Wformat-overflow false positive for %d on bounded integer when inlining
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83733 Martin Sebor changed: What|Removed |Added Last reconfirmed|2018-01-08 00:00:00 |2020-5-1 Known to fail|9.1.0 |9.2.0 --- Comment #5 from Martin Sebor --- Reconfirming with GCC 10.
[Bug tree-optimization/94908] New: Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908
Bug ID: 94908
Summary: Failure to optimally optimize certain shuffle patterns
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
typedef float v4sf __attribute__((vector_size(16)));
v4sf g();
v4sf f(v4sf a, v4sf b)
{
return (v4sf){g()[1], a[1], a[2], a[3]};
}
With -O3, LLVM outputs this :
f(float __vector(4), float __vector(4)): # @f(float __vector(4), float
__vector(4))
sub rsp, 24
movaps xmmword ptr [rsp], xmm0 # 16-byte Spill
call g()
movaps xmm1, xmmword ptr [rsp] # 16-byte Reload
shufps xmm0, xmm1, 17 # xmm0 = xmm0[1,0],xmm1[1,0]
shufps xmm0, xmm1, 232 # xmm0 = xmm0[0,2],xmm1[2,3]
add rsp, 24
ret
GCC outputs this :
f(float __vector(4), float __vector(4)):
sub rsp, 24
movaps XMMWORD PTR [rsp], xmm0
call g()
movaps xmm1, XMMWORD PTR [rsp]
add rsp, 24
shufps xmm0, xmm0, 85
movaps xmm2, xmm1
shufps xmm2, xmm1, 85
movaps xmm3, xmm2
movaps xmm2, xmm1
unpckhps xmm2, xmm1
unpcklps xmm0, xmm3
shufps xmm1, xmm1, 255
unpcklps xmm2, xmm1
movlhps xmm0, xmm2
ret
This also seems to occurs on powerpc64le, so I haven't marked it as
target-specific.
[Bug tree-optimization/85741] [meta-bug] bogus/missing -Wformat-overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85741 Bug 85741 depends on bug 83278, which changed state. Bug 83278 Summary: missing -Wformat-overflow for an inlined __builtin___sprintf_chk with a local buffer https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83278 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/83278] missing -Wformat-overflow for an inlined __builtin___sprintf_chk with a local buffer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83278
Martin Sebor changed:
What|Removed |Added
Known to fail||8.3.0, 9.2.0
Known to work||10.0
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
Last reconfirmed||2020-5-1
--- Comment #2 from Martin Sebor ---
Since r276469 GCC 10 inlines all three calls and so it issues the expected
diagnostics. GCC 9 declines to inline the call to h() in call_h().
pr83278.c: In function ‘call_f’:
pr83278.c:7:26: warning: ‘%s’ directive writing 5 bytes into a region of size 3
[-Wformat-overflow=]
7 | __builtin_sprintf (a, "%s", s); // warning (good)
| ^~
..
14 | f ("12345");
| ~~~
pr83278.c:7:3: note: ‘__builtin_sprintf’ output 6 bytes into a destination of
size 3
7 | __builtin_sprintf (a, "%s", s); // warning (good)
| ^~
pr83278.c: In function ‘call_g’:
pr83278.c:22:60: warning: ‘%s’ directive writing 6 bytes into a region of size
3 [-Wformat-overflow=]
22 | __builtin_object_size (a, 1), "%s", s);
|^~
..
27 | g ("123456");
|
pr83278.c:21:3: note: ‘__builtin___sprintf_chk’ output 7 bytes into a
destination of size 3
21 | __builtin___sprintf_chk (a, 1, // duplicate warning
| ^
22 | __builtin_object_size (a, 1), "%s", s);
| ~~
pr83278.c: In function ‘call_h’:
pr83278.c:35:59: warning: ‘%s’ directive writing 7 bytes into a region of size
3 [-Wformat-overflow=]
35 |__builtin_object_size (a, 1), "%s", s);
| ^~
..
42 | h ("1234567");
| ~
pr83278.c:34:3: note: ‘__builtin___sprintf_chk’ output 8 bytes into a
destination of size 3
34 | __builtin___sprintf_chk (a, 1, // missing warning (bug)
| ^
35 |__builtin_object_size (a, 1), "%s", s);
|~~
[Bug tree-optimization/71501] missing warning on printf %s with an unterminated array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71501
Martin Sebor changed:
What|Removed |Added
Depends on||87719
Known to fail|9.0 |10.0, 9.2.0
Summary|missing warning on printf |missing warning on printf
|%s with a non-nul |%s with an unterminated
|terminated string |array
--- Comment #5 from Martin Sebor ---
With pr87719 resolved, GCC 10 detects unterminated constant array arguments to
printf %s directives, but not the same problem in dynamically constructed
arrays. That has to wait until GCC 11.
$ cat pr71501.c && gcc -O2 -S -Wall pr71501.c
const char a[] = { 'a' };
int main (void)
{
const char b[] = { 'b' };
__builtin_printf ("a=%s", a); // warning (good)
__builtin_printf ("b=%s", b); // missing warning
}
pr71501.c: In function ‘main’:
pr71501.c:7:24: warning: ‘%s’ directive argument is not a nul-terminated string
[-Wformat-overflow=]
7 | __builtin_printf ("a=%s", a); // warning (good)
|^~ ~
pr71501.c:1:12: note: referenced argument declared here
1 | const char a[] = { 'a' };
|^
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87719
[Bug 87719] missing warning on printf %s and unterminated array
[Bug fortran/94909] New: Rejects valid code for recursion where there is none
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94909 Bug ID: 94909 Summary: Rejects valid code for recursion where there is none Product: gcc Version: 9.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: neil.n.carlson at gmail dot com Target Milestone: --- The compiler rejects the following valid code that contains no recursion. module example type, abstract :: foo contains procedure :: dot procedure(dot), deferred :: dot_ end type contains function dot(a, b) class(foo) :: a, b dot = a%dot_(b) end function end module $ gfortran -c gfortran-20200501.f90 gfortran-20200501.f90:13:10: 13 | dot = a%dot_(b) | 1 Error: Function ‘dot’ at (1) cannot be called recursively, as it is not RECURSIVE
[Bug target/94892] (x >> 31) + 1 not getting narrowed to compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94892
Harald van Dijk changed:
What|Removed |Added
CC||harald at gigawatt dot nl
--- Comment #3 from Harald van Dijk ---
Changing the test slightly to
inline int sign(int x)
{
return (x >> 31) | ((unsigned)-x >> 31);
}
void f1(void);
void f2(void);
void f(int x)
{
if (sign(x) > -1)
f1();
else
f2();
}
shows at -O3 with LLVM:
f:
testedi, edi
js .LBB0_2
jmp f1
.LBB0_2:
jmp f2
whereas GCC produces:
f:
mov eax, edi
sar edi, 31
neg eax
shr eax, 31
or edi, eax
cmp edi, -1
je .L2
jmp f1
.L2:
jmp f2
In that example, LLVM is doing much better.
[Bug c++/94885] [10/11 Regression] Functional cast from int to empty class type with empty base incorrectly accepted with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94885
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:30da2906ac521749aef8260fc1d942e62073f19d
commit r11-20-g30da2906ac521749aef8260fc1d942e62073f19d
Author: Marek Polacek
Date: Thu Apr 30 11:36:17 2020 -0400
c++: Parenthesized-init of aggregates accepts invalid code [PR94885]
Here we have (conceptually *) something like
struct B { };
struct D : B { };
D(0); // invalid
and in C++20 the ()-initialization has created a { 0 } constructor that
it tries to initialize an object of type D with. We should reject
initializing an object of type B from 0, but we wrongly accept it because
process_init_constructor_record skips initializers for empty bases/fields:
if (DECL_SIZE (field) && integer_zerop (DECL_SIZE (field))
&& !TREE_SIDE_EFFECTS (next))
/* Don't add trivial initialization of an empty base/field to the
constructor, as they might not be ordered the way the back-end
expects. */
continue;
but here 'next' was error_mark_node, returned by massage_elt_init, so we
wound up with { } which would validly value-initialize the object.
[*] Usually digest_init in build_new_method_call_1 would detect this,
but in this case the instance is is_dummy_object and we don't call
digest just yet.
PR c++/94885
* typeck2.c (process_init_constructor_record): Return
PICFLAG_ERRONEOUS
if an initializer element was erroneous.
* g++.dg/cpp2a/paren-init26.C: New test.
[Bug c++/94885] [10 Regression] Functional cast from int to empty class type with empty base incorrectly accepted with -std=c++2a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94885 Marek Polacek changed: What|Removed |Added Summary|[10/11 Regression] |[10 Regression] Functional |Functional cast from int to |cast from int to empty |empty class type with empty |class type with empty base |base incorrectly accepted |incorrectly accepted with |with -std=c++2a |-std=c++2a --- Comment #5 from Marek Polacek --- Fixed on trunk so far.
[Bug c++/90880] compile error instead of SFINAE with non-public member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880 --- Comment #5 from CVS Commits --- The master branch has been updated by Patrick Palka : https://gcc.gnu.org/g:4f6c1ca287d2c64856ef67fa50bc462633d5b8cf commit r11-21-g4f6c1ca287d2c64856ef67fa50bc462633d5b8cf Author: Patrick Palka Date: Fri May 1 16:18:19 2020 -0400 c++: Missing SFINAE with inaccessible static data member [PR90880] This is a missing SFINAE issue when verifying the accessibility of a static data member. The cause is that check_accessibility_of_qualified_id unconditionally passes tf_warning_or_error to perform_or_defer_access_check, even when called from tsubst_qualified_id(..., complain=tf_none). This patch fixes this by plumbing 'complain' from tsubst_qualified_id through check_accessibility_of_qualified_id to reach perform_or_defer_access_check, and by giving check_accessibility_of_qualified_id the appropriate return value. gcc/cp/ChangeLog: PR c++/90880 * cp-tree.h (check_accessibility_of_qualified_id): Add tsubst_flags_t parameter and change return type to bool. * parser.c (cp_parser_lookup_name): Pass tf_warning_to_error to check_accessibility_of_qualified_id. * pt.c (tsubst_qualified_id): Return error_mark_node if check_accessibility_of_qualified_id returns false. * semantics.c (check_accessibility_of_qualified_id): Add complain parameter. Pass complain instead of tf_warning_or_error to perform_or_defer_access_check. Return true unless perform_or_defer_access_check returns false. gcc/testsuite/ChangeLog: PR c++/90880 * g++.dg/template/sfinae29.C: New test.
[Bug c++/90880] compile error instead of SFINAE with non-public member variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90880 Patrick Palka changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |11.0 Status|ASSIGNED|RESOLVED --- Comment #6 from Patrick Palka --- Fixed for GCC 11.
[Bug sanitizer/94910] New: detect_stack_use_after_return=1 is much slower than clang's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94910 Bug ID: 94910 Summary: detect_stack_use_after_return=1 is much slower than clang's Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: rafael at espindo dot la CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at gcc dot gnu.org Target Milestone: --- The test I am using is from https://github.com/scylladb/seastar/. It can be build with $ cmake -DCMAKE_BUILD_TYPE=Debug -GNinja $ ninja tests/unit/chunked_fifo_test And can be run with: Clang: $ time ASAN_OPTIONS=detect_stack_use_after_return=1 ./tests/unit/chunked_fifo_test -t chunked_fifo_big ... 1.80s user 0.02s system 99% cpu 1.826 total $ time ASAN_OPTIONS=detect_stack_use_after_return=0 ./tests/unit/chunked_fifo_test -t chunked_fifo_big ... 1.67s user 0.01s system 99% cpu 1.691 total GCC: $ time ASAN_OPTIONS=detect_stack_use_after_return=1 ./tests/unit/chunked_fifo_test -t chunked_fifo_big 89.12s user 0.03s system 99% cpu 1:29.34 total $ time ASAN_OPTIONS=detect_stack_use_after_return=0 ./tests/unit/chunked_fifo_test -t chunked_fifo_big 1.32s user 0.02s system 99% cpu 1.350 total So while plain asan is faster with gcc, enabling detect_stack_use_after_return makes it much slower.
[Bug tree-optimization/94911] New: Failure to optimize comparisons of VLA sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911
Bug ID: 94911
Summary: Failure to optimize comparisons of VLA sizes
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
inline void assume(_Bool b)
{
if (!b)
__builtin_unreachable();
}
_Bool f(int n)
{
assume(n >= 1);
typedef int A[n];
++n;
A a;
int b[n];
n -= 2;
typedef int C[n];
C c;
return (sizeof(a) < sizeof(b)) && (sizeof(a) > sizeof(c));
}
This C code (this will have different results in C++ with GCC) should always
`return true`. LLVM makes this transformation, but GCC does not.
Also, extra question, is the fact that this always returns `false` when
compiled as C++ normal ? Clang has it return `true` if compiled as C++.
[Bug tree-optimization/94908] Failure to optimally optimize certain shuffle patterns
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94908 --- Comment #1 from Marc Glisse --- Even if we write __builtin_shuffle, the vector lowering pass turns it into the same code (constructor of BIT_FIELD_REFs), which seems to indicate that the target does not handle this pattern.
[Bug tree-optimization/94911] Failure to optimize comparisons of VLA sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911 --- Comment #1 from Marc Glisse --- gcc computes sizeof(a) as 4ul*(size_t)n, and unsigned types don't provide nice overflow guarantees, so that complicates things.
[Bug tree-optimization/94911] Failure to optimize comparisons of VLA sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug tree-optimization/94911] Failure to optimize comparisons of VLA sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911 --- Comment #2 from Andrew Pinski --- (In reply to Marc Glisse from comment #1) > gcc computes sizeof(a) as 4ul*(size_t)n, and unsigned types don't provide > nice overflow guarantees, so that complicates things. While the C++ front-end does: (sizetype) ((ssizetype) n + -1) + 1) * 4)
[Bug tree-optimization/94911] Failure to optimize comparisons of VLA sizes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94911 --- Comment #3 from Marc Glisse --- Since VLA is an extension for compatibility with C, it is strange that it behaves differently (does one use the value of n at the time of the typedef and the other at the time of the declaration?). This bug is about the optimization, maybe a separate report about the C++ behavior would make sense.
[Bug c++/94905] Bogus warning -Werror=maybe-uninitialized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94905 --- Comment #1 from Marc Glisse --- Several of us asked, and it was rejected. Your next step is to provide a self-contained testcase (preprocessed sources?). You may also want to check if it still warns in gcc-10.
[Bug c++/94912] New: Non-consistent behaviour of VLAs compared to C
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94912
Bug ID: 94912
Summary: Non-consistent behaviour of VLAs compared to C
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
#include
#include
bool f(int n)
{
typedef int A[n];
++n;
A a;
int b[n];
n -= 2;
typedef int C[n];
C c;
return (sizeof(a) < sizeof(b)) && (sizeof(a) > sizeof(c));
}
int main()
{
printf("%d", (int)f(10));
}
If compiled as C, this program will print 1. If compiled as C++, this program
will print 0. The C++ frontend seems to fail to take into account that the
`typedef`'s results are calculated at runtime based on the current value of
`n`.
[Bug tree-optimization/94913] New: Failure to optimize not+cmp into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94913
Bug ID: 94913
Summary: Failure to optimize not+cmp into overflow check
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(unsigned x, unsigned y)
{
return ~x < y;
}
With -O3, LLVM outputs this :
f(unsigned int, unsigned int):
add edi, esi
setb al
ret
GCC outputs this :
f(unsigned int, unsigned int):
not edi
cmp edi, esi
setb al
ret
[Bug tree-optimization/94913] Failure to optimize not+cmp into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94913
--- Comment #1 from Gabriel Ravier ---
The same thing happens for this code :
bool f(unsigned x, unsigned y)
{
return (x - y - 1) >= x;
}
LLVM outputs this :
f(unsigned int, unsigned int):
cmp esi, edi
setae al
ret
GCC outputs this :
f(unsigned int, unsigned int):
mov eax, edi
sub eax, esi
sub eax, 1
cmp eax, edi
setnb al
ret
[Bug tree-optimization/94914] New: Failure to optimize check of high part of 64-bit result of 32 by 32 multiplication into overflow check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94914
Bug ID: 94914
Summary: Failure to optimize check of high part of 64-bit
result of 32 by 32 multiplication into overflow check
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: gabravier at gmail dot com
Target Milestone: ---
bool f(uint32_t x, uint32_t y)
{
return (((uint64_t)x * y) >> 32) != 0;
}
This can be optimized an overflow check on a 32-bit multiplication. LLVM does
this transformation, but GCC does not.
[Bug tree-optimization/94898] Failure to optimize compare plus sub of same operands into compare
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94898 --- Comment #1 from Gabriel Ravier --- Also, if this function is changed to return `int`, it can then be optimized to a conditional move, which GCC fails to do
[Bug target/93492] Broken code with -fpatchable-function-entry and -fcf-protection=full
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93492 --- Comment #16 from CVS Commits --- The master branch has been updated by H.J. Lu : https://gcc.gnu.org/g:6607bdd4c834f92fce924abdaea3405f62dc commit r11-23-g6607bdd4c834f92fce924abdaea3405f62dc Author: H.J. Lu Date: Fri May 1 21:03:10 2020 -0700 Add patch_area_size and patch_area_entry to crtl Currently patchable area is at the wrong place. It is placed immediately after function label and before .cfi_startproc. A backend should be able to add a pseudo patchable area instruction durectly into RTL. This patch adds patch_area_size and patch_area_entry to crtl so that the patchable area info is available in RTL passes. It also limits patch_area_size and patch_area_entry to 65535, which is a reasonable maximum size for patchable area. gcc/ PR target/93492 * cfgexpand.c (pass_expand::execute): Set crtl->patch_area_size and crtl->patch_area_entry. * emit-rtl.h (rtl_data): Add patch_area_size and patch_area_entry. * opts.c (common_handle_option): Limit function_entry_patch_area_size and function_entry_patch_area_start to USHRT_MAX. Fix a typo in error message. * varasm.c (assemble_start_function): Use crtl->patch_area_size and crtl->patch_area_entry. * doc/invoke.texi: Document the maximum value for -fpatchable-function-entry. gcc/c-family/ PR target/93492 * c-attribs.c (handle_patchable_function_entry_attribute): Limit value to USHRT_MAX (65535). gcc/testsuite/ PR target/93492 * c-c++-common/patchable_function_entry-error-1.c: New test. * c-c++-common/patchable_function_entry-error-2.c: Likewise. * c-c++-common/patchable_function_entry-error-3.c: Likewise.
[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577 --- Comment #209 from Peter Bisroev --- (In reply to dave.anglin from comment #206) > Does adding the linker option "-Wl,-O" help to reduce the size of cc1 and > cc1plus? Hi Dave, Sorry for the delayed response. I have tried linker option "-Wl,-O" but it does not seem to make any difference. I used gcc 4.7.4 compiled with --enable-comdat option as per my comment 181 and get the same number of PCREL21B errors as before. I wonder if HPs linker does garbage collection after it deals with all the relocations first. Looks like we might have to get the fix into GNU AS first to get PCREL60B working. I will try to look into how we can get this done hopefully next weekend. Thanks! --peter
