[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94583 Jason Merrill changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from Jason Merrill --- Fixed.
[Bug c++/94583] [10 Regression] ICE in get_defaulted_eh_spec, at cp/method.c:2421
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94583 --- Comment #4 from CVS Commits --- The master branch has been updated by Jason Merrill : https://gcc.gnu.org/g:352811870d7d7edcca109ef50822e26ca7ef2b36 commit r10-7957-g352811870d7d7edcca109ef50822e26ca7ef2b36 Author: Jason Merrill Date: Fri Apr 24 16:27:26 2020 -0400 c++: implicit operator== with previous decl [PR94583] P2085 clarified that a defaulted comparison operator must be the first declaration of the function. Rejecting that avoids the ICE trying to compare the noexcept-specifications. gcc/cp/ChangeLog 2020-04-24 Jason Merrill PR c++/94583 * decl.c (redeclaration_error_message): Reject defaulted comparison operator that has been previously declared.
[Bug c/94755] New: [10 Regression] internal compiler error: Segmentation fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94755
Bug ID: 94755
Summary: [10 Regression] internal compiler error: Segmentation
fault
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 void foo ( void ) ;
void bar ( double x )
{
if ( x == __builtin_speculation_safe_value() )
foo ( ) ;
}
$ 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 ‘bar’:
reduced.c:6:2: error: too few arguments to function
‘__builtin_speculation_safe_value’
6 | if ( x == __builtin_speculation_safe_value() )
| ^~
reduced.c:6:2: internal compiler error: Segmentation fault
0xdab3ef crash_signal
../../gcc-10-20200419/gcc/toplev.c:328
0x89132f vec::operator[](unsigned int)
../../gcc-10-20200419/gcc/vec.h:867
0x89132f resolve_overloaded_builtin(unsigned int, tree_node*, vec*)
../../gcc-10-20200419/gcc/c-family/c-common.c:7405
0x81a6c9 c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
../../gcc-10-20200419/gcc/c/c-typeck.c:3199
0x838cde c_parser_postfix_expression_after_primary
../../gcc-10-20200419/gcc/c/c-parser.c:10501
0x8307a1 c_parser_postfix_expression
../../gcc-10-20200419/gcc/c/c-parser.c:10176
0x834ada c_parser_unary_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8273
0x83632d c_parser_cast_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8115
0x83671a c_parser_binary_expression
../../gcc-10-20200419/gcc/c/c-parser.c:8041
0x837595 c_parser_conditional_expression
../../gcc-10-20200419/gcc/c/c-parser.c:7652
0x837bb0 c_parser_expr_no_commas
../../gcc-10-20200419/gcc/c/c-parser.c:7569
0x837e11 c_parser_expression
../../gcc-10-20200419/gcc/c/c-parser.c:10637
0x8394a4 c_parser_expression_conv
../../gcc-10-20200419/gcc/c/c-parser.c:10670
0x8394a4 c_parser_condition
../../gcc-10-20200419/gcc/c/c-parser.c:6329
0x839597 c_parser_paren_condition
../../gcc-10-20200419/gcc/c/c-parser.c:6349
0x82e3e0 c_parser_if_statement
../../gcc-10-20200419/gcc/c/c-parser.c:6528
0x82e3e0 c_parser_statement_after_labels
../../gcc-10-20200419/gcc/c/c-parser.c:6160
0x82ff71 c_parser_compound_statement_nostart
../../gcc-10-20200419/gcc/c/c-parser.c:5805
0x84c8c4 c_parser_compound_statement
../../gcc-10-20200419/gcc/c/c-parser.c:5617
0x84e381 c_parser_declaration_or_fndef
../../gcc-10-20200419/gcc/c/c-parser.c:2505
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug analyzer/94754] -fanalyzer false positive due to it ignoring previous if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754
--- Comment #1 from Alejandro Colomar ---
__builin_unreachable() helped silencing that specific bug, as a temporary
workaround:
[[gnu::nonnull]]
static
int init_x(int cond, int **x, int *y)
{
if (!cond)
return -1;
*x = y;
return 0;
}
int foo(int cond)
{
int *x;
int y = 7;
if (cond < 2)
return -1;
/* cond >= 2 != 0, so it will initialize x and return 0 */
if (init_x(cond, , ))
__builtin_unreachable();
return *x;
}
[Bug analyzer/94754] New: -fanalyzer false positive due to it ignoring previous if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94754
Bug ID: 94754
Summary: -fanalyzer false positive due to it ignoring previous
if
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: colomar.6.4.3 at gmail dot com
Target Milestone: ---
The analyzer follows branches that are incompatible (sometimes).
Code to reproduce the bug:
[[gnu::nonnull]]
static
voidinit_x(int cond, int **x, int *y)
{
if (!cond)
return;
*x = y;
}
int foo(int cond)
{
int *x;
int y = 7;
if (cond < 2)
return -1;
/* cond >= 2 != 0, so it will initialize x */
init_x(cond, , );
return *x;
}
$ gcc-10 -c false_positive.c -o foo -fanalyzer
In function ‘foo’:
false_positive.c:22:9: warning: use of uninitialized value ‘x’ [CWE-457]
[-Wanalyzer-use-of-uninitialized-value]
22 | return *x;
| ^~
‘foo’: events 1-4
|
| 11 | int foo(int cond)
| | ^~~
| | |
| | (1) entry to ‘foo’
|..
| 16 | if (cond < 2)
| | ~
| | |
| | (2) following ‘false’ branch (when ‘cond > 1’)...
|..
| 20 | init_x(cond, , );
| |
| | |
| | (3) ...to here
| | (4) calling ‘init_x’ from ‘foo’
|
+--> ‘init_x’: events 5-7
|
|3 | void init_x(int cond, int **x, int *y)
| | ^~
| | |
| | (5) entry to ‘init_x’
|..
|6 | if (!cond)
| | ~
| | |
| | (6) following ‘true’ branch (when ‘cond == 0’)...
!!! cond == 0, but previously it assumed cond > 1 !!!
|7 | return;
| | ~~
| | |
| | (7) ...to here
|
<--+
|
‘foo’: events 8-9
|
| 20 | init_x(cond, , );
| | ^~~~
| | |
| | (8) returning to ‘foo’ from ‘init_x’
| 21 |
| 22 | return *x;
| | ~~
| | |
| | (9) use of uninitialized value ‘x’ here
|
$
___
But.
- If I copy (manual inline) `init_x` code inside `foo`, the warning goes
away.
- If I use pointers instead of double pointers (`void init_x(int cond, int *x,
int y)`), the warning goes away.
[Bug preprocessor/94753] New: -undef, c++20 and feature-test macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94753 Bug ID: 94753 Summary: -undef, c++20 and feature-test macros Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: preprocessor Assignee: unassigned at gcc dot gnu.org Reporter: r_new at rambler dot ru Target Milestone: --- In c++20 feature-test macros (__cpp_attributes, __cpp_constexpr, ...) are standard predefined macros, must be predefined even with -undef. g++ -undef -std=c++2a -E -dM -x c++ - < /dev/null #define __STDC_HOSTED__ 1 #define __STDC_IEC_559__ 1 #define __STDC_ISO_10646__ 201706L #define __STDC_UTF_16__ 1 #define __cplusplus 201709L #define _STDC_PREDEF_H 1 #define __STDC_IEC_559_COMPLEX__ 1 #define __STDC_UTF_32__ 1 #define __STDC__ 1 #define _GNU_SOURCE 1 gcc version 10.0.1 20200423 (experimental) (Compiler-Explorer-Build) and gcc version 9.3.0 (Arch Linux 9.3.0-1)
[Bug middle-end/92830] -fdiagnostics-url shows the wrong URL for warnings which are not in 'gcc' but e.g. in 'gfortran'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92830 David Malcolm changed: What|Removed |Added CC||dmalcolm at gcc dot gnu.org --- Comment #4 from David Malcolm --- Similarly, -fanalyzer warnings are documented within Static-Analyzer-Options.html.
[Bug c++/94751] [9/10 Regression] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 Marek Polacek changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #2 from Marek Polacek --- We now error_mark_node around for a longer time, so we need to handle it. Taking.
[Bug c++/94752] New: [coroutines] compiler ICE with coroutine with unnamed parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94752
Bug ID: 94752
Summary: [coroutines] compiler ICE with coroutine with unnamed
parameter
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: lewissbaker.opensource at gmail dot com
Target Milestone: ---
See https://godbolt.org/z/QCXqeo
Compile the following source code with GCC trunk.
Flags: -std=c++20 -fcoroutines
-
#include
using namespace std;
struct task {
struct promise_type {
promise_type() {}
task get_return_object() { return {}; }
suspend_never initial_suspend() { return {}; }
suspend_never final_suspend() { return {}; }
void return_void() {}
void unhandled_exception() {}
};
};
task foo(int) {
co_return;
}
-
Results in an internal-compile-error - segmentation-fault.
Pointing at closing curly-brace of 'foo()'.
Seems to be related to the parameter being unnamed as naming
the parameter results in this code compiling successfully.
[Bug c++/94751] [9/10] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||mpolacek at gcc dot gnu.org Target Milestone|--- |9.4 Last reconfirmed||2020-04-24 Ever confirmed|0 |1 Keywords||ice-on-invalid-code --- Comment #1 from Marek Polacek --- Started with r9-6097-g9d35a27a8353b57ed11fa1cb7d747edf1c4faa01
[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163 Bug 26163 depends on bug 89430, which changed state. Bug 89430 Summary: A missing ifcvt optimization to generate csel https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 Jakub Jelinek changed: What|Removed |Added Resolution|FIXED |--- CC||jakub at gcc dot gnu.org Status|RESOLVED|REOPENED --- Comment #13 from Jakub Jelinek --- The testcases for which this has been filed are no longer optimized, that needs more work for GCC11.
[Bug c++/94742] [8/9 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 Jakub Jelinek changed: What|Removed |Added Summary|[8/9/10 Regression] |[8/9 Regression] Incorrect |Incorrect "no return|"no return statement" |statement" warning with |warning with [[noreturn]] |[[noreturn]] and|and __FUNCTION__ |__FUNCTION__| --- Comment #4 from Jakub Jelinek --- Fixed on the trunk so far.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #19 from Jakub Jelinek --- Fixed.
[Bug c++/94742] [8/9/10 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 --- Comment #3 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:4ff685a8705e8ee55fa86e75afb769ffb0975aea commit r10-7953-g4ff685a8705e8ee55fa86e75afb769ffb0975aea Author: Jakub Jelinek Date: Sat Apr 25 00:11:35 2020 +0200 c++: Avoid -Wreturn-type warning if a template fn calls noreturn template fn [PR94742] finish_call_expr already has code to set current_function_returns_abnormally if a template calls a noreturn function, but on the following testcase it doesn't call a FUNCTION_DECL, but TEMPLATE_DECL instead, in which case we didn't check noreturn at all and just assumed it could return. 2020-04-25 Jakub Jelinek PR c++/94742 * semantics.c (finish_call_expr): When looking if all overloads are noreturn, use STRIP_TEMPLATE to look through TEMPLATE_DECLs. * g++.dg/warn/Wreturn-type-12.C: New test.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #18 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cf39dccf9284d2fd9f9aa7050760adea110c8d88 commit r10-7952-gcf39dccf9284d2fd9f9aa7050760adea110c8d88 Author: Jakub Jelinek Date: Sat Apr 25 00:10:01 2020 +0200 cselim: Don't assume it is safe to cstore replace a store to a local variable with unknown offset [PR94734] As the new testcase shows, it is not safe to assume we can optimize a conditional store into an automatic non-addressable var, we can do it only if we can prove that the unconditional load or store actually will not be outside of the boundaries of the variable. If the offset and size are constant, we can, but this is already all checked in !tree_could_trap_p, otherwise we really need to check for a dominating unconditional store, or for the specific case of automatic non-addressable variables, it is enough if there is a dominating load (that is what those 4 testcases have). tree-ssa-phiopt.c has some infrastructure for this already, see the add_or_mark_expr method etc., but right now it handles only MEM_REFs with SSA_NAME first operand and some integral offset. So, I think it can be for GCC11 extended to handle other memory references, possibly up to just doing get_inner_reference and hasing based on the base, offset expressions and bit_offset and bit_size, and have also a special case that for !TREE_ADDRESSABLE automatic variables it could ignore whether something is a load or store because the local stack should be always writable. But it feels way too dangerous to do this this late for GCC10, so this patch just restricts the optimization to the safe case (where lhs doesn't trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if flag_store_data_races, because my understanding the reason for TREE_ADDRESSABLE check is that we want to avoid introducing store data races (if address of an automatic var escapes, some other thread could be accessing it concurrently). 2020-04-25 Jakub Jelinek Richard Biener PR tree-optimization/94734 PR tree-optimization/89430 * tree-ssa-phiopt.c: Include tree-eh.h. (cond_store_replacement): Return false if an automatic variable access could trap. If -fstore-data-races, don't return false just because an automatic variable is addressable. * gcc.dg/tree-ssa/pr89430-1.c: Add xfail. * gcc.dg/tree-ssa/pr89430-2.c: Add xfail. * gcc.dg/tree-ssa/pr89430-5.c: Add xfail. * gcc.dg/tree-ssa/pr89430-6.c: Add xfail. * gcc.c-torture/execute/pr94734.c: New test.
[Bug preprocessor/94657] [patch] libcpp uses 'AR = ar' tool even if --build/--host are passed explicitly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94657 Eric Gallager changed: What|Removed |Added URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-April/5 ||44379.html Keywords||patch --- Comment #3 from Eric Gallager --- (In reply to Sergei Trofimovich from comment #2) > Sent as https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544379.html thanks, adding the "patch" keyword
[Bug tree-optimization/89430] A missing ifcvt optimization to generate csel
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89430 --- Comment #12 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:cf39dccf9284d2fd9f9aa7050760adea110c8d88 commit r10-7952-gcf39dccf9284d2fd9f9aa7050760adea110c8d88 Author: Jakub Jelinek Date: Sat Apr 25 00:10:01 2020 +0200 cselim: Don't assume it is safe to cstore replace a store to a local variable with unknown offset [PR94734] As the new testcase shows, it is not safe to assume we can optimize a conditional store into an automatic non-addressable var, we can do it only if we can prove that the unconditional load or store actually will not be outside of the boundaries of the variable. If the offset and size are constant, we can, but this is already all checked in !tree_could_trap_p, otherwise we really need to check for a dominating unconditional store, or for the specific case of automatic non-addressable variables, it is enough if there is a dominating load (that is what those 4 testcases have). tree-ssa-phiopt.c has some infrastructure for this already, see the add_or_mark_expr method etc., but right now it handles only MEM_REFs with SSA_NAME first operand and some integral offset. So, I think it can be for GCC11 extended to handle other memory references, possibly up to just doing get_inner_reference and hasing based on the base, offset expressions and bit_offset and bit_size, and have also a special case that for !TREE_ADDRESSABLE automatic variables it could ignore whether something is a load or store because the local stack should be always writable. But it feels way too dangerous to do this this late for GCC10, so this patch just restricts the optimization to the safe case (where lhs doesn't trap), and on Richi's request also ignores TREE_ADDRESSABLE bit if flag_store_data_races, because my understanding the reason for TREE_ADDRESSABLE check is that we want to avoid introducing store data races (if address of an automatic var escapes, some other thread could be accessing it concurrently). 2020-04-25 Jakub Jelinek Richard Biener PR tree-optimization/94734 PR tree-optimization/89430 * tree-ssa-phiopt.c: Include tree-eh.h. (cond_store_replacement): Return false if an automatic variable access could trap. If -fstore-data-races, don't return false just because an automatic variable is addressable. * gcc.dg/tree-ssa/pr89430-1.c: Add xfail. * gcc.dg/tree-ssa/pr89430-2.c: Add xfail. * gcc.dg/tree-ssa/pr89430-5.c: Add xfail. * gcc.dg/tree-ssa/pr89430-6.c: Add xfail. * gcc.c-torture/execute/pr94734.c: New test.
[Bug libstdc++/94747] Confusing code in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Nathan Sidwell changed: What|Removed |Added Last reconfirmed||2020-04-24 Summary|Undefined behavior: integer |Confusing code in |overflow in |libsupc++/dyncast.cc |libsupc++/dyncast.cc| CC||nathan at gcc dot gnu.org Status|RESOLVED|ASSIGNED Assignee|unassigned at gcc dot gnu.org |nathan at gcc dot gnu.org Resolution|INVALID |--- Ever confirmed|0 |1 --- Comment #3 from Nathan Sidwell --- While the code is well formed, it does not convey intent well. I wrote that code, and probably even considered spelling as -ptrdiff_t (offsetof ...). but didn't because it causes a line wrap and has no semantic difference. negating unsigned numbers often shows programmer confusion, and can cause bugs on I32LP64 systems, where the negation happens at a lower precision than expected. That's not the case here. If size_t has fewer bits than a pointer, there cannot be overflow from the top size_t bit to the pointer arithmetic -- that breaks C & C++ semantics. Something for stage 1
[Bug c++/94750] [10 Regression] Redundant identical using-declaration rejected since r10-554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94750 Patrick Palka changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Patrick Palka --- Never mind -- I think this is invalid.
[Bug bootstrap/94739] GCC won't build on CET enabled Linux OS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94739 H.J. Lu changed: What|Removed |Added Last reconfirmed||2020-04-24 Keywords||patch Status|UNCONFIRMED |NEW Ever confirmed|0 |1 URL||https://gcc.gnu.org/piperma ||il/gcc-patches/2020-April/5 ||44535.html --- Comment #1 from H.J. Lu --- A patch is posted at https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544535.html
[Bug target/94710] [8/9 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 Segher Boessenkool changed: What|Removed |Added Known to work||10.0 Summary|[8/9/10 Regression] |[8/9 Regression] Assembler |Assembler messages: Error: |messages: Error: operand |operand out of range (4 is |out of range (4 is not |not between 0 and 3)|between 0 and 3) (xxsldwi |(xxsldwi 0,32,33,4) |0,32,33,4) Known to fail|10.0| --- Comment #10 from Segher Boessenkool --- Fixed on trunk (so far).
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 --- Comment #9 from CVS Commits --- The master branch has been updated by Segher Boessenkool : https://gcc.gnu.org/g:9c725245beed2f056b67f5dc218fef6cb869c5f2 commit r10-7949-g9c725245beed2f056b67f5dc218fef6cb869c5f2 Author: Segher Boessenkool Date: Fri Apr 24 13:33:14 2020 + rs6000: Properly handle LE index munging in vec_shr (PR94710) The PR shows the compiler crashing with -mvsx -mlittle -O0. This turns out to be caused by a failure to make of the higher bits in an index endian conversion. 2020-04-24 Segher Boessenkool PR target/94710 * config/rs6000/vector.md (vec_shr_ for VEC_L): Correct little endian byteshift_val calculation.
[Bug c++/94751] New: [9/10] ICE on invalid code in maybe_instantiate_noexcept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94751
Bug ID: 94751
Summary: [9/10] ICE on invalid code in
maybe_instantiate_noexcept
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: s...@li-snyder.org
Target Milestone: ---
hi -
gcc version:
gcc version 10.0.1 20200329 (experimental) (GCC)
ICEs on the following (invalid) input:
-- x.cc -
struct Algorithm
{
Algorithm( float );
};
template
struct ToolWithConstants
: public Algorithm
{
using Algorithm::Algorithm;
struct Constant
{
Constant (int name);
};
Constant c { "order" };
};
class unique_ptr {};
unique_ptr make()
{
return unique_ptr (new ToolWithConstants (10.5));
}
like this:
[sss@karma rootaccess]$ g++ -c x.cc
x.cc: In function ‘unique_ptr make()’:
x.cc:25:60: internal compiler error: Segmentation fault
25 | return unique_ptr (new ToolWithConstants (10.5));
|^
0xc4fe4f crash_signal
/home/sss/gcc/gcc/gcc/toplev.c:328
0x7f4d24bf8ebf ???
/usr/src/debug/glibc-2.29-51-g845278f2c6/signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x759eff maybe_instantiate_noexcept(tree_node*, int)
/home/sss/gcc/gcc/gcc/cp/pt.c:25032
0x6b8388 mark_used(tree_node*, int)
/home/sss/gcc/gcc/gcc/cp/decl2.c:5512
0x644892 build_over_call
/home/sss/gcc/gcc/gcc/cp/call.c:9048
0x646ade build_new_method_call_1
/home/sss/gcc/gcc/gcc/cp/call.c:10338
0x647796 build_new_method_call(tree_node*, tree_node*, vec**, tree_node*, int, tree_node**, int)
/home/sss/gcc/gcc/gcc/cp/call.c:10413
0x647796 build_special_member_call(tree_node*, tree_node*, vec**, tree_node*, int, int)
/home/sss/gcc/gcc/gcc/cp/call.c:9814
0x6cec5f build_new_1
/home/sss/gcc/gcc/gcc/cp/init.c:3588
0x6cf9f8 build_new(unsigned int, vec**,
tree_node*, tree_node*, vec**, int, int)
/home/sss/gcc/gcc/gcc/cp/init.c:3905
0x729a37 cp_parser_new_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:8825
0x72a057 cp_parser_unary_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:8418
0x706b1a cp_parser_binary_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:9554
0x7081ce cp_parser_assignment_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:9859
0x70a668 cp_parser_parenthesized_expression_list
/home/sss/gcc/gcc/gcc/cp/parser.c:7981
0x70ada2 cp_parser_functional_cast
/home/sss/gcc/gcc/gcc/cp/parser.c:29572
0x721f24 cp_parser_postfix_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:7180
0x706b1a cp_parser_binary_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:9554
0x7081ce cp_parser_assignment_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:9859
0x7084e2 cp_parser_expression
/home/sss/gcc/gcc/gcc/cp/parser.c:10027
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
A crash is also observed with a 20200424 version as well as
gcc version 9.2.1 20190827 (Red Hat 9.2.1-1) (GCC)
thanks,
sss
[Bug c++/94750] New: [10 Regression] Redundant identical using-declaration rejected since r10-554
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94750
Bug ID: 94750
Summary: [10 Regression] Redundant identical using-declaration
rejected since r10-554
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppalka at gcc dot gnu.org
Target Milestone: ---
$ cat testcase.C
namespace ns
{
using type = int;
}
int
main()
{
using ns::type;
using ns::type;
}
$ g++ testcase.C
testcase.C: In function ‘int main()’:
testcase.C: error: redeclaration of ‘using type = int’
10 | using ns::type;
| ^~~~
testcase.C: note: previous declaration ‘using type = int’
3 | using type = int;
| ^~~~
[Bug libstdc++/94747] Undefined behavior: integer overflow in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Jonathan Wakely changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #2 from Jonathan Wakely --- (In reply to AK from comment #0) > Integer overflow reported by asan with the following stack trace. asan?! Are you sure? As Jakub says, this is probably the dumb "unsigned-integer-overflow" sanitizer, which is dumb because unsigned integers can't overflow by definition (they wrap) and because that wrapping is never undefined. The code is fine.
[Bug c++/94745] No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 Richard Biener changed: What|Removed |Added Resolution|--- |WONTFIX Status|UNCONFIRMED |RESOLVED --- Comment #3 from Richard Biener --- If you want to detect whether a warning is supported use -Wfoo, not -Wno-foo.
[Bug target/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740 --- Comment #4 from Peter Bergner --- Removing the bswap and recompiling, the non-bswap load pattern has no problem accepting an address like that, so this looks like a target issue with that pattern.
[Bug target/94383] [8/9/10 Regression] class with empty base passed incorrectly with -std=c++17 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383 --- Comment #17 from CVS Commits --- The master branch has been updated by Jakub Jelinek : https://gcc.gnu.org/g:9407f0c32b215d55d3474a234b0043bddc185b1c commit r10-7948-g9407f0c32b215d55d3474a234b0043bddc185b1c Author: Jakub Jelinek Date: Fri Apr 24 19:14:27 2020 +0200 testsuite: C++14 vs. C++17 struct-layout-1.exp testing with ALT_CXX_UNDER_TEST [PR94383] > I haven't added (yet) checks if the alternate compiler does support these > options (I think that can be done incrementally), so for now this testing is > done only if the alternate compiler is not used. This patch does that, so now when testing against not too old compiler it can do the -std=c++14 vs. -std=c++17 testing also between under test and alt compilers. 2020-04-24 Jakub Jelinek PR c++/94383 * g++.dg/compat/struct-layout-1.exp: Use the -std=c++14 vs. -std=c++17 ABI compatibility testing even with ALT_CXX_UNDER_TEST, as long as that compiler accepts -std=c++14 and -std=c++17 options.
[Bug libstdc++/94749] New: std::istream::ignore discards too many characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94749
Bug ID: 94749
Summary: std::istream::ignore discards too many characters
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: serpent7776 at gmail dot com
Target Milestone: ---
Created attachment 48369
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48369=edit
full source example
The following code results in '=' assigned to c when using libstdc++, but '+'
is assigned when using libc++, I believe libc++ is correct here
std::stringstream s(" +=");
char c;
s.ignore(1, '+');
s >> c;
Tested this on godbolt with newest gcc and locally on FreeBSD with gcc7
(command: g++7 -Wall -Wextra -pedantic test.cpp)
https://godbolt.org/z/yS5je8
[Bug target/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740
--- Comment #3 from Peter Bergner ---
Here's a simpler test case that fails the same way:
int array[8];
int
foo (void)
{
return __builtin_bswap32 (array[1]);
}
So before CSE, we have:
(insn 5 2 6 2 (set (reg/f:DI 121)
(symbol_ref:DI ("*.LANCHOR0") [flags 0x182]))
{*pcrel_local_addr})
(insn 6 5 7 2 (set (reg:DI 123)
(const_int 4 [0x4])) {*movdi_internal64})
(insn 7 6 8 2 (set (reg:SI 122)
(bswap:SI (mem/c:SI (plus:DI (reg/f:DI 121)
(reg:DI 123)
{bswapsi2_load}
(expr_list:REG_EQUAL (bswap:SI (mem/c:SI (plus:DI (reg/f:DI 121)
(const_int 4 [0x4]))
...
After CSE, we then have all the way up to LRA:
(insn 7 9 14 2 (set (reg:SI 122)
(bswap:SI (mem/c:SI (plus:DI (symbol_ref:DI ("*.LANCHOR0")
[flags 0x182])
(const_int 4) {bswapsi2_load})
...
LRA then calls decompse_address with the above address, which causes us to go
sideways. Not sure why yet. Maybe our bswap2_load pattern needs help?
[Bug target/94748] New: aarch64: many unnecessary bti j emitted
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94748
Bug ID: 94748
Summary: aarch64: many unnecessary bti j emitted
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: nsz at gcc dot gnu.org
Target Milestone: ---
__attribute__((target("branch-protection=bti")))
int foo(void)
{
label:
return 0;
}
compiles to
foo:
hint34 // bti c
hint36 // bti j
mov w0, 0
ret
the bti j is not necessary and bti j should be rarely emitted
otherwise the security architecture is weakened.
[Bug libstdc++/94747] Undefined behavior: integer overflow in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Negation of unsigned long value is well defined for all possible values, including 16. Is that with the flawed clang -fsanitize=unsigned-integer-overflow ? GCC doesn't implement that for a reason.
[Bug target/94740] ICE on testsuite/gcc.dg/sso/t5.c with -mcpu=future -mpcrel -O1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94740 Peter Bergner changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2020-04-24 --- Comment #2 from Peter Bergner --- Confirmed. I'll have a quick look.
[Bug libstdc++/94747] New: Undefined behavior: integer overflow in libsupc++/dyncast.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94747 Bug ID: 94747 Summary: Undefined behavior: integer overflow in libsupc++/dyncast.cc Product: gcc Version: 7.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hiraditya at msn dot com Target Milestone: --- Integer overflow reported by asan with the following stack trace. If this is not sufficient I can try to provide a repro gcc/7.x/libstdc++-v3/libsupc++/dyncast.cc:53:11: runtime error: negation of 16 cannot be represented in type 'unsigned long' > #0 in __dynamic_cast gcc/7.x/libstdc++-v3/libsupc++/dyncast.cc:53 > #1 in bool std::has_facet >(std::locale const&) > gcc/7.x/.../bits/locale_classes.tcc:110 > #2 in std::basic_ios > >::_M_cache_locale(std::locale const&) gcc/7.x/.../bits/basic_ios.tcc:159 > #3 in std::basic_ios > >::init(std::basic_streambuf >*) > gcc/7.x/.../bits/basic_ios.tcc:132 > #4 in std::basic_ostream > >::basic_ostream(std::basic_streambuf >*) > gcc/7.x/.../ostream:85 > #5 in std::ios_base::Init::Init() > gcc/7.x/libstdc++-v3/src/c++98/ios_init.cc:91 > #6 in __cxx_global_var_init gcc/7.x/.../iostream:74
[Bug target/92950] Wrong load instructions emitted for movv1qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950 Andreas Krebbel changed: What|Removed |Added Status|RESOLVED|CLOSED --- Comment #5 from Andreas Krebbel --- Fixed
[Bug target/92950] Wrong load instructions emitted for movv1qi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||jakub at gcc dot gnu.org Resolution|--- |FIXED --- Comment #4 from Jakub Jelinek --- Assuming fixed.
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
--- Comment #17 from Martin Sebor ---
As you observed, the warning disappears if the assert is removed, so that's one
workaround. But rather than working around it I would suggest to rewrite the
code to avoid the pointer subtraction. Chances are it will not only avoid the
warning but help improve the emitted object code. I'm not sure I understand
correctly what the test case is meant to do but the example below shows what
I'm thinking of. If modifying the code isn't feasible then #pragma GCC
diagnostic is the recommended suppression mechanism.
typedef unsigned char byte;
typedef __PTRDIFF_TYPE__ ptrdiff_t;
typedef __SIZE_TYPE__ size_t;
typedef struct pstream_t {
const byte * p;
ptrdiff_t n;
} pstream_t;
static inline _Bool ps_has (const pstream_t *ps, size_t len)
{
return (size_t)ps->n >= len;
}
static inline int __ps_skip (pstream_t * ps, size_t len)
{
if (!ps_has (ps, len))
__builtin_abort ();
ps->p += len;
ps->n -= len;
return 0;
}
static inline int ps_skip (pstream_t * ps, size_t len)
{
return ps_has (ps, len) ? __ps_skip(ps, len) : -1;
}
byte c;
int c_len;
void f(void)
{
pstream_t ps = { , c_len };
ps_skip (, 7);
}
[Bug c++/91706] [8/9/10 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in equate_type_number_to_die, at dwarf2out.c:5782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91706
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #5 from Patrick Palka ---
Slightly more reduced testcase:
template struct A;
struct C {
template static int c ();
};
template struct D : C {
using c = decltype (c);
using E = A;
};
D g;
[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90254 Marek Polacek changed: What|Removed |Added Keywords||ice-on-valid-code Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Status|NEW |ASSIGNED
[Bug middle-end/93488] [OpenACC] ICE in type-cast 'async', 'wait' clauses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93488 Andrew Stubbs changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #2 from Andrew Stubbs --- I think this is done now.
[Bug c/94746] New: -Wsizeof-pointer-div not triggered by system header macros
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94746
Bug ID: 94746
Summary: -Wsizeof-pointer-div not triggered by system header
macros
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: colomar.6.4.3 at gmail dot com
Target Milestone: ---
I found out that the macro `#define __arraycount(__x) (sizeof(__x) /
sizeof(__x[0]))` which is in libbsd's doesn't trigger any warning
when applied to a pointer.
I investigated the reason, and I found out that my own `#define ARRAY_SIZE(arr)
(sizeof(arr) / sizeof((arr)[0]))` doesn't trigger any warnings either (it is
installed in `/usr/local/include/`, but it does trigger warnings when compiling
before installing it.
So I came to the conclusion that the bug is the following:
GCC suppresses warnings in system headers, which of course is a generally good
thing, but in this case it is not a good thing.
Maybe a solution would be to not suppress warnings about macros defined in
system headers (this might suddenly trigger lots of warnings, some of them
maybe unwanted, I don't know). There might be more bugs like this one being
ignored.
Code to reproduce the bug:
#include
int main(void)
{
int *p;
return __arraycount(p);
}
Minimum compilation settings to reproduce the bug:
$ gcc -Wsizeof-pointer-div bug.c `pkg-config --cflags libbsd-overlay`
[Bug c++/94745] No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 --- Comment #2 from Jonathan Wakely --- (In reply to Louis Dionne from comment #0) > This makes detecting whether GCC supports a given warning flag very > challenging in build systems. You're doing it wrong then. Try 'g++ -Q --help=warnings' instead of probing individual options.
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 --- Comment #8 from Segher Boessenkool --- Patch is bootstrapping.
[Bug c++/94745] No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 --- Comment #1 from Jonathan Wakely --- This is by design. It means that makefiles written for different versions of GCC do not trigger spurious diagnostics. If somebody says "I don't want warnings about cat noises" and their version of GCC doesn't support -Wmeow then their request is granted. Warning about it would cause valid compilations to fail. If other diagnostics are being emitted anyway, then adding one to point out the unrecognized option isn't going to make a build go from passing to failing.
[Bug libstdc++/94203] experimental/executor and socket header issues-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94203 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- Fixed for 9.4
[Bug libstdc++/94744] [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94744 --- Comment #3 from Jonathan Wakely --- Fixed now.
[Bug libstdc++/94203] experimental/executor and socket header issues-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94203 --- Comment #3 from CVS Commits --- The releases/gcc-9 branch has been updated by Jonathan Wakely : https://gcc.gnu.org/g:942b32e261c414a033766ed7848d923f9630b991 commit r9-8543-g942b32e261c414a033766ed7848d923f9630b991 Author: Jonathan Wakely Date: Fri Apr 24 14:29:37 2020 +0100 libstdc++: Fix type-erasure in experimental::net::executor (PR 94203) The _Tgt and _TgtImpl types that implement type-erasure didn't agree on the virtual interface, so failed as soon as they were instantiated. With Clang they failed even sooner. The interface was also dependent on whether RTTI was enabled or not. This patch fixes the broken virtual functions and makes the type work without RTTI, by using a pointer to a specialization of a function template (similar to the approaches in std::function and std::any). The changes to the virtual functions would be an ABI change, except that the previous code didn't even compile if instantiated. This is experimental TS material anyway. Backport from mainline 2020-03-18 Jonathan Wakely PR libstdc++/94203 * include/experimental/executor (executor::executor(Executor)): Call make_shared directly instead of _M_create. Create _Tgt1 object. (executor::executor(allocator_arg_t, const ProtoAlloc&, Executor)): Call allocate_shared directly instead of _M_create. Create _Tgt2 object. (executor::target_type): Add cast needed for new _Tgt interface. (executor::target): Define when RTTI is disabled. Use _Tgt::_M_func. (executor::_Tgt): Define the same interface whether RTTI is enabled or not. (executor::_Tgt::target_type, executor::_Tgt::target): Do not use std::type_info in the interface. (executor::_Tgt::_M_func): Add data member. (executor::_TgtImpl): Replace with _Tgt1 and _Tgt2 class templates. (executor::_Tgt1::_S_func): Define function to access target without depending on RTTI. (executor::_M_create): Remove. (operator==, operator!=): Simplify comparisons for executor. * include/experimental/socket (is_error_code_enum): Define specialization before use. * testsuite/experimental/net/executor/1.cc: New test.
[Bug c++/94745] New: No error emitted for unknown -Wno-meow argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94745 Bug ID: 94745 Summary: No error emitted for unknown -Wno-meow argument Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: ldionne.2 at gmail dot com Target Milestone: --- GCC does not diagnose unsupported -Wno-meow command line flags unless another error happens during compilation. For example, the following compiles just fine even though -Wno-foo doesn't exist: $ echo | g++ -xc++ - -Werror -fsyntax-only -Wno-foo If, however, another error happens during compilation, the unsupported command-line flag is reported: $ echo '#error' | g++ -xc++ - -Werror -fsyntax-only -Wno-foo :1:2: error: #error cc1plus: error: unrecognized command line option '-Wno-foo' [-Werror] cc1plus: all warnings being treated as errors This makes detecting whether GCC supports a given warning flag very challenging in build systems. This issue popped up while trying to support GCC when running the libc++ Standard Library conformance test suite.
[Bug c++/90448] [8/9 Regression] decltype-based lambda parameter pack is rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90448
Jakub Jelinek changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
||segher at gcc dot gnu.org
--- Comment #7 from Jakub Jelinek ---
So, seems the second argument of the call is some empty class - struct
._anon_2, 1 byte long, and the FE in the CALL_EXPR passes an empty CONSTRUCTOR
of that type.
The gimplifier then creates a temporary for that (and doesn't initialize it),
so we have:
struct ._anon_2 D.3223;
:
= fooV<{const char*, int, double, char, float, short int, unsigned
int}>operator()::, const char*,
int, double, char, float, short int, unsigned int> (0B, D.3223, _2(D)
, _3(D), _4(D), _5(D), _6(D), _7(D), _8(D)); [return slot optimization]
up to *.optimized in a thunk, D.3223 is not initialized (contains just padding)
and is passed by value to the call.
Now, on powerpc -m32, the ABI wants to pass that by reference -
if (pass_by_reference (args_so_far_pnt, arg))
is true, and we enter:
/* If we're compiling a thunk, pass through invisible references
instead of making a copy. */
if (call_from_thunk_p
|| (callee_copies
&& !TREE_ADDRESSABLE (type)
&& (base = get_base_address (args[i].tree_value))
&& TREE_CODE (base) != SSA_NAME
&& (!DECL_P (base) || MEM_P (DECL_RTL (base)
block because call_from_thunk_p is true. But, base is a DECL with DECL_RTL of
a (reg:QI ...).
The code calls mark_addressable on args[i].tree_value, but that doesn't do
anything immediately, because currently_expanding_to_rtl is true (but even if
it would, that doesn't change DECL_RTL of the arg being passed).
Later the code calls build_fold_addr_expr_loc and ICEs when expanding that,
because trying to expand ADDR_EXPR on a VAR_DECL with DECL_RTL of (reg:QI ...)
doesn't work.
I don't see how this can be implemented other than actually making a copy,
so wonder if the condition shouldn't be
if ((call_from_thunk_p || callee_copies)
&& !TREE_ADDRESSABLE (type)
&& ...
instead. But what do I know about thunks.
[Bug libstdc++/94203] experimental/executor and socket header issues-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94203 Jonathan Wakely changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #2 from Jonathan Wakely --- *** Bug 94744 has been marked as a duplicate of this bug. ***
[Bug libstdc++/94744] [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94744 Jonathan Wakely changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #2 from Jonathan Wakely --- This is PR 94203, which is still open until I backport it. The added test on the branch reveals the latent bug. *** This bug has been marked as a duplicate of bug 94203 ***
[Bug libstdc++/94744] [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94744 Jonathan Wakely changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Last reconfirmed||2020-04-24 Target Milestone|--- |9.4 Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Jonathan Wakely --- I think I need to backport g:98f29f5638f73d8e55590eba8098a537ba746287
[Bug c++/94288] co_await in while loop crashes g++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94288 Iain Sandoe changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Iain Sandoe --- A test case from the original post was committed as r10-7944-g1d072f3eeac4 (I missed the PR number from the commit) so fixed.
[Bug libstdc++/94744] New: [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94744 Bug ID: 94744 Summary: [9 Regression] FAIL: experimental/net/executor/1.cc (test for excess errors) Product: gcc Version: 9.3.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: hjl.tools at gmail dot com Target Milestone: --- On Fedora 31, r9-8540 gave Executing on host: /export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc/xg++ -shared-libgcc -B/export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc -nostdinc++ -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/.libs -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/libsupc++/.libs -B/usr/9.3.1/i686-linux/bin/ -B/usr/9.3.1/i686-linux/lib/ -isystem /usr/9.3.1/i686-linux/include -isystem /usr/9.3.1/i686-linux/sys-include -fchecking=1 -B/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -fcf-protection -mshstk -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux -I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/util /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc -include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/filesystem/.libs -lm -o ./1.exe(timeout = 600) spawn -ignore SIGHUP /export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc/xg++ -shared-libgcc -B/export/gnu/import/git/gcc-test-release-1-ia32/bld/./gcc -nostdinc++ -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/.libs -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/libsupc++/.libs -B/usr/9.3.1/i686-linux/bin/ -B/usr/9.3.1/i686-linux/lib/ -isystem /usr/9.3.1/i686-linux/include -isystem /usr/9.3.1/i686-linux/sys-include -fchecking=1 -B/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -fcf-protection -mshstk -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/i686-linux -I/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/libsupc++ -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/include/backward -I/export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/util /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc -include bits/stdc++.h -fno-diagnostics-show-caret -fdiagnostics-color=never ./libtestc++.a -Wl,--gc-sections -L/export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/src/filesystem/.libs -lm -o ./1.exe In file included from /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:20: /export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/experimental/executor: In instantiation of '_Executor* std::experimental::net::v1::executor::target() [with _Executor = test02()::E]': /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:71: required from here /export/gnu/import/git/gcc-test-release-1-ia32/bld/i686-linux/libstdc++-v3/include/experimental/executor:1112: error: no matching function for call to 'test02()::E::E(const void*&)' /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45: note: candidate: 'constexpr test02()::E::E(const test02()::E&)' /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45: note: no known conversion for argument 1 from 'const void*' to 'const test02()::E&' /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45: note: candidate: 'constexpr test02()::E::E(test02()::E&&)' /export/gnu/import/git/gcc-test-release-1-ia32/src-9/libstdc++-v3/testsuite/experimental/net/executor/1.cc:45:
[Bug c++/94742] [8/9/10 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 Jakub Jelinek changed: What|Removed |Added Last reconfirmed||2020-04-24 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jakub Jelinek --- Created attachment 48368 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48368=edit gcc10-pr94742.patch Untested fix.
[Bug target/94743] New: IRQ handler implementation wrong when using __attribute__ ((interrupt("IRQ")))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94743
Bug ID: 94743
Summary: IRQ handler implementation wrong when using
__attribute__ ((interrupt("IRQ")))
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: clyon at gcc dot gnu.org
Target Milestone: ---
Hi,
As described in https://bugs.linaro.org/show_bug.cgi?id=5614:
IRQ implementation when using __attribute__ ((interrupt("IRQ"))) by GCC does
not save/restore NEON scratch registers when using -mfloat-abi=hard
-mfpu=neon-fp16.
But if the handler calls a function that uses Neon scratch registers, this will
corrupt the values seen by the program when the IRQ handler completes.
An easy example uses memcpy in the handler:
=== irq_test.c ===
typedef struct {
int data[32];
} dummy_t ;
extern void foo(dummy_t d);
__attribute__ ((interrupt("IRQ"))) void IRQ_HDLR_Test(void) {
dummy_t d;
d.data[3] = 3;
foo(d);
}
===
Compile with arm-none-eabi-gcc -mcpu=cortex-a9 -mtune=cortex-a9 -marm
-mfloat-abi=hard -mfpu=neon-fp16 -Ofast irq_test.c
The generated code looks like:
21IRQ_HDLR_Test:
22@ Interrupt Service Routine.
23@ args = 0, pretend = 0, frame = 128
24@ frame_needed = 0, uses_anonymous_args = 0
25 04E04EE2 sub lr, lr, #4
26 0004 0F502DE9 push{r0, r1, r2, r3, ip, lr}
27 0008 F0D04DE2 sub sp, sp, #240
28 000c 0330A0E3 mov r3, #3
29 0010 80108DE2 add r1, sp, #128
30 0014 7020A0E3 mov r2, #112
31 0018 0D00A0E1 mov r0, sp
32 001c 7C308DE5 str r3, [sp, #124]
33 0020 FEEB bl memcpy
34 0024 70308DE2 add r3, sp, #112
35 0028 0F0093E8 ldm r3, {r0, r1, r2, r3}
36 002c FEEB bl foo
37 0030 F0D08DE2 add sp, sp, #240
38@ sp needed
39 0034 0F90FDE8 ldmfd sp!, {r0, r1, r2, r3, ip, pc}^
In this case, the newlib version of memcpy uses NEON code and will clobber NEON
registers.
To be safe, the IRQ handler should
push {d0-d7, d16-d31}
This can be costly in terms of CPU cycles for an IRQ handler, so maybe we could
think of adding another attribute but it would be hard for the end-user to
guess that he might use Neon registers in an implicit way (like here where the
compiler calls memcpy)
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #43 from John David Anglin --- The fix for PR 94694 fixed the build on hppa2.0w-hp-hpux11.11. We are left with the following new fails in dec_math.f90: FAIL: gfortran.dg/dec_math.f90 -O0 (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -O0 execution test FAIL: gfortran.dg/dec_math.f90 -O1 (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -O1 execution test FAIL: gfortran.dg/dec_math.f90 -O2 (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -O2 execution test FAIL: gfortran.dg/dec_math.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel- loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel- loops -ftracer -finline-functions execution test FAIL: gfortran.dg/dec_math.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -O3 -g execution test FAIL: gfortran.dg/dec_math.f90 -Os (test for excess errors) FAIL: gfortran.dg/dec_math.f90 -Os execution test This is caused by the missing 'l' suffix routines: spawn /test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../gfortran -B/test/gnu/gcc/objdir/gcc/testsuite/gfortran/../../ -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/ /test/gnu/gcc/gcc/gcc/testsuite/gfortran.dg/dec_math.f90 -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers -fdiagnostics-color=never -fdiagnostics-urls=never -O0 -cpp -std=gnu -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libgfortran/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libatomic/.libs -B/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libquadmath/.libs -lm -o ./dec_math.exe /usr/ccs/bin/ld: Unsatisfied symbols: tanl (first referenced in /var/tmp//ccQhSJVu.o) (code) asinl (first referenced in /var/tmp//ccQhSJVu.o) (code) sinl (first referenced in /var/tmp//ccQhSJVu.o) (code) acosl (first referenced in /var/tmp//ccQhSJVu.o) (code) atanl (first referenced in /var/tmp//ccQhSJVu.o) (code) atan2l (first referenced in /var/tmp//ccQhSJVu.o) (code) cosl (first referenced in /var/tmp//ccQhSJVu.o) (code) collect2: error: ld returned 1 exit status compiler exited with status 1 While I will continue to work on a change to use the 'q' routines from libquadmath on hppa-hpux, this is of lower priority.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #42 from Jakub Jelinek --- I think this one is not fixed yet, there is some pa hpux specific patch. See e.g. #c39.
[Bug libfortran/94586] trigd_lib.inc:84:28: error: implicit declaration of function 'fmaf'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586 --- Comment #41 from Richard Biener --- If this is now fixed can you close the bug as such please, John?
[Bug c++/94742] [8/9/10 Regression] Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742 Jakub Jelinek changed: What|Removed |Added Summary|Incorrect "no return|[8/9/10 Regression] |statement" warning with |Incorrect "no return |[[noreturn]] and|statement" warning with |__FUNCTION__|[[noreturn]] and ||__FUNCTION__ Target Milestone|--- |8.5 CC||jakub at gcc dot gnu.org --- Comment #1 from Jakub Jelinek --- Started with r8-4349-g1b6fa695ab5e6f6fd57ed9264b336f06f440125b when -Wreturn-type has been enabled by default, but with explicit -Wreturn-type and __attribute__((noreturn)) instead of [[noreturn]] already failed in r105000.
[Bug c/94726] [10 Regression] ICE in uniform_vector_p, at tree.c:11214 since r10-2089-g21caa1a2649d586f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org Priority|P3 |P4 --- Comment #4 from Jakub Jelinek --- Bet dup of PR94730 and PR94731, it is really the same problem, the middle-end is unhappy if types of variables used in functions change to random different type later.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #17 from Jakub Jelinek --- Created attachment 48367 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48367=edit gcc10-pr94734.patch Updated patch.
[Bug c++/94742] New: Incorrect "no return statement" warning with [[noreturn]] and __FUNCTION__
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94742
Bug ID: 94742
Summary: Incorrect "no return statement" warning with
[[noreturn]] and __FUNCTION__
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: didier.gcc at trosset dot fr
Target Milestone: ---
g++ version 8.3.0, default compiler for Debian 10, issues an incorrect "no
return statement in function returning non-void" when the __FUNCTION__ macro is
used to call a [[noreturn]] function.
This looks similar to bug 30988. This later is fixed, but the following code
still issue this incorrect warning. Similar to 30988, if __FUNCTION__ is casted
to char const*, the warning vanishes.
===
template [[noreturn]] void Throw( T const& t, char const* /* f */ )
{ throw T(t); }
template
int DoIt()
{
//::Throw( int(42), __FILE__ );// No warning
::Throw( int(42), __FUNCTION__ ); // warning: no return statement
}
int main()
{
DoIt();
return 0;
}
===
$ g++ -Wall -Wextra -v gcc-test-function.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/8/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 8.3.0-6'
--with-bugurl=file:///usr/share/doc/gcc-8/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++ --prefix=/usr
--with-gcc-major-version-only --program-suffix=-8
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-vtable-verify --enable-libmpx --enable-plugin --enable-default-pie
--with-system-zlib --with-target-system-zlib --enable-objc-gc=auto
--enable-multiarch --disable-werror --with-arch-32=i686 --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --with-tune=generic
--enable-offload-targets=nvptx-none --without-cuda-driver
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 8.3.0 (Debian 8.3.0-6)
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/8/cc1plus -quiet -v -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE gcc-test-function.cpp -quiet -dumpbase gcc-test-function.cpp
-mtune=generic -march=x86-64 -auxbase gcc-test-function -Wall -Wextra -version
-o /tmp/ccMsF2uX.s
GNU C++14 (Debian 8.3.0-6) version 8.3.0 (x86_64-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring duplicate directory "/usr/include/x86_64-linux-gnu/c++/8"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../../x86_64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/include/c++/8
/usr/include/x86_64-linux-gnu/c++/8
/usr/include/c++/8/backward
/usr/lib/gcc/x86_64-linux-gnu/8/include
/usr/local/include
/usr/lib/gcc/x86_64-linux-gnu/8/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
GNU C++14 (Debian 8.3.0-6) version 8.3.0 (x86_64-linux-gnu)
compiled by GNU C version 8.3.0, GMP version 6.1.2, MPFR version 4.0.2,
MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 3c854693d01dc9a844a56a0b1ab1c0f4
gcc-test-function.cpp: In function ‘int DoIt()’:
gcc-test-function.cpp:9:1: warning: no return statement in function returning
non-void [-Wreturn-type]
}
^
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
as -v --64 -o /tmp/cc02zIqQ.o /tmp/ccMsF2uX.s
GNU assembler version 2.31.1 (x86_64-linux-gnu) using BFD version (GNU Binutils
for Debian) 2.31.1
COMPILER_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-linux-gnu/8/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../../lib/:/lib/x86_64-linux-gnu/:/lib/../lib/:/usr/lib/x86_64-linux-gnu/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-linux-gnu/8/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-Wall' '-Wextra' '-v' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib/gcc/x86_64-linux-gnu/8/collect2 -plugin
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #16 from Jakub Jelinek --- Created attachment 48366 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48366=edit gcc10-pr94734.patch So like this? The store data races thing can be covered by the non-addressable auto var checks.
[Bug rtl-optimization/94708] rtl combine should consider NaNs when generate fp min/max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708 --- Comment #3 from CVS Commits --- The master branch has been updated by Richard Biener : https://gcc.gnu.org/g:cbd2a10dd9edadb262934aed64c0959339da68d1 commit r10-7941-gcbd2a10dd9edadb262934aed64c0959339da68d1 Author: Haijian Zhang Date: Fri Apr 24 08:56:25 2020 +0800 rtl combine should consider NaNs when generate fp min/max [PR94708] As discussed on PR94708, it's unsafe for rtl combine to generate fp min/max under -funsafe-math-optimizations, considering NaNs. In addition to flag_unsafe_math_optimizations check, we also need to do extra mode feature testing here: && !HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode) 2020-04-24 Haijian Zhang gcc/ PR rtl-optimization/94708 * combine.c (simplify_if_then_else): Add check for !HONOR_NANS (mode) && !HONOR_SIGNED_ZEROS (mode). gcc/testsuite/ PR fortran/94708 * gfortran.dg/pr94708.f90: New test.
[Bug rtl-optimization/94708] rtl combine should consider NaNs when generate fp min/max
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94708 Richard Biener changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener --- Fixed.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #15 from Richard Biener --- (In reply to Jakub Jelinek from comment #13) > Even better. Note none of the committed testcases would be handled with this. There's also the issue of store data races (not sure if the notrap handling is correct there, it looks like not) - for auto variables that would not be an issue (but would need to be checked extra). A dominating store to the same location isn't enough to prove validity either since that might be inside a different protected region.
[Bug c/94726] [10 Regression] ICE in uniform_vector_p, at tree.c:11214 since r10-2089-g21caa1a2649d586f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726 Martin Liška changed: What|Removed |Added Assignee|marxin at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #3 from Martin Liška --- Leaving to a C maintainer.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #14 from Jakub Jelinek --- (In reply to Jakub Jelinek from comment #10) > bar is still miscompiled by some other optimization though > (and GCC 9 didn't do that), so we have some other regression. Sorry for the false alarm, the testcase was buggy, 17 is out of bounds. Let's sed -i -e 's/17, 17/15, 15/' in the testcase.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #13 from Jakub Jelinek --- Even better.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #12 from rguenther at suse dot de ---
On Fri, 24 Apr 2020, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
>
> --- Comment #11 from Jakub Jelinek ---
> If we don't want to revert the change completely, could we perhaps do:
> --- gcc/tree-ssa-phiopt.c.jj2020-03-19 10:23:50.542872359 +0100
> +++ gcc/tree-ssa-phiopt.c 2020-04-24 10:54:10.341716841 +0200
> @@ -2237,10 +2237,26 @@ cond_store_replacement (basic_block midd
> whose value is not available readily, which we want to avoid. */
>if (!nontrap->contains (lhs))
> {
> - /* If LHS is a local variable without address-taken, we could
> -always safely move down the store. */
> - tree base = get_base_address (lhs);
> - if (!auto_var_p (base) || TREE_ADDRESSABLE (base))
> + /* If LHS is an access to a local variable without address-taken
> +or its part and the access is provably within the bounds of the
> +local variable, we could always safely move down the store. */
> + HOST_WIDE_INT offset, size, decl_size;
> + bool reverse;
> + tree base = get_ref_base_and_extent_hwi (lhs, , ,
> + );
> + if (base == NULL_TREE || !auto_var_p (base) || TREE_ADDRESSABLE (base))
> + return false;
> + if (!DECL_SIZE (base)
> + || !tree_fits_shwi_p (DECL_SIZE (base)))
> + return false;
> + decl_size = tree_to_shwi (DECL_SIZE (base));
> + if (offset < 0
> + || size < 0
> + || decl_size < 0
> + || offset >= decl_size
> + || size > decl_size
> + || ((unsigned HOST_WIDE_INT) offset + size
> + > (unsigned HOST_WIDE_INT) decl_size))
> return false;
> }
That should be roughly equivalent to
if (!nontrap->contains (lhs)
|| !tree_could_trap_p (lhs))
which for ARRAY_REFs checks in_array_bounds_p.
[Bug c/94726] [10 Regression] ICE in uniform_vector_p, at tree.c:11214 since r10-2089-g21caa1a2649d586f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94726
Richard Biener changed:
What|Removed |Added
CC||jsm28 at gcc dot gnu.org,
||mpolacek at gcc dot gnu.org
Component|middle-end |c
--- Comment #2 from Richard Biener ---
So we are building the VEC_PERM_EXPR at a point where 'a' has vector type but
then later via
(gdb) bt
#0 pop_scope () at ../../src/trunk/gcc/c/c-decl.c:1375
#1 0x00976572 in pop_file_scope ()
at ../../src/trunk/gcc/c/c-decl.c:1456
#2 0x00ac6667 in c_common_parse_file ()
at ../../src/trunk/gcc/c-family/c-opts.c:1191
#3 0x0132b2e0 in compile_file () at ../../src/trunk/gcc/toplev.c:458
#4 0x0132e469 in do_compile () at ../../src/trunk/gcc/toplev.c:2273
we are patching up its type to an ARRAY_TYPE, resulting in invalid GENERIC
for the formerly built tree.
We should do no such thing here. Iff the FE wants to continue then it
should simply remove the shadowed decl from the bindings and continue
with the shadowing one. But here it seems to patch something up
what wasn't "merged" during duplicate_decls so clearly something is "off".
Oddly enough both b and b->shadowed refer to the same decl(?) and with
vector type(!). I guess I don't really understand the purpose of
the type "restore(?)" below:
tree
pop_scope (void)
{
...
/* It is possible for a decl not to have a name. We get
here with b->id NULL in this case. */
if (b->id)
{
gcc_assert (I_SYMBOL_BINDING (b->id) == b);
I_SYMBOL_BINDING (b->id) = b->shadowed;
if (b->shadowed && b->shadowed->u.type)
TREE_TYPE (b->shadowed->decl) = b->shadowed->u.type;
Martin, while we certainly can paper over this in the middle-end the
issue clearly lies in the FE so I suggest to leave this to FE maintainers
to sort out.
I suppose similar issues might arise with
double a;
double foo () { return a / 3.0; };
int a = 0;
where we should get a RDIV_EXPR with integer typed a. Hum, no, for some
unknown reason _this_ testcase has 'a' still have double type and we
do not run into the above code?! Ah, so in _this_ case we have
two different decls in b->decl vs. b->shadowed->decl and
b->shadowed->u.type is NULL.
Err, for the vector case we get everything correct up to popping
the vector a which somehow has itself registered as shadowed
but with array type?!
OK, so for the vector case we register two bindings for the same decl:
#0 0x0097496f in bind (name=,
decl=, scope=0x76c3b300, invisible=true,
nested=false, locus=266848) at ../../src/trunk/gcc/c/c-decl.c:729
#1 0x0097e409 in pushdecl (x=)
at ../../src/trunk/gcc/c/c-decl.c:3274
#2 0x00982c4f in start_decl (declarator=0x3764510,
declspecs=0x3764450, initialized=false, attributes=)
at ../../src/trunk/gcc/c/c-decl.c:5177
and then
#0 0x0097496f in bind (name=,
decl=, scope=0x76d7e1e0, invisible=false,
nested=true, locus=266848) at ../../src/trunk/gcc/c/c-decl.c:729
#1 0x0097e485 in pushdecl (x=)
at ../../src/trunk/gcc/c/c-decl.c:3295
#2 0x00982c4f in start_decl (declarator=0x3764510,
declspecs=0x3764450, initialized=false, attributes=)
at ../../src/trunk/gcc/c/c-decl.c:5177
and then update u.type of the shadowed here:
/* Deduce size of array from initialization, if not already known.
This is only needed for an initialization in the current scope;
it must not be done for a file-scope initialization of a
declaration with external linkage, redeclared in an inner scope
with the outer declaration shadowed in an intermediate scope. */
if (TREE_CODE (type) == ARRAY_TYPE
&& TYPE_DOMAIN (type) == NULL_TREE
&& TREE_CODE (decl) != TYPE_DECL
&& !(TREE_PUBLIC (decl) && current_scope != file_scope))
{
...
case 0:
/* For global variables, update the copy of the type that
exists in the binding. */
if (TREE_PUBLIC (decl))
{
struct c_binding *b_ext = I_SYMBOL_BINDING (DECL_NAME (decl));
while (b_ext && !B_IN_EXTERNAL_SCOPE (b_ext))
b_ext = b_ext->shadowed;
if (b_ext && TREE_CODE (decl) == TREE_CODE (b_ext->decl))
{
if (b_ext->u.type && comptypes (b_ext->u.type, type))
b_ext->u.type = composite_type (b_ext->u.type, type);
else
b_ext->u.type = type;
so the special case here is an array initializer. Indeed the following
testcase exposes the bogus RDIV_EXPR:
double a;
double foo () { return a / 3.0; };
int a[] = { 0 };
but we're not consuming the bogus IL anywhere it would ICE.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #11 from Jakub Jelinek ---
If we don't want to revert the change completely, could we perhaps do:
--- gcc/tree-ssa-phiopt.c.jj2020-03-19 10:23:50.542872359 +0100
+++ gcc/tree-ssa-phiopt.c 2020-04-24 10:54:10.341716841 +0200
@@ -2237,10 +2237,26 @@ cond_store_replacement (basic_block midd
whose value is not available readily, which we want to avoid. */
if (!nontrap->contains (lhs))
{
- /* If LHS is a local variable without address-taken, we could
-always safely move down the store. */
- tree base = get_base_address (lhs);
- if (!auto_var_p (base) || TREE_ADDRESSABLE (base))
+ /* If LHS is an access to a local variable without address-taken
+or its part and the access is provably within the bounds of the
+local variable, we could always safely move down the store. */
+ HOST_WIDE_INT offset, size, decl_size;
+ bool reverse;
+ tree base = get_ref_base_and_extent_hwi (lhs, , ,
+ );
+ if (base == NULL_TREE || !auto_var_p (base) || TREE_ADDRESSABLE (base))
+ return false;
+ if (!DECL_SIZE (base)
+ || !tree_fits_shwi_p (DECL_SIZE (base)))
+ return false;
+ decl_size = tree_to_shwi (DECL_SIZE (base));
+ if (offset < 0
+ || size < 0
+ || decl_size < 0
+ || offset >= decl_size
+ || size > decl_size
+ || ((unsigned HOST_WIDE_INT) offset + size
+ > (unsigned HOST_WIDE_INT) decl_size))
return false;
}
+ xfail the tests from the PR89430 because they all need the nontrap ARRAY_REF
etc. handling?
With that, in the above testcase baz is still cselim optimized , but foo and
bar are not. bar is still miscompiled by some other optimization though (and
GCC 9 didn't do that), so we have some other regression.
[Bug target/94710] [8/9/10 Regression] Assembler messages: Error: operand out of range (4 is not between 0 and 3) (xxsldwi 0,32,33,4)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94710 --- Comment #7 from Segher Boessenkool --- Needs -mvsx -mlittle -O0 to fail.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734
--- Comment #10 from Jakub Jelinek ---
Yeah.
add_or_mark_expr could be extended to handle more complex addresses (perhaps
get_inner_reference and hash on the decl + offset expression and taking into
account the bitpos/bitsize then?
Further testcase. Both foo and bar are miscompiled, baz is fine because arr[7]
is known to be always within the object bounds.
__attribute__((noipa)) int
foo (int n)
{
int arr[16], s = 0;
for (int i = 0; i < n; i++)
{
if (i < 16)
arr[i] = i;
}
for (int i = 0; i < 16; i++)
s += arr[i];
return s;
}
__attribute__((noipa)) int
bar (int n, int x, unsigned long y, unsigned long z)
{
int arr[16], s = 0;
arr[4] = 42;
for (int i = 0; i < n; i++)
{
if (x == (i & 0x25))
arr[y] = i;
}
return arr[z];
}
__attribute__((noipa)) int
baz (int n, int x, unsigned long z)
{
int arr[16], s = 0;
arr[12] = 42;
for (int i = 0; i < n; i++)
{
if (x == (i & 0x25))
arr[7] = i;
}
return arr[z];
}
int
main ()
{
if (foo (10374) != 15 * 16 / 2)
__builtin_abort ();
if (bar (25, 0x25, (unsigned long) 0xdeadbeefbeefdeadULL, 4) != 42)
__builtin_abort ();
if (bar (25, 4, 17, 17) != 22)
__builtin_abort ();
if (baz (25, 0x25, 12) != 42)
__builtin_abort ();
if (baz (25, 4, 7) != 22)
__builtin_abort ();
if (baz (25, 4, 12) != 42)
__builtin_abort ();
return 0;
}
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #9 from Richard Biener --- (In reply to Richard Biener from comment #8) > In particular tree_could_trap_p woudl consider the load possibly trapping > due to the variable indexing but the patch seems to override that which > I agree is bogus. I think we need to revert it and re-implement for GCC 11. > All testcases contain a dominating load in the condition and what we _can_ > do is treat loads of stack variables the same as stores as far as > non-trappingness is concerned. Actually the non-trapping machinery only considers plain SSA name dereferences so there's much more to extend. Definitely nothing for GCC 10.
[Bug tree-optimization/94734] [10 Regression] Program crashes when compiled with -O2 since r10-1892-gb9ef6a2e04bfd013
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94734 --- Comment #8 from Richard Biener --- In particular tree_could_trap_p woudl consider the load possibly trapping due to the variable indexing but the patch seems to override that which I agree is bogus. I think we need to revert it and re-implement for GCC 11. All testcases contain a dominating load in the condition and what we _can_ do is treat loads of stack variables the same as stores as far as non-trappingness is concerned.
[Bug tree-optimization/94675] [9/10 regression] -Warray-bounds false positive with -O2 since r9-1948
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675 --- Comment #16 from Xavier --- (In reply to Martin Sebor from comment #14) > That said and codegen improvements aside, I think the submitted test case is > sufficiently tricky that I don't see issuing a warning for it as a problem. > All flow-based warnings have a non-zero rate of false positives (as do many > front-end warnings) and there are mechanisms to avoid them. Compared to > some of the other false positives we have, avoiding this one seems like a > low priority to me. Well is there a workaround ? Or do you suggest using pragma ignore ?
[Bug other/94741] stringop-truncation is triggered or not depending on surrounding members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94741 Richard Biener changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED Known to work||10.0 --- Comment #2 from Richard Biener --- Fixed on trunk.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 Thomas Koenig changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #12 from Thomas Koenig --- Fixed.
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 --- Comment #11 from Thomas Koenig --- Fixed on all open branches. Thanks a lot for the bug report! Regards
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 --- Comment #10 from CVS Commits --- The releases/gcc-8 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:aadc54867cc200ad7d073222769b9de7f13b5bcd commit r8-10218-gaadc54867cc200ad7d073222769b9de7f13b5bcd Author: Thomas König Date: Fri Apr 24 09:26:48 2020 +0200 Fix PR 93956, wrong pointer when returned via function. Backport from trunk. This one took a bit of detective work. When array pointers point to components of derived types, we currently set the span field and then create an array temporary when we pass the array pointer to a procedure as a non-pointer or non-target argument. (This is inefficient, but that's for another release). Now, the compiler detected this case when there was a direct assignment like p => a%b, but not when p was returned either as a function result or via an argument. This patch fixes that. 2020-04-24 Thomas Koenig PR fortran/93956 * expr.c (gfc_check_pointer_assign): Also set subref_array_pointer when a function returns a pointer. * interface.c (gfc_set_subref_array_pointer_arg): New function. (gfc_procedure_use): Call it. 2020-04-24 Thomas Koenig PR fortran/93956 * gfortran.dg/pointer_assign_13.f90: New test.
[Bug other/94741] stringop-truncation is triggered or not depending on surrounding members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94741 --- Comment #1 from Daniel Adamski --- Oh, I just checked in godbolt and it seems it is already fixed in "trunk" version: https://godbolt.org/z/hyCQCX
[Bug other/94741] New: stringop-truncation is triggered or not depending on surrounding members
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94741
Bug ID: 94741
Summary: stringop-truncation is triggered or not depending on
surrounding members
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: danregister at poczta dot fm
Target Milestone: ---
The example code compiled with "-Wall -Werror -O2" gives:
main.cpp: In constructor ‘S3::S3(const char*)’:
main.cpp:26:22: error: 'char* __builtin_strncpy(char*, const char*, long
unsigned int)' specified bound 5 equals destination size
[-Werror=stringop-truncation]
26 | __builtin_strncpy(a_, a, kMaxLen);
It complains only about S3 while it should complain about all of them.
The example code:
constexpr auto kMaxLen = 5;
struct S1 { // just array
S1(const char* a);
char a_[kMaxLen];
};
S1::S1(const char* a) {
__builtin_strncpy(a_, a, kMaxLen);
}
struct S2 { // int member before array
S2(const char* a);
int n_;
char a_[kMaxLen];
};
S2::S2(const char* a) {
__builtin_strncpy(a_, a, kMaxLen);
}
struct S3 { // int member after array
S3(const char* a);
char a_[kMaxLen];
int n_;
};
S3::S3(const char* a) {
__builtin_strncpy(a_, a, kMaxLen);
}
[Bug fortran/93956] Wrong array creation with p => array_dt(1:n)%component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93956 --- Comment #9 from CVS Commits --- The releases/gcc-9 branch has been updated by Thomas Kथà¤nig : https://gcc.gnu.org/g:2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6 commit r9-8541-g2a732dbdfcc0a3bc2b4bdb5387fffa193fea6df6 Author: Thomas König Date: Fri Apr 24 08:22:48 2020 +0200 Fix PR 93956, wrong pointer when returned via function. Backport from trunk. This one took a bit of detective work. When array pointers point to components of derived types, we currently set the span field and then create an array temporary when we pass the array pointer to a procedure as a non-pointer or non-target argument. (This is inefficient, but that's for another release). Now, the compiler detected this case when there was a direct assignment like p => a%b, but not when p was returned either as a function result or via an argument. This patch fixes that. 2020-04-24 Thomas Koenig PR fortran/93956 * expr.c (gfc_check_pointer_assign): Also set subref_array_pointer when a function returns a pointer. * interface.c (gfc_set_subref_array_pointer_arg): New function. (gfc_procedure_use): Call it. 2020-04-24 Thomas Koenig PR fortran/93956 * gfortran.dg/pointer_assign_13.f90: New test.
